From: "Evan Simpson" To: Subject: Linux Standards Essay Submission Date: Fri, 21 Aug 1998 15:49:29 -0500 1. What are we fighting for? Standardization efforts have been multiplying like rabbits lately, and the objections to these efforts, and to the very idea of standardization, have been fairly thoroughly aired. The case in favor of standardization in general, or in specific incarnations, hasn't been made to my satisfaction, picky bastard that I am, ergo this essay. How could an Open Source *nix standard be truly useful/a good thing? If it allowed more authors to produce more code that runs on more systems with less effort, without causing anyone to lose, that would be worthwhile, yes? Serious effort has already been exerted, and serious gains harvested, in the form of automake, autoconf, standard libraries, and so forth. Where should we go now? That answer to that, I suggest, depends on what's missing. 2. What's missing? What *are* the significant differences among the various Linux configurations? Among all of the open source *nixes (eg. *BSD)? I ask partly because I don't know, and partly because I think that these questions lie at the heart of all the brouhaha over standardization. By significant differences, of course, I mean those which would affect the operation or automatic installation of any software package. I would guess that these would include the platform, kernel version, standard libraries, directory structures, and the available version of common tools and languages. On the other hand, they would not include the way in which the system was installed or what packages came on the CD or were downloaded (major ways in which distributions distinguish themselves). The point here is that I *don't* know, and that I *need* to guess. Is there any one place where the categories of difference (kernel, libraries, /opt, etc) and the existing variations in each category (libc5, glibc; /var, no /var) are all laid out, with detailed notes on how these variations need to be taken into account in an application's code or in it's installation package? If so, is it vigorously updated and maintained? If not, why not? 3. Who cares? Clearly, there are scads of developers who already know how to write code and make .DEB, .RPM, .tgz, etc, etc such that they do the right thing. Did they all learn through trial and error, or from mentors, or from reading the code? If so, good for them, but a clearer trail would benefit both developers new to the game and the community as a whole. More information about how to "run everywhere" would only be the first step, though. It would still mean that every makefile, binary, and package would be bloated with case handling. 4. So what's the second step, smartass? Once we know, clearly, what the significant differences between *nix installations are likely to be, I'll bet that most of them can be (and have been) killed or bridged. How many of them could be eliminated with a symbolic link? By installing a library? By setting up a central /etc file full of variables to eliminate the need to probve the system? Only bug- or major feature-based differences, where one or another alternative isn't generally agreed to be superior couldn't be handled this easily; For the rest, pick a variation and call it canonical. Suppose there were a package/makefile/script/whatever which would not only tell you which aspects of your system weren't compatible with the canonical set, but could automatically create the links, add the libraries, and make the /etc file entries. I'd nab such a thing in a heartbeat, if it let me run applications more and fight with my computer less. 5. You're a Borg, then? FUD thrives on lack of information. My favorite SQLDB, InterBase, was just released, not for Linux, not for *BSD, but for Red Hat 5.0, probably because InterBase Corp's coders weren't really sure whether it ran on Debian, FreeBSD, or even prior versions of Red Hat! Various folks have since shown that it will run on various other *nix bases, sometimes with tweaks, sometimes without. Meanwhile, since there isn't a standard, or "standard deviation" reference, opponents of free, open OSes can say "See - the unix world is fragmented and scary to write for - stick with a REAL OS". I don't want to bully everyone into running Red Hat 5.0, or "Standard Linux". I'd just like to be able to run down a checklist, pull out a recipe or two, and be assured that if the killer app I just wrote (Ha!) meets a configuration it can't deal with, it can fail gracefully and let the user know exactly how they could adjust their system easily and safely with a commonly available tool.