"There's no shortage of videos showing Steam running on expensive ARM single-board computers with discrete GPUs," writes Slashdot reader VennStone. "So I thought it would be worthwhile to make a guide for doing it on (relatively) inexpensive RK3588-powered single-board computers, using Box86/64 and Armbian." The guides I came across were out of date, had a bunch of extra steps thrown in, or were outright incorrect... Up first, we need to add the Box86 and Box64 ARM repositories [along with dependencies, ARMHF architecture, and the Mesa graphics driver]...
The guide closes with a multi-line script and advice to "Just close your eyes and run this. It's not pretty, but it will download the Steam Debian package, extract the needed bits, and set up a launch script." (And then the final step is sudo reboot now.)

"At this point, all you have to do is open a terminal, type 'steam', and tap Enter. You'll have about five minutes to wait... Check out the video to see how some of the tested games perform." At 720p, performance is all over the place, but the games I tested typically managed to stay above 30 FPS. This is better than I was expecting from a four-year-old SOC emulating x86 titles under ARM.

Is this a practical way to play your Steam games? Nope, not even a little bit. For now, this is merely an exercise in ludicrous neatness. Things might get a wee bit better, considering Collabora is working on upstream support for RK3588 and Valve is up to something ARM-related, but ya know, "Valve Time"...
"You might be tempted to enable Steam Play for your Windows games, but don't waste your time. I mean, you can try, but it ain't gonna work."

With Microsoft ending free security updates for Windows 10 in October, millions of PCs that don't meet Windows 11's hardware requirements face an uncertain fate... Charities that refurbish and distribute computers to low-income individuals must choose between providing soon-to-be-insecure Windows 10 machines, transitioning to Linux -- despite usability challenges for non-tech-savvy users -- or recycling the hardware, contributing to ewaste. Tom's Hardware reports: So how bad will it really be to run an end-of-lifed Windows 10? Should people worry? [Chester Wisniewski, who serves as Director and Global Field CISO for Sophos, a major security services company] and other experts I talked to are unequivocal. You're at risk. "To put this in perspective, today [the day we talked] was Patch Tuesday," he said. "There were 57 vulnerabilities, 6 of which have already been abused by criminals before the fixes were available. There were also 57 in February and 159 in January. Windows 10 and Windows 11 largely have a shared codebase, meaning most, if not all, vulnerabilities each month are exploitable on both OSs. These will be actively turned into digital weapons by criminals and nation-states alike and Windows 10 users will be somewhat defenseless against them."

So, in short, even though Windows 10 has been around since 2015, there are still massive security holes being patched. Even within the past few weeks, dozens of vulnerabilities were fixed by Microsoft. So what's a charity to do when these updates are running out and clients will be left vulnerable? "What we decided to do is one year ahead of the cutoff, we discontinued Windows 10," said Casey Sorensen, CEO of PCs for People, one of the U.S.'s largest non-profit computer refurbishers. "We will distribute Linux laptops that are 6th or 7th gen. If we distribute a Windows laptop, it will be 8th gen or newer." Sorensen said that any PC that's fifth gen or older will be sent to an ewaste recycler.

[...] Sorensen, who founded the company in 1998, told us that he's comfortable giving clients computers that run Linux Mint, a free OS that's based on Ubuntu. The latest version of Mint, version 22.1, will be supported until 2029. "Ten years ago if we distributed Linux, they would be like what is it," he said. But today, he notes that many view their computers as windows to the Internet and, for that, a user-friendly version of Linux is acceptable. Further reading: Is 2025 the Year of the Linux Desktop?

Axiom Space and Red Hat will collaborate to launch Data Center Unit-1 (AxDCU-1) to the International Space Station this spring. It's a small data processing prototype (powered by lightweight, edge-optimized Red Hat Device Edge) that will demonstrate initial Orbital Data Center (ODC) capabilities.

