You don’t have to watch. You can listen to it in the background.

It’s really easy to configure a self-hosted forgejo instance. Even if you rm your local work, you can clone it from your server. Be that hosted on the same system over localhost, or on another system in your network.

No modifications are being done to Qt/KDE theming, and we won’t be able to get KDE apps to adapt to the COSMIC theme until the KDE ecosystem has finished migrations to the Union theme engine.

I don’t know how you can keep telling me that I never contacted Canonical even though I did. Nor did anyone ever publicly mock Canonical. You are putting words in our mouths. So much contradictory and hyperbolic nonsense here. Let me guess: you read a certain hyperbolic hit piece from a Chris Davis—one of the most prominent libadwaita and stopthemingmyapp developers—whom had a personal axe to grind with us because of many heated online arguments with him over the petition, theming, and libadwaita. He created a hit piece to influence public perception of the company and intentionally used the GNOME blog to reach the widest audience for his vendetta. Even though if you dig through the details his statements are weak, if not outright false. To make matters worse, GNOME never addressed that personal blog post hosted on their website, even though we had been sponsoring and sometimes hosting GNOME events for 5 years prior, and donated a total of $100K. Leading many to conclude that this was the voice of GNOME, even if internally it was not. This is what happens if you only read the story from one side without putting equal weight on the other.

The alpha began in August of last year, and will continue to be classified as alpha until all features are finished.

Your link demonstrates the exact opposite. GNOME rejected a patch for disabling mouse acceleration profiles, and I then ported that patch to Pop!_OS. It was often the case that I merged third party patches into Pop!_OS that were either rejected by GNOME, or were in an actively-open PR. In all instances where contributions could be upstreamed that we worked on personally, pull requests were given to the appropriate projects. And it is the case that many such instances were merged into GNOME, such as the keyboard settings page redesign. Our team has submitted many contributions to GTK, GNOME, and other projects over the years, so to smear us for not contributing upstream is incredibly deceitful.

Issues with youtube-dl being outdated are constantly reported on Launchpad, and are still an issue to this day because YouTube keeps changing the API. It was reported at that time as well. In fact, I have submitted several patches upstream to Ubuntu through Launchpad over the years, but unfortunately they typically go straight into limbo because developers rarely notice them, and it’s difficult to get their attention. It’s usually better to go straight to the upstream developer to get those changes merged there, and therefore the issue will be fixed in the next release of Ubuntu when they package the updated software. If Canonical is interested in any of the work we have done in Pop!_OS, they are also free to take from our GitHub repositories. It’s all open source, after all.

It speaks to me that you have certain intentions and motivations in your speech to paper over the good we’ve done over the years to focus on small nit picks. Nitpicking an obscure debian changelog that no one reads and was never presented to the user is a very poor argument. I was frustrated at the time because youtube-dl kept breaking and we kept getting issue reports on it. I was unable to get any response from Canonical, so I fixed it myself in Pop. I haven’t written anything in the debian changelog fields since then.

This is the actual truth of the matter. COSMIC is the result of many years of planning and developments in response to customer requests in Pop!_OS. Over time, the COSMIC extensions for GNOME diverged in UX to the point where it was untenable to maintain long-term, and impossible to make further progress without forking. We were going to create a modern desktop environment in Rust from the ground up regardless of whether disputes happened with GNOME Foundation / Core members, even if disagreements helped to accelerate that goal.

Today we have built a highly modular desktop environment in Rust from the ground up that anyone can use as a platform for building an operating system with thanks to the flexibility of the Wayland layer-shell protocol. You may mix and match any arrangement of layer-shell applets in any order. You can even swap out the cosmic session for a different desktop environment’s session, and vice versa load another desktop environment’s session inside of cosmic-comp.

Distribution and user theming is also significantly improved over GTK with programmatic generation of themes—automatically adapting colors at runtime to the most ideal contrasting color values via OKLCH and other related algorithms—which distributions can use to customize to their preferred branding, and app developers can freely adopt without needing to worry about user themes breaking their apps. Users also get the convenience of generating their own custom themes with COSMIC Settings, even if that means creating an abomination of conflicting colors.

