NULCODE

RockPro64 LEDs

Mon, 26 Oct 2026 19:00:00 +0000

Disclaimer

This blog post is written based on a session I had with Google Gemini, googling for “RockPro64 toggle GPIO in U-Boot”.

Of course, nearly like always, the register name, page or chapter, were nowhere to be found in linked documentation, great!

The conversation turned to hell, where it was super hard to not ragequit or throw insults at it. Classical, I know…

As the topic might be more interesting than “I’m too stupid to browse the internet nowadays” which could also be a topic itself, I decided to make a blog post out of it.

So, if you’re in YOLO mode, just type this in U-Boot, this is roughly what the fantastic LLM told me to do, what could go wrong?

mw.l 0xff730004 0x00000012
mw.l 0xff730000 0x00000012

The hardware world

I’m using a RockPro64 from Pine64 as a server (the famous one with the RAID issue I’m still fighting with).

I’m not sponsored; a friend of mine bought the board and didn’t use it anymore.

So, the RockPro64 is in its case, the white LED barely visible, and as I cracked down and needed to open the board for further diagnostics anyway, let’s add some LEDs to it.

After consulting the pins mapping table, let’s go for pins 15 and 16: mapped to GPIO Chip 1, Lines 1 and 4. Why these? Because GPIO1_A1 and GPIO_A4 sound good.

Picture of the setup

Side notes:

Always use resistors with LEDs (220 Ohm is my goto value, yes it’s a topic you can spend time with, but avoid wasting time debugging with burnt LEDs).
Stay away from the kind of cheap bread boards you see on the pictures, I spend ~30 minutes of debugging why the setup didn’t work, just because some columns of the breadboard have shorts of faulty contacts. Great!

Don’t worry about the hardware details, the only relevant stuff to follow here:

RockPro64: the System on Chip (consider this to be a CPU if you don’t know this term, that’s fine) is a Rockchip RK3399.
We’re using CPU Pins GPIO1_A1 and GPIO1_A4 as GPIOs.

Finding documentation

So you want to find the reference manual of the CPU you have on your desk, beware and welcome to the fantastic hardware world…

If you want to play a game, go to rock-chips.com and try to find the reference manual of the RK3399 CPU.

Hint: we’re talking about one or more heavy PDFs, in the ballpark of thousands of pages for such a chip.

The English button is on the top-right corner, don’t thank me: you won’t find any info in English either.

The wayback machine link just in case

Did you find something else than the marketing datasheet of ~75 pages?

I tend to use the great wayback machine to link stuff (disclaimer: I’m financially supporting it). In this specific case it’s mandatory: the datasheet is officially gone.

And the results of the game… Whaaat, you gave up? Ok, me too.

If you didn’t want to play the crappy game, here’s what you missed

Fun fact: I made a typo writing this article and discovered that rock-chip without ‘s’ also exists and references Rockchip stuff fair enough.

Here are the links to the confidential reference manual part 1 and part 2… from the Stanford Secure Computer Systems group; Archived FTP

Kudos to Stanford and a cool discovery for me: Zachary Yedidia who studied there and made them host the refman for us. Definitely prefering linking a low-level hard-core hacker (which also had fun with incremental compilation, in D, not in Zig) than a random hardware company making its documentation as accessible as usual in this domain.

Yes, this document is probably outdated with a shit ton of erratas barely documented, no I don’t care (plus looked for this documented intensively twice, once really searching for it, another time writing this post wanted to make sure I didn’t miss it).

Here I just want to set a GPIO, so fine I’ll take what I find. If I were to pick a board seriously or evaluate hardware to base something long-term-ish, this would be a red flag.

As this document is officially (still?) confidential, it’s understandable that Pine64 does not host it, but this is still a pain point.

RTFM

So, after raging about why the fuck is it so hard to find a document in the hardware world, how do we proceed?

Remember that we used the pins of the RockPro64 mapped to the CPU to GPIO1_A1 and GPIO1_A4. It means we need to find at which address are these pins of the CPU mapped.

Meta: in this kind of overwhelming documents, the stuff working for me: scroll through the table of content and always jump back to it. Do not search in the document yet, taking the risk to end up page 666 and seeing your PDF viewer freezing loading the thousands next results without a way back. Don’t rely on me to advertise LLMs, but generally uploading a few chapters and let them process these looking for specific information works fairly well whereas they just explode if you somehow manage to upload the full PDF.

So, let’s go: I went for the “Part 1” because after opening both, I didn’t see a clear explanation of which one if for what (probably if you register on their website as a manufacturer promising to buy million of chips you get a better explanation of why the reference manual is split in two parts, but not today).

GPIO Group 1

Hey, we’re lucky this time, the memory mapping is the very first chapter.

We’re greet by the memory mapping, happily showing us where the GPIOs are mapped (if only any info could be found that easily…).

The GPIO1 group is mapped at address $FF73_0000 let’s keep this in mind.

GPIO lines 1 and 4

Now, we need to find where the lines 1 and 4 (where we plugged the LEDs) in the GPIO group are mapped.

As everything is well done, you can click on the GPIO1 entry of the table to jump to the relevant page. Nope, just kidding, stop using your Windows tool called a mouse, there is of course, no link here, so go back to the table of content.

After some scrolling in the table of content, the GPIOs chapter.

Let’s go directly to the registers section of the GPIO chapter.

Relevant GPIO registers

The interesting registers for us are:

Data Direction register (GPIO_SWPOARTA_DDR), as we need to specify that the LEDs are output.
Data register (GPIO_SWPOARTA_DR), do we want to set or reset the GPIO.

Let’s write

Ok, we have 32 bits to set to say that lines 1 and 4 are output and set high (to 1). How to know what these bits represent?

GPIOs overview: 32 bits - 32 signals

This means that signals (lines) 0 to 31 are mapped to bits 0 to 31. The lines 1 and 4 we’re interested in correspond to bits… 1 and 4, yes you follow.

Let’s set the GPIO1 Lines 1 and 4 to output (a LED is an output device, a keyboard an input device from the CPU perspective).

in binary: 0b0001_0010 (the line 0 is mapped to the bit 0). This is 0x12 in hex.

Direction: Output

Data Direction Register: set the LEDs as output

