tag: #linux

sudo's oldest weakness is structural - it is a large setuid program that starts as root holding a process the untrusted user built. run0, from systemd 256, escalates the opposite way, by asking the already-privileged systemd to spawn a clean process with no inherited context and no setuid anywhere. Here is the real architectural difference, when it matters, and why sudo still wins for automation.

Every service on your box runs with far more power than it needs. systemd has a full sandboxing toolkit built into the service manager that strips a service down to what it actually requires, no extra software, just directives in the unit. Almost nobody uses it. Run systemd-analyze security once and you will see why that is a problem.

Everyone learns SSH keys and stops at authorized_keys. That is exactly the part that does not scale and cannot be revoked cleanly. SSH has had a certificate authority for over a decade that fixes both, kills the host-key TOFU prompt, and gives every login an expiry. Almost nobody uses it. Here is why you should.

A symlink vanishes and the normal logs say nothing. syslog and the journal record what programs choose to say. auditd records what the kernel actually did in the syscall path. That is why it names the culprit, and why it only works if you turned it on first.

Building Linux From Scratch means living without a package manager for the duration, and the absence teaches you what the presence was doing all along. apt install is one command. Underneath it is dependency resolution, ordering, conflict detection, file tracking, and clean removal, all of which you do by hand under LFS, and all of which you stop noticing the moment you have a package manager to do them for you.

Seven years ago I built Linux From Scratch for the first time and understood maybe sixty percent of what I was doing. Last week I built it again on 13.0-systemd, and the second build turned out to be the clearest benchmark I have of what seven years of this work actually added up to.

The follow-up to running Ubuntu Touch on a Fairphone 4 is the feature that actually distinguishes it from every mainstream phone. Plug the phone into a monitor over USB-C, pair a Bluetooth keyboard, and the phone becomes a desktop computer. The phone's own touchscreen then works as the trackpad. This is convergence, and once it works, it changes what the phone is for.

top tells you a process is busy. It does not tell you why. The perf toolchain, plus a handful of eBPF-based tools, answer the why at the level of functions, cache misses, and individual block-device latencies. This is the advanced layer, for when the basic tools have already told you which process to look at.

bcachefs is, on technical merit, the most interesting copy-on-write filesystem to arrive on Linux in a decade. It is also, as of Linux 6.18, no longer in the kernel, ejected after a governance dispute between its author and Linus Torvalds and now shipping as a DKMS module like ZFS. This is the story of a filesystem whose engineering and whose politics point in opposite directions, and what that means for anyone deciding whether to run it.

I run Ubuntu Touch on a Fairphone 4 as my actual phone. It is a good experience, better than the skeptics assume and worse than the enthusiasts claim. Waydroid runs most Android apps, microG handles most of the apps that expect Google services, and the one real cost is that backups do not work the way you are used to. This is the honest writeup.