In practice, because Rust libraries are always statically-linked, the MPL-2.0 is equivalent to the LGPL in spirit. Meanwhile, because of the static linking restrictions in the LGPL, the LGPL is effectively no different from the GPL. Hence, you’re going to find a lot of open source copyleft projects from the Rust ecosystem preferring either GPL or MPL-2.0, where MPL-2.0 is used in libraries where LGPL would have used previously in C projects. Dynamic linking is essentially going the way of the Dodo.

The Linux kernel already allows proprietary modules via DKMS, and a handful of vendors have been using this for decades, so this is no different. Case in point: NVIDIA driver, and Android vendor drivers.

All source code in Rust is statically-linked when compiled, which thereby renders the LGPL no different from the GPL in practice. For Rust, the MPL-2.0 is a better license because it does not have the linking restriction.

I’d recommend spending some time reading about it. It’s not as hard as he thinks. Applications developed for Linux are quite easy to port to Redox. It supports many of the same system calls and has a compatible libc implementation. The kernel does have abstractions to ease the porting process. And if you’re going to make a new kernel today, you should do it right and make a microkernel like Redox. One of the benefits of having a microkernel is that it doesn’t matter what language you write drivers in. They’re isolated to their own processes. Rust, C, C++, whatever.

It does work like this, but as with justice, the wheels can be slow at times.

What report are you referring to?

What GPU configuration do you have? I don’t have any of these issues. If NVIDIA, you have to wait for NVIDIA to release explicit sync Wayland drivers.

I’ve seen plenty of people using GTK themes with rectangular switches.

I’d recommend everyone to try out cosmic-store (with cosmic-icons) when they get a chance. Whether you use COSMIC or not, it’s fully functional with any desktop environment. It’s packaged by default in Pop!_OS 22.04, available in Fedora 40 via ryanabx/cosmic-epoch, and the AUR.

Yeah, it’s in the Pop!_OS 22.04 repositories, this Fedora 40 COPR, and on the AUR.

Consumes less energy (CPU) while also rendering more responsively.

I’d just remove it with sudo apt remove pop-shop, and install cosmic-store (with cosmic-icons) instead.

Pop Shop

Install the cosmic-store (with cosmic-icons) and try it out!

Speaking of being defensive, not only are you being far more defensive than I, but these bullet points are both misleading and wildly inaccurate. It’s also telling that you think none of my points are good, when they are the truth. Could you possibly be even more a hypocrite?

I think it already it is available on NixOS

Ubuntu is Debian with more up-to-date packages and a lot of additional third party packages. There’s a lot of companies who produce development toolkits, frameworks, and applications that are explicitly built for the Ubuntu base. Some governmental agencies and organizations also require access to packages and repositories that have been audited by security agencies, which Ubuntu has gone through the process of getting certification for certain kernels and their Ubuntu Pro repositories. All of which are useful for real world customers.

Regardless of shortcomings in Snap, Pop does not rely on Snaps, and offers its own packaging for things that would otherwise require Snap on Ubuntu.

GNOME Shell extensions are JavaScript monkey patch injections to gnome-shell’s JavaScript process. They’re only compatible with the exact version of gnome-shell that they target because most of them require to override private internals of gnome-shell that are sensitive to order of injection and names of private variables and methods.

COSMIC uses a modern Wayland-based approach to shell interface design with layer-shell applets. Each applet is its own process, using the layer-shell Wayland protocol to render their windows as shell components, and communicating with the compositor securely with the security context Wayland protocol. The protocols they use are standardized, so they will be stable across COSMIC releases. Other Wayland compositors could integrate with them if they desire to.

There’s a very large gap between having tiling, and having excellent auto-tiling capabilities with intuitive shortcuts and behaviors. COSMIC’s autotiling was designed from the ground up to be just as usable with a mouse as it is with a keyboard.

If COSMIC is pathetic, then GNOME must be abysmally unusable. COSMIC was already planned long before there was any beef with GNOME. We listen to user feedback and prioritize development of features that our developers and users want. Good luck trying to replicate COSMIC’s theming and tiling capabilities in GNOME. Let alone the overall stability and performance of COSMIC. COSMIC Store is the fastest app store on Linux now. I’d recommend everyone to try it out. sudo apt install cosmic-store

It wouldn’t be possible for us to build a platform toolkit, or the COSMIC platform itself, without a text editor or terminal. It would also be deeply embarrassing if we release our desktop without them. Imagine telling people they need to switch to a TTY or use a software center to install a plain text editor or terminal. It is thanks to the text editor project that we have first class text rendering across the Rust GUI ecosystem now. Without it, we wouldn’t have been achieve proper bidrectional text rendering or ligatures. The text editor project also made the terminal possible, and now any application that we develop in the future can have proper text editing widgets and embedded terminals.