0 is input and 1 is output (what we want for our LEDs): Let’s write 0bXXXX_XXXX_XXX1_XX10 to this register!

What’s the value of ‘X’? I’m ~~lazy~~ a professional! So, I force the bits I don’t care to their default value (in this case, input: 0). To do this cleanly, it would be a good idea to read the GPIO value and OR the relevant bits we want to set. We have no idea what the other thirty signals (lines) are mapped to, and we just set them to input writing 0x12…

In U-Boot to write 32 bits, use a long: MemoryWrite.long: mw.l which takes an address and a value:

mw.l 0xff730004 0x00000012

Now that the relevant GPIOs are configured as output, let’s set them to high (ON).

Value

Data Register: set the LEDs ON

“Value written to this register are output”, so let’s set the LEDs high (set to 1). We can use the same mask as before to set both LEDs. mw.l 0xff730004 0x00000012

Or control independently line 1 with mw.l 0xff730004 0x00000002 and line 4 with mw.l 0xff730004 0x00000010

… And the LEDs turn on \o/

I hope some of the hardware / software thin frontier hard to grasp stuff were a bit demistified.

It does not have to always end badly Reading The Fucking Manual

Bonus stages

Play with a GPIO under Linux

Directly writing to /sys/class/gpio/ is deprecated… for a decade.

Use instead gpioset -t0 --chip 1 4=1 for instance to set the GPIO group 1 line 4 to 1.

Permanent U-Boot config (under Armbian)

One needs to create a U-Boot script and recreate the image to load this on boot (again, probably a bad idea to set every unused GPIO of the first group as input).

Create a uboot script (for instance in /boot/uboot_leds.cmd)

echo "Turning both LEDs ON"

# Set GPIO1 lines (bits) 1 and 4 to output
mw.l 0xff730004 0x00000012

# Set GPIO1 lines 1 and 4 to high
mw.l 0xff730000 0x00000012

Then, recreate the image (fixup.scr is a hard-coded Armbian output name, you may have to adapt this part).

mkimage -C none -A arm64 -T script -d /boot/uboot_leds.cmd /boot/fixup.scr

Loud ugliness (under Linux)

As you may have guessed, having LEDs in a closed box is not that ideal and there is no buzzer, by experience I cannot rely on the network, so to have even more fun I hi-jacked the fan (which turns anyway at the incredible speed of 0 RPM to cool down a board and 2 SSDs doing nothing most of the time).

By hi-jacking I mean: let’s spin it in an SOS pattern if something goes wrong so that you have audible feedback while passing by instead of actively having to peak at the box from time to time to check if a LED is on.

Depressing quick but really dirty echo:

echo 255 > /sys/devices/platform/pwm-fan/hwmon/hwmon3/pwm1

Really dirty because… actually someone else plays around with the fan along with you echoing in the PWM (who could have forsee this?).

Which means that the real code I use echoes periodically to make a Morse dot or dash.

Plus, don’t do that if you really need your fan btw…

That said, it works good enough for my use case; Spoiler alert: someone asked me why is the server doing weird noises, the question you don’t want to hear after a normal shitty day.

NixOS re-re-re-build

Wed, 21 Oct 2026 18:30:00 +0000

Slowly filling up `/boot`

Someone on this blog wrote about NixOS:

Having a look at the garbage collector: after a few weeks (85 builds), 141MB free over 1GB on /boot good to keep in mind…

So guess what, /boot went full.

Actually it’s worse than that: I didn’t care, because I thought that I would just need to invoke the garbage collector to fix the issue when it will show up.

Garbage collecting

So, let’s run sudo nix-collect-garbage --delete-older-than 7d as planned… and it doesn’t clean up /boot

Searching online for the correct nix tool to do this and the stuff popping up look like:

Don’t let this happen, fix your config (fair enough, that’s a valid answer, but not to this problem)
sudo nix-collect-garbage --delete-older-than 7d yes, if /boot is not already full
Complain about the fact NixOS does not prevent this to happen (to be fair I’m not aware of a distro preventing this, and this is an issue I quite respect as it is often noticed the hard way on the next boot)

What bothered me a bit (and that’s why actually this post exits) is that there does not seem to be a “clean” nix way to do this.

So, maybe I didn’t find the clean solution I looked for but what at least worked for me (and should work on any system): delete manually a few entries in /boot/EFI/nixos/

I only deleted the last two oldest kernels and initrd sets, don’t need to nuke everything, as I wanted to check that the garbage collector worked as intended, when it can.

sudo nix-collect-garbage --delete-older-than 7d

Yes… this cleans /nix/store, but I couldn’t find a message about removing stuff in /boot on success (if /boot is full, it does not report anything either…).

Now, building is possible again nixos-rebuild switch --flake /etc/nixos and df reports a sane /boot again.

I’d like to investigate the internals of NixOS to understand why nix-collect-garbage cannot delete stuff in this very situation or who exactly deletes stuff.

Notes

NixOS gives a great feeling of resilience. If you want to sneakily nuke NixOS, maybe start with dd if=/dev/urandom of=/boot/let_us_fill_this_boot_partition and break the current system.

Apparently you also can run in a very similar issue if /tmp fills up (iirc a full /var on Debian also leads to interesting issues).

There is this fairly old NixOS open issue about this

Use something like boot.loader.systemd-boot.configurationLimit = 5; in your config.

Let's try something new! Rust?

Sun, 18 Oct 2026 10:00:00 +0000

Picking up a new programming language

I wanted to give Rust a fair try, the last time I didn’t go far and the only stuff I truly remember about Rust is this tiny detail, which still puzzles me:

fn main() {
  let a = 2; // a is an integer
  // a = "2"; // failure: sting assignment to an integer, ok
  let a = "2"; // compiles... WTF!? Yes it's re-defined, but this design choice...
}

This tiny snippet compiles fine, with unused warnings. A warning free version on Compiler Explorer Or use this full link just in case

Zig philosophy

I discovered Zig reading somewhere that it wanted to be a better C, and I chuckled (like really, how robust are their shoulders to support their heads while saying this?), but then wanted to have a look at its official website to confirm this by myself, just to discard it from my programming languages to check list.

Actually, I realized quickly it has many good ideas, not only stuff you would expect from modern programming languages (readable compile time stuff for instance), but also some specifics (avoiding hidden control flow / memory allocations).

