How does it differ from existing tools kinda do exactly same, like e.g. toolbx. (And to a slightly lesser degree flatpack, snap, etc.)?
And what prevented adopting/supporting existing projects, instead of further tool ecosystem fragmentation? (kinda the same question, just differently phrased)
Ha! I wrote the first commit to CoreOS's toolbox in 2014: <a href="https://github.com/coreos/toolbox/commit/dc4aa0b14bceafd6afaf144c54cf66156109e220" rel="nofollow">https://github.com/coreos/toolbox/commit/dc4aa0b14bceafd6afa...
And then I read your comment and my first reaction was, oh, they typoed toolbox. But, nope, Red Hat created toolbx which confusingly has the CLI binary of `toolbox`: <a href="https://containertoolbx.org" rel="nofollow">https://containertoolbx.org
... it's not. Just another way to keep my host clean and do the dirty work somewhere else. Where did reproducible builds come through? Another comment?
Most of these tools you mention are designed to work best as an overlay to your $HOME. toolbx, distrobox, and to some extent flatpak and snap. NSL is built to give you the "pet" virtual machines with limited integration to the host - you can get to the host filesystem if you want, and you can use the host's Wayland session. I think a better comparison would be using NSL instead of using a remote computer or VM.
dathinab · · focus · HN ↗
And what prevented adopting/supporting existing projects, instead of further tool ecosystem fragmentation? (kinda the same question, just differently phrased)
philips · · focus · HN ↗
And then I read your comment and my first reaction was, oh, they typoed toolbox. But, nope, Red Hat created toolbx which confusingly has the CLI binary of `toolbox`: <a href="https://containertoolbx.org" rel="nofollow">https://containertoolbx.org
bketelsen · · focus · HN ↗
philips · · focus · HN ↗
bketelsen · · focus · HN ↗
philips · · focus · HN ↗
bketelsen · · focus · HN ↗