GNOME deepens systemd dependencies
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.
Posted Jun 23, 2025 15:38 UTC (Mon)
by benzea (subscriber, #96937)
[Link]
> 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!
Posted Jun 23, 2025 15:40 UTC (Mon)
by wtarreau (subscriber, #51152)
[Link] (32 responses)
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.
Posted Jun 23, 2025 15:59 UTC (Mon)
by smurf (subscriber, #17840)
[Link]
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.
Posted Jun 23, 2025 16:00 UTC (Mon)
by bluca (subscriber, #118303)
[Link] (30 responses)
Posted Jun 23, 2025 23:49 UTC (Mon)
by tux3 (subscriber, #101245)
[Link] (29 responses)
Posted Jun 23, 2025 23:56 UTC (Mon)
by pizza (subscriber, #46)
[Link] (28 responses)
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
Posted Jun 24, 2025 17:45 UTC (Tue)
by linuxrocks123 (subscriber, #34648)
[Link] (27 responses)
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.
Posted Jun 24, 2025 19:21 UTC (Tue)
by pizza (subscriber, #46)
[Link]
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?
> Why do something ridiculous like using temporary user IDs for xdm?
1) "Defense in depth"
> Most machines are only going to be running one copy of xdm anyway,
....And what about those which don't?
Posted Jun 24, 2025 20:00 UTC (Tue)
by smurf (subscriber, #17840)
[Link] (23 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.
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.
Posted Jun 25, 2025 2:51 UTC (Wed)
by linuxrocks123 (subscriber, #34648)
[Link] (22 responses)
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.
Posted Jun 25, 2025 4:30 UTC (Wed)
by jem (subscriber, #24231)
[Link]
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).
Posted Jun 25, 2025 7:45 UTC (Wed)
by smurf (subscriber, #17840)
[Link] (20 responses)
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.
Posted Jun 25, 2025 17:15 UTC (Wed)
by linuxrocks123 (subscriber, #34648)
[Link] (19 responses)
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.
Posted Jun 25, 2025 17:41 UTC (Wed)
by jem (subscriber, #24231)
[Link] (18 responses)
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.
Posted Jun 26, 2025 6:51 UTC (Thu)
by linuxrocks123 (subscriber, #34648)
[Link] (17 responses)
(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.
Posted Jun 26, 2025 7:21 UTC (Thu)
by mjg59 (subscriber, #23239)
[Link] (13 responses)
? 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.
Posted Jun 26, 2025 14:24 UTC (Thu)
by linuxrocks123 (subscriber, #34648)
[Link] (12 responses)
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.)
Posted Jun 26, 2025 17:49 UTC (Thu)
by mjg59 (subscriber, #23239)
[Link] (11 responses)
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.
Posted Jun 26, 2025 21:01 UTC (Thu)
by linuxrocks123 (subscriber, #34648)
[Link] (10 responses)
https://www.brow.sh/
> 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.
Posted Jun 26, 2025 22:28 UTC (Thu)
by mjg59 (subscriber, #23239)
[Link] (7 responses)
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.
Posted Jun 27, 2025 23:08 UTC (Fri)
by linuxrocks123 (subscriber, #34648)
[Link] (6 responses)
> 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.
Posted Jun 27, 2025 23:16 UTC (Fri)
by intelfx (subscriber, #130118)
[Link] (1 responses)
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".
Posted Jun 28, 2025 3:13 UTC (Sat)
by linuxrocks123 (subscriber, #34648)
[Link]
Posted Jun 28, 2025 8:20 UTC (Sat)
by jem (subscriber, #24231)
[Link] (3 responses)
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.
Posted Jun 28, 2025 23:58 UTC (Sat)
by linuxrocks123 (subscriber, #34648)
[Link] (2 responses)
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.
Posted Jun 29, 2025 10:52 UTC (Sun)
by cortana (subscriber, #24596)
[Link] (1 responses)
"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!
Posted Jun 29, 2025 22:02 UTC (Sun)
by linuxrocks123 (subscriber, #34648)
[Link]
Posted Jun 27, 2025 6:21 UTC (Fri)
by smurf (subscriber, #17840)
[Link] (1 responses)
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.
Posted Jun 27, 2025 23:14 UTC (Fri)
by linuxrocks123 (subscriber, #34648)
[Link]
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.
Posted Jun 26, 2025 22:32 UTC (Thu)
by elsandosgrande (subscriber, #174457)
[Link] (2 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.
Posted Jun 27, 2025 23:27 UTC (Fri)
by linuxrocks123 (subscriber, #34648)
[Link] (1 responses)
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.
Posted Jun 28, 2025 23:59 UTC (Sat)
by linuxrocks123 (subscriber, #34648)
[Link]
Posted Jun 24, 2025 21:36 UTC (Tue)
by Cyberax (✭ supporter ✭, #52523)
[Link] (1 responses)
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.
Posted Jun 25, 2025 3:35 UTC (Wed)
by linuxrocks123 (subscriber, #34648)
[Link]
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.
Posted Jun 23, 2025 15:42 UTC (Mon)
by calvin (subscriber, #168398)
[Link] (34 responses)
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.
Posted Jun 23, 2025 15:56 UTC (Mon)
by wtarreau (subscriber, #51152)
[Link] (33 responses)
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.
Posted Jun 23, 2025 16:44 UTC (Mon)
by Wol (subscriber, #4433)
[Link]
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,
Posted Jun 23, 2025 17:39 UTC (Mon)
by calvin (subscriber, #168398)
[Link]
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)...
Posted Jun 23, 2025 17:48 UTC (Mon)
by jafd (subscriber, #129642)
[Link]
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.
Posted Jun 23, 2025 18:25 UTC (Mon)
by ballombe (subscriber, #9523)
[Link] (15 responses)
Posted Jun 23, 2025 18:52 UTC (Mon)
by joib (subscriber, #8541)
[Link] (14 responses)
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...
Posted Jun 23, 2025 21:30 UTC (Mon)
by wtarreau (subscriber, #51152)
[Link]
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!
Posted Jun 24, 2025 6:39 UTC (Tue)
by joib (subscriber, #8541)
[Link] (1 responses)
Not sure whether I should be happy or horrified that it's possible to recreate that look with modern xfce. ;-)
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.
Posted Jun 24, 2025 9:46 UTC (Tue)
by paulj (subscriber, #341)
[Link] (8 responses)
Posted Jun 24, 2025 11:34 UTC (Tue)
by joib (subscriber, #8541)
[Link] (7 responses)
Posted Jun 24, 2025 12:40 UTC (Tue)
by paulj (subscriber, #341)
[Link] (6 responses)
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.
Posted Jun 24, 2025 14:25 UTC (Tue)
by paulj (subscriber, #341)
[Link] (5 responses)
Posted Jun 24, 2025 14:53 UTC (Tue)
by wtarreau (subscriber, #51152)
[Link] (1 responses)
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.
Posted Jun 24, 2025 16:35 UTC (Tue)
by paulj (subscriber, #341)
[Link]
Posted Jun 26, 2025 19:04 UTC (Thu)
by jmalcolm (subscriber, #8876)
[Link] (2 responses)
Posted Jun 27, 2025 10:58 UTC (Fri)
by paulj (subscriber, #341)
[Link] (1 responses)
Thanks!
Posted Jun 27, 2025 12:42 UTC (Fri)
by smurf (subscriber, #17840)
[Link]
Not looking back.
Not looking forward to converting my laptop either, but that's a different topic.
Posted Jun 24, 2025 13:49 UTC (Tue)
by clump (subscriber, #27801)
[Link]
I can imagine the mouse pointer changing window colors when hovering, and the right click menu disappearing when you release the button.
Posted Jun 23, 2025 18:53 UTC (Mon)
by parametricpoly (subscriber, #143903)
[Link] (13 responses)
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.
Posted Jun 23, 2025 21:35 UTC (Mon)
by wtarreau (subscriber, #51152)
[Link] (12 responses)
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.
Posted Jun 23, 2025 23:39 UTC (Mon)
by parametricpoly (subscriber, #143903)
[Link]
Posted Jun 24, 2025 0:32 UTC (Tue)
by pizza (subscriber, #46)
[Link]
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.
Posted Jun 24, 2025 2:10 UTC (Tue)
by smurf (subscriber, #17840)
[Link]
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).
Posted Jun 24, 2025 3:03 UTC (Tue)
by mjg59 (subscriber, #23239)
[Link] (5 responses)
Posted Jun 24, 2025 6:35 UTC (Tue)
by joib (subscriber, #8541)
[Link] (4 responses)
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.
Posted Jun 24, 2025 7:43 UTC (Tue)
by smurf (subscriber, #17840)
[Link]
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.
Posted Jun 24, 2025 14:20 UTC (Tue)
by rjones (subscriber, #159862)
[Link] (2 responses)
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.
Posted Jun 24, 2025 14:53 UTC (Tue)
by joib (subscriber, #8541)
[Link] (1 responses)
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.
Posted Jun 25, 2025 11:07 UTC (Wed)
by rjones (subscriber, #159862)
[Link]
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.
Posted Jun 24, 2025 7:16 UTC (Tue)
by zdzichu (subscriber, #17118)
[Link] (2 responses)
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.
Posted Jun 24, 2025 10:01 UTC (Tue)
by dottedmag (subscriber, #18590)
[Link]
Posted Jun 24, 2025 18:15 UTC (Tue)
by adobriyan (subscriber, #30858)
[Link]
Posted Jun 24, 2025 5:40 UTC (Tue)
by SiB (subscriber, #4048)
[Link] (36 responses)
Posted Jun 24, 2025 6:58 UTC (Tue)
by ebee_matteo (subscriber, #165284)
[Link] (16 responses)
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.
Posted Jun 24, 2025 8:18 UTC (Tue)
by pabs (subscriber, #43278)
[Link]
Posted Jun 24, 2025 8:19 UTC (Tue)
by pabs (subscriber, #43278)
[Link] (3 responses)
Posted Jun 24, 2025 17:36 UTC (Tue)
by pbonzini (subscriber, #60935)
[Link] (2 responses)
What you might remember is moving away from supporting all apps in favor of flatpak—one major example being LibreOffice.
Posted Jun 25, 2025 5:28 UTC (Wed)
by ebee_matteo (subscriber, #165284)
[Link]
Posted Jun 26, 2025 3:35 UTC (Thu)
by pabs (subscriber, #43278)
[Link]
Posted Jun 24, 2025 9:56 UTC (Tue)
by paulj (subscriber, #341)
[Link] (3 responses)
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).
Posted Jun 24, 2025 9:57 UTC (Tue)
by paulj (subscriber, #341)
[Link]
Posted Jun 24, 2025 16:32 UTC (Tue)
by smurf (subscriber, #17840)
[Link] (1 responses)
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.
Posted Jul 19, 2025 14:27 UTC (Sat)
by daenzer (subscriber, #7050)
[Link]
Making the Wayland compositor not advertise any outputs at negative locations to Xwayland, while technically a workaround, should be a much easier solution overall.
Posted Jun 25, 2025 8:38 UTC (Wed)
by patrick_g (subscriber, #44470)
[Link] (6 responses)
How can we be sure it's true? Have you seen that post from Ted Unangst?
Posted Jun 25, 2025 8:48 UTC (Wed)
by pbonzini (subscriber, #60935)
[Link] (5 responses)
Posted Jun 25, 2025 10:06 UTC (Wed)
by smurf (subscriber, #17840)
[Link] (4 responses)
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.
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."
Posted Jun 25, 2025 13:29 UTC (Wed)
by farnz (subscriber, #17727)
[Link] (2 responses)
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.
Posted Jun 25, 2025 15:00 UTC (Wed)
by paulj (subscriber, #341)
[Link] (1 responses)
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).
Posted Jun 25, 2025 15:12 UTC (Wed)
by farnz (subscriber, #17727)
[Link]
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.
Posted Jun 24, 2025 8:16 UTC (Tue)
by pabs (subscriber, #43278)
[Link] (17 responses)
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/
Posted Jun 24, 2025 10:12 UTC (Tue)
by ebassi (subscriber, #54855)
[Link] (16 responses)
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.
Posted Jun 24, 2025 12:40 UTC (Tue)
by linuxrocks123 (subscriber, #34648)
[Link] (14 responses)
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.
Posted Jun 26, 2025 18:42 UTC (Thu)
by jmalcolm (subscriber, #8876)
[Link] (13 responses)
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.
Posted Jun 27, 2025 6:09 UTC (Fri)
by smurf (subscriber, #17840)
[Link]
None of them will, because these days Xwayland can be auto-started when the first legacy X client wants it.
Posted Jun 27, 2025 8:41 UTC (Fri)
by farnz (subscriber, #17727)
[Link]
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.
Posted Jun 29, 2025 0:30 UTC (Sun)
by linuxrocks123 (subscriber, #34648)
[Link] (10 responses)
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:
Posted Jun 29, 2025 2:40 UTC (Sun)
by pizza (subscriber, #46)
[Link] (6 responses)
"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.
Posted Jun 29, 2025 15:01 UTC (Sun)
by linuxrocks123 (subscriber, #34648)
[Link] (5 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.
> 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.
Posted Jun 30, 2025 2:18 UTC (Mon)
by pizza (subscriber, #46)
[Link] (4 responses)
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"
Posted Jul 2, 2025 5:51 UTC (Wed)
by linuxrocks123 (subscriber, #34648)
[Link] (3 responses)
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
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?
Posted Jul 2, 2025 11:21 UTC (Wed)
by pizza (subscriber, #46)
[Link] (2 responses)
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.
Posted Jul 2, 2025 13:21 UTC (Wed)
by jzb (editor, #7867)
[Link]
Posted Jul 2, 2025 13:53 UTC (Wed)
by linuxrocks123 (subscriber, #34648)
[Link]
Posted Jun 29, 2025 3:54 UTC (Sun)
by Cyberax (✭ supporter ✭, #52523)
[Link]
Wayland support in XFCE is nearly completed: https://wiki.xfce.org/releng/wayland_roadmap
Posted Jun 30, 2025 5:32 UTC (Mon)
by smurf (subscriber, #17840)
[Link] (1 responses)
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.
Posted Jun 30, 2025 19:06 UTC (Mon)
by raven667 (subscriber, #5198)
[Link]
<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.
Posted Jun 26, 2025 18:51 UTC (Thu)
by jmalcolm (subscriber, #8876)
[Link]
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.
Posted Jun 26, 2025 10:06 UTC (Thu)
by parametricpoly (subscriber, #143903)
[Link]
Isn't the systemd related stuff only relevant for gdm / gnome-shell sessions? I think you can run individual applications without systemd just fine.
Posted Jun 26, 2025 21:49 UTC (Thu)
by jmalcolm (subscriber, #8876)
[Link] (1 responses)
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.
Posted Jun 27, 2025 9:40 UTC (Fri)
by intelfx (subscriber, #130118)
[Link]
...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.
Posted Jul 4, 2025 3:25 UTC (Fri)
by zahlman (guest, #175387)
[Link] (1 responses)
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.)
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.
dbus-daemon dependency is gone
Might be a good move
Might be a good move
Might be a good move
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
Might be a good move
Might be a good move
Might be a good move
2) What about non-ASCII (especially CJK that requires more advanced input methods)
3) _Which_ attached keyboard/mouse[/camera/biometric/etc]?
2) It's a lot less work than "rewrite everything else" (and inevitably introduce a different set of bugs/regressions)
Might be a good move
Might be a good move
Might be a good move
>Oh, dear. They really managed to overcomplicate things, now didn't they?
Might be a good move
Might be a good move
Might be a good move
Might be a good move
Might be a good move
Might be a good move
Might be a good move
Might be a good move
https://github.com/fathyb/carbonyl
Might be a good move
Might be a good move
Might be a good move
Might be a good move
Might be a good move
Might be a good move
Might be a good move
Might be a good move
Might be a good move
Might be a good move
Might be a good move
Might be a good move
Might be a good move
Might be a good move
Might be a good move
probably not a huge deal, but bigger implications
probably not a huge deal, but bigger implications
probably not a huge deal, but bigger implications
Wol
probably not a huge deal, but bigger implications
probably not a huge deal, but bigger implications
probably not a huge deal, but bigger implications
probably not a huge deal, but bigger implications
probably not a huge deal, but bigger implications
probably not a huge deal, but bigger implications
probably not a huge deal, but bigger implications
CDE as XFCE gateway
probably not a huge deal, but bigger implications
probably not a huge deal, but bigger implications
probably not a huge deal, but bigger implications
probably not a huge deal, but bigger implications
probably not a huge deal, but bigger implications
probably not a huge deal, but bigger implications
probably not a huge deal, but bigger implications
probably not a huge deal, but bigger implications
probably not a huge deal, but bigger implications
probably not a huge deal, but bigger implications
probably not a huge deal, but bigger implications
probably not a huge deal, but bigger implications
probably not a huge deal, but bigger implications
probably not a huge deal, but bigger implications
probably not a huge deal, but bigger implications
probably not a huge deal, but bigger implications
probably not a huge deal, but bigger implications
probably not a huge deal, but bigger implications
probably not a huge deal, but bigger implications
probably not a huge deal, but bigger implications
probably not a huge deal, but bigger implications
probably not a huge deal, but bigger implications
probably not a huge deal, but bigger implications
probably not a huge deal, but bigger implications
Individual GNOME applications
Will it become difficult or impossible to run individual applications with sysv and X11?
Individual GNOME applications
Individual GNOME applications
Individual GNOME applications
Individual GNOME applications
Individual GNOME applications
Individual GNOME applications
Individual GNOME applications
Individual GNOME applications
Individual GNOME applications
Individual GNOME applications
Individual GNOME applications
https://flak.tedunangst.com/post/forbidden-secrets-of-anc...
Individual GNOME applications
Individual GNOME applications
Individual GNOME applications
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.
Individual GNOME applications
Individual GNOME applications
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.
Individual GNOME applications
Individual GNOME applications
https://mir-server.io/
Individual GNOME applications
Individual GNOME applications
Individual GNOME applications
Individual GNOME applications
Individual GNOME applications
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.
Individual GNOME applications
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
Individual GNOME applications
Individual GNOME applications
Individual GNOME applications
https://qa.debian.org/popcon.php?package=libx11
Individual GNOME applications
Individual GNOME applications
Individual GNOME applications
Individual GNOME applications
Individual GNOME applications
Individual GNOME applications
Individual GNOME applications
Individual GNOME applications
Let projects have their own goals
Let projects have their own goals
A line in the sand
A line in the sand