Everything’s monolithic.

Zig comes with a compiler (no shit…), a standard library, but also a package manager, unit tests framework, formatter, fuzzer, …

I had no strong opinion about this, but the more I dig into Python and see people using multiple package managers, formatters and tests frameworks in a single project without noticing it or understanding why it’s fishy and then complaining that nothing’s compatible, the more I think it’s not a bad idea to centralize stuff.

Installing Zig means downloading and extracting a ~55 MB (at the time of writing) .tar.xz and… that’s it.

$ wget https://ziglang.org/download/0.17.0/zig-x86_64-linux-0.17.0.tar.xz
--2026-10-18 08:47:32--  https://ziglang.org/download/0.17.0/zig-x86_64-linux-0.17.0.tar.xz
Resolving ziglang.org (ziglang.org)... 2a01:4f9:3051:4bd2::2, 65.109.105.178
Connecting to ziglang.org (ziglang.org)|2a01:4f9:3051:4bd2::2|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 57332648 (55M) [application/octet-stream]
Saving to: ‘zig-x86_64-linux-0.17.0.tar.xz’

zig-x86_64-linux-0.17.0.tar.x 100%[===============================================>]  54.68M  6.18MB/s    in 9.6s    

2026-10-18 08:47:42 (5.69 MB/s) - ‘zig-x86_64-linux-0.17.0.tar.xz’ saved [57332648/57332648]

$ ls -lh zig-x86_64-linux-0.17.0.tar.xz
-rw-r----- 1 jp jp 55M Oct  2 21:55 zig-x86_64-linux-0.17.0.tar.xz

$ tar xf zig-x86_64-linux-0.17.0.tar.xz

$ zig-x86_64-linux-0.17.0/zig version
0.17.0

Congratulation, you installed zig!

Oh btw, why 55 MB, isn’t it quite heavy? After decompression, the zig binary takes roughly half of the extracted weight. Something I didn’t mention is that Zig embedds a C compiler (note that Zig does not transpiles to C though). The rest of the weight mostly comes from the libc (42% you cannot compete with this).

du-dust from extracted zig tarball

I left the raw dust output because maybe you noticed on the screenshot, the presence of multiple C libraries, and maybe also the unexpected presence of mingw in a x86_64-linux so, cannot the Zig maintainers properly pack their artifacts or is there a real reason?

Zig is actually a cross-compiler.

Cross-compilation in Zig is still a topic I need to deep dive into. Zig can cross compile for many targets (different BSD flavors, arm-linux-gnueabihf, the dreaded Windows, …). Actually the Zig build system can be a drop in replacement to cmake, autotools, …

For which exacts targets can you compile you may ask? Many! This time, no full output, because…

$ zig targets | wc -l
35009

Zig respects the C ABI. Zig competes sanely with C, it embraces C not trashes it. The decades of legacy still lives on, and Zig can help you with it instead of telling you to re-write everything with the new shit.

Killer features

Incremental compilation

The idea is simple: compile only what you need to compile: if you modify one local variable without side effects, do you need to recompile the full project?

This is the kind of black magic I didn’t even realize it was possible before learning the Zig core team worked on it. I mean, binary patching is a thing (and, no I don’t mean asking a LLM to not modify some specific sources and… noticing this fucker patched the binary instead). But, hotfixing with the linker, like really? You need to know about dependencies, side-effects, linker sections, …

If you want to dive in this topic, Matthew Lugg from the core team wrote a blog post about this; definitely worth multiple reads.

Oh, btw yes, the core team implemented their own linker.

Optimization

We’re talking about custom linker, custom C compiler, everything done the Zig way, so what we just throw away decades of optimization in other toolchains? Actually no: LLVM is still used as the backend in optimization mode (--release=fast)

The custom backend is used for debugging, incremental compilation, … but the LLVM one is used (so far?) for optimization.

For the size optimization side, the standard library is optional, you can go bare-metal.

Simplicity

This language actually focus on simplicity, or in other words, forcing the user to understand what’s going on.

You want memory? Ok, how do you want it allocated?

You want to print something? Oh buffered print this time, fine, where is your buffer?

We constantly hear about C++ devs arguing that there is no overhead in C++ which can be true, if you know exactly what’s going on.

Either perf says: nope, it’s slower than you thought, or you hear a dev mumbling something like “ok this operator overload so, this constructor will be called, then Short String Optimization kicks in, …” and after a few minutes, arguing against perf results.

In Zig, reading the code gives you clear hints on what’s going on. For instance, if a function needs to allocate memory, it will likely take an allocator as argument.

The best of all worlds

Zig feels like having the best of all worlds:

It can feel like an interpreted language, without compilation time, but with compilation checks before blindly running a binary crashing with a parse error.

Fair comparisons show C-runtime performances levels.

If your code is too slow, measuring will likely not pinpoint to unknown regions, where you ponder why a strlen coming directly from GCC is magically called, but more on your handwritten code.

Drawbacks of Zig

None, next section… No? Ok.

Evolving fast

Zig is under heavy development. The core team regularly breaks stuff and removes features. Blindly upgrading to the next release can be a breeze, where the formatter will do the job for you (no kidding) or a painful death.

Try to keep an eye on the devlog, the forums or ideally on the repo on codeberg for instance to have a feeling on what you should already modify or stop doing.

Documentation

The documentation is really poor (let’s troll: there is no documentation), but the sources are readable. I mean it: I have a fair C or C++ experience, using these professionally for most of my career. For me, opening the C standard library is doable, the C++ one is a no-go, always ending up with more questions, assuming I found what I was looking for.

The Zig sources often contains unit tests. You can rely on these and they give you a quick and meaningful way to use some feature.

The language can feel too simple.

Consider this: there is no direct support for classes; indeed OOP is not the only truth, don’t forget about Data Oriented Design or the Zig version).

Let’s try it

I don’t have a fancy ritual to share while picking a new programming language. I do something like this:

Try to grasp the idea of the language (Which problem does it solve?): Read the home page
Have a glance at the syntax
Scroll through the documentation
Browse randomly its standard library
Follow some tutorials
Begin writing trivial programs (let’s say “Guess the number”)
Write a bit more complex program (for instance a chess or a tower defense I’m both not proud about)
Start a nice but not too hard-core project, let’s say a Game Boy emulator, how hard can it be?

