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."

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.

A heated dispute has erupted in the Linux kernel community over the integration of Rust code, with kernel maintainer Christoph Hellwig likening multiple programming languages to "cancer" for the project's maintainability. The conflict centers on a proposed patch enabling Rust-written device drivers to access the kernel's DMA API, which Hellwig strongly opposed. While the dispute isn't about Rust itself, Hellwig argues that maintaining cross-language codebases severely compromises Linux's integrated nature. From a report: "Don't force me to deal with your shiny language of the day," he [Hellwig] wrote. "Maintaining multi-language projects is a pain I have no interest in dealing with. If you want to use something that's not C, be that assembly or Rust, you write to C interfaces and deal with the impedance mismatch yourself as far as I'm concerned." This resistance follows the September departure of Microsoft engineer Wedson Almeida Filho from the Rust for Linux project, citing "nontechnical nonsense."

Software developer and prolific blogger Herman Ounapuu, writing in a blog post: I liked Ubuntu. For a very long time, it was the sensible default option. Around 2016, I used the Ubuntu GNOME flavor, and after they ditched the Unity desktop environment, GNOME became the default option.

I was really happy with it, both for work and personal computing needs. Estonian ID card software was also officially supported on Ubuntu, which made Ubuntu a good choice for family members.

But then something changed. Ounapuu recounts how Ubuntu's bi-annual long-term support releases consistently broke functionality, from minor interface glitches to catastrophic system failures that left computers unresponsive. His breaking point came after multiple problematic upgrades affecting family members' computers, including one that rendered a laptop completely unusable during an upgrade from Ubuntu 20.04 to 22.04. Another incident left a relative's system with broken Firefox shortcuts and duplicate status bar icons after updating Lubuntu 18.04.

Canonical's aggressive push of Snap packages has drawn particular criticism. The forced migration of system components from traditional Debian packages to Snaps resulted in compatibility issues, broken desktop shortcuts, and government ID card authentication failures. In one instance, he writes, a Snap-related bug in the GNOME desktop environment severely disrupted workplace productivity, requiring multiple system restarts to resolve. The author has since switched to Fedora, praising its implementation of Flatpak as a superior alternative to Snaps.

In his post about the future of Fedora Workstation, Christian F.K. Schaller discusses how the Red Hat team plans to integrate AI with IBM's open-source Granite engine to enhance developer tools, such as IDEs, and create an AI-powered Code Assistant. He says the team is also working on streamlining AI acceleration in Toolbx and ensuring Fedora users have access to tools like RamaLama. From the post: One big item on our list for the year is looking at ways Fedora Workstation can make use of artificial intelligence. Thanks to IBMs Granite effort we know have an AI engine that is available under proper open source licensing terms and which can be extended for many different usecases. Also the IBM Granite team has an aggressive plan for releasing updated versions of Granite, incorporating new features of special interest to developers, like making Granite a great engine to power IDEs and similar tools. We been brainstorming various ideas in the team for how we can make use of AI to provide improved or new features to users of GNOME and Fedora Workstation. This includes making sure Fedora Workstation users have access to great tools like RamaLama, that we make sure setting up accelerated AI inside Toolbx is simple, that we offer a good Code Assistant based on Granite and that we come up with other cool integration points. "I'm still not sure how I feel about this approach," writes designer/developer and blogger, Bradley Taunt. "While IBM Granite is an open source model, I still don't enjoy so much artificial 'intelligence' creeping into core OS development. This also isn't something optional on the end-users side, like a desktop feature or package. This sounds like it's going to be built directly into the core system."

"Red Hat has been pushing hard towards AI and my main concern is having this influence other operating system dev teams. Luckily things seems AI-free in BSD land. For now, at least."

An anonymous reader quotes a report from Ars Technica: In what is becoming a sadly regular occurrence, two popular free software projects, X.org/Freedesktop.org and Alpine Linux, need to rally some of their millions of users so that they can continue operating. Both services have largely depended on free server resources provided by Equinix (formerly Packet.net) and its Metal division for the past few years. Equinix announced recently that it was sunsetting its bare-metal sales and services, or renting out physically distinct single computers rather than virtualized and shared hardware. As reported by the Phoronix blog, both free software organizations have until the end of April to find and fund new hosting, with some fairly demanding bandwidth and development needs.

