[9fans] Re:

[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:

[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 --]

(no subject)

[arisawa]

Hello,

Thank you for your quick reply.
 
>Are you running on a recognised CPU and the speed is correct?
CPU speed shown from 9pcfs is correct. I have added a patch by forsyth.

>the (tivial) DOS driver doesn't understand the layout of your
>floppy -this can happen if the FAT filesystem was made
>by a system we haven't catered for in the code.
The floppy is created using Plan9 pc/bootfloppy that is rewritten
following Russ.
------ pc/bootfloppy ------
#!/bin/rc

if(! ~ $#* 2) {
        echo 'usage: bootfloppy /dev/fd0disk plan9.ini'>[1=2]
        exit usage
}

if(! test -f $2) {
        echo $2 does not exist >[1=2]
        exit noplan9.ini
}

mkdir /tmp/bootfloppy.$pid
cp $2 /tmp/bootfloppy.$pid/plan9.ini
dd -bs 512 -count 1 < /dev/zero >/tmp/bootfloppy.$pid/plan9.nvr
disk/format -b /386/pbs -f -d $1 /386/9load /tmp/bootfloppy.$pid/*
rm -rf /tmp/bootfloppy.$pid
-------------------------------

9pcfs is copied using Windows98 because I have never succeeded in
copying file when I did on Plan9.

By the way, I will classify bellow what I can do or not.
1. pc/bootfloppy 		--- works fine
2. cp diskimage /dev/fd0disk	--- works ( but not fine )
3. cp file n/a:/file	--- always results in destruction


>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.


Eric said:
>well, i can say i've seen this one before.  i have two AMD K6-3-400
>boxes, both obtained at about the same time, with two different
>motherboards.

And Okamoto:
>Mime works for K6/200 is ASUS TX97-E motherboard

The PC are:
GA-5AX with K6-2/300
ASUS P5A-VM with K6-2/350
Bus clock 100MHz makes a trouble?

By the way, I tried the boot disk to a PC with celeron/466.
The result was fine. It was straight until I got the "Config:" message.

Kenji Arisawa
E-mail: arisawa@aichi-u.ac.jp

[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.

(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:

[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