New AI policy update: LLM-generated content is no longer allowed for code, comments, or descriptions https://github.com/pop-os/cosmic-epoch/pull/3911

The only code contributions that we have approved that used AI assistance so far have been minor fixes and improvements where the risk of regression and copyright violation is low. The requirement to certify contributions under the Developer Certificate of Origin also makes the person submitting the changes liable if they are submitting copyrighted code.

Any of the more complex changes and feature developments that people have attempted have been denied and will continue be denied. If you look through all of the changes that we do merge, the vast majority of large feature developments and fixes are done by hand by trusted contributors (ie: Hojjat) and official team members who are consistently and frequently contributing large changes to COSMIC that did not involve any LLM use.

It is more the exception when a contribution that used AI assistance was used that is able to be approved and we will likely make some policy adjustments due to the amount of burden that they’re currently causing in the review process. Truthfully the only situations where AI has been useful over the last year is when the person used it for debugging purposes rather than code generation.

Accepting some contributions that used LLM assistance and being pro LLM are two entirely different things. As per the AI policy[0], use of LLMs is heavily discouraged. Contributions that fail to check every item on that list will not be reviewed. Those that correctly document their use of LLMs in each commit description will be heavily scrutinized with an unfavorable level of trust as the baseline. This filters out most LLM contributions so that only the highest quality contributions are reviewed. Lower quality contributions will likely be rewritten by hand in a completely different way if it solves a problem.

[0] https://github.com/pop-os/pop/blob/master/.github/PULL_REQUEST_TEMPLATE.md

It is normal for cosmic applications to write logs to the terminal.

You have to type the key sym name into the input field. It is not a raw shortcut editor yet.

You are already on the LTS version if you’ve installed the COSMIC Alpha 6 ISO, or did a release upgrade.

You can choose a session in cosmic-greeter through a dropdown.

3D acceleration is required with cosmic-comp right now. I’m not sure if software rendering will be ready or not for the first release, but it is on the issue board.

There’s already been explanations in every thread on COSMIC for the last 2 years. Along with a dozen interviews and conference talks. Why are you demanding answers here?

See the Ubuntu Summit 2024 talk: https://www.youtube.com/watch?v=bwrBKccfYws

It’s not resources, in fact, this Alpha performs pretty poorly on its own vs Gnome

I haven’t seen any benchmark where GNOME was more performant than COSMIC. Despite alpha status, it is already much more responsive than GNOME.

GNOME uses a single thread to render all displays in a multi-display configuration. This is often so slow that they need to rely on double or even triple buffering when the frame rate lags behind the display’s refresh rate. Meanwhile in COSMIC, thanks to the thread safety features of Rust, it was easy to implement thread-per-display multi-threaded rendering. This means that each display is rendered and composited independently on their own respective threads.

GNOME’s compositor also has an entire JavaScript runtime bundled inside of it, which it uses for drawing interfaces and handling application logic for those interfaces. All within the same process as the compositor, slowing down its event loop. COSMIC instead keeps the compositor process very lean, with all desktop interfaces running in their own isolated processes outside of the compositor via wayland’s layer-shell protocol.

If you can’t see the difference, it’s because you’re not even looking.

It can’t be fixed without forking and rewriting a lot of gnome-shell’s internal logic.

Also, COSMIC is not a rewrite of GNOME. Not even close. It is a completely different architecture, toolkit, language, and design system.

deleted by creator

Doesn’t matter. New compositor: cosmic-comp. Does not share any code with gnome-shell or mutter.

OpenGL is required, even if by software rendering.

You can’t release a desktop operating system without a file manager or text editor. The xdg desktop portal interface for the file chooser portal dialogs requires a file manager to be implemented for the portal to be able to create a file chooser dialog for the operating system on behalf of applications requested file choosers through the portal.

The text editor is also required to have a GUI toolkit featuring properly rendered and editable text. It is thanks to the text editor project that the Rust ecosystem now has cosmic-text as the de facto crate for handling text layout, shaping, and rendering with support for international language glyps, ligatured language scripts, and bidirectional text layouts.

Virtual machines have always been supported as long as you enable GPU acceleration. GNOME Boxes, virt-manager, and VirtualBox have been tested.

That just depends on your use case. I’d imagine you’d only get 5-15% performance difference. Choice of programming language and the quality of the code makes a bigger impact on performance. Case in point, Rust’s png library is 1.8x faster than the C libpng system library. Of course, only Rust applications benefit from that, unless the C libpng maintainers decide to adopt Rust’s png library as their implementation.

Not ready to release yet

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.