|
|
Log in / Subscribe / Register

GNOME deepens systemd dependencies

By Joe Brockmeier
June 23, 2025

Adrian Vovk, a GNOME contributor and member of its release team, recently announced in a blog post that GNOME would be adding new dependencies on systemd, and soon. The idea is to shed GNOME's homegrown service manager in favor of using systemd, and to improve GNOME's ability to run concurrent user sessions. However, the move is also going to throw a spanner in the works for the BSDs and Linux distributions without systemd when the changes take effect in the GNOME 49 release that is set for September.

Vovk's announcement started by noting that GNOME does not have a formal, well-defined policy about systemd dependencies. The rule of thumb, he said, was that GNOME doesn't absolutely depend on systemd, but some individual features of GNOME may break without it. But there is no project-wide policy that dictates that the project should avoid depending on systemd, even though GNOME has historically been available on many non-Linux operating systems and Linux distributions that do not use systemd as their service manager.

The now-retired GNOME wiki has a "What We Release" page published nearly 12 years ago that explained the GNOME release team's philosophy on dependencies and non-Linux systems clearly; the project is focused on "a tightly-integrated desktop environment based on the GNOME Shell running on a GNU-based operating system with a Linux kernel". Any non-Linux usage, such as running GNOME on a BSD, is considered a secondary concern.

Systemd, even then, was listed as a component that is encouraged but not required by GNOME. Wayland—which is soon to be the only supported display system for GNOME—is also named as a recommended (but not required) component. The page hasn't been ported to the GNOME Project Handbook that is still maintained, but GNOME's philosophy toward non-Linux usage and favoring systemd has not changed, even if it is not currently codified as a formal policy.

More systemd, fewer hacks

For about a decade, GNOME has had at least one strong dependency on systemd: its user-session manager, systemd-logind. In 2015, support for the ConsoleKit framework was completely removed in favor of systemd-logind. However, Vovk said, it is possible to use elogind—which is logind "extracted" from systemd as a standalone daemon. That made it possible for BSD distributions and others to run GNOME without systemd itself as a dependency. Now, GNOME is going to be gaining two more dependencies on systemd—and those will not be so easy to swap out. The first is systemd-userdbd, which will be used by the GNOME Display Manager (GDM).

Vovk said that GNOME and systemd do not support running more than one graphical session under a single user account—but GDM may need to display multiple login screens at once, so that multiple users can log into their own GNOME sessions on a system. So, GDM needs to start each graphical login session as a unique user.

To do this GDM has relied on "legacy behaviors and straight-up hacks" to provide multiple graphical sessions. Now, GDM can use systemd-userdbd to allocate user accounts dynamically and run each login screen as a unique user. That means that the hacks are going away, and GDM will require systemd-userdbd. Note that the unique users are only needed for the login screen instance; when a user logs in, the GNOME session runs as that user.

At some point, Vovk said, the systemd-userdbd dependency will extend further to replace the AccountsService daemon that GNOME uses to access user accounts and information about those accounts. "Now that systemd's userdb enables rich user records, we can start work on replacing AccountsService." Vovk said that AccountsService was meant to be a temporary solution, but it has now been in use for 15 years. In a discussion about the move, Rich Felker asked why a fallback implementation couldn't just pull user data from /etc/passwd and /etc/shadow as it had always done. Vovk said:

For one, /etc/passwd doesn't have any form of rich information about the user. No profile pictures, no ability to export any kind of user settings to the login screen, etc. It barely has the ability to store a display name (which is actually "GECOS" instead, which is... complicated for historical reasons). Userdb is json, so we can add new stuff to it whenever we want instead of going in and implementing weird side databases.

The JSON user records used by systemd-userdbd can include many things that are not available in the GECOS field. That format, which can trace its heritage back to the early 1960s and General Electric's General Comprehensive Operating System (GECOS), is more than a bit long in the tooth. The systemd JSON user-record format, on the other hand, can not only contain more biographical information about users, it can contain additional security credentials, resource-management settings, and more.

Goodbye GNOME service manager

GNOME has had a built-in service manager since its 2.x days that can be used by gnome-session to start and manage services. GNOME has mostly used systemd for service management since the 3.34 release, but it kept the built-in service manager as a fallback when systemd is unavailable—and because the "hacks" used by GDM for multi-seat support were incompatible with systemd. Since those are going away, Vovk said, the built-in service manager will be "completely unused and untested", so it is being removed. He said that getting rid of the legacy service manager would also make it possible to implement a session save and restore feature.

Vovk submitted a merge request to remove the built-in service manager on June 6. In the discussion there, Pablo Correa Gomez, who is a GNOME Foundation board member and has been working on adding systemd to PostmarketOS to make it easier to support GNOME (and KDE), said that he had conflicting feelings about the change. Wearing his GNOME-maintainer hat, he admitted that he had been "bitten many times before by the poor, old gnome-session management code". He agreed that the old code needed to go. But he was terrified by the change as a downstream maintainer:

We, at postmarketOS are working, and getting very close to good systemd integration. But Alpine Linux and quite some others are not. Removing the built-in startup on GNOME session basically means breaking support for quite a lot of people, and giving others quite a headache. Generally speaking, I think that is not good for anybody.

He said that the change needed public communication, a call for feedback, and a decision from the release team on the timing. He also thanked Vovk for doing the work and necessary cleanups "not just specifically related to systemd".

Vovk replied that the session manager was a blocker for a feature to be included in GNOME 49, presumably the dynamic users for GDM greeter sessions, though he did not specify. He noted that the announcement about the change was coming, and it would set out exactly what would need to be implemented to use GNOME 49 without systemd. "In short, I don't think it's an unreasonable amount of integration work." He also said that the removal of GNOME's session manager had already been discussed with the release team and approved.

In his announcement blog post, Vovk apologized for the short timeline, but said: "this blog post could only be published after I knew how exactly I'm splitting up gnome-session into separate launcher and main D-Bus service processes". One might quibble with that—certainly it's possible to announce that a component other projects depend on might be dropped soon, even if the exact details are not yet known. The affected parties will usually appreciate the courtesy of a heads-up and the opportunity to collaborate, as Gomez indicated.

What are the options for distributions that do not use systemd? Vovk suggests that they "consider using systemd"; failing that, they will have to implement replacements for the systemd components as has been done with elogind. He goes into some detail about what would be required; replacing the GNOME built-in service manager with another, rewriting the systemd unit files to work with the alternative service manager, as well as replacing gnome-session-ctl, which is a utility that coordinates between GDM, the D-Bus service, and systemd. That's all before upgrading to GNOME 49—in a future GNOME release, probably 50, non-systemd distributions will also need to implement even more systemd-userdbd features:

Finally: You should implement the necessary infrastructure for the userdb Varlink API to function. Once AccountsService is dropped and GNOME starts to depend more on userdb, the alternate code path will be removed from GDM.

Reactions

Alpine Linux founder Natanael Copa said that the move was frustrating: Alpine uses musl, instead of the GNU C Library (glibc), and musl is not currently supported by systemd. Luca Boccassi said that systemd was open to supporting musl as long as someone else reimplements the features musl lacks. Copa replied that "nobody has the time, will and skills to do the actual work, so now it looks like we are losing GNOME".

The Chimera Linux distribution, which we covered in January, uses the Dinit service manager and musl as its C library. Its founder, Nina Kolesa, said that she was not expecting GNOME to drop the gnome-session legacy code now; she expected it to be dropped much earlier, "given it's pretty much unused in everything except gdm and non-systemd distros". Replacing gnome-session in Chimera had been "the plan since forever", so GNOME's decision to drop it just hurried things along a bit. Kolesa dismissed complaints about the decision:

The legacy handling code is kinda terrible and janky, doing away with it is a good thing overall and if your non-systemd service manager is worth anything at all, you *can* replicate the same (better) approach.

On GNOME's Discourse forum, Noé Lopez said that he was looking into porting gnome-session to the GNU Shepherd service manager but needed more guidance than was available in Vovk's blog post. He understood the desire to drop old code, but collaboration was needed to avoid dropping a huge part of GNOME's user base. GNOME contributor Emmanuele Bassi said that he didn't think that a huge part of GNOME's user base was running a non-systemd-based distribution in 2025. Vovk replied to Lopez with a link to the merge request and invited him to reach out on the systemd mailing list with questions about systemd-userdbd. "I'll be happy to assist there".

Must GNOME be portable?

GNOME embracing systemd as a required component and/or a Linux-only desktop environment has been a recurring topic for many years now, going back to at least 2009 when Christian Schaller called for the release team to declare GNOME "a Linux desktop system as opposed to a desktop system for any Unix-like system". LWN covered Bastien Nocera's plan to make systemd a hard requirement for the power plugin in the GNOME settings daemon in 2012.

In addition to his activities on the GNOME release team, Vovk is also a contributor to GNOME OS, a distribution for testing and development of the GNOME desktop. At least, that's what it is today. Vovk has written about his vision to turn GNOME OS into an image-based "daily-drivable general purpose OS" with the goal of making it suitable for non-enthusiasts. Part of that vision includes dulling the "sharp edges" of Linux on the desktop in favor of a GNOME OS optimized for usability. From that perspective, cutting away the legacy bits that are needed for portability and focusing on a fully-controlled platform makes some sense.

As "mort" said on the Lobste.rs discussion forum:

There are many great alternatives which do slot neatly into the "desktop environment" hole, most notably KDE and XFCE. These are great projects and using one of them is probably a much better idea than to try to extract only the desktop environment-like part of GNOME to get it to run outside of the intended GNOME system. Personally, I'm excited to see what the GNOME folks are able to do when unconstrained by old traditions like "everything should be a self-contained puzzle piece which can slot together with any arbitrary set of other puzzle pieces".

GNOME has been flirting with systemd as a hard requirement for a long time; perhaps it's time to make it official so that there is no expectation that GNOME is portable beyond Linux systems with systemd. That will disappoint some users, perhaps many, but other desktop projects would likely welcome them—and their non-systemd requirements—with open arms.


to post comments

dbus-daemon dependency is gone

