The bigger side argument about the Unix philosophy is also intriguing. Rob Pike claimed it was dead and Perl delivered the eulogy, which I can half agree with. The problem is shell scripting is archaic nonsense, but our script languages can't do what you can do in shell scripts well enough. The idea of a Unix where you get rid of bash/csh/whatever and just run a lua/python/ruby prompt and have your apps implemented largely in that same language (with shell commands being replaced by functions) may make some people squirm, but would make a lot of sense for reducing the overall learning curve.
The more I realize all the untapped potential lying around, the more I realize how so many Linux users are living in their monoculture. Unfortunately there is no one there to amplify all the good efforts and hidden gems scattered all over the place, so you have people just reading Phoronix and LWN articles and standing in their bubble. Meanwhile, all the non-Linux Unices and the "toy project" builders are doing great things, but everyone thinks they're irrelevant and dying.
This is one of the main reasons I approve of systemd. It is something completely new fighting against the old entrenched cruft. End result might be good, might be bad, but at least it is activity instead of sedateness.
For all bad things that could be said about Poettering, at least he has ideas and the confidence to execute on them.
I used rc as my interactive shell and for very light shell scripting for over 10 years, and I consider it only slight better than the other Unix shells. In fact, the fact that rc's rules for escaping (quoting) characters like hash and space are incompatible with Emacs's shell mode's file-name completion was enough to cancel out any benefit I have derived from the relative "cleanness" of rc.
the (minor) advantages of rc for me: not having to remember the more complex quoting rules of bash, etc. unlike with bash, etc, no part of an rc commandline is ever interpreted twice except for when the double-interpretation is caused by an explicit use of the "backquote" (eval and substitute) operator.
I know this is just my subjective opinion, but I find Unix shells, including rc, inferior to almost any other programming language.
I always got a little sad when I needed to write anything requiring an if statement or anything but the simplest loop in rc (or any other Unix shell). I have come to realize that I would much, much rather write such things in Emacs Lisp -- and have transitioned to doing so. (The start-up time of Emacs --batch is fast enough on modern hardware not to be an impediment.)
+1 for the bash comments
+1 for the toy projects
Anyone remember how Linux got started?
I think what burns a lot of us anti systemd people is the apparently lack of sound engineering principles and overengineering. It's just a damn init system! Other init systems (runit, etc) had already mostly solved many of the problems systemd claims to solve with dramatically less code leaving things like logging, scheduled jobs, etc to tools that absolutely didn't need replacing.
[1] http://dl.acm.org/authorize?N80603 [2] http://2014.splashcon.org/track/dls14-papers#Proceedings
I side with the liberals here, but with a few caveats. I'm not a huge fan of systemd, though I agree that it'll probably get fixed and so far it seems better than the hairy old SysV-init mess.
The debate is doing more harm than even a slightly broken systemd would do-- Linux is already far too fragmented to no benefit. I'm all for freedom but I don't like pointless forks that add nothing.
― G.K. Chesterton
Maybe those forks don't add nothing for you, but for me they're beneficial, because I think Darwinian evolution also applies to software.
The unix paradigm doesn't exist under linux. It was dead before linux got started (the kernel, in the early 90s).
systemd doesn't help with that AT ALL. Other init systems do support this notion much better.
There are other options, but systemd seems to have caught on as the popular option for a replacement. The issue that most people take with systemd is that it does much more than replace init. It replaces cron, has a login management hooks, has it's own network daemon, replaces the system logging facilities and more. It's a serious complex system.
The issue some take with systemd has a few facets:
1) Some feel that systemd's approach to managing everything goes against Unix's core principles where services and applications are supposed to be small, self contained entities that work in unison to form a cohesive system.
2) It can be daunting task to switch over to systemd as you have to relearn many traditional unix tools that most take for granted (remote logging for example).
3) Security minded people are concerned that a single service is touching so many parts of the core system all at once. There have been many complaints levied that such a large change introduces too much risk into the ecosystem all at once.
4) Some have accused the dev team of having a "not invented here" problem. I've seen it asked many times why they really needed to replace cron or logging.
The pro-systemd stance is that they are simply cleaning up many of the antiquated systems. Cron, logging, and init definitely all needed an overhaul. Linux never had a good network daemon and there are good reasons for the other things they are doing. The systemd team sees systemd as not just an init system but basically the system manager. So, by that view, this all makes sense.
Ultimately, it's a fundamental difference of opinion about what services in general should or should not look like on a unix/linux system.
To make a stupid car analogy, it feels like having someone redesign your car's ignition switch and suddenly finding out that he also had strong opinions on the stereo UI so he made the changes together (and dependent on one another), and you're an idiot if you don't like it.
A lot of people complain about systemd missing the "unix philosophy" and that gets derailed on specifics of what people think that philosophy means ("everything is a file" or "do one thing only and do it well" and "be modular") but one significant difference to me between unix systems and Windows or OSX is that unix is built of simple components whose scope is very limited. It's related to do-one-thing and modularity but it's not exactly the same thing. Systemd is not simple or limited in scope.
The problem motivating a switch is that init is an underpowered solution for the number of things that a distribution is asked to handle these days; it results in a lot of hand-tuned scripts with duplicated effort.
Enter the politics. A lot of the value of a distribution can come down to how its init system has been built, since it means the difference between essential stuff working or not working. Systemd pushes the value and the accountability into a central location by annexing lots of different features that were traditionally just spread out amongst various interdependent scripts. There are a lot of straightforward technical advantages to centralizing some of these things(speed, simplicity of configuration, etc.), but everyone and their dog has an opinion about which things should or shouldn't be annexed, and the form in which it should be done. Many people's jobs are potentially at stake here.
The more conspiracy-minded also view systemd as a power grab from Red Hat. Red Hat's business substantially involves contracts with the military, lending circumstantial evidence to the idea that they are doing deliberate harm to serve state interests - thus everything they do is viewed with some suspicion.
Upstart was developed by Ubuntu, which has stopped supporting it and is adopting systemd because they recognized the need to standardize on a single system. After the Debian committee voted to go with systemd, Ubuntu (being a Debian derivative) followed suit.[1]
OpenRC isn't really a replacement for sysvinit; rather it bolts on some functionality on top of sysvinit. My understanding is that OpenRC is not an incredibly mature codebase and would have needed a lot of work to come up to feature/stability parity with systemd. Because it doesn't fully replace sysvinit, it also doesn't solve all of the same problems as systemd.
It's not the goal of OpenRC to be a systemd replacement either. In fact, I don't think it's the goal of any init system to be a systemd replacement, except for uselessd (please correct me if I'm wrong).
OpenRC solves some of the bigger problems that systemd solves--namely, reliable process tracking, cleaner init scripts, user-defined targets, parallel service startup/shutdown, etc. Moreover, most of the above features are optional, and the system exposes most of its runtime state through the filesystem instead of DBus (so you can inspect it however you want with whatever tools you want). As an added bonus, it's portable.
It's really a pity that the Debian TC didn't look at it closely back during the init system vote, but to be fair, OpenRC's Debian integration was a work-in-progress at the time (I'm pleased to say it runs without problems on my Debian subnotebook).
There's also outliers like nosh[0], which implements at least some of the good bits of systemd (socket activation is in there), and the ideas and general architecture are solid enough that it could be extended to implement more (device/path dependencies through udev and inotify are two that I hear people wanting). Then separate pieces of software can implement the remainder of what systemd implements (its many dbus APIs).
[0] http://homepage.ntlworld.com/jonathan.deboynepollard/Softwar...
The problem is that systemd is that is being forcefully pushed to all distros. For instance, by merging udev with systemd. We want to keep all the alternatives open.
Look at the source and you understand the whole system within a minute. All of it.
No really. Systemd now includes a caching DNS server and DHCP. Another alternative is ntpd. No really. Systemd now includes a time daemon.
Being intellectually lazy I like to think of the alternatives as "choice" and "linux".
The big features sysvinit are missing require user space applications to be able to interact with [generic launch system]. Those applications must use some sort of standard taxonomy and flow control. As applications are ported to [generic launch system], they cease working on sysvinit systems because sysv either doesn't support those features or supports them in a different manner.
Sysvinit doesn't really do all that much, to be honest. So it's really easy for [generic init system] to emulate most of its functionality. [generic init system] does a lot more, so it's harder to copy. Even more, if you were to "clone" [generic init system], applications make big assumptions as to how [generic init system] functions, so your [generic init system] replacement would need to function nearly identically to [generic init system].
Basically, someone made a call and said "this is how a modern init system should function". There is a vocal group of people who disagree with that definition. But no matter what the definition is, people would disagree because different people have different ideas about what Linux is/should be. You would see the same problem if a sysvinit derivative was the leading candidate instead of systemd.
I'm not on either side, but I appreciate the way some complexity is dealt with simple little things. So elegantly solving problems: https://www.youtube.com/watch?v=S0mviKhVmBI#t=450
It misses one huge thing: Consistency.
The elephant in the room is that most people who dislike systemd simply dislike it because they learned and used init.d scripts, runlevels, and chkconfig, and that is the extent of their understanding.
The main hatred for systemd is coming from people simply being resistant to change. If it ain't broke, don't fix it.
I like systemd for it's technical merits. I personally would prefer to use a distribution like CentOS in a mode where there is no systemd, simply because I like simplicity and systemd is more confusing to me.
What I foresee happening: people who don't like systemd are going to go try other distributions that don't use it, and may abandon the ones that do because it is too much trouble to run them without it.
The statement that it will lead to divide between graphical linux users and minimalists is likely very true. Runlevels may be simplistic and outdated, but they are easy to remember.
--------------------------------
"The rather huge scope and opinionated nature of systemd leads to people yearning for the days of sysvinit. A lot of this is ignorance about good design principles, but a good part may also be motivated from an inability to properly convey desires of simple and transparent systems. In this way, proponents and opponents get caught in feedback loops of incessantly going nowhere with flame wars over one initd implementation (that happened to be dominant), completely ignoring all the previous research on improving init, as it all gets left to bite the dust. Even further, most people fail to differentiate init from rc scripts, and sort of hold sysvinit to be equivalent to the shoddy initscripts that distros have written, and all the hacks they bolted on top like LSB headers and startpar(2). This is a huge misunderstanding that leads to a lot of wasted energy."
-------------------------------
This isn't about people "hating change". It looks like it, because a lot of people who defend sysvinit aren't really doing that as much as they are defending minimal and transparent systems. In fact, there's way too many people who don't understand "init". Init is the first userspace process that is started. That's it. Init doesn't mean "manages services", "manages processes" or anything like that. Those are separate concepts. The sooner we realize this, the sooner we can have some more innovative architectures for managing services, as we're still trapped in this mental cage.
Moreover, it's not just systemd haters who are resistant to change. A lot of systemd lovers are, as well. In fact, the reason we didn't fix the problem earlier and stuck with SysV for so long was precisely because people didn't care about init, and didn't want to change their flawed ways. Well, at least in the Linux communities. Many of the people who resisted change when presented with non-SysV approaches back in the day are the same who now support systemd and lament on how much "systemd haters don't like change".
systemd, of course, went significantly beyond service management, and thus had a much bigger impact than previous designs which were rather focused on one problem domain. Thus, systemd simply became far more prominent (and controversial) than anything else because of its huge ambitions.
From the perspective of the average linux user ( one that knows little to nothing about linux internals ) the entire discussion is the real waste of energy.
The people who know a ton are a different category altogether; you have addressed those.
The category of people you are ignoring is those who did it one way now they are suddenly "forced" to change.
I feel the same way about firewalld as I do about systemd. Iptables was confusing, but I used it till I was able to do what I needed. Now all of that knowledge is useless because I have to use a different system to stay with the rest of the group.
Is systemd better? Sure. Is firewalld better? Dunno; I think so. Am I ignorant and clueless and misunderstanding everything? No... I just have a different perspective than all of the people fighting about this. All I want is to continue my simple life. Learning new stuff is a drag if it worked fine before. ( I'm aware of how sucky 'fine' is... )
This is not an argument; it's just a statement of how I and a lot of people feel. We used to have a normal car; now the steering wheel is gone and replaced by a grid of 20 buttons that control an automated robot who steers for us. We were used to the wheel. We ask for the wheel back and we are told we are clueless and ignorant and should use the buttons.
While there are people who most likely dislike systemd because they are resistant to change, they don't constitute everyone with objections. I for one dislike systemd, not because I am resistant to change, but on a purely technical basis (which I won't discuss as it has already been reiterated ad nauseam).
I must also add that I dislike sysv and like that the community is discussing alternatives; but the race to systemd, with some serious technical failings which have not been addressed, scares me.
I don't have to rely on 'many eyes' to tell me what's going on with init scripts, I can just look. systemd is sprawling, has no particular philosophy that I can notice, and all of its internal systems are heavily interconnected; this leads me to expect that very few people will be auditing the code that don't work for redhat, because very few will understand it. I expect it to increase the vulnerability of the entire system to accidental or intentionally inserted bugs by an order of magnitude. Therefore, I'd like to see it in the wild for 5 or so years before personally using it - but it looks as if to continue using many linux applications I have to switch to it while it is being written.
I don't get the point (other than cgroups and boot times), I don't get the hurry, and I don't get the animosity to alternate and legacy init systems, and to alternate Unices.
I realize that I could probably find out "bad things about HAL" via internet searching, but it would be more interesting to see the author's take on the issues in the context of the article.
Nonetheless, "the udev debacle" refers to systemd merging udev into its codebase, along with tying it to systemd's shared files, the recent "debug" parameter fiasco and the rather blunt statement by Lennart concerning migrating the transport to kdbus: http://lists.freedesktop.org/archives/systemd-devel/2014-May...
PulseAudio (originally PolypAudio) is a networked sound server most often used in Linux systems coming with a variety of centralized features (see here: http://www.freedesktop.org/wiki/Software/PulseAudio/About/), which proved to be highly controversial initially and less so to this day. People realized it was buggy and unstable, and different factors were blamed: poor integration, sloppy ALSA drivers, or PulseAudio itself. The most common narrative these days is "PulseAudio was bad because Ubuntu rushed it", but I haven't studied things in enough detail to pinpoint exact reasons.
As for HALd, it did solve problems at the time, but I'll quote the Ubuntu wiki: https://wiki.ubuntu.com/Halsectomy
So that really worried me when I found out Arch linux was switching to systemd! Thankfully it's all been ok as far as I can tell. Had to learn a few new commands and that's about it. Maybe it's different for the people actually configuring daemons, but as far as the end user goes, I haven't noticed any problems.
> The fallacies that systemd opponents make have been pointed out so many times that it’s not worth giving a comprehensive overview.
Great, now I have homework to do before I can read your article. I guess I'm just not in the target audience for this article because I haven't been following the debate from the start.
[1] AFAIK 90% of Red Hat's revenue is from servers, not desktops.
just a correction, red hat revenue is from support contracts.
> If systemd is bad for servers, why did RHEL[1] and CoreOS adopt it? Are we to believe that these companies work against themselves?
I know of two theories:
1) making systemd a dependency for gnome and the rest, red hat is trying to exterminate *bsd, which is considered better for servers.
2) "Software that ain't broken doesn't sell $$$upport. "
edit: both redhat and CoreOS have email addresses, as far as I know.
Then suddenly init.d will look very open and friendly again.
Maybe the same thing can happen to grub2 and I wouldn't mind going back to good old grub.conf
Having used systemd on a few machines by now, I won't ever go back. It's utterly naive to think that systemd would go away if Lennart were to.
1: https://github.com/systemd/systemd/graphs/contributors?from=...
There might be more current issues, but I believe it's good enough. For example, BSD init doesn't have super web scale auto restarting and monitoring and log routing. Well... it doesn't need to. Just use it to launch supervisord or something. Also, it's not super fast because it uses the shell. Again, it doesn't need to be. It's fast enough for general purpose servers and desktops. For special cases like containers and whatnot you need special tools.
I think a lot of the rage and loathing regarding systemd is due to its coupling to the rest of the OS. I think a lot of !systemd users were quiet on this initially (and today even) since it's not hard to avoid systemd if you're not running a full-fledged desktop environment. I think it's the fear that this will change in the near-future that has prompted the backlash we're seeing now.
I hope that Debian's new init system coupling GR will address this, both for itself and for its derivative distros. If the rest of the OS does not care about whether or not it's systemd managing the daemons or something else, then everyone wins.
same thing all over again :-P
