GTK 5 is not yet in the works to my knowledge.

GTK 3 apps support Wayland natively. GIMP, for example, is GTK 3 and Wayland native.

GTK 2 is X11 only if you use a distro that even ships GTK 2 anymore. Many do not, including mine.

Was it to revert MUSL?

Ducks /s

With all the bleating about how GNOME does not listen to users, these kinds of little quality of life improvements may be more significant than you think. Let’s hope we see more of them.

Everything runs under Wayland. That should be your default expectation.

At this point, Wayland is the preferred environment for GTK and Qt apps. Unless the app is exploiting some specific aspect of X11, all GTK (3 and up) and Qt (5 and up) apps work fine under Wayland.

As for other toolkits, FLTK, Electron, and SDL apps run in Wayland too.

And by “preferred”, I mean that these apps (like Thunar) will run natively on Wayland even if Xwayland is available.

There are Wayland only toolkits now but not really any “modern” toolkits that do not support Wayland. When Thunar gets ported to GTK5, it will be Wayland only.

Obviously ancient x11 specific stuff like XCB or Athena, and things built on them like Motif will require Xwayland or Xsatellite. So if you want to run, xv or motif nedit, you need those. This list includes GTK2 as well. But even they work well enough you may not notice. I mean, xeyes won’t track your mouse I guess.

And just in case mentioning xeyes brings out the Wayland critics, you can build an xeyes app that works in Wayland. I think the Wayland Maker compositor project has one for example (WindowMaker in Wayland).

The industry cannot code safely. There are many reports, studies, and corporate disclosures highlighting that memory related bugs are the primary source of critical security issues in C and C++ code. That is why even NIH companies like Google and Microsoft are adopting Rust in their core products.

That you want to publicly ignore all that evidence to paint it as an individual skill issue does not come across as competent or intelligent. Few of us are going to assume your code is free of these kinds of bugs.

The fact that your have to say it so dismissively makes me think that you know it too.

Yes. There is also a GCC front-end for Rust (does not go to C first).

The timeline is not super abrupt, especially for architectures where all he is asking is to ensure that your Rust toolchain is in order. That is especially true when you consider that Rust is already well maintained on all the Debian architectures that people actually use.

The abruptness (almost rudeness) is in the second part where he basically says that, if you cannot get Rust going in time, you should just stop releasing Debian for that architecture.

It is mostly just poorly worded though. Because none of these architectures have “official” support even now. This will not be the only way they are behind. So, there is not reason to be so dramatic.

And that would be my response to him. Another option here is that these alternative architectures just continue to ship an older version of APT for now. Emergency avoided. Few of them ship with up-to-date versions of APT even now.

Another solution is to use one of the multiple projects that is working to make Rust code build with the GCC compiler back-end. At least one of these projects has already announced that they want to work with these Debian variants to ensure that APT builds with them.

So, the 6 month timeline is a reasonable impetus to make that happen which would be quite a good thing beyond just APT.

There are many other useful tools written in Rust you are going to want to use on these architectures. It will be a fantastic outcome if this pressure from APT kickstarts that happening for some of these long abandoned architectures (by the mainstream at least).

Rust is generally not going to outperform well optimized C code.

That said, it is far easier to write performant Rust code than C code. So, what we see, is that projects that move to Rust frequently see performance gains.

That just means the initial C code was not that great (performance wise). From observation, most C projects are fairly unoptimized.

You are the one preaching and yelling.

Stay on X if you want. As you say, that is the freedom Open Source provides. I use ancient hardware. To each their own. If I was still using XFCE, I would still be using X myself*.

But if you are going to voluntarily stay behind, stop complaining that the bus left without you.

Wayland users are in the majority. By the time Mint (Cinnamon) flips to Wayland (2026?) and GTK5 is released (2028?) it will be over 90%. Almost all GNOME and Plasma users are Wayland now and that must be 60% already (without even counting Hyprland, Sway, COSMIC, or Niri).

We already have Wayland only distros (eg. RHEL10). GNOME will not even be the first Wayland only DE (COSMIC). The ship has sailed.

• I have one box that uses XFCE on Wayland but if I wanted to use XFCE as my main desktop, I would probably use X. My daily drivers are Niri and Plasma Wayland.

It is pretty hard to improve if you are not allowed to change anything.

Yes, the design of Wayland means that some of the techniques that work on X will not work on Wayland (on purpose). So yes, some apps have to be adapted to use the techniques that do work on Wayland. And no, changing Wayland to support the old ways is not the answer (because they were changed on purpose).

Wayland has been criticized for taking away previous capabilities before providing new ways to do things. That is a fair critique, though somewhat par for the course when replacing old tech. But at this point, almost everything necessary is possible and Wayland users are in the majority (the massive majority soon).

At this point, it really is the apps developers responsibility to support Wayland properly. I mean, they do not have to of course but that means their app will be broken for 80% of Linux users on two years (and more than half today).