Re: [9fans] writing code

Re: [9fans] writing code

[andrey mirtchovski]

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


NOTE: i originally sent this message (successfuly, according to
plan9.ucalgary's mail server) but since it took so long i'll just
assume some filter decided fcp.c was spam.  i've gzipped it now.
sorry if you get double copies.

andrey

--- original message follows ---

> if you want to experiment, i've attached a version of the Inferno
> cp(1) called "streamcp" that uses this technique to try to speed up
> file transfer; it allows you to specify the number of concurrent reads
> and writes.

attached is the same idea for plan9, done by Aki Nyrhinen (with a
little help from me integrating it with the official plan9 cp).  it
speeds up copy from sources up to tenfold in some occasions.  has
reasonable speed locally.

i heard ioproc is even faster.

% time cp /n/sources/extra/sun.tgz /dev/null
0.00u 0.02s 19.91r   cp /n/sources/extra/sun.tgz /dev/null
% time cp /n/sources/extra/sun.tgz /dev/null
0.00u 0.03s 20.35r   cp /n/sources/extra/sun.tgz /dev/null
% time cp /n/sources/extra/sun.tgz /dev/null
0.00u 0.03s 19.93r   cp /n/sources/extra/sun.tgz /dev/null


% time fcp /n/sources/extra/sun.tgz /dev/null
0.00u 0.01s 4.36r    fcp /n/sources/extra/sun.tgz /dev/null
% time fcp /n/sources/extra/sun.tgz /dev/null
0.00u 0.00s 5.31r    fcp /n/sources/extra/sun.tgz /dev/null
% time fcp /n/sources/extra/sun.tgz /dev/null
0.00u 0.04s 5.36r    fcp /n/sources/extra/sun.tgz /dev/null

[-- Attachment #2: fcp.c.gz --]
[-- Type: application/octet-stream, Size: 1482 bytes --]

Re: [9fans] writing code

[rog]

> attached is the same idea for plan9, done by Aki Nyrhinen (with a
> little help from me integrating it with the official plan9 cp).  it
> speeds up copy from sources up to tenfold in some occasions.  has
> reasonable speed locally.

have you compared the speed against raw TCP?

Re: [9fans] writing code

[andrey mirtchovski]

> have you compared the speed against raw TCP?

this may sound silly, but the only way i could find to compare against
raw tcp is via hget:

% time fcp /n/sources/extra/sun.tgz /dev/null
0.00u 0.01s 2.90r 	 fcp /n/sources/extra/sun.tgz /dev/null
0.00u 0.02s 4.16r 	 fcp /n/sources/extra/sun.tgz /dev/null
0.01u 0.02s 4.07r 	 fcp /n/sources/extra/sun.tgz /dev/null
0.00u 0.00s 2.83r 	 fcp /n/sources/extra/sun.tgz /dev/null


% time hget http://204.178.31.2/magic/9down4e/compressed/1108752459/sun.tgz > /dev/null
0.01u 0.00s 2.49r 	 hget http://204.178.31.2/magic/9down4e/compressed/1108752459/sun.tgz
0.00u 0.00s 2.43r 	 hget http://204.178.31.2/magic/9down4e/compressed/1108752459/sun.tgz
0.00u 0.01s 3.14r 	 hget http://204.178.31.2/magic/9down4e/compressed/1108752459/sun.tgz
0.01u 0.02s 2.34r 	 hget http://204.178.31.2/magic/9down4e/compressed/1108752459/sun.tgz

short of writing something small, of course :)

Re: [9fans] writing code

[Charles Forsyth]

>>BTW, there's a bug in fcp; you need to malloc the
>>buffer separately inside each thread, otherwise
>>you get data corruption.

i think it was Cray that observed (about fp) ``you can get the right answer, or the quick answer''

Re: [9fans] writing code

[rog]

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

i tried it myself:

% for(i in 1 2 3 4){
	time fcp sun.tgz /dev/null
	time cp sun.tgz /dev/null
	time hget http://plan9.bell-labs.com/magic/9down4e/compressed/1108754619.nm555mqv7uc7rvvyye52p4zcaeeziq2d/sun.tgz  > /dev/null
}
0.00u 0.01s 12.09r 	 fcp sun.tgz /dev/null
0.00u 0.03s 30.37r 	 cp sun.tgz /dev/null
0.03u 0.11s 11.93r 	 hget http://plan9.bell-labs.com/magic/9down4e/compressed/1108754619.nm555mqv7uc7rvvyye52p4zcaeeziq2d/sun.tgz
0.00u 0.04s 12.16r 	 fcp sun.tgz /dev/null
0.00u 0.00s 30.32r 	 cp sun.tgz /dev/null
0.01u 0.06s 10.16r 	 hget http://plan9.bell-labs.com/magic/9down4e/compressed/1108754619.nm555mqv7uc7rvvyye52p4zcaeeziq2d/sun.tgz
0.00u 0.04s 12.46r 	 fcp sun.tgz /dev/null
0.00u 0.01s 30.24r 	 cp sun.tgz /dev/null
0.08u 0.02s 9.71r 	 hget http://plan9.bell-labs.com/magic/9down4e/compressed/1108754619.nm555mqv7uc7rvvyye52p4zcaeeziq2d/sun.tgz
0.00u 0.01s 11.86r 	 fcp sun.tgz /dev/null
0.00u 0.03s 30.10r 	 cp sun.tgz /dev/null
0.05u 0.07s 9.93r 	 hget http://plan9.bell-labs.com/magic/9down4e/compressed/1108754619.nm555mqv7uc7rvvyye52p4zcaeeziq2d/sun.tgz

overhead was averaging about 15% there.
it seems it isn't nearly as bad as i remember, which is good!

BTW, there's a bug in fcp; you need to malloc the
buffer separately inside each thread, otherwise
you get data corruption.

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

From: andrey mirtchovski <mirtchov@cpsc.ucalgary.ca>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] writing code
Date: Fri, 18 Feb 2005 11:53:09 -0700
Message-ID: <0f57322cacb80f7c319565aeb7cfae61@plan9.ucalgary.ca>

> have you compared the speed against raw TCP?

this may sound silly, but the only way i could find to compare against
raw tcp is via hget:

