Date: Thu, 20 Aug 1998 09:14:29 -0700 (PDT) From: "Jakob 'sparky' Kaivo" To: malda@slashdot.org Subject: Essay on Linux Standards Rob, This is in response to your 'Call for Essays on Linux Standards'. I've always been of the mind that standards, for the most part, are good thing. Sure, competition breeds ingenuity (see KDE vs. GNOME), but standards breed compatibility. For instance, if there was no standard for the world's phone system, it would be difficult at best to call someone across town, and downright impossible to call someone across the ocean. So why does Linux need standards? Why indeed. Some people suggest that FSS is all we need, and then use autoconf/automake to configure the software for your system, it will find the necessary libraries. Fine, that works. For the people that have all the necessary software installed (i.e., GCC, autoconf, make, development libraries, etc.). But what about Joe Average Linux user, fresh from Windows 95/98/NT, who's been set up on a Linux system /without/ development tools. OK, so he installs the development tools from the CD (after maybe a week of trying to figure out how, remember, he's a newbie). Suddenly, Joe's hard drive is very low on space, and he doesn't have room to untar and compile that new GNU Office Suite (or Emacs, or some other hideously large package). All that development stuff took a lot of space to install. So, after another week or so, he figures out how to remove the stuff he just installed, and goes and finds a binary of the program on sunsite. OK, now he tries installing again. It seems to install fine. He goes to run the program, oops! That program requires version X.yy.z of library ABC. His distribution ships with version X.yy.q, even though all the others have X.yy.z. Now what does he do? He has to figure out how to get the new version of the library. Now, consider the example of a Linux Standard, specifying that all distributions that include library ABC have at least version X.yy.z. So, Joe can just start by grabbing binary package from the distributor's site (they can do this easier, since all distros have the same libraries), run the install script (which calls the appropriate package manager, since there is now (probably) a standard packaging system), and it just works. Which do you think is more likely to make Joe stay on Linux and not go back to Windows? Binary compatibility is what LSB/LCS is really all about, making sure that a binary compiled on one system that conforms will work on all other systems that conform. Then you don't need to have a separate RedHat RPM, Caldera RPM, Debian package, and Slackware package (and Stampede, and SuSE, and ...). You have now just a couple of packages: source (for those who really want/need it), an i386 package, an axp package, a sparc package, an m68k package, etc. One package per CPU architecture, not one per distribution. Remember, this is something that Windows already does, better than Linux. A single binary will work (unless it uses one of the few OS specific things) unmodified on Windows 95, Windows 98, and Windows NT on i386-series processors. The other half of Linux standardization is source compatibility, which we mostly have now, but could be better. Being the self-declared guy checking LSB/LCS vs. UNIX 98, source compatibility is something that is really important to me. It is important for the things that are distributed as source that they can expect all Linux distributions to have this system call and that symbolic constant, without having to use autoconf. Autoconf is a great tool, but it is only necessary because of the splintering of the *NIX world. If we can keep Linux UNIX 98 compliant, or at least document the differences, your source can use all UNIX 98 calls and compile out of box, without modification or autoconf, on and Linux or any UNIX 98 system. If there are places where we choose to diverge from UNIX 98, they would be well documented, and can be taken care of in source with a simple #ifdef LINUX or similar. Perhaps the most important thing to remember for the LSB/LCS is that the standard itself, and all required components, must remain as free as the Linux kernel. This is one place where we will definitely diverge from UNIX 98. The Single UNIX Specification (I believe) requires either Motif and/or CDE, which would be contrary to the nature of Linux, so we won't require it. Unfortunately, this keeps KDE from becoming the standard desktop, unless it is rewritten for a different toolkit, or qt is rewritten. I say unfortunately because KDE actually is pretty nice. GNOME is also very nice. I think in the end GNOME will win because it is completely free. However, I think that is out of the current scope of the LSB, although I see a point in the future where the LSB would expand to include different specifications, such as the absolute base, the workstation base, the server base, the graphical base, etc. For now, we are concentrating on standardizing of the libraries that basically every program uses. I hope we are able to get everyone to cooperate, and have the ability to run Linux programs on a single Linux, standard across distros, with each distro being able to on top of that cater to its own audience with its own peculiarities. +-----------------------------+--------------------------------+ | Jakob 'sparky' Kaivo | jake@nodomainname.net | | NoDomainName Networks | http://www.nodomainname.net | +-----------------------------+--------------------------------+