Re: [9fans] plan 9 ports to unix (including libdraw)

Re: [9fans] plan 9 ports to unix (including libdraw)

[Richard C Bilson]

> cd src/libthread; make tprimes
> gives a slew of errors. maybe cygwin really doesn't have pthreads (though
> the headers are there) or it could be a linker problem. I'm getting *lots*
> of "undefined reference to foo" messages.

Add -lpthread, perhaps?

I also had to add -lrt on Solaris, to find sched_yield.

Re: [9fans] plan 9 ports to unix (including libdraw)

[Caerwyn B Jones]

> I'm just curious whether somebody
> else has thought of it already.

My 9term and sam on unix have plumbing and mouse chording, but these use
the old libXg.
I'll try this weekend to get the 9pm 9term working with the new libdraw,
and include plumbing and chording.

The tricky bit is to get the current working directory of the shell.
On Solaris it's possible to use /proc/n/cwd to find it out. There's
probably an equivalent on Linux.

It's worth doing because it makes the user interface so much more fluid.

-Caerwyn

Re: [9fans] plan 9 ports to unix (including libdraw)

[Derek Fawcus]

On Fri, Oct 17, 2003 at 02:21:22PM -0400, Caerwyn B Jones wrote:
>
> The tricky bit is to get the current working directory of the shell.
> On Solaris it's possible to use /proc/n/cwd to find it out. There's
> probably an equivalent on Linux.

Well from the below,  it's similar.  I believe that readlink() on
/proc/n/cwd (for linux) will get what you want.  I'm not sure what
one does on solaris.

DF

Solaris:

$ ls -l /proc/$$
total 2717
-rw-------   1 dfawcus   2752512 Oct 16 19:09 as
-r--------   1 dfawcus       152 Oct 16 19:09 auxv
-r--------   1 dfawcus        36 Oct 16 19:09 cred
--w-------   1 dfawcus         0 Oct 16 19:09 ctl
lr-x------   1 dfawcus         0 Oct 16 19:09 cwd ->
dr-x------   2 dfawcus      8208 Oct 16 19:09 fd
-r--r--r--   1 dfawcus       120 Oct 16 19:09 lpsinfo
-r--------   1 dfawcus       912 Oct 16 19:09 lstatus
-r--r--r--   1 dfawcus       536 Oct 16 19:09 lusage
dr-xr-xr-x   3 dfawcus        48 Oct 16 19:09 lwp
-r--------   1 dfawcus      2304 Oct 16 19:09 map
dr-x------   2 dfawcus       544 Oct 16 19:09 object
-r--------   1 dfawcus      2776 Oct 16 19:09 pagedata
-r--r--r--   1 dfawcus       336 Oct 16 19:09 psinfo
-r--------   1 dfawcus      2304 Oct 16 19:09 rmap
lr-x------   1 dfawcus         0 Oct 16 19:09 root ->
-r--------   1 dfawcus      1440 Oct 16 19:09 sigact
-r--------   1 dfawcus      1232 Oct 16 19:09 status
-r--r--r--   1 dfawcus       256 Oct 16 19:09 usage
-r--------   1 dfawcus         0 Oct 16 19:09 watch
-r--------   1 dfawcus      3648 Oct 16 19:09 xmap

Linux:

; ls -l /proc/$pid
total 0
-r--r--r--    1 dfawcus  dfawcus         0 Oct 17 21:28 cmdline
lrwxrwxrwx    1 dfawcus  dfawcus         0 Oct 17 21:28 cwd -> /home/dfawcus
-r--------    1 dfawcus  dfawcus         0 Oct 17 21:28 environ
lrwxrwxrwx    1 dfawcus  dfawcus         0 Oct 17 21:28 exe -> /usr/packages/rc-1.6b3/bin/rc-el
dr-x------    2 dfawcus  dfawcus         0 Oct 17 21:28 fd
-r--r--r--    1 dfawcus  dfawcus         0 Oct 17 21:28 maps
-rw-------    1 dfawcus  dfawcus         0 Oct 17 21:28 mem
lrwxrwxrwx    1 dfawcus  dfawcus         0 Oct 17 21:28 root -> /
-r--r--r--    1 dfawcus  dfawcus         0 Oct 17 21:28 stat
-r--r--r--    1 dfawcus  dfawcus         0 Oct 17 21:28 statm
-r--r--r--    1 dfawcus  dfawcus         0 Oct 17 21:28 status

Re: [9fans] plan 9 ports to unix (including libdraw)

[David Presotto]

We need help.  We're falling further behind in supported devices.  We
could use a real browser.  We need better C++ support (someone to
really finish dave hogan's gnu work).  Rsc and I have discussed some
possible projects to keep us going with a small number of people:

- a way to wrap linux drivers so we could use them in our kernel.

	We wouldn't want our most important drivers run this way, but
	it would be nice to quickly get drivers for stuff noone has
	time to work on.

- a native port of X (i.e.  one that actually integrates well with
 plan 9 rather then a straight port).

	If we're going to get a browser that we can use (or use one on
	another machine) this is one way to do it.  Current browsers
	may be outside of our philosophy, but who can live without
	one?

- a better POSIX porting environment.

	'configure' should at least figure out how to build for us.
	Ape isn't quite there.

- an emulation environment we could run Linux binaries in.

	I'm less sanguine about this but it might be a quicker way to
	using stuff from Linux.

I've said Linux rather than FreeBSD.  I like the latter better but the
Linux would be more useful.

