> No, nothing deserves this constant whining and crying day in and day out.

Why even try an start a conversation with that attitude? Wayland doesn't get nearly as much hate as Windows, Chrome, or iOS. But I guess literally nothing is worth writing an article that has the word "fuck" in it 7 times, because that crosses some kind of ultimate line?

There are plenty of projects that move something in the Linux world.

The problem with systemd and Wayland is that they are not like any other projects which the users may choose depending on how useful they are for their needs.

Wayland and systemd are forced by a few distribution maintainers upon a great number of Linux users, regardless of what those users may want.

Many users may not be directly impacted by these changes, so they may trust that the maintainers know what they are doing.

But there are also many users for which these replacements would require a lot of work so such users would expect a better justification of why systemd or Wayland are an improvement over alternatives. I have seen tons of presentations about systemd or Wayland, but none of them were convincing. There were never any correct comparisons with alternatives to show that systemd or Wayland are better at something.

I agree than it would be very desirable for X11 to be replaced by something better.

But I have never seen any piece of information that would indicate that Wayland is better. On the contrary, almost every detail that I learn about Wayland shows a bad design decision.

For example, before reading the parent article, I was not aware that the Wayland client API is so reliant on callback functions. In my opinion, this is bad because such an API is inefficient, as it leads to a lot of code duplication.

In my opinion, the cases when it is a good choice to use callback functions are very rare. Instead of callback functions, it should have been better to use some kind of event queue, because there is little else that callback functions can do, except inserting the event into a queue, for handling by the main thread.

The only "advantage" of callback functions is that the implementer of the API might have chosen a bad implementation of an event queue, while an API based on callback functions is not yet committed to a particular queue implementation, allowing the user of the API to do the right thing, but possibly with a waste of code in the initial part of all callback functions.

Avoiding the choice of an implementation for the event queue could still be done efficiently if there were a single callback that you could use for all Wayland functions, which would be your own implementation of the queue insertion function. This would be a good API, as there would be no code duplication, while also not forcing an implementation choice. Multiple callback functions make sense on the server side of a protocol, not on the client side of a protocol, because the messages passing through the protocol might be seen as remote procedure calls originating from the client.

Tbh, it's quite delusional to think that a better alternative solution would win that's not backed by Redhat and GNOME. In a purely competitive environment, a design like Wayland could never have "won" as an X11 replacement, it was pushed long enough until it was "too big to fail".

You’re not being serious with your over-generalization dangling around.

The ancient Linux sysvinit-based service management is a strawman, because the scripts available in various distributions were very heterogeneous and many were quite bad.

There are other ancient service management systems that were much more coherent and which did not show any disadvantage in comparison with systemd, e.g. even the sysvinit-based service management of FreeBSD or other *BSD, which were and are much better than the "sysvinit-based" of old Linux.

An example of how a replacement for the traditional UNIX service management can be well designed was the daemontools of Daniel J. Bernstein, written more than a quarter of century ago, long before systemd. There are derivatives of daemontools that are brought up-to-date and they are much simpler and more secure than systemd, while systemd does not have any advantage that can justify its complexity, opacity and interference with other applications.

All the non-systemd service management solutions have the advantage that even if you are not familiar with a computer, it is easy to debug any problem because all the behavior is written in a bunch of text files. With systemd, you can never be sure what happens. The behavior implemented by systemd may change between versions, you might not have the source of systemd or the source of the particular version installed on the computer with problems, the source may be very complex in comparison with traditional shell scripts or with the very simplified scripts of something like daemontools.

Thus claiming that using systemd uses "descriptive" files is not really true, because the uncertainties about what those files describe are much greater than for any other service management solutions.

Even a set of shell scripts, like that of FreeBSD, can be as "descriptive" as the configuration files of systemd, when all the service scripts share a common set of definitions of functions and of configuration parameters.

You're right I do fall into category 1

That's fair. I have not interacted with it beyond using journalctl to debug various services and I found it easy to work with

> It works very reliably, [...], and it has fixed a number of problems with the Linux desktop.

Yep. Today, I would tend to agree with this.

> switching to it caused no issues

Yeah, okay, there's no need to make wild untrue claims to support your position. The initial adoption was rough, things absolutely did break, and some of those rough edges are still around to bite the unwary (enable-linger/KillUserProcesses are my "favorite" footgun that will never be fixed because systemd thinks killing your stuff is a feature).

"Some people just want to live in the 80s forever."

I think this shaming of free software users that want to make other choices is rather terrible.