In 2021 I did my first solo bike-packing trip along the picturesque (and hilly) coasts of Cornwall. I collected a few thoughts about that experience in an article titled What I learned by solo bike-packing for 10 days around Cornwall.

It's now been 5 years, and my life has changed quite a bit: I'm now happily married and I've moved countries a few more times. Because of pure coincidence, my wife also happens to like cycling (although she's more on the gravel side of things, 'cause kids these days), which meant that this year we chose to embark on a bike-packing journey together!

This post is a collection of git tips and tricks that have improved my life while working on all kind of codebases, from small libraries to huge monorepos hosting the services of a whole org. Some tips are Emacs-specific, others will take the shape of simple git oneliners that I use daily. This is a 'live' article and it will keep evolving as I collect more tips.

The first few months after moving for work to the core of Silicon Valley I kept randomly stumbling into the offices of Redhat, Pinterest, Adobe, Amazon, etc.. without really wanting to. It was just part of going around places. With that, a slow but inescapable realization also started taking shape: every flipping bit of digital tech I used was coming from that place. Brands and logos that I had only seen in digital shape were now occupying my same physical space.

When I was living in Italy or in the UK that small innocuous fact had no real consequence: Silicon Valley was just a place somewhere on a map: of course every digital revolution came from there, it was in the name, after all.

However (see Taking a break from corporate America) now that I was living there I had a much more concrete idea of what Silicon Valley really meant to me, outside of the Hollywood dramatisations that dominated the collective imagination (and consequentially mine too).

After a few years of constantly hearing about how cool Niri is, today I finally caved and decided to give it a try (aaah, the miracles of peer pressure).

I was initially hesitant because in my experience tiling window managers (ackshually on Wayland they are compositors, but you get the gist) have a tendency to be useful for very narrow use cases, while the giant hype around them (cough hyperland cough) tends to just focus on flashy animations. Not that I mind aesthetics, but I'd also like to use my computer for pursuing somewhat productive activities.

The last time I played with a tiling window manager was a couple of years ago (see Setting up Sway on a new machine). I was generally pleased with how easy and nice it was to configure Sway, but in reality I didn't end up daily driving it on my Arch machine: KDE took that spot. The thing is: while the idea of tiling managers is pretty neat, the practical usability tends to suffer the moment you exit from a world where the only thing I do on this computer is write code all day. Doing any kind of creative work with many floating windows tends to negate the benefits of automatically tiling windows.

Which is why on my first day trying out Niri I was positevely surprised..

TL;DR: A short essay on the elegance and practicality of composable interfaces. AKA 'why I prefer Houdini to Maya'.

The other day I was watching the latest video by Entagma, titled Nerd Rant: Are we switching to Linux?.
At some point Manuel - in a very tranchant way - mentions that the way terminals work is mostly due to leftovers from the past, and that (compared to GUIs) text based interfaces are not ideal from a design standpoint.

I found that particularly surprising, especially since Entagma has historically done a lot of great Houdini content, and Houdini has deep roots in the UNIX philosophy, which has been a fundamental drive in the design of most terminal applications we use today.

At some point, I used to share a similar opinion to Manuel's regarding command line tools and terminals. However, with time I radically changed my perspective, so I here I have collected my thoughts on how that happened, and why now I believe that for certain tasks, terminal-based workflows are terribly elegant and efficient.

Gnu-linux minimalistic logo (CC-BY-SA-4.0), Cocktail Orange Drink (Public Domain)

Since I've been using Linux as my daily driver for a while, I thought it might be useful to write a small handbook to help demistify how to live your Linux desktop journey without sacrificing a good UX. Especially on Reddit, there's so much silly noise that makes it hard to focus on what really matters when using computers to "get stuff done".

This article is dedicated mostly to new Linux users, but who knows, maybe you'll learn a trick or two nonetheless. Note that this post will keep being updated as I keep discovering stuff!