We really wanted to improve upon the developer UX for Rust GUIs by creating libcosmic, and have succeeding in doing so with a toolkit based on Iced that uses Elm’s Model-View-Update paradigm. It is so much easier to build apps and applets with libcosmic compared to gtk4-rs. I have a lot of testimonials from developers who have built apps and applets with it. Some of which have also contributed a lot to cosmic and libcosmic, even if they had little or no Rust/programming experience previously.

Also, while it may be alpha, it is very usable. It is only in alpha so long as all features aren’t implemented yet. You may have to supplement a GNOME app here or there. Some bugs are also expected, but it works great otherwise. In many ways better than the 22.04 environment currently offered.

That’s honestly a very revisionist version of history. Unfortunately I’m too tired to do a proper rebuttal to it. We have made many upstream contributions to GNOME. There has never been an instance of refusal to upstream anything. There has been instances of upstream not being interested in our contributions though. But that’s how things go when you have creative differences with an upstream, or have technical contributions which aren’t of interest to upstream’s use cases. Keep in mind that just because a downstream makes something cool and interesting, it doesn’t automatically mean that creation fits in with upstream’s vision for their project. Hence why there’s hundreds of gnome-shell extensions that aren’t built into GNOME.

There is a whole team working on COSMIC. Paid, full-time developers, UX designers, and a QA team.

Give it a try. We are close to being finished. I don’t even know why anyone would think this isn’t a thing.

Alpha 5 is actually releasing next week. I’d also disagree with “very alpha” as most of the beta milestone is finished now. Regardless, I don’t understand where the disconnect is. A spin can release at any time. Doesn’t matter when COSMIC Epoch 1 releases.

That would be completely wrong. See the Fedora Miracle Spin, for example. The project (miracle-wm) is still a work in progress, and yet Fedora already officially offers a Spin for it. What you’re describing would only be true if Fedora was switching to COSMIC as the official desktop for Fedora.

There would be no reason to delay anything regardless of it being beta or not. Fedora is always doing rolling release updates of software that lends well to that paradigm, and COSMIC is one of those. It’s not like GNOME or KDE where you have to carefully and meticulously manage 100 system libraries used by the whole ecosystem. System dependencies in the COSMIC ecosystem are virtually non-existent. If they really wanted to, they could just wait a few weeks to release the spin. But I don’t think there’s any reason to.

In practice, because Rust libraries are always statically-linked, the MPL-2.0 is equivalent to the LGPL in spirit. Meanwhile, because of the static linking restrictions in the LGPL, the LGPL is effectively no different from the GPL. Hence, you’re going to find a lot of open source copyleft projects from the Rust ecosystem preferring either GPL or MPL-2.0, where MPL-2.0 is used in libraries where LGPL would have used previously in C projects. Dynamic linking is essentially going the way of the Dodo.

The Linux kernel already allows proprietary modules via DKMS, and a handful of vendors have been using this for decades, so this is no different. Case in point: NVIDIA driver, and Android vendor drivers.

All source code in Rust is statically-linked when compiled, which thereby renders the LGPL no different from the GPL in practice. For Rust, the MPL-2.0 is a better license because it does not have the linking restriction.

I’d recommend spending some time reading about it. It’s not as hard as he thinks. Applications developed for Linux are quite easy to port to Redox. It supports many of the same system calls and has a compatible libc implementation. The kernel does have abstractions to ease the porting process. And if you’re going to make a new kernel today, you should do it right and make a microkernel like Redox. One of the benefits of having a microkernel is that it doesn’t matter what language you write drivers in. They’re isolated to their own processes. Rust, C, C++, whatever.

It does work like this, but as with justice, the wheels can be slow at times.

What report are you referring to?

What GPU configuration do you have? I don’t have any of these issues. If NVIDIA, you have to wait for NVIDIA to release explicit sync Wayland drivers.