Systemd pissed off many people. For me and most users, the transition was fully imperceptible. With the difference that systemctl tools seem to work better for what it does than the many sparse different tools it replaced.
I am considered a Linux expert in my field but the truth is that I really don't know how systemd internals work well enough to read that review and fully understand it. The review did teach me some things about what Units really are, more than just services and timers, but other than that it was too deep for me.
And yet I work full time with Linux systems, building services on Linux systems for major clients and government contracts.
From my perspective as a user and operator of Linux, systemd has been nothing but good things.
There is strange false history that systemd replaced sysvinit, which occurred only on Debian, because Debian was the last major system to discard sysvinit.
Gentoo had replaced sysvinit with OpenRC in 2006; Fedora and Ubuntu were using Upstart in 2005. systemd primarily replaced Upstart and systems that used Runit or OpenRC tended to have stayed with them.
Frankness be, this false history seems to be crafted in order to compare it with very outdated technology to make it look good. Obviously systemd is better than sysvinit, technology that almost all systems but Debian had discarded long before systemd was even started. The issue is whether it compares favorably to Upstart, runit, and OpenRC, and to the first I would say yes, because Upstart was full of very ugly hacks and didn't deliver it's ambition. In the second two cases, their mode of operation is so different that it's hard to compare. runit was inspired by daemontools and is very simple and effective and works in a very different way from most models of service management; OpenRC is backwards compatible with sysvinit and is essentially a large library so that init scripts typically need nothing more than something such as:
#!/sbin/openrc-run
command=sshd
args="-D"
daemon=no
provides=ssh
after=net
The previous gentoo init system was already better than sysvinit and initscripts.
I still prefer and use systemd though.
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? The comparison with sysvinit, suggesting that those that do not use systemd advocate sysvinit instead, is simply a flagrant straw-man designed to make systemd look good.
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.
So the year you're looking for isn't when OpenRC was introduced, but rather when Gentoo started using the OpenRC style of init script, which happened much earlier - it's definitely been like that since I started using Gentoo, at least since 2003 or so.
It's actually a misconception that sysvinit is the whole init system; sysvinit is PID 1. Gentoo still uses sysvinit for PID 1 by default. What matters is what your service manager is - that's OpenRC here.
But on the desktop I use FreeBSD which has a different system again.
By the way alpine is also working on a full service manager init system (like systemd) but more minimalistic, based on s6 service manager. Looking forward to seeing how that pans out.
https://skarnet.com/projects/service-manager.html
When something comes from the alpine team I have a much higher confidence that I'll like it than from RedHat :) I don't care for Gnome either as it has become so opinionated.
I would add S6 to the list, as this would be the better challenger to systemd. That said, I use OpenRC daily on Alpine servers with little to complain about.
This is partially incorrect and partially misleading.
Incorrect in that openSUSE and Arch are major distros and migrated from sysvinit to systemd.
https://news.opensuse.org/2011/12/22/systemd-e2-80-93-boot-f...
https://www.reddit.com/r/archlinux/comments/4lzxs3/why_did_a...
Misleading in that Ubuntu and Fedora did use Upstart but not in its native mode, they used it in its sysvinit compatibility mode. This is almost identical to sysvinit, so from the point of view of a user or a package maintainer it was functionally barely distinguishable from sysvinit.
OpenRC was considered by Debian, but 7 out of 8 members of the technical committee preferred both systemd and Upstart to OpenRC (Ian Jackson preferred sysvinit over OpenRC and "further discussion" over every other option).
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=727708;msg...
OpenSUSE also had upstart in the meanwhile but continued to support sysvinit as an alternative.
Arch Linux had sysvinit as it's pid1, but it's big sell initially was that, similar to Crux, it had a custom BSD-style init script setup and did not use sysvinit's booting and rc mechanism.
OpenRC systems typically also continue to use sysvinit's pid1 to this day, which is not the complaint people have with it but the impossible to understand script sand lack of dependency management of it's service management because it was never meant to do service management which was a bit of a hack.
> Misleading in that Ubuntu and Fedora did use Upstart but not in its native mode, they used it in its sysvinit compatibility mode. This is almost identical to sysvinit, so from the point of view of a user or a package maintainer it was functionally barely distinguishable from sysvinit.
There is no such compatibility mode as far as I know. A big sell of Upstart and OpenRC was always that it was backwards compatible with old-style sysvinit-style scripts even though new ones were written in the new style. There is no global mode as far as I know but no doubt many of the olds scripts remained.
> OpenRC was considered by Debian, but 7 out of 8 members of the technical committee preferred both systemd and Upstart to OpenRC (Ian Jackson preferred sysvinit over OpenRC and "further discussion" over every other option).
That would not surprise me. It's not what Debian is looking for.
I wasn't aware of that ... it turns out that it was the other way around: openSUSE 11.3 has this item, implying it's not the default:
"Upstart is included as optional init system"
https://en.opensuse.org/Archive:Product_highlights_11.3
openSUSE 11.4 then mentions systemd, although "experimental".
https://en.opensuse.org/Archive:Product_highlights_11.4
openSUSE 12.1 defaults to systemd (see previous comment), with sysvinit as non-default option.
So Upstart was a short-lived non-default option.
> A big sell of Upstart and OpenRC was always that it was backwards compatible with old-style sysvinit-style scripts even though new ones were written in the new style.
You are right that there are no distinct modes as such, my memory is quite fuzzy as it's been some years, and I wouldn't rely on anything I say. And it looks like Ubuntu (unlike Fedora) did replace a lot of init.d scripts with native Upstart jobs.
https://launchpad.net/ubuntu/+spec/replacement-initscripts
I can't remember what the problem was with mixing init.d scripts and native Upstart jobs, or what impact it had, maybe it was not important in practice.
The Debian wiki has this item, but, well, it's a Wiki, so perhaps it's not the most reliable source.
Can't set proper dependencies until everything has converted from SysV init files to Upstart jobs.
At 82k loc it's huge for what it does, but nonetheless is order(s?) of magnitude smaller than systemd. If it was active I'd trust it more that systemd on that basis alone.
I can't say I'm a fan of systemd's event driven approach. A system whose state depends on it's configuration plus past state is usually a nightmare to debug and control compared to a system who state is dependent on it's configuration alone - and that's how it has worked out for me and systemd.
The simple cases work fine of course but systemd's power over what came before it is it's dependency relationships it allows you setup. But they are the very things that break in weird and wonderful ways when the events it's reacting to fire in an unexpected order. If you could set them up reliably without much thinking it would be a big win - but as it is, not so much.
The vast, and I mean vast majority of distros used SysV before transitioning to SystemD
Also upstart, which was actually pretty good, but systemd was more ambitious.
Additionally Upstart was not good. It has some good ideas but its approach to dependencies was generally regarded as unintuitive. Writing services in systemd is much more obvious than writing for Upstart.
If you spend an afternoon installing it and configuring a few network services, you’ll already know most of what there is to know about how init used to work.
It used to be extremely elegant and robust.
The main flaw in the design was that the “service” files were written in a Turing complete language, which meant that distribution maintainers could ship things that were arbitrarily terrible, and many chose to do so.
(Edit: Also, the organizations that somehow couldn’t figure out how to use and maintain traditional init systems were the ones that produced the current generation replacements and pushed them so hard.)
This is revisionist. The organizations that built the current generation were those who had to support those who couldn't figure out how to use and maintain "traditional" init systems. Distro init scripts were (usually, and at great effort) decent, whether from Red Hat, SuSE, Debian, etc. (just don't ask too hard about why they were different). But the third-party (often, but not exclusively, proprietary) software vendors looking to support even a single distro were godawful. Eventually the support burden for e.g. Red Hat got large enough it made more sense to replace it wholesale than keep mentoring the latest batch of e.g. Oracle interns in how to write half-decent shell scripts.
For example, one of my Void flavored machines is using runit: 11 tasks; but a freshly booted headless Debian using systemd: 95 tasks... and that is with a massively slimmed down, purpose built, kernel. Abstractions atop abstraction... the amount of waste in the pursuit of generality has to stop - if this silicon shortage doesn't do it nothing will.
A normal user will never really link the features they see or do not see back to the init system. I'll draw a parallel with the worst subsystem being cut out of modern Linux - X Windows.
As far as I can tell Linux is missing good macro systems that can record actions taken by a user, then replay them. For loops for non programmers, basically. This isn't because the idea is radical, but because implementing the vision historically needed a programmer to understand X - which is too hard. There is a hidden link between the subsystem being awful and programs not existing.
Similarly, the monoculture created by systemd is influencing how the future of Linux evolves by making some things easier and others harder. End users won't be able to detect those influences though, and unlike X's problems systemd is likely a net positive. Systemd easily improves on the old init scripts.
While I agree with the broader point about (any) monoculture, I don't think that this can be blamed on systemd.
Systemd did not itself create the monoculture. When it came up, it was one of a multiculture. Distro maintainers then chose it en masse so that it became a de facto monoculture.
I'm not saying that necessarily makes it the best choice, though.
On a slightly different note, I find such comments funny in a way, because one of the reasons given for Linux's lack of market share on "the desktop" and, broadly, as a platform for "enterprise" software (think Adobe, etc.) is because the ecosystem is so fragmented. So, essentially, the platform isn't considered because it's not a monoculture (as would be Windows and Mac).
systemd became the de-facto default init sys because Distro Maintainers have chosen it. I posted this link here before, but I will happily post it again: https://www.reddit.com/r/archlinux/comments/4lzxs3/why_did_a...
Such a thing doesn't happen if the thing offered isn't an improvement over what was before.
As a matter of fact, this doesn't even happen if the thing offered is only a small improvement. We have seen this time and time again in Programmig languages: Exciting, clever new things that offer real advantages vanishing into obscurity because while they were better, they were not better by a large enough margin.
Diversity is great if it offers advantages. Different kinds of RDBMS are a good example. Different kinds of shells. Rust being there as a C alternative, Go being there as a Java alternative, Julia as a possible Python alternative, WASM instead of JS. All great.
But keeping something mainstream just because its different, adds no value. People can and do still use other init systems, but I am very glad I no longer have to wrestle 400-line sh init scripts on my production servers.
It does happen sometimes. GNOME3 and GTK3 didn't offer much to Linux desktop users, yet they were adopted.
And improvement is subjective. Maybe systemd made maintainers' lives better. But it also introduced big nasty software full of bugs that discourages hacking by users. Many users consider that a deterioration of the Linux ecosystem.
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.
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.
Fixing a bug in shell script, even if 30 times, is still much easier than downloading, understanding modifying and compiling and deploying 4000 files and 1.6 million lines of systemd C code. There is an obvious cost/benefit factor here.
If systemd fixed just init and basic service management in correct and minimalistic way, maybe fixing its C code here and there by power users would be rational. Not with the ever-expanding pile of prototype-level software we got. I'm not reading that code, not even for money.
For desktop app developers? There were a lot of API refinements and enhancements to the widgets too, I didn't mention them all because there's far too many.
>4000 files and 1.6 million lines of systemd C
Just FYI these figures are incorrect, you're likely including the tests, documentation and data files. Running cloc on the current systemd code base I get around 2100 .c and .h files and 520,000 lines of C. That also includes all the other components too, not just the service manager. The service manager is a small fraction of that, it's only around 150 files including the headers.
>There is an obvious cost/benefit factor here.
From the perspective of a distribution I think it's much more cost effective for them to fix this once in C. To you what looks like just 30 shell scripts can quickly multiply into the thousands when you have to consider this is across all users of that distribution who might all have the same buggy set of 30 shell scripts but with different ad-hoc fixes applied.
>If systemd fixed just init and basic service management in correct and minimalistic way, maybe fixing its C code here and there by power users would be rational.
I think if you actually look at it, you'll find this is already what it does. That's what I saw when I actually took a few hours to familiarize myself with the code.
If a bug happens in this code, everything is affected, everyone screams at the same time, it is obvious there is a bug, and once its fixed, its fixed everywhere and for every service.
If there is a bug in one of the old init scripts, it may go unnoticed for several years, until suddenly someone needs service Bar depend on Service Foo, but Bar cannot figure out the state of Foo correctly, and good luck to whoever has to solve this: unless the combination of services is a popular one, whoever has this problem, is likely the first to encounter this, there is no general outcry because nothing else is affected by it. A fix may not be forthcoming because the behavior may not even be considered a bug (the maintainers of Foo and Bar may simply disagree how some service state is to be communicated), and usually someone has to trawl through a pile of sh scripts (because backward compatible all the way to the 90s it has to be!) and implements a fix, which then gets destroyed by an update when the guy who fixed it is on holiday.
As someone who has been that exact guy, I have to say sorry but no, I don't want to do this any more.
Shell scripts are tunable to the specific system. If a rare bug is in a shell script, I can usually find and fix it, unless the script is insane, in which case I can write a sane one.
If a bug is in systemd, I can't easily fix it myself. I now have to fight upstream to recognize my issue and fix it for me. I don't have a good experience with this. Nowadays I'd rather write a small script to work around that bug if possible. Much faster and much more effective.
That's not true. You can do as you would with the shell script and patch it in your local copy. If this is too much hassle then that shell script workflow shouldn't be broken by systemd and you can always fall back to it. It's still possible to run shell scripts as systemd units. You could also run another service manager as a systemd unit as another workaround.
Also, in my experience, if you're fixing an actual crash, those patches are really likely to get accepted. Upstream appreciates that, I haven't seen them fight anyone over an easily verified issue. If you're submitting giant 10,000 line patches that change the public interfaces and cause regressions, that's a different story.
Because they were forced to choose it due to vendorlock and many other projects became dependent on systemd. Unsystemding everything would be very expensive.
Same problem will be with snap and flatpak.
Snap and flatpak are essentially just package managers, I can't see why you would expect those to be worse than any other package manager.
> Snap and flatpak are essentially just package managers, I can't see why you would expect those to be worse than any other package manager.
Those are even worse than tarball bundles. Main purpose of both overengineered projects is to tie users to vendor's services (snapcraft, flathub, e.t.c.). Centralized delivery is outmoded, future is decentralized distributed distribution. Both package managers deprive me of control over my system. I don't like the aggressiveness with which these projects are enforced. When Let's Encrypt switched to Spat as the only official distribution of their tool, I had to switch to alternative tool acme.sh instead of installing bloated snapd on my server.
Under some circumstances (not all), GNOME has a dependency on logind. If you're in one of those circumstances, you can use elogind as a drop-in replacement. That's far from having a dependency on systemd.
>Main purpose of both overengineered projects is to tie users to vendor's services (snapcraft, flathub, e.t.c.). Both package managers deprive me of control over my system.
I don't think snap lets you deploy your own repository, but for Flatpak this is very very wrong. Check here: https://docs.flatpak.org/en/latest/hosting-a-repository.html
yes, it's still open source, but modifications and inspection are far more complicated creating a much higher barrier to entry.
in the earlier days when it was still buggy, even linus himself was screaming about not being able to easily take the case off of pid 1 when it misbehaved.
I’m waiting for Microsoft to buy Red Hat. Failing that, IBM.
I doubt they will though. Like others have said MS buying Canonical would make a lot more sense. And there have already been a lot of overtures.
The UNIX philosophy isn't meant to be taken as gospel - hell, it's very hard to define what "doing one thing" even means.
Yes.
Emacs development began during the 1970s at the MIT AI Lab, whose PDP-6 and PDP-10 computers used the Incompatible Timesharing System (ITS) operating system that featured a default line editor known as Tape Editor and Corrector (TECO)
GNU Emacs later (1984) was based on Gosling Emacs (1981), which was written in C and extended with Mocklisp. Mocklisp was a rather uncomplete Lisp, which was replaced with Emacs Lisp by Richard Stallman.
I use MacOS and iOS for internet viewing and A/V. I have no interest in how they are implemented - superficial observation indicates they are a mess. I do ssh into my servers from MacOS - it's comfortable with my laptop actually in my lap.
There were several init replacements in the mainstream before systemd. OSX and Solaris both had their own, and they were as UNIX (officially certified) as you can get.
Also, as long as we're doing non-sequitors; Microsoft is more likely to buy Canonical than they are to buy RedHat or IBM.
The piece of software systemd is most like is launchctl, which doesn't come from Windows.
On the other hand, the biggest "Windows-ism" to reach Linux lately is io_uring. But it's both too technical and too useful to have some populist uprising against it.
I don't care about the init system - I reboot a Linux system once in a blue moon, for kernel updates. It's the rest of the complication and changes to a system that I had already made the effort to master. I understand that the New Linux is better for Enterprise, so that's what is going to happen. That doesn't mean I have to like Poettering gradually re-writing the entire base of userland. I just want to run simple servers, not a major enterprise.
The biggest problem I had was that it was difficult to keep upgraded. In those days, it was basically a re-install every six months, plus a merge of any local changes. I understand things are much better now, and I may give it another try.
I would argue that locked and pentalobe metaphor is not very accurate - systemd is no more locked than most other open source software.
Personally, I was more of a fan of upstart then systemd, but both were a massive improvement over sysvinit in terms of offering an actual interface with abstractions for the things you wanted to do. This is again from the perspective of a user, but that's where (in my opinion) most of the cost/benefit was anyway.
A monorepo containing well-organized boring C, developed on github of all places, is the polar opposite of raising the barrier to contributing vs. what was replaced.
Full-disclosure: I contribute to systemd.
But, like some other comments have said, I was young enough to dodge the drama. I basically grew up with systemd and I don't feel like I'm missing anything. The biggest problem I have is that Ubuntu Server defaults (or used to default) to having the system wait on network interfaces, which is annoying when I want to build a desktop off of it. And sometimes on shutdown it waits for some daemon I don't care about to quit. Which is probably just a bug in the daemon.
But now that things aren't buggy, being unable to modify them in place is a good thing. It sets a clear boundary that this is not how you do things on a modern system, so you can always expect systemd to be the same, consistent, non customized thing it always is.
i'm not going to argue it's a bad thing, i actually really like macs and think they hide a lot of details making time and space for other pursuits, although since you cede user serviceability it's important to purchase a service plan and that you don't try anything that wasn't provided for in the design.
maybe simple composable parts are past their prime. i always loved the simplicity of inetd. it was both self describing and inclusive. you could write an internet service without any knowledge at all of sockets and learn about the system by simply looking at it. but i suppose that's given way to large monolithic daemons these days.
personally though, i always thought the simplicity and the composability of unix philosophy was what bred systems that outperformed their competition in terms of security and extensibility. so many commercial systems reflected apparent power grabs within the corporate structures that produced them... i suppose that when you see foss monoliths like this, it's the same game playing out on a different field.
You could achieve the same thing with systemd socket activation :)
neither. last i checked, linux, even with rt_preempt, was unsuitable for realtime control applications.
even hollywood gets that, didn't you see the end of "don't look up"?
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.
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.
"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.
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.
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.
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.
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.
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.
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.
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.
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?
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 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.
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.
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 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.
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.
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.
Or what, is everyone except you under thrall to Lennart Poettering, master wizard?
I have very specifically only criticized Red Hat developers. I have no problem with any of the others and they don't show the same problems.
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?
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.
https://trac.transmissionbt.com/ticket/3685
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.
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.
See https://wayland.freedesktop.org/libinput/doc/latest/pointer-...
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.
Who would not prefer a better looking desktop?
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.
-- Sent from my terminal
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.
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.
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.
Systemd may indeed be somewhat more complex, but I don’t think that it would employ many accidental complexity— it is complex due to the problem domain. But imo that is a worthwhile thing to spend complexity budget on.
There is absolutely no need for its command names and everything else about it to be so counterintuitive.
Exactly this, yes; and that's why it was pushed the way it was.
I dread the day when systemd or an init system just like it consumes the BSD world.
Do yourselvs a favour and pick Postgres for new projects. If you properly vacuum your tables you'll probably be fine.
Git has the same problem but at least git is excellent enough software in other ways that it makes up for the horrible UX. Systemd is mediocre.
systemd-cgls
> How do I list units
systemctl list-units
Simply use tab completion (like in zsh). And do not dare to compare UX-nightmare from git with systemd...
So far. I hope for your sake it continues to be so.
I actually appreciate, now, what systemd is trying to do, but I am not certain why it has to take over home directories and everything else to do it. And I am really uncertain why it has to have such bad taste. I can get why it uses C, even though IMHO that is a mistake. But .ini files? D-Bus? XML‽‽‽
Oh well, at least it's not YAML.