NOTE: My shift towards using Linux more and more has been motivated by having worked at Apple and coming changed after that experience. See Reflections on 20 years of computing.

If we're Linkedin connections, you might have noticed that I left Apple a few weeks ago. Not only that, but I also left the USA to go back to Europe!

What is happening? Why am I here back in (allegedly cloudy) London?

Well, after almost 4 years of working at Apple, and after 2 years of living in the heart of Silicon Valley in California, I decided to take a small break and reconsider what's (really) important for me in life. Turns out that working in Big Tech in the midst of Silicon Valley is not really high on the list.

A collection of photos I took of Prop 65 notices in California. Because why not?

Image credits: https://www.eff.org/pages/certbot

Folks that know me also know that I'm a big fan of the work of the Electronic Foundier Foundation.

Today I'll give you one more reason to love (or discover) them even if you never cared about their battles on digital privacy, free speech, etc..

If, like me, you have a website and you have been regenerating your SSL certificates by hand every year like a peasant (while also paying an SSL provider for them!) you might enjoy this small quality of life improvement given by certbot.

For me, it's literally been LIFE-CHANGING: it doesn't happen everyday that you discover how to save money and time on what is fundamentally a chore!

If there's one thing that I have learned from my stay in the Silicon Valley, is that Americans love their cars and trucks. Oh boy if they do. This results in having the majority of the transport infrastructure leaning HEAVILY towards car-based movements (to the point that cycling or walking to get to places feels a bit like a quirky habit?).

I could write a whole post about this, but for now let's just say that for somebody used to do most of their errands just cycling around and hopping on trains, that was a bit traumatic. I'll never forget entering SF for the first time by motorbike and realizing that there's a literal highway (the 101) passing through the center of the city, not around it (like I'm used to from Rome/London/Paris, which all have a big ring outside the historical city center).

