Thoughts after installing KISS Linux
I have used NixOS for almost two years. I like that I can safely reinstall and wipe my disks without worrying I might lose important configuration since it’s all in a git repo. However, the uncomfortable truth is that Nix(OS) is extremely complex, both technically and to use.
Of course, Nix is the only real solution to a problem that didn’t need to exist in the first place. (I have planned an article about dynamic/static linking but it isn’t ready yet). What I hate the most about NixOS is that you are absolutely forced to use systemd. Systemd is by far the worst piece of free software on earth
Well yeah, we’re not talking about bad software, this post is, surprisingly, very positive.
What’s KISS Linux
KISS Linux takes the KISS principle (Keep It Simple Stupid) to its logical conclusion. It’s a meta-distribution created by the man himself, Dylan Araps (the guy that created neofetch, and the pure (ba)sh bibles among other things).
A distro really isn’t more than a package manager. What is Arch if not pacman? What is Debian if not apt? What is Fedora if not dnf? Sometimes just a desktop environment on top of it (Of course, the desktop environment is most likely KDE or GNOME, not part of the distribution in and of itself).
KISS, as well, presents its own way of managing packages, which I think is as close to perfection as a package manager can be. It has features that I haven’t seen in other package managers, features that should be basic. And everything around 1000 lines of POSIX shell. Absolutely impressive.
By default you’re given busybox utilities (and init system), the musl C library, and pretty much nothing else. The installation is similar to Arch or Gentoo, in the sense you do everything manually, which makes you understand everything about everything.
Installation
I have to admit, it took me a few days to have a working minimal system. I wanted to do things a little bit differently than I usually do, so I needed to step outside of my comfort zone.
Before installing it on my main production machine(s), I wanted to test it out, not in a VM, but on real hardware. I installed it on a Thinkpad T410 I had lying around and wasn’t using. Also, I used an outdated Arch Linux installation media I had as well, because I didn’t want to flash anything.
Of course, this isn’t a tutorial, I won’t go through all installation steps unless I find them particularly interesting. It’s not much different than installing Arch anyways.
Grub
During the installation process I stumbled upon a bunch of different roadblocks, Grub was the first one of them.
The Thinkpad T410, of course, doesn’t support UEFI. So I’m doing a
traditional BIOS installation. After running grub-install
and no errors reported I confidently rebooted my PC, not
expecting it to boot (since I don’t have anything), but at least I
expected to see the grub menu.
Sadly, this was the least satisfying solution of this whole process.
After several hours of trying different things, manually creating
grub.cfg, using grub-mkconfig, everything,
still failed. Even BEFORE it had read the configuration file. To this
day I’m unaware of any real solutions or even what was
the root of the problem. What I ended up doing was running the
grub-install present in the ARCHISO, not in the chrooted
environment. It worked without problems…
Initramfs
In KISS fashion, I didn’t want to use scripts like
mkinitcpio or whatever. I wanted the true
experience of making my own initramfs, honestly, this was the part I
enjoyed the most about this installation. Of course, this is not
KISS-specific, but I was already with the “KISS mindset” so I might as
well do it.
Doing your own initramfs is literally, selecting a directory to work
with, and creating your minimal filesystem. This filesystem should have
installed all the necessary utilities to do whatever it is that you want
to do before booting the system. For me, this includes
busybox for regular unix utilities, and
cryptsetup for actually decrypting the disk.
Remember, if you’re installing busybox in an initramfs, make sure all symlinks are relative and not absolute. I made a few mistakes that forced me to start over, and ALWAYS forgot that.
In your initramfs you need an init script, this script
will be the first thing your kernel runs. Use this script to mount
necessary filesystems (proc, sysfs,
devtmpfs & tmpfs). Without these
filesystems mounted the system can’t function properly.
What gave me problems here was kernel modules. Since this was only a
installation and there were various things that could go wrong, I was
hesitant to compile my kernel before I had a functional system. So I
lazily copied the vmlinuz image present in the archiso and
stopped worrying about it. The problem was that it didn’t have the
modules for decrypting the drive builtin, so I needed to
modprobe them and copy them into the initramfs. With the
correct structure and stuff.
After that was sorted out, I finally found myself booted into a minimal kiss linux and I could stop relying on the live ISO (or so I thought)
Kernel
Of course, I needed to compile my own kernel if I wanted to be a cool kid, so I did. (And using the arch kernel was a temporary solution, as I didn’t want to be loading kernel modules manually all the time, nor did I want to create scripts that do that. Loading kernel modules is a lot like dynamic linking so I wanted everything (or at least almost everything) to be built into the kernel itself).
I thought that running make defconfig would give me a
starting point of functional configuration that will apply to roughly
all machines. That wasn’t the case, at least for me. The kernel didn’t
boot with the default configuration. It was missing a lot of essential
modules that really should be the defaults. Mostly those about
cryptography.
I had to load the i915 driver for my integrated gpu to work properly
and tinker with a few related settings to get graphics working. But
eventually I got it. If your graphics aren’t working properly and you
want to boot into your system, try adding nomodeset as a
kernel parameter in your bootloader, this worked for me while I tried to
get graphics working properly.
However, after the graphics loaded properly now I had a problem… The TTY didn’t have proper colors…
I KNOW IT’S A NITPICK, I WON’T BE USING THE TTY REGULARLY ANYWAYS
After (again) several hours of trying different configurations,
different kernel modules etc… I finally got it. It wasn’t a kernel
problem, it was a grub problem. What I did was
insmod video modules (vbe, vga,
font, gfxterm). Configure
grub to use graphics instead of the fallback VESA video
and in your kernel parameters add vga=current. Not only
your colors are fixed, but your bootloader looks pretty, as well.
After installation
I’ve been using it, not as my daily driver, but as a “playground” where I can try certain things once in a while, and it hasn’t been that hard to do what I want. The upstream repos are tiny, which encourages you to create your own repo, which I did after a few hours of installing it.
The first thing I packaged was zsh. The
community repo has zsh packaged but… is it
broken?? For some reason $(command substitution) hangs
forever. So I packaged it myself. I’m not entirely
sure, but my guess is a musl compatibility problem. When I needed to
package something the Alpine repos have been of great use to me, since
they already have patches for making software work on musl.
I just looked at Alpine’s APKBUILD, downloaded the patches and
translated everything into kiss’ build system, and I had
zsh working like a charm in no time.
I packaged a few things after zsh, if upstream provided
statically-linked binaries I just downloaded them and copied them, I
might be a purist about a lot of things, but I’m not a “compile
everything” purist. If upstream provides a perfectly working static
binary, I just save a lot of time by using it, not just
compiling, but in crafting a build script as well.
I don’t mind compiling most of my software, but if I can avoid it, I will. However, if there’s one thing I will DEFINITELY NOT COMPILE, is a web browser.
Installing Nix in Kiss
If you want to use proprietary software or bloated software on Kiss you’re in a tough spot. Most, if not all, proprietary software (and upstream binaries of free software) are dynamically linked against glibc, which Kiss Linux doesn’t use. With free software you can get away with it by recompiling it and linking it against musl (at which point you might as well statically link it).
The only other solution would be using an alternative packaging system/manager. Options are flatpak, appimages and… docker?? (I guess). Of course, you read the subtitle, what I went with was nix. Honestly because I’m way more familiar with nix and is the best (but still not perfect) solution for dependency linked dynamic hell.
I could package nix as a kiss package; I KNOW it’s (probably)
possible. But honestly, nix being such a massive thing (build users,
daemon, need to load environment variables, creating the /nix/store,
etc…) I really didn’t want to do that. First I thought to lazily copy
the upstream installation script into the build script, of
course that wasn’t going to work because kiss runs that script in
isolation, so it wouldn’t install anything. I had to do everything
manually. But I didn’t want to lol. Maybe later I’ll actually do it.
As expected, the installation script provided by nixos.org
wasn’t portable at all. It had a hard dependency on
sudo, non-standard cp options. And another
problem that I didn’t know what was causing it. The first fix was
symlinking doas to sudo, and thhose parts of
the script worked. Then, I used kiss’ alternatives system
to temporarily change busybox’s cp to gnu’s
cp. At the end of the script it said something along the
lines of
Remember to add this to your profile so the environment variables work and nix can do its thing
.(Obviously not the exact words but you get the idea)
Yes, just a period. I’m guessing the script was hardcoded to add a
. and then a path to source required environment variables,
but something went wrong. What went wrong? honestly, no idea.
Anyways I added the scripts inside
~/.nix-profile/etc/profile.d/* to my shell profile, and nix
was working flawlessly.
After installing Nix, I already have everything I should need for a functional system. If for some reason I can’t do something with regular kiss, I have Nix to use as a fallback.
Conclusion
Surprisingly, installing Kiss Linux was a really good experience overall, I got to learn a lot about the system’s internals that I couldn’t have learned otherwise. Compiling all your software isn’t that bad, as long as you install mostly minimal software, (which you should be doing already). I might switch my production machines to Kiss, but I will have to test it more days to see if I completely like it.
Also, I need to figure out a way for remote building of packages, so I can use my homelab to compile everything instead of choking my poor thinkpad.
Making a script for declarative packages and services so I have the exact same git-managed setup in every machine shouldn’t be that hard. Once I have that I will happily move all my machines to Kiss. Or perhaps I will try oasis?? I don’t know at this point.