[9fans] Re: Announcing the release of NetBSD 3.0

[9fans] Re: Announcing the release of NetBSD 3.0

[lucio]

I wouldn't think this would merit major mention, but it's nice to see
that the NetBSD developers keep an eye on Plan 9 too.  It pops up
surprisingly often on the mailing lists, very seldom in the context
of: "If you want Plan 9, you know where to get it" :-)

++L

>      * Added seq(1), a utility which prints a sequence of numbers.
>        seq(1) is derived from Plan 9.

Re: [9fans] Re: Announcing the release of NetBSD 3.0

[Uriel]

And they have "magic symlinks"! that shows how much they have
learned from Plan 9... not.

Oh, and they pioneered in LSD(sic) land the marvelous idea of
dynamically linking /bin

Paraphrasing our founding fathers: 
"The NetBSD project hasn't learned anything"

uriel

On Sat, Dec 24, 2005 at 11:01:36AM +0200, lucio@proxima.alt.za wrote:
> I wouldn't think this would merit major mention, but it's nice to see
> that the NetBSD developers keep an eye on Plan 9 too.  It pops up
> surprisingly often on the mailing lists, very seldom in the context
> of: "If you want Plan 9, you know where to get it" :-)
> 
> ++L
> 
> >      * Added seq(1), a utility which prints a sequence of numbers.
> >        seq(1) is derived from Plan 9.
> 

Re: [9fans] Re: Announcing the release of NetBSD 3.0

[Uriel]

On Sat, Dec 24, 2005 at 10:11:34AM +0000, Uriel wrote:
> Paraphrasing our founding fathers: 
> "The NetBSD project hasn't learned anything"

Maybe this reference was too obscure, so here is the source:

http://fred.cambridge.ma.us/c.o.r.flame/msg00037.html

The whole thread is a gold mine.

uriel

Re: [9fans] Re: Announcing the release of NetBSD 3.0

[erik quanstrom]

this is quite an interesting thread. i remember reading it way
back when.

it would be interesting to see how that discussion would play out
with modern parameters.

ron, are you still using dsm?

- erik

Uriel <uriell@binarydream.org> writes

| 
| On Sat, Dec 24, 2005 at 10:11:34AM +0000, Uriel wrote:
| > Paraphrasing our founding fathers: 
| > "The NetBSD project hasn't learned anything"
| 
| Maybe this reference was too obscure, so here is the source:
| 
| http://fred.cambridge.ma.us/c.o.r.flame/msg00037.html
| 
| The whole thread is a gold mine.
| 
| uriel

Re: [9fans] Re: Announcing the release of NetBSD 3.0

[Paul Lalonde]

I can certainly say something I've learned in the last 15 years -  
gone are the days when Usenet had actual interesting conversation :-(
There's bits of the old days I really do miss.

Paul

On 25-Dec-05, at 4:54 AM, Uriel wrote:

> On Sat, Dec 24, 2005 at 10:11:34AM +0000, Uriel wrote:
>> Paraphrasing our founding fathers:
>> "The NetBSD project hasn't learned anything"
>
> Maybe this reference was too obscure, so here is the source:
>
> http://fred.cambridge.ma.us/c.o.r.flame/msg00037.html
>
> The whole thread is a gold mine.
>
> uriel

Re: [9fans] Re: Announcing the release of NetBSD 3.0

[Ronald G. Minnich]

> ron, are you still using dsm?

Nah. I was young and naive back then. Now I am old and naive. Along the
way, I dumped DSM, although my last go-round was something called ZOUNDS,
which I used to good effect for X11-based tiled displays and other such
things you can see on my web page. ZOUNDS is available free of charge bla
bla bla, and I still hear from people every now and then who are using it.

I did build a 17-node hardware DSM system based on SCI that worked really,
really well for a parallel mpeg encoding project -- you know, the kind of
thing your cheap PC now does at 60x real-time or something :-)

SCI was a very powerful network, shame it had so many problems. It's
really, really nice to do stuff like atomic increment of a variable in
another machine's memory with a simple function call. Yeah, it's not "the
right thing" any more but, that said, it sure was nice.