An issue ticket on Freedesktop.org's GitLab repository provides the story and the nitty-gritty needs of that project. Both the X.org foundation (home of the 40-year-old window system) and Freedesktop.org (a shared base of specifications and technology for free software desktops, including Wayland and many more) used Equinix's donated space. [...] Alpine Linux, a small, security-minded distribution used in many containers and embedded devices, also needs a new home quickly. As detailed in its blog, Alpine Linux uses about 800TB of bandwidth each month and also needs continuous integration runners (or separate job agents), as well as a development box. Alpine states it is seeking co-location space and bare-metal servers near the Netherlands, though it will consider virtual machines if bare metal is not feasible.

Tom's Hardware reports: Facebook's heavy-handed censorship of Linux groups and topics was "in error," the social media juggernaut has admitted. Responding to reports earlier this week, sparked by the curious censorship of the eminently wholesome DistroWatch, Facebook contacted PCMag to say that it had made a mistake and that the underlying issue had been rectified.

"This enforcement was in error and has since been addressed. Discussions of Linux are allowed on our services," said a Meta rep to PCMag. That is the full extent of the statement reproduced by the source... Copenhagen-hosted DistroWatch says it has appealed against the Community Standards-triggered ban shortly after it noticed it was in effect (January 19). PCMag received the Facebook admission of error on January 28. The latest statement from DistroWatch, which now prefers posting on Mastodon, indicates that Facebook has lifted the DistroWatch links ban.
More details from PCMag: Meta didn't say what caused the crackdown in the first place. But the company has been revamping some of its content moderation and plans to replace its fact-checking methodology with a user-driven Community Notes, similar to X. "We're also going to change how we enforce our policies to reduce the kind of mistakes that account for the vast majority of the censorship on our platforms," the company said earlier this month, in another irony.

"Up until now, we have been using automated systems to scan for all policy violations, but this has resulted in too many mistakes and too much content being censored that shouldn't have been," Meta added in the same post.

Google is enhancing Android 16's Linux Terminal app to support graphical Linux applications, so Android Authority decided to put it to the test by running Doom. From the report: The Terminal app first appeared in the Android 15 QPR2 beta as a developer option, and it still remains locked behind developer settings. Since its initial public release, Google pushed a few changes that fixed issues with the installation process and added a settings menu to resize the disk, forward ports, and backup the installation. However, the biggest changes the company has been working on, which include adding hardware acceleration support and a full graphical environment, have not been pushed to any public releases.

Thankfully, since Google is working on this feature in the open, it's possible to simply compile a build of AOSP with these changes added in. This gives us the opportunity to trial upcoming features of the Android Linux Terminal app before a public release. To demonstrate, we fired up the Linux Terminal on a Pixel 9 Pro, tapped a new button on the top right to enter the Display activity, and then ran the 'weston' command to open up a graphical environment. (Weston is a reference implementation of a Wayland compositor, a modern display server protocol.)

We also went ahead and enabled hardware acceleration beforehand as well as installed Chocolate Doom, a source port of Doom, to see if it would run. Doom did run, as you can see below. It ran well, which is no surprise considering Doom can run on literal potatoes. There wasn't any audio because an audio server isn't available yet, but audio support is something that Google is still working on.

Facebook has banned posts mentioning Linux-related topics, with the popular Linux news and discussion site, DistroWatch, at the center of the controversy. Tom's Hardware reports: A post on the site claims, "Facebook's internal policy makers decided that Linux is malware and labeled groups associated with Linux as being 'cybersecurity threats.' We tried to post some blurb about distrowatch.com on Facebook and can confirm that it was barred with a message citing Community Standards. DistroWatch says that the Facebook ban took effect on January 19. Readers have reported difficulty posting links to the site on this social media platform. Moreover, some have told DistroWatch that their Facebook accounts have been locked or limited after sharing posts mentioning Linux topics.

