Developing inside containers
As a long-time Fedora user, I have recently stumbled upon Fedora Silverblue: an immutable version of Fedora. By moving as much software to the userspace as possible, we can increase main system’s stability. This means either using Flatpaks or utilizing userspace containers.
Sounds cool, but surely, especially for software development, you need to install system programs, right? For those few Linux-specific applications that e.g. require Kernel access, yes. But the vast majority of software, and all the software that I deal with, runs entirely in the user space.
This means that you can install it within a container. You could do
that by manually spinning up docker/podman instances, or, you could
use a tool that makes doing it more convenient, such as
distrobox
.
Working within containers is similar to working on the host system.
You can either install programs on the containers themselves and
export them using distrobox export
, or use programs on
the host that support container development, such as
vscode
. Or, if you are a caveman like me that likes to
work from the command line as much as possible, you can just enter the
environment via
distrobox enter <name of the container>
Pros
-
no need to “bloat” your host operating system. Personally, I don’t like installing tons of software for work or cloned projects on my host system. It feels like it is becoming bloated, since there is no easy way to uninstall them later on. Containers are disposable, they don’t have this problem.
-
software versioning. Some projects might require you to use specific, possibly outdated versions of software. The thing is, your distro might not provide that version, or you might have a personal projects on the same machine that uses an up-to-date version. Best way to handle this is to install these dependencies within separate containers.
Cons
-
additional latency. It takes time to spin up a container. On my laptop, it is about 250ms. Not a dealbreaker for me at all, but worth mentioning.
-
clipboard integration. If you have used vim over ssh, you will encounter a similar problem: you cannot copy to clipboard with vim over ssh. This can be fixed by using
osc52
in vim as a clipboard. Note that this also requires your terminal to support it. VsCode works just fine.