% time fcp /n/sources/extra/sun.tgz /dev/null
0.00u 0.01s 2.90r 	 fcp /n/sources/extra/sun.tgz /dev/null
0.00u 0.02s 4.16r 	 fcp /n/sources/extra/sun.tgz /dev/null
0.01u 0.02s 4.07r 	 fcp /n/sources/extra/sun.tgz /dev/null
0.00u 0.00s 2.83r 	 fcp /n/sources/extra/sun.tgz /dev/null


% time hget http://204.178.31.2/magic/9down4e/compressed/1108752459/sun.tgz > /dev/null
0.01u 0.00s 2.49r 	 hget http://204.178.31.2/magic/9down4e/compressed/1108752459/sun.tgz
0.00u 0.00s 2.43r 	 hget http://204.178.31.2/magic/9down4e/compressed/1108752459/sun.tgz
0.00u 0.01s 3.14r 	 hget http://204.178.31.2/magic/9down4e/compressed/1108752459/sun.tgz
0.01u 0.02s 2.34r 	 hget http://204.178.31.2/magic/9down4e/compressed/1108752459/sun.tgz

short of writing something small, of course :)

Re: [9fans] writing code

[andrey mirtchovski]

> BTW, there's a bug in fcp; you need to malloc the
> buffer separately inside each thread, otherwise
> you get data corruption.

you got old version of the code, sorry.

Re: [9fans] writing code

[Ralph Corderoy]

Tim Newsham wrote:
> > i think it's realistic.  a boot cd would get you the same access.
> > if you get physical machine access, you win.  typing a password to
> > authenticate to the local system gives you the feeling of security,
> > not actual security.
> 
> To prevent this you either need to prevent someone from booting (ie.
> bios password and hope they dont go through the trouble of yanking the
> drive or resetting the bios) or you need to protect the disk (after
> all thats probably what they want to get at after they log in, not
> network access or the gui).

The ATA spec. has passwords that are stored in the hard drive unit.  The
password must be given before the drive will respond with anything
useful.  It isn't a BIOS password so moving the drive doesn't help.
Forgetting the password is a pain;  there's a `master' one known to the
manufacturer but that just lets you re-format the drive if you can
persuade them, e.g. Dell, to give it to you.

Cheers,


Ralph.

Re: [9fans] writing code

[Roland Dowdeswell]

Around Fri Feb 18 14:34:48 EST 2005, Tim Newsham wrote:
> To prevent this you either need to prevent someone from booting
> (ie. bios password and hope they dont go through the trouble
> of yanking the drive or resetting the bios) or you need to
> protect the disk (after all thats probably what they want to
> get at after they log in, not network access or the gui).
> Something like:
>
>	http://phk.freebsd.dk/pubs/bsdcon-03.gbde.paper.pdf
>
> would address this nicely.  For those who don't want to chase
> down the paper, it's an encrypted disk format used by the
> FreeBSD group.

You might also consider CGD [which I wrote].  GBDE has a number of
serious drawbacks, namely:

	1.  it can lose sectors if the machine crashes in the ``middle''
	    of a write to a single sector,
	2.  it is quite slow,
	3.  it makes no attempt to frustrate dictionary attacks, and
	4.  the crypto is a little dubious [and brittle].

Thanks,

--
    Roland Dowdeswell                      http://www.Imrryr.ORG/~elric/

Re: [9fans] writing code

[Kenji Okamoto]

