Re: [9fans] design clairvoyance & the 9 way

Re: [9fans] design clairvoyance & the 9 way

[jmk]

On Wed May  7 19:30:16 EDT 2003, sah@softcardsystems.com wrote:
> ...
> What *could* have been done differently, or better?
> ...

'Wormingest' and 'atolwhex' would be reserved words.

Re: [9fans] design clairvoyance & the 9 way

[David Presotto]

Dave Mazieres had a reasonable take on the name space.  The
implementation in the kernel (chan.c) is hard to understand.
Exportfs is wierd because the namespace it exports isn't
really what it sees (a bunch of different mount points all
with their own qid space) but instead makes up a new qid
space to paper over the differences.

He wanted to make the name space even more visible, make
the file protocol recursive (i.e. able to encapsulate in
a visible way subsets of itself), and perhaps implement the
whole thing at user level.

I didn't really like his particular solution in that direction
but I believe that his observation was right.  I'm just not sure
what the fix should be or even if it wouldn't be worse than the
problem.

Re: [9fans] design clairvoyance & the 9 way

[rog]

> Exportfs is wierd because the namespace it exports isn't
> really what it sees (a bunch of different mount points all
> with their own qid space) but instead makes up a new qid
> space to paper over the differences.

making a qid path a variable-length byte array would
get you quite a long way, i think... but how costly would
it be?

Re: [9fans] design clairvoyance & the 9 way

[Russ Cox]

A student here at MIT is going to try out something
approaching dm's idea.  Make the kernel interface 9P
instead of the usual file system calls.  Have the kernel
do proper multiplexing* of the 9P connections
rather than rely on exportfs's inexact approximation.
Exportfs becomes a system call, like in Inferno but with
a precise implementation.  Processes that want to do a
lot of overlapped I/O can exportfs("/") and then interact
with their name space via 9P messages, avoiding the
need for lots of slave procs to manage just to run I/O.

The kernel drivers would change to deal with 9P explicitly
(like the 9P2000 lib9p interface) rather than assume that the
call needs to have the reply ready before it returns (like
the 9P1 lib9p interface).  This will complicate things a little,
but opens new doors too.  For example, the SCSI driver
could easily look at the 9P queue and do disk scheduling or
issue multiple SCSI requests at once.

It'll be a while before we see how it turns out.

Russ

[*] By proper I just mean that the message are
translated faithfully.  Exportfs can't do that exactly
since it's constantly rewalking paths and trying to
use the system calls to implement the messages.

Re: [9fans] design clairvoyance & the 9 way

[Russ Cox]

Variable-length qids don't fix the real problem.
If I have the same file server mounted on my terminal
and in my cpu session, then I'd like

	cp /mnt/term/usr/rsc/lib/profile /usr/rsc/lib/profile

not to silently truncate my profile.

Re: [9fans] design clairvoyance & the 9 way

[rog]

> If I have the same file server mounted on my terminal
> and in my cpu session, then I'd like
>
> 	cp /mnt/term/usr/rsc/lib/profile /usr/rsc/lib/profile
>
> not to silently truncate my profile.

i don't believe that's possible to solve (without some special
mechanism for detecting identical files) unless you have globally
unique qids, which i think would go against the grain in plan 9.

the other problem you mentioned in a previous message: it would be
nice if a cpu server could know that all the copies of rc that it's
running are actually the same binary.  this is an easier problem:
Ropen could contain an optional SHA1 hash of the contents, venti
style; in this case you don't care if they're the same file, just that
the contents are identical.

at least variable length qids would get rid of those insidious
exportfs qid hacks and enable encapsulation without worries.

Re: [9fans] design clairvoyance & the 9 way

[rog]

> Processes that want to do a
> lot of overlapped I/O can exportfs("/") and then interact
> with their name space via 9P messages, avoiding the
> need for lots of slave procs to manage just to run I/O.

wouldn't you then need the slave procs on the server side, anyway?  as
you'd need to avoid blocking a device because its client wasn't
reading the message...  unless you added asynchronous writes, i
suppose.

> For example, the SCSI driver
> could easily look at the 9P queue and do disk scheduling or
> issue multiple SCSI requests at once.

surely it could anyway?  just give it a proc to itself, and have the
various device entry points queue messages, which could then be
inspected in much the same way.

Re: [9fans] design clairvoyance & the 9 way

[Russ Cox]

> surely it could anyway?  just give it a proc to itself, and have the
> various device entry points queue messages, which could then be
> inspected in much the same way.

Sure.  But then every driver doesn't have to do this for itself.

Re: [9fans] design clairvoyance & the 9 way

[boyd, rounin]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 684 bytes --]

"Sam" <sah@softcardsystems.com> a �crit dans le message de
news:Pine.LNX.4.30.0305071048580.10670-100000@athena...
> ``Your conventional `good citizen' ...

... the epistemological anarchist has no compunction to defend
the most trite, or the most outrageous statement. ... he may
use reason, emotion, ridicule, an `attitude of serious concern'
and whatever other means have been invented by humans to
get the better of their fellow men. His favourite pastime is
to confuse rationalists ... There is no view, however `absurd'
or `immoral', he refuses to consider or to act upon, and no
method is regarded as indispensable.

    -- Paul K Feyerabend "Against Method"

