Roastidio.us Tagged with linux

Clean your Mac & Windows/Linux PC with Disk Space – SOS

Wed, 16 Sep 2026 04:07:11 +0000

TLDR: Download the best disk cleanup app in existence from diskspace.io. A fun experiment in writing the same app three times (well kind of 4 times) with AI, and being as optimised and OS native as possible.

My Mac recently filled its 1TB drive and my quest to find out where the space had gone was very frustrating. The existing tools for tracking down disk space were slow, clunky and it was impossible to use them until their 30 minute crawl of my hard drive completed.

I decided to fix this by building a new app called Disk Space, which takes the great features of my favourite old time app Disk Inventory X, makes it blazingly fast and adds much improved file/folder deletion aesthetics so that you can clean up safely and quickly, as well as highlighting recently created files so you can find what changed more quickly.

Let’s get nerdy

The three versions, Mac, Windows and Linux, are all mostly independent, with just a little shared C++ code. My goal was to make each app as small, fast, as native to its environment as possible. This meant not using any of the more common cross platform libraries, and leaning on Claude to do the work.

MacOS

The MacOS version of Disk Space is written fully in Swift, with no dependencies on other libraries. This was the first version I built. It detects how many CPU cores your machine has and optimises itself to maximise the throughput. The size of the installed app is just under 1MB, with about 300KB of that being multiple sizes of the icon, so the app itself is just over 600KB in size. Not bad!

Releasing desktop apps for the Mac is actually not too bad an experience. You can choose to put it in the App Store, but then it can be a pain to release a new version. Apple offer a free notarisation service that signs the built app with your Apple Developer credentials, and it works well. For this reason, you can simply download the MacOS version of Disk Space from the site.

Windows

The Windows version is a direct port of the Swift code to C++. Similar to the MacOS version it optimises its operation based on the number of cores, but it also checks if the drive being scanned is a spinning disk or a solid state drive. If it’s a spinning disk there’s no point running many threads against it, it’s physically incapable of responding, so it caps the number of threads. Since it it just pure C++ with no dependencies pulled in, the installer is just about 600KB, pretty cool.

Releasing apps on Windows these days generally means you are forced to either release through the Microsoft Store or pay for quite expensive yearly fees to have your app notarized. Without this, the user will be shown very scary warning dialogs, making the app very hostile to use. Since this is a small free app, I went the Microsoft Store route.

Linux

The Linux version shares some of the C++ with the Windows version, especially the code that draws the multi-coloured tree map on the right. Similar to the Windows version, it checks the hardware of your storage to best optimize itself and otherwise builds the UI using Linux native code with almost not dependencies. The first version Claude recommended depended on the GTK libraries for the UI, which was convenient, but it meant that using the app on any system that didn’t include those libraries would force the user to download hundreds of megabytes just to get a 500KB app running. Luckily, within an hour Claude had completely rewritten the app to be almost fully self contained.

This means that the Linux app, which is packaged as an AppImage file, is just about 600KB all in, and you can simply download it from the site.

Epilogue

This was a fun experiment in building an identical app for all three operating systems while keeping it as native and optimised as possible. The hardest part was the hardware setup required for testing.

I now have on my desk:

My MacBook Pro (my primary machine). I do most of my work on this, run Claude and do all testing of the MacOS app.
A small but powerful Windows Desktop. This is pretty great, as not only can Claude build and test Windows apps on it, it can also build and test (to some degree) Linux apps too. I use this as the main machine for those two operating systems.
An ancient, 2009 MacBook Pro 17″ that I installed Linux on just for building this app. I use this for testing the Linux version on a real machine, not just on Windows WSL. It works relatively well, but with just 4GB of memory I won’t be doing any development on it any time soon. Still, it’s great to make use of the old hardware instead of throwing it away – I knew there was a reason I hung on to it!
… a lot of messy crap I need to tidy up. Any day now….

I can’t believe you read this far, thanks! Now go get Disk Space from diskspace.io, your hard drive will thank you 🙂

Switching to GNU Guix: a beginner’s perspective

Tue, 15 Sep 2026 23:42:32 +0000

Want to run something a little more exotic on your server? How about GNU Guix?

It has been a month since migrating my home server to GNU Guix. Managing OS state declaratively through Git has eliminated configuration drift, and Guile Scheme provides a cohesive environment that complements Emacs. While adapting to a smaller package ecosystem and managing substitute timing requires occasional adjustments, the stability, reproducibility, and container isolation make it a dependable foundation.
↫ Wai Hon

I’m definitely noticing an increase in interest in Guix lately.

Network Subsystem | Internals for Interns

Tue, 15 Sep 2026 21:45:20 +0000

At the end of the previous article we watched a module fill in a struct net_device_ops (include/linux/netdevice.h:1436), hand it to register_netdev() (net/core/dev.c:11531), and walk away. That’s a promise: here are my function pointers, call me when you need the hardware. What we never got to see is the other half of the promise — who calls them, and what happens in between the wire and your program.

So let’s go look. We’re going to follow one packet all the way in, and then one packet all the way back out.

The setup is deliberately boring. A server is listening on port 8080 on your machine, blocked in recv(), waiting. Somewhere out on the network a client sends a small HTTP request, which gets wrapped into a TCP packet, travels across the internet, and eventually arrives at your machine’s network card. Several stops later, recv() returns with that request in a buffer. Then the server writes a reply, and the whole thing runs backwards.

📌 A note on scope
Everything here is against Linux 7.1, following IPv4 and TCP over Ethernet. And as always, this is a deliberate simplification: some things I’ve flattened out, and a few I’ve left out entirely.

Before we start walking, let’s be clear about what it is we’re following.

Four layers, four headers

If you’ve written socket code most of this will be familiar, but it’s worth stating plainly, because the shape of the stack is the shape of this article.

Start with the part that catches people out: the kernel has no idea what HTTP is. It never sees a request line, never parses a header. What it offers is a stream of bytes that arrives complete and in the right order; making those bytes mean something is the application’s job. Building that stream means wrapping the data in layers, each one solving exactly one problem and adding a header to record how it solved it:

Layer	The problem it solves	How it identifies it
HTTP	What do these bytes mean?	the application’s job, not the kernel’s
TCP	Which program does this go to, and did it all arrive in order?	port numbers, sequence numbers
IP	Which machine on the internet do we send it to?	IP addresses
Ethernet	Which device on this cable do we hand it to?	MAC addresses

So we have four layers, each solving one problem and leaving a header behind to record how it solved it. On the way out a packet picks them up one at a time; on the way in it sheds them the same way. That’s the shape of everything that follows — but let’s start at the beginning.

The arrival

So: the frame is on the cable your machine is plugged into. Never mind how it got there — at this point it’s just an electrical signal on the wire, and the card’s hardware is what turns that signal into bytes.

The very front of those bytes is the Ethernet header, starting with the destination MAC address. That’s the only question the card cares about right now: is this frame for me? It compares that address against its own, and if it doesn’t match, the frame is discarded on the spot and nobody is told — as far as your kernel is concerned, it never existed.

Ours matches. So what we have is a frame, addressed to us, sitting in a tiny buffer on the card, with the next frame possibly already arriving behind it.

And this is where the kernel starts getting involved.

How the card and the kernel share memory

Normally, when something happens out in the physical world, the way the hardware tells the operating system about it is an interrupt: the CPU stops what it was doing, and the kernel drops everything to go and deal with the event. That’s a perfectly good arrangement for a keypress, or a disk finishing a read. It falls apart completely when packets are arriving in their millions every second.

So network cards work a different way. Instead of announcing each packet and waiting to be served, the card and the kernel agree in advance to share some memory, and the card writes packets straight into it using DMA — direct memory access, where the device reads and writes RAM without the CPU moving a single byte. The data is delivered first, and the kernel is told about it afterwards.

Let’s look at how that’s arranged:

The card is on the left, holding our frame in that tiny buffer. Main memory is on the right. And the thing that joins them is the descriptor ring: a circular array of small records, living in main memory, that both sides read and write. Each record — a descriptor — is a small fixed-size struct, and the two sides take turns writing into it.

Two things are worth being precise about here. The first is that the descriptor’s layout isn’t the kernel’s to choose. It’s dictated by the hardware and written down in the card’s datasheet, field by field and bit by bit. Knowing it is a large part of what a network card driver is, and it’s why the driver has to be card-specific while everything above it isn’t.

The second is that the ring never holds packet data. Not one byte of our frame goes into it. A descriptor only ever describes a transfer. The frame itself lives in the pages underneath, and the descriptor just tells you where.

So that’s the arrangement: the driver keeps the ring stocked with pages mapped for DMA, and tells the card they’re there by ringing the doorbell — writing a slot number into a register on the card (the little box in the diagram) that means “everything up to slot N is yours”. That happens once at startup, and again every time the packets in some slots have been consumed and the driver has made those slots ready to receive more.

The card’s side of the bargain is the other direction. It DMAs the frame into one of those pages, writes the length and status back into the descriptor, and only then raises an interrupt.

And that interrupt doesn’t mean “here is a packet”, it means “there is traffic”. Interrupts for that queue then go quiet and the kernel polls the ring until it drains, so a whole batch of frames costs one interrupt instead of one each.

Turning that page of bytes into something the rest of the stack can work with takes one more object.

One object does all the travelling

That object is the sk_buff — the socket buffer, universally called an skb (include/linux/skbuff.h:886).

An skb is not the packet itself. It’s the packet’s paperwork: a metadata object holding a handful of pointers into the buffer where the bytes actually live. That separation is the point — a packet crosses several layers on its way through the kernel, and copying or shuffling its bytes at every handoff would be ruinously expensive, so what gets passed around is the skb, never the data. And the way those pointers move is the whole trick:

Look at the top strip first. head and end mark the memory that was allocated, and data marks where the packet currently begins. The hatched gap between head and data is the headroom — deliberately empty space, set aside in front of the payload before anyone has asked for it.

Let’s start by thinking about how the skb is built on its way out. It begins with the payload and some empty headroom in front of it, and as it travels down the stack each layer writes its own header into that space — TCP’s, then IP’s, then Ethernet’s. The payload is never copied and the buffer is never reallocated; the data pointer just moves backwards to wherever the packet now begins. Once the bottom layer is done, the whole thing goes out on the wire.

Coming in, it’s the same picture read from the bottom up. The headers are already there, and each layer handles its own and then moves data forwards past it, so the layer above receives an skb whose data points at exactly the header it cares about. Every layer only ever has to think about its own.

So our frame is in memory, wrapped in an object the kernel can hand from layer to layer and address one protocol at a time. Let’s follow it up the stack.

GRO: Generic Receive Offload

The obvious next move is to hand it up to IP — but the driver calls napi_gro_receive() (include/linux/netdevice.h:4286) instead.

Here’s why. Ethernet caps a frame at around 1500 bytes, so a 1 MB download turns up as some seven hundred separate packets. Taken one at a time, each has to climb the whole stack: IP checks it, routing looks at it, TCP finds the socket and queues the bytes. Seven hundred rounds of that, for what is really one lump of data chopped up for the journey.

So GRO — Generic Receive Offload — glues the pieces back together first. dev_gro_receive() (net/core/gro.c:474) hashes the flow, and if it’s already holding a packet from that same conversation, it asks whether the newcomer is a legal continuation: same addresses and ports, sequence numbers exactly adjacent, nothing odd in the flags. If so, the payload is tacked on as another page fragment and the new skb disappears.

A run of back-to-back segments therefore collapses into a single skb of up to 64 KB, which crosses IP and TCP once instead of forty-five times.

GRO read the headers, but only to work out what could merge with what. Nothing has yet decided where the packet actually goes.

Who does this packet belong to?

However it got here — merged with others or on its own — our skb now reaches __netif_receive_skb_core() (net/core/dev.c:5972), the device layer’s last act before the packet is handed to a protocol, IP in our case. It runs a fixed sequence of steps, always in the same order:

Housekeeping. Small fixups, like stripping off a VLAN tag if the card didn’t already do it.
The taps. Any socket that asked to see everything gets a copy right here. This is where tcpdump gets your packet — and note that it happens before any firewalling, which is exactly why tcpdump cheerfully shows you packets that iptables then drops.
tc and netfilter ingress. The first step that can actually intervene: BPF programs and traffic-control filters attached to the interface run here, and they may drop the packet or send it somewhere else entirely.
The rx_handler. A hook (include/linux/netdevice.h:2189) that lets a virtual device steal packets from a physical one. It’s how bridges, bonding and macvlan get their traffic before the kernel decides it was meant for this machine.
The protocol demux. And finally the actual question: what’s inside this frame, and who handles it?

That last step is how the packet reaches IP at all, and the mechanism is refreshingly plain. The Ethernet header ends with two bytes called the EtherType, which say what kind of packet is wrapped inside it. The kernel takes those two bytes and looks them up in a hash table of protocols that registered themselves at boot. IPv4 is simply one entry in that table (net/ipv4/af_inet.c:1881), saying “EtherType 0x0800 goes to ip_rcv”.

And if nothing matches? The packet is dropped with a named reason. That’s a habit worth noticing, because it’s everywhere in this stack: nearly every place a packet can die tags itself, so you can always find out exactly why something vanished.

Ours is 0x0800. Off to IP.

IP

ip_rcv() (net/ipv4/ip_input.c:603) starts with the unglamorous part: is this packet even real? Wrong version, truncated header, bad header checksum, a total length that doesn’t fit the buffer — dropped, each with its own reason code.

Next the packet goes through netfilter, the machinery behind iptables and friends. What’s interesting here isn’t what it does but the shape of the call: every netfilter hook takes, as its last argument, the function to call if the packet survives. You don’t ask the firewall for a verdict and carry on — you hand the firewall your continuation.

Assuming the packet lives, IP has one real question left: where is this going? Answering it means a route lookup — walking the routing table to work out whether this packet is for us or for somebody else, and attaching that answer to the skb as a dst_entry (include/net/dst.h:26).

There’s a shortcut, though. Before routing, IP looks up the socket — tcp_v4_early_demux() (net/ipv4/ip_input.c:322), and if it finds an established connection it borrows the route that socket already has.

Our packet is for us, so it’s handed to ip_local_deliver (net/ipv4/ip_input.c:250), which runs one more netfilter hook, strips the IP header off the front, and looks up the protocol number in a registration table — the same trick as the EtherType table, one layer up. Protocol 6 is TCP, registered to tcp_v4_rcv.

TCP

tcp_v4_rcv() (net/ipv4/tcp_ipv4.c:2068) checks the TCP checksum and works out which socket the packet belongs to, by looking up four numbers — source and destination address, source and destination port — in a table of open connections.

Right now we’re running in kernel code, kicked off by the card’s interrupt, and the data has to end up in the socket’s receive queue. The catch is that your program might be sitting in a syscall on that very socket at this moment — also in kernel code, also reaching for that same queue. The two of them have to coordinate, and the way they do it is the socket lock.

If nobody holds the lock, this code takes it and does TCP’s work straight away — sequence numbers, windows, ACKs, queueing the data — before your program has even woken up. If your thread is holding it, though, we can’t simply wait our turn: this is the kernel’s deferred packet-processing context, which isn’t allowed to sleep, and blocking here would stall packet processing for everyone else on the machine. So the packet is parked on the socket’s backlog queue, and the thread holding the lock inherits the job, doing it on its way back out of the syscall.

Either way the data ends up where it belongs, in tcp_data_queue() (net/ipv4/tcp_input.c:5574): bytes that arrived in order go onto the socket’s receive queue, ready to be read, and anything that arrived early — the packet after one that got lost — waits until the gap is filled.

Then somebody needs telling. TCP calls the socket’s sk_data_ready callback (net/core/sock.c:3614), which wakes anything sleeping on the socket. This is the wakeup that ends a blocking recv(), and the one that makes an epoll_wait() return.

`recv()` finally returns

All this time our server thread has been asleep — not spinning, not checking anything, just parked and taken off the run queue, waiting inside recvfrom(). The syscall had carried it into tcp_recvmsg() (net/ipv4/tcp.c:2931), which locked the socket, found nothing to read, and put the thread to sleep.

The wakeup we just fired puts it back on the run queue, and it carries on from exactly where it stopped: walk the receive queue to find the skb holding the next byte the application hasn’t read, copy those bytes into the buffer the application handed to recv(), note how far it has got, and free the skbs that are now fully drained.

One last thing happens on the way out, in release_sock() (net/core/sock.c:3819). Remember the backlog, where packets got parked because our thread was holding the socket lock? Those get processed now, in our thread, before the lock is released. Your application quietly pays the CPU cost of its own protocol processing, inside its own syscall.

And then recv() returns, with the request sitting in the application’s buffer. The journey in is over — and it’s worth seeing the whole of it in one picture before we turn around:

Notice how much of that column is spent working out who the packet belongs to — the MAC, the EtherType, the protocol number, the socket — and how little of it touches the data itself. The way back out inverts that completely. The destination is known from the very first line, and nearly all the work goes into deciding when to send.

The way out

Our server writes its reply — a short HTTP response — with send(). The thing to understand about the transmit path is that copying and sending are two separate steps: send() always does the first, and then asks whether to do the second.

tcp_sendmsg_locked() (net/ipv4/tcp.c:1117) looks at the tail of the socket’s write queue. If there’s an skb there with room left, it appends to it; if not, it allocates a fresh one (net/ipv4/tcp.c:927) — and the first thing that allocation does is reserve a couple of hundred bytes of headroom before putting any payload in. That’s the diagram from earlier, set up in advance: every header this packet will ever need — TCP, IP, Ethernet, any tunnelling in between — has already been paid for, right here, at copy time. Nothing further down the path will have to reallocate anything; each layer will just move the data pointer backwards into space that has been waiting for it. The skb is also marked as needing only a partial checksum, because the card will finish that job later, so nobody wastes cycles on it now.

Then the payload is copied in, from the user’s buffer into kernel pages attached to the skb, and the write sequence number advances. That’s the copy done. Whether any of it actually goes out is a separate question, and it gets asked next.

At the very end, tcp_push() (net/ipv4/tcp.c:741) decides whether to actually try transmitting, and it has a nice trick called autocorking: if there’s already data of ours queued further down that hasn’t gone out yet, don’t transmit at all. Mark the socket as throttled and return. The bet is that the application is in a write loop and the next send() will land in the same skb, turning several small packets into one bigger one — a bet the kernel wins constantly, because applications really do write in loops.

Sooner or later, though, the data does have to go out, and that decision is nowhere near a simple yes or no.

Deciding when to send

tcp_write_xmit() (net/ipv4/tcp_output.c:2963) walks the write queue and puts each skb through a series of gates. Any one of them can stop the loop dead:

Gate	The question it asks
Pacing	Is it too early to send this, at our current pacing rate?
Congestion window	Does the network have room for more unacknowledged data?
Receive window	Does the peer have room?
Nagle	Is this a small packet we should hold, hoping for more?
TSO deferral	Would waiting briefly let us build a bigger, cheaper segment?
Split to MSS	Is it too big for one segment, and needs cutting?
TCP Small Queues	Do we already have too many bytes in flight locally?

Six of those seven are classic TCP. The last one isn’t about the network at all. TCP Small Queues, or TSQ (net/ipv4/tcp_output.c:2856) caps how many bytes a single socket may have sitting in the local transmit queues.

When the limit is hit, the socket is marked throttled and transmission stops. Which raises the obvious question: who restarts it? Hold that thought.

Headers, added backwards

An skb that gets through all that reaches __tcp_transmit_skb() (net/ipv4/tcp_output.c:1529), which starts by cloning it. TCP can’t throw data away until the other end acknowledges it, so the original waits in the retransmit queue and only the clone goes down the stack — and since an skb is only paperwork, cloning copies the paperwork, not the bytes. Then the TCP header goes on, written into the headroom reserved back in sendmsg.

Here’s where the other half of TSQ gets set up, and it’s the half that answers the question we left hanging. Remember what it was about: capping how many bytes of one socket can be sitting in the local outbound queues at the same time. Somebody has to keep that count, and this is where it happens. Before sending the skb down, TCP adds its size to that count, and attaches a destructor to it: a function that will run when the skb is freed — which is to say, when the card has actually finished sending it. That function subtracts those bytes again and, if the socket had been throttled for hitting the limit, wakes it up to send more.

