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.
Hacking's just another word for nothing left to kludge.
(Score: -1, Redundant) by Anonymous Coward on Saturday December 03 2016, @08:37PM
...so long as it isn't systemd?
(Score: 0) by Anonymous Coward on Saturday December 03 2016, @08:44PM
init-system-helpers [devuan.org]
This package provides helpers for all init systems (except systemd because we've removed that for Devuan, because it doesn't allow other init systems
(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]
(Score: 3, Interesting) by Bot on Saturday December 03 2016, @09:21PM
are you seriously suggesting that the debian fork without systemd should waste development effort readding it?
Account abandoned.
(Score: 2) by fritsd on Saturday December 03 2016, @10:17PM
Well, it was actually suggested by someone on the mailinglist.
But no, it was regarded as "we don't support systemd anymore" ;-)
(Score: 0) by Anonymous Coward on Saturday December 03 2016, @10:30PM
Surely some people want to have the option of using systemd. Packages that support it along with other init systems could--politics permitting--be included in Debian, so they wouldn't have to be maintained separately.
(Score: 1, Informative) by Anonymous Coward on Saturday December 03 2016, @10:33PM
Debian already exist for those people.
(Score: 0) by Anonymous Coward on Sunday December 04 2016, @12:03AM
Really, systemd is optional in Debian? Then there is no reason to have Devuan.
(Score: 2, Disagree) by Aiwendil on Sunday December 04 2016, @09:14AM
It is - just requires that you blacklist systemd (or append "systemd-" to any and all upgrade, install, remove et.c operations) and that will case apt to find alternate solutions.
(Do anyone know if there is a way to make sure apt enforces a certain package is alwsys installed?)
Of course it probably will land you in depenncy hell (in part due to some solutions will prevent systemd-shim [helper to reduce the systemd-mess on systemd-free systems] from being installed, and in part due to some packages requiring systemd without offering alternatives [knowing how to alter and rebuild deb-packages is very helpful])
Heck, the official debian way to run a systemd-free debian [debian.org] is to just install a conflicting init (which will cause apt to kick out systemd and all that depends on it with no other requirement-ruote)
(Score: 4, Interesting) by fritsd on Sunday December 04 2016, @03:13PM
I'm a long-term Debian user.
When I upgraded from Debian Wheezy to Debian Jessie, it installed systemd.
Without asking, without even a mention in debconf, that I can recall.
Then my system was fucked up.
Then it took me more than a week to try to extricate all the packages that depended on packages that depended on packages that suddenly depended on systemd, but never did before.
You are right: it landed me in dependency hell.
Maybe it's me, but I found that it was really *extremely difficult* to remove systemd; even with 20 years experience with Unix, Linux, Debian, even as an amateur dpkg package builder, it was extremely difficult.
Then I became a Devuan volunteer and shared my experiences modifying packages to remove the dependencies! So it all ended OK ;-)
(Score: 2) by Aiwendil on Sunday December 04 2016, @10:46PM
Ahh, I avoided systemd by doing a crapload of apt-get install systemd- foo bar baz (and apt-get --dry-run dist-upgrade to get a list of what was needed) until I got a clean enough apt-get upgrade
(I'm in the habit of doing it that way since I've gotten my system hosed by bad libc [static linked dpkg and lynx are in my toolbox], conflicting perl-packages [always intersting to upgrade perl-base] and gotten gnome accidently installed once (took a while to get my system back to "login at console" after that one) over the years - so I distrust anything I havn't check by checking the output of apt-get --dry-run $command first)
(Score: 1, Informative) by Anonymous Coward on Sunday December 04 2016, @09:41AM
The entire point of devuan was that the leadership of debian voted down attempts to keep systemd optional and provide alternatives to systemd because 'too many other packages rely on it.'
As a result of that schism a number of dissenters were forced out/quit and spun off devuan instead.
Personally I think it was a good thing. Deb+Ian have been dead for years, Ian himself has been dead for a year. The Debian distribution has been dying for a long time, and this is just finally an opportunity to put another nail in its coffin as it slowly fades into irrelevancy (well outside its basis as the foundation of Ubuntu.)
Having said that: Adding support for systemd to devuan shouldn't be too hard. The biggest issue is finding a way to include optional systemd configuration packages for devuan packages that no longer contain them (most distros and a number of source packages install them by default whether you wanted systemd config files or not, cluttering up your filesystem, esp given most of them install to /usr/lib/systemd or elsewhere rather than /etc like config files are supposed to. Xorg isn't helping with that nowadays either, putting its default config files in /usr/lib and having /etc/X11 only being overrides. But then again they think dbus is a spectacularly good idea.
(Score: 0) by Anonymous Coward on Sunday December 04 2016, @10:40AM
As a result of that schism a number of dissenters were forced out/quit and spun off devuan instead.
That is false as none of the people involved in Devuan have been part of the Debian project before.
They are people who haven't worked on a real Linux distribution (i.e. not just a live image) before and are slowly starting to try and figure out how this works. There is a reason they can't do any estimates on how long something would take.
(Score: 2) by fritsd on Sunday December 04 2016, @06:06PM
I was never a DD; don't know about the others. I'm not sure you can generalize.
(Score: 0) by Anonymous Coward on Friday December 09 2016, @09:47AM
I'm not sure you can generalize.
It's a fact that none of the Devuan developers were members of the Debian project.
Unlike your feelings it could be proven wrong (if it were not true).
(Score: 2) by Bot on Monday December 05 2016, @10:45PM
In fact Jaromil worked at dyne:bolic which is a live image.
This is not a matter of experience. Given the real reasons for pushing systemd, I expect that it will be tears and blood for those wanting to remove it, or on the other hand master it, no matter their experience. Systemd is complicated and, according to the creator, always a moving target, Android style. It does not matter if the doors are unlocked if you have to open 343349 of those to go for one room to another.
Account abandoned.
(Score: 2) by hash14 on Saturday December 03 2016, @09:30PM
I'm not sure if systemd can be installed or not, but without a doubt, Devuan comes with a better default init system.
But systemd is all about eliminating choice anyways, so while there's an illusion of choice on Debian and other distros today, they are with no uncertainty marching to a world where that's not the case.
(Score: 0) by Anonymous Coward on Sunday December 04 2016, @08:21AM
Sure. Sysv-init/sysv-rc is a great combo. That is probably why literally every Linux distribution is dumping that for systemd, OpenRC, epoch, and lots of other replacements.
Even in devuan there is lots of talk about replacing sysv-rc eventually.
(Score: 2) by butthurt on Sunday December 04 2016, @08:19PM
According to the Slackware Web site, they haven't dumped sysvinit.
http://www.slackware.com/config/init.php [slackware.com]
(Score: 0) by Anonymous Coward on Saturday December 03 2016, @09:59PM
What about Upstart? Works pretty well in Ubuntu 14.04, although I see Canonical has since moved to systemd.
(Score: 1) by zoward on Saturday December 03 2016, @10:17PM
Ubuntu felt they more or less had to. They're downstream from Debian, and Debian had already decided to go systemd. They felt it would take too much effort to have to maintain the modifications it would take to keep all the downstream applications that had added systemd as a dependency running correctly. I'm looking forward to trying Devuan out on my server.
(Score: 0) by Anonymous Coward on Sunday December 04 2016, @09:31AM
Considering that very a third of the members of the Debian technical committee work on Ubuntu, I dare say that ubuntu had its fair share of influence on Debian's decision.
(Score: 2) by fritsd on Saturday December 03 2016, @10:14PM
Of course you can try to install systemd on your Devuan machine, nobody is stopping you doing whatever on your own machines.
Whether it still works is your problem; you can download and study the systemd source.
If you want to have systemd as init system, please consider Debian instead of Devuan.
Debian is basically Devuan + systemd support ;-)
(Score: 3, Insightful) by MadTinfoilHatter on Sunday December 04 2016, @06:02AM
Debian is basically Devuan + systemd support ;-)
While I realize you're (partially) joking I think there is a need to clarify this issue, which the starter of this thread seems to not have grasped:
With Debian you can pick any init you want, but if you pick anything except systemd, you're relegated to second class citizen status. Some things won't work with non-systemd inits, because everything is built from a systemd-über-alles point of view. With Devuan you can pick any init you want (except of course systemd), and will still be a first class citizen, no matter your choice.
I think Devuan is doing the sane thing. Systemd is basically like a bully in the sandbox, who refuses to play nice with anyone else. The right thing to do is to banish the bully from the sandbox until he learns that if he won't play nice, he won't play at all.
(Score: 0) by Anonymous Coward on Sunday December 04 2016, @08:31AM
Actually with devuan you can install any init system and you get a second rate experience with all of them. Upstream projects do use systemd to improve security, features or convenience and that then gets removed by devuan.
Systemd does play nice with a lot of developers and helps them solve problems in the Linux platform. Yes, it does break stuff in the process. Yes, that is annoying at times. But at least the platform improves that way.
(Score: 2) by canopic jug on Sunday December 04 2016, @11:50AM
Money is not free speech. Elections should not be auctions.
(Score: 0) by Anonymous Coward on Sunday December 04 2016, @01:53AM
Well, it'd be Debian then, wouldn't it?