Bonus

The Zig Software Foundation is a non-profit corporation (read: more resilience to entshitification).
The sources are under the permissive MIT license.
The core team switched to Codeberg over github
Strict no LLM policy (a really hard-core one, including translation)
The Zig Software Foundation supports FOSS projects they rely on (musl for instance)

$ zig zen

 * Communicate intent precisely.
 * Edge cases matter.
 * Favor reading code over writing code.
 * There is an idiomatic way to do it.
 * Runtime crashes are better than bugs.
 * Compile errors are better than runtime crashes.
 * Incremental improvements.
 * Avoid local maximums.
 * Reduce the amount one must remember.
 * Focus on logic, not style.
 * Resource allocation may fail.
 * Resource deallocation must succeed.

Together, we serve the users!

Notes

I like to troll (if possible Windows, but apparently there’s not too much left of it to troll), but I don’t really like flame wars.

If you absolutely want a A Vs B programming language topic, do not consider Rust Vs Zig but maybe more Rust Vs C++ and Zig Vs C.

Time to look for a job

Sun, 11 Oct 2026 20:00:00 +0000

The various reasons I’m fed up with my current situation

AI, “What a pleasant surprise!”

Let’s put this out of the way: I hate AI, for various reasons, but let’s focus on the job topic:

Takes the fun out of programming It’s a job, so, invalid argument
Ecological disaster I’m currently working in the consumer electronics industry, so, invalid argument too

The main issue in a working environment is to make it clear that a proof of concept is not a product. Taking shortcuts to test or demo something makes sense. AI is good at it and blazing fast.

I would be surprised if a Software company would have a strong no-AI policy, but “How many percents of your core product code is generated by LLMs?” is definitely on my questions list.

An analogy to trigger you: would you build a 3D renderer based on a demo of the demoscene?

Lessons learned

In every company and likely any project released or canceled ends in the same way:

After doing, a ton of things, including a lot of failures over years. At some point a full review is done. Its name is variable: call it “retrospective”, “review” or my favorite: “lessons learned”. Why my favorite you may ask?

Spoiler Alert

We never learn anything.
“Ah shit, here we go again.”

In the best case scenario, a few important mistakes are avoided. From the critical ones, nearly everything is repeated over time.

The classics from what I saw. In EVERY SINGLE FUCKING PROJECT I worked on in a professional environment:

There is no clear architecture or no architect on fairly large projects: Every team work in their area, despite being all the time in meeting no information is shared. You end up with double work, non compatible interfaces, breaking stuff you didn’t know existed.
Unrealistic plan from the beginning or sudden plan change: everybody wonders how unrealistic (or “Sporty” in management language) is the planing. If you think no one cares, remember you need to rush, and not only in the end.
Really debug only in the end.

On top of that, add normal mistakes you cannot easily prevent if you don’t know them and, the critical failures you make because you absolutely want to do something different way.

Build crap with gold

I work with some really talented people, but the project quality is so far below from what a normal human being would expect from these profiles… that’s something I cannot explain and that’s killing me.

I asked for fun from time to time who in my team would feel confident to release the current state of our repo as an open source project. We’re all ashamed of this quality.

Let’s troll a bit: consider the monsters working at Microsoft and look at the crappy Windows… what kind of dissonance is this?

Never fix, just workaround

Why don’t we just fix things when we can work around them faster? … And end up spending an absurd amount of time fixing stupid mistakes afterwards.

In the fantastic times of AI, this is a bigger problem than ever. Things are not compatible? Just vibe-code a wrapper. It works, why should you read the code? Someone complained that it stopped working? Re-ask your favorite agent, tokens are cheap (so far).

By experience, if you want to fix something working often, you have some options:

Don’t consider fixing it
Attempt to quickly fix it and abort
Write a ticket which will rot in the backlog:
You won’t fix it because it’s low priority, and the day it became a real problem you will notice it will take a tremendous effort to fix as so much stuff was added…
But the priority will change from “won’t do” to “blocker”.
Do “Guerilla Software” as a colleague named it: don’t tell your boss you’re doing it, just fix it properly, eventually over time.

Ok, so what now?

These main reasons lead me to believe it’s time, not to look for yet another job in yet another company, but to truly change things.

Let’s throw away decades of experience in software and start building buggies: ~400 kg, a ~75 HP electric motor, ~100 km autonomy: Something approaching the kind of cars we really need to go from A to B in a fun way.

No ok, I’m joking… Even if I’m pissed off with the car industry and if I would break down that’s probably what I’d try to do, that’s another topic.

Giving up on software is not an option for me: this is my main hobby. I can understand the argument “You’re paid for doing your job, so don’t give a shit about what you deliver”, but that’s not me.
By the way, let’s be honest, the overly comfortable situation some magical keyword on a CV add to your income is just insane.

The ideal working environment for me (likely not realistic to check everything, but I can use it as a reference… and depress later on, signing a contract).

Work in open source environment. Everything I do must be open source
I need to be sure of my stuff before pushing it. We properly review before we release something broken (oh, and the CI pipeline is reliable).
As a bonus, looking at the sources before signing up is possible.
Work for a non-profit foundation.
Hopefully less bullshit, nothing should be hidden
No vibe coding (using an LLM is fine if done responsibly, but if you need to maintain generated stuff you didn’t even read, maintain it without me).
Not a single Windows PC around (including sales, HRs, …).

Fun fact (ok, depressing fact)

As some project in a company where advertised as “Open Source”. What did I do being a new employee and discovering these projects?
Yes indeed, I searched for their repos from home! But guess what “Open Source” does not mean Open Source, it’s just internal open source.

If for some reason, you may consider it, you can find my redacted CV here. Feel free to contact me.

NixOS after a few days

Tue, 22 Sep 2026 22:00:00 +0000

Introduction

This is the follow-up of the article NixOS init

So, how does NixOS feel after a few days of usage?

The learning curve is a wall. Picture a deadly, cold wall loosing itself in the fog (picture it in your mind, leave Midjourney alone).

Passed the installation and minor-tweaking the default configuration, the following days are horrible, but let’s dive in the details of the journey before I forget them (it’s not like I could but still…).

Just trolling

The first days feel like the NixOS home page which greets your with a language you never saw, without syntax highlighting.

