Red Hat, IBM Partner to Certify Apps for Linux
robyannetta writes "British tech site
Microscope has an interesting article talking about how Red Hat and IBM will join forces to help software suppliers certify their applications for Linux. The program is designed to make it easier for suppliers to migrate their software to Linux, and will also give IBM and Red Hat a boost by enlarging the pool of applications certified to run on Red Hat Enterprise Linux with IBM hardware and middleware. Yet another example of creative business foresight that keeps both Red Hat and IBM in the black."
First of all, before we try to make it easier for suppliers to migrate their software to Linux, why don't we come up with some standards for the operating system? Such as where in the heck are files supposed to go? I know there is an FS tree standard... but what about where DLLs are supposed to go? With all the package managers out there, we still suffer from DLL hell.
I think there is something to be learned from the OS that just won't die: BeOS... The file system was sort of like a database. Today, there are all sorts of file systems that support attributes, metadata that is attached to a file but isn't part of it; BeOS leveraged this feature to keep track of the type of files. It didn't matter what the extension was; BeOS kept a database of MIME types for each file. If the MIME type attribute hadn't been set, I believe it would first check the extension, and then the contents of the file, to figure out what the heck is going on. This type of file system could be used to provide ACL-like functionality, along with other great things.
This type of feature could be used to sort out the DLL hell mess that we suffer from on Linux. Because I simply don't understand why trying to install a single application causes so many dependencies that you practically have to pull in all applications that exist for Linux.
So what the heck did we talk about? Solving DLL hell, dependency hell, and using an attribute capable file system to create an OS that people can easily make software for.
I would even say that these problems are bigger (in my organization) than having a better scheduler or proc filesystem. But that's just my two cents worth.