"It all sounds rather grand for something that resembles a glorified shoebox," reports the Register. Axiom Space said: "The prototype will test applications in cloud computing, artificial intelligence, and machine learning (AI/ML), data fusion and space cybersecurity."

Space is an ideal environment for edge devices. Connectivity to datacenters on Earth is severely constrained, so the more processing that can be done before data is transmitted to a terrestrial receiving station, the better. Tony James, chief architect, Science and Space at Red Hat, said: "Off-planet data processing is the next frontier, and edge computing is a crucial component. With Red Hat Device Edge and in collaboration with Axiom Space, Earth-based mission partners will have the capabilities necessary to make real-time decisions in space with greater reliability and consistency...."

The Red Hat Device Edge software used by Axiom's device combines Red Hat Enterprise Linux, the Red Hat Ansible Platform, and MicroShift, a lightweight Kubernetes container orchestration service derived from Red Hat OpenShift. The plan is for Axiom Space to host hybrid cloud applications and cloud-native workloads on-orbit. Jason Aspiotis, global director of in-space data and security, Axiom Space, told The Register that the hardware itself is a commercial off-the-shelf unit designed for operation in harsh environments... "AxDCU-1 will have the ability to be controlled and utilized either via ground-to-space or space-to-space communications links. Our current plans are to maintain this device on the ISS. We plan to utilize this asset for at least two years."
The article notes that HPE has also "sent up a succession of Spaceborne computers — commercial, off-the-shelf supercomputers — over the years to test storage, recovery, and operational potential on long-duration missions." (They apparently use Red Hat Enterprise Linux.) "At the other end of the scale, the European Space Agency has run Raspberry Pi computers on the ISS for years as part of the AstroPi educational outreach program."

Axiom Space says their Orbital Data Center is deigned to "reduce delays traditionally associated with orbital data processing and analysis." By utilizing Earth-independent cloud storage and edge processing infrastructure, Axiom Space ODCs will enable data to be processed closer to its source, spacecraft or satellites, bypassing the need for terrestrial-based data centers. This architecture alleviates reliance on costly, slow, intermittent or contested network connections, creating more secure and quicker decision-making in space.

The goal is to allow Axiom Space and its partners to have access to real-time processing capabilities, laying the foundation for increased reliability and improved space cybersecurity with extensive applications. Use cases for ODCs include but are not limited to supporting Earth observation satellites with in-space and lower latency data storage and processing, AI/ML training on-orbit, multi-factor authentication and cyber intrusion detection and response, supervised autonomy, in-situ space weather analytics and off-planet backup & disaster recovery for critical infrastructure on Earth.

Google has introduced a Debian Linux terminal app for Android in its ongoing effort to transform Android into a versatile desktop OS. It's initially available on Pixel devices running Android 15 but will be expanded to "all sufficiently robust Android phones" when Android 16 arrives later this year," writes ZDNet's Steven Vaughan-Nichols. An anonymous reader shares an excerpt from the report: Today, Linux is only available on the latest Pixel devices running Android 15. When Android 16 arrives later this year, it's expected that all sufficiently robust Android phones will be able to run Linux. Besides a Linux terminal, beta tests have already shown that you should be able to run desktop Linux programs from your phone -- games like Doom, for example. The Linux Terminal runs on top of a Debian Linux virtual machine. This enables you to access a shell interface directly on your Android device. And that just scratches the surface of Google's Linux Terminal. It's actually a do-it-all app that enables you to download, configure, and run Debian. Underneath Terminal runs the Android Virtualization Framework (AVF). These are the APIs that enable Android devices to run other operating systems.

To try the Linux Terminal app, you must activate Developer Mode by navigating to Settings - About Phone and tapping the build number seven times. I guess Google wants to make sure you want to do this. Once Developer Mode is enabled, the app can be activated via Settings - System - Developer options - Linux development environment. The initial setup may take a while because it needs to download Debian. Typically this is a 500MB download. Once in place, it allows you to adjust disk space allocation, set port controls for network communication, and recover the virtual machine's storage partition. However, it currently lacks support for graphical user interface (GUI) applications. For that, we'll need to wait for Android 16.

