uselessdguy

The speed benefits come at the trade-off of integration complexity potentially diminishing them: http://freedesktop.org/wiki/Software/systemd/Optimizations/

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".

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.

Of course, it's easier to just heap in outrage.

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.

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.

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.

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.

We have notes in our Bitbucket source.

systemd has libqrencode integration, in order to, if I recall correctly, display a QR code when you generate FSS keys from journalctl.

--------------------------------

"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.

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.

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.

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

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.

EDIT: I don't know the motivation for the downvotes. I replied like this because the commenter posted a canned cookie-cutter reply that is addressed in the article as Fallacy #6.1.

Jupiter Broadcasting are an unreliable source, to say the least. I did watch that episode. When you use such pristine arguments as "Someone reimplemented systemd's D-Bus APIs, therefore systemd is portable!" (much like the Windows API is portable, because Wine exists) and claim that systemd is a "manufactured controversy" while responding to easy straw man arguments, there is a term for that kind of person: a shill.

I was also very amused by the Linux Action Show's coverage of uselessd. They spent the entire time whining about the name, thinking it makes fun of the systemd developers, when in fact it's making fun of ourselves. They also got mad over the use of the word "cruft" and later called us "butthurt BSD users".

Good to see that you bring some new insights, however. Very mature and enlightening.

At the moment, yes. We do keep much of the internal systemd architecture in tact, but we do eventually aim on partially decoupling it, or at the very least expanding the breadth of configure prefixes for tuning its behavior. We are a pretty early stage project, after all.

Indeed, the systembsd and systemd-shim projects are working on the D-Bus interface reimplementation part.

Our goal right now is to be a minimal systemd base that can be plugged in interchangeably and have the vast majority of unit options be respected.

There already are systems that offer primitives to reuse systemd units. nosh is one of them, and there also exist scripts that can convert systemd services to SysV initscripts, and even the opposite (dshimv).

Considering GNOME is part of the new school design philosophy in general and largely developed by Red Hat employees, it's inevitable that it would have happened anyway, but the systemd developers were directly complicit in speeding it up.

Keep in mind I'm not advocating a strict separation, it does make sense to intertwine to an extent for practical purposes. I'm mostly trying to say that they're separate stages, and should not be completely equated for each other, lest some undesirable design properties emerge.

Gentoo's eudev is more relevant now than it ever has been before.

The author of this piece makes the classic mistake of equating the init system as the process manager and process supervisor. These are, in fact, all separate stages. The init system runs as PID 1 and strictly speaking, the sole responsibility is to daemonize, reap its children, set the session and process group IDs, and optionally exec the process manager. The process manager then defines a basic framework for stopping, starting, restarting and checking status for services, at a minimum. The process supervisor then applies resource limits (or even has those as separate tools, like perp does with its runtools), process monitoring (whether through ptrace(2), cgroups, PID files, jails or whatnot), autorestart, inotify(7)/kqueue handlers, system load diagnostics and so forth. The shutdown stage is another separate part, often handled either in the initd or the process manager. Often, it just hooks to the argv[0] of standard tools like halt, reboot, poweroff, shutdown to execute killall routines, detach mount points, etc.

To stuff everything in the init system, I'd argue, is bad design. One must delegate, whether to auxiliary daemons, shell scripts, configuration syntax (in turn read and processed by daemons) or what have you.

sysvinit is certainly inadequate. The inittab is cryptic and clunky, and runlevels are a needlessly restrictive concept to express what is essentially a named service group that can be isolated/overlayed.

Of course, to start services on socket connections, you either use (x)inetd, or you reimplement a subset or (partial or otherwise) superset of it. There's no way around this, it's choosing to handle more on your own rather than delegate. In systemd's case, they do this to support socket families like AF_NETLINK.

As for systemd being documented, I'd say it's quote mediocre. The manpages proved to be inconsistent and incomplete, and for anyone but an end user or a minimally invested sysadmin, of little use whatsoever. Quantity is nice, but the quality department is lacking.

sysvinit's baroque and arduous shell scripts are not the fault of using shell scripts as a service medium, but have to deal with sysvinit's aforementioned cruft (inittab and runlevels) and the historical lack of any standard modules. BSD init has the latter in the form of /etc/rc.subr, which implements essential functions like rc_cmd and wait_for_pids. Exact functions vary from BSD to BSD, but more often than not, BSD init services are even shorter than systemd services: averaging 3-4 lines of code.

A unified logging sink is nothing novel, it's just that systemd is the first of its kind that gained momentum, but with its own unique set of issues. syslogd and kmsg were still passable, and the former also seamlessly integrated itself with databases.

Once again, changing the execution environment is a separate stage and has multiple ways of being done. Init-agnostic tools that wrap around syscalls are probably my favorite, but YMMV.

As for containers, it's about time Linux caught up to Solaris and FreeBSD.

Strictly speaking, init(8)'s sole responsibility is to reap children, set the session and process group IDs, and optionally exec the actual process manager. In practice, this is bare bones, but strictly that's all that's required.

A process manager then usually provides an abstraction around processes (usually PIDs) called a "service", implementing a minimum of start/stop/restart/status. Status is most primitively done using a PID file. Other extensions like conditional restart can be added.

A process supervisor then ensures that processes are automatically restarted, that inotify(7) triggers are added, that system load is monitored, applying resource limits, emailing an admin upon state change, etc.

Such a trichotomy is rarely expressed, but a hypothetical example that would likely work would be sinit + svc + perp.

Autorestart should be expressly enabled by the sysadmin's choice and disabled by default, due to the possibility of buggy daemons improperly backing up their state, as well as edge cases that may be present in the admin's particular environment.