It's FOSS reports: Asahi Linux is the reason you can run Linux on an Apple Silicon Mac today. For years, the project put most of its own code under the MIT license so that anyone, including the BSDs, could reuse it as needed... They have announced that Asahi is moving all of its repositories to the GNU General Public License version 2 or later. Going forward, all Asahi Linux code will be under strong copyleft licenses only.
Asahi Linux compares their dilemma to the 1990s, when "permissively licenced projects were viewed by tech companies as free real estate to pilfer and exploit," adding that "Those who do not learn from history are doomed to repeat it... The malicious practices of the 90s and 2000s have reared their ugly heads once again, this time driven in large part by both the insatiable appetite of frontier AI labs for high-quality training data, and militant animosity toward the Free Software community." In short, they argue that for Asahi Linux, using the permissive MIT license "is no longer viable." Some time ago, we were made aware of multiple attempts to exploit our permissive licensing to hijack our work, with a direct view to replacing the project and aggressively monetising Linux on Apple Silicon. In some extreme cases, in-development feature code was being lifted straight out of our personal forks and published without attribution or lazily rewritten with LLM assistance to obfuscate its origin. The MIT licence explicitly allows this, and has no carveouts to protect against bad faith actors. As such, we made the difficult decision to begin the process of transitioning all of our repositories to the GNU General Public License version 2 or later. Going forward all Asahi Linux code will be licenced under strong copyleft licences only.
It's FOSS explains that "Under the GPL, anyone who distributes a modified version has to release the source under the same license. You can't legally build a closed, paid Apple Silicon distro on top of GPL code. And if a product's source has to be public, the copying is easier to spot."

And their article also points out that before AI, bad actors attempting code laundering "usually meant manually rewriting code line by line, renaming variables and stuff, and shuffling functions around until it no longer looked like the original. LLMs made it much more easy and cheaper of course." In case you did not know, Asahi Linux forbids AI generated code contribution... As far as I can tell, this is the first time a major open source project has moved to copyleft specifically because of AI-assisted code laundering. Projects have relicensed before, but usually to stop cloud providers from reselling their work as a service. This one is specifically about AI...

The move has drawn criticism, particularly from the BSD side, which was one of the main reasons Asahi chose MIT in the first place. OpenBSD's Apple Silicon support relies on Asahi's m1n1 bootloader.

"AlmaLinux OS charted a new path in 2023 when Red Hat restricted source code access to Red Hat Enterprise Linux," remembers Linux Magazine. "Rather than pursue 1:1 compatibility with RHEL like other Enterprise Linux alternatives, the AlmaLinux OS Foundation chose application binary interface (ABI) compatibility, which guarantees that applications and kernel modules that work on RHEL will work on AlmaLinux OS." No longer constrained by the 1:1 promise, AlmaLinux can offer new features, or add back deprecated ones, while still remaining a stable, drop-in replacement for RHEL... The release of AlmaLinux OS 10.2 in May 2026 reveals just how far AlmaLinux has come....

When RHEL 10 increased the x86-64-v2 architecture baseline to x86-64-v3, many older server platforms (and some new ones) were left in the lurch. These older servers couldn't support the modern CPU feature sets in x86-64-v3, including AVX2 CPU instructions. AlmaLinux recognized that many community members employed older hardware that relied on x86-64-v2. While x86-64-v3 is enabled by default in AlmaLinux OS 10 and AlmaLinux OS Kitten 10, an additional x86-64-v2 build is also available. The x86-64-v2 build works best for environments that rely on standard OS packages or that can rebuild any additional packages required by x86-64-v2. For users with older hardware, the additional x86-64-v2 build allows continued use of current hardware, saving money and keeping servers from the landfill. AlmaLinux OS 10 is actively supported through 2030 with security support through 2035, significantly extending the life of older hardware....

Many legacy applications and containerized workloads still run on i686, a 32-bit computer processor architecture belonging to the Intel x86 family, including software that only ships as i686, CI pipelines that require a specific 32-bit glibc, and seemingly normal looking containers that require a 32-bit environment. RHEL 10 completely removed 32-bit application support and multilib libraries after deprecating support in earlier releases... AlmaLinux OS 10.2 has added package repos and official container images for 32-bit x86 (but not a 32-bit kernel or installer)...

