Multiple distros
-> If you routinely have to work with multiple different distros
Consider changing the way you work, and use one. You will save yourself duplication of effort.
Developer Luca di Maio has released version 1.3.0 of DistroBox, a tool to simplify running different versions of Linux in containers. Distrobox is likely to be one of those tools that sounds either great or totally mystifying, depending on the sort of Linux user you are. If you routinely have to work with multiple different …
Agreed.
You don't even need to pick a "good" one. I still mainly use Red Hat Enterprise 6 because I find Mate to be less polished than the Gnome 2 of old, I prefer the old OpenOffice, I prefer the old Gimp, I prefer the old Blender, I basically prefer the older revisions of everything.
However, instead I set up a Debian chroot (via debootstrap) for more recent development tools and web browsers. It basically gets me off that treadmill of losing the bits I like and want to keep using for the sake of compatibility with upstream.
I pretty much do it by minimizing surface area of attack on the host. The only bits of software that go online (or even have access to the network) are the chrooted web browser and ssh. I really don't need anything else (git and cvs run within the chroot utilizing ssh). Since the chroot is running a recent Debian packages, gnutls, crypto and ssl libs are all recent. Most of /dev is also inaccessible too.
For example `ss -tulpn` reports no listening ports (avahi, cups and all that cruft). I don't really trust them anyway, even on an up-to-date system. Since X11 is managed by a non-networked UNIX domain socket for a long while now, I simply ln (non symbolic) the socket descriptor into the chroot and set permissions. It can be as old as heck but is completely inaccessible to the outside world.
My theory is that an effectively offline Windows 95 PC will always be more secure than a fully up-to-date albeit connected, always online Linux system. So I go a middle ground between the two :)
Your points are valid, but they are also symptoms of the differences between distributions. Developing for Linux is 100 times worse than Java. Not "write once debug everywhere", but "write for every distribution you want to target and debug everywhere". It is a waste of time.
I use two.
Slackware for both "real work" and day-to-day.
Debian (w xfce desktop) as the second-boot option for laptops; it is slightly more likely to "just work", and for the basics (mainly web, ms teams, and some ad hoc games stuff; not my full suite), it is much easier to install & use without thinking.
There isn't much duplication because the way I use Debian requires very little effort at all.
"Consider changing the way you work, and use one. You will save yourself duplication of effort."
Different products for different use cases.
Devuan for most family laptops.
Devuan also for the NextCloud Pi,
Mythbuntu for the MythTV box.
OSMC/Kodi for the Pis bolted on the back of the TVs.
Mint for the old laptop for which full-size Devuan is getting too big.
Zorin for cousins and anyone else moving from Windows.
Android for the phone.
One size does not fit all.
[Author here]
It may not be an option. I don't think you're trying hard enough to envisage the usage scenarios here.
For instance, I can see this being very useful indeed for app developers. Build and test on multiple distros very quickly and easily without needing to spawn VMs.
Or for users of non-glibc-based distros, to run Chrome or Skype or other proprietary apps.
And the one I mentioned: for immutable OSes, it gives you an easy way to install and run your own native packages. As I have said before, immutable OSes are very probably the future of most commercial Linux distros, and it's the handful of commercial ones that pay for the R&D that sustains the entire ecosystem.
It still sounds like the most pointless thing since "How to speak French" was translated into French.
Nothing is unique to any Linux distro, by design. If there is a configuration tool from another distro that you like, there is nothing stopping you from downloading the Source Code and building it on your own favourite distro.
Well I think somebody should also translate "How to speak English" into English for the English and also "How to understand English in England for Americans", but more to the point.
I am very annoyed I am not as keen to test all available linux distros as before, but if I was, then I have no doubt there was use for Distrobox, and if not, then it would not exist.
Humm, perhaps I will try it.
Heh. :-) That's a good question!
Containers don't involve any hardware magic or anything, so I suppose that yes, you could do this, and in principle, ½ dozen layers should not impose any particular performance overhead or anything.
Good luck trying to cut-and-paste from one to another, though...
Quote: "If you develop or manage software that runs on Linux, you have to allow for these differences, which means a lot of testing and switching boxes and distros."
....puzzled old fool here.....but I didn't think that someone writing stuff in Python (or Perl) needed to bother with this.....
....someone can explain what sort of development/delivery requires testing on multiple distros.....maybe C or assembler?
[Author here]
I can think of many examples.
What if you are working in Ubuntu 22.04 but you want your app to run on 20.04 and 18.04, which have different versions of Python and Perl?
What if the path to the interpreter is different on Ubuntu and Fedora?
What if Ubuntu includes a Python package that Debian does not?
What if you rely on a GCC optimisation that GCC11 does but GCC10 does not?
What if you work on Fedora, but you are describing RHEL? Or work in openSUSE but are describing SLE? I have worked for both Red Hat and SUSE and I can attest that this is how most staff actually use their own work computers.