Plan 9.r(hizoome) post 00/B45D

Tags: @9rhiz @English

DISCLAIMER: If you want to know what I discover inside the box keep on reading. If you want to know how to use the box properly please go to 9front.org. For plan9 experts reading this: I promise to do everything by the book one day and as much as I can as a go, but that is not my priority.
This is about my learning process: Everything I post worked at the time, but has probably been replace by something better or more correct by now.

Reducing complexity

I have been reducing my Linux setup for a while. Currently I am running alpine in an offline dial-up-style. The complete distro and all distfiles are local. I am running kmscon and tmux (no graphical interface). All external git-projects and mail can be synced with a command. With the insteadOf config in git, I can even do offline git-submodules. I very often go into the aports directory - to a package - and do abuild unpack to read the source of the package instead the online research I would have done in the past. I also have wikipedia, the complete stackoverflow, superuser and serverfault served by kiwix-server. With zimwriterfs I make a zim-file of all the documentation I downloaded because the docs are missing in man. I read this with the links browser. I go online about 3 times a day.

I have written all the glue you usually have on a desktop in lua. If you write and have written as much code as I do, this is faster than configuring all the desktop tools correctly. At least if you configure it to the degree I would. For example if I press meta-space in tmux I get this menu that uses fzf.

▌ suspend
▌ print up
▌ print down
▌ reboot
▌ backup
▌ network up
▌ poweroff
▌ sync
▌ network down
▌ sync more
  10/10 ───────────
>

The limit

But here I hit the limit. I have been trying to remove the very complex compiler-chain. I had some success for example using oasislinux and musl-cross-make: I have been able to create a static sysroot that can compile itself. So it is kind of independent of the global update-rat-wheel. I also looked into compiling most of my tools with cproc and qbe, which is possible. But because of the Linux-kernel gcc would have to foot in the door forever.

Plan b

A kind person reminded me of plan9 - actually 9front. It’s absolutely amazing. I booted it and it confused me because it said it was using cga, but displayed in a graphics mode it could only use if had initialized the graphics card. First I assumed it initialized the framebuffer in UEFI and just kept using it. But that didn’t feel right. So I opened /sys/src/9/pc/vgaigfx.c. I could read it like book. If I tried the same thing in Linux I would be cross-referencing things for many hours. I was pretty sure that it initialized vgaigfx without updating the information in /dev/vgactl. I added a bunch of print statements and compiled the kernel with mk all to get 9pc64. I took less than 3 minutes. Then I didn’t find out where there kernel is stored, because I didn’t actually install 9front, but just booted it from a USB-stick. By now I know where it is stored, but then I decided to get my hardware ready for 9front kernel development, since there are a few quirks I have to fix if I wanted to use 9front as main OS.

Hardware

I have a fixed hardware I decided to use forever. The Hardware of Theseus. On the server side it is modular hardware I can get replacements easily. My ‘workstation’ is a very common notebook from 2015 that is easy to find on second-hand markets and it is one of the last relatively modular designs by that company. You can even still get new third-party batteries. But the firmware is proprietary UEFI only. I have stocked a few them, I even bought some broken ones and fixed them to see if it fits my requirements. I planned to use it with Linux which supports everything but WiFi, what I obviously don’t need. With 9front I have a few issue. For one I need backlight control. I consulted the intel HD 6000 manual and I think it is very easy to control using a register I should get access to via mmio in vgaigfx.c, of course things get more difficult if I want to properly expose the control to /dev/backlight.

The mouse

I am very keyboard-centric. Not because I think it is superior in any way. There are actually many downsides. But my brain just loves to memorise and execute sequences of shortcuts. I have learned about the philosophy of plan9 many years ago and keyboard-centric people will not be happy there. I definitely plan to use the mouse more, but I’m in a position where I just write my own tools; plan9 is very open to scripting. Also 9front is more open than plan9 was. There is riow that makes rio more keyboard-centric for example.

Qemu

This has become a very different post than I planned. I actually wanted to show I how automated 9front with qemu and lua, so I can stay in my familiar Linux environment a bit longer. But I felt I need to describe my motivation. So qemu and lua is the next post.

Happy Φc!