The Inner and Outer Repos
cover image by Dietmar Rabich, CC BY-SA 4.0
Your software options might change a little when using Linux as opposed to Mac or Windows. The software you used before might not be the best option on a Linux platform. Some developers just refuse to make their code Linux compatible. Other Linux distributions might package one solution but not another. Regardless, finding and installing the right software for your project on Linux is not all that difficult when you know about all the various package repositories available to you.
Of course, the repository provided by your distribution; In my case, those maintained by Arch Linux; is the primary source of packages on your system. Always go through the official channels first. If we were looking to install the popular Java IDE, Eclipse, instead of going to the developer's website to download an installer, we would use our package manager (Eg., apt search eclipse on Ubuntu, yum search eclipse on Redhat, pacman -Ss eclipse on Arch, zypper se 'eclipse' on SUSE, or emerge --search eclipse on Gentoo).
Also, keep in mind that on many 64-bit distributions, the 32-bit side of the repositories are not enabled by default! If you can't find something on a 64-bit machine, make certain the package doesn't depend on 32-bit code! If it does, you will need to enable those repositories. The way you do so varies from one distribution to the next.
Even if the official repositories don't have what you are looking for, there are often alternatives. I'm talking about platform-independent package managers like Flatpak, Snapcraft, Steam, and Homebrew. This way the package and all its dependencies are contained and documented. "Why not just," I hear you protest, "use this other repository? Or download the package in my browser?"
Package management provides stability. When you go outside the official repositories, you can run into some serious problems. The maintainers of the official repositories make certain that everything that works together in the repository actually works together. And when packages don't work together, their package managers can tell you so. We cannot be certain that an unofficial repository or package will be reliably maintained in lockstep with the rest of the system. We can, however, be reasonably sure that whatever that package does to the system will not be supported by the official maintainers. In other words, if the package breaks, you and whoever works on that package are on your own!
So, when the official package manager doesn't have what you are looking for, don't immediately resort to adding unofficial repositories, installing from the source, or packaging the software yourself. It's a way better idea to get another, platform-independent package management system offered by your system that does. That way, those packages are contained and easily managed from the safety of the abstraction that is package management.
Only when it is clear there is no reliable way to get the packages you need, do you resort to unofficial channels. At that, a standalone installation is generally more stable than installing to the system proper.
Top comments (4)
Yet another topic I need to pick your brain about, Nica! Curious specifically about the reasoning behind some developers "refusing to make their code Linux compatible" — is this most often due to a (real or perceived) concern about DX/intuitive development environments?
I think the short version is that there's very little incentive to compile software packages for every environment. Some of the packages that people rely on every day are maintained as small sidelines by their original developers with little or no financial support from anyone. If anyone else has a theory about why this happens, I'm all ears :)
Very well put!
In my experience, the ability to maintain standalone installations -- which coexist with the system packages seamlessly but don't modify them in any way -- is an extremely valuable skill, and ultimately leads to a deeper understanding of software engineering, compilers and build systems, dynamic linkers, and many more rich and deep areas of UNIX systems lore.
I think a great challenge to get started on this path is to get used to using Homebrew, or similar, without ever entering a root/sudo password. That's probably the easiest way to make sure you're not accidentally overwriting your system's curated packages.
Great post!
I never knew Steam was a package manager...