Re: [9fans] Plan9 development

[Dan Cross <crossd@gmail.com>]

On Sun, Nov 14, 2010 at 11:29 PM, Gary V. Vaughan <gary@vaughan.pe> wrote:
> You can either try to remember what all of those are, or use something
> like autoconf to probe for known bugs, and gnulib to plug them, or
> you can link against a shim library like GNU libposix which will
> do all of that automatically when it is built and installed, allowing
> you to write to the POSIX APIs with impunity.

I've read this discussion with interest.  Something that strikes me is
that there are certain underlying beliefs and assumptions in the Plan
9 community that are taken for granted and rarely articulated, but
that frame many of the comments from 9fans.  Further, those are, in
many ways, contrary to the assumptions and requirements Gary is
constrained by when working on libtool.

I believe that one of the most powerful decisions that the original
plan 9 developers made was consciously resisting backwards
compatibility with Unix.  That's not to say that they completely
ignored it, or that it was actively worked against, but that it was
not a primary consideration and did not (overly) constrain either
design or implementation.  This freed them to revisit assumptions,
rethink many of the decisions in the base system, and clean up a lot
of rough edges.

For instance, and relevant to this discussion, take a look at how
cross-compilation and platform independence on Plan 9 "just works" in
a simple, consistent way across multiple architectures.  I was
surprised how an earlier message in this discussion when Gary said,

> If you have never tried to build and link shared libraries from the same
> code-base on 30 (or even 3) separate incompatible architectures, then
> you are probably missing the point, and needn't read any further.

Granted, I think the key thing here is that Gary's talking about
shared libraries (which, as Russ said, the Plan 9 developers simply
punted on), instead of just building, but I can't help but feel that
this overlooks part of the plan 9 way of doing things.

The plan 9 developers made a decision to break with the convention of
naming object files with a ".o" extension, assigned a letter to each
archicture, established the convention that object files and libraries
would use that letter in their filenames, and renamed the compiler,
assembler and linker accordingly.  Then they modified the filesystem
hierarchy to have archiecture specific directory trees for
architecture specific things (which is easy to do with you've got
mutable namespaces).  Mk was smart enough that these conventions could
be used in the build system pretty easily.  None of these are name
changes are particularly deep; in many ways, they are simply cosmetic.
 However, they led to a simplification that makes building for
different architectures out of the same tree nearly trivial.  Just by
setting an environment variable, I can build the entire system for a
different architecture, in the same tree, with a single command, with
no conflicts.  Since the compiler for each architecture is just
another program, cross-compilation isn't special or complicated.
Compare this to setting up gcc for cross compilation.

And that's sort of the point.  9fans tend not to ask, "how can I make
this work across multiple systems that are immutable as far as I'm
concerned as a developer" but rather they ask, "how can the system
support me doing this in a simpler, orthogonal, more consistent way?"
If that means shedding some convention and replacing it with something
else that makes life easier, there's less hesitation to do that.

To that end, libtool, autoconf and automake, etc, all seem to answer
the wrong question.  From the 9fans perspective (and take this with a
grain of salt; I can't claim to speak for all of us), libtool seems
"crazy" because it puts a bandaid on a wart instead of trying to solve
the underlying problem of complex, inconsistent interfaces across
systems.  In this way, it is reactionary.  Autoconf et al are
analogous to a bunch of nested #ifdef's, and most 9fans would chose to
program to some sort of shim library that provided a consistent
interface as a matter of course.  Better yet, they'd go fix the
underlying systems so that they correctly implemented the relevant
standard or interface.  I'm not sure that's possible with Unix, as
Gary rightly points out, because of the weight of the installed base,
fragmentation between variants and the requirements of backwards
compability.  Though unrealistic, it's certainly idealistic.

One of the enduring benefits of Plan 9 is that it is (still) a good
example of how well-reasoned engineering tradeoffs and a modicum of
good taste can produce a powerful and elegant system with a simple
implementation.  Rob Pike is (in?)famously quoted as saying, "not only
is Unix dead, it's starting to smell really bad" (note to Rob: is this
apocryphal?  I've never found an original source).  I think that's
often taken out of context; Unix may be dead as an exciting venue for
the exploration of fundamentally new ways of doing things, for all the
reasons that have been mentioned.  That doesn't mean it's not useful
for getting real work done.  In this sense it's more like a large
wooden support beam; it's dead in the sense that the tree it came from
(presumably) isn't growing anymore, even though the beam serves some
useful purpose.  Libtool is more inline with this view of the world.
It facilitates divergent systems doing useful things (in the sense of
end-users finding those systems useful; my mom could care less what
hardware and software platform gmail runs on, as long as she can
communicate with family and friends).  It fits the world view of the
massive number of developers who are already familiar with the Unix
and Linux model and who aren't particularly interested in other
models.  But it's not exciting as tool for figuring out how to make
those systems better in and of themselves.  The assumptions that 9fans
make are that the latter is more important than the former.

Sorry, this was long-winded.

        - Dan C.