The free software movement needs to get away from Unix

Francois-Rene Rideau
29 Jun 1998 21:33:07 +0200

The following message is a courtesy copy of an article
that has been posted to gnu.misc.discuss as well. (Jason Stokes) writes:

> Most importantly, Unix is traditionally implemented in C.  This means
> that the bulk of free software development is also done in C, not just
> in the operating system itself but in the vast range of software done
> for the Unix operating system.  But C is a deeply flawed language that
> has been critiqued endlessly by users of more developed languages.  C
> has given us entire *class* of bugs that have achieved that status of
> classics -- from buffer overruns to memory leaks.  Writing in C makes
> free software difficult to understand for those not inducted into the C
> priesthood and encourages an unhealthy 'C hacker' mentality that prides
> obscurity over robust, maintainable software.

The problem is not that Unix be *implemented* in C: it could be implemented
in PL/I, COBOL, or Visual Perl++, that'd be just the same
(well, from everyone's but the implementer's point of view).
The problem is that the Unix *interface* is *designed* over the low-level
semantics of C, that is, of a coarse-grained low-level single-threaded
von-Neuman virtual machine with explicit memory management.

Because the design is so low-level, any added feature necessarily
*interferes* with every other, and cannot be added in an orthogonal way.
Because it is coarse-grained, incremental improvement is not possible.
Because it is basically single-threaded, any attempt to do multiprogramming
has to deal with hellish explicit management of interactions between
virtual machines. Because memory management has to be explicit, a whole
class of bugs appear that make everything very unstable, and prevent
reliable implementation of such features as persistence, migration, etc,
and increase the overall cost of combining and maintaining
independently developed modules. Moreover, modules can only share globals;
there is no notion of namespace and lexical scoping in C, which induces
clashes and is a break to free development of uninterfering features.

The problem is, C is a (passable) low-level language,
and it's being used as a (very bad) high-level language,
because it has been made "the standard".
We end up with C as a lowest common denominator for interaction of programs.

Unix copes with the unstability of a C-based system, by a tradition of using
text streams as a human-readable interaction format between programs
(but without any standard text representation; just a strong preference
for line-oriented stuff); it adds lots of crufty, special purpose "scripting
languages" with coarse grain of usability, to allow users to actually do
things, by manipulating text.

Win* and Mac*, whose interfaces also depend on low-level C-like semantics,
instead choose to not cope with unstability at all, and just crash.
They do not allow users to do things, unless specifically enabled
by software developed by M$ or Apple, or hacked by third parties.

Actually, the need for a low-level interface is necessary
in a world of proprietary software: at some point, any and all programs
must access the hardware, and if you don't provide sources to recompile,
so you must have a low-level interface somewhere, anyway,
and all distributed software must sit on it.
Existing proprietary systems still make the mistake of writing
*every interface* in the low-level system instead of making a clean
separation between various levels of interfaces that would allow
for easier upgrade of low-level components.

Now, a free system doesn't have such requirement of providing
a low-level interface in which all distributed software be defined.
All the contrary, the GREAT ADVANTAGE of a system based on free software,
would be that distributing high-level programs is possible,
because they can be recompiled and reoptimized by a whole bunch hackers
with the help of lots of tweakable tools, everytime they have to migrate
to a new environment. This should make modification of the underlying
environment easy, and induce performance and feature gains undreamed of
in a low-level proprietary setting.

Just as an example, if programs were distributed as sources in a
real high-level language, they could be recompiled on-the-fly to take
advantage of every parallel platform (whether SMP, or distributed, etc)
where someone would care to install them.
Because the geometry of parallel platforms is subject to sooo many
differences with completely different performance tradeoffs,
proprietary systems, as well other systems (such as free Unices) based on
monolithic low-level programs just cannot provide distribution
of binaries that adapt to parallel computing platforms at large.

> Don't get me wrong.  Unix's design is far superior to something like
> Windows NT.  But Unix itself is inferior to any improvement you can
> think of.  We need a completely new, end-user focussed operating system
> which includes the power and best features of Unix and other current
> operating systems.

It needn't be new: if they weren't proprietary, LISP Machines could
have done the job pretty well. They may be somewhat outdated, at least,
they are a design of the 1980's, not a design of the 1970's like UNIX.

Now If you want a complete rethink of what an OS should be like,
you may be interested in a project like TUNES <>

> Alas, I think that we are likely to be stuck with
> Unix for quite some time to come.  [...] conservatism [...]
> At the very least,
> nothing will ever change if the current generation of Unix users don't
> even recognise the need for change.

True enough.

## Faré | VN: Уng-Vû Bân   | Join the TUNES project! ##
## FR: François-René Rideau |    TUNES is a Useful, Not Expedient System     ##
## Reflection&Cybernethics  | Project for a Free Reflective Computing System ##
I can't speak english, but I pretend so well, that no one ever figured out
that I am speaking a completely different tongue, and that my sentences have
a meaning completely different from the one people think they have.