The NixOS home page

Okay, I have to admit: this is actually cool asciinema demonstrating some NixOS features a nice way.

The issues I faced as a beginner

The broken plan

The first plan looked like this:

Learn about Nix (the language)
Learn about nix (the package manager)
Learn about NixOS

Nix (the language)

The language is pretty straight forward (didn’t use a functional programming language for a too long time, but Nix is not overly complex):

Except a few tricks I needed to look up while reading some configuration code, the rest is readable. I’m definitely not a Nix expert, just have the level to read basic Nix code.

I likely invested a bit too much time in the language learning for a kickstart but definitely not a waste of time. Just to try NixOS, probably a grasp on attribute sets is enough ;)

Consider this analogy: learning shell scripting to edit your .bashrc This is definitely not wrong but maybe consider postponing.

nixpkgs (the package manager)

The manual is between really useful and a joke: probably exhaustive list of every available packages with scarce details.

But actually the packages configuration sources are readable.

NixOS

It’s just about editing the config, what could possibly go wrong?

So many questions

So, I had a rough idea how what is taking care of what, where are the clearly delimited boundaries. In theory…

One of the first question poping really fast while digging around: “Should I use Flakes?”

The main arguments for the flakes: “Everyone’s using flakes, use them!”… cool but try with arguments… and rabbit hole discovered!

Officially they’re instable, and their RFC is still on a branch which PR was declined, but indeed for new configuration you should use flakes.

Flakes:

Some background: I come from Debian which means “stability” to me. Yes it’s anoying that some packages are too old but I generally handle these ones without package manager (compiling from sources for intance, looking at you Emacs).

My flakes interpretation: Make the build reproducible, pinning every used package version in a flake.lock (which I .gitignored seeing this generated file fith this extension poping up btw…).

Oh btw, as you use flakes, use nix-command (still unsure why they always seem to come together and what other experimental stuff I should have a look at).

One of the next question is about nixos / nixpkg unstable. Both nixos-unstable and nixpkgs-unstable follow the master branch of the Nixpkgs repository, but if anyway everything’s pinned, if it works, it should be stable-ish right?

The most answers about picking any solution sound like “Hey, it’s your OS so it’s your call”

Main issue with the plan

I wanted to make everything correctly, from the beginning (sounds good? Was likely a mistake).

This implies bringing up flakes, trying to understand modules, and use home-manager while having no idea of NixOS.

Which means: instead of pasting some stuff accumulated over years in ~/.config I thought I would very soon use home manager so denied this intermediate step.

This also implies: No editor config, no bash aliases (okay, cracking down and adding aliases manually from time to time to the current bash instance or just prefering ssh) but you get the idea.

So to summarize the first few days: It’s horrible! But let’s see after a few weeks.

NixOS after these steps

So I learned the hard way to

Read the error messages, not using --show-trace without a good reason.
Use --dry-activate / --dry-build
It is much more user-friendly to read something like:
“would remove group ‘networkmanager’”
or
“would remove user my_only_user”
and pondering if a rebuild switch is still a good idea instead of wondering why the ssh connection dropped or why login directly or through ssh just doesn’t work anymore.
Actually, I have git hooks running nixos-rebuild with dry-build / dry-activate, just in case.
That said, a very good feature of NixOS is to forbid generating an OS without a user (I tested, yes root is still there).
File not found likely means “Hey, you forgot to git add”
“everything’s obvious, afterwards”.
According to me, enforcing a VCS is a good feature.
The sources of upstream packages are readable.
To be brutal, maybe more readable than the man page which just blindly list options for a package… which would be super cool… if you could easily install packages offline.

Config failure

This is still a recurrent issue for me.

Some packages are still commented out because they need to be built, … on every rebuild switch which I don’t understand.

Why are not every or none package are built, why some are? This is still an open question.

I was debugging my i3 config, while being logged in and was happy that everything finally worked (forgot the modifier key…). The day after I could not log in: LightDM reported: “Failed to start session”

This happened multiple times to me (I know, I’m the culprit): on the list of errors where you start to consider testing if roll-backing works:

error: executing “git”: No such file or directory

Note that git not needed by nix-env, so just start an environment with git.

As a side effect, I’m rebooting even more than a Windows user (ok not that much but still a few times a day to make sure the config did not break).

What stays to learn

… Everything I guess, but maybe urgently:

Having a look at the garbage collector: after a few weeks (85 builds), 141MB free over 1GB on /boot good to keep in mind…
nix-env nix-shell nix-daemon nix-your-grandmother
Out of curiosity: are python virtual environments or docker still a thing? I would have expect a sound “no” but the NixOS homepage has a section about “Minimal docker images”
As I’m thinking my configuration to work on multiple machines, cross-building would be interesting.
Find a way to search for a package using a cache (so in less than 30 seconds).
How to properly debug a configuration (of course not that I need this but…)

Special mention

The vimjoyer - “Learn Nix” course - Videos on youtube about specific features
Some friends which shared / explained their configs to me.

A RAID failure is no worries! Right? RIGHT?

Wed, 16 Sep 2026 19:00:00 +0000

Let’s have a peaceful evening

Note: Mainly for brevity, some commands / output were modified, but the essence was kept.

After noticing that a service from a server was no longer available, the journey started with a ls … which resulted in I/O errors.

$ ls test
ls: reading directory '/raid/': Input/output error

Investigating the root cause

$ cat /proc/mdstat
md0 : broken raid1 sdb[1](F) sda[0]

Yes, broken is the word you don’t want to read.

What does dmesg think about that?

...
[    4.113971] ata1.00: 2000409264 sectors, multi 1: LBA48 NCQ (depth 32), AA
[    4.112887] ata1.00: ATA-9: Verbatim Vi550 S3, W0704A0, max UDMA/133
...
[    4.607618] ata2.00: failed to IDENTIFY (INIT_DEV_PARAMS failed, err_mask=0x80)
...

Ok, so on the SATA but, only one disk says Hi.

It would be nice to fix the issue

In order to investigate further, let’s unmount the RAID:

$ sudo umount /dev/mapper/vg_raid-lv_data
umount: /raid: target is busy.

Let’s try to at least umount everything properly, stoping some services known to attempt to access the raid.

Ok still not umount-able, so lsof please help:

