LWN: Comments on "GNOME deepens systemd dependencies"

Individual GNOME applications

daenzer — Sat, 19 Jul 2025 14:27:04 +0000

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.

A line in the sand

anselm — Fri, 04 Jul 2025 10:52:05 +0000

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.

A line in the sand

zahlman — Fri, 04 Jul 2025 03:25:27 +0000

> 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.)

Individual GNOME applications

linuxrocks123 — Wed, 02 Jul 2025 13:53:32 +0000

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

Individual GNOME applications

jzb — Wed, 02 Jul 2025 13:21:18 +0000

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

pizza — Wed, 02 Jul 2025 11:21:50 +0000

> 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

linuxrocks123 — Wed, 02 Jul 2025 05:51:06 +0000

> 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

raven667 — Mon, 30 Jun 2025 19:06:20 +0000

> 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

smurf — Mon, 30 Jun 2025 05:32:39 +0000

> 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

pizza — Mon, 30 Jun 2025 02:18:08 +0000

> 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"

Might be a good move

linuxrocks123 — Sun, 29 Jun 2025 22:02:11 +0000

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

Individual GNOME applications

linuxrocks123 — Sun, 29 Jun 2025 15:01:13 +0000

> 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.

Might be a good move

cortana — Sun, 29 Jun 2025 10:52:11 +0000

> 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!

Individual GNOME applications

Cyberax — Sun, 29 Jun 2025 03:54:32 +0000

> XFCE, for instance, does not support it

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

Individual GNOME applications

pizza — Sun, 29 Jun 2025 02:40:15 +0000

> 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

linuxrocks123 — Sun, 29 Jun 2025 00:30:15 +0000

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.

Might be a good move

linuxrocks123 — Sat, 28 Jun 2025 23:59:02 +0000

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

Might be a good move

linuxrocks123 — Sat, 28 Jun 2025 23:58:00 +0000

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

jem — Sat, 28 Jun 2025 08:20:57 +0000

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

linuxrocks123 — Sat, 28 Jun 2025 03:13:28 +0000

Agree to disagree :P

Might be a good move

linuxrocks123 — Fri, 27 Jun 2025 23:27:02 +0000

> 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

intelfx — Fri, 27 Jun 2025 23:16:15 +0000

> 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

linuxrocks123 — Fri, 27 Jun 2025 23:14:22 +0000

> 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

linuxrocks123 — Fri, 27 Jun 2025 23:08:17 +0000

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.

probably not a huge deal, but bigger implications

smurf — Fri, 27 Jun 2025 12:42:40 +0000

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

paulj — Fri, 27 Jun 2025 10:58:58 +0000

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!

Let projects have their own goals

intelfx — Fri, 27 Jun 2025 09:40:04 +0000

> 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.

Individual GNOME applications

farnz — Fri, 27 Jun 2025 08:41:51 +0000

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.

Might be a good move

smurf — Fri, 27 Jun 2025 06:21:08 +0000

> 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.

Individual GNOME applications

smurf — Fri, 27 Jun 2025 06:09:03 +0000

> 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.

Might be a good move

elsandosgrande — Thu, 26 Jun 2025 22:32:17 +0000

> 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

mjg59 — Thu, 26 Jun 2025 22:28:31 +0000

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.

Let projects have their own goals

jmalcolm — Thu, 26 Jun 2025 21:49:49 +0000

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.

Might be a good move

linuxrocks123 — Thu, 26 Jun 2025 21:01:06 +0000

> 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.

probably not a huge deal, but bigger implications

jmalcolm — Thu, 26 Jun 2025 19:04:56 +0000

Check out WaylandMaker

https://github.com/phkaeser/wlmaker

Individual GNOME applications

jmalcolm — Thu, 26 Jun 2025 18:51:38 +0000

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

jmalcolm — Thu, 26 Jun 2025 18:42:13 +0000

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.

Might be a good move

mjg59 — Thu, 26 Jun 2025 17:49:51 +0000

> 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

linuxrocks123 — Thu, 26 Jun 2025 14:24:37 +0000

> 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.)

Individual GNOME applications

parametricpoly — Thu, 26 Jun 2025 10:06:01 +0000

> 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.