And here’s our regular reminder that “Western Civilization” is a colonialist concept.

Whenever you hear that term used, ask yourself: who are people specifically wanting to exclude when they prefix “civilization” with “Western”?

For any non-racist definition of “civilized”, people are civilized in every country of the world; East and West, North and South. The idea that there’s some other chunk of the world “which doesn’t share our values” is us-and-them propaganda.

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.

Earlier today, Ludovic Courtès asked these questions on Mastodon:

Are npm/crates.io just a different approach to distributing software, compared to Linux distros?

Or is there something more fundamental about their approach, how it affects user/developer relations, and how if affects user autonomy?

My take on these questions is that to me there are two fundamental differences:

1) npm/crates.io/LuaRocks (language package managers) are package managers for programmers. They ship primarily modules/libraries; apt/rpm/etc (system package managers) are package managers for end-users. I don’t expect a non-programmer to ever use cargo but I expect a Ubuntu user to use apt (even if via a GUI).

2) language package managers cut the “middleman” and allow module/library devs to make them available to other devs right away, without someone like a Debian developer having to deem them relevant/ready enough for packaging.

The fact that there is no curation is a feature for language package managers, just like the fact that there is curation is a feature for system package managers.

The reason why system package managers are curated is for end-user protection. The reason why language package managers are not curated is to provide developer autonomy. There is a wide gradient between these two things.

If as a developer you put too many hurdles between me and the library I want to use in the name of “protecting” me, I’m gonna skip your package manager and just fetch my dependencies from the upstream source.

For end-users just trying to keep their browser up-to-date, I understand the story is completely different.

There are other practical reasons why developers use language-specific package managers, of course. One of them is dealing with dependency versioning. By having per-project trees (think of node_modules in npm), each project can define their own dependency versions, regardless of what is available system-wide (if it is available at all). This is something that happens in practice, but that is not necessarily a fundamental design difference between language and system manager. In our 2019 paper we discussed alternatives, but the approaches we suggested there are not the general state of the world today.

An aside: when talking about projects adopting or not certain package managers, one needs to keep an eye for the motivations. I’ve seen questionable arguments from companies keeping packages away from community repos (for example, to retain control over download metrics). But in my experience, I’ve only ever seen this happening to system package managers, but never to language package managers, which just seem to reiterate how different these two universes are.

In an ideal world, system package managers and language package managers would be able to cross-reference each other to avoid the duplication of packaging work we see everywhere. This is something we talked about in the paper linked above. In fact, I’ve been trying to preach the gospel of cross-language links across ecosystems since at least… *checks git, or rather, cvs history*… 2003.

I’m as sympathetic to the ideal as they come, but the reality is that we need to deal with these two universes for now (…for a significant definition of “now”).

Amidst the lively debate in Mastodon, my friend Julio brought up the elephant in the room:

(puts Diogenes beard):
“Docker.”

…to which I can only nod my head in agreement and say: the success of Docker is the developer world’s tacit acknowledgement that package management has failed.

(For anyone else reading this tongue-in-cheek comment without further context: I have authored two package managers, both in the language side and distro side of the game. If that remark feels excessive, just s/has failed/is hard/, but my point still stands.)

Don’t get me wrong, package management has evolved greatly over the years, but as a community we’re still understanding it. There are two very different things that are both called package managers, and they serve different purposes. Another world is possible, but it will take a lot of gradual change, and “if only everyone would adopt my package manager where everything works” is not a solution (that applies to people living inside the bubble of their own language ecosystem as well!). Age has turned me from a revolutionary into a reformist.

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.

Writing this review in English due to the international appeal of this book, even though it was printed in Portuguese.

This book collects a series of interviews of French psychoanalyst Felix Guattari conducted by Japanese artist and researcher Tetsuo Kogawa.

“Tetsuo is a really very influential figure in underground radio art and media-art theory, with over 30 years of collaboration and connection with some of the most influential artists and thinkers of that period, worldwide (He’s published over 30 books, had a series of interviews with Felix Guttari, has known and collaborated with pioneers of experimental music in Japan from the 50’s on (big guns like Yasanao Tone and Takehisa Kosugi and so on…)).

He’s perhaps best known internationally as the founding father of the micro-fm boom in Japan in the 80’s. Inspired by the Marxist ‘Autonomia’ movement and their pirate radio stations in 1970’s Italy, Kogawa set up Radio Home Run as a resistance to the commodification of subculture; theorising, practically enabeling and kick starting a Japanese boom which saw thousands of tiny radio stations set up and run, by and for communities across the country. They became a space for polymorphous chaos, a kind of chaos found through difference and ‘order through fluctuations’.”

– Arika on Tetsuo Kogawa

This book collects those interviews and add texts by Guattari, Kogawa, and the Brazilian organizers, who were in direct contact with Kogawa while working on this collection.

I found the discussion of the various movements of free/pirate radio in the late 70s and early 80s especially interesting: Autonomia in Italy, free radio in France and mini-FMs in Japan. The parallels with the rise of the free software movements were apparent to me, and in fact, the timelines match (the GNU Manifesto dates from 1983) and in more recent writings Kogawa and the organizers do allude to free software. It was a stark realization to me to finally notice how the lore of the free software movement was (and to the extent that it still exists, still is) propagated entirely in a vacuum, without any real context of the surrounding free culture movements of the time. Seeing Guattari and Kogawa discuss the free radio movements, and their similarities and differences in each country, it is clear to me now how the free software movement was a product of its time — both its genesis in the US in the early 80s and its later boom in Latin America in the early 2000s, with the main event, FISL, happening in Porto Alegre, the same city that hosted the first editions of the World Social Forum featuring the likes of Noam Chomsky, Lula and José Saramago.

Another interesting observation comes from Guattari discussing how the free radio movement in France was a way for the various regions (and their languages!) to break away from “parisian imperialism” — having lived in different parts of Brazil, I have personally observed these phenomena of domestic cultural imperialism for a long time, and how they present themselves, by design, as being mostly invisible.

Kogawa’s more recent discussion of “social autism” relating to media is also insightful: he discussed the collective catharsis of the mini-FM movement as a therapeutic way to break away from the social autism of mass media by scaling it down, and how the ultra downscaling to the individual scale of personal smartphones has led to another kind of social autism, more lethargic and legitimized on a global scale.

Finally, it was impressive to see Guattari discuss back in 1980 how micropolitics — in the form of what we today understand as identity politics, for example — had the potential to produce large-scale political change. Time and again I marvel at how philosophers look at the world with a clarity that makes it seem like they’re reading the future decades in advance. I got the same feeling from reading Bauman.