I'm not pronouncing our effort at the labs dead (we still depend on
Plan 9 for a lot of stuff) but it sure is moving a lot slower and the
vultures aren't jumping as far away when we throw rocks at them.

Re: [9fans] plan 9 ports to unix (including libdraw)

[okamoto]

> We need help.  We're falling further behind in supported devices.  We
> could use a real browser.  We need better C++ support (someone to
> really finish dave hogan's gnu work).  Rsc and I have discussed some
> possible projects to keep us going with a small number of people:

First of all, we need a robust file server!
I want to shift our file server to fossil+venti, however, I'm still hasitating.
This is because:
1) there are some negative experiences the users report.
2) no clear document to describe how to install it.
3) Is it really safe to use it as fossil+venti+auth server on one machine?

Etec, etc

Kenji

RE: [9fans] plan 9 ports to unix (including libdraw)

[Nigel Roles]

> First of all, we need a robust file server!
> I want to shift our file server to fossil+venti, however, I'm still
> hasitating. This is because: 1) there are some negative experiences
> the users report. 2) no clear document to describe how to install it.
> 3) Is it really safe to use it as fossil+venti+auth server on one
> machine?
>
> Etec, etc
>
> Kenji

I've not had any experience of fossil+venti as to it's reliability,
but I would refer back to previous conversations here about disk
reliability. I'm nervous about committing important data to modern
disk drives, especially IDE drives.

Plan 9 offers three choices in increasing cost:

1. IDE drives with devfs mirroring
2. SCSI drives with devfs mirroring
3. DVD jukebox.

Unfortunately, I can't cost justify anything other than (1). This
has the feel of not actually providing much more reliability. and
recovering from a disk failure would be a homebrew affair, so
isn't quite good enough.

What would be equivalent on cost, and offer a reasonable recovery
route would be hardware RAID 5, so the BIOS can do the recovery
for me if needed.

I'm trying to secure my data, not put it at risk, so writing a
hardware RAID 5 driver for Plan 9 is not a good route to take,
even if I had the time just now!

There is excellent RAID 5 support in Linux, and reasonable (and
perhaps more trustworthy) support in FreeBSD. Thus a port of venti
to Lunix would offer people a means to secure their data without
having to give up on fossil or all the other nice things in Plan 9.

So we'll have less of the talk about rats thank you very much. There
are good reasons for taking the best of both I would have thought.

Re: [9fans] plan 9 ports to unix (including libdraw)

[Charles Forsyth]

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

i'd put fossil+venti on a separate machine from a general
cpu server, much as with the old file server.
that way you can give it lots of memory all to itself, for cache, and you are
much less likely to suffer unpleasantness (because a random program
exhausts memory for instance or trips over something in the system).

i'd have thought the auth could happily coexist, though:
they are small, fairly easily bounded as to the resource requirements,
and are unlikely to cause much trouble.

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

From: okamoto@granite.cias.osakafu-u.ac.jp
To: 9fans@cse.psu.edu
Subject: Re: [9fans] plan 9 ports to unix (including libdraw)
Date: Mon, 20 Oct 2003 11:01:12 +0900
Message-ID: <d0118b5cf7685bf21fe08e1a8707af55@granite.cias.osakafu-u.ac.jp>

> We need help.  We're falling further behind in supported devices.  We
> could use a real browser.  We need better C++ support (someone to
> really finish dave hogan's gnu work).  Rsc and I have discussed some
> possible projects to keep us going with a small number of people:

First of all, we need a robust file server!
I want to shift our file server to fossil+venti, however, I'm still hasitating.
This is because:
1) there are some negative experiences the users report.
2) no clear document to describe how to install it.
3) Is it really safe to use it as fossil+venti+auth server on one machine?

Etec, etc

Kenji

Re: [9fans] plan 9 ports to unix (including libdraw)

[Fco.J.Ballesteros]

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

regarding robustness, I'd say venti and fossil are robust. At least,
we did suffer more problems with the worm that we have with venti&fossil.

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

[-- Attachment #2.1.1: Type: text/plain, Size: 497 bytes --]

i'd put fossil+venti on a separate machine from a general
cpu server, much as with the old file server.
that way you can give it lots of memory all to itself, for cache, and you are
much less likely to suffer unpleasantness (because a random program
exhausts memory for instance or trips over something in the system).

i'd have thought the auth could happily coexist, though:
they are small, fairly easily bounded as to the resource requirements,
and are unlikely to cause much trouble.

[-- Attachment #2.1.2: Type: message/rfc822, Size: 2633 bytes --]

From: okamoto@granite.cias.osakafu-u.ac.jp
To: 9fans@cse.psu.edu
Subject: Re: [9fans] plan 9 ports to unix (including libdraw)
Date: Mon, 20 Oct 2003 11:01:12 +0900
Message-ID: <d0118b5cf7685bf21fe08e1a8707af55@granite.cias.osakafu-u.ac.jp>

> We need help.  We're falling further behind in supported devices.  We
> could use a real browser.  We need better C++ support (someone to
> really finish dave hogan's gnu work).  Rsc and I have discussed some
> possible projects to keep us going with a small number of people:

First of all, we need a robust file server!
I want to shift our file server to fossil+venti, however, I'm still hasitating.
This is because:
1) there are some negative experiences the users report.
2) no clear document to describe how to install it.
3) Is it really safe to use it as fossil+venti+auth server on one machine?

Etec, etc

Kenji

Re: [9fans] plan 9 ports to unix (including libdraw)

