cross-posted from: https://lemmy.world/post/13038090
https://fosstodon.org/@soller/112083947500126938
COSMIC Store is coming along quickly, though there is still a lot left to do. It loads nearly instantly, because it uses bitcode to cache appstream data in an optimized format. It uses very little memory compared to the Pop Shop. Searches can be performed live as they are done in parallel. Searching for “e” takes 5.5 ms on my desktop and returns 4601 results.
You must log in or register to comment.
I just realized that I haven’t read any infos about the package manager that Cosmic is going to use. Is it going to be build on top of Ubuntu like Pop!OS and use apt? Are the apps going to be served by the package manager or as Flatpaks? If the later, it could be interesting to public them on the Flathub Beta remote when they reach that stage.
Cosmic is a desktop environment, not a distro. So Pop!OS will keep using deb packages and something like a Fedora Cosmic Spin will use rpm packages.
I assume you meant Pop!_OS instead of COSMIC. Pop!_OS 24.04 will be based on Ubuntu 24.04.
This is not relevant to this specific post but does anyone know how if the static linking used in Rust is an issue with cosmic?
The last time I tried building a small app with Iced it was pretty bing (20MB) even though it didn’t do much. On the other hand a GTK app in rust easily fits within 5MB.
Anyway I’m thrilled to try cosmic out as soon as it reached the Arch repos.
Static linking is not an issue. Binaries may require more space on disk, but the benefit is that they are self-contained, portable, with excellent performance, and low memory usage. Binaries are compiled with LTO, so unused functions are stripped from the binary. What remains is highly optimized to that application’s use cases.
It looks like I was right: https://github.com/pop-os/cosmic-applets/pull/282
20MB for every simple application is a lot, and multical binaries won’t be an option for third party developers.
This is still worth the much better DX of using Rust though.
I wouldn’t rule out the possibility of a cosmic-applets-community package which bundles third party applets, or the gradual inclusion of popular applets into cosmic-applets. Given that an applet would only become popular if there’s a lot of need for those use cases, then it would make sense to open a path to getting them mainlined.
I wasn’t thinking about applets but more about full-blown libcosmic applications.
Gnome Circle bas a lot of very simple apps that do just 1 thing and weight a couple MB each at worst.
With iced such an ecosystem would be at 20MB per app, so simple " don’t 1 thing and do it right" apps would be less scalable. And I doubt you would want to have all of gnome circle as a multicall binary.
You might be surprised how much disk space those GNOME Circle applications actually require, despite being dynamically linked to a lot of GTK/GNOME libraries. Unless they’re written in a scripting language, they’re much closer to a COSMIC application than you think.
- https://flathub.org/apps/org.gnome.TwentyFortyEight 12 MB
- https://flathub.org/apps/org.gnome.Reversi 12 MB
- https://flathub.org/apps/org.gnome.NetworkDisplays 13 MB
- https://flathub.org/apps/org.gnome.eog 12 MB
- https://flathub.org/apps/org.gnome.Photos 29 MB
- https://flathub.org/apps/org.gnome.Notes 12 MB
- https://flathub.org/apps/org.gnome.gedit 20 MB
- https://flathub.org/apps/app.drey.Warp 22 MB
- https://flathub.org/apps/com.github.flxzt.rnote 41 MB
- https://flathub.org/apps/io.gitlab.news_flash.NewsFlash 42 MB
I don’t see the issue with an application having a static binary within the realm of 15-25 MB. Even if you had 100 applications installed, that’s only 2 GB of disk usage.
