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.

That is pretty limiting solution though.

First, you can only have one libadwaita library installed. So, if GNOME is already on a system, installing another DE alongside it will create a conflict.

Second, livadwaita is not designed to enable third-party theming. It surfaces the capabilities desired by GNOME, which is less and less all the time. That limits what others can do.

Do you mean by supplying your own version of libadwaita?

Absolutely GNOME.

GIMP just finally finished their port from GTK2 to GTK3 a few months ago. GTK4, released 5 years ago, has literally nothing to do with them.

Like GNOME, I think that GTK is one of those projects that now says that the letters do not stand for anything.

I imagine that the XAML output by this app would work with Uno Platform. If XAML Studio itself can be made cross-platform, this would create a fairly nice cross-platform C# story.

https://platform.uno/platform/

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!

It has really only been a problem since GTK4. A lot of the rest of the GTK universe has stuck with GTK3. Now we are seeing people come up with alternative versions of libadwaita.

We should end up seeing a fork on the GTK side with GNOME going one way and everybody else another.

I always preferred GTK and its ecosystem. But GTK is more and more positioning itself as just a toolkit for GNOME. And GNOME is more and more going not only going its own way but also not concerning itself with compatibility beyond what I will call the Red Hat Linux platform.

So I can certainly see why anybody outside of GNOME would consider migrating off GTK. I mean, this is basically how we got COSMIC as well, based off the Iced toolkit.

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 agree. I wish Flatpak used a proper package manager. You install one Flatpak and you need the entire freedesktop sdk even if you use a fifth of it. Install a second Flatpak and maybe do it again.

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.