[okamoto]

> i'd have thought the auth could happily coexist, though:

So, you think that we don't worry about to have AUTH + Fosssil + Venti
on a machine.   I'm not a speciallist of computer security.   I'd like to know
what is the difference between old file server and new fossil + etc, the
former was a standalone machine, and the latter can be a network machine.

Kenji

Re: [9fans] plan 9 ports to unix (including libdraw)

[Fco.J.Ballesteros]

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

Doesnt have to be a difference if you don't want to have it. For us, our fileserver
is also a regular cpuserver used just for the web, mail, and the like. But you could
certainly use it to export your fossil to the network and nothing else; and it would
behave like the old worm. In fact, we are not even exporting venti, since it
runs only on a loopback interface to service fossil requests.

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

From: okamoto@granite.cias.osakafu-u.ac.jp
To: 9fans@cse.psu.edu
Subject: Re: [9fans] plan 9 ports to unix (including libdraw)
Date: Mon, 20 Oct 2003 17:45:17 +0900
Message-ID: <df0294ec5aceae44f5797c4640e175a0@granite.cias.osakafu-u.ac.jp>

> i'd have thought the auth could happily coexist, though:

So, you think that we don't worry about to have AUTH + Fosssil + Venti
on a machine.   I'm not a speciallist of computer security.   I'd like to know
what is the difference between old file server and new fossil + etc, the
former was a standalone machine, and the latter can be a network machine.

Kenji

Re: [9fans] plan 9 ports to unix (including libdraw)

[ron minnich]

On Mon, 20 Oct 2003 okamoto@granite.cias.osakafu-u.ac.jp wrote:

> 1) there are some negative experiences the users report.

You mean like losing files and lockups? true. Snapshots help here however.
But it is still hardly an ideal situation.

I do not totally agree with some of the linux comments I have seen here.
My experience is that Plan 9 file systems are less reliable than linux
file systems, and both of these are less reliable then freebsd, and none
of them compare to AIX JFS from 1991. In 1991, to reboot an RS/6000 AIX
machine running JFS, you just hit reset. You never lost a file.

For trusting my files to a system, I don't yet see an advantage of Plan 9
over Linux. That situation is set to improve, I suppose. But I just lost a
file today under fossil and I had a fossil lockup last week, so work is
left to be done.

ron

Re: [9fans] plan 9 ports to unix (including libdraw)

[Charles Forsyth]

>>of them compare to AIX JFS from 1991. In 1991, to reboot an RS/6000 AIX
>>machine running JFS, you just hit reset. You never lost a file.

ha ha ha ha ha.

Re: [9fans] plan 9 ports to unix (including libdraw)

[ron minnich]

On Mon, 20 Oct 2003, Charles Forsyth wrote:

> >>of them compare to AIX JFS from 1991. In 1991, to reboot an RS/6000 AIX
> >>machine running JFS, you just hit reset. You never lost a file.
>
> ha ha ha ha ha.


Oh, all right, I'll admit it: *I* never lost a file. YMMV.

But neither did any of the other folks I worked with at U. Penn.

I'm willing to accept that 'reset' is a less-than-sensible way to reboot a
machine.

:-)

ron

Re: [9fans] plan 9 ports to unix (including libdraw)

[mirtchov]

> I'm willing to accept that 'reset' is a less-than-sensible way to reboot a
> machine.

no, you need this:

	NAME
 	      	halt, reboot, poweroff - stop the system.

	SYNOPSIS
       		/sbin/halt [-n] [-w] [-d] [-f] [-i] [-p] [-h]
       		/sbin/reboot [-n] [-w] [-d] [-f] [-i]
       		/sbin/poweroff [-n] [-w] [-d] [-f] [-i] [-h]

also:

	NAME
	       	shutdown - bring the system down

	SYNOPSIS
       		/sbin/shutdown [-t sec] [-arkhncfF] time [warning-message]

but that's not all! you are also required to have the usermode utilities. To quote:

	The usermode package contains the userhelper program, which
	can be used to allow configured programs to be run with
	superuser privileges by ordinary users.

It provides, among other things, the very user-helpful:

	/usr/bin/halt
	/usr/bin/poweroff
	/usr/bin/reboot

which allow a normal user to reboot the console without having
administrative privileges!

You may say "but why don't you just remove the usermode package, eh?"

The answer is hidden here, try to find it:

root@fbsd# rpm -ev usermode
error: Failed dependencies:
        usermode is needed by (installed) redhat-config-proc-0.18-1
        usermode >= 1.36 is needed by (installed) redhat-config-securitylevel-1.0.1-1
        usermode >= 1.36 is needed by (installed) redhat-config-xfree86-0.6.7-1
        usermode = 1.63-1 is needed by (installed) usermode-gtk-1.63-1
        usermode >= 1.36 is needed by (installed) redhat-config-services-0.8.2-1
        usermode is needed by (installed) gtoaster-1.0beta5-9
        usermode is needed by (installed) xawtv-3.74-4
        usermode >= 1.36 is needed by (installed) redhat-config-date-1.5.15-1
        usermode is needed by (installed) gdm-2.4.0.7-14
        usermode >= 1.36 is needed by (installed) up2date-gnome-3.0.7.2-1
root@fbsd#


Now, the $0.02 question is: "Can you guess which of the two 'reboot'
programs, the one that wants root, and the one that doesn't, comes
first in a default RedHat user's $PATH?"

andrey

