SoylentNews is people
SoylentNews is powered by your submissions, so send in your scoop. Only 17 submissions in the queue.
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.
The last time I saw him he was walking down Lover's Lane holding his own hand.
-- Fred Allen
(Score: 2, Interesting) by Anonymous Coward on Saturday December 03 2016, @11:57PM
Actually systemd does allow other init systems just fine. Even a lot of the stuff in the systemd repository will run fine without systemd being PID1! See syatemd-udev, which is actually used in devuan.
But systemd-init offers a service by managing cgroups and other unrelated software depends on that service being available. That is what makes it hard to switch to another init system. Those dependency is what makes it hard to use anything but systemd.
Devuan's solution to those dependencies is to just remove that code enrirely, mostly without even bothering to put in the code that the systemd-implementation replaced. That seems rather short-sighted to me: That code was added by developers for a reason (and no, they were not bough by Redhat, there are technical reasons for those dependencies), so just removing it without bothering to understand what that code does is dangerous.
E.g. running xorg in devuan less secure than elsewhere: Logind (which is one of the big things depending on the cgroups management service of systemd-pid1 can actually revoke access to the devices it hands out. So logind can enforce that e.g. xorg can not read keyboard input while you log into a virtual console as root. Devuan needs to hope that the x-server will play nice... that was good enough for decades, true, but going back behind what is the standard today wrt. security is something that needs to be discussed and documented so that users can make informed decisions based on their use-cases. I would currently recommend to stay away from Devuan on multi-user systems, but it probably is fine for single user machines (as long as you stay away from their horribly insecure custom network manager:-).
(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.
(Score: 0) by Anonymous Coward on Sunday December 04 2016, @09:35AM
Xorg requires +s/suid on systems where either init is used or the systemd configuration is broken (mine is the latter, since it was an older system upgraded from init, apparently without distro provisions to handle that migration outside of an upgrade cd/program instead of a package manager.)
The infuriating part about it is that X doesn't have error messages which make it clear what the failure is when the Display Manager triggers the user change and attempts to log in. I finally after a few hours found a forum post mentioning the error being the permissions shortcomings of X when run without suid or logind. Upon setuid, X login worked as expected.
Much like my complaint about Linus elsewhere, the X.org guys have been phoning it in for years on the features they should fix in X, similiar to issues with the kernel and the missing features in sysvinit/alternatives compared to systemd. And *NONE* of these groups of developers are bothering to make clear and concise new documention covering the features, errata, and known gotchas of interaction with common applications that would help reduce debugging burden due to insufficient error messages, common configuration issues. :(
(Score: 2) by butthurt on Sunday December 04 2016, @08:43PM
"The wrapper is loosely modelled after the existing Debian Xwrapper," says the Xorg commit log.
https://github.com/mirror/xserver/commit/e7b84ca46944895971a8f048c7e34869b7de01c0 [github.com]
Running a non-suid X server was not just possible, but was the default, with XFreee86 in 1999:
https://groups.google.com/forum/?_escaped_fragment_=topic/comp.windows.x.i386unix/7QOVG3xanSM#!topic/comp.windows.x.i386unix/7QOVG3xanSM [google.com]
From a better-formatted copy of the same text:
Q.E14- What is Xwrapper and why can't startx or xinit find it?
The XFree86 X servers require root privileges to access the video hardware. In releases prior to 3.3.2 the X servers were installed set-uid root so that normal users could run them with the required privileges. This is a potential security problem, especially given how large and complex the X servers are. One class of such security problems is exploiting the set-uid program with carefully crafted user-supplied data (either on the command line or in the environment). Starting with the 3.3.2 release the XFree86 X servers are installed without the set-uid bit set, and a small wrapper program ``Xwrapper'' which is installed set-uid root is used to start the X server after checking the command line and environment. This does not provide a 100% guarantee that the X servers are not vulnerable to such exploits, but it does reduce the chances of such exploits succeeding. Also, if vulnerabilities are found in the future that the current Xwrapper doesn't catch, we can easily supply an updated version. It is much easier to do that than to provide updated versions of all the X server binaries.
The xinit command (which startx runs) provided with XFree86 3.3.2 and later has been modified to look for an X server called ``Xwrapper'' instead of ``X''. If you don't have Xwrapper installed, you will get an error message from xinit/startx when it tries to start the non-set-uid X server without using the wrapper. The same thing will happen if you do have Xwrapper installed but you have an xserverrc file (usually $HOME/.xserverrc, but it can be any file pointed to by your XSERVERRC environment variable) that references ``X'' instead of ``Xwrapper''. To fix that, edit your xserverrc file and replace ``X'' with ``Xwrapper''. If instead of X you have some other X server name (eg, XF86_SVGA) in your xserverrc file, you will need to create a symbolic link from it to /usr/X11R6/bin/X and replace it with ``Xwrapper'' in your xserverrc file.
We strongly recommend against making the X servers set-uid root because of the potential security implications of doing so. We also recommend running xdm at boot time to handle starting the X server on a multi user system.
-- http://www.fifi.org/doc/xfree86-common/XFree86-FAQ.html#Xwrapper [fifi.org]