Run a container with a host directory mount, and it either leaves root-owned files behind or it runs into "permission denied" errors. Welcome to the dreadful container host filesystem owner matching problem. These issues confuse and irritate people, and they happen because apps in the container run as a different user than the host user.

There are various strategies to solve this issue, but they are all non-trivial (requiring complex logic) and/or have significant caveats (e.g., requiring privileged containers). Here's where my new tool MatchHostFsOwner comes in.

Ubuntu 22.04 was released a couple of days ago. Fullstaq Ruby now provides packages for this distribution!

I previously designed a robust distributed locking algorithm based on Google Cloud. Now I'm releasing a Ruby implementation of this algorithm: distributed-lock-google-cloud-storage-ruby.

To use this, add to your Gemfile:

gem 'distributed-lock-google-cloud-storage'

Many workloads nowadays involve many systems that operate concurrently. This ranges from microservice fleets to workflow orchestration to CI/CD pipelines. Sometimes it's important to coordinate these systems so that concurrent operations don't step on each other. One way to do that is by using distributed locks that work across multiple systems.

Distributed locks used to require complex algorithms or complex-to-operate infrastructure, making them expensive both in terms of costs as well as in upkeep. With the emergence of fully managed and serverless cloud systems, this reality has changed.

In this post I'll look into a distributed locking algorithm based on Google Cloud. I'll discuss several existing implementations and suggest algorithmic improvements in terms of performance and robustness.

Containers are no longer only used on servers. They are increasingly used on the desktop: as CLI apps or as development environments. I call this the "container-as-OS-app" use case. Within this use case, containerized apps often generate files that are not owned by your local machine's user account. Sometimes they can't access files on the host machine at all. This is the host filesystem owner matching problem.

• This is bad for security. Containers shouldn't run as root in the first place!
• This is a potential productivity killer. It's annoying having to deal with wrong file permissions!

Solutions are available, but they have major caveats. As a result it's easy to implement a solution that only works for some, but not everyone. "It works on my machine" is kind of embarrassing when you distribute a development environment to a coworker, who then runs into issues.

This post describes what causes the host filesystem owner matching problem, and analyzes various solutions and their caveats.

Traveling Ruby allows you to easily ship Ruby apps to end users. It lets you create self-contained Ruby app packages that run on multiple versions of Windows, Linux and macOS.

Today I’ve released version 20210206. This release supports Ruby 2.4, bumps all the gem versions, bumps the minimum supported macOS and Linux versions, and fixes some bugs.

It has been a long time since the last release. So this post also adresses an elephant in the room: is Traveling Ruby back?

In my last blog post about Traveling Ruby's future, I said that it's hard to democratize the development of Traveling Ruby because of System Integrity Protection (SIP). Traveling Ruby's build process relies on DYLD_LIBRARY_PATH, which is blocked by SIP. This means that:

• Contributors that build Traveling Ruby on their own laptops, must disable SIP.
• Traveling Ruby cannot be built on many CI hosting services, such as Azure DevOps and Github Actions, because it's not possible to disable SIP there.

After some research and experimentation, I've found an alternative to DYLD_LIBRARY_PATH, meaning that it's no longer necessary to disable SIP. This significantly changes the ability to democratize Traveling Ruby's development.

A couple of years ago, I had a dream: to make it dead-easy to distribute Ruby CLI apps to end users, without requiring those users to install Ruby or muck about with gems and Bundler. And thus Traveling Ruby was born.

Traveling Ruby hasn't seen updates for quite a while now. Recently I tried making a new bugfix release, but I found it to be more challenging than I had hoped. In this article I reflect on those challenges, as well as on the future of Traveling Ruby.

Debian packaging can be quite mysterious and hard to figure out. In this guide I'll provide a simple introduction into the Debian packaging process and its most important concepts.

This is not a full guide into all aspects of packaging. Instead, I'll cover just enough of the basics to help you develop a mental model of what Debian packaging is about, and to be able to produce useful results.

I'll cover:

• What a Debian package is.
• The anatomy of a package.
• How to inspect a package.
• How to create a package.
• What APT repositories are.
• How to create an APT repository.

What's the difference between command and command | cat? There shouldn't be any, right? The first prints the output directly, and the latter prints output via cat, but they should have the same effect. Not so: the latter can cause the command to get stuck indefinitely. This has given a particular CI pipeline of mine quite some headache.

To learn why this happens, and how we can mitigate this problem, we need to dive into the arcane magic that is Unix process management. Join me on this journey.