According to Android specialist Mishaal Rahman, 'Google wants to turn Android into a proper desktop operating system, and in order to do that, it has to make it work better with traditional PC input methods and display options. Therefore, Google is now testing new external display management tools in Android 16 that bring Android closer to other desktop OSes.'

An anonymous reader quotes a report from 9to5Linux: Mozilla published today the final build of the Firefox 136 open-source web browser for all supported platforms ahead of the March 4th, 2025, official release date, so it's time to take a look at the new features and changes. Highlights of Firefox 136 include official Linux binary packages for the AArch64 (ARM64) architecture, hardware video decoding for AMD GPUs on Linux systems, a new HTTPS-First behavior for upgrading page loads to HTTPS, and Smartblock Embeds for selectively unblocking certain social media embeds blocked in the ETP Strict and Private Browsing modes.

Firefox 136 is available for download for 32-bit, 64-bit, and AArch64 (ARM64) Linux systems right now from Mozilla's FTP server. As mentioned before, Mozilla plans to officially release Firefox 136 tomorrow, March 4th, 2025, when it will roll out as an OTA (Over-the-Air) update to macOS and Windows users. Here's a list of the general features available in this release:

- Vertical Tabs Layout
- New Browser Layout Section
- PNG Copy Support
- HTTPS-First Behavior
- Smartblock Embeds
- Solo AI Link
- Expanded Data Collection & Use Settings
- Weather Forecast on New Tab Page
- Address Autofill Expansion

A full list of changes can be found here.

What's Linux's marketshare on Steam? The Steam Survey numbers tell this story:

11/24: 2.03%
12/24: 2.29%
01/25: 2.06%
02:25: 1.45%

"The February numbers show a staggering 0.61% drop to Linux use..." reports Phoronix. But they attribute this to an sampling error: According to the survey, it shows 50% of Steam users using the Simplified Chinese language pack [a 20% increase from the month before]. In prior months where there has been drops to Linux use, it's been correlated to wild swings in the Chinese use on Steam. This looks to be another such month.

Of the Linux specific data, SteamOS continues to prove most popular for that Valve distribution powering the Steam Deck [at 34.67%, with Arch Linux coming in second at 9.7%].

AMD CPUs power around 70% of the Linux gaming systems thanks to the Steam Deck APU and AMD Ryzen being quite popular with Linux enthusiasts.

When it comes to application packaging, earlier this month the site Its FOSS complained that Fedora Flatpaks "are often unmaintained or broken, leading to a poor experience for users who aren't usually aware they're using them." And this apparently created friction with OBS Studio, the free/open-source screencasting and streaming app.

"We are now considering the Fedora Flatpaks distribution of OBS Studio a hostile fork," OBS Studio lead Joel Bethke posted in on GitLab's page for Fedora Flatpaks. They said they were making "a formal request to remove all of our branding, including but not limited to, our name, our logo, any additional IP belonging to the OBS Project, from your distribution. Failure to comply may result in further legal action taken...." (Issues with Fedora's packaging led "to users complaining upstream thinking they are being served the official package..." Bethke said in his original Issue. "I would also like some sort of explanation on why someone thought it was a good idea to take a Flatpak that was working perfectly fine, break it, and publish it at a higher priority to our official builds.")

23 people clicked "Like" on the original Issue — but threatening legal action only happened after Bethke felt Fedora was unresponsive, according to It's FOSS: In a comment on a video by Brodi Robertson (check pinned comment), Joel shared that folks from Fedora were not taking this issue seriously, with one of them even resorting to name-calling by labeling the OBS Studio devs as being "terrible maintainers". Since then, a major step has been taken by Neal Gompa, a well-known Fedora contributor and member of the Fedora Engineering Steering Committee (FESCo). He has opened a new issue to remove Fedora's OBS Studio flatpak from the registry as soon as possible.
But by Tuesday Bethke posted in a new comment on GitLab announcing that "a very good conversation" with the Flatpak SIG and Fedora Project Leader seemed to have cleared the tension. "We discussed the issues, how we got here, and what next steps are... [T]he OBS Project is no longer requesting a removal of IP or rebrand of the OBS Studio application provided by Fedora Flatpaks." To the issue of not knowing where to report bugs for the downstream package, "We had some very good discussion on how this might be accomplished in the medium-long term, but don't consider it a blocker at this point." As for other issues with Fedora's Flatpak for OBS Studio, "The discussion was positive and they are actively working to resolve..."