If you're wondering if there might be something specific to DistroWatch.com, something on the site that the owners/operators perhaps don't even know about, for example, then it seems pretty safe to rule out such a possibility. Reports show that "multiple groups associated with Linux and Linux discussions have either been shut down or had many of their posts removed." However, we tested a few other Facebook posts with mentions of Linux, and they didn't get blocked immediately. Copenhagen-hosted DistroWatch says it has tried to appeal against the Community Standards-triggered ban. However, they say that a Facebook representative said that Linux topics would remain on the cybersecurity filter. The DistroWatch writer subsequently got their Facebook account locked... DistroWatch points out the irony at play here: "Facebook runs much of its infrastructure on Linux and often posts job ads looking for Linux developers."

UPDATE: Facebook has admited they made a mistake and stopped blocking the posts.

Amid the ongoing Linux 6.14 kernel development cycle, Phoronix spotted a pull request for ACPI updates which "will allow for faster suspend and resume cycles on some systems."

Wikipedia defines ACPI as "an open standard that operating systems can use to discover and configure computer hardware components" for things like power management and putting unused hardware components to sleep. Phoronix reports: The ACPI change worth highlighting for Linux 6.14 is switching from msleep() to usleep_range() within the acpi_os_sleep() call in the kernel. This reduces spurious sleep time due to timer inaccuracy. Linux ACPI/PM maintainer Rafael Wysocki of Intel who authored this change noted that it could "spectacularly" reduce the duration of system suspend and resume transitions on some systems...

Rafael explained in the patch making the sleep change:

"The extra delay added by msleep() to the sleep time value passed to it can be significant, roughly between 1.5 ns on systems with HZ = 1000 and as much as 15 ms on systems with HZ = 100, which is hardly acceptable, at least for small sleep time values."
One 2022 bug report complained a Dell XPS 13 using Thunderbolt took "a full 8 seconds to suspend and a full 8 seconds to resume even though no physical devices are connected." In November an Intel engineer posted on the kernel mailing list that the fix gave a Dell XPS 13 a 42% improvement in kernel resume time (from 1943ms to 1127ms).

Two computer scientists at the University of Waterloo in Canada believe changing 30 lines of code in Linux "could cut energy use at some data centers by up to 30 percent," according to the site Data Centre Dynamics.

It's the code that processes packets of network traffic, and Linux "is the most widely used OS for data center servers," according to the article: The team tested their solution's effectiveness and submitted it to Linux for consideration, and the code was published this month as part of Linux's newest kernel, release version 6.13. "All these big companies — Amazon, Google, Meta — use Linux in some capacity, but they're very picky about how they decide to use it," said Martin Karsten [professor of Computer Science in the Waterloo's Math Faculty]. "If they choose to 'switch on' our method in their data centers, it could save gigawatt hours of energy worldwide. Almost every single service request that happens on the Internet could be positively affected by this."

The University of Waterloo is building a green computer server room as part of its new mathematics building, and Karsten believes sustainability research must be a priority for computer scientists. "We all have a part to play in building a greener future," he said. The Linux Foundation, which oversees the development of the Linux OS, is a founder member of the Green Software Foundation, an organization set up to look at ways of developing "green software" — code that reduces energy consumption.
Karsten "teamed up with Joe Damato, distinguished engineer at Fastly" to develop the 30 lines of code, according to an announcement from the university. "The Linux kernel code addition developed by Karsten and Damato was based on research published in ACM SIGMETRICS Performance Evaluation Review" (by Karsten and grad student Peter Cai).

Their paper "reviews the performance characteristics of network stack processing for communication-heavy server applications," devising an "indirect methodology" to "identify and quantify the direct and indirect costs of asynchronous hardware interrupt requests (IRQ) as a major source of overhead...

"Based on these findings, a small modification of a vanilla Linux system is devised that improves the efficiency and performance of traditional kernel-based networking significantly, resulting in up to 45% increased throughput..."