I’m incredibly interested in COSMIC DE! For multiple different reasons, actually.
Rust - I’m very interested to see how performant/memory-efficient this DE will be compared with other DEs. Also, I wonder how the Iced toolkit will evolve and be adopted in other projects.
Benefits over GNOME - I’m looking forward to seeing how much out-of-box customizability and features come with COSMIC over GNOME (which I’m currently using).
Maintainability going forward - Since the DE basically started from scratch and is using a much better language for robust software, I wonder how much easier and faster it would be to maintain the desktop environment. This potential improved maintainability could be huge in overtaking other DEs sometime soon.
There’s several things that make Rust more ideal for writing software that makes efficient use of resources than C or C++.
One of these is how cumbersome it is to use tagged unions in C/C++. They’re integrated as a first class citizen in Rust in the form of enums, and both the standard library and all Rust projects as a whole utilize them extensively. An example would be the Cow<'a, T> type. The compiler also has some clever tricks like zero-sized types which can reduce the size of types which contain them.
On the surface, the borrowing and ownership model is useful for guaranteeing memory safety. Yet if you take that a step further, it’s the perfect tool for finely optimizing resource usage with confidence. In comparison, defensive programming practices are the norm in C and C++ because resource management is risky. So applications written in Rust are more likely to be better optimized.
And the GNOME project doesn’t just use C/C++ right? It uses Javascript for developing all sorts of components and Python for scripting/misc utilties. That’s what I meant by more memory-efficient.
A couple of months ago our company decided to standardise on only one GNU/Linux distro and they chose PopOS. While the default desktop is better then stocj GNOME it was still far away to what I am used from the powerful, featureful and customizable KDE Plasma so after about two weeks I switched to KDE Plasma (unfortunately they have an extremely old version in their repos, but still much better).
I can only guess that Cosmic will be on pair to their current improved GNOME but will still be way lacking compared to what even an old KDE Plasma offers. And I would also much more like to see if they put more attention to keeping more updated KDE Plasma and KDE software packages in their repo. Even for Cosmic I think they would be much better of basing it on the extremely flexible and configurable KDE Plasma base and make it a heavy modification of this.
It is the application Docker that is not secure. Containers are. In fact Docker runs a daemon as root to wich you communicate from a client. This is what makes it less secure; running under root power. It also has a few shortcomings of privileged containers. This can be easily solved by using podman and SELinux. If you can manage to run Docker rootless, then you are magnitudes higher in security.
Great. I don’t know enough to use either but I think I’m going to try lean on podman from the get go. In any case, I know that all podman commands are exactly identical to Docker, such that you can replace, say, docker compose with podman compose and move on with ease.
With the specific exception of podman compose I completely agree. I haven’t tested it for a while but podman compose has had issues with compose file syntax in my experience. Especially with network configs.
However, I have been using “docker-compose” with podman’s docker compatible socket implementation when necessary, with great success
I welcome new and innovative DEs. I am tired of how some organizations handle things. I must however, acknowledge that with every additional major DE comes further fragmentation. COSMIC seems to really care and for that reason I am rooting for them. The negative effects, however, are always in the back of my mind.
linux
Newest
This magazine is from a federated server and may be incomplete. Browse more on the original instance.