Drill holes in your CPU for better cooling!

ZSH still needs the completion data files to be installed. It won’t just magically know the completions.

losing integration because “containerized”

Bollocks. I’ve seen that many times with Flatpak (can’t speak for Snap), and every single time it was either because the packager failed to set up permissions or because the user messed with permissions that the application needed. Break off the tip of a screwdriver and it will no longer function as a screwdriver.

And I know you’re talking out of your ass because AppImage isn’t even sandboxed.

taking GBs of space

That part is true and accurate, and for a very good reason: dependency pinning. System packages can break if they don’t have the correct versions of shared libraries. If a package requires a very old version of a library, and doesn’t link it statically or supply it with the package, it can misbehave, have missing features, or refuse to even start. Flatpak (and probably Snap too, can’t speak for it) solves that by letting the packager specify (pin) the exact version of a dependency. If five separate packages require five different versions of the GNOME application framework, then they will download five separate packages of the correct version. AppImage solves it by being monolithic: everything is packaged together into a single executable.

Sometimes, “Yes, do as I say!” just doesn’t get the message through.

That’s pretty much what happened. Windows 8 was such dogshit that it might be indirectly responsible for the revolution of Linux gaming. https://archive.ph/iHl8q

(edit) The comments are fucking hilarious.

Who is this turkey anyway. He says it’s “unusable” but doesn’t say he’s used it. Had he done so he would have looked past the surface change and recognized the true power and smoothness under the hood. […] Way to go Microsoft too bad you need to put up with idiots that are too lazy to keep up with the times.

I take it you’ve never done any serious software development.

No matter how much they try, the in-house testing environment will never be as diverse as the “wild”. Running the software in production, where it will encounter a vastly greater range of system configurations, and users who will report issues, is often the only way to catch the more elusive bugs. Like xz. And let me point it out because people seem to have completely missed it: they caught the bug and fixed it.

Unless I’m terribly misunderstanding the word’s meaning (or anglophones once again redefined a word to reflect their current sensibilities), “conservative” doesn’t automatically imply politics, just that someone is resistant to new ideas. A person who only listens to music produced before the 20th century and goes into a rage when video game music composers are mentioned is a conservative, but not in terms of political views.

Yes, the people who refuse to either upgrade to Win11-compatible hardware or move to an OS compatible with their existing hardware will eventually get left behind. Both in terms of security and compatibility. It’s happened many times, from the fall of AGP in favour of PCIE, to every time Intel inroduced a new CPU socket. X11 is the next.

Getting left behind is the natural and inevitable consequence of obsolescence.

It has been implemented in the development branch, and will be released publicly in 22.3, the next point release.

It’s more of an “it’s still experimental” kind of issue. They’re releasing the Wayland session into the wild before it’s ready to boost the pace of bug-squashing. X11 remains default, but they allow the people who want to contribute (instead of whine on public forums about missing features) to test the Wayland session on a much greater variety of hardware and OS configurations than could ever be achieved in-house, report bugs, break things, and submit changes.

In my eyes, it’s the same deal as conservatives coping with the changing world. There is a version where they just shut up and let the rest of the tech landscape improve while they happily stick to the X they know (X.org or even XLibre).

That’s what happens when you use an experimental feature that is actively being developed and receiving improvements over time. Transitioning an X11 stack to Wayland is not as simple as flipping on a build flag.

Keyboard support has been implemented and will arrive in 22.3:

Wayland support

Under the hood, the Cinnamon keyboard handling relied on libgnomekbd and only worked in Xorg.

This meant that Cinnamon under Wayland could only be used with an English (US) layout.

This new support is fully compatible with Wayland for both traditional layouts and IBus input methods.

It looks like GNOME is the only compositor that doesn’t support the wlr_layer_shell protocol, which is anything but surprising. Smithay works (Cosmic and Niri), wlroots works, Kwin and Mir work, Aquamarine (Hyprland) is not listed, but I know that it works.

X11 was released in 1987. The original X Window System was released in 1984. That is not just a few years of difference.

If you meant the X.org implementation, then compare it to compositors, not to the protocol.

You’ll have to look into GTK’s Layer Shell implementation.

Look at the source of Eww. It’s written in Rust, it uses GTK (or GDK?), and it has a config option that opens the windows in the bottom layer.

https://github.com/elkowar/eww/blob/fddb4a09b107237819e661151e007b99b5cab36d/crates/eww/src/display_backend.rs#L61

Ubuntu:

Such as?