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."
I really dislike systemd. It ruined my Debian installation. But I'm also really displeased with the Devuan project, too. I followed it briefly when it first started up, and I think it was a fucking joke. The smugness of the people involved was terrible. The first months of the project were constant accusations of people being "systemd trolls". I found everything about it to be shameful and amateurish. And it became clear pretty quickly that it wasn't going anywhere. So instead of waiting for it, I moved to FreeBSD. And you know what? I couldn't be happier! It brought me the best parts of the traditional Debian experience: stability, reliability, trustworthiness, and robustness. But it also didn't subject me to systemd. The more I use FreeBSD the more I regret not switching sooner. As far as I'm concerned, there's no need for a project like Devuan because FreeBSD is a full, systemd-less replacement for Debian, and Linux in general.
It prevents it. The init part of systemd is just a small part of it. It has started to replace many (and a growing number) of core Linux userspace subsystems. It has gotten to the point where you may not be able to run the desktop environment you want without systemd. The generic, modular bits that systemd has consumed are now components that more and more pieces of software are depending on. In the very near future, it may not be possible to run a modern Linux desktop without systemd.
And, for what benefit? None that I've ever seen. There is nothing that I can now do with my laptop that I couldn't do before. But, there are plenty of things that I can no longer do since the introduction of systemd.
We run SUSE SLES 12 with systemd on our 1020 node Cray XE6 and it works just perfectly. What a joke, "veteran unix administrators", it doesn't get much more complex than a 1020 node, 21,824 processor Cray XE6 with Nvidia Tesla on each compute node. Node management and integration with the job scheduler is significantly simpler than older versions. The older system was a mess of shell scripts, perl scripts, and who knows what else, the new system is all streamlined in a simple config file and few modules.
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.
Here's one of a few discussions
Also google on: systemd degraded btrfs
The hell of it is that once it dropped to the emergency shell, simply entering the needed mount command by hand mounted it right up. Had it been a script based system, I could just stuff the mount command in as an imperitive and moved on to the next issue.
This is interesting. How about issue the mount command? If it is complete enough to succeed then it will succeed. Otherwise it will fail. That was obvious enough that SysV init got it right. Note how "let the admin decide" wasn't apparently even a consideration.
Since that wasn't the only issue, I found a way to mostly defang systemd in Jessie (Debian) so I left it at that. I fave the Devuan beta downloading now. I may very well go that route.
The problem with systemd isn't its replacement for scripts.
Well, kind of it is, since they arrogantly didn't bother to provide any way of getting certain things done that scripts were doing, but that's only where the outrage begins.
The problem with systemd is that it doesn't want to coexist peacefully. It wants to own everything. Not just resource control, but logging and other things as well.
its targeted more at VMs etc that get torn down and restarted many times a day when speed is needed, its just a nice feature for the rest of us which you may or may not see as a benefit.
"The hands that help are better far than lips that pray." - Robert Ingersoll (1833-1899)
So either you get a new hotplug environment within runlevel 5, which then handles all the temporarily running services, or you just accept that the hotplug environment does nothing else than init (starting and stopping services depending on a set of constraints), just in a more flexible and granular manner, and init with runlevels 1, 2, 3 and 5 is just a special case of the hotplug environment, which just duplicates the functionality of the hot plugging environment in a more clumsy and less flexible manner.