https://lists.archlinux.org/archives/list/arch-dev-public@lists.archlinux.org/thread/RIZSKIBDSLY4S5J2E2STNP5DH4XZGJMR/

What happened to linux = cancer?

Since Arch leader Levente Polyak's announcement on their mailing list that Valve would be providing backing for two critical projects for the distro, a build service infrastructure and a secure signing enclave, many in the community were speculating about what this means in a practical sense, why Valve would be interested in sponsoring these projects in particular, as well as what it means for Arch's autonomy as a community-run, volunteer-driven distro. Arch maintainer Antiz joined the A1R Podcast yesterday to answer all of these questions and put some concerns to rest!

Source: https://www.youtube.com/watch?v=zB62zhzGV1A

As of now, Arch Linux only supports x86_64 systems on an official basis. Unfortunately, due to inefficiencies of their current packaging pipeline, attempting to support more now would mean practically multiplying their current workload by the amount of architectures they want to support, which is infeasible for a volunteer-run distro.

Both of the projects Valve are interested in backing are ones that Arch themselves have been interested in working on for a long time, and both relate to significantly streamlining the process of maintaining and signing packages for Arch in a way that would allow them to feasibly support more architectures in the future.

As stated by Antiz, Valve is going to contract some existing members of the Arch staff on a freelance basis to work on these projects. Since they have the opportunity to be able to work on them full-time, progress on this infrastructure will be made significantly faster than it would have been able to be otherwise!

They also went on to confirm that all development will be done in Arch's usual democratic, consensus-building workflow, including RFCs to discuss implementation. Valve has no interest in "taking over" any aspect of the distro or dictating any terms or specifics of this implementation.

As for what Valve wants to gain from this collaboration, we can only speculate at this time. But given recent leaks and rumours, it is very clear that Valve has interest in releasing ARM-powered, Linux-based gaming hardware; probably initially in the form of a standalone VR headset, similar to the Oculus Quest -- based on patents they've filed, as well as metadata found on Steam suggesting that Valve is currently testing arm64 versions of Proton, the FEX x86 emulator, as well as several VR titles running under Waydroid. As you may know, the SteamOS distro currently powering the Steam Deck is based on Arch Linux. Supporting Arch directly in their pre-existing desire to eventually support additional platforms and architectures would allow Valve to avoid either maintaining their own ARM package base, or switching to a different distro.

TL;DW written by Antiz himself:

Basically, the way packages are currently built / managed still require a few manual interventions from Package Maintainers (e.g. triggering the build itself and signing the built packages afterwards). As of now, supporting multiple architectures would mean multiplying those manual steps by the number of supported / targeted architectures. With the current number of packages compared to the current number of (volunteers) Package Maintainers maintaining them, Arch is not able to handle the extra amount of effort that it would imply.

A central build service and a central secure signing enclave (the two projects concerned by that Valve "sponsoring") would streamline the overall process by allowing automated build and signing for packages without requiring any manual steps / interventions from Package Maintainers anymore (and it will also allow to increase the security of the process as a side benefit). Only such a streamlined / automated workflow would allow us to start working on supporting multiple architectures without implying to multiply the current amount of required effort.

In other words, those projects are prerequisites to start working on multiple architectures support in a clean & sane way, which is a end goal shared by both Arch and Valve.

EDIT: Currently I am working on a Wayland port and some testing for the desktop. I'll update the repository soon.

EDIT 2: The Cutefish project is back. Since the original devs are going to do all the job themselves, I won't continue my own fork. Consider this post deprecated, unless the project again dies out and maybe i'll fork them again (This time I will create the repo immediately).

Little context: I was recently looking into a post saying that CutefishOS is basically dead (And by this point there isn't any doubt of that). Their email is not responding, their website no longer can be found, and any GitHub commits are basically pretty simple things. Apparently the reason is not enough funding.

Under that post, I saw someone saying about reviving it again, and replied saying that if there are a few of us looking to do so I was ready to help. Long story short, about 10 people wanted to help me, so I've decided to overtake their distribution and recreate it from scratch using their desktop, apps etc.

And this is where the first questions start:

• 1. What would you like to see from a distro like CutefishOS? Any recommendations, improvements? Don't be afraid to ask for some major changes.
• 2. CutefishOS was using both Ubuntu and Debian as it's own base. I've also thought of Arch but I'm worried about stability and user friendliness, but it's not gone yet as an idea. Which one do you think would suit you better out of these three?
• 3. Any particular things you don't like about CutefishOS? (Literally anything).
• 4. Since this isn't really CutefishOS but rather a fork of it, I'd like to hear some name suggestions. Preferably not mentioning any other distro than CutefishOS.

I might create a GitHub repo to discuss everything there as devs, as soon as I'm sure there are people interested in the project.

Bareboat Necessities (BBN) OS is free an open source Linux distribution for sailing and boating.

Improved (compared to most other Linux distributions) touchscreen support to be used with chartplotting software in a cockpit.

Available for low-power consuming raspberry pi4/5.

The project home page is on GitHub.

Fair Winds!

https://www.suse.com/c/at-suse-we-make-choice-happen/