So what restarts a throttled socket isn’t a timer, and isn’t anything watching over it: it’s its own packets finishing. TCP transmits at the rate the card sets.

Past TCP, the packet drops a floor. ip_queue_xmit() (net/ipv4/ip_output.c:463) repeats the same move: take the route the socket already had cached, claim a bit more headroom, fill in the IP header.

And here something odd happens: often the packet is deliberately too big for the wire. TCP hands down one oversized skb carrying many packets’ worth of data and lets the card slice it up itself, so the stack gets walked once instead of forty-five times. That’s segmentation offload (GSO in general, TSO when the hardware does it for TCP), and if the card can’t, the kernel does the slicing in software further down.

Finally, ip_finish_output2() (net/ipv4/ip_output.c:200) turns “next hop 192.168.1.1” into a MAC address, which is what ARP is for. For a neighbour we’ve spoken to recently the whole 14-byte Ethernet header is already cached: it isn’t built, it’s memcpy’d (include/net/neighbour.h:507) into the headroom that is still sitting there from sendmsg. The packet is complete: Ethernet, IP, TCP, payload.

Nothing has left the machine yet, though. The finished packet still has to make it out to the card.

Sending to the card

__dev_queue_xmit() (net/core/dev.c:4766) is the device layer’s transmit entrance, and it mirrors what we saw on the way in: tc, netfilter and any BPF program attached to the interface get their shot at the packet, with the same power to drop it or send it somewhere else.

Then the packet joins a queue on its way out, and that queue is managed by a qdisc — a queueing discipline, the scheduler deciding what actually leaves and in what order.

Next, validation. validate_xmit_skb() (net/core/dev.c:4019) compares what the packet needs against what your card can actually do, and makes up the difference in software: slicing a big skb into wire-sized frames, flattening a payload spread across pages, computing a checksum. This is why the layers above could afford to be so relaxed — they build the packet they want, and this function reconciles it with whatever hardware you happen to own.

Then the driver. dev_hard_start_xmit() (net/core/dev.c:3894) hands a copy to anything listening to the whole interface — this is where tcpdump sees outgoing packets — and then calls into the network device driver.

The driver does the same dance as the receive ring, in reverse (for a real example, Intel’s igb does it here). The packet’s bytes may be scattered across a few pages, so for each of those pieces the driver asks the kernel for an address the card can use to reach it, and writes that address into a descriptor. Then it rings the doorbell: the same register write as before, this time saying “descriptors up to here are yours”.

And that’s the last the kernel sees of it. The card reads the descriptors, fetches the bytes, finishes the checksums, and puts frames on the cable.

Summary

Step back from the function names and the journey is fairly simple. A frame lands on the card, which writes it straight into a memory page the kernel handed over long beforehand, and only afterwards mentions that it did. The kernel wraps that page in an skb and passes it upward, each layer asking one question and answering it: is this frame mine, is this packet valid, whose connection is this, and is anybody waiting for these bytes? Somebody was — a thread asleep inside recv(), which wakes, copies the data out, and returns.

The way back out is the same journey inverted. send() copies your bytes into a queue and then asks whether anything should go out — a question answered by congestion, the receiver’s window, and how much of its own data is already queued locally. Often the answer is yes and the packet leaves inside the same syscall; when it’s no, the data waits. Then the headers go on backwards, into headroom reserved right at the start, and the driver rings a doorbell.

A few habits repeat throughout. Nothing copies the payload if it can avoid it. Nothing is hardcoded — protocols register themselves in tables rather than turning up in somebody’s switch statement. And nothing travels alone if it can help it, which is what GRO, GSO and the batched doorbell are all quietly doing.

Next time, something completely different: NUMA. On a machine with more than one socket, not all memory is equally close to every CPU, and the kernel has to take that into account both when it allocates memory and when it decides where to run things. We’ll see how it models that, and what it does with it.

Durable AI agent execution beyond terminal sessions · vincent

Tue, 15 Sep 2026 19:47:47 +0000

The terminal should not own the work

A terminal is a good place to start a process. It is a poor place to store the truth about that process.

When an agentic task belongs to one terminal tab, the tab becomes an accidental control plane. Closing it can stop the work. Losing scrollback can erase the useful explanation. Reopening the project means reconstructing what ran, which branch it changed, and whether it was waiting, finished, or quietly stuck. The longer the task runs, the more fragile that arrangement feels.

Vincent moves ownership into a background daemon. The daemon owns task state, workflow execution, agent processes, scheduling, the database, and git worktrees. The TUI, CLI, and API are clients of that state. Closing any client changes nothing about the work behind it.

That architectural choice has consequences that are easy to feel. I can start a task, close the TUI, use the terminal for something else, and return later to the same state and history. Several clients can inspect the same daemon without becoming competing writers. The scheduler can admit tasks by priority and concurrency limits even when nobody has a dashboard open.

Durability also changes how interruption is handled. Vincent persists a state transition before acting on it. If the daemon stops during a step, restart recovery records the interrupted attempt, verifies any orphaned process before stopping it, and runs the step again without consuming a failure retry. The system does not pretend that a process survives a machine restart; it makes the interruption explicit and recovers from known state.

Installing the daemon as a user service extends the same model across logins. The operating system starts the control plane, and the terminal returns to being what it should be: one optional window into the work.

This matters because agentic coding is increasingly a workload rather than a conversation. Tasks wait on quotas, gates, retries, child branches, and external checks. Their lifetime should not be coupled to the lifetime of the interface that launched them.

The terminal can show the work. It should not own the work.

Back to Why vincent is awesome · Understand the daemon

Finally: Some Pricing Information On The Power S1112 Entry Server

Tue, 15 Sep 2026 19:05:30 +0000

The entry “Bonnell+” Power S1112 server based on the Power11 processor – the only machine that has a P05 software tier for the IBM i operating system – has been shipping for six weeks now, and I have been digging around trying to get detailed, feature-level pricing for the new machine. I have yet to find that fine-grained pricing that I love to have my hands on, but I did get some help from some friends in the reseller community to get current prices for six different configurations of the Power S1112 – two tower configurations and four rack configurations. …

The post Finally: Some Pricing Information On The Power S1112 Entry Server appeared first on IT Jungle.

Any Nix package, live in your browser

Tue, 15 Sep 2026 12:08:27 +0000

Any Nix package, live in your browser

Farid Zakaria calls this his "magnum opus of Nix work", and I can see why.

trynix.dev provides a qemu-wasm powered x86_64 Linux virtual machine running entirely in your browser through WebAssembly. That VM can then be booted with any Nix package from the past 13 years. They are URL addressable, so you can navigate to this page:

https://trynix.dev/?pkg=python3%403.6.2

Then click "Load" and get an interactive shell against a virtual machine running Python 3.6.2 from 2017.

Farid is building all sorts of neat things on top of this. One recent example: Review a pull request by booting it introduces trynix-preview, described like this:

GitHub action that comments a link on a pull request which lets you boot the PR’s build in the browser using https://trynix.dev. No servers, just browsers.

Via Lobste.rs

Tags: code-review, linux, webassembly, github-actions

Dropping eBPF CPU Cost by About 90% With Memoization (Not AI Gen) :: nathan naveen

Tue, 15 Sep 2026 04:41:46 +0000

My brother and I spent a lot of time designing our eBPF security agent to be really fast from the ground up, but recently we discovered we could make it much faster using memoization!

A couple of weeks ago, I profiled the eBPF code and found that the most expensive part of the protection isn’t actually enforcing a policy (allow/deny), but figuring out which policy applies to a given file open.

Our policies are path based, so our eBPF leverages an LSM hook that triggers on file open. We then reconstruct the path, walk up parent dentries, and check whether the file or any ancestor directory has a matching policy. While this works, it isn’t performant, and we end up repeating much of the work for files we have already seen (for example, database accesses that repeatedly reaccess file paths).

So, we cache which policy applies for each inode. This dropped our kernel CPU cost by about 90%.

Additionally, we recently open sourced our repo, so everything in this blog post can be found at https://github.com/bomfather/agent.

The Problem

Before the cache, every file open would walk through the entire path. So the flow would look like this:

Get the file path.
Walk up the file path with dentries.
At each level, check whether a policy exists for the path.
Then combine the results to get a final policy, which we can use to decide whether to allow or deny.

This works, but if the same file is opened multiple times or multiple files in the same subtree are opened, we have to repeat these steps for each file.

For example: In Postgres, if we only want Postgres to be able to touch /var/lib/postgres, we can have this example policy:

policies:
  - executable: "filepath = /usr/lib/postgresql/16/bin/postgres"
    can_access_dirs:
      - "/var/lib/postgres:read"

Then Postgres retrieves files from var/lib/postgres/data/base/123, var/lib/postgres/data/base/234, and var/lib/postgres/data/base/345. We would have to walk the entire path of dentries for each of these file accesses, which is really inefficient.

For the rest of this blog post, I’ll call this inefficient path walk “the slow path.”

What’s in the Cache?

Our solution is to use a cache. But we need to make sure the cache isn’t heavy and that it’s safe to reuse cached items.

We were thinking of using dentries, but dentries are pointers, and pointers can’t be stored inside eBPF maps. If we wanted to use dentries, we could store the dentries’ contents in a struct and use that struct as the map key, but it would be a pretty heavy struct.

So instead, we decided to use an inode based cache. Our cache key has three fields: the mount namespace ID, the mount ID, and the inode number.

We can’t cache the inode by itself because inode numbers are unique to a specific mount tree (so if a policy covers multiple mount trees, inodes could overlap). The mount ID helps us identify which mounted tree we observed the file through. The mount namespace ID also prevents us from using cached entries in a different namespace.

