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.

It already supports VRR and DRM leasing. VRR monitors and VR headsets have been tested.

Translation: no one should ever attempt to innovate on the Linux desktop. GNOME is the epitome of software development and everyone else should quietly give up. If GNOME can’t fix an issue, no one can. Only GNOME has the god-given right to make decisions on how desktops are developed for Linux. There can only be one party. The One Desktop principle. Contribute to your party leader, or else…

We will be adding integrations to our theme engine to automatically generate themes for GTK3, GTK4, and libadwaita.

The GTK4 project was cancelled for multiple reasons. We originally began working on Relm4 to use GTK4 for COSMIC applets. While others on the team were also experimenting with alternative Rust GUI libraries.

It required a lot of effort to patch GTK4 to support the Wayland layer shell protocol. Getting those patches merged into GTK4 was also taking a much longer time. There were long delays between code reviews; and they also wanted a series of much larger refactoring changes to be made to GTK4 before exposing the layer shell feature. It was much easier to get layer-shell working with iced, as it is a much leaner and concise code base.

GTK does not support fractional scaling, which is something we want our applets to support on day one. This was one of our major concerns. A concern that didn’t apply to iced.

It was also exceedingly difficult to create custom widgets with GTK in Rust. Even those of us with years of experience considered it to be unreasonably difficult. So it was not feasible to expect new hires on the team to be able to comfortably develop COSMIC components with it. In comparison, our team was able to develop custom widgets with iced with much less effort and with greater flexibility, so the demand for iced grew stronger.

At the end of the day, GTK is not a Rust toolkit, and its API is cumbersome to adapt to Rust. Use of GTK would always be a compromise that lessens the developer experience for COSMIC app and applet development. A compromise that would eventually require us to rewrite everything in a native Rust GUI library the moment it would become possible to do so.

Since we are developing a desktop environment from the ground up anyway, we decided that there would be much more value for our time if we contribute to the Rust ecosystem and utilize iced to make a fully featured GUI library for application development.

It would certainly be easier for them to port COSMIC because there are very few dependencies on shared C libraries. Cargo links all Rust libraries statically, so it’s easier to maintain and update components. This will depend how open they are to accepting Cargo and Rust into their ecosystems.

The keyword is alternative. All first party applications are written natively with our libcosmic toolkit, which is based on iced-rs. We are using a fork of iced though because we needed to implement a custom runtime with the sctk (smithay client toolkit) for COSMIC applet development, but our desktop applications will use the original winit runtime.

As long as you have access to the latest version of Rust, porting would be somewhere near cowsay.

That would compromise our vision of a GUI platform built from the ground up in Rust. It would also not be feasible to use Flutter for applet development. We can easily make modifications directly to iced for all the Wayland integrations that we need in COSMIC, as the iced code base is very lean, and written in Rust.

We are integrating AccessKit into libcosmic for accessibility support.

If you want to develop applets and/or applications with libcosmic, you must do so with Rust. There are no plans to develop C bindings for libcosmic.

COSMIC is being written in libcosmic, which is based on iced.

I don’t think you can say that because we haven’t published our design language yet. Only a handful of design mockups have been published so far. The screenshots here are not design mockups but a work in progress implementation. Hence the “In-progress” part of the title.

Rounded corners are a user preference in the Appearance page in COSMIC Settings.

Corner roundedness is personal preference in the Appearance page in COSMIC Settings. Similar to interface density.

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.

As of today, https://pop-os.github.io/libcosmic/cosmic/ is now available.

Sounds like voltage droop and/or a motherboard with faulty automatic “training” settings. I don’t recall if the Ryzen 3000 had custom PBO curves, but tweaking this can fix it. Upping LLC and the SOC and CPU voltage slightly alternatively could help. Though I’ve had my most stable overclock by disabling PBO entirely and using a manual CPU multiplier.