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.

Written in the early 2000s, “The West Divided” is a collection of interviews, newspaper articles and an essay by Habermas about post-9/11 international politics and the different approaches taken by the US through the Bush administration and the EU, through a philosophical lens.

The structure of the book helps the reader, by starting with transcripts from interviews and articles, which use a more direct language and establish some concepts explained by Habermas to the interviewers, and then proceeding with a more formal academic work in the form of the essay of the last part, which is a more difficult read. Habermas discusses the idealist and realist schools of international relations, aligning the idealist school with Kant’s project and the evolution of the EU, and opposing it to the realist school proposed by authors such as Carl Schmitt, a leading scholar from Nazi Germany. Habermas proposes a future of the Kantian project which lies in the ultimate development of cosmopolitan (i.e. worldwide) juridical institutions, such that cosmopolitan law gives rights directly to (all) people, rather than as a layer of inter-national law between states.

It was especially timely to read this book in the wake of the Russian invasion of Ukraine in February 2022, and to have this theoretical background at hand when watching John Mearsheimer’s talk from 2015 on “Why Ukraine is the West’s Fault”. Mearsheimer, an American professor in the University of Chicago and himself a noted realist, gives an excellent talk and makes a very important point that in international conflict one needs to understand how the other side thinks — instead of “idealist” vs. “realist” (which are clearly loaded terms) he used himself the terms “19th century people” to refer to himself, Putin, and the Chinese leadership, as opposed to “21st century people” to refer to the leaders in the EU and in Washington.

It is interesting to see Mearsheimer put the European and American governments in the same bucket, when Habermas’s book very much deals with the opposition of their views, down to the book’s very title. Habermas wrote “The West Divided” during the Bush administration, and the Mearsheimer talk was given during the Obama years, but he stated he saw no difference between Democrats and Republicans in this regard. Indeed, in what concerns international law, what we’ve seen from Obama wasn’t that different from what we saw before or afterwards — perhaps different in rhetoric, but not so much in actions, as he broke his promise of shutting down Guantanamo and continued the policy of foreign interventions.

As much as Mearsheimer’s analysis is useful to understand Putin, Habermas’s debate that there are different ways to see a future beyond endless Schmittian regional conflicts is still a valid one. And we get a feeling that all is not lost whenever we see that there are still leaders looking to build a future of cosmopolitan cooperation more in line with Kant’s ideals. Martin Kimani, the Kenyan envoy to the UN said this regarding the Russian invasion of Ukraine:

This situation echoes our history. Kenya and almost every African country was birthed by the ending of empire. Our borders were not of our own drawing. They were drawn in the distant colonial metropoles of London, Paris, and Lisbon, with no regard for the ancient nations that they cleaved apart.

Today, across the border of every single African country, live our countrymen with whom we share deep historical, cultural, and linguistic bonds. At independence, had we chosen to pursue states on the basis of ethnic, racial, or religious homogeneity, we would still be waging bloody wars these many decades later.

Instead, we agreed that we would settle for the borders that we inherited, but we would still pursue continental political, economic, and legal integration. Rather than form nations that looked ever backwards into history with a dangerous nostalgia, we chose to look forward to a greatness none of our many nations and peoples had ever known. We chose to follow the rules of the Organisation of African Unity and the United Nations charter, not because our borders satisfied us, but because we wanted something greater, forged in peace.

We believe that all states formed from empires that have collapsed or retreated have many peoples in them yearning for integration with peoples in neighboring states. This is normal and understandable. After all, who does not want to be joined to their brethren and to make common purpose with them? However, Kenya rejects such a yearning from being pursued by force. We must complete our recovery from the embers of dead empires in a way that does not plunge us back into new forms of domination and oppression.

Words to build a new future by.