I’m a System76 engineer / Pop!_OS maintainer. I’ve been a Linux user since 2007; and Rust since 2015. I’m currently working on COSMIC-related projects.
They commented on their video that it was their fault. There was never a packaging issue. The issue was that we pushed a systemd source package update to Launchpad, which silently didn’t build or publish the 32-bit systemd library packages, because Ubuntu had systemd on a blacklist for 32-bit package builds. We noticed this minutes after packages were published, and had it fixed within an hour later.
This didn’t actually affect any systems in the wild because apt held back the update until we had worked around the restriction on Launchpad (there was an invisible ceiling to the package version number). They were only affected during that time period because they manually entered that sentence from the prompt in a terminal. We stopped using Launchpad with 21.10, so all packages released since then are the same packages that are built and tested by our packaging server, and used by our QA team internally.
The drama and reputational damage that LTT caused was unnecessary. Especially given that they uploaded this video a week later, and never attempted to reach out. They still have yet to properly edit the video.
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.
You can generate documentation by running cargo doc and browsing the generated web pages in target/doc. There are also examples in the examples directory of libcosmic, as well as a design demo example which is a WIP.
libcosmic is an alternative toolkit for building desktop applications and layer shell applets. It wouldn’t make much sense to build a toolkit only for ourselves. It’s the best way to develop layer shell applets for COSMIC, and other Wayland compositors that support the layer shell protocol.
Iced is a lower level GUI library, similar to what GDK is to GTK. We built our own COSMIC-themed GUI toolkit around iced, which is called libcosmic. As we’ve gotten more and more widgets and application logic developed, actual application development with libcosmic is a breeze. Even if you do have to create a custom widget, it’s much easier to creating custom widgets in GTK. We’re able to develop much faster than we ever could with GTK now.
Yew and Leptos aren’t comparable since they’re not native GUI toolkits. These are for web developers rather than application development. It wouldn’t be possible to use this for developing layer shell applets for COSMIC, either.
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.
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.
If they support the wlr output configuration protocols, then yes it’ll work fine. There are some more advanced features that we want that aren’t supported by the protocol though, so we will likely develop some cosmic protocol extensions for those features.
No, we have been making our own platform toolkit (libcosmic), which is built upon iced-rs. We are using this both for our wayland compositor applets, and our desktop applications.
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.
It’s difficult to say for sure with certainty what the issue is without trial and error. I would expect that the motherboard’s manufacturer would make sure that their board can successfully pass all tests with the standard JEDEC spec for DDR4 (2133 MHz).
Since you say that you’ve tried different RAM kits, another alternative could be the cleanliness of power from the power supply. Perhaps there is intermittent voltage droop, and you need to experiment with the Load Line Calibration settings to adjust for vdroop between idle and load. Disabling frequency boosting and manually setting the CPU frequency could help check if it’s related to that. PBO curves might be undervolting too much while idle.
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.
Make sure you have the latest firmware for your motherboard. This sounds like unstable voltages for memory, or an overly-aggressive PBO curve. Did you try disabling the XMP profile on the RAM, disabling PBO, and upping the voltages (within safe limits) of the SOC, DDR, and VDDP? You might find some useful info here[0] or here[1] if you intend to run your memory at 3200 MHz.
As pointed out in This Week in GNOME, there’s been some continued work on Variable Rate Refresh for the GNOME desktop. The VRR setting within GNOME Settings continues to be iterated on as the developers iron out how they’d like to present the Variable Rate Refresh setting for users. The developers have been discussing how to...
COSMIC is a Wayland desktop environment for Linux that is written in Rust with Smithay and Iced. COSMIC applications are developed with the libcosmic platform toolkit, which is based on iced. They are cross-platform and supported on Windows, Mac, and Redox OS in addition to Linux....
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.
It’s been explained 100 times ad nauseam over the last two years. Go read comments from previous months’ updates if you want to catch up.
As for cross-platform compatibility, this should not come as a surprise because everything is written in Rust, and the libraries we use are already cross-platform by default in most instances. Supporting multiple platforms takes almost zero effort on our part. Especially when we could design something from the ground up that’s easy to adapt.
Linux Distros Evolution - January 2024 Update: Pop!_OS in Decline? (boilingsteam.com)
An interesting trend graph of the most diffused distros and their adoption by users over time.
COSMIC: The Road to Alpha (blog.system76.com)
Random application segfaults on Arch
Hi everyone,...
GNOME Sees Progress On Variable Refresh Rate Setting, Adding Battery Charge Control (www.phoronix.com)
As pointed out in This Week in GNOME, there’s been some continued work on Variable Rate Refresh for the GNOME desktop. The VRR setting within GNOME Settings continues to be iterated on as the developers iron out how they’d like to present the Variable Rate Refresh setting for users. The developers have been discussing how to...
December Updates: The Spirit of COSMIC (blog.system76.com)
In-progress COSMIC apps: terminal, file manager, text editor, and settings (fosstodon.org)
COSMIC is a Wayland desktop environment for Linux that is written in Rust with Smithay and Iced. COSMIC applications are developed with the libcosmic platform toolkit, which is based on iced. They are cross-platform and supported on Windows, Mac, and Redox OS in addition to Linux....
COSMIC Edit with project-wide search (fosstodon.org)
https://lemmy.world/pictrs/image/43bacf86-09d6-485f-b771-e9d8600bdbcf.png