Slashdot Mirror
Devuan Releases Beta of Systemd-Free 'Debian Fork' Base System (devuan.org)
jaromil writes: Devuan beta is released today, following up the Debian fork declaration and progress made during the past two years. Devuan now provides an alternative upgrade path to Debian, and switching is easy from both Wheezy and Jessie. From The Register: "Devuan came into being after a rebellion by a self-described 'Veteran Unix Admin collective' argued that Debian had betrayed its roots and was becoming too desktop-oriented. The item to which they objected most vigorously was the inclusion of the systemd bootloader. The rebels therefore decided to fork Debian and 'preserve Init freedom.' The group renamed itself and its distribution 'Devuan' and got work, promising a fork that looked, felt, and quacked like Debian in all regards other than imposing systemd as the default Init option."
Seriously, who cares how fast it boots? Unless you're on some tablet type device I see no reason why boot speed should even be a thing. The old initscripts are plenty fast enough for my laptop even.
The issue that I have with Lennarts work is that it goes completely against the design philosophy of *nix that made it so great in the first place. It also broke a bunch of stuff that relied on the old behavior - a big no-no and an instant turn-off.
C|N>K
So you learned to do the easiest part and called good. 'grats. Now, consider my use case. I build a btrfs using RAID1 in a VM. I dettached one of the virtual drives to test things and rebooted the VM. Systemd dumped me to an emergency shell with the network down. Try as I might, even digging through the 100 or more low level config files kept under the rug I could see no way to show systemd the error of it's ways. And yes, I specified mount option degraded on the kernel command line and fstab, but systemd ignored it. All it knew is that it was prepared to wait forever for that no longer connected disk to come online and was not going to be made to see reason.
Naturally, I hit up google. Turns out many people had a similar problem with RAID1 volumes as root. No solution there, even from LP. Furthermore, the devs were stumped as to an approach to fix the problem. They considered it intractable and so WONTFIX. It never did get fixed as far as I can tell. The best solution on offer is to use SCRIPTING in the initfs to mount the RAID volume before systemd gets to run. Yes, SCRIPTING.
THAT is why I object to systemd. It's just too damned easy to find something is simply won't do as soon as you use a system in any manner that LP doesn't. I guess he doesn't do much with servers.
Now, if they would just keep their fingers out of all the pies I wouldn't care. You can use systemd and I'll stick to scripts. Alas, they insist on sticking their fingers in every pie through a pernicious knot of dependencies. For a while it seemed that the stronger the objections, the more things became dependent on it. That's why it took Devuan so long to purge it from Jessie.
Very ugly.