For the past few weeks, I’ve been refining Wyverkiss for use in my production machine. It’s not perfect by any means, but it’s usable. There are still some GNU packages installed like ncurses, but it’s not urgent for me, for now, and would be fairly trivial to replace.
So far, it actually is a smooth experience. No real hard hiccups aside of some builds which requires GNU Make, so bmake can’t be used. I’ve also sent some patches and issues to projects for issues regarding Makefiles and yacc commands (such as curl and libxkbcommon). A lot of patches and pointers have been contributed by E5ten on the KISS IRC channel, and for that, thanks to him/her/them/(whatever the pronoun is)!
However, since I’m pretty much done with Wyverkiss (except the part that some packages need GNU programs to build, but that one also applies to Wyvertux in this case), what’s next? I have some visions which will make Wyvertux less like KISS and Carbs Linux, and more in line with traditional Linux distributions (think Debian, Fedora, Arch, or Gentoo) since I think KISS (and by extension, Wyverkiss) is already perfect when we’re talking about “simple” distributions.
-
Wyvertux doesn’t aim to be a minimal and/or lightweight distro.
A lot of Linux distributions aim to be minimal, this is not the case for Wyvertux since we aim to make a GNU-free Linux, that’s it. Yes, this means PulseAudio and D-Bus will be included in the distribution (though I don’t know if it will be installed by default). Yes, even systemd (if this is even possible, though with the core part of Wyvertux being musl, I doubt this will do).
-
Wyvertux aims to have just one implementation of a (core) function, if possible.
I don’t plan to support different implementations of a core functionality (e.g. just eudev, no mdev - or util-linux will provide certain binaries, not busybox) this is a practical limit since the manpower is not sufficient to support both (i.e. I can’t do more than one implementation), however while I don’t provide support (i.e. will fix at once) if something doesn’t support what Wyvertux wants, but I will help in any way I can.
-
Only a few packages will be statically linked
To retain core functionalities if something goes kaput, a few packages (such as busybox, util-linux, and rsync) will be packaged statically. However, that’s it. Otherwise, it’s all dynamically linked.
-
Wyvertux (still) aims to be completely customizable, even if you’re on your own.
Wyvertux will steal the functionality of
kisspackage manager for this one. Since it’s really flexible, I think one can mix-and-match packages from KISS and Wyvertux (note: this is not supported, Wyverkiss is available for that purpose). Like I said, I will help in any way I can, but I don’t officially support it. -
Wyvertux will support amd64. That’s it.
Again, this is a practical limit since I don’t have any ARM device to test on. I don’t even know if my kiss-llvm repo for KISS even build in other architectures, though I believe James Davies (jedavies-dev on GitHub) is trying (or has tried) it in ARM64. I hope it does build (though I think there will be some build flags needed to be changed)!
-
Make sure GNU packages are also available in Wyvertux (EXCEPT toolchain packages)
While this is a direct contradiction of vision #2, I recognize that some GNU packages are superior to its competitors, such as GNU coreutils, GNU bash, and a few others. We will make them available, upon request, in a separate
gnu/repo directory. For toolchain packages, we only build with GNU toolchain (and even then, I still have a few more restrictions (e.g. GNU Make only)) if it can’t be build with standard Wyvertux toolchain.
I hope I can resume development on mid-May 2020 if my spare laptop works, as it’ll receieve a hell lot of agony because of constant compling.