The main logo choice is fine, no complaints there, but the choices for the others just seem so disjointed from each other (not to mention they basically just chose the old Leap logo again, but in yellow). I really liked the idea of having some sort of unifying design element across the logos to indicate they are all OpenSUSE products. There were some decent concepts with that idea floating around.
Bcachefs still misses major features, so it’s possible to expect that performance will change over time. Just because bcachefs is upstreamed to Linux doesn’t mean it’s finished.
Does this apply to Proton as well, or have they had their own fixes for Vulkan or something? Cause I’ve been playing games on Wayland with Proton just fine for a good while now.
@leo KDE with Wayland was all crashy when I tried it. If Wayland windowing is as buggy and crashy as their browser we'll all need to switch to Windows or Mac just to get any work done.
I’m daily driving Firefox with Wayland on KDE Plasma since years, not on Xwayland, and can’t remember it not working well. This on two different distributions (Arch and NixOS). Not saying this is your fault but your experience is not representative for everyone
@Laser My experience is representative for enough people to show that Linux Desktop is a mess and is not suitable for production work. I don't identify myself by my choice of software. I just want to get work done.
@crypto@Laser Linux desktop is not one thing. If you have a company that standardizes on Gnome, then the software you need to work will work as they will likely have been tested to work. As for work, well, not everyone uses it for work.
I suppose it really depends on when you tried it. Ubuntu 23.10 has been working quite well on Wayland. I haven’t once failed down to X, and the only papercut I run into now is with differently scaled displays (100% and 150%) where OBS will crash the session when moving back and forth.
Everything else seems good as I haven’t really seen anything else break at all and I use Firefox, Kdenlive, Audacity, lots of chat apps, and played some games. Specifically, playing Vivaldia 2 while I was remotely compiling Gentoo using OBS to livestream.
I can’t say I’m a huge fan of btrfs, in my limited sample size of one I had several episodes of esoteric errors and data loss. It’s anecdotal but filesystems have never been something to give me trouble in any other scenario to date. They just exist and do their job silently in my experience, except for btrfs.
This is what I thought too, but in my case it turned out my drive was busted and btrfs detected an error and went read only… which was super annoying and my initial reaction was “ugh, piece of shit filesystem!” But ultimately I’m grateful it noticed something was wrong with the drive. If I was just using ext4 I just would have had silent data corruption. In that sense other filesystems do silently do their jobs… but they also potentially fail silently which is a little scary. Checksums are nice.
So X.Org fully dies on the 31st May 2035 with the end of Extended Life Cycle Support for RHEL 9. We have XOrg’s death day. Even if it will likely be on it’s death bed taking its final breaths for years before that.
I thought this as well but the more I think about it, the less true this seems. From an engineering point of view, it could last longer.
Xwayland is really just Xorg and Xwayland continues to be supported in RHEL10 and beyond.
Xorg and Wayland compositors have grown together in some ways. Both now use libinput, libdrm, and KMS for example. Those are not going away.
Xwayland is really just Xorg adapted to talk to Wayland instead of KMS and libinput. It is mostly the same code. So, Xorg will continue to benefit from the care and attention that Xwayland gets. Perhaps there may not be many new features but the code is not going to bit rot and security will continue to be addressed. While Xwayland does not use libinput or KMS, the Wayland compositor itself will, so those pieces are also going to be maintained including new features and new hardware support. Mesa is a common component as well.
So, while Red Hat may stop coordinating releases of Xorg at some point, a surprising amount of the code will still be actively maintained and current. It may not take a lot of work for somebody else to take over and bundle it up as a release.
What will probably kill Xorg is lack of demand.
Despite the anti-Wayland chatter, the migration to Wayland looks like it will gain substantial momentum this year and next and not only on Linux. Three to five years from now, the number of people that still care about Xorg ( as the primary display server - not as Xwayland ) may be very small indeed. Obviously it will be running on older systems for a long, long time but, ten years from now, installing Xorg on a new system is likely to be very rare ( like CP/M now rare ).
Red Hat may end up being one of the very last players that cares about Xorg after 2030. My guess is that most of the current never-Wayland crowd will have moved to it long before then.
Yeah, thank you for doing such a good explanation of it. I completely agree. Truth be told, the features I missed with Qtile on Wayland (some bugs that took a while to iron out, and are only fixed in qtile-git, as well as rounded corners, which are a work-in-progress, leaving me with only 1 issue with Qtile, that being how difficult Qtile Wayland is to install and set up, if only there was a working guide for doing so via pip, but pywayland and/or pywlroots via pip are usually broken), were all fixed by Hyprland, so I’m on Hyprland full time now, and I love it! There is only one minor issue I have (drop downs from Waybar’s systray are kinda broken on Hyprland, rendering weirdly, with strange black gaps between sections and rendering under, rather than over, windows).
Wayland is just a protocol. The WMs, compositors and applications need to implement the features the X server used to provide.
Those that don’t will become useless when X is gone.
Right so I guess I should have over specified that I hope ALL the other bits that actually make it function the same will also catch up and for example something as basic as forwarding GUI programs will simply work without jumping through a bunch of tedious flaming hoops with pitfalls on either side. It doesn’t really matter to me that Wayland has decided it’s somebody else problem.
For many uses, Wayland has feature parity now or is even the superior option. That is how it can be the default on so many systems ( including RHEL9 as per the article ).
Compositors that do not provide the features that uses want will fail to compete ( what you mean by become useless I assume ).
That said, different users will want different things and, unlike X, Wayland allows competing compositors to address different communities. Some compositors will lack features some users want while offering features that other users need. A composite targeting embedded use cases may not need multi-monitor or fractional scaling features for example. A security focussed option may think that global hot-keys and external lock-screens are anti-features. I think the Wayland world could be quite interesting.
phoronix.com
Active