One of the key differences between Apple’s Macs and the iPhone and iPad is that the Mac can still boot and run non-Apple operating systems. This is a feature that Apple specifically built for the Mac, one of many features meant to ease the transition from Intel’s chips to Apple’s own silicon.
The problem, at least at first, was that alternate operating systems like Windows and Linux didn’t work natively with Apple’s hardware, not least because of missing drivers for basic things like USB ports, GPUs, and power management. Enter the Asahi Linux project, a community-driven effort to make open-source software run on Apple’s hardware.
In just a few years, the team has taken Linux on Apple Silicon from “basically bootable” to “plays native Windows games and sounds great doing it.” And the team’s ultimate goal is to contribute enough code upstream that you no longer need a Linux distribution just for Apple Silicon Macs.
On December 4 at 3: 30 pm Eastern (1: 30 pm Pacific), Ars Technica Senior Technology Reporter Andrew Cunningham will host a livestreamed YouTube conversation with Asahi Linux Project Lead Hector Martin and Graphics Lead Alyssa Rosenzweig that will cover the project’s genesis and its progress, as well as what the future holds.
Normally, Secure Boot prevents the UEFI from running all subsequent files unless they bear a digital signature certifying those files are trusted by the device maker. The exploit bypasses this protection by injecting shell code stashed in a malicious bitmap image displayed by the UEFI during the boot-up process. The injected code installs a cryptographic key that digitally signs a malicious GRUB file along with a backdoored image of the Linux kernel, both of which run during later stages of the boot process on Linux machines.
The silent installation of this key induces the UEFI to treat the malicious GRUB and kernel image as trusted components, and thereby bypass Secure Boot protections. The final result is a backdoor slipped into the Linux kernel before any other security defenses are loaded.
Diagram illustrating the execution flow of the LogoFAIL exploit Binarly found in the wild. Credit: Binarly
In an online interview, HD Moore, CTO and co-founder at runZero and an expert in firmware-based malware, explained the Binarly report this way:
The Binarly paper points to someone using the LogoFAIL bug to configure a UEFI payload that bypasses secure boot (firmware) by tricking the firmware into accepting their self-signed key (which is then stored in the firmware as the MOK variable). The evil code is still limited to the user-side of UEFI, but the LogoFAIL exploit does let them add their own signing key to the firmware’s allow list (but does not infect the firmware in any way otherwise).
It’s still effectively a GRUB-based kernel backdoor versus a firmware backdoor, but it does abuse a firmware bug (LogoFAIL) to allow installation without user interaction (enrolling, rebooting, then accepting the new MOK signing key).
In a normal secure boot setup, the admin generates a local key, uses this to sign their updated kernel/GRUB packages, tells the firmware to enroll the key they made, then after reboot, the admin has to accept this new key via the console (or remotely via bmc/ipmi/ilo/drac/etc bios console).
In this setup, the attacker can replace the known-good GRUB + kernel with a backdoored version by enrolling their own signing key without user interaction via the LogoFAIL exploit, but it’s still effectively a GRUB-based bootkit, and doesn’t get hardcoded into the BIOS firmware or anything.
Machines vulnerable to the exploit include some models sold by Acer, HP, Fujitsu, and Lenovo when they ship with a UEFI developed by manufacturer Insyde and run Linux. Evidence found in the exploit code indicates the exploit may be tailored for specific hardware configurations of such machines. Insyde issued a patch earlier this year that prevents the exploit from working. Unpatched devices remain vulnerable. Devices from these manufacturers that use non-Insyde UEFIs aren’t affected.
“Remove some entries due to various compliance requirements. They can come back in the future if sufficient documentation is provided.”
That two-line comment, submitted by major Linux kernel maintainer Greg Kroah-Hartman, accompanied a patch that removed about a dozen names from the kernle’s MAINTAINERS file. “Some entries” notably had either Russian names or .ru email addresses. “Various compliance requirements” was, in this case, sanctions against Russia and Russian companies, stemming from that country’s invasion of Ukraine.
This merge did not go unnoticed. Replies on the kernel mailing list asked about this “very vague” patch. Kernel developer James Bottomley wrote that “we” (seemingly speaking for Linux maintainers) had “actual advice” from Linux Foundation counsel. Employees of companies on the Treasury Department’s Office of Foreign Assets Control list of Specially Designated Nationals and Blocked Persons (OFAC SDN), or connected to them, will have their collaborations “subject to restrictions,” and “cannot be in the MAINTAINERS file.” “Sufficient documentation” would mean evidence that someone does not work for an OFAC SDN entity, Bottomley wrote.
There followed a number of messages questioning the legitimacy, suddenness, potentially US-forced, and non-reviewed nature of the commit, along with broader questions about the separation of open source code from international politics. Linux creator Linus Torvalds entered the thread with, “Ok, lots of Russian trolls out and about.” He wrote: “It’s entirely clear why the change was done” and noted that “Russian troll factories” will not revert it and that “the ‘various compliance requirements’ are not just a US thing.
The malware resides in the userspace portion of the interbank switch connecting the issuing domain and the acquiring domain. When a compromised card is used to make a fraudulent translation, FASTCash tampers with the messages the switch receives from issuers before relaying it back to the merchant bank. As a result, issuer messages denying the transaction are changed to approvals.
The following diagram illustrates how FASTCash works:
Credit: haxrob
Credit: haxrob
The switches chosen for targeting run misconfigured implementations of ISO 8583, a messaging standard for financial transactions. The misconfigurations prevent message authentication mechanisms, such as those used by field 64 as defined in the specification, from working. As a result, the tampered messages created by FASTCash aren’t detected as fraudulent.
“FASTCash malware targets systems that ISO8583 messages at a specific intermediate host where security mechanisms that ensure the integrity of the messages are missing, and hence can be tampered,” haxrob wrote. “If the messages were integrity protected, a field such as DE64 would likely include a MAC (message authentication code). As the standard does not define the algorithm, the MAC algorithm is implementation specific.”
The researcher went on to explain:
FASTCash malware modifies transaction messages in a point in the network where tampering will not cause upstream or downstream systems to reject the message. A feasible position of interception would be where the ATM/PoS messages are converted from one format to another (For example, the interface between a proprietary protocol and some other form of an ISO8583 message) or when some other modification to the message is done by a process running in the switch.
CISA said that BeagleBoyz—one of the names the North Korean hackers are tracked under—is a subset of HiddenCobra, an umbrella group backed by the government of that country. Since 2015, BeagleBoyz has attempted to steal nearly $2 billion. The malicious group, CISA said, has also “manipulated and, at times, rendered inoperable, critical computer systems at banks and other financial institutions.”
The haxrob report provides cryptographic hashes for tracking the two samples of the newly discovered Linux version and hashes for several newly discovered samples of FASTCash for Windows.
The ability to remain installed and undetected makes Perfctl hard to fight.
Thousands of machines running Linux have been infected by a malware strain that’s notable for its stealth, the number of misconfigurations it can exploit, and the breadth of malicious activities it can perform, researchers reported Thursday.
The malware has been circulating since at least 2021. It gets installed by exploiting more than 20,000 common misconfigurations, a capability that may make millions of machines connected to the Internet potential targets, researchers from Aqua Security said. It can also exploit CVE-2023-33246, a vulnerability with a severity rating of 10 out of 10 that was patched last year in Apache RocketMQ, a messaging and streaming platform that’s found on many Linux machines.
Perfctl storm
The researchers are calling the malware Perfctl, the name of a malicious component that surreptitiously mines cryptocurrency. The unknown developers of the malware gave the process a name that combines the perf Linux monitoring tool and ctl, an abbreviation commonly used with command line tools. A signature characteristic of Perfctl is its use of process and file names that are identical or similar to those commonly found in Linux environments. The naming convention is one of the many ways the malware attempts to escape notice of infected users.
Perfctl further cloaks itself using a host of other tricks. One is that it installs many of its components as rootkits, a special class of malware that hides its presence from the operating system and administrative tools. Other stealth mechanisms include:
Stopping activities that are easy to detect when a new user logs in
Using a Unix socket over TOR for external communications
Deleting its installation binary after execution and running as a background service thereafter
Manipulating the Linux process pcap_loop through a technique known as hooking to prevent admin tools from recording the malicious traffic
Suppressing mesg errors to avoid any visible warnings during execution.
The malware is designed to ensure persistence, meaning the ability to remain on the infected machine after reboots or attempts to delete core components. Two such techniques are (1) modifying the ~/.profile script, which sets up the environment during user login so the malware loads ahead of legitimate workloads expected to run on the server and (2) copying itself from memory to multiple disk locations. The hooking of pcap_loop can also provide persistence by allowing malicious activities to continue even after primary payloads are detected and removed.
Besides using the machine resources to mine cryptocurrency, Perfctl also turns the machine into a profit-making proxy that paying customers use to relay their Internet traffic. Aqua Security researchers have also observed the malware serving as a backdoor to install other families of malware.
Assaf Morag, Aqua Security’s threat intelligence director, wrote in an email:
Perfctl malware stands out as a significant threat due to its design, which enables it to evade detection while maintaining persistence on infected systems. This combination poses a challenge for defenders and indeed the malware has been linked to a growing number of reports and discussions across various forums, highlighting the distress and frustration of users who find themselves infected.
Perfctl uses a rootkit and changes some of the system utilities to hide the activity of the cryptominer and proxy-jacking software. It blends seamlessly into its environment with seemingly legitimate names. Additionally, Perfctl’s architecture enables it to perform a range of malicious activities, from data exfiltration to the deployment of additional payloads. Its versatility means that it can be leveraged for various malicious purposes, making it particularly dangerous for organizations and individuals alike.
“The malware always manages to restart”
While Perfctl and some of the malware it installs are detected by some antivirus software, Aqua Security researchers were unable to find any research reports on the malware. They were, however, able to find a wealth of threads on developer-related sites that discussed infections consistent with it.
This Reddit comment posted to the CentOS subreddit is typical. An admin noticed that two servers were infected with a cryptocurrency hijacker with the names perfcc and perfctl. The admin wanted help investigating the cause.
“I only became aware of the malware because my monitoring setup alerted me to 100% CPU utilization,” the admin wrote in the April 2023 post. “However, the process would stop immediately when I logged in via SSH or console. As soon as I logged out, the malware would resume running within a few seconds or minutes.” The admin continued:
I have attempted to remove the malware by following the steps outlined in other forums, but to no avail. The malware always manages to restart once I log out. I have also searched the entire system for the string “perfcc” and found the files listed below. However, removing them did not resolve the issue. as it keep respawn on each time rebooted.
After exploiting a vulnerability or misconfiguration, the exploit code downloads the main payload from a server, which, in most cases, has been hacked by the attacker and converted into a channel for distributing the malware anonymously. An attack that targeted the researchers’ honeypot named the payload httpd. Once executed, the file copies itself from memory to a new location in the /tmp directory, runs it, and then terminates the original process and deletes the downloaded binary.
Once moved to the /tmp directory, the file executes under a different name, which mimics the name of a known Linux process. The file hosted on the honeypot was named sh. From there, the file establishes a local command-and-control process and attempts to gain root system rights by exploiting CVE-2021-4043, a privilege-escalation vulnerability that was patched in 2021 in Gpac, a widely used open source multimedia framework.
The malware goes on to copy itself from memory to a handful of other disk locations, once again using names that appear as routine system files. The malware then drops a rootkit, a host of popular Linux utilities that have been modified to serve as rootkits, and the miner. In some cases, the malware also installs software for “proxy-jacking,” the term for surreptitiously routing traffic through the infected machine so the true origin of the data isn’t revealed.
The researchers continued:
As part of its command-and-control operation, the malware opens a Unix socket, creates two directories under the /tmp directory, and stores data there that influences its operation. This data includes host events, locations of the copies of itself, process names, communication logs, tokens, and additional log information. Additionally, the malware uses environment variables to store data that further affects its execution and behavior.
All the binaries are packed, stripped, and encrypted, indicating significant efforts to bypass defense mechanisms and hinder reverse engineering attempts. The malware also uses advanced evasion techniques, such as suspending its activity when it detects a new user in the btmp or utmp files and terminating any competing malware to maintain control over the infected system.
The diagram below captures the attack flow:
Credit: Aqua Security
Credit: Aqua Security
The following image captures some of the names given to the malicious files that are installed:
Credit: Aqua Security
Credit: Aqua Security
By extrapolating data such as the number of Linux servers connected to the Internet across various services and applications, as tracked by services such as Shodan and Censys, the researchers estimate that the number of machines infected by Perfctl is measured in the thousands. They say that the pool of vulnerable machines—meaning those that have yet to install the patch for CVE-2023-33246 or contain a vulnerable misconfiguration—is in the millions. The researchers have yet to measure the amount of cryptocurrency the malicious miners have generated.
People who want to determine if their device has been targeted or infected by Perfctl should look for indicators of compromise included in Thursday’s post. They should also be on the lookout for unusual spikes in CPU usage or sudden system slowdowns, particularly if they occur during idle times. To prevent infections, it’s important that the patch for CVE-2023-33246 be installed and that the the misconfigurations identified by Aqua Security be fixed. Thursday’s report provides other steps for preventing infections.
Dan Goodin is Senior Security Editor at Ars Technica, where he oversees coverage of malware, computer espionage, botnets, hardware hacking, encryption, and passwords. In his spare time, he enjoys gardening, cooking, and following the independent music scene. Dan is based in San Francisco. Follow him at @dangoodin on Mastodon. Contact him on Signal at DanArs.82.
Enlarge/ A photo of Dmitry Grinberg’s custom Linux/4004 circuit board.
Hardware hacker Dmitry Grinberg recently achieved what might sound impossible: booting Linux on the Intel 4004, the world’s first commercial microprocessor. With just 2,300 transistors and an original clock speed of 740 kHz, the 1971 CPU is incredibly primitive by modern standards. And it’s slow—it takes about 4.76 days for the Linux kernel to boot.
Initially designed for a Japanese calculator called the Busicom 141-PF, the 4-bit 4004 found limited use in commercial products of the 1970s before being superseded by more powerful Intel chips, such as the 8008 and 8080 that powered early personal computers—and then the 8086 and 8088 that launched the IBM PC era.
If you’re skeptical that this feat is possible with a raw 4004, you’re right: The 4004 itself is far too limited to run Linux directly. Instead, Grinberg created a solution that is equally impressive: an emulator that runs on the 4004 and emulates a MIPS R3000 processor—the architecture used in the DECstation 2100 workstation that Linux was originally ported to. This emulator, along with minimal hardware emulation, allows a stripped-down Debian Linux to boot to a command prompt.
Linux/4004.
Grinberg is no stranger to feats of running Linux in unlikely places. As he explains on his website, “In 2012, I ran real Linux on an 8-bit microcontroller (AVR), setting a new world record for lowest-end-machine to ever run Linux.” After others improved on that record in recent years, he decided to surpass himself and others by targeting the very first microprocessor.
The long, slow boot
To make Linux on the 4004 work, Grinberg had to overcome numerous challenges. The 4004 has extremely limited ROM and RAM, no interrupts, and lacks even basic logical operations like AND and OR. Grinberg’s emulator makes clever use of lookup tables and other tricks to squeeze maximum performance out of the primitive CPU.
The final hardware uses the 4004 (overclocked to 790 kHz) along with several other period-correct support chips from Intel’s MCS-4 chipset. It includes a VFD display to show Linux output and can accept input over a serial connection. The whole setup draws about 6 W of power.
To pull it all together, Grinberg designed a custom circuit board with no vias (paths from one side of the circuit board to the other) and only right-angle traces for a retro aesthetic. It’s meant to be wall-mountable as an art piece, slowly executing Linux commands over the course of days or weeks.
While it has no practical purpose, the Linux/4004 project demonstrates the flexibility of Linux and pushes emulation to its limits. Grinberg is considering the possibility of offering kits or fully assembled boards for others who want to experience Linux at its slowest, though this is not yet definite.
The full details of the project, including schematics and source code, are available on Grinberg’s website. For those interested in vintage computing or extreme Linux implementations, it’s a fascinating look at what’s possible with 1970s technology and a lot of clever engineering.
Enlarge/ Cutting metal with lasers is hard, but even harder when you don’t know the worst-case timings of your code.
Getty Images
As is so often the case, a notable change in an upcoming Linux kernel is both historic and no big deal.
If you wanted to use “Real-Time Linux” for your audio gear, your industrial welding laser, or your Mars rover, you have had that option for a long time (presuming you didn’t want to use QNX or other alternatives). Universities started making their own real-time kernels in the late 1990s. A patch set, PREEMPT_RT, has existed since at least 2005. And some aspects of the real-time work, like NO_HZ, were long ago moved into the mainline kernel, enabling its use in data centers, cloud computing, or anything with a lot of CPUs.
But officialness still matters, and in the 6.12 kernel, PREEMPT_RT will likely be merged into the mainline. As noted by Steven Vaughan-Nichols at ZDNet, the final sign-off by Linus Torvalds occurred while he was attending Open Source Summit Europe. Torvalds wrote the original code for printk, a debugging tool that can pinpoint exact moments where a process crashes, but also introduces latency that runs counter to real-time computing. The Phoronix blog has tracked the progress of PREEMPT_RT into the kernel, along with the printk changes that allowed for threaded/atomic console support crucial to real-time mainlining.
What does this mean for desktop Linux? Not much. Beyond high-end audio production or replication (and even that is debatable), a real-time kernel won’t likely make windows snappier or programs zippier. But the guaranteed execution and worst-case latency timings a real-time Linux provides are quite useful to, say, the systems that monitor car brakes, guide CNC machines, and regulate fiendishly complex multi-CPU systems. Having PREEMPT-RT in the mainline kernel makes it easier to maintain a real-time system, rather than tend to out-of-tree patches.
It will likely change things for what had been, until now, specialty providers of real-time OS solutions for mission-critical systems. Ubuntu, for example, started offering a real-time version of its distribution in 2023 but required an Ubuntu Pro subscription for access. Ubuntu pitched its release at robotics, automation, embedded Linux, and other real-time needs, with the fixes, patches, module integration, and testing provided by Ubuntu.
“Controlling a laster with Linux is crazy,” Torvalds said at the Kernel Summit of 2006, “but everyone in this room is crazy in his own way. So if you want to use Linux to control an industrial welding laser, I have no problem with your using PREEMPT_RT.” Roughly 18 years later, Torvalds and the kernel team, including longtime maintainer and champion-of-real-time Steven Rostedt, have made it even easier to do that kind of thing.
Enlarge/ Sorry about all the black space in the lower-right corner. Nerdfetch does not make good use of the space it’s given—unlike the Asahi install on this MacBook.
Kevin Purdy
Almost nobody truly needed Neofetch, but the people who did use it? They really liked it.
Neofetch, run from a terminal, displayed key system information alongside an ASCII-art image of the operating system or distribution running on that system. You knew most of this data, but if you’re taking a screenshot of your system, it looked cool and conveyed a lot of data in a small space. “The overall purpose of Neofetch is to be used in screen-shots of your system,” wrote Neofetch’s creator, Dylan Araps, on its Github repository. “Neofetch shows the information other people want to see.”
Neofetch did that, providing cool screenshots and proof-of-life images across nearly 150 OS versions until late April. The last update to the tool was made three years before that, and Araps’ Github profile now contains a rather succinct coda: “Have taken up farming.” Araps joins “going to a commune in Vermont” and “I now make furniture out of wood” in the pantheon of programmers who do not just leave the field, but flee into another realm entirely.
As sometimes happens, the void was filled not by one decent replacement but many.
Fastfetch, which is indeed pretty fast and seems to have more distros recognized (like Asahi Linux on an ARM MacBook).
Kevin Purdy
Hyfetch, which gives you a bunch of pride flag options on first running but can also be used without pride colors.
Nerdfetch, which I could never quite get to run perfectly with Nerdfonts, Cozette, or Phosphor. It’s small, which can be handy, but it mostly just shows a Tux penguin, not an OS-specific ASCII image.
Cpufetch, which, as the name implies, drops much more chip data into the term.
The neo-Neofetches
Fastfetch seems to have captured the default forum/thread/blog recommendation as a Neofetch replacement. It is under active development, with changes occurring just hours before this post was published. It’s highly customizable, available across most major platforms and distributions, and extensible through modules. It supports Wayland, provides more detailed memory and storage statistics, and, as the name suggests, is generally faster. It’s FOSS and has a tutorial on customizing and extending Fastfetch.
NerdFetch gives you the kind of icon customization you might expect if you’re the type who takes meticulously arranged screenshots of your desktop. By installing one of the glyph-packed Nerd Fonts, you can replace text inside your readout with icons readable at a glance. It’s available on POSIX-compliant systems (“Anything but Windows”). It lacks a lot of customization and module options, and it’s missing the big, custom OS logo (it seemingly shows a very abstract ASCII Tux in both MacOS and Asahi Linux). But it’s also compact and a bit different.
What else? There’s hyfetch, which is “neofetch with pride flags,” but it also contains inside it “neowofetch,” which is an updated neofetch sans pride coloring. The macchina system info tool is written in Rust and offers themeing, being “basic by default and extensible by design.” And cpufetch is, as you might imagine, a lot more CPU data, along with a logo. Curiously, cpufetch showed an “arm” rendering when I ran it under Asahi Linux on a MacBook, but then an Apple logo while inside MacOS. Works either way! Just interesting.
If you’ve put time into getting a Linux desktop just how you like it—or just getting Linux onto a device that really doesn’t want it—it follows that you’d want to show it off. These are not the last of the apps that will try to make fetch happen, but they’re a strong start.
Enlarge/ Rust never sleeps. But Rust, the programming language, can be held at bay if enough kernel programmers aren’t interested in seeing it implemented.
Getty Images
The Linux kernel is not a place to work if you’re not ready for some, shall we say, spirited argument. Still, one key developer in the project to expand Rust’s place inside the largely C-based kernel feels the “nontechnical nonsense” is too much, so he’s retiring.
Wedson Almeida Filho, a leader in the Rust for Linux project, wrote to the Linux kernel mailing list last week to remove himself as the project’s maintainer. “After almost 4 years, I find myself lacking the energy and enthusiasm I once had to respond to some of the nontechnical nonsense, so it’s best to leave it up to those who still have it in them,” Filho wrote. While thanking his teammates, he noted that he believed the future of kernels “is with memory-safe languages,” such as Rust. “I am no visionary but if Linux doesn’t internalize this, I’m afraid some other kernel will do to it what it did to Unix,” Filho wrote.
Filho also left a “sample for context,” a link to a moment during a Linux conference talk in which an off-camera voice, identified by Filho in a Register interview as kernel maintainer Ted Ts’o, emphatically interjects: “Here’s the thing: you’re not going to force all of us to learn Rust.” In the context of Filho’s request that Linux’s file system implement Rust bindings, Ts’o says that while he knows he must fix all the C code for any change he makes, he cannot or will not fix the Rust bindings that may be affected.
“They just want to keep their C code”
Asahi Lina, developer on the Asahi Linux project, posted on Mastodon late last week: “I regretfully completely understand Wedson’s frustrations.” Noting that “a subset of C kernel developers just seem determined to make the lives of Rust maintainers as difficult as possible,” Lina detailed the memory safety issues they ran into writing Direct Rendering Manager (DRM) scheduler abstractions. Lina tried to push small fixes that would make the C code “more robust and the lifetime requirements sensible,” but was blocked by the maintainer. Bugs in that DRM scheduler’s C code are the only causes of kernel panics in Lina’s Apple GPU driver, she wrote—”Because I wrote it in Rust.”
“But I get the feeling that some Linux kernel maintainers just don’t care about future code quality, or about stability or security any more,” Lina wrote. “They just want to keep their C code and wish us Rust folks would go away. And that’s really sad… and isn’t helping make Linux better.”
Drew DeVault, founder of SourceHut, blogged about Rust’s attempts to find a place inside the Kernel. In theory the kernel should welcome enthusiastic input from motivated newcomers. “In practice, the Linux community is the wild wild west, and sweeping changes are infamously difficult to achieve consensus on, and this is by far the broadest sweeping change ever proposed for the project,” DeVault writes. “Every subsystem is a private fiefdom, subject to the whims of each one of Linux’s 1,700+ maintainers, almost all of whom have a dog in this race. It’s herding cats: introducing Rust effectively is one part coding work and ninety-nine parts political work – and it’s a lot of coding work.”
Rather than test their patience with the kernel’s politics, DeVault suggests Rust developers build a Linux-compatible kernel from scratch. “Freeing yourselves of the [Linux Kernel Mailing List] political battles would probably be a big win for the ambitions of bringing Rust into kernel space,” DeVault writes.
Torvalds understands why Rust uptake is slow
You might be wondering what lead maintainer Linus Torvalds thinks about all this. He took a “wait and see” approach in 2021, hoping Rust would first make itself known in relatively isolated device drivers. At an appearance late last month, Torvalds… essentially agreed with the Rust-minded developer complaints, albeit from a much greater remove.
“I was expecting [Rust] updates to be faster, but part of the problem is that old-time kernel developers are used to C and don’t know Rust,” Torvalds said. “They’re not exactly excited about having to learn a new language that is, in some respects, very different. So there’s been some pushback on Rust.” Torvalds added, however, that “another reason has been the Rust infrastructure itself has not been super stable.”
The Linux kernel is a high-stakes project in which hundreds or thousands of developers have a stake; conflict is perhaps inevitable. Time will tell how long C will remain the primary way of coding for, and thinking about, such a large yet always-moving, codebase.
Ars has reached out to both Filho and Ts’o for comment and will update this post with response.
Enlarge/ A little auto-tiling on the Cosmic desktop.
System76
System76 has released an alpha version of its Cosmic desktop environment for Linux and Unix-like systems. The Linux hardware firm isn’t targeting only its customers with its GNOME replacement; it also hopes to get distro maintainers and app makers on board with its Rust-built, UX-focused desktop.
While the Cosmic desktop will be built into the Linux vendor’s Pop!_OS (which is also in the alpha ISO), it’s also available to other systems, as you might expect. System76 provides drop-in instructions for Fedora and Arch Linux installs, among others.
System76 says it is “excited to see COSMIC integration elevate Linux as a whole,” along with what results “from making UX-building more accessible.” By building Cosmic natively in the Rust language, System76 also intends to provide a more stable and memory-safe environment for apps.
Cosmic shows deep attention to tiling, keyboard shortcuts, and panel and dock customization, as has been present on its Pop!_OS. I’m a bit of a boring side-by-side, single-workspace type; Gardiner Bryant on YouTube went deeper into the Cosmic alpha’s tiling, panels, and GTK app acceptance. I found that getting Cosmic into a reasonable shape I could work from, and picking up its keyboard window shortcuts, was easier than with either KDE or GNOME.
One thing System76 made clear in its push for Cosmic is its readiness for more deeply integrated themes. System76 offered a few examples in its press materials, and I must admit a fondness for its over-the-top examples.
System76 probably can’t officially offer this theme, what with Internet Explorer logo and other recognizable icons, but it does illustrate the theme potentials.
System76
Answering the eternal software question “Can it run Doom?” even in desktop environments.
System76
This? This is the subtle side of this very Polish-RPG-influenced theme.
System76
If you’re going to hack the net and fight the corpos, you gotta wake your eyes up, choom.
System76
Promising, but definitely not production
I’ve been using the Cosmic-topped desktop alpha since last week on an also alpha-ish Pop!_OS 24.04 long-term support distribution with Wayland windowing. It’s running on my desktop-ified Framework laptop, since System76 noted that virtual machines would require some hardware acceleration trickery to function properly. It’s definitely an alpha, with lots of things you’d expect to see in the settings and around the system missing or non-interactive.
What I can say about Cosmic, even at this early alpha stage, is that it’s relatively snappy and cohesive compared to other systems I’ve used. The settings app only has six main categories, and one of them is “Desktop,” with robust settings for changing your dock, windows, workspaces, and appearance. I keep a webcam on top of my monitor, with a clamp big enough to hide the time/date combo sometimes perched there by GNOME desktops. Cosmic’s panel controls made it easy to move this to the right and similarly position and style my dock however I like.
Most of what is on display here is not for end users, though, as much as it is for adventurous users, or maybe community distro packagers, looking for a desktop environment carrying far less technical debt than GNOME and KDE. At the same time, that means there will be some tension and scraping between certain apps and this new environment. Slack’s main window on my system is constantly disappearing, and clicking its persistent notification in the tray won’t bring it back. And I’m the type who always remaps his Caps Lock key to Escape, but there’s no place to do that yet, and the Gnome-Tweaks app won’t work, either. Some of this is probably the distribution itself, some of it is Cosmic, and some of it is between the two. (Yes, I’m certain there’s a way to get that keyboard fix with a command or config file, but this is just a test run.)
The Cosmic team says it will next work on settings pages, the Files app, variable refresh rate, and software rendering, among other bugs and refinements. After that comes the hard part of gaining acceptance and installs across the wider open source community.
“Nvidia transitions fully” sounds like real commitment, a burn-the-boats call. “Towards open-source GPU,” yes, evoking the company’s “first step” announcement a little over two years ago, so this must be progress, right? But, back up a word here, then finish: “GPU kernel modules.”
So, Nvidia has “achieved equivalent or better application performance with our open-source GPU kernel modules,” and added some new capabilities to them. And now most of Nvidia’s modern GPUs will default to using open source GPU kernel modules, starting with driver release R560, with dual GPL and MIT licensing. But Nvidia has moved most of its proprietary functions into a proprietary, closed-source firmware blob. The parts of Nvidia’s GPUs that interact with the broader Linux system are open, but the user-space drivers and firmware are none of your or the OSS community’s business.
Is it better than what existed before? Certainly. AMD and Intel have maintained open source GPU drivers, in both the kernel and user space, for years, though also with proprietary firmware. This brings Nvidia a bit closer to the Linux community and allows for community debugging and contribution. There’s no indication that Nvidia aims to go further with its open source moves, however, and its modules remain outside the main kernel, packaged up for users to install themselves.
Not all GPUs will be able to use the open source drivers: a number of chips from the Maxwell, Pascal, and Volta lines; GPUs from the Turing, Ampere, Ada Lovelace, and Hopper architectures are recommended to switch to the open bits; and Grace Hopper and Blackwell units must do so.
As noted by Hector Martin, a developer on the Asahi Linux distribution, at the time of the first announcement, this shift makes it easier to sandbox closed-source code while using Nvidia hardware. But the net amount of closed-off code is about the same as before.
Nvidia’s blog post has details on how to integrate its open kernel modules onto various systems, including CUDA setups.
Linux and its code are made by people, and people are not with us forever. Over the weekend, a brief message on the Linux kernel mailing list reminded people of just how much one person can mean to a seemingly gargantuan project like Linux, and how quickly they can disappear:
Denise Finger, wife of the deceased, wrote to the Linux Wireless list on Friday evening:
This is to notify you that Larry Finger, one of your developers, passed away on June 21st.
LWN.net reckons that Finger, 84, contributed to 94 Linux kernel releases, or 1,464 commits total, at least since kernel 2.6.16 in 2006 (and when the kernel started using git to track changes). Given the sometimes precarious nature of contributing to the kernel, this is on its own an impressive achievement—especially for someone with no formal computer training, and who considered himself a scientist.
The deepest of trenches: Linux Wi-Fi in the 2000s
That kind of effort is worth celebrating, regardless. But it’s the space that Finger devoted himself to that makes him a notably patient, productive contributor.
Getting Wi-Fi to work on a device running Linux back when Finger started contributing was awful. The chances of your hardware being recognized, activated, and working properly right after install was akin to getting a straight flush in poker. If nobody had gotten around to your wireless chipset yet, you used NDISwrapper, a Windows-interfacing kludge tool that simultaneously made your Linux install less open and yet still painful to install and maintain.
Finger started fixing this with work on Broadcom’s BCM43XX drivers. Broadcom provided no code for its gear, so Finger helped reverse-engineer the necessary specs by manually dumping and reading hardware registers. Along with Broadcom drivers, Finger also provided Realtek drivers. Many commenters across blogs and message boards are noting that their systems are still using pieces of Finger’s code today.
Fixing mainframes, science gear, and RV resorts
Larry Finger, and fish, from his Quora profile.
Quora
Finger doesn’t have a large footprint on the web, outside of his hundreds of kernel commits. He has a page for DRAWxtl, for producing crystal-structure drawings, on his personal domain, but not a general personal page. He sometimes answered Quora questions. He had a GitHub profile, showing more than 100 contributions to projects in 2024.
Perhaps the biggest insight into Finger found in one place is a three-part series for Linux Journal, “Linux in a Windows Workstation Environment,” written in 2005, when he was roughly 65. He summarizes his background: Fortran programmer in 1963, PDP-11 interfaces to scientific instruments in the 1970s, VAX-11/780 work in the early 1980s, and then Unix/Linux systems, until retiring from the Carnegie Institution for Science in Washington, DC, in 1999. The mineral Fingerite is named for Finger, whose work in crystallography took him on a fellowship to northern Bavaria, as noted in one Quora answer about the Autobahn.
“At that time, I became a full-time RV resident, dedicated to the avoidance of cold weather,” Finger writes. He and his wife Denise arrived that year at a 55-plus RV community in Mesa, Arizona. He joined the computer club, which had a growing number of Windows PCs sharing a DSL connection through one of the systems running WinGate. A new RV resort owner wanted to expand to 22 workstations, but WinGate licenses for that many would have been expensive for the club. Finger, who was “highly distrustful of using Windows 98 in a mission-critical role,” set to work.
Finger goes on across the series to describe the various ways he upgraded the routing and server capacity of the network, which grew to 38 user stations, Samba shares, a membership database, VPN tunnels, several free RJ-45 ports, and “free Wi-Fi access… throughout the park.”
Lots of people have commented on the broad work Finger did to make Linux usable for more people. A few mention that Finger also mentored people, the kind of work that has exponential effects. “MB” wrote on LWN.net that Finger “mentored other people to get the Broadcom Open Source code into kernel. And I think it was a huge success. And that was only a small part of Larry’s success story.”
In a 2023 Quora response to someone asking if someone without “any formal training in computer science” can “contribute something substantial” to Linux, Finger writes, “I think that I have.” Finger links to the stats for the 6.4 kernel, showing 172,346 lines of his code in it, roughly 0.5% of the total.
I have never taken any courses in Computer Science; however, I have considerable experience in coding, much of which happened when computers were a lot less powerful than today, and it was critical to write code that ran efficiently.
Finger suggests in his response small patches, deep reading of the guidelines, and always using git’s send-email to send patches: “Nothing will get shot down more quickly than a patch submitted from a mailer such as Thunderbird.” Finding typos and errors in comments and text strings can help, especially after translation. Finger advises being patient, expecting criticism about following rules and formats, and to keep plugging away at it.
In another Quora response about kernel driver development, Finger says, “This activity can be highly rewarding, and also equally frustrating!” You should learn C, Finger suggested, and maybe start with analyzing USB drivers, and take your time learning about DMA.
“Do not lose hope,” Finger wrote. “It took me about 2 years before I could do anything more than tell the experts where my system was generating a fault.”
