Comment by an_d_rew | Hacker News Reader

Comment by an_d_rew | Hacker News Reader

Parent Full thread

This was an amazing review, and love systemd or hate it, this article gives a fantastic history and exposition of what systemd actually is.

My favorite quote (and when taken in context is much less tongue-in-cheek thank you might think):

systemd is an event-driven object manager with dependency-like side effects which ‘boxes’ primitive kernel resources and userspace subsystems into a generic object type called Unit. These Unit objects are scheduled through the state propagation mechanism of ‘jobs’ and dynamically dispatched via a singleton object called Manager, responsible for launching jobs in ‘transactions’ which do merging, cyclic ordering and consistency checks and serve as the main point at which unit dependencies are pulled in. Unit startup is executed as a non-indempotent parallel dataflow with weak ordering guarantees on the job level, mostly independent of the active state of dependent units.

Any night you have insomnia, just read that a few times and you'll be out like a light! :-)

I’m a fan of this description. It might not be the easiest to understand or the first one you should read, but I wish more things had this kind of description somewhere (but not necessarily on the introductory materials or front page).

It’s buzzword bingo with the aim to inflate the writer’s ego and intimidate the reader. This stuff happens all the time when insecure people get to write things.

Which words do you think are buzzwords in the description? What I think of by buzzwords are things like “Blockchain”, “Machine Learning” etc. which are generic topics used to build hype whilst not really explaining anything.

In this case however, the words are all fairly precise and accurate (at least from my basic understanding of systemd). They might not be words used in everyday conversation, but they don’t need to be unless the document is targeted as introductory material (which I don’t think is the case).

That’s not to say this is the only way to explain it, but it is a very concise way, which I at appreciate.

I would say most of it is unnecessary buzzwords that don't help explain it. The whole thing can be simplified to something like "systemd is a task runner that has a dependency graph and transactions". That should also be fairly straightforward to you if you've used it a few times.

I'd say the other mistake the article commits is by trying to paint this as being a very complex design for the problem space. It's not when you consider the design constraints. You want services to have dependencies, and you want the updates to the unit files to be committed atomically to avoid stale data. Hence, the dependency graph and the transactions.

I highly disagree. Sure, it contains a lot of buzzwords, but it clearly describes systemd and its philosophy in a single paragraph. It's not the first thing you should throw at someone unprepared (because then it would really be intimidation), but it prevents you from reading 20 pages of documentation and not getting the gist.

Sometimes, a concise, high-level overview is what you need.

> it clearly describes systemd

It really doesn’t.

Agree to disagree.

Maybe because I've worked in embedded Linux for so long (including on inits of various forms), but that description clearly articulates exactly what systemd is and does and I appreciate the direct, crystal clear technical language rather than some long form essay written assuming a clueless reader with 0 technical background.

You’re pulling my leg, right? The description could be improved, for starters, by forcing the author to not use the word “object.” That overuse alone makes me wonder if the description is satire.

I expect everyone here commenting is familiar with systemd. I doubt very much that anyone who was unfamiliar with systemd and read that description would then have any idea what it does or how it works.

I mean, I'll agree with you in so far as that the wording could be improved further. But I do really, honestly think it's a good summary.

> I expect everyone here commenting is familiar with systemd. I doubt very much that anyone who was unfamiliar with systemd and read that description would then have any idea what it does or how it works.

