From mboxrd@z Thu Jan  1 00:00:00 1970
Message-Id: <200008011834.OAA28649@small-gods.mit.edu>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] Installing the updates
In-Reply-To: Your message of "Tue, 01 Aug 2000 09:35:52 EDT."
             <200008011335.JAA17292@cse.psu.edu> 
Date: Tue,  1 Aug 2000 14:34:21 -0400
From: Greg Hudson <ghudson@MIT.EDU>
Topicbox-Message-UUID: f0cff884-eac8-11e9-9e20-41e7f4b1d025

> but we did expect a Plan 9 program that runs on a 386 to work on a
> SPARC, say, without change, just by compiling it.
[...]
> Show me another system that builds all its software on multiple
> architectures without #ifdefs or config.

I don't see what the big deal here is.  Processor architecture has
never been a big source of portability problems for Unix software.
Software has to actually go and do something weird to uncover a
portability problem relating to the hardware platform.  It's true,
some software does weird stuff (playing fast and loose with
representations of integers, or having native assembly code to speed
up certain operations), but it's not the majority of software and such
software would presumably have the same problems doing those things on
different architectures all running Plan 9.

Portability problems arise mainly from operating systems, not from
processors.

I also don't see what this has to do with multiple include protection
and headers including other headers.  With regard to that issue, I'm
fine with the Plan 9 designers making the choice they made, but it
puzzles me when I see statements like this one:

	It's a terrible practice that leads to n-squared inclusion of
	files, painful overwork by the C preprocessor, and a bad name
	for the idea of #include files in the first place.

which dramatically overstate the (largely nonexistent) problems
resulting from the alternative.