Most of those are perfectly ready for every day use without issues today. All are alternatives that bring new features and specific use cases, solving new problems, or solving old problems in innovative ways. Wayland is an active replacement to an existing technology, as the old X is expected to just not exist anymore at some point in the future. BTRFS isn’t intended to replace Ext4 wholesale, Flatpaks doesn’t intend to replace apt/pacman/etc., Pipewire does the same that Pulse and Jack but Pulse and Jack won’t stop existing. Adwaita existing doesn’t mean that you can’t use QT or GTK in your projects. That’s the difference.
As a result Wayland has the burden to actually fulfill and comply with all the features and use cases that X11 already does, with all the new security improvements on top. That’s a tall order, and until it can do so, it will be undercooked and under adopted, because they set themselves up to that bar, nobody but them is responsible for this. Is the ancient “let’s rewrite from scratch” trap that all dev teams fall on at least once in their lives. It isn’t impossible, but it always takes way longer than the optimist project managers anticipate.
Feature parity with X has never been the goal. Because most of X’s features are a legacy of the 80’ and dreadfully obsolete anyway.
I’m all for maintaining compatibility where it makes sense, but carrying over a 40 years old feature set just in case is the best way to prevent anything from moving forward.
Wayland can already do or is actively being developed for stuff that is relevant to modern systems: multi-monitor with different refresh rates and scaling, HDR etc. Stuff that X would never dream of.
Feature parity, maybe not, but use cases, definitely is the goal.
I’m just saying that if users have to run X compatibility portals to get basic functionality for every day tasks, then something is not fully baked yet. There’s nothing wrong with that. But apparently pointing it out is some sort of herecy.
I don’t think it’s heresy, but I always find it funny that an extremely vocal community shits on systemd for being a bloated tentacular monster shat should be abandoned, but praise X for being a bloated tentacular monster.
In a way, Wayland is much closer to the Unix Philosophy than X. It’s a display protocol, nothing more. Everything else should be implemented by the applications using this protocol. X has grown over the decades to include way too many features and edge cases.
Translation layers like XWayland are important and extremely useful for the transition period, but shouldn’t be taken as a sign that Wayland is not ready for prime time. If 10% the people shitting on Wayland had instead worked on adding Wayland functionality to their favorite apps (that includes you fuckers at nVidia), the transition would have ended years ago.
Lets apply that logic to everything in the linux eco system get rid of BTRFS,Flatpaks,Libadwaita,pipewire…
Most of those are perfectly ready for every day use without issues today. All are alternatives that bring new features and specific use cases, solving new problems, or solving old problems in innovative ways. Wayland is an active replacement to an existing technology, as the old X is expected to just not exist anymore at some point in the future. BTRFS isn’t intended to replace Ext4 wholesale, Flatpaks doesn’t intend to replace apt/pacman/etc., Pipewire does the same that Pulse and Jack but Pulse and Jack won’t stop existing. Adwaita existing doesn’t mean that you can’t use QT or GTK in your projects. That’s the difference.
As a result Wayland has the burden to actually fulfill and comply with all the features and use cases that X11 already does, with all the new security improvements on top. That’s a tall order, and until it can do so, it will be undercooked and under adopted, because they set themselves up to that bar, nobody but them is responsible for this. Is the ancient “let’s rewrite from scratch” trap that all dev teams fall on at least once in their lives. It isn’t impossible, but it always takes way longer than the optimist project managers anticipate.
Feature parity with X has never been the goal. Because most of X’s features are a legacy of the 80’ and dreadfully obsolete anyway.
I’m all for maintaining compatibility where it makes sense, but carrying over a 40 years old feature set just in case is the best way to prevent anything from moving forward.
Wayland can already do or is actively being developed for stuff that is relevant to modern systems: multi-monitor with different refresh rates and scaling, HDR etc. Stuff that X would never dream of.
Feature parity, maybe not, but use cases, definitely is the goal.
I’m just saying that if users have to run X compatibility portals to get basic functionality for every day tasks, then something is not fully baked yet. There’s nothing wrong with that. But apparently pointing it out is some sort of herecy.
I don’t think it’s heresy, but I always find it funny that an extremely vocal community shits on systemd for being a bloated tentacular monster shat should be abandoned, but praise X for being a bloated tentacular monster.
In a way, Wayland is much closer to the Unix Philosophy than X. It’s a display protocol, nothing more. Everything else should be implemented by the applications using this protocol. X has grown over the decades to include way too many features and edge cases.
Translation layers like XWayland are important and extremely useful for the transition period, but shouldn’t be taken as a sign that Wayland is not ready for prime time. If 10% the people shitting on Wayland had instead worked on adding Wayland functionality to their favorite apps (that includes you fuckers at nVidia), the transition would have ended years ago.