DreamHost finally bugged me to upgrade FlatPress from my super-old version running PHP 7 to the latest one running PHP 8.1. Making a tiny blog post just to test it — hope this works!

You know how there are these little annoyances that are just mild enough so that you do nothing about it?

In the world of open source there’s always this notion of “if you want something to be different, the code is there, you can change it”, but most often this is not practical: I would never go about carrying a patched version of Git with me to every machine I work on just because of the annoying `a/` and `b/` prefixes that show up on Git diffs.

But those tiny prefixes always made me unable to select and paste a filename with a double-click and a middle-click on the terminal.

Today, after who knows how many years, I decided to make a search about it — “I can’t be the only one annoyed by this, right?” — and lo and behold: someone did ask about this on StackOverflow, and there is a global configuration to disable those prefixes:

git config --global diff.noprefix true

And just like that, this annoyance is gone!

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.

The Linux program with most contrived argument handling logic ever has got to be gcc.

Everything in it has a reason, of course, but the end result is that you get a weird mix where the order matters for some args and not for others PLUS there are imperative arguments:

Say you want to link a static library into your program (I’m going to use […] to skip other flags)

gcc -o myprogram [...] myprogram.c libmylibrary.a [...]

This works, but now you want to add plugins to your program. So you add some runtime dynamic linking logic and add -ldl.

Oops, you realize your plugins can’t find some symbols from the static library, only those already used by the main program. The compiler threw away everything from libmylibrary.a that was “unused”.

-Wl,–whole-archive to the rescue!

Wait, what’s that? Two flags joined by a comma?

Turns out gcc is a main driver command which launches other programs, and passes arguments along to them. -Wl,–something means that it will pass the flag –something to the linker. You can add after -Wl, anything that is understood by ld, the GNU Linker.)

But you have other libraries you’re linking as well, and now you start getting duplicated symbol errors when compiling, because it is linking too much stuff! The solution? Wait for it…

gcc [...stuff...] -Wl,--whole-archive libfoo.a -Wl,--no-whole-archive [...other libs...]

The arguments in gcc when dealing with linker options are not only positional, they are imperative!

And I mean that in a quite literal sense. They interpreted like a sequence with side-effects: you set a flag, the next libraries is affected by it, you unset the flag, the following libraries aren’t affected anymore.

I thought find was a strong contender for Unix command with the weirdest argument handling, but I guess gcc takes the cake. 🍰

Melvin Conway famously said that organizations design systems that mirror their own communication structure. But how about Conway’s Law applied to the entire industry rather than a single company?

The tech industry, and open source (OSS) in particular, are mostly shaped now around the dominating communication structure — GitHub. Nadia Eghbal’s book “Working in Public” does a great job at explaining how OSS’s centralization around a big platform mirrors what happened everywhere on the internet, with us going from personal websites to social networks.

Another huge shift in organizational and communication structure, especially in Open Source, has been the increasing coalescence of maintainership: we historically talk about “a loosely-knit group of contributors” but most OSS nowadays is written by employees of big companies.

The commit stats in big projects like the Linux kernel indicate this, as do GitHub stats and the like. There’s a long tail of small independent contributors, of course, but by quantity major projects are dominated by those hired full-time to work on it.

One thing I haven’t seen discussed a lot is how much this reality changes the way projects are run and developed. Sometimes we see it coming up in particular cases, such as the relationship between Amazon and Rust, but this is a general phenomenon.

When Canonical came into the scene back in 2004-2005, I remember distinctly noticing their impact on OSS; it wasn’t just “more getting done” (yay?) but also what and how—various projects shifted direction around that time (GNOME comes to mind); it didn’t feel like a coincidence.

I don’t mean to imply it’s all bad, just that we don’t discuss enough about how the influence of Big Co development styles affect, in a “Conway’s-law-way”, the development of OSS, and even tech in general, since both open and closed development are so linked nowadays.

OSS has a big impact on how tech in general works (though the reliance of every company on OSS dependencies), and Big Cos have an impact on how OSS works (through their huge presence on the OSS developer community), so in this way they affect everybody. People bring in the experiences they know and how they’re used to working, from coding styles to architecture and deployment patterns to decision processes.

One great example where this is more evident is the “monorepo” discussion, which happens to projects of many sizes nowadays, and where Google and FB experiences are often brought up.

“help our codebase is too big” no, your company is too big. try sharding into microservice entities operating as a cluster in the same management substrate rather than staying as a monolith

— @myrrlyn on Twitter

The tweet above is such a great insight: we often see conversations about how to deal with huge codebases (using the likes of Google and FB as examples) AND we often see conversations about Big Tech monopolies — and how they’ve grown way beyond the status at which other monopolies were broken up in the past — but those two topics are hardly ever linked.

If we agree that some aspects of Big Tech as organizations are negative, how much of those do they bring into tech as technology practices via Conway’s Law? OSS seems to act as a filter that makes this relationship less evident, because contributions come from individuals, even though they work for these companies, and often replicate their practices, even if unknowingly.

These individuals will often, even if unknowingly, replicate practices from these companies. This is after all, a process of cultures spreading and influencing each other. It just seems to me that we as an industry are not aware enough of this phenomenon, and we probably should be more attuned to this.