This could be a long blog post, but I’ll try to make it a short one, basically expanding on a GitHub comment I just posted.

Recently, Mike Pall deleted some tags for old LuaJIT versions from his upstream GitHub repo. That is a pretty nuclear option for forcing people to upgrade, and in normal circumstances it would be seen as a very, err, unfriendly move in any FOSS situation.

But I can see the frustration he’s probably coming from. I know there are tons of projects out there stuck in tags like `luajit-2.1.0-beta3` for ages. He’s most likely getting bug reports for bugs fixed over ten years ago. I know because it’s the same in the LuaRocks world, where we keep getting bug reports for LuaRocks 2.0.8 from 2012 because distros haven’t updated them. I’ve also been on the other side and I know how taxing it is for distro maintainers, so I’m not pointing fingers. I’m just saying that maintenance and getting people to update is hard.

This is, however, an especially difficult problem in the Lua community.

Ever since the Lua/LuaJIT split around 5.2 (gosh, that was… 15 years ago!?), the community has gotten in this paralyzing tendency of supporting old versions forever, even when upstream doesn’t support them anymore. People making Lua libraries keep testing their packages against Lua 5.1, 5.2, 5.3, 5.4 and now 5.5; then LuaJIT 2.1, sometimes the OpenResty variant as well, and now 3.0.

I understand that Lua is an embeddable language and if you make a decision in a point in time to bundle, say Lua 5.2 in your app and you build a plugin ecosystem around it, then you’re married to it forever. But then that’s your app’s ecosystem to take care.

For Lua as an extensible language (that is, an interpreter + libraries), the story should be different, and it should be more like any other dynamic/scripting language out there. We should really be (gradually?) moving into supporting only the latest PUC-Rio Lua and the latest LuaJIT, at best.

I know why we ended up where we are. I know the history because I was there: with the Lua/LuaJIT schism, people wanted to support both environments, and targeting 5.1 was a good way to support both. And then 5.2, 5.3, etc. came along and people wanted to keep supporting the latest PUC-Rio Lua, but still felt tied to the 5.1 anchor. I’m sure I’m partly to blame for this because I engaged in this and helped others, by maintaining compat-5.3, itself an evolution of compat-5.2, with a history tracing all the way back to compat-5.0, which predates my involvement with Lua… and then we’re talking over 20 years ago.

My small contribution to try to undo this, nowadays, is Teal, a language that aims to be to Lua what TypeScript is to JavaScript: it not only aims to bring types to the language, but it also aims to bridge the version gaps. You can write Teal once, and then generate Lua with –gen-target=5.1 all the way to –gen-target=5.5. Hopefully this will help untie writers of Lua code from the Lua 5.1 anchor.

But even if you’re not using Teal, and you’re a Lua library author, consider doing what Roberto and Mike are doing: they do EOL their language versions. LuaJIT 1.0 is EOL, LuaJIT 2.0.0 is EOL (there’s a 2.0 bugfix branch, but the old tarballs are EOL), and all PUC-Rio Lua versions up to 5.3 are EOL (”There will be no further releases of Lua 5.3.” — note that as of August 2026, this is not said of Lua 5.4; there’s usually one last release a while after the next major Lua 5.x comes out).

If Roberto and Mike are EOLing the interpreters, maybe we should be doing the same for the libraries. If people really want to be using very very old versions of Lua, they should be using very very old versions of the supporting ecosystem as well, and not forcing maintainers into supporting 20+ years of legacy at all times.

There’s software that Just Works, and then there’s Frustrating Software.

htop Just Works. LuaRocks is Frustrating Software. I wrote them both.

As a user and an author of Frustrating Software, there’s a very particular brand of frustration caused by its awkward workflows.

I recognize it as a user myself when using software by others, and unfortunately I recognize it in my users when they fail to use my software. I know the answer in both cases is “well, the workflow is awkward because reasons”. There’s always reasons, they’re always complicated.

I wonder if I would know that were I not a developer myself.

Well-intentioned awkward free software still beats slick ill-intentioned proprietary software any day of the week. Both cause frustration, but the nature of the frustration is so, so different. The latter pretends it Just Works, and the frustration is injected for nefarious reasons. The frustration in the former is an accidental emergent behavior. I feel empathy to that, but it’s no less frustrating.

I wonder if non-developer end-users feel the difference, or if the end result is just the same: “this doesn’t work”. I’ve seen people not realizing they were being manipulated by slick ill-intentioned software. I’ve seen people dismissing awkward well-intentioned software outright with “this is broken”.

If users were looking at a person performing a task in front of them (say, an office clerk) rather than a piece of code, everyone would be able to tell the difference instantly.

In the end, all we can do as authors of well-intentioned free software is to be aware when we ended up building Frustrating Software.

Don’t be mad at users when they don’t “get it” that it’s “because reasons”.

Don’t embrace the awkwardness retroactively as a design decision; just because it can explained and “that’s how it is” it doesn’t mean that “that’s how it should be” (and definitely don’t turn it into a “badge of honor” to tell apart the “initiated”).

Once we step back after the defensive kneejerk reaction when our work is criticized, it is not that hard to tell apart someone just trolling from genuine frustration from someone who really tried and failed to use our software. Instead of trying to explain their frustration away to those people, take that as valuable design feedback into trying to improve your project into something that Just Works.

As for me? LuaRocks has a long way to go (because reasons!), but we’ll get there.

Today is my last day at Kong!

Posts like this tend to be cliché, with the usual adjectives and thank-yous. I’ve already thanked many people in person (err, Zoom!) already, so I thought I’d take this opportunity instead to celebrate all we’ve achieved together.

