And quite a dishonest readme at that. All the “not natively supported” entries for things designed to work with XDG desktop portals are hilarious.

This is obviously more of a political statement than anything else. I would not expect much from it.

I will bet the full dollar that Trinity never gets ported to Wayland.

They would have to port it to a version of Qt that supports Wayland. If they were ever going to do that, they would have done it by now.

MATE (GNOME2) ported from GTK2 to GTK3 so most of MATE works on Wayland today. You can use all the bits with a different Wayland compositor. And I think they are making their own.

But Trinity maintains their own fork of Qt3. Bringing that up to Qt6 or adding Wayland to Qt3 would be a big project. I do not see either happening.

Xorg fans will not accept that people like Wayland better because it is a better experience: higher performance and less jank. But that is the main reason and the reason that 80 percent of new Linux desktop users start on Wayland and will never switch. It does not matter if you believe it.

And of course the “killer feature” of Wayland is that it runs Wayland apps. And Wayland-only desktop environments and compositors. This will matter more and more every day. I could live without foot and COSMIC but already the fact that I cannot use Niri on Xorg is all I need to know to be Wayland exclusive.

But if you need an itemized list:

• HDR
• VRR
• Multi-monitor fractional scaling
• Tear-free
• isolated I/O
• multi-touch
• kinetic scrolling
• security in general
• and probably more

Waypipe and WPRS are better than the X11 equivalents.

Oh, and inevitability.

There are few Wayland only apps today. But as the percentage of Linux desktop users on Wayland goes over 80 percent, that will change.

And today, GUI toolkits and desktop environments have to limit features to those that will work in both environments. But not for long.

My guess is that it will be totally impractical to use an X11 only desktop 3 years from now. 5 for sure. In fact, I bet few people will even have Xwayland installed 5 years from now. To run what? Xfig? Netscape?

But certainly it will still be possible to run an X server. Xorg itself will still probably run fine. It already uses KMS and DRI from the kernel and those may not change much. And I am sure at least a few zealots will still be pushing XLibre a decade from now. And Wayback will almost certainly let you run an X11 desktop for many, many years to come for those “legacy use cases” you talk about. Like running CDE for a couple of hours.

Probably the most interesting development has been Phoenix. They have floated the idea of having an X11 first environment (eg. using an X11 window manager) that can run Wayland apps too. If that actually happens, I am sure it will find some fans. If you have spent 15 years fine-tuning your FVWM or Xmonad config, you won’t want to give it up.

It will be interesting to see where the BSD world goes with all of this. I think FreeBSD will go Wayland. But NetBSD and OpenBSD could be x11 holdouts. But the Wayland-only app problem will impact everyone. Time will tell.

Wayland has improved a lot in the last few years. And yes, there are and have been differences in hardware.

I think the biggest difference is likely to be software though. Primarily in two ways.

First, a lot of people are using older software. Not to pick on Debian but it is a good example. A Debian Stable user may be using NVIDIA drivers that are literally years older than what an Arch user is using. Paired with Wayland compositors and XDG portals that are older as well. So when they talk about Wayland (even today), they are really describing the experience from years ago. Alma Linux probably falls on this camp.

Second, what use cases are well supported on Wayland still varies from compositor to compositor. Somebody using Plasma 6 may experience that pretty much everything just works. Somebody using Sway may find that some uses cases are still immature.

Put these together and you have a lot of NVIDIA on Debian people telling you things don’t work and a lot of AMD on Fedora people wondering what they are talking about.

Today, Wayland and Xorg are more “different” than better or worse. If you are happy with Wayland, migrating to Xorg would probably feel like a real step back and there would be all kinds of issues and deficiencies. But, for some, the reverse can still be true. Wayland still has a few gaps.

Finally, they ARE different. Which means that if you insist on trying to make Wayland work exactly like X11, it is easy to make it seem like it is not working, even if Wayland can do exactly what you need in some slightly different way.