> coherent idea of identity?  what does a numeric user id mean?  what,
> for that matter, does a user name mean?  maybe this is where the ideas
> in SDSI/SPKI can help (see http://www.faqs.org/rfcs/rfc2693.html).

Sorry of mt delay to respond this, rog.
I have not enough time to read that RFC.

Now, I got what you were saying, however, I suppose it beyonds the
original scope of Plan 9 which was designed for.   She is (has been) for
a somewhat closed affiliations such as a laboratory or a, say, departmetnt.
However, you are aiming to expand it to wider system in the sense of
location or network topology.   In this case, I agree the original design
of Plan 9 may not fit to its need, as if Unix was so to Plan 9.

Then, my view of your proposal is that you'd better to design another
system than Plan 9, or you have to change it for that purpose, however,
is it really possible without causing complexity as such we've seen in the
developement of unices?   I have no idea for it.

Kenji

Re: [9fans] writing code

[rog]

> So, the unix caused chaos to maintain its system, that's the one of
> the most main motivation to produce Plan 9 system, I think.

a centrally administered authentication system should be possible, but
i don't think it should be mandatory.

is it perhaps the case that unix is chaos mainly because there's no
coherent idea of identity?  what does a numeric user id mean?  what,
for that matter, does a user name mean?  maybe this is where the ideas
in SDSI/SPKI can help (see http://www.faqs.org/rfcs/rfc2693.html).

Re: [9fans] writing code

[Russ Cox]

For those who are interested in making plan9port
work under Windows, I put out the code from my last
attempt, pieces of which should be salvageable for
use.  Also in there is my /dev/draw that copes with
screen resizes.

See http://swtch.com/usr/local/plan9/9pm/README.

Russ

Re: [9fans] writing code

[Steve Simon]

> Complete hegemony, for one. When every terminal is a (potential)
> cpu server - depending on its owner's whim - there will be a
> plethora of resources, just waiting to be used. It's somewhat like
> what P2P is to FTP.

I like this model, but I think we would need to be able to specify
a namespace based on authdom, and a cpu % - Fair Share Scheduler anyone?

Then here is the problem of resource discovery...

-Steve

Re: [9fans] writing code

[Richard Miller]

> When every terminal is a (potential)
> cpu server

Here's the rc script I use when I want my (laptop) terminal to act
as a cpu (and drawterm) server.  Of course it could be generalised
to add more services.

#!/bin/rc
rfork ne
auth/keyfs -p $home/lib/keys
aux/listen1 -t tcp!*!ticket /bin/auth/authsrv &
service=cpu aux/listen1 tcp!*!cpu /bin/cpu -O &
service=cpu aux/listen1 tcp!*!ncpu /bin/cpu -R &

Re: [9fans] writing code

[Tiit Lankots]

> So, the unix caused chaos to maintain its system, that's the one of
> the most main motivation to produce Plan 9 system, I think.

It will be a completely different thing, locally- (vs centrally) organised  
system.

Re: [9fans] writing code

[Kenji Okamoto]

> Complete hegemony, for one. When every terminal is a (potential)
> cpu server - depending on its owner's whim - there will be a
> plethora of resources, just waiting to be used. It's somewhat like
> what P2P is to FTP.

So, the unix caused chaos to maintain its system, that's the one of
the most main motivation to produce Plan 9 system, I think.

Kenji

Re: [9fans] writing code

[Tiit Lankots]

>> i'd like to see the distinction between cpu server and terminal
>> disappear.
>
> Then, what is the difference between your new scheme and the
> present day unix scheme?
>
> I don't really understand your motivation to make it real...
> You mean all of direct democracy?

Complete hegemony, for one. When every terminal is a (potential)
cpu server - depending on its owner's whim - there will be a
plethora of resources, just waiting to be used. It's somewhat like
what P2P is to FTP.

Re: [9fans] writing code

[Kenji Okamoto]

> i'd like to see the distinction between cpu server and terminal
> disappear.

Then, what is the difference between your new scheme and the
present day unix scheme?

I don't really understand your motivation to make it real...
You mean all of direct democracy?

Kenji

Re: [9fans] writing code

[Bruce Ellis]

oz-inferno has an encrypted filesystem (based on flashfs).
the configuration and other local private stuff is intended
to live on a usb-flash thingy (along with the executable
and boot crap).  i hope to release some of this stuff when
i get some time off doing real work.

brucee

On Sat, 19 Feb 2005 01:15:59 -0800, David Leimbach <leimy2k@gmail.com> wrote:
> On Fri, 18 Feb 2005 11:59:50 -0800, Christopher Nielsen
> <cnielsen@pobox.com> wrote:
> > On Fri, Feb 18, 2005 at 11:49:43AM -0800, David Leimbach wrote:
> > > > To prevent this you either need to prevent someone from booting
> > > > (ie. bios password and hope they dont go through the trouble
> > > > of yanking the drive or resetting the bios) or you need to
> > > > protect the disk (after all thats probably what they want to
> > > > get at after they log in, not network access or the gui).
> > > > Something like:
> > > >
> > > >     http://phk.freebsd.dk/pubs/bsdcon-03.gbde.paper.pdf
> > > >
> > > > would address this nicely.  For those who don't want to chase
> > > > down the paper, it's an encrypted disk format used by the
> > > > FreeBSD group.
> > > >
> > >
> > > Isn't it actually a block-level encryption rather than a filesystem
> > > implementation?
> >
> > yes. that's exactly what it is. how is that not useful in this
> > case?
> >
> >
>
> Why would you assume that I'd think it's not useful?
>

Re: [9fans] writing code

[David Leimbach]

On Fri, 18 Feb 2005 11:59:50 -0800, Christopher Nielsen
<cnielsen@pobox.com> wrote:
> On Fri, Feb 18, 2005 at 11:49:43AM -0800, David Leimbach wrote:
> > > To prevent this you either need to prevent someone from booting
> > > (ie. bios password and hope they dont go through the trouble
> > > of yanking the drive or resetting the bios) or you need to
> > > protect the disk (after all thats probably what they want to
> > > get at after they log in, not network access or the gui).
> > > Something like:
> > >
> > >     http://phk.freebsd.dk/pubs/bsdcon-03.gbde.paper.pdf
> > >
> > > would address this nicely.  For those who don't want to chase
> > > down the paper, it's an encrypted disk format used by the
> > > FreeBSD group.
> > >
> >
> > Isn't it actually a block-level encryption rather than a filesystem
> > implementation?
>
> yes. that's exactly what it is. how is that not useful in this
> case?
>
>

Why would you assume that I'd think it's not useful?

Re: [9fans] writing code

[Christopher Nielsen]

On Fri, Feb 18, 2005 at 09:36:18PM +0000, rog@vitanuova.com wrote:
> > http://phk.freebsd.dk/pubs/bsdcon-03.gbde.paper.pdf
>
> looks like a project!

yes, it is, and as i said in a previous message, it is a
project i am working on. if others wish to pitch in, i am
more than happy to accept help, and phk has offered
code review assistance, as well; phk would really like
to see gbde implemented on other platforms.

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

Re: [9fans] writing code

[McLone]

On Fri, 18 Feb 2005 18:52:51 +0000, rog@vitanuova.com <rog@vitanuova.com> wrote:
> maybe one could make the unused portion of the vid memory
> another memory pool from which memdraw could choose to allocate?
i even saw that one somewhere in linux patches, so it can be done.
One can have memory disk in videoram, IIRC

p.s. i strongly dislike linux's code - that one was really ugly.
--
wbr,                        |\      _,,,---,,_           dog bless ya!
`                       Zzz /,`.-'`'    -.  ;-;;,_
McLone at GMail dot com    |,4-  ) )-,_. ,\ (  `'-'
  net- and *BSD admin     '---''(_/--'  `-'\_)   ...sorry for translit

Re: [9fans] writing code

[rog]

> http://phk.freebsd.dk/pubs/bsdcon-03.gbde.paper.pdf

looks like a project!

Re: [9fans] writing code

[Ronald G. Minnich]

On Fri, 18 Feb 2005 lucio@proxima.alt.za wrote:

> PS: the above may be a little murky, but I need to beat a dealine and
> Ron's remark deserve a more positive reply.  I'm sure Ron will catch my
> meaning.

I catch your meaning, and I agree that I'm probably wrong.

But I still worry about the disconnected laptop case, because I take my
laptop to many places where network access is just not possible, and then
bring it out again. So my network access in the laptop case is available
maybe 20% of my working day and will always remain so.

Ah well, too little time to write this in a comprehensible way, I take
your meaning and Russ's meaning and the meaning of the other good notes
that got sent to me w.r.t. this issue.

ron

Re: [9fans] writing code

[rog]

> there's a qualifying conditional at the start of that sentence
> and as with a few early papers it's a rather complex description
> for something that becomes less elaborate with a more abstract interpretation,
> even when the computations are exactly the same!

actually, the next paragraph seems to unqualify the conditional:

: The assumption is quite good for most mattes, though it can be
: improved if we know that the coverage seldom overlaps (adjacent
: segments of a continuous line) or always overlaps (repeated
: application of a picture).  For ease in presentation throughout this
: paper, let us make this assumption and consider the alpha values as
: representing subpixel coverage of opaque objects.

i'd have thought this was rather a useful way of looking at things
when we're talking about graphics primitives which might allow
sub-pixel positioning of anchor points, but currently do not.

Re: [9fans] writing code

[rog]

> it's really transparency (or opacity), not partial filling (of an area).
> the whole area is filled, but with something more or less transparent/opaque.

from the porter-duff paper:
: If α(a) and α(b) represent subpixel areas covered by opaque geometric
: objects, the overlap of objects within the pixel is quite arbitrary.
: We know that object A divides the pixel into two subpixel areas of
: ratio α(a):1-α(a).  We know that object B divides the pixel into two
: subpixel areas of ratio α(b):α(1-b).  The result of the assumption is
: the same arithmetic as with semi-transparent objects and is summarised
: in the following table:

Re: [9fans] writing code

[Charles Forsyth]

there's a qualifying conditional at the start of that sentence
and as with a few early papers it's a rather complex description
for something that becomes less elaborate with a more abstract interpretation,
even when the computations are exactly the same!

Re: [9fans] writing code

[Christopher Nielsen]

On Fri, Feb 18, 2005 at 11:49:43AM -0800, David Leimbach wrote:
> > To prevent this you either need to prevent someone from booting
> > (ie. bios password and hope they dont go through the trouble
> > of yanking the drive or resetting the bios) or you need to
> > protect the disk (after all thats probably what they want to
> > get at after they log in, not network access or the gui).
> > Something like:
> >
> >     http://phk.freebsd.dk/pubs/bsdcon-03.gbde.paper.pdf
> >
> > would address this nicely.  For those who don't want to chase
> > down the paper, it's an encrypted disk format used by the
> > FreeBSD group.
> >
>
> Isn't it actually a block-level encryption rather than a filesystem
> implementation?

yes. that's exactly what it is. how is that not useful in this
case?

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

Re: [9fans] writing code

[Charles Forsyth]

>>given that a pixel with alpha notionally represents a partially filled
>>area, might it would make sense to change the interface so that you

it's really transparency (or opacity), not partial filling (of an area).
the whole area is filled, but with something more or less transparent/opaque.

Re: [9fans] writing code

[David Leimbach]

> To prevent this you either need to prevent someone from booting
> (ie. bios password and hope they dont go through the trouble
> of yanking the drive or resetting the bios) or you need to
> protect the disk (after all thats probably what they want to
> get at after they log in, not network access or the gui).
> Something like:
>
>     http://phk.freebsd.dk/pubs/bsdcon-03.gbde.paper.pdf
>
> would address this nicely.  For those who don't want to chase
> down the paper, it's an encrypted disk format used by the
> FreeBSD group.
>

Isn't it actually a block-level encryption rather than a filesystem
implementation?

Dave
> Tim N.
>

Re: [9fans] writing code

[Tim Newsham]

>> I mean, turn it on, pick a random user name which is likely to work, and
>> you're in with no password or anything. Am I the only one who thinks this
>> is not so terrific?
>
> [answer 1]
> i think it's realistic.  a boot cd would get you the same access.
> if you get physical machine access, you win.  typing a password
> to authenticate to the local system gives you the feeling of
> security, not actual security.

To prevent this you either need to prevent someone from booting
(ie. bios password and hope they dont go through the trouble
of yanking the drive or resetting the bios) or you need to
protect the disk (after all thats probably what they want to
get at after they log in, not network access or the gui).
Something like:

    http://phk.freebsd.dk/pubs/bsdcon-03.gbde.paper.pdf

would address this nicely.  For those who don't want to chase
down the paper, it's an encrypted disk format used by the
FreeBSD group.

Tim N.

Re: [9fans] writing code

[rog]

> This is why I'd like to see the key served from a smart dongle - A more
> secure handshake model can be used, and the dongle typically lives
> separated from the data.

i agree a smart dongle is a good idea, but mainly because
it can subvert dictionary attacks if someone gets direct
access to the disk.

if someone jumps in before you in the boot process,
they can still ask your dongle for the relevant information
to enable them to decrypt the data, so a secure boot is
still necessary.

Re: [9fans] writing code

[Paul Lalonde]

On 18-Feb-05, at 10:22 AM, rog@vitanuova.com wrote:
> this would be a way forward.  if your fs is encrypted, it doesn't
> matter who has hardware access to your machine, as long as only you
> have the key.  the important thing is to make the boot process itself
> secure, so that nobody else can step in and subvert your key entry.
>
This is why I'd like to see the key served from a smart dongle - A more
secure handshake model can be used, and the dongle typically lives
separated from the data.  In my case I already carry a USB-flash device
with my keys (physical ones), and I'm much less likely to lose my
laptop and my keys.  If only I could lock my laptop data with the USB
provided key.  Now that cheap programmable dongles exist, this should
be easy - the hardest part for Plan9 looks to be the USB stack...

Paul

Re: [9fans] writing code

[Russ Cox]

> the first classic example i encountered of this was when i sent a
> "reboot" message through such a connection.  the kernel rebooted
> immediately (not sending the reply), and as soon as the server came
> back up again, it resent the request, causing another reboot, and on
> and on.

works as documented!  ;-)

