jutty.dev

jaq: polyglot jq clone

2026-06-18T07:07:13-03:00

kage: Clone rendered websites locally

2026-06-18T06:53:44-03:00

Junited 2026

2026-06-06T19:05:32-03:00

Scoped Commits

2026-06-05T21:03:09-03:00

The Virtual OS Museum

2026-05-28T01:40:04-03:00

rura: TUI for building shell pipelines

2026-05-28T01:01:26-03:00

No Ghosts!

2026-05-27T23:33:34-03:00

computers should be liberating

2026-05-27T23:22:32-03:00

A poet and a scientist on what programming even is

2026-05-27T13:13:22-03:00

I was reading this piece, I am not a Software Engineer</a> by Andrew Golding, and had just skimmed through Peter Naur’s Programming as Theory Building</a>. The two immediately connected in my mind, both eloquent and poignant in different ways.

The author says they’re not a software engineer. Perhaps a poet? There is a certain cadence and symbology going on, a certain feeling expressed and reflection on the meaning of more than a few words. My own poet’s heart could feel it. It’s not a rehash of “programmers are not engineers”, it’s actually setting the term aside for what perhaps it always meant, or came to mean, accurate or not per a dictionary.

If software engineering is making code spit itself and not even care what or how it’s spitting, it still would likely offend any engineer to call it as such, but then it might also drift from what the converted ex-programmer signed up for.

I’ve personally always preferred the term programmer, which I suppose the LinkedIn Software Engineer would consider merely the act of writing code. This seems to miss the mark even if you go back several years, with Naur here defining it as “the whole activity of design and implementation of programmed solutions” in 1985. That makes you ask, then, what is software engineering and if you try the “official” route you’ll read things like “sound engineering principles” (Sommerville) and “systematic, disciplined, quantifiable” (IEEE), but the actual trend is moving farther and farther away from this ideal. At its core, it is still “design and implementation”, with the notion of its distinctive feature being rigor having historically failed and now become laughable.

But what if even programming had never been just design and implementation of computer programs?

Naur strikes at the core of it:

programming properly should be regarded as an activity by which the programmers form or achieve a certain kind of insight, a theory, of the matters at hand. This suggestion is in contrast to what appears to be a more common notion, that programming should be regarded as a production of a program and certain other texts. </blockquote>
He then goes on to describe what he means by theory:

What characterizes intellectual activity, over and beyond activity that is merely intelligent, is the person’s building and having a theory, where theory is understood as the knowledge a person must have in order not only to do certain things intelligently but also to explain them, to answer queries about them, to argue about them, and so forth. </blockquote>
Naur goes on and explains that what he means by theory is not merely knowing the hard rules, but being able to understand how the rules apply to different phenomena of the real world in ways that may not be explicit in the general form of the theory. He closes this thought with a striking metaphor:

[…] the knowledge held by someone who has the theory could not, in principle, be expressed in terms of rules. In fact, the similarities in question are not, and cannot be, expressed in terms of criteria, no more than the similarities of many other kinds of objects, such as human faces, tunes, or tastes of wine, can be thus expressed. </blockquote>
After a section on change, in which there is also the interesting remark that change without understanding of the program’s theory will cause the decay of the program, Naur’s next section, also poetically called “Program Life, Death and Revival”, we find this:

The death of a program happens when the programmer team possessing its theory is dissolved. </blockquote>
In this same section, he goes into how to properly do some programming necromancy, cautioning that trying to revive a program without contact with its authors and its original theory can end up reviving it with a different theory. What a missed opportunity to call it the program’s spirit, but alas, a serious computer scientist he was.
Naur’s piece is philosophical, always making stops to ask what something is. If you are interested, it is available in full here</a>. It’s featured in his 1992 book, Computing: A Human Activity. I’ll leave you with one last quote, from his closing remarks, in which Naur pushes back on the notion that humans work better when they have their intellects confined:

[…] current discussion of programming seems to assume that programming is similar to industrial production, the programmer being regarded as a component of that production, a component that has to be controlled by rules of procedure and which can be replaced easily. Another related view is that human beings perform best if they act like machines, by following rules, with a consequent stress on formal modes of expression, which make it possible to formulate certain arguments in terms of rules of formal manipulation. Such views agree well with the notion, seemingly common among persons working with computers, that the human mind works like a computer. At the level of industrial management these views support treating programmers as workers of fairly low responsibility, and only brief education. On the Theory Building View the primary result of the programming activity is the theory held by the programmers. Since this theory by its very nature is part of the mental possession of each programmer, it follows that the notion of the programmer as an easily replaceable component in the program production activity has to be abandoned. Instead the programmer must be regarded as a responsible developer and manager of the activity in which the computer is a part. </blockquote>

Technology with a Human Face

2026-05-27T01:06:21-03:00

bgm-mpd - Music with gaps like game soundtracks

2026-05-23T18:49:32-03:00

Casuarina Linux: glibc Chimera Linux derivative

2026-05-20T00:29:09-03:00

A 2026 survey of Linux music players

2026-05-16T20:28:09-03:00

In composing this list, I was looking for a player with:

Queue controls</li>
Library search and filtering</li>
Tray icon</li>
MPRIs</li>
Scrobbling to both ListenBrainz and Libre.fm would be nice to have</li> </ul>
Best TUI #</a></h2>
cmus</a> is perhaps the player I’ve used the most. Shoutout to musikcube</a>, which looks better, is simpler to navigate, has nice search and filter capabilities that cmus lacks, but that has a single dealbreaker for me: the lack of a hotkey to append the selected track into the queue.
Best GUI #</a></h2>
fooyin</a> and Quod Libet</a>.
fooyin is (clearly) heavily inspired by foobar2000</a>, but FOSS and available for Linux. I’ve used foobar2000 a lot in my Windows days, so it feels like home. It did crash a few times when clicking things, but it mostly sits in the back anyways.
Quod Libet is also very feature-packed. The tray icon did not show up on my system though.
MPD clients #</a></h2>
MPD</a> (Music Player Daemon) is the queen of music players and has a plethora of available clients: GUI, CLI, TUI, even specialty things like bgm-mpd</a>, a player that places random breaks between songs to emulate the experience of game soundtracks. Because MPD frees the client developers from having to implement a backend, they can focus on creating excellent frontends, and this yielded a diversity of options.
TUI #</a></h3>
I usually will say that I like TUI things because they favor a state of flow between activities. They compose well and you can do a lot without changing neither the application, nor the UI paradigm nor the input device. That’s a lot of tunneling for my attention.
But, to be fair, a music player is something you use to make your selection, and then it gets out of your way and can go on for hours and hours. So it’s not exactly a huge attention hog, particularly because nearly all of them come with keyboard shortcuts and MPRIS integration.
Nonetheless, there are plenty of TUI MPD clients, and the most frutiful lineage seems to have descended from MPD’s own ncmpc</a>, which inspired the venerable ncmpcpp</a>, which leads us to… ~~ncmpcpprs</del>~~ rmpc</a>, which is a full-blown terminal junkie TUI for MPD.
For a simpler option, you could try any of its ancestors and there’s also pms</a>. You’ll find many others, but actively developed ones are much fewer. If you have more recommendations on this category, do let me know!
GUI #</a></h3>
This one was harder than I expected. On the outset, I found players that look very complete, such as Euphonica</a>. It could be my machine and its quirks, but I couldn’t get it to find MPD. So I guess I did not find a maximalist GUI MPD client? At least nothing to the level of the other picks in this list.
Honorable mention #</a></h3>
An honorable mention is in order for Ymuse</a>. As you can see from my top choices, I prefer my music players on the bulkier side with a lot of knobs and pulls. That’s because if I want something simple, I’ll probably reach for plain mpv</a> or mpc</a>. But If you are looking for something simple, but polished, Ymuse is my recommendation to you. It has a queue, some filtering and is very light on resources.
See also #</a></h2>

MPD’s own list of clients</a></li>
mpris-scrobbler</a>, Multi-Scrobbler</a>: scrobbling from MPD to Libre.fm, ListenBrainz, Last.fm, …</li>
mpd-mpris</a> and mpDris2</a>: lets your MPD talk to everything</li> </ul>

kew: Music for the Shell

2026-05-12T21:20:06-03:00

Building the deployment tool I wish I had

2026-05-07T02:10:00-03:00

The vi family

2026-05-07T01:36:37-03:00

The Journey of ls

2026-05-07T01:14:07-03:00

Links to CSS colour palettes

2026-05-05T11:37:42-03:00

dashbrew: TUI dashboard builder

2026-05-03T14:30:08-03:00

Tags, RSS explosion and Octothorpe Protocol

2026-05-02T17:53:18-03:00

On more updates to this blog, we now have tags to browse specific topics and dedicated RSS feeds. This means this blog now serves an obscene amount of RSS feeds which is really appropriate considering RSS is adorable.
To complement the tags, I’ve added support for the Octothorpe Protocol</a>, which is a way to aggregate hashtags and other relations through an indexing server that allows you to discover and curate related content.
I’ve also added webmention metadata to be able to receive it, but haven’t implemented any way to display it yet.

numbat: Statically typed language for scientific computations

2026-04-29T22:18:44-03:00

Collective Speed Is Not the Summation of Individual Speed

2026-04-29T10:53:44-03:00

Bugs Rust Won't Catch

2026-04-29T10:52:58-03:00

Own Your Web: Curators

2026-04-25T16:52:41-03:00

gita: CLI tool to manage multiple git repos

2026-04-23T09:55:53-03:00

sem: Semantic version control CLI

2026-04-14T12:37:18-03:00

Feed & link updates

2026-04-11T14:04:07-03:00

