My experience with Arch is that it has been very solid and stable. It is just “makes sense” for the most part and so issues are very resolvable.
If you use the AUR, you can get times when packages need to be excluded ( held back ) in order for the overall system to update. I do not see that as an Arch problem and it is easy to handle.
One thing that is an Arch problem is that, if you do not update often enough, you can end-up with outdated keys that prevent you from installing before packages. The solution is just to update the keyring before updating everything else but this is confusing for a new user and kind of dumb in my opinion. I feel like the system should do this for me.
Ironically, I find Arch is most stable if you update very frequently ( which makes the updates smaller and more incremental ). I do a quick update almost every day without any fear of breaking my system. Any “problems” I have had with Arch updates are trying to update a system that has not been updated forever. Even then, it is just a bit more work.
Another thing that can happen if you leave it too long is that packages will have been replaced by newer ones. Keeping up to date means there are only going to be a small number of those. An update after a year can run into a surprising number of them.
I dug out an old laptop that had Arch on it from 3 years before. Updating it was annoying but in the end it was totally up to date and stable.
Xwayland is likely to be with us a very long time. I do not see Motif adding Wayland support anytime soon for example. How long for GNUstep to hop on board?
I am usually on the pro-Wayland side but with GNOME and KDE the Wayland implementations are fairly independent. That means that your statement that KDE going “Wayland by default is going to benefit gnome too since it’ll put more priority on bugs” is watered down somewhat.
Fixing bugs in the KDE compositor / display server ( KWin ) will not necessarily address bugs or missing functionality in GNOME ( Mutter ). A lot of what they share is also shared with Xorg ( libinput, libdrm, KMS, Mesa ).
On the application side, apps lean heavily on the toolkit libraries. KDE apps are built with Qt and GNOME apps are built with GTK. Fixing Qt bugs may not improve the quality of GTK and vice versa.
Smaller projects will share more infrastructure. Many other environments are using Wlroots as a compositor library for example. Fixing bugs there will benefit them all but again is independent of KDE and GNOME.
Your point is still valid though. For one thing, the larger the Wayland user base, the greater the number of use cases the Wayland protocol itself will be adapted to address and the more testing and development everything in the Wayland ecosystem will get.
Over time, one benefit of multiple implementations will probably be code quality. Apps that run well in multiple environments are well implemented and the same is true of environments that provide the necessarily features to a large body of apps. In that way, more bugs will be found and fixed in all environments.
If you are a Linux user and like commercial games, you probably would prefer them to work on Linux.
“Market share” on Linux aligns the vested interest of game makers and Linux game players. If the company thinks it can make money, it will do more to allow games to run, or at least do less to stop them.
I realize that the major point of GIMP 3 is the port to GTK3. That said, I feel like colour spaces are what people have been waiting for and probably the most significant deficiency that keeps GIMP from being treated as a professional tool.
If they are really this close, why not set the GIMP 3 release date for when colour management is ready?
Non-destructive editing will be huge as well. GIMP 3 is really going to be a crazy leap forward. It is going to be amazing to finally get access to all this work that has been walled off for decades.
The bug situation sounds terrible. Honestly though, they should just get 3 out and then make bug fixing the number one job until it gets into better shape.
Not only is it a small team but right now there are basically two different projects ( 2 and 3 ). With only one code base, perhaps the pace of progress can improve.
Now that you mention it, Trump sounds a bit like the way FreeBSD people talk about Linux.
“When they send us Linux distributions, they are not sending their best. Linux is an unplanned, undocumented, unusable, crashy mess. Some, I assume, are also good distros.”
A lot of people are saying its the best. Perhaps they are right. I don’t kmow. And I hear it all the time. “It’s the best! It’s the best!”. Who knows. But a lot of great people are saying it. Maybe the best people. That’s just what I hear.
Agreed ( on the code ). Wayland and Xorg also share libinput, libdrm, KMS, and Mesa.
The biggest difference is that Red Hat will stop bundling this stuff up together, testing it, and created releases. Most of the actual code will still be maintained though.
I think they may actually be suggesting that you let each OS be the primary OS and then just control which one you want via boot order in the BIOS.
But yes, if Windows is able to install its boot loader on its own drive, it will not mess up the Linux boot loader on another drive. The Linux boot loader can detect Windows though and allow you to boot to it ( and Linux too of course ). That is why you make sure Linux boots first.
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.
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.