The cache value has two parts: an access_index and a cache state. We store our policies as bitmasks for space efficiency, and the access_index is the bit position for the path policy (https://nathannaveen.dev/posts/optimizing-ebpf-policies-for-speed-and-space/).

So, our cache, along with the keys and values, looks something like this:

#define INODE_POLICY_CACHE_NO_POLICY 0
#define INODE_POLICY_CACHE_ACCESS_INDEX 1
#define INODE_POLICY_CACHE_GLOBAL_READ_ONLY 2
#define INODE_POLICY_CACHE_ACCESS_INDEX_AND_GLOBAL_RO 3 

struct inode_cache_key {
    u64 mntns_id;
    u64 mount_id;
    u64 inode;
};

struct inode_policy_cache_value {
    u32 access_index;
    u8 state;
};

struct {
    __uint(type, BPF_MAP_TYPE_LRU_HASH);
    __uint(max_entries, 10000);
    __type(key, struct inode_cache_key);
    __type(value, struct inode_policy_cache_value);
} bomfather_inode_policy_cache SEC(".maps");

Now with the cache, our flow looks something like this:

We need to build the cache key.
We can look up the key in the LRU hash map.
If there is a hit, we can enforce the file open based on the cached result.
If there is a miss, we can do the slow path and store the result in the cache.

Performance Changes

In our benchmark tests, we opened the same file 200,000 times to analyze performance; the cache reduced kernel cycles from 28 billion to 3.03 billion. Without the cache, our tail_call_security_check appeared on the stack 89.2%, is_restricted_filepath 81.9%, and path_check_callback 63.7% of the time.

In the flamegraphs below, we can see that with the cache, the expense from path traversal pretty much disappears after the first lookup. For example, is_restricted_filepath and path_check_callback each shrink to roughly 0.02%, which is small enough to effectively disappear from the graph.

Before (without cache):

After (with cache):

We profiled the kernel CPU with perf using the cycles:k event. This measures kernel side CPU cost during file opens.

Edge Cases

One thing we had to account for with this cache is that multiple paths can share a single inode. Hardlinks are the easiest example; with a hardlink, two different paths can share the same inode. This is a big problem because accurate results matter more than cache performance.

Our solution is more of a workaround than a real solution. Inodes have a link count (i_nlink) that tells us how many paths point to the inode; we can read it, and if it is greater than 1, we don’t use that cache entry and fall back to the slow path.

if (BPF_CORE_READ_INTO(&nlink, inode, i_nlink)) {
    return false;
}

if (nlink != 1) {
    inode_cache_stats_inc(INODE_CACHE_STATS_SKIPS_NLINK);
    return false;
}

This is a trade off since we are giving up some cache coverage, but I don’t think it is too big a deal because having an accurate cache is most important.

Final Thoughts

In the end, this was a really fun thing to work on since I had to work through multiple different ideas for the cache until I landed on this.

I am also pretty happy the cache is entirely internal, so a user’s policy doesn’t need to change for the agent to speed up!

Setting up CachyOS on a ThinkPad T14s Gen 1 AMD with LUKS2, BTRFS, Limine and Sway

Mon, 14 Sep 2026 17:44:13 +0000

I wanted a boring laptop.

Not boring in the “old corporate machine with a dying battery” sense, although this is a ThinkPad, so there is always a bit of that. I mean boring in the useful sense: encrypted, recoverable, fast enough, boring to boot, boring to update, boring to suspend, and boring enough that I can stop thinking about the machine and start building things on it.

Naturally, this meant wiping the disk more than once.

This is a guide to setting up CachyOS on a ThinkPad T14s Gen 1 AMD with LUKS2, Btrfs subvolumes, a Btrfs swapfile for hibernation, Limine, Snapper, AppArmor, Sway, and Ly with the cmatrix animation, because if you are going to use a terminal display manager you may as well make it look slightly ridiculous.

This is based on the actual install I did, not the imaginary blog-post version where every decision was obvious before I typed the first command. The final setup worked out nicely, but I did change direction during the install. The original plan was a simpler encrypted setup. Then I looked more closely at the CachyOS Btrfs/Limine/Snapper path and decided it was worth doing properly.

The hardware

The machine is a ThinkPad T14s Gen 1 AMD:

ThinkPad T14s Gen 1
Ryzen 7 PRO 4750U
14 GiB usable RAM
WDC PC SN730 476.9G NVMe SSD

The final stack:

CachyOS
4 GiB EFI System Partition
LUKS2 encrypted root
Btrfs with CachyOS-style subvolumes
24 GiB Btrfs swapfile for hibernation
Limine bootloader
Snapper snapshots via limine-snapper-sync
AppArmor
Sway Wayland desktop
Ly display manager with cmatrix animation

This is not the absolute simplest Linux laptop install. If you just want something that boots, use the normal CachyOS installer and get on with your day. This guide is for the slightly more annoying case: a manual install with encrypted root, snapshot-friendly Btrfs, hibernation, and a minimal Wayland desktop.

Before you copy anything

This guide wipes the internal NVMe drive. In my case, the target disk was /dev/nvme0n1. Yours may not be. Check before running destructive commands.

If you copy and paste the partitioning commands without checking your disk names, you may have a very efficient data deletion experience.

Most commands are run from the CachyOS live ISO. Some commands require interactive passphrase entry and should be run directly on the laptop. I did some of the install over SSH using ssh cachy, but I have written the commands below as if you are typing them directly on the live system.

1. Verify the environment

Start by confirming the target disk and that you booted the installer in UEFI mode.

lsblk -o NAME,PATH,MODEL,SERIAL,SIZE,TYPE,FSTYPE,LABEL,MOUNTPOINTS
ls -d /sys/firmware/efi/efivars

Expected: the internal disk is /dev/nvme0n1, and /sys/firmware/efi/efivars exists. If you do not see EFI variables, stop and fix your boot mode before continuing.

2. Partition the disk

I ended up using a 4 GiB EFI System Partition because this setup uses Limine with snapshot boot support. The rest of the disk becomes one LUKS2 container.

sgdisk --zap-all /dev/nvme0n1

sgdisk \
  -n 1:1MiB:+4GiB -t 1:ef00 -c 1:EFI \
  -n 2:0:0        -t 2:8309 -c 2:cryptroot \
  /dev/nvme0n1

partprobe /dev/nvme0n1
lsblk -o NAME,PATH,SIZE,TYPE,PARTTYPENAME,PARTLABEL /dev/nvme0n1

Format the ESP:

mkfs.fat -F32 -n EFI /dev/nvme0n1p1

At this point, /dev/nvme0n1p1 is the EFI partition and /dev/nvme0n1p2 is the partition that will hold the encrypted root.

3. Create and open the LUKS2 container

Run this directly on the laptop. It requires typing YES and entering the encryption passphrase.

cryptsetup luksFormat \
  --type luks2 \
  --cipher aes-xts-plain64 \
  --key-size 512 \
  --hash sha512 \
  --pbkdf argon2id \
  --label cryptroot \
  /dev/nvme0n1p2

cryptsetup open /dev/nvme0n1p2 cryptroot

Verify the mapper exists:

lsblk -o NAME,PATH,SIZE,TYPE,FSTYPE,LABEL /dev/nvme0n1 /dev/mapper/cryptroot

You should see /dev/nvme0n1p2 as crypto_LUKS and /dev/mapper/cryptroot as the opened encrypted device.

4. Create the Btrfs filesystem

Create the filesystem inside the opened LUKS container:

mkfs.btrfs -L cachyos /dev/mapper/cryptroot

Then create the subvolume layout. This is the CachyOS-style layout, with extra subvolumes for snapshots and swap.

mount /dev/mapper/cryptroot /mnt

btrfs subvolume create /mnt/@
btrfs subvolume create /mnt/@home
btrfs subvolume create /mnt/@root
btrfs subvolume create /mnt/@srv
btrfs subvolume create /mnt/@cache
btrfs subvolume create /mnt/@tmp
btrfs subvolume create /mnt/@log
btrfs subvolume create /mnt/@snapshots
btrfs subvolume create /mnt/@swap

btrfs subvolume list /mnt
umount /mnt

Btrfs snapshots are not backups. They are rollback points. If an update breaks the system, a snapshot can get you back to a working state quickly. It will not save you from disk failure, theft, or deleting something and only noticing six months later.

Use snapshots for recovery. Use backups for backups.

5. Mount everything for installation

Mount the root subvolume first:

mount -o subvol=@,compress=zstd:3,noatime,ssd,discard=async \
  /dev/mapper/cryptroot /mnt

Create the mountpoint directories:

mkdir -p /mnt/{boot,home,root,srv,.snapshots,swap}
mkdir -p /mnt/var/{cache,tmp,log}

Mount the remaining subvolumes:

OPTS="compress=zstd:3,noatime,ssd,discard=async"

mount -o subvol=@home,$OPTS      /dev/mapper/cryptroot /mnt/home
mount -o subvol=@root,$OPTS      /dev/mapper/cryptroot /mnt/root
mount -o subvol=@srv,$OPTS       /dev/mapper/cryptroot /mnt/srv
mount -o subvol=@cache,$OPTS     /dev/mapper/cryptroot /mnt/var/cache
mount -o subvol=@tmp,$OPTS       /dev/mapper/cryptroot /mnt/var/tmp
mount -o subvol=@log,$OPTS       /dev/mapper/cryptroot /mnt/var/log
mount -o subvol=@snapshots,$OPTS /dev/mapper/cryptroot /mnt/.snapshots
mount -o subvol=@swap,$OPTS      /dev/mapper/cryptroot /mnt/swap

Mount the ESP:

mount /dev/nvme0n1p1 /mnt/boot

Check the whole mount tree:

findmnt -R /mnt

6. Create a Btrfs swapfile for hibernation

The laptop has 14 GiB usable RAM, so I used a 24 GiB swapfile to support hibernation.

btrfs filesystem mkswapfile --size 24g /mnt/swap/swapfile
swapon /mnt/swap/swapfile

Collect the resume offset and UUIDs. You will need these later for the kernel command line.

btrfs inspect-internal map-swapfile -r /mnt/swap/swapfile   # resume offset
blkid -s UUID -o value /dev/nvme0n1p2                       # LUKS UUID
blkid -s UUID -o value /dev/mapper/cryptroot                # Btrfs UUID
blkid -s UUID -o value /dev/nvme0n1p1                       # EFI UUID

Write them down somewhere that is not the terminal scrollback you are about to lose.

7. Install the base system

Install the base CachyOS system and the bits needed for encrypted boot, Btrfs, Limine, Snapper, networking, and AppArmor.

pacstrap /mnt base linux-cachyos linux-cachyos-headers linux-firmware amd-ucode \
  btrfs-progs cryptsetup mkinitcpio networkmanager sudo vim nano \
  man-db man-pages texinfo bash-completion dosfstools e2fsprogs efibootmgr \
  limine limine-mkinitcpio-hook limine-snapper-sync snapper \
  cachyos-keyring cachyos-mirrorlist cachyos-settings cachyos-hooks chwd \
  apparmor hunspell-en_gb inetutils which

Generate fstab and fix a couple of permissions:

genfstab -U /mnt | tee -a /mnt/etc/fstab
chmod 750 /mnt/root
chmod 1777 /mnt/var/tmp

/var/tmp needs to be world-writable and sticky. Forgetting this is a very boring way to create very annoying problems later.

8. Configure encrypted boot

Use a systemd-based initramfs with sd-encrypt:

sed -i 's/^HOOKS=.*/HOOKS=(base systemd autodetect microcode modconf kms keyboard sd-vconsole block sd-encrypt filesystems fsck)/' /mnt/etc/mkinitcpio.conf

Now write the kernel command line. Substitute your own LUKS UUID, Btrfs UUID, and resume offset.

I included psmouse.elantech_smbus=1 because the TrackPoint on this AMD ThinkPad involves the Elan SMBus companion path. Whether it saves you is another matter, but at least it shows where the bodies are buried.

mkdir -p /mnt/etc/kernel

cat > /mnt/etc/kernel/cmdline <<EOF
psmouse.elantech_smbus=1 rd.luks.name=<LUKS_UUID>=cryptroot root=UUID=<BTRFS_UUID> rootflags=subvol=@ rw resume=UUID=<BTRFS_UUID> resume_offset=<OFFSET> apparmor=1 security=apparmor lsm=landlock,lockdown,yama,integrity,apparmor,bpf
EOF

Regenerate initramfs and update Limine:

arch-chroot /mnt mkinitcpio -P
arch-chroot /mnt limine-update
grep cmdline /mnt/boot/limine.conf

You want to see your LUKS, root, resume, and AppArmor parameters in the generated Limine config.

9. Enable core services

Enable AppArmor and NetworkManager:

arch-chroot /mnt systemctl enable apparmor.service
arch-chroot /mnt systemctl enable NetworkManager.service

10. Set hostname, locale and timezone

I called the machine bc. Use whatever hostname you want.

echo bc > /mnt/etc/hostname
printf '%s\n' '127.0.0.1 localhost' '::1 localhost' '127.0.1.1 bc.localdomain bc' > /mnt/etc/hosts

Set locale and keyboard:

sed -i 's/^#en_GB.UTF-8 UTF-8/en_GB.UTF-8 UTF-8/; s/^#en_US.UTF-8 UTF-8/en_US.UTF-8 UTF-8/' /mnt/etc/locale.gen
arch-chroot /mnt locale-gen
echo LANG=en_GB.UTF-8 > /mnt/etc/locale.conf
echo KEYMAP=uk > /mnt/etc/vconsole.conf

Set timezone:

arch-chroot /mnt ln -sf /usr/share/zoneinfo/Europe/London /etc/localtime
arch-chroot /mnt hwclock --systohc

11. Create the user

Create the user and allow the wheel group to use sudo without a password. I used x as the username on this machine.

arch-chroot /mnt useradd -m -G wheel,seat,video,audio,input,storage -s /bin/bash x

echo '%wheel ALL=(ALL:ALL) NOPASSWD: ALL' > /mnt/etc/sudoers.d/00-wheel
chmod 440 /mnt/etc/sudoers.d/00-wheel

Set passwords:

arch-chroot /mnt passwd x
arch-chroot /mnt passwd root

If you plan to use fingerprint sudo later, remember that NOPASSWD means sudo will not prompt at all, so fingerprint auth will not appear. That is for the next post. First we need a machine that boots.

12. Configure root SSH key access

I wanted key-based root SSH access for setup and recovery. Add your own public key.

install -d -m 700 /mnt/root/.ssh
echo '<YOUR_SSH_PUBKEY>' > /mnt/root/.ssh/authorized_keys
chmod 600 /mnt/root/.ssh/authorized_keys

Configure sshd:

install -d /mnt/etc/ssh/sshd_config.d
cat > /mnt/etc/ssh/sshd_config.d/10-root-login.conf <<EOF
PermitRootLogin prohibit-password
PasswordAuthentication yes
PubkeyAuthentication yes
EOF

Generate host keys and enable sshd:

arch-chroot /mnt ssh-keygen -A
arch-chroot /mnt systemctl enable sshd.service

Yes, PasswordAuthentication yes looks funny next to root key-only access. PermitRootLogin prohibit-password prevents root password login specifically. You can tighten this further once the machine is up and you are no longer balancing on the branch you are sawing.

13. Install Sway and basic desktop packages

Install a small Sway desktop, audio, clipboard, screenshots, fonts, Firefox, Evolution, and Ly.

pacstrap /mnt \
  sway swaybg swayidle swaylock xorg-xwayland \
  xdg-desktop-portal-wlr xdg-desktop-portal-gtk \
  kitty foot rofi waybar \
  pipewire pipewire-pulse wireplumber pavucontrol \
  brightnessctl grim slurp wl-clipboard mako \
  pcmanfm mousepad firefox evolution \
  ly cmatrix \
  ttf-iosevka-nerd ttf-iosevkaterm-nerd noto-fonts noto-fonts-emoji \
  polkit

I originally had nm-applet in mind, but that uses legacy XEmbed and does not work properly in Sway. Use nm-tray later instead:

paru -S nm-tray

That is a post-boot polish item, not something worth blocking the install on.

14. Configure Ly with cmatrix

Ly uses a template unit. I enabled it on tty2 and disabled the conflicting getty.

arch-chroot /mnt systemctl disable [email protected]
arch-chroot /mnt systemctl enable [email protected]

Enable the matrix animation:

sed -i 's/^animation = .*/animation = matrix/' /mnt/etc/ly/config.ini

On boot, Ly presents a terminal login on tty2 with falling green characters. After login, it launches the user’s Sway session from:

/usr/share/wayland-sessions/sway.desktop

Is this necessary? No. Is it the correct amount of stupid for a ThinkPad running an encrypted manual CachyOS install? Obviously.

15. Reboot

Unmount everything and close the encrypted root:

umount -R /mnt
cryptsetup close cryptroot
reboot

After reboot, unlock LUKS and log in through Ly. Then verify the basics:

swaymsg -t get_inputs
sudo snapper list
sudo aa-status
efibootmgr -v | grep Limine
free -h

At this point the machine has a working encrypted CachyOS install with Btrfs subvolumes, Limine boot, Snapper snapshot support, AppArmor enabled, Sway installed, and a terminal login screen that looks like it escaped from a 1999 hacker film.

That is enough for the base laptop setup post. The machine boots, unlocks, logs in, and has a usable Wayland environment.

The next layer is the personal workstation stuff: dotfiles, GPG, YubiKey, smart card behaviour, SSH agent forwarding, fingerprint sudo, and the small collection of problems that appear once a laptop stops being a fresh install and starts being an actual working machine.

Known issues from this install

The TrackPoint and physical buttons were not fully happy. The Elantech v4 SMBus companion on this AMD Renoir ThinkPad did not initialise cleanly, with the familiar “SMBus companion is not ready yet” class of failure. The workaround for now is touchpad tap-to-click.

fwupd also needed attention because Limine and the ESP location can confuse ESP detection. If firmware updates matter to you, check this before assuming capsule updates will just work.

Finally, nm-applet is not the right tray tool for Sway. Use nm-tray instead.

Reference values from my install

Do not copy these blindly. They are here to show what the real output looked like.

Kernel command line, with shortened UUIDs:

psmouse.elantech_smbus=1 rd.luks.name=b5290f64-...=cryptroot root=UUID=b66eba1e-... rootflags=subvol=@ rw resume=UUID=b66eba1e-... resume_offset=533760 apparmor=1 security=apparmor lsm=landlock,lockdown,yama,integrity,apparmor,bpf

There we have it. A fast, encrypted CachyOS laptop with snapshots, hibernation, Sway, and just enough green terminal nonsense to remind you why you liked Linux in the first place.

How to Sandbox a Linux Process with Landlock, No Root Required

Mon, 14 Sep 2026 17:00:08 +0000

Here's a program restricting itself, then trying to read two files:

without landlock:
  read /etc/hostname            ok
  read /tmp/secret.txt          ok
with landlock, /etc allowed:
  read /etc/hostname            ok
  read /tmp/secret.txt          FAILED (Permission denied)

There's no root, no container, no configuration file, and no daemon. The program asked the kernel to take away its own access to most of the filesystem, and the kernel obliged.

That's Landlock, which has been in the kernel since 2021 without most people noticing. This article builds that program from nothing, runs it, and then walks into the four surprises that catch people the first time.

What You Need
Where Landlock Sits
Three System Calls and No Library
A Program That Restricts Itself
Why no_new_privs is Mandatory
Rulesets Intersect, They Never Widen
What Your Children Inherit
The exec Trap
Wrapping a Program You Didn't Write
Finding the Paths a Program Needs
Which ABI Version You Have
Conclusion
Epilogue

What You Need

To follow along, you'll need a kernel of 5.13 or newer, the standard headers, and a C compiler. Nothing else, and notably not root.

grep landlock /sys/kernel/security/lsm
ls /usr/include/linux/landlock.h

The first command matters. Landlock can be compiled into a kernel and still be inactive, because Linux Security Modules have to be enabled at boot. On this machine, that file reads lockdown,capability,landlock,yama,apparmor.

If landlock is missing from yours, add lsm=landlock, to the front of the existing list in your kernel command line and reboot. Ubuntu has shipped it enabled since 22.04, and current Fedora and Arch kernels carry it too, but the grep above is the only answer that counts for your machine.

Everything below was run on kernel 5.15.0-190-generic under Ubuntu 22.04.5, compiled with gcc 11.4, as an ordinary user with no sudo anywhere.

Where Landlock Sits

Linux Security Modules are a framework, not a policy. The kernel calls out to LSM hooks at decision points, before opening a file, creating a process, or mapping executable memory, and whatever modules are loaded get to say yes or no.

SELinux and AppArmor are the two most people have heard of, and both are administrator tools: someone with root writes a policy, the system loads it, and your program lives inside whatever that policy says.

Landlock inverts that. It's the first LSM a process can apply to itself, without privilege, at runtime. You don't need to convince an administrator that your program deserves a policy. The program asks for less than it currently has, and the kernel narrows it.

That "asks for less" is the whole design. Landlock can only ever remove access. There's no call that grants you something you didn't already have, which is precisely why it's safe to expose to unprivileged processes.

Three System Calls and No Library

Landlock is three syscalls and glibc wraps none of them, so you call them directly through syscall():

static int create_ruleset(const struct landlock_ruleset_attr *attr)
{ return syscall(__NR_landlock_create_ruleset, attr, sizeof(*attr), 0); }

static int add_rule(int fd, const struct landlock_path_beneath_attr *pb)
{ return syscall(__NR_landlock_add_rule, fd, LANDLOCK_RULE_PATH_BENEATH, pb, 0); }

static int restrict_self(int fd)
{ return syscall(__NR_landlock_restrict_self, fd, 0); }

landlock_create_ruleset declares which kinds of access you intend to govern and returns a file descriptor representing the ruleset. landlock_add_rule adds an exception in the form of a directory you want to keep. Finally, landlock_restrict_self applies the whole thing to the calling process, permanently.

The handled_access_fs field in the ruleset attribute is the part people get backwards. It doesn't list what you're allowing. It lists the access types this ruleset is responsible for, and anything in that list is denied everywhere except the paths you explicitly add. Handle read access and you lose read access to the entire filesystem until you add rules back.

A Program That Restricts Itself

Here is the whole thing:

#define _GNU_SOURCE
#include <linux/landlock.h>
#include <sys/prctl.h>
#include <sys/syscall.h>
#include <fcntl.h>
#include <unistd.h>
#include <stdio.h>
#include <string.h>
#include <errno.h>

#define READ_RIGHTS (LANDLOCK_ACCESS_FS_READ_FILE | LANDLOCK_ACCESS_FS_READ_DIR)

static int create_ruleset(const struct landlock_ruleset_attr *attr)
{ return syscall(__NR_landlock_create_ruleset, attr, sizeof(*attr), 0); }

static int add_rule(int fd, const struct landlock_path_beneath_attr *pb)
{ return syscall(__NR_landlock_add_rule, fd, LANDLOCK_RULE_PATH_BENEATH, pb, 0); }

static int restrict_self(int fd)
{ return syscall(__NR_landlock_restrict_self, fd, 0); }

static int allow_read(int ruleset_fd, const char *path)
{
    struct landlock_path_beneath_attr pb = { .allowed_access = READ_RIGHTS };
    int rc;

    pb.parent_fd = open(path, O_PATH | O_CLOEXEC);
    if (pb.parent_fd < 0) { perror(path); return -1; }
    rc = add_rule(ruleset_fd, &pb);
    close(pb.parent_fd);
    return rc;
}

static void try_read(const char *path)
{
    int fd = open(path, O_RDONLY);

    if (fd < 0)
        printf("  read %-24s FAILED (%s)\n", path, strerror(errno));
    else
        { printf("  read %-24s ok\n", path); close(fd); }
}

int main(void)
{
    struct landlock_ruleset_attr attr = { .handled_access_fs = READ_RIGHTS };
    int ruleset_fd = create_ruleset(&attr);

    if (ruleset_fd < 0) { perror("landlock_create_ruleset"); return 1; }
    if (allow_read(ruleset_fd, "/etc") < 0) return 1;

    if (prctl(PR_SET_NO_NEW_PRIVS, 1, 0, 0, 0)) { perror("prctl"); return 1; }
    if (restrict_self(ruleset_fd)) { perror("landlock_restrict_self"); return 1; }
    close(ruleset_fd);

    printf("with landlock, /etc allowed:\n");
    try_read("/etc/hostname");
    try_read("/tmp/secret.txt");
    return 0;
}

Build and run it:

gcc -Wall -o sandbox sandbox.c
echo "hunter2" > /tmp/secret.txt
./sandbox

with landlock, /etc allowed:
  read /etc/hostname            ok
  read /tmp/secret.txt          FAILED (Permission denied)

Two details in there matter. The rule refers to a directory by an open file descriptor rather than a path string, opened with O_PATH so you get a handle without needing read permission on the directory itself. And restrict_self takes effect immediately for the calling process, with no way to undo it.

Why `no_new_privs` is Mandatory

Take the prctl call out and the program stops working:

landlock_restrict_self -> Operation not permitted

That's EPERM, and it's deliberate. PR_SET_NO_NEW_PRIVS tells the kernel that this process and its descendants can never gain privileges through execve, which is what stops a sandboxed process from escaping by running a setuid binary.

Without that guarantee, a restricted process could exec sudo or any setuid program and step outside the restrictions you just applied. Landlock refuses to apply itself at all rather than offer a sandbox with that hole in it. Set no_new_privs first, every time.

Rulesets Intersect, They Never Widen

This is the property to get right. Apply a ruleset allowing /etc, then apply a second allowing /tmp, and ask what you can reach:

after first ruleset:  /etc=ok               /tmp=Permission denied
after second ruleset: /etc=Permission denied  /tmp=Permission denied

The second ruleset didn't add /tmp. It took away /etc, and left you with nothing.

Each restrict_self intersects with everything already applied. The first ruleset permitted /etc and denied the rest. The second permitted /tmp and denied the rest. What survives is the overlap of those two, which is empty.

So a Landlock sandbox is a ratchet. Every application can only tighten, never loosen, and there's no operation anywhere in the API that widens what a restricted process may do. If you need a process to have access to two directories, both rules go into one ruleset before you apply it.

That also means you can't change your mind. A long-running process that restricts itself early can't be granted more later, by itself or by anyone else, short of starting a new process.

What Your Children Inherit

Restrictions follow fork without asking:

parent:       /etc=ok   /tmp/secret.txt=Permission denied
forked child: /etc=ok   /tmp/secret.txt=Permission denied

The child inherits the parent's Landlock domain exactly and there's no flag to opt out. The same holds across execve, which is the point of no_new_privs: the new program starts already inside the sandbox the old one built.

This is what makes Landlock useful for wrapping something you didn't write. Restrict yourself, then exec the thing you want contained, and it runs inside your restrictions without knowing they exist.

The `exec` Trap

It also sets a trap. Take the program above, keep only /etc allowed, and try to exec anything:

allowed: /etc
execl(/usr/bin/cat) failed: Permission denied

Executing a binary requires reading it. This ruleset handles LANDLOCK_ACCESS_FS_READ_FILE, so the kernel checks whether /usr/bin/cat may be read, finds no rule covering /usr, and refuses before the program ever starts.

Add /usr to the same ruleset and it works:

allowed: /etc and /usr
devils-dell

The general lesson is that a Landlock sandbox has to include everything the process touches, and that set is larger than you think. Your binary, its interpreter, every shared library it loads, and any config it reads at startup. ldd on the binary is a good place to begin the list.

Wrapping a Program You Didn't Write

Inheritance across exec is what makes Landlock useful beyond your own code. Restrict yourself, then exec whatever you want contained, and it runs inside the sandbox without cooperating or even knowing.

A usable wrapper needs one addition to the program above. Handle LANDLOCK_ACCESS_FS_EXECUTE alongside the read rights, allow the system directories any binary needs, then allow whatever working directory the user asked for:

#define RIGHTS (LANDLOCK_ACCESS_FS_READ_FILE | LANDLOCK_ACCESS_FS_READ_DIR | \
                LANDLOCK_ACCESS_FS_EXECUTE)

static int add_path(int ruleset_fd, const char *path)
{
    struct landlock_path_beneath_attr pb = { .allowed_access = RIGHTS };
    int rc;

    pb.parent_fd = open(path, O_PATH | O_CLOEXEC);
    if (pb.parent_fd < 0)
        return -1;
    rc = syscall(__NR_landlock_add_rule, ruleset_fd,
                 LANDLOCK_RULE_PATH_BENEATH, &pb, 0);
    close(pb.parent_fd);
    return rc;
}

int main(int argc, char **argv)
{
    struct landlock_ruleset_attr attr = { .handled_access_fs = RIGHTS };
    const char *base[] = { "/usr", "/lib", "/lib64", "/bin", "/etc" };
    int fd, i;

    if (argc < 3) { fprintf(stderr, "usage: %s DIR CMD...\n", argv[0]); return 2; }

    fd = syscall(__NR_landlock_create_ruleset, &attr, sizeof(attr), 0);
    if (fd < 0) { perror("create_ruleset"); return 1; }

    for (i = 0; i < (int)(sizeof(base) / sizeof(*base)); i++)
        add_path(fd, base[i]);
    if (add_path(fd, argv[1]) < 0) { perror(argv[1]); return 1; }

    if (prctl(PR_SET_NO_NEW_PRIVS, 1, 0, 0, 0)) { perror("prctl"); return 1; }
    if (syscall(__NR_landlock_restrict_self, fd, 0)) { perror("restrict_self"); return 1; }
    close(fd);

    execvp(argv[2], &argv[2]);
    fprintf(stderr, "%s: %s\n", argv[2], strerror(errno));
    return 1;
}

The loop ignores what add_path returns, so the same binary works on systems where /lib64 or /bin are absent or symlinked somewhere else. The directory the user named is checked, because a typo there should be an error now rather than a puzzling denial later.

Now cat and ls can see the working directory and nothing else:

mkdir -p /tmp/work && echo "project data" > /tmp/work/notes.txt

./llrun /tmp/work cat /tmp/work/notes.txt
./llrun /tmp/work cat /tmp/secret.txt
./llrun /tmp/work ls /home

project data
cat: /tmp/secret.txt: Permission denied
ls: cannot open directory '/home': Permission denied

Neither program was modified, recompiled, or asked for consent. bwrap and similar tools reach that outcome by building mount and user namespaces around the program. This gets there by asking one LSM for less, in about sixty lines, with nothing to install.

Finding the Paths a Program Needs

The hard part of any sandbox isn't the API. It's the list. Programs open far more than you expect, and a path you forget shows up as a failure somewhere deep in a run.

Two tools build the list for you. ldd gives the shared libraries, which must be readable or the program never starts:

ldd /usr/bin/cat

linux-vdso.so.1 (0x00007fff85f39000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f4f61bb5000)
/lib64/ld-linux-x86-64.so.2 (0x00007f4f61e0a000)

