Thank you to everyone who has expressed interest in seeing a Fedora COSMIC and COSMIC Atomic spin come to life! There has been a ton of excitement for this idea since it was mentioned on Fedora community spaces, news outlets, and YouTube videos. Big thanks to @ryanabx for leading the charge on this initiative and @hyperreal for making the original post!
As with most things in the Fedora Project, things exist because there is a community of contributors who come together to make it happen. We manifest things into existence. Fedora COSMIC and Ryan’s work can go far, but only if he’s supported by more people. If you want to see Fedora COSMIC happen, pitching in is the best way to make it so.
Below are priority items that Ryan put together for those looking to get involved. If you have questions or would like to dive into contribution, please join us in the Matrix room for Fedora COSMIC.
Priority tasks
Leadership/participation help. If you have led or participated in a Fedora SIG before, or would like to help manage resources for one, please join the Matrix room and introduce yourself!
Packaging (and especially maintaining) rpms for COSMIC. If you have any packaging or maintaining experience, or would like to learn, and would like to help improve the packaging for COSMIC, our goal is to have all COSMIC rpms compliant with the Fedora packaging guidelines. A WIP set of spec files can be found here, and the rpms themselves are in a COPR here. Edit: spec files will be moving here.
Contributing to COSMIC’s development. If you are a Rust programmer, app developer, translator, or you’d like to contribute documentation, join the pop-os COSMIC development chat and also check out the pop-os repos on GitHub. There’s always a place you can contribute, and the developers are kind when it comes to PRs. They don’t have to be perfect from the get-go, the contributors will help you get there!
Last bit of thanks: @carlwgeorge, @decathorpe, and @ngompa have been super helpful from the Fedora side to help a new contributor get off the ground. Also thanks to @drakulix, @ahoneybun, and @mmstick from System76 for also giving input and helping thus far!
If you know of other things we should be working on, please let us know. See you in the Matrix room!
There is a GitLab issue with the Fedora Marketing Team to discuss how the Marketing Team could support further here (see my comment). We need some leadership from the folks doing the work right now to help push things further to success… is there someone can help do that leadership work, or be the face of the COSMIC DE in Fedora?
More details are on GitLab, but in order for marketing-team to empower this further, we need some help from the people working on COSMIC right now, since we are not the ones doing the development and packaging work.
I’m regularly checking the Fedora Cosmic chat for developments and right now they’re just plugging away at packaging. I did this topic and shared on social media looking for more contributors, but I don’t think more is needed for right now. Part of it is just the packaging work that needs to happen. Part of it is also syncing up with System76 and there development. For now I’d say that we’re good. We just have to let them cook.
this is a follow-up on the question I asked during @ryanabx’s talk during F40 Release Party. I booted ublue-os/cosmic-base:40-amd64 on a spare laptop to confirm the answer that I got in the chat.
COSMIC currently just puts everything in one giant systemd service, which means that everything ends up in one giant cgroup. This is not good. It’s essentially a regression to where GNOME and KDE were 2 years ago. With a bit of pain, those DEs converted to a scheme where the services and applets that are started by the DE are not spawned directly, but instead go through the systemd API which puts the program in a separate service under the user instance of systemd.
Segregating apps into separate systemd user services has the following advantages:
we can stop (gracefully or forcefully) the service, incl. if it has spawned subprocesses
we get accounting of resources and can set limits and priorities. (The kernel implements this for us, systemd just provides a convenient interface.)
the DE can start things asynchronously and systemd will take care of scheduling jobs relative to one another
systemd-oomd works properly
systemd will automatically respawn services (if configured)
we get some sandboxing (this is a moving target, and unprivileged user systemd can only implement a subset of what the system instance allows, but progress is being made).
the DE does not have to implement the code to spawn subprocesses, reap children, take care of hung processes, detect readiness.
So… I think COSMIC looks very promising, and I like the flexibility, but I would also love to avoid a regression wrt. to how apps are started. If COSMIC developers would be interested, I would be very happy to conversation and help with this.
Hi, thanks for the reply! I’m of course still learning a lot about linux and systemd, but I agree that does sound like something the cosmic team would want to know about.
Probably the best thing to do other than contacting the devs directly would be to post a bug report at Issues · pop-os/cosmic-epoch · GitHub where it can be triaged.
See you in the Matrix room!