NVIDIA GPUs, ubiquitous in modern computing, have been a pain point for Linux users. Getting the closed-source NVIDIA drivers has required extra steps and manual installation. When NVIDIA released an open source version of their graphics driver, AlmaLinux integrated the drivers, along with the associated CUDA components, into the AlmaLinux repository starting with AlmaLinux OS 9 and 10. AlmaLinux also signs the open source drivers, allowing secure boot with the NVIDIA drivers they ship. Unlike RHEL users, AlmaLinux users now have native support, allowing them to skip manual installation. AlmaLinux users can now enjoy a fully integrated NVIDIA experience.
In addition, "Thanks to ABI compatibility, AlmaLinux can sometimes deliver patches more quickly than RHEL," the article points out. And it lists other points where AlmaLinux OS 10.2 diverges from RHEL 10:

• Re-enabling frame pointers disabled by default in RHEL and CentOS Stream to provide system-wide, real-time tracing and profiling to diagnose and optimize code.
• Enabling both kernel and userspace components that allow installation of AlmaLinux on a Btrfs filesystem
• Adding SPICE support dropped in RHEL 9, allowing users to interact with a virtual machine's desktop remotely instead of just from the host server.
• Restoring support for older storage and network drivers disabled upstream, including Adaptec, Dell PERC, HP, Mellanox, QLogic, Emulex, LSI, and Broadcom.

OpenAI says its new GPT-6 Cyber model helped an automated system identify 1,724 security flaws in the Linux kernel and exploit 948 of them to gain administrator-level access during testing, including at least 10 previously unknown techniques. Axios reports: During testing, the system identified 1,724 security flaws and found ways to use 948 of them to gain administrator-level access to Linux systems for about $1.2 million in API credits. At least 10 of the techniques the model used were previously unknown, according to OpenAI. Human researchers reviewed the Linux findings before reporting vulnerabilities and proposed fixes to maintainers. The model also uncovered 81 previously unknown, high-severity flaws in Mozilla's Firefox browser.

A newly disclosed OpenSSH flaw dubbed "*sshole" can allow attackers to log in to password-disabled accounts on certain musl-based Linux systems simply by submitting a password longer than 256 bytes. "Apparently certain varieties of musl Linux (Alpine, OpenWrt, Buildroot, Yocto, etc.) have had this OpenSSH vulnerability for about a decade," writes longtime Slashdot reader AlteredEgg. "Upgrade now!" BleepingComputer reports: Security researcher Ozgun Kultekin, who discovered and released details on the vulnerability today, says the flaw has existed since 2016 and stems from how OpenSSH handles password verification errors on systems using the musl C library. Linux accounts can be configured to prevent password logins by replacing their password hash with an asterisk (*) in the /etc/shadow file. Because this is not a valid password hash, no password should allow access to those accounts. However, a patch introduced in OpenSSH in 2016 to fix a username enumeration vulnerability tracked as CVE-2016-6210 changed how OpenSSH handled accounts without usable password hashes.

To prevent attackers from identifying valid usernames through different response times, OpenSSH was modified to perform password hashing even when an account had no usable password hash, including accounts configured with * to block password logins. The problem is that the musl C library's crypt() function also returns * when password hashing fails, including when a submitted password exceeds its 256-byte limit. This means an attacker can submit an oversized password and cause OpenSSH to compare the returned * against the account's stored *, resulting in a successful login.

To be clear, the flaw does not allow attackers to bypass passwords on accounts with valid password hashes. [...] Admins who can't immediately install the update can mitigate the issue by turning off SSH password authentication with PasswordAuthentication no in their SSH server configuration and restarting SSH. Kultekin says admins can also check for signs of exploitation by examining SSH authentication logs for password-based logins for accounts that should not allow them.

SUSE plans to cut roughly 10% of its 1,900-person workforce, with CEO Dirk-Peter van Leeuwen saying "automation and AI" are reducing the need for some roles and allowing the open source software company to operate with less overhead and flatter management structures. "We are announcing a reduction of SUSE's global workforce of approximately 10 percent," said Van Leeuwen in an email. "These decisions are painful for our people, our culture, and our open source community, but they are necessary for us to adapt and build a sustainable, resilient SUSE for the long term." The Register reports: Van Leeuwen says the business, bought by Swedish private equity provider EQT, decided to cut jobs after scrutinizing its "future strategy, required capabilities, and team structures." The rest of the organization will get a look at the fiscal year 2027 strategy on November 16. He said in the message to staff: "What is clear is that automation and AI are fundamentally shifting how software companies operate. AI capabilities are advancing exponentially, forcing us to radically reimagine our work. We have seen this trend already both inside our sector and in the wider economy. This means that the organizational design and cost base that SUSE is built on today will not carry us forward successfully.

