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

Elden Ring. It is good for what it is, probably the best in its genre, but after so many Soulsbornes, it just feels like more of the same. Formulaic. I’ve tried it three separate times and it never grabbed me.

DT770 gang!

I was pointing out a part of the documentation that you may have overlooked. In good faith, I might add, because the documentation is comprehensive but horribly signposted. Everything I wrote in my first comment is there, but in a less human, more technical phrasing.

Ubuntu:

https://docs.python.org/3/tutorial/modules.html#packages

The __init__.py files are required to make Python treat directories containing the file as packages (unless using a namespace package, a relatively advanced feature). This prevents directories with a common name, such as string, from unintentionally hiding valid modules that occur later on the module search path. In the simplest case, __init__.py can just be an empty file, but it can also execute initialization code for the package or set the __all__ variable, described later.

Quick template: https://files.catbox.moe/g5tcy5.tar

Also, don’t delete this post. Others might need this information too.

If you have to import a directory structure, you should make each directory a module by creating an __init__.py file in them, and use relative import statements. I usually have one main.py as the entry point, which imports a lib module that contains all of the program logic.

├── lib
│   ├── __init__.py
│   ├── module_content.py
│   └── submodule
│       ├── __init__.py
│       └── submodule_content.py
└── main.py

You can import the lib directory as a module:

main.py:

from lib import some_fn

Within any module, though, you should use relative import statements to import from files and submodules, and regular import statements to import packages from the system or the venv:

lib/__init__.py:

from .module_content import some_fn # import from a file
from .submodule import some_other_fn # import from a submodule directory
from os.path import join # import from an installed package

Items that you define in __init__.py or import into it will be available to import from the module: from .submodule import some_fn. Otherwise, you can import an item from a file by specifying the full path: from .submodule.submodule_content import some_fn.

You can also import an item from a parent package using the .. prefix: from ..some_other_submodule import some_fn.

You can probably play Vampire Survivors. All you really do is move around.

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.