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.
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'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.
Sometimes, a concise, high-level overview is what you need.
It really doesn’t.
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.
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 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.
- 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.
“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.
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.
surely it is the very opposite of bullshit.
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.
> “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?
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.
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.
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...