Plan 9.r(hizoome) post 00/B45D
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!