One thing that I don’t like mentioning but you have to be careful of is that the companies behind Linux distros may not always have truly modularizing Linux software in their best interest. If they wanted to be mean, they would try to prevent any software on their systems from being modular so that users would be forced to install their OS to have access to certain programs. Of course, that’s ridiculous, and things shouldn’t be that way. Not to mention, by embracing things like that, if any of them are, they are shooting themselves in the foot since Linux needs all the mutual help and working together it can get, and there’s just so many ways that making software installation easy will solve. Linux adoption will take off so much faster after this is solved for too many reasons to list here. All we need is some point of standardization, SOMEwhere, like most all the package managers being able to use all the different package file formats, or being compatible with a new format or better yet, a container format for packages. The Berlin API sounds like it will be the best solution by far, though.

To JJS: I’m not suer I follow the problem, the LSB sounds really good to me as long as they make it easy to see which non-common libraries aren’t included in it, so you can include those with your program. They definitely need to make this process easier for you, it sounds like. Any libraries which get really heavily used can be added in later LSB revisions of course. When downloading packages from websites, they could contain a URL for automatic updates, and check to see if any of the libraries were already installed to reduce wasteful downloading.

A good goal would be to have there be no need for a distro to have a repository. Instead, there could be one repository if you wanted there to be, the Linux software repository. But of course that wouldn’t happen and there’d be multiple ones still or at the very least multiple mirrors. The Sourceforge repository, Freshmeat, Download.com, etc etc.

Any way, I definitely don’t think your method of continuing to do things the way they’ve always been done is at all realistic. We don’t want to compile packages for specific distros, vendors can’t and won’t do that nor is it at all fair to users running distros that are lesser-known. We want programs compiled once, and have them run on all Linux distros. All it takes is a small commonality in all package managers or on all distros to give users the ability to install any kind of package. That’s what this post is about, and it’s what we want and need.

No problems are impossible to solve, and this one in essence is very simple, it just needs a modular, flexible, expandable solution so that it can adapt to new software and new libraries and the future while allowing previous software to continue to function. It CAN be solved, and it will be, and without any detriment to anyone. Even talking about performance issues, I don’t believe deep integration is the key to performance and definitely not helpful for software modularity. I believe programs can be very modular while still very fast, it just depends on how well they are programmed.

Any way, go standard API to release us from this locked-up limited software prison!

I used to support the Linux Standard Base (LSB) initiative, but have come up against far too many of its limitations. The LSB basically addresses compiled programs with no interfaces to other applications. Here are some of the issues that it cannot resolve:

- Libraries: My biggest complaint with the LSB is that it is a ‘thou shalt not’ specification. The allowed base libraries provide support for only the most trivial of programs. The “solution” is to compile excluded libraries into programs statically. This requires the developers to research the libraries and insure that all of their excluded dependencies are statically linked. I will leave it as an exercise for the reader to come up with at least 5 ways that this approach drives developers away from porting applications to Linux.

- Interpreted languages such as Perl, PHP, Python, or Java: There has been no definition for these at all, and although the most recent version added Perl and Python, the definition takes the same ‘thou shalt not’ approach as with libraries.

- Databases: Again there is no definition for which one or the minimum version required.

- Startup: The definition defines what an init script must provide but does not explain how it gets installed to be available at system boot.

- Application documentation: No mention.

- Security/bug fix updates: No mention. In fact, the underlying philosophy of the LSB would create an environment where each vendor is responsible for providing an update method, leaving administrators with the responsibility of hunting down announcements (like that of the Microsoft platforms), and ruining one of the best features of Linux distros.

Compare this with the most prevalent package management systems, DEBs and RPMs. These take a ‘Yes you can’ approach, and even a ‘Perhaps you would also like’ attitude. They allow the packager to define everything that is needed for the application, including minimum versions, without having to worry at all about the details of installation. They provide automated update facilities. And when creating a Debian package, the ‘lintian’ utility is run to verify its correctness and will call out programs that do not have man pages among other things (I haven’t built an RPM so I can’t speak to its requirements).

For over a year now, I have been advocating that a utility for developers to easily create packages for specific distros (such as the ESP Package Manager at http://epmhome.org/index.php) and repositories for developer maintained packages be supported by the distros. This would allow project teams or vendors to include their applications in the ecosystem of the distro package managers, which I believe is the best, if not only realistic, method of handling installation issues in Linux distros.

Later . . . Jim

The Realeyes IDS, check it out at:
http://realeyes.sourceforge.net