Linux

as-the-kernel-turns:-rust-in-linux-saga-reaches-the-“linus-in-all-caps”-phase

As the Kernel Turns: Rust in Linux saga reaches the “Linus in all-caps” phase

Rust, a modern and notably more memory-safe language than C, once seemed like it was on a steady, calm, and gradual approach into the Linux kernel.

In 2021, Linux kernel leaders, like founder and leader Linus Torvalds himself, were impressed with the language but had a “wait and see” approach. Rust for Linux gained supporters and momentum, and in October 2022, Torvalds approved a pull request adding support for Rust code in the kernel.

By late 2024, however, Rust enthusiasts were frustrated with stalls and blocks on their efforts, with the Rust for Linux lead quitting over “nontechnical nonsense.” Torvalds said at the time that he understood it was slow, but that “old-time kernel developers are used to C” and “not exactly excited about having to learn a new language.” Still, this could be considered a normal amount of open source debate.

But over the last two months, things in one section of the Linux Kernel Mailing List have gotten tense and may now be heading toward resolution—albeit one that Torvalds does not think “needs to be all that black-and-white.” Greg Kroah-Hartman, another long-time leader, largely agrees: Rust can and should enter the kernel, but nobody will be forced to deal with it if they want to keep working on more than 20 years of C code.

Previously, on Rust of Our Lives

Earlier this month, Hector Martin, the lead of the Asahi Linux project, resigned from the list of Linux maintainers while also departing the Asahi project, citing burnout and frustration with roadblocks to implementing Rust in the kernel. Rust, Martin maintained, was essential to doing the kind of driver work necessary to crafting efficient and secure drivers for Apple’s newest chipsets. Christoph Hellwig, maintainer of the Direct Memory Access (DMA) API, was opposed to Rust code in his section on the grounds that a cross-language codebase was painful to maintain.

Torvalds, considered the “benevolent dictator for life” of the Linux kernel he launched in 1991, at first critiqued Martin for taking his issues to social media and not being tolerant enough of the kernel process. “How about you accept that maybe the problem is you,” Torvalds wrote.

As the Kernel Turns: Rust in Linux saga reaches the “Linus in all-caps” phase Read More »

asahi-linux-lead-resigns-from-mac-based-distro-after-tumultuous-kernel-debate

Asahi Linux lead resigns from Mac-based distro after tumultuous kernel debate

Working at the intersection of Apple’s newest hardware and Linux kernel development, for the benefit of a free distribution, was never going to be easy. But it’s been an especially hard couple of weeks for Hector Martin, project lead for Asahi Linux, capping off years of what he describes as burnout, user entitlement, and political battles within the Linux kernel community about Rust code.

In a post on his site, “Resigning as Asahi Linux project lead,” Martin summarizes his history with hardware hacking projects, including his time with the Wii homebrew scene (Team Twiizers/fail0verflow), which had its share of insistent users desperate to play pirated games. Martin shifted his focus, and when Apple unveiled its own silicon with the M1 series, Martin writes, “I realized that making it run Linux was my dream project.” This time, there was no jailbreaking and a relatively open, if tricky, platform.

Support and donations came quickly. The first two years saw rapid advancement of a platform built “from scratch, with zero vendor support or documentation.” Upstreaming code to the Linux kernel, across “practically every Linux subsystem,” was an “incredibly frustrating experience” (emphasis Martin’s).

Then came the users demanding to know when Thunderbolt, monitors over USB-C, M3/M4 support, and even CPU temperature checking would appear. Donations and pledges slowly decreased while demands increased. “It seemed the more things we accomplished, the less support we had,” Martin writes.

Martin cites personal complications, along with stalking and harassment, as slowing down work through 2024, while Vulkan drivers and an emulation stack still shipped. Simultaneously, issues with pushing Rust code into the Linux kernel were brewing. Rust was “the entire reason our GPU driver was able to succeed in the time it did,” Martin writes. Citing the Nova driver for Nvidia GPUs as an example, Martin writes that “More modern programming languages are better suited to writing drivers for more modern hardware with more complexity and novel challenges, unsurprisingly.”

Asahi Linux lead resigns from Mac-based distro after tumultuous kernel debate Read More »

popular-linux-orgs-freedesktop-and-alpine-linux-are-scrambling-for-new-web-hosting

Popular Linux orgs Freedesktop and Alpine Linux are scrambling for new web hosting

Having worked “around the clock” to move from Google Cloud Platform after its open source credits there ran out, and now rushing to move off Equinix, Tissoires suggests a new plan: “[H]ave [freedesktop.org] pay for its own servers, and then have sponsors chip in.”

“Popular without most users knowing it”

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.

Like X.org/Freedesktop, Alpine is using this moment as a wake-up call. Responding to Ars, Carlo Landmeter, who serves on Alpine’s council, noted that Alpine Linux is a kind of open source project “that became popular without most users knowing it.” Users are starting to donate, and companies are reaching out to help, but it’s still “early days,” Landmeter wrote.

Every so often, those working at the foundations of open source software experience something that highlights the mismatch between a project’s importance and its support and funding. Perhaps some people or some organizations will do the harder work of finding a sustaining future for these projects.

Ars has reached out to Equinix and X/Freedesktop and will update this post with responses.

Popular Linux orgs Freedesktop and Alpine Linux are scrambling for new web hosting Read More »

