FWIW, uBlue has been brewing for almost three years now for their CLI stuff: see this issue tracker and this blogpost from Bluefin’s creator.
The distrobox workflow overall has mostly been superseded by better alternatives[1]. Though, for completeness’ sake, openSUSE’s atomic offering continues to heavily rely on Distrobox. But, in their defense, I think their atomic offerings are simply better[2] suited for it.
There’s sysext with its (WIP) manager, Brew Tap to tap into homebrew casks and some peeps even use coldbrew. And last, but definitely not least,
nixsupport has improved over the years. And if you just want to usednf, RakuOS’ innovative hybrid design allows just that; an image-based core you can’t touch (like the other ‘immutables’), butdnfworks and is applied through a persistent overlay. ↩︎Fedora’s container images are tied to its major release versions. Hence, every 7-13 months you’re required to set them up from scratch if you’d like to continue using them 😅. Even if this process can be streamlined, it’s IMO very cumbersome regardless. In openSUSE’s case, the containers are based on Tumbleweed. Which, has a rolling release cadence. Hence, it was meant to be used indefinitely. ↩︎


It has been my pleasure 😊. I really appreciate your kind words 🤍.
Absolutely. But, I think it’s nuanced and the lines are becoming increasingly blurry. If something based on Fedora can become something based on Arch (and vice-versa), if almost any distro has multiple releases/channels/braches, if software for/from any distro can be installed on every other distro, then… at what point is it truly “around these parts” rather than “with those not-hardcoded system specifications”? Kinda like how DEs can be (un)installed, and how those come with implications on how some stuff is done…