Yes. 1.5, if my mind serves correctly. Later on, LSB tried to do something similar for sysvinit using initscript headers that were interpreted by an external insserv program, but these proved to be far more fragile compared to rcorder(8).
This is a disingenuous presentation, though I would not expect any different from a systemd proponent, or opponent, for that matter. I wrote about the follies of systemd debates here: http://uselessd.darknedgy.net/ProSystemdAntiSystemd/
Whether or not it is easier to maintain cannot really be objectively gauged. As for declarative configuration, I will grant that. systemd is not the first to do this on Linux, though. eINIT was, though it used XML as its configuration language (similar to launchd and SMF in fact, though not as verbose). eINIT also had the benefit of a modular plugin-based architecture, a property also shared by finit and initng.
Change does not imply progress. This should go without saying.
No, a lot of objectors simply come from having different opinions on process management and general software architectures. That said, there is a contingent who did approve of the old approaches, yes. I dislike sysvinit, but I can understand them. Serial execution with a concretely defined boot sequence that is easy to reason about can be a benefit to some. In contrast, the systemd approach eschews any definition of "boot process" or "boot sequence" that can be specifically intervened in by order, instead taking the philosophy that specifying a unit's dependencies and relative order to a target/synchronization point is enough, the rest being handled by internal transaction and job semantics.
systemd most certainly is monolithic. It is also modular, but to a partial extent. System generators and various auxiliaries (journald, but also some of the more minor tooling) cannot be disabled at build time. Certain things like Plymouth communication are also explicitly done at runtime.
launchd as a whole is still a much smaller system than systemd, at the end of the day. This is because launchd has a concretely defined purpose. systemd has little in the way of that other than vague descriptions that ultimately amount to being "as much as possible between the kernel and base libs+utils".
I don't think anyone really considers sysvinit to "follow Unix". In fact, I'd say sysvinit is more of a historical accident than anything. An actual example of a service manager that follows the Unix philosophy would probably be daemontools and its derivatives (s6, perp, nosh, daemontools-encore and runit).
Slackware, Gentoo/Funtoo, CRUX, PCLinuxOS and all its derivatives. Then some more niche ones like Alpine Linux (which also eschews a lot of the GNU base system for alternatives) and Void Linux.
My personal experience is that BSD people by and large care about Linux mostly out of necessity, but nonetheless they're still knowledgeable about both. Mostly they're angry whenever the Linux community feels the need to reinvent yet another square wheel (as was mocked in the OpenBSD 5.2 release song), because it slows them from doing their own innovations and necessitates them to emulate Linux's interfaces.
In contrast, a disturbingly large number of Linux users remain willfully ignorant about other Unices and, worse, they attack them without knowing the first thing about them.
But yes, Linux users are dominant, so more idiots overall.
A lot of people conveniently ignore that the shirt was actually made by a female friend of his named Elly Prizeman. The situation all of a sudden becomes completely different when you factor in that fact.
But then by this logic, OpenBSD should also be a dysfunctional mess. It's not. It has almost the same number of contributors per 6-month release cycle that systemd alone gets in only about 3 months, yet it is a remarkably productive project.
No, I do not think Linus is at fault here. I think a more likely explanation is that (GNU/)Linux is the go to alternative operating system, and it gets a lot of cocky newbies who think they're special for using a Unix-like operating system.
I completely condemn such nonsense as a bunch of vitriolic people driving a distribution maintainer away from their position all because of their indirect affiliation with a controversial project.
Such actions are why I identify with neither the systemd opponents nor the proponents. Unfortunately, it does dilute arguments against systemd, because of immediate associations with fools who attack people and scream fallacies (even though the non-systemd camp is an amorphous blob more than anything). This in turn gives moral high ground to the proponents and any attempt at debate devolves into the same dead ends and non-arguments between equally clueless factions.
Yet as much as the entire display is abominable, it is sadly also completely predictable. For all the good things the systemd crew have done, their ideas are disruptive, in that they're trying to mold a cathedral out of what has been a rather adamantly bazaar-based community for over two decades now. Contrary to popular belief, simply developing your tools in one repository doesn't magically make you "more like the BSDs" - there's far more to the BSDs than that, and every time I see someone make that argument, I twitch.
We're in the midst of an unprecedented schism. But, for what it's worth, this isn't an issue with "open source". No, it's an issue with the Linux community in particular. It is particularly dysfunctional. I have no idea why Linux attracts so much drama and carnage amongst its constituents, but it does.
I'm pretty disappointed in all sides here. The people who attack systemd and its developers on completely false premises, and the people who are convinced it's the be all and the end all, and have been living under a sysvinit-based rock their entire lives. It's just so exhausting. It really is.
I don't know how this will end. But the irony is intense: an attempt at distro unification has led to a big divide. The best thing we can hope for is people doing a bunch of new experimentation in Unix process management. Projects like Epoch and nosh are up and coming. Hopefully we'll see more.
You can run uselessd with or without being PID1. The two modes have different implications, obviously. The latter choice will mean a separation of system manager and service manager. cgroupfs monitoring works properly in both cases.
PID files and SysV initscripts are broken. We're well aware and this has been common knowledge for a long time. What I meant was that you can still get more potential from a dedicated program that tries to focus and solve cases in one specific areas. Making a distinction between the init part and the manager/supervisor part is one of our longer term goals with uselessd, beginning with version 5. It's a trade-off.
We understand what we're doing, and we do not deny the presence of warts. When we announce that we're stable and ready for system integration, then we can really talk. As it stands now, this is all preliminary pondering.
ANTINEWS is the best kind of NEWS. And you don't just lose things, come on. Our recent support for running a system instance of systemd/uselessd without taking over init (as early and rudimentary as it still may be) is a good thing. Cross-libc is another. A couple of things from main.c were refactored into independent tools.
This is still a giant WIP and it's quite experimental. We make this perfectly clear in the wiki that it's not ready for system integration or daily use, and there's still a long way to go (including some more radical ideas) before we ever think of making a stable release.
uselessd is about sticking to processes. Did we not make that clear? If you want a dedicated supervisor, you can use something explicitly designed for such a purpose, like monit or supervisord, instead of using systemd's mixed functionality. Device activation can still be accomplished through (e)udev. We're device node manager-agnostic. We made this clear.
No, you're not screwed. I think you completely ignored the fact that we intend on being portable. This is still early, again, but nonetheless we do compile on FreeBSD and Debian GNU/Hurd and some of the tools (like systemd-delta) actually run properly.
To be honest, we haven't tested the systemd-fsck unit. We mostly removed the binary due to being something that used libudev and looked like it belonged to a shell script more than anything. You can still force fscks through other means (tune2fs for ext2/3/4, etc.) We'll be sorting this out.
It sounds like this project offends your personal ideological sensibilities, as you totally misunderstand its purpose and fail to realize it's a WIP and unstable.
By the way, I liked the jab about choice. I wish we all voted for the same political party, too.
Off the top of my head: __compar_fn_t (just a typedef), strndupa(), parse_printf_format(), canonicalize_file_name(), the GLOB_BRACE flag, implicitly included headers, error.h (also in uClibc)...
The name is perfect and I do not see myself changing it. The fact that so many people misunderstand makes it better. The Linux Action Show thought we were calling systemd "useless" and went on a hilarious rant, there's people on LinuxQuestions.org who really insist that it's pronounced "use less dee" (I call it "uselessdee", as in it's of no use, personally).
"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.
Because they all largely did the same things that sysv did with a few bolt-on features.
That is a total misrepresentation, I'm sorry. The fact is SysV was probably one of the weakest init systems around, besides deliberately minimal ones like busybox-init and sinit.
I devoted the "sysvinit: the eternal red herring" section precisely to debunk that. I just want people to stop comparing everything to SysV, because it only demonstrates that you're unwashed or closed-minded more than anything. The recent parody site forkfedora.org really aggravated me for that same reason. Instead of doing some witty response to the Debian fork stupidity, they just basically posted "LOL look at this SysV initscript, and now this systemd service file. Checkmate, systemd-haters!"
Much to my disappointment, people keep committing the same fallacies even when discussing an article meant to try and silence them at least this one time. I guess it only proves my point, I don't know.
Shell scripting isn't "archaic nonsense" at all, it's just that the warts from how most shells implement their command language (ksh/bash/POSIX sh) are holding us back. If you go look at Plan 9 rc shell scripts, you'll see how much cleaner they are. In addition, the s6 people have done some interesting things with execline (which looks kind of like Tcl), which works as a chain loader instead of holding the shell resident, has a simple parser and is performant: http://skarnet.org/software/execline/
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.
I kind of stitched this essay together haphazardly, and it certainly does require some background knowledge to fully understand.
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.
The writeup was quite nice. I was actually in the process of writing my own notes to respond to Poettering's "The Biggest Myths", but your approach is better. I'll definitely use it as a reference to link to in discussions.
That said, I have a little caveat for #9. Though systemd violating KISS is virtually undeniable, you should reword it so as to point it out on systemd's own merits, not in relation to sysvinit, which systemd explicitly intends to be more complex than.