Introducing stronger dependencies on systemd(blogs.gnome.org)
blogs.gnome.org
Introducing stronger dependencies on systemd
https://blogs.gnome.org/adrianvovk/2025/06/10/gnome-systemd-dependencies/
176 comments
There's so much I disagree with in the beginning but the ending is what actually grinds my gears. You make it sound like systemd manufactured this monoculture somehow. This is also the point I've seen people throw in a comparison to some closed-source org with money to burn and questionable morals.
Systemd was chosen by distros and users across different communities because it solves hard problems better than the others. We can debate about why that is, but the maintainers of Systemd aren't running smear campaigns against other open source projects. Often systemd is the subject of such ire.
They chose to solve hard problems and people adopted it. It's not anything more sinister. It's definitely not an "un-auditable mess". It's written in well formatted C with structure, good tooling, and an open community. You can disagree with the ideology but that's open source for you.
Additionally and away from my point, I believe that Systemd won our because they chose to embrace some complexity to solve really hard problems. Let's not pretend that a modern "init" does only system initialisation by calling shell scripts and then disappearing.
Systemd was chosen by distros and users across different communities because it solves hard problems better than the others. We can debate about why that is, but the maintainers of Systemd aren't running smear campaigns against other open source projects. Often systemd is the subject of such ire.
They chose to solve hard problems and people adopted it. It's not anything more sinister. It's definitely not an "un-auditable mess". It's written in well formatted C with structure, good tooling, and an open community. You can disagree with the ideology but that's open source for you.
Additionally and away from my point, I believe that Systemd won our because they chose to embrace some complexity to solve really hard problems. Let's not pretend that a modern "init" does only system initialisation by calling shell scripts and then disappearing.
All of us paying attention saw how the systemd authors shopped their stuff around issue trackers and mailing lists telling everyone "it's just the way it is now." They absolutely did manufacture the situation. They pushed hard enough doing this that it's resulted in multiple large distros being forked by groups of former maintainers.
Oh my god, they told other people they are developing open source software and that they like their own software. Say it aint so. Have we informed the authorities about this?
Care to share any evidence to back up the tall claim that systemd authors forced their code on anyone?
The claim was "shopped around" and if you are going to change people's words do not be surprised when nobody takes your challenge. And preemptively: absence of evidence is not evidence of absence.
What does "shopped around" mean? That's not a common or accepted idiom for code. Or not one I've come across anyway.
Also show me evidence of them "shopping around" code. I'll wait.
Also show me evidence of them "shopping around" code. I'll wait.
Truly, don't bother. I've been watching this conversation play out for 10 years. I've watched it play out with systemd, udev, rust, Wayland.
Just ignore them. Their validation is meaningless. Their ignorance is mostly meaningless, too, for reasons that feel mean to type out.
Just ignore them. Their validation is meaningless. Their ignorance is mostly meaningless, too, for reasons that feel mean to type out.
I'm getting the sense that both sets of parties here have a strong opinion and that this isn't a real discussion because of that.
Strong opinions don't make something not a discussion. Announcing to the room how aloof you are though does make you not very aloof.
Yeah my strong opinion is that I have better hidpi support than any other platform, no tearing, ever, a better security model, the x devs have abandoned x11. They have accessibility (which I am completely sympathetic to, but is rarely the actual point) and a bunch of hand waving neck beard bullshit.
I have worked on DEs, I have committed to compositors. I know which side has more merit.
I have worked on DEs, I have committed to compositors. I know which side has more merit.
My task here was to reprimand you for arguing disingenuously, not to teach you language or do homework for you. What an appallingly entitled way to carry yourself.
> absence of evidence is not evidence of absence
After holding up well for a long time, absence of evidence becomes a good indicator for actual evidence of absence.
After holding up well for a long time, absence of evidence becomes a good indicator for actual evidence of absence.
[deleted]
> good tooling
My completely oblique, binary logs disagree. It won because it solved problems companies with money needed solved. There is no indication that it succeeded on merit.
My completely oblique, binary logs disagree. It won because it solved problems companies with money needed solved. There is no indication that it succeeded on merit.
There are pros and con with binary logs. One isn't magically better.
The tools they have for their logs are pretty good, and its incredibly easy to disable, if you do, you will never notice a difference.
Helping engineers solve technical problems is not 'success'? Its only 'success' if open source nerds use it in their basement to run on an old sun workstation? What kind of dumb logic is that?
Why do you think Linux sees so much development?
The tools they have for their logs are pretty good, and its incredibly easy to disable, if you do, you will never notice a difference.
Helping engineers solve technical problems is not 'success'? Its only 'success' if open source nerds use it in their basement to run on an old sun workstation? What kind of dumb logic is that?
Why do you think Linux sees so much development?
Logs that I can read are objectively better. I must assert that point because it is true.
Ths only issue that non-human readable log storage has caused is the endless nagging on forums. Literally never been an issue besides.
literally has, or there would be no "nagging". I have yet to experience a benefit for those binary logs
I'm interested in your idea that "merit" is some sort of objective measure.
If it works for me but not for you, does it have more merit?
If it works for me but not for you, does it have more merit?
Some anecdotical evidence of mine. I tend to kill -9 Firefox or derivatives before system, or browser updates, to reliably get my tabs and cookies (for selected sites) back, without the need for any extensions.
Usually I'm doing that from within htop, or btop++. Under systemd that is slow, the process-tree of FF takes several seconds to vanish.
That felt very wrong. I increased the update frequency of htop and btop++ to 200ms (usually they poll/actualize/redraw at 2 seconds only) to investigate.
Then I retested that with Runit/S6(6) on the same systems.
Magic! The process-tree is instantly gone! And if you only SigHup it, it instantly reappears. BAM! BAM! BAM!
This applies to all sorts of process-trees also, not only FF.
Compared to that systemd feels like a sloth.
Yes, Yes, I did that under several different distros, initially AntiX, recently "init diversity edition"(Debian derivative optimized for 'live-booting', running from RAM, in all sorts of 'Frugal' installs), some Arch-derivatives, sometimes 'riced' to the max, and default Debian, just to be sure.
Over several years. Initially on a Core-i7 640LM with only 8GB RAM, more recently on Core-i5 7500t, and Core-i7 7700t with 32GB RAM.
Verdict: systematically slo(w)thified.
Usually I'm doing that from within htop, or btop++. Under systemd that is slow, the process-tree of FF takes several seconds to vanish.
That felt very wrong. I increased the update frequency of htop and btop++ to 200ms (usually they poll/actualize/redraw at 2 seconds only) to investigate.
Then I retested that with Runit/S6(6) on the same systems.
Magic! The process-tree is instantly gone! And if you only SigHup it, it instantly reappears. BAM! BAM! BAM!
This applies to all sorts of process-trees also, not only FF.
Compared to that systemd feels like a sloth.
Yes, Yes, I did that under several different distros, initially AntiX, recently "init diversity edition"(Debian derivative optimized for 'live-booting', running from RAM, in all sorts of 'Frugal' installs), some Arch-derivatives, sometimes 'riced' to the max, and default Debian, just to be sure.
Over several years. Initially on a Core-i7 640LM with only 8GB RAM, more recently on Core-i5 7500t, and Core-i7 7700t with 32GB RAM.
Verdict: systematically slo(w)thified.
Do you think this is any different on more modern systems? Fear not, it gets worse with more cores!1!!
> You make it sound like systemd manufactured this monoculture somehow.
Where are you getting this from? I do not see it at all. The parent comment just says that it is an emergent compromise they don't think is a good one. That the code cannot be audited is also not necessarily a quality issue, either. It is just impossible to feasibly audit over 10 million lines of C. (this criticism applies equally to the kernel, although I doubt anyone would claim the kernel is less audited than systemd)
> Let's not pretend that a modern "init" does only system initialisation by calling shell scripts and then disappearing.
Nobody is pretending this. the comment you are replying to literally says "I don't think it represents the current state of the community".
Where are you getting this from? I do not see it at all. The parent comment just says that it is an emergent compromise they don't think is a good one. That the code cannot be audited is also not necessarily a quality issue, either. It is just impossible to feasibly audit over 10 million lines of C. (this criticism applies equally to the kernel, although I doubt anyone would claim the kernel is less audited than systemd)
> Let's not pretend that a modern "init" does only system initialisation by calling shell scripts and then disappearing.
Nobody is pretending this. the comment you are replying to literally says "I don't think it represents the current state of the community".
I believe you are making assumptions about my beliefs that don't follow from what I said.
> I believe that systemd won out because they chose to embrace some complexity to solve really hard problems. Let's not pretend that a modern "init" does only system initialization by calling shell scripts and then disappearing.
I made a point to clarify I do not think SysV init scripts are a good solution for most systems Starting the services in a correct maximally parallel order is a constraint satisfaction problem, and many modern alternative init systems understand that. My personal favorite, dinit, explicitly uses the systemd model to great success, being faster than runit or OpenRC with less LoC. If someone finds that too opaque, they are free to use a more imperative init system without any obstacles.
> They chose to solve hard problems and people adopted it. It's not anything more sinister. It's definitely not an "un-auditable mess". It's written in well-formatted C with structure, good tooling, and an open community. You can disagree with the ideology but that's open source for you.
A piece of software being hard to understand doesn't imply it's because it's badly written. systemd is simply more complex as an "enterprise" piece of software. Think about it: RedHat's business is selling support contracts, so they won't risk losing a major contract by not implementing a feature their client needs, even if most won't use it. This both made it more robust and much wider in scope than other init systems, maintained mostly by hobbyist desktops.
For contrast, despite Canonical having killed Upstart in 2014, Google still feels confident enough in its security to deploy it across millions of ChromeOS devices, because it's a simple program that does one thing well, and thus no more risky than any other privileged binary.
> systemd was chosen by distros and users across different communities because it solves hard problems better than the others. We can debate about why that is, but the maintainers of Systemd aren't running smear campaigns against other open source projects. Often systemd is the subject of such ire.
I'm not ascribing any intent to systemd maintainers. But it's undeniable there exists a connection between GNOME, Freedesktop, and systemd, namely that each receive support from RedHat and share the most active RedHat contributors. When systemd releases a new feature, GNOME very soon integrates it, which FreeDesktop then uses as a justification for their new specification, which other desktops soon follow. This often lead us to fast-tracking adoption of genuinely good standards, but there is the confounding factor of funding to their general merit.
> I believe that systemd won out because they chose to embrace some complexity to solve really hard problems. Let's not pretend that a modern "init" does only system initialization by calling shell scripts and then disappearing.
I made a point to clarify I do not think SysV init scripts are a good solution for most systems Starting the services in a correct maximally parallel order is a constraint satisfaction problem, and many modern alternative init systems understand that. My personal favorite, dinit, explicitly uses the systemd model to great success, being faster than runit or OpenRC with less LoC. If someone finds that too opaque, they are free to use a more imperative init system without any obstacles.
> They chose to solve hard problems and people adopted it. It's not anything more sinister. It's definitely not an "un-auditable mess". It's written in well-formatted C with structure, good tooling, and an open community. You can disagree with the ideology but that's open source for you.
A piece of software being hard to understand doesn't imply it's because it's badly written. systemd is simply more complex as an "enterprise" piece of software. Think about it: RedHat's business is selling support contracts, so they won't risk losing a major contract by not implementing a feature their client needs, even if most won't use it. This both made it more robust and much wider in scope than other init systems, maintained mostly by hobbyist desktops.
For contrast, despite Canonical having killed Upstart in 2014, Google still feels confident enough in its security to deploy it across millions of ChromeOS devices, because it's a simple program that does one thing well, and thus no more risky than any other privileged binary.
> systemd was chosen by distros and users across different communities because it solves hard problems better than the others. We can debate about why that is, but the maintainers of Systemd aren't running smear campaigns against other open source projects. Often systemd is the subject of such ire.
I'm not ascribing any intent to systemd maintainers. But it's undeniable there exists a connection between GNOME, Freedesktop, and systemd, namely that each receive support from RedHat and share the most active RedHat contributors. When systemd releases a new feature, GNOME very soon integrates it, which FreeDesktop then uses as a justification for their new specification, which other desktops soon follow. This often lead us to fast-tracking adoption of genuinely good standards, but there is the confounding factor of funding to their general merit.
systemd isn't even a constraint solving system, it's highly "imperative", there's just memes floating around that think it is??? not even poettering would claim that
What you say would be more credible if you would provide a list of those "hard problems".
I have been using Linux on many desktops, laptops, servers, including on my primary workstations, for the last 30 years. I have also managed Linux on the computers of other people who have successfully used Linux for many years, despite the fact that they did not know what "Linux" is.
During all these years, both at home and at various companies, I have never encountered any of those problems for which systemd is supposedly required.
Using systemd appears to be a matter of preference, not of necessity. However I have never seen any Linux users who could explain their preference for systemd.
Systemd is ubiquitous now because it has been chosen by the maintainers of most major Linux distributions, not because it has been chosen by any end-users. Most maintainers also have not chosen it for any personal reasons, but because the maintenance of the distribution would have become a PITA without systemd, due to the dependencies introduced by a few important packages, like GNOME, which were thought to be indispensable in any distribution.
Perhaps systemd has some advantages that I am not aware of, but with certainty the proponents of systemd suck at selling it, because they have never been able to describe those advantages. Instead of trying to convince others that systemd is technically superior, the dependencies upon systemd have been imposed by force upon all Linux users by a relatively small number of developers.
By coincidence, just these days I have begun to study elogind, which is mentioned in TFA and which is a workaround for not having a complete systemd.
Until a couple of weeks ago, I had succeeded to not use even elogind, but the last version of the Xorg server has acquired a hard dependency on systemd, so after upgrading it now I have to run this additional useless elogind daemon, to simulate the presence of systemd. I have begun to study elogind because launching it early during boot seems to have introduced some bugs in the behavior of the Linux virtual consoles. Even if I normally do not use those, I have been intrigued so I have started to investigate what elogind really does.
After these news about GNOME, I think that I will be forced to do a much more thorough study of elogind and systemd than I would have ever wanted to do, in order to write some replacements for satisfying any systemd dependencies in the applications that I am interested. I do not use GNOME, but there are useful applications that expect some GNOME services, and those may become now more dependent of systemd.
I hate that I will have to do a lot of work without any obvious useful purpose, just to keep running the same programs that previously worked fine without systemd.
I have been using Linux on many desktops, laptops, servers, including on my primary workstations, for the last 30 years. I have also managed Linux on the computers of other people who have successfully used Linux for many years, despite the fact that they did not know what "Linux" is.
During all these years, both at home and at various companies, I have never encountered any of those problems for which systemd is supposedly required.
Using systemd appears to be a matter of preference, not of necessity. However I have never seen any Linux users who could explain their preference for systemd.
Systemd is ubiquitous now because it has been chosen by the maintainers of most major Linux distributions, not because it has been chosen by any end-users. Most maintainers also have not chosen it for any personal reasons, but because the maintenance of the distribution would have become a PITA without systemd, due to the dependencies introduced by a few important packages, like GNOME, which were thought to be indispensable in any distribution.
Perhaps systemd has some advantages that I am not aware of, but with certainty the proponents of systemd suck at selling it, because they have never been able to describe those advantages. Instead of trying to convince others that systemd is technically superior, the dependencies upon systemd have been imposed by force upon all Linux users by a relatively small number of developers.
By coincidence, just these days I have begun to study elogind, which is mentioned in TFA and which is a workaround for not having a complete systemd.
Until a couple of weeks ago, I had succeeded to not use even elogind, but the last version of the Xorg server has acquired a hard dependency on systemd, so after upgrading it now I have to run this additional useless elogind daemon, to simulate the presence of systemd. I have begun to study elogind because launching it early during boot seems to have introduced some bugs in the behavior of the Linux virtual consoles. Even if I normally do not use those, I have been intrigued so I have started to investigate what elogind really does.
After these news about GNOME, I think that I will be forced to do a much more thorough study of elogind and systemd than I would have ever wanted to do, in order to write some replacements for satisfying any systemd dependencies in the applications that I am interested. I do not use GNOME, but there are useful applications that expect some GNOME services, and those may become now more dependent of systemd.
I hate that I will have to do a lot of work without any obvious useful purpose, just to keep running the same programs that previously worked fine without systemd.
> Monocultures are bad because they eliminate competitive pressure for good design and create single points of failure that affect everyone.
For a practical example of this, the XZ backdoor [1] affected liblzma which is (was?) a dependency for libsystemd, and some distributions patched OpenSSH to include libsystemd. As a result, the decision of putting journal file compression functionality directly into your init system means that a significant portion of all Linux systems out there came this close to being backdoored.
[1] https://news.ycombinator.com/item?id=39911311
For a practical example of this, the XZ backdoor [1] affected liblzma which is (was?) a dependency for libsystemd, and some distributions patched OpenSSH to include libsystemd. As a result, the decision of putting journal file compression functionality directly into your init system means that a significant portion of all Linux systems out there came this close to being backdoored.
[1] https://news.ycombinator.com/item?id=39911311
This wasn't a systemd problem— this was distro maintainers doing something stupid problem. The thing the maintainers wanted to patch into OpenSSH was systemd-notify which is the way services can tell systemd that they're ready. The protocol is literally sending the string READY=1 over a file descriptor. libsystemd contains a reference implementation but it's a protocol specifically for the reason that every service isn't supposed to link to libsystemd. Maintainers thought it was easier to link in all of libsystemd (and therefore xz) into OpenSSH just for the sd_notify function.
Just link in a huge library into security critical code, what could go wrong?!
Just link in a huge library into security critical code, what could go wrong?!
You're not wrong, but look at it from a user's perspective. The documentation (https://www.freedesktop.org/software/systemd/man/latest/sd_n...) explicitly says:
Then, you look at the reference code and see some reasonably nontrivial stuff that's a bit outside the maintainer's remit to add.
All of that is going to lead people in the direction of linking the library rather than reimplementing from scratch.
using this library should be preferred in order to avoid code duplication
Then, you look at the reference code and see some reasonably nontrivial stuff that's a bit outside the maintainer's remit to add.
All of that is going to lead people in the direction of linking the library rather than reimplementing from scratch.
Putting to much unnecessary stuff into libsystemd is something sub-optimal that they do. Its a bit lazy. But it is correct that people should link it like that.
From the horse's mouth. https://mastodon.social/@pid_eins/112202687764571433
> In the past, I have been telling anyone who wanted to listen that if all you want is sd_notify() then don't bother linking to libsystemd, since the protocol is stable and should be considered the API, not our C wrapper around it. After all, the protocol is so trivial
I'm actually surprised that they added the note about code duplication after adding the standalone implementation specifically so people won't do that.
> In the past, I have been telling anyone who wanted to listen that if all you want is sd_notify() then don't bother linking to libsystemd, since the protocol is stable and should be considered the API, not our C wrapper around it. After all, the protocol is so trivial
I'm actually surprised that they added the note about code duplication after adding the standalone implementation specifically so people won't do that.
It's not even that, that whole story's main point was about how an incredibly complex, sophisticated and lengthy social engineering attack was carried out, probably by a nation-state actor, after singleing out an over-worked open source maintainer of a core project (xz) doing a thankless job and getting pressured left-and-right until he caved (no fault of his own), and they managed to install an updatable, generic backdoor that could be used to attack literally anything. The initial version was chosen to target sshd <-- libsystemd <-- xz.
The takeway that sensible people go away with is that core critical infrastructure needs to be properly funded, and people need to stop harassing open source maintainers.
Idiots instead rant about "muh systemd" and use it to attack other maintainers.
The takeway that sensible people go away with is that core critical infrastructure needs to be properly funded, and people need to stop harassing open source maintainers.
Idiots instead rant about "muh systemd" and use it to attack other maintainers.
If you think that's wild you should hear about kernel vulnerabilities!
Yeah, the Linux monoculture is also bad. In fact, one reason the systemd monoculture is bad is because it enforces the Linux monoculture.
What about the Windows monoculture in business?
What about the seemingly Apple monoculture on HN?
What about the OpenBSD monoculture with OpenBSD!!!!!
You know what Linux needs? Another audio stack. Be sure it's backwards compatible with all the others, just like the last dozen were.
What about the seemingly Apple monoculture on HN?
What about the OpenBSD monoculture with OpenBSD!!!!!
You know what Linux needs? Another audio stack. Be sure it's backwards compatible with all the others, just like the last dozen were.
I remember reading PipeWire is more stable than Pulseaudio because it removed a buggy and hard-to-implement-correctly feature. So not completely backwards compatible.
> What about the Windows monoculture in business?
...yes? Obviously?
> What about the seemingly Apple monoculture on HN?
I don't think that exists, but if it did then I would object to it.
> What about the OpenBSD monoculture with OpenBSD!!!!!
What would that even mean? ...Actually, no, even if I sort of pretend that the concept makes sense it's not really a thing; OpenBSD constantly exports their software to be usable on other systems (ex. OpenSSH is an OpenBSD project) and imports general unix-like software to work on it. So no, there is no OpenBSD monoculture and wouldn't be even if it was that popular.
> You know what Linux needs? Another audio stack. Be sure it's backwards compatible with all the others, just like the last dozen were.
See, the real reason that this is funny is that PipeWire is a new audio system, is mostly superior to its predecessors, and largely is successful because it is backwards compatibile. So... Yes, actually, exactly what you said but unironically and without the slightest bit of sarcasm.
...yes? Obviously?
> What about the seemingly Apple monoculture on HN?
I don't think that exists, but if it did then I would object to it.
> What about the OpenBSD monoculture with OpenBSD!!!!!
What would that even mean? ...Actually, no, even if I sort of pretend that the concept makes sense it's not really a thing; OpenBSD constantly exports their software to be usable on other systems (ex. OpenSSH is an OpenBSD project) and imports general unix-like software to work on it. So no, there is no OpenBSD monoculture and wouldn't be even if it was that popular.
> You know what Linux needs? Another audio stack. Be sure it's backwards compatible with all the others, just like the last dozen were.
See, the real reason that this is funny is that PipeWire is a new audio system, is mostly superior to its predecessors, and largely is successful because it is backwards compatibile. So... Yes, actually, exactly what you said but unironically and without the slightest bit of sarcasm.
If openssh isn't a monoculture this whole thing you've got falls apart.
And pipewire is fine and good? Ask a sound engineer.
And pipewire is fine and good? Ask a sound engineer.
> Replying to some sibling comments asking why anyone wouldn't want to use systemd.
I get why some people don't want to use systemd. That's fine.
I really don't understand why this group of people are so passionate about broadcasting this opinion to anyone within earshot. They don't like a piece of software, great! They've got different values! Use something else!
I get why some people don't want to use systemd. That's fine.
I really don't understand why this group of people are so passionate about broadcasting this opinion to anyone within earshot. They don't like a piece of software, great! They've got different values! Use something else!
I think you're missing the point. This is a thread about GNOME, a major desktop environment, declaring systemd-userdb as a necessary requirement for its future version, asking the non-systemd community to provide an API-compatible implementation if they want to keep using GNOME.
I personally do not use GNOME, nor am I running a non-systemd system at the moment. This is the first time I wrote a single word about systemd vs other inits on the internet, explicitly because it couldn't be more on-topic.
It's a common false compromise to say you now depend on a component but welcome alternative implementations. In reality, this quickly becomes treadmill for their maintainers, forced to adapt to its quirks so the dependent software even has a chance of working. You can read more about eudev as a more notable example of that dynamic. Projects like Wayland avoid it by having a committee of major implementations vote on proposed specs.
I personally do not use GNOME, nor am I running a non-systemd system at the moment. This is the first time I wrote a single word about systemd vs other inits on the internet, explicitly because it couldn't be more on-topic.
It's a common false compromise to say you now depend on a component but welcome alternative implementations. In reality, this quickly becomes treadmill for their maintainers, forced to adapt to its quirks so the dependent software even has a chance of working. You can read more about eudev as a more notable example of that dynamic. Projects like Wayland avoid it by having a committee of major implementations vote on proposed specs.
Well GNOME is a bit of an oddball in the Linux userland world and everyone knows it. They have a "my way or the highway" type attitude to everything they do, and all the pros and cons that come with that. On one hand, they're able to achieve a development velocity and quality that a lot of other full-featured desktop environments cannot. On the other hand, users can perceive regressions in features and choice.
I think, if this is a surprise to anyone, they're not really paying attention. If you want GNOME you go along for the ride, and that's the message we've all gotten for the past 10 years. This same conversation keeps coming back up.
Just use KDE or something else if that's not an experience you, or other's, want. Personally, I despise GNOME, so problem solved for me. But, we have these conflicting takes where people will complain about fragmentation on Linux and then also complain about monocultures like GNOME. That's the experience GNOME very clearly wants to give, so if that's bad to you, then don't use it. And, on a distro level, maintainers can decide if they want to ship GNOME or if they want to make it the default.
I think, if this is a surprise to anyone, they're not really paying attention. If you want GNOME you go along for the ride, and that's the message we've all gotten for the past 10 years. This same conversation keeps coming back up.
Just use KDE or something else if that's not an experience you, or other's, want. Personally, I despise GNOME, so problem solved for me. But, we have these conflicting takes where people will complain about fragmentation on Linux and then also complain about monocultures like GNOME. That's the experience GNOME very clearly wants to give, so if that's bad to you, then don't use it. And, on a distro level, maintainers can decide if they want to ship GNOME or if they want to make it the default.
> if they want to keep using GNOME
It's fine if they don't. Other users of GNOME will want to push back on API changes and deprecation. This is normal in software.
It's fine if they don't. Other users of GNOME will want to push back on API changes and deprecation. This is normal in software.
"And some are just running a musl system that can't even use systemd."
no longer…
https://catfox.life/2024/09/05/porting-systemd-to-musl-libc-...
no longer…
https://catfox.life/2024/09/05/porting-systemd-to-musl-libc-...
The end of the article details the steps necessary for people who want to run Gnome without systemd. There is a monoculture of sorts, which is that bespoke init systems aren't tested or supported by Gnome itself, but like you already need to do to get Gnome working normally, you can still patch in support for whatever system you prefer. The article even provides a list of services and APIs that you will need to hook up to Gnome to make it work.
You don't need to reimplement logind or D-Bus, but you will need to patch your mechanisms of choice into Gnome itself. Gnome isn't planning on maintaining a second copy of common system services that exist on modern systems anymore (a copy that is based on a hack in the first place). The burden of maintenance now falls on whoever wants to provide their own alternative.
All the extra work you need to do to get alternative init systems working is work the Gnome team no longer needs to do.
You don't need to reimplement logind or D-Bus, but you will need to patch your mechanisms of choice into Gnome itself. Gnome isn't planning on maintaining a second copy of common system services that exist on modern systems anymore (a copy that is based on a hack in the first place). The burden of maintenance now falls on whoever wants to provide their own alternative.
All the extra work you need to do to get alternative init systems working is work the Gnome team no longer needs to do.
This is a sensible move. systemd is a good piece of software, and foundational Linux infrastructure which by now is very widely deployed.
I’ve been doing Linux a long time and my experience is that systemd is much more pleasant to work with than the brittle duct tape and shell script stuff which came before.
I’ve been doing Linux a long time and my experience is that systemd is much more pleasant to work with than the brittle duct tape and shell script stuff which came before.
Agreed. I wonder how many people in this thread hating on systemd have actually tried to work with upstream. They are an extremely pleasant and welcoming community who are willing to work with you on the most trivial stuff.
systemd maintainers were extremely unpleasant, unwelcoming, and unwilling to work with others in my experience.
Xorg was also a "good piece of software, foundational Linux infrastructure and very wildly deployed"
Still is?
100%, I won't replace x11 it until I feel all my automation tools work correctly or the "way.." alternative is better
Was just making the parallel with Wayland, how frustrating it has been for a lot of people, how everyone preaching correct software design, should be simple/protocols/standards/modular with correct responsibilities between projects... and how fast everyone forgot it
Was just making the parallel with Wayland, how frustrating it has been for a lot of people, how everyone preaching correct software design, should be simple/protocols/standards/modular with correct responsibilities between projects... and how fast everyone forgot it
Systemd is crap. Works in the main use case, mess up otherwise. It is the windows kernel of linux distributions.
Here for example, suddenly systemd will be mandatory despite systemd not caring for multiple session of a single user. Not only not yet implemented but totally that don't need it personally so no one can want to have it. And so again the capability of our linux based distribution will be restricted for something that was just working for decades.
Again, we can also notice how systemd people try to force systemd usage down or throats by making it mandatory for core parts like the login. Where it is not the responsibility of the initsystem to deal with that (except in windows) and if the thing was not a damned crap, it would be easy to switch to alternatives with clear interfaces.
Here for example, suddenly systemd will be mandatory despite systemd not caring for multiple session of a single user. Not only not yet implemented but totally that don't need it personally so no one can want to have it. And so again the capability of our linux based distribution will be restricted for something that was just working for decades.
Again, we can also notice how systemd people try to force systemd usage down or throats by making it mandatory for core parts like the login. Where it is not the responsibility of the initsystem to deal with that (except in windows) and if the thing was not a damned crap, it would be easy to switch to alternatives with clear interfaces.
> Where it is not the responsibility of the initsystem
systemd is not an init system. It's an umbrella project with many distinct tools and services, only one of which is an init provider.
systemd is not an init system. It's an umbrella project with many distinct tools and services, only one of which is an init provider.
What makes it problematic is that they still end up with cross-dependencies. I might find resolved or logind great tools, but I can't use them without systemd, even though I can sitll use systemd without resolved. They all reinforce systemd as an irreplaceable component that will only grow more hooks for these subprojects, becoming increasingly unimplementable and complex.
systemd is far from perfect, but it's the best we've got on Linux. Treating systemd like an init system is like treating your car like a Bluetooth speaker: yes, you can connect your phone to the speaker system over bluetooth and yes you can take the speakers with you to most places, but the speakers are only a small part of what you're taking along with you
Nobody is forcing systemd down anyone's throats. You can use init.d if you like, or OpenRC, or whatever you prefer. What's happening instead is that people who maintain software are no longer interested in maintaing init.d scripts or working around the missing features many supposed alternatives lack.
Nobody is forcing systemd down anyone's throats. You can use init.d if you like, or OpenRC, or whatever you prefer. What's happening instead is that people who maintain software are no longer interested in maintaing init.d scripts or working around the missing features many supposed alternatives lack.
And to add to the fact that it was shoved down our throat, it wasn't even the best system. There was plenty of them that were interested with great features initng, upstart,... But systemd won because they manage to force us to depend on them for main distributions and core components like login. Pushed strong by red hat...
Sorry, but systemd is really forced upon the users throats, all the time, more and more.
Just a few weeks ago, in some systems that worked perfectly without systemd, I have upgraded Xorg server, but the new version would no longer run, because it has acquired a hard dependence upon systemd.
As a workaround, I had to run the additional elogind daemon, which does not provide any useful function, except of keeping happy the developer who has added this extra systemd dependency.
Such events have happened for years, every few months, with more and more dependencies of systemd added to various applications, which after that do not gain any useful feature but they force their users who do not want systemd to waste time for developing workarounds that satisfy the new undesirable systemd dependencies.
Just a few weeks ago, in some systems that worked perfectly without systemd, I have upgraded Xorg server, but the new version would no longer run, because it has acquired a hard dependence upon systemd.
As a workaround, I had to run the additional elogind daemon, which does not provide any useful function, except of keeping happy the developer who has added this extra systemd dependency.
Such events have happened for years, every few months, with more and more dependencies of systemd added to various applications, which after that do not gain any useful feature but they force their users who do not want systemd to waste time for developing workarounds that satisfy the new undesirable systemd dependencies.
It's more comparable to the Windows Registry.. (well ok the registry isn't also dozens of daemons that run everything...)
The fact that the next blog post (linked at the bottom of the article) is titled "a desktop for all" is deliciously ironic in context.
For all in this context does not mean “all the infinite combinations of software for people that refuse to adopt the status quo”
systemd is here to stay. It is ludicrous to imagine everybody to keep supporting that 1% that is ideologically opposed to it, no? As those people love to say, open-source is written by volunteers, you can always fork it.
systemd is here to stay. It is ludicrous to imagine everybody to keep supporting that 1% that is ideologically opposed to it, no? As those people love to say, open-source is written by volunteers, you can always fork it.
What about the (admittedly small) % of operating systems that can't support systemd, like FreeBSD? systemd is pretty heavily dependent on Linux, and that's not an ideological thing.
Does gnome officially support non Linux kernels? It's possible to implement the systemd APIs gnome is taking dependencies on without strictly using systemd itself.
I have yet to hear an argument against systemd which isn’t a variation of:
- """bloat"""
- I dislike Poettering. Remember pulseaudio?
- a core user-space layer for modern applications that can’t only rely on the spartan kernel syscall API? Literally 1984.
Given that systemd is good enough and is running on 99% of desktops and servers, I always find it hilarious to see how the vocal minority is overrepresented on this forum.
- """bloat"""
- I dislike Poettering. Remember pulseaudio?
- a core user-space layer for modern applications that can’t only rely on the spartan kernel syscall API? Literally 1984.
Given that systemd is good enough and is running on 99% of desktops and servers, I always find it hilarious to see how the vocal minority is overrepresented on this forum.
There aren't decent Pro systemd arguments other than "the Linux API confused me" and sysv init (which no one argues is good) was bad.
Personally the last system I had systemd on corrupted my package database after killing apt that I was running in tmux. "Oh you can fix that with xyz systemd configuration." Here's my response:
Kindly shove it up your ass and quit moving things around all the time just because you're board.
Also if "it's good enough for most people" is a decent argument then you should be on Windows.
Personally the last system I had systemd on corrupted my package database after killing apt that I was running in tmux. "Oh you can fix that with xyz systemd configuration." Here's my response:
Kindly shove it up your ass and quit moving things around all the time just because you're board.
Also if "it's good enough for most people" is a decent argument then you should be on Windows.
The pro argument is that writing shell scripts for starting/restarting/enabling/disabling/stopping is total garbage. Not to mention having to manage lock files. systemd units are not perfect, but they are a billion times better than the crap we used to deal with.
Wow, neither of you actually read my comment.
The pro part is the massive simplification and security advantages systemd brings to plain and simple config files. Sure, I can reimplement the containerisation API in OpenRC if I stack enough helper binaries and shell script libraries in there, but I don't want to. Kindly shove it up your ass and quit moving things around all the time just because you're board.
If it's good enough for most people, that means it's good enough to use as a basis for development. The same way no company develops mobile apps for Phosh or Plasma Mobile: the tiny fraction of people who have more esoteric preferences aren't worth rewriting the software stack for. Those who don't like the status quo can write their own wrappers and hacks if they want to use your software.
If it's good enough for most people, that means it's good enough to use as a basis for development. The same way no company develops mobile apps for Phosh or Plasma Mobile: the tiny fraction of people who have more esoteric preferences aren't worth rewriting the software stack for. Those who don't like the status quo can write their own wrappers and hacks if they want to use your software.
It is weird to name something as a "massive simplification" when saying that it is intended to replace "plain and simple config files". "Massive simplification" is a term that may be applied to something like the daemontools of Bernstein and to other systems inspired by it, but certainly not to anything based on systemd, where it is much harder to discover what it really does, when problems appear.
Perhaps systemd has "security advantages" over alternative solutions, but I have never heard of them and I cannot imagine them, so please name them.
Perhaps systemd has "security advantages" over alternative solutions, but I have never heard of them and I cannot imagine them, so please name them.
Honestly this sounds like an apt problem. A properly robust package management system shouldn't be able to succumb to such a problem.
Your abrasiveness is not helping discussion. I'm also not a board.
Your abrasiveness is not helping discussion. I'm also not a board.
So your software broke my machine then you tell me it's my problem and wonder why people are angry and frustrated with you?
Do you see why most competent people's reaction is to just use something else? systemd might even be technically superior but the maintainers are such assholes it's not worth it.
Do you see why most competent people's reaction is to just use something else? systemd might even be technically superior but the maintainers are such assholes it's not worth it.
sph(1)
[deleted]
I believe that the opposite applies.
I have yet to hear any argument pro systemd that is valid.
As long as the systemd supporters cannot explain its advantages, there is no reason for anybody else to replace their good systems that work fine without systemd, with systems using systemd.
In practice, systemd has been imposed by force. The developers of a few packages, like GNOME, have introduced dependencies upon systemd. Then the maintainers of the major Linux distributions have considered that such packages cannot be removed from their distribution, therefore they must base it on systemd.
Then the users have discovered when upgrading their computers that they must either migrate to systemd or stay with their ancient program versions.
This is how systemd has propagated. In no place there was any analysis about technical advantages and any attempt to find an optimal solution by consensus.
I have yet to hear any argument pro systemd that is valid.
As long as the systemd supporters cannot explain its advantages, there is no reason for anybody else to replace their good systems that work fine without systemd, with systems using systemd.
In practice, systemd has been imposed by force. The developers of a few packages, like GNOME, have introduced dependencies upon systemd. Then the maintainers of the major Linux distributions have considered that such packages cannot be removed from their distribution, therefore they must base it on systemd.
Then the users have discovered when upgrading their computers that they must either migrate to systemd or stay with their ancient program versions.
This is how systemd has propagated. In no place there was any analysis about technical advantages and any attempt to find an optimal solution by consensus.
> As long as the systemd supporters cannot explain its advantages, there is no reason for anybody else to replace their good systems that work fine without systemd, with systems using systemd.
Assuming you know what systemd as init system able to do, I'm not sure what extra information you need for getting list of advantages.
If you going with examples is better for you, i'll mention couple of mine - note that I likely forget some other good samples as it's so natural so I'm may be not realizing it's systemd's feature, just "how things work"
* hardening - syscall filtering, privilege limiting, read/write path filtering, per-unit tmp files. As nice example, I have great peace of mind when I put php-fpm into network isolated to localhost only for IP level
* resource management and resource information at all - observing resource usage by multiple units when needed with a quick way saves my time, in addition to being able to collect such metrics into monitoring. Setting the lowest IO priority for backup scripts and even MB/sec per block device - godsend. Limits on CPU usage or RAM usage where needed ensures smooth operations of the fleet without nasty surprises
* things like quick overview with systemctl --failed, user-level units instead of flacky @reboot in crontab (yeah, we still remember it from eggdrop/psybnc days)
* clear and uniform way to work with services across the team, no hacky bash scripts with saving PIDs
so on.
Probably you do system administration for your servers in some other way that all that goodies are not noticeable for you and your team.
Assuming you know what systemd as init system able to do, I'm not sure what extra information you need for getting list of advantages.
If you going with examples is better for you, i'll mention couple of mine - note that I likely forget some other good samples as it's so natural so I'm may be not realizing it's systemd's feature, just "how things work"
* hardening - syscall filtering, privilege limiting, read/write path filtering, per-unit tmp files. As nice example, I have great peace of mind when I put php-fpm into network isolated to localhost only for IP level
* resource management and resource information at all - observing resource usage by multiple units when needed with a quick way saves my time, in addition to being able to collect such metrics into monitoring. Setting the lowest IO priority for backup scripts and even MB/sec per block device - godsend. Limits on CPU usage or RAM usage where needed ensures smooth operations of the fleet without nasty surprises
* things like quick overview with systemctl --failed, user-level units instead of flacky @reboot in crontab (yeah, we still remember it from eggdrop/psybnc days)
* clear and uniform way to work with services across the team, no hacky bash scripts with saving PIDs
so on.
Probably you do system administration for your servers in some other way that all that goodies are not noticeable for you and your team.
> I always find it hilarious to see how the vocal minority is overrepresented on this forum.
Those who oppose the norm are usually a lot more vocal than the people who support it, or just don't care. This is why you get bathtub curves in ratings - you can bet the low ratings are over-represented in comparison with the meh and the praise.
Those who oppose the norm are usually a lot more vocal than the people who support it, or just don't care. This is why you get bathtub curves in ratings - you can bet the low ratings are over-represented in comparison with the meh and the praise.
fotomar(2)
Funny how it doesn't matter anymore.
Gnome has been quite good for more than 10 years but nobody really care because the web browser has become the Desktop Environment. I haven't notices any change in the last 10-15 years.
and power users will use i3, sway or hyprland anyway.
The Gnome people create drama about irrelevant things to get attention like "the danger in theming apps", some minor UI changes or the stronger dependency on systemd but few people care.
What I would worry more about in term of adoption across Unixes is Wayland, it seems the OpenBSD and FreeBSD people are not warm to it.
Gnome has been quite good for more than 10 years but nobody really care because the web browser has become the Desktop Environment. I haven't notices any change in the last 10-15 years.
and power users will use i3, sway or hyprland anyway.
The Gnome people create drama about irrelevant things to get attention like "the danger in theming apps", some minor UI changes or the stronger dependency on systemd but few people care.
What I would worry more about in term of adoption across Unixes is Wayland, it seems the OpenBSD and FreeBSD people are not warm to it.
Gnome without extensions is pretty terrible. Missing some just basic stuff that you really can't just not have. Most distros add that stuff back in.
But then the extensions aren't stable at all, its honestly a bit of a mess.
And in terms of performance its ok, but not exactly great.
I still use Gnome but mostly just because I'm used to it and hoping Cosmic will mature.
Gnome isn't bad, but they made a lot of dumb decisions that are just unnecessary. And they have been a disaster for Wayland development.
But then the extensions aren't stable at all, its honestly a bit of a mess.
And in terms of performance its ok, but not exactly great.
I still use Gnome but mostly just because I'm used to it and hoping Cosmic will mature.
Gnome isn't bad, but they made a lot of dumb decisions that are just unnecessary. And they have been a disaster for Wayland development.
> Gnome has been quite good for more than 10 years
I know there’s no accounting for taste, but GNOME Shell has to be the worst desktop environment I’ve ever used, and man I’ve used a lot of different ones
I know there’s no accounting for taste, but GNOME Shell has to be the worst desktop environment I’ve ever used, and man I’ve used a lot of different ones
Yeah let me put it in context.
I was exited and used Gnome 1.2 back in 2000 (?) It was fun but not serious compared to let's say the MS Windows 2000 desktop.
Progressing in the Gnome 2 serie it became a more serious project and something that could compete with the MS Windows desktop.
Both are full of annoyances...
I was exited and used Gnome 1.2 back in 2000 (?) It was fun but not serious compared to let's say the MS Windows 2000 desktop.
Progressing in the Gnome 2 serie it became a more serious project and something that could compete with the MS Windows desktop.
Both are full of annoyances...
For all worried check out xfce. It works, is light, is customizable, has gtk responsiveness (I find Qt click and drag and drop downs odd)
Only downside maybe is no Wayland support yet.
Mate supports Wayland since Mate 1.28.
See https://wiki.mate-desktop.org/developers-corner/wayland-meso...
Quote:
> One of the most notable improvements is the enhanced support for Wayland, bringing us closer to a fully native MATE-Wayland experience. Several components have been updated to work seamlessly with Wayland, ensuring a more integrated and responsive desktop environment.
See https://wiki.mate-desktop.org/developers-corner/wayland-meso...
Quote:
> One of the most notable improvements is the enhanced support for Wayland, bringing us closer to a fully native MATE-Wayland experience. Several components have been updated to work seamlessly with Wayland, ensuring a more integrated and responsive desktop environment.
with 4.20, there is experimental wayland support for almost all xfce4 applications. I've used it and didn't even face a single crash.
So, it's not far away.
So, it's not far away.
great!
Do you feel is a "good" change? does using a DE with wayland feels better or different? not talking about technical advantages...
i don't see any change other than display colours and font looking more crispy. i use computer mostly for watching and programming. some very light FOSS gaming(Luanti, STK).
> no Wayland support yet
That's not a downside.
That's not a downside.
My hardware doesn't work with X. Screen tearing. So im stuck with wayland, although I'd like to move to xfce when they support wayland
Screen tearing has been fixed on X11 for a while:
> xrandr --output DisplayPort-0 --set TearFree on
That works on AMD and Intel modesetting. There's something similar for nVidia. I haven't had a screen tearing issue in years on X11
> xrandr --output DisplayPort-0 --set TearFree on
That works on AMD and Intel modesetting. There's something similar for nVidia. I haven't had a screen tearing issue in years on X11
I think this is a good move: it focuses on maintaining a single, well-tested code path while still offering guidance for those who want alternatives (see the section "So what should distros without systemd do?" in the article).
It's not making it impossible to run GNOME on non-systemd systems, but it shifts the responsibility of maintaining that support to the projects that are actually interested in it. I think ultimately this might lead to a better user experience since the people developing non-systemd support are also the ones using it.
It's not making it impossible to run GNOME on non-systemd systems, but it shifts the responsibility of maintaining that support to the projects that are actually interested in it. I think ultimately this might lead to a better user experience since the people developing non-systemd support are also the ones using it.
I just registered for comment here: they always refused to admit it (by "they" I mean Fedora/IBM) but we will end up having a Gnome OS for the general public... And I'm afraid the 3E rule is starting to be applied (Extended already, Embraced in all the "other OS" and now...)
Gnome maintains an OS for developers and such: https://os.gnome.org/
Red Hat Enterprise Linux is basically a Gnome OS already. So is Ubuntu. Though both come in KDE flavour and a bunch of others too.
I don't see what's wrong with Red Hat spending development time for "only" one single desktop environment.
Red Hat Enterprise Linux is basically a Gnome OS already. So is Ubuntu. Though both come in KDE flavour and a bunch of others too.
I don't see what's wrong with Red Hat spending development time for "only" one single desktop environment.
pcpuser(2)
Just rename Gnome to systemd-desktop and be done with it.
This is a good move. Without having endless resources keeping the codebase small and focused just makes sense.
I know it's going to be painful for non-Linux users but volunteer devs can't be expected to cover all bases.
I know it's going to be painful for non-Linux users but volunteer devs can't be expected to cover all bases.
They do have endless resources. They are an IBM company.
If people choose to work for IBM without getting payed, that's kind of their problem.
gnome is an IBM company?
IBM bought Redhat, Redhat hires the devs for GNOME and hosts its infrastructure.
IBM and Redhat where also the main founders of GNOME.
They don't need to legally own GNOME. When most of the people working on systemD and GNOME are IBM employees, IBM makes the decisions. And GNOME is an IBM company.
https://wiki.gnome.org/RedHat https://en.wikipedia.org/wiki/GNOME_Foundation
https://wiki.gnome.org/RedHat https://en.wikipedia.org/wiki/GNOME_Foundation
Someone should tell them.
>Keeping the codebase small and focused makes sense
LMFAO. You have not even glanced at insane dumpster fire that is the gnome codebase.
LMFAO. You have not even glanced at insane dumpster fire that is the gnome codebase.
Regardless of what it's currently like, supporting fewer things is going to make it easier to maintain.
If Gnome cared about an easy to maintain codebase it would be radically different. Gnome's complexity is comparable to a large web browser (which is kind of insane considering how little it really does.)
To be completely fair to Gnome, they're doing some stuff that nobody else is doing. The idea of building an entire desktop off the backs of C and the gobject system is very novel and gives Gnome a lot of advantages. For example, it had binding for just about every language under the sun. Compare that to KDE and Qt, which is C++ or bust.
Obviously it's a bit hacky and kind of a mess, but it is technically interesting.
Obviously it's a bit hacky and kind of a mess, but it is technically interesting.
I don't know how things are done in the GTK-land, but Qt definitely has bindings for Python, Go, and others. Maybe GObject has some other advantages, but I don't know.
Kind of, but those binding are incomplete and not all modules are supported.
When I say GTK has bindings for every language, I do literally mean every language. It's the nice thing about choosing C as the language to make your entire API in.
When I say GTK has bindings for every language, I do literally mean every language. It's the nice thing about choosing C as the language to make your entire API in.
What's interesting here isn't a strict dependency on systemd, but dependencies on some APIs it provides. Given the ability and existence of things which implement those APIs outside of systemd, it's worth considering that the APIs themselves should be the focus. Perhaps they should be spun out of systemd itself. It seems sensible to that gnome would want to move to a better API which is almost defacto a standard these days anyways. Versioning the API and allowing more folks outside of the systemd organization to participate in its continued evolution should be the focus imo.
The problem is that those APIs are not well documented, so reading the convolute source code may be the only documentation in some cases.
Perhaps there is some documentation, but it is well hidden.
Just these days, after being hit by the fact that the Xorg server has become dependent on systemd, I have begun to search for what elogind is really doing to simulate the login services of systemd. I have not found any easy way to discover that, except by reading the source code, which is not simple at all.
I would not care if GNOME or any other package would add systemd dependencies, but these were accompanied by a document describing precisely the protocols or APIs they use for accessing systemd services, so that it would be easy to write alternative implementations.
The reality is that no such documentation is provided, so the only way to avoid systemd is to become an expert in its internals. This is why I hate when such new dependencies are added.
Perhaps there is some documentation, but it is well hidden.
Just these days, after being hit by the fact that the Xorg server has become dependent on systemd, I have begun to search for what elogind is really doing to simulate the login services of systemd. I have not found any easy way to discover that, except by reading the source code, which is not simple at all.
I would not care if GNOME or any other package would add systemd dependencies, but these were accompanied by a document describing precisely the protocols or APIs they use for accessing systemd services, so that it would be easy to write alternative implementations.
The reality is that no such documentation is provided, so the only way to avoid systemd is to become an expert in its internals. This is why I hate when such new dependencies are added.
> The reality is that no such documentation is provided, so the only way to avoid systemd is to become an expert in its internals.
The blog post subject of the thread literally links to the documentation. If you can't even be bothered clicking on the provided links, what are you even doing commenting on such a thread. But by all means, don't let facts get in the way of a good baseless rant.
The blog post subject of the thread literally links to the documentation. If you can't even be bothered clicking on the provided links, what are you even doing commenting on such a thread. But by all means, don't let facts get in the way of a good baseless rant.
What is Gnomes market share like these days?
It used to be the de facto FOSS desktop in the GNOME 2.x days but things changed with the release of Gnome 3 and I’ve not really noticed Gnome ever bounce back since.
It used to be the de facto FOSS desktop in the GNOME 2.x days but things changed with the release of Gnome 3 and I’ve not really noticed Gnome ever bounce back since.
Every time there is an interview of some startup and they show the offices with a glimpse of a monitor, it's always Ubuntu. Running gnome.
Also a few people I know, if they used Linux on a desktop it was Ubuntu.
Don't know anyone using KDE, steam deck being the only exception.
So from a personal perspective, if it's Linux on the desktop, it's gnome.
Also a few people I know, if they used Linux on a desktop it was Ubuntu.
Don't know anyone using KDE, steam deck being the only exception.
So from a personal perspective, if it's Linux on the desktop, it's gnome.
KDE is quite popular for personal computers I believe. It's got things like HDR support much earlier than Gnome did.
Corporate also seems to like OpenSUSE and RHEL. Universities seem to like Debian. Practically all of them default to Gnome or offer Gnome equivalently.
Even several (relatively) big SteamOS-alikes are using Gnome despite SteamOS itself defaulting to KDE.
Corporate also seems to like OpenSUSE and RHEL. Universities seem to like Debian. Practically all of them default to Gnome or offer Gnome equivalently.
Even several (relatively) big SteamOS-alikes are using Gnome despite SteamOS itself defaulting to KDE.
Things might have changed recently (though screenshots suggest otherwise) but Suse has always preferred KDE.
It's the default DE for RedHat, Fedora, Debian, Ubuntu, and many others.
KDE is commonly more popular among gamers it seems.
who does even compete with Gnome ? it is the de facto default desktop in almost all notable distros.
it just works, though it is far less customizable compared to KDE, it is far more stable -still only compared to KDE..
it just works, though it is far less customizable compared to KDE, it is far more stable -still only compared to KDE..
> it just works
For some definition of works, like a folder with 300 videos loading for 15 seconds and image viewer unable to open 150MB images.
I prefer how Gnome works compared to KDE, but I can't get past the ridiculous performance issues.
For some definition of works, like a folder with 300 videos loading for 15 seconds and image viewer unable to open 150MB images.
I prefer how Gnome works compared to KDE, but I can't get past the ridiculous performance issues.
Your use-cases are hardly average. I don't think I ever encountered 150MB image or folder with 300 videos. I don't even use nautilus outside of the very niche cases. I'm using Chromium or Terminal or VScode or Idea 99% of time. My GNOME is just a shell switching windows. Whatever file managers, image viewers or other stuff bundled with GNOME matters little for me, I can easily replace them. I don't even understand the concept of DE, this is just wasted work to maintain those apps. They even develop their own browser...
A computer should have no problems at all dealing with a 150MB image or 300 videos. I'm invoking cmuratori here. What do you think you are getting out of running defense for objectively broken/unusable software?
> it is far more stable -still only compared to KDE
Citation needed ;) I haven't seen any 'instability' in KDE since I switched from GNOME, and performance/snappiness of KDE is actually better.
Citation needed ;) I haven't seen any 'instability' in KDE since I switched from GNOME, and performance/snappiness of KDE is actually better.
Performance/stability on KDE used to be a lot worse IMO. Your opinion on KDE depends on when you last checked.
Does this matter as of now?
KDE 6 is quite stable in my experience and faster/more efficient than Gnome too.
I wonder if the changes to GDM will mean that other DE's like Cinnamon, MATE, Budgie, Deepen (XFCE?) won't be able to start anymore via GDM?
I think this is a good announcement. Just making things clear
Because let's be frank GDM/Gnome has not been playing well with other software for a while
Because let's be frank GDM/Gnome has not been playing well with other software for a while
This is the back-end plague which is everywhere in free software. The idea is that whatever "it" is, adding support for "it" is "just another back-end" . Take cairo for example, it has or had back-ends for gdk, win32, png, svg, html canvas, pdf, postscript, opengl, xlib, quartz, etc. Only a few of them are actually usable and support has been removed for several others over the years. The number of sound back-ends on Linux is uncountable: ALSA, OSS, OpenAl, PulseAudio, Jack, Esound, PipeWire... It's never "just another back-end" because every back-end needs continuous testing and maintenance.
Poettering when designing systemd wisely, WISELY decided to not go the back-end route. Other free software hackers learn the hard way that multiple back-ends are expensive and rarely worth the cost.
Poettering when designing systemd wisely, WISELY decided to not go the back-end route. Other free software hackers learn the hard way that multiple back-ends are expensive and rarely worth the cost.
The problem is that everyone is doing their own thing instead of coming up with a common standard. That's kinda why Wayland is so hated.
What people seem to be misunderstanding about systemd is that it is not encroaching and forcing itself upon distros. It's the opposite. It's solving problems faster than anyone else and thereby wins by default. If there was a competing project that did the same things systemd did (the problem is that you need a whole collection of projects that are poorly integrated with each other), then you could start talking about standardizing things, but as of right now, systemd is spiritually the new Xorg of Linux.
What people seem to be misunderstanding about systemd is that it is not encroaching and forcing itself upon distros. It's the opposite. It's solving problems faster than anyone else and thereby wins by default. If there was a competing project that did the same things systemd did (the problem is that you need a whole collection of projects that are poorly integrated with each other), then you could start talking about standardizing things, but as of right now, systemd is spiritually the new Xorg of Linux.
> The problem is that everyone is doing their own thing instead of coming up with a common standard
I mean, there is a reason XKCD 927 is the most quoted to the point of attracting downvotes. It's pure cliché, so I wonder why you believe a common standard to rule them all is possible.
There is only one sane approach in software: opinionated configuration. Yet the free-software world somehow still clings to the utopia of multiple, freely interchangeable choices, and all you get is half a dozen unmaintained backends and just one that actually works for a number of years when someone forgets 927 and decides to reinvent the wheel, badly.
I mean, there is a reason XKCD 927 is the most quoted to the point of attracting downvotes. It's pure cliché, so I wonder why you believe a common standard to rule them all is possible.
There is only one sane approach in software: opinionated configuration. Yet the free-software world somehow still clings to the utopia of multiple, freely interchangeable choices, and all you get is half a dozen unmaintained backends and just one that actually works for a number of years when someone forgets 927 and decides to reinvent the wheel, badly.
This seems like it might impact systemd musl systems too, due to the NSS and getpwent requirement, right?
yay about time
yolkedgeek(1)
People want to understand their software as well as it's practically possible. It's not an uncommon preference; worse-is-better was quite successful for a reason. As systemd stands, it's an unauditable mess of tightly-coupled components built to handle any conceivable need. These features create new attack vectors: for instance, systemd-machined credential passing system, which can inject arbitrary files such as keys and configs into the guest, also runs on bare metal. And some are just running a musl system that can't even use systemd.
Some might look at the old SysV init scripts through rose-tinted glasses, but I don't think it represents the current state of the community. We have the modern OpenRC with parallel startup, dependency-based initialization, supervision, network management, and cgroups; dinit, which tries to imitate the 80% of systemd features that people use with 20% of its footprint; s6 with its supervision trees; runit that just works; and GNU Shepherd, which gives you an entire Scheme interpreter to configure your system.
Monocultures are bad because they eliminate competitive pressure for good design and create single points of failure that affect everyone. systemd was an excellent addition to the ecosystem in its day, but has become uncomfortably sticky: you can't just choose to replace systemd; you'll need to reimplement udevd, logind, D-Bus activation interfaces, and now userdb, all of which have their own subtle quirks you'll need to replicate. Look to the state of mdev or elogind and you'll see why it's not a sustainable compromise.