"We are adapting. Across SUSE, modern tooling is already changing our daily workflows, enabling teams to move faster with less operational overhead and flatter reporting lines. The requirement for some existing roles has greatly diminished. Other roles will evolve over the next few years. This means we are accelerating investments in high priority areas, and deprioritizing others. These are hard, painful decisions to make, but necessary for our future."

[...] The specific roles at risk of redundancy were not outlined but SUSE claims it has considered where the people in those positions are "able to evolve, what they can stop doing, what they need to do more of - and decisions have been made on that basis." Staff caught up in the redundancies will be informed by November 4, employee representatives nominated the following day, and one to one meetings will begin at the start of next week. Van Leeuwen says in the internal memo that the job cuts are a "reflection of shifting organizational needs, not your talent or commitment. You have tackled hard infrastructure and open source challenges that power critical enterprise systems around the world. "Any organization will be fortunate to have your expertise."

From the blog It's FOSS Gregory Kurtzer is no stranger to the Linux world. He created CentOS, and when Red Hat messed it up, he started Rocky Linux as the community replacement. He also co-founded CIQ, the company offering enterprise support around Rocky. His latest project has nothing to do with rebuilding another Linux distro, though. He has built an entirely new operating system kernel, and he didn't write most of the code himself. An AI agent did.

Meet Ginux, Linux userspace without Linux underneath... It's an independent, Rust-first x86-64 kernel. Which simply means it is NOT a fork of the Linux kernel. It has its own memory management, scheduler, process model, filesystems, networking, and device support, all written from scratch.

The most interesting part is that even though it is not Linux, it is Linux-compatible. Ginux implements the Linux ABI (the binary interface compiled programs use to talk to the kernel), so existing Linux binaries can run on it unmodified. In the project's own terms, Linux is a "personality" that Ginux exposes, not the kernel running underneath...

Right now, Ginux runs only in a QEMU virtual machine, with no physical hardware profile, no GPU or NVMe support, and no independent security audit.

"On a Git commit basis, the Linux 7.4 merge window has been the busiest on record," writes Phoronix," with 19,671 commits since Linux 7.3: As of this morning in Linux Git ahead of v7.4-rc1, the kernel source tree is up to 41,605,120 lines. That's from 5,193,578 blank lines, 4,993,604 lines of comments, and 31,417,938 lines of detected code. Or nearly half a million lines of code added during the Linux 7.4 merge window, ignoring comments and blank lines [as detected by cloc ].
A historical graph of commits shows a clear spike for Linux 7.4, which Phoronix argues shows the definite recent uptick due to AI/LLM activity." With Linux kernel maintainers being "completely overwhelmed" due to both AI generated bug reports and patches/fixes, the Git commit activity has been surging as a result... The upward trend has continued building the past several kernel releases. Typically the merge windows saw 13~14k commits or less and now we are pushing 20k....

Linux 6.14: 10,034
Linux 6.15: 13,568
Linux 6.16: 13,805
Linux 6.17: 12,289
Linux 6.18: 12,910
Linux 6.19: 13,229
Linux 7.0: 12,468
Linux 7.1: 13,963
Linux 7.2: 14,395
Linux 7.3: 16,267
Linux 7.4: 19,671
And "we could still see a few more trickle in today for Linux 7.4 ahead of the expected Linux 7.4-rc1 kernel release later in the day."

UPDATE: "People are expecting 7.4 to be the next long-term support release," Linus Torvalds wrote today in his weekly state of the kernel update, saying that's also "another independent reason why some releases tend larger than others. So it may not *just* be the flood of AI patches."

The Register reports: Torvalds also seems not to be completely convinced that all AI submissions are entirely helpful, by describing this release as "Large, and full of fixes for issues found by AI (and more and more the patches have been suggested by AI too, although they often get rewritten)."

"EMACS, the mother of all editors, turns 50!" writes Slashdot reader dr_jerry, sharing a report from MIT Technology Review: Programming used to be a very different experience from the one we know today. In fact, the first programmers didn't write code at all; the six women who worked on the ENIAC, one of the world's first computers, at the University of Pennsylvania in 1946 did it by physically configuring switches, cables, and plugboards.

A few years later, MIT engineers programmed the Whirlwind by punching code onto paper tape that was then loaded into the computer's memory -- making it among the first "stored-program" machines. Later, they and others moved on to punch cards, one for each line of code.

