The danger of monoculture
By joe
- 3 minutes read - 487 wordsThose with anti-Microsoft postures might think this will be a missive about Microsoft. It is not. Microsoft will not be mentioned here apart from these two sentances.
The monoculture to which I refer is that of building dependencies upon particular packaging mechanisms in open source tools, or upon specific distributions. We are trying to build OFED-1.x for OpenSuSE 10.2 in order to provide Infiniband driver support to a customer’s cluster. OFED supports RPM distributions, specifically highly specific versions from RedHat and SuSE. Debian/Ubuntu need not apply. Most Linux software uses Gnu autoconf which is annoying and complex IMO. Not as bad as some other tools, but just hard enough to make developers think twice about it. You have to work hard with autoconf to get the right arguments together for your scripts. Once this is done, it can do a fairly respectable job of building makefiles for you. If there are ways to automate this and make it easier/more error free, by all means, help point me towards such a tool. RPM likes autoconf, or more correctly, gnu configure. It is set up to run it. Ok, I am setting up the dominoes to be knocked down right now. When building OFED 1.x on OpenSuSE 10.2 I get
Digging into the error log, I find this
Grrrr….. It is a mis-match between what the code thinks is in the structure and the kernel header thinks is in the structure. I have been told that it is supported in SLES 10, and RHEL4/5. OpenSuSE need not apply. Here is why I think this is dangerous. Designing packages to specific distributions reduces their ability to be used outside of the targeted distro. This reduces the utility of the package, as distro specific peculiarities can impede adoption. Sure Redhat and Novell may like that, but it effectively creates a mono (or bi) culture of packages and applications. Worse, it ties it to specific versions which may not be in use for very good reasons. Say for example applying important patches for security or functionality. This is problematic at best. Ok, now I am going to mention Microsoft. These are some of the aspects of the Microsoft “dictatorship” that are to be admired. A single ABI for MPI. The packages “should” install and work. No, I am not advocating the Microsoft model over the open source model. I am just hoping that the open source model actually gets a bit more open. Update: A kernel update, and a build_env.sh change appear to have solved some set of problems. I will put these RPMs up on our download site. This is BTW, one of the reasons why I think the OSS model is better. I have the power to investigate and change the build environment (while complaining about it online on this blog). Not just to call a support number and hope that it actually will be deigned to be looked at.