strace gives everything else. Run the program unrestricted first and collect what it opens:

strace -e trace=openat cat /etc/hostname 2>&1 | grep -oE '"/[^"]+"' | sort -u

"/etc/hostname"
"/etc/ld.so.cache"
"/lib/x86_64-linux-gnu/libc.so.6"
"/usr/lib/locale/locale-archive"

Four paths for a program that prints one file, and only one of them is the file you asked for. The linker cache, the C library, and the locale archive are all mandatory, which is why the wrapper allows /usr, /lib and /etc before it allows anything you chose.

Once restricted, strace also tells you exactly what a denial was:

strace -f -e trace=openat ./llrun /tmp/work cat /tmp/secret.txt 2>&1 | grep EACCES

openat(AT_FDCWD, "/tmp/secret.txt", O_RDONLY) = -1 EACCES (Permission denied)

That's the loop. Run it, read the EACCES line, decide whether the path belongs in the ruleset or the program shouldn't be reaching for it, then repeat. Landlock logs nothing of its own on this kernel, so strace is the debugger. Kernels from 6.15 report denials through the audit subsystem, so check your version before hunting for a log that isn't there.

Which ABI Version You Have

Landlock has grown since 5.13, and features you read about may not exist on your kernel. Ask it directly:

int v = syscall(__NR_landlock_create_ruleset, NULL, 0,
                LANDLOCK_CREATE_RULESET_VERSION);

This machine reports 1, which is the original from 5.13 and offers thirteen filesystem access rights:

grep -oE "LANDLOCK_ACCESS_FS_[A-Z_]+" /usr/include/linux/landlock.h | sort -u

LANDLOCK_ACCESS_FS_EXECUTE      LANDLOCK_ACCESS_FS_MAKE_BLOCK
LANDLOCK_ACCESS_FS_MAKE_CHAR    LANDLOCK_ACCESS_FS_MAKE_DIR
LANDLOCK_ACCESS_FS_MAKE_FIFO    LANDLOCK_ACCESS_FS_MAKE_REG
LANDLOCK_ACCESS_FS_MAKE_SOCK    LANDLOCK_ACCESS_FS_MAKE_SYM
LANDLOCK_ACCESS_FS_READ_DIR     LANDLOCK_ACCESS_FS_READ_FILE
LANDLOCK_ACCESS_FS_REMOVE_DIR   LANDLOCK_ACCESS_FS_REMOVE_FILE
LANDLOCK_ACCESS_FS_WRITE_FILE

Later versions added file reparenting, truncation, network rules covering TCP bind and connect, and control over device ioctls. Each arrived in its own ABI bump, so a program that wants a newer right should query the version and degrade rather than assume. Passing a right the running kernel doesn't know about makes landlock_create_ruleset fail with EINVAL, which is a confusing error to debug if you haven't checked the version first.

Conclusion

You can now sandbox a process from inside itself, with no privileges and no configuration, and you know the four surprises. no_new_privs comes first or nothing applies. Rulesets intersect rather than accumulate, so build one ruleset with everything in it. Children inherit, which is a feature. And read restrictions break exec unless the binary's path is allowed too.

There are a few directions to go from here. Add LANDLOCK_ACCESS_FS_WRITE_FILE to handled_access_fs and make a program that can read widely but write to exactly one directory. Wrap a program you didn't write by restricting yourself and then calling execve. Or look at how strace reports the denials, which is the fastest way to build the list of paths a real program actually needs.

Epilogue

The interesting question about Landlock isn't what it does. It's what it can't express. A ruleset names paths, so the unit of authority is a location in the filesystem rather than a particular file you were handed. You can say this process may read below /etc. You can't say this process may read the one file the user just picked, and nothing else.

That gap is what I've spent the last while on, building a capability-backed desktop OS in which authority arrives as a handle to one object rather than a rule about a location, with the Debian ecosystem still working underneath. Landlock does a great deal of the work, and the places it stops are where the design gets interesting.

I write about systems and their mysteries at thechris.in.

Sorry, Wrong Number: Debugging a Crash under Wine

Mon, 14 Sep 2026 07:45:05 +0000

On December 3rd, 2021, a friend of mine needed help: their program was crashing on Wine, and they wanted to know how to fix it.

(And I'm only getting around to publishing this now, several months later. I'm a bit disorganized...)

Normally, the answer to this question is not very complicated, because a lot of stuff works just fine in Wine provided the environment is setup correctly, and some stuff simply doesn't work. Usually problems fall into one of those two categories; however, in this case, there really wasn't any obvious reason (at least to me) why it shouldn't work.

The program in question is compiled with MSys2's MinGW-w64 package, using GCC 10.3. It contains a few other libraries also compiled with the same toolchain, as DLLs, including libpng and zlib, which I am about to become very familiar with.

Some debugging had already been done, and they knew which call the application was failing in: a call to png_read_info. I ran it under Wine using the WINE_DEBUG=+all option and generated a gigantic log file of mostly useless information. After a bit of correlation, I found the last API call before the crash: an msvcrt._read, returning successfully... and then we crash.

After a bit of misdirection, I realized a crucial detail that I had been glancing over for a bit: the access violation was an execute, not a read or write. That means that RIP is landing in the middle of a page that is not executable. Hmmm. Stack corruption, somehow?

Something interesting about Wine is that you can run it under Valgrind, which, with a few flags, does actually work correctly. But upon doing this, I discovered nothing particularly interesting, certainly nothing that would suggest stack corruption, so I moved on.

At this point I decided to break out rr, a special debugger that can record and replay program execution. Honestly, it's a bit overkill here, but it does make it easier to analyze crashes, and this seemed like a good excuse to pull it out. There is a bit of trickiness with using rr on top of Wine, but it works more or less just fine; it's just a bit of a pain to get the replay working. I never quite figured out how to get debug symbols to map correctly with this Wine-under-GDB setup going on, so I had to manually explore the address space to figure out what I was looking at.

After much ado, the program crashes into... nowhere. It crashes at 0x2'fe8f'2910. Nothing is mapped here. Hmm.

Using the magic of rr, I can replay to some point directly before the crash and then step into it. A few hundred stepis later, and I found the culprit: e8 20 45 7e 96, at the address 0x3'6810'e3eb. AKA, CALL 0x2fe8f2910. In other words: there is an explicit CALL to nowhere.

At this point, I threw libpng in a disassembler, and found the instruction at 0x36810e3eb. The instruction?

A call to... crc32?

Bizarre. That CALL has a completely different address. It is e8 78 9e 03 00, not e8 20 45 7e 96 which is non-sense and points backwards to before the entire module.

So who's modifying the CALL? Is it the program? Is it libpng? Is it Wine?

Tracing the CALL

One thing we do know about the .text segment is that it's read-only. Of course, you should at least verify this in your disassembler, but I did, and indeed, it's read-only. That means that in order to modify the segment, someone would need to deliberately mark it writable. On UNIX-like platforms, you would use a syscall like mprotect, whereas Windows provides VirtualProtect in kernel32. Thankfully, there's really no way that libpng would link to VirtualPro-

Goddammit.

...what exactly is libpng doing calling this?

Apparently, it reaches back to sub_3680F1200, which is just the entry point of the DLL–there's a stub over at the "true" entry point, but IDA does not count the jmp in the call graph, so you can't see it here.

In order to try to identify what this code was, I used the tried and true strategy of looking for interesting strings, and quickly found a few, but the most interesting was this one: "Unknown pseudo relocation bit size %d" – hrm, what's a pseudo relocation?

What is a pseudo relocation?

I've mostly glossed over many of the lower level details in this post, but I think this one merits some more attention.

What is a normal relocation?

Before answering what a pseudo relocation is, I'd like to discuss regular relocations. When a linker links a program module, it has to pick some arbitrary "base address" to use for position-dependent code and data. What does that mean? Let's say you have a global, statically-initialized variable that is a pointer to another global variable. This is allowed. The pointer written into the executable file during compilation (specifically linking) is the address that would be correct if the program module was loaded into its preferred base address. Much code and data is position-independent, and thus does not need relocations, but any place where an absolute offset into the address space must be written, such as static pointers, relocations will be needed.

However, being loaded at your preferred base address is somewhat rare these days. For one thing, almost all executable loaders need to support relocating the module to a different base address, because otherwise, it'd be impossible to simultaneously load two modules whose preferred base addresses lead to an overlap, and these cannot be coordinated ahead of time in most cases. In addition, modern AMD64 machines have plenty of address space, so for security reasons, a mitigation called ASLR is almost always used, which essentially just randomizes the base address of program modules even if they are not initially overlapping. (This is a bit of an oversimplification.)

If we move (that is, change the location of) the program module in memory, the addresses that the linker had to write based off of the preferred base address don't line up, as the module is now at a different address, and all offsets are now shifted by some value. In order to adjust this pointer, the linker stores a relocation entry in the binary during compilation for each instance of position-dependent code or data, such as our pointer. At runtime, the executable loader or runtime linker will read each relocation entry and adjust it based on the type of relocation and the offset; adding the offset between the preferred base and the actual base directly to the value present at the address. As long as there is no inadvertent position-dependent code not accounted for by relocations, everything will work perfectly fine.

Modern Windows uses the Portable Executable format. The PE format contains ~9 or so different kinds of relocation entries, some of which vary depending on CPU architecture. The main reason this is necessary is to handle different relocations that modify CPU instructions, where the address may be encoded into the CPU instruction in different ways that the relocation needs to be aware of. PE handles, for example, special cases for the MIPS, ARM (32-bit), and RISC-V instruction sets. (UEFI uses the PE binary format for its binaries, so in order for RISC-V to be able to support UEFI, the PE binary format needed to add support for RISC-V, too. Fun fact!)

Microsoft Windows vs. everything else

The thing is, though, in many other operating systems, especially UNIX-likes, relocations and symbols are different. Whereas Windows binaries have explicit Imports and Exports, and a vector of pointers called the IAT (Import Address Table,) ELF binaries have a single unified symbol table. And when it comes to relocations, ELF has a lot more types of relocations than PE.

Why does this matter? The answer has everything to do with linkage.

When you compile some C code, and it references a symbol which is not defined in that translation unit, it is treated as an external symbol. Later, during linking, when the linker resolves that symbol, it can place the address of the symbol where needed, and thus, the symbol is resolved.

This becomes a problem when linking to other libraries and modules; the address of the symbol is not actually known until runtime, when those libraries and modules are loaded in. Because of that, you need to generate different code; code that resolves the address at runtime, then uses that address. At least on Windows, it would not be typical to generate code like this for any external symbol; it would be slow and wasteful.

Thankfully, there is a workaround for function calls: the linker can generate a thunk; a small routine that forwards the call through the IAT, then that thunk can be used as the address to write in for the CALL instruction.

But what if you reference a data symbol from another library or module? Or, if you try to get the address of a function symbol from another library or module? That's a problem. You need to generate the aforementioned code which resolves the address first, and the compiler, not knowing that this is the case, will generate the wrong code, and the linker will not be able to deal with it.

With ELF, you actually can do this, using symbol-relative relocations. With PE, you are S.O.L.; Or at least, you would normally be.

What a pseudo-relocation is.

Of course, it is possible to link to data symbols on Windows. This is what all of that __declspec(dllimport) business is for: you can specify it on declarations of external symbols, and that way the compiler can generate code which is appropriate for linking to an external symbol in another library.

So what's the problem?

Well, a lot of code written for UNIX-likes doesn't mark their symbols with __declspec(dllimport), given that it is a non-standard Visual C++ extension. MinGW wants to support compiling these programs, and in order to support that, it has invented the concept of pseudo-relocations. (Or perhaps Cygwin has invented this concept; I'm not sure.) A pseudo-relocation is a "fake" relocation handled at runtime, by the library itself, after the real relocations are done. It does this by, at the entrypoint, walking through a list of pseudo-relocations and adjusting the pointers with some offset relative to an IAT entry. These pseudo-relocations import symbol-relative imports, just like ELF systems.

In other words... Pseudo-relocations are a MinGW feature that implements a special kind of "relocation" where a pointer in code or data is replaced with an address relative to an imported symbol.

(Truth be told, it's unclear why MinGW has decided that a call to crc32 needs a pseudo-relocation, but it seems like it can happen when you pass flags to prevent thunks from being generated, and the wrong definitions to zlib to prevent it from using the proper linkage attributes on its symbols.)

Hopefully, you have at least as good an understanding as I do about why pseudo-relocations exist, and what problem they're meant to solve... but a problem remains:

Why does this code, which works under Windows, break under Wine? If you are particularly keen, you may already have an idea what's going on, but just to make sure we're going to dive into exactly what's happening.

Digging Deeper

In order to get more insight into what's going on, we can debug the pseudo-relocation implementation. I don't have debug symbols for it, but that's not a big deal, since the pseudo-relocation code compiles down to relatively succinct and understandable machine code.

Wine provides a GDB server, so you can connect a number of different debuggers. However, I hit a crucial limitation with winedbg right away: it seems to execute the loader before we have a chance to insert breakpoints, which means the libpng entrypoint has already ran before we get the chance to break on it. This leaves us with a couple of different options:

We could fudge the was_init variable. It's a global that the pseudo-reloc code uses to determine if it has run already; the DLL entrypoint runs for new threads, so we could just break on that, then adjust was_init so that it runs again anyways. This might work, but even if so, it's not very versatile.
We can forgo winedbg and simply run Wine itself under GDB.

Wine under GDB

When I used rr earlier, I was basically already doing this. However, rr is pretty overkill for this problem, and actually introduces some complexity of its own, so it's probably easier to just forgo it for now.

I'm on NixOS, where the WINE binary on the $PATH is actually a shell script. We'll tell GDB to execute bash first.

$ gdb --args bash wine Game.exe

This won't work just yet; we need to adjust the behaviors on fork and exec; then we can go.

(gdb) set follow-fork-mode child
(gdb) set follow-exec-mode new
(gdb) catch fork
Catchpoint 1 (fork)
(gdb) catch exec
Catchpoint 2 (exec)
(gdb) run

We can continue a couple of times until we're finally in our target binary, then flip follow-fork-mode back to parent and follow-exec-mode back to same. I want to set a breakpoint at the point at which the was_init variable is flagged. Because WINE doesn't implement ASLR, our libraries end up at their preferred base addresses, so lacking symbols in GDB, I can just enter the raw addresses as determined by digging around in IDA:

(gdb) break *0x36812E5C8
Breakpoint 3 at 0x36812e5c8

GDB doesn't give us a whole lot of feedback. Something useful you can do is have GDB print the disassembly at the instruction pointer for you:

(gdb) display/i $pc
1: x/i $pc
=> 0x36812e5c8: movl   $0x1,0x14b0e(%rip)        # 0x3681430e0
(gdb)

Now, as we step through, we can see what instruction we are on.

In this case, the +0x14b0e address is was_init. This instruction may look strange since pseudo-reloc has ++was_init rather than was_init = 1, but I think we can assume that the compiler has optimized it to assume was_init is zero due to the conditional beforehand. Neat.

This could get pretty boring if we tried to understand and explain each instruction. I've already analyzed the function and found the relocations, so I should be able to set a conditional breakpoint that gets me into the exact spot I want to be.

IDA Pro annoyingly shows the same address for all relocations because it's marked as an array. That's OK – we just need to calculate it out, and make a quick breakpoint:

(gdb) break *0x36812E69D if $rbx == 0x36813DF4C
Breakpoint 5 at 0x36812e69d

And now we can continue. Once we're there, we can step around:

(gdb) stepi
0x000000036812e69f in ?? ()
1: x/i $pc
=> 0x36812e69f: mov    0x4(%rbx),%esi
(gdb)
0x000000036812e6a2 in ?? ()
1: x/i $pc
=> 0x36812e6a2: movzbl 0x8(%rbx),%edx
(gdb)
0x000000036812e6a6 in ?? ()
1: x/i $pc
=> 0x36812e6a6: add    %r13,%rax
(gdb)
0x000000036812e6a9 in ?? ()
1: x/i $pc
=> 0x36812e6a9: add    %r13,%rsi
(gdb)
0x000000036812e6ac in ?? ()
1: x/i $pc
=> 0x36812e6ac: mov    (%rax),%r15
(gdb)
0x000000036812e6af in ?? ()
1: x/i $pc
=> 0x36812e6af: cmp    $0x20,%edx
(gdb)
0x000000036812e6b2 in ?? ()
1: x/i $pc
=> 0x36812e6b2: je     0x36812e7a8
(gdb)

This is just a switch statement compiled into a conditional tree. As luck would have it, all of our relocations are 32-bit (...), so this first conditional hits immediately.

(gdb)
0x000000036812e7a8 in ?? ()
1: x/i $pc
=> 0x36812e7a8: mov    (%rsi),%edx
(gdb)
0x000000036812e7aa in ?? ()
1: x/i $pc
=> 0x36812e7aa: mov    %rdx,%rcx
(gdb) nexti
0x000000036812e7ad in ?? ()
1: x/i $pc
=> 0x36812e7ad: or     %r14,%rdx
(gdb)
0x000000036812e7b0 in ?? ()
1: x/i $pc
=> 0x36812e7b0: test   %ecx,%ecx
(gdb)
0x000000036812e7b2 in ?? ()
1: x/i $pc
=> 0x36812e7b2: cmovns %rcx,%rdx
(gdb)
0x000000036812e7b6 in ?? ()
1: x/i $pc
=> 0x36812e7b6: mov    %rsi,%rcx
(gdb)
0x000000036812e7b9 in ?? ()
1: x/i $pc
=> 0x36812e7b9: sub    %rax,%rdx
(gdb)
0x000000036812e7bc in ?? ()
1: x/i $pc
=> 0x36812e7bc: add    %rdx,%r15
(gdb)
0x000000036812e7bf in ?? ()
1: x/i $pc
=> 0x36812e7bf: call   0x36812e420
(gdb)
0x000000036812e7c4 in ?? ()
1: x/i $pc
=> 0x36812e7c4: mov    %r15d,(%rsi)
(gdb)
0x000000036812e7c7 in ?? ()
1: x/i $pc
=> 0x36812e7c7: jmp    0x36812e694
(gdb)

This code right here is the culprit. It just wrote %r15d to the memory at the address pointed to by %rsi. What are those values?

(gdb) i r r15d
r15d           0x967e4520          -1770109664
(gdb) i r rsi
rsi            0x36810e3ec         14630839276

We have, without a doubt, located the culprit. It's writing the exact same sequence of incorrect bytes we saw earlier. What the heck is wrong with it? Why isn't it getting the correct address for crc32? Why is it 0x1'0000'0000 too far forward?

If you haven't figured it out yet, this should do it:

# At this point, %rax points to where the IAT entry is,
# and %r15 points to the actual value in it.
rax            0x368148268         14631076456
r15            0x1fe8f2910         8565762320

# Read the value at the target into %edx.
# This is a pointer into the IAT.
mov    (%rsi),%edx

rsi            0x36810e3ec         14630839276
*rsi           0x39e78             237176
edx            0x20 -> 0x39e78     32 -> 237176

# Copy %rdx into %rcx.
mov    %rdx,%rcx
rdx            0x39e78             237176
rcx            0x0 -> 0x39e78      0 -> 237176

# Perform sign extension on %rdx copy.
or     %r14,%rdx
r14            0xffffffff00000000  -4294967296
rdx            0x39e78 -> 0xffffffff00039e78  237176 -> -4294730120

# Test %ecx for flags.
test   %ecx,%ecx
eflags         0x286               [ PF SF IF ]
ecx            0x39e78             237176

# This undoes the sign extension if the sign bit is not set.
cmovns %rcx,%rdx
eflags         0x206               [ PF IF ]
rcx            0x39e78             237176
rdx            0xffffffff00039e78 -> 0x39e78  -4294730120 -> 237176

# At this point we've undone the sign extension.

# Move relative offset of IAT into rcx, for mark_section_writable.
mov    %rsi,%rcx
rsi            0x36810e3ec         14630839276
rcx            0x39e78 -> 0x36810e3ec  237176 -> 14630839276

# %rax is the absolute address of the IAT entry. Subtract it from %rdx.
sub    %rax,%rdx
rax            0x368148268         14631076456
rdx            0x39e78 -> 0xfffffffc97ef1c10  237176 -> -14630839280

# Add %rdx to %r15.
add    %rdx,%r15
rdx            0xfffffffc97ef1c10  -14630839280
r15            0x1fe8f2910 -> 0xfffffffe967e4520  8565762320 -> -6065076960

# Call mark_section_writable
call   0x36812e420

# Write the pseudo-relocation back.
mov    %r15d,(%rsi)
rsi            0x36810e3ec         14630839276
*rsi           0x39e78 -> 0x967e4520  237176 -> -1770109664
r15d           0x967e4520          -1770109664

Did you catch it? The distance between the instruction is greater than what can be stored in a 32-bit value. The E8 CALL instruction can only jump between [-2³¹,2³¹) bytes away from the RIP as of execution because it can only store a 32-bit signed offset. Unfortunately, the pseudo reloc code simply failed silently back when I was debugging this, but I believe it has been fixed and now outputs an error when this occurs, so it shouldn't be so puzzling to future generations.

One last thing...

There is one more weird thing though. This program works on Windows, reliably. Obviously, it isn't loading libraries at their preferred base addresses, or it would crash. So why is this happening?

Well, simple: Wine doesn't support ASLR, and the libraries, at their preferred addresses, wind up too far away for the pseudo-relocations.

However, the fact that it works seemingly reliably on Windows is very interesting. Maybe an interesting exploration would be to see exactly why Windows ASLR seems to consistently choose addresses that are unproblematic. Perhaps it's because the first time after bootup that these particular modules load is in quick succession?

Regardless, now knowing how the problem can be fixed, it's hard to be motivated to dig too much deeper. It might be nice if Wine could have similar ASLR behavior to Windows, so that these problems are less likely to crop up only on Wine, but these problems could also occur on Windows with ASLR disabled, so it's probably not that important.

Overall, I had fun debugging this issue. I'm also really happy with how far Wine has come, and I do not think it is a coincidence that the issue we hit was not reasonably Wine's fault. I am, however, a bit sad that I didn't get an opportunity to track down and fix a nasty Wine bug, but all the more happy that the reason for this is because it simply didn't exist.

Maybe next time. :)

