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.
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.
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.
...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.
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.
Funny you post that it isn't going anywhere in an article about a significant milestone accomplished.
You know i for one welcome our new systemd overlords. Part of why non-systemd users don't get supported anymore is because there are no non-systemd services anymore with a rich API as systemd. And very often unification is very good.
You know there have been multiple projects for standardisation among linux, and many of them have failed. Most of them just published a standard nothing more. systemd offered an implementation, without a standard, and it was successful, didn't fail.
Oh the problem is there alright.
See here for example: https://www.youtube.com/watch?...
You want to replace sysvinit with something.
Now whether that is upstart, OpenRC, systemd or something else is the question.
systemd's service dependency tree and triggering is definitely attractive, and you can do some cool server configurations with it. For example, assign resources to a service, and that restriction applies to all sub-processes. Or find all processes launched by a service.
NB: The message above might reflect my opinion right now, but not necessarily tomorrow or next year.
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.
I still have no idea why they needed to fork from debian, instead of just maintaining packages/patches required to provide a systemd alternative from within debian.
When choosing a distribution, why anybody choose a distribution whose only clear philosophy was that it is not something else? Unlike debian which is ultimate software freedom and stability or whatever.
SURELY NOT!!!!!
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.
And that is just it: This thing does not exist to solve any exiting problem, it is a power-grab, plain and simple. That is also why it grows though Linux like a cancer and absorbs everything it can, so it cannot easily be ripped out. If it had stuck to being a better init-system, it may have had merit, but this way it is a huge threat to Linux, nothing else.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
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.
initd starts the event manager in that use case.
My ism, it's full of beliefs.