ron

Re: [9fans] Re: Announcing the release of NetBSD 3.0

[erik quanstrom]

i was interested in one posting (i'm to lazy to re reread it and find the 
reference) where you were multicasting or broadcasting a buffer to
n nodes for digestion using what sounded like page-based DSM.

it's the type of operation that you can't do with 9p.
and i never did convince myself that i needed to. 

page-based DSM has always sounded like 1/2 of a brilliant idea.
there was an os named dsum dimsum or something based on DSM
in the early 90s. the only problem was that they put the DSM so
deep in the system that you couldn't mix processor types in a cluster.
(who's to say what node you might have landed on.)

needless to say, i couldn't google it up.

- erik

"Ronald G. Minnich" <rminnich@lanl.gov> writes

| 
| 
| > ron, are you still using dsm?
| 
| Nah. I was young and naive back then. Now I am old and naive. Along the
| way, I dumped DSM, although my last go-round was something called ZOUNDS,
| which I used to good effect for X11-based tiled displays and other such
| things you can see on my web page. ZOUNDS is available free of charge bla
| bla bla, and I still hear from people every now and then who are using it.
| 

Re: [9fans] Re: Announcing the release of NetBSD 3.0

[Ronald G Minnich]

erik quanstrom wrote:
> i was interested in one posting (i'm to lazy to re reread it and find the 
> reference) where you were multicasting or broadcasting a buffer to
> n nodes for digestion using what sounded like page-based DSM.

available in ZOUNDS. ZOUNDS was more like an "attach this chunk of your 
virtual memory to this network connection endpoint" than a real DSM. I 
never did coherency protocols anyway -- MESI on an ethernet? You gotta 
be kidding ...

Anyways, ZOUNDS used IP multicast for this stuff, and we have found out 
that many switches choke and die on IP multicast, even today. A nice 
theory, killed by a brutal gang of facts.


> deep in the system that you couldn't mix processor types in a cluster.
> (who's to say what node you might have landed on.)
> 

the encoding cluster I mentioned was pentium/freebsd and alpha/linux 
(64-bit). You can do this stuff, you just have to be careful.

ron

Re: [9fans] Re: Announcing the release of NetBSD 3.0

[erik quanstrom]

Ronald G Minnich <rminnich@lanl.gov> writes

| 
| erik quanstrom wrote:
| > i was interested in one posting (i'm to lazy to re reread it and find the 
| > reference) where you were multicasting or broadcasting a buffer to
| > n nodes for digestion using what sounded like page-based DSM.
| 
| available in ZOUNDS. ZOUNDS was more like an "attach this chunk of your 
| virtual memory to this network connection endpoint" than a real DSM. I 
| never did coherency protocols anyway -- MESI on an ethernet? You gotta 
| be kidding ...

there are lots of fancy things one can roll up as part of DSM. but thair
be dragons in coherency protocols. 

| 
| Anyways, ZOUNDS used IP multicast for this stuff, and we have found out 
| that many switches choke and die on IP multicast, even today. A nice 
| theory, killed by a brutal gang of facts.

if #nodes >> #switches you could try using your own software gw to 
forward the multicast across bothersome hardware. i've never found
a switch (even the linksys on my desk) to fail with a 224.0.0.1 local
network broadcast.

| > deep in the system that you couldn't mix processor types in a cluster.
| > (who's to say what node you might have landed on.)
| > 
| 
| the encoding cluster I mentioned was pentium/freebsd and alpha/linux 
| (64-bit). You can do this stuff, you just have to be careful.

you were savvy enough segregate the DSM data from stuff on the heap/stack.
in the system i was talking about, the operating system was DSM based and 
would send pages around underneath the application. stack, heap, bss, 
data segment, whatever.

lets assume that we can reliably reset the registers and pc from one architecture
to the next,  the insurrmountable problem with this kind of system is it is impossible,
given a page of memory, tell which bytes are endian-dependent.

this kind of system would only make sense in an virtual machine environment.
i'm suprised that that was never part of the discussion.

- erik