[9fans] python

[9fans] python

[Russ Cox]

Supposedly a Python port exists, but the URL
on the Wiki and in the Plan 9 FAQ doesn't work.

Anyone have other details?  Do you know if it
was a native port or an APE port?

Thanks.
Russ

Re: [9fans] python

[Boyd Roberts]

> Supposedly a Python port exists, but the URL
> on the Wiki and in the Plan 9 FAQ doesn't work.

Yes, there is one IIRC.

> Anyone have other details?  Do you know if it
> was a native port or an APE port?

Not really.  My native port ground to a halt when
my 'copious spare time' (tm) went to zero.  I would
still like to complete it.

I believe that APE ports are cheating and are an
invitation for disaster (no slur on APE intended)
because of the multiple layers of complexity and
the 'where is the bug' syndrome:

    Is it an application problem, ANSI problem, APE
    problem or Plan 9 problem?

Too many choices to my mind.  Native ports cut out
some of the uncertanty, but do raise other issues:

    You have to know unix and Plan 9 pretty well and you
    have to port it very cleanly because version n + 1 is
    just around the corner :(

On a quasi-related topic:  I had a hack at porting
faces/seemail to X11 using libXg.  This isn't too hard,
except some of the includes need to be augmented (or
added), some other libc functions need to be added
and ken C incompatibilities need to be addressed.

This last point has to be done cleanly, rather than
just hack (sic) defining around it.  I'd like to
build a toolkit to automate (as far as possible)
ports in both directions.

Before the Licence Police start to worry, I plan to
do it in such a way that you need to have Plan 9
installed and it copies the various files and all
other code will either be already in the public domain
or written from scratch by me.

I did have an evil thought of adding a:

    --kenC

option to gcc, but I'm pretty sure I'd be entering
a world of pain:

    Walter: OVER THE LINE!
    Smokey: Huh?
    Walter: I'm sorry, Smokey. You were over the line, that's a foul.
    Smokey: Bullshit. Mark it 8, Dude.
    Walter: Uh, excuse me. Mark it zero. Next frame.
    Smokey: Bullshit, Walter. Mark it 8, Dude.
    Walter: Smokey, this is not 'Nam. This is bowling. There are rules.

    ... [Walter grabs his M1911] ...

    Walter: You're entering a world of pain.

It would only work for people with gcc, which is not
a sufficiently general (or good) solution to my mind.

btw: any 'Help's found in this message are Outlook Express'
     screams of pain.  I like to think of it as a testimony
     to the skills of Microsoft software engineering.

Re: [9fans] python

[Laura Creighton]

Kenji Arisawa also has a 1.5.2 python port.
Look:
ftp://plan9.aichi-u.ac.jp/import/
or
ftp://ar.aichi-u.ac.jp/plan9/import/


Laura Creighton
.

Re: [9fans] Monitors and VGADB

[Russ Cox]

aux/vga won't recognize your monitor
per se, but if you set monitor=micron-17FGx you
should be all set.  i've been using a micron
monitor with the cm751u defn to run at 1600x1200
and it works fine (yes it's a hack).

an odd side-note: i plugged my (real) hitachi cm751u
into a win98 box the other day, and the win98 box
figured out that it was connected to a "Hitachi CM751"
(new hardware detected!, etc.).  does anyone know
how it did that?  i thought the video output
cable was one-way.

for translation from the manual to the
numbers needed by vgadb, the best reference
i know of is the XFree86 Video Timings HOWTO
(formerly the Hitchhiker's Guide to X386
Video Timings).

http://www.linuxdoc.org/HOWTO/XFree86-Video-Timings-HOWTO.html

russ

Re: [9fans] Monitors and VGADB

[Matt]

> an odd side-note: i plugged my (real) hitachi cm751u
> into a win98 box the other day, and the win98 box
> figured out that it was connected to a "Hitachi CM751"
> (new hardware detected!, etc.).  does anyone know
> how it did that?  i thought the video output
> cable was one-way.

DDC
Short for Display Data Channel, a VESA standard for communication between a
monitor and a video adapter. Using DDC, a monitor can inform the video card
about its properties, such as maximum resolution and color depth. The video
card can then use this information to ensure that the user is presented with
valid options for configuring the display.



http://webopedia.internet.com/TERM/D/DDC.html

Re: [9fans] Monitors and VGADB

[Matt]

>  does anyone know
> how it did that?  i thought the video output
> cable was one-way.

DDC

and I'm pleasantly surprised to know something Russ didn't know


that's like something I can tell people about :-)

Re: [9fans] Monitors and VGADB

[Scott Schwartz]

| does anyone know
| how it did that?  i thought the video output
| cable was one-way.

No, modern monitors use "DDC" to communicate their vital data back to
a DDC compatable video card.

There's a linux program that supposedly exercises this, but I didn't
have much luck with a Nokia 447x talking to a #9 771.

http://altern.org/vii/programs/linux/read-edid/ 

Re: [9fans] Adding history to Rio's windows

[Russ Cox]

I think " and "" are easier to use, especially since you
can quickly specify which command you want.  Also, if you
don't use the prompt, how do you tell user input to
the shell from input to another program?  I quite like
the blur actually: I make lists of commands prefixed
with g% and cat them in windows to ``seed'' the behavior
of " and "".

There seem to be good arguments that five is
about the most number of things that is comfortable
on a menu.  For more see the bottom of p. 7 of
http://cm.bell-labs.com/cm/cs/doc/88/1-07.ps.gz.
I have a hard time finding things quickly in the button 2
menu now that "plumb" makes six items.
Hiding windows makes the same thing happen on the
button 3 menu.  For a good time, try navigating a >200
page PDF file using page's button 3 menu.

Russ

Re: [9fans] Adding history to Rio's windows

[Scott Schwartz]

| Also, if you
| don't use the prompt, how do you tell user input to
| the shell from input to another program?

Hm.  Well, if one process had a way to find out which
other one did a write(), it could record that too.
That's a facility that's generally useful, in fact.

| There seem to be good arguments that five is
| about the most number of things that is comfortable
| on a menu.

That's true of a linear menu.  Radial pie menus comfortably support
many more items, and you can use them without looking.  Imagine a clock
(12 items) or a compass (8 items), for example.

| For a good time, try navigating a >200
| page PDF file using page's button 3 menu.

Yep.  Unbounded and variable entries are the wrong thing for
menus.

Re: [9fans] Adding history to Rio's windows

[Boyd Roberts]

From: "Russ Cox" <rsc@plan9.bell-labs.com>

> There seem to be good arguments that five is
> about the most number of things that is comfortable
> on a menu

yes, reminds me of the 7 + or - 2 'things' study used to work out
how may 'things' people could remember.  it was used to decide
on 7 digit phone numbers for the bell system -- most people
can remember 7, some can only remember 5, and others can
remember 9.

sam becomes pretty unmanageable when you have 20 (or so) windows.
the menu is just too big, the 'scrollbar' menu was hard to use 'cos wherever
you were was always a long way from where you wanted to be and the
mouse manipulation was unpleasant.

Re: [9fans] scripting sam

[Russ Cox]

there's always sam -d < script,
and i think there are two programs
called ssam floating around on the
unix side of things.  search google
for ssam, they're sure to turn up.

russ

Re: [9fans] scripting sam

[Scott Schwartz]

<russ:
| there's always sam -d < script,

Sam, like ed, has no control structures for reacting to errors, so if
the slightest thing goes wrong, it's garbage out.  Really what one wants
is a noninteractive version of acme, so that you can write tcl scripts
to control /dev/editor.  (NIH: that's roughly how XEDIT and REXX worked
in the IBM mainframe universe.)

Re: [9fans] stopping sleep and aux/listen

[Russ Cox]

	while (){
	lc /n/ftp >> templog
	sleep 300
	}&

You can't kill this except by killing
the rc that is running the while loop.

Better to put it into a script pingftp
and then kill pingftp|rc.

To kill off the listeners, try this:

term% cat /rc/bin/Kill
#!/bin/rc
ps | sed -n 's%^[^ ]* *([^ ]*) *[^ ]* *[^ ]* *[^ ]* *[^ ]* *'$1'%chmod 666 /proc/\1/ctl;echo kill > /proc/\1/ctl%p'
term%

It's like slay but for any process, not just
those owned by you.

Also at http://plan9.bell-labs.com/~rsc/Kill
if the line gets mangled (that's one line not
counting #!/bin/rc).

Russ

Re: [9fans] stopping sleep and aux/listen

[Scott Schwartz]

| You can't kill this except by killing
| the rc that is running the while loop.

ftpfs used to send NOOPs once in a while.  Isn't that sufficient to
keep the connection alive?

[9fans] ML, CVS, Python

[Russ Cox]

Moscow ML is at http://www.eecs.harvard.edu/~rsc/mosml.9gz.
I don't have the online help facility working yet but
I suspect that's just a small misconfiguration.

CVS is at http://www.eecs.harvard.edu/~rsc/cvs.9gz.
I used it all summer (under duress) and it seemed solid.

I thought I remembered a Python port already.
A google search turned up http://csociety-ftp.ecn.purdue.edu/pub/plan9
which claims to be a Python 2.0 port.  I thought
someone in Japan had one too.

Russ

Re: [9fans] ML, CVS, Python

[sergent]

> I thought I remembered a Python port already.
> A google search turned up http://csociety-ftp.ecn.purdue.edu/pub/plan9
> which claims to be a Python 2.0 port.  I thought
> someone in Japan had one too.

That's me.

It's got some problems.  Applying the ape diffs (Scott Schwartz has them
somewhere) and rebuilding will help make some of the networking stuff work
(via the socket emulation code in APE) a bit better than it does in the
binaries that are there.  There are still problems with it that I did not
have time to debug (some of the modules make it crash).


--jss.

Re: [9fans] ML, CVS, Python

[Randolph Fritz]

On Wed, 3 Jan 2001 09:04:12 GMT, sergent@kgb.etla.net
<sergent@kgb.etla.net> wrote:
>> I thought I remembered a Python port already.
>> A google search turned up http://csociety-ftp.ecn.purdue.edu/pub/plan9
>> which claims to be a Python 2.0 port.  I thought
>> someone in Japan had one too.
>
>That's me.
>
>It's got some problems.  Applying the ape diffs (Scott Schwartz has them
>somewhere) and rebuilding will help make some of the networking stuff work
>(via the socket emulation code in APE) a bit better than it does in the
>binaries that are there.  There are still problems with it that I did not
>have time to debug (some of the modules make it crash).
>

It sounds like you're further along than me.  I think what's really
needed is a push to get this back into the Python source tree, so that
the work doesn't have to be done over again.

Randolph

Re: [9fans] ML, CVS, Python

[Scott Schwartz]

| >Applying the ape diffs (Scott Schwartz has them
| >somewhere)

http://www.cse.psu.edu/~schwartz/ape-diffs.bz2

Re: [9fans] ML, CVS, Python

[Dan Cross]

In article <20010103005128.50428199E6@mail.cse.psu.edu> you write:
>Moscow ML is at http://www.eecs.harvard.edu/~rsc/mosml.9gz.
>I don't have the online help facility working yet but
>I suspect that's just a small misconfiguration.

Thanks, Russ, and indeed, all those who replied.

I spent yesterday evening porting Moscow ML and got a working
system, but I suspect that your port is more stable, since I
merely hacked the code until it compiled and ran---hardly the
way to produce a reliable programming environment.  :-)  It
seems I should have waited a day and I could have saved myself
the trouble.  :-)

I also made an abortive effort at getting Objective CAML running
last night, but abandoned that fairly quickly---it was harder to
port, and isn't ``standard.''

Anyway, once again, thanks to all who responded.  It's nice to
have SML under Plan 9!

	- Dan C.

Re: [9fans] python and lua

[Russ Cox]

> What kind of situations?
> I asked this because I've never seen it.

Usually a terminal booted from local disk
can't sustain more than a few minutes of local disk swapping
before the window system or kfs swaps in a bogus page
and dies.  

Try running a few instances of the following program

	for(i in `{seq 10})
		memeat -x 10000000

and sit back.  This doesn't seem to happen when swapping
to a network file server.  Perhaps the timing is different.

I suspect something in the x86 memory management code,
although presotto says the carreras had similar problems.
I spent a day this summer trying to find anything, but
like everyone else came up empty handed.  

Instead, I moved more memory in from another machine
and turned off swapping.  On a laptop, of course,
this is less of an option, but I don't run my laptop
with swapping enabled either.  I'd much rather see 
"no physical memory" and type ^t^t k.

Russ


g% cat memeat.c
#include <u.h>
#include <libc.h>

void
main(int argc, char **argv)
{
	int xflag=0;
	int i, n;
	char *p;

	ARGBEGIN{
	case 'x':
		xflag=1;
	}ARGEND;
	n = atoi(argv[0]);
	p = malloc(n);
	memset(p, 0, n);
	i=0;
	for(;;) {
		sleep(1000+1000*(rand()%8));
		if(xflag)	memset(p, i++, n);
	}
}
g%

[9fans] re: paging

[Scott Schwartz]

> "no physical memory" and type ^t^t k.

I once did something like that, and killed my local kfs.  Bye filesystem!

Re: [9fans] re: paging

[paurea]

Scott Schwartz writes:
 > From: Scott Schwartz <schwartz@bio.cse.psu.edu>
 > 
 > > "no physical memory" and type ^t^t k.
 > 
 > I once did something like that, and killed my local kfs.  Bye filesystem!

Happened to me to while playing with the swap...
-- 
                 Saludos,
                         Gorka

"Curiosity sKilled the cat"
-- 
    /"\
    \ /    ascii ribbon campaign - against html mail 
     X                           - against ms attachments
    / \

Re: [9fans] weird print(2) problems...

[Russ Cox]

> But, having a program that does a `print("");' render an acme window
> unusable for all intents and purposes still seems like a problem that
> needs to be fixed somehow.

We've overloaded a read of length 0 with
two meanings, and there's no good way out now.
Should write(1, "", 0) render an acme window
unusable?  Maybe it's acme's fault.  Telnetd waits
for three zero-length writes, so that
	g% echo -n
dosen't hang up the connection but
	g% echo -n; echo -n; echo -n
still does.  We can dive into heuristics
ad nauseum, but I think we're just stuck
with the overload until everyone switches
to a language with tupled return values
like Limbo.

Russ

Re: [9fans] weird print(2) problems...

[Scott Schwartz]

| We can dive into heuristics
| ad nauseum, but I think we're just stuck
| with the overload until everyone switches
| to a language with tupled return values
| like Limbo.

If you don't mind changing old code (and I think it's fair to say
that Plan 9 fans are selected for that) you could return -2 for EOF,
or return -1 and check errstr, or have the read library function return
the length via a pointer argument and return +/0/- for ok/eof/err,
or something along those lines.

Re: [9fans] pptp.c install failed

[Russ Cox]

> pptp.c:92 function args not checked: threadnonotes

threadnonotes is in the 03270425a update.

> pptp.c:671 name not declared: ERRMAX
> pptp.c:671 array size must be a positive constant
> pptp.c:674 function args not checked: rerrstr

sorry.  i was using a new interface.
change it to e[ERRLEN] and rerrstr(e) and
add the function

void
rerrstr(char *buf)
{
	char tmp[ERRLEN];

	errstr(tmp);
	memmove(buf, tmp, ERRLEN);
	errstr(tmp);
}

before there.

russ

Re: [9fans] pptp.c install failed

[Scott Schwartz]

> rerrstr(char *buf)

Why not ``rerrstr(char *buf, int size)''?
Or even ``rerrstr(Str buf)''?

C needs a counted array type, but until then we shouldn't
cut corners.

Re: [9fans] pptp.c install failed

[Dan Cross]

In article <20011111211751.23249.qmail@g.bio.cse.psu.edu> you write:
>C needs a counted array type

I disagree.  What we need is a new systems programming language that
includes a first-class string type that can grow dynamically.  Limbo
does this, but I don't think it goes far enough in other areas
(functions should be first-class, too, and where's my generic
dictionary?  If I ever have to code another set of freakin' hash table
routines...  I mean come on, that's not skill, it's tedium).

C is *really great* for what it does, but all too often it becomes the
language of choice when it shouldn't be.  If Inferno taught us nothing
else, it's that it needn't be a one-man game.  Large chunks of the
Inferno kernel are written in C, but all of the user-land stuff is done
in Limbo.  If we could take that concept of a two-man game and apply it
to Plan 9, we'd have an incredibly powerful system (but be even further
marginalized).

I guess what I'm really looking for is something like ``Limbo vs. ML''
meets ``?[cl]'' to replace C at the user level.

	- Dan C.

Re: [9fans] pptp.c install failed

[Boyd Roberts]

Scott Schwartz wrote:
> C needs a counted array type, but until then we shouldn't
> cut corners.

No, C needs to be left alone.  Use limbo.

Re: [9fans] pptp.c install failed

[William S .]

OK, I applied the changes as you specified below
and it installed. However, when I ran pptp
this happened:


term% ip/ipconfig ether /net/ether0 10.0.0.150 255.255.255.0
ip/ipconfig: binding device: dial 0x800 failed
term%

Is something configured incorrectly that I need to
change?

Thank you,

Bill

On Sun, Nov 11, 2001 at 03:35:38PM -0500, Russ Cox wrote:
> > pptp.c:92 function args not checked: threadnonotes
>
> threadnonotes is in the 03270425a update.
>
> > pptp.c:671 name not declared: ERRMAX
> > pptp.c:671 array size must be a positive constant
> > pptp.c:674 function args not checked: rerrstr
>
> sorry.  i was using a new interface.
> change it to e[ERRLEN] and rerrstr(e) and
> add the function
>
> void
> rerrstr(char *buf)
> {
> 	char tmp[ERRLEN];
>
> 	errstr(tmp);
> 	memmove(buf, tmp, ERRLEN);
> 	errstr(tmp);
> }
>
> before there.
>
> russ

Re: [9fans] on TCP vs IL

[Russ Cox]

ggm@apnic.net:
> In designing IL over IP, I suspect the network transport people face the
> same problems TCP does. To argue successfully for a *radically*
> different approach demands a bit of rigour. What is the core abstraction in
> IL which makes it so compelling? Whats its addressing schema in the packets.
> What does it offer routers in terms of knowledge of end-to-end flows, or
> in proving for the Clark end-to-end model irrespective of the attempts to
> make routers over-smart?

You could read the paper to answer your fancy questions.
hget http://plan9.bell-labs.com/sys/doc/il/il.pdf | page -w

It's not radically different.  Think TCP without worrying about
congestion in any way, shape, or form.  For RPC over an ethernet
that isn't overused, the claim is that these are unnecessary
because RPCs are inherently flow controlled.

cross@math.psu.edu:
> Yes, but isn't il a lot more efficient on the wire than TCP,
> particularly over mostly reliable local area networks?  TCP has a lot
> of baggage to deal with high loss, high latency, networks with moderate
> bandwidth at the expense of higher bandwidth, lower latency, low loss
> networks; in other words, it doesn't cope well with short networks.  :-)

TCP is usable over long and short networks.  IL is usable only over
short networks.  If I had to pick just one, guess which one I'd use?
Wouldn't you rather use the general solution than the specialized one?

TCP is probably only slightly less efficient on the wire than IL.
TCP has all that baggage, yes, but it won't get used on local
ethernets unless the net is in big trouble.  I have no numbers
to back up my ``only slightly less efficient'' assertion.  But then,
you haven't presented any numbers either.  Local networks are
fast enough that it just doesn't matter.

Russ

Re: [9fans] on TCP vs IL

[George Michaelson]

> It's not radically different.  Think TCP without worrying about
> congestion in any way, shape, or form.  For RPC over an ethernet
> that isn't overused, the claim is that these are unnecessary
> because RPCs are inherently flow controlled.

That reads like a claim which is worth betting against in deployment.

Like, deploy Plan9 in a dealing room with millions of packets and suddenly
maybe the 'ethernet which isn't overused' is not so clear. Or, have to share
media with live 40Mbit HDTV steams.

Saying RPC are inherently flow controlled also implies inherently single-
threaded RPC models, no parallelism in the procedure call layer for a given
binding sounds like an awfully big assumption. Sure, that way lies madness
but multiplexing does happen.

re-assuring its essentially a TCPlike protocol. It would be interesting to
see if it had the same end-to-end performance with less cost for a reliable
transport.

cheers
	-George

(thanks for the docref btw)

--
George Michaelson       |  APNIC
Email: ggm@apnic.net    |  PO Box 2131 Milton QLD 4064
Phone: +61 7 3367 0490  |  Australia
  Fax: +61 7 3367 0482  |  http://www.apnic.net

Re: [9fans] on TCP vs IL

[Dan Cross]

In article <20011121010744.C4DBB19A46@mail.cse.psu.edu> you write:
>TCP is usable over long and short networks.  IL is usable only over
>short networks.  If I had to pick just one, guess which one I'd use?
>Wouldn't you rather use the general solution than the specialized one?

A chainsaw will cut both butter and trees.  A butter knife will cut
both as well, but will be very much less efficient cutting down a
tree.

If I had to choose only one....  I'd probably pick the chainsaw so as
to also be able to terrorize those who ask such silly rhetorical
questions.  :-)

The analogy is strained, perhaps, but apropos.  il seems like the
buffer knife.  It's great for cutting butter.  TCP is like the
chainsaw, it's great for cutting down trees (and terrorizing half-naked
coeds in B flicks), but makes a huge mess when buttering your toast.
What ever happened to the right tool for the job?  Is il just too much
of a maintenance hassle so as to be not worth it for local area networks?

(And no, I've never terrorized anyone with a chainsaw, nor would I.  :-)

>TCP is probably only slightly less efficient on the wire than IL.

I've read differently; see below.

>TCP has all that baggage, yes, but it won't get used on local
>ethernets unless the net is in big trouble.

Some of that baggage gets used no matter what (all the window size
negotiation stuff, for instance).

>I have no numbers to back up my ``only slightly less efficient''
>assertion.  But then, you haven't presented any numbers either.

Of course I didn't post any numbers; I was asking a question.  If I'd
already known the answer, why would I have asked?  :-)  But since you
brought it up....

Once, I sat down on a Saturday (it was raining) and I read the entire
9fans archives.  Contained there in was a detailing of someone's
experience running Plan 9 over a 10Mbps Ethernet.  When using IL, they
used up something like 30% of the available bandwidth to move data at
some rate.  When they switched to TCP, bandwidth utilization jumped up
to something like 80%.  Granted, that's on a much slower form of
Ethernet than what's commonly used today, and the TCP implementation
has been much improved, but one gets the impression that IL requires
rather less overhead than TCP.

Unfortuantely, since PSU's Computer Science department has seen fit to
put the 9fans archives on an SSL protected web server that I can't talk
to using the only computer I have net access on right now, I can't look
up the exact citation.  :-(

>Local networks are fast enough that it just doesn't matter.

Fair enough.

	- Dan C.

Re: [9fans] on TCP vs IL

[Scott Schwartz]

| Unfortuantely, since PSU's Computer Science department has seen fit to
| put the 9fans archives on an SSL protected web server that I can't talk
| to using the only computer I have net access on right now, I can't look
| up the exact citation.  :-(

Coincidentally, I keep a snapshot of the archives on my own system.
Go to http://www.cse.psu.edu/~schwartz/software.html and follow the link
labeled "older 9fans archives".

Re: [9fans] on TCP vs IL

[Steve Kilbane]

One justification for the presence of IL is that it's a simpler
protocol to implement - quicker time to get your system off the
ground, if you're starting everything from scratch. Whether IL
support actually predated TCP support is a different matter...

steve

Re: [9fans] on TCP vs IL

[Boyd Roberts]

> ...Whether IL support actually predated TCP support is a different matter...

IIRC philw did the IP stack before IL was developed.

Re: [9fans] Nagle algorithm

[Russ Cox]

> > i claim it's not the TCP/IP subsystem's responsibility to delay
> > sending something so that it can buffer up writes to make larger
> > packets.  that's for stdio or bio (or local OS equivalent).
>
> If there was a way for the user say when to set TCP's PUSH bit,
> would that do the job?

Why would you want this?  I thought the above
was a very effective argument.

Russ

Re: [9fans] Nagle algorithm

[Scott Schwartz]

| > > i claim it's not the TCP/IP subsystem's responsibility to delay
| > > sending something so that it can buffer up writes to make larger
| > > packets.  that's for stdio or bio (or local OS equivalent).
| >
| > If there was a way for the user say when to set TCP's PUSH bit,
| > would that do the job?
|
| Why would you want this?  I thought the above
| was a very effective argument.

If user level buffering isn't needed, then why use it?  TCP is what it
is; we might as well use what it offers.  The normal unix api doesn't
give the user a way to tell tcp when pending data should be flushed,
but maybe it should have.  I believe that windows and linux have ways
to do that, so apparently some other people think so too.  (But Charles
says that Nagle turns off PSH.  Oh well.)

Re: [9fans] python

[Jonathan Sergent]

> Supposedly a Python port exists, but the URL
> on the Wiki and in the Plan 9 FAQ doesn't work.
>
> Anyone have other details?  Do you know if it
> was a native port or an APE port?

Someone appears to have lost it on the FTP server.
I can't replace it for the mean time due to the AT&T/@Home meltdown.

I will see if the people that run the FTP server know what happened to it.

It was an APE port.  It had some bugs (plus I think it may have tickled
some things that aren't supported by APE).  I lost interest.

I think a native port would be better so that one could more easily write
modules for 9p, drawing, controls, etc.


--jss.

[9fans] semaphores

[Russ Cox]

I just wrote these for a porting project and
then discovered that I didn't need them.
However, they seem a little subtle to me
(I gave up the first couple times I tried)
so I figured I'd toss them out for others
and to see if anyone noticed any problems.

Russ

/*
 * Semaphore support.
 *
 * The data QLock could be a Lock if you care;
 * it protects the n and need values.
 *
 * The wait QLock manages the line of people waiting to
 * acquire the semaphore.  If you manage to qlock it,
 * it's your turn.  If n isn't big enough for you, record
 * your needs and rendezvous on the Sema; once incsema
 * makes n big enough, it will rendezvous with you.
 */
typedef struct Sema Sema;
struct Semaphore {
	QLock data;
	QLock wait;
	int n;
	int need;
};

void
incsema(Sema *s, int c)
{
	qlock(&s->data);
	s->n += c;
	if(s->need > 0 && s->n >= s->need){
		rendezvous(s, 0);
		s->need = 0;
	}
	qunlock(&s->data);
}

void
decsema(Sema *s, int c)
{
	qlock(&s->wait);
	qlock(&s->data);
	if(s->n < c){
		s->need = c;
		qunlock(&s->data);
		rendezvous(s, 0);
		qlock(&s->data);
	}
	assert(s->n >= c);
	s->n -= c;
	qunlock(&s->data);
	qunlock(&s->wait);
}

int
candecsema(Sema *s, int c)
{
	int ret;

	if(!canqlock(&s->wait))
		return 0;
	qlock(&s->data);	/* won't block for long */
	if(s->n >= c){
		ret = 1;
		s->n -= c;
	}else
		ret = 0;
	qunlock(&s->data);
	qunlock(&s->wait);
	return ret;
}

Re: [9fans] semaphores

[Scott Schwartz]

A previous edition's malloc used a pipe with a byte in it as a semaphore.
I thought that was a lovely solution, given shared file descriptors.

Re: [9fans] semaphores

[Boyd Roberts]

Scott Schwartz wrote:
> A previous edition's malloc used a pipe with a byte in it as a semaphore.

I wrote a POP client/daemon on unix that kept the password in a pipe
to minimise the probability of it ending up in a core dump.

Of course on plan 9 and inferno there are no cores -- another plus.

Re: [9fans] semaphores

[Ronald G Minnich]

On Tue, 15 Jan 2002, Scott Schwartz wrote:

> A previous edition's malloc used a pipe with a byte in it as a semaphore.
> I thought that was a lovely solution, given shared file descriptors.

those are great if you have a long time to wait, I use them too. But
memory-based ones like Russ posted are also mighty handy!

ron

Re: [9fans] semaphores

[Ralph Corderoy]

Hi Russ,

> I figured I'd toss them out for others and to see if anyone noticed
> any problems.
> ...
> typedef struct Sema Sema;
> struct Semaphore {
>       QLock data;
>       QLock wait;
>       int n;
>       int need;
> };
>
> void
> incsema(Sema *s, int c)
> {
>       qlock(&s->data);

Should that be `typedef struct Semaphore Sema;' in order for s->data to
work?


Ralph.

Re: [9fans] how small can you get

[Russ Cox]

I just built a stripped down pc kernel --
IDE, CGA, no ether, no network, and got 
about 361kb.

g% size 9tiny
247634t + 78200d + 35628b = 361462	9tiny
g% ls -l 9tiny
--rwxrwxr-x M 173507 rsc sys 447113 Feb  7 20:42 9tiny
g% 

It's hard to include ethernet but not IP,
as you requested, because there are a few
ether routines that depend on functions in
the IP code.

Russ

Re: [9fans] how small can you get

[Scott Schwartz]

| I just built a stripped down pc kernel --
| IDE, CGA, no ether, no network, and got 
| about 361kb.

I'm surprised it is that big.  Back in the days of 4.2BSD, normal
kernels were smaller than that.  But maybe the vax had better code
density than x86.

Re: [9fans] how small can you get

[Ronald G Minnich]

On Thu, 7 Feb 2002, Russ Cox wrote:

> I just built a stripped down pc kernel --
> IDE, CGA, no ether, no network, and got
       ^^^

can we go to full serial console?

> about 361kb.

what happened after gzip?

many thanks.

ron

Re: [9fans] mkfile for Solaris-sparc using gcc?

[Russ Cox]

Does Solaris 8 not come with the Sun cc compiler?

I tried gcc when I did the port, and it didn't
work (or I couldn't figure out the incantation
to make it thread-aware), so I switched to cc.

Russ

Re: [9fans] mkfile for Solaris-sparc using gcc?

[Scott Schwartz]

> Does Solaris 8 not come with the Sun cc compiler?

Nope.  Unbundled product.

Re: [9fans] mkfile for Solaris-sparc using gcc?

[Boyd Roberts]

Scott Schwartz wrote:
> 
> > Does Solaris 8 not come with the Sun cc compiler?
> 
> Nope.  Unbundled product.

It was unbundled as far back at Solaris 5 or earlier.

Hello gcc ...

Re: [9fans] mkfile for Solaris-sparc using gcc?

[AMSRL-CI-CN]

"Boyd Roberts" <boyd@strakt.com> wrote...
> > > Does Solaris 8 not come with the Sun cc compiler?
> It was unbundled as far back at Solaris 5 or earlier.

Nearly all commercial versions of UNIX did the same thing,
to the dismay of those of us for whom UNIX without C isn't
really UNIX.

Re: [9fans] mkfile for Solaris-sparc using gcc?

[Ish Rattan]

On Mon, 11 Mar 2002, Russ Cox wrote:

> Does Solaris 8 not come with the Sun cc compiler?
Some do not have the money to buy it.
>
> I tried gcc when I did the port, and it didn't
> work (or I couldn't figure out the incantation
> to make it thread-aware), so I switched to cc.

Solaris does POSIX thread support via -lpthread, I shall chase
the code and see how it works.

-ishwar

Re: [9fans] Ephase question.

[Russ Cox]

> > - Unix' solution of making the remove fail with "file busy"; it was
> > always inconvenient and confusing.  They use that one for in use
> > executables.
>
> I haven't seen a version of unix do this one for a while (as in decades).
> The remove succeeds, the file goes away when the last reference does (but
> you have to have inodes ...). But maybe there is some version of Unix
> you're referencing I'm not familiar with -- there's a lot of possibilities
> out there nowadays ...

i've seen it recently on either freebsd or linux,
in the case of trying to remove or perhaps overwrite
binaries that were being executed at the time.
it was definitely a binary rather than a normal file.

Re: [9fans] Ephase question.

[Scott Schwartz]

rsc writes:
| i've seen it recently on either freebsd or linux,
| in the case of trying to remove or perhaps overwrite

It's overwrite.  (Solaris, on the other hand, blows away the process.)
So to safely (atomically) install a new executable or shared library,
you have to write it to a temp file, and then rename it into place.

Re: [9fans] Ephase question.

[Ronald G Minnich]

On Tue, 13 Aug 2002, Russ Cox wrote:

> > I haven't seen a version of unix do this one for a while (as in decades).
> > The remove succeeds, the file goes away when the last reference does (but
> > you have to have inodes ...). But maybe there is some version of Unix
> > you're referencing I'm not familiar with -- there's a lot of possibilities
> > out there nowadays ...
>
> i've seen it recently on either freebsd or linux,
> in the case of trying to remove or perhaps overwrite
> binaries that were being executed at the time.

overwrite, yeah. That EBUSY will definitely occur for overwrite in
different ways on different unices. Now I see what you meant.

On freebsd and Linux, exec happens via an mmap (more or less). Possibly
the behavioural difference you saw between binary and normal file was due
to how the kernels handle mmap for exec vs. file I/O, not due to it being
a binary vs. normal file.

ron

Re: [9fans] Ephase question.

[Alexander Viro]

On Tue, 13 Aug 2002, Ronald G Minnich wrote:

> overwrite, yeah. That EBUSY will definitely occur for overwrite in
> different ways on different unices. Now I see what you meant.
>
> On freebsd and Linux, exec happens via an mmap (more or less). Possibly
> the behavioural difference you saw between binary and normal file was due
> to how the kernels handle mmap for exec vs. file I/O, not due to it being
> a binary vs. normal file.

Yes.  Notice that both Linux and FreeBSD have few reasons even for that
protection (and it's not too consistent - e.g. shared libraries are
not protected).  It is, indeed, result of mmap() - there is a flag
(MAP_DENYWRITE) used when we map the binary and it prevents opening
file for write (and having file opened from write makes such mmap()
call fail).  IIRC, it's a compatibility with fairly old systems and
it could be killed if anyone cared enough.

There's absolutely no protection against unlink()/rename() and there's
nothing to protect against - both would keep file alive until the
final close()/munmap(), so there's nothing to break.

Re: [9fans] Ephase question.

[Alexander Viro]

On Tue, 13 Aug 2002, Russ Cox wrote:

> > > - Unix' solution of making the remove fail with "file busy"; it was
> > > always inconvenient and confusing.  They use that one for in use
> > > executables.
> >
> > I haven't seen a version of unix do this one for a while (as in decades).
> > The remove succeeds, the file goes away when the last reference does (but
> > you have to have inodes ...). But maybe there is some version of Unix
> > you're referencing I'm not familiar with -- there's a lot of possibilities
> > out there nowadays ...
>
> i've seen it recently on either freebsd or linux,
> in the case of trying to remove or perhaps overwrite
> binaries that were being executed at the time.
> it was definitely a binary rather than a normal file.

Overwrite - sure.  Remove - nope.

Re: [9fans] lp doesn't work after upgrade from downloaded cd image

[Russ Cox]

There's a bug in the lp on the CD image, due to
a bug in the APE freopen.  The version on sources
is corrected.  If I remember correctly, that doesn't
help you.

Would people find it helpful to have a ``bleeding edge''
CD image of the whole sources archive regenerated
every night that you could use to update if you can't
get to sources from inside Plan 9?

Russ

[9fans] bleeding edge sources

[John Saylor]

Hi

( 02.10.08 11:58 -0400 ) Russ Cox:
> Would people find it helpful to have a ``bleeding edge''
> CD image of the whole sources archive regenerated
> every night that you could use to update if you can't
> get to sources from inside Plan 9?

Yes, that sounds good [even though I'm just starting to use plan9].
Also, are the instructions on upgrading from inside plan9 in the wiki,
or on a man page, or in a document somewhere?

Or will it become clear as I get more comfortable with the system?

--
.--- ...

Re: [9fans] lp doesn't work after upgrade from downloaded cd image

[Scott Schwartz]

Russ writes:
| Would people find it helpful to have a ``bleeding edge''
| CD image of the whole sources archive regenerated
| every night that you could use to update if you can't
| get to sources from inside Plan 9?

Sure, that would be rather like how Debian has "stable" and "testing"
releases.

[9fans] tex erratum

[Russ Cox]

the binary /386/bin/tpic has been omitted.

	cd /sys/src/cmd/tex/tpic
	mk install

will create it.  i do not plan to update the
tex package any time soon, sorry.  i figure
no one has noticed so far...

Re: [9fans] tex erratum

[Scott Schwartz]

Russ writes:
| ...  i do not plan to update the
| tex package any time soon, sorry.  i figure
| no one has noticed so far...

Speaking of TeX, does the current version (which I admit I don't have
installed) pass the trip test?  The second edition's didn't.

Re: [9fans] Serving 9p in python - anyone started that?

[Russ Cox]

porting lib9p to python would actually be very easy.
a lot of the code in lib9p is to handle things like my
own hash tables and various kludges with function
pointers that really make objects.

i like to think of python as a limbo that doesn't require
limbo's environment and is thus more widespread.

Re: [9fans] Serving 9p in python - anyone started that?

[Scott Schwartz]

| i like to think of python as a limbo that doesn't require
| limbo's environment and is thus more widespread.

What sort of thread support does python have?  It would be great to see
it with limbo-style concurrency constructs.

Re: [9fans] Serving 9p in python - anyone started that?

[matt]

----- Original Message -----
From: "Scott Schwartz" <schwartz@bio.cse.psu.edu>
To: <9fans@cse.psu.edu>
Sent: Thursday, November 14, 2002 6:28 PM
Subject: Re: [9fans] Serving 9p in python - anyone started that?


> | i like to think of python as a limbo that doesn't require
> | limbo's environment and is thus more widespread.
>
> What sort of thread support does python have?  It would be great to see
> it with limbo-style concurrency constructs.

http://www.python.org/doc/current/lib/module-thread.html

7.4 thread -- Multiple threads of control

This module provides low-level primitives for working with multiple threads
(a.k.a. light-weight processes or tasks) -- multiple threads of control
sharing their global data space. For synchronization, simple locks (a.k.a.
mutexes or binary semaphores) are provided.

The module is optional. It is supported on Windows NT and '95, SGI IRIX,
Solaris 2.x, as well as on systems that have a POSIX thread (a.k.a.
``pthread'') implementation.

see also

http://www.python.org/doc/current/lib/module-threading.html
7.5 threading -- Higher-level threading interface

Re: [9fans] Serving 9p in python - anyone started that?

[Dan Cross]

Scott writes:
> What sort of thread support does python have?  It would be great to see
> it with limbo-style concurrency constructs.

And Matt responds:
> http://www.python.org/doc/current/lib/module-thread.html
>
> [...]

So it's the standard co-routine style.  I think that Scott is looking
for is something with a more CSP-like feel, like Limbo.  Stackless
python is doing this, which sounds pretty sweet, but I think that
python is getting a little heavy around the waste.  At least, the
standard distribution is; some objects are marked deprecated and such,
and flag errors at runtime when invoked in the interactive environment,
but not when run as a script, etc....  Still, I like the language.
Ruby is another nice language in a similar vein that I like a lot.

	- Dan C.

Re: [9fans] Serving 9p in python - anyone started that?

[William Josephson]

On Thu, Nov 14, 2002 at 01:28:41PM -0500, Scott Schwartz wrote:
> | i like to think of python as a limbo that doesn't require
> | limbo's environment and is thus more widespread.
>
> What sort of thread support does python have?  It would be great to see
> it with limbo-style concurrency constructs.

I think "stackless" Python comes closest.
Should be able to find information via Google.

Re: [9fans] POSIXy V7 sh

[Dennis Ritchie]

 > Rob Pike <rob@mightycheese.com> writes:
 >> it's the v8 shell that i would like to have.

 > Anyone know of any possibility of getting the rest of the research Unix
 > code released in the same way the v7 and prior code is?

 >	- Dan C.

Until the SCO suit I was about ready to quietly slip
the V8 distribution into the TUHS archive under
the kinder-gentler SCO's license.  So far TUHS
hasn't been hassled by the new, wacky SCO,
and I'm hesitant to attract their attention to TUHS.

If Rob or someone else wants the V8 or later shell,
I'd be glad to send it.

	Dennis

Re: [9fans] POSIXy V7 sh

[Geoff Collyer]

If the licensing can be worked out, I'm pretty sure I can put my hands
on the V9 shell that I worked over, including the re-worked memory
management.

For that matter, I could probably lay hands on Dave Kapilow's
V9-on-the-Sun3 tape for TUHS if licensing were solved.

Re: [9fans] POSIXy V7 sh

[Richard Miller]

>  the new, wacky SCO,

It's all very confusing.  As far as I can tell, the new wacky SCO is
actually Caldera, which changed its name to SCO when it bought the
rights to Unix from the original SCO, which is now called Tarantella Inc.

So it's not a question of SCO changing its nature, but a case of
(legal) identity theft.

Re: [9fans] POSIXy V7 sh

[Boyd Roberts]

putting v8-ism's into the sysVr2 shell was trivial.

Re: [9fans] POSIXy V7 sh

[Douglas A. Gwyn]

Boyd Roberts wrote:
> putting v8-ism's into the sysVr2 shell was trivial.

Actually I still use the BRL version of the Bourne Shell,
which was adaptable via compile-time parameters to fit any
known Unix environment (including Research), and optionally
supported pathname completion, EMACS-like command-line
editing, job control, scrollable/searchable history, etc.
which is hard to live without once one has gotten used to
it.  I haven't tried porting it to the native Plan 9
environment.

Re: [9fans] POSIXy V7 sh

[Steve Kilbane]

Doug wrote:

> Actually I still use the BRL version of the Bourne Shell, [...]
> which is hard to live without once one has gotten used to
> it.

*Anything's* hard to live without once one has gotten sufficiently
used to it.

[9fans] 4e sam for unix

[Scott Schwartz]

Folks, I've put a link to a unix port of the 4th edition's sam on my
web site:

  http://www.cse.psu.edu/~schwartz/sam-4e-unix.tar.bz2

This requires some libraries from Russ' web site, and
a samterm from the netlib (or other) distribution.

Re: [9fans] 4e sam for unix

[boyd, rounin]

i don't understand this.  bandwidth is free.  why compress it?

bundle is nice.

Re: [9fans] 4e sam for unix

[Steve Kilbane]

Boyd wrote:
> i don't understand this.  bandwidth is free.

Not to all of us, it's not.

steve

[9fans] Fork: useless and painful?

[Andrew Simmons]

>Not to mention the fact that you have to send/receive on sockets
>and read/write on everything else so that an app has to check
>the type of any handles it is passed so that it can use the
>right calls.
Actually, under Winsock2 you can use ReadFile/WriteFile with sockets as well
as file handles. You can also use WaitForMultipleObjects, not on the socket
handle itself, but on an event object which is triggered when eg there is
data available for reading. Admittedly you'd never know this from the
documentation, which says you have to use WSAWaitForMultipleEvents, and use
WSAEvents rather than regular Windows events.

The main problem I have with Windows is not the bazillion parameters for
each function call, which you soon learn to ignore, but the fact that it
seems to consist of a random collection of constantly changing APIs
designed, if that's the right word, by different groups of people who never
talked to each other about things such as a uniform method for reporting
errors.

Re: [9fans] Fork: useless and painful?

[David Presotto]

I just tried a ReadFile on a socket on my NT system and it
failed miserably.

Re: [9fans] struct problems

[David Presotto]

>From: Scott Schwartz <schwartz@bio.cse.psu.edu>
>The best one was something like:
>	I'll use bit-fields before I use Plan 9!  - Brian Kernighan

Trust in the grep Scott:

	% grep bit /sys/games/lib/fortunes|grep field
	I'd use plan 9 before i'd use bitfields -- pjw

Re: [9fans] struct problems

[Scott Schwartz]

| Trust in the grep Scott:

Oops.  Sorry for the misquote.

Re: [9fans] struct problems

[Skip Tavakkolian]

> 	I'd use plan 9 before i'd use bitfields -- pjw

Is this why Plan9 uses pjw as the catchall glyph?

Re: [9fans] struct problems

[boyd, rounin]

> Is this why Plan9 uses pjw as the catchall glyph?

those who forget their history are doomed to repeat it ...

ever seen the pjw labs management hierarchy diagram?

or the t-shirt, or the tower, or the stolen tower template, or the thief, or the
accused thief?

Re: [9fans] struct problems

[Skip Tavakkolian]

> those who forget their history are doomed to repeat it ...

This reminds me, was there or is there a Bell-Labs historian?  I would
think some of the stories would make an interesting history book.  The
exciting ones, of course, not the belly-button-lint-picking ones ☺

Re: [9fans] struct problems

[boyd, rounin]

> This reminds me, was there or is there a Bell-Labs historian?

talk to jmk ...

Re: [9fans] struct problems

[Dennis Ritchie]

>> Is this why Plan9 uses pjw as the catchall glyph?

> those who forget their history are doomed to repeat it ...

> ever seen the pjw labs management hierarchy diagram?

> or the t-shirt, or the tower, or the stolen tower template, or the thief, or the
> accused thief?

 cf. http://spinroot.com/pico/pjw.html

	Dennis

Re: [9fans] struct problems

[matt]

> > cf. http://spinroot.com/pico/pjw.html


what a lovely story

with one slightly disturbing aspect :

"Peter agreed to let us take a plaster cast of his faces."

I hope it's a consonant added rather than a missing vowel.

Curious that the plan9 glyph isn't mentioned.

m

Re: [9fans] struct problems

[boyd, rounin]

somewhere i have the 'white shirt'.

Re: [9fans] struct problems

[boyd, rounin]

i'll have the QAB shirt in a few days

Re: [9fans] struct problems

[northern snowfall]

>
>
>i'll have the QAB shirt in a few days
>
That'd be a pretty sweet tshirt:
    Font:
        Image of the plan9 pjw glyph
    Back:
        "I always wondered what that font glyph meant..."
                             plan9 by Bell Labs
Don

Re: [9fans] struct problems

[boyd, rounin]

i could post a cropped copy of the back of it.

Re: [9fans] struct problems

[boyd, rounin]

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

goto [label that got deleted];



[-- Attachment #2: qab.jpg --]
[-- Type: image/jpeg, Size: 106910 bytes --]

Re: [9fans] struct problems

[jmk]

On Sat May 10 03:12:21 EDT 2003, dmr@plan9.bell-labs.com wrote:
> ...
>  cf. http://spinroot.com/pico/pjw.html
> ...

The above reference is not accurate regarding the versions of the
T-shirts. The original white with blue logo and the pale blue with
black logo shown in http://spinroot.com/pico/pjw_shirt_front.jpg
used a version of Duff's log with fewer lines. The second version,
done by Paul Glick, was a brighter (but still pale) blue with a
blocky 'pixelated' version of PJW's face, not the 'death-star' style
of the first.

As far as I remember, the original white was a small run of no more
than a dozen or so, done in a Portland, OR shop during a break at the
USENIX conference.

Re: [9fans] struct problems

[boyd, rounin]

> As far as I remember, the original white was a small run of no more
> than a dozen or so, done in a Portland, OR shop during a break at the
> USENIX conference.

not sure where mine is.  i was wearing at CRL one day and the lab director
was very curious about how i'd got it ...

the story i heard is that he declined the expense claim for the paint.

Re: [9fans] struct problems

[rob pike, esq.]

> the story i heard is that he declined the expense claim for the paint.

Different 'he'.  The decliner was Vic Vyssotsky.

-rob

Re: [9fans] struct problems

[boyd, rounin]

> Different 'he'.  The decliner was Vic Vyssotsky.

stranger and stranger, but you [i] learn something every day ...

    June 10-14, 1985, there were 1,730 attendees at the Portland,
    OR, meeting. Vic Vyssotsky was the keynote speaker. Other speakers
    were Gordon Bell, Eric Allman, Bjarne Stroustrup, Rob Pike, Dave Presotto,
    Andy Koenig, Tom Ferrin, Dave Yost, Dennis Ritchie, Don Libes, Mike Hawley,
    Ed Gould, Sam Leffler, Dave Korn, Kirk McKusick, Mike Karels, Brian Redman,
and . . .

http://www.usenix.org/publications/login/2000-8/usenixnews.html

hang on, google vet allt ...

    Victor Vyssotsky gave us the freedom to experiment carefully with the
    Internetgateway at Digital's Cambridge ResearchLab. NeilFishman and
   TedWojcikassisted withourexperiments at CRL's gateway.

http://www.usenix.org/publications/library/proceedings/cinci93/full_papers/treese.txt

Re: [9fans] struct problems

[Dennis Ritchie]

Boyd said,

 > not sure where [my t-shirt]  is.  i was wearing at CRL one day and the lab director
 > was very curious about how i'd got it ...

 > the story i heard is that he declined the expense claim for the paint.

Rob demurred,

 > Different 'he'.  The decliner was Vic Vyssotsky.

Assuming CRL was Digital's Cambridge (MA) research
lab, they were presumably the same person--Vic moved
there.  The story of the paint voucher can be expanded.
It was submitted to Vyssotsky, signed indeed by
G. R. Emlin (in a handwriting a graphologist would
have little trouble with).  It came back with a note
from Vic, saying approximately:

	Unfortunately I do not have authorization under
	the G.E.I. to approve real estate improvements.
	If Ms [then perhaps Mr] Emlin wishes to arrange
	a transfer to the Buildings and Grounds group, I
	will help to facilitate this.

Vic also let it be quietly known that the envelope had
been pushed to its very limit.

	Dennis

Re: [9fans] struct problems

[boyd, rounin]

From: "Dennis Ritchie" <dmr@plan9.bell-labs.com>
> Vic also let it be quietly known that the envelope had
> been pushed to its very limit.

iirc he took a short stroll to collect his thoughts on the matter.

Re: [9fans] struct problems

[boyd, rounin]

> As far as I remember, the original white was a small run of no more
> than a dozen or so, done in a Portland, OR shop during a break at the
> USENIX conference.

this sounds right;  piers, maltby and brucee were there

Re: [9fans] struct problems

[rob pike, esq.]

> As far as I remember, the original white was a small run of no more
> than a dozen or so, done in a Portland, OR shop during a break at the
> USENIX conference.

That is correct.  I think Joe Buhler had a friend who made t-shirts and
we used him.  Later, back in NJ, we took the same pattern to a shop
and made a bunch more.  The originals were polyester/cotton blend
and kinda flimsy; the later set were pure cotton and a darker (less
close to AT&T) blue.  Glick's version was much later.

-rob

Re: [9fans] struct problems

[Skip Tavakkolian]

>>> Is this why Plan9 uses pjw as the catchall glyph?
>
>> those who forget their history are doomed to repeat it ...
>
>> ever seen the pjw labs management hierarchy diagram?
>
>> or the t-shirt, or the tower, or the stolen tower template, or the thief, or the
>> accused thief?
>
>  cf. http://spinroot.com/pico/pjw.html

Thanks, now I remember.  I did read about it in the Digital Darkroom book.
But like a good story, it is fun to hear it again.

Maybe a deeper question is, why did Pike and Holzmann do it?  Was
it an inspiration that then snowballed, or was there a deeper
motivation?  The campaign to distribute it in so many forms, certainly
has a fanatical feel to it.

Re: [9fans] struct problems

[rob pike, esq.]

> why did Pike and Holzmann do it?

An imponderable.

-rob

Re: [9fans] struct problems

[boyd, rounin]

how was the 'face the nation' pjw icon encoded in troff, circa 1984?

knowing it's 'size' is trivial, but getting troff to render it, well ... think
of berkeley

Re: [9fans] struct problems

[rob pike, esq.]

> how was the 'face the nation' pjw icon encoded in troff, circa 1984?

Helvetica periods.

-rob

Re: [9fans] struct problems

[boyd, rounin]

> Helvetica periods.

nice use of the 48x48x1 and troff.

Re: [9fans] struct problems

[Anthony Mandic]

"boyd, rounin" wrote:
>
> > Is this why Plan9 uses pjw as the catchall glyph?
>
> those who forget their history are doomed to repeat it ...
>
> ever seen the pjw labs management hierarchy diagram?

	No, never.

> or the t-shirt, or the tower, or the stolen tower template, or the thief, or the
> accused thief?

	Can you be less obscure and elaborate?

-am	� 2003

Re: [9fans] struct problems

[boyd, rounin]

> Can you be less obscure and elaborate?

never ask a question you don't know the answer to :)

there are always 3 responses.

Re: [9fans] Fork: useless and painful?

[Andrew Lynch]

On Jul 10, 10:17pm, David Presotto wrote:

> I just tried a ReadFile on a socket on my NT system and it
> failed miserably.

You should upgrade to XP. There it fails with a smile on its face.

Andrew.

Re: [9fans] Fork: useless and painful?

[boyd, rounin]

> I just tried a ReadFile on a socket on my NT system and it
> failed miserably.

absolutely.  you have to cut the code into one chunk that deals with
'files' and another that deals with 'sockets' and that means threads.

jesus, these fools don't even have SIGINT.

it truly is ghastly.  it's windows 3 with dave cutler's footprints over
everything.

Re: [9fans] Fork: useless and painful?

[boyd, rounin]

> Actually, under Winsock2 you

should cut up, not across.  if you want to slash your wrists correctly.

Re: [9fans] Fork: useless and painful?

[matt]

>
>
> the fact that it
>seems to consist of a random collection of constantly changing APIs
>designed, if that's the right word, by different groups of people who never
>talked to each other about things such as a uniform method for reporting
>errors.
>
>

that's a business model, those MSDN subscriptions aren't free ya know


[at least they weren't free the day I stopped reading them]

[9fans] ipconfig dhcp vs ndb

[Scott Schwartz]

ipconfig doesn't seem to use ndb when configuring e.g. ethernet.  Is there
any reason not to?  For a standalone system I think ndb would be easier
than hardcoding the numbers in termrc.

Re: [9fans] ipconfig dhcp vs ndb

[David Presotto]

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

I used to use the ethernet address in ndb to find things.  I stopped doing
it because many of our systems roam from network to network.

If you want, I can throw in a flag that says, use ndb.

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

From: "Scott Schwartz" <schwartz@bio.cse.psu.edu>
To: 9fans@cse.psu.edu
Subject: [9fans] ipconfig dhcp vs ndb
Date: 25 Jun 2003 16:36:32 -0400
Message-ID: <20030625203632.12717.qmail@g.bio.cse.psu.edu>

ipconfig doesn't seem to use ndb when configuring e.g. ethernet.  Is there
any reason not to?  For a standalone system I think ndb would be easier
than hardcoding the numbers in termrc.

Re: [9fans] ipconfig dhcp vs ndb

[Scott Schwartz]

> If you want, I can throw in a flag that says, use ndb.

That'd be great.  Then termrc.local can arrange to pass it to ipconfig.

Re: [9fans] ipconfig dhcp vs ndb

[David Presotto]

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

-N flag now in ip/ipconfig to tell it to look in /lib/ndb for the
parameters.  It only works for ethernets.

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

From: Scott Schwartz <schwartz@bio.cse.psu.edu>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] ipconfig dhcp vs ndb
Date: Wed, 25 Jun 2003 16:50:26 -0400
Message-ID: <20030625205026.13085.qmail@g.bio.cse.psu.edu>

> If you want, I can throw in a flag that says, use ndb.

That'd be great.  Then termrc.local can arrange to pass it to ipconfig.

[9fans] mail problems..

[Apurva Mehta]

I have been trying to use plan 9 to check my email but I am getting
stuck. I have a pop3 account with gmx.net and here is what I have
typed on the command line to check it..

upas/fs -f /pop/pop.gmx.net/my_user_name

The first time I did that, I was asked for my password. It accepted it
and the I got the term% prompt again.

When I executed 'mail' from acme, it said that I had 0 messages. I
know for a fact that there were messages on the server, why were they
not downloaded?

Also, I am confused about how to send mail using an authenticated smtp
server. What do the different rewrite files do? I have edited my
rewrite.gateway file to point to my smtp server (mail.gmx.net). But
how do I handle authentication? I have also added a 'From' header file
in my /mail/box/user_name/headers file. Will this 'From' header be
used for every email I send from my account?

	- Apurva

Re: [9fans] mail problems..

[Dan Cross]

> upas/fs -f /pop/pop.gmx.net/my_user_name
>
> The first time I did that, I was asked for my password. It accepted it
> and the I got the term% prompt again.
>
> When I executed 'mail' from acme, it said that I had 0 messages. I
> know for a fact that there were messages on the server, why were they
> not downloaded?

It sounds like acme was running in a different namespace and thus didn't
see the /mail/fs that was being presented by upas/fs talking to the POP3
server.  Did you run acme in the same window you ran upas/fs in?

> Also, I am confused about how to send mail using an authenticated smtp
> server. What do the different rewrite files do? I have edited my
> rewrite.gateway file to point to my smtp server (mail.gmx.net). But
> how do I handle authentication? I have also added a 'From' header file
> in my /mail/box/user_name/headers file. Will this 'From' header be
> used for every email I send from my account?

Well, you should move rewrite.gateway to rewrite.  Authentication is
handled using smtp; change /mail/lib/remotemail such that, when it
invokes smtp, it supplies the ``-a'' and ``-u <your_user_name>''
options.  Note that authentication is a little picky in that the SMTP
server must support TLS for it to work.  The client won't authenticate
by sending a password over an unencrypted connection.  Make sure your
password on the mailserver is in a factotum that smtp can see (if
you're just using a standalone machine, that's your normal factotum).
Something like:
echo 'key proto=pass service=smtp server=''your.mail.server'' !password=''your_password''' >> /mnt/factotum/ctl
(You may not need to quote the mailserver name, nor the password, but
it won't hurt anything).

	- Dan C.

Re: [9fans] mail problems..

[Apurva Mehta]

On Tue, 24 Jun 2003 11:24:09 -0400
Dan Cross <cross@math.psu.edu> wrote:

>
> It sounds like acme was running in a different namespace and thus
> didn't see the /mail/fs that was being presented by upas/fs talking
> to the POP3 server.  Did you run acme in the same window you ran
> upas/fs in?

Thanks, I ran mail from the window I ran upas/fs from and I could read
my mail. However, it does not store a local copy of the messages, it
seems to download them from the server everytime I access my mail
box.. Is there any way to make it download a local copy while leaving
the original message on the server?

> Well, you should move rewrite.gateway to rewrite.  Authentication is
> handled using smtp; change /mail/lib/remotemail such that, when it
> invokes smtp, it supplies the ``-a'' and ``-u <your_user_name>''
> options.  Note that authentication is a little picky in that the
> SMTP server must support TLS for it to work.  The client won't
> authenticate by sending a password over an unencrypted connection.
> Make sure your password on the mailserver is in a factotum that smtp
> can see (if you're just using a standalone machine, that's your
> normal factotum). Something like:
> echo 'key proto=pass service=smtp server=''your.mail.server''
> !password=''your_password''' >> /mnt/factotum/ctl(You may not need
> to quote the mailserver name, nor the password, but it won't hurt
> anything).

I did that, but my messages do not seem to be reaching the recipients.
I will wait and see, but usually my smtp server delivers messages
almost instantly. BTW, I ran 'mail recipient_address' on the command
line and typed in a message. I then hit ESC and CTRL+D. Since I have
used justqmail in my rewrite file, I executed '/mail/lib/kickqueue'.
There was some activity on my modem and I got the prompt back..

Is this the correct way of going about sending mail? Also, my
smtp service requires that the address I am sending from should be an
@gmx.net address. I have added the line : "From: "Apurva Mehta"
<apurva@gmx.net> to my /mail/box/user_name/headers file. Will this
ensure that the 'from' address is as required by the service?

	- Apurva

Re: [9fans] mail problems..

[Russ Cox]

> Thanks, I ran mail from the window I ran upas/fs from and I could read
> my mail. However, it does not store a local copy of the messages, it
> seems to download them from the server everytime I access my mail
> box.. Is there any way to make it download a local copy while leaving
> the original message on the server?

It downloads every time you start it, but it does not delete them,
and if you leave it running, then it will dial out periodically
to check for new messages but not redownload the old ones.
If you delete them via mail or Mail, they get deleted from the
server.

Every time you run the "mail" command, it will dial out just to
see if there are new messages.  That might be the delay you are seeing.

> I did that, but my messages do not seem to be reaching the recipients.
> I will wait and see, but usually my smtp server delivers messages
> almost instantly. BTW, I ran 'mail recipient_address' on the command
> line and typed in a message. I then hit ESC and CTRL+D. Since I have
> used justqmail in my rewrite file, I executed '/mail/lib/kickqueue'.
> There was some activity on my modem and I got the prompt back..

tail /sys/log/smtp and /sys/log/mail.  Probably an error occurred
and they got dropped on the floor (the bounces bounced too).
You can look at the queue in /mail/queue/$user.

> Is this the correct way of going about sending mail? Also, my
> smtp service requires that the address I am sending from should be an
> @gmx.net address. I have added the line : "From: "Apurva Mehta"
> <apurva@gmx.net> to my /mail/box/user_name/headers file. Will this
> ensure that the 'from' address is as required by the service?

Sure, but you also need to edit /mail/lib/remotemail to set the
from domain there.  The headers file just affects the headers,
not the smtp envelope.

Russ

Re: [9fans] mail problems..

[Richard Miller, miller]

> It downloads every time you start it, but it does not delete them,
> and if you leave it running, then it will dial out periodically
> to check for new messages but not redownload the old ones.

By default, "periodically" means every 60 seconds, which is not a very
good choice if you have a dial-up connection or a busy mail server (or
both).  You can change this to N seconds by writing to /mail/fs/mbox/ctl
the (undocumented?) control message 'refresh N'.

Re: [9fans] mail problems..

[Russ Cox]

> By default, "periodically" means every 60 seconds, which is not a very
> good choice if you have a dial-up connection or a busy mail server (or
> both).  You can change this to N seconds by writing to /mail/fs/mbox/ctl
> the (undocumented?) control message 'refresh N'.

Is this too frequent or not frequent enough?  I usually do 15 seconds.

Russ

Re: [9fans] mail problems..

[Scott Schwartz]

> Is this too frequent or not frequent enough?  I usually do 15 seconds.

Our computer center won't let you poll the POP server more often than
once every few minutes.

Gripe: why don't ISPs pick some way to notify POP users, instead of
making them poll.  comsat wasn't rocket science, and all the instant
messager programs these days are a plausible alternative.

Re: [9fans] mail problems..

[boyd, rounin]

> Gripe: why don't ISPs pick some way to notify POP users, instead of
> making them poll.  comsat wasn't rocket science, and all the instant
> messager programs these days are a plausible alternative.

hmm,  i'd like to hear your design that would be reliable and scale
to thousands of users.  iirc, comsat was a toy that ran on old
machines in very limited user environments.

reliable scaleability is a hard problem.

Re: [9fans] mail problems..

[Scott Schwartz]

| hmm,  i'd like to hear your design that would be reliable and scale
| to thousands of users.

How about zephyr?  Or AIM?

| reliable scaleability is a hard problem.

Fine, so do best effort delivery and retry every 10 minutes.

Re: [9fans] mail problems..

[boyd, rounin]

> Fine, so do best effort delivery and retry every 10 minutes.

best effort?  no way.

maybe this might be an interesting read?

     http://www.strakt.com/~jacob/ifc-accu.ps

Re: [9fans] mail problems..

[Scott Schwartz]

Oh, come on... just to indicate that email is waiting?
A udp packet once in a while is more than enough.

It's all fantasy anyway.  People won't stop polling,
because their pop clients will continue to let them.

Re: [9fans] mail problems..

[boyd, rounin]

> Oh, come on... just to indicate that email is waiting?
> A udp packet once in a while is more than enough.

UDP?  is that reliable?  does it scale?

Re: [9fans] mail problems..

[Dan Cross]

I think Scott's point is that, for this application, it doesn't matter.
A UDP packet that said, ``hey, you just got mail,'' would certainly scale
to thousands of users.  Unfortunately, no user agent software supports
such a thing, and most over-zealous firewall administrators would block
it anyway.  In that case, one could certainly fallback to polling.

	- Dan C.

Re: [9fans] mail problems..

[boyd, rounin]

the whole thing is a fiasco.  it is next to impossible to get mail
notification 'right' and if it were my firewall(s) next to nothing
would be allowed to wander through.  isn't that the point?

having said that, firewalls are are just all wrong.

tomorrow is 'will do tcp/ip for food day', plus a chat to the
Swedish Embassy -- that should be fun :)

gawd, tcp is 20+ years old iirc ...

Re: [9fans] mail problems..

[andrey mirtchovski]

On Thu, 26 Jun 2003, boyd, rounin wrote:

> the whole thing is a fiasco.  it is next to impossible to get mail
> notification 'right'

mail notification seems to work right with plumbing...

Re: [9fans] mail problems..

[boyd, rounin]

> mail notification seems to work right with plumbing...

i'm thinking on a slightly more global scale ...

Re: [9fans] mail problems..

[andrey mirtchovski]

On Thu, 26 Jun 2003, boyd, rounin wrote:

> > mail notification seems to work right with plumbing...
>
> i'm thinking on a slightly more global scale ...
>

i'm sorry, i was thinking on a scale appropriate for this list :)

Re: [9fans] mail problems..

[okamoto]

> gawd, tcp is 20+ years old iirc ...

then, what is your solution?

Kenji

Re: [9fans] mail problems..

[boyd, rounin]

> then, what is your solution?

specification of the problem would be a start.

Re: [9fans] mail problems..

[Scott Schwartz]

| > Oh, come on... just to indicate that email is waiting?
| > A udp packet once in a while is more than enough.
|
| UDP?  is that reliable?  does it scale?

Sure.  It works fine for much larger things, like DNS and AIM.  It's just
the right tool for this job.

Re: [9fans] mail problems..

[boyd, rounin]

> Sure.  It works fine for much larger things, like DNS and AIM.  It's just
> the right tool for this job.

http://www.theregister.co.uk/content/6/31392.html

Re: [9fans] mail problems..

[matt]

boyd, rounin wrote:

>>Sure.  It works fine for much larger things, like DNS and AIM.  It's just
>>the right tool for this job.
>>
>>
>
>http://www.theregister.co.uk/content/6/31392.html
>

That seems to suggest that UDP works for billions of daily DNS requests.

Sounds like a few thousand mail clients per server would be well with
its capability.

It might make you reconsider knowing that Hotmail / Passport / MSN
Messenger offer that exact service.
Messenger notifies you if you have any Hotmail mail arrive, if that
isn't a proof of concept then I don't know what you would consider.

If the Beast can make it work for Hotmail & Windows then surely using
distributed computing should make it all the easier and less resource
hungry.

Sounds to me that this would be the sort of application for which the
use of Secstore/Factotum is intended.

Authenticating the sender will be mandated for communications with
Government somewhere soon, be that tax returns or road tolls or
something. Microsoft is already trying to get Passport as the de-facto :
http://theregister.co.uk/content/archive/24938.html

Re: [9fans] mail problems..

[boyd, rounin]

> That seems to suggest that UDP works for billions of daily DNS requests.

sure, and the reason it works is cos of the TCP zone transfers that populate
the planet with a bunch of local caches.

Re: [9fans] mail problems..

[matt]

boyd, rounin wrote:

>>That seems to suggest that UDP works for billions of daily DNS requests.
>>
>>
>
>sure, and the reason it works is cos of the TCP zone transfers that populate
>the planet with a bunch of local caches.
>

sooo, that's exactly what mail servers are, local caches

an email address is a handle used to retrieve a list of local caches
from the MX records

but you know all this.

Your original argument was against the local cache pushing something to
the client over UDP because UDP doesn't scale.

> hmm,  i'd like to hear your design that would be reliable and scale to thousands of users.

Well, you've heard the design and Microsoft already successfully scale it to well over thousands of users all day every day.




Dan C said :
> A UDP packet that said, ``hey, you just got mail,'' would certainly scale to thousands of users.
> Unfortunately, no user agent software supports such a thing,


Sorry Dan, although I don't know which client I'm pretty sure we can draw conclusions from Exchange supporting the mechanism similar to the one described :


    http://support.microsoft.com/default.aspx?scid=kb%3Ben-us%3B264035


    MORE INFORMATION

New mail notification messages are sent by means of UDP packets from the
server to the client. The ports used for this notification are set by
the client when the client logs on to the information store.

As part of the log on process to the information store, the client tells
the server the IP address and port where it expects to receive new mail
notification messages. This will be a UDP port in the 1024-65535 range.

When the server receives a mail message for a mailbox that a client is
logged on to, it opens a UDP port dynamically, and sends a packet to the
IP address and port registered by the client logged on to that mailbox.

Because the client picks a port at startup and the server does not
always use the same port when sending the notification, there is no way
to predict either the source or destination ports that this traffic will
use.

Re: [9fans] mail problems..

[boyd, rounin]

> an email address is a handle used to retrieve a list of local caches
> from the MX records
>
> but you know all this.

yes, i do.

> Your original argument was against the local cache pushing something to
> the client over UDP because UDP doesn't scale.

no it doesn't and my other point is it's not reliable, so you just bang out
packets until one finds its destination.  this, in a worst case scenario,
would flood the 'network'.

it 'works' by virtue of the fact that the problem has been reduced in scale.

'caches are multiplicative' i think rob said in his sam paper.

and there's NAT and firewalls, just for extra points etc, etc ...

Re: [9fans] mail problems..

[David Presotto]

It would be silly to only announce mail messages.  The daemon on the client
should generate plumbing messages.  We should have broadcast groups too.
I think we should call it .NET instant messenger.

Re: [9fans] mail problems..

[Richard Miller, miller]

>> By default, "periodically" means every 60 seconds, which is not a very
>> good choice if you have a dial-up connection or a busy mail server (or
>> both).  You can change this to N seconds by writing to /mail/fs/mbox/ctl
>> the (undocumented?) control message 'refresh N'.
>
> Is this too frequent or not frequent enough?  I usually do 15 seconds.

Too frequent with a dial-up connection - particularly in the UK where you
get charged by the minute for every call (even on the local exchange).

Too frequent for a server like pop3.demon.co.uk, which at busy times can
take two or three minutes just to login and STAT.

Anyway, my solution to the notifcation problem, now that I have broadband,
is to switch to a provider who can forward mail directly by SMTP.

-- Richard

Re: [9fans] mail problems..

[Apurva Mehta]

On Tue, 24 Jun 2003 20:13:03 -0400
"Russ Cox" <rsc@plan9.bell-labs.com> wrote:

> Every time you run the "mail" command, it will dial out just to
> see if there are new messages.  That might be the delay you are
> seeing.

How does it dial out automatically? I have not saved any connection
information anywhere (yet).  I connect using ip/ppp ..

> tail /sys/log/smtp and /sys/log/mail.  Probably an error occurred
> and they got dropped on the floor (the bounces bounced too).
> You can look at the queue in /mail/queue/$user.

The /sys/log/smtp file was empty. The /sys/log/mail file did list the
mails I had tried to send, but there was no error message associated
with any of them.

> Sure, but you also need to edit /mail/lib/remotemail to set the
> from domain there.  The headers file just affects the headers,
> not the smtp envelope.

I set fd=gmx.net in /mail/lib/remotemail .. Is this correct? Also, in
the/sys/log/mail file it continues to list the sender as 'apurva',
with no mention of the gmx.net domain. Personally, I feel that this
may be the reason why my emails are not reaching.

	- Apurva

Re: [9fans] mail problems..

[Russ Cox]

> upas/fs -f /pop/pop.gmx.net/my_user_name
>
> The first time I did that, I was asked for my password. It accepted it
> and the I got the term% prompt again.
>
> When I executed 'mail' from acme, it said that I had 0 messages. I
> know for a fact that there were messages on the server, why were they
> not downloaded?

This is because acme and your terminal are running
in different name spaces.  You need to start upas/fs
in your profile, before rio, to make it appear everywhere.
Alternately, you can use the apparently undocumented -s
option to upas/fs to post a service file:

	upas/fs -f -s /pop/pop.gmx.net/my_user_name

and then execute

	Local mount /srv/upasfs.$user /mail/fs

in acme to access it.

Russ

Re: [9fans] mail problems..

[Apurva Mehta]

On Tue, 24 Jun 2003 20:16:54 -0400
"Russ Cox" <rsc@plan9.bell-labs.com> wrote:

> This is because acme and your terminal are running
> in different name spaces.  You need to start upas/fs
> in your profile, before rio, to make it appear everywhere.
> Alternately, you can use the apparently undocumented -s
> option to upas/fs to post a service file:
>
> 	upas/fs -f -s /pop/pop.gmx.net/my_user_name
>
> and then execute
>
> 	Local mount /srv/upasfs.$user /mail/fs
>

When I execute the last line in acme, I get the error
/srv/upasfs.apurva file not found.. How should I create it?

	- Apurva

Re: [9fans] The new ridiculous license

[Keith Nash]

On Tuesday 17 June 2003 16:04, Theo de Raadt wrote:

> That is not a license which makes it free.  It is a *contract* with
> consequences; let me be clear -- it is a contract with consequences
> that I am unwilling to accept.

This is an aspect of open-source license wars that I was not previously aware of.

If the license is a contract, that contract is not enforceable as such in court.  The reason (at least in English law, perhaps someone can comment on NY/USA law) is that for a contract to be created, there must be an exchange of value - i.e. Lucent gives you the software, you have to give them something of value (e.g. cash) in return.

Therefore, no license where the software is given away can be a contract: it is merely a grant of rights to the licensor's copyrighted material (and/or patents and trademarks) - which is exactly what Theo would like it to be.

> Or perhaps you guys are utterly blind to what is happening with IBM
> and SCO right now.

The IBM/SCO case is different, because they have an enforceable contract: IBM paid SCO for certain rights.

Keith.

Re: [9fans] The new ridiculous license

[boyd, rounin]

> If the license is a contract, that contract is not enforceable as such in
court.
> The reason (at least in English law, perhaps someone can comment on
> NY/USA law) is that for a contract to be created, there must be an exchange
> of value - i.e. Lucent gives you the software, you have to give them something
> of value (e.g. cash) in return.

UK law, a contract has three things:

    - offer [the thing being sold]
    - acceptance [when you say 'i wanna buy it']
    - consideration [the thing given, usually money, so that you get the thing
you want]

that's a common law thing.

contracts are usually things that you sign that both sides are bound by.

however, having said that, in sweden (god forbid) if there's a typo in the
contract and you buy, say, volvo for 1 �re, the court will quash the
contract because it's 'obviously' 'wrong'.

i suspect that the 'problem' with the plan 9 licence is because lucent is a
us company who must comply with ITAR, the Denied Parties List, and
various other export controls --  take it up with the us govt.  end user
certificates, etc etc ...

eg. i can tell you of the existance of the Denied Parties List [DPL], but i
cannot tell you who's on it.  it's so long ago i did the DPL stuff i don't
even want to talk about it, but it still applies to me.

i do find it _hysterical_ that the BSD boys want the plan 9 compilers.

Re: [9fans] The new ridiculous license

[David Presotto]

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

Follow the Part 772 link on our download page.  That's the denied parties
list.

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

From: "boyd, rounin" <boyd@insultant.net>
To: <9fans@cse.psu.edu>
Subject: Re: [9fans] The new ridiculous license
Date: Thu, 19 Jun 2003 15:51:26 +0200
Message-ID: <002301c33669$e2f6d8c0$e3944251@insultant.net>

> If the license is a contract, that contract is not enforceable as such in
court.
> The reason (at least in English law, perhaps someone can comment on
> NY/USA law) is that for a contract to be created, there must be an exchange
> of value - i.e. Lucent gives you the software, you have to give them something
> of value (e.g. cash) in return.

UK law, a contract has three things:

    - offer [the thing being sold]
    - acceptance [when you say 'i wanna buy it']
    - consideration [the thing given, usually money, so that you get the thing
you want]

that's a common law thing.

contracts are usually things that you sign that both sides are bound by.

however, having said that, in sweden (god forbid) if there's a typo in the
contract and you buy, say, volvo for 1 €re, the court will quash the
contract because it's 'obviously' 'wrong'.

i suspect that the 'problem' with the plan 9 licence is because lucent is a
us company who must comply with ITAR, the Denied Parties List, and
various other export controls --  take it up with the us govt.  end user
certificates, etc etc ...

eg. i can tell you of the existance of the Denied Parties List [DPL], but i
cannot tell you who's on it.  it's so long ago i did the DPL stuff i don't
even want to talk about it, but it still applies to me.

i do find it _hysterical_ that the BSD boys want the plan 9 compilers.

Re: [9fans] The new ridiculous license

[boyd, rounin]

> Follow the Part 772 link on our download page.  That's the denied parties
list.

well, that looks like a bunch of definitions.

when i was a lad, the names of the the 'denied parties' were on the list.

they could _not_ be revealed.  well, you could, but you'd be in a
'world of pain'.

i had a bourne shell script which used 'agrep' to search it.

Re: [9fans] The new ridiculous license

[Erik Terpstra]

boyd, rounin wrote:

>
> i do find it _hysterical_ that the BSD boys want the plan 9 compilers.
>

Obviously because they think the compilers are of great value, that's a
compliment if you ask me. And even better, they are willing to share
their improvements for the benefit of us all.

What's hysterical about that?

Re: [9fans] The new ridiculous license

[boyd, rounin]

> What's hysterical about that?

but i thought gcc was the 'one true compiler' ...

Re: [9fans] The new ridiculous license

[Dan Cross]

> > i do find it _hysterical_ that the BSD boys want the plan 9 compilers.
>
> And even better, they are willing to share
> their improvements for the benefit of us all.

Perhaps what Boyd finds hilarious is the idea of them making improvements.

	- Dan C.

Re: [9fans] The new ridiculous license

[boyd, rounin]

> Perhaps what Boyd finds hilarious is the idea of them making improvements.

yes, i'd like to see some improvements.  where could we begin? err, killing

    - NFS
    - csh
    - vi
    - gcc
    - sendmail
    - symbolic links
    - emacs
    - curses
    - X11
    - unix domain sockets
    - 'lpr' protocol
    - vi/emacs line editing in bash
    - 2M SLOC which is the linux kernel

and that's just for starters ...

then again, i'd be more than happy to see my world view contradicted.

Re: [9fans] The new ridiculous license

[Jack Johnson]

On Thu, 19 Jun 2003, boyd, rounin wrote:
> yes, i'd like to see some improvements.  where could we begin? err, killing
>     - sendmail
>
> then again, i'd be more than happy to see my world view contradicted.

I've never been a sendmail fan, but the latest SysAdmin has a great
article on securing sendmail on random hosts (if you find you have to do
that sort of thing).  It made me take a second look at sendmail, and now I
don't hate it (for the application outlined in the article).

-Jack

Re: [9fans] The new ridiculous license

[Jason Gurtz]

Jack Johnson wrote:

> On Thu, 19 Jun 2003, boyd, rounin wrote:
>
>>yes, i'd like to see some improvements.  where could we begin? err, killing
>>    - sendmail
>>
>>then again, i'd be more than happy to see my world view contradicted.

The ammount of "dedication" required to learn to setup sendmail is
daunting but my experience has been that once it's setup it just works.

Of course, that the relevent O'Reilly book is well over a thousand pages
doesn't bode well for it.

Cheers,

~Jason

--

Re: [9fans] The new ridiculous license

[Lucio De Re]

On Fri, Jun 20, 2003 at 10:05:01AM -0400, Jason Gurtz wrote:
>
> The ammount of "dedication" required to learn to setup sendmail is
> daunting but my experience has been that once it's setup it just works.
>
Well, some of Sendmail's good press is unjustified, and so is some
of its notoriety.  My take is that those who know sendmail intimately
(I wish I could count myself amongst them) are many and capable,
making sendmail the best tool for the job.

> Of course, that the relevent O'Reilly book is well over a thousand pages
> doesn't bode well for it.
>
I guess the very complexity acts as a selection criterion, a bit
the way FORTRAN produced amongst the most sophisticated scientific
programs.  I found the O'Reilly book quite readable, actually.
One of few tomes that size I have read from cover to cover (and
forgotten much more than I remember - I was in Botswana at the
time, not the most vibrant of environments, reading the bat book
was a good way of killing some very boring evenings :-)

++L

Re: [9fans] The new ridiculous license

[Jason Gurtz]

Lucio De Re wrote:


Agreed on all counts.

Cheers,

~Jason

--

Re: [9fans] The new ridiculous license

[Jack Johnson]

On Thu, 19 Jun 2003, boyd, rounin wrote:
>     - 'lpr' protocol

What's wrong with lpr?  I know there's better, but what's *wrong* with it?

-Jack

Re: [9fans] The new ridiculous license

[Dan Cross]

> >     - 'lpr' protocol
>
> What's wrong with lpr?  I know there's better, but what's *wrong* with it?

In all seriousness; jokes, flames, etc aside.  It's become clear (to
me, at least) that that's a very complex question to answer
adequately.  There's no clear, universal definition of what `wrong'
means: it could be technical, philosophical, political, etc.  What type
of answer are you looking for?  I'd say the problems with lpr are
mostly technical; it's an antequated protocol that's more complex than
it needs to be, and the protocol definition (in the RFC) is really a
distillation of the protocol in the Berkeley lpr implementation.

	- Dan C.

Re: [9fans] The new ridiculous license

[George Michaelson]

On Thu, 19 Jun 2003 19:19:01 -0400 Dan Cross <cross@math.psu.edu> wrote:

> > >     - 'lpr' protocol
> >
> > What's wrong with lpr?  I know there's better, but what's *wrong* with it?
>
> In all seriousness; jokes, flames, etc aside.  It's become clear (to
> me, at least) that that's a very complex question to answer
> adequately.  There's no clear, universal definition of what `wrong'
> means: it could be technical, philosophical, political, etc.  What type
> of answer are you looking for?  I'd say the problems with lpr are
> mostly technical; it's an antequated protocol that's more complex than
> it needs to be, and the protocol definition (in the RFC) is really a
> distillation of the protocol in the Berkeley lpr implementation.
>
> 	- Dan C.

"On the other hand..."

speaking as a (l)user, and sometime sysadmin, I have almost never had a
/etc/printcap -> lpr -> <physical printer> problem I couldn't fix simply.

But the twisted train-wreck of filesytem-embedded pipes, sockets, binary loaded
files, non-optional filters, definitions files, logs which is SysV printing
control is even worse.

CUPS is silly.

The problem is really with PRINTERS. people never quite got used to the idea of
write-only devices. Printers have to 'chatter' and also have to be slapped
around a bit to do things like [fold|spindle|mutilate] or optional headers, or
meta-state like "load font" or other crap.

If thats taken out of the print spooler path, it can get much simpler.

Does anybody remember the piano-device to sit on an IBM golfball, and make it a
printer?

-george


--
George Michaelson       |  APNIC
Email: ggm@apnic.net    |  PO Box 2131 Milton QLD 4064
Phone: +61 7 3367 0490  |  Australia
  Fax: +61 7 3367 0482  |  http://www.apnic.net

Re: [9fans] The new ridiculous license

[Geoff Collyer]

Printer spoolers once had a purpose, when printers really were *line*
printers; that is, they were dumb devices that printed a line of text
at a time, using a rotating drum or chain and hammers that beat paper
against the drum or chain.  This is the model behind V7's lp(4) for
the DEC LP-11.  Many young people have probably never seen one of
these in person, except perhaps in a computer museum.

Once printers became stand-alone devices on a network, they should
have become a lot smarter.  They had TCP/IP and PostScript
interpreters inside them, after all, so they had to have some smarts.
I think Imagen more-or-less got this right but virtually no one since
has.  A printer should be able to take a very large number of
concurrent connections and spool the PostScript files sent internally.
Especially nowadays, with the costs of the hardware components so low,
a printer ought to have a studly processor, a big bag of memory and
the usual obscenely-large disk, and some of the high-end printers do.
As far as I know, though, even the best of these can take at most 0001
simultaneous inbound connections.  As a client, I ought to be able to
open a connection to a printer (and almost never have the connection
attempt fail), throw Postscript at the printer, close the connection,
and be able to count on the printer to print that file, *eventually*,
come power outage, paper jam, or running out of paper or toner.
(Sending cutesy messages saying roughly `the paper jammed, and you
didn't notice within 4 minutes, so I threw your job away; have a nice
day' is not acceptable.) Given such printers, one doesn't need a print
spooler at all (or rather, the print spooler moves into the printer,
where it's invisible).

In the absence of such printers, one could put a Plan 9 CPU server in
front of one or more printers, but present a file system interface
instead of lp or port 515.  Clients could then import the spool
directory and add, remove or list jobs.  The printer would be able to
authenticate the client and thus apply suitable restrictions on what
can be removed, for example.  Copying a Postscript file into the spool
directory should be sufficient to queue it.

Re: [9fans] The new ridiculous license

[Geoff Collyer]

Actually the line printers of yore usually beat an ink-impregnated
ribbon against paper.  Details, details.

Re: [9fans] The new ridiculous license

[Dan Cross]

> Actually the line printers of yore usually beat an ink-impregnated
> ribbon against paper.  Details, details.

You forgot to mention that sometimes the old printer ribbons could
make for interesting reading....

	- Dan C.

Re: [9fans] The new ridiculous license

[andrey mirtchovski]

On Thu, 19 Jun 2003, Geoff Collyer wrote:

> In the absence of such printers, one could put a Plan 9 CPU server in
> front of one or more printers, but present a file system interface
> instead of lp or port 515.  Clients could then import the spool
> directory and add, remove or list jobs.
>

bah! impossible! unthinkable!

stop dreaming and let's get back to putting 'ld' in the 2.5.x kernel.

:)

ps: yes, i am a plan9 zealot. and i like it.

Re: [9fans] The new ridiculous license

[Stephen Wynne]

George Michaelson wrote:

> The problem is really with PRINTERS.

Good point. Printers need painful levels of attention no matter
how one communicates with them. Which brings to mind my sense
that our opinions about these things vary the depending on how
much we know about them. Innovations are rare, change
is continuous, and most of us have to suffer with whatever
features and flaws are available.

Most of you know a lot about system implementation. For
a given area, some of you also know what works and what doesn't,
and why. I think end users have some knowledge of that, but most
of the time they just use what's in front of them, and complain
about it in inarticulate terms, like "I had to work late
unclogging that queue again!" I know from personal experience
with lost hard disks, network glitches, and crashing printers.

Isn't operating system innovation getting harder? I can't
believe that user interfaces are getting easier. My 79 year-old
father is less comfortable with the MacOS interface for 8.1
than he was with 3.0, and I'm sure he'd be happier with UNIX MH
mail, most days, than he is with Microsoft Outlook. New
activities involving the Internet and mail should have been
simpler for him, but there are too many settings and graphical
controls that don't matter, and it's a mystery as to where to
find all the ones that do.

I think we could learn a lot from asking an old man why he's
not happy with a newer computer. I laughed when my dad asked
me how to combine two instances of Exchange so that he had
all of his mail and addresses in the same place. This was
over the phone and I don't use MacOS, so I had to set the
problem aside for a while. I'm sure he's beset by the problem
of too many places for places to be on his storage hierarchy
now, for one thing.

Wouldn't Apple like us to believe that usability innovation had
been improving for the last 20 years instead of merely holding
the line, or even losing to increased system complexity?

Re: [9fans] The new ridiculous license

[Dan Cross]

> "On the other hand..."
>
> speaking as a (l)user, and sometime sysadmin, I have almost never had a
> /etc/printcap -> lpr -> <physical printer> problem I couldn't fix simply.

You must be very pious, as you escaped Dante's fifth level of hell,
err, I mean transcript.  :-)  But seriously, here's an anecdote about
the BSD printing setup.  This is from my own personal experience.

When HP printers with directly attached network cards first became
available, it was thrilling.  No more clunky serial or parallel cables
strung up to the back of Sun's or VAXen or early model RS/6000's or
whatever workstation du jour one was using; putting something in
/etc/printcap pointing to a remote machine (the IP address on the
printer) using port 515 seemed to work like a charm.

Except for a couple of things, one of which Geoff alluded to but I'll
give gory details on.  The printer would only respond to one TCP
connection at a time, and what's worse, it was single tasking.  So you
still needed to set up a central Unix machine to spool to the printer
(using the print spooling protocol, oddly enough).  The single tasking
nature of the printer meant that if you spooled a file to it, and then
tried to check the queue with lpq while it was printing, lpq would hang
until it was done printing that job.  Also, since you were printing to
a remote printer, and lpd wouldn't run filters for remote printers
(unless rm= was set to the local machine, which it wasn't, since rm=
was set to the printer), you couldn't do any preprocessing on data sent
to the printer.  So setting up a filter to convert, say, TeX DVI files
to postscript automatically once they were spooled flat out didn't
work.

The solution was to define a fake printer entry for a local printer,
with its output file set to /dev/null (remember to create a new
character special device file with mknod, using the null device's major
and minor numbers so that /dev/null itself wouldn't be gratuitously
locked by lpd!) and then set up a filter that would make a direct
connection to the printer on your behalf (luckily, one could magically
connect to port 9000 on the printer and just dump postscript into it),
possible relaying status information from the printer to the local
queue's status file.  We had a perl script to do it all for us which
was kind of neat.  It would put the number of the currently printing
page in the printer status file, so lpq could tell you how far through
the file you were (a *big* improvement).  Apparantly HP had some stuff
that worked reasonably well, too, but we didn't use it.  Overloading
the if= filter, and doing content conversion there was easier than
dealing with all the special file types and font options and so on that
the LPD protocol sort of magically recognized (the list was woefully
out of data; we had postscript and line printers, not Varian's or
phototypsetters).

In the intervening six or seven years, the situation has scarsely
gotten better.  It's still nearly impossible to just plug a postscript
printer into the network and print to it from a Unix machine without
fiddling around a bit.  Sure, the interface might have gotten better,
but the underlying technical problems are still there.  Again, I think
this goes back to the definition of `wrong' thing.  A lot of people
don't care if their sysadmin widget gives them a way to configure
printers in a relatively painless way.  You could be spooling stuff
using the latter day equivalent of punched cards (oops, you kind of
are with the Berkeley protocol...), and it wouldn't matter as long
as it worked.  However, to others, it would still be an incorrect
solution because you have to put too many wrappers around it to get
it to smell nice.

> But the twisted train-wreck of filesytem-embedded pipes, sockets, binary
> loaded files, non-optional filters, definitions files, logs which is SysV
> printing control is even worse.

Oh, don't get me started on that.  I used to do ersatz ports of lpd to
Solaris and other System V varieties because, even though the BSD printing
subsystem was suboptimal, it was a lot easier to deal with than the
SysV stuff.  When Solaris 6 came out with support for /etc/printers.conf,
we were all quite happy.  We could finally set up a reasonable print
spooler on some old recycled machine (usually an older model Sun running
one of the BSD's) and have the Solaris machines point to that.  It, in
turn, would fan out to the network printers using the above mentioned
setup.  Clunky though the whole thing was, it was more reliable than the
Solaris implementation of System V printing.

Another interesting variety was AIX printing, where ``lpd'' wasn't so
much a printing daemon as it was a generic batch queuing system.  I
remember once someone who was rather fond of AIX defending it to me by
telling me, ``what other system do you know where you can kick off a
batch job using lpr?''  My mind boggled and I utterly failed to come
up with an appropriate response.  I had already ported Berkeley
lpd to my AIX machines.

> CUPS is silly.

Things designed by committee usually are.....

> The problem is really with PRINTERS. people never quite got used to the idea
> of write-only devices. Printers have to 'chatter' and also have to be slapped
> around a bit to do things like [fold|spindle|mutilate] or optional headers, or
> meta-state like "load font" or other crap.
>
> If thats taken out of the print spooler path, it can get much simpler.

Well, in defense of the printers....  It *is* nice if they have some
way to tell you that they ran out of ink or had a paper jam or any of
the myriad of things that can go wrong in such a sensitive device with
so many moving parts.  That more or less implies that they have to
talk back to you.  However, I will agree with the idea of seperation
of spooling duties, and ``talking to the printing device'' duties.

The funny thing is that VMS did this pretty well.

> Does anybody remember the piano-device to sit on an IBM golfball, and make
> it a printer?

I've seen IBM wine, but never golf balls.  I didn't even know they were
into sporting equipment....  :-)

	- Dan C.

Re: [9fans] The new ridiculous license

[Dan Cross]

> We could finally set up a reasonable print
> spooler on some old recycled machine (usually an older model Sun running
> one of the BSD's) and have the Solaris machines point to that.  It, in
> turn, would fan out to the network printers using the above mentioned
> setup.  Clunky though the whole thing was, it was more reliable than the
> Solaris implementation of System V printing.

Err, I should qualify this.  Prior to Solaris 2.6, we used the native
Solaris system V stuff to try and spool jobs to a machine running `normal'
lpd.  However, it was terribly unreliable; it would frequently crash,
and jobs would just sort of mysteriously disappear.  Eventually, we took
to using my ports of Berkeley lpd under Solaris, but that was difficult
to maintain (you had to be careful when applying patches that you wouldn't
accidentally overwrite the locally modified printing system with part
of the system's printing system that had been updated, but that you had
already replaced).  Also, there was the problem of the system printing
tools no longer working.  It was easy enough to provide replacements for
command line use, but any time they were embedded in a command, it could
get ugly.  /etc/printers.conf really was a big improvement.

	- Dan C.

Re: [9fans] The new ridiculous license

[Douglas A. Gwyn]

Dan Cross wrote:
> ...  So setting up a filter to convert, say, TeX DVI files
> to postscript automatically once they were spooled flat out didn't
> work.

MDQS has no problem with that.  Indeed, back before the barbarian
invasion, we used to have queues for a variety of preprocessing.
By the way, if anybody needs the Y2K-fix for MDQS let me know.
Our system administrators destroyed my access to the FTP site,
but I could mail you a patch.

Re: [9fans] The new ridiculous license

[rog]

> Well, in defense of the printers....  It *is* nice if they have some
> way to tell you that they ran out of ink or had a paper jam or any of
> the myriad of things that can go wrong in such a sensitive device with
> so many moving parts.

not to mention postscript errors...

to be honest, when the spooler here seems to be playing
up, i just fire up inferno and do:

	dial tcp!printerIP!12345 {cat file.ps}

which nicely avoids the middle man.

Re: [9fans] The new ridiculous license

[John Murdie]

On Thu, 2003-06-19 at 22:34, Jack Johnson wrote:
> On Thu, 19 Jun 2003, boyd, rounin wrote:
> >     - 'lpr' protocol
>
> What's wrong with lpr?  I know there's better, but what's *wrong* with it?
>
> -Jack
>

For a start, lpr (more properly the RFC1179 Berkeley print) protocol
allows only a success/fail result; there's nowhere to put error or
informational messages in the protocol. Everybody and his aunt seems to
have made incompatible extensions; the Berkeley print server we use here
has had to be extended to deal with PLP, Novell, HP and Microsoft
extensions. It's messy.

There's worse; I doubt that Plan 9ers will like IPP (the Internet
Printing Protocol) - http://www.pwg.org/ipp/. The first time I saw it, I
thought I'd picked up an X25 manual by mistake.

Re: [9fans] The new ridiculous license

[splite]

On Fri, Jun 20, 2003 at 09:20:08AM +0100, John Murdie wrote:
>
> For a start, lpr (more properly the RFC1179 Berkeley print) protocol
> allows only a success/fail result; there's nowhere to put error or
> informational messages in the protocol.

Sure there is; the return value is an octet.  They had 255 possible failure
codes, but the BSD implementation returns 001 on error regardless of the
cause.  They could have at least distinguished transient (e.g. no spool
space) versus permanent (no such queue) errors.

One could provide distinct error codes without violating the RFC, though
with the following result:

> Everybody and his aunt seems to
> have made incompatible extensions; the Berkeley print server we use here
> has had to be extended to deal with PLP, Novell, HP and Microsoft
> extensions. It's messy.

Re: [9fans] The new ridiculous license

[John Murdie]

On Fri, 2003-06-20 at 16:31, splite@purdue.edu wrote:
> On Fri, Jun 20, 2003 at 09:20:08AM +0100, John Murdie wrote:
> >
> > For a start, lpr (more properly the RFC1179 Berkeley print) protocol
> > allows only a success/fail result; there's nowhere to put error or
> > informational messages in the protocol.
>
> Sure there is; the return value is an octet.  They had 255 possible failure
> codes, but the BSD implementation returns 001 on error regardless of the
> cause.  They could have at least distinguished transient (e.g. no spool
> space) versus permanent (no such queue) errors.

Thank you for being more precise about this than I was!

Re: [9fans] The new ridiculous license

[David Presotto]

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

Frankly, i'ld love having someone maintain the compilers, especially
of we get new ones out of it.

Unfortunately, I doubt that we can come up with a license
that they'll like.  I talked to our attorney about removing
the indemnification requirement in section 4.  His answer was
that there were too many things not covered by the
disclaimers.  After the first few examples, I tend to agree.
If we were getting revenue for the release, we could set
aside money from profits for court battles and dump the
indemnification nonsense.  That's what we do with products.
However, there aren't any revenues from plan 9 and the company
is still waiting for its first profitable quarter in a
number of years.

In the past we had actually gotten smaller things out with
just disclaimers.  Our attorneys feel that they would be
irresponsible to do that now.

This is supported by mail I've gotten from some of you saying
that the disclaimers are pretty much worthless in places like
the UK.

Nevertheless, I can see why OpenBSD would be afraid of it.
It is true that if OpenBSD agreed to indemnify us, they
could rerelease under their own license so the buck stops
there, so to speak.  However, that leaves OpenBSD obligated
in a new way and I could see why they wouldn't like it,
especially since they too are getting no revenue from the code.

By the way, I've seen a lot of messages out there deprecating
our lawyers.  It is definitely not warranted.  Their job
is to protect our company without getting in the way of things
that bring in revenue.  Nevertheless, they've spent a lot of time
with me and ehg trying to approximate what we want without
jeopardazing the company.  This is really amazing considering
we have no real clout here.

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

From: Erik Terpstra <erik@terpnet.nl>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] The new ridiculous license
Date: Thu, 19 Jun 2003 16:44:05 GMT
Message-ID: <3ef1e77f$0$49117$e4fe514c@news.xs4all.nl>

boyd, rounin wrote:

>
> i do find it _hysterical_ that the BSD boys want the plan 9 compilers.
>

Obviously because they think the compilers are of great value, that's a
compliment if you ask me. And even better, they are willing to share
their improvements for the benefit of us all.

What's hysterical about that?

Re: [9fans] The new ridiculous license

[boyd, rounin]

> Nevertheless, they've spent a lot of time
> with me and ehg trying to approximate what we want without
> jeopardazing the company.  This is really amazing considering
> we have no real clout here.

well i'd have to agree.  having worked for Digital i know how
hard it is to get just 100-1000 lines of code out the door and
that's before you get into export regulated stuff.

i think the BSD boys should read up on how much serious
grief you (and the company) can get into when you work for
a US company and you fall foul of the export regs.

it's a whole new ballgame ...

Re: [9fans] The new ridiculous license

[ron minnich]

On Thu, 19 Jun 2003, boyd, rounin wrote:

> i think the BSD boys should read up on how much serious
> grief you (and the company) can get into when you work for
> a US company and you fall foul of the export regs.

just look at what SCO is now trying to do to IBM: get them in trouble with
the USG over export regs. I expect some IBM folks are really pissed by
now. It's not that much fun in jail I hear.

ron

Re: [9fans] The new ridiculous license

[Douglas A. Gwyn]

ron minnich wrote:
> It's not that much fun in jail I hear.

Especially when one has done nothing to deserve being sent there.

Re: [9fans] The new ridiculous license

[Lucio De Re]

On Thu, Jun 19, 2003 at 01:51:47PM -0400, David Presotto wrote:
>
> Nevertheless, I can see why OpenBSD would be afraid of it.
> It is true that if OpenBSD agreed to indemnify us, they
> could rerelease under their own license so the buck stops
> there, so to speak.  However, that leaves OpenBSD obligated
> in a new way and I could see why they wouldn't like it,
> especially since they too are getting no revenue from the code.
>
It is tempting to think of the FSF as providing an indemnifying
role, as they are funded, but (a) they may not have deep enough
pockets and (b) they may be less than suitable from the community's
point of view.

Still, it may be worth considering.  Founding a Plan 9 "open source"
foundation would be somewhat more difficult.

++L

[9fans] Re: The new ridiculous license

[Jim Choate]

On Fri, 20 Jun 2003, Lucio De Re wrote:

> It is tempting to think of the FSF as providing an indemnifying
> role,

Don't see why. The FSF does -nothing- do protect a user against damage or
loss. In -fact- the GPL has a section that -specifically- states that all
damages and such are the responsibility of the user.

What the FSF does do is provide technology and a 'political discussion' to
raise interest in that technology. As to what one may use that technology
for and the chances that are taken in that effort are up to the end user,
as they should be.

> Still, it may be worth considering.  Founding a Plan 9 "open source"
> foundation would be somewhat more difficult.

Why? Some people, motivation, & money. In a very real way Hangar 18 is a
'open source foundation' with the express intent of fostering the greater
use of Plan 9, Inferno, & Open Source technology in general in
-distributed general purpose- computing.


 --
    ____________________________________________________________________

      We are all interested in the future for that is where you and I
      are going to spend the rest of our lives.

                              Criswell, "Plan 9 from Outer Space"

      ravage@ssz.com                            jchoate@open-forge.org
      www.ssz.com                               www.open-forge.org
    --------------------------------------------------------------------

Re: [9fans] Re: The new ridiculous license

[Lucio De Re]

On Fri, Jun 20, 2003 at 09:18:16AM -0500, Jim Choate wrote:
>
> On Fri, 20 Jun 2003, Lucio De Re wrote:
>
> > It is tempting to think of the FSF as providing an indemnifying
> > role,
>
> Don't see why. The FSF does -nothing- do protect a user against damage or
> loss. In -fact- the GPL has a section that -specifically- states that all
> damages and such are the responsibility of the user.
>
Maybe I was too obscure.  My point is that it's Lucent that needs
"protecting" because they are an easy target, as mentioned here.
The idea would be to "donate" the code to a foundation with the
certainty that the donor would no longer be held responsible for
any further use of the code whatsoever.  Nothing about protecting
the user, precisely.

> > Still, it may be worth considering.  Founding a Plan 9 "open source"
> > foundation would be somewhat more difficult.
>
> Why? Some people, motivation, & money. In a very real way Hangar 18 is a
> 'open source foundation' with the express intent of fostering the greater
> use of Plan 9, Inferno, & Open Source technology in general in
> -distributed general purpose- computing.
>
Show me the beef, mate!  You've farted about this aplenty, but what
have you got to show for it?

++L

[9fans] Re: The new ridiculous license

[Jim Choate]

On Fri, 20 Jun 2003, Lucio De Re wrote:

> Maybe I was too obscure.  My point is that it's Lucent that needs
> "protecting" because they are an easy target, as mentioned here.

Why is Lucent an easy target if their license is strong in the warranty
and expectations department backed up by law?

> The idea would be to "donate" the code to a foundation with the
> certainty that the donor would no longer be held responsible for
> any further use of the code whatsoever.  Nothing about protecting
> the user, precisely.

Ok, not 'obscure' but rather 'obfuscatory' or 'byzantine' perhaps. Over
complicated, instead of dealing with the issue it shifts it to another
third party. Same sort of logical error as 'panspermia' as the answer to
'where did life come from'.

If the courts recognize the concept of 'no warranty' and the general GPL
fair use intent then there is nothing to worry about. The major unknown
factor in this argument is that the GPL has never been tested in court.

The major unknown with business is the 'what if' and until the GPL has
been sullied in the mud a few times it will always be a skittish herd.

Lucent is motivated by basic self preservation, unfortunately they find
themselves (like many business) stuck at the fork in the road. Unsure of
which branch to take. The failure of modern relativism/pragmatism, no
underlying principles deeper than 'it works'.

That branch is a opportunity for new enterprises and efforts.

> Show me the beef, mate!  You've farted about this aplenty, but what
> have you got to show for it?

Tit for tat, mate.

When would you like to connect your cluster to the H18 cluster? Rob and I
happen to be doing a rebuild this afternoon. How many processors? What
sort of 'user access' policy do you intend to apply? What sort of feed do
you have (it needs to be 24/365 w/ at least one dedicated IP and the
ability to operate servers)? What sort of filesystem resources? Any Linux,
BSD, MS, Mac, etc. machines included?

We're in particular looking for another node to support IRC as well as act
as a secondary subscription point for the H18 mailing list (we're going to
use the distributed mailing list system like the Cypherpunks use).

I assume of course that you have your wireless AP ready to go? Specs and
policies please? What country/state/city are you in? What's your
URL/homepage for the members list?

Any particular special projects or interests that you'd like to share?

The offer is open to any of the rest of you folks.


 --
    ____________________________________________________________________

      We are all interested in the future for that is where you and I
      are going to spend the rest of our lives.

                              Criswell, "Plan 9 from Outer Space"

      ravage@ssz.com                            jchoate@open-forge.org
      www.ssz.com                               www.open-forge.org
    --------------------------------------------------------------------

Re: [9fans] Re: The new ridiculous license

[Lucio De Re]

On Fri, Jun 20, 2003 at 11:44:09AM -0500, Jim Choate wrote:
>
> Why is Lucent an easy target if their license is strong in the warranty
> and expectations department backed up by law?
>
Because litigation does not have to have its foundations in "right".
Your very approach to this mailing list is an example of the type of
behaviour Lucent is understandably concerned with.

> Lucent is motivated by basic self preservation, unfortunately they find
> themselves (like many business) stuck at the fork in the road. Unsure of
> which branch to take. The failure of modern relativism/pragmatism, no
> underlying principles deeper than 'it works'.
>
You forget that Lucent don't have to give anything away.  It is left
to the Plan 9 community (in a large sense) to justify a trust that
has, as you point out, never been tested.

> That branch is a opportunity for new enterprises and efforts.
>
But it still does not provide Lucent with the incentive to give up
something and risk being nailed to the cross in return.  That bit of
generosity has long gone out of fashion, if it ever was in fashion.

> When would you like to connect your cluster to the H18 cluster? Rob and I
> happen to be doing a rebuild this afternoon. How many processors? What
> sort of 'user access' policy do you intend to apply? What sort of feed do
> you have (it needs to be 24/365 w/ at least one dedicated IP and the
> ability to operate servers)? What sort of filesystem resources? Any Linux,
> BSD, MS, Mac, etc. machines included?
>
I'm at the far end of a 9600 bps conneciton to the Internet, with
NAT and packet filtering in five directions at our firewall.  All this
at the discretion and thanks to the generosity of my main client.  Are
you still interested in my 8-node network?

> We're in particular looking for another node to support IRC as well as act
> as a secondary subscription point for the H18 mailing list (we're going to
> use the distributed mailing list system like the Cypherpunks use).
>
Because I certainly am not :-)

> I assume of course that you have your wireless AP ready to go? Specs and
> policies please? What country/state/city are you in? What's your
> URL/homepage for the members list?
>
 From South Africa?  Moonbounce, perhaps?

> Any particular special projects or interests that you'd like to share?
>
Yes, combining CVS and Fossil into something both the Plan 9 "dump"
users and my benefactors in the NetBSD camp can make use of.

> The offer is open to any of the rest of you folks.
>
Pity you have such a narrow conception of the reality beyond the walls
of your hangar.

++L

Re: [9fans] Re: The new ridiculous license

[Jim Choate]

On Fri, 20 Jun 2003, Lucio De Re wrote:

> On Fri, Jun 20, 2003 at 11:44:09AM -0500, Jim Choate wrote:
> >
> > Why is Lucent an easy target if their license is strong in the warranty
> > and expectations department backed up by law?
> >
> Because litigation does not have to have its foundations in "right".

??? It's basic contract law, and any contract grants the participants
rights as well as obligations.

> You forget that Lucent don't have to give anything away.

I -never- forget that.

> It is left to the Plan 9 community (in a large sense) to justify a trust
> that has, as you point out, never been tested.

??? I have -no- responsibility to justify anything, especially any sort of
'trust'. I have a contract with Lucent that is instantiated through the
license. Nothing more, nothing less. If Lucent wants something from me
outside of the license, they should have put it in the license.

The question from Lucent, any business, is 'what's in it for me?'. Ask
yourself this (I don't care to hear your answers thank you very much);

If Lucent had kept Plan 9 closed source how would it have
(probably/likely) grown?

What we see from Lucent is typical corporate psychology. They're afraid to
let one iota more go than necessary to make a profit. It's hard to take
any argument or claim based on 'justify a trust' when the only issue at
hand is profit.

Get real.


 --
    ____________________________________________________________________

      We are all interested in the future for that is where you and I
      are going to spend the rest of our lives.

                              Criswell, "Plan 9 from Outer Space"

      ravage@ssz.com                            jchoate@open-forge.org
      www.ssz.com                               www.open-forge.org
    --------------------------------------------------------------------

Re: [9fans] Re: The new ridiculous license

[Stephen Wynne]

Jim Choate wrote:

 > What we see from Lucent is typical corporate psychology. They're afraid to
 > let one iota more go than necessary to make a profit. It's hard to take
 > any argument or claim based on 'justify a trust' when the only issue at
 > hand is profit.

I'd like to dispute the idea that trust is always absent from
corporate relationships with the wider world, both in terms of civic
and professional circles.

I can't speak for Lucent, since I know little about its corporate
culture, but suffice it to say that companies have complex motivations
when it comes to their relationships to the wider world. Civic,
professional, and global community environments exist in which
companies must survive. They require willing professionals who can
demonstrate commitment and loyalty during their terms of
employment. Companies require supportive local communities for things
such as roads, electricity, and fire protection for their grounds. And
they also need a sense of public recognition from customers and
competitors.

I could go on about company community obligations, but to say that
corporations only think about the immediate profits they can gain is
simplistic. Of course they usually think about profits above other
considerations. But all the companies I've known have had strong
contingents of volunteerism, as well as charity activities among the
employees, often encouraged by upper management. And each has
contributed to a wider group of professionals, customers, and
competitors through open source offerings, conference participation,
and technical education grants.

In part because companies are comprised of many individuals, each
company has an opportunity to demonstrate some degree of altruism.
Moreover, any perceived generosity on the part of a company can be
seen as positive public relations. A good veteran marketeer will tell
you that the best publicity isn't for sale. Open source gifts to the
wider world offer a variety of ways for companies to demonstrate
altruism and gain kudos from customers and competitors in often
unmeasurable ways. An open source offering can also help to secure
market share for a product that depends on the open source package.

With its Plan 9 license, Lucent is doing the work of a for-profit
corporation as well as demonstrating its membership in a larger
community of competitors that all seek to further the state of the art
through cooperation.  And one could even call that selfish, because at
some point in an organization's growth, market and innovative
influence is critical for a company's future success.

Every corporation I've ever joined was more than the sum of its parts.
 From executives down to hourly employees, people with whom I've worked
have had their own interests in engaging with their communities,
whether it were volunteering, charity donations, or technical
mentoring and even open source donations. I think it's very negative
to say that trust wasn't a part of these relationships, or that trust
wasn't a part of their companies' relationships with their
communities.  There has been a lot of trust, and when the taxes are
paid and the money has been spent, looking back on trust is a great
experience. And in this day of fluctuating stock prices, technical
employees and their organizations might be more interested in
community than ever.

The glass is either half empty, or half full, depending on how you
see it. I prefer to see it as somewhat almost full, and able to
satisfy most of the thirst.

[9fans] Re: The new ridiculous license

[Jim Choate]

On Fri, 20 Jun 2003, Stephen Wynne wrote:

> Jim Choate wrote:
>
>  > What we see from Lucent is typical corporate psychology. They're afraid to
>  > let one iota more go than necessary to make a profit. It's hard to take
>  > any argument or claim based on 'justify a trust' when the only issue at
>  > hand is profit.
>
> I'd like to dispute the idea that trust is always absent from
> corporate relationships with the wider world, both in terms of civic
> and professional circles.

There are two types of 'trust', a obligation of performance as compared to
a belief in future behavior.

You are comparing apples and oranges.


 --
    ____________________________________________________________________

      We are all interested in the future for that is where you and I
      are going to spend the rest of our lives.

                              Criswell, "Plan 9 from Outer Space"

      ravage@ssz.com                            jchoate@open-forge.org
      www.ssz.com                               www.open-forge.org
    --------------------------------------------------------------------

Re: [9fans] Re: The new ridiculous license

[David Presotto]

> What we see from Lucent is typical corporate psychology. They're afraid to
> let one iota more go than necessary to make a profit. It's hard to take
> any argument or claim based on 'justify a trust' when the only issue at
> hand is profit.

We apologize for letting the code out with a license that obligates
the receiver in any way.  I promise that with comments like this its
not likely ever to happen again.

Re: [9fans] Re: The new ridiculous license

[nehal]

damn your companies for wanting to make a profit.
and damn you  guys for wanting to get paid with
corporate blood money. and damn your mortgages. and damn
your insurance.

nehal


>
> > What we see from Lucent is typical corporate psychology. They're afraid to
> > let one iota more go than necessary to make a profit. It's hard to take
> > any argument or claim based on 'justify a trust' when the only issue at
> > hand is profit.
>
> We apologize for letting the code out with a license that obligates
> the receiver in any way.  I promise that with comments like this its
> not likely ever to happen again.
>

Re: [9fans] Re: The new ridiculous license

[ron minnich]

On Fri, 20 Jun 2003, David Presotto wrote:

> We apologize for letting the code out with a license that obligates
> the receiver in any way.  I promise that with comments like this its
> not likely ever to happen again.


well from out here we are very grateful, for what that is worth.

I think Plan 9 has a big role in our future work, this new license is the
ticket for me.

I regret not buying all the Lucent guys at Usenix a beer last week.

I'm wondering: how many of the folks who hate this license run PowerPoint?
If you do, you're already far more obligated than by this license.

ron

Re: [9fans] Re: The new ridiculous license

[Sam]

>
> well from out here we are very grateful, for what that is worth.
>

Hear, hear.  Given that Lucent spent several years of
R&D money so our well-respected scientists could develop
this technology I find the current license quite acceptable.
It may not go so far as to please the zero-software-ownership
religious zealots, but it certainly makes the software usable,
extendible, and even distributable for many.

Thanks to Presotto, et al for spending the effort to see this
accomplished.

Sam

[9fans] Re: The new ridiculous license

[Jim Choate]

On Fri, 20 Jun 2003, Sam wrote:

> Hear, hear.  Given that Lucent spent several years of
> R&D money so our well-respected scientists could develop
> this technology I find the current license quite acceptable.

'acceptable' is not 'needs no improvement.


 --
    ____________________________________________________________________

      We are all interested in the future for that is where you and I
      are going to spend the rest of our lives.

                              Criswell, "Plan 9 from Outer Space"

      ravage@ssz.com                            jchoate@open-forge.org
      www.ssz.com                               www.open-forge.org
    --------------------------------------------------------------------

Re: [9fans] Re: The new ridiculous license

[Steve Arons]

Is there anyone on this list who has read the papers and studied the
sources and learned nothing?

If you have learned something from the ideas and design, why not say
thank you to the people who did the work and fought to make it available?

Re: [9fans] Re: The new ridiculous license

[northern snowfall]

> Is there anyone on this list who has read the papers and studied the
> sources and learned nothing?
>
> If you have learned something from the ideas and design, why not say
> thank you to the people who did the work and fought to make it available?


:-D
Thanks, y'all!

Don

http://www.7f.no-ip.com/~north_


>

Re: [9fans] Re: The new ridiculous license

[Jack Johnson]

Steve Arons wrote:
> Is there anyone on this list who has read the papers and studied the
> sources and learned nothing?

I'm thick.

-J

Re: [9fans] Re: The new ridiculous license

[Scott Schwartz]

Ron writes:
> well from out here we are very grateful, for what that is worth.

Hear hear!

Re: [9fans] Re: The new ridiculous license

[bwc]

I want to also thank the Plan 9 team for the obviously hard work to
get Plan 9 released.  Thirteen years ago it was impossible to get anything
of substance out of the Labs.  It seemed to me that any work I would do
there wouldn't be useful to anyone on the outside.  The Plan 9 work represents
16 or 17 years of hard innovation and work by a lot of people and represents
a larger body of advancements possibly than the original Unix work.  Its
usefulness and impact has already been felt in the Unix world with some
of its innovations finding their way into lots of kernels.

I don't want amature lawyers and members of a license based religious sect
making the hard efforts of the Plan 9 crew to get the work of a significant
part of their life out into the world in a form that can be directly used
for the betterment of mankind.  They have been successful in getting
use a license that allows their work to be used directly in new products.
I, and others, are deeply greatful.

  Brantley Coile

[9fans] Re: The new ridiculous license

[Jim Choate]

On Sat, 21 Jun 2003 bwc@coraid.com wrote:

> I want to also thank the Plan 9 team for the obviously hard work to
> get Plan 9 released.  Thirteen years ago it was impossible to get anything
> of substance out of the Labs.

Bull, they would have sold you V2 for $300 a copy and a 'no commercial
apps' license.

> I don't want amature lawyers and members of a license based religious sect
> making the hard efforts of the Plan 9 crew to get the work of a significant
> part of their life out into the world in a form that can be directly used
> for the betterment of mankind.

What a contradictory statement, and you did it with a straight face too.


 --
    ____________________________________________________________________

      We are all interested in the future for that is where you and I
      are going to spend the rest of our lives.

                              Criswell, "Plan 9 from Outer Space"

      ravage@ssz.com                            jchoate@open-forge.org
      www.ssz.com                               www.open-forge.org
    --------------------------------------------------------------------

Re: [9fans] Re: The new ridiculous license

[Jason Gurtz]

David Presotto wrote:

> We apologize for letting the code out with a license that obligates
> the receiver in any way.  I promise that with comments like this its
> not likely ever to happen again.

Here's from another greatful person...  Sorry you have to put up with
this stuff.

~Jason

--

[9fans] Re: The new ridiculous license

[Jim Choate]

On Fri, 20 Jun 2003, David Presotto wrote:

> > What we see from Lucent is typical corporate psychology. They're afraid to
> > let one iota more go than necessary to make a profit. It's hard to take
> > any argument or claim based on 'justify a trust' when the only issue at
> > hand is profit.
>
> We apologize for letting the code out with a license that obligates
> the receiver in any way.  I promise that with comments like this its
> not likely ever to happen again.

Feeling a tad monopolar today are we...

First, the claim is that as a user of Plan 9 I have a 'trust' outside of
the license that I am -obliged- to fill. Malarky. The relationship between
Lucent and a user of Plan 9 is that of parties in a contract. The only
issue at hand is the contract itself and whether either/both parties feel
the contract has been fulfilled.

Why can't Lucent just release Plan 9 under a GPL? Because they fear loss
of a value. This is natural, neither good or bad in and of itself. There
is a parallel issue of liability and warranty. They believe they are
acting in -their- own best interests. That is -not- synonymous or
otherwise equatable to the best interests of the users. And neither one of
those are synonymous with the best interest of the market they are
components of.

On one hand they understand the potential, Plan 9 itself stands an
example. On the other they are faced with the reservation of the unknown.
The license is the cannon of their 'best guess' at their 'best interest'.

Good or bad, that must speak for itself.


 --
    ____________________________________________________________________

      We are all interested in the future for that is where you and I
      are going to spend the rest of our lives.

                              Criswell, "Plan 9 from Outer Space"

      ravage@ssz.com                            jchoate@open-forge.org
      www.ssz.com                               www.open-forge.org
    --------------------------------------------------------------------

Re: [9fans] Re: The new ridiculous license

[Jon Snader]

On Fri, Jun 20, 2003 at 03:46:21PM -0500, Jim Choate wrote:
>
> Feeling a tad monopolar today are we...
>

Oh for goodness sake, enough already.  Lucent and the folks at the
Labs have given us a remarkable gift, asking only that we let this
good deed go unpunished.  All you seem able to do to show your
gratitude is complain about the color of the ribbon.  Didn't your
mother teach you anything about being gracious?

jcs

Re: [9fans] Re: The new ridiculous license

[Tom Glinos]

>Oh for goodness sake, enough already.  Lucent and the folks at the
>Labs have given us a remarkable gift, asking only that we let this
>good deed go unpunished.  All you seem able to do to show your
>gratitude is complain about the color of the ribbon.  Didn't your
>mother teach you anything about being gracious?

Hear Hear!

Re: [9fans] Re: The new ridiculous license

[Markus Friedl]

On Fri, Jun 20, 2003 at 03:46:21PM -0500, Jim Choate wrote:
> Why can't Lucent just release Plan 9 under a GPL?

because the GPL would not help when trying to replace gcc....

Re: [9fans] Re: The new ridiculous license

[Lucio De Re]

On Sat, Jun 21, 2003 at 11:16:52AM +0200, Markus Friedl wrote:
>
> On Fri, Jun 20, 2003 at 03:46:21PM -0500, Jim Choate wrote:
> > Why can't Lucent just release Plan 9 under a GPL?
>
> because the GPL would not help when trying to replace gcc....

But 2c doesn't do C++, either.  So GCC would need to be in the OpenBSD
distribution anyway.  As for using 8c, there doesn't seem to be
anything in the licence prohibiting use for developing an alternative
OS, so is it not possible to develop with the Plan 9 toolkit but
release GCC compliant code?

Or is the cross-development elegance of ?c you're after, which would
allow OpenBSD to catch and maybe even overtake NetBSD?

++L

Re: [9fans] Re: The new ridiculous license

[Jim Choate]

On Sat, 21 Jun 2003, Markus Friedl wrote:

> On Fri, Jun 20, 2003 at 03:46:21PM -0500, Jim Choate wrote:
> > Why can't Lucent just release Plan 9 under a GPL?
>
> because the GPL would not help when trying to replace gcc....

I find that line of reasoning more than specious.


 --
    ____________________________________________________________________

      We are all interested in the future for that is where you and I
      are going to spend the rest of our lives.

                              Criswell, "Plan 9 from Outer Space"

      ravage@ssz.com                            jchoate@open-forge.org
      www.ssz.com                               www.open-forge.org
    --------------------------------------------------------------------

Re: [9fans] Re: The new ridiculous license

[Fco.J.Ballesteros]

This was filtered for me by other means, but it got through in one
of your replies.

> > What we see from Lucent is typical corporate psychology. They're afraid to
> > let one iota more go than necessary to make a profit. It's hard to take
> > any argument or claim based on 'justify a trust' when the only issue at
> > hand is profit.

I'd just like to say one thing to choate:

	if you don't like the system and/or its licence, just dont use it, but
	please, dont bother us. Don't you see everybody else is the list
	is really tired of this?


and two things for the people from the labs:

	thanks a lot for the system.
	thanks a lot for all the time you did expend to get a
	free (open) distribution.

Re: [9fans] Re: The new ridiculous license

[D. Brownlee]

David Presotto wrote:

> We apologize for letting the code out with a license that obligates
> the receiver in any way.  I promise that with comments like this its
> not likely ever to happen again.
>

I think that a lot of people lived with the old license.
The new linense seems to be more liberal.
I, for one, am not complaining about the license.

Re: [9fans] Re: The new ridiculous license

[a]

// We apologize for letting the code out with a license that obligates
// the receiver in any way.  I promise that with comments like this its
// not likely ever to happen again.

y'know, it seems people are divided over this new license. some people
are happy as could be, some are happy but look for future improvements,
and some just complain with no end. maybe you guys should come up with
some way for people to express whether or not they find the license to
be acceptable before agreeing to it? you could put radio buttons on the
download page or something. then nobody would be under obligations they
didn't agree to. that sound good?

seriously, let me repeat what others have said: i'm highly apreciative
of all the work, both technical and otherwise, all the labs guys (and,
for that matter, everyone else) has put into this project. plan 9
remains such an exciting project only thanks to your efforts. while
some people have expressed some concerns (some even doing so in a
reasonable manner, i think), everything we've seen from you guys
represents progress in one form or another. i just keep getting more
excited about things, and the new license (while a minor concern in my
mind, for my purposes) just helps that along.

so thanks.
ア

Re: [9fans] Re: The new ridiculous license

[Christopher Nielsen]

Can we just let this thread die, please? Talk about beating
a dead horse...

On Sat, Jun 21, 2003 at 11:10:28PM -0400, a@9srv.net wrote:
> // We apologize for letting the code out with a license that obligates
> // the receiver in any way.  I promise that with comments like this its
> // not likely ever to happen again.
>
> y'know, it seems people are divided over this new license. some people
> are happy as could be, some are happy but look for future improvements,
> and some just complain with no end. maybe you guys should come up with
> some way for people to express whether or not they find the license to
> be acceptable before agreeing to it? you could put radio buttons on the
> download page or something. then nobody would be under obligations they
> didn't agree to. that sound good?
>
> seriously, let me repeat what others have said: i'm highly apreciative
> of all the work, both technical and otherwise, all the labs guys (and,
> for that matter, everyone else) has put into this project. plan 9
> remains such an exciting project only thanks to your efforts. while
> some people have expressed some concerns (some even doing so in a
> reasonable manner, i think), everything we've seen from you guys
> represents progress in one form or another. i just keep getting more
> excited about things, and the new license (while a minor concern in my
> mind, for my purposes) just helps that along.
>
> so thanks.

--
Christopher Nielsen
"They who can give up essential liberty for temporary
safety, deserve neither liberty nor safety." --Benjamin Franklin

Re: [9fans] Re: The new ridiculous license

[northern snowfall]

Christopher Nielsen wrote:

>Can we just let this thread die, please? Talk about beating
>a dead horse...
>
I find that sometimes beating a dead horse can be a good thing.
Especially if it gets real dusty and you need to clean it out.

Don

http://www.7f.no-ip.com/~north_


>

Re: [9fans] Re: The new ridiculous license

[Jon Snader]

On Sat, Jun 21, 2003 at 08:33:44PM -0700, Christopher Nielsen wrote:
> Can we just let this thread die, please? Talk about beating
> a dead horse...
>

Usually I'd be inclined to agree with you, but if I am fed up with
the whining and complaining, I can only imagine how the folks at the
Labs must feel.  Sometimes it's appropriate to say ``thank you'' and
to reaffirm to Lucent and the guys that the overwhelming majority of
us do understand and appreciate the efforts they have made for us.

jcs

Re: [9fans] Re: The new ridiculous license

[Dan Oglesby]

Jon Snader wrote:

> On Sat, Jun 21, 2003 at 08:33:44PM -0700, Christopher Nielsen wrote:
>
>>Can we just let this thread die, please? Talk about beating
>>a dead horse...
>>
>
>
> Usually I'd be inclined to agree with you, but if I am fed up with
> the whining and complaining, I can only imagine how the folks at the
> Labs must feel.  Sometimes it's appropriate to say ``thank you'' and
> to reaffirm to Lucent and the guys that the overwhelming majority of
> us do understand and appreciate the efforts they have made for us.
>
> jcs
>

I just signed up for this mailing list last week.  I'm currently lurking
a bit to get a feel for how things operate around here.

Plan9 interests me.  I will be installing Plan9 on a machine I am
currently building (finding compatible hardware).

 From someone who is incredibly "green" with regards to this system, I
wish to say "THANK YOU" to the people who have made Plan9 possible.

Too many people fail speak up to offer thanks for the hard work of
others in this day and age.  This is not beating a dead horse, it is
speaking up and making your opinion known.

*crawls back into the shadows*

--Dan

Re: [9fans] Re: The new ridiculous license

[Douglas A. Gwyn]

David Presotto wrote:
> We apologize for letting the code out with a license that obligates
> the receiver in any way.  I promise that with comments like this its
> not likely ever to happen again.

Oh, come on!  You can't let a never-satisfied malcontent dictate
what your policy should be.  There are many other satisfied
customers.  It's hard to consider somebody who wants a handout
without providing anything in return a customer at all.

Re: [9fans] Re: The new ridiculous license

[bs]

David Presotto wrote:
>>What we see from Lucent is typical corporate psychology. They're afraid to
>>let one iota more go than necessary to make a profit. It's hard to take
>>any argument or claim based on 'justify a trust' when the only issue at
>>hand is profit.
>
>
> We apologize for letting the code out with a license that obligates
> the receiver in any way.  I promise that with comments like this its
> not likely ever to happen again.
One can only satisfy some people all the time, all the people some time...

I for one am happy with this license. It also proves that there is
nothing really free. I am looking forward to a similar license for Inferno.

Optimistically, with these two, a computing revolution might begin (again).

Re: [9fans] Re: The new ridiculous license

[matt]

>
> I for one am happy with this license. It also proves that there is
> nothing really free. I am looking forward to a similar license for
> Inferno.
>
> Optimistically, with these two, a computing revolution might begin
> (again).


There is already movement in this direction from Inferno with a new
licensing scheme in the pipeline for the forthcoming 4th edition

http://www.vitanuova.com/inferno/4thedoverview.html

http://www.vitanuova.com/inferno/4e/licence.html


The best way to help plan9 or inferno is to buy a copy.

Spend some time learning about it and share whatever little nuggets of
brilliance you find with the world. Every line of working source code
that appears is eagerly awaited as we all walk in different directions.

Use the source, Luke.

etc.

Re: [9fans] Re: The new ridiculous license

[boyd, rounin]

> Every line of working source code that appears is eagerly
> awaited as we all walk in different directions.

sure, and you can use 'repo' as pointer to 'em if you like:

    http://www.insultant.net/repo

since i got insultant.net re-hosted and more or less setup.

maybe i should add a pointer to the wiki, but i'm not a huge
fan of wiki's.

i'd like to attack the boot from memory stick deal, but i have
a few more pressing issues, like finding a job, donc une
chose � la fois ...

Re: [9fans] Re: The new ridiculous license

[Douglas A. Gwyn]

Jim Choate wrote:
> What we see from Lucent is typical corporate psychology. They're afraid to
> let one iota more go than necessary to make a profit. It's hard to take
> any argument or claim based on 'justify a trust' when the only issue at
> hand is profit.
> Get real.

You should take your own advice and "get real".  It has been quite
evident that Lucent doesn't expect to make a profit from Plan 9 as
such.  But in the real world, potential litigation is an important
concern.  Nobody, corporation or otherwise, should be expected to
do good deeds with the expectation of getting screwed for doing so.

[9fans] BOF timing

[ron minnich]

I'm just checking again -- I'm there from june 7 to june 14. Any interest
in a BOF wednesday or thursday night?

ron

Re: [9fans] BOF timing

[Dan Cross]

> I'm just checking again -- I'm there from june 7 to june 14. Any interest
> in a BOF wednesday or thursday night?

I think that might be okay, but I've got to check the timing again.  I'm
supposed to go to Corpus Christi sometime around then.  Where exactly will
the BoF be?  If it's someplace close by, maybe I'll ride the Harley out.

	- Dan C.

Re: [9fans] BOF timing

[David Presotto]

I'll arrive at the airport around 8:15 on Wed.  If it's
a late boff, I'll make it.

Re: [9fans] BOF timing

[Dan Cross]

> I'll arrive at the airport around 8:15 on Wed.  If it's
> a late boff, I'll make it.

Umm, no offense, but if there's any boffing involved, I think I'll stay
home instead, thanks.

	- Dan C.

Re: [9fans] BOF timing

[ron minnich]

On Fri, 30 May 2003, Dan Cross wrote:

> > I'm just checking again -- I'm there from june 7 to june 14. Any interest
> > in a BOF wednesday or thursday night?
>
> I think that might be okay, but I've got to check the timing again.  I'm
> supposed to go to Corpus Christi sometime around then.  Where exactly will
> the BoF be?  If it's someplace close by, maybe I'll ride the Harley out.

we'll have to sneak you in, Usenix claim is it is open to registered
attendees only but who's going to give any shit to a guy on a harley?

Can you ride it through the hotel doors and up the stairs to the room?
Should resolve any issues.

Anyway get back to me on timing. IF I can figure out how to set up a BOF
I'll do it.

ron

Re: [9fans] BOF timing

[Dan Cross]

> > I think that might be okay, but I've got to check the timing again.  I'm
> > supposed to go to Corpus Christi sometime around then.  Where exactly will
> > the BoF be?  If it's someplace close by, maybe I'll ride the Harley out.
>
> we'll have to sneak you in, Usenix claim is it is open to registered
> attendees only but who's going to give any shit to a guy on a harley?
>
> Can you ride it through the hotel doors and up the stairs to the room?
> Should resolve any issues.
>
> Anyway get back to me on timing. IF I can figure out how to set up a BOF
> I'll do it.

If it helps, I can bring a couple of guns, too.  This is in Texas, after
all.

Seriously, though, I don't think it'll be too hard to get in.  Right now,
I'm thinking Thursday is probably better, but I'll know definitely this
evening.  Who all is going to be there?

	- Dan C.

Re: [9fans] BOF timing

[ron minnich]

On Fri, 30 May 2003, Dan Cross wrote:

> Seriously, though, I don't think it'll be too hard to get in.  Right now,
> I'm thinking Thursday is probably better, but I'll know definitely this
> evening.  Who all is going to be there?

so far it's me, andrey, presotto, and .....

I'm bringing the plan 9 solid state cluster.

ron

Re: [9fans] BOF timing

[Scott Schwartz]

| so far it's me, andrey, presotto, and .....
|
| I'm bringing the plan 9 solid state cluster.

For those of us who can't make it, it would be cool if you guys could
take notes and pictures and post them here afterwards.

Re: [9fans] BOF timing

[ron minnich]

OK, somebody who's coming, bring your digital camera.

I've asked for a 9-11 slot. I'm hoping to get some hacking done too.

ron

[9fans] 9pm broken?

[Jack Johnson]

Am I crazy, or is awk broken in 9pm?

	du -a | awk '{print $2}'

returns nada, as does

	awk '{print "hi"}'

(or am I mired in linuxisms?)

-Jack

P.S.
This is all on XP, if it matters.

Re: [9fans] BOF timing

[Dan Cross]

> OK, somebody who's coming, bring your digital camera.

Okay, I'll bring mine, if they let me in.

> I've asked for a 9-11 slot. I'm hoping to get some hacking done too.

Cool.

	- Dan C.

Re: [9fans] BOF timing

[boyd, rounin]

can't we make it a plan 9 BOOF[head]?

Re: [9fans] BOF timing

[ron minnich]

On Fri, 30 May 2003, boyd, rounin wrote:

> can't we make it a plan 9 BOOF[head]?


that would have been too smart for me to think of. I did

Plan 9 Show and Tell

Sorry, bad name, I ran out of ideas.

ron

Re: [9fans] BOF timing

[Geoff Collyer]

I'll be there, arriving at the airport Wednesday just after 18h.

Re: [9fans] BOF timing

[boyd, rounin]

http://www.tmk.com/ftp/humor/firearms.txt

Re: [9fans] BOF timing

[Jack Johnson]

On Fri, 30 May 2003, ron minnich wrote:
> I'm just checking again -- I'm there from june 7 to june 14. Any interest
> in a BOF wednesday or thursday night?

I would love to be there, though I won't be attending (and probably
wouldn't have much to contribute, but I make a decent sponge).

For what it's worth, if you received the USENIX booklet in the mail, this
is the insane coaster from the back cover:

http://www.rcdb.com/installationdetail605.htm

Just in case you need a different kind of BOF gathering afterwards.

-Jack

[9fans] Mp3 Resources

[mp3]

[-- Attachment #1.1: Type: text/plain, Size: 898 bytes --]

Hi,

 My name is Marc Janeway and I have a site about mp3 and it contains resources related to this and this is the url: "qozi.com/mp3".
 I think our sites are compatible and I would like very much to exchange links with your site: http://plan9.escet.urjc.es/.

 If you don't agree with that, just ignore this message, but if you like the idea you can fill in the form at: http://www.qozi.com/mp3/form.html and you will see your link up on our site in a day or two.

 Also in order for you to link to us you might use this information:

 URL: http://www.qozi.com/mp3/
 Title: Mp3 Resources
 Description: mp3 related news, books and web resources

 or you can copy & paste this :

 --START HERE--

 <a href="http://www.qozi.com/mp3/">Mp3 Resources</a> - mp3 related news, books and web resources.<br><br>

 --END HERE--

 Best Regards,
 Marc Janeway


[-- Attachment #1.2: Type: text/html, Size: 1185 bytes --]

Re: [9fans] Mp3 Resources

[boyd, rounin]

all this spam is beginning to annoy me -- time for active measures.

Re: [9fans] Mp3 Resources

[Scott Schwartz]

> all this spam is beginning to annoy me -- time for active measures.

The simplest thing is to disallow non-list-member postings.
We can figure out what to do about the usenet gateway afterwards.

Re: [9fans] Mp3 Resources

[boyd, rounin]

> The simplest thing is to disallow non-list-member postings.
> We can figure out what to do about the usenet gateway afterwards.

no, i want to erradicated the _whole problem_, not just for one list.

and i reckon i know how.

Re: [9fans] Mp3 Resources

[Damian Gerow]

Thus spake boyd, rounin (boyd@insultant.net) [29/05/03 11:25]:
> > The simplest thing is to disallow non-list-member postings.
> > We can figure out what to do about the usenet gateway afterwards.
>
> no, i want to erradicated the _whole problem_, not just for one list.
>
> and i reckon i know how.

Care to share with the rest of us?  There's a large number of people
currently investigating ways to kill spam.

Re: [9fans] Mp3 Resources

[Anthony Mandic]

Damian Gerow wrote:
>
> Thus spake boyd, rounin (boyd@insultant.net) [29/05/03 11:25]:
> >
> > no, i want to erradicated the _whole problem_, not just for one list.
> >
> > and i reckon i know how.
>
> Care to share with the rest of us?  There's a large number of people
> currently investigating ways to kill spam.

	After coming across this -
	http://support.microsoft.com/support/kb/articles/Q99/8/84.asp
	in comp.risks a while back, I settled on a more proactive
	spam deflection policy (and since it sticks to to Hotmail as
	well, I'm killing two birds).

-am	� 2003

Re: [9fans] Mp3 Resources

[boyd, rounin]

> Care to share with the rest of us?

dws works, but i have an even better idea:

     http://www.insultant.net/repo/dws.html

Re: [9fans] Mp3 Resources

[rog]

> dws works

deep water soloing?

Re: [9fans] Mp3 Resources

[boyd, rounin]

> deep water soloing?

did you _read_ the script?

Re: [9fans] Mp3 Resources

[rog]

> > deep water soloing?

> did you _read_ the script?

hit send before i realised the link pertained to the acronym...

Re: [9fans] Mp3 Resources

[Dan Cross]

> > dws works
>
> deep water soloing?

Die, Worthless Spammer!

Somebody should make a video game.  Make it a first person shooter, like
Unreal Tournament (gotta dig the sniper rifle in that one), but with
spammers instead of aliens.

	- Dan C.

Re: [9fans] Mp3 Resources

[paurea]

> Somebody should make a video game.  Make it a first person shooter, like
> Unreal Tournament (gotta dig the sniper rifle in that one), but with
> spammers instead of aliens.

Isn't speaking of spam itself spam?. Maybe it is meta-spam....

							Gorka

Re: [9fans] Mp3 Resources

[boyd, rounin]

> Somebody should make a video game.  Make it a first person shooter, like
> Unreal Tournament (gotta dig the sniper rifle in that one), but with
> spammers instead of aliens.

there was some sort of flash based exe i got a while back and you could
snipe at stuff, and as you got better it got harder.  it was based around
some US western bar theme ...

Re: [9fans] Mp3 Resources

[ron minnich]

On Fri, 30 May 2003, boyd, rounin wrote:

> > Somebody should make a video game.  Make it a first person shooter, like
> > Unreal Tournament (gotta dig the sniper rifle in that one), but with
> > spammers instead of aliens.

Why not SCO Lawyers instead of spammers?

ron

Re: [9fans] Mp3 Resources

[boyd, rounin]

> Why not SCO Lawyers instead of spammers?

SCO, my god, that was lunix++

Re: [9fans] Mp3 Resources

[Martin Harriss]

"boyd, rounin" wrote:
>
> > The simplest thing is to disallow non-list-member postings.
> > We can figure out what to do about the usenet gateway afterwards.
>
> no, i want to erradicated the _whole problem_, not just for one list.
>
> and i reckon i know how.

Does it involve large thermonuclear devices?

Re: [9fans] Mp3 Resources

[Robin KAY]

Scott Schwartz wrote:

> The simplest thing is to disallow non-list-member postings.
> We can figure out what to do about the usenet gateway afterwards.

Implement a way to join the list but not actually receive any mail from
it. Accept postings from the NNTP gateway that come from list members.

--
Wishing you good fortune,
--Robin Kay-- (komadori)

[9fans] suggestion: avoiding out of date binaries

[Fco.J.Ballesteros]

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

Hi,

	I just got bitten recently by a couple of out of date binaries.
All I had to do to `fix' what seemed to be a bug was to recompile a
couple of programs.

What about automating recompilation of out of date programs?
My system is very much up to date wrt sources and it seems
that all of my /386/bin is out of date, sic.

The silly script I attach does pretty well for me to detect out of date
binaries. It would be a matter of recompiling those ones detected after
source code gets changed. I know this would make us pull new binaries
often, but at least it's better for safety.

Even better would be to instruct our mkfiles to compile only thing out
of date and then simply run `mk' in the whole cmd tree; but I dont
know of a clean way of doing it. The only way I know would be to
use of a script like this in `update' targets added to every mkfile.

[-- Attachment #2: Type: text/plain, Size: 1040 bytes --]

#!/bin/rc
#
# -q: faster, but you wont know why it's out of date
# -i: to ignore a file you know has changed (eg /sys/include/libc.h)

rfork e

fn usage {
	echo usage: outofdate [-q] [-i ignore] file... >[1=2]
	exit usage
}

fn newer {
	m1=`{mtime $1 | awk '{print $1}'}
	m2=$2
	test $m1 -gt $m2
}

ignored=()
quiet=no
while(~ $1 -*){
	switch($1){
	case -q
		quiet=yes
	case -i
		if (~ $2 '')
			usage
		ignored=`{cat $2}
		shift
	case -*
		usage
	}
	shift
}
if (~ $#* 0)
	usage

updated=''
for (file in $*){
	if (~ `{file $file} *'plan 9 executable'*) {
		srcs=`{nm -a $file | grep ' z ' | sed -e 's/^.* z //' |
			 grep -v '^$' | sort | uniq}
		fupdated=''
		ftime=`{mtime $file | awk '{print $1}'}
		for (s in $srcs) {
			if (! ~ $fupdated outofdate || ! ~ $quiet yes)
			if (test -f $s)
			if (! ~ $s $ignored)
			if (newer $s $ftime){
				fupdated=outofdate
				updated=outofdate
				if (~ $quiet yes)
					echo $file
				if not
					echo $file: $s
			}
		}
	}
}
exit $updated

Re: [9fans] suggestion: avoiding out of date binaries

[Russ Cox]

A cron job recompiles all the binaries every night and then
mails me the list of changed binaries.  I manually install them
after sanity checking the list.

Which binaries in particular were out of date?  That isn't
supposed to happen anymore.

Perhaps you weren't pulling the binaries because you'd
compiled them before (and thus they're locally modified).

Russ

Re: [9fans] suggestion: avoiding out of date binaries

[Fco.J.Ballesteros]

> Which binaries in particular were out of date?  That isn't
> supposed to happen anymore.
> Perhaps you weren't pulling the binaries because you'd
> compiled them before (and thus they're locally modified).

Almost all the binaries are out of date here. I just checked and I
think that happens on sources too. For example:

; ; ls -l (/n/sources/plan9/ /)^sys/include/libc.h
--rw-rw-r-- M 63 glenda sys 18829 Apr  4 05:13 /n/sources/plan9/sys/include/libc.h
--rw-rw-r-- M  9 sys    sys 18829 Apr  4 05:13 /sys/include/libc.h
; ls -l (/n/sources/plan9/ /)^386/bin/rc
--rwxrwxr-x M  9 sys    sys 140122 Feb 18 04:14 /386/bin/rc
--rwxrwxr-x M 63 glenda sys 140122 Feb 18 04:14 /n/sources/plan9/386/bin/rc

That's what outofdate says, in fact.

; outofdate /386/bin/rc
/386/bin/rc: /sys/include/libc.h

Re: [9fans] suggestion: avoiding out of date binaries

[Russ Cox]

> Almost all the binaries are out of date here. I just checked and I
> think that happens on sources too. For example:
>
> ; ; ls -l (/n/sources/plan9/ /)^sys/include/libc.h
> --rw-rw-r-- M 63 glenda sys 18829 Apr  4 05:13 /n/sources/plan9/sys/include/libc.h
> --rw-rw-r-- M  9 sys    sys 18829 Apr  4 05:13 /sys/include/libc.h
> ; ls -l (/n/sources/plan9/ /)^386/bin/rc
> --rwxrwxr-x M  9 sys    sys 140122 Feb 18 04:14 /386/bin/rc
> --rwxrwxr-x M 63 glenda sys 140122 Feb 18 04:14 /n/sources/plan9/386/bin/rc

Yes but this is only because I cheat sometimes.
For example, if libc.h is updated with something
harmless (like the addition of a new function),
there's no need to recompile every binary in the
system.  When I apply such inconsequential changes,
I do the following:

* make sure the binaries are up-to-date on sources
* make the change and recompile everything
* record info about new binaries but don't install them

Sweeps actually compare the recently compiled binaries
with binaries in a staging area.  The last step above
copies the new binaries to the staging area but not sources.
This way future sweeps will not think they need updating,
until they change again.

This way everyone doesn't have to download all new
binaries just because we added a function to libc.h.

You haven't answered my question yet about which
binaries were actually broken.  Tit for tat, you know.

Russ

Re: [9fans] suggestion: avoiding out of date binaries

[Fco.J.Ballesteros]

I see. That's nice. I'm very happy to know that sources binaries are kept
updated.

Now that you ask,
the binaries were paqfs and mkpaqfs for the arm as well as 5[cla] for the
pc. What happen was that a freshly recompiled bitsy kernel was not able to
attach to the paqdisk nor to file servers. I just recompiled 5[cla] and
then recompiled /sys/src/paqfs for the arm and everything got working.

This is what outofdate said for 5c, for example.

; outofdate /386/bin/5c
/386/bin/5c: /386/include/u.h
/386/bin/5c: /sys/include/libc.h
/386/bin/5c: /sys/src/cmd/cc/dcl.c
/386/bin/5c: /sys/src/cmd/cc/dpchk.c
/386/bin/5c: /sys/src/libc/9sys/dirstat.c
/386/bin/5c: /sys/src/libc/fmt/dofmt.c


thanks a lot for your replies

Re: [9fans] suggestion: avoiding out of date binaries

[Geoff Collyer]

As I recall, the compiler binaries other than 8c aren't maintained on
sources, so you have to recompile them yourself as needed.

Re: [9fans] suggestion: avoiding out of date binaries

[Fco.J.Ballesteros]

> As I recall, the compiler binaries other than 8c aren't maintained on
> sources, so you have to recompile them yourself as needed.

Then I'd suggest to keep them at least recompiled when getting out of
date. If that's automated as Russ said, it'd be easy to include other
compiler binaries too. They're small so I don't think it would be a problem.

Re: [9fans] suggestion: avoiding out of date binaries

[Russ Cox]

For non-386 binaries, you are on your own.
As Geoff points out, you are also on your own
for non-386 compilers, loaders, and assemblers.

In both cases the theory is that almost no one uses
them, so they're not worth the space they take up.
The first case is more defensible than the second.

Russ

Re: [9fans] suggestion: avoiding out of date binaries

[Fco.J.Ballesteros]

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

I think what happen to me is just that I recompile all the arm
binaries/libs/..., but I just didnt notice that I had to do the
same with 5[cla] for the pc.

BTW, I'm not sure, but think that what happen to me could also
happen to Sape.

Anyway, now that I know it's not a big deal; although I still think it
would be more clean to keep all the 386 binaries updated.

thanks a lot again.

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

From: "Russ Cox" <rsc@plan9.bell-labs.com>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] suggestion: avoiding out of date binaries
Date: Mon, 19 May 2003 03:32:10 -0400
Message-ID: <e17842438481b3cdd19b769706354b38@plan9.bell-labs.com>

For non-386 binaries, you are on your own.
As Geoff points out, you are also on your own
for non-386 compilers, loaders, and assemblers.

In both cases the theory is that almost no one uses
them, so they're not worth the space they take up.
The first case is more defensible than the second.

Russ

Re: [9fans] suggestion: avoiding out of date binaries

[Geoff Collyer]

Oh, barf!  I compiled everything for the arm for the first time a few
days ago since I expect an ipaq to arrive Monday or Tuesday.

I just rebuilt 5c and it's different from /386/bin/5c:

cpu% ls -l 8.out /bin/5c
--rwxrwxr-x M 25391 sys   sys 300181 Jun 22  2002 /bin/5c
--rwxrwxr-x M 25391 geoff sys 300874 May 19 00:40 8.out
cpu% size 8.out /bin/5c
187738t + 31664d + 27176b = 246578	8.out
187340t + 31656d + 27176b = 246172	/bin/5c

Do I really have to throw away 89MB of WORM storage and rebuild /arm
all over again?

Re: [9fans] suggestion: avoiding out of date binaries

[boyd, rounin]

prusker & wobber

Re: [9fans] suggestion: avoiding out of date binaries

[Fco.J.Ballesteros]

> Do I really have to throw away 89MB of WORM storage and rebuild /arm
> all over again?

I keep /arm at /n/once, which is a partition that wont get into the
worm. But yes, I'd recompile it all.

Re: [9fans] suggestion: avoiding out of date binaries

[Scott Schwartz]

| Which binaries in particular were out of date?  That isn't
| supposed to happen anymore.

The kernels on a recently installed system weren't up to date, if I
recall correctly.

Also, during the install, I reshaped a window and got an error from
/dev/draw via a failing echo command.  8.5 never complained about
stuff like that!

Re: [9fans] suggestion: avoiding out of date binaries

[Russ Cox]

> The kernels on a recently installed system weren't up to date, if I
> recall correctly.

The install CD is woefully out of date.  So are the kernels on sources.
It's hard to tell if the kernels are out of date because they
contain the time they were compiled, so cmp isn't enough.
The next time I install kernels on sources (which requires
more testing than installing binaries) I'm going to retire the
old install CD and make the nightly regenerated snapshot the
default install CD.

> Also, during the install, I reshaped a window and got an error from
> /dev/draw via a failing echo command.  8.5 never complained about
> stuff like that!

I'm having a hard time parsing this.  8.5 is replaced by rio, not /dev/draw.
The failing echo command is completely separate from both.
There are some background processes trying to guard against
people who touch the mouse without knowing what they're doing.
In particular, every time a prompt comes up in the main
window, it runs

	echo top >/dev/wctl
	echo current >/dev/wctl

or something like that.  That's probably what failed, though
I can't imagine why.  I can't think of any reasons you'd echo
anything into a file in the /dev/draw hierarchy.

Russ

Re: [9fans] suggestion: avoiding out of date binaries

[Scott Schwartz]

| I'm having a hard time parsing this.

At 4am, I had a hard time generating it. :)

I meant to say rio, of course.  The message was "action disallowed when
mouse active", from wctl.c.

| or something like that.  That's probably what failed, though
| I can't imagine why.  I can't think of any reasons you'd echo
| anything into a file in the /dev/draw hierarchy.

All I did was sweep out a new window while things were
scrolling along in the install windows.

Re: [9fans] suggestion: avoiding out of date binaries

[Joel Salomon]

On Sun, 18 May 2003, Fco.J.Ballesteros wrote:
> What about automating recompilation of out of date programs?
Isn't the purpose of mk to be able to compile only programs that are out
of date wrt source? Or am I mising something

--Joel

Re: [9fans] suggestion: avoiding out of date binaries

[Fco.J.Ballesteros]

> Isn't the purpose of mk to be able to compile only programs that are out
> of date wrt source? Or am I mising something

mk knows how to generate targets from sources. But if you for example,
do a mk clean, a mk install will install the binary again.

[9fans] Free Plan 9 "shell" accounts?

[Martin Kielhorn]

Has there ever been  an attempt  to provide free accounts
on a Plan 9 network for people curious to "play" with it.

I've found several Unix servers where free shell accounts
are available (like m-net.arbornet.org). I wasn't able to
locate something comparable for Plan 9.

I would really like an open  Plan 9  CPU  server. Maybe I
could even connect to it with drawterm or vnc because I
would really like to learn programming for rio.

How many graphical logins could a typical (perhaps  256M,
500 MHz, shared 155Mbit internet) cheap server provide?

On m-net there are often 20 - 30 people logged in and all
programs still work responsive (some people surve the web
others read mails and many are idle  - everything in com-
mand line).

			Martin

Re: [9fans] Free Plan 9 "shell" accounts?

[Andrew]

ive been trying to get an open plan9 network going, i was almost done
when my fileserver broke (i think the motherboard gave up). I have some
other boxes to move it to, just havent had time, but probably will
this weekend.

On Fri, May 16, 2003 at 06:05:06PM +0200, Martin Kielhorn wrote:
> Has there ever been  an attempt  to provide free accounts
> on a Plan 9 network for people curious to "play" with it.
>
> I've found several Unix servers where free shell accounts
> are available (like m-net.arbornet.org). I wasn't able to
> locate something comparable for Plan 9.
>
> I would really like an open  Plan 9  CPU  server. Maybe I
> could even connect to it with drawterm or vnc because I
> would really like to learn programming for rio.
>
> How many graphical logins could a typical (perhaps  256M,
> 500 MHz, shared 155Mbit internet) cheap server provide?
>
> On m-net there are often 20 - 30 people logged in and all
> programs still work responsive (some people surve the web
> others read mails and many are idle  - everything in com-
> mand line).
>
> 			Martin
>

Re: [9fans] Free Plan 9 "shell" accounts?

[Geoff Collyer]

The upstream bandwidth is probably the major resource requirement.
I've got adequate resources to offer accounts but my ADSL is *very* A:
only 128Kb/s upstream.  There's also the issue of WORM-block
consumption or, in venti, arena-block consumption.

If giving out accounts to complete strangers, I'd want to look at what
to do about the wide-open permissions that seem to be necessary under
/mail and the ability of anybody to create and remove files from /srv.
Apparently no one can rename files in /srv (the attempt is quietly
ignored), which helps.  It might be handy to have a way to create a
new #s instance or perhaps to be able to copy #s during rfork
(RFSRVG?).

Re: [9fans] Free Plan 9 "shell" accounts?

[andrey mirtchovski]

On Fri, 16 May 2003, Geoff Collyer wrote:

> If giving out accounts to complete strangers, I'd want to look at what
> to do about the wide-open permissions that seem to be necessary under
> /mail and the ability of anybody to create and remove files from /srv.
> Apparently no one can rename files in /srv (the attempt is quietly
> ignored), which helps.  It might be handy to have a way to create a
> new #s instance or perhaps to be able to copy #s during rfork
> (RFSRVG?).
>

you know, this may be a good small project -- identify potential soft spots
of a Plan 9 installation that has completely untrusted users.

i had myself created a small system to which i gave access to friends to
connect with drawterm, but my setup was much different than a normal plan9
installation -- a kfs/cpu/auth server running within a host-only vmware
session in a restricted unix process, with limited cpu time and disk space.
i had forwarded ports 567 and 17013 to the 172.16... internal ip address of
the box, and have told everybody that they simply won't be able to connect
to anything external..

the accounts were just for educational purpose, and the occasional
xscreensaver hack :)

unfortunately my university keeps thinking that i'm running P2P applications
and takes me off the net whenever it feels like it, so i can't offer this
setup for general consumption...

does anyone remember the alpha boxes Compaq had setup three years ago? they
gave free accounts to whomever wanted them and let them test their software
on spiffy fast alphas running tru64 and linux.. that's the setup i was
trying to accomplish..

andrey

Re: [9fans] Free Plan 9 "shell" accounts?

[northern snowfall]

>
>
>does anyone remember the alpha boxes Compaq had setup three years ago? they
>gave free accounts to whomever wanted them and let them test their software
>on spiffy fast alphas running tru64 and linux.. that's the setup i was
>trying to accomplish..
>
Yeah, www.testdrive.compaq.com is the signup page. I still
use this service to study Alpha assembly.
Don

>

Re: [9fans] Free Plan 9 "shell" accounts?

[northern snowfall]

>
>
>If giving out accounts to complete strangers, I'd want to look at what
>to do about the wide-open permissions that seem to be necessary under
>/mail and the ability of anybody to create and remove files from /srv.
>Apparently no one can rename files in /srv (the attempt is quietly
>ignored), which helps.  It might be handy to have a way to create a
>new #s instance or perhaps to be able to copy #s during rfork
>(RFSRVG?).
>
Just as a note, I attempted this same thing for friends a while
back. I was left with a feeling of insecurity, however. While
plan9 is great for securing against individuals without access
to a CPU server, allowing users to connect leaves many things
dynamically changeable. Of course, this is fine for most
research situations where users have a sense of loyalty to
their environment. However, a "free 9shell" situation would
have many possibilities for on-system manipulation.
    My biggest problems related to securing the network. Any
user can alter the routing tables, arp tables, etc. Not to
mention, users are also able to put the ether device in promisc
mode and write to the ether device raw. This obviously leaves
sniffing easily open to both hubs and switched environments, as
spoofing to hijack the network is extremely simplified on plan9.
In fact, if you know what you're doing, you can do it without
compiling any special code. I wrote patches to quash these issues
in plan9 revision 3 and had good success with it. Though, I've
not looked at the differences in the network code from 3 to 4, so,
I wouldn't know how my patches would be relevant now.
    Since this is something I've had on the back burners of my
in-mind todo-list, I may upgrade the patches to 4.
Don

>

Re: [9fans] Free Plan 9 "shell" accounts?

[northern snowfall]

> I wrote patches to quash these issues
> in plan9 revision 3 and had good success with it. Though, I've
> not looked at the differences in the network code from 3 to 4, so,
> I wouldn't know how my patches would be relevant now.


    As an addendum, it should be noted that these
constraints make plan9 look less and less like
plan9 and more and more like a UNIX superuser
environment. Which, gives me a strange desire to
design a 9p network amendment, seperating the actual
network code to a single network server.
    So, now, instead of just a CPU Auth and FS, you'd
also have a Net. Imports might actually make this
desirable, allowing a single administrator to maintain
each fragment of a complete virtual operating system.
It might be possible to hack in more support for a
"firewall" or other things using this kind of scheme.

Don

Re: [9fans] Free Plan 9 "shell" accounts?

[Russ Cox]

I think the real problem with a free Plan 9 server is
latency.  We can figure out the system robustness
problems, but the network latency is much harder
to get around.  I'm typing this in my apartment,
on a drawterm session over my DSL line to
plan9.bell-labs.com.  The latency is about 38ms.
At this distance drawterm is usable but noticeably
sluggish.  But 38ms is probably near best case
for an open Plan 9 server across the internet.

You could use a text connection, but that's just
not a faithful experience.

VNC is a little better but still leaves something to
be desired.

Russ

[9fans] Re: Free Plan 9 "shell" accounts?

[Jim Choate]

On Sat, 17 May 2003, Russ Cox wrote:

> I think the real problem with a free Plan 9 server is
> latency.  We can figure out the system robustness
> problems, but the network latency is much harder
> to get around.  I'm typing this in my apartment,
> on a drawterm session over my DSL line to
> plan9.bell-labs.com.  The latency is about 38ms.
> At this distance drawterm is usable but noticeably
> sluggish.  But 38ms is probably near best case
> for an open Plan 9 server across the internet.

The average human response time is something like 200mS. If there is a
problem then it's not 38mS latency, there is something else dragging it
down.

> You could use a text connection, but that's just
> not a faithful experience.
>
> VNC is a little better but still leaves something to
> be desired.

And until somebody pushes it, such as a public server, the problem will
never be solved.


 --
    ____________________________________________________________________

      We are all interested in the future for that is where you and I
      are going to spend the rest of our lives.

                              Criswell, "Plan 9 from Outer Space"

      ravage@ssz.com                            jchoate@open-forge.org
      www.ssz.com                               www.open-forge.org
    --------------------------------------------------------------------

Re: [9fans] Re: Free Plan 9 "shell" accounts?

[Russ Cox]

> The average human response time is something like 200mS. If there is a
> problem then it's not 38mS latency, there is something else dragging it
> down.

This is true.  There are too many round trips in most
graphics operations.  That multiplies the 38ms up to
something barely bearable.  But like I said, the latency of
those operations is the real barrier to using the system
remotely.

Russ

[9fans] Latency Issues (was: Re: Free Plan 9 "shell" accounts?)

[Jim Choate]

On Sun, 18 May 2003, Russ Cox wrote:

> > The average human response time is something like 200mS. If there is a
> > problem then it's not 38mS latency, there is something else dragging it
> > down.
>
> This is true.  There are too many round trips in most
> graphics operations.  That multiplies the 38ms up to
> something barely bearable.  But like I said, the latency of
> those operations is the real barrier to using the system
> remotely.

That was my next question, what is multiplying those latencies?

As a datum, I am on a ISDN to a T1 and the ping times to my gateway which
is about 6 miles away leaves me with a 34mS latency on ping times. I pull
Xterms and such under Linux to Linux and don't see any significant latency
issues.

If we have 1000 mS and 30 frames/S this leaves us with 33 mS/frame. That's
roughly a single frames worth of delay.

On average, how many transfers are required for a single 640x480 frame?

Clearly the graphics engine will need some attention once we get the auth
issues worked out.

I'll bump up its priority in the 'To do' queue...;) Considering we want to
port Squeak to Plan 9 for the express purpose of using the VRML to create
a expandable shared game environment this is clearly an important issue.

Thanks for the info.


 --
    ____________________________________________________________________

      We are all interested in the future for that is where you and I
      are going to spend the rest of our lives.

                              Criswell, "Plan 9 from Outer Space"

      ravage@ssz.com                            jchoate@open-forge.org
      www.ssz.com                               www.open-forge.org
    --------------------------------------------------------------------

Re: [9fans] Latency Issues (was: Re: Free Plan 9 "shell" accounts?)

[Russ Cox]

> That was my next question, what is multiplying those latencies?

Read draw(3), but fundamentally the difference is that a 9P
write doesn't finish until the other side acks it (responds with
an Rwrite), while in X the writes are just sent off without waiting
for responses.  There are a couple draw calls that need responses
(when you're allocating new images, for example) but the majority
don't and would be helped quite a bit by not having to wait for the
Rwrite.

> Clearly the graphics engine will need some attention once we get the auth
> issues worked out.
>
> I'll bump up its priority in the 'To do' queue...;) Considering we want to
> port Squeak to Plan 9 for the express purpose of using the VRML to create
> a expandable shared game environment this is clearly an important issue.

I look forward to your fixes.

Re: [9fans] Latency Issues (was: Re: Free Plan 9 "shell" accounts?)

[Joel Salomon]

On Sun, 18 May 2003, Jim Choate wrote:

> I'll bump up its priority in the 'To do' queue...;) Considering we want to
> port Squeak to Plan 9 for the express purpose of using the VRML to create
> a expandable shared game environment this is clearly an important issue.

Just remember /sys/doc/names:
> Object-oriented readers may approach the rest of this paper as a study
> in how to make objects look like files.

--Joel

Re: [9fans] Re: Free Plan 9 "shell" accounts?

[rob pike, esq.]

> The average human response time is something like 200mS.

Boyd must be superhuman.

-rob

Re: [9fans] Re: Free Plan 9 "shell" accounts?

[boyd, rounin]

> Boyd must be superhuman.

i have not yet begun to fight :)

http://www.history.navy.mil/trivia/trivia02a.htm

[9fans] Re: Free Plan 9 "shell" accounts?

[Jim Choate]

On Fri, 16 May 2003, Martin Kielhorn wrote:

> Has there ever been  an attempt  to provide free accounts
> on a Plan 9 network for people curious to "play" with it.

http://open-forge.org (this site is going away later in the year due to
the poor job market)

or,

http://einstein.ssz.com/hangar18

We don't provide free shell accounts since this really doesn't make a lot
of sense with regard to Plan 9. What we can do is provide a auth server
and related resources (ie process pool and community namespaces). We also
provide services for developers such as webpages and code management tools
(ie CVS).

We are in a re-engineering cycle at the moment due to some changes in
participants. We expect to have the auth server moved to the SSZ domain
sometime during the week of June 16-20. Later in the year the current
primary home site, Open Forge, will be going away due to lack of
sponsorship. This means that SSZ will return as the primary host of the
webpage and services.


 --
    ____________________________________________________________________

      We are all interested in the future for that is where you and I
      are going to spend the rest of our lives.

                              Criswell, "Plan 9 from Outer Space"

      ravage@ssz.com                            jchoate@open-forge.org
      www.ssz.com                               www.open-forge.org
    --------------------------------------------------------------------

Re: [9fans] Re: Free Plan 9 "shell" accounts?

[Dan Cross]

> http://einstein.ssz.com/hangar18
>
> We don't provide free shell accounts since this really doesn't make a lot
> of sense with regard to Plan 9. What we can do is provide a auth server
> and related resources (ie process pool and community namespaces). We also
> provide services for developers such as webpages and code management tools
> (ie CVS).

I don't understand what this means; doesn't the ability to start a
process on a remote machine (``process pool'') mean you can start a
shell on it?

	- Dan C.

[9fans] Re: Free Plan 9 "shell" accounts?

[Jim Choate]

On Sun, 18 May 2003, Dan Cross wrote:

> I don't understand what this means; doesn't the ability to start a
> process on a remote machine (``process pool'') mean you can start a
> shell on it?

Yes, if you want to look at it by the 'process tied to machine' viewpoint.
Plan 9 means much more. The concept of 'starting a shell on it' is a
rather non-distributed way of thinking about Plan 9 though. An archaic
viewpoint if you will.

Plan 9 has per process namespace, and there is really nothing that says
the namespace that a particular process is running on a particular piece
of hardware are shared. In other words the resources for a given shell
don't necessarily have to reside on that machine. In other words the
process server doesn't have to share any of its kfs resources into the
namespace of the process). The namespace doesn't even have to come from a
single machine. So, if you've got a process that has it's I/O connected to
your machine, and various namespaces transitively mounted from machines
other than the process server executing the job, can you really say the
shell is running on 'that machine'?

I'd say "No".

If you have a process server executing a job that spawns multiple
processes, Tower of Hanoi or a factorial might be a job that would do for
an example, and those processes are running on different machines; can
you say that the program runs on 'that machine'?

I'd say "No",

You're running a 'shell on a machine' and that machine hiccups, with
traditional operating systems the only result is to throw an error
condition and halt. On Plan 9 it's possible that in cases that if a
machine were to die the namespace resources (which we'll assume aren't on
the process server native) are saved and the machine that started the
process would simply re-init that job on another processer, without the
user even knowing about it. Is that running that program 'on a machine'?

I'd say "No".

There are many other examples I could think of, you will too; eventually.

Plan 9 has the unique advantage of being able to create a distributed
virtual machine. This means that where the job runs is irrelevant, and
where the resources of the namespace exist is irrelevant. Plan 9 is not so
much 'where' but 'how to impliment'.

To worry about the specific machine is a pretty archaic viewpoint that is
not really compatible with understanding what one can get out of Plan 9.

Plan 9 is a -distributed- operating system. This means that you have to
think of 'process clouds' and many resources clustered together to form a
namespace. The fact the namespace is -per process- is what takes it a step
above the 'run a shell on a machine' perspective.

You have to get past thinking of Plan 9 as a OS 'on a machine' and think
of it as a OS -across machines-. Note the plural in that, it's critical to
understanding the true power of the OS from the perspective of the user.
[1]

If you really want to have an OS on -a machine- then Plan 9 will bring you
nothing of interest. Stick with traditional operating systems. If you want
to join a -community of resources- then look into Plan 9, it will surpise
you. [2]

Hope that helps clear up your confusion...;)


[1] This goes right to the heart of one of my issues with the Plan 9
community here with regard to lack of understanding of 'user' space as
compared to looking at everything as a 'developer' space issue. Such is
the flaw of having a goal of keeping a technology limited to a niche (ie
research OS).

[2] I've mentioned this distinction many times in the past, and it amazes
me that many long time users of Plan 9 still don't 'get it'.


 --
    ____________________________________________________________________

      We are all interested in the future for that is where you and I
      are going to spend the rest of our lives.

                              Criswell, "Plan 9 from Outer Space"

      ravage@ssz.com                            jchoate@open-forge.org
      www.ssz.com                               www.open-forge.org
    --------------------------------------------------------------------

Re: [9fans] Re: Free Plan 9 "shell" accounts?

[Dan Cross]

I know I shouldn't get into this....

> > I don't understand what this means; doesn't the ability to start a
> > process on a remote machine (``process pool'') mean you can start a
> > shell on it?
>
> Plan 9 has per process namespace, and there is really nothing that says
> the namespace that a particular process is running on a particular piece
> of hardware are shared. In other words the resources for a given shell
> don't necessarily have to reside on that machine. In other words the
> process server doesn't have to share any of its kfs resources into the
> namespace of the process). The namespace doesn't even have to come from a
> single machine. So, if you've got a process that has it's I/O connected to
> your machine, and various namespaces transitively mounted from machines
> other than the process server executing the job, can you really say the
> shell is running on 'that machine'?
>
> I'd say "No".

Yes.  It's executing on that machine.  It's effectively the same
situation as a program running on a diskless Unix machine with the
filesystem served by NFS.

So you agree that you will allow someone to run code on your machine,
you just won't provide them with a filesystem.  So they can run a copy
of /bin/rc on your machine if they like.

> If you have a process server executing a job that spawns multiple
> processes, Tower of Hanoi or a factorial might be a job that would do for
> an example, and those processes are running on different machines; can
> you say that the program runs on 'that machine'?
>
> I'd say "No",

Yes.  What it does, such as starting jobs on other machines, is
irrelevant.  It itself is still running on that machine.

> You're running a 'shell on a machine' and that machine hiccups, with
> traditional operating systems the only result is to throw an error
> condition and halt. On Plan 9 it's possible that in cases that if a
> machine were to die the namespace resources (which we'll assume aren't on
> the process server native) are saved and the machine that started the
> process would simply re-init that job on another processer, without the
> user even knowing about it. Is that running that program 'on a machine'?
>
> I'd say "No".

It's possible, perhaps, but doesn't happen now.  At least not without
writing code.  But it would be possible to write the same code on any
number of systems; amoeba comes to mind as an example of a system that
already approximates that sort of behavior.

But that doesn't change the fact that, yes, the program is running on
a machine somewhere.  The only thing you're saying is new is that you
don't care what machine it's running on.

> There are many other examples I could think of, you will too; eventually.

I'm sorry, but I think you're confused about basic definitions.  What
it means for a piece of code to be running on a computer is that it's
executing on that computer.  Whether you can do clever things behind to
scenes to give the illusion of it being transparantly relocatable to
another computer is irrelevant.

Even then, I'm disappointed that all you're talking about is restarting
a program on a different machine.  If you were talking about generalizing
/proc to replicate process state across multiple machines operating
in lockstep in real time, I might start to be kind of impressed.

> Plan 9 has the unique advantage of being able to create a distributed
> virtual machine. This means that where the job runs is irrelevant, and
> where the resources of the namespace exist is irrelevant. Plan 9 is not so
> much 'where' but 'how to impliment'.

That's not unique.  Condor, MOSIX, Amoeba, and other systems implement
similar functionality.

> To worry about the specific machine is a pretty archaic viewpoint that is
> not really compatible with understanding what one can get out of Plan 9.
>
> Plan 9 is a -distributed- operating system. This means that you have to
> think of 'process clouds' and many resources clustered together to form a
> namespace. The fact the namespace is -per process- is what takes it a step
> above the 'run a shell on a machine' perspective.

Again, you're misunderstanding the definition of what it means to run
a shell on a machine.

> You have to get past thinking of Plan 9 as a OS 'on a machine' and think
> of it as a OS -across machines-. Note the plural in that, it's critical to
> understanding the true power of the OS from the perspective of the user.
> [1]

I don't see how the two are mutually exclusive.

> If you really want to have an OS on -a machine- then Plan 9 will bring you
> nothing of interest. Stick with traditional operating systems. If you want
> to join a -community of resources- then look into Plan 9, it will surpise
> you. [2]

Or Amoeba.

> Hope that helps clear up your confusion...;)

I see what you're saying, but I think you missed my point.  It might
help if you reviewed a book on operating systems basics; it's pretty
clear you don't have much of a formal background here.  I can recommend
a titles, if you'd like.

> [1] This goes right to the heart of one of my issues with the Plan 9
> community here with regard to lack of understanding of 'user' space as
> compared to looking at everything as a 'developer' space issue. Such is
> the flaw of having a goal of keeping a technology limited to a niche (ie
> research OS).
>
> [2] I've mentioned this distinction many times in the past, and it amazes
> me that many long time users of Plan 9 still don't 'get it'.

And how.

	- Dan C.

Re: [9fans] Re: Free Plan 9 "shell" accounts?

[Jim Choate]

On Sun, 18 May 2003, Dan Cross wrote:

> I know I shouldn't get into this....

You're such an ass Dan.

> Yes.  It's executing on that machine.

No, only -part of it is 'on that machine'. Your archaic viewpoint is
showing.

> It's effectively the same situation as a program running on a diskless Unix
> machine with the filesystem served by NFS.

No, it's not.

> So you agree that you will allow someone to run code on your machine,

Absolutely, go read the whole point of Hangar 18 at,

http://open-forge.org

http://einstein.ssz.com/hangar18

What do you think 'distributed processing', 'community', and 'tit for tat'
mean?

Oh yeah, you don't have a clue.

You're a perfect example of what is wrong with the Plan 9 community here.


 --
    ____________________________________________________________________

      We are all interested in the future for that is where you and I
      are going to spend the rest of our lives.

                              Criswell, "Plan 9 from Outer Space"

      ravage@ssz.com                            jchoate@open-forge.org
      www.ssz.com                               www.open-forge.org
    --------------------------------------------------------------------

Re: [9fans] Re: Free Plan 9 "shell" accounts?

[andrey mirtchovski]

On Sun, 18 May 2003, Jim Choate wrote:

> You're a perfect example of what is wrong with the Plan 9 community here.
>

You're a perfect example of what's wrong with the world outside the Plan 9
community. Dan's fine, you're not.

Re: [9fans] Re: Free Plan 9 "shell" accounts?

[Dan Cross]

> > I know I shouldn't get into this....
>
> You're such an ass Dan.

...and this is why.  We can't expect anything but an attack after
questioning your views.  This isn't a particularly good way to advance
your argument or start dialogue, Jim.

> > Yes.  It's executing on that machine.
>
> No, only -part of it is 'on that machine'. Your archaic viewpoint is
> showing.

So, what's missing?  It's memory image is stored on that machine: all
the program text, data, and the stack; the processor state including
the PSL and all the machine registers, etc is local.  Even the I/O
devices it does I/O through are local.  The fact that it gets the data
it manipulates from someplace else isn't relevant to the fact that it's
running on that machine.

> > It's effectively the same situation as a program running on a diskless Unix
> > machine with the filesystem served by NFS.
>
> No, it's not.

Okay, then.  Why not?

> > So you agree that you will allow someone to run code on your machine,
>
> Absolutely, go read the whole point of Hangar 18 at,
>
> http://open-forge.org
>
> http://einstein.ssz.com/hangar18
>
> What do you think 'distributed processing', 'community', and 'tit for tat'
> mean?

You cut off the rest of my sentence, which explained what I was getting
at.  Here's the rest:

	...you just won't provide them with a filesystem.  So they
	can run a copy of /bin/rc on your machine if they like.

> Oh yeah, you don't have a clue.

Wow, insults.  That's a great way to advance your viewpoint.

> You're a perfect example of what is wrong with the Plan 9 community here.

So, Jim, can we expect you at the BoF in San Antonio?  Looking forward
to meeting you!

	- Dan C.

[9fans] Re: Free Plan 9 "shell" accounts?

[Jim Choate]

On Sun, 18 May 2003, Dan Cross wrote:

> > > I know I shouldn't get into this....
> >
> > You're such an ass Dan.
>
> ...and this is why.  We can't expect anything but an attack after
> questioning your views.  This isn't a particularly good way to advance
> your argument or start dialogue, Jim.

Pot, kettle, black.

> > > Yes.  It's executing on that machine.
> >
> > No, only -part of it is 'on that machine'. Your archaic viewpoint is
> > showing.
>
> So, what's missing?

Per process namespace (THE most important distinction)

processes running on other processors besides the cpu on the diskless
workstation with shared namespaces that are not tied to any of the processors
the processes are running on (the second most important distinction),

transitive mounts of not only files but hardware (the third most important
distinction).

"If all you know is a hammer, then everything looks like a nail."


 --
    ____________________________________________________________________

      We are all interested in the future for that is where you and I
      are going to spend the rest of our lives.

                              Criswell, "Plan 9 from Outer Space"

      ravage@ssz.com                            jchoate@open-forge.org
      www.ssz.com                               www.open-forge.org
    --------------------------------------------------------------------

Re: [9fans] Re: Free Plan 9 "shell" accounts?

[Dan Cross]

> > ...and this is why.  We can't expect anything but an attack after
> > questioning your views.  This isn't a particularly good way to advance
> > your argument or start dialogue, Jim.
>
> Pot, kettle, black.

I don't understand.  I'm trying to engage in dialogue with you, and
all I get back are insults, a condescending attitude, and flames.  It's
been like this since you showed up on 9fans, as far as I can tell.

> > > > Yes.  It's executing on that machine.
> > >
> > > No, only -part of it is 'on that machine'. Your archaic viewpoint is
> > > showing.
> >
> > So, what's missing?

You keep cutting off my statements.  Here's the rest:

	It's memory image is stored on that machine: all the program
	text, data, and the stack; the processor state including the
	PSL and all the machine registers, etc is local.  Even the I/O
	devices it does I/O through are local.  The fact that it gets
	the data it manipulates from someplace else isn't relevant to
	the fact that it's running on that machine.

Then you go on to say:

> Per process namespace (THE most important distinction)

Which is part of where it gets the data it manipulates.  Again, that's
irrelevant to the idea of a program executing on a computer.

> processes running on other processors besides the cpu on the diskless
> workstation with shared namespaces that are not tied to any of the processors
> the processes are running on (the second most important distinction),

Same.

> transitive mounts of not only files but hardware (the third most important
> distinction).

Same.

> "If all you know is a hammer, then everything looks like a nail."

If you want to change the definition of what ``hammer'' means because
you're confused about what a hammer is, you're going to be in for a
rough time.

It's obvious we're talking at cross-purposes here.

	- Dan C.

Re: [9fans] Re: Free Plan 9 "shell" accounts?

[Jim Choate]

On Sun, 18 May 2003, Dan Cross wrote:

> > > ...and this is why.  We can't expect anything but an attack after
> > > questioning your views.  This isn't a particularly good way to advance
> > > your argument or start dialogue, Jim.
> >
> > Pot, kettle, black.
>
> I don't understand.  I'm trying to engage in dialogue with you,

No Dan you are most assuredly not.

Go back and read the very first sentence of your initial response. At no
point have you been anywhere near your claimed goals.

Try not to gag on your own hubris.


 --
    ____________________________________________________________________

      We are all interested in the future for that is where you and I
      are going to spend the rest of our lives.

                              Criswell, "Plan 9 from Outer Space"

      ravage@ssz.com                            jchoate@open-forge.org
      www.ssz.com                               www.open-forge.org
    --------------------------------------------------------------------

Re: [9fans] Re: Free Plan 9 "shell" accounts?

[Dan Cross]

> > I don't understand.  I'm trying to engage in dialogue with you,
>
> No Dan you are most assuredly not.

I just think you can't answer my questions.

	- Dan C.

(Oh, what the hell, I might as well tell the truth: You're right.  I'm
part of the vast underground conspiracy to try and distract you from
your true destiny: The liberation of the human race from the oppressive
yoke of ignorance.  Only you, with Plan 9 by your side, can do it.  You
are...The One.  The prophecy has foretold all, and it's useless to deny
it any longer.  We're at the dawning of a new era, one in which all the
classical definitions of computer science will be rewritten to conform
to Jim's grand vision.  I must go now; they will be after me for
revealing The Truth.  Don't listen if Scott Schwartz or anyone from
Bell Labs posts ordering me to stop: they're really in on it, too.
Goodbye, Jim, you won't hear from me again as I'll be caught and
reprogrammed.  Good luck!  Remember that I was truly your faithful
servent after the apocolyptic end which is coming, that only you can
bring about!)

Re: [9fans] Re: Free Plan 9 "shell" accounts?

[boyd, rounin]

hanger 18?

err, area 51 ...

Re: [9fans] Re: Free Plan 9 "shell" accounts?

[boyd, rounin]

From: "Jim Choate" <ravage@einstein.ssz.com>
> processes running on other processors besides the cpu on the diskless
> workstation with shared namespaces that are not tied to any of the processors
> the processes are running on (the second most important distinction),

pure MVS ... :(

[9fans] Re: Free Plan 9 "shell" accounts?

[Jim Choate]

On Sun, 18 May 2003, boyd, rounin wrote:

> From: "Jim Choate" <ravage@einstein.ssz.com>
> > processes running on other processors besides the cpu on the diskless
> > workstation with shared namespaces that are not tied to any of the processors
> > the processes are running on (the second most important distinction),
>
> pure MVS ... :(

Strawman. I'm not claiming -any- of this is new or unique in and of
itself.

The collection is. That is what makes Plan 9 unique.


 --
    ____________________________________________________________________

      We are all interested in the future for that is where you and I
      are going to spend the rest of our lives.

                              Criswell, "Plan 9 from Outer Space"

      ravage@ssz.com                            jchoate@open-forge.org
      www.ssz.com                               www.open-forge.org
    --------------------------------------------------------------------

Re: [9fans] Re: Free Plan 9 "shell" accounts?

[boyd, rounin]

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

"Jim Choate" <ravage@einstein.ssz.com> a �crit dans le message de
news:Pine.LNX.4.33.0305181129000.1252-100000@einstein.ssz.com...
> > pure MVS ... :(
>
> Strawman. ...

Mark V. Shaney was not made out of straw.  maybe you mean the tin man?

Re: [9fans] Re: Free Plan 9 "shell" accounts?

[Anthony Mandic]

"boyd, rounin" wrote:
>
> From: "Jim Choate" <ravage@einstein.ssz.com>
> > processes running on other processors besides the cpu on the diskless
> > workstation with shared namespaces that are not tied to any of the processors
> > the processes are running on (the second most important distinction),
>
> pure MVS ... :(

	What? Shaney?

-am	� 2003

Re: [9fans] Re: Free Plan 9 "shell" accounts?

[boyd, rounin]

> What? Shaney?

nah, the operating system :)

Re: [9fans] Re: Free Plan 9 "shell" accounts?

[Anthony Mandic]

"boyd, rounin" wrote:
>
> > What? Shaney?
>
> nah, the operating system :)

	Pity.

-am	� 2003

Re: [9fans] Re: Free Plan 9 "shell" accounts?

[boyd, rounin]

 > Pity.

it was deliberately ambiguous ...

Re: [9fans] Re: Free Plan 9 "shell" accounts?

[Anthony Mandic]

"boyd, rounin" wrote:
>
>  > Pity.
>
> it was deliberately ambiguous ...

	I know but I was kind of hoping Mark would pop his head in
	on this silly thread. Maybe, if we ask nicely, brucee will
	have a word with him.

-am	� 2003

Re: [9fans] Re: Free Plan 9 "shell" accounts?

[boyd, rounin]

> I know but I was kind of hoping Mark would pop his head in
> on this silly thread. Maybe, if we ask nicely, brucee will
> have a word with him.

for the record, it was my idea.  after reading net.singles and
hearing of this markov chain text generator i said, well let's
snarf up some text, feed it into the markov chain, create
a persona and post it straight back at them.  this small detail
seemed to have been forgotten when it got written up in the
Scientific American.

the implementation (iirc), of said idea, was brucee and rob.

Re: [9fans] Re: Free Plan 9 "shell" accounts?

[rob pike, esq.]

> the implementation (iirc), of said idea, was brucee and rob.

Don P.  Mitchell had the markov program that inspired whoever had the
original idea.  The code we used was rewritten by brucee.  I believe I
wrote the shell script wrapper and, with brucee, created the account,
mail box, etc.  Brucee did most of the daily management of MVS's wit.

-rob

Re: [9fans] Re: Free Plan 9 "shell" accounts?

[Skip Tavakkolian]

> Don P.  Mitchell had the markov program that inspired whoever had the
> original idea.  The code we used was rewritten by brucee.  I believe I
> wrote the shell script wrapper and, with brucee, created the account,
> mail box, etc.  Brucee did most of the daily management of MVS's wit.

A reprint of the SA article is in "The Magic Machine" book by Dewdney.
In it, Dewdney says "Readers may also be interested in what is perhaps
Mark V.  Shaney's magnum opus: a 20-page commentary on the
deconstructionist philosophy of Jean Boudrillard".  I found a link to
an old email by rob.  MVS's dissertation sounds remarkably like some of
the recent discussions on 9fans.  Now I see how we ended up here.

http://www.evolutionzone.com/kulturezone/c-g.writing/cgw.baudrillard.txt

Re: [9fans] Re: Free Plan 9 "shell" accounts?

[boyd, rounin]

> Don P.  Mitchell had the markov program that inspired whoever had the
> original idea.  The code we used was rewritten by brucee.  I believe I
> wrote the shell script wrapper and, with brucee, created the account,
> mail box, etc.  Brucee did most of the daily management of MVS's wit.

yup

[9fans] Re: Free Plan 9 "shell" accounts?

[Jim Choate]

On Mon, 19 May 2003, rob pike, esq. wrote:

> > the implementation (iirc), of said idea, was brucee and rob.
>
> Don P.  Mitchell had the markov program that inspired whoever had the
> original idea.  The code we used was rewritten by brucee.  I believe I
> wrote the shell script wrapper and, with brucee, created the account,
> mail box, etc.  Brucee did most of the daily management of MVS's wit.

While you guys are dropping names...

If you run across any of the AmSci guys, especially Shawn, please say "Hi,
from the Tesla folks. We're still building the lenses".


 --
    ____________________________________________________________________

      We are all interested in the future for that is where you and I
      are going to spend the rest of our lives.

                              Criswell, "Plan 9 from Outer Space"

      ravage@ssz.com                            jchoate@open-forge.org
      www.ssz.com                               www.open-forge.org
    --------------------------------------------------------------------

Re: [9fans] Re: Free Plan 9 "shell" accounts?

[Anthony Mandic]

"rob pike, esq." wrote:
>
> > the implementation (iirc), of said idea, was brucee and rob.
>
> Don P.  Mitchell had the markov program that inspired whoever had the
> original idea.  The code we used was rewritten by brucee.  I believe I
> wrote the shell script wrapper and, with brucee, created the account,
> mail box, etc.  Brucee did most of the daily management of MVS's wit.

	I wonder if he could run riot in slash dot?

-am	� 2003

Re: [9fans] Re: Free Plan 9 "shell" accounts?

[matt]

>
>
>
>	I wonder if he could run riot in slash dot?
>
>

Markov has posted enough auto-trolls already thanks

Re: [9fans] Re: Free Plan 9 "shell" accounts?

[boyd, rounin]

> I wonder if he could run riot in slash dot?

slash dot is a riot [LOL]

Re: [9fans] Re: Free Plan 9 "shell" accounts?

[matt]

>
>
>I see what you're saying, but I think you missed my point.  It might
>help if you reviewed a book on operating systems basics; it's pretty
>clear you don't have much of a formal background here.  I can recommend
>a titles, if you'd like.
>
>

can you recommend them anyway 8)

and anyone else while we're on the subject

I can't find any decent books at my local bookstores that I can buy and
read for the sake of it i.e. not for reference

the only book on my current list is "Life With Qmail" and that doesn't
sound too exciting

m

Re: [9fans] Re: Free Plan 9 "shell" accounts?

[Dan Cross]

> >I see what you're saying, but I think you missed my point.  It might
> >help if you reviewed a book on operating systems basics; it's pretty
> >clear you don't have much of a formal background here.  I can recommend
> >a titles, if you'd like.
>
> can you recommend them anyway 8)

Sure.  I think the new edition of Tanenbaum's, ``Modern Operating
Systems'' is quite good, as is Avi Silberschatz's, ``Operating Systems
Concepts,'' now in it's 6th Edition.  Silberschwatz also has a another
book, in it's first edition: ``Applied Operating System Concepts'' that
is similar in nature to his earlier book, but targeted to a slightly
different audience.  It's my impression that the former concentrates a
little more on theory, while the latter talks about applications of
that theory.  Either is probably fine if you don't have a lot of
background in OS's.

Also, there are at least two books that talk about operating system
implementation in great detail: Tanenbaum's, ``Operating Systems:
Design and Implementation,'' in it's second edition, and John Lions's,
``Lions' Commentary on Unix 6th Edition, with Source Code.''  The
former is the famous (infamous?) Minix book; the latter is the infamous
(famous?) Lions' Papers, which go through the Unix kernel line by
line.  Both of these books provide great insight into operating system
internals.  The Lions book is obviously dated; Tanenbaum updated the
Minix book a few years ago.

Of course, Nemo's tome on the Plan 9 kernel will give you a lot of
insight into Plan 9, in a manner similar to how Lions' papers gave
one insight into Unix.

Those will get people started.  After that, there are a few other
decent books, but it's probably more fruitful to go directly to the
research literature.

> and anyone else while we're on the subject
>
> I can't find any decent books at my local bookstores that I can buy and
> read for the sake of it i.e. not for reference
>
> the only book on my current list is "Life With Qmail" and that doesn't
> sound too exciting

Well, I recommend, ``A Farewell to Arms'' and ``Of Mice and Men,'' two
of my favorite books.  Also, ``We'', if you can get a hold of one of
the modern translations is a fantastic read (a pre-cursor to the
prototypical Orwellian novel).  If you mean computer books....  Don't
ask me; computer books put me to sleep.

	- Dan C.

(Though I have managed to get through, ``The Elements of Programming
Style,'' ``The Practice of Programming,'' ``Programming Pearls,''
``The Pragmatic Programmer,'' and a few others.  The first three I
recommend to anyone serious about programming computers.)

Re: [9fans] Re: Free Plan 9 "shell" accounts?

[northern snowfall]

>
>
>Well, I recommend, ``A Farewell to Arms'' and ``Of Mice and Men,'' two
>of my favorite books.  Also, ``We'', if you can get a hold of one of
>the modern translations is a fantastic read (a pre-cursor to the
>prototypical Orwellian novel).  If you mean computer books....  Don't
>ask me; computer books put me to sleep.
>
I recommend anything from Agatha Christie. Especially from the
Poirot mysteries. I just can't get enough of that dame :)
Don

>

Re: [9fans] Re: Free Plan 9 "shell" accounts?

[boyd, rounin]

err, Novel With Cocaine?

    Bush "Still Likes Tasty Things"
    While President Bush was in Russia, he enjoyed some candy.
    This report also claims that "before coming to Russia Bush read
    Dostoyevsky's novel Crime and Punishment in order to get a better
    understanding of the Russian soul." I would have recommended he
    read M. Agayev's Novel with Cocaine instead.

    http://www.boss-tweed.com/2002_05_01_archives.html#77055291

Re: Reading lists (was: [9fans] Re: Free Plan 9 "shell" accounts?)

[Dan Cross]

While we're on the subject of reading lists, I don't normally talk
about things like this, but I know Boyd will appreciate the following
book.  If you haven't read it, can find a copy, and are interested in
such things, I highly recommend ``The Walking Dead: A Marine's Story of
Vietnam.''  It's one of the most accurate descriptions of what it's
like to be a Marine that I've ever read.  S/f,

	- Dan C.

Re: Reading lists (was: [9fans] Re: Free Plan 9 "shell" accounts?)

[boyd, rounin]

i see your ``The Walking Dead: A Marine's Story of Vietnam.''
and raise you "The Scars of War" written by an ex SBS guy,
not those sissies in the SAS.

    Hugh McManners, The Scars of War (London: Harper Collins, 1994).

truly superb.

Re: [9fans] Re: Free Plan 9 "shell" accounts?

[George Bronnikov]

It's `A Love Affair With Cocaine' (same word in Russian - "roman").
A fine book, really.  The translator must have been a moron.

Sorry for OT.

	goga

On Sun, 18 May 2003, boyd, rounin wrote:

> err, Novel With Cocaine?
>
>     Bush "Still Likes Tasty Things"
>     While President Bush was in Russia, he enjoyed some candy.
>     This report also claims that "before coming to Russia Bush read
>     Dostoyevsky's novel Crime and Punishment in order to get a better
>     understanding of the Russian soul." I would have recommended he
>     read M. Agayev's Novel with Cocaine instead.
>
>     http://www.boss-tweed.com/2002_05_01_archives.html#77055291
>

Re: [9fans] Re: Free Plan 9 "shell" accounts?

[boyd, rounin]

From: "George Bronnikov" <goga@bronnikov.mccme.ru>
> It's `A Love Affair With Cocaine' (same word in Russian - "roman").
> A fine book, really.  The translator must have been a moron.

roman -- same word in french.

i read the english translation.

Re: [9fans] Re: Free Plan 9 "shell" accounts?

[Joel Salomon]

> Of course, Nemo's tome on the Plan 9 kernel will give you a lot of
> insight into Plan 9, in a manner similar to how Lions' papers gave
> one insight into Unix.
Speaking of which, is there a newer version out? The version I have is
Notes on the Plan 9 tm 3rd edition Kernel Source
January 8, 2001

I don't mean to pressure anyone, just a friendly inquiry.
--Joel

Re: [9fans] Re: Free Plan 9 "shell" accounts?

[Fco.J.Ballesteros]

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

Nope. Sorry. I didnt get the time to update it.
You probably have the last version. If any update it, I'll let 9fans
know, so dont worry.

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

From: Joel Salomon <salomo3@cooper.edu>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] Re: Free Plan 9 "shell" accounts?
Date: Mon, 19 May 2003 09:06:47 -0400 (EDT)
Message-ID: <Pine.SOL.3.96.1030519085933.9437A-100000@robin.cooper.edu>

> Of course, Nemo's tome on the Plan 9 kernel will give you a lot of
> insight into Plan 9, in a manner similar to how Lions' papers gave
> one insight into Unix.
Speaking of which, is there a newer version out? The version I have is
Notes on the Plan 9 tm 3rd edition Kernel Source
January 8, 2001

I don't mean to pressure anyone, just a friendly inquiry.
--Joel

Re: [9fans] Re: Free Plan 9 "shell" accounts?

[Jim Choate]

On Sun, 18 May 2003, matt wrote:

> >I see what you're saying, but I think you missed my point.  It might
> >help if you reviewed a book on operating systems basics; it's pretty
> >clear you don't have much of a formal background here.  I can recommend
> >a titles, if you'd like.

> can you recommend them anyway 8)
>
> and anyone else while we're on the subject
>
> I can't find any decent books at my local bookstores that I can buy and
> read for the sake of it i.e. not for reference

I keep a list of suggested reading, it's been transfered over to the
Hangar 18 site, it does need a little editing:

http://einstein.ssz.com/hangar18/links.html

I'm very fond of Silberschatz myself (ie Dinosaur Book).


 --
    ____________________________________________________________________

      We are all interested in the future for that is where you and I
      are going to spend the rest of our lives.

                              Criswell, "Plan 9 from Outer Space"

      ravage@ssz.com                            jchoate@open-forge.org
      www.ssz.com                               www.open-forge.org
    --------------------------------------------------------------------

Re: [9fans] Re: Free Plan 9 "shell" accounts?

[boyd, rounin]

> "Life With Qmail"

oxymoron

Re: [9fans] Re: Free Plan 9 "shell" accounts?

[Andrew]

On Sun, May 18, 2003 at 09:21:07PM +0200, boyd, rounin wrote:
> > "Life With Qmail"
>
> oxymoron
>
maybe Im going to look stupid for asking this, but whats wrong with
qmail? Sure its a unix tool, and djb isnt always the nicest guy in the
world, but it seems to work pretty darn well, compared with
say...sendmail.

Re: [9fans] Re: Free Plan 9 "shell" accounts?

[boyd, rounin]

> maybe Im going to look stupid for asking this, but whats wrong with
> qmail?

4 chars ... SMTP -- Simple Mail Transfer Protocol

no files, no 8 bit chars, nothing but 7 bit ASCII.

then we get the 150 pages of the 4 MINE (sic) rfcs and we
know who the guilty are and why and it is no longer SIMPLE.

POP ... Post Office Protocol -- simple

IMAP ... DISASTER, it tries to be a file server but it's only dealing with mail.

FTP ... File Transfer Protocol

QED

Re: [9fans] Re: Free Plan 9 "shell" accounts?

[boyd, rounin]

call me a luddite and i'll be off straight to hell with dan and we'll be smiling
...

Re: [9fans] Re: Free Plan 9 "shell" accounts?

[Andrew]

well, thats email in general, as Dan said, qmail is fine, modulo a
few issues. but you're absolutly right, email is a disaster...i read
rfc821 (or was it 822) the other day...all i have to say is: wtf!?

although i dont think qmail itself is bad, its fast (regardless of the
multiple tcp delivery thing), its secure (theres an idea!), and its
pretty simple no bells and whistles and not much bloat, theres not much
more one could ask for given the underlying circumstances.

thanks for the input though ;)


Andrew

On Sun, May 18, 2003 at 09:35:21PM +0200, boyd, rounin wrote:
> > maybe Im going to look stupid for asking this, but whats wrong with
> > qmail?
>
> 4 chars ... SMTP -- Simple Mail Transfer Protocol
>
> no files, no 8 bit chars, nothing but 7 bit ASCII.
>
> then we get the 150 pages of the 4 MINE (sic) rfcs and we
> know who the guilty are and why and it is no longer SIMPLE.
>
> POP ... Post Office Protocol -- simple
>
> IMAP ... DISASTER, it tries to be a file server but it's only dealing with mail.
>
> FTP ... File Transfer Protocol
>
> QED
>

Re: [9fans] Re: Free Plan 9 "shell" accounts?

[boyd, rounin]

> rfc821 (or was it 822) the other day...all i have to say is: wtf!?

822 ... an 'interesting' read ...

Re: [9fans] Re: Free Plan 9 "shell" accounts?

[boyd, rounin]

> rfc821 (or was it 822) the other day...all i have to say is: wtf!?

would you like the yacc address parser?

Re: [9fans] Re: Free Plan 9 "shell" accounts?

[Dan Cross]

> > rfc821 (or was it 822) the other day...all i have to say is: wtf!?
>
> would you like the yacc address parser?

Can yacc even handle 822?  I didn't think the subset of the grammar
for the Received: headers was in LALR(1).

	- Dan C.

Re: [9fans] Re: Free Plan 9 "shell" accounts?

[boyd, rounin]

> Can yacc even handle 822?

yes and no.  the addresses yes, but the Received: headers are a context
sensitive grammar -- a nasty piece of work, but i have a plan;  no more
passive anti-spam -- it's time for active anti-spam.  code it in limbo
and complain to the sender and all the hosts it passed through.

that should shut 'em down :)

it's tricky, but with limbo it can't be _that_ hard -- err, oops, i just forgot
i'm one of those roswell conspiritors ...

btw: repo is crudely re-hosted and when i sam it into shape i'll update
the wiki, as is insultant.net

Re: [9fans] Re: Free Plan 9 "shell" accounts?

[Scott Schwartz]

Boyd writes:
| passive anti-spam -- it's time for active anti-spam.  code it in limbo
| and complain to the sender and all the hosts it passed through.

Be careful---standard spammer practice is to put forged Received lines
on the junk they send.  Same deal with From and envelope sender.

Re: [9fans] Re: Free Plan 9 "shell" accounts?

[boyd, rounin]

> Be careful---standard spammer practice is to put forged Received lines
> on the junk they send.  Same deal with From and envelope sender.

nope, dws killed a lotta spammers back in '96/'97 and it was low tech:

    http://www.insultant.net/fr.inter.net/code/dws.html

an rc script in fact.

Re: [9fans] Re: Free Plan 9 "shell" accounts?

[boyd, rounin]

> Be careful---standard spammer practice is to put forged Received lines
> on the junk they send.  Same deal with From and envelope sender.

anyway, complaining to forged lines will just get the spammer into more grief,
not less.

Re: [9fans] Re: Free Plan 9 "shell" accounts?

[Scott Schwartz]

| anyway, complaining to forged lines will just get the spammer into more grief,
| not less.

On the contrary.  Spammers have put my address on forged headers, and the
double bounces and direct complaints that I got did absolutely nothing
at all to discommode the spammers.  Please don't also add forged Received
lines to the collatoral damage problem.

Re: [9fans] Re: Free Plan 9 "shell" accounts?

[Adrian Tritschler]

Scott Schwartz wrote:

> | anyway, complaining to forged lines will just get the spammer into more grief,
> | not less.
>
> On the contrary.  Spammers have put my address on forged headers, and the
> double bounces and direct complaints that I got did absolutely nothing
> at all to discommode the spammers.  Please don't also add forged Received
> lines to the collatoral damage problem.

Definitely.

We've just spent most of the morning dealing with W32/Palyh-a [1].  It arrives
in mail that purports to come from support@microsoft.com  Klez was more fun,
it picked random addresses from people's Micorsoft Outbreak address book to
create its own to and from addresses.

Amazing how many people _still_ run attachments that come in the mail.  I
wonder if I put a bottle on the ground labelled "drink me"...

	Adrian

[1] http://www.sophos.com/virusinfo/analyses/w32palyha.html

---------------------------------------------------------------
Adrian Tritschler    mailto:Adrian.Tritschler@its.monash.edu.au
Latitude 38�S, Longitude 145�E, Altitude 50m,      Shoe size 44
---------------------------------------------------------------

Re: [9fans] Re: Free Plan 9 "shell" accounts?

[Jason Gurtz]

Adrian Tritschler wrote:

> We've just spent most of the morning dealing with W32/Palyh-a [1].

May MIMEDefang come to your rescue.  It's let me sleep at night in these
troubled times.

~Jason

--

Re: [9fans] Re: Free Plan 9 "shell" accounts?

[boyd, rounin]

> May MIMEDefang come to your rescue.  It's let me sleep at night in these

the really stupid thing about the MINE (sic) field is that you can parse it
with awk -- it looks recursive, but it's just linear, with some context.

i had to do it once for a security audit, for the rat squad ...

Re: [9fans] Re: Free Plan 9 "shell" accounts?

[northern snowfall]

>
>
>anyway, complaining to forged lines will just get the spammer into more grief,
>not less.
>
How will that work if noone knows the real sender and virii bots
are sending the messages. If you can't prove who is behind the
email, there is noone to legally target. Even if you can prove
a party probably sent a given spam, you still have the burden
of proving they were at the console that sent the original
message. That can't be done with the net bot movements and
other, older, forms of spamming.
Don

>

Re: [9fans] Re: Free Plan 9 "shell" accounts?

[boyd, rounin]

ok, i admit -- i know nothing about active spam killing.

end of discussion.

Re: [9fans] Re: Free Plan 9 "shell" accounts?

[boyd, rounin]

> Can yacc even handle 822?

i've found a version, but it's a little large to post to the list.

i could hang it off insultant.net and post the URL.

[9fans] RFC822 & yacc

[boyd, rounin]

it's at:

    http://www.insultant.net/repo/822yacc.txt

Re: [9fans] Re: Free Plan 9 "shell" accounts?

[Dan Cross]

> > oxymoron
>
> maybe Im going to look stupid for asking this, but whats wrong with
> qmail? Sure its a unix tool, and djb isnt always the nicest guy in the
> world, but it seems to work pretty darn well, compared with
> say...sendmail.

Qmail is okay.  The biggest single problem with it is that DJB is
firmly convinced that the thing to do is avoid latency, because SMTP is
slow.  So, he opens up many TCP connections to a single remote server
at once.  The result is that the remote server can get severely
overloaded, which makes it defer delivery.  You end up with this
happening in a slowly attenuating cycle, which can actually increase
latency.  Maybe this has been fixed with a qmail patch; I don't know.

Postfix solves this problem by using a slow-start style algorithm to
find the point at which it's transfering the most mail to a remote site
in parallel, without overloading it.  You trade a little bit of
increased latency at the beginning for greater efficiency overall.  But
Postfix is getting kind of big and bloated, itself.  :-(

	- Dan C.

Re: [9fans] Re: Free Plan 9 "shell" accounts?

[boyd, rounin]

> The biggest single problem with it is that DJB

QED

SMTP stuff. Was: Re: [9fans] Re: Free Plan 9 "shell" accounts?

[Aharon Robbins]

Perhaps a bit off topic, but ... since SMTP came up, if anyone's interested,

	http://www.skeeve.com/sendout3.ps.gz

is the postscript for a small program I wrote (four years ago) using
Gawk and its sockets.  It reads a Unix-style mbox file and sends the
contained messages to an SMTP server for delivery.  I wrote it when my
network connectivity was somewhat more primitive than now.

It's not a sendmail/qmail/postfix replacement by any means, but it may
provide some amusement.

(It's a .ps file since I used literate programming (noweb + latex) to
write the code.)

Enjoy,

Arnold
--
Aharon (Arnold) Robbins --- Pioneer Consulting Ltd.	arnold@skeeve.com
P.O. Box 354		Home Phone: +972  8 979-0381	Fax: +1 928 569 9018
Nof Ayalon		Cell Phone: +972 51  297-545
D.N. Shimshon 99785	ISRAEL

Re: SMTP stuff. Was: Re: [9fans] Re: Free Plan 9 "shell" accounts?

[matt]

I'm particularly interested as that was a solution I was looking for at
that very moment

Now I'm solving the "how to get the .awk out of the .ps" problem instead

I'm not sure if that wouldn't even be a DMCA violation !


>Perhaps a bit off topic, but ... since SMTP came up, if anyone's interested,
>
>	http://www.skeeve.com/sendout3.ps.gz
>
>is the postscript for a small program I wrote (four years ago) using
>Gawk and its sockets.  It reads a Unix-style mbox file and sends the
>contained messages to an SMTP server for delivery.  I wrote it when my
>network connectivity was somewhat more primitive than now.
>
>It's not a sendmail/qmail/postfix replacement by any means, but it may
>provide some amusement.
>
>(It's a .ps file since I used literate programming (noweb + latex) to
>write the code.)
>
>Enjoy,
>
>Arnold
>
>

Re: SMTP stuff. Was: Re: [9fans] Re: Free Plan 9 "shell" accounts?

[boyd, rounin]

> Perhaps a bit off topic, but ... since SMTP came up, if anyone's interested,
>
> http://www.skeeve.com/sendout3.ps.gz
>

does it grok groups?

Re: [9fans] Re: Free Plan 9 "shell" accounts?

[boyd, rounin]

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

limbo meets POP ...

[-- Attachment #2.1: Type: text/plain, Size: 341 bytes --]

The following attachment had content that we can't
prove to be harmless.  To avoid possible automatic
execution, we changed the content headers.
The original header was:

	Content-Type: application/octet-stream;
	name="pop.bundle"
	Content-Transfer-Encoding: quoted-printable
	Content-Disposition: attachment;
	filename="pop.bundle"

[-- Attachment #2.2: pop.bundle.suspect --]
[-- Type: application/octet-stream, Size: 6702 bytes --]

# To unbundle, run this file
echo pop.b
sed 's/.//' >pop.b <<'//GO.SYSIN DD pop.b'
-# (C) Copyright Boyd Roberts, Bruce Ellis, November 1998
-
-implement Pop;
-
-include	"sys.m";
-include	"bufio.m";
-include	"string.m";
-include	"pop.m";
-
-sys:	Sys;
-bufio:	Bufio;
-str:	String;
-
-Iobuf:	import bufio;
-
-stderr:	ref Sys->FD;
-rx, tx:	ref Iobuf;
-
-debug:	con 0;
-
-init(): string
-{
-	sys = load Sys Sys->PATH;
-	if (sys == nil)
-		return "load $Sys failed";
-	stderr = sys->fildes(2);
-	bufio = load Bufio Bufio->PATH;
-	if (bufio == nil)
-		return sys->sprint("could not load %s: %r", Bufio->PATH);
-	str = load String String->PATH;
-	if (str == nil)
-		return sys->sprint("could not load %s: %r", String->PATH);
-	return nil;
-}
-
-fetch(user, host, password, dir: string, del: int): (string, big)
-{
-	dest := sys->sprint("tcp!%s!%d", host, Pop->POP3);
-	(ok, C) := sys->dial(dest, nil);
-	if (ok < 0)
-		return (sys->sprint("dial '%s' failed: %r", dest), big 0);
-
-	rx = bufio->fopen(C.dfd, Sys->OREAD);
-	if (rx == nil)
-		return (sys->sprint("bufio read open '%s' failed: %r", dest), big 0);
-	tx = bufio->fopen(C.dfd, Sys->OWRITE);
-	if (tx == nil)
-		return (sys->sprint("bufio write open '%s' failed: %r", dest), big 0);
-
-	(e, s) := reply(0);
-	case e {
-	ERR =>
-		return(s, big 0);
-	OK =>
-		if (debug)
-			sys->print("%s\n", s);
-	}
-	
-	(e, s) = request(CMD_USER, user);
-	case e {
-	ERR =>
-		return(s, big 0);
-	OK =>
-		if (debug)
-			sys->print("%s\n", s);
-	}
-
-	(e, s) = request(CMD_PASS, password);
-	case e {
-	ERR =>
-		return(s, big 0);
-	OK =>
-		if (debug)
-			sys->print("%s\n", s);
-	}
-
-	(e, s) = request(CMD_STAT, nil);
-	case e {
-	ERR =>
-		return(s, big 0);
-	OK =>
-		if (debug)
-			sys->print("%s\n", s);
-	}
-
-	messages := big 0;
-	size := big 0;
-	(n, l) := sys->tokenize(s, " ");
-	case n {
-	1 =>
-		sys->print("%d message%s for '%s@%s', maildrop size unknown.\n", int messages, plural(messages), user, host);
-		messages = big hd l;
-
-	2 =>
-		messages = big hd l;
-		size = big hd tl l;
-
-	* =>
-		return (sys->sprint("unknown number of messages for '%s@%s'.\n", user, host), big 0);
-	}
-
-	fetched: list of string;
-	err := "";
-getem:
-	for (i := big 1; i <= messages; i++) {
-		(e, s) = request(CMD_RETR, string i);
-		case e {
-		ERR =>
-			return(s, big 0);
-		OK =>
-			if (debug)
-				sys->print("%s\n", s);
-		}
-		f := filename(dir, string i);
-		fd := sys->create(f, Sys->OWRITE, 0);
-		if (fd == nil) {
-			err = sys->sprint("could not create '%s'", f);
-			break;
-		}
-
-		for (;;) {
-			(e, s) = reply(1);
-			case e {
-			ERR =>
-				err = s;
-				break getem;
-			DATA =>
-				if (debug)
-					sys->print("%s\n", s);
-				if (sys->fprint(fd, "%s\n", s) < 0) {
-					err = sys->sprint("could not write '%s': %r", f);
-					sys->remove(f);
-					break getem;
-				}
-
-			END =>
-				s = readable(f, fd);
-				if (s != nil)
-					sys->fprint(stderr, "warning: %s\n", s);
-				fd = nil;
-				fetched = string i :: fetched;
-				continue getem;
-			}
-		}
-	}
-
-	messages = big 0;
-
-	if (del)
-	{
-		while (fetched != nil)
-		{
-			s = hd fetched;
-			fetched = tl fetched;
-	
-			(e, s) = request(CMD_DELE, s);
-			case e {
-			ERR =>
-				sys->remove(filename(dir, s));
-			OK =>
-				messages++;
-			}
-		}
-	}
-
-	(e, s) = request(CMD_QUIT, nil);
-	if (e != OK && err == nil) {
-		if (messages != big 0)
-			err = sys->sprint("%bd message%s: ", messages, plural(messages));
-		err = sys->sprint("%swarning: %s", err, s);
-	}
-
-	return (err, messages);
-}
-
-reply(data: int): (int, string)
-{
-	r := rx.gets('\n');
-	if (r == nil)
-		return (ERR, sys->sprint("pop server read failed: %r"));
-	(n, l) := sys->tokenize(r, "\r\n");
-	if (n != 1) {
-		if (n == 0 && data)
-			return (DATA, nil);
-		return (ERR, "reply missing CRLF");
-	}
-	line := hd l;
-	if (debug)
-		sys->print("<-- %s\n", line);
-
-	if (data) {
-		if (line == REP_TCHAR)
-			return (END, nil);
-		return (DATA, line);
-	}
-
-	(cmd, rest) := str->splitl(line, " ");
-	rest = rest[1:];
-	case cmd {
-	REP_OK =>
-		return (OK, rest);
-	REP_ERR =>
-		return (ERR, rest);
-	* =>
-		return (ERR, "protocol error");
-	}
-}
-
-request(cmd, arg: string): (int, string)
-{
-	s := cmd;
-	if (arg != nil)
-		s += " " + arg;
-	if (debug)
-		sys->print("--> %s\n", s);
-	if (tx.puts(s + "\r\n") < 0 || tx.flush() < 0)
-		return (ERR, sys->sprint("pop server write failed: %r"));
-	return reply(0);
-}
-
-plural(n: big): string
-{
-	if (n == big 1)
-		return nil;
-
-	return "s";
-}
-
-readable(f: string, fd: ref Sys->FD): string
-{
-	(ok, d) := sys->fstat(fd);
-	if (ok < 0)
-		return sys->sprint("could not fstat '%s': %r", f);
-
-	d.mode |= 8r600;
-	if (sys->wstat(f, d) < 0)
-		return sys->sprint("could not wstat '%s': %r", f);
-
-	return nil;
-}
-
-filename(dir, file: string): string
-{
-	return dir + "/" + file;
-}
//GO.SYSIN DD pop.b
echo pop.m
sed 's/.//' >pop.m <<'//GO.SYSIN DD pop.m'
-# (C) Copyright Boyd Roberts, Bruce Ellis, November 1998
-
-Pop: module
-{
-	PATH:		con "pop.dis";
-	POP3:		con 110;
-	OK:		con 0;
-	END:		con 1;
-	DATA:		con 2;
-	ERR:		con -1;
-
-	CMD_DELE:	con "DELE";
-	CMD_LAST:	con "LAST";
-	CMD_NOOP:	con "NOOP";
-	CMD_PASS:	con "PASS";
-	CMD_QUIT:	con "QUIT";
-	CMD_RETR:	con "RETR";
-	CMD_RSET:	con "RSET";
-	CMD_STAT:	con "STAT";
-	CMD_USER:	con "USER";
-
-	REP_OK:		con "+OK";
-	REP_ERR:	con "-ERR";
-	REP_TCHAR:	con ".";
-
-	init:		fn(): string;
-	fetch:		fn(user, host, password, dir: string, del: int): (string, big);
-	plural:		fn(n: big): string;
-};
//GO.SYSIN DD pop.m
echo test.b
sed 's/.//' >test.b <<'//GO.SYSIN DD test.b'
-# (C) Copyright Boyd Roberts, Bruce Ellis, November 1998
-
-implement Test;
-
-include	"sys.m";
-include	"draw.m";
-include	"pop.m";
-
-sys:	Sys;
-pop:	Pop;
-
-stderr:	ref Sys->FD;
-
-Test: module
-{
-	init:	fn(nil: ref Draw->Context, nil: list of string);
-};
-
-init(nil: ref Draw->Context, nil: list of string)
-{
-	sys = load Sys Sys->PATH;
-	stderr = sys->fildes(2);
-	pop = load Pop Pop->PATH;
-	if (pop == nil)
-		exits(sys->sprint("could not load %s: %r\n", Pop->PATH));
-	s := pop->init();
-	if (s != nil)
-		exits(s);
-	n: big;
-	(s, n) = pop->fetch("user", "host", "password", ".", 0);
-	if (s != nil)
-		exits(s);
-	if (n != big 0)
-		sys->print("%bd message%s\n", n, pop->plural(n));
-}
-
-exits(s: string)
-{
-	sys->raise("fail: " + s);
-}
//GO.SYSIN DD test.b

Re: [9fans] Re: Free Plan 9 "shell" accounts?

[boyd, rounin]

> I know I shouldn't get into this....

yeah, real warren commission stuff :(

[9fans] same functions everywhere

[paurea]

Reading the code for different commands and filesystems, I have found
there are at least three functions repeated with equivalent
implementations all over the place. These are erealloc emalloc and estrdup.
They call the function without the e and call sysfatal on error. Wouldn't it
be more economical and clear to have them on a library?.

On another terms, it would be great to have some function, macro, mechanism
or whatever to describe calling a function and calling sysfatal on error, because
this usage of functions repeats itself a lot.



									Gorka

Re: [9fans] same functions everywhere

[Russ Cox]

> Reading the code for different commands and filesystems, I have found
> there are at least three functions repeated with equivalent
> implementations all over the place. These are erealloc emalloc and estrdup.
> They call the function without the e and call sysfatal on error. Wouldn't it
> be more economical and clear to have them on a library?.

I almost did this but was talked out of it.
The problem is that if they are in the library
then it encourages other libraries to use
them, and then we end up with a C library
in which it is impossible to correctly handle
an out-of-memory error.

The decision to abort is best left up to the
application.

Re: [9fans] same functions everywhere

[paurea]

> The problem is that if they are in the library
> then it encourages other libraries to use
> them, and then we end up with a C library
> in which it is impossible to correctly handle
> an out-of-memory error.

I see the point, but can't swallow they have to be reimplemented so
many times.

>
> The decision to abort is best left up to the
> application.

I agree that the decision is best left up to the application, but
having to rewrite or copy the implementation of the funtcions
everywhere shouldn't be necessary.  I feel this is not the Right thing
to do.  The only alternatives I can think of are ugly patches, so if
you have any idea...


							Gorka
ゴルカ

Re: [9fans] same functions everywhere

[Fco.J.Ballesteros]

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

An intermediate way would be to add another library with
common tools like those ones. But maybe we end up with too many
libraries then...

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

From: paurea@plan9.escet.urjc.es
To: 9fans@cse.psu.edu
Subject: Re: [9fans] same functions everywhere
Date: Wed, 23 Apr 2003 17:29:08 +0200
Message-ID: <e40276308b5dbec193161e2129556275@plan9.escet.urjc.es>

> The problem is that if they are in the library
> then it encourages other libraries to use
> them, and then we end up with a C library
> in which it is impossible to correctly handle
> an out-of-memory error.

I see the point, but can't swallow they have to be reimplemented so
many times.

>
> The decision to abort is best left up to the
> application.

I agree that the decision is best left up to the application, but
having to rewrite or copy the implementation of the funtcions
everywhere shouldn't be necessary.  I feel this is not the Right thing
to do.  The only alternatives I can think of are ugly patches, so if
you have any idea...


							Gorka
ゴルカ

Re: [9fans] same functions everywhere

[rob pike, esq.]

> An intermediate way would be to add another library with
> common tools like those ones. But maybe we end up with too many
> libraries then...

This doesn't really address the objection unless you also require that
other libraries not use this one, which seems bizarre.

The argument I think carries the day is that error handling is an
application-specific issue, not a library issue.  I have written emalloc
several times but each application tends to do something different
in the error case.  That is the real point.

-rob

Re: [9fans] same functions everywhere

[paurea]

> The argument I think carries the day is that error handling is an
> application-specific issue, not a library issue.  I have written emalloc
> several times but each application tends to do something different
> in the error case.  That is the real point.
>


Most of them do exactly the same, calling sysfatal.  The only
different thing is the error string and sometimes, it is just "out of
memory" or variations on this.



							Gorka

Re: [9fans] same functions everywhere

[Charles Forsyth]

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

sam and acme, for instance, have a good attempt at
saving work-in-progress, and arguably a few others should too.

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

From: paurea@plan9.escet.urjc.es
To: 9fans@cse.psu.edu
Subject: Re: [9fans] same functions everywhere
Date: Thu, 24 Apr 2003 14:02:58 +0200
Message-ID: <5258fb01cfa482d7b8d985e1c26dfac1@plan9.escet.urjc.es>


> The argument I think carries the day is that error handling is an
> application-specific issue, not a library issue.  I have written emalloc
> several times but each application tends to do something different
> in the error case.  That is the real point.
>


Most of them do exactly the same, calling sysfatal.  The only
different thing is the error string and sometimes, it is just "out of
memory" or variations on this.



							Gorka

Re: [9fans] same functions everywhere

[Sam]

>
> Most of them do exactly the same, calling sysfatal.  The only
> different thing is the error string and sometimes, it is just "out of
> memory" or variations on this.
>

Is the argument purely about ambiguity?  I don't see anything
about the name emalloc(...) that indicates it will take the program
down.  This is less of an issue in a program context as the scope
is generally tighter (and the programmer wrote it).

Perhaps if the name were changed to fatalmalloc and you could
pass in a string for sysfatal it would be less ambiguous.  It
just seems like a moot point for 6 lines of code.

If you want to pick on malloc, why not lambast mallocz for having
the second parameter to qualify the zero'ing?  Its primary use
is for dynamically discerning whether to zero out the associated
memory, and in

grep '[^e]mallocz' `{du -a /sys/src | awk '{print $2}' | grep '\.c$'}
| wc -l
    149

149 uses there isn't one call that does this.

Sam

Re: [9fans] same functions everywhere

[Sam]

>
> grep '[^e]mallocz' `{du -a /sys/src | awk '{print $2}' | grep '\.c$'}
> | wc -l
>     149

My apologies, this should read:

grep '[^e]mallocz(.*,.*)' `{du -a /sys/src | awk '{print $2}' | grep
'\.c$'} | wc -l
	149

or else you pick up the mallocz versions redefined by others who
have elided the second argument.  The number is still correct - I
flub'd transcribing.

Sam

Re: [9fans] same functions everywhere

[Boyd Roberts]

----- Original Message -----
From: <paurea@plan9.escet.urjc.es>
> Most of them do exactly the same, calling sysfatal.  The only
> different thing is the error string and sometimes, it is just "out of
> memory" or variations on this.

yup, you got that right.

then again, there is limbo and memory is 'free'.

Re: [9fans] same functions everywhere

[okamoto]

> 							Gorka
> ゴルカ

It's correct!

Kenji

Re: [9fans] same functions everywhere

[Boyd Roberts]

> > Gorka
> > ゴルカ
>
> It's correct!

yup, go ru ka

Re: [9fans] same functions everywhere

[Douglas A. Gwyn]

paurea@plan9.escet.urjc.es wrote:
> On another terms, it would be great to have some function, macro, mechanism
> or whatever to describe calling a function and calling sysfatal on error, because
> this usage of functions repeats itself a lot.

I would suggest instead installing a general exception package,
with a global handler to field uncaught exceptions; the global
handler could call sysfatal.

Re: [9fans] same functions everywhere

[Fco.J.Ballesteros]

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

I just think that for whatever mechanism you want, if it's
commonly used we could just put it in a library intended for
the final application (and not for other library implementors, despite
being bizarre). Actually, I kind of do that; most of the silly apps
I write use a tiny utils.[ch] package that includes among other things
emalloc, errealloc, catcherror, noerror and error (exceptions along the
lines of the exception handling code in the kernel).

I agree that each application should be able to do whatever it wants,
and also that probably this code shouldnt get in the library by default;
but I'd like to see several alternate libraries for error handling so that
when I write an application (and not a library) I could borrow them.

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

From: "Douglas A. Gwyn" <DAGwyn@null.net>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] same functions everywhere
Date: Fri, 25 Apr 2003 10:40:40 GMT
Message-ID: <3EA6EADB.16078459@null.net>

paurea@plan9.escet.urjc.es wrote:
> On another terms, it would be great to have some function, macro, mechanism
> or whatever to describe calling a function and calling sysfatal on error, because
> this usage of functions repeats itself a lot.

I would suggest instead installing a general exception package,
with a global handler to field uncaught exceptions; the global
handler could call sysfatal.

Re: [9fans] same functions everywhere

[Douglas A. Gwyn]

"Fco.J.Ballesteros" wrote:
> I agree that each application should be able to do whatever it wants,
> and also that probably this code shouldnt get in the library by default;
> but I'd like to see several alternate libraries for error handling so that
> when I write an application (and not a library) I could borrow them.

It's much, much easier when the library functions throw
exceptions.  That way the application can handle them any
way it wants (or allow default handling to occur, normally
a fatal error), and the same utility library can be used
unchanged with any application.

Re: [9fans] same functions everywhere

[Joel Salomon]

On Wed, 30 Apr 2003, Douglas A. Gwyn wrote:
>
> It's much, much easier when the library functions throw
> exceptions.  That way the application can handle them any
> way it wants (or allow default handling to occur, normally
> a fatal error), and the same utility library can be used
> unchanged with any application.
>
Can Plan 9 libraries throw such exceptions? where does this functionality
exist?

--Joel

Re: [9fans] same functions everywhere

[rsc]

> Can Plan 9 libraries throw such exceptions? where does this functionality
> exist?

Doug is thinking ahead to C1x.

Re: [9fans] same functions everywhere

[Scott Schwartz]

| > Can Plan 9 libraries throw such exceptions? where does this functionality
| > exist?
|
| Doug is thinking ahead to C1x.

Tell Doug that the committee should be thinking about a standard counted
string/array mechanism instead.

Re: [9fans] same functions everywhere

[Douglas A. Gwyn]

Scott Schwartz wrote:
> | > Can Plan 9 libraries throw such exceptions? where does this functionality
> | > exist?
> | Doug is thinking ahead to C1x.
> Tell Doug that the committee should be thinking about a standard counted
> string/array mechanism instead.

Why?

Re: [9fans] same functions everywhere

[Scott Schwartz]

| Scott Schwartz wrote:
| > | > Can Plan 9 libraries throw such exceptions? where does this functionality
| > | > exist?
| > | Doug is thinking ahead to C1x.
| > Tell Doug that the committee should be thinking about a standard counted
| > string/array mechanism instead.
|
| Why?

Because I think the main problem C has is buffer overruns, and I believe
that the main cause of that is that people use C arrays, pointers,
which don't encode the bounds, along with standard library routines that
discourage doing anything else.

My hypothesis is that if there were an official string library then
people would use that and have fewer bugs, especially if there were a
little syntactic sugar.

	int array q;

Re: [9fans] same functions everywhere

[boyd, rounin]

----- Original Message -----
From: "Scott Schwartz" <schwartz@bio.cse.psu.edu>
> Because I think the main problem C has is buffer overruns, and I believe
> that the main cause of that is that people use C arrays, pointers,
> which don't encode the bounds, along with standard library routines that
> discourage doing anything else.

nope, use a better tool; limbo -- leave 'C' alone.

Re: [9fans] same functions everywhere

[northern snowfall]

>
>
>>Because I think the main problem C has is buffer overruns, and I believe
>>that the main cause of that is that people use C arrays, pointers,
>>which don't encode the bounds, along with standard library routines that
>>discourage doing anything else
>>
The beauty of C is its ability to allow the programmer a very
eloquent sense of flexibility with the underlying system.
"Buffer overruns" are just the manifestation of bad programming,
not a weakness in the language, itself. Every language has its
issues, but, that's where experience and a deep understanding
of how a language works comes in handy :-)
Don't blame C, blame the coder.
Exceptions in a C environment is basically admitting that you
don't understand enough about C to promote elegant and simple
solutions to complex problems in that language. Putting the
blame on C, itself, is simplistic and, frankly, arrogant.
Don

Re: [9fans] same functions everywhere

[Lucio De Re]

On Wed, May 07, 2003 at 06:03:51AM -0500, northern snowfall wrote:

> Exceptions in a C environment is basically admitting that you
> don't understand enough about C to promote elegant and simple
> solutions to complex problems in that language. Putting the
> blame on C, itself, is simplistic and, frankly, arrogant.

I don't go along with that.  Consider the conventional linear search
of an array:

	int a[100];
	int x, v;

	...

	x = 0;
	while (x < 100 && a[x] != v) {
		++x;
	}

(or whatever version you prefer).

At the end, you always have to determine whether you found the
desired element or exceeded the array bounds.  Now, if exceeding
the array bounds could be treated as an exception (imagine a clever
CPU with array bounds checking in hardware delivering a segment
violation error), you could write:

	x = 0;
	while (a[x] != v) {
		++x;
	}

and at the end you'd know that the element was found, because the
exception wasn't triggered.  Better, you'd not even reach the end
of the loop if the element wasn't found.

This particular problem has bugged me for decades :-)  I go along
with Doug that exception handling can hide the extremely uninteresting
code involved in dealing with rare or "off band" conditions.

++L

Re: [9fans] same functions everywhere

[northern snowfall]

>
>
>	int a[100];
>	int x, v;
>
>	...
>
>	x = 0;
>	while (x < 100 && a[x] != v) {
>		++x;
>	}
>
Ok, this seems pretty silly to me, because, it just
breaks down to bad coding style.

#include <u.h>
#include <libc.h>

enum {
    true,
    false,
};

// returns true if value IS found in every slot
// returns false if value is NOT found in every slot
int
gotvalue/*?*/(int * a, uint len, int val)
{
    uint xa;

    for(ua = 0; ua < len; ua++) {
        if(a[ua] != val)
            return false;
    }
    return true;
}

void
main(int argc, char * argv[])
{
    int a[100];

    // somehow "a" gets filled with values

    if(gotvalue(&a[0], sizeof(a), 0xdeadca75) == true)
        print("yay, we're true! \n");
    else
        print("ick. \n");

    exits(0);
}

Re: [9fans] same functions everywhere

[Lucio De Re]

On Wed, May 07, 2003 at 08:05:33AM -0500, northern snowfall wrote:
> >
> Ok, this seems pretty silly to me, because, it just
> breaks down to bad coding style.
>
Not really.  Mostly, one wants the location where the item was found
(x, in my example) which your function discards.  Sometimes, one may
want to take action if the item is not found.

Was it APL that returned -1 on not found?  Doesn't help much if I'm
not interested, as I still have to check the validity of the return
value.

++L

Re: [9fans] same functions everywhere

[northern snowfall]

>
>
>Not really.  Mostly, one wants the location where the item was found
>(x, in my example) which your function discards.  Sometimes, one may
>want to take action if the item is not found.
>
I saw this comin' as soon as I hit the send button. Oh well.
Simply add in functionality to determine the slot of the
first false test.

#include <u.h>
#include <libc.h>

enum {
    true,
    false,
};

// returns true if all slots EQUATE to val
// returns false if all slots do NOT equate to val
// side effects: equates *pos to the first slot that tests false
int
gotvalue/*?*/(int * a, uint len, int val, uint * pos)
{
    uint ua;
    for(ua = 0; ua < len; ua++) {
        if(a[ua] != val) {
            *pos = ua;
            return false;
        }
    }
    return true;
}

int
main(int argc, char * argv[])
{
    int a[100];
    uint pos;

    // somehow "a" gets filled with values

    if(gotvalue(&a[0], sizeof(a), 0xdeadca75, &pos) == true)
        print("yay, we're true! \ n");
    else
        print("negate at slot %ud \n", pos);

    exits(0);
}

Re: [9fans] same functions everywhere

[northern snowfall]

>    if(gotvalue(&a[0], sizeof(a), 0xdeadca75, &pos) == true)

Ack! Apparently I don't rule!
    "sizeof(a)" should be "sizeof(a) / sizeof(int)"
Don't ask me why I missed that. Um. Someone else
typed the email for me. Thats it.
Thanks Butler
Don

Re: [9fans] same functions everywhere

[Ralph Corderoy]

Hi northern snowfall,

> // returns true if all slots EQUATE to val
> // returns false if all slots do NOT equate to val

s/all slots do/any slot does/

> // side effects: equates *pos to the first slot that tests false
> int
> gotvalue/*?*/(int * a, uint len, int val, uint * pos)
> {
>     uint ua;
>     for(ua = 0; ua < len; ua++) {
>         if(a[ua] != val) {
>             *pos = ua;
>             return false;
>         }
>     }
>     return true;
> }

99% of code comments in the world are worthless.

Tact-sucks-ly,

--
Ralph Corderoy.      http://inputplus.co.uk/ralph/     http://troff.org/

Re: [9fans] same functions everywhere

[northern snowfall]

>
>
>>// returns false if all slots do NOT equate to val
>>
>s/all slots do/any slot does/
>
You're, like, misreading the grammar.
If any of single slot does not equate to said value, then,
the slots, as a group, can not all equate to said value.
Like, for sure.

Re: [9fans] same functions everywhere

[David Butler]

Okay, that seems *really* silly to me! Why make a
subroutine call? Why re-test at the end what you know?
If it can be remembered that C is really a portable
assembly language, you will program in a "structured"
assembly style. Use the language:

  int a[100];
  int x, v;

  for (x = sizeof(a) / sizeof(a[0]); x >= 0; x--) {
    if (a[x] == v) {
      goto foundv;
    }
  }

  damn;

foundv:
  cool;

:)

Goto is not bad, programmers that misuse goto are bad.

David

----- Original Message -----
From: "northern snowfall" <dbailey27@ameritech.net>
To: <9fans@cse.psu.edu>
Sent: Wednesday, May 07, 2003 8:05 AM
Subject: Re: [9fans] same functions everywhere


> >
> >
> > int a[100];
> > int x, v;
> >
> > ...
> >
> > x = 0;
> > while (x < 100 && a[x] != v) {
> > ++x;
> > }
> >
> Ok, this seems pretty silly to me, because, it just
> breaks down to bad coding style.
>
> #include <u.h>
> #include <libc.h>
>
> enum {
>     true,
>     false,
> };
>
> // returns true if value IS found in every slot
> // returns false if value is NOT found in every slot
> int
> gotvalue/*?*/(int * a, uint len, int val)
> {
>     uint xa;
>
>     for(ua = 0; ua < len; ua++) {
>         if(a[ua] != val)
>             return false;
>     }
>     return true;
> }
>
> void
> main(int argc, char * argv[])
> {
>     int a[100];
>
>     // somehow "a" gets filled with values
>
>     if(gotvalue(&a[0], sizeof(a), 0xdeadca75) == true)
>         print("yay, we're true! \n");
>     else
>         print("ick. \n");
>
>     exits(0);
> }
>
>
>

Re: [9fans] same functions everywhere

[northern snowfall]

>
>
>Okay, that seems *really* silly to me!
>
hehe
Well, the reason why I make it a seperate
function is because:
    1) unless specified otherwise we have to
        assume that the function will be used
        multiple times.
    2) if used multiple times we're actually
        minimizing instructures in the code
        segment by using a seperate function
    3) modular reusable code is easy to read,
        use, audit, test, retest, hack, recode, etc
    4) Because I rule
But, sure, your way works well, too :)
You're right about goto, too. Lots of people
are afraid of goto, but, as long as its used
wisely, it ain't nothin' but a jump. It all
breaks down to the right choice for the
given situation.
Don

Re: [9fans] same functions everywhere

[boyd, rounin]

#define nels(x)     (sizeof(x) / sizeof (x[0]))

for (p = m; p < &p[nels(m)]; p++) printf("duh\n");

Re: [9fans] same functions everywhere

[Douglas A. Gwyn]

Lucio De Re wrote:
> 	while (x < 100 && a[x] != v) {

Of course there is a well-known "kludge" when the array
has been allocated with an extra slot that can be safely
written:
	a[100] = v;	// sentinel
	while (a[x] != v) {
which speeds the loop up.  The obvious test at the end
distinguishes between "found" and "not found".

I'm not suggesting fine-grained exceptions for such
application unless tightly integrated into the language.
For Standard C at present we seem to be limited to using
setjmp/longjmp, which has too much overhead on most
platforms.

Re: [9fans] same functions everywhere

[Bruce Ellis]

the plan9 setjmp/longjmps i've seen play with the PC and the SP.
that's cheap.  that's why we the error stuff in the kernel doesn't
hit performance.

> For Standard C at present we seem to be limited to using
> setjmp/longjmp, which has too much overhead on most
> platforms.

Re: [9fans] same functions everywhere

[rog]

> the plan9 setjmp/longjmps i've seen play with the PC and the SP.
> that's cheap.  that's why we the error stuff in the kernel doesn't
> hit performance.

if the plan 9 compilers were callee-save, it wouldn't
be so cheap, presumably.

i imagine that might be a source of the inefficiency on other
platforms.

Re: [9fans] same functions everywhere

[Ralph Corderoy]

Hi Lucio,

> I don't go along with that.  Consider the conventional linear search
> of an array:
>
> 	int a[100];
> 	int x, v;
>
> 	...
>
> 	x = 0;
> 	while (x < 100 && a[x] != v) {
> 		++x;
> 	}
>
> (or whatever version you prefer).
>
> At the end, you always have to determine whether you found the desired
> element or exceeded the array bounds.
> ...
> This particular problem has bugged me for decades :-)  I go along with
> Doug that exception handling can hide the extremely uninteresting code
> involved in dealing with rare or "off band" conditions.

Python solves this particular problem like this:

    a = [1, 2, 3]

    for x in range(len(a)):
        if a[x] == 42:
            print x
            break
    else:
        print -1

The for's else clause is only executed if a natural end to the loop is
reached, i.e. you don't break out of it.

Cheers,

--
Ralph Corderoy.      http://inputplus.co.uk/ralph/     http://troff.org/

C (Was: [9fans] same functions everywhere)

[Sam]

> "Buffer overruns" are just the manifestation of bad programming,
> not a weakness in the language, itself. Every language has its

Well, yes, but even the most seasoned programmers
*can* make mistakes.  I believe the issue at hand
is that having this check (and others) a part of
the language permits quick bug discovery and as
a result faster development cycles, in addition
to safer code.

Modifying C to add run-time functionality not
specified by the programmer seems like a step
away from the original intent of the language.
IMHO it should be left as a portable assembly
language.  I view C as a solid base for developing
new languages as it's devilishly fun to write.
Limbo is a wonderful example of how extending
the core of C for something new can be
fruitful.

While I've not read it, I'm told the commentary
on the c99 standard is about 1k pages long.  I
belive this qualifies as sufficiently bloated.

Sam

Re: C (Was: [9fans] same functions everywhere)

[northern snowfall]

>
>
>Well, yes, but even the most seasoned programmers
>*can* make mistakes.  I believe the issue at hand
>is that having this check (and others) a part of
>the language permits quick bug discovery and as
>a result faster development cycles, in addition
>to safer code.
>
You're right. Everyone makes mistakes. Though, I can't
submit to that as a valid reason to move away from a
particular language or define a just-in-case subset to
a language. However, I do feel justified to present a
format for dealing with the issue: breaking down the
development process. To me, this goes right back to
design. Breaking the development process in to
segments allows a project to be generated with less
flaws if adhered to. I'm basically looking at a format
of: theory, design, audit. I'm sure alot of us already
use this formula, to some extent, in our work, now.
Adding on machines that check for "exceptions", such
as a buffer overflow, are often only throwing mud on
top of a dirt grave. There's still a dead cat under there,
somewhere (snowball II?). In my opinion, this is a
big problem with the design of resources, from UNIX
to Windows, and beyond. Instead of looking ahead to
determine the most likely long-term solution, we seem
to patch this-and-that when it seems fit: i.e. sockets in
UNIX, secure-logins, IDS, honeypots, etc. Sure, some
of these things were great improvements/hacks, but,
in the end, the patchwork-quilt design becomes a
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?
Don

[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

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.

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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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]

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

[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

[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

[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

[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

[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]

> toilet seats - just hover

not autorotate?

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

[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]

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

[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: C (Was: [9fans] same functions everywhere)

[Douglas A. Gwyn]

Sam wrote:
> While I've not read it, I'm told the commentary
> on the c99 standard is about 1k pages long.  I
> belive this qualifies as sufficiently bloated.

Do you mean the Rationale document?  (A work still
in progress.)  It has to discuss what could have been
done but wasn't, and why not.  That's inherently a
lot of stuff, and isn't necessary to understand C.
A better example would be K&R 2nd Ed. which is a
tutorial and abbreviated reference guide; much less
than 1000 pages.

Re: [9fans] same functions everywhere

[Russ Cox]

> Don't blame C, blame the coder.

Love the sin, hate the sinner?

[lots of thread snipped]

You're all nuts.  But at least use nelem(a) in
place of sizeof(a)/sizeof(int).

Re: [9fans] same functions everywhere

[northern snowfall]

>
>
>You're all nuts.
>
I call cashews

Re: [9fans] same functions everywhere

[Jack Johnson]

On Wed, May 07, 2003 at 10:47:54AM -0500, northern snowfall wrote:
> >You're all nuts.
> I call cashews

Is that a long-distance call?

-Jack

Re: [9fans] same functions everywhere

[northern snowfall]

>
>
>Is that a long-distance call?
>
Not sure yet... ndb is still attempting to
translate the dial("tcp!cashews!wtf", nil, nil, nil)
call. I'll let you know when it connects.

>

Re: [9fans] same functions everywhere

[Douglas A. Gwyn]

northern snowfall wrote:
>> You're all nuts.
> I call cashews

Gesundheits.

Re: [9fans] same functions everywhere

[Scott Schwartz]

| You're all nuts.  But at least use nelem(a) in
| place of sizeof(a)/sizeof(int).

Maybe nelem should be a compiler builtin, so it can draw a syntax error
when applied to anything that has decayed to a pointer (i.e. almost
every use of an array).

Re: [9fans] same functions everywhere

[Douglas A. Gwyn]

northern snowfall wrote:
> Exceptions in a C environment is basically admitting that you
> don't understand enough about C to promote elegant and simple
> solutions to complex problems in that language.

Not really.  Exceptions reflect complications due to
some warts of the real world.  These can *occur* no
matter what syntax is available, and the only real
issue is how to deal with them.  Leaving that decision
to each and every instance of a function invocation
hardly qualifies as "elegant", and the resulting code
is not "simple" (unless it fails to deal with the
exceptional cases; alas, a lot of existing code is
like that).

Re: [9fans] same functions everywhere

[Brian Inglis]

On Wed, 7 May 2003 14:45:22 GMT in comp.os.plan9,
rsc@plan9.bell-labs.com (Russ Cox) wrote:

>> Don't blame C, blame the coder.
>
>Love the sin, hate the sinner?
>
>[lots of thread snipped]
>
>You're all nuts.  But at least use nelem(a) in
>place of sizeof(a)/sizeof(int).

shouldn't that be called nwords/nints(a) or else shouldn't the
expression be (sizeof(a)/sizeof(*(a)))?

Thanks. Take care, Brian Inglis 	Calgary, Alberta, Canada
--
Brian.Inglis@CSi.com 	(Brian dot Inglis at SystematicSw dot ab dot ca)
    fake address		use address above to reply

Re: [9fans] same functions everywhere

[Russ Cox]

> >You're all nuts.  But at least use nelem(a) in
> >place of sizeof(a)/sizeof(int).
>
> shouldn't that be called nwords/nints(a) or else shouldn't the
> expression be (sizeof(a)/sizeof(*(a)))?

No, it should be called nelem because it's defined (in libc.h):

#define	nelem(x)	(sizeof(x)/sizeof((x)[0]))

You've pointed out a bug in what they were using,
which was part of why I suggested nelem.

Re: [9fans] same functions everywhere

[Douglas A. Gwyn]

rsc@plan9.bell-labs.com wrote:
>>Can Plan 9 libraries throw such exceptions? where does this functionality
>>exist?
> Doug is thinking ahead to C1x.

Actally, no.  Several people (including me) have implemented
general, low-overhead exception-handling systems in C.  It
would be possible to make them more convenient with support
in the language itself, but one can go a long way just by
exploiting setjmp/longjmp via better packaging.

Re: [9fans] same functions everywhere

[Russ Cox]

> Actally, no.  Several people (including me) have implemented
> general, low-overhead exception-handling systems in C.  It
> would be possible to make them more convenient with support
> in the language itself, but one can go a long way just by
> exploiting setjmp/longjmp via better packaging.

You're preaching to the choir.  Look at the Plan 9 kernel.

Re: [9fans] same functions everywhere

[Joel Salomon]

On Thu, 1 May 2003, Russ Cox wrote:
>
> You're preaching to the choir.  Look at the Plan 9 kernel.

So can the kernel's "exceptions" be packaged in library form for
applications?

--Joel

Re: [9fans] same functions everywhere

[rsc]

There are some programs that use the same method,
but it's best used in moderation.  I haven't seen many
programs that would really benefit from it.  (Except, of
course, user-level ports of the Plan 9 kernel.)

Re: [9fans] same functions everywhere

[Joel Salomon]

On Thu, 1 May 2003 rsc@plan9.bell-labs.com wrote:
> There are some programs that use the same method,
> but it's best used in moderation.  I haven't seen many
> programs that would really benefit from it.

So someone porting one of the C "exception" libraries would be a bad idea,
or just of limited use? (Assuming the implementation would come with
wrappers for malloc, fopen, etc.)

--Joel

Re: [9fans] same functions everywhere

[rsc]

Given the syntactic weight of C exception
``libraries'', I'm not convinced they're appropriate
for things like fopen failing.  I think it would be
of limited use.  The code itself is utterly trivial.

Re: [9fans] same functions everywhere

[Douglas A. Gwyn]

rsc@plan9.bell-labs.com wrote:
> Given the syntactic weight of C exception
> ``libraries'', I'm not convinced they're appropriate
> for things like fopen failing.  I think it would be
> of limited use.  The code itself is utterly trivial.

Done right, the main advantages are:

(a) uniform, tested error handling instead of ad-hoc
(b) ensures reasonable default when user neglects to
deal with the possibility of failre
(c) no need for explicit tests of function error
returns

Basically, it's a way to impose order on chaos.

Re: [9fans] same functions everywhere

[rob pike, esq.]

> (a) uniform, tested error handling instead of ad-hoc

only for certain kinds of errors. you still need to write explicit
code (perhaps using exceptions) for many kinds of errors.

> (b) ensures reasonable default when user neglects to
> deal with the possibility of failre

a weak premise and again, only for certain errors.

> (c) no need for explicit tests of function error
> returns

therefore subverting programming discipline.

> Basically, it's a way to impose order on chaos.

and replace it with a mysterious, hard to understand
mechanism with a tendency to overlay a program's
structure with confusing, noisy error-handling
details.

i'm not a fan of exceptions. good programming
can trump them every time; bad exception handling
can destroy a program.  they're an interesting idea
but i judge them a failure.

-rob

Re: [9fans] same functions everywhere

[Andrew Simmons]

Re exceptions, I found the following quote from Stroustrup interesting:

"A notable exception to this agreement was Doug McIlroy, who stated that the
availability of exception handling would make systems less reliable because
library writers and other programmers will throw exceptions rather than try
to understand and handle problems. Only time will tell to what extent Doug's
prediction will be true."

Re: [9fans] same functions everywhere

[Douglas A. Gwyn]

rob pike, esq. wrote:
>>(a) uniform, tested error handling instead of ad-hoc
> only for certain kinds of errors. you still need to write explicit
> code (perhaps using exceptions) for many kinds of errors.

The point is that the same mechanism is used everywhere.
Of course when the current higher-level handling strategy
is not what is wanted in a specific situation, one has to
provide an implementation of whatever strategy is wanted
for that situation.  That strategy can take advantage of
the more global one to field exceptions that the local
code doesn't know how to handle.

>>(b) ensures reasonable default when user neglects to
>>deal with the possibility of failre
> a weak premise and again, only for certain errors.

The current handler for the thrown exception class
fields whatever exceptions the local code doesn't know
about.  Or, the local code could handle the unknown
exception classes if it really wants total control.
The programmer gets to decide, but in the (all too
frequent) case where he hasn't anticipated a failure,
at least the next higher level does whatever it deemed
appropriate, which is generally better than proceeding
to compute "at random" with bogus data.

>>(c) no need for explicit tests of function error
>>returns
> therefore subverting programming discipline.

It's just a different form of discipline.  The main
improvement is that the main logic is much more
visible, since there is no clutter from testing for
all those things that are incidental to the intended
function of the components.  I.e. malloc's job is to
allocate a chunk of storage, not really to test
whether the program has run out of heap space.  The
latter hopefully never occurs, so almost all the time
those tests are for naught.  I'm sure we have all
seen lots of code where the programmer doesn't bother
to check for a null return from malloc, which he has
(good but not perfect) reason to think will not occur.
Such a programmer is a happier one, and with exception
handling in place running out of heap gets caught and
reported without bothering the programmer at all.

>>Basically, it's a way to impose order on chaos.
> and replace it with a mysterious, hard to understand
> mechanism with a tendency to overlay a program's
> structure with confusing, noisy error-handling
> details.

If you're going to handle errors, the code has to
exist one way or another.  A good exception facility
centralizes the error handling in a corner away from
the main logic.  Error handling inherently interferes
with the main logic; it is easier to verify loop
invariants etc. if one doesn't have the "error terms"
in the assertions.  Usually the corner with the error
handling can be verified as doing the correct thing
much more simply than if the possible error cases are
scattered through the main logic.

> i'm not a fan of exceptions. good programming
> can trump them every time; bad exception handling
> can destroy a program.  they're an interesting idea
> but i judge them a failure.

I have the opposite opinion.  I took a substantial
chunk of code from BRL's MUVES project, which was
very careful to "unwind" partial operations upon
errors, and rewrote it using a C exception package.
The result was cleaner looking, easier to follow,
and somewhat smaller, with explicit gotos (necessary
to unwind nested operations) removed.  That is a win.

Re: [9fans] same functions everywhere

[Joel Salomon]

"Douglas A. Gwyn" <DAGwyn@null.net> wrote:

> The main improvement is that the main logic is much more visible, since
> there is no clutter from testing for all those things that are
> incidental to the intended function of the components

Except in java, where *everything* (almost) that can be thrown must be
checked for. Good thing that port was stopped.

Fortunately, I don't think that Java's idiocy can be imposed by any C
based exception package.

Just my $.02

--Joel

Re: [9fans] same functions everywhere

[rog]

> If you're going to handle errors, the code has to exist one way or
> another.  A good exception facility centralizes the error handling in
> a corner away from the main logic.  Error handling inherently
> interferes with the main logic; it is easier to verify loop invariants
> etc.  if one doesn't have the "error terms" in the assertions.
> Usually the corner with the error handling can be verified as doing
> the correct thing much more simply than if the possible error cases
> are scattered through the main logic.

what kinds of exceptional conditions are you thinking about here?

Re: [9fans] same functions everywhere

[Douglas A. Gwyn]

rog@vitanuova.com wrote:
> what kinds of exceptional conditions are you thinking about here?

What would be considered "problems in completing the assignment".
Typically, running out of some system resource, or a already
created data structure is found to have an "impossible" value in
some field, etc.  The idea is that things that are expected to
occur quite a lot should be dealt with in the main logic, since
not taking them into account would be an essential lack of
function, but that things that should rarely occur and are not
of the same kind as expected results should be treated as
exceptions.  Looking at it another way, if it seems that a
situation should be handled within an ongoing loop then it's
not a candidate for an exception, but if it seems that the loop
needs to be aborted because it would be pointless to continue
in the same vein, then it should be an exception.  Yet another
take on the same thing:  If local tactics are expected then it's
not a candidate for an exception, but if a global strategy for
recovery from the condition is expected, then it's an exception.
In practice, the distinction is usually clear.  One could debate
whether getc() returning EOF with ferror() returning false should
be handled as an exception rather than as an exceptional value
for the data, but I'm inclined to think that it should, after
consideration of the problems that having in-band signals has
caused.

Re: [9fans] same functions everywhere

[rog]

> > what kinds of exceptional conditions are you thinking about here?
>
> What would be considered "problems in completing the assignment".
> Typically, running out of some system resource, or a already
> created data structure is found to have an "impossible" value in
> some field, etc.

i think that sounds completely reasonable, and, despite rob's
comments, is de facto the case in many places in plan 9 (if you try to
use a nil data structure, divide by zero, etc).

IMHO there's probably a good case for extending this kind of
exception raising to other errors where most programs will be unable
to recover, the classic example being out-of-memory errors.

> The idea is that things that are expected to
> occur quite a lot should be dealt with in the main logic, since
> not taking them into account would be an essential lack of
> function, but that things that should rarely occur and are not
> of the same kind as expected results should be treated as
> exceptions.

with this, however, i have to disagree.

i believe an exception should represent a genuinely exceptional
condition, i.e.  something which one would not normally expect to
happen during the usual execution of the program.

if something occurs rarely, it's not necessarily exceptional in any
way.

> One could debate whether getc() returning EOF with ferror() returning
> false should be handled as an exception rather than as an exceptional
> value for the data, but I'm inclined to think that it should, after
> consideration of the problems that having in-band signals has caused.

this is a good example.

encountering the end of a file is in no way an exceptional condition.
in fact, for most programs, this condition occurring is a
pre-requisite for correct operation of the program!  using exceptions
for this kind of thing makes the code harder to read, which is a
cardinal sin.

in a normal program, i should never have to deal with exceptions at
all.

(BTW, getc doesn't use in-band signalling, and even if it did,
tuples are a much cleaner solution than exceptions, IMHO).

Re: [9fans] same functions everywhere

[Scott Schwartz]

> encountering the end of a file is in no way an exceptional condition.

A better example is when a write fails.  One common reason is a full disk;
another is a broken pipe.  They're not handled the same, but maybe they
would have been if C had had an exception system.

Re: [9fans] same functions everywhere

[rog]

> A better example is when a write fails.  One common reason is a full disk;
> another is a broken pipe.  They're not handled the same, but maybe they
> would have been if C had had an exception system.

a closed pipe is a special case because it is known that a write can
never work again.  (actually, i always thought you got a least one
error before you got a signal, so that a program that actually checks
for write errors won't be killed, but a quick experiment shows me to
be wrong).

writes fail all the time in plan 9, without necessarily meaning
anything unduly significant (a syntax error in a ctl request for
example).  killing the process responsible seems a bit heavy handed.

i guess one has to ask:

	would killing the process result in more sensible default
	behaviour in most cases than just ignoring the error?

in the case of named pipes, i think it's safe to say that it would.
(stopping endless resource hogging).
for most other things, i don't think so...

Re: [9fans] same functions everywhere

[Douglas A. Gwyn]

rog@vitanuova.com wrote:
> (BTW, getc doesn't use in-band signalling, and even if it did,
> tuples are a much cleaner solution than exceptions, IMHO).

In C, it certainly does.  EOF is returned instead of data
when end-of-file is detected.  An alternative to using an
exception would be to separate the return into two kinds
of information instad of just one; since C doesn't have
tuples, and returning a struct makes for awkward usage,
we could use something like
	io_status new_getc(unsigned char *where);

Re: [9fans] same functions everywhere

[rog]

DAGwyn@null.net:
> rog@vitanuova.com wrote:
> > (BTW, getc doesn't use in-band signalling, and even if it did,
> > tuples are a much cleaner solution than exceptions, IMHO).
>
> In C, it certainly does.  EOF is returned instead of data
> when end-of-file is detected.

depends on how you look at the return value of getc.  there's no
ambiguity between the different kinds of return value.  one can
consider the return value from getc to be "character X or no
character" in just the same way that a function returning a pointer to
a struct can be considered to return "pointer to struct or nil".

it's a perfectly good kind of data - EOF is only out of band if one
doesn't consider "not EOF" to be part of the normal getc return value.

Re: [9fans] same functions everywhere

[Douglas A. Gwyn]

rog@vitanuova.com wrote:
> it's a perfectly good kind of data - EOF is only out of band if one
> doesn't consider "not EOF" to be part of the normal getc return value.

Well, I don't want to get into a debate about that; suffice
it to say that "get next character" is, to me, a function
that cannot be performed when there is no next character,
thus something out of the ordinary has to occur, and making
it occur in the data channel constitutes, to me, an in-band
signal.  Note that this design causes very real problems
for portable C programming, because when sizeof(char)==
sizeof(int) it is very likely that all-one bits is a valid
data value *as well as* the EOF marker, so the program has
to perform an additional feof() test that would not be
necessary if the two kinds of information had been kept
separate.

Re: [9fans] same functions everywhere

[rog]

DAGwyn@null.net:
> when sizeof(char)==
> sizeof(int) it is very likely that all-one bits is a valid
> data value *as well as* the EOF marker

don't most >8bit character encodings (including unicode) provide at
least one code point to represent "not a character"?

anyway, i'm not arguing about the design of getc.  maybe it should
have been

	int getc(FILE *f, char *c);

filling in the character at c iff it returns 1.  some of the plan 9
rune(2) functions work in this kind of way.

however, i would argue that using exceptions for such a thing would be
fairly unwieldy, and end up obfuscating what should be plain,
straightforward code.

exceptions are surprising things: they do not facilitate linear
reading of the code; they should be kept for genuinely surprising
conditions.

Re: [9fans] same functions everywhere

[John Murdie]

On Fri, 2003-05-09 at 14:21, rog@vitanuova.com wrote:
> DAGwyn@null.net:
> > when sizeof(char)==
> > sizeof(int) it is very likely that all-one bits is a valid
> > data value *as well as* the EOF marker
>
> don't most >8bit character encodings (including unicode) provide at
> least one code point to represent "not a character"?
>
> anyway, i'm not arguing about the design of getc.  maybe it should
> have been
>
> 	int getc(FILE *f, char *c);
>
> filling in the character at c iff it returns 1.  some of the plan 9
> rune(2) functions work in this kind of way.
>
> however, i would argue that using exceptions for such a thing would be
> fairly unwieldy, and end up obfuscating what should be plain,
> straightforward code.
>
> exceptions are surprising things: they do not facilitate linear
> reading of the code; they should be kept for genuinely surprising
> conditions.

And then what should one do? Suppose that a "genuinely surprising
condition" occurs when a launch vehicle is a few tens of seconds off the
ground; just what should the program do?

I agree with those here that hold the opinion that exceptions are no
substitute for a well-thought-out and well-notated program (we used to
call it "structured programming"). Need error handling obscure the
"all's well" logic of the program?

John A. Murdie
Department of Computer Science
University of York
UK

Re: [9fans] same functions everywhere

[northern snowfall]

>
>
>And then what should one do? Suppose that a "genuinely surprising
>condition" occurs when a launch vehicle is a few tens of seconds off the
>ground; just what should the program do?
>
Hopefully, the programmer would have enough sense to
see this coming? The point of smart design is to facilitate
the unexpected, I don't think that means exceptions are
the answer. Certainly, this argument is slightly dramatic,
wouldn't you agree, John?
When I look at exceptions in C, I think mainly of sigjmp
(and to a lesser extent, goto). Though, this still doesn't
eradicate the problem that manfiested the exception. A
good example is the recent exploit I wrote for sendmail
version 8.12.8. Since version 8.12.8, itself, emulated an
exception on detection of invalid lengths in the prescan()
function, the exploitation technique for versions <8.12.8
was moot, since prescan() never returned. Instead, a
sigjmp_buf was used to reconstruct the execution
environment as it would have looked well before the
call to prescan(). However, I noticed that certain code
paths to prescan() allocated a small enough amount of
stack for me to reach the actual sigjmp_buf. On UNIX,
the first address stored in a sigjmp_buf is the EIP to be
entered on longjmp-and-friends. Able to overwrite this
EIP with values that would redirect code execution (still
in the valid code segment) to a place that would then
create a secondary vuln:
    e.g. assembly code used to call (*fp->{read, ... })(...
        mov (0x44)%ebx, %eax
        call *%eax
Thus, in very limited situations, I was still able to get
my malicious code, pumped in from the network, run.

This situation is a great example of a "genuinely
surprising condition", and the writers did a good job
to eradicate the easier frame-pointer-overwrite
technique. However, I was still able to assert control
of the target. In a more volatile situation (launch vehicle?)
is this good enough? This is what makes me think that
exception handlers are still secondary to forcing our
developers to take the time to think about the repercussions
of their work: whether it be an addendum, redesign, fresh
write, etc. Well designed code can still be flexible in all
given situations, even the unexpected. However,
implementing exceptions simply because you *think*
that might make things better (as opposed to taking a
look at the big picture) might just change the scope of
the problem.
Don

Re: [9fans] same functions everywhere

[John Murdie]

On Fri, 2003-05-09 at 19:24, northern snowfall wrote:
> >
> >
> >And then what should one do? Suppose that a "genuinely surprising
> >condition" occurs when a launch vehicle is a few tens of seconds off the
> >ground; just what should the program do?
> >
> Hopefully, the programmer would have enough sense to
> see this coming? The point of smart design is to facilitate
> the unexpected, I don't think that means exceptions are
> the answer. Certainly, this argument is slightly dramatic,
> wouldn't you agree, John?

That's precisely my point (and, yes, it is slightly dramatic but, then,
people do code launch vehicle control systems). I'm glad we agree. I
would hope that the analyst/programmer[s] would have designed the code
in such a way that it straightforwardly describes what should be done in
all anticipatable circumstances. I don't think it is worth betting that
ad hoc exception-handling code can cope with the "genuinely surprising
condition".

I think that exceptions encourage careless, lazy, analysis and
programming, and produce code that is unclear and (more) difficult to
reason about than traditional sequential, predicate-transforming, code.
Yes, they can be used as a short-hand notation to code e.g. the rule
"whenever an arithmetic overflow occurs in this section of code, I don't
care; just quit (or do the calculation again with different parameters,
or whatever)", but they are also used as an inadequate substitute for
proper systems analysis and coding. I think that this was Rob Pike's
point, with which I agree.

(To counter my own argument, though, I remember reading something that -
I think - Doug McIlroy wrote about error handling code in telephone
exchanges; the code had been known to recover successfully from errors
that the designers had not anticipated. That said, I'd rather not trust
to such luck.)

John A. Murdie

Re: [9fans] same functions everywhere

[boyd, rounin]

From: "John Murdie" <john@cs.york.ac.uk>
> I think that exceptions encourage careless, lazy, analysis and
> programming, and produce code that is unclear and (more) difficult to
> reason about than traditional sequential, predicate-transforming, code.
> Yes, they can be used as a short-hand notation to code e.g. the rule
> "whenever an arithmetic overflow occurs in this section of code, I don't
> care; just quit (or do the calculation again with different parameters,
> or whatever)", but they are also used as an inadequate substitute for
> proper systems analysis and coding.

like when the F-16 rolled inverted when it crossed the equator when flying
south.

Re: [9fans] same functions everywhere

[boyd, rounin]

NASA used to build spacecraft; top down design, bottom up implementation.

now they 'build the shuttle'.

grissom is dead because of their own 'failure of vision';  the gemini mission
where the exploding bolts fired, so they removed 'em and so we had O2 +
velcro + a spark --- all of 'em dead ...

Re: [9fans] same functions everywhere

[Douglas A. Gwyn]

John Murdie wrote:
> (To counter my own argument, though, I remember reading something that -
> I think - Doug McIlroy wrote about error handling code in telephone
> exchanges; the code had been known to recover successfully from errors
> that the designers had not anticipated. That said, I'd rather not trust
> to such luck.)

The point is, it wasn't luck, but rather a global strategy that
would handle whatever had not been explcitly identified in
advance as a possible problem.

The problem with embedded error recovery in predicate-transform
approach is that the Boolean expressions become unwieldy very
quickly; by their nature exceptional conditions are a wart that
don't fit cleanly into the main logic flow.  If you cram them
into the main flow anyway, then the complexity increases to the
point that no programmer can completely grasp it.

Of course, for "toy systems" almost anything will work if
enough thought goes into it, but for large, intrinsically
messy systems, methodology for bringing complexity under control
is essential.

Re: [9fans] same functions everywhere

[boyd, rounin]

digital telephony, 2nd ed, john bellamy

Re: [9fans] same functions everywhere

[David Presotto]

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

I love religious arguments.

In #5ESS, error handling was a large % of the code.  It involved
in line checks, dead man timers, separate auditing systems,
and lots of code review to make sure there were no `don't care'
cases.  It was incredibly messy and fragile.  Exceptions might
have cleaned up some part of it but most of the process was
trying to avoid being sloppy.  Much of that could be
automated through tools, path analysis, and testing.

The complexity is still there with inline error handling or
exception mechanisms.  Separating the exception code can
(but not always will) clean up the main flow.  It also
reduces the number of places you can 'forget' to check.
Unfortunately, the further from the main flow it moves, the
less likely that it will be updated when the main flow changes.
This has caused us almost as many errors over time as missing
an exception case.  At the very least the exception catcher has to be in the
scope of what its cleaning up or everything (recoverable) in
the main flow has to be global.

However, the important part is handling all the possible
error states. The really unforseen ones (except for the odd
nil pointer reference or divide by zero) don't throw
exceptions.  In #5ESS, the auditing code was the mechanism
for these kinds of errors.  The auditing code continually
scanned the state of switch boards, processes, and memory
to make sure states didn't exist that were considered
'impossible'.  Of course this meant enumerating forseen
states.  If you stepped outside of the forseen, it was
time for action (reset the switch, kill processes, switch
to another processor, ...).  This is a really hard way to
 program and not something I'ld normally do.

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

From: "Douglas A. Gwyn" <DAGwyn@null.net>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] same functions everywhere
Date: Mon, 12 May 2003 08:56:43 GMT
Message-ID: <3EBDBBDC.3090300@null.net>

John Murdie wrote:
> (To counter my own argument, though, I remember reading something that -
> I think - Doug McIlroy wrote about error handling code in telephone
> exchanges; the code had been known to recover successfully from errors
> that the designers had not anticipated. That said, I'd rather not trust
> to such luck.)

The point is, it wasn't luck, but rather a global strategy that
would handle whatever had not been explcitly identified in
advance as a possible problem.

The problem with embedded error recovery in predicate-transform
approach is that the Boolean expressions become unwieldy very
quickly; by their nature exceptional conditions are a wart that
don't fit cleanly into the main logic flow.  If you cram them
into the main flow anyway, then the complexity increases to the
point that no programmer can completely grasp it.

Of course, for "toy systems" almost anything will work if
enough thought goes into it, but for large, intrinsically
messy systems, methodology for bringing complexity under control
is essential.

Re: [9fans] same functions everywhere

[boyd, rounin]

non local gotos are not your friend

complex embedded systems was [9fans] same functions everywhere

[David Butler]

Ah, religious arguments. My life is full of them.

[This is only remotely related to exception handling in a
language and more about implementing complex systems,
including handling exceptions.]

All this talk of large and complex embedded systems
reminds me of a problem I had while doing the electrical
power subsystem software of the F-22. The F-22 has
more need for electricity than it can generate (something
about needing to keep the weight of the generators down).

The design called for all other subsystems to "request" power
and the electrical software made the decision of what to turn
on based on requests, sensors, power generation, damaged
power distribution systems, etc. etc. etc... There were hundreds
of inputs and the little 16 bit TI processor had to drive outputs
20 times a second!

If that was not hard enough, the requirements changed hourly.
We would get these "state tables" from subsystem engineers
to describe their little part of the world. It was amazing what
went into deciding which fuel pumps to turn on to help keep
the plane balanced... :)

So I created a tool. It helped with the description (allows using
"spread sheet" programs to edit the "tables") analysis (ambiguous
states, unused inputs, etc.), coding (nested if's or, if the nesting
went beyond the compiler's ability, flat jump code), and
optimization (minimized the worse case number of inputs that
need to be checked at any time). And by using the ELSE feature,
I could easily identify the exceptions. I would usually give that
input back to the subsystem team for analysis.

If you are really twisted and like these kind of things you can
find more information at www.dbSystems.com/stc/.

David

----- Original Message -----
From: "David Presotto" <presotto@closedmind.org>
To: <9fans@cse.psu.edu>
Sent: Monday, May 12, 2003 8:19 AM
Subject: Re: [9fans] same functions everywhere


> I love religious arguments.
>
> In #5ESS, error handling was a large % of the code.  It involved
> in line checks, dead man timers, separate auditing systems,
> and lots of code review to make sure there were no `don't care'
> cases.  It was incredibly messy and fragile.  Exceptions might
> have cleaned up some part of it but most of the process was
> trying to avoid being sloppy.  Much of that could be
> automated through tools, path analysis, and testing.
>
> The complexity is still there with inline error handling or
> exception mechanisms.  Separating the exception code can
> (but not always will) clean up the main flow.  It also
> reduces the number of places you can 'forget' to check.
> Unfortunately, the further from the main flow it moves, the
> less likely that it will be updated when the main flow changes.
> This has caused us almost as many errors over time as missing
> an exception case.  At the very least the exception catcher has to be in
the
> scope of what its cleaning up or everything (recoverable) in
> the main flow has to be global.
>
> However, the important part is handling all the possible
> error states. The really unforseen ones (except for the odd
> nil pointer reference or divide by zero) don't throw
> exceptions.  In #5ESS, the auditing code was the mechanism
> for these kinds of errors.  The auditing code continually
> scanned the state of switch boards, processes, and memory
> to make sure states didn't exist that were considered
> 'impossible'.  Of course this meant enumerating forseen
> states.  If you stepped outside of the forseen, it was
> time for action (reset the switch, kill processes, switch
> to another processor, ...).  This is a really hard way to
>  program and not something I'ld normally do.

Re: complex embedded systems was [9fans] same functions everywhere

[boyd, rounin]

> The F-22 has more need for electricity than it can generate (something
> about needing to keep the weight of the generators down).

isn't that the international signal to run away?

Re: [9fans] same functions everywhere

[boyd, rounin]

> The problem with embedded error recovery in predicate-transform
> approach is that the Boolean expressions become unwieldy very
> quickly; by their nature exceptional conditions are a wart that
> don't fit cleanly into the main logic flow.  If you cram them
> into the main flow anyway, then the complexity increases to the
> point that no programmer can completely grasp it.

spin

Re: [9fans] same functions everywhere

[rog]

> I agree with those here that hold the opinion that exceptions are no
> substitute for a well-thought-out and well-notated program (we used to
> call it "structured programming"). Need error handling obscure the
> "all's well" logic of the program?

leaving safety-critical systems aside (where every error *must* be
handled appropriately), there are runtime errors that can occur with
very low probability which mean that the program is unable to proceed.

in many programs, the only reasonable thing to do in such a case is to
exit.  in some others, there might be other actions that are worth
performing (e.g.  an editor might save current work; a multi-threaded
program might kill the other threads, etc).

if i wish to enable such a thing without any sort of exceptions, there
must be a return path back from *any* function that calls (directly or
indirectly) any other function that can incur one of these errors.

i.e.  it is never acceptable to write a function f returning type T
without also providing an additional error return (which must then be
propagated up the stack).

the additional error return, and the code necessary to check and
propagate the error, certainly seems like clutter to me, since i would
otherwise choose not to handle the error (or activate some
"fingers-crossed" recovery mechanism).  the exception mechanism also
enables me to catch errors generated by the run-time-system, where
there's no obvious place to handle the error (e.g.  stack overflow,
division by zero).

note that it's only clutter *because* i would have chosen not to try
to handle the error.  thus i would not count the error checking code
around fopen as clutter, because i will almost always choose to handle
that error appropriately (e.g.  by printing a sensible error message).

safety-critical systems are very different in this respect.  perhaps
in this kind of system, every division operation *should* have a check
for division by zero around it...

  cheers,
    rog.

[9fans] (Re:) Exception handling

[Sape Mullender]

I have `ported' (it's so trivial, it doesn't deserve being calleda port) the kernel's
exception mechanism (error, waserror, nexterror, poperror)
to a largish application we're building for a high-speed wireless switch.
I did this after we already had a lot of conventional error checking in the code, e.g.,
	snprint(buf, sizeof(buf), "add %s 255.255.255.255 %s %d proxy",
		con->locaddr, con->remaddr, 2048);
	if(fprint(cfd, "%s", buf) < 0){
		close(cfd);
		return "can't set  addresses";
	}
	if(fprint(cfd, "iprouting 1") < 0){
		close(cfd);
		return "can't set  iprouting";
	}
(This routine used a nn-nil return as an error indication).
The caller of this routine would have a similar test:
	if (error = ipsetup(con)){
		cleanup();
		...
Converting the whole app from this error checking style to using waserror, etc.
took some time, but in the end it did reduce code size and it made the code more
legible.  It also made it harder to ignore unhandled errors deep in several
layers of subroutines.

Re: [9fans] (Re:) Exception handling

[Russ Cox]

I used exception handling once and it made everything better.

Re: [9fans] (Re:) Exception handling

[Fco.J.Ballesteros]

My experience with error handling has been very much like Sape said
in his post. I get cleaner code with my `port' of the kernel expection
handling than I get with

	if ( ! dothis() ){
		handle the failure
	}
	if ( ! dothat() ){
		handle the failure
	}

Although code can get obscured if exceptions are used badly, the same
happens with traditional error checking.

In the end, I think it's the programmer what counts, and not the
particular error handling mechanism. I've seen both good and nasty
code with and without exceptions (regarding err handling).

Re: [9fans] (Re:) Exception handling

[boyd, rounin]

> In the end, I think it's the programmer what counts, and not the
> particular error handling mechanism.

1

Re: [9fans] (Re:) Exception handling

[Fco.J.Ballesteros]

>> In the end, I think it's the programmer what counts, and not the
>> particular error handling mechanism.
>
> 1

465 nemo: replymail(): unknown exception

Re: [9fans] (Re:) Exception handling

[Dan Cross]

> I used exception handling once and it made everything better.

I have a loaf of stale bread at home, but I really want a peanut butter
and jelly sandwich.  Which exception handling package would you recommend
to make my bread better?

	- Dan C.

Re: [9fans] (Re:) Exception handling

[boyd, rounin]

> I have a loaf of stale bread at home, but I really want a peanut butter
> and jelly sandwich.  Which exception handling package would you recommend
> to make my bread better?

the MP5-A[35]

well, it'll make you feel better :)

Re: [9fans] (Re:) Exception handling

[Russ Cox]

I used exception handling once and it made everything worse.

Re: [9fans] (Re:) Exception handling

[boyd, rounin]

> I used exception handling once and it made everything worse.

i've seen it used badly 'and it made everything worse'.

the maze of twisty little gotos, all alike ...

Re: [9fans] (Re:) Exception handling

[Dan Cross]

> I used exception handling once and it made everything worse.

Oh; was that what that ``swarm of locusts'' thing was all about?

	- Dan C.

Re: [9fans] (Re:) Exception handling

[boyd, rounin]

> Oh; was that what that ``swarm of locusts'' thing was all about?

yeah, we were a few miles out of barstow and ...

Re: [9fans] (Re:) Exception handling

[boyd, rounin]

> Converting the whole app from this error checking style to using waserror,
etc.
> took some time, but in the end it did reduce code size and it made the code
more
> legible.  It also made it harder to ignore unhandled errors deep in several
> layers of subroutines.

yup, invest some time at the beginning and avoid those false economies.

Re: [9fans] same functions everywhere

[boyd, rounin]

> leaving safety-critical systems aside ...

every system is 'safety-critical'; i want perfection ...

Re: [9fans] same functions everywhere

[rog]

> > leaving safety-critical systems aside ...
>
> every system is 'safety-critical'; i want perfection ...

cost <-> benefit

Re: [9fans] same functions everywhere

[boyd, rounin]

> cost <-> benefit

gee, i learn something every day ...

Re: [9fans] same functions everywhere

[Dan Cross]

> exceptions are surprising things: they do not facilitate linear
> reading of the code; they should be kept for genuinely surprising
> conditions.

I think this kind of depends on the syntax.  I once saw a proposed syntax
for Limbo (due to  Michael Baldwin, inspired by Icon, perhaps) that I
thought was really great; it looked something like:

	thing = function(foo, bar, baz); ! { exception handler, note bang }

The ability to station an exception handler after a statement using
the bang syntax gave one the `feeling' of programming without exceptions,
but also allowed one to move the error handling to a potentially more
appropriate place.  You could write code like:

	if (a == SYMBOLIC_CONSTANT) {
		str := string arr;
		b := a / 2;
		mod = load Mod Mod->PATH;
	} ! { sys->print("Something bad happened.\n"); }

It was very unintrusive, and I liked it a lot.

	- Dan C.

Re: [9fans] same functions everywhere

[Douglas A. Gwyn]

rog@vitanuova.com wrote:
> don't most >8bit character encodings (including unicode) provide at
> least one code point to represent "not a character"?

We're not talking about character codes, but rather data
obtained via getc().  It could be an arbitrary binary stream.

Re: [9fans] same functions everywhere

[boyd, rounin]

From: "Douglas A. Gwyn" <DAGwyn@null.net>
> rog@vitanuova.com wrote:
> > don't most >8bit character encodings (including unicode) provide at
> > least one code point to represent "not a character"?
>
> We're not talking about character codes, but rather data
> obtained via getc().  It could be an arbitrary binary stream.

yup, getc() returns 8 bits.  it does not return unicode chars or unicode
codespace characters.

Re: [9fans] same functions everywhere

[rog]

> From: "Douglas A. Gwyn" <DAGwyn@null.net>
> > rog@vitanuova.com wrote:
> > > don't most >8bit character encodings (including unicode) provide at
> > > least one code point to represent "not a character"?
> >
> > We're not talking about character codes, but rather data
> > obtained via getc().  It could be an arbitrary binary stream.
>
> yup, getc() returns 8 bits.  it does not return unicode chars or unicode
> codespace characters.

if that's the case then doug's original objection isn't a problem, as
you're guaranteed that int has more than 8 bits, so there's always
space for a representation of EOF.

i'm slightly doubtful that the standard actually says 8 bits though.
K&R just says "returns the next character", which could mean anything.

Re: [9fans] same functions everywhere

[boyd, rounin]

> i'm slightly doubtful that the standard actually says 8 bits though.
> K&R just says "returns the next character", which could mean anything.

getc() always returned an int (>= 16 bits) and EOF was -1, so there is
no confusion.  get it wrong and it will bite you one day;  what was the
paper that described feeding 'random' bit stream into lunix (sic) filters?
i forget, but a lot of 'em broke.

    ashes to ashes
    dust to dust
    if you hack the kernel
    it's gonna bust

       -- bassoids

Re: [9fans] same functions everywhere

[Douglas A. Gwyn]

"boyd, rounin" wrote:
> yup, getc() returns 8 bits.

Actually an integer value representable using CHAR_BIT bits.
Even as of K&R 1st Ed. it wasn't necessarily exactly 8 bits.

Re: [9fans] same functions everywhere

[boyd, rounin]

> Actually an integer value representable using CHAR_BIT bits.
> Even as of K&R 1st Ed. it wasn't necessarily exactly 8 bits.

8 bits != -1

Re: [9fans] same functions everywhere

[boyd, rounin]

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

"Douglas A. Gwyn" <DAGwyn@null.net> a �crit dans le message de
news:3EBB29D8.7030200@null.net...
> Well, I don't want to get into a debate about that; suffice
> it to say that "get next character" is, to me, a function
> that cannot be performed when there is no next character ...

that's what peekc() macros are for :)

Re: [9fans] same functions everywhere

[Dan Cross]

> I have the opposite opinion.  I took a substantial
> chunk of code from BRL's MUVES project, which was
> very careful to "unwind" partial operations upon
> errors, and rewrote it using a C exception package.
> The result was cleaner looking, easier to follow,
> and somewhat smaller, with explicit gotos (necessary
> to unwind nested operations) removed.  That is a win.

Sounds like a good candidate for writing in C++ or a similar language.
C isn't optimal for writing really big applications; it's great for
smaller things like utilities, text editors, systems software, etc.
But it's frankly inconvenient for building huge programs.  It's just
too low-level.  E.g., if I ever have to write another hashing function
to try and implement some sort of string-based lookup again, I'll
scream.

I don't understand why everyone feels the need to try and shoehorn
their favorite language into every conceivable problem domain.  C
doesn't need a low-level string type, nor does it need exceptions; what
programmers who are looking for those things need to do is look for
another language.

	- Dan C.

Re: [9fans] same functions everywhere

[Russ Cox]

> Sounds like a good candidate for writing in C++ or a similar language.
> C isn't optimal for writing really big applications; it's great for
> smaller things like utilities, text editors, systems software, etc.
> But it's frankly inconvenient for building huge programs.  It's just
> too low-level.  E.g., if I ever have to write another hashing function
> to try and implement some sort of string-based lookup again, I'll
> scream.

All this and more can be said of C++.

> I don't understand why everyone feels the need to try and shoehorn
> their favorite language into every conceivable problem domain.

Because when you start out writing a program in one language,
once you get a lot of code written it's costly to switch to another.
Or maybe you want to use some outside libraries available only in C.

> C doesn't need a low-level string type, nor does it need exceptions; what
> programmers who are looking for those things need to do is look for
> another language.

And what language is going to give it to them?  C++?  Ha.  Ha ha ha.
What happens when C++ is too low-level for the job at hand?  It's not
any more malleable than C is (though it is quite a bit more amorphous).

I've been looking for another language for a few years now, and I
don't see it.  Would you have us not write programs because there's
no good language to write them in?

Claiming that the language designer will correctly anticipate the
exact level of abstraction required for your huge program is ridiculous.
The programmer has to be able to build up abstractions as necessary.
And you can do this in C as well as you can in any of the other languages
commonly used for systems programming.

The only language that facilitates programmer-based extension
outstandingly well is Lisp, but Lisp has other problems.

Russ

Re: [9fans] same functions everywhere

[Dan Cross]

You totally missed my point.  What I was trying to convey is that one
size doesn't fit all; there's no one single language for doing everything,
but people tend to take a language and stick to it like glue, no matter
that it might not be the best candidate for any given job.

> > Sounds like a good candidate for writing in C++ or a similar language.
                                                    ^^^^^^^^^^^^^^^^^^^^^
> > C isn't optimal for writing really big applications; it's great for
> > smaller things like utilities, text editors, systems software, etc.
> > But it's frankly inconvenient for building huge programs.  It's just
> > too low-level.  E.g., if I ever have to write another hashing function
> > to try and implement some sort of string-based lookup again, I'll
> > scream.
>
> All this and more can be said of C++.

Perhaps.  However, note that I said, ``or a similar language.''  C++ is
a contrived example.  However, I don't need to add a string type or
exceptions to it, and the STL more or less eliminates the need to
write stuff like linked lists or growable arrays or generic dictionary
containers.  That's a win if I want to get something done, and not
fiddle around with a lot of low-level details.  From the sounds of Doug's
example, he had to do a lot of low-level wrangling.

> > I don't understand why everyone feels the need to try and shoehorn
> > their favorite language into every conceivable problem domain.
>
> Because when you start out writing a program in one language,
> once you get a lot of code written it's costly to switch to another.
> Or maybe you want to use some outside libraries available only in C.

Continuing the C++ example, C++ makes it very easy to call C code.  In
fact, I'd go so far as to say that most languages one might seriously
consider for writing big applications do.

> > C doesn't need a low-level string type, nor does it need exceptions; what
> > programmers who are looking for those things need to do is look for
> > another language.
>
> And what language is going to give it to them?  C++?  Ha.  Ha ha ha.

No, Limbo.

C++ *does* give you a string type and exceptions.  Is it suitable for
every job?  No, but I never said it was.  In fact, my point was that no
single language is.  Once again, the use of C++ was a contrived example.

> What happens when C++ is too low-level for the job at hand?  It's not
> any more malleable than C is (though it is quite a bit more amorphous).

So use something else.

There are any number of languages available to fill all kinds of roles.
Use whatever fits.

> I've been looking for another language for a few years now, and I
> don't see it.  Would you have us not write programs because there's
> no good language to write them in?

What part of what I wrote makes you think that's what I meant?

> Claiming that the language designer will correctly anticipate the
> exact level of abstraction required for your huge program is ridiculous.

I don't recall ever making that claim.  Perhaps you can cite where I did.

I do recall claiming that no one language is suitable for every
application domain, and that trying to shoehorn C into being so is a
mistake.

> The programmer has to be able to build up abstractions as necessary.

Agreed.

> And you can do this in C as well as you can in any of the other languages
> commonly used for systems programming.

Note that I mentioned ``applications programming,'' not just ``systems
programming.''  For systems programming, you're right.  For applications
programming, you're not.

> The only language that facilitates programmer-based extension
> outstandingly well is Lisp, but Lisp has other problems.

That's subjective.  I could argue that any number of functional
programming languages do just as good a job as Lisp in this arena.

But hell, why don't we all just program in some kind of generic
assembly language?  We can define a set of opcodes that map to useful
operations, and build a macro assembler that provides a generic string
type and exceptions.  And why have a seperate shell language that we
write scripts in?  Why not write everything as a C program?

	- Dan ``One size doesn't fit all'' C.

Re: [9fans] same functions everywhere

[root]

You guys are headed down the wrong track.

The right way to program is with small modules written in several
different languages which are meant for specific purposes.

-Phil/CERisE

On Thu, May 08, 2003 at 02:14:53PM -0400, Dan Cross wrote:
> You totally missed my point.  What I was trying to convey is that one
> size doesn't fit all; there's no one single language for doing everything,
> but people tend to take a language and stick to it like glue, no matter
> that it might not be the best candidate for any given job.
>
> > > Sounds like a good candidate for writing in C++ or a similar language.
>                                                     ^^^^^^^^^^^^^^^^^^^^^
> > > C isn't optimal for writing really big applications; it's great for
> > > smaller things like utilities, text editors, systems software, etc.
> > > But it's frankly inconvenient for building huge programs.  It's just
> > > too low-level.  E.g., if I ever have to write another hashing function
> > > to try and implement some sort of string-based lookup again, I'll
> > > scream.
> >
> > All this and more can be said of C++.
>
> Perhaps.  However, note that I said, ``or a similar language.''  C++ is
> a contrived example.  However, I don't need to add a string type or
> exceptions to it, and the STL more or less eliminates the need to
> write stuff like linked lists or growable arrays or generic dictionary
> containers.  That's a win if I want to get something done, and not
> fiddle around with a lot of low-level details.  From the sounds of Doug's
> example, he had to do a lot of low-level wrangling.
>
> > > I don't understand why everyone feels the need to try and shoehorn
> > > their favorite language into every conceivable problem domain.
> >
> > Because when you start out writing a program in one language,
> > once you get a lot of code written it's costly to switch to another.
> > Or maybe you want to use some outside libraries available only in C.
>
> Continuing the C++ example, C++ makes it very easy to call C code.  In
> fact, I'd go so far as to say that most languages one might seriously
> consider for writing big applications do.
>
> > > C doesn't need a low-level string type, nor does it need exceptions; what
> > > programmers who are looking for those things need to do is look for
> > > another language.
> >
> > And what language is going to give it to them?  C++?  Ha.  Ha ha ha.
>
> No, Limbo.
>
> C++ *does* give you a string type and exceptions.  Is it suitable for
> every job?  No, but I never said it was.  In fact, my point was that no
> single language is.  Once again, the use of C++ was a contrived example.
>
> > What happens when C++ is too low-level for the job at hand?  It's not
> > any more malleable than C is (though it is quite a bit more amorphous).
>
> So use something else.
>
> There are any number of languages available to fill all kinds of roles.
> Use whatever fits.
>
> > I've been looking for another language for a few years now, and I
> > don't see it.  Would you have us not write programs because there's
> > no good language to write them in?
>
> What part of what I wrote makes you think that's what I meant?
>
> > Claiming that the language designer will correctly anticipate the
> > exact level of abstraction required for your huge program is ridiculous.
>
> I don't recall ever making that claim.  Perhaps you can cite where I did.
>
> I do recall claiming that no one language is suitable for every
> application domain, and that trying to shoehorn C into being so is a
> mistake.
>
> > The programmer has to be able to build up abstractions as necessary.
>
> Agreed.
>
> > And you can do this in C as well as you can in any of the other languages
> > commonly used for systems programming.
>
> Note that I mentioned ``applications programming,'' not just ``systems
> programming.''  For systems programming, you're right.  For applications
> programming, you're not.
>
> > The only language that facilitates programmer-based extension
> > outstandingly well is Lisp, but Lisp has other problems.
>
> That's subjective.  I could argue that any number of functional
> programming languages do just as good a job as Lisp in this arena.
>
> But hell, why don't we all just program in some kind of generic
> assembly language?  We can define a set of opcodes that map to useful
> operations, and build a macro assembler that provides a generic string
> type and exceptions.  And why have a seperate shell language that we
> write scripts in?  Why not write everything as a C program?
>
> 	- Dan ``One size doesn't fit all'' C.
>

Re: [9fans] same functions everywhere

[William Ahern]

On Thu, May 08, 2003 at 11:21:21AM -0700, root wrote:
> You guys are headed down the wrong track.
>
> The right way to program is with small modules written in several
> different languages which are meant for specific purposes.
>
> -Phil/CERisE

yeah. and isn't this the philosophy behind Unix and Plan 9? that is, a
system that defines a very generic, very abstract and yet very simple means
for inter-process communication?

once you're holding a huge bag of code, you've already lost the game.
all the different pieces are too intertwined, regardless of how well
you encapsulate or w'ever within the language.

IP, pipe streams and file object namespaces are good; concerning yourself w/
how you link some language into a C library is bad.

managing application complexity by building a more complex language
seems a tad misguided.

in this day and age, w/ all the talk going into "emergent behaviors",
complex systems, etc, i'm surprised to hear people arguing for monolithic
designs that specify brittle internal procedure and process, rather than
simple designs that define simple interactions.

Re: [9fans] same functions everywhere

[Dan Cross]

> once you're holding a huge bag of code, you've already lost the game.
> all the different pieces are too intertwined, regardless of how well
> you encapsulate or w'ever within the language.

Well, once you put the application logic into the domain of some
network system, it could be argued that you're tied to that network
system.  This may or may not be beneficial.  Sometimes that introduces
complexity that shouldn't exist (consider all the Corba cruft under
Unix et al, or how complex J2EE is; in both cases, you're trying to
distributed things in some way so that the code isn't centralized).

> IP, pipe streams and file object namespaces are good; concerning yourself w/
> how you link some language into a C library is bad.

This is noble, but somewhat misguided.  Russ was right; what do you
do when you're supplied with a library that's in C only?  You need
some way to interface with it.  Sure, you might build some sort of
network server that provides a file hierarchy for accessing the
functionality of the library, but sometimes (often) that's neither
possible nor warranted; calling a C routine from C++ is really trivial.
It'd be a step in the wrong direction to build a network server for it
just so I could call a function.  It's less trivial in Python, but
still easy.

> managing application complexity by building a more complex language
> seems a tad misguided.

Don't confuse managing complexity with eliminating complexity.
Building exception handling packages for C is introducing complexity
that doesn't exist when you use a language that supports exceptions
natively.  You aren't ``building'' a more complex language necessarily,
but rather making use of a pre-existing language that provides
functionality you'd have to otherwise build yourself.  In the C example,
you're trying to manage complexity.  In the `other language' example,
you're eliminating it.  Similarly with things like generic dictionary
objects; building hash tables in C is easy, but tedious and thus error
prone.  It adds complexity that wouldn't otherwise exist if I had a
generic container object.

> in this day and age, w/ all the talk going into "emergent behaviors",
> complex systems, etc, i'm surprised to hear people arguing for monolithic
> designs that specify brittle internal procedure and process, rather than
> simple designs that define simple interactions.

You can't make *everything* modular.  Or, rather, you might be able to
but it might not be the best idea.  Consider the fmt library; you could
define a network server just to handle I/O, and pass messages to it,
but why?  It's much easier and more intuitive to call print() and have
it do the work itself.  (Of course, in effect, the kernel acts kind of
like a network server that does the real work).  Or a more basic
example, calculating a square root.  Does it make sense to pass a
floating point number over the network to a server that does that and
then returns the result?  Not really, unless you're doing something
really specialized.

Of course, the above two examples are *really* contrived, and I'd go so
far as to say kind of stupid, but they illustrate a general idea:
sometimes it's just not worth it to make things more modular than they
have to be.

	- Dan C.

Re: [9fans] same functions everywhere

[Dan Cross]

> You guys are headed down the wrong track.
>
> The right way to program is with small modules written in several
> different languages which are meant for specific purposes.

Uhh, that's what I said, no?

	- Dan C.

Re: [9fans] same functions everywhere

[Joel Salomon]

> > > C doesn't need a low-level string type, nor does it need exceptions; what
> > > programmers who are looking for those things need to do is look for
> > > another language.
> >
> > And what language is going to give it to them?  C++?  Ha.  Ha ha ha.
>
> No, Limbo.
 From http://www.vitanuova.com/inferno/4e/limbo1.html:

> We have added exception handling to the Limbo language, replacing
> sys->rescue etc. This is intended to make it more straightforward to
> write fault-tolerant subsystems.
clip..
> The source changes to Limbo applications are relatively small, and the
> result is tidier.

Is there any data available on the exception handling in the new Limbo?
(syntax, implementation, etc)

I'd like to see what a "good" (in labs/vitanuova developer's view)
implimentation of exceptions looks like.

--Joel

Re: [9fans] same functions everywhere

[Scott Schwartz]

> No, Limbo.

How do you write a generic sort function in Limbo?

Re: [9fans] same functions everywhere

[Dan Cross]

> > No, Limbo.
>
> How do you write a generic sort function in Limbo?

I had fun once writing a set of modules that allowed me to plug in
different sorting algorithms really easily at run time.  But you're
talking about what you're sorting, not how you're sorting it.  I
suspect games could be played with modules; maybe not, but the work
on parametric polymorphism that's being implemented for consideration
for Inferno 4th edition looks promising.

	- Dan C.

http://www.vitanuova.com/inferno/4e/limbo2.html

Re: [9fans] same functions everywhere

[rog]

> How do you write a generic sort function in Limbo?

there are several ways, most of which would be considered too
heavyweight for a simple sort, but which can be fine for larger
operations when generic behaviour is required (channels and modules
both provide different kinds of dynamic coupling).

as dan says, the new parametric polymorphism will provide a more
conventional way to do it: it's not *completely* generic (the
polymorphism only works on ref adts), but fine for many purposes.

to be honest, low level generic functionality like that doesn't seem
to be actually used *that* often.  (it's fairly unusual to need to
sort more than one kind of thing in a given module).

to be honest, where i've needed to sort something, i just paste in the
following code:

sort(a: array of T)
{
	mergesort(a, array[len a] of T);
}
mergesort(a, b: array of T)
{
	r := len a;
	if (r > 1) {
		m := (r-1)/2 + 1;
		mergesort(a[0:m], b[0:m]);
		mergesort(a[m:], b[m:]);
		b[0:] = a;
		for ((i, j, k) := (0, m, 0); i < m && j < r; k++) {
			if(greater(b[i], b[j]))
				a[k] = b[j++];
			else
				a[k] = b[i++];
		}
		if (i < m)
			a[k:] = b[i:m];
		else if (j < r)
			a[k:] = b[j:r];
	}
}

and define suitable values for T and greater(),
e.g.
T: type int;
greater(a, b: int): int
{
	return a>b;
}

the function itself is byte-for-byte identical with the other places
it's used, and well debugged.

since the actual code doesn't need to change at all, it's easily
verified as being the same as that in other places (and easily
searched for should a bug emerge.  there are a few.

i dislike cut&paste code in other circumstances, but this seems
different (as the code itself doesn't change, and the interface is
very narrow).  maybe i'm hopelessly misguided!

  cheers,
    rog.

PS. the other dynamic features of limbo mean *far* more
to me in terms of writing re-usable, re-applicable and
understandable, reasonable code than the lack of polymorphism.

Re: [9fans] same functions everywhere

[Dan Cross]

> to be honest, where i've needed to sort something, i just paste in the
> following code:
>
> [snip]
>
> and define suitable values for T and greater(),
> e.g.
> T: type int;
> greater(a, b: int): int
> {
> 	return a>b;
> }
>
> the function itself is byte-for-byte identical with the other places
> it's used, and well debugged.
>
> since the actual code doesn't need to change at all, it's easily
> verified as being the same as that in other places (and easily
> searched for should a bug emerge.  there are a few.
>
> i dislike cut&paste code in other circumstances, but this seems
> different (as the code itself doesn't change, and the interface is
> very narrow).  maybe i'm hopelessly misguided!

This is fine, but one question I have is why cut and paste instead of
putting sort() and mergesort() into their own file and then including
it after defining T and greater()?  Just curious.

	- Dan C.

Re: [9fans] same functions everywhere

[rog]

> This is fine, but one question I have is why cut and paste instead of
> putting sort() and mergesort() into their own file and then including
> it after defining T and greater()?  Just curious.

lack of surprises.  if i see that a source file has been included, i
have no idea what names the namespace has been polluted with.

one thing that's particularly nice about limbo is that, with the
necessary exception of module names, if i see a name referred to, i
can find out what it refers to very quickly and surely in the local
source file (defined locally, or explicitly imported from a module).

the moment i start including external source code, i'm again awash in
a sea of uncertainty.

much better to explicitly include the code: it keeps the code
dependencies as narrow as the module interfaces that have been
included, which are easy to understand, well-defined and well-behaved
(no callbacks, for example).

whenever i've had to make significant changes to an interface that's
used by many modules, the fact that all dependencies are explicitly
defined, and all names explicitly declared has made life soooo much
easier and less error-prone.  it makes for code that is much more
malleable and reusable (despite the apparent contradiction with Limbo
being such a strongly typed language).

sorry, this has veered way off topic!

Re: [9fans] same functions everywhere

[Dan Cross]

> > This is fine, but one question I have is why cut and paste instead of
> > putting sort() and mergesort() into their own file and then including
> > it after defining T and greater()?  Just curious.
>
> lack of surprises.  if i see that a source file has been included, i
> have no idea what names the namespace has been polluted with.

Granted, but as you noted yourself, this is a rather special case.
Anyway, I was just curious.

> sorry, this has veered way off topic!

Indeed it has, but that was a great explanation.  Thanks, Rog.

	- Dan C.

Re: [9fans] same functions everywhere

[Charles Forsyth]

>>Is there any data available on the exception handling in the new Limbo?
>>(syntax, implementation, etc)

i was planning to post my thoughts about the topic,
but i haven't had a chance to compose it yet.  i agreed with rob's
comments.  yet i had Limbo extended to support exceptions in
the language (they were already in the system).  is there a contradiction?
not really, but that's the bit i haven't had time to write yet!
i'll try to find time to do it tomorrow.

Re: [9fans] same functions everywhere

[Douglas A. Gwyn]

Dan Cross wrote:
> Sounds like a good candidate for writing in C++ or a similar language.

No, that was not an option.

Re: [9fans] same functions everywhere

[boyd, rounin]

From: "rob pike, esq." <rob@mightycheese.com>
> i'm not a fan of exceptions. good programming
> can trump them every time; bad exception handling
> can destroy a program.  they're an interesting idea
> but i judge them a failure.

sounds like a 'class 1 [dis]agreement' to me ...

--
The Beretta 92FS -- don't leave home without it ...

Re: [9fans] exception handling caused the Ariane 5 rocket accident

[Anssi Porttikivi]

rob@mightycheese.com (rob pike, esq.) wrote in message news:<2c48f76cc19c912eb71595a28defda34@mightycheese.com>...

[About "exceptions":]

> > Basically, it's a way to impose order on chaos.
>
> and replace it with a mysterious, hard to understand
> mechanism with a tendency to overlay a program's
> structure with confusing, noisy error-handling
> details.
>
> i'm not a fan of exceptions. good programming
> can trump them every time; bad exception handling
> can destroy a program.  they're an interesting idea
> but i judge them a failure.
>
> -rob

Lack of understanding and too much reliance on the existence of upper
level exception handling in the Ada language caused the blow up of the
Ariane 5 rocket in 1996:

"The internal SRI software exception was caused during execution of a
data conversion from 64-bit floating point to 16-bit signed integer
value. The floating point number which was converted had a value
greater than what could be represented by a 16-bit signed integer.
This resulted in an Operand Error. The data conversion instructions
(in Ada code) were not protected from causing an Operand Error,
although other conversions of comparable variables in the same place
in the code were protected." (Google, "ariane 5 failure")

C.A.R Hoare talked about this in his 1980 Turing award lecture:

"...Gradually, these [Ada design] objectives have been been sacrificed
in favor of power, supposedly achieved by a plethora of features and
notational conventions, many of them unnecessary and some of them,
like exception handling, even dangerous..."

"...Do not allow this language (Ada) in its present state to be used
in applications where reliability is critical, i.e., nuclear power
stations, cruise missiles, early warning systems, anti-ballistic
missile defense systems. The next rocket to go astray as a result of a
programming language error may not be an exploratory space rocket on a
harmless trip to Venus: It may be a nuclear warhead exploding over one
of our cities..." (Google, "hoare turing")

Re: [9fans] exception handling caused the Ariane 5 rocket accident

[Douglas A. Gwyn]

Anssi Porttikivi wrote:
> "The internal SRI software exception was caused during execution of a
> data conversion from 64-bit floating point to 16-bit signed integer
> value. The floating point number which was converted had a value
> greater than what could be represented by a 16-bit signed integer.
> This resulted in an Operand Error. The data conversion instructions
> (in Ada code) were not protected from causing an Operand Error,
> although other conversions of comparable variables in the same place
> in the code were protected." (Google, "ariane 5 failure")

It doesn't sound like a problem with exception handling as such;
if appropriate layered error recovery strategies were in place
at all, such a low-level error should have been recovered from.
The real problem sounds like a mismatch between an Ada run-time
system and a programmer's assumptions.

Re: [9fans] exception handling caused the Ariane 5 rocket accident

[Dan Cross]

Actually, the problem was that they assumed they could use a piece of
software from Ariane-4 on Ariane-5 without modification.  Bad
assumption.

Exception handling is interesting, and potentially useful, because it
allows one to scope error recovery in an essentially dynamic way.  But
the ugly fact is that it's often abused and made to look like a
glorified goto with a side effect.  When used by a competent programmer,
it's fine; when used by the average programmer, it's a disaster waiting
to happen because, frankly, the average programmer isn't disciplined
enough to use the mechanism appropriately.

I guess that, as other's have said, it boils down to the programmer.
Rob Pike or Russ Cox can get away with building clean code that doesn't
use exceptions because they're virtuosos.  Doug Gwyn can get away with
using exceptions because he's a virtuoso.  The average programmer is
not a virtuoso, and more often than not messes up either way.

	- Dan C.

Re: [9fans] exception handling caused the Ariane 5 rocket accident

[Mário Amado Alves]

> Lack of understanding and too much reliance on the existence of upper
> level exception handling in the Ada language caused the blow up of the
> Ariane 5 rocket in 1996: ...

Not quite. Exception handling is just a tool, and it is not the tool's
fault that it was misused. The Ariane-5 error was more on the
requirements specification side. Namely code from Ariane-4 was reused
on the (wrong) assumption that is was 'compatible' with the Ariane-5
environment. "Lack of understanding" yes. "Too much reliance on the
existence of upper level exception handling" I doubt.

--Marius

Re: [9fans] exception handling caused the Ariane 5 rocket accident

[boyd, rounin]

would somebody please read feynman's shuttle investigation?

Re: [9fans] exception handling caused the Ariane 5 rocket accident

[Jim Choate]

On Thu, 15 May 2003, boyd, rounin wrote:

> would somebody please read feynman's shuttle investigation?

It wasn't Feynman's investigation, he was on the review board. I assume
you're talking about his great(!) quote about technology and fooling
Nature, that was not a popular sentiment of the board. The only reason it was
included was his fame.


 --
    ____________________________________________________________________

      We are all interested in the future for that is where you and I
      are going to spend the rest of our lives.

                              Criswell, "Plan 9 from Outer Space"

      ravage@ssz.com                            jchoate@open-forge.org
      www.ssz.com                               www.open-forge.org
    --------------------------------------------------------------------

Re: [9fans] exception handling caused the Ariane 5 rocket accident

[boyd, rounin]

From: "Jim Choate" <ravage@einstein.ssz.com>
> It wasn't Feynman's investigation, he was on the review board. I assume
> you're talking about his great(!) quote about technology and fooling
> Nature, that was not a popular sentiment of the board. The only reason it was
> included was his fame.

i know i shouldn't even attempt to enter into this, but ...

he talked to the engineers.  they said the probability of a loss of
vehicle was between 1 in 100-300 flights.  upper level management
had been quoting 1 in a million [maybe they were guns 'n roses fans?].

there have been, say, 150 flights and 2 'loss of vehicle' incidents.

have i been too cryptic?

[9fans] Re: exception handling caused the Ariane 5 rocket accident

[Jim Choate]

On Thu, 15 May 2003, boyd, rounin wrote:

> From: "Jim Choate" <ravage@einstein.ssz.com>
> > It wasn't Feynman's investigation, he was on the review board. I assume
> > you're talking about his great(!) quote about technology and fooling
> > Nature, that was not a popular sentiment of the board. The only reason it was
> > included was his fame.
>
> i know i shouldn't even attempt to enter into this, but ...
>
> he talked to the engineers.  they said the probability of a loss of
> vehicle was between 1 in 100-300 flights.  upper level management
> had been quoting 1 in a million [maybe they were guns 'n roses fans?].
>
> there have been, say, 150 flights and 2 'loss of vehicle' incidents.
>
> have i been too cryptic?

Irrelevant strawman. It wasn't 'Feynman's' investigation; that assertion
is a misrepresentation in the spirit of Feynmans quote in fact. He was a
member of a board. The investigation was run by NASA.

As to the odds of failure, there was much more involved in the
investigation than this simple spindocotorism. There was a travesty of
errors commited because underlings wanted to tell their bosses what they
wanted to hear.

You might try reading the report, I can loan you my copy.


 --
    ____________________________________________________________________

      We are all interested in the future for that is where you and I
      are going to spend the rest of our lives.

                              Criswell, "Plan 9 from Outer Space"

      ravage@ssz.com                            jchoate@open-forge.org
      www.ssz.com                               www.open-forge.org
    --------------------------------------------------------------------

Re: [9fans] Re: exception handling caused the Ariane 5 rocket accident

[boyd, rounin]

> You might try reading the report, I can loan you my copy.

been there, done that, got the book[s] ...

Re: [9fans] Re: exception handling caused the Ariane 5 rocket accident

[northern snowfall]

>
>
>You might try reading the report, I can loan you my copy.
>
I'd like to read the report.
Don

>

Re: [9fans] same functions everywhere

[boyd, rounin]

From: "Douglas A. Gwyn" <DAGwyn@null.net>
> Done right, the main advantages are:
>
> (a) uniform, tested error handling instead of ad-hoc
> (b) ensures reasonable default when user neglects to
> deal with the possibility of failre
> (c) no need for explicit tests of function error
> returns
>
> Basically, it's a way to impose order on chaos.

if 'done right'.  i'm not sure 'C' needs it.  error handling in 'C' is a nightmare
and most code gets it wrong.  i want 'C' to remain a powerful tool that does
_exactly_ what i tell it to do;  a Gerber Stilletto Backup knife -- the
thing is damn dangerous, but it does _exactly_ what i want it to do.

user mode code should not be written in 'C' -- choose a better tool for
the job, err limbo anyone?  'C' should only be used on embedded
systems, such as the kernel.  i can code my own exceptions trivially,
unlike some of the hideously complex and twisted maze of non
local gotos, oops exceptions, which various other 'programming languages'
get wrong.

strings are a real pain in 'C' so i wrote a library for 'infinite' strings; type
a buncha extra characters and you get no buffer overflows and when you
run out of memory the library spits an error message and calls exit(2) -- end
of story.

just obey:

    for (p = m; *p != '\0': p++) ...

i don't think it's on-line anymore and given i'm at:

    33V UE 29764
    MGRS   00890
    WGS 84

i can't check it out, but it is spinning on this local disk; a 256k bundle [which it is a
small part of] is just too big to post to the list.

give me IP (sic) or give me death ...
--
The Beretta 92FS -- don't leave home without it ...

Re: [9fans] same functions everywhere

[Taj Khattra]

On Thu, May 01, 2003 at 01:21:19PM -0400, rsc@plan9.bell-labs.com wrote:
> There are some programs that use the same method,
> but it's best used in moderation.

e.g. squint, rob's Newsqueak interpreter

-taj

Re: [9fans] same functions everywhere

[FJ Ballesteros]

Yes. I think one of the programs in sources /nemo includes a
util.[ch] that has one of such packages.

Joel Salomon wrote:

> On Thu, 1 May 2003, Russ Cox wrote:
>
>>You're preaching to the choir.  Look at the Plan 9 kernel.
>>
>
> So can the kernel's "exceptions" be packaged in library form for
> applications?
>
> --Joel
>
>

Re: [9fans] same functions everywhere

[Boyd Roberts]

> Doug is thinking ahead to C1x.

i hope the lessons of python style exception handling have been learned.

--
The Beretta 92FS -- don't leave home without it ...

Re: [9fans] same functions everywhere

[Boyd Roberts]

From: "Douglas A. Gwyn" <DAGwyn@null.net>
> It's much, much easier when the library functions throw
> exceptions.  That way the application can handle them any
> way it wants (or allow default handling to occur, normally
> a fatal error), and the same utility library can be used
> unchanged with any application.

hmm, exceptions can be a nightmare, if they turn out to be
a 'nasty set of  nested non local gotos' -- ouch.

but if they're done 'right', then ok ...

--
The Beretta 92FS -- don't leave home without it ...

[9fans] ndb/local

[ron minnich]

OK, it's probably just me, but this ndb/local stuff is getting on my
nerves.

I have a new T21 just loaded from the CDROM. I have no dhcp. I want to get
the hostname set to P9. I want to set it from local files only. Hints from
the wiki imply that if you have a sys= entry with the ether address set,
the various bits of software will Do The Right Thing for setting up the
network, but that is not working for me.

Here is ndb/local after the database= section:

ipnet=ccstar ip=10.128.0.0 ipmask=255.255.0.0
	ipsubmask=255.255.0.0 dnsdomain=ccstar.lanl.gov
	ipgw=10.128.10.241 dns=10.128.10.241
	auth=p9 fs=p9 dom=p9 authdom=p9

ip=10.128.207.112 sys=p9 ether=0010a48975c5 dom=p9 authdom=p9

At the head of /rc/bin/termrc I have:

sysname=p9

/dev/sysname is set to p9

ip/ipconfig would, I thought, take the sysname and set all the ipifc stuff
up correctly. No dice. So I did it by hand in termrc:
ip/ipconfig -g 10.0.10.241 10.128.207.112 255.255.0.0

but /net/ipifc/0 still has an empty address.

OK, what dumb thing am I doing here? Multiple dumb things, probably. Is
there a way to get reasonable debugging done when I screw up ndb/local?

thanks

ron

Re: [9fans] ndb/local

[David Presotto]

That's what I'm trying to address now but I'm not coding fast enough.

ip/ipconfig -g 10.0.10.241 ether /net/ether0 10.128.207.112 255.255.0.0

should work.  putting stuff in /lib/ndb/local does nothing for you
vis a vis ipconfig unless you've got a plan 9 server for you serving
dhcp.

Re: [9fans] ndb/local

[ron minnich]

On Tue, 22 Apr 2003, David Presotto wrote:

> That's what I'm trying to address now but I'm not coding fast enough.
>
> ip/ipconfig -g 10.0.10.241 ether /net/ether0 10.128.207.112 255.255.0.0

any reason to leave that >/dev/null in there? what purpose does it serve?

ron

Re: [9fans] ndb/local

[David Presotto]

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

What >/dev/null?  No, I wouldn't put one there on the ipconfig
line.  WHo does?

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

From: ron minnich <rminnich@lanl.gov>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] ndb/local
Date: Tue, 22 Apr 2003 11:49:42 -0600 (MDT)
Message-ID: <Pine.LNX.4.44.0304221149230.23833-100000@maxroach.lanl.gov>

On Tue, 22 Apr 2003, David Presotto wrote:

> That's what I'm trying to address now but I'm not coding fast enough.
>
> ip/ipconfig -g 10.0.10.241 ether /net/ether0 10.128.207.112 255.255.0.0

any reason to leave that >/dev/null in there? what purpose does it serve?

ron

Re: [9fans] ndb/local

[ron minnich]

On Tue, 22 Apr 2003, David Presotto wrote:

> What >/dev/null?  No, I wouldn't put one there on the ipconfig
> line.  WHo does?

by /rc/bin/termrc has the ipconfig command as this:

ipconfig blabhblbah > /dev/null [2>=1]

ron

Re: [9fans] ndb/local

[ron minnich]

On Tue, 22 Apr 2003, David Presotto wrote:

> What >/dev/null?  No, I wouldn't put one there on the ipconfig
> line.  WHo does?

this leads me to wonder: how out of sync are the distribution bits like
termrc and what you guys run? seems like maybe a bit?

ron

Re: [9fans] ndb/local

[Russ Cox]

> this leads me to wonder: how out of sync are the distribution bits like
> termrc and what you guys run? seems like maybe a bit?

the >/dev/null was added at some point for
reasons now forgotten, probably to silence
ipconfig when there was no ethernet card.

for the most part, we try to keep our own
file server and sources synchronized.
termrc and cpurc are not, since we have
various local customizations in both.

ipconfig is a good example -- there's no
ipconfig in our own termrc, because termrc
serves hosts booting off the network, so
they'd better have set up their ip settings
already!

the vast majority of the files are in sync.
we have a script that watches these things.

Re: [9fans] ndb/local

[David Presotto]

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

We (the labs) almost always boot and run off a remote file
server so we don't even have an ipconfig in our termrc.

That is a dichotomy between most of our users and us.

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

From: ron minnich <rminnich@lanl.gov>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] ndb/local
Date: Tue, 22 Apr 2003 12:30:27 -0600 (MDT)
Message-ID: <Pine.LNX.4.44.0304221230060.23833-100000@maxroach.lanl.gov>

On Tue, 22 Apr 2003, David Presotto wrote:

> What >/dev/null?  No, I wouldn't put one there on the ipconfig
> line.  WHo does?

this leads me to wonder: how out of sync are the distribution bits like
termrc and what you guys run? seems like maybe a bit?

ron

Re: [9fans] ndb/local

[andrey mirtchovski]

On Tue, 22 Apr 2003, David Presotto wrote:

> We (the labs) almost always boot and run off a remote file
> server so we don't even have an ipconfig in our termrc.
>
> That is a dichotomy between most of our users and us.

what's the biggest number of users that your file servers handle? we're
yet to see scalability numbers for plan9 (except when Russ mentioned that
downloads from your web site were hitting the file server pretty bad and he
had to switch to ramfs).

seeing how many simulated users a "normal" plan9 setup can reasonably hold
would be interesting...

Re: [9fans] ndb/local

[David Presotto]

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

No maximums.  Here's a who on emelie our mail file server:

 34:        ndb    il!135.104.9.11!14850      0      0 (1,3) (-615121,3124,-6876) (55,255,168,0)
 31:        rsc     il!135.104.9.23!6435      0      0 (1,3) (-2444,8056,-1944) (5886,288,144,0)
 28:       none    il!135.104.9.29!28508      0      0 (1,3) (-1049,5752,-1236) (2874,235,117,0)
 27:       none    il!135.104.9.55!10848      0      0 (1,3) (-3294,4108,-3468) (3208,203,98,0)
 26:       none   il!135.104.9.129!11273      0      0 (1,3) (-1603,6400,-1848) (8959,365,200,0)
 25:       none     il!135.104.9.2!28284      0      0 (1,3) (-17593,1252,-8748) (406,547,214,0)
 24:        jmk     il!135.104.9.16!6208      0      0 (1,3) (163,1384,-84) (3170,414,192,0)
 23:     mjcoss   il!135.104.52.12!11579      0      0 (1,3) (-3852140,232,-9768) (2037,179,76,0)
 22:        rsc     il!135.104.9.16!6209      0      0 (1,3) (-1094118602,8044,-1956) (800,400,200,0)
 21:        ehg    il!135.104.9.69!27142      0      0 (1,3) (-4887,1936,-5088) (1814,258,138,0)
 20:       none     il!135.104.9.2!28283      0      0 (1,3) (-1012,3364,-1260) (3202,481,177,0)
 19:       sape    il!135.104.9.67!16524      0      0 (1,3) (-24589544,7528,-2472) (5592,283,122,0)
 18:        rsc     il!135.104.9.23!6436      0      0 (1,3) (-1452446167,1816,-8184) (721,413,212,0)
 17:        sys    il!135.104.9.15!31929      0      0 (1,3) (-536757,652,-9348) (3051,455,222,0)
 16:       none    il!135.104.9.15!31936      0      0 (1,3) (-183238,976,-9024) (2585,258,125,0)
 15:       upas    il!135.104.9.15!31923      0      0 (1,3) (-222,6196,-468) (1655,410,191,0)
 14:         pb     il!135.104.9.44!9720      0      0 (1,3) (-3890,5128,-4140) (800,400,200,0)
 13:       none     il!135.104.9.6!14336      0      0 (1,3) (-89614172,6652,-3348) (4262,423,209,0)
 12:        ynl     il!135.104.9.6!14329      0      0 (1,3) (198,5584,-12) (260,335,139,293)
 11:       none    il!135.104.9.67!16521      0      0 (1,3) (-2198,6484,-2448) (800,400,200,0)
 10:      hobby   il!135.104.52.81!14329      0      0 (1,3) (-6097,5512,-4488) (1254,537,241,0)
  9:       sape    il!135.104.9.91!19735      0      0 (1,3) (-11194,4876,-5124) (2750,273,145,0)
  8:   presotto    il!135.104.9.65!11393      0      0 (1,3) (-6661,9052,-948) (233,315,224,0)
  7:        rsc     il!135.104.9.6!14335      0      0 (1,3) (-37851961,1780,-8220) (89,416,222,0)
  6:       none    il!135.104.9.73!15374      0      0 (1,3) (-9052,8068,-1920) (458,321,193,0)
  5:        rsc    il!135.104.9.92!28844      0      0 (1,3) (-17245079,1420,-8580) (7752,236,105,0)
  4:        jmk   il!135.104.9.222!10146      0      0 (1,3) (-11102,736,-9264) (800,400,200,0)
  3:       none    il!135.104.9.92!28842      0      0 (1,3) (-7463,8500,-1500) (3625,477,236,0)
  2:        rsc   il!135.104.9.222!10147      0      0 (1,3) (-1374505802,1900,-8100) (800,400,200,0)
  1:       upas     il!135.104.9.7!11691      0      0 (1,3) (-383865,3904,-6096) (2320,274,146,0)
  0:        adm                  console      0      0

It just shows connections from other machines, not users on a system.  We're probably
at our low point for number of users.  We've only got 30 or so users logged in these
days at any one time.

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

From: andrey mirtchovski <mirtchov@cpsc.ucalgary.ca>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] ndb/local
Date: Tue, 22 Apr 2003 13:41:32 -0600 (MDT)
Message-ID: <Pine.LNX.4.44.0304221337450.21774-100000@fbsd.cpsc.ucalgary.ca>

On Tue, 22 Apr 2003, David Presotto wrote:

> We (the labs) almost always boot and run off a remote file
> server so we don't even have an ipconfig in our termrc.
>
> That is a dichotomy between most of our users and us.

what's the biggest number of users that your file servers handle? we're
yet to see scalability numbers for plan9 (except when Russ mentioned that
downloads from your web site were hitting the file server pretty bad and he
had to switch to ramfs).

seeing how many simulated users a "normal" plan9 setup can reasonably hold
would be interesting...

Re: [9fans] ndb/local

[Charles Forsyth]

>> 16:       none    il!135.104.9.15!31936      0      0 (1,3) (-183238,976,-9024) (2585,258,125,0)

i noticed there were quite a few `none's in the list.
is this a new ploy to avoid attention from Lucent anti-HR?
a bit like Ulysses in reverse: `lay off none!'

Re: [9fans] ndb/local

[David Presotto]

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

No, it just means that the attach was from none.  It probably was
done by a daemon running as none before it switched authenticated
and switched to something else.

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

From: Charles Forsyth <forsyth@caldo.demon.co.uk>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] ndb/local
Date: Tue, 22 Apr 2003 21:27:55 +0100
Message-ID: <471b30ebe09bf60ae8ca5e9088ddcc54@caldo.demon.co.uk>

>> 16:       none    il!135.104.9.15!31936      0      0 (1,3) (-183238,976,-9024) (2585,258,125,0)

i noticed there were quite a few `none's in the list.
is this a new ploy to avoid attention from Lucent anti-HR?
a bit like Ulysses in reverse: `lay off none!'

Re: [9fans] ndb/local

[ron minnich]

hmm. we're experimenting with v9fs here --> 1023 nodes to one server.

We'll keep ya posted. I know it's not plan 9, it's linux, but the 9p2000
protocol is really good stuff and it was nice to see those 1023 mounts
even work at all :-)

ron

Re: [9fans] ndb/local

[Scott Schwartz]

| We'll keep ya posted. I know it's not plan 9, it's linux, but the 9p2000
| protocol is really good stuff and it was nice to see those 1023 mounts
| even work at all :-)

I'm very interested to hear how this works out, especially compared with
NFS on the same system.

Re: [9fans] ndb/local

[andrey mirtchovski]

On Tue, 22 Apr 2003, Scott Schwartz wrote:

> I'm very interested to hear how this works out, especially compared with
> NFS on the same system.

i think ron considers it an insult to run NFS on his cluster. doubtful he's
even tried to :)

Re: [9fans] ndb/local

[ron minnich]

On Tue, 22 Apr 2003, Scott Schwartz wrote:

> | We'll keep ya posted. I know it's not plan 9, it's linux, but the 9p2000
> | protocol is really good stuff and it was nice to see those 1023 mounts
> | even work at all :-)
>
> I'm very interested to hear how this works out, especially compared with
> NFS on the same system.

I would never in a million years ask NFS to even try to do those mounts
:=)

ron

Re: [9fans] ndb/local

[Russ Cox]

It's worth noting that what the ramfs fixed was
hardly normal behavior for a user.  Many many
people reading the same 60MB file over and over
again is atypical for interactive users.

We've never pushed very hard on caching, because
it tends to create more problems than it solves,
and so it shows for things like this.  The ramfs
just acts as enough of a cache to keep the network
traffic to the file server down.  (It also acts as
enough of a cache to cause problems once in a while.)

One thing that would be nice is if we could figure
out that all the different /bin/rc's running on the
system really are the same binary and then share text
space for them.  It's not clear how to do that, though.
You'd have to assume that each mount gave back the
same file system, which isn't always true.

Re: [9fans] ndb/local

[Skip Tavakkolian]

> That is a dichotomy between most of our users and us.

Not all users :)

Re: [9fans] ndb/local

[Skip Tavakkolian]

>> That is a dichotomy between most of our users and us.
>
> Not all users :)

Good god! how could I have missed it.  Please ignore.

Re: [9fans] ndb/local

[FJ Ballesteros]

dont you have to say something like ether in the args of ipconfig?
I dont remember and dont have my laptop here to check, sorry.

ron minnich wrote:

> OK, it's probably just me, but this ndb/local stuff is getting on my
> nerves.
>
> I have a new T21 just loaded from the CDROM. I have no dhcp. I want to get
> the hostname set to P9. I want to set it from local files only. Hints from
> the wiki imply that if you have a sys= entry with the ether address set,
> the various bits of software will Do The Right Thing for setting up the
> network, but that is not working for me.
>
> Here is ndb/local after the database= section:
>
> ipnet=ccstar ip=10.128.0.0 ipmask=255.255.0.0
> 	ipsubmask=255.255.0.0 dnsdomain=ccstar.lanl.gov
> 	ipgw=10.128.10.241 dns=10.128.10.241
> 	auth=p9 fs=p9 dom=p9 authdom=p9
>
> ip=10.128.207.112 sys=p9 ether=0010a48975c5 dom=p9 authdom=p9
>
> At the head of /rc/bin/termrc I have:
>
> sysname=p9
>
> /dev/sysname is set to p9
>
> ip/ipconfig would, I thought, take the sysname and set all the ipifc stuff
> up correctly. No dice. So I did it by hand in termrc:
> ip/ipconfig -g 10.0.10.241 10.128.207.112 255.255.0.0
>
> but /net/ipifc/0 still has an empty address.
>
> OK, what dumb thing am I doing here? Multiple dumb things, probably. Is
> there a way to get reasonable debugging done when I screw up ndb/local?
>
> thanks
>
> ron
>
>
>
>

Re: [9fans] ndb/local

[ron minnich]

On Tue, 22 Apr 2003, FJ Ballesteros wrote:

> dont you have to say something like ether in the args of ipconfig?
> I dont remember and dont have my laptop here to check, sorry.

I told you it was me being dumb :-)

It'll be nice when ipconfig uses ndb/local. I am assuming that is what
Dave was pounding on.

ron

Re: [9fans] ndb/local

[David Presotto]

>
> It'll be nice when ipconfig uses ndb/local. I am assuming that is what
> Dave was pounding on.
>

...among other things.  I'm going to make ether address the last resort.
the problem is that with the same ether address you can at different times
(or at least I do) connect to very different networks.  I'm going to use
the args first, dhcp second, and ether as last resort.  I'm also building
a tool that goes through your interfaces, asks you questions, and tries
to create a /lib/ndb/local file and an rc script to start ip.  I have
a lot of samples from the ways I connect to work, ISP's, etc.  I'm hoping
to see a few more.

Re: [9fans] ndb/local

[Scott Schwartz]

| ...among other things.  I'm going to make ether address the last resort.
| the problem is that with the same ether address you can at different times
| (or at least I do) connect to very different networks.

The nicest things about Apple's OSX is the "location" menu.  You tell
your laptop where you are, and it sets up the network accordingly.
Some locations use ethernet, others the modem, still others airport;
some could use more than one, so they search in a given order.  It uses
DHCP or static information, as requested for that location.

Re: [9fans] ndb/local

[David Presotto]

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

good idea

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

From: Scott Schwartz <schwartz@bio.cse.psu.edu>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] ndb/local
Date: Tue, 22 Apr 2003 18:44:53 -0400
Message-ID: <20030422224453.5766.qmail@g.bio.cse.psu.edu>

| ...among other things.  I'm going to make ether address the last resort.
| the problem is that with the same ether address you can at different times
| (or at least I do) connect to very different networks.

The nicest things about Apple's OSX is the "location" menu.  You tell
your laptop where you are, and it sets up the network accordingly.
Some locations use ethernet, others the modem, still others airport;
some could use more than one, so they search in a given order.  It uses
DHCP or static information, as requested for that location.

Re: [9fans] ndb/local

[Charles Forsyth]

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

it seemed to me you might just as well build such policy
into termrc and cpurc using for instance `{ndb/query ether ...}, where
it's more obvious how to tune it to special requirements (eg, the
same ether on many networks), rather than putting it (back?)
in ipconfig where it's slightly harder to change because you need
to understand more surrounding code.

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

From: David Presotto <presotto@closedmind.org>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] ndb/local
Date: Tue, 22 Apr 2003 18:40:48 -0400
Message-ID: <594ddae1154d167c950d93d56153bd4e@plan9.bell-labs.com>

>
> It'll be nice when ipconfig uses ndb/local. I am assuming that is what
> Dave was pounding on.
>

...among other things.  I'm going to make ether address the last resort.
the problem is that with the same ether address you can at different times
(or at least I do) connect to very different networks.  I'm going to use
the args first, dhcp second, and ether as last resort.  I'm also building
a tool that goes through your interfaces, asks you questions, and tries
to create a /lib/ndb/local file and an rc script to start ip.  I have
a lot of samples from the ways I connect to work, ISP's, etc.  I'm hoping
to see a few more.

Re: [9fans] fast compilers

[Theo de Raadt]

and since it is gpl, we cannot, and will not switch to it.

i have tried to make this clear to various people, in an attempt to
convince them that a bigger picture view would be good.  if it was bsd
licensed, everyone could use it, and we would have some competition
for gcc.  we would try to improve it -- we would try to switch to it.

but if it is gpl, we will not.

> mirtchov@cpsc.ucalgary.ca wrote:
> > to quote:
> [...]
> > > > gcc 3.2.1 is TWICE AS SLOW as gcc 2.95, and the more recent development
> [...]
> > I wish the plan9 compiler was 100% free.  It's blazingly fast.
>
> the inferno version of the plan 9 C compiler, which is almost
> identical to the plan 9 version, is distributed under the same
> license as gcc.
>
>   cheers,
>     rog.
>

Re: [9fans] fast compilers

[Dan Cross]

> To: rog@vitanuova.com
> Cc: 9fans@cse.psu.edu
      ^^^^^
> Subject: Re: [9fans] fast compilers
> From: Theo de Raadt <deraadt@cvs.openbsd.org>
>
> and since it is gpl, we cannot, and will not switch to it.
>
> i have tried to make this clear to various people, in an attempt to
> convince them that a bigger picture view would be good.  if it was bsd
> licensed, everyone could use it, and we would have some competition
> for gcc.  we would try to improve it -- we would try to switch to it.
>
> but if it is gpl, we will not.
>
> > mirtchov@cpsc.ucalgary.ca wrote:
> > > to quote:
> > [...]
> > > > > gcc 3.2.1 is TWICE AS SLOW as gcc 2.95, and the more recent development
> > [...]
> > > I wish the plan9 compiler was 100% free.  It's blazingly fast.
> >
> > the inferno version of the plan 9 C compiler, which is almost
> > identical to the plan 9 version, is distributed under the same
> > license as gcc.
> >
> >   cheers,
> >     rog.
> >

9fans isn't appropriate for discussions related to the licensing of
software components and their inclusions in other operating systems.
Please, keep this stuff off-list.  (In this case, Rog should have
known better.)

I should note, however, that building compilers akin to Plan 9's C
compiler shouldn't really be too hard; why hasn't anyone done it yet?
With the oodles of BSD programmers out there, I'd have thought it'd
have been done years ago.

	- Dan C.

Re: [9fans] fast compilers

[Dan Cross]

> [...]

Aww hell, that was supposed to go to de Raadt alone.

	- Dan C.

Re: [9fans] fast compilers

[Scott Schwartz]

Dan asks:
| I should note, however, that building compilers akin to Plan 9's C
| compiler shouldn't really be too hard; why hasn't anyone done it yet?

Does lcc qualify?
 http://www.cs.princeton.edu/software/lcc/

Re: [9fans] fast compilers

[Charles Forsyth]

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

it's a good piece of work, and at one time
it even had a go at implementing some of the Plan 9 extensions,
but it still requires an external assembler and linker
in the old style (in all the incarnations i've seen).

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

From: Scott Schwartz <schwartz@bio.cse.psu.edu>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] fast compilers
Date: Tue, 08 Apr 2003 02:11:15 -0400
Message-ID: <20030408061115.28990.qmail@g.bio.cse.psu.edu>

Dan asks:
| I should note, however, that building compilers akin to Plan 9's C
| compiler shouldn't really be too hard; why hasn't anyone done it yet?

Does lcc qualify?
 http://www.cs.princeton.edu/software/lcc/

Re: [9fans] fast compilers

[bwc]

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

I find the external assembler and linker to be simpler than the plan 9 *[cal] suite.
It seems more modular, easier to understand all the components.  I also find
it easy to port an assembler to a new machine than it is to mess with the internal
compiler stuff in the plan 9 C set of programs.

Was Ken's compiler an expirment in a new way of doing things?  If so
what was the verdict?  I enjoy using the compiler, but is it the
best way to do compilers?

 Brantley

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

[-- Attachment #2.1.1: Type: text/plain, Size: 220 bytes --]

it's a good piece of work, and at one time
it even had a go at implementing some of the Plan 9 extensions,
but it still requires an external assembler and linker
in the old style (in all the incarnations i've seen).

[-- Attachment #2.1.2: Type: message/rfc822, Size: 1679 bytes --]

From: Scott Schwartz <schwartz@bio.cse.psu.edu>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] fast compilers
Date: Tue, 08 Apr 2003 02:11:15 -0400
Message-ID: <20030408061115.28990.qmail@g.bio.cse.psu.edu>

Dan asks:
| I should note, however, that building compilers akin to Plan 9's C
| compiler shouldn't really be too hard; why hasn't anyone done it yet?

Does lcc qualify?
 http://www.cs.princeton.edu/software/lcc/

Re: [9fans] fast compilers

[Charles Forsyth]

i found it far easier and faster doing the powerpc and Fairchild
Clipper ports (long gone) using the balance of work in Ken's structure
than anything else i've worked with, including my own compilers
producing either text or binary.  (that's not to say ?[acl] couldn't
be improved at all, or made easier to follow and port.)

much of the advantage and speed in porting is because
only the linker really knows the binary encoding for
a particular architecture, which isolates one of the messiest
and most tedious parts.  (it's a good modular split in my experience.)
architectures that have got span- or context-dependent instructions
are much easier to handle that way.  otherwise, the compiler
or assembler--sometimes both!--end up having to duplicate
work the linker does or second-guess it.

the assembler's trivial (i often do that first to get a good feel for the architecture).
with the powerpc it was a little more work because i had to decide
what to do about all those peculiar instructions.

for a load/store architecture, it's fairly easy to get the C compiler generating
reasonable code quickly.  on the other  hand, i'm glad i didn't
need to deal with the non-load/store ones implemented (eg, x86).

for most architectures, the linker is an opcode table that drives instruction selection,
a small addressing mode classifier, and an assembler that's
a big switch statement.

i also found it easier to do the linker and produce its input
than to have to have the compiler generate
correct assembly-language text or to have to deal with typically
bizarre and equally ill-documented object and executable file formats.

in use, i actually like having all the platforms use the same dataflow syntax and order
when i write assembler support.  i make fewer mistakes moving between them.

one practical nuisance, which can i suppose be  underestimated,
is that you can't trivially recycle existing assembly-language
code (although i've had to deal with several platforms that had several
different assembly languages anyway), and it's a challenge given
the documentation to work out the mapping for some of the peculiar
ones (see powerpc comment above).

Re: [9fans] fast compilers

[Dan Cross]

> | I should note, however, that building compilers akin to Plan 9's C
> | compiler shouldn't really be too hard; why hasn't anyone done it yet?
>
> Does lcc qualify?
>  http://www.cs.princeton.edu/software/lcc/

lcc is very nice, but was ham-strung for many years by lack of a `long
long' type.  Lcc 4 fixes that, but the license terms are even worse
than for gcc.

	- Dan C.

[9fans] clwalk on open directories

[Ronald G. Minnich]

A simple question has come up: given that your are reading a directory, 
should you be able to clwalk it (i.e. do a walk with a name and a newfid). 

On my old 9p server I allowed this. u9fs does not. Details follow. 

Also I am curious as to why my earlier message was impounded as 
'suspicious' so I am trying this one more time.

ron

---------- Forwarded message ----------
Date: Sun, 2 Mar 2003 19:47:07 -0700 (MST)
From: Ronald G. Minnich <rminnich@lanl.gov>
To: 9fans@cse.psu.edu
Subject: another question on u9fs

u9fs serving; v9fs2k client; mounted at /mnt

stat /mnt/tmp/file does this:
<- Twalk tag 0 fid 0 newfid 1 nwname 1 0:tmp 
-> Rwalk tag 0 nwqid 1 0:(0000000000030300 1047737901 d) 
<- Tstat tag 0 fid 1
-> Rstat tag 0  stat 'tmp' '00000000' '00000000' '' q (0000000000030300 
1046689325 d) m 020000000777 at 1046689902 mt 1046689325 l 0 t 0 d 0
.
.
<- Topen tag 0 fid 1 mode 0
-> Ropen tag 0 qid (0000000000030300 1046689325 d) iounit 0 

(open /mnt//tmp/ for a readdir from the linux side)

<- Tread tag 0 fid 1 offset 0 count 512
-> Rread tag 0 count 499 '49000000 00000000 80a77a71 3e670b2d 00000000 
00ff0100 80a77a61 3ea77a61 3e001000 00000000 000a002e 666f6e74 2d756e69 
78080030 30303030 30326208'
<- Tread tag 0 fid 1 offset 499 count 512
-> Rread tag 0 count 507 '40000000 00000000 80decfa8 3dbf4716 00000000 
00fd0100 805a6a2f 3edecfb8 3d001000 00000000 00010078 08003030 30303031 
66340800 30303030 30316634'
.
.
.

read the directory

<- Twalk tag 0 fid 1 newfid 2 nwname 1 0:bad 
-> Rerror tag 0 ename bad use of fid

Try to stat /mnt/tmp/bad by walking from /mnt/tmp (fid 1) to bad with 
newfid 2. 

the bad use of fid is due to the fact that fid 1 is open. 

(gdb) 
432             if(fid->omode != -1){
(gdb) 
433                     seterror(tx, Ebadusefid);

(gdb) print *fid
$1 = {fid = 1, path = 0x80cc498 "/tmp", st = {st_dev = 769, __pad1 = 0, 
    st_ino = 196609, st_mode = 17407, st_nlink = 18, st_uid = 0, st_gid = 
0, 
    st_rdev = 0, __pad2 = 0, st_size = 0, st_blksize = 4096, st_blocks = 
8, 
    st_atime = 1046689902, __unused1 = 0, st_mtime = 1046689325, 
    __unused2 = 0, st_ctime = 1046689335, __unused3 = 0, __unused4 = 0, 
    __unused5 = 0}, u = 0x80cbe38, omode = 0, dir = 0x80cc4a8, 
  diroffset = 2971, fd = -1, dirent = 0x0, next = 0x80cbda0, prev = 0x0}


OK, here's the question. If the newfid is != fid, does it really matter 
that the fid is open? This is pretty much the classical Linux way to ls 
-l: open dir, read dir, stat each thing in dir. So the dir is going to be 
open. Should I be cloning the dir when I open it? Seems inefficient. 

Or should we add code to u9fs rwalk to do this:

        if ((rx->newfid == rx->fid ) && (fid->omode != -1)){
                seterror(tx, Ebadusefid);
                return;
        }

i.e. it's an error to walk an opened fid, but not an error to walk if 
you're going to a new fid? 

What's the right thing to do?

ron

Re: [9fans] clwalk on open directories

[Scott Schwartz]

| Also I am curious as to why my earlier message was impounded as 
| 'suspicious' so I am trying this one more time.

A very lame attempt at spam detection, now changed.

Re: [9fans] clwalk on open directories

[Russ Cox]

> This is pretty much the classical Linux way

This is never a good reason to do something.
The more I learn about the current state of Unix 
(as exemplified by Linux), the more disgusted I get.
I'm glad it was easy to fix your client.

[9fans] u9fs, Linux, large files no good

[Ronald G. Minnich]

For files > 32 bits you need the following define somewhere. 
_FILE_OFFSET_BITS=64

Without this, stat on files > 32 bits in size gets an error each time on 
LInux. The error is:
#define EOVERFLOW       75      /* Value too large for defined data type*/

I put mine in the makefile:

#
# To correctly handle 64-bit files and offsets, add -64 to CFLAGS and 
LDFLAGS
# On Irix 5.X, add -DIRIX5X to hack around their own #include problems 
(see plan
9.h).
#
CC=cc
CFLAGS=-g -I. -D_FILE_OFFSET_BITS=64
LD=cc
LDFLAGS= -g
LDTAIL=


If there is something better to do just let me know.

ron

p.s. Obviously, this fix would have been impossible to work up without the
Intellectual Property provided by Unix technology owned by SCO. Call your
lawyers if you have any doubt. Better yet, format all disks and call SCO
for their pricing.

Re: [9fans] u9fs, Linux, large files no good

[Scott Schwartz]

| p.s. Obviously, this fix would have been impossible to work up without the
| Intellectual Property provided by Unix technology owned by SCO.

Guess we all have to switch to Plan 9. :)

Re: [9fans] u9fs, Linux, large files no good

[Russ Cox]

I would rather see it go in plan9.h:

/* magic to get SUSV2 standard, including pread, pwrite*/
#define _XOPEN_SOURCE 500
/* magic to get 64-bit pread/pwrite */
#define _LARGEFILE64_SOURCE
/* magic to get 64-bit stat on Linux, maybe others */
#define _FILE_OFFSET_BITS 64

Re: [9fans] u9fs, Linux, large files no good

[Ronald G. Minnich]

On Mon, 10 Mar 2003, Russ Cox wrote:

> I would rather see it go in plan9.h:
> 
> /* magic to get SUSV2 standard, including pread, pwrite*/
> #define _XOPEN_SOURCE 500
> /* magic to get 64-bit pread/pwrite */
> #define _LARGEFILE64_SOURCE
> /* magic to get 64-bit stat on Linux, maybe others */
> #define _FILE_OFFSET_BITS 64


works for me, I was unsure of whether it would need an #ifdef in there 
somewhere. 

ron

[9fans] spam avoidance

[Scott Schwartz]

I'm thinking, once again, that we should set the list to
only allow postings from subscribers.  Some people read
via local exploders, or usenet.  I think it's worth
breaking that in order to avoid a bunch of obvious spam.

Re: [9fans] spam avoidance

[David Presotto]

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

It would be nice to first see how many submissions are made by
people not on the list.

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

From: "Scott Schwartz" <schwartz@bio.cse.psu.edu>
To: 9fans@cse.psu.edu
Subject: [9fans] spam avoidance
Date: 23 Feb 2003 02:35:37 -0500
Message-ID: <20030223073537.1363.qmail@g.bio.cse.psu.edu>

I'm thinking, once again, that we should set the list to
only allow postings from subscribers.  Some people read
via local exploders, or usenet.  I think it's worth
breaking that in order to avoid a bunch of obvious spam.

Re: [9fans] spam avoidance

[Mike Haertel]

I'm not on the list.  I do all mailing lists via local repeaters.

Re: [9fans] spam avoidance

[William Josephson]

On Sun, Feb 23, 2003 at 10:24:08AM -0800, Mike Haertel wrote:
> I'm not on the list.  I do all mailing lists via local repeaters.

Similarly, I do many via local aliases,
but then my mail set up is rather Byzantine.
I'm also not wild about having to send mail
with a working envelope address as 9fans is
a growing source of spam off the list.

Re: [9fans] spam avoidance

[Dan Cross]

> > I'm not on the list.  I do all mailing lists via local repeaters.
>
> Similarly, I do many via local aliases,
> but then my mail set up is rather Byzantine.
> I'm also not wild about having to send mail
> with a working envelope address as 9fans is
> a growing source of spam off the list.

Scott, is it possible to have password authentication?  Ie, when you
sign up for the list, you get a password; as long as that password is
in the envelope somewhere, the from address is ignored.  It's not
particularly secure, but would suffice to cut out most of the spam.

	- Dan C.

Re: [9fans] spam avoidance

[David Presotto]

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

I'ld be happy just to have the list dump any mail
with html in it.

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

From: Dan Cross <cross@math.psu.edu>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] spam avoidance
Date: Sun, 23 Feb 2003 13:54:44 -0500
Message-ID: <200302231854.h1NIsiM27287@augusta.math.psu.edu>

> > I'm not on the list.  I do all mailing lists via local repeaters.
>
> Similarly, I do many via local aliases,
> but then my mail set up is rather Byzantine.
> I'm also not wild about having to send mail
> with a working envelope address as 9fans is
> a growing source of spam off the list.

Scott, is it possible to have password authentication?  Ie, when you
sign up for the list, you get a password; as long as that password is
in the envelope somewhere, the from address is ignored.  It's not
particularly secure, but would suffice to cut out most of the spam.

	- Dan C.

Re: [9fans] spam avoidance

[Dan Cross]

> I'ld be happy just to have the list dump any mail with html in it.

No complaints here.  If it also dumped anything with a signature file
over 5 lines, that'd be exstaticating.

	- Dan C.

Re: [9fans] spam avoidance

[Jon Snader]

On Sun, Feb 23, 2003 at 01:56:41PM -0500, David Presotto wrote:
> I'ld be happy just to have the list dump any mail
> with html in it.

I agree--almost all spam is html and virtually nothing of value
arrives with html.

jcs

Re: [9fans] spam avoidance

[rob pike, esq.]

> I agree--almost all spam is html and virtually nothing of value
> arrives with html.

<em>:-)</em>

-rob

Re: [9fans] spam avoidance

[Dan Cross]

> > I agree--almost all spam is html and virtually nothing of value
> > arrives with html.
>
> <em>:-)</em>

That doesn't conform to the HTML DTD.

	- Dan C.

Re: [9fans] spam avoidance

[rob pike, esq.]

> That doesn't conform to the HTML DTD.

Then your HTML detector shouldn't reject it.

-rob

Re: [9fans] spam avoidance

[William Josephson]

On Sun, Feb 23, 2003 at 10:47:49PM -0800, rob pike, esq. wrote:
> > That doesn't conform to the HTML DTD.
>
> Then your HTML detector shouldn't reject it.

... yielding a filter that is about 0% effective
for the intended purpose ...

Re: [9fans] spam avoidance

[Scott Schwartz]

| I'ld be happy just to have the list dump any mail
| with html in it.

Me too.  I'd already had it set to reject headers containing content-type:
text/html, but the spammers sometimes use multipart/alternative (which
I've added), or fail to label it, or otherwise try to be obscure.

Re: [9fans] spam avoidance

[Anthony Mandic]

David Presotto wrote:
>
> I'ld be happy just to have the list dump any mail
> with html in it.

	The Nigerian scammers don't seem to use it so you'd have
	to scan emails for keywords like money, inheritance, etc.

	However, I note that they are now giving out fax and phone numbers.
	Hmmm ... I wonder if tying them up with reverse charges calls would
	have any effect?

-am	� 2003

Re: [9fans] spam avoidance

[Charles Shannon Hendrix]

In article <a6caf012c84ccb2d2de2ee95ad5bf124@plan9.bell-labs.com>, David Presotto wrote:
> This is a multi-part message in MIME format.
> --upas-qacyjawgeouwispgffdcdnybuw
> Content-Disposition: inline
> Content-Type: text/plain; charset="US-ASCII"
> Content-Transfer-Encoding: 7bit
> 
> I'ld be happy just to have the list dump any mail
> with html in it.

Or your screwed up multipart MIME turds... :)

What *is* up with your postings?  Looks broken.

Re: [9fans] spam avoidance

[Russ Cox]

> Or your screwed up multipart MIME turds... :)
> What *is* up with your postings?  Looks broken.

That message looked fine to me.  What looks wrong
to you?  Do you just not have a MIME reader?

Re: [9fans] spam avoidance

[Scott Schwartz]

| Scott, is it possible to have password authentication?

Not really... the list is being run by "mailman" on the department's mail
servers, and so I have to use the canned features that it provides.
One of them is a switch that says "only subscribers can post".
Anything else would require actual work.

Re: [9fans] spam avoidance

[Anthony Mandic]

David Presotto wrote:
> 
> It would be nice to first see how many submissions are made by
> people not on the list.

	This is another one.

-am	© 2003

[9fans] iSCSI

[matt]

I expect that iSCSI has already hit your radar but here's the latest

iSCSI Gets Go-Ahead

http://www.byteandswitch.com/document.asp?doc_id=28277


iSCSI Specification Approved

 Posted by michael on 13/02/03 19:08
from the i-everything dept.
nasorsan writes "The iSCSI protocol is a means to transport SCSI commands
and data using TCP/IP packets. This ratification by the IETF is "the last
major hurdle for iSCSI to become widely supported. . . 'Now that it's done,
Microsoft Corp. and Novell Inc. will release drivers, and the games will
begin,' says Steve Duplessie, senior analyst at Enterprise Storage Group
Inc. 'Anyone who doesn't think this is the beginning of a huge market is
insane.'" he added."


http://developers.slashdot.org/article.pl?sid=03/02/13/1713245

Re: [9fans] iSCSI

[Ronald G. Minnich]

On Thu, 13 Feb 2003, matt wrote:

> I expect that iSCSI has already hit your radar but here's the latest
>
> iSCSI Gets Go-Ahead

Am I the only person in the world who can't figure out why anyone wants
iSCSI? I just can't get it to make sense. My brain just won't go near it.

ron

Re: [9fans] iSCSI

[David Presotto]

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

Don't deflate my sails!  I was about to suggest eSCSI where each SCSI command is
carried as a separate MIME attachment.

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

From: "Ronald G. Minnich" <rminnich@lanl.gov>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] iSCSI
Date: Thu, 13 Feb 2003 13:08:16 -0700 (MST)
Message-ID: <Pine.LNX.4.44.0302131307470.26717-100000@carotid.ccs.lanl.gov>

On Thu, 13 Feb 2003, matt wrote:

> I expect that iSCSI has already hit your radar but here's the latest
>
> iSCSI Gets Go-Ahead

Am I the only person in the world who can't figure out why anyone wants
iSCSI? I just can't get it to make sense. My brain just won't go near it.

ron

Re: [9fans] iSCSI

[Christopher Nielsen]

Better yet, NFS over SMTP.

On Thu, Feb 13, 2003 at 03:13:08PM -0500, David Presotto wrote:
> Don't deflate my sails!  I was about to suggest eSCSI where each SCSI command is
> carried as a separate MIME attachment.

> From: "Ronald G. Minnich" <rminnich@lanl.gov>
> To: 9fans@cse.psu.edu
> Date: Thu, 13 Feb 2003 13:08:16 -0700 (MST)
> Subject: Re: [9fans] iSCSI
>
> On Thu, 13 Feb 2003, matt wrote:
>
> > I expect that iSCSI has already hit your radar but here's the latest
> >
> > iSCSI Gets Go-Ahead
>
> Am I the only person in the world who can't figure out why anyone wants
> iSCSI? I just can't get it to make sense. My brain just won't go near it.
>
> ron


--
Christopher Nielsen - Metal-wielding pyro techie
"They who can give up essential liberty for temporary
safety, deserve neither liberty nor safety." --Benjamin Franklin

Re: [9fans] iSCSI

[Scott Schwartz]

| Am I the only person in the world who can't figure out why anyone wants
| iSCSI? I just can't get it to make sense. My brain just won't go near it.

You are caught in a time warp, back to before network filesystems
were invented.  Now, when you have a big SCSI disk and 100 PeeCees.
You divide the disk into 100 partitions and give one to each PeeCee.

Re: [9fans] iSCSI

[Jonathan Sergent]

On Thursday, Feb 13, 2003, at 12:08 US/Pacific, Ronald G. Minnich wrote:
> Am I the only person in the world who can't figure out why anyone wants
> iSCSI? I just can't get it to make sense. My brain just won't go near
> it.

I think the point is that it makes more sense than Fibre Channel.

Re: [9fans] iSCSI

[Ronald G. Minnich]

On Fri, 14 Feb 2003, Jonathan Sergent wrote:

> On Thursday, Feb 13, 2003, at 12:08 US/Pacific, Ronald G. Minnich wrote:
> > Am I the only person in the world who can't figure out why anyone wants
> > iSCSI? I just can't get it to make sense. My brain just won't go near
> > it.
>
> I think the point is that it makes more sense than Fibre Channel.


I remember the saying now ... "damn with faint praise" right?

ron

Re: [9fans] iSCSI

[Dan Cross]

Holy Shit!  I think I'm having a fucking heart attack!  Someone call
the paramedics!

iSCSI is a colosally bad idea.  Better yet, it's probably a joke.  I've
been waiting for someone to create the standards joke movement, but it
didn't seem to have taken root, until now.

	- Dan C.

Re: [9fans] iSCSI

[David Gordon Hogan]

> iSCSI is a colosally bad idea.  Better yet, it's probably a joke.  I've
> been waiting for someone to create the standards joke movement, but it
> didn't seem to have taken root, until now.

An important clue is that "iSCSI" is a palindrome.  Perhaps ATA is a
joke standard too?

Re: [9fans] iSCSI

[Dan Cross]

> An important clue is that "iSCSI" is a palindrome.  Perhaps ATA is a
> joke standard too?

I thought that was a given.

	- Dan C.

Re: [9fans] iSCSI

[Sam]

> Holy Shit!  I think I'm having a fucking heart attack!  Someone call
> the paramedics!
>

Paramedics, I'm afraid, can do little for tourette's syndrome.

> iSCSI is a colosally bad idea.  Better yet, it's probably a joke.  I've

... what if I've just been dying to get my hands on ip routable
disk blocks?  Why just imagine the breaches, err, uses that will
arise from such functionality.

Sam

Re: [9fans] iSCSI

[Dan Cross]

In article <Pine.LNX.4.30.0302131700370.10362-100000@athena> you write:
>> Holy Shit!  I think I'm having a fucking heart attack!  Someone call
>> the paramedics!
>
>Paramedics, I'm afraid, can do little for tourette's syndrome.

More like Parkinson's.  Like Muhammad Ali, brought on by too many
blows to the head from this stupid industry.

	- Dan C.

Re: [9fans] iSCSI

[Richard Miller]

> ... what if I've just been dying to get my hands on ip routable
> disk blocks?  Why just imagine the breaches, err, uses that will
> arise from such functionality.

Early versions of SunOS used a block-oriented "Network Disk" protocol
over IP to serve root and swap to diskless clients.  It was not
particularly secure ...

Re: [9fans] iSCSI

[Ronald G. Minnich]

On Fri, 14 Feb 2003, Richard Miller wrote:

> Early versions of SunOS used a block-oriented "Network Disk" protocol
> over IP to serve root and swap to diskless clients.  It was not
> particularly secure ...

yep. I still remember setting that one up.

What's weird is that the whole PC world seems oblivious to the fact that
we've been here before, multiple times. It figures, microsoft is involved.

So who's writing #iSCSI?

ron

[9fans] rotzoomer -- another xscreensaver hack

[andrey mirtchovski]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 534 bytes --]

i saw this one on somebody else's computer and just wanted to have it :)

start it up in a small window and then resize to full screen for
complete satisfaction...

it doesn't take all that much to convert the X drawing calls to draw ones,
took me longer to clean it up into some sort of viewable form. i'm sure i
haven't managed to do so completely.

non-plan9 code is GNU, so have that in mind if you decide to play with it.

andrey

ps: other xscreensaver hacks here:

    http://www.acl.lanl.gov/plan9/xscreensaver/

[-- Attachment #2: Type: APPLICATION/octet-stream, Size: 99848 bytes --]

Re: [9fans] rotzoomer -- another xscreensaver hack

[geoff]

I've got a sped-up version of rotzoomer at
http://collyer.net/~geoff/9, along with faster (though still slow)
versions of maze and mandel.  I also found a few bugs in maze by
inspection and fixed them.

I suspect that rotzoomer should build up new images in memory and push
them out in large fractions of a window, rather than pixel by pixel.

Re: [9fans] rotzoomer -- another xscreensaver hack

[andrey mirtchovski]

that's how it originally operated. i didn't find it too fast on my own
machine and opted for simplicity...

do you want me to add your modifications to www.acl.lanl.gov's xscreensaver
archive?

i just tried your web site and the link to rotzoomer.bun appears to be broken...



On Tue, 21 Jan 2003 geoff@collyer.net wrote:

> I've got a sped-up version of rotzoomer at
> http://collyer.net/~geoff/9, along with faster (though still slow)
> versions of maze and mandel.  I also found a few bugs in maze by
> inspection and fixed them.
>
> I suspect that rotzoomer should build up new images in memory and push
> them out in large fractions of a window, rather than pixel by pixel.
>

Re: [9fans] rotzoomer -- another xscreensaver hack

[geoff]

> do you want me to add your modifications to www.acl.lanl.gov's
> xscreensaver archive?

Sure, that would be fine.

> i just tried your web site and the link to rotzoomer.bun appears to be
> broken...

Sorry about that; I had the link working and then broke it.  It's
fixed now.  I've also incorporated your suggested changes into my
rotzoomer bundle.

Re: [9fans] rotzoomer -- another xscreensaver hack

[Russ Cox]

you know, you could read /dev/vgactl in a daemon 
to figure out how long the terminal has been idle
and then invoke the screensaver automatically.

if you were into that sort of thing.

Re: [9fans] rotzoomer -- another xscreensaver hack

[andrey mirtchovski]

I don't know how to write over the entire screen instead of just in a
window...

plus, I'm not sure whether rio will be forgiving enough if I sidestep it, or
whether you guys will accept modified rio sources (like adding extra
controls to rio itself)

i wouldn't mind converting all those hacks into screensavers, just never
really thought about it seriously enough..

On Tue, 21 Jan 2003, Russ Cox wrote:

> you know, you could read /dev/vgactl in a daemon
> to figure out how long the terminal has been idle
> and then invoke the screensaver automatically.
>
> if you were into that sort of thing.
>

Re: [9fans] rotzoomer -- another xscreensaver hack

[Russ Cox]

you don't need to write to the screen.  allocate a new
window as big as the screen.

Re: [9fans] rotzoomer -- another xscreensaver hack

[Scott Schwartz]

Russ writes:
> if you were into that sort of thing.

Let me put in a vote for the opposite sort of thing: using DPMS to powersave
the monitor.

Re: [9fans] rotzoomer -- another xscreensaver hack

[Russ Cox]

> Let me put in a vote for the opposite sort of thing: using DPMS to powersave
> the monitor.

every time i have tried to do dpms by the vesa spec,
the screens never come back correctly
when i turn them back on.  the code is in
/sys/src/9/pc/vga.c:/^vgablank, but it breaks
so many setups that it's not used.

some video cards have their own ways to get at dpms
(see /sys/src/9/pc/vgasavage.c:/^savageblank, also
s3, mga6xx, nvidia) and that seems to work better.
it's still not perfect though.  mach64xx, for example,
doesn't behave right even using the mach64xx-specific
blanking.

it's just a nightmare.  the lcds tend to work better because
they have an explicit signal to do blanking rather than
infer something from the horizontal and vertical sync pulses.
both laptops and digital cards like t2r4 seem to work well.

[9fans] suspending screens (was: rotzoomer)

[andrey mirtchovski]

On Tue, 21 Jan 2003, Russ Cox wrote:

> it's just a nightmare.  the lcds tend to work better because
> they have an explicit signal to do blanking rather than
> infer something from the horizontal and vertical sync pulses.
> both laptops and digital cards like t2r4 seem to work well.
>

The T21 IBM laptop I have can never restore the screen correctly after a
suspend (such as closing the laptop and reopening it immediately). The
problem has been reported here a few times by different people -- the screen
gets split in three columns, each showing only the first third on the
original screen...

I have looked but wasn't really able to fix it. It existed in FreeBSD too,
but has disappeared after 4.6RC2...

Re: [9fans] suspending screens (was: rotzoomer)

[jmk]

although i have't tried it on the t21, the t23 has a similar problem when used
in anything other that 8-bit mode. the bios apm code fails to set the depth bits
correctly in crt register 0x90, e.g. for 16-bit mode it should be 0x81, not 0x80
(see /sys/src/cmd/vga/virge.c). i have a dumb little programme ('adjust') for poking
registers directly when testing things and use this to reset the screen after
the lid has been opened:

	/usr/jmk/src/v/adjust crt 0x90 0x81

if i could be bothered i'd figure ou how to get that run automatically on
opening the lid. fyi, here's how to display on an external monitor on the t23:

	# turn on hsync/vsync to external monitor
	% adjust seq 0x0d 0
	0x3C4[0x0D]: 0x50->0x00

	# power up the DACs
	% adjust seq 0x18 0
	0x3C4[0x18]: 0x20->0x00

	# turn off the lcd
	% adjust seq 0x31 0
	0x3C4[0x31]: 0x10->0x00
	% 

Re: [9fans] rotzoomer -- another xscreensaver hack

[rob pike, esq.]

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

On a related note, here's a screen locker. I intended to wrap it in a shell
script to watch the idle time in vgactl but bounced off a bug in an early
version of that code and never returned.  I just run it by hand.

/lib/bunny.bit is a cropped version of glenda from the web site and too
large to attach here.

-rob

[-- Attachment #2: lock.c --]
[-- Type: text/plain, Size: 5802 bytes --]

#include <u.h>
#include <libc.h>
#include <libsec.h>
#include <draw.h>

char pic[] = "/lib/bunny.bit";

int vgactl;
int debug;

uchar	storedhash[SHA1dlen];
uchar	thishash[SHA1dlen];
char user[256];
char home[256];
char hashfile[256];

void
error(char *fmt, ...)
{
	Fmt f;
	char buf[64];
	va_list arg;

	fmtfdinit(&f, 1, buf, sizeof buf);
	fmtprint(&f, "lock: ");
	va_start(arg, fmt);
	fmtvprint(&f, fmt, arg);
	va_end(arg);
	fmtprint(&f, "\n");
	fmtfdflush(&f);
	postnote(PNGROUP, getpid(), "die");
	exits("fatal error");
}

void
usage(void)
{
	fprint(2, "usage: lock [-p]\n");
	exits("usage");
}


void
readfile(char *name, char *buf, int nbuf, int addnul)
{
	int fd;

	fd = open(name, OREAD);
	if(fd == -1)
		error("%s: can't open: %r", name);
	nbuf = read(fd, buf, nbuf-addnul);
	close(fd);
	if(nbuf == -1)
		error("%s: can't can't read: %r", name);
	if(addnul)
		buf[nbuf] = '\0';
}

int
readstoredhash(int mustexist)
{
	if(access(hashfile, AEXIST) < 0){
		if(!mustexist)
			return 0;
		error("no password set; use lock -p to set password");
	}
	readfile(hashfile, (char*)storedhash, sizeof storedhash, 0);
	return 1;
}

void
readline(char *buf, int nbuf)
{
	char c;
	int i;

	i = 0;
	while(i < nbuf-1){
		if(read(0, &c, 1) != 1 || c == '\04' || c == '\177'){
			buf[0] = '\0';
			return;
		}
		if(c == '\n'){
			buf[i] = '\0';
			return;
		}
		if(c == '\b' && i > 0){
			--i;
			continue;
		}
		if(c == '\025'){
			i = 0;
			continue;
		}
		buf[i++] = c;
	}
}

void
checkpassword(int must)
{
	char buf[256];
	static int opened;
	int fd, consctl;

	if(!opened){
		fd = open("/dev/cons", OREAD);
		if(fd == -1)
			error("can't open cons: %r");
		dup(fd, 0);
		close(fd);
		fd = open("/dev/cons", OWRITE);
		if(fd == -1)
			error("can't open cons: %r");
		dup(fd, 1);
		dup(1, 2);
		close(fd);
		consctl = open("/dev/consctl", OWRITE);
		if(consctl == -1)
			error("can't open consctl: %r");
		if(write(consctl, "rawon", 5) != 5)
			error("can't turn off echo\n");
		opened = 1;
	}

	for(;;){
		fprint(2, "password: ");
		readline(buf, sizeof buf);
		fprint(2, "\n");
		if(buf[0] == '\0' || buf[0] == '\04'){
			if(must)
				continue;
			error("no password typed");
		}
		sha1((uchar*)buf, strlen(buf), thishash, nil);
		memset(buf, 0, sizeof buf);
		if(memcmp(thishash, storedhash, sizeof storedhash) == 0)
			break;
		fprint(2, "password mismatch\n");
	}
}

void
changepassword(void)
{
	int fd;
	char buf[256];

	if(readstoredhash(0))
		checkpassword(0);
	for(;;){
		fprint(2, "password: ");
		readline(buf, sizeof buf);
		fprint(2, "\n");
		if(buf[0] == '\0' || buf[0] == '\04')
			exits("no password typed");
		sha1((uchar*)buf, strlen(buf), thishash, nil);
		memset(buf, 0, sizeof buf);
		fprint(2, "re-type password: ");
		readline(buf, sizeof buf);
		fprint(2, "\n");
		if(buf[0] == '\0' || buf[0] == '\04')
			exits("no password typed");
		sha1((uchar*)buf, strlen(buf), storedhash, nil);
		memset(buf, 0, sizeof buf);
		if(memcmp(storedhash, thishash, sizeof storedhash) != 0){
			fprint(2, "password mismatch\n");
			continue;
		}

		fd = create(hashfile, OWRITE, 0600);
		if(fd < 0)
			error("can't create hashfile: %r");
		if(write(fd, storedhash, sizeof storedhash) != sizeof storedhash)
			error("error writing hashfile: %r");
		break;
	}
}

void
grabmouse(void)
{
	int fd;
	char ibuf[256], obuf[256];

	if(debug)
		return;
	fd = open("/dev/mouse", ORDWR);
	if(fd < 0)
		error("can't open /dev/mouse: %r");
	switch(fork()){
	case -1:
		error("can't fork mouse process: %r");
	default:
		return;
	case 0:
		break;
	}

	snprint(obuf, sizeof obuf, "m %d %d",
		screen->r.min.x+Dx(screen->r)/2,
		screen->r.min.y+Dy(screen->r)/2);
	while(read(fd, ibuf, sizeof ibuf) > 0)
		fprint(fd, "%s", obuf);
}

void
lockscreen(void)
{
	enum { Nfld=5, Fldlen = 12 };
	char buf[Nfld*Fldlen], *flds[Nfld], newcmd[128];
	enum { Cursorlen=2*4+2*2*16 };
	char cbuf[Cursorlen];
	int fd, dx, dy;
	Image *i;
	Rectangle r;

	fd = open("/dev/screen", OREAD);
	if(fd < 0)
		error("can't open /dev/screen: %r");
	if(read(fd, buf, Nfld*Fldlen) != Nfld*Fldlen)
		error("can't read /dev/screen: %r");
	close(fd);
	buf[sizeof buf-1] = 0;
	if(tokenize(buf, flds, Nfld) != Nfld)
		error("can't tokenize /dev/screen header");
	snprint(newcmd, sizeof newcmd, "-r %s %s %d %d",
		flds[1], flds[2],
		atoi(flds[3])-1, atoi(flds[4])-1);
	newwindow(newcmd);
	initdraw(nil, nil, "lock");

	/* screen is now open and covered. grab mouse and hold on tight */
	grabmouse();
	fd = open(pic, OREAD);
	if(fd > 0){
		i = readimage(display, fd, 0);
		if(i){
			r = screen->r;
			dx = (Dx(screen->r)-Dx(i->r))/2;
			r.min.x += dx;
			r.max.x -= dx;
			dy = (Dy(screen->r)-Dy(i->r))/2;
			r.min.y += dy;
			r.max.y -= dy;
			draw(screen, r, i, nil, i->r.min);
			flushimage(display, 1);
		}
		close(fd);
	}

	/* clear the cursor */
	fd = open("/dev/cursor", OWRITE);
	if(fd > 0){
		memset(cbuf, 0, sizeof cbuf);
		write(fd, cbuf, sizeof cbuf);
		/* leave it open */
	}
	
	fprint(vgactl, "blank");
}

void
main(int argc, char *argv[])
{
	readfile("#c/user", user, sizeof user, 1);
	readfile("#e/home", home, sizeof home, 1);
	snprint(hashfile, sizeof hashfile, "%s/lib/lockhash", home);

	vgactl = open("#v/vgactl", OWRITE);
	if(vgactl == -1)
		error("can't open vgactl: %r");

	ARGBEGIN{
	case 'd':
		debug++;
		break;
	case 'p':
		changepassword();
		exits(nil);
	default:
		usage();
	}ARGEND

	if(argc != 0)
		usage();

	readstoredhash(1);
	rfork(RFNOTEG);
	lockscreen();
	checkpassword(1);
	postnote(PNGROUP, getpid(), "die");
	exits(nil);
}

Re: [9fans] Serving 9p in python - anyone started that?

[Russ Cox]

> Just curiosity. Why did you take that way instead of trying to get
> a toolset for doing rc 9p servers? I mean, IMHO, rc is the
> preferred way of scripting. I've some times wanted to
> be able to plug rc scripts into a generic 9p server skeleton,
> and alto to write an rc script that uses other tools to speak 9p.

i don't know about john, but i did my 9p python code because
i was sick of c getting in my way while trying to write the 9p
tester.  the c version was all details i didn't care about.  the
python version is nice and simple.  i would like to be able to
use rc instead, but it wasn't clear how to do that.  rc is a nice
shell but it's not the best programming environment.
my example is the install scripts.  they push the limit of
what you really want to be doing in an rc script.  (transitive
closure, for instance.)

Re: [9fans] Serving 9p in python - anyone started that?

[Ronald G. Minnich]

> > Just curiosity. Why did you take that way instead of trying to get
> > a toolset for doing rc 9p servers? I mean, IMHO, rc is the
> > preferred way of scripting.

never complain about work somebody else does for free. You don't like it,
change the channel :=)

I think the python thing is quite cool, and I plan to use it to validate
our forthcoming 4e server for Linux (we're still 3e).

ron

Re: [9fans] Serving 9p in python - anyone started that?

[Scott Schwartz]

> I think the python thing is quite cool,

Me too!

Re: [9fans] Essay: Is network transparency something bad?

[rog]

> But I don't think there's a single right answer to this. As we perl
> programmers often say, "there's more than one way to do it."

i think plan 9's approach is better than the more usual "network
transparency" where a function or method invocation is turned into an
RPC behind your back.

at least in the plan 9 way, it is well documented that all system
calls can potentially block for a long period of time, and they have
error returns that can describe the arbitrary errors that can be
associated with network transfers.

so it's quite possible to write programs in the light of that
knowledge (a decent threads library makes that easier too).
i don't think it's so easy with, for instance, Java RMI
(but i'd be glad to be contradicted).

it's interesting to see what *does* lock up when a file access takes
an unexpectedly long time (e.g.  accessing the dump fs).  for instance
acme locks while it's opening a file; rio locks when plumbing a file.

  rog.

Re: [9fans] Essay: Is network transparency something bad?

[Scott Schwartz]

| at least in the plan 9 way, it is well documented that all system
| calls can potentially block for a long period of time,

I just wish that they were interruptable.  Having something block forever
just because a file server isn't answering can be painful.

| it's interesting to see what *does* lock up when a file access takes
| an unexpectedly long time (e.g.  accessing the dump fs).  for instance
| acme locks while it's opening a file; rio locks when plumbing a file.

That suggests a diagnostic tool: slowfs, which interposes between you
and the real filesystem and randomly delays for several seconds before
passing messages on.

Re: [9fans] Essay: Is network transparency something bad?

[Ronald G Minnich]

On Thu, 24 Oct 2002, Scott Schwartz wrote:

> I just wish that they were interruptable.  Having something block forever
> just because a file server isn't answering can be painful.

well, consider a true case that occurs on ham radio links (or did a few
years ago). FTP sessions in some cases would block for a *day* and then
start again.

The question is, should you interrupt or not? It always struck me as a
pretty hard question.

ron

Re: [9fans] Essay: Is network transparency something bad?

[Dan Cross]

> well, consider a true case that occurs on ham radio links (or did a few
> years ago). FTP sessions in some cases would block for a *day* and then
> start again.
>
> The question is, should you interrupt or not? It always struck me as a
> pretty hard question.

I think what Scott means is that the user ought to be able to interupt
the connection.

	- Dan C.

Re: [9fans] Essay: Is network transparency something bad?

[Scott Schwartz]

| I think what Scott means is that the user ought to be able to interupt
| the connection.

Exactly.

Re: [9fans] Essay: Is network transparency something bad?

[Boyd Roberts]

Ronald G Minnich wrote:

>The question is, should you interrupt or not? It always struck me as a
>pretty hard question.
>
I agree.

Look at the mess that BSD was with its interruptable system calls.

The horror, the horror ...

Re: [9fans] Essay: Is network transparency something bad?

[Steve Kilbane]

rog wrote:
> i think plan 9's approach is better than the more usual "network
> transparency" where a function or method invocation is turned into an
> RPC behind your back.

Or to put it another way: sweeping the problems under someone else's
carpet. In this case, the user's.

> it's interesting to see what *does* lock up when a file access takes
> an unexpectedly long time

Indeed. It's fun when the expected value for "a long time" changes by
many orders of magnitude. I once dealt with an OO database, where the
database transactions could last for many months between initiation and
commit rather than mere seconds. That changed a few working methods.

[9fans] trying to reach

[FODEMESI Gergely]

Hi,

I am trying to reach Sean Quinlan and/or Sean Dorward, I tried to send
email to seanq@bell-labs.com, sean@..., sean.quinlan@..., sean.dorward@...
All 4 emails came back with:
"<........> was not found in corporate database"
Could somebody at bell-labs tell me the correct address?

 thanks: gergo

[9fans] weird print(2) problems...

[Dan Cross]

Running the following program, output after the ``print("");''
never makes it as piped input to other programs.

Has anyone else noticed this?  btw- when I tried to run it
under an acme ``win'' window, it hung and I had to Delete the
window to clear it up.  Very strange....  Any ideas?  (btw- I
removed a literal `eot' from below.)

	- Dan C.

term% cat > test.c
#include <u.h>
#include <libc.h>
void
main(void)
{
	print("");
	print("Test.\n");
	exits(0);
}
(eot)term% 8c test.c && 8l test.8
term% 8.out
Test.
term% 8.out | cat
term% echo twilight zone theme....
twilight zone theme....
term%

Re: [9fans] weird print(2) problems...

[Scott Schwartz]

Hm.  Pipes in Plan 9 preserve write boundaries, right?  Print is probably
sending a zero length write, and confusing programs that interpret it
as eof.

Re: [9fans] weird print(2) problems...

[Dan Cross]

In article <20010904190825.3180.qmail@f.bio.cse.psu.edu> you write:
>Hm.  Pipes in Plan 9 preserve write boundaries, right?  Print is probably
>sending a zero length write, and confusing programs that interpret it
>as eof.

Hmm, that seems plausible.  It's also rather annoying; it seems to me
that if write(2) sees a zero length argument, it should consider that a
nop and return.  But then it seems that that would break some weird
semantic somewhere (``Any write will update a timestamp; except for
zero length writes, which are ignored.'' ``Dude, that's broken.'')

Is there an elegant solution (other than ``don't do print("");'',
since that might really mean ``don't do,

	read(0, str, 128);
	trimwhitespace(str);
	print("%s", str);

where the only thing read is a blank line or something.'')?

	- Dan C.

Re: [9fans] weird print(2) problems...

[Boyd Roberts]

> Is there an elegant solution (other than ``don't do print("");'',
> since that might really mean ``don't do,

print() shouldn't call write(), as there's nothing to write.

we're dealing with strings here.

[9fans] Quality of Plan 9's Cyrillic fonts?

[Dan Cross]

I've a need to write a bunch of text files in Russian; how do native
speakers/readers feel about the quality of Plan 9's Cyrillic fonts?
Are they good, or should I search elsewhere?  Also (and this might be
related to Andrey's recent question), is there a way to type in
Cyrillic's without hitting an Alt sequence for each character?
Thanks!

	- Dan C.

Re: [9fans] Quality of Plan 9's Cyrillic fonts?

[Scott Schwartz]

| I've a need to write a bunch of text files in Russian; how do native
| speakers/readers feel about the quality of Plan 9's Cyrillic fonts?

I can't speak to that, but under Unix I've been happy using the newer X11
bitmap fonts that have some unicode coverage (like the updated version
of the venerable 10x20.)  If the licences permit, it might make sense
to ship repackaged versions of them with Plan 9.

Re: [9fans] Quality of Plan 9's Cyrillic fonts?

[George Bronnikov]

On Sun, 25 Aug 2002, Dan Cross wrote:

> I've a need to write a bunch of text files in Russian; how do
> native
> speakers/readers feel about the quality of Plan 9's Cyrillic
> fonts?
> Are they good, or should I search elsewhere?  Also (and this
> might be
> related to Andrey's recent question), is there a way to type
> in
> Cyrillic's without hitting an Alt sequence for each character?
> Thanks!

The fonts are bad -- readable but ugly (the 'b' letter looks
especially strange).  I am no font expert but I think the fixed
fonts that come with X (Cronyx) can serve as the first
approximation.

As for keyboard drivers: I posted one for 3rd edition a while
ago (based on forsyth's and russ's work), and nemo has another
variant, though I believe his version does not have Russian
layout.  It should be a trivial task to adapt any of those to
current sources.  Maybe I'll do it myself in the next couple of
days, but I don't have a running Plan 9 nearby right now, so I don't
promise.

	Goga

Re: [9fans] Quality of Plan 9's Cyrillic fonts?

[Andrey S. Kukhar]

this is my feature about quality of some russian fonts:

        /lib/font/bit/lucida/unicode.7.font, unicode.6.font
        rather not bad, but could be better.

        /lib/font/bit/lucidasans/unicode.7.font
	not very good, too small, ugly and curves; not discernible letters
	"О©╫" and "О©╫"; not similar to english characters view.

        /lib/font/bit/lucidasans/unicode.8.font
        too bold, must be named boldunicode.8.font.

        /lib/font/bit/lucidasans/boldunicode.8.font
        in general do not display cyrillic symbols.

        /lib/font/bit/misc/unicode.6x13.font
        big, ugly; not similar to english characters view.

        /lib/font/bit/pelm/unicode.8.font
        big, ugly; not similar to english characters view.

fate of russian fonts to me not indifferent so do not take offence if i has
gone too far somewhere.

Dan, if you need help with writing russian text files, tell me.

-ask

> I've a need to write a bunch of text files in Russian; how do native
> speakers/readers feel about the quality of Plan 9's Cyrillic fonts?
> Are they good, or should I search elsewhere?  Also (and this might be
> related to Andrey's recent question), is there a way to type in
> Cyrillic's without hitting an Alt sequence for each character?
> Thanks!
>
> 	- Dan C.

Re: [9fans] Quality of Plan 9's Cyrillic fonts?

[Dan Cross]

Thanks George and Andrey for your advice on this question.  Andrey, I'll
definitely let you know if I need help typing Russian.  :-)

	- Dan C.

[9fans] Tunneling 9p over rfc822 encoded email/SMTP?

[Dan Cross]

Has anyone worked on this?  I think it'd be useful, as email traffic is
frequently allowed through corporate firewalls.  Sure, the latency would
be high, but still....  We could uuencode the packet data.

How about carrier pigeons?  There's an RFC for transmitting IP packets
via carrier pigeon, and that'll certainly get through a corporate firewall
(and a lot of fenced-in compounds, as well).

	- Dan C.

(btw- we can already tunnel 9p over SSH; would it be that hard to write
something that did HTTP proxying and then invoke it out of execnet?)

Re: [9fans] Tunneling 9p over rfc822 encoded email/SMTP?

[Steve Kilbane]

Dan wrote:
> (btw- we can already tunnel 9p over SSH; would it be that hard to write
> something that did HTTP proxying and then invoke it out of execnet?)

I misread that as "invoke it out of exocet". Which would certainly be
more exciting than carrier pigeons, and gets my vote.

steve

Re: [9fans] Tunneling 9p over rfc822 encoded email/SMTP?

[Boyd Roberts]

Steve Kilbane wrote:

>I misread that as "invoke it out of exocet". Which would certainly be
>more exciting than carrier pigeons, and gets my vote.
>
Although you'd still get better range from pigeons than an Exocet
and they require no end-user certificates  ...

Re: [9fans] Ephase question.

[Russ Cox]

> What about releasing the resources attached to the file descriptor
> / fid?  A long-running command using hundreds of files in
> sequence - for instance a network server - would be a resource
> hog without close.  Of course you could provide a garbage collector
> but that opens a whole new world of trouble.

It'd be just like NFS!

Re: [9fans] Ephase question.

[rob pike, esq.]

> It would be an interesting academic exercise to determine the
> minimal set.  E.g. close() doesn't seem to be needed; whenever
> there's no reference to the object, any connection to it can be
> cleaned up.
What about releasing the resources attached to the file descriptor
/ fid?  A long-running command using hundreds of files in
sequence - for instance a network server - would be a resource
hog without close.  Of course you could provide a garbage collector
but that opens a whole new world of trouble.

> At least for Unix devices, it was only the *last*
> close that did anything interesting.
Except for releasing the fd.

>  And I've sometimes had
> the feeling that bind and mount aren't dissimilar enough to
> require separation.
The earliest version of Plan 9 had a different setup than bind
and mount; it was mount and fmount.  It was a mess.  I don't
remember much about it but the current scheme was a huge
improvement - huge.  I think for instance exportfs might have
been impossible in the old scheme.

But there well may be a unified approach that we just missed.


In any case, who cares?  As you said, it's academic.  I can do
everything with a single system call, syscall, that takes as its
first argument the call to make.  If you call that cheating, I
respond that rfork is really a set of calls encoded with a bitvector.

Nobody asks what the minimum libc interface is, or even counts
the calls.  For some reason system calls are seen as magical.  They're
just one way to implement a library.  In Plan 9 in particular, we've
tried to blur the difference between syscall and library, with
things moving back and forth over time.  Stat, wait, and read (!) are
no longer system calls.

What matters is expressibility without bloat, not finding the
criteria under which to claim a lower count of functions of type
T, for some T.

-rob

Re: [9fans] Ephase question.

[Douglas A. Gwyn]

"rob pike, esq." wrote:
> Of course you could provide a garbage collector
> but that opens a whole new world of trouble.

That's the sort of thing I had in mind.  Unused resources
can *in principle* be reclaimed without the resource client's
explicit participation.  How practical it would be is another
question, and I'm not proposing that real systems be boiled
down to minimal possible facilities that are hard to use.
(Otherwise we'd all be given just gate arrays to program.)

> In any case, who cares?  As you said, it's academic.

Doesn't mean that it's not worth thinking about.  Sometimes
good ideas emerge that can be adapted into useful practice.

> ... rfork is really a set of calls encoded with a bitvector.

Indeed there have been several composite "spawn" implementations;
while simplicity might be hard to measure accurately, a single
call with lots of parameters doesn't seem as simple as a couple
of calls with very few parameters.

> Nobody asks what the minimum libc interface is, ...

To some degree we do.  How much *has* to be provided by each
specific C implementation in order for a user to be able to
provide his own portable implementation of all the standard
library?  In the embedded-processor world I find that such
questions can be of urgent practical importance.

A similar question is, what is the minimum synchronization
mechanism needed to coordinate threads?  Add "efficiently".
Mutexes seem to be the answer, but if someone knows better
I'd appreciate hearing about it.

> What matters is expressibility without bloat, not finding
> the criteria under which to claim a lower count of
> functions of type T, for some T.

It can depend on one's goal.  For example, if a primary goal
is proof of security, it seems intractible unless the number
of primitive functions is fairly small and each has a fairly
clean specification.  Reliability and correctness, ditto.
English is very expressive, but problematic for purposes of
precise specification.  It would be meaningful and potentially
useful for linguists to consider minimal requirements for an
equally expressive but precise natural language.  (Leaving
aside any requirement for intentional ambiguity, which for
the most part is also a working assumption for OS services.)

Re: [9fans] Ephase question.

[Ronald G Minnich]

On Thu, 15 Aug 2002, Douglas A. Gwyn wrote:

> > What matters is expressibility without bloat, not finding
> > the criteria under which to claim a lower count of
> > functions of type T, for some T.
>
> It can depend on one's goal.  For example, if a primary goal
> is proof of security, it seems intractible unless the number
> of primitive functions is fairly small and each has a fairly
> clean specification.  Reliability and correctness, ditto.

Why I care about "how many system calls"; check out the Unix (Linux)
system call list nowadays. There are lots of different resource types
(pathnames, sysctl names, fds, pids, etc. etc) and consequently lots of
different difficulties. Just watching the freebsd 'jail' discussion has
been interesting. How do you ever secure an interface this complicated?
Seems very hard, and has proven to be hard in practice.

It's not just "reduce T for some T". Exploding system call counts can
indicate a problem with the design of the system (see some of the later
Linux system calls ...).

ron

Re: [9fans] Ephase question.

[rog]

> > would it be too nasty to make the fileserver refuse writes
> > on files that are currenty open with OEXEC?

> sometimes you really do want to update a binary and it's annoying when
> you can't

well, safeinstall would still have its place:

	cp $prereq $stem || mv $prereq _$stem && cp $prereq $stem

...it would just be less exercised.

round here we tend to

	mv /bin/prog /bin/prog.`{date -n}

which leads to less clashes (but does require garbage collection
every so often).

i don't have such a problem doing this with publicly installed
executables; it's when i'm in the usual compile/edit cycle, and
accidentally overwrite a running executable and spend half an hour
looking for the non-existent bug that gets my goat.  it also means
that i have developed a tendency to ignore hard-to-explain problems:
"oh, it must have been overwritten".

  rog.

Re: [9fans] Ephase question.

[Russ Cox]

> and, out of curiosity, were there ever syscalls for
> slots 48 and 49? if so, what'd they do?

I think the gap is historical.  We split the 9P2000 kernel and libraries
from the main sources and added all the new 9P2000 code
in a separate tree.  At some point while the trees were split,
we added pread and pwrite to both systems.  In the 9P2000
system, they were 37 and 38 (previously occupied by read9p
and write9p).  The calls got added to the 9P1 systems some time
later, because they were too convenient not to have, and
I think 50 and 51 got used just to be out of the way as a temporary
slot until the 9P2000 kernels got installed.  (We couldn't replace
read9p and write9p in the 9P1 system, so we needed new numbers.
At the time, the biggest 9P1 syscall number was seek at 39,
while the 9P2000 syscalls were slowly eating the 40s.  I think 50
was just a safe bet.)

One compatibility measure taken in the 9P2000 kernels is that
all the old system calls are emulated, so that old binaries (at least
those that don't read directories) continue to work.  This implies
that we had to allow 50 and 51 as pread/pwrite, so we just
changed the numbers rather than have two for each.

Hence the gap.  There was in fact a summer student project using
40 and 41, but they got recycled for 9P2000 calls.

Pedantically,
Russ

Re: [9fans] Ephase question.

[rob pike, esq.]

> are these 10 depricated calls used anywhere? if i'm
> reading things right, they're all from the switch to
> 9p2000 (mm, plus ERRSTR change?), so i gather not.
> does any plan exist for removing these?

Some ancient binaries we have still contain them.
They do not appear in the libraries.

> and on the same topic, were write9p and read9p
> eliminated because they were considered redundant
> with pwrite and pread?

They became unnecessary because of the encapsulation
possible with thew new 9P, not because of pread and
pwrite.

> and, out of curiosity, were there ever syscalls for
> slots 48 and 49? if so, what'd they do?

I believe a summer student had something planned
there.

-rob

Re: [9fans] Ephase question.

[anothy]

are these 10 depricated calls used anywhere? if i'm
reading things right, they're all from the switch to
9p2000 (mm, plus ERRSTR change?), so i gather not.
does any plan exist for removing these?

and on the same topic, were write9p and read9p
eliminated because they were considered redundant
with pwrite and pread?

and, out of curiosity, were there ever syscalls for
slots 48 and 49? if so, what'd they do?
ア

Re: [9fans] Ephase question.

[Russ Cox]

I don't know.  Plan 9 has 48 system calls these days,
10 of which are deprecated.  So 38.  That's still a lot.

Re: [9fans] Ephase question.

[Douglas A. Gwyn]

Russ Cox wrote:
> I don't know.  Plan 9 has 48 system calls these days,
> 10 of which are deprecated.  So 38.  That's still a lot.

It would be an interesting academic exercise to determine the
minimal set.  E.g. close() doesn't seem to be needed; whenever
there's no reference to the object, any connection to it can be
cleaned up.  At least for Unix devices, it was only the *last*
close that did anything interesting.  And I've sometimes had
the feeling that bind and mount aren't dissimilar enough to
require separation.  The trick is to combine function in some
natural way, not merely tunnel through the syscall port then
expand again on the other side.

Would it be possible for a 9P-like system to make all service
calls just access a server within the protocol?  E.g., instead
of open() there would be a channel that handles 9P-open packets
(as well as other 9P packets).  (Apologies if I've garbled the
details; the general idea is all I'm wondering about.)

Re: [9fans] Ephase question.

[Russ Cox]

> I've just got v9fs back and mostly working on Linux (uses 9p still but 3e
> ... 4e is next). But I'm going to have the Unix semantics. The shared exec
> over a network case is too common not to use the Unix semantics.

And arguably you _should_ have the Unix semantics.  No one here is
saying that one way is required.  9P doesn't say anything about when
the remove happens.  It's a choice made by some file servers.
U9fs just does a Unix remove too, so you'd get Unix semantics there as well.

Russ

Re: [9fans] Ephase question.

[rob pike, esq.]

> would it be too nasty to make the fileserver refuse writes
> on files that are currenty open with OEXEC?

We talked a lot about this in the early design days.  If I recall
right we decided to allow the write, given permission, because
sometimes you really do want to update a binary and it's annoying when
you can't: build scripts fail, installs abort, that sort of thing.
There are times when we install everything and it's nice not to
worry about it.  Although it's far from perfect, I'm comfortable
enough with the safeinstall notion to leave things as they are.

I realize that's not much of an argument.

-rob

Re: [9fans] Ephase question.

[rog]

> My biggest headache has been replacing running binaries.  Since we
> can't remove them or overwrite them without disasterous consequences,
> we end up with a 'safeinstall' option in all our mkfiles.  The safeinstall
> moves the file to an unlikely name (e.g. x -> _x) and copies in the
> new file.  Of course, since we have dozens of machines all running off
> the same file system,  something is probably running off the _x that
> was there.  So we sometimes have to move _x to __x, etc.  It's a
> royal pain.  We often forget and just install with the result that
> someone an hour after the fact in some other part of the building
> sends you a snap or pointer to a broken process.  Since I don't have
> to implement the fs, I'ld have preferred the Unix semantics in this
> case.  It's caused me a lot of inconvenience over the last 10+ years.

i was going to mention this, but you did it for me.

would it be too nasty to make the fileserver refuse writes
on files that are currenty open with OEXEC?

that would alleviate somewhat the most common (and hard to find)
problem: overwriting a running binary.
(which can also be a problem for shellscripts, note)

  rog.

Re: [9fans] Ephase question.

[presotto]

> - Unix' solution of making the remove fail with "file busy"; it was
> always inconvenient and confusing.  They use that one for in use
> executables.

I'm clearly misremembering.  I was thinking of overwrite.  Don't know
why, had to remove a file last week on an SGI system to do just that.

> The really interesting question is how much pain did that cause when
> porting/rewriting software from Unix.  creat()/unlink()/work with fd
> you'd got from creat()  is definitely a common idiom.  OTOH, most of
> its uses are for situations when you either want remove-on-close
> or are messing with shared directories...
>
> How bad it had it actually been?

Russ addressed the ape library.

As someone, Rob?, has already mentioned, the close on remove
flag (ORCLOSE) flag on open/create does the same thing as unlinking
immediately after opening.

My biggest headache has been replacing running binaries.  Since we
can't remove them or overwrite them without disasterous consequences,
we end up with a 'safeinstall' option in all our mkfiles.  The safeinstall
moves the file to an unlikely name (e.g. x -> _x) and copies in the
new file.  Of course, since we have dozens of machines all running off
the same file system,  something is probably running off the _x that
was there.  So we sometimes have to move _x to __x, etc.  It's a
royal pain.  We often forget and just install with the result that
someone an hour after the fact in some other part of the building
sends you a snap or pointer to a broken process.  Since I don't have
to implement the fs, I'ld have preferred the Unix semantics in this
case.  It's caused me a lot of inconvenience over the last 10+ years.

> "Accident" in this case need not imply "unintentional".
> When Canaday et al. invented the inode-based system,
> it is conceivable that they thought the semantics were
> just what they wanted.

Since the same 'et al' implemented both the first Unix fs
and the first Plan 9 fs, I'll ask him and see what he says.

Re: [9fans] Ephase question.

[Ronald G Minnich]

On Tue, 13 Aug 2002 presotto@plan9.bell-labs.com wrote:

> My biggest headache has been replacing running binaries.  Since we
> can't remove them or overwrite them without disasterous consequences,
> we end up with a 'safeinstall' option in all our mkfiles.  The safeinstall
> moves the file to an unlikely name (e.g. x -> _x) and copies in the
> new file.  Of course, since we have dozens of machines all running off
> the same file system,  something is probably running off the _x that
> was there.  So we sometimes have to move _x to __x, etc.  It's a
> royal pain.

yes, NFS has a similar problem with this but in a different place. When
clients remove files, NFS servers don't really remove files, they rename
them. See SILLYRENAME. In NFS servers never know if someone is using a
file, so they don't want to remove it, hence all that .nfsxxyyzzww crud
you start to see in NFS over time (if the rm happens on client).

Of course if the rm happens on server, and a remote process is exec'ing
the file, bad things happen. This latter problem has led people over the
years to do the same kind of thing you describe above. Or, as in one place
I worked, the sysadmins upgrade executables on the server and then reboot
everybody's machine.

> We often forget and just install with the result that
> someone an hour after the fact in some other part of the building
> sends you a snap or pointer to a broken process.  Since I don't have
> to implement the fs, I'ld have preferred the Unix semantics in this
> case.  It's caused me a lot of inconvenience over the last 10+ years.

I've just got v9fs back and mostly working on Linux (uses 9p still but 3e
... 4e is next). But I'm going to have the Unix semantics. The shared exec
over a network case is too common not to use the Unix semantics.

ron

Re: [9fans] Ephase question.

[David Gordon Hogan]

> On freebsd and Linux, exec happens via an mmap (more or less). Possibly
> the behavioural difference you saw between binary and normal file was due
> to how the kernels handle mmap for exec vs. file I/O, not due to it being
> a binary vs. normal file.

So [gigantic leap here], not only does Linux have ~250 system
calls, but most of them can be emulated with mmap?

Re: [9fans] Ephase question.

[Ronald G Minnich]

On Tue, 13 Aug 2002, David Gordon Hogan wrote:

> So [gigantic leap here], not only does Linux have ~250 system
> calls, but most of them can be emulated with mmap?

Hmm, I'm hoping you're joking ... I just woke up but this made me want to
go hide under my bed.

I'm actually thinking I need a slide:

slide 1: linux system call list

Slide 2: plan 9 system call list to the same scale. The problem with slide
2 to the same scale as slide 1 is that it will look like fuzz on the
slide, not a system call list ... to get all those linux calls on 1 slide
I'll need a 1-pt font.

ron

Re: [9fans] Ephase question.

[Charles Forsyth]

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

so if i completely remove a file that someone is executing, it continues to work,
but if i copy into a file that remains and someone is executing it, it fails.

makes perfect sense to me.

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

From: Alexander Viro <viro@math.psu.edu>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] Ephase question.
Date: Tue, 13 Aug 2002 02:13:08 -0400 (EDT)
Message-ID: <Pine.GSO.4.21.0208130206400.1501-100000@weyl.math.psu.edu>



On Tue, 13 Aug 2002, Russ Cox wrote:

> > > - Unix' solution of making the remove fail with "file busy"; it was
> > > always inconvenient and confusing.  They use that one for in use
> > > executables.
> >
> > I haven't seen a version of unix do this one for a while (as in decades).
> > The remove succeeds, the file goes away when the last reference does (but
> > you have to have inodes ...). But maybe there is some version of Unix
> > you're referencing I'm not familiar with -- there's a lot of possibilities
> > out there nowadays ...
>
> i've seen it recently on either freebsd or linux,
> in the case of trying to remove or perhaps overwrite
> binaries that were being executed at the time.
> it was definitely a binary rather than a normal file.

Overwrite - sure.  Remove - nope.

Re: [9fans] Ephase question.

[Russ Cox]

APE simulates the creat()/unlink()/work idiom,
so APE-ported Unix programs would tend not to notice.
The programs I've natively ported have never cared.

Russ

Re: [9fans] Ephase question.

[rob pike, esq.]

>   I see. But can you give me any insight into why it was implemented this
>   way. Again, it seems so obvious to use fids for reference counting and it
>   shouldn't be of a significant overhead. Moreover it's entirely up to
>   the FileServer to support this feature -- kernel is not supposed to
>   care. You should've had some reason for not supporting this in all
>   your FileServers.

There was an implementation reason, which I don't remember.  I prefer
this argument:

	When you remove a file, it's removed.

That's the definition of remove, as I understand it.

Unix has a weird property that you can remove files and they're still not
removed until some unfindable process dies.  We used to run out of disk
space because an editor (mine) unlinked its /tmp file so it wouldn't clutter the
disk if it exited prematurely.  If someone edited a big file, /tmp would fill
up but ls /tmp wouldn't tell you anything.  Not to mention what happens
if the kernel crashed with a file in that half-made state.

open(ORCLOSE) is a much cleaner solution to the /tmp problem.

But the real argument is that Unix's semantics are an accident of the way
it implemented its file system.  Plan 9 has different semantics.  Whether
or not it's what you want, it's hard to argue with:

	When you remove a file, it's removed.


-rob

Re: [9fans] Ephase question.

[Douglas A. Gwyn]

"rob pike, esq." wrote:
> Unix's semantics are an accident of the way
> it implemented its file system.

"Accident" in this case need not imply "unintentional".
When Canaday et al. invented the inode-based system,
it is conceivable that they thought the semantics were
just what they wanted.

I actually *like* being able to have scratch files that have
no directory entries, because they are *guaranteed* to go
away when the processes using them all terminate.

> Plan 9 has different semantics.

Indeed.

Re: [9fans] Ephase question.

[presotto]

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

We chose it because it was easier to implement and we couldn't see
that doing so would cause undo hardship.  Rsc's observation is good
but wasn't really a design goal.

There are 3 obvious alternatives:
- Unix' solution of making the remove fail with "file busy"; it was
always inconvenient and confusing.  They use that one for in use
executables.  The fs doesn't really know when a file is executing so that
one isn't really that useful to us.
- Have the remove work but not really remove the file from the directory
till the current opener goes away.  That's just too confusing.
- Disassociate the file with the directory, but leave it around for anyone
that has it open to keep playing with.  This is easy to do when the
file is really represented by an inode that doesn't have anything to
do with a directory.  It's a lot harder without that indirection.  We
didn't have inodes.  The best we could do is copy it somewhere else
and fudge up pointers to the somewhere else (a special invisible
directory perhaps).  It also leads to cleaning up orphaned files
during a reboot of the file server, fsck's job (or one of many) in
Unix.  It gets messy quick without inodes being the one true
representation.

Clearly its a matter of taste; with enough code you can do most
anything.  If it were a goal, Ken would proabably have designed
his fs a bit differently.  Our taste, like our minds, tends to
favor the simple.  Of course, we're gradually losing our sense
of taste due to exigency. About time for a new simple operating
system.

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

From: "Roman V. Shaposhnick" <vugluskr@unicorn.math.spbu.ru>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] Ephase question.
Date: Tue, 13 Aug 2002 07:14:22 +0400
Message-ID: <20020813071422.A12044@unicorn.math.spbu.ru>

On Mon, Aug 12, 2002 at 09:39:40PM -0400, presotto@plan9.bell-labs.com wrote:
> This isn't new semantics.  If you remove a file that someone
> else is using, too bad for him.  There's nothing sacred about
> having a file open.

  Indeed. Same applies to any fid, not just opened ones.

> If someone else has permissions to do nasty and nefarious things to it,
> they can.
>
> This is very different than Unix.

  I see. But can you give me any insight into why it was implemented this
  way. Again, it seems so obvious to use fids for reference counting and it
  shouldn't be of a significant overhead. Moreover it's entirely up to
  the FileServer to support this feature -- kernel is not supposed to
  care. You should've had some reason for not supporting this in all
  your FileServers.

Thanks,
Roman.

> Received: from plan9.cs.bell-labs.com ([135.104.9.2]) by plan9; Mon Aug 12 21:27:18 EDT 2002
> Received: from mail.cse.psu.edu ([130.203.4.6]) by plan9; Mon Aug 12 21:27:17 EDT 2002
> Received: from psuvax1.cse.psu.edu (psuvax1.cse.psu.edu [130.203.8.6])
> 	by mail.cse.psu.edu (CSE Mail Server) with ESMTP
> 	id 04B4D199B9; Mon, 12 Aug 2002 21:27:07 -0400 (EDT)
> Delivered-To: 9fans@cse.psu.edu
> Received: from unicorn.math.spbu.ru (unicorn.math.spbu.ru [195.19.226.166])
> 	by mail.cse.psu.edu (CSE Mail Server) with ESMTP id 4D5C41998C
> 	for <9fans@cse.psu.edu>; Mon, 12 Aug 2002 21:26:20 -0400 (EDT)
> Received: (from vugluskr@localhost)
> 	by unicorn.math.spbu.ru (8.9.3/8.9.3) id FAA10626
> 	for 9fans@cse.psu.edu; Tue, 13 Aug 2002 05:26:18 +0400
> From: "Roman V. Shaposhnick" <vugluskr@unicorn.math.spbu.ru>
> To: 9fans@cse.psu.edu
> Message-ID: <20020813052618.A10336@unicorn.math.spbu.ru>
> Mime-Version: 1.0
> Content-Type: text/plain; charset=us-ascii
> X-Mailer: Mutt 1.0pre3i
> Subject: [9fans] Ephase question.
> Sender: 9fans-admin@cse.psu.edu
> Errors-To: 9fans-admin@cse.psu.edu
> X-BeenThere: 9fans@cse.psu.edu
> X-Mailman-Version: 2.0.11
> Precedence: bulk
> Reply-To: 9fans@cse.psu.edu
> List-Id: Fans of the OS Plan 9 from Bell Labs <9fans.cse.psu.edu>
> List-Archive: <https://lists.cse.psu.edu/archives/9fans/>
> Date: Tue, 13 Aug 2002 05:26:18 +0400
>
> Hi everybody,
>
> digging inside 4th edition gave me some very unexpected results
> in terms of file access semantics in user space. But let me show
> a scenario first:
>
> first-user$ cat > /shared-directory/file
> blah-blah-blah
>
> second-user$ rm /shared-directory/file
>
> [first user after hitting <CR> ]
> "phase error -- directory entry not allocated"
>
> I was a little bit shocked at first, mainly because I've got so used to
> UNIX semantics of "once you get it -- it's yours", that I've been taking
> it for granted in Plan9 as well.
>
> Suddenly I can't remember how 3nd and 2nd editions behaved.
>
> Before now I was under the impression that regular unopened fids are mostly
> used for reference counting and once you grab a fid nobody can kill the
> actual object it refers to, but 4th edition proved me wrong. Even though
> I still can't understand why it behaves this way. Could somebody explain
> the rationale behind that to me, please ? And I'm really curios now about
> what obligations server is supposed to have when it accepts a new fid from
> a client for a given object.
>
> Thanks,
> Roman.

Re: [9fans] Ephase question.

[Alexander Viro]

On Mon, 12 Aug 2002 presotto@plan9.bell-labs.com wrote:

> We chose it because it was easier to implement and we couldn't see
> that doing so would cause undo hardship.  Rsc's observation is good
> but wasn't really a design goal.

[snip the list of alternatives]

The really interesting question is how much pain did that cause when
porting/rewriting software from Unix.  creat()/unlink()/work with fd
you'd got from creat()  is definitely a common idiom.  OTOH, most of
its uses are for situations when you either want remove-on-close
or are messing with shared directories...

How bad it had it actually been?

Re: [9fans] Ephase question.

[Ronald G Minnich]

On Mon, 12 Aug 2002 presotto@plan9.bell-labs.com wrote:

> - Unix' solution of making the remove fail with "file busy"; it was
> always inconvenient and confusing.  They use that one for in use
> executables.

I haven't seen a version of unix do this one for a while (as in decades).
The remove succeeds, the file goes away when the last reference does (but
you have to have inodes ...). But maybe there is some version of Unix
you're referencing I'm not familiar with -- there's a lot of possibilities
out there nowadays ...

I just tried this 'cat > /tmp/a' and 'rm' sequence on Linux and it works
as the original poster expected. In the case of executables I think the
principle of least surprise dictates that removing an executable shouldn't
cause running instances of that executable to toss chunks and die. This
kind of behaviour was always a source of major pain for people running
executables from NFS servers.

On the other hand, removing a log file that is growing without bound and
having it just go away is really nice. The old search-and-destroy
technique you have to use on Unix for this type of thing is pretty ugly.

> - Have the remove work but not really remove the file from the directory
> till the current opener goes away.  That's just too confusing.

Ick. No argument there.

I wouldn't give up on your current simple OS just yet. Linux is going to
cross the 250-system-call mark soon, so you have a long way to go before
you're that crazy.

ron

Re: [9fans] Ephase question.

[Boyd Roberts]

Ronald G Minnich wrote:

>I haven't seen a version of unix do this one for a while (as in decades).
>The remove succeeds, the file goes away when the last reference does (but
>you have to have inodes ...).
>
Yes, removal was fixed with BSD so you no longer got ETXTBUSY; the
directory entry would
disappear but the inode would persist.

>But maybe there is some version of Unix
>you're referencing I'm not familiar with -- there's a lot of possibilities
>out there nowadays ...
>
However, this did not fix the over-write problem, which most/all unix'
still suffer from.

Re: [9fans] Ephase question.

[Andrew Lynch]

On Aug 12, 11:33pm, presotto@plan9.bell-labs.com wrote:
>
> We chose it because it was easier to implement and we couldn't see
> that doing so would cause undo hardship.

So how easily could first-user undo the delete?
Maybe Freud can tell us...

Andrew.

Re: [9fans] Ephase question.

[Roman V. Shaposhnick]

Thanks for the answer ( special thanks to Ken for providing historical
background ). The only thing I still wish for is couple of lines in
9P specification or any other document saying that, generally speaking,
Servers have no obligations whatsoever regarding returned fids. Fids can
be dangling.

As for simplicity -- I can't agree more. That's what make 9P and Plan9 so
appealing to me.

Roman.

On Mon, Aug 12, 2002 at 11:33:53PM -0400, presotto@plan9.bell-labs.com wrote:
> We chose it because it was easier to implement and we couldn't see
> that doing so would cause undo hardship.  Rsc's observation is good
> but wasn't really a design goal.
>
> There are 3 obvious alternatives:
> - Unix' solution of making the remove fail with "file busy"; it was
> always inconvenient and confusing.  They use that one for in use
> executables.  The fs doesn't really know when a file is executing so that
> one isn't really that useful to us.
> - Have the remove work but not really remove the file from the directory
> till the current opener goes away.  That's just too confusing.
> - Disassociate the file with the directory, but leave it around for anyone
> that has it open to keep playing with.  This is easy to do when the
> file is really represented by an inode that doesn't have anything to
> do with a directory.  It's a lot harder without that indirection.  We
> didn't have inodes.  The best we could do is copy it somewhere else
> and fudge up pointers to the somewhere else (a special invisible
> directory perhaps).  It also leads to cleaning up orphaned files
> during a reboot of the file server, fsck's job (or one of many) in
> Unix.  It gets messy quick without inodes being the one true
> representation.
>
> Clearly its a matter of taste; with enough code you can do most
> anything.  If it were a goal, Ken would proabably have designed
> his fs a bit differently.  Our taste, like our minds, tends to
> favor the simple.  Of course, we're gradually losing our sense
> of taste due to exigency. About time for a new simple operating
> system.
> Received: from plan9.cs.bell-labs.com ([135.104.9.2]) by plan9; Mon Aug 12 23:15:17 EDT 2002
> Received: from mail.cse.psu.edu ([130.203.4.6]) by plan9; Mon Aug 12 23:15:15 EDT 2002
> Received: from psuvax1.cse.psu.edu (psuvax1.cse.psu.edu [130.203.6.6])
> 	by mail.cse.psu.edu (CSE Mail Server) with ESMTP
> 	id DC934199DD; Mon, 12 Aug 2002 23:15:06 -0400 (EDT)
> Delivered-To: 9fans@cse.psu.edu
> Received: from unicorn.math.spbu.ru (unicorn.math.spbu.ru [195.19.226.166])
> 	by mail.cse.psu.edu (CSE Mail Server) with ESMTP id 661B919999
> 	for <9fans@cse.psu.edu>; Mon, 12 Aug 2002 23:14:24 -0400 (EDT)
> Received: (from vugluskr@localhost)
> 	by unicorn.math.spbu.ru (8.9.3/8.9.3) id HAA12130
> 	for 9fans@cse.psu.edu; Tue, 13 Aug 2002 07:14:22 +0400
> From: "Roman V. Shaposhnick" <vugluskr@unicorn.math.spbu.ru>
> To: 9fans@cse.psu.edu
> Subject: Re: [9fans] Ephase question.
> Message-ID: <20020813071422.A12044@unicorn.math.spbu.ru>
> References: <edbdeed0efb39dc5d9a1446470bbbdac@plan9.bell-labs.com>
> Mime-Version: 1.0
> Content-Type: text/plain; charset=us-ascii
> X-Mailer: Mutt 1.0pre3i
> In-Reply-To: <edbdeed0efb39dc5d9a1446470bbbdac@plan9.bell-labs.com>
> Sender: 9fans-admin@cse.psu.edu
> Errors-To: 9fans-admin@cse.psu.edu
> X-BeenThere: 9fans@cse.psu.edu
> X-Mailman-Version: 2.0.11
> Precedence: bulk
> Reply-To: 9fans@cse.psu.edu
> List-Id: Fans of the OS Plan 9 from Bell Labs <9fans.cse.psu.edu>
> List-Archive: <https://lists.cse.psu.edu/archives/9fans/>
> Date: Tue, 13 Aug 2002 07:14:22 +0400
>
> On Mon, Aug 12, 2002 at 09:39:40PM -0400, presotto@plan9.bell-labs.com wrote:
> > This isn't new semantics.  If you remove a file that someone
> > else is using, too bad for him.  There's nothing sacred about
> > having a file open.
>
>   Indeed. Same applies to any fid, not just opened ones.
>
> > If someone else has permissions to do nasty and nefarious things to it,
> > they can.
> >
> > This is very different than Unix.
>
>   I see. But can you give me any insight into why it was implemented this
>   way. Again, it seems so obvious to use fids for reference counting and it
>   shouldn't be of a significant overhead. Moreover it's entirely up to
>   the FileServer to support this feature -- kernel is not supposed to
>   care. You should've had some reason for not supporting this in all
>   your FileServers.
>
> Thanks,
> Roman.
>
> > Received: from plan9.cs.bell-labs.com ([135.104.9.2]) by plan9; Mon Aug 12 21:27:18 EDT 2002
> > Received: from mail.cse.psu.edu ([130.203.4.6]) by plan9; Mon Aug 12 21:27:17 EDT 2002
> > Received: from psuvax1.cse.psu.edu (psuvax1.cse.psu.edu [130.203.8.6])
> > 	by mail.cse.psu.edu (CSE Mail Server) with ESMTP
> > 	id 04B4D199B9; Mon, 12 Aug 2002 21:27:07 -0400 (EDT)
> > Delivered-To: 9fans@cse.psu.edu
> > Received: from unicorn.math.spbu.ru (unicorn.math.spbu.ru [195.19.226.166])
> > 	by mail.cse.psu.edu (CSE Mail Server) with ESMTP id 4D5C41998C
> > 	for <9fans@cse.psu.edu>; Mon, 12 Aug 2002 21:26:20 -0400 (EDT)
> > Received: (from vugluskr@localhost)
> > 	by unicorn.math.spbu.ru (8.9.3/8.9.3) id FAA10626
> > 	for 9fans@cse.psu.edu; Tue, 13 Aug 2002 05:26:18 +0400
> > From: "Roman V. Shaposhnick" <vugluskr@unicorn.math.spbu.ru>
> > To: 9fans@cse.psu.edu
> > Message-ID: <20020813052618.A10336@unicorn.math.spbu.ru>
> > Mime-Version: 1.0
> > Content-Type: text/plain; charset=us-ascii
> > X-Mailer: Mutt 1.0pre3i
> > Subject: [9fans] Ephase question.
> > Sender: 9fans-admin@cse.psu.edu
> > Errors-To: 9fans-admin@cse.psu.edu
> > X-BeenThere: 9fans@cse.psu.edu
> > X-Mailman-Version: 2.0.11
> > Precedence: bulk
> > Reply-To: 9fans@cse.psu.edu
> > List-Id: Fans of the OS Plan 9 from Bell Labs <9fans.cse.psu.edu>
> > List-Archive: <https://lists.cse.psu.edu/archives/9fans/>
> > Date: Tue, 13 Aug 2002 05:26:18 +0400
> >
> > Hi everybody,
> >
> > digging inside 4th edition gave me some very unexpected results
> > in terms of file access semantics in user space. But let me show
> > a scenario first:
> >
> > first-user$ cat > /shared-directory/file
> > blah-blah-blah
> >
> > second-user$ rm /shared-directory/file
> >
> > [first user after hitting <CR> ]
> > "phase error -- directory entry not allocated"
> >
> > I was a little bit shocked at first, mainly because I've got so used to
> > UNIX semantics of "once you get it -- it's yours", that I've been taking
> > it for granted in Plan9 as well.
> >
> > Suddenly I can't remember how 3nd and 2nd editions behaved.
> >
> > Before now I was under the impression that regular unopened fids are mostly
> > used for reference counting and once you grab a fid nobody can kill the
> > actual object it refers to, but 4th edition proved me wrong. Even though
> > I still can't understand why it behaves this way. Could somebody explain
> > the rationale behind that to me, please ? And I'm really curios now about
> > what obligations server is supposed to have when it accepts a new fid from
> > a client for a given object.
> >
> > Thanks,
> > Roman.

Re: [9fans] Ephase question.

[Russ Cox]

>   I see. But can you give me any insight into why it was implemented this
>   way. Again, it seems so obvious to use fids for reference counting and it
>   shouldn't be of a significant overhead. Moreover it's entirely up to
>   the FileServer to support this feature -- kernel is not supposed to
>   care. You should've had some reason for not supporting this in all
>   your FileServers.

If someone has a big runaway log file open that is running you out of
disk space, and you remove it, then it goes away.  That's a feature.
(Of course, we don't have this problem on the worm drive, but the
point stands.)  This way is simpler, and I've yet to see a compelling
argument against it.

You're right that the kernel doesn't care -- the file server is giving
you the phase error.  Many of the non-disk file systems do reference
count their files.

Russ

Re: [9fans] Ephase question.

[presotto]

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

This isn't new semantics.  If you remove a file that someone
else is using, too bad for him.  There's nothing sacred about
having a file open.  If someone else has permissions to do
nasty and nefarious things to it, they can.

This is very different than Unix.

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

From: "Roman V. Shaposhnick" <vugluskr@unicorn.math.spbu.ru>
To: 9fans@cse.psu.edu
Subject: [9fans] Ephase question.
Date: Tue, 13 Aug 2002 05:26:18 +0400
Message-ID: <20020813052618.A10336@unicorn.math.spbu.ru>

Hi everybody,

digging inside 4th edition gave me some very unexpected results
in terms of file access semantics in user space. But let me show
a scenario first:

first-user$ cat > /shared-directory/file
blah-blah-blah

second-user$ rm /shared-directory/file

[first user after hitting <CR> ]
"phase error -- directory entry not allocated"

I was a little bit shocked at first, mainly because I've got so used to
UNIX semantics of "once you get it -- it's yours", that I've been taking
it for granted in Plan9 as well.

Suddenly I can't remember how 3nd and 2nd editions behaved.

Before now I was under the impression that regular unopened fids are mostly
used for reference counting and once you grab a fid nobody can kill the
actual object it refers to, but 4th edition proved me wrong. Even though
I still can't understand why it behaves this way. Could somebody explain
the rationale behind that to me, please ? And I'm really curios now about
what obligations server is supposed to have when it accepts a new fid from
a client for a given object.

Thanks,
Roman.

Re: [9fans] Ephase question.

[Roman V. Shaposhnick]

On Mon, Aug 12, 2002 at 09:39:40PM -0400, presotto@plan9.bell-labs.com wrote:
> This isn't new semantics.  If you remove a file that someone
> else is using, too bad for him.  There's nothing sacred about
> having a file open.

  Indeed. Same applies to any fid, not just opened ones.

> If someone else has permissions to do nasty and nefarious things to it,
> they can.
>
> This is very different than Unix.

  I see. But can you give me any insight into why it was implemented this
  way. Again, it seems so obvious to use fids for reference counting and it
  shouldn't be of a significant overhead. Moreover it's entirely up to
  the FileServer to support this feature -- kernel is not supposed to
  care. You should've had some reason for not supporting this in all
  your FileServers.

Thanks,
Roman.

> Received: from plan9.cs.bell-labs.com ([135.104.9.2]) by plan9; Mon Aug 12 21:27:18 EDT 2002
> Received: from mail.cse.psu.edu ([130.203.4.6]) by plan9; Mon Aug 12 21:27:17 EDT 2002
> Received: from psuvax1.cse.psu.edu (psuvax1.cse.psu.edu [130.203.8.6])
> 	by mail.cse.psu.edu (CSE Mail Server) with ESMTP
> 	id 04B4D199B9; Mon, 12 Aug 2002 21:27:07 -0400 (EDT)
> Delivered-To: 9fans@cse.psu.edu
> Received: from unicorn.math.spbu.ru (unicorn.math.spbu.ru [195.19.226.166])
> 	by mail.cse.psu.edu (CSE Mail Server) with ESMTP id 4D5C41998C
> 	for <9fans@cse.psu.edu>; Mon, 12 Aug 2002 21:26:20 -0400 (EDT)
> Received: (from vugluskr@localhost)
> 	by unicorn.math.spbu.ru (8.9.3/8.9.3) id FAA10626
> 	for 9fans@cse.psu.edu; Tue, 13 Aug 2002 05:26:18 +0400
> From: "Roman V. Shaposhnick" <vugluskr@unicorn.math.spbu.ru>
> To: 9fans@cse.psu.edu
> Message-ID: <20020813052618.A10336@unicorn.math.spbu.ru>
> Mime-Version: 1.0
> Content-Type: text/plain; charset=us-ascii
> X-Mailer: Mutt 1.0pre3i
> Subject: [9fans] Ephase question.
> Sender: 9fans-admin@cse.psu.edu
> Errors-To: 9fans-admin@cse.psu.edu
> X-BeenThere: 9fans@cse.psu.edu
> X-Mailman-Version: 2.0.11
> Precedence: bulk
> Reply-To: 9fans@cse.psu.edu
> List-Id: Fans of the OS Plan 9 from Bell Labs <9fans.cse.psu.edu>
> List-Archive: <https://lists.cse.psu.edu/archives/9fans/>
> Date: Tue, 13 Aug 2002 05:26:18 +0400
>
> Hi everybody,
>
> digging inside 4th edition gave me some very unexpected results
> in terms of file access semantics in user space. But let me show
> a scenario first:
>
> first-user$ cat > /shared-directory/file
> blah-blah-blah
>
> second-user$ rm /shared-directory/file
>
> [first user after hitting <CR> ]
> "phase error -- directory entry not allocated"
>
> I was a little bit shocked at first, mainly because I've got so used to
> UNIX semantics of "once you get it -- it's yours", that I've been taking
> it for granted in Plan9 as well.
>
> Suddenly I can't remember how 3nd and 2nd editions behaved.
>
> Before now I was under the impression that regular unopened fids are mostly
> used for reference counting and once you grab a fid nobody can kill the
> actual object it refers to, but 4th edition proved me wrong. Even though
> I still can't understand why it behaves this way. Could somebody explain
> the rationale behind that to me, please ? And I'm really curios now about
> what obligations server is supposed to have when it accepts a new fid from
> a client for a given object.
>
> Thanks,
> Roman.

[9fans] Ephase question.

[Roman V. Shaposhnick]

Hi everybody,

digging inside 4th edition gave me some very unexpected results
in terms of file access semantics in user space. But let me show
a scenario first:

first-user$ cat > /shared-directory/file
blah-blah-blah

second-user$ rm /shared-directory/file

[first user after hitting <CR> ]
"phase error -- directory entry not allocated"

I was a little bit shocked at first, mainly because I've got so used to
UNIX semantics of "once you get it -- it's yours", that I've been taking
it for granted in Plan9 as well.

Suddenly I can't remember how 3nd and 2nd editions behaved.

Before now I was under the impression that regular unopened fids are mostly
used for reference counting and once you grab a fid nobody can kill the
actual object it refers to, but 4th edition proved me wrong. Even though
I still can't understand why it behaves this way. Could somebody explain
the rationale behind that to me, please ? And I'm really curios now about
what obligations server is supposed to have when it accepts a new fid from
a client for a given object.

Thanks,
Roman.

Re: [9fans] Getting started in Plan9 - help

[David Gordon Hogan]

> On Unix systems since around 7th Edition, one can bind any input
> character to the INTR function, and the DEL character was the
> default (somewhat confused by Berkeleyites who tried to change
> to DEC OS conventions: ^C -> INTR, DEL -> char-erase, etc.).
> ^? is just a way of representing the ASCII DEL character using
> printable notation; the actual character is still DEL (0x7F).

What _really_ annoys me is when I hit the BACKSPACE key on
the keyboard, while running some terminal emulator, and it
sends DELETE.  This has a tendency to make me feel homicidal.

Actually, xterm is doing it to me right now.  xev receives the
keystroke correctly as "keycode 64 (keysym 0xff08, BackSpace)",
then xterm says, duh, I think you want delete.  Grrrr!

Of course, xterm is configurable through some resource, but
the default should be that backspace is backspace.

Re: [9fans] Getting started in Plan9 - help

[Douglas A. Gwyn]

David Gordon Hogan wrote:
> What _really_ annoys me is when I hit the BACKSPACE key on
> the keyboard, while running some terminal emulator, and it
> sends DELETE.

DEC actually started making terminals like that!

> the default should be that backspace is backspace.

I agree..

Re: [9fans] Getting started in Plan9 - help

[Thomas Bushnell, BSG]

"Douglas A. Gwyn" <DAGwyn@null.net> writes:

> David Gordon Hogan wrote:
> > What _really_ annoys me is when I hit the BACKSPACE key on
> > the keyboard, while running some terminal emulator, and it
> > sends DELETE.
> 
> DEC actually started making terminals like that!
> 
> > the default should be that backspace is backspace.
> 
> I agree..

The ASCII standard fortunately solves this one, and you're both wrong.

The ASCII BS charactec is specifically to help the "backup and
overstrike" operation.  For example, à is supposed to be rendered as 

  a BS `

The ASCII sequence for "ignore last character transmitted" is:

  BS DEL

That is, DEL is *overstruck* on a character to delete it.  Note the
nice way this works on paper tape: DEL is all-ones, so that means a
paper tape reader should ignore all-ones.  It's also supposed to
ignore NUL (all-zeros); some hardware could not be relied upon to deal
so accurately with spacing, and false reads of all-zeros would happen.

Thomas

Re: [9fans] Getting started in Plan9 - help

[Ronald G Minnich]

On Wed, 23 Jan 2002, Thomas Bushnell, BSG wrote:

> The ASCII standard fortunately solves this one, and you're both wrong.

yeah but I don't care. I want the keyboard to do what I want, not ride
some standard defined when we all used KSRs for terminals. I dismantled
and threw my Teletypes out 25 years ago (although I saved some pictures --
heroic hardware, that stuff was).

ron

Re: [9fans] Getting started in Plan9 - help

[Scott Schwartz]

> The ASCII standard

I thought Plan 9 had given up on that? :-)

Re: [9fans] Getting started in Plan9 - help

[Thomas Bushnell, BSG]

rminnich@lanl.gov (Ronald G Minnich) writes:

> yeah but I don't care. I want the keyboard to do what I want, not ride
> some standard defined when we all used KSRs for terminals. I dismantled
> and threw my Teletypes out 25 years ago (although I saved some pictures --
> heroic hardware, that stuff was).

Sure, but to get the keyboard to "do what you want" doesn't say
anything about what internal coding the key sends.

I want the "big key with the arrow" to delete the previous character.
I couldn't care less whether that is internally coded with 010 or 0177.

Thomas

Re: [9fans] Getting started in Plan9 - help

[Boyd Roberts]

"Thomas Bushnell, BSG" wrote:
> The ASCII BS charactec is specifically to help the "backup and
> overstrike" operation.

Some unix tty drivers would do this.  They'd overstrike with a space
and then a BS :)

Re: [9fans] Getting started in Plan9 - help

[Thomas Bushnell, BSG]

boyd@strakt.com (Boyd Roberts) writes:

> "Thomas Bushnell, BSG" wrote:
> > The ASCII BS charactec is specifically to help the "backup and
> > overstrike" operation.
>
> Some unix tty drivers would do this.  They'd overstrike with a space
> and then a BS :)

Some overstrikes are easier than others.

There are two misunderstandings about ASCII that piss me off, that's
all.

One misunderstanding is that "ASCII doesn't represent accents", which
is totally wrong; it was deliberately constructed to allow for accents
for all/many languages that use the latin alphabet.  The idea was (as
I mentioned previously) to use overstriking.

Now it turns out that the idea was not as good as just separate codes
for the accents (though that has its problems too), but it's not like
there was some American chauvinism that didn't bother to think about
other languages.

The other thing that pisses me off is people complaining that this or
that character is "the erase character" in ASCII, and complaining that
some system is using a different character.  ASCII has no erase
character (just as it has no newline character), and there is no "one
true character" for erase, any more than there is one true C brace
indenting style or one true endianness.

Thomas

Re: [9fans] Getting started in Plan9 - help

[David Arnold]

-->"Thomas" == Thomas Bushnell, BSG <tb+usenet@becket.net> writes:

  Thomas> ASCII has no erase character (just as it has no newline
  Thomas> character), and there is no "one true character" for erase,
  Thomas> any more than there is one true C brace indenting style or
  Thomas> one true endianness.

just to expose my ignorance, what was the intended meaning of DEL (127) ?




d

Re: [9fans] Getting started in Plan9 - help

[Thomas Bushnell, BSG]

arnold@dstc.monash.edu.au (David Arnold) writes:

> -->"Thomas" == Thomas Bushnell, BSG <tb+usenet@becket.net> writes:
>
>   Thomas> ASCII has no erase character (just as it has no newline
>   Thomas> character), and there is no "one true character" for erase,
>   Thomas> any more than there is one true C brace indenting style or
>   Thomas> one true endianness.
>
> just to expose my ignorance, what was the intended meaning of DEL (127) ?

As I mentioned before, DEL and NUL were the two ignored characters.

To tell the receiver to erase the last received character, you would
send a BS DEL sequence; that is, you'd overstrike the last character
with a DEL character.  On paper tape, that did exactly the right thing
very cleverly without any special handling; other media were supposed
to DTRT.

To delete n characters, obviously, you sound BS^n DEL^n, and certainly
not (BS DEL)^n.

There may have been additional meanings to DEL, but the only one I
know of is as part of a BS DEL sequenc.e.

Thomas

Re: [9fans] Getting started in Plan9 - help

[Dan Cross]

> To delete n characters, obviously, you sound BS^n DEL^n, and certainly
> not (BS DEL)^n.

I think you mean BS * n followed by DEL * n.  You want repitition, not
exponentiation (which would be meaningless, I think).  The operation in
this context is non-distributive, though.

> There may have been additional meanings to DEL, but the only one I
> know of is as part of a BS DEL sequenc.e.

Is this one of those, ``well, people are still posting about this
subject, therefore I feel no need to worry about its topicality...''
things?

Surely there are more important things to worry about, like getting
the Atari 2600 simulator working....

	- Dan C.

Re: [9fans] Getting started in Plan9 - help

[Thomas Bushnell, BSG]

cross@math.psu.edu (Dan Cross) writes:

> > To delete n characters, obviously, you sound BS^n DEL^n, and certainly
> > not (BS DEL)^n.
>
> I think you mean BS * n followed by DEL * n.  You want repitition, not
> exponentiation (which would be meaningless, I think).  The operation in
> this context is non-distributive, though.

In formal languages theory, "product" is usually concatenation,
"exponentiation" is repeated concatenation.  (For example, one says
that a DFA can scan A^n but not A^n B^n; one says that a context free
grammar can parse A^n B^n but not A^n B^n C^n.)

Your notation would have "addition" to be concatenation, and "product"
to be repeated concatenation.  That convention would work as well, but
since addition is conventionally always commutative, and product is
not, it's a more confusing convention.  (As you note, it suggests a
distributive property which of course does not exist.)

In other words, we agree about substance but are just using different
notations.

> > There may have been additional meanings to DEL, but the only one I
> > know of is as part of a BS DEL sequenc.e.
>
> Is this one of those, ``well, people are still posting about this
> subject, therefore I feel no need to worry about its topicality...''
> things?

Of course.  :)  Plus I think it's fun.

> Surely there are more important things to worry about, like getting
> the Atari 2600 simulator working....

Well, or getting Plan 9 to boot on my laptop.

Re: [9fans] Getting started in Plan9 - help

[Dan Cross]

> In formal languages theory, "product" is usually concatenation,
> "exponentiation" is repeated concatenation.  (For example, one says
> that a DFA can scan A^n but not A^n B^n; one says that a context free
> grammar can parse A^n B^n but not A^n B^n C^n.)

Whoops, I should have realized that's what you were refering to.  My bad.

	- Dan C.

Re: [9fans] Getting started in Plan9 - help

[Boyd Roberts]

> In formal languages theory, "product" is usually concatenation,
> "exponentiation" is repeated concatenation.

Depends on your domain.  In mathematics a product could be a dot
[rc's ^] or a cross product [trickier].

Re: [9fans] Getting started in Plan9 - help

[Douglas A. Gwyn]

Boyd Roberts wrote:
> Depends on your domain.  In mathematics a product could be a dot
> [rc's ^] or a cross product [trickier].

There are all sorts of "products" in mathematics,
but the so-called "cross product" is one of the least qualified
to go by that name.

[OT] Re: [9fans] Getting started in Plan9 - help

[paurea]

Douglas A. Gwyn writes:
 > There are all sorts of "products" in mathematics,
 > but the so-called "cross product" is one of the least qualified
 > to go by that name.

I don't think so. It is the dual of the sesquilineal projection of the
tensorial product. I couln't resist writing it. :-)

The fact that it is anticonmutative doesn't stop it being a product,
it distributes with the sum and has an absorbing element (I don't know if
it is called so in English) and has all sorts of properties which make it a
product.

--
                 Saludos,
                         Gorka

"Curiosity sKilled the cat"

Re: [OT] Re: [9fans] Getting started in Plan9 - help

[Thomas Bushnell, BSG]

paurea@gsyc.escet.urjc.es writes:

> The fact that it is anticonmutative doesn't stop it being a product,
> it distributes with the sum and has an absorbing element (I don't know if
> it is called so in English) and has all sorts of properties which make it a
> product.

I think "absorbing element" in English is just called "zero" (if I'm
guessing right at what you mean).  In whatever ring, the additive
identity is always called "zero".

Thomas

[9fans] upas/fs -f/imap faltering start

[Matt H]

Well my plan9 box is up again (woohoo)
I fiddled for ages with ndb & termrc only to discover that my 2114x NIC
didn't like the CAT5 cable (which works fine on a dlink 530tx!)

first thing I went for is mail, hoping to post my success from there
great to see imap & pop3 have made it into upas but sadly :

%upas/fs -f/imap/tcp!192.168.1.100!143/matt
%success
%unexpected line: INFO: LOGIN, user=user, ip=[127.0.0.1]
%upas/fs: opening mailbox: error in initial handshake

I'm trying to attach to courier IMAP on FreeBSD4.4

any clues or docs I can look at

cheers
Matt

Re: [OT] Re: [9fans] Getting started in Plan9 - help

[Douglas A. Gwyn]

paurea@gsyc.escet.urjc.es wrote:
> I don't think so. [The "cross product"] is the dual of the
> sesquilineal projection of the tensorial product. ...

As usually defined the c.p. is supposed to result in the same
type as its arguments, but e.g. the c.p. of two vectors is
*not* a vector (it's a so-called pseudo- or axial vector,
which can indeed be thought of as a *component* of the tensor
product).  So while it might be a "product" it is not as nice
as the kinds of products that map from space x space into space.
The "non-conservation of parity" work that was awarded a Nobel
prize seems to actually have been confusion on this very score.

Re: [OT] Re: [9fans] Getting started in Plan9 - help

[paurea]

Douglas A. Gwyn writes:
 > As usually defined the c.p. is supposed to result in the same
 > type as its arguments, but e.g. the c.p. of two vectors is
 > *not* a vector (it's a so-called pseudo- or axial vector,

Well, as everything, depends on what you call type. Everything here
are Tensors at least. (and also vectors, because tensor spaces are
vector spaces).

Anyway I think you confusing the c.p. with the wedge product which is
it's dual in an special case. As far as I know the c.p. of two vectors
is a vector. In fact, it is the special case of aplying the dual
operator to the wedge product with N=3 and r=2, that is, the result is
also a vector in the same space, that is why it is called vector
product too.

The tensors which written as a wedge product form a tensor are called its
strict components (I think you are referring to that). Anyway, the
wedge product of a group of tensors is a tensor too. And *all* of this
operations are called products, though that is exterior algebra and maybe
the analogy has been taken a little bit too far.

--
                 Saludos,
                         Gorka

"Curiosity sKilled the cat"

Re: [OT] Re: [9fans] Getting started in Plan9 - help

[Thomas Bushnell, BSG]

paurea@gsyc.escet.urjc.es writes:

> Well, as everything, depends on what you call type. Everything here
> are Tensors at least. (and also vectors, because tensor spaces are
> vector spaces).

Two tensors are of the same type if they have the same formal
character: that is, the same rank (and, if you are allowing covectors,
then the same rank and the same indexes "up" and "down").

> Anyway I think you confusing the c.p. with the wedge product which is
> it's dual in an special case. As far as I know the c.p. of two vectors
> is a vector.

Only in three dimensions.

Re: [OT] Re: [9fans] Getting started in Plan9 - help

[Douglas A. Gwyn]

paurea@gsyc.escet.urjc.es wrote:
> Anyway I think you confusing the c.p. with the wedge product which is
> it's dual in an special case.

No, read on...

> As far as I know the c.p. of two vectors is a vector.

No, it is not, and the fact that people treat it as one is the problem.
The *geometric object* that is the closest thing to the c.p. is a skew
tensor (practically the same as wedge product), which (only) in 3D has
Cartesian components that resemble those of a vector, *except* that
this pseudo-vector *flips* under reflection (unlike a genuine vector).
Unfortunately, physicists have been trained to express Maxwell's laws
as a relationship between a genuine vector (field) and a c.p., which
means that that expression of those laws *changes* under reflection,
something that physicists are *not* taught and which appears to have
been overlooked in the analysis of the (nonconservation of) parity
experiment.

Apologies for being off-topic, but the subject arose in this group..

Re: [OT] Re: [9fans] Getting started in Plan9 - help

[Thomas Bushnell, BSG]

"Douglas A. Gwyn" <DAGwyn@null.net> writes:

> As usually defined the c.p. is supposed to result in the same
> type as its arguments, but e.g. the c.p. of two vectors is
> *not* a vector (it's a so-called pseudo- or axial vector,
> which can indeed be thought of as a *component* of the tensor
> product).  So while it might be a "product" it is not as nice
> as the kinds of products that map from space x space into space.
> The "non-conservation of parity" work that was awarded a Nobel
> prize seems to actually have been confusion on this very score.

Sure enough.  The cross product as tensor-product-with-volume-element
makes this even clearer; the result of the "product" is actually a
higher rank tensor than the arguments.

Re: [OT] Re: [9fans] Getting started in Plan9 - help

[Andrew Simmons]

>The "non-conservation of parity" work that was awarded a Nobel
>prize seems to actually have been confusion on this very score.
>
Apologies to the group for wasting bandwidth, but I'd be interested if you
could provide a pointer to somewhere I could find out more about this
(amateur's interest, having done a PhD in this stuff years ago).

Thanks

Re: [OT] Re: [9fans] Getting started in Plan9 - help

[George Michaelson]

>>The "non-conservation of parity" work that was awarded a Nobel
>>prize seems to actually have been confusion on this very score.
>>
>Apologies to the group for wasting bandwidth, but I'd be interested if you
>could provide a pointer to somewhere I could find out more about this
>(amateur's interest, having done a PhD in this stuff years ago).
>
>Thanks

Martin Gardiner wrote this up years ago in a Pelican. If you search on
his name at amazon for:

	"The Ambidextrous Universe"


You'll find the re-issue brought up to date.

cheers
	-George

You'll find the information.

cheers
	-George

[Ever more OT] Re: [9fans] Getting started in Plan9 - help

[Andrew Simmons]

>Martin Gardiner wrote this up years ago in a Pelican. If you search on
>his name at amazon for:
>
>	"The Ambidextrous Universe"
>
Thanks for that. I read the original a long time ago. I was actually
interested in the specific idea that the Nobel prizewinning work of Lee &
Yang was based on a confusion, and don't remember that from the book - is
there anything on this topic in the updated version?

Re: [OT] Re: [9fans] Getting started in Plan9 - help

[Douglas A. Gwyn]

Non-conservation of parity is usually discussed under "CPT",
which should be in the index of many textbooks, predating the Web.
My assessment of the analytical error dates back to around 1967 but
has not been published.  In fact I got out of physics as a profession
mainly because my attempts to publish (other) theoretical work met
with repeated opposition from reviewers who did not want to
recognize that they had been chasing chimeras.  I didn't want to
be frustrated my whole career, so I moved into computing instead.

Re: [OT] Re: [9fans] Getting started in Plan9 - help

[Lucio De Re]

On Thu, Jan 31, 2002 at 12:28:13AM -0500, Douglas A. Gwyn wrote:
>
> [ ... ] I didn't want to
> be frustrated my whole career, so I moved into computing instead.

Huh?!

++L

Re: [OT] Re: [9fans] Getting started in Plan9 - help

[Douglas A. Gwyn]

Lucio De Re wrote:
> Huh?!

Drat, that was the second time I tried to reply to "sender" in
Netscape and had it go to Reply-To rather than to From (Andrew).

Re: [OT] Re: [9fans] Getting started in Plan9 - help

[Lucio De Re]

On Thu, Jan 31, 2002 at 09:43:15AM +0000, Douglas A. Gwyn wrote:
>
> Lucio De Re wrote:
> > Huh?!
>
> Drat, that was the second time I tried to reply to "sender" in
> Netscape and had it go to Reply-To rather than to From (Andrew).

Well, you made it sound like computing was less frustrating than
mainline physics.  Heard any good M$ jokes lately?

++L

PS: I dunno about comp.os.plan9 but 9fans is pleasantly tolerant of
off-topic discussion, I vote to keep it that way.

Re: [OT] Re: [9fans] Getting started in Plan9 - help

[Douglas A. Gwyn]

Lucio De Re wrote:
> Well, you made it sound like computing was less frustrating than
> mainline physics.  Heard any good M$ jokes lately?

Undoubtedly *some* aspects of computing are frustrating
(how about everybody who tries to get Plan 9 working on
unsupported hardware?), but I don't find the whole
*profession* frustrating.  At least not until mandatory
certification, which is something that we're threatened
with every so often.

Re: [OT] Re: [9fans] Getting started in Plan9 - help

[Boyd Roberts]

"Douglas A. Gwyn" wrote:
> ... I didn't want to
> be frustrated my whole career, so I moved into computing instead.

Another physics / comp sci swap.  Interesting.

I think we have 3 or 4 here.

Re: [OT] Re: [9fans] Getting started in Plan9 - via physics

[Matt H]

On Thu, 31 Jan 2002 12:22:21 +0100
"Boyd Roberts" <boyd@strakt.com> wrote:

> "Douglas A. Gwyn" wrote:
> > ... I didn't want to
> > be frustrated my whole career, so I moved into computing instead.
>
> Another physics / comp sci swap.  Interesting.
>
> I think we have 3 or 4 here.

When I arrived at Uni for my Comp Sci degree they included physics modules

I dropped out after 2 of 4 yrs

M

Re: [OT] Re: [9fans] Getting started in Plan9 - help

[Douglas A. Gwyn]

Non-conservation of parity is usually discussed under "CPT",
which should be in the index of many textbooks, predating the Web.
My assessment of the analytical error dates back to around 1967 but
has not been published.  In fact I got out of physics as a profession
mainly because my attempts to publish (other) theoretical work met
with repeated opposition from reviewers who did not want to
recognize that they had been chasing chimeras.  I didn't want to
be frustrated my whole career, so I moved into computing instead.

Re: [OT] Re: [9fans] Getting started in Plan9 - help

[Thomas Bushnell, BSG]

DAGwyn@null.net (Douglas A. Gwyn) writes:

> Non-conservation of parity is usually discussed under "CPT",
> which should be in the index of many textbooks, predating the Web.
> My assessment of the analytical error dates back to around 1967 but
> has not been published.

So the usual rule (as I was taught it) is that parity alone is not
conserved, but the product of parity, time, and charge is conserved.
(Perhaps I've got that slightly wrong.)  Is this not actually correct?
Gardner says roughly what I said.

So are there references that back up what you are saying, that this is
not in fact the case?

Re: [OT] Re: [9fans] Getting started in Plan9 - help

[Douglas A. Gwyn]

"Thomas Bushnell, BSG" wrote:
> So are there references that back up what you are saying, ...

What I am saying is that if parity was *not* conserved, the
theoretical analysis behind the famous experiments (on weak
decay) did not demonstrate it, due to not accounting for the
non-vectorial nature of the c.p. in the form of Maxwell's laws
used in the analysis.

I have my own reasons to think that mirror symmetry *has* to
be a fundamental property of physics and that any asymmetry
is environmentally induced.

Re: [OT] Re: [9fans] Getting started in Plan9 - help

[Thomas Bushnell, BSG]

"Douglas A. Gwyn" <DAGwyn@null.net> writes:

> What I am saying is that if parity was *not* conserved, the
> theoretical analysis behind the famous experiments (on weak
> decay) did not demonstrate it, due to not accounting for the
> non-vectorial nature of the c.p. in the form of Maxwell's laws
> used in the analysis.

Gotcha.  Where can I read about it?

> I have my own reasons to think that mirror symmetry *has* to
> be a fundamental property of physics and that any asymmetry
> is environmentally induced.

Sure, I think that's why the original result was so
counter-intuitive.  There are profound metaphysical reasons to insist
on certain physical symmetries.

[9fans] Cross products - longish & boring, but now officially on topic!

[Andrew Simmons]

Since this topic is now in the FAQ, I presume that I'm allowed to drone on
about it a bit more. Besides, it means I can put off wrestling with CORBA
for a few minutes.

I'm confused. When I was a lad we were taught that there were two types of
vector, polar and axial which differed in their behaviour under reflection
of the co-ordinate system. The fact that the cross product of two polar
vectors is an axial vector doesn't mean that axial vectors aren't really
vectors, any more than the fact that the product of two negative integers
is a positive integer means that positive integers aren't really integers.

I'm not sure what the problem with Maxwell's equations is. The electric
field E is a polar vector, but the magnetic field B is an axial vector.
Since the curl of an axial vector is polar, and vice versa, it is perfectly
kosher to relate the curl of E to the time derivative of B, both terms
being axial vectors, and hence the equation being invariant under
reflection. Similarly with the equation involving the curl of B, where both
sides are polar.

As far as I understand Lee & Yang's analysis of the parity experiments,
which is admittedly not very far, they explained the asymmetry in the decay
of the Cobalt nucleus by mixing polar (momentum) and axial (angular
momentum) vectors in the same equation, and so unlike Maxwell's equations
theirs does change under reflection.

>I have my own reasons to think that mirror symmetry *has* to
>be a fundamental property of physics and that any asymmetry
>is environmentally induced.
>
I'm suspicious of any attempt to say what nature has to look like on a
priori grounds, but to pursue this would be majorly off-topic. Unless Mr
Kotsopoulos can be persuaded to add a new entry to the FAQ, perhaps with
the title "Can there be synthetic a priori propositions?"

The above probably indirectly addresses Boyd's musing about the
physics/computing crossover. I don't think I could possibly support a wife,
a child, and a gin habit doing this sort of stuff.

Oh well, back to CORBA. I feel SO much better having to deal with the whole
filthy mess since Reiser told us it was influenced by Plan 9.

Re: [OT] Re: [9fans] Getting started in Plan9 - help

[Thomas Bushnell, BSG]

"Douglas A. Gwyn" <DAGwyn@null.net> writes:

> The "non-conservation of parity" work that was awarded a Nobel
> prize seems to actually have been confusion on this very score.

Um, the non-conservation of parity is part of the assymetry of certain
weak decay modes, right?

Re: [9fans] Getting started in Plan9 - help

[Boyd Roberts]

"Thomas Bushnell, BSG" wrote:
> One misunderstanding is that "ASCII doesn't represent accents", which
> is totally wrong; it was deliberately constructed to allow for accents
> for all/many languages that use the latin alphabet.  The idea was (as
> I mentioned previously) to use overstriking.
>
> Now it turns out that the idea was not as good ...

s/not as good/ghastly/

Re: [9fans] Getting started in Plan9 - help

[Thomas Bushnell, BSG]

boyd@strakt.com (Boyd Roberts) writes:

> "Thomas Bushnell, BSG" wrote:
> > One misunderstanding is that "ASCII doesn't represent accents", which
> > is totally wrong; it was deliberately constructed to allow for accents
> > for all/many languages that use the latin alphabet.  The idea was (as
> > I mentioned previously) to use overstriking.
> >
> > Now it turns out that the idea was not as good ...
>
> s/not as good/ghastly/

Well, there are lots of multibyte fans out there still.   But hey, it
was really the very first guess; I think they should get *some*
credit. :)

Re: [9fans] Getting started in Plan9 - help

[Douglas A. Gwyn]

"Thomas Bushnell, BSG" wrote:
> The ASCII BS charactec is specifically to help the "backup and
> overstrike" operation.

Actually it's just the backspace part of that composite operation,
which is what we said.

> That is, DEL is *overstruck* on a character to delete it.  Note the
> nice way this works on paper tape: DEL is all-ones, so that means a
> paper tape reader should ignore all-ones.  It's also supposed to
> ignore NUL (all-zeros); some hardware could not be relied upon to deal
> so accurately with spacing, and false reads of all-zeros would happen.

That's a bit revisionist; no paper tape punch that I know of
ever automatically reversed tape motion upon receipt of a BS
character.  The overstrike-DEL-to-delete was done *manually*
when preparing tapes off line.  The ignore-NUL mode was normally
used only for the *initial* mode of each tape ("file"), i.e.
to skip leader, with embedded NUL characters often used in binary
encodings.

Another cute thing:  The ASR-33 didn't immediately stop the reader
when an XOFF was read, and it didn't even stop reliably after the
*next* character had already passed, unless that character was a
DEL.  (Apparently when all 8 sensing fingers activated there was a
big enough dump of mechanical energy to ensure reliable stopping.)
Therefore, Honeywell's source tape convention was LF, text, CR,
XOFF, DEL (usually called RUBOUT rather than DEL).  The funny
split of the LF and CR actions allowed the assembler to input a
line from the reader with echo-print on the paper, then starting
from the new (beginning-of-line) position it would print the
object code, at some point sending a TAPE-ON (DC2) to enable the
punch unit and then the binary record, which used all nonprinting,
nonmotion characters (including BEL, ding ding) then TAPE-OFF (DC4).
At which point XON (DC1) would be sent to enable the reader which
would input the next text line (starting with that echoed LF to
clear the just-completed line on the paper).  A nifty way to use
the ASR-33 for a complete one-pass assembly process with object
code and full output listing.  You can investigate this using
one of the Honeywell Series-16 (+ ASR-33) simulators (Sapere's or
Supnick's) and the DAP assembler (available at Sapere's site).

Re: [9fans] Getting started in Plan9 - help

[Boyd Roberts]

David Gordon Hogan wrote:
> What _really_ annoys me is when I hit the BACKSPACE key on
> the keyboard, while running some terminal emulator, and it
> sends DELETE.  This has a tendency to make me feel homicidal.

I'm with you Captain, I can already smell the napalm burning...

I tried to fight that fight with a cordless Logitech iTouch,
X11, xterm and xmodmap and gave up in disgust at some point
last week.

The _really freaky thing_ is that when I type 8 bit chars
on my Swedish qwerty keyboard _in some windows_ I see
Cyrillic.  I can read it, but it doesn't make matters
any better.

I won't even touch KDE.  If I want a window [xterm] I use 'x':

    x [ hostname ]

Actually I'd like to build jammers for these horrible cordless
things :)

Re: [9fans] Getting started in Plan9 - help

[Thomas Bushnell, BSG]

dhog@plan9.bell-labs.com (David Gordon Hogan) writes:

> Of course, xterm is configurable through some resource, but
> the default should be that backspace is backspace.

You mean, the default is that "backspace erases a character backwards"
or "backspace sets up an overstrike"?  The latter is what ASCII means
by backspace.

Or maybe you mean that the default is that "backspace should send #".

Re: [9fans] standalone cpu/auth server??

[Russ Cox]

Something about your nvram is hosed.  Try doing
	echo asdfasdfasdf >/dev/sdC1/nvram
and then reboot again.  If it still
doesn't work, then the system isn't
finding your nvram partition properly.
Adding prints in /sys/src/9/boot/key.c
should help point a finger.

Russ

Re: [9fans] standalone cpu/auth server??

[Ish Rattan]

On Wed, 22 Aug 2001, Russ Cox wrote:

> Something about your nvram is hosed.  Try doing
> 	echo asdfasdfasdf >/dev/sdC1/nvram
> and then reboot again.  If it still
I have tried that. The boot messages change to
boot: bad nvram key: file does not exist
password:		(for which user???)
authid[no default]: authdom[bootes]: boot: #c/hostowner: bad arg in system
call

cpu# who

none
cpu#

Also, I put print statments in /sys/src/9/boot/key.c after
fd = open("#S/sdC1/nvram", ORDWR);
and open is successful (fd is 3).

Is it possible to have nvram on a disk other than sdC0?
Can I use another cpu/auth server to boot this one (how)??

-ishwar

Re: [9fans] standalone cpu/auth server??

[Dan Cross]

In article <Pine.LNX.4.30.0108221144410.14515-100000@pali.cps.cmich.edu> you write:
>On Wed, 22 Aug 2001, Russ Cox wrote:
>
>> Something about your nvram is hosed.  Try doing
>> 	echo asdfasdfasdf >/dev/sdC1/nvram
>> and then reboot again.  If it still
>I have tried that. The boot messages change to
>boot: bad nvram key: file does not exist
>password:		(for which user???)

For bootes, of course.  :-)

>authid[no default]:

At this point, enter ``bootes'' or whatever auth user you're using.

>authdom[bootes]:

I'm not sure why the default is bootes here; normally, one enters
one's Internet domain.

>boot: #c/hostowner: bad arg in system
>call
>
>cpu# who
>
>none
>cpu#

It looks like the authid is a blank string here (ie, "").

>Also, I put print statments in /sys/src/9/boot/key.c after
>fd = open("#S/sdC1/nvram", ORDWR);
>and open is successful (fd is 3).
>
>Is it possible to have nvram on a disk other than sdC0?
>Can I use another cpu/auth server to boot this one (how)??

It looks like everything's okay, but you've got to enter the auth 
user's password and ID after zeroing out the nvram (I guess you're
not really zeroing it, but you know what I mean).

	- Dan C.

Re: [9fans] standalone cpu/auth server??

[Scott Schwartz]

| >boot: bad nvram key: file does not exist
| >password:		(for which user???)

Alas, errstr fails to live up to its full potential.

[9fans] A Plan 9 Python Interest Group?

[Randolph Fritz]

Off and on I've been hammering away on getting Python 2.0 to build in
the Plan 9 APE.  I have got to the point of compiling and running, and
it passes many of the built-in self-tests, but it still has major
problems--there are serious storage leaks, and for some reason
(perhaps related) complex arithmetic has problems.

(And, meantime, I've had a messy crash I need to recover from so I
can't work on it for a while.)

I'd like to know who else is interested in this and if anyone is
interested if we could get a Plan 9 Python project together.  I would
like to see Plan 9 support, native (though with sockets to support
various existing internet client classes) and with classes to support
Plan 9's unique features, in some future release of Python.

I've made a start at getting it going, and I can put in some more
work, but I can't do most of it; once the next term starts, I'll have
to concentrate on my (non-CS) schoolwork.  So are there enough of us
with interest and time to keep at it?

Randolph

Re: [9fans] A Plan 9 Python Interest Group?

[Jonathan Sergent]

> Off and on I've been hammering away on getting Python 2.0 to build in
> the Plan 9 APE.  I have got to the point of compiling and running, and
> it passes many of the built-in self-tests, but it still has major
> problems--there are serious storage leaks, and for some reason
> (perhaps related) complex arithmetic has problems.
> 
> (And, meantime, I've had a messy crash I need to recover from so I
> can't work on it for a while.)

I made a start at the APE port (I have not worked on it for a while...)
which you can get from

	ftp://csociety-ftp.ecn.purdue.edu/pub/plan9

I think mine ended up in the same situation that you have yours in...

> I'd like to know who else is interested in this and if anyone is
> interested if we could get a Plan 9 Python project together.  I would
> like to see Plan 9 support, native (though with sockets to support
> various existing internet client classes) and with classes to support
> Plan 9's unique features, in some future release of Python.
> 
> I've made a start at getting it going, and I can put in some more
> work, but I can't do most of it; once the next term starts, I'll have
> to concentrate on my (non-CS) schoolwork.  So are there enough of us
> with interest and time to keep at it?

I am interested but I don't have tons of time.


--jss.

Re: [9fans] A Plan 9 Python Interest Group?

[matt heath]

I'm ingterested in plan9 & python

I can program in C but I'm no expert but I know enough to find leaks etc.

Implementing a plan9 FS with a python class is something I've often thought
about.

As for time - I'm going into hospital next week and I've got 6 weeks off
work - don't know if I'll be able to code but I'm moving my PC's into my
bedroom in hope :-)

And I do want to cut my plan9 teeth on something

M

Re: [9fans] A Plan 9 Python Interest Group?

[Randolph Fritz]

On Wed, 3 Jan 2001 06:49:19 GMT, Jonathan Sergent
<sergent@csociety.purdue.edu> wrote:
>
>I made a start at the APE port (I have not worked on it for a while...)
>which you can get from
>
>	ftp://csociety-ftp.ecn.purdue.edu/pub/plan9
>
>I think mine ended up in the same situation that you have yours in...
>

Very cool!  Mine started squirming in the APE tonight.  It is actually
running most of the test scripts for the modules I was able to build.

The immediate problem areas are:
  - I don't have an environment where I can easily test the "socket"
    module
  - complex math is broken
  - test_longexp does lots of page thrashing (perhaps because my
    system doesn't have enough memory)

I am also realizing, as I review my notes, that this needs to be
tested with checks for memory leaks turned on.  D'oh!

Beyond that, I need information from Python experts on how best to
add the Plan 9 platform to their source--anyone who actually knows
something about this please comment!--and thoughts on how to 9ify the
installation.  My current thought on an installation is to have a
/Python directory with $cputype and lib directories at the second
level; the appropriate directories could then be unioned with the
system directories.  But this may be very bogus--what do you experts
think?

>
>I am interested but I don't have tons of time.
>

Oh, well.  I've attached my notes and the results of the builtin test
scripts.  I know some of the stuff I've done to get this going is
gross--I am rapidly getting to hate conditional compilation--but it's
sort-of working and I'm pleased with that.

If anyone wants to build this you will also need a copy of my v7ish grep
for the APE, to make the configure script go.

Randolph

------------- Python/APE porting notes, so far ---------------
Environment:
	CFLAGS=-lap -D_BSD_EXTENSION

Makefile:
	set OPT to -D_BSD_EXTENSION (for some reason
	configure thinks a -O command works. it doesn't)
	Plan 9 does not support "mv -f" (remove the -f)
	LN=cp

config.h:
	turn off HAVE_FSYNC, GETPGRP_HAVE_ARG, HAVE__GETPTY
	Add PLAN9_APE definition (I would prefer this be done
	by configure)

Include/Python.h:
(this may not work)
#ifdef PLAN9_APE
#undef assert
#define assert(e) ((e) || (_assert(__FILE__, __LINE__),0))
#endif


Modules/Makefile.pre:
	same for OPT

Modules/mathmodule.c:
#ifdef PLAN9_APE
extern	double	hypot(double, double);
#endif


Modules/timemodule.c:
(this needs to be fixed up--it is west coast US specific)
	Provide 9-ish "timezone" and "daylight" variables, hack:
#ifdef PLAN9_APE
static long timezone = -28800;
static long daylight = 1;
#endif

Modules/_localemodule.c:
#ifdef PLAN9_APE
#include <bsd.h>
#endif


Modules/fcntlmodule.c:
#ifndef PLAN9_APE
		ret = ioctl(fd, code, buf);
#else
		ret = ioctl(fd, code, (void*) buf);
#endif

Modules/selectmodule.c:
#ifdef PLAN9_APE
#define FD_SETSIZE 96
#endif

Modules/socketmodule.c:
getprotobyname() not avail--ifdef it out

Modules/pwdmodule.c:
.../grpmodule.c:
.../mmapmodule.c:
	Not supported here. just drop 'em.

At this point it builds...but...it fails the "cmath" test, apparently
because taking the absolute value of a complex number doesn't work.

test_longexp.py sends my system into page thrashing

test_socket doesn't work because I don't have a network

The Makefile references -lsocket and -ldir--these are unnecessary &
unavailable

----------- test results -----------

test_grammar
test_opcodes
test_operations
test_builtin
test_exceptions
test_types
test_MimeWriter
test_StringIO
test_al
test test_al skipped --  No module named al
test_array
test_atexit
test_audioop
test test_audioop skipped --  No module named audioop
test_augassign
test_binascii
test_binhex
test_bsddb
test test_bsddb skipped --  No module named bsddb
test_cd
test test_cd skipped --  No module named cd
test_cfgparser
test_cgi
test_cl
test test_cl skipped --  No module named cl
test_class
test_compile
test_contains
test_cookie
test_copy_reg
test_cpickle
test_crypt
test test_crypt skipped --  No module named crypt
test_dbm
test test_dbm skipped --  No module named dbm
test_dl
test test_dl skipped --  No module named dl
test_dospath
test_errno
test_extcall
test_fcntl
test test_fcntl skipped --  No module named FCNTL
test_file
test_fork1
test test_fork1 skipped --  No module named thread
test_format
test_gc
test_gdbm
test test_gdbm skipped --  No module named gdbm
test_getopt
test_gettext
test_gl
test test_gl skipped --  No module named gl
test_grp
test test_grp skipped --  No module named grp
test_gzip
test test_gzip skipped --  No module named zlib
test_hash
test_imageop
test test_imageop skipped --  No module named imageop
test_imgfile
test test_imgfile skipped --  No module named imgfile
test_import
test_largefile
test test_largefile skipped --  platform does not have largefile support
test_linuxaudiodev
test test_linuxaudiodev skipped --  No module named linuxaudiodev
test_long
test_math
test_md5
test_mimetools
test_minidom
test test_minidom skipped --  No module named pyexpat
test_mmap
test test_mmap skipped --  No module named mmap
test_new
test_nis
test test_nis skipped --  No module named nis
test_ntpath
test_openpty
test test_openpty skipped --  No openpty() available.
test_operator
test_parser
test_pickle
test_pkg
test_poll
test test_poll skipped --  select.poll not defined -- skipping test_poll
test_popen2
test_posixpath
test_pow
test_pty
test test_pty skipped --  No module named FCNTL
test_pwd
test test_pwd skipped --  No module named pwd
test_pyexpat
test test_pyexpat skipped --  cannot import name expat
test_re
test_regex
test_rfc822
test_rgbimg
test test_rgbimg skipped --  No module named rgbimg
test_rotor
test_sax
test test_sax skipped --  no XML parsers available
test_select
test_sha
test_signal
test_socket
test test_socket crashed -- socket.error: host not found
test_sre
test_strftime
test_string
test_strop
test_struct
test_sunaudiodev
test test_sunaudiodev skipped --  No module named sunaudiodev
test_thread
test test_thread skipped --  No module named thread
test_time
test_timing
test test_timing skipped --  No module named timing
test_tokenize
test_ucn
test_unicode
test_unicodedata
test_unpack
test_urllib
test_urlparse
test_userdict
test_userlist
test_userstring
test_wave
test_winreg
test test_winreg skipped --  No module named _winreg
test_winsound
test test_winsound skipped --  No module named winsound
test_xmllib
test_zipfile
test_zlib
test test_zlib skipped --  No module named zlib
70 tests OK.
1 test failed: test_socket
34 tests skipped: test_al test_audioop test_bsddb test_cd test_cl
test_crypt test_dbm test_dl test_fcntl test_fork1 test_gdbm test_gl
test_grp test_gzip test_imageop test_imgfile test_largefile
test_linuxaudiodev test_minidom test_mmap test_nis test_openpty
test_poll test_pty test_pwd test_pyexpat test_rgbimg test_sax
test_sunaudiodev test_thread test_timing test_winreg test_winsound
test_zlib

Re: [9fans] A Plan 9 Python Interest Group?

[arisawa]

Hello,

>I'd like to know who else is interested in this and if anyone is
>interested if we could get a Plan 9 Python project together.  I  
would
>like to see Plan 9 support, native (though with sockets to support
>various existing internet client classes) and with classes to  
support
>Plan 9's unique features, in some future release of Python.

I am interested in this project.
I coded some plan9 interface for Python1.5:
	rfork, mount, bind, ...
They were not a difficult task.
Interupt handling was difficult for me and kept unfinished.

Kenji Arisawa
E-mail: arisawa@aichi-u.ac.jp

[9fans] python and lua

[Quinn Dunkan]

> I'd like to know who else is interested in this and if anyone is
> interested if we could get a Plan 9 Python project together.  I would
> like to see Plan 9 support, native (though with sockets to support
> various existing internet client classes) and with classes to support
> Plan 9's unique features, in some future release of Python.
> 
> I've made a start at getting it going, and I can put in some more
> work, but I can't do most of it; once the next term starts, I'll have
> to concentrate on my (non-CS) schoolwork.  So are there enough of us
> with interest and time to keep at it?

I'm interested in this too.  I also made a port, but ran into trouble when
trying to write extension modules.  The problem was that I needed to compile
python under the APE, but extension modules had to be compiled natively to use
the native plan9 functions.  I got tired of monkeying around with APE
impedance-matching, and decided to port lua to compile natively, since lua has
fewer posix dependencies and is smaller in general.  Besides, I realized that
all my plan9 hack time was going into learning the vagaries of the plan9
emulation of the same old posix, which is sort of missing the point :)

So I wrote out a mkfile and hacked around all the lua posixlyness, and now I'm
starting on a p9lib wrapper which will provide the basic syscalls.  I might
write an io library that uses BIO instead of stdio, and purge stdio from the
interpreter, which ought to make it a bit smaller, but mostly give me an
excuse to get familiar with BIO.  Then I'll see about writing a lua library to
speak 9p, so I can easily set up "language driven fileservers" like the
plumber, even on non-plan9 systems (provided 9p will work over tcp...).  Maybe
experiment with bouncing lua bytecode around with the plumber, if I can think
of any sort of use for that.

Anyway, seeing as python is still one of my favorite languages, I'd love to
see it under plan9 as well.  And plan9 definitely needs a few more high-level
languages (I mean, awk is great and all, but... you know...).



And some miscellanea---miscellaneou---ARGH!  Some random questions:

Are the plan9 fonts anti-aliased?  It sorta looks like they are, but that may
be the result of bad eyes, a dusty monitor, and a fuzzy voodoo3 card.

I get lots of random slow-downs, where entering text or something will hang
for just a moment.  I can get quite long hangs if someone sucks up cpu time,
like if I ask 'page' to reverse its image.  Especially scrolling text in acme
is slow---if I click on the scrollbar at a steady rate, it will scroll in
irregular bursts.  Is the voodoo3 driver accelerated?  I do have a 'echo accel
on >#v/vgactl' in my termrc, but it doesn't seem to make a lot of difference.
Is this usual?  I'm running a local kfs, would these go away with a real
fileserver?

Re: [9fans] python and lua

[arisawa]

Hello,

>I do have a 'echo accel
>on >#v/vgactl' in my termrc, but it doesn't seem to make a lot of  
>difference.
Try:
echo -n 'hwaccel on' >'#v/vgactl'

Kenji Arisawa
E-mail: arisawa@aichi-u.ac.jp

[9fans] A question of temperature...

[Jim Choate]

I was wondering if anyone has looked at creating 'process clients' that
would sit on a machine (ala seti@home) and provide transient process
space for a Plan 9 environment within the context of a host OS (eg Win98)?

I gave a little talk about Plan 9 at the Austin Linux Group last Thu. and
one question came up about multi-boot. I know that it's in the archives
but has anyone condensed this material and orderd it as to what does or
doesn't work? I'd like to give a vector to something more concise than
several thousands of emails.

Another item of note, the first meeting of the Plan 9 Users of Austin will
be held the last Thursday of January. A notice will go out shortly with
more details. The meeting will be monthly. Thanks go to the Austin Linux
Group for providing us a nice place to meet with amenities. All are
welcome!

http://einstein.ssz.com/hangar18

We will post contact info for other Plan 9 user groups or mailing lists if
they're interested.

Which raises another question, the Linux group has arrangements with
several vendors to take 'discount batch' orders of releases. Is there any
plans to support user groups in this fashion for Plan 9? One observation I
did note, the $100 price tag is still a tad too high. Most folks are used
to paying sub-$50 for a release. They grumble about 'but what can I do
with it to justify it?'.

I got my Thinkpad 760XL put back together (I built it out of pieces from
about a dozen busted ones) and it seems to be working. I'm running Linux
as a burn in on it now. In about a week or so I'll load Plan 9. I'd like
to hear from anyone who has used this machine with Plan 9. Please respond
directly to me. So far I've gotten a single responce about the video
hardware (though they hadn't actually installed it).

Finally, anyone done anything with Lego Mindstorms and Plan 9?

    ____________________________________________________________________

           Before a larger group can see the virtue of an idea, a
           smaller group must first understand it.

                                           "Stranger Suns"
                                           George Zebrowski

       The Armadillo Group       ,::////;::-.          James Choate
       Austin, Tx               /:'///// ``::>/|/      ravage@ssz.com
       www.ssz.com            .',  ||||    `/( e\      512-451-7087
                           -====~~mm-'`-```-mm --'-
    --------------------------------------------------------------------

Re: [9fans] A question of temperature...

[Boyd Roberts]

From: Jim Choate <ravage@ssz.com>

> I gave a little talk about Plan 9 at the Austin Linux Group last Thu. and
> one question came up about multi-boot.

multi-boot, that's pretty funny.  state of the world, i guess.

[9fans] Re: A question of temperature...

[Jim Choate]

On Sun, 7 Jan 2001, Boyd Roberts wrote:

> From: Jim Choate <ravage@ssz.com>
> 
> > I gave a little talk about Plan 9 at the Austin Linux Group last Thu. and
> > one question came up about multi-boot.
> 
> multi-boot, that's pretty funny.  state of the world, i guess.

??? I assume you mean that if a person is using Plan 9 then why would they
need another OS?

I disagree.

    ____________________________________________________________________

           Before a larger group can see the virtue of an idea, a
           smaller group must first understand it.

                                           "Stranger Suns"
                                           George Zebrowski

       The Armadillo Group       ,::////;::-.          James Choate
       Austin, Tx               /:'///// ``::>/|/      ravage@ssz.com
       www.ssz.com            .',  ||||    `/( e\      512-451-7087
                           -====~~mm-'`-```-mm --'-
    --------------------------------------------------------------------

Re: [9fans] Re: A question of temperature...

[Boyd Roberts]

From: Jim Choate <ravage@ssz.com>
> ??? I assume you mean that if a person is using Plan 9 then why would they
> need another OS?

more or less.

> I disagree.

linux?  don't make me puke...

Re: [9fans] A question of temperature...

[Douglas A. Gwyn]

Jim Choate wrote:
> one question came up about multi-boot.

I use System Commander on my home system to choose among
various OSes at boot time.  One of the choices is Plan 9,
via its partition boot.  (I never could get the boot loader
methods to work, under any of Windows 98, Me, NT, or 2000.)

Re: [9fans] A question of temperature...

[Fariborz 'Skip' Tavakkolian]

>I was wondering if anyone has looked at creating 'process clients' that
>would sit on a machine (ala seti@home) and provide transient process
>space for a Plan 9 environment within the context of a host OS (eg Win98)?

Do you mean something like Inferno? Most concepts are similar or the
same between Plan9 and Inferno, and Inferno runs OS hosted or self hosted.

[9fans] Re: A question of temperature...

[Jim Choate]

On Sat, 6 Jan 2001, Fariborz 'Skip' Tavakkolian wrote:

> >I was wondering if anyone has looked at creating 'process clients' that
> >would sit on a machine (ala seti@home) and provide transient process
> >space for a Plan 9 environment within the context of a host OS (eg Win98)?
> 
> Do you mean something like Inferno? Most concepts are similar or the
> same between Plan9 and Inferno, and Inferno runs OS hosted or self hosted.

seti@home has a data space that is made up of these similarly sized
datasets. A 'user' of seti@home installs a client on their machine as a
screen saver. So for whatever time each day your screensaver would process
this block of data. When it finished it would deliver the results to a
server somewhere and grab another block of data.

Now consider a little program I load on my Win98 machine that simply
connects to an existing Plan 9 environment as a process server. The client
could define the amount of load it would place on the system. As long as
my machine is on it would be available to run jobs on. This would allow
you to use the processing power of systems which can't be Plan 9 boxes.

My understanding of Inferno is that it's a data appliance
environment/language. Intended for controlling smart vacuum cleaners and
my refrigerator. It has broader uses of course.

    ____________________________________________________________________

           Before a larger group can see the virtue of an idea, a
           smaller group must first understand it.

                                           "Stranger Suns"
                                           George Zebrowski

       The Armadillo Group       ,::////;::-.          James Choate
       Austin, Tx               /:'///// ``::>/|/      ravage@ssz.com
       www.ssz.com            .',  ||||    `/( e\      512-451-7087
                           -====~~mm-'`-```-mm --'-
    --------------------------------------------------------------------

Re: [9fans] Re: A question of temperature...

[Dan Cross]

In article <Pine.LNX.3.96.1010106132253.25692f-100000@einstein.ssz.com> you write:
>Now consider a little program I load on my Win98 machine that simply
>connects to an existing Plan 9 environment as a process server. The client
>could define the amount of load it would place on the system. As long as
>my machine is on it would be available to run jobs on. This would allow
>you to use the processing power of systems which can't be Plan 9 boxes.

Yes, but Plan 9 is an operating system, seti@home is an application,
with a small and well-defined set of ``services'' (Actually, not really
services, but I'm too tired to think of a better word right now): get
a block, chunk away on it, send back a result.  Plan 9 is, obviously,
far more open ended.  To get the same set of services while hosted under
another OS and not compromising that OS or Plan 9, I'd probably have to
run it in some sort of virtual machine.  Consider a system call; I could
trap it to, eg, Windows, but what do I do with rfork()?  It's easier to
build a virtual machine than work with the existing OS.  This is what
Inferno does.

That's a pretty hefty screen saver.

Also, what do you do when the user comes back?  Terminate all the jobs?
Migrate them elsewhere?  seti@home probably doesn't care because it's
embarassingly paraellel.  Most applications, however, aren't set up to
tolerate the lose of a CPU server.  :-(

	- Dan C.

Re: [9fans] Re: A question of temperature...

[Jim Choate]

On Mon, 8 Jan 2001, Dan Cross wrote:

> Yes, but Plan 9 is an operating system, seti@home is an application,
> with a small and well-defined set of ``services'' (Actually, not really
> services, but I'm too tired to think of a better word right now): get
> a block, chunk away on it, send back a result.  Plan 9 is, obviously,
> far more open ended.  To get the same set of services while hosted under
> another OS and not compromising that OS or Plan 9, I'd probably have to
> run it in some sort of virtual machine.  Consider a system call; I could
> trap it to, eg, Windows, but what do I do with rfork()?  It's easier to
> build a virtual machine than work with the existing OS.  This is what
> Inferno does.
> 
> That's a pretty hefty screen saver.

I didn't say anything about the app BEING a screensaver.

You should up the meds.

    ____________________________________________________________________

           Before a larger group can see the virtue of an idea, a
           smaller group must first understand it.

                                           "Stranger Suns"
                                           George Zebrowski

       The Armadillo Group       ,::////;::-.          James Choate
       Austin, Tx               /:'///// ``::>/|/      ravage@ssz.com
       www.ssz.com            .',  ||||    `/( e\      512-451-7087
                           -====~~mm-'`-```-mm --'-
    --------------------------------------------------------------------

Re: [9fans] Re: A question of temperature...

[Dan Cross]

In article <Pine.LNX.3.96.1010108171535.25692a-100000@einstein.ssz.com> you write:
>> That's a pretty hefty screen saver.
>
>I didn't say anything about the app BEING a screensaver.

Whoops, looks like I forgot the obligatory smiley at the end
of my, ``that's a pretty hefty screen saver'' joke.

>You should up the meds.

I'm sorry, but where did this come from?  There was no offense
intended in my earlier note.  Perhaps you should mellow out.
(Which might mean up'ing the meds.  :-)

	- Dan C.

Re: [9fans] Re: A question of temperature...

[Jim Choate]

On Mon, 8 Jan 2001, Dan Cross wrote:

> In article <Pine.LNX.3.96.1010108171535.25692a-100000@einstein.ssz.com> you write:
> >> That's a pretty hefty screen saver.
> >
> >I didn't say anything about the app BEING a screensaver.
> 
> Whoops, looks like I forgot the obligatory smiley at the end
> of my, ``that's a pretty hefty screen saver'' joke.
> 
> >You should up the meds.
> 
> I'm sorry, but where did this come from?  There was no offense
> intended in my earlier note.  Perhaps you should mellow out.
> (Which might mean up'ing the meds.  :-)

Gottcha.

    ____________________________________________________________________

           Before a larger group can see the virtue of an idea, a
           smaller group must first understand it.

                                           "Stranger Suns"
                                           George Zebrowski

       The Armadillo Group       ,::////;::-.          James Choate
       Austin, Tx               /:'///// ``::>/|/      ravage@ssz.com
       www.ssz.com            .',  ||||    `/( e\      512-451-7087
                           -====~~mm-'`-```-mm --'-
    --------------------------------------------------------------------

Re: [9fans] Re: A question of temperature...

[matt heath]

> > That's a pretty hefty screen saver.
> 
> I didn't say anything about the app BEING a screensaver.
> 
> You should up the meds.

could it be that seti@home is a screensaver?

Re: [9fans] Re: A question of temperature...

[Boyd Roberts]

> You should up the meds.

when in doubt, double the dose.  that's my motto.

Re: [9fans] Re: A question of temperature...

[Dan Cross]

In article <006701c07a21$54c3c740$0ab9c6d4@cybercable.fr> you write:
>> You should up the meds.
>
>when in doubt, double the dose.  that's my motto.

That explains a few things, Boyd.  :-)

	- Dan C.

Re: [9fans] Re: A question of temperature...

[Boyd Roberts]

    That explains a few things, Boyd.  :-)

except in the special case where the dose is zero :-)

Re: [9fans] Re: A question of temperature...

[Andy Newman]

Dan Cross wrote:
>That's a pretty hefty screen saver.

I know someone who wrote one (screen saver) with an inbuilt C compiler
and debugger!  It was a game (Hotrocks).  Program the robots sort of thing
(actually space ships that fly around and fight other player's ships).
Distributed of course. Your machine starts playing when the saver kicks in.

It was written for Windows by a fellow called Richard Ling and has lcc
embedded in the screen saver with a simple VM for running your ship programs.
(Of course this is a totally nasty way to do it but it is Windows)

>Also, what do you do when the user comes back?

Stop playing games and get back to work of course :)

[9fans] not just 3-button mice

[Douglas A. Gwyn]

Have you tried to buy a keyboard recently?
Current models all have "Web function" keys
that seem to require loading a special driver
(hook?) into Windows to support them..

There is a *lot* of old computer gear I wish
I'd held onto so I could use it now instead of
the cruft that has replaced it.

Re: [9fans] not just 3-button mice

[Christopher Nielsen]

On Fri, 15 Dec 2000, Douglas A. Gwyn wrote:

> There is a *lot* of old computer gear I wish
> I'd held onto so I could use it now instead of
> the cruft that has replaced it.

Oddly, I've noticed the same about good reference books and
textbooks. Publishing companies and hardware companies seem
to be taking the same tack: both obsoleting good and useful
products in favor of the latest and greatest.

-- 
Christopher Nielsen
cnielsen@pobox.com

Re: [9fans] not just 3-button mice

[Tom Duff]

> There is a *lot* of old computer gear I wish
> I'd held onto so I could use it now instead of
> the cruft that has replaced it.
Yes -- I slavaged a half dozen of the hemispherical
red Depraz mice used on Jerqs from the trash at
Bell Labs.  They're the most pleasant mice ever made,
but are obsolete because they were made before the
advent of serial mouse interfaces.  A simple PIC
project ought to bring them back to life...

Re: [9fans] not just 3-button mice

[Boyd Roberts]

From: Tom Duff <td@pixar.com>
To: <9fans@cse.psu.edu>
Sent: Saturday, December 16, 2000 4:03 AM
Subject: Re: [9fans] not just 3-button mice


> ... a half dozen of the hemispherical
> red Depraz mice used on Jerqs from the trash at
> Bell Labs.

now _that_ was a mouse.