(no subject)

[presotto]

There's now a pointer to updates and new full packages in

	http://plan9.plan9.com/plan9dist/ureg.html

We've put a new (June 11) full package there that included things
we fixed and things that were left out of the first
package.  The last package listed is always what you
get by following the download pages.

Use wrap/install, see wrap(8), to unpack the packages.

[9fans] Re:

[Andrey Mirtchovski]

You mean:
    http://plan9.bell-labs.com/plan9dist/ureg.html

Btw, is plan9.bell-labs.com going to be the official plan9 sit, or is
there another domain planned?

Andrey

presotto@plan9.bell-labs.com wrote:

> There's now a pointer to updates and new full packages in
>
>         http://plan9.plan9.com/plan9dist/ureg.html
>

[9fans] Re: (none)

[Douglas A. Gwyn]

presotto@plan9.bell-labs.com wrote:
> We've put a new (June 11) full package there that included things
> we fixed and things that were left out of the first
> package.  ...

I for one appreciate this, and hope that VN doesn't "freeze" the
CD-ROM distribution and documentation for a while, while we shake
out the various minor bugs, glitches, etc.

> Use wrap/install, see wrap(8), to unpack the packages.

Rob says its actually "wrap/inst" (inconsistency in documentation,
supposedly now fixed).

[9fans] Re:

[Vester Thacker]

On Mon, 27 Sep 2004 22:52:33 +0100, Steve Simon <steve@quintile.net> wrote:
>
> I got a copy on ebay (though I have never seen another one).
> maybe somone will offer you one "off list".

Heh, if I could only be that lucky. :-)   

--Vester

[9fans] Re:

[Paul.clark]

[-- Attachment #1: Type: text/html, Size: 110 bytes --]

[-- Attachment #2: kgodvystyd.bmp --]
[-- Type: image/bmp, Size: 2286 bytes --]

[-- Attachment #3.1: Type: text/plain, Size: 367 bytes --]

from postmaster@ethel:
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="New_MP3_Player.zip"
	Content-Transfer-Encoding: base64
	Content-Disposition: attachment; filename="New_MP3_Player.zip"

[-- Attachment #3.2: New_MP3_Player.zip.suspect --]
[-- Type: application/octet-stream, Size: 0 bytes --]

[9fans] Re:

[Presotto]

[-- Attachment #1: Type: text/html, Size: 69 bytes --]

[-- Attachment #2: qkegwohtao.bmp --]
[-- Type: image/bmp, Size: 4462 bytes --]

[-- Attachment #3.1: Type: text/plain, Size: 355 bytes --]

from postmaster@ethel:
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="Cool_MP3.zip"
	Content-Transfer-Encoding: base64
	Content-Disposition: attachment; filename="Cool_MP3.zip"

[-- Attachment #3.2: Cool_MP3.zip.suspect --]
[-- Type: application/octet-stream, Size: 0 bytes --]

[9fans] Re:

[Owner-]

[-- Attachment #1: Type: text/html, Size: 116 bytes --]

[-- Attachment #2: usomeorofd.gif --]
[-- Type: image/gif, Size: 1074 bytes --]

[-- Attachment #3.1: Type: text/plain, Size: 345 bytes --]

from postmaster@ethel:
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="Cat.zip"
	Content-Transfer-Encoding: base64
	Content-Disposition: attachment; filename="Cat.zip"

[-- Attachment #3.2: Cat.zip.suspect --]
[-- Type: application/octet-stream, Size: 0 bytes --]

[9fans] Re:

[Kma]

[-- Attachment #1: Type: text/html, Size: 67 bytes --]

[-- Attachment #2: unebggqvih.bmp --]
[-- Type: image/bmp, Size: 3594 bytes --]

[-- Attachment #3.1: Type: text/plain, Size: 349 bytes --]

from postmaster@ethel:
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="Garry.zip"
	Content-Transfer-Encoding: base64
	Content-Disposition: attachment; filename="Garry.zip"

[-- Attachment #3.2: Garry.zip.suspect --]
[-- Type: application/octet-stream, Size: 0 bytes --]

[9fans] Re:

[Eric Dorman]

From: <arisawa@ar.aichi-u.ac.jp>
To: <9fans@cse.psu.edu>
Sent: Tuesday, July 25, 2000 2:07 AM


> >Remake the fileserver kernel with 'chatty' defined as non-zero in
> >dosfs.c and let's take a look at the output plus a hex dump of
> >block 0 of the floppy.
> The result is:
> getclust0 @ 0
> getclust seek addr 0
> getclust read addr 0
> can't read block
> can't read boot block
> panic: can't init dos dosfs on fd.
[xx]
Kenji Arisawa
> E-mail: arisawa@aichi-u.ac.jp

curiouser.  my usual diagnostic is not having the floppy appear
at all.  sounds like time to get back into that trench.

good luck sir!
--eric

Re: [9fans] Re:

[presotto]

	Btw, is plan9.bell-labs.com going to be the official plan9 sit, ...

We're still feeling our way through doing disributions etc.  It
may be a while before we've decided how to do this long term.
Until thenm, we'll continue to assemble and redistribute changes.

[9fans] Re:

[Elliott]

> Hmm. kernel hacks, maybe, but surely there wasn't any restriction on
> distributing brand new applications, or those ported to Plan 9?

no, of course not, but who's going to choose to write for Plan 9 rather
than Linux? my lwm window manager for X, for example, was originally my
modified version of 8.5 while i was at York. it didn't seem worth making
diffs for that, because no-one would have used it. people i knew would
run it from my bin, but that was it. when i wrote lwm, those same people
would ask if they could have the source so they could use it at home.

my point was about "the enticement of having users". it's a lot nicer to
know that someone other than just you is using your programs. [unless
it's paid programming, in which case users are a pain in the bum ;-)]

-- 
http://users.ch.genedata.com/~enh/

[9fans] Re:

[steve_kilbane]

On 21/09/98 10:43:54 Elliott Hughes  wrote:

> and then there's the catch-22: the enticement of having users. no-one
likes to  write
> software to push it to the back of their disc to rot (though i do wonder
sometimes),
> and the one place where you can be sure of users is the free world. if
you can't
> give your code away for free to run on a free platform, you're going to
have  fewer
> users than if you could.

Hmm. kernel hacks, maybe, but surely there wasn't any restriction on
distributing brand new applications, or those ported to Plan 9?

steve