[9fans] New user

[ruel hernandez <ru60hz@gmail.com>]

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

Hi, my name is ruel hernandez, a contract worker here in saudi arabia as an
electrician.
i really wanted to know
how computers and operating systems are working, at first i tried linux but
along the way
i found plan9 sometime in sept. 2009. i downloaded the sept iso and tried it
live, at work
since then i.ve been longing to install it to my own computer. last march i
got my pentium
4 (repaired), 2 ghz. 256 ram, no harddisk. installed plan9 using 1gb compact
flash drive in
a compactflash adapter board. and well, i can say i,m happy using  plan9,
using rio is
better, acme, although i've not learned all yet i'm already using it in
editing, browsing the
files. oh, by the way you have a slow learner here, for more than 1 week now
i.ve been
trying to figure out how to view html pages but no sucess. any comment here
would be
great, cause i don't have internet at home, i just save them from work then
read it at
home. here is the tries which i have done;

% webfs
% abaco 'file://usr/glenda/exampledothtml
in abaco page, it says
'file://usr/glenda/exampledothtml: 'mnt/web/0/body' unsupported url type

% abaco example.html
"example.html: relative url given without base"

i tried also plumb but it is only showing the source in acme
i know i needed to read more 2 to 3hours aday is not enough but i will,
i want to learn more, i just hope i am not disturbing your advanced issues
here
in 9fans but i,m already a fan of yours

thanks for creating a nice operating system.



On Thu, Apr 29, 2010 at 11:03 AM, <9fans-request@9fans.net> wrote:

> Send 9fans mailing list submissions to
>        9fans@9fans.net
>
> To subscribe or unsubscribe via the World Wide Web, visit
>        http://mail.9fans.net/listinfo/9fans
> or, via email, send a message with subject or body 'help' to
>        9fans-request@9fans.net
>
> You can reach the person managing the list at
>        9fans-owner@9fans.net
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of 9fans digest..."
>
>
> Today's Topics:
>
>   1. Re: A simple experiment (roger peppe)
>   2. Re: ctrl radeon: not working for ATI Radeon 9600 Mobility?
>      (Venkatesh Srinivas)
>   3. Re: A simple experiment (David Leimbach)
>   4. Re: A simple experiment (Eric Van Hensbergen)
>   5. Re: A simple experiment (erik quanstrom)
>   6. Re: A simple experiment (David Leimbach)
>   7. Re: A simple experiment (erik quanstrom)
>   8. Re: A simple experiment (erik quanstrom)
>   9. Re: A simple experiment (David Leimbach)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Thu, 29 Apr 2010 13:40:53 +0100
> From: roger peppe <rogpeppe@gmail.com>
> Subject: Re: [9fans] A simple experiment
> To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net>
> Message-ID:
>        <z2gdf49a7371004290540g29060151k700bac13f78f34dc@mail.gmail.com>
> Content-Type: text/plain; charset=UTF-8
>
> On 28 April 2010 19:42, ron minnich <rminnich@gmail.com> wrote:
> > We did a simple experiment recently: added a new 9p type called
> > Tstream, because this issue of streams vs. transactions has been
> > bugging me for years. The semantics are simple: it's a lot like Tread
> > (almost same packet) but a single Tstream results in any number of
> > Rstreams, until you hit no more data (/dev/mouse) or maybe EOF
> > (/usr/rminnich/movie). Andrey tossed a sample implementation into
> > newsham's 9p library. We ?saw a 27x improvement in performance from
> > calgary to sandia for a big file. Fcp did not come close.
>
> what happens if the consumer is slow and the Rstream writer
> blocks? how do you stop all the other replies on the connection
> waiting for the consumer to get on with it?
>
> in fact, how do you stop it deadlocking if the consumer is in
> fact waiting for one of those replies?
>
> i suppose this comes down to what the API looks like.
> isochronous might be easier, as a slow reader is a bad reader
> so you could just throw away some data.
>
>
>
> ------------------------------
>
> Message: 2
> Date: Thu, 29 Apr 2010 08:44:37 -0400
> From: Venkatesh Srinivas <me@acm.jhu.edu>
> Subject: Re: [9fans] ctrl radeon: not working for ATI Radeon 9600
>        Mobility?
> To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net>
> Message-ID:
>        <t2jf75780241004290544reb54e94n977f8c5b26c82a38@mail.gmail.com>
> Content-Type: text/plain; charset=UTF-8
>
> On Thu, Apr 29, 2010 at 7:17 AM, erik quanstrom <quanstro@quanstro.net>
> wrote:
> >> I added two lines of code to /sys/src/cmd/aux/vga/radeon.h; compiled
> >> vga and kernel; added line to /lib/vgadb.
> >> Now kernel sees the device (and I see it too: cat /dev/vgactl), but
> >> attempt to start framebuffer gives blank screen. Pointers are
> >> appreciated!
> >
> > it didn't work for me, either. ?i added a bit of
> > code to support the newer "atom bios" but
> > ran out of patience and the vesa driver works.
>
> ATOM BIOS should be unnecessary for the R9600; it is an r300-era card.
> I've not ever tried with a mobility (is it an m10?) r9600, but the
> desktop variant works when its PCI IDs are added... I forget whether I
> had to enable r300hack, though, for it...
>
> -- vs
>
>
>
> ------------------------------
>
> Message: 3
> Date: Thu, 29 Apr 2010 05:54:34 -0700
> From: David Leimbach <leimy2k@gmail.com>
> Subject: Re: [9fans] A simple experiment
> To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net>
> Message-ID:
>        <t2j3e1162e61004290554y3a1ea10br5f6ec89cc46ad4c1@mail.gmail.com>
> Content-Type: text/plain; charset="iso-8859-1"
>
> On Thu, Apr 29, 2010 at 5:40 AM, roger peppe <rogpeppe@gmail.com> wrote:
>
> > On 28 April 2010 19:42, ron minnich <rminnich@gmail.com> wrote:
> > > We did a simple experiment recently: added a new 9p type called
> > > Tstream, because this issue of streams vs. transactions has been
> > > bugging me for years. The semantics are simple: it's a lot like Tread
> > > (almost same packet) but a single Tstream results in any number of
> > > Rstreams, until you hit no more data (/dev/mouse) or maybe EOF
> > > (/usr/rminnich/movie). Andrey tossed a sample implementation into
> > > newsham's 9p library. We  saw a 27x improvement in performance from
> > > calgary to sandia for a big file. Fcp did not come close.
> >
> > what happens if the consumer is slow and the Rstream writer
> > blocks? how do you stop all the other replies on the connection
> > waiting for the consumer to get on with it?
> >
> > in fact, how do you stop it deadlocking if the consumer is in
> > fact waiting for one of those replies?
> >
> > i suppose this comes down to what the API looks like.
> > isochronous might be easier, as a slow reader is a bad reader
> > so you could just throw away some data.
> >
> >
> It sounds ok on the surface so far.  Does RStream signal the end of the
> stream chunks, or does the TStreamer already know that answer?  Is there
> any
> sort of realtime constraint for handling incoming RStream chunks?   I would
> think this could be ok, even if it forces the client to put the streamed
> blocks somewhere handy while processing is going on.  Streaming audio and
> video over plan 9 links this way might be nice.
>
> But then I start to wonder why we feel we want to compete with HTTP when it
> already works, and is still fairly simple.  Nothing wrong with improving 9P
> I suppose, but what's so wrong with HTTP transfers that it warrants
> changing
> our beloved resource sharing protocol?  Maybe I'm being too practical, and
> not feeling adventurous or something :-)
>
> Dave
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://mail.9fans.net/private/9fans/attachments/20100429/04570ac5/attachment-0001.htm
> >
>
> ------------------------------
>
> Message: 4
> Date: Thu, 29 Apr 2010 08:19:22 -0500
> From: Eric Van Hensbergen <ericvh@gmail.com>
> Subject: Re: [9fans] A simple experiment
> To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net>
> Message-ID:
>        <j2ta4e6962a1004290619yc038805ds524525e3d535c68@mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1
>
> On Wed, Apr 28, 2010 at 3:51 PM, ron minnich <rminnich@gmail.com> wrote:
> > On Wed, Apr 28, 2010 at 1:36 PM, Francisco J Ballesteros <nemo@lsub.org>
> wrote:
> >
> >> That's similar to a Tget in op with unlimited replies. The difference
> adds on
> >> quickly.
> >
> > neat, I need to study op more than I did :-)
> >
>
> For the record, I kept telling you that.
>
>    -eric
>
>
>
> ------------------------------
>
> Message: 5
> Date: Thu, 29 Apr 2010 10:22:37 -0400
> From: erik quanstrom <quanstro@quanstro.net>
> Subject: Re: [9fans] A simple experiment
> To: 9fans@9fans.net
> Message-ID: <43de5c2167c0a4851aeafaa07a0b982d@kw.quanstro.net>
> Content-Type: text/plain; charset="US-ASCII"
>
> > what happens if the consumer is slow and the Rstream writer
> > blocks? how do you stop all the other replies on the connection
> > waiting for the consumer to get on with it?
>
> the tcp window closes. and the producer blocks.
>
> > in fact, how do you stop it deadlocking if the consumer is in
> > fact waiting for one of those replies?
>
> i don't think i understand this.
>
> i think Tstream would be very dependant on the
> transport layer.  that's the part that makes me nervous.
> all the world's a tcp?
>
> - erik
>
>
>
> ------------------------------
>
> Message: 6
> Date: Thu, 29 Apr 2010 07:36:21 -0700
> From: David Leimbach <leimy2k@gmail.com>
> Subject: Re: [9fans] A simple experiment
> To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net>
> Message-ID:
>        <m2v3e1162e61004290736vf921c63am5c3bc0d00fb5eb54@mail.gmail.com>
> Content-Type: text/plain; charset="iso-8859-1"
>
> On Thu, Apr 29, 2010 at 7:22 AM, erik quanstrom <quanstro@quanstro.net
> >wrote:
>
> > > what happens if the consumer is slow and the Rstream writer
> > > blocks? how do you stop all the other replies on the connection
> > > waiting for the consumer to get on with it?
> >
> > the tcp window closes. and the producer blocks.
> >
> > > in fact, how do you stop it deadlocking if the consumer is in
> > > fact waiting for one of those replies?
> >
> > i don't think i understand this.
> >
> > i think Tstream would be very dependant on the
> > transport layer.  that's the part that makes me nervous.
> > all the world's a tcp?
> >
> >
> What does 9P require to function?  If TStream has the same or lesser
> requirements, then there's no problem right?  This comes back to my
> wondering why we don't just use 9P to set up HTTP streams.
>
>
> > - erik
> >
> >
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://mail.9fans.net/private/9fans/attachments/20100429/f3db15ab/attachment-0001.htm
> >
>
> ------------------------------
>
> Message: 7
> Date: Thu, 29 Apr 2010 10:35:34 -0400
> From: erik quanstrom <quanstro@quanstro.net>
> Subject: Re: [9fans] A simple experiment
> To: 9fans@9fans.net
> Message-ID: <40cf59cfc2735e232f0fd67df725e65d@kw.quanstro.net>
> Content-Type: text/plain; charset="US-ASCII"
>
> > But then I start to wonder why we feel we want to compete with HTTP when
> it
> > already works, and is still fairly simple.  Nothing wrong with improving
> 9P
> > I suppose, but what's so wrong with HTTP transfers that it warrants
> changing
> > our beloved resource sharing protocol?  Maybe I'm being too practical,
> and
> > not feeling adventurous or something :-)
>
> do we put a http bag on the side of every /n/remoteslowlink
> fileserver, since 9p can't take care of it's own business?
>
> - erik
>
>
>
> ------------------------------
>
> Message: 8
> Date: Thu, 29 Apr 2010 10:43:48 -0400
> From: erik quanstrom <quanstro@quanstro.net>
> Subject: Re: [9fans] A simple experiment
> To: 9fans@9fans.net
> Message-ID: <816a521c149b06088f5023d3dfddf0ed@kw.quanstro.net>
> Content-Type: text/plain; charset="US-ASCII"
>
> > What does 9P require to function?  If TStream has the same or lesser
> > requirements, then there's no problem right?  This comes back to my
> > wondering why we don't just use 9P to set up HTTP streams.
>
> see /sys/src/doc/il/il.ps
> - reliable,
> - in order.
> (the other three are not hard requirements)
>
> i would think that Tstream has greater requirements.
> it would seem to require flow control.
>
> - erik
>
>
>
> ------------------------------
>
> Message: 9
> Date: Thu, 29 Apr 2010 08:03:25 -0700
> From: David Leimbach <leimy2k@gmail.com>
> Subject: Re: [9fans] A simple experiment
> To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net>
> Message-ID:
>        <u2n3e1162e61004290803v6e9f804erc0e7b8ebf33866dc@mail.gmail.com>
> Content-Type: text/plain; charset="iso-8859-1"
>
> On Thu, Apr 29, 2010 at 7:43 AM, erik quanstrom <quanstro@quanstro.net
> >wrote:
>
> > > What does 9P require to function?  If TStream has the same or lesser
> > > requirements, then there's no problem right?  This comes back to my
> > > wondering why we don't just use 9P to set up HTTP streams.
> >
> > see /sys/src/doc/il/il.ps
> > - reliable,
> > - in order.
> > (the other three are not hard requirements)
> >
> > i would think that Tstream has greater requirements.
> > it would seem to require flow control.
> >
> > - erik
> >
> >
>
> 9P doesn't require any flow control?  That doesn't seem right :-)  But then
> again it doesn't stream, at least in the traditional way I think of
> streaming.  To stream you typically need flow control, so 9P isn't good for
> streaming in the sense I think of streaming. (yet?)
>
> Fix 9P or don't is the decision to be made.
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://mail.9fans.net/private/9fans/attachments/20100429/a57ee49b/attachment.htm
> >
>
> End of 9fans Digest, Vol 72, Issue 79
> *************************************
>

[-- Attachment #2: Type: text/html, Size: 18158 bytes --]