Choose Your Side On the Linux Divide 826
snydeq writes The battle over systemd exposes a fundamental gap between the old Unix guard and a new guard of Linux developers and admins, writes Deep End's Paul Venezia. "Last week I posted about the schism brewing over systemd and the curiously fast adoption of this massive change to many Linux distributions. If there's one thing that systemd does extremely well, it is to spark heated discussions that devolve into wild, teeth-gnashing rants from both sides. Clearly, systemd is a polarizing subject. If nothing else, that very fact should give one pause. Fundamental changes in the structure of most Linux distributions should not be met with such fervent opposition. It indicates that no matter how reasonable a change may seem, if enough established and learned folks disagree with the change, then perhaps it bears further inspection before going to production. Clearly, that hasn't happened with systemd."
LOL ... (Score:2, Interesting)
LOL ... Then I choose FreeBSD. :-P
A plague on both their houses (Score:5, Interesting)
Yes, the old SysV init of hordes of scripts running in series was broken - especially for large-scale systems that have to do a lot of things during startup.
But systemd is just plain FUCKED UP. Read the dependencies [debian.org].
Why the fuck does the startup process have to depend on the IPv6 kernel module? The other dependencies are no better.
Re:My opinion on the matter. (Score:4, Interesting)
TL;DR version: You spend around 20 years getting used to the old way of doing it and now you can't stand change.
My story: Been using Linux heavily since 2000. Arch adopted Systemd big-time in 2013 or so. I spent a little while learning the new commands, and now it's just as easy/hard/whatever as the old RC system was. Oh, but my boot times are way shorter than they used to be.
Re:A complex, fragile, unmanageable TURD (Score:4, Interesting)
It actually did need more than just streamlining, e.g. it needed to use multiple processors if available. But systemd seems "a bridge too far". OTOH, I prever grub over either lilo or grub2. Grub gave me enough control and was easy enough to understand for the simple features I wanted to use. Grub2 is inintelligible, and all the readable files say "warning: This file will be automatically overwritten". And lilo didn't give me any control over what what happening.
I'm not deep into systems administration, and I don't want to be. OTOH, I do want to configure my own system to do what *I* want. And what I want is often not what the designers of the software expect, even though it's well within the range of things handled by the software. So I dislike systems that are either too automagic or too inflexible. Systemd is, from all reports, too automagic, and simultaneously too inflexible. So I'm seriously thinking about switching to Gentoo or Slackware. Or even one of the BSDs, though I don't know enough to even guess which one. (I have a desktop orientation, not a server or minimalist orientation, but I need to do some server style jobs. Most Linux systems will handle this easily, but I think that some BSD systmes are too heavily oriented towards server setups.)
Re:I call TROLL ALERT (Score:4, Interesting)
It's true that most distros are committed to using systemd. That doesn't make it a good choice, and it was often a very narrow vote that approved it, because that are lots of things to hate about systemd. Also, a large number of people don't really trust the lead developer. And .... well, there are a large number of things not to like about it.
I'll probably wait to decide that I won't have anything to do with it for awhile, though. Perhaps it won't turn out to be as much of a blivet as it looks like. But in the meantime I'm going to be checking out alternatives. Just in case. If it's as bad as some have reported, I may be switching to some flavor of BSD.
Re:My opinion on the matter. (Score:5, Interesting)
It amuses me greatly that both replies to this post responded as if Bill was talking about "X" the windowing system rather than a placeholder variable.
Should've used $X. ;)
Re:My opinion on the matter. (Score:2, Interesting)
The primary reason everyone is switching to systemd is because it saves the distro and package maintainers a huge pile of time spent integrating packages. Unit files are maintained upstream by the individual projects. "Arch, Debian, Fedora, Mageia, openSUSE, RHEL, Ubuntu and possibly others" can now all use the same unit file published by the upstream project instead of tailoring init scripts.
Re:systemd adds to and supports the old model (Score:4, Interesting)
If by "less technically adept users" you mean ordinary PC users who are being encouraged to adopt the Linux desktop, there is no reason that the init process has to be changed to woo them, because such users won't ever touch the system internals anyway, whether they be sysvinit or systemd.
If by "less technically adept users" you mean people with some command-line skills but who are not yet Unix wizards, well, arguably systemd makes things more difficult for them. One of the biggest reasons systemd adoption has pissed people off is that for the systemd devs, documentation is at best an afterthought. The API has changed significantly over the last couple of years, but most documentation one can find on the internet is now out of date, and it has not been replaced with docs for the current state of systemd. sysvinit, on the other hand, is extremely well documented from a number of sources, and the technology remains accessible to anyone with some bash skills.
Re:My opinion on the matter. (Score:3, Interesting)
You must be really stupid. Otherwise you would be able to use a search-engine and would have found out that there are numerous ways to do so and none of them involve complex software (except the systemd version). Hell, I wrote a python-wrapper in a few hours for that 12 years ago that has since worked flawlessly 24/7.
Re:My opinion on the matter. (Score:5, Interesting)
You got a bunch of "upstarts" who don't know, or don't care, about Linux's roots and want to turn it into something it just never was meant to be
When I was a junior network engineer, I sometimes had to work on (what we now consider ancient) technology such as ATM, Frame Relay and ISDN. I even had my share of IPX/SPX. Back in those days, the experienced network engineers with 20+ years of experience despised Ethernet while complaining about those junior folks who knew nothing about the established technologies. As it turned out, all of them are out of a job now.
Bottom line is, when it comes to technology progress, roots are pretty much irrelevant. I don't care if something has been done like this for 1000 years. If we can find a better way to do it, let's do it.
The question should be whether or not systemd is progress, or an unnecessary burden. History is irrelevant in this case.
Re:Choosing Sides (Score:5, Interesting)
If you want an eye opener take a look at the dependency list for SystemD and those packages that depend on SystemD some time, note how entries appear in both lists, then consider the following questions: Bearing in mind that SystemD is the first thing that is loaded after the Kernel; does that look like a good design to you? Does it explain why so many distros have adopted it, given that many of those dependencies either won't work without SystemD underneath or require a considerable amount of customisation to use any alternative?
Still, there's always BSD.
Re:My opinion on the matter. (Score:2, Interesting)
"What's broken exactly?" - PRECISELY.
The Red Hat 6.5 implementation does not work as documented. Either fix the code, or fix the documentation. I've not tried Red Hat 7 yet, haven't gotten a round tuit. Ever try to take System V init code and convert it to systemd? I even tried to A/B between Red Hat 5 code and Red Hat 6.5, and that didn't show the rules.
Re:My opinion on the matter. (Score:4, Interesting)
What's funny is it actually has the ability, and nobody uses it except for gettys.
This. Actually, in RHEL/CentOS, you can simply run /etc/rc every minute via cron and it'll sync what's running with what's supposed to be, assuming things have been /sbin/service stopped. (And if they haven't been cleanly stopped, you need a specialized tool that understands how to *TEST* the service rather than rely on subsys.)
The init system (Score:5, Interesting)
What's broken is this. The initt system assumes:
1) All the subsystems boot quickly
2) None of them need to communicate back and forth about status in complex ways
3) The list isn't too long
There exists lots of users for which one or more of those 3 assumptions are false. If you don't assume those 3 then you would design boot differently.
What's being done is large Unix distributions are heading the effort that deal with thousands of packages. The risk is being handled by going through package by package by package and resolving any small problems.
The 2nd most used Unix is OSX. That uses launchd. That of course handles the problem of integrating in daemon tools and cron like features into the launch system which is different than either init or systemd. If the goal were better compatibility with other Unixes that not init would be the target.
Anyway the big change is likely to be that more and more linux software is going to assume systemd as hard dependency which means that other Unixes are going to have to switch or at least support systemd if they want to be able to port from Linux.
Re:My opinion on the matter. (Score:5, Interesting)
Are you also using 'cat | grep'?
What's wrong with that?
It is more convenient for me, for example /some/file/somewhere| grep something (hmm, didn't get what I wanted) /some/file/somewhere| grep some (good)
cat
cat
If I do grep something /some/file/somewhere and and to edit my search string, I have to move the cursor further than in the cat|grep version.
Also, I sometimes replace tail with cat when looking at a log file
tail -n 2000 | grep (it wasn't here, let's look at the whole file)
cat | grep (found it)
Re:Display server (Score:4, Interesting)
Re:My opinion on the matter. (Score:5, Interesting)
The new guard in most arenas seem predisposed to think that newer is the same as better. And sometimes that is true. In the case of systemd it's a mix of some new stuff that's good and desirable but inseparable from other parts which are new but not so good. So the conflict seems to be in the push to get the new+good stuff out soon while other people are concerned rightly about all the new+bad stuff being pushed out without any plan or discussion.
Similarly, there's the ubuntu unity style of stuff: a big push by new guard that want tablet/phone presence, and an old guard wondering what corrupted their desktop (you could probably peek inside Microsoft and see the same divide in the Windows 8 debacle). You can see this in the Mozilla Firefox version deathmarch probably.
Ultimately it's the push to get new stuff in as soon as possible that leads to the conflict.
Re:My opinion on the matter. (Score:5, Interesting)
I don't think the seasoned admins will argue that systemd is bad because it doesn't follow history, they'll argue it's bad because it doesn't follow well established design principles.
(I'd also dispute that there really were a large percentage of Network engineeres who really disliked Ethernet. I heard some complaints 20 years ago from people who did real-time process control systems, but that's quite a small nitch.)
I've been doing Linux admin in some fashion or another for 20+ years, so in many ways I'm part of the "old guard". The argument about small being better, making programs that do one thing well, etc is a good design element that's worked for years. At the same time I've also often been bitten by the problem of having to port "yet-another-shell-script-for distributiion-X" problem that seems like it should have a more standardized way of doing things. So from a replacing init-scripts perspective, I can see the appeal.
I'm not heavily involved in administration like I once was, so I don't have experience with systemd as of yet. (My systems run Ubuntu or Debian, no RHEL7). With that said, the monolithic design and trying to do everything sounds like a major design flaw to me.
Re:My opinion on the matter. (Score:5, Interesting)
You know what sucks my ass though? Not being able to modify the init scripts as I need. I'm so glad we've made a daemon that will make sure I never need to alter the low-level starting dynamics of a service again. At least I assume it does that, since it *does* deprive me of my ability to.
Re:My opinion on the matter. (Score:2, Interesting)
But I understand, old sysadmins are used to having One Big Machine where they are kings of the realm, lording their power over mere users. Sorry, granpa but these days are over.
Re:My opinion on the matter. (Score:5, Interesting)
Also, what advantage does X forwarding offer over VNC?
Integration with your existing desktop; the forwarded app works just like an existing app.
It's like you get married and instead of you and your wife moving into the same house you just move your houses together so you have two external windows that are touching and you can look into her house. That's such a stupid analogy but it just occurred to me so of course I have to jot it down here.
Re:My opinion on the matter. (Score:4, Interesting)
Despite what people claim, systemd is a perfect example of one tool does one job and does it well. Systemd is an umbrella project where a collection of tools are developed in the same place, and with the specific aim of making the tools work together in a modular integrated fashion. There is nothing monolithic about systemd and the way it works.
So "systemctl" controls stopping and starting services, "journalctl" filters log files and displays the output via a pager ("less" is standard, but it is easily changed), "hostnamectl" sets and display hostnames etc.
All the tools can be chained together with standard pipes, so they are just like any other Linux tool, though remarkable well made (tiny and fast) and well documented. bash-completion is also well integrated, so "hostnamectl " will show all possible keywords.
Regarding network engineers disliking ethernet; I heard plenty of that in those days. Remember, ATM was once king in telecom, and Token ring in the LAN world. Believe me, at lot of those network guys really looked down on ethernet in the beginning; they saw it as primitive and that it did everything the wrong way. The "happy-go-lucky" ethernet attitude to network collision grated on their nerves.
Re:My opinion on the matter. (Score:5, Interesting)
A "crash" does not involve anyone running "service X stop" so you're providing a solution for a problem nobody wants nor asked about.
And that specialized tool is... wait for it...
THE SERVICE'S OWN INIT SCRIPT!!!
That's right, you can iterate through service "$X" status on everything, and do a restart on anything that has terminated, but that's just a hack, and something that can be done infinitely superior within the software handling the service startup... namely, upstart or systemd.
I hate Lennart Poettering and PulseAudio as much as anybody, but SysVinit is broken, and systemd is a fix. Angry zealots repeatedly denying that there's a problem, is probably why it's taken so very long before a fix finally arrived.
Re:My opinion on the matter. (Score:2, Interesting)
Re:The init system (Score:5, Interesting)
systemd developers explicitly stated that they do not care about other OSes at all. If it is ported, then whoever ports it has to maintain it. Not to mention that they'll either need to port all the Linux-specific OS APIs it depends on, as well (and then maintain them), or else rewrite huge chunks of it. Basically, it's non-portable by design.
This is why the effects of this are so big that they go beyond Linux even. It means that software, in some cases, has to make a choice over whether it wants to support other platforms at all, or at least with reduced functionality. This doesn't bode well for *BSDs.
Re:My opinion on the matter. (Score:5, Interesting)
From every experience I've had with systemd, I'd say that it is NOT progress. I don't want every little thing integrated in the manner systemd does.
Integrated in what way? Sure, they have a bundled suite of applications, but you can swap out journald for syslog just as you can swap out koffice for libreoffice if you run KDE. It has some dependencies like udev and dbus, but that's just a design choice.
And frankly, OpenRC is a lot better.
How do you figure? I've been using OpenRC for more than a decade and there are a LOT of things it doesn't accomplish like: /etc that sets that one setting and systemd merges it in every time.
1. Having upstream-provided service scripts for most packages. Most OpenRC scripts are custom-built by Gentoo maintainers. If a Gentoo maintainer doesn't maintain a script, you will have to write your own.
2. Actually stopping services thoroughly. If a service doesn't clean up children properly. OpenRC doesn't care.
3. Optional auto-restart.
4. Sane network configuration. The networkd configuration is much simpler than oldnet/newnet/whatever.
5. Drop-ins. I like a Gentoo-provided openrc script, but I want to set ionice. That means hacking up the script, and then merging in changes every time it is upgraded. With systemd I just stick a drop-in file into
6. Booting in milliseconds in a container. I'm not sure how well it boots in a container at all, though I know this is being worked on.
7. Clean shutdowns when you're using stuff like lvm/raid/etc. Systemd can drop to dracut and allow the initramfs to do a full clean unmount. Sure, the read-only approach works reasonably well, but it always bothered me seeing OpenRC shut down with in-use messages.
OpenRC is about as good as it gets for a traditional bash-based service management system. I've always been happy to use it. However, unless I'm stuck on BSD or something I doubt I'll be using it much in the future.