By the early 1960s, programmers with interactive computers could use a "line editor" to type their code on teletypes -- large, noisy keyboard-and-printer machines. They'd type one line of code at a time, and their work would be saved on a spinning hard disk the size of a modern washing machine. But there was still no such thing as the now-familiar full-screen text editors that allow programmers to see and modify many lines at a time on a display.

One of the first such tools, EMACS, turns 50 this year, and it is still widely used. EMACS first ran on the early video terminals at the MIT Artificial Intelligence Laboratory in 1976, but its core concepts were so powerful that it was rewritten for many operating systems in the decades that followed. Apple even distributed it with Mac OS X. Beyond that, the software-sharing community that started around EMACS helped give rise to the modern-day free software movement and the GNU/Linux operating system.

"As of today in systemd Git it's now possible for the systemd programs to be written in the Rust programming language as an alternative to C," reports Phoronix: Core systemd code like the systemd library doesn't yet support Rust code, but for the various systemd programs / leaf components there is now support for using Rust... The new systemd-keyring-setup utility in Rust is used for provisioning keyrings and enrolling X.509 certificates into the kernel's dm-verity / fs-verity / BPF keyrings during the boot process while dealing them afterward. This systemd-keyring-setup code hasn't been merged yet but is expected soon now that the Rust infrastructure has landed. Originally it was all part of a single big commit before being split-up for the Rust enablement, systemd-keyring-setup, and other preparations for this new component.

Systemd developers aren't planning on porting existing C code to Rust, all the Rust code is built with Meson [no Cargo usage], and C linkage only is mandated.

Systemd Rust components come out slightly larger than C with a test program being 32KB compared to 20KB for its C twin. For now at least the systemd Rust support is optional and toggled by the -Drust= Meson option with it being auto by default.

BeamFS creator Aurelien Desbrieres is not calling for a merge, but is requesting feedback on an 18-patch proposal that takes the place of FTRFS, an earlier filesystem he proposed in April.

The Linux/Open Source blog It's FOSS reports: Filesystems that can repair damage, like Btrfs and ZFS, usually do it by falling back on a spare copy of the data. BeamFS skips that and stores Reed-Solomon error-correcting codes inside every block. Every read gets checked against those codes, and small amounts of damage are corrected before the data reaches the application. If the filesystem can tell the damage is beyond repair, the read fails with an error instead of returning the wrong bytes...

In his technical report, ext4 and ext3 returned wrong data without any error, while Btrfs refused to read the file. BeamFS returned the correct file every time except once, when a flip hit a pointer to the file's data and it refused the read.
"Aurelien says he used Anthropic's Claude to write the code, the tool that checks the patches, and the cover letter..."

Trend Micro's Zero Day Initiative appears to have accidentally disclosed several unpatched Linux kernel vulnerabilities on the public LKML instead of the private security list, including two CVSS 9.0 flaws that could enable remote code execution through SMB Direct and KSMBD. "This seemingly was a mistake with Linux's second-in-command Greg Kroah-Hartman responding to each report asking about their submission to the public mailing list," adds Phoronix. The newly-disclosed vulnerabilities include: ZDI-CAN-33549 as a CVSS 9.0 scored vulnerability for SMB Direct remote code execution vulnerability due to integer underflow. For this one there is a patch in a Git branch of code intended for Linux v7.5 but now presumably will be expedited for getting to mainline.

ZDI-CAN-33774 as a KSMBD race condition that can lead to remote code execution. Another CVSS 9.0 rated vulnerability.

ZDI-CAN-33367 is a vulneravbility for skbuff skb_zerocopy in the network code that can lead to local privilege escalation. For this one Linux kernel developers received a security report from another source last week over the same issue and a patch is expected to be posted soon.

ZDI-CAN-34068 as a VMWGFX VMware graphics driver bug with an out-of-bounds write leading to local privilege escalation.

ZDI-CAN-34076 an uninitialized resource in the NVMET code leading to information disclosure.

ZDI-CAN-32005 was also posted to the mailing list a day prior for a search-domain TCP query stack buffer overflow leading to local privilege escalation.

AMD has published Linux kernel patches for an official Ryzen overclocking driver that allows users to adjust CPU power and current limits through a firmware interface exposed via sysfs. Phoronix reports: AMD engineer Shyam Sundar S K posted the patches for the AMD Overclocking "AOD" WMI driver as an interface to the platform firmware for managing overclocking and power/current limits of modern Ryzen CPUs.

