Yes, they do, via the mintupgrade tool.

Not sure why the downvote, other than that they specified “versioned” (not rolling).

All rolling distros obviously auto-upgrade by definition.

It is pretty easy to point out how long we have been researching fusion. That said, few of the skeptics will highlight just what an explosion of private capital we have seen in recent years and how different that is to previous decades. They will not show you the previous times in history when we have seen similar patterns.

Sure this capital is speculative. And most of them will have picked the wrong winner. But history tells us that this is what it looks like before a technology succeeds. Not 30 years before. More like 10. Which means saying 5 is ambitious but not exactly crazy.

Fusion does not belong in your list. First, some of them exist. You can buy a 3D printer with bitcoins. Of those that don’t, none has more than perhaps one resource unconstrained backer. Not a lot of people think we are colonizing Mars anytime soon. Fusion has billions of dollars of private capital chasing it as this point.

The situation may be closer to Quantum Computing than your examples. And I would say there are more physical unknowns in quantum computing. Because we do not have a quantum computer we can see in the sky everyday.

Your list looks funny in another way. Did you know that a company just launched a solar power satellite to do AI in orbit. It is up there and operational. They want to build a solar powered AI data-center in space. Whether you back such and idea or not, you cannot say something is impossible that has already been done.

And sometimes things work out differently than intended. For example, the technology developed or fusion stelerators is being use for drilling. One use may be to drill geothermal power vents. Who knows, maybe fusion power research will inadvertently make geothermal so cheap that fusion reactors no longer make economic sense.

Our first “Linux put me in the hospital” story of 2026!

Ironically, the bug report I read was originally filed for Android as crashpad did not built with bionic either (bionic being the C library on Android).

Glibc is the most popular C library on Linux but also the most non-standard.

It may be that they are picking geographically close mirrors that are massively slower. The difference between connecting to a very remote mirror can be up to a couple hundred milliseconds latency and a few percent in bandwidth due to “the Internet” itself.

But the mirrors themselves can vary massively in performance. First, it may be older hardware that gets more easily overwhelmed. But it may also be on a connection with far less bandwidth. If that outgoing bandwidth is being shared across many users, you may not be getting much of it.

I am fortunate enough that the speed of the package manager itself would make a bigger difference.

But connecting to a slow mirror can be a killer so, If that was a frequent problem for me, it would absolutely factor into my decision.

I guess the other factor is how often you are updating. For a rolling distro, it would be essential.

On Debian Stable, I would care a lot less. Just let it update overnight once in a while.

As somebody with a dozen workstations running MUSL, I disagree. But you are going to want to use a performant allocator.

The issue with C libraries is that you will have problems using pre-compiled binaries that are dynamically linked against a different C library.

If I gave you a binary dynamically linked against MUSL, it would not work with Glibc either. It is not some kind of MUSL deficiency.

The issue of course is that most pre-built proprietary software was built against Glibc. The proprietary NVIDIA drivers are a good example. But all the in-tree GPU drivers are fine.

There is gcompat which pretends to be Glibc and forwards calls to MUSL from software that is trying to call Glibc. That may be enough to make things work sometimes.

So there are two answers to “what works with MUSL?”.

The first answer is that, if the software is linked with MUSL when it is built, almost everything works. A musl based distro could have a huge package library.

The second answer is that, if you are trying to run software that was dynamically linked against a different C library when it was compiled, then basically nothing works. This is no different than missing any other dependency. Gcompat is a hack that makes programs use MUSL when they try to call Glibc, and that will work some of the time.

As an aside, MUSL allows you to statically compile programs which means they include the C library in their binary. This allows these programs to run regardless of what C library is available on the local system. For this reason, MUSL is often used to create static binaries even on systems that use Glibc. Pacman on Arch is a good example.

Chimera Linux builds MUSL with mimalloc. As a daily Chimera Linux user, I can say that Firefox works pretty well.

You may want to take a look at their configuration.

https://github.com/chimera-linux/cports/tree/master/main/musl

Why do you say that it “seems to work”?

If it is no longer visible on the network, are you sure it is still booting successfully?

I have never used dropbear but, if it is promoting for a password, doesn’t that mean the system has connected over the network successfully?

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.

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.

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.