I've been happy to break for the end of year, and January was a good month in terms of energy for me. The break allowed me to get a fresh view on the current status of things, and I've gotten more organized.
January saw the return of the sticky notes, which are bringing me joy!
One big shift for me was how I handle my work day and organize my weeks. I'm starting my days earlier — after 7 to 8 hours of sleep — with 30 minutes of meditation and then let the coffee kick in.
The combination of these changes seem to provide me the clarity of view that I've been lacking at times.
Dangerzone
In December, we shipped Independent Container Updates, a feature we've been working on for a year or so. That was a relief. Dangerzone is now able to ship sandbox updates without having us to do a complete release. That changes considerably the feeling and work of being a maintainer. I really feel it was worth the work, given the stress it removes from us (me).
We can ship new container updates in hours rather than weeks, removing the need for not-so-interesting QA, and so it's a win. Our January container update has been downloaded by about 5k users in less that a month, so it seems to be working well, and we haven't had that many questions from users with broken installations.
We've had preliminary discussions on splitting Dangerzone in smaller parts. The goal is to lower the cost for contributors, and make it possible to use Dangerzone as a library. During this process, we've decided to go ahead with a dangerzone rust prototype I've been playing with. I'm pretty happy about it: it was fun to code, I've learned myself some rust, and one of the goals I had was to be as minimalist as possible. For instance, it generates the PDFs without external dependencies. After all, all we're doing is putting some pixels arrays in the right location. The resulting binary is less than a megabyte, and so that's exciting.
Into other news, Dangerzone now can ship dangerzone without a container.tar, which should prove useful to distribute lighter packages, we removed the macOS intel tests from the CI as they were excruciatingly slow, we made it able to react to light/dark mode changes, have fixed detection of PDF readers on Linux (which even takes into account Flatpaks .desktop files, thanks to a contributor); and Fedora and Debian packages are now published via the R2 storage solution, hopefully reducing egress costs and simplifying Ops work.
We're also in the process of publishing a few articles on the changes that happened in the past year or so, and are progressing on the threat modeling effort. The process of going through all the threats is time-consuming, but we're getting there!
Conflict prevention
I'm currently exploring if/how conflict prevention (yeah, better than conflict management, I guess) can be something I do more, and as part of that I've been reaching to folks I know who are in these areas. This is both fascinating and frightening to see how conflict both undermines community efforts and lead to suffering for folks who never wanted that. I want to learn more about how we can prevent it, and practice it more.
If you know anything about the matter (resources, folks, trainings), please reach out: I'm interested in what you have to say :-)
Handling signal groups as a team
I'm part of a team of folks who are tracking multiple signal groups. Everybody was doing this with their personal signal account, which was problematic because:
- Time-consuming ;
- Mixing different areas of our lives together, putting a burden on us when we didn't want to ;
- We were not able to hide messages away when we wanted to (we're taking turns) ;
- We didn't know if somebody already read and treated the messages, and so synchronization between us was not easy.
I have set up a new account for this, found a solution with a bridge from Signal to Matrix, using mautrix that works great so far, making it possible for the team to share the reading progress, and keep this separate from their main signal account. Great!
I hate money
I've handed off the ihatemoney project to a new team of maintainers, and I'm feeling great about it!
I was actually thinking of archiving the project, but they stepped up saying it would be sad as the tool is in their sweet spot, and more useful to some others they tried.
I'm happy to see that a project started 15 years ago is still useful, and am really looking forward to their work.
Other cool stuff
- I've done an [Arpentage (fr)](https://fr.wikipedia.org/wiki/Arpentage_(%C3%A9ducation_populaire), where we collectively split a book between participants, read it, summarized back and discussed. This time it was on the book “Antidote to the cult of performance. Robustness from nature” from Olivier Hamant.
- We're kick-starting a new band with a friend, with the goal to play New Orleans music in the streets of the countryside and elsewhere. One of the songs we've started to cover is “I will survive”, in swing jazz, and I so much love the vibes.
- I've managed to play a bit with a Sousaphone in my brass band. I don't really know anything about the valves, but I've been able to have a bass part rolling, on top of which other musicians were able to play. So cool!
- I attended a talk about what Cellebrite and tools able to extract data from a phone are capable of, and what is the current state of the art (yeah, it's clearly not art at this stage) around these type of tools used by law enforcement. I found all of it really useful, and learned a few tricks along the way.
AI
I've been giving a shot to AI for the month of January, as I wanted to know more about its capabilities, even though I'm very concerned about the impact it can have on humans and its environment. It made me go through a bunch of different states.
On the one hand, it's working pretty well for almost everything I threw at it. If I was able to give it the proper context and not trust it blindly. On the other hand, I've seen my “joy” of using it fading pretty quickly. It works until it doesn't anymore, and then when you try to make changes, you need to learn back what you delegated. That becomes a blocker rather than a help.
I recently viewed an interview (in French) of Aurélien Barrau, where he says:
What Groethendieck shows us — and this is of course anachronistic because AI did not exist in his day — what he tells us in his work is that a theorem proven by artificial intelligence — by a neural network, by a machine — would not have little value, it would have no value at all.
It would have zero value because what is important in a scientific result — as in any other result or discovery — is not the theorem, it is not the thing itself. It is the subtle, delicate, and passionate discovery of the landscape that unfolds around the discovery. It is that moment of communion between the thinker and the object of their thought.
This really resonates with my experience as a developer, where I feel that we can lose parts of what we usually learn, which I call appropriation. See what I wrote about what the AI does to developers:
This phenomenon is changing the way we write code, replacing a model that uses tools we own with another model that depends on external services, which offer to produce code according to the instructions we give it. We no longer take ownership of the resulting code, in a sense: we replace our attention to detail with a concern for having done things. We imagine the broad outlines of a project and let the machine take care of the rest.
For me, the central point is this question of ownership. But what do I mean by that? I'm thinking of the feeling we get when we can sing a song by heart, because it's now a little bit ours. We understand its deeper meaning, or perhaps we give it one. In a way, we feel closer to that piece of music. That's what I mean when I talk about appropriation and ownership. In the field of software, it's those lines of code where you've made mistakes and tried several ways to solve a problem before finding the one that seems most appropriate.
More generally, that's my experience with the code I write. It's possible that the machine will solve it faster than I would have, but I won't benefit from it, in the sense that my understanding of the problem at hand will not increase. Most of the time, it didn't, in my January experiment.
Not surprisingly, if I want to learn — and most of the time I want —, delegating to a third party will do the exact contrary.