I don’t mind The Register, and overall I think the article was objective and informative. There’s a couple things I think should be noted. Firstly, it mentioned Pop uses systemd-boot instead of GRUB and kind of inferred that was unusual. It might seem unusual when comparing it to the number of distributions still using GRUB, but if you consider things logically, using systemd-boot on a system that uses systemd it makes a lot more sense than using an old, bloated, unsecure chain-loader. Systemd-boot meets Freedesktop bootloader specifications for a bootloader with systemd. It’s simple, fast and secure. You can use GRUB if you like, but it’s probably only familiarity that keeps it around.
I don’t think Pop’s partition layout, use of encryption is “overly paranoid”. It’s timely and necessary!
And finally, I don’t think the author completely comprehends what is possible with COSMIC desktop. I could understand their POV if COSMIC was actually like GNOME in that it is difficult to modify heavily without causing instability. Gnome modification also relies on third party software which GNOME often don’t support. So saying “If you don’t like GNOME, you won’t like this” could be true if stock COSMIC wasn’t able to be modified easily. However, COSMIC is supremely easy to modify and people who like KDE, Cinnamon or any other desktop will be surprised to learn that they will likely be able to use Pop!_OS with COSMIC and make it look like KDE, Cinnamon, Gnome or even Windows. It’s only a matter of desktop configurations, most of which will be native in Settings, and with the difference being COSMIC will remain stable. I will also mention that Gnome have never had a native tiling solution.
COSMIC is not Gnome. It’s not even a fork of Gnome. It doesn’t even use GTK3. It’s completely new, and when alpha2 is complete I’m sure many people will suddenly “get it”. COSMIC is integrating many features that Gnome have been removing for years.
Register, I like you, but I think you missed some important considerations.
Yeah, the author normally rarely misses an opportunity to complain about KDE being too complex in his articles - and COSMIC aims to fall in that sweet spot between the extremes that are GNOME and KDE, while adding features like optional but native tiling.
The applet concept where applets live in their own process and communicate via Wayland protocols (behind a COSMIC API) is also less likely to break than GNOME plugins that are horribly injected into its bowels.
Given the toolkit, organized development and UX decisions being up-front designed with figma sketches, etc. that are reviewed before implemented, and having both paid developers and community contributors it has a lot of potential.
applets live in their own process and communicate via Wayland protocols (behind a COSMIC API)
Even better. A COSMIC API was not necessary since Wayland protocols already exist for this (layer-shell and security-context).
Could you explain a little more on that? Just curious.
Wayland compositors use IPC over a UNIX socket to communicate with Wayland clients. To increase security and enable sandboxed applet support, COSMIC applets use the security-context protocol for their IPC connection to the compositor. To be an applet, COSMIC applications use the layer-shell protocol to behave as an applet. Neither of which were made for COSMIC. Some other Wayland compositors support these protocols. You can see which compositors support the protocols at the bottom of the wayland.app protocol pages.
Do you think it will be long before COSMIC is available outside Pop_OS? I love Pop_OS but I’ve started running Bazzite with GNOME/Pop Shell but I know that’ll get left behind once COSMIC gets a full release.
It already is available. See the links on the COSMIC webpage: https://system76.com/cosmic
COSMIC is already available outside of Pop!_OS. There’s already a good number of distributions (members of distributions) working on integrating COSMIC. There’s Fedora and NixOS and I hear SerpentOS is interested too. Maybe Bazzite will do the work to integrate COSMIC.
I’m grateful for what Cosmic has done for Rust Wayland compositors. I’ll have to give it a try and see if it has any advantages over Sway.
Niri is also based on the smithay library we use for COSMIC, so there’s some collaborative work between COSMIC and Niri on Smithay.
I like the Cosmic tiling better than Sway, because it tiles through the long edge by default.
I.e. If I just two windows after each other, Sway will tile them as two equal columns. If I open another window, it’ll add another column, while making each column the same size.
Cosmic also creates two equal columns with two windows, but the next window tiles the focused column horizontally.
With three windows this means half the screen is a single window, the other half is two windows taking up a quarter of the screen. Obviously if you instead focus another window, it’ll be tiled instead.This is basically the same behaviour as the autotiling script for Sway/i3, but it works reliably (I’ve always had issues with those scripts).
That’s good to hear. Is it as easy to navigate and customize as Sway/i3?
Navigation within a single workspace is pretty much the same as in Sway/i3.
I don’t remember how it’s done in Sway/i3. If you have two monitors side by side, moving the focus from the left most window on the right monitor to the left, moves the focus to the left monitor.
A major difference is the workspace design. In Cosmic, there’s currently a single set of workspaces for each monitor. In Sway there’s one set shared between all monitors.
The workspaces can be either horizontal or vertical, which is useful depending on how you configure a multi monitor setup. This is because with vertical workspaces, moving down from the bottom window moves the focus to the next workspace (and vice versa).
In my case with two monitors side by side, this is awesome, because moving the focus feels like moving naturally on a single giant plane. E.g. moving down moves to the next workspace, then moving to the left moves to the left monitor, where I could move up to the workspace above etc.
It’s difficult to explain for me, so I recommend giving it a try (or maybe wait a while, depending on your needs, e.g. there’s no VRR, no window rules etc. Also, currently monitors have to be aligned at the top edge to be recognised as side by side. If they aren’t, moving between monitors and workspaces doesn’t behave right.).
Thanks for all the info. This makes me want to try it even more now!