$ sudo lsof | grep /raid
lsof: no pwd entry for UID 999
lsof: WARNING: can't stat() tracefs file system /sys/kernel/debug/tracing

Plenty of errors (but only 2 categories).

On this server, the Root File System is not in the RAID array (read: it can properly boot without RAID), so in ~~despair~~ expert mode, I rebooted the server.

$> shutdown now

LUKS on top of RAID

$ > sudo cryptsetup luksOpen /dev/md0 crypt_raid
Device /dev/md0 does not exist or access denied.

… oh, ok let’s mount manually

There are (normally 2 disks; but here was only /dev/sda listed by lsblk so let’s use this one)

$ sudo mdadm --assemble --run /dev/md0 /dev/sda
mdadm: no recogniseable superblock on /dev/sda
mdadm: /dev/sda has no superblock - assembly aborted

ok, if the mirror RAID’s broken because of 1 disk failure, it’s quite interesting right?

Hey, come on, I already saw some I/O errors in the past, this is fine, let’s do a proper power-cycle, it will work. $> shutdown now Unplugged the power supply, waited ~2 minutes. … the issue persists, it’s not a Microslop product (not that they work after a power cycle either…)

Spoiler alert: this power-cycle is a big mistake for the post-mortem investigation.

$ lsblk -o NAME,VENDOR,MODEL
sda          ATA      Verbatim Vi550 S3
sdb          ATA      SD Ultra 3D 1TB
└─md0

$ sudo mdadm --examine /dev/sda
mdadm: No md superblock detected on /dev/sda.

ok, no /dev/sda

$ sudo mdadm --examine /dev/sdb
/dev/sdb:
...
     Raid level : raid1
...
    Data Offset : 264192 sectors
...

ok, so I started to be lost, but thought “hey, who care about RAID, we just need data, so let’s skip the header”. After getting mad at the offset needed by losetup, browsing the internet brought the guess: 512 bytes per sectors (of course). (I genuinely do not know where to get this information from actually…). So 265_192 * 512 = 135_266_304

$ > sudo losetup --find --show --read-only --offset 135266304 /dev/sda
/dev/loop0

$ sudo cryptsetup luksOpen /dev/loop0 crypt_raid

Oh, it works! And took only ~1.5 hours so far…

$ sudo mount /dev/mapper/crypt_raid /raid
mount: /raid: unknown filesystem type 'LVM2_member'.

… but I forgot about LVM

LVM on top of LUKS, on top of RAID.

$ sudo fsck /dev/mapper/vg_raid-lv_data
fsck.ext4: Input/output error while recovering journal of /dev/mapper/vg_raid-lv_data
fsck.ext4: unable to set superblock flags on /dev/mapper/vg_raid-lv_data

Noooo… oh wait, the losetup mount was done in read only, and as a bonus for the good news, I’ll spare you the vgchange -an / luksClose / re-losetup / re-luksOpen

and the mighty and dreaded fsck said: “clean”. Mhhhnn’k

# mount /dev/mapper/vg_raid-lv_data /raid

$ ls /raid
-- Works, just works :D

So now, as you can guess after the hassle it’s ~~bed~~ BACKUP time! I do make backups, but… they stay on this very RAID, I just scp / test them from time to time, … manually (I know…).

Just hotswap the disk, trivial

So, no data loss, everything’s cool, was an adventure through the evening, nice, everything’s ends well! Right? … Just a simple question: which disk is the culprit? I mean /dev/sda or sata1 are not that explicit to me. Why does a disk not report to the SATA bus… and the other one has a broken header?

I left some hints here and there which you may have noticed: The RAID is composed of 2 disks.

One from Verbatim
One from SanDisk (“SD” as VENDOR in lsblk output)

Please note that I’m not sponsored nor want to bash a manufacturer, it’s just easier to name a disk by its manufacturer than UUID for instance.

Confusing output

Initial boot: md0 : broken raid1 sdb[1](F) sda[0]

$ lsblk -o NAME,VENDOR,MODEL /dev/sdb
NAME                  VENDOR   MODEL
sdb                   ATA      SD Ultra 3D 1TB
└─md0
  └─crypt_raid
    └─vg_raid-lv_data

The SanDisk is the culprit, easy! And, after the first power cycle (shutdown -r now), only the Verbatim is on the SATA bus (mapped as /dev/sda)

$ > dmesg
[    4.112887] ata1.00: ATA-9: Verbatim Vi550 S3, W0704A0, max UDMA/133
...
[    4.183576] sd 0:0:0:0: [sda] Attached SCSI disk
[    4.602340] ata2: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
[    4.607618] ata2.00: failed to IDENTIFY (INIT_DEV_PARAMS failed, err_mask=0x80)

And now comes the second power cycle (shutdown + no power supply for about two minutes) into play.

$ > cat /proc/mdstat
Personalities : [raid0] [raid1] [raid4] [raid5] [raid6] [raid10] 
md0 : inactive sdb[1](S)
      976630488 blocks super 1.2

$ > sudo mdadm --examine /dev/sda
mdadm: No md superblock detected on /dev/sda.

$ > lsblk -o NAME,VENDOR,MODEL
sda          ATA      Verbatim Vi550 S3
sdb          ATA      SD Ultra 3D 1TB
└─md0

It confirms everything: the SanDisk is dead as /de… oh no wait this time, the Verbatim is not in the RAID array, but the SanDisk is.

A day after the party, re-reading the logs confirmed what I first thought: I don’t understand what’s going on.

Why is one disk not reporting on the bus?
Why does one disk have sudden Software issues (header broken) at the same time?
Why does this seem random?
Could it be that the issue lays one level deeper (motherboard)?
~~Could it be that~~ I understand nothing

And some side quests pops up:

Should I switch to HDDs? (these two SSDs are about 3 years old, nearly never under heavy load)
Is ext4 a good idea?
Should a disk be “mostly write”?

As you can see, this is still under investigation, but I wanted to re-read logs carefully, avoid guessing on what I did and now, I have a documentation of what happened / was done.

So, see you hopefully in a later blog post with answers.

NixOS installation

Sun, 06 Sep 2026 19:00:00 +0000

Installation

For a long time I wanted to give NixOS a try. I finally got into it.

So, the first step are just like a normal distribution: dd an iso on a USB stick and you’re good to go. (yes, you can boot over network too to flex around; that’s on my list).

