Of course, but I would not like to have to patch it to modify something that on other systems can be modified with either a configuration option, or a shell script.
To me, the most poisonous example that contrasts the traditional design with Freedesktop's design is acpid contrasting logind. In the former case, an acpi event is sent, and acpid simply executes a file such as `/etc/acpi/action/lid_down.sh`. That file can contain anything the system administrator wills, from a simple script that does nothing more than `systemctl sleep` to whatever complex task he could desire.
The last time I checked the situation, logind had replaced this powerful, and simple mechanism with a configuration that offers nine options to execute when the lid is pressed, none of which involve executing a simple file. Of course I can edit the source code and recompile to allow it to do what I want it to, but I would far rather simply quickly alter a simple shell script to do so.
And luckily I can, because I do not use logind but acpid, but that does not change the ire I experience when dealing with many Redhat and Freedesktop people who make it very clear that I should be using logind, that it's better, and that they create artificial dependencies on it to as Poettering calls it “gently puh” me in that direction.
And this means we can’t do things like force disconnect an eGPU or whatever on acpi events.
I think I figured out my issue with systemd. It does not apply Chesterton Fence when redeveloping things… and how could it, when it redevelops so much.
Maybe it’s fine if it’s all you’ve ever know (or you never hacked on your system) but those that did have lost something.
The situation is that such hackers and tweakers rarely use systemd, for these reasons.
They are simply annoyed by A) it being pushed on them; B) people often acting that they are irrational for not liking it while it does not what they expect and need; and C) discussions with Freedesktop developers that, frankness be, reveal they live inside of a very strange bubble and have no idea of the use cases outside of it.
This is software brought to you by the minds who brought you. “I have no idea what XFCE is or does, sorry.” or that libinput did not need a way to disable mouse acceleration because everyone wants mouse acceleration.
> libinput did not need a way to disable mouse acceleration because everyone wants mouse acceleration.
You mean you want a flat acceleration curve? You want to accelerate the mouse, otherwise you need a gaming mouse with the DPI set very high and then keep going into the mouse firmware to adjust the DPI whenever you play a game or switch between different (scaled) resolutions. Libinput has different acceleration profile defaults for different devices, but you can just change it to the flat profile which I prefer as well.
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".
I have no issues with XFCE. I personally would never use i, but it also leaves me alone and it's developers don't exhibit this mentality.
I have a problem with Jon McCann's famous quote, who was at the time a lead developed of GTK+, who did not know what XFCE, one of the biggest consumers of the library, even was when he made a change that broke about anything outside of GNOME. — What his language suggested was that he lived in a bubble thinking that only KDE and GNOME existed, and that since KDE wasn't using GTK+ it was fine to do this.
The ticket is about GNOME 3 removing support for status icons from the GNOME panel. GTK3 still has the status icon API, although they're deprecated and don't work on Wayland. That shouldn't have any effect on XFCE or any other shell with an old panel that supports the old X11 status icons. I think you can also restore the functionality to GNOME with an extension.
Also, if you check further down the issue you'll see this clarification:
>There should be no change in behavior for non-GNOME platforms.
This is a peculiarity of the GTK developers, not anything to do with systemd or fd.o. I maintained a popular GTK-but-explicitly-not-GNOME application long before the days of systemd and they had the same attitude.
I believe it is common to pretty much all Red Hat and Freedesktop developers.
Poettering has come with very similar claims that betray that he does not understand what people outside of his small circle want and need, the same can be said for Wayland developers, DBus, NetworkManager, PulseAudio and all such other infamous projects.
It's difficult to understand what your complaint is, that describes every software project I've ever seen. You pick a target set of users and then develop for those users. Is there some other way to develop software?
I don't think it is common to find memorable quotes akin to “I have no idea what XFCE is or does, sorry.” outside of this circle. This is a vintage and often quoted Red Hat-ism that betrays their mentality.
QT developers will not tell you “I have no idea what LXQt is or does.”; they do not generally break things that compromise 90% of their consumer base and they do not remove theming because they fear it's existence will hurt the “brand identity” of KDE.
It's dishonest to say similar problems occur outside of the Red Hat circle and that circle alone is commonly criticized on these policies.
If you're trying to prove a point, you could at least mention something that actually caused a real problem instead of taking this one out of context. I have no idea why anyone would keep mentioning this quote or find it memorable, it seems completely insignificant to me. You also seem to be ignoring all the positive interactions this engineer (or any other Red Hat engineer) might have had. I can personally name a lot of instances where Red Hat engineers have fixed upstream bugs that were affecting me. And just to make it clear I'm not saying this to single them out for praise, a lot of other companies fix upstream bugs too. That's how open source is supposed to work.
And you actually could go and search around on old mailing lists to find similarly questionable 11-year-old quotes from Qt developers if you really were interested in digging up more old drama. These things happen everywhere that people go because people don't agree on everything. I suspect you also think that's ultimately futile though, so why keep flogging this particular dead horse? This is still way, way outside the scope of discussion for systemd anyway.
If your problem is with the Red Hat developers, and the fd.o developers, and the GTK developers, and the Debian and Arch and SuSE and Ubuntu developers, and the DBus developers - maybe your problem is not actually with any of these developers but a mistaken idea of how open-source development ever worked?
Or what, is everyone except you under thrall to Lennart Poettering, master wizard?
I'm replying to a post in which you specifically called out Wayland and D-Bus, and your criticism of GTK and fd.o is all over this thread. Your lack of criticism of SuSE developers appears to be because you misremembered when/how they switched to systemd - because they did, relatively quickly.
But that raises the real question: If the problem is systemd, and the problem is so bad, why do you only blame Red Hat and not the every other distribution that switched to it? Do you think they were all victims of Tricksy Lennart, or?
> I'm replying to a post in which you specifically called out Wayland and D-Bus, and your criticism of GTK and fd.o is all over this thread. Your lack of criticism of SuSE developers appears to be because you misremembered when/how they switched to systemd - because they did, relatively quickly.
And you also brought in SuSE, Arch, and KDE, which I never criticized to make your argument that I simply hate everything work, which is quite disingenuous.
> But that raises the real question: If the problem is systemd, and the problem is so bad, why do you only blame Red Hat and not the every other distribution that switched to it? Do you think they were all victims of Tricksy Lennart, or?
I do not, and have never blamed distributions for switching to systemd.
They can use what they want and it's neither their fault nor problem that systemd and other Red Hat projects are known to create dependencies upon one another for ill technical merit.
I have criticized Red Hat projects for creating dependencies on other Red Hat projects for political, rather than technical reasons; the rest is simply your putting words into my mouth to make a straw-man argument function.
I haven't seen any of these supposed Red Hat projects that have dependencies for political reasons. If that were really true then it would be trivial for anyone to remove those dependencies, and there wouldn't be anything for anyone to complain about. Any way you slice it doesn't seem like a cause for alarm.
acpid vs logind is another illustration of the trade offs involved when moving towards GUIfication of the bazar that is (was?) unix.
Basically the proposition is akin to a weapon exchange program: hand over your powerful but dangerous Turing complete configuration language in exchange for nicer looking desktops.
It's what you consider nicer. I consider dialog windows to be a slow and frustrating way to configure anything and on top of that in this case it loses me the ability for my computer to do what I want it to when I close my lid.
And if it simply remained at that, but left me alone I wouldn't be so irate, but I don't feel left alone and “Who would not prefer a better looking desktop?” already borders on this “My way, of the highway.” philosophy of Freedesktop, whose developers all too often tell one that one's subjective likings are wrong and that one is somehow “wrong” or “outdated” for favoring a machine that is fast to configure and does what one wants.
It also doesn't help much that on a purely visual level there design choices look ugly to me, and that these are also the same people that remove theme options lest the holy “brand identity” be compromised, as well as that their design blasts too much bright white light into my face when I'm already tiring my eyes out trying to learn to read a language that's not written in a script I'm accustomed to.
I believe this issue of Turing complete config language vs simpler declarative configuration is one of the basic thing for which there exist no good universal solution.
I face the very same issue in my day job where I'm struggling to cut the right balance between a featureful data manipulation language with which the customer can implement whatever he needs, as long as he is OK with a bit of programming, or a more limited one for which we have a GUI... and that GUI itself has to be tested, and I'm also currently reviewing QA tools to help testing GUIs, and they basically fall in two camps: those that require one to spend a week learning how to program them, and those that are much more limited but come with a straightforward GUIs...
Before systemd the same conflict happened with network-manager: my network setups were usually custom and out of reach from network-manager that I despised and purged of my desktops first thing after a fresh install. Yet with time network-manager supported more and more use cases and I'm now happy to use it. Maybe one day systemd will also make it possible to add the bits of hackery here and there and we will all be satisfied with it.
For now, if so many users have it easier thanks to systemd, which seems to indeed be the case, then it's still something.
> I believe this issue of Turing complete config language vs simpler declarative configuration is one of the basic thing for which there exist no good universal solution.
Indeed there isn't. And people that want simpler declarative configuration files can have them as far as I'm concerned.
My ire is the mentality common of Red Hat employees that I am wrong for wanting traditional Unix-style flexible configuration and their dependency politics to try to get others to switch over. If they just designed their software how they want to and otherwise let it be, such as KDE and XFCE are doing, then they would not be drawing the same criticism, but they have a tendency of coming with a dismissive attitude to everyone who wants it different than they do and insist their way is the future and when people point out that their way does not offer functionality they need either for convenience, or their livelihood they dismiss it.
> For now, if so many users have it easier thanks to systemd, which seems to indeed be the case, then it's still something.
If various Red Hat projects didn't find a way to create dependencies on systemd to encourage it's adoption and systemd was simply there for the people that wanted it but left those that didn't alone, then it wouldn't be so controversial.
What I quoted was “Who wouldn't want [...]”; that's the Red Hat mentality, that everyone who has subjective ideals than they either does not exist, or is wrong.
>If they just designed their software how they want to and otherwise let it be
In my experience, that is what they're doing. Their software just happens to be adopted by more users because in a lot of cases it is better and does represent the future. You have that advantage when you support a lot of commercial users over a long period of time. Red Hat also has a policy of contributing a lot to upstream so that also adds to why they have success with other projects.
>If various Red Hat projects didn't find a way to create dependencies on systemd to encourage it's adoption
I think this is an exaggeration. I haven't seen any projects that have anything more than a trivial dependency on systemd to enable some optional functionality.
Although I like the acpid approach, the logind way is probably safer to abstract behind a user friendly GUI. That's what most people will be using. :-/
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.
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.
To me, the most poisonous example that contrasts the traditional design with Freedesktop's design is acpid contrasting logind. In the former case, an acpi event is sent, and acpid simply executes a file such as `/etc/acpi/action/lid_down.sh`. That file can contain anything the system administrator wills, from a simple script that does nothing more than `systemctl sleep` to whatever complex task he could desire.
The last time I checked the situation, logind had replaced this powerful, and simple mechanism with a configuration that offers nine options to execute when the lid is pressed, none of which involve executing a simple file. Of course I can edit the source code and recompile to allow it to do what I want it to, but I would far rather simply quickly alter a simple shell script to do so.
And luckily I can, because I do not use logind but acpid, but that does not change the ire I experience when dealing with many Redhat and Freedesktop people who make it very clear that I should be using logind, that it's better, and that they create artificial dependencies on it to as Poettering calls it “gently puh” me in that direction.