Next-Gen Linux

Distroboxes

Distrobox is a major improvement on vanilla containers for everyday development for several reasons:

  1. it not gives you an easy and ergonomic way to drop into the shells of various containers (inheriting your default shell, your environment variables, etc)
  2. gives those containers access to your home directory (by default, only your home directory) so they can use any executables you've installed into your home directory on your host (which is where I'd install packages I want all my distroboxes and my host to share, using netbsd's pkgsrc or eg cargo install built from inside a distrobox (which works bc rust always statically links everything besides glibc), and all of your dotfiles and projects and stuff
  3. gives you the ability to integrate GUI applications installed in those development containers into your host desktop environment (.desktop files, etc), and even terminal commands too iirc
  4. makes sure the containers start on boot so you don't have to wait for them to start when you want to use them
  5. creates new terminal shortcuts for each of them

And more I'm probably forgetting.

There's even a great terminal emulator app, Pytaxis, that directly integrates with distroboxes, letting you assign terminal profiles based on which container you're in, and directly launch terminal windows or tabs into a container from within it.

The extra benefits (besides just keeping your environment clean) to container based development environments are:

  1. that you can control what they do and don't have access to file system and hardware wise, and by default they don't require any permissions besides home dir and network access, so they can't even see your actual system files or hardware or anything, and you can spin up ephemeral environments, so you can more securely do curl | bash, build and install random things, install unofficial packages, etc, which you often might need to do in development.
  2. You can have any distro you want at your beck and call to easily install or build things, and reproduce anyone Linux user's (eg build or test) environment with ease
  3. You can use Containerfiles and distrobox-compose to reproducably and automatically build your own containers from upstream images, so you can regenerate your development environment anywhere, and even use CI/CD and self hosted (plus self signed) docker image repos like the one github has to automatically regularly build (and thus update) and serve out those images so they're always already built and available for you anywhere, on any computer. See: https://github.com/ublue-os/boxkit?tab=readme-ov-file
  4. You can take advantage of the pre-made development or execution environments already available in the incomprehensively massive library of Docker containers available.
  5. You can decouple the the versions of programs you use for your development from the versions of those same functions that your Linux distribution May rely on to function, which should have been separate anyway but in our current world where everything is managed by the same package manager and required to align independencies and versions as a result, distrobox is the best way to achieve this decoupling. It also allows you to decouple the versions of programs that you use between projects even. You can get this with Nix or guix, but they bring a whole huge wad of other problems, including the fact that every single program has to be patched to work with them and their file structure is not human readable and they can't take advantage of existing doctor containers built wad of other problems, including the fact that every single program has to be patched to work with them and their file structure is not human readable and they can't take advantage of existing doctor containers built for things.

