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.

Put all of the postcodes in a paginated list that displays only 30 entries at a time (60 and 100 per page for premium users), only has next/previous navigation buttons, orders the entries by popularity, and goes back to the first page if you reload the website. Or an infinitely scrolling page that loads each page dynamically, but returns 429 Too Many Requests if the user scrolls too fast.

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:

The market share is never a precise number because not everybody is asked to do the hardware survey, and not everybody who is asked does. But the Linux userbase is small enough that “~3%” is in the ballpark.

Version control of dependencies is not as difficult as it seems. Unix systems can easily implement bundled dependencies like Windows does, even without sandboxed or monolithic packaging formats. The important thing is to tell the dynamic linker (ld.so in Linux’s case) where to look for the library files, similar to how PATH is used to locate executables. This is similar to how containerization works to a lesser extent, and the Steam client actually does this by loading its own .so files from ~/.local/share/Steam/.... I’m sure there are additional challenges, my knowledge is superficial and approximate at best.

But the point still stands: in most cases, Linux-native ports are simply not worth the effort, either because of limited resources in small teams, or because of profits in large studios. BG3 and Factorio are definite outliers.

From the sole developer responsible for Factorio’s Linux-native port: https://www.factorio.com/blog/post/fff-408

“Why don’t most games support macOS and Linux?” is a sentiment I often see echoed across the internet. Supporting a new platform is a lot more than just changing some flags and hitting compile. Windows, macOS, Linux, and the Nintendo Switch all use different compilers, different implementations of the C++ standard library, and have different implementation quirks, bugs, and features. You need to set up CI for the new platform, expand your build system to support the new compiler(s) and architecture(s), and have at least one person on the team that cares enough about the platform to actively maintain it. If you are a video game, you will likely need to add support for another graphics backend (Vulkan or OpenGL) as well, since DirectX is Windows-exclusive.

Many developers will take one look at the Windows market share and decide that it is not worth the trouble to support other platforms. Also, with the meteoric rise of the Steam Deck and Proton, it is easier than ever for game developers to ignore Linux support because Valve does some black magic that lets their game run anyway.

The list of Linux-first games is so short it’s not even a factor. It’s very difficult to justify the additional effort of implementing a platform that serves exclusively the playerbase with a ~3% market share, especially when a different method exists to serve that same playerbase that works just as well and also serves the 90%+ with no additional effort.

The article I linked also contains an explanation as to why GNOME’s decision to drop server-side decorations is fucking stupid.

I think you can get some kind of exemption for archival purposes. I know that the Internet Archive has one. But I also know that ultimately Microsoft is responsible for the data hosted on Github, and Microsoft’s interest is to not even risk getting sued.

Such as?

That tells me you don’t understand what a “stable” release branch is. The Debian maintainers do a lot of work to ensure that the packages not only work, but work well together. They don’t introduce breaking changes during the lifecycle of a major branch. They add feature updates between point releases, and continuously release security updates.

In the real world, that stability is a great value, especially in the server space. You’d be insane to use Arch as a production server, and I’m saying that as an Arch user.

Something, something, sword of Damocles.

Very important! When mounting an NTFS filesystem that is also used by Windows, always specify the windows_names option, both in /etc/fstab and when using mount.ntfs.

Windows is not fully compliant with the NTFS specs, which is a bloody genius move on Microsoft’s part. NTFS allows file names and paths to contain characters that are illegal in Windows, like the : character. If you create a file with such a name, it will make the volume unmountable. Ask me how I know. The windows_names option prevents that.

At work, we use PiSignage for a large overhead screen. It’s based on Debian and uses a fullscreen Firefox running in the labwc compositor. The developer advertises a management server (cloud or self-hosted) to manage multiple connected devices, but it’s completely optional (superfluous in my opinion) and the standalone web UI is perfectly usable.

I tried it recently. They changed the rootkit and it’s a coin flip on Linux. Genshin is supposed to work, but I’ve never been able to launch the game.