It depends on what knowledge you expect. If someone is familiar with general init management and some programming concepts, this short summary will get them up to speed (and that's what I/we were arguing). If you grab a layperson of the street and read them this, it's obviously not going to tell them anything - but that's not the target audience.

What I value is a short summary which brings a reader, who knows the concepts and the space a software is operating in, up to speed quickly. And that's what this summary does.

It uses many well defined technical terms like:

- event-driven

- object

- side effects

- kernel resources

- userspace

- subsystems

- unit

- scheduled

- state propagation

- dispatched

- singleton

- merging

- cyclic ordering

- consistency checks

- dependencies

- non-idempotent

- weak ordering guarantees

And while this list is good for BS Bingo, as these terms are being used in other contexts too, the overall description of what systemd does is pretty precise for just three sentences.

That's what you've got from a very clear technical description, in a very detailed history and breakdown?

If you don’t understand something, it’s cleverer to remain silent

Exactly.

“Idempotent” is one of the key words used as a cudgel in this way. It’s great for the bullshit artist, as to a layman the dictionary definition is completely inscrutable.

> as to a layman the dictionary definition is completely inscrutable.

This isn't written for laymen, who would obviously never be reading about what SystemD is. It's written for specialists who do engineering work on or with Linux, and who actually need to know the technical details of their tools.

And anyway, I suspect plenty of laymen, and highly trained professionals in other fields like law, medicine, and philosophy among others, would have no trouble understanding what "idempotent" is. It's not inscrutable at all, but rather is one of the easiest concepts in CS and software engineering to understand.

Idempotence is a desirable property of systems whereby repeating an action has no effect. Mathematically, an operator is idempotent if f(f(x)) = f(x).

Idempotence is handy because it implies that one can retry safely if one isn't sure whether something succeeded or failed. Not sure if your file was saved? Save again! If it was indeed saved, the file continues to be saved. If the file was not saved, it is now. Yay.

I would kill for such descriptions of every system I work with.

Idempotent is surely a valuable piece of software jargon. I know exactly what the user intends, and have good ideas of how hard it is and what likely trade offs they will be making behind the scenes

surely it is the very opposite of bullshit.

But the phrase in the paragraph is non-idempotent which is completely redundant. Every piece of software in the world is non-idempotent.

Apart from the idempotent ones ... :-)

Idempotent is a perfectly fine word. There is absolutely no reason why CS shouldn't have it's own jargon. I found the description very descriptive.

"I found the description very descriptive" - an idempotent system in action.

Actually, it is just a word to describe the property that if you do something repeatedly, it leads to the same result as doing it just once. So the latter executions don't change anything.

And because it is such a common property when talking about algorithms and APIs the word is pretty common among CS people.

One very popular example are REST APIs because some HTTP verbs are idempotent and others are not [1]. This is also the reason why your browser asks you, if you want to submit a form again when refreshing a page that has been reached by submitting a POST-form.

[1] https://en.wikipedia.org/wiki/Representational_state_transfe...

> Exactly.

> “Idempotent” is one of the key words used as a cudgel in this way. It’s great for the bullshit artist, as to a layman the dictionary definition is completely inscrutable.

Are you saying that being "idempotent" is completely inscrutable? Is it not a fairly straight-forward concept?

If we're going to be pedantic, "idempotent" (or rather non-idempotent) as used in the description is rather vapid and meaningless. Idempotency is a quality that describes the result of an action; as such, only actions can be thought of as idempotent. Applying the word idempotent to any noun that does not describe an action (such as "dataflow" in this case) is meaningless.

What does it mean for a dataflow to be idempotent in the first place? What purpose does it then serve to describe a dataflow as non-idempotent? What they meant to say, I guess, is that the dataflow may contain multiple actions for the same unit, and that systemd makes no guarantees about the end state of the unit in such a case. But even then, it is the execution which should be described as non-idempotent, and not the dataflow.

That feels unnecessarily pedantic. If the sole job of entity X is to perform action Y, and it always performs this action idempotently, then why not describe X as idempotent? It's shorter, and it's clear enough. It might not be precisely accurate in the dictionary definition of the word - but natural languages also have DSLs, and those DSLs evolve to adapt to their use cases. Saying "thing that performs an idempotent action" over and over again is a waste of everybody's time.

In the context used, it’s fluff.

Idempotent is a perfectly cromulent word for a technical article not aimed at complete newbies.

Idempotent is a very clear and quite basic term: being able to run something multiple times with no different outcome than running it once. A very valuable property for certain systems (even for simple shell scripts).

And the description of systemd just uses bog standard terms related to what systemd does and the resources it manages.

But I get the feeling that both this and the parent comment it agrees with were more about the putdown and talking bad at someone, than about a technical or other objection.

It reads like an over-eager developer read Design Patterns and then was tasked with writing a new init system for Linux.

I think the whole problem with systemd wasn't just about technology. The results were spectacular. Before systemd normal Linux boot times were well over a minute. After switching you could get below 10 seconds on the same hardware. And that is just one aspect.

I think the core of the problem was somewhere between the style of introducing changes and the way how people communicated. After all, it speaks for itself that pulseaudio and systemd shared a lot of common criticism. Both are technically sound systems today, but in a way, systemd was just the escalation of the pulseaudio debacle.