ps: I had to run sed on this email to change all the '-' in the pasted
man pages from the special short dash symbol that Red Hat uses, surely
to prevent me from searching for documentation on specific options by
typing '/-d' for example.

pps: I'm sending this email as a pissed off FreeBSD user, not as a
pissed off Plan 9 user.  Plan 9 is so detached from such debaucheries,
that their vile nature is incomprehensible to the average 9fan, thus
cannot drive him (her) to such curmudgeonry as witnessed in this
email.

Re: [9fans] plan 9 ports to unix (including libdraw)

[ron minnich]

On Mon, 20 Oct 2003 mirtchov@cpsc.ucalgary.ca wrote:

> pps: I'm sending this email as a pissed off FreeBSD user, not as a
> pissed off Plan 9 user.  Plan 9 is so detached from such debaucheries,
> that their vile nature is incomprehensible to the average 9fan, thus
> cannot drive him (her) to such curmudgeonry as witnessed in this
> email.

yeah, on Plan 9 you reboot and when you come up /lib/ndb/local is gone.

Just happened this morning. Sorry, things have to improve on Plan 9, not
that Linux is a model, but ...

ron

Re: [9fans] plan 9 ports to unix (including libdraw)

[David Presotto]

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

Where does that happen?

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

From: ron minnich <rminnich@lanl.gov>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] plan 9 ports to unix (including libdraw)
Date: Mon, 20 Oct 2003 14:14:53 -0600 (MDT)
Message-ID: <Pine.LNX.4.44.0310201414170.16637-100000@maxroach.lanl.gov>

On Mon, 20 Oct 2003 mirtchov@cpsc.ucalgary.ca wrote:

> pps: I'm sending this email as a pissed off FreeBSD user, not as a
> pissed off Plan 9 user.  Plan 9 is so detached from such debaucheries,
> that their vile nature is incomprehensible to the average 9fan, thus
> cannot drive him (her) to such curmudgeonry as witnessed in this
> email.

yeah, on Plan 9 you reboot and when you come up /lib/ndb/local is gone.

Just happened this morning. Sorry, things have to improve on Plan 9, not
that Linux is a model, but ...

ron

Re: [9fans] plan 9 ports to unix (including libdraw)

[Enache Adrian]

On Mon, Oct 20, 2003 a.d., mirtchov@cpsc.ucalgary.ca wrote:
> ps: I had to run sed on this email to change all the '-' in the pasted
> man pages from the special short dash symbol that Red Hat uses, surely
> to prevent me from searching for documentation on specific options by
> typing '/-d' for example.

The dash is 'MINUS SIGN' (0x2212 - in utf-8: \xe2\x88\x92)
Disable UTF-8 locales to get rid of all that trouble.

export LC_ALL=C
in .bashrc

RH does not really support UTF-8 (there are a lot of horror stories
about their locales defaulting to xx_XX.UTF-8).

Regards,
Adi

Re: [9fans] plan 9 ports to unix (including libdraw)

[mirtchov]

> The dash is 'MINUS SIGN' (0x2212 - in utf-8: \xe2\x88\x92)
> Disable UTF-8 locales to get rid of all that trouble.

no, sorry.  i _want_ to use utf-8 locale.  the fact that it takes 10
years for linux to support it is just another reason for me to
complain :)

at least we stole their fonts :P

Re: [9fans] plan 9 ports to unix (including libdraw)

[Scott Schwartz]

> at least we stole their fonts :P