Linux 7.3-rc2 Arrives Heavier Than Usual, With Torvalds Joking the Blame Falls on AI

Mon, 14 Sep 2026 06:20:20 +0000

On September 6, 2026, Linus Torvalds made available Linux 7.3-rc2, calling it unusually large for that stage in the development cycle which usually provides developers with a short break once the merge window has closed, on the basis of his post to the Linux Kernel Mailing List.

A large number of bug reports and fixes came in early. Torvalds never identified one specific cause for the size and instead settled on a more modest explanation by saying, "We'll obviously all blame it on AI," without confirming that AI tools were responsible for the increase. The stable version of Linux 7.3 is due on October 18.

AI and LLM-generated contributions have continued arriving throughout the 7.3 cycle.

Linux 7.3-rc2 Fixes and Torvalds on Its Unusual Size

The source code is available at kernel.org, and kernel testers and distribution maintainers are encouraged to run validation passes on drivers and tooling.

Tooling fixes made up about 20 percent of the non-driver patch volume, with filesystem, core kernel, and networking contributions filling out the rest. Drivers accounted for most of the total diff.

On networking, TCP and IPv6 received targeted fixes, the ksmbd SMB server gained memory-safety corrections, and NTFS and XFS both saw adjustments.

Graphics changes touched AMD's DRM driver and the open-source Nouveau driver for NVIDIA hardware. rc2 also carried a scheduler fix for Cache Aware Scheduling misfits on hybrid CPUs that combine performance and efficiency cores, and developer Kees Cook ran a tree-wide conversion moving more kmalloc() calls to the newer kmalloc_obj() family across hundreds of files.

The Nouveau driver gained display fixes for NVIDIA's current Blackwell GPUs. Nouveau developer Mohamed Ahmed said the fixes covered four independent groups of issues tied to the GPU System Processor, including corrections to HDMI vendor infoframes on GB20x hardware, HDMI GCP AVMute register offsets, and vblank interrupts on Blackwell cards.

Ahmed said the work grew out of efforts to bring HDMI 2.1 support to Nouveau, pointing to a 2.147GHz pixel clock cap as an example of a problem that needs fixing before features such as FRL, DSC, and VRR can work correctly.

A separate change disables the RandStruct security feature by default on systems with a usable Rust compiler toolchain, to sidestep a circular dependency between RandStruct and Rust kernel support.

Torvalds spent part of his post trying to identify the reason for the release's size without settling on one answer. He pointed first to a late pull from the Error Detection and Correction (EDAC) subsystem that had been overlooked during the merge window, then called that explanation too minor by itself.

He described several filesystems sending in fixes together, alongside a sizable DRM pull, networking and BPF fixes, and contributions from a number of driver trees landing in the same window.

With no single item accounting for the total, he landed on the AI remark, without confirming whether AI tools were actually behind the increase.

AI-Generated Linux Kernel Patches and Review Pressure

AI and LLM-generated contributions have kept arriving throughout the 7.3 cycle. Kernel co-maintainer Greg Kroah-Hartman had already flagged the cycle as likely to be difficult, posting in early September that "this is going to be a rough -rc cycle" after filtering his inbox for Linux USB subsystem submissions.

Kroah-Hartman said his filtered queue held 1,732 of 4,807 messages tied to the USB subsystem when he first posted, a number he brought down to 1,094 of 4,170 after clearing the most obvious fixes.

He added that pushing back against AI-generated submissions takes time even when a patch is clearly wrong, since he does not want to reject genuine bug fixes in the process.

This tension has appeared in earlier Linux release candidates and echoes wider industry findings on AI-generated code and security review.

Linux 7.3 Development Cycle and Stable Release Timeline

The 7.3 cycle was already large before rc2. Linux 7.3-rc1 reached 40.98 million lines of code on August 30, made up of 30,937,090 lines of code, 4,912,366 lines of comments, and 5,134,418 blank lines, up from 40.42 million lines in Linux 7.2.

A large share of the increase came from a new set of AMD DCN6 graphics register headers, which Torvalds said accounted for about a third of the entire rc1 patch.

Torvalds also used the rc1 announcement to describe a system upgrade he ran mid-merge-window that went wrong, calling himself "a grade A nincompoop," though he said the problem was resolved without lasting effects.

No systemic architectural issues turned up despite the higher patch volume. The stable Linux 7.3 release is scheduled for October 18, with a possible slip to October 25 if the pace of incoming patches does not ease in the coming weeks. rc2 is available now at kernel.org for testing.

Thank you for being a Ghacks reader. The post Linux 7.3-rc2 Arrives Heavier Than Usual, With Torvalds Joking the Blame Falls on AI appeared first on gHacks.

Switching to GNU Guix: A Beginner's Perspective - Wai Hon's Blog

Mon, 14 Sep 2026 01:34:24 +0000

Switching to GNU Guix: A Beginner's Perspective

2026-09-13 #linux #guix

Background: A Decade of Arch Linux

Arch Linux was my distribution of choice for more than a decade. With its rolling-release model, minimal base, and the invaluable ArchWiki, it felt like the final distribution I would ever need.

My primary Linux machine is a dedicated home server, handling services like Home Assistant, local DNS, background jobs, and developer sandboxes. For a server running 24/7, long-term stability and maintainability are critical. Over years of incremental tweaks, configuration entropy inevitably crept in. System state became scattered across /etc, /usr, systemd service units, and package manager transactions. Whenever I made changes, I had to keep diligent notes about which files were edited, when, and why.

Recent events, such as the Arch Linux AUR security incidents (which I touched upon in my previous post on Caddy) and developments around Omarchy, prompted me to re-evaluate my setup. I wanted an operating system that was declarative, reproducible, and manageable entirely in code.

NixOS vs GNU Guix

Declarative operating systems offer a compelling answer to configuration drift. When researching options, NixOS was actually my first choice.

Testing NixOS in a VM

I spun up a NixOS virtual machine and spent time experimenting by replicating the core services I was running on Arch to ensure everything worked properly. It worked really well: declaring the entire system state in a configuration file with instant rollback capabilities felt like the right model for operating systems.

However, as I explored deeper, documentation in NixOS became a major source of friction. The newer nix command line interface and Flakes remain experimental features that are not yet enabled by default or standardized across the ecosystem, leading to divergent documentation and tutorials. Finding guidance was further complicated by the presence of two separate wikis.

Discovering GNU Guix

While learning more about NixOS, I came across David Wilson’s video from System Crafters: Why I Choose Guix Over NixOS. As a fan of David Wilson, his arguments resonated strongly with me. Shortly after, I also watched YouTux’s video, One of the Best Linux Distros Isn’t Even in DistroWatch’s Top 100.

These videos prompted me to research GNU Guix and try it inside a VM.

GNU Guix shares the same core architectural foundation as NixOS (functional package management, declarative configuration, and atomic rollbacks), but its design choices felt much more cohesive:

Language (GNU Guile Scheme vs Nix DSL): Nix uses its own bespoke domain-specific language. Guix configurations are written entirely in GNU Guile, a general-purpose Scheme (Lisp). As an Emacs user accustomed to Emacs Lisp, Scheme felt familiar and expressive. Rather than learning a specialized configuration syntax, I could leverage a real programming language with first-class functions, macros, and modules.
Init System (GNU Shepherd vs systemd): NixOS builds on systemd, while Guix System uses GNU Shepherd as its service manager. In Guix, Shepherd services are also defined in Guile Scheme. Everything from package recipes to system daemons to PID 1 shares a unified language and data model.
Documentation: Guix’s documentation is remarkably cohesive. Even though some community tutorials can be dated, the official GNU Guix reference manual is consistent, comprehensive, and avoids the fragmented wiki landscape of Nix.
Philosophy (GNU Libre Standards vs Pragmatism): NixOS takes a pragmatic stance, offering toggles for proprietary software and unfree drivers. GNU Guix strictly adheres to the GNU Free System Distribution Guidelines, shipping the Linux-libre kernel and free software exclusively by default.

This philosophical strictness has its trade-offs. For my home server, which connects to the network through an Ethernet cable, proprietary Wi-Fi firmware is unnecessary, and the Linux-libre kernel works out of the box. The purity and auditability feel satisfying, though it does mean dealing with a more curated package catalog. Also, a personal server is personal, I can have my own opinion – I prefer purity over pragmatism, but I think GNU Guix is pragmatic enough for my use cases.

Between the familiarity of Scheme, the unified architecture, and its close kinship with Emacs, I decided to make the switch to GNU Guix.

What I Like as a Beginner

Unified Declarative Config in Git

With GNU Guix, the entire operating system configuration lives in code and is tracked in Git. I manage both Guix System (operating system declarations, system daemons, kernel parameters) and Guix Home (user packages, shell environments, and dotfiles) within a single literate Org-mode file (guix.org) using Org Babel.

At any point, I can see exactly which packages are installed and which services are active directly from the codebase. In the past, I hesitated to invest in complex system configurations because maintaining them across updates was fragile. With Guix, configuring the operating system feels as manageable and predictable as tweaking my Emacs configuration.

Flexible Guile Configuration

Guix configurations are written in a full-featured programming language rather than static YAML or JSON. This gives immense flexibility when composing services.

Using Guix’s service extension mechanism with simple-service, you can extend existing system services cleanly without modifying base declarations. In a traditional distribution, deploying a service forces you to fragment its configuration across completely separate subsystems: a systemd unit in /etc/systemd/system/, and reverse proxy blocks in /etc/nginx/conf.d/.

With Guix, you can co-locate a service and its surrounding infrastructure side by side in the exact same configuration block:

;; Home Assistant container
(simple-service 'home-assistant-container
                oci-service-type
                (oci-extension
                 (containers
                  (list
                   (oci-container-configuration
                    (provision "home-assistant")
                    (image "ghcr.io/home-assistant/home-assistant:stable")
                    ...details config...)))))

