From: erik quanstrom <quanstro@quanstro.net>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] impressive
Date: Tue, 9 May 2006 19:45:42 -0500 [thread overview]
Message-ID: <2256501d5763ca7585ed7c8a52da5efd@quanstro.net> (raw)
i think your problems miss the point. an explicit portability layer
is another name for a virtual os interface. breaking things
up on a call-by-call basis creates calls^2 virtual os interfacen.
good luck in testing.
of course the simple virtual interface is usually too simple to express
what the autoconf guys are really after, so they add a level of indirection.
the ironic bit about autoconf is that the vast majority of autoconf garbage
is dedicated to features that don't make any difference. using the
lowest-common denomitor call would work just as well. (and why
not, you have to code this case anyway.)
it /is/ possible to make stuff portable across many different posixish
systems with very little code. p9p really does a nice job. there's some
glue, but that's mostly for the thread library and some networking goo.
most projects don't need to get that friendly with the hardware.
- erik
On Tue May 9 16:57:15 CDT 2006, davide+p9@cs.cmu.edu wrote:
> The "old way" was to create an explicit portability layer,
> with the application running on top of that layer and
> one version of the layer for each platform. So each
> application would need one expert to maintain the SunOS
> blob, one to maintain the HP-UX blob, etc.
>
> The autoconf approach (following perl's pioneering
> configuration infrastructure) was based on the observation
> that the 1995 version of the SunOS blob and the 1995
> version of the Irix blob looked somewhat like each other,
> especially in the sense that if you looked at the 1998
> version of each the underlying platforms had added many
> of the same features. Also, if you looked at the SunOS
> blob for one application and the SunOS blob for another
> application, they would of course share many similarities.
>
> So the theory was to ignore platforms and start testing
> for *features*, and the hope was that once a *feature*
> had been coded for platforms would add the feature over
> time and all software using autoconf would automatically
> start using the feature. Great!
next reply other threads:[~2006-05-10 0:45 UTC|newest]
Thread overview: 69+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-05-10 0:45 erik quanstrom [this message]
2006-05-10 2:09 ` Lyndon Nerenberg
2006-05-10 3:35 ` David Arnold
2006-05-10 4:03 ` Lyndon Nerenberg
-- strict thread matches above, loose matches on Subject: below --
2006-05-08 22:02 erik quanstrom
2006-04-27 2:13 erik quanstrom
2006-04-27 1:35 erik quanstrom
2006-04-27 1:23 erik quanstrom
2006-04-27 5:08 ` Micah Stetson
2006-04-27 1:10 erik quanstrom
2006-04-27 2:06 ` Jack Johnson
2006-04-26 3:24 jmk
2006-04-26 2:38 erik quanstrom
2006-04-26 0:55 erik quanstrom
2006-04-26 1:07 ` Roman Shaposhnick
2006-04-26 0:26 erik quanstrom
2006-04-26 0:48 ` geoff
2006-04-26 0:54 ` Roman Shaposhnick
2006-04-26 0:53 ` Roman Shaposhnick
2006-04-26 2:15 ` Taj Khattra
2006-04-26 4:59 ` David Leimbach
2006-04-26 12:37 ` Anthony Sorace
2006-04-26 15:28 ` Rian Hunter
2006-04-26 16:39 ` Micah Stetson
2006-04-26 18:02 ` Bruce Ellis
2006-04-26 20:14 ` Micah Stetson
2006-05-08 14:50 ` Harri Haataja
2006-05-08 15:04 ` LiteStar numnums
2006-05-08 15:12 ` Charles Forsyth
2006-05-08 20:08 ` Micah Stetson
2006-05-08 20:52 ` LiteStar numnums
2006-05-08 21:10 ` Jack Johnson
2006-05-08 21:17 ` andrey mirtchovski
2006-05-08 21:18 ` Paul Lalonde
2006-05-08 22:25 ` Francisco J Ballesteros
2006-05-09 21:56 ` Dave Eckhardt
2006-05-10 0:13 ` geoff
2006-05-10 8:39 ` Lluís Batlle
2006-05-08 23:31 ` geoff
2006-05-09 1:18 ` Paul Lalonde
2006-05-09 1:39 ` quanstro
2006-05-09 2:12 ` Paul Lalonde
2006-05-09 2:20 ` quanstro
2006-05-09 3:00 ` Paul Lalonde
2006-05-09 9:32 ` Bruce Ellis
2006-04-26 22:57 ` Roman Shaposhnick
2006-04-26 4:57 ` David Leimbach
2006-04-26 4:53 ` Ronald G Minnich
2006-04-26 5:11 ` Roman Shaposhnick
2006-04-25 10:20 erik quanstrom
2006-04-25 2:30 erik quanstrom
2006-04-25 2:48 ` Derek Fawcus
2006-04-24 20:37 Ronald G Minnich
2006-04-24 20:51 ` Charles Forsyth
2006-04-24 21:32 ` Brantley Coile
2006-04-25 11:06 ` Anthony Sorace
2006-04-25 11:08 ` Anthony Sorace
2006-04-25 2:15 ` Derek Fawcus
2006-04-25 2:23 ` Roman Shaposhnick
2006-04-25 2:37 ` Derek Fawcus
2006-04-25 3:51 ` Roman Shaposhnick
2006-04-25 8:17 ` Derek Fawcus
2006-04-25 17:53 ` Roman Shaposhnick
2006-04-26 1:11 ` Derek Fawcus
2006-04-26 1:19 ` Roman Shaposhnick
2006-04-26 2:12 ` Derek Fawcus
2006-04-25 3:02 ` Andy Newman
2006-04-25 3:13 ` Ronald G Minnich
2006-04-25 19:57 ` Dan Cross
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=2256501d5763ca7585ed7c8a52da5efd@quanstro.net \
--to=quanstro@quanstro.net \
--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).