SystemV init allows for init scripts to run in parallel, but that was rarely used. Most time spent was anyhow waiting for network (e.g. the MTA trying to resolve the hostname) and hardware initialization. Bourne shell isn't particularly fast, but ten years ago hardware used for typical Linux desktop/server systems was fast enough that it hardly mattered (it's used here for sequentially starting system processes, not number crunching). Not that it matters -- how often do you boot a desktop/server in a day? Performance mattered for VMs deployed in the cloud on request, but whether a full OS is the best choice for such services is a different topic ...

Here's a good example.

https://bugs.freedesktop.org/show_bug.cgi?id=76935

His name is Lennart Poettering, and apparently he was tasked with reinventing the entire operating system

Quite true, and he was coerced!

http://systemd-the-porno.com

... I don't get it? Who is "Madeline" supposed to represent?

...so, how does a systemd unit definition differ from a Makefile (other than using a different syntax, obviously)? What features would you need to add to UNIX make (and PID 1, for that matter) in order to be able to separate out this whole dependency management business from the other stuff PID 1 has to deal with already?

For one thing make is imperative and doesn't actually know what it's doing. Systemd is declarative. You'd need to replace all the options service files give you.

Make doesn't do dependencies between unrelated projects. A makefile can't say "I want to run if X runs, but I should run before them".

Make doesn't have supervision, you'd need some kind of declaratively configured poller.

Systemd is also parallel, there's probably some complexity there that make might or might not handle well.

I think the most important problems would only be obvious once you started using a replacement system though. Systemd almost totally replaces the need for any imperative code whatsoever for process autostart, configuration, and supervision, and that might be hard to do in a more modular setup.

You don't need extra stuff besides the service file. Everything is extremely consistent and done the same way for every service.

Everything statement that comment makes about make is incorrect, except the bit about polling.

Polling is better-addressed by having each service implement its own error handling. Restart loops are the wrong policy for most services. In the rare cases where they are actually the correct behavior, they’re trivial for the service author to implement.

Those that don’t understand make are doomed to reimplement it poorly.

How are restart loops the wrong policy? If it should be running, and it's not, how else would I fix it except by restarting it?

They're not exactly trivial. There's restart delay, number of times to restart, passing stdout through so the journal can get it, and there's failure reporting.

How is PID 1 supposed to know if my service failed when the restart daemon is still up and running, but my actual app keeps crashing? How can it tell the difference between my app and a supervisor, or a fully failed app or just one failed subprocess that my app can handle? Now you need some scheme for that.

If PID1 doesn't know what's failed, how would I get a list of all failed systems programmatically?

Systemd could provide a standard supervisor component, but then it couldn't ever do anything but restart failed apps, or you're back to people complaining about monoliths.

You'd have to have your service file explicitly call it with some command line args making your syntax uglier.

And more importantly, it might be harder for the systemd dev team because now they have a communication protocol between this restart daemon and everything else.

Or they could leave restart daemons up to the user... and everyone would probably choose 3 different ones, that might or might not keep up with compatibility. That would break the "One and only one obvious way" principle.

When you start splitting stuff up in tiny bits, you get more overhead, all the extra nice features seem to evaporate.

To pick just a small piece of the pie:

Dependencies in make are equivalent to systemd's Requires= and After= combined. Systemd is far more general in this regard, both in that Requires= and After= are separate concepts, but also in that there is Wants=, BindsTo=, etc. and their inverses (RequiredBy=, Before=, etc.). Sometimes when I'm writing Makefiles I wish Make were capable of expressing some of these concepts.

My devuan linux desktop says something like this on each boot:

INIT: version 2.88 booting

Using makefile-style concurrent boot in runlevel S.

I've tried Devuan once then it some roadblock because Docker wouldn't run easily on it, but that was a long time ago.

I may try it again one of these days now that the latest Devuan stable is based on Debian Bullseye.

The "why" is simple: to restore some balance in the force.

I do prefer my Linux world to be one where I still have a choice as to which init system and PID 1 my system is running.

Devuan has its own problems with its image and communication:

https://lwn.net/Articles/786593/

It's not even the immaturity of the joke that bothered me back then, but that the response to the criticism was to imply that it is "corporate bullshit" and/or "giving up on having fun".

you could at least give openrc a go.

Reply on news.ycombinator.com