Generic Linux distributions (i.e. Debian, Fedora, Ubuntu, …) adopted Full Disk Encryption (FDE) more than 15 years ago, with the LUKS/cryptsetup infrastructure. It was a big step forward to a more secure environment. Almost ten years ago the big distributions started adding UEFI SecureBoot to their boot process. Support for Trusted Platform Modules (TPMs) has been added to the distributions a long time ago as well — but even though many PCs/laptops these days have TPM chips on-board it’s generally not used in the default setup of generic Linux distributions.
How these technologies currently fit together on generic Linux distributions doesn’t really make too much sense to me — and falls short of what they could actually deliver. In this story I’d like to have a closer look at why I think that, and what I propose to do about it.
In Linux there are so many permission mechanisms, depending on exactly what you want to do, it dazzles the mind. There is suid, dbus policies, polkit, Linux capabilities, files attributes, PAM modules, SELinux and the list goes on. It does not surprise then, that choosing the correct approach can become paralyzing or give anxiety inducing.
The Framework laptop is the first laptop to ever score a 10⁄10 from Ifixit for repairability. But it’s no thick-as-a-brick throwback the size of a 2005 Thinkpad – it’s approximately the same dimensions as a MacBook.
This is just a random note to let people know that today is actually
one of the core 30-year anniversary dates: 0.01 was uploaded Sept 17,
Now, that 0.01 release was never publicly announced, and I only
emailed a handful of people in private about the upload (and I don’t
have old emails from those days), so there’s no real record of that.
The only record of the date is in the Linux-0.01 tar-file itself, I
Alas, the dates in that tar-file are for the last modification dates,
not the actual creation of the tar-file, but it does seem to have
happened around 7:30pm (Finnish time), so the exact anniversary was
technically a couple of hours ago.
Just thought I’d mention it, since while unannounced, in many ways
this is the true 30th anniversary date of the actual code.
The Debian Janitor is an automated system that commits fixes for (minor) issues in Debian packages that can be fixed by software. It gradually started proposing merges in early December. The first set of changes sent out ran lintian-brush on sid packages maintained in Git. This post is part of a series about the progress of the Janitor.
As I noted in my last blog, I have been working on a set of tools which enable the building of so-called “distroless” images based on Alpine. These tools have now evolved to a point where they are usable for testing in lab environments, thus I am happy to announce the witchery project.
For the uninitiated, a “distroless” image is one which contains only the application and its dependencies. This has some desirable qualities: since the image is only the application and its immediate dependencies, there is less attack surface to worry about. For example, a simple hello-world application built with witchery clocks in at 619kB, while that same hello-world application deployed on
alpine:3.14clocks in at 5.6MB. There are also drawbacks: a distroless image typically does not include a package manager, so there is generally no ability to add new packages to a distroless image.
Languages don’t enjoy long lives. Very few people still code with the legacies of the 1970s: ML, Pascal, Scheme, Smalltalk. (The C language is still widely used but in significantly updated versions.) Bucking that trend, the 1977 Unix utility Awk can boast of a loyal band of users and seems poised to continue far into the future. In this article, I’ll explain what makes Awk special and keeps it relevant.
With the release of the 5.14 kernel, the Linux community celebrates 30 years since the birth of the biggest collaborative software project in the world. Since then, this open collaboration by thousands of engineers has produced an operating system kernel that is more reliable, efficient, and better suited for countless applications than any single organization could ever achieve.
While the high quality of this huge collaborative effort is definitely apparent by the widespread presence of Linux in the market today, this also means there is an ever-increasing interest in more modern hardware support, as well as a more reliable kernel that is thoroughly tested. This is where Collabora’s developers come in to help make this a reality. Here’s a look at their contributions to this latest kernel release.
Being worked on for several years now on the Linux desktop has been high resolution scrolling including work for it around X Input, the libinput library used both by X.Org and Wayland systems, and the kernel driver side for the HID/input devices to support it. The latest user-space work is high resolution scroll wheel support within the next libinput release. Separately, with Linux 5.15 is now additionally support for high resolution scrolling with the Apple Magic Mouse.
Peter Hutterer of Red Hat who serves as the Linux input expert and is responsible for much of the high resolution scrolling work released libinput 1.18-rc1. With this new snapshot there is support for hold gestures and high resolution scroll wheel support. Peter notes in that announcement that the high resolution wheel scrolling replaces the earlier pointer axis API.
I have been using the awesome window manager for 10 years. It is a tiling window manager, configurable and extendable with the Lua language. Using a general-purpose programming language to configure every aspect is a double-edged sword. Due to laziness and the apparent difficulty of adapting my configuration—about 3000 lines—to newer releases, I was stuck with the 3.4 version, whose last release is from 2013.
It was time for a rewrite. Instead, I have switched to the i3 window manager, lured by the possibility to migrate to Wayland and Sway later with minimal pain. Using an embedded interpreter for configuration is not as important to me as it was in the past: it brings both complexity and brittleness.
Linux is celebrating its 30-year anniversary today, so I’m taking the opportunity to highlight 30 of my favorite free and open source Linux games, their communities, and their stories!
If you like RTS, FPS, space trading, roguelike, racing, strategy, or platform games then you’re bound to find something you like below. Oh, and some of the games work on Windows and macOS too, so there should be something for (almost) everyone.
The purpose of these articles is to describe how to build, from the official Raspbian Linux release, a truly minimal Linux, with a read-only root filessytem. The first article describes how to boot to a root shell. No
init, no package manager, no users – nothing. Just a
#prompt. This set-up will be used as the basis for a more useful Linux installation, including lightweight X support, in due course.
One of the ways I learn is by reading and sometimes rewriting other people’s scripts. Here I learn more about
jqby rewriting a friend’s password CLI script.
My friend Christian Drumm published a nice post this week on Adapting the Bitwarden CLI with Shell Scripting, where he shared a script he wrote to conveniently grab passwords into his paste buffer at the command line.
It’s a good read and contains some nice CLI animations too. In the summary, Christian remarks that there may be some areas for improvement. I don’t know about that, and I’m certainly no “shell scripting magician” but I thought I’d have a go at modifying the script to perhaps introduce some further Bash shell,
fzffeatures to dig into.
With this initial release for Debian Bullseye the Freedombone project changes to a new domain with a new name: LibreServer at libreserver.org. Although the name has changed the goal remains substantially the same - to make it easier to self-host internet services on low cost hardware that you personally own and control. It’s about having some place on the internet which is genuinely yours, and where Google or Facebook are not acting as gatekeepers or bridge trolls. Getting back to the idea of the internet as a network of peers with a better balance of power.
So, you want to write a kernel module. You know C, you have written a few normal programs to run as processes, and now you want to get to where the real action is, to where a single wild pointer can wipe out your file system and a core dump means a reboot.
What exactly is a kernel module? Modules are pieces of code that can be loaded and unloaded into the kernel upon demand. They extend the functionality of the kernel without the need to reboot the system. For example, one type of module is the device driver, which allows the kernel to access hardware connected to the system. Without modules, we would have to build monolithic kernels and add new functionality directly into the kernel image. Besides having larger kernels, this has the disadvantage of requiring us to rebuild and reboot the kernel every time we want new functionality.
On UNIX-like operating systems, userland processes invoke kernel procedures using the “syscall” feature. Each syscall is identified by a “syscall number” and has a short list of parameters, which both can vary betwen operating systems, hardware platforms, and configuration options.
Performing a syscall is usually done via a special assembly instruction, though some platforms use other mechanisms (e.g. a vDSO). This page is a catalog of how to invoke syscalls on different UNIX-like platforms.