> oh yes, here's another one for the pot:
> change screen resolution dynamically.

i made this work once, but in the aborted
plan9port for windows.  it's not too hard.
if someone wants to go after it i can dig up
the code i was using.

russ

Re: [9fans] writing code

[rog]

> it should be straightforward to adapt the line drawing algorithm
> to put down alpha-blended grey.  that would be nice.

given that a pixel with alpha notionally represents a partially filled
area, might it would make sense to change the interface so that you
can specify lengths smaller than integer pixels?  if you're using
alpha blending, a line that's half a pixel in radius is quite a
reasonable thing, for example.

> you don't need to accelerate everything, just the common stuff.
> the obscured window case you describe is an important one
> that should be handled better.  i'd love to see that happen.
> it's not so much the lack of acceleration as the copying to
> backing store and back.

i think it has to copy to backing store.  i think maybe the underlying
problem is that the backing store is in main memory, not video memory.

given that video cards these days tend to have lots of memory, maybe
it would be possible to allocate some off-screen images in video
memory, thus making them accessible to current acceleration routines.
i know virtually nothing about vid cards, so this might easily be
impossible; just a thought.

from a plan 9 point of view, maybe one could make the unused portion
of the vid memory another memory pool from which memdraw could choose
to allocate?

> there have been at least two attempts to do this.  the early
> brazil kernels maintained state in the Chans and tried to reestablish
> them, but my understanding is that the code never really worked
> right, and eventually it got taken out.  i wrote a user-level file
> server for 9P1 that redialed as necessary to keep the connection
> running without any help from the kernel.  it worked very well
> but i never updated it for 9P2000.  it's not a big program.

