That's just saying "I want things to be the way I first learnt them and don't want them to change."

This is fine, but you do have to accept that things are going to move on without you.

Heck I hadnt used Linux for a few years and when I got back to it systemd was on every distro I use. I just use it. I dont see the big deal. I grep the piped output of services if I want to narrow things down more just as you would the output of cat or ls or anything on Linux.

By that logic, no mistakes can ever be criticized.

I explained, why systemd is a step in the wrong direction in mutiple ways. That has nothing to do with habbits.

> I explained, why systemd is a step in the wrong direction

I see a bunch of "I want X", but I don't see any "why"

>I want to use the tools I like

>I want to call a script that does that. A script which I can look at and see what it does

But there have been reasons given. They want to use standard tools to deal with the log. They want to see the scripts that manage the system and poke around in it, which has the implicit reason to learn about the system and being able to easily modify it.

> They want to use standard tools to deal with the log.

I have a little sympathy for this one as an old habit if you don't know any better. It's also an extremely inefficient way to work with logs. If you've used a system like Splunk seriously, the idea of going back and grepping through logs on a host with the shell is just frustrating.

> They want to see the scripts that manage the system and poke around in it, which has the implicit reason to learn about the system and being able to easily modify it.

I have no sympathy for this one. Scripts are a terrible place to define policy. They are nigh impossible to audit. They are brittle. They multiply complexity by making everything a special case. They make integration of different parts of the system nearly impossible.

No, that's saying I want things that stick to the Unix philosophy of simplicity, clarity and text formats with no hidden magic.

Aren't systemd units simple text files with no hidden magic? In fact, all systemd configuration is plain text files and symbolic links. The only binary format is the journal.

> Aren't systemd units simple text files with no hidden magic?

Compared to something like a shell script, systemd unit files are magic because you have to know a lot about how systemd works to figure out how your config file translates into actual behavior.

I think learning systemd configs is substantially easier than learning an entire awkward programming language.

Whenever systemd comes up, someone appears to counter any criticism with words suggesting you'll get left behind if you don't follow us. No justification beyond that.

> When I want to write a script that runs on startup, I expect that I can just put (or link) it in some directory where the scripts are that get started on startup

This is not very specific, have you never had any race-condition with this? There is a reason SystemD ask some informations regarding the service that needs to be launched. I don't see how ignoring those makes a good argument against SystemD.

Many simple systems don't do parallel service startup like systemd, if that is what you mean.

They mean that you can specify dependencies. So start some service Y only after X has been started. I use this extensively in my home automation services. Can't start other services if the MQTT-Server hasn't started and that isn't done until the network is initialized.

Sure, but doesn't that also make them slower?

Hardly. I'm an OpenRC user. Booting OpenRC vs SystemD, desktop, server, VM. Near zero difference in boot time, neither side was a clear winner, nor always faster.

My favorite part is OpenRC still likes the old ways, has script extensions for new ways, and runs the same path every time.

That's just anecdotal. If it's a technical fact that SystemD does parallel upstarts where OpenRC for example does not, that just means you don't have a system where parallel upstart makes a difference.

No, I can not remember having a race condition regarding startup scripts.

Then you didn't have to mantain a system of any kind of complexity.

And you have? Can you give an example and how you solved it? Thanks! (edit: not trolling; curious)

I think my issue what binding Consul to docker0 while Docker is starting. Half the time the interface wasn't ready. I don't remember exactly how I fixed it but with SystemD you can just specify a dependency.

I think I had one where one service was trying to bind to a network interface that wasn't ready, maybe docker0. It was painful to find and fix.

> When I want to write a script that runs on startup, I expect that I can just put (or link) it in some directory where the scripts are that get started on startup. Or that there is one main script that calls all scripts that are intended to be startet on startup.

AFAIK, systemd is compatible with sysv init scripts.

> I do not want to write a "service" that has some "only run once and then discard" flag or whatever.

Why? Writing one isn't so complicated.

> When I want to look at logs, I want to use the tools I like. less, grep, tail etc. I do not want to dabble with some binary format and its tooling.

Well, nothing prevents you from piping output from journalctl to whichever tool you prefer. In fact, people do it all the time.

> When I want to start or stop a service, I want to call a script that does that. A script which I can look at and see what it does. Like /etc/init.d/apache2. I do not want to execute some magic command like "service apache start" which I have to guess or look up and which gives me no clue about what it does.

I don't see how sysv init is any better than systemd in this regard. You'd still have to look at indidual scripts to see what it does. It's not like systemd hides the contents of the service files.

> A script which I can look at and see what it does. Like /etc/init.d/apache2. I do not want to execute some magic command like "service apache start" which I have to guess or look up and which gives me no clue about what it does.

Interesting. I feel the other way. Unix failed to provide a real service management system early on, so we have layers of historical cruft (Fork, close all descriptors, fork again, escape process group? Really?), and ended up with all kinds of absurdity in shell scripts to handle it.

The right way is to have a strong system contract on what constitutes a service, and have no wiggle room so that 'service apache start' does a fixed, known thing.

Sadly, systemd has to support all kinds of legacy hacks. A nice way to chart a way forward might be to define a simple contract and require someone to mark a unit file as "legacy" to enable the other possibilities.

So I take it you've never used journalctl then at all? Because seeing as how it's default behaviour is to use the system pager, which on any system with `less` installed is less, I'm somewhat at a loss as to what you can't do with it that you can with files now.

> I do not want to write a "service" that has some "only run once and then discard" flag or whatever.

Then just use cron.