Flatpak wins because we need one “Linux-wide” solution—one universal package format—and it was the first.

Distrobox can make any package format work on any distro if that is what you want.

My favourite package manager is APK v3 but the distros that use it do not have big repositories. So I end up using an APK host with Pacman / Yay running in a Distrobox.

I am very pro Linux but “I like Windows” is valid enough for me. I might ask why but I am not going to act like that reason is invalid.

Speaking for myself, this is why COSMIC is appealing:

• nice middle-ground between oversimplified and over opinionated GNOME and KDE complexity
• both floating and tiling are first class
• Wayland native (no legacy)
• pushing DE innovation
• commercially backed
• written in Rust
• attractive
• fast

I also love that it is driving Smithay and Iced which matures the foundations of other great projects like Niri and even RedoxOS.

Kraft being labelled as Canadian is daft

Quite happy to see Servo coming along again. I am still excited for Ladybird and it seems more likely to deliver a truly viable browser sooner.

I am not a Swift dev but I think it has decent memory safety as well. I think it is one of the reasons Ladybird is moving to it. They evaluated Rust and decided it lacked the OOP features they needed.

The C++ that Ladybird writes is also very good. They have their own standard library (written for SerenityOS) which is very modern including memory safety and security. Still C++ though of course.

Two years ago. Absolutely.

Now. You have got to be kidding me.

1. Canada needs to be moving away from the US, not towards

2. What does Canada do when the US says it needs to pay for 90% of it to be “fair”?

BSD is well designed and cohesive but has many more missing bits and contraints than Linux. So, if you are in its sweet spot, it is awesome and maybe better than Linux. However, outside that it can be totally unusable.

For me, the biggest issue is the lack of software. There is both a mountain of it as it is of course an POSIX compatible OS and at the same time it is trivial to need important software that is missing.

As a desktop, it therefore feels very nice and also very limiting.

I love that it is actually real UNIX with an unbroken history back to the beginning. I find that really compelling. At the same time, I always get “bored” using it because it inevitably does not support what I want to do.

I am still hoping Chimera Linux finds a sweet spot that melds the two worlds in a nice way.

Shortest answer is that RISC-V is Open Source and ARM is proprietary but what does that mean?

First, it means “freedom” for chip makers. They can do what they want, not what they are licensed to do. There are a lot of implications to this so I will not get into all of them but it is a big deal. There is even a standard way of adding ISA extensions. It makes RISC-V an interesting choice for custom chip makers trying to position themselves as a platform ( think high-end, specialty products ).

If you are a country or an economy that is being hit with trade restrictions from the Western world ( eg. China ), then the “freedom” of RISC-V also provides you away around potentially being denied access to ARM.

For chip makers, the second big benefit is that RISC-V is “free” as in beer—no licenses. For chips in laptops or servers, the ISA license is a small part of the expense per unit. But for really high-volume, low-cost use cases, it matters.

In the ARM universe, middle of the market chip makers license their designs off of ARM ( not just the ISA ). This is why you can buy “Cortex” CPUs from multiple suppliers. Nobody else can really occupy this space other than ARM. In the RISC-V universe, you can compete with ARM not just selling chips but by licensing cores to others. So, you get players like StarV and MilkV that again want to be platforms.

So, RISC-V is positioned well across the spectrum—somewhat uniquely so. This makes it an excellent bet for building software and / or expertise.

It is only the ISA that is Open Source though. Unlike some of the other answers here imply, any given RISC-V chip is not required to be any more open than ARM. The chip design itself can be completely proprietary. The drivers can be proprietary. There is no requirement for Linux support, etc. That said, the “culture” of RISC-V is shaping up to be more open than ARM.

Perhaps because they want to be platforms, or perhaps because RISC-V is the underdog, RISC-V companies are putting more work into the software for example. RISC-V chip makers seem more likely to provide a working Linux disto for example and to be working on getting hardware support into the mainline kernel. There is a lot of support in the RISC-V world for standards for things like firmware and booting.

With the exception of RaspberryPi, the ARM world is a lot more fractured than RISC-V. You see this in the non-Pi SBC world for example. That said, if we do consider just RaspberryPi, things are more unified there than in RISC-V.

Overall, RISC-V may be maturing more quickly than ARM did but it is still less mature overall. This is most evident in performance. Nobody is going to be challenging Apple Silicon or Qualcomm X Elite with their RISC-V chips just yet. Not even the Pi is really at risk.

Eventually, we will also just get completely Open Souce designs that anybody can implement. These could be University research. They could be state funded. They could be corporately donated designs ( older generations maybe ). Once that starts to happen, all the magical things that happened for Open Source software will happen for RISC V as well.

Open Source puts a real wind at RISC-V’s back though. And no other platform makes as much sense from the very big to the very small.

Well, it could be genuine altruism. But I doubt a web totally controlled by Google sounds good to a company that relies on the semi-open web for its business.

This is a bit like Valve liking Linux I imagine.

The command-line is not just faster, it is also much more universal.

You and I may use different distros and different desktop environments. If you want to create instructions that tell us how to do something using the GUI, there is an excellent chance you need different instructions for each of us. If you instead give us CLI instructions, there is an excellent chance that the same instructions will work for both of us.

You are aware that Trump was indicted for Jan 6 right? The trial is on hold while the Supreme Court decides if he is totally immune to legal consequences.

I thought this as well but the more I think about it, the less true this seems. From an engineering point of view, it could last longer.

Xwayland is really just Xorg and Xwayland continues to be supported in RHEL10 and beyond.

Xorg and Wayland compositors have grown together in some ways. Both now use libinput, libdrm, and KMS for example. Those are not going away.

Xwayland is really just Xorg adapted to talk to Wayland instead of KMS and libinput. It is mostly the same code. So, Xorg will continue to benefit from the care and attention that Xwayland gets. Perhaps there may not be many new features but the code is not going to bit rot and security will continue to be addressed. While Xwayland does not use libinput or KMS, the Wayland compositor itself will, so those pieces are also going to be maintained including new features and new hardware support. Mesa is a common component as well.

So, while Red Hat may stop coordinating releases of Xorg at some point, a surprising amount of the code will still be actively maintained and current. It may not take a lot of work for somebody else to take over and bundle it up as a release.

What will probably kill Xorg is lack of demand.

Despite the anti-Wayland chatter, the migration to Wayland looks like it will gain substantial momentum this year and next and not only on Linux. Three to five years from now, the number of people that still care about Xorg ( as the primary display server - not as Xwayland ) may be very small indeed. Obviously it will be running on older systems for a long, long time but, ten years from now, installing Xorg on a new system is likely to be very rare ( like CP/M now rare ).

Red Hat may end up being one of the very last players that cares about Xorg after 2030. My guess is that most of the current never-Wayland crowd will have moved to it long before then.