>From 9fans-outgoing-owner Tue Aug 1 01:42:33 1995 Received: by psuvax1.cse.psu.edu id <33971>; Tue, 1 Aug 1995 01:28:59 -0400 Received: from goonsquad.spies.com ([192.216.22.66]) by psuvax1.cse.psu.edu with SMTP id <33958>; Tue, 1 Aug 1995 01:28:42 -0400 Received: by goonsquad.spies.com (Smail3.1.29.1 #2) id m0sd9qs-000245C; Mon, 31 Jul 95 22:26 PDT Message-Id: From: ahm@goonsquad.spies.com (Andreas Meyer) Subject: Re: questions To: 9fans Date: Mon, 31 Jul 1995 01:26:49 -0400 In-Reply-To: <95Jul27.083136edt.33979@psuvax1.cse.psu.edu> from "rob@plan9.att.com" at Jul 27, 95 08:31:11 am Organization: The Internet Wiretap Content-Type: text Content-Length: 457 Sender: owner-9fans Precedence: bulk Reply-To: 9fans rob@plan9.att.com writes: > Those of you who received the first distribution were asked to mail > plan.9@research.att.com with questions. We are turning off that > mail alias; use this 9fans list as a first place for queries from now on. Not to be rude, but I see nothing BUT questions here. Will there eventually be answers? Thanks. Andy -- Andreas Meyer, N2FYE Sustain. Endure. Evolve. ahm@goonsquad.spies.com http://www.spies.com/~ahm/ >From 9fans-outgoing-owner Tue Aug 1 02:38:09 1995 Received: by psuvax1.cse.psu.edu id <34046>; Tue, 1 Aug 1995 02:23:59 -0400 Received: from galapagos.cse.psu.edu ([130.203.2.12]) by psuvax1.cse.psu.edu with SMTP id <33958>; Tue, 1 Aug 1995 02:23:43 -0400 Received: from localhost by galapagos.cse.psu.edu with SMTP id <12684>; Tue, 1 Aug 1995 02:23:16 -0400 To: 9fans Subject: Re: questions In-reply-to: Your message of "Mon, 31 Jul 1995 01:26:49 EDT." Date: Tue, 1 Aug 1995 02:23:04 -0400 From: Scott Schwartz Message-Id: <95Aug1.022316edt.12684@galapagos.cse.psu.edu> Sender: owner-9fans Precedence: bulk Reply-To: 9fans Andreas writes: | Not to be rude, but I see nothing BUT questions here. | Will there eventually be answers? In response to the questions I posted I've gotten answers via private email. Thanks to Jim and Dave for their help! I was going to post a summary once things were stablized a bit, but here's a quick rundown: My ss2 didn't like the new scsi driver. Replacing src/fs/ss/scsi.c with the code from the first edition fixed the disk problems I was seeing. Also, the ss fs gets the clock wrong. In toy.c, I fixed it by incrementing rtc.year by 68 after reading the clock. After doing that, I noticed that the terminal version of the kernel fixes this problem slightly differently, but I haven't tried making that change to the fileserver yet. On a (sparc, at least) auth server, boot dies if you tell it that its ip address is 0.0.0.0; use the real ip number instead. >From 9fans-outgoing-owner Tue Aug 1 02:52:46 1995 Received: by psuvax1.cse.psu.edu id <34051>; Tue, 1 Aug 1995 02:38:41 -0400 Received: from staff.cs.su.OZ.AU ([129.78.8.1]) by psuvax1.cse.psu.edu with SMTP id <34047>; Tue, 1 Aug 1995 02:37:30 -0400 Received: from plan9.cs.su.oz.au by staff.cs.su.OZ.AU (mail from boyd for 9fans@cse.psu.edu) with MHSnet (insertion MHSnet site: staff.cs.su.oz.au); Tue, 01 Aug 1995 16:24:12 +1000 Received: from lore.plan9.cs.su.oz.au. by staff.cs.su.OZ.AU.; Tue, 01 Aug 1995 16:24:09 +1000 From: Boyd Roberts Date: Tue, 1 Aug 1995 02:12:00 -0400 To: 9fans Subject: Re: questions In-Reply-To: Message-ID: <199508011612.27381.out.babun@plan9.cs.su.oz.au> From: ahm@goonsquad.spies.com (Andreas Meyer) Sender: owner-9fans Precedence: bulk Reply-To: 9fans ot to be rude, but I see nothing BUT questions here. Will there eventually be answers? why do you ask? >From 9fans-outgoing-owner Tue Aug 1 08:50:22 1995 Received: by psuvax1.cse.psu.edu id <34047>; Tue, 1 Aug 1995 08:30:55 -0400 Received: from crab.plan9.cs.su.oz.au ([129.78.96.3]) by psuvax1.cse.psu.edu with SMTP id <33958>; Tue, 1 Aug 1995 08:30:35 -0400 Date: Tue, 1 Aug 1995 08:25:37 -0400 From: dhog@plan9.cs.su.oz.au To: 9fans Subject: The Old and the New Message-Id: <95Aug1.083035edt.33958@psuvax1.cse.psu.edu> Sender: owner-9fans Precedence: bulk Reply-To: 9fans Here at Basser we have a mixture of machines running the old and new versions of Plan 9. We would like to get rid of the old version. However, one of these machines is a fileserver, with attached jukebox, containing valuable files. Is it safe to just install a new file server kernel on it? I am guessing that the disk filesystem format hasn't changed; is this a safe assumption to make? Note for those not in the know: the 9P protocol has changed in the second edition, due to changes in the way that Plan 9 does its authentication. Writing a "protocol convertor" looks infeasible, unless you only want to log in as user "none". Not all files on the old system are publically readable, and neither should they be. Currently we have one CPU server still on the old system, allowing us to use ftpfs to access the old files. But this is quite clumsy, hence my desire to just run the new system with the old files. So... Can it be done? >From 9fans-outgoing-owner Tue Aug 1 09:57:20 1995 Received: by psuvax1.cse.psu.edu id <34052>; Tue, 1 Aug 1995 09:32:46 -0400 Received: from crab.plan9.cs.su.oz.au ([129.78.96.3]) by psuvax1.cse.psu.edu with SMTP id <34049>; Tue, 1 Aug 1995 09:32:28 -0400 Date: Tue, 1 Aug 1995 09:27:31 -0400 From: David Hogan To: 9fans Subject: Re: plan 9 for sun 3/60 Message-Id: <95Aug1.093228edt.34049@psuvax1.cse.psu.edu> Sender: owner-9fans Precedence: bulk Reply-To: 9fans forsyth@plan9.cs.york.ac.uk writes: >several people ported older versions of Plan 9 to bits of the Sun-3 line. >i did one locally for the sun-3/50 and sun-3/60; since i'm still using >it, i'll probably do the modest amount of work required to get the >new version running. i'm not promising anything though, since i might >just buy some PCs instead. I'm one of the several. I actually have the new system running on 3/50s and 3/60s. At some stage I will tidy this up and make it available to anyone who cares (and has a valid license). I also have 80% of a port of Plan 9 to the DEC Alpha architecture. Currently only axp 400s and 500s. I plan to make this available when I reach 85% :-) I'm hoping that someone out there who has a spare alpha will help to finish it off. Since both of these ports are derived from Plan 9, I am only allowed to give them to other licencees. This will mean checking with AT&T that you actually have a licence. Please note that I am not quite ready to distribute the alpha port -- preparing the distribution will take time, which I am short of at the moment. I am telling you all this to try to avoid duplication of effort. I'll announce to the list when it's ready -- hopefully within a month. >From 9fans-outgoing-owner Tue Aug 1 12:02:58 1995 Received: by psuvax1.cse.psu.edu id <33960>; Tue, 1 Aug 1995 11:16:09 -0400 Received: from plan9.att.com ([192.20.225.252]) by psuvax1.cse.psu.edu with SMTP id <34059>; Tue, 1 Aug 1995 11:11:00 -0400 From: ken@plan9.att.com To: 9fans Date: Tue, 1 Aug 1995 11:01:40 -0400 Message-Id: <95Aug1.111100edt.34059@psuvax1.cse.psu.edu> Sender: owner-9fans Precedence: bulk Reply-To: 9fans > Here at Basser we have a mixture of machines running the old > and new versions of Plan 9. We would like to get rid of the old > version. However, one of these machines is a fileserver, with > attached jukebox, containing valuable files. Is it safe to just install > a new file server kernel on it? I am guessing that the disk filesystem > format hasn't changed; is this a safe assumption to make? > Note for those not in the know: the 9P protocol has changed in the > second edition, due to changes in the way that Plan 9 does its > authentication. Writing a "protocol convertor" looks infeasible, > unless you only want to log in as user "none". Not all files on the old > system are publically readable, and neither should they be. Currently > we have one CPU server still on the old system, allowing us to use ftpfs > to access the old files. But this is quite clumsy, hence my desire > to just run the new system with the old files. > So... Can it be done? the disk format is the same. there should be no problem running the new FS code on the old disk. ken >From 9fans-outgoing-owner Tue Aug 1 13:20:46 1995 Received: by psuvax1.cse.psu.edu id <34076>; Tue, 1 Aug 1995 12:46:25 -0400 Received: from BROWNVM.brown.edu ([128.148.19.19]) by psuvax1.cse.psu.edu with SMTP id <34151>; Tue, 1 Aug 1995 12:36:00 -0400 Received: from monte.chem.brown.edu by BROWNVM.brown.edu (IBM VM SMTP V2R2) with TCP; Tue, 01 Aug 95 12:14:17 EDT Received: from cse.psu.edu by monte.chem.brown.edu via UUCP (950221.405.SGI.8.6.10/911001.SGI) for 9fans@cse.psu.edu id MAA00286; Tue, 1 Aug 1995 12:24:24 -0400 Date: Tue, 1 Aug 1995 12:24:24 -0400 From: 9fans-outgoing-owner To: <9fans> Message-Id: <199508011624.MAA00286@monte.chem.brown.edu> Apparently-To: 9fans@cse.psu.edu Sender: owner-9fans Precedence: bulk Reply-To: 9fans ***** UNDELIVERABLE MAIL sent to absinthe, being returned by monte!absinthe ***** mail: Error # 8 'Invalid recipient' encountered on system monte Received: from nick.chem.brown.edu by monte.chem.brown.edu via ESMTP (950221.405.SGI.8.6.10/911001.SGI) for id MAA00277; Tue, 1 Aug 1995 12:24:22 -0400 Received: from Brown.EDU by nick.chem.brown.edu via ESMTP (950221.405.SGI.8.6.10/911001.SGI) for id MAA00922; Tue, 1 Aug 1995 12:04:04 -0400 Received: (from daemon@localhost) by Brown.EDU (8.6.10/8.6.10) id MAA04435 for absinthe@monte.chem.Brown.EDU; Tue, 1 Aug 1995 12:05:44 -0400 Received: from psuvax1.cse.psu.edu (psuvax1.cse.psu.edu [130.203.1.6]) by Brown.EDU (8.6.10/8.6.10) with SMTP id MAA04428 for ; Tue, 1 Aug 1995 12:05:42 -0400 Received: by psuvax1.cse.psu.edu id <33960>; Tue, 1 Aug 1995 11:16:09 -0400 Received: from plan9.att.com ([192.20.225.252]) by psuvax1.cse.psu.edu with SMTP id <34059>; Tue, 1 Aug 1995 11:11:00 -0400 X-PH: V4.2@Brown.EDU From: ken@plan9.att.com To: 9fans@cse.psu.edu Date: Tue, 1 Aug 1995 11:01:40 -0400 Message-Id: <95Aug1.111100edt.34059@psuvax1.cse.psu.edu> Sender: owner-9fans@cse.psu.edu Precedence: bulk Reply-To: 9fans@cse.psu.edu > Here at Basser we have a mixture of machines running the old > and new versions of Plan 9. We would like to get rid of the old > version. However, one of these machines is a fileserver, with > attached jukebox, containing valuable files. Is it safe to just install > a new file server kernel on it? I am guessing that the disk filesystem > format hasn't changed; is this a safe assumption to make? > Note for those not in the know: the 9P protocol has changed in the > second edition, due to changes in the way that Plan 9 does its > authentication. Writing a "protocol convertor" looks infeasible, > unless you only want to log in as user "none". Not all files on the old > system are publically readable, and neither should they be. Currently > we have one CPU server still on the old system, allowing us to use ftpfs > to access the old files. But this is quite clumsy, hence my desire > to just run the new system with the old files. > So... Can it be done? the disk format is the same. there should be no problem running the new FS code on the old disk. ken >From 9fans-outgoing-owner Tue Aug 1 13:56:43 1995 Received: by psuvax1.cse.psu.edu id <34078>; Tue, 1 Aug 1995 13:17:47 -0400 Received: from BROWNVM.brown.edu ([128.148.19.19]) by psuvax1.cse.psu.edu with SMTP id <34155>; Tue, 1 Aug 1995 12:36:37 -0400 Received: from monte.chem.brown.edu by BROWNVM.brown.edu (IBM VM SMTP V2R2) with TCP; Tue, 01 Aug 95 12:14:25 EDT Received: from cse.psu.edu by monte.chem.brown.edu via UUCP (950221.405.SGI.8.6.10/911001.SGI) for 9fans@cse.psu.edu id MAA00329; Tue, 1 Aug 1995 12:24:32 -0400 Date: Tue, 1 Aug 1995 12:24:32 -0400 From: 9fans-outgoing-owner To: <9fans> Message-Id: <199508011624.MAA00329@monte.chem.brown.edu> Apparently-To: 9fans@cse.psu.edu Sender: owner-9fans Precedence: bulk Reply-To: 9fans ***** UNDELIVERABLE MAIL sent to absinthe, being returned by monte!absinthe ***** mail: Error # 8 'Invalid recipient' encountered on system monte Received: from nick.chem.brown.edu by monte.chem.brown.edu via ESMTP (950221.405.SGI.8.6.10/911001.SGI) for id MAA00314; Tue, 1 Aug 1995 12:24:29 -0400 Received: from Brown.EDU by nick.chem.brown.edu via ESMTP (950221.405.SGI.8.6.10/911001.SGI) for id IAA00694; Tue, 1 Aug 1995 08:50:57 -0400 Received: (from daemon@localhost) by Brown.EDU (8.6.10/8.6.10) id IAA13932 for absinthe@monte.chem.Brown.EDU; Tue, 1 Aug 1995 08:52:38 -0400 Received: from psuvax1.cse.psu.edu (psuvax1.cse.psu.edu [130.203.1.6]) by Brown.EDU (8.6.10/8.6.10) with SMTP id IAA13927 for ; Tue, 1 Aug 1995 08:52:36 -0400 Received: by psuvax1.cse.psu.edu id <34047>; Tue, 1 Aug 1995 08:30:55 -0400 Received: from crab.plan9.cs.su.oz.au ([129.78.96.3]) by psuvax1.cse.psu.edu with SMTP id <33958>; Tue, 1 Aug 1995 08:30:35 -0400 Date: Tue, 1 Aug 1995 08:25:37 -0400 X-PH: V4.2@Brown.EDU From: dhog@plan9.cs.su.oz.au To: 9fans@cse.psu.edu Subject: The Old and the New Message-Id: <95Aug1.083035edt.33958@psuvax1.cse.psu.edu> Sender: owner-9fans@cse.psu.edu Precedence: bulk Reply-To: 9fans@cse.psu.edu Here at Basser we have a mixture of machines running the old and new versions of Plan 9. We would like to get rid of the old version. However, one of these machines is a fileserver, with attached jukebox, containing valuable files. Is it safe to just install a new file server kernel on it? I am guessing that the disk filesystem format hasn't changed; is this a safe assumption to make? Note for those not in the know: the 9P protocol has changed in the second edition, due to changes in the way that Plan 9 does its authentication. Writing a "protocol convertor" looks infeasible, unless you only want to log in as user "none". Not all files on the old system are publically readable, and neither should they be. Currently we have one CPU server still on the old system, allowing us to use ftpfs to access the old files. But this is quite clumsy, hence my desire to just run the new system with the old files. So... Can it be done? >From 9fans-outgoing-owner Tue Aug 1 14:29:44 1995 Received: by psuvax1.cse.psu.edu id <34079>; Tue, 1 Aug 1995 13:54:17 -0400 Received: from BROWNVM.brown.edu ([128.148.19.19]) by psuvax1.cse.psu.edu with SMTP id <34153>; Tue, 1 Aug 1995 12:36:47 -0400 Received: from monte.chem.brown.edu by BROWNVM.brown.edu (IBM VM SMTP V2R2) with TCP; Tue, 01 Aug 95 12:14:21 EDT Received: from cse.psu.edu by monte.chem.brown.edu via UUCP (950221.405.SGI.8.6.10/911001.SGI) for 9fans@cse.psu.edu id MAA00301; Tue, 1 Aug 1995 12:24:26 -0400 Date: Tue, 1 Aug 1995 12:24:26 -0400 From: 9fans-outgoing-owner To: <9fans> Message-Id: <199508011624.MAA00301@monte.chem.brown.edu> Apparently-To: 9fans@cse.psu.edu Sender: owner-9fans Precedence: bulk Reply-To: 9fans ***** UNDELIVERABLE MAIL sent to absinthe, being returned by monte!absinthe ***** mail: Error # 8 'Invalid recipient' encountered on system monte Received: from nick.chem.brown.edu by monte.chem.brown.edu via ESMTP (950221.405.SGI.8.6.10/911001.SGI) for id MAA00290; Tue, 1 Aug 1995 12:24:25 -0400 Received: from Brown.EDU by nick.chem.brown.edu via ESMTP (950221.405.SGI.8.6.10/911001.SGI) for id JAA00743; Tue, 1 Aug 1995 09:56:35 -0400 Received: (from daemon@localhost) by Brown.EDU (8.6.10/8.6.10) id JAA20604 for absinthe@monte.chem.Brown.EDU; Tue, 1 Aug 1995 09:58:14 -0400 Received: from psuvax1.cse.psu.edu (psuvax1.cse.psu.edu [130.203.1.6]) by Brown.EDU (8.6.10/8.6.10) with SMTP id JAA20585 for ; Tue, 1 Aug 1995 09:58:05 -0400 Received: by psuvax1.cse.psu.edu id <34052>; Tue, 1 Aug 1995 09:32:46 -0400 Received: from crab.plan9.cs.su.oz.au ([129.78.96.3]) by psuvax1.cse.psu.edu with SMTP id <34049>; Tue, 1 Aug 1995 09:32:28 -0400 Date: Tue, 1 Aug 1995 09:27:31 -0400 X-PH: V4.2@Brown.EDU From: David Hogan To: 9fans@cse.psu.edu Subject: Re: plan 9 for sun 3/60 Message-Id: <95Aug1.093228edt.34049@psuvax1.cse.psu.edu> Sender: owner-9fans@cse.psu.edu Precedence: bulk Reply-To: 9fans@cse.psu.edu forsyth@plan9.cs.york.ac.uk writes: >several people ported older versions of Plan 9 to bits of the Sun-3 line. >i did one locally for the sun-3/50 and sun-3/60; since i'm still using >it, i'll probably do the modest amount of work required to get the >new version running. i'm not promising anything though, since i might >just buy some PCs instead. I'm one of the several. I actually have the new system running on 3/50s and 3/60s. At some stage I will tidy this up and make it available to anyone who cares (and has a valid license). I also have 80% of a port of Plan 9 to the DEC Alpha architecture. Currently only axp 400s and 500s. I plan to make this available when I reach 85% :-) I'm hoping that someone out there who has a spare alpha will help to finish it off. Since both of these ports are derived from Plan 9, I am only allowed to give them to other licencees. This will mean checking with AT&T that you actually have a licence. Please note that I am not quite ready to distribute the alpha port -- preparing the distribution will take time, which I am short of at the moment. I am telling you all this to try to avoid duplication of effort. I'll announce to the list when it's ready -- hopefully within a month. >From 9fans-outgoing-owner Tue Aug 1 15:00:27 1995 Received: by psuvax1.cse.psu.edu id <34080>; Tue, 1 Aug 1995 14:27:50 -0400 Received: from BROWNVM.brown.edu ([128.148.19.19]) by psuvax1.cse.psu.edu with SMTP id <34129>; Tue, 1 Aug 1995 12:37:05 -0400 Received: from monte.chem.brown.edu by BROWNVM.brown.edu (IBM VM SMTP V2R2) with TCP; Tue, 01 Aug 95 12:14:41 EDT Received: from cse.psu.edu by monte.chem.brown.edu via UUCP (950221.405.SGI.8.6.10/911001.SGI) for 9fans@cse.psu.edu id MAA00397; Tue, 1 Aug 1995 12:24:47 -0400 Date: Tue, 1 Aug 1995 12:24:47 -0400 From: 9fans-outgoing-owner To: <9fans> Message-Id: <199508011624.MAA00397@monte.chem.brown.edu> Apparently-To: 9fans@cse.psu.edu Sender: owner-9fans Precedence: bulk Reply-To: 9fans ***** UNDELIVERABLE MAIL sent to absinthe, being returned by monte!absinthe ***** mail: Error # 8 'Invalid recipient' encountered on system monte Received: from nick.chem.brown.edu by monte.chem.brown.edu via ESMTP (950221.405.SGI.8.6.10/911001.SGI) for id MAA00386; Tue, 1 Aug 1995 12:24:44 -0400 Received: from Brown.EDU by nick.chem.brown.edu via ESMTP (950221.405.SGI.8.6.10/911001.SGI) for id CAA00549; Tue, 1 Aug 1995 02:59:15 -0400 Received: (from daemon@localhost) by Brown.EDU (8.6.10/8.6.10) id DAA03496 for absinthe@monte.chem.Brown.EDU; Tue, 1 Aug 1995 03:00:56 -0400 Received: from psuvax1.cse.psu.edu (psuvax1.cse.psu.edu [130.203.1.6]) by Brown.EDU (8.6.10/8.6.10) with SMTP id DAA03491 for ; Tue, 1 Aug 1995 03:00:53 -0400 Received: by psuvax1.cse.psu.edu id <34051>; Tue, 1 Aug 1995 02:38:41 -0400 Received: from staff.cs.su.OZ.AU ([129.78.8.1]) by psuvax1.cse.psu.edu with SMTP id <34047>; Tue, 1 Aug 1995 02:37:30 -0400 Received: from plan9.cs.su.oz.au by staff.cs.su.OZ.AU (mail from boyd for 9fans@cse.psu.edu) with MHSnet (insertion MHSnet site: staff.cs.su.oz.au); Tue, 01 Aug 1995 16:24:12 +1000 Received: from lore.plan9.cs.su.oz.au. by staff.cs.su.OZ.AU.; Tue, 01 Aug 1995 16:24:09 +1000 X-PH: V4.2@Brown.EDU From: Boyd Roberts Date: Tue, 1 Aug 1995 02:12:00 -0400 To: 9fans@cse.psu.edu Subject: Re: questions In-Reply-To: Message-ID: <199508011612.27381.out.babun@plan9.cs.su.oz.au> From: ahm@goonsquad.spies.com (Andreas Meyer) Sender: owner-9fans@cse.psu.edu Precedence: bulk Reply-To: 9fans@cse.psu.edu ot to be rude, but I see nothing BUT questions here. Will there eventually be answers? why do you ask? >From 9fans-outgoing-owner Tue Aug 1 15:31:23 1995 Received: by psuvax1.cse.psu.edu id <34083>; Tue, 1 Aug 1995 14:56:04 -0400 Received: from BROWNVM.brown.edu ([128.148.19.19]) by psuvax1.cse.psu.edu with SMTP id <34128>; Tue, 1 Aug 1995 12:36:54 -0400 Received: from monte.chem.brown.edu by BROWNVM.brown.edu (IBM VM SMTP V2R2) with TCP; Tue, 01 Aug 95 12:14:37 EDT Received: from cse.psu.edu by monte.chem.brown.edu via UUCP (950221.405.SGI.8.6.10/911001.SGI) for 9fans@cse.psu.edu id MAA00383; Tue, 1 Aug 1995 12:24:43 -0400 Date: Tue, 1 Aug 1995 12:24:43 -0400 From: 9fans-outgoing-owner To: <9fans> Message-Id: <199508011624.MAA00383@monte.chem.brown.edu> Apparently-To: 9fans@cse.psu.edu Sender: owner-9fans Precedence: bulk Reply-To: 9fans ***** UNDELIVERABLE MAIL sent to absinthe, being returned by monte!absinthe ***** mail: Error # 8 'Invalid recipient' encountered on system monte Received: from nick.chem.brown.edu by monte.chem.brown.edu via ESMTP (950221.405.SGI.8.6.10/911001.SGI) for id MAA00372; Tue, 1 Aug 1995 12:24:42 -0400 Received: from Brown.EDU by nick.chem.brown.edu via ESMTP (950221.405.SGI.8.6.10/911001.SGI) for id CAA00542; Tue, 1 Aug 1995 02:42:25 -0400 Received: (from daemon@localhost) by Brown.EDU (8.6.10/8.6.10) id CAA03137 for absinthe@monte.chem.Brown.EDU; Tue, 1 Aug 1995 02:44:06 -0400 Received: from psuvax1.cse.psu.edu (psuvax1.cse.psu.edu [130.203.1.6]) by Brown.EDU (8.6.10/8.6.10) with SMTP id CAA03132 for ; Tue, 1 Aug 1995 02:44:04 -0400 Received: by psuvax1.cse.psu.edu id <34046>; Tue, 1 Aug 1995 02:23:59 -0400 Received: from galapagos.cse.psu.edu ([130.203.2.12]) by psuvax1.cse.psu.edu with SMTP id <33958>; Tue, 1 Aug 1995 02:23:43 -0400 Received: from localhost by galapagos.cse.psu.edu with SMTP id <12684>; Tue, 1 Aug 1995 02:23:16 -0400 X-PH: V4.2@Brown.EDU To: 9fans@cse.psu.edu Subject: Re: questions In-reply-to: Your message of "Mon, 31 Jul 1995 01:26:49 EDT." Date: Tue, 1 Aug 1995 02:23:04 -0400 From: Scott Schwartz Message-Id: <95Aug1.022316edt.12684@galapagos.cse.psu.edu> Sender: owner-9fans@cse.psu.edu Precedence: bulk Reply-To: 9fans@cse.psu.edu Andreas writes: | Not to be rude, but I see nothing BUT questions here. | Will there eventually be answers? In response to the questions I posted I've gotten answers via private email. Thanks to Jim and Dave for their help! I was going to post a summary once things were stablized a bit, but here's a quick rundown: My ss2 didn't like the new scsi driver. Replacing src/fs/ss/scsi.c with the code from the first edition fixed the disk problems I was seeing. Also, the ss fs gets the clock wrong. In toy.c, I fixed it by incrementing rtc.year by 68 after reading the clock. After doing that, I noticed that the terminal version of the kernel fixes this problem slightly differently, but I haven't tried making that change to the fileserver yet. On a (sparc, at least) auth server, boot dies if you tell it that its ip address is 0.0.0.0; use the real ip number instead. >From 9fans-outgoing-owner Tue Aug 1 18:05:23 1995 Received: by psuvax1.cse.psu.edu id <34240>; Tue, 1 Aug 1995 17:30:47 -0400 Received: from burdell.cc.gatech.edu ([130.207.3.207]) by psuvax1.cse.psu.edu with SMTP id <34313>; Tue, 1 Aug 1995 16:26:01 -0400 Received: from lennon.cc.gatech.edu (snm@lennon.cc.gatech.edu [130.207.9.20]) by burdell.cc.gatech.edu (8.6.12/8.6.9) with ESMTP id PAA04195 for <9fans@cse.psu.edu>; Tue, 1 Aug 1995 15:09:13 -0400 Received: (from snm@localhost) by lennon.cc.gatech.edu (8.6.10/8.6.9) id PAA11479 for 9fans@cse.psu.edu; Tue, 1 Aug 1995 15:09:09 -0400 Date: Tue, 1 Aug 1995 15:09:09 -0400 From: snm@cc.gatech.edu (Sathis Menon) Message-Id: <199508011909.PAA11479@lennon.cc.gatech.edu> To: 9fans Subject: unsubscribe Sender: owner-9fans Precedence: bulk Reply-To: 9fans unsubscribe >From 9fans-outgoing-owner Tue Aug 1 18:40:38 1995 Received: by psuvax1.cse.psu.edu id <34049>; Tue, 1 Aug 1995 18:13:27 -0400 Received: from BROWNVM.brown.edu ([128.148.19.19]) by psuvax1.cse.psu.edu with SMTP id <34060>; Tue, 1 Aug 1995 16:41:04 -0400 Received: from monte.chem.brown.edu by BROWNVM.brown.edu (IBM VM SMTP V2R2) with TCP; Tue, 01 Aug 95 12:45:23 EDT Received: from cse.psu.edu by monte.chem.brown.edu via UUCP (950221.405.SGI.8.6.10/911001.SGI) for 9fans@cse.psu.edu id MAA00415; Tue, 1 Aug 1995 12:24:50 -0400 Date: Tue, 1 Aug 1995 12:24:50 -0400 From: 9fans-outgoing-owner To: <9fans> Message-Id: <199508011624.MAA00415@monte.chem.brown.edu> Apparently-To: 9fans@cse.psu.edu Sender: owner-9fans Precedence: bulk Reply-To: 9fans ***** UNDELIVERABLE MAIL sent to absinthe, being returned by monte!absinthe ***** mail: Error # 8 'Invalid recipient' encountered on system monte Received: from nick.chem.brown.edu by monte.chem.brown.edu via ESMTP (950221.405.SGI.8.6.10/911001.SGI) for id MAA00398; Tue, 1 Aug 1995 12:24:46 -0400 Received: from Brown.EDU by nick.chem.brown.edu via ESMTP (950221.405.SGI.8.6.10/911001.SGI) for id BAA00524; Tue, 1 Aug 1995 01:45:26 -0400 Received: (from daemon@localhost) by Brown.EDU (8.6.10/8.6.10) id BAA01624 for absinthe@monte.chem.Brown.EDU; Tue, 1 Aug 1995 01:47:07 -0400 Received: from psuvax1.cse.psu.edu (psuvax1.cse.psu.edu [130.203.1.6]) by Brown.EDU (8.6.10/8.6.10) with SMTP id BAA01614 for ; Tue, 1 Aug 1995 01:47:04 -0400 Received: by psuvax1.cse.psu.edu id <33971>; Tue, 1 Aug 1995 01:28:59 -0400 Received: from goonsquad.spies.com ([192.216.22.66]) by psuvax1.cse.psu.edu with SMTP id <33958>; Tue, 1 Aug 1995 01:28:42 -0400 Received: by goonsquad.spies.com (Smail3.1.29.1 #2) id m0sd9qs-000245C; Mon, 31 Jul 95 22:26 PDT Message-Id: X-PH: V4.2@Brown.EDU From: ahm@goonsquad.spies.com (Andreas Meyer) Subject: Re: questions To: 9fans@cse.psu.edu Date: Mon, 31 Jul 1995 01:26:49 -0400 In-Reply-To: <95Jul27.083136edt.33979@psuvax1.cse.psu.edu> from "rob@plan9.att.com" at Jul 27, 95 08:31:11 am Organization: The Internet Wiretap Content-Type: text Content-Length: 457 Sender: owner-9fans@cse.psu.edu Precedence: bulk Reply-To: 9fans@cse.psu.edu rob@plan9.att.com writes: > Those of you who received the first distribution were asked to mail > plan.9@research.att.com with questions. We are turning off that > mail alias; use this 9fans list as a first place for queries from now on. Not to be rude, but I see nothing BUT questions here. Will there eventually be answers? Thanks. Andy -- Andreas Meyer, N2FYE Sustain. Endure. Evolve. ahm@goonsquad.spies.com http://www.spies.com/~ahm/ >From 9fans-outgoing-owner Tue Aug 1 19:01:45 1995 Received: by psuvax1.cse.psu.edu id <34088>; Tue, 1 Aug 1995 18:39:49 -0400 Received: from optima.cs.arizona.edu ([192.12.69.5]) by psuvax1.cse.psu.edu with SMTP id <34142>; Tue, 1 Aug 1995 16:53:47 -0400 Received: from baskerville.CS.Arizona.EDU by optima.cs.arizona.edu (5.65c/15) via SMTP id AA24692; Tue, 1 Aug 1995 10:27:02 MST Received: (from jdavis@localhost) by baskerville.CS.Arizona.EDU (8.6.9/8.6.6) id KAA28299; Tue, 1 Aug 1995 10:27:02 -0700 Date: Tue, 1 Aug 1995 13:27:01 -0400 From: Jim Davis X-Sender: jdavis@baskerville To: 9fans Subject: comp.os.plan9 In-Reply-To: <95Aug1.111100edt.34059@psuvax1.cse.psu.edu> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-9fans Precedence: bulk Reply-To: 9fans It looks like the voting address is working again. Voting on the newsgroup ends tomorrow; you can get a copy of the Call For Votes, which contains the voting instructions, by sending email to the mailbot at plan9-cfv@sub-rosa.com. Remember it takes a supermajority for a newsgroup proposal to pass, and if the proposal fails it will be six months before it can be voted on again. This is the one (and only) chance for a mainstream Usenet Plan 9 newsgroup in 1995. >From 9fans-outgoing-owner Tue Aug 1 21:37:14 1995 Received: by psuvax1.cse.psu.edu id <34120>; Tue, 1 Aug 1995 21:18:14 -0400 Received: from staff.cs.su.OZ.AU ([129.78.8.1]) by psuvax1.cse.psu.edu with SMTP id <34143>; Tue, 1 Aug 1995 20:42:01 -0400 Received: from plan9.cs.su.oz.au by staff.cs.su.OZ.AU (mail from boyd for 9fans@cse.psu.edu) with MHSnet (insertion MHSnet site: staff.cs.su.oz.au); Wed, 02 Aug 1995 09:46:22 +1000 Received: from lore.plan9.cs.su.oz.au. by staff.cs.su.OZ.AU.; Wed, 02 Aug 1995 09:46:20 +1000 From: Boyd Roberts Date: Tue, 1 Aug 1995 19:19:14 -0400 To: 9fans Subject: aux/vga Message-ID: <199508020919.5148.9.babig@plan9.cs.su.oz.au> Sender: owner-9fans Precedence: bulk Reply-To: 9fans I have a problem with aux/vga and my Quadtel S3 video board. The standard /lib/vgadb entry wasn't working so I looked at the board and saw it had a att20c40-80 chip in in so I changed the ramdac entry, and then reordered link=3clock ... so it was before the ramdac entry (don't ask me how I worked this out :-) and changed the clock field to be icd2061a. Then I run aux/vga -l and the weirdest thing happens: I get two half screens, side by side, which are identical; the mouse tracks in both and 8 1/2 runs fine. I think I'm close at this stage, but I'm at a loss to understand what's happening (the only thing I know about PC hardware is that diskette rhymes with whiskette). Any clues? The aux/vga and /lib/vgadb I have come from the pre-release that we have here. >From 9fans-outgoing-owner Tue Aug 1 22:29:36 1995 Received: by psuvax1.cse.psu.edu id <34114>; Tue, 1 Aug 1995 22:03:25 -0400 Received: from burdell.cc.gatech.edu ([130.207.3.207]) by psuvax1.cse.psu.edu with SMTP id <34046>; Tue, 1 Aug 1995 21:10:56 -0400 Received: from gvu1.cc.gatech.edu (ejl@gvu1.cc.gatech.edu [130.207.119.241]) by burdell.cc.gatech.edu (8.6.12/8.6.9) with ESMTP id UAA19636 for <9fans@cse.psu.edu>; Tue, 1 Aug 1995 20:37:42 -0400 Received: (from ejl@localhost) by gvu1.cc.gatech.edu (8.6.10/8.6.9) id UAA25356 for 9fans@cse.psu.edu; Tue, 1 Aug 1995 20:37:37 -0400 Date: Tue, 1 Aug 1995 20:37:37 -0400 From: ejl@cc.gatech.edu (E. J. Lee) Message-Id: <199508020037.UAA25356@gvu1.cc.gatech.edu> To: 9fans Subject: unsubscribe Sender: owner-9fans Precedence: bulk Reply-To: 9fans unsubscribe >From 9fans-outgoing-owner Wed Aug 2 01:38:05 1995 Received: by psuvax1.cse.psu.edu id <34078>; Wed, 2 Aug 1995 01:17:48 -0400 Received: from plan9.att.com ([192.20.225.252]) by psuvax1.cse.psu.edu with SMTP id <34087>; Wed, 2 Aug 1995 00:46:40 -0400 From: jmk@plan9.att.com To: 9fans Date: Tue, 1 Aug 1995 23:24:47 -0400 Subject: re: aux/vga Message-Id: <95Aug2.004640edt.34087@psuvax1.cse.psu.edu> Sender: owner-9fans Precedence: bulk Reply-To: 9fans the S3 chip (which one is it?) thinks it can do 2x8-bit pixels at a time at the higher resolutions, but it sounds like it's a standard 8-bit dac and it can't do that (the dac you gave looks like a typo), so you see the image twice. the highest clock you can use is 80MHz in this case. still, it shouldn't be allowed to happen, but the insides of aux/vga are a twisty mess. more information please. ------ original message follows ------ >From cse.psu.edu!9fans-outgoing-owner Tue Aug 1 21:44:20 EDT 1995 Received: by psuvax1.cse.psu.edu id <34120>; Tue, 1 Aug 1995 21:18:14 -0400 Received: from staff.cs.su.OZ.AU ([129.78.8.1]) by psuvax1.cse.psu.edu with SMTP id <34143>; Tue, 1 Aug 1995 20:42:01 -0400 Received: from plan9.cs.su.oz.au by staff.cs.su.OZ.AU (mail from boyd for 9fans@cse.psu.edu) with MHSnet (insertion MHSnet site: staff.cs.su.oz.au); Wed, 02 Aug 1995 09:46:22 +1000 Received: from lore.plan9.cs.su.oz.au. by staff.cs.su.OZ.AU.; Wed, 02 Aug 1995 09:46:20 +1000 From: Boyd Roberts Date: Tue, 1 Aug 1995 19:19:14 -0400 To: 9fans@cse.psu.edu Subject: aux/vga Message-ID: <199508020919.5148.9.babig@plan9.cs.su.oz.au> Sender: owner-9fans@cse.psu.edu Precedence: bulk Reply-To: 9fans@cse.psu.edu I have a problem with aux/vga and my Quadtel S3 video board. The standard /lib/vgadb entry wasn't working so I looked at the board and saw it had a att20c40-80 chip in in so I changed the ramdac entry, and then reordered link=3clock ... so it was before the ramdac entry (don't ask me how I worked this out :-) and changed the clock field to be icd2061a. Then I run aux/vga -l and the weirdest thing happens: I get two half screens, side by side, which are identical; the mouse tracks in both and 8 1/2 runs fine. I think I'm close at this stage, but I'm at a loss to understand what's happening (the only thing I know about PC hardware is that diskette rhymes with whiskette). Any clues? The aux/vga and /lib/vgadb I have come from the pre-release that we have here. >From 9fans-outgoing-owner Wed Aug 2 12:29:27 1995 Received: by psuvax1.cse.psu.edu id <34174>; Wed, 2 Aug 1995 11:57:03 -0400 Received: from alpha.xerox.com ([13.1.64.93]) by psuvax1.cse.psu.edu with SMTP id <34147>; Wed, 2 Aug 1995 11:54:24 -0400 Received: from reynaldo.parc.xerox.com ([13.2.116.96]) by alpha.xerox.com with SMTP id <15311(3)>; Wed, 2 Aug 1995 08:48:53 PDT Received: from localhost by reynaldo.parc.xerox.com with SMTP id <34950>; Wed, 2 Aug 1995 08:48:50 -0700 To: 9fans cc: kerch@parc.xerox.com Subject: Re: aux/vga In-reply-to: Your message of "Tue, 01 Aug 95 16:19:14 PDT." <199508020919.5148.9.babig@plan9.cs.su.oz.au> Date: Wed, 2 Aug 1995 11:48:48 -0400 From: Berry Kercheval Message-Id: <95Aug2.084850pdt.34950@reynaldo.parc.xerox.com> Sender: owner-9fans Precedence: bulk Reply-To: 9fans >>>Boyd Roberts said: > > Then I run aux/vga -l and the weirdest thing happens: I get two half > screens, side by side, which are identical; the mouse tracks in both > and 8 1/2 runs fine. I think I'm close at this stage, but I'm at a > loss to understand what's happening (the only thing I know about PC > hardware is that diskette rhymes with whiskette). Any clues? This sounds like a bug I had when I was doing a port of the X11R4 server to MS-DOS (for my sins, don't ask) about 4 years ago. Time has muddied the details, and my jerk boss would insist they were proprietary anyway (he's not my boss anymore, thank God) but I seem to remember that it had to do with the VGA board being in 4-bit deep mode (16 colors) when the program thought it was in 8-bit deep mode (256 colors) or maybe vice versa. I recently had a similar occurence on a Linux laptop, where Mosaic was too stupid to understand about Visuals other than 8-bit deep and 1-bit deep. Shit. What a mess. I can't wait for my plan9 CDROM to arrive.... --berry (P.S. I realize I probably haven't specifically helped Boyd, and have whined a lot, but I hope I have pointed him at the right place to look) Berry Kercheval :: Xerox Palo Alto Research Center >From 9fans-outgoing-owner Wed Aug 2 15:21:04 1995 Received: by psuvax1.cse.psu.edu id <34159>; Wed, 2 Aug 1995 14:42:58 -0400 Received: from plan9.att.com ([192.20.225.252]) by psuvax1.cse.psu.edu with SMTP id <34150>; Wed, 2 Aug 1995 14:42:10 -0400 From: presotto@plan9.att.com To: plan9-fans Date: Wed, 2 Aug 1995 14:37:43 -0400 subject: auth/wrkey Message-Id: <95Aug2.144210edt.34150@psuvax1.cse.psu.edu> Sender: owner-9fans Precedence: bulk Reply-To: 9fans wrkey was changing the wrong locations in the aparc nvram. fix in http://plan9.att.com/plan9/errata.html. >From 9fans-outgoing-owner Wed Aug 2 17:12:35 1995 Received: by psuvax1.cse.psu.edu id <34093>; Wed, 2 Aug 1995 16:50:45 -0400 Received: from igw.merck.com ([155.91.1.1]) by psuvax1.cse.psu.edu with SMTP id <34068>; Wed, 2 Aug 1995 16:50:00 -0400 Received: by igw.merck.com; Wed, 2 Aug 95 16:55:09 -0400 Message-Id: <9508022055.AA08307@igw.merck.com> From: anthony_starks@merck.com (Anthony Starks) Subject: Panel Library and Raster Graphics docs on the Web? To: 9fans Date: Wed, 2 Aug 1995 16:47:26 -0400 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 274 Sender: owner-9fans Precedence: bulk Reply-To: 9fans Two documents referenced on http://plan9.att.com/plan9/vol2.html: Raster Graphics in Plan 9 (http://plan9.att.com/plan9/doc/gfx.html) A Quick Introduction to the Panel Library (http://plan9.att.com/plan9/doc/panel.html) are still in their abstract form. -- Anthony >From 9fans-outgoing-owner Wed Aug 2 17:48:20 1995 Received: by psuvax1.cse.psu.edu id <34155>; Wed, 2 Aug 1995 17:33:21 -0400 Received: from plan9.att.com ([192.20.225.252]) by psuvax1.cse.psu.edu with SMTP id <34150>; Wed, 2 Aug 1995 17:32:25 -0400 From: presotto@plan9.att.com To: 9fans Date: Wed, 2 Aug 1995 17:31:07 -0400 Subject: re: Panel Library and Raster Graphics docs on the Web? Message-Id: <95Aug2.173225edt.34150@psuvax1.cse.psu.edu> Sender: owner-9fans Precedence: bulk Reply-To: 9fans That's due to their author also being in abstract form. I'll get to it tonight. >From 9fans-outgoing-owner Wed Aug 2 20:52:27 1995 Received: by psuvax1.cse.psu.edu id <34093>; Wed, 2 Aug 1995 20:39:40 -0400 Received: from staff.cs.su.OZ.AU ([129.78.8.1]) by psuvax1.cse.psu.edu with SMTP id <34083>; Wed, 2 Aug 1995 20:38:57 -0400 Received: from plan9.cs.su.oz.au by staff.cs.su.OZ.AU (mail from boyd for 9fans@cse.psu.edu) with MHSnet (insertion MHSnet site: staff.cs.su.oz.au); Thu, 03 Aug 1995 10:38:41 +1000 Received: from lore.plan9.cs.su.oz.au. by staff.cs.su.OZ.AU.; Thu, 03 Aug 1995 10:38:37 +1000 From: Boyd Roberts Date: Wed, 2 Aug 1995 20:21:40 -0400 To: 9fans Subject: re: aux/vga In-Reply-To: <95Aug2.004640edt.34087@psuvax1.cse.psu.edu> Message-ID: <199508031021.19755.9.babij@plan9.cs.su.oz.au> Sender: owner-9fans Precedence: bulk Reply-To: 9fans oops, a typo: I have an att20c490-80. I tried out another s3 pc and that just worked fine with the standard setup. It's this digital lpv+ 433sx I have that has the problem. A minor point: aux/vga's usage message includes an f option, which it doesn't support. >From 9fans-outgoing-owner Wed Aug 2 22:59:39 1995 Received: by psuvax1.cse.psu.edu id <34083>; Wed, 2 Aug 1995 22:32:52 -0400 Received: from idpentium.idsoftware.com ([192.246.40.9]) by psuvax1.cse.psu.edu with SMTP id <34080>; Wed, 2 Aug 1995 22:32:01 -0400 Received: from idnewt by idpentium.idsoftware.com (NX5.67e/NX3.0M) id AA13376; Wed, 2 Aug 95 21:29:56 -0500 Received: by idnewt.idsoftware.com (NX5.67e/NX3.0S) id AA25544; Wed, 2 Aug 95 21:30:31 -0500 Message-Id: <9508030230.AA25544@idnewt.idsoftware.com> Mime-Version: 1.0 (NeXT Mail 3.3risc v118.3) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Received: by NeXT.Mailer (1.118.3) From: John Carmack Date: Wed, 2 Aug 1995 22:30:29 -0400 To: 9fans Subject: Quake on plan 9 Sender: owner-9fans Precedence: bulk Reply-To: 9fans I am going to buy a system to run plan 9 on. Are there any = integrators in the audience that will provide a ready-to-run, high = performance pc system? I want to be able to make a standalone = plan 9 network with a pc and a couple old NEXTStations, as well as = mount some NFS volumes from our main file server. My first project will be to bring up Quake. If anyone has any = comments on troubles I am likely to run into, please let me know. = The game's requirements are: Good keyboard event handling. Up / down notifications for all = keys is ideal, but I can live with some keys being special. A rapid bitmap blitter. Mapping the framebuffer is ideal. A = single copy to screen from shared memory is usually fine. Pumping = a bitmap through a generic imaging function generally isn't. For = actually playing games, as opposed to developing them, an easy way = to change the display resolution, like xfree86, is great. Low level sound access. Mapping the recirculating dma buffers = with a call to get the current dma position is ideal. A blocking = write to a sound stream is fine if I can get tight control of the = buffering done in the driver. Does a sound driver even exist? It = sounds like a fun and straightforward project if not. Non blocking, non buffering TCP/IP. Any implementation that = handles the BSD sockopts should be fine. A way to get raw mickey counts from the mouse would be cool. Our = NEXTSTEP and X versions have to live without mouse input. John Carmack Id Software >From 9fans-outgoing-owner Wed Aug 2 23:49:09 1995 Received: by psuvax1.cse.psu.edu id <34159>; Wed, 2 Aug 1995 23:29:27 -0400 Received: from plan9.att.com ([192.20.225.252]) by psuvax1.cse.psu.edu with SMTP id <34172>; Wed, 2 Aug 1995 23:24:41 -0400 From: philw@plan9.att.com To: 9fans Date: Wed, 2 Aug 1995 23:04:52 -0400 Subject: re: Quake on plan 9 Message-Id: <95Aug2.232441edt.34172@psuvax1.cse.psu.edu> Sender: owner-9fans Precedence: bulk Reply-To: 9fans (including system test ...) >From 9fans-outgoing-owner Thu Aug 3 00:06:08 1995 Received: by psuvax1.cse.psu.edu id <34155>; Wed, 2 Aug 1995 23:45:41 -0400 Received: from plan9.att.com ([192.20.225.252]) by psuvax1.cse.psu.edu with SMTP id <34165>; Wed, 2 Aug 1995 23:24:34 -0400 From: philw@plan9.att.com To: 9fans Date: Wed, 2 Aug 1995 23:04:02 -0400 Subject: re: Quake on plan 9 Message-Id: <95Aug2.232434edt.34165@psuvax1.cse.psu.edu> Sender: owner-9fans Precedence: bulk Reply-To: 9fans Mapping the frame buffer using segattach is no problem. Event handling can be made as good as you need. We will give you whatever help you need. philw >From 9fans-outgoing-owner Thu Aug 3 01:02:33 1995 Received: by psuvax1.cse.psu.edu id <34120>; Thu, 3 Aug 1995 00:38:50 -0400 Received: from staff.cs.su.OZ.AU ([129.78.8.1]) by psuvax1.cse.psu.edu with SMTP id <34182>; Thu, 3 Aug 1995 00:36:15 -0400 Received: from staff.cs.su.oz.au by staff.cs.su.OZ.AU (mail from gary for 9fans@cse.psu.edu) with MHSnet; Thu, 03 Aug 1995 14:27:44 +1000 Received: from staff.cs.su.OZ.AU. by staff.cs.su.OZ.AU.; Thu, 03 Aug 1995 14:27:40 +1000 To: 9fans Subject: Re: Quake on plan 9 Date: Thu, 3 Aug 1995 00:27:40 -0400 From: Gary Capell Message-Id: <95Aug3.003615edt.34182@psuvax1.cse.psu.edu> Sender: owner-9fans Precedence: bulk Reply-To: 9fans No!!!! One of the features of Plan 9 for me is that there are currently no exciting games on it, and you're offering to help get Id software up and running. Next someone will port netrek and all will be lost :-( >From 9fans-outgoing-owner Thu Aug 3 01:50:08 1995 Received: by psuvax1.cse.psu.edu id <34187>; Thu, 3 Aug 1995 01:29:13 -0400 Received: from lore.plan9.cs.su.oz.au ([129.78.96.2]) by psuvax1.cse.psu.edu with SMTP id <34168>; Thu, 3 Aug 1995 01:11:12 -0400 From: boyd@plan9.cs.su.oz.au To: <9fans> Date: Thu, 3 Aug 1995 00:20:53 -0400 Message-Id: <95Aug3.011112edt.34168@psuvax1.cse.psu.edu> Sender: owner-9fans Precedence: bulk Reply-To: 9fans what's the etymology of bootes? >From 9fans-outgoing-owner Thu Aug 3 04:52:39 1995 Received: by psuvax1.cse.psu.edu id <34114>; Thu, 3 Aug 1995 04:18:54 -0400 Received: from staff.cs.su.OZ.AU ([129.78.8.1]) by psuvax1.cse.psu.edu with SMTP id <34080>; Thu, 3 Aug 1995 04:17:57 -0400 Received: from sour.sw.oz.au by staff.cs.su.OZ.AU (mail from jeremy for 9fans@cse.psu.edu) with MHSnet (insertion MHSnet site: swallow.sw.oz.au); Thu, 03 Aug 1995 18:17:30 +1000 Received: from sour.sw.oz.au by swallow.sw.oz.au with SMTP id AA29065; Thu, 3 Aug 95 18:17:14 EST (4.1/Unixware) (from jeremy@sour.sw.oz.au for 9fans@cse.psu.edu) Received: by sour.sw.oz.au id AA11165; Thu, 3 Aug 1995 18:17:11 +1000 (5.65c/1.34) (from jeremy@sour.sw.oz.au for 9fans@cse.psu.edu) From: jeremy@sour.sw.oz.au (Jeremy Fitzhardinge) Message-Id: <199508030817.AA11165@sour.sw.oz.au> Subject: Alef questions To: 9fans (Graverobbers from Outer Space!) Date: Thu, 3 Aug 1995 04:17:10 -0400 Organization: Softway Pty Ltd X-Face: '6U=%Tv\k1l-:?\$C[D@G 7(vl~w8&y}!f\bh#wL#n,TGKh>T.c7eT5-y)Hl'i;A1z$9?*lD.k}yqshddFb l[EC}c=;uc%x'}uh3E91p&oE? The ',' operator has gone, I suppose because it would be impossible to syntactically disambiguate from tuples. It's not a great loss in general (given that tuples are very useful), but it does make the for() statement less concise. For example, this is pretty common in C: for(i = j = 0; i < 10; i++, j += 4) /* ... */ Is there a new idiom for this kind of thing in ALEF? I've tried to use tuples, for(i = j = 0; i < 10; (i++, j += 4)) /* ... */ but the compiler warns "expression not used" (or something to that effect, I presume about the tuple), and when run the loop never terminates and i and j are always 0. Is this a compiler bug? Numbered break and continue. Why numbered? It seems somewhat delicate (in that it would be easy to introduce cut and paste errors), and inconsistent with goto. My feeling for this is that labelled loops and using labels would be better (goto is goto is goto...). Is the ability to break or continue multiple levels very useful, given that it can be done with goto more clearly? unallocing channels between procs If you have two processes communicating with a channel, and you want to free the channel but keep the procs running, does one end or both have to free it? The old (very old) ALEF ref man suggests that procs may be in separate address spaces, but a light reading of the new ref man says that they are in the same address space. I guess this means that only one proc needs to free it. Similarly, I assume that only one task should free a channel too. alt Is there a way of blocking for input on a set of channels not known at compile time (a library call analogous to poll() or select() I suppose)? Does alt allow for waiting for a channel of a set to become available for sending? Something like: alt { case c1 <-= foo: /* ... */ break; case c2 <-= bar: /* ... */ break; /* etc. */ } It would get around the inherent unreliability of the "can send" operator in many cases... [I haven't looked at alt with varient type channels enough to even formulate a proper question yet; is it some form of dynamic typing? ] initialising and other C differences Why has initialising all but static objects been dropped? I was quite surprised to find it missing, since it's so common in C, and there's no obvious reason for it not to be in ALEF. Is there a subtle reason? (I've also typed "c" "h" "a" "r" almost every time I meant "byte", but that's just me. "byte" is clearly the correct keyword, and will just take getting used to). types The table of basic types on page 4 of the reference gives their sizes in bits. Does this mean that all implementations of ALEF are expected to make the basic types exactly those sizes, or is it just documenting the existing plan9 implementations? In particular it says that channels are 32 bits, and then goes on to say that they're the same size as pointers. It seems likely that the Alpha port, for example, will want 64 bit pointers. On the other hand, having known 8, 16 and 32 bit sizes is very useful... Oh, and the ref says that the ++ and -- postfix operators can only operate on integral typed lvalues, but the prefix versions can take integral or pointer types. I assume this is just a oversight and both forms can take both pointer and integral types. Any particular reason they can't take a float type (not that f += 1.0 is onerous)? Also, the syntax for block statements in 7.3 doesn't allow blocks without declarations... (the yacc grammar does however). Thanks, J >From 9fans-outgoing-owner Thu Aug 3 05:28:32 1995 Received: by psuvax1.cse.psu.edu id <34199>; Thu, 3 Aug 1995 04:53:14 -0400 Received: from gateway.morgan.com ([138.20.30.3]) by psuvax1.cse.psu.edu with SMTP id <34163>; Thu, 3 Aug 1995 04:51:08 -0400 Received: from ls5.fid.morgan.com ([138.20.110.10]) by gateway.morgan.com with SMTP id <41683>; Thu, 3 Aug 1995 04:30:34 -0400 Received: from tasmania.Morgan.COM by ls5.fid.morgan.com (4.1/MS/FID/Sun-1.3) id AA14268; Thu, 3 Aug 95 09:30:26 BST From: "David Lukes" Message-Id: <9508030930.ZM10129@morgan.com> Date: Thu, 3 Aug 1995 04:30:25 -0400 In-Reply-To: boyd@plan9.cs.su.oz.au "" (Aug 3, 0:20) References: <95Aug3.011112edt.34168@psuvax1.cse.psu.edu> X-Face: ",23ZL}.AnSu!4o'e&Zi$|&rY^Py}G`e=fI&l{$n@td6#Kar.lKC9yYg$@'yxv|Pw37"-%Ax}(QJFS35S;vKtZ_JzuiK5LvmGz`S_MHpiqgR?dJ@QsE$Jn&RO-Rh|XpcAh?:x\{m%=Vad3j} Subject: What's the etymology of bootes? Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-9fans Precedence: bulk Reply-To: 9fans Bootes: a northern constellation containing the bright star Arcturus Dave. >From 9fans-outgoing-owner Thu Aug 3 09:19:57 1995 Received: by psuvax1.cse.psu.edu id <34080>; Thu, 3 Aug 1995 08:47:34 -0400 Received: from plan9.att.com ([192.20.225.252]) by psuvax1.cse.psu.edu with SMTP id <34076>; Thu, 3 Aug 1995 08:42:01 -0400 From: rob@plan9.att.com To: 9fans Date: Thu, 3 Aug 1995 00:38:16 -0400 Subject: Re: Quake on plan 9 Message-Id: <95Aug3.084201edt.34076@psuvax1.cse.psu.edu> Sender: owner-9fans Precedence: bulk Reply-To: 9fans You'll need to do some minor system hacking to give you up/down events on the keyboard. Plan 9 hides all that stuff for you as a service to most software, so on machines that have up/down events (the first few machines we ported to didn't) we generate UTF directly. It would be a few minutes' work to make another device file that gives you the up/down stuff in any form that's helpful. Similar comments apply to the mouse. With a little more work, this could even be made to work through the window system. The framebuffer is mappable already, although you may need to add a line to a table in the kernel and recompile before you can get to it. If you're on a VGA, you may also need a hook to get to the routine that copies from the internal buffer to the page-mapped display. This is easy, too, although getting it to cooperate with the window system is not. (It's very easy in Brazil, but that's another story.) There is a sound driver for the Sound-Blaster cards and Nextstations. I don't know it well enough to say if it does enough, but as you say it's a straightforward project if not. Again, unbuffered TCP/IP will take a little kernel work but not much. -rob >From 9fans-outgoing-owner Thu Aug 3 12:29:27 1995 Received: by psuvax1.cse.psu.edu id <34120>; Thu, 3 Aug 1995 12:00:03 -0400 Received: from plan9.att.com ([192.20.225.252]) by psuvax1.cse.psu.edu with SMTP id <34150>; Thu, 3 Aug 1995 11:59:39 -0400 From: philw@plan9.att.com To: 9fans Date: Thu, 3 Aug 1995 11:39:59 -0400 Subject: re: Alef questions Message-Id: <95Aug3.115939edt.34150@psuvax1.cse.psu.edu> Sender: owner-9fans Precedence: bulk Reply-To: 9fans >Is the name 'A' 'L' 'E' 'F' or under Unix>? ALEF is the name because we run on unix systems as well as plan 9. >effect, I presume about the tuple), and when run the loop never >terminates and i and j are always 0. Is this a compiler bug? comma is gone because it cant live with tuples. It might be considered a bug - I did know about it. Tuples are evaluated by generating the address of the lval and then evaluating each member directly into the destination. If there is no lval the expression is thrown away. >Why numbered? It seems somewhat delicate (in that it would be easy >to introduce cut and paste errors), and inconsistent with goto. >My feeling for this is that labelled loops and using labels would >be better (goto is goto is goto...). Is the ability to break or >continue multiple levels very useful, given that it can be done >with goto more clearly? If you cut random lines of program and paste them around the chances are your program will not work. I've heard this argument lots and just don't buy it. I find that I often want to break from combination for/switch: for(;;) { c = getc(); switch(c) { case EOF: break 2; This is worth having. You might argue I could have chosen a differnt keyword, a break from loops and a break from switch. break n seemed simpler. >If you have two processes communicating with a channel, and you >want to free the channel but keep the procs running, does one end >or both have to free it? The old (very old) ALEF ref man suggests >that procs may be in separate address spaces, but a light reading >of the new ref man says that they are in the same address space. >I guess this means that only one proc needs to free it. Similarly, >I assume that only one task should free a channel too. Channels are just data structures (In fact just fancy rendezvous) it was generated from a malloc and needs to be unalloc'd just once. If you try and free a channel DURING a communication the process performing the free will block until the communication is complete. This is implementation detail in the runtime and not defined by the language - maybe it should be. Channels and process are not really connected as resources. The channel is just a data structure processes might use. The process who created is no more connected to it than any other. >Is there a way of blocking for input on a set of channels not known >at compile time (a library call analogous to poll() or select() I >suppose)? Does alt allow for waiting for a channel of a set to >become available for sending? Something like: You need to build a multiplexor using co-routines. >[I haven't looked at alt with varient type channels enough to even > formulate a proper question yet; is it some form of dynamic typing? ] Yes, this release of the compiler has lots of dynamic typing. >Why has initialising all but static objects been dropped? I was >quite surprised to find it missing, since it's so common in C, >and there's no obvious reason for it not to be in ALEF. Is there >a subtle reason? no subtle reason. I find code written that way hard to read. I am so anal I sort the lengths of all automatics into a ski run, go figure. >The table of basic types on page 4 of the reference gives their >sizes in bits. Does this mean that all implementations of ALEF >are expected to make the basic types exactly those sizes, or is it >just documenting the existing plan9 implementations? In particular >it says that channels are 32 bits, and then goes on to say that >they're the same size as pointers. It seems likely that the Alpha >port, for example, will want 64 bit pointers. They are supposed to be minimum sizes. >Oh, and the ref says that the ++ and -- postfix operators can only >operate on integral typed lvalues, but the prefix versions can take >integral or pointer types. I assume this is just a oversight and >both forms can take both pointer and integral types. Any particular >reason they can't take a float type (not that f += 1.0 is onerous)? Thats a mistake in the manual. the float pre/post inc seemed of limited use. >Also, the syntax for block statements in 7.3 doesn't allow blocks >without declarations... (the yacc grammar does however). Another mistake. philw >From 9fans-outgoing-owner Thu Aug 3 16:41:48 1995 Received: by psuvax1.cse.psu.edu id <34078>; Thu, 3 Aug 1995 16:17:14 -0400 Received: from galapagos.cse.psu.edu ([130.203.2.12]) by psuvax1.cse.psu.edu with SMTP id <34080>; Thu, 3 Aug 1995 16:16:29 -0400 Received: from localhost by galapagos.cse.psu.edu with SMTP id <12712>; Thu, 3 Aug 1995 16:15:08 -0400 To: 9fans Subject: Re: Quake on plan 9 In-reply-to: Your message of "Thu, 03 Aug 1995 00:38:16 EDT." <95Aug3.084201edt.34076@psuvax1.cse.psu.edu> Date: Thu, 3 Aug 1995 16:14:53 -0400 From: Scott Schwartz Message-Id: <95Aug3.161508edt.12712@galapagos.cse.psu.edu> Sender: owner-9fans Precedence: bulk Reply-To: 9fans Rob says: | It's very easy in Brazil, but that's another story. Tell it, tell it! When can we start thinking about a brazil-fans mailing list? >From 9fans-outgoing-owner Thu Aug 3 18:12:17 1995 Received: by psuvax1.cse.psu.edu id <34067>; Thu, 3 Aug 1995 17:50:16 -0400 Received: from plan9.att.com ([192.20.225.252]) by psuvax1.cse.psu.edu with SMTP id <34080>; Thu, 3 Aug 1995 17:49:38 -0400 From: rob@plan9.att.com To: 9fans Date: Thu, 3 Aug 1995 17:42:19 -0400 Subject: Re: Quake on plan 9 Message-Id: <95Aug3.174938edt.34080@psuvax1.cse.psu.edu> Sender: owner-9fans Precedence: bulk Reply-To: 9fans > When can we start thinking about a brazil-fans mailing list? Let's get Quake out first. -rob >From 9fans-outgoing-owner Thu Aug 3 19:18:46 1995 Received: by psuvax1.cse.psu.edu id <34078>; Thu, 3 Aug 1995 18:26:36 -0400 Received: from goonsquad.spies.com ([192.216.22.66]) by psuvax1.cse.psu.edu with SMTP id <34080>; Thu, 3 Aug 1995 18:25:52 -0400 Received: by goonsquad.spies.com (Smail3.1.29.1 #2) id m0se8gA-00024LC; Thu, 3 Aug 95 15:23 PDT Message-Id: From: ahm@goonsquad.spies.com (Andreas Meyer) Subject: Serial port i/o, how? To: 9fans (9fans) Date: Thu, 3 Aug 1995 18:23:49 -0400 Organization: The Internet Wiretap Content-Type: text Content-Length: 133 Sender: owner-9fans Precedence: bulk Reply-To: 9fans This might be a rudimentary question, but how do I access a serial port? (for example, to use a window as a terminal) Thanks, Andy >From 9fans-outgoing-owner Thu Aug 3 20:28:22 1995 Received: by psuvax1.cse.psu.edu id <34080>; Thu, 3 Aug 1995 20:10:39 -0400 Received: from plan9.att.com ([192.20.225.252]) by psuvax1.cse.psu.edu with SMTP id <34067>; Thu, 3 Aug 1995 20:09:51 -0400 From: philw@plan9.att.com To: 9fans Date: Thu, 3 Aug 1995 20:07:41 -0400 Subject: re: Serial port i/o, how? Message-Id: <95Aug3.200951edt.34067@psuvax1.cse.psu.edu> Sender: owner-9fans Precedence: bulk Reply-To: 9fans >This might be a rudimentary question, but >how do I access a serial port? >(for example, to use a window as a terminal) con -r /dev/eia0 >From 9fans-outgoing-owner Fri Aug 4 02:58:52 1995 Received: by psuvax1.cse.psu.edu id <34157>; Fri, 4 Aug 1995 02:36:26 -0400 Received: from staff.cs.su.OZ.AU ([129.78.8.1]) by psuvax1.cse.psu.edu with SMTP id <34156>; Fri, 4 Aug 1995 02:35:37 -0400 Received: from sour.sw.oz.au by staff.cs.su.OZ.AU (mail from jeremy for 9fans@cse.psu.edu) with MHSnet (insertion MHSnet site: swallow.sw.oz.au); Fri, 04 Aug 1995 16:35:15 +1000 Received: from sour.sw.oz.au by swallow.sw.oz.au with SMTP id AA14459; Fri, 4 Aug 95 16:34:52 EST (4.1/Unixware) (from jeremy@sour.sw.oz.au for 9fans@cse.psu.edu) Received: by sour.sw.oz.au id AA02277; Fri, 4 Aug 1995 16:34:48 +1000 (5.65c/1.34) (from jeremy@sour.sw.oz.au for 9fans@cse.psu.edu) From: jeremy@sour.sw.oz.au (Jeremy Fitzhardinge) Message-Id: <199508040634.AA02277@sour.sw.oz.au> Subject: Re: Alef questions To: 9fans Date: Fri, 4 Aug 1995 02:34:48 -0400 In-Reply-To: <95Aug3.115939edt.34150@psuvax1.cse.psu.edu> from "philw@plan9.att.com" at Aug 3, 95 11:39:59 am Organization: Softway Pty Ltd X-Face: '6U=%Tv\k1l-:?\$C[D@G 7(vl~w8&y}!f\bh#wL#n,TGKh>T.c7eT5-y)Hl'i;A1z$9?*lD.k}yqshddFb l[EC}c=;uc%x'}uh3E91p&oE Tuples are > evaluated by generating the address of the lval and then evaluating > each member directly into the destination. If there is no lval the > expression is thrown away. If it's not a bug, it's very surprising. Even if you throw away a value, you expect the side-effects to happen. I was kind of expecting it to work, since it would effectively recover the comma operator: you get the general form where you can use or throw away any of the expressions. J >From 9fans-outgoing-owner Fri Aug 4 03:22:14 1995 Received: by psuvax1.cse.psu.edu id <34156>; Fri, 4 Aug 1995 02:59:38 -0400 Received: from plan9.att.com ([192.20.225.252]) by psuvax1.cse.psu.edu with SMTP id <34167>; Fri, 4 Aug 1995 02:57:47 -0400 From: presotto@plan9.att.com To: 9fans Date: Fri, 4 Aug 1995 02:44:04 -0400 Subject: models Message-Id: <95Aug4.025747edt.34167@psuvax1.cse.psu.edu> Sender: owner-9fans Precedence: bulk Reply-To: 9fans I'm trying to make a list of PC models that Plan 9 works on. Could you mail me the flavor PC you are using, i.e., box or motherboard manufacturer and model number? Thanks much. >From 9fans-outgoing-owner Fri Aug 4 06:08:22 1995 Received: by psuvax1.cse.psu.edu id <34157>; Fri, 4 Aug 1995 05:36:08 -0400 Received: from mail.Chemietechnik.Uni-Dortmund.DE ([129.217.128.111]) by psuvax1.cse.psu.edu with SMTP id <34178>; Fri, 4 Aug 1995 05:30:38 -0400 Received: from plato.Chemietechnik.Uni-Dortmund.DE by mail.Chemietechnik.Uni-Dortmund.DE id AA02673; Fri, 4 Aug 95 11:21:20 +0200 From: Heiko Wengler Message-Id: <9508040921.AA05964@plato.Chemietechnik.Uni-Dortmund.DE> Subject: Re: Quake on plan 9 To: 9fans Date: Fri, 4 Aug 1995 05:21:18 -0400 In-Reply-To: <95Aug3.003615edt.34182@psuvax1.cse.psu.edu> from "Gary Capell" at Aug 3, 95 00:27:40 am X-Mailer: ELM [version 2.4 PL13] Content-Type: text Content-Length: 312 Sender: owner-9fans Precedence: bulk Reply-To: 9fans >Next someone will port netrek and all will be lost :-( Funny that you mention Netrek. The only (:-)) reason why i was waiting for the Plan 9 PC dist was to port Netrek to it and can play from every PC after that. (Windows (gulp :)) X11 server are so slooooooooow :-) Heiko Wengler Sometimes client hacker... >From 9fans-outgoing-owner Fri Aug 4 06:42:58 1995 Received: by psuvax1.cse.psu.edu id <34179>; Fri, 4 Aug 1995 06:15:57 -0400 Received: from taurus.math.tau.ac.il ([132.67.64.4]) by psuvax1.cse.psu.edu with SMTP id <34167>; Fri, 4 Aug 1995 06:08:36 -0400 Received: from leo.math.tau.ac.il (laden@leo.math.tau.ac.il [132.67.128.6]) by taurus.math.tau.ac.il (8.6.10/math) with ESMTP id MAA18898 for ; Fri, 4 Aug 1995 12:44:55 +0300 From: Guy Laden Received: (laden@localhost) by leo.math.tau.ac.il (8.6.9/8.6.9) id MAA12036 for plan9-fans@cse.psu.edu; Fri, 4 Aug 1995 12:44:53 +0300 Message-Id: <199508040944.MAA12036@leo.math.tau.ac.il> Subject: vga card question To: plan9-fans Date: Fri, 4 Aug 1995 05:44:53 -0400 X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 475 Sender: owner-9fans Precedence: bulk Reply-To: 9fans Has anyone had any luck runnign the new pc binary distribution on a mach32 PCI card? I'm am unable to use anything but 640x480x1, when specifying ctlr=mach32. The card bios reads: ATI68800AX PCI 32K BIOS And further down in the rom: ATI VGAWONDER+B I added one of those to the 'mach32' vgadb entry, but i can't go to any higher resolutions. >From looking at the card it seems the DAC is a bt481. I have no idea what clock generator it has. Any ideas anyone? thanks, guy. >From 9fans-outgoing-owner Fri Aug 4 09:30:32 1995 Received: by psuvax1.cse.psu.edu id <34175>; Fri, 4 Aug 1995 09:04:08 -0400 Received: from symbol.com ([204.241.44.10]) by psuvax1.cse.psu.edu with SMTP id <34188>; Fri, 4 Aug 1995 08:53:50 -0400 Received: from proxy.symbol.com (proxy.symbol.com [157.235.5.10]) by symbol.com (8.6.12/8.6.10) with ESMTP id IAA13609 for <9fans@cse.psu.edu>; Fri, 4 Aug 1995 08:41:40 -0400 Received: from sys2.symbol.COM (nysmtp.symbol.com [157.235.16.12]) by proxy.symbol.com (8.6.12/8.6.10) with SMTP id IAA14697 for <9fans@cse.psu.edu>; Fri, 4 Aug 1995 08:42:05 -0400 Received: from sftpc3 (dgtlpc20) by sys2.symbol.COM (4.1/SMI-4.1) id AA08916; Fri, 4 Aug 95 08:41:35 EDT From: "Paul Poloniewicz" Message-Id: <9508040839.ZM170@sftpc3> Date: Fri, 4 Aug 1995 08:39:44 -0400 In-Reply-To: presotto@plan9.att.com "models" (Aug 4, 2:44am) References: <95Aug4.025747edt.34167@psuvax1.cse.psu.edu> X-Mailer: ZM-Win (3.2.1 11Sep94) To: 9fans Subject: Re: models Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-9fans Precedence: bulk Reply-To: 9fans Hi. Dell 433TE (486-33). At least the pre-release version runs. -prp -- >>>>>>>>>>>>>>>>>>>>>>>>>> Paul Poloniewicz Symbol Technologies, Inc. prp@symbol.com >>>>>>>>>>>>>>>>>>>>>>>>>> >From 9fans-outgoing-owner Fri Aug 4 12:52:18 1995 Received: by psuvax1.cse.psu.edu id <34213>; Fri, 4 Aug 1995 12:20:55 -0400 Received: from plan9.att.com ([192.20.225.252]) by psuvax1.cse.psu.edu with SMTP id <34197>; Fri, 4 Aug 1995 12:00:59 -0400 From: philw@plan9.att.com To: 9fans Date: Fri, 4 Aug 1995 11:25:33 -0400 Subject: Re: Alef questions Message-Id: <95Aug4.120059edt.34197@psuvax1.cse.psu.edu> Sender: owner-9fans Precedence: bulk Reply-To: 9fans >If it's not a bug, it's very surprising. Even if you throw away >a value, you expect the side-effects to happen. I was kind of You might, I don't. I think the comma operator was a mistake in C, making it possible to duplicate its effect in ALEF was not appealing. You are not the first person to suggest this. >From 9fans-outgoing-owner Fri Aug 4 14:07:39 1995 Received: by psuvax1.cse.psu.edu id <34187>; Fri, 4 Aug 1995 13:44:36 -0400 Received: from goonsquad.spies.com ([192.216.22.66]) by psuvax1.cse.psu.edu with SMTP id <34191>; Fri, 4 Aug 1995 13:39:02 -0400 Received: by goonsquad.spies.com (Smail3.1.29.1 #2) id m0seQWr-00024FC; Fri, 4 Aug 95 10:27 PDT Message-Id: From: ahm@goonsquad.spies.com (Andreas Meyer) Subject: No physical memory? To: 9fans (9fans) Date: Fri, 4 Aug 1995 13:27:24 -0400 Organization: The Internet Wiretap Content-Type: text Content-Length: 471 Sender: owner-9fans Precedence: bulk Reply-To: 9fans I was trying to install the pcdist onto my clone 386DX40 (128k cache, 4MB RAM, WD Caviar IDE hard drive). Everything looked fine until I got into installing the last three floppies, and then I get a message "No physical memory". I haven't seen any refs to this message anywhere. Can someone tell me what it means, and how to correct for it? Thanks, Andy -- Andreas Meyer, N2FYE Sustain. Endure. Evolve. ahm@goonsquad.spies.com http://www.spies.com/~ahm/ >From 9fans-outgoing-owner Fri Aug 4 15:59:53 1995 Received: by psuvax1.cse.psu.edu id <34173>; Fri, 4 Aug 1995 15:36:26 -0400 Received: from blah.math.tu-graz.ac.at ([129.27.150.3]) by psuvax1.cse.psu.edu with SMTP id <34094>; Fri, 4 Aug 1995 15:31:13 -0400 Received: from blah.math.tu-graz.ac.at (bri@localhost [127.0.0.1]) by blah.math.tu-graz.ac.at (8.6.12/8.6.12) with ESMTP id VAA02739 for <9fans@cse.psu.edu>; Fri, 4 Aug 1995 21:12:56 +0200 Message-Id: <199508041912.VAA02739@blah.math.tu-graz.ac.at> To: 9fans Subject: Re: No physical memory? In-reply-to: ahm's message of Fri, 04 Aug 1995 13:27:24 -0400. X-Face: 29;Iyv)JH{G=UziUMA{%xq2B_n$'$=u]9ADO2|aim*9Cc\RvEwI}Bje_})-96'bV`yJ{ya. G.I&s"~y?9\f?rEx;CF^)0b=xr~gdY1Z_('&;}{hMqGu!Fcy"A)M3|z!q3P-__AH;bgt]xEW)Pa:H= G)DU;<.a^+Q'Zyz=W]h/=b{=?sxK,EE\[cCa^ga\ZPm=[VhJF}=om+qLijs:ts&E Date: Fri, 4 Aug 1995 15:12:56 -0400 From: Brian Ward Sender: owner-9fans Precedence: bulk Reply-To: 9fans |I was trying to install the pcdist onto my clone 386DX40 |(128k cache, 4MB RAM, WD Caviar IDE hard drive). | ^^^^^^^ |Everything looked fine until I got into installing the last |three floppies, and then I get a message "No physical memory". I think I read somewhere that the minimum for plan 9 on a pc is 8 megs. So it just looks like you're out of memory. Buy some more, or better yet, see if anyone will give you some or at least buy it used. There are so many 30 pin 1 meg SIMMs without a home out there; hopefully you've got SIMMs. >From 9fans-outgoing-owner Fri Aug 4 16:26:39 1995 Received: by psuvax1.cse.psu.edu id <34120>; Fri, 4 Aug 1995 15:58:41 -0400 Received: from plan9.att.com ([192.20.225.252]) by psuvax1.cse.psu.edu with SMTP id <34209>; Fri, 4 Aug 1995 15:32:26 -0400 From: rob@plan9.att.com To: 9fans Date: Fri, 4 Aug 1995 15:19:14 -0400 Subject: Re: No physical memory? Message-Id: <95Aug4.153226edt.34209@psuvax1.cse.psu.edu> Sender: owner-9fans Precedence: bulk Reply-To: 9fans As is clearly said early in the installation document, Plan 9 needs eight megabytes of RAM on a PC. What the message means is that you don't have enough memory in your machine. I leave it to you to find a way to correct the problem. >From 9fans-outgoing-owner Fri Aug 4 16:37:08 1995 Received: by psuvax1.cse.psu.edu id <34152>; Fri, 4 Aug 1995 16:22:37 -0400 Received: from goonsquad.spies.com ([192.216.22.66]) by psuvax1.cse.psu.edu with SMTP id <34203>; Fri, 4 Aug 1995 15:32:45 -0400 Received: by goonsquad.spies.com (Smail3.1.29.1 #2) id m0seSKc-00024CC; Fri, 4 Aug 95 12:22 PDT Message-Id: From: ahm@goonsquad.spies.com (Andreas Meyer) Subject: Re: Serial port i/o, how? To: 9fans Date: Fri, 4 Aug 1995 15:22:52 -0400 In-Reply-To: <95Aug3.200951edt.34067@psuvax1.cse.psu.edu> from "philw@plan9.att.com" at Aug 3, 95 08:07:41 pm Organization: The Internet Wiretap Content-Type: text Content-Length: 338 Sender: owner-9fans Precedence: bulk Reply-To: 9fans philw@plan9.att.com writes: > >how do I access a serial port? > con -r /dev/eia0 When I do this, it just hangs. I'm using a hardware setup (null modem cable to another machine) which works in DOS. In another window, 'cat /dev/eia0ctl' returns: cts dsr ring dcd dtr rts Is there anything else I need to send to the control port? Andy >From 9fans-outgoing-owner Fri Aug 4 21:14:42 1995 Received: by colossus.cse.psu.edu id <46598>; Fri, 4 Aug 1995 20:55:59 -0400 Received: from interlock.wdni.com ([199.221.59.2]) by colossus.cse.psu.edu with SMTP id <46600>; Fri, 4 Aug 1995 20:55:40 -0400 Received: by interlock.wdni.com id AA25211 (InterLock SMTP Gateway 3.0 for 9fans@cse.psu.edu); Fri, 4 Aug 1995 17:55:33 -0700 Message-Id: <199508050055.AA25211@interlock.wdni.com> Received: by interlock.wdni.com (Protected-side Proxy Mail Agent-1); Fri, 4 Aug 1995 17:55:33 -0700 Date: Fri, 4 Aug 1995 20:55:47 -0400 From: Steven Plite To: 9fans Subject: Re: models Mime-Version: 1.0 Content-Type: text/plain; charset=X-roman8 Content-Transfer-Encoding: quoted-printable Sender: owner-9fans Precedence: bulk Reply-To: 9fans > I'm trying to make a list of PC models that Plan 9 works on. > Could you mail me the flavor PC you are using, i.e., box > or motherboard manufacturer and model number? Thanks much. I'm using the 4-floppy system on a Dell Omniplex 560/L (60MHz Pentium (ov= er- clocked to 66MHz :), PCI, 32MB, Connor 540MB EIDE, Cirrus Logic 5430) wit= h a 3com 3c509. Seems to work fine after tweaking /lib/vgadb, although I hav= en't used it much yet. I only wish it supported my AHA-2940. :( _________________________________________________________________________= ______ Steven Plite Open Systems Eng. & Support, Weyerh= aeuser "This is the roller coaster of endless and violent vomit." -- Jason F= ox >From 9fans-outgoing-owner Fri Aug 4 22:36:41 1995 Received: by colossus.cse.psu.edu id <46604>; Fri, 4 Aug 1995 22:24:36 -0400 Received: from goonsquad.spies.com ([192.216.22.66]) by colossus.cse.psu.edu with SMTP id <46603>; Fri, 4 Aug 1995 22:24:20 -0400 Received: by goonsquad.spies.com (Smail3.1.29.1 #2) id m0seYsd-00024DC; Fri, 4 Aug 95 19:22 PDT Message-Id: From: ahm@goonsquad.spies.com (Andreas Meyer) Subject: Re: No physical memory? To: 9fans Date: Fri, 4 Aug 1995 22:22:26 -0400 In-Reply-To: <95Aug4.153226edt.34209@psuvax1.cse.psu.edu> from "rob@plan9.att.com" at Aug 4, 95 03:19:14 pm Organization: The Internet Wiretap Content-Type: text Content-Length: 190 Sender: owner-9fans Precedence: bulk Reply-To: 9fans rob@plan9.att.com writes: > As is clearly said early in the installation document, Plan 9 needs > eight megabytes of RAM on a PC. Oops. I must have glossed over that somehow... Thanks. >From 9fans-outgoing-owner Sat Aug 5 00:43:59 1995 Received: by colossus.cse.psu.edu id <46609>; Sat, 5 Aug 1995 00:31:39 -0400 Received: from plan9.att.com ([192.20.225.252]) by colossus.cse.psu.edu with SMTP id <46608>; Sat, 5 Aug 1995 00:31:23 -0400 From: jmk@plan9.att.com To: 9fans Date: Sat, 5 Aug 1995 00:23:16 -0400 Subject: Re: models Message-Id: <95Aug5.003123edt.46608@colossus.cse.psu.edu> Sender: owner-9fans Precedence: bulk Reply-To: 9fans I only wish it supported my AHA-2940. :( if adaptec has supplied the manuals when i asked there would be a driver. >From 9fans-outgoing-owner Sat Aug 5 01:09:38 1995 Received: by colossus.cse.psu.edu id <46615>; Sat, 5 Aug 1995 00:57:05 -0400 Received: from interlock.wdni.com ([199.221.59.2]) by colossus.cse.psu.edu with SMTP id <46611>; Sat, 5 Aug 1995 00:52:41 -0400 Received: by interlock.wdni.com id AA26993 (InterLock SMTP Gateway 3.0 for 9fans@cse.psu.edu); Fri, 4 Aug 1995 21:46:03 -0700 Message-Id: <199508050446.AA26993@interlock.wdni.com> Received: by interlock.wdni.com (Protected-side Proxy Mail Agent-1); Fri, 4 Aug 1995 21:46:03 -0700 Date: Sat, 5 Aug 1995 00:46:19 -0400 From: Steven Plite To: 9fans Subject: 387 required? Mime-Version: 1.0 Content-Type: text/plain; charset=X-roman8 Content-Transfer-Encoding: quoted-printable Sender: owner-9fans Precedence: bulk Reply-To: 9fans Is a 387 required to run the 4-floppy dist on a 386? The hardware requir= ements in the install docs don't say so, but the section on the 386 compiler in "The Various Ports" says "...the compiler assumes i387-compatible hardwar= e...". _________________________________________________________________________= ______ Steven Plite Open Systems Eng. & Support, Weyerh= aeuser "This is the roller coaster of endless and violent vomit." -- Jason F= ox >From 9fans-outgoing-owner Sat Aug 5 02:09:42 1995 Received: by colossus.cse.psu.edu id <46612>; Sat, 5 Aug 1995 01:56:15 -0400 Received: from chamber.cco.caltech.edu ([131.215.48.55]) by colossus.cse.psu.edu with SMTP id <46608>; Sat, 5 Aug 1995 01:47:51 -0400 Received: from gap.cco.caltech.edu by chamber.cco.caltech.edu with ESMTP (8.6.12/DEI:4.41) id WAA06556; Fri, 4 Aug 1995 22:36:21 -0700 Received: by gap.cco.caltech.edu (8.6.7/DEI:4.41) id WAA26258; Fri, 4 Aug 1995 22:36:19 -0700 To: mlist-plan9-fans@nntp-server.caltech.edu Path: egnor From: egnor@pride.ugcs.caltech.edu (Daniel Egnor) Newsgroups: mlist.plan9-fans Subject: Re: 387 required? *and* Memory errors? Mothra sucks? Date: Sat, 5 Aug 1995 01:36:19 -0400 Organization: California Institute of Technology, Pasadena, CA Lines: 47 Message-ID: <3vv00j$pkg@gap.cco.caltech.edu> References: <199508050446.AA26993@interlock.wdni.com> NNTP-Posting-Host: pride.ugcs.caltech.edu Sender: owner-9fans Precedence: bulk Reply-To: 9fans In article <199508050446.AA26993@interlock.wdni.com>, Steven Plite <9fans@cse.psu.edu> wrote: >Is a 387 required to run the 4-floppy dist on a 386? The hardware >requirements in the install docs don't say so, but the section on the 386 >compiler in "The Various Ports" says "...the compiler assumes i387-compatible >hardware...". I have successfully installed and booted Plan 9 on a 386 sans 387. It seems to work, except that floating-point operations fail with bogus results -- the only immediate result of this is that the 8 1/2 clock gizmo does not draw the hands correctly (or at all), since doing so requires trig. :) I assume other things break, too. This same installation crashes after being alive for more than a minute or two. I believe this is due to a faulty memory configuration (gah) but have not verified -- it *could* be due to lack of a coprocessor, but I rather doubt it. Additional topics: It appears (on a more stable system!) that Plan 9 deals very poorly with memory errors. For example, a simple recursive rc function, which a beginner can easily make accidentally, for example: fn ls { lc -F } (If you're clever you'll figure out why this loops -- it took me a while, since I wasn't used to the system) will very quickly cause an 8MB machine to scroll "No physical memory" messages all over the screen. Unless one is very quick to kill the offending shell (which is difficult with messages coursing all over one's screen!) the system crashes. This is poor. Have I misconfigured somehow? Perhaps I should add some swap space or something? Along similar lines, when Plan 9 boots, it prints a message about the amount of memory available, and invariably (even when booting from floppy!) prints some _large_ amount of swap available (like 50MB). Why does it do this? OK, an unrelated gripe: Why is Mothra just an ordinary old Web browser, except with a lame interface (and a lot of bugs)? Given Plan 9, I'd think you'd have something like a urlfs, which would be terribly handy, and an HTML browser on top of that... am I missing something? (Don't get me wrong, I love a lot of the concepts in Plan 9, I'm just wondering about some of the smaller issues. I do not yet have the CD, BTW.) Dan >From 9fans-outgoing-owner Sat Aug 5 02:50:17 1995 Received: by colossus.cse.psu.edu id <46611>; Sat, 5 Aug 1995 02:40:49 -0400 Received: from plan9.att.com ([192.20.225.252]) by colossus.cse.psu.edu with SMTP id <46619>; Sat, 5 Aug 1995 02:40:30 -0400 From: rob@plan9.att.com To: 9fans Date: Sat, 5 Aug 1995 02:33:38 -0400 Subject: Re: 387 required? *and* Memory errors? Mothra sucks? Message-Id: <95Aug5.024030edt.46619@colossus.cse.psu.edu> Sender: owner-9fans Precedence: bulk Reply-To: 9fans The system will run fine without a 387 until you need a floating point instruction to be executed. The kernel and most utilities do not use floating point. The "no physical memory" messages can be removed by turning on swapping. Choose a swap partition and point swap at it; see swap(8). It is not enabled by default because the system cannot safely identify a partition to use; you must set one up. The announcement about how much swap space reflects the size of an internal data structure. A `urlfs' would be folly, because URLs are not a real name space and the semantics are utterly unmanageable. The argument is analogous to that which prevented us from putting network names in the file name space. As for mothra, the interface may be lame but I wonder why you think that, given that you have not got the CD and therefore probably haven't seen it. Response from outsiders who have seen it is that its interface is an improvement. Its bugs, as said in the manual, are because it is a very new program. New releases will likely appear on the net. I disagree with your assessment of the program - it's a perfectly fine interface to a perfectly awful network. It's not a marvel, but it does its job. -rob >From 9fans-outgoing-owner Sat Aug 5 02:58:51 1995 Received: by colossus.cse.psu.edu id <46619>; Sat, 5 Aug 1995 02:49:35 -0400 Received: from interlock.wdni.com ([199.221.59.2]) by colossus.cse.psu.edu with SMTP id <46610>; Sat, 5 Aug 1995 02:40:31 -0400 Received: by interlock.wdni.com id AA27622 (InterLock SMTP Gateway 3.0 for 9fans@cse.psu.edu); Fri, 4 Aug 1995 23:38:21 -0700 Message-Id: <199508050638.AA27622@interlock.wdni.com> Received: by interlock.wdni.com (Protected-side Proxy Mail Agent-1); Fri, 4 Aug 1995 23:38:21 -0700 Date: Sat, 5 Aug 1995 02:38:40 -0400 From: Steven Plite To: 9fans Subject: Re: models Mime-Version: 1.0 Content-Type: text/plain; charset=X-roman8 Content-Transfer-Encoding: quoted-printable Sender: owner-9fans Precedence: bulk Reply-To: 9fans >> I only wish it supported my AHA-2940. :( > if adaptec has supplied the manuals when i asked there would be a drive= r. You should have told them that Plan 9 was a multimedia system for Windows= , or something. 0.5*:-) _________________________________________________________________________= ______ Steven Plite Open Systems Eng. & Support, Weyerh= aeuser "This is the roller coaster of endless and violent vomit." -- Jason F= ox >From 9fans-outgoing-owner Sat Aug 5 04:00:05 1995 Received: by colossus.cse.psu.edu id <46633>; Sat, 5 Aug 1995 03:49:10 -0400 Received: from interlock.wdni.com ([199.221.59.2]) by colossus.cse.psu.edu with SMTP id <46632>; Sat, 5 Aug 1995 03:48:54 -0400 Received: by interlock.wdni.com id AA28098 (InterLock SMTP Gateway 3.0 for 9fans@cse.psu.edu); Sat, 5 Aug 1995 00:48:48 -0700 Message-Id: <199508050748.AA28098@interlock.wdni.com> Received: by interlock.wdni.com (Protected-side Proxy Mail Agent-1); Sat, 5 Aug 1995 00:48:48 -0700 Date: Sat, 5 Aug 1995 03:49:10 -0400 From: Steven Plite To: 9fans Subject: Re: 387 required? *and* Memory errors? Mothra sucks? Mime-Version: 1.0 Content-Type: text/plain; charset=X-roman8 Content-Transfer-Encoding: quoted-printable Sender: owner-9fans Precedence: bulk Reply-To: 9fans > The system will run fine without a 387 until you need a floating point > instruction to be executed. The kernel and most utilities do not use > floating point. Good, then maybe I still have a shot at getting this working. I have the= 4-floppy distribution installed (after swapping my floppy controller), an= d configured for 640x480x1. The kernel loads okay, but the system hangs at the "init: starting /bin/r= c" message. After it prints that message, it waits a few seconds, then some= multicolored horizontal bars flash once on the screen (still in text mode= ), then the display stays at the "starting /bin/rc" screen until I whap the = reset button. I assumed the screen flash was the attempt to change to VGA graphics mode= , so I swapped in an old Oak VGA card. No flash, but it hung in the same plac= e anyway. I've fiddled with the BIOS settings, turned shadowing and caching on and = off, etc, etc. I even swapped mice. Always get the above result. Here's my setup: no-name ISA motherboard with AMD 386DX/40, UMC 491F chipset, and AMI BIOS= 32MB RAM (tried with only 16MB too) Adaptec 1542CF (IRQ 11, DMA 6, mem dc000, port 330) Quantum ProDrive 105S (SCSI 1, only device on chain) STB PowerGraph X-24 (I've tried all the different jumper settings) Logitech C-9 serial mouse generic multifunction I/O card (2S,1P,1G) (mouse is the only thing connec= ted) Now I'm left to suspect the 1542 or my motherboard. Anybody have any ide= as? _________________________________________________________________________= ______ Steven Plite Open Systems Eng. & Support, Weyerh= aeuser "This is the roller coaster of endless and violent vomit." -- Jason F= ox >From 9fans-outgoing-owner Sat Aug 5 04:44:52 1995 Received: by colossus.cse.psu.edu id <45512>; Sat, 5 Aug 1995 04:36:14 -0400 Received: from mail.swip.net ([192.71.180.65]) by colossus.cse.psu.edu with SMTP id <45514>; Sat, 5 Aug 1995 04:35:58 -0400 Received: from bull.se by mail.swip.net (8.6.8/3.01) id KAA00296; Sat, 5 Aug 1995 10:41:31 +0200 Received: from comserv.bull.se by bull.se with smtp (Smail3.1.28.1 #8) id m0seehP-0000qlC; Sat, 5 Aug 95 10:35 MDT Received: from ml by comserv.bull.se with uucp (Smail3.1.28.1 #2) id m0seekc-0000gaC; Sat, 5 Aug 95 10:38 MET Received: by ml.link.bull.se (Smail3.1.28.1 #5) id m0seehq-0009YeC; Sat, 5 Aug 95 10:35 MDT Received: by maja.bull.se (AIX 3.2/UCB 5.64/4.03) id AA26586; Sat, 5 Aug 1995 10:33:01 +0200 Date: Sat, 5 Aug 1995 04:33:01 -0400 Message-Id: <9508050833.AA26586@maja.bull.se> From: mkc@bull.se To: 9fans Subject: Re: 387 required? *and* Memory errors? Mothra sucks? Newsgroups: mlist.plan9-fans In-Reply-To: <3vv00j$pkg@gap.cco.caltech.edu> References: <199508050446.AA26993@interlock.wdni.com> <3vv00j$pkg@gap.cco.caltech.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-9fans Precedence: bulk Reply-To: 9fans Daniel Egnor writes about Plan 9 dealing poorly with memory errors and gives this example of rc code: > fn ls { lc -F } > (If you're clever you'll figure out why this loops -- it took me a while, since > I wasn't used to the system) will very quickly cause an 8MB machine to scroll > "No physical memory" messages all over the screen. I did that too, under AIX, the IBM (and Bull) Unix. My rc was over 15 MB before I killed the process. Oops. The memory in the machine is 288 MB, though, so I didn't have to go through what you describe. Anyway, it's not just Plan 9 that deals poorly with out-of-memory situations. Look at your vanilla Unix system and see what it does... Mikael Cardell, Dharma Hacker /* No, I don't speak for Bull */ >From 9fans-outgoing-owner Sat Aug 5 09:37:57 1995 Received: by colossus.cse.psu.edu id <45523>; Sat, 5 Aug 1995 09:14:56 -0400 Received: from sol.we.lc.ehu.es ([158.227.6.42]) by colossus.cse.psu.edu with SMTP id <45514>; Sat, 5 Aug 1995 09:14:40 -0400 Received: from sirius.we.lc.ehu.es by sol.we.lc.ehu.es (5.x/SMI-SVR4) id AA03262; Sat, 5 Aug 1995 15:13:44 +0200 Date: Sat, 5 Aug 1995 09:13:44 -0400 From: borjam@we.lc.ehu.es (Borja Marcos) Message-Id: <9508051313.AA03262@sol.we.lc.ehu.es> To: 9fans Subject: Plan9 and mice Sender: owner-9fans Precedence: bulk Reply-To: 9fans Hello, I have just installed the 4 floppy distribution (and I'm waiting impatiently to receive the complete system I've ordered :-) ). I had a problem with the miec I tested. One of them is a Genius HiMouse (serial, Mouse-Systems type) which works flawlessly with XFree86, and a Dexxa mouse, also Mouse Systems compatible in COM1. Neuther of them worked when I told the system to use COM1. It said "Unknown mouse type". However, I tried to execute "aux/mouse" WITHOUT any parameters and it works now. After editing the rc script which loads the driver, the system is working fine. What is the difference if I don't give parameters to the mouse driver? The rest of the installation has gone well, without any problems. I'm looking forward to receive the complete system so that I acn make a permanent installation. Thank you very much, Bell Labs, for bringing another interesting operating system; perhaps in ten years it will be widespread? :-) Borja Marcos. borjam@we.lc.ehu.es >From 9fans-outgoing-owner Sat Aug 5 10:36:56 1995 Received: by colossus.cse.psu.edu id <45514>; Sat, 5 Aug 1995 10:20:13 -0400 Received: from plan9.att.com ([192.20.225.252]) by colossus.cse.psu.edu with SMTP id <45528>; Sat, 5 Aug 1995 10:15:52 -0400 From: presotto@plan9.att.com To: 9fans Date: Sat, 5 Aug 1995 09:59:49 -0400 Subject: re: Plan9 and mice Message-Id: <95Aug5.101552edt.45528@colossus.cse.psu.edu> Sender: owner-9fans Precedence: bulk Reply-To: 9fans Without parameters the aux/mouse assumes the mouse is on serial port 0, we number them 0 and 1 unlike DOS's 1 and 2. Other than that, it's the same. ------ original message follows ------ >From cse.psu.edu!9fans-outgoing-owner Sat Aug 5 09:38:53 EDT 1995 Received: by colossus.cse.psu.edu id <45523>; Sat, 5 Aug 1995 09:14:56 -0400 Received: from sol.we.lc.ehu.es ([158.227.6.42]) by colossus.cse.psu.edu with SMTP id <45514>; Sat, 5 Aug 1995 09:14:40 -0400 Received: from sirius.we.lc.ehu.es by sol.we.lc.ehu.es (5.x/SMI-SVR4) id AA03262; Sat, 5 Aug 1995 15:13:44 +0200 Date: Sat, 5 Aug 1995 09:13:44 -0400 From: borjam@we.lc.ehu.es (Borja Marcos) Message-Id: <9508051313.AA03262@sol.we.lc.ehu.es> To: 9fans@cse.psu.edu Subject: Plan9 and mice Sender: owner-9fans@cse.psu.edu Precedence: bulk Reply-To: 9fans@cse.psu.edu Hello, I have just installed the 4 floppy distribution (and I'm waiting impatiently to receive the complete system I've ordered :-) ). I had a problem with the miec I tested. One of them is a Genius HiMouse (serial, Mouse-Systems type) which works flawlessly with XFree86, and a Dexxa mouse, also Mouse Systems compatible in COM1. Neuther of them worked when I told the system to use COM1. It said "Unknown mouse type". However, I tried to execute "aux/mouse" WITHOUT any parameters and it works now. After editing the rc script which loads the driver, the system is working fine. What is the difference if I don't give parameters to the mouse driver? The rest of the installation has gone well, without any problems. I'm looking forward to receive the complete system so that I acn make a permanent installation. Thank you very much, Bell Labs, for bringing another interesting operating system; perhaps in ten years it will be widespread? :-) Borja Marcos. borjam@we.lc.ehu.es >From 9fans-outgoing-owner Sat Aug 5 11:50:22 1995 Received: by colossus.cse.psu.edu id <45530>; Sat, 5 Aug 1995 11:40:19 -0400 Received: from Fox.NSTN.Ca ([137.186.128.12]) by colossus.cse.psu.edu with SMTP id <45529>; Sat, 5 Aug 1995 11:40:00 -0400 Received: from [137.186.184.143] (ottawa-ts-43.nstn.ca [137.186.184.143]) by Fox.NSTN.Ca (8.6.10/8.6.10) with SMTP id MAA18694 for <9fans@cse.psu.edu>; Sat, 5 Aug 1995 12:39:45 -0300 Date: Sat, 5 Aug 1995 12:39:44 -0400 From: "Sandy Harris" Message-Id: <54888.sharris@fox.nstn.ca> X-Minuet-Version: Minuet1.0_Beta_16 X-POPMail-Charset: English To: 9fans Subject: Load sharing in Plan 9 Sender: owner-9fans Precedence: bulk Reply-To: 9fans Given a PC running Plan 9, one user & a desire for more computational horsepower (mainly for large compiles & CPU-eating background jobs like searching for factors of huge numbers), I can afford: either another PC, 16 megs, fast 486 or low-end Pentium or half a dozen Sun 3/60s each with 16 megs & 20 MHz 68020 Costs on these are roughly equal. Does Plan 9 have load-sharing support to make the multi-Sun configuration an interesting parallel compute server? Or has anyone ported PVM or other similar code? -- Sandy Harris sharris@fox.nstn.ns.ca >From 9fans-outgoing-owner Sat Aug 5 12:10:50 1995 Received: by colossus.cse.psu.edu id <45538>; Sat, 5 Aug 1995 12:01:50 -0400 Received: from staff.cs.su.OZ.AU ([129.78.8.1]) by colossus.cse.psu.edu with SMTP id <45537>; Sat, 5 Aug 1995 12:01:29 -0400 Received: from staff.cs.su.oz.au by staff.cs.su.OZ.AU (mail from gary for 9fans@cse.psu.edu) with MHSnet; Sun, 06 Aug 1995 02:01:17 +1000 Date: Sat, 5 Aug 1995 12:01:13 -0400 From: gary@cs.su.oz.au (Gary Capell) To: 9fans Message-ID: Subject: Re: Load sharing in Plan 9 Sender: owner-9fans Precedence: bulk Reply-To: 9fans I think 'cpu' is the most sophisticated load-sharing command. You could use this to easily implement a coarse-grain parallel make, but I suspect most of the time you'd be better off with the Pentium. >From 9fans-outgoing-owner Sat Aug 5 12:27:54 1995 Received: by colossus.cse.psu.edu id <45537>; Sat, 5 Aug 1995 12:20:41 -0400 Received: from chamber.cco.caltech.edu ([131.215.48.55]) by colossus.cse.psu.edu with SMTP id <45528>; Sat, 5 Aug 1995 12:20:25 -0400 Received: from gap.cco.caltech.edu by chamber.cco.caltech.edu with ESMTP (8.6.12/DEI:4.41) id JAA11075; Sat, 5 Aug 1995 09:20:14 -0700 Received: by gap.cco.caltech.edu (8.6.7/DEI:4.41) id JAA19404; Sat, 5 Aug 1995 09:20:13 -0700 To: mlist-plan9-fans@nntp-server.caltech.edu Path: egnor From: egnor@whip.ugcs.caltech.edu (Daniel Egnor) Newsgroups: mlist.plan9-fans Subject: Re: 387 required? *and* Memory errors? Mothra sucks? Date: Sat, 5 Aug 1995 12:20:12 -0400 Organization: California Institute of Technology, Pasadena, CA Lines: 31 Message-ID: <4005ns$iua@gap.cco.caltech.edu> References: <95Aug5.024030edt.46619@colossus.cse.psu.edu> NNTP-Posting-Host: whip.ugcs.caltech.edu Sender: owner-9fans Precedence: bulk Reply-To: 9fans In article <95Aug5.024030edt.46619@colossus.cse.psu.edu>, <9fans@cse.psu.edu> wrote: >The "no physical memory" messages can be removed by turning on swapping. >Choose a swap partition and point swap at it; see swap(8). It is not enabled >by default because the system cannot safely identify a partition to use; you >must set one up. The announcement about how much swap space reflects the size >of an internal data structure. Neato! I will do this, thanks (though I will have to wait for the CD). People who have done this, what happens when some process starts chewing up VM? Can you set process limits in Plan 9? >A `urlfs' would be folly, because URLs are not a real name space and the >semantics are utterly unmanageable. What is meant by this, in particular? Maybe I will re-read some of the papers to try to understand more fully the concept of a Plan 9 "name space"... >The argument is analogous to that which prevented us from putting network >names in the file name space. As for mothra, the interface may be lame but >I wonder why you think that, given that you have not got the CD >and therefore probably haven't seen it. A version of mothra comes with the four disk set. >Its bugs, as said in the manual, are because it is a very new program. *nod* -- "early alpha". Dan >From 9fans-outgoing-owner Sat Aug 5 12:37:57 1995 Received: by colossus.cse.psu.edu id <45541>; Sat, 5 Aug 1995 12:28:21 -0400 Received: from plan9.att.com ([192.20.225.252]) by colossus.cse.psu.edu with SMTP id <45528>; Sat, 5 Aug 1995 12:27:29 -0400 From: philw@plan9.att.com To: 9fans Date: Sat, 5 Aug 1995 12:10:03 -0400 Subject: Re: 387 required? *and* Memory errors? Mothra sucks? Message-Id: <95Aug5.122729edt.45528@colossus.cse.psu.edu> Sender: owner-9fans Precedence: bulk Reply-To: 9fans Look at the manual page for swap. You might try reading the documentation before posting. phil >From 9fans-outgoing-owner Sat Aug 5 12:54:03 1995 Received: by colossus.cse.psu.edu id <45544>; Sat, 5 Aug 1995 12:41:33 -0400 Received: from plan9.att.com ([192.20.225.252]) by colossus.cse.psu.edu with SMTP id <45528>; Sat, 5 Aug 1995 12:41:16 -0400 From: rob@plan9.att.com To: 9fans Date: Sat, 5 Aug 1995 12:38:45 -0400 Message-Id: <95Aug5.124116edt.45528@colossus.cse.psu.edu> Sender: owner-9fans Precedence: bulk Reply-To: 9fans I just put our current, much stronger version of mothra on the FTP site. /plan9/pcdist/mothra.386 is the 386 binary. Use it instead of the version that unpacks with the 4-diskette system. >From 9fans-outgoing-owner Sat Aug 5 13:40:04 1995 Received: by colossus.cse.psu.edu id <45550>; Sat, 5 Aug 1995 13:30:01 -0400 Received: from galapagos.cse.psu.edu ([130.203.2.12]) by colossus.cse.psu.edu with SMTP id <45528>; Sat, 5 Aug 1995 13:29:45 -0400 Received: from localhost by galapagos.cse.psu.edu with SMTP id <12712>; Sat, 5 Aug 1995 13:29:33 -0400 To: 9fans Subject: emoticons Date: Sat, 5 Aug 1995 13:29:24 -0400 From: Scott Schwartz Message-Id: <95Aug5.132933edt.12712@galapagos.cse.psu.edu> Sender: owner-9fans Precedence: bulk Reply-To: 9fans The utf paper says "why type :-) when you can use the character €м? Under unix, sam supports :) to generate the happy face, but that Rune seems to be missing from /sys/src/9/port/latin1.c. Should we add :), :( and ;) to the table? >From 9fans-outgoing-owner Sat Aug 5 14:29:09 1995 Received: by colossus.cse.psu.edu id <45556>; Sat, 5 Aug 1995 14:11:12 -0400 Received: from ncrhub1.ATTGIS.COM ([192.127.251.16]) by colossus.cse.psu.edu with SMTP id <45555>; Sat, 5 Aug 1995 14:06:43 -0400 Received: from ncrgw1 by ncrhub1.ATTGIS.COM id aa12552; 5 Aug 95 14:01 EDT Received: by ncrgw1.ATTGIS.COM; 5 Aug 95 13:57:39 EDT Received: by ncrhub4.ATTGIS.COM; 5 Aug 95 13:57:28 EDT Date: Sat, 5 Aug 1995 13:56:15 -0400 From: MAILER-DAEMON@ncrcae.columbiasc.NCR.COM Full-Name: Mail Router (smail 2.8.1 dl,da,fa,tu,po,qf,dbm 06/12/93 6) Subject: Returned mail To: 9fans Message-ID: <9508051401.aa12552@ncrhub1.ATTGIS.COM> Sender: owner-9fans Precedence: bulk Reply-To: 9fans Your mail could not be delivered because of the following reason: ----- Transcript of session follows ----- Executing: /usr/lib/mail/surrcmd/smtpqer -C -u ncrcae.ColumbiaSC.NCR.COM!ncrhub4!ncrgw1!cse.psu.edu!9fans yesac wescott@yesac smtpqer: Binary contents cannot be sent via SMTP server "/usr/lib/mail/surrcmd/smtpqer" failed - unknown mailer error 1 ----- Unsent message follows ----- >From ncrgw1!cse.psu.edu!9fans Sat Aug 5 13:57 EDT 1995 remote from ncrhub4 Received: by ncrhub4.ATTGIS.COM; 5 Aug 95 13:57:11 EDT Received: by ncrgw1.ATTGIS.COM; 5 Aug 95 13:56:58 EDT Received: by colossus.cse.psu.edu id <45550>; Sat, 5 Aug 1995 13:30:01 -0400 Received: from galapagos.cse.psu.edu ([130.203.2.12]) by colossus.cse.psu.edu with SMTP id <45528>; Sat, 5 Aug 1995 13:29:45 -0400 Received: from localhost by galapagos.cse.psu.edu with SMTP id <12712>; Sat, 5 Aug 1995 13:29:33 -0400 To: 9fans@cse.psu.edu Subject: emoticons Date: Sat, 5 Aug 1995 13:29:24 -0400 From: Scott Schwartz Message-Id: <95Aug5.132933edt.12712@galapagos.cse.psu.edu> Sender: owner-9fans@cse.psu.edu Precedence: bulk Reply-To: 9fans@cse.psu.edu The utf paper says "why type :-) when you can use the character b:? Under unix, sam supports :) to generate the happy face, but that Rune seems to be missing from /sys/src/9/port/latin1.c. Should we add :), :( and ;) to the table? >From 9fans-outgoing-owner Sat Aug 5 16:18:26 1995 Received: by colossus.cse.psu.edu id <45528>; Sat, 5 Aug 1995 16:02:19 -0400 Received: from plan9.att.com ([192.20.225.252]) by colossus.cse.psu.edu with SMTP id <45552>; Sat, 5 Aug 1995 16:00:53 -0400 From: jmk@plan9.att.com To: 9fans Date: Sat, 5 Aug 1995 15:50:12 -0400 Subject: VGA problems Message-Id: <95Aug5.160053edt.45552@colossus.cse.psu.edu> Sender: owner-9fans Precedence: bulk Reply-To: 9fans One of the biggest problems with Plan 9 on the PC is the awful VGA device and the equally awful programme to set it up, aux/vga. If the system hangs on boot before a message from dossrv appears on the CGA screen then aux/vga blew it. You can prevent aux/vga from running by commenting out the 'monitor=' line in plan9.ini, /bin/termrc will only run aux/vga if the environment variable 'monitor' is set. You will be left in CGA mode. Two warnings about this: 1) make sure you do not start anything fancy (such as a window manager) in your lib/profile; 2) DEL is interpreted by the window manager so you will be unable to interrupt anything you start. If you can't get to this state then your PC/VGA just isn't compatible with Plan 9. Manually run aux/vga to see if it can put the VGA card into the basic 640x480x1 mode which all compatible cards should support: aux/vga -lvp > /tmp/x (aux/vga defaults to 'monitor=vga' and resolution 640x480x1). Output is redirected to capture some information during this run while still in CGA mode that would be destroyed by the switch to VGA mode. Usually this will have the desired effect and the system will be in VGA mode. Look in /tmp/x for any obvious errors. There may be a section which says e.g. controller not in /lib/vgadb 0xC0000 55 AA 40 EB 04 37 34 30 30 E9 0A 15 00 00 00 00 U.@..7400....... 0xC0010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 49 42 ..............IB 0xC0020 4D 20 56 47 41 20 43 6F 6D 70 61 74 69 62 6C 65 M VGA Compatible 0xC0030 20 42 49 4F 53 2E 20 00 BB 66 DB 01 EF 01 81 00 BIOS. ..f...... 0xC0040 00 FF 00 0A 51 75 61 64 74 65 6C 20 53 33 20 38 ....Quadtel S3 8 0xC0050 36 43 38 30 35 20 45 6E 68 61 6E 63 65 64 20 56 6C805 Enhanced V 0xC0060 47 41 20 42 49 4F 53 2E 20 56 65 72 73 69 6F 6E GA BIOS. Version 0xC0070 20 32 2E 31 33 2E 30 32 45 30 31 0D 0A 43 6F 70 2.13.02E01..Cop 0xC0080 79 72 69 67 68 74 20 31 39 38 37 2D 31 39 39 32 yright 1987-1992 0xC0090 20 51 75 61 64 74 65 6C 20 43 6F 72 70 2E 2C 20 Quadtel Corp., 0xC00A0 41 20 50 68 6F 65 6E 69 78 20 54 65 63 68 6E 6F A Phoenix Techno 0xC00B0 6C 6F 67 69 65 73 20 4C 74 64 20 43 6F 6D 70 61 logies Ltd Compa 0xC00C0 6E 79 2E 0D 0A 41 6C 6C 20 52 69 67 68 74 73 20 ny...All Rights 0xC00D0 52 65 73 65 72 76 65 64 0D 0A 00 00 00 00 00 00 Reserved........ 0xC00E0 00 00 00 00 4F 72 63 68 69 64 20 54 65 63 68 6E ....Orchid Techn 0xC00F0 6F 6C 6F 67 79 20 46 61 68 72 65 6E 68 65 69 74 ology Fahrenheit This is a dump of part of the VGA BIOS and we can use this to add an entry to /lib/vgadb for this card: ctlr 0xC0044="Quadtel S3 86C805 Enhanced VGA BIOS. Version 2.13.02E01" ctlr=vga With this in place aux/vga should work without complaint for resolutions 640x480x[18] as these require no additional programming of the graphics chip, RAMDAC or clock generator. To proceed to higher resolutions and clock rates it's necessary to know more about the VGA card, specifically which graphics chip, RAMDAC and clock generator are used; inspect the card and see VGADB(6) for more details. >From 9fans-outgoing-owner Sat Aug 5 23:50:55 1995 Received: by colossus.cse.psu.edu id <45599>; Sat, 5 Aug 1995 23:41:37 -0400 Received: from emory.mathcs.emory.edu ([128.140.2.1]) by colossus.cse.psu.edu with SMTP id <45598>; Sat, 5 Aug 1995 23:41:21 -0400 Received: from skeeve.UUCP by emory.mathcs.emory.edu (5.65/Emory_mathcs.4.0.15) via UUCP id AA21106 ; Sat, 5 Aug 95 23:41:11 -0400 Received: by skeeve.atl.ga.us (/\==/\ Smail3.1.22.1 #22.1) id ; Sat, 5 Aug 95 23:25 EDT Message-Id: Date: Sat, 5 Aug 1995 23:25:00 -0400 From: arnold@skeeve.atl.ga.us (Arnold D. Robbins) To: 9fans Subject: Re: emoticons In-Reply-To: <95Aug5.132933edt.12712@galapagos.cse.psu.edu> X-Mailer: [XMailTool v3.1.2] Sender: owner-9fans Precedence: bulk Reply-To: 9fans > The utf paper says "why type :-) when you can use the character b:? > Under unix, sam supports :) to generate the happy face, but > that Rune seems to be missing from /sys/src/9/port/latin1.c. Should > we add :), :( and ;) to the table? Yeah, I asked bobf to include that in the Unix version of sam and he did, I guess it didn't make it back into the master plan 9 version. Arnold Robbins -- The Basement Computer | Laundry increases Internet: arnold@skeeve.ATL.GA.US | exponentially in the UUCP: emory!skeeve!arnold | number of children. Bitnet: Forget it. Get on a real network. | -- Miriam Robbins >From 9fans-outgoing-owner Sun Aug 6 01:28:43 1995 Received: by colossus.cse.psu.edu id <45609>; Sun, 6 Aug 1995 01:16:54 -0400 Received: from interlock.wdni.com ([199.221.59.2]) by colossus.cse.psu.edu with SMTP id <45610>; Sun, 6 Aug 1995 01:16:38 -0400 Received: by interlock.wdni.com id AA02120 (InterLock SMTP Gateway 3.0 for 9fans@cse.psu.edu); Sat, 5 Aug 1995 22:16:21 -0700 Message-Id: <199508060516.AA02120@interlock.wdni.com> Received: by interlock.wdni.com (Protected-side Proxy Mail Agent-1); Sat, 5 Aug 1995 22:16:21 -0700 Date: Sun, 6 Aug 1995 01:16:33 -0400 From: Steven Plite To: 9fans Subject: Re: VGA problems Mime-Version: 1.0 Content-Type: text/plain; charset=X-roman8 Content-Transfer-Encoding: quoted-printable Sender: owner-9fans Precedence: bulk Reply-To: 9fans When we last left our protagonist, he was fruitlessly trying to get the 4-floppy dist running on his 386DX/40: > If the system hangs on boot before a message from dossrv appears on > the CGA screen then aux/vga blew it. You can prevent aux/vga from runni= ng Okay, so aux/vga is blowing it. If I remove the "monitor=3D" line from plan9.ini, I'm left at a shell prompt in CGA mode. > Manually run aux/vga to see if it can put the VGA card into the basic > 640x480x1 mode which all compatible cards should support: > aux/vga -lvp > /tmp/x Okay. This causes the same flash I was getting, then returns to the shel= l prompt. /tmp/x contains: tag =3D Tnone; expected Tfile I tried fiddling with the entry for the PowerGraph X-24 in /lib/vgadb, su= ch as commenting out the lines following "link=3Dvga". No help. I also change= d the BIOS ID string, to make sure vga(8) was actually recognizing my card. It= is. I'd give up on this card, except that it's supposedly supported (first en= try in vgadb, even.) Do I have an old rev? The stickers on the video BIOS c= hips say V1.4, although the BIOS dump showed "X-24 BIOS Ver. 2.01". Is the S3= 801 driver in the 4-floppy dist broken with respect to the X-24? Would the dump from "aux/vga -pv" give anybody an idea? Or should I just= bag it? Thanks for the help. _________________________________________________________________________= ______ Steven Plite Open Systems Eng. & Support, Weyerh= aeuser "This is the roller coaster of endless and violent vomit." -- Jason F= ox >From 9fans-outgoing-owner Sun Aug 6 11:49:11 1995 Received: by colossus.cse.psu.edu id <45634>; Sun, 6 Aug 1995 11:31:18 -0400 Received: from plan9.att.com ([192.20.225.252]) by colossus.cse.psu.edu with SMTP id <45633>; Sun, 6 Aug 1995 11:31:00 -0400 From: jmk@plan9.att.com To: 9fans Date: Sun, 6 Aug 1995 11:22:45 -0400 Subject: Re: VGA problems Message-Id: <95Aug6.113100edt.45633@colossus.cse.psu.edu> Sender: owner-9fans Precedence: bulk Reply-To: 9fans prompt. /tmp/x contains: tag =3D Tnone; expected Tfile I tried fiddling with the entry for the PowerGraph X-24 in /lib/vgadb, su= ch as commenting out the lines following "link=3Dvga". No help. I also change= d the BIOS ID string, to make sure vga(8) was actually recognizing my card. It= is. 1) i don't understand the error in /tmp/x, it's nothing to do with aux/vga, try running ramfs first; 2) i don't understand the reference to "link=3Dvga", you haven't been fiddling with aux/vga without a licence have you? my understanding here is that you have a supported vga card but an unsupported monitor. using the line "monitor=vga" in plan9.ini and the distributed /lib/vgadb should work for resolutions of 640x480x[18] and 800x600x[18]. then you need to either find a suitable entry in the monitor section of /lib/vgadb (one of the 'multisync... entries) or craft one yourself. >From 9fans-outgoing-owner Sun Aug 6 17:03:08 1995 Received: by psuvax1.cse.psu.edu id <34113>; Sun, 6 Aug 1995 16:54:14 -0400 Received: from galapagos.cse.psu.edu ([130.203.2.12]) by psuvax1.cse.psu.edu with SMTP id <34242>; Sun, 6 Aug 1995 16:27:24 -0400 Received: from localhost by galapagos.cse.psu.edu with SMTP id <12712>; Fri, 4 Aug 1995 16:29:42 -0400 To: 9fans Subject: emoticons Date: Fri, 4 Aug 1995 16:29:27 -0400 From: Scott Schwartz Message-Id: <95Aug4.162942edt.12712@galapagos.cse.psu.edu> Sender: owner-9fans Precedence: bulk Reply-To: 9fans The utf paper says "why type :-) when you can use the character €€€€?". Under unix, sam supports :) to generate the happy face, but that Rune seems to be missing from /sys/src/9/port/latin1.c. >From 9fans-outgoing-owner Sun Aug 6 17:27:34 1995 Received: by psuvax1.cse.psu.edu id <34101>; Sun, 6 Aug 1995 17:21:08 -0400 Received: from plan9.cs.york.ac.uk ([144.32.32.195]) by psuvax1.cse.psu.edu with SMTP id <34325>; Sun, 6 Aug 1995 16:46:27 -0400 From: forsyth@plan9.cs.york.ac.uk Date: Sun, 6 Aug 1995 12:20:44 -0400 To: 9fans@cs.psu.edu subject: link=3Dvga; broken f.s. Message-Id: <95Aug6.164627edt.34325@psuvax1.cse.psu.edu> Sender: owner-9fans Precedence: bulk Reply-To: 9fans >>2) i don't understand the reference to "link=3Dvga", you haven't been fiddling >> with aux/vga without a licence have you? splite@wdni.com's mailer seems to be using = as an escape (3D is `='). >>Content-Type: text/plain; charset=X-roman8 >>Content-Transfer-Encoding: quoted-printable anyhow, as far as this goes: >>prompt. /tmp/x contains: >> tag = Tnone; expected Tfile that probably signifies a corrupt file system; that looks to me like a message from disk/kfs (or /fs). it isn't surprising there are problems if the system hung up and had to be reset before a disk/kfscmd halt could be done. (if it happens again, wait about 30 seconds before resetting to give it a chance to sync automatically; normally the f.s. will then be consistent.) disk/kfscmd 'check' will show the extent of the damage, but the demo. system is small enough that there aren't any optional files; something is bound to break later. while it is possible to make the curdled file system consistent again using the options to disk/kfscmd 'check', it's probably better to unpack the distribution again into a remade file system. >From 9fans-outgoing-owner Sun Aug 6 17:56:16 1995 Received: by psuvax1.cse.psu.edu id <34024>; Sun, 6 Aug 1995 17:49:16 -0400 Received: from plan9.att.com ([192.20.225.252]) by psuvax1.cse.psu.edu with SMTP id <34261>; Sun, 6 Aug 1995 17:41:38 -0400 From: philw@plan9.att.com To: 9fans Date: Sun, 6 Aug 1995 16:54:53 -0400 Subject: Re: Serial port i/o, how? Message-Id: <95Aug6.174138edt.34261@psuvax1.cse.psu.edu> Sender: owner-9fans Precedence: bulk Reply-To: 9fans it is entirely possible we number the ports in the opposite fashion to DOS. try eia1. philw >From 9fans-outgoing-owner Sun Aug 6 18:07:32 1995 Received: by psuvax1.cse.psu.edu id <33963>; Sun, 6 Aug 1995 17:58:33 -0400 Received: from ncrhub1.ATTGIS.COM ([192.127.251.16]) by psuvax1.cse.psu.edu with SMTP id <34045>; Sun, 6 Aug 1995 17:47:35 -0400 Received: from ncrgw1 by ncrhub1.ATTGIS.COM id aa17177; 6 Aug 95 17:24 EDT Received: by ncrgw1.ATTGIS.COM; 6 Aug 95 17:21:36 EDT Received: by ncrhub4.ATTGIS.COM; 6 Aug 95 17:21:27 EDT Date: Sun, 6 Aug 1995 17:20:09 -0400 From: MAILER-DAEMON@ncrcae.columbiasc.NCR.COM Full-Name: Mail Router (smail 2.8.1 dl,da,fa,tu,po,qf,dbm 06/12/93 6) Subject: Returned mail To: 9fans Message-ID: <9508061724.aa17177@ncrhub1.ATTGIS.COM> Sender: owner-9fans Precedence: bulk Reply-To: 9fans Your mail could not be delivered because of the following reason: ----- Transcript of session follows ----- Executing: /usr/lib/mail/surrcmd/smtpqer -C -u ncrcae.ColumbiaSC.NCR.COM!ncrhub4!ncrgw1!cse.psu.edu!9fans yesac wescott@yesac smtpqer: Binary contents cannot be sent via SMTP server "/usr/lib/mail/surrcmd/smtpqer" failed - unknown mailer error 1 ----- Unsent message follows ----- >From ncrgw1!cse.psu.edu!9fans Sun Aug 6 17:21 EDT 1995 remote from ncrhub4 Received: by ncrhub4.ATTGIS.COM; 6 Aug 95 17:21:10 EDT Received: by ncrgw1.ATTGIS.COM; 6 Aug 95 17:20:58 EDT Received: by psuvax1.cse.psu.edu id <34113>; Sun, 6 Aug 1995 16:54:14 -0400 Received: from galapagos.cse.psu.edu ([130.203.2.12]) by psuvax1.cse.psu.edu with SMTP id <34242>; Sun, 6 Aug 1995 16:27:24 -0400 Received: from localhost by galapagos.cse.psu.edu with SMTP id <12712>; Fri, 4 Aug 1995 16:29:42 -0400 To: 9fans@cse.psu.edu Subject: emoticons Date: Fri, 4 Aug 1995 16:29:27 -0400 From: Scott Schwartz Message-Id: <95Aug4.162942edt.12712@galapagos.cse.psu.edu> Sender: owner-9fans@cse.psu.edu Precedence: bulk Reply-To: 9fans@cse.psu.edu The utf paper says "why type :-) when you can use the character b:?". Under unix, sam supports :) to generate the happy face, but that Rune seems to be missing from /sys/src/9/port/latin1.c. >From 9fans-outgoing-owner Mon Aug 7 02:30:16 1995 Received: by psuvax1.cse.psu.edu id <33960>; Mon, 7 Aug 1995 02:03:06 -0400 Received: from nsof.co.il ([192.114.145.1]) by psuvax1.cse.psu.edu with SMTP id <33958>; Mon, 7 Aug 1995 02:02:33 -0400 Received: by nsof.co.il (4.1/SMI-4.1) id AA07818; Mon, 7 Aug 95 09:02:06 IDT Date: Mon, 7 Aug 1995 05:02:06 -0400 From: amos@nsof.co.il (Amos Shapir) Message-Id: <9508070602.AA07818@nsof.co.il> To: 9fans Subject: Re: emoticons Sender: owner-9fans Precedence: bulk Reply-To: 9fans MAILER-DAEMON@ncrcae.columbiasc.NCR.COM writes: > Your mail could not be delivered because of the following reason: > ----- Transcript of session follows ----- (cruft deleted) > smtpqer: Binary contents cannot be sent via SMTP > ----- Unsent message follows ----- (more cruft deleted) > To: 9fans@cse.psu.edu > Subject: emoticons > Date: Fri, 4 Aug 1995 16:29:27 -0400 > From: Scott Schwartz > The utf paper says "why type :-) when you can use the character b:?". Well, now we know why!... Amos Shapir Net: amos@nsof.co.il Paper: nSOF Parallel Software, Ltd. Givat-Hashlosha 48800, Israel Tel: +972 3 9388551 Fax: +972 3 9388552 GEO: 34 55 15 E / 32 05 52 N >From 9fans-outgoing-owner Mon Aug 7 06:37:02 1995 Received: by psuvax1.cse.psu.edu id <33963>; Mon, 7 Aug 1995 06:11:43 -0400 Received: from staff.cs.su.OZ.AU ([129.78.8.1]) by psuvax1.cse.psu.edu with SMTP id <33958>; Mon, 7 Aug 1995 06:07:16 -0400 Received: from sour.sw.oz.au by staff.cs.su.OZ.AU (mail from jeremy for 9fans@cse.psu.edu) with MHSnet (insertion MHSnet site: swallow.sw.oz.au); Mon, 07 Aug 1995 20:05:30 +1000 Received: from sour.sw.oz.au by swallow.sw.oz.au with SMTP id AA29506; Mon, 7 Aug 95 20:05:11 EST (4.1/Unixware) (from jeremy@sour.sw.oz.au for 9fans@cse.psu.edu) Received: by sour.sw.oz.au id AA29618; Mon, 7 Aug 1995 20:05:10 +1000 (5.65c/1.34) (from jeremy@sour.sw.oz.au for 9fans@cse.psu.edu) From: jeremy@sour.sw.oz.au (Jeremy Fitzhardinge) Message-Id: <199508071005.AA29618@sour.sw.oz.au> Subject: #9 GXE64 support To: 9fans (Graverobbers from Outer Space!) Date: Mon, 7 Aug 1995 06:05:09 -0400 Organization: Softway Pty Ltd X-Face: '6U=%Tv\k1l-:?\$C[D@G 7(vl~w8&y}!f\bh#wL#n,TGKh>T.c7eT5-y)Hl'i;A1z$9?*lD.k}yqshddFb l[EC}c=;uc%x'}uh3E91p&oEFrom 9fans-outgoing-owner Mon Aug 7 08:49:02 1995 Received: by psuvax1.cse.psu.edu id <33980>; Mon, 7 Aug 1995 08:21:26 -0400 Received: from sangam.ncst.ernet.in ([144.16.11.1]) by psuvax1.cse.psu.edu with SMTP id <33958>; Mon, 7 Aug 1995 08:16:12 -0400 Received: from iisc.ernet.in (iisc.iisc.ernet.in [144.16.64.3]) by sangam.ncst.ernet.in (8.6.12/8.6.6) with SMTP id RAA06128 for <9fans@cse.psu.edu>; Mon, 7 Aug 1995 17:43:01 +0530 Received: from vigyan.UUCP by iisc.ernet.in (ERNET-IISc/SMI-4.1) id AA29385; Mon, 7 Aug 95 17:46:39+0530 Received: by vigyan.iisc.ernet.in (smail2.3) id AA18539; 7 Aug 95 15:25:23 EDT (Mon) Received: from india29.sasi by sasi.ernet.in (4.1/SMI-4.1) id AA13533; Sat, 5 Aug 95 15:32:41+050 From: kp@sasi.ernet.in (Kiran Pamnany) Received: (kp@localhost) by india29.sasi (8.6.12/SMI-4.1) id PAA09959 for 9fans@cse.psu.edu; Sat, 5 Aug 1995 15:32:40 +0500 Date: Sat, 5 Aug 1995 06:32:40 -0400 Message-Id: <199508051032.PAA09959@india29.sasi> To: 9fans Subject: Plan 9 PC Distribution... Sender: owner-9fans Precedence: bulk Reply-To: 9fans Hi, I have this weird problem with the four diskette PC distribution. When I run plan9\b after installing the three diskettes, it says: '.bad magic 0xeb3e01eb not a plan 9 executable!' It then told me that the available boot devices were e!0, hd!0 (my work disk) and h!1 (the plan9 disk) and asked me which to boot from. Typing in h!1 repeats the problem and obviously the other two are useless. The entire installation procedure went across as smooth as silk -- disk1 booted and installed itself properly, the archives on the three other disks were properly expanded onto my second hard disk, the installation procedure said it was writing the kernel to the disk and then it told me to boot and run plan9\b and... If any of the disks didn't come across ok, how come it installs perfectly and expands the archives with no problem? The hardware is an Opti motherboard with a P54C 90MHz processor, 16 MB of RAM, a Diamond Stealth 64 DRAM in a PCI slot. The hard disks are driven off an IDE controller in a PCI slot (I'm not sure which). The first disk is a Quantum Maverick 540A which has DOS 6.22 and OS/2 Warp co-existing on a FAT partition and the second disk is a Maxtor 7120AT which I want to use exclusively for Plan 9 -- it has no partitions. What's going on?? BTW, cc your reply to kp@sasi.ernet.in -- sometimes I don't see mail which is sent to the list. Thanx, Kiran >From 9fans-outgoing-owner Mon Aug 7 10:09:13 1995 Received: by psuvax1.cse.psu.edu id <33986>; Mon, 7 Aug 1995 09:41:33 -0400 Received: from symbionics.co.uk ([158.43.6.17]) by psuvax1.cse.psu.edu with SMTP id <34025>; Mon, 7 Aug 1995 09:23:51 -0400 Received: from sympc143 ([194.32.100.46]) by symbionics.co.uk (4.1/SMI-4.1) id AA01136; Mon, 7 Aug 95 13:56:42 BST Message-Id: <9508071256.AA01136@symbionics.co.uk> Comments: Authenticated sender is From: "Nigel Roles" Organization: Symbionics Communications To: 9fans Date: Mon, 7 Aug 1995 09:56:40 -0400 Subject: Diamond Stealth VRAM 64 Priority: normal X-Mailer: Pegasus Mail for Windows (v2.01) Sender: owner-9fans Precedence: bulk Reply-To: 9fans These are the /lib/vgadb settings I use to support my Stealth VRAM 64 (PCI) in case anyone finds them useful: ctlr 0xC0045="Stealth 64 Vers. 1.05" # Diamond Stealth VRAM 64/PCI link=vga hwgc=s3hwgc ctlr=vision864 link=ibm8514 ramdac=bt485-135 clock=icd2061a link=s3clock I don't have a very capable monitor, so I haven't explored the outer limits much, just 1024x768x1 >From 9fans-outgoing-owner Mon Aug 7 10:51:48 1995 Received: by psuvax1.cse.psu.edu id <33985>; Mon, 7 Aug 1995 10:21:00 -0400 Received: from plan9.att.com ([192.20.225.252]) by psuvax1.cse.psu.edu with SMTP id <34045>; Mon, 7 Aug 1995 09:36:31 -0400 From: presotto@plan9.att.com To: 9fans Date: Mon, 7 Aug 1995 09:09:42 -0400 Subject: Re: Serial port i/o, how? Message-Id: <95Aug7.093631edt.34045@psuvax1.cse.psu.edu> Sender: owner-9fans Precedence: bulk Reply-To: 9fans Read: http://helix/magic/man2html/3/scc http://helix/magic/man2html/1/con You can set baud rates, etc., by echoing the right goo into the ctl file. For example: echo -n b19200 > /dev/eai0ctl sets eia0 to 19200 baud. Not all the controls are sticky in the Unix sense so you should do this while you have the /dev/eia0 open. ------ original message follows ------ >From cse.psu.edu!9fans-outgoing-owner Sun Aug 6 16:25:01 EDT 1995 Received: by psuvax1.cse.psu.edu id <34152>; Fri, 4 Aug 1995 16:22:37 -0400 Received: from goonsquad.spies.com ([192.216.22.66]) by psuvax1.cse.psu.edu with SMTP id <34203>; Fri, 4 Aug 1995 15:32:45 -0400 Received: by goonsquad.spies.com (Smail3.1.29.1 #2) id m0seSKc-00024CC; Fri, 4 Aug 95 12:22 PDT Message-Id: From: ahm@goonsquad.spies.com (Andreas Meyer) Subject: Re: Serial port i/o, how? To: 9fans@cse.psu.edu Date: Fri, 4 Aug 1995 15:22:52 -0400 In-Reply-To: <95Aug3.200951edt.34067@psuvax1.cse.psu.edu> from "philw@plan9.att.com" at Aug 3, 95 08:07:41 pm Organization: The Internet Wiretap Content-Type: text Content-Length: 338 Sender: owner-9fans@cse.psu.edu Precedence: bulk Reply-To: 9fans@cse.psu.edu philw@plan9.att.com writes: > >how do I access a serial port? > con -r /dev/eia0 When I do this, it just hangs. I'm using a hardware setup (null modem cable to another machine) which works in DOS. In another window, 'cat /dev/eia0ctl' returns: cts dsr ring dcd dtr rts Is there anything else I need to send to the control port? Andy >From 9fans-outgoing-owner Mon Aug 7 11:49:52 1995 Received: by psuvax1.cse.psu.edu id <34024>; Mon, 7 Aug 1995 11:15:04 -0400 Received: from plan9.att.com ([192.20.225.252]) by psuvax1.cse.psu.edu with SMTP id <34017>; Mon, 7 Aug 1995 10:53:47 -0400 From: jmk@plan9.att.com To: 9fans Date: Mon, 7 Aug 1995 09:55:53 -0400 Subject: re: #9 GXE64 support Message-Id: <95Aug7.105347edt.34017@psuvax1.cse.psu.edu> Sender: owner-9fans Precedence: bulk Reply-To: 9fans the ATT21C498 is the production version of the ATT20C498 according to the datasheet. my suspicion is that aux/vga is not switching over to 2x8-bit mode for the higher clock rates when it can, we've never played with any resolution requiring a clock between 80MHz and 135MHz. please post your parameters. ------ original message follows ------ >From cse.psu.edu!9fans-outgoing-owner Mon Aug 7 06:46:32 EDT 1995 Received: by psuvax1.cse.psu.edu id <33963>; Mon, 7 Aug 1995 06:11:43 -0400 Received: from staff.cs.su.OZ.AU ([129.78.8.1]) by psuvax1.cse.psu.edu with SMTP id <33958>; Mon, 7 Aug 1995 06:07:16 -0400 Received: from sour.sw.oz.au by staff.cs.su.OZ.AU (mail from jeremy for 9fans@cse.psu.edu) with MHSnet (insertion MHSnet site: swallow.sw.oz.au); Mon, 07 Aug 1995 20:05:30 +1000 Received: from sour.sw.oz.au by swallow.sw.oz.au with SMTP id AA29506; Mon, 7 Aug 95 20:05:11 EST (4.1/Unixware) (from jeremy@sour.sw.oz.au for 9fans@cse.psu.edu) Received: by sour.sw.oz.au id AA29618; Mon, 7 Aug 1995 20:05:10 +1000 (5.65c/1.34) (from jeremy@sour.sw.oz.au for 9fans@cse.psu.edu) From: jeremy@sour.sw.oz.au (Jeremy Fitzhardinge) Message-Id: <199508071005.AA29618@sour.sw.oz.au> Subject: #9 GXE64 support To: 9fans@cse.psu.edu (Graverobbers from Outer Space!) Date: Mon, 7 Aug 1995 06:05:09 -0400 Organization: Softway Pty Ltd X-Face: '6U=%Tv\k1l-:?\$C[D@G 7(vl~w8&y}!f\bh#wL#n,TGKh>T.c7eT5-y)Hl'i;A1z$9?*lD.k}yqshddFb l[EC}c=;uc%x'}uh3E91p&oEFrom 9fans-outgoing-owner Mon Aug 7 14:29:14 1995 Received: by colossus.cse.psu.edu id <45471>; Mon, 7 Aug 1995 14:03:00 -0400 Received: from interlock.wdni.com ([199.221.59.2]) by colossus.cse.psu.edu with SMTP id <45470>; Mon, 7 Aug 1995 14:02:45 -0400 Received: by interlock.wdni.com id AA20077 (InterLock SMTP Gateway 3.0 for 9fans@cse.psu.edu); Mon, 7 Aug 1995 11:02:12 -0700 Message-Id: <199508071802.AA20077@interlock.wdni.com> Received: by interlock.wdni.com (Protected-side Proxy Mail Agent-1); Mon, 7 Aug 1995 11:02:12 -0700 Date: Mon, 7 Aug 1995 14:02:12 -0400 From: Steven Plite To: 9fans Subject: Re: VGA problems Mime-Version: 1.0 Content-Type: text/plain; charset=X-roman8 Content-Transfer-Encoding: quoted-printable Sender: owner-9fans Precedence: bulk Reply-To: 9fans >> prompt. /tmp/x contains: >> tag =3D3D Tnone; expected Tfile >> I tried fiddling with the entry for the PowerGraph X-24 in /lib/vgadb,= such >> as commenting out the lines following "link=3D3Dvga". No help. I als= o >> changed the BIOS ID string, to make sure vga(8) was actually recognizi= ng my >> card. It is. > 1) i don't understand the error in /tmp/x, it's nothing to do with aux/= vga, > try running ramfs first; If it's the "3D" bit in the error message that's throwing you, I have no = idea where that came from. Ignore it. I'll look into ramfs anyway, though. > 2) i don't understand the reference to "link=3D3Dvga", you haven't been= > fiddling with aux/vga without a licence have you? Again, ignore the "3D". (Maybe this stupid HP mailer is dorking my mail = up.) And, no I haven't been fiddling with "aux/vga". (I don't know enough x86= machine language to patch the binary... :) I was only modifying /lib/vga= db. > my understanding here is that you have a supported vga card but an > unsupported monitor. using the line "monitor=3Dvga" in plan9.ini and t= he > distributed /lib/vgadb should work for resolutions of 640x480x[18] and > 800x600x[18]. then you need to either find a suitable entry in the mon= itor > section of /lib/vgadb (one of the 'multisync... entries) or craft one > yourself. No, that's not it. All my experiements *have* been using "monitor=3Dvga"= and 640x480x1 resolution. My problem is that my supposedly supported card do= esn't appear to work. Any attempt to get it to change into a VGA mode (I've tr= ied 640x480x1 and 1024x768x1) causes my PC to lock up. I tried Plan 9 on a different machine with a Cirrus Logic 5430 PCI VGA ad= aptor. When I first booted it into 640x480x1, aux/vga rightly complained that it= couldn't find a match for it in /lib/vgadb, then switched into 640x480. = Okay, fine. Add an entry to vgadb, restart, everything's cool. I would expect the same thing to work with my X-24. I even commented the= entry for it in vgadb out, so that aux/vga would assume a vanilla VGA car= d and switch to 640x480x1. No dice. Locks every time. Again, the only reason I'm still yammering about this is that this card i= s claimed to be supported. Has anyone outside BL gotten this sucker to wor= k? If not, maybe the docs and /lib/vgadb should to be updated so the next po= or sucker doesn't get his hopes up. :) BTW, is the 4-floppy dist going to be updated with fixes from time to tim= e, or is the current version "it" until the next major CD-ROM release? Thanks again for you help. _________________________________________________________________________= ______ Steven Plite Open Systems Eng. & Support, Weyerh= aeuser "This is the roller coaster of endless and violent vomit." -- Jason F= ox >From 9fans-outgoing-owner Mon Aug 7 14:49:23 1995 Received: by colossus.cse.psu.edu id <45470>; Mon, 7 Aug 1995 14:38:33 -0400 Received: from interlock.wdni.com ([199.221.59.2]) by colossus.cse.psu.edu with SMTP id <45468>; Mon, 7 Aug 1995 14:36:15 -0400 Received: by interlock.wdni.com id AA21929 (InterLock SMTP Gateway 3.0 for 9fans@cse.psu.edu); Mon, 7 Aug 1995 11:30:02 -0700 Message-Id: <199508071830.AA21929@interlock.wdni.com> Received: by interlock.wdni.com (Protected-side Proxy Mail Agent-1); Mon, 7 Aug 1995 11:30:02 -0700 Date: Mon, 7 Aug 1995 14:30:11 -0400 From: Steven Plite To: 9fans Subject: Re: link=3Dvga; broken f.s. Mime-Version: 1.0 Content-Type: text/plain; charset=X-roman8 Content-Transfer-Encoding: quoted-printable Sender: owner-9fans Precedence: bulk Reply-To: 9fans >>> 2) i don't understand the reference to "link=3D3Dvga", you haven't be= en >>> fiddling with aux/vga without a licence have you? > = > splite@wdni.com's mailer seems to be using =3D as an escape (3D is `=3D= '). Yeah. I'm going to build MH this afternoon. HP's mailx has (broken) met= amail support. (Hmmm... metamail came from BL too. Coincidence or conspiracy?= :) >>>prompt. /tmp/x contains: >>> tag =3D Tnone; expected Tfile > = > that probably signifies a corrupt file system; that looks to me like a > message from disk/kfs (or /fs). Ahh... the light of realization dawns. > it isn't surprising there are problems if the system hung up > and had to be reset before a disk/kfscmd halt could be done. > (if it happens again, wait about 30 seconds before resetting > to give it a chance to sync automatically; normally the f.s. will > then be consistent.) I've been wondering how Plan 9 dealt with a corrupted filesystem. I figu= red that resetting without halt'ing would screw something, but it never compl= ained on boot, so I (wrongly) assumed the fs was okay. > disk/kfscmd 'check' will show the extent of the damage, but > the demo. system is small enough that there aren't any optional files; > something is bound to break later. "optional files"? > while it is possible to make the curdled file system consistent again u= sing > the options to disk/kfscmd 'check', it's probably better to unpack the > distribution again into a remade file system. I'll do that. Thanks. (Sorry about all the bandwidth. I'm reading the docs as fast as I can, b= ut it's hard (for me, anyway) to learn a system without having a working one= to play with.) _________________________________________________________________________= ______ Steven Plite Open Systems Eng. & Support, Weyerh= aeuser "This is the roller coaster of endless and violent vomit." -- Jason F= ox >From 9fans-outgoing-owner Mon Aug 7 15:14:47 1995 Received: by psuvax1.cse.psu.edu id <33958>; Mon, 7 Aug 1995 15:03:06 -0400 Received: from plan9.att.com ([192.20.225.252]) by psuvax1.cse.psu.edu with SMTP id <33983>; Mon, 7 Aug 1995 14:57:40 -0400 From: jmk@plan9.att.com To: 9fans Date: Mon, 7 Aug 1995 14:41:25 -0400 Subject: Re: VGA problems Message-Id: <95Aug7.145740edt.33983@psuvax1.cse.psu.edu> Sender: owner-9fans Precedence: bulk Reply-To: 9fans Unfortunately the only X-24 card we had was smoked a couple of weeks ago, so I cannot verify if it works here either. Try to get the output from 'aux/vga -pv > somefile' after coming up in cga mode. >From 9fans-outgoing-owner Mon Aug 7 16:38:03 1995 Received: by colossus.cse.psu.edu id <45478>; Mon, 7 Aug 1995 16:19:53 -0400 Received: from galapagos.cse.psu.edu ([130.203.2.12]) by colossus.cse.psu.edu with SMTP id <45474>; Mon, 7 Aug 1995 16:19:37 -0400 Received: from localhost by galapagos.cse.psu.edu with SMTP id <12712>; Mon, 7 Aug 1995 16:19:29 -0400 To: 9fans Subject: Re: VGA problems In-reply-to: Your message of "Mon, 07 Aug 1995 14:02:12 EDT." <199508071802.AA20077@interlock.wdni.com> Date: Mon, 7 Aug 1995 16:19:22 -0400 From: Scott Schwartz Message-Id: <95Aug7.161929edt.12712@galapagos.cse.psu.edu> Sender: owner-9fans Precedence: bulk Reply-To: 9fans Steven Plite writes: | Again, ignore the "3D". (Maybe this stupid HP mailer is dorking my mail = | up.) It's your mail user agent. Your mail is packed up with MIME using the quoted-printable encoding. See if you can turn that off. Anyone know the official cookies for telling mime to use utf-8? >From 9fans-outgoing-owner Mon Aug 7 18:18:05 1995 Received: by colossus.cse.psu.edu id <45482>; Mon, 7 Aug 1995 18:00:18 -0400 Received: from galapagos.cse.psu.edu ([130.203.2.12]) by colossus.cse.psu.edu with SMTP id <45483>; Mon, 7 Aug 1995 17:55:55 -0400 Received: from localhost by galapagos.cse.psu.edu with SMTP id <12712>; Mon, 7 Aug 1995 17:53:03 -0400 To: 9fans Date: Mon, 7 Aug 1995 17:52:55 -0400 From: Scott Schwartz Message-Id: <95Aug7.175303edt.12712@galapagos.cse.psu.edu> Sender: owner-9fans Precedence: bulk Reply-To: 9fans Why does this happen... I run dossrv, and then exit, and the shell doesn't go away until dossrv is killed from another window. >From 9fans-outgoing-owner Mon Aug 7 19:37:36 1995 Received: by psuvax1.cse.psu.edu id <33986>; Mon, 7 Aug 1995 19:21:43 -0400 Received: from plan9.att.com ([192.20.225.252]) by psuvax1.cse.psu.edu with SMTP id <34017>; Mon, 7 Aug 1995 19:21:22 -0400 From: philw@plan9.att.com To: 9fans Date: Mon, 7 Aug 1995 19:15:25 -0400 Message-Id: <95Aug7.192122edt.34017@psuvax1.cse.psu.edu> Sender: owner-9fans Precedence: bulk Reply-To: 9fans >Why does this happen... I run dossrv, and then exit, and the shell >doesn't go away until dossrv is killed from another window. the dossrv is holding a reference to the files supplied by the window system (eg. /dev/cons). Windows are cleared up by reference counting. >From 9fans-outgoing-owner Mon Aug 7 19:40:55 1995 Received: by colossus.cse.psu.edu id <45489>; Mon, 7 Aug 1995 19:25:42 -0400 Received: from galapagos.cse.psu.edu ([130.203.2.12]) by colossus.cse.psu.edu with SMTP id <45495>; Mon, 7 Aug 1995 19:18:34 -0400 Received: from localhost by galapagos.cse.psu.edu with SMTP id <12712>; Mon, 7 Aug 1995 19:08:47 -0400 To: 9fans Date: Mon, 7 Aug 1995 19:08:40 -0400 From: Scott Schwartz Message-Id: <95Aug7.190847edt.12712@galapagos.cse.psu.edu> Sender: owner-9fans Precedence: bulk Reply-To: 9fans /dev/swap is ideosyncratic... it prints punctuation and labels, where none of the other console files do. Also, it doesn't tell you what the pagesize is. >From 9fans-outgoing-owner Mon Aug 7 20:08:20 1995 Received: by colossus.cse.psu.edu id <45511>; Mon, 7 Aug 1995 19:53:01 -0400 Received: from merlin.resmel.bhp.com.au ([134.18.1.6]) by colossus.cse.psu.edu with SMTP id <45483>; Mon, 7 Aug 1995 19:48:46 -0400 Received: from cerberus.bhpese.oz.au (cerberus.bhpese.oz.au [134.18.16.17]) by merlin.resmel.bhp.com.au (8.6.11/8.6.11) with SMTP id XAA21031 for <9fans@cse.psu.edu>; Mon, 7 Aug 1995 23:36:14 GMT Received: from nc.itntl.bhp.com.au (nc) by cerberus.bhpese.oz.au with SMTP id AA18747; Tue, 8 Aug 1995 09:36:18 +1000; sendmail 5.67a/Sm3.17RMPSU (from Sm@nc.bhpese.oz.au for 9fans@cse.psu.edu) Received: from nc.itntl.bhp.com.au by nc.itntl.bhp.com.au with ESMTP id JAA19251; Tue, 8 Aug 1995 09:36:03 +1000; sendmail 8.6.10/Sm2.1sun (from Sm@nc.itntl.bhp.com.au for <9fans@cse.psu.edu>) Message-Id: <199508072336.JAA19251@nc.itntl.bhp.com.au> To: 9fans Subject: Re: link=3Dvga; broken f.s. In-Reply-To: Your message of "Mon, 07 Aug 1995 14:30:11 -0400." <199508071830.AA21929@interlock.wdni.com> X-Face: '82~l%BnDBWVn])DV^cl_%bla$T]kNbRN&]>v{ED9[" Sender: owner-9fans Precedence: bulk Reply-To: 9fans >> splite@wdni.com's mailer seems to be using =3D as an escape (3D is `=3D='). > >Yeah. I'm going to build MH this afternoon. HP's mailx has (broken) metamail >support. (Hmmm... metamail came from BL too. Coincidence or conspiracy? :) Bell Labs != Bellcore Sm >From 9fans-outgoing-owner Mon Aug 7 20:33:25 1995 Received: by psuvax1.cse.psu.edu id <34025>; Mon, 7 Aug 1995 20:12:16 -0400 Received: from plan9.att.com ([192.20.225.252]) by psuvax1.cse.psu.edu with SMTP id <34031>; Mon, 7 Aug 1995 20:07:43 -0400 From: philw@plan9.att.com To: 9fans Date: Mon, 7 Aug 1995 19:54:42 -0400 Message-Id: <95Aug7.200743edt.34031@psuvax1.cse.psu.edu> Sender: owner-9fans Precedence: bulk Reply-To: 9fans >/dev/swap is ideosyncratic... it prints punctuation and labels, where >none of the other console files do. Also, it doesn't tell you what >the pagesize is. my fault, I put it in for debugging. It stuck. >From 9fans-outgoing-owner Mon Aug 7 22:34:01 1995 Received: by colossus.cse.psu.edu id <45508>; Mon, 7 Aug 1995 22:22:11 -0400 Received: from galapagos.cse.psu.edu ([130.203.2.12]) by colossus.cse.psu.edu with SMTP id <45509>; Mon, 7 Aug 1995 21:54:45 -0400 Received: from localhost by galapagos.cse.psu.edu with SMTP id <12712>; Mon, 7 Aug 1995 21:33:41 -0400 To: 9fans In-reply-to: Your message of "Mon, 07 Aug 1995 19:54:42 EDT." <95Aug7.200743edt.34031@psuvax1.cse.psu.edu> Date: Mon, 7 Aug 1995 21:33:26 -0400 From: Scott Schwartz Message-Id: <95Aug7.213341edt.12712@galapagos.cse.psu.edu> Sender: owner-9fans Precedence: bulk Reply-To: 9fans philw@plan9.att.com writes: | >/dev/swap is ideosyncratic... it prints punctuation and labels, where | >none of the other console files do. Also, it doesn't tell you what | >the pagesize is. | my fault, I put it in for debugging. It stuck. Naturally: the information /dev/swap gives is really useful to have. Are you amenable to adding the pagesize to the output and regularizing the format? >From 9fans-outgoing-owner Mon Aug 7 23:33:51 1995 Received: by colossus.cse.psu.edu id <45492>; Mon, 7 Aug 1995 23:13:50 -0400 Received: from galapagos.cse.psu.edu ([130.203.2.12]) by colossus.cse.psu.edu with SMTP id <45517>; Mon, 7 Aug 1995 22:52:39 -0400 Received: from localhost by galapagos.cse.psu.edu with SMTP id <12712>; Mon, 7 Aug 1995 22:10:29 -0400 To: 9fans In-reply-to: Your message of "Mon, 07 Aug 1995 19:15:25 EDT." <95Aug7.192122edt.34017@psuvax1.cse.psu.edu> Date: Mon, 7 Aug 1995 22:10:15 -0400 From: Scott Schwartz Message-Id: <95Aug7.221029edt.12712@galapagos.cse.psu.edu> Sender: owner-9fans Precedence: bulk Reply-To: 9fans philw@plan9.att.com writes: | >Why does this happen... I run dossrv, and then exit, and the shell | >doesn't go away until dossrv is killed from another window. | the dossrv is holding a reference to the files supplied by the | window system (eg. /dev/cons). Windows are cleared up by | reference counting. That sounds like a bug. But why doesn't ftpfs suffer the same symptoms? On the other hand, even sleep 10 >[0]/tmp/zz >[1]/tmp/zz >[2]/tmp/zz >[3]/tmp/zz & makes the window stick around; what files is that holding open? It should be none, right? >From 9fans-outgoing-owner Mon Aug 7 23:55:39 1995 Received: by colossus.cse.psu.edu id <45528>; Mon, 7 Aug 1995 23:39:28 -0400 Received: from staff.cs.su.OZ.AU ([129.78.8.1]) by colossus.cse.psu.edu with SMTP id <45483>; Mon, 7 Aug 1995 23:13:42 -0400 Received: from staff.cs.su.oz.au by staff.cs.su.OZ.AU (mail from matty for 9fans@cse.psu.edu) with MHSnet; Tue, 08 Aug 1995 12:50:45 +1000 To: 9fans Message-ID: <19950808124742.29379.frobozz@staff.cs.su.oz.au> In-Reply-To: <95Aug7.161929edt.12712@galapagos.cse.psu.edu> From: matty@cs.usyd.edu.au (James Matthew Farrow) Date: Mon, 7 Aug 1995 22:47:43 -0400 X-Name: James Matthew Farrow X-Mailer: Frobozz Magic Mailer [1.5] Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 840 Subject: Re: VGA problems Sender: owner-9fans Precedence: bulk Reply-To: 9fans To: 9fans@cse.psu.edu Subject: Re: VGA problems Date: Mon, 7 Aug 1995 16:19:22 -0400 From: Scott Schwartz Sender: owner-9fans@cse.psu.edu Steven Plite writes: | Again, ignore the "3D". (Maybe this stupid HP mailer is dorking my mail = | up.) It's your mail user agent. Your mail is packed up with MIME using the quoted-printable encoding. See if you can turn that off. Anyone know the official cookies for telling mime to use utf-8? I use Content-Type: text/plain; charset=unicode-1-1-utf-8 which is most `official' charset tag I have seen, however, I'm not sure it's registered so perhaps it should be X-unicode-1-1-utf-8. Unfortunately I can't remember where I picked this up now. I'll have a scout around. Matty. >From 9fans-outgoing-owner Tue Aug 8 01:15:26 1995 Received: by psuvax1.cse.psu.edu id <33986>; Tue, 8 Aug 1995 00:52:43 -0400 Received: from plan9.att.com ([192.20.225.252]) by psuvax1.cse.psu.edu with SMTP id <33958>; Tue, 8 Aug 1995 00:52:05 -0400 From: seanq@plan9.att.com To: 9fans Date: Tue, 8 Aug 1995 00:22:06 -0400 Message-Id: <95Aug8.005205edt.33958@psuvax1.cse.psu.edu> Sender: owner-9fans Precedence: bulk Reply-To: 9fans >That sounds like a bug. But why doesn't ftpfs suffer the same >symptoms? On the other hand, even > sleep 10 >[0]/tmp/zz >[1]/tmp/zz >[2]/tmp/zz >[3]/tmp/zz & >makes the window stick around; what files is that holding open? >It should be none, right? When you open a window, a new name space is created with the window's files bound in the appropriate places, i.e. /dev and /mnt/8€Ž€. These binds are in effect open file descriptors and the window will not go away until they are closed. This is why the command line sleep 10 >[0]/tmp/zz >[1]/tmp/zz >[2]/tmp/zz >[3]/tmp/zz & stops the window from closing. The namespace itself is referenced counted, so when all processes associated with the name space have exited, any open files bound in the namespace are closed. The reason the window closes even though ftpfs is running is rather subtle. When ftpfs is started, it rforks the server process with the flag RFNAMEG set. This puts the server process in a copy of the original namespace. Note that since it is a copy of the original namespace, it contains references the the window's files. The server is accessed by a pipe that is mounted in the original namespace. When /bin/rc exits, the original namespace closes. At this point, the window is held up by ftpfs's namespace. However, the original name-space contains the only reference to one end of the pipe to ftpfs, thus this end of the pipe is closed. Ftpfs notices this and dies. This closes the namespace associated with ftpfs, closing the files associated with the window, which finally allows the window to close....... The reason that the above does not occur for dossrv is that the server process is not rforked with RFNAMEG set. This is probably a bug. The net result is that rc and dossrv share the same namespace, and thus when rc exits, the namespace is not closed and hence dossrv does not die.....In effect dossrv holds itself up, which stops the window from closing. >From 9fans-outgoing-owner Tue Aug 8 02:09:25 1995 Received: by colossus.cse.psu.edu id <45482>; Tue, 8 Aug 1995 01:54:12 -0400 Received: from ncrhub1.ATTGIS.COM ([192.127.251.16]) by colossus.cse.psu.edu with SMTP id <45471>; Tue, 8 Aug 1995 01:40:43 -0400 Received: from ncrgw1 by ncrhub1.ATTGIS.COM id ab00496; 8 Aug 95 1:29 EDT Received: by ncrgw1.ATTGIS.COM; 8 Aug 95 01:26:53 EDT Received: by ncrhub4.ATTGIS.COM; 8 Aug 95 01:26:42 EDT Date: Wed, 9 Aug 1995 06:38:44 -0400 From: MAILER-DAEMON@ncrausl1.australia.NCR.COM Full-Name: Mail Router (smail 2.8.1 dl,da,fa,tu,po,qf,dbm 04/16/92 1) Subject: Returned mail To: 9fans Message-ID: <9508080129.ab00496@ncrhub1.ATTGIS.COM> Sender: owner-9fans Precedence: bulk Reply-To: 9fans Your mail could not be delivered because of the following reason: ----- Transcript of session follows ----- Executing: /usr/lib/mail/surrcmd/smtpqer -B -C -u ncrausl1.Australia.NCR.COM!ncrhub4!ncrgw1!cse.psu.edu!9fans msm2syd bduane@msm2syd smtpqer: Binary contents cannot be sent via SMTP server "/usr/lib/mail/surrcmd/smtpqer" failed - unknown mailer error 1 ----- Unsent message follows ----- >From ncrgw1!cse.psu.edu!9fans Tue Aug 8 01:26 EDT 1995 remote from ncrhub4 Received: by ncrhub4.ATTGIS.COM; 8 Aug 95 01:26:12 EDT Received: by ncrgw1.ATTGIS.COM; 8 Aug 95 01:21:54 EDT Received: by psuvax1.cse.psu.edu id <33986>; Tue, 8 Aug 1995 00:52:43 -0400 Received: from plan9.att.com ([192.20.225.252]) by psuvax1.cse.psu.edu with SMTP id <33958>; Tue, 8 Aug 1995 00:52:05 -0400 From: seanq@plan9.att.com To: 9fans@cse.psu.edu Date: Tue, 8 Aug 1995 00:22:06 -0400 Message-Id: <95Aug8.005205edt.33958@psuvax1.cse.psu.edu> Sender: owner-9fans@cse.psu.edu Precedence: bulk Reply-To: 9fans@cse.psu.edu >That sounds like a bug. But why doesn't ftpfs suffer the same >symptoms? On the other hand, even > sleep 10 >[0]/tmp/zz >[1]/tmp/zz >[2]/tmp/zz >[3]/tmp/zz & >makes the window stick around; what files is that holding open? >It should be none, right? When you open a window, a new name space is created with the window's files bound in the appropriate places, i.e. /dev and /mnt/8B=. These binds are in effect open file descriptors and the window will not go away until they are closed. This is why the command line sleep 10 >[0]/tmp/zz >[1]/tmp/zz >[2]/tmp/zz >[3]/tmp/zz & stops the window from closing. The namespace itself is referenced counted, so when all processes associated with the name space have exited, any open files bound in the namespace are closed. The reason the window closes even though ftpfs is running is rather subtle. When ftpfs is started, it rforks the server process with the flag RFNAMEG set. This puts the server process in a copy of the original namespace. Note that since it is a copy of the original namespace, it contains references the the window's files. The server is accessed by a pipe that is mounted in the original namespace. When /bin/rc exits, the original namespace closes. At this point, the window is held up by ftpfs's namespace. However, the original name-space contains the only reference to one end of the pipe to ftpfs, thus this end of the pipe is closed. Ftpfs notices this and dies. This closes the namespace associated with ftpfs, closing the files associated with the window, which finally allows the window to close....... The reason that the above does not occur for dossrv is that the server process is not rforked with RFNAMEG set. This is probably a bug. The net result is that rc and dossrv share the same namespace, and thus when rc exits, the namespace is not closed and hence dossrv does not die.....In effect dossrv holds itself up, which stops the window from closing. >From 9fans-outgoing-owner Tue Aug 8 02:25:39 1995 Received: by colossus.cse.psu.edu id <45495>; Tue, 8 Aug 1995 02:09:49 -0400 Received: from staff.cs.su.OZ.AU ([129.78.8.1]) by colossus.cse.psu.edu with SMTP id <45492>; Tue, 8 Aug 1995 02:09:05 -0400 Received: from sour.sw.oz.au by staff.cs.su.OZ.AU (mail from jeremy for 9fans@cse.psu.edu) with MHSnet (insertion MHSnet site: swallow.sw.oz.au); Tue, 08 Aug 1995 15:48:02 +1000 Received: from sour.sw.oz.au by swallow.sw.oz.au with SMTP id AA02706; Tue, 8 Aug 95 15:47:37 EST (4.1/Unixware) (from jeremy@sour.sw.oz.au for 9fans@cse.psu.edu) Received: by sour.sw.oz.au id AA11752; Tue, 8 Aug 1995 15:47:34 +1000 (5.65c/1.34) (from jeremy@sour.sw.oz.au for 9fans@cse.psu.edu) From: jeremy@sour.sw.oz.au (Jeremy Fitzhardinge) Message-Id: <199508080547.AA11752@sour.sw.oz.au> Subject: Re: #9 GXE64 support To: 9fans Date: Tue, 8 Aug 1995 01:47:34 -0400 In-Reply-To: <95Aug7.105347edt.34017@psuvax1.cse.psu.edu> from "jmk@plan9.att.com" at Aug 7, 95 09:55:53 am Organization: Softway Pty Ltd X-Face: '6U=%Tv\k1l-:?\$C[D@G 7(vl~w8&y}!f\bh#wL#n,TGKh>T.c7eT5-y)Hl'i;A1z$9?*lD.k}yqshddFb l[EC}c=;uc%x'}uh3E91p&oE my suspicion is that aux/vga is not switching over to 2x8-bit mode for the > higher clock rates when it can, we've never played with any resolution > requiring a clock between 80MHz and 135MHz. > > please post your parameters. This is how XFree86 detects my card: # XF86_S3 -probeonly (**) stands for supplied, (--) stands for probed/default values (**) Mouse: type: MouseSystems, device: /dev/mouse, baudrate: 1200 (**) S3: Graphics device ID: "#9GXE64" (**) S3: Monitor ID: "MX17FG" (**) FontPath set to "/usr/X11R6/lib/X11/fonts/75dpi/,/usr/X11R6/lib/X11/fonts/100dpi/,/usr/X11R6/lib/X11/fonts/misc/,/usr/X11R6/lib/X11/fonts/Type1/,/usr/X11R6/lib/X11/fonts/Speedo/" (**) S3: Option "number_nine" (--) S3: card type: PCI (--) S3: chipset: 864 rev. 0 (**) S3: chipset driver: mmio_928 (**) S3: videoram: 2048k (--) S3: Detected an ATT 20C498/21C498 RAMDAC (--) S3: Ramdac type: att20c498 (**) S3: Ramdac speed: 135 (**) S3: Using ICD2061A programmable clock (--) S3: Maximum allowed dot-clock: 135.000 MHz (**) S3: Mode "1184x888@100": mode clock = 100.000 (**) S3: Mode "1152x864@90": mode clock = 90.000 (**) S3: Mode "1024x768": mode clock = 75.000 (**) S3: Mode "800x600": mode clock = 50.000 (**) S3: Mode "640x480": mode clock = 25.000 (--) S3: Using 8 bits per RGB value (--) S3: Virtual resolution set to 1184x888 Here's the relevent details from /lib/vgadb: ctlr 0xC0094="#9-864" # #9GXE64 0xC0044="Phoenix S3 Vision864 (16Bit DAC)" # GIS Globalyst 550 link=vga hwgc=s3hwgc ctlr=vision864 link=ibm8514 ramdac=att21c498-135 clock=icd2061a link=s3clock # From XFree86 config file: # ModeLine "1184x888" 100 1184 1216 1576 1608 888 891 903 928 include = 1184x888@67Hz clock=100 shb=1216 ehb=1576 ht=1608 vrs=891 vre=903 vt=928 # # MAG MX17FG # Horizontal timing: # Allowable frequency range: 30-64KHz # Vertical timing: # Allowable frequency range: 50-120Hz # Video bandwidth: # 120MHz monitor mag17fg = 1184x888x8 include=1184x888@67Hz mag17fg = 1184x888x4 include=1184x888@67Hz mag17fg = 1184x888x1 include=1184x888@67Hz # ModeLine "1152x864@90" 90 1152 1184 1496 1528 864 867 876 900 #mag17fg = 1152x864x1 # clock=90 # shb=1184 ehb=1496 ht=1528 # vrs=867 vre=876 vt=900 # ModeLine "1152x864@80" 80 1152 1160 1384 1480 864 867 876 900 mag17fg = 1152x864x1 clock=80 shb=1160 ehb=1384 ht=1480 vrs=867 vre=876 vt=900 mag17fg alias=multisync75 >From 9fans-outgoing-owner Tue Aug 8 02:33:29 1995 Received: by colossus.cse.psu.edu id <45492>; Tue, 8 Aug 1995 02:25:10 -0400 Received: from ncrhub1.ATTGIS.COM ([192.127.251.16]) by colossus.cse.psu.edu with SMTP id <45470>; Tue, 8 Aug 1995 02:08:41 -0400 Received: from ncrgw1 by ncrhub1.ATTGIS.COM id ac00810; 8 Aug 95 1:42 EDT Received: by ncrgw1.ATTGIS.COM; 8 Aug 95 01:38:56 EDT Received: by ncrhub4.ATTGIS.COM; 8 Aug 95 01:38:46 EDT Date: Tue, 8 Aug 1995 01:37:31 -0400 From: MAILER-DAEMON@ncrcae.columbiasc.NCR.COM Full-Name: Mail Router (smail 2.8.1 dl,da,fa,tu,po,qf,dbm 06/12/93 6) Subject: Returned mail To: 9fans Message-ID: <9508080142.ac00810@ncrhub1.ATTGIS.COM> Sender: owner-9fans Precedence: bulk Reply-To: 9fans Your mail could not be delivered because of the following reason: ----- Transcript of session follows ----- Executing: /usr/lib/mail/surrcmd/smtpqer -C -u ncrcae.ColumbiaSC.NCR.COM!ncrhub4!ncrgw1!cse.psu.edu!9fans yesac wescott@yesac smtpqer: Binary contents cannot be sent via SMTP server "/usr/lib/mail/surrcmd/smtpqer" failed - unknown mailer error 1 ----- Unsent message follows ----- >From ncrgw1!cse.psu.edu!9fans Tue Aug 8 01:38 EDT 1995 remote from ncrhub4 Received: by ncrhub4.ATTGIS.COM; 8 Aug 95 01:38:24 EDT Received: by ncrgw1.ATTGIS.COM; 8 Aug 95 01:37:59 EDT Received: by psuvax1.cse.psu.edu id <33986>; Tue, 8 Aug 1995 00:52:43 -0400 Received: from plan9.att.com ([192.20.225.252]) by psuvax1.cse.psu.edu with SMTP id <33958>; Tue, 8 Aug 1995 00:52:05 -0400 From: seanq@plan9.att.com To: 9fans@cse.psu.edu Date: Tue, 8 Aug 1995 00:22:06 -0400 Message-Id: <95Aug8.005205edt.33958@psuvax1.cse.psu.edu> Sender: owner-9fans@cse.psu.edu Precedence: bulk Reply-To: 9fans@cse.psu.edu >That sounds like a bug. But why doesn't ftpfs suffer the same >symptoms? On the other hand, even > sleep 10 >[0]/tmp/zz >[1]/tmp/zz >[2]/tmp/zz >[3]/tmp/zz & >makes the window stick around; what files is that holding open? >It should be none, right? When you open a window, a new name space is created with the window's files bound in the appropriate places, i.e. /dev and /mnt/8B=. These binds are in effect open file descriptors and the window will not go away until they are closed. This is why the command line sleep 10 >[0]/tmp/zz >[1]/tmp/zz >[2]/tmp/zz >[3]/tmp/zz & stops the window from closing. The namespace itself is referenced counted, so when all processes associated with the name space have exited, any open files bound in the namespace are closed. The reason the window closes even though ftpfs is running is rather subtle. When ftpfs is started, it rforks the server process with the flag RFNAMEG set. This puts the server process in a copy of the original namespace. Note that since it is a copy of the original namespace, it contains references the the window's files. The server is accessed by a pipe that is mounted in the original namespace. When /bin/rc exits, the original namespace closes. At this point, the window is held up by ftpfs's namespace. However, the original name-space contains the only reference to one end of the pipe to ftpfs, thus this end of the pipe is closed. Ftpfs notices this and dies. This closes the namespace associated with ftpfs, closing the files associated with the window, which finally allows the window to close....... The reason that the above does not occur for dossrv is that the server process is not rforked with RFNAMEG set. This is probably a bug. The net result is that rc and dossrv share the same namespace, and thus when rc exits, the namespace is not closed and hence dossrv does not die.....In effect dossrv holds itself up, which stops the window from closing. >From 9fans-outgoing-owner Tue Aug 8 03:38:20 1995 Received: by psuvax1.cse.psu.edu id <34036>; Tue, 8 Aug 1995 03:19:10 -0400 Received: from plan9.cs.su.oz.au ([129.78.96.3]) by psuvax1.cse.psu.edu with SMTP id <34033>; Tue, 8 Aug 1995 03:18:07 -0400 Date: Tue, 8 Aug 1995 03:07:25 -0400 From: dhog@plan9.cs.su.oz.au To: 9fans Message-Id: <95Aug8.031807edt.34033@psuvax1.cse.psu.edu> Sender: owner-9fans Precedence: bulk Reply-To: 9fans >The namespace itself is referenced counted, so when all processes associated >with the name space have exited, any open files bound in the namespace are closed. At which point the server says ``Honey, I Clunked the Fids''. >From 9fans-outgoing-owner Tue Aug 8 04:02:00 1995 Received: by psuvax1.cse.psu.edu id <34033>; Tue, 8 Aug 1995 03:39:13 -0400 Received: from plan9.cs.su.oz.au ([129.78.96.3]) by psuvax1.cse.psu.edu with SMTP id <34045>; Tue, 8 Aug 1995 03:36:13 -0400 Date: Tue, 8 Aug 1995 03:17:32 -0400 From: dhog@plan9.cs.su.oz.au To: 9fans, postmaster@ncrcae.columbiasc.NCR.COM, postmaster@ncrausl1.australia.NCR.COM Subject: Re: Returned mail Message-Id: <95Aug8.033613edt.34045@psuvax1.cse.psu.edu> Sender: owner-9fans Precedence: bulk Reply-To: 9fans >Your mail could not be delivered because of the following reason: > > > ----- Transcript of session follows ----- >Executing: /usr/lib/mail/surrcmd/smtpqer -B -C -u ncrausl1.Australia.NCR.COM!ncrhub4!ncrgw1!cse.psu.edu!9fans msm2syd bduane@msm2syd >smtpqer: Binary contents cannot be sent via SMTP Is there any way to disable this message? Fans of Plan 9 _want_ to be able to send 8 bit (utf) characters, and most smtp agents will let them (the "cannot" in the message is patently false). If the software at NCR (sysv upas??) is going to bounce such mail, it should at least go to the envelope sender, and not the entire list. >From 9fans-outgoing-owner Tue Aug 8 09:45:02 1995 Received: by psuvax1.cse.psu.edu id <34038>; Tue, 8 Aug 1995 09:14:53 -0400 Received: from plan9.att.com ([192.20.225.252]) by psuvax1.cse.psu.edu with SMTP id <34040>; Tue, 8 Aug 1995 09:13:36 -0400 From: presotto@plan9.att.com To: 9fans Date: Tue, 8 Aug 1995 08:50:39 -0400 Subject: Re: link=3Dvga; broken f.s. Message-Id: <95Aug8.091336edt.34040@psuvax1.cse.psu.edu> Sender: owner-9fans Precedence: bulk Reply-To: 9fans Something to pipe splite's mail through: ftp://plan9.att.com/plan9/pcdist/unmime.c. The format his mail is in is mime quoted mode. Unmime, if given an argument, will unpack multipart mime messages into separate files. It's worth the price and not much more. Mime is not from Bell Labs, its from Bellcore. We're in the same state and we both have something to do with telephones but we're not the same company. The quoted mode uses = as an escape. ='s followed by cr's mean ignore the cr. ='s followed by 2 characters of hex should be replaced by the character whose value is the hex. Thus =3D is really just =. >From 9fans-outgoing-owner Tue Aug 8 10:16:39 1995 Received: by psuvax1.cse.psu.edu id <34053>; Tue, 8 Aug 1995 09:45:36 -0400 Received: from plan9.att.com ([192.20.225.252]) by psuvax1.cse.psu.edu with SMTP id <34061>; Tue, 8 Aug 1995 09:43:27 -0400 From: presotto@plan9.att.com To: 9fans Date: Tue, 8 Aug 1995 09:12:17 -0400 Message-Id: <95Aug8.094327edt.34061@psuvax1.cse.psu.edu> Sender: owner-9fans Precedence: bulk Reply-To: 9fans Unlike dossrv, ftpfs doesn't post a file in /srv. Dossrv does that since it can be mounted many times. If you removed dossrv's /srv/dos file, it too would go away since that would clunk the last reference. ------ original message follows ------ >From cse.psu.edu!9fans-outgoing-owner Mon Aug 7 23:35:50 EDT 1995 Received: by colossus.cse.psu.edu id <45492>; Mon, 7 Aug 1995 23:13:50 -0400 Received: from galapagos.cse.psu.edu ([130.203.2.12]) by colossus.cse.psu.edu with SMTP id <45517>; Mon, 7 Aug 1995 22:52:39 -0400 Received: from localhost by galapagos.cse.psu.edu with SMTP id <12712>; Mon, 7 Aug 1995 22:10:29 -0400 To: 9fans@cse.psu.edu In-reply-to: Your message of "Mon, 07 Aug 1995 19:15:25 EDT." <95Aug7.192122edt.34017@psuvax1.cse.psu.edu> Date: Mon, 7 Aug 1995 22:10:15 -0400 From: Scott Schwartz Message-Id: <95Aug7.221029edt.12712@galapagos.cse.psu.edu> Sender: owner-9fans@cse.psu.edu Precedence: bulk Reply-To: 9fans@cse.psu.edu philw@plan9.att.com writes: | >Why does this happen... I run dossrv, and then exit, and the shell | >doesn't go away until dossrv is killed from another window. | the dossrv is holding a reference to the files supplied by the | window system (eg. /dev/cons). Windows are cleared up by | reference counting. That sounds like a bug. But why doesn't ftpfs suffer the same symptoms? On the other hand, even sleep 10 >[0]/tmp/zz >[1]/tmp/zz >[2]/tmp/zz >[3]/tmp/zz & makes the window stick around; what files is that holding open? It should be none, right? >From 9fans-outgoing-owner Tue Aug 8 12:06:05 1995 Received: by colossus.cse.psu.edu id <45542>; Tue, 8 Aug 1995 11:38:50 -0400 Received: from galapagos.cse.psu.edu ([130.203.2.12]) by colossus.cse.psu.edu with SMTP id <45540>; Tue, 8 Aug 1995 11:38:33 -0400 Received: from localhost by galapagos.cse.psu.edu with SMTP id <12720>; Tue, 8 Aug 1995 11:38:06 -0400 To: 9fans cc: postmaster@ncrcae.columbiasc.ncr.com, postmaster@ncrausl1.australia.ncr.com Subject: Re: Returned mail In-reply-to: Your message of "Tue, 08 Aug 1995 03:17:32 EDT." <95Aug8.033613edt.34045@psuvax1.cse.psu.edu> Date: Tue, 8 Aug 1995 11:37:51 -0400 From: Scott Schwartz Message-Id: <95Aug8.113806edt.12720@galapagos.cse.psu.edu> Sender: owner-9fans Precedence: bulk Reply-To: 9fans dhog@plan9.cs.su.oz.au writes: | Is there any way to disable this message? Starting right now, anyone whose mailer does this will be unsubscribed from the list. >From 9fans-outgoing-owner Tue Aug 8 12:48:10 1995 Received: by colossus.cse.psu.edu id <45550>; Tue, 8 Aug 1995 12:24:26 -0400 Received: from ncrhub1.ATTGIS.COM ([192.127.251.3]) by colossus.cse.psu.edu with SMTP id <45530>; Tue, 8 Aug 1995 12:19:48 -0400 Received: from ncrcan by ncrhub1.ATTGIS.COM id aa18974; 8 Aug 95 11:36 EDT Subject: Re: Returned mail To: 9fans Date: Tue, 8 Aug 1995 11:33:01 -0400 From: Greg Nenych In-Reply-To: <95Aug8.033613edt.34045@psuvax1.cse.psu.edu>; from "dhog@plan9.cs.su.oz.au" at Aug 8, 95 3:17 am X-Mailer: ELM [version 2.3 PL11] Message-ID: <9508081136.aa18974@ncrhub1.ATTGIS.COM> Sender: owner-9fans Precedence: bulk Reply-To: 9fans >Your mail could not be delivered because of the following reason: > > ----- Transcript of session follows ----- >Executing: /usr/lib/mail/surrcmd/smtpqer -B -C -u ncrausl1.Australia.NCR.COM!ncrhub4!ncrgw1!cse.psu.edu!9fans msm2syd bduane@msm2syd >smtpqer: Binary contents cannot be sent via SMTP smtpqer is part of the stock SVR4 SMTP software. When SVR4's rmail invokes smtpqer (via mailsurr) and smtpqer gags on the message, rmail punts the message to, in this case, the address in the Reply-To: line. Sadly, the recipients don't even realize that this is happening. This is possibly a configuration issue since I am using the same(?) SMTP software and, as far as I know, messages to me have not bounced. (I receive the original message as well as the bounces) dhog@plan9.cs.su.oz.au writes: > Is there any way to disable this message? Probably. However, the offending message did not have a "Content-Length:" line or anything else to clue the mailer in to the fact that the message had non-7bit-ascii contents. > If the software at NCR (sysv upas??) is going > to bounce such mail, it should at least go to the envelope sender, and > not the entire list. Mailers have several things to choose from including "From ", "From: ", and "Reply-To: ". Do (or should) any of them use "Sender: "? Not adding the "Reply-To: 9fans@cse.psu.edu" header might make the problem go away. > Fans of Plan 9 _want_ to be able > to send 8 bit (utf) characters, and most smtp agents will let them (the "cannot" > in the message is patently false). Actually, that's 8/16 bit UTF characters depending on the encoding. This stuff will cause even more problems for netnews when, hopefully, this list will be gatewayed into comp.os.plan9. -- Greg Nenych AT&T Global Information Solutions Canada Ltd. >From 9fans-outgoing-owner Tue Aug 8 13:39:57 1995 Received: by psuvax1.cse.psu.edu id <34052>; Tue, 8 Aug 1995 13:20:12 -0400 Received: from interlock.wdni.com ([199.221.59.2]) by psuvax1.cse.psu.edu with SMTP id <34059>; Tue, 8 Aug 1995 13:13:45 -0400 Received: by interlock.wdni.com id AA01085 (InterLock SMTP Gateway 3.0 for 9fans@cse.psu.edu); Tue, 8 Aug 1995 10:03:52 -0700 Message-Id: <199508081703.AA01085@interlock.wdni.com> Received: by interlock.wdni.com (Protected-side Proxy Mail Agent-1); Tue, 8 Aug 1995 10:03:52 -0700 Date: Tue, 8 Aug 1995 13:02:48 -0400 From: Steven Plite To: 9fans Subject: Re: link=3Dvga; broken f.s. Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-9fans Precedence: bulk Reply-To: 9fans > Something to pipe splite's mail through: ftp://plan9.att.com/plan9/pcdist/unmime.c. > The format his mail is in is mime quoted mode. Unmime, if given an argument, > will unpack multipart mime messages into separate files. It's worth the price > and not much more. That shouldn't be necessary anymore. I think I have HP's mailx beaten into submission now. > Mime is not from Bell Labs, its from Bellcore. We're in the same state and > we both have something to do with telephones but we're not the same company. If I had disengaged my mouth (err... fingers) and used my brain, I would have remembered that. Obviously, it's been too long since I poked around with MIME. Sorry if anyone was insulted (like saying a Yale man went to Harvard. :) Sorry again for the confusion. _______________________________________________________________________________ Steven Plite Open Systems Eng. & Support, Weyerhaeuser "This is the roller coaster of endless and violent vomit." -- Jason Fox >From 9fans-outgoing-owner Tue Aug 8 14:07:13 1995 Received: by colossus.cse.psu.edu id <45540>; Tue, 8 Aug 1995 13:43:43 -0400 Received: from galapagos.cse.psu.edu ([130.203.2.12]) by colossus.cse.psu.edu with SMTP id <45522>; Tue, 8 Aug 1995 13:34:24 -0400 Received: from localhost by galapagos.cse.psu.edu with SMTP id <12720>; Tue, 8 Aug 1995 13:17:03 -0400 To: 9fans Subject: Re: Returned mail In-reply-to: Your message of "Tue, 08 Aug 1995 11:33:01 EDT." <9508081136.aa18974@ncrhub1.ATTGIS.COM> Date: Tue, 8 Aug 1995 13:16:48 -0400 From: Scott Schwartz Message-Id: <95Aug8.131703edt.12720@galapagos.cse.psu.edu> Sender: owner-9fans Precedence: bulk Reply-To: 9fans Greg Nenych writes: | smtpqer is part of the stock SVR4 SMTP software. But wait, it gets better... NCR Australia says: X-Mailer: Microsoft Mail V3.0 User mail received addressed to the following unknown addresses: ATTSYD/MSM2SYD/postmaster | Probably. However, the offending message did not have a "Content-Length:" | line or anything else to clue the mailer in to the fact that the message | had non-7bit-ascii contents. Naturally: It wasn't a MIME format message. Even if we slap all the mime stuff on our messages, silly mailers can sill bounce our 8 bit messages. | Actually, that's 8/16 bit UTF characters depending on the encoding. | This stuff will cause even more problems for netnews when, hopefully, this | list will be gatewayed into comp.os.plan9. No, actually it won't. C news and INN handle 8 bit messages perfectly well. The only reason internet mailers have trouble is because the folks at ietf didn't want to standardize the widely existing practice of "just send 8", thus giving authors of new mailers licence to do the wrong thing. >From 9fans-outgoing-owner Tue Aug 8 15:01:58 1995 Received: by colossus.cse.psu.edu id <45546>; Tue, 8 Aug 1995 14:42:31 -0400 Received: from kissimmee.infomkt.ibm.com ([204.146.129.20]) by colossus.cse.psu.edu with SMTP id <45522>; Tue, 8 Aug 1995 14:28:57 -0400 Received: from dingler.dev.infomkt.ibm.com (dingler.dev.infomkt.ibm.com [204.146.132.31]) by kissimmee.infomkt.ibm.com (8.6.10/8.6.10) with ESMTP id OAA19862 for <9fans@cse.psu.edu>; Tue, 8 Aug 1995 14:15:57 -0400 Received: (from quanstro@localhost) by dingler.dev.infomkt.ibm.com (8.6.10/8.6.10) id NAA33960 for 9fans@cse.psu.edu; Tue, 8 Aug 1995 13:04:49 -0400 Date: Tue, 8 Aug 1995 13:04:49 -0400 From: goon Message-Id: <199508081704.NAA33960@dingler.dev.infomkt.ibm.com> Warning: alias database /etc/aliases.pag out of date To: 9fans Subject: utf --- as long as you're being picky Sender: owner-9fans Precedence: bulk Reply-To: 9fans >> Fans of Plan 9 _want_ to be able >> to send 8 bit (utf) characters, and most smtp agents will let them (the "cannot" >> in the message is patently false). >Actually, that's 8/16 bit UTF characters depending on the encoding. >This stuff will cause even more problems for netnews when, hopefully, this >list will be gatewayed into comp.os.plan9. as long as you're going to get technical, plan 9 uses only one encoding of unicode which is fss-utf-8 (called fss-utf-2 in some plan 9 papers) it uses either 1, 2 or 3 bytes per character. >From 9fans-outgoing-owner Tue Aug 8 15:57:53 1995 Received: by colossus.cse.psu.edu id <45573>; Tue, 8 Aug 1995 15:31:36 -0400 Received: from glenlivet.ohm.york.ac.uk ([144.32.136.21]) by colossus.cse.psu.edu with SMTP id <45640>; Tue, 8 Aug 1995 15:11:57 -0400 Received: from talisker.ohm.york.ac.uk ([144.32.136.89]) by glenlivet.ohm.york.ac.uk with smtp id m0sftvY-0004fGC (/\##/\ Smail3.1.30.10 #30.21); Tue, 8 Aug 95 20:03:00 +0100 (BST) Message-Id: Received: by talisker.ohm.york.ac.uk (NX5.67e/NX3.0X) id AA01842; Tue, 8 Aug 95 19:59:45 +0100 Content-Type: text/plain Mime-Version: 1.0 (NeXT Mail 3.3 v118.2) Received: by NeXT.Mailer (1.118.2) From: Roger Peppe Date: Tue, 8 Aug 1995 14:59:42 -0400 To: 9fans Subject: mouse quirk References: <95Aug8.091336edt.34040@psuvax1.cse.psu.edu> Sender: owner-9fans Precedence: bulk Reply-To: 9fans a small problem with our (serial) mouse. it works fine except the middle button doesn't work; the right button sometimes acts as the middle button, and sometimes as itself (opening /dev/mouse sometimes switches it from one to the other - bizarre...) is this likely to be because of an unknown mouse type (aux/mouse doesn't complain) or something more arcane ? (the same problem occurs with two mice of the same sort) on an unrelated note, what's the status of the CDA tools with respect to the current release - are they available under a separate license ? thanks, rog. >From 9fans-outgoing-owner Tue Aug 8 17:01:13 1995 Received: by psuvax1.cse.psu.edu id <34064>; Tue, 8 Aug 1995 16:42:09 -0400 Received: from plan9.att.com ([192.20.225.252]) by psuvax1.cse.psu.edu with SMTP id <34059>; Tue, 8 Aug 1995 16:41:37 -0400 From: jmk@plan9.att.com To: 9fans Date: Tue, 8 Aug 1995 16:26:51 -0400 Subject: Re: #9 GXE64 support Message-Id: <95Aug8.164137edt.34059@psuvax1.cse.psu.edu> Sender: owner-9fans Precedence: bulk Reply-To: 9fans i've lowered the threshold at which the att21x498 ramdac decides to use 2x8-bit mode which should fix the problem. there's a new aux/vga and vgadb available in the pcdist directory for pick-up by ftp. use at your own risk (i'd keep a copy of the old one around...). there are some other changes in the new version: support for #9GXE64pro; add trivial ctlr entry for att20c490 ramdac and tweak ramdac 'magic access' code; lower threshold at which att21c498 will use 2x8-bit mode to > 80MHz; add "-e" and "-k tables for the Chrontel CH9294 clock generator and look for clock-divisors on the CH9294 and ICS2494 if asked for (ET4000); change BIOS id string for the Hercules Dynamite Power PCI and add ctlr entry for the ISA version. >From 9fans-outgoing-owner Tue Aug 8 17:35:29 1995 Received: by psuvax1.cse.psu.edu id <34059>; Tue, 8 Aug 1995 17:18:38 -0400 Received: from plan9.cs.york.ac.uk ([144.32.32.195]) by psuvax1.cse.psu.edu with SMTP id <34067>; Tue, 8 Aug 1995 17:16:53 -0400 From: forsyth@plan9.cs.york.ac.uk Date: Tue, 8 Aug 1995 16:39:16 -0400 To: 9fans@cs.psu.edu subject: pc file server kernel: caveats Message-Id: <95Aug8.171653edt.34067@psuvax1.cse.psu.edu> Sender: owner-9fans Precedence: bulk Reply-To: 9fans the pc file server kernel's ether509 driver needs similar changes to /sys/src/9/pc/ether509.c: specifically, it needs to loop until there aren't any more interrupts waiting. otherwise, under load it can suddenly stop seeing further interrupts and things time out. i have the impression that this is more likely to happen with the newer 3c509b than with the original 3c509. the pc file server decides my 16 Mbyte AMD486dx4/100 (no-obvious-name clone) motherboard has 256 Mbytes (would be nice). not surprisingly, it then blows up in iobufinit. i've no idea what the m/board is doing that causes the probe not to detect that the memory subsystem has wrapped the addresses; perhaps this board doesn't do the usual thing. it's happy if the probe is limited to 128 Mbytes. >From 9fans-outgoing-owner Tue Aug 8 20:22:53 1995 Received: by colossus.cse.psu.edu id <45552>; Tue, 8 Aug 1995 20:08:44 -0400 Received: from noao.edu ([140.252.1.54]) by colossus.cse.psu.edu with SMTP id <45548>; Tue, 8 Aug 1995 20:08:28 -0400 Received: from gemini.tuc.noao.edu by noao.edu (4.1/SAG-Noao.G102) id AA24778; Tue, 8 Aug 95 17:08:04 MST; for 9fans@cse.psu.edu Received: from daikon.tuc.noao.edu.noao by gemini.tuc.noao.edu (4.1/SAG.sat.14) id AA16061; Tue, 8 Aug 95 17:08:05 MST; for 9fans@cse.psu.edu Received: by daikon.tuc.noao.edu.noao (4.1/SAG.sun.8) id AA01643; Tue, 8 Aug 95 17:08:04 MST; for 9fans@cse.psu.edu Date: Tue, 8 Aug 1995 20:08:04 -0400 From: rwolff@noao.edu (Richard Wolff) Message-Id: <9508090008.AA01643@daikon.tuc.noao.edu.noao> To: 9fans Subject: ATI video controller Sender: owner-9fans Precedence: bulk Reply-To: 9fans I have an ATI Mach32 video board that only seems to work in the basic 640x480 mode. I have a similar, but newer, ATI board at home that worked right away, so it's not that the ATI support in aux/vga and /lib/vgadb is all wrong. The problem board is a couple years old, clearly a mach32 board with a ics2494AM clock chip (but a BCT245 chip I take to be the ramdac). At 800x600 and higher res, the screen is looks very much like the timing is all wrong---patterns of dots/lines that repeat every so often and are aligned vertically along a diagonal. I've added a clock=ics2494a to no avail. The reason I'm appealing to the mailing list rather than spending (quite some) time trying timing parameters is that the fact that aux/vga always comes up with "controller not in /lib/vgadb" even though it clearly is (and correctly so and at the correct 0xC0085 for LOCAL BUS ATI ULTRA PRO which happens as well to match the original 0xC008F ATI ULTRA PRO ). Does anyone know if the "controller not in lib/vgadb" message can mean, "yes, the controller is in the db, but I'm not happy with your description of it"? BTW, for the "what models work", my Gateway at home is a 4DX2-66V with an ATI Mach32 VLB video board and two 405MB IDE drives (and SB-16 and CDROM which are untried with the 4 disk floppy distribution). >From 9fans-outgoing-owner Tue Aug 8 23:06:29 1995 Received: by colossus.cse.psu.edu id <45563>; Tue, 8 Aug 1995 22:55:04 -0400 Received: from mailgw.claircom.com ([199.5.241.51]) by colossus.cse.psu.edu with SMTP id <45562>; Tue, 8 Aug 1995 22:51:31 -0400 Received: from nimo.claircom.com by mailgw.claircom.com with smtp (Smail3.1.26.7 #2) id m0sg1Eh-0004teC; Tue, 8 Aug 95 19:51 PDT Received: by nimo.claircom.com (Smail3.1.26.7 #2) id m0sg1Eh-0005YlC; Tue, 8 Aug 95 19:51 PDT Message-Id: Date: Tue, 8 Aug 1995 22:51:00 -0400 From: fst@claircom.com (Fariborz Skip Tavakkolian) To: 9fans Subject: What causes ``panic: ataintr: read/ident'' in 9DOS? Sender: owner-9fans Precedence: bulk Reply-To: 9fans I am having trouble installing the 3 dis[ck] demo set; This is a Toshiba T2450CT laptop (75MHz i486DX4, 8MB, TFT VGA, 320MB IDE, and AccuPoint). The problem occurs on the first dis[ck] when B.COM is invoked on the A: drive. B.COM seems to find, load, and run 9DOS. Here is what it says: 1269 free pages, 5076K bytes, swap 32596K, highwater 252K, headroom 312K CPU is a 74 MHz IntelDX4 (cpuid: ax 480 dx 3) pcmcia controller0 is a 1 slot Cirrus Logic PD6710 fs...time...panic: ataintr: read/ident exiting Any ideas? P.S. (1) An older Toshiba (T4600) installation of the demo set was successful. (2) For the troubled T2450CT, I followed the instructions in the ``Read this section if you have trouble installing on the PC'' section, and got the same result. >From 9fans-outgoing-owner Tue Aug 8 23:12:53 1995 Received: by psuvax1.cse.psu.edu id <34076>; Tue, 8 Aug 1995 23:02:05 -0400 Received: from plan9.att.com ([192.20.225.252]) by psuvax1.cse.psu.edu with SMTP id <34075>; Tue, 8 Aug 1995 23:01:48 -0400 From: jmk@plan9.att.com To: 9fans Date: Tue, 8 Aug 1995 22:17:16 -0400 Subject: re: ATI video controller Message-Id: <95Aug8.230148edt.34075@psuvax1.cse.psu.edu> Sender: owner-9fans Precedence: bulk Reply-To: 9fans > board with a ics2494AM clock chip (but a BCT245 chip I take to be the ramdac). the clock chip may be made by ICS but it contains an ATI specific table of frequencies. there are, according to ATI, 3 possible clock chips on the mach32 which they call the 18811-[012] and i have seen a board with a clock-chip so labelled. the -[12] chips have the same table. since i can't tell what the chip type is from software, the mach32 part of aux/vga has a truncated table of frequencies whose entries match on all the chips: 25175000, 32000000, 40000000, 44900000, 65000000, 75000000 these frequencies match the common resolutions up to 1024x768. anything higher on the mach32/64 requires using the accelerator and possibly programming the ramdac (this would be a good thing to have as the mach64 is quite a zippy chip, hint). > The reason I'm appealing to the mailing list rather than spending (quite some) > time trying timing parameters is that the fact that aux/vga > always comes up with "controller not in /lib/vgadb" even though it > clearly is (and correctly so and at the correct 0xC0085 for > LOCAL BUS ATI ULTRA PRO which happens as well to match the original > 0xC008F ATI ULTRA PRO ). > Does anyone know if the "controller not in lib/vgadb" message can mean, > "yes, the controller is in the db, but I'm not happy with your description > of it"? no, it just means it couldn't find a matching address/string in the BIOS. this is surprising given what you say. let's see the output of 'aux/vga -vp>somefile'. >From 9fans-outgoing-owner Tue Aug 8 23:46:51 1995 Received: by psuvax1.cse.psu.edu id <34077>; Tue, 8 Aug 1995 23:36:17 -0400 Received: from plan9.att.com ([192.20.225.252]) by psuvax1.cse.psu.edu with SMTP id <34079>; Tue, 8 Aug 1995 23:33:50 -0400 From: jmk@plan9.att.com To: 9fans Date: Tue, 8 Aug 1995 23:20:57 -0400 Subject: Re: What causes ``panic: ataintr: read/ident'' in 9DOS? Message-Id: <95Aug8.233350edt.34079@psuvax1.cse.psu.edu> Sender: owner-9fans Precedence: bulk Reply-To: 9fans boot dos and execute 'a:\b hd!0'. this will show if b.com has the same problem (it won't touch the hard disc if it detects there's a floppy installed). also, b.com has a debugging print installed for this case. it may be something like the cmos indicates there is a hard disc but the disc/controller is in some sleep mode we don't know how to get out of. >From 9fans-outgoing-owner Wed Aug 9 01:17:51 1995 Received: by colossus.cse.psu.edu id <45564>; Wed, 9 Aug 1995 00:59:48 -0400 Received: from fegmania.wustl.edu ([128.252.120.11]) by colossus.cse.psu.edu with SMTP id <45568>; Wed, 9 Aug 1995 00:59:27 -0400 Received: (from bryan@localhost) by fegmania.wustl.edu (8.6.11/8.6.11) id XAA21858 for 9fans@cse.psu.edu; Tue, 8 Aug 1995 23:58:19 -0500 Date: Wed, 9 Aug 1995 00:58:19 -0400 From: "bryan d. o'connor" Message-Id: <199508090458.XAA21858@fegmania.wustl.edu> To: 9fans Subject: help -- 486/33, adaptec scsi, dies on extract of disk2.vd Content-Length: 648 Sender: owner-9fans Precedence: bulk Reply-To: 9fans I'm trying to install onto a 486/33 with an Adaptec SCSI controller. It seems to install disk1 just fine. After running plan9\b.com and choosing "install from 3 disks", it starts to extract from the second disk and then dies with the message: /bin/rc The error was: rc 30:vdexpand 31:fail | Press any key to continue... the "extract" window has: /n/kfs/... /n/kfs/386/b.com /n/kfs/386/9pcdisk out-of-sync expansion failed disk/mdex I have tried new copies of disk 2. I am running Windows 95 on the machine... but it failed the same way when booting off of DOS 5.0 disks. ...bryan >From 9fans-outgoing-owner Wed Aug 9 02:53:33 1995 Received: by colossus.cse.psu.edu id <45579>; Wed, 9 Aug 1995 02:26:46 -0400 Received: from mail1.eworld.com ([192.215.65.17]) by colossus.cse.psu.edu with SMTP id <45568>; Wed, 9 Aug 1995 02:26:30 -0400 Received: from newton.apple.com by hp1.online.apple.com with SMTP (1.37.109.16/16.2) id AA238469573; Tue, 8 Aug 1995 23:26:13 -0700 Received: from [17.205.28.27] by newton.apple.com (4.1/SMI-4.1) id AA19677; Tue, 8 Aug 95 23:26:09 PDT Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 9 Aug 1995 03:26:08 -0400 To: 9fans From: wrs@newton.apple.com (Walter Smith) Subject: Re: help -- 486/33, adaptec scsi, dies on extract of disk2.vd Sender: owner-9fans Precedence: bulk Reply-To: 9fans > /bin/rc > The error was: > rc 30:vdexpand 31:fail | > Press any key to continue... I have the same problem (but the exact message varies) on a Dell Optiplex 486/66 with Adaptec 1542 controller. - W --------------------------------------------------------------- Walter Smith Internet: wrs@apple.com Newton Software AppleLink: WALTER.SMITH Apple Computer, Inc. +1 408 974 5892 >From 9fans-outgoing-owner Wed Aug 9 03:19:46 1995 Received: by psuvax1.cse.psu.edu id <34088>; Wed, 9 Aug 1995 03:02:13 -0400 Received: from plan9.cs.su.oz.au ([129.78.96.3]) by psuvax1.cse.psu.edu with SMTP id <34087>; Wed, 9 Aug 1995 03:00:32 -0400 Date: Wed, 9 Aug 1995 02:59:10 -0400 From: dhog@plan9.cs.su.oz.au To: 9fans Subject: Re: Returned mail Message-Id: <95Aug9.030032edt.34087@psuvax1.cse.psu.edu> Sender: owner-9fans Precedence: bulk Reply-To: 9fans Greg Nenych wrote: >Mailers have several things to choose from including "From ", "From: ", and >"Reply-To: ". Do (or should) any of them use "Sender: "? No. Note that "From: " and "Reply-To: " are there for the user agent. Bounce messages should never be sent based on these headers. Rather, they should use the SMTP "envelope sender" (yes, I'm assuming we're talking SMTP here). This is frequently stored in the Unix "From " header (YMMV). Some software may put it in the "Return-Path: " header. Mailing list exploders set the envelope sender to the list maintainer, so that bounces go back to the one person able to do anything about them (eg unsubscribe them). Some software throws away the envelope sender and uses the rfc822 From: header instead. This is very bad. It can cause mail loops, resulting in many many bounce messages in everyone's mail box (this has happened on 9fans). A lesser sin is for the mail user agent to generate replies based on the envelope sender. This is usually easier to fix/work around (just replace the user agent :-). >> Fans of Plan 9 _want_ to be able >> to send 8 bit (utf) characters, and most smtp agents will let them (the "cannot" >> in the message is patently false). > >Actually, that's 8/16 bit UTF characters depending on the encoding. I meant full 8 bit chars as opposed to 7 bit ascii... Anyway, enough about mail. Back to Plan 9! >From 9fans-outgoing-owner Wed Aug 9 03:39:57 1995 Received: by psuvax1.cse.psu.edu id <34089>; Wed, 9 Aug 1995 03:22:50 -0400 Received: from plan9.cs.su.oz.au ([129.78.96.3]) by psuvax1.cse.psu.edu with SMTP id <34090>; Wed, 9 Aug 1995 03:19:02 -0400 Date: Wed, 9 Aug 1995 03:04:59 -0400 From: dhog@plan9.cs.su.oz.au To: 9fans Subject: Deadlock in fileserver lance driver Message-Id: <95Aug9.031902edt.34090@psuvax1.cse.psu.edu> Sender: owner-9fans Precedence: bulk Reply-To: 9fans I have encountered a deadlock in the lance driver for the fileserver kernel. It seems to be aggravated by our slow jukebox :-) Anyway, here is my fix (a similar change should be made to the other fs kernels). diff /n/dump/1995/0806/sys/src/fs/ss/lance.c /sys/src/fs/ss/lance.c 212a213 > qunlock(c); 213a215 > qlock(c); 215a218 > qunlock(c); 216a220 > qlock(c); >From 9fans-outgoing-owner Wed Aug 9 03:58:45 1995 Received: by colossus.cse.psu.edu id <45583>; Wed, 9 Aug 1995 03:44:24 -0400 Received: from symbionics.co.uk ([158.43.6.17]) by colossus.cse.psu.edu with SMTP id <45582>; Wed, 9 Aug 1995 03:44:07 -0400 Received: from sympc143 ([194.32.100.46]) by symbionics.co.uk (4.1/SMI-4.1) id AA04527; Wed, 9 Aug 95 08:43:10 BST Message-Id: <9508090743.AA04527@symbionics.co.uk> Comments: Authenticated sender is From: "Nigel Roles" Organization: Symbionics Communications To: 9fans Date: Wed, 9 Aug 1995 04:43:07 -0400 Subject: Re: help -- 486/33, adaptec scsi, dies on extract of disk2. Priority: normal X-Mailer: Pegasus Mail for Windows (v2.01) Sender: owner-9fans Precedence: bulk Reply-To: 9fans > > /bin/rc > > The error was: > > rc 30:vdexpand 31:fail | > > Press any key to continue... > > I have the same problem (but the exact message varies) on a Dell Optiplex > 486/66 with Adaptec 1542 controller. > This is a DMA overrun on the floppy controller, caused by the disk cache flushing to the HD as vdexpand goes to the floppy for the next chunk. For reasons I don't yet understand, the floppy controller cannot seize the bus in time. Both the FreeBSD and Linux floppy drivers have a "retry forever on DMA overrun" strategy, and change comments saying "fixed the DMA overrun bug". Anyone out there know why this is such a problem? Anyhow, I had exactly the same problem with a similar 1542 based system, so I bought an IDE drive. I still had the problem; at least I'm sure I did; now I'm not so sure since two more people are reporting it with an Adaptec 1542. Solutions? 1. At least one person I know patched the binary of 9dos so that it loads the images from "/n/c:/disk*.vd" not " /n/a:/disk*.vd". He said that the floppy still needed to be in the drive, but it read from c:. That was on an AMD 386/40 with an Adaptec 1542. 2. Wait till the CD-ROM release! >From 9fans-outgoing-owner Wed Aug 9 04:14:42 1995 Received: by psuvax1.cse.psu.edu id <34094>; Wed, 9 Aug 1995 03:56:25 -0400 Received: from cegelecproj.co.uk ([159.245.72.6]) by psuvax1.cse.psu.edu with SMTP id <34090>; Wed, 9 Aug 1995 03:53:48 -0400 Received: from vampire.cegelecproj.co.uk (cerberus.cegelecproj.co.uk) by cegelecproj.co.uk (4.1/SMI-4.1) id AA05140; Wed, 9 Aug 95 08:49:21 BST Received: from phantom.cegelecproj.co.uk (phantom.limbo.cegelecproj.co.uk) by vampire.cegelecproj.co.uk (5.0/SMI-SVR4) id AA02533; Wed, 9 Aug 1995 08:49:18 +0100 Received: from phantom (localhost) by phantom.cegelecproj.co.uk (5.0/SMI-SVR4) id AA26238; Wed, 9 Aug 1995 08:49:15 +0100 Message-Id: <9508090749.AA26238@phantom.cegelecproj.co.uk> To: 9fans Subject: Re: mouse quirk In-Reply-To: Your message of "Tue, 08 Aug 1995 14:59:42 EDT." Date: Wed, 9 Aug 1995 03:49:13 -0400 From: Steve_Kilbane Content-Length: 523 Sender: owner-9fans Precedence: bulk Reply-To: 9fans Bawr. Boo, hiss. I'm coming to the conclusion that the crappy Dell 316SX i've got here just isn't compatible, somehow. I can get it to boot in text mode ok, but the vga stuff just won't work, even in 640x480x1. And we've tried three video cards in it now (the on-board Paradise one, a Video Seven and a Trident). We've added each to vgadb as a simple card, by putting an address and string under the "Don't know enough" entry, but still no dice. The damn thing just hangs, every time. Sigh. It's good, then, is it? steve >From 9fans-outgoing-owner Wed Aug 9 06:21:26 1995 Received: by colossus.cse.psu.edu id <45546>; Wed, 9 Aug 1995 06:04:26 -0400 Received: from hal ([192.102.161.37]) by colossus.cse.psu.edu with SMTP id <45542>; Wed, 9 Aug 1995 06:04:09 -0400 Received: from nil.do.isst.fhg.de (nil.do.isst.fhg.de [192.102.161.34]) by hal (8.6.9/8.6.9) with ESMTP id MAA18912 for <9fans@cse.psu.edu>; Wed, 9 Aug 1995 12:07:22 +0200 From: Dirk Vleugels Received: (vleugels@localhost) by nil.do.isst.fhg.de (8.6.9/8.6.9) id MAA09347; Wed, 9 Aug 1995 12:07:04 +0200 Date: Wed, 9 Aug 1995 06:07:04 -0400 Message-Id: <199508091007.MAA09347@nil.do.isst.fhg.de> To: 9fans Subject: No more mails? Sender: owner-9fans Precedence: bulk Reply-To: 9fans Hello. I get no more 9fans mails. I lost an account, but i'm not sure if it was subscribed to 9fans (excessive use of .forward :(). So: - There is no more traffic? - Mails are bouncing from vleugels@oslo.informatik.uni-dortmund.de If so, please change the adress to vleugels@do.isst.fhg.de Sorry for all bogus mails, Dirk "It's 206 ms to Chicago, we've got a full disk of GIFs, half a meg of hypertext, it's dark, and we're wearing sunglasses." "Click it." -- >From 9fans-outgoing-owner Wed Aug 9 07:39:31 1995 Received: by colossus.cse.psu.edu id <45550>; Wed, 9 Aug 1995 07:20:38 -0400 Received: from plan9.att.com ([192.20.225.252]) by colossus.cse.psu.edu with SMTP id <45540>; Wed, 9 Aug 1995 07:20:22 -0400 From: presotto@plan9.att.com To: 9fans Date: Wed, 9 Aug 1995 07:17:09 -0400 Subject: Re: help -- 486/33, adaptec scsi, dies on extract of disk2.vd Message-Id: <95Aug9.072022edt.45540@colossus.cse.psu.edu> Sender: owner-9fans Precedence: bulk Reply-To: 9fans I'll make a new version of disk1 with a 9dos containing the DMA fix. I'll post to 9fans when I've done it. ------ original message follows ------ >From cse.psu.edu!9fans-outgoing-owner Wed Aug 9 02:59:44 EDT 1995 Received: by colossus.cse.psu.edu id <45579>; Wed, 9 Aug 1995 02:26:46 -0400 Received: from mail1.eworld.com ([192.215.65.17]) by colossus.cse.psu.edu with SMTP id <45568>; Wed, 9 Aug 1995 02:26:30 -0400 Received: from newton.apple.com by hp1.online.apple.com with SMTP (1.37.109.16/16.2) id AA238469573; Tue, 8 Aug 1995 23:26:13 -0700 Received: from [17.205.28.27] by newton.apple.com (4.1/SMI-4.1) id AA19677; Tue, 8 Aug 95 23:26:09 PDT Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 9 Aug 1995 03:26:08 -0400 To: 9fans@cse.psu.edu From: wrs@newton.apple.com (Walter Smith) Subject: Re: help -- 486/33, adaptec scsi, dies on extract of disk2.vd Sender: owner-9fans@cse.psu.edu Precedence: bulk Reply-To: 9fans@cse.psu.edu > /bin/rc > The error was: > rc 30:vdexpand 31:fail | > Press any key to continue... I have the same problem (but the exact message varies) on a Dell Optiplex 486/66 with Adaptec 1542 controller. - W --------------------------------------------------------------- Walter Smith Internet: wrs@apple.com Newton Software AppleLink: WALTER.SMITH Apple Computer, Inc. +1 408 974 5892 >From 9fans-outgoing-owner Wed Aug 9 09:54:07 1995 Received: by colossus.cse.psu.edu id <45466>; Wed, 9 Aug 1995 09:31:11 -0400 Received: from plan9.att.com ([192.20.225.252]) by colossus.cse.psu.edu with SMTP id <45464>; Wed, 9 Aug 1995 09:30:49 -0400 From: presotto@plan9.att.com To: 9fans Date: Wed, 9 Aug 1995 09:03:54 -0400 Subject: What causes ``panic: ataintr: read/ident'' in 9DOS? Message-Id: <95Aug9.093049edt.45464@colossus.cse.psu.edu> Sender: owner-9fans Precedence: bulk Reply-To: 9fans It means that after getting an interrupt from the hard disk we didn't see it come ready or announce an error in a timely fashion. Try copying b.com and 9dos (under DOS) to c:\ and then running c:\> b hd!0!9dos to see if at least the driver in b.com can understand the disk. If this doesn't work, I can always make a more informative 9dos to try to track down the problem. >From 9fans-outgoing-owner Wed Aug 9 10:39:13 1995 Received: by psuvax1.cse.psu.edu id <34057>; Wed, 9 Aug 1995 10:10:31 -0400 Received: from nixpbe.pdb.sni.de ([192.109.2.33]) by psuvax1.cse.psu.edu with SMTP id <34056>; Wed, 9 Aug 1995 10:09:41 -0400 Received: (from nerv@localhost) by nixpbe.pdb.sni.de (8.6.12/8.6.12) id QAA06985 for 9fans@cse.psu.edu; Wed, 9 Aug 1995 16:06:40 +0200 Message-Id: <199508091406.QAA06985@nixpbe.pdb.sni.de> Subject: unsubscribe To: 9fans Date: Wed, 9 Aug 1995 12:05:45 -0400 From: suhr X-Mailer: xmail 2.4 (based on ELM 2.2 PL16) Sender: owner-9fans Precedence: bulk Reply-To: 9fans unsubscribe >From 9fans-outgoing-owner Wed Aug 9 11:35:33 1995 Received: by colossus.cse.psu.edu id <45466>; Wed, 9 Aug 1995 11:14:56 -0400 Received: from plan9.att.com ([192.20.225.252]) by colossus.cse.psu.edu with SMTP id <45464>; Wed, 9 Aug 1995 11:12:26 -0400 From: jmk@plan9.att.com To: 9fans Date: Wed, 9 Aug 1995 10:55:14 -0400 Subject: re: Deadlock in fileserver lance driver Message-Id: <95Aug9.111226edt.45464@colossus.cse.psu.edu> Sender: owner-9fans Precedence: bulk Reply-To: 9fans I'm not sure what the locks are doing there at all, I don't know what they are protecting. The magnum fs kernel was cloned from the power kernel on March 13 1992 and the power kernel had the locks in at that time. They disappeared from the power kernel on May 15th 1992. The sparc kernel was cloned from the magnum kernel on August 16th 1992 and /sys/src/fs/ss/lance.c has not changed since. ------ original message follows ------ >From cse.psu.edu!9fans-outgoing-owner Wed Aug 9 03:40:18 EDT 1995 Received: by psuvax1.cse.psu.edu id <34089>; Wed, 9 Aug 1995 03:22:50 -0400 Received: from plan9.cs.su.oz.au ([129.78.96.3]) by psuvax1.cse.psu.edu with SMTP id <34090>; Wed, 9 Aug 1995 03:19:02 -0400 Date: Wed, 9 Aug 1995 03:04:59 -0400 From: dhog@plan9.cs.su.oz.au To: 9fans@cse.psu.edu Subject: Deadlock in fileserver lance driver Message-Id: <95Aug9.031902edt.34090@psuvax1.cse.psu.edu> Sender: owner-9fans@cse.psu.edu Precedence: bulk Reply-To: 9fans@cse.psu.edu I have encountered a deadlock in the lance driver for the fileserver kernel. It seems to be aggravated by our slow jukebox :-) Anyway, here is my fix (a similar change should be made to the other fs kernels). diff /n/dump/1995/0806/sys/src/fs/ss/lance.c /sys/src/fs/ss/lance.c 212a213 > qunlock(c); 213a215 > qlock(c); 215a218 > qunlock(c); 216a220 > qlock(c); >From 9fans-outgoing-owner Wed Aug 9 12:07:48 1995 Received: by colossus.cse.psu.edu id <45473>; Wed, 9 Aug 1995 11:46:59 -0400 Received: from alpha.xerox.com ([13.1.64.93]) by colossus.cse.psu.edu with SMTP id <45495>; Wed, 9 Aug 1995 11:43:56 -0400 Received: from reynaldo.parc.xerox.com ([13.2.116.96]) by alpha.xerox.com with SMTP id <15387(3)>; Wed, 9 Aug 1995 08:28:04 PDT Received: from localhost by reynaldo.parc.xerox.com with SMTP id <34950>; Wed, 9 Aug 1995 08:28:01 -0700 To: 9fans cc: kerch@parc.xerox.com Subject: Re: help -- 486/33, adaptec scsi, dies on extract of disk2.vd In-reply-to: Your message of "Wed, 09 Aug 95 00:26:08 PDT." Date: Wed, 9 Aug 1995 11:27:55 -0400 From: Berry Kercheval Message-Id: <95Aug9.082801pdt.34950@reynaldo.parc.xerox.com> Sender: owner-9fans Precedence: bulk Reply-To: 9fans >>>Walter Smith said: > > /bin/rc > > The error was: > > rc 30:vdexpand 31:fail | > > Press any key to continue... > > I have the same problem (but the exact message varies) on a Dell Optiplex > 486/66 with Adaptec 1542 controller. I had it too -- remember, rob? -- But I'll have to go back to the office and check the hardware in that computer. --berry Berry Kercheval :: Xerox Palo Alto Research Center >From 9fans-outgoing-owner Wed Aug 9 13:30:29 1995 Received: by colossus.cse.psu.edu id <45476>; Wed, 9 Aug 1995 13:09:26 -0400 Received: from alpha.xerox.com ([13.1.64.93]) by colossus.cse.psu.edu with SMTP id <45467>; Wed, 9 Aug 1995 13:09:08 -0400 Received: from reynaldo.parc.xerox.com ([13.2.116.96]) by alpha.xerox.com with SMTP id <15140(5)>; Wed, 9 Aug 1995 10:08:42 PDT Received: from localhost by reynaldo.parc.xerox.com with SMTP id <34950>; Wed, 9 Aug 1995 10:08:39 -0700 X-Mailer: exmh version 1.6.1 5/23/95 To: 9fans cc: kerch@parc.xerox.com Subject: Re: help -- 486/33, adaptec scsi, dies on extract of disk2. In-reply-to: Your message of "Wed, 09 Aug 95 01:43:07 PDT." <9508090743.AA04527@symbionics.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 9 Aug 1995 13:08:37 -0400 From: Berry Kercheval Message-Id: <95Aug9.100839pdt.34950@reynaldo.parc.xerox.com> Sender: owner-9fans Precedence: bulk Reply-To: 9fans l>>>"Nigel Roles" said: > Solutions? > > 1. ... patch .. binary of 9dos so that it loads the images from > "/n/c:/disk*.vd" not " /n/a:/disk*.vd". > > 2. Wait till the CD-ROM release! 3. Apparently you can fetch a BIOS upgrade for the AHA-1542 from Adaptec's Web site. One of our sysadmins here reports that this enabled him to run Linuxm with no problems. You'll need a prom burner and access to: http://www.adaptec.com/techsupp/bbs_eprm.htm If I try this myself I'll report what happens. --berry Berry Kercheval :: Xerox Palo Alto Research Center >From 9fans-outgoing-owner Wed Aug 9 13:46:15 1995 Received: by colossus.cse.psu.edu id <45485>; Wed, 9 Aug 1995 13:32:38 -0400 Received: from glenlivet.ohm.york.ac.uk ([144.32.136.21]) by colossus.cse.psu.edu with SMTP id <45484>; Wed, 9 Aug 1995 13:32:22 -0400 Received: from talisker.ohm.york.ac.uk ([144.32.136.89]) by glenlivet.ohm.york.ac.uk with smtp id m0sgEyv-0004eKC (/\##/\ Smail3.1.30.10 #30.21); Wed, 9 Aug 95 18:31:53 +0100 (BST) Message-Id: Received: by talisker.ohm.york.ac.uk (NX5.67e/NX3.0X) id AA02127; Wed, 9 Aug 95 18:28:45 +0100 Content-Type: text/plain Mime-Version: 1.0 (NeXT Mail 3.3 v118.2) Received: by NeXT.Mailer (1.118.2) From: Roger Peppe Date: Wed, 9 Aug 1995 13:28:42 -0400 To: 9fans Subject: Re: mouse quirk References: <95Aug8.091336edt.34040@psuvax1.cse.psu.edu> Sender: owner-9fans Precedence: bulk Reply-To: 9fans i wrote: > a small problem with our (serial) mouse. it works fine except... problem seems to be solved - use a logitech mouse. i tried 4 different types of serial mouse before finally getting hold of a logitech mouse to try. all of them exhibit the same problem (except the ones with a 2/3 button switch, which gave an 'unknown mouse type' error when in 3 button mode) the doc. doesn't seem to mention any possible compatibility probs with non-logitech mice, and i know nothing about PC hardware; has anyone out there got a non-logitech mouse to work (without messing with the drivers) ? sorry to bother you. cheers, rog. >From 9fans-outgoing-owner Wed Aug 9 14:53:59 1995 Received: by colossus.cse.psu.edu id <45467>; Wed, 9 Aug 1995 14:39:57 -0400 Received: from mail.eecs.uic.edu ([128.248.174.29]) by colossus.cse.psu.edu with SMTP id <45482>; Wed, 9 Aug 1995 14:38:45 -0400 Received: from ernie.eecs.uic.edu (ernie.eecs.uic.edu [128.248.176.24]) by mail.eecs.uic.edu (8.6.11/8.6.10) with ESMTP id NAA26337 for <9fans@cse.psu.edu>; Wed, 9 Aug 1995 13:39:27 -0500 From: Mikhail Estrin Received: (mestrin@localhost) by ernie.eecs.uic.edu (8.6.10/8.6.10) id NAA16795 for 9fans@cse.psu.edu; Wed, 9 Aug 1995 13:39:32 -0500 Message-Id: <199508091839.NAA16795@ernie.eecs.uic.edu> Subject: Re: mouse quirk To: 9fans Date: Wed, 9 Aug 1995 14:39:32 -0400 In-Reply-To: from "Roger Peppe" at Aug 9, 95 01:28:42 pm X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 654 Sender: owner-9fans Precedence: bulk Reply-To: 9fans > i tried 4 different types of serial mouse before finally getting > hold of a logitech mouse to try. all of them exhibit the same > problem (except the ones with a 2/3 button switch, which gave > an 'unknown mouse type' error when in 3 button mode) > > the doc. doesn't seem to mention any possible compatibility probs > with non-logitech mice, and i know nothing about PC hardware; > has anyone out there got a non-logitech mouse to work (without > messing with the drivers) ? aux/mouse -dC detects MouseSystem interface serial mouse for me (generic $10 mouse with 2/3 button switch on 3). -- mestrin@eecs.uic.edu "All Men Play on Ten" - MANOWAR >From 9fans-outgoing-owner Wed Aug 9 16:16:10 1995 Received: by psuvax1.cse.psu.edu id <34077>; Wed, 9 Aug 1995 15:45:55 -0400 Received: from interlock.wdni.com ([199.221.59.2]) by psuvax1.cse.psu.edu with SMTP id <34059>; Wed, 9 Aug 1995 15:44:30 -0400 Received: by interlock.wdni.com id AA19112 (InterLock SMTP Gateway 3.0 for 9fans@cse.psu.edu); Wed, 9 Aug 1995 12:40:30 -0700 Message-Id: <199508091940.AA19112@interlock.wdni.com> Received: by interlock.wdni.com (Protected-side Proxy Mail Agent-1); Wed, 9 Aug 1995 12:40:30 -0700 Date: Wed, 9 Aug 1995 15:39:44 -0400 From: Steven Plite To: 9fans Subject: Re: help -- 486/33, adaptec scsi, dies on extract of disk2. Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-9fans Precedence: bulk Reply-To: 9fans >>> /bin/rc >>> The error was: >>> rc 30:vdexpand 31:fail | >>> Press any key to continue... >> >> I have the same problem (but the exact message varies) on a Dell Optiplex >> 486/66 with Adaptec 1542 controller. > > [ explanation deleted ] > > Anyhow, I had exactly the same problem with a similar 1542 based > system, so I bought an IDE drive. I still had the problem; at least > I'm sure I did; now I'm not so sure since two more people are > reporting it with an Adaptec 1542. I had the same problem while my floppy drives were connected to a generic multifunction I/O card. Moving the drives to the floppy controller on my 1542 fixed the problem for me. _______________________________________________________________________________ Steven Plite Open Systems Eng. & Support, Weyerhaeuser "This is the roller coaster of endless and violent vomit." -- Jason Fox >From 9fans-outgoing-owner Wed Aug 9 16:39:40 1995 Received: by colossus.cse.psu.edu id <45489>; Wed, 9 Aug 1995 16:23:50 -0400 Received: from goonsquad.spies.com ([192.216.22.66]) by colossus.cse.psu.edu with SMTP id <45482>; Wed, 9 Aug 1995 16:23:34 -0400 Received: by goonsquad.spies.com (Smail3.1.29.1 #2) id m0sgHcx-00024pC; Wed, 9 Aug 95 13:21 PDT Message-Id: From: ahm@goonsquad.spies.com (Andreas Meyer) Subject: Re: models To: 9fans Date: Wed, 9 Aug 1995 16:21:22 -0400 In-Reply-To: <95Aug4.025747edt.34167@psuvax1.cse.psu.edu> from "presotto@plan9.att.com" at Aug 4, 95 02:44:04 am Organization: The Internet Wiretap Content-Type: text Content-Length: 434 Sender: owner-9fans Precedence: bulk Reply-To: 9fans presotto@plan9.att.com writes: > I'm trying to make a list of PC models that Plan 9 works on. > Could you mail me the flavor PC you are using, i.e., box > or motherboard manufacturer and model number? Thanks much. AT&T 6386/SX WGS (had to add 80387) Probably no surprise, but thought it should be on the list. Andy -- Andreas Meyer, N2FYE Sustain. Endure. Evolve. ahm@goonsquad.spies.com http://www.spies.com/~ahm/ >From 9fans-outgoing-owner Wed Aug 9 17:33:49 1995 Received: by colossus.cse.psu.edu id <45489>; Wed, 9 Aug 1995 17:09:29 -0400 Received: from plan9.att.com ([192.20.225.252]) by colossus.cse.psu.edu with SMTP id <45508>; Wed, 9 Aug 1995 17:03:32 -0400 From: jmk@plan9.att.com To: 9fans Date: Wed, 9 Aug 1995 16:46:09 -0400 Subject: more VGA stuff Message-Id: <95Aug9.170332edt.45508@colossus.cse.psu.edu> Sender: owner-9fans Precedence: bulk Reply-To: 9fans There is a new version of aux/vga available for pickup by ftp, look in the pcdist/vga subdirectory (yesterday's vga.386 and vgadb have been removed). A description is in the file 'CHANGES'. All hardware supported by Brazil which does not require a kernel change is now included (exceptions are the ARK2000PV found on the Hercules Stingray 64/Video and the C&T 65540 found in some laptops). >From 9fans-outgoing-owner Wed Aug 9 20:09:40 1995 Received: by colossus.cse.psu.edu id <45511>; Wed, 9 Aug 1995 19:53:24 -0400 Received: from tigger ([204.187.66.2]) by colossus.cse.psu.edu with SMTP id <45496>; Wed, 9 Aug 1995 19:48:11 -0400 Received: by tigger (1.37.109.11/16.2) id AA137781770; Wed, 9 Aug 1995 19:42:50 -0400 From: Henry Baragar Subject: Re: mouse quirk To: 9fans Date: Wed, 9 Aug 1995 19:42:50 -0400 In-Reply-To: <199508091839.NAA16795@ernie.eecs.uic.edu> from "Mikhail Estrin" at Aug 9, 95 02:39:32 pm Organization: Instantiated Software Inc. Phone: (613) 723-2656 X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit Content-Length: 772 Message-Id: <95Aug9.194811edt.45496@colossus.cse.psu.edu> Sender: owner-9fans Precedence: bulk Reply-To: 9fans Hi, > i tried 4 different types of serial mouse before finally getting > hold of a logitech mouse to try. all of them exhibit the same > problem (except the ones with a 2/3 button switch, which gave > an 'unknown mouse type' error when in 3 button mode) > > the doc. doesn't seem to mention any possible compatibility probs > with non-logitech mice, and i know nothing about PC hardware; > has anyone out there got a non-logitech mouse to work (without > messing with the drivers) ? > I use a mouse off of an HP X-terminal that seems to work just fine with the demo distribution (mind you, it might be a Logitech in disguise). Henry (henry@instantiated.on.ca) THERE'S SMALL CHOICE IN A BOWL OF ROTTEN APPLES. SHAKESPEARE (Taken from GAUSSIAN 88) >From 9fans-outgoing-owner Wed Aug 9 22:52:55 1995 Received: by psuvax1.cse.psu.edu id <34096>; Wed, 9 Aug 1995 22:37:19 -0400 Received: from plan9.cs.su.oz.au ([129.78.96.33]) by psuvax1.cse.psu.edu with SMTP id <34106>; Wed, 9 Aug 1995 22:29:22 -0400 From: Boyd Roberts Date: Wed, 9 Aug 1995 22:07:15 -0400 To: 9fans Subject: pppclient Message-ID: <199508101207.1625.9.babim@plan9.cs.su.oz.au> Sender: owner-9fans Precedence: bulk Reply-To: 9fans I've been trying to get pppclient to go with a foreign ppp server. I think it's getting hung up in compression negotiation: the remote requests Van Jacobsen compression and pppclient says nak, then the remote request it again. So I see: Peer wants to do compress 2d 15 0 It's the 0 that's the problem as ppp.l says if (15 != 15 || 0 != 1) return nak. So is my server bust? What's the deal? >From 9fans-outgoing-owner Thu Aug 10 03:55:56 1995 Received: by psuvax1.cse.psu.edu id <34121>; Thu, 10 Aug 1995 03:29:34 -0400 Received: from staff.cs.su.OZ.AU ([129.78.8.1]) by psuvax1.cse.psu.edu with SMTP id <34119>; Thu, 10 Aug 1995 03:28:51 -0400 Received: from sour.sw.oz.au by staff.cs.su.OZ.AU (mail from jeremy for 9fans@cse.psu.edu) with MHSnet (insertion MHSnet site: swallow.sw.oz.au); Thu, 10 Aug 1995 17:28:25 +1000 Received: from sour.sw.oz.au by swallow.sw.oz.au with SMTP id AA20859; Thu, 10 Aug 95 17:23:38 EST (4.1/Unixware) (from jeremy@sour.sw.oz.au for 9fans@cse.psu.edu) Received: by sour.sw.oz.au id AA06760; Thu, 10 Aug 1995 17:23:36 +1000 (5.65c/1.34) (from jeremy@sour.sw.oz.au for 9fans@cse.psu.edu) From: jeremy@sour.sw.oz.au (Jeremy Fitzhardinge) Message-Id: <199508100723.AA06760@sour.sw.oz.au> Subject: Re: more VGA stuff To: 9fans Date: Thu, 10 Aug 1995 03:23:34 -0400 In-Reply-To: <95Aug9.170332edt.45508@colossus.cse.psu.edu> from "jmk@plan9.att.com" at Aug 9, 95 04:46:09 pm Organization: Softway Pty Ltd X-Face: '6U=%Tv\k1l-:?\$C[D@G 7(vl~w8&y}!f\bh#wL#n,TGKh>T.c7eT5-y)Hl'i;A1z$9?*lD.k}yqshddFb l[EC}c=;uc%x'}uh3E91p&oE > There is a new version of aux/vga available for pickup by ftp, look in the > pcdist/vga subdirectory (yesterday's vga.386 and vgadb have been removed). > A description is in the file 'CHANGES'. I tried out the Aug 8th version of aux/vga, and it worked much better. The fickering pixels went away, and I got a good clear 1184x888x8 image with a 100MHz dot clock. However, when I used a 1 (or 4) bit deep mode, it seemed as though only every second pixel was being displayed. Is this something else which needs to be addressed when pixel multiplexing is turned on in the ramdac? I also noticed that a hardware cursor is not supported except in 8 bit deep screens; is this a limitation of the #9 GXE64 card, or in aux/vga (or the kernel driver)? I'll try the new version out soon, but I didn't see anything in the changes file which might relate to the 1 bit screen problem, so I thought I'd mention it. Thanks, J >From 9fans-outgoing-owner Thu Aug 10 04:25:27 1995 Received: by colossus.cse.psu.edu id <45526>; Thu, 10 Aug 1995 04:04:03 -0400 Received: from symbionics.co.uk ([158.43.6.17]) by colossus.cse.psu.edu with SMTP id <45511>; Thu, 10 Aug 1995 04:02:57 -0400 Received: from sympc143 ([194.32.100.46]) by symbionics.co.uk (4.1/SMI-4.1) id AA07765; Thu, 10 Aug 95 09:01:36 BST Message-Id: <9508100801.AA07765@symbionics.co.uk> Comments: Authenticated sender is From: "Nigel Roles" Organization: Symbionics Communications To: 9fans Date: Thu, 10 Aug 1995 05:01:35 -0400 Subject: Re: help -- 486/33, adaptec scsi, dies on extract of disk2. Priority: normal X-Mailer: Pegasus Mail for Windows (v2.01) Sender: owner-9fans Precedence: bulk Reply-To: 9fans > 3. Apparently you can fetch a BIOS upgrade for the AHA-1542 from Adaptec's Web > site. One of our sysadmins here reports that this enabled him to run Linuxm > with no problems. You'll need a prom burner and access to: > http://www.adaptec.com/techsupp/bbs_eprm.htm > > If I try this myself I'll report what happens. > > Yes, I'm in the process as well. My 1542B needs 2 EPROMS, one for BIOS, the other for microcode (8085 assembler). On the grounds nobody uses 200nS 27c128s anymore I've been scrounging from peoples junk boxes. I've found one so far, and have leads for the other! >From 9fans-outgoing-owner Thu Aug 10 04:49:35 1995 Received: by colossus.cse.psu.edu id <45489>; Thu, 10 Aug 1995 04:26:10 -0400 Received: from symbionics.co.uk ([158.43.6.17]) by colossus.cse.psu.edu with SMTP id <45511>; Thu, 10 Aug 1995 04:24:53 -0400 Received: from sympc143 ([194.32.100.46]) by symbionics.co.uk (4.1/SMI-4.1) id AA07774; Thu, 10 Aug 95 09:04:29 BST Message-Id: <9508100804.AA07774@symbionics.co.uk> Comments: Authenticated sender is From: "Nigel Roles" Organization: Symbionics Communications To: 9fans Date: Thu, 10 Aug 1995 05:04:27 -0400 Subject: Re: help -- 486/33, adaptec scsi, dies on extract of disk2. Priority: normal X-Mailer: Pegasus Mail for Windows (v2.01) Sender: owner-9fans Precedence: bulk Reply-To: 9fans > >>> /bin/rc > >>> The error was: > >>> rc 30:vdexpand 31:fail | > >>> Press any key to continue... > >> > > Anyhow, I had exactly the same problem with a similar 1542 based > > system, so I bought an IDE drive. I still had the problem; at least > > I'm sure I did; now I'm not so sure since two more people are > > reporting it with an Adaptec 1542. > > I had the same problem while my floppy drives were connected to a generic > multifunction I/O card. Moving the drives to the floppy controller on my 1542 > fixed the problem for me. > Hmm. Tried that. Tried everything. Is yours a 1542B or C? >From 9fans-outgoing-owner Thu Aug 10 05:31:38 1995 Received: by psuvax1.cse.psu.edu id <34128>; Thu, 10 Aug 1995 05:09:02 -0400 Received: from cegelecproj.co.uk ([159.245.72.6]) by psuvax1.cse.psu.edu with SMTP id <34127>; Thu, 10 Aug 1995 05:04:38 -0400 Received: from vampire.cegelecproj.co.uk (cerberus.cegelecproj.co.uk) by cegelecproj.co.uk (4.1/SMI-4.1) id AA29797; Thu, 10 Aug 95 10:01:04 BST Received: from phantom.cegelecproj.co.uk (phantom.limbo.cegelecproj.co.uk) by vampire.cegelecproj.co.uk (5.0/SMI-SVR4) id AA04874; Thu, 10 Aug 1995 10:01:00 +0100 Received: from phantom (localhost) by phantom.cegelecproj.co.uk (5.0/SMI-SVR4) id AA11915; Thu, 10 Aug 1995 10:00:56 +0100 Message-Id: <9508100900.AA11915@phantom.cegelecproj.co.uk> To: 9fans@cs.psu.edu Subject: Re: help -- 486/33, adaptec scsi, dies on extract of disk2. Date: Thu, 10 Aug 1995 05:00:55 -0400 From: Steve_Kilbane Content-Length: 360 Sender: owner-9fans Precedence: bulk Reply-To: 9fans > >>> /bin/rc > >>> The error was: > >>> rc 30:vdexpand 31:fail | > >>> Press any key to continue... I've had this error a lot, although to be honest, the floppy drive on this machine is suspect anyway. I found that retrying eventually got the disk to read ok. Took about an hour of retrying, though. Luckily, I had other stuff to get on with. :-) steve >From 9fans-outgoing-owner Thu Aug 10 10:31:51 1995 Received: by colossus.cse.psu.edu id <45466>; Thu, 10 Aug 1995 10:12:51 -0400 Received: from plan9.att.com ([192.20.225.252]) by colossus.cse.psu.edu with SMTP id <45450>; Thu, 10 Aug 1995 10:12:33 -0400 From: jmk@plan9.att.com To: 9fans Date: Thu, 10 Aug 1995 10:01:44 -0400 Subject: Re: more VGA stuff Message-Id: <95Aug10.101233edt.45450@colossus.cse.psu.edu> Sender: owner-9fans Precedence: bulk Reply-To: 9fans in order to do resolutions >1024x768 the S3 chip must be put into enhanced mode, which implies 8-bit deep. there are ways to make the hardware do colour-expansion or whatever to make 1-bit work but it doesn't fit the plan9 kernel graphics structure. brazil only deals with 1 and 8 -bit. the hardware cursor on the S3 chips only works in enhanced mode. if you have a bt485 or tvp302x ramdac that may work in the non-enhanced mode but aux/vga is currently set up not to allow the hwgc except in enhanced mode. ------ original message follows ------ >From cse.psu.edu!9fans-outgoing-owner Thu Aug 10 04:06:12 EDT 1995 Received: by psuvax1.cse.psu.edu id <34121>; Thu, 10 Aug 1995 03:29:34 -0400 Received: from staff.cs.su.OZ.AU ([129.78.8.1]) by psuvax1.cse.psu.edu with SMTP id <34119>; Thu, 10 Aug 1995 03:28:51 -0400 Received: from sour.sw.oz.au by staff.cs.su.OZ.AU (mail from jeremy for 9fans@cse.psu.edu) with MHSnet (insertion MHSnet site: swallow.sw.oz.au); Thu, 10 Aug 1995 17:28:25 +1000 Received: from sour.sw.oz.au by swallow.sw.oz.au with SMTP id AA20859; Thu, 10 Aug 95 17:23:38 EST (4.1/Unixware) (from jeremy@sour.sw.oz.au for 9fans@cse.psu.edu) Received: by sour.sw.oz.au id AA06760; Thu, 10 Aug 1995 17:23:36 +1000 (5.65c/1.34) (from jeremy@sour.sw.oz.au for 9fans@cse.psu.edu) From: jeremy@sour.sw.oz.au (Jeremy Fitzhardinge) Message-Id: <199508100723.AA06760@sour.sw.oz.au> Subject: Re: more VGA stuff To: 9fans@cse.psu.edu Date: Thu, 10 Aug 1995 03:23:34 -0400 In-Reply-To: <95Aug9.170332edt.45508@colossus.cse.psu.edu> from "jmk@plan9.att.com" at Aug 9, 95 04:46:09 pm Organization: Softway Pty Ltd X-Face: '6U=%Tv\k1l-:?\$C[D@G 7(vl~w8&y}!f\bh#wL#n,TGKh>T.c7eT5-y)Hl'i;A1z$9?*lD.k}yqshddFb l[EC}c=;uc%x'}uh3E91p&oE > There is a new version of aux/vga available for pickup by ftp, look in the > pcdist/vga subdirectory (yesterday's vga.386 and vgadb have been removed). > A description is in the file 'CHANGES'. I tried out the Aug 8th version of aux/vga, and it worked much better. The fickering pixels went away, and I got a good clear 1184x888x8 image with a 100MHz dot clock. However, when I used a 1 (or 4) bit deep mode, it seemed as though only every second pixel was being displayed. Is this something else which needs to be addressed when pixel multiplexing is turned on in the ramdac? I also noticed that a hardware cursor is not supported except in 8 bit deep screens; is this a limitation of the #9 GXE64 card, or in aux/vga (or the kernel driver)? I'll try the new version out soon, but I didn't see anything in the changes file which might relate to the 1 bit screen problem, so I thought I'd mention it. Thanks, J >From 9fans-outgoing-owner Thu Aug 10 12:33:00 1995 Received: by colossus.cse.psu.edu id <45467>; Thu, 10 Aug 1995 12:08:14 -0400 Received: from mailgw.claircom.com ([199.5.241.51]) by colossus.cse.psu.edu with SMTP id <45465>; Thu, 10 Aug 1995 12:07:56 -0400 Received: from nimo.claircom.com by mailgw.claircom.com with smtp (Smail3.1.26.7 #2) id m0sga8z-0004teC; Thu, 10 Aug 95 09:07 PDT Received: by nimo.claircom.com (Smail3.1.26.7 #2) id m0sga8y-0005Z4C; Thu, 10 Aug 95 09:07 PDT Message-Id: Date: Thu, 10 Aug 1995 12:07:00 -0400 From: fst@claircom.com (Fariborz Skip Tavakkolian) To: 9fans Subject: What causes ``panic: ataintr: read/ident'' in 9DOS? In-Reply-To: <95Aug9.093049edt.45464@colossus.cse.psu.edu> References: <95Aug9.093049edt.45464@colossus.cse.psu.edu> Sender: owner-9fans Precedence: bulk Reply-To: 9fans > c:\> b hd!0!9dos The same panic message appears. FYI, the disk controller is in Enhanced IDE mode, and I'm unable to change it to Standard IDE mode. Thanks >From 9fans-outgoing-owner Thu Aug 10 15:00:27 1995 Received: by colossus.cse.psu.edu id <45493>; Thu, 10 Aug 1995 14:37:27 -0400 Received: from plan9.att.com ([192.20.225.252]) by colossus.cse.psu.edu with SMTP id <45489>; Thu, 10 Aug 1995 14:34:05 -0400 From: presotto@plan9.att.com To: 9fans Date: Thu, 10 Aug 1995 14:18:12 -0400 Subject: re: pppclient Message-Id: <95Aug10.143405edt.45489@colossus.cse.psu.edu> Sender: owner-9fans Precedence: bulk Reply-To: 9fans We're the ones that are wrong, sort of. For the second number 0 == don't compress connection id (or slot number or whatever you call it) 1 == connection id may be compressed Our code only knows about the second and rejects compression otherwise. It would be easy enough easy to change, just remember that the other requested no compression and change the comparison on line 192 of compress.l. However, the foriegn PPP should be accepting the Nak and just not compressing. Perhaps we're screwing up the Nak. I'll leave it up to someone who really uses it do the change. Noone here has used the code since a summer student wrote it a few years ago. ------ original message follows ------ >From cse.psu.edu!9fans-outgoing-owner Wed Aug 9 22:58:49 EDT 1995 Received: by psuvax1.cse.psu.edu id <34096>; Wed, 9 Aug 1995 22:37:19 -0400 Received: from plan9.cs.su.oz.au ([129.78.96.33]) by psuvax1.cse.psu.edu with SMTP id <34106>; Wed, 9 Aug 1995 22:29:22 -0400 From: Boyd Roberts Date: Wed, 9 Aug 1995 22:07:15 -0400 To: 9fans@cse.psu.edu Subject: pppclient Message-ID: <199508101207.1625.9.babim@plan9.cs.su.oz.au> Sender: owner-9fans@cse.psu.edu Precedence: bulk Reply-To: 9fans@cse.psu.edu I've been trying to get pppclient to go with a foreign ppp server. I think it's getting hung up in compression negotiation: the remote requests Van Jacobsen compression and pppclient says nak, then the remote request it again. So I see: Peer wants to do compress 2d 15 0 It's the 0 that's the problem as ppp.l says if (15 != 15 || 0 != 1) return nak. So is my server bust? What's the deal? >From 9fans-outgoing-owner Thu Aug 10 15:13:25 1995 Received: by psuvax1.cse.psu.edu id <34153>; Thu, 10 Aug 1995 14:45:05 -0400 Received: from plan9.cs.york.ac.uk ([144.32.32.195]) by psuvax1.cse.psu.edu with SMTP id <34152>; Thu, 10 Aug 1995 14:44:31 -0400 From: forsyth@plan9.cs.york.ac.uk Date: Thu, 10 Aug 1995 14:19:23 -0400 To: 9fans@cs.psu.edu subject: ip/rip Message-Id: <95Aug10.144431edt.34152@psuvax1.cse.psu.edu> Sender: owner-9fans Precedence: bulk Reply-To: 9fans if ip/rip complains it can't announce because cs can't translate the address, add udp=rip port=520 to /lib/ndb/local (i hope i hadn't accidentally deleted it myself!) >From 9fans-outgoing-owner Thu Aug 10 17:06:23 1995 Received: by psuvax1.cse.psu.edu id <34155>; Thu, 10 Aug 1995 16:46:54 -0400 Received: from noao.edu ([140.252.1.54]) by psuvax1.cse.psu.edu with SMTP id <34152>; Thu, 10 Aug 1995 16:46:18 -0400 Received: from gemini.tuc.noao.edu by noao.edu (4.1/SAG-Noao.G102) id AA29575; Thu, 10 Aug 95 13:46:04 MST; for 9fans@cse.psu.edu Received: from daikon.tuc.noao.edu.noao by gemini.tuc.noao.edu (4.1/SAG.sat.14) id AA09147; Thu, 10 Aug 95 13:46:03 MST; for 9fans@cse.psu.edu Received: by daikon.tuc.noao.edu.noao (4.1/SAG.sun.8) id AA02374; Thu, 10 Aug 95 13:46:02 MST; for 9fans@cse.psu.edu Date: Thu, 10 Aug 1995 16:46:02 -0400 From: rwolff@noao.edu (Richard Wolff) Message-Id: <9508102046.AA02374@daikon.tuc.noao.edu.noao> To: 9fans Subject: Question on network setup Sender: owner-9fans Precedence: bulk Reply-To: 9fans When my 486 boots, it prints out an error message that I need to edit /ndb/local and reboot. Having done that many times, it's clear something else is wanted. Also, /ndb/cs does not set sysname and the local tcp network isn't available. However, if I tell ip/ipconfig what the ip address of my machine is by way of a command line argument, the /ndb/local error message goes away, the network is accessible, and I just have to mount #P and poke some routes at iproute. Is there something I should do so the initial setup (aside from the routing) happens automagically as the error message seems to imply? (Gateway 486, enet board WD8013EPC) Richard >From 9fans-outgoing-owner Thu Aug 10 17:55:53 1995 Received: by psuvax1.cse.psu.edu id <34153>; Thu, 10 Aug 1995 17:35:39 -0400 Received: from plan9.att.com ([192.20.225.252]) by psuvax1.cse.psu.edu with SMTP id <34152>; Thu, 10 Aug 1995 17:22:52 -0400 From: presotto@plan9.att.com To: 9fans Date: Thu, 10 Aug 1995 17:13:42 -0400 Subject: re: Question on network setup Message-Id: <95Aug10.172252edt.34152@psuvax1.cse.psu.edu> Sender: owner-9fans Precedence: bulk Reply-To: 9fans If /bin/ndb/cs can't figure out the name of the system, its because it can't find the ether or IP address in /lib/ndb/local (or couldn't open the ether device). Clearly you think you've done this. Could you send me the relevant lines from /lib/ndb/local? ------ original message follows ------ >From cse.psu.edu!9fans-outgoing-owner Thu Aug 10 17:12:10 EDT 1995 Received: by psuvax1.cse.psu.edu id <34155>; Thu, 10 Aug 1995 16:46:54 -0400 Received: from noao.edu ([140.252.1.54]) by psuvax1.cse.psu.edu with SMTP id <34152>; Thu, 10 Aug 1995 16:46:18 -0400 Received: from gemini.tuc.noao.edu by noao.edu (4.1/SAG-Noao.G102) id AA29575; Thu, 10 Aug 95 13:46:04 MST; for 9fans@cse.psu.edu Received: from daikon.tuc.noao.edu.noao by gemini.tuc.noao.edu (4.1/SAG.sat.14) id AA09147; Thu, 10 Aug 95 13:46:03 MST; for 9fans@cse.psu.edu Received: by daikon.tuc.noao.edu.noao (4.1/SAG.sun.8) id AA02374; Thu, 10 Aug 95 13:46:02 MST; for 9fans@cse.psu.edu Date: Thu, 10 Aug 1995 16:46:02 -0400 From: rwolff@noao.edu (Richard Wolff) Message-Id: <9508102046.AA02374@daikon.tuc.noao.edu.noao> To: 9fans@cse.psu.edu Subject: Question on network setup Sender: owner-9fans@cse.psu.edu Precedence: bulk Reply-To: 9fans@cse.psu.edu When my 486 boots, it prints out an error message that I need to edit /ndb/local and reboot. Having done that many times, it's clear something else is wanted. Also, /ndb/cs does not set sysname and the local tcp network isn't available. However, if I tell ip/ipconfig what the ip address of my machine is by way of a command line argument, the /ndb/local error message goes away, the network is accessible, and I just have to mount #P and poke some routes at iproute. Is there something I should do so the initial setup (aside from the routing) happens automagically as the error message seems to imply? (Gateway 486, enet board WD8013EPC) Richard >From 9fans-outgoing-owner Fri Aug 11 11:51:32 1995 Received: by psuvax1.cse.psu.edu id <34155>; Fri, 11 Aug 1995 11:23:21 -0400 Received: from noao.edu ([140.252.1.54]) by psuvax1.cse.psu.edu with SMTP id <34154>; Fri, 11 Aug 1995 11:22:30 -0400 Received: from gemini.tuc.noao.edu by noao.edu (4.1/SAG-Noao.G102) id AA03910; Fri, 11 Aug 95 08:22:12 MST; for 9fans@cse.psu.edu Received: from daikon.tuc.noao.edu.noao by gemini.tuc.noao.edu (4.1/SAG.sat.14) id AA00723; Fri, 11 Aug 95 08:22:13 MST; for 9fans@cse.psu.edu Received: by daikon.tuc.noao.edu.noao (4.1/SAG.sun.8) id AA02569; Fri, 11 Aug 95 07:33:01 MST; for 9fans@cse.psu.edu Date: Fri, 11 Aug 1995 10:33:01 -0400 From: rwolff@noao.edu (Richard Wolff) Message-Id: <9508111433.AA02569@daikon.tuc.noao.edu.noao> To: 9fans Subject: Re: Question on network setup Sender: owner-9fans Precedence: bulk Reply-To: 9fans > When my 486 boots, it prints out an error message that I need to > edit /ndb/local and reboot. Having done that many times, it's clear > something else is wanted. Also, /ndb/cs does not set sysname and the > local tcp network isn't available. problem resolved. Don't use uppercase hex digits in setting 'ether=nnnnnnnn' in /lib/ndb/local. >From 9fans-outgoing-owner Fri Aug 11 18:59:31 1995 Received: by colossus.cse.psu.edu id <45581>; Fri, 11 Aug 1995 18:46:13 -0400 Received: from postman.ncube.com ([134.242.8.47]) by colossus.cse.psu.edu with SMTP id <45575>; Fri, 11 Aug 1995 18:45:57 -0400 Received: from db1.ncube.com by postman.ncube.com (4.1/SMI-4.1) id AA05651; Fri, 11 Aug 95 15:45:31 PDT Received: from cirque.ncube.com by db1.ncube.com (4.1/SMI-4.1) id AA16700; Fri, 11 Aug 95 15:45:28 PDT Date: Fri, 11 Aug 1995 18:45:28 -0400 From: peterw@postman.ncube.com (Peter Wang) Message-Id: <9508112245.AA16700@db1.ncube.com> To: 9fans Subject: can't boot plan9 on a stand_alone PC? Sender: owner-9fans Precedence: bulk Reply-To: 9fans - The system: a PC compatiable with a Pentium735 chip, and 853 MB IDE drive. Made a partition of 80 MB (C drive) and DOS formatted, leaving the rest of the hard disk to plan9. - How the problem started: plan9 runs perfectly until I added additional hard disks and then did partitions from C:\ using fdisk of DOS command. - Symptom: when run plan9 from DOS, c:\plan9\b.com, get error message on screen, .bad majic 0xf6xxxxxx not a plan 9 executable! boot from: - Question: How to recover? I would appreciate any hints! - Peter Wang >From 9fans-outgoing-owner Fri Aug 11 20:33:31 1995 Received: by colossus.cse.psu.edu id <45582>; Fri, 11 Aug 1995 20:22:29 -0400 Received: from plan9.att.com ([192.20.225.252]) by colossus.cse.psu.edu with SMTP id <45575>; Fri, 11 Aug 1995 20:22:13 -0400 From: jmk@plan9.att.com To: 9fans Date: Fri, 11 Aug 1995 20:12:01 -0400 Subject: re: can't boot plan9 on a stand_alone PC? Message-Id: <95Aug11.202213edt.45575@colossus.cse.psu.edu> Sender: owner-9fans Precedence: bulk Reply-To: 9fans when you see the 'boot from: ' prompt does it give a list of boot devices on the previous line? if so, what does it give? you can copy (under dos) the 9dos file from the floppy to c: then do c:\plan9\b hd!0!9dos which will get you up and able to look at the hard discs to see what went wrong. sounds like the boot partition was overwritten. ------ original message follows ------ >From cse.psu.edu!9fans-outgoing-owner Fri Aug 11 19:00:51 EDT 1995 Received: by colossus.cse.psu.edu id <45581>; Fri, 11 Aug 1995 18:46:13 -0400 Received: from postman.ncube.com ([134.242.8.47]) by colossus.cse.psu.edu with SMTP id <45575>; Fri, 11 Aug 1995 18:45:57 -0400 Received: from db1.ncube.com by postman.ncube.com (4.1/SMI-4.1) id AA05651; Fri, 11 Aug 95 15:45:31 PDT Received: from cirque.ncube.com by db1.ncube.com (4.1/SMI-4.1) id AA16700; Fri, 11 Aug 95 15:45:28 PDT Date: Fri, 11 Aug 1995 18:45:28 -0400 From: peterw@postman.ncube.com (Peter Wang) Message-Id: <9508112245.AA16700@db1.ncube.com> To: 9fans@cse.psu.edu Subject: can't boot plan9 on a stand_alone PC? Sender: owner-9fans@cse.psu.edu Precedence: bulk Reply-To: 9fans@cse.psu.edu - The system: a PC compatiable with a Pentium735 chip, and 853 MB IDE drive. Made a partition of 80 MB (C drive) and DOS formatted, leaving the rest of the hard disk to plan9. - How the problem started: plan9 runs perfectly until I added additional hard disks and then did partitions from C:\ using fdisk of DOS command. - Symptom: when run plan9 from DOS, c:\plan9\b.com, get error message on screen, .bad majic 0xf6xxxxxx not a plan 9 executable! boot from: - Question: How to recover? I would appreciate any hints! - Peter Wang >From 9fans-outgoing-owner Sun Aug 13 10:32:10 1995 Received: by colossus.cse.psu.edu id <45676>; Sun, 13 Aug 1995 10:08:12 -0400 Received: from plan9.att.com ([192.20.225.252]) by colossus.cse.psu.edu with SMTP id <45685>; Sun, 13 Aug 1995 10:07:16 -0400 From: presotto@plan9.att.com To: 9fans Date: Sun, 13 Aug 1995 09:58:12 -0400 Subject: re: What causes ``panic: ataintr: read/ident'' in 9DOS? Message-Id: <95Aug13.100716edt.45685@colossus.cse.psu.edu> Sender: owner-9fans Precedence: bulk Reply-To: 9fans fst@@claircom.com writes: Dear Rosanne Rosanadanna, I am having trouble installing the 3 dis[ck] demo set; This is a Toshiba T2450CT laptop (75MHz i486DX4, 8MB, TFT VGA, 320MB IDE, and AccuPoint). The problem occurs on the first dis[ck] when B.COM is invoked on the A: drive. B.COM seems to find, load, and run 9DOS. Here is what it says: 1269 free pages, 5076K bytes, swap 32596K, highwater 252K, headroom 312K CPU is a 74 MHz IntelDX4 (cpuid: ax 480 dx 3) pcmcia controller0 is a 1 slot Cirrus Logic PD6710 fs...time...panic: ataintr: read/ident exiting Any ideas? We took this off line. After a few go arounds we figured out that the drive was sending us ident info that Plan 9 didn't understand. We made the driver more robust in the face of rediculous info. The diffs are in http://plan9.att.com/plan9/errata/devata.c.diff. I also made a version of disk1, ftp://plan9.att.com/plan9/pcdist/disk1.2 with the changes included. >From 9fans-outgoing-owner Mon Aug 14 07:52:42 1995 Received: by colossus.cse.psu.edu id <46021>; Mon, 14 Aug 1995 07:17:16 -0400 Received: from kitten.mcs.com ([192.160.127.90]) by colossus.cse.psu.edu with SMTP id <46020>; Mon, 14 Aug 1995 07:17:00 -0400 Received: from venus.mcs.com (root@Venus.mcs.com [192.160.127.92]) by kitten.mcs.com (8.6.10/8.6.9) with SMTP id GAA02311 for <9fans@cse.psu.edu>; Mon, 14 Aug 1995 06:16:45 -0500 Received: by venus.mcs.com (/\==/\ Smail3.1.28.1 #28.5) id ; Mon, 14 Aug 95 06:16 CDT Message-Id: Subject: Re: unsibscribe To: 9fans Date: Mon, 14 Aug 1995 07:16:45 -0400 From: "Michael S. Jenkins" In-Reply-To: <95Aug13.100716edt.45685@colossus.cse.psu.edu> from "presotto@plan9.att.com" at Aug 13, 95 09:58:12 am X-Mailer: ELM [version 2.4 PL24] Content-Type: text Content-Length: 57 Sender: owner-9fans Precedence: bulk Reply-To: 9fans unsubscribe -- mjenkins@mcs.com >From 9fans-outgoing-owner Mon Aug 14 09:21:49 1995 Received: by psuvax1.cse.psu.edu id <34163>; Mon, 14 Aug 1995 08:40:51 -0400 Received: from plan9.cs.su.oz.au ([129.78.96.2]) by psuvax1.cse.psu.edu with SMTP id <34488>; Sun, 13 Aug 1995 20:11:27 -0400 From: Boyd Roberts Date: Sun, 13 Aug 1995 19:55:24 -0400 To: 9fans Subject: re: pppclient In-Reply-To: <95Aug10.143405edt.45489@colossus.cse.psu.edu> Message-ID: <199508140955.518.9.babip@plan9.cs.su.oz.au> Sender: owner-9fans Precedence: bulk Reply-To: 9fans i pulled the ppp docs and have added the code to handle slot id compression. i think what i see now is that the ack is mangled, i'm not sure. i'll try and check it out today. things are a bit slow as the source is not where i am so the compile edit run cycle is a bit arduous. >From 9fans-outgoing-owner Mon Aug 14 10:54:42 1995 Received: by colossus.cse.psu.edu id <46025>; Mon, 14 Aug 1995 10:18:11 -0400 Received: from symbionics.co.uk ([158.43.6.17]) by colossus.cse.psu.edu with SMTP id <46044>; Mon, 14 Aug 1995 10:07:03 -0400 Received: from sympc143 ([194.32.100.46]) by symbionics.co.uk (4.1/SMI-4.1) id AA21333; Mon, 14 Aug 95 14:53:54 BST Message-Id: <9508141353.AA21333@symbionics.co.uk> Comments: Authenticated sender is From: "Nigel Roles" Organization: Symbionics Communications To: 9fans Date: Mon, 14 Aug 1995 10:53:51 -0400 Subject: Changes Priority: normal X-Mailer: Pegasus Mail for Windows (v2.01) Sender: owner-9fans Precedence: bulk Reply-To: 9fans Since we are bound by the licence not to distribute modified versions of THE SOFTWARE to anyone without a licence, do we have a plan by wihich we can authenticate licensees? >From 9fans-outgoing-owner Mon Aug 14 12:00:08 1995 Received: by psuvax1.cse.psu.edu id <34182>; Mon, 14 Aug 1995 11:26:47 -0400 Received: from tango.rahul.net ([192.160.13.5]) by psuvax1.cse.psu.edu with SMTP id <34226>; Sun, 13 Aug 1995 00:51:54 -0400 Received: from bolero.rahul.net by tango.rahul.net with SMTP id AA25967 (5.67b8/IDA-1.5 for ); Sat, 12 Aug 1995 21:51:38 -0700 Received: from bedlam.rahul.net by bolero.rahul.net with SMTP id AA24373 (5.67b8/IDA-1.5 for ); Sat, 12 Aug 1995 21:51:35 -0700 Received: by bedlam.rahul.net id m0shUzk-0002G7C (Debian /\oo/\ Smail3.1.29.1 #29.31); Sat, 12 Aug 95 21:49 PDT Message-Id: Date: Sun, 13 Aug 1995 00:49:00 -0400 From: bhogan@bedlam.rahul.net (Bill Hogan) To: plan9-fans@cs.psu.edu Subject: installing plan9 demo on a PC Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Sender: owner-9fans Precedence: bulk Reply-To: 9fans Hello. I took a first crack at installing the plan9 demo on my PC yesterday. Schematically: Boot from Disk 1 OK Create c:\plan9, etc OK Create plan9.ini OK (see below) Remove disk 1 & reboot ??? That is, after I reboot to DOS and give the command C:>plan9\B instead of the next stage of the installation process, I get the error message "error walking to 9dos" and it asks me where to "boot from" so I gave it sd!0!/plan9/9dos but I got the same error message back. Here is what it says it sees: scsi devices: ----------------- scsi0 = dos C: drive scsi1 = dos D: drive scsi2 = dos E: <----------- this is where I want to install plan9 scsi3 = dos F: scsi4 = dos H: (Texel cdrom) boot devices: ----------------- fd!1 sd!0 sd!2 sd!3 Here is a directory listing of C:\plan9: bedlam:[*root*]/C/plan9 # ls -lt --rev ---------------------------------------------------------------- total 568 -rwxr-xr-x 1 root root 61280 Aug 11 20:26 b.com* -rwxr-xr-x 1 root root 208 Aug 11 20:26 notice* drwxr-xr-x 3 root root 2048 Aug 11 20:26 adm/ -rwxr-xr-x 1 root root 437704 Aug 11 20:26 9dos* drwxr-xr-x 2 root root 2048 Aug 11 20:26 srv/ drwxr-xr-x 2 root root 2048 Aug 11 20:26 tmp/ drwxr-xr-x 3 root root 2048 Aug 11 20:27 386/ drwxr-xr-x 3 root root 2048 Aug 11 20:27 lib/ drwxr-xr-x 4 root root 2048 Aug 11 20:27 mnt/ drwxr-xr-x 8 root root 2048 Aug 11 20:27 n/ drwxr-xr-x 4 root root 2048 Aug 11 20:27 rc/ -rwxr-xr-x 1 root root 132 Aug 12 09:19 plan9.ini* ------------------------------------------------------------------ and here is plan9.ini: bedlam:[*root*]/C/plan9 # cat plan9.ini ---------------------------------------- mouseport=0 monitor=vga vgasize=640x480x1 scsi0=type=aha1542 port=0x330 console=cga bootfile=sd!0!/plan9/9dos rootdir=/plan9 ----------------------------------------- Thank you in advance for your kind assistance. Bill >From 9fans-outgoing-owner Mon Aug 14 12:35:06 1995 Received: by psuvax1.cse.psu.edu id <33981>; Mon, 14 Aug 1995 11:57:10 -0400 Received: from staff.cs.su.OZ.AU ([129.78.8.1]) by psuvax1.cse.psu.edu with SMTP id <34196>; Sat, 12 Aug 1995 13:14:26 -0400 Received: from plan9.cs.su.oz.au by staff.cs.su.OZ.AU (mail from dhog for 9fans@cse.psu.edu) with MHSnet (insertion MHSnet site: staff.cs.su.oz.au); Sun, 13 Aug 1995 03:14:14 +1000 Received: from riker.plan9.cs.su.oz.au. by staff.cs.su.OZ.AU.; Sun, 13 Aug 1995 03:14:12 +1000 X-Claimed-Received: from plan9.cs.su.oz.au Date: Sat, 12 Aug 1995 13:04:16 -0400 From: dhog@plan9.cs.su.oz.au To: 9fans Subject: Bug found in ape's rename() function Message-Id: <95Aug12.131426edt.34196@psuvax1.cse.psu.edu> Sender: owner-9fans Precedence: bulk Reply-To: 9fans If you use ape's rename() function, and the files aren't in the same directory, it corrupts the file. Here is a fix: diff /sys/src/ape/lib/ap/plan9/rename.c new 63c63 < while(n>=0 && (n = _READ(ffd, buf, 8192) > 0)) --- > while(n>=0 && (n = _READ(ffd, buf, 8192)) > 0) >From 9fans-outgoing-owner Mon Aug 14 13:09:01 1995 Received: by psuvax1.cse.psu.edu id <34165>; Mon, 14 Aug 1995 12:37:06 -0400 Received: from plan9.cs.york.ac.uk ([144.32.32.195]) by psuvax1.cse.psu.edu with SMTP id <34175>; Fri, 11 Aug 1995 21:18:13 -0400 From: forsyth@plan9.cs.york.ac.uk Date: Fri, 11 Aug 1995 20:56:50 -0400 To: 9fans@cs.psu.edu subject: ed buglet Message-Id: <95Aug11.211813edt.34175@psuvax1.cse.psu.edu> Sender: owner-9fans Precedence: bulk Reply-To: 9fans ed neither ignores nor delays interrupts during a shell escape. try: p9gate% diff old/ed.c /sys/src/cmd/ed.c 55a56 > int waiting; 677c678 < if(rescuing) --- > if(rescuing || waiting) 905a907 > int pid; 919c921 < if(fork() == 0) { --- > if((pid = fork()) == 0) { 923c925,928 < wait(&w); --- > waiting = 1; > while(wait(&w) != pid) > ; > waiting = 0; >From 9fans-outgoing-owner Mon Aug 14 17:28:41 1995 Received: by colossus.cse.psu.edu id <46022>; Mon, 14 Aug 1995 16:58:47 -0400 Received: from optima.CS.Arizona.EDU ([192.12.69.5]) by colossus.cse.psu.edu with SMTP id <45676>; Mon, 14 Aug 1995 16:36:32 -0400 Received: from baskerville.CS.Arizona.EDU by optima.CS.Arizona.EDU (5.65c/15) via SMTP id AA04634; Mon, 14 Aug 1995 12:53:56 MST Received: (from jdavis@localhost) by baskerville.CS.Arizona.EDU (8.6.9/8.6.6) id MAA29041; Mon, 14 Aug 1995 12:53:59 -0700 Date: Mon, 14 Aug 1995 15:53:58 -0400 From: Jim Davis X-Sender: jdavis@baskerville To: 9fans Subject: comp.os.plan9 voting result. Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-9fans Precedence: bulk Reply-To: 9fans Well, the votes have been counted and... RESULT moderated group comp.os.plan9 passes 449:14 There were 449 YES votes and 14 NO votes, for a total of 463 valid votes. There were 2 abstains. For group passage, YES votes must be at least 2/3 of all valid (YES and NO) votes. There also must be at least 100 more YES votes than NO votes. There is a five day discussion period after these results are posted. If no serious allegations of voting irregularities are raised, the moderator of news.announce.newgroups will create the group shortly thereafter. comp.os.plan9 passed on Fri Jul 14 01:42:24 1995 >From 9fans-outgoing-owner Mon Aug 14 18:22:16 1995 Received: by psuvax1.cse.psu.edu id <34181>; Mon, 14 Aug 1995 17:49:49 -0400 Received: from plan9.att.com ([192.20.225.252]) by psuvax1.cse.psu.edu with SMTP id <34221>; Mon, 14 Aug 1995 16:51:14 -0400 From: howard@plan9.att.com To: 9fans Date: Mon, 14 Aug 1995 15:53:10 -0400 Subject: Re: Bug found in ape's rename() function Message-Id: <95Aug14.165114edt.34221@psuvax1.cse.psu.edu> Sender: owner-9fans Precedence: bulk Reply-To: 9fans > If you use ape's rename() function, and the files aren't in the same > directory, it corrupts the file. Here is a fix: > > diff /sys/src/ape/lib/ap/plan9/rename.c new > 63c63 > < while(n>=0 && (n = _READ(ffd, buf, 8192) > 0)) > --- > > while(n>=0 && (n = _READ(ffd, buf, 8192)) > 0) Sorry about that. Thanks for the fix. >From 9fans-outgoing-owner Mon Aug 14 22:39:22 1995 Received: by psuvax1.cse.psu.edu id <34220>; Mon, 14 Aug 1995 22:09:40 -0400 Received: from plan9.cs.su.oz.au ([129.78.96.2]) by psuvax1.cse.psu.edu with SMTP id <34230>; Mon, 14 Aug 1995 20:52:06 -0400 From: Boyd Roberts Date: Mon, 14 Aug 1995 19:27:36 -0400 To: 9fans Subject: re: pppclient In-Reply-To: <199508140955.518.9.babip@plan9.cs.su.oz.au> Message-ID: <199508150927.1656.9.babis@plan9.cs.su.oz.au> Sender: owner-9fans Precedence: bulk Reply-To: 9fans Looking further into the IPCP code I see that its not likely to converge when negociating with my server. The configuration request/nak/reject code is just wrong. I'm not going to try and fix it any further. It just doesn't hold enough state to ensure the negociation will converge; it's nearly stateless, but not quite. >From 9fans-outgoing-owner Tue Aug 15 01:13:33 1995 Received: by psuvax1.cse.psu.edu id <34172>; Tue, 15 Aug 1995 00:46:20 -0400 Received: from plan9.att.com ([192.20.225.252]) by psuvax1.cse.psu.edu with SMTP id <34205>; Mon, 14 Aug 1995 23:42:50 -0400 From: jmk@plan9.att.com To: 9fans Date: Mon, 14 Aug 1995 22:02:37 -0400 Subject: re: installing plan9 demo on a PC Message-Id: <95Aug14.234250edt.34205@psuvax1.cse.psu.edu> Sender: owner-9fans Precedence: bulk Reply-To: 9fans don't see anything obviously wrong with this (why doesn't sd!1 show up as a boot device?). to get 'error walking to 9dos' one of the elements in the path has to show up either as a non-directory or could not be found in the directory scan (i.e. 'plan9' isn't being found in c:). this is surprising because the files were obviously put there by plan9 during the first part of the installation. check the disc isn't corrupt. copy the plan9.ini and 9dos files to the root of c: and then try plan9\b sd!0!9dos it's a mystery. ------ original message follows ------ >From cse.psu.edu!9fans-outgoing-owner Mon Aug 14 12:10:58 EDT 1995 Received: by psuvax1.cse.psu.edu id <34182>; Mon, 14 Aug 1995 11:26:47 -0400 Received: from tango.rahul.net ([192.160.13.5]) by psuvax1.cse.psu.edu with SMTP id <34226>; Sun, 13 Aug 1995 00:51:54 -0400 Received: from bolero.rahul.net by tango.rahul.net with SMTP id AA25967 (5.67b8/IDA-1.5 for ); Sat, 12 Aug 1995 21:51:38 -0700 Received: from bedlam.rahul.net by bolero.rahul.net with SMTP id AA24373 (5.67b8/IDA-1.5 for ); Sat, 12 Aug 1995 21:51:35 -0700 Received: by bedlam.rahul.net id m0shUzk-0002G7C (Debian /\oo/\ Smail3.1.29.1 #29.31); Sat, 12 Aug 95 21:49 PDT Message-Id: Date: Sun, 13 Aug 1995 00:49:00 -0400 From: bhogan@bedlam.rahul.net (Bill Hogan) To: plan9-fans@cse.psu.edu Subject: installing plan9 demo on a PC Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Sender: owner-9fans@cse.psu.edu Precedence: bulk Reply-To: 9fans@cse.psu.edu Hello. I took a first crack at installing the plan9 demo on my PC yesterday. Schematically: Boot from Disk 1 OK Create c:\plan9, etc OK Create plan9.ini OK (see below) Remove disk 1 & reboot ??? That is, after I reboot to DOS and give the command C:>plan9\B instead of the next stage of the installation process, I get the error message "error walking to 9dos" and it asks me where to "boot from" so I gave it sd!0!/plan9/9dos but I got the same error message back. Here is what it says it sees: scsi devices: ----------------- scsi0 = dos C: drive scsi1 = dos D: drive scsi2 = dos E: <----------- this is where I want to install plan9 scsi3 = dos F: scsi4 = dos H: (Texel cdrom) boot devices: ----------------- fd!1 sd!0 sd!2 sd!3 Here is a directory listing of C:\plan9: bedlam:[*root*]/C/plan9 # ls -lt --rev ---------------------------------------------------------------- total 568 -rwxr-xr-x 1 root root 61280 Aug 11 20:26 b.com* -rwxr-xr-x 1 root root 208 Aug 11 20:26 notice* drwxr-xr-x 3 root root 2048 Aug 11 20:26 adm/ -rwxr-xr-x 1 root root 437704 Aug 11 20:26 9dos* drwxr-xr-x 2 root root 2048 Aug 11 20:26 srv/ drwxr-xr-x 2 root root 2048 Aug 11 20:26 tmp/ drwxr-xr-x 3 root root 2048 Aug 11 20:27 386/ drwxr-xr-x 3 root root 2048 Aug 11 20:27 lib/ drwxr-xr-x 4 root root 2048 Aug 11 20:27 mnt/ drwxr-xr-x 8 root root 2048 Aug 11 20:27 n/ drwxr-xr-x 4 root root 2048 Aug 11 20:27 rc/ -rwxr-xr-x 1 root root 132 Aug 12 09:19 plan9.ini* ------------------------------------------------------------------ and here is plan9.ini: bedlam:[*root*]/C/plan9 # cat plan9.ini ---------------------------------------- mouseport=0 monitor=vga vgasize=640x480x1 scsi0=type=aha1542 port=0x330 console=cga bootfile=sd!0!/plan9/9dos rootdir=/plan9 ----------------------------------------- Thank you in advance for your kind assistance. Bill >From 9fans-outgoing-owner Tue Aug 15 02:02:04 1995 Received: by psuvax1.cse.psu.edu id <34070>; Tue, 15 Aug 1995 01:37:22 -0400 Received: from postman.ncube.com ([134.242.8.47]) by psuvax1.cse.psu.edu with SMTP id <34157>; Tue, 15 Aug 1995 00:00:18 -0400 Received: from butler.ncube.com by postman.ncube.com (4.1/SMI-4.1) id AA11305; Mon, 14 Aug 95 19:58:00 PDT Received: from skynet.ncube.com by butler.ncube.com (5.0/SMI-SVR4) id AA21632; Mon, 14 Aug 1995 19:57:54 +0800 Date: Mon, 14 Aug 1995 07:57:54 -0400 From: avg@postman.ncube.com (Vadim Antonov) Message-Id: <9508150257.AA21632@butler.ncube.com> To: 9fans Subject: telnetd improvements Content-Length: 2867 Sender: owner-9fans Precedence: bulk Reply-To: 9fans Hi -- i fixed the telnetd "line discipline" to make it more convinient for those who telnet into a Plan 9 system (i.e. it simulates the BSD-style kill/erase behaviour). Diffs (from 2.0 source) are: cpu% cd /sys/src/cmd/service cpu% diff telnetd.c.old telnetd.c 273a274,276 > #define BACKSPACE() { ECHO('\b'); ECHO(' '); ECHO('\b'); } > #define RUBOUT(c) { BACKSPACE(); if((c)<' ' || (c)==0177) BACKSPACE(); } > 347,350d349 < case 0x00: < if(noproto) /* telnet ignores nulls */ < *bp++ = c; < continue; 357c356 < if(start < bp) --- > if(start < bp) { 359,360c358,360 < if(opt[Echo].local) < ECHO(c); --- > if(opt[Echo].local) > RUBOUT(*bp); > } 364,369c364,368 < bp = start; < if(opt[Echo].local){ < ECHO('^'); < ECHO('U'); < ECHO('\r'); < ECHO('\n'); --- > if(opt[Echo].local) { > while (bp > start) { > bp--; > RUBOUT(*bp); > } 375,378c374 < while (--bp >= start && !alnum(*bp)) < ECHO('\b'); < while (bp >= start && alnum(*bp)) { < ECHO('\b'); --- > while (bp > start && !alnum(bp[-1])) { 379a376 > RUBOUT(*bp); 381c378,381 < bp++; --- > while (bp > start && alnum(bp[-1])) { > bp--; > BACKSPACE(); > } 386a387,389 > ECHO('\r'); > ECHO('\n'); > bp = start; 388a392,396 > case 0x00: > if(!noproto) /* telnet ignores nulls */ > break; > /*FALL THRU*/ > 390,391c398,405 < if(opt[Echo].local) < ECHO(c); --- > if(opt[Echo].local) { > if( c >= ' ' ) { > ECHO(c); > } else { > ECHO('^'); > ECHO(0x40|c); > } > } cpu% --vadim >From 9fans-outgoing-owner Tue Aug 15 03:50:07 1995 Received: by psuvax1.cse.psu.edu id <34180>; Tue, 15 Aug 1995 03:20:03 -0400 Received: from plan9.att.com ([192.20.225.252]) by psuvax1.cse.psu.edu with SMTP id <34181>; Tue, 15 Aug 1995 01:27:44 -0400 From: presotto@plan9.att.com To: 9fans Date: Mon, 14 Aug 1995 22:43:48 -0400 Subject: re: pppclient Message-Id: <95Aug15.012744edt.34181@psuvax1.cse.psu.edu> Sender: owner-9fans Precedence: bulk Reply-To: 9fans I agree, we wrote a different version for brazil. Unfortunately, they share no code except for the tcp compression. This one went out with the release in the hope that a plan 9 version would be useful to someone. It has worked talking to xylogics annex boxes. ------ original message follows ------ >From cse.psu.edu!9fans-outgoing-owner Mon Aug 14 22:42:30 EDT 1995 Received: by psuvax1.cse.psu.edu id <34220>; Mon, 14 Aug 1995 22:09:40 -0400 Received: from plan9.cs.su.oz.au ([129.78.96.2]) by psuvax1.cse.psu.edu with SMTP id <34230>; Mon, 14 Aug 1995 20:52:06 -0400 From: Boyd Roberts Date: Mon, 14 Aug 1995 19:27:36 -0400 To: 9fans@cse.psu.edu Subject: re: pppclient In-Reply-To: <199508140955.518.9.babip@plan9.cs.su.oz.au> Message-ID: <199508150927.1656.9.babis@plan9.cs.su.oz.au> Sender: owner-9fans@cse.psu.edu Precedence: bulk Reply-To: 9fans@cse.psu.edu Looking further into the IPCP code I see that its not likely to converge when negociating with my server. The configuration request/nak/reject code is just wrong. I'm not going to try and fix it any further. It just doesn't hold enough state to ensure the negociation will converge; it's nearly stateless, but not quite. >From 9fans-outgoing-owner Tue Aug 15 04:28:30 1995 Received: by colossus.cse.psu.edu id <45676>; Tue, 15 Aug 1995 03:54:41 -0400 Received: from tango.rahul.net ([192.160.13.5]) by colossus.cse.psu.edu with SMTP id <46109>; Tue, 15 Aug 1995 03:24:53 -0400 Received: from bolero.rahul.net by tango.rahul.net with SMTP id AA05626 (5.67b8/IDA-1.5 for <9fans@cse.psu.edu>); Tue, 15 Aug 1995 00:19:29 -0700 Received: from bedlam.rahul.net by bolero.rahul.net with SMTP id AA15904 (5.67b8/IDA-1.5 for <9fans@cse.psu.edu>); Tue, 15 Aug 1995 00:19:26 -0700 Received: by bedlam.rahul.net id m0si52g-0002G7C (Debian /\oo/\ Smail3.1.29.1 #29.31); Mon, 14 Aug 95 12:19 PDT Message-Id: Date: Mon, 14 Aug 1995 15:19:00 -0400 From: bhogan@bedlam.rahul.net (Bill Hogan) To: 9fans Subject: re: installing plan9 demo on a PC In-Reply-To: <95Aug14.234250edt.34205@psuvax1.cse.psu.edu> References: <95Aug14.234250edt.34205@psuvax1.cse.psu.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Sender: owner-9fans Precedence: bulk Reply-To: 9fans "j" == jmk writes: j> don't see anything obviously wrong with this (why doesn't sd!1 show up as a boot device?). j> to get 'error walking to 9dos' one of the elements in the j> path has to show up either as a non-directory or could not be found in the j> directory scan (i.e. 'plan9' isn't being found in c:). this is surprising j> because the files were obviously put there by plan9 during the first part j> of the installation. j> check the disc isn't corrupt. j> copy the plan9.ini and 9dos files to the root of c: and then try j> plan9\b sd!0!9dos j> it's a mystery. ~~~~~~~~~~~~~~~ Ok, I will take another look. I also thought it was peculiar that sd!1 was not picked up as a boot device but then I have no idea what criterion is being applied nor by whom. For that matter, I don't have a clear idea of what plan9/B *exactly* what `B' is trying to do. Also, just now I noticed something about my plan9.init that strikes me as suspicious, namely, the `rootdir' specification. j> bedlam:[*root*]/C/plan9 # cat plan9.ini j> ---------------------------------------- j> mouseport=0 j> monitor=vga j> vgasize=640x480x1 j> scsi0=type=aha1542 port=0x330 j> console=cga j> bootfile=sd!0!/plan9/9dos j> rootdir=/plan9 <-----------------------------sd!0!/plan9 ??? j> ----------------------------------------- Thank you for taking the time to reply to my question. Cheers! Bill j> scsi devices: j> ----------------- j> scsi0 = dos C: drive j> scsi1 = dos D: drive j> scsi2 = dos E: j> scsi3 = dos F: j> scsi4 = dos H: (Texel cdrom) j> boot devices: j> ----------------- j> fd!1 j> sd!0 <---------------------- why not sd!1 ? j> sd!2 j> sd!3 >From 9fans-outgoing-owner Tue Aug 15 06:01:35 1995 Received: by psuvax1.cse.psu.edu id <34181>; Tue, 15 Aug 1995 05:40:27 -0400 Received: from mailgw.claircom.com ([199.5.241.51]) by psuvax1.cse.psu.edu with SMTP id <33981>; Tue, 15 Aug 1995 05:29:02 -0400 Received: from nimo.claircom.com by mailgw.claircom.com with smtp (Smail3.1.26.7 #2) id m0siGxd-0004teC; Tue, 15 Aug 95 01:02 PDT Received: by nimo.claircom.com (Smail3.1.26.7 #2) id m0siGxc-0005ZfC; Tue, 15 Aug 95 01:02 PDT Message-Id: Date: Tue, 15 Aug 1995 04:02:00 -0400 From: fst@claircom.com (Fariborz Skip Tavakkolian) To: 9fans Subject: Acme gags, if pushed too far!!! Sender: owner-9fans Precedence: bulk Reply-To: 9fans In the pcdist version of plan9, acme gags, fairly consistently, if the second column is pushed too far to the right. The output is something like this: acme: draw: _frcanfit==0: file does not exist acme 79: suicide: sys: trap: fault write addr=0x0 pc=0x00022ab2 term% The fastest way to reproduce it, is this: [1] New a term window. [2] Start acme. [3] In the second (rightmost) column, where the directory ``/usr/none/'' is displayed, drag the mouse across the `/' while holding down the right button, and let go. This stacks a new window, below, with the contents of the root directory. [4] Now move the whole column by placing the mouse on the topmost/rightmost solid square; click and hold the right mouse button, and move the mouse (column) to the right, passed the right edge of the window. Voila. Step 3 seems to be important in causing this. If it is skipped, nothing happens. BTW, and after the fact, is this the right place for this kind of question/bug-report? -fst FYI, the system is a Toshiba T2130CT 486DX4 75Mhz, 8 MB, vga 640x480x1, with an AccuPoint (looks like a PS2) pointing device. >From 9fans-outgoing-owner Tue Aug 15 06:08:01 1995 Received: by colossus.cse.psu.edu id <46021>; Tue, 15 Aug 1995 05:47:04 -0400 Received: from tango.rahul.net ([192.160.13.5]) by colossus.cse.psu.edu with SMTP id <45582>; Tue, 15 Aug 1995 05:46:48 -0400 Received: from bolero.rahul.net by tango.rahul.net with SMTP id AA09983 (5.67b8/IDA-1.5 for <9fans@cse.psu.edu>); Tue, 15 Aug 1995 02:46:35 -0700 Received: from bedlam.rahul.net by bolero.rahul.net with SMTP id AA25495 (5.67b8/IDA-1.5 for <9fans@cse.psu.edu>); Tue, 15 Aug 1995 02:46:32 -0700 Received: by bedlam.rahul.net id m0si7L1-0002G7C (Debian /\oo/\ Smail3.1.29.1 #29.31); Mon, 14 Aug 95 14:46 PDT Message-Id: Date: Mon, 14 Aug 1995 17:46:00 -0400 From: bhogan@bedlam.rahul.net (Bill Hogan) To: 9fans Subject: [comp.os.linux.misc] Help wanted, Plan9 a piece of junk! Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Sender: owner-9fans Precedence: bulk Reply-To: 9fans ------- Start of forwarded message ------- From: xke@paul.rutgers.edu (Xiao Ke) Newsgroups: comp.os.linux.misc Subject: Help wanted, Plan9 a piece of junk! Date: 15 Aug 1995 00:10:54 -0400 Organization: Rutgers University LCSR NNTP-Posting-Host: paul.rutgers.edu Hi, there, Help wanted, Plan9, the so boasted next generation os is just a piece of junk. This time, AT&T really picked a good name for plan9. I've run linux1.2.0 for about a half year, everything seems OK. Today, I download the plan9 to play with, it looks working too. However, actually when I was installing plan9, it overwrote my linux partition without any pre-warning. My linux partition is not bootable now, and I try to boot from floppy, and do fsck on it, it says: "bad magic number". So definately plan9 overwrote my linux partition. I want to recover my more than half-year work, since I don't have tape backup. Please help! Any suggestion will be mostly appreciated. I guess this is doable, since my linux partition occupies 400Mbytes, while plan9 only occupies 20Mbytes according to its installation notes, so it looks like the rest 380Mbytes should be able to recoverd, sounds reasonable? Thanks, -----Xiao Ke xke@paul.rutgers.edu ------- End of forwarded message ------- >From 9fans-outgoing-owner Tue Aug 15 07:12:08 1995 Received: by colossus.cse.psu.edu id <46033>; Tue, 15 Aug 1995 06:39:36 -0400 Received: from staff.cs.su.OZ.AU ([129.78.8.1]) by colossus.cse.psu.edu with SMTP id <46025>; Tue, 15 Aug 1995 06:39:20 -0400 Received: from plan9.cs.su.oz.au by staff.cs.su.OZ.AU (mail from dhog for 9fans@cse.psu.edu) with MHSnet (insertion MHSnet site: staff.cs.su.oz.au); Tue, 15 Aug 1995 20:39:14 +1000 Received: from riker.plan9.cs.su.oz.au. by staff.cs.su.OZ.AU.; Tue, 15 Aug 1995 20:39:11 +1000 X-Claimed-Received: from plan9.cs.su.oz.au Date: Tue, 15 Aug 1995 06:29:18 -0400 From: dhog@cs.su.oz.au To: 9fans Subject: Re: [comp.os.linux.misc] Help wanted, Plan9 a piece of junk! Message-Id: <95Aug15.063920edt.46025@colossus.cse.psu.edu> Sender: owner-9fans Precedence: bulk Reply-To: 9fans >From: xke@paul.rutgers.edu (Xiao Ke) >Newsgroups: comp.os.linux.misc >[...] >I want to recover my more than half-year work, since I don't have tape >backup. HAHAHAHA!! Stop it, you're killing me! >Please help! Any suggestion will be mostly appreciated. >I guess this is doable, since my linux partition occupies 400Mbytes, >while plan9 only occupies 20Mbytes according to its installation notes, >so it looks like the rest 380Mbytes should be able to recoverd, sounds >reasonable? Maybe he should try Norton Utilities >From 9fans-outgoing-owner Tue Aug 15 09:38:30 1995 Received: by psuvax1.cse.psu.edu id <34112>; Tue, 15 Aug 1995 08:48:16 -0400 Received: from cegelecproj.co.uk ([159.245.72.6]) by psuvax1.cse.psu.edu with SMTP id <34040>; Tue, 15 Aug 1995 08:47:57 -0400 Received: from vampire.cegelecproj.co.uk (cerberus.cegelecproj.co.uk) by cegelecproj.co.uk (4.1/SMI-4.1) id AA22137; Tue, 15 Aug 95 13:47:33 BST Received: from phantom.cegelecproj.co.uk (phantom.limbo.cegelecproj.co.uk) by vampire.cegelecproj.co.uk (5.0/SMI-SVR4) id AA10988; Tue, 15 Aug 1995 13:47:30 +0100 Received: from phantom (localhost) by phantom.cegelecproj.co.uk (5.0/SMI-SVR4) id AA00284; Tue, 15 Aug 1995 13:47:26 +0100 Message-Id: <9508151247.AA00284@phantom.cegelecproj.co.uk> X-Mailer: exmh version 1.6.1 5/23/95 To: 9fans@cs.psu.edu Subject: sparc kernels and bootp X-Face: Iqsa(US9p?)Y^W+6Ff[Z]rM"uFE) lFDjag1e]\/#2 X-Planation: X-Faces can be viewed with Faces from cs.indiana.edu. Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 15 Aug 1995 08:47:25 -0400 From: Steve_Kilbane Content-Length: 752 Sender: owner-9fans Precedence: bulk Reply-To: 9fans I'm having hours of fun attempting to get a Sun SLC booted without going through all the usual routine of setting up a PC fileserver. This is because I haven't got a PC that (a) will work with aux/vga (b) has enough disk space for the CD-ROM. However. The basic problem is that the sparc kernel doesn't seem to be using BOOTP. I've entered the relevant stuff in bootparams on the SS2 I'm running u9fs and tftpd on, but the SLC doesn't seem to send out any requests for this info. It just prompts every time. It gets a little wearing to have to enter ip, ipmask, ipgw, etc. every time I have to reboot the SLC (which is quite often; I haven't got it all the way up yet), and I tend to make typos... So, should the sparc kernel be using BOOTP? steve >From 9fans-outgoing-owner Tue Aug 15 09:44:25 1995 Received: by colossus.cse.psu.edu id <46052>; Tue, 15 Aug 1995 09:05:30 -0400 Received: from gateway.morgan.com ([138.20.30.3]) by colossus.cse.psu.edu with SMTP id <46057>; Tue, 15 Aug 1995 08:55:25 -0400 Received: from ls5.fid.morgan.com ([138.20.110.10]) by gateway.morgan.com with SMTP id <41525>; Tue, 15 Aug 1995 08:38:06 -0400 Received: from tasmania.Morgan.COM by ls5.fid.morgan.com (4.1/MS/FID/Sun-1.3) id AA02998; Tue, 15 Aug 95 13:38:01 BST From: "David Lukes" Message-Id: <9508151338.ZM5317@morgan.com> Date: Tue, 15 Aug 1995 08:38:00 -0400 In-Reply-To: dhog@cs.su.oz.au "Re: [comp.os.linux.misc] Help wanted, Plan9 a piece of junk!" (Aug 15, 6:29) References: <95Aug15.063920edt.46025@colossus.cse.psu.edu> X-Face: ",23ZL}.AnSu!4o'e&Zi$|&rY^Py}G`e=fI&l{$n@td6#Kar.lKC9yYg$@'yxv|Pw37"-%Ax}(QJFS35S;vKtZ_JzuiK5LvmGz`S_MHpiqgR?dJ@QsE$Jn&RO-Rh|XpcAh?:x\{m%=Vad3j} HAHAHAHA!! Stop it, you're killing me! It's unfair to mock the afflicted. I must say it's nice they're teaching basic logic so well at Rutgers: Premise 1: I never back anything up. Premise 2: I don't understand the difference between an async port and my elbow. Conclusion: the operating system sucks. Very sound. Dave. >From 9fans-outgoing-owner Tue Aug 15 10:05:25 1995 Received: by psuvax1.cse.psu.edu id <34159>; Tue, 15 Aug 1995 09:39:45 -0400 Received: from plan9.att.com ([192.20.225.252]) by psuvax1.cse.psu.edu with SMTP id <34185>; Tue, 15 Aug 1995 09:37:48 -0400 From: jmk@plan9.att.com To: 9fans Date: Tue, 15 Aug 1995 09:29:25 -0400 Subject: Re: [comp.os.linux.misc] Help wanted, Plan9 a piece of junk! Message-Id: <95Aug15.093748edt.34185@psuvax1.cse.psu.edu> Sender: owner-9fans Precedence: bulk Reply-To: 9fans But wait! There's more! Path: alice!allegra!uunet!in2.uu.net!news.ios.com!tribeca.ios.com!hvaidya From: hvaidya@tribeca.ios.com (Hemant Vaidya) Newsgroups: alt.uu.comp.os.linux.questions,comp.os.linux.misc Subject: Installing Plan9 corrupted Linux root partition Date: 11 Aug 1995 18:12:59 GMT Organization: Internet Online Services Lines: 43 Message-ID: <40g6jb$raj@news.ios.com> NNTP-Posting-Host: tribeca.ios.com X-Newsreader: TIN [version 1.2 PL2] Hi Linux Experts, When I installed Plan9 on my PC it seems to have corrupted root partition on my drive. I get following error when booting from LILO or floppy. DOS partition seems OK. The kernel version is 1.2.0 gcc 2.6.3 PC configuration: P90, 16MB,1MB SCSI-II, BusLogic PCI SCSI-II controller (BT946C) Partition check: sda: sda1 sda2 sda3 sda4 [MS-DOS FS Rel. 12, FAT 102,check=n,conv=b,uid=0,gid=0,umask=022,bmap] [me=0x10,cs=0,#f=0,fs=0,fl=0,ds=0,de=53505,data=0,se=32798, ts=-63599110,ls=252] Transaction block size = 512 Kernel panic: VFS :Unable to mount root fs on 08:02 sda1 is DOS primary starting at 1 to 100 sda2 is root partition starting at cylinder 101 sda3 is swap sda4 I think was created by Plan9 sda5 is DOS logical drive D: I can still boot from slackware distribution without mounting root and using ramdisk. If I then go into fdisk (linux) I see partition info as before. If I try to mount /dev/sda2 /mnt I get error: /dev/sda2 not mountable something like that. I can mount sda1 under /mnt without problem. Is there a way to salvage my root partition or fix the problem. If you think more info is needed I can try and get it. You can reply at: hvaidya@tribeca.ios.com --Hemant >From 9fans-outgoing-owner Tue Aug 15 10:13:14 1995 Received: by colossus.cse.psu.edu id <46039>; Tue, 15 Aug 1995 09:50:37 -0400 Received: from paul.rutgers.edu ([128.6.5.53]) by colossus.cse.psu.edu with SMTP id <46087>; Tue, 15 Aug 1995 09:45:29 -0400 Received: (from xke@localhost) by paul.rutgers.edu (8.6.12+bestmx+oldruq+newsunq/8.6.12) id JAA05664 for 9fans@cse.psu.edu; Tue, 15 Aug 1995 09:07:12 -0400 Date: Tue, 15 Aug 1995 09:07:12 -0400 From: Xiao Ke Message-Id: <199508151307.JAA05664@paul.rutgers.edu> To: 9fans Subject: HELP WANTED----plan9 overwrote linux partition Sender: owner-9fans Precedence: bulk Reply-To: 9fans Hi, there, Help wanted, Plan9, the so boasted next generation os is just a piece of junk. This time, AT&T really picked a good name for plan9. I've run linux1.2.0 for about a half year, everything seems OK. Today, I download the plan9 to play with, it looks working too. However, actually when I was installing plan9, it overwrote my linux partition without any pre-warning. My linux partition is not bootable now, and I try to boot from floppy, and do fsck on it, it says: "bad magic number". So definately plan9 overwrote my linux partition. I want to recover my more than half-year work, since I don't have tape backup. Please help! Any suggestion will be mostly appreciated. I guess this is doable, since my linux partition occupies 400Mbytes, while plan9 only occupies 20Mbytes according to its installation notes, so it looks like the rest 380Mbytes should be able to recoverd, sounds reasonable? Thanks, -----Xiao Ke xke@paul.rutgers.edu >From 9fans-outgoing-owner Tue Aug 15 10:31:25 1995 Received: by psuvax1.cse.psu.edu id <34154>; Tue, 15 Aug 1995 10:05:01 -0400 Received: from plan9.att.com ([192.20.225.252]) by psuvax1.cse.psu.edu with SMTP id <34178>; Tue, 15 Aug 1995 09:37:35 -0400 From: jmk@plan9.att.com To: 9fans Date: Tue, 15 Aug 1995 08:59:37 -0400 Subject: re: installing plan9 demo on a PC Message-Id: <95Aug15.093735edt.34178@psuvax1.cse.psu.edu> Sender: owner-9fans Precedence: bulk Reply-To: 9fans I also thought it was peculiar that sd!1 was not picked up as a boot device but then I have no idea what criterion is being applied nor by whom. For that matter, I don't have a clear idea of what plan9/B *exactly* what `B' is trying to do. man b.com. man pages are available at http://plan9.att.com/plan9/mansearch.html. Also, just now I noticed something about my plan9.init that strikes me as suspicious, namely, the `rootdir' specification. this name is within the boot device so does not require a 'device!ctrlno' prefix. >From 9fans-outgoing-owner Tue Aug 15 10:35:38 1995 Received: by colossus.cse.psu.edu id <46087>; Tue, 15 Aug 1995 10:13:08 -0400 Received: from konrad.lysator.liu.se ([130.236.253.6]) by colossus.cse.psu.edu with SMTP id <46123>; Tue, 15 Aug 1995 09:46:19 -0400 Received: from kamelen.lysator.liu.se (kamelen.lysator.liu.se [130.236.254.87]) by konrad.lysator.liu.se (8.6.11/8.6.11) with ESMTP id PAA13928 for <9fans@cse.psu.edu>; Tue, 15 Aug 1995 15:28:38 +0200 Received: (ture@localhost) by kamelen.lysator.liu.se (8.6.11/8.6.11) id PAA26522; Tue, 15 Aug 1995 15:28:31 +0200 Date: Tue, 15 Aug 1995 09:28:31 -0400 Message-Id: <199508151328.PAA26522@kamelen.lysator.liu.se> From: Ture P}lsson To: 9fans In-reply-to: <95Aug15.063920edt.46025@colossus.cse.psu.edu> (dhog@cs.su.oz.au) Subject: Re: [comp.os.linux.misc] Help wanted, Plan9 a piece of junk! Sender: owner-9fans Precedence: bulk Reply-To: 9fans > >[...] > >I want to recover my more than half-year work, since I don't have tape > >backup. > > HAHAHAHA!! Stop it, you're killing me! Seriously, I don't like the way the 4-disk set is supposed to magically figure out what partition on my disk to install on. I have a farily complicated partition setup, and I want to tell Plan 9 to "go onto /dev/hda3, period!" (Or whatever Plan 9 calls the third partition on the first disk). However, I haven't managed to get as far as actually installing the thing. During the fist stage, copying files to C:\PLAN9, it says "problem copying file: file does not exist" about a file which most certainly is on the floppy -- both DOS and Linux can read it. (Naturally, I left my notes at home so I don't remember the exact name of the file...) After rebooting into DOS, there's no trace of Plan9 on C:, but when I reboot from the first Plan9 floppy it tells me that Plan9 is already on my disk, and asks whether I want to reconfigure. I'm beginning to suspect that the installation program somehow gets confused by my setup, and tries to copy the floppy onto itself, or something similarly stupid. Is that possible? I _am_ two megabytes showt of RAM (i.e, I have only 6 MB). Is 8 Mbytes a "hard" limit, or is it just a "it-will-run-but-not-very-fast" limit? (Even Solaris can run in 8 Mbytes, and I though Plan9 was supposed to be small?) My setup is: Noname asian-made 386+387sx, AMI BIOS, Trident 8900C, two Seagate IDE disks (102 + 545 Mbytes, on the same controller), one 3.5" (known by dos as A:) and one 5.25" floppy. >From 9fans-outgoing-owner Tue Aug 15 11:08:05 1995 Received: by psuvax1.cse.psu.edu id <34201>; Tue, 15 Aug 1995 10:35:11 -0400 Received: from plan9.cs.york.ac.uk ([144.32.33.120]) by psuvax1.cse.psu.edu with SMTP id <34209>; Tue, 15 Aug 1995 10:04:12 -0400 From: forsyth@plan9.cs.york.ac.uk To: 9fans Date: Tue, 15 Aug 1995 09:52:46 -0400 Subject: re: sparc kernels and bootp Message-Id: <95Aug15.100412edt.34209@psuvax1.cse.psu.edu> Sender: owner-9fans Precedence: bulk Reply-To: 9fans bootparams has nothing to do with BOOTP. bootparams is used by sun's very own /usr/etc/rpc.bootparamd, which uses SUN RPC/XDR. actually, i'm curious how you encoded the information in bootparams. anyhow, pick up the Unix bootp daemon from plan9.att.com in /plan9/unixsrc/bootp/ . that version replies correctly to a plan 9 bootp request (there's a convention for `vendor specific' data). the daemon might require changes to work on a Sun. most things do. the sparc Plan 9 kernel is the same as all the others in its use of bootp (that part is in portable code). >From 9fans-outgoing-owner Tue Aug 15 11:18:42 1995 Received: by colossus.cse.psu.edu id <46121>; Tue, 15 Aug 1995 10:39:15 -0400 Received: from sangam.ncst.ernet.in ([144.16.11.1]) by colossus.cse.psu.edu with SMTP id <46126>; Tue, 15 Aug 1995 09:50:14 -0400 Received: from iisc.ernet.in (iisc.iisc.ernet.in [144.16.64.3]) by sangam.ncst.ernet.in (8.6.12/8.6.6) with SMTP id TAA26594 for <9fans@cse.psu.edu>; Tue, 15 Aug 1995 19:00:41 +0530 Received: from vigyan.UUCP by iisc.ernet.in (ERNET-IISc/SMI-4.1) id AA26629; Tue, 15 Aug 95 19:04:22+0530 Received: by vigyan.iisc.ernet.in (smail2.3) id AA06252; 14 Aug 95 12:17:51 EDT (Mon) Received: from india29.sasi by sasi.ernet.in (4.1/SMI-4.1) id AA06546; Mon, 14 Aug 95 09:52:13+050 From: kp@sasi.ernet.in (Kiran Pamnany) Received: (kp@localhost) by india29.sasi (8.6.12/SMI-4.1) id JAA10103 for 9fans@cse.psu.edu; Mon, 14 Aug 1995 09:52:12 +0500 Date: Mon, 14 Aug 1995 00:52:12 -0400 Message-Id: <199508140452.JAA10103@india29.sasi> To: 9fans Subject: PC installation problems Sender: owner-9fans Precedence: bulk Reply-To: 9fans peterw wrote: > > - The system: > a PC compatiable with a Pentium735 chip, and 853 MB IDE drive. > Made a partition of 80 MB (C drive) and DOS formatted, leaving > the rest of the hard disk to plan9. > > - How the problem started: > plan9 runs perfectly until I added additional hard disks and then > did partitions from C:\ using fdisk of DOS command. > > - Symptom: > when run plan9 from DOS, c:\plan9\b.com, get error message on screen, > .bad majic 0xf6xxxxxx not a plan 9 executable! > boot from: > > - Question: > How to recover? > And jmk replied: > > when you see the 'boot from: ' prompt does it give a list of boot devices > on the previous line? if so, what does it give? > I have a similar problem, and I'd asked for help: > I have this weird problem with the four diskette PC distribution. When I > run plan9\b after installing the three diskettes, it says: > > '.bad magic 0xeb3e01eb not a plan 9 executable!' > > It then told me that the available boot devices were e!0, hd!0 (my work > disk) and h!1 (the plan9 disk) and asked me which to boot from. Typing in > h!1 repeats the problem and obviously the other two are useless. > > > The hardware is an Opti motherboard with a P54C 90MHz processor, 16 MB of > RAM, a Diamond Stealth 64 DRAM in a PCI slot. The hard disks are driven off > an IDE controller in a PCI slot (I'm not sure which). The first disk is a > Quantum Maverick 540A which has DOS 6.22 and OS/2 Warp co-existing on a FAT > partition and the second disk is a Maxtor 7120AT which I want to use > exclusively for Plan 9 -- it has no partitions. I didn't run fdisk at all after completing the Plan 9 installation,, it said it was writing a kernel to the partition, I selected the option to make 'this' the default plan 9 partition, selected reboot and from the DOS prompt immediately tried plan9\b. There doesn't seem to have been any chance for the boot partition to get overwritten in this case. presotto had suggested: > > Try booting with > > plan9\b h!1!boot > > and see if it makes a difference. If not, I'll have to give you something > more extensive to try. > I tried that and had the same problem. I'd replied to this mail but the answer probably got lost,, our internet gateway was down all of last week. Any ideas? Kiran >From 9fans-outgoing-owner Tue Aug 15 11:44:28 1995 Received: by psuvax1.cse.psu.edu id <34189>; Tue, 15 Aug 1995 11:09:19 -0400 Received: from symbionics.co.uk ([158.43.6.17]) by psuvax1.cse.psu.edu with SMTP id <34183>; Tue, 15 Aug 1995 11:07:20 -0400 Received: from sympc143 ([194.32.100.46]) by symbionics.co.uk (4.1/SMI-4.1) id AA25617; Tue, 15 Aug 95 15:51:24 BST Message-Id: <9508151451.AA25617@symbionics.co.uk> Comments: Authenticated sender is From: "Nigel Roles" Organization: Symbionics Communications To: 9fans Date: Tue, 15 Aug 1995 11:51:19 -0400 Subject: Re: HELP WANTED----plan9 overwrote linux partition Priority: normal X-Mailer: Pegasus Mail for Windows (v2.01) Sender: owner-9fans Precedence: bulk Reply-To: 9fans > Hi, there, > > Help wanted, Plan9, the so boasted next generation os is just a piece of > junk. This time, AT&T really picked a good name for plan9. > > I've run linux1.2.0 for about a half year, everything seems OK. > Today, I download the plan9 to play with, it looks working too. > However, actually when I was installing plan9, it overwrote my linux > partition without any pre-warning. > Oh dear. The installation instructions referenced in http://www.plan9.att.com/distrib.html implored people to read the errata document. In particular, a new version of prep (the disk partitioner) is required to avoid this. The original version installs after the highest numbered DOS active partiton. Evidently your Linux partition is after your DOS partition. > My linux partition is not bootable now, and I try to boot from floppy, > and do fsck on it, it says: "bad magic number". So definately > plan9 overwrote my linux partition. > Yes no question that your Linux partition is totalled. > I want to recover my more than half-year work, since I don't have tape > backup. Please help! Any suggestion will be mostly appreciated. > I guess this is doable, since my linux partition occupies 400Mbytes, > while plan9 only occupies 20Mbytes according to its installation notes, > so it looks like the rest 380Mbytes should be able to recoverd, sounds > reasonable? > Unfortunately, again, the installation documents are clear that Plan 9 will occupy ALL the space at the 'end' of the disk, not just 20Mb. 20Mb was a minimum requirement, not a maxiumum. I guess you need help from the Linux community to help recover the data. It appears that you are not the only person. The free demo version of Plan 9 was issued for people to work out whether it would work on their machines before buying the full version, because Plan 9 is not intended to be as PC compatible as Linux is. Under such restrictions it was perhaps a bit rash to install it on a valued machine without a backup. Good luck with recovering your data. >From 9fans-outgoing-owner Tue Aug 15 11:59:38 1995 Received: by colossus.cse.psu.edu id <46112>; Tue, 15 Aug 1995 11:24:24 -0400 Received: from nixpbe.pdb.sni.de ([192.109.2.33]) by colossus.cse.psu.edu with SMTP id <46074>; Tue, 15 Aug 1995 10:37:04 -0400 Received: (from nerv@localhost) by nixpbe.pdb.sni.de (8.6.12/8.6.12) id QAA08850 for 9fans@cse.psu.edu; Tue, 15 Aug 1995 16:26:54 +0200 Message-Id: <199508151426.QAA08850@nixpbe.pdb.sni.de> Subject: Re: HELP WANTED----plan9 overwrote linux partition To: 9fans Date: Tue, 15 Aug 1995 12:25:53 -0400 From: suhr In-Reply-To: <199508151307.JAA05664@paul.rutgers.edu>; from "Xiao Ke" at Aug 15, 95 9:07 am X-Mailer: xmail 2.4 (based on ELM 2.2 PL16) Sender: owner-9fans Precedence: bulk Reply-To: 9fans > Hi, there, > > Help wanted, Plan9, the so boasted next generation os is just a piece of > junk. This time, AT&T really picked a good name for plan9. > > I've run linux1.2.0 for about a half year, everything seems OK. > Today, I download the plan9 to play with, it looks working too. > However, actually when I was installing plan9, it overwrote my linux > partition without any pre-warning. > > My linux partition is not bootable now, and I try to boot from floppy, > and do fsck on it, it says: "bad magic number". So definately > plan9 overwrote my linux partition. Sorry Sir, this is a mailing list for Plan9 users not for UNIX beginners. Bye, Andre >From 9fans-outgoing-owner Tue Aug 15 12:17:11 1995 Received: by psuvax1.cse.psu.edu id <34097>; Tue, 15 Aug 1995 11:41:16 -0400 Received: from symbionics.co.uk ([158.43.6.17]) by psuvax1.cse.psu.edu with SMTP id <34212>; Tue, 15 Aug 1995 11:05:39 -0400 Received: from sympc143 ([194.32.100.46]) by symbionics.co.uk (4.1/SMI-4.1) id AA25191; Tue, 15 Aug 95 15:10:13 BST Message-Id: <9508151410.AA25191@symbionics.co.uk> Comments: Authenticated sender is From: "Nigel Roles" Organization: Symbionics Communications To: 9fans Date: Tue, 15 Aug 1995 11:10:10 -0400 Subject: Re: [comp.os.linux.misc] Help wanted, Plan9 a piece of junk Priority: normal X-Mailer: Pegasus Mail for Windows (v2.01) Sender: owner-9fans Precedence: bulk Reply-To: 9fans > > HAHAHAHA!! Stop it, you're killing me! > > It's unfair to mock the afflicted. > > I must say it's nice they're teaching basic logic so well at Rutgers: > > Premise 1: I never back anything up. > Premise 2: I don't understand the difference between an async port and my > elbow. > Conclusion: the operating system sucks. > > Very sound. > Dave. Sounds like he used the original version of prep; the one with the "erase all inferior operating systems barring MSDOS" option. >From 9fans-outgoing-owner Tue Aug 15 12:53:16 1995 Received: by psuvax1.cse.psu.edu id <34217>; Tue, 15 Aug 1995 12:27:49 -0400 Received: from cegelecproj.co.uk ([159.245.72.6]) by psuvax1.cse.psu.edu with SMTP id <34219>; Tue, 15 Aug 1995 12:15:39 -0400 Received: from vampire.cegelecproj.co.uk (cerberus.cegelecproj.co.uk) by cegelecproj.co.uk (4.1/SMI-4.1) id AA25564; Tue, 15 Aug 95 17:01:48 BST Received: from phantom.cegelecproj.co.uk (phantom.limbo.cegelecproj.co.uk) by vampire.cegelecproj.co.uk (5.0/SMI-SVR4) id AA11206; Tue, 15 Aug 1995 17:01:43 +0100 Received: from phantom (localhost) by phantom.cegelecproj.co.uk (5.0/SMI-SVR4) id AA00714; Tue, 15 Aug 1995 17:01:38 +0100 Message-Id: <9508151601.AA00714@phantom.cegelecproj.co.uk> X-Mailer: exmh version 1.6.1 5/23/95 To: 9fans@cs.psu.edu Subject: shutdown X-Face: Iqsa(US9p?)Y^W+6Ff[Z]rM"uFE) lFDjag1e]\/#2 X-Planation: X-Faces can be viewed with Faces from cs.indiana.edu. Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 15 Aug 1995 12:01:38 -0400 From: Steve_Kilbane Content-Length: 549 Sender: owner-9fans Precedence: bulk Reply-To: 9fans Ok, I have my SLC running a window system, with the filesystem all mounted from a UNIX box via u9fs. I guess I don't need to do anything special to halt this SLC, except turn it off? Right now, it's running as none anyway, so (i believe) the filesystem is read-only anyway. The PC installation document only seems to mention kfscmd halt before rebooting, but the SLC isn't running that. There's also the fact that (as far as I can tell) there isn't any way for the SLC to produce a corrupt filesystem at the other end of a u9fs connection. steve >From 9fans-outgoing-owner Tue Aug 15 12:57:13 1995 Received: by colossus.cse.psu.edu id <46075>; Tue, 15 Aug 1995 12:28:07 -0400 Received: from tango.rahul.net ([192.160.13.5]) by colossus.cse.psu.edu with SMTP id <46123>; Tue, 15 Aug 1995 12:18:58 -0400 Received: from bolero.rahul.net by tango.rahul.net with SMTP id AA26961 (5.67b8/IDA-1.5 for <9fans@cse.psu.edu>); Tue, 15 Aug 1995 09:09:39 -0700 Received: by bolero.rahul.net id AA11493 (5.67b8/IDA-1.5 for 9fans@cse.psu.edu); Tue, 15 Aug 1995 09:09:38 -0700 Date: Tue, 15 Aug 1995 12:09:37 -0400 From: Bill Hogan Subject: re: installing plan9 demo on a PC To: 9fans Cc: 9fans In-Reply-To: <95Aug15.093735edt.34178@psuvax1.cse.psu.edu> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-9fans Precedence: bulk Reply-To: 9fans On Tue, 15 Aug 1995 jmk@plan9.att.com wrote: [apropos my comment that] > I also thought it was peculiar that sd!1 was not picked up as a > boot device but then I have no idea what criterion is being applied nor > by whom. > > For that matter, I don't have a clear idea of what plan9/B > is trying to do. [this:] > maqn b.com. man pages are available at http://plan9.att.com/plan9/mansearch.html. What does this mean "are available"? Available for downloading? Available for on-line browsing (which I have tried and only gets me "can't access document" messages from lynx)? Thank you. Bill >From 9fans-outgoing-owner Tue Aug 15 13:22:30 1995 Received: by psuvax1.cse.psu.edu id <34221>; Tue, 15 Aug 1995 12:51:03 -0400 Received: from plan9.att.com ([192.20.225.252]) by psuvax1.cse.psu.edu with SMTP id <34229>; Tue, 15 Aug 1995 12:15:04 -0400 From: rob@plan9.att.com To: 9fans Date: Tue, 15 Aug 1995 11:55:01 -0400 Subject: Re: Acme gags, if pushed too far!!! Message-Id: <95Aug15.121504edt.34229@psuvax1.cse.psu.edu> Sender: owner-9fans Precedence: bulk Reply-To: 9fans This is a silly bug with no easy guaranteed fix. The code has a check against the problem but it's too lax. Change the appearances of the value 20 in /sys/src/cmd/acme/rows.l to 80 and that should cover most cases. A proper fix involves rewriting the underlying frame library, which may happen someday but not anytime soon. I have placed the diffs in the errata web page. It's not worth posting a new binary; just avoid making columns so uselessly narrow. -rob >From 9fans-outgoing-owner Tue Aug 15 13:23:43 1995 Received: by colossus.cse.psu.edu id <46085>; Tue, 15 Aug 1995 12:56:39 -0400 Received: from glacier.MIT.EDU ([18.248.0.54]) by colossus.cse.psu.edu with SMTP id <46082>; Tue, 15 Aug 1995 12:20:34 -0400 Received: (from ghudson@localhost) by glacier.MIT.EDU (8.6.11/8.6.11) id KAA07593; Tue, 15 Aug 1995 10:53:59 -0400 Message-Id: <199508151453.KAA07593@glacier.MIT.EDU> To: 9fans Subject: Re: [comp.os.linux.misc] Help wanted, Plan9 a piece of junk! In-reply-to: Your message of "Tue, 15 Aug 1995 09:28:31 EDT." <199508151328.PAA26522@kamelen.lysator.liu.se> Date: Tue, 15 Aug 1995 10:53:58 -0400 From: Greg Hudson Sender: owner-9fans Precedence: bulk Reply-To: 9fans > Seriously, I don't like the way the 4-disk set is supposed to > magically figure out what partition on my disk to install on. For what it's worth, after testing the Plan 9 4-disk set on a machine here at MIT, we also noticed the Linux partition wiped, even though we had cleared up room on the first IDE disk after the DOS partition. (We're good about not keeping important data on non-backed-up storage, though; there wasn't really anything there besides the operating system.) Bad business, very bad. >From 9fans-outgoing-owner Tue Aug 15 13:39:52 1995 Received: by psuvax1.cse.psu.edu id <34161>; Tue, 15 Aug 1995 13:19:22 -0400 Received: from postman.ncube.com ([134.242.8.47]) by psuvax1.cse.psu.edu with SMTP id <34162>; Tue, 15 Aug 1995 12:17:57 -0400 Received: from garcon.ncube.com by postman.ncube.com (4.1/SMI-4.1) id AA00596; Tue, 15 Aug 95 08:09:21 PDT Received: from pejs.ncube.com by garcon.ncube.com (5.x/SMI-SVR4) id AA12807; Tue, 15 Aug 1995 08:09:20 -0700 Date: Tue, 15 Aug 1995 11:09:20 -0400 From: sch@postman.ncube.com (Steve Hemminger) Message-Id: <9508151509.AA12807@garcon.ncube.com> Received: by pejs.ncube.com (4.1/SMI-4.1) id AA05858; Tue, 15 Aug 95 08:10:00 PDT To: 9fans Subject: floppy boot on Pentium Sender: owner-9fans Precedence: bulk Reply-To: 9fans Booting directly from floppy (like the 1st disk of the 4 disk set) does not work on our Pentium PC's when they are running at full speed. It gets part way through the load and fails with "premature EOF" (fails at different point every time). It does work if: - turn off cache (in BIOS) - or set clock rate to 25Mhz - or boot DOS then run b Looks like the boot block program is not setting up something related to the floppy controller (or has a silly spin loop). -sch >From 9fans-outgoing-owner Tue Aug 15 13:52:52 1995 Received: by colossus.cse.psu.edu id <46021>; Tue, 15 Aug 1995 13:34:47 -0400 Received: from icc-fw.integctr.com ([204.181.192.3]) by colossus.cse.psu.edu with SMTP id <46182>; Tue, 15 Aug 1995 13:28:13 -0400 Date: Tue, 15 Aug 1995 13:22:55 -0400 From: Brian Rogers To: Xiao Ke cc: 9fans, Roger Davenport , John Chamberlain Subject: Re: HELP WANTED----plan9 overwrote linux partition In-Reply-To: <199508151307.JAA05664@paul.rutgers.edu> Message-ID: Organization: The Integrity Center (214)484-6140 (800)456-1811 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-9fans Precedence: bulk Reply-To: 9fans [ Cc's are being sent to others who might get a laugh out of this. ] On Tue, 15 Aug 1995, Xiao Ke wrote: > Help wanted, Plan9, the so boasted next generation os is just a piece of > junk. This time, AT&T really picked a good name for plan9. > > I've run linux1.2.0 for about a half year, everything seems OK. > Today, I download the plan9 to play with, it looks working too. > However, actually when I was installing plan9, it overwrote my linux > partition without any pre-warning. ----- RTFM ----- If you had read the ERRATA, you would have known about this and known how to avoid it. I didn't read the ERRATA and my Linux partition was also blasted, but I don't blame Plan 9. I blame my impatience and over-confidence. How can you complain about a product that you didn't pay for? Also, AT&T warns the world that Plan 9 is only for research and educational purposes; it is not a production OS and AT&T has warned us that they will not support it. How can you complain about the behavior of product that is unsupported? Also, how can you deride the OS just because of this? Unix had the same start. You and I should have been more careful. We should have known better than to trust such a product so much. When I discovered the damage that the installation had done, I was upset but not indignant; after all, I hadn't even read the instructions or looked for warnings. I had seen ERRATA and failed to read it. Remember, it's not necessarily safe sex just because the girl is pretty. Also, you should have backed up your valuable files beforehand. This is strictly common sense and no one's responsibility but yours. ----- RTFM ----- /* Brian Rogers -- tech admin, coffee achiever -- brogers@integctr.com */ /* The Integrity Center -- "objective risk management information" */ /* http://www.integctr.com/ -- info@integctr.com */ /* (214)484-6140 (800)456-1811 FAX (214)484-6381 FOD (214)484-2147 */ >From 9fans-outgoing-owner Tue Aug 15 14:01:52 1995 Received: by psuvax1.cse.psu.edu id <34166>; Tue, 15 Aug 1995 13:38:05 -0400 Received: from plan9.att.com ([192.20.225.252]) by psuvax1.cse.psu.edu with SMTP id <34200>; Tue, 15 Aug 1995 12:23:25 -0400 From: presotto@plan9.att.com To: 9fans Date: Tue, 15 Aug 1995 11:24:01 -0400 Subject: Re: [comp.os.linux.misc] Help wanted, Plan9 a piece of junk! Message-Id: <95Aug15.122325edt.34200@psuvax1.cse.psu.edu> Sender: owner-9fans Precedence: bulk Reply-To: 9fans Love that subject... Since everything in Plan 9 is a file, the message 'file does not exist' is probably the least useful and most seen message. It would be nice to know what file is not copying over. Also, it would be helpful to see what if anything does manage to get into c:\plan9. You don't happen to have a DOS compressed file system do you? >From 9fans-outgoing-owner Tue Aug 15 15:09:54 1995 Received: by psuvax1.cse.psu.edu id <34174>; Tue, 15 Aug 1995 14:30:01 -0400 Received: from plan9.att.com ([192.20.225.252]) by psuvax1.cse.psu.edu with SMTP id <34286>; Tue, 15 Aug 1995 14:08:10 -0400 From: jmk@plan9.att.com To: 9fans Date: Tue, 15 Aug 1995 13:36:38 -0400 Subject: re: installing plan9 demo on a PC Message-Id: <95Aug15.140810edt.34286@psuvax1.cse.psu.edu> Sender: owner-9fans Precedence: bulk Reply-To: 9fans >> man b.com. man pages are available at >> http://plan9.att.com/plan9/mansearch.html. >What does this mean "are available"? >Available for downloading? >Available for on-line browsing (which I have tried and only gets me >"can't access document" messages from lynx)? 1) the plan9 home page http://plan9.att.com/plan9/ mentions the ftp archive which includes the man pages; 2) follow the link on the home page for the distribution and then for installing the distribution. that page has a link to the b.com(8) page. >From 9fans-outgoing-owner Tue Aug 15 17:44:22 1995 Received: by psuvax1.cse.psu.edu id <34040>; Tue, 15 Aug 1995 17:18:24 -0400 Received: from plan9.att.com ([192.20.225.252]) by psuvax1.cse.psu.edu with SMTP id <33962>; Tue, 15 Aug 1995 17:17:52 -0400 From: jmk@plan9.att.com To: 9fans Date: Tue, 15 Aug 1995 17:13:10 -0400 Subject: re: floppy boot on Pentium Message-Id: <95Aug15.171752edt.33962@psuvax1.cse.psu.edu> Sender: owner-9fans Precedence: bulk Reply-To: 9fans I've applied the dma overrun fix to b.com, the boostrap programme. A new image of disk1 is available via ftp, disk1.3. When we were testing the distribution there was one system that consistently gave truly appalling floppy performance and we could never pin down why, it was an NCR Globalyst 600 with a P90. We have other 90MHz systems that give no trouble. ------ original message follows ------ >From cse.psu.edu!9fans-outgoing-owner Tue Aug 15 13:44:02 EDT 1995 Received: by psuvax1.cse.psu.edu id <34161>; Tue, 15 Aug 1995 13:19:22 -0400 Received: from postman.ncube.com ([134.242.8.47]) by psuvax1.cse.psu.edu with SMTP id <34162>; Tue, 15 Aug 1995 12:17:57 -0400 Received: from garcon.ncube.com by postman.ncube.com (4.1/SMI-4.1) id AA00596; Tue, 15 Aug 95 08:09:21 PDT Received: from pejs.ncube.com by garcon.ncube.com (5.x/SMI-SVR4) id AA12807; Tue, 15 Aug 1995 08:09:20 -0700 Date: Tue, 15 Aug 1995 11:09:20 -0400 From: sch@postman.ncube.com (Steve Hemminger) Message-Id: <9508151509.AA12807@garcon.ncube.com> Received: by pejs.ncube.com (4.1/SMI-4.1) id AA05858; Tue, 15 Aug 95 08:10:00 PDT To: 9fans@cse.psu.edu Subject: floppy boot on Pentium Sender: owner-9fans@cse.psu.edu Precedence: bulk Reply-To: 9fans@cse.psu.edu Booting directly from floppy (like the 1st disk of the 4 disk set) does not work on our Pentium PC's when they are running at full speed. It gets part way through the load and fails with "premature EOF" (fails at different point every time). It does work if: - turn off cache (in BIOS) - or set clock rate to 25Mhz - or boot DOS then run b Looks like the boot block program is not setting up something related to the floppy controller (or has a silly spin loop). -sch >From 9fans-outgoing-owner Wed Aug 16 09:53:13 1995 Received: by colossus.cse.psu.edu id <46164>; Wed, 16 Aug 1995 09:30:47 -0400 Received: from tango.rahul.net ([192.160.13.5]) by colossus.cse.psu.edu with SMTP id <46191>; Wed, 16 Aug 1995 09:29:39 -0400 Received: from bolero.rahul.net by tango.rahul.net with SMTP id AA19162 (5.67b8/IDA-1.5 for <9fans@cse.psu.edu>); Tue, 15 Aug 1995 21:53:11 -0700 Received: from bedlam.rahul.net by bolero.rahul.net with SMTP id AA29125 (5.67b8/IDA-1.5 for <9fans@cse.psu.edu>); Tue, 15 Aug 1995 21:53:07 -0700 Received: by bedlam.rahul.net id m0siPEY-0002G7C (Debian /\oo/\ Smail3.1.29.1 #29.31); Tue, 15 Aug 95 09:52 PDT Message-Id: Date: Tue, 15 Aug 1995 12:52:00 -0400 From: bhogan@bedlam.rahul.net (Bill Hogan) To: 9fans Subject: Re: HELP WANTED----plan9 overwrote linux partition In-Reply-To: <9508151451.AA25617@symbionics.co.uk> References: <9508151451.AA25617@symbionics.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Sender: owner-9fans Precedence: bulk Reply-To: 9fans "NR" == Nigel Roles writes: >> Hi, there, >> >> Help wanted, Plan9, the so boasted next generation os is just a piece of >> junk. This time, AT&T really picked a good name for plan9. >> >> I've run linux1.2.0 for about a half year, everything seems OK. >> Today, I download the plan9 to play with, it looks working too. >> However, actually when I was installing plan9, it overwrote my linux >> partition without any pre-warning. >> NR> Oh dear. The installation instructions referenced in NR> http://www.plan9.att.com/distrib.html implored people to read the NR> errata document. In particular, a new version of prep (the disk NR> partitioner) is required to avoid this. The original version installs after the NR> highest numbered DOS active partiton. Evidently your Linux partition NR> is after your DOS partition. >> My linux partition is not bootable now, and I try to boot from floppy, >> and do fsck on it, it says: "bad magic number". So definately >> plan9 overwrote my linux partition. >> NR> Yes no question that your Linux partition is totalled. >> I want to recover my more than half-year work, since I don't have tape >> backup. Please help! Any suggestion will be mostly appreciated. >> I guess this is doable, since my linux partition occupies 400Mbytes, >> while plan9 only occupies 20Mbytes according to its installation notes, >> so it looks like the rest 380Mbytes should be able to recoverd, sounds >> reasonable? >> NR> Unfortunately, again, the installation documents are clear that Plan NR> 9 will occupy ALL the space at the 'end' of the disk, not just 20Mb. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Excuse me, but exactly where does it say that? For example, where errata.html says, "Installation from diskettes works correctly only on systems with a single DOS partition. On systems with multiple partitions, Plan 9 will install over the second through last partitions." it is only with the benefit of hindsight and considerable effort (forgetting such things as "hop over", "skip over", "jump over", "pass over", etc.) that I can discern in the phrase "Plan 9 will install over the second through last partitions" the idea that Plan 9 will *DESTROY* my second through the last partitions -- so when it goes on to say "If you have multiple partitions, pick up ftp://plan9.att.com/plan9/pcdist/prep. After the installation step entitled Installing diskette 1 on your DOS hard drive, return to DOS. Copy the new prep onto C:\plan9\386\bin\disk\prep. Then continue with the Plan 9 installation." and then assures me "This will ensure that any newly created partition will occupy the unallocated portion at the high end of the disk, avoiding existing DOS partitions." I am even now quite frankly not convinced I should believe it. For one thing, what does "the high end of the disk" mean when I have four SCSI hard drives, and what does "[thus] avoiding existing DOS partitions" mean three of those four drives contain a mixture of FAT, HPFS, and Linux partitions? Believe me, if plan9 wiped out every partition after the first one on my C: drive, and every partition on each of my three remaining drives, the internet would never hear the end of it. Bill >From 9fans-outgoing-owner Wed Aug 16 10:09:21 1995 Received: by colossus.cse.psu.edu id <46110>; Wed, 16 Aug 1995 09:52:25 -0400 Received: from tango.rahul.net ([192.160.13.5]) by colossus.cse.psu.edu with SMTP id <46109>; Wed, 16 Aug 1995 09:29:56 -0400 Received: from bolero.rahul.net by tango.rahul.net with SMTP id AA16471 (5.67b8/IDA-1.5 for <9fans@cse.psu.edu>); Tue, 15 Aug 1995 21:01:05 -0700 Received: from bedlam.rahul.net by bolero.rahul.net with SMTP id AA24790 (5.67b8/IDA-1.5 for <9fans@cse.psu.edu>); Tue, 15 Aug 1995 21:01:02 -0700 Received: by bedlam.rahul.net id m0siOQA-0002G7C (Debian /\oo/\ Smail3.1.29.1 #29.31); Tue, 15 Aug 95 09:00 PDT Message-Id: Date: Tue, 15 Aug 1995 12:00:00 -0400 From: bhogan@bedlam.rahul.net (Bill Hogan) To: 9fans Subject: Re: [comp.os.linux.misc] Help wanted, Plan9 a piece of junk! In-Reply-To: <199508151328.PAA26522@kamelen.lysator.liu.se> References: <95Aug15.063920edt.46025@colossus.cse.psu.edu> <199508151328.PAA26522@kamelen.lysator.liu.se> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Sender: owner-9fans Precedence: bulk Reply-To: 9fans "l" == lsson writes: >> >[...] >> >I want to recover my more than half-year work, since I don't have tape >> >backup. >> l> Seriously, I don't like the way the 4-disk set is supposed to l> magically figure out what partition on my disk to install on. I have a l> fairly complicated partition setup, and I want to tell Plan 9 to "go l> onto /dev/hda3, period!" (Or whatever Plan 9 calls the third partition l> on the first disk). ... Absolutely. Bill >From 9fans-outgoing-owner Wed Aug 16 10:20:07 1995 Received: by psuvax1.cse.psu.edu id <34239>; Wed, 16 Aug 1995 09:36:35 -0400 Received: from plan9.cs.york.ac.uk ([144.32.33.120]) by psuvax1.cse.psu.edu with SMTP id <33971>; Wed, 16 Aug 1995 09:27:15 -0400 From: forsyth@plan9.cs.york.ac.uk To: 9fans@cs.psu.edu Date: Tue, 15 Aug 1995 21:12:38 -0400 Subject: Re: [comp.os.linux.misc] Help wanted, Plan9 a piece of junk! Message-Id: <95Aug16.092715edt.33971@psuvax1.cse.psu.edu> Sender: owner-9fans Precedence: bulk Reply-To: 9fans You should be glad that bridge fell down -- I was planning to build 13 more to the same design. Remark attributed to I.K. Brunel, addressing the Directors of the Great Western Railway (i think i saw it first in one of P J Brown's books, but i'm not sure.) i've been told that windows 95 will also scribble over a linux partition given half a chance. clearly, people have it in for linux. anyhow, i expect in consequence to see lots of articles about Plan 9 in the local computing press! >From 9fans-outgoing-owner Wed Aug 16 10:24:39 1995 Received: by colossus.cse.psu.edu id <46134>; Wed, 16 Aug 1995 10:08:39 -0400 Received: from tango.rahul.net ([192.160.13.5]) by colossus.cse.psu.edu with SMTP id <46155>; Wed, 16 Aug 1995 09:30:02 -0400 Received: from bolero.rahul.net by tango.rahul.net with SMTP id AA10675 (5.67b8/IDA-1.5 for <9fans@cse.psu.edu>); Tue, 15 Aug 1995 19:19:07 -0700 Received: from bedlam.rahul.net by bolero.rahul.net with SMTP id AA01638 (5.67b8/IDA-1.5 for <9fans@cse.psu.edu>); Tue, 15 Aug 1995 19:19:05 -0700 Received: by bedlam.rahul.net id m0siMpT-0002GPC (Debian /\oo/\ Smail3.1.29.1 #29.31); Tue, 15 Aug 95 07:18 PDT Message-Id: Date: Tue, 15 Aug 1995 10:18:00 -0400 From: bhogan@bedlam.rahul.net (Bill Hogan) To: 9fans Subject: re: installing plan9 demo on a PC In-Reply-To: <95Aug15.140810edt.34286@psuvax1.cse.psu.edu> References: <95Aug15.140810edt.34286@psuvax1.cse.psu.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Sender: owner-9fans Precedence: bulk Reply-To: 9fans "j" == jmk writes: >>> man b.com. man pages are available at >>> http://plan9.att.com/plan9/mansearch.html. >> What does this mean "are available"? j> 1) the plan9 home page http://plan9.att.com/plan9/ mentions the ftp archive which includes the man pages; j> 2) follow the link on the home page for the distribution and then for installing the distribution. that page has a link to the b.com(8) page. Eureka! Amazing! Using `lynx' (in reverse order of occurrence): 4. -- You selected: Plan 9's B.COM(8) 3. -- You selected: Installing the Plan 9 Distribution 2. -- You selected: Plan 9 Distribution 1. -- You selected: Plan 9 Index 0. -- You selected: ATT Bell Laboratories Computing Research home page Please allow me to apologize for my outburst. Thank you! Bill >From 9fans-outgoing-owner Wed Aug 16 11:05:26 1995 Received: by psuvax1.cse.psu.edu id <34044>; Wed, 16 Aug 1995 10:31:33 -0400 Received: from plan9.att.com ([192.20.225.252]) by psuvax1.cse.psu.edu with SMTP id <33963>; Wed, 16 Aug 1995 09:35:56 -0400 From: jmk@plan9.att.com To: 9fans Date: Tue, 15 Aug 1995 22:34:46 -0400 Subject: Re: Help wanted, Plan9 a piece of junk! Message-Id: <95Aug16.093556edt.33963@psuvax1.cse.psu.edu> Sender: owner-9fans Precedence: bulk Reply-To: 9fans I took a look in comp.os.linux.misc and felt right at home - there were articles about weird hangs trying to install distributions, hardware not being recognised, mice not being found, filesystems being trashed (NOT related to Plan 9), etc. From: bhogan@rahul.net (Bill Hogan) Newsgroups: comp.os.linux.misc Subject: Re: Help wanted, Plan9 a piece of junk! Date: 14 Aug 1995 22:26:05 GMT Organization: Reasonable Systems Lines: 56 Message-ID: References: <40p6oe$q2t@paul.rutgers.edu> Reply-To: bhogan@rahul.net NNTP-Posting-Host: 192.160.13.192 NNTP-Posting-User: bhogan In-reply-to: xke@paul.rutgers.edu's message of 15 Aug 1995 00:10:54 -0400 "XK" == Xiao Ke writes: In article <40p6oe$q2t@paul.rutgers.edu> xke@paul.rutgers.edu (Xiao Ke) writes: XK> Hi, there, XK> Help wanted, Plan9, the so boasted next generation os is just a piece of XK> junk. This time, AT&T really picked a good name for plan9. XK> I've run linux1.2.0 for about a half year, everything seems OK. XK> Today, I download the plan9 to play with, it looks working too. XK> However, actually when I was installing plan9, it overwrote my linux XK> partition without any pre-warning. XK> My linux partition is not bootable now, and I try to boot from floppy, XK> and do fsck on it, it says: "bad magic number". So definately XK> plan9 overwrote my linux partition. XK> I want to recover my more than half-year work, since I don't have tape XK> backup. Please help! Any suggestion will be mostly appreciated. XK> I guess this is doable, since my linux partition occupies 400Mbytes, XK> while plan9 only occupies 20Mbytes according to its installation notes, XK> so it looks like the rest 380Mbytes should be able to recoverd, sounds XK> reasonable? XK> Thanks, XK> -----Xiao Ke XK> xke@paul.rutgers.edu Hello Xiao. I do not know if you will be able to salvage what used to be your Linux partition or not. I do know that the plan9 installation guide is something I would be ashamed to have appear in print under my name. Given that ATT is apparently planning on *selling* plan9 at $350 per, and given the availability of packages like the Slackware Linux book/CDROM at < $50 per, I find it totally amazing that ATT would put out such a half-baked, half-hearted PC/plan9 demo package! Some demo. Up until now I had thought I was having a problem because I could not reboot plan9/B after it was installed on my hard drive but now I count myself fortunate it didn't. Bill -- |- "5. Improve constantly and forever the system of production and service, to improve quality and productivity, and thus constantly decrease costs." (W. Edwards Deming) >From 9fans-outgoing-owner Wed Aug 16 13:34:47 1995 Received: by colossus.cse.psu.edu id <46213>; Wed, 16 Aug 1995 13:21:32 -0400 Received: from konrad.lysator.liu.se ([130.236.253.6]) by colossus.cse.psu.edu with SMTP id <46212>; Wed, 16 Aug 1995 13:21:12 -0400 Received: from kamelen.lysator.liu.se (kamelen.lysator.liu.se [130.236.254.87]) by konrad.lysator.liu.se (8.6.11/8.6.11) with ESMTP id TAA04848 for <9fans@cse.psu.edu>; Wed, 16 Aug 1995 19:21:01 +0200 Received: (ture@localhost) by kamelen.lysator.liu.se (8.6.11/8.6.11) id TAA27761; Wed, 16 Aug 1995 19:20:54 +0200 Date: Wed, 16 Aug 1995 13:20:54 -0400 Message-Id: <199508161720.TAA27761@kamelen.lysator.liu.se> From: Ture P}lsson To: 9fans In-reply-to: <95Aug15.122325edt.34200@psuvax1.cse.psu.edu> (presotto@plan9.att.com) Subject: `file does not exist' when copying first stage files Sender: owner-9fans Precedence: bulk Reply-To: 9fans [ Hm. First attempt bounced. Hope you don't see this twice... ] After some trial-and-error, I've finally got Plan 9 up and running on my home machine. Here's what I learned in the process: * The installation procedure doesn't like anything before the DOS partition on the disk. I had a Linux swap partition there, which caused the mount of C: on /n/c to fail. The installation program then merrily went on copying files into /n/c, which was now a plain direcory on the floppy. I.e, it _was_ copying the floppy onto itself, like I suspected. How about removing the >/dev/null redirections from the rc files in the distribution, so one can see what is going on? * Having LILO (the Linux boot loader) in the master boot record apparently doesn't work with Plan9. After installing the files from the first floppy and rebooting, the PLAN9\B thing refused to start Plan 9. Replacing the MBR with a vanilla DOS one (FDISK /MBR) solved this problem (but also means I can't boot Linux anymore, since it's on the second hard disk, which the DOS MBR doesn't understand. Foo.) -- Ture >From 9fans-outgoing-owner Wed Aug 16 14:35:04 1995 Received: by colossus.cse.psu.edu id <46278>; Wed, 16 Aug 1995 14:24:50 -0400 Received: from mail.crl.com ([165.113.1.22]) by colossus.cse.psu.edu with SMTP id <46265>; Wed, 16 Aug 1995 14:24:10 -0400 Received: from crl8.crl.com by mail.crl.com with SMTP id AA22417 (5.65c/IDA-1.5 for <9fans@cse.psu.edu>); Wed, 16 Aug 1995 11:11:08 -0700 Message-Id: <199508161811.AA22417@mail.crl.com> To: 9fans Cc: fashford@crl.com Subject: Re: `file does not exist' when copying first stage files In-Reply-To: Your message of "Wed, 16 Aug 1995 13:20:54 EDT." <199508161720.TAA27761@kamelen.lysator.liu.se> Date: Wed, 16 Aug 1995 14:11:07 -0400 From: Frank Ashford Sender: owner-9fans Precedence: bulk Reply-To: 9fans In message <199508161720.TAA27761@kamelen.lysator.liu.se>, Ture P}lsson writes: > >After some trial-and-error, I've finally got Plan 9 up and running >on my home machine. Here's what I learned in the process: > >[stuff about install deleted] > >* Having LILO (the Linux boot loader) in the master boot record > apparently doesn't work with Plan9. After installing the files from > the first floppy and rebooting, the PLAN9\B thing refused to start > Plan 9. Replacing the MBR with a vanilla DOS one (FDISK /MBR) solved > this problem (but also means I can't boot Linux anymore, since it's on the second hard disk, which the DOS MBR doesn't understand. Foo.) Hmm. Lilo is still livin' large on my system; I just tell it to boot from the dos partition. I then run plan9\b. No problem. By the way, I'm running the demo from the ftp site. Any luck building the executable from the source code in the 8.5 document listed on the website? I seem to be missing some include files from that listing. Should an error message indicating those files can't be found come up from the compiler? >-- Ture -Frank >From 9fans-outgoing-owner Wed Aug 16 15:35:07 1995 Received: by colossus.cse.psu.edu id <45511>; Wed, 16 Aug 1995 15:19:11 -0400 Received: from staff.cs.su.OZ.AU ([129.78.8.1]) by colossus.cse.psu.edu with SMTP id <45520>; Wed, 16 Aug 1995 15:18:54 -0400 Received: from plan9.cs.su.oz.au by staff.cs.su.OZ.AU (mail from dhog for 9fans@cse.psu.edu) with MHSnet (insertion MHSnet site: staff.cs.su.oz.au); Wed, 16 Aug 1995 15:55:12 +1000 Received: from riker.plan9.cs.su.oz.au. by staff.cs.su.OZ.AU.; Wed, 16 Aug 1995 15:55:08 +1000 X-Claimed-Received: from plan9.cs.su.oz.au Date: Wed, 16 Aug 1995 01:45:23 -0400 From: dhog@plan9.cs.su.oz.au To: 9fans Subject: Re: [comp.os.linux.misc] Help wanted, Plan9 a piece of junk! Message-Id: <95Aug16.151854edt.45520@colossus.cse.psu.edu> Sender: owner-9fans Precedence: bulk Reply-To: 9fans Perhaps in the interests of world peace, the versions of disk1 on the ftp site (and mirrors) containing the original disk/prep should be made inaccessible? Though that still leaves the physical copies that have been (or will be) sent out to licensees -- will the Labs be issuing some sort of errata sheet/warning with bought copies of the distribution? I mean, these people are potentially less likely to look at the ftp site's errata list or the README in /plan9/pcdist >From 9fans-outgoing-owner Wed Aug 16 15:52:09 1995 Received: by colossus.cse.psu.edu id <46195>; Wed, 16 Aug 1995 15:36:19 -0400 Received: from staff.cs.su.OZ.AU ([129.78.8.1]) by colossus.cse.psu.edu with SMTP id <46111>; Wed, 16 Aug 1995 15:34:34 -0400 Received: from plan9.cs.su.oz.au by staff.cs.su.OZ.AU (mail from dhog for 9fans@cse.psu.edu) with MHSnet (insertion MHSnet site: staff.cs.su.oz.au); Wed, 16 Aug 1995 16:49:04 +1000 Received: from riker.plan9.cs.su.oz.au. by staff.cs.su.OZ.AU.; Wed, 16 Aug 1995 16:49:01 +1000 X-Claimed-Received: from plan9.cs.su.oz.au Date: Wed, 16 Aug 1995 02:39:16 -0400 From: dhog@plan9.cs.su.oz.au To: 9fans Subject: Re: [comp.os.linux.misc] Help wanted, Plan9 a piece of junk! Message-Id: <95Aug16.153434edt.46111@colossus.cse.psu.edu> Sender: owner-9fans Precedence: bulk Reply-To: 9fans >Love that subject... He can't even spell Linux... ;-) >Since everything in Plan 9 is a file, the message 'file does not >exist' is probably the least useful and most seen message. I've noticed that sometimes the message is printed even when there is no actual file that couldn't be opened. The reason for this appears to be: (1) Some programs use errstr when reporting errors which don't actually set errstr (2) open() can set errstr as a side effect, even when the call succeeds. This is due to the implementation of union directories -- walk() tries each directory in a union in turn until it succeeds, and errstr is set to 'file does not exist' as a side effect of a failed attempt. Thus any program which, say, uses files in /dev, will have errstr set to 'file does not exist' instead of 'no error'. In fact, it's worse than that, since "/" is a union directory, opening any file in the namespace will set errstr! I'm not sure what the best way to fix this is. Ideally, open() should not change errstr at all if it succeeds, but this would require wasteful copying of errstr in every call to walk() on a union directory. The alternative is to just blindly clear u->error[0] on a sucessful open() -- cheaper, but is it The Right Thing? Anyway, here is a program to demonstrate the problem: ----------------- #include #include void try(char *file) { char err[ERRLEN]; strcpy(err, "no error, dude"); fprint(2, "\nbefore opening %s, set errstr = '%s'\n", file, err); errstr(err); if (open(file, OREAD) < 0) fprint(2, "open %s failed!: %r\n", file); else fprint(2, "after opening %s, errstr = '%r'\n", file); } void main(int argc, char *argv[]) { fprint(2, "on program entry, errstr = '%r'\n"); try("/dev/null"); try("/adm/users"); try("#p/1/status"); exits(0); } -------------------- Here's the output when I run it: on program entry, errstr = 'file does not exist' before opening /dev/null, set errstr = 'no error, dude' after opening /dev/null, errstr = 'file does not exist' before opening /adm/users, set errstr = 'no error, dude' after opening /adm/users, errstr = 'file does not exist' before opening #p/1/status, set errstr = 'no error, dude' after opening #p/1/status, errstr = 'no error, dude' -------------------- P.S. If Plan9 is junk, what does that make Windows 3.1? >From 9fans-outgoing-owner Wed Aug 16 17:21:19 1995 Received: by psuvax1.cse.psu.edu id <34028>; Wed, 16 Aug 1995 17:01:58 -0400 Received: from postman.ncube.com ([134.242.8.47]) by psuvax1.cse.psu.edu with SMTP id <34022>; Wed, 16 Aug 1995 17:01:37 -0400 Received: from butler.ncube.com by postman.ncube.com (4.1/SMI-4.1) id AA05731; Wed, 16 Aug 95 14:01:19 PDT Received: from skynet.ncube.com by butler.ncube.com (5.0/SMI-SVR4) id AA01032; Wed, 16 Aug 1995 14:01:15 +0800 Date: Wed, 16 Aug 1995 02:01:15 -0400 From: avg@postman.ncube.com (Vadim Antonov) Message-Id: <9508162101.AA01032@butler.ncube.com> To: 9fans Subject: BUG in /sys/src/libauth/getchal.c Content-Length: 2625 Sender: owner-9fans Precedence: bulk Reply-To: 9fans Hi -- error handling in getchal/chalreply routines was broken. If one of file descriptors was wrong close() overwrites error string. The new code which produces correct error string is appended. --vadim ----cut here---- #include #include #include #include "authlocal.h" static char *damsg = "problem with /dev/authenticate"; static char *ccmsg = "can't call AS"; static char *pbmsg = "AS protocol botch"; int getchal(Chalstate *c, char *user) { int n; Ticketreq tr; char trbuf[TICKREQLEN]; /* get ticket request from kernel and add user name */ c->afd = open("/dev/authenticate", ORDWR); if(c->afd < 0){ werrstr(damsg); return -1; } n = read(c->afd, trbuf, TICKREQLEN); if(n != TICKREQLEN){ close(c->afd); werrstr(damsg); return -1; } convM2TR(trbuf, &tr); memset(tr.uid, 0, sizeof(tr.uid)); strcpy(tr.uid, user); tr.type = AuthChal; convTR2M(&tr, trbuf); /* send request to authentication server and get challenge */ c->asfd = authdial(); if(c->asfd < 0){ close(c->afd); werrstr(ccmsg); c->afd = c->asfd = -1; return -1; } if(write(c->asfd, trbuf, TICKREQLEN) != TICKREQLEN){ werrstr(pbmsg); goto err; } if(_asrdresp(c->asfd, c->chal, NETCHLEN) < 0) goto err; return 0; err: close(c->afd); close(c->asfd); c->afd = c->asfd = -1; return -1; } int chalreply(Chalstate *c, char *response) { char resp[NETCHLEN]; char ticket[TICKETLEN]; /* send response to auth server and get ticket */ memset(resp, 0, sizeof resp); strncpy(resp, response, NETCHLEN-1); if(write(c->asfd, resp, NETCHLEN) != NETCHLEN){ werrstr(pbmsg); goto err; } if(_asrdresp(c->asfd, ticket, TICKETLEN+AUTHENTLEN) < 0) goto err; /* pass ticket to /dev/authenticate */ if(write(c->afd, ticket, TICKETLEN+AUTHENTLEN) != TICKETLEN+AUTHENTLEN){ werrstr("permission denied"); goto err; } close(c->asfd); close(c->afd); c->afd = c->asfd = -1; return 0; err: if(c->asfd >= 0) close(c->asfd); if(c->afd >= 0) close(c->afd); c->afd = c->asfd = -1; return -1; } >From 9fans-outgoing-owner Wed Aug 16 17:26:33 1995 Received: by colossus.cse.psu.edu id <46107>; Wed, 16 Aug 1995 17:16:52 -0400 Received: from galapagos.cse.psu.edu ([130.203.2.12]) by colossus.cse.psu.edu with SMTP id <45520>; Wed, 16 Aug 1995 17:16:36 -0400 Received: from localhost by galapagos.cse.psu.edu with SMTP id <12773>; Wed, 16 Aug 1995 17:16:22 -0400 To: 9fans Subject: Re: [comp.os.linux.misc] Help wanted, Plan9 a piece of junk! In-reply-to: Your message of "Wed, 16 Aug 1995 02:39:16 EDT." <95Aug16.153434edt.46111@colossus.cse.psu.edu> Date: Wed, 16 Aug 1995 17:16:16 -0400 From: Scott Schwartz Message-Id: <95Aug16.171622edt.12773@galapagos.cse.psu.edu> Sender: owner-9fans Precedence: bulk Reply-To: 9fans dhog@plan9.cs.su.oz.au writes: | (2) open() can set errstr as a side effect, even when the call succeeds. Ouch: ``...it is understood that the error string is altered only if an error occurs.'' -- intro(2). >From 9fans-outgoing-owner Wed Aug 16 18:54:51 1995 Received: by psuvax1.cse.psu.edu id <34031>; Wed, 16 Aug 1995 18:35:11 -0400 Received: from plan9.cs.york.ac.uk ([144.32.33.120]) by psuvax1.cse.psu.edu with SMTP id <34034>; Wed, 16 Aug 1995 18:29:04 -0400 From: forsyth@plan9.cs.york.ac.uk To: 9fans@cs.psu.edu Date: Wed, 16 Aug 1995 18:11:29 -0400 subject: `over' Message-Id: <95Aug16.182904edt.34034@psuvax1.cse.psu.edu> Sender: owner-9fans Precedence: bulk Reply-To: 9fans >>it is only with the benefit of hindsight and considerable effort >>(forgetting such things as "hop over", "skip over", "jump over", "pass >>over", etc.) that I can discern in the phrase "Plan 9 will install >>over the second through last partitions" the idea that Plan 9 will >>*DESTROY* my second through the last partitions -- so when it goes on >>to say oh god. really, i have a lot of sympathy for you esp. owing to the problem with disk/prep; i'm very sorry about any loss, and so on; i can tell you what plan 9 has, can, and might do to your discs; BUT i really cannot agree that the Errata notes about installation are not quite clear in the common dialects of English about the effect of using the old disk/prep on a DOS disc with several DOS partitions. no, i'm not having any of this. let's see. (Compact Edition of the full Oxford English Dictionary; none of this CDROM stuff.) i believe `over' is intended in the following sense: II. In sense `on', `upon' 5. On the upper or outer surface of; upon: sometimes implying the notion of supported or resting upon, sometimes (now more frequently) that of covering the surface. 6. To a position on the surface or top of, or so as to cover; upon (with verbs of motion). 7. a. (Position) on all parts of the surface of; everywhere on; here and there upon. Often strengthened by `all', now esp. `all over'. b. (Motion) from place to place on the surface of; all about; throughout. Often `all over'. c. Through every part of, all through. (Sometimes including the notion of examination or consideration: cf. 4.) ... 13. From side to side of a surface or space; across, to the other side of (a sea, river, boundary, etc. [disc partition!?]); from end to end of (a line), along. and to my mind might even include: 8. Above in authority, rule or power; with sbs., as `king', `lord over'; `jurisdiction', `rule', `triumph', `victory over'; adjs. `victorious over'; vbs. `to reign', `rule', `triumph', `appoint' or `set' any one `over'. 9. Above or beyond in degree or quality, or action; in preference to; more than. but no doubt you would have it thus: 14. fig. In transgression or violation of; in contravention of, contrary to. (Obs.) It really is quite clear, and a proper use of the word `over': `install over' as in `paper over'. Your `skip over' and `jump over' examples really prove the point: the skip or jump *crosses the surface*, *`from side to side'* of the thing jumped or skipped over, that is precisely why `over' is used in that phrase. that one ends up on the other side of the object is a property of `skip' or `jump', not of `over'. that property is not shared by `cover', `paper', `sweat', `place', ... or `install'. what happens when you `slide over' something? what happens when you `cover over the cracks' (hello, Gates!)? i mean, really. >From 9fans-outgoing-owner Wed Aug 16 20:24:14 1995 Received: by psuvax1.cse.psu.edu id <34022>; Wed, 16 Aug 1995 20:03:46 -0400 Received: from plan9.cs.su.oz.au ([129.78.96.2]) by psuvax1.cse.psu.edu with SMTP id <34034>; Wed, 16 Aug 1995 19:51:18 -0400 From: Boyd Roberts Date: Wed, 16 Aug 1995 19:26:38 -0400 To: 9fans Cc: fashford@crl.com Subject: Re: `file does not exist' when copying first stage files In-Reply-To: <199508161811.AA22417@mail.crl.com> Message-ID: <199508170926.1082.9.babob@plan9.cs.su.oz.au> Sender: owner-9fans Precedence: bulk Reply-To: 9fans From: Frank Ashford Hmm. Lilo is still livin' large on my system; I just tell it to boot I put plan9 onto a linux system. We just had to turn off the linux partition for it to recognise that the attached disks were bootable. >From 9fans-outgoing-owner Thu Aug 17 06:19:19 1995 Received: by colossus.cse.psu.edu id <46225>; Thu, 17 Aug 1995 06:05:12 -0400 Received: from relay2.geis.com ([192.77.188.3]) by colossus.cse.psu.edu with SMTP id <46223>; Thu, 17 Aug 1995 06:04:55 -0400 Received: by relay2.geis.com (1.37.109.15/15.6) id AA073564460; Thu, 17 Aug 1995 10:14:20 GMT From: nms@ey.geis.com Message-Id: <199508171014.AA073564460@relay2.geis.com> Date: Thu, 17 Aug 1995 05:13:00 -0400 To: 9fans Subject: Unix/Lynex Info Please X-Ey-Id: 1540217 X-Ey-From: NMS Sender: owner-9fans Precedence: bulk Reply-To: 9fans Item forwarded by NMS to 9FANS@CSE.PSU.EDU@INTERNET# Item forwarded by NMS to SALES@BYTED.COM@INTERNET# Item forwarded by NMS to TECH@PHT.COM@INTERNET# Item forwarded by NMS to INFO@PHT.COM@INTERNET# Item forwarded by NMS to EDWAR028@GOLD.TC.UMN.EDU@INTERNET# Item forwarded by NMS to GREG.HANKINS@CC.GATECH.EDU@INTERNET# Item forwarded by NMS to PTF@CFCL.COM@INTERNET# Item forwarded by NMS to SALES@PROMOX.UUCP.NETCOM.COM@INTERNET# Item forwarded by NMS to SWT@NETCOM8.NETCOM.COM@INTERNET# Item forwarded by NMS to SUSE@SUSE.DE@INTERNET# Item forwarded by NMS to LJQUESTIONS@SSC.COM@INTERNET# Item forwarded by NMS to PIPNET@DORSAI.ORG@INTERNET# Item forwarded by NMS to 73544.3552@COMPUSERVE.COM@INTERNET# Item forwarded by NMS to FAWCETT@PNW.NET@INTERNET# Item forwarded by NMS to LINUX@SSC.COM@INTERNET# Item forwarded by NMS to INFO@LSL.COM@INTERNET# Item forwarded by NMS to SALES@SSC.COM@INTERNET# Item forwarded by NMS to JOQNNE@SSC.COM@INTERNET# Item forwarded by NMS to LJEDITOR@SSC.COM@INTERNET# Item forwarded by NMS to INFO@VITAL.COM@INTERNET# Item 3871235 95/08/17 04:46 From: NMS N. M. S. To: info@yaggdrasil.com@INTERNET# INTERNET GATEWAY Sub: Unix/Lynex Info Please Sir/Madam, I am a new user in the Unix/Lynex world. I am still basic and using MKS tools to train myself on basic Unis/Lynex. However I have already bought the Lynex CD's package and ready to install. What I am currently looking for is Unix/Lynex site on the Internet which can be a source of information that will infrom about the: 1. Unix/Lynex products, applications and games and where to look for them. 2. Latest developments. 3. Discussion lists or home pages that I can subcripe to, that has Unix/Lynex issues. For right now I cannot browse or serf the Internet. The only facility that I have is e-mail. Can someone help me please. Thanks, Nadir Salih, NMS@EY@GEIS.COM >From 9fans-outgoing-owner Thu Aug 17 06:51:57 1995 Received: by colossus.cse.psu.edu id <46227>; Thu, 17 Aug 1995 06:42:51 -0400 Received: from tango.rahul.net ([192.160.13.5]) by colossus.cse.psu.edu with SMTP id <46223>; Thu, 17 Aug 1995 06:42:35 -0400 Received: from bolero.rahul.net by tango.rahul.net with SMTP id AA21467 (5.67b8/IDA-1.5 for <9fans@cse.psu.edu>); Thu, 17 Aug 1995 03:42:25 -0700 Received: from bedlam.rahul.net by bolero.rahul.net with SMTP id AA18444 (5.67b8/IDA-1.5 for <9fans@cse.psu.edu>); Thu, 17 Aug 1995 03:42:23 -0700 Received: by bedlam.rahul.net id m0sipIW-0002GYC (Debian /\oo/\ Smail3.1.29.1 #29.31); Wed, 16 Aug 95 13:42 PDT Message-Id: Date: Wed, 16 Aug 1995 16:42:00 -0400 From: bhogan@bedlam.rahul.net (Bill Hogan) To: 9fans Subject: Re: Help wanted, Plan9 a piece of junk! In-Reply-To: <95Aug16.093556edt.33963@psuvax1.cse.psu.edu> References: <95Aug16.093556edt.33963@psuvax1.cse.psu.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Sender: owner-9fans Precedence: bulk Reply-To: 9fans "j" == jmk writes: j> I took a look in comp.os.linux.misc and felt right at home - there were articles about weird hangs trying to install distributions, hardware not being recognised, mice not being found, filesystems being trashed (NOT related to Plan 9), etc. This I do not doubt, but comp.os.linux.* is not a multi-billion dollar corporation and Linux does not cost $350, either. BH >From 9fans-outgoing-owner Thu Aug 17 07:01:54 1995 Received: by colossus.cse.psu.edu id <46223>; Thu, 17 Aug 1995 06:51:11 -0400 Received: from tango.rahul.net ([192.160.13.5]) by colossus.cse.psu.edu with SMTP id <46226>; Thu, 17 Aug 1995 06:42:36 -0400 Received: from bolero.rahul.net by tango.rahul.net with SMTP id AA21472 (5.67b8/IDA-1.5 for <9fans@cse.psu.edu>); Thu, 17 Aug 1995 03:42:30 -0700 Received: from bedlam.rahul.net by bolero.rahul.net with SMTP id AA18449 (5.67b8/IDA-1.5 for <9fans@cse.psu.edu>); Thu, 17 Aug 1995 03:42:27 -0700 Received: by bedlam.rahul.net id m0sir7M-0002IkC (Debian /\oo/\ Smail3.1.29.1 #29.31); Wed, 16 Aug 95 15:39 PDT Message-Id: Date: Wed, 16 Aug 1995 18:39:00 -0400 From: bhogan@bedlam.rahul.net (Bill Hogan) To: 9fans Subject: `over' In-Reply-To: <95Aug16.182904edt.34034@psuvax1.cse.psu.edu> References: <95Aug16.182904edt.34034@psuvax1.cse.psu.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Sender: owner-9fans Precedence: bulk Reply-To: 9fans "f" == forsyth writes: >>> it is only with the benefit of hindsight and considerable effort >>> (forgetting such things as "hop over", "skip over", "jump over", "pass >>> over", etc.) that I can discern in the phrase "Plan 9 will install >>> over the second through last partitions" The idea that Plan 9 will >>> *DESTROY* my second through the last partitions -- so when it goes on >>> to say f> oh god. f> really, i have a lot of sympathy for you esp. owing to the problem with disk/prep; i'm very sorry about any loss, and so on; i can tell you what plan 9 has, can, and might do to your discs; BUT i really cannot agree that the Errata notes about installation are not quite clear in the common dialects of English about the effect of using the old disk/prep on a DOS disc with several DOS partitions. f> no, i'm not having any of this. f> let's see. (Compact Edition of the full Oxford English Dictionary; none of this CDROM stuff.) f> i believe `over' is intended in the following sense: f> II. In sense `on', `upon' f> 5. On the upper or outer surface of; upon: sometimes implying the notion of supported or resting upon, sometimes (now more frequently) that of covering the surface. f> 6. To a position on the surface or top of, or so as to cover; upon (with verbs of motion). f> 7. a. (Position) on all parts of the surface of; everywhere on; here and there upon. f> Often strengthened by `all', now esp. `all over'. f> b. (Motion) from place to place on the surface of; all about; throughout. Often `all over'. f> c. Through every part of, all through. (Sometimes including the notion of examination or consideration: cf. 4.) [and so on in a similar vein -- the OED is always fun to read] First off, I am not the person whose hard drive partitions were installed (all?) over by the plan9 demo. But as I said, while it is possible to construe the phrase "install over the second through last partitions" in a manner parallel to the sense in which most speakers of English will I am sure immediately understand the phrase "paint over the second through last letters", I seriously doubt that possibility is the one which will occur *first* in the minds of most speakers of English, and that IMO makes it much more likely than it needs to be in this case that a key point will be missed even if every first-time plan9 installer reads `errata.html'. I think you have shown the OED supports my position. The point is that revisions which may spell the difference between catastrophe and success do not belong in an erratum but should be incorporated into a new edition of the text to which they apply. Bill >From 9fans-outgoing-owner Thu Aug 17 07:19:40 1995 Received: by colossus.cse.psu.edu id <46236>; Thu, 17 Aug 1995 07:02:06 -0400 Received: from symbionics.co.uk ([158.43.6.17]) by colossus.cse.psu.edu with SMTP id <46221>; Thu, 17 Aug 1995 07:01:30 -0400 Received: from sympc143 ([194.32.100.46]) by symbionics.co.uk (4.1/SMI-4.1) id AA29534; Thu, 17 Aug 95 11:43:54 BST Message-Id: <9508171043.AA29534@symbionics.co.uk> Comments: Authenticated sender is From: "Nigel Roles" Organization: Symbionics Communications To: 9fans Date: Thu, 17 Aug 1995 07:43:49 -0400 Subject: Re: Unix/Lynex Info Please Priority: normal X-Mailer: Pegasus Mail for Windows (v2.01) Sender: owner-9fans Precedence: bulk Reply-To: 9fans < spectacular amounts of crap deleted> > Sir/Madam, > > I am a new user in the Unix/Lynex world. I am still basic and using MKS tools > Oh no, a rogue Plan 9 installation has installed 'over' the Linux spell checker. >From 9fans-outgoing-owner Thu Aug 17 07:32:03 1995 Received: by colossus.cse.psu.edu id <46221>; Thu, 17 Aug 1995 07:19:16 -0400 Received: from cegelecproj.co.uk ([159.245.72.6]) by colossus.cse.psu.edu with SMTP id <46232>; Thu, 17 Aug 1995 07:01:37 -0400 Received: from vampire.cegelecproj.co.uk (cerberus.cegelecproj.co.uk) by cegelecproj.co.uk (4.1/SMI-4.1) id AA09564; Thu, 17 Aug 95 11:56:23 BST Received: from phantom.cegelecproj.co.uk (phantom.limbo.cegelecproj.co.uk) by vampire.cegelecproj.co.uk (5.0/SMI-SVR4) id AA00087; Thu, 17 Aug 1995 11:56:18 +0100 Received: from phantom (localhost) by phantom.cegelecproj.co.uk (5.0/SMI-SVR4) id AA27625; Thu, 17 Aug 1995 11:56:14 +0100 Message-Id: <9508171056.AA27625@phantom.cegelecproj.co.uk> X-Mailer: exmh version 1.6.1 5/23/95 To: 9fans Subject: Re: Help wanted, Plan9 a piece of junk! In-Reply-To: Your message of "Wed, 16 Aug 1995 16:42:00 EDT." X-Face: Iqsa(US9p?)Y^W+6Ff[Z]rM"uFE) lFDjag1e]\/#2 X-Planation: X-Faces can be viewed with Faces from cs.indiana.edu. Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 17 Aug 1995 06:56:13 -0400 From: Steve_Kilbane Content-Length: 448 Sender: owner-9fans Precedence: bulk Reply-To: 9fans > This I do not doubt, but comp.os.linux.* is not a multi-billion > dollar corporation and Linux does not cost $350, either. This is a "piece of string" issue, here. How much, specifically, *should* the manuals and CD-ROM cost, then? How much do you pay for the Linux equivalent? At what point do you draw the line and say, "Right, anything costing $x or more must be bug free"? And how much have you paid for those four disk images? steve >From 9fans-outgoing-owner Thu Aug 17 08:02:56 1995 Received: by colossus.cse.psu.edu id <46235>; Thu, 17 Aug 1995 07:52:48 -0400 Received: from minster.cs.york.ac.uk ([144.32.16.26]) by colossus.cse.psu.edu with SMTP id <46232>; Thu, 17 Aug 1995 07:52:31 -0400 Message-ID: X-Sender: pete@minster.york.ac.uk X-Mailer: Windows Eudora Light Version 1.5.2b1 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 17 Aug 1995 07:52:10 -0400 To: 9fans From: Pete Fenelon Subject: Re: Help wanted, Plan9 a piece of junk! Sender: owner-9fans Precedence: bulk Reply-To: 9fans At 06:56 AM 8/17/95 -0400, Kilbs wrote: >This is a "piece of string" issue, here. How much, specifically, >*should* the manuals and CD-ROM cost, then? How much do you pay >for the Linux equivalent? At what point do you draw the line and >say, "Right, anything costing $x or more must be bug free"? This is a very good point. Lots of people who lack the time, inclination or facilities to get the system off the net go out and buy one of those user-patronising doorstop Linux books with a couple of CD-Roms in the back, and/or buy ; I can quite easily imagine someone spending a couple of hundred dollars on a Linux installation and docs.... As for "if it costs >$x it must be bug free" -- every software house I've ever heard of would be destroyed by lawsuits by now :-) > >And how much have you paid for those four disk images? Exactly. :-) pete -- Peter Fenelon - Research Associate - High Integrity Systems Engineering Group, Dep't of Computer Science, University of York, York, YO1 5DD (+44 1904 433388) pete.fenelon@minster.york.ac.uk http://dcpu1.cs.york.ac.uk:6666/pete/pete.html >From 9fans-outgoing-owner Thu Aug 17 08:33:37 1995 Received: by colossus.cse.psu.edu id <46237>; Thu, 17 Aug 1995 08:23:46 -0400 Received: from plan9.cs.su.oz.au ([129.78.96.3]) by colossus.cse.psu.edu with SMTP id <46232>; Thu, 17 Aug 1995 08:23:27 -0400 Date: Thu, 17 Aug 1995 08:11:51 -0400 From: dhog@plan9.cs.su.oz.au To: 9fans Subject: Re: `over' Message-Id: <95Aug17.082327edt.46232@colossus.cse.psu.edu> Sender: owner-9fans Precedence: bulk Reply-To: 9fans > But as I said, while it is possible to construe the phrase "install >over the second through last partitions" in a manner parallel to the >sense in which most speakers of English will I am sure immediately >understand the phrase "paint over the second through last letters", I >seriously doubt that possibility is the one which will occur *first* >in the minds of most speakers of English, and that IMO makes it much >more likely than it needs to be in this case that a key point will be >missed even if every first-time plan9 installer reads `errata.html'. I'm sorry, but if you write sentences like that, then you are in no position to argue. :-) If the erratum had contained that many dependent clauses then the "most speakers of English" might have been forgiven for misunderstanding it! As it is, I believe anyone misunderstanding the phrase in the way that you suggest is not competent to switch their computer on, let alone install an operating system. People who do not understand the meaning of phrases such as "install over" will probably not understand other phrases such as "DOS partition", "operating system" or "hard disk". You make it seem like everything is riding on the interpretation of the one phrase "install over", but the whole paragraph warns the user in 3 different ways that there is a problem if they have more than one partition. I would consider it much more likely that our friend who lost his linux partition didn't read the errata list at all, rather than read it and misinterpretted it in the way that you suggest. Sorry about all the flamage, I haven't been the same since I started administering MS Windows (spit!) for a living. :-( >From 9fans-outgoing-owner Thu Aug 17 08:41:59 1995 Received: by colossus.cse.psu.edu id <46224>; Thu, 17 Aug 1995 08:34:04 -0400 Received: from plan9.cs.su.oz.au ([129.78.96.3]) by colossus.cse.psu.edu with SMTP id <46231>; Thu, 17 Aug 1995 08:32:56 -0400 Date: Thu, 17 Aug 1995 08:21:58 -0400 From: dhog@plan9.cs.su.oz.au To: 9fans Subject: Re: Unix/Lynex Info Please Message-Id: <95Aug17.083256edt.46231@colossus.cse.psu.edu> Sender: owner-9fans Precedence: bulk Reply-To: 9fans >> I am a new user in the Unix/Lynex world. I am still basic and using MKS tools >> > >Oh no, a rogue Plan 9 installation has installed 'over' the Linux spell >checker. I am still getting over that fact that he said "serf the Internet". Sort of like what Microsoft are trying to do with MSN ;-) No vassalating please. >From 9fans-outgoing-owner Thu Aug 17 11:09:23 1995 Received: by colossus.cse.psu.edu id <46250>; Thu, 17 Aug 1995 10:53:48 -0400 Received: from dealer.cards.com ([192.133.70.2]) by colossus.cse.psu.edu with SMTP id <46248>; Thu, 17 Aug 1995 10:53:32 -0400 Received: from monte (monte.cards.com) by dealer.cards.com (4.1/mls/3.2) id AA11696; Thu, 17 Aug 95 10:53:39 EDT Message-Id: <9508171453.AA11696@dealer.cards.com> Received: by monte (4.1/mls/3.2) id AA00427; Thu, 17 Aug 95 10:53:38 EDT From: carvell@cards.com Subject: Re: `file does not exist' when copying first stage files To: 9fans Date: Thu, 17 Aug 1995 10:53:37 -0400 In-Reply-To: <199508161720.TAA27761@kamelen.lysator.liu.se> from "Ture P}lsson" at Aug 16, 95 01:20:54 pm Content-Type: text Content-Length: 1915 Sender: owner-9fans Precedence: bulk Reply-To: 9fans Ture P}lsson wrote: > [...] > * Having LILO (the Linux boot loader) in the master boot record > apparently doesn't work with Plan9. After installing the files from > the first floppy and rebooting, the PLAN9\B thing refused to start > Plan 9. Replacing the MBR with a vanilla DOS one (FDISK /MBR) solved > this problem (but also means I can't boot Linux anymore, since it's > on the second hard disk, which the DOS MBR doesn't understand. Foo.) > > -- Ture > > For what it's worth, I had no problem with Lilo and Plan 9. My setup: single 207M IDE HD, partition 1=DOS, 2=Linux, 3=Linux swap, the rest is Plan 9. For anyone using Dos/Linux/Plan 9 out there: I did a complete install of DOS, Linux and Plan9 at basically the same time since my previous Linux setup was an old version, also it occupied my whole disk and I wanted to add a DOS partition. I don't know if all this was required or not, but, here's what I did: Booted from a DOS floppy, used DOS fdisk to make the main DOS partition and another DOS partition the size of the Linux and Linux swap combined (2nd one being to allocate space under DOS so Plan 9 would not install over it). Installed Plan 9 at the end of the disk. Booted DOS again and removed the pretend linux/swap partition (to allow Linux to create its own partitions, since the docs recommend against letting DOS make them). Booted Linux from the installation floppy (bootdisk/rootdisk), used Linux fdisk to make the Linux and swap partitions in place of the 2nd DOS one. (Whew). Again, I don't know if all that was necessary.... but everything seems to work fine. When I get the CD version of Plan 9, hopefully this will be all be simpler as I will be picking up a new HD for it to live on as well.... Gary -- Gary Carvell Galaxy Global Corporation http://www.cards.com/home/carvell carvell@{cards.com, sort.ivv.nasa.gov} / 1-304-367-8249 / fax 1-304-367-8223 >From 9fans-outgoing-owner Thu Aug 17 11:56:32 1995 Received: by colossus.cse.psu.edu id <46107>; Thu, 17 Aug 1995 11:41:43 -0400 Received: from alpha.xerox.com ([13.1.64.93]) by colossus.cse.psu.edu with SMTP id <46110>; Thu, 17 Aug 1995 11:41:27 -0400 Received: from reynaldo.parc.xerox.com ([13.2.116.96]) by alpha.xerox.com with SMTP id <15586(3)>; Thu, 17 Aug 1995 08:41:06 PDT Received: from localhost by reynaldo.parc.xerox.com with SMTP id <34950>; Thu, 17 Aug 1995 08:40:57 -0700 To: 9fans cc: kerch@parc.xerox.com Subject: Re: `over' In-reply-to: Your message of "Thu, 17 Aug 95 05:11:51 PDT." <95Aug17.082327edt.46232@colossus.cse.psu.edu> Date: Thu, 17 Aug 1995 11:40:53 -0400 From: Berry Kercheval Message-Id: <95Aug17.084057pdt.34950@reynaldo.parc.xerox.com> Sender: owner-9fans Precedence: bulk Reply-To: 9fans >>>dhog@plan9.cs.su.oz.au said: > You make it seem like everything is riding on the interpretation of the > one phrase "install over", but the whole paragraph warns the user in > 3 different ways that there is a problem if they have more than one > partition. I would consider it much more likely that our friend who > lost his linux partition didn't read the errata list at all, rather than read > it and misinterpretted it in the way that you suggest. Furthermore, I (and I suspect a lot of us) refuse to have any sympathy for anyone who does a major installation of a new operating system without doing a backup first. I can't count how many times I've read that you should backup often, and always before doing anything major. Get a clue guys: *THIS IS WHY*. Unexpected problems have a way of biting you when you least expect it. Remember: backups will get you through times of no disks better than disks will get you through times of no backups. Apologies to the 99% of the members of this mailing list who already *know* this stuff. --berry Berry Kercheval :: Xerox Palo Alto Research Center >From 9fans-outgoing-owner Thu Aug 17 15:49:54 1995 Received: by colossus.cse.psu.edu id <46260>; Thu, 17 Aug 1995 15:35:26 -0400 Received: from postman.ncube.com ([134.242.8.47]) by colossus.cse.psu.edu with SMTP id <46257>; Thu, 17 Aug 1995 15:35:10 -0400 Received: from butler.ncube.com by postman.ncube.com (4.1/SMI-4.1) id AA20093; Thu, 17 Aug 95 12:35:12 PDT Received: from skynet.ncube.com by butler.ncube.com (5.0/SMI-SVR4) id AA05366; Thu, 17 Aug 1995 12:35:07 +0800 Date: Thu, 17 Aug 1995 00:35:07 -0400 From: avg@postman.ncube.com (Vadim Antonov) Message-Id: <9508171935.AA05366@butler.ncube.com> To: 9fans Subject: BUG FIX for getwd() Content-Length: 1323 Sender: owner-9fans Precedence: bulk Reply-To: 9fans ----FORWARDED MESSAGE---- From: markw@kira (Mark Wiley) Subject: This is too much fun to keep to myself ... If you call getwd with a buffer which it too small to contain the current working directory, it returns 0 and places the message 'buffer too small' in the buffer EVEN if the buffer is too small to contain that message. Sigh. Markw ------------------------- The fix is appended, although the right way to do things would be to change the way the error message is returned (it should be in errstr...) --vadim File /sys/src/libc/9sys/getwd.c: naiad% diff getwd.c.old getwd.c 14c14 < getwd(char *s , int size) --- > getwd(char *s , int size0) 18a19 > int size; 19a21 > size = size0; 22c24 < strcpy(s, "stat of / failed"); --- > strncpy(s, "stat of / failed", size0); 29c31 < strcpy(s, "stat of . failed"); --- > strncpy(s, "stat of . failed", size0); 51c53 < strcpy(s, "chdir .. failed"); --- > strncpy(s, "chdir .. failed", size0); 65c67 < strcpy(s, "buffer too small"); --- > strncpy(s, "buffer too small", size0); 77c79 < strcpy(s, "failed to return to ."); --- > strncpy(s, "failed to return to .", size0); >From 9fans-outgoing-owner Thu Aug 17 18:05:53 1995 Received: by colossus.cse.psu.edu id <46225>; Thu, 17 Aug 1995 17:48:28 -0400 Received: from postman.ncube.com ([134.242.8.47]) by colossus.cse.psu.edu with SMTP id <46221>; Thu, 17 Aug 1995 17:48:03 -0400 Received: from butler.ncube.com by postman.ncube.com (4.1/SMI-4.1) id AA23607; Thu, 17 Aug 95 14:47:57 PDT Received: from skynet.ncube.com by butler.ncube.com (5.0/SMI-SVR4) id AA05991; Thu, 17 Aug 1995 14:47:52 +0800 Date: Thu, 17 Aug 1995 02:47:52 -0400 From: avg@postman.ncube.com (Vadim Antonov) Message-Id: <9508172147.AA05991@butler.ncube.com> To: 9fans Subject: More bugs. Content-Length: 941 Sender: owner-9fans Precedence: bulk Reply-To: 9fans /sys/src/cmd/auth/lib/readln didn't turn raw mode off before sending newline (which caused some funny behaviour if the server translates the newline differently in raw and cooked modes). Also, in some cases closed stream could be interpreted as DEL by readln. The quick fix is appended. As always, the real fix would be to make echo-on and echo-off _separate_ from raw-on and raw-off. I remember seeing the same kind of problem in Unix version 6. I guess aliens from outer space kept somebody in suspended animation all those years :) --vadim naiad% pwd /sys/src/cmd/auth/lib naiad% diff readln.c.old readln.c 49,50d48 < if(*p == 0x7f) < exits(0); 53c51,52 < if(raw) --- > if(raw) { > write(ctl, "rawoff", 6); 54a54 > } 58a59,60 > if(*p == 0x7f) > exits(0); naiad% >From 9fans-outgoing-owner Thu Aug 17 18:19:25 1995 Received: by colossus.cse.psu.edu id <46271>; Thu, 17 Aug 1995 18:09:07 -0400 Received: from postman.ncube.com ([134.242.8.47]) by colossus.cse.psu.edu with SMTP id <46107>; Thu, 17 Aug 1995 18:02:58 -0400 Received: from butler.ncube.com by postman.ncube.com (4.1/SMI-4.1) id AA24355; Thu, 17 Aug 95 14:56:38 PDT Received: from skynet.ncube.com by butler.ncube.com (5.0/SMI-SVR4) id AA06022; Thu, 17 Aug 1995 14:56:33 +0800 Date: Thu, 17 Aug 1995 02:56:33 -0400 From: avg@postman.ncube.com (Vadim Antonov) Message-Id: <9508172156.AA06022@butler.ncube.com> To: 9fans Subject: new telnetd (again) Content-Length: 12488 Sender: owner-9fans Precedence: bulk Reply-To: 9fans The "more improved" line discipline plus the plaintext-password authentication option for those who does not have SecureNet keys or use reasonable firewalls. The plaintext password mode is turned on with -P option (i.e. replace /rc/bin/service/tcp23 with #!/bin/rc exec /bin/aux/telnetd -P Since there were many changes i appended the complete source (/sys/src/cmd/service/telnetd.c): --vadim ---CUT HERE--- #include #include #include #include #include "../ip/telnet.h" /* console state (for consctl) */ typedef struct Consstate Consstate; struct Consstate{ int raw; int hold; int noecho; int col; int scol; }; Consstate *cons; int notefd; /* for sending notes to the child */ int noproto; /* true if we shouldn't be using the telnet protocol */ int trusted; /* true if we need not authenticate - current user is ok */ int nonone; /* don't allow none logins */ int plaintext; /* use less secure plaintext passowrds */ /* input and output buffers for network connection */ Biobuf netib; Biobuf childib; char remotesys[2*NAMELEN]; /* name of remote system */ int alnum(int); int conssim(void); int fromchild(char*, int); int fromnet(char*, int); void rubout(char*, char*, char**); int termchange(Biobuf*, int); int termsub(Biobuf*, uchar*, int); int xlocchange(Biobuf*, int); int xlocsub(Biobuf*, uchar*, int); int challuser(char*); void* share(int); #define TELNETLOG "telnet" void logit(char *fmt, ...) { char buf[8192], *s; s = buf; s = doprint(s, buf + sizeof(buf) / sizeof(*buf), fmt, &fmt + 1); *s = 0; syslog(0, TELNETLOG, "(%s) %s", remotesys, buf); } void getremote(char *dir) { int fd, n; char remfile[2*NAMELEN]; sprint(remfile, "%s/remote", dir); fd = open(remfile, OREAD); if(fd < 0) strcpy(remotesys, "unknown2"); n = read(fd, remotesys, sizeof(remotesys)-1); if(n>0) remotesys[n-1] = 0; else strcpy(remotesys, remfile); close(fd); } void main(int argc, char *argv[]) { char buf[1024]; int fd; char user[NAMELEN]; int tries = 0; int childpid; int n; memset(user, 0, sizeof(user)); ARGBEGIN { case 'n': opt[Echo].local = 1; noproto = 1; break; case 'N': nonone = 1; break; case 't': trusted = 1; strncpy(user, getuser(), NAMELEN-1); break; case 'u': strncpy(user, ARGF(), sizeof(user)-1); break; case 'D': debug = 1; break; case 'P': plaintext = 1; break; } ARGEND if(argc) getremote(argv[argc-1]); else strcpy(remotesys, "unknown"); /* options we need routines for */ opt[Term].change = termchange; opt[Term].sub = termsub; opt[Xloc].sub = xlocsub; /* setup default telnet options */ if(!noproto){ send3(1, Iac, Will, opt[Echo].code); send3(1, Iac, Do, opt[Term].code); send3(1, Iac, Do, opt[Xloc].code); } /* shared data for console state */ cons = share(sizeof(Consstate)); if(cons == 0) fatal("shared memory", 0, 0); cons->scol = -1; /* authenticate and create new name space */ Binit(&netib, 0, OREAD); if (!trusted){ while(challuser(user) < 0) { if(++tries == 5){ logit("failed as %s", user); print("authentication failure\r\n"); exits("authentication"); } *user = 0; } } logit("logged in as %s", user); newns(user, 0); putenv("service", "con"); /* simulate /dev/consctl and /dev/cons using pipes */ fd = conssim(); if(fd < 0) fatal("simulating", 0, 0); Binit(&childib, fd, OREAD); /* start a shell in a different process group */ switch(childpid = rfork(RFPROC|RFNAMEG|RFFDG|RFNOTEG)){ case -1: fatal("fork", 0, 0); case 0: fd = open("/dev/cons", OREAD); dup(fd, 0); close(fd); fd = open("/dev/cons", OWRITE); dup(fd, 1); dup(fd, 2); close(fd); segdetach(cons); execl("/bin/rc", "rc", "-il", 0); fatal("/bin/rc", 0, 0); default: sprint(buf, "/proc/%d/notepg", childpid); notefd = open(buf, OWRITE); if(notefd < 0) fatal(buf, 0, 0); break; } /* two processes to shuttle bytes twixt children and network */ switch(fork()){ case -1: fatal("fork", 0, 0); case 0: while((n = fromchild(buf, sizeof(buf))) >= 0) if(write(1, buf, n) != n) break; break; default: while((n = fromnet(buf, sizeof(buf))) >= 0) if(write(fd, buf, n) != n) break; break; } /* kill off all server processes */ sprint(buf, "/proc/%d/notepg", getpid()); fd = open(buf, OWRITE); write(fd, "die", 3); exits(0); } void prompt(char *p, char *b, int n) { char *e; int i; print("%s: ", p); for(e = b+n; b < e;){ i = fromnet(b, e-b); if(i <= 0) exits("fromnet: hungup"); b += i; if(*(b-1) == '\n'){ *(b-1) = 0; return; } } } /* * challenge user */ int challuser(char *user) { char nchall[NETCHLEN+32]; char response[NAMELEN]; Chalstate ch; char key[DESKEYLEN]; if(*user == 0) prompt("user", user, NAMELEN); if(strcmp(user, "none") == 0){ if(nonone) return -1; return 0; } if(getchal(&ch, user) < 0) return -1; if(plaintext) { cons->noecho = 1; prompt("password", response, NAMELEN); cons->noecho = 0; print("\r\n"); passtokey(key, response); strcpy(response, ch.chal); netcrypt(key, response); } else { sprint(nchall, "challenge: %s\r\nresponse", ch.chal); prompt(nchall, response, sizeof response); } if(chalreply(&ch, response) < 0) return -1; return 0; } /* * Process some input from the child, add protocol if needed. If * the input buffer goes empty, return. */ int fromchild(char *bp, int len) { int c; char *start; for(start = bp; bp-start < len-1; ){ c = Bgetc(&childib); if(c < 0){ if(bp == start) return -1; else break; } if(cons->raw == 0) { switch(c) { case '\n': *bp++ = '\r'; case '\r': cons->col = 0; break; case '\b': if(cons->col > 0) cons->col--; break; case '\t': cons->col = (cons->col + 8) & ~07; break; default: cons->col++; } } *bp++ = c; if(Bbuffered(&childib) == 0) break; } return bp-start; } /* * Read from the network up to a '\n' or some other break. * * If in binary mode, buffer characters but don't * * The following characters are special: * '\r\n's and '\r's get turned into '\n's. * ^H erases the last character buffered. * ^U kills the whole line buffered. * ^W erases the last word * ^D causes a 0-lenght line to be returned. * Intr causes an "interrupt" note to be sent to the children. */ #define ECHO(c) { *ebp++ = (c); } #define BACKSPACE() { ECHO('\b'); ECHO(' '); ECHO('\b'); } int fromnet(char *bp, int len) { int c; char echobuf[1024]; char *ebp; char *start; static int crnl; static int doeof; /* simulate an EOF as a 0 length input */ if(doeof){ doeof = 0; return 0; } for(ebp = echobuf,start = bp; bp-start < len && ebp-echobuf < sizeof(echobuf); ){ c = Bgetc(&netib); if(c < 0){ if(bp == start) return -1; else break; } /* telnet protocol only */ if(!noproto){ /* protocol messages */ switch(c){ case Iac: crnl = 0; c = Bgetc(&netib); if(c == Iac) break; control(&netib, c); continue; case 0: /* telnet ignores nulls */ continue; } } /* \r\n or \n\r become \n */ if(c == '\r' || c == '\n'){ if(crnl && crnl != c){ crnl = 0; continue; } if(cons->raw == 0 && opt[Echo].local){ ECHO('\r'); ECHO('\n'); cons->col = 0; cons->scol = -1; } crnl = c; *bp++ = '\n'; break; } else crnl = 0; /* raw processing (each character terminates */ if(cons->raw){ *bp++ = c; break; } /* in binary mode, there are no control characters */ if(opt[Binary].local){ if(opt[Echo].local) ECHO(c); *bp++ = c; continue; } /* cooked processing */ if(cons->scol == -1) cons->scol = cons->col; switch(c){ case 0x04: if(bp != start) doeof = 1; goto out; case 0x08: /* ^H */ if(start < bp) { bp--; if(opt[Echo].local) rubout(bp, start, &ebp); } break; case 0x15: /* ^U */ if(opt[Echo].local && cons->scol >= 0) { while (cons->col > cons->scol) { BACKSPACE(); cons->col--; } } bp = start; break; case 0x17: /* ^W */ if (opt[Echo].local) { while (bp > start && !alnum(bp[-1])) rubout(--bp, start, &ebp); while (bp > start && alnum(bp[-1])) { bp--; BACKSPACE(); cons->col--; } } break; case 0x7f: /* Del */ write(notefd, "interrupt", 9); ECHO('\r'); ECHO('\n'); bp = start; cons->col = 0; cons->scol = -1; break; case 0x09: /* Tab */ if(opt[Echo].local) { cons->col = (cons->col + 8) & ~7; ECHO(c); } *bp++ = c; break; default: if(opt[Echo].local) { if( c >= ' ' ) { ECHO(c); cons->col++; } else { ECHO('^'); ECHO(0x40|c); cons->col += 2; } } *bp++ = c; } if(ebp != echobuf && !cons->noecho) write(1, echobuf, ebp-echobuf); ebp = echobuf; } out: if(ebp != echobuf && !cons->noecho) write(1, echobuf, ebp-echobuf); return bp - start; } /* * Rub out an echoed character */ void rubout(char *bp, char *buf, char **pp) { char *ebp = *pp; int col; char *q; if( *bp == '\t' ) { /* tough case */ col = cons->scol; for(q = buf ; q < bp ; q++) { if(*q == '\t') col = (col + 8) & ~07; else if(*q < ' ') col += 2; else col++; } while(cons->col > col) { BACKSPACE(); cons->col--; } *pp = ebp; return; } else if( *bp < ' ' ) { cons->col--; BACKSPACE(); } cons->col--; BACKSPACE(); *pp = ebp; } int termchange(Biobuf *bp, int cmd) { char buf[8]; char *p = buf; if(cmd != Will) return 0; /* ask other side to send term type info */ *p++ = Iac; *p++ = Sb; *p++ = opt[Term].code; *p++ = 1; *p++ = Iac; *p++ = Se; return iwrite(Bfildes(bp), buf, p-buf); } int termsub(Biobuf *bp, uchar *sub, int n) { char term[NAMELEN]; USED(bp); if(n-- < 1 || sub[0] != 0) return 0; if(n >= sizeof term) n = sizeof term; strncpy(term, (char*)sub, n); putenv("TERM", term); return 0; } int xlocchange(Biobuf *bp, int cmd) { char buf[8]; char *p = buf; if(cmd != Will) return 0; /* ask other side to send x display info */ *p++ = Iac; *p++ = Sb; *p++ = opt[Xloc].code; *p++ = 1; *p++ = Iac; *p++ = Se; return iwrite(Bfildes(bp), buf, p-buf); } int xlocsub(Biobuf *bp, uchar *sub, int n) { char xloc[NAMELEN]; USED(bp); if(n-- < 1 || sub[0] != 0) return 0; if(n >= sizeof xloc) n = sizeof xloc; strncpy(xloc, (char*)sub, n); putenv("DISPLAY", xloc); return 0; } /* * create a shared segment. Make is start 2 meg higher than the current * end of process memory. */ void* share(int len) { ulong vastart; vastart = ((ulong)sbrk(0)) + 2*1024*1024; if(segattach(0, "shared", (void *)vastart, len) < 0) return 0; return (void*)vastart; } /* * bind a pipe onto consctl and keep reading it to * get changes to console state. */ int conssim(void) { int i, n; int fd; int tries; char buf[128]; char *field[10]; /* a pipe to simulate the /dev/cons */ if(bind("#|", "/mnt/cons/cons", MREPL) < 0 || bind("/mnt/cons/cons/data1", "/dev/cons", MREPL) < 0) fatal("/dev/cons", 0, 0); /* a pipe to simulate consctl */ if(bind("#|", "/mnt/cons/consctl", MBEFORE) < 0 || bind("/mnt/cons/consctl/data1", "/dev/consctl", MREPL) < 0) fatal("/dev/consctl", 0, 0); /* a process to read /dev/consctl and set the state in cons */ switch(fork()){ case -1: fatal("forking", 0, 0); case 0: break; default: return open("/mnt/cons/cons/data", ORDWR); } setfields(" "); for(tries = 0; tries < 100; tries++){ cons->raw = 0; cons->hold = 0; fd = open("/mnt/cons/consctl/data", OREAD); if(fd < 0) continue; tries = 0; for(;;){ n = read(fd, buf, sizeof(buf)-1); if(n <= 0) break; buf[n] = 0; n = getmfields(buf, field, 10); for(i = 0; i < n; i++){ if(strcmp(field[i], "rawon") == 0) cons->raw = 1; else if(strcmp(field[i], "rawoff") == 0) cons->raw = 0; else if(strcmp(field[i], "holdon") == 0) cons->hold = 1; else if(strcmp(field[i], "holdoff") == 0) cons->hold = 0; } } close(fd); } exits(0); return -1; } int alnum(int c) { /* * Hard to get absolutely right. Use what we know about ASCII * and assume anything above the Latin control characters is * potentially an alphanumeric. */ if(c <= ' ') return 0; if(0x7F<=c && c<=0xA0) return 0; if(strchr("!\"#$%&'()*+,-./:;<=>?@`[\\]^{|}~", c)) return 0; return 1; } >From 9fans-outgoing-owner Thu Aug 17 18:35:05 1995 Received: by colossus.cse.psu.edu id <46221>; Thu, 17 Aug 1995 18:26:30 -0400 Received: from postman.ncube.com ([134.242.8.47]) by colossus.cse.psu.edu with SMTP id <46277>; Thu, 17 Aug 1995 18:20:55 -0400 Received: from butler.ncube.com by postman.ncube.com (4.1/SMI-4.1) id AA25756; Thu, 17 Aug 95 15:13:32 PDT Received: from skynet.ncube.com by butler.ncube.com (5.0/SMI-SVR4) id AA06167; Thu, 17 Aug 1995 15:13:25 +0800 Date: Thu, 17 Aug 1995 03:13:25 -0400 From: avg@postman.ncube.com (Vadim Antonov) Message-Id: <9508172213.AA06167@butler.ncube.com> To: 9fans Subject: FTPD plaintext password option Content-Length: 839 Sender: owner-9fans Precedence: bulk Reply-To: 9fans Few changes, to provide the same functionality as -P in telnetd. --vadim cpu% pwd /sys/src/cmd/service cpu% diff ftp.c.old ftp.c 125a126 > int plaintext; 169a171,173 > case 'P': > plaintext = 1; > break; 471c475,476 < return reply("331 encrpyt challenge, %s, as a password", ch.chal); --- > return reply(plaintext? "331 Your password, please?" : > "331 Encrypt challenge, %s, as a password", ch.chal); 479a485,486 > char key[DESKEYLEN]; > 485c492,497 < return reply("531 Send user id before encrypted challenge"); --- > return reply("531 Send user id before password"); > if(plaintext) { > passtokey(key, response); > strcpy(response, ch.chal); > netcrypt(key, response); > } cpu% >From 9fans-outgoing-owner Thu Aug 17 18:50:59 1995 Received: by colossus.cse.psu.edu id <46107>; Thu, 17 Aug 1995 18:41:56 -0400 Received: from postman.ncube.com ([134.242.8.47]) by colossus.cse.psu.edu with SMTP id <46270>; Thu, 17 Aug 1995 18:38:22 -0400 Received: from butler.ncube.com by postman.ncube.com (4.1/SMI-4.1) id AA26094; Thu, 17 Aug 95 15:23:37 PDT Received: from skynet.ncube.com by butler.ncube.com (5.0/SMI-SVR4) id AA06239; Thu, 17 Aug 1995 15:23:33 +0800 Date: Thu, 17 Aug 1995 03:23:33 -0400 From: avg@postman.ncube.com (Vadim Antonov) Message-Id: <9508172223.AA06239@butler.ncube.com> To: 9fans Subject: Fun with cs. Cc: pluto@postman.ncube.com Content-Length: 379 Sender: owner-9fans Precedence: bulk Reply-To: 9fans In my setup ndb/cs refused to handle strings like net!$auth!ticket. The fix is to change /rc/bin/cpurc to call ndb/cs -n before using sysname *and* call it once again (instead of sending "add il tcp udp" to /net/cs) after network initialization is complete. I guess "add" command is broken somehow but have no wish to investigate as the workaround is straightforward. --vadim >From 9fans-outgoing-owner Thu Aug 17 19:31:16 1995 Received: by colossus.cse.psu.edu id <46236>; Thu, 17 Aug 1995 19:20:34 -0400 Received: from noao.edu ([140.252.1.54]) by colossus.cse.psu.edu with SMTP id <46279>; Thu, 17 Aug 1995 19:14:39 -0400 Received: from gemini.tuc.noao.edu by noao.edu (4.1/SAG-Noao.G102) id AA23731; Thu, 17 Aug 95 16:06:30 MST; for 9fans@cse.psu.edu Received: from daikon.tuc.noao.edu.noao by gemini.tuc.noao.edu (4.1/SAG.sat.14) id AA18015; Thu, 17 Aug 95 16:06:29 MST; for 9fans@cse.psu.edu Received: by daikon.tuc.noao.edu.noao (4.1/SAG.sun.8) id AA06029; Thu, 17 Aug 95 16:06:27 MST; for 9fans@cse.psu.edu Date: Thu, 17 Aug 1995 19:06:27 -0400 From: rwolff@noao.edu (Richard Wolff) Message-Id: <9508172306.AA06029@daikon.tuc.noao.edu.noao> To: 9fans Subject: errata Sender: owner-9fans Precedence: bulk Reply-To: 9fans I'm curious as to how errata are going to be handled over the long run. The posting via the web page is currently acceptable, but I'm not convinced this will scale well. Moreover, there are various patches being posted that may apparently cure a problem but, for some reason or another, not be a solution that's adequately blessed by the plan9 developers: eg, they just don't like the solution, it doesn't fit the long range notion of some changes they've not yet promulgated, it's really not correct, etc. So I'll probably not want to incorporate everything I see on the net ( :-) ). On the other hand, I don't want to keep running a system with known and readily repaired bug(lets). I'd like to be able to know what's the current "vanilla" plan9...that is, the system that would be distributed today on a new CD-ROM, were one to be generated. So, how are changes to be dealt with? Is there going to be a clearinghouse for these? If the web page is used, should one just expect to download it every so often and diff it against a previous version to see what's changed? Or an ftp'able file that contains all the diff listings suitable for something ala patch. Richard >From 9fans-outgoing-owner Thu Aug 17 20:04:15 1995 Received: by colossus.cse.psu.edu id <46225>; Thu, 17 Aug 1995 19:54:46 -0400 Received: from plan9.cs.su.oz.au ([129.78.96.2]) by colossus.cse.psu.edu with SMTP id <46221>; Thu, 17 Aug 1995 19:54:26 -0400 From: Boyd Roberts Date: Thu, 17 Aug 1995 19:39:48 -0400 To: 9fans Subject: Re: Help wanted Plan9 a piece of junk! In-Reply-To: Message-ID: <199508180939.3204.out.badal@plan9.cs.su.oz.au> Sender: owner-9fans Precedence: bulk Reply-To: 9fans From: bhogan@bedlam.rahul.net (Bill Hogan) This I do not doubt, but comp.os.linux.* is not a multi-billion dollar corporation and Linux does not cost $350, either. BH plan9 comes from a small group in 1127, not the at&t colossus. >From 9fans-outgoing-owner Thu Aug 17 20:15:38 1995 Received: by colossus.cse.psu.edu id <46227>; Thu, 17 Aug 1995 20:09:00 -0400 Received: from plan9.cs.su.oz.au ([129.78.96.2]) by colossus.cse.psu.edu with SMTP id <46107>; Thu, 17 Aug 1995 20:08:39 -0400 From: Boyd Roberts Date: Thu, 17 Aug 1995 19:52:42 -0400 To: 9fans Subject: Re: More bugs. In-Reply-To: <9508172147.AA05991@butler.ncube.com> Message-ID: <199508180952.3303.9.babof@plan9.cs.su.oz.au> Sender: owner-9fans Precedence: bulk Reply-To: 9fans From: avg@postman.ncube.com (Vadim Antonov) The quick fix is appended. As always, the real fix would be to make echo-on and echo-off _separate_ from raw-on and raw-off. I remember seeing the same kind of problem in Unix version 6. I guess aliens from outer space kept somebody in suspended animation all those years :) ohh no, rob has got it right with raw mode. any other tty mode is a waste of time; just extra complexity for nothing. this kind of thinking will result in a bsd-tty line discipline for plan9, job control, csh, dbx -- the horror, the horror... >From 9fans-outgoing-owner Thu Aug 17 20:22:30 1995 Received: by colossus.cse.psu.edu id <46221>; Thu, 17 Aug 1995 20:16:00 -0400 Received: from plan9.cs.su.oz.au ([129.78.96.2]) by colossus.cse.psu.edu with SMTP id <46270>; Thu, 17 Aug 1995 20:15:30 -0400 From: Boyd Roberts Date: Thu, 17 Aug 1995 20:02:37 -0400 To: 9fans Message-ID: <199508181002.3414.9.babog@plan9.cs.su.oz.au> Sender: owner-9fans Precedence: bulk Reply-To: 9fans if people are going to post source, please post diffs as they highlight the fix rather than hiding it. >From 9fans-outgoing-owner Thu Aug 17 20:28:41 1995 Received: by colossus.cse.psu.edu id <46225>; Thu, 17 Aug 1995 20:21:46 -0400 Received: from plan9.cs.su.oz.au ([129.78.96.2]) by colossus.cse.psu.edu with SMTP id <46236>; Thu, 17 Aug 1995 20:15:07 -0400 From: Boyd Roberts Date: Thu, 17 Aug 1995 19:59:08 -0400 To: 9fans Subject: Re: new telnetd (again) In-Reply-To: <9508172156.AA06022@butler.ncube.com> Message-ID: <199508180959.3392.out.badam@plan9.cs.su.oz.au> Sender: owner-9fans Precedence: bulk Reply-To: 9fans From: avg@postman.ncube.com (Vadim Antonov) The "more improved" line discipline plus the one message i'm worried about it, the next it happens... >From 9fans-outgoing-owner Thu Aug 17 21:08:13 1995 Received: by colossus.cse.psu.edu id <46221>; Thu, 17 Aug 1995 21:02:12 -0400 Received: from postman.ncube.com ([134.242.8.47]) by colossus.cse.psu.edu with SMTP id <46225>; Thu, 17 Aug 1995 21:01:56 -0400 Received: from butler.ncube.com by postman.ncube.com (4.1/SMI-4.1) id AA00834; Thu, 17 Aug 95 18:02:01 PDT Received: from skynet.ncube.com by butler.ncube.com (5.0/SMI-SVR4) id AA07098; Thu, 17 Aug 1995 18:01:55 +0800 Date: Thu, 17 Aug 1995 06:01:55 -0400 From: avg@postman.ncube.com (Vadim Antonov) Message-Id: <9508180101.AA07098@butler.ncube.com> To: 9fans Subject: Re: More bugs. Content-Length: 2205 Sender: owner-9fans Precedence: bulk Reply-To: 9fans >ohh no, rob has got it right with raw mode. any other tty mode is >a waste of time; just extra complexity for nothing. this kind of >thinking will result in a bsd-tty line discipline for plan9, job >control, csh, dbx -- the horror, the horror... Plan9 already has "line discipline" modules is several places (devcons, 81/2, readln in auth utilities, telnetd), so instead of replicating it would be useful to keep it in one place. Raw mode and no echo mode are two different things and lumping them together only makes all programs which read passwords to be equipped with handling of kill and erase. Most of the complexity of BSD and SysV line disciplines comes from the history of the issue, as in v6 and v7 the hardware-specific things were lumped together with the line discipline stuff. Namely, ~ECHO had dual functon -- to handle half-duplex terminals *and* to allow reading passwords. Needless to say it was inconvinient for both :) RAW was "both ways", meaning no conversion on output to terminals and no cooked processing on input. That was very funny on terminals which needed output processing for things like Shift-In and Shift-Out (yes, Virgina, there are people who speak funny languages with letters like ya and tvyordyi znak). For the hack value -- "no echo" on half-duplex hardcopy terminals means typing over many times. To my knowledge unix never did that right. If you don't like line disciplines you'd better not do telnet-ing around. There are different things (even TTYs) on the Internet. I respect the "simplicity is beauty" maxim but tins on a string are arguably simplier than telephone. Much of ugliness of present-day unices comes from the under-functionality of the original system. The holes were plugged by other people, differently, and so the Babylon started. Later, some sorely misguided souls tried to "unify" things by getting all variances into one system instead of redesigning things to provide clear separation of functions. Providing no functionality is not an answer, as people who need to solve real problems in the real life will find ways around it -- but it won't be pretty. Not at all. --vadim (kremvax? yes, i used to run _the_ kremvax). >From 9fans-outgoing-owner Thu Aug 17 21:23:48 1995 Received: by psuvax1.cse.psu.edu id <34184>; Thu, 17 Aug 1995 21:05:28 -0400 Received: from plan9.cs.york.ac.uk ([144.32.33.120]) by psuvax1.cse.psu.edu with SMTP id <34181>; Thu, 17 Aug 1995 21:04:55 -0400 From: forsyth@plan9.cs.york.ac.uk To: 9fans@cs.psu.edu Date: Thu, 17 Aug 1995 21:02:22 -0400 subject: fixes Message-Id: <95Aug17.210455edt.34181@psuvax1.cse.psu.edu> Sender: owner-9fans Precedence: bulk Reply-To: 9fans >>if people are going to post source, please post diffs >>as they highlight the fix rather than hiding it. yes, and it is probably ill-advised to put too much of THE SOURCE out in public, since it is subject to licence. diffs sometimes beg the question of a reference source (if you haven't got the CDROM on line), and they do not always avoid excessive detail, esp. without -b, but seem a reasonable compromise. diff -e is quite effective at hiding detail, but troublesome and downright confusing if the reference source turns out to be wrong! in Old Unix days there was some light-hearted discussion about whether it would be possible to reconstruct THAT SOURCE by accumulating all the diffs that had been published; enough people took the possibility seriously enough to try to ensure that only people with a licence could subscribe to the newsletters with the diffs. during the discussion about comp.os.plan9, it struck me that one of the advantages of a moderated newsgroup was that a moderator might spot the more obvious violations. even so, i don't mean to dent Vadim Antonov's enthusiasm, since it is natural to want to share joys; or, in Bill Hogan's case, misery. >From 9fans-outgoing-owner Thu Aug 17 21:51:39 1995 Received: by colossus.cse.psu.edu id <46227>; Thu, 17 Aug 1995 21:43:33 -0400 Received: from plan9.cs.su.oz.au ([129.78.96.2]) by colossus.cse.psu.edu with SMTP id <46225>; Thu, 17 Aug 1995 21:43:12 -0400 From: Boyd Roberts Date: Thu, 17 Aug 1995 21:15:39 -0400 To: 9fans Subject: Re: More bugs. In-Reply-To: <9508180101.AA07098@butler.ncube.com> Message-ID: <199508181115.3805.9.baboj@plan9.cs.su.oz.au> Sender: owner-9fans Precedence: bulk Reply-To: 9fans From: avg@postman.ncube.com (Vadim Antonov) Plan9 already has "line discipline" modules is several places (devcons, 81/2, readln in auth utilities, telnetd), so instead of replicating it would be useful to keep it in one place. i don't have a problem with lines discipline as a technology, it's just their misuse that concerns me. i've seen that (in the old system) readln was duplicated in too many places. that should be addresed. adding further /dev/cons modes is a road to ruin: they're unnecessary in any modern system -- rob Raw mode and no echo mode are two different things and lumping them together only makes all programs which read passwords to be equipped with handling of kill and erase. on plan9 their are bugger all of these things that want to fool with the cons mode; the interface is the window system, not some archaic tty interface. occassionally you are faced with this stuff: ftpfs, passwd. but, for the most part you're not. --vadim (kremvax? yes, i used to run _the_ kremvax). yes, i know who you are vadim. you look just like brucee :-) >From 9fans-outgoing-owner Thu Aug 17 22:00:28 1995 Received: by colossus.cse.psu.edu id <46236>; Thu, 17 Aug 1995 21:52:27 -0400 Received: from staff.cs.su.OZ.AU ([129.78.8.1]) by colossus.cse.psu.edu with SMTP id <46272>; Thu, 17 Aug 1995 21:51:08 -0400 Received: from staff.cs.su.oz.au by staff.cs.su.OZ.AU (mail from bruce for 9fans@cse.psu.edu) with MHSnet; Fri, 18 Aug 1995 11:51:05 +1000 Date: Thu, 17 Aug 1995 21:34:17 -0400 From: bruce@staff.cs.su.oz.au (Bruce Janson) Subject: fixes To: 9fans Message-Id: <95Aug17.215108edt.46272@colossus.cse.psu.edu> Sender: owner-9fans Precedence: bulk Reply-To: 9fans .. From: forsyth@plan9.cs.york.ac.uk .. Date: Thu, 17 Aug 1995 21:02:22 -0400 Message-Id: <95Aug17.210455edt.34181@psuvax1.cse.psu.edu> .. >>if people are going to post source, please post diffs >>as they highlight the fix rather than hiding it. yes, and it is probably ill-advised to put too much of THE SOURCE out in public, since it is subject to licence. diffs sometimes .. Use the source Luke. Specifically, nominate a particular fragment of the original source (shared by all legal players) as a key to encrypt and decrypt pieces of newer source. Such encrypted newer source could be posted or made available for anon ftp. The efficacy of this scheme would degrade over time as fragments of the original source `escaped', but this might be secure enough to keep the lawyers happy. Cheers, Bruce Janson Email: bruce@cs.usyd.edu.au Basser Department of Computer Science Phone: +61-2-351-3423/4 University of Sydney, N.S.W., 2006, AUSTRALIA Fax: +61-2-351-3838 >From 9fans-outgoing-owner Thu Aug 17 22:22:08 1995 Received: by colossus.cse.psu.edu id <46235>; Thu, 17 Aug 1995 22:13:54 -0400 Received: from postman.ncube.com ([134.242.8.47]) by colossus.cse.psu.edu with SMTP id <46225>; Thu, 17 Aug 1995 22:13:38 -0400 Received: from butler.ncube.com by postman.ncube.com (4.1/SMI-4.1) id AA02770; Thu, 17 Aug 95 19:13:48 PDT Received: from skynet.ncube.com by butler.ncube.com (5.0/SMI-SVR4) id AA07261; Thu, 17 Aug 1995 19:13:43 +0800 Date: Thu, 17 Aug 1995 07:13:43 -0400 From: avg@postman.ncube.com (Vadim Antonov) Message-Id: <9508180213.AA07261@butler.ncube.com> To: 9fans Subject: Re: fixes Content-Length: 86 Sender: owner-9fans Precedence: bulk Reply-To: 9fans Did anybody port "patch" to plan9? That would make diffs a lot more useful. --vadim >From 9fans-outgoing-owner Thu Aug 17 22:30:49 1995 Received: by colossus.cse.psu.edu id <46263>; Thu, 17 Aug 1995 22:23:11 -0400 Received: from postman.ncube.com ([134.242.8.47]) by colossus.cse.psu.edu with SMTP id <46107>; Thu, 17 Aug 1995 22:22:53 -0400 Received: from butler.ncube.com by postman.ncube.com (4.1/SMI-4.1) id AA03168; Thu, 17 Aug 95 19:22:59 PDT Received: from skynet.ncube.com by butler.ncube.com (5.0/SMI-SVR4) id AA07281; Thu, 17 Aug 1995 19:22:53 +0800 Date: Thu, 17 Aug 1995 07:22:53 -0400 From: avg@postman.ncube.com (Vadim Antonov) Message-Id: <9508180222.AA07281@butler.ncube.com> To: 9fans Subject: Re: More bugs. Content-Length: 1109 Sender: owner-9fans Precedence: bulk Reply-To: 9fans >i don't have a problem with lines discipline as a technology, it's >just their misuse that concerns me. i've seen that (in the old system) >readln was duplicated in too many places. that should be addresed. >adding further /dev/cons modes is a road to ruin: It still is. And with different bugs in different places. Verry funnny. > they're unnecessary in any modern system -- rob Yep. As long as you don't get to move to a real world where most of terminals are messy-loss machines, all of them have vt100 emulator. >on plan9 their are bugger all of these things that want to fool >with the cons mode; the interface is the window system, not some >archaic tty interface. occassionally you are faced with >this stuff: ftpfs, passwd. but, for the most part you're not. Plan9 is a text-based system, just like good 'ol unix. A window system is merely something to enter text. There is absolutely *no* reason for making it hard to work from other systems. Particularly, my additions to telnetd made telnet session to feel like 81/2 terminal (though you can't run sam or do Unicode). --vadim >From 9fans-outgoing-owner Thu Aug 17 22:40:36 1995 Received: by colossus.cse.psu.edu id <46273>; Thu, 17 Aug 1995 22:33:04 -0400 Received: from postman.ncube.com ([134.242.8.47]) by colossus.cse.psu.edu with SMTP id <46107>; Thu, 17 Aug 1995 22:32:44 -0400 Received: from butler.ncube.com by postman.ncube.com (4.1/SMI-4.1) id AA03501; Thu, 17 Aug 95 19:32:38 PDT Received: from skynet.ncube.com by butler.ncube.com (5.0/SMI-SVR4) id AA07299; Thu, 17 Aug 1995 19:32:29 +0800 Date: Thu, 17 Aug 1995 07:32:29 -0400 From: avg@postman.ncube.com (Vadim Antonov) Message-Id: <9508180232.AA07299@butler.ncube.com> To: 9fans Subject: Re: fixes Content-Length: 510 Sender: owner-9fans Precedence: bulk Reply-To: 9fans >From the legal point of view posting "old lines" in the diff and posting a single source file are identical, and both are covered by "fair use", as in both cases the "original bytes" are present and are useless without the rest of the system. Even *names of files* can be considered "violation", see also the text of USL's complaint against BSD Inc. Can somebody from Bell Labs explain their policy on posting fixes and additions in the public mailing lists? Just to put the discussion to the rest. --vadim >From 9fans-outgoing-owner Thu Aug 17 23:50:30 1995 Received: by colossus.cse.psu.edu id <46227>; Thu, 17 Aug 1995 23:42:21 -0400 Received: from plan9.att.com ([192.20.225.252]) by colossus.cse.psu.edu with SMTP id <46221>; Thu, 17 Aug 1995 23:42:05 -0400 From: presotto@plan9.att.com To: 9fans Date: Thu, 17 Aug 1995 23:31:44 -0400 Message-Id: <95Aug17.234205edt.46221@colossus.cse.psu.edu> Sender: owner-9fans Precedence: bulk Reply-To: 9fans As advised by 9fans, we've replaced the online distribution with one containing some of the more important fixes, i.e., those that allow more sites to install plan 9. disk1 and disk2.vd are new and contain: - the floppy DMA overrun fixes - changes to devata.c to put up with disks returning bogus ident information - the current disk/prep - the current aux/vga and /lib/vgadb. It's tested to the extent that I tried what I had the hardware to try. Please tell me if anyone has problems. The old versions are still out there under the names disk1.orig and disk{2,3,4}.vd.orig. >From 9fans-outgoing-owner Fri Aug 18 00:01:02 1995 Received: by colossus.cse.psu.edu id <46263>; Thu, 17 Aug 1995 23:51:59 -0400 Received: from plan9.cs.su.oz.au ([129.78.96.3]) by colossus.cse.psu.edu with SMTP id <46107>; Thu, 17 Aug 1995 23:51:34 -0400 Date: Thu, 17 Aug 1995 23:41:11 -0400 From: dhog@plan9.cs.su.oz.au To: 9fans Subject: Re: fixes Message-Id: <95Aug17.235134edt.46107@colossus.cse.psu.edu> Sender: owner-9fans Precedence: bulk Reply-To: 9fans >Did anybody port "patch" to plan9? That would make >diffs a lot more useful. Yes, and it's not too hard either. You can run patch's configure script under ape, and it works suprisingly well. Then you just have to edit the Makefile, adding "LIBS = -lap" and deleting "rename.o" from OBJS, and edit util.c, replacing ask() with something sensible. Oh, and you need to apply the fix to ape's rename() function that I posted to the list. So, just run "ape/psh", then type "sh configure", edit the Makefile and util.c as suggested above, then type make, and you should get a patch binary. If patch corrupts your files, then you need to fix rename() (don't try this at home kids!) Here is the hacked version of ask() that I use, which doesn't try to read standard output or standard error: void ask(pat,arg1,arg2,arg3) char *pat; long arg1,arg2,arg3; { static int ttyfd = -1; int r; Sprintf(buf, pat, arg1, arg2, arg3); Fflush(stderr); if (ttyfd >= 0 || (ttyfd = open("/dev/cons", 2)) >= 0) { write(ttyfd, buf, strlen(buf)); r = read(ttyfd, buf, sizeof buf); Close(ttyfd); } else { /* no terminal at all--default it */ buf[0] = '\n'; r = 1; } if (r <= 0) buf[0] = 0; else buf[r] = '\0'; } >From 9fans-outgoing-owner Fri Aug 18 04:34:27 1995 Received: by psuvax1.cse.psu.edu id <34036>; Fri, 18 Aug 1995 04:17:10 -0400 Received: from cegelecproj.co.uk ([159.245.72.6]) by psuvax1.cse.psu.edu with SMTP id <34033>; Fri, 18 Aug 1995 04:16:20 -0400 Received: from vampire.cegelecproj.co.uk (cerberus.cegelecproj.co.uk) by cegelecproj.co.uk (4.1/SMI-4.1) id AA00785; Fri, 18 Aug 95 09:16:01 BST Received: from phantom.cegelecproj.co.uk (phantom.limbo.cegelecproj.co.uk) by vampire.cegelecproj.co.uk (5.0/SMI-SVR4) id AA17066; Fri, 18 Aug 1995 09:15:58 +0100 Received: from phantom (localhost) by phantom.cegelecproj.co.uk (5.0/SMI-SVR4) id AA16643; Fri, 18 Aug 1995 09:15:54 +0100 Message-Id: <9508180815.AA16643@phantom.cegelecproj.co.uk> X-Mailer: exmh version 1.6.1 5/23/95 To: 9fans@cs.psu.edu Subject: UNIX auth servers X-Face: Iqsa(US9p?)Y^W+6Ff[Z]rM"uFE) lFDjag1e]\/#2 X-Planation: X-Faces can be viewed with Faces from cs.indiana.edu. Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 18 Aug 1995 04:15:52 -0400 From: Steve_Kilbane Content-Length: 304 Sender: owner-9fans Precedence: bulk Reply-To: 9fans This is probably a daft question, but is a UNIX-based auth server a feasible proposition? Current hardware limitations here mean that I can swipe disk space from our UNIX servers, to allow me to run a diskless Plan 9 terminal, but I'm currently limited to just logging in as "none" all the time. steve >From 9fans-outgoing-owner Fri Aug 18 07:59:58 1995 Received: by psuvax1.cse.psu.edu id <34036>; Fri, 18 Aug 1995 07:40:22 -0400 Received: from plan9.cs.york.ac.uk ([144.32.33.120]) by psuvax1.cse.psu.edu with SMTP id <34033>; Fri, 18 Aug 1995 07:39:48 -0400 From: forsyth@plan9.cs.york.ac.uk To: 9fans@cs.psu.edu Date: Fri, 18 Aug 1995 07:26:25 -0400 subject: secure login without digital pathways box Message-Id: <95Aug18.073948edt.34033@psuvax1.cse.psu.edu> Sender: owner-9fans Precedence: bulk Reply-To: 9fans >>plaintext-password authentication option for >>those who does not have SecureNet keys or use >>reasonable firewalls. if, like us, you are unwilling to reduce the level of security the system offers -- we've got lots of potential ethernet snoopers -- an alternative is to provide a version of `netkey' on your unix systems, with which to calculate the response to a plan 9 challenge. this is a little trickier with this release since the source for crypt has not been included for the usual batty munitions act reasons. i used one i prepared earlier, but has anyone got a good plug compatible replacement that can be placed somewhere outside the USA? it might be a nice touch to put it on whatever is kremvax these days. >From 9fans-outgoing-owner Fri Aug 18 08:24:12 1995 Received: by colossus.cse.psu.edu id <46287>; Fri, 18 Aug 1995 08:11:24 -0400 Received: from plan9.att.com ([192.20.225.252]) by colossus.cse.psu.edu with SMTP id <46286>; Fri, 18 Aug 1995 08:11:08 -0400 From: presotto@plan9.att.com To: 9fans Date: Fri, 18 Aug 1995 08:04:22 -0400 Subject: re: UNIX auth servers Message-Id: <95Aug18.081108edt.46286@colossus.cse.psu.edu> Sender: owner-9fans Precedence: bulk Reply-To: 9fans It's easy enough to do. However, you would have to use TCP or write an IL protocol driver for Unix. By default we use IL everywhere. You'll also have to change the kernel so that it does authentication when it uses TCP, pretty small change. Currently it doesn't. >From 9fans-outgoing-owner Fri Aug 18 08:42:03 1995 Received: by colossus.cse.psu.edu id <46286>; Fri, 18 Aug 1995 08:31:19 -0400 Received: from plan9.att.com ([192.20.225.252]) by colossus.cse.psu.edu with SMTP id <46285>; Fri, 18 Aug 1995 08:31:02 -0400 From: presotto@plan9.att.com To: 9fans Date: Fri, 18 Aug 1995 08:19:57 -0400 Subject: passwords in the clear Message-Id: <95Aug18.083102edt.46285@colossus.cse.psu.edu> Sender: owner-9fans Precedence: bulk Reply-To: 9fans My heart is broken, I can't go on. I thought I finally got rid of the damn things. Vadim, what is the property of your firewall that forces you to go to a scheme that anyone can break by watching packets go by? >From 9fans-outgoing-owner Fri Aug 18 09:16:33 1995 Received: by colossus.cse.psu.edu id <46291>; Fri, 18 Aug 1995 09:02:24 -0400 Received: from sol.we.lc.ehu.es ([158.227.6.42]) by colossus.cse.psu.edu with SMTP id <46288>; Fri, 18 Aug 1995 09:01:52 -0400 Received: from sirius.we.lc.ehu.es by sol.we.lc.ehu.es (5.x/SMI-SVR4) id AA13303; Fri, 18 Aug 1995 15:00:57 +0200 From: borjam@we.lc.ehu.es (Borja Marcos) Message-Id: <9508181300.AA13303@sol.we.lc.ehu.es> Subject: Re: mouse quirk To: 9fans Date: Fri, 18 Aug 1995 09:26:18 -0400 In-Reply-To: from "Roger Peppe" at Aug 9, 95 01:28:42 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-9fans Precedence: bulk Reply-To: 9fans > > i wrote: > > a small problem with our (serial) mouse. it works fine except... > > problem seems to be solved - use a logitech mouse. > > i tried 4 different types of serial mouse before finally getting > hold of a logitech mouse to try. all of them exhibit the same > problem (except the ones with a 2/3 button switch, which gave > an 'unknown mouse type' error when in 3 button mode) > > the doc. doesn't seem to mention any possible compatibility probs > with non-logitech mice, and i know nothing about PC hardware; > has anyone out there got a non-logitech mouse to work (without > messing with the drivers) ? It was even more strange for me. The first time I installed Plan9 it didn't recognize the mouse I tried; the second time, it worked. (It's a Dexxa, I guess it's mouse-systems compatible) Regards, Borja. -- ******************************************************************* Borja Marcos | Preferred: borjam@we.lc.ehu.es Alangoeta, 11, 1. izq. | Others: borjamar@mx.sarenet.es 48990 - Algorta (Vizcaya) | 100015.3502@compuserve.com SPAIN | CIS: 100015,3502 ****************************************************************** >From 9fans-outgoing-owner Fri Aug 18 10:09:39 1995 Received: by colossus.cse.psu.edu id <46289>; Fri, 18 Aug 1995 09:57:40 -0400 Received: from galapagos.cse.psu.edu ([130.203.2.12]) by colossus.cse.psu.edu with SMTP id <46288>; Fri, 18 Aug 1995 09:57:24 -0400 Received: from localhost by galapagos.cse.psu.edu with SMTP id <12719>; Fri, 18 Aug 1995 09:57:28 -0400 To: 9fans Subject: Re: fixes In-reply-to: Your message of "Thu, 17 Aug 1995 07:13:43 EDT." <9508180213.AA07261@butler.ncube.com> Date: Fri, 18 Aug 1995 09:57:12 -0400 From: Scott Schwartz Message-Id: <95Aug18.095728edt.12719@galapagos.cse.psu.edu> Sender: owner-9fans Precedence: bulk Reply-To: 9fans avg@postman.ncube.com (Vadim Antonov) writes: | Did anybody port "patch" to plan9? That would make | diffs a lot more useful. I just compiled it, using ape and _BSD_EXTENSIONS. It's confused about prompting from /dev/tty, but that's probably easy to repair. Other than that, a few tests seemed to work. >From 9fans-outgoing-owner Fri Aug 18 15:00:42 1995 Received: by colossus.cse.psu.edu id <46293>; Fri, 18 Aug 1995 14:43:31 -0400 Received: from postman.ncube.com ([134.242.8.47]) by colossus.cse.psu.edu with SMTP id <46288>; Fri, 18 Aug 1995 14:43:06 -0400 Received: from butler.ncube.com by postman.ncube.com (4.1/SMI-4.1) id AA27898; Fri, 18 Aug 95 11:42:15 PDT Received: from skynet.ncube.com by butler.ncube.com (5.0/SMI-SVR4) id AA10306; Fri, 18 Aug 1995 11:42:11 +0800 Date: Thu, 17 Aug 1995 23:42:11 -0400 From: avg@postman.ncube.com (Vadim Antonov) Message-Id: <9508181842.AA10306@butler.ncube.com> To: 9fans Subject: Re: secure login without digital pathways box Content-Length: 1856 Sender: owner-9fans Precedence: bulk Reply-To: 9fans -----BEGIN PGP SIGNED MESSAGE----- Look for "fcrypt" at European FTP servers (ftp.funet.fi?) The source for DES was available everywhere outside US for at least a decade. As for reducing security -- when a corporation has all really valuable data stored on Unix machines it makes very little sense to protect toys zealously. Also, challenge-response schemes do not protect against active snoopers (you can always "steal" an already authenticated TCP or UDP session) and so are of very little value as protection against Ethernet snoopers (to steal packets you already have to have access to a machine on the Ethernet, ok?) This means that you still need a solid firewall, no matter if you use one-time passwords or not. Over long-distance links the one-time-password schemes are vulnerable to host-route attacks (a man-in-the-middle scheme) or compromised source hosts (i.e. the securenet thingie can't protect you if you're logging from a host with doctored telnet). The real answer to the network security is the encryption of all data and using key exchange schemes resistant to the man-in-the middle attacks. And, also, *never* log in from a machine you don't trust. Better carry your own laptoy, as security of the machine is as good as its physical security. There's no magic bullet. So, the options i added are designed for use inside protected LANs, where excessive level of paranoya only makes people irritated (and by doing so _compromises_ security, as then the users will tend to circumvent authentication so rendering it useless). - --vadim -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBMDTfQUDODjim2XUVAQEf1gP8DIh6ORzpLA4kslZ90Vk5igudSF5ZZpZP Kj60qTxNkztRk9X/qEKISPXjfe/Ifmmm5vPlBGPT42gcMvDKWcOrizrt9cTBsTBU apGzLyUT9AsuMmva4hfd0xyY3QHb/Aj84aRrGYFHtKLlbylpcEjoHtfncqie+R5L fVA1OYUKk+E= =bOcB -----END PGP SIGNATURE----- >From 9fans-outgoing-owner Fri Aug 18 15:12:19 1995 Received: by colossus.cse.psu.edu id <46288>; Fri, 18 Aug 1995 14:59:28 -0400 Received: from galapagos.cse.psu.edu ([130.203.2.12]) by colossus.cse.psu.edu with SMTP id <46297>; Fri, 18 Aug 1995 14:43:12 -0400 Received: from localhost by galapagos.cse.psu.edu with SMTP id <12773>; Fri, 18 Aug 1995 14:42:23 -0400 To: 9fans Subject: Re: errata In-reply-to: Your message of "Thu, 17 Aug 1995 19:06:27 EDT." <9508172306.AA06029@daikon.tuc.noao.edu.noao> Date: Fri, 18 Aug 1995 14:42:23 -0400 From: Scott Schwartz Message-Id: <95Aug18.144223edt.12773@galapagos.cse.psu.edu> Sender: owner-9fans Precedence: bulk Reply-To: 9fans rwolff@noao.edu (Richard Wolff) writes: | I'm curious as to how errata are going to be handled over the long | run. Or even over the short run... by now the pcdist images have diverged a lot from the source on the cdrom. >From 9fans-outgoing-owner Fri Aug 18 15:32:02 1995 Received: by colossus.cse.psu.edu id <46297>; Fri, 18 Aug 1995 15:16:16 -0400 Received: from postman.ncube.com ([134.242.8.47]) by colossus.cse.psu.edu with SMTP id <46340>; Fri, 18 Aug 1995 15:11:52 -0400 Received: from butler.ncube.com by postman.ncube.com (4.1/SMI-4.1) id AA28457; Fri, 18 Aug 95 12:02:17 PDT Received: from skynet.ncube.com by butler.ncube.com (5.0/SMI-SVR4) id AA10427; Fri, 18 Aug 1995 12:02:14 +0800 Date: Fri, 18 Aug 1995 00:02:14 -0400 From: avg@postman.ncube.com (Vadim Antonov) Message-Id: <9508181902.AA10427@butler.ncube.com> To: 9fans Subject: Re: passwords in the clear Content-Length: 1526 Sender: owner-9fans Precedence: bulk Reply-To: 9fans Dave Presotto wrote: >My heart is broken, I can't go on. I thought I finally got >rid of the damn things. >Vadim, what is the property of your firewall that forces you >to go to a scheme that anyone can break by watching packets >go by? If somebody can *watch* packets on Ethernet, that somebody can also *send* them, ok? The challenge-reply authentication is useless on LANs, as stealing an already authenticated TCP session is trivial. Sending an ARP bogon is very simple, and so is programming Pee-See cards for an arbitrary MAC address. Been there, done that. The only way to defeat snoopers on Ethernet is to encrypt all data or to use filtering bridges, or to use good application-level gateway and not bother with protection from insiders (which you never can do anyway... as an insider can always stick a floppy in your machine and voila! all data is his). Please, the false expectation of "security" is worse than the known lack of it. Overall, the security must be *adequate*, not *perfect*. If a person can walk to my machine i won't bother protecting my files with anything more elaborate than plaintext passwords, and the company already has an application-level gateway. For many of us, SNK doesn't worth the hassle (btw, i wrote the SNK stuff for BSD, so you can't call me ignorant or whatever). --vadim PS: A helpful SNK hint: to erase the memory you don't need to remove the batteries, just type in: ON 3 ENT 00000000 ENT repeat the sequence, and it'll give you the EO - prompt. >From 9fans-outgoing-owner Fri Aug 18 16:42:11 1995 Received: by colossus.cse.psu.edu id <46289>; Fri, 18 Aug 1995 16:33:05 -0400 Received: from cannon.ecf.toronto.edu ([128.100.8.5]) by colossus.cse.psu.edu with SMTP id <46288>; Fri, 18 Aug 1995 16:32:48 -0400 Received: by cannon.ecf.toronto.edu id <206>; Fri, 18 Aug 1995 16:32:48 -0400 From: Steve Kotsopoulos To: 9fans Subject: comp.os.plan9 FAQ Message-Id: <95Aug18.163248edt.206@cannon.ecf.toronto.edu> Date: Fri, 18 Aug 1995 16:32:42 -0400 Sender: owner-9fans Precedence: bulk Reply-To: 9fans Since comp.os.plan9 will be created soon, I've been working on the faq. If anyone wants to take a look at it, the url is http://www.ecf.toronto.edu/plan9/plan9faq.html Please send any comments or suggestions to steve@ecf.toronto.edu >From 9fans-outgoing-owner Fri Aug 18 17:03:45 1995 Received: by colossus.cse.psu.edu id <46303>; Fri, 18 Aug 1995 16:51:27 -0400 Received: from optima.CS.Arizona.EDU ([192.12.69.5]) by colossus.cse.psu.edu with SMTP id <46302>; Fri, 18 Aug 1995 16:51:10 -0400 Received: from baskerville.CS.Arizona.EDU by optima.CS.Arizona.EDU (5.65c/15) via SMTP id AA07168; Fri, 18 Aug 1995 13:51:20 MST Received: (from jdavis@localhost) by baskerville.CS.Arizona.EDU (8.6.9/8.6.6) id NAA25685; Fri, 18 Aug 1995 13:51:19 -0700 Date: Fri, 18 Aug 1995 16:51:19 -0400 From: Jim Davis X-Sender: jdavis@baskerville To: 9fans Subject: Re: comp.os.plan9 FAQ In-Reply-To: <95Aug18.163248edt.206@cannon.ecf.toronto.edu> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-9fans Precedence: bulk Reply-To: 9fans On Fri, 18 Aug 1995, Steve Kotsopoulos wrote: > Since comp.os.plan9 will be created soon... August 21st, in fact. Though the newgroup control message will probably take a few days to propagate across Usenet. >From 9fans-outgoing-owner Fri Aug 18 17:15:20 1995 Received: by colossus.cse.psu.edu id <46304>; Fri, 18 Aug 1995 17:05:13 -0400 Received: from plan9.att.com ([192.20.225.252]) by colossus.cse.psu.edu with SMTP id <46305>; Fri, 18 Aug 1995 17:03:12 -0400 From: presotto@plan9.att.com To: 9fans Date: Fri, 18 Aug 1995 16:48:37 -0400 Subject: religious wars Message-Id: <95Aug18.170312edt.46305@colossus.cse.psu.edu> Sender: owner-9fans Precedence: bulk Reply-To: 9fans We want to make clear why we fear clear passwords entering the telnet/ftp/etc code. If one takes Vadim's argument to the extreme, he should eliminate passwords internally since he has adequate protection, trusts everyone internally, and plan 9 is just a toy system. We ran that way ourselves for years (till management started using Plan 9 and wanted something better to keep us from seeing their secret stuff). Replacing ARP entries, changing MAC addresses, and taking over active sessions cause denial or interruption of service to people and are more likely to be detected. The first two don't even work unless you are on the same side of a gateway. Just stealing passwords is much harder to detect since it is entirely passive. It works an arbitrary number of hops away. Once acquired, the passwords are useable to set up new connections at any time as compared to the above attacks that are once only. These are hardly similar. In AT&T we are protected by a firewall similar to what you describe, one of the first in fact and built by our group. However, we still have people constantly creating backdoors to the internet all over the company, sometimes because we merge with (or buy out) someone that already has a less protected gateway, sometimes because someone finds the current firewalls confining and get their own links. Creating crappy internal security just allows others to take advantage of these lapses. Also, we use multiple networks, not just broadcast media like ethernet. Our ATM and Datakit networks aren't susceptible to spoofing though they can be snooped. In these, our security is infinitely better than clear passwords. In short, passwords in the clear are a worse mechanism than what we have. As Vadim points out, it could be better. The main reason for wanting passwords is that they make access from Unix or DOS easier. Out biggest fear is that this pressure will make passwords a default mechanism. We'ld rather see people working on getting Unix and DOS to use better security or making Plan 9 security tighter like adding expontial key exchange than to add options to Plan 9 to make it less secure. Just the ability to do passwords in the clear is the first step down a very steep slope. Climbing back up again is real hard. We have a chance for a system that never goes that route, why blow it. >From 9fans-outgoing-owner Fri Aug 18 17:45:26 1995 Received: by colossus.cse.psu.edu id <46289>; Fri, 18 Aug 1995 17:36:27 -0400 Received: from alpha.xerox.com ([13.1.64.93]) by colossus.cse.psu.edu with SMTP id <46288>; Fri, 18 Aug 1995 17:35:55 -0400 Received: from reynaldo.parc.xerox.com ([13.2.116.96]) by alpha.xerox.com with SMTP id <16067(1)>; Fri, 18 Aug 1995 14:35:54 PDT Received: from localhost by reynaldo.parc.xerox.com with SMTP id <34950>; Fri, 18 Aug 1995 14:35:42 -0700 X-Mailer: exmh version 1.6.1 5/23/95 To: 9fans cc: kerch@parc.xerox.com Subject: Re: religious wars In-reply-to: Your message of "Fri, 18 Aug 95 13:48:37 PDT." <95Aug18.170312edt.46305@colossus.cse.psu.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 18 Aug 1995 17:35:30 -0400 From: Berry Kercheval Message-Id: <95Aug18.143542pdt.34950@reynaldo.parc.xerox.com> Sender: owner-9fans Precedence: bulk Reply-To: 9fans >>>presotto@plan9.att.com said: > However, we still have people > constantly creating backdoors to the internet all > over the company Indeed. THe only time I know that PARC got seriously hacked, the intruders didn't come in through *our* firewall -- they got into Xerox somewhere else and just rode the corporate net over here. We keep talking about a firewall between PARC and the rest of Xerox, but managers frown on it for some reason :-) --berry Berry Kercheval :: Xerox Palo Alto Research Center >From 9fans-outgoing-owner Fri Aug 18 18:59:50 1995 Received: by colossus.cse.psu.edu id <46305>; Fri, 18 Aug 1995 18:51:41 -0400 Received: from galapagos.cse.psu.edu ([130.203.2.12]) by colossus.cse.psu.edu with SMTP id <46302>; Fri, 18 Aug 1995 18:51:25 -0400 Received: from localhost by galapagos.cse.psu.edu with SMTP id <12776>; Fri, 18 Aug 1995 18:51:28 -0400 To: 9fans Subject: Re: religious wars In-reply-to: Your message of "Fri, 18 Aug 1995 16:48:37 EDT." <95Aug18.170312edt.46305@colossus.cse.psu.edu> Date: Fri, 18 Aug 1995 18:51:23 -0400 From: Scott Schwartz Message-Id: <95Aug18.185128edt.12776@galapagos.cse.psu.edu> Sender: owner-9fans Precedence: bulk Reply-To: 9fans I agree with most of what Dave wrote; here's my 2€Ž€. | If one takes Vadim's argument to the extreme, he | should eliminate passwords internally since he | has adequate protection, trusts everyone | internally, and plan 9 is just a toy system. | We ran that way ourselves for years | (till management started using Plan 9 and wanted | something better to keep us from seeing | their secret stuff). Lots of things about the system, and unix before it, reflect this mode of development. Consider file permissions: user/group/other is adequate in uncomplicated circumstances, but in the typical university setting access control lists would make life much easier, particularly because the people you trust with particular files or directories varies so much and so dynamically. Also, there's a difference between any-user and unauthenticated-person that user none doesn't seem to capture. Shipping the system with telnetd allowing "none" to log in from anywhere strikes me as a mistake. Allowing anonymous 9p connections is worrysome too. AFS does better, since it lets you restrict what unauthenticated users are allowed to look at (easy with ACLs). | Out biggest fear is that this pressure will make | passwords a default mechanism. We'ld rather see | people working on getting Unix and DOS to use | better security or making Plan 9 security | tighter like adding expontial key exchange than | to add options to Plan 9 to make it less secure. | Just the ability to do passwords in the clear is | the first step down a very steep slope. Climbing | back up again is real hard. We have a chance for | a system that never goes that route, why blow it. I very strongly agree with this. In the unix world most people (and vendors) aggressively avoid kerberos, s/key, and other things that would improve our lives. Plan 9 is a rare and valuable example of doing things better and easier. When I show it off to visitors I always point that out. >From 9fans-outgoing-owner Fri Aug 18 19:27:46 1995 Received: by colossus.cse.psu.edu id <46310>; Fri, 18 Aug 1995 19:18:58 -0400 Received: from ncrhub1.ATTGIS.COM ([192.127.251.16]) by colossus.cse.psu.edu with SMTP id <46313>; Fri, 18 Aug 1995 19:17:20 -0400 Received: from ncrgw1 by ncrhub1.ATTGIS.COM id aa20561; 18 Aug 95 19:15 EDT Received: by ncrgw1.ATTGIS.COM; 18 Aug 95 19:12:38 EDT Received: by ncrhub4.ATTGIS.COM; 18 Aug 95 19:12:07 EDT Date: Fri, 18 Aug 1995 19:11:10 -0400 From: MAILER-DAEMON@ncrcae.columbiasc.NCR.COM Full-Name: Mail Router (smail 2.8.1 dl,da,fa,tu,po,qf,dbm 06/12/93 6) Subject: Returned mail To: 9fans Message-ID: <9508181915.aa20561@ncrhub1.ATTGIS.COM> Sender: owner-9fans Precedence: bulk Reply-To: 9fans Your mail could not be delivered because of the following reason: ----- Transcript of session follows ----- Executing: /usr/lib/mail/surrcmd/smtpqer -C -u ncrcae.ColumbiaSC.NCR.COM!ncrhub4!ncrgw1!cse.psu.edu!9fans yesac wescott@yesac smtpqer: Binary contents cannot be sent via SMTP server "/usr/lib/mail/surrcmd/smtpqer" failed - unknown mailer error 1 ----- Unsent message follows ----- >From ncrgw1!cse.psu.edu!9fans Fri Aug 18 19:11 EDT 1995 remote from ncrhub4 Received: by ncrhub4.ATTGIS.COM; 18 Aug 95 19:11:53 EDT Received: by ncrgw1.ATTGIS.COM; 18 Aug 95 19:09:08 EDT Received: by colossus.cse.psu.edu id <46305>; Fri, 18 Aug 1995 18:51:41 -0400 Received: from galapagos.cse.psu.edu ([130.203.2.12]) by colossus.cse.psu.edu with SMTP id <46302>; Fri, 18 Aug 1995 18:51:25 -0400 Received: from localhost by galapagos.cse.psu.edu with SMTP id <12776>; Fri, 18 Aug 1995 18:51:28 -0400 To: 9fans@cse.psu.edu Subject: Re: religious wars In-reply-to: Your message of "Fri, 18 Aug 1995 16:48:37 EDT." <95Aug18.170312edt.46305@colossus.cse.psu.edu> Date: Fri, 18 Aug 1995 18:51:23 -0400 From: Scott Schwartz Message-Id: <95Aug18.185128edt.12776@galapagos.cse.psu.edu> Sender: owner-9fans@cse.psu.edu Precedence: bulk Reply-To: 9fans@cse.psu.edu I agree with most of what Dave wrote; here's my 2B". | If one takes Vadim's argument to the extreme, he | should eliminate passwords internally since he | has adequate protection, trusts everyone | internally, and plan 9 is just a toy system. | We ran that way ourselves for years | (till management started using Plan 9 and wanted | something better to keep us from seeing | their secret stuff). Lots of things about the system, and unix before it, reflect this mode of development. Consider file permissions: user/group/other is adequate in uncomplicated circumstances, but in the typical university setting access control lists would make life much easier, particularly because the people you trust with particular files or directories varies so much and so dynamically. Also, there's a difference between any-user and unauthenticated-person that user none doesn't seem to capture. Shipping the system with telnetd allowing "none" to log in from anywhere strikes me as a mistake. Allowing anonymous 9p connections is worrysome too. AFS does better, since it lets you restrict what unauthenticated users are allowed to look at (easy with ACLs). | Out biggest fear is that this pressure will make | passwords a default mechanism. We'ld rather see | people working on getting Unix and DOS to use | better security or making Plan 9 security | tighter like adding expontial key exchange than | to add options to Plan 9 to make it less secure. | Just the ability to do passwords in the clear is | the first step down a very steep slope. Climbing | back up again is real hard. We have a chance for | a system that never goes that route, why blow it. I very strongly agree with this. In the unix world most people (and vendors) aggressively avoid kerberos, s/key, and other things that would improve our lives. Plan 9 is a rare and valuable example of doing things better and easier. When I show it off to visitors I always point that out. >From 9fans-outgoing-owner Fri Aug 18 20:11:27 1995 Received: by colossus.cse.psu.edu id <46304>; Fri, 18 Aug 1995 19:58:48 -0400 Received: from postman.ncube.com ([134.242.8.47]) by colossus.cse.psu.edu with SMTP id <46309>; Fri, 18 Aug 1995 19:55:48 -0400 Received: from butler.ncube.com by postman.ncube.com (4.1/SMI-4.1) id AA05730; Fri, 18 Aug 95 16:51:26 PDT Received: from skynet.ncube.com by butler.ncube.com (5.0/SMI-SVR4) id AA11791; Fri, 18 Aug 1995 16:51:22 +0800 Date: Fri, 18 Aug 1995 04:51:22 -0400 From: avg@postman.ncube.com (Vadim Antonov) Message-Id: <9508182351.AA11791@butler.ncube.com> To: 9fans Subject: Re: religious wars Content-Length: 1560 Sender: owner-9fans Precedence: bulk Reply-To: 9fans Well, i'm not against better security -- as long as it can be tuned to fit the requirements. Note that the option i added *is not on by default*. Let me reiterate that the security level should be adequate in regard to the value of information. By not providing the low security you effectively eliminate the whole class of applications for the system. "What? Give securenet keys to all people who want to log into the xxx account? I don't even know them!" BTW, i appreciated the joke about managenment not wanting you (designers of the system) to see their information :) The session stealing attacks do not have to be easily identifyable, and in fact they are already happening, as the knowledge is becoming more common. Also, while the "passive snooper" is a nice theoretical model in data world all passive snoopers have capability for active interference by definition. One-time passwords are a mere deterrent, not the system a determined hacker can't break. Cleartext passwords are also a deterrent. I may choose not to protect the system at all and use the police as a deterrent. Please don't force the choice of security level down the system administrators' throats. They know the local circumstances better. In our village doors are left open more often than in yours :) It is not a "religion", it is a common sense. I saw too many misguided efforts to improve security by making it hard to use, to the net result that everybody simply ignores the procedures. Ah, those proverbial holes in fences of top-secret installations. --vadim >From 9fans-outgoing-owner Fri Aug 18 20:29:24 1995 Received: by colossus.cse.psu.edu id <46318>; Fri, 18 Aug 1995 20:18:26 -0400 Received: from ncrhub1.ATTGIS.COM ([192.127.251.16]) by colossus.cse.psu.edu with SMTP id <46322>; Fri, 18 Aug 1995 20:13:29 -0400 Received: from ncrgw1 by ncrhub1.ATTGIS.COM id aa22165; 18 Aug 95 20:00 EDT Received: by ncrgw1.ATTGIS.COM; 18 Aug 95 19:56:47 EDT Received: by ncrhub4.ATTGIS.COM; 18 Aug 95 19:56:38 EDT Received: by ncrlnk.DaytonOH.NCR.COM; 18 Aug 95 19:55:22 EDT Date: Fri, 18 Aug 1995 21:58:19 -0400 From: MAILER-DAEMON@iss.southafrica.NCR.COM Full-Name: Mail Router (smail 2.8.1 dl,da,fa,tu,po,qf,dbm 04/16/92 1) Subject: Returned mail To: 9fans Message-ID: <9508182000.aa22165@ncrhub1.ATTGIS.COM> Sender: owner-9fans Precedence: bulk Reply-To: 9fans Your mail could not be delivered because of the following reason: ----- Transcript of session follows ----- Executing: /usr/lib/mail/surrcmd/smtpqer -B -C -u iss.SouthAfrica.NCR.COM!ncrlnk!ncrhub4!ncrgw1!cse.psu.edu!9fans capetown.SouthAfrica.ATTGIS.COM lynna@capetown.SouthAfrica.ATTGIS.COM smtpqer: Binary contents cannot be sent via SMTP server "/usr/lib/mail/surrcmd/smtpqer" failed - unknown mailer error 1 ----- Unsent message follows ----- >From ncrhub4!ncrgw1!cse.psu.edu!9fans Fri Aug 18 19:11 EDT 1995 remote from ncrlnk Received: by ncrlnk.DaytonOH.NCR.COM; 18 Aug 95 19:11:13 EDT Received: by ncrhub4.ATTGIS.COM; 18 Aug 95 19:11:54 EDT Received: by ncrgw1.ATTGIS.COM; 18 Aug 95 19:09:10 EDT Received: by colossus.cse.psu.edu id <46305>; Fri, 18 Aug 1995 18:51:41 -0400 Received: from galapagos.cse.psu.edu ([130.203.2.12]) by colossus.cse.psu.edu with SMTP id <46302>; Fri, 18 Aug 1995 18:51:25 -0400 Received: from localhost by galapagos.cse.psu.edu with SMTP id <12776>; Fri, 18 Aug 1995 18:51:28 -0400 To: 9fans@cse.psu.edu Subject: Re: religious wars In-reply-to: Your message of "Fri, 18 Aug 1995 16:48:37 EDT." <95Aug18.170312edt.46305@colossus.cse.psu.edu> Date: Fri, 18 Aug 1995 18:51:23 -0400 From: Scott Schwartz Message-Id: <95Aug18.185128edt.12776@galapagos.cse.psu.edu> Sender: owner-9fans@cse.psu.edu Precedence: bulk Reply-To: 9fans@cse.psu.edu I agree with most of what Dave wrote; here's my 2B". | If one takes Vadim's argument to the extreme, he | should eliminate passwords internally since he | has adequate protection, trusts everyone | internally, and plan 9 is just a toy system. | We ran that way ourselves for years | (till management started using Plan 9 and wanted | something better to keep us from seeing | their secret stuff). Lots of things about the system, and unix before it, reflect this mode of development. Consider file permissions: user/group/other is adequate in uncomplicated circumstances, but in the typical university setting access control lists would make life much easier, particularly because the people you trust with particular files or directories varies so much and so dynamically. Also, there's a difference between any-user and unauthenticated-person that user none doesn't seem to capture. Shipping the system with telnetd allowing "none" to log in from anywhere strikes me as a mistake. Allowing anonymous 9p connections is worrysome too. AFS does better, since it lets you restrict what unauthenticated users are allowed to look at (easy with ACLs). | Out biggest fear is that this pressure will make | passwords a default mechanism. We'ld rather see | people working on getting Unix and DOS to use | better security or making Plan 9 security | tighter like adding expontial key exchange than | to add options to Plan 9 to make it less secure. | Just the ability to do passwords in the clear is | the first step down a very steep slope. Climbing | back up again is real hard. We have a chance for | a system that never goes that route, why blow it. I very strongly agree with this. In the unix world most people (and vendors) aggressively avoid kerberos, s/key, and other things that would improve our lives. Plan 9 is a rare and valuable example of doing things better and easier. When I show it off to visitors I always point that out. >From 9fans-outgoing-owner Fri Aug 18 20:52:46 1995 Received: by colossus.cse.psu.edu id <46311>; Fri, 18 Aug 1995 20:41:24 -0400 Received: from postman.ncube.com ([134.242.8.47]) by colossus.cse.psu.edu with SMTP id <46317>; Fri, 18 Aug 1995 20:35:34 -0400 Received: from butler.ncube.com by postman.ncube.com (4.1/SMI-4.1) id AA06917; Fri, 18 Aug 95 17:34:27 PDT Received: from skynet.ncube.com by butler.ncube.com (5.0/SMI-SVR4) id AA11968; Fri, 18 Aug 1995 17:34:19 +0800 Date: Fri, 18 Aug 1995 05:34:19 -0400 From: avg@postman.ncube.com (Vadim Antonov) Message-Id: <9508190034.AA11968@butler.ncube.com> To: 9fans Subject: Set User (aka su) Content-Length: 1921 Sender: owner-9fans Precedence: bulk Reply-To: 9fans Hi -- there's an equivalent of Unix "su" for Plan9, to allow to become a different user temporarily. It uses the file /lib/namespace.su to remount the root file system under new user name. On a CPU server or terminal running kfs that should be naiad% cat /lib/namespace.su mount -bc /srv/kfs / naiad% Does anybody know a better way to tell the file system that user name has changed? Also, note the magic incantation "cd `{pwd}". God, if feels like the quote from ken/slp.c. --vadim naiad% pwd /sys/src/cmd/auth naiad% diff mkfile.old mkfile 16a17 > su\ 37a39,41 > > $BIN/su:V: $O.su > cp $O.su /$objtype/bin/su naiad% cat su.c #include #include #include #include "authsrv.h" void main(int argc, char *argv[]) { char buf[32], pass[32], key[DESKEYLEN]; int fd; Chalstate ch; char *s; if( argc != 2 ) { fprint(2, "usage: su user\n"); exits("usage"); } s = getenv("service"); if(s && strcmp(s, "cpu") == 0){ fprint(2, "su must not be run on the cpu server\n"); exits("boofhead"); } if(getchal(&ch, argv[1]) < 0) { fprint(2, "Authentication failure\n"); exits("can't get challenge"); } readln("Password: ", pass, sizeof pass, 1); passtokey(key, pass); strcpy(buf, ch.chal); netcrypt(key, buf); if( chalreply(&ch, buf) < 0 ) { fprint(2, "Authentication failed\n"); exits("bad response"); } rfork(RFNAMEG|RFENVG); if( (fd = create("#e/prompt", OWRITE, 0644)) >= 0 ) { snprint(buf, sizeof buf, "[%s]%% ", argv[1]); write(fd, buf, strlen(buf)); close(fd); } if( (fd = create("#e/user", OWRITE, 0644)) >= 0 ) { write(fd, argv[1], strlen(argv[1])); close(fd); } /* Do some magic and start interactive shell */ execl("/bin/rc", "rc", "-c", ". /lib/namespace.su; cd `{pwd}; exec /bin/rc -i", 0); fprint(2, "Exec failed\n"); exits("exec"); } naiad% >From 9fans-outgoing-owner Fri Aug 18 22:16:50 1995 Received: by colossus.cse.psu.edu id <45450>; Fri, 18 Aug 1995 22:06:37 -0400 Received: from clark.net ([168.143.0.7]) by colossus.cse.psu.edu with SMTP id <46323>; Fri, 18 Aug 1995 21:50:59 -0400 Received: (proberts@localhost) by clark.net (8.6.12/8.6.5) id VAA15585; Fri, 18 Aug 1995 21:27:43 -0400 Date: Fri, 18 Aug 1995 21:27:43 -0400 From: "Paul D. Robertson" To: 9fans Subject: Re: religious wars In-Reply-To: <95Aug18.143542pdt.34950@reynaldo.parc.xerox.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-9fans Precedence: bulk Reply-To: 9fans On Fri, 18 Aug 1995, Berry Kercheval wrote: > Indeed. THe only time I know that PARC got seriously hacked, the intruders > didn't come in through *our* firewall -- they got into Xerox somewhere else > and just rode the corporate net over here. > > We keep talking about a firewall between PARC and the rest of Xerox, but > managers frown on it for some reason :-) > I've been selling it as zoned security, and explaining that the multiple zones are to protect in layers. It's looking like a probably buy-in from my management. If I just said "I don't trust other operating units", they'd probably react like yours. Well, back to outer space.... > --berry > > Berry Kercheval :: Xerox Palo Alto Research Center > > > ----------------------------------------------------------------------------- Paul D. Robertson "My statements in this message are personal opinions proberts@clark.net which may have no basis whatsoever in fact." PSB#9280 >From 9fans-outgoing-owner Fri Aug 18 22:24:22 1995 Received: by colossus.cse.psu.edu id <46092>; Fri, 18 Aug 1995 22:16:05 -0400 Received: from staff.cs.su.OZ.AU ([129.78.8.1]) by colossus.cse.psu.edu with SMTP id <46021>; Wed, 16 Aug 1995 11:36:26 -0400 Received: from plan9.cs.su.oz.au by staff.cs.su.OZ.AU (mail from boyd for 9fans@cse.psu.edu) with MHSnet (insertion MHSnet site: staff.cs.su.oz.au); Wed, 16 Aug 1995 09:55:14 +1000 Received: from lore.plan9.cs.su.oz.au. by staff.cs.su.OZ.AU.; Wed, 16 Aug 1995 09:55:10 +1000 X-Claimed-Received: from plan9.cs.su.oz.au From: Boyd Roberts Date: Tue, 15 Aug 1995 19:38:56 -0400 To: 9fans Subject: Re: floppy boot on Pentium In-Reply-To: <9508151509.AA12807@garcon.ncube.com> Message-ID: <199508160938.4544.9.babiv@plan9.cs.su.oz.au> Sender: owner-9fans Precedence: bulk Reply-To: 9fans From: sch@postman.ncube.com (Steve Hemminger) Booting directly from floppy (like the 1st disk of the 4 disk set) does not work on our Pentium PC's when they are running at full speed. It gets part way through the load and fails with "premature EOF" (fails at different point every time). I had the same problem with just about all of our PC's here, until I got it to go on a laptop. So I thought: bugger it, I'll just copy it onto c: and make c: look enough like the floppy to boot it. However I did stumble across the problem that DOS reckons 'aux' is a device, like prn: or lpt1: -- gag. Copy /bin/aux/* with plan9. >From 9fans-outgoing-owner Fri Aug 18 22:36:04 1995 Received: by colossus.cse.psu.edu id <46132>; Fri, 18 Aug 1995 22:23:57 -0400 Received: from cegelecproj.co.uk ([159.245.72.6]) by colossus.cse.psu.edu with SMTP id <46196>; Wed, 16 Aug 1995 11:07:19 -0400 Received: from vampire.cegelecproj.co.uk (cerberus.cegelecproj.co.uk) by cegelecproj.co.uk (4.1/SMI-4.1) id AA21018; Wed, 16 Aug 95 15:48:31 BST Received: from phantom.cegelecproj.co.uk (phantom.limbo.cegelecproj.co.uk) by vampire.cegelecproj.co.uk (5.0/SMI-SVR4) id AA16089; Wed, 16 Aug 1995 15:48:19 +0100 Received: from phantom (localhost) by phantom.cegelecproj.co.uk (5.0/SMI-SVR4) id AA14551; Wed, 16 Aug 1995 15:48:15 +0100 Message-Id: <9508161448.AA14551@phantom.cegelecproj.co.uk> X-Mailer: exmh version 1.6.1 5/23/95 To: 9fans Subject: Re: HELP WANTED----plan9 overwrote linux partition In-Reply-To: Your message of "Tue, 15 Aug 1995 12:52:00 EDT." X-Face: Iqsa(US9p?)Y^W+6Ff[Z]rM"uFE) lFDjag1e]\/#2 X-Planation: X-Faces can be viewed with Faces from cs.indiana.edu. Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 16 Aug 1995 10:48:14 -0400 From: Steve_Kilbane Content-Length: 748 Sender: owner-9fans Precedence: bulk Reply-To: 9fans Bill Hogan writes: > "Installation from diskettes works correctly only on systems with a > single DOS partition. On systems with multiple partitions, Plan 9 will > install over the second through last partitions." > > it is only with the benefit of hindsight [..] > that I can discern [...] that Plan 9 will > *DESTROY* my second through the last partitions [...] At the risk of being unhelpful, that was what I assumed it meant. > Believe me, if plan9 wiped out every partition after the first one > on my C: drive, and every partition on each of my three remaining > drives, the internet would never hear the end of it. In which case, stay the hell away from Plan 9. When you've got the support contract, then you can whinge. steve >From 9fans-outgoing-owner Fri Aug 18 22:46:08 1995 Received: by colossus.cse.psu.edu id <46140>; Fri, 18 Aug 1995 22:35:17 -0400 Received: from cegelecproj.co.uk ([159.245.72.6]) by colossus.cse.psu.edu with SMTP id <46193>; Wed, 16 Aug 1995 11:04:08 -0400 Received: from vampire.cegelecproj.co.uk (cerberus.cegelecproj.co.uk) by cegelecproj.co.uk (4.1/SMI-4.1) id AA20947; Wed, 16 Aug 95 15:43:05 BST Received: from phantom.cegelecproj.co.uk (phantom.limbo.cegelecproj.co.uk) by vampire.cegelecproj.co.uk (5.0/SMI-SVR4) id AA16017; Wed, 16 Aug 1995 15:42:59 +0100 Received: from phantom (localhost) by phantom.cegelecproj.co.uk (5.0/SMI-SVR4) id AA14342; Wed, 16 Aug 1995 15:42:55 +0100 Message-Id: <9508161442.AA14342@phantom.cegelecproj.co.uk> X-Mailer: exmh version 1.6.1 5/23/95 To: 9fans Subject: Re: [comp.os.linux.misc] Help wanted, Plan9 a piece of junk! In-Reply-To: Your message of "Tue, 15 Aug 1995 21:12:38 EDT." <95Aug16.092715edt.33971@psuvax1.cse.psu.edu> X-Face: Iqsa(US9p?)Y^W+6Ff[Z]rM"uFE) lFDjag1e]\/#2 X-Planation: X-Faces can be viewed with Faces from cs.indiana.edu. Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 16 Aug 1995 10:42:55 -0400 From: Steve_Kilbane Content-Length: 1878 Sender: owner-9fans Precedence: bulk Reply-To: 9fans forsyth writes: > anyhow, i expect in consequence to see lots of articles about Plan 9 in > the local computing press! Possibly, which is a shame, because I get the impression that the Plan 9 release is an attempt to get back to the early days of UNIX, with all that that entailed: You want a copy? Here's a dump of our system; it's up to you to figure out how to get it going at your end. Personally, I can't complain about how things are. Plan 9 is supposed to be unsupported, but you can't deny that the plan9.att.com folks have been helpful on this list. There appear to be two basic mistakes, here: - the 4-disk installation seems to cope for most people, but in some cases, it's out of its depth, and causes damage. Personally, I was surprised that so much effort had been put into the PC installation arrangement in the first place. Perhaps the PC program should have asked for more confirmation? - people still aren't backing up their disks. I know it's not much comfort to say things like this when folks have just trashed months of work, but to be honest, this is often the only way that many people learn. In my case, I *removed* the disk from the machine; no way was I going to risk losing data, just because the software did something I didn't expect. I'm probably not expressing my point too well here, but what the hell. Think of Plan 9 as an Alpha, because that's near enough the case. Remember early versions of, oh, Mosaic or Netscape? Crashes all over the place. Well, this is a similar situation, except Plan 9 is an OS, and when an OS goes down, well, you'd just better have done your backups. If this sounds negative, sorry. It's not supposed to be. I just get a bit annoyed when people start treating all software as the same. Plan 9 != gcc != Microsoft Word, so don't expect them to have similar attributes. steve, somewhat incoherent >From 9fans-outgoing-owner Fri Aug 18 22:54:51 1995 Received: by colossus.cse.psu.edu id <46332>; Fri, 18 Aug 1995 22:46:36 -0400 Received: from clark.net ([168.143.0.7]) by colossus.cse.psu.edu with SMTP id <46330>; Fri, 18 Aug 1995 21:33:25 -0400 Received: (proberts@localhost) by clark.net (8.6.12/8.6.5) id VAA14268; Fri, 18 Aug 1995 21:23:11 -0400 Date: Fri, 18 Aug 1995 21:23:10 -0400 From: "Paul D. Robertson" To: 9fans Subject: Re: passwords in the clear In-Reply-To: <9508181902.AA10427@butler.ncube.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-9fans Precedence: bulk Reply-To: 9fans On Fri, 18 Aug 1995, Vadim Antonov wrote: [snip] > Been there, done that. The only way to defeat snoopers on > Ethernet is to encrypt all data or to use filtering bridges, > or to use good application-level gateway and not bother with > protection from insiders (which you never can do anyway... as > an insider can always stick a floppy in your machine and > voila! all data is his). > You forgot switching hubs, which negate the whole sniffing/snooping/spoofing problem (If someone substitues a host, you've got more problems than network security will handle). If for no other reason, this is why some of us just can't wait for ATM all over the friggin place :) Paul. ----------------------------------------------------------------------------- Paul D. Robertson "My statements in this message are personal opinions proberts@clark.net which may have no basis whatsoever in fact." PSB#9280 >From 9fans-outgoing-owner Fri Aug 18 23:13:53 1995 Received: by colossus.cse.psu.edu id <45470>; Fri, 18 Aug 1995 23:05:37 -0400 Received: from blah.math.tu-graz.ac.at ([129.27.150.3]) by colossus.cse.psu.edu with SMTP id <46126>; Fri, 18 Aug 1995 22:23:56 -0400 Received: from blah.math.tu-graz.ac.at (bri@localhost [127.0.0.1]) by blah.math.tu-graz.ac.at (8.6.12/8.6.12) with ESMTP id RAA08709 for <9fans@cse.psu.edu>; Wed, 16 Aug 1995 17:36:27 +0200 Message-Id: <199508161536.RAA08709@blah.math.tu-graz.ac.at> To: 9fans Subject: Re: Help wanted, Plan9 a piece of junk! In-reply-to: jmk's message of Tue, 15 Aug 1995 22:34:46 -0400. <95Aug16.093556edt.33963@psuvax1.cse.psu.edu> Date: Wed, 16 Aug 1995 11:36:26 -0400 From: Brian Ward Sender: owner-9fans Precedence: bulk Reply-To: 9fans jmk writes: |I took a look in comp.os.linux.misc and felt right at home - there were |articles about weird hangs trying to install distributions, hardware not |being recognised, mice not being found, filesystems being trashed (NOT |related to Plan 9), etc. Welcome to the PC world. :-) Seriously, though, the "plan 9 install way" of picking out what "partition" it wants to use on the disk leaves a lot to be desired, especially when you've got other operating systems on the disk. That you can't use a DOS partition that's not the first partition on the disk to install it is a bug (well, I consider that you need DOS in the first place to be a bug, but it's worth putting up with for now), and so is that it seems to want to use everything at the first "empty space" on the disk. This could seemingly all be solved by just teaching prep to know about regular PC partitions and have the install program ask which partition to install onto. However, I don't have any sympathy for anyone who tries to install an operating system on their computer without making backups. >From 9fans-outgoing-owner Sat Aug 19 00:01:23 1995 Received: by colossus.cse.psu.edu id <45464>; Fri, 18 Aug 1995 23:52:29 -0400 Received: from noao.edu ([140.252.1.54]) by colossus.cse.psu.edu with SMTP id <45486>; Fri, 18 Aug 1995 23:30:00 -0400 Received: from gemini.tuc.noao.edu by noao.edu (4.1/SAG-Noao.G102) id AA07739; Fri, 18 Aug 95 20:13:36 MST; for 9fans@cse.psu.edu Received: from daikon.tuc.noao.edu.noao by gemini.tuc.noao.edu (4.1/SAG.sat.14) id AA28347; Fri, 18 Aug 95 20:13:37 MST; for 9fans@cse.psu.edu Received: by daikon.tuc.noao.edu.noao (4.1/SAG.sun.8) id AA06748; Fri, 18 Aug 95 20:13:36 MST; for 9fans@cse.psu.edu Date: Fri, 18 Aug 1995 23:13:36 -0400 From: rwolff@noao.edu (Richard Wolff) Message-Id: <9508190313.AA06748@daikon.tuc.noao.edu.noao> To: 9fans Subject: attaching the cdrom Sender: owner-9fans Precedence: bulk Reply-To: 9fans Harcourt-Brace delivered today and I now have a cdrom sitting in my mitsumi drive (on a Gateway). I can't do the full cdrom install because I only have about 250 MB available for plan9 (I know, there's a relatively cheap, and certainly easy, fix to that). So I thought I'd copy some of what I want off the drive onto the hard disk. That requires running 9660srv and doing a bind and mount. According to cdrom(3), the bind is bind -a '#m' /dev but typing that in produces the error message "unknown device in # filesystem". A hint would be appreciated. Richard >From 9fans-outgoing-owner Sat Aug 19 00:51:20 1995 Received: by colossus.cse.psu.edu id <45508>; Sat, 19 Aug 1995 00:41:59 -0400 Received: from minster.cs.york.ac.uk ([144.32.16.26]) by colossus.cse.psu.edu with SMTP id <45472>; Sat, 19 Aug 1995 00:34:16 -0400 From: pete@minster.york.ac.uk Date: Sat, 19 Aug 1995 01:03:41 -0400 Message-ID: To: 9fans Subject: Re: [comp.os.linux.misc] Help wanted, Plan9 a piece of junk! Sender: owner-9fans Precedence: bulk Reply-To: 9fans The irony here is that the current plan9 release is doing precisely the things Linux was doing back in the 0.11/0.12 days.... yet people seem to expect some magically reliable piece of software. pete (sitting there looking at a pile of diskettes and a nice empty IDE drive, and considering making the plunge tomorrow afternoon!) >From 9fans-outgoing-owner Sat Aug 19 01:27:53 1995 Received: by colossus.cse.psu.edu id <45517>; Sat, 19 Aug 1995 01:19:31 -0400 Received: from plan9.att.com ([192.20.225.252]) by colossus.cse.psu.edu with SMTP id <45478>; Sat, 19 Aug 1995 01:11:50 -0400 Date: Sat, 19 Aug 1995 01:05:52 -0400 To: 9fans From: dmr@plan9.att.com (Dennis Ritchie) Subject: distribution of changes Message-Id: <95Aug19.011150edt.45478@colossus.cse.psu.edu> Sender: owner-9fans Precedence: bulk Reply-To: 9fans The question arises Since we are bound by the licence not to distribute modified versions of THE SOFTWARE to anyone without a licence, do we have a plan by which we can authenticate licensees? It would be reasonable to assume for practical purposes that anyone who goes to the trouble of subscribing to 9fans is either a licensee or a member of an organization that has a licensee (I'm proud that I sneaked that clause into the shrink-wrap). Anyone can get the entire authentic source for $350. I'm quite certain that quoting fragments of it on a mailing list, or archiving repaired versions of things on an FTP site, is unlikely to be objectionable until the quantity grows to a level at which Plan 9 can be reconstructed more cheaply by seining out its source from the list--that is, the point at which demonstrable harm begins to exist. If that happens, expect mail from us asking you to stop, please; also expect mailbombs from 9fans readers who already have the system and don't want to find another copy in their mailboxes. Dennis >From 9fans-outgoing-owner Sat Aug 19 03:43:32 1995 Received: by colossus.cse.psu.edu id <45478>; Sat, 19 Aug 1995 03:37:02 -0400 Received: from plan9.att.com ([192.20.225.252]) by colossus.cse.psu.edu with SMTP id <46356>; Sat, 19 Aug 1995 03:32:40 -0400 From: rob@plan9.att.com To: 9fans Date: Sat, 19 Aug 1995 03:25:03 -0400 Subject: Re: Set User (aka su) Message-Id: <95Aug19.033240edt.46356@colossus.cse.psu.edu> Sender: owner-9fans Precedence: bulk Reply-To: 9fans Vadim, it's not Unix. It's not supposed to be. -rob >From 9fans-outgoing-owner Sat Aug 19 06:07:24 1995 Received: by colossus.cse.psu.edu id <45530>; Sat, 19 Aug 1995 05:59:30 -0400 Received: from plan9.cs.york.ac.uk ([144.32.33.120]) by colossus.cse.psu.edu with SMTP id <45528>; Sat, 19 Aug 1995 05:59:14 -0400 From: forsyth@plan9.cs.york.ac.uk To: 9fans Date: Sat, 19 Aug 1995 06:01:54 -0400 Subject: re: distribution of changes Message-Id: <95Aug19.055914edt.45528@colossus.cse.psu.edu> Sender: owner-9fans Precedence: bulk Reply-To: 9fans >>a member of an organization that has a licensee (I'm proud that >>I sneaked that clause into the shrink-wrap). that explains it. i thought that clause was stunning. thanks very much! >From 9fans-outgoing-owner Sat Aug 19 09:46:44 1995 Received: by colossus.cse.psu.edu id <46192>; Sat, 19 Aug 1995 09:36:15 -0400 Received: from plan9.cs.york.ac.uk ([144.32.33.120]) by colossus.cse.psu.edu with SMTP id <45529>; Sat, 19 Aug 1995 09:35:59 -0400 From: forsyth@plan9.cs.york.ac.uk To: 9fans Date: Sat, 19 Aug 1995 09:32:36 -0400 Subject: Re: [comp.os.linux.misc] Help wanted, Plan9 a piece of junk! Message-Id: <95Aug19.093559edt.45529@colossus.cse.psu.edu> Sender: owner-9fans Precedence: bulk Reply-To: 9fans several people have commented on the reliability of the system. it is wrong to conclude from installation problems (or even some operational problems on the PC) that plan 9 is an `alpha' or `early version' of something, and that it is unsurprising to have it fail regularly. once installed on (or adapted to) a particular hardware configuration, most of the software that is running is software with a good few years behind it. the bulk of the code is portable code that has run on many different platforms, not just the PC. it certainly is not error free, but it is far better than `alpha' or `beta' quality. of course, there are newer, more experimental parts, that are less well tried, but as in the original Unix systems, the documentation is forthright about potential problems and limitations. as one example, see the health warnings in the documentation for Mothra and the Panel library on which it is built. nevertheless, i've been using the Panel library in a program i'm building and i regret to say that the errors have been in my code, not td's. (it is a very nice package, by the way.) in general, compared to most other systems i know, there is typically several orders of magnitude less source code to do more work (and more interesting work at that), and consequently there is less space for the bugs to hide. you really do have to read the documentation, though. if you approach the system with too many preconceptions about what it `obviously' will do, it will trip you up. in particular, the PC is just a hardware platform on which Plan 9 runs. it isn't the system's primary platform (it hasn't got one!). Plan 9 has its own conventions that it adheres to on *all hardware platforms*. this is a strength, not a weakness. as someone operating a plan 9 installation, i can tell you from experience that it is a real joy to have something that is so plug compatible in its interfaces and details of management that i can once again regard sparcs, 680x0 boxes, PCs, etc. as just a source of faster (or slower) computing power. >From 9fans-outgoing-owner Sat Aug 19 13:16:07 1995 Received: by colossus.cse.psu.edu id <46366>; Sat, 19 Aug 1995 13:05:35 -0400 Received: from mail.Germany.EU.net ([192.76.144.65]) by colossus.cse.psu.edu with SMTP id <46339>; Sat, 19 Aug 1995 13:05:18 -0400 Received: by mail.Germany.EU.net with UUCP (5.51:31/EUnetD-2.5.2.a) via EUnet id TAA25996; Sat, 19 Aug 1995 19:07:18 +0200 Received: from mwtech by shakti.rent-a-guru.de with UUCP (5.65+/MIKROS-5.0) id AA08211; Sat, 19 Aug 95 18:09:31 +0200 Received: by mwtech.rent-a-guru.de (5.65+/MIKROS-5.0) id AA01645; Sat, 19 Aug 95 15:45:48 GMT From: Martin Weitzel Message-Id: <9508191545.AA01645@mwtech.rent-a-guru.de> Subject: Re: Help wanted, Plan9 a piece of junk! To: 9fans Date: Sat, 19 Aug 1995 11:45:47 -0400 In-Reply-To: <199508161536.RAA08709@blah.math.tu-graz.ac.at> from "Brian Ward" at Aug 16, 95 11:36:26 am X-Mailer: ELM [version 2.4 PL20] Content-Type: text Content-Length: 1135 Sender: owner-9fans Precedence: bulk Reply-To: 9fans My $0.02: If you just want to play a around with the free Plan 9 floppies, get a fresh hard drive. Plan 9 is demanding very little. Considering that several hundred MB cost no more than a few hundred bucks, many people upgrade their hardware, so it should be easy to acquire an old 20 or 40 MB drive for nearly nothing. If you have a serious interrest in Plan 9, especially if you want to install the CD-ROM version with full source, you probably need a fresh hard disk anyway. Using a 1 GB drive with one half for Plan 9, the other half for your "serious work" will cost about the same as two drives of half the size. I'd choose the latter alternative. Years ago I equipped my PC with a unit called "Mobile Rack", which allows me to pull out the HD and replace it with another in less than a minute. The part you fix in the PC costs about $15, the part you need for each drive costs about the same, but IMHO it's worth the price: I have drives for my serious work, I have others to play with, and I've never had any headaches if more experimental ventures like installing an unknown OS could step on valuable data. --Martin >From 9fans-outgoing-owner Sat Aug 19 14:38:32 1995 Received: by colossus.cse.psu.edu id <46370>; Sat, 19 Aug 1995 14:27:29 -0400 Received: from postman.osf.org ([130.105.1.152]) by colossus.cse.psu.edu with SMTP id <46368>; Sat, 19 Aug 1995 14:25:15 -0400 Received: from sulphur.osf.org (sulphur.osf.org [130.105.1.123]) by postman.osf.org (8.6.9/8.6.x) with SMTP id OAA01027 for <9fans@cse.psu.edu>; Sat, 19 Aug 1995 14:24:17 -0400 From: Rich Salz Received: by sulphur.osf.org (1.38.193.4/4.7) id AA22552; Sat, 19 Aug 1995 14:24:04 -0400 Date: Sat, 19 Aug 1995 14:24:04 -0400 Message-Id: <9508191824.AA22552@sulphur.osf.org> To: 9fans Subject: Re: religious wars Sender: owner-9fans Precedence: bulk Reply-To: 9fans It is perhaps not unreasonable to allow site administrators to set up their own security model. It is stupid to have both a locked front door and an open back door on the same system. To the extent that Plan9 provides a practical demonstration that non-weak security isn't onerous in a distributed environment, that's a great thing. Viewed this way, adding cleartext network passwords is as useful as peeing in the petri dish. /r$, pike wannabe >From 9fans-outgoing-owner Sat Aug 19 17:24:41 1995 Received: by colossus.cse.psu.edu id <46367>; Sat, 19 Aug 1995 16:34:31 -0400 Received: from desiree.teleport.com ([192.108.254.11]) by colossus.cse.psu.edu with SMTP id <46374>; Sat, 19 Aug 1995 16:32:17 -0400 Received: from teleport.com (ip-pdx1-45.teleport.com [204.119.60.45]) by desiree.teleport.com (8.6.10/8.6.9) with ESMTP id NAA23613 for <9fans@cse.psu.edu>; Sat, 19 Aug 1995 13:32:23 -0700 Message-Id: <199508192032.NAA23613@desiree.teleport.com> To: 9fans Subject: Re: distribution of changes In-reply-to: Your message of Sat, 19 Aug 1995 01:05:52 EDT. <95Aug19.011150edt.45478@colossus.cse.psu.edu> Date: Sat, 19 Aug 1995 16:27:29 -0400 From: Felix Lee Sender: owner-9fans Precedence: bulk Reply-To: 9fans Dennis Ritchie: > It would be reasonable to assume for practical purposes that anyone > who goes to the trouble of subscribing to 9fans is either a licensee or > a member of an organization that has a licensee (I'm proud that > I sneaked that clause into the shrink-wrap). cute. but at the moment, I'm neither, and probably not going to find a spare $350 (plus $ for a disk drive, etc.) in the immediate future. well, can I claim that I'm a member of an organization called the USA? but there's probably a legal definition of "organization" that precludes this.. -- >From 9fans-outgoing-owner Sun Aug 20 02:24:22 1995 Received: by colossus.cse.psu.edu id <46372>; Sun, 20 Aug 1995 01:38:42 -0400 Received: from plan9.att.com ([192.20.225.252]) by colossus.cse.psu.edu with SMTP id <46381>; Sun, 20 Aug 1995 00:59:26 -0400 From: jmk@plan9.att.com To: 9fans Date: Sun, 20 Aug 1995 00:09:29 -0400 Subject: format for source diffs Message-Id: <95Aug20.005926edt.46381@colossus.cse.psu.edu> Sender: owner-9fans Precedence: bulk Reply-To: 9fans I'd like to make the source changes for aux/vga available, what should the format be? The changes include new files as well as diffs. I was thinking of a bundle containing the new files plus one file containing the output from diff /n/juke/plan_9/sys/src/cmd/aux/vga /sys/src/cmd/aux/vga (/n/juke/plan_9 contains the distribution cd). >From 9fans-outgoing-owner Sun Aug 20 10:35:07 1995 Received: by colossus.cse.psu.edu id <45565>; Sun, 20 Aug 1995 10:25:06 -0400 Received: from galapagos.cse.psu.edu ([130.203.2.12]) by colossus.cse.psu.edu with SMTP id <45561>; Sun, 20 Aug 1995 10:24:50 -0400 Received: from localhost by galapagos.cse.psu.edu with SMTP id <12684>; Sun, 20 Aug 1995 10:24:54 -0400 To: 9fans Subject: Re: format for source diffs In-reply-to: Your message of "Sun, 20 Aug 1995 00:09:29 EDT." <95Aug20.005926edt.46381@colossus.cse.psu.edu> Date: Sun, 20 Aug 1995 10:24:41 -0400 From: Scott Schwartz Message-Id: <95Aug20.102454edt.12684@galapagos.cse.psu.edu> Sender: owner-9fans Precedence: bulk Reply-To: 9fans jmk@plan9.att.com writes: | I'd like to make the source changes for aux/vga available, what should the | format be? The bundle plus diff would work, but it might be nice to take advantage of patch's functionality, since most people will be using it anyway and it can automatically create new files from context diffs built with -Nc or -Nu. That would require augmenting /bin/diff or porting gnu diff, of course. >From 9fans-outgoing-owner Sun Aug 20 13:42:38 1995 Received: by colossus.cse.psu.edu id <45509>; Sun, 20 Aug 1995 13:32:56 -0400 Received: from plan9.att.com ([192.20.225.252]) by colossus.cse.psu.edu with SMTP id <45450>; Sun, 20 Aug 1995 13:32:40 -0400 From: presotto@plan9.att.com To: 9fans Date: Sun, 20 Aug 1995 13:32:14 -0400 Subject: re: religous wars Message-Id: <95Aug20.133240edt.45450@colossus.cse.psu.edu> Sender: owner-9fans Precedence: bulk Reply-To: 9fans Vadim, You missed the point of the subject. I'm not accusing you of a religious war, we are the zealots here. We all recognize you for the voice of informed choice and common sense that you are. We just don't happen to subscribe to the common sense. We are on a jihad against it. >From 9fans-outgoing-owner Sun Aug 20 15:14:28 1995 Received: by colossus.cse.psu.edu id <45557>; Sun, 20 Aug 1995 15:07:40 -0400 Received: from hal ([192.102.161.37]) by colossus.cse.psu.edu with SMTP id <45553>; Sun, 20 Aug 1995 15:07:23 -0400 Received: from po.isst (po.do.isst.fhg.de [192.102.161.66]) by hal (8.6.9/8.6.9) with SMTP id VAA24522 for <9fans@cse.psu.edu>; Sun, 20 Aug 1995 21:10:54 +0200 Date: Sun, 20 Aug 1995 15:10:54 -0400 Message-Id: <199508201910.VAA24522@hal> Received: by po.isst (4.1/SMI-4.1) id AA26931; Sun, 20 Aug 95 21:10:42 +0200 From: Dirk Vleugels To: 9fans Subject: Re: format for source diffs In-Reply-To: <95Aug20.005926edt.46381@colossus.cse.psu.edu> References: <95Aug20.005926edt.46381@colossus.cse.psu.edu> Sender: owner-9fans Precedence: bulk Reply-To: 9fans Hello, >>>>> "jmk" == jmk writes: jmk> I'd like to make the source changes for aux/vga available, jmk> what should the format be? The changes include new files as jmk> well as diffs. I was thinking of a bundle containing the new jmk> files plus one file containing the output from diff jmk> /n/juke/plan_9/sys/src/cmd/aux/vga /sys/src/cmd/aux/vga jmk> (/n/juke/plan_9 contains the distribution cd). The right place for a few questions. I installed the pcdist last night and suceeded! I screwed my ide disk one time, but who cares for MS-* anyways (i also have a backup ;) As far as i can see, i like the system. The 8c is fast, giving great turn around times with writing and debugging. I'm only able to use 640x480x1. (my card is a Spea Mirage S3 with 868 chip and 2MB dram). Anyone know if i can patch the vgadb to work with this chip? In fact, my main question is: Does it make sense to put work in the attempt to work with the pcdist. It lacks the man pages, most binarys (as far as i can see) and (of course) the source. Is it possible to enhance the system by hand (get 386 binaries from the net &&| free sources?). I used 80MB for the installation with this thought in mind. Is the documentation available on the net? (maybe parts of it?) Thanx for any advice Dirk ps: ignore my lousy english spelling >From 9fans-outgoing-owner Sun Aug 20 17:58:25 1995 Received: by colossus.cse.psu.edu id <45558>; Sun, 20 Aug 1995 17:47:39 -0400 Received: from galapagos.cse.psu.edu ([130.203.2.12]) by colossus.cse.psu.edu with SMTP id <45561>; Sun, 20 Aug 1995 17:47:21 -0400 Received: by galapagos.cse.psu.edu id <12684>; Sun, 20 Aug 1995 17:45:22 -0400 From: Scott Schwartz To: 9fans Subject: keyfs/ishost Message-Id: <95Aug20.174522edt.12684@galapagos.cse.psu.edu> Date: Sun, 20 Aug 1995 17:45:12 -0400 Sender: owner-9fans Precedence: bulk Reply-To: 9fans The keyfs manpage mentions the ishost file. The current code doesn't provide that, though the old system did. >From 9fans-outgoing-owner Sun Aug 20 19:58:39 1995 Received: by colossus.cse.psu.edu id <45562>; Sun, 20 Aug 1995 19:52:21 -0400 Received: from plan9.att.com ([192.20.225.252]) by colossus.cse.psu.edu with SMTP id <45560>; Sun, 20 Aug 1995 19:52:05 -0400 From: presotto@plan9.att.com To: 9fans Date: Sun, 20 Aug 1995 19:48:02 -0400 Subject: re: keyfs/ishost Message-Id: <95Aug20.195205edt.45560@colossus.cse.psu.edu> Sender: owner-9fans Precedence: bulk Reply-To: 9fans right you are. yet another addendum to errata.html. ------ original message follows ------ >From cse.psu.edu!9fans-outgoing-owner Sun Aug 20 18:01:00 EDT 1995 Received: by colossus.cse.psu.edu id <45558>; Sun, 20 Aug 1995 17:47:39 -0400 Received: from galapagos.cse.psu.edu ([130.203.2.12]) by colossus.cse.psu.edu with SMTP id <45561>; Sun, 20 Aug 1995 17:47:21 -0400 Received: by galapagos.cse.psu.edu id <12684>; Sun, 20 Aug 1995 17:45:22 -0400 From: Scott Schwartz To: 9fans@cse.psu.edu Subject: keyfs/ishost Message-Id: <95Aug20.174522edt.12684@galapagos.cse.psu.edu> Date: Sun, 20 Aug 1995 17:45:12 -0400 Sender: owner-9fans@cse.psu.edu Precedence: bulk Reply-To: 9fans@cse.psu.edu The keyfs manpage mentions the ishost file. The current code doesn't provide that, though the old system did. >From 9fans-outgoing-owner Sun Aug 20 23:39:52 1995 Received: by colossus.cse.psu.edu id <45560>; Sun, 20 Aug 1995 23:32:53 -0400 Received: from plan9.att.com ([192.20.225.252]) by colossus.cse.psu.edu with SMTP id <45558>; Sun, 20 Aug 1995 23:32:37 -0400 From: jmk@plan9.att.com To: 9fans Date: Sun, 20 Aug 1995 23:26:27 -0400 Subject: Re: format for source diffs Message-Id: <95Aug20.233237edt.45558@colossus.cse.psu.edu> Sender: owner-9fans Precedence: bulk Reply-To: 9fans As far as i can see, i like the system. The 8c is fast, giving great turn around times with writing and debugging. I'm only able to use 640x480x1. (my card is a Spea Mirage S3 with 868 chip and 2MB dram). Anyone know if i can patch the vgadb to work with this chip? the 868 can be described in vgadb as a vision864. i don't know what the clock or ramdac is on that board. >From 9fans-outgoing-owner Sun Aug 20 23:46:34 1995 Received: by colossus.cse.psu.edu id <45558>; Sun, 20 Aug 1995 23:39:15 -0400 Received: from plan9.att.com ([192.20.225.252]) by colossus.cse.psu.edu with SMTP id <45557>; Sun, 20 Aug 1995 23:32:35 -0400 From: jmk@plan9.att.com To: 9fans Date: Sun, 20 Aug 1995 23:25:26 -0400 Subject: Re: format for source diffs Message-Id: <95Aug20.233235edt.45557@colossus.cse.psu.edu> Sender: owner-9fans Precedence: bulk Reply-To: 9fans i can't say i'm thrilled about either of those options. ------ original message follows ------ >From cse.psu.edu!9fans-outgoing-owner Sun Aug 20 10:35:54 EDT 1995 Received: by colossus.cse.psu.edu id <45565>; Sun, 20 Aug 1995 10:25:06 -0400 Received: from galapagos.cse.psu.edu ([130.203.2.12]) by colossus.cse.psu.edu with SMTP id <45561>; Sun, 20 Aug 1995 10:24:50 -0400 Received: from localhost by galapagos.cse.psu.edu with SMTP id <12684>; Sun, 20 Aug 1995 10:24:54 -0400 To: 9fans@cse.psu.edu Subject: Re: format for source diffs In-reply-to: Your message of "Sun, 20 Aug 1995 00:09:29 EDT." <95Aug20.005926edt.46381@colossus.cse.psu.edu> Date: Sun, 20 Aug 1995 10:24:41 -0400 From: Scott Schwartz Message-Id: <95Aug20.102454edt.12684@galapagos.cse.psu.edu> Sender: owner-9fans@cse.psu.edu Precedence: bulk Reply-To: 9fans@cse.psu.edu jmk@plan9.att.com writes: | I'd like to make the source changes for aux/vga available, what should the | format be? The bundle plus diff would work, but it might be nice to take advantage of patch's functionality, since most people will be using it anyway and it can automatically create new files from context diffs built with -Nc or -Nu. That would require augmenting /bin/diff or porting gnu diff, of course. >From 9fans-outgoing-owner Sun Aug 20 23:53:50 1995 Received: by colossus.cse.psu.edu id <45509>; Sun, 20 Aug 1995 23:47:06 -0400 Received: from plan9.att.com ([192.20.225.252]) by colossus.cse.psu.edu with SMTP id <45562>; Sun, 20 Aug 1995 23:46:03 -0400 From: jmk@plan9.att.com To: 9fans Date: Sun, 20 Aug 1995 23:31:50 -0400 Subject: more advice for the lovelorn Message-Id: <95Aug20.234603edt.45562@colossus.cse.psu.edu> Sender: owner-9fans Precedence: bulk Reply-To: 9fans ------ original message follows ------ >From jmk Sat Aug 19 23:59 EDT 1995 Path: alice!allegra!uhog.mit.edu!news.mathworks.com!newshost.marcam.com!usc!howland.reston.ans.net!news.sprintlink.net!sunic!sunic.sunet.se!news.uni-c.dk!tkemi.klb.dtu.dk!jjw From: jjw@tkemi.klb.dtu.dk (Joachim Wlodarz) Newsgroups: comp.os.linux.misc Subject: Re: Help wanted, Plan9 a piece of junk! Date: 18 Aug 1995 07:20:08 GMT Organization: News Server at UNI-C, Danish Computing Centre for Research and Education. Lines: 68 Message-ID: <411ev8$q4j@news.uni-c.dk> References: <40p6oe$q2t@paul.rutgers.edu> <40s0ao$6d3@nntp5.u.washington.edu> NNTP-Posting-Host: tkemi.klb.dtu.dk X-Newsreader: TIN [version 1.2 PL1] Mike Kenney (mike@wavelet.apl.washington.edu) wrote: : In article <40p6oe$q2t@paul.rutgers.edu>, Xiao Ke wrote: : Jeez. Doesn't anybody read installation notes anymore! I was just checking : out the Plan9 documentation the other day and it says plain as day that : the Plan9 PC installation assumes you have DOS *only* on your disk and that : it will overwrite the last 20Mb of your partition. There is also a note : in the "bugs" section concerning disks with multiple partitions. : READ THE INSTALLATION NOTES CAREFULLY BEFORE INSTALLING *ANY* SOFTWARE! : Now, with that off my chest ... Plan9 looks like a very interesting system. : If I can scrounge up a spare PC I plan to give it a try. Sure AT&T is : charging $350.00 for the full distribution but the include the source for : several architectures (i386, 68020, MIPS R4000, SPARC). There is a fixed partitioning program, named prep, available from AT&T (http://plan9.att.com/). This version will try not to overwrite everything except the primary DOS partition. The old version of prep (dated 95-05-19, size 22543) should be replaced with the new one (95-07-19, 22526). As the installation boot diskette is DOS formatted, it's easy to do (in directory a:\386\bin\disk\). It could be also done right after the first stage of installation, when the content of boot diskette has been transferred to the DOS partition, but BEFORE you boot Plan9 again (in directory C:\plan9\386\bin\disk\). I've tried it on my machine and it works OK. Plan9 is really a very interesting system. It would be even more interesting if a full PC distribution, including the sources, were available for free :-) The best thing to do before installing Plan9 is to check out how your HD looks to Plan9, and especially to the prep program, which writes the Plan9 partition table. It's quite easy: edit the file a:\rc\bin\cpurc and place a # at the beginning of the last line in the file (#exec /bin/install) to prevent the install program from loading. As the Plan9 Rc shell doesn't like CRLF-s, use an editor which do not introduce them (e.g. under Linux) or convert the file appropriately, if must do that under DOS. Then boot from this diskette. When Plan9 prompts for password, simply hit Enter. Then, at the Rc shell prompt (a % sign), type disk/prep -r /dev/hd0disk (or /dev/hd1disk) It will display the contents of your MBR partition table (it's named DOS partition table here) and the default Plan9 partition layout. Check out carefully the displayed partition tables for possible overlaps. Keep in mind that the Plan9 partition table resides on the LAST sector of the harddrive, and is independent from the MBR partition table residing in the FIRST physical sector. The -r switch should prevent prep from writing to the disk, but it will be always better not to play to much with this program and exit by Ctrl-Alt-Del. Actually, the real damage is not done by prep alone (it writes only the last sector), but by the kfs and mkext programs, which generate the Plan9 filesystem and populate it with files from the distribution set according to the Plan9 partition table. If everything looks fine, Plan9 should install without doing any damage to the existing partitions. Hope this helps, -jjw. >From 9fans-outgoing-owner Mon Aug 21 02:34:13 1995 Received: by psuvax1.cse.psu.edu id <34144>; Mon, 21 Aug 1995 02:12:45 -0400 Received: from plan9.cs.york.ac.uk ([144.32.33.120]) by psuvax1.cse.psu.edu with SMTP id <34139>; Mon, 21 Aug 1995 02:12:24 -0400 From: forsyth@plan9.cs.york.ac.uk To: 9fans@cs.psu.edu Date: Mon, 21 Aug 1995 02:15:56 -0400 subject: putative bug fix to ape's strerror function Message-Id: <95Aug21.021224edt.34139@psuvax1.cse.psu.edu> Sender: owner-9fans Precedence: bulk Reply-To: 9fans ape's strerror function gibbered at me. it should return `Shut down' for ESHUTDOWN, not `Too many references'. i think this will fix it. % diff old/strerror.c /sys/src/ape/lib/ap/stdio/strerror.c 57a58 > "Protocol family not supported", cd /sys/src/ape/lib/ap mk S_strerror.all >From 9fans-outgoing-owner Mon Aug 21 04:13:12 1995 Received: by colossus.cse.psu.edu id <46374>; Mon, 21 Aug 1995 04:04:03 -0400 Received: from symbionics.co.uk ([158.43.6.17]) by colossus.cse.psu.edu with SMTP id <46377>; Mon, 21 Aug 1995 04:03:41 -0400 Received: from sympc143 ([194.32.100.46]) by symbionics.co.uk (4.1/SMI-4.1) id AA06808; Mon, 21 Aug 95 09:03:21 BST Message-Id: <9508210803.AA06808@symbionics.co.uk> Comments: Authenticated sender is From: "Nigel Roles" Organization: Symbionics Communications To: 9fans Date: Mon, 21 Aug 1995 05:03:19 -0400 Subject: pppclient Priority: normal X-Mailer: Pegasus Mail for Windows (v2.01) Sender: owner-9fans Precedence: bulk Reply-To: 9fans Following Boyd's problems with pppclient, I had a different problem. My pppserver (demon internet) wants to do (2d 15 1) compression which is fine. What nadgers it is that pppclient then negotiates for VJ TCP compression and IL compression. Demon's pppserver hasn't heard of IL compression (can't blame it) so sends Configure NAK. I think I then hit the same problem as Boyd in that pppclient keeps trying the same Configure Request and getting Configure NAK until the server starts saying Configure REJ (presumably out of frustration). The fix is simple. Delete the IL compression request. It was simpler than trying to implement Configure Req backoff. Then I get the connectiion up. What I haven't figured yet is what else to do to actually get the packets sent up the ppp link..... >From 9fans-outgoing-owner Mon Aug 21 06:05:23 1995 Received: by colossus.cse.psu.edu id <45634>; Mon, 21 Aug 1995 05:52:48 -0400 Received: from symbionics.co.uk ([158.43.6.17]) by colossus.cse.psu.edu with SMTP id <45633>; Mon, 21 Aug 1995 05:52:32 -0400 Received: from sympc143 ([194.32.100.46]) by symbionics.co.uk (4.1/SMI-4.1) id AA07397; Mon, 21 Aug 95 10:52:02 BST Message-Id: <9508210952.AA07397@symbionics.co.uk> Comments: Authenticated sender is From: "Nigel Roles" Organization: Symbionics Communications To: 9fans Date: Mon, 21 Aug 1995 06:52:00 -0400 Subject: Fun Priority: normal X-Mailer: Pegasus Mail for Windows (v2.01) Sender: owner-9fans Precedence: bulk Reply-To: 9fans Best $350 I ever spent (on software). I haven't had so much fun since 8th edition. Thanks, guys. >From 9fans-outgoing-owner Mon Aug 21 06:23:10 1995 Received: by colossus.cse.psu.edu id <45638>; Mon, 21 Aug 1995 06:10:42 -0400 Received: from faui45.informatik.uni-erlangen.de ([131.188.2.45]) by colossus.cse.psu.edu with SMTP id <45637>; Mon, 21 Aug 1995 06:10:10 -0400 Received: from faui01.informatik.uni-erlangen.de (root@faui01.informatik.uni-erlangen.de [131.188.2.1]) by uni-erlangen.de with SMTP id MAA20532 (8.6.12/7.4d-FAU); for <9fans%cse.psu.edu@faui45.UUCP>; Mon, 21 Aug 1995 12:10:19 +0200 Received: from faui04b.informatik.uni-erlangen.de by cip.informatik.uni-erlangen.de with SMTP; id AA22311 (5.65c-6/7.3m-FAU); Mon, 21 Aug 1995 12:10:17 +0200 From: "Markus Friedl (CIP Admin)" Message-Id: <199508211010.AA22311@faui01.informatik.uni-erlangen.de> Subject: SPEA Mirage (was: Re: format for source diffs) To: 9fans Date: Mon, 21 Aug 1995 06:10:16 -0400 In-Reply-To: <95Aug20.233237edt.45558@colossus.cse.psu.edu> from "jmk@plan9.att.com" at Aug 20, 95 11:26:27 pm X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 439 Sender: owner-9fans Precedence: bulk Reply-To: 9fans > (my card is a Spea Mirage S3 with 868 chip and 2MB dram). Anyone know if i > can patch the vgadb to work with this chip? > > the 868 can be described in vgadb as a vision864. i don't know what the clock > or ramdac is on that board. The SPEA MirageP64 (2MB DRAM) has a: - S3 86C716 SDAC RAMDAC and Clockchip (BIOS 4.xx) - 20C498 or 21C498 RAMDAC, ICS2595 Clockchip (BIOS 3.xx) (according to the X11R6/XFree3.1.2 documents) --markus >From 9fans-outgoing-owner Mon Aug 21 08:30:15 1995 Received: by colossus.cse.psu.edu id <45635>; Mon, 21 Aug 1995 08:16:47 -0400 Received: from hal ([192.102.161.37]) by colossus.cse.psu.edu with SMTP id <45633>; Mon, 21 Aug 1995 08:16:30 -0400 Received: from po.isst (po.do.isst.fhg.de [192.102.161.66]) by hal (8.6.9/8.6.9) with SMTP id OAA01564 for <9fans@cse.psu.edu>; Mon, 21 Aug 1995 14:20:34 +0200 Date: Mon, 21 Aug 1995 08:20:34 -0400 Message-Id: <199508211220.OAA01564@hal> Received: by po.isst (4.1/SMI-4.1) id AA29736; Mon, 21 Aug 95 14:20:16 +0200 From: Dirk Vleugels To: 9fans Subject: Re: format for source diffs In-Reply-To: <95Aug20.233237edt.45558@colossus.cse.psu.edu> References: <95Aug20.233237edt.45558@colossus.cse.psu.edu> Sender: owner-9fans Precedence: bulk Reply-To: 9fans >>>>> "jmk" == jmk writes: Hello, jmk> the 868 can be described in vgadb as a vision864. i don't jmk> know what the clock or ramdac is on that board. Markus.Friedl@informatik.uni-erlangen.de wrote: The SPEA MirageP64 (2MB DRAM) has a: - S3 86C716 SDAC RAMDAC and Clockchip (BIOS 4.xx) - 20C498 or 21C498 RAMDAC, ICS2595 Clockchip (BIOS 3.xx) (according to the X11R6/XFree3.1.2 documents) Now, how to use this informations? Is it possible to get this card working with the current pcdist? Thanx for any clue Dirk >From 9fans-outgoing-owner Mon Aug 21 09:05:02 1995 Received: by colossus.cse.psu.edu id <45633>; Mon, 21 Aug 1995 08:52:36 -0400 Received: from plan9.att.com ([192.20.225.252]) by colossus.cse.psu.edu with SMTP id <45638>; Mon, 21 Aug 1995 08:52:05 -0400 From: presotto@plan9.att.com To: 9fans Date: Mon, 21 Aug 1995 08:36:49 -0400 Subject: announce(2) Message-Id: <95Aug21.085205edt.45638@colossus.cse.psu.edu> Sender: owner-9fans Precedence: bulk Reply-To: 9fans postman.ncube.com!dlc (Dan Clark) noticed that announcing with a system name to UDP (or TCP) results in an error. When announcing on tcp and udp, use the sytem name '*' as in announce("udp!*!666, dir). Other networks like datakit allow you to specify a system name but not a port, ... He also noticed that udp channels have no listen. Part of this is because UDP isn't really a connection oriented protocol. However, given how we handle it anyways, that's no excuse. Listen would have worked. We just got lazy because we only use udp for a couple of things. >From 9fans-outgoing-owner Mon Aug 21 09:24:16 1995 Received: by psuvax1.cse.psu.edu id <34149>; Mon, 21 Aug 1995 08:56:04 -0400 Received: from plan9.cs.york.ac.uk ([144.32.33.120]) by psuvax1.cse.psu.edu with SMTP id <34147>; Mon, 21 Aug 1995 08:55:26 -0400 From: forsyth@plan9.cs.york.ac.uk To: 9fans@cs.psu.edu Date: Mon, 21 Aug 1995 08:54:44 -0400 subject: fix small glitch in tmac.pm Message-Id: <95Aug21.085526edt.34147@psuvax1.cse.psu.edu> Sender: owner-9fans Precedence: bulk Reply-To: 9fans troff runs on $cputype, not always the same as $objtype, hence: diff old/tmac.pm /sys/lib/tmac/tmac.pm 2c2 < .pi /$objtype/bin/aux/pm --- > .pi /$cputype/bin/aux/pm >From 9fans-outgoing-owner Mon Aug 21 11:04:39 1995 Received: by colossus.cse.psu.edu id <45651>; Mon, 21 Aug 1995 10:41:34 -0400 Received: from plan9.att.com ([192.20.225.252]) by colossus.cse.psu.edu with SMTP id <45642>; Mon, 21 Aug 1995 10:32:16 -0400 From: jmk@plan9.att.com To: 9fans Date: Mon, 21 Aug 1995 10:07:55 -0400 Subject: re: SPEA Mirage (was: Re: format for source diffs) Message-Id: <95Aug21.103216edt.45642@colossus.cse.psu.edu> Sender: owner-9fans Precedence: bulk Reply-To: 9fans > The SPEA MirageP64 (2MB DRAM) has a: > - S3 86C716 SDAC RAMDAC and Clockchip (BIOS 4.xx) > - 20C498 or 21C498/ICS2595 Clockchip (BIOS 3.xx) > (according to the X11R6/XFree3.1.2 documents) >From vgadb(6): ADDING A NEW VGA CONTROLLER While the use of this database formalizes the steps needed to program a VGA controller, unless you are very lucky and all the important components on a new VGA controller card are interconnected in the same way as an existing entry, adding a new entry requires adding new internal types to vga(8). At a minimum you will need the data sheets for the VGA con- troller chip, the RAMDAC and the clock generator. You will also need to know how these components interact. For exam- ple, a common combination is an S3 86C928 VGA chip with an ICD2061A clock generator. The ICD2061A is usually loaded by clocking a serial bit-stream out of one of the 86C928 regis- ters. Similarly, the RAMDAC may have an internal clock- doubler and/or pixel-multiplexing modes, in which case both the clock generator and VGA chip must be programmed accord- ingly. Neither of the SPEA Mirage variants above is completely described by the current aux/vga and database. I don't have a datasheet for the 86C716 but that would likely be the more stable of the to two try programming, there's obviously less room for maneuver connecting 2 chips together compared to 3 using the 21C498+ICS2595 combination. However, the 21C498 is already handled by aux/vga and the 2595 looks straightforward from the datasheet (although it's programmable, it has a default table which might suffice). >From 9fans-outgoing-owner Mon Aug 21 13:22:48 1995 Received: by colossus.cse.psu.edu id <45475>; Mon, 21 Aug 1995 13:08:55 -0400 Received: from mailhub.iastate.edu ([129.186.166.169]) by colossus.cse.psu.edu with SMTP id <45474>; Mon, 21 Aug 1995 13:08:39 -0400 Received: from math (pollux.math.iastate.edu [129.186.52.4]) by mailhub.iastate.edu (8.6.9/8.6.9) with SMTP id MAA05229 for <9fans@cse.psu.edu>; Mon, 21 Aug 1995 12:09:13 -0500 Received: from [129.186.52.48] (ca461a.math.iastate.edu) by math (4.1/SMI-4.1) id AA03160; Mon, 21 Aug 95 12:09:11 CDT From: "Mike Fletcher" Date: Mon, 21 Aug 1995 13:08:20 -0400 Message-Id: <43701.fletcher@pollux.math.iastate.edu> X-Popmail-Charset: English To: 9fans Subject: unsuuscribe Sender: owner-9fans Precedence: bulk Reply-To: 9fans unsubscribe >From 9fans-outgoing-owner Mon Aug 21 13:55:11 1995 Received: by colossus.cse.psu.edu id <45479>; Mon, 21 Aug 1995 13:41:39 -0400 Received: from weaver-gw.netapp.com ([198.95.224.2]) by colossus.cse.psu.edu with SMTP id <45482>; Mon, 21 Aug 1995 13:39:08 -0400 Received: from netapp.com ([192.9.200.1]) by weaver.netapp.com with SMTP id <15942>; Mon, 21 Aug 1995 10:36:44 +0100 Received: from nova.netapp.com by netapp.com (4.1/SMI-4.1) id AA04570; Mon, 21 Aug 95 10:39:31 PDT Received: by nova.netapp.com (4.1/SMI-4.1) id AA09500; Mon, 21 Aug 95 10:39:28 PDT Date: Mon, 21 Aug 1995 13:39:28 -0400 From: byron@netapp.com (Byron Rakitzis) Message-Id: <9508211739.AA09500@nova.netapp.com> To: 9fans Subject: SS standalone? Sender: owner-9fans Precedence: bulk Reply-To: 9fans I was wondering if it's possible to boot a sparcstation standalone. If not, what kind of work do I have to do to make it so? Byron. (I don't have the CDROM yet, but pointers to relevant online documentation are greatly appreciated; however, I have read "doc/port.html" and I think it is unclear about whether SPARC can be booted standalone) >From 9fans-outgoing-owner Mon Aug 21 15:35:52 1995 Received: by colossus.cse.psu.edu id <45501>; Mon, 21 Aug 1995 15:17:05 -0400 Received: from postman.ncube.com ([134.242.8.47]) by colossus.cse.psu.edu with SMTP id <45506>; Mon, 21 Aug 1995 15:12:34 -0400 Received: from butler.ncube.com by postman.ncube.com (4.1/SMI-4.1) id AA08345; Mon, 21 Aug 95 12:09:59 PDT Received: from skynet.ncube.com by butler.ncube.com (5.0/SMI-SVR4) id AA21982; Mon, 21 Aug 1995 12:09:55 +0800 Date: Mon, 21 Aug 1995 00:09:55 -0400 From: avg@postman.ncube.com (Vadim Antonov) Message-Id: <9508211909.AA21982@butler.ncube.com> To: 9fans Subject: Re: passwords in the clear Content-Length: 1196 Sender: owner-9fans Precedence: bulk Reply-To: 9fans "Filtering bridge" is the same as "switching hub". Terminology :) ATM is short for "Another Terrible Mistake" :) --vadim Date: Fri, 18 Aug 1995 21:23:10 -0400 From: "Paul D. Robertson" On Fri, 18 Aug 1995, Vadim Antonov wrote: [snip] > Been there, done that. The only way to defeat snoopers on > Ethernet is to encrypt all data or to use filtering bridges, > or to use good application-level gateway and not bother with > protection from insiders (which you never can do anyway... as > an insider can always stick a floppy in your machine and > voila! all data is his). > You forgot switching hubs, which negate the whole sniffing/snooping/spoofing problem (If someone substitues a host, you've got more problems than network security will handle). If for no other reason, this is why some of us just can't wait for ATM all over the friggin place :) Paul. ----------------------------------------------------------------------------- Paul D. Robertson "My statements in this message are personal opinions proberts@clark.net which may have no basis whatsoever in fact." PSB#9280 >From 9fans-outgoing-owner Mon Aug 21 16:22:16 1995 Received: by colossus.cse.psu.edu id <45595>; Mon, 21 Aug 1995 16:03:04 -0400 Received: from postman.ncube.com ([134.242.8.47]) by colossus.cse.psu.edu with SMTP id <45613>; Mon, 21 Aug 1995 15:51:24 -0400 Received: from butler.ncube.com by postman.ncube.com (4.1/SMI-4.1) id AA09087; Mon, 21 Aug 95 12:36:24 PDT Received: from skynet.ncube.com by butler.ncube.com (5.0/SMI-SVR4) id AA22126; Mon, 21 Aug 1995 12:36:20 +0800 Date: Mon, 21 Aug 1995 00:36:20 -0400 From: avg@postman.ncube.com (Vadim Antonov) Message-Id: <9508211936.AA22126@butler.ncube.com> To: 9fans Subject: Re: Set User (aka su) Content-Length: 1503 Sender: owner-9fans Precedence: bulk Reply-To: 9fans >Vadim, it's not Unix. It's not supposed to be. > >-rob It is still not an excuse for not providing elementary conviniences. My next pet peeve is that telnet from Plan9 does not even support carriage returns (although Plan9 telnetd does insert them). The minimalism itself is ok. Heck, i myself did research on mimimalist systems (the first report in Russian on the regular O.S. architecture was presented in 88). My current home project is called "Trivial Routing Architecture Proposal". However, too often what goes for minimalism is simply shifting complexity from one place to another, or having a user to deal with inconvinient interfaces (like, i can't really use Plan9 system as my workstation exactly because i can't telnet from it and do anything useful because it lacks emulation of a reasonably simple alphanumeric terminal, including (horror!) direct positioning). Ultimately, MS-DOS is "more minimal" than Plan9. It also is not supposed to be and is not Unix. Therefore it must be better. Beat it. My opinios is that *human interface* must be minimalistic and the rest of the system should be minimal as possible while supporting the functionality. Functionality comes first. Any missing piece in the basic system spawns ugly (and different) workarounds. Unix is the best example of it, what was in the v7 remained the "common denominator" and the basis for portability, the missing pieces were added in a multitude of different and often architecturally insane ways. --vadim >From 9fans-outgoing-owner Mon Aug 21 16:49:23 1995 Received: by colossus.cse.psu.edu id <45608>; Mon, 21 Aug 1995 16:37:42 -0400 Received: from postman.ncube.com ([134.242.8.47]) by colossus.cse.psu.edu with SMTP id <45524>; Mon, 21 Aug 1995 16:24:29 -0400 Received: from butler.ncube.com by postman.ncube.com (4.1/SMI-4.1) id AA09719; Mon, 21 Aug 95 12:59:07 PDT Received: from skynet.ncube.com by butler.ncube.com (5.0/SMI-SVR4) id AA22203; Mon, 21 Aug 1995 12:59:02 +0800 Date: Mon, 21 Aug 1995 00:59:02 -0400 From: avg@postman.ncube.com (Vadim Antonov) Message-Id: <9508211959.AA22203@butler.ncube.com> To: 9fans Subject: Re: [comp.os.linux.misc] Help wanted, Plan9 a piece of junk! Content-Length: 2028 Sender: owner-9fans Precedence: bulk Reply-To: 9fans >Plan 9 has its own conventions that it adheres to on *all hardware >platforms*. this is a strength, not a weakness. >as someone operating a plan 9 installation, i can tell you from >experience that it is a real joy to have something that is so >plug compatible in its interfaces and details of management >that i can once again regard sparcs, 680x0 boxes, PCs, etc. as >just a source of faster (or slower) computing power. Is it anything new? My first large-scale project (i was in a kind of leading position in the project, it had no formal "organization" behind it for a long time) was building a family of Unix-like systems (called DEMOS, addreviation for "Interactive Unified Portable Operating System"). It was running on eight different architectures (including clones of IBM/370 and some machines with no Western prototypes), and was built from the same source tree (modulo hardware dependencies and stuff like support for 3270s). Needless to say all machines were "the same". It also was (and still is) the only effort in complete internationalization of Unix. I guess it is more like that Plan 9 has a single organization producing releases. If the system will be successful it is inevitably going to change as i do not suppose that Bell Labs people will be interested in supporting the commercial releases (it is a hell lot of tedious work). When it will happen the history with Unix will repeat itself, as the root cause of the divergence of revisions wasn't fixed. That root cause is the functional incompleteness. Nobody in his own mind makes systems incompatible for the sheer hell of it. Rather, people add things to fix their particular problems which weren't adequately addressed in the original system. The ideal system is "functionally complete" in regard to the class of applications. Then there wouldn't be ugly extensions and creeping featurism. Note that this approach is kind of contradictory to the pure minimalism, which is to do absoulte minimum to solve the problems at hand. --vadim >From 9fans-outgoing-owner Mon Aug 21 17:11:32 1995 Received: by colossus.cse.psu.edu id <45522>; Mon, 21 Aug 1995 16:55:25 -0400 Received: from postman.ncube.com ([134.242.8.47]) by colossus.cse.psu.edu with SMTP id <45513>; Mon, 21 Aug 1995 16:31:39 -0400 Received: from butler.ncube.com by postman.ncube.com (4.1/SMI-4.1) id AA09851; Mon, 21 Aug 95 13:04:03 PDT Received: from skynet.ncube.com by butler.ncube.com (5.0/SMI-SVR4) id AA22212; Mon, 21 Aug 1995 13:04:00 +0800 Date: Mon, 21 Aug 1995 01:04:00 -0400 From: avg@postman.ncube.com (Vadim Antonov) Message-Id: <9508212004.AA22212@butler.ncube.com> To: 9fans Subject: Re: format for source diffs Content-Length: 469 Sender: owner-9fans Precedence: bulk Reply-To: 9fans From: Scott Schwartz >The bundle plus diff would work, but it might be nice to take advantage >of patch's functionality, since most people will be using it anyway and >it can automatically create new files from context diffs built with -Nc >or -Nu. That would require augmenting /bin/diff or porting gnu diff, >of course. Aw! The next thing to port will be EMACS :) An illustration to my point on functional completeness. --vadim >From 9fans-outgoing-owner Mon Aug 21 17:43:25 1995 Received: by colossus.cse.psu.edu id <45506>; Mon, 21 Aug 1995 17:31:56 -0400 Received: from postman.ncube.com ([134.242.8.47]) by colossus.cse.psu.edu with SMTP id <45496>; Mon, 21 Aug 1995 17:22:59 -0400 Received: from garcon.ncube.com by postman.ncube.com (4.1/SMI-4.1) id AA11573; Mon, 21 Aug 95 14:14:27 PDT Received: from pejs.ncube.com by garcon.ncube.com (5.x/SMI-SVR4) id AA18221; Mon, 21 Aug 1995 14:14:24 -0700 Date: Mon, 21 Aug 1995 17:14:24 -0400 From: sch@postman.ncube.com (Steve Hemminger) Message-Id: <9508212114.AA18221@garcon.ncube.com> Received: by pejs.ncube.com (4.1/SMI-4.1) id AA01050; Mon, 21 Aug 95 14:15:06 PDT To: 9fans Subject: Re: Set User (aka su) In-Reply-To: <9508211936.AA22126@butler.ncube.com> References: <9508211936.AA22126@butler.ncube.com> Sender: owner-9fans Precedence: bulk Reply-To: 9fans Vadim Antonov writes: > often what goes for minimalism is simply shifting complexity from > one place to another, or having a user to deal with inconvinient > interfaces (like, i can't really use Plan9 system as my workstation > exactly because i can't telnet from it and do anything useful > because it lacks emulation of a reasonably simple alphanumeric > terminal, including (horror!) direct positioning). hp telnet > My opinios is that *human interface* must be minimalistic and > the rest of the system should be minimal as possible while > supporting the functionality. Functionality comes first. > Any missing piece in the basic system spawns ugly (and different) > workarounds. Unix is the best example of it, what was in the > v7 remained the "common denominator" and the basis for portability, > the missing pieces were added in a multitude of different and > often architecturally insane ways. agreed. >From 9fans-outgoing-owner Mon Aug 21 17:56:28 1995 Received: by colossus.cse.psu.edu id <45511>; Mon, 21 Aug 1995 17:45:32 -0400 Received: from cannon.ecf.toronto.edu ([128.100.8.5]) by colossus.cse.psu.edu with SMTP id <45553>; Mon, 21 Aug 1995 17:28:01 -0400 Received: by cannon.ecf.toronto.edu id <1343>; Mon, 21 Aug 1995 17:01:06 -0400 From: Steve Kotsopoulos To: 9fans Subject: Re: Set User (aka su) Message-Id: <95Aug21.170106edt.1343@cannon.ecf.toronto.edu> Date: Mon, 21 Aug 1995 17:01:04 -0400 Sender: owner-9fans Precedence: bulk Reply-To: 9fans avg@postman.ncube.com (Vadim Antonov) wrote: > >Vadim, it's not Unix. It's not supposed to be. > > > >-rob > > It is still not an excuse for not providing elementary > conviniences. My next pet peeve is that telnet from Plan9 > does not even support carriage returns (although Plan9 telnetd > does insert them). > > The minimalism itself is ok. Heck, i myself did research on > mimimalist systems (the first report in Russian on the regular > O.S. architecture was presented in 88). My current home project > is called "Trivial Routing Architecture Proposal". However, too > often what goes for minimalism is simply shifting complexity from > one place to another, or having a user to deal with inconvinient > interfaces (like, i can't really use Plan9 system as my workstation > exactly because i can't telnet from it and do anything useful > because it lacks emulation of a reasonably simple alphanumeric > terminal, including (horror!) direct positioning). May I suggest the following: Try plan9. If you like the plan9 user interface (rc, sam, 8 1/2), install rc, sam and 9term on your Unix systems. Enjoy life. If you don't like the user interface, install *nix over-top your plan9 partition. Go back to enjoying life. >From 9fans-outgoing-owner Mon Aug 21 18:17:39 1995 Received: by colossus.cse.psu.edu id <45542>; Mon, 21 Aug 1995 18:09:21 -0400 Received: from blah.math.tu-graz.ac.at ([129.27.150.3]) by colossus.cse.psu.edu with SMTP id <45482>; Mon, 21 Aug 1995 17:45:30 -0400 Received: from blah.math.tu-graz.ac.at (bri@localhost [127.0.0.1]) by blah.math.tu-graz.ac.at (8.6.12/8.6.12) with ESMTP id XAA12650 for <9fans@cse.psu.edu>; Mon, 21 Aug 1995 23:28:18 +0200 Message-Id: <199508212128.XAA12650@blah.math.tu-graz.ac.at> To: 9fans Subject: Re: format for source diffs In-reply-to: avg's message of Mon, 21 Aug 1995 01:04:00 -0400. <9508212004.AA22212@butler.ncube.com> Date: Mon, 21 Aug 1995 17:28:18 -0400 From: Brian Ward Sender: owner-9fans Precedence: bulk Reply-To: 9fans vadim writes: |Aw! The next thing to port will be EMACS :) Isn't it already (unforunately) done? I saw the man page (recommended reading). >From 9fans-outgoing-owner Mon Aug 21 18:52:16 1995 Received: by colossus.cse.psu.edu id <45588>; Mon, 21 Aug 1995 18:44:02 -0400 Received: from postman.ncube.com ([134.242.8.47]) by colossus.cse.psu.edu with SMTP id <45840>; Mon, 21 Aug 1995 18:26:20 -0400 Received: from butler.ncube.com by postman.ncube.com (4.1/SMI-4.1) id AA12680; Mon, 21 Aug 95 14:59:56 PDT Received: from skynet.ncube.com by butler.ncube.com (5.0/SMI-SVR4) id AA22812; Mon, 21 Aug 1995 14:59:52 +0800 Date: Mon, 21 Aug 1995 02:59:52 -0400 From: avg@postman.ncube.com (Vadim Antonov) Message-Id: <9508212159.AA22812@butler.ncube.com> To: 9fans Subject: Re: Set User (aka su) Content-Length: 832 Sender: owner-9fans Precedence: bulk Reply-To: 9fans Vadim Antonov writes: > often what goes for minimalism is simply shifting complexity from > one place to another, or having a user to deal with inconvinient > interfaces (like, i can't really use Plan9 system as my workstation > exactly because i can't telnet from it and do anything useful > because it lacks emulation of a reasonably simple alphanumeric > terminal, including (horror!) direct positioning). >hp >telnet hp takes 100+ Kb to implement something which could be done in fifty bytes of code in 81/2, scrolls awfully slowly and does not handle resizing properly. I.e. not implementing a display instead of a typewriter in 81/2 simply moved the complexity to other place (hp) and made user interface incoherent (can't call sam in the same window as telnet!) If you call *that* minimalism i'm the Pope. --vadim >From 9fans-outgoing-owner Mon Aug 21 19:23:50 1995 Received: by colossus.cse.psu.edu id <45527>; Mon, 21 Aug 1995 19:14:03 -0400 Received: from galapagos.cse.psu.edu ([130.203.2.12]) by colossus.cse.psu.edu with SMTP id <45512>; Mon, 21 Aug 1995 18:59:57 -0400 Received: by galapagos.cse.psu.edu id <12721>; Mon, 21 Aug 1995 18:40:44 -0400 From: Scott Schwartz To: 9fans Subject: diff|patch Message-Id: <95Aug21.184044edt.12721@galapagos.cse.psu.edu> Date: Mon, 21 Aug 1995 18:40:42 -0400 Sender: owner-9fans Precedence: bulk Reply-To: 9fans I don't get it. As far as I can tell, context diffs and patch are not a matter of unix compatability, creeping features, religious wars, or anything like that. It's just a fact that without patch applying these updates is intolerably arduous, and without context diffs you have to manually examine the files, split them into sections for patch, and copy new files into place, and suffer a greater likelihood of error. Why do it the hard way, when simple, effective, minimalistic, software tools are available to do the job? >From 9fans-outgoing-owner Mon Aug 21 19:55:47 1995 Received: by colossus.cse.psu.edu id <45495>; Mon, 21 Aug 1995 19:43:45 -0400 Received: from plan9.cs.york.ac.uk ([144.32.33.120]) by colossus.cse.psu.edu with SMTP id <45538>; Mon, 21 Aug 1995 19:04:34 -0400 From: forsyth@plan9.cs.york.ac.uk To: 9fans Date: Mon, 21 Aug 1995 18:54:38 -0400 Subject: Re: [comp.os.linux.misc] Help wanted, Plan9 a piece of junk! Message-Id: <95Aug21.190434edt.45538@colossus.cse.psu.edu> Sender: owner-9fans Precedence: bulk Reply-To: 9fans >>that i can once again regard sparcs, 680x0 boxes, PCs, etc. as >Is it anything new? My first large-scale project (i was in a kind no, that's why i carefully said `again'. i intend to keep it this time, though. >From 9fans-outgoing-owner Mon Aug 21 20:39:42 1995 Received: by colossus.cse.psu.edu id <45512>; Mon, 21 Aug 1995 20:30:26 -0400 Received: from plan9.cs.york.ac.uk ([144.32.33.120]) by colossus.cse.psu.edu with SMTP id <45552>; Mon, 21 Aug 1995 20:14:27 -0400 From: forsyth@plan9.cs.york.ac.uk To: 9fans Date: Mon, 21 Aug 1995 19:42:36 -0400 Subject: Re: Set User (aka su) Message-Id: <95Aug21.201427edt.45552@colossus.cse.psu.edu> Sender: owner-9fans Precedence: bulk Reply-To: 9fans >>done in fifty bytes of code in 81/2, scrolls awfully slowly >>and does not handle resizing properly. hmmmm, all right. show me that code (and it's not as though i'm from Missouri). the thing that many people want from hp -- support for the ESC-based cursor addressing schemes -- is the bulk of hp's source code. furthermore, the people who want that here are rarely satisfied by hp -- they wt more more more cursor addressing codes -- specifically support for either VT320 or PC `ANSI' escape sequences. that requires somewhat more than the code in hp. i've been looking at this recently, so i've had to read lots of vt220 emulators, the vt/pc emulator in the linux kernel, etc. i don't accept this statement at all. also, the scrolling in hp is slow because it makes no attempt to be fast. it has little to do with the fact that it is working as a client of 8€Ž€. (after all, Sun's EEPROM has the screen mapped, and did you ever see the display and scrolling time on that in the older Sparcs. whew!) >>made user interface incoherent (can't call sam in the same >>window as telnet!) i do not understand how support for cursor addressing makes the user interface `coherent' on any of the systems that support this archaic crud. sam is usable in an X11 xterm only because it makes a separate call back to the terminal to produce something that isn't an xterm. there is incoherence in the plan 9 user interface, because there are several. most obviously, the mouse handling conventions in Acme are different from those elsewhere; perhaps the conventions will eventually converge again at a new limit. at least it is an interesting diversion. >From 9fans-outgoing-owner Mon Aug 21 20:52:21 1995 Received: by colossus.cse.psu.edu id <45537>; Mon, 21 Aug 1995 20:45:50 -0400 Received: from plan9.att.com ([192.20.225.252]) by colossus.cse.psu.edu with SMTP id <45496>; Mon, 21 Aug 1995 20:18:16 -0400 From: rob@plan9.att.com To: 9fans Date: Mon, 21 Aug 1995 19:51:32 -0400 Subject: Re: Set User (aka su) Message-Id: <95Aug21.201816edt.45496@colossus.cse.psu.edu> Sender: owner-9fans Precedence: bulk Reply-To: 9fans >hp takes 100+ Kb to implement something which could be >done in fifty bytes of code in 81/2, scrolls awfully slowly >and does not handle resizing properly. >I.e. not implementing a display instead of a typewriter in >81/2 simply moved the complexity to other place (hp) and >made user interface incoherent (can't call sam in the same >window as telnet!) The point was to try new ways of working, not reproduce the old ways. I left cursor addressing out on purpose: what Plan 9 offers is a different way to edit, both local and remote. No, you can't run sam on a telnet window but you can run it in a cpu window, and we prefer that way of working. Even when connected to unix, sam -r unixmachine works fine. Sure, that doesn't work in a telnet window, but that's a minor point. Putting cursor addressing in 8€Ž€ would make it too easy to fall back to the old style of interaction, obscuring the new ideas. All your carping is really about Plan 9's interface incompatibilities with Unix. If it's that important to you to use Unix, go use it. Plan 9 is a statement about its own environment, not about how to connect to Unix using telnet. Putting the kind of support you want into Plan 9 compromises the ideas in the system itself. We oppose that. If you decide that things need to be compatible with all that's gone before, you end up on the road Unix is on. You'll get something like Spring or Mach, which are really just reengineerings of the Unix interface. An O.S. is only as good as its view of the system. Plan 9 provides a different view, and its tools take advantage of those differences. You could port emacs or whatever other tool you feel is missing, but why bother? You already have it where you work now. If you want to see what Plan 9 is about, try it as it is. The true test is not how easily you can reproduce what Plan 9 is trying to replace; rather it's how the new environment makes new things possible. -rob >From 9fans-outgoing-owner Mon Aug 21 21:04:28 1995 Received: by colossus.cse.psu.edu id <45549>; Mon, 21 Aug 1995 20:56:18 -0400 Received: from postman.ncube.com ([134.242.8.47]) by colossus.cse.psu.edu with SMTP id <45561>; Mon, 21 Aug 1995 20:23:06 -0400 Received: from butler.ncube.com by postman.ncube.com (4.1/SMI-4.1) id AA17087; Mon, 21 Aug 95 17:08:29 PDT Received: from skynet.ncube.com by butler.ncube.com (5.0/SMI-SVR4) id AA23348; Mon, 21 Aug 1995 17:08:24 +0800 Date: Mon, 21 Aug 1995 05:08:24 -0400 From: avg@postman.ncube.com (Vadim Antonov) Message-Id: <9508220008.AA23348@butler.ncube.com> To: 9fans Subject: Re: diff|patch Content-Length: 1287 Sender: owner-9fans Precedence: bulk Reply-To: 9fans From: Scott Schwartz >I don't get it. You're not alone. >As far as I can tell, context diffs and patch are not >a matter of unix compatability, creeping features, religious wars, or >anything like that. It's just a fact that without patch applying these >updates is intolerably arduous, and without context diffs you have to >manually examine the files, split them into sections for patch, and >copy new files into place, and suffer a greater likelihood of error. >Why do it the hard way, when simple, effective, minimalistic, software >tools are available to do the job? diff with context is undoubtly convinient. As for the patches, may i propose that all patches be published in format like that: ed - /sys/src/cmd/mycmd.c << '/&' .... output of diff -e /& and applied only to the CD-ROM code (i.e. no patches on patches). (For you computer history buffs -- /& was the terminating card in datasets in DOS/360. OS/370 and later used '//'. //GO.SYSIN DD * was used as indicator of a beginning of the dataset following this card, for step GO (program run). '*' means that the data is inlined, the end of data was indicated by any card containting // in first two columns. So, the bundle's usage of the sacred JCL is revisionist :) --vadim >From 9fans-outgoing-owner Mon Aug 21 21:20:34 1995 Received: by colossus.cse.psu.edu id <45607>; Mon, 21 Aug 1995 21:11:33 -0400 Received: from plan9.cs.york.ac.uk ([144.32.33.120]) by colossus.cse.psu.edu with SMTP id <45505>; Mon, 21 Aug 1995 20:40:28 -0400 From: forsyth@plan9.cs.york.ac.uk To: 9fans Date: Mon, 21 Aug 1995 20:04:36 -0400 Subject: re: diff|patch Message-Id: <95Aug21.204028edt.45505@colossus.cse.psu.edu> Sender: owner-9fans Precedence: bulk Reply-To: 9fans >>anything like that. It's just a fact that without patch applying these >>updates is intolerably arduous, and without context diffs you have to >>manually examine the files, split them into sections for patch, and based on my experience over the years with diff|patch, i am reluctant to apply patch to anything i care about and not manually examine the files before and after, especially with patches coming from a number of sources applied to (possibly) different base versions. i'd be happier receiving a package that contained (say) the checksums of the original files on the originating site, a set of diff -e changes, and a script that checked before applying that my copy of the source was the right version and also checks for instance that the output file matches the new version on the originating site (it might suffice to check that diff applied to input and output files reproduces the diff output in the package). if precondition or postcondition fails, then i really do want to know about it. >From 9fans-outgoing-owner Mon Aug 21 22:11:05 1995 Received: by colossus.cse.psu.edu id <45505>; Mon, 21 Aug 1995 22:02:45 -0400 Received: from ncrhub1.ATTGIS.COM ([192.127.251.16]) by colossus.cse.psu.edu with SMTP id <45496>; Mon, 21 Aug 1995 22:02:28 -0400 Received: from ncrgw1 by ncrhub1.ATTGIS.COM id aa04494; 21 Aug 95 22:02 EDT Received: by ncrgw1.ATTGIS.COM; 21 Aug 95 21:56:59 EDT Received: by ncrhub4.ATTGIS.COM; 21 Aug 95 21:56:47 EDT Received: by ncrlnk.DaytonOH.NCR.COM; 21 Aug 95 21:55:43 EDT Date: Mon, 21 Aug 1995 23:58:16 -0400 From: MAILER-DAEMON@iss.southafrica.NCR.COM Full-Name: Mail Router (smail 2.8.1 dl,da,fa,tu,po,qf,dbm 04/16/92 1) Subject: Returned mail To: 9fans Message-ID: <9508212202.aa04494@ncrhub1.ATTGIS.COM> Sender: owner-9fans Precedence: bulk Reply-To: 9fans Your mail could not be delivered because of the following reason: ----- Transcript of session follows ----- Executing: /usr/lib/mail/surrcmd/smtpqer -B -C -u iss.SouthAfrica.NCR.COM!ncrlnk!ncrhub4!ncrgw1!cse.psu.edu!9fans capetown.SouthAfrica.ATTGIS.COM lynna@capetown.SouthAfrica.ATTGIS.COM smtpqer: Binary contents cannot be sent via SMTP server "/usr/lib/mail/surrcmd/smtpqer" failed - unknown mailer error 1 ----- Unsent message follows ----- >From ncrhub4!ncrgw1!cse.psu.edu!9fans Mon Aug 21 21:04 EDT 1995 remote from ncrlnk Received: by ncrlnk.DaytonOH.NCR.COM; 21 Aug 95 21:04:25 EDT Received: by ncrhub4.ATTGIS.COM; 21 Aug 95 21:04:41 EDT Received: by ncrgw1.ATTGIS.COM; 21 Aug 95 20:58:25 EDT Received: by colossus.cse.psu.edu id <45537>; Mon, 21 Aug 1995 20:45:50 -0400 Received: from plan9.att.com ([192.20.225.252]) by colossus.cse.psu.edu with SMTP id <45496>; Mon, 21 Aug 1995 20:18:16 -0400 From: rob@plan9.att.com To: 9fans@cse.psu.edu Date: Mon, 21 Aug 1995 19:51:32 -0400 Subject: Re: Set User (aka su) Message-Id: <95Aug21.201816edt.45496@colossus.cse.psu.edu> Sender: owner-9fans@cse.psu.edu Precedence: bulk Reply-To: 9fans@cse.psu.edu >hp takes 100+ Kb to implement something which could be >done in fifty bytes of code in 81/2, scrolls awfully slowly >and does not handle resizing properly. >I.e. not implementing a display instead of a typewriter in >81/2 simply moved the complexity to other place (hp) and >made user interface incoherent (can't call sam in the same >window as telnet!) The point was to try new ways of working, not reproduce the old ways. I left cursor addressing out on purpose: what Plan 9 offers is a different way to edit, both local and remote. No, you can't run sam on a telnet window but you can run it in a cpu window, and we prefer that way of working. Even when connected to unix, sam -r unixmachine works fine. Sure, that doesn't work in a telnet window, but that's a minor point. Putting cursor addressing in 8B= would make it too easy to fall back to the old style of interaction, obscuring the new ideas. All your carping is really about Plan 9's interface incompatibilities with Unix. If it's that important to you to use Unix, go use it. Plan 9 is a statement about its own environment, not about how to connect to Unix using telnet. Putting the kind of support you want into Plan 9 compromises the ideas in the system itself. We oppose that. If you decide that things need to be compatible with all that's gone before, you end up on the road Unix is on. You'll get something like Spring or Mach, which are really just reengineerings of the Unix interface. An O.S. is only as good as its view of the system. Plan 9 provides a different view, and its tools take advantage of those differences. You could port emacs or whatever other tool you feel is missing, but why bother? You already have it where you work now. If you want to see what Plan 9 is about, try it as it is. The true test is not how easily you can reproduce what Plan 9 is trying to replace; rather it's how the new environment makes new things possible. -rob >From 9fans-outgoing-owner Mon Aug 21 22:19:31 1995 Received: by colossus.cse.psu.edu id <45496>; Mon, 21 Aug 1995 22:10:05 -0400 Received: from ncrhub1.ATTGIS.COM ([192.127.251.16]) by colossus.cse.psu.edu with SMTP id <45495>; Mon, 21 Aug 1995 22:02:29 -0400 Received: from ncrgw1 by ncrhub1.ATTGIS.COM id ab04494; 21 Aug 95 22:02 EDT Received: by ncrgw1.ATTGIS.COM; 21 Aug 95 21:56:56 EDT Received: by ncrhub4.ATTGIS.COM; 21 Aug 95 21:56:46 EDT Received: by ncrlnk.DaytonOH.NCR.COM; 21 Aug 95 21:55:39 EDT Date: Mon, 21 Aug 1995 23:58:13 -0400 From: MAILER-DAEMON@iss.southafrica.NCR.COM Full-Name: Mail Router (smail 2.8.1 dl,da,fa,tu,po,qf,dbm 04/16/92 1) Subject: Returned mail To: 9fans Message-ID: <9508212202.ab04494@ncrhub1.ATTGIS.COM> Sender: owner-9fans Precedence: bulk Reply-To: 9fans Your mail could not be delivered because of the following reason: ----- Transcript of session follows ----- Executing: /usr/lib/mail/surrcmd/smtpqer -B -C -u iss.SouthAfrica.NCR.COM!ncrlnk!ncrhub4!ncrgw1!cse.psu.edu!9fans capetown.SouthAfrica.ATTGIS.COM lynna@capetown.SouthAfrica.ATTGIS.COM smtpqer: Binary contents cannot be sent via SMTP server "/usr/lib/mail/surrcmd/smtpqer" failed - unknown mailer error 1 ----- Unsent message follows ----- >From ncrhub4!ncrgw1!cse.psu.edu!9fans Mon Aug 21 21:04 EDT 1995 remote from ncrlnk Received: by ncrlnk.DaytonOH.NCR.COM; 21 Aug 95 21:04:13 EDT Received: by ncrhub4.ATTGIS.COM; 21 Aug 95 21:04:36 EDT Received: by ncrgw1.ATTGIS.COM; 21 Aug 95 20:58:20 EDT Received: by colossus.cse.psu.edu id <45512>; Mon, 21 Aug 1995 20:30:26 -0400 Received: from plan9.cs.york.ac.uk ([144.32.33.120]) by colossus.cse.psu.edu with SMTP id <45552>; Mon, 21 Aug 1995 20:14:27 -0400 From: forsyth@plan9.cs.york.ac.uk To: 9fans@cse.psu.edu Date: Mon, 21 Aug 1995 19:42:36 -0400 Subject: Re: Set User (aka su) Message-Id: <95Aug21.201427edt.45552@colossus.cse.psu.edu> Sender: owner-9fans@cse.psu.edu Precedence: bulk Reply-To: 9fans@cse.psu.edu >>done in fifty bytes of code in 81/2, scrolls awfully slowly >>and does not handle resizing properly. hmmmm, all right. show me that code (and it's not as though i'm from Missouri). the thing that many people want from hp -- support for the ESC-based cursor addressing schemes -- is the bulk of hp's source code. furthermore, the people who want that here are rarely satisfied by hp -- they wt more more more cursor addressing codes -- specifically support for either VT320 or PC `ANSI' escape sequences. that requires somewhat more than the code in hp. i've been looking at this recently, so i've had to read lots of vt220 emulators, the vt/pc emulator in the linux kernel, etc. i don't accept this statement at all. also, the scrolling in hp is slow because it makes no attempt to be fast. it has little to do with the fact that it is working as a client of 8B=. (after all, Sun's EEPROM has the screen mapped, and did you ever see the display and scrolling time on that in the older Sparcs. whew!) >>made user interface incoherent (can't call sam in the same >>window as telnet!) i do not understand how support for cursor addressing makes the user interface `coherent' on any of the systems that support this archaic crud. sam is usable in an X11 xterm only because it makes a separate call back to the terminal to produce something that isn't an xterm. there is incoherence in the plan 9 user interface, because there are several. most obviously, the mouse handling conventions in Acme are different from those elsewhere; perhaps the conventions will eventually converge again at a new limit. at least it is an interesting diversion. >From 9fans-outgoing-owner Mon Aug 21 22:29:32 1995 Received: by colossus.cse.psu.edu id <45495>; Mon, 21 Aug 1995 22:24:23 -0400 Received: from postman.ncube.com ([134.242.8.47]) by colossus.cse.psu.edu with SMTP id <45506>; Mon, 21 Aug 1995 22:24:06 -0400 Received: from butler.ncube.com by postman.ncube.com (4.1/SMI-4.1) id AA02154; Mon, 21 Aug 95 19:24:31 PDT Received: from skynet.ncube.com by butler.ncube.com (5.0/SMI-SVR4) id AA23935; Mon, 21 Aug 1995 19:24:26 +0800 Date: Mon, 21 Aug 1995 07:24:26 -0400 From: avg@postman.ncube.com (Vadim Antonov) Message-Id: <9508220224.AA23935@butler.ncube.com> To: 9fans Subject: Re: Set User (aka su) Content-Length: 1980 Sender: owner-9fans Precedence: bulk Reply-To: 9fans From: forsyth@plan9.cs.york.ac.uk >the thing that many people want from hp -- support for the >ESC-based cursor addressing schemes -- is the bulk of hp's source code. HP is an extremely poor choice of terminal to emulate, as it is overly complicated and full of margianlly useful features. I counted lines, BTW, and >90% of the code is spent on doing menus, yet another line discipline, emulating "cons" and "consctl", etc etc. Only about 100 lines are devoted to parsing command sequences (and most of them are unnecessary). I would prefer arguing not about beliefs but about facts, ok? >furthermore, the people who want that here are rarely satisfied >by hp -- they wt more more more cursor addressing codes -- >specifically support for either VT320 or PC `ANSI' escape sequences. It definitely makes sense to do something standard if the standard exists. You may argue till the hell freezes that the electric plugs are of the wrong shape, but try to manufacture "improved" ones which won't plug into old sockets. >i've been looking at this recently, so i've had to read lots of vt220 emulators, >the vt/pc emulator in the linux kernel, etc. i don't accept this statement >at all. You don't need to emulate anything fancy, just a minimal device which can be used as a display. >also, the scrolling in hp is slow because it makes no attempt to be fast. And doing it fast would bloat the code even more. >>made user interface incoherent (can't call sam in the same >>window as telnet!) >i do not understand how support for cursor addressing makes the user interface >`coherent' on any of the systems that support this archaic crud. Sorry, emulation of a teletype is even more "archaic" than of a display. Bzzt. >sam is usable in an X11 xterm only because it makes a separate call back to the terminal to produce something that isn't an xterm. You didn't understand what i said. Try to do: hp sam somefile (telnet and cu are barely useful without hp). --vadim >From 9fans-outgoing-owner Mon Aug 21 23:12:50 1995 Received: by colossus.cse.psu.edu id <45506>; Mon, 21 Aug 1995 23:04:19 -0400 Received: from postman.ncube.com ([134.242.8.47]) by colossus.cse.psu.edu with SMTP id <45505>; Mon, 21 Aug 1995 23:04:03 -0400 Received: from butler.ncube.com by postman.ncube.com (4.1/SMI-4.1) id AA03528; Mon, 21 Aug 95 20:04:32 PDT Received: from skynet.ncube.com by butler.ncube.com (5.0/SMI-SVR4) id AA24079; Mon, 21 Aug 1995 20:04:28 +0800 Date: Mon, 21 Aug 1995 08:04:28 -0400 From: avg@postman.ncube.com (Vadim Antonov) Message-Id: <9508220304.AA24079@butler.ncube.com> To: 9fans Subject: Re: Set User (aka su) Content-Length: 3096 Sender: owner-9fans Precedence: bulk Reply-To: 9fans >Sure, that doesn't work in a telnet window, but that's a minor point. "It does not work" is the euphmeism for "it will be fixed by commercial vendors, many times over, and all their fixes will be incompatible". >Putting cursor addressing in 8€Ž€ would make it too easy to fall back >to the old style of interaction, obscuring the new ideas. There is a large class of applications which do not need any fancy graphical interfaces. You insist on making them inherently more complex by forcing implementors to do graphics, their own cooked mode processing (i already found eight instances in Plan9, all of them different!) and making interaction with other systems a lot more inconvinient than it should be. >All your carping is really about Plan 9's interface incompatibilities with >Unix. If it's that important to you to use Unix, go use it. Sorry, i *do* use Unix, and mostly because there is a lot of things i can't do with Plan 9, because of stupid reasons. >Plan 9 is >a statement about its own environment, not about how to connect to >Unix using telnet. Ah, ok, so implementing a teletype instead of a display is a "statement". May i politely inquire why didn't you decide to get rid of command line interface completely? It is so archaic. Some people did that long time ago and already made millions. >Putting the kind of support you want into Plan 9 >compromises the ideas in the system itself. We oppose that. As i said you either confine system to research lab and hobbyists or make it able to live in the real world, where legacy systems are not going to die any time soon. >If you decide that things need to be compatible with all that's gone >before, you end up on the road Unix is on. You missed the point of my philosophy completely. The road the Unix went is because things were lacking in the initial system, not because of the inherently bad interface. It was very easy to design a good generic terminal emulator and put it into kernel, and get rid of termcap goo in applications forever. Instead, users and vendors in need of a quick fix expanded it, so it became intractable. The same is going to happen with Plan 9, if it is going to be a successful system. The lack of interface in the system will simply proliferate ugly hacks. If you have to duplicate functionality in a number of places it is an indication of a design failure. >You'll get something like >Spring or Mach, which are really just reengineerings of the Unix >interface. Does not Plan 9 include APE? To make a statement coherent you should remove it, as it makes people to use their old habits of fopening and printf-ing. It even has stty and pseudo-terminals. Why does it have telnet and cu at all? It connects people to the systems with a completely different interface (horror!). Sure, people who want to talk to Unix systems can use Unix. Also, to make the statement pure the name of "ls" should be changed, so users won't forget they're not on a Unix system. I respect people who go on hunger strikes. As long as they don't sneak food in when nobody watches. --vadim >From 9fans-outgoing-owner Mon Aug 21 23:35:42 1995 Received: by colossus.cse.psu.edu id <45510>; Mon, 21 Aug 1995 23:27:55 -0400 Received: from plan9.att.com ([192.20.225.252]) by colossus.cse.psu.edu with SMTP id <45508>; Mon, 21 Aug 1995 23:27:39 -0400 From: rob@plan9.att.com To: 9fans Date: Mon, 21 Aug 1995 23:27:23 -0400 Subject: Re: Set User (aka su) Message-Id: <95Aug21.232739edt.45508@colossus.cse.psu.edu> Sender: owner-9fans Precedence: bulk Reply-To: 9fans Compromises are necessary for interoperation; we want to leave them as compromises, you want to elevate them to the level of those interfaces in the systems you're connecting to. We'll never agree. I suggest a different compromise: you do whatever you want, we ignore you. Deal? -rob >From 9fans-outgoing-owner Tue Aug 22 00:12:47 1995 Received: by colossus.cse.psu.edu id <45511>; Tue, 22 Aug 1995 00:01:19 -0400 Received: from ncrhub1.ATTGIS.COM ([192.127.251.16]) by colossus.cse.psu.edu with SMTP id <45482>; Tue, 22 Aug 1995 00:01:01 -0400 Received: from ncrgw1 by ncrhub1.ATTGIS.COM id ab08703; 22 Aug 95 0:01 EDT Received: by ncrgw1.ATTGIS.COM; 21 Aug 95 23:55:56 EDT Received: by ncrhub4.ATTGIS.COM; 21 Aug 95 23:55:46 EDT Received: by ncrlnk.DaytonOH.NCR.COM; 21 Aug 95 23:54:40 EDT Date: Tue, 22 Aug 1995 01:57:42 -0400 From: MAILER-DAEMON@iss.southafrica.NCR.COM Full-Name: Mail Router (smail 2.8.1 dl,da,fa,tu,po,qf,dbm 04/16/92 1) Subject: Returned mail To: 9fans Message-ID: <9508220001.ab08703@ncrhub1.ATTGIS.COM> Sender: owner-9fans Precedence: bulk Reply-To: 9fans Your mail could not be delivered because of the following reason: ----- Transcript of session follows ----- Executing: /usr/lib/mail/surrcmd/smtpqer -B -C -u iss.SouthAfrica.NCR.COM!ncrlnk!ncrhub4!ncrgw1!cse.psu.edu!9fans capetown.SouthAfrica.ATTGIS.COM lynna@capetown.SouthAfrica.ATTGIS.COM smtpqer: Binary contents cannot be sent via SMTP server "/usr/lib/mail/surrcmd/smtpqer" failed - unknown mailer error 1 ----- Unsent message follows ----- >From ncrhub4!ncrgw1!cse.psu.edu!9fans Mon Aug 21 23:21 EDT 1995 remote from ncrlnk Received: by ncrlnk.DaytonOH.NCR.COM; 21 Aug 95 23:21:12 EDT Received: by ncrhub4.ATTGIS.COM; 21 Aug 95 23:21:52 EDT Received: by ncrgw1.ATTGIS.COM; 21 Aug 95 23:21:41 EDT Received: by colossus.cse.psu.edu id <45506>; Mon, 21 Aug 1995 23:04:19 -0400 Received: from postman.ncube.com ([134.242.8.47]) by colossus.cse.psu.edu with SMTP id <45505>; Mon, 21 Aug 1995 23:04:03 -0400 Received: from butler.ncube.com by postman.ncube.com (4.1/SMI-4.1) id AA03528; Mon, 21 Aug 95 20:04:32 PDT Received: from skynet.ncube.com by butler.ncube.com (5.0/SMI-SVR4) id AA24079; Mon, 21 Aug 1995 20:04:28 +0800 Date: Mon, 21 Aug 1995 08:04:28 -0400 From: avg@postman.ncube.com (Vadim Antonov) Message-Id: <9508220304.AA24079@butler.ncube.com> To: 9fans@cse.psu.edu Subject: Re: Set User (aka su) Content-Length: 3096 Sender: owner-9fans@cse.psu.edu Precedence: bulk Reply-To: 9fans@cse.psu.edu >Sure, that doesn't work in a telnet window, but that's a minor point. "It does not work" is the euphmeism for "it will be fixed by commercial vendors, many times over, and all their fixes will be incompatible". >Putting cursor addressing in 8B= would make it too easy to fall back >to the old style of interaction, obscuring the new ideas. There is a large class of applications which do not need any fancy graphical interfaces. You insist on making them inherently more complex by forcing implementors to do graphics, their own cooked mode processing (i already found eight instances in Plan9, all of them different!) and making interaction with other systems a lot more inconvinient than it should be. >All your carping is really about Plan 9's interface incompatibilities with >Unix. If it's that important to you to use Unix, go use it. Sorry, i *do* use Unix, and mostly because there is a lot of things i can't do with Plan 9, because of stupid reasons. >Plan 9 is >a statement about its own environment, not about how to connect to >Unix using telnet. Ah, ok, so implementing a teletype instead of a display is a "statement". May i politely inquire why didn't you decide to get rid of command line interface completely? It is so archaic. Some people did that long time ago and already made millions. >Putting the kind of support you want into Plan 9 >compromises the ideas in the system itself. We oppose that. As i said you either confine system to research lab and hobbyists or make it able to live in the real world, where legacy systems are not going to die any time soon. >If you decide that things need to be compatible with all that's gone >before, you end up on the road Unix is on. You missed the point of my philosophy completely. The road the Unix went is because things were lacking in the initial system, not because of the inherently bad interface. It was very easy to design a good generic terminal emulator and put it into kernel, and get rid of termcap goo in applications forever. Instead, users and vendors in need of a quick fix expanded it, so it became intractable. The same is going to happen with Plan 9, if it is going to be a successful system. The lack of interface in the system will simply proliferate ugly hacks. If you have to duplicate functionality in a number of places it is an indication of a design failure. >You'll get something like >Spring or Mach, which are really just reengineerings of the Unix >interface. Does not Plan 9 include APE? To make a statement coherent you should remove it, as it makes people to use their old habits of fopening and printf-ing. It even has stty and pseudo-terminals. Why does it have telnet and cu at all? It connects people to the systems with a completely different interface (horror!). Sure, people who want to talk to Unix systems can use Unix. Also, to make the statement pure the name of "ls" should be changed, so users won't forget they're not on a Unix system. I respect people who go on hunger strikes. As long as they don't sneak food in when nobody watches. --vadim >From 9fans-outgoing-owner Tue Aug 22 05:02:40 1995 Received: by psuvax1.cse.psu.edu id <34261>; Tue, 22 Aug 1995 04:37:28 -0400 Received: from plan9.cs.york.ac.uk ([144.32.33.120]) by psuvax1.cse.psu.edu with SMTP id <34155>; Tue, 22 Aug 1995 04:36:53 -0400 From: forsyth@plan9.cs.york.ac.uk To: 9fans@cs.psu.edu Date: Tue, 22 Aug 1995 04:40:42 -0400 subject: standards Message-Id: <95Aug22.043653edt.34155@psuvax1.cse.psu.edu> Sender: owner-9fans Precedence: bulk Reply-To: 9fans >>It definitely makes sense to do something standard if the >>standard exists. You may argue till the hell freezes that >>the electric plugs are of the wrong shape, but try to manufacture >>"improved" ones which won't plug into old sockets. funnily enough, i live in a country where this really has changed several times. it was apparently supposed to change again, owing to EU standardisation, but i haven't heard much about it recently. up to now, each new plug design has had enough advantages (in safety, in capacity) to offset the disadvantages of making a change. >From 9fans-outgoing-owner Tue Aug 22 07:18:41 1995 Received: by psuvax1.cse.psu.edu id <34264>; Tue, 22 Aug 1995 06:53:26 -0400 Received: from plan9.cs.york.ac.uk ([144.32.33.120]) by psuvax1.cse.psu.edu with SMTP id <34155>; Tue, 22 Aug 1995 06:53:07 -0400 From: forsyth@plan9.cs.york.ac.uk To: 9fans@cs.psu.edu Date: Tue, 22 Aug 1995 06:44:15 -0400 subject: graphics programming Message-Id: <95Aug22.065307edt.34155@psuvax1.cse.psu.edu> Sender: owner-9fans Precedence: bulk Reply-To: 9fans it's strange. i find it much easier to program now using , and sometimes than it was even to work through the manual pages and bugs for , let alone terminfo. i get a better class of display and interaction, too. bitmap graphics looks complex if you've been faced with that shelf of basic X11 manuals, but it's straightforward, really. i heartily encourage those readers who have been put off until now to have a go. for those applications that don't particularly benefit from fancy graphics, Acme centralises and simplifies the interface building effort, and encourages a coherence to the interaction. it even does your `cooked mode' processing for you (and more important things as well). >From 9fans-outgoing-owner Tue Aug 22 07:51:22 1995 Received: by colossus.cse.psu.edu id <45512>; Tue, 22 Aug 1995 07:34:50 -0400 Received: from plan9.cs.su.oz.au ([129.78.96.3]) by colossus.cse.psu.edu with SMTP id <45524>; Tue, 22 Aug 1995 07:34:33 -0400 Date: Tue, 22 Aug 1995 07:25:18 -0400 From: dhog@plan9.cs.su.oz.au To: 9fans Subject: Re: [comp.os.linux.misc] Help wanted, Plan9 a piece of junk! Message-Id: <95Aug22.073433edt.45524@colossus.cse.psu.edu> Sender: owner-9fans Precedence: bulk Reply-To: 9fans avg@postman.ncube.com (Vadim Antonov) writes: >The ideal system is "functionally complete" in regard to the >class of applications. Then there wouldn't be ugly extensions >and creeping featurism. Note that this approach is kind of >contradictory to the pure minimalism, which is to do absoulte >minimum to solve the problems at hand. The only problem is that you need an infinite amount of storage. A "functionally complete" system must be able to understand all the file formats of the world (audio, video, data compression, MS Word documents etc) including ones yet to be devised. It must contain all the applications that anyone ever wants to be able to use a computer for, including ones yet to be devised. No system can provide all the functionality that users are going to want. Look at X windows. It is a system which _tries_ to be functionally complete. Yet every new release provides yet another batch of ugly features that were "missing" in the last. The toolkit & widget sets try to do everything for the programmer, who is forced to spend hours writing messy code which describes just what the widgets should do, only to find that some bug in the libraries takes even longer to find a workaround for. This pattern is duplicated by many other software systems, written by well meaning programmers with your philosophy. So Seventh Edition Unix didn't provide support for networking. Can't really blame its authors, networking was pretty non-existant in those days. I suppose that in another 10-20 years, people like you will be bemoaning the fact that the original versions of Plan 9 didn't include support for (say) direct brain interfaces, so that there are multiple conflicting implementations of them... >From 9fans-outgoing-owner Tue Aug 22 08:08:01 1995 Received: by colossus.cse.psu.edu id <45529>; Tue, 22 Aug 1995 07:51:59 -0400 Received: from plan9.cs.su.oz.au ([129.78.96.3]) by colossus.cse.psu.edu with SMTP id <45538>; Tue, 22 Aug 1995 07:51:18 -0400 Date: Tue, 22 Aug 1995 07:37:51 -0400 From: dhog@plan9.cs.su.oz.au To: 9fans Subject: Re: Set User (aka su) Message-Id: <95Aug22.075118edt.45538@colossus.cse.psu.edu> Sender: owner-9fans Precedence: bulk Reply-To: 9fans >>Plan 9 is >>a statement about its own environment, not about how to connect to >>Unix using telnet. > >Ah, ok, so implementing a teletype instead of a display is a >"statement". Did a teletype let you go back and edit previous output, and then resend it??? Plan 9's windowing system (which is not named here for fear of invoking the wrath of System V upas) is most definately not "implementing a teletype". It is more modern than xterm, which doesn't make effective use of the mouse. Encoding cursor motions as a series of escape sequences, now _that_'s archaic. >May i politely inquire why didn't you decide to >get rid of command line interface completely? It is so archaic. >Some people did that long time ago and already made millions. He did. It's called acme. I'm using it to send this mail. What I just can't understand is why Unix and Dos don't provide support for acme, I mean they're so functionally incomplete. >From 9fans-outgoing-owner Tue Aug 22 11:51:42 1995 Received: by colossus.cse.psu.edu id <45556>; Tue, 22 Aug 1995 11:28:20 -0400 Received: from dealer.cards.com ([192.133.70.2]) by colossus.cse.psu.edu with SMTP id <45552>; Tue, 22 Aug 1995 11:27:58 -0400 Received: from monte (monte.cards.com) by dealer.cards.com (4.1/mls/3.2) id AA05275; Tue, 22 Aug 95 11:28:24 EDT Message-Id: <9508221528.AA05275@dealer.cards.com> Received: by monte (4.1/mls/3.2) id AA00544; Tue, 22 Aug 95 11:28:22 EDT From: carvell@cards.com Subject: Re: Set User (aka su) To: 9fans Date: Tue, 22 Aug 1995 11:28:21 -0400 In-Reply-To: <95Aug22.075118edt.45538@colossus.cse.psu.edu> from "dhog@plan9.cs.su.oz.au" at Aug 22, 95 07:37:51 am Content-Type: text Content-Length: 1317 Sender: owner-9fans Precedence: bulk Reply-To: 9fans > > >>Plan 9 is > >>a statement about its own environment, not about how to connect to > >>Unix using telnet. > > > >Ah, ok, so implementing a teletype instead of a display is a > >"statement". > > Did a teletype let you go back and edit previous output, and then resend it??? As a side note... has anyone on the Plan 9 list ever used the Macintosh MPW shell? It is a Unix-like shell combined with a programmer's text editor. You could select any text at any location in any editing window, hit Enter, and send it off as a command. Or conversely edit any command with the full power of the text editor. This gave you many of the features of the 8 1/2 terminal and Acme, e.g. you could directly execute the examples in the help files, or make a handy file of commonly used commands. It's been several years since I've done any Mac programming - always missed MPW though. It is nice to have those powerful user interface capabilities again. I'm still struggling with Sam (years of using emacs has damaged my cerebral cortex, I'm afraid) but I'm already hooked on Acme. Well, enough rambling from me.... back to our regularly scheduled discussion! Gary -- Gary Carvell Galaxy Global Corporation http://www.cards.com/home/carvell carvell@{cards.com, sort.ivv.nasa.gov} / 1-304-367-8249 / fax 1-304-367-8223 >From 9fans-outgoing-owner Tue Aug 22 12:18:17 1995 Received: by colossus.cse.psu.edu id <45553>; Tue, 22 Aug 1995 12:06:54 -0400 Received: from galapagos.cse.psu.edu ([130.203.2.12]) by colossus.cse.psu.edu with SMTP id <45552>; Tue, 22 Aug 1995 12:06:37 -0400 Received: by galapagos.cse.psu.edu id <12691>; Tue, 22 Aug 1995 12:06:56 -0400 From: Scott Schwartz To: 9fans Message-Id: <95Aug22.120656edt.12691@galapagos.cse.psu.edu> Date: Tue, 22 Aug 1995 12:06:49 -0400 Sender: owner-9fans Precedence: bulk Reply-To: 9fans Speaking of vga, what card do people recommend? >From 9fans-outgoing-owner Tue Aug 22 13:55:42 1995 Received: by colossus.cse.psu.edu id <45607>; Tue, 22 Aug 1995 13:36:43 -0400 Received: from cannon.ecf.toronto.edu ([128.100.8.5]) by colossus.cse.psu.edu with SMTP id <45593>; Tue, 22 Aug 1995 13:32:42 -0400 Received: by cannon.ecf.toronto.edu id <1408>; Tue, 22 Aug 1995 13:30:20 -0400 From: Steve Kotsopoulos To: 9fans Message-Id: <95Aug22.133020edt.1408@cannon.ecf.toronto.edu> Date: Tue, 22 Aug 1995 13:30:19 -0400 Sender: owner-9fans Precedence: bulk Reply-To: 9fans Scott Schwartz : > Speaking of vga, what card do people recommend? according to "APPENDIX - What We Use - Last Updated 1-Aug-95" at url http://www.ecf.toronto.edu/plan9/clone.html : Subjectively, the Tseng Labs ET4000/W32p gives the best performance under Plan 9, its only drawbacks being the lack of a hardware cursor in 2x8bit mode and a maximum pixel-clock of 135MHz when used with a suitable RAMDAC. The Hercules Stingray 64/Video with the ARK2000pv chip looks good too and doesn't have restrictions on the use of the hardware cursor. Unfortunately we have't been able to get the hardware cursor to work satisfactorily under Plan 9. Don't know why, haven't had time to investigate. There are a number of cards out there using the S3 Trio64 chip, they're cheap and perform well; the single-chip solution cuts out a lot of the guesswork in getting the card to work. >From 9fans-outgoing-owner Tue Aug 22 14:19:37 1995 Received: by colossus.cse.psu.edu id <45544>; Tue, 22 Aug 1995 14:08:55 -0400 Received: from mail1.eworld.com ([192.215.65.17]) by colossus.cse.psu.edu with SMTP id <45595>; Tue, 22 Aug 1995 14:06:32 -0400 Received: from newton.apple.com by hp1.online.apple.com with SMTP (1.37.109.16/16.2) id AA052244604; Tue, 22 Aug 1995 11:03:24 -0700 Received: from [17.205.6.60] (smith-walter.apple.com) by newton.apple.com (4.1/SMI-4.1) id AA08405; Tue, 22 Aug 95 11:03:22 PDT Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 22 Aug 1995 15:03:24 -0400 To: 9fans From: wrs@newton.apple.com (Walter Smith) Subject: Re: Set User (aka su) Sender: owner-9fans Precedence: bulk Reply-To: 9fans >As a side note... has anyone on the Plan 9 list ever used the >Macintosh MPW shell? It is a Unix-like shell combined with a >programmer's text editor. You could select any text at any location in >any editing window, hit Enter, and send it off as a command. Or >conversely edit any command with the full power of the text editor. >This gave you many of the features of the 8 1/2 terminal and Acme... Yes, I use it all the time. I've never understood why this style didn't migrate to Unix/Emacs/etc. systems...seems like there's always some complicated mechanism of copying things to the input line in the shell window or some such thing, instead of just executing the stuff in place. Smalltalk-80 had this years ago, of course. Another little-appreciated feature of MPW is that while a file is open in the editor, the contents of the window _are_ the contents of the file (of course, the file is really still there if you close the window without saving). Unlike Emacs, you don't have to save and load between the edit buffers and the disk all the time. If you redirect output to a file that's open in the editor, the output spits out into the edit window. It's also handy to use a scratch window as an input file. Seems like this would be an easy namespace manipulation in Acme (of course, maybe it already works this way...pardon me if I'm preaching to the choir). - W --------------------------------------------------------------- Walter Smith Internet: wrs@apple.com Newton Software AppleLink: WALTER.SMITH Apple Computer, Inc. +1 408 974 5892 >From 9fans-outgoing-owner Tue Aug 22 14:28:28 1995 Received: by psuvax1.cse.psu.edu id <34278>; Tue, 22 Aug 1995 14:06:47 -0400 Received: from plan9.cs.york.ac.uk ([144.32.33.120]) by psuvax1.cse.psu.edu with SMTP id <34277>; Tue, 22 Aug 1995 14:06:29 -0400 From: forsyth@plan9.cs.york.ac.uk To: 9fans@cs.psu.edu Date: Tue, 22 Aug 1995 14:10:25 -0400 subject: acme and 17/2.0 Message-Id: <95Aug22.140629edt.34277@psuvax1.cse.psu.edu> Sender: owner-9fans Precedence: bulk Reply-To: 9fans after using Acme i've automatically been using the 1+2 cut and 1+3 paste button combinations in the window system 17/2.0; i only just noticed that i was doing it (and that they work). >From 9fans-outgoing-owner Tue Aug 22 17:12:19 1995 Received: by colossus.cse.psu.edu id <45608>; Tue, 22 Aug 1995 17:02:19 -0400 Received: from galapagos.cse.psu.edu ([130.203.2.12]) by colossus.cse.psu.edu with SMTP id <45595>; Tue, 22 Aug 1995 17:02:03 -0400 Received: from localhost by galapagos.cse.psu.edu with SMTP id <12691>; Tue, 22 Aug 1995 17:02:25 -0400 To: 9fans In-reply-to: Your message of "Tue, 22 Aug 1995 13:30:19 EDT." <95Aug22.133020edt.1408@cannon.ecf.toronto.edu> Date: Tue, 22 Aug 1995 17:02:23 -0400 From: Scott Schwartz Message-Id: <95Aug22.170225edt.12691@galapagos.cse.psu.edu> Sender: owner-9fans Precedence: bulk Reply-To: 9fans Steve says: | according to "APPENDIX - What We Use - Last Updated 1-Aug-95" | at url http://www.ecf.toronto.edu/plan9/clone.html : | ... | There are a number of cards out there using the S3 Trio64 chip, they're cheap | and perform well; the single-chip solution cuts out a lot of the guesswork in | getting the card to work. Ok, but which models use the S3 Trio64 chip? The local computer store was pretty unhelpful; I was hoping to order something that is known to work. vgadb lists the "Diamond Stealth 64 DRAM": have people had good results with that, or is the "Hercules PCI Bus Dynamite" the better choice? >From 9fans-outgoing-owner Tue Aug 22 17:36:23 1995 Received: by colossus.cse.psu.edu id <45635>; Tue, 22 Aug 1995 17:26:23 -0400 Received: from postman.ncube.com ([134.242.8.47]) by colossus.cse.psu.edu with SMTP id <45620>; Tue, 22 Aug 1995 17:25:29 -0400 Received: from butler.ncube.com by postman.ncube.com (4.1/SMI-4.1) id AA08584; Tue, 22 Aug 95 14:18:36 PDT Received: from skynet.ncube.com by butler.ncube.com (5.0/SMI-SVR4) id AA28015; Tue, 22 Aug 1995 14:18:32 +0800 Date: Tue, 22 Aug 1995 02:18:32 -0400 From: avg@postman.ncube.com (Vadim Antonov) Message-Id: <9508222118.AA28015@butler.ncube.com> To: 9fans Subject: Re: [comp.os.linux.misc] Help wanted, Plan9 a piece of junk! Content-Length: 1304 Sender: owner-9fans Precedence: bulk Reply-To: 9fans >The only problem is that you need an infinite amount of storage. >A "functionally complete" system must be able to understand all >the file formats of the world (audio, video, data compression, MS >Word documents etc) including ones yet to be devised. Not. Check any math book for the definition of the term. >Look at X windows. It is a system which _tries_ to be functionally >complete. Yet every new release provides yet another batch of ugly >features that were "missing" in the last. You obviously confuse completeness with complexity. May i suggest elementary text on a math logics? The problems of X are exactly because they did poor design of the system, and instead of rethinking it to make things simplier and more orthogonal (loosely speaking, to look for orthogonal basis) they choose to patch it by adding more complexity. In a sense, functional completeness is very close to minimality, since it is hard to build a system which is complete and *not* minimal, as gaining confidence in completeness is becoming harder for larger systems. My own research in O.S. architectures in an attempt to find a complete set of kernel primitives led to a discovery of an architecture which can work even on analog machines or support process communication by means of ICBM exchange :) --vadim >From 9fans-outgoing-owner Tue Aug 22 18:00:05 1995 Received: by colossus.cse.psu.edu id <45595>; Tue, 22 Aug 1995 17:47:55 -0400 Received: from postman.ncube.com ([134.242.8.47]) by colossus.cse.psu.edu with SMTP id <45610>; Tue, 22 Aug 1995 17:47:34 -0400 Received: from butler.ncube.com by postman.ncube.com (4.1/SMI-4.1) id AA09554; Tue, 22 Aug 95 14:47:59 PDT Received: from skynet.ncube.com by butler.ncube.com (5.0/SMI-SVR4) id AA28205; Tue, 22 Aug 1995 14:47:54 +0800 Date: Tue, 22 Aug 1995 02:47:54 -0400 From: avg@postman.ncube.com (Vadim Antonov) Message-Id: <9508222147.AA28205@butler.ncube.com> To: 9fans Subject: BUG in a kernel mkfile Content-Length: 308 Sender: owner-9fans Precedence: bulk Reply-To: 9fans In 2.0 distribution: 1. Can't compile kernel FIX: In file /sys/src/9/boot/mkfile replace lines ar uv $LIBRARY $names rm -f $names with eval ar uvc $LIBRARY $names eval rm -rf $names (Sorry, i discovered it two weeks ago and forgot to post). --vadim >From 9fans-outgoing-owner Tue Aug 22 18:11:37 1995 Received: by colossus.cse.psu.edu id <45609>; Tue, 22 Aug 1995 18:00:46 -0400 Received: from alpha.xerox.com ([13.1.64.93]) by colossus.cse.psu.edu with SMTP id <45512>; Tue, 22 Aug 1995 17:59:28 -0400 Received: from IMPACT.Xerox.COM ([13.2.144.1]) by alpha.xerox.com with SMTP id <14559(5)>; Tue, 22 Aug 1995 14:50:42 PDT Received: from lonewolf.IMPACT.Xerox.COM by IMPACT.Xerox.COM (4.1/SMI-4.1) id AA06882; Tue, 22 Aug 95 14:50:41 PDT Received: by lonewolf.IMPACT.Xerox.COM (5.x/SMI-SVR4) id AA07967; Tue, 22 Aug 1995 14:50:40 -0700 Date: Tue, 22 Aug 1995 17:50:40 -0400 From: bj@impact.xerox.com (Bill Jackson) Message-Id: <9508222150.AA07967@lonewolf.IMPACT.Xerox.COM> To: 9fans Subject: Re: Set User (aka su) X-Sun-Charset: US-ASCII Sender: owner-9fans Precedence: bulk Reply-To: 9fans |> From: forsyth@plan9.cs.york.ac.uk |> |> (after all, Sun's EEPROM has the screen mapped, and did you ever see |> the display and scrolling time on that in the older Sparcs. whew!) I hate to find myself in the possible position of defending Sun on this one, but I would like to point out that there were two very significant reasons for this: (1) folks didn't expect that performance would be an issue, and (2) the code involved was interpreted forth running from EEPROM which require 1 usec/byte fetch. It doesn't take long to figure out where all the time goes... Of course, this little factoid has nothing to do with the current conversation. My preference would also be to cast out support for 'terminals', but I'll concede that it's a bit naive. Also, while I find plan9's user interfaces inhibiting at best, this seems like fertile ground for folks who might be interested in exploring new approaches. -bj >From 9fans-outgoing-owner Tue Aug 22 18:21:41 1995 Received: by colossus.cse.psu.edu id <45512>; Tue, 22 Aug 1995 18:11:13 -0400 Received: from galapagos.cse.psu.edu ([130.203.2.12]) by colossus.cse.psu.edu with SMTP id <45610>; Tue, 22 Aug 1995 17:59:27 -0400 Received: by galapagos.cse.psu.edu id <12728>; Tue, 22 Aug 1995 17:50:01 -0400 From: Scott Schwartz To: 9fans Subject: ether509.c.diff problem Message-Id: <95Aug22.175001edt.12728@galapagos.cse.psu.edu> Date: Tue, 22 Aug 1995 17:49:57 -0400 Sender: owner-9fans Precedence: bulk Reply-To: 9fans Is the diff for ether509.c correct? It looks like some of the changes there have already been applied to the code on the cdrom. Can we get a clean diff from cdrom to current? >From 9fans-outgoing-owner Tue Aug 22 18:39:03 1995 Received: by colossus.cse.psu.edu id <45612>; Tue, 22 Aug 1995 18:25:36 -0400 Received: from plan9.att.com ([192.20.225.252]) by colossus.cse.psu.edu with SMTP id <45610>; Tue, 22 Aug 1995 18:20:58 -0400 From: presotto@plan9.att.com To: 9fans Date: Tue, 22 Aug 1995 17:38:24 -0400 Subject: junk Message-Id: <95Aug22.182058edt.45610@colossus.cse.psu.edu> Sender: owner-9fans Precedence: bulk Reply-To: 9fans >>The only problem is that you need an infinite amount of storage. >>A "functionally complete" system must be able to understand all >>the file formats of the world (audio, video, data compression, MS >>Word documents etc) including ones yet to be devised. > >Not. Check any math book for the definition of the term. OK, the following books have no definition of the term: Theory of Formal Systems, Annals of Mathematical Studies #47 Raymond M Smullyin Theory of Recursive Functions and Effective Computability, McGraw-Hill Series on Higher Mathematics Hartley Rogers Elements of Discrete Mathematics McGraw-Hill Computer Science Series C.L. Liu Linear Algebra Harcourt Brace Jovanovich Michael O'nan Actually, I also did a local library search and it didn't find it there either. There are many definitions of completeness, though they vary drasticly with the mathematical concept being defined (complete graph, complete field, ...). Perhaps you could send us a reference and definition. >From 9fans-outgoing-owner Tue Aug 22 18:49:32 1995 Received: by colossus.cse.psu.edu id <45610>; Tue, 22 Aug 1995 18:38:13 -0400 Received: from galapagos.cse.psu.edu ([130.203.2.12]) by colossus.cse.psu.edu with SMTP id <45634>; Tue, 22 Aug 1995 18:22:23 -0400 Received: by galapagos.cse.psu.edu id <12732>; Tue, 22 Aug 1995 18:20:49 -0400 From: Scott Schwartz To: 9fans Subject: /sys/src/mkfile damaged Message-Id: <95Aug22.182049edt.12732@galapagos.cse.psu.edu> Date: Tue, 22 Aug 1995 18:20:39 -0400 Sender: owner-9fans Precedence: bulk Reply-To: 9fans /sys/src/mkfile's restart target is missing at least a '}'. >From 9fans-outgoing-owner Tue Aug 22 20:26:05 1995 Received: by colossus.cse.psu.edu id <45640>; Tue, 22 Aug 1995 20:15:25 -0400 Received: from plan9.att.com ([192.20.225.252]) by colossus.cse.psu.edu with SMTP id <45613>; Tue, 22 Aug 1995 20:00:26 -0400 From: jmk@plan9.att.com To: 9fans Date: Tue, 22 Aug 1995 19:35:52 -0400 Message-Id: <95Aug22.200026edt.45613@colossus.cse.psu.edu> Sender: owner-9fans Precedence: bulk Reply-To: 9fans I trawled through the offerings at CompUSA a few weeks ago and found the Trio64 on the STB Powergraph 64 and some Number9 card I can't remember the number of (perhaps Motion 330?) as well as the Diamond Stealth 64 DRAM. I think the Hercules Terminator 64 DRAM also uses it. In any case, the chip used was clearly marked on all the boxes I looked at. Remember from the updated aux/vga CHANGES file: 09-Aug-95 ========= 1) data.c mkfile trio64.c (new) vga.h /lib/vgadb Support for Trio32/Trio64. There's a bug at high resolutions causing a thin white stripe to appear between the right edge of the display and the border. I'll be trying to fix this when I can get time on the systems we have with the Trio64, they're all heavily used in Ken's house right now ('high reolution' means > 1024). ------ original message follows ------ >From cse.psu.edu!9fans-outgoing-owner Tue Aug 22 17:17:42 EDT 1995 Received: by colossus.cse.psu.edu id <45608>; Tue, 22 Aug 1995 17:02:19 -0400 Received: from galapagos.cse.psu.edu ([130.203.2.12]) by colossus.cse.psu.edu with SMTP id <45595>; Tue, 22 Aug 1995 17:02:03 -0400 Received: from localhost by galapagos.cse.psu.edu with SMTP id <12691>; Tue, 22 Aug 1995 17:02:25 -0400 To: 9fans@cse.psu.edu In-reply-to: Your message of "Tue, 22 Aug 1995 13:30:19 EDT." <95Aug22.133020edt.1408@cannon.ecf.toronto.edu> Date: Tue, 22 Aug 1995 17:02:23 -0400 From: Scott Schwartz Message-Id: <95Aug22.170225edt.12691@galapagos.cse.psu.edu> Sender: owner-9fans@cse.psu.edu Precedence: bulk Reply-To: 9fans@cse.psu.edu Steve says: | according to "APPENDIX - What We Use - Last Updated 1-Aug-95" | at url http://www.ecf.toronto.edu/plan9/clone.html : | ... | There are a number of cards out there using the S3 Trio64 chip, they're cheap | and perform well; the single-chip solution cuts out a lot of the guesswork in | getting the card to work. Ok, but which models use the S3 Trio64 chip? The local computer store was pretty unhelpful; I was hoping to order something that is known to work. vgadb lists the "Diamond Stealth 64 DRAM": have people had good results with that, or is the "Hercules PCI Bus Dynamite" the better choice? >From 9fans-outgoing-owner Tue Aug 22 21:49:49 1995 Received: by colossus.cse.psu.edu id <45639>; Tue, 22 Aug 1995 21:38:18 -0400 Received: from plan9.att.com ([192.20.225.252]) by colossus.cse.psu.edu with SMTP id <45623>; Tue, 22 Aug 1995 21:30:00 -0400 From: jmk@plan9.att.com To: 9fans Date: Tue, 22 Aug 1995 21:13:17 -0400 Subject: re: ether509.c.diff problem Message-Id: <95Aug22.213000edt.45623@colossus.cse.psu.edu> Sender: owner-9fans Precedence: bulk Reply-To: 9fans It looks like the diff was completely bogus to me. I've replaced it with just a copy of the complete interrupt routine. A diff on the current source would be too much, there's code for the 3C590 which would mean pulling in the PCI support file, etc. ------ original message follows ------ >From cse.psu.edu!9fans-outgoing-owner Tue Aug 22 18:26:46 EDT 1995 Received: by colossus.cse.psu.edu id <45512>; Tue, 22 Aug 1995 18:11:13 -0400 Received: from galapagos.cse.psu.edu ([130.203.2.12]) by colossus.cse.psu.edu with SMTP id <45610>; Tue, 22 Aug 1995 17:59:27 -0400 Received: by galapagos.cse.psu.edu id <12728>; Tue, 22 Aug 1995 17:50:01 -0400 From: Scott Schwartz To: 9fans@cse.psu.edu Subject: ether509.c.diff problem Message-Id: <95Aug22.175001edt.12728@galapagos.cse.psu.edu> Date: Tue, 22 Aug 1995 17:49:57 -0400 Sender: owner-9fans@cse.psu.edu Precedence: bulk Reply-To: 9fans@cse.psu.edu Is the diff for ether509.c correct? It looks like some of the changes there have already been applied to the code on the cdrom. Can we get a clean diff from cdrom to current? >From 9fans-outgoing-owner Tue Aug 22 22:31:52 1995 Received: by colossus.cse.psu.edu id <45620>; Tue, 22 Aug 1995 22:22:05 -0400 Received: from plan9.att.com ([192.20.225.252]) by colossus.cse.psu.edu with SMTP id <45623>; Tue, 22 Aug 1995 21:57:45 -0400 From: jmk@plan9.att.com To: 9fans Date: Tue, 22 Aug 1995 21:18:08 -0400 Subject: re: BUG in a kernel mkfile Message-Id: <95Aug22.215745edt.45623@colossus.cse.psu.edu> Sender: owner-9fans Precedence: bulk Reply-To: 9fans If this is a bug I don't understand how I've ever been able to make a kernel. The distributed mkfile works fine for me. ------ original message follows ------ >From cse.psu.edu!9fans-outgoing-owner Tue Aug 22 18:02:40 EDT 1995 Received: by colossus.cse.psu.edu id <45595>; Tue, 22 Aug 1995 17:47:55 -0400 Received: from postman.ncube.com ([134.242.8.47]) by colossus.cse.psu.edu with SMTP id <45610>; Tue, 22 Aug 1995 17:47:34 -0400 Received: from butler.ncube.com by postman.ncube.com (4.1/SMI-4.1) id AA09554; Tue, 22 Aug 95 14:47:59 PDT Received: from skynet.ncube.com by butler.ncube.com (5.0/SMI-SVR4) id AA28205; Tue, 22 Aug 1995 14:47:54 +0800 Date: Tue, 22 Aug 1995 02:47:54 -0400 From: avg@postman.ncube.com (Vadim Antonov) Message-Id: <9508222147.AA28205@butler.ncube.com> To: 9fans@cse.psu.edu Subject: BUG in a kernel mkfile Content-Length: 308 Sender: owner-9fans@cse.psu.edu Precedence: bulk Reply-To: 9fans@cse.psu.edu In 2.0 distribution: 1. Can't compile kernel FIX: In file /sys/src/9/boot/mkfile replace lines ar uv $LIBRARY $names rm -f $names with eval ar uvc $LIBRARY $names eval rm -rf $names (Sorry, i discovered it two weeks ago and forgot to post). --vadim >From 9fans-outgoing-owner Tue Aug 22 23:37:51 1995 Received: by colossus.cse.psu.edu id <45614>; Tue, 22 Aug 1995 23:26:21 -0400 Received: from Fox.NSTN.Ca ([137.186.128.12]) by colossus.cse.psu.edu with SMTP id <45650>; Tue, 22 Aug 1995 23:11:34 -0400 Received: from [137.186.184.130] (ottawa-ts-30.nstn.ca [137.186.184.130]) by Fox.NSTN.Ca (8.6.10/8.6.10) with SMTP id XAA25281 for <9fans@cse.psu.edu>; Tue, 22 Aug 1995 23:52:00 -0300 Date: Tue, 22 Aug 1995 22:51:29 -0400 From: "Sandy Harris" Message-Id: <91605.sharris@fox.nstn.ca> X-Minuet-Version: Minuet1.0_Beta_14.1 X-POPMail-Charset: English To: 9fans Subject: Re: diff|patch Sender: owner-9fans Precedence: bulk Reply-To: 9fans On Mon, 21 Aug 1995 05:08:24 -0400, Vadim Antonov wrote: >As for the patches, >may i propose that all patches be published in format like that: > > ed - /sys/src/cmd/mycmd.c << '/&' > .... output of diff -e > /& Sounds sensible. >and applied only to the CD-ROM code (i.e. no patches on patches). Yes! Absolutely. -- Sandy Harris sharris@fox.nstn.ca >From 9fans-outgoing-owner Wed Aug 23 02:33:04 1995 Received: by colossus.cse.psu.edu id <45634>; Wed, 23 Aug 1995 02:20:05 -0400 Received: from sangam.ncst.ernet.in ([144.16.11.1]) by colossus.cse.psu.edu with SMTP id <45667>; Wed, 23 Aug 1995 02:04:30 -0400 Received: from iisc.ernet.in (iisc.iisc.ernet.in [144.16.64.3]) by sangam.ncst.ernet.in (8.6.12/8.6.6) with SMTP id LAA02746 for <9fans@cse.psu.edu>; Wed, 23 Aug 1995 11:11:57 +0530 Received: from sasi.ernet.in by iisc.ernet.in (ERNET-IISc/SMI-4.1) id AA09615; Wed, 23 Aug 95 11:15:33+0530 Received: from india29.sasi by sasi.ernet.in (4.1/SMI-4.1) id AA12922; Wed, 23 Aug 95 11:05:31+050 From: kp@sasi.ernet.in (Kiran Pamnany) Received: (kp@localhost) by india29.sasi (8.6.12/SMI-4.1) id LAA28840 for 9fans@cse.psu.edu; Wed, 23 Aug 1995 11:05:30 +0500 Date: Wed, 23 Aug 1995 02:05:30 -0400 Message-Id: <199508230605.LAA28840@india29.sasi> To: 9fans Subject: vga Sender: owner-9fans Precedence: bulk Reply-To: 9fans Speaking of vgas, my machine has a Diamond S64 DRAM. However, the hex dump at 0xC000:0045 says 'Stealth 64 DRAM Vers. 2.01' and the entry in /lib/vgadb says 'Vers 2.02'. I tried adding another entry with 'Vers. 2.01' leaving all else unchanged but alas,, it didn't work. My knowledge of video and video hardware is infinitesimal, so if anyone has had any luck with this, I'd appreciate some info. Thanx, Kiran >From 9fans-outgoing-owner Wed Aug 23 04:55:40 1995 Received: by colossus.cse.psu.edu id <45646>; Wed, 23 Aug 1995 04:43:25 -0400 Received: from symbionics.co.uk ([158.43.6.17]) by colossus.cse.psu.edu with SMTP id <45675>; Wed, 23 Aug 1995 04:08:20 -0400 Received: from sympc143 ([194.32.100.46]) by symbionics.co.uk (4.1/SMI-4.1) id AA10927; Wed, 23 Aug 95 08:40:36 BST Message-Id: <9508230740.AA10927@symbionics.co.uk> Comments: Authenticated sender is From: "Nigel Roles" Organization: Symbionics Communications To: 9fans Date: Wed, 23 Aug 1995 04:40:34 -0400 Subject: NCR 53C810 PCI SCSI Controller Priority: normal X-Mailer: Pegasus Mail for Windows (v2.01) Sender: owner-9fans Precedence: bulk Reply-To: 9fans This is probably premature, but if anyone is interested in a driver for this (or it's alter egos, the 53C815, 20, 25, Symbios 53C810A etc) let me know. I have somehing which nearly works. >From 9fans-outgoing-owner Wed Aug 23 05:07:16 1995 Received: by colossus.cse.psu.edu id <45654>; Wed, 23 Aug 1995 04:54:47 -0400 Received: from symbionics.co.uk ([158.43.6.17]) by colossus.cse.psu.edu with SMTP id <45668>; Wed, 23 Aug 1995 04:08:18 -0400 Received: from sympc143 ([194.32.100.46]) by symbionics.co.uk (4.1/SMI-4.1) id AA10918; Wed, 23 Aug 95 08:37:00 BST Message-Id: <9508230737.AA10918@symbionics.co.uk> Comments: Authenticated sender is From: "Nigel Roles" Organization: Symbionics Communications To: 9fans Date: Wed, 23 Aug 1995 04:36:58 -0400 Subject: Re: Set User (aka su) Priority: normal X-Mailer: Pegasus Mail for Windows (v2.01) Sender: owner-9fans Precedence: bulk Reply-To: 9fans > > |> From: forsyth@plan9.cs.york.ac.uk > |> > |> (after all, Sun's EEPROM has the screen mapped, and did you ever see > |> the display and scrolling time on that in the older Sparcs. whew!) > > I hate to find myself in the possible position of defending Sun > on this one, but I would like to point out that there were two very > significant reasons for this: (1) folks didn't expect that performance > would be an issue, and (2) the code involved was interpreted forth > running from EEPROM which require 1 usec/byte fetch. It doesn't Why is interpreted Forth a defence? Sounds more like a plea bargain. >From 9fans-outgoing-owner Wed Aug 23 06:08:56 1995 Received: by colossus.cse.psu.edu id <45648>; Wed, 23 Aug 1995 05:51:45 -0400 Received: from staff.cs.su.OZ.AU ([129.78.8.1]) by colossus.cse.psu.edu with SMTP id <45683>; Wed, 23 Aug 1995 05:07:06 -0400 Received: from suede.sw.oz.au by staff.cs.su.OZ.AU (mail from jeremy for 9fans@cse.psu.edu) with MHSnet (insertion MHSnet site: swallow.sw.oz.au); Wed, 23 Aug 1995 19:05:43 +1000 Received: from suede.sw.oz.au by swallow.sw.oz.au with SMTP id AA19400; Wed, 23 Aug 95 19:05:30 EST (4.1/Unixware) (from jeremy@suede.sw.oz.au for 9fans@cse.psu.edu) Received: by suede.sw.oz.au id AA19450; Wed, 23 Aug 1995 19:08:34 +1000 (5.x/1.34) (from jeremy@suede.sw.oz.au for 9fans@cse.psu.edu) From: "Jeremy Fitzhardinge" Message-Id: <9508231908.ZM19448@suede.sw.oz.au> Date: Wed, 23 Aug 1995 20:08:33 -0400 In-Reply-To: "Nigel Roles" "NCR 53C810 PCI SCSI Controller" (Aug 23, 4:40am) References: <9508230740.AA10927@symbionics.co.uk> X-Face: '6U=%Tv\k1l-:?\$C[D@G 7(vl~w8&y}!f\bh#wL#n,TGKh>T.c7eT5-y)Hl'i;A1z$9?*lD.k}yqshddFb l[EC}c=;uc%x'}uh3E91p&oEFrom 9fans-outgoing-owner Wed Aug 23 07:14:34 1995 Received: by colossus.cse.psu.edu id <45668>; Wed, 23 Aug 1995 07:02:03 -0400 Received: from alf.zfn.uni-bremen.de ([134.102.20.22]) by colossus.cse.psu.edu with SMTP id <45675>; Wed, 23 Aug 1995 06:38:20 -0400 Received: from blue.lrw.uni-bremen.de by alf.zfn.uni-bremen.de (AIX 3.2/UCB 5.64/4.940318) id AA43041; Wed, 23 Aug 1995 11:39:41 +0200 Received: from black.lrw.uni-bremen.de by lrw.uni-bremen.de (5.0/SMI-SVR4) id AA29220; Wed, 23 Aug 1995 11:43:49 +0200 Received: by black.lrw.uni-bremen.de (5.0/SMI-SVR4) id AA03512; Wed, 23 Aug 1995 11:41:32 +0200 Date: Wed, 23 Aug 1995 05:41:32 -0400 From: a82@blue.lrw.uni-bremen.de (Henner Gratz) Message-Id: <9508230941.AA03512@black.lrw.uni-bremen.de> To: 9fans Subject: European price for Plan9 Content-Length: 639 Sender: owner-9fans Precedence: bulk Reply-To: 9fans Hello everybody! Today, I've got a call from my bookstore, they told me, that H&B wants 297 British Pounds for the full Plan 9 kit (without VAT). It's not as much as I expected, but more than enough :*) Tschuess, Henner -- =============================================================================== Henner Gratz Email: a82@lrw.uni-bremen.de Leeuwarder Str. 16A Fax (at home): +49-(0)421-58 52 10 D-28259 Bremen Tel (at home): +49-(0)421-58 51 84 GERMANY =============================================================================== >From 9fans-outgoing-owner Wed Aug 23 08:35:18 1995 Received: by colossus.cse.psu.edu id <45666>; Wed, 23 Aug 1995 08:22:26 -0400 Received: from plan9.cs.york.ac.uk ([144.32.33.120]) by colossus.cse.psu.edu with SMTP id <45667>; Wed, 23 Aug 1995 07:57:44 -0400 From: forsyth@plan9.cs.york.ac.uk To: 9fans Date: Wed, 23 Aug 1995 07:36:15 -0400 Subject: re: European price for Plan9 Message-Id: <95Aug23.075744edt.45667@colossus.cse.psu.edu> Sender: owner-9fans Precedence: bulk Reply-To: 9fans HBJ here never rang me back as promised. i'll try them again. >>297 British Pounds for the full Plan 9 kit (without VAT). It's not as note that in the UK, unlike much of the rest of the EU, VAT should not be charged on the books, since books are not chargeable, but the software -- CDROM and diskettes -- will be chargeable. >From 9fans-outgoing-owner Wed Aug 23 08:46:08 1995 Received: by psuvax1.cse.psu.edu id <34211>; Wed, 23 Aug 1995 08:13:46 -0400 Received: from plan9.cs.york.ac.uk ([144.32.33.120]) by psuvax1.cse.psu.edu with SMTP id <34203>; Wed, 23 Aug 1995 08:12:47 -0400 From: forsyth@plan9.cs.york.ac.uk To: 9fans@cs.psu.edu Date: Wed, 23 Aug 1995 08:01:11 -0400 subject: HBJ (UK) Message-Id: <95Aug23.081247edt.34203@psuvax1.cse.psu.edu> Sender: owner-9fans Precedence: bulk Reply-To: 9fans i have just spoken to a helpful woman at HBJ in London. the full kit will be published in the UK in June 1996 (ie, next year), and the estimated price will be 257 pounds sterling ex. VAT. (she then gave me a price with VAT that obviously included the books in the calculation, but i'll wait until next year to sort that out). the books are `not available' in the UK until then. as far as she knows, until next year all orders from the UK should be placed directly with the US, at +1 407 345 3800 (which is indeed the international number on the plan9.att.com web page). she also said that she doesn't deal with non-UK orders (eg, German bookshops). those are dealt with by someone else, and she didn't know what they were advising. (since the books are not published here, however, it seems that they have not much choice but just to turn round and order in from the US as required.) >From 9fans-outgoing-owner Wed Aug 23 09:07:19 1995 Received: by colossus.cse.psu.edu id <45613>; Wed, 23 Aug 1995 08:52:36 -0400 Received: from hal ([192.102.161.37]) by colossus.cse.psu.edu with SMTP id <45682>; Wed, 23 Aug 1995 08:17:51 -0400 Received: from po.isst (po.do.isst.fhg.de [192.102.161.66]) by hal (8.6.9/8.6.9) with SMTP id NAA22791 for <9fans@cse.psu.edu>; Wed, 23 Aug 1995 13:51:23 +0200 Date: Wed, 23 Aug 1995 07:51:23 -0400 Message-Id: <199508231151.NAA22791@hal> Received: by po.isst (4.1/SMI-4.1) id AA12533; Wed, 23 Aug 95 13:51:15 +0200 From: Dirk Vleugels To: 9fans Subject: Re: European price for Plan9 In-Reply-To: <9508230941.AA03512@black.lrw.uni-bremen.de> References: <9508230941.AA03512@black.lrw.uni-bremen.de> Sender: owner-9fans Precedence: bulk Reply-To: 9fans >>>>> "Henner" == Henner Gratz writes: Henner> Hello everybody! Today, I've got a call from my Henner> bookstore, they told me, that H&B wants 297 British Pounds Henner> for the full Plan 9 kit (without VAT). It's not as much as Henner> I expected, but more than enough :*) Oha! There is nothing like a student version, isn't it? Maybe i sell my car :) Dirk >From 9fans-outgoing-owner Wed Aug 23 14:14:57 1995 Received: by colossus.cse.psu.edu id <45610>; Wed, 23 Aug 1995 13:54:12 -0400 Received: from plan9.att.com ([192.20.225.252]) by colossus.cse.psu.edu with SMTP id <45607>; Wed, 23 Aug 1995 13:53:51 -0400 From: bobf@plan9.att.com To: 9fans Date: Wed, 23 Aug 1995 13:51:44 -0400 Subject: re: BUG in a kernel mkfile Message-Id: <95Aug23.135351edt.45607@colossus.cse.psu.edu> Sender: owner-9fans Precedence: bulk Reply-To: 9fans > From: postman.ncube.com!avg (Vadim Antonov) > > FIX: In file /sys/src/9/boot/mkfile > replace lines > > ar uv $LIBRARY $names > rm -f $names > > with > > eval ar uvc $LIBRARY $names > eval rm -rf $names the mkfile is correct as released. >From 9fans-outgoing-owner Wed Aug 23 17:12:04 1995 Received: by colossus.cse.psu.edu id <45668>; Wed, 23 Aug 1995 17:03:23 -0400 Received: from postman.ncube.com ([134.242.8.47]) by colossus.cse.psu.edu with SMTP id <45666>; Wed, 23 Aug 1995 17:03:07 -0400 Received: from butler.ncube.com by postman.ncube.com (4.1/SMI-4.1) id AA17749; Wed, 23 Aug 95 14:03:56 PDT Received: from skynet.ncube.com by butler.ncube.com (5.0/SMI-SVR4) id AA02891; Wed, 23 Aug 1995 14:03:49 +0800 Date: Wed, 23 Aug 1995 02:03:49 -0400 From: avg@postman.ncube.com (Vadim Antonov) Message-Id: <9508232103.AA02891@butler.ncube.com> To: 9fans Subject: re: BUG in a kernel mkfile Content-Length: 372 Sender: owner-9fans Precedence: bulk Reply-To: 9fans Strange -- i cannot reproduce it. When i first did it i used 1.0 binaries in /386/bin, though; and loaded newer ones later. The problem was that everything in $names was one space-separated string, not an array. Sorry for the false alarm. --vadim If this is a bug I don't understand how I've ever been able to make a kernel. The distributed mkfile works fine for me. >From 9fans-outgoing-owner Wed Aug 23 20:08:16 1995 Received: by colossus.cse.psu.edu id <45669>; Wed, 23 Aug 1995 19:58:21 -0400 Received: from chelm.cs.nmt.edu ([129.138.6.50]) by colossus.cse.psu.edu with SMTP id <45737>; Wed, 23 Aug 1995 19:57:48 -0400 Received: (from yodaiken@localhost) by chelm.cs.nmt.edu (8.6.8.1/8.6.6) id JAA07343 for 9fans@cse.psu.edu; Wed, 23 Aug 1995 09:13:46 -0600 Message-Id: <199508231513.JAA07343@chelm.cs.nmt.edu> From: yodaiken@sphinx.cs.nmt.edu (Victor Yodaiken) Date: Wed, 23 Aug 1995 11:13:46 -0400 In-Reply-To: avg@postman.ncube.com (Vadim Antonov) "Re: [comp.os.linux.misc] Help wanted, Plan9 a piece of junk!" (Aug 22, 2:18am) reply_to: yodaiken@chelm.nmt.edu X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: 9fans Subject: Re: [comp.os.linux.misc] Help wanted, Plan9 a piece of junk! Sender: owner-9fans Precedence: bulk Reply-To: 9fans On Aug 22, 2:18am, Vadim Antonov wrote: Subject: Re: [comp.os.linux.misc] Help wanted, Plan9 a piece of junk! >My own research in O.S. architectures in an attempt to find >a complete set of kernel primitives led to a discovery of an >architecture which can work even on analog machines or support >process communication by means of ICBM exchange :) This was certainly a fad in OS design for a while, but the result indicates that the clean simple complete set of kernel primitives may not exist. >From 9fans-outgoing-owner Wed Aug 23 20:17:11 1995 Received: by colossus.cse.psu.edu id <45671>; Wed, 23 Aug 1995 20:07:34 -0400 Received: from alpha.xerox.com ([13.1.64.93]) by colossus.cse.psu.edu with SMTP id <45774>; Wed, 23 Aug 1995 19:58:04 -0400 Received: from reynaldo.parc.xerox.com ([13.2.116.96]) by alpha.xerox.com with SMTP id <14571(4)>; Wed, 23 Aug 1995 08:31:38 PDT Received: from localhost by reynaldo.parc.xerox.com with SMTP id <34952>; Wed, 23 Aug 1995 08:31:31 -0700 To: 9fans cc: kerch@parc.xerox.com Subject: Re: Set User (aka su) In-reply-to: Your message of "Wed, 23 Aug 95 01:36:58 PDT." <9508230737.AA10918@symbionics.co.uk> Date: Wed, 23 Aug 1995 11:31:20 -0400 From: Berry Kercheval Message-Id: <95Aug23.083131pdt.34952@reynaldo.parc.xerox.com> Sender: owner-9fans Precedence: bulk Reply-To: 9fans >>>"Nigel Roles" said: > > I hate to find myself in the possible position of defending Sun > > on this one, but I would like to point out that there were two very > > significant reasons for this: (1) folks didn't expect that performance > > would be an issue, and (2) the code involved was interpreted forth > > running from EEPROM which require 1 usec/byte fetch. It doesn't > > Why is interpreted Forth a defence? Sounds more like a plea bargain. Interpreted Forth is not the defence, it's the excuse. The defence is most people don't live in the raw console; they start some kind of window system immediately upon booting; some even start it automatically. And, by the way, it's not just the interpreted code that makes it slow; the raw console bitmap font lives in that EEPROM too, and the stock console driver hits it for every row of every character. A friend of mine wrote a little program that copies the code to RAM and forks a new shell for you; this makes running on the console ENORMOUSLY faster. I like to use it when I'm debugging a driver that I expect to crash and don't want to take the time to start X up. Later Sun EEPROM code does this (copy font to RAM) too; it may even copy out its own code, I'm not sure. It gets a lot snappier. ....but this is all irrelevant to 9fans. Maybe when my CDROM comes I can be more relevant :-) --berry Berry Kercheval :: Xerox Palo Alto Research Center >From 9fans-outgoing-owner Wed Aug 23 20:56:42 1995 Received: by colossus.cse.psu.edu id <45669>; Wed, 23 Aug 1995 20:50:04 -0400 Received: from igw.merck.com ([155.91.1.1]) by colossus.cse.psu.edu with SMTP id <45665>; Wed, 23 Aug 1995 20:49:44 -0400 Received: by igw.merck.com; Wed, 23 Aug 95 20:55:55 -0400 Message-Id: <9508240055.AA09405@igw.merck.com> From: anthony_starks@merck.com (Anthony Starks) Subject: libpanel missing? To: 9fans Date: Wed, 23 Aug 1995 20:35:54 -0400 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 115 Sender: owner-9fans Precedence: bulk Reply-To: 9fans I cannot seem to locate libpanel.a in the FTP-able PC distribution. Was is left out on purpose? -- Anthony >From 9fans-outgoing-owner Wed Aug 23 22:14:55 1995 Received: by colossus.cse.psu.edu id <45665>; Wed, 23 Aug 1995 22:04:59 -0400 Received: from mail.Germany.EU.net ([192.76.144.65]) by colossus.cse.psu.edu with SMTP id <45675>; Wed, 23 Aug 1995 22:04:42 -0400 Received: by mail.Germany.EU.net with UUCP (5.51:31/EUnetD-2.5.2.a) via EUnet id EAA12021; Thu, 24 Aug 1995 04:07:26 +0200 Received: from mwtech by shakti.rent-a-guru.de with UUCP (5.65+/MIKROS-5.0) id AA11121; Wed, 23 Aug 95 20:49:01 +0200 Received: by mwtech.rent-a-guru.de (5.65+/MIKROS-5.0) id AA06853; Wed, 23 Aug 95 17:51:29 GMT From: Martin Weitzel Message-Id: <9508231751.AA06853@mwtech.rent-a-guru.de> Subject: Ordering from Germany (was: Re: HCB(UK)) To: 9fans Date: Wed, 23 Aug 1995 13:51:28 -0400 In-Reply-To: <95Aug23.081247edt.34203@psuvax1.cse.psu.edu> from "forsyth@plan9.cs.york.ac.uk" at Aug 23, 95 08:01:11 am X-Mailer: ELM [version 2.4 PL20] Content-Type: text Content-Length: 1101 Sender: owner-9fans Precedence: bulk Reply-To: 9fans [...] > she also said that she doesn't deal with non-UK orders (eg, German bookshops). > those are dealt with by someone else, and she didn't know what > they were advising. (since the books are not published here, > however, it seems that they have not much choice but just to > turn round and order in from the US as required.) I live in Germany and ordered the Plan 9 Book+CD-ROM-Set through HCB's international phone number as given in the WWW page. This was early in August, my order was shipped on August 11-th, and arrived on August 15-th. The price was $350 as announced in the WWW page, so the parcel contained no final invoice. Because of that I cannot cannot tell exactly how much will be charged for postage, but for "rushed delivery" I expect $30 - $50. BTW: The woman at HCB was helpful and friendly. She knew of the Plan 9 Book+CD-ROM-Set before I had given her the ISBN. My poor English (esp. when spoken) was sufficient and there was no need for a written or faxed order (some German companies do not accept phone orders when you don't already have a customer ID). --Martin >From 9fans-outgoing-owner Wed Aug 23 22:33:14 1995 Received: by colossus.cse.psu.edu id <45677>; Wed, 23 Aug 1995 22:25:45 -0400 Received: from postman.ncube.com ([134.242.8.47]) by colossus.cse.psu.edu with SMTP id <45675>; Wed, 23 Aug 1995 22:25:29 -0400 Received: from butler.ncube.com by postman.ncube.com (4.1/SMI-4.1) id AA25992; Wed, 23 Aug 95 19:26:10 PDT Received: from skynet.ncube.com by butler.ncube.com (5.0/SMI-SVR4) id AA04254; Wed, 23 Aug 1995 19:26:05 +0800 Date: Wed, 23 Aug 1995 07:26:05 -0400 From: avg@postman.ncube.com (Vadim Antonov) Message-Id: <9508240226.AA04254@butler.ncube.com> To: 9fans Subject: multi-user terminal Content-Length: 8285 Sender: owner-9fans Precedence: bulk Reply-To: 9fans The following changes effectively separate the CPU server functionality and terminal functionality, so the console of a CPU server can be used as a "normal" terminal. Effectively, it allows to run a full-blown Plan9 system on a stand-alone machine. The kernel modifications provide interface to the new device #c/termowner, which is the same as hostowner but affects only devices associated with the terminal interface (keyboard, screen, floppy). Only hostowner can write to termowner, and writing to hostowner changes termowner as well. There's also a new revision of init which asks the user name and performs authentication; for the hostowner both #c/key and the auth. server are attempted (so if auth. server is dead you still can log into the machine as an owner). To log out of 81/2 you've got to kill it. You know where to complain. Also, to use that functionality you may want to modify /rc/bin/cpurc to set up VGA and mouse before doing other things (before, to allow for diagnostics to stay on the screen). --vadim echo /sys/src/cmd/init.c... cp /sys/src/cmd/init.c /sys/src/cmd/init.c.old ed - /sys/src/cmd/init.c <