BObonzini·Aug 18, 2025
There is toolbox, see https://github.com/containers/toolbox.
In Finding a Successor to the FHScontainers
toolbox
Go2018–2026
containers / toolbox
toolbox
Tool for interactive command line environments on Linux
27Distinct people
30Mentions
0Explicit recommenders
3.5KGitHub stars
What to know before exploring
What it is
Tool for interactive command line environments on Linux
GitHub
Where it is used
No documented product use was verified in the last source check.
What people are saying
No recommendation phrase was found in the indexed comments.
No classified warning is attached to this page. Read the discussions before treating silence as approval.
Also in these discussions
- 89luca89/distrobox · linked in 3 of the same discussions
Mentioned in the same Hacker News threads. That is not proof they are substitutes.
This week on Hacker News
Nov 8–Nov 15 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/15/2026, 9:28:18 AM UTC.
No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.
Mentions over time
HN mentions by year30 dated mentions
Observed mentions: 2018-12-13 18:49:07 UTC to 2026-10-06 10:54:23 UTC.
* An incomplete calendar period is marked with an outlined bar. Its count is not directly comparable with a full period.
Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.
View mention counts and date ranges
| Period | Start (UTC) | End (exclusive, UTC) | Mentions | Submissions | Comments |
|---|---|---|---|---|---|
| 2018 | 2018-01-01 00:00:00 UTC | 2019-01-01 00:00:00 UTC | 1 | 0 | 1 |
| 2019 | 2019-01-01 00:00:00 UTC | 2020-01-01 00:00:00 UTC | 3 | 0 | 3 |
| 2020 | 2020-01-01 00:00:00 UTC | 2021-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2021 | 2021-01-01 00:00:00 UTC | 2022-01-01 00:00:00 UTC | 9 | 1 | 8 |
| 2022 | 2022-01-01 00:00:00 UTC | 2023-01-01 00:00:00 UTC | 2 | 0 | 2 |
| 2023 | 2023-01-01 00:00:00 UTC | 2024-01-01 00:00:00 UTC | 7 | 0 | 7 |
| 2024 | 2024-01-01 00:00:00 UTC | 2025-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2025 | 2025-01-01 00:00:00 UTC | 2026-01-01 00:00:00 UTC | 6 | 0 | 6 |
| 2026 (partial) | 2026-01-01 00:00:00 UTC | 2027-01-01 00:00:00 UTC | 2 | 0 | 2 |
What Hacker News says
6 sourcesHaving smaller scaling units is a convenience. Yes. The mainframe world has tended to require massive upgrades to scale, yes.
Yet, in many ways, the world we are in today is actually intensely terminal based. When you are on Facebook, on Google, ask yourself where the compute is happening. Ask yourself what you think the split is, what the ratio of client : server compute is. My money is that Facebook and Google spend far more compute than I do when I use their services. And that's with these companies spending probably billions of dollars carefully optimizing their server side architectures to relentlessly reduce cost.
The hyperscalers use lots of powerful dense small servers. It could be argued that these servers more resemble one kind of shared personal computer model, since there are many dozens of them in the rack, not one big system
Read the rest
. But still, these systems host many dozens of requests at any given point in time, are being used as a shared system with many terminals connected to them.
Last, I do think we have mis-optimized like hell, and have almost no data points about how incredibly bad a job we are doing, have almost no idea what a thin-client / terminal based world could look like. Much of the reason for personal computers is that individuals had power over these systems, that it didn't take getting departmental them IT approval for each use case: you have your computer and do with it as you will. The organizational complexity pushed us away from the terminal model long long long ago.
But today, there's enormously popular container options. There's incredibly festureful container-based development options abundant, with web or GUI options abound. Toolbox is a great example. https://github.com/containers/toolbox I guess it could be argued that this brings a personal computer model to a shared terminal system, hybridized the option?
But I long to see better richer shared systems, that strive to create interconnected multi user systems, that we terminal into. There is so much power on tap now, so many amazing many core chips that we could be sharing very effectively, offloading work to, while sparing our batteries & reducing our work:idle compute ratios drastically with.
toolbx is not actually intended to provide any security or isolation, see e.g. https://github.com/containers/toolbox/issues/183
In Apptainer: Application Containers for LinuxCoreOS had a toolbox container that worked similarly to the one you have (the Podman people took over its maintenance): https://github.com/containers/toolbox
In docker2exe: Convert a Docker image to an executableThat's okay for the base OS that doesn't change all that often.
However, that falls apart when you start trying to have lots of "toolbox"/"containers"/"docker" things that people want to use for development.
The DNFs you need inside the container pile up very quickly when trying to do development. Those want to be deduplicated between containers. There is a reason why Nix gets grief about how large its store becomes.
In addition, lots of people also want to containerize their working/home directory. That requires really good overlay support, and nobody has this right now.
There are LOTS of issues filed against "toolbox" for this, for example:
https://github.com/containers/toolbox/issues/183
https://github.com/containers/toolbox/issues/348
https://github.com/containers/toolbox/issues/1470
This is something that should be straightforward
Read the rest
to implement. However, because the filesystem support sucks, it is not.
I'm using Universal Blue now (Aurora, i.e. KDE flavour) and I'm very happy with it. With its large amount of pre-installed packages and drivers (including proprietary ones), I still didn't need to install any custom package (rpm-ostree) or otherwise modify the OS config (except for turning off SELinux in /etc/sysconfig/selinux). It's the most pragmatic distro I've used so far.
SaveDesktop[0] (saves flatpak apps and DE configs) and mise-en-place[1] (declarative shell environment manager) are making my installation backupable and quite reproducible (not to NixOS standards though).
For software that's not in flatpak, docker or mise, toolbox[2] and distrobox[3] are available for the rescue. Both work really well (toolbox seems better for CLIs, distrobox for GUIs), but all atomicity/declarativity is lost.
[0] https://github.com/vikdevelop/Save