I feel very proud to have had the chance to work on an open-source project of this scale. The stories we’ve heard through the years really bring home the positive impact these lines of code we wrote together have had on literally billions of people.

So I look back at those commit graphs, and they tell the story not only of lines of code, but of all of the teamwork that went into getting them out there.

I look at these graphs and I see the earliest days in 2017 joining our newly-formed Core Team fronted by Thibault Charbonnier, taking over from the two-man-show that was him and Marco Palladino (who’s still ahead of me in the contributions ranking! — though I’m happy we’re both now overtaken by Aapo Talvensaari!). I see Kong going 1.0, then me taking the mantle as the team’s tech lead driving Kong to 2.0 and beyond, doing whatever was needed to try and help the project forward (even PM at times!). I see my 2021 sabbatical and I see Guanlan Dai bringing me back to take on a new project.

I look at these graphs and I see myself once again working alongside Thibault, this time in the WasmX team, helping him and Caio Casimiro make WebAssembly support in Kong a reality. Finally, I see the time I’ve put in design (which does not show in the commit graphs!) and implementation (which does!) for my final project at the company, DataKit, which is just coming out now. In short, I look at these graphs and I see Kong’s past, present and future!

Commits and lines of code barely begin to tell the story, though. In one of my very earliest days, my first manager at the company, Geoff Townsend, asked me what was my main motivation driver: the “what”, the “why”, the “how” or the “who”. I’m always amused when I remember his surprised reaction when I immediately said: the “who”. I’m a team player first and foremost, and there’s no way I could properly give shout-outs to everyone, but there’s been great people around me every step of the way, from the very first incarnation of the Core Team led by Geoff (Thibault, Aapo, Enrique García Cota, Thijs Schreijer) to the most recent incarnation of the WasmX team led by Robert Serafini (Thibault, Caio + Michael Martin, Vinicius Mignot, Brent Yarger). By shouting out my first and last engineering teams, I hope they represent all Kongers past and present who I’ve ever crossed paths with, and through them I thank you all!

Since I ended up doing thank-yous, I guess I’ll have to do the adjectives too! Kong was a fun, challenging and fulfilling adventure, and I leave feeling accomplished. A new challenge awaits me, so in the wise words of Dave Grohl, “done! and on to the next one!” 🤘

I had to clone the NetworkManager repo and grep my way through the source code to figure out how to do it, but here’s how to change the background color of nmtui from the default pink to a more subdued blue background:

NEWT_COLORS=’window=blue’ nmtui

As usual, add a line like `export NEWT_COLORS=’window=blue’` to your `~/.profile` file to make this setting automatic in future terminal sessions.

Apparently you can set lots of color settings with that variable

Confession time: once I *almost* added a terminal version of Tetris as an Easter egg in htop.

I managed to implement a real crude but working version of it code golfing to make it as short as possible and got it pretty tiny, then added it to the help screen so it would activate by typing h, t, o, p (since h would take you to the help screen and the other keys would be nops in that screen).

Then there’s the question of how to hide an Easter egg in a FOSS codebase… The best I could think of was to make it into a long one-liner starting at column 200 so that most people looking at the code without word-wrapping editors would miss it. But after everything was coded, I decided that trying to “sneak code in”, even in my own codebase, was a bad practice and the good intention of innocent fun wasn’t worth it.

My fascination with Tetris goes way back. I first implemented it when I was in high school, and it getting it done really gave me pause: that was a real program, something that people paid real money for in Nintendo cartridges. It was the first time I thought I could really call myself a programmer for real. At the same time, it was my first contact with the ethics of software. I had never heard of FOSS then, and yet I asked myself: “what if my friends ask for the source code? what should I do?”

Years later, when we did the first CD version for our GoboLinux distro, I took an existing ncurses version of Tetris and hacked it into our installer, adding a progress bar that showed the status of files copying from CD to disk, while the user played the game (distro installers took forever back then!). Everyone loved it–except for the fact that it was supposed to auto-quit when the installation was finished but we changed the list of packages last minute so it got the count wrong.

A lot of people just kept playing for a long time without realizing the installation was done! (But it wasn’t too bad, they could just press Esc or something to quit and finish the install.)

Our early Gobo releases were full of little fun tweaks like that. In one release we included an emulator and legend has it that some hidden folder contains a ROM (not Tetris!), but not even I remember where that is, and that ISO probably isn’t even online anymore. (We really should have preserved our old stuff better!)

The memory of the Tetris installer in Gobo having a last-minute bug was another thing that dispelled me from the idea of the Tetris Easter egg in htop: while having bugs is just normal, I couldn’t bear the thought of htop having some serious bug caused by code added for silly reasons…

htop has its fair share of “unnecessary code”, such as the “big-digit LCD” meter and the themes, which are more artsy than utilitarian and I stand by them. If anything, I think software in general should be more artsy.

But “hidden Tetris in htop causes buffer overflow” would be terrible PR for the project (and my reputation by extension, I guess). That along with the bad taste in the mouth of the idea of hiding code in FOSS left made me drop the Easter egg idea.

I wish I still had that code, though! If only to keep it to myself as an autobiographical side-note.

Come to think of it, after writing all of this I realize I probably _should_ have included that code… as a comment!! Maybe that’s the way to do Easter eggs in FOSS? Add a fun/silly feature but leave it commented out, so that someone tinkering with the code finds it, enables it and has fun with it for a bit. I know that *I* would have enjoyed finding something like that in a codebase.

Oh well, maybe someday I’ll pull this off in some project.