i've got an inferno program that does something similar.  the problem
i have with it is to do with non-idempotent 9p requests.  e.g.  i send
a Tcreate and the server goes down.  has the file been created or not?
should the intermediate agent resend the request or not after it has
connected.

as far as i can see, you can't do this in general without some kind of
application knowledge.  but maybe there's a cunning way of doing it.

the first classic example i encountered of this was when i sent a
"reboot" message through such a connection.  the kernel rebooted
immediately (not sending the reply), and as soon as the server came
back up again, it resent the request, causing another reboot, and on
and on...


oh yes, here's another one for the pot:
change screen resolution dynamically.

Re: [9fans] writing code

[rog]

lucio:
> Not really.  Laptops are a poor solution to the problem of information
> ownership and, on the reverse side, information sharing.  So is the
> disked workstation; for that matter, the entire "personal computer"
> idea.  Plan 9 does not propose to solve the problem, but addresses it
> much better than all other conventional approaches.

i'm not sure i agree.  if you can always contact your authentication
and file servers, the current plan 9 model works fine, but i think the
idea of universal global interconnect isn't realistic.  firewalls are
ubiquitous.  network coverage is patchy (and probably always will be).

i think it makes sense to carry your personal information near your
person, even if you only carry a key that enables you to access your
personal data on other systems.

paul:
> Useful would be an encrypted file system on my laptop with a USB-dongle
> auth server providing the key; something like a gumstix
> (www.gumstix.org) could run an auth server pretty easily.

this would be a way forward.  if your fs is encrypted, it doesn't
matter who has hardware access to your machine, as long as only you
have the key.  the important thing is to make the boot process itself
secure, so that nobody else can step in and subvert your key entry.

russ:
> i don't know what peer-to-peer means, but if we moved to
> a public key model (which was the reason presotto created p9any)
> and had the auth server just be a repository for public keys
> (signed by bootes), then any amount of caching could happen.

i'd like to see an authentication model along SDSI/SPKI lines, where
entities can authenticate directly with one another without
necessarily needing to talk to a third party auth server.  the inferno
model does this currently, but you can only authenticate with parties
in the same domain.  charles has done some work in this area for
Inferno.  it's highly applicable to plan 9 too.

this way, me and my laptop are at the centre of my world.  i can talk
to anyone, and name chaining and SPKI tag rules mean that i can make
useful deductions about what i should do on their behalf, even if
their public key isn't known to me.

i'd like to see the distinction between cpu server and terminal
disappear.

Re: [9fans] writing code

[rog]

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

> sure.  you could imagine adding a stream message to
> start some number of reads, but maybe it's enough to
> define that streaming style servers allow the client to
> queue multiple read messages and respond in order.
>
> you can already do that for file transfers by using the
> offset field appropriately.

i tried that, and it didn't seem to speed things up much.  regardless
of the number of concurrent reads, it was still much slower than
streaming TCP.

i couldn't say why though - i just measured it across a slow
trans-atlantic connection.

if you want to experiment, i've attached a version of the Inferno
cp(1) called "streamcp" that uses this technique to try to speed up
file transfer; it allows you to specify the number of concurrent reads
and writes.

perhaps someone that knows something about TCP might be able to say
why this technique can't use more of the available bandwidth?  it'd be
great if it could...

[-- Attachment #2: streamcp.b.gz --]
[-- Type: application/octet-stream, Size: 2281 bytes --]

Re: [9fans] writing code

[rog]

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

> sure.  you could imagine adding a stream message to
> start some number of reads, but maybe it's enough to
> define that streaming style servers allow the client to
> queue multiple read messages and respond in order.
>
> you can already do that for file transfers by using the
> offset field appropriately.

i tried that, and it didn't seem to speed things up much.  regardless
of the number of concurrent reads, it was still much slower than
streaming TCP.

i couldn't say why though - i just measured it across a slow
trans-atlantic connection.

if you want to experiment, i've attached a version of the Inferno
cp(1) called "streamcp" that uses this technique to try to speed up
file transfer; it allows you to specify the number of concurrent reads
and writes.

perhaps someone that knows something about TCP might be able to say
why this technique can't use more of the available bandwidth?  it'd be
great if it could...

[-- Attachment #2: streamcp.b.gz --]
[-- Type: application/octet-stream, Size: 2281 bytes --]

Re: [9fans] writing code

[Ronald G. Minnich]

On Thu, 17 Feb 2005, andrey mirtchovski wrote:

> clients, not servers.  hence the second-rate citizenship.  i move my
> laptop from home to school every day.  it serves as a terminal to
> plan9.ucalgary.ca and the only plan9-related things it has are a couple
> of partitions -- 9fat and cfs (cache).  none of my files are stored on
> it (except whatever is in cfs).  it's as secure as anything else.


it's a fine model, it's just not a universal model. I'm not convinced. But
I'm wrong lots of times, so I'll leave it at that.

ron

Re: [9fans] writing code

[boyd, rounin]

> there were usually two results: ``this is brilliant!'', or
> ``why am i here??''.

an additional phrase often uttered is ''that's funny ...'' when
some new insight is stumbled upon.
--
MGRS 31U DQ 52572 12604

Re: [9fans] writing code

[C H Forsyth]

>>i agree that it would be great to have a list of interesting problems
>>to solve, but i'm not sure we could actually figure out beforehand
>>which solutions are the best ones or even which are complete flops.

i think that might be taken as a definition of an `interesting problem'
(or more accurately, an `interesting solution' to a perceived problem).
a friend of mine worked for a time for a famous computer scientist,
who produced many interesting ideas.  paraphrasing a bit,
my friend said that half-way through an implementation,
there were usually two results: ``this is brilliant!'', or
``why am i here??''.  he said it was rarely possible even to
guess which would result beforehand.

Re: [9fans] writing code

[Skip Tavakkolian]

>> i think it's realistic.  a boot cd would get you the same access.
>> if you get physical machine access, you win.  typing a password
>> to authenticate to the local system gives you the feeling of
>> security, not actual security.
>
> yes, if I get physical acccess, I win. I'll just tear the thing to bits
> and boot it with an ICE :-) I don't even care if I mark up the pretty
> plastic.
>

Possession is 9/10th of security.  The boot cd is the other 1/10th.

Re: [9fans] writing code

[andrey mirtchovski]

i believe russ meant that on Plan 9 networks laptops are just
keyboard/mouse/display interfaces and should never serve as standalone
systems.  they're meant to connect to a physically secure fs/auth
servers, not serve those files themselves.

clients, not servers.  hence the second-rate citizenship.  i move my
laptop from home to school every day.  it serves as a terminal to
plan9.ucalgary.ca and the only plan9-related things it has are a
couple of partitions -- 9fat and cfs (cache).  none of my files are
stored on it (except whatever is in cfs).  it's as secure as anything
else.

Re: [9fans] writing code

[Ronald G. Minnich]

On Thu, 17 Feb 2005, Russ Cox wrote:

> [answer 1]
> i think it's realistic.  a boot cd would get you the same access.
> if you get physical machine access, you win.  typing a password
> to authenticate to the local system gives you the feeling of
> security, not actual security.

yes, if I get physical acccess, I win. I'll just tear the thing to bits
and boot it with an ICE :-) I don't even care if I mark up the pretty
plastic.

