...or too few resources?

...or too few resources?

Posted Jan 19, 2008 0:55 UTC (Sat) by jd (guest, #26381)
In reply to: Too much choice by khim
Parent article: Fedora developers on PackageKit

I agree with the sentiment, but not with the problem. If the binaries are statically linked or the libraries are provided and installed if not already globally provided (using LD_LIBRARY_PATH or one of the other loader tricks to use local libraries where you need to force a version), you can indeed provide one installation that will work on every distro.

Or you could compile to a shim layer and provide a distro-specific abstraction layer or shim. The advantage of this approach is that you would then have one x86 binary for all x86-based operating systems, using really just an extension of the IBCS module idea and the WINE approach. Then a port is nothing more than adapting an existing shim and compiling that shim. The program itself would only ever be compiled once per version. Likewise, a change to the application would only require recompiling the application, the shims would not be affected.

A third option would be for ISVs to more actively adopt the approach of licensing out building for commercial distros, so that they only have to focus on a very narrow range of builds for systems they want supported and which can't (for whatever reason) support themselves.

What do all these three things have in common? They tie up resources. The first ties up much more disk space and much more bandwidth. The second ties up a considerable amount of additional manpower. The third ties up money. They are all perfectly achievable, but only if someone invests the resources needed. No resources, no transparent multi-platform support.

People provide the multiple installation packages, then, not because they have to but because they have decided that they do not wish to invest the resouces in any of the alternative solutions that exist. It is a choice, not a requirement.

As for the package builder packages - we really do have enough of those, I think, and we have far too few abstraction libraries that can reduce the need for vast numbers of differently-configured packages. Again, not because it's impossible, but because that's not what people are developing. Package development kits are the right solution if, in fact, packaging is the right problem. Even a perfect solution is only helpful if the actual, underlying problem is something in the class of problems the solution is designed for. I have always been convinced that this is, in fact, the wrong problem, which is why none of the solutions end up really solving very much.

Of course, this entire line of reasoning only applies for code that can be made portable by correctly designing and implementing it. Some code is inherently non-portable, because it relies on too many highly implementation-specific details of what it is working with. In other cases, a portable solution is possible but so sub-optimal for any system that it is no longer worth using.

Anything that is not in those two categories can be written and compiled for a specific instruction set and word size. (And endienness, in the case of MIPS processors, as they can be switched at boot time.) Everything else can be hidden from the program, making it unnecessary for the program to know anything else.

---

(Log in to post comments)

now there is one. Debian and Ubuntu have diverged their repositories far enough so that it's
not easy to install .debs between them (however it's still not hard to rebuild them from the
source). Earlier, the same could be said about Debian vs Stormix. Overall, as the policy
becomes less strict and less centralized, the hell ensues.