As is often the case with scientific research which many people believe to be pointless, technological innovations aren't always made by achieving the end goal, but through the technologies developed to reach that goal.

Development on COSMIC Edit has lead towards improvements to the cosmic-text library, which is used by many GUI libraries in the Rust ecosystem now. Similarly, the UX designs for the text editor improves the COSMIC interface guidelines, and puts design theories to practice. Likewise, widgets that are necessary for the editor are added to the COSMIC platform toolkit, and existing widgets and features are improved to improve the development experience for applications like this.

No one would want to build applications for a platform that lacks widgets capable of properly displaying, formatting, and editing text. Many would also find it debilitating to have a desktop environment without a text editor preinstalled. Imagine if GNOME didn't have Gedit, and KDE didn't have Kate.

Besides, this is a default text editor for a desktop environment. It is really not that complex. The goal is not to develop an IDE, but a text editor that anyone would feel comfortable using as their default editor on the COSMIC platform.

It's not as simple as you think it is. First, we use Plausible instead instead of Google Analytics, so tracking data is not being given to Google. If the choice was purely up to System76's web team, use of Google services wouldn't be required. However, you'll be hard pressed to find any online store that accepts online payments without a captcha service, because most payment processors require it. System76's payment processor also requires it, and will not allow you to substitute your own solution or bypass that requirement. Same as said here: https://lemmy.world/comment/3137069

Customer services and other web-facing frontends are also a constant target of attacks, so a captcha service is required.

Because that's not how software development works, and that's not how you make progress in the field. In order for our technical vision to be integrated with an existing desktop, such as GNOME, it would have required that they give us the reigns to their project to delete their entire codebase and rebuild it into exactly what you see today in COSMIC.

As in life, sometimes you've got to demolish, pave, and build better foundations. There's a lot of cool technologies available to build a truly next-generation desktop experience in, but you're not going to get it through rigid bureaucracy and old tools. With COSMIC, we've got freedom to make decisions and build something truly unique, and we're using our talent to show you what we can do.

This year? No. We are still working on achieving our Alpha 1 milestone.

No, we have been making our own platform toolkit (libcosmic), which is built upon iced-rs. We are using this both for our wayland compositor applets, and our desktop applications.

All desktops use the Super key nowadays. Sway, i3, GNOME, Plasma, etc. are all using the Super key. Have been for years. The standard convention is that the Super key is reserved for system-level shortcuts handled by the window manager; and Alt key shortcuts are reserved for application-level shortcuts. Your desktop might have bound both Alt and Super because of legacy reasons.

GNOME was focusing on building Rust bindings for GTK for many years before Qt development picked up. The GTK bindings were usable within a year or two after Rust's 1.0 release. Yet even today, those looking to build applications in Rust will find that GTK is the only mature toolkit right now. And if you're doing that today, I'd recommend starting with Relm4 for the best GTK Rust experience.

Rust does not support the C++ ABI, and Qt does not provide a C interface, so much work has to be done on building the tooling for binding C++ libraries to Rust. That work is still ongoing, so some have opted to use QML instead of interfacing with Qt C++ libraries. Yet if you're looking to use Qt or QML, you may as well use Slint instead. It's developed by former Qt/Trolltech developers and has a similar approach as QML.

I am still actively maintaining Pop!_OS. COSMIC has not changed that aspect of my job. Just within the last week I packaged Linux 6.6.8, Mesa 23.3.2, Just 1.22, Rust 1.75.0, and updated Popsicle's dependencies to fix a bindgen build error with recent versions of Clang. We have a systemd update that was packaged today, and I'll be doing another linux-firmware backport soon. So I don't understand why you'd think it is stagnant. We're even shipping Pipewire 1.0.0 by default, which Ubuntu hasn't yet done in the latest version. People usually complain that we update too often.

2022 was only a year and a half ago, and we ship the latest Linux kernel, firmware, Mesa libraries, NVIDIA drivers and libraries, Pipewire/Wireplumber, ZFS, Firefox, Alacritty, Lutris, Steam, and Rust. Since when did we start considering that to be "incredibly ancient"? The next LTS release is not yet available to base Pop!_OS upon, but we ship newer kernels and drivers than the latest version of Ubuntu.