;; Inject the Nginx reverse proxy configuration for Home Assistant
(simple-service 'home-assistant-nginx-server
                nginx-service-type
                (list
                 (nginx-server-configuration
                  (inherit ssl-server-configuration)
                  (server-name (list (string-append "home." domain)))
                  (locations
                   (list
                    (nginx-location-configuration
                     ...details config...)))))

This architectural clarity makes understanding, modifying, or removing a service self-contained and painless.

Streamlined Shepherd Timers

Another example is Shepherd Timers. Defining scheduled jobs in Guix is also much more streamlined than in traditional distributions. In systemd, setting up a recurring job requires declaring a .service file and a separate .timer unit.

With GNU Shepherd in Guix, you can declare the executable script, its dependencies, and its schedule together in a single Guile expression:

(let* ((duckdns-script
        (program-file
         "duckdns-update"
         (with-extensions (list guile-gnutls) ;required by (web client)
                          #~(begin
                              (use-modules (ice-9 textual-ports)
                                           (web client))
                              (let ((token (string-trim-both
                                            (call-with-input-file "/etc/secrets/duckdns.token"
                                              get-string-all)))
                                    (query-template (string-append "https://www.duckdns.org/"
                                                                   "update?domains=<mydomain>"
                                                                   "&token=~a&ip=")))
                                (http-get (format #f query-template token)))))))
       (duckdns-timer
        (shepherd-timer '(duckdns)
                        "*/5 * * * *"
                        #~(#$duckdns-script)
                        #:requirement '(networking)
                        #:documentation "Update personal domain IP on DuckDNS every 5 minutes.")))
  (simple-service 'duckdns-timer
                  shepherd-root-service-type
                  (list duckdns-timer)))

Sandboxed Containers with `guix shell`

The guix shell command has transformed how I run ad-hoc software. Instead of polluting my profile with one-off utilities, guix shell creates an ephemeral environment that is cleaned up when the session ends.

Furthermore, its container mode (guix shell -C or --container) makes lightweight isolation trivial. By specifying exactly which directories (--share) and network access (--network) to expose, I can run untrusted commands or AI coding agents inside an isolated sandbox.

For example, I run the Antigravity CLI within a sandbox granting access only to the current working directory, its configuration, and necessary binaries:

# Run Antigravity CLI in a Guix sandbox with access to its config and the project directories.
agy-guix() {
    guix shell --container --network --emulate-fhs \
         --share="$PWD" \
         --share="$HOME/.gemini" \
         --share="$HOME/.local/bin" \
         --preserve='^(TERM)$' \
         coreutils nss-certs bash guix guile emacs git ripgrep fd zip unzip -- $HOME/.local/bin/agy "$@"
}

Knowing an agent cannot access arbitrary files outside its granted path makes experimentation much safer.

Purity and the Minimal Bootstrap Seed

By default, GNU Guix is strictly libre. It ships with the Linux-libre kernel and avoids proprietary binary blobs.

Beyond day-to-day use, Guix’s architectural focus on bootstrapping integrity (reducing the bootstrap binary seed down to around 357 bytes through the stage0/Mes bootstrap) provides a strong sense of technical rigor. Knowing the system can be built from minimal, auditable foundations provides real trust in the underlying stack.

Issues and How I Handle Them

Slow `guix pull` and Source Builds

A fundamental difference between Guix and Arch Linux is that Guix is a source-based distribution at its core, backed by substitute servers that distribute prebuilt binaries.

If a newly pulled channel commit has not yet been built by the substitute build farm (such as ci.guix.gnu.org or Bordeaux), your machine will fall back to compiling the packages locally. While this architecture empowers powerful capabilities like guix challenge (verifying build reproducibility against other servers) and guix time-machine (traveling back to any historical revision), waiting for long local builds on a home server can be tedious.

To avoid unexpected local compilation, my practical workaround is to pin guix pull to a specific commit from a day or two earlier, ensuring substitutes are already built and cached:

Addressing the Package Gap

The most noticeable hurdle for a beginner coming from Arch Linux is repository size. The official Guix channel has strict libre standards and a smaller catalog than the Arch User Repository (AUR). Common utilities like hugo and caddy are not present in the official channel.

In practice, there are several practical ways I handle this gap:

1. Writing Custom Package Definitions

Writing a package definition in Scheme is straightforward. You can define a package that builds from source or downloads an official upstream release archive:

(define hugo
  (package
    (name "hugo")
    (version "0.165.0")
    (source (origin
              (method url-fetch)
              (uri (string-append
                    "https://github.com/gohugoio/hugo/releases/download/v"
                    version "/hugo_" version "_linux-amd64.tar.gz"))
              (sha256 (base32 "0..."))))
    (build-system trivial-build-system)
    ...))

For Hugo, I created a local package definition downloading the official prebuilt binary, making it available seamlessly to my system and deploy scripts.

2. Running Ephemeral Toolchains via `guix shell`

For tools that exist within language ecosystems, guix shell can pair with ecosystem runners (uvx, npx) without installing packages globally:

# That is how I publish my blog to Cloudflare now.
guix shell node -- npx -y wrangler

3. Generating Definitions with `guix import`

When a package is missing, guix import can automatically generate package definitions from upstream registries, such as PyPI, Crates.io, CPAN, or GNU ELPA. This significantly reduces the manual effort of writing package recipes.

4. Switching to Readily Available Alternatives

Sometimes the simplest path is adopting software that is already a first-class citizen in Guix. Rather than maintaining a custom Caddy setup with third-party plugins, I switched back to Nginx combined with Certbot. Both are well-supported native services in Guix System, simplifying long-term maintenance.

Conclusion

It has been a month since migrating my home server to GNU Guix. Managing OS state declaratively through Git has eliminated configuration drift, and Guile Scheme provides a cohesive environment that complements Emacs. While adapting to a smaller package ecosystem and managing substitute timing requires occasional adjustments, the stability, reproducibility, and container isolation make it a dependable foundation.

In my free time, I have started reading the legendary SICP (Structure and Interpretation of Computer Programs) to deepen my understanding of Scheme and functional programming.

Flare-On 11 – Task 5

Sun, 13 Sep 2026 17:34:36 +0000

Flare-On is an annual CTF run by Mandiant Flare Team. In this series of writeups I present solutions to some of my favorite tasks from this year. All the sourcecodes are available on my Github, in dedicated repository: flareon2024. The … Continue reading →

Fuzzing Under The Cave: Hunting Bugs In Batman-adv

Sun, 13 Sep 2026 16:43:29 +0000

We went looking for an under-tested corner of the Linux kernel and landed on batman-adv, the mesh networking subsystem, whose routing.c sat at 0% coverage on Syzbot. This post walks through how we wired Syzkaller up to fuzz the Ethernet frame reception path — including the Syzlang grammar we had to write from scratch — and the three bugs that came out of it: a 16-bit integer overflow in OGM fragmentation (now patched in mainline), a use-after-free race in the throughput meter, and an integer truncation leading to an out-of-bounds read in the translation table TVLV handler.

Research during a grace period

We had some spare time to conduct vulnerability research on an open subject. We needed to find an interesting target where we could learn something new and related to the Linux kernel. Thus, we searched through Linux subsystems to find our happiness. While looking at Syzbot‘s coverage, we noticed that the subsystem batman had a file called routing.c with 0% of coverage:

We determined there was an opportunity to fuzz the ethernet frames receival logic.

What is BATMAN-ADV?

B.A.T.M.A.N. for Better Approach To Mobile Ad hoc Networking is a routing protocol designed by the Freifunk community for multi-hop ad-hoc mesh networks. The batman-adv implementation works on the Data-link layer (L2) of the OSI model and is implemented as a Linux kernel module.

We can think of a batman-adv as a big switch where we have devices that can be inter-connected as peers. The protocol uses Originator Messages and Echo Location Protocol (on batman-adv V) to maintain routing information. There are also other utilities but we will not describe them as they are already well documented by the maintainers.

Fuzzing batman-adv

Fuzzing Methodology

We used Syzkaller which is a coverage-guided kernel fuzzer. We had experience using it and since Syzbot is based on it, we could reach the same code paths using the existing batman-adv grammar that ensures we can trigger messages to manage the subsystem through a netlink socket (This is a common pattern used to communicate through kernel subsystems).

We already worked on the nftables subsystem, which also involved fuzzing the network reception part. During this work, we discovered the blog post from xairy.io that uses TUN/TAP to send network traffic to the VM’s network stack.

TUN/TAP is a subsystem that provides virtual network devices. The goal is to have a mechanism to communicate network traffic through userland programs. It is a tool often used by VPN applications to encapsulate the network frames/packets:

Syzkaller provides a pseudo-syscall named syz_emit_ethernet for these use cases. However, we needed to adapt some parts of the executor code to initialize the bat0 interface correctly.

Fuzzing implementation

Since we managed to setup Syzkaller to fuzz the frame receival logic, we needed to make sure the grammar for the different types of messages exist. Syzkaller uses Syzlang language to define grammars for syscalls. There is the sys/linux/vnet.txt file to describe the network protocol messages. There was no existing grammar for the batman-adv messages so we had to implement them directly in this file. To provide correct Syzlang descriptions for each message, we based ourselves on the include/uapi/linux/batadv_packet.h file.

				eth2_packet [
        ...
+       batman_adv eth2_packet_t[ETH_P_BATMAN, batman_packet]
+] [varlen]

[...]

+include <uapi/linux/batadv_packet.h>
+
+batman_packet [
+       batman_packet_ogm batman_packet_ogm_t
+       batman_packet_ogm2 batman_packet_ogm2_t
+       batman_packet_elp batman_packet_elp_t
+       batman_packet_multicast batman_packet_multicast_t
+       batman_packet_icmp batman_packet_icmp_t
+       batman_packet_coded batman_packet_coded_t
+       batman_packet_unicast_tvlv batman_packet_unicast_tvlv_t
+       batman_packet_icmp_tp batman_packet_icmp_tp_t
+       batman_packet_icmp_rr batman_packet_icmp_rr_t
+       batman_packet_unicast batman_packet_unicast_t
+       batman_packet_unicast_ext batman_packet_unicast_ext_t
+       batman_packet_fragmented_unicast batman_packet_fragmented_unicast_t
+       batman_packet_broadcast batman_packet_broadcast_t
+] [varlen]

[...]

+batman_packet_ogm_t {
+       hdr batman_header_t[const[BATADV_IV_OGM, int8]]
+       ttl int8
+       flags const[0, int8]
+       seqno int32be
+       orig mac_addr
+       prev_sender mac_addr
+       reserved const[0, int8]
+       tq int8
+       tvlv_len int16be
+} [packed]

Vulnerabilities discovered

Bug 1: Integer Overflow during frame fragmentation

With the complete setup, we quickly found our first bug in batman-adv.

We searched why the bug was triggered and here is our analysis. There is a function call to batadv_iv_ogm_send_to_if to send the OGM message to a given interface. It also handles the fragmentation.

				/* send a batman ogm to a given interface */
static void batadv_iv_ogm_send_to_if(struct batadv_forw_packet *forw_packet,
                                     struct batadv_hard_iface *hard_iface)
{
        struct batadv_priv *bat_priv = netdev_priv(hard_iface->soft_iface);
        const char *fwd_str;
        u8 packet_num;
        s16 buff_pos;
        struct batadv_ogm_packet *batadv_ogm_packet;
        struct sk_buff *skb;
        u8 *packet_pos;

        if (hard_iface->if_status != BATADV_IF_ACTIVE)
                return;

        packet_num = 0;
        buff_pos = 0;
        packet_pos = forw_packet->skb->data;
        batadv_ogm_packet = (struct batadv_ogm_packet *)packet_pos;

        /* adjust all flags and log packets */
        while (batadv_iv_ogm_aggr_packet(buff_pos, forw_packet->packet_len,
                                         batadv_ogm_packet)) {
                [...]

                buff_pos += BATADV_OGM_HLEN;
                buff_pos += ntohs(batadv_ogm_packet->tvlv_len);
                packet_num++;
                packet_pos = forw_packet->skb->data + buff_pos;
                batadv_ogm_packet = (struct batadv_ogm_packet *)packet_pos;
        }

        [...]
}

We found out that there is a variable named buff_pos that stores the current buffer position to separate the OGM messages from the forward packet. We noted that the variable stores this information on a signed integer of 16 bits. There is a size check that is done on this variable in the batadv_iv_ogm_aggr_packet function that can be called in the previous function multiple times.

				/**
 * batadv_iv_ogm_aggr_packet() - checks if there is another OGM attached
 * @buff_pos: current position in the skb
 * @packet_len: total length of the skb
 * @ogm_packet: potential OGM in buffer
 *
 * Return: true if there is enough space for another OGM, false otherwise.
 */
static bool
batadv_iv_ogm_aggr_packet(int buff_pos, int packet_len,
                          const struct batadv_ogm_packet *ogm_packet)
{
        int next_buff_pos = 0;

        /* check if there is enough space for the header */
        next_buff_pos += buff_pos + sizeof(*ogm_packet);
        if (next_buff_pos > packet_len)
                return false;

        /* check if there is enough space for the optional TVLV */
        next_buff_pos += ntohs(ogm_packet->tvlv_len);

        return next_buff_pos <= packet_len;
}

However, this function compares our buff_pos variable against a signed 32 bits integer. After some debugging, we noticed the variable signed on 16 bits can overflow with large frames, which caused the condition to still pass since we are below the packet_len with a negative value.

The patch was fairly simple as we simply needed to change buff_pos into a signed 32 bits integer variable in the batadv_iv_ogm_send_to_if function. Since it was an unknown bug, we were able to send the patch to the maintainers. The patch is now merged into the Linux kernel mainline.

Bug 2: Race condition on throughput meter when interface is deleted

Syzkaller showed us a slab use-after-free bug on the batadv_find_router function. We analyzed the KASAN trace and started to understand why the bug occurred. We understood that we needed to initiate a ThroughputMeter (TP) which is a tool to calculate the bandwidth in the mesh network. It can be triggered through a netlink socket using the BATADV_CMD_TP_METER message.

This action creates a kthread in the batadv_tp_start_kthread function.

				static void batadv_tp_start_kthread(struct batadv_tp_sender *tp_vars)
{
	struct task_struct *kthread;
	struct batadv_priv *bat_priv = tp_vars->common.bat_priv;
	u32 session_cookie;

	kref_get(&tp_vars->common.refcount);
	kthread = kthread_create(batadv_tp_send, tp_vars, "kbatadv_tp_meter");
	
        [...]

	wake_up_process(kthread);
}

We also checked where the use-after-free occurred. After reading the code, we determined it happened in batadv_find_router when trying to access an attribute of the batadv_priv structure. This is interesting because it contains information about the mesh interface. This helped determine that there was a race condition because of the kthread trying to access data when the interface was already deleted.

However, the bug was already known and patches were already implemented in the mailing lists.

Bug 3: Integer truncation when computing the VLAN size when receiving a unicast packet with a TT TVLV

A TVLV (Type Version Length Value) is a “container” that can be appended to some packets (such as OGM or Unicast) to send information to other nodes. For this bug, we will have a look at the Translation Table (TT) TVLV (see the open-mesh documentation). Its objective is to advertise local non-mesh clients. Here is the format of the TVLV:

				0                   1                   2                   3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   TVLV 0x04   |    Version    |             Length            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   TT Flags    |     TTVN      |       Number of VLANs         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                        CRC32_vlan1                            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|       VID_vlan1               |       reserved_vlan1          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                        CRC32_vlan2                            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|       VID_vlan2               |       reserved_vlan2          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                       ...................                     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                        CRC32_vlanN                            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|       VID_vlanN               |       reserved_vlanN          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| flags_change1 |          reserved_change1                     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                       mac_addr_change1...                     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     ...mac_addr_change1       |          vid_change1          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| flags_change2 |          reserved_change2                     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                       mac_addr_change2...                     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     ...mac_addr_change2       |          vid_change2          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                       ...................                     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| flags_changeM |          reserved_changeM                     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                       mac_addr_changeM...                     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     ...mac_addr_changeM       |          vid_changeM          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The bug is in batadv_tt_tvlv_unicast_handler_v1 when computing the size of the vlans:

				/**
 * batadv_tt_tvlv_unicast_handler_v1() - process incoming (unicast) tt tvlv
 *  container
 * @bat_priv: the bat priv with all the mesh interface information
 * @src: mac address of tt tvlv sender
 * @dst: mac address of tt tvlv recipient
 * @tvlv_value: tvlv buffer containing the tt data
 * @tvlv_value_len: tvlv buffer length
 *
 * Return: NET_RX_DROP if the tt tvlv is to be re-routed, NET_RX_SUCCESS
 * otherwise.
 */
static int batadv_tt_tvlv_unicast_handler_v1(struct batadv_priv *bat_priv,
					     u8 *src, u8 *dst,
					     void *tvlv_value,
					     u16 tvlv_value_len)
{
	struct batadv_tvlv_tt_data *tt_data;
	u16 tt_num_entries;
	u16 tt_vlan_len;
	char tt_flag;
	bool ret;

	if (tvlv_value_len < sizeof(*tt_data))
		return NET_RX_SUCCESS;

	tt_data = tvlv_value;
	tvlv_value_len -= sizeof(*tt_data);

	tt_vlan_len = flex_array_size(tt_data, vlan_data,
				      ntohs(tt_data->num_vlan));

	if (tvlv_value_len < tt_vlan_len)
		return NET_RX_SUCCESS;

	tvlv_value_len -= tt_vlan_len;
	tt_num_entries = batadv_tt_entries(tvlv_value_len);
        [...]
}

The function flex_array_size returns a size_t, which will be truncated when assigned to tt_vlan_len which is a u16. This bug will later cause an out-of-bounds read.

Conclusion

This work showed us the importance of analyzing what was already done and what was not well explored. With this first analysis, we identified the routing spot in batman-adv. Using existing solutions like Syzkaller with its networking utilities and our custom made Syzlang grammar, we managed to find and report an unknown bug. There are also other opportunities to explore in the batman-adv subsystem since we can tweak some parameters such as the protocol version (e.g. this changes the routing algorithm). This ensures that we explore other code paths that could be complex for the fuzzer to setup directly through the normal grammar since mutation of the corpus can take some time.

Sources

Alexis & Lyes

About Us

Founded in 2021, FuzzingLabs is an offensive security company specializing in fuzzing, vulnerability research and reverse engineering on firmware, binaries and embedded systems. Our team has published 20+ CVEs, found over 1,500 bugs and won three Pwn2Own competitions. We also build FuzzForge, an autonomous offensive security platform for continuous validation of firmware, binaries and embedded systems.

Immurok Fingerprint Key Unlocks Linux, Approves SSH And AI Agents

Sat, 12 Sep 2026 22:54:39 +0000

12 Sep, 2026

Immurok Fingerprint Key Unlocks Linux, Approves SSH and AI Agents

2026-09-122026-09-12 Danie

“It is a tiny wireless box that can unlock your desktop session, approve a sudo command, authenticate via polkit, log you into a server over SSH, generate TOTP codes for 2FA, and put a physical touch in front of an AI coding agent. And it does all of that with the same finger, over Bluetooth. The good news is that the core features work. The less good news is that on Linux, getting there was not as simple as touching a sensor.”

So, yes no ready to use graphical interface like Windows, and macOS users get, but it can be setup and got to work, and after that it seems pretty seamless.

You always have your passwords to fall back to, if you leave your finger behind or lose it somewhere.

It is a Kickstarter project, but good to see there is a working review unit, so it is not vaporware.

See https://itsfoss.com/immurok-review

Like this:

Like Loading…

Simon Tatham: "I noticed today that an update to the #Linux #Zoo…" - Hachyderm.io

Sat, 12 Sep 2026 17:53:41 +0000

I noticed today that an update to the #Linux #Zoom client has made it start proactively reading _everything_ written to the X11 clipboard. If you keep interesting secrets in your clipboard – particularly, if a password manager uses it as a means of getting the password to where it needs to be – this might be a thing you need to know about!

Base84 deserves a place in file names - Frank DENIS random thoughts.

Sat, 12 Sep 2026 17:53:41 +0000

The TurboCrypt file encryption tool was originally designed for Unix systems.

And it used to encrypt file names and encode the resulting ciphertext using Base91.

Why Base91? Because it’s a perfect fit for encrypted file names, producing strings that can be stored as valid files on Unix and macOS.

“But my filesystem can store arbitrary file names”! That may be true for some filesystems, but this is without taking libraries and applications into consideration. For example, the macOS Finder would not like this at all.

So, Base91 worked fine for encrypted file and directory names.

Then people asked for Windows support, where several characters in the Unix filesystem-safe alphabet are forbidden.

So, TurboCrypt is switching to Base84.

Something surprisingly not defined nor (apparently) used anywhere, even though it’s a perfect fit for anything that should be encoded as portable filesystem-safe names.

Why Base84?

There are 94 printable ASCII characters excluding the space. But Windows rules exclude nine of them:

< > : " / \ | ? *

That leaves 85.

But a name ending in a dot doesn’t work reliably through the Windows shell and ordinary file APIs.

Remove the dot as well, and we have 84 characters that can appear anywhere in a filename component. Microsoft documents these restrictions.

However, Windows allows a leading dot: .gitignore is fine.

But dropping dots also avoids hidden names on Unix and the special names . and ...

Here’s the alphabet, in encoding order:

ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789!#$%&'()+,-;=@[]^_`{}~

Every character is acceptable in a filename on the usual Linux, macOS and Windows filesystems.

Packing the bits

zig-base84 is an implementation of Base84.

It emits groups of five characters. Five is the sweet spot: 84⁵ = 4,182,119,424, only 2.6% short of 2³².

That leaves enough room for a group to hold 32 bits about 95% of the time on uniformly random input, and 31 bits otherwise.

The encoder looks at the next 31 bits. If their value is below 84⁵ - 2³¹, there’s room for a 32nd bit. Otherwise, it consumes just those 31 bits. Either way, the value fits in five base-84 digits.

On random input, that’s about 31.95 bits per group, or 6.39 bits per character. The output is about 25.2% larger than the binary input. Almost Base85.

These expansion rates ignore the final partial group; the averages assume random input:

An input filled with 0xff forces every full group to consume only 31 bits. That’s the worst case: about 29% expansion.

Most filesystems cap a name at 255 bytes. Since the alphabet is ASCII, that’s 255 characters. Five divides 255 exactly, so even a maximum-length name holds only complete groups, with no bits lost to a partial one. Base84 guarantees room for 197 bytes of input, compared with 191 for unpadded Base64.

Unix-only names

Unix filenames can contain most of the punctuation Windows rejects. NUL and / are forbidden inside a filename; the Linux pathname documentation lists the rules and filesystem-specific limits.

The filesystem variant in zig-base91 replaces the standard Base91 alphabet’s slash with an apostrophe. It packs about 6.51 bits per character on random input, giving roughly 23% expansion.

For Unix-only names, use that variant. Standard Base91 still contains /, and both alphabets contain characters Windows rejects.

Reserved names and case

Windows reserves device names such as CON, NUL and COM1, regardless of case.

The five-character packing has a useful side effect: with the standard alphabet, the encoder can’t spell a reserved device name, even for short inputs.

A three-character output always ends with A through J. That rules out CON, PRN, AUX and NUL, regardless of case.

A four-character output always ends with an uppercase letter or a, b, c. It can’t end with a digit, so COM1 through COM9 and LPT1 through LPT9 are impossible too. The superscript digits Windows also reserves aren’t in the alphabet.

And the alphabet has no dots, so a reserved name followed by an extension is also impossible.

No padding or special handling is needed to avoid these names.

CSF Security Advisory September 2026: Critical Vulnerability and Patch Guide

Sat, 12 Sep 2026 17:00:35 +0000

Expert Care

User Login

Discord Screen Share Broken on KDE Wayland? Here's the fix

Sat, 12 Sep 2026 04:48:56 +0000

So I’m in a call, someone asks me to share my screen, I click the button and… nothing. No error, no dialog, no nothing. Just Discord pretending I never clicked anything. Cool cool cool.

I’m on KDE Plasma + Wayland. And oh, Arch btw (CachyOS specifically). Running the native discord package from pacman. Everything was working perfectly fine like two days ago. What changed? No idea. Something crashed silently. “It just works” said no linux user ever. 🙃

How screen sharing even works on Wayland

Okay so on Wayland, screen sharing goes through this whole chain:

Discord (Electron) → xdg-desktop-portal → KDE portal backend → PipeWire → your screen

Discord asks the portal “hey can I see the screen?”, the portal asks your desktop environment’s backend to handle it, and that backend uses PipeWire to actually grab the pixels. It’s a lot of moving parts. But it works.

The debugging rabbit hole

First thing I checked: are the right Electron flags set? On Wayland, Discord needs these or it won’t even try the proper screen capture path:

discord --enable-features=UseOzonePlatform,WebRTCPipeWireCapturer --ozone-platform=wayland

(These go in your .desktop file’s Exec= line. If you haven’t done this already, do it now.)

But that wasn’t it. I already had these set. Screen share was still completely dead.

So I dug deeper. Is the ScreenCast portal interface even available?

$ dbus-send --session \
    --dest=org.freedesktop.portal.Desktop \
    --type=method_call --print-reply \
    /org/freedesktop/portal/desktop \
    org.freedesktop.DBus.Properties.Get \
    string:org.freedesktop.portal.ScreenCast \
    string:version
Error org.freedesktop.DBus.Error.InvalidArgs: No such interface "org.freedesktop.portal.ScreenCast"

No ScreenCast interface. At all. There it is. The portal literally has no backend that knows how to capture screens. No wonder Discord was doing nothing — there was nothing to do.

The actual problem

Wanna guess?

$ systemctl --user status plasma-xdg-desktop-portal-kde.service
○ plasma-xdg-desktop-portal-kde.service - Xdg Desktop Portal For KDE
     Active: inactive (dead)

Dead. The KDE portal backend was just… dead. This is the service that provides ScreenCast, Screenshot, RemoteDesktop — basically everything screen-related on KDE Plasma. Without it, the only portal running was the GTK one, which doesn’t provide ScreenCast on a KDE session (why would it).

So Discord asks to share screen, the portal goes “I don’t know how to do that”, and Discord goes “okay nevermind” without telling you anything. Super helpful error handling there 🤣

The fix (it’s two commands)

systemctl --user start plasma-xdg-desktop-portal-kde.service
systemctl --user restart xdg-desktop-portal.service

Start the KDE backend, then restart the main portal so it picks up the new backend. You can verify it worked:

$ dbus-send --session \
    --dest=org.freedesktop.portal.Desktop \
    --type=method_call --print-reply \
    /org/freedesktop/portal/desktop \
    org.freedesktop.DBus.Properties.Get \
    string:org.freedesktop.portal.ScreenCast \
    string:version
variant    uint32 5

Restart Discord after this. You should get the KDE screen picker dialog when you try to share. 🎉

But why did it die in the first place?

Here’s the annoying part — plasma-xdg-desktop-portal-kde is a static systemd unit. It doesn’t auto-restart on crash. Your Plasma session starts it once when you log in, and if it crashes mid-session (OOM, random segfault, who knows), it just stays dead. You just lose screen sharing until you notice and manually restart it, or log out and back in.

If this keeps happening to you, check the logs next time:

journalctl --user -u plasma-xdg-desktop-portal-kde

Maybe there’s a pattern. Maybe something is killing it. I haven’t figured that part out yet (added to my infinitely long todo list).

TL;DR

Discord screen share broken on KDE Wayland? Run systemctl --user status plasma-xdg-desktop-portal-kde.service. It’s probably dead. Start it, restart xdg-desktop-portal, restart Discord. Done.

Power grab

Sat, 12 Sep 2026 02:21:37 +0000

Omarchy should not matter. But sadly it does. As a power grab.

If you don’t know what Omarchy is here’s the short summary. David Heinemeier Hansson, creator of RubyOnRails, owner of a software business and millionaire, decided a few months ago to go all in on Linux and – because that’s just his MO – thought that turning his setup into a project made sense. Omarchy is just that: A pretty standard Arch Linux distribution with a handful of configuration files, that Heinemeier Hansson (or DHH as he is often called) wrote, or vibed or whatever. There is nothing wrong with this, custom, opinionated special purpose distributions have been part of the Linux culture for a long time and provide a lot of value and experimentation that sometimes even flows back to the original project. In a way Ubuntu Linux is just that to the basis Debian.

There’s also nothing wrong in more opinionated software – quite the opposite. I do think that RubyOnRails and similar frameworks gained traction especially because they do have a clear idea of how they see the respective problem domain. There’s even the statement “There should be one – and preferably only one – obvious way to do it” in the Zen of Python. Having a strong point of view is not a bad thing in software or in general. The problem is the kind of points of view DHH has.

I don’t want to go into all the gritty details here, Brennan Kenneth Brown did a great job with their article “Normalized Fascism in Open Source: $12 Million Given to DHH“, but here’s the short version. DHH is a racist and a fascist. He recently wrote articles on how there are [Content Warning: massive racism] too many brown people in London these days. In July he wrote an [Content Warning: Racism, anti-romanism] article comparing Roma communities (using a slur for them) to “wolves” that should be “shot”. His X account is also know to be “edgy” in a similar way. A few days ago he posted sort of a manifesto for his set of config files:

There’s even a longer version on the website. Even without a strong background in antifascist literature or history this reads like a fascist creed. About unity and identity. About “holding the line” (against codes of conduct and the rights of marginalized people as the website explains). About how there always needs to be a strong leader who makes the decisions. Given DHH’s other writing this is not a misguided joke, this is how he thinks about the world.

I began this text writing “Omarchy should not matter” but I have not explained why it does. It’s surely not about user numbers (it’s a clunky distro aimed at people who love to cosplay hackers). But it is about power.

DHH has used his connection to CEO’s of tech corporations and his position as influencer to collect up to now above 18 million dollars of funding for Omarchy. He uses that money not for himself (he has enough of that) but to fund certain pieces of Software he uses in his distribution. Like for example the window manager hyprland whose main developer the Omarchy money now funds. What is “Vaxry” known for outside of a niche window manager? He runs a community based around LGBTQ discrimination and participates in that (see the short summary on Drew DeVault’s “Weird Little Guys of FOSS” list). His bigotry is so consistent that he was banned from participating in the Freedesktop.org community where all the other developers of window managers and the free software desktop stack collaborate. And it was long before DHH funded him.

One could see a world where a CEO using his connections to drum up some funding for free software projects would be a good thing. But that’s not the world we live in I am afraid. DHH got 3 million USD from Digital Ocean (a cloud provider) for Omarchy. Basically at the same time where Digital Ocean cancelled their support of Flathub and GNOME that amounted to a value of 50 USD per month.

DHH is using his position and his influence to accumulate donations that he then can distribute to projects that align with his fascist worldview and ambitions. And in a time where many important projects and infrastructures are strapped for cash running just on the goodwill of a handful of people that is increasingly dangerous. Not because its corporate money – a lot of funding for open source comes from corporations, they are after all who are sucking up all the surplus from people’s labor. It’s because this amount of money gives him power.

The Omarchy foundation will be where projects in desperate need of funding will be pointed. And will a project focused on human rights and social justice get funding from our fascist overlord? What kind of pressure can that exert on projects who have to decide to either die due to lack of funding or kill their code of conduct?

An open fascist is building one of the bigger sources of funding for open source fully under his individual control and sucks up a lot of money that otherwise might have gone to liberatory projects. Community projects. Antifascist projects.

And that is why Omarchy matters. Sadly. Not because of its technical merit (even though those fascists love to use the “merit” argument to fight human rights) but because of its leader, his connections and his ability to accumulate financial power. Without anyone in that ecosystem saying anything about how that leader operates and talks. And you might know the saying: If there’s a Nazi and 10 folks sitting together at a table and nobody says and does anything? There’s 11 Nazis at that table.

Omarchy got a lot of recognition recently. Not only by corporate donors but by Youtubers and other tech influencers who kept praising it and nudged people (who might not know about DHH’s exploits) towards testing it. To become “a hardcore linux user/dev” or whatever other chauvinist argument they made. This makes it dangerous.

Running Omarchy means contributing to this dynamic. It means willingly integrating oneself into a fascist community. Legitimizing it. Supporting it. Omarchy is a fascist project that normalizes fascist thinking for everyone entering that community (even unknowingly). The baseline has to be not to use that system. And as people who believe in human rights and dignity, in community and a tech world that can be better we need to oppose Omarchy. Need to make sure it gets no seat at any table. Support projects who actively refuse to collaborate. Support projects who care about human rights and flourishing. And do not do business with the companies who willingly support fascists.

Siamo tutti antifascisti!

(Share this message about Omarchy [or some other similar post] around in the tech circles you frequent. Tell people about the background of this hyped Linux distribution and its fascist leader. Quit your 1password or Digital Ocean accounts and mention that it is because the support fascists.)

Liked it? Take a second to support tante on Patreon!

This work is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License.

39 distributions Linux populaires | Stackscale

Fri, 11 Sep 2026 20:30:23 +0000

Une distribution Linux est un système d’exploitation assemblé autour du noyau Linux, accompagné d’un gestionnaire de paquets, d’outils système et, souvent, d’un environnement de bureau. Toutes partagent le même noyau ; ce qui les sépare, ce sont les choix faits autour de lui — le rythme des mises à jour, la politique de support, le modèle de gouvernance et le public visé.

Cette liste rassemble 39 distributions Linux et systèmes d’exploitation apparentés, avec leur licence et leur dernière version à jour. Certaines y figurent parce qu’elles dominent le marché ; d’autres, parce qu’elles ont été abandonnées et que la question « est-elle encore maintenue ? » se pose encore. Nous les signalons explicitement plutôt que de les retirer.

Ubuntu

Ubuntu est une distribution Linux fondée sur Debian, développée par Canonical et une communauté de développeurs. Elle propose trois éditions officielles — Desktop, Server et Core — qui fonctionnent aussi bien sur un poste de travail que sur une machine virtuelle.

C’est la distribution la plus répandue sur les serveurs web et l’une des plus courantes dans les projets cloud, en grande partie grâce à son cycle LTS de cinq ans, extensible avec Ubuntu Pro.

Licence d’Ubuntu : GPL et autres licences.

Dernière version LTS (septembre 2026) : Ubuntu 26.04 LTS « Resolute Raccoon », publiée le 23 avril 2026. Ubuntu 24.04 LTS reste prise en charge jusqu’en mai 2029.

Debian

Debian est un système d’exploitation libre annoncé par Ian Murdock en 1993. Le projet Debian est une communauté de développeurs et d’utilisateurs qui maintient le système GNU à partir de logiciels libres.

Sa réputation de stabilité en fait la base d’un grand nombre d’autres distributions, Ubuntu comprise, et un choix fréquent pour les serveurs de production.

Licence de Debian : BSD, GPL et autres licences libres.

Dernière version (septembre 2026) : Debian 13 « Trixie », publiée le 9 août 2025 ; version corrective actuelle 13.6.

CentOS Linux

CentOS Linux était une distribution construite à partir du code source de Red Hat Enterprise Linux. Lancée en 2004, elle offrait une compatibilité RHEL sans coût de licence et s’est imposée dans de nombreux parcs de serveurs.

En 2019, Red Hat a annoncé son remplacement par CentOS Stream, ce qui a donné naissance à de nouvelles alternatives open source comme Rocky Linux et AlmaLinux.

Licence de CentOS Linux : GNU GPL.

Projet abandonné : CentOS Linux 8 a atteint sa fin de vie le 31 décembre 2021 et CentOS Linux 7 le 30 juin 2024. Il n’existe pas de successeur sous ce nom — les alternatives sont AlmaLinux, Rocky Linux ou CentOS Stream.

CentOS Stream

CentOS Stream est une plateforme de développement en amont de Red Hat Enterprise Linux : elle reçoit les changements avant qu’ils n’arrivent dans RHEL, au lieu de les répliquer après coup.

Ce positionnement en fait un environnement utile pour anticiper les évolutions de RHEL, mais un choix différent d’un clone stable pour de la production classique.

Licence de CentOS Stream : GNU GPL.

Dernière version (septembre 2026) : CentOS Stream 10, publiée le 12 décembre 2024 et prise en charge jusqu’en mai 2030. CentOS Stream 9 l’est jusqu’en mai 2027.

Red Hat Enterprise Linux (RHEL)

Red Hat Enterprise Linux est la distribution commerciale de Red Hat, disponible en versions serveur et poste de travail. Elle repose sur des logiciels libres mais son abonnement couvre le support, la certification matérielle et les correctifs de sécurité à long terme.

C’est la référence du Linux d’entreprise, en particulier dans les secteurs où la certification des applications tierces est une contrainte.

Licence de Red Hat Enterprise Linux (RHEL) : GPL.

Dernière version (septembre 2026) : RHEL 10, publiée le 20 mai 2025 ; versions mineures en cours 10.2 et 9.8.

Gentoo

Gentoo est une distribution en compilation depuis les sources, à travers son système de paquets Portage. L’utilisateur choisit les options de compilation de chaque composant, ce qui permet d’ajuster finement le système au matériel et à l’usage.

En contrepartie, l’installation et la maintenance demandent nettement plus de temps que sur une distribution binaire.

Licence de Gentoo : logiciel libre.

Publication : rolling release, sans versions numérotées.

Fedora

Fedora est la distribution communautaire soutenue par Red Hat. Elle sert de terrain d’essai aux technologies qui arriveront plus tard dans RHEL, avec un cycle court et une politique stricte de logiciel libre.

Chaque version est prise en charge environ treize mois, ce qui en fait un système d’innovation plutôt qu’un système de production longue durée.

Licence de Fedora : GNU GPL et autres licences.

Dernière version (septembre 2026) : Fedora Linux 44, publiée le 28 avril 2026.

openSUSE

openSUSE est le projet communautaire parrainé par SUSE. Il propose deux approches : Leap, une version stable alignée sur SUSE Linux Enterprise, et Tumbleweed, une rolling release.

Son outil d’administration YaST et son système d’instantanés Btrfs avec retour arrière sont deux de ses signes distinctifs, même si Leap 16 a abandonné YaST.

Licence d’openSUSE : GNU GPL et autres licences.

Dernière version (septembre 2026) : openSUSE Leap 16.0, publiée le 1er octobre 2025.

Scientific Linux

Scientific Linux était une distribution fondée sur RHEL et produite par le Fermilab, avec la participation du CERN, de DESY et de l’ETH Zurich, pour les besoins de calcul scientifique.

Licence de Scientific Linux : GNU GPL.

Projet abandonné : Scientific Linux 7 a atteint sa fin de vie le 30 juin 2024. Le Fermilab recommande de migrer vers AlmaLinux ou CentOS Stream.

CloudLinux

CloudLinux est une distribution commerciale destinée aux hébergeurs mutualisés. Sa technologie LVE isole les ressources de chaque compte, de sorte qu’un site qui consomme trop n’affecte pas les autres du même serveur.

Licence de CloudLinux : GPL et licences propriétaires.

Dernière version (septembre 2026) : CloudLinux OS 10.2, publiée le 26 mai 2026. Depuis la série 10, elle s’installe par-dessus AlmaLinux au moyen de cldeploy, sans image d’installation propre.

elementary OS

elementary OS est une distribution fondée sur Ubuntu LTS, centrée sur la cohérence visuelle et la simplicité. Son environnement de bureau Pantheon et son modèle de paiement libre pour les applications en font l’une des propositions les plus soignées du Linux grand public.

Licence d’elementary OS : GNU GPL et autres licences.

Dernière version (septembre 2026) : elementary OS 8.1.1 « Circe », publiée le 27 février 2026.

Linux Mint

Linux Mint est une distribution fondée sur Ubuntu, souvent recommandée pour la migration depuis Windows grâce à son environnement Cinnamon et à un ensemble d’outils propres particulièrement aboutis.

Le projet maintient également LMDE, une variante bâtie directement sur Debian.

Licence de Linux Mint : GNU GPL et autres licences.

Dernière version (septembre 2026) : Linux Mint 22.3 « Zena », publiée le 11 janvier 2026 et prise en charge jusqu’en avril 2029.

Arch Linux

Arch Linux suit le principe KISS : une base minimale que l’utilisateur construit lui-même, sans couches d’abstraction. Son gestionnaire de paquets pacman et le dépôt communautaire AUR donnent accès à un catalogue logiciel très large.

Sa documentation, l’Arch Wiki, est une référence utilisée bien au-delà de la distribution elle-même.

Licence d’Arch Linux : GNU GPL et autres licences.

Publication : rolling release. L’image d’installation est publiée chaque mois.

Manjaro

Manjaro repose sur Arch Linux mais introduit un délai de validation des paquets et un installateur graphique, ce qui adoucit considérablement la courbe d’entrée tout en conservant l’accès à l’AUR.

Licence de Manjaro : GNU GPL et autres licences.

Dernière version (septembre 2026) : Manjaro 26.1, publiée en août 2026.

Oracle Linux

Oracle Linux est une distribution compatible RHEL distribuée gratuitement, avec un support commercial optionnel. Elle propose son propre noyau optimisé, l’Unbreakable Enterprise Kernel, en plus du noyau compatible Red Hat.

Licence d’Oracle Linux : GNU GPL et autres licences.

Dernière version (septembre 2026) : Oracle Linux 10, publiée en juin 2025 ; mise à jour actuelle 10.2.

Slackware

Slackware est la plus ancienne distribution encore maintenue, créée en 1993 à partir du Softlanding Linux System. Elle revendique la simplicité au sens Unix du terme : peu d’outils d’automatisation, une configuration en fichiers texte et très peu de modifications par rapport aux logiciels d’origine.

Licence de Slackware : GNU GPL.

Dernière version (septembre 2026) : Slackware 15.0, publiée le 3 février 2022 et toujours la version stable en vigueur.

Mageia

Mageia est un système de type Unix né en 2010 d’un fork de Mandriva Linux, créé par d’anciens salariés de Mandriva S.A. et des membres de sa communauté. Le projet met en avant la stabilité et une gouvernance associative.

Licence de Mageia : GNU GPL et autres licences.

Dernière version (septembre 2026) : Mageia 10, publiée le 29 juin 2026.

Clear Linux

Clear Linux OS était une distribution développée par Intel et optimisée pour ses propres processeurs, connue pour ses performances dans les tests de référence et pour son modèle de bundles à la place des paquets classiques.

Licence de Clear Linux : GPL et autres licences.

Projet abandonné : le 18 juillet 2025, Intel a annoncé la fin de Clear Linux OS. Depuis cette date, il ne reçoit plus ni correctifs de sécurité ni maintenance, et son dépôt a été archivé en lecture seule.

Rocky Linux

Rocky Linux est né en réponse à l’arrêt de CentOS Linux, sous l’impulsion de Gregory Kurtzer, cofondateur de CentOS. Il vise une compatibilité binaire avec RHEL et est porté par la Rocky Enterprise Software Foundation.

Licence de Rocky Linux : BSD et autres licences libres.

Dernière version (septembre 2026) : Rocky Linux 10.2, publiée le 28 mai 2026.

AlmaLinux

AlmaLinux OS est l’autre grande réponse à l’arrêt de CentOS Linux, portée par une fondation à but non lucratif. Depuis la version 10, le projet a assumé de ne plus être un clone strict de RHEL : il conserve la compatibilité applicative mais réintègre des pilotes retirés en amont et prend en charge du matériel plus ancien.

Licence d’AlmaLinux : GPLv2 et autres licences.

Dernière version (septembre 2026) : AlmaLinux OS 10.2, publiée le 26 mai 2026.

Asahi Linux

Asahi Linux est le projet de rétro-ingénierie qui porte Linux sur les Mac à puce Apple Silicon. Il fournit les pilotes graphiques et le travail de bas niveau qu’Apple ne documente pas, et se distribue principalement sous la forme de Fedora Asahi Remix.

Licence d’Asahi Linux : GNU GPL et autres licences.

Dernière version (septembre 2026) : Fedora Asahi Remix 44, disponible depuis le 28 avril 2026. Le projet n’est plus en phase alpha.

Lubuntu

Lubuntu est la variante officielle d’Ubuntu avec l’environnement léger LXQt. Elle vise les machines dont les ressources sont limitées ou les déploiements où l’empreinte du bureau doit rester minimale.

Licence de Lubuntu : GNU GPL et autres licences.

Dernière version (septembre 2026) : Lubuntu 26.04 LTS, publiée le 23 avril 2026.

SUSE Linux Enterprise

SUSE Linux Enterprise Server est la distribution commerciale de SUSE, très implantée dans les environnements SAP et dans l’industrie européenne. Elle mise sur des cycles de vie longs et sur les mises à jour du noyau à chaud.

Licence de SUSE Linux Enterprise : GNU GPL et licences propriétaires.

Dernière version (septembre 2026) : SUSE Linux Enterprise Server 16, disponible depuis le 4 novembre 2025. Le dernier service pack de la série 15 est le SP7.

Knoppix

Knoppix a été l’une des premières distributions live à s’exécuter entièrement depuis un CD, sans installation. Elle reste une référence historique pour le diagnostic et la récupération de systèmes.

Licence de Knoppix : licences de logiciel libre.

Dernière version : Knoppix 9.2, de 2021. Le projet n’a publié aucune nouveauté depuis.

VzLinux

VzLinux était une distribution compatible RHEL développée par Virtuozzo, pensée pour les environnements virtualisés et les conteneurs.

Licence de VzLinux : GNU GPL.

Projet sans activité : aucune version ni annonce n’est recensée après 2021.

Peppermint OS

Peppermint OS est une distribution légère qui privilégie une base minimale que l’utilisateur complète à sa guise. Le projet maintient aujourd’hui deux branches : l’une sur Debian, l’autre sans systemd, bâtie sur Devuan.

Licence de Peppermint OS : GNU GPL et autres licences.

Dernière version (septembre 2026) : le projet ne numérote plus ses versions et publie des images datées. La branche Debian 13 date d’octobre 2025 et la branche Devuan 6, sans systemd, de juin 2026.

Zorin OS

Zorin OS est une distribution fondée sur Ubuntu qui soigne particulièrement la transition depuis Windows et macOS, avec des dispositions de bureau imitant l’une ou l’autre. Elle est développée en Irlande.

Licence de Zorin OS : logiciel libre.

Dernière version (septembre 2026) : Zorin OS 18.1, publiée le 15 avril 2026.

BlackArch Linux

BlackArch est un dérivé d’Arch Linux orienté sécurité offensive et tests d’intrusion, avec un dépôt de plusieurs milliers d’outils installable par-dessus une installation Arch existante.

Licence de BlackArch Linux : licences diverses.

Publication : rolling release, avec un dépôt mis à jour en continu.

SUSE Liberty Linux

SUSE Liberty Linux n’était pas une distribution à part entière mais une offre de support : SUSE prenait en charge des installations RHEL ou CentOS existantes, sans migration.

Licence de SUSE Liberty Linux : support commercial.

La marque a disparu : SUSE a intégré Liberty Linux dans son offre SUSE Multi-Linux Support, qui continue d’assurer le support des installations RHEL et CentOS.

Navy Linux

Navy Linux était une distribution d’entreprise compatible RHEL, apparue elle aussi dans le sillage de l’arrêt de CentOS Linux.

Licence de Navy Linux : GNU GPL.

Projet sans activité : la dernière version, Navy Linux 8.6, date de mai 2022.

Tizen

Tizen est un système fondé sur le noyau Linux, porté par la Linux Foundation et Samsung. On le trouve surtout sur les téléviseurs, les montres connectées et l’électroménager, plus que sur des ordinateurs.

Licence de Tizen : GPLv2, LGPL, Apache License 2.0, BSD et autres.

Dernière version (septembre 2026) : Tizen 10.0, présente sur la gamme de téléviseurs Samsung 2026.

Distributions immuables et orientées conteneurs

Les distributions ci-dessus sont des systèmes polyvalents. Depuis 2020, une seconde famille s’est développée sur un principe différent : des systèmes à racine immuable, sans gestionnaire de paquets traditionnel, mis à jour de façon atomique et configurés de manière déclarative. On ne les administre pas, on les déploie. Elles soutiennent une grande partie de l’infrastructure de conteneurs actuelle et méritent une section à part.

Alpine Linux

Alpine Linux est une distribution minimaliste bâtie sur musl libc et BusyBox plutôt que sur la glibc et les GNU coreutils. Ce choix ramène une image de base à quelques mégaoctets, ce qui en a fait le point de départ de fait des images de conteneurs : une grande partie de ce qui tourne aujourd’hui sur Docker et Kubernetes démarre depuis une couche Alpine.

Sa taille et sa surface d’attaque réduite expliquent son adoption, mais musl n’est pas totalement compatible avec la glibc et certaines applications livrées en binaires précompilés demandent des ajustements.

Licence d’Alpine Linux : GNU GPL et autres licences.

Dernière version (septembre 2026) : Alpine Linux 3.24, publiée le 9 juin 2026.

NixOS

NixOS pousse l’infrastructure as code jusqu’au système d’exploitation lui-même : toute la configuration de la machine — paquets, services, utilisateurs, réseau — est déclarée dans des fichiers, et le système est construit à partir d’eux. Deux machines partageant la même configuration sont identiques, et chaque changement produit une nouvelle génération amorçable.

Revenir sur une mise à jour ratée revient donc à choisir la génération précédente dans le menu de démarrage. C’est la distribution à la courbe d’apprentissage la plus raide de cette liste, mais elle traite la dérive de configuration à la racine.

Licence de NixOS : MIT.

Dernière version (septembre 2026) : NixOS 26.05 « Yarara », publiée le 30 mai 2026.

Fedora CoreOS

Fedora CoreOS est un système minimal, immuable et à mise à jour automatique, conçu exclusivement pour exécuter des conteneurs. Le système de fichiers racine est en lecture seule, les mises à jour s’appliquent de façon atomique via rpm-ostree et la configuration initiale se déclare avec Ignition au premier démarrage.

Il succède à Container Linux dans l’écosystème Fedora et sert de laboratoire au modèle d’image que Red Hat a ensuite porté dans RHEL.

Licence de Fedora CoreOS : GNU GPL et autres licences.

Dernière version (septembre 2026) : flux continu bâti sur Fedora Linux 44. Le projet ne publie pas de versions à support long terme.

Flatcar Container Linux

Flatcar Container Linux est la continuation ouverte de Container Linux après son arrêt, maintenue comme projet de la CNCF. Elle partage l’approche de Fedora CoreOS — système immuable, sans gestionnaire de paquets, dédié aux conteneurs — mais applique ses mises à jour par partitions A/B : la nouvelle version est écrite sur la partition inactive et activée au redémarrage, de sorte qu’un échec ramène au démarrage précédent.

Licence de Flatcar Container Linux : Apache License 2.0.

Dernière version stable (septembre 2026) : Flatcar 4593.2.5, du 13 août 2026.

Talos Linux

Talos Linux est un système d’exploitation conçu pour une seule chose : être un nœud Kubernetes. Il n’a ni shell, ni SSH, ni gestionnaire de paquets, et s’administre entièrement par une API gRPC authentifiée. Cela supprime d’emblée une bonne part de la surface d’attaque d’un nœud classique et rend la configuration du cluster reproductible par construction.

La contrepartie est la rigidité : on n’ouvre pas une session sur un nœud Talos pour déboguer à la main. Il convient aux clusters durcis et homogènes, pas aux serveurs polyvalents.

Licence de Talos Linux : Mozilla Public License 2.0.

Dernière version (septembre 2026) : Talos Linux 1.14.0, du 3 septembre 2026.

SUSE Linux Micro

SUSE Linux Micro est la proposition immuable de SUSE pour l’edge et comme hôte de conteneurs. Elle utilise des mises à jour transactionnelles sur Btrfs : chaque changement s’applique dans un instantané distinct qui ne devient le système actif qu’après un redémarrage réussi, avec retour arrière automatique en cas d’échec.

Elle complète le portefeuille de SUSE aux côtés de SUSE Linux Enterprise Server 16 et dispose d’un équivalent communautaire, openSUSE Leap Micro.

Licence de SUSE Linux Micro : GNU GPL et autres licences.

Dernière version (septembre 2026) : SUSE Linux Micro 6.2.

Amazon Linux

Amazon Linux est la distribution qu’AWS maintient et optimise pour ses propres instances, avec une intégration directe aux services et aux outils du fournisseur. Amazon Linux 2023 est la génération actuelle, avec une version majeure tous les deux ans et cinq ans de support.

Un point pratique mérite d’être signalé : Amazon Linux 2 a atteint sa fin de vie le 30 juin 2026, de sorte que les charges encore hébergées sur cette version sont aujourd’hui sans support et en attente de migration.

Licence d’Amazon Linux : licence Amazon fondée sur des logiciels open source.

Dernière version (septembre 2026) : Amazon Linux 2023, prise en charge jusqu’au 30 juin 2029.

Proxmox VE

Proxmox Virtual Environment n’est pas une distribution polyvalente mais une plateforme de virtualisation bâtie sur Debian, qui combine KVM pour les machines virtuelles et LXC pour les conteneurs système, avec le stockage distribué Ceph et la haute disponibilité intégrés, le tout administré depuis sa propre interface web.

Elle est devenue une référence européenne dans la discussion sur les alternatives ouvertes aux plateformes de virtualisation propriétaires, et sa base Debian garde l’administration sous-jacente familière. Chez Stackscale, nous déployons et exploitons Proxmox VE sur une infrastructure dédiée.

Licence de Proxmox VE : GNU AGPLv3.

Dernière version (septembre 2026) : Proxmox VE 9.2, du 21 mai 2026.

Liste des distributions Linux populaires

Voici la liste des distributions Linux présentées, par ordre alphabétique :

Distribution Linux	Licence	Dernière version (en septembre 2026)
AlmaLinux	GPLv2 et autres licences	AlmaLinux OS 10.2 (mai 2026)
Alpine Linux	GNU GPL et autres licences	Alpine Linux 3.24 (juin 2026)
Amazon Linux	licence Amazon fondée sur l’open source	Amazon Linux 2023
Arch Linux	GNU GPL et autres licences	Rolling release
Asahi Linux	GNU GPL et autres licences	Fedora Asahi Remix 44 (avril 2026)
BlackArch Linux	licences diverses	Rolling release
CentOS Linux	GNU GPL	Abandonnée — fin de vie 31/12/2021
CentOS Stream	GNU GPL	CentOS Stream 10 (décembre 2024)
Clear Linux	GPL et autres licences	Abandonnée — Intel, 18/07/2025
CloudLinux	GPL et licences propriétaires	CloudLinux OS 10.2 (mai 2026)
Debian	BSD, GPL et autres licences libres	Debian 13 « Trixie » (août 2025)
elementary OS	GNU GPL et autres licences	elementary OS 8.1.1 « Circe » (février 2026)
Fedora	GNU GPL et autres licences	Fedora Linux 44 (avril 2026)
Fedora CoreOS	GNU GPL et autres licences	Fedora CoreOS 44 (flux continu)
Flatcar Container Linux	Apache License 2.0	Flatcar 4593.2.5 (août 2026)
Gentoo	logiciel libre	Rolling release
Knoppix	licences de logiciel libre	Knoppix 9.2 (2021) — sans activité
Linux Mint	GNU GPL et autres licences	Linux Mint 22.3 « Zena » (janvier 2026)
Lubuntu	GNU GPL et autres licences	Lubuntu 26.04 LTS (avril 2026)
Mageia	GNU GPL et autres licences	Mageia 10 (juin 2026)
Manjaro	GNU GPL et autres licences	Manjaro 26.1 (août 2026)
Navy Linux	GNU GPL	Sans activité — dernière 8.6 (2022)
NixOS	MIT	NixOS 26.05 « Yarara » (mai 2026)
openSUSE	GNU GPL et autres licences	openSUSE Leap 16.0 (octobre 2025)
Oracle Linux	GNU GPL et autres licences	Oracle Linux 10 (juin 2025)
Peppermint OS	GNU GPL et autres licences	Images datées (Debian 13 / Devuan 6)
Proxmox VE	GNU AGPLv3	Proxmox VE 9.2 (mai 2026)
Red Hat Enterprise Linux	GPL	RHEL 10 (mai 2025)
Rocky Linux	BSD et autres licences libres	Rocky Linux 10.2 (mai 2026)
Scientific Linux	GNU GPL	Abandonnée — fin de vie 30/06/2024
Slackware	GNU GPL	Slackware 15.0 (février 2022)
SUSE Liberty Linux	support commercial	Intégrée dans SUSE Multi-Linux Support
SUSE Linux Enterprise	GNU GPL et licences propriétaires	SUSE Linux Enterprise Server 16 (novembre 2025)
SUSE Linux Micro	GNU GPL et autres licences	SUSE Linux Micro 6.2
Talos Linux	Mozilla Public License 2.0	Talos Linux 1.14 (septembre 2026)
Tizen	GPLv2, LGPL, Apache 2.0, BSD et autres	Tizen 10.0 (2026)
Ubuntu	GPL et autres licences	Ubuntu 26.04 LTS (avril 2026)
VzLinux	GNU GPL	Sans activité — dernière 8.5 (2021)
Zorin OS	logiciel libre	Zorin OS 18.1 (avril 2026)

Sur la page suivante, vous pouvez consulter les statistiques des distributions Linux les plus utilisées au cours de la dernière décennie. Et pour vérifier au jour le jour les versions, les dates de publication et les fins de support de chaque système, le répertoire Linux Gratis tient une fiche par distribution, pour plus de deux cents systèmes d’exploitation, mise à jour en continu.

C'est toujours une histoire de budget

Fri, 11 Sep 2026 18:29:01 +0000

En 2010 ou en 2011, dans le cadre d'une conférence organisé par l'association Aristote j'avais engagé la conversation avec un colonel de la Gendarmerie Nationale. À l'époque, je travaillais pour Mozilla messaging et la gendarmerie utilisait Thunderbird, car celui-ci gérait les ACLs au niveau imap. Nous avions alors discuté du pourquoi du comment la gendarmerie était passée à Linux.

On m'avait alors expliqué, que comme beaucoup d'entreprises, le pole informatique gérait aussi les télécommunications. Les communications pour la gendarmerie, c'est être capable d'envoyer des messages depuis une ile perdue du pacifique ou depuis le fin fond de la forêt tropicale guyanaise. Une très grosse partie du budget de ce service partait donc dans les équipements télécoms. La mise à niveau de l'OS de Microsoft ne rentrait pas dans le budget. Après une maquette rapide, la décision avait été prise de :

Déployer Genbuntu sur les machines de services
Mettre la distribution à disposition des gendarmes dans un cadre privé (pour utiliser la même chose à la maison qu'au travail)

Desktop software I use June 2025 edition

Fri, 11 Sep 2026 18:29:00 +0000

I currently run Fedora 42 as my main work and private machine.

Desktop software:

Firefox for work because that's the only viable alternative
Firefox nightly because testing releases is important and a very easy way to contribute
Thunderbird, so I can read four email accounts at the same time and get notifications
NewsFlash because I *need* an RSS feed reader.
Hexchat - because I still use IRC (three different networks)
Papers because I like the idea of a Rust based PDF viewer
Google chrome because I need to access teams meetings once in a while
Chromium so I can play TTRPG with foundryvtt

Command line tools:

Podman I'm trying not to use docker to see if it's viable on my new work machine
jq, awk, cat , less and normal unix tools.
lnav for log reading
atuin for shell history management
fish as my default shell

August 2026 ClangBuiltLinux Work | Nathan Chancellor

Fri, 11 Sep 2026 14:18:14 +0000

Occasionally, I will forget to link something from the mailing list in this post. To see my full mailing list activity (patches, reviews, and reports), you can view it on lore.kernel.org.

Linux kernel patches#

Build errors: These are patches to fix various build errors that I found through testing different configurations with LLVM or were exposed by our continuous integration setup. The kernel needs to build in order to be run :)
- thermal/drivers/qcom-spmi-mbg-tm: Add module namespace import for IIO_CONSUMER (v1)
- net: macb: Move macb_{alloc,free}_tieoff() out of CONFIG_OF block (v1)
Miscellaneous fixes and improvements: These are fixes and improvements that don’t fit into a particular category but matter in some way to my other work.
- ARM: Fix get_cycles() after delay_read_timer() conversion (v1)
Stable backports and fixes: It is important to make sure that the stable trees are as free from issues as possible, as those are the trees that devices and users use; for example, Android and Chrome OS regularly merge from stable, so if there is a problem that will impact those trees that we fixed in mainline, it should be backported.
- Backports of c1f3e770eec26d6f96dd6d2ea30555ba7c09a244 for 6.6 and 6.1
- [PATCH 6.12 0/2] Backport of 6ee149f61bcce39692f0335a01e99355d4cec8da
Warning fixes: These are patches to fix various warnings that appear with LLVM. I used to go into detail about the different warnings and what they mean, but the important takeaway for this section is that the kernel should build warning free, as all developers should be using CONFIG_WERROR, which will turn these all into failures. Maybe these should be in the build failures section…
- swim3: Add missing MODULE_DESCRIPTION (v1)
- scsi: qla2xxx: Fix size_t format specifier in qla29xx_process_rd_image() (v1)
- arch_numa: Avoid false positive fortify warning in setup_node_to_cpumask_map() (v1, v2)
- scsi: ibmvfc: Fix use of uninitialized rport in ibmvfc_do_work() (v1)
- scripts/sorttable: Mark long_size as __maybe_unused (v1)

Patch handling, review, and input#

For the next sections, I link directly to my first response in the thread when possible but there are times where the link is to the main post. My responses can be seen inline by going to the bottom of the thread and clicking on my name.

Reviewing patches that are submitted is incredibly important, as it helps ensure good code quality due to catching mistakes before the patches get accepted and it can help get patches accepted faster, as some maintainers will blindly pick up patches that have been reviewed by someone that they trust.

Issue triage, input, and reporting#

The unfortunate thing about working at the intersection of two projects is we will often find bugs that are not strictly related to the project, which require some triage and reporting back to the original author of the breakage so that they can be fixed and not impact our own testing. Some of these bugs fall into that category while others are issues strictly related to this project.

Tooling improvements#

These are changes to various tools that we use, such as our continuous integration setup, booting utilities, toolchain building scripts, or other closely related projects such as AOSP’s distribution of LLVM and TuxMake.

Behind the scenes#

Every day that there is a new linux-next release, I rebase and build a few different kernel trees then boot and runtime test them on several different machines, including a SolidRun Honeycomb LX2, an Ampere Altra Developer Platform, four Intel-based devices, and two AMD-based devices. This is not always visible because I do not report anything unless there is something broken but it can take up to a few hours each day, depending on the amount of churn and issues uncovered.
I continue to upload prebuilt, fast versions of LLVM for kernel developers and our continuous integration to use.
- 23.1.0-rc3
- 23.1.0
I developed a solid, working prototype for the third generation of ClangBuiltLinux continuous integration to permit moving to infrastructure that we have full authority over.

Special thanks#

Special thanks to Google and the Linux Foundation for sponsoring my work.

Un ingeniero de ARM optimiza la compilación de Linux a partir de código «horrible» generado por IA

Fri, 11 Sep 2026 10:53:32 +0000

La inteligencia artificial puede ayudar a mejorar Linux, aunque el código que genera deje bastante que desear. Es lo que cuenta Lorenzo Stoakes, ingeniero de ARM y veterano desarrollador del kernel, que ha presentado una serie de 23 parches para acelerar su compilación tras apoyarse en un modelo de lenguaje para localizar y resolver cuellos de botella.

Según recoge Phoronix, el problema está en distintas fases del proceso de compilación que se ejecutan en un solo hilo y que terminan frenando el conjunto, por lo que el trabajo realizado por Stoakes se centra en paralelizar esas tareas y mejorar la eficiencia del proceso, con resultados que, de acuerdo con las pruebas publicadas, pueden llegar a ser considerables.

En concreto, Stoakes señala una compilación alrededor de un 36 % más rápida con todos los módulos habilitados, hasta un 70 % más rápida en compilaciones incrementales y hasta aproximadamente un 90 % en las denominadas «noop», aquellas en las que no hay cambios que compilar, aunque conviene aclarar que ese último porcentaje no describe lo que se tarda en construir el kernel desde cero.

Por lo demás, los cambios afectan a diferentes piezas de la infraestructura de compilación de Linux, entre ellas Kbuild, kallsyms, modpost, objtool y mksysmap, además del sistema de compilación de Rust. La propuesta abarca, por tanto, varios puntos del proceso, y las pruebas recogidas en la noticia muestran mejoras con distintas configuraciones del kernel y equipos.

Hasta aquí, lo que viene a ser una optimización técnica con cifras llamativas. Lo particular de este caso, sin embargo, es cómo se ha llegado a ese resultado y la franqueza con la que lo explica su autor: la IA generó mucho código, buena parte del cual califica de «horrible». Stoakes no especifica qué modelo utilizó, pero sí detalla que lo empleó primero para localizar los cuellos de botella y después para buscar cómo corregirlos.

La IA hizo más que «simplemente» escribir código, ya que también coordinó compilaciones, pruebas, depuración y análisis. Vamos, que le faltó ponerse el prompt a sí misma. Por su parte, el desarrollador asegura haber auditado extensamente y reescrito buena parte del resultado y haber revisado en profundidad los mensajes de los commits, la presentación de la propuesta y los comentarios del código.

Pero la intervención humana va un poco más allá y Stoakes afirma haber comprobado manualmente tanto la compilación como el funcionamiento de los kernels generados con estos cambios, así como haber verificado las mejoras de rendimiento. Además, para dejar constancia del uso de IA, todos los commits incluyen una etiqueta «Assisted-by».

¿Y ahora? La serie de parches se ha presentado para revisión, por lo que todavía habrá que ver qué termina incorporándose al kernel. De momento, el caso deja un ejemplo interesante del uso de estas herramientas en su desarrollo, con resultados prometedores y un trabajo de revisión y corrección humana que el propio autor se ha encargado de subrayar. Un capítulo más en la historia de la IA en Linux.

La entrada Un ingeniero de ARM optimiza la compilación de Linux a partir de código «horrible» generado por IA es original de MuyLinux

Roastidio.us Tagged with linux

Clean your Mac & Windows/Linux PC with Disk Space – SOS

Let’s get nerdy

MacOS

Windows

Linux

Epilogue

Switching to GNU Guix: a beginner’s perspective

Network Subsystem | Internals for Interns

Four layers, four headers

The arrival

How the card and the kernel share memory

One object does all the travelling

GRO: Generic Receive Offload

Who does this packet belong to?

IP

TCP

recv() finally returns

The way out

Deciding when to send

Headers, added backwards

Sending to the card

Summary

Durable AI agent execution beyond terminal sessions · vincent

The terminal should not own the work

Finally: Some Pricing Information On The Power S1112 Entry Server

Any Nix package, live in your browser

Dropping eBPF CPU Cost by About 90% With Memoization (Not AI Gen) :: nathan naveen

The Problem

What’s in the Cache?

Performance Changes

Edge Cases

Final Thoughts

Setting up CachyOS on a ThinkPad T14s Gen 1 AMD with LUKS2, BTRFS, Limine and Sway

The hardware

Before you copy anything

1. Verify the environment

2. Partition the disk

3. Create and open the LUKS2 container

4. Create the Btrfs filesystem

5. Mount everything for installation

6. Create a Btrfs swapfile for hibernation

7. Install the base system

8. Configure encrypted boot

9. Enable core services

10. Set hostname, locale and timezone

11. Create the user

12. Configure root SSH key access

13. Install Sway and basic desktop packages

14. Configure Ly with cmatrix

15. Reboot

Known issues from this install

Reference values from my install

How to Sandbox a Linux Process with Landlock, No Root Required

Table of Contents

What You Need

Where Landlock Sits

Three System Calls and No Library

A Program That Restricts Itself

Why no_new_privs is Mandatory

Rulesets Intersect, They Never Widen

What Your Children Inherit

The exec Trap

Wrapping a Program You Didn't Write

Finding the Paths a Program Needs

Which ABI Version You Have

Conclusion

Epilogue

Sorry, Wrong Number: Debugging a Crash under Wine

Tracing the CALL

What is a pseudo relocation?

What is a normal relocation?

Microsoft Windows vs. everything else

What a pseudo-relocation is.

Digging Deeper

Wine under GDB

One last thing...

Linux 7.3-rc2 Arrives Heavier Than Usual, With Torvalds Joking the Blame Falls on AI

Linux 7.3-rc2 Fixes and Torvalds on Its Unusual Size

AI-Generated Linux Kernel Patches and Review Pressure

`recv()` finally returns

Why `no_new_privs` is Mandatory

The `exec` Trap

Sandboxed Containers with `guix shell`

Slow `guix pull` and Source Builds

2. Running Ephemeral Toolchains via `guix shell`

3. Generating Definitions with `guix import`