wine-10.0-brings-arm-windows-apps-to-linux,-still-is-not-an-emulator

Wine 10.0 brings Arm Windows apps to Linux, still is not an emulator

The open source Wine project—sometimes stylized WINE, for Wine Is Not an Emulator—has become an important tool for companies and individuals who want to make Windows apps and games run on operating systems like Linux or even macOS. The CrossOver software for Mac and Windows, Apple’s Game Porting Toolkit, and the Proton project that powers Valve’s SteamOS and the Steam Deck are all rooted in Wine, and the attention and resources put into the project in recent years have dramatically improved its compatibility and usefulness.

Yesterday, the Wine project announced the stable release of version 10.0, the next major version of the compatibility layer that is not an emulator. The headliner for this release is support for ARM64EC, the application binary interface (ABI) used for Arm apps in Windows 11, but the release notes say that the release contains “over 6,000 individual changes” produced over “a year of development effort.”

ARM64EC allows developers to mix Arm and x86-compatible code—if you’re making an Arm-native version of your app, you can still allow the use of more obscure x86-based plugins or add-ons without having to port everything over at once. Wine 10.0 also supports ARM64X, a different type of application binary file that allows ARM64EC code to be mixed with older, pre-Windows 11 ARM64 code.

Wine’s ARM64EC support does have one limitation that will keep it from working on some prominent Arm Linux distributions, at least by default: the release notes say it “requires the system page size to be 4K, since that is what the Windows ABI specifies.” Several prominent Linux-on-Arm distributions default to a 16K page size because it can improve performance—when page sizes are smaller, you need more of them, and managing a higher number of pages can introduce extra CPU overhead.

Asahi Linux, the Fedora-based distribution that is working to bring Linux to Apple Silicon Macs, uses 16K pages because that’s all Apple’s processors support. Some versions of the Raspberry Pi OS also default to a 16K page size, though it’s possible to switch to 4K for compatibility’s sake. Given that the Raspberry Pi and Asahi Linux are two of the biggest Linux-on-Arm projects going right now, that does at least somewhat limit the appeal of ARM64EC support in Wine. But as we’ve seen with Proton and other successful Wine-based compatibility layers, laying the groundwork now can deliver big benefits down the road.

Wine 10.0 brings Arm Windows apps to Linux, still is not an emulator Read More »

join-us-tomorrow-for-ars-live:-how-asahi-linux-ports-open-software-to-apple’s-hardware

Join us tomorrow for Ars Live: How Asahi Linux ports open software to Apple’s hardware

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.

View livestream

Add to Google Calendar

Add to calendar (.ics download)

Join us tomorrow for Ars Live: How Asahi Linux ports open software to Apple’s hardware Read More »

code-found-online-exploits-logofail-to-install-bootkitty-linux-backdoor

Code found online exploits LogoFAIL to install Bootkitty Linux backdoor

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.

Code found online exploits LogoFAIL to install Bootkitty Linux backdoor Read More »

removal-of-russian-coders-spurs-debate-about-linux-kernel’s-politics

Removal of Russian coders spurs debate about Linux kernel’s politics

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

Removal of Russian coders spurs debate about Linux kernel’s politics Read More »

north-korean-hackers-use-newly-discovered-linux-malware-to-raid-atms

North Korean hackers use newly discovered Linux malware to raid ATMs

Credit: haxrob

Credit: haxrob

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.

North Korean hackers use newly discovered Linux malware to raid ATMs Read More »

thousands-of-linux-systems-infected-by-stealthy-malware-since-2021

Thousands of Linux systems infected by stealthy malware since 2021


The ability to remain installed and undetected makes Perfctl hard to fight.

Real Java Script code developing screen. Programing workflow abstract algorithm concept. Closeup of Java Script and HTML code.

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.

Other discussions include: Reddit, Stack Overflow (Spanish), forobeta (Spanish),  brainycp (Russian), natnetwork (Indonesian), Proxmox (Deutsch), Camel2243 (Chinese), svrforum (Korean), exabytes, virtualmin, serverfault and many others.

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.

Photo of Dan Goodin

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.

Thousands of Linux systems infected by stealthy malware since 2021 Read More »

linux-boots-in-4.76-days-on-the-intel-4004

Linux boots in 4.76 days on the Intel 4004

To pull oneself up by one’s bootstraps —

Historic 4-bit microprocessor from 1971 can execute Linux commands over days or weeks.

A photo of Dmitry Grinberg's custom Linux/4004 circuit board.

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.

Linux boots in 4.76 days on the Intel 4004 Read More »

real-time-linux-is-officially-part-of-the-kernel-after-decades-of-debate

Real-time Linux is officially part of the kernel after decades of debate

No RTO needed for RTOS —

Now you can run your space laser or audio production without specialty patches.

CNC laser skipping across a metal surface, leaving light trails in long exposure.

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.

Real-time Linux is officially part of the kernel after decades of debate Read More »

neofetch-is-over,-but-many-screenshot-system-info-tools-stand-ready

Neofetch is over, but many screenshot system info tools stand ready

Pics or it didn’t compile —

Dev behind a popular screenshot tool checks out, but the successors are good.

Four terminal windows open to different system information fetching tools

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.

Listing image by Kevin Purdy

Neofetch is over, but many screenshot system info tools stand ready Read More »