We will attempt to automatically generate themes for common toolkits, but the desktop environment has no control over how the toolkit chooses to render itself or operate.

Ubuntu is Debian with more up-to-date packages and a lot of additional third party packages. There's a lot of companies who produce development toolkits, frameworks, and applications that are explicitly built for the Ubuntu base. Some governmental agencies and organizations also require access to packages and repositories that have been audited by security agencies, which Ubuntu has gone through the process of getting certification for certain kernels and their Ubuntu Pro repositories. All of which are useful for real world customers.

Regardless of shortcomings in Snap, Pop does not rely on Snaps, and offers its own packaging for things that would otherwise require Snap on Ubuntu.

I'm not sure why you think this is unique to COSMIC or elementary OS. Do you not realize that this is true of all operating systems? Look at Steam, Spotify, Discord, Zoom, and Slack for starters.

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.

They commented on their video that it was their fault. There was never a packaging issue. The issue was that we pushed a systemd source package update to Launchpad, which silently didn't build or publish the 32-bit systemd library packages, because Ubuntu had systemd on a blacklist for 32-bit package builds. We noticed this minutes after packages were published, and had it fixed within an hour later.

This didn't actually affect any systems in the wild because apt held back the update until we had worked around the restriction on Launchpad (there was an invisible ceiling to the package version number). They were only affected during that time period because they manually entered that sentence from the prompt in a terminal. We stopped using Launchpad with 21.10, so all packages released since then are the same packages that are built and tested by our packaging server, and used by our QA team internally.

The drama and reputational damage that LTT caused was unnecessary. Especially given that they uploaded this video a week later, and never attempted to reach out. They still have yet to properly edit the video.

1. Yes
2. That depends on those other distributions willingness to package it for their distributions.

The compositor and its applications have been developed bottom up with a full Rust stack, so stability hasn't been a concern. We spend very little time debugging since the logic usually works if it compiles.

There's only a handful of applications slated for the first release, and they're almost finished. Besides core applications, we need only develop a couple additional settings pages to be ready for release, and integrate COSMIC versions of the remaining desktop portals. Altogether, that's really not that much compared to all the work in the last two years.

Besides feature development, the main focus will be ironing out theming issues in the toolkit to adhere to our design files, and writing documentation for developers interested in building apps for cosmic. As well as the necessary work to enable a smooth upgrade from Pop 22.04 to 24.04.

They are not "resold". The laptops are custom-ordered and manufactured in Taiwan. The same as virtually every computer you buy. Taiwan would be very unhappy to see comments claiming they're Chinese.

You are misunderstanding the data. It is not the number of users, but a percent of posts to ProtonDB, which only applies to PC gamers. There can be a disproportionately larger number of reports from those who need to spend time tweaking their system as opposed to using it, or that are particularly vocal about sharing their tweaks.

The total number of users playing games on Linux is rising each year. Pop!_OS was the first OS that a lot of people tried a few years ago, and so you'll see a lot more diversity in choice now. People who are new to Linux, yet particularly heavily invested in it, tend to like to try out a lot of different distributions in the following years.

The desktop environment doesn't control how applications look or function. Regarding theming, GTK3 applications need a GTK3 theme, GTK4 applications need a GTK4 theme, libadwaita applications need a libadwaita theme, and KDE applications need a KDE theme. Our tooling for generating themes will attempt to generate themes for other toolkits, but COSMIC applications have a different design language than GNOME or KDE applications.

The toolkit decides how their applications look based on whatever theming engines they use. The desktop doesn't have control over that. So GTK applications use GTK themes, libadwaita applications use libadwaita themes, libcosmic applications will use libcosmic themes. We'll try to automatically generate similar-ish GTK/KDE/etc. themes if possible, but it'll depend by what specs those toollkits support in their theming.

Our internal testing won't begin until the first ISO is ready, which marks the alpha. As it is open source, our internal testing is also publicly available to everyone interested in downloading the ISO and testing it. The Alpha will not include all features that are planned for release. Then we will switch to Beta after all featues are implemented, where QA will begin reviewing every PR to ensure that no regressions make it to release. Then it releases after we deem the beta free of oustanding issues on the board.

