9fans - fans of the OS Plan 9 from Bell Labs
 help / color / mirror / Atom feed
From: Greg Hudson <ghudson@MIT.EDU>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] Installing the updates
Date: Tue,  1 Aug 2000 14:34:21 -0400	[thread overview]
Message-ID: <200008011834.OAA28649@small-gods.mit.edu> (raw)
In-Reply-To: Your message of "Tue, 01 Aug 2000 09:35:52 EDT." <200008011335.JAA17292@cse.psu.edu>

> 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.


  reply	other threads:[~2000-08-01 18:34 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2000-08-01 13:35 rob pike
2000-08-01 18:34 ` Greg Hudson [this message]
2000-08-02  9:53 ` Douglas A. Gwyn
  -- strict thread matches above, loose matches on Subject: below --
2000-08-02  9:47 forsyth
2000-08-02  9:52 ` Boyd Roberts
2000-08-01 17:06 Russ Cox
2000-08-02  8:32 ` Bruce G. Stewart
2000-08-01 16:27 rob pike
2000-08-02 10:53 ` Ralph Corderoy
2000-08-01 16:26 rob pike
2000-08-02 21:49 ` Steve Simon
2000-08-01 13:06 rob pike
2000-08-01 13:10 ` Lucio De Re
2000-08-01 12:55 rob pike
2000-08-02  9:39 ` Douglas A. Gwyn
2000-08-01  6:04 Russ Cox
2000-08-01  5:42 Russ Cox
2000-07-31 17:09 Russ Cox
2000-07-31 15:57 jmk
2000-07-31 15:15 rob pike
2000-08-01  8:53 ` Douglas A. Gwyn
2000-08-01 12:12   ` Howard Trickey
2000-08-02  9:11     ` Douglas A. Gwyn
2000-08-01 14:31   ` Ralph Corderoy
2000-08-01 16:03     ` Greg Hudson
2000-08-01 16:32       ` James A. Robinson
2000-08-01 17:05         ` James A. Robinson
2000-08-02  9:39       ` Douglas A. Gwyn
2000-08-02  9:11     ` Douglas A. Gwyn
2000-08-03 14:51     ` ozan s. yigit
     [not found] <djhender@telusplanet.net>
2000-07-31 14:53 ` Doug Henderson
2000-07-31 17:38   ` Scott Schwartz
2000-07-31 20:10     ` Steve Simon

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200008011834.OAA28649@small-gods.mit.edu \
    --to=ghudson@mit.edu \
    --cc=9fans@cse.psu.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).