FYI: distrobox can run on top of either podman or docker, but I seriously recommend using podman instead of docker (for everything in general tbh), since podman doesn't need to run a common daemon to manage your containers, and it can be truly run in rootless mode bc it doesn't need to be internally running as root to run containers like docker does (even if you don't need root to run docker commands, the daemon it uses to run containers still itself must run as root), do it's a lot safer and more secure. Root, as a concept, was a mistake.

https://hackeryarn.com/post/distrobox

https://distrobox.it/

https://www.ypsidanger.com/declaring-your-own-personal-distroboxes/

https://www.ypsidanger.com/making-the-most-out-of-distrobox-and-toolbx/

Examples of pre made development environments you could use with distrobox:

Image-based immutable Linux distros

(by which I mean the ones made with rpm-ostree, e.g., Fedora Atomic and the Universal Blue community subdistros — the images I recommend you use are the universal blue base images, which are just Fedora Silverblue with all the common sysadmin housekeeping you'd ordinarily have to do yourself after install taken care of, or secureblue, a significantly hardened version of the ublue images that borrows a ton of configs and hardened_malloc from GrapheneOS. There are non image based immutable distros, like NixOS, and non-immutable image based distros too, I believe)

The operating system you install on bare metal is itself an image, a container, specified with the same standard OSI format that docker uses, that is mounted read-only (except for your home directory and the /etc directory, which is where they put every configuration file in your whole OS) and reset fresh from the image on every reboot. You can only modify the OS image through layers that never modify the core image at all, but just add overlays on top of it to e.g. add or hide packages, or through building your own images prior to installation (basically, making your own personal distro without the hassle of manually keeping up with upstream, because they're just docker images, so you can make a containerfile that pulls in an upstream docker image, makes any modification you want, and produces a new image, and get CI/CD and CDN delivery and auto updates on new upstream images automatically)

This really cuts down the system administration, because you are freed from the entropic nature of maintaining a mutable Linux system over time, where basically anything can be modified and so it just bitrots over time. Instead, your core OS is always known-good underneath, but at the same time you can still make modifications, they are just overlay layers on top of the core image, always self-contained and reversible and listed, so you can do git style operations on your OS image and its layers like cherry picks and rebases to other images. And unlike git these layers aren't temporal, there's no linear history to make it harder to mix and match. Even /etc is just an overlay on top of the default configs provided (and updated) with the OS image, so you can always reset them or diff them.

For example, updating consists of rebasing to an updated OS image, which is an always working, fully coherent OS, instead of just a blindly applied piecemeal packages updates, then replaying the changes you've made on top of the fresh updated image, instead of playing the updates on top of your modified system, hoping blindly that it ends up where you should. This way you can be sure that the updates will always work and then your own changes will be replayed on top of that to make sure they are fresh and maintained as well.

There are also of course security benefits too, because it becomes much more difficult to modify your system, since the only way to do it is through packages, but then that modification will show up as a layer with its own name that you can always remove without touching anything else, and because by default it only will even install packages signed by repositories whose public keys you have added to your trusted list. There is no other way to modify the system. And of course those packages can do arbitrary things, but they do them through an overlay file system so your core is always safe. This of course means you also get transactional changes and rollbacks. And you also get A/B style updates. And in fact it always keeps at least two older images around, and you can pin more, so you can always revert things completely.

There are some things you should know if you go this route though that will save you a lot of pain and frustration:

  1. Fedora Atomic is really barebones by default, and since layering is kind of painful it can be really annoying to do the system administration necessary to get it set up; especially if you have an Nvidia card and you have to do all the typical annoying shit you have to do on Linux to set that up. So instead of using vanilla Fedora Atomic, I highly recommend checking out Universal Blue, which offers pre-built Fedora Atomic images with all of that annoying setup and system administration done for you already. Their headline images (Bazzite and Bluefin) are really opinionated, but don't worry about that, their base images are perfectly usable too! That's what I use :)
  2. Layering packages via rpm-ostree should not be used for just random system utilities or applications. That's not how it is intended to be used, and that way lies only pain. The whole point is that the applications you use as a user, including terminal ones, should be separate from the core system, and not dependent on it, so they can be updated separately and not break each other. Layers, since they are updated by the system package manager, must be versioned in lockstep with the rest of the system, and the system image will fail to build if it can't update the layers you have, so really only use it for things you consider part of your essential OS. People who forget this tend to come away really hating Atomic distros. For your development environment or any build environments you need, create distroboxes and install applications inside them; for GUI applications, just use Flatpak, or install the application inside a distrobox and use distrobox-export to integrate the app into the host. If distrobox feels too heavyweight, or you just want various sundry utilities installed on your host system, then I recommend using something like Homebrew or Nix or Guix or Pkgsrc, that is, any package manager that installs things to your home directory in a way that is cleanly separated from your host system and independently updated. Universal Blue images come with a script to get Homebrew all set up for you. Wouldn't have been my first choice, but its very convenient.

https://blog.verbum.org/2020/08/22/immutable-%E2%86%92-reprovisionable-anti-hysteresis/

https://www.ypsidanger.com/chromebook-alternative/

https://www.ypsidanger.com/the-distribution-model-is-changing/

https://www.ypsidanger.com/a-container-runtime-on-the-linux-desktop/

https://www.ypsidanger.com/a-34-line-container-file-saves-the-linux-desktop/

https://www.ypsidanger.com/myths-about-this-new-fangled-linux-desktop/

https://universal-blue.org/

Flatpak: linux application distribution for the future

There has been a lot of lies and misinformation spread about f l a t p a k in the Linux community, mostly as a result of a few people being set in their ways and inventing nonsensical post hoc justifications for not wanting to change, or not understanding how it works. I will link to some articles debunking that misinformation below. But the core idea is excellent. Basically, instead of:

  1. having the versions of every application you can have on your system artificially locked to the version of your Linux distribution itself, and forced to having the versions of every application you can have on your system artificially locked to the version of your Linux distribution itself,
  2. Having your app forced to only use versions of its dependencies that are compatible with the versions your Linux distribution itself needs, which is unnecessary entanglement between your user applications and the innards of your os,
  3. getting your GUI applications filtered through whatever nonsensical arbitrary patches and chopping up and dicing or merging your Linux distribution may randomly decide to do to your application, and through whatever capricious decisions they may make about when to update your application and when not to, so that you never fully know whether a problem you are having with an application is the result of a bug in the application or a bug in how your distribution packages at,
  4. package manager having to imperatively and mechanically and blindly, whenever you install an application, do its best to make sure your environment is set up for that application, but often be unable to change everything it needs to you to ensure the application works properly
  5. Have every application you run run effectively as if it was itself you, so that anything you as the owner of the computer can do or access your application can also do or access, and the system will allow it,
  6. Being unable to get the system to understand that different applications are different and should have different permissions and accesses, since they all run as you
  7. Having to worry about whether an application is packaged for your distribution or not and what it will be called if it is

Flatpak means you can:

  1. Install applications in a way that is cleanly separated from your system in a principled way that allows it to update independently from your system and use whatever dependencies it needs
  2. Get applications directly from the creator of the application, and know that you will always have the exact version that they distributed and it will always be up to date
  3. Allow the creator of the application to declaratively and reproducibly specify the environment the application expects to run in, so that it can run inside that environment so that it can run inside that environment while still interacting almost transparently with your distribution as while still interacting almost transparently with your distribution as needed
  4. Have the ability to an extremely powerful and granular level set the permissions of every application, separately and separately from what you yourself as the user have access to, and allow the system to transparently temporarily Grant extendedSeparately and separately from what you yourself as the user have access to, and allow the system to transparently temporarily Grant extended access rights if you clearly intend to, like temporarily granting an application access to a folder that you drag and drop into the application or select through the applications fileAn application access to a folder that you drag and drop into the application or select through the file picker
  5. Have a completely distribution independent packaging system for your applications so you never have to worry again whether an application exists for distro or not
  6. Have a build model where the source code of an application does not need to be handed directly over for compilation and packaging to distribution maintainers, but where application developers can develop their application however they want and to produce build artifacts themselves and then distribute them to you directly, with the application repository being able to verify whether the packages come from who they say they do, and applications being able to link to their open source code and publicly available build process if they are open source, meaning that both open source projects and proprietary applications can comfortably process if they are open source, meaning that both open source projects and proprietary applications can comfortably distribute

A lot of benefits imo!

https://theevilskeleton.gitlab.io/2023/06/04/response-to-developers-are-lazy-thus-flatpak/

https://theevilskeleton.gitlab.io/2023/05/11/overview-of-flatpaks-permission-models/

https://theevilskeleton.gitlab.io/2022/05/16/response-to-flatpak-is-not-the-future/

https://theevilskeleton.gitlab.io/2021/02/11/response-to-flatkill-org/

https://www.ypsidanger.com/lets-just-kill-the-silly-myths/

https://orowith2os.gitlab.io/posts/Flatpak-an-insecurity-nightmare/

Versus Nix

If you're wondering what the advantage of this is over Nix, the most important to advantages for me are that:

  1. Nix's directory structure is basically completely unreadable and unusable for human beings in a way that is far worse than the default posix directory structure
  2. Nix requires absolutely every program and package that runs on it to be custom patched to deal with its alternate directory structure, and while sure yes it's package repository is gigantic so a lot of that work is done for you, it can still cause weird problems and make things much more unreliable and good luck if there's a package that isn't there or hasn't been updated for a while. I'm on an emacs Discord and apparently installing it on Nix is very difficult. It's just another layer of possible incompatibility and failure and annoyance on top of the stack of those layers that compose linux.

Meanwhile, you got most of the same benefits on an atomic distro, except:

  1. it's all completely human readable
  2. uses standardized technology so it's already compatible with everything without having to do any work
  3. you can get fully different distros inside distro boxes, unlike with and Nix's equivalent.

The other thing is that with nix, you configure your entire system at a layer of abstraction above what's actually happening on the system — it's not like that declarative config is actually directly deciding how the system operates, no, it's just layered on top of all of the existing crap Linux has going on, and you're just hoping that it can automatically, imperatively perform the actions necessary to keep your system in line with the config.

That, and to get the same level of resistance to entropy and reversibility and ability to power wash and rebase and cherry-pick changes and stuff that you get with an atomic distro on nix, you would have to Version Control your Nix config and then also be very very careful with manually committing with informative commit names at regular intervals every time you make a change and stuff, instead of it being handled automatically for you and not requiring an extra version control tool slapped on top.

Plus, Nix doesn't benefit from the minor, but still meaningful in my opinion, security benefits of an immutable image-based distro.

Edit Report
Pub: 22 Jun 2024 22:53 UTC
Edit: 25 Jun 2024 14:22 UTC
Views: 161