That's already happening

For the past two years, I have also been the lead developer of AccessKit

When COSMIC development was officially announced, we mentioned that we would be using AccessKit for accessibility support. While certain people in GNOME were spreading concern and doubts about COSMIC supporting accessibility, work was already underway to integrate AccessKit into COSMIC, successfully.

Pop!_OS is "Snapless". Our Firefox builds come directly from Mozilla in the deb format.

If they support the wlr output configuration protocols, then yes it'll work fine. There are some more advanced features that we want that aren't supported by the protocol though, so we will likely develop some cosmic protocol extensions for those features.

It should be noted that COSMIC itself hasn't been delayed. Development on the core applications progressed much faster than expected, so we decided to skip the Alpha 1 release and release Alpha 2 instead.

Why wouldn't you like using it right now? I wouldn't call it "very alpha".

Not sure how that would be the fault of customer service. There were a lot of component shortages during the pandemic. Suppliers often discontinued components in the middle of production because they couldn't source the chips required. Batteries also require chips to control their charging thresholds and voltages.

It's not stable in the Debian sense. We've always had rolling release updates for the system base; and people often complain about regressions in Linux, Pipewire, Mesa, and NVIDIA updates. I get them packaged shortly after they're released. As long as they pass QA tests in the System76 hardware lab, they get released within a week.

I assume you meant Pop!_OS instead of COSMIC. Pop!_OS 24.04 will be based on Ubuntu 24.04.

Yes, the libcosmic toolkit automates a decent chunk of the process to building an application with our interface guidelines. If building an application with the cosmic::Application trait. Which includes the header bar, navigation bar, and context drawer.

Make sure you have the latest firmware for your motherboard. This sounds like unstable voltages for memory, or an overly-aggressive PBO curve. Did you try disabling the XMP profile on the RAM, disabling PBO, and upping the voltages (within safe limits) of the SOC, DDR, and VDDP? You might find some useful info here[0] or here[1] if you intend to run your memory at 3200 MHz.

• [0] https://github.com/integralfx/MemTestHelper/blob/oc-guide/DDR4%20OC%20Guide.md#amd
• [1] https://www.techpowerup.com/review/amd-ryzen-memory-tweaking-overclocking-guide/2.html

Since around June/July.

Iced is a lower level GUI library, similar to what GDK is to GTK. We built our own COSMIC-themed GUI toolkit around iced, which is called libcosmic. As we've gotten more and more widgets and application logic developed, actual application development with libcosmic is a breeze. Even if you do have to create a custom widget, it's much easier to creating custom widgets in GTK. We're able to develop much faster than we ever could with GTK now.

Yew and Leptos aren't comparable since they're not native GUI toolkits. These are for web developers rather than application development. It wouldn't be possible to use this for developing layer shell applets for COSMIC, either.

We have been developing our own toolkit, libcosmic, which is being used for everything. From the lock screen, compositor, applets for the desktop, and the applications themselves. There is an examples directory for third party developers to learn hope to build their own applets and applications with.

Yes, you can do anything with COSMIC's dock and panel. No extensions needed. If an applet exists on the system, you can embed it into your panel or dock.

There are new versions released every two or three weeks. I'm about to release Linux 6.6.8 with Mesa 23.3.2. We have Pipewire 1.0.0 and NVIDIA 545. ISOs are regularly rebuilt with our latest updates.

I hope to see Linux brought to the Web 2.0 era with proper use of Git forges. As it is, most people won't bother to go through the existing processes unless they're paid to do it. Raising the barrier to entry in order to discourage low quality submissions is a poor excuse. The existing system makes it difficult to get any changes approved or reviewed with a serious eye, regardless of their quality.

There's a very large gap between having tiling, and having excellent auto-tiling capabilities with intuitive shortcuts and behaviors. COSMIC's autotiling was designed from the ground up to be just as usable with a mouse as it is with a keyboard.

It already supports VRR and DRM leasing. VRR monitors and VR headsets have been tested.

PRs to cosmic-panel and libcosmic are welcome