And similar sentiments were echoed on Fedora's own issue tracker. "We had a good conversation today, and there is a hopeful path forward that does not require the OBS Project distancing itself from Fedora Flatpaks..."

An anonymous Slashdot reader shared this report from Phoronix: Linux's second-in-command Greg Kroah-Hartman has also been a big proponent of Rust kernel code. He's crafted another Linux kernel mailing list post [Wednesdsay] outlining the benefits of Rust and encouraging new kernel code/drivers to be in Rust rather than C. Greg KH makes the case that the majority of the kernel bugs are due to "stupid little corner cases in C that are totally gone in Rust."
"As someone who has seen almost EVERY kernel bugfix and security issue for the past 15+ years... and who sees EVERY kernel CVE issued, I think I can speak on this topic," Kroah-Hartman began. Here's some excerpts from his remarks. Citing corner cases like overwrites of memory, error path cleanups, use-after-free mistakes and forgetting to check error values, Kroah-Hartman says he's "all for... making these types of problems impossible to hit." That's why I'm wanting to see Rust get into the kernel, these types of issues just go away, allowing developers and maintainers more time to focus on the REAL bugs that happen (i.e. logic issues, race conditions, etc.)... [F]or new code / drivers, writing them in Rust where these types of bugs just can't happen (or happen much much less) is a win for all of us, why wouldn't we do this...? Rust isn't a "silver bullet" that will solve all of our problems, but it sure will help in a huge number of places, so for new stuff going forward, why wouldn't we want that...?

Yes, mixed language codebases are rough, and hard to maintain, but we are kernel developers dammit, we've been maintaining and strengthening Linux for longer than anyone ever thought was going to be possible. We've turned our development model into a well-oiled engineering marvel creating something that no one else has ever been able to accomplish. Adding another language really shouldn't be a problem, we've handled much worse things in the past and we shouldn't give up now on wanting to ensure that our project succeeds for the next 20+ years. We've got to keep pushing forward when confronted with new good ideas, and embrace the people offering to join us in actually doing the work to help make sure that we all succeed together.
Kroah-Hartman emphasized later that "a huge majority of the stupid things we do in C just don't happen in the same code implemented in Rust (i.e. memory leaks, error path cleanups, return value checking, etc.) "

The complete thread contains over 140 messages — including Linus Torvalds' observation that " #pragma is complete garbage and should never be used."

Linus Torvalds responded Thursday to kernel developer Christoph Hellwig, who had claimed Torvalds merged Rust code into the kernel even over his objections as the original C code's maintainer. Highlights from Torvalds' response: The fact is, the pull request you objected to DID NOT TOUCH THE DMA LAYER AT ALL. It was literally just another user of it, in a completely separate subdirectory, that didn't change the code you maintain in _any_ way, shape, or form... Honestly, what you have been doing is basically saying "as a DMA maintainer I control what the DMA code is used for".

And that is not how *any* of this works. What's next? Saying that particular drivers can't do DMA, because you don't like that device, and as a DMA maintainer you control who can use the DMA code? That's _literally_ exactly what you are trying to do with the Rust code. You are saying that you disagree with Rust — which is fine, nobody has ever required you to write or read Rust code. But then you take that stance to mean that the Rust code cannot even use or interface to code you maintain...

You don't have to like Rust. You don't have to care about it. That's been made clear pretty much from the very beginning, that nobody is forced to suddenly have to learn a new language, and that people who want to work purely on the C side can very much continue to do so. So to get back to the very core of your statement:

"The document claims no subsystem is forced to take Rust"

that is very much true. You are not forced to take any Rust code, or care about any Rust code in the DMA code. You can ignore it...

You can't have it both ways. You can't say "I want to have nothing to do with Rust", and then in the very next sentence say "And that means that the Rust code that I will ignore cannot use the C interfaces I maintain".... So when you change the C interfaces, the Rust people will have to deal with the fallout, and will have to fix the Rust bindings. That's kind of the promise here: there's that "wall of protection" around C developers that don't want to deal with Rust issues in the promise that they don't *have* to deal with Rust.

But that "wall of protection" basically goes both ways. If you don't want to deal with the Rust code, you get no *say* on the Rust code. Put another way: the "nobody is forced to deal with Rust" does not imply "everybody is allowed to veto any Rust code".
Torvalds also made sure to add some kind remarks, including "I respect you technically, and I like working with you."

Christoph Hellwig continues to voice strong opposition to Rust in the Linux kernel, arguing that its introduction creates fragmentation, unclear language guidelines, and additional burdens on maintainers. He also says Linus Torvalds has privately stated he will override objections to Rust code, effectively making its adoption inevitable. Phoronix's Michael Larabel has the latest: The latest on Hellwig's perspective of Rust code within the Linux kernel is below. Some interesting insight from a dissenting view. The thread in full can be found on the Rust for Linux mailing list.

