What does “path-agnostic applications” mean?
“Path-agnostic” means: you unzip (or untar, or whatever) the application install package… wherever you want on your filesystem… and it works!
What do you mean? Isn’t that the norm?
This sounds outright boring and “duh” and obvious. It should always work like that, right?
But it doesn’t. Not on Linux, anyway. The norm in Linux systems is that things have to be installed at specific paths and that those paths are determined at compile time (meaning: the install paths are chosen by someone who is not the user doing the installing).
Why does this matter?
Path-agnostic applications are much easier to use, and much easier to distribute.
- As a user, you just unpack them, and they are ready to run.
- As a user, you can also choose to just “drag and drop” the application to any install path you want. It’s your choice. Total freedom. Organize things however you want.
- As a developer: being free of system install path strictures means you can “package once; ship anywhere”. It means your work is highly reusable.
If you look at it the other way — what happens when we don’t have path-agnostic applications — the value is clear:
- Putting the choice about installation path in the hands of the builder, rather than the user, is just plain strange and wrong. It makes no sense.
- When installation paths have to share one global namespace, it means collisions can happen. (In other words, Goal: Co-installability can easily be violated.) Combined with the issue that the install path choices are made well in advance, this means when Person A sets up a computer, they can end up with a system that’s un-workable because of choices of Person B and Person C, even if none of them have met before.
- When organizations are formed in order to combat that collision problem: now these organizations become bottlenecks, and are a home to “bikeshedding” discussions. Ultimately, the result is several different organizations, who maintain slightly different name-collision-avoidance models… which also happen to prevent applications shipped in one system for working in another system. (E.g.: the path to shared libraries on Debian and RedHat is different… etc. The path to shared libraries on NixOS and Guix are also different!) This becomes a balkanizing force that prevents collaboration and sharing, and makes more work globally, while resulting in less reusable packages.