Standard interfaces

[Alex Nicolaou]

Angelo Schneider wrote:
> Alex Nicolaou wrote:
> > Yes, standard interfaces of any kind, and the software that implements
> > them, are inherently unfree.
> 
> What, if not a standard interface, is the glibc?
> If you improve glibc you will certainly keep the calling conventions
> and the parameter types of the standard c functions, wouldn't you?

Please open /usr/include/stdlib.h from a GCC distribution and search for
__USE_GNU, __USE_BSD, __USE_XOPEN_EXTENDED, etc. Or just read the file.
You'll soon find that the file is filled with variations, in some cases
to accomodate other standards, and in other cases simply to provide
better ways to do existing tasks (see especially __USE_GNU and
__USE_MISC blocks). So, glibc is a de facto standard interface, but it
clearly attempts to provide a superset of ANSI C. Supersetting a
standard is not conforming to it, it is "improving" it.

To a large extent, this variety was forced on gcc by the enourmous
number of variations in stock C compilers in UNIX distributions
everywhere (once upon a time you would buy a UNIX machine and it
actually came with the vendor's C compiler, as opposed to requiring a
several thousand dollar add-on). However, not all of the changes fit
this mold; a number of them reflect a desire to "improve" things that
probably would be better improved by providing separate libraries
instead of extending glibc itself.

> Linux and the GNU Project would not exist if they would not agreee on
> somewhat fixed standards. You can extend the interfaces and standards
> by adding more interfaces or by making changes which keep compatibility,
> but you certanly can't change the arguments to fprintf() or fopen()
> or popen() or what ever without getting into a lot of trouble!

Linux and the GNU Project exist because they co-operate on some de facto
standards: the use of GCC as the definition for the language that the
Linux kernel is written in, and the kernel interface expected by GNU
software applications, which is provided by the Linux kernel. Just try
compiling the Linux kernel with an ANSI C compiler. You'll probably wish
to start by editing init/main.c and removing the check for the version
of GCC.

However, the Linux kernel developers are against standard interfaces
inside the kernel. Every few months, an enormous debate erupts between
the core kernel developers and the device driver developers over changes
in the kernel's internal API that break all of the device drivers. The
device driver developers get angry because the kernel developers simply
apply the change with a sed script and the driver breaks, or perhaps
they don't apply the change at all and the driver no longer compiles.
The kernel developers claim that the reason the kernel stays small and
lean is that they change the interface when needed and everyone better
be prepared to keep pace or drop out of doing Linux development. Don't
take my word for it: look for various versions of this argument in your
favourite l-k archive!

> > The fact that some people have sympathy for the de facto approach
> > towards standards can be seen in the support for Microsoft in the
> > Sun-Microsoft suit over Microsoft's implementation of the JVM: the
> > statement of many is that the "market should decide" and there is
> > support for the idea of simply seeing which standard survives as the
> > definition method of choice.
> 
> The market follows always short term considerations e.g. the price.
> But technology is not pricy when it is brought to market. Only hughe
> companies can effort to develop a new technology and place it for free
> or nearly free on the market. (MS vs. Netscape!)
> Standards which are build upon market decisions are not as valuable like
> those which are build up from industry consortiums (e.g OMG, POSIX).

I think you missed my point. I'm not saying standards are good or bad,
or that de facto standards are right or wrong. I'm saying that the fact
that people defend standards generated by competition in the market
place is evidence that some people accept the idea of de facto standards
and reject official standards. For a different example of the same,
consider that people routinely speed by 10 kph on the roadways, and by
20 kph on the highways. This is because they understand that the police
won't bother to enforce the speed limit on them (the official standard);
so there is a de facto standard about how to drive and people follow
*that* standard in preference to the official one. Developers are no
different: if they can do their work with a de facto standard and ship
sooner, they do. That's why Sun sued Microsoft: because Microsoft seeks
to take advantage of this type of anti-standard behaviour so that they
can take over the job of defining the actual, de facto, standard in
place of the official standard.

The bottom line is that standards are an obstacle to freedom. If freedom
is the primary right, then standards are only preserved at the suffrance
of the users, who are free at any time to stop conforming to the
standard if they think that that is better. I think that there are many
examples in the GNU software world where the software has been
"improved" rather than conforming to the standard. To this day I hate
operating "info" and curse the person who decided that man pages were
not good enough; but there you have it: a better way was chosen over the
standard way, because standards are an obstacle to progress.

alex