And if you get access, you'll probably hit the jackpot much more than I
will, and you probably won't even need to use a screwdriver.  But if most
schmoozes get physical access, they don't win. Most criminals being stupid
schmoozes, I'm ok with protecting against them and not against the KGB.

Everybody who has a null root password, based on the physical access
argument, raise their hand.

I don't buy this argument.

> [answer 2]
> you could just run the screen locker that rob wrote in termrc.

makes sense to me. So why don't we do it?

ron

Re: [9fans] writing code

[Paul Lalonde]

Not to mention that laptops are an important class of networked
devices.  I rarely wind up with my laptop more than a few hours away
from its next connection, and spend most of my days with my laptop
wirelessly connected.
My laptop isn't second class - it has become my principal machine.
Useful would be an encrypted file system on my laptop with a USB-dongle
auth server providing the key; something like a gumstix
(www.gumstix.org) could run an auth server pretty easily.

Paul

On 17-Feb-05, at 8:48 PM, Ronald G. Minnich wrote:

>
>
> On Thu, 17 Feb 2005, Russ Cox wrote:
>
>> [answer 3]
>> plan 9 is intended to be used as a networked system.  laptops
>> are second-class citizens.
>>
>
> hmm, this just sounds like another argument against using plan 9.
>
> ron
>

Re: [9fans] writing code

[lucio]

>> [answer 3]
>> plan 9 is intended to be used as a networked system.  laptops
>> are second-class citizens.
>>
>
> hmm, this just sounds like another argument against using plan 9.

Not really.  Laptops are a poor solution to the problem of information
ownership and, on the reverse side, information sharing.  So is the
disked workstation; for that matter, the entire "personal computer"
idea.  Plan 9 does not propose to solve the problem, but addresses it
much better than all other conventional approaches.

You've forgotten the sanity in the early Plan 9 papers and have (no
offence intended) been swept along by the commoditisation of computing
resources.  Consider the COO of laptops, specially when lost or
stolen, then replace the laptop with an authentication device that
gives you access to any computing terminal anywhere, where Plan 9
provides the computing and file services your access device
authenticates you to.  Even Microsoft Passport aspired to such a
model, but they could not pull off what Plan 9 does by default.

++L

PS: the above may be a little murky, but I need to beat a dealine and
Ron's remark deserve a more positive reply.  I'm sure Ron will catch
my meaning.

Re: [9fans] writing code

[Ronald G. Minnich]

On Thu, 17 Feb 2005, Russ Cox wrote:

> [answer 3]
> plan 9 is intended to be used as a networked system.  laptops
> are second-class citizens.
>

hmm, this just sounds like another argument against using plan 9.

ron

Re: [9fans] writing code

[Russ Cox]

>         isochronous/streaming data transfer over 9p:
>
>                 9p is slow over wide area networks when streaming
>                 data, due to the ping-pong nature of the data
>                 transfer.  can anything be done to help solve this?

sure.  you could imagine adding a stream message to
start some number of reads, but maybe it's enough to
define that streaming style servers allow the client to
queue multiple read messages and respond in order.

you can already do that for file transfers by using the
offset field appropriately.

it's less clear what the kernel interface for streaming
would look like.

>         distributed authentication:
>
>                 the plan 9 authentication model relies on having an
>                 on-line authentication server.  as firewalls and
>                 mobile devices continue to proliferate, might it be
>                 worthwhile adding support for a peer-to-peer model be
>                 more appropriate?

i don't know what peer-to-peer means, but if we moved to
a public key model (which was the reason presotto created p9any)
and had the auth server just be a repository for public keys
(signed by bootes), then any amount of caching could happen.

>         graphics:
>
>                 high-bandwidth bitmap access is slow.  additionally,
>                 even the existing hardware acceleration could be
>                 leveraged more than it is (if any portion of a window
>                 is obscured, then no h/w acceleration is used for that
>                 window).  is it conceivable to have a system where all
>                 graphics operations are accelerated (as apple are
>                 apparently to be doing with their next system), or
>                 does the current architecture preclude this?

you don't need to accelerate everything, just the common stuff.
the obscured window case you describe is an important one
that should be handled better.  i'd love to see that happen.
it's not so much the lack of acceleration as the copying to
backing store and back.

i'm less excited by high-bandwidth bitmap access, but it still
shouldn't be hard.  rob took rio out of the loop for exactly this
reason -- talking to a local /dev/draw is just a single copy of the
data from user space to the frame buffer.  what's needed is a
driving application.

>         graphics primitives:
>
>                 graphics drawn with the existing non-bitblt primitives
>                 is not great (e.g.  lots of jaggies on diagonal
>                 lines).  could implementing subpixel rendering help
>                 matters here?

it should be straightforward to adapt the line drawing algorithm
to put down alpha-blended grey.  that would be nice.

>         how can i continue to do work when a server goes down?
>
>                 aan can deal with a broken network connection, but say
>                 someone reboots the fileserver?  is there any way we
>                 can incorporate some redundancy into the system, or
>                 make it easier for a applications to recover?

there have been at least two attempts to do this.  the early
brazil kernels maintained state in the Chans and tried to reestablish
them, but my understanding is that the code never really worked
right, and eventually it got taken out.  i wrote a user-level file
server for 9P1 that redialed as necessary to keep the connection
running without any help from the kernel.  it worked very well
but i never updated it for 9P2000.  it's not a big program.

russ

Re: [9fans] writing code

[Russ Cox]

