

Do you guys use the stock allocator?
Using mimalloc instead seems to work pretty well.


Do you guys use the stock allocator?
Using mimalloc instead seems to work pretty well.


Yes
But I would just use Distrobox if you want to do that.


Ah. Thanks.


Um.
First, I am not trying to recruit you to Wayland. Do what you want. I am responding to your demand to explain what is better about it and your implication that the answer is “nothing”.
Apparently you like Xorg. You like it enough that you see nothing better about Wayland. Given that, getting bent out of shape about the word “fan” appearing in my response is a bit excessive. Protest too much? Christ.
And I did not even apply that term to you specifically. I just answered your bloody question. A question that was grumpy to start with. Grace you say?
Finally, I have been using Linux since well before 1.0 when I had to spend all night on a Sun workstation downloading floppy images. And half the next day guessing mode lines for my monitor to make XFree86 work and fixing build scrips for whatever I was trying to run on it. I moved straight from OS/2 to Linux though I installed BSD/386 before that. I own both SGI and Sun (Solaris era) hardware.
My preferred Linux distro does not use Glibc, GCC, GNU utils, or systemd.
I doubt if there are many Linux technologies you have encountered that I have not. So I am not sure what point you think you are making.
That said, it sounds like you used Ubuntu a whole lot more than I did. I better walk around these egg shells before I ask if you liked it.


I could see MATE going Wayland only before XFCE does. They are a “traditional” desktop but not committed to old tech in general. Their whole system has already been ported to Wayland when used with a compositor like Wayfire or LabWC. As a small project, they may not want to maintain both longer term.
Lots of MATE users on other UNIX systems though. Not just BSD but Solaris and such. So, who knows.
XFCE is building libraries to make supporting both longer term easier. So, they should support X11 for a long time. We will see what happens if GTK5 is Wayland only.
Trinity Desktop is probably stuck on X11.
And most X11 window managers will remain X11 window managers forever. The only reason Sway exists is because i3 is not moving. There is Wayland Maker instead of WimdowMsker and DWL instead of DWM. This list goes on. What non-DE x11 window manager is porting to Wayland? I cannot think of one.
But Plasma is not ditching X for a year or more. And many distros will ship the X version far longer. The freaking out seems more like a political statement than a pragmatic requirement at this point.
If Debian Forky ships Plasma with X11 support in 2027 (and I bet it does), the first version of Debian Stable to ship Wayland-only Plasma will be Debian 15 in 2029/2030. Many, maybe most, never-Waylanders will have migrated to Wayland by then.
Does Kubuntu not use snap?
I keep my arc welder next to my water jet cutter. Check out my next video where I build a fusion reactor. The follow up shows you the quantum computer I used to model the plasma.
Why the quotes? Is the Commodore 64 Ultimate ‘old’?


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:
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.
It is my root partition and it is quite good.
Too bad the lead dev got it kicked out. It is worse for users but he seems happier.
deleted by creator


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.
I don’t use Google Crashpad but when did you last try it.
I just read a bug report that says it fixed building on MUSL in 2023. The fix was to comment out a reference to user_vfp in thread_info.h and to put the change in an #ifdef.
I assume this is in the mainline by now.