As I’m lazy, I took the graphical installation. Then, as an expert, I clicked next > next > next > reboot.

Packages installation

The main config file seems usable, the comments provide a fair quick reference.

This pointed me right to the keyboard layout -> I can type instead of looking at my keyboard… which has no printed keys.

The packages installation is really clean in my opinion: just list what to install. I find this way neat as you instantly see which packages you installed.

I know, package managers can list installed packages (we can depress together if you’re using a Debian based distribution: apt list --installed reports more than 3k installed packages on my system).

The point of having a list screaming at you is to ponder if you need the bloat you’re not using while scrolling it. (I’m a maniac keeping this kind of lists alphabetically sorted if you wondered).

That said, let’s add i3 for me to not jump through the window (pun intended) attempting to use a mouse. And the moment of truth: sudo nixos-rebuild switch Works as promised, nice!

Let’s then add ghostty (always wanted to really give this terminal emulator a shot). Now I’m no longer dying from xterm with black on nuclear blast light. So, a paranoiac rebuild + power cycle, to see that everything works as expected (to be fair, we’re talking about the package manager of the OS, no big wonder it just works).

With the emergency topics off the way, I can use my brain to think about packages, no longer about brightness. So, I added a bunch of packages (something between the lines: nvim, emacs, zig, gcc), rebuild… forever …

With the CPU going 100% (guessed from the fan noise at least). Untils boom! The terminal just closed. Wondering about the stability of ghostty (I needed a culprit), I retried, same issue.

After some trivial monitoring during the build, the CPU went indeed berserk, and the RAM went low, dangerously low. On terminal crash, checking the system logs, journalctl happily repported the Out Of Memory Killer kicked in…

Searching around in the man to discover that --cores --max-jobs --show-trace may be useful with sound values. … Until after a few Out Of Memory issues I though (“hey, come on in 2026, mutli-core is a far too new fancy technology so, let’s use 1 core and 1 job”). Taking forever, while the RAM usage continued to raise I searched for another solution and, good news, it’s a known issue, no worries… just need a swap.

Dooming myself for not having thinking during the installation, I then saw the swap is actually a file (nice!). Ok, so with a swap, everything’s building fine \o/

But why is anything being built in the first place? I mean, it is really good to have the option to build from sources, but often your package manager defaults to build from sources XOr download, so ok, Nix does both… but depending on what.

Sorry I don’t know yet why, but it’s really triggering me, so I’ll need to investigate xD

Summary of the first steps

I took a few good decisions (yes, this happens sometimes). Concretely:

Initialize a git repo in /etc/nixos/ (I really wondered for a while if it’s the proper NixOS way, but I think it’s much better than nothing) Do this! (and do this as soon as possible; in my case the first commit a bit late: keyboard config, survival packages are already there)
Add ONE package at a time, commit often. Adding nvim did not trigger a deadly compilation; adding emacs did. (Maybe I should not add an OS in an OS next time).

Next steps

The installation opened a scarry number of rabbit holes (flakes? overlays? Nix? Normal user? Home manager? What is nixos-rebuild doing and why? …?).

A lot of topics remains, for instance I want to configure some packages, let’s say a trivial .bashrc I feel this should not be done through a classic scp another_machine:.bashrc . So I’ll need to find the Nix way, but that will be for another post.

How do editors handle directory creation on save

Thu, 27 Aug 2026 20:00:00 +0000

Introduction

NOTE

Unless a post is about vscode or eclipse, no editor flame war is intended.

To keep the comparison fair, only the defaults of the editors are used… which often show that any editor will have at some point interesting default behaviors…

Emacs

Emacs is started as emacs --no-init-file ... (aka emacs -q)

Editing a file which path traverse non exiting directories triggers a warning:

Use M-x make-directory RET RET to create the directory and its parents

On save attempt, you’re explicitly asked:

Directory ‘/tmp/lol/’ does not exist; create? (y or n)

vi(m)

Considering vi and vim, not nvim here. Starting vi / vim with --clean

“/tmp/lol/hello” [New DIRECTORY]

So yes, vim, just like, vi displays a warning.

On save, oh boy… you’re on your own and I needed to search for the way to create directories.

“/tmp/lol/hello” E212: Can’t open file for writing Press ENTER or type command to continue

The no-config remember-able solution I can come up with is calling a shell command:

:!mkdir -p %:h

nvim

Interestingly enough, nvim shows nothing interesting in the status line opening a file behind a non-existing path.

On save, save error message shown as in vi(m) but a cleaner solution is available.

:w ++p

Helix

Nothing shown opening a file behind a non-existing path.

On save:

can’t save file, parent directory does not exist (use w! to create it)

from the :w! pop-up help message: “Force write changes to disk creating necessary subdirectories.”

Conclusion

Yes these editors are configurable but still, the default behavior of vi / vim / nvim is horrible, just telling you: “you’re doomed” and you realisticaly end up with Ctrl-z to your shell and running mkdir because there’s just nothing to remember.

In my opinion, there is no clear winner here. Helix has the best defaults: it’s not proposing you to create directories for you like Emacs does, it teaches you how to do it.

That said lacking a useful warning right after starting your editor telling you that the file you’re editing is not empty but lays behind non-existing directories is really useful.

Use case: copy-paste a path to a file from a failing service and not pondering why nothing was logged as the file appears empty, but knowing that the directory does not exist, so maybe the service did not start at all… (btw, a silent-ish warning is the best according to me: you don’t have to acknowledge anything, you can type right away if you want to create a file; if not, the warning will trigger you).

Keyboard layouts

Wed, 19 Aug 2026 19:00:00 +0000

A long time ago, I wanted to write a blog (cough cough) and the topic I had in mind at that time was about keyboard layouts (I didn’t even know about custom keyboards, lucky me).

So, some background: I picked up programming relatively late, using the layout coming out of the box on my country (where you need a combo using Alt-Gr to insert brackets or braces just to pick an example).

… Just giving you some time to locate the Alt-Gr key on your keyboard (or remind you that you may need it on your fancy custom layout) …

Shortly after, I joined the university, where I switched to a qwerty layout, not to be cool but only because the keyboards we had there where qwerty labeled and… I was not able to touch type (it’s a skill I tried to pick up in panic days before the university thinking everyone would be able to, but had just broken basics, and anyway surounded by many people in the same situation).

