For years I’ve had New Year’s resolutions to commit to blogging. This year isn’t any different!
So, what is different? For one, I feel I have more to share with the world now. I recently moved back to North Carolina, took up motorcycling again, and have professionally refocused on computer security.
In a surprising turn of events, Twitter recently torched its community goodwill and has suffered a massive brain drain. While this has been felt most acutely in the computer security industry, other groups, such as journalists, have also moved to Mastodon. I’ve tried my hand at Mastodon too, and while it’s been a good way to connect with more local personalities, it still feels a bit empty and hollow.
The post-Twitter shift has made room for a nascent renaissance in distributed social media and even blogging. There's been a clamor for folks to Start a Fucking Blog. Feeds are back en vogue, even if they have taken on a new flavor: ActivityPub.
Now blogs such as this one have ActivityPub feeds, which means they can be followed on Mastodon (this one is @thomrstrom@unfinished.bike). Even a decade after it was declared dead, RSS is still around and Feedly is as good as ever.
It remains to be seen what will be done with this next-to-new-found-land.
While preparing for my first week at Chainguard, the CEO mentioned that I should order my own laptop. As a ~15 person startup, there isn't an IT department to handle these sorts of things.
In 2022, the default laptop of choice for a software engineer working on cloud infrastructure is the Apple M1 Powerbook. They hit nearly all the checkboxes: a great screen, powerful CPUs, and battery life that is the envy of any laptop in their class. The arm64 based Macs are fantastic: in fact, I'm typing this from my personal M1 MacBook Air. Ever the contrarian, I however felt that:
What if you could easily reduce the length of outages by 3X?
According to the SRE book, “recording the best practices ahead of time in a playbook produces roughly a 3x improvement in MTTR”. This improvement mirrors my experience with well-written playbooks.
In my experience as a software engineer and a software engineering manager, I’ve found that the best way to motivate software engineers is with empathy, purpose, and a sense of craftsmanship. Conversely, the most effective way to demotivate a software engineering team over the long term is with excessive process and deadlines.
Let’s dive a little bit deeper into the levers I’ve found that work in motivating software engineers into doing their best work:
Ever wanted to run Docker on an unmanned macOS machine, where all users could have access to a working Docker command-line?
First, be aware that docker is not designed to be securely shared among multiple users. As with Linux, Please assume that anyone who has access to docker is effectively equivalent to `root'.
I wanted to get my feet wet with understanding Kaniko, an open-source in-cluster builder for Docker images. I happen to work with one of the maintainers, Tejal, and I asked her if there was any interesting UNIX-internals sort of bugs that might be interesting.
Here's the mystery issue: “The USER command does not set the correct gids, so extra groups are dropped”. Here's an example to reproduce it:
