awrmc

>GNOME3 and GTK3 didn't offer much to Linux desktop users, yet they were adopted.

Are we thinking of the same thing? GTK3 had a much better theming system, new widgets, support for high DPI displays, improved rendering, support for animations, and a lot of other things. GNOME 3 had a much more streamlined design too. You may not have liked them but there were plenty of new features to offer.

>I'll take wrestling a bug in a 400-line shell script to wrestling a bug in the systemd C code and compiling my fixed version.

I wouldn't, once you fix the bug in the C code it's fixed for everything. The bugs in the shell scripts keep needing to be fixed over and over again, because copying code around in shell scripts is really common. There is also a line to be drawn where low-level code should be written in C and I think this is well past that line. Service script code is usually privileged and runs as root so the utility of making it hackable seems pretty small. I expect you'd agree running bash scripts inside the kernel is a bad idea too.

I would say most of it is unnecessary buzzwords that don't help explain it. The whole thing can be simplified to something like "systemd is a task runner that has a dependency graph and transactions". That should also be fairly straightforward to you if you've used it a few times.

I'd say the other mistake the article commits is by trying to paint this as being a very complex design for the problem space. It's not when you consider the design constraints. You want services to have dependencies, and you want the updates to the unit files to be committed atomically to avoid stale data. Hence, the dependency graph and the transactions.

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.

>And why wouldn't you compare it with the systems it actually competes against and replaces rather than against something that was barely used any more before systemd even stated development?

I would say that's a meaningless comparison and those other systems were never considered as real replacements. At that time I don't remember OpenRC getting any traction outside of Gentoo, and the distros using Upstart were already unhappy with it. Adding to that, systemd explicitly was targeting distros that used a lot of sysvinit scripts and was intended to be used as an upgrade for them. It's largely succeeded at that.

I'm an open source hacker and I like systemd. Once I took the time to learn its APIs I found it does everything I expect.

Your issues with XFCE and libinput don't seem to be related to systemd. I can't see how airing grievances against other unrelated projects would be a constructive place to take this discussion. Complaining about open source projects only supporting some use cases is also confusing to me. A lot of these projects are very open about the fact that they exist only to "scratch their own itch".

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.

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.