During the last few years, I’ve found a number of people who are consistently thought provoking through the forums at TechRepublic. George and I discussed a few times the idea that we wanted this site to be able to give a voice to people who might not have a venue. Sure, anyone can get a LiveJournal or WordPress blog somewhere, but that does not mean that it will get read, even if it is worthwhile. In an effort to give a good airing to some of these people, I will, from time-to-time, run a “guest blog” post. Today’s guest blogger is Jaqui Greenlees.
The text is complete and unabridged; the only changes I made were some minor formatting, and alteration of some numbering on a list or two.
Information Technology Standard
By Jaqui Greenlees
Information Technology Standards, there are a plethora of them. Very few pieces of software meet most standards that are appropriate for the particular program. Is this an important thing, or should we not care? I think we should care, and that it is important for software to meet the applicable standards, with one notable exception.
What exception? The Linux Standard Base or, more commonly, the L.S.B.[ http://www.linux-foundation.org/en/LSB ]
It is my opinion that they went seriously awry right from the start with the L.S.B., for several reasons.
The F.H.S. [http://www.pathname.com/fhs/ ] File-system Hierarchy Standard has to much leeway in it, allowing for basic tools to be put in different locations. This really does need to be a very specific part of a BASE STANDARD for LINUX to reduce the incompatibilities between the different distributions.
They think that a BASE standard is hardware specific. Since GNU-Linux will work on all hardware, a BASE standard MUST be hardware agnostic.
They went far beyond a base system with it. A BASE STANDARD should stop at the file system layout, and the minimal software to have a system running the operating system with the capability of adding more software.
They specified the A.P.I.s for the shared libraries for C and C++. WHY? Is not this specified already in the ANSI [ http://www.ansi.org/ ] specifications for these languages? Do they think that the Free Software Foundation’s GNU.org projects would change the way their base system utilities work just for the fun of it? The GNU teams do not get paid to make interoperability hard, not like Microsoft’s development teams do, they mostly don’t get paid at all, and WANT to make their products easily used for a long time. GNU development teams won’t change the API’s other than to ADD extra functionality.
Why specify the Executable and Linkable Format of programs, when GNU-Linux was always meant to be a Unix like operating system, and the Single Unix Specification [ http://www.unix.org/ ]already has this format detailed? While GNU-Linux is not a Unix, it is a compatible operating system, with the same File-system Hierarchy, and by default, a very similar executable format. By using the Unix Specification for this, the improvement in interoperability between GNU-Linux and the Unix operating systems applications would benefit all of the Unix and Unix like operating systems.
In short, the L.S.B. went to far, in the wrong direction, and not far enough in the important direction. Currently, the L.S.B. is a poorly written specification for a GNU-Linux DISTRIBUTION, not a base system as the name implies.
Before anyone starts saying put up or shut up on this, I am. I’m currently working on a BASE file system and operating system specification. When it is complete, I’ll publish it on line, and let the Open Source Community decide which one they think is a better definition of a base standard that PROMOTES compatibility between the different distributions.
File System Hierarchy: a quick draft.
/ # the root of the entire file-system.
/bin # basic command line utilities for ALL users.
/boot # boot-loader, initialisation and kernel images.
/dev # device nodes for the system, such as optical drives, hard drives, terminals, network interfaces excetera.
/etc # system configuration files, optionally an application’s configuration can be in a sub-folder of the application name.
/home # user files, in a sub-folder of the user name.
/init # System initialization scripts.
/lib # base system libraries. optionally in a sub-folder of the application name, when the application has a number of libraries specific for it.
/lib/firmware # firmware for those devices that require binary roms.
/mnt # for ALL file systems, including removable devices. Why confuse those coming from Windows with a folder name they expect to contain mp3 and avi files.
/opt # for software NOT included in a distro installer, such as Softimage XSI’s proprietary 3D modeling and animation package for GNU-Linux.
/opt/bin # the place for said 3rd party applications to put their application startup executables.
/proc # that wonderful, depreciated?, place for active device nodes and processes to be stored. Active services excetera.
/root # System Administrator’s documents.
/sbin # system administrator tools
/tmp # temporary files for the system, user’s processes should use a tmp folder in the user folder, since users should not have write access to this folder.
/usr # the entire tree is the biggest part of a file-system specification, the short form is to just define it as holding user accessible programs, and the shared libraries for them. I will add here that /usr/local would not be included, any software that the user wants to install, but not in the main /usr tree should be put into the /opt tree, that is what it is for.
/var # system logs, mailcap and other files that are being altered frequently by system processes.
A Base System Standard definition:
The minimum software required to have an instance of an operating system operational, with the capability of adding more software to suit the needs of the user. This means listing software by types, rather than by name, wherever possible. An example is a default text editor must be included. [ Why anyone would pick as such a tool an overly powerful application is beyond me, but if nuking a mosquito is how you kill one, then by all means use vi(m) or emacs for this purpose instead of the much easier to use for newcomers pico / joe / nano / ... ]
While the capability of adding and removing software is required, and met by compilers and make tools, most people will prefer to use a package manager, this needs to be picked and implemented right from the base system, specially if you are doing a “‘from sources” install. Compliant software packages will include a file in their source archive that contains:
a) Package name and version
b) What the package provides
c)What it REQUIRES to build (this is different, the requires has never been included, causing the “dependency hell” phrase to be used.)
d) A Description of what the software does.
Compliant software will have COMPLETE end user focused documentation included. While this seems terrible for the volunteers creating open source software, the most common issue people have with open source programs is a lack of documentation that helps the end user figure out how to use it. Yes, it is a lot of work, but that just means you will have to place a higher priority on finding and working with a documentation writer.
This standard is meant to define a “Lowest common Denominator” for a compliant system. While the Single Unix specification and Linux Standards Base are a foundation, this standard attempts to address the issues of the LSB, while acknowledging the difference of Linux from a Unix. This standard is meant to promote an easier portability of applications to both different Linux Distros and to true Unix systems.
The scope of this standard’s use is only intended for a base system, any references to software beyond that is only made when the section of the operating system the standard is defining needs to take into consideration that software, in building the base system.