I’ve changed where the links RSS feed points its main URL to, linking directly to what I’m sharing instead of a page with nothing where you just click the actual link.
If there’s a note attached to the link, it will link to it. Otherwise, you get straight to the destination.
As a downside, depending on how it’s configured, this might cause your feed reader to flood you with a bunch of links as if they were new. Sorry!
I’ve also set the author</code> field properly so the feeds and posts don’t all show up as if the content is by me. This should make the “All content” feed less confusing.
Finally, I’ve made some layout changes to make the blog look less cluttered on mobile and the link note page more clearly separated between the link and its commentary.
Capsicum vs seccomp: Process Sandboxing 2026-04-11T10:46:25-03:00 Tips and tricks to avoid cloning 2026-04-07T10:25:21-03:00 Shell Tricks That Actually Make Life Easier 2026-03-26T03:36:21-03:00 Capability-based Security for Redox OS 2026-03-20T23:43:47-03:00 Rob Pike's 5 Rules of Programming 2026-03-19T00:40:32-03:00 I like the last one: Data structures, not algorithms, are central to programming. </blockquote> or its alternative, as also mentioned there: write stupid code that uses smart objects </blockquote> AI Agents Recruiting Humans To Observe The Offline World 2026-03-19T00:39:04-03:00 The two kinds of error 2026-03-04T23:09:50-03:00 Printing OCaml Data Structures 2026-03-04T22:42:08-03:00 World History Atlas 2026-03-04T16:57:12-03:00 Making WebAssembly a first-class language on the Web 2026-02-28T02:54:47-03:00 Git Rebase for the Terrified 2026-02-15T00:59:23-03:00 How Terminals Work 2026-01-22T11:46:28-03:00 Handling secrets (somewhat) securely in shells 2026-01-21T15:43:41-03:00 Three Inverse Laws of Robotics 2026-01-20T01:33:11-03:00 CheriBSD: capability-aware OS for Morello, RISC-V and QEMU 2026-01-05T01:16:09-03:00 Stop Forwarding Errors, Start Designing Them 2026-01-05T01:12:28-03:00 Assorted less(1) tips 2026-01-03T12:19:53-03:00 You can make up HTML tags 2025-12-31T00:35:22-03:00 treemd: Terminal markdown tree-based navigation 2025-12-22T15:15:09-03:00 Rethinking sudo with object capabilities 2025-12-22T01:43:00-03:00 layoutz: Haskell TUI library 2025-12-12T11:32:55-03:00 mosaic: OCaml TUI library 2025-12-12T11:32:17-03:00 The Cloudflare Outage May Be a Security Roadmap 2025-11-20T01:42:59-03:00 Just enough Makefile to be dangerous 2025-11-16T19:10:56-03:00 Man Pages (Part 1) 2025-11-15T18:09:50-03:00 Website and blog building tools 2025-11-15T17:03:38-03:00 Directory of Open Access Books 2025-11-09T12:14:05-03:00 Automated PDF Generation with Typst 2025-11-09T11:59:22-03:00 FreeBSD OCI Containers introduction 2025-11-04T11:51:27-03:00 Underappreciated top 2025-10-31T00:48:57-03:00 Postgres for Everything 2025-10-30T16:42:23-03:00 rsync_cmd: edit locally, build remotely 2025-10-30T16:34:23-03:00 Keep Android Open 2025-10-28T21:53:23-03:00 defuddle-cli: Extract clean html, markdown and metadata from web pages 2025-10-26T21:40:21-03:00 feedlynx: Collect links to read later into an RSS feed 2025-10-26T12:26:47-03:00 Scripts I wrote that I use all the time 2025-10-23T02:46:15-03:00 pdfly: CLI tool to manipulate PDF files 2025-10-15T02:54:42-03:00 Octothorpes Protocol: site-independent hashtags 2025-10-15T02:09:52-03:00 Introducing oui: standalone installers for OCaml 2025-10-09T20:43:05-03:00 We Move As One 2025-10-09T04:16:19-03:00 How to actually test your readme 2025-10-09T04:00:54-03:00 CHERI with a Linux on top 2025-10-06T03:00:51-03:00 Accessible by Design: Improving CLIs for All 2025-09-23T18:34:33-03:00 Baby Steps Accessibility - Color Contrast of Text 2025-09-23T18:16:56-03:00 Reverse centaurs are the answer to the AI paradox 2025-09-18T10:59:58-03:00 Dot-slash revisited 2025-09-17T00:38:57-03:00 asciinema 3.0 2025-09-16T21:37:49-03:00 Gemini Protocol Quickstart 2025-09-16T13:07:29-03:00 term.everything: Run any GUI app in the terminal 2025-09-09T11:42:19-03:00 Capitalization of Initialisms 2025-09-06T00:32:40-03:00 incplot: great looking plots in the terminal 2025-09-03T01:10:51-03:00Half an year on Alpine: just musl aside 2025-08-31T20:05:26-03:00 Warning: Contains tongue-in-cheek language that might feel provocative if you have invested part of your identity into your software choices.1</a> For roughly six months now, I’ve been running Alpine</a> on my laptop as a daily driver. Before that, I was running Void</a>. I like how blazing fast Void is to start up and shut down, has an excellent package management system and its init system, runit, is beautifully integrated. Alpine also fits this description. When I first learned about Void, I read it described itself as “rolling but stable”, meaning you get new package versions often, but not to the point of breakage. While I never had an upgrade break a system, it still bothered me to upgrade and suddenly have sound or Bluetooth not work anymore, or have the system Python version change frequently, leading to all sorts of complaints from this or that application I didn’t even know was a Python program. I wanted to go back to a more stable distribution, but I also wanted a simpler, faster init system than systemd. Alpine, which has fixed releases every six months, eventually rose as an alternative. Expand for an overly detailed rundown of how I narrowed down my options </summary> How many options, really? #</a></h2> Preferably not rolling. Preferably without systemd. At first glance it may seem like the choices of operating systems and distributions are endless, but turns out these two requirements are enough to nearly wipe them out. My main reason to not like systemd is not that I believe Red Hat is involved in a deep state conspiracy to turn frogs gay. In fact, I’d take systemd over SysV-style init on a heartbeat. What I prefer are the sweet spots between them, not the regression into the previous mess. My reasoning is actually mostly around speed. Call me impatient, and I know it can be tweaked to improve this, but I don’t like it when a machine is coming up or going down and you get a timer from some random process saying it will wait X minutes to exit. I’d rather have a simpler tool tackling initialization and shutdown, and have learned to compose the operating system with various programs that fill in for systemd’s vast feature set. Admittedly, I also have an insatiable curiosity for getting to know and experiment with how different operating systems work. Before this experience, I knew nothing about OpenRC and several other peculiarities Alpine brings to the table. So no regrets there. I also did not want a distribution that is too new or too niche, as I don’t appreciate being stuck in dead ends too often. Just sometimes. I am curious about fringe operating systems, but I am looking for something to daily drive and work on, not experiment with. The systemd realm #</a></h3> There’s a plethora of Linux distributions. But the vast majority are based on some other one. I don’t mean that this isn’t meaningful for whatever use case they are suited for — some derivatives do go the extra mile and increment their bases in more advanced ways — but when you are looking for a distribution that you want to set up your way, it makes less sense to go for one whose selling point is how it’s already set up for something. If we drop the derivatives and focus on some arbitrary measure of adoption, we end up with Debian, Fedora, Arch, OpenSUSE and Nix. I never seriously tried OpenSUSE or Fedora. Among these three, I think I prefer Debian simply because its governance model seems (feels?) healthier and more independent/resilient. NixOS is its own kind of hell. It truly sets it apart. If you are grasping my preference for compatibility and ease of running experimental programs, you can probably guess how I felt about not even having a standard filesystem hierarchy. What I am saying about stability and preferring fixed over rolling release should also explain why Arch is not an option either, although I’d say its cultural issues far outweigh anything else for me. The non-systemd realm #</a></h3> Then, for all the other ways to summon an operating system from its slumber, we have the BSDs, Gentoo, Slackware, Guix, Void and Alpine. And because changing the init system is significantly more effort than just providing some configuration on top of another system, I think it’s fair to include derivatives here, such as Devuan and antiX. I run FreeBSD on a separate, desktop machine. I use it a lot over SSH and have also set up a graphical session there. It is a delight to use and learn about, particularly because of its Unix heritage, first-class ZFS support and how different its ecosystem is in comparison. But compatibility-wise (hardware and software), it doesn’t fit the bill for this laptop either. Something (roughly) similar can be said of the other BSDs. I have tried Gentoo, with binary packages enabled and all, but who has time for compiling a browser? Certainly not me, with my old refurbished computers. There is Guix, but my experience with Nix was a portability nightmare that, while not as wasteful of my time as Gentoo, gets close. And while definitely a control freak, I am not at the Slackware level of control freakiness. As you can see, usability and practicality have grown on me with all this messing around, so now I’d rather not have “just install everything” proposed as the solution to dependency resolution. You see, it’d be much easier not to be such a nerd. When I set up a computer for someone else, it’s Windows or LMDE or Fedora. It’s such a no-brainer. The relationship with a computer can be simple: like/dislike, works/doesn’t work, can fix/can’t fix. One can actually accept that something can’t be fixed or changed! Really admirable. But that’s not me. I actually care what is the DHCP daemon, who’s resolving the DNS queries and how aggressive the OOM killer is going to be. And because Void is a rolling release distribution, the only survivor of all this begging and choosing is Alpine. </details> Choosing a path forward #</a></h2> So, prompted by a charger dying in the beginning of this year, which put a machine out of work, I decided to take the opportunity to try another system with a slower release cycle and started weighing my options. What remained in the end were Devuan, antiX and Alpine. And I briefly tried all three during this experiment before settling on Alpine. Devuan and antiX do offer options besides SysV-style init, but they don’t really integrate them very well in their systems. While with Void you will really use runit to manage any services installed through the distribution’s package manager, because when a package has a relevant service to ship it will ship a runit service, Devuan and antiX have other init systems as options rather than the distribution’s init system. What you really get then is a mixture of runit/OpenRC and SysV-style init, leaning a lot more towards SysV-style and leveraging the runit/OpenRC ability to also run SysV-style init scripts.2</a> If you like managing SysV-style init, that should not be a problem, although in that case you might as well get the SysV-style version then! Alpine, on the other hand, just like Void, has OpenRC as the way to run services. Alpine it is #</a></h2> For starters, I wanted to learn a little bit more about this unknown-to-me init system, OpenRC, since I’d be spending some time setting up services with it. OpenRC can be used alongside or in place of SysV-style init. I will not get into the different roles played by so-called init systems and process supervisors, but OpenRC provides openrc-init</code>, which can replace /sbin/init</code> for a fully OpenRC-powered system. I could not find explicit information on whether this is the case with Alpine, but an actual inspection of the running system shows it is not. Mind you, even Alpine’s /sbin/init</code> is actually BusyBox: % file $(which init) /sbin/init: symbolic link to /bin/busybox</code></pre> I then checked out BusyBox’s manual page to try and understand more: Init is the first process started during boot. It never exits. It (re)spawns children according to /etc/inittab. Signals: HUP: reload /etc/inittab</li> TSTP: stop respawning until CONT</li> QUIT: re-exec another init</li> USR1/TER, /USR2/INT: run halt/reboot/poweroff/Ctrl-Alt-Del script</li> </ul> </blockquote> I knew Alpine heavily leaned on BusyBox, but didn’t realize it was to this extent. So, following this trail, there was Alpine’s /etc/inittab</code>, where I found this: ::sysinit:/sbin/openrc sysinit ::sysinit:/sbin/openrc boot ::wait:/sbin/openrc default</code></pre> Meaning, Alpine’s init is BusyBox’s init, which in turn calls on OpenRC to bring services up. Working around musl… #</a></h2> Willing to give OpenRC a try, I had to clear up my only concern with Alpine: lack of compatibility with glibc software. This took a long time to evaluate, because you need to actually try to do what you usually do in real situations to see if things will work out or not. If you are questioning whether Alpine can reliably run a full desktop environment or window manager, play and record audio, share your screen, run GUI applications including the latest browsers, act as the host of virtualization and development environments, the answer is an unwavering yes. If you are questioning whether on top of that Alpine can play DRM video and games (e.g., Netflix and Steam), the answer is also yes, but you’ll need a glibc layer around it. If you like Flatpak, that might actually be trivial. But for more involved usage of software that requires glibc, in particular novel and experimental stuff you are compiling yourself or exploring and prototyping with, your mileage may vary. It is more likely that a vendor will not provide a musl build of their software. Some stuff works just by installing gcompat</code>, a compatibility layer that will make glibc software run as-is. Some however won’t work with it. Sometimes I’d just compile something myself, meaning I made my own musl-linked executable of something that was available only for glibc. That works, but compilation for musl is often less documented and may not be possible at all depending on whether or not musl provides all the needed features. The latter case was however quite rare in my experience. Some other options are running things through Flatpak, or Nix, or Distrobox. But sometimes, if all failed, I just had to accept it wasn’t possible. Or it would work and then crash when using a specific feature at runtime. And that’s great, having ways to circumvent musl. But you could also just… run stuff directly? It’s nice to have options, but it’s also a lot of friction. And sadly that is what ended up exhausting me from using Alpine as a daily driver. I think that, if you have a very consistent usage of Alpine, where you are mostly doing the same thing and using the same tools, you could find a comfy workflow there. But I am extremely moved by experimentation and curiosity. And something tells me that I could devise a more fluid workflow to run my experiments and try different tools inside isolated glibc-friendly environments, but in the end it’s still friction. And it’s hard to shake the feeling that, if you were running a more compatible system to begin with, that wouldn’t even be something to think about. Getting software from the distribution’s package manager is the way to go for numerous reasons. But sometimes that is just not an option. Sometimes the package is just nonexistent in the repositories. Sometimes you need to compile it yourself because you need a specific version. Or because you don’t trust the provided pre-compiled binary. Sometimes you need a specific compilation with a specific feature. Sometimes you are in a hurry, or just curious to try something you can securely run in isolation. So not being able to install it the conventional way is friction in itself. Having to compile something every time is extra friction. Having to recompile on upgrades is more friction. And to not be able to compile or run it even by compiling it yourself, that is just compounded friction with some frustration sprinkled on top. … though I’d rather not #</a></h2> This is not about Alpine, but it’s also inseparable from Alpine. Alpine has an excellent, fast package manager that never broke my setup. When things did break, it was able to fix them by itself. The six months release cycle is to me a really sweet spot at which to space versions — not too often, not too seldom. A lot of software is available. Developers are security conscious. It’s extremely lean on resources. And in the spirit of being so lightweight, Alpine shines on virtualized and embedded systems. This focus on being small is why musl is a great fit, since it’s a lot lighter than glibc, among other advantages</a>. For me though, while I appreciate the smaller size, it’s not that critical that I’d sacrifice compatibility and versatility over it. So I have zero complaints about Alpine, musl aside. It is perfect in everything I signed up for when I decided to try it. It delivered on every feature and never lied to me. It never said to me it was going to be smooth and easy to run glibc programs. So it’s not so much that I didn’t like Alpine, it’s that I wish there were a glibc Alpine just like there is a glibc Void. But I’m well aware that’s not happening. Choosing a path beyond #</a></h2> It was excellent to learn hands-on about how Alpine works and what it can offer. I learned a lot about not just its components, such as OpenRC and BusyBox, which were basically strangers to me, known only conceptually. Alpine also taught me a lot about all the things it doesn’t have. Because, seriously, if you do a chroot installation of Alpine and don’t even run its setup scripts, you’ll end up with something so trimmed down you’ll wonder if you’re midway through LFS</a>. You’ll have to work your way up to a usable system piece by piece, finding out what you need, why you need it and how to set it up. And that is a huge learning opportunity for those interested For now though, I decided to backtrack a little bit and then fully reverse course if I can’t find a working compromise. That means giving Void another try and, if stability keeps being a problem, go further back and land on Debian. If I shed the non-systemd preference aside, Debian would deliver on the stability and compatibility that I am looking for. You see, I am not looking for the next distribution to try as if it were a hobby and I wanted to try novelty out of FOMO. This is actually a lot of work! I’d rather do other things with the operating system rather than install and configure it, as I mentioned before</a>. And if at the other end of the bell curve it’s Debian, whatever. Perfect is the enemy of good and being picky is exhausting. I mentioned curiosity is a big factor in wanting to try things too. And frankly, after a while holding this preference for non-systemd operating systems and using systems without it, I might as well seize the opportunity to learn more about systemd as well. At my current internship, systemd is what all the distros we have in production are using. In future work, that is very likely to be the case too. So there is nothing to lose. I really wish, though, that package managers were more capable of differentiating between security and feature upgrades. If they were, we could run a rolling distro in “Debian mode” at will. This thought may not sit well with some rolling distributions, say, in Arch Linux you have the notion that “Partial upgrades are unsupported”</a>. There may be the expectation that the whole repository at any given time is the end state for all machines subscribed to it, but if dependencies could also be at the version and not only package level, that could also be solved, though I won’t undersell the consequences and added complexity in such a change. Just like mail clients, all operating systems suck. Some just suck less for some specific use case. Also, if you find out how to reclaim that identity, do share. Asking for a friend. ↩</a> </li> It’s no surprise a distribution’s main init system has better support, as it sure is a lot of work for packagers to support and test multiple init systems. ↩</a> </li> </ol> </section> Setting up a CI server for Forgejo 2025-08-27T01:18:36-03:00 The Insecurity of Debian 2025-08-27T00:58:03-03:00 sptlrx: Synchronized lyrics in your terminal 2025-08-26T23:41:41-03:00 doxx: terminal docx viewer 2025-08-26T21:49:50-03:00 Developing an alt text button for my website 2025-08-26T17:08:38-03:00 Why Lean 4 replaced OCaml as my Primary Language 2025-08-26T17:04:25-03:00 A visual explanation of Big O notation 2025-08-26T00:38:39-03:00 gcli: Git(hub|lab|tea)/Forgejo/Bugzilla CLI tool 2025-08-16T21:59:10-03:00 pspg: Unix pager for PostgreSQL, MySQL CSV, TSV and more 2025-08-16T21:55:26-03:00 Implementing a basic equivalent of pflog in nftables 2025-08-16T00:42:08-03:00 A Friendly Introduction to SVG 2025-08-15T10:32:33-03:00 How to help someone use a computer 2025-08-15T10:24:11-03:00 ethersync: Editor-agnostic, real-time collaborative text editing 2025-07-29T11:32:02-03:00 ANSI Escape Codes Inspector 2025-07-26T02:28:00-03:00 Bread on Penguins 2025-07-14T18:34:23-03:00 outside: multi-purpose terminal weather client 2025-07-13T20:35:57-03:00 BastilleBSD 1.0 Release 2025-07-10T01:29:31-03:00 OCaml, modules, and import schemes 2025-07-02T20:49:34-03:00 The Tectonic Typesetting System 2025-07-02T20:45:43-03:00 In Praise of Links 2025-06-20T14:05:14-03:00 jarun/pdd: Tiny date, time diff calculator with piggybacked timers 2025-06-18T22:40:49-03:00 Poline: esoteric color palette generation 2025-06-14T20:07:25-03:00 gbprod/substitute: Neovim plugin with replace and exchange operators 2025-06-14T19:53:14-03:00 Why apk-tools is different than other package managers 2025-06-10T21:17:25-03:00 ifd3f/caligula: user-friendly, lightweight TUI for disk imaging 2025-06-10T17:11:55-03:00 pastel: A CLI tool to generate, analyze, convert and manipulate colors 2025-06-10T17:03:27-03:00 the algebra of dependent types 2025-05-29T00:32:09-03:00 Waypipe: graphical remote access for Wayland applications 2025-05-28T19:29:14-03:00 Tried out Waypipe</a> today as a way to remotely control graphical Wayland applications between Alpine Linux and FreeBSD hosts and it’s snappy on my wireless network + decade-old hardware combo! At first, the minimal example given by Waypipe in its README and man page did not work: waypipe ssh user@server foot</code></pre> (I’m using foot</a> as the example here because that’s the terminal I use on both systems, but it could be anything — a simplistic application, a web browser or even a full-blown compositor). This failed with the following message: S2874: 0.603209 [src/server.c:649] Env. var XDG_RUNTIME_DIR not available, cannot place display socket for WAYLAND_DISPLAY="wayland-HBTrV7VT"</code></pre> The issue here is that most (all?) Wayland applications expect at least XDG_RUNTIME_DIR</code> to be set, and a bare ssh connection will not set that on its own. The man page does mention this and how to fix it. It gives you several options, one of which is using ~/.ssh/environment</code> and setting it up properly at the client</a> and server</a>. Instead, I prefer to use the following approach because it’s isolated to each host instead: Client ~/.ssh/config</code>: Host <server> User <user> SetEnv XDG_RUNTIME_DIR=<user-writable-directory></code></pre> The directory above must exist prior to the connection and must be writable by the user as whom we will ssh into the server. Otherwise, it will throw the following error: S2889: 60.436704 [src/util.c:237] Error opening folder in which to connect to socket: Permission denied</code></pre> If you’d rather reuse the XDG_RUNTIME_DIR</code> value you already have set on the client, you can also use SendEnv</code> instead of SetEnv</code>, but their values may not be interchangeable. In my case, Alpine and FreeBSD use different directories with different permissions. This is one other advantage of this method over ~/.ssh/environment</code>. Next, you need to make sure the server will allow the client to send this environment variable. Server /etc/ssh/sshd_config</code>: AcceptEnv XDG_RUNTIME_DIR</code></pre> Make sure you have Waypipe installed on both server and client. Finally, from the client’s shell: waypipe ssh user@server foot</code></pre> That’s it! If all went well, a window should pop up with foot</code> — or whatever command you chose — running directly from the server. Why Algebraic Effects? 2025-05-27T22:22:25-03:00 Having your compile-time cake and eating it too 2025-05-24T18:58:45-03:00 Parsing expressions by precedence climbing 2025-05-13T23:26:52-03:00 FreeBSD VM under Incus on Debian 2025-05-06T03:18:31-03:00 Linux on a 70's Typewriter 2025-04-29T19:51:06-03:00 Revisiting an early critique of formal verification 2025-04-19T00:53:46-03:00 Allowed commands in SSH authorized_keys 2025-04-17T20:56:14-03:00 Introduction to Linear Types 2025-04-15T17:19:58-03:00 Two Years of Rust 2025-04-15T15:21:27-03:00 OEM Support in Linux Mint Debian Edition 2025-04-09T19:52:51-03:00 End-user Programming 2025-04-05T22:18:40-03:00 Pitfalls of Safe Rust 2025-04-04T19:37:22-03:00 clawtype: wearable chorded keyboard and mouse 2025-04-04T19:21:17-03:00 landrun: unprivileged Linux sandboxes using Landlock 2025-03-28T20:34:29-03:00 Using elinks to browse the web 2025-03-27T17:37:24-03:00 Don't Be Afraid Of Types 2025-03-22T13:33:16-03:00 slipshow: the next-gen version of slides 2025-03-20T21:53:40-03:00 The road to mainstream Matrix 2025-03-18T23:36:24-03:00 Verification-First Development 2025-03-18T21:26:19-03:00 An interview with Mike Amundsen, Author of 'RESTful Web APIs' 2025-03-17T17:52:16-03:00 Almquist Shell Variants 2025-03-13T22:32:48-03:00 Beyond Bad Output 2025-03-13T22:31:53-03:00 termpicker: A color picker for the terminal 2025-03-11T22:02:09-03:00 Understanding Unix filesystem timestamps 2025-03-09T14:52:25-03:00 Build your own Command Line with ANSI escape codes 2025-03-07T21:55:40-03:00 Standards for ANSI escape codes 2025-03-07T21:26:21-03:00 Dependent Haskell Roadmap 2025-03-07T17:11:14-03:00 Why ZFS Reports Less Space: Space Accounting Explained 2025-03-04T17:09:59-03:00 hue.tools 2025-03-04T14:54:54-03:00 Falsehoods programmers believe about languages 2025-03-02T12:07:14-03:00 mdo: FreeBSD su alternative without setuid binaries 2025-02-27T01:25:49-03:00 A timeline of Unix shells 2025-02-24T14:34:25-03:00 For some reason, I really like timeline visualizations, meaning a graph with events listed along a temporal axis with the dates in which they happened. I remember using tape to glue several pieces of paper on the wall as a kid to make a long timeline of world history events. So every time I find a tool to do that, I want to check it out. The latest was Markwhen</a>, which works entirely by defining the timeline as code and then running an executable against it to render image or interactive web outputs. To try it out, I made this timeline of Unix shells. You can view the HTML version here</a> or the images below (dark and light themes): </a> </a> Expand for a textual list of the timeline events</summary> 1963: RUNCOM</li> 1965: Multics shell</li> 1971-11: Thompson shell (sh)</li> 1977-07-01: PWB shell (sh)</li> 1978: C shell (csh)</li> 1979: Bourne shell (sh)</li> 1983-10-04: TENEX C Shell (tcsh)</li> 1983-06-09: KornShell (ksh)</li> 1989-05-30: Almquist shell (ash)</li> 1989-06-08: Bourne-Again Shell (bash)</li> 1990-12-14: Z shell (zsh)</li> 1992: Plan 9 Rc (rc)</li> 1995-06-16: Public Domain KornShell (pdksh)</li> 1997-06-19: Debian Almquist shell (dash)</li> 2004-04-07: MirBSD Korn Shell (mksh)</li> 2005: friendly interactive shell (fish)</li> 2019-08-23: Nushell (nu)</li> 2020-10-30: Portable OpenBSD KornShell (oksh)</li> </ul> </details> Don’t ask me why every item is followed by …, I’d love to know. If you are interested, here is the source code</a> that was used to generate the images above. The source code also contains notes that are only displayed in the HTML version. These notes are sources for the dates and sometimes observations on the date precision. Enjoying Alpine as a daily driver 2025-02-23T22:07:09-03:00 I am happy to report that my Alpine root-on-ZFS experiment is – apparently – a success. I’ve been running it as my only OS on my laptop for the past week. I was previously on Void and I switched because the stable part in “rolling but stable” wasn’t really fulfilling what I expected, with occasional breakage on updates, or just things changing too often. For instance, every minor Python version you get a bump and every Python program on your system starts yelling deprecation warnings amid their output. I just can’t with this rate of change of fundamental stuff like compilers and interpreters. My favorite model of update is FreeBSD’s. Your core system updates in one way, the third-party packages update another way, the core only updates if necessary and packages not too often as to introduce such breakage. But for this machine FreeBSD is just not there (yet). Alpine updates every six months and it can be made as rolling as setting your Debian repositories to “stable” or “testing” (“edge” in Alpine) if you appreciate chaos enough. It’s my first time daily driving OpenRC and musl, which I feared would introduce painful compatibility issues, but so far I’ve been able to use everything I need, sometimes leveraging the alternatives</a>, like its glibc compatibility layer or a Flatpak as last resort (e.g. for playing DRM video). I started drafting a blog post with the journey so far, but I’ll keep using it and hitting some more of my use cases along the way to have a more complete write-up. Post-Quantum Cryptography in February 2025 2025-02-19T22:16:13-03:00 Five Kinds of Nondeterminism 2025-02-19T19:18:12-03:00 LabPlot – Scientific plotting and data analysis 2025-02-15T18:42:03-03:00 laktak/tome: script playbooks with vim 2025-01-23T23:20:35-03:00 nixbsd: An unofficial NixOS fork with a FreeBSD kernel 2025-01-21T17:32:00-03:00 Koto Programming Language 2025-01-08T21:31:31-03:00 aaronik/treewalker.nvim: Move around your code in a syntax tree aware manner 2025-01-08T03:31:48-03:00 yassinebenaid/bunster: Compile shell scripts to machine code 2025-01-07T00:07:58-03:00 One-stop performance analysis using atop 2025-01-06T00:39:14-03:00 Category Theory Illustrated 2024-12-29T19:08:10-03:00 Revisiting the NetBSD build system 2024-12-28T22:26:03-03:00 Canop/rhit: A nginx log explorer 2024-12-27T00:37:00-03:00 Schemio, a platform for dynamic diagramming 2024-12-24T00:28:30-03:00 Ideas from "A Philosophy of Software Design" 2024-12-22T17:33:54-03:00 Cognitive load is what matters 2024-12-22T16:46:15-03:00 How to properly shut down a Linux system 2024-12-21T18:14:32-03:00 Web Origami 2024-12-21T12:22:49-03:00 Artemis - a calm web reader 2024-12-21T00:40:57-03:00 Conjuring a Linux distribution out of thin air 2024-12-13T16:59:18-03:00 Telescopic Text 2024-12-11T18:48:21-03:00 An Undefeated Pull Request Template 2024-12-10T22:39:33-03:00 How to Pronounce Chinese Names a Little Better 2024-12-07T11:14:25-03:00 8 months of OCaml after 8 years of Haskell 2024-12-04T00:00:00+00:00 Demystifying git submodules 2024-12-04T00:00:00+00:00 December Adventure 2024-12-04T00:00:00+00:00 Announcing Hurl 6.0.0 2024-12-04T00:00:00+00:00 Typst as a Language 2024-12-03T00:00:00+00:00 The "Property Based Testing" series 2024-12-03T00:00:00+00:00 Linear Types and Exceptions 2024-12-02T00:00:00+00:00 Dependent Types and the Art of HTTP Headers 2024-11-28T00:00:00+00:00 Frederik Braun: Modern solutions against cross-site attacks 2024-11-27T00:00:00+00:00 I ❤ [tmux] shortcuts #2 2024-11-26T00:00:00+00:00 Functional programming self-affirmations - NorikiTech 2024-11-26T00:00:00+00:00 How I configure my Git identities | benji 2024-11-25T00:00:00+00:00 re2c — Regular Expressions to Code 2024-11-25T00:00:00+00:00 On self-hosting being a patch 2024-11-23T15:00:00-03:00 Recently the blog post Self-Hosting Isn’t a Solution; It’s A Patch</a> landed in my reading list via Lobsters</a>. It was an interesting read and I recommend anyone interested in tech decentralization and regulation to check it out, but two thoughts came to mind: First, perhaps most of the blame is in the concept of “self-hosting” itself. It is too narrow for what it really represents. Something described as self-hosted can most of the times not only be individually-hosted but community-hosted. You can host it yourself and bear all the associated burdens alone, yes, but the way the article portrays this as the only possibility is a bit of a straw man. “Self-hosting” also implies open-source software that you could run for a whole community, a town, a country, a continent, or the planet if you can. It implies that not only the software’s source is available and its license is a free software license, but that it is designed in a way that you should be able to run it to its full capacity yourself. How large that scale will be, how many people are running it, and how it gets funded and managed can take multiple forms and, if regulation is to be the answer, that is one possible structure (government) that can fund such projects, though it doesn’t have to be. The second thought is that regulation and self-hosting are not opposed to each other. In fact, they are not at odds at all. So to point to regulation as the better solution and self-hosting as a limited one may pose the illusion that we have to choose – we miss that they actually are far more effective together. That is, unless your goal is just to reform the big-technology-corporation-owns-everything model. For that, regulation alone is much better, with all the long-winded bureaucracy, ceremony and always-open possibility of a reversal. The regulations in Europe during the past years have surprised in how strong they are in favoring interoperability and some decentralization. Also, more then a few stories about European tech funds putting money into open source projects have crossed the same channels that landed this article among my browser tabs. Neither of them is, alone, the solution, as you could also see regulation as a lubricant, a way of legitimizing the predatory practices of everyday capitalism by putting it into a nice, confined setting and stamping it with the seal of compliance, however you are able to ascertain it, while still allowing most of the damage to happen, be it a loophole, a cover-up or simply something that didn’t happen to bother the regulators to begin with. In this sense, the act of building completely independent platforms, able to operate using their own software and infrastructure, comes from a whole different angle and a much more incisive one at that. It works not simply on the level of “how can we make these companies play nice” but of “how can we not depend on these companies to begin with”. This is not solely a concern about reliability, as seen when the article notices how small and underfunded decentralized projects can simply vanish due to lack of funds or inability to stand up to legal threats, it is a concern about privacy and autonomy too. While it is always sad to see an open-source project or community close down, this is also a community that was built on foundations of interoperability and that values the capacity of taking your data out and moving it elsewhere when needed. I do think platforms like the Fediverse could improve in this regard, as, for instance you can’t always move your content with you as easily as more portable data such as follows and followers, but that is one of many issues we can work on and move past. Conversely, when a company goes out of business or sells out, a completely different situation is presented to you. Your data may simply be “transitioned” to the infrastructure of another company and the way you interface with it may completely change. Or it may have been built on fully proprietary software and data formats that will essentially become useless a few years after the company shuts down. Or it may simply vanish and you never had a way to get your data to begin with. Our systems do not need to be high-maintenance, intensive on resources and energy needs. They don’t have to answer every request with availability and latency that measures up to however many nines or zeroes are the current industry standard. They have to attend to the needs of those who are using them, which can be much less demanding. We can run both infrastructure and software at more human scales and learn other ways of growing or shrinking, and we can also scale to high performance and availability too. This is what the concept of a network enables after all, but it is often used to centralize and create dependency instead. Styling Graphviz with CSS 2024-11-18T00:00:00+00:00 New notes section 2024-11-17T00:00:01-03:00 This blog now has a Notes section for shorter, less elaborate thoughts, meant to allow more free-form updates as opposed to the longer posts which take much more time to write. As usual, dedicated RSS feeds</a> are available for all content or just notes on a per-language basis. MomBoard: E-ink display for a parent with amnesia 2024-11-13T00:00:00+00:00 A mental model for Linux file, hard and soft links | Jayesh Bhoot 2024-11-09T00:00:00+00:00 Configuring SSH Keys for Multiple Accounts 2024-11-05T00:00:00+00:00 Searching for and navigating Git commits 2024-11-03T00:00:00+00:00 Debugging Haskell Type Errors | jelv.is 2024-11-03T00:00:00+00:00 Nobody cares about decentralization until they do 2024-10-31T00:00:00+00:00 nickgerace/gfold: CLI tool to keep track of Git repositories 2024-10-29T00:00:00+00:00 Improving SSH's security with SSHFP DNS records | APNIC Blog 2024-10-26T00:00:00+00:00 Smarter than 'Ctrl+F': Linking Directly to Web Page Content 2024-10-24T00:00:00+00:00 Solene'% : A dedicated administration workstation 2024-10-23T00:00:00+00:00 against /tmp - Tony Finch 2024-10-22T00:00:00+00:00 Typst 0.12 is just ... better 2024-10-18T00:00:00+00:00 That's Not an Abstraction, That's Just a Layer of Indirection 2024-10-14T00:00:00+00:00 FFmpeg Explorer 2024-10-14T00:00:00+00:00 The ultimate guide to Haskell Strings · Hasufell's blog 2024-10-11T00:00:00+00:00 HTML for People 2024-10-10T00:00:00+00:00 Statically Typed Functional Programming with Python 3.12 2024-10-07T00:00:00+00:00 Chris's Wiki :: blog/unix 2024-10-05T00:00:00+00:00 A hypermedia rabbit hole in which I quickly fell. wrestling the web from corporate control requires making it boring again 2024-10-05T00:00:00+00:00 In an age where web is essential, we need a universal web browser for minority platforms. One that focuses on keeping HTML+JS working rather than chasing things like “WebVR” and collaborating with the ads industry. Unfortunately, I think the system has been set up to ensure that small players are no longer possible. Let’s hope I’m proven wrong. </blockquote> Sandboxing Adoption in Open Source Ecosystems 2024-10-04T00:00:00+00:00 The Reticular Society 2024-10-04T00:00:00+00:00 In necroreticular flows which cut across algorithmically distributed gigs and connected places of work, the number of lives integrated together corresponds to the interoperable potential of the reticular society’s optimization and domination, subsuming life and in so doing circulating death. </blockquote> carl: modern version of cal that can incorporate ICal (ics) data 2024-10-01T00:00:00+00:00 This is superb in conjunction with vdirsyncer</a>, which I’ve been using for a long time for exactly the purpose of having a local directory of .ics</code> files for each of my Nextcloud DAV calendars. If you like this, you may also like khal</a>. diffnav: git diff pager based on delta but with a file tree 2024-10-01T00:00:00+00:00 I Want Process-Aware Types 2024-09-30T00:00:00+00:00 Alopex Networks Wiki 2024-09-29T00:00:00+00:00 Small Internet protocol roundup 2024-09-29T00:00:00+00:00 Release tmux 3.5 · tmux/tmux 2024-09-27T00:00:00+00:00 Interesting changes</a> include: “Display hyperlinks in copy mode and add copy_cursor_hyperlink</code> format to get the hyperlink under the cursor.”</li> “Add a prefix timeout option.”</li> “Add mirrored versions of the main-horizontal</code> and main-vertical</code> layouts where the main pane is bottom or right instead of top or left.”</li> “Add --enable-jemalloc</code> to build with jemalloc memory allocator (since glibc malloc is so poor).”</li> “Add N</code> to search backwards in tree modes.”</li> “Use default-shell</code> for command prompt, #()</code> and popups.”</li> “Add a command-error</code> hook when a command fails.”</li> </ul> Debating ifupdown replacements for Debian trixie [LWN.net] 2024-09-26T00:00:00+00:00 Project Cybersyn - 99% Invisible 2024-09-22T00:00:00+00:00 Lagrange v1.18: TUI and Misfin 2024-09-22T00:00:00+00:00 jacek-kurlit/pik: Process Interactive Kill 2024-09-17T00:00:00+00:00 The First HTML LSP That Reports Syntax Errors | Loris Cro's Blog 2024-09-11T00:00:00+00:00 Make Your Own Read-Only Device With NetBSD - IT Notes 2024-09-10T00:00:00+00:00 Critical analysis of Fediverse decentralization promises 2024-09-08T00:00:00+00:00 Unix command line conventions over time 2024-09-06T00:00:00+00:00 FenTiger/FedIAM: Login and access control based on open identities 2024-09-01T00:00:00+00:00 Notice on RSS feeds 2024-09-01T00:00:00+00:00 For those subscribing to this blog’s RSS feeds: First, if you are getting links but would rather only be notified about posts, you are probably subscribed to an “all content” feed. You can find all feed options in the feeds</a> page. Second, as per a recent thread</a> I started on Mastodon, I am planning on keeping only the Atom feeds in the future. Currently, all feeds are served in two formats, for example: https://blog.jutty.dev/posts/rss.xml</a></li> https://blog.jutty.dev/posts/atom.xml</a></li> </ul> On a much later date, I plan on retiring the rss.xml</code> feeds, so if that’s what you are subscribed to, consider changing to the equivalent atom.xml</code> feed sometime in the future. Both formats will keep working for now. The only immediate change will be that only the atom.xml</code> ones will be advertised on the feeds</a> page and on HTML meta tags. jatcwang/instant-scala: instant Scala script startup 2024-08-30T00:00:00+00:00 Deterministic Replay of QEMU Emulation 2024-08-29T00:00:00+00:00 Hurl 5.0.0, the Parallel Edition 2024-08-28T00:00:00+00:00 Good programmers worry about data structures and their relationships 2024-08-27T00:00:00+00:00 Misconceptions about the UNIX Philosophy 2024-08-26T00:00:00+00:00 The Impressionist Blogging Movement - Jim Nielsen’s Blog 2024-08-20T00:00:00+00:00 Support PUT, PATCH, and DELETE in HTML Forms 2024-08-19T00:00:00+00:00 Giving up simplicity 2024-08-10T00:00:00+00:00 or Unwinding</h1> Due to a worker strike, the university semester ended late this year. That meant everything had to be compressed into little more than a month in order to wrap up what would have taken four. Now that we’re almost through it, my mind wanders to writing. It is almost always what springs from the void in me, what has been winded up loosens and the scattered meaning starts to recollect into the drain of language and swirl through the piping of my nervous system. Wind is air that has been somehow compressed. If there was no pressure pushing it anywhere, it would be just expansive air, floating in peace with the atmosphere. If you’d entertain this thought further, consider a work of visual art. It can be more figurative, clearly depicting shapes that mean something, and therefore able to convey an array of ideas to whatever extent of detail the artist wants. Conversely, it can be more abstract, where ideas will be a lot more sparse, possibly to the point where nothing at all is conveyed other than the appearance, whatever aesthetic is employed being the whole message in itself. Very little is packed into the work, just like the air you can’t even feel weighing on you. In computing, and more specifically in the realm of programming – a craft presently overshadowed by the semantically starved jargon of whatever the department responsible for inflating public perception numbers is called these days – simplicity is often emphasized. Code is supposed to be clear, expressive and clean. A software application is supposed to have as few dependencies as possible, and strive to keep it simple, or risk stupidity. While that is a lofty goal, and while clear, expressive and clean code is a refreshing and tranquilizing sight, more often than not software just can’t be simple. Not having dependencies means implementing more and more yourself. There are corner cases to cover, tests to run, different architectures and operating systems to support. Even the simplest of software ideas, say, a calculator, a program that prints back a sentence in reverse, that displays a picture you give it, whatever you conceive as the simplest use case, is hardly ever implemented with simplicity in the naïve sense of something that is, quite literally, simplistic. More often than not, simplicity is actually abstraction. The breaking apart of complexity behind a simpler facade. More so a way to manage complexity by conveying it simply than to enact simplicity in its actual sense. Each step in abstraction is actually a layer deeper into intricacy. And yet, it makes things immensely easier to manage and understand. For some reason, I have always felt very drawn to abstract works. Staring into them, there is no expectation to understand, get, or argue about. Interestingly, to me that also means they couldn’t be any more clear. It does not mean a specific, intelligible message is conveyed from the artist to me, rather, it means whatever impression is caused on the viewer was never intended to reach too deep anyways. It never intended to carry that much through its medium. Sometimes, too much detail, no matter how specific, can draw an idea so far out that it becomes harder and harder to grasp. In contrast to that, a brisk exposition can get the message across like lightning. So detail does not always convey meaning, although it can convey a specific meaning to someone who will bear with you as you build the context for it. Otherwise, you could convey your message just as effectively in an abstract manner if your receiver already has that context from the outset. In computing, such possibility is simply absent from us. No context whatsoever can be assumed, and if it is present, that is because some other structure is providing it. Complexity produces confusion, confusion produces frustration, and frustration can lead to either surrender or a rebound. So the interesting thing about this pressurizing of ideas is that it springs back into action a process that may reverse it or deflect into something else entirely. Instead of surrendering to the frustration of complexity, sometimes I actually take the time to recollect myself and analyze it into understanding. This feeling of winning over something that had me on my knees and ready to give up is a very gratifying one. It convinces me I can squeeze grit from despair if I bet on it and willingly risk desperation in order to see it through. Yet, after chasing the deadline of effort all of it relaxes back into this state. In it, the only way to rest is to embrace complexity as the whole, and simplicity as one of its manifestations. It is so cold right now in the south, but in the north it is not. Four days and nine hours ago it was the peak of the winter. I’m wrapped in blankets and the room is dark like the depths of a submarine cave, LED lights here and there like fluorescent eyes blinking in silence. The professor had us build games and then present them to the whole faculty. Among the outputs, one algorithm I produced stuck with me for what I deem is simplicity. It is responsible for causing an enemy to chase the player by finding the difference between their positions and lowering it: func move_to(x, y): var x_difference = self.global_position.x - x var y_difference = self.global_position.y - y if abs(x_difference) > chase_speed: if x_difference > 0: self.global_position.x -= chase_speed else: self.global_position.x += chase_speed else: self.global_position.x += x_difference if abs(y_difference) > chase_speed: if y_difference > 0: self.global_position.y -= chase_speed else: self.global_position.y += chase_speed else: self.global_position.y += y_difference</code></pre> It could be further abstracted. The logic is repetitive. The math could be condensed. But should it? Would that make it harder or easier to understand? And to whom? There is no single answer, and yet I would really appreciate knowing. mrusme/reader: for your command line what the 'readability view' is for browsers 2024-08-06T00:00:00+00:00 A handful of reasons JavaScript won’t be available - Piccalilli 2024-08-01T00:00:00+00:00 jgs font 2024-07-02T00:00:00+00:00 Introducing tori 2024-06-30T00:00:00+00:00 tori</a> is a tool to track your personal systems’ configurations and replicate them. For the past 5 months, I’ve been simultaneously using and writing it to manage my main machine’s configuration. By “manage the configuration” what I mean is keeping track of installed packages, configuration files, symlinks, and other settings that can be queried and set through command line interfaces. After installing a given system, I wanted to get it to the same configuration state I was used to, or to a certain configuration specific to its purpose. Just copying backups would certainly be a very manual task, namely because: Not all settings live in /etc</code></li> Some settings must be set using a specific CLI utility</li> Backups usually carry an overwhelming amount of redundant default configuration you never even touched</li> It does not track what is changing as you are still using the system</li> I actually wanted to know what I was tracking</li> </ul> Configuring a system can become a very vague process as you start to lose track of where the changes are being made and what is the specific configuration needed for something to work. Every time you change some configuration file, every time you create a symlink somewhere, that’s all having effects on the system that you may expect to be there in the future, but you may not remember how to accomplish that. This drift between what you have and what you are able to replicate only grows as you keep using your system. To get a better idea, see the code snippet below. It’s from the main file that I use to manage all function calls: xbps_get_many packages check_service dbus check_group audio check_group video copy dhcpcd.conf /etc/dhcpcd.conf place kernel-cmd-line.conf /etc/dracut.conf.d check_link /etc/localtime /usr/share/zoneinfo/America/Sao_Paulo get_nix tailspin tspin get_cargo taplo-cli taplo --locked get_bun bash-language-server get_bin 'https://raw.githubusercontent.com/hackerb9/lsix/master/lsix' lsix check_gsettings gtk-theme 'Plata-Noir' check_gsettings font-name 'Mononoki Nerd Font Regular'</code></pre> What is happening here: A file named packages</code> containing package names is parsed and all packages are queried and installed by the xbps</code> package manager, if not already installed</li> Service dbus</code> is enabled if not already enabled</li> The user is added to groups audio</code> and video</code>, unless already in them</li> File dhcpcd.conf</code> from the configuration directory’s base</code> directory is checked against the one in the passed path and overwrites it if the user chooses to do so</li> File kernel-cmd-line.conf</code> from the configuration directory’s base</code> directory is copied into the passed path. If the file already exists or differs, tori will present an error</li> A symlink is checked to be on /etc/localtime</code> pointing to the passed path. If it doesn’t, it is created or fixed</li> If not installed, a few packages are installed using different package managers: tailspin</code>, taplo</code> and bash-language-server</code></li> If absent, an executable for lsix</code> is downloaded from a URL and placed at ~/.local/bin</code></li> Some gsettings</code> values are read and set if they differ: gtk-theme</code> and font-name</code></li> </ol> Notice how everything is conditioned to the system not already presenting that state? tori aims to be idempotent. Running it twice should do nothing the second time it runs so you can run it multiple times while making changes without any doubled effects. I mentioned a base</code> directory. This is what a sample tori directory would look like in its present state: . ├── base │ ├── dhcpcd.conf │ ├── kernel-cmd-line.conf │ ├── packages │ └── vars.sh ├── .bkp │ ├── canonical │ │ ├── etc │ │ └── opt │ └── ephemeral │ └── etc ├── src │ ├── checks.sh │ ├── copy.sh │ └── get.sh └── strap</code></pre> What you are seeing in this sample of the directory are the following files and directories: base</code>: Where you place the configuration files that functions like copy</code> and place</code> will look for and copy into the desired locations</li> .bkp/canonical</code>: Where tori will look for initial backups and create them if none exists</li> .bkp/ephemeral</code>: Where tori will place timestamped backups every time a file is modified or overwritten</li> src</code>: Where the source files live, mostly containing function definitions</li> strap</code>: The main file used to call the functions</li> </ul> Because I developed tori for my own purposes initially, I didn’t really care to separate the actual source files from the context-sensitive data. While a mistake from a higher level, it allowed me to just keep developing the whole system configuration and the code that tracked it from a single, version-controlled location, amounting to very little complexity. I can’t deny to have enjoyed it so far, but going forward that is going to change. Currently, tori is able to install several package managers and their packages, including xbps, apt, nix, opam, stack, cargo, go, sdkmanager, npm, flatpak and pipx. It can also perform several other tasks: setup programming runtimes for OCaml, Scala (via Coursier), Go, JavaScript (node and bun), Rust (via rustup)</li> generate GPG certificates</li> query and set options with update-alternatives</code> and gsettings</code></li> change the user shell</li> check and enable services (systemd and runit)</li> download pre-built binaries from tarballs and (g)zip files, unpacking and making them executable</li> get files through the network using rsync</li> several other things likely not worth mentioning</li> </ul> The application slowly grew to accommodate many of my needs, but I also made it very hard to share with the world in the process, since I never really meant to go public with it. Portability issues #</a></h2> Despite it being very useful to me in its current state and still being something I actively use every day, a lot of it is hard-coded for my very personal use. It was not written with portability in mind and therefore requires a lot of source-code editing to use in a different system. For instance, when I switched from Debian to Void Linux, most of it broke. I certainly would not expect the package list to be compatible between them, but I realized at that point how tightly it was coupled to Debian. When I started delving deeper into FreeBSD and setting up the system, I kept reaching out to something like tori. But it wasn’t there, and it wouldn’t work even if it were. Something that certainly influenced my desire to write tori was my experience using NixOS, which was full of mixed feelings, but undeniably had good feelings that stuck. I really liked being able to manage the system configuration and packages from a single file. But, at the same time, I felt it was overkill. It was limiting because most of the time you were forced to configure things through its interfaces. It was basically incompatible with what every other Unix system expects, and therefore what people who write software for these systems also expect. I appreciated bringing the system configuration to a centralized file, but I certainly did not want to manage all my ~/.config</code> configuration files from that same place. After writing tori, I can choose what to place under its tracking and what not to. Third-party software still works as both me and its creators expect it to, instead of my system breaking things and needing them to work the way it expects. Glad to reinvent the wheel #</a></h2> While I understand there are very mature and powerful tools to manage a system’s state and reproduce it, I am aiming here for a much simpler use case. I have no intention to see it used in enterprise or distributed systems. It is all about managing how your personal computing is set up and having a backup of how you did it. What I need is not a tool that can orchestrate a fleet of containers running a given configuration. What I need is a tool that can run in a bare system that just got installed and get it to a state that feels useful to me. I do not want it to run instructions over a range of IPs, I just want to be able to check at any time if the system state has diverged from the configuration I am using to track it. I wanted a tool that would help me develop a different habit when I need to make system-level changes. And finally, I suppose I just really wanted to build this. I really enjoy the process of configuring operating systems and learning how they work and differ. And I really wanted to learn more about portable, POSIX-compatible shell scripting. So I decided to rewrite it with portability in mind. I am doing this rewrite in FreeBSD, to put the portability to the test. Once some basic functionality is done, the next step will be bringing it to Void Linux, Debian and NetBSD. tori is a bird that has just hatched, so everything is still very, very crude. At this stage, the docs often show intentions rather than implemented functionality. Still, because it is something I’ve come to depend on, it has this rewarding sense of usefulness behind it. If it sounds interesting to you, take a look. You can follow development at the main repository at Codeberg</a> or through its mirrors on GitHub</a> and elsewhere</a>. Going forward, I will also probably be talking a lot about it on my Mastodon profile</a>. Differential Analysis: A Summary 2024-06-28T00:00:00+00:00 aryak/mozhi: Mozhi is an alternative-frontend for many translation engines. - Codeberg.org 2024-06-27T00:00:00+00:00 JFryy/qq: jq multi-configuration format tool with interactive REPL. 2024-06-23T00:00:00+00:00 phyphox | F-Droid - Free and Open Source Android App Repository 2024-06-21T00:00:00+00:00 UserLAnd | F-Droid - Free and Open Source Android App Repository 2024-06-21T00:00:00+00:00 Sounds of the Forest - Soundmap Timber Festival 2024-06-14T00:00:00+00:00 Effects Showroom - TerminalTextEffects Docs 2024-06-10T00:00:00+00:00 Piku 2024-06-10T00:00:00+00:00 Void on ZFS 2024-06-09T00:00:00+00:00 June is here. It brings the usual cold weather and some extra rhinitis complications. With that I find myself in a recovery mood Sunday, wrapped in a blanket with a mug of tea, a screwdriver, some notes on paper, a flash drive, a couple of NVMe cards and the trio of Unix-powered machines that will help me get this done. The mission is to get a root-on-ZFS EFI installation of Void Linux with ZFSBootMenu on a Dell Latitude 7480. To my left, a ceiling-collapse-survivor Sony VAIO is running NetBSD with spectrwm. It’s split with sakura and tmux on a terminal to one side, where Neovim is storing these words, and Firefox on the other, ready to fetch all the docs. In the middle, the object of today’s operation. And to my right, a headless PC board runs FreeBSD with ZFS, holding all the backups needed for the post-install tasks. This lengthy post, written not after the fact but during it, is my way of documenting and also sharing how it all went. Additionally, it’s a way to delve deeper into many of the things the ZFSBootMenu docs leave unexplained, an urge I already had yesterday as I just tried it out without much modification. Last night, I ran through the ZFSBootMenu documentation guide for Void</a> and followed it both on a VM and then on an external SATA HDD plugged through a USB case, taking some notes and getting a general idea of the process. The Void installer does not support ZFS out of the box, so the Void Handbook</a> itself recommends the ZFSBootMenu documentation before its own</a> (a manual chroot installation) when it comes to doing a ZFS-on-root install. This guide from ZFSBootMenu is what we’ll be following throughout this post. Do note that, while comprehensive, my account is no replacement for the original guide</a>. Although more concise, it contains certain notes not included in this post and covers a larger set of possibilities than I did here. Some of the code blocks you’ll see here are identical to the ones from the guide, but many others are specific to how I did things, so keep that in mind and try things before going with your final installation. Why Void? #</a></h2> I don’t really enjoy distro-hopping. I usually will spend a few years on the same OS and only switch for good reason and after some thorough testing. And after some Debian time, I felt interested in trying Void for a few reasons: rolling, but stable</li> runit init system</li> BSD-like rc files</li> BSD-like handbook documentation</li> numerous, up to date, but stable packages</li> </ul> After trying it, some other features made me settle: fast and feature-packed package manager</li> very fast startup time (kudos to runit)</li> first-class support in ZFSBootMenu</li> </ul> The Void package manager, xbps</a>, has several interesting features. One of my favorites, for a taste, is xbps-query --cat</code>, which shows the original contents of a given file in a package. For example, xpbps-query --cat /etc/zfsbootmenu/config.yaml zfsbootmenu</code> will show you the original content of the config.yaml</code> file in the zfsbootmenu</code> package. You can use it for very core packages like base-system</code> or runit-void</code> to determine the original version of files shipped by them. And why ZFS? #</a></h2> My first contact with ZFS was when using FreeBSD, which provides it as an option in its installer, making it a bit too easy not to try. Having a server on ZFS means all the data it holds can be safeguarded and transferred in robust ways, and mistakes are also easier to recover from. Aside from all the data integrity features and flexibility it brings, the features that interest me the most are the ones for managing snapshots. ZFS snapshots allow you to store the filesystem state at a given point in time, and to compare against, access the content of, and fully revert to this state. After the guide has been followed throughout, an extra section at the end of this post has some snapshot basics. Getting in #</a></h2> So, first things first, open the machine up and swap the NVMe cards. For me, that means getting my 128 GB NVMe stick, which I use basically for tests, and replace it with the 256 GB one which currently has Debian on it. Yes, I get by just fine with that much. While a bit dusty, the machine was overall in good state. The release date for the model is 2017, which for my computing standards is very recent. It has a single NVMe slot, one 16 GB RAM stick and one unused RAM slot. If you look closely, you can notice a dent on the vent tube connecting the cooler to the CPU. Despite this, it very rarely heats up. Next up is to boot up hrmpf</a> in EFI mode. hrmpf is a Void-based rescue system maintained by a Void team member and distributed as a bootable image that can accomplish many things, some of them being a full Void installation, entering a proper chroot, and being ZFS-ready with the needed drivers and tools. Once booted into it, EFI support can be confirmed by filtering the output of dmesg</code>: dmesg | grep -i efivars</code></pre> The output should contain “Registered efivars operations”. Make sure you have an Internet connection at this point. Most of the following steps will run fine without one, but closer to the end, when installing the Void base system, it will all go to waste if we can’t reach a package mirror. Setting up the installation environment #</a></h2> The ZFSBootMenu guide uses some variables in order to avoid mistakes and make the instructions more portable across the different storage types and supported operating systems. /etc/os-release</code> #</a></h3> The /etc/os-release</code> file typically contains information on the operating system you are running. In the hrmpf live system, these are its contents: NAME="Void" ID="void" PRETTY_NAME="Void Linux" HOME_URL="https://voidlinux.org/" DOCUMENTATION="https://docs.voidlinux.org/" LOGO="void-logo" ANSI_COLOR="0;38;2;71;128;97" DISTRIB_ID="void</code></pre> For comparison, here is FreeBSD’s os-release</code> file: NAME=FreeBSD VERSION="14.0-RELEASE" VERSION_ID="14.0" ID=freebsd ANSI_COLOR="0;31" PRETTY_NAME="FreeBSD 14.0-RELEASE" CPE_NAME="cpe:/o:freebsd:freebsd:14.0" HOME_URL="https://FreeBSD.org/" BUG_REPORT_URL="https://bugs.FreeBSD.org/"</code></pre> In contrast, NetBSD has no such file. For the purposes of the ZFSBootMenu guide, only the $ID</code> value appears to be used. And because the file already is structured as shell-compatible variable assignments, we just source it: source /etc/os-release export ID</code></pre>hostid</code> #</a></h3> Required by ZFS intallations, a host ID is a 32-bit hexadecimal value that, supposedly, will uniquely identify a machine. Considering the number of existing machines and the 32-bit range, you might guess why I say supposedly. If your machine has the hostid</code> utilities, you can see the host ID by simply running hostid</code>. Prior to generation, my hrmpf live system reports 00000000</code>. It can’t provide a real guarantee that it will be unique, so it’s up to you to take care that it is unique among your machines. Read on for why that’s hardly an issue. From the gethostid(3)</code> man page: […] a unique 32-bit identifier for the current machine. The 32-bit identifier was intended to be unique among all UNIX systems in existence. This normally resembles the Internet address for the local machine, as returned by gethostbyname(3)</code>, and thus usually never needs to be set. </blockquote> This seems to be more or less a legacy feature. In Void’s man page for gethostid(3)</code>, you see this in the history section: 4.2BSD; dropped in 4.4BSD. SVr4 and POSIX.1-2001 include gethostid() but not sethostid(). </blockquote> Still, it is something that OpenZFS requires to be set: At time of import or creation, the pool stores the system’s unique host ID and for the purposes of supporting multipath, import into other systems will fail unless forced. — OpenZFS docs, Introduction to ZFS: Storage pools</a> </blockquote> zgenhostid</code>, which is shipped by OpenZFS, according to its man page “emulates the genhostid(1)</code> utility and is provided for use on systems which do not include the utility or do not provide the sethostid(3)</code> function.” When used without arguments, these commands will generate a random host ID. But they can also be passed a hexadecimal value, which gets stored by default in /etc/hostid</code> unless another path is given with -o</code>. Considering this information, it threw me off a bit that the ZFSBootMenu guide tells you to specify an arbitrary host ID rather than generate a random one: zgenhostid -f 0x00bab10c</code></pre> If they must be unique, that seems odd. The value 0x00bab10c</code> actually has significance in the context of OpenZFS as an identifier (and leetspeak) for its uberblock. However, it apparently is totally unrelated to host IDs. Should you be curious still, you can refer to this GitHub discussion</a> where a ZFSBootMenu user brought this exact question to the developers. According to the answer given above, the uniqueness of host IDs is useful for “multipathed SAS enclosures with two discrete head unis attached”, which is an enterprise-grade storage solution. The value 0x00bab10c</code> is indeed unrelated and chosen for easy identification. Any value may be used, but when using the pre-built ZFSBootMenu images it may make the process slightly slower (around 250ms) as ZFSBootMenu will have to “discover the hostid every boot”. Disk variables #</a></h3> Here too, the ZFSBootMenu guide works with a set of variables</a> to make it easier covering different possible storage types: BOOT_DISK</code>, BOOT_PART</code> and BOOT_DEVICE</code></li> POOL_DISK</code>, POOL_PART</code> and POOL_DEVICE</code></li> </ul> My target device is an NVMe at nvme0n1</code>, so I’ll have: BOOT_DISK="/dev/nvme0n1"</code></li> BOOT_PART="1"</code></li> BOOT_DEVICE="${BOOT_DISK}p${BOOT_PART}"</code> which evaluates to /dev/nvme0n1p1</code> </li> </ul> </li> POOL_DISK="/dev/nvme0n1"</code></li> POOL_PART="2"</code></li> POOL_DEVICE="${POOL_DISK}p${POOL_PART}"</code> which evaluates to /dev/nvme0n1p2</code></li> </ul> </li> </ul> While this may seem silly at first, it allows using the values separately in the next steps. It also makes the docs a lot more concise while covering several possible disk setups. Confirming the environment setup #</a></h3> At this point, we should be able to print something like this in our environment: # env | grep ID ID=void # hostid 00bab10c # echo $BOOT_DEVICE /dev/nvme0n1p1 # echo $POOL_DEVICE /dev/nvme0n1p2</code></pre> Take care to keep this same environment for all the next steps as they depend on it. For instance, the hrmpf live system ships tmux. While that is great and I have used it throughout, you must be careful to use a single pane for all the actual steps, and the other panes just for secondary things like looking up man pages or checking file contents. Filesystem setup #</a></h2> Wiping #</a></h3> The first step is to clear the current ZFS label information from the device: zpool labelclear -f "$POOL_DISK"</code></pre> The -f</code> option will “treat exported or foreign devices as inactive”, per the man page. This step fails consistenly for me, which I assume is because the previous filesystem was not ZFS to begin with. Next, we will use wipefs</code> to erase the current filesystem signature. This command is not ZFS-specific, but part of the kernel utilities. It does not erase the filesystems themselves, nor their content, but the signatures that aid in their detection. Without any options, it will list all the filesystems that are still visible: # wipefs "$BOOT_DISK" DEVICE OFFSET TYPE UUID LABEL nvme0n1 0x200 gpt nvme0n1 0x3d9e655e00 gpt nvme0n1 0x1fe PMBR</code></pre> The -a</code> option is for erasing all signatures. This means it will “scan the device again after each modification until no magic string [signature] is found”, as per its man page. In my case: wipefs -a "$POOL_DISK" wipefs -a "$BOOT_DISK"</code></pre> Along the guide, commands are sometimes repeated for both $POOL_DISK</code> and $BOOT_DISK</code>. If you are using the same disk for both, this may be redundant, although also harmless. This is my case, so I am not typically running it twice. I’ll still leave it as is however, so as not to mislead the reader. Now, when listing the signatures again with wipefs "$BOOT_DISK"</code>, there should be no output. Finally, the current MBR and GPT tables must be destroyed. For this, the ZFSBootMenu guide uses sgdisk</code>. This is also not ZFS-specific. sgdisk --zap-all "$POOL_DISK" sgdisk --zap-all "$BOOT_DISK"</code></pre> The --zap-all</code> option contrasts with --zap</code> in that it will destroy both MBR and GPT partition tables. Partitioning #</a></h3> In the ZFSBootMenu guide, sgdisk</code> is used again for creating the partitions: sgdisk \ -n "${BOOT_PART}:1m:+512m" \ -t "${BOOT_PART}:ef00" "$BOOT_DISK" sgdisk \ -n "${POOL_PART}:0:-10m" \ -t "${POOL_PART}:bf00" "$POOL_DISK"</code></pre> In the commands above, option -n</code> is short for --new</code>, and is specifying the start and end sectors by using relative kibibyte measures. The format is --new partnum:start:end</code>. Breaking it down: 1m</code> 1 mebibyte from the start of the disk</li> +512m</code> 512 mebibytes after the default start sector</li> -10m</code> 10 mebibytes before the last available sector</li> 0</code> the default value</li> </ul> In the list above, “default” is “the start of the largest available block for the start sector and the end of the same block for the end sector”, as per the sgdisk</code> man page. 1:1m:+512m</code>, therefore, means that partition 1 will start 1 mebibyte from the start of the disk and end 512 mebibytes after the start of the largest available block. 2:0:-10m</code>, in turn, means partition 2 will begin at the start of the largest available block and end 10 mebibytes before the last available sector. Option -t</code> is for setting the typecode for each partition. Typecode ef00</code> is for the EFI system partition, and typecode bf00</code> is for “Solaris root”, the Unix system upon whose ZFS implementation OpenZFS was based. For a list of typecodes, see sgdisk -L</code>. While just running these commands as-is is your safest option, you might have a different layout in mind or prefer an interactive UI. For one thing, I’ve had issues in the past with the boot partition being too small, so I’ll be using 2g</code> instead of 512m</code> for it. sgdisk</code> has a friendlier counterpart named gdisk</code>, which you can use just by passing it the disk path, as in gdisk /dev/sda</code>. At this point, you should be safe to try partitioning and going back to wiping as needed until you are satisfied. When you are done, you can use lsblk</code> to confirm the results. The following will show you the options just configured: lsblk -o NAME,SIZE,TYPE,PARTTYPENAME</code></pre>Creating the pool #</a></h3> This part of the guide was the one that actually made me want to delve deeper and understand what each option meant. With little knowledge about ZFS still, I wanted to understand precisely what was happening here, but also what a pool even is and what its creation meant. Here’s the zpool(8)</code> man page: A storage pool is a collection of devices that provides physical storage and data replication for ZFS datasets. All datasets within a storage pool share the same space. </blockquote> The definition of a dataset is then indicated to be at zfs(8)</code>: A dataset is identified by a unique path within the ZFS namespace: pool[/component]/component</code> for example: rpool/var/log</code> </blockquote> Here, it’s also explained that a dataset can be a file system, logical volume, snapshot or bookmark. Further information is also hinted to be found at zpoolconcepts(7)</code>. At this point you start to notice the breadth of knowledge available in the documentation. The man pages are not only comprehensible, but sometimes contain several examples on how to apply their concepts. Each command has their own man page named with a hyphen for separation, as in zpool-create</code>. We’ll be exploring only the zpool-create(8)</code> command in depth, in particular the options used in the ZFSBootMenu guide: -f</code> force the use of virtual devices, even if they appear in use</li> -o feature=value</code> set a pool feature</li> -O property=value</code> set a file system property in the root file system of the pool</li> -o compatibility=off|legacy|file[,file]</code> specify a compatibility feature set</li> -m mountpoint</code> the mountpoint (default: /pool</code>)</li> pool</code> the pool</li> vdev</code> the virtual device</li> </ul> The listing with pool features (including compatibility feature sets) is at zpool-features(7)</code>. Pool properties are at zpoolprops(7)</code> and file system properties at zfsprops(7)</code>. In the guide, these are the options given: zpool create -f \ -o ashift=12 \ -O compression=lz4 \ -O acltype=posixacl \ -O xattr=sa \ -O relatime=on \ -o autotrim=on \ -o compatibility=openzfs-2.1-linux \ -m none zroot "$POOL_DEVICE"</code></pre> Among the options above, several pool features and system properties are set: -o ashift=12</code> “Alignment shift”, used to calculate physical sector sizes.This is discussed at greater length in the online documentation on Workload Tuning</a></li> -O compression=lz4</code> Sets the compression algorithm used (LZ4</a>)</li> -O acltype=posixacl</code> Whether ACLs</a> are enabled and what type to use. The value posixacl</code> is equivalent to posix</code> (default on Linux: off)</li> -O xattr=sa</code> Enables extended attributes. If value is on</code>, uses directory-based extended attributes, while sa</code> uses system-attribute-based. The latter has performance benefits, and is important for ACLs and SELinux usage</li> -O relatime=on</code> “Causes the access time to be updated relative to the modify or change time.” Also, “access time is only updated if the previous access time was earlier than the current modify or change time or if the existing access time hasn’t been updated within the past 24hours”</li> -o autotrim=on</code> Automatically reclaims unused blocks from time to time. Can put the filesystem under some stress</li> </ul> The last option, the compatibility feature set, specifies in this case a relative filename to /usr/share/zfs/compatibility.d</code>: -o compatibility=openzfs-2.1-linux</code></li> </ul> zpool-create(8)</code> also states: By default, all supported features are enabled on the new pool. The -d</code> option and the -o</code> compatibility property […] can be used to restrict the features that are enabled, so that the pool can be imported on other releases of ZFS. </blockquote> The compatibility option openzfs-2.1-linux</code> is described as a “conservative” choice in the ZFSBootMenu guide and in my tests had little impact, so I decided to not use it for this installation. Creating the filesystems #</a></h3> Once the pool is ready, the filesystems can be created. For this task, the zfs</code> command is used with create</code>: zfs create -o mountpoint=none zroot/ROOT zfs create -o mountpoint=/ -o canmount=noauto zroot/ROOT/${ID} zfs create -o mountpoint=/home zroot/home</code></pre> The ZFSBootMenu guide explains at this point that if canmount=noauto</code> is not set on file systems with the /</code> mountpoint, the OS will try to mount them all and fail. It goes on to say: Automatic mounting of / is not required because the root file system is explicitly mounted in the boot process. </blockquote> After the filesystems have been created, the boot file system must be set. zpool set bootfs=zroot/ROOT/${ID} zroot</code></pre> Essentially, this is saying “set zroot</code>’s bootfs</code> property to zroot/ROOT/void</code>” Export, reimport and mount #</a></h3> The next steps consist in exporting and then importing the pool with a given mountpoint. zpool export zroot zpool import -N -R /mnt zroot</code></pre> From what I gather, exporting means putting the pool in a more portable state. According to the zpool-export(8)</code> man page, “the devices [marked as exported] can be moved between systems […] and imported as long as a sufficient number of devices are present.” If zfs import</code> is used without any arguments, it will list the exported pools available to be imported. The -N root</code> option imports the pool without mounting any of its file systems, the -R</code> option “sets the cachefile</code> property to none</code> and the altroot</code> property to root</code>”. In this case, that root</code> will be /mnt</code>. altroot</code> stands for the alternate root directory. In zpoolprops(7)</code>, this becomes clearer when it is stated that “this directory is prepended to any mount points within the pool.” Once re-imported, we can mount: zfs mount zroot/ROOT/${ID} zfs mount zroot/home</code></pre> And verify that all is mounted correctly with mount | grep mnt</code>: # mount | grep mnt zroot/ROOT/void on /mnt type zfs (rw,relatime,xattr,posixacl,casesensitive) zroot/home on /mnt/home type zfs (rw,relatime,xattr,posixacl,casesensitive)</code></pre> Lastly, we request the device events from the kernel to update the device symlinks: udevadm trigger</code></pre>Setting up Void #</a></h2> Installation #</a></h3> So far, not much here was Void-specific. This is when we start bootstrapping the void system into the filesystem we laid out. XBPS_ARCH=x86_64 xbps-install \ -S -R https://repo-fastly.voidlinux.org/current \ -r /mnt base-system</code></pre> Here, we are passing an environment variable to set the architecture to x86_64</code>, then use xbps-install</code> from the xbps package manager to fetch the Void base system. -S</code> takes care of synchronizing the data from the mirror so that package data is fetched, -R</code> allows us to manually specify the repository for this run, and -r</code> allows choosing a different root directory to act upon. Here, I chose the Fastly mirror over the ServerCentral one. Any working mirror</a> should do. Note that not all mirrors have the same content at the root of their URL. Some point directly to a Void repo, some don’t. You can access the mirror in a browser or otherwise inspect it to find the path to the current</code> directory. With this done, we can copy the host ID file, which will also be required in our final system, and we are ready to chroot. cp /etc/hostid /mnt/etc</code></pre>chrooting #</a></h3> We will chroot into the system mounted at the /mnt</code> directory using xchroot</code>, which is part of the xbps xtools</code> package and should already be available on hrmpf. It provides a more sane</a> chroot than the plain one, in particular regarding the required mountpoints: xchroot /mnt</code></pre> This is a good time to get back to the notes I mentioned taking the day before. Reconfiguring packages #</a></h4> After chrooting, it may be a good idea to run xbps-reconfigure</code> to make sure packages are properly configured. This is because in the bootstrap process some packets may have tried to configure themselves while relying on directories that were not mounted anywhere. This is particularly true for dracut</code></a>, which is a tool that generates initramfs and initrd images, therefore being critical to the early boot process. You might see error messages related to it in your first run of xbps outside of the chroot, when installing the base system. To reconfigure all packages, just run xbps-reconfigure -fa</code>. If you’d rather only reconfigure dracut</code>, go with xpbs-reconfigure -f dracut</code>. root password #</a></h4> As early as possible is a good time to run passwd</code> and set the root password. rc.conf</code> #</a></h4> runit</code> reads the /etc/rc.conf</code> file during startup to configure the system, setting up things like the keymap, hardware clock and terminal font. For your reference, here is what I added to mine during the installation: HARDWARECLOCK="UTC" KEYMAP="br-abnt2" FONT="ter-120n"</code></pre>Time zone and locale #</a></h4> To configure your local time zone, create a symlink at /etc/localtime</code> that points to the corresponding time zone in the /usr/share/zoneinfo</code> directory. ln -sf /usr/share/zoneinfo/<timezone> /etc/localtime</code></pre> Unless you are using musl</code>, you also want to set and generate the glibc</code> locales. Edit /etc/default/libc-locales</code> and uncomment the desired locales, then run xbps-reconfigure -f glibc-locales</code>. dracut #</a></h4> dracut</code> generates file system images used by the kernel at the very early stages of boot. We have to make it able to identify our ZFS root filesystem by enabling the proper modules. This is accomplished by creating /etc/dracut.conf.d/zol.conf</code> with: nofsck="yes" add_dracutmodules+=" zfs " omit_dracutmodules+=" btrfs "</code></pre> Notice the spaces surrounding the module names. Installing and configuring ZFSBootMenu #</a></h2> We are now ready to install both ZFS and ZFSBootMenu. Let’s start with ZFS: xbps-install -R https://repo-fastly.voidlinux.org/current zfs</code></pre> Now, before installing ZFSBootMenu, we set the kernel commandline. This is the command line that will be used by the Linux kernel, so any options you are used to go here. The ZFSBootMenu guide has only the quiet</code> option. In my case, I added net.ifnames=0</code> to have the classic eth0</code>, wlan0</code> network interface names, and fbcon=nodefer video=efifb:nobgrt</code>, which prevents the manufacturer’s logo from showing after boot and sometimes obscuring the boot process output. zfs set org.zfsbootmenu:commandline="quiet net.ifnames=0 fbcon=nodefer video=efifb:nobgrt" zroot/ROOT</code></pre> We also need a vfat</code> filesystem on our boot device: mkfs.vfat -F32 "$BOOT_DEVICE"</code></pre> Now we can add an /etc/fstab</code> entry pointing to it, and mount: echo "$(blkid | grep "$BOOT_DEVICE" | cut -d ' ' -f 2) /boot/efi vfat defaults 0 0" >> /etc/fstab mkdir -p /boot/efi mount /boot/efi</code></pre> Into this directory we just mounted, we can now install ZFSBootMenu. The guide provides two different paths here: a prebuilt image or the Void package, which you can get through xbps. While there are advantages to both, I decided to go with the prebuilt image since I’d rather the package manager not touch the boot manager on updating. This has the downside of you having to take care of being aware of any relevant versions and when to upgrade to them. xbps-install curl mkdir -p /boot/efi/EFI/ZBM curl -o /boot/efi/EFI/ZBM/VMLINUZ.EFI -L https://get.zfsbootmenu.org/efi cp /boot/efi/EFI/ZBM/VMLINUZ.EFI /boot/efi/EFI/ZBM/VMLINUZ-BACKUP.EFI</code></pre> If you’d rather use the repository package, see the corresponding instructions in the guide</a>. Finally, a second choice has to be made between rEFind</code> or plain efibootmgr</code> for managing the boot entries. I prefer to go with the simpler one, but you may find rEFind</code> more feature-packed. First, install efibootmgr</code> using xbps-install efibootmgr</code>, then run the following commands: efibootmgr -c -d "$BOOT_DISK" -p "$BOOT_PART" \ -L "ZFSBootMenu (Backup)" \ -l '\EFI\ZBM\VMLINUZ-BACKUP.EFI' efibootmgr -c -d "$BOOT_DISK" -p "$BOOT_PART" \ -L "ZFSBootMenu" \ -l '\EFI\ZBM\VMLINUZ.EFI'</code></pre> If you’d prefer to use rEFInd, see the guide’s relevant section</a>. zbm-kcl</code> is mentioned here in passing. This utility allows you, among other things, to set ZFSBootMenu options, such as the delay before automatically booting. I am not sure if it comes included with the ZFSBootMenu package, as I went for the pre-built image, but you can nonetheless get it from GitHub: curl -O https://raw.githubusercontent.com/zbm-dev/zfsbootmenu/master/bin/zbm-kcl chmod +x zbm-kcl</code></pre> Now, if you want to change an option, you can use its -a</code> option to append an argument to the target image’s command line: zbm-kcl -a 'zbm.timeout=2' /boot/efi/EFI/ZBM/VMLINUZ.EFI</code></pre> In the example above, the timeout before automatically booting is set from its 10 seconds default to 2 seconds. Getting out #</a></h2> We are all done. It’s time to exit the chroot, unmount and export the pool. exit umount -n -R /mnt zpool export zroot</code></pre> If all above went well, we can now run reboot</code>, remove the flash drive used for installation, and log in for the first time into our new system. ZFS snapshot basics #</a></h2> Something you might want to do at this point is to take a snapshot of the current state, since it can serve as a baseline before any further tweaking, allowing you to go back or access the files in this state as you make important changes that could potentially break the system. zfs snapshot -r zroot/ROOT/void@baseline</code></pre> Note that, if you followed the ZFSBootMenu guide in creating a separate dataset for your home directory, this snapshot will not include the contents inside and under /home</code> (which at this point should be empty anyways). You can access the contents of a snapshot at any time in the .zfs</code> directory at the root of a given dataset. For the ones we previously set up, those would be /.zfs</code> and /home/.zfs</code>. Note that these directories are not only hidden in the traditional way, but they won’t show up even if you use ls -a</code>. You need to actually cd</code> into the apparently absent directory for it to work. ZFS snapshots start taking virtually no space at all, but grow with time as the snapshot drifts from the present system state. For that reason, keeping a snapshot of the very first moment of your system can take up significant space. Depending on your storage resources, you might eventually decide to destroy this snapshot: zfs destroy -r zroot/ROOT/void@baseline</code></pre> You may also want to list your current snapshots. While typically you can use zfs list -t snap</code>, I tend to use the following command in order to get more relevant output: zfs list -t snap -o creation,name,used,written,referenced,refcompressratio -S creation</code></pre> Finally, you might want to rename a snapshot: zfs rename -r zroot/ROOT/void@baseline @day0</code></pre> Combined, these commands can get you as far as an automatic, rolling snapshot system. Say, for instance you add the following to rc.local</code>: zfs destroy -r zroot/ROOT/void@fallbackBoot zfs rename -r zroot/ROOT/void@previousBoot @fallbackBoot zfs rename -r zroot/ROOT/void@currentBoot @previousBoot zfs snapshot -r zroot/ROOT/void@currentBoot</code></pre> This would give you a per-boot snapshot trail to rely on. The zfs-snapshot(8)</code> man page provides a similar example for daily snapshots. Considering how simple the zfs CLI is, scripting several snapshot schemes can be quite easy, be them per boot, daily, or even every so many minutes using cron. Because ZFS snapshots grow as they drift from the present state, rotating them is optimal when storage space is a concern. That’s it! I hope this was helpful to you in either learning about ZFS or about Void installations with Root on ZFS. Originally written June 2nd, 2024 Share Paste O2 | F-Droid - Free and Open Source Android App Repository 2024-06-08T00:00:00+00:00 hackerb9/lsix Like ls, but for images. Shows thumbnails in terminal using sixel graphics. 2024-06-06T00:00:00+00:00 Moving Beyond Type Systems | Vhyrro's Digital Garden 2024-06-06T00:00:00+00:00 Capital Offense How to Handle Abbreviations in CamelCase - Approxion 2024-06-05T00:00:00+00:00 Meeting the BSD family 2024-05-20T00:00:00+00:00 During this year I have been delving deeper and deeper in the BSD realm. Switching my home server to FreeBSD, trying NetBSD and OpenBSD on my backup machine, getting a cheap SSD to see how they’d all run on my main one, all beaming with the joy of tinkering and learning. As a nerd who delights in reading documentation, manuals and handbooks, I feel like I have found a gigantic library to lose myself in. And to me the delight of such reading is in that it’s never a passive learning experience, but something you can act on and bring to fruition yourself. While Linux-based operating systems, with all the popularity they have gained, have developed into a complex and extremely active ecosystem, the BSD operating systems feel less bloated and more focused on whatever their specialty is. You can’t really complain about software availability, given the amount of pre-packaged binaries you will find. When trying FreeBSD, I could not miss anything I needed. More recently, on NetBSD, I also found most of the tools I reached for. Though I have a mostly text-driven workflow, doing almost all things with a browser and a terminal alone – which certainly helps in making your stack more portable – I do rely on some GUI applications for the domains where they excel. What you might experience is a slower pace of change for major things, such as on Wayland adoption, which like it or not is coming for all of us with X deprecation looming. Running BSD is an incredible opportunity to really learn about UNIX-like systems and operating systems in general. Recently, I’ve been learning more about NetBSD after spending some time with FreeBSD. And this inner diversity of fully-independent operating systems with their own kernels and perks keeps multiplying the learning opportunities. If you already learned a lot about whatever OS you currently use, I’d say particularly if that OS is Linux-based, when you start to play with a BSD system you are able to realize what is similar and what is not. Whatever is different is likely teaching you the more portable, UNIX way of doing things. Even if it isn’t, it’s teaching you how a different OS is designed and behaves. Things that are the same, which are not few, also offer learning opportunities. You get to see what parts of a Linux-based OS perhaps didn’t really originate there, or aren’t in any way an exclusive feature of it. Now, to lay any zealousness aside and not make this a saccharine one-sided tale, I’d also like to mention a certain social phenomenon that this endeavour reminded me of. This is certainly not something specific to BSD, but because it has such an engaged and savvy community, you definitely get to notice it sometimes. I’m talking about the tendency to identify with and then indiscriminately defend the software you use. One common meme you’ll find is people complaining about lack of hardware support, especially wifi. In response, I’ve seen people stating with little nuance that any difficulty to getting your hardware to work on <insert a BSD OS here></code> is to be explained by poor skills or lack of dedication in reading the documentation. I see that as denial. When everyone around is just defending something to no end, no critiques allowed, it starts to feel… awkward, to say the least. Conversely, when I see people openly pointing out weaknesses in something I value and that I can tell they also care for, I feel relief and admiration for that person and that community at large. And thankfully I have also found a lot of this among the BSD folks. Because running a given operating system on a machine you rely on is such a big commitment, it intensifies this phenomenon where users start to identify with the software they use and defend it beyond reason. It happens with frameworks, desktop environments and window managers, but operating systems require you to commit even more because you can’t just swap them as easily, so my guess is we identify to compensate this sense of being tied to it. And from this identification comes an urge to deny any defect. If you are cognizant of the perils, identifying with something is not necessarily a bad thing, though. To some extent, it is inevitable, and being really into something, caring about it, nurturing immense curiosity and a desire to discuss it, are all sources of pleasure I do not excuse myself from. Software wars aside, getting to know this family of operating systems better has been a joy. It opened up whole new avenues and perspectives to understanding operating systems as a whole, and how beyond Linux-based OSs there are numerous other free and open source operating systems that strengthen the diversity in this field.