The important thing to acknowledge though is that more than half of Linux desktop users run Wayland now. And the majority of new users start in Wayland and will never switch. So X11 is the weird one now. And while Xorg is about as good as it is ever going to be, Wayland gets better every day.

So, 6 MUSL bugs for all of Gentoo?

And three of them are the same just for different versions of MUSL. And reading the bug report, it seems like a commit has been created and is awaiting review.

If all that is true, we have our answer. MUSL works with everything.

The default allocator is very slow but it can be changed. Chimera Linux, for example, uses mimalloc which is very fast.

My distro is based on MUSL. I seem to remember finding something that would not build on it but I do not recall what that is. In addition to the thousands of packages I am using, I have compiled hundreds of applications. Compatibility is very high.

Certainly it is clear the “most applications” work with MUSL.

That is, the source code does.

gcompat is when you want to run something that is already a binary that wants to call into Glibc. I try to avoid that so I cannot comment much.

There is the odd time I have had a binary built for Glibc that I could not avoid. For example, bootstrapping .NET or the version of vcpkg that the Ladybird browser uses in its build system. To be honest, in those cases, I just reach for Distrobox and drop into a distro that has Glibc natively, like Arch. Or I might use a RHEL Distrobox for a commercial binary meant to target that distro.

Clearly running a binary without one of the dependencies it was built against is a problem no matter what library you are taking about. But if we are just asking what works on MUSL, I would say almost everything.

I can almost guarantee that the problem you encountered was an outdated archlinux-keyring that meant you did not have the GPG keys to validate the packages you were trying to install. It is an annoying problem that happens way too often on Arch. Things are not actually screwed up but it really looks that way if you do not know what you are looking at. One line fix if you know what to do.

It was my biggest gripe when I used Arch. I did not run into it much as I updated often but it always struck me as a really major flaw.

Half of them probably will. People are like that.

Many times, I have seen people switch tech because something is missing or has changed…and they switch to something that also does not have it. Boggles my mind.

It could be that /dev/sdb2 really does not exist. Or it could be mapped to another name. It is more reliable to use UUiD as others have said.

What filesystem though? Another possibility is that the required kernel module is not being loaded and the drive cannot be mounted.

Nothing that uses apt is remotely bullet-proof. It has gotten better but it is hardly difficult to break.

pacman is hard to break. APK 3 is even harder. The new moss package manager is designed to be hard to break but time will tell. APK is the best at the moment IMHO. In my view, apt is one of the most fragile.

COSMiC has made Iced and Smithay stronger. Now Niri is based on Smithay. I for one are happy they spent their time on something other than GNOME.

GNOME has been shedding market share to KDE and now COSMIC is going to take a chunk of the rest.

Sour grapes.

Unbelievably ignorant take.

Arch and its forks are, in my view, the BEST options for a daily use desktop.

FreeBSD has made a real laptop push recently and 15.1 is supposed to offer KDE out of the box.

Depending on your hardware, it is really viable now.

/tmp should be just that (temporary).

There should not be any ill effects to completely empty /tmp

Some distros put /tmp on a ram drive that gets created fresh (and empty) with each reboot.

Almost everything you care about should be in /home so back that up. Many people keep it on a separate partition or drive to make changing distros (or reinstalling the existing one) easier.

Most of your system config is in /etc so you may want to make a copy of that too.

But the proper process on Linux is not to re-install. It should not be necessary.

On top of this, part of the reasons to use containers is that you can create and destroy them at will while leaving your host tidy and stable. I use Distrobox quite a bit for this reason.

Decent point. Not every grandmother is my grandmother. And a 21 year old that has only used phones and tablets to consume content may actually be less tech literate than an older person with no screen experience that knows how to fix their car, blender, or sewing machine.

If you install a kernel from the Arch repos, DKMS will build the kernel module for you automatically as well as the initial RAM disk and boot entries. Kernel upgrades take a little longer but you do not have to do anything manually.

It will work with custom kernels too but, if you do build your own kernel, you have to make sure a couple of options are selected.

https://wiki.archlinux.org/title/NVIDIA