Fun fact, when possible, I tried to pick up one of the very few non-qwerty labeled keyboards in the university, because nearly every single keyboard had broken feet but non-qwerty keyboards where deserted so, with feet, always. As touch typing slowly became a thing, this was really nice.

A failure I made and still can’t properly fix it: I remapped the backspace key on the capslock, easily reachable… allowing much more typos. I unfortunately still have a far too reachable capslock.

Later on, after years of programming for a living, it pissed me off to not be able to cleanly touch type, and as some colleagues transited to dvorak or colemark, I was motivated to follow but wondered what would be the state of the art layout.

Not-so-quick tries and errors and extensive search lead me to the holly workman layout (Wayback machine link)

The workman layout from OJ Bucao

OJ Bucao, its creator holds a long and understandable description why where other layouts not that practical and overall, he measured not the travel distance of your fingers to reach a random key, but the cost of reaching keys to make digraphs (compare extending your index Vs your pinky for instance and typing ‘th’ Vs typing ‘ue’: which bigram is more useful in english; On this post draft: 1 match for ‘ue’ but 29 matches for ‘th’).

This layout came with bonuses:

Nearly no cheating possibility. You need to touch type (it still breaks my brain to have a look at keyboard labels while typing).
The slight strain I had in my wrists calmed down for a while.

WARNING

Do seek professional medical advice, do not read a blog for medical issues.

To be fair, the workman layout comes with some drawbacks:

Your editor bindings / muscle memory are off.
The Ctrl-c / Ctrl-v mainstream shortcuts are off-by-one.
Using this layout makes you an alien in random companies (if you already experienced being the only non Windows user in a whole department, this is worse).
Gaming is painful as you need to remap everything… if you’re using a normal keyboard.

In general, learning a layout is hard. If the layout is really good, it’s definitely worth it, even if you’re only writing AI prompts ;)

Fun facts

Learning the workman programmer variant is still on my list
(and writing this article re-motivates me to attempt a transition).

I contaminated one person so far with the holly workman layout, will you be the next one?

Writing this blog post was my oldest ticket.

First Post: zine init

Wed, 12 Aug 2026 20:30:00 +0000

Reboot of a writing space

I didn’t write anything in the last years and was never able to keep a correct writing rhythm. The main reasons are:

Motivation: Let’s face it: this is still a major issue, but if I don’t start now, I’ll delay forever and regret it (actually, I really hope I’ll be able to populate this site, sharing my small knowledge)
Fatalism: “Why should I write something about X, if anyway you can ask a LLM about X and likely get a better answer?” => I don’t care anymore

Against fatalism

As more and more of the Software I see tend to take a weird direction, I admit that Zig, mostly, is my light in the dark: the philosophy of Zig in my words: You don’t have to stick with bad designs, nothing’s impossible, undoable.

“We are the ones making computers do what they do” Andrew Kelly - Don’t take the Black Pill - talk given at the Software Should Work 2026 (at this timestamp)

“Owning your content means that you will be unaffected by enshitification of platforms that would otherwise keep your data hostage. It also is the single most effective thing you can do as an individual to take power away from platforms, all while protecting your own immediate interests.” - Loris Cro - Zine example

Why, the fuck, Zine?

I like the idea of static website (just focus on the content).

As a Zig fan I soon enough discovered Zine, but didn’t give it a shot, as:

org-mode in Emacs worked okay-ish for me
I found it really overkill to have like Super MD + Super HTML + Zig… for a static website (compared to Hugo for instance), like what, you need to come up with your own languages, come on

So, what changed my mind?

After more than 10 years (oh boy…) of using Emacs, I switched to VS Co… NOPE, nice try, I switched to Neovim this means that I respect both editors, and overall, can troll both (and by the way if we could stop this weird war and trash together vscode and its funny ecosystem, it would be great…) so… even if vim org-mode is a thing, the full automation I had in Emacs was not matching the level of automation I like in nvim.
Actually Super HTML really has an edge with validation: HTML is really permissive (maybe a bit too much, but for a browser whatever happens the show must go on, can’t just abort displaying a page).
The benefit of SuperHTML is validation; SuperMD is merely an implementation detail while fixing markdown issues
Zine just works and comes out of the box with this nice zig build --watch like feature I’m so used to.

WARNING

I only a few hours of practical “experience” with Zine.

In summary:

maintainable templates
no tool specific magic

So far, it works for me. It’s up to you to find the best solution for you.

NULCODE

RockPro64 LEDs

Disclaimer

The hardware world

Finding documentation

RTFM

GPIO Group 1

GPIO lines 1 and 4

Let’s write

Direction: Output

Value

Bonus stages

Play with a GPIO under Linux

Permanent U-Boot config (under Armbian)

Loud ugliness (under Linux)

NixOS re-re-re-build

Slowly filling up /boot

Someone on this blog wrote about NixOS:

Garbage collecting

Notes

Let's try something new! Rust?

Picking up a new programming language

Zig philosophy

Everything’s monolithic.

Killer features

Incremental compilation

Optimization

Simplicity

The best of all worlds

Drawbacks of Zig

Evolving fast

Documentation

The language can feel too simple.

Let’s try it

Bonus

Notes

Time to look for a job

The various reasons I’m fed up with my current situation

AI, “What a pleasant surprise!”

Lessons learned

Spoiler Alert

Build crap with gold

Never fix, just workaround

Ok, so what now?

Fun fact (ok, depressing fact)

NixOS after a few days

Introduction

Just trolling

The issues I faced as a beginner

The broken plan

Nix (the language)

nixpkgs (the package manager)

NixOS

So many questions

Main issue with the plan

NixOS after these steps

Config failure

What stays to learn

Special mention

A RAID failure is no worries! Right? RIGHT?

Let’s have a peaceful evening

Investigating the root cause

It would be nice to fix the issue

LUKS on top of RAID

LVM on top of LUKS, on top of RAID.

Just hotswap the disk, trivial

Confusing output

NixOS installation

Installation

Packages installation

Summary of the first steps

Next steps

How do editors handle directory creation on save

Introduction

NOTE

Emacs

vi(m)

nvim

Helix

Conclusion

Slowly filling up `/boot`