Re: [9fans] design clairvoyance & the 9 way

[boyd, rounin]

From: "northern snowfall" <dbailey27@ameritech.net>
> >speaking of SARS, i believe a linux beowulf cluster was used
> >to help map the genomic sequence of the SARS coronavirus.
> >
> Nice

hmm ...

the 'vector':

How is SARS spread?
The primary way that SARS appears to spread is by close person-to-person
contact. Potential ways in which SARS can be spread include touching the skin of
other people or objects that are contaminated with infectious droplets and then
touching your eye(s), nose, or mouth. This can happen when someone who is sick
with SARS coughs or sneezes droplets onto themselves, other people, or nearby
surfaces. It also is possible that SARS can be spread more broadly through the
air or by other ways that are currently not known.

http://www.cdc.gov/ncidod/sars/qa/spread.htm#1

Re: [9fans] design clairvoyance & the 9 way

[boyd, rounin]

> toilet seats - just hover

not autorotate?

Re: [9fans] design clairvoyance & the 9 way

[David Presotto]

[-- Attachment #1: Type: text/plain, Size: 25 bytes --]

toilet seats - just hover

[-- Attachment #2: Type: message/rfc822, Size: 2336 bytes --]

From: "boyd, rounin" <boyd@insultant.net>
To: <9fans@cse.psu.edu>
Subject: Re: [9fans] design clairvoyance & the 9 way
Date: Fri, 9 May 2003 21:52:55 +0200
Message-ID: <015201c31664$95dc76a0$e3944251@insultant.net>

> >speaking of SARS, i believe a linux beowulf cluster was used
> >to help map the genomic sequence of the SARS coronavirus.
> >
> Nice

err, isn't this a retro-virus that mutates? as soon as i get a spare
nanosecond i'm gonna check out what the CDC have to say about it.

all this noise on the news and _no-one_ has declared the 'vector' ...

Re: [9fans] design clairvoyance & the 9 way

[boyd, rounin]

> >speaking of SARS, i believe a linux beowulf cluster was used
> >to help map the genomic sequence of the SARS coronavirus.
> >
> Nice

err, isn't this a retro-virus that mutates? as soon as i get a spare
nanosecond i'm gonna check out what the CDC have to say about it.

all this noise on the news and _no-one_ has declared the 'vector' ...

Re: [9fans] design clairvoyance & the 9 way

[boyd, rounin]

> > > Ken and Rob thought up the idea of building everything around a
> > > single file system protocol.

9p looks pretty similar to the sam/samterm protocol and
that's been 'round for a _very long time_ ...

Re: [9fans] design clairvoyance & the 9 way

[northern snowfall]

>
>
>The two process contexts on the CPU? One becomes a 32-bit context, one
>becomes a 64-bit context.
>
heh

>

Re: [9fans] design clairvoyance & the 9 way

[ron minnich]

On Fri, 9 May 2003, Douglas A. Gwyn wrote:

> Joel Salomon wrote:
> > Then why has Intel been pushing hyperthreading? (SMP on a chip)
>
> My guess is that they need to keep introducing new products
> and convincing people to buy them.

It's hard to understand putting all the effort (enormous effort!) into
hype-r-threading if it's not going to pay off. It is a serious engineering
accomplishment, that's for sure. People keep wondering why it's there.
Could there be some other reason?

Oh, all right, here's a theory for all you conspiracy buffs. Rumors
continue to abound that there is a 'hidden MSR' on the Xeon and later P4s
that turns it into Intel's version of the K8. You see it in the trade rags
all the time.

Where is the Magic Conspiracy MSR?  There are definitely undocumented
MSRs, and on P3 and later CPUs intel made them very hard to find by not
throwing an exception when you accessed an invalid MSR -- which makes it
very hard to find the valid ones in the 2^32 MSR space. I once had to use
a PII to find all the valid MSRs since the P3 just won't tell you. (the
errata is amusing: "P3 won't cause exception on access to invalid MSR".
User workaround: "don't access invalid MSR".  Intel plans to fix: "No
plans to fix this problem").

Now, starting from this crazy theory, what happens to all the
hype-r-threading hardware when you set the Magic Conspiracy Bit? Simple,
it all lines up to build 64-bit ALUs. Or as somebody joked, "propagate the
carry from one half of hyperthreading to the other".

The two process contexts on the CPU? One becomes a 32-bit context, one
becomes a 64-bit context.

Told you it was crazy. But it's funny speculation. And no, I have zero
data to prove or disprove this -- it's more a lunchtime table napkin
exercise as we tried to figure out why we had 2048 P4s with
hype-r-threading. I don't think we saved the napkin.

ron

Re: [9fans] design clairvoyance & the 9 way

[northern snowfall]

>
>
>speaking of SARS, i believe a linux beowulf cluster was used
>to help map the genomic sequence of the SARS coronavirus.
>
Nice

>

Re: [9fans] design clairvoyance & the 9 way

[Douglas A. Gwyn]

Joel Salomon wrote:
> Then why has Intel been pushing hyperthreading? (SMP on a chip)

My guess is that they need to keep introducing new products
and convincing people to buy them.

Re: [9fans] design clairvoyance & the 9 way

[Taj Khattra]

On Wed, May 07, 2003 at 07:46:35PM -0500, northern snowfall wrote:
>
> ... to gene analysis (that'd be great if we could
> have an automated system to break down virii like SARS
> fairly quickly with a cluster, don't you think...?) ....!
>

speaking of SARS, i believe a linux beowulf cluster was used
to help map the genomic sequence of the SARS coronavirus.

-taj

Re: [9fans] design clairvoyance & the 9 way

[ron minnich]

On Thu, 8 May 2003, Joel Salomon wrote:

> On Thu, 8 May 2003, Dan Cross wrote:
> > The current trends seem to be *away* from SMP machines and towards
> > clusters of single-CPU machines
>
> Then why has Intel been pushing hyperthreading? (SMP on a chip)

I wish somebody would tell me. The 1152-node MCR cluster has turned it
off, our 1024-node cluster has turned it off, and a 400-node I know of has
turned it off, and .... darn shame, as it seems like it ought to be a neat
thing, but in practice it's not working out.

An IBM study showed that hyperthreading is great for running chat rooms.
Is that the market?

ron

Re: [9fans] design clairvoyance & the 9 way

[northern snowfall]

>
>
>You missed my point.  There's nothing wrong with asking whether SMP is
>still relevant.  See, that's the thing.  The current trends seem to be
>*away* from SMP machines and towards clusters of single-CPU machines; I
>remember when The Abyss was made on clusters of multi-processor SGI
>Iris systems; Toy Story was then made on a cluster of multi-processor
>SPARCstation 20's; then Titanic was (partially) made on a cluster of
>single-CPU Alpha's running Linux.  Maybe Pixar is using SMP machines
>because that's where the sweet spot is in terms of price/performance.
>But it's been that way in the past, and then it's changed.  Whatever is
>happening now doesn't mean it will be that way in two years, or five.
>In other words, the future trend is likely to be uniprocessor machines
>connected by a really fast network, not big SMP machines connected by a
>fast network.  See, for instance, the new blade systems being shipped
>by various vendors.
>
Oh, I did miss what you were saying. Hopefully because I just woke up.
I wasn't condemning Sam, I was just making the observation that SMP
research is necessary for more than a few great reasons. Thats probably
why I completely ignored your point about condemning someone for
asking a question, because I didn't feel that I was. People totally have a
right to ask any question they want. I also have a right to respond.

I can understand the point of moving away from SMP to clusters of single
CPU machines, simply because they're getting so much cheaper. However,
SMP x86 is becoming cheaper, too. It might actually become cheaper to
run 10 3CPU SMP machines versus 20 or 30 single CPU x86 machines.
Talking about RISC price ranges isn't my best trait, but, when the Sun
Blades
came out, a Blade100 was still around $1,300 for the full package that
included a 501mhz UltraSPARC processor. Knowing I can get a couple
x86 machines for the same price (SMP or not), I might choose to skip
out on the Sun. Besides, the Blades (Sun or otherwise) are really designed
to be workstations, aren't they?

If you're talking about what is happening now versus what will be in a
few years from now, thats why we look at the trends in the research
institutions and the trends in places doing groundbreaking work in their
field. Find out what they need and what they use (or want to use), then
look at trends in the public sector that may purport that these techniques
go global, etc. Looking at places like Pixar and Lucas, not to mention
the Yahoo/Google farms, etc, gives us a more-likely-candidate
perception of what the future will look like. Thats why there are followers
versus leaders. Most people end up doing what's worked for the
people willing to try new things. That becomes trend.


>

Re: [9fans] design clairvoyance & the 9 way

[Geoff Collyer]

This is a somewhat rambling discussion, but I'll throw in my 2 cents
on several, perhaps related, topics.

The conventional monolithic, one-machine-does-it-all `desktop' PC
already seems like a throwback to 1960's mainframe (S/360) thinking
(except that pre-XA 370s were too small to run Netscape!).  Laptops,
PDAs, ipaqs, ipods, and increasing use of wireless technologies
suggest that `the future of the desktop PC' may not matter a great
deal.

30 years ago it looked like we'd never be rid of the IBM 360/370
architecture and accompanying IBM software.  It's still with us, but
isn't the plague on computing it once was.  20 years ago, one could
say ``All the world's a VAX'' with a straight face; no more.  15 years
ago, one could say ``All the world's a Sun'' with a straight face; no
more.  All the world may look like an x86 PC today, but This Too Shall
Pass.  And that's ignoring the embedded-systems market: the software
in your printer, router, firewall, wireless widget, and perhaps your
car is almost certainly not Windows 2000 and the processor is likely a
MIPS or ARM chip or 68000 ASIC, not an x86.  So far, at least, in the
history of computing, no single architecture dominates forever (it
just seems that way).

I'm not sure what advantage one could obtain from an
`architecture-dependent' kernel.  There might be a slight performance
gain, but given the speed, and rate of increase, of modern processors,
who cares?  Wait a week or a month and you can buy the performance
gain without changing any code.  A kernel dedicated to a single
architecture would likely be less clean than one intended for broader
use, and the history of manufacturers' operating systems dedicated to
particular architectures isn't encouraging; these systems tended to be
strangely designed (to be polite) and lacking in function, which isn't
too surprising, since they existed mainly to sell hardware, and so had
to be just good enough to help sell machines.

There are other reasons than raw computing power to want multiple
processors.  The one I like best is the ability to absorb load while
remaining responsive.  An MP terminal holds up under load.  If you've
ever used a Unix workstation running X, you've probably seen the
machine ignore your mouse movements and keystrokes when it gets busy.
Plan 9 terminals are less prone to this, but with an extra processor,
it virtually never happens.  MP cpu servers are pleasant places to do
heavy work since they too degrade gracefully under load.

Furthermore, the supposed complexity in Plan 9 due to support for
multiprocessing seems to be mainly getting locking right, which is
worth doing even with just one processor.  I don't believe that we pay
a huge cost in code complexity or performance for SMP support.

Central file storage simplifies backup and retrieval.  The more places
you have files stored, the more care it takes to ensure that they are
really getting backed up, and the more places you may have to look
when you can't remember where you stored something.  Of course, google
now sells an appliance to index and search one's files...

I suspect that programmer ability matters more than choice of
language.  I've been looking at an MP3 decoder.  It's 8,000
non-comment lines of C, many of them duplicated (dup -t1 reports that
26% of the source is redundant).  Functions ramble on for hundreds of
lines.  The code is littered with unexplained magic numbers.  None of
this is encouraged by C: functions are easy to write and cheap to
call; enum or even #define provide easy ways to declare manifest
constants.  (For sheer humour value, though, one has to look to
sendmail:

; funclen *.c | sort -nr | sed 20q
2627	main.c:152,2779	main()
2510	srvrsmtp.c:338,2848	smtp()
2301	deliver.c:1251,3552	deliver()
1468	readcf.c:2130,3598	setoption()
782	daemon.c:147,929	getrequests()
754	daemon.c:2010,2764	makeconnection()
746	map.c:4066,4812	ldapmap_parseargs()
712	deliver.c:70,782	sendall()
673	queue.c:3783,4456	readqf()
661	recipient.c:444,1105	recipient()
620	parseaddr.c:941,1561	rewrite()
590	savemail.c:760,1350	errbody()
588	queue.c:322,910	queueup()
583	collect.c:289,872	collect()
575	readcf.c:88,663	readcf()
571	mime.c:99,670	mime8to7()
538	deliver.c:4988,5526	mailfile()
533	milter.c:564,1097	milter_open()
513	queue.c:1738,2251	run_work_group()
502	deliver.c:4444,4946	putbody()
)

Re: [9fans] design clairvoyance & the 9 way

[northern snowfall]

>
>
>All of that represents about 0% of the market.  I'm not saying SMP is
>bad, or that support for it should be abandoned, but one should
>concentrate on where the biggest bang for the buck is.  It's certainly
>a valid question whether that's in the SMP arena, and it would be
>intellectually dishonest to simply say, ``of course it is!  Pixar uses
>it!''
>
It may represent 0% of the market today (check your figures), but,
not in the near future. Besides, I'd rather be flexible enough to
contract out to write the software for the 0% that will pay me
6 figures per hit, than concentrate on the other 99% of the market
that will may me out 6 figures per year. Pixar was just an
example of what a large group of people are actually becoming
involved in. Think about how many animation groups alone
are beginning to use the same techniques as Pixar. I think Lucas
Light-and-whatever was actually using SMP clusters before
Pixar. That may still be two examples, but, this is what trend
analysis is all about. Looking at who is doing what, then,
determining the most likely group of individuals to follow, and
whether there is a market for it. If you want the biggest bang
for the buck, it seems to me you should be looking towards future
trends, not old ones.

>

Re: [9fans] design clairvoyance & the 9 way

[Joel Salomon]

On Thu, 8 May 2003, Dan Cross wrote:
> The current trends seem to be *away* from SMP machines and towards
> clusters of single-CPU machines

Then why has Intel been pushing hyperthreading? (SMP on a chip)

--Joel

Re: [9fans] design clairvoyance & the 9 way

[Dan Cross]

> It may represent 0% of the market today (check your figures), but,
> not in the near future. Besides, I'd rather be flexible enough to
> contract out to write the software for the 0% that will pay me
> 6 figures per hit, than concentrate on the other 99% of the market
> that will may me out 6 figures per year. Pixar was just an
> example of what a large group of people are actually becoming
> involved in. Think about how many animation groups alone
> are beginning to use the same techniques as Pixar. I think Lucas
> Light-and-whatever was actually using SMP clusters before
> Pixar. That may still be two examples, but, this is what trend
> analysis is all about. Looking at who is doing what, then,
> determining the most likely group of individuals to follow, and
> whether there is a market for it. If you want the biggest bang
> for the buck, it seems to me you should be looking towards future
> trends, not old ones.

You missed my point.  There's nothing wrong with asking whether SMP is
still relevant.  See, that's the thing.  The current trends seem to be
*away* from SMP machines and towards clusters of single-CPU machines; I
remember when The Abyss was made on clusters of multi-processor SGI
Iris systems; Toy Story was then made on a cluster of multi-processor
SPARCstation 20's; then Titanic was (partially) made on a cluster of
single-CPU Alpha's running Linux.  Maybe Pixar is using SMP machines
because that's where the sweet spot is in terms of price/performance.
But it's been that way in the past, and then it's changed.  Whatever is
happening now doesn't mean it will be that way in two years, or five.
In other words, the future trend is likely to be uniprocessor machines
connected by a really fast network, not big SMP machines connected by a
fast network.  See, for instance, the new blade systems being shipped
by various vendors.

Now, maybe I'm wrong about SMP versus uniprocessor machines, but my
real point was that condeming someone for asking a question of
relevance isn't a step in the right direction.

	- Dan C.

Re: [9fans] design clairvoyance & the 9 way

[Dan Cross]

> Isn't that kind of like what Bill Gates said... something
> about "640 kilobytes should be enough"...

No, it's more like saying, ``wow, we can remove a lot of complexity
that we may not need, since machines are so fast there's no need for it
anymore.''  Kind of like moving from the x86's segmented memory
architecture back in the day to a flat memory space.  In other words,
we've moved from a position of requiring SMP to get the kind of numbers
needed to tackle big problems to not requiring SMP.  It's completely
valid to try and assess the impact of that.

> SMP is still valuable for a ton of research, the DNA modeling
> project comes to mind. I was talking to fellow Interlochen
> "alumni", recently, that works at Pixar. All they do is use
> clusters of SMP Linux (according to him) to do image and
> animation generation. We could go on to the .mil's interest
> in crypto and quantum simulation... Simply *because* processors
> are becoming faster+relatively cheaper, means that scalable
> SMP systems are becoming more desired. With the parallel
> processing support of stuff like plan9 and friends, I think more
> corporations and laboratories are going to begin investing
> in distributed SMP clusters to process a range of data: from
> market analysis, to gene analysis (that'd be great if we could
> have an automated system to break down virii like SARS
> fairly quickly with a cluster, don't you think...?) ....!

All of that represents about 0% of the market.  I'm not saying SMP is
bad, or that support for it should be abandoned, but one should
concentrate on where the biggest bang for the buck is.  It's certainly
a valid question whether that's in the SMP arena, and it would be
intellectually dishonest to simply say, ``of course it is!  Pixar uses
it!''

As for breaking down SARS (which is way over-hyped to begin with;
influenza kills many more people per day), why does one *need* SMP when
networks of x86 machines connected by gigabit networks can be had
cheaply?  SMP may or may not be a better solution, but it's not a
necessity, and one *must* evaluate the impact of it no longer being an
absolute necessity for doing work on big problems.  There's nothing
wrong with that, or with asking questions.

	- Dan C.

Re: [9fans] design clairvoyance & the 9 way

[Russ Cox]

> We're facing a new paradigm where all the world
> is an x86, networks are fast *and* reliable,
> and it's all at a rather reasonable cost.

Cost is subjective.  None of the others are true.

Russ

Re: [9fans] design clairvoyance & the 9 way

[Dan Cross]

> > Ken and Rob thought up the idea of building everything around a
> > single file system protocol.
>
> This particular post of Dave's explains the whole plan9 effort in a
> simpler and more succinct way than I've seen before. (Not that I've
> read every description of why plan9 was undertaken.)
>
> If I haven't missed a better one, I think we should put it in the FAQ.

I think it's a fine candidate for inclusion in the FAQ, but do want
to point out that it's very similar to the Motivation section of the
Plan 9 overview paper.  Granted, Dave's being a lot more informal on
the mailing list.

	- Dan C.

Re: [9fans] design clairvoyance & the 9 way

[Sam]

> >
> Isn't that kind of like what Bill Gates said... something
> about "640 kilobytes should be enough"...

I suppose if we go to something completely
revolutionary like, for example, 3D hologram
interfaces (a la star wars: `help me obi wan
kenobi, you're my only hope'), we could
see processing power become a bottleneck again
... or not.  Ingenuity hasn't been terribly
successful at keeping up with Moore's law.
The processor race in the 90s was fueled
largely by systems overloaded with cruft.
Ousterhout accurately asked, "why aren't
operating systems getting faster as fast as
hardware (usenix, '90)."  Plan9 is a good
answer to this question, but still seems
rather heavy on the inside.  It's not
a one-man maintainable kernel, though
SuperRuss certainly does an admirable job.

> SMP is still valuable for a ton of research, the DNA modeling
> project comes to mind. I was talking to fellow Interlochen

Sure, there will always be a place for large computing
systems.  The question of whether it's necessary on
the desktop still remains.  Perhaps it has a place
in a centralized file server, but perhaps not.
We're facing a new paradigm where all the world
is an x86, networks are fast *and* reliable,
and it's all at a rather reasonable cost.  As
pragmatists, we're constantly trying to figure
out how it can be done simpler.  Perhaps the kernel
*should* be architecture dependent, if you cover
95% of the world.  Perhaps the complexity of an
SMP kernel just isn't worth it unless you *are*
examining DNA and even then, why a timesharing OS?

Questioning design decisions and rewriting with
discretion is all a part of system evolution.
I think it's wonderful that our pioneers are
still alive for us to bother. ;)

There's something to be learned from 9 about system
design and evolutionary compatibility in the face of
long-term efficacy.

Cheers,

Sam

Re: [9fans] design clairvoyance & the 9 way

[A.S. Kukhar]

Steve should (http://www.fywss.com/plan9/plan9faq.html)

-kyxap

> David Presotto wrote:
> > Ken and Rob thought up the idea of building everything
> > around a single file system protocol.
>
> This particular post of Dave's explains the whole plan9
> effort in a simpler and more succinct way than I've seen
> before. (Not that I've read every description of why
> plan9 was undertaken.)
>
> If I haven't missed a better one, I think we should put
> it in the FAQ.

Re: [9fans] design clairvoyance & the 9 way

[Russ Cox]

> What does tomorrow's unix look like?

I'm confident that tomorrow's Unix will look
like today's Unix, only cruftier.

Russ

Re: [9fans] design clairvoyance & the 9 way

[northern snowfall]

>
>
>In retrospect, was this worth it?  Sure, SMP machines
>are becoming more prevalent, but when I can get a 2GHz on
>my desktop the race with the back cpu server is pretty much
>over.  Ron probably appreciates it in his cluster computing,
>but these days single processor systems are sufficiently cheap
>and fast for most needs.
>
Isn't that kind of like what Bill Gates said... something
about "640 kilobytes should be enough"...
SMP is still valuable for a ton of research, the DNA modeling
project comes to mind. I was talking to fellow Interlochen
"alumni", recently, that works at Pixar. All they do is use
clusters of SMP Linux (according to him) to do image and
animation generation. We could go on to the .mil's interest
in crypto and quantum simulation... Simply *because* processors
are becoming faster+relatively cheaper, means that scalable
SMP systems are becoming more desired. With the parallel
processing support of stuff like plan9 and friends, I think more
corporations and laboratories are going to begin investing
in distributed SMP clusters to process a range of data: from
market analysis, to gene analysis (that'd be great if we could
have an automated system to break down virii like SARS
fairly quickly with a cluster, don't you think...?) ....!

>
>
>

Re: [9fans] design clairvoyance & the 9 way

[northern snowfall]

>
>
>``Your conventional `good citizen' can be depended
>on not to be too thoughtful.  His ideas, beliefs,
>and practices are those of other people.  He loves
>and hates with them.  He is unreflectively loyal to
>the institutions under which he lives, and to the
>men who administer them.  But the really educated
>good man has no right to go along without question.''
>	- Henry Raymond Mussey
>
Somehow, I find it hard to believe that simply because
I've come to the same conclusion that other people
have, I'm a blindly loyal follower. The fact is I have
questioned. That is *why* I got interested in OS
research. That is *why* I forced myself to read the
entire BSD kernel and plan9 kernel before I even
fully understood the C language. That is *why* I
chose to take on my own OS development initiatives
to push myself further than what I've learned from
the above, and other, experiences. If two brilliant
men both surmise that E=MC2, is only the first one
that brings the subject to public light seen as
genius? Or, are they both respected for the hard
work they've done.
If you noticed, I said that there was merit in a lot of
the work done by the patchwork-quilt appendages
to the UNIX world, and others. If it wasn't for
Windows, I wouldn't even *be* involved in
computers, today. Just because these things have
design problems relating to their eventual growth
and extension doesn't mean they're any less usable
or worthy of praise. However, it *does* mean that
developers have to be wary in implementing new
techniques. VPN in a Windows environment is a
superb example of this. Look how many problems
the design of their driver architecture had when
attempting to implement a secure wide-area-network
infrastructure. Rather than pursuing a solution that
would afford e-business some security, they patched
in a simple driver that afforded horrible overlay of
crypto to a sickly protocol that was easily manipulated
by security analysts with a wide range of skill:
www.atstake.com, www.team-teso.net, etc. The
problems do not seem to end here. It isn't necessarily
that things *can't* be fixed, as much as it is that
to implement true dynamic flexibility in an Operating
System, certain things need to be adhered to. Namespaces,
presenting everything as files for simple resource
exportation, runes, plumbing, embedded authentication
semantics, to name a few, are all great examples of
ways to extend the capability of an OS for *years* of
research, when implementing new ideas, testing theory,
or whatever you're doing. UNIX simply failed to have
these things and because of the way the OS has been
structured from years of hacking and rehacking, it
would just be another *hack* to attempt implementation
of these ideas. We've seen attempts at these hacks
in projects like SELinux at the NSA and it is very
telling that their work seems to prove that, though name
spaces in a *NIX environment is a great ambition, the
underlying VFS/Net framework presents a serious
problem to the abstraction of isolated resource management,
severely crippling the implementation. So, what you
end up with is almost a redesigned Linux. Isn't it more
sensible to move to another OS with these ideas built
from the ground up, rather than spending a large amount
of time attempting to redesign the core of an OS whose
design is proven to be non-adherent to your goal?
Sheesh.

>

Re: [9fans] design clairvoyance & the 9 way

[Sam]

> Mk and rc are from Unix.  You many not like them, but does that mean

I like rc a lot.  Shell naming diversity seems appropriate
as the entire user interface changes.  mk's new interface
added pattern-matching vs. suffix-transformation metarules
(per hume's paper).  In the face of history (egrep, fgrep, troff, etc)
it may have been better accepted would it were [A-Za-z]make.
Quibbling about naming conventions probably isn't helpful,
though, and I should have probably picked something more
capricious like print vs. printf.

>
> The thought was that the new environment wouldn't change from Unix
> except where we thought it would make our goal easier to build.
> The kernel had to go.  The single monitor view of the Unix kernel
> was a real pain for making good use of the SMP's.  Therefore, we

In retrospect, was this worth it?  Sure, SMP machines
are becoming more prevalent, but when I can get a 2GHz on
my desktop the race with the back cpu server is pretty much
over.  Ron probably appreciates it in his cluster computing,
but these days single processor systems are sufficiently cheap
and fast for most needs.

> interface had to change though.  That was a separate topic.  Lots
> of others have rewritten the kernel from the ground up while
> maintaining something that looked more like a Unix.

Really?  What were the purposes of these endeavors?

> that looks very different.  The ease which with it can be done
> can be witnessed by the number of failed/stalled attempts
> to add the plan 9 namespace to Linux...

I think this assumes the 8+ edition kernels approached
the complexity of linux, which I can't verify.  Besides,
your group is generally a touch sharper than your ``average
bear.''

Thanks for the thoughts - I wasn't really trying to question
the design decisions of the time as research motivated
development should be open enough to permit any new
path necessary.  I'm more interested in your thoughts
as designers now, looking back.  What *could* have
been done differently, or better?  What does tomorrow's
unix look like?

I should have been more clear.  I apologize.

Sam

Re: [9fans] design clairvoyance & the 9 way

[Steve Kotsopoulos]

yes, I agree

Stephen Wynne wrote:
> David Presotto wrote:
>
> > Ken and Rob thought up the idea of building everything around a
> > single file system protocol.
>
> This particular post of Dave's explains the whole plan9 effort in a
> simpler and more succinct way than I've seen before. (Not that I've
> read every description of why plan9 was undertaken.)
>
> If I haven't missed a better one, I think we should put it in the FAQ.
>

Re: [9fans] design clairvoyance & the 9 way

[Stephen Wynne]

David Presotto wrote:

> Ken and Rob thought up the idea of building everything around a
> single file system protocol.

This particular post of Dave's explains the whole plan9 effort in a
simpler and more succinct way than I've seen before. (Not that I've
read every description of why plan9 was undertaken.)

If I haven't missed a better one, I think we should put it in the FAQ.

Re: [9fans] design clairvoyance & the 9 way

[David Presotto]

[-- Attachment #1: Type: text/plain, Size: 2941 bytes --]

Mk and rc are from Unix.  You many not like them, but does that mean
we're supposed to live forever with the original tools that existed
under 5th edition Unix or wherever you've decided to freeze it?
Is nmake any less different.  If we'ld called it nnmake would that
have been better.

Before Plan 9, we were running lots of Unices held together by a
few networks, a remote file system (different uid's on each Unix),
and a bunch of remote execution commands.  We hated it since it
was much harder to manage and use than our old single mutiuser
machine.  We wanted an environment that not only put together a
lot of boxes and made them look like one but which also would make
use of the new technologies that were appearing (SMP's, heterogeneous
architectures, juke boxes, ...).

The thought was that the new environment wouldn't change from Unix
except where we thought it would make our goal easier to build.
The kernel had to go.  The single monitor view of the Unix kernel
was a real pain for making good use of the SMP's.  Therefore, we
started that from scratch.  That didn't mean that the kenrel
interface had to change though.  That was a separate topic.  Lots
of others have rewritten the kernel from the ground up while
maintaining something that looked more like a Unix.

Ken and Rob thought up the idea of building everything around a
single file system protocol.  They also added the idea of
a subjective namespace to try to unify all the binding
ideas of Unix.  This name space is the one thing underlying
plan 9.  We could have done the same thing to a Unix kernel
(with an infinite amount of sweating) but the result would
have been the same from the user standpoint, i.e., a system
that looks very different.  The ease which with it can be done
can be witnessed by the number of failed/stalled attempts
to add the plan 9 namespace to Linux...

Also, we were tired of the general kitchen sink nature of
Unix, especially of System V.  If there were 3 projects
or groups to do a single thing (like character processing,
shared memory, networking, ...) they all eventually got jammed
in.  We wanted something simpler to work with.

Lastly, we had all developed an extreme allergy to code filled
with #if, #ifdef, #else, #elseif.  Getting rid of that cruft
by sticking differences into separate files/routines required
a hell of a lot of rewriting.

So the result was a different kenrel, with a different design
philosophy, a similar but different interface, but mostly the
same old commands.

If you think that Unix was just a single track in comparison,
you're sadly mistaken.  We just made more of a bend than others
did.

We are guilty of rewriting commands just for the sake of doing
it.  The reason there was sometimes legitimate, to match our
different kernel interfaces or whatever.  However, ot was just
as often so we wouldn't have to worry about Unix licenses.

[-- Attachment #2: Type: message/rfc822, Size: 3201 bytes --]

From: Sam <sah@softcardsystems.com>
To: <9fans@cse.psu.edu>
Subject: [9fans] design clairvoyance & the 9 way
Date: Wed, 7 May 2003 12:33:45 -0400 (EDT)
Message-ID: <Pine.LNX.4.30.0305071048580.10670-100000@athena>

> problem. Think about how many of these things could
> have been eradicated if we had the fore-sight when
> UNIX was being designed. Hasn't Pike been saying
> this stuff for years?
>

``Your conventional `good citizen' can be depended
on not to be too thoughtful.  His ideas, beliefs,
and practices are those of other people.  He loves
and hates with them.  He is unreflectively loyal to
the institutions under which he lives, and to the
men who administer them.  But the really educated
good man has no right to go along without question.''
	- Henry Raymond Mussey

While written with government in mind, this statement
seems apropos as a starter to this thread.  What
design issues about plan9 made it unsatisfactory
to consider reworking research UNIX?  Why reimplement
everything from the ground up?  If, for example,
mk isn't sufficiently better than make, why bother?

I've heard the spirit in the labs was such that
everything had to be written anew to be considered
worth using.  In retrospect, was this mantra taken
too far?  Compatibility was of no concern, but now
that labs folks are getting disseminated into the
non-labs world we see 9 libraries getting "ported"
over for use on *nix.  Is there any concern that
maybe it would have been better to keep an eye
on compatibility instead of running off in a direction
claiming the one true path?

I guess I'm just wondering what ``problems
with UNIX were too deep to fix.''  We know why
aspects of current unix systems are inferior
to 9, but perhaps if more effort was given to
redesigning the problem areas in place
the *nix world wouldn't be stuck using hacked
20 year old technology and we'd all be
better off.

Thoughts?

Cheers,

Sam

Re: [9fans] design clairvoyance & the 9 way

[Fco.J.Ballesteros]

I dont know what others say, but I feel that
unix has problems too deep to fix whenever I want to

1. Use stuff that is not files from other machines
2. Write programs once to work on all the machines where my unix runs
3. Customize the environment without getting to the sys admin.

IMHO, of course.

[9fans] design clairvoyance & the 9 way

[Sam]

> problem. Think about how many of these things could
> have been eradicated if we had the fore-sight when
> UNIX was being designed. Hasn't Pike been saying
> this stuff for years?
>

``Your conventional `good citizen' can be depended
on not to be too thoughtful.  His ideas, beliefs,
and practices are those of other people.  He loves
and hates with them.  He is unreflectively loyal to
the institutions under which he lives, and to the
men who administer them.  But the really educated
good man has no right to go along without question.''
	- Henry Raymond Mussey

While written with government in mind, this statement
seems apropos as a starter to this thread.  What
design issues about plan9 made it unsatisfactory
to consider reworking research UNIX?  Why reimplement
everything from the ground up?  If, for example,
mk isn't sufficiently better than make, why bother?

I've heard the spirit in the labs was such that
everything had to be written anew to be considered
worth using.  In retrospect, was this mantra taken
too far?  Compatibility was of no concern, but now
that labs folks are getting disseminated into the
non-labs world we see 9 libraries getting "ported"
over for use on *nix.  Is there any concern that
maybe it would have been better to keep an eye
on compatibility instead of running off in a direction
claiming the one true path?

I guess I'm just wondering what ``problems
with UNIX were too deep to fix.''  We know why
aspects of current unix systems are inferior
to 9, but perhaps if more effort was given to
redesigning the problem areas in place
the *nix world wouldn't be stuck using hacked
20 year old technology and we'd all be
better off.

Thoughts?

Cheers,

Sam