I have been working on a small independent Linux distribution called Zainium OS, and I would like honest feedback from people here. It is still early and not ready for daily use.
The main idea is simple. There is no /usr at the root. The whole system lives in layers under /overlayer, so the base and the software you install never mix. The base is read-only, even for root, but apps still install and run straight away, with no reboot.
Most software still works, because a small library finds the right file when a program asks for an old path like /usr/bin/env.
Two questions for you:
Is dropping /usr worth the trouble, or would you rather keep the usual layout?
What would you need to see before you tried a new distro like this?
If you would like to try it, please use a VM or a spare computer: Download Ā· Zainium OS
Fair question. Yes, AI tools were used extensively. Some package recipes, several bug fixes in the initramfs, were written with AI assistance.
I design the system, test it on my own hardware and in VMs, and take full responsibility for it. It is all open source, so please judge it by the code. I should have said this in the first post.
Thank you for the honest assessment.
The key question for us on this forum is " did you do enough of the planning and coding work yourself to be able to understand it and debug it and maintain it?"
It is hard for us to judge. What do you say to that?
Honest answer: partly. The design, layers, and core decisions are mine. I run and test this system daily, so I catch the bugs and decide what ships.
I maintain the recipes and boot logic, but AI wrote some of the OverlayFS patch fixes, and I am still learning those deep VFS details.
If anyone finds a bug, I will fix it or be transparent when I need help.
You are a long way better than someone who vibe-coded a whole project in 2 days and published it in their own name, without underdtanding any of its content.
OK, we can cope with this on our forum .
I hope you find someone interested enough to test it.
My own feeling is it may appeal more to business users than to home users. ā¦ immutable sort of goes against people who like to fiddle with their system.
I think your warning is important ā¦ try it in a VM or a spare machine.
Do you think it will behave well in a multiboot situation ā¦ ie will the installer not try to grab the whole disk ā¦ will grub detect it ?
That is completely fair. Immutable systems and customs setups are definitely not for everyone, and traditional distros give you a level of familiarity and flexibility that custom ones just cannot match
No offense taken at allāappreciate you taking the time to check it out!
Thank you, that means a lot. You may be right about business users, and I will
keep the warning in.
Multiboot is not ready yet. The installer erases the whole disk it is given and
makes its own partitions, so please do not point it at a disk that has another
OS. It asks you to confirm before it erases, but there is no āinstall alongsideā
option for now. It boots with Limine, and I do not expect GRUB to detect it,
because os-prober looks for files in places that do not exist on this layout.
I have not tested that.
For now, a VM or a spare disk is the safe choice. Multiboot is now on the roadmap:
The day is coming when you generate your own OS to specs. Distros will be redundant, and updates will consist of generate a new whole distro using the updated AI model.
The whole thing will probably be put into firmware, and you just press the ānew osā button.
While I do appreciate the idea of this distribution, and I hope its unique filesystem layout will expose bugs in software which make just too many assumptions, I also will not be testing this thing.
That being said: I have been poking around in its repositories, but, for the life of me, I could not find out which init system it uses by default. Why did you go for that init system? How is it implemented? How does it relate to the rest of the OS (if applicable)?
Wowā¦ all those modern choices , combined with crappy old systemd?
I wonder if @alizain has looked into modern efficient init systems like dinit or s6-66?
To answer honestly: We actually started out with a custom init system written in Rust alongside quantra-ramfs. However, we ran into a major roadblockāenvironments like the COSMIC desktop rely heavily on systemd and OpenRC service management.
Being a solo developer, maintaining a custom init system while trying to build a completely non-FHS custom filesystem layout (/usrless architecture) became too overwhelming to handle alone. If we had gone the OpenRC route (like Alpine), we would have had to write and maintain extensive custom patches for a massive number of upstream packages that assume systemd. Sticking to systemd saved countless hours and ensured software compatibility didnāt break entirely.
If the DHS 1.0 filesystem layout and base packages stabilize over the next couple of months, I might revisit exploring lightweight init alternatives, but right now, systemd is kept purely for stability and ecosystem compatibility.
@nevj You nailed it. Indeed, using systemd in a modern custom/immutable distro is quite ironic with all the advanced decisions!
The choice was based solely on bandwidth and compatibility with packages. If we were to use some OpenRC method, then it would have been impossible for one person to patch hundreds of packages in order to remove any mention of systemd services, as well as designing our own VFS structure and zex.
Furthermore, it saved me lots of time in terms of packaging compatibility of things such as desktop services and Flatpaks. Perhaps in the future, when everything will be fine-tuned, we will try something else, but until then, it is just a necessity!
Dinit and s6 are quite modern. Why not use those ā once youāve managed to attract some help ā instead of building your own? That way, if you find a bug you get to complain with the developer, instead of having to fix it on your own.
I understand. I have done things with init systems.
Remember systemd is more than 10 years old and unfortumately has its tentacles embedded in some packages. The non-systemd distros that are based on a systemd distro ( eg antiX, Devuan) do a lot of work to remove it.
It is possible for a distro to be systemd and non-systemd simultaneously , and even to switch between them ā¦ see MX Linux.
Consider this. Systemd is over 1.4 million lines of code. Dinit is about 10000 lines of code. Dinit can do anything systemd can do in managing services, but it does not branch out into other areas. Its commands are even similar. Which is the better choice?
There is one Linux (Gentoo) where you can install with or without
systemd, simply be setting a USE flag. If you set -systemd use flag , you get OpenRC. I had no problem in Gentoo , removing OpenRC and installing Dinit. I dont seem to encounter packages that must have systemd, but maybe I am not a big package user.
Dont go backwards to that , it is older than systemd. When you do try, consider dinit or S6
If you want to experience modern init systems, try antiX26.
hatās a really fair pointā10,000 lines of focused service management versus 1.4 million lines of systemd sprawl is a massive difference in maintainability.
Iām constantly reading up on and studying how different distributions handle this under the hood. Most of the deep systemd entanglement shows up in desktop session management (logind), which is what we hit earlier with COSMIC. Once the next version of COSMIC drops, Iāll definitely test a build with dinit (alongside seatd ) to see how cleanly it handles the session layer on top of our immutable layout. Thanks for the tip on antiX26 too!
antiX handles it by using turnstile instead of logind.
Artix stays with elogind
Both antiX and Artix handle the init service config for packages by having an extra package that does the init system config ā¦ eg there are packages sshd and dinit-service-sshd and 66-service-sshd and runit-service-sshd.
You install the base sshd package plus the package for whatever init system you are running.
dinit has the easiest service config filesā¦ they are not scripts like old sysvinit or runitā¦ they are just simple variable settings like most Unix config files.