> a plan 9 laptop is about as secure as dos 1.0
>
> I mean, turn it on, pick a random user name which is likely to work, and
> you're in with no password or anything. Am I the only one who thinks this
> is not so terrific?

[answer 1]
i think it's realistic.  a boot cd would get you the same access.
if you get physical machine access, you win.  typing a password
to authenticate to the local system gives you the feeling of
security, not actual security.

[answer 2]
you could just run the screen locker that rob wrote in termrc.

[answer 3]
plan 9 is intended to be used as a networked system.  laptops
are second-class citizens.

russ

Re: [9fans] writing code

[Russ Cox]

> > The mechanism is, and always is, someone writes code.
>
> maybe this is unrealistic, but i'd like to see more "encouragement on
> principle".  that is, if someone suggests something, it'd be nice if
> people (particular labs or ex-labs people) would chip in and say "yes,
> it's a good idea in principle; i'd like to see something like that"
> (or perhaps "yes, but it should be done in this way", or "bad idea,
> philosophically misguided").

i'm all for encouragement on principle, but the thread i was replying
to had gotten beyond that point.  it started out with an interesting
question -- what to do beyond rio -- but devolved into religion about
why rio should be more like what's on unix/mac/windows without
pointing out a single problem that would solve.

i think there are plenty of interesting answers to the original question.
acme is one.  but "be more like other systems" is never an interesting
answer.

ultimately, it always comes down to code.  we can talk all we want
but at the end of the day the only real proof that something is a
good idea is to implement it, try it, and see.  andrey and i have
been talking about an implementation of alt-tab for the plan9port rio
that i think will feel quite rio-like (except for the whole typing thing),
but we won't know if it's actually reasonable until we write it.

> if there were various projects around that had been given the
> thumbs-up on principle (pending actual implementation), perhaps more
> people might be inclined to get their hands dirty and write some code
> towards those ends.

that would be great.  nothing in the rio thread resembled a project.

> instead, i feel that people face the prospect of spending weeks
> writing code, only to be told at the end that the whole aim of their
> effort was misguided; or, worse, that the work was indeed misguided, but
> it gets included anyway on the grounds of inclusiveness, diluting the
> excellence of the whole system.

i can see that, but it's hard to say ahead of time that something isn't
misguided.  i think what happens most of the time is someone writes
something to solve a problem that they have, and if it's generally
useful, it makes its way in.  a good example is aquarela.  but there
are problems that have been solved and not rolled in -- ron is working
on better clustering support, but i doubt that will be polished enough
to be mainstream for a while yet.  tim has got the ultrasparc almost
working.  all of these people wrote the code because it solved a problem
they had, so it was useful to do regardless of whether it gets picked up.

it's also hard to say something's not misguided until you try it.
(it's often easy to say it *is* misguided, but that's not the
encouragement you were looking for).  there's always a risk
that it might turn out not to be a good idea, or to need another
go around.  even the things that are successful often need
extra go-arounds:  even central pieces such as the file server, 9P, and
the graphics system have gone through at least three major revisions each.

i agree that it would be great to have a list of interesting problems
to solve, but i'm not sure we could actually figure out beforehand
which solutions are the best ones or even which are complete flops.
but you're right -- we can at least identify the problems.

russ

Re: [9fans] writing code

[boyd, rounin]

> it's not the 8259 that's the problem, your bios isn't telling the
> truth about the interrupt setup. i explained it to you.
> i gave you the hack. you didn't reply as to whether it worked.

ok, i stand corrected.

pretty sure i applied it and got no joy.  that mail got lost in a
head crash -- don't ask.
--
MGRS 31U DQ 52572 12604

Re: [9fans] writing code

[jmk]

On Thu Feb 17 18:03:41 EST 2005, boyd@insultant.net wrote:
> i'd like to see a fix for:
>
>      i8259.c:  print("i8259enable: irq %d shared but not level\n", irq);
>
> i'd have a hack if i had the controller's doc and declaration from a psych that i wouldn't lose my sanity ...
> --
> MGRS 31U DQ 52572 12604
>

it's not the 8259 that's the problem, your bios isn't telling the
truth about the interrupt setup. i explained it to you.
i gave you the hack. you didn't reply as to whether it worked.

Re: [9fans] writing code

[Steve Simon]

I think the idea of a list of "accepted" problem areas
and thoughts on differnt strategys is a good idea, in
the same way as the tip O' the day list is a good idea.

My contribution is actually an indirest reference to the discussion
on the 9grid list about cross domain authentiction IE:

I want to allow YOU to be able use some of my cpu cycles and to be able to
see a limited namespace on THIS machine using THAT authentication server
to prove your credentials.

I am willing to write the code but its still a ways down the list.

If anyone wants another good reason for such a discussion,
9fans has been far too quiet of late ☺

-Steve

Re: [9fans] writing code

[Russ Cox]

it presents a clean 9p interface to user space.

On Thu, 17 Feb 2005 23:33:47 +0000, rog@vitanuova.com <rog@vitanuova.com> wrote:
> > did you read russ' original post?
>
> yes.  i was left wondering "why?"  though.
>
> it's seems a bit like choosing a different fixed point for a recursive
> function (though i'm probably abusing terminology again here!).
> the work's got to be done somehow, and changing how the multiplexing
> is done doesn't really change the fact that the multiplexing has to be
> done somehow - it's just an internal architecture issue.
>
> i don't see what problem it was trying to address.
>
> hence my question to you.
>
>

Re: [9fans] writing code

[rog]

> did you read russ' original post?

yes.  i was left wondering "why?"  though.

it's seems a bit like choosing a different fixed point for a recursive
function (though i'm probably abusing terminology again here!).
the work's got to be done somehow, and changing how the multiplexing
is done doesn't really change the fact that the multiplexing has to be
done somehow - it's just an internal architecture issue.

i don't see what problem it was trying to address.

hence my question to you.

Re: [9fans] writing code

[Christopher Nielsen]

On Thu, Feb 17, 2005 at 11:07:01PM +0000, rog@vitanuova.com wrote:
> > > i talked to russ about his idea of turning the kernel into an
> > > efficient 9p mux and making everything talk 9p.
> >
> > That, to me, is the really exciting idea.
>
> what does it get you?

did you read russ' original post?

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

Re: [9fans] writing code

[rog]

> >>could implementing subpixel rendering help matters here?
>
> that one's easy: no.
> something else might, though.

maybe i got the terminology wrong.

i wasn't referring to that LCD hack, if that's what you're thinking of,
but of being able to specify finer resolutions for (say) the
endpoints of lines than single pixels, and perhaps
have the primitives use alpha blending (i.e. non boolean mask)
to achieve a decent result.

some already allow the former, internally (e.g. _memfillpolysc).

Re: [9fans] writing code

[rog]

> > i talked to russ about his idea of turning the kernel into an
> > efficient 9p mux and making everything talk 9p.
>
> That, to me, is the really exciting idea.

what does it get you?

Re: [9fans] writing code

[Ronald G. Minnich]

On Thu, 17 Feb 2005, Christopher Nielsen wrote:

> i talked to russ about his idea of turning the kernel into an
> efficient 9p mux and making everything talk 9p.

That, to me, is the really exciting idea.

ron

Re: [9fans] writing code

[boyd, rounin]

i'd like to see a fix for:

     i8259.c:  print("i8259enable: irq %d shared but not level\n", irq);

i'd have a hack if i had the controller's doc and declaration from a psych that i wouldn't lose my sanity ...
--
MGRS 31U DQ 52572 12604

Re: [9fans] writing code

[Christopher Nielsen]

On Thu, Feb 17, 2005 at 10:21:19PM +0000, rog@vitanuova.com wrote:
>
> of course, it's perfectly possible to take the view that plan 9 is
> perfect; that beyond minor bug fixes, new hardware ports and device
> drivers and more applications, plan 9 is as good as it could be.
>
> if that's the consensus view, then fine, i can live with that.
>
> but personally, i think that there *are* places where plan 9 doesn't
> perhaps do as well as it could, and fixing some of those might require
> the rethinking of some core parts of the system.

we talked about some of this at the OSDI BoF. there are places
where plan 9 can be improved. i have a list of projects that
i ammend every time i come across something that i think would
be good to have or should be improved.

i talked to russ about his idea of turning the kernel into an
efficient 9p mux and making everything talk 9p. i think that
is an interesting idea. a link to his initial thoughts on it
is here:
http://groups-beta.google.com/group/comp.os.plan9/msg/3bcdde3580d62263

i've talked to presotto about implementing something like sfs.
http://www.fs.net/sfswww/

i've started working on an implementation of gbde as an extension
of devfs. don't hold your breath on when it will be done. really
busy with paying work these days.
http://phk.freebsd.dk/pubs/bsdcon-03.gbde.paper.pdf

so there are plenty of good project ideas. i don't announce
mine because i don't want there to be any expectations that
i am going to produce them in a timely fashion. unfortunately,
plan 9 is a hobby for me. if i had a way to pay the bills and
improve plan 9, i'd certainly do it.

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

Re: [9fans] writing code

[Charles Forsyth]

>>could implementing subpixel rendering help matters here?

that one's easy: no.
something else might, though.

Re: [9fans] writing code

[Ronald G. Minnich]

On Thu, 17 Feb 2005 rog@vitanuova.com wrote:

> here are a few for starters:


hmm,.


how about:

a plan 9 laptop is about as secure as dos 1.0


I mean, turn it on, pick a random user name which is likely to work, and
you're in with no password or anything. Am I the only one who thinks this
is not so terrific?

Or am I missing something.

ron

[9fans] writing code

[rog]

> The mechanism is, and always is, someone writes code.

maybe this is unrealistic, but i'd like to see more "encouragement on
principle".  that is, if someone suggests something, it'd be nice if
people (particular labs or ex-labs people) would chip in and say "yes,
it's a good idea in principle; i'd like to see something like that"
(or perhaps "yes, but it should be done in this way", or "bad idea,
philosophically misguided").

if there were various projects around that had been given the
thumbs-up on principle (pending actual implementation), perhaps more
people might be inclined to get their hands dirty and write some code
towards those ends.

instead, i feel that people face the prospect of spending weeks
writing code, only to be told at the end that the whole aim of their
effort was misguided; or, worse, that the work was indeed misguided, but
it gets included anyway on the grounds of inclusiveness, diluting the
excellence of the whole system.

of course, it's perfectly possible to take the view that plan 9 is
perfect; that beyond minor bug fixes, new hardware ports and device
drivers and more applications, plan 9 is as good as it could be.

if that's the consensus view, then fine, i can live with that.

but personally, i think that there *are* places where plan 9 doesn't
perhaps do as well as it could, and fixing some of those might require
the rethinking of some core parts of the system.

maybe the first thing to do is to try and get some consensus as to
where the weaknesses of the system are.  the kind of things that might
be put in the BUGS section of intro(1), if there was one.

to start with, perhaps we could suggest areas in plan 9 which we think could use
some work, in the broadest terms possible, avoiding specific solutions;
then we could try to work towards specific projects aimed at addressing
those areas. people could give their views on each issue, e.g.

	a) this isn't a problem, it's meant to be this way.
	b) yes this is a problem; i've no idea what to do about it though.
	c) yes, this is a problem, but i don't think there's a decent solution possible.
	d) yes, this is a problem, and here's a possible solution.
	e) yes, this is a problem, but the right solution is too hard.
	f) you're coming at this from the wrong angle.
	g) you're making a mountain out of a molehill.
	h) i don't care in the slightest about this issue.
	i) i don't know what the hell you're on about.

here are a few for starters:

	isochronous/streaming data transfer over 9p:

		9p is slow over wide area networks when streaming
		data, due to the ping-pong nature of the data
		transfer.  can anything be done to help solve this?

	distributed authentication:

		the plan 9 authentication model relies on having an
		on-line authentication server.  as firewalls and
		mobile devices continue to proliferate, might it be
		worthwhile adding support for a peer-to-peer model be
		more appropriate?

	graphics:

		high-bandwidth bitmap access is slow.  additionally,
		even the existing hardware acceleration could be
		leveraged more than it is (if any portion of a window
		is obscured, then no h/w acceleration is used for that
		window).  is it conceivable to have a system where all
		graphics operations are accelerated (as apple are
		apparently to be doing with their next system), or
		does the current architecture preclude this?

	graphics primitives:

		graphics drawn with the existing non-bitblt primitives
		is not great (e.g.  lots of jaggies on diagonal
		lines).  could implementing subpixel rendering help
		matters here?

	how can i continue to do work when a server goes down?

		aan can deal with a broken network connection, but say
		someone reboots the fileserver?  is there any way we
		can incorporate some redundancy into the system, or
		make it easier for a applications to recover?