Toolbox conceptual model

Desktop Silverblue
#1

Hi,

Just recently discovered Silverblue/Toolbox and I really love the general idea about a stable/robust/immutable base OS, and easily spun up (throw away) containers for experimental development etc.

However, after some intial tinkering, what I don’t understand is why you are able to write to any file or subdirectory in the the HOME directory from a toolbox. I mean, what is the point of isolation if any software you install in a toolbox can modify your home dir content? What I (naivley) expected was something more like this:

  • HOME dir content would (by default) be read-only from within a toolbox.

    • I want my general configuration settings (nano, git) to work also in toolbox.

  • Any files I create or modifiy from a toolbox, under HOME, should be copied (or superimposed) onto a local toolbox “HOME” dir.

    • In case I want to override my usual setting s for a given toolbox.

  • Ability to specify subdirectories under HOME, that a given toolbox can have full read/write acces to, when creating a new toolbox.

Of course these are my personal expectations, and other people will probably have other ones, but having found no clear description/specification of the toolbox design intentions I found it quite confusing and frankly a bit demotivating (at the moment) to invest more time into. I think it would be really great for better/wider adoption if the designers of toolbox would invest some time in explaining the roadmap and how they think it should ideally work/behave when finalized. Don’t mean to be negative, love your work, but would appreciate some more communication on the design intents.

Thoughts?

#2

Not a Toolbox dev, but I can tell you about my use case. If the goal is proper containerization, you can use Podman proper for that. However, you can not (easily) use Podman if you, say, want to install Ruby gems or Python or Rust packages that you want available outside of the Toolbox, but that needs, say, gcc and/or other tools to install. Concrete example: I’ve installed Ansible inside a Toolbox with python -m pip install --user ansible for the express purpose of making it easily available outside of the Toolbox (it needs a compile step even if it’s mostly Python). Your expectation for Toolbox would make this workflow impossible. This saves me both the hassles of running everything in containers and layering packages like compilers on top of the main Silverblue image, and allows applications that need compiling to be installed in HOME. I use this strategy for Ruby on Rails development as well and it’s by far the best workflow I’ve had. (Old school local means lots of dnf packages for compilers and runtimes, Vagrant is too slow, Podman is a poor fit for Rails, etc. - Toolbox is the only tool I’ve really liked.)

That said, this has been discussed before. For instance, you can (although it’s cumbersome and non-intuitive) use a subdir or a different path entirely as a Toolbox’s HOME. Here’s one thread that discusses this: Is it possible to create a Toolbox with its own separate home directory? - #5 by rugk. Also, there’s some relevant discussion in this Github issue: Adjust home path · Issue #348 · containers/toolbox · GitHub

#3

I mean, what is the point of isolation if any software you install in a toolbox can modify your home dir content?

One point here is that by keeping your host system small and decoupled from your development environment, you can e.g. ensure you’re applying kernel and base OS security updates more quickly, without also dragging in e.g. gcc updates when the next kernel CVE comes out.

Anyways I also agree we should support this. But note that ultimately the toolbox program is just a wrapper for podman - which definitely supports a lot of configuration that you’re talking about; so nothing is blocking someone from either forking toolbox or making your own.

#4

Actually people already did that.

#5

Thank you for the pointers/links. Given the previous discussions on this (linked above by @evenreven) it seems I am not the only one confused about things. Given how old some of these threads are I’m suprised not more effort has been put in to clarify the key use case(s) for toolbox. In my eyes the marketing message at “Why use toolbox?” is misleading and should be described in more fine grain terms to better reflect (reality) how the tool currently works.

Overall, I think the project would benefit from clarifying the overarching vision/primary use cases for toolbox. Of course it can not solve every problem, but must focus on solving one or a few well. These goals, and their motivation, could definitely be more clearly stated to avoid confusing newcomers.

I really like the potential of toolbox, so I’m looking forward to see how it evolves.

1 Like