SoylentNews is people
SoylentNews
Greybeard-built Debian fork bringing init freedom on track for early 2017 release
The self-proclaimed "Veteran Unix Admins" forking Debian in the name of init freedom have released Beta 2 of their "Devuan" Linux distribution.
Devuan came about after some users felt it had become too desktop-friendly. The change the greybeards objected to most was the decision to replace sysvinit init with systemd, a move felt to betray core Unix principles of user choice and keeping bloat to a bare minimum.
Supporters of init freedom also dispute assertions that systemd is in all ways superior to sysvinit init, arguing that Debian ignored viable alternatives like sinit, openrc, runit, s6 and shepherd. All are therefore included in Devuan.
-- submitted from IRC
This discussion has been archived.
No new comments can be posted.
systemd Free Linux Distro Devuan Releases Second Beta
|
Log In/Create an Account
| Top
| 82 comments
| Search Discussion
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
Confess your sins to the Lord and you will be forgiven;
confess them to man and you will be laughed at.
-- Josh Billings
(Score: 5, Insightful) by coolgopher on Sunday December 04 2016, @01:15AM
The thing is, systemD isn't an init system, despite the frequently repeated statement to that effect. It's a monolithic replacement of everything from init through to just-below-the-desktop-UI. These days I believe it's even more monolithic than Windows, on which AFAIU it was modelled in the first place. It's a my-way-or-the-highway approach, with a large degree of fuck-you-all inserted, and goes against the core principle of Unix design - one tool does one thing, and does it well, and can be substituted as desired. Conceptually, it's going from e.g.
dd if=/dev/sda bs=512 count=2 skip=6 | xxd -g1 | grep 'AA 55' | cut -f2- -d:
to
somemotherfuckerofabinary --mode=readrawsector --sectors=6-7 --match='AA 55' --matchformat=hex --outputformat=hex --outputfields=2-17
and then you discover that there's no option to set the blocksize/sector size and it's hardcoded as 4096, or there's no way to specify the field delimiter for example. You lose a fuckton of power and flexibility down this path, and bugs get harder to deal with since there are no alternatives you can use in the meantime while said bug is getting fixed. From a developer point of view it's hell too, because all of a sudden you have a huge codebase that touches on all aspects of running an OS which you need to get your head around before you can dive in. It goes completely against accepted best practices in terms of architecture and design as well, which is to keep separate concerns, well, separate, and with well defined interfaces between the components. Whether it's classes, modules, libraries or separate binaries, the philosophy is the same.
While initially a monolithic design can be appealing due to the more rapid development cycle (by foregoing having to define the interfaces between components), over time this comes back to bite you. The weight of the design eventually causes the whole thing to collapse in on itself, and forces a complete rewrite of everything. Over my years as a developer, I've seen this happen over and over to this type of application. The ones who had the extra time spent up front to modularise have needed far less maintenance work to evolve to changing requirements.
I believe systemD is the worst enemy the Linux ecosystem has come up against to date, worse than Microsoft and SCO/Novell. That threat was sufficiently external that people bandied together to fight it. This one is more insidious, and has already caused a divide.
(Score: 0, Disagree) by Anonymous Coward on Sunday December 04 2016, @08:17AM
There were few facts in your post and there is no point to argue about personal beliefs.
Systemd is indeed more than an init: It is a project that wants to do the building blocks for an Linux-kernel based OS. There are lots of bits and pieces that can be used separately or together. There is no Linux distribution out there that uses everything and most use at least parts of systemd. Even devuan uses part of systemd! If systemd was as monolithic as you claim then that should not be possible, should it?
It is a layered architecture though: Starting out with the init system, logging and communicationat the base. That is the same design principle that is at work everywhere in Unix by the way.
Having the core system in one repository is another very unix-y thing by the way. The BSDs do exactly that from the very start.
(Score: 4, Informative) by fritsd on Sunday December 04 2016, @03:04PM
That is a bit disingenuous. The current version, Devuan Jessie uses systemd-udev, to stay as close as possible to Debian Jessie.
The reason is that udev, a critical component, has been absorbed by systemd.
For the next version, we're looking at alternatives for systemd-udev, and then Devuan will no longer use anything from systemd.
I'm not 100% sure if the alternative is already stable, because when I last looked half a year ago, there were some issues with the initramfs stage. And initramfs stage is difficult to debug.
I agree with you when you say "If systemd was as monolithic as you claim then that should not be possible, should it?".
With respect to systemd version 215 from 2014, which provides the udev that is still used in Devuan Jessie.
I don't speak for Devuan, but personally I don't trust that systemd udev would stay "buildable" without the rest of systemd in the future.
(Score: 2) by Justin Case on Sunday December 04 2016, @04:33PM
udev, a critical component
Serious question: why is it critical? I'm not sure I want it there at all. It seems to cause trouble, and I'm suspicious of root processes that run forever with no perceived value.
From what I can find without hours of research, it changes /dev entries when hardware is added or removed. Well I certainly don't want to do that! On the rare occasions when I do upgrade my hardware, I'll expect to create the appropriate /dev entry once and not have it shifting under my feet like quicksand.
What am I missing?
Did you mean to say that it is "critical" for unstable hardware configurations?
(Score: 2) by fritsd on Sunday December 04 2016, @05:52PM
Yeah, I think I said it wrong. From a wrong perspective.
udev is not critical, in the sense that your server will boot fine without it, if you have a simple disk layout.
If your root filesystem is an encrypted filesystem on an LVM2 logical volume on a RAID 5 array, then your initramfs has to do a lot of complicated stuff before the final root filesystem is available for booting from.
I think this includes creating new device inodes when they become available (e.g. after mdadm has assembled a RAID array). I don't actually know if it would work to
mount /dev/md0 /
if the kernel would somehow try to assemble the /dev/md0 raid itself from its component partitions' metadata (which are the component partitions??). I haven't studied the code, but I think the mdadm userspace program does that.
Now that I have read "man 4 md" I'm doubting.
For people like me who use Linux as a workstation with a GUI (most of the time), it's nice that you can plug in USB stuff and have it working. That's an important function of udev. And when you plug in a USB device it adds new hardware
(the system couldn't know before what you were going to plug in).
I've had to modify some udev rules to get my mobile phone recognized so that I can access it with adb (Android development) as non-root. So it's a program to regulate user access to hardware.
From my perspective, which is a really odd and uncommon perspective (sorry), udev was "critical" because it was a big log in the systemd "log-jam" [wikipedia.org] of dependencies in the low-level base Debian system.
(Score: 2) by butthurt on Sunday December 04 2016, @10:29PM
If your root filesystem is an encrypted filesystem on an LVM2 logical volume on a RAID 5 array, then your initramfs has to do a lot of complicated stuff before the final root filesystem is available for booting from.
The man page for udev says it's for "dynamic device management." Your example isn't dynamic. The grey-beard way was mknod, perhaps run from a /dev/MAKEDEV script.