Slashdot Mirror
Debate Over Systemd Exposes the Two Factions Tugging At Modern-day Linux
walterbyrd (182728) sends this article about systemd from Paul Venezia, who writes:
In discussions around the Web in the past few months, I've seen an overwhelming level of support of systemd from Linux users who run Linux on their laptops and maybe a VPS or home server. I've also seen a large backlash against systemd from Linux system administrators who are responsible for dozens, hundreds, or thousands of Linux servers, physical and virtual. ... The release of RHEL 7 has brought the reality of systemd to a significant number of admins whose mantra is stability over all else and who perhaps had not waded into the choppier waters of Fedora or Debian unstable to work with systemd before it arrived in RHEL.
IMO, administrators' backlash against systemd is just plain wrong. It enables some seriously cool administrative features, a lot of which are very much utilized by CoreOS to make setting up and managing a cluster of servers a breeze. Is creating unit files really so difficult? The syntax is not exactly complex. As for stability... I have never, not once, had a systemd related crash or anything of the sort. Some distros do particularly suck at packaging systemd, however (I'm looking at you, Gentoo). Give it a try, preferably on something like Arch. If you still have complaints... well, stick to slackware, I guess?
I've seen an overwhelming level of support of systemd from Linux users who run Linux on their laptops and maybe a VPS or home server
I haven't seen an overwhelming support anywhere. Most people who run Linux on their laptops say, "meh, as long as it boots."
This article is a LOT better than the previous one by the same author. He makes his point clearly, that he doesn't like SystemD, as a sysadmin he doesn't want binary log files etc; but if someone else feels like they need systemD, maybe there should be a fork to make place for those people. It's a fairly kind, open attitude. Maybe we should have more of that around here.
"First they came for the slanderers and i said nothing."
Who controls the system, the system administrator or software developers?
How many packages come with init scripts that actually work?
How many packages have dependencies that aren't documented?
How many packages work only on a narrow subset of environments that are tested by the developers?
The answer, of course, is "all of them."
Today, the competent administrator can control startup, dependencies, etc on a granular basis. With systemd, that control has gone - somewhere else.
Who gets called when stuff fucks up because some bozo fucked up their package's systemd configuration? It won't be the package developer, that's for sure.
I use LMDE on three laptops. I don't support systemd. Ignoring the technical arguments, it's been forced down people throats and that alone should be enough for people to step back and halt it's adoption.
That aside, will people please stop this constant masturbation about startup times? There are way, way, way more important things to deal with than edging out a few more seconds. Systemd provides me with no perceivable gains. I don't sit down, press the power button, then stare at the screen until I can log-in, then wait again for the desktop to load. I press the power button, plug-in the laptop, take out my mouse, manager whatever papers I'm going to use, etc... and then log-in. When I had a desktop, I almost never rebooted it. Startup times matters even less on desktops.
However, systemd does provide me perceivable losses. Time spent arguing over systemd could have been spent making everything else better. Systemd removes options, that while I'm not doing anything with at the moment, I like the ability to choose in the future. There are way too many instances of previously good companies/projects suddenly fucking over it's users (of which systemd is becoming an example of in and of itself). I prefer not being locked into something. Systemd didn't present itself as an option, it demanded that it be a requirement.
Personally, I find it crazy that Microsoft and other large software companies are doing more to support scripting while somehow the linux community is being dragged into less and less scripting. (article mentions desktop users don't want to know how to script anything). We need more scripting not less. I'd love to be able to pull out the couple commands I use that are buried in menus and place them as buttons on the menu bar. I don't want an AI to do it for me, I want to take my common commands and make them easier to navigate to and execute or completely automate them.
systemd breaks not only the Unix philosophy, it breaks systems. For years I used SysVinit and had zero problems. Since switching to systemd I've had three breakages, and lost dozens of hours fixing them. I could not care less if the machine takes ten minutes or even one hour to boot, but I do care if it wastes my time.
These distros fight for your freedom: Slackware, Gentoo, Funtoo and CRUX.
Stay away from Poettering-infected distros. This includes previously good distros like Debian and Archlinux.
Or we have learned that you can't argue with Red Hat. As a company we have decided against upgrading to RHEL 7 because of systemd, and likely will be migrating to FreeBSD when it is no longer supported.
I'm waiting for our research team to get bored and start finding holes in systemd
I'm starting to think GNU is the problem with "GNU/Linux" these days.
As for the unix philosophy, init systems pre-systemd hardly did just one thing and hardly did it well.
Every time I see stuff like this I simply laugh. Having worked with *nix for over 30 years I have never had init "not work well" or "not work" as people try and claim. This is 30 years, with at least 8 brands of *nix, and more servers than I can count any longer (ranging from 1CPU to 128CPU E10K/F15K, so my opinion is not based on limited experience).
Systemd is not going to be any better, than Sun's SMF. SMF added nothing over init, except for some sales guy got to tell everyone how great it was. Maybe systemd is going to be worse though... at least SMF was script hackable as long as you could parse and edit XML, and that is not really possible with systemd (last I checked). And in that net zero gain, what did all of the Sun customers get? Lots and lots of costs to develop new scripts and new monitoring tools because SMF was different (not because monitoring was broken). Meanwhile anything that was important stayed out of SMF and went to legacy mode "init" scripts anyway since we could be extremely granular and detailed in a startup
-The wise argue that there are few absolutes, the fool argues that there are no probabilities.
I have similar length and breadth of experience of Unix systems and to be fair, I have seen init break but only once and it was when I broke it myself. I forgot to put an & and the end of a "sleep 20000 /dev/tty10" while trying to keep a serial line to a printer working properly. Next re-boot hung the machine but I was able to guess what the problem was.
When I first saw SMF break I had absolutely no clue why I couldnt ssh into the machine nor where to start looking. It was when I discovered that sshd startup was dependent on utmp being available which depended on filesystem mounting being successful that I knew for sure that systemd style init was nothing I wanted.
For me, scanning through /etc/inittab and being able to see exactly what is going on in the initialisation stage is the essence of Unix. Even this is sadly being slowly broken even before the utterly pointless systemd was born.
As I've said on many occasions, I've had race conditions completely stop boot scripts in their tracks before (pre-upstart RHEL). Any talk of a binary log is a red herring, plain and simple.
Saying, on many occasions, that you cannot manage and modify your startup scripts by hand for boot problem prevention, hardly qualify you as an adviser on system management issues.
Actually, most of the new sysadmins who join my team do not get taught by crusty old sysadmins but learn by themselves. Every single one of them chooses to use a init script to start something up when given the choice though.
And, why would I need a portable init script for forking a daemon with or without a limited capability set and why would I want to do it in five lines when I can do it with one that everybody can clearly understand in /etc/inittab?
I have no problem with control groups. They provide features that have been more or less provided for in several different ways before and are a handy feature but killing daemons reliably has not been a problem for the forty or so years before cgroups came along.
You seem to believe these crusty old unix admins with years of experience have nothing to teach you so Im gad you dont work on critical systems but I urge you to re-consider your outlook. It will save you a lot of trouble in all aspects of your life.
Regards
Persistent arent you.
You are correct that the /etc/inittab has no notion of dependencies but you do and thats the key.
I can certainly see that whole S021startsomething.sh is a bit of an ugly hack but its a workable hack. If the dependency thing is such a problem for you why not have a simple dependency file that something reads and describes dependencies and perhaps what to do when dependencies are not met. You can easily implement something like that with the current model. Cant see why you need to over engineer a behemoth just to solve that? Personally Ive never broken a system because a service started when a dependency had failed but I have found myself unable to log in to a Solaris box because one filesystem didnt mount.
I have never seen gigabytes of logs filled with output of failing daemons and have never missed crucial logs in a start up session. If you have then perhaps you need to review your own policies.
Why are binary log files such a big issue? First, Linux already is using binary log files in wtmp, secondly, you can still use text log files in systemd, and third, you can see binary log files just as well as text files. Because there is actually no difference between binary files and text files.
https://wiki.archlinux.org/ind...
# journalctl -b | grep NetworkManager
http://www.mueller-public.de - My site http://www.anr-institute.com/ - Advanced Natural Research Institute
If it were simply a case of being a DEFAULT experience, there wouldn't be all this hue and cry. Systemd insists on being the ONLY experience, indeed, the ONLY way of *thinking* about init. Its tendrils are *everywhere*, and spreading every day. And as for applications, the NOTION that an application has a dependency on which init system is running is enough to have Dennis Ritchie (and most admins) spinning. The 'two factions' argument comes down to laptop users saying "faster boot times!" and server admins saying "who cares?". As for VPSs, (or daemons, for that matter) how often do you start/stop them that faster boot times becomes an issue?
The argument goes both ways.
New is not always better does not imply that old is not always better either. There have been some amazing examples of throwing away the old and replacing with new to large improvement (just think of the change in network stack between the older Windows kernels and Windows 7, or the change in driver design). A new implementation of the same system is not likely to be bug free first go, but it has every chance of being good, and can quickly grow to become a nice stable foundation.
While this is all great it really has nothing to do with the topic here. Systemd is not a re-write of anything. It's a fundamental change in the operating philosophy of the OS. The "old" folk are being ignored because systemd has nothing in the unix world to which it can be compared, and that raises a never ending triad of ignorant posts claiming it is an init system which does too much.
But worst of all the criticism is not at all constructive, it isn't at all pointing out bugs or complaining about re-writing working functionality. From what I've seen it seems to be entirely a case of "it's different and so it must be bad", and THAT is what gets people labelled as luddites.