And it is portable to the BSDs, what a concept, writting portable applications :)

To bad that is now out of fashion. If the BSD software was not portable Linux would not have gotten off the ground.

If there was a portable implementation of namespaces that was implemented by both Linux and BSDs, then sure systemd could be made more portable. Otherwise the only reason OpenRC is more portable is that it does not isolate services in the first place (as systemd does using namespaces).

It works perfectly well with namespaces but you have to tell it to use them (it uses them for runlevels out of the box, but you need to tell the launch script if you want a process to be isolated). Though for that matter SysV does too.

It’s a system service manager, it being portable is not a requirement nor any benefit when BSD has nearly no traction in the desktop or server space other than a few cases.

> it being portable is not a requirement nor any benefit when BSD has nearly no traction in the desktop or server space other than a few cases.

Is your argument that portability is irrelevant because nothing but (systemd/)GNU/Linux matters, or that service manager in particular don't need to be portable?

Some complex applications are starting to require systemd components. So yes, portability may become important to the BSDs.

Which applications?

GNOME since more than 10 years

Gnome runs on OpenBSD so it clearly doesn't "require" systemd

gnome hard depends on systemd, so much that for it, *bsd (and any non-systemd unix-like) had to write a systemd-shim to emulate some functions of it, and/or gut some of systemd's components such as logind in to elogind

Not for a while now; accountsservice runs fine with cosolekit. I still don't understand why the broader Linux ecosystem burned the better part of a decade on the long-solved problem of "who is logged in to this TTY?", but whatever floats their boat...

BSD is used in a lot more than you think due to solid engineering and a non-viral commercial friendly license.

OpenRC predates systemd I believe

It's also not a complete alternative, because it doesn't have anything for user session services like `systemd --user`. I use postmarketOS which is based on Alpine which uses OpenRC, and desktop session daemons currently have to be started by the compositor via XDG autostart files. So services start fine but they're not restarted if they crash, they have ad-hoc logging, etc.

One of the pmOS devs wrote a user session service manager [1] but pmOS doesn't use it (yet?). And Alpine as a whole is planning on moving away from OpenRC anyway.

[1]: https://git.sr.ht/~craftyguy/superd

Oh, what is Alpine planning to move to?

> It's also not a complete alternative, because it doesn't have anything for user session services like `systemd --user`.

i am working on a implementation of that for openrc for a while now, it's been working nicely so far: https://github.com/OpenRC/openrc/pull/573

Enjoy https://jdebp.uk/Softwares/nosh/guide/per-user-dbus-demand-s... and https://jdebp.uk/Softwares/nosh/guide/commands/dbus-daemon-l... .

There is work being done to add user sessions to openrc by some person. It seems pretty cool so far!

I'm not totally sure whether openrc will merge this or not, but I would definitely like to see this be added.

edit: They actually seem to have replied to you while I was writing the original comment.

It really seems strange to me that postmarketOS does not use systemd, given how its too main usecases (mobile use as well as server use of repurposed devices) would certainly benefit from a mature service manager. Possibly even if they had to put it on top of Alpine themselves.

pmOS has no intention of moving off of Alpine base, and systemd is still incompatible with musl (or vice versa, depending on which side you're on in the arguement :) ), and OpenRC works well enough for now.

That doesn't mean its initial design didn't learn from the mistakes systemd made.

How could that be possible if it predates systemd?

systemd repeats a lot of mistakes that systems prior to openrc made, and that openrc avoided.

Systemd is a complete solution to a variety of problems with system services under Linux, including user sessions, non-racy session termination, etc.

Other init systems, not so much.

There are no alternatives to systemd, kinda like there are no alternatives to Excel. Some packages solve many of the same problems, but none solve all of them as thoroughly.

Systemd is a hydra, gradually strangling more and more existing functionality with replacements of questionable utility.

> non-racy session termination

I've seen a lot of dangling sessions with systemd actually although I'm not sure what the root cause is.

I had to get an intern to basically live in the server room and look for screens saying "stop command for user 1001 waiting 30 seconds... 90 seconds..." etc. and power cycle the machine. It's ludicrous.

In other words, tell me you've never adminned systemd without telling me you've never adminned systemd.

Hint: man systemd.service, look for TimeoutStopSec.

lol no. Never worked. Tell me you've never run systemd in a server room without telling me you've never actually run systemd in a server room.

My comment is embarrassing. I'm sorry for that.

Systemd is a complete solution to a variety of problems may not exists. :P

>non-racy session termination

The irony it's hard there. SystemD it's the only init system which gave me errors trying to shutdown a machine...

>alternatives to Excel

You are right. Both systemd and Excels are turds. Excel mangled genomics data making it unusable and forcing scientists to rename sequences in order to not clash with Excel's internal names. That's utterly crap and a severe step backwards from scientists from the 90's used to be around Unix/GNU-Linux envs where they were utterly free to name whatever thing in almost any way they wanted.

The commonality between Excel and an incel is they think everything is a date.

Yes, I have a software watchdog specifically because systemd sometimes fails to reboot correctly :-)