I just wish Bitstream Vera was a full unicode font, like Cyberbit.
(It's especially nice because it comes in bold and italic variants.)

Re: [9fans] plan 9 ports to unix (including libdraw)

[Skip Tavakkolian]

> I just wish Bitstream Vera was a full unicode font, like Cyberbit.
> (It's especially nice because it comes in bold and italic variants.)

Any chance of getting Oberon's "syntax" font (I think that was the name)?

Re: [9fans] plan 9 ports to unix (including libdraw)

[Geoff Collyer]

I'm still waiting for fossil to settle down.  I haven't yet been able
to shutdown a fossil gracefully (with "fsys sync", a pause, then "fsys
halt") and come back up without any missing blocks.

I've had good experience with Ken's file server, though perhaps the
best part of that is automatic nightly dumps to stable, write-once
optical storage.

I haven't had bad experiences with Linux file systems; I was saying
that I'd be queasy to swap out a Plan 9 kernel and replace it with a
Linux kernel.  I can't see how replacing a relatively small and
well-written kernel with a large and sprawling kernel written by a
cast of hundreds, if not thousands, could improve reliability,
robustness or correctness of the kernel.

Re: [9fans] plan 9 ports to unix (including libdraw)

[okamoto]

> I've had good experience with Ken's file server, though perhaps the
> best part of that is automatic nightly dumps to stable, write-once
> optical storage.

That's the point I wish, although I'm using emulated WORM on scsi disks.
I have no doubt what kinds of bad will happen on my file server.
The file server is out of my consideration when something bad happened.
This is the very point I expect to the new file server.
I have no such skill to write such an exellent file server, and I'm not
complaining to anyone who are developping it.   However, if we must 
concentrate our power to something, I'd like to say it's the file server.

I can continue to make Plan 9 more usable to may by writing some 
applications though.   However, OS itself is not my bussiness.☺

Kenji

Re: [9fans] plan 9 ports to unix (including libdraw)

[okamoto]

I meant the way should be on only one road, that is
fossil+venti file server if possible.

Kenji

Re: [9fans] plan 9 ports to unix (including libdraw)

[Russ Cox]

> I'm still waiting for fossil to settle down.  I haven't yet been able
> to shutdown a fossil gracefully (with "fsys sync", a pause, then "fsys
> halt") and come back up without any missing blocks.

The missing block thing is a red herring, I think.
I suspect that flchk misses some blocks that are actually
reachable, and that we leak maybe a block or two per snapshot.
Either way it hasn't seemed major enough to make time to
track it down.

What I really like about fossil is that once the data
hits Venti you know it's not going to be corrupted by
bugs in Fossil.  Almost all of the fossil development
that I did was done using fossil itself as my file server.
When I trashed the write buffer, I always had the score
from the last archival snapshot (I took archival snapshots
before rebooting with any new code) to save my neck.

That alone makes me feel good enough about it to use for
real data.  Especially now that my Venti server is mirrored
across two different-model 200GB IDE drives.

> I've had good experience with Ken's file server, though perhaps the
> best part of that is automatic nightly dumps to stable, write-once
> optical storage.

Right, this is how I feel about the Venti archives.

> I haven't had bad experiences with Linux file systems; I was saying
> that I'd be queasy to swap out a Plan 9 kernel and replace it with a
> Linux kernel.  I can't see how replacing a relatively small and
> well-written kernel with a large and sprawling kernel written by a
> cast of hundreds, if not thousands, could improve reliability,
> robustness or correctness of the kernel.

I have talked to a few people who independently claim that if you
start Linux running lots of fs accesses and then pull the plug,
fsck never fully recovers, even in ext3.  I haven't verified these
claims, but I trust the people who told me.

Russ

Re: [9fans] plan 9 ports to unix (including libdraw)

[okamoto]

> real data.  Especially now that my Venti server is mirrored
> across two different-model 200GB IDE drives.

How about IDE problem which Niger wrote.
I've been using only scsi disks for our old file server, and now
start to use IDE disks for our new fossil+venti...

Kenji

Re: [9fans] plan 9 ports to unix (including libdraw)

[Russ Cox]

> > real data.  Especially now that my Venti server is mirrored
> > across two different-model 200GB IDE drives.
>
> How about IDE problem which Niger wrote.

That's why I'm mirroring across two different-model 200GB drives.
The theory is that they're not that likely to fail simultaneously.
If you believe that a drive will fail once a year (which I think is high)
then two drives independently failing together will happen once
every few centuries, which is low enough that I can worry about
other problems, like my apartment catching fire.

Russ

Re: [9fans] plan 9 ports to unix (including libdraw)

[ron minnich]

On Mon, 20 Oct 2003, Russ Cox wrote:

> every few centuries, which is low enough that I can worry about
> other problems, like my apartment catching fire.

especially if you keep dropping T23s left and right :-)

ron

Re: [9fans] plan 9 ports to unix (including libdraw)

[David Presotto]

mine has survived dropping twice.  I'm impressed.  First time I
stepped out onto stairs covered with ice and it broke my fall.
Second time the strap on my bag gave out while I was bicycling
to work.  Both times the case fell apart but precious little damage
to the plastic and none to the machine or disk.

RE: [9fans] plan 9 ports to unix (including libdraw)

[Nigel Roles]

9fans-admin@cse.psu.edu wrote:
>>> real data.  Especially now that my Venti server is mirrored
>>> across two different-model 200GB IDE drives.
>>
>> How about IDE problem which Niger wrote.
>
> That's why I'm mirroring across two different-model 200GB drives.
> The theory is that they're not that likely to fail simultaneously.
> If you believe that a drive will fail once a year (which I think is
> high) then two drives independently failing together will happen once
> every few centuries, which is low enough that I can worry about
> other problems, like my apartment catching fire.
>
> Russ

It's certainly true that simultaneous failures are unlikely, and
you should check your fire extinguisher in your apartment, but I
think Geoff made the point a while back that the probability of
failure for every given day is not 1/365.25; it starts high,
drops to near zero, and then climbs rapidly in the few months before
the warranty runs out. This is the "bath tub reliability curve".
Also, if I cannot get to my machine for a few weeks, this
significantly widens the window for a simultaneous failure.
I think a few centuries is optimistic.

In my case I'm more interested in having someone else already
worked out how to replace and rebuild a drive when it fails, hence
a need for a reputable RAID BIOS.

Mentioning no names, our experience with SCSI U320 drives (i.e.
the des. res. drives of the moment) is that price is not a guide
to reliability.

Re: [9fans] plan 9 ports to unix (including libdraw)

[Richard Miller]

> other problems, like my apartment catching fire.

Seems to me there are other possible external causes of multiple disk
failure which are more likely than that one - e.g.  spike on the power
line (or don't you get those in the USA?) or air conditioning failure
during a heatwave.

-- Richard

Re: [9fans] plan 9 ports to unix (including libdraw)

[Adrian Tritschler]

Richard Miller wrote:

>>other problems, like my apartment catching fire.

> Seems to me there are other possible external causes of multiple disk
> failure which are more likely than that one - e.g.  spike on the power
> line (or don't you get those in the USA?) or air conditioning failure
> during a heatwave.

Nah, fully privatised power companies, world's best practice, nothing 
could possibly go wrong... go wrong... go wrong...

One other consideration is theft of the fileserver, especially if it is 
just a PC in the apartment.

Just imagine those two perfectly good, reliable, mirrored drives --- 
stolen along with the stereo and your CDs when the junkies come visiting.

> -- Richard

---------------------------------------------------------------
Adrian Tritschler                          mailto:ajft@ajft.org
Latitude 38°S, Longitude 145°E, Altitude 50m,      Shoe size 44
---------------------------------------------------------------

Re: [9fans] plan 9 ports to unix (including libdraw)

[a]

// ...though perhaps the best part of that is automatic nightly dumps
// to stable, write-once optical storage.

that and the fact that it NEVER crashed. despite serious pounding and
software that almost seemed to by trying to crash it (remember the web
browser interface to the jukebox?). again, there's some distinction to
be made here between the file *system* and the file *server*. was ken's
file *system* good? certainly. but longer file names would've been
nice, and spaces (no, not for anything i create, but for importing!).
but ken's file *server* was bullet-proof.

some other file *systems* i've used have seemed quite good, as well.
but no file *server* comes close.
ア

Re: [9fans] plan 9 ports to unix (including libdraw)

[paurea]

> I do not totally agree with some of the linux comments I have seen here.
> My experience is that Plan 9 file systems are less reliable than linux
> file systems, and both of these are less reliable then freebsd, and none
> of them compare to AIX JFS from 1991. In 1991, to reboot an RS/6000 AIX
> machine running JFS, you just hit reset. You never lost a file.

We use fossil here. On your terminals you can just reboot. I have never
lost a file and find if the most reliable system I ever saw (snapshots make
it even user-proof). I cross my fingers anyway...



						Gorka

Re: [9fans] plan 9 ports to unix (including libdraw)

[C H Forsyth]

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

whether it's RS6000 with JFS, Linux, log-structured file systems or
fossil, unless writes are write-through to disc, if you simply
reset the machine, i'd expect you stand a good chance of losing data
you've written just (ie, instantly) before the reset
(unless the system somehow intercepts the reset).

the systems might use one or more of journalling, soft-writes, or
ordered writes to ensure the logical consistency of the stored file system
data and metadata, if the system is interrupted at arbitrary points.
but nevertheless, unless they buffer all modified data through intermediate NVRAM
that they pick up after a boot, that's just the consistency on storage,
and you'll lose whatever doesn't get to disc before the reset (or if
the device can't write it before power fails).  it might check
cleanly, because the metadata is consistent, but a file is empty!

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

From: paurea@plan9.escet.urjc.es
To: 9fans@cse.psu.edu
Subject: Re: [9fans] plan 9 ports to unix (including libdraw)
Date: Tue, 21 Oct 2003 16:01:20 +0200
Message-ID: <88d8e2add78e9f08ceaa62a7f8bcb2bc@plan9.escet.urjc.es>

> I do not totally agree with some of the linux comments I have seen here.
> My experience is that Plan 9 file systems are less reliable than linux
> file systems, and both of these are less reliable then freebsd, and none
> of them compare to AIX JFS from 1991. In 1991, to reboot an RS/6000 AIX
> machine running JFS, you just hit reset. You never lost a file.

We use fossil here. On your terminals you can just reboot. I have never
lost a file and find if the most reliable system I ever saw (snapshots make
it even user-proof). I cross my fingers anyway...



						Gorka

Re: [9fans] plan 9 ports to unix (including libdraw)

[Fco.J.Ballesteros]

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

There's no disagreement b/w you two. Our terminals are diskless, so
a Twrite was already made and probably you also got your Rwrite
(because you saw the buffer status changed in acme); a reset suffices.

Of course, the file server is a world appart, and we halt it prior to
reset (we do the same for local fossils on terminals).

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

[-- Attachment #2.1.1: Type: text/plain, Size: 880 bytes --]

whether it's RS6000 with JFS, Linux, log-structured file systems or
fossil, unless writes are write-through to disc, if you simply
reset the machine, i'd expect you stand a good chance of losing data
you've written just (ie, instantly) before the reset
(unless the system somehow intercepts the reset).

the systems might use one or more of journalling, soft-writes, or
ordered writes to ensure the logical consistency of the stored file system
data and metadata, if the system is interrupted at arbitrary points.
but nevertheless, unless they buffer all modified data through intermediate NVRAM
that they pick up after a boot, that's just the consistency on storage,
and you'll lose whatever doesn't get to disc before the reset (or if
the device can't write it before power fails).  it might check
cleanly, because the metadata is consistent, but a file is empty!

[-- Attachment #2.1.2: Type: message/rfc822, Size: 2513 bytes --]

From: paurea@plan9.escet.urjc.es
To: 9fans@cse.psu.edu
Subject: Re: [9fans] plan 9 ports to unix (including libdraw)
Date: Tue, 21 Oct 2003 16:01:20 +0200
Message-ID: <88d8e2add78e9f08ceaa62a7f8bcb2bc@plan9.escet.urjc.es>

> I do not totally agree with some of the linux comments I have seen here.
> My experience is that Plan 9 file systems are less reliable than linux
> file systems, and both of these are less reliable then freebsd, and none
> of them compare to AIX JFS from 1991. In 1991, to reboot an RS/6000 AIX
> machine running JFS, you just hit reset. You never lost a file.

We use fossil here. On your terminals you can just reboot. I have never
lost a file and find if the most reliable system I ever saw (snapshots make
it even user-proof). I cross my fingers anyway...



						Gorka

Re: [9fans] plan 9 ports to unix (including libdraw)

[Charles Forsyth]

>>There's no disagreement b/w you two. Our terminals are diskless, so
>>a Twrite was already made and probably you also got your Rwrite
>>(because you saw the buffer status changed in acme); a reset suffices.

in which case the original post didn't really say much about fossil's reliability, which
seemed to be the intent!  your comment does, however, point out one possible advantage
not yet mentioned of the lessened dependence on local discs everywhere
by sharing a venti (fossil) server.   the most reliable disc is one that isn't there!

Re: [9fans] plan 9 ports to unix (including libdraw)

[matt]

> Opinions?

I'm with you, captain.

Seeing the libs exported to another OS is like watching the first rat sliding down the anchor lines.

Unless, of course, it is to put 9p in there somewhere.

The usual outcome is that 90% gets ported and it's the 10% that bites.

Will the mantra be "Linux : better plan9 than plan9' ?

But it's theit time and effort, they are free to spend it how they choose.


Personally I'd settle for fixing Fossil & adding cookies to mothra

m

Re: [9fans] plan 9 ports to unix (including libdraw)

[Nigel Roles]

matt@proweb.co.uk wrote:

>>Opinions?
>>
>>
>
>I'm with you, captain.
>
>Seeing the libs exported to another OS is like watching the first rat sliding down the anchor lines.
>
>
>
A dangerous simile I would have thought. According to commonly held belief,
rats only do this when the ship is sinking.

Re: [9fans] plan 9 ports to unix (including libdraw)

[matt]

>A dangerous simile I would have thought. According to commonly held belief,
rats only do this when the ship is sinking.

That's exactly why I said it.
Once there is no differentiation, plan9 has no reason to live.

Re: [9fans] plan 9 ports to unix (including libdraw)

[Caerwyn B Jones]

Forward the files to me please. I was about to do the port myself.

-Caerwyn



----------------------------------------------------------------------------------------

This is a PRIVATE message. If you are not the intended recipient, please
delete without copying and kindly advise us by e-mail of the mistake in
delivery. NOTE: Regardless of content, this e-mail shall not operate to
bind CSC to any order or other contract unless pursuant to explicit written
agreement or government initiative expressly permitting the use of e-mail
for such purpose.
----------------------------------------------------------------------------------------

[9fans] plan 9 ports to unix (including libdraw)

[Russ Cox]

I've been using Unix (FreeBSD) for day-to-day work for a few
weeks now, and have started to bring over some Plan 9 tools to make
life a bit more hospitable.

Mk was already done, and Scott Schwartz did sam over the summer.

As I mentioned before, I did a fairly complete libdraw port
that is enough to compile samterm almost unchanged from the
current sources (the only real change was to use a named
pipe instead of /srv for the B file).

It has been working pretty well for me on FreeBSD and for
Rob on Mac OS X.  I tested it on Linux but haven't exercised
it very much.

This morning I compiled my crossword puzzle player without
any changes -- just worked (well, except for a little bug in the
libdraw port which I fixed).  I am hopeful about other things
compiling easily.

I'd love to see the plumber and acme made to work, though that
will require some reengineering to eliminate dependence on Plan 9
features.  I'm not likely to have time in the near future, though.
If anyone is interested and has time to hack, I'd be happy to do
a brain dump.

On a similar note, I have a 9P2000 drawterm that is very very alpha.
If you have time to bang on it, I'd be happy to share.  It's not
quite ready for regular use though.  Email me off-list.

http://pdos.lcs.mit.edu/~rsc/software/plan9/

Russ

Re: [9fans] plan 9 ports to unix (including libdraw)

[Caerwyn Jones]

>
> I'd love to see the plumber and acme made to work, though that
> will require some reengineering to eliminate dependence on Plan 9
> features.  I'm not likely to have time in the near future, though.
> If anyone is interested and has time to hack, I'd be happy to do
> a brain dump.

I have a plumber that reads from a named pipe and is single threaded.
I'll post it when I get it to compile with your latest plan9 lib ports.

-Caerwyn

Re: [9fans] plan 9 ports to unix (including libdraw)

[arisawa]

Thanks Russ for your porting Plan 9 tools.
I have downloaded and compiled.

It seems the absence of a directory plan9/lib causes
compile error.

Kenji Arisawa

Re: [9fans] plan 9 ports to unix (including libdraw)

[andrey mirtchovski]

Just for fun I tried compiling my xscr ports for linux/fbsd using your
plan9.tar.gz port...

Here's what I had to add in order to get them going, cvs diff against
the current repository (unchanged parts skipped):

cvs server: Diffing include
Index: include/lib9.h
===================================================================
RCS file: /cvs/plan9/include/lib9.h,v
retrieving revision 1.4
diff -r1.4 lib9.h
296a297,301
>
> #define       HUGE    3.4028234e38
> #define       PIO2    1.570796326794896619231e0
> #define       PI      (PIO2+PIO2)
>
cvs server: Diffing src/lib9
Index: src/lib9/Makefile
===================================================================
RCS file: /cvs/plan9/src/lib9/Makefile,v
retrieving revision 1.6
diff -r1.6 Makefile
21a22,23
>       lrand.$O\
>       frand.$O\



both lrand and frand are from /sys/src/libc/port, with the definition of
'srand' in lrand commented out -- it just uses the unix libc one by default.

andrey

Re: [9fans] plan 9 ports to unix (including libdraw)

[andrey mirtchovski]

that was supposed to go just to russ, sorry...

ps: USED() in Plan 9 accepts more than one argument, USED() in unix' plan9
libs does not..

Re: [9fans] plan 9 ports to unix (including libdraw)

[Richard C Bilson]

To avoid unnecessary duplication of effort, let me note that I'm very
close to having the unix ports running on sparc solaris.

It's been pretty straightforward -- most of what I have so far was
done in an afternoon.  Right now, however, my threads crap out on the
first call to a shared library.  I may have to spend some time
learning more about the dynamic linker than I ever wanted to know
(although, it's possible that I've simply misread the abi *again*).

If anyone feels like poking at it I can send files and diffs.

Kudos to Russ.  The ports are already making life better for me on
Linux/386.

Re: [9fans] plan 9 ports to unix (including libdraw)

[William Josephson]

On Thu, Oct 16, 2003 at 10:53:33PM -0400, Richard C Bilson wrote:
> Kudos to Russ.  The ports are already making life better for me on
> Linux/386.

I just hope we can settle on a definitive port.  I've done three
myself of the same bits (save for libdraw) and Russ has done a few
previously, too.  Every time I've thought it was much better than the
last, yet there's always another.

Re: [9fans] plan 9 ports to unix (including libdraw)

[a]

of late i've been assuming context of things i read a lot, and letting
that overwrite what the message actually says. it's caused problems. i
think my head's broke. so when i read:
   ...close to having the unix ports running on sparc solaris.
somewhere between my eyes and my brain "unix" turned into "plan 9". i
got *really* excited for a few seconds. :-(
ア

Re: [9fans] plan 9 ports to unix (including libdraw)

[Joel Salomon]

I've managed to compile most of the port under cygwin.

cp Make.FreeBSD-386 Make.CYGWIN_NT-5.0-386

in libthread/label.h, change:
 #if defined (__i386__) && (defined(__FreeBSD__) || defined(__linux__))
to:
 #if defined (__i386__) && (defined(__FreeBSD__) || defined(__linux__) || \
 defined(__CYGWIN__))

cp asm-Linux-386.s asm-CYGWIN_NT-5.0-386.s

in lib9:
cp ffork-Darwin.c ffork-CYGWIN_NT-5.0.c
cp rendez-Darwin.c rendez-CYGWIN_NT-5.0.c
(cygwin provides pthreads, so I'm using that interface)

Compiling sam fails, though, with:
disk.o(.text+0x27c): In function `diskwrite':
/yadda yadda/plan9/src/cmd/sam/disk.c:108: undefined reference to `_pwrite'
disk.o(.text+0x31e): In function `diskread':
/yadda yadda/plan9/src/cmd/sam/disk.c:120: undefined reference to `_pread'

Haven't been able to test anything yet.

When a windows port is started, I'll try libdraw under mingw. Some of the
rest compiles, but I can't remember which parts.

> Kudos to Russ.
Seconded.

--Joel

Re: [9fans] plan 9 ports to unix (including libdraw)

[Joel Salomon]

> I've managed to compile most of the port under cygwin.
<snip>
> Haven't been able to test anything yet.

Well I have now...

cd src/libthread; make tprimes
gives a slew of errors. maybe cygwin really doesn't have pthreads (though
the headers are there) or it could be a linker problem. I'm getting *lots*
of "undefined reference to foo" messages.

Anyone have better luck?

--Joel

Re: [9fans] plan 9 ports to unix (including libdraw)

[Bruce Ellis]

you'll find somewhere in the cygwin pthread headers a comment along
the lines of "we don't really support pthreads because we can't swap
stacks".  i didn't look into it any further.

brucee
> cd src/libthread; make tprimes
> gives a slew of errors. maybe cygwin really doesn't have pthreads (though
> the headers are there) or it could be a linker problem. I'm getting *lots*
> of "undefined reference to foo" messages.
>
> Anyone have better luck?
>
> --Joel

Re: [9fans] plan 9 ports to unix (including libdraw)

[Roman Shaposhnick]

Speaking of ports -- I have had this idea for a long time to hack
xterm (or rxvt) and make them understand plumbing the way rio does.
It shouldn't be too hard, and I'm just curious whether somebody
else has thought of it already.

Comments ?

Thanks,
Roman.

On Thu, Oct 16, 2003 at 10:53:33PM -0400, Richard C Bilson wrote:
> To avoid unnecessary duplication of effort, let me note that I'm very
> close to having the unix ports running on sparc solaris.
>
> It's been pretty straightforward -- most of what I have so far was
> done in an afternoon.  Right now, however, my threads crap out on the
> first call to a shared library.  I may have to spend some time
> learning more about the dynamic linker than I ever wanted to know
> (although, it's possible that I've simply misread the abi *again*).
>
> If anyone feels like poking at it I can send files and diffs.
>
> Kudos to Russ.  The ports are already making life better for me on
> Linux/386.
>

Re: [9fans] plan 9 ports to unix (including libdraw)

[matt]

> make them understand plumbing the way rio does.

rio doesn't understand plumbing

Re: [9fans] plan 9 ports to unix (including libdraw)

[Roman Shaposhnick]

On Fri, Oct 17, 2003 at 07:00:25PM +0100, matt@proweb.co.uk wrote:
> > make them understand plumbing the way rio does.
>
> rio doesn't understand plumbing

  sure it does -- otherwise you won't be able to select something
  and tell it "plumb this".

Roman.

Re: [9fans] plan 9 ports to unix (including libdraw)

[matt]

Maybe I should read the ported libs

Perhaps I interpret your 'understand' too deeply.

#include <plumb.h>
Plumbmsg *m;
m = emalloc(sizeof(Plumbmsg));
.. fill m
plumbsend(fd, m)


m