So last year, using this trauma as a positive motivation (what you're gonna do otherwise?), I decided to start digging up open data about the occurrence of car crashes in SF. Given I lived a few years in London, I was curious also to draw some quick parallels. The report that follows is a collection of visualizations analyzing the last 20 years of car crashes in the city, thanks to the open data provided by https://data.sfgov.org.

It is no surprise that over the last few years I've grown increasingly disillusioned over the direction taken by most technological developments pushed by 'Big Tech' firms (enshittification is very real!). As a result, I started searching for new answers on questions that I thought I had answered early in my 20s, to better understand where I'm really coming from and find the right direction for my future choices. One of the most important questions in this area is always: what is a quality OS environment for my computing needs?

If I look at the evolution of my digital journey from the beginning, it feels that it started two epochs ago. Of course, in fully dialectic spirit, every thesis has an anti-thesis, so I sense that both epochs should resolve in third one that represents a synthesis of some sort..

In The elephant in the room, Part 1: Rust interop with C++ I looked into how one can integrate Rust into an existing C++ project by writing Rust code and exposing a simple C API that can be called from C++. All you needed to do was compile your crate as a shared library and then link it in your C++ binary.

In this exciting new installment I'll instead explore the other direction: how to call functions from a C++ library inside your Rust crate. Follow me into one more 🦀-shaped hole, where we'll try to use OpenImageIO (the famous C++ library) from Rust..

Let's have some physical computing by programming Raspberry Pi Pico using Rust.. 'cause why not?

• Are you stuck living in a C++ world even if you didn't choose it? (cough VFX cough)
• Do you prefer the ergonomics of cargo add to the ones of apt-get install some-random-dev-header until things work ?
• Do you like a language whose motto is to "empower everyone to build reliable and efficient software" ?

Then follow me in this beautiful 🦀-shaped hole..

Imagine that one day you stumble, almost by sheer chance, into a repository that explains how to override the Splash Screen of your favourite application via some intricate pointer and LD_PRELOAD magic. Then imagine realizing that the person that made the repo is technically (almost) an ex colleague of yours, and the code is now 8 years old.

Could you resist the temptation to reproduce their teachings after all those years ?

From there, Gregor's gaze directed itself towards the window, and the drab weather outside - raindrops could be heard plinking against the tin window ledges - made him quite melancholy. What if I went back to sleep for a while, and forgot about all this nonsense?' he thought, but that proved quite impossible, because he was accustomed to sleeping on his right side, and is present state he was unable to find that position. However vigorously he flung himself to his right, he kept rocking on to his back.

It is no surprise (see Choosing to work with Common Lisp in 2023) that I've been trying to build my perfect creative coding framework for a while.

Something that:

• Feels like live coding in Extempore
• Is as flexible as OpenFrameworks (but with less duct-tape around it)
• Looks as elegant as https://github.com/inconvergent/weird
• Is crossplatform, or at least supports on Linux and macOS

Ideally, it might even have support for working in scene linear, like Nannou.

I'm currently at my 3rd iteration of this adventure. It's a pet project: I might work on it a few hours every several months, or a few intense days in a row; I don't care if it never sees the light of the day, at this stage I just work on it to fulfill an internal need.

I always wanted it to be written in Rust, and to be hackable via a higher level scripting language (first a declarative one, then Python via PyO3, and for v3 I'm exploring a small Scheme-like interpreter).

In those ~3 years that I embarked in this part-time adventure, I completely lost trust in wgpu (the crate) getting somewhat stable anytime soon, so now I'm rewriting the graphics backend to move away from the need to constantly play catch-up with wgpu.

In this post I just try to piece together the puzzle of "how the realtime graphics Rust ecosystem looks like today", to understand where it makes sense to bet.

An interesting title could have also been: Lets build A Python interpreter (à la https://github.com/RustPython/RustPython). That's a bit more involved, so instead I will write out about building THE One and Only CPython interpreter from source, and why would one want to do it.

Today I watched Eno for the second time.

I don't generally do "happy new year" posts, but after watching Protesilaos' video I had an overflow of good energy and so I'm resharing his vlog here. Γνῶθι σεαυτόν, love yourself, and have a happy new year you all!

Protesilaos' website (Emacs tips, philosophy, et cetera): https://protesilaos.com

Premise

So I had a Linux laptop for a bit now. On my main desktop workstation I used to have Arch, but to help my wife's recent 3d endevours I installed PopOS instead, which is more user friendly, and most importantly, is somewhat officially supported by Autodesk. Where by "officially supported" I mean: there's a 13 steps guide on their website documenting the commands to run to get it to work, including setting up correctly their beautiful Licensing tools (something that I tried to on Arch without success, mostly due to the horrible error messages spit out by the AdskLicensingHelper CLI).

Due to this loss, the amount of tinkering I feel the need to do on my laptop has grown exponentially. Which eventually lead me into the beautiful 🐇 hole of tiling window managers..

A quick note on how I install (doom) emacs on a new computer. For a guide on how to use Doom once it's installed, see my doom-emacs-handbook article instead.

In thoughts-on-ai-art (which is from 2018, in the midst of my Computational Art studies), I wrote the beginning of a never-to-be-completed draft about the role of AI as a mean to generate artworks. As somebody deeply interested in coding rules, patterns, cellular automata by hand the Weltanschauung around using AI to generate the final product always left me with a sense of.. unfullfiment.

Since I might never finish that article, and I've decided to keep that as-is, I can least re-share an article that I found to share some of my same internal doubts about this new world we've somehow decided to build: https://drewdevault.com/2023/08/29/2023-08-29-AI-crap.html (which I got from https://mckayla.blog/posts/recommended-reading-2023.html).

A new adventure

I've been wanting a just-for-my-own-enjoyment Linux laptop for a looong time. Probably it all started from my time in Framestore, when CentOS was the main OS at work, and I could see the Linux Jedi there perform all kind of (useful) one-line shell trickeries. You could tell those kind of things came from running Linux as a daily driver at home, not just at your $dayjob.