Comment by antonyh

> But there's a reason it's being adopted: it does it's job well

My problem with systemd is that it's taking over more and more and locking in. It is encouraging developers to have a hard dependency on it, and making it harder to have an alternative.

My problem is not philosophical with "it's a monolith, it's not unixy". My problem is "it's on the way to lock me in".

We like to complain about lock-in across the board. I don't see why it would be different with systemd.

I wrote up some issues with service reliability here https://github.com/andrewbaxter/puteron/?tab=readme-ov-file#...

Design-wise, I think having users modify service on/off state *and* systemd itself modify those states is a terrible design, which leads to stuff turning back on when you turn it off, or things turning off despite you wanting them on, etc. (also mentioned higher up)

FWIW after making puteron I found dinit https://github.com/davmac314/dinit which has a very similar design, so presumably they hit similar issues.

Ohh... I have sooooo many issues with systemd. The core systemd is fine, and the ideas behind it are sound.

But it lacks any consistency. It's not a cohesive project with a vision, it's a collection of tools without any overarching idea. This is reflected in its documentation, it's an OK reference manual, but go on and try to build a full picture of system startup.

To give you concrete examples:

1. Systemd has mount units, that you would expect to behave like regular units but for mounts. Except that they don't. You can specify the service retry/restart policy for regular units, including start/stop timeouts, but not for mounts.

2. Except that you can, but only if you use the /etc/fstab compat.

3. Except that you can not, if systemd thinks that your mounts are "local". How does it determine if mounts are local? By checking its mount device.

4. Systemd has separate behaviors for network and local filesystems.

5. One fun example of above, there's a unit that fires up after each system update. It inserts itself _before_ the network startup. Except that in my case, the /dev/sda is actually an iSCSI device and so it's remote. So systemd deadlocks, but only after a system update. FUN!!!

6. How does systemd recognize network filesystems? Why, it has a pre-configured list of them: https://github.com/systemd/systemd/blob/4c6afaab193fcdcb1f5a... Yes, you read it correctly. A low-level mount code has special case for sshfs, that it detects by string-matching.

7. But you can override it, right? Nope. This list is complete and authoritative. Nobody would ever need fuse.s3fs . And if you do, see figure 1.

I can go on for a looooong time.

To pile on, a minimal OpenRC service file is just as complicated as a minimal SystemD service file; that is, they're both almost-exclusively composed of key-value pairs. For instance, this is the service file for the 'rsyncd' service [0]:

  #!/sbin/openrc-run
  
  command="/usr/bin/rsync"
  command_args="--daemon ${RSYNC_OPTS}"
  pidfile="/var/run/${SVCNAME}.pid"
  
  depend() {
   use net
  }

Like SystemD, OpenRC provides pre/post start/stop hooks that you can use to call out to other programs.

Unlike SystemD if you need to make nontrivial decisions at service-status-management time, you have the option of putting your scripts or calls to other programs inline, rather than hoping that SystemD gives you the hooks you need in the places you need them and passes in the data you require. [1]

[0] And if 'rsyncd' was supervised with 'supervise-daemon', you wouldn't need to specify the location of the pidfile.

[1] As a trivial example, you can dynamically depend on other services depending on system configuration (as PostgreSQL does). As a less-trivial example, you can check for and warn the administrator about common service misconfigurations with the same mechanism that provides service startup and status information (as several services do).

systemd is not a monolith, and distros make different choices on what portions of systemd they which to ship and enable by default.

For example, not all distros ship and use systemd-resolved by default, to choose from your list.

The thing is not just about distros and big developers it is about every developer out there who wants to write system software. Instead of doing the work to support multiple different APIs they can concentrate on the software. Its just easier. You don't have to track the compatability of different tools.

For many people Linux is not an academic exercise. It is a tool they want to use. The don't care to use a different network manager or resolver.

And that is exactly the same as Windows. There is one solution across the whole system and it works together because it is written by the same people and tested together.

Others have been reminding us of the *BSD init systems, and I remind that SysVinit is not going away from Linux while projects like Devuan and others continue. GNU Hurd is another other-than-systemd learning opportunity.

I've heard of Hurd, but never felt tempted to try it. That could be an interesting option.

Did they finally add USB support?

I would somewhat doubt it; the negative aspects of Mach’s design are a technical albatross around the neck of any kernel.

Apple has had to invest reams of engineering effort in mitigating Mach’s performance and security issues in XNU; systemd dissatisfaction alone seems unlikely to shift the needle towards Hurd.

> Freedesktop wants to kill X11

There is a difference of opinion. Freedesktop wants to "stabilize" X11. That does mean that they do not want to evolve Xorg. However, it does not mean that you cannot keep using it or that they are going to take it away. In fact, it is still being maintained and will be for a long time.

You can interpret the rejecting of patches and banning of developers as political. However others see the rejection and banning as protecting the stablity that is the goal.

If your goal is for Xorg to evolve and not to stabalize (fair), you may prefer Xlibre as a project.

Phoenix looks pretty cool too.

KDE Plasma and GNOME are trying to kill X11. Or, at least, they do not want to maintain support for it in their projecs. And COSMIC did not bother to add support for X11 at all. That will probably be the trend on desktop Linux.

> Freedesktop wants to kill X11 and are working continuously on that, to the point if rejecting patches and banning developers.

Are you referring to the developer of Xlibre, who submitted multiple broken patches & kept breaking ABI compatibility for little to no reason[0]? Or someone else?

[0]: see discussion & linked issues in the announcement https://news.ycombinator.com/item?id=44199502

I see this was your first HN contribution and you didn't post any links, so maybe that's what they were thinking?