And that is probably the motivation for this design philosophy of limiting options that Redhat and Freedesktop champion where more and more, simple, clean, turing complete solutions are replaced by a discrete list of simple options.

But it does not change at all why I dislike it, and why I am annoyed by Freedesktop's pushing and insistence that many keep to these more custoizable solutions supposedly simply because they are “stuck in their ways” and that their philosophy is the future and “modern”, whereas all I see is more hurdles that stop me from effectively being the master of my own machine.

You have a misunderstanding of what Freedesktop is. Freedesktop is just a group of desktop developers that submit standards to each other, they don't really dictate anything. For that reason it tends to self-select for developers who are actively working on desktop environments, and the standards that tend to get submitted there are things that already have some level of adoption among open source desktops. You too can submit specifications to Freedesktop but you'll probably not have much luck with getting something adopted among peers if you're not already interacting with other desktop developers on a regular basis.

"Customizability" is also not the domain of a group that like Freedesktop that publishes specifications. Their purpose is to define some baseline of standard behavior for interoperability. The customization comes from individual projects. No offense but your criticism is pretty misplaced.

In theory it is that; in practice it has become a different face of Redhat because it's mostly Redhat developers that submit these standards there and the body is known to have a certain philosophy that is indeed exemplified by systemd.

They aren't particularly keen on hacking in how they design their software and standards and talking with them is frustrating to say the least.

I can't understand what you're talking about, I'm looking through the list of specifications and I don't see anything specific to Red Hat or systemd. I also see a lot of other names besides Red Hat people: https://specifications.freedesktop.org/

If Red Hat engineers submit something there it's because they think it's useful to the other desktop projects. It's just a collaborative space to put specs. If you have a spec of your own you can just create a new RFC. You don't need to persuade them to change how they design theirs, unless you intend to start working at Red Hat and start maintaining some of their software for them.

“People who write the code get to make the rules” is perhaps the most fundamental part of bazaar development ideology. If you don’t like it, write more code.

Writing more code does not always mean producing better software. Often it's better to just move to an already existing better software. For service management, there are many alternatives already.

> Writing more code does not always mean producing better software.

I didn't say it did! I said if you really buy into the "Linux is about choice", "Red Hat stole our fun OS" etc. bullshit that always circumscribes the populist anti-systemd position in these debates - then you don't really have a moral or tactical position other than "shut up and code."

I don't think that's true - I think there are other obligations to users which are just as important - but these all suggest systemd even more than the "master of my own machine" nonsense.

> you don't really have a moral or tactical position other than "shut up and code."

I don't believe that. People commenting negatively on some Linux software/trend do not need any such privilege or permission or show of stake. I think anybody with Linux experience is entitled to his/her opinion on what should and should not be done on their Linux machine and in the Linux software space, whether they produce new code or not.

That's just re-stating the grandparent comment! If you think everyone is entitled to their opinion then the only tangible way to express that opinion would be to produce new code. What use is the opinion if nobody ever implements it?

I don't believe that. There are many ways to express an opinion about Linux software, e.g. by writing about it, or by rejecting some software, or by adopting some different software.

I don't use systemd on my systems, I prefer sysvinit and openrc, and I sometimes express my arguments for why. Why would I have to write my own init system just to express my opinion that for some usecases, other software is better than systemd?

You've decided the best way forward for you is to write sysvinit and openrc scripts. That's an opinion completely focused around writing some additional code. You don't have to write it all from scratch to be expressing that opinion, you can express it a lot of different ways but that's all it encompasses. Unless we're talking about something else that I missed? Suggesting that something is better than something else is really meaningless without that.

People are writing code.

The difference is that everyone outside of Red Hat an Freedesktop isn't creating artificial dependencies on each other's projects to “gently push them” so people outside of it again have to write more code to decouple them again.

They did write the code to fork elongind in such a way that it no longer required systemd; they did write the code so that GNOME could run without logind like every other system; they did write the code to fork of udev from systemd again so that it could run without glibc. — None of these projects suffered loss of functionality.

They're complaining that they have to, because every time, these dependencies that have no technical justification happen, it's always one RedHat project depending on another to create product tying and encouraging adoption.

The rule of capitalism is simply that product tying works in practice, however bad it is for the user and consumer. That's why Apple likes to come with custom cables that only work on their hardware for no technical reason, and that's why logind was incorporated into systemd and came to depend on it for no technical reason.

> They did write the code to fork elongind in such a way that it no longer required systemd; they did write the code so that GNOME could run without logind like every other system; they did write the code to fork of udev from systemd again so that it could run without glibc.

It sounds to me like the bazaar system is working fine qua its own standards, then. Red Hat writes what they need to solve their problems, party X writes what they need to solve their problems, the code is shared, everyone gets what they want.

Except: It sounds like what you really want is for Red Hat to solve your problems, not only their problems. That's definitely not how this stuff shook out historically. And it opens a door you might not want to open, because now you need to ask yourself why users liked systemd, and what obligations you have to support beyond your own needs in your own software.

> It sounds to me like the bazaar system is working fine qua its own standards, then. Red Hat writes what they need to solve their problems, party X writes what they need to solve their problems, the code is shared, everyone gets what they want.

The difference is that Red Hat's problem is not making enough money, and everyone's problem is software not working because Red Hat breaks functionality to make more money.

Red Hat's “problems” are similar to the “problem” Apple experienced that that heir hardware was interoperable with third party hardware, so they made sure to use proprietary cables that only work with Apple hardware.

> Except: It sounds like what you really want is for Red Hat to solve your problems, not only their problems. That's definitely not how this stuff shook out historically. And it opens a door you might not want to open, because now you need to ask yourself why users liked systemd, and what obligations you have to support beyond your own needs in your own software.

No, what I want is for Red Hat to stop product tying, which you conveniently ignored and didn't address.

What they're doing isn't solving any technical problems any more than Apple is doing by using proprietary cables when standard cables suffice.

If you're asking for Red Hat to stop creating integrations between different parts of their distribution, that isn't going to happen. That's one of the benefits you get from being a distribution vendor. Every Linux distribution that grows past a certain size does that eventually, that's how you create a cohesive system. They make money from this because customers actually ask them to do it. You're essentially asking them to kill their core product.

Describing systemd as "product tying" is ridiculous. The product is the OS distribution. Even in the heady days of a dozen of diverging Unix vendors, nobody was pitching their user-pluggable init system. What's next, coreutils and busybox are illegal, because I don't want my `cp` and `mv` from the same vendor?

> the logind way is probably safer to abstract behind a user friendly GUI.

How so? The canonical solution would be to ship a default `lid_down` script that could take the currently-active policy as set by the GUI as an input. But the nice thing is that adding/tweaking policies is a fully-supported operation, you just edit the script and the GUI config mechanism to support them.

I just made an account to respond to this. Shipping scripts is racy and error-prone. It's the wrong approach and is not how any actively developed desktop wants to do things. They want an API they can use from a service, that's what logind provides and that's why it's been adopted. You can also run acpid alongside logind if that's what you prefer, but it will be racy unless you also use logind's inhibitor API.