* [9fans] browse /sys/src
@ 2005-01-26 2:00 YAMANASHI Takeshi
2005-01-26 2:27 ` Kenji Okamoto
2005-01-26 9:55 ` [9fans] browse /sys/src Fco. J. Ballesteros
0 siblings, 2 replies; 53+ messages in thread
From: YAMANASHI Takeshi @ 2005-01-26 2:00 UTC (permalink / raw)
To: 9fans
Hi, I setup a src browsing gateway on a tip9ug server.
http://www.tip9ug.jp/magic/srcgw/sys/src
HISTORY link is not much useful yet because I don't pull
regulary and there's almost nothing in /n/dump. Hope the
gateway finds sourcesdump soon.
Also, a mirror of Installation CD's iso image is also
available on the server. Please read the License before
download the image.
http://plan9.bell-labs.com/plan9dist/license.html
http://www.tip9ug.jp/mirror/plan9.iso.bz2
The image is updated daily.
Hope these will help.
--
Sincerely,
YAMANASHI Takeshi
^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: [9fans] browse /sys/src
2005-01-26 2:00 [9fans] browse /sys/src YAMANASHI Takeshi
@ 2005-01-26 2:27 ` Kenji Okamoto
2005-01-26 2:31 ` Michael H. Collins
2005-01-26 9:55 ` [9fans] browse /sys/src Fco. J. Ballesteros
1 sibling, 1 reply; 53+ messages in thread
From: Kenji Okamoto @ 2005-01-26 2:27 UTC (permalink / raw)
To: 9fans
> Hi, I setup a src browsing gateway on a tip9ug server.
> http://www.tip9ug.jp/magic/srcgw/sys/src
>
> HISTORY link is not much useful yet because I don't pull
> regulary and there's almost nothing in /n/dump. Hope the
> gateway finds sourcesdump soon.
I'm not offending your efforts basically.
It said first, however, I'd like to know the process of discussions
where you and sources members and also this 9fans community
members. I don't want to discuss LICENSE frames, however,
I believe we have more basic moral to make refer the others
works...
Making source trees available to anyone who want it may help
the community or may not. I think it's not so clear to me yet,
only to me?
Kenji
^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: [9fans] browse /sys/src
2005-01-26 2:27 ` Kenji Okamoto
@ 2005-01-26 2:31 ` Michael H. Collins
2005-01-26 2:45 ` boyd, rounin
2005-01-26 3:50 ` Russ Cox
0 siblings, 2 replies; 53+ messages in thread
From: Michael H. Collins @ 2005-01-26 2:31 UTC (permalink / raw)
To: Fans of the OS Plan 9 from Bell Labs
yes. i call bullshit
too
Kenji Okamoto wrote:
>>Hi, I setup a src browsing gateway on a tip9ug server.
>> http://www.tip9ug.jp/magic/srcgw/sys/src
>>
>>HISTORY link is not much useful yet because I don't pull
>>regulary and there's almost nothing in /n/dump. Hope the
>>gateway finds sourcesdump soon.
>
>
> I'm not offending your efforts basically.
> It said first, however, I'd like to know the process of discussions
> where you and sources members and also this 9fans community
> members. I don't want to discuss LICENSE frames, however,
> I believe we have more basic moral to make refer the others
> works...
>
> Making source trees available to anyone who want it may help
> the community or may not. I think it's not so clear to me yet,
> only to me?
>
> Kenji
>
>
>
--
Michael H. Collins Admiral, Penguinista Navy
http://linuxlink.com
/"\ ASCII Ribbon Campaign
\ / No HTML/RTF in email
x No Word docs in email
/ \ Respect for open standards
Take your laptop and yell out:
"Can a brother get a ip address?"
^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: [9fans] browse /sys/src
2005-01-26 2:31 ` Michael H. Collins
@ 2005-01-26 2:45 ` boyd, rounin
2005-01-26 3:50 ` Russ Cox
1 sibling, 0 replies; 53+ messages in thread
From: boyd, rounin @ 2005-01-26 2:45 UTC (permalink / raw)
To: Fans of the OS Plan 9 from Bell Labs
> yes. i call bullshit
the Repo code ...
--
MGRS 31U DQ 52572 12604
^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: [9fans] browse /sys/src
2005-01-26 2:31 ` Michael H. Collins
2005-01-26 2:45 ` boyd, rounin
@ 2005-01-26 3:50 ` Russ Cox
2005-01-26 4:28 ` Kenji Okamoto
2005-01-26 21:32 ` [9fans] fossil speed rog
1 sibling, 2 replies; 53+ messages in thread
From: Russ Cox @ 2005-01-26 3:50 UTC (permalink / raw)
To: Fans of the OS Plan 9 from Bell Labs
No need to jump on Yamanashi. He checked with us
at Bell Labs before announcing it. The consensus here
is that making the LICENSE file obvious on the site and
in the downloaded tgzs is sufficient.
Lucent insists on the click-through for the official distribution,
but the terms of the Lucent Public License do not require
it of others. (This is in contrast to the Plan 9 License,
which did.) There is at least already one external site
already that makes much of the Plan 9 source available
without a click-through: the plan9port site.
I believe the CMU 3rd ed. browser was shut down because
the person running it moved on and could no longer
maintain it.
I think the web interface to sources that Yamanashi set
up is quite nice.
Russ
^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: [9fans] browse /sys/src
2005-01-26 3:50 ` Russ Cox
@ 2005-01-26 4:28 ` Kenji Okamoto
2005-01-26 4:39 ` Kenji Okamoto
2005-01-26 8:49 ` Skip Tavakkolian
2005-01-26 21:32 ` [9fans] fossil speed rog
1 sibling, 2 replies; 53+ messages in thread
From: Kenji Okamoto @ 2005-01-26 4:28 UTC (permalink / raw)
To: russcox, 9fans
> Lucent insists on the click-through for the official distribution,
> but the terms of the Lucent Public License do not require
> it of others. (This is in contrast to the Plan 9 License,
> which did.) There is at least already one external site
> already that makes much of the Plan 9 source available
> without a click-through: the plan9port site.
I believe, because I haven't got it, plan9port is only a part of Plan9,
I mean, by only those we cannot run Plan 9.
> I think the web interface to sources that Yamanashi set
> up is quite nice.
I doubt this.
Web can be reached from anyone who wants, even he/she is
a terrorist etc, I don't mean the word same as Iqaqi etc.
We, academic community is 'open', anyone can get the resources
we developed. However, if you want to enter the community,
you have to be evaluated before. In this sense, academic community
is not completely 'open'. However, we don't believe it's not open.
I'd like the Plan 9 community is as such.
I don't brame click-through procedure of Lucent, because it's just
like the above I mentioned. I still believe moral term.
Kenji
^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: [9fans] browse /sys/src
2005-01-26 4:28 ` Kenji Okamoto
@ 2005-01-26 4:39 ` Kenji Okamoto
2005-01-26 8:49 ` Skip Tavakkolian
1 sibling, 0 replies; 53+ messages in thread
From: Kenji Okamoto @ 2005-01-26 4:39 UTC (permalink / raw)
To: 9fans
[-- Attachment #1: Type: text/plain, Size: 162 bytes --]
I forgot one thing.
I don't say that the sources should be limited to Lucent alone.
However, this issue should be discussed before making decision.
Kenji
[-- Attachment #2: Type: message/rfc822, Size: 4358 bytes --]
From: Kenji Okamoto <okamoto@granite.cias.osakafu-u.ac.jp>
To: russcox@gmail.com, 9fans@cse.psu.edu
Cc:
Subject: Re: [9fans] browse /sys/src
Date: Wed, 26 Jan 2005 13:28:54 +0900
Message-ID: <2aab0c267882f16e9ce77d5b9ff0f5a8@granite.cias.osakafu-u.ac.jp>
> Lucent insists on the click-through for the official distribution,
> but the terms of the Lucent Public License do not require
> it of others. (This is in contrast to the Plan 9 License,
> which did.) There is at least already one external site
> already that makes much of the Plan 9 source available
> without a click-through: the plan9port site.
I believe, because I haven't got it, plan9port is only a part of Plan9,
I mean, by only those we cannot run Plan 9.
> I think the web interface to sources that Yamanashi set
> up is quite nice.
I doubt this.
Web can be reached from anyone who wants, even he/she is
a terrorist etc, I don't mean the word same as Iqaqi etc.
We, academic community is 'open', anyone can get the resources
we developed. However, if you want to enter the community,
you have to be evaluated before. In this sense, academic community
is not completely 'open'. However, we don't believe it's not open.
I'd like the Plan 9 community is as such.
I don't brame click-through procedure of Lucent, because it's just
like the above I mentioned. I still believe moral term.
Kenji
^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: [9fans] browse /sys/src
2005-01-26 4:28 ` Kenji Okamoto
2005-01-26 4:39 ` Kenji Okamoto
@ 2005-01-26 8:49 ` Skip Tavakkolian
2005-01-26 10:00 ` Matthias Teege
1 sibling, 1 reply; 53+ messages in thread
From: Skip Tavakkolian @ 2005-01-26 8:49 UTC (permalink / raw)
To: 9fans
> We, academic community is 'open', anyone can get the resources
> we developed. However, if you want to enter the community,
> you have to be evaluated before. In this sense, academic community
> is not completely 'open'. However, we don't believe it's not open.
> I'd like the Plan 9 community is as such.
I don't.
BTW, Plan9 is the most practical system I have. I can access all my data
all the time from anywhere. It's secure, reliable and resilient. It's wrong
to reinforce the impression that Plan9 is some academic exercise.
^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: [9fans] browse /sys/src
2005-01-26 8:49 ` Skip Tavakkolian
@ 2005-01-26 10:00 ` Matthias Teege
0 siblings, 0 replies; 53+ messages in thread
From: Matthias Teege @ 2005-01-26 10:00 UTC (permalink / raw)
To: 9fans
> all the time from anywhere. It's secure, reliable and resilient. It's wrong
> to reinforce the impression that Plan9 is some academic exercise.
I don't know if I understand Kenji Okamotos point but I agree with
Skip in this point. Plan 9 isn't a toy. It is one of it strengths
that it has left behind the academic exercise stage. I don't know any
other "alternative" system which is usefull (today) like Plan 9 is.
Ok, maybe Minix works but it's yust another UNIX. ;-)
Matthias
^ permalink raw reply [flat|nested] 53+ messages in thread
* [9fans] fossil speed
2005-01-26 3:50 ` Russ Cox
2005-01-26 4:28 ` Kenji Okamoto
@ 2005-01-26 21:32 ` rog
2005-01-26 21:36 ` andrey mirtchovski
2005-01-27 3:39 ` boyd, rounin
1 sibling, 2 replies; 53+ messages in thread
From: rog @ 2005-01-26 21:32 UTC (permalink / raw)
To: 9fans
has anyone else found fossil to be very slow? even when it's not
using venti at all (e.g. extracting a large tar archive).
crudely comparing the speed of my local fossil on a T22 laptop to a
local linux box, it seems to perform operations anywhere from 100 to
200 times as slow. (again, this is totally crude; i just extracted
the firefox source code, 300MB uncompressed, and then removed it).
even allowing for a factor of 10 in drive/driver speed, this
still seems like a lot.
is there something that can be done about this? maybe i've just got
things set up wrong.
day to day i don't really use big files so this hadn't impacted me
until now.
cheers,
rog.
^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: [9fans] fossil speed
2005-01-26 21:32 ` [9fans] fossil speed rog
@ 2005-01-26 21:36 ` andrey mirtchovski
2005-01-26 22:09 ` Charles Forsyth
` (3 more replies)
2005-01-27 3:39 ` boyd, rounin
1 sibling, 4 replies; 53+ messages in thread
From: andrey mirtchovski @ 2005-01-26 21:36 UTC (permalink / raw)
To: 9fans
> has anyone else found fossil to be very slow? even when it's not
> using venti at all (e.g. extracting a large tar archive).
>
"almost" identical machines using ide disks (2.0 vs 2.6ghz cpu's):
on plan9:
plan9% time tar cv xen | gzip > xen.tgz
a xen/9pccpu 3189 blocks
a xen/etc_xen_plan9 7 blocks
a xen/kfs_root_image.gz 298211 blocks
0.42u 6.48s 56.15r tar cv xen
plan9%
then this very same file was copied and untarred on the linux box:
$ time tar cvf - xen | gzip > xen.tgz
xen/
xen/9pccpu
xen/etc_xen_plan9
xen/kfs_root_image.gz
real 0m29.123s
user 0m22.805s
sys 0m2.635s
$
i have both rwm and dma turned on. the disks are IDE in both cases.
for Plan 9, fossil is mounted through a devfs mirror of two disks,
which should slow it down even more.
andrey
^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: [9fans] fossil speed
2005-01-26 21:36 ` andrey mirtchovski
@ 2005-01-26 22:09 ` Charles Forsyth
2005-01-26 22:18 ` andrey mirtchovski
` (2 subsequent siblings)
3 siblings, 0 replies; 53+ messages in thread
From: Charles Forsyth @ 2005-01-26 22:09 UTC (permalink / raw)
To: 9fans
[-- Attachment #1: Type: text/plain, Size: 32 bytes --]
what happens when you extract?
[-- Attachment #2: Type: message/rfc822, Size: 2932 bytes --]
From: andrey mirtchovski <mirtchov@cpsc.ucalgary.ca>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] fossil speed
Date: Wed, 26 Jan 2005 14:36:29 -0700
Message-ID: <bcad6afcd37a3dc9f5ec58a336592223@plan9.ucalgary.ca>
> has anyone else found fossil to be very slow? even when it's not
> using venti at all (e.g. extracting a large tar archive).
>
"almost" identical machines using ide disks (2.0 vs 2.6ghz cpu's):
on plan9:
plan9% time tar cv xen | gzip > xen.tgz
a xen/9pccpu 3189 blocks
a xen/etc_xen_plan9 7 blocks
a xen/kfs_root_image.gz 298211 blocks
0.42u 6.48s 56.15r tar cv xen
plan9%
then this very same file was copied and untarred on the linux box:
$ time tar cvf - xen | gzip > xen.tgz
xen/
xen/9pccpu
xen/etc_xen_plan9
xen/kfs_root_image.gz
real 0m29.123s
user 0m22.805s
sys 0m2.635s
$
i have both rwm and dma turned on. the disks are IDE in both cases.
for Plan 9, fossil is mounted through a devfs mirror of two disks,
which should slow it down even more.
andrey
^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: [9fans] fossil speed
2005-01-26 21:36 ` andrey mirtchovski
2005-01-26 22:09 ` Charles Forsyth
@ 2005-01-26 22:18 ` andrey mirtchovski
2005-01-26 22:22 ` andrey mirtchovski
2005-01-26 22:26 ` rog
3 siblings, 0 replies; 53+ messages in thread
From: andrey mirtchovski @ 2005-01-26 22:18 UTC (permalink / raw)
To: Fans of the OS Plan 9 from Bell Labs
i managed to find a way of slowing down fossil even more (while discussing
this and how to include anything past the pipe in the timing on irc) by
working with many small files in a single directory:
plan9% ls b24 | wc -l; du b24
3601
11827 b24
plan9% time tar cf b24.tar b24
0.05u 0.75s 7.31r tar cf b24.tar b24
plan9% time tar xf b24.tar
0.09u 0.94s 4.99r tar xf b24.tar
plan9%
$ time tar cf b24.tar b24
real 0m0.251s
user 0m0.060s
sys 0m0.175s
$ time tar xf b24.tar
real 0m1.291s
user 0m0.062s
sys 0m1.207s
$
repeated timings get the factor of difference up to 7, but still way below
the one you're observing..
^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: [9fans] fossil speed
2005-01-26 21:36 ` andrey mirtchovski
2005-01-26 22:09 ` Charles Forsyth
2005-01-26 22:18 ` andrey mirtchovski
@ 2005-01-26 22:22 ` andrey mirtchovski
2005-01-26 22:48 ` rog
2005-01-26 22:26 ` rog
3 siblings, 1 reply; 53+ messages in thread
From: andrey mirtchovski @ 2005-01-26 22:22 UTC (permalink / raw)
To: 9fans
here's the extract:
plan9% time tar xf xen.tar
0.22u 5.12s 39.09r tar xf xen.tar
plan9%
$ time tar xf xen.tar
real 0m15.771s
user 0m0.048s
sys 0m1.388s
$
^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: [9fans] fossil speed
2005-01-26 21:36 ` andrey mirtchovski
` (2 preceding siblings ...)
2005-01-26 22:22 ` andrey mirtchovski
@ 2005-01-26 22:26 ` rog
2005-01-26 22:13 ` Charles Forsyth
` (2 more replies)
3 siblings, 3 replies; 53+ messages in thread
From: rog @ 2005-01-26 22:26 UTC (permalink / raw)
To: 9fans
[-- Attachment #1: Type: text/plain, Size: 1516 bytes --]
that's not too bad.
i fancy that the big difference i was seeing might have
been to do with the fact that i was creating (or destroying)
tens of thousands of tiny files, whereas your example contains
only three. also, isn't gzip somewhat more compute-intensive
than gunzip, in which case maybe what you were doing
was more cpu-bound?
one example:
linux% time rm -r mozilla
real 0m3.621s
user 0m0.090s
sys 0m1.180s
linux%
an equivalent under fossil, removing only half that
number of files took more than 5 minutes.
another:
linux% ls -l *.bz2
-rw-r--r-- 1 rog rog 32686249 Jan 26 20:54 firefox.tar.bz2
linux% time sh -c 'bunzip2 < firefox.tar.bz2 | dd 'bs=512k' | tar xf -'
real 1m23.266s
user 0m36.600s
sys 0m5.050s
linux%
(the big blocksize dd is there to try and reduce disk contention
between the bunzip process and the tar write).
when i did this using fossil i killed it after an hour had passed.
thanks for pointing out the dma/rwm - i hadn't in fact enabled these
when network booting. however, even after enabling them, it still
going to take 20-40 minutes (estimate varies a bit)
it might very well be my slow disk, but i'd like to hear how other
people's systems compare.
i wonder if perhaps the rather complex fossil/venti directory structure
might be slowing things down? also, my fossil cache size is 2000
blocks. i would imagine this'd be sufficient to cache
parent-directory meta data, but perhaps i'm wrong.
[-- Attachment #2: Type: message/rfc822, Size: 2922 bytes --]
From: andrey mirtchovski <mirtchov@cpsc.ucalgary.ca>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] fossil speed
Date: Wed, 26 Jan 2005 14:36:29 -0700
Message-ID: <bcad6afcd37a3dc9f5ec58a336592223@plan9.ucalgary.ca>
> has anyone else found fossil to be very slow? even when it's not
> using venti at all (e.g. extracting a large tar archive).
>
"almost" identical machines using ide disks (2.0 vs 2.6ghz cpu's):
on plan9:
plan9% time tar cv xen | gzip > xen.tgz
a xen/9pccpu 3189 blocks
a xen/etc_xen_plan9 7 blocks
a xen/kfs_root_image.gz 298211 blocks
0.42u 6.48s 56.15r tar cv xen
plan9%
then this very same file was copied and untarred on the linux box:
$ time tar cvf - xen | gzip > xen.tgz
xen/
xen/9pccpu
xen/etc_xen_plan9
xen/kfs_root_image.gz
real 0m29.123s
user 0m22.805s
sys 0m2.635s
$
i have both rwm and dma turned on. the disks are IDE in both cases.
for Plan 9, fossil is mounted through a devfs mirror of two disks,
which should slow it down even more.
andrey
^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: [9fans] fossil speed
2005-01-26 22:26 ` rog
@ 2005-01-26 22:13 ` Charles Forsyth
2005-01-26 22:15 ` Charles Forsyth
2005-01-26 22:40 ` andrey mirtchovski
2005-01-27 7:51 ` Fco. J. Ballesteros
2 siblings, 1 reply; 53+ messages in thread
From: Charles Forsyth @ 2005-01-26 22:13 UTC (permalink / raw)
To: 9fans
ah. which linux system is being used in the office?
^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: [9fans] fossil speed
2005-01-26 22:26 ` rog
2005-01-26 22:13 ` Charles Forsyth
@ 2005-01-26 22:40 ` andrey mirtchovski
2005-01-27 2:47 ` Russ Cox
2005-01-27 7:51 ` Fco. J. Ballesteros
2 siblings, 1 reply; 53+ messages in thread
From: andrey mirtchovski @ 2005-01-26 22:40 UTC (permalink / raw)
To: 9fans
On Wed, 26 Jan 2005 rog@vitanuova.com wrote:
> linux% time rm -r mozilla
>
> real 0m3.621s
> user 0m0.090s
> sys 0m1.180s
> linux%
>
> an equivalent under fossil, removing only half that
> number of files took more than 5 minutes.
here's what i got here:
$ time rm -rf mozilla
real 0m6.685s
user 0m0.166s
sys 0m1.637s
$
plan9% time rm -rf mozilla
0.12u 3.01s 152.24r rm -rf mozilla
plan9%
^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: [9fans] fossil speed
2005-01-26 22:26 ` rog
2005-01-26 22:13 ` Charles Forsyth
2005-01-26 22:40 ` andrey mirtchovski
@ 2005-01-27 7:51 ` Fco. J. Ballesteros
2005-01-27 21:09 ` geoff
2 siblings, 1 reply; 53+ messages in thread
From: Fco. J. Ballesteros @ 2005-01-27 7:51 UTC (permalink / raw)
To: 9fans
> thanks for pointing out the dma/rwm - i hadn't in fact enabled these
> when network booting. however, even after enabling them, it still
Any of you using rwm with ≥2 ide disks in the same machine?
thanks
^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: [9fans] fossil speed
2005-01-27 7:51 ` Fco. J. Ballesteros
@ 2005-01-27 21:09 ` geoff
2005-01-27 21:23 ` andrey mirtchovski
0 siblings, 1 reply; 53+ messages in thread
From: geoff @ 2005-01-27 21:09 UTC (permalink / raw)
To: 9fans
I have a ken fs (not kfs) with 4 IDE disks using dma and rwm
on a Promise controller. It works, but this is using the new
64-bit fs kernel with entirely new IDE code. jmk's got the code.
^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: [9fans] fossil speed
2005-01-27 21:09 ` geoff
@ 2005-01-27 21:23 ` andrey mirtchovski
2005-01-27 21:35 ` Russ Cox
2005-01-27 22:28 ` geoff
0 siblings, 2 replies; 53+ messages in thread
From: andrey mirtchovski @ 2005-01-27 21:23 UTC (permalink / raw)
To: 9fans
> I have a ken fs (not kfs) with 4 IDE disks using dma and rwm
> on a Promise controller. It works, but this is using the new
> 64-bit fs kernel with entirely new IDE code. jmk's got the code.
great! what's the maximum length of a file name in the new ken-fs?
^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: [9fans] fossil speed
2005-01-27 21:23 ` andrey mirtchovski
@ 2005-01-27 21:35 ` Russ Cox
2005-01-27 22:28 ` geoff
1 sibling, 0 replies; 53+ messages in thread
From: Russ Cox @ 2005-01-27 21:35 UTC (permalink / raw)
To: Fans of the OS Plan 9 from Bell Labs
whatever you #define NAMELEN to.
On Thu, 27 Jan 2005 14:23:10 -0700, andrey mirtchovski
<mirtchov@cpsc.ucalgary.ca> wrote:
> > I have a ken fs (not kfs) with 4 IDE disks using dma and rwm
> > on a Promise controller. It works, but this is using the new
> > 64-bit fs kernel with entirely new IDE code. jmk's got the code.
>
> great! what's the maximum length of a file name in the new ken-fs?
>
>
^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: [9fans] fossil speed
2005-01-27 21:23 ` andrey mirtchovski
2005-01-27 21:35 ` Russ Cox
@ 2005-01-27 22:28 ` geoff
2005-01-28 2:11 ` Kenji Okamoto
1 sibling, 1 reply; 53+ messages in thread
From: geoff @ 2005-01-27 22:28 UTC (permalink / raw)
To: 9fans
File names are unbounded, as always in Plan 9 (and originally in Unix,
before Unix was ``fixed'').
File name *components* are limited to NAMELEN-1 bytes (not characters).
This was 27 ASCII characters or 9 Japanese characters. In the new ken fs,
I've made it 55 ASCII characters or 18 Japanese characters, which turns
out to be enough to handle all but one of the file names that lnfs on
my machines recorded (and that was one was some obscene XML file name).
When you install the new ken fs, you can crank NAMELEN up higher if you want,
though you'll then get few directory entries per block.
^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: [9fans] fossil speed
2005-01-27 22:28 ` geoff
@ 2005-01-28 2:11 ` Kenji Okamoto
2005-01-28 4:08 ` geoff
0 siblings, 1 reply; 53+ messages in thread
From: Kenji Okamoto @ 2005-01-28 2:11 UTC (permalink / raw)
To: 9fans
Hi geoff.
> In the new ken fs,
> I've made it 55 ASCII characters or 18 Japanese characters,
I have some long filename by a Windows user like:
履修指針(専門基礎ー化学)12ー1
yeah, it's safe, however, more long filename can be found, I suppose.
> When you install the new ken fs, you can crank NAMELEN up higher if you want,
> though you'll then get few directory entries per block.
So, the file trees already there on now ken's file server must be reinstalled
for your new fileserver?
Kenji
^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: [9fans] fossil speed
2005-01-28 2:11 ` Kenji Okamoto
@ 2005-01-28 4:08 ` geoff
2005-01-28 4:39 ` Kenji Okamoto
0 siblings, 1 reply; 53+ messages in thread
From: geoff @ 2005-01-28 4:08 UTC (permalink / raw)
To: 9fans
It is possible to generate file server kernels exactly compatible with
existing ken fs on-disk file systems, but you get none of the benefits
of the new file server if you do that. It does however let you build
old and new file server kernels from the same sources.
If you want to get the benefits of the new file server (64-bit file
sizes, offsets and block numbers; smarter IDE code ported from the cpu
kernel; larger file name components; indirect blocks beyond
double-indirect; etc.), you have to build a new file server kernel
that will not be compatible on disk with existing file systems (it
will however speak 9p2000 compatibly, though not 9p1, because 9p1
depends crucially on NAMELEN being 28; 9p1 is disabled in the new file
server kernels, but it turns out that nothing needs 9p1 any more [old
drawterm uses it, but it never connects to file servers directly]).
I decided that I could live without the history on my old file server,
so just copied its main file system to a new file server. It's nice
to not need lnfs any more.
^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: [9fans] fossil speed
2005-01-28 4:08 ` geoff
@ 2005-01-28 4:39 ` Kenji Okamoto
2005-01-28 4:54 ` geoff
0 siblings, 1 reply; 53+ messages in thread
From: Kenji Okamoto @ 2005-01-28 4:39 UTC (permalink / raw)
To: 9fans
Thanks geoff for your kind reply.
Yes, 9p2000 is good for all of us, I agree.
> I decided that I could live without the history on my old file server,
> so just copied its main file system to a new file server. It's nice
> to not need lnfs any more.
Ok, I got it.
How about il protocol?
Does the new ken fileserver use TCP?
Kenji -- still a user of ken's file server and fossil
^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: [9fans] fossil speed
2005-01-26 21:32 ` [9fans] fossil speed rog
2005-01-26 21:36 ` andrey mirtchovski
@ 2005-01-27 3:39 ` boyd, rounin
1 sibling, 0 replies; 53+ messages in thread
From: boyd, rounin @ 2005-01-27 3:39 UTC (permalink / raw)
To: Fans of the OS Plan 9 from Bell Labs
try comparing that to an 11/780 with 4Mb of ram and some rm-0[35]s.
--
MGRS 31U DQ 52572 12604
^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: [9fans] browse /sys/src
2005-01-26 2:00 [9fans] browse /sys/src YAMANASHI Takeshi
2005-01-26 2:27 ` Kenji Okamoto
@ 2005-01-26 9:55 ` Fco. J. Ballesteros
1 sibling, 0 replies; 53+ messages in thread
From: Fco. J. Ballesteros @ 2005-01-26 9:55 UTC (permalink / raw)
To: 9fans
[-- Attachment #1: Type: text/plain, Size: 119 bytes --]
The interface for browsing is really nice. It's also nice
to be able to use the dump from there :-)
Thanks a lot.
[-- Attachment #2: Type: message/rfc822, Size: 3067 bytes --]
From: YAMANASHI Takeshi <9.nashi@gmail.com>
To: 9fans@cse.psu.edu
Subject: [9fans] browse /sys/src
Date: Wed, 26 Jan 2005 11:00:32 +0900
Message-ID: <6abdda19759c2c9e08a6a15e7e871166@orthanc.cc.titech.ac.jp>
Hi, I setup a src browsing gateway on a tip9ug server.
http://www.tip9ug.jp/magic/srcgw/sys/src
HISTORY link is not much useful yet because I don't pull
regulary and there's almost nothing in /n/dump. Hope the
gateway finds sourcesdump soon.
Also, a mirror of Installation CD's iso image is also
available on the server. Please read the License before
download the image.
http://plan9.bell-labs.com/plan9dist/license.html
http://www.tip9ug.jp/mirror/plan9.iso.bz2
The image is updated daily.
Hope these will help.
--
Sincerely,
YAMANASHI Takeshi
^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: [9fans] browse /sys/src
@ 2005-01-26 2:09 YAMANASHI Takeshi
0 siblings, 0 replies; 53+ messages in thread
From: YAMANASHI Takeshi @ 2005-01-26 2:09 UTC (permalink / raw)
To: 9fans
> Hi, I setup a src browsing gateway on a tip9ug server.
I forgot one thing. I will try to look into steve's work (srch)
and add a feature which you can jump to the function/variable
declarations when you click on such names.
--
^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: [9fans] browse /sys/src
@ 2005-01-26 2:57 YAMANASHI Takeshi
2005-01-26 3:03 ` andrey mirtchovski
0 siblings, 1 reply; 53+ messages in thread
From: YAMANASHI Takeshi @ 2005-01-26 2:57 UTC (permalink / raw)
To: 9fans
hi,
> Making source trees available to anyone who want it may help
> the community or may not. I think it's not so clear to me yet,
> only to me?
Well... I dunno either. Just that there was a similar service
for 3rd ed. Plan 9 before and I miss it sometimes. So I made it.
Can somebody explain why the similar service for 3rd ed. was shutdown?
I might be able to learn from that too. The url was:
http://offworld.fac.cs.cmu.edu/cgi-bin/9login
--
^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: [9fans] browse /sys/src
@ 2005-01-26 4:09 YAMANASHI Takeshi
0 siblings, 0 replies; 53+ messages in thread
From: YAMANASHI Takeshi @ 2005-01-26 4:09 UTC (permalink / raw)
To: 9fans
Thanks for the explanation about license issues, russ.
I should have written in the announce mail that I had
checked about it.
As for the moral issue, I hope the fact that it is the Plan 9
source is obvious enough to get gateway users to reach back to
Bell Labs.
--
^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: [9fans] browse /sys/src
@ 2005-01-26 5:03 YAMANASHI Takeshi
2005-01-26 5:07 ` Kenji Okamoto
0 siblings, 1 reply; 53+ messages in thread
From: YAMANASHI Takeshi @ 2005-01-26 5:03 UTC (permalink / raw)
To: 9fans
> We, academic community is 'open', anyone can get the resources
> we developed. However, if you want to enter the community,
> you have to be evaluated before. In this sense, academic community
> is not completely 'open'. However, we don't believe it's not open.
> I'd like the Plan 9 community is as such.
I might be missing your point as usual, but the community is open
and anyone can get the sources regardless of how one get them
(9fs sources/web browser). Nothing of browsing the sources on www
contradicts to your idea of open-ness, doesn't it?
--
^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: [9fans] browse /sys/src
2005-01-26 5:03 YAMANASHI Takeshi
@ 2005-01-26 5:07 ` Kenji Okamoto
2005-01-26 5:09 ` Kenji Okamoto
0 siblings, 1 reply; 53+ messages in thread
From: Kenji Okamoto @ 2005-01-26 5:07 UTC (permalink / raw)
To: 9fans
> I might be missing your point as usual, but the community is open
> and anyone can get the sources regardless of how one get them
This is the problem I bramed.☺
> (9fs sources/web browser). Nothing of browsing the sources on www
> contradicts to your idea of open-ness, doesn't it?
You should implement some tools to identify the user and verify who is
the real user. At least to log those informations for us.
Kenji
^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: [9fans] browse /sys/src
@ 2005-01-26 5:44 YAMANASHI Takeshi
2005-01-26 5:48 ` Kenji Okamoto
0 siblings, 1 reply; 53+ messages in thread
From: YAMANASHI Takeshi @ 2005-01-26 5:44 UTC (permalink / raw)
To: 9fans
On Wed Jan 26 14:09:22 JST 2005, Kenji Okamoto wrote:
> > I might be missing your point as usual, but the community is open
> > and anyone can get the sources regardless of how one get them
>
> This is the problem I bramed.?
Didn't you write that you'd like the community to be as such?
We, academic community is 'open', anyone can get the resources
we developed. However, if you want to enter the community,
you have to be evaluated before. In this sense, academic community
is not completely 'open'. However, we don't believe it's not open.
I'd like the Plan 9 community is as such.
> You should implement some tools to identify the user and verify who is
> the real user. At least to log those informations for us.
And I think getting access to the sources doesn't count as entering
the community so one doesn't need to be evaluated before getting them.
Even Lucent isn't gathering these info anyway...
--
^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: [9fans] browse /sys/src
2005-01-26 5:44 YAMANASHI Takeshi
@ 2005-01-26 5:48 ` Kenji Okamoto
2005-01-26 5:54 ` Kenji Okamoto
0 siblings, 1 reply; 53+ messages in thread
From: Kenji Okamoto @ 2005-01-26 5:48 UTC (permalink / raw)
To: 9fans
> And I think getting access to the sources doesn't count as entering
> the community so one doesn't need to be evaluated before getting them.
That's cheap way, I don't like. Probably, in such a way, money or darty
man will win over human's good will.
> Even Lucent isn't gathering these info anyway...
I don't know what kind of job in Lucent is beeing done.
Kenji
^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: [9fans] browse /sys/src
2005-01-26 5:48 ` Kenji Okamoto
@ 2005-01-26 5:54 ` Kenji Okamoto
2005-01-26 6:11 ` andrey mirtchovski
2005-01-26 8:49 ` Skip Tavakkolian
0 siblings, 2 replies; 53+ messages in thread
From: Kenji Okamoto @ 2005-01-26 5:54 UTC (permalink / raw)
To: 9fans
>> Even Lucent isn't gathering these info anyway...
>
> I don't know what kind of job in Lucent is beeing done.
I fogot one.
We need password to get sources!
Password is not so strong to prevent intruder... Maybe so, but,
it's better than nothing.
Kenji
^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: [9fans] browse /sys/src
2005-01-26 5:54 ` Kenji Okamoto
@ 2005-01-26 6:11 ` andrey mirtchovski
2005-01-26 6:24 ` Kenji Okamoto
2005-01-26 6:44 ` Kenji Okamoto
2005-01-26 8:49 ` Skip Tavakkolian
1 sibling, 2 replies; 53+ messages in thread
From: andrey mirtchovski @ 2005-01-26 6:11 UTC (permalink / raw)
To: 9fans
> We need password to get sources!
> Password is not so strong to prevent intruder... Maybe so, but,
> it's better than nothing.
Bell Labs have been fine with redistribution for quite some time, it
appears:
http://lists.cse.psu.edu/archives/9fans/2004-February/031969.html
that doesn't answer the question whether we, 9fans, are ok with other
people's greasy fingers on "our" baby :)
^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: [9fans] browse /sys/src
2005-01-26 6:11 ` andrey mirtchovski
@ 2005-01-26 6:24 ` Kenji Okamoto
2005-01-26 6:44 ` Kenji Okamoto
1 sibling, 0 replies; 53+ messages in thread
From: Kenji Okamoto @ 2005-01-26 6:24 UTC (permalink / raw)
To: 9fans
> http://lists.cse.psu.edu/archives/9fans/2004-February/031969.html
hanger18!
Oh! no!
Kenji
^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: [9fans] browse /sys/src
2005-01-26 6:11 ` andrey mirtchovski
2005-01-26 6:24 ` Kenji Okamoto
@ 2005-01-26 6:44 ` Kenji Okamoto
2005-01-26 6:53 ` andrey mirtchovski
2005-01-26 9:01 ` Vester Thacker
1 sibling, 2 replies; 53+ messages in thread
From: Kenji Okamoto @ 2005-01-26 6:44 UTC (permalink / raw)
To: 9fans
I should be more full to explain my thoughts on this issue.
1) Do we need to expertize Plan 9 distribution more?
No, these decade history of Plan 9 revealed we don't.
Plan 9 is for someone who really want it.
2) sources is not enough for dowloading things for us?
I don't think so.
It seems not so large amount of downloders of Plan 9.☺
3) Do we need another host to prepare when the sources will appear?
Maybe. if so, Yamanashi-san がんばれ!
4) Other downlod site may make the difficulty more?
Yes, now it's not so easy to maintain the consistency between
source trees.
5) anyother?
Kenji
^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: [9fans] browse /sys/src
2005-01-26 6:44 ` Kenji Okamoto
@ 2005-01-26 6:53 ` andrey mirtchovski
2005-01-26 7:01 ` Kenji Okamoto
2005-01-26 9:01 ` Vester Thacker
1 sibling, 1 reply; 53+ messages in thread
From: andrey mirtchovski @ 2005-01-26 6:53 UTC (permalink / raw)
To: 9fans
> 5) anyother?
browsing the source is very educational for newcomers. allowing for an easy
interface to that is beneficial...
i myself used offworld at cmu.edu primarily when learning the system.
especially the way LXR (which is what offworld used) linked the function
calls to the function definition.
it took me half a year to acquire identical swiftness when using acme..
andrey
^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: [9fans] browse /sys/src
2005-01-26 6:44 ` Kenji Okamoto
2005-01-26 6:53 ` andrey mirtchovski
@ 2005-01-26 9:01 ` Vester Thacker
2005-01-27 1:51 ` Kenji Okamoto
1 sibling, 1 reply; 53+ messages in thread
From: Vester Thacker @ 2005-01-26 9:01 UTC (permalink / raw)
To: Fans of the OS Plan 9 from Bell Labs
On Wed, 26 Jan 2005 15:44:37 +0900, Kenji Okamoto
<okamoto@granite.cias.osakafu-u.ac.jp> wrote:
> I should be more full to explain my thoughts on this issue.
>
> 1) Do we need to expertize Plan 9 distribution more?
>
> No, these decade history of Plan 9 revealed we don't.
> Plan 9 is for someone who really want it.
We can agree to disagree, but I say 'Yes' to the question. There are
areas where Plan 9 needs to be improved to stay current. I believe it
is important to change with the times. For example, more and more
machines today are sold without a floppy drive. This makes it
difficult to pass parameters, as with an edited plan9.ini on a boot
floppy, if you're doing a CD only install. Of course, Plan 9 can still
be installed but at a greater cost in time and effort. Why not revise
a method/tool if it is possible? Having an installation that also
serves as an aptitude test is a dumb idea. "A program should do one
thing well", I forgot who said that originally.
> 2) sources is not enough for dowloading things for us?
>
> I don't think so.
> It seems not so large amount of downloders of Plan 9.☺
Viewing sources via http and seeing changes over time is helpful to
some people. Granted, not everyone is a programmer. But if a few
programmers find it useful, then I say why not give them an easy to
view resource.
On another note, I wonder how often Plan 9 sources will appear when
doing a Google search for a C reserve word. ;-)
> 3) Do we need another host to prepare when the sources will appear?
>
> Maybe. if so, Yamanashi-san がんばれ!
It never hurts to be prepared. If Lucent was ever to give up Plan 9
and request the Plan 9 community to move the source tree out of the
Labs, then Plan 9 would have a happy home in Japan. Of course, only if
it meets the approval of the Plan 9 community. ;-)
> 4) Other downlod site may make the difficulty more?
>
> Yes, now it's not so easy to maintain the consistency between
> source trees.
There is only one true source tree, the one at Lucent, everything else
is a mirror image. Consistency is an issue, but a manageable one.
-vester
^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: [9fans] browse /sys/src
2005-01-26 5:54 ` Kenji Okamoto
2005-01-26 6:11 ` andrey mirtchovski
@ 2005-01-26 8:49 ` Skip Tavakkolian
1 sibling, 0 replies; 53+ messages in thread
From: Skip Tavakkolian @ 2005-01-26 8:49 UTC (permalink / raw)
To: 9fans
>>> Even Lucent isn't gathering these info anyway...
>>
>> I don't know what kind of job in Lucent is beeing done.
>
> I fogot one.
> We need password to get sources!
> Password is not so strong to prevent intruder... Maybe so, but,
> it's better than nothing.
>
> Kenji
I'm sure if Lucent had felt a need, they could have
put a "Plan9-worthy" clause in the license. They didn't.
^ permalink raw reply [flat|nested] 53+ messages in thread
end of thread, other threads:[~2005-01-28 4:54 UTC | newest]
Thread overview: 53+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2005-01-26 2:00 [9fans] browse /sys/src YAMANASHI Takeshi
2005-01-26 2:27 ` Kenji Okamoto
2005-01-26 2:31 ` Michael H. Collins
2005-01-26 2:45 ` boyd, rounin
2005-01-26 3:50 ` Russ Cox
2005-01-26 4:28 ` Kenji Okamoto
2005-01-26 4:39 ` Kenji Okamoto
2005-01-26 8:49 ` Skip Tavakkolian
2005-01-26 10:00 ` Matthias Teege
2005-01-26 21:32 ` [9fans] fossil speed rog
2005-01-26 21:36 ` andrey mirtchovski
2005-01-26 22:09 ` Charles Forsyth
2005-01-26 22:18 ` andrey mirtchovski
2005-01-26 22:22 ` andrey mirtchovski
2005-01-26 22:48 ` rog
2005-01-26 22:26 ` rog
2005-01-26 22:13 ` Charles Forsyth
2005-01-26 22:15 ` Charles Forsyth
2005-01-26 22:40 ` andrey mirtchovski
2005-01-27 2:47 ` Russ Cox
2005-01-27 19:20 ` rog
2005-01-27 7:51 ` Fco. J. Ballesteros
2005-01-27 21:09 ` geoff
2005-01-27 21:23 ` andrey mirtchovski
2005-01-27 21:35 ` Russ Cox
2005-01-27 22:28 ` geoff
2005-01-28 2:11 ` Kenji Okamoto
2005-01-28 4:08 ` geoff
2005-01-28 4:39 ` Kenji Okamoto
2005-01-28 4:54 ` geoff
2005-01-27 3:39 ` boyd, rounin
2005-01-26 9:55 ` [9fans] browse /sys/src Fco. J. Ballesteros
2005-01-26 2:09 YAMANASHI Takeshi
2005-01-26 2:57 YAMANASHI Takeshi
2005-01-26 3:03 ` andrey mirtchovski
2005-01-26 3:30 ` Kenji Okamoto
2005-01-26 3:38 ` Devon H. O'Dell
2005-01-26 3:51 ` Kenji Okamoto
2005-01-26 4:09 YAMANASHI Takeshi
2005-01-26 5:03 YAMANASHI Takeshi
2005-01-26 5:07 ` Kenji Okamoto
2005-01-26 5:09 ` Kenji Okamoto
2005-01-26 5:44 YAMANASHI Takeshi
2005-01-26 5:48 ` Kenji Okamoto
2005-01-26 5:54 ` Kenji Okamoto
2005-01-26 6:11 ` andrey mirtchovski
2005-01-26 6:24 ` Kenji Okamoto
2005-01-26 6:44 ` Kenji Okamoto
2005-01-26 6:53 ` andrey mirtchovski
2005-01-26 7:01 ` Kenji Okamoto
2005-01-26 9:01 ` Vester Thacker
2005-01-27 1:51 ` Kenji Okamoto
2005-01-26 8:49 ` Skip Tavakkolian
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).