The driver in its initial form allows setting via sysfs a number of CPU tunables including the Package Power Tracking (PPT), Thermal Design Current (TDC), and Electrical Design Current (EDC) limits along with reading their supported range. SMT toggling can also be done via the interface as an alternative to the likes of Linux's "nosmt" option in disabling SMT at the platform level rather than kernel disabling. The current memory clocks can also be read via this AOD driver.

The power tunables aren't applied in real-time but go into effect at next reboot. The firmware does support many more commands compared to the few initially wired up and hopefully in time more of these controls will be enabled with this driver.

Linux maintainers "have ruled that people no longer have to declare their LLM usage," reports XDA Developers, "as Torvalds himself calls a ban on AI 'utterly stupid.'" The first part of this story comes via a message sent to the Linux mailing list. It announces one of the major changes decided during the Maintainers Summit on October 8, 2026, in Prague, Czechia, where submissions to the kernel no longer need to use the "Assisted-by" tag... meaning that people can submit AI-generated code without needing to declare it as such.

In some correspondence regarding concern about this new disclosure removal, the creator of Linux, Linus Torvalds, made his thoughts known... [Torvalds] compares an AI ban to getting rid of text editors, as doing so would prove that someone could write a good commit message without making any mistakes. He then rounds off his argument by asking, "Do you not see how UTTERLY STUPID those kinds of rules would be?" and stating that he simply expects the people working on the Linux kernel to "understand what they are doing."
Here's the last line of Torvalds' post. "Quite honestly, in my experience, the people I respect and call intelligent are not the ones that shy away from using new and interesting tools."

In a related story, Torvalds says he's used AI to help him understand patches that were hard to follow. And this week Torvalds even posted an LLM-assisted patch, reports Tom's Hardware: The development branch purports to fix an old issue with massive cache contention when many CPUs are reading the same file — a scenario potentially encountered when using shared libraries, databases, and web servers. Several developers had already made attempts over the years at fixing the issue, all with varied results, none quite ideal as an all-encompassing solution... He's now posted his solution in a development branch, and claims that he's seen a 23x performance improvement in a dedicated synthetic benchmark, though he notes that actual real-world impact will be far less significant, as "no real load" will witness those figures.
Torvalds used Anthropic's Claude Code, reports The New Stack, and "said the assistant wrote the implementation, tests, and initial documentation, and reviewed the code under his direction. He ran the benchmarks himself, despite having previously criticized developers for claiming AI writes 99% of their code." Tuesday Torvalds submitted a 10-patch series.

"Reviewers have since identified a race condition and raised concerns about memory reclamation," adds The New Stack. "Torvalds has handed further development to Kiryl Shutsemau, a Linux kernel developer who previously worked on the same bottleneck."

Valve has released a new Steam Client beta that finally moves the Linux client to 64-bit architecture, while also placing it inside a containerized Steam Runtime environment. However, Linux users still need 32-bit libraries and graphics drivers for compatibility, meaning fully 64-bit-only systems remain unsupported. VideoCardz.com reports: Valve's updated requirements explicitly state that 64-bit-only installations are not supported. Systems must still provide both 32-bit and 64-bit libraries and graphics drivers, including multilib support. The new client also requires Linux kernel 5.6 or newer and glibc 2.31 or newer.

The update also introduces Steam Achievement Sets, a feature we covered earlier that allows developers to organize achievements into separate groups for base games, DLCs and seasonal content. Players can complete individual sets without losing their existing completion status when developers add more achievements. Valve has also updated the achievements page to display progress across these groups.

The 64-bit Linux client and Achievement Sets are currently available through the Steam Client Beta. Valve has not confirmed when these changes will reach the stable Linux release. Until then, users on the regular Steam client will continue using the existing architecture.

An anonymous reader quotes a report from Phoronix: The feature-packed and polished Plasma 6.8 KDE desktop is now available. Making this release all the more special is that it coincides with the 30th anniversary of the KDE project. KDE Plasma 6.8 ships many exciting improvements including vRAM usage optimizations, dwell clicker support on Wayland, Wayland commit-timing protocol support for KWin, improvements for the Union theme engine, better remote desktop support, multi-GPU handling improvements, the new kscreenctl tool, server-side drop shadow support, multi-monitor improvements, and a lot of other polishing throughout. Especially from the Wayland angle there has been a lot of polishing and fine tuning for Plasma 6.8. Accompanying the release is a new film, The KDE Documentary, which "tells the story of the pioneering open source community that gave computer users a free and open alternative to proprietary desktops like Windows." The documentary is available to stream for free on YouTube.