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'm not going to bother saying anything about Lennart or other core systemd developers since it's been widely established that they have proven to be disagreeable on numerous occasions.
What I will say, however, is that after spending the time reading up on systemd and learning how to use it, how to write unit files and all that jazz, I really fail to understand what the furore over it is. My systemd machines are ready to go much faster than any bash-script based init system and writing a new unit file for some daemon that lacks one already is easy peasy.
The only place where I feel it falls somewhat short is in systemd-networkd which currently lacks good support for policy routing. Fortunately, it doesn't bar me from running a post-network-up script to do command-line based route installation, so until it develops that functionality, that's what I'm doing.
Systemd scripts and other init scripts can coexist peacefully in the same package, so I don't see why maintainers can't work together. If there is a willing team of people who want to maintain these scripts I see no reason why the Debian team should stop them.
A beautiful thing about open source is you have the choice to go against the flow. Sometimes it pays off. Often times it doesn't. If someone stops you then fork, but I really don't see what the big deal is. Let's keep our egos in check and hopefully we can see maintainers working together even if they have slightly different methodologies.
Yes, this, uh, adult, reasoned, calmly and rationally stated essay really instills confidence in the maturity and professionalism of the maintainers of this distribution.
(That son, I say that son, is a a a joke son, I say a joke.)
You are not alone. This is not normal. None of this is normal.
I'm in the same boat, and the water is very murky. Every time I see a bunch of technical claims, I see someone claiming the exact opposite point-for-point, and I don't know who to believe.
It is often claimed that it is not so bad for desktop but terrible for servers. I don't know if that is true or not.
One thing that keeps coming up is a philosophical point: "do one thing and do it well", with the implication that systemd takes on many responsibilities that used to be separate tools, for the worse. I don't have a dog in that fight.
There is a perception that it is a "borg" which keeps taking over more functionality and becoming a dependency for so many things that there is no choice but to use it, an example being Gnome. I don't know if this is fair or not.
I will note that maintainers of several unrelated distributions independently chose to adopt it, including Arch Linux. I mention Arch because A) they are famously in favour of a simple base system which you customise the way you want, B) I don't believe have anything to do with Red Hat (where the systemd creators come from), and C) they haven't been forced to switch by e.g. gnome because they don't require gnome or any other desktop.
Comments from an Arch developer on their forum: https://bbs.archlinux.org/viewtopic.php?pid=1149530#p1149530
...my take on systemd is this: As an init system, I actually like it - far better than other SysV replacements, especially SMF on Solaris and friends. Where it goes off the rails, though, is the ever-expanding mission creep into things that really aren't an init system's purview.
If systemd would just be an init system and get out of the way, I'd cheer it on. But one of the first things I do when I set up a CentOS 7 server is to shut off firewalld and use iptables directly. Firewalld is OK on a laptop where you're connecting to a variety of different networks, but leave it off my servers, please.
Oh, no! You have walked into the slavering fangs of a lurking grue!
To me, systemd is a solution looking for a problem. Ego has little to do with it; rather, trying to get shit done is what the issue is all about.
Also, systemd reminds me of the time I got soap suds up my pee-pee hole.
Systemd scripts and other init scripts can coexist peacefully in the same package, so I don't see why maintainers can't work together.
Found the guy that has never dealt with Debian developers.
There is a perception that it is a "borg" which keeps taking over more functionality and becoming a dependency for so many things that there is no choice but to use it, an example being Gnome. I don't know if this is fair or not.
This is effectively the crux of it. Everything else is just a symptom of this. People will make detailed technical analysis of the inner workings of systemd and that's cool and some of them are correct. But, bad technical decisions aren't that big of a deal until they start spreading across the system like a virus. Once systemd has infected everything (and, we are rapidly approaching that), it will be difficult or maybe impossible to cut out that cancer. We are right on the verge of being stuck with systemd and that's a very bad situation to be in.
I will note that maintainers of several unrelated distributions independently chose to adopt it, including Arch Linux. I mention Arch because A) they are famously in favour of a simple base system which you customise the way you want, B) I don't believe have anything to do with Red Hat (where the systemd creators come from), and C) they haven't been forced to switch by e.g. gnome because they don't require gnome or any other desktop.
Comments from an Arch developer on their forum: https://bbs.archlinux.org/view...
This is the second problem with systemd. It has polarized people to such an extent that it resembles a religion or US politics. You must pick a side and you must rabidly defend that side no matter what. To be fair, it's an issue worth having an opinion on but, your opinion definitely doesn't matter. You have distros with very finite resources (like Arch) and distros with effectively unlimited resources (RedHat). The smaller distros kinda have to eat whatever shit sandwich the larger distros serve up because they don't have the resources to do anything else.
There is a very small percentage of cases where systemd cannot make use of the scripts. You could check here to see if any of your problems are listed https://www.freedesktop.org/wi... Logging is one of the fantastic bits about systemd, its far more comprehensive than anything else. Its just a matter of learning about the new features and tools.
"The hands that help are better far than lips that pray." - Robert Ingersoll (1833-1899)
Servers sitting in a light's out facility rarely have things plugged ind unplugged.
The whole controversy could have been avoided if systemd was properly designed as a plug-in component. System starts up under the old init. At some point (after the basic system has been brought up), an rc script or inittab starts systemd (a series of event listeners) to deal with hot-plugging and such. Make sure it doesn't block others from listening.
Poof, no controversy, no objections.
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.
I don't think you have actually studied the design of systemd; it is exactly designed to co-exist peacefully with other components. It is a major reason why it was adopted so successfully and fast:
You can use any syslog daemon like Rsyslog or syslog-ng with systemd's journald.
You can use you own homegrown resource manager using cgroups instead of systemd's. systemd uses cgroups for two things; tracking and grouping services, and resource control. But the latter use is entirely optional and you can compile systemd without such support.
Really, people are so misinformed about systemd. It is like they never even read a systemd man-page, but just uncritically iterate whatever some random blog guy once wrote.