[Here's an excerpt from the thread:] "I don't think having a web page in any form is useful. If you want it to be valid it has to be in the kernel tree and widely agreed on. It also states factually incorrect information. E.g. 'Some subsystems may decide they do not want to have Rust code for the time being, typically for bandwidth reasons. This is fine and expected.' while Linus in private said that he absolutely is going to merge Rust code over a maintainers objection. (He did so in private in case you are looking for a reference). So as of now, as a Linux developer or maintainer you must deal with Rust if you want to or not. [...] Right now the rules is Linus can force you whatever he wants (it's his project obviously) and I think he needs to spell that out including the expectations for contributors very clearly."
Inevitably there was a response... Torvalds: Rust Kernel Code Isn't Forced In Over Maintainers' Objections.

PAjamian writes: Two years ago Red Hat announced an end to its public source code availability. This caused a great deal of outcry from the Enterprise Linux community at large. Since then many have waited for a statement from the Free Software Foundation concerning their stance on the matter. Now, nearly two years later the FSF has finally responded to questions regarding their stance on the issue with the following statement:

When asked if the FSF would be willing to intervene on behalf of the community they had this to say:

Following is the full text of my original email to them and their response:

Subject: Statement about recent changes in source code distribution for Red Hat Enterprise Linux
Date: 2023-07-16 00:39:51

> Hi,
>
> I'm a user of Red Hat Enterprise Linux, Rocky Linux and other Linux
> distributions in the RHEL ecosystem. I am also involved in the EL
> (Enterprise Linux) community which is being affected by the statements
> and changes in policy made by Red Hat at
> https://www.redhat.com/en/blog/furthering-evolution-centos-stream and
> https://www.redhat.com/en/blog/red-hats-commitment-open-source-
> response-gitcentosorg-changes
> (note there are many many more links and posts about this issue which
> I
> believe you are likely already aware of). While a few of these
> questions are answered more directly by the license FAQ some of them
> are
> not and there are a not insignificant number of people who would very
> much appreciate a public statement from the FSF that answers these
> questions directly.
>
> Can you please comment or release a statement about the Free Software
> Foundation's position on this issue? Specifically:
>

Thank you for writing in with your questions. My apologies for the delay, but we are a small team with limited resources and can be challenging keeping up with all the emails we receive.

Generally, we don't agree with what Red Hat is doing. Whether it constitutes a violation of the GPL would require legal analysis and the FSF does not give legal advice. However, as the stewards of the GNU GPL we can speak how it is intended to be applied and Red Hat's approach is certainly contrary to the spirit of the GPL. This is unfortunate, because we would expect such flagship organizations to drive the movement forward.

> Is Red Hat's removal of sources from git.centos.org a violation of the
> GPL and various other Free Software licenses for the various programs
> distributed under RHEL?
>
> Is Red Hat's distribution of source RPMs to their customers under
> their
> subscriber agreement sufficient to satisfy the above mentioned
> licenses?
>
> Is it a violation if Red Hat terminates a subscription early because
> their customer exercised their rights under the GPL and other Free
> Software licenses to redistribute the RHEL sources or create
> derivative
> works from them?
>
> Is it a violation if Red Hat refuses to renew a subscription that has
> expired because a customer exercised their rights to redistribute or
> create derivative works?
>
> A number of the programs distributed with RHEL are copyrighted by the
> FSF, some examples being bash, emacs, GNU core utilities, gcc, gnupg
> and
> glibc. Given that the FSF has standing to act in this matter would
> the
> FSF be willing to intervene on behalf of the community in order to get
> Red Hat to correct any of the above issues?
>

As of today, we are not aware of any issue with Red Hat's new policy that we could pursue on legal grounds. However, if you do find a violation, please [follow these instructions][0] and send a report to <license-violation@gnu.org>.

[0]: https://www.gnu.org/licenses/gpl-violation.html

If you are interested in something more specific on this, the Software Freedom Conservancy [published an article about the RHEL][1] situation and hosted a [panel at their conference in 2023][2]. These cover the situation fairly thoroughly.

[1]: https://sfconservancy.org/blog/2023/jun/23/rhel-gpl-analysis/
[2]: https://sfconservancy.org/blog/2023/jul/19/rhel-panel-fossy-2023/

Hector Martin has resigned as the project lead of Asahi Linux, weeks after stepping down from his role as a Linux kernel maintainer for Apple ARM support. His departure from Asahi follows a contentious exchange with Linus Torvalds over development processes and social media advocacy. After quitting kernel maintenance earlier this month, the conflict escalated when Martin suggested that "shaming on social media" might be necessary to effect change.

Torvalds sharply rejected this approach, stating that "social media brigading just makes me not want to have anything at all to do with your approach" and suggested that Martin himself might be the problem. In his final resignation announcement from Asahi, Martin wrote: "I no longer have any faith left in the kernel development process or community management approach."

The dispute reflects deeper tensions in the Linux kernel community, particularly around the integration of Rust code. It follows the August departure of another key Rust for Linux maintainer, Wedson Almeida Filho from Microsoft. According to Sonatype's research, more than 300,000 open source projects have slowed or halted updates since 2020.

Longtime Slashdot reader BrendaEM writes: Command-line aside, Cinnamon is the most effective keeper of the Linux desktop flame -- by not abandoning desktop and laptop computers. Yes, there are other desktop GUIs, such as MATE, and the lightweight Xfce, which are valuable options when low overhead is important, such as in LinuxCNC. However, among the general public lies a great expanse of office workers who need a full-featured Linux desktop.

The programmers who work on GNOME and its family of supporting applications enrich many other desktops do their more than their share. These faithful developers deserve better user-interface leadership. GNOME has tried to steer itself into tablet waters, which is admirable, but GNOME 3.x diminished the desktop experience for both laptop and desktop users. For instance, the moment you design what should be a graphical user interface with words such as "Activities," you ask people to change horses midstream. That is not to say that the command line and GUI cannot coexist -- because they can, as they do in many CAD programs.

I remember a time when GNOME ruled the Linux desktop -- and I can remember when GNOME left those users behind. Perhaps in a future, GNOME could return to the Linux desktop and join forces with Cinnamon -- so that we may once again have the year of the Linux desktop.

Keynotes at this year's FOSDEM included free AI models and systemd, reports Heise.de — and also a progress report from Miguel Ojeda, supervisor of the Rust integration in the Linux kernel. Only eight people remain in the core team around Rust for Linux... Miguel Ojeda therefore launched a survey among kernel developers, including those outside the Rust community, and presented some of the more important voices in his FOSDEM talk. The overall mood towards Rust remains favorable, especially as Linus Torvalds and Greg Kroah-Hartman are convinced of the necessity of Rust integration. This is less about rapid progress and more about finding new talent for kernel development in the future.
The reaction was mostly positive, judging by Ojeda's slides:

- "2025 will be the year of Rust GPU drivers..." — Daniel Almedia

- "I think the introduction of Rust in the kernel is one of the most exciting development experiments we've seen in a long time." — Andrea Righi

- "[T]he project faces unique challenges. Rust's biggest weakness, as a language, is that relatively few people speak it. Indeed, Rust is not a language for beginners, and systems-level development complicates things even more. That said, the Linux kernel project has historically attracted developers who love challenging software — if there's an open source group willing to put the extra effort for a better OS, it's the kernel devs." — Carlos Bilbao

- "I played a little with [Rust] in user space, and I just absolutely hate the cargo concept... I hate having to pull down other code that I do not trust. At least with shared libraries, I can trust a third party to have done the build and all that... [While Rust should continue to grow in the kernel], if a subset of C becomes as safe as Rust, it may make Rust obsolete..." Steven Rostedt

Rostedt wasn't sure if Rust would attract more kernel contributors, but did venture this opinion. "I feel Rust is more of a language that younger developers want to learn, and C is their dad's language."

But still "contention exists within the kernel development community between those pro-Rust and -C camps," argues The New Stack, citing the latest remarks from kernel maintainer Christoph Hellwig (who had earlier likened the mixing of Rust and C to cancer). Three days later Hellwig reiterated his position again on the Linux kernel mailing list: "Every additional bit that another language creeps in drastically reduces the maintainability of the kernel as an integrated project. The only reason Linux managed to survive so long is by not having internal boundaries, and adding another language completely breaks this. You might not like my answer, but I will do everything I can do to stop this. This is NOT because I hate Rust. While not my favourite language it's definitively one of the best new ones and I encourage people to use it for new projects where it fits. I do not want it anywhere near a huge C code base that I need to maintain."
But the article also notes that Google "has been a staunch supporter of adding Rust to the kernel for Linux running in its Android phones." The use of Rust in the kernel is seen as a way to avoid memory vulnerabilities associated with C and C++ code and to add more stability to the Android OS. "Google's wanting to replace C code with Rust represents a small piece of the kernel but it would have a huge impact since we are talking about billions of phones," Ojeda told me after his talk.

In addition to Google, Rust adoption and enthusiasm for it is increasing as Rust gets more architectural support and as "maintainers become more comfortable with it," Ojeda told me. "Maintainers have already told me that if they could, then they would start writing Rust now," Ojeda said. "If they could drop C, they would do it...."

Amid the controversy, there has been a steady stream of vocal support for Ojeda. Much of his discussion also covered statements given by advocates for Rust in the kernel, ranging from lead developers of the kernel and including Linux creator Linus Torvalds himself to technology leads from Red Hat, Samsung, Google, Microsoft and others.

Asahi lead developer Hector Martin, writing in an email: I no longer have any faith left in the kernel development process or community management approach.

Apple/ARM platform development will continue downstream. If I feel like sending some patches upstream in the future myself for whatever subtree I may, or I may not. Anyone who feels like fighting the upstreaming fight themselves is welcome to do so.
The Register points out that the action follows this interaction with Linux Torvalds.

Hector Martin: If shaming on social media does not work, then tell me what does, because I'm out of ideas.

Linus Torvalds: How about you accept the fact that maybe the problem is you. You think you know better. But the current process works. It has problems, but problems are a fact of life. There is no perfect. However, I will say that the social media brigading just makes me not want to have anything at all to do with your approach. Because if we have issues in the kernel development model, then social media sure as hell isn't the solution.