Oct 102020
 

One of the big names in the opensource world – Eric Raymond – has declared that Windows will soon be effectively a Linux distribution. Which seems like a ridiculous notion; except technically it might make a lot of sense.

How?

It seems impossible for Microsoft to replace Windows with Linux, but actually it could be done. Windows itself consists of a bunch of software applications which call Windows “APIs” which in turn make calls to the legacy NT kernel. If all that software is written cleanly (it won’t be, but bear with me), it should be possible to make modifications to both (or either) the Linux kernel and the Windows APIs to allow Windows software to run natively.

Impossible? Nope – it has already been done to a certain extent – Wine and Proton allow a considerable amount of Windows software (and games!) to run under Linux.

Why?

So it’s not impossible, but surely it is a lot of work. So why?

Microsoft has a bit of a problem – they don’t make a huge amount of money selling the Windows operating system, and maintaining it is hugely expensive. All those security fixes, all those bug fixes, and all those new features they want to introduce.

Now most of this is done to the “userland” rather than the kernel itself, but the kernel does still need to be maintained. But what if you could use the Linux kernel and get some level of maintenance supplied by those not employed by Microsoft?

Would that save Microsoft money? It seems quite possible, and you can bet someone in Microsoft has estimated whether it would or not.

Will It Happen?

There are those who point to certain actions by Microsoft – the Linux subsystem for Windows, the Edge browser for Linux, the rumour of an Office build under Linux, etc. as indicators that Microsoft is planning this.

I think they’re wrong to the extent that those actions don’t say whether Microsoft is planning to make Windows a Linux distribution or not. There are plenty of reasons why Microsoft is releasing Linux software not least because they will almost certainly have developers that believe that porting software is a good way of finding bugs.

The real answer is that the only people who know are inside Microsoft.

The Join
Jul 112020
 

So I am currently messing around with a tiling window manager on my laptop – I prefer tiling window managers in general (I use Awesome on my main desktops). These are (in general) not “desktop environments” but just manage windows (and sometimes a “status bar”).

As it happens the window manager I’m messing with doesn’t come as part of a distribution package with a pre-prepared file for GDM3 to use. So I created a ~/.xsession file – something that has worked since display managers first arrived.

Didn’t work.

Turns out that I need to “hack” GDM3 to make a long standard bit of functionality functional again. As an aside (and especially to the GNOME people), all you had to do to keep this functional was detect if someone had a ~/.xsession file and then offer that up as a menu option. Not that difficult to do and even if it isn’t your preferred way of doing things, it’s a nice thing to do for us old-timers.

Anyway, to restore this functionality all it took was to create a file in //usr/share/xsessions/ called xsession.desktop with the following contents :-

[Desktop Entry]
Name=XSession
Comment=This session uses the custom xsession file
Exec=/etc/X11/Xsession
Type=Application
DesktopNames=GNOME-Flashback;GNOME;
X-Ubuntu-Gettext-Domain=gnome-flashback

Dead simple.

And yes I stole this and adapted it myself – I’m putting this up here so that I know where to look when I need it again.

Jun 222020
 

I have a problem with serial ports (usually “virtual ones” or USB←→serial port dongles) – I have too many of them, and I usually end up with the wrong one. And selecting a TrueRNG serial port and connecting a terminal emulator to it gets very messy very quickly.

So I was searching around, semi-idly wondering if I could somehow build a device name to USB name mapping that I could stuff into rofi (or dmenu) and I discovered the /dev/serial/by-id/ which did 99% of the work for me.

So yes, I can invoke kermit and up will pop a menu allowing me to select which serial port to connect to :-

ls /dev/serial/by-id |\
  rofi -dmenu -l 20 -p "Pick a serial device" -font "mono 20"

That is the core of it, but to make it functional I need to embed it into a command line argument to kermit :-

alias kermit='kermit -C "set line /dev/serial/by-id/$(ls /dev/serial/by-id | rofi -dmenu -l 20 -p "Pick a serial device" -font "mono 20"),set carrier-watch off"'

Which is admittedly a bit of a mouthful!

But so useful if you have two or three USB to serial adopters plugged in plus a switch’s console port and a Linux widget that provides a serial console.

Jun 222020
 

Unfortunately, the serial communication program I tend to use (kermit) appears to have not been updated in quite a while. Which in some ways is reasonable (it’s a very old program and probably does not need much work), understandable (the main developer is no longer employed to make it work), but is somewhat frustrating when it no longer compiles.

To get it to work on my latest system :-

  1. Download the cku302.tar.gz source code and unpack.
  2. Try the first compile with make linux KFLAGS=-DNOARROWKEYS (losing the arrow keys is unfortunate but not fatal unless you’re in command mode far too long).
  3. If that doesn’t compile with zillions of undefined references to curses sounding functions (printw, stdscr, wmove, etc.) then scroll up to the top of the errors where the final command to “compile” all the objects into a final binary is available. Paste that command and add a “-lncurses” :-
$ gcc  -o wermit \
      ckcmai.o ckclib.o ckutio.o ckufio.o \
      ckcfns.o ckcfn2.o ckcfn3.o ckuxla.o \
      ckcpro.o ckucmd.o ckuus2.o ckuus3.o \
      ckuus4.o ckuus5.o ckuus6.o ckuus7.o \
      ckuusx.o ckuusy.o ckuusr.o ckucns.o \
      ckudia.o ckuscr.o ckcnet.o ckusig.o \
      ckctel.o ckcuni.o ckupty.o ckcftp.o \
      ckuath.o ck_crp.o ck_ssl.o -lutil -lresolv -lcrypt -lncurses -lm

The final output of “wermit” just needs to be stripped, moved to a proper location, and renamed :-

$ strip wermit
$ sudo mv wermit /opt/bin/kermit

And there it seems to work fine.

Of course this is not a proper fix, and we are missing a lot of features but it is at least working. And saves me from having to struggle with minicom, screen, or cu.

Jun 212020
 

If you are just running Ubunbtu with ZFS without poking into the details, you may not be aware of the scrubber running. For background information, and for the benefit of those who prefer to go their own way, this is all about that little scrubber.

A pool scrub operation is where the kernel runs through checking all of the data in a pool and makes any necessary repairs. Whilst ZFS does check the integrity of the data (using checksums) when performing reads, a regular scrub repairs these issues in advance.

It need only be run weekly for larger systems or monthly for normal systems (it’s a pretty arbitrary border line). And can be started manually with :-

# zpool scrub pool0

(And “pool0” being the name of the pool to scrub)

Whilst a scrub is going on in the background, the only effect on the system is that disk accesses to that pool will be slightly slower than normal. Usually not enough to notice unless you are benchmarking!

When in progress the output of zpool status pool0 will show the current state and how long it is expected to take to complete the scrub. Once finished the status will look like :-

# zpool status | grep scan:
  scan: scrub repaired 0B in 0 days 09:19:27 with 0 errors on Sun Jun 21 10:36:28 2020