Same systemd often hang at shutdown and I cannot be bothered to understand why.

My biggest issue with systemd is the log system. It is so stupidly slow, that I don't think it is possible to make it that slow without purpose. It literally takes minutes to grep though logs on any of my machines with journalctl.

In fact it is so slow. It is faster to first eat the few minutes to extract the logs into a text file. Which I can then grep through in milliseconds.

Oh and the raw text file takes less space than the systemd log database!

What scientist would ever even consider excel in the first place?

Most of them, in my experience.

And it uses Linux native services like cgroups for isolation.

So does any init system if you tell it to; systemd just forces you to use them

Manually writing bash scripts to juggle cgroups is not "the init system supporting it".

With systemd, this comes out of the box.

I mean, you (or somebody) need to write a short bash script for each service on sysv, and adding cgroup management to that isn't particularly hard. I just never understood how people find that more complex than a huge mess of unit files that transpile down to God-knows-what, but apparently people do.

The user services systemd offers are legitimately cool (though shepherd does it better), I've just never personally understood how people find it "simpler" as a system service manager.

Thanks for the clarification.

But I still don't get it; have you ever _seen_ a complete init script? These things are hundreds of lines long if you want to account for stuff like PID management and restart capability and isolation.

And you have to do that for every service on your system. And they are not even really portable.

It only gets that long if you include the LSB dependency nonsense. Look at Slackware's scripts and tell me where those hundreds of lines are hiding.

Okay. Would you mind explaining how you set up dependencies between the various services if you don't use the "LSB dependency nonsense"? What does Slackware use for that?

You write the shell commands that start them in the order you want them started in and run that from your rc system. I stg I have no idea why people find this so hard.

For me the hard part comes when you don't want these services run all the time, but only when needed.

How'd you do that?

Inetd, the software people mysteriously re-invent every decade or so

And then you don't have dependencies anymore, so you're back to square one.

I don't see how this is supposed to be more comprehensible or even "simpler" than a 12 lines unit file.

Several dozen unit files whose dependencies need not be listed in the files themselves, you mean. Which is why it's a step backwards in terms of simplicity.

You get the dependencies just like you do with any other socket activation. Web request starts the web server, which connects to and starts the application server, which connects to and starts the data store.

> Several dozen unit files whose dependencies need not be listed in the files themselves

Where else would you expect to declare the dependencies other than the file which defines the service? That's where I would expect to find (and add) the dependencies.

> You get the dependencies just like you do with any other socket activation. Web request starts the web server, which connects to and starts the application server, which connects to and starts the data store.

Fair enough!

But dependencies can also be expressed by the location of a symlink

I've used this opportunity to look at some recent init files.

Here's one of the first I stumbled upon.

https://github.com/NagiosEnterprises/nagioscore/blob/master/...

It's 288 lines long; the LSB dependency nonsense is 8 lines of that.

Then I looked up one for Postgres;

https://wiki.postgresql.org/wiki/Lsb_conforming_init_script

This one is a whooping 356 lines long, LSB is again about 10 lines long, depending whether you count the header or not.

I don't think the "LSB dependency" argument holds water.

The irony is that a lot of the boilerplate from both, including that massive case...esac part, has been eliminatable for about 10 years. See https://unix.stackexchange.com/a/480897/5132.

These are not "recent" at all, which is part of the problem. The wiki page largely froze in 2010, several years before the init-d-script innovation; and the people maintaining the nagios script until around 2018 never even tried to make use of init-d-script.

It might well be that most of the boilerplate is a "solved problem" - then the question becomes; is this solution used at all? Let's have a look at a recent init file, from current Debian. I again just picked the first thing that I found, which was the openldap package:

https://packages.debian.org/bookworm/amd64/slapd/download

This init file too is over 200 lines long. I don't know how much of this is avoidable boilerplate, but evidently the Debian package maintainers either don't know about it or they lack the resources to implement it.

Systemd is a solution to problems that exist in rare corner cases.

We had a nail and all we needed was a hammer, instead we got a hydraulic press.

OpenRC was released 3 years before systemd