RHEL 9 defaulted to Wayland in 2022. RHEL 10 will not even include Xorg.

I agree that businesses lag, often by years. So the fact that RHEL is so far along in the Wayland transition kind of shows how out-of-date the anti-Wayland rhetoric is.

Are you a Debian Stable user perhaps? It feels like you have been trapped on an island alone and are not aware that WWII is over.

Your point is that it is still rough and then you bring up a bunch of stuff that is no longer an issue.

NVIDIA in particular is a solved problem with both explicit sync and open source kernel modules as the default from NVIDIA themselves.

RDP, Rustdesk, and Waypipe are probably going to eat into your billion dollars (and network transparency laments).

As stated in the article, opt-out vsync is already a thing (though not widely implemented yet).

I have not used GNOME in a while but KDE on Wayland is great. And the roadmap certainly looks a lot nicer than xorg’s.

I was on a video call in Wayland an hour ago. I shared my screen. I did not think about it much at the time but, since you brought it up….

If that is your full list, I think you just made the case that Wayland is in good shape.

RHEL 9 defaulted to Wayland in 2022 and RHEL 10 will not even include Xorg as an option. Clearly the business world is transitioning to Wayland just fine.

GNOME and KDE both default to Wayland. So, most current Linux desktops do as well.

X11 will be with us a long time but most Linux users will not think about it much after this year. They will all be using Wayland.

With the AUR, there is an “it depends” since AUR packages are unofficial and variable in quality.

That said, I have a strong bias for installing the distro package over using AppImage or Flatpak.

There are three reasons not to use the distro package:

• the package is not available
• the package is too old
• the package maintainer cannot be trusted

My #1 reason for using Arch is to eliminate 1 and 2. In my experience, the AUR is almost always fine for #3.

Even when I use another distro, I put Distrobox with Arch on it and get any of the packages that the distro does not have from there.

The only Flatpak I have had to install has been pgAdmin.

Performance is not the ISA. It is just the culmination of historical investment. It will get there.

Remember, it is not about licensing costs, it is about minimizing risk and maximizing flexibility (control).

Open always wins.

It is a shame this was so obvious. Even though I saw it a week late, it was so obviously an April Fool’s joke that it was not worth reading past the headline.

I feel bad for whoever put the work in.

I love that RiSC-V is already so well supported in the Linux kernel even though the hardware is not really out there yet. When decent hardware does arrive, a fairly mature ecosystem will be waiting for it.

Compare that to ARM which took quite a while. There is already more of a culture of getting device support into the mainline for RISC-V than for ARM even now.

I do think decent RISC-V kit is coming. The existing players like SciFive are getting there, we know big players like Qualcomm and Samsung have projects, and future disruptors like AheadComputing see RISC-V as their attack vector on the current industry. And for sure China is going to surprise with a decent RISC-V offering at some point—maybe Alibaba, maybe Huawei, or maybe someone else.

The only issue with LFS is maintenance. It is one thing to set it up but having to manually keep it all up to date does not sound like fun.

I use Chimera Linux which is musl based. Compatibility is great. If you have the source, you are probably fine.

It can be a pain for projects that ship binaries as part of the build. Two examples that I have run into:

• The Ladybird browser uses vpkg and the version their scripts download assumes Glibc. You can build vpkg itself on musl but the whole process is a pain.
• dotnet requires a binary build of dotnet to bootstrap from. There are musl builds available but they assume GCC and Chimera uses Clang. Not really a musl problem now that I think of it.

Anyway, I use a Distrobox of Arch on Chimera. If I do run into something (like the two above), I just pop into that and problem solved.

Flatpak is essentially the same solution as they run in a container and the freedesktop base is Glibc based.

Not only is musl not generally a problem but, these days, it is trivial to work around it.

You are using Turnstile on Void? Cool.

You don’t like the AUR? I have moved to Chimera Linux but I still use Distrobox just for the AUR.

Older MacBooks and MacBook Airs (pre-2018 or so) make awesome Linux machines and have really come down in price. If you can find one cheap, I highly recommend them.

Intel machines later than that have T2 chips and are still good but take a bit more research.

M1 Macs are pretty well supported now but that is a different universe.

Apple makes the source code to all their core utilities available? Nobody cares but they do.

Why do they?

They are BSD licensed (very similar to MIT). According to the crowd here, Apple would never Open Source their changes. Yet, in the real world, they do.

Every Linux distro uses CUPS for printing. Apple wrote that and gave it away as free software.

How do we explain that?

There are many companies that use BSD as a base. None of them have take the BSD utils “commercial”.

Why not?

Most of the forks have been other BSD distros. Or Chimera Linux.

How about OpenSSH?

It is MiT licensed. Should somebody have embraced, extended, and extinguished it by now?

Why haven’t they?

Some people might say that so many companies contributing free and open code to clang/llvm instead of GCC is real world evidence against the idea that companies only contribute to free software because the GPL makes them. Or even that permissive licenses can lead to greater corporate sharing than the GPL does. Why does Apple openly contribute to LLVM but refuse to ship GPL3 anything?

According to the web, Red Hat is the most evil company in Open Source. They are also the biggest contributor to Xorg and Wayland. Those are MIT licensed. Why don’t they just keep all their code to themselves? The license would allow it after all. Why did they license systemd as GPL? They did not have to.

The memory allocator used in my distro was written by Microsoft. I have not paid them a dime and I enjoy “the 4 freedoms” with the code they gave me because it is completely free software. Guess what license it uses?

How is actually writing and contributing free software not “actively helping the FOSS community”?

You could do that. MIT is a very free license.

Of course, that would only be a useful thing to do if you were also going to contribute to the code.

Since you seem so reasonable…

The restriction that some people object to is that the GPL restricts the freedom of the software developers (the people actually writing and contributing the code).

Most people would agree at first glance that developers should be able to license code that they write under whatever license they like. MIT is one option. Some prefer the GPL. Most see the right to choose a proprietary license for your own work as ok but some people describe this as unethical. I personally see all three as valid. I certainly think the GPL should be one of the options.

That said, if we are talking about code that already exists, the GPL restricts freedom without adding any that MIT does not also provide.

MIT licensed software is “free software” by definition. Once something has been MIT licensed, it is Open Source and cannot be taken away.

The MIT license provides all of the Free Software Foundations “4 freedoms”. It also provides freedoms that the GPL does not.

What the MIT license does not provide is guaranteed access to “future” code that has not yet been written. That is, in an MIT licensed code base, you can add new code that is not free. In a GPL code base, this is not possible.

So, the GPL removes rights from the developers in that it removes the right to license future code contributions as you want. Under the GPL, the right of users to get future code for free is greater than the right of the developer to license their future contributions. Some people do not see that as a freedom. Some even see it as quite the opposite (forced servitude). This “freedom” is not one of the “4 freedoms” touted by the FSF but it is the main feature of the GPL.

I believe that NTsync delivers better compatibility. I do not remember the details but Fsync can cause problems sometimes. So this is more like performance without compromise.

Now that it is in the kernel, I would expect Wine to move to it and for Proton to follow suit.

One less hack to maintain.

Somewhat ironic example.

X (Xorg) has been MT licensed for 40 years. So is Wayland. So is Mesa.

I think Xorg is a good example of the real world risks for something like core utils. If you did not know or care until now that X and Wayland were MIT licensed, you probably do not need to care too much about utils licensing either.

Text is better. Not perfect. Better.