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.

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.

NVIDIA believes they’ll have the Vulkan on Wayland issue fixed in the 550 driver that they are planning to release early this year. Someone’s working on a fix in wgpu that happens to also boost performance for every driver in demos.

We’ve been using COSMIC on our systems since summer of last year. Some graphics drivers have issues, particularly NVIDIA drivers using Vulkan on Wayland. There are some XWayland bugs from time to time. It is very usable as is, but some settings aren’t implemented yet, and some toolkit features aren’t fully implemented.

I hope to see Linux brought to the Web 2.0 era with proper use of Git forges. As it is, most people won’t bother to go through the existing processes unless they’re paid to do it. Raising the barrier to entry in order to discourage low quality submissions is a poor excuse. The existing system makes it difficult to get any changes approved or reviewed with a serious eye, regardless of their quality.

Matrix is a better platform for realtime communication, but it has the same issue with needing an account and being difficult to search. Any discussions that take place on Discord or Matrix will be fleeting, as it prioritizes only the most recent discussion in the chat. Thus making long form discussions about particular topics impossible.

All technical discussions should be archived on a searchable forum. If you are using a source forge like GitHub and GitLab, then public discussions should take place there. There’s no better place for discussions and questions about code than in the same place where the code is hosted itself. Platform integrations make it very easy to associate discussions to commits and merge requests.

While not ideal, even hosted forum platforms like Lemmy and Reddit are still better than using a chat client. If only to serve as a platform for broader public discussions and questions. People are more likely to already have a Lemmy or Reddit account than they are to have a GitHub or GitLab account.

I don’t need Google to tell me what I already know since writing software in Rust for the last 8 years. It was your argument that Rust is not suitable for newbies. So if you want to change the topic to what language a person should learn, then Rust is most definitely at the every top. It’s a life-changing experience that significantly boosts your programming skill once learned. There’s a reason why it’s been the most loved programming language on Stack Overflow for seven consecutive years. Not because it’s hard, but because it’s enjoyable to learn and use. The patterns and techniques that Rust teaches are useful in every language.

The Rust community is a very diverse group of people with many different opinions. It is not a universal truth that the Rust community believes Rust to be an awful first language. I’ve known plenty of people who started their careers with Rust. I started my career with Rust, too. The complaint with difficulty adapting to the borrow checker has been irrelevant since the 2021 edition of Rust. The borrow checker has become smarter about rearranging borrows and automatically tagging lifetimes in most cases. The remaining constraints that the compiler enforces are also hard requirements to learn when developing software in any other language. The same practices equally apply to all software. For example, mutating an array while iterating it in Python or JavaScript will lead to unexpected behavior. Python and JavaScript’s lack of a proper type system causes a lot of software to explode at runtime when you think inputs are always X but suddenly in one case it happens to be Y.

I believe you’re mistakenly assuming it’s more difficult to work with than it really is. For example, imagine telling someone that pattern matching in Rust is more difficult than constructing unions and casting pointers in C. Even something as simple as string manipulation is a lot easier to do with Rust than in C or C++. I’ve worked with a number of people over the years that had little experience in programming outside Rust. It’s not that difficult.

You’re not making the strong case that you think you are. Quite the opposite. The ease of “shooting yourself in the foot” is precisely what makes it so difficult to learn. Segmentation faults and random memory corruption make it incredibly hard to get started with programming. The compiler typically providing no help at all for diagnosing where the memory handling flaws are. You need to learn how to use a debugger to get anywhere with fixing them. Many people give up when it gets too difficult to diagnose them

Rust’s constraints are very clear and concise in comparison, with a helpful compiler that will teach you how to handle memory correctly by pointing out the precise location where a borrow error occurs, and provides a suggestion for how to change your code to fix it. There’s never a question about whether a value will be passed or cloned. Cargo’s API documentation is also extensive in comparison to typical C or C++ documentation. It is a major boon for beginning programmers that the language ships a tool which automatically generates high quality documentation for every library you will ever use.

This is very over-exaggerated. A lot of people started with C or C++ as their first language. Both of which are significantly harder than learning Rust. In fact, I had a much easier time learning Rust than I had with Python and Java because the Rust compiler’s always had great error messages and documentation. Which then significantly boosted my ability to write C and C++. If, in an alternate reality, I had started learning programming today, I would recommend to my alternate self to start with Rust. Especially now that it’s gotten so much easier than when I had learned Rust when it was still in alpha. Error messages have gotten very detailed lately, to the point where many of them show the precise code to write to fix the error. The compiler’s also much less strict with borrowing and lifetimes.

For the past two years, I have also been the lead developer of AccessKit

When COSMIC development was officially announced, we mentioned that we would be using AccessKit for accessibility support. While certain people in GNOME were spreading concern and doubts about COSMIC supporting accessibility, work was already underway to integrate AccessKit into COSMIC, successfully.

You can ask on the System76 subreddit

Every Intel-based System76 laptop ships day one with Coreboot firmware preinstalled. The System76 firmware interface is also written in Rust using Redox libraries.

The next Pop!_OS release will use COSMIC as its desktop environment instead of GNOME. There will be an upgrade path, same as in previous releases.

Depends on what you are wanting to configure. To configure displays, use wdisplay. I personally use the system defaults.

Since around June/July.

The cosmic-greeter package is already installable today. It will work on any system that has greetd available. The Appearance panel in COSMIC Settings is not yet merged, but it is in the appearance staging branch.

The desktop environment doesn’t control how applications look or function. Regarding theming, GTK3 applications need a GTK3 theme, GTK4 applications need a GTK4 theme, libadwaita applications need a libadwaita theme, and KDE applications need a KDE theme. Our tooling for generating themes will attempt to generate themes for other toolkits, but COSMIC applications have a different design language than GNOME or KDE applications.