Posted Jun 23, 2025 15:38 UTC (Mon) by benzea (subscriber, #96937) [Link]

I believe this is the main commit referred to as using "legacy behaviors and straight-up hacks":

> https://gitlab.gnome.org/GNOME/gdm/-/commit/febeb9a9295fc...

You should finally be able to remove dbus-daemon from your system. I am really happy to see that Adrian finally fixed this!

Might be a good move

Posted Jun 23, 2025 15:40 UTC (Mon) by wtarreau (subscriber, #51152) [Link] (32 responses)

It's probably a good move for those seeking a windows-like environment where everything is tightly coupled. However, there are people whose first move from windows to linux used to result in "wow, that's fantastic, now I can observe, understand and tune everything, nothing's magically happening in my back". I remember my rare encounters with GNOME being among the ones giving me the strongest headaches, precisely feeling like I had absolutely zero control over the machine's behavior, and anything I took for granted based on well-established config files was no longer necessarily true in that world. But there's definitely a public for this, and making it official is not a bad thing. Users might split between those seeking again a bit more understanding and control, and those seeking a windows-like experience. There has always been two populations anyway. Maybe it will be the opportunity to officially describe it as "a graphical interface for systemd" to clarify the situation.

By the way reading some of the horrors in the description about the "need" to create users on the fly reminded me that some people long ago said that systemd tried to address the ultra-rare races where a pid could be reused and you kill the wrong process. But thinking that together they'll now be emitting uids on the fly for the purpose of dealing with multiple sessions... that's beyond me! What could possibly go wrong when using dynamic IDs? Will the next step require all users to have sudo permissions to be able to exchange files between sessions? Also I've been using multiple X sessions each with its own window manager for decades without having to handle multiple UIDs, so it looks to me like the whole monster has become so complicated architecturally speaking that new concepts have to be invented to circumvent previously designed problems... That's probably a never-ending story.

Might be a good move

Posted Jun 23, 2025 15:59 UTC (Mon) by smurf (subscriber, #17840) [Link]

> What could possibly go wrong when using dynamic IDs?

Given that (a) there is exactly one process that hands out those IDs and (b) in the context of this discusstion, the dynamic ID requirement is explicitly limited to GDM's login sessions and NOT to the user that's subsequently using the session:

Not much. In fact I'd challenge you to name something that *can* go wrong in this context.

Might be a good move

Posted Jun 23, 2025 16:00 UTC (Mon) by bluca (subscriber, #118303) [Link] (30 responses)

1) The ephemeral UIDs are for the _greeters_ not the user sessions - right now every distro just hacks it and creates a single shared system uid used for every greeter session, which I'm sure I don't have to explain why it's bad
2) dynamic UID/GID ranges have been in use for years and years, pretty much all container managers use them

Might be a good move

Posted Jun 23, 2025 23:49 UTC (Mon) by tux3 (subscriber, #101245) [Link] (29 responses)

I'm afraid I may be a little slow. For those in the back, why is a single greeter uid bad?

Might be a good move

Posted Jun 23, 2025 23:56 UTC (Mon) by pizza (subscriber, #46) [Link] (28 responses)

> I'm afraid I may be a little slow. For those in the back, why is a single greeter uid bad?

Just off the top of my head, compromising one won't give the attacker full access to the runtime state [1] of all of the others?

[1] Notably including any credentials entered

Might be a good move

Posted Jun 24, 2025 17:45 UTC (Tue) by linuxrocks123 (subscriber, #34648) [Link] (27 responses)

I don't think that's a realistic concern.

Unless there is absolutely no sanity left among mainstream Linux desktop programmers, there's no option to start a shell from those greeters. All you can do is click some stuff and enter text in the username and password fields.

Sure, I guess theoretically you could buffer overflow the username or password field, but since you (again, if there is any sanity left in this world) are limited to the ASCII keys you can physically type on the attached keyboard, it would be pretty damn hard to construct an exploit. And, hopefully, these greeters aren't so broken that someone is actually using something gets() on the user/pass fields, so there's unlikely to be a hole to exploit even if you could somehow find a way to exploit it once you found it.

If someone is actually worried about greeter exploits, why not just write a new greeter in Rust like the cascade of attention-deficit teenagers in charge of this space does with everything else? Why do something ridiculous like using temporary user IDs for xdm? Most machines are only going to be running one copy of xdm anyway, so, if someone can exploit xdm to send usernames/passwords to an attacker, you haven't substantially mitigated that problem by using temporary user IDs.

Might be a good move

Posted Jun 24, 2025 19:21 UTC (Tue) by pizza (subscriber, #46) [Link]

> Unless there is absolutely no sanity left among mainstream Linux desktop programmers, there's no option to start a shell from those greeters. All you can do is click some stuff and enter text in the username and password fields.

Maybe the "greeter" is sane, but can the same be said for everything in its tech stack?

> limited to the ASCII keys you can physically type on the attached keyboard,

1) What about non-password-based login mechanisms?
2) What about non-ASCII (especially CJK that requires more advanced input methods)
3) _Which_ attached keyboard/mouse[/camera/biometric/etc]?

> Why do something ridiculous like using temporary user IDs for xdm?

1) "Defense in depth"
2) It's a lot less work than "rewrite everything else" (and inevitably introduce a different set of bugs/regressions)

> Most machines are only going to be running one copy of xdm anyway,

....And what about those which don't?

Might be a good move

Posted Jun 24, 2025 20:00 UTC (Tue) by smurf (subscriber, #17840) [Link] (23 responses)

> All you can do is click some stuff and enter text in the username and password fields.

… and shut down / restart the system, and configure some assistive tools, and attach a Bluetooth keyboard, and read a 2nd factor USB key, and whatnot.

Most of this requires a working dbus server that's attached to a specific seat. The session dbus connection's socket is in, surprise, /run/user/UID/bus, unless you set an envvar (which has its own set of potential issues).

In other words, different and transient user IDs for each login screen aren't just a good idea from a security PoV, they also afford removal of a number of crude hacks and/or enabling tools that didn't want to work right before.

Might be a good move

Posted Jun 25, 2025 2:51 UTC (Wed) by linuxrocks123 (subscriber, #34648) [Link] (22 responses)

> … and shut down / restart the system, and configure some assistive tools, and attach a Bluetooth keyboard, and read a 2nd factor USB key, and whatnot.

Oh, dear. They really managed to overcomplicate things, now didn't they?

> Most of this requires a working dbus server that's attached to a specific seat. The session dbus connection's socket is in, surprise, /run/user/UID/bus, unless you set an envvar (which has its own set of potential issues).

DBUS to solve a problem that xdm has been solving without DBUS since 1988. Hilarious. And, because they managed to f* up what should be a simple GUI version of getty so badly, now they want to f* up UID management too to try to paper over that. ROFL. There truly is no sanity left among the cascade of attention deficit teenagers.

Ah, well. I'm over here with my Slackware, which will never incorporate any of this ongoing offense against good taste, so not my problem. And they do have version control, so they can always just revert all that nonsense when they grow up.

Might be a good move

Posted Jun 25, 2025 4:30 UTC (Wed) by jem (subscriber, #24231) [Link]

>> … and shut down / restart the system, and configure some assistive tools, and attach a Bluetooth keyboard, and read a 2nd factor USB key, and whatnot.
>Oh, dear. They really managed to overcomplicate things, now didn't they?

These are problems that have to be solved somehow. What if a workstation only has a bluetooth keyboard? It has to be recognized by the display manager.

Some time ago there was talk about a public sector Linux desktop. Logging in using a smart card is an absolutely essential requirement for the public sector in large parts of Europe. This is technically very similar to the USB key case, and requires talking to local hardware (the card reader).

Might be a good move

Posted Jun 25, 2025 7:45 UTC (Wed) by smurf (subscriber, #17840) [Link] (20 responses)

> DBUS to solve a problem that xdm has been solving without DBUS since 1988.

No it has not. Tried to do a 2FA login with xdm lately? Attach a Bluetooth keyboard? Turn on the Sticky Mods a11y helper so that a user who doesn't have the usual number of hands and/or fingers can log in?

You want to rewrite all of that to work directly as XDM plugins instead, be my guest, but I'd rather use whatever everybody else is using. Fewer bugs that slip through the cracks that way, not to mention vastly less pointless work.

Might be a good move

Posted Jun 25, 2025 17:15 UTC (Wed) by linuxrocks123 (subscriber, #34648) [Link] (19 responses)

> No it has not.

Yes it has too.

> Tried to do a 2FA login with xdm lately?

I don't use xdm. I use console logins at runlevel 3 and then start X if I want it. But, to answer your real question, 2FA is PAM's job, not the greeter's, so of course it would work work xdm.

> Attach a Bluetooth keyboard?

Those can be configured to auto-connect.

> Turn on the Sticky Mods a11y helper so that a user who doesn't have the usual number of hands and/or fingers can log in?

Seriously? You think no one bothered to think of sticky keys with xdm from 1988 to whenever Poettering started f*ing things up? Add +accessx to /etc/X11/xdm/Xservers and you're good.

> You want to rewrite all of that to work directly as XDM plugins instead, be my guest, ...

Traditional UNIX tools already work for these corner cases, and, since traditional UNIX tools are modular and well-designed, they work without requiring a Rube Goldberg service manager to do ghastly hacks like manipulate UIDs.

> ...but I'd rather use whatever everybody else is using. Fewer bugs that slip through the cracks that way, not to mention vastly less pointless work.

Popularity can help, but its effects plateau quickly. Software that is simple and well-designed generally inherently has fewer bugs at the outset, and it is also far less trouble to manage and configure than more complex software. Additionally, more mature software has had a much longer time to see its original bugs fixed.

Might be a good move

Posted Jun 25, 2025 17:41 UTC (Wed) by jem (subscriber, #24231) [Link] (18 responses)

>2FA is PAM's job, not the greeter's, so of course it would work work xdm.

The greeter needs to prompt the user to insert the token (USB key or smart card), and after that prompt for the PIN code. The greeter also needs to respond to errors, like if an invalid token is inserted or the wrong PIN code is entered.

Might be a good move

Posted Jun 26, 2025 6:51 UTC (Thu) by linuxrocks123 (subscriber, #34648) [Link] (17 responses)

Okay, so, before I get into this again, I hope you guys realize that the weird auth tricks you're saying XDM can't do are all also things the login program running on the gettys couldn't do and that creating a setup where the gettys on your machines all are broken would be an insane thing to do.

(Fortunately, XDM actually can do the weird auth tricks, because PAM is in charge of all of the weird auth tricks, and login can use PAM, too.)

> The greeter needs to prompt the user to insert the token (USB key or smart card), and after that prompt for the PIN code.

The primary enterprise 2FA security theater crap I've encountered has been in the form of "install this stupid app on your phone, and, when you try to log in, we will hang the login until you respond to a notification on your phone." The greeter obviously has no role in that.

The greeter also has no role in the alternative 2FA security theater I encountered when I told an organization I didn't have a cell phone that would work with the app they wanted me to use, so they sent me a Yubikey USB device where you press a button and it spits out a bunch of letters. If someone wanted to use that with PAM, they could claim the USB keyboard device created when a Yubikey is plugged in and hang the login until the button is pressed and the letters are spit out.

Since those are the only two situations I've personally encountered, I'm unfamiliar with the enterprise 2FA security theater crap you're describing. If you're using a password, a PIN, and a smart card all together, that would be 3FA in a way which seems pointless because the password and PIN are duplicative factors. But, I guess PAM could probably take the PIN and password munged together if someone really wants that. For this smart card, it looks like there's a PIN but no password, so you can just put the PIN in the standard password field: https://docs.oneidentity.com/bundle/safeguard-authenticat...

> The greeter also needs to respond to errors, like if an invalid token is inserted or the wrong PIN code is entered.

PAM will just fail the login if that happens. An administrator could find the reason in the logs if it keeps happening.

Might be a good move

Posted Jun 26, 2025 7:21 UTC (Thu) by mjg59 (subscriber, #23239) [Link] (13 responses)

> creating a setup where the gettys on your machines all are broken would be an insane thing to do

? No, this is an entirely normal thing. There's an expectation that the login environment be able to present things through audio, to change the colours it's presenting, to support touchscreen text entry, to support eyetracking input devices. There's a whole bunch of accessibility requirements that can never be satisfied by a text console, and that's just fine.

But even outside accessibility, yes, complex authentication is expected to fail in simpler environments. How does a console interface interact with PAM in such a way that you can choose which of the multiple authentication mechanisms with it should trigger with appropriate UI guidance? How does your getty login manage user choice of whether to use a password, fingerprint, or facial recognition? You may not care about these use cases, but the people deploying Linux in enterprise environments (including me) do.

Might be a good move

Posted Jun 26, 2025 14:24 UTC (Thu) by linuxrocks123 (subscriber, #34648) [Link] (12 responses)

> There's a whole bunch of accessibility requirements that can never be satisfied by a text console, and that's just fine.

Text console is one of the most inherently accessible interfaces for the blind because it is extremely easy to do text-to-speech with. I recently read a blog post by a blind Linux user in which he lamented that he's recently had to switch back to the console since GUI accessibility is degrading as GTK4 was adopted more, since GTK4 was released with some bad accessibility bugs. Unfortunately, I can't find it now. I think it was on BlueSky.

> How does your getty login manage user choice of whether to use a password, fingerprint, or facial recognition?

First thought that came to the top of my head was to put linuxrocks123-pass, linuxrocks123-finger, or linuxrocks123-facial in the the username field. You could put those instructions in /etc/issue for user friendliness, right below your standard enterprise all-caps threat that I'm sure is already there. (You know what I mean, that "ATTENTION: IF YOU DO SOMETHING WE DON'T LIKE WE WILL MAKE SURE YOUR LIFE BECOMES A LIVING A HELL" thing.)

Might be a good move

Posted Jun 26, 2025 17:49 UTC (Thu) by mjg59 (subscriber, #23239) [Link] (11 responses)

> Text console is one of the most inherently accessible interfaces for the blind

That's great, except you can't run a modern browser there so you're cut off from most of the world. But even then, accessibility isn't purely about people being blind, there's a giant array of other accessibility mechanisms that can't possibly work in a text-only world. Someone who needs to use an eye-tracking on-screen keyboard isn't going to do very well at the console.

> First thought that came to the top of my head was to put linuxrocks123-pass, linuxrocks123-finger, or linuxrocks123-facial in the the username field

Ah, so we'd encode additional logic into getty to parse out the PAM stack it should use? That'd probably work, and now we're starting down the road that gets you to the level of complexity modern graphical login environments have.

Might be a good move

Posted Jun 26, 2025 21:01 UTC (Thu) by linuxrocks123 (subscriber, #34648) [Link] (10 responses)

> That's great, except you can't run a modern browser there so you're cut off from most of the world.

https://www.brow.sh/
https://github.com/fathyb/carbonyl

> Ah, so we'd encode additional logic into getty to parse out the PAM stack it should use?

No, "getty" (you actually mean "login") wouldn't change. PAM would interpret the username and decide what to do based on the suffix. Or, if you don't like that, I guess you could type one of the actual password, "finger", or "facial", to select what you want to do at the password prompt.

Or you could just use pam_any to try all of them at once: https://github.com/ChocolateLoverRaj/pam-any

That would probably best for that situation.

Might be a good move

Posted Jun 26, 2025 22:28 UTC (Thu) by mjg59 (subscriber, #23239) [Link] (7 responses)

You're narrowly focusing on one aspect of accessibility and ignoring the much wider spectrum (there are people who use screen readers but still have enough vision that presenting them with graphics is worthwhile, for instance) which leaves me pretty convinced you don't actually care about accessibility - a text only interface is an option for a set of people who need accessibility features, and entirely unusable for another set. A graphical login system needs to handle those situations, which means it needs more complexity.

And shoving this into PAM in the way you describe breaks any users who have hyphens in their username, and running everything in parallel provides no indication to the user what they should be trying and is going to be confusing if the face recognition fails because they're looking down at their keyboard to find the fingerprint reader. The complexity that exists isn't gratuitous, it solves real problems for real people. You don't need to care about those problems, and you're free to run software that doesn't solve them. But I *need* software that solves these problems because I have users and policies that have these requirements and telling me that this software shouldn't exist doesn't make my problems go away.

Might be a good move

Posted Jun 27, 2025 23:08 UTC (Fri) by linuxrocks123 (subscriber, #34648) [Link] (6 responses)

If your usernames have hyphens then yeah type it in the password field.

> running everything in parallel provides no indication to the user what they should be trying and is going to be confusing if the face recognition fails because they're looking down at their keyboard to find the fingerprint reader.

As long as they find the fingerprint reader, they won't have a problem. pam_any is successful if *ANY* of the authentication options succeeds.

> The complexity that exists isn't gratuitous, it solves real problems for real people.

Agree to disagree.

> But I *need* software that solves these problems because I have users and policies that have these requirements

Not users, I wouldn't think, but, I am sure you have *policies* with those requirements, likely the same *policies* that gave CrowdStrike's customers so many problems a year ago (and serves them right, I'd say).

> telling me that this software shouldn't exist doesn't make my problems go away.

A problem doesn't exist because software that meets stupid requirements doesn't exist. A problem exists because someone has stupid requirements in the first place. Now, if you can't solve the "someone has stupid requirements" problem, then sure, maybe you do need to use or create software that meets the stupid requirements as a workaround.

But can't you at least cordon the stupid software off from the rest of the system and not make it the default? Must you really expand the attack surface of the login prompt so much that you then have to take heroic measures to give each individual login prompt its own UID to protect it from *other instances of itself*?

I'd say no. I'd say let the enterprise buffoons write their own greeter and maintain it themselves. But, I'm on Slackware, so none of this is my problem anyway.

Might be a good move

Posted Jun 27, 2025 23:16 UTC (Fri) by intelfx (subscriber, #130118) [Link] (1 responses)

> Agree to disagree.

That's not how it works.

"Agree to disagree" is only appropriate in situations when both sides have presented compelling, non-mutually-exclusive arguments, but can't decide *which* arguments have more weight. You haven't presented any, short of "I don't have that problem, so I don't care about solving it".

Might be a good move

Posted Jun 28, 2025 3:13 UTC (Sat) by linuxrocks123 (subscriber, #34648) [Link]

Agree to disagree :P

Might be a good move

Posted Jun 28, 2025 8:20 UTC (Sat) by jem (subscriber, #24231) [Link] (3 responses)

Let me tell you about a two factor authentication system I'm familiar with. In this system, every user has a smart card. To log in to a workstation, they insert the card into the reader and, if the card is valid, a PIN entry pop-up is displayed. After entering the correct PIN they are logged in.

No field for entering a user name is displayed, the user is identified from the certificate the card sends when the negotiating with the system. The backend system also checks that the user is authorized to log in by examining the certificate (which is digitally signed.)

The card also functions as a visual ID badge. When the user leaves their desk, they have to remove the card from the reader and carry it with them. This automatically locks the workstation.

Why a smart card? A smart card is designed to follow the Unix principle: do one thing, and do it well. The "one thing" in this case is to be a unique, extremely hard to forge physical token, designed to protect the private key of the user. A smart card also has a very small attack surface: a serial interface with a limited command set.

This system is in use all over the public sector here, nation wide. It has been in use for at least 15 years now. The workstations are running Windows, of course. Trying to sell a "Public sector Linux OS" as a replacement with this functionality haphazardly shoehorned into an XDM-like user interface is doomed from the beginning. That ship sailed a long time ago.

Might be a good move

Posted Jun 28, 2025 23:58 UTC (Sat) by linuxrocks123 (subscriber, #34648) [Link] (2 responses)

That sounds like both a cool setup and a fancy way to waste taxpayer money. Not super secure to be using a PIN instead of a password as the second authentication factor, though.

You could certainly make that work on Linux without any changes by just leaving the username empty and typing a password for the PIN, so I'm not sure why at you think it would present a problem for a standard greeter or why support would need to be "shoehorned". However, if you wanted to make the login UX superb, with a whizz-bang popup window saying "Hello <Name>" like you described, you could certainly make a custom greeter that watches for the device to be plugged in and then uses PAM to authenticate after plugging it in. You could do the auto-locking thing with a few custom udev rules and a script to do xscreensaver-command --lock when the key is removed.

Whether or not you wrote a custom greeter, you'd want the complexity in PAM so that people can still unlock xscreensaver by plugging in the device and typing the PIN in the xscreensaver password field.

In the end, these problems are not hard. There's no reason for these programs to be complex, and there are good reasons for them not to be.

Might be a good move

Posted Jun 29, 2025 10:52 UTC (Sun) by cortana (subscriber, #24596) [Link] (1 responses)

> Not super secure to be using a PIN instead of a password as the second authentication factor, though

"PIN" does not imply "4 numeric digits". But in any case - the smart card will only allow authentication attempts at a configured rate, and will lock down, preventing any further attempts after a certain number of failures.

> You could certainly make that work on Linux

sssd already implements all this AFAIK. At least, what jem describes is exactly how I use my YubiKey, except that I haven't enabled the option to lock the screen when it's unplugged, because I'm using this on my home systems and I often do want to have my laptop and desktop both active at the same time!

Might be a good move

Posted Jun 29, 2025 22:02 UTC (Sun) by linuxrocks123 (subscriber, #34648) [Link]

Good to know. It looks like pam_sss is the module that bridges sssd to standard login programs: https://linux.die.net/man/8/pam_sss

Might be a good move

Posted Jun 27, 2025 6:21 UTC (Fri) by smurf (subscriber, #17840) [Link] (1 responses)

> That would probably best for that situation.

Please accept the fact that there are many people out there who do not think, for various reasons (not all of which can be argued away), that "that situation" is acceptable these days.

NB: using expletives to describe these requirements ("security theater crap") and/or systemd and/or its implementation, goals or whatever doesn't help your case either.

Might be a good move

Posted Jun 27, 2025 23:14 UTC (Fri) by linuxrocks123 (subscriber, #34648) [Link]

> Please accept the fact that there are many people out there who do not think, for various reasons (not all of which can be argued away), that "that situation" is acceptable these days.

I don't think you're understanding the thread. There's a hypothetical situation where someone wants to do really weird auth, and we're talking about whether using PAM, which would work with every greeter, is better for that situation, or if it's better to create a greeter that handles the weirdness in the greeter itself. I hope that helps.

Might be a good move

Posted Jun 26, 2025 22:32 UTC (Thu) by elsandosgrande (subscriber, #174457) [Link] (2 responses)

> PAM will just fail the login if that happens. An administrator could find the reason in the logs if it keeps happening.

Do you mean that the login manager shouldn't report errors to the user at all, that it should just report a generic “login failed” error and that the user or administrator then should look in the system log(s) to see the details of said failure, or …? Neither of the two interpretations of your statement that I can think of right now sound like a great user experience compared to the login manager giving the user at least a bit more information regarding login failures.

Might be a good move

Posted Jun 27, 2025 23:27 UTC (Fri) by linuxrocks123 (subscriber, #34648) [Link] (1 responses)

> Do you mean that the login manager shouldn't report errors to the user at all, that it should just report a generic “login failed” error and that the user or administrator then should look in the system log(s) to see the details of said failure, or …? Neither of the two interpretations of your statement that I can think of right now sound like a great user experience compared to the login manager giving the user at least a bit more information regarding login failures.

mjg59 got into a bit of a stupid argument about whether it would work at all, not whether it would work well. Yes, of course an ideal greeter would say why the login failed. pam_info is the function that allows that message to be printed, but it has some prereqs that mean I don't think it actually works with the current versions of login and xdm. I expect that would be easy to fix if someone wanted to fix it.

Might be a good move

Posted Jun 28, 2025 23:59 UTC (Sat) by linuxrocks123 (subscriber, #34648) [Link]

Meant to say "mjg59 and I got into a bit of a stupid argument"

Might be a good move

Posted Jun 24, 2025 21:36 UTC (Tue) by Cyberax (✭ supporter ✭, #52523) [Link] (1 responses)

> Sure, I guess theoretically you could buffer overflow the username or password field

Some password greeters can do remote calls to LDAP, there can be greeters that can do a 3D scan of your face with a call to a remote service to validate it, etc. That's quite a sizeable attack surface.

And I have personally seen a greeter that opens a browser and does an SSO login to retrieve the user's details.

Might be a good move

Posted Jun 25, 2025 3:35 UTC (Wed) by linuxrocks123 (subscriber, #34648) [Link]

> And I have personally seen a greeter that opens a browser and does an SSO login to retrieve the user's details.

I actually wrote a greeter like that for a university! The browser was locked down, of course. It was a very unusual set of requirements.

probably not a huge deal, but bigger implications

Posted Jun 23, 2025 15:42 UTC (Mon) by calvin (subscriber, #168398) [Link] (34 responses)

I suspect what will happen is like with elogind, someone will provide a systemd-free version of the interfaces that Gnome needs out of systemd. I don't think it's tight coupling as much as it's one of the few interfaces to do what they want without having to reimplement a worse service manager themselves. Support for another service manager could be added, or an adapter for that API.

I think the bigger insight is: the system layer is pretty important (see Benno Rice's talk); perhaps there should be an effort to make that kind of functionality available across OSes, and have an API for it. The POSIX of service management, if you will.

probably not a huge deal, but bigger implications

Posted Jun 23, 2025 15:56 UTC (Mon) by wtarreau (subscriber, #51152) [Link] (33 responses)

> the system layer is pretty important (see Benno Rice's talk); perhaps there should be an effort to make that kind of functionality available across OSes, and have an API for it. The POSIX of service management, if you will.

But IMHO there's already such an API, it's based on config files, /dev entries and reasonably portable commands like mount, ps, etc. It has worked for a very long time. Even 25 years ago, the CDE environment was very well integrated with multiple proprietary operating systems without having to require deep OS-level changes. You could perfectly well click on a CD icon to mount a CD for example, listen to wav files, or see notifications when you had mails.

I'm not really sure what is being attempted these days by making all this stuff so much complicated, brittle and resource hog, but it must be profitable to someone (maybe users?) or maybe it's self-feeding.

probably not a huge deal, but bigger implications

Posted Jun 23, 2025 16:44 UTC (Mon) by Wol (subscriber, #4433) [Link]

> I'm not really sure what is being attempted these days by making all this stuff so much complicated, brittle and resource hog, but it must be profitable to someone (maybe users?) or maybe it's self-feeding.

Ooh - new! shiny!

Unfortunately grey beards are not normally shiny.

As Ecclesiastes said, there's nothing new under the sun. Unfortunately the young turks keep re-inventing the wheel - isn't that part of what being a young turk is?

Cheers,
Wol

probably not a huge deal, but bigger implications

Posted Jun 23, 2025 17:39 UTC (Mon) by calvin (subscriber, #168398) [Link]

Can you point me to a standard Unix API for managing processes? Even before systemd, System V and BSDs had their own things, and they lacked a general API for building supervision trees, especially at a per user or session level.

Your memories of CDE aren't also quite accurate - there was a ton of vendor customization of CDE. Solaris, for instance, had its own automounter that they had CDE integrate into. The other vendors had their own and they were all proprietary and different in their own ways. The current state of affairs with fd.o presenting a single interface for i.e. UDisks or whatever is much better than what we had in the 90s. A lot more complicated than mount(8)...

probably not a huge deal, but bigger implications

Posted Jun 23, 2025 17:48 UTC (Mon) by jafd (subscriber, #129642) [Link]

My memory is that the "API" we had so far, based on "config files, /dev entries and reasonably portable commands like mount, ps, etc." has been, as you put it, "so much complicated, brittle and resource hog".

There are reasons every desktop environment in existence comes with its own "session manager" (one is that before systemd, there was nothing portable or uniform to manage the user session at all, and no, a 4,000-line bashrc ain't it). In my older days, playing audio used to be related to a wonderfully refreshing experience of using lsof to find who was holding up the sound hardware this time. Using removable media was invariably connected with a cornucopia of permission errors, then begrudgingly dropping to a root shell.

Sure, you could count on the commands to be "reasonably portable", for some values of "reasonable", but there are all sorts of hooks and crooks when it comes to actually using them all together and making assumptions about things. Look at the old sysvinit scripts for popular services — you can see how they grew in response to edge cases being discovered. They are very far from being simple. Knowing and understanding them could sure bring joy to someone fond of collecting arcane bits of knowledge.

probably not a huge deal, but bigger implications

Posted Jun 23, 2025 18:25 UTC (Mon) by ballombe (subscriber, #9523) [Link] (15 responses)

Use xfce, xfce is what CDE tried to be but never achieved.

probably not a huge deal, but bigger implications

Posted Jun 23, 2025 18:52 UTC (Mon) by joib (subscriber, #8541) [Link] (14 responses)

I recall xfce 2.x and 3.x having some resemblance to CDE, but the current XFCE 4.x, not so much.

probably not a huge deal, but bigger implications

Posted Jun 23, 2025 18:56 UTC (Mon) by jzb (editor, #7867) [Link] (13 responses)

Users can still theme Xfce to look like CDE if that happens to be their preference.

Funny enough, I used to think CDE was hideous—but I have to admit, it's grown on me over the years. Probably just nostalgia...

probably not a huge deal, but bigger implications

Posted Jun 23, 2025 21:30 UTC (Mon) by wtarreau (subscriber, #51152) [Link]

> I used to think CDE was hideous

I always found it hideous as well :-) And super slow. But it did work on a 64 MB machine at 300 MHz. Standards have changed!

probably not a huge deal, but bigger implications

Posted Jun 24, 2025 6:39 UTC (Tue) by joib (subscriber, #8541) [Link] (1 responses)

CDE was(is?) hideous, but I used xfce 2.x for some years due to being used to the UI from using a precursor to CDE at a summer job (HP VUE).

Not sure whether I should be happy or horrified that it's possible to recreate that look with modern xfce. ;-)

CDE as XFCE gateway

Posted Jun 24, 2025 12:26 UTC (Tue) by dskoll (subscriber, #1630) [Link]

Yes! I had a job on Solaris running CDE, and I discovered XFCE which at the time was very CDE-like.

I'm still happily using XFCE4 even though it's no longer particularly CDE-like. The XFCE developers are very conservative about changes to look and feel, and my muscle memory appreciates that.

probably not a huge deal, but bigger implications

Posted Jun 24, 2025 9:46 UTC (Tue) by paulj (subscriber, #341) [Link] (8 responses)

CDE looked clunky and ugly, when you were used to OpenLook!

probably not a huge deal, but bigger implications

Posted Jun 24, 2025 11:34 UTC (Tue) by joib (subscriber, #8541) [Link] (7 responses)

It was even possible to run openlook on Linux. Alas, IIRC it was never open source so you had to download and compile it and whatever applications needed the libs yourself instead of using something packaged by the distro of your choice. I think I tried it out sometime, as I had sometime visited my fathers workplace where they had these Sun workstations with for the time humongous 21" screens. Albeit grayscale, but still glorious.

probably not a huge deal, but bigger implications

Posted Jun 24, 2025 12:40 UTC (Tue) by paulj (subscriber, #341) [Link] (6 responses)

Yes, there was 'olwm' - OpenLook Window Manager. Unfortunately the OpenLook toolkit was never released with source, AFAIK. A lower level XView toolkit was, but I don't think much used it (?). The ability to pin windows - literally with a little virtual pin - was nice in OpenLook.

The Silicon Graphics "Indigo Magic Desktop" was also nice, with some nice widgets. Like a little thumbwheel for zooming in and out of views, and sliders that looked like sliders. Very nice. Motif based, so the later CDE didn't look /too/ different from it (indeed, CDE surely took a lot of cues from IMD).

University I went to had a lab full of SparcStation 1's and 1+'s with OpenLook, and another lab full of Silicon Graphics Indy's with IMD. Such amazing machines at the time (the Indy's particularly). Unix OSes and their desktops were just light years ahead of Win3.11 and Win95 PCs, and their underlying MSDOS.

probably not a huge deal, but bigger implications

Posted Jun 24, 2025 14:25 UTC (Tue) by paulj (subscriber, #341) [Link] (5 responses)

I wish WindowMaker were still actively developed. That was my preferred WM for many a year. Unfortunately, it isn't really useable on laptops - can't cope with switching/extending displays.

probably not a huge deal, but bigger implications

Posted Jun 24, 2025 14:53 UTC (Tue) by wtarreau (subscriber, #51152) [Link] (1 responses)

> I wish WindowMaker were still actively developed. That was my preferred WM for many a year. Unfortunately, it isn't really useable on laptops - can't cope with switching/extending displays.

Not really sure what you mean, I *am* using it on a laptop and have dealt with screen size changes every time I connect it to an external projector. When the external size is larger than yours, the only thing is that if you stored your icons on the right, they stay at their absolute position (which can become 2/3 of the screen), but everything works fine for me.

probably not a huge deal, but bigger implications

Posted Jun 24, 2025 16:35 UTC (Tue) by paulj (subscriber, #341) [Link]

Huh, you don't need to restart WindowMaker when you change res or monitor? Did the new maintainer update WM and make it cope dynamically with resolutions at last? :)

probably not a huge deal, but bigger implications

Posted Jun 26, 2025 19:04 UTC (Thu) by jmalcolm (subscriber, #8876) [Link] (2 responses)

Check out WaylandMaker

https://github.com/phkaeser/wlmaker

probably not a huge deal, but bigger implications

Posted Jun 27, 2025 10:58 UTC (Fri) by paulj (subscriber, #341) [Link] (1 responses)

If that works well enough, that may overturn my inner kurmudgeon's "Sigh, am I really going to have to change my whole desktop?" feeling towards Wayland. ;)

Thanks!

probably not a huge deal, but bigger implications

Posted Jun 27, 2025 12:42 UTC (Fri) by smurf (subscriber, #17840) [Link]

Heh. I feel with you. A few months ago I switched my desktop from Gnome to Sway because I couldn't stand the bloat any more.

Not looking back.

Not looking forward to converting my laptop either, but that's a different topic.

probably not a huge deal, but bigger implications

Posted Jun 24, 2025 13:49 UTC (Tue) by clump (subscriber, #27801) [Link]

That is an impressive screen shot. The colors, fonts, and lines gave me a rush of nostalgia.

I can imagine the mouse pointer changing window colors when hovering, and the right click menu disappearing when you release the button.

probably not a huge deal, but bigger implications

Posted Jun 23, 2025 18:53 UTC (Mon) by parametricpoly (subscriber, #143903) [Link] (13 responses)

> It has worked for a very long time

Yes, if you measure system's functionality by the fact that things somehow seem to work, mostly, and some graphics appears on the screen (if not, just reboot), then yes... quite ridiculous that many x11 based greeters still run as root (e.g. https://github.com/canonical/lightdm/issues/18), no proper isolation. Since Covid, many have had a flexible office. GECOS is such a stinking pile of garbage, no wonder most users doesn't use it at all.

probably not a huge deal, but bigger implications

Posted Jun 23, 2025 21:35 UTC (Mon) by wtarreau (subscriber, #51152) [Link] (12 responses)

> GECOS is such a stinking pile of garbage, no wonder most users doesn't use it at all.

And what's the next step ? Drop support for /etc/passwd and /etc/shadow and force users to use yet another GNOME mega-application to edit an entry from the local console ? Have them run an imitation of regedit to change their UID ? We're progressively but surely going away from the KISS principle that has made UNIX-based systems last 5 decades, and slowly turning them into a single megalith that nobody understands and that newcomers will denounce as the pest to combat like windows was pointed the finger at 25 years ago. We might reach a point where the stuff will have become so complex and boring that nobody will want to hack on it anymore and it will die by itself in boredom.

probably not a huge deal, but bigger implications

Posted Jun 23, 2025 23:39 UTC (Mon) by parametricpoly (subscriber, #143903) [Link]

The article clearly stated the problem. There's a need to convey extra metadata related to the user. That field is a time capsule to 1960s. What would be your solution?

probably not a huge deal, but bigger implications

Posted Jun 24, 2025 0:32 UTC (Tue) by pizza (subscriber, #46) [Link]

> Drop support for /etc/passwd and /etc/shadow

You say that as if it's a bad thing.

In the real world, requiring all processes performing authentication to (1) run as root and (2) work with plaintext credentials is both (i) a major security weakness (that has been exploited countless times) and (ii) severely limits the sorts of authentication mechanisms one can use.

> We're progressively but surely going away from the KISS principle that has made UNIX-based systems last 5 decades, and slowly turning them into a single megalith that nobody understands and that newcomers will denounce as the pest to combat like windows was pointed the finger at 25 years ago.

User info and authentication hasn't been obtained directly from /etc/passwd(etc) since Unix System V Release 4 in *1988*, instead proxying through the libc's NSS to allow for NIS and other directory services to be transparently used. This was later augmented by PAM (1996) and SSSD (mid-late 2000s), which in turn could be plugged into countless other user authentiction/directory services.

"KISS" ended nearly 40 years ago, out of the necessity of working in the real world.

probably not a huge deal, but bigger implications

Posted Jun 24, 2025 2:10 UTC (Tue) by smurf (subscriber, #17840) [Link]

> And what's the next step ? Drop support for /etc/passwd and /etc/shadow

Lots of places already did. Did you ever try to edit /etc/passwd when the name displayed by your company's Active Directory server was wrong?

systemd's user info server isn't yet another huge thing you need tooling for. It's mainly an aggregator. You can plug a parser for /etc/passwd+shadow into it, or AD, or whichever other service you want. It's a protocol, not an API or (worse) a file format from the 70s/90s that can't evolve and can't be extended. There's strict separation of concerns (in contrast to libpam and related ugliness).

probably not a huge deal, but bigger implications

Posted Jun 24, 2025 3:03 UTC (Tue) by mjg59 (subscriber, #23239) [Link] (5 responses)

If your expectation is that you can look up a user in /etc/passwd then that hasn't been true for decades - even if we choose to ignore NIS as a Sun special, Project Athena had come up with Hesiod in the 80s, and modern enterprise environments are almost certainly using some form of LDAP (either natively or via Active Directory). At some point it becomes necessary to consider whether continuing to apply bodges on top of the existing infrastructure ("Your password is here, unless it isn't, in which case you need to know which backend to query to find it") is genuinely simpler than replacing it with unified tooling that caters to the modern world rather than one which envisaged managing hostnames by just having people mail out updates to /etc/hosts

probably not a huge deal, but bigger implications

Posted Jun 24, 2025 6:35 UTC (Tue) by joib (subscriber, #8541) [Link] (4 responses)

There was also some effort by the sssd people some years ago to provide a dbus service to query also local users in some unified way and provide more info than possible with NSS&PAM, but seems it never went anywhere and support was eventually ripped out from the codebase.

So now systemd is trying the same. Will it allow some unification and simplification, or the opposite if applications will need to support that in addition to classical NSS&PAM along with some ad-hoc kludge to provide more info if necessary, and the sssd thing if that was ever supported? I guess one can only try and hope it gains more or less universal adoption, but there's a risk this will just increase complexity rather than reduce it.

probably not a huge deal, but bigger implications

Posted Jun 24, 2025 7:43 UTC (Tue) by smurf (subscriber, #17840) [Link]

> provide a dbus service

The problem with dbus is (a) its access rights model, which is surprisingly complex and a source of subtle security errors, (b) libdbus isn't exactly easy to integrate, (c) hey now your passwords pass through yet another daemon what could possibly go wrong.

systemd has a plugin for PAM, so your the legacy(-ish) tooling will continue to work. The other way 'round, there's the io.systemd.Machine provider.

probably not a huge deal, but bigger implications

Posted Jun 24, 2025 14:20 UTC (Tue) by rjones (guest, #159862) [Link] (2 responses)

I've always just used 'getent' to look up users and groups.

This leverages nss and thus works regardless of what service is sourcing the id numbers for these things. This includes the systemd dynamic uids, which is also exposed via nss with the nss-systemd module.

Cat your /etc/nsswitch.conf to confirm. You should see 'systemd' listed there after files, etc

I don't think there is anything special that applications need to do to support anything at this point. Even if /etc/passwd was to magically disappear.

probably not a huge deal, but bigger implications

Posted Jun 24, 2025 14:53 UTC (Tue) by joib (subscriber, #8541) [Link] (1 responses)

NSS, despite its architectural shortcomings, roughly does what it was designed for, and support for it is indeed near universal, from things like getent to the various user/group querying APIs in libc that applications use to look up info.

Problem here seems to be a desire to associate additional info to a user, not possible in the NSS data model. Like a picture of the user, email address, fully qualified username (name@DOMAIN), etc. Sssd having a go at this failed, remains to be seen whether the systemd approach will turn out to be more successful.

probably not a huge deal, but bigger implications

Posted Jun 25, 2025 11:07 UTC (Wed) by rjones (guest, #159862) [Link]

Oh, well that make sense.

Took a quick look at JSON Group Record and JSON User record from Systemd's documentation it all seems very reasonable and not any different then what people have already been doing for decades with LDAP.

It would be nice to have a nice way for users to set their picture, email address, timezone, default language, security keys, etc. in a saner manner. None of that seems crazy or undesirable.

And since systemd-userdb provides support for multiple backends then it can provide a unified interface for retrieving and interacting with LDAP and other sources of user information people already use and rely on while systemd-homed provides feature parity for people not using any of those services.

If it all works out then it should represent a nice improvement and simplification of the OS over the status quo.

probably not a huge deal, but bigger implications

Posted Jun 24, 2025 7:16 UTC (Tue) by zdzichu (subscriber, #17118) [Link] (2 responses)

I vaguely remember some distributions dropping /etc/passwd. The replacement was a directory tree somewhere in /etc, each user-representing directory owned by that user. Inside were files for metadata like real name, a symlink to the shell etc.

I can't find it now, but Openwall's TCB (https://www.openwall.com/tcb/) looks similar. Or maybe that was something from GoboLinux? Or maybe T2 SDE? Nevertheless, life without /etc/{passwd,shadow} is possible and even quite pleasant.

probably not a huge deal, but bigger implications

Posted Jun 24, 2025 10:01 UTC (Tue) by dottedmag (subscriber, #18590) [Link]

It was ALT Linux probably, it uses TCB.

probably not a huge deal, but bigger implications

Posted Jun 24, 2025 18:15 UTC (Tue) by adobriyan (subscriber, #30858) [Link]

This is likely to make updates non-atomic.

Individual GNOME applications

Posted Jun 24, 2025 5:40 UTC (Tue) by SiB (subscriber, #4048) [Link] (36 responses)

The only thing from GNOME that I am using is gnumeric.
Will it become difficult or impossible to run individual applications with sysv and X11?

Individual GNOME applications

Posted Jun 24, 2025 6:58 UTC (Tue) by ebee_matteo (guest, #165284) [Link] (16 responses)

No, I don't think this will be a problem in the short term.

At some point the move to wayland will kinda kick in, and then I expect X11 to slowly go away simply because there seem to be a strong dip in number of commits/bugfixes. Certain things like HiDPI and multiple monitor setups that are expected by modern users are very difficult to add to X11. But wayland is quickly closing the gap. Running old applications requiring X under Wayland is mostly fine by now.

But at the end, it's a matter of effort and distro support. As long as there are enough sysv or openrc users around willing to support them, it will keep working. Maybe not with GNOME, but there are other DEs out there. Systemd also has a compatibility layer for sysv.

The reality is that Linux is becoming more successful also for enterprise workstations. Which is what most of us always wished for, right? More "market share". That means that covering a lot of use cases that are "enterprise" in nature (e.g. Microsoft Entra ID interoperability) is mandatory to stay relevant. These were not as important before. Now businesses which are financing development are strongly pushed to cater for these requirements. Read Red Hat, for instance, from governments and companies around the globe.

At some point, we need to understand that we are somewhat victims of our own success. The system becomes more complicated because it needs to, not just because some youngsters think reimplementing everything is fun. This is an hobbyist system becoming finally mainstream, and having to respond to regulatory and interoperability constraints.

Individual GNOME applications

Posted Jun 24, 2025 8:18 UTC (Tue) by pabs (subscriber, #43278) [Link]

The systemd compat layer for sysv init scripts got removed btw. It is a systemd generator though, so in theory you could split it out of an old systemd version and run it on a new systemd version, maybe with some changes.

Individual GNOME applications

Posted Jun 24, 2025 8:19 UTC (Tue) by pabs (subscriber, #43278) [Link] (3 responses)

I thought RedHat was moving away from workstation stuff towards cloudy things?

Individual GNOME applications

Posted Jun 24, 2025 17:36 UTC (Tue) by pbonzini (subscriber, #60935) [Link] (2 responses)

Workstation is certainly not a major revenue source but it still exists.

What you might remember is moving away from supporting all apps in favor of flatpak—one major example being LibreOffice.

Individual GNOME applications

Posted Jun 25, 2025 5:28 UTC (Wed) by ebee_matteo (guest, #165284) [Link]

Government contracts, especially in some European and Asian countries, are consistent.

Individual GNOME applications

Posted Jun 26, 2025 3:35 UTC (Thu) by pabs (subscriber, #43278) [Link]

Yeah, and some other apps like Evolution that they were funding. I wonder if they just dropped those apps, or are funding the Flatpak versions instead?

Individual GNOME applications

Posted Jun 24, 2025 9:56 UTC (Tue) by paulj (subscriber, #341) [Link] (3 responses)

> Certain things like HiDPI and multiple monitor setups that are expected by modern users are very difficult to add to X11.

That's news to me. I've been running X11 on my Dell XPS laptop with (very) HiDPI and plugging in and out of external monitors since I got that laptop - and it's at least a decade old. (There were HiDPI issues initially, they are largely gone - before Wayland was a useable thing).

Individual GNOME applications

Posted Jun 24, 2025 9:57 UTC (Tue) by paulj (subscriber, #341) [Link]

Oh, and multi-monitor support works _better_ in X11 than it does in MS Windows (which I was forced to use at an employer - which I did mostly as a GUI shell around WSL; but Windows _really_ sucks at multi-monitor, constantly forgetting which windows had been on which monitors particularly, very very annoying).

Individual GNOME applications

Posted Jun 24, 2025 16:32 UTC (Tue) by smurf (subscriber, #17840) [Link] (1 responses)

It's not news to me. There's still lots of programs that don't work correctly with HiDPI under X11. No, not just games.

Also, don't even think about trying to span monitors of disparate resolution with a single window.

Also² don't get me started on other silly assumptions in the X11 codebase. Simple example: Wayland thinks that negative pointer coordinates are a perfectly cromulent thing to have. Xwayland does not. You guess what happens on my monitor setup, where monitor #2 is mounted 120 pixels higher than #1.

Individual GNOME applications

Posted Jul 19, 2025 14:27 UTC (Sat) by daenzer (subscriber, #7050) [Link]

FWIW, per the discussion starting at https://gitlab.freedesktop.org/xorg/xserver/-/merge_reque... , while this could be fixed in Xwayland in theory, it would be really tricky to catch all affected code. And it could likely still confuse some X clients.

Making the Wayland compositor not advertise any outputs at negative locations to Xwayland, while technically a workaround, should be a much easier solution overall.

Individual GNOME applications

Posted Jun 25, 2025 8:38 UTC (Wed) by patrick_g (subscriber, #44470) [Link] (6 responses)

> Certain things like HiDPI and multiple monitor setups that are expected by modern users are very difficult to add to X11

How can we be sure it's true? Have you seen that post from Ted Unangst?
https://flak.tedunangst.com/post/forbidden-secrets-of-anc...

Individual GNOME applications

Posted Jun 25, 2025 8:48 UTC (Wed) by pbonzini (subscriber, #60935) [Link] (5 responses)

The problem is having mixed resolutions, stuff at one high DPI external monitor and a low DPI laptop screen. Bonus points for rendering at one resolution and zooming to the other when a window is moving between one screen and the other.

Individual GNOME applications

Posted Jun 25, 2025 10:06 UTC (Wed) by smurf (subscriber, #17840) [Link] (4 responses)

For even more fun, try a window that spans both screens. Doesn't work: depending on the phase of the moon you either have a half window that's way too large, or one that's way too small.

This is a fundamental X11 protocol limitation.

Granted that you could "fix" this by creating a virtual high-res screen that replaces your low-res one, then downscale onto the latter, but (a) the result looks somewhere between ugly and unusable if you want do to Real Work, (b) we're way beyond the point where the heap of hacks and extensions that has been piled onto the original X11 protocol stopped being maintainable in a meaningful way.

Individual GNOME applications

Posted Jun 25, 2025 12:37 UTC (Wed) by dskoll (subscriber, #1630) [Link] (3 responses)

I have an X11 setup with four monitors, and I can move a window so half of it is on one monitor and the other half on another and it works just fine. Perhaps I am not quite getting what you mean when you write "try a window that spans both screens."

Individual GNOME applications

Posted Jun 25, 2025 13:29 UTC (Wed) by farnz (subscriber, #17727) [Link] (2 responses)

If you have different scale factors for each screen, so that windows appear the same size as they cross the boundary even though the screens have different native PPI, you'll see the issue on X11, but not Wayland. You won't see this with 4 monitors of same diagonal size and resolution.

Under X11, the display is represented as a single large buffer, rectangular sections of which are sent to scanout. Scaling is applied to content as the window content goes from the application's internal representation to the buffer, and this scale factor is the same for all monitors (whether that's the 200 PPI laptop display I'm using as a second screen, or the 150 PPI external monitor I use as my primary display). As a result, I cannot set a scale factor that's right for both monitors - there will always be a discontinuity at the seam, because X11 assumes that something 1,000 pixels high on my laptop screen is visually the same height as something 1,000 pixels high on my external screen, and that's not true (on my laptop screen, that's about 5 inches, on my external screen, it's a bit over 6.6 inches).

Wayland's architecture works differently; the display is considered as-if it's composited from individual windows at scan-out time. The compositor and the application negotiate the window's scaling factor, so the application knows that it's rendering something that's visually meant to be 1,000 abstract units high, but that it's being expected to render (say) a 2,000 pixel high buffer that will be scaled down by the compositor. The compositor can then scale that down to 1,500 pixels on my external monitor (10 inches), and display it at 1:1 on my laptop screen (10 inches), making it look the same on both monitors.

Wayland can also renegotiate the scaling as windows move; so when a window is on my external monitor only, the application can know that it'll be rendering a 1,500 pixel high buffer, which will be rendered as-if it filled 1,000 abstract units of space, while moving that window to my laptop screen gets the same application told to render to a 2,000 pixel high buffer, which will be rendered as-if it filled 1,000 abstract units.

Individual GNOME applications

Posted Jun 25, 2025 15:00 UTC (Wed) by paulj (subscriber, #341) [Link] (1 responses)

Hmm... the thing is, you can still change the resolution on external monitors to suit. You don't per se need to have Linux do the scaling.

The only time I notice scaling issues now is with xpra to apps running on a server and I havn't set dpi to 48 with xrandr. It doesn't seem to affect any local apps on the HiDPI laptop, but scaling of /1/ particular app (which seems to use some custom toolkit in Java that renders via OpenGL) can be off. Other than, things have been fine for years, with my HiDPI laptop and the monitors I plug into anyway (1 of which is one of those large, v wide Dell ones).

Individual GNOME applications

Posted Jun 25, 2025 15:12 UTC (Wed) by farnz (subscriber, #17727) [Link]

Well, depends on the display and the attachment method; my external monitor flickers wildly at any resolutions other than CEA-861 predefined resolutions (and I've not bothered to work out why - there's a firmware update available, but I'd have to get a Windows machine sorted to apply it). No trouble at 640x480, 2880x576, 1280x720 or 3840x2160, but huge trouble at 2560x1440@60Hz. I therefore need Linux to do the scaling, because the scale I'm asking for would need the monitor to run at 2560x1440.

And I also find that Linux is better at doing the scaling than the monitor is; text is easier to read when the application renders for a 5120x2880 monitor, and then the compositor downscales to 3840x2160, than it is when the application renders for 2560x1440, and the monitor or the compositor upscales to 3840x2160.

Individual GNOME applications

Posted Jun 24, 2025 8:16 UTC (Tue) by pabs (subscriber, #43278) [Link] (17 responses)

GTK intend to drop X11 support with GTK 5:

https://blog.gtk.org/2025/02/01/whats-new-in-gtk-winter-2...

So you would need to switch to a Wayland compositor, a way to run Wayland apps on an Xorg server, or a multi-protocol display server like Arcan or Mir.

https://arcan-fe.com/
https://mir-server.io/

Individual GNOME applications

Posted Jun 24, 2025 10:12 UTC (Tue) by ebassi (subscriber, #54855) [Link] (16 responses)

>> Will it become difficult or impossible to run individual applications with sysv and X11?

GTK never depended on whatever init system or middleware layer you're using. Only the display server is relevant for, you know, a GUI toolkit.

> GTK intend to drop X11 support with GTK 5:

Dropping the native X11 backend is only ever going to be a problem if Gnumeric is ported to GTK5, which is fairly unlikely to happen within the next 10 years. Gnumeric developers **will** need to port to GTK4 at least, though, because once GTK5 is out, GTK3 will be EOL'ed; nevertheless, GTK4 still has a native X11 backend.

Individual GNOME applications

Posted Jun 24, 2025 12:40 UTC (Tue) by linuxrocks123 (subscriber, #34648) [Link] (14 responses)

> Gnumeric developers **will** need to port to GTK4 at least, though, because once GTK5 is out, GTK3 will be EOL'ed; nevertheless, GTK4 still has a native X11 backend.

They won't *need* to. It doesn't really matter if your upstream toolkit is EOL. Even GTK+ (GTK1) still compiles and runs and can be packaged for modern distros.

https://mirrors.slackware.com/slackware/slackware64-curre...

Perhaps they *will* stay on the pointless GTK upgrade treadmill, like most Linux GTK software seems to do. But they won't *need* to.

Individual GNOME applications

Posted Jun 26, 2025 18:42 UTC (Thu) by jmalcolm (subscriber, #8876) [Link] (13 responses)

Well, it is worth noting that GTK1 and GTK2 do not support Wayland.

Probably more than 50% of Linux desktops are Wayland now. It will probably by 80% or more by the end of 2026. When GTK5 ships in 2027 (guess) it will quickly push this number to 90% or more. If Wayland only apps or compositors (like COSMIC) become popular before then, we could hit those percentages sooner.

Of course, all this means is that GTK1 and GTK2 will require Xwayland to run. Xwayland is going to be with us for a long, long time. It is inconceivable that it will not be in RHEL11 for example which pushes it to 2040 at least. No doubt it will be around long, long after that.

I am genuinely curious though how many people will use Xwayland in the future. I have been assuming it would be all of us. However, more and more I am seeing signs that it may actually become fairly niche.

Even if you can run Xwayland, if it is not already installed, it may as well not exist for many users. Apps that need it will simply not run.

Already, we are seeing Wayland compositors appear that do not have Xwayland support. Niri does not as an example. And the Louvre Wayland compositor toolkit only supports Xwayland in rootful mode.

All the toolkits support Wayland now. This means GTK and Qt of course but even stuff like FLTK and wxWidgets. Newer toolkits like Iced are Wayland only as are emerging projects like Cosmoe (BeOS API on Wayland). You do not need to run Xwayland to run any of these apps.

Steam still requires Xwayland (for now) as do Java Swing apps (like JetBrains IDEs and BurpSuite). But it may not be long before 90% of the apps that 90% of users run are Wayland native. Will all those users continue to run an X server in the background that they never use? (Xwayland).

Are most users going to install Xwayland just to pay XBill or run one GTK2 app? Maybe. As I said, until recently I thought everybody would be running Xwayland for the next decade or two. Now I am not so sure.

Individual GNOME applications

Posted Jun 27, 2025 6:09 UTC (Fri) by smurf (subscriber, #17840) [Link]

> Will all those users continue to run an X server in the background that they never use?

None of them will, because these days Xwayland can be auto-started when the first legacy X client wants it.

Individual GNOME applications

Posted Jun 27, 2025 8:41 UTC (Fri) by farnz (subscriber, #17727) [Link]

Already, we are seeing Wayland compositors appear that do not have Xwayland support. Niri does not as an example. And the Louvre Wayland compositor toolkit only supports Xwayland in rootful mode.

All the toolkits support Wayland now. This means GTK and Qt of course but even stuff like FLTK and wxWidgets. Newer toolkits like Iced are Wayland only as are emerging projects like Cosmoe (BeOS API on Wayland). You do not need to run Xwayland to run any of these apps.

Steam still requires Xwayland (for now) as do Java Swing apps (like JetBrains IDEs and BurpSuite). But it may not be long before 90% of the apps that 90% of users run are Wayland native. Will all those users continue to run an X server in the background that they never use? (Xwayland).

First, Niri now supports Xwayland, via xwayland-satellite, as of this commit to Niri, as long as xwayland-satellite has the associated listenfd commits. These will be in the next release as of 2025-06-27.

Second, Xwayland supports socket activation by design - that's what the -listenfd option is for. A Wayland compositor that supports Xwayland but doesn't want to waste resources can open the X11 listening socket, wait for the notification that there's an incoming connection, and spawn Xwayland when an X11 client tries to connect to it; this would let you have Xwayland on your system, not consuming resources (other than storage on your SSD) until you run an X11 client.

And, at least in theory, Xwayland can be terminated when the last X11 client exits, so that running an X11 application doesn't force you to spend the resources on Xwayland until you next log out.

Individual GNOME applications

Posted Jun 29, 2025 0:30 UTC (Sun) by linuxrocks123 (subscriber, #34648) [Link] (10 responses)

I would be very surprised if more than 50% of Linux desktops were currently Wayland. XFCE, for instance, does not support it, and XFCE is very popular among individual users. Among corporate users, a large percentage of them are probably still on RHEL 7 and therefore very unlikely to be running Wayland.

Anyway, GTK1 will still work, as you say, the programs will just run under XWayland.

Here's my personal plan for Wayland, by the way:
1. On the hardware side, run XOrg until it breaks, then run XLibre until it breaks, then run a Wayland compositor with a single rootful XWayland instance taking up the entire screen.
2. On the software side, use the X11 versions of programs until they stop being released because the toolkits dropped support, then use 12to11 to run programs that won't run directly under X11 anymore.
3. Proceed to ignore Wayland forever.

Individual GNOME applications

Posted Jun 29, 2025 2:40 UTC (Sun) by pizza (subscriber, #46) [Link] (6 responses)

> I would be very surprised if more than 50% of Linux desktops were currently Wayland. XFCE, for instance, does not support it, and XFCE is very popular among individual users.

"Very popular" according to what objective metric?

...I would be surprised if even 15% of the total "desktop linux" install base is using anything other than GNOME or KDE.

But let's take Debian's limited opt-in popcon stats (about 300K respondents). xfce, kde, gnome, mate, and cinnamon come to about 21%, 21%, 42%, 11%, and 4% respectively. That gives about 59% of Wayland-capable environments. mate will probably be there in its next release.

> Among corporate users, a large percentage of them are probably still on RHEL 7 and therefore very unlikely to be running Wayland.

Given that RHEL7 dropped out of support a literal year ago (June 30, 2024), I'm gonna have to go [citation needed] on this one.

Individual GNOME applications

Posted Jun 29, 2025 15:01 UTC (Sun) by linuxrocks123 (subscriber, #34648) [Link] (5 responses)

> But let's take Debian's limited opt-in popcon stats (about 300K respondents). xfce, kde, gnome, mate, and cinnamon come to about 21%, 21%, 42%, 11%, and 4% respectively. That gives about 59% of Wayland-capable environments. mate will probably be there in its next release.

Since all of those desktops also work under X, with those numbers, you'd need about 85% of all desktops that theoretically could be running Wayland to be running it instead of X. That seems unlikely to me.

> Given that RHEL7 dropped out of support a literal year ago (June 30, 2024), I'm gonna have to go [citation needed] on this one.

I've had to use RHEL7 within the last few months. You can buy extended support, and these places do.

Individual GNOME applications

Posted Jun 30, 2025 2:18 UTC (Mon) by pizza (subscriber, #46) [Link] (4 responses)

> Since all of those desktops also work under X, with those numbers, you'd need about 85% of all desktops that theoretically could be running Wayland to be running it instead of X. That seems unlikely to me.

You started out using an example of something that didn't support wayland at all (xfce) to support your assertion that most folks weren't using wayland. Now you're moving the goalposts.

Feel free to supply some actual numbers. Otherwise your anectdata is just as worthless as mine. (ie "100% of all linux desktop users I know are running on top of Wayland")

> I've had to use RHEL7 within the last few months. You can buy extended support, and these places do.

"can buy extended support" is not the same as " a large percentage of them are probably still on RHEL 7"

Individual GNOME applications

Posted Jul 2, 2025 5:51 UTC (Wed) by linuxrocks123 (subscriber, #34648) [Link] (3 responses)

> Feel free to supply some actual numbers.

I was using your numbers, from Debian, which back me up? After factoring out the always-non-Wayland desktops, 85% of the remaining desktops, which we don't know are Wayland or X, must be running Wayland in order for over 50% of Linux desktops to be on Wayland. That strains credulity.

But, hey, you want numbers, here are numbers:

https://qa.debian.org/popcon.php?package=wayland
https://qa.debian.org/popcon.php?package=libx11

Debian popularity contest points to about 60% X11, 40% Wayland.

> "can buy extended support" is not the same as " a large percentage of them are probably still on RHEL 7"

The extended support is only offered because demand exists, so, yes, that actually does mean there is a lot of RHEL 7 still out there. I've actually personally used RHEL 7 machines recently -- or were they RHEL 6? -- and _NOT_ because I wanted to. I also used Ubuntu 20.04 just yesterday -- and not because I wanted to.

The corporate world really does not like to upgrade their Unix boxes. This has been true for decades and has also been obvious for decades. Or did you think Red Hat was still patching kernel version 2.6.32 in 2024 just for the funzies of it?

Individual GNOME applications

Posted Jul 2, 2025 11:21 UTC (Wed) by pizza (subscriber, #46) [Link] (2 responses)

> Debian popularity contest points to about 60% X11, 40% Wayland.

You're still moving the goalposts!

You started out claiming that most folks were running in a modern environment that was *incapable* of wayland. I pointed out that this was likely incorrect.

Now you're instead claiming that most folks _aren't_ running wayland. Whether you are correct or not, it's a very different proposition -- of course folks intentionally using old versions of software aren't going to have newer features that come with the newer versions.

(Meanwhile, Debian popcon numbers probably aren't representative of Debian as a whole, nor is it likely representative of the rest of the Linux ecosystem)

> The extended support is only offered because demand exists, so, yes, that actually does mean there is a lot of RHEL 7 still out there. I've actually personally used RHEL 7 machines recently --

Great, more anectdata!

....So, how many of these "lots of RHEL7[+rebuilds] out there" are *desktops* versus servers? IME it was overwhelmingly the latter, even when RHEL was the _current_ release instead of being obsoleted three times over.

Individual GNOME applications

Posted Jul 2, 2025 13:21 UTC (Wed) by jzb (editor, #7867) [Link]

Hi folks -- while this discussion is technically on-topic, it seems to have become a personal debate, and one that's less than interesting for the majority of people who follow the comments. I don't think anyone's mind will be changed here, so let's end it here, please. Thanks.

Individual GNOME applications

Posted Jul 2, 2025 13:53 UTC (Wed) by linuxrocks123 (subscriber, #34648) [Link]

Reply: https://soylentnews.org/comments.pl?noupdate=1&sid=64...

Individual GNOME applications

Posted Jun 29, 2025 3:54 UTC (Sun) by Cyberax (✭ supporter ✭, #52523) [Link]

> XFCE, for instance, does not support it

Wayland support in XFCE is nearly completed: https://wiki.xfce.org/releng/wayland_roadmap

Individual GNOME applications

Posted Jun 30, 2025 5:32 UTC (Mon) by smurf (subscriber, #17840) [Link] (1 responses)

> Here's my personal plan for Wayland, by the way:

So you want to run a Wayland compositor with an X11 root window in it and then use 12to11 to X11-ize your Wayland apps.

I'm sure I'll be sorry to have asked, but seriously: what the heck is (or will be) the point of this exercise? All of this cannot possibly work any better than using Wayland directly.

Individual GNOME applications

Posted Jun 30, 2025 19:06 UTC (Mon) by raven667 (subscriber, #5198) [Link]

> I'm sure I'll be sorry to have asked, but seriously: what the heck is (or will be) the point of this exercise

<snark>I'm sure the flavor of the pixels have a richness and umami that cannot be described or replicated ;-)</snark>

jokes aside, if they want to run things that way because it makes them happy to do so, then we can just be happy that they are happy even if we don't understand or wouldn't do it that way ourselves, as long as they don't require other users to be harmed by breaking more common workflows to support their personal oddities.

Along those lines I saw a recent project called `wayback` which was for running an X11 desktop on a Wayland graphics output, which might be useful to demonstrate some of the large back catalog of interesting and unique window managers which have been created over the years to new generations of people, and might be useful for cases like this.

Individual GNOME applications

Posted Jun 26, 2025 18:51 UTC (Thu) by jmalcolm (subscriber, #8876) [Link]

GIMP just migrated to GTK3 a couple of months ago, about 4 years after the GTK2 EOL.

Any wagers on when they move to GTK4 or GTK5?

GTK3 runs native on Wayland. Most users will probably be fine with running GTK3 apps for quite a while.

Individual GNOME applications

Posted Jun 26, 2025 10:06 UTC (Thu) by parametricpoly (subscriber, #143903) [Link]

> Will it become difficult or impossible to run individual applications with sysv and X11?

Isn't the systemd related stuff only relevant for gdm / gnome-shell sessions? I think you can run individual applications without systemd just fine.

Let projects have their own goals

Posted Jun 26, 2025 21:49 UTC (Thu) by jmalcolm (subscriber, #8876) [Link] (1 responses)

Personally, I am ok with projects having their own goals. Let the GNOME project build GNOME OS and craft it exactly to their vision, whatever that is.

If the rest of us want to use it, let's found the "Portable GNOME Project" with the goal of adapting vanilla GNOME to work with systemd alternatives, with theme-able libadwaita alternatives, and the like. Why should the GNOME devs have to fill their days with the priorities of others?

And if there is not enough interest to drive the "Portable GNOME Project", well then I guess those making different choices than GNOME OS does will not be running GNOME.

Do not get me wrong. I want everybody to collaborate. GNOME should work with the "Portable GNOME Project" or even individual distros and developers to ensure that portability is possible. They should at least build the right interfaces and such and try to understand what other people need. But GNOME does not have to ship portable implementations of the kinds of things mentioned in this article. And they should not be held back by limitations found in software the project does not use.

I think the quotes from the Alpine and Chimera projects are interesting. Alpine says they will have to stop shipping GNOME because they use musl. Chimera, who also uses musl, says building the capabilities required has always been the plan. This is because Chimera realized that, if choosing musl meant no systemd, other ways of providing the same features would need to be found.

In my view, the Chimera model is the right one.

I mean, Alpine is free to do as they want as well. However, we need to understand that choosing implementations with fewer features may mean that we are unable to run some things. And if this stems from our choices or "requirements", then that may be our problem to solve. The same is true of distros that want to ship without Rust, or without Wayland, or without Pipewire, or without GTK4, or without Python3, or without "not free enough" stuff, or whatever other hill they want to die on. Choose what you like, but own the gap that creates.

Let projects have their own goals

Posted Jun 27, 2025 9:40 UTC (Fri) by intelfx (subscriber, #130118) [Link]

> Let the GNOME project build GNOME OS <...> If the rest of us want to use it, <...>

...then we also can just use it, because the result is quite usable as is. There's a false dichotomy here — some (I'd even bet *most*) of us don't actually need any systemd alternatives, or libadwaita alternatives, despite not being part of the GNOME project or the GNOME OS community.

A line in the sand

Posted Jul 4, 2025 3:25 UTC (Fri) by zahlman (guest, #175387) [Link] (1 responses)

> GNOME contributor Emmanuele Bassi said that he didn't think that a huge part of GNOME's user base was running a non-systemd-based distribution in 2025.

It's hard for me to imagine that a huge part of the user base of non-systemd-based distributions are running GNOME, similarly. In particular, it looks like a real pain to deal with on Artix already, while Xfce appears to be default on Devuan and Gentoo — with the latter trying pretty hard to support users who want it since it became technically feasible, but it hardly seems essential.

In the last few months — especially with the Xlibre drama playing out — I've been noticing a pretty clear conflict in the overall world of Linux, with RedHat and the GNOME Foundation on one side, and everyone else (even other systemd embracers) on the other side. Of course GNOME would like to move towards a systemd-only world; systemd comes from RedHat, which is the largest corporate contributor to the GNOME Project. It's exactly as unsurprising as the plan to focus on Wayland, which is also RedHat's preference (from what I can tell, Xorg is already gone in the newly released RHEL 10, with XWayland serving as a stop-gap, and that was already planned almost two years ago). And of course (this does get a little more conspiratorial) the GNOME Foundation is happy to do what RedHat wants, because they dropped ties with GNU in 2021 (and were trying since 2019 if you believe Neil McGovern) and corporate sponsorship represents money that most FOSS projects simply cannot access.

In short, I fully expect that other non-systemd distros will simply drop support for GNOME Desktop rather than trying to apply their own hacks. At best they might maintain an EOL version for a while. The way I see it, there's simply no love lost between them; multiple aspects of the GNOME philosophy run counter to what users are looking for when they choose such a distro. From that perspective — the one driven by user freedom and a preference for modularity — GNOME have quite literally forgotten what they stand for.

(I say this not as an advocate — I don't particularly care myself — but as someone who has listened to them.)

A line in the sand

Posted Jul 4, 2025 10:52 UTC (Fri) by anselm (subscriber, #2796) [Link]

In the end it probably comes down to whether there are people who feel strongly enough about the non-systemd case to actually shoulder the support burden of keeping it going. Hand-wringing by people who don't agree with what the GNOME project is planning to do but aren't prepared to get their own hands dirty doesn't really count.

I don't even think Red Hat has a lot to do with it. Systemd has been around for quite some time now and there is a very widespread consensus – certainly among most distribution providers including but not limited to Red Hat – that it is the way to go¹. So even if we leave Red Hat out of the picture entirely, it makes reasonable sense for the GNOME project to avail itself officially of systemd services that are widely available, instead of expending effort to keep supporting a technology stack which has, de facto, been supplanted in most of the important Linux distributions for more than a decade.

The situation with Wayland is basically similar; virtually all the people who used to work on Xorg are now working on Wayland instead, so we don't need to come up with a conspiracy narrative that this is all because of Red Hat – the problems of X11 are well-known, and if you're into display servers, it does make sense to work on something new and exciting instead of applying more band aids and baling wire to something that has been around since the 1980s. X11 did have a good run in its time but nobody should be faulted for focusing on a new approach that actually suits modern hardware. (Especially since you still get to run X11 applications in a Wayland environment.)

1. Here, too, hand-wringing by systemd detractors has not led to a viable systemd alternative; outfits like Devuan have generally continued with the ancient pre-systemd tooling (and all its shortcomings, warts, and inconsistencies) instead.


Copyright © 2025, Eklektix, Inc.
This article may be redistributed under the terms of the Creative Commons CC BY-SA 4.0 license
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds