9fans - fans of the OS Plan 9 from Bell Labs
 help / color / mirror / Atom feed
* [9fans] (no subject)
@ 2002-11-18 21:39 bwc
  0 siblings, 0 replies; 433+ messages in thread
From: bwc @ 2002-11-18 21:39 UTC (permalink / raw)
  To: 9fans

I've been getting so much junk mail that I'm resorting to
a draconian mechanism to avoid the mail.  In order
to make sure that there's a real person sending mail, I'm
asking you to explicitly enable access.  To do that, send
mail to bwc at this domain with the token:
	PGyKN
in the subject of your mail message.  After that, you
shouldn't get any bounces from me.  Sorry if this is
an inconvenience.

----------------
Original message
----------------
Received: from mail.cse.psu.edu ([130.203.4.6]) by edsac; Mon Nov 18 16:39:55 EST 2002
Received: from psuvax1.cse.psu.edu (psuvax1.cse.psu.edu [130.203.23.6])
	by mail.cse.psu.edu (CSE Mail Server) with ESMTP
	id B0D6819A7A; Mon, 18 Nov 2002 16:38:11 -0500 (EST)
Delivered-To: 9fans@cse.psu.edu
Received: from edsac.borf.com (borf.com [209.179.94.84])
	by mail.cse.psu.edu (CSE Mail Server) with ESMTP id 5842619A0D
	for <9fans@cse.psu.edu>; Mon, 18 Nov 2002 16:37:33 -0500 (EST)
Message-ID: <3b9bacdf3cb60b9d2af5b5c718859c0f@coraid.com>
From: bwc@coraid.com
To: 9fans@cse.psu.edu
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Subject: [9fans] (no subject)
Sender: 9fans-admin@cse.psu.edu
Errors-To: 9fans-admin@cse.psu.edu
X-BeenThere: 9fans@cse.psu.edu
X-Mailman-Version: 2.0.11
Precedence: bulk
Reply-To: 9fans@cse.psu.edu
List-Id: Fans of the OS Plan 9 from Bell Labs <9fans.cse.psu.edu>
List-Archive: <https://lists.cse.psu.edu/archives/9fans/>
Date: Mon, 18 Nov 2002 16:39:00 -0500

I've been getting so much junk mail that I'm resorting to
a draconian mechanism to avoid the mail.  In order
to make sure that there's a real person sending mail, I'm
asking you to explicitly enable access.  To do that, send
mail to bwc at this domain with the token:
	PGyKN
in the subject of your mail message.  After that, you
shouldn't get any bounces from me.  Sorry if this is
an inconvenience.

----------------
Original message
----------------
Received: from mail.cse.psu.edu ([130.203.4.6]) by edsac; Mon Nov 18 16:38:59 EST 2002
Received: from psuvax1.cse.psu.edu (psuvax1.cse.psu.edu [130.203.23.6])
	by mail.cse.psu.edu (CSE Mail Server) with ESMTP
	id 74DDF19A69; Mon, 18 Nov 2002 16:37:12 -0500 (EST)
Delivered-To: 9fans@cse.psu.edu
Received: from magnum.cooper.edu (magnum.cooper.edu [199.98.16.4])
	by mail.cse.psu.edu (CSE Mail Server) with SMTP id 7769C19A6A
	for <9fans@cse.psu.edu>; Mon, 18 Nov 2002 16:36:05 -0500 (EST)
Received: from robin.cooper.edu by magnum.cooper.edu with SMTP id AA26960
  (5.65c/IDA-1.4.4 for <9fans@cse.psu.edu>); Mon, 18 Nov 2002 16:37:44 -0500
Received: from localhost by robin.cooper.edu (SMI-8.6/SMI-SVR4)
	id QAA07906; Mon, 18 Nov 2002 16:36:00 -0500
From: Joel Salomon <salomo3@cooper.edu>
To: 9fans@cse.psu.edu
Message-Id: <Pine.SOL.3.96.1021118163207.7823A-100000@robin.cooper.edu>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Subject: [9fans] how to avoid a memset() optimization
Sender: 9fans-admin@cse.psu.edu
Errors-To: 9fans-admin@cse.psu.edu
X-BeenThere: 9fans@cse.psu.edu
X-Mailman-Version: 2.0.11
Precedence: bulk
Reply-To: 9fans@cse.psu.edu
List-Id: Fans of the OS Plan 9 from Bell Labs <9fans.cse.psu.edu>
List-Archive: <https://lists.cse.psu.edu/archives/9fans/>
Date: Mon, 18 Nov 2002 16:36:00 -0500 (EST)

Andrew Simmons wrote:
>http://groups.google.com/groups?threadm=oA47GsAf7M29EwY0%40robinton.demon.co.uk
this did not work for me, try:
http://groups.google.com/groups?hl=en&lr=lang_en&ie=UTF-8&threadm=3DD35AAB.AA37D5CA%40monitorbm.co.nz&rnum=1
(should be all on one line)

--Joel
______________________________________________________
Due to economic circumstances, the light at the end of
the tunnel has been turned off.



^ permalink raw reply	[flat|nested] 433+ messages in thread

* Re: [9fans] (no subject)
  2018-04-02 15:27 Steve Simon
@ 2018-04-02 21:08 ` Digby R.S. Tarvin
  0 siblings, 0 replies; 433+ messages in thread
From: Digby R.S. Tarvin @ 2018-04-02 21:08 UTC (permalink / raw)
  To: Fans of the OS Plan 9 from Bell Labs

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

I'd certainly be happy to give it a good home if nobody else has claimed it.

digbyt42@gmail.com if you want to discuss logistics off the list...

Digby.

On 2 April 2018 at 16:27, Steve Simon <steve@quintile.net> wrote:

> Hi,
>
> I am in the Uk, and moving house.
>
> t have an HP T5325 Thin client which uses the
> same Marvel chipset as the guruplug.
> http://www.parkytowers.me.uk/thin/hp/t5325/index.shtml
>
> Someone got as far as getting one to net boot plan9 but
> didn't (If I remember correctly) get the graphics working.
> http://thread.gmane.org/gmane.os.plan9.general/72588
>
> There is also an SATA interface which can be accessed with
> a little soldering.
> https://habrahabr.ru/post/260631/
>
>
> Free to anyone who wants it - I may ask for a postage
> contribution if you are far from me. Be quick or it goes
> into the skip.
>
> -Steve
>
>

[-- Attachment #2: Type: text/html, Size: 1679 bytes --]

^ permalink raw reply	[flat|nested] 433+ messages in thread

* [9fans] (no subject)
@ 2018-04-02 15:27 Steve Simon
  2018-04-02 21:08 ` Digby R.S. Tarvin
  0 siblings, 1 reply; 433+ messages in thread
From: Steve Simon @ 2018-04-02 15:27 UTC (permalink / raw)
  To: 9front, 9fans

Hi,

I am in the Uk, and moving house.

t have an HP T5325 Thin client which uses the
same Marvel chipset as the guruplug.
http://www.parkytowers.me.uk/thin/hp/t5325/index.shtml

Someone got as far as getting one to net boot plan9 but
didn't (If I remember correctly) get the graphics working.
http://thread.gmane.org/gmane.os.plan9.general/72588

There is also an SATA interface which can be accessed with
a little soldering.
https://habrahabr.ru/post/260631/


Free to anyone who wants it - I may ask for a postage
contribution if you are far from me. Be quick or it goes
into the skip.

-Steve



^ permalink raw reply	[flat|nested] 433+ messages in thread

* Re: [9fans] (no subject)
  2018-01-04 20:11 Steve Simon
  2018-01-04 20:22 ` Lyndon Nerenberg
@ 2018-01-04 23:37 ` Greg Lewin
  1 sibling, 0 replies; 433+ messages in thread
From: Greg Lewin @ 2018-01-04 23:37 UTC (permalink / raw)
  To: Fans of the OS Plan 9 from Bell Labs

I don't know if this is such common knowledge that nobody has bothered
to mention it (please tell me either way), but much of that is now at

http://9p.io/

http://9p.io/plan9/index.html

and a newer one ?
https://s3-us-west-2.amazonaws.com/belllabs-microsite-plan9/plan9.html



was http://sources.cs.bell-labs.com materially different from these?



^ permalink raw reply	[flat|nested] 433+ messages in thread

* Re: [9fans] (no subject)
  2018-01-04 22:27     ` Joseph Stewart
@ 2018-01-04 23:22       ` Rob Pike
  0 siblings, 0 replies; 433+ messages in thread
From: Rob Pike @ 2018-01-04 23:22 UTC (permalink / raw)
  To: Fans of the OS Plan 9 from Bell Labs

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

What's this? https://plan9.io/



On Fri, Jan 5, 2018 at 9:27 AM, Joseph Stewart <joseph.stewart@gmail.com>
wrote:

> Someone (not me) should make a 9p to S3 service and put all the goodies
> there.
> -joe
>
> On Thu, Jan 4, 2018 at 1:20 PM, Steve Simon <steve@quintile.net> wrote:
>
>> I found the old addresses here:
>>
>> https://dnshistory.org
>>
>> plan9.bell-labs.com was 204.178.31.16
>> and sources.cs.bell-labs.com was 204.178.31.32
>>
>> Both gone too, its not just DNS.
>>
>> I think it has fallen off its perch,
>> it is are pine-ing for the fjords,
>> it is an ex OS research group.
>>
>> -Steve
>>
>>
>

[-- Attachment #2: Type: text/html, Size: 1655 bytes --]

^ permalink raw reply	[flat|nested] 433+ messages in thread

* Re: [9fans] (no subject)
  2018-01-04 21:20   ` Steve Simon
@ 2018-01-04 22:27     ` Joseph Stewart
  2018-01-04 23:22       ` Rob Pike
  0 siblings, 1 reply; 433+ messages in thread
From: Joseph Stewart @ 2018-01-04 22:27 UTC (permalink / raw)
  To: Fans of the OS Plan 9 from Bell Labs

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

Someone (not me) should make a 9p to S3 service and put all the goodies
there.
-joe

On Thu, Jan 4, 2018 at 1:20 PM, Steve Simon <steve@quintile.net> wrote:

> I found the old addresses here:
>
> https://dnshistory.org
>
> plan9.bell-labs.com was 204.178.31.16
> and sources.cs.bell-labs.com was 204.178.31.32
>
> Both gone too, its not just DNS.
>
> I think it has fallen off its perch,
> it is are pine-ing for the fjords,
> it is an ex OS research group.
>
> -Steve
>
>

[-- Attachment #2: Type: text/html, Size: 1105 bytes --]

^ permalink raw reply	[flat|nested] 433+ messages in thread

* Re: [9fans] (no subject)
  2018-01-04 20:22 ` Lyndon Nerenberg
@ 2018-01-04 21:20   ` Steve Simon
  2018-01-04 22:27     ` Joseph Stewart
  0 siblings, 1 reply; 433+ messages in thread
From: Steve Simon @ 2018-01-04 21:20 UTC (permalink / raw)
  To: 9fans

I found the old addresses here:

https://dnshistory.org

plan9.bell-labs.com was 204.178.31.16
and sources.cs.bell-labs.com was 204.178.31.32

Both gone too, its not just DNS.

I think it has fallen off its perch,
it is are pine-ing for the fjords,
it is an ex OS research group.

-Steve



^ permalink raw reply	[flat|nested] 433+ messages in thread

* Re: [9fans] (no subject)
  2018-01-04 20:11 Steve Simon
@ 2018-01-04 20:22 ` Lyndon Nerenberg
  2018-01-04 21:20   ` Steve Simon
  2018-01-04 23:37 ` Greg Lewin
  1 sibling, 1 reply; 433+ messages in thread
From: Lyndon Nerenberg @ 2018-01-04 20:22 UTC (permalink / raw)
  To: Fans of the OS Plan 9 from Bell Labs

> I haven't tried for a few weeks but sources.cs.bell-labs.com
> has gone (from DNS), I don't know about the server behind it
> as I never kept a record of the IP address.
>
> has the labs server gone for good? (RIP).

The entire cs.bell-labs.com domain is gone.

And given that bell-labs.com has now outsourced their email to
outlook.com, I think we can safely say the stake has well and truly been
driven through the heart of this once grand institution.

--lyndon




^ permalink raw reply	[flat|nested] 433+ messages in thread

* [9fans] (no subject)
@ 2018-01-04 20:11 Steve Simon
  2018-01-04 20:22 ` Lyndon Nerenberg
  2018-01-04 23:37 ` Greg Lewin
  0 siblings, 2 replies; 433+ messages in thread
From: Steve Simon @ 2018-01-04 20:11 UTC (permalink / raw)
  To: 9fans

Hi,

I haven't tried for a few weeks but sources.cs.bell-labs.com
has gone (from DNS), I don't know about the server behind it
as I never kept a record of the IP address.

has the labs server gone for good? (RIP).

-Steve



^ permalink raw reply	[flat|nested] 433+ messages in thread

* Re: [9fans] (no subject)
  2017-08-30 14:12 Steve Simon
@ 2017-08-30 16:36 ` Steven Stallion
  0 siblings, 0 replies; 433+ messages in thread
From: Steven Stallion @ 2017-08-30 16:36 UTC (permalink / raw)
  To: Fans of the OS Plan 9 from Bell Labs

I've been grateful for the nightly vac jobs I've had going for the
last several years of sources lately, though admittedly it was only
for my tiny corner of contrib.

On Wed, Aug 30, 2017 at 9:12 AM, Steve Simon <steve@quintile.net> wrote:
> Hi,
>
> I haven't looked for a while, but http://plan9.bell-labs.com has gone,
> and http://plan9.bell-labs.com/sources/ is broken -
> /usr/web/plan9/sources.html has disappeared from the web server.
>
> Is there anyone left at the labs who might be able to fix at least the
> web access to sources, it does look rather sad.
>
> https://9p.io/plan9 is still available, thank goodness.
>
> -Steve
>



^ permalink raw reply	[flat|nested] 433+ messages in thread

* [9fans] (no subject)
@ 2017-08-30 14:12 Steve Simon
  2017-08-30 16:36 ` Steven Stallion
  0 siblings, 1 reply; 433+ messages in thread
From: Steve Simon @ 2017-08-30 14:12 UTC (permalink / raw)
  To: 9fans

Hi,

I haven't looked for a while, but http://plan9.bell-labs.com has gone,
and http://plan9.bell-labs.com/sources/ is broken -
/usr/web/plan9/sources.html has disappeared from the web server.

Is there anyone left at the labs who might be able to fix at least the
web access to sources, it does look rather sad.

https://9p.io/plan9 is still available, thank goodness.

-Steve



^ permalink raw reply	[flat|nested] 433+ messages in thread

* Re: [9fans] (no subject)
  2016-12-02 11:44 Steve Simon
@ 2016-12-02 19:12 ` Bakul Shah
  0 siblings, 0 replies; 433+ messages in thread
From: Bakul Shah @ 2016-12-02 19:12 UTC (permalink / raw)
  To: Fans of the OS Plan 9 from Bell Labs

On Fri, 02 Dec 2016 11:44:52 GMT "Steve Simon" <steve@quintile.net> wrote:
> Hi all,
>
> Anyone have some small and neat code (in C) to parse ISO8601 date/time
> notation with all its glorious options?
>
> Its not hard to write, but it would be time consuming to test all the varients
> so if anyone has some code, or knows of some in /sys/src that I have missed,
> please tell me.

May be this will help:
ftp://ftp.ripe.net/test-traffic/ROOT/delayplots/iso8601.C



^ permalink raw reply	[flat|nested] 433+ messages in thread

* [9fans] (no subject)
@ 2016-12-02 11:44 Steve Simon
  2016-12-02 19:12 ` Bakul Shah
  0 siblings, 1 reply; 433+ messages in thread
From: Steve Simon @ 2016-12-02 11:44 UTC (permalink / raw)
  To: 9fans

Hi all,

Anyone have some small and neat code (in C) to parse ISO8601 date/time
notation with all its glorious options?

Its not hard to write, but it would be time consuming to test all the varients so
if anyone has some code, or knows of some in /sys/src that I have missed,
please tell me.

Thanks people,

-Steve



^ permalink raw reply	[flat|nested] 433+ messages in thread

* [9fans] (no subject)
@ 2016-07-29  0:01 kokamoto
  0 siblings, 0 replies; 433+ messages in thread
From: kokamoto @ 2016-07-29  0:01 UTC (permalink / raw)
  To: 9fans

Subject change to ether Yuk driver for 88E8036

I noticed the 9fans reopen now.
I tried this mail at June 16, 2016, but failed...
I'd like to announce this to all, particulary eric.

I posted a mail to 9fans, but I don't have received that mail,
so retries it to this mailing-list.

I asked the above line for about two weeks ago to 9fans.
Now I got a solution by myself.

The problem was 88E8036(Yukfe) chip has a small amount
of RAM buffer, which eric didn't pay attention.

I tried to may diff file, however, I wrote too many comment lines
on the file, which leads to a fuge sized diff file.
Therefore, I'll write only the differences between the last cdrom
of 9front and myself.
belows are the data:
(please pay attention to ===> lines)
-----from here-----
1)static Vtab vtab[] = {
	0x11ab,	0x4351,	1514,	"88e8036",



2)in buffinit() function:

	if(q == Qr || q == Qr + Qportsz){
===>		t = end - start;
		rrwrite32(c, q + Rpon, t - 8192/8);		/* set Rx upper threshold, pause on */
===>		rrwrite32(c, q + Rpoff, t/4);		/* set Rx lower threshold pause off */



3)in phyinit() function:

	if((c->feat & Fnewphy) == 0){
		u = phyread(c, Phyextctl);
		u &= ~0xf70;			/* clear downshift counters */
		u |= 0x7<<4;			/* mac tx clock = 25mhz */
		if(c->type == Yukec)
			u |= 2*Dnmstr | Dnslv;
		else
===>			u |= (0<<8 & 3<<8)|(1<<8 & 3<<8);
				......
	}else{
===>		if(c->feat != 0)		/* exclude Yukfe */
			u |= Ppmdixa >> 1;		/* why the shift? */
		if(c->type == Yukfep && c->rev == 0){
		}
			.....
+++	if (c->type == Yukfe){	/* led control */
+++		u = u1 = phyread(c, Phyphy);
+++		u &= ~(0xf <<4);
+++		u |= 0x0b<<4 & 0xf<<4;
+++		phywrite(c, 0x16, u);
+++		u1 |= (1<<8 & 7<<8) <<1;
+++		phywrite(c, 0x18, u1);
+++	}
	phywrite(c, Phyintm, Anok | Anerr | Lsc);		/* phy interrupt mask */
	dprint("phyid %.4ux step %.4ux\n", phyread(c, 2), phyread(c, 3));
}
------- to here -----

Kenji




^ permalink raw reply	[flat|nested] 433+ messages in thread

* [9fans] (no subject)
@ 2014-11-25  4:20 trebol
  0 siblings, 0 replies; 433+ messages in thread
From: trebol @ 2014-11-25  4:20 UTC (permalink / raw)
  To: 9fans

Hello everyone.

I'm curious about the behavior of rc concatenating null strings (brakes
execution on error...).  It's a feature, rationally thought-out, or a bug?

If anyone can tell me the story behind, I'll be grateful.

trebol.




^ permalink raw reply	[flat|nested] 433+ messages in thread

* [9fans] (no subject)
@ 2014-07-31  5:18 kokamoto
  0 siblings, 0 replies; 433+ messages in thread
From: kokamoto @ 2014-07-31  5:18 UTC (permalink / raw)
  To: 9fans

Subkject: A68-N5000 cabini motherboard

I got it functional partially.

This is for energy-saving motherboard with APU (15W TDP)
on it without coolong fan.

I just moved the HDD used on a C2D machine
to this box, where it booted successfully with only
one problem, ether chip.

The ether chip on this board is:
1.0.0: net 02.00.00 10ec/8168 ....,
and the error message from the kernel is:
rtl8169: unknown mac 8168 4c000000.

No, the ether8169.c file does not have that line.
However ether82598.c file does.
Then, I checked out the ether8169 line from /sys/src/9/pc/pcf,
and tried to recompile the kernel, and got a huge sized one:
size 9pcf
  1309468t + 6491264d + 375712b = 8176444.

I think the second size may be too big!

I recompiled the 386 kernel many times and had
no problem like this.
The compilation after the last kernel recompilation are
go(1.3?) and amd64 kernel.

Anyone has an idea what'i going on?

Kenji




^ permalink raw reply	[flat|nested] 433+ messages in thread

* [9fans] (no subject)
@ 2014-07-05  0:38 kokamoto
  0 siblings, 0 replies; 433+ messages in thread
From: kokamoto @ 2014-07-05  0:38 UTC (permalink / raw)
  To: 9fans

Subjecxt: how to change login user on 9pi?

I tried to change the /n/9fat/cmdline.txt file to

readparts=1 nobootprompt=local user=kokamoto.

Now I can login as kokamoto.  Then I'd like to make ask the
login name at boottime.  How I can change it?

Year!  Now I'm a network user of 9pi.
I got Buffalo's ether-wireless bridge at about 5000円,
which is higher than pi board itself!

Now I can write Japanese email like:
日本語の練習をしましょう

Kenji




^ permalink raw reply	[flat|nested] 433+ messages in thread

* Re: [9fans] (no subject)
  2014-06-21 23:39 ` cinap_lenrek
@ 2014-06-22  6:54   ` Steve Simon
  0 siblings, 0 replies; 433+ messages in thread
From: Steve Simon @ 2014-06-22  6:54 UTC (permalink / raw)
  To: 9fans

The ones that have bitten me have been ed, du and ls.

I fixed cleanname not to restamp the terminating zero on the string
if its already there which makes cleanname(".") work (for ls).

du's problem is wrapped in String.h issues and I haven't dug any more.

ed is exactly as you say.

I assumed the problem was more extensive, berhaps its a non-problem
with a couple of tiny fixes.

Thanks,

-Steve



^ permalink raw reply	[flat|nested] 433+ messages in thread

* Re: [9fans] (no subject)
  2014-06-21 19:45 Steve Simon
@ 2014-06-21 23:39 ` cinap_lenrek
  2014-06-22  6:54   ` Steve Simon
  0 siblings, 1 reply; 433+ messages in thread
From: cinap_lenrek @ 2014-06-21 23:39 UTC (permalink / raw)
  To: 9fans

what are the programs passing string constants? only found:

ed.c:160: 	tfname = mktemp("/tmp/eXXXXX");

all the other programs copy the template in a buffer
before passing it to mktemp(). i think it would be
better to just fix ed no?

--
cinap



^ permalink raw reply	[flat|nested] 433+ messages in thread

* [9fans] (no subject)
@ 2014-06-21 19:45 Steve Simon
  2014-06-21 23:39 ` cinap_lenrek
  0 siblings, 1 reply; 433+ messages in thread
From: Steve Simon @ 2014-06-21 19:45 UTC (permalink / raw)
  To: 9fans

Subject p9p and writable strings

Anyone built p9p recently, how do you cope with modern gcc
which now places all string constants in a readonly section
in the executable, and there is nolonger an option to prevent it.

the two main offenders I have found so far are mktemp() and cleanname().
In several places these are passed string constants.

the obvious alternatives would be to have these two functions return
malloc'ed memory (and remeber to free it later), or to replace
the string constant with an initialised variable.

What has anyone else done? have I missed somthing?

-Steve



^ permalink raw reply	[flat|nested] 433+ messages in thread

* Re: [9fans] (no subject)
  2014-04-16  1:52 sl
@ 2014-04-16  9:39 ` Ingo Krabbe
  0 siblings, 0 replies; 433+ messages in thread
From: Ingo Krabbe @ 2014-04-16  9:39 UTC (permalink / raw)
  To: 9fans

>>> In my experience a VESA BIOS will sometimes report
>>> different available modes depending on the detected
>>> EDID.
>>
>> I have no problem believing this is true, but I'm also sure > there's more to it than that.
>
> I agree. One problem is that these things are all different,
> almost completely undocumented, and implement non-standard
> modes seemingly at random. Some people involved with various
> OSX86[0] efforts have developed methods for probing (and in
> some cases, modifiying) the VESA BIOS on some cards. All
> kinds of strange behaviors have been observed.
>

In qemu the emulated controller seems to support 1920x1200x{16,24,32} as well as some other modes

term% aux/vga -m vesa -p
warning: reading edid: VBE error 0x0100
vesa flag            Ulinear|Hlinear
vesa sig            VESA 2.0
vesa oem            Bochs/Plex86 VBE(C) 2003 http://savannah.nongnu.org/projects/vgabios/ 0.2
vesa vendor         Bochs/Plex86 Developers
vesa product        Bochs/Plex86 VBE Adapter
vesa rev            $Id: vbe.c,v 1.64 2011/07/19 18:25:05 vruppert Exp $
vesa cap             8-bit-dac
vesa mem            16777216
[...]
vesa mode           0x187 1920x1200x16 r5g6b5 direct
vesa mode           0x188 1920x1200x24 r8g8b8 direct
vesa mode           0x189 1920x1200x32 x8r8g8b8 direct
vesa mode           0x18a 2560x1600x16 r5g6b5 direct
vesa mode           0x18b 2560x1600x24 r8g8b8 direct
vesa mode           0x18c 2560x1600x32 x8r8g8b8 direct
[...]

you may be able to try these with your monitors as a start.

>> I'd be interested in a survey with broader results
>> than just dueling anecdotes
>
> I haven't made any attempt to catalogue VESA vs EDID
> discrepancies, but I do keep a small archive of hardware
> info here:
>
> http://plan9.stanleylieber.com/hardware
>
> We try to collect the sysinfo[1] output for as many
> systems as possible, for later reference.
>
> sl
>
> [0] http://www.osx86project.org
> [1] http://man.aiju.de/1/sysinfo





^ permalink raw reply	[flat|nested] 433+ messages in thread

* Re: [9fans] (no subject)
@ 2014-04-16  1:52 sl
  2014-04-16  9:39 ` Ingo Krabbe
  0 siblings, 1 reply; 433+ messages in thread
From: sl @ 2014-04-16  1:52 UTC (permalink / raw)
  To: 9fans

>> In my experience a VESA BIOS will sometimes report
>> different available modes depending on the detected
>> EDID.
>
> I have no problem believing this is true, but I'm also sure > there's more to it than that.

I agree. One problem is that these things are all different,
almost completely undocumented, and implement non-standard
modes seemingly at random. Some people involved with various
OSX86[0] efforts have developed methods for probing (and in
some cases, modifiying) the VESA BIOS on some cards. All
kinds of strange behaviors have been observed.


> I'd be interested in a survey with broader results
> than just dueling anecdotes

I haven't made any attempt to catalogue VESA vs EDID
discrepancies, but I do keep a small archive of hardware
info here:

http://plan9.stanleylieber.com/hardware

We try to collect the sysinfo[1] output for as many
systems as possible, for later reference.

sl

[0] http://www.osx86project.org
[1] http://man.aiju.de/1/sysinfo



^ permalink raw reply	[flat|nested] 433+ messages in thread

* Re: [9fans] (no subject)
  2014-04-15 18:18   ` sl
  2014-04-15 22:42     ` erik quanstrom
@ 2014-04-16  1:20     ` Anthony Sorace
  1 sibling, 0 replies; 433+ messages in thread
From: Anthony Sorace @ 2014-04-16  1:20 UTC (permalink / raw)
  To: Fans of the OS Plan 9 from Bell Labs

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

> In my experience a VESA BIOS will sometimes report
> different available modes depending on the detected
> EDID.

I have no problem believing this is true, but I'm also sure there's more to it than that. The device I'm most frustrated with is a Thinkpad, reporting on the built-in display, for example. I've seen the same on at least one other laptop with a widescreen display (some HP thing), and at least a pair of desktop graphics cards with a 16:10 monitor attached. Very frustrating. I'd be interested in a survey with broader results than just dueling anecdotes; I'd be happy to know I'd just gotten unlucky.
Anthony


[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 169 bytes --]

^ permalink raw reply	[flat|nested] 433+ messages in thread

* Re: [9fans] (no subject)
  2014-04-15 22:42     ` erik quanstrom
@ 2014-04-15 23:40       ` arisawa
  0 siblings, 0 replies; 433+ messages in thread
From: arisawa @ 2014-04-15 23:40 UTC (permalink / raw)
  To: Fans of the OS Plan 9 from Bell Labs

Hello,

the result below is on one of my machine with  GA-H61M-USB3H.
the MB is nice with 9front.
maia% @{rfork n; aux/realemu; aux/vga -p}|grep  '^vesa mode' 
vesa mode           0x107 1280x1024x8 m8 packed
vesa mode           0x11a 1280x1024x16 r5g6b5 direct
vesa mode           0x11b 1280x1024x32 x8r8g8b8 direct
vesa mode           0x105 1024x768x8 m8 packed
vesa mode           0x117 1024x768x16 r5g6b5 direct
vesa mode           0x118 1024x768x32 x8r8g8b8 direct
vesa mode           0x112 640x480x32 x8r8g8b8 direct
vesa mode           0x114 800x600x16 r5g6b5 direct
vesa mode           0x115 800x600x32 x8r8g8b8 direct
vesa mode           0x101 640x480x8 m8 packed
vesa mode           0x103 800x600x8 m8 packed
vesa mode           0x111 640x480x16 r5g6b5 direct
vesa mode           0x17d 1920x1080x8 m8 packed
vesa mode           0x17e 1920x1080x16 r5g6b5 direct
vesa mode           0x17f 1920x1080x32 x8r8g8b8 direct
maia% 
and
maia% echo $vgasize
1920x1080x16
maia% 

I have wide screen display with DVI and is quite comfortable.
NOTE that VGA connector cannot live with VESA mode on the MB!
probably MB dependent.

Kenji Arisawa

2014/04/16 7:42、erik quanstrom <quanstro@quanstro.net> のメール:

> thanks for the confirmation!
> 
> - erik
> 




^ permalink raw reply	[flat|nested] 433+ messages in thread

* Re: [9fans] (no subject)
  2014-04-15 18:18   ` sl
@ 2014-04-15 22:42     ` erik quanstrom
  2014-04-15 23:40       ` arisawa
  2014-04-16  1:20     ` Anthony Sorace
  1 sibling, 1 reply; 433+ messages in thread
From: erik quanstrom @ 2014-04-15 22:42 UTC (permalink / raw)
  To: 9fans

thanks for the confirmation!

- erik



^ permalink raw reply	[flat|nested] 433+ messages in thread

* Re: [9fans] (no subject)
  2014-04-15 15:36 ` Anthony Sorace
@ 2014-04-15 18:18   ` sl
  2014-04-15 22:42     ` erik quanstrom
  2014-04-16  1:20     ` Anthony Sorace
  0 siblings, 2 replies; 433+ messages in thread
From: sl @ 2014-04-15 18:18 UTC (permalink / raw)
  To: 9fans

In my experience a VESA BIOS will sometimes report
different available modes depending on the detected
EDID.

The following cards reported the following modes when
the following EDIDs were detected:

---

1.0.0:	vid  03.00.00 1106/3344  11 0:f0000008 67108864 1:f4000000 16777216
	VIA Technologies, Inc. VT3314 VIA/S3G UniChrome Pro IGP

@{rfork n; aux/realemu; aux/vga -p}
vesa flag            Ulinear|Hlinear|Fsnarf
vesa sig            VESA 3.0
vesa oem            VIA P4N800 PRO
 1.0
vesa vendor
vesa product
vesa rev
vesa cap             8-bit-dac
vesa mem            16777216
vesa mode           0x101 640x480x8 m8 packed
vesa mode           0x111 640x480x16 r5g6b5 direct
vesa mode           0x112 640x480x32 x8r8g8b8 direct
vesa mode           0x171 720x480x8 m8 packed
vesa mode           0x173 720x480x16 r5g6b5 direct
vesa mode           0x175 720x480x32 x8r8g8b8 direct
vesa mode           0x1b9 720x540x8 m8 packed
vesa mode           0x1ba 720x540x16 r5g6b5 direct
vesa mode           0x1bb 720x540x32 x8r8g8b8 direct
vesa mode           0x17c 720x576x8 m8 packed
vesa mode           0x17e 720x576x16 r5g6b5 direct
vesa mode           0x17f 720x576x32 x8r8g8b8 direct
vesa mode           0x22e 800x480x8 m8 packed
vesa mode           0x22f 800x480x16 r5g6b5 direct
vesa mode           0x230 800x480x32 x8r8g8b8 direct
vesa mode           0x103 800x600x8 m8 packed
vesa mode           0x114 800x600x16 r5g6b5 direct
vesa mode           0x115 800x600x32 x8r8g8b8 direct
vesa mode           0x15c 848x480x8 m8 packed
vesa mode           0x15d 848x480x16 r5g6b5 direct
vesa mode           0x15f 848x480x32 x8r8g8b8 direct
vesa mode           0x196 852x480x8 m8 packed
vesa mode           0x197 852x480x16 r5g6b5 direct
vesa mode           0x198 852x480x32 x8r8g8b8 direct
vesa mode           0x222 853x480x8 m8 packed
vesa mode           0x223 853x480x16 r5g6b5 direct
vesa mode           0x224 853x480x32 x8r8g8b8 direct
vesa mode           0x128 960x600x8 m8 packed
vesa mode           0x129 960x600x16 r5g6b5 direct
vesa mode           0x12a 960x600x32 x8r8g8b8 direct
vesa mode           0x193 1024x512x8 m8 packed
vesa mode           0x194 1024x512x16 r5g6b5 direct
vesa mode           0x195 1024x512x32 x8r8g8b8 direct
vesa mode           0x20b 1024x576x8 m8 packed
vesa mode           0x20c 1024x576x16 r5g6b5 direct
vesa mode           0x20d 1024x576x32 x8r8g8b8 direct
vesa mode           0x200 1024x600x8 m8 packed
vesa mode           0x201 1024x600x16 r5g6b5 direct
vesa mode           0x203 1024x600x32 x8r8g8b8 direct
vesa mode           0x204 1024x640x8 m8 packed
vesa mode           0x205 1024x640x16 r5g6b5 direct
vesa mode           0x206 1024x640x32 x8r8g8b8 direct
vesa mode           0x105 1024x768x8 m8 packed
vesa mode           0x117 1024x768x16 r5g6b5 direct
vesa mode           0x118 1024x768x32 x8r8g8b8 direct
vesa mode           0x161 1152x864x8 m8 packed
vesa mode           0x163 1152x864x16 r5g6b5 direct
vesa mode           0x164 1152x864x32 x8r8g8b8 direct
vesa mode           0x125 1280x720x8 m8 packed
vesa mode           0x126 1280x720x16 r5g6b5 direct
vesa mode           0x127 1280x720x32 x8r8g8b8 direct
vesa mode           0x179 1280x768x8 m8 packed
vesa mode           0x17a 1280x768x16 r5g6b5 direct
vesa mode           0x17b 1280x768x32 x8r8g8b8 direct
vesa mode           0x1b6 1280x800x8 m8 packed
vesa mode           0x1b7 1280x800x16 r5g6b5 direct
vesa mode           0x1b8 1280x800x32 x8r8g8b8 direct
vesa mode           0x13f 1280x960x8 m8 packed
vesa mode           0x14f 1280x960x16 r5g6b5 direct
vesa mode           0x16a 1280x960x32 x8r8g8b8 direct
vesa mode           0x107 1280x1024x8 m8 packed
vesa mode           0x11a 1280x1024x16 r5g6b5 direct
vesa mode           0x11b 1280x1024x32 x8r8g8b8 direct
vesa mode           0x16c 1360x768x8 m8 packed
vesa mode           0x16d 1360x768x16 r5g6b5 direct
vesa mode           0x16e 1360x768x32 x8r8g8b8 direct
vesa mode           0x183 1366x768x8 m8 packed
vesa mode           0x184 1366x768x16 r5g6b5 direct
vesa mode           0x185 1366x768x32 x8r8g8b8 direct
vesa mode           0x13b 1400x1050x8 m8 packed
vesa mode           0x13c 1400x1050x16 r5g6b5 direct
vesa mode           0x13e 1400x1050x32 x8r8g8b8 direct
vesa mode           0x211 1440x900x8 m8 packed
vesa mode           0x212 1440x900x16 r5g6b5 direct
vesa mode           0x213 1440x900x32 x8r8g8b8 direct
vesa mode           0x20e 1600x1024x8 m8 packed
vesa mode           0x20f 1600x1024x16 r5g6b5 direct
vesa mode           0x210 1600x1024x32 x8r8g8b8 direct
vesa mode           0x120 1600x1200x8 m8 packed
vesa mode           0x122 1600x1200x16 r5g6b5 direct
vesa mode           0x124 1600x1200x32 x8r8g8b8 direct
vesa mode           0x12b 1680x1050x8 m8 packed
vesa mode           0x12c 1680x1050x16 r5g6b5 direct
vesa mode           0x12d 1680x1050x32 x8r8g8b8 direct
vesa mode           0x166 1920x1080x8 m8 packed
vesa mode           0x167 1920x1080x16 r5g6b5 direct
vesa mode           0x168 1920x1080x32 x8r8g8b8 direct
vesa mode           0x146 1920x1200x8 m8 packed
vesa mode           0x148 1920x1200x16 r5g6b5 direct
vesa mode           0x149 1920x1200x32 x8r8g8b8 direct
vesa mode           0x199 1920x1440x8 m8 packed
vesa mode           0x19a 1920x1440x16 r5g6b5 direct
vesa mode           0x19b 1920x1440x32 x8r8g8b8 direct
vesa mode           0x156 2048x1536x8 m8 packed
vesa mode           0x158 2048x1536x16 r5g6b5 direct
vesa mode           0x159 2048x1536x32 x8r8g8b8 direct
edid mfr            GSM
edid serialstr      31430
edid name           15 TFTLCD MNT
edid product        15091
edid serial         34106
edid version        1.1
edid mfrdate        2001.41
edid size (cm)      31x23
edid gamma          2.50
edid vert (Hz)      56-75
edid horz (Hz)      31000-61000
edid pclkmax        100000000
edid flags           standby suspend activeoff
edid 640x480@60Hz
		clock=25.175
		shb=648 ehb=792 ht=800
		vrs=490 vre=492 vt=525
		hsync=- vsync=-
edid 640x480@73Hz
		clock=31.5
		shb=648 ehb=824 ht=832
		vrs=489 vre=492 vt=520
		hsync=- vsync=-
edid 640x480@75Hz
		clock=31.5
		shb=640 ehb=840 ht=840
		vrs=481 vre=484 vt=500
		hsync=- vsync=-
edid 800x600@56Hz
		clock=36
		shb=800 ehb=1024 ht=1024
		vrs=601 vre=603 vt=625
		hsync=+ vsync=+
edid 800x600@60Hz
		clock=40
		shb=800 ehb=1056 ht=1056
		vrs=601 vre=605 vt=628
		hsync=+ vsync=+
edid 800x600@72Hz
		clock=50
		shb=800 ehb=1040 ht=1040
		vrs=637 vre=643 vt=666
		hsync=+ vsync=+
edid 800x600@75Hz
		clock=49.5
		shb=800 ehb=1056 ht=1056
		vrs=601 vre=604 vt=625
		hsync=+ vsync=+
edid 1024x768@60Hz
		clock=65
		shb=1024 ehb=1344 ht=1344
		vrs=771 vre=777 vt=806
		hsync=- vsync=-
edid 1024x768@70Hz
		clock=75
		shb=1024 ehb=1328 ht=1328
		vrs=771 vre=777 vt=806
		hsync=- vsync=-
edid 1024x768@75Hz
		clock=78.75
		shb=1024 ehb=1312 ht=1312
		vrs=769 vre=772 vt=800
		hsync=+ vsync=+
edid 1024x768@85Hz
		clock=94.5
		shb=1072 ehb=1168 ht=1376
		vrs=769 vre=772 vt=808
		hsync=+ vsync=+

---

1.0.0:	vid  03.00.00 10de/0422  11 0:d2000000 16777216 1:c000000c 268435456 2:00000000 16 3:d0000004 33554432 4:00000000 16 5:00004001 128
	NVIDIA Corporation G86 NVIDIA GeForce 8400 GS
10.9.0:	net  02.00.00 10b7/9055   5 0:00005001 128 1:d3100000 128

@{rfork n; aux/realemu; aux/vga -p}
fd 000000FD00384C1F5311000A202020202020
vesa flag            Ulinear|Hlinear|Fsnarf
vesa sig            VESA 3.0
vesa oem            NVIDIA 96.134
vesa vendor         NVIDIA Corporation
vesa product        G86 Board - p413h05
vesa rev            Chip Rev
vesa cap             8-bit-dac
vesa mem            14680064
vesa mode           0x100 640x400x8 m8 packed
vesa mode           0x101 640x480x8 m8 packed
vesa mode           0x103 800x600x8 m8 packed
vesa mode           0x105 1024x768x8 m8 packed
vesa mode           0x107 1280x1024x8 m8 packed
vesa mode           0x10e 320x200x16 r5g6b5 direct
vesa mode           0x10f 320x200x32 x8r8g8b8 direct
vesa mode           0x111 640x480x16 r5g6b5 direct
vesa mode           0x112 640x480x32 x8r8g8b8 direct
vesa mode           0x114 800x600x16 r5g6b5 direct
vesa mode           0x115 800x600x32 x8r8g8b8 direct
vesa mode           0x117 1024x768x16 r5g6b5 direct
vesa mode           0x118 1024x768x32 x8r8g8b8 direct
vesa mode           0x11a 1280x1024x16 r5g6b5 direct
vesa mode           0x11b 1280x1024x32 x8r8g8b8 direct
vesa mode           0x130 320x200x8 m8 packed
vesa mode           0x131 320x400x8 m8 packed
vesa mode           0x132 320x400x16 r5g6b5 direct
vesa mode           0x133 320x400x32 x8r8g8b8 direct
vesa mode           0x134 320x240x8 m8 packed
vesa mode           0x135 320x240x16 r5g6b5 direct
vesa mode           0x136 320x240x32 x8r8g8b8 direct
vesa mode           0x13d 640x400x16 r5g6b5 direct
vesa mode           0x13e 640x400x32 x8r8g8b8 direct
vesa mode           0x160 1280x800x8 m8 packed
vesa mode           0x161 1280x800x32 x8r8g8b8 direct
vesa mode           0x162 768x480x8 m8 packed
vesa mode           0x168 1680x1050x8 m8 packed
vesa mode           0x169 1680x1050x32 x8r8g8b8 direct
edid mfr            NEC
edid serialstr      03105090TA
edid name           AS221WM
edid product        26562
edid serial         0
edid version        1.3
edid mfrdate        2010.10
edid size (cm)      47x30
edid gamma          2.20
edid vert (Hz)      56-76
edid horz (Hz)      31000-83000
edid pclkmax        170000000
edid flags           digital standby suspend activeoff
edid 640x480@60Hz
		clock=25.175
		shb=648 ehb=792 ht=800
		vrs=490 vre=492 vt=525
		hsync=- vsync=-
edid 640x480@73Hz
		clock=31.5
		shb=648 ehb=824 ht=832
		vrs=489 vre=492 vt=520
		hsync=- vsync=-
edid 640x480@75Hz
		clock=31.5
		shb=640 ehb=840 ht=840
		vrs=481 vre=484 vt=500
		hsync=- vsync=-
edid 800x600@56Hz
		clock=36
		shb=800 ehb=1024 ht=1024
		vrs=601 vre=603 vt=625
		hsync=+ vsync=+
edid 800x600@60Hz
		clock=40
		shb=800 ehb=1056 ht=1056
		vrs=601 vre=605 vt=628
		hsync=+ vsync=+
edid 800x600@72Hz
		clock=50
		shb=800 ehb=1040 ht=1040
		vrs=637 vre=643 vt=666
		hsync=+ vsync=+
edid 800x600@75Hz
		clock=49.5
		shb=800 ehb=1056 ht=1056
		vrs=601 vre=604 vt=625
		hsync=+ vsync=+
edid 1024x768@60Hz
		clock=65
		shb=1024 ehb=1344 ht=1344
		vrs=771 vre=777 vt=806
		hsync=- vsync=-
edid 1024x768@70Hz
		clock=75
		shb=1024 ehb=1328 ht=1328
		vrs=771 vre=777 vt=806
		hsync=- vsync=-
edid 1024x768@75Hz
		clock=78.75
		shb=1024 ehb=1312 ht=1312
		vrs=769 vre=772 vt=800
		hsync=+ vsync=+
edid 1280x1024@75Hz
		clock=135
		shb=1280 ehb=1688 ht=1688
		vrs=1025 vre=1028 vt=1066
		hsync=+ vsync=+
edid 1680x1050@60Hz
		clock=146.25
		shb=1784 ehb=1960 ht=2240
		vrs=1053 vre=1059 vt=1089
		hsync=- vsync=+

---

0.3.0:	ser  07.80.00 8086/2a44  11 0:fc326804 16 1:00000000 16
	Intel Corporation Mobile 4 Series Chipset Intel Management Engine Interface

@{rfork n; aux/realemu; aux/vga -p}
vesa flag            Ulinear|Hlinear|Fsnarf
vesa sig            VESA 3.0
vesa oem            Intel(r)Cantiga Graphics Chip Accelerated VGA BIOS 1.0
vesa vendor         Intel Corporation
vesa product        Intel(r)Cantiga Graphics Controller
vesa rev            Hardware Version 0.0
vesa cap             8-bit-dac
vesa mem            33488896
vesa mode           0x160 768x480x8 m8 packed
vesa mode           0x161 768x480x16 r5g6b5 direct
vesa mode           0x162 768x480x32 x8r8g8b8 direct
vesa mode           0x163 960x600x8 m8 packed
vesa mode           0x164 960x600x16 r5g6b5 direct
vesa mode           0x165 960x600x32 x8r8g8b8 direct
vesa mode           0x166 1280x800x8 m8 packed
vesa mode           0x167 1280x800x16 r5g6b5 direct
vesa mode           0x168 1280x800x32 x8r8g8b8 direct
vesa mode           0x169 1440x900x8 m8 packed
vesa mode           0x16a 1440x900x16 r5g6b5 direct
vesa mode           0x16b 1440x900x32 x8r8g8b8 direct
vesa mode           0x105 1024x768x8 m8 packed
vesa mode           0x117 1024x768x16 r5g6b5 direct
vesa mode           0x118 1024x768x32 x8r8g8b8 direct
vesa mode           0x112 640x480x32 x8r8g8b8 direct
vesa mode           0x114 800x600x16 r5g6b5 direct
vesa mode           0x115 800x600x32 x8r8g8b8 direct
vesa mode           0x101 640x480x8 m8 packed
vesa mode           0x103 800x600x8 m8 packed
vesa mode           0x111 640x480x16 r5g6b5 direct
edid mfr            LEN
edid serialstr
edid name
edid product        16435
edid serial         0
edid version        1.3
edid mfrdate        2008.0
edid size (cm)      30x19
edid gamma          2.20
edid vert (Hz)      0-0
edid horz (Hz)      0-0
edid pclkmax        0
edid flags           digital standby suspend activeoff
edid 1440x900@60Hz
		clock=102
		shb=1488 ehb=1520 ht=1832
		vrs=903 vre=909 vt=926
		hsync=- vsync=-
edid 1440x900@50Hz
		clock=85.8
		shb=1488 ehb=1520 ht=1856
		vrs=903 vre=909 vt=926
		hsync=- vsync=-

---

0.2.0:	vid  03.00.00 8086/2a02  10 0:f8100004 1048576 1:00000000 16 2:e000000c 268435456 3:00000000 16 4:00001801 16
	Intel Corporation 02091028 Intel GM965, Intel X3100

@{rfork n; aux/realemu; aux/vga -p}
vesa flag            Ulinear|Hlinear|Fsnarf
vesa sig            VESA 3.0
vesa oem            Intel(r)GM965/PM965/GL960 Graphics Chip Accelerated VGA BIOS 1.0
vesa vendor         Intel Corporation
vesa product        Intel(r)GM965/PM965/GL960 Graphics Controller
vesa rev            Hardware Version 0.0
vesa cap             8-bit-dac
vesa mem            7798784
vesa mode           0x160 768x480x8 m8 packed
vesa mode           0x161 768x480x16 r5g6b5 direct
vesa mode           0x162 768x480x32 x8r8g8b8 direct
vesa mode           0x163 960x600x8 m8 packed
vesa mode           0x164 960x600x16 r5g6b5 direct
vesa mode           0x165 960x600x32 x8r8g8b8 direct
vesa mode           0x166 1280x800x8 m8 packed
vesa mode           0x167 1280x800x16 r5g6b5 direct
vesa mode           0x168 1280x800x32 x8r8g8b8 direct
vesa mode           0x105 1024x768x8 m8 packed
vesa mode           0x117 1024x768x16 r5g6b5 direct
vesa mode           0x118 1024x768x32 x8r8g8b8 direct
vesa mode           0x112 640x480x32 x8r8g8b8 direct
vesa mode           0x114 800x600x16 r5g6b5 direct
vesa mode           0x115 800x600x32 x8r8g8b8 direct
vesa mode           0x101 640x480x8 m8 packed
vesa mode           0x103 800x600x8 m8 packed
vesa mode           0x111 640x480x16 r5g6b5 direct

---

0.2.0:	vid  03.00.00 8086/0046  11 0:f2000004 4194304 1:00000000 16 2:d000000c 268435456 3:00000000 16 4:00001801 16
	Intel Corporation Intel Graphics Media Accelerator HD Intel Graphics Media Accelerator HD

@{rfork n; aux/realemu; aux/vga -p}
vesa flag            Ulinear|Hlinear|Fsnarf
vesa sig            VESA 3.0
vesa oem            Intel(R)Ironlake Mobile Graphics Chipset Accelerated VGA BIOS 1.0
vesa vendor         Intel Corporation
vesa product        Intel(R)Ironlake Mobile Graphics Controller
vesa rev            Hardware Version 0.0
vesa cap             8-bit-dac
vesa mem            33488896
vesa mode           0x160 768x480x8 m8 packed
vesa mode           0x161 768x480x16 r5g6b5 direct
vesa mode           0x162 768x480x32 x8r8g8b8 direct
vesa mode           0x163 960x600x8 m8 packed
vesa mode           0x164 960x600x16 r5g6b5 direct
vesa mode           0x165 960x600x32 x8r8g8b8 direct
vesa mode           0x166 1280x800x8 m8 packed
vesa mode           0x167 1280x800x16 r5g6b5 direct
vesa mode           0x168 1280x800x32 x8r8g8b8 direct
vesa mode           0x169 768x480x8 m8 packed
vesa mode           0x16a 768x480x16 r5g6b5 direct
vesa mode           0x16b 768x480x32 x8r8g8b8 direct
vesa mode           0x16c 960x600x8 m8 packed
vesa mode           0x16d 960x600x16 r5g6b5 direct
vesa mode           0x16e 960x600x32 x8r8g8b8 direct
vesa mode           0x105 1024x768x8 m8 packed
vesa mode           0x117 1024x768x16 r5g6b5 direct
vesa mode           0x118 1024x768x32 x8r8g8b8 direct
vesa mode           0x112 640x480x32 x8r8g8b8 direct
vesa mode           0x114 800x600x16 r5g6b5 direct
vesa mode           0x115 800x600x32 x8r8g8b8 direct
vesa mode           0x101 640x480x8 m8 packed
vesa mode           0x103 800x600x8 m8 packed
vesa mode           0x111 640x480x16 r5g6b5 direct
vesa mode           0x17d 1280x800x8 m8 packed (unoffered)
vesa mode           0x17e 1280x800x16 r5g6b5 direct (unoffered)
vesa mode           0x17f 1280x800x32 x8r8g8b8 direct (unoffered)
edid mfr            LEN
edid serialstr
edid name
edid product        16401
edid serial         0
edid version        1.3
edid mfrdate        2009.0
edid size (cm)      26x16
edid gamma          2.20
edid vert (Hz)      0-0
edid horz (Hz)      0-0
edid pclkmax        0
edid flags           digital standby suspend activeoff
edid 1280x800@60Hz
		clock=68.94
		shb=1296 ehb=1344 ht=1408
		vrs=801 vre=804 vt=816
		hsync=- vsync=-
edid 1280x800@50Hz
		clock=60.96
		shb=1328 ehb=1360 ht=1478
		vrs=803 vre=809 vt=825
		hsync=- vsync=-

---

Intel HD Graphics 3000 (not sure of VID/DID)

@{rfork n; aux/realemu; aux/vga -p}
vesa flag            Ulinear|Hlinear|Fsnarf
vesa sig            VESA 3.0
vesa oem            Intel(R)Sandybridge Mobile Graphics Chipset Accelerated VGA BIOS 1.0
vesa vendor         Intel Corporation
vesa product        Intel(R)Sandybridge Mobile Graphics Controller
vesa rev            Hardware Version 0.0
vesa cap             8-bit-dac
vesa mem            67043328
vesa mode           0x160 768x480x8 m8 packed
vesa mode           0x161 768x480x16 r5g6b5 direct
vesa mode           0x162 768x480x32 x8r8g8b8 direct
vesa mode           0x163 960x600x8 m8 packed
vesa mode           0x164 960x600x16 r5g6b5 direct
vesa mode           0x165 960x600x32 x8r8g8b8 direct
vesa mode           0x105 1024x768x8 m8 packed
vesa mode           0x117 1024x768x16 r5g6b5 direct
vesa mode           0x118 1024x768x32 x8r8g8b8 direct
vesa mode           0x112 640x480x32 x8r8g8b8 direct
vesa mode           0x114 800x600x16 r5g6b5 direct
vesa mode           0x115 800x600x32 x8r8g8b8 direct
vesa mode           0x101 640x480x8 m8 packed
vesa mode           0x103 800x600x8 m8 packed
vesa mode           0x111 640x480x16 r5g6b5 direct
vesa mode           0x17d 1366x768x8 m8 packed (unoffered)
vesa mode           0x17e 1366x768x16 r5g6b5 direct (unoffered)
vesa mode           0x17f 1366x768x32 x8r8g8b8 direct (unoffered)
edid mfr            LGD
edid serialstr
edid name
edid product        728
edid serial         0
edid version        1.3
edid mfrdate        2010.0
edid size (cm)      28x16
edid gamma          2.20
edid vert (Hz)      0-0
edid horz (Hz)      0-0
edid pclkmax        0
edid flags           digital standby suspend activeoff
edid 1366x768@60Hz
		clock=75.2
		shb=1414 ehb=1478 ht=1582
		vrs=772 vre=779 vt=792
		hsync=+ vsync=-

---

Intel HD Graphics 4000 (not sure of VID/DID)

@{rfork n; aux/realemu; aux/vga -p}
vesa flag            Ulinear|Hlinear|Fsnarf
vesa sig            VESA 3.0
vesa oem            Intel(R) Sandybridge/Ivybridge Graphics Chipset Accelerated VGA BIOS 1.0
vesa vendor         Intel Corporation
vesa product        Intel(R) Sandybridge/Ivybridge Graphics Controller
vesa rev            Hardware Version 0.0
vesa cap             8-bit-dac
vesa mem            67043328
vesa mode           0x105 1024x768x8 m8 packed
vesa mode           0x117 1024x768x16 r5g6b5 direct
vesa mode           0x118 1024x768x32 x8r8g8b8 direct
vesa mode           0x112 640x480x32 x8r8g8b8 direct
vesa mode           0x114 800x600x16 r5g6b5 direct
vesa mode           0x115 800x600x32 x8r8g8b8 direct
vesa mode           0x101 640x480x8 m8 packed
vesa mode           0x103 800x600x8 m8 packed
vesa mode           0x111 640x480x16 r5g6b5 direct
vesa mode           0x17d 1366x768x8 m8 packed
vesa mode           0x17e 1366x768x16 r5g6b5 direct
vesa mode           0x17f 1366x768x32 x8r8g8b8 direct
edid mfr            LGD
edid serialstr
edid name
edid product        728
edid serial         0
edid version        1.3
edid mfrdate        2012.0
edid size (cm)      28x16
edid gamma          2.20
edid vert (Hz)      0-0
edid horz (Hz)      0-0
edid pclkmax        0
edid flags           digital standby suspend activeoff
edid 1366x768@60Hz
		clock=75.2
		shb=1414 ehb=1478 ht=1582
		vrs=772 vre=779 vt=792
		hsync=+ vsync=-

---

sl



^ permalink raw reply	[flat|nested] 433+ messages in thread

* Re: [9fans] (no subject)
  2014-04-15 17:46   ` Aram Hăvărneanu
@ 2014-04-15 17:53     ` erik quanstrom
  0 siblings, 0 replies; 433+ messages in thread
From: erik quanstrom @ 2014-04-15 17:53 UTC (permalink / raw)
  To: 9fans

> Funny, I have 10+ machines that all use vesa, all widescreen. I have
> never seen a vesa BIOS that didn't provide widescreen modes. I'm sure
> they exist, but they certainly are not rare. I drive 1920x1200x32 with
> vesa and Cinap's realemu just fine.

my experience has been similar to anthony's.  i have >> 10 machines, and
none of them offer a non 4:3 mode from onboard graphics, at least when
attached to a 4:3 monitor.  i suspect that the modes offered may be different
when different montors are attached, but i haven't proved that.

what kind of video cards/onboard video are you using?

- erik



^ permalink raw reply	[flat|nested] 433+ messages in thread

* Re: [9fans] (no subject)
  2014-04-15 15:50 ` erik quanstrom
@ 2014-04-15 17:46   ` Aram Hăvărneanu
  2014-04-15 17:53     ` erik quanstrom
  0 siblings, 1 reply; 433+ messages in thread
From: Aram Hăvărneanu @ 2014-04-15 17:46 UTC (permalink / raw)
  To: Fans of the OS Plan 9 from Bell Labs

On Tue, Apr 15, 2014 at 5:36 PM, Anthony Sorace <a@9srv.net> wrote:
> Cards with VESA entries for non-4:3 modes are rare; I'm not sure I've ever seen one.


On Tue, Apr 15, 2014 at 5:50 PM, erik quanstrom <quanstro@quanstro.net> wrote:
> and vesa bioses don't typicall provide em.

Funny, I have 10+ machines that all use vesa, all widescreen. I have
never seen a vesa BIOS that didn't provide widescreen modes. I'm sure
they exist, but they certainly are not rare. I drive 1920x1200x32 with
vesa and Cinap's realemu just fine.

-- 
Aram Hăvărneanu



^ permalink raw reply	[flat|nested] 433+ messages in thread

* Re: [9fans] (no subject)
  2014-04-15 14:41 Steve Simon
  2014-04-15 15:36 ` Anthony Sorace
@ 2014-04-15 15:50 ` erik quanstrom
  2014-04-15 17:46   ` Aram Hăvărneanu
  1 sibling, 1 reply; 433+ messages in thread
From: erik quanstrom @ 2014-04-15 15:50 UTC (permalink / raw)
  To: 9fans

> I have got hold of a new 1920x1200 monitor but no card I can find seems
> to support it on plan9 - Even cards that claim this resolution and higher
> don't have the vesa mode entry.
>
> Anyone any thoughts, or suggestions of cards that do
> have the apropriate high resolution VESA modes?

as anthony hints, vesa doesn't define non 4:3 modes
in the standard.  and vesa bioses don't typicall provide
em.

- erik



^ permalink raw reply	[flat|nested] 433+ messages in thread

* Re: [9fans] (no subject)
  2014-04-15 14:41 Steve Simon
@ 2014-04-15 15:36 ` Anthony Sorace
  2014-04-15 18:18   ` sl
  2014-04-15 15:50 ` erik quanstrom
  1 sibling, 1 reply; 433+ messages in thread
From: Anthony Sorace @ 2014-04-15 15:36 UTC (permalink / raw)
  To: Fans of the OS Plan 9 from Bell Labs

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

I'd love to hear about positive results here. Cards with VESA entries for non-4:3 modes are rare; I'm not sure I've ever seen one. The Pi, by contrast, drives my 16:10 high-res monitor without issues, which is the main reason it's my main Plan 9 terminal these days.

Anthony


[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 169 bytes --]

^ permalink raw reply	[flat|nested] 433+ messages in thread

* [9fans] (no subject)
@ 2014-04-15 14:41 Steve Simon
  2014-04-15 15:36 ` Anthony Sorace
  2014-04-15 15:50 ` erik quanstrom
  0 siblings, 2 replies; 433+ messages in thread
From: Steve Simon @ 2014-04-15 14:41 UTC (permalink / raw)
  To: 9fans

Hi,

I have got hold of a new 1920x1200 monitor but no card I can find seems
to support it on plan9 - Even cards that claim this resolution and higher
don't have the vesa mode entry.

Anyone any thoughts, or suggestions of cards that do
have the apropriate high resolution VESA modes?

Thanks,

-Steve



^ permalink raw reply	[flat|nested] 433+ messages in thread

* [9fans] (no subject)
@ 2014-03-19 18:44 Jacob Todd
  0 siblings, 0 replies; 433+ messages in thread
From: Jacob Todd @ 2014-03-19 18:44 UTC (permalink / raw)
  To: Fans of the OS Plan 9 from Bell Labs, erik quanstrom

On Sun, 16 Mar 2014 10:51:37 -0400, erik quanstrom wrote:
>since you mention the host's hardware, i'm a little confused.  the host's
>hardware doesn't make any difference.  it's drawterm's bridge between
>#A and the host's audio device that's the question.  has someone
>done this for os-x?  if so, where's the code?
>
http://h1ro.dyndns.org/drawterm/
http://9fans.net/archive/2012/06/205



^ permalink raw reply	[flat|nested] 433+ messages in thread

* Re: [9fans] (no subject)
  2014-03-15 23:26 ` Jacob Todd
@ 2014-03-16 14:51   ` erik quanstrom
  0 siblings, 0 replies; 433+ messages in thread
From: erik quanstrom @ 2014-03-16 14:51 UTC (permalink / raw)
  To: 9fans

On Sat Mar 15 19:27:44 EDT 2014, jaketodd422@gmail.com wrote:

> Audio worked with hiro's drawterm and intel hda in 9front.

since you mention the host's hardware, i'm a little confused.  the host's
hardware doesn't make any difference.  it's drawterm's bridge between
#A and the host's audio device that's the question.  has someone
done this for os-x?  if so, where's the code?

- erik



^ permalink raw reply	[flat|nested] 433+ messages in thread

* Re: [9fans] (no subject)
  2014-03-15 23:07 Steve Simon
  2014-03-15 23:26 ` Jacob Todd
@ 2014-03-16  1:51 ` Jeff Sickel
  1 sibling, 0 replies; 433+ messages in thread
From: Jeff Sickel @ 2014-03-16  1:51 UTC (permalink / raw)
  To: Fans of the OS Plan 9 from Bell Labs

It’s on the back burner for osx.  Well, maybe the storage bin waiting for a sifter.

-jas


On Mar 15, 2014, at 6:07 PM, Steve Simon <steve@quintile.net> wrote:

> Subject Drawterm windows audio?
> 
> Anyone added an audio driver to windows or osx drawterms?
> 
> -Steve
> 




^ permalink raw reply	[flat|nested] 433+ messages in thread

* Re: [9fans] (no subject)
  2014-03-15 23:07 Steve Simon
@ 2014-03-15 23:26 ` Jacob Todd
  2014-03-16 14:51   ` erik quanstrom
  2014-03-16  1:51 ` Jeff Sickel
  1 sibling, 1 reply; 433+ messages in thread
From: Jacob Todd @ 2014-03-15 23:26 UTC (permalink / raw)
  To: Fans of the OS Plan 9 from Bell Labs

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

Audio worked with hiro's drawterm and intel hda in 9front.

[-- Attachment #2: Type: text/html, Size: 81 bytes --]

^ permalink raw reply	[flat|nested] 433+ messages in thread

* [9fans] (no subject)
@ 2014-03-15 23:07 Steve Simon
  2014-03-15 23:26 ` Jacob Todd
  2014-03-16  1:51 ` Jeff Sickel
  0 siblings, 2 replies; 433+ messages in thread
From: Steve Simon @ 2014-03-15 23:07 UTC (permalink / raw)
  To: 9fans

Subject Drawterm windows audio?

Anyone added an audio driver to windows or osx drawterms?

-Steve



^ permalink raw reply	[flat|nested] 433+ messages in thread

* [9fans] (no subject)
@ 2013-11-17 23:04 Steve Simon
  0 siblings, 0 replies; 433+ messages in thread
From: Steve Simon @ 2013-11-17 23:04 UTC (permalink / raw)
  To: 9fans

Subject i2c and gpio

I need an i2c driver for plan9, anyone implemented
one in the past and have opinions on what they should
look like?

I have to revisit some old code but I wrote a driver for
another OS which implemeted 255 virtual files in /dev/i2c/*
one for each possible address (well there are some reserved
ones but you get the idea).

I need GPIO pins too. again in OSs passim I just had a file
per pin, no clever magical mapping of bits into integers.

I then allowed a write to reconfigure the port as an output,
or a read to set it as an input; the I/O config being persistent.

This worked well for us but perhaps is naive?

Thoughts anyone?

-Steve



^ permalink raw reply	[flat|nested] 433+ messages in thread

* Re: [9fans] (no subject)
@ 2013-06-03 15:43 sl
  0 siblings, 0 replies; 433+ messages in thread
From: sl @ 2013-06-03 15:43 UTC (permalink / raw)
  To: 9fans

> what would be helpful, and move the discussion forward, is if someone
> could try to replicate this with unclean shutdowns after various file
> operations.  i suspect that it won't repeat.  but either way, it
> will move the discussion forward.

For what it's worth, unclean shutdowns resulted in lost data for me
under both fossil and hjfs. In my experience unclean shutdowns never
seemed to cause problems for cwfs64x.

In the case of both fossil and hjfs it is sometimes possible to repair
the damage. Other times it is not. Fossil has vocal supporters, while
hjfs is still marked experimental (bugs are actually getting fixed). The
problem for users is that when you boot the system and you can't access
your files, it gets in the way of the reason you booted the system in the
first place. Persistence of this condition is unacceptable.

I ran fossil on both hardware and under different virtual machines and
eventually experienced file corruption on every single install. Once I
found out about cwfs I switched to that and had zero problems, ever.
Okay, I said to myself, this is where I'll stay. Anecdotal? You betcha.
But cwfs never lost data.

We can argue about who misread what messages forever. The fact is
that some of us had problems with fossil and then found ways around
the problems. For some of us that meant patching fossil or changing
the way we used fossil. For others, it meant finding some other
filesystem. Saying "there is no problem" changes nothing. You can
debate with the Grand Canyon for hours, but when you walk off the
cliff you're still going to plummet to the ground.

http://img.stanleylieber.com/src/15358/img/1370274020.jpg

-sl



^ permalink raw reply	[flat|nested] 433+ messages in thread

* Re: [9fans] (no subject)
  2013-04-30 15:56 lucio
@ 2013-04-30 17:11 ` erik quanstrom
  0 siblings, 0 replies; 433+ messages in thread
From: erik quanstrom @ 2013-04-30 17:11 UTC (permalink / raw)
  To: 9fans

On Tue Apr 30 11:57:34 EDT 2013, lucio@proxima.alt.za wrote:
> Subject Sheevaplug and NVRAM
>
> Every time I start the Sheevaplug, I have to enter the authentication
> details that ought to be written to VNRAM.  This seems unnecessary,
> but my attempts to assign a single block of flash to NVRAM have so far
> been unsuccessful.

the key for me was to add a partition for the flash to the plan9.ini, e.g.

flash0part=nvram 0x100000 0x120000/plan9.ini 0x120000 0x140000/kernel 0x140000 0x4c0000

- erik



^ permalink raw reply	[flat|nested] 433+ messages in thread

* [9fans] (no subject)
@ 2013-04-30 15:56 lucio
  2013-04-30 17:11 ` erik quanstrom
  0 siblings, 1 reply; 433+ messages in thread
From: lucio @ 2013-04-30 15:56 UTC (permalink / raw)
  To: 9fans

Subject Sheevaplug and NVRAM

Every time I start the Sheevaplug, I have to enter the authentication
details that ought to be written to VNRAM.  This seems unnecessary,
but my attempts to assign a single block of flash to NVRAM have so far
been unsuccessful.

Could somebody mail me an example of a successful allocation of flash
memory for Plan 9 use on a Sheevaplug so I can figure out what I am
doing wrong?

++L




^ permalink raw reply	[flat|nested] 433+ messages in thread

* [9fans] (no subject)
@ 2012-10-19  9:46 Sophit4
  0 siblings, 0 replies; 433+ messages in thread
From: Sophit4 @ 2012-10-19  9:46 UTC (permalink / raw)
  To: 9fans

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

RIP, Uriel. Wish you'd stayed around to make us laugh and contribute to
plan9.

>From http://uriel.cat-v.org

*
*

*"The individual has always had to struggle to keep from being overwhelmed
by the tribe. If you try it, you will be lonely often, and sometimes
frightened. But no price is too high to pay for the privilege of owning
yourself."*

                                        — Friedrich Nietzsche

On 10/17/2012 06:08 PM, Rob Pike wrote:

Does anyone know what happened?

-rob

[-- Attachment #2: Type: text/html, Size: 592701 bytes --]

^ permalink raw reply	[flat|nested] 433+ messages in thread

* Re: [9fans] (no subject)
  2012-09-03 11:16 yaroslav
@ 2012-09-03 11:40 ` Charles Forsyth
  0 siblings, 0 replies; 433+ messages in thread
From: Charles Forsyth @ 2012-09-03 11:40 UTC (permalink / raw)
  To: Fans of the OS Plan 9 from Bell Labs

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

it's a shell script that copies updated files from a Bell Labs system to
sources.

[-- Attachment #2: Type: text/html, Size: 102 bytes --]

^ permalink raw reply	[flat|nested] 433+ messages in thread

* [9fans] (no subject)
@ 2012-09-03 11:16 yaroslav
  2012-09-03 11:40 ` Charles Forsyth
  0 siblings, 1 reply; 433+ messages in thread
From: yaroslav @ 2012-09-03 11:16 UTC (permalink / raw)
  To: 9fans

subect: update:V: in system mkfiles

Many system mkfiles have targets like this:

update:V:
	update $UPDATEFLAGS $UPDATE

These're no program named 'update' however — besides pc/update which
doesn't seem to apply here.

Could somebody please advise what these are meant for?  Is it still
relevant?

Thanks.

- yk




^ permalink raw reply	[flat|nested] 433+ messages in thread

* [9fans] (no subject)
@ 2012-04-11  9:38 陈俊秀
  0 siblings, 0 replies; 433+ messages in thread
From: 陈俊秀 @ 2012-04-11  9:38 UTC (permalink / raw)
  To: 9fans

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

hi,

I try to mount the local foler in the vm, use the 9p protocol, it mount
success, enter the foler, i can read and write the files already in the
folder ,but can't create new folders and files in it. why and how can i
solve it?

i created the vm use qemu -fsdev
local,id=test_dev,path=/root/shared,security_model=none -device
virtio-9p-pci,fsdev=test_dev,mount_tag=test_mount
the guest vm is redhat with 2.6.32 kernel,  in the guest os terminal: mount
-t 9p -o trans=virtio test_mount /tmp/shared/ -
oversion=9p2000.L,posixacl,cache=loose
and it's no use when i update the kernel to higher .


thanks,
xiu

[-- Attachment #2: Type: text/html, Size: 1944 bytes --]

^ permalink raw reply	[flat|nested] 433+ messages in thread

* Re: [9fans] (no subject)
  2011-12-31 19:32           ` erik quanstrom
@ 2012-01-05 18:03             ` Aram Hăvărneanu
  0 siblings, 0 replies; 433+ messages in thread
From: Aram Hăvărneanu @ 2012-01-05 18:03 UTC (permalink / raw)
  To: erik quanstrom; +Cc: 9fans

erik quanstrom wrote:
> for me, the most important questions are
> - how do i set up a raid/hot spares, and
> - can i do this without rebooting.

Of course, and right now I'm doing exactly that using a different
operating system.  Can I do that on Plan 9? I don't know, I'm trying
to find out without much success.

> wikipedia.

I really don't understand why are you sending me to read wikipedia.
Generally, I think of myself as a decent speaker, I know how to make
myself clear.  It's obvious that in this case I failed.  In my
previous job I have worked on a file system that among other things
also implements redundancy.  If I implemented these things I guess I
know about them without having to read wikipedia.

The machine I use today for storage also runs bits of my own software.
 It's very easy to administer, tells me when disks are broken, I can
just add disks for more storage without reboot and I can hot swap
disks.  Can Plan 9 do this?  I don't know, I guess not?  It's fine by
me, I'm willing to sacrifice performance and ease of administration
for an operating system I like better.  I'm willing to implement
myself what I need and doesn't exist yet, though I have a very hard
time understanding what's missing from these very, very vague
discussions.

> there's nothing strange about a sata device or even a raid of
> various devices of any type being presented with an ide programming
> interface.  one could just as easily slap an ahci programming interface
> on, but either requires translation software/hardware.

I agree that's nothing inherently strange, but in practice it's
uncommon, at least in my experience.  But then again, I'm not a
hardware guy, so my experience means nothing.

-- 
Aram Hăvărneanu



^ permalink raw reply	[flat|nested] 433+ messages in thread

* Re: [9fans] (no subject)
       [not found]         ` <CAEAzY39S9z6mKtun68DGFbEkA6y8kaqTEyDCkW6ydHK8aHFG5A@mail.gmail.c>
@ 2011-12-31 19:32           ` erik quanstrom
  2012-01-05 18:03             ` Aram Hăvărneanu
  0 siblings, 1 reply; 433+ messages in thread
From: erik quanstrom @ 2011-12-31 19:32 UTC (permalink / raw)
  To: aram.h, 9fans

> > (see wiki's raid article.)
>
> Plan 9 wiki? It mentions SiL 3112 SATA, 3114 SATA/RAID and VIA 82C686,
> VT8237 SATA/RAID, strangely, under IDE section.
>
> I haven't found yet relevant information about the SiL stuff, but the
> VIA stuff is what Adaptec calls HostRAID and Linux fakeRAID.

wikipedia.

there's nothing strange about a sata device or even a raid of
various devices of any type being presented with an ide programming
interface.  one could just as easily slap an ahci programming interface
on, but either requires translation software/hardware.

for me, the most important questions are
- how do i set up a raid/hot spares, and
- can i do this without rebooting.

- erik



^ permalink raw reply	[flat|nested] 433+ messages in thread

* Re: [9fans] (no subject)
  2011-12-31  5:31       ` erik quanstrom
@ 2011-12-31 17:40         ` Aram Hăvărneanu
       [not found]         ` <CAEAzY39S9z6mKtun68DGFbEkA6y8kaqTEyDCkW6ydHK8aHFG5A@mail.gmail.c>
  1 sibling, 0 replies; 433+ messages in thread
From: Aram Hăvărneanu @ 2011-12-31 17:40 UTC (permalink / raw)
  To: Fans of the OS Plan 9 from Bell Labs

> the motivation behind my question is that it's not clear to me that there is
> such a thing as pure hardware raid.  if someone knows of something that
> implements the entire read/write path without a cpu, even with a degraded
> or rebuilding raid, i'd be very interested in that.

Ahh, I see what you mean.  I agree that probably there is no such
thing as RAID purely implemented in hardware.  I think for most people
the hardware epithet is used to describe a black box where the user
doesn't have access to it's internal gearing, be it hardware or
software.  A microwave is a hardware device for its users because the
users don't need to care if the unit has firmware, discrete
electronics or mechanical gears.

Probably a better term would be to always use the term appliance,
instead of this hardware/softare false dichotomy.

> (see wiki's raid article.)

Plan 9 wiki? It mentions SiL 3112 SATA, 3114 SATA/RAID and VIA 82C686,
VT8237 SATA/RAID, strangely, under IDE section.

I haven't found yet relevant information about the SiL stuff, but the
VIA stuff is what Adaptec calls HostRAID and Linux fakeRAID.

A Happy New Year!

-- 
Aram Hăvărneanu



^ permalink raw reply	[flat|nested] 433+ messages in thread

* Re: [9fans] (no subject)
  2011-12-30 21:39     ` Jack Norton
@ 2011-12-31  5:31       ` erik quanstrom
  2011-12-31 17:40         ` Aram Hăvărneanu
       [not found]         ` <CAEAzY39S9z6mKtun68DGFbEkA6y8kaqTEyDCkW6ydHK8aHFG5A@mail.gmail.c>
  0 siblings, 2 replies; 433+ messages in thread
From: erik quanstrom @ 2011-12-31  5:31 UTC (permalink / raw)
  To: 9fans

> > if a coraid appliance were pcie-attached rather than ethernet attached,
> > would you still ask this question?  do you think the block diagram of coraid
> > hardware looks fundamentally different than the block diagram of a raid
> > card?
> 
> It's just curiosity.  I know the appliance is Plan 9 based.  If it
> uses an off-the-shelf RAID chip I might buy a card with that chip
> since it works in Plan 9.  If it's fs(3) I know fs(3) is good enough
> for my needs.  If it's something else at least I know fs(3) is not
> good enough and I might be tempted to write something myself.  So yes,
> I'd ask even if it was a PCIe card instead of network appliance.

the motivation behind my question is that it's not clear to me that there is
such a thing as pure hardware raid.  if someone knows of something that
implements the entire read/write path without a cpu, even with a degraded
or rebuilding raid, i'd be very interested in that.  but as far as i know, there's
always a processor in there on the other side of the bus.  in case of aoe, the
bus is ethernet and for a "hardware raid" card, it's usually some form
of pci.

(see wiki's raid article.)

- erik



^ permalink raw reply	[flat|nested] 433+ messages in thread

* Re: [9fans] (no subject)
  2011-12-30 22:41           ` Charles Forsyth
@ 2011-12-30 23:00             ` Lyndon Nerenberg
  0 siblings, 0 replies; 433+ messages in thread
From: Lyndon Nerenberg @ 2011-12-30 23:00 UTC (permalink / raw)
  To: Fans of the OS Plan 9 from Bell Labs

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


On 2011-12-30, at 14:41 PM, Charles Forsyth wrote:

> That's upgrading the stored formats,

Yes.

[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 858 bytes --]

^ permalink raw reply	[flat|nested] 433+ messages in thread

* Re: [9fans] (no subject)
  2011-12-30 21:56         ` Aram Hăvărneanu
@ 2011-12-30 22:41           ` Charles Forsyth
  2011-12-30 23:00             ` Lyndon Nerenberg
  0 siblings, 1 reply; 433+ messages in thread
From: Charles Forsyth @ 2011-12-30 22:41 UTC (permalink / raw)
  To: Fans of the OS Plan 9 from Bell Labs

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

That's upgrading the stored formats, not the in-kernel(?) software support
for a particular version?

On 30 December 2011 21:56, Aram Hăvărneanu <aram.h@mgk.ro> wrote:

> > zpool/zfs upgrade? Yes. Don't recall if I had to reboot
> > afterwards.
>
> You don't.
>
> --
> Aram Hăvărneanu
>
>

[-- Attachment #2: Type: text/html, Size: 620 bytes --]

^ permalink raw reply	[flat|nested] 433+ messages in thread

* Re: [9fans] (no subject)
  2011-12-30 21:53       ` Bakul Shah
@ 2011-12-30 21:56         ` Aram Hăvărneanu
  2011-12-30 22:41           ` Charles Forsyth
  0 siblings, 1 reply; 433+ messages in thread
From: Aram Hăvărneanu @ 2011-12-30 21:56 UTC (permalink / raw)
  To: Fans of the OS Plan 9 from Bell Labs

> zpool/zfs upgrade? Yes. Don't recall if I had to reboot
> afterwards.

You don't.

-- 
Aram Hăvărneanu



^ permalink raw reply	[flat|nested] 433+ messages in thread

* Re: [9fans] (no subject)
  2011-12-30 21:34     ` Charles Forsyth
  2011-12-30 21:38       ` Aram Hăvărneanu
@ 2011-12-30 21:53       ` Bakul Shah
  2011-12-30 21:56         ` Aram Hăvărneanu
  1 sibling, 1 reply; 433+ messages in thread
From: Bakul Shah @ 2011-12-30 21:53 UTC (permalink / raw)
  To: Fans of the OS Plan 9 from Bell Labs

On Fri, 30 Dec 2011 21:34:39 GMT Charles Forsyth <charles.forsyth@gmail.com>  wrote:
>
> Could you do the latter without taking the machine down?
>
> On 30 December 2011 21:28, Bakul Shah <bakul@bitblocks.com> wrote:
>
> > Since then I have replaced disks with much bigger disks without taking the
> > machine down, upgraded the os & zpool/zfs versions a couple of times

zpool/zfs upgrade? Yes. Don't recall if I had to reboot
afterwards.  "Resilvering" to replace a disk takes a long time
so not having to take the machine for hours is nice.  A quick
reboot is no big deal.



^ permalink raw reply	[flat|nested] 433+ messages in thread

* Re: [9fans] (no subject)
  2011-12-30 21:05   ` erik quanstrom
@ 2011-12-30 21:39     ` Jack Norton
  2011-12-31  5:31       ` erik quanstrom
  0 siblings, 1 reply; 433+ messages in thread
From: Jack Norton @ 2011-12-30 21:39 UTC (permalink / raw)
  To: Fans of the OS Plan 9 from Bell Labs

On 12/30/2011 3:05 PM, erik quanstrom wrote:
>> Does the Coraid applience implement RAID in hardware or does it use
>> fs(3) or another software solution?
>
> if a coraid appliance were pcie-attached rather than ethernet attached,
> would you still ask this question?  do you think the block diagram of coraid
> hardware looks fundamentally different than the block diagram of a raid
> card?
>
> - erik
>

I think he is trying to get you to divulge details on the software
running on the coraid appliance itself.  We all know it is plan 9 based
(right?), so it would be interesting to know how this extra
functionality of raid was added.  I know these are trade secrets though
so I've never asked.

I would still ask that question if it were pcie attached.  Curiosity
will be my undoing though.

-Jack



^ permalink raw reply	[flat|nested] 433+ messages in thread

* Re: [9fans] (no subject)
  2011-12-30 21:34     ` Charles Forsyth
@ 2011-12-30 21:38       ` Aram Hăvărneanu
  2011-12-30 21:53       ` Bakul Shah
  1 sibling, 0 replies; 433+ messages in thread
From: Aram Hăvărneanu @ 2011-12-30 21:38 UTC (permalink / raw)
  To: Fans of the OS Plan 9 from Bell Labs

Charles Forsyth wrote:
>> Since then I have replaced disks with much bigger disks without taking the
>> machine down, upgraded the os & zpool/zfs versions a couple of times
>
> Could you do the latter without taking the machine down?

Upgrade zpool/zfs version yes, os, no.

-- 
Aram Hăvărneanu



^ permalink raw reply	[flat|nested] 433+ messages in thread

* Re: [9fans] (no subject)
  2011-12-30 21:28   ` Bakul Shah
@ 2011-12-30 21:34     ` Charles Forsyth
  2011-12-30 21:38       ` Aram Hăvărneanu
  2011-12-30 21:53       ` Bakul Shah
  0 siblings, 2 replies; 433+ messages in thread
From: Charles Forsyth @ 2011-12-30 21:34 UTC (permalink / raw)
  To: Fans of the OS Plan 9 from Bell Labs

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

Could you do the latter without taking the machine down?

On 30 December 2011 21:28, Bakul Shah <bakul@bitblocks.com> wrote:

> Since then I have replaced disks with much bigger disks without taking the
> machine down, upgraded the os & zpool/zfs versions a couple of times

[-- Attachment #2: Type: text/html, Size: 508 bytes --]

^ permalink raw reply	[flat|nested] 433+ messages in thread

* Re: [9fans] (no subject)
  2011-12-30 20:35 ` Aram Hăvărneanu
@ 2011-12-30 21:28   ` Bakul Shah
  2011-12-30 21:34     ` Charles Forsyth
  0 siblings, 1 reply; 433+ messages in thread
From: Bakul Shah @ 2011-12-30 21:28 UTC (permalink / raw)
  To: Fans of the OS Plan 9 from Bell Labs

My fileserver is running freebsd zfs. Basically one machine for nfs, venti, cifs, timemachine + sundry other services. This has worked well since 2005. Initially I used h/w raid under zfs. This was a mistake, forcibly corrected when my machine died. Now I use raidz. Since then I have replaced disks with much bigger disks without taking the machine down, upgraded the os & zpool/zfs versions a couple of times (could've done without them but I prefer to run the latest stable release). Except for these events it has required hardly any maintenance (just checking vital signs like fan speed, any disk errors in weekly zpool scrub etc). One issue is FreeBSD install still doesn't install on zfs. But you can run a minimal root off a USB disk and manually setup zfs (which is pretty easy). I should probably run an AOE server on it as well! When I next replace this machine I will see if I can create a USB disk image.

On Dec 30, 2011, at 12:35 PM, Aram Hăvărneanu <aram.h@mgk.ro> wrote:

>> aoe doesn't require solaris, or any other operating system.
>> you can use it directly with a plan 9 file server, as i do.
> 
> Of course AoE doesn't require much, my comment was in the context of
> Coraid's hardware appliance.
> 
> I don't have much use for AoE at home.  At one point I used it to
> network boot machines, but I only have laptops now, which have local
> disks because I need to use them disconnected from the network
> sometimes.
> 
> I need a higher level protocol like 9p or venti, and I'd rather have a
> single Plan 9 machine with direct attached disks serving everything
> than a Plan 9 front end serving 9p and another machine providing AoE
> to it.  I have way, way to many machines. Yesterday I've thrown away
> 5.  I need less machines, not more :-).
> 
> Does the Coraid applience implement RAID in hardware or does it use
> fs(3) or another software solution?
> 
> -- 
> Aram Hăvărneanu
> 



^ permalink raw reply	[flat|nested] 433+ messages in thread

* Re: [9fans] (no subject)
       [not found] ` <CAEAzY38puVSzEnn90mmi+Bq4hnL9WpbBsnysjJYvXYw3xvE=xA@mail.gmail.c>
@ 2011-12-30 21:05   ` erik quanstrom
  2011-12-30 21:39     ` Jack Norton
  0 siblings, 1 reply; 433+ messages in thread
From: erik quanstrom @ 2011-12-30 21:05 UTC (permalink / raw)
  To: aram.h, 9fans

> I don't have much use for AoE at home.  At one point I used it to
> network boot machines, but I only have laptops now, which have local
> disks because I need to use them disconnected from the network
> sometimes.
>
> I need a higher level protocol like 9p or venti, and I'd rather have a
> single Plan 9 machine with direct attached disks serving everything
> than a Plan 9 front end serving 9p and another machine providing AoE
> to it.  I have way, way to many machines. Yesterday I've thrown away
> 5.  I need less machines, not more :-).

sure, but you haven't answered the question of how to do redundancy
and recovery.  aoe is a good way to isolate these functions into an appliance.

> Does the Coraid applience implement RAID in hardware or does it use
> fs(3) or another software solution?

if a coraid appliance were pcie-attached rather than ethernet attached,
would you still ask this question?  do you think the block diagram of coraid
hardware looks fundamentally different than the block diagram of a raid
card?

- erik



^ permalink raw reply	[flat|nested] 433+ messages in thread

* Re: [9fans] (no subject)
  2011-12-30 18:08 erik quanstrom, erik quanstrom
  2011-12-30 18:49 ` Jack Norton
@ 2011-12-30 20:35 ` Aram Hăvărneanu
  2011-12-30 21:28   ` Bakul Shah
       [not found] ` <CAEAzY38puVSzEnn90mmi+Bq4hnL9WpbBsnysjJYvXYw3xvE=xA@mail.gmail.c>
  2 siblings, 1 reply; 433+ messages in thread
From: Aram Hăvărneanu @ 2011-12-30 20:35 UTC (permalink / raw)
  To: Fans of the OS Plan 9 from Bell Labs

> aoe doesn't require solaris, or any other operating system.
> you can use it directly with a plan 9 file server, as i do.

Of course AoE doesn't require much, my comment was in the context of
Coraid's hardware appliance.

I don't have much use for AoE at home.  At one point I used it to
network boot machines, but I only have laptops now, which have local
disks because I need to use them disconnected from the network
sometimes.

I need a higher level protocol like 9p or venti, and I'd rather have a
single Plan 9 machine with direct attached disks serving everything
than a Plan 9 front end serving 9p and another machine providing AoE
to it.  I have way, way to many machines. Yesterday I've thrown away
5.  I need less machines, not more :-).

Does the Coraid applience implement RAID in hardware or does it use
fs(3) or another software solution?

-- 
Aram Hăvărneanu



^ permalink raw reply	[flat|nested] 433+ messages in thread

* Re: [9fans] (no subject)
  2011-12-30 18:49 ` Jack Norton
@ 2011-12-30 19:24   ` erik quanstrom
  0 siblings, 0 replies; 433+ messages in thread
From: erik quanstrom @ 2011-12-30 19:24 UTC (permalink / raw)
  To: 9fans

> I don't think he was implying that one needed the other.  In any case I
> figured I would ask -- are there any plans for a small scale AoE
> appliance from coraid?  Didn't there used to be a single drive AoE kit
> long ago?

there was once a single drive pata unit.

> What is the list's personal/home usage of AoE like?  Do you guys use
> generic hardware and something like vblade (or those other ones people
> have made for linux like ggblade or whatever it is called)?

http://www.quanstro.net/plan9/fs.html

i also use vblade(8) on plan 9 for testing.

- erik



^ permalink raw reply	[flat|nested] 433+ messages in thread

* Re: [9fans] (no subject)
  2011-12-30 18:08 erik quanstrom, erik quanstrom
@ 2011-12-30 18:49 ` Jack Norton
  2011-12-30 19:24   ` erik quanstrom
  2011-12-30 20:35 ` Aram Hăvărneanu
       [not found] ` <CAEAzY38puVSzEnn90mmi+Bq4hnL9WpbBsnysjJYvXYw3xvE=xA@mail.gmail.c>
  2 siblings, 1 reply; 433+ messages in thread
From: Jack Norton @ 2011-12-30 18:49 UTC (permalink / raw)
  To: Fans of the OS Plan 9 from Bell Labs

On 12/30/2011 12:08 PM, erik quanstrom wrote:
>>> It might be a bit
>>> much for home use, but if I had a little bit of a budget I'd use Coraid's AoE
>>> stuff as the basis for my storage.
>>
>> Yeah, it's pretty overkill.  I've previously worked at a storage
>> company as a file system guy and now I have at home a nice array with
>> ZFS on top.  It works great, but I want to scale down.  I want less
>> stuff, not more.  And I want to use Plan9, not Solaris.
>
> aoe doesn't require solaris, or any other operating system.
> you can use it directly with a plan 9 file server, as i do.
>
> - erik
>

I don't think he was implying that one needed the other.  In any case I
figured I would ask -- are there any plans for a small scale AoE
appliance from coraid?  Didn't there used to be a single drive AoE kit
long ago?
What is the list's personal/home usage of AoE like?  Do you guys use
generic hardware and something like vblade (or those other ones people
have made for linux like ggblade or whatever it is called)?

-Jack



^ permalink raw reply	[flat|nested] 433+ messages in thread

* [9fans] (no subject)
@ 2011-12-30 18:08 erik quanstrom, erik quanstrom
  2011-12-30 18:49 ` Jack Norton
                   ` (2 more replies)
  0 siblings, 3 replies; 433+ messages in thread
From: erik quanstrom, erik quanstrom @ 2011-12-30 18:08 UTC (permalink / raw)
  To: 9fans

> > It might be a bit
> > much for home use, but if I had a little bit of a budget I'd use Coraid's AoE
> > stuff as the basis for my storage.
>
> Yeah, it's pretty overkill.  I've previously worked at a storage
> company as a file system guy and now I have at home a nice array with
> ZFS on top.  It works great, but I want to scale down.  I want less
> stuff, not more.  And I want to use Plan9, not Solaris.

aoe doesn't require solaris, or any other operating system.
you can use it directly with a plan 9 file server, as i do.

- erik



^ permalink raw reply	[flat|nested] 433+ messages in thread

* [9fans] (no subject)
@ 2011-11-22 18:32 Steve Simon
  0 siblings, 0 replies; 433+ messages in thread
From: Steve Simon @ 2011-11-22 18:32 UTC (permalink / raw)
  To: 9fans

Subject factotum auth for commodity web browsers?

Hi,

I have a distant memory of somone talking about adding
factotum support to mozilla or firefox, but I can nolonger
fine a reference - did I imagine it?

Is there such a thing for p9p perhaps?

-Steve



^ permalink raw reply	[flat|nested] 433+ messages in thread

* Re: [9fans] (no subject)
  2011-08-09 18:21     ` Lyndon Nerenberg (VE6BBM/VE7TFX)
@ 2011-08-09 18:31       ` Steve Simon
  0 siblings, 0 replies; 433+ messages in thread
From: Steve Simon @ 2011-08-09 18:31 UTC (permalink / raw)
  To: 9fans

> auth/newns


Aha!

excellent, this is just what I need.

thanks

-Steve



^ permalink raw reply	[flat|nested] 433+ messages in thread

* Re: [9fans] (no subject)
  2011-08-09 13:07   ` Steve Simon
  2011-08-09 14:52     ` erik quanstrom
@ 2011-08-09 18:21     ` Lyndon Nerenberg (VE6BBM/VE7TFX)
  2011-08-09 18:31       ` Steve Simon
  1 sibling, 1 reply; 433+ messages in thread
From: Lyndon Nerenberg (VE6BBM/VE7TFX) @ 2011-08-09 18:21 UTC (permalink / raw)
  To: 9fans

> the problem is as soon as I do that I lost contact with the
> mount command and as its not a shell builtin this means I
> can never get back the namespace I have lost.

auth/newns




^ permalink raw reply	[flat|nested] 433+ messages in thread

* Re: [9fans] (no subject)
  2011-08-09 13:07   ` Steve Simon
@ 2011-08-09 14:52     ` erik quanstrom
  2011-08-09 18:21     ` Lyndon Nerenberg (VE6BBM/VE7TFX)
  1 sibling, 0 replies; 433+ messages in thread
From: erik quanstrom @ 2011-08-09 14:52 UTC (permalink / raw)
  To: 9fans

> The only solution I can see is to write some C code, but
> I was hoping somone might see a trick I missed.

what are you really trying to accomplish?

- erik



^ permalink raw reply	[flat|nested] 433+ messages in thread

* Re: [9fans] (no subject)
  2011-08-09 12:40 Steve Simon
  2011-08-09 12:54 ` erik quanstrom
@ 2011-08-09 14:12 ` Russ Cox
  1 sibling, 0 replies; 433+ messages in thread
From: Russ Cox @ 2011-08-09 14:12 UTC (permalink / raw)
  To: Fans of the OS Plan 9 from Bell Labs

Yes, rfork N is very nearly useless in rc.
In a C program it is more useful, because
you can open file descriptors you need
before and make system calls afterward.

Russ


^ permalink raw reply	[flat|nested] 433+ messages in thread

* Re: [9fans] (no subject)
  2011-08-09 12:54 ` erik quanstrom
@ 2011-08-09 13:07   ` Steve Simon
  2011-08-09 14:52     ` erik quanstrom
  2011-08-09 18:21     ` Lyndon Nerenberg (VE6BBM/VE7TFX)
  0 siblings, 2 replies; 433+ messages in thread
From: Steve Simon @ 2011-08-09 13:07 UTC (permalink / raw)
  To: 9fans

> don't you just want rfork Nm?

I don't think so, that is worse, this would really mean
I couldn't mount anything.

I don't mind the new app adding mounts if it wants to, but
I want it to start with a new root dir and children, so
I need to flush out the old namespace.

the problem is as soon as I do that I lost contact with the
mount command and as its not a shell builtin this means I
can never get back the namespace I have lost.

I am stuck in no-mans-land.

its easy enough to experiment:
	open a window
	type rfork N
	try to get ls to work.

I can pass an open file descriptor across
the rfork N boundry, but I still cannot mount it.

The only solution I can see is to write some C code, but
I was hoping somone might see a trick I missed.

-Steve



^ permalink raw reply	[flat|nested] 433+ messages in thread

* Re: [9fans] (no subject)
  2011-08-09 12:40 Steve Simon
@ 2011-08-09 12:54 ` erik quanstrom
  2011-08-09 13:07   ` Steve Simon
  2011-08-09 14:12 ` Russ Cox
  1 sibling, 1 reply; 433+ messages in thread
From: erik quanstrom @ 2011-08-09 12:54 UTC (permalink / raw)
  To: 9fans

On Tue Aug  9 08:41:44 EDT 2011, steve@quintile.net wrote:
> Subject rfork N
>
> I want to construct a new namespace for an app, including a new root dir.
> I was hoping to do this with a few lines of script starting with rfork N,
> however this seems to be a dead end.
>
> I can still access kernel devices directly using the # escape in filenames,
> which includes '#s/fossil' for my file server. However I cannot get access
> to mount(1) so I can never access any files in that fossil.
>
> is rfork N in rc useless, and do I get a prize for noticing?
>
> (or is it a lack of vision on my behalf as usual?)

don't you just want rfork Nm?

- erik



^ permalink raw reply	[flat|nested] 433+ messages in thread

* [9fans] (no subject)
@ 2011-08-09 12:40 Steve Simon
  2011-08-09 12:54 ` erik quanstrom
  2011-08-09 14:12 ` Russ Cox
  0 siblings, 2 replies; 433+ messages in thread
From: Steve Simon @ 2011-08-09 12:40 UTC (permalink / raw)
  To: 9fans

Subject rfork N

I want to construct a new namespace for an app, including a new root dir.
I was hoping to do this with a few lines of script starting with rfork N,
however this seems to be a dead end.

I can still access kernel devices directly using the # escape in filenames,
which includes '#s/fossil' for my file server. However I cannot get access
to mount(1) so I can never access any files in that fossil.

is rfork N in rc useless, and do I get a prize for noticing?

(or is it a lack of vision on my behalf as usual?)

-Steve



^ permalink raw reply	[flat|nested] 433+ messages in thread

* Re: [9fans] (no subject)
  2011-04-25  7:42 ` Steve Simon
@ 2011-04-25 13:11   ` erik quanstrom
  0 siblings, 0 replies; 433+ messages in thread
From: erik quanstrom @ 2011-04-25 13:11 UTC (permalink / raw)
  To: 9fans

On Mon Apr 25 03:43:36 EDT 2011, steve@quintile.net wrote:
> I don't manage 1920x1080 but I do get 1600x1200x16 from my
> NVidia GeForce2 MX-200. This card is old but its what is in the
> machine and its works.
>
> I must say lots of pixels makes a very nice interface.

i thought i responded to this.  i run the same resolution in
vesa mode on this

; pci 1002/9714
1002/9714
	ATI Technologies Inc RS880 [Radeon HD 4290]

this sucker supports
vesa mode           0x1e5 1920x1440x16 r5g6b5 direct
vesa mode           0x1e6 1920x1440x32 r8g8b8 direct

but my monitor isn't that good.  i also run with intel
integrated graphics on an atom motherboard.

- erik



^ permalink raw reply	[flat|nested] 433+ messages in thread

* Re: [9fans] (no subject)
  2011-04-06  9:09 Stanley Lieber
@ 2011-04-25  7:42 ` Steve Simon
  2011-04-25 13:11   ` erik quanstrom
  0 siblings, 1 reply; 433+ messages in thread
From: Steve Simon @ 2011-04-25  7:42 UTC (permalink / raw)
  To: 9fans

I don't manage 1920x1080 but I do get 1600x1200x16 from my
NVidia GeForce2 MX-200. This card is old but its what is in the
machine and its works.

I must say lots of pixels makes a very nice interface.

-Steve



^ permalink raw reply	[flat|nested] 433+ messages in thread

* [9fans] (no subject)
@ 2011-04-06  9:09 Stanley Lieber
  2011-04-25  7:42 ` Steve Simon
  0 siblings, 1 reply; 433+ messages in thread
From: Stanley Lieber @ 2011-04-06  9:09 UTC (permalink / raw)
  To: 9fans, video, cards, for, 1920x1080

> From: Tharaneedharan Vilwanathan <vdharani@gma...>
> Subject: suggestion for a video card
> Date: Tue, 18 Aug 2009 11:53:58 -0700
>
> hi,
>
> i am looking for a video card for plan9.
>
> here are my requirements:
>
> - should do 1920x1080 at 60Hz so i can connect to my LCD TV via HDMI
> - HDMI connector preferable but if the card does 1920x1080, i can use
> DVI to HDMI adapter
> - would be nice if it can also do 1920x1200
>
> has anyone played with such a card? is it orderable? any suggestions?
>
> any help appreciated.
>
> regards
> dharani

This post didn't garner a response. A couple of years later,
I have the same question. Is anyone running Plan 9 native
at 1920x1080 with an LCD monitor? What video card are you
using? What tweaks were necessary to get it to work?

The Nvidia card I use with OpenBSD crashes Plan 9 when I
attempt xga above 640x480x8. With cinap's realemu I'm able
to run at 800x600x32, but the card's VESA bios doesn't report
any available modes above 800x600. Some other cards I had
sitting around yielded higher resolutions under realemu (VMware
even reports 1920x1080 as a valid mode under VESA), but I
haven't yet hit upon the right combination to drive my LCD
monitor at 1920x1080.

-sl





^ permalink raw reply	[flat|nested] 433+ messages in thread

* [9fans] (no subject)
  2011-03-28 15:18     ` ron minnich
@ 2011-03-28 22:57       ` erik quanstrom
  0 siblings, 0 replies; 433+ messages in thread
From: erik quanstrom @ 2011-03-28 22:57 UTC (permalink / raw)


On Mon Mar 28 11:20:39 EDT 2011, rminnich at gmail.com wrote:
> Erik, sounds like you need a motor generator ... flames from outlets
> ... wow ... maybe some opto isolators with a 2 meter air gap too :-)

evidently the strike was closer to the neighbors.  they lost
all their major appliances, and a heat pump.  (i thought you
couldn't kill them.)

fire breathing refrigerator!

- erik



^ permalink raw reply	[flat|nested] 433+ messages in thread

* [9fans] (no subject)
  2011-03-28 14:50   ` cinap_lenrek at gmx.de
@ 2011-03-28 15:18     ` ron minnich
  2011-03-28 22:57       ` erik quanstrom
  0 siblings, 1 reply; 433+ messages in thread
From: ron minnich @ 2011-03-28 15:18 UTC (permalink / raw)


Erik, sounds like you need a motor generator ... flames from outlets
... wow ... maybe some opto isolators with a 2 meter air gap too :-)

ron



^ permalink raw reply	[flat|nested] 433+ messages in thread

* [9fans] (no subject)
  2011-03-28 13:56 ` erik quanstrom
@ 2011-03-28 14:50   ` cinap_lenrek at gmx.de
  2011-03-28 15:18     ` ron minnich
  0 siblings, 1 reply; 433+ messages in thread
From: cinap_lenrek at gmx.de @ 2011-03-28 14:50 UTC (permalink / raw)


so the front fell off?

--
cinap
-------------- next part --------------
An embedded message was scrubbed...
From: erik quanstrom <quanstro at labs.coraid.com>
Subject: [9fans] (no subject)
Date: Mon, 28 Mar 2011 09:56:11 -0400
Size: 2696
URL: <http://mail.9fans.net/private/9fans/attachments/20110328/e829b9f4/attachment.mht>


^ permalink raw reply	[flat|nested] 433+ messages in thread

* [9fans] (no subject)
       [not found] <96cc26fe3002748983b3fc16cc949bab@quintile.net>
@ 2011-03-28 13:56 ` erik quanstrom
  2011-03-28 14:50   ` cinap_lenrek at gmx.de
  0 siblings, 1 reply; 433+ messages in thread
From: erik quanstrom @ 2011-03-28 13:56 UTC (permalink / raw)


On Mon Mar 28 08:07:44 EDT 2011, steve at quintile.net wrote:
> looks like your web server (quanstro.net) is down.
> 

yes, we had a big thunderstorm come by and knock
out power for 4 hrs.  we had a strike close enough to
the house to blow up lightbulbs and shoot flames out
of sockets shortly after power came back on, so i lost
some ethernet interfaces, including the web/auth/ftp
server's.  both my lines are down, too.

note to self: stop buying crappy consumer motherboards.

hopefully i'll get it all replaced or patched up this afternoon.  and
with luck, the phone company will have things fixed
as well.

- erik



^ permalink raw reply	[flat|nested] 433+ messages in thread

* [9fans] (no subject)
@ 2010-12-21  3:43 erik quanstrom, erik quanstrom
  0 siblings, 0 replies; 433+ messages in thread
From: erik quanstrom, erik quanstrom @ 2010-12-21  3:43 UTC (permalink / raw)
  To: 9fans

has anyone using cifs/aquarela had the chance to try
nfactotum with either with the mschap protocol?

(you will need the latest version of nfactotum to have
any hope of success.)

- erik



^ permalink raw reply	[flat|nested] 433+ messages in thread

* [9fans] (no subject)
@ 2010-05-06 19:55 erik quanstrom
  0 siblings, 0 replies; 433+ messages in thread
From: erik quanstrom @ 2010-05-06 19:55 UTC (permalink / raw)
  To: 9fans

- erik



^ permalink raw reply	[flat|nested] 433+ messages in thread

* Re: [9fans] (no subject)
  2010-03-09  5:50             ` Lyndon Nerenberg (VE6BBM/VE7TFX)
@ 2010-03-09 20:08               ` Patrick Kelly
  0 siblings, 0 replies; 433+ messages in thread
From: Patrick Kelly @ 2010-03-09 20:08 UTC (permalink / raw)
  To: Fans of the OS Plan 9 from Bell Labs

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

POSIX is a standard in which hardly anyone actually adheres too. AIX POSIX
is not Solaris POSIX is not Linux POSIX etc. What good is a standard that
isn't truthfully standardised. Alas I will say that POSIX does add quite a
bit more cross platfom conformity than some other... things... but there a
better solutions.

While Plan 9 has some similiaritys to UNIX, it is not. Porting UNIX tools to
something that is not is just not a good idea. You don't "port" a lawnmower
engine to a Ferrari. You don't "port" horse tranquilizer to a rat.

Should the few of you continue on this path, I would also ask you to port
the ReactOS framework over to Plan9, and the Haiku kits, and AROS's
librarys, and... and...

A big reason for the creation of Plan 9 was to get away from the complexity,
from the "everything but the kitchen sink" mentality. I would strongly
suggest reading the articles on http://plan9.bell-labs.com/sys/doc/ before
you continue your massochistic crusade.
On Tue, Mar 9, 2010 at 12:50 AM, Lyndon Nerenberg (VE6BBM/VE7TFX) <
lyndon@orthanc.ca> wrote:

> > surely your joking, mr. nerenberg!
>
> Nope.  Over the past 10 years I can only think of one or two projects
> I did that required platform-specific optimizations outside of POSIX.
>
>
>

[-- Attachment #2: Type: text/html, Size: 1728 bytes --]

^ permalink raw reply	[flat|nested] 433+ messages in thread

* Re: [9fans] (no subject)
  2010-03-09  5:32           ` erik quanstrom
@ 2010-03-09  5:50             ` Lyndon Nerenberg (VE6BBM/VE7TFX)
  2010-03-09 20:08               ` Patrick Kelly
  0 siblings, 1 reply; 433+ messages in thread
From: Lyndon Nerenberg (VE6BBM/VE7TFX) @ 2010-03-09  5:50 UTC (permalink / raw)
  To: 9fans

> surely your joking, mr. nerenberg!

Nope.  Over the past 10 years I can only think of one or two projects
I did that required platform-specific optimizations outside of POSIX.




^ permalink raw reply	[flat|nested] 433+ messages in thread

* Re: [9fans] (no subject)
  2010-03-09  5:26         ` Lyndon Nerenberg (VE6BBM/VE7TFX)
@ 2010-03-09  5:32           ` erik quanstrom
  2010-03-09  5:50             ` Lyndon Nerenberg (VE6BBM/VE7TFX)
  0 siblings, 1 reply; 433+ messages in thread
From: erik quanstrom @ 2010-03-09  5:32 UTC (permalink / raw)
  To: 9fans

On Tue Mar  9 00:27:59 EST 2010, lyndon@orthanc.ca wrote:
> > But there ought to be a sane
> > alternative and it should not be anywhere as complex.
>
> There is: it's called POSIX.

surely your joking, mr. nerenberg!

- erik



^ permalink raw reply	[flat|nested] 433+ messages in thread

* Re: [9fans] (no subject)
  2010-03-09  4:20       ` lucio
@ 2010-03-09  5:26         ` Lyndon Nerenberg (VE6BBM/VE7TFX)
  2010-03-09  5:32           ` erik quanstrom
  0 siblings, 1 reply; 433+ messages in thread
From: Lyndon Nerenberg (VE6BBM/VE7TFX) @ 2010-03-09  5:26 UTC (permalink / raw)
  To: lucio, 9fans

> But there ought to be a sane
> alternative and it should not be anywhere as complex.

There is: it's called POSIX.




^ permalink raw reply	[flat|nested] 433+ messages in thread

* Re: [9fans] (no subject)
  2010-03-08 22:19     ` James Tomaschke
@ 2010-03-09  4:34       ` lucio
  0 siblings, 0 replies; 433+ messages in thread
From: lucio @ 2010-03-09  4:34 UTC (permalink / raw)
  To: 9fans

> What tools do you have in mind?
>
> This can be true for useful projects but it is not the case with
> Autotools, because it is properly implemented as a useless tool.

No, I do not have the autotools in mind, I share the prevalent dislike
for them.

Just to clarify, I use dot, fgb has ported both OpenSSH and OpenSSL
with good cause.

Your comments about generating a mkfile from Makefile.am are the most
constructive I have seen so far.

++L




^ permalink raw reply	[flat|nested] 433+ messages in thread

* Re: [9fans] (no subject)
  2010-03-08 19:20     ` Lyndon Nerenberg (VE6BBM/VE7TFX)
@ 2010-03-09  4:20       ` lucio
  2010-03-09  5:26         ` Lyndon Nerenberg (VE6BBM/VE7TFX)
  0 siblings, 1 reply; 433+ messages in thread
From: lucio @ 2010-03-09  4:20 UTC (permalink / raw)
  To: 9fans

> Then there cannot possibly be enough to port the auto* abortion.

I hope so too, that would be insane.  But there ought to be a sane
alternative and it should not be anywhere as complex.  I'm sorry I put
the NetBSD package system in the same basket as the autoconf stuff,
their relationship is merely that the package system is geared towards
autoconf, but that is only a fraction of its functionality and I'm
sure can be replaced.  In fact, thinking about it, I've often wished
the configuration stuff would move out of the individual packages so
that duplication could be eliminated.  So maybe that's what _I'm_
looking for.

But enough said.  I have a much better idea of what the vocal Plan 9
community would (not) like.

++L




^ permalink raw reply	[flat|nested] 433+ messages in thread

* Re: [9fans] (no subject)
  2010-03-08  4:22 lucio
  2010-03-08  4:49 ` ron minnich
  2010-03-08  8:54 ` Richard Miller
@ 2010-03-08 22:53 ` Sascha Retzki
  2010-03-08 18:01   ` lucio
  2 siblings, 1 reply; 433+ messages in thread
From: Sascha Retzki @ 2010-03-08 22:53 UTC (permalink / raw)
  To: lucio, 9fans

> Thing is, It's autoconf that needs careful
> redesign:

The question is, why should I care about that all? I have mk(1) and I really don't need more to build software on Plan9 (rc, awk/sed, etc. come in handy).

You seem to insist on alien software, why is porting software from lunix a prefered solution? Most of the solutions are a.) either to problems we don't even have or b.) so awkward in interfacing you just end up writing a native fork anyway.

Another interesting quesiton is: Should we have the ability to port alien software to Plan9, from an ethical point of view? I personally would feel better if APE was in extra/ (and has it's own mailinglist and contrib/).

> even though contrib/replica is not as comprehensive as a
> revision control even when backed by venti, it is unmatched for Plan 9
> purposes.

parse error. What are unmatched Plan9 purposes? And what has autoconf to do with contrib and replica?




^ permalink raw reply	[flat|nested] 433+ messages in thread

* Re: [9fans] (no subject)
  2010-03-08 18:01   ` lucio
  2010-03-08 19:20     ` Lyndon Nerenberg (VE6BBM/VE7TFX)
  2010-03-08 19:41     ` erik quanstrom
@ 2010-03-08 22:19     ` James Tomaschke
  2010-03-09  4:34       ` lucio
  2 siblings, 1 reply; 433+ messages in thread
From: James Tomaschke @ 2010-03-08 22:19 UTC (permalink / raw)
  To: Fans of the OS Plan 9 from Bell Labs

lucio@proxima.alt.za wrote:
> That's simple pragmatism.  Using Plan 9 without some of the Open
> Source stuff is hard at least for some of us.  And there just aren't
> enough Plan 9 developers to produce alternatives.  Considering the
> number of useful (if poorly implemented) Open Source tools out there,
> I'm sure I'm not being absurd.

What tools do you have in mind?

This can be true for useful projects but it is not the case with
Autotools, because it is properly implemented as a useless tool.

If they wrote their own Makefile.in you can use that or Makefile.am to
create a mkfile fairly quickly.

There's no need to worry about path searching because of Plan 9
filespace unions.

Testing for missing headers/libraries is also pointless as compiling
will tell you this.

Autotools will not generate portable code, it can only inject code that
the author wrote a condition for.

effort > reward ergo GNU Not Useful



^ permalink raw reply	[flat|nested] 433+ messages in thread

* Re: [9fans] (no subject)
  2010-03-08 18:01   ` lucio
  2010-03-08 19:20     ` Lyndon Nerenberg (VE6BBM/VE7TFX)
@ 2010-03-08 19:41     ` erik quanstrom
  2010-03-08 22:19     ` James Tomaschke
  2 siblings, 0 replies; 433+ messages in thread
From: erik quanstrom @ 2010-03-08 19:41 UTC (permalink / raw)
  To: lucio, 9fans

On Mon Mar  8 13:04:41 EST 2010, lucio@proxima.alt.za wrote:
> > You seem to insist on alien software, why is porting software from
> > lunix a prefered solution?  Most of the solutions are a.) either to
> > problems we don't even have or b.) so awkward in interfacing you just
> > end up writing a native fork anyway.
>
> That's simple pragmatism.  Using Plan 9 without some of the Open
> Source stuff is hard at least for some of us.  And there just aren't
> enough Plan 9 developers to produce alternatives.  Considering the
> number of useful (if poorly implemented) Open Source tools out there,
> I'm sure I'm not being absurd.

regardless, this thread is turning into a trollfest.
minds are made up.  no one is being swayed by
the arguments.  (and all the arguments have already
made the rounds.)  i think the only way to redeem it
is write some code.  failing that, let's at least give this
thread a proper burial.

- erik



^ permalink raw reply	[flat|nested] 433+ messages in thread

* Re: [9fans] (no subject)
  2010-03-08 18:01   ` lucio
@ 2010-03-08 19:20     ` Lyndon Nerenberg (VE6BBM/VE7TFX)
  2010-03-09  4:20       ` lucio
  2010-03-08 19:41     ` erik quanstrom
  2010-03-08 22:19     ` James Tomaschke
  2 siblings, 1 reply; 433+ messages in thread
From: Lyndon Nerenberg (VE6BBM/VE7TFX) @ 2010-03-08 19:20 UTC (permalink / raw)
  To: lucio, 9fans

> And there just aren't
> enough Plan 9 developers to produce alternatives.

Then there cannot possibly be enough to port the auto* abortion.




^ permalink raw reply	[flat|nested] 433+ messages in thread

* Re: [9fans] (no subject)
  2010-03-08 22:53 ` Sascha Retzki
@ 2010-03-08 18:01   ` lucio
  2010-03-08 19:20     ` Lyndon Nerenberg (VE6BBM/VE7TFX)
                       ` (2 more replies)
  0 siblings, 3 replies; 433+ messages in thread
From: lucio @ 2010-03-08 18:01 UTC (permalink / raw)
  To: 9fans

> You seem to insist on alien software, why is porting software from
> lunix a prefered solution?  Most of the solutions are a.) either to
> problems we don't even have or b.) so awkward in interfacing you just
> end up writing a native fork anyway.

That's simple pragmatism.  Using Plan 9 without some of the Open
Source stuff is hard at least for some of us.  And there just aren't
enough Plan 9 developers to produce alternatives.  Considering the
number of useful (if poorly implemented) Open Source tools out there,
I'm sure I'm not being absurd.

++L




^ permalink raw reply	[flat|nested] 433+ messages in thread

* Re: [9fans] (no subject)
  2010-03-08 15:13     ` Patrick Kelly
@ 2010-03-08 15:57       ` Francisco J Ballesteros
  0 siblings, 0 replies; 433+ messages in thread
From: Francisco J Ballesteros @ 2010-03-08 15:57 UTC (permalink / raw)
  To: Fans of the OS Plan 9 from Bell Labs; +Cc: lucio

At lsub we are doing a bit of work on a db for linux.
To make a long story short, autoconf/automake/xmkmf/whatelse?
made the code so non portable that a particular version of suse is
now necessary to run the thing.

Isn't that the opposite of what auto* was trying to achieve?

I'd just say: say no.

On Mon, Mar 8, 2010 at 4:13 PM, Patrick Kelly <kameo76890@gmail.com> wrote:
>
>
>> -----Original Message-----
>> From: 9fans-bounces@9fans.net [mailto:9fans-bounces@9fans.net] On Behalf Of lucio@proxima.alt.za
>> Sent: Sunday, March 07, 2010 11:58 PM
>> To: 9fans@9fans.net
>> Subject: Re: [9fans] (no subject)
>>
>> >> Agreed wholeheartedly.  Thing is, It's autoconf that needs careful
>> >> redesign:
>> >
>> > I don't see any need for autoconf. As one wise person put it to me,
>> > "things like configure and autoconf just mean you don't know how to
>> > write portable code".
>> >
>> Again, agreed, but reality out there suggests many others are still believers, no matter how misguided.  We were discussing making
>> available Open Source ports...
>
> What your discussing is adding massive complexity. I would prefer to not have the tools and programs, and retain simplicity, rather than add outlandish complexity.
>
>>
>> > I still like to point people at plan 9 ports as an example of a
>> > complex system that gets by without this *conf* nonsense.
>>
>> It falls over just enough to be attacked.  Otherwise, p9p source would have been ported back to Plan 9 in its entirety.  It's a shame,
>> really, and with some work it could be fixed, but some of that work is design work.
>>
>> ++L
>>
>> PS: I realise that I'm proposing two nearly orthogonal objectives, sorry that I didn't clarify that sooner.
>
>
>
>



^ permalink raw reply	[flat|nested] 433+ messages in thread

* Re: [9fans] (no subject)
  2010-03-08  4:58   ` lucio
  2010-03-08  6:17     ` Russ Cox
@ 2010-03-08 15:13     ` Patrick Kelly
  2010-03-08 15:57       ` Francisco J Ballesteros
  1 sibling, 1 reply; 433+ messages in thread
From: Patrick Kelly @ 2010-03-08 15:13 UTC (permalink / raw)
  To: lucio, 'Fans of the OS Plan 9 from Bell Labs'



> -----Original Message-----
> From: 9fans-bounces@9fans.net [mailto:9fans-bounces@9fans.net] On Behalf Of lucio@proxima.alt.za
> Sent: Sunday, March 07, 2010 11:58 PM
> To: 9fans@9fans.net
> Subject: Re: [9fans] (no subject)
> 
> >> Agreed wholeheartedly.  Thing is, It's autoconf that needs careful
> >> redesign:
> >
> > I don't see any need for autoconf. As one wise person put it to me,
> > "things like configure and autoconf just mean you don't know how to
> > write portable code".
> >
> Again, agreed, but reality out there suggests many others are still believers, no matter how misguided.  We were discussing making
> available Open Source ports...

What your discussing is adding massive complexity. I would prefer to not have the tools and programs, and retain simplicity, rather than add outlandish complexity.

> 
> > I still like to point people at plan 9 ports as an example of a
> > complex system that gets by without this *conf* nonsense.
> 
> It falls over just enough to be attacked.  Otherwise, p9p source would have been ported back to Plan 9 in its entirety.  It's a shame,
> really, and with some work it could be fixed, but some of that work is design work.
> 
> ++L
> 
> PS: I realise that I'm proposing two nearly orthogonal objectives, sorry that I didn't clarify that sooner.





^ permalink raw reply	[flat|nested] 433+ messages in thread

* Re: [9fans] (no subject)
  2010-03-08  8:54 ` Richard Miller
@ 2010-03-08  9:31   ` lucio
  0 siblings, 0 replies; 433+ messages in thread
From: lucio @ 2010-03-08  9:31 UTC (permalink / raw)
  To: 9fans

>> Thing is, It's autoconf that needs careful
>> redesign
>
> s/redesign/annihilation/

Yes, but even if everybody were to switch to Linux/386 as the only
available platform, there would remain a niche for something like
autoconf, programmers just don't change habits very quickly.  The
trick is to make sure the next instance isn't as monstrous, knowing
that normally the next generation is more monstrous than the previous
one.

Nice thing is, annihilation does not have to be "careful" :-)

++L




^ permalink raw reply	[flat|nested] 433+ messages in thread

* Re: [9fans] (no subject)
  2010-03-08  4:22 lucio
  2010-03-08  4:49 ` ron minnich
@ 2010-03-08  8:54 ` Richard Miller
  2010-03-08  9:31   ` lucio
  2010-03-08 22:53 ` Sascha Retzki
  2 siblings, 1 reply; 433+ messages in thread
From: Richard Miller @ 2010-03-08  8:54 UTC (permalink / raw)
  To: lucio, 9fans

> Thing is, It's autoconf that needs careful
> redesign

s/redesign/annihilation/




^ permalink raw reply	[flat|nested] 433+ messages in thread

* Re: [9fans] (no subject)
  2010-03-08  6:17     ` Russ Cox
@ 2010-03-08  6:22       ` lucio
  0 siblings, 0 replies; 433+ messages in thread
From: lucio @ 2010-03-08  6:22 UTC (permalink / raw)
  To: 9fans

> There is already a tool to port plan9port code back to Plan 9.
> See cp(1).

Touche'.

++L




^ permalink raw reply	[flat|nested] 433+ messages in thread

* Re: [9fans] (no subject)
  2010-03-08  4:58   ` lucio
@ 2010-03-08  6:17     ` Russ Cox
  2010-03-08  6:22       ` lucio
  2010-03-08 15:13     ` Patrick Kelly
  1 sibling, 1 reply; 433+ messages in thread
From: Russ Cox @ 2010-03-08  6:17 UTC (permalink / raw)
  To: lucio, Fans of the OS Plan 9 from Bell Labs

>> I still like to point people at plan 9 ports as an example of a
>> complex system that gets by without this *conf* nonsense.
>
> It falls over just enough to be attacked.  Otherwise, p9p source would
> have been ported back to Plan 9 in its entirety.  It's a shame,
> really, and with some work it could be fixed, but some of that work is
> design work.

There is already a tool to port plan9port code back to Plan 9.
See cp(1).

Russ


^ permalink raw reply	[flat|nested] 433+ messages in thread

* Re: [9fans] (no subject)
  2010-03-08  4:49 ` ron minnich
@ 2010-03-08  4:58   ` lucio
  2010-03-08  6:17     ` Russ Cox
  2010-03-08 15:13     ` Patrick Kelly
  0 siblings, 2 replies; 433+ messages in thread
From: lucio @ 2010-03-08  4:58 UTC (permalink / raw)
  To: 9fans

>> Agreed wholeheartedly.  Thing is, It's autoconf that needs careful
>> redesign:
> 
> I don't see any need for autoconf. As one wise person put it to me,
> "things like configure and autoconf just mean you don't know how to
> write portable code".
> 
Again, agreed, but reality out there suggests many others are still
believers, no matter how misguided.  We were discussing making
available Open Source ports...

> I still like to point people at plan 9 ports as an example of a
> complex system that gets by without this *conf* nonsense.

It falls over just enough to be attacked.  Otherwise, p9p source would
have been ported back to Plan 9 in its entirety.  It's a shame,
really, and with some work it could be fixed, but some of that work is
design work.

++L

PS: I realise that I'm proposing two nearly orthogonal objectives,
sorry that I didn't clarify that sooner.




^ permalink raw reply	[flat|nested] 433+ messages in thread

* Re: [9fans] (no subject)
  2010-03-08  4:22 lucio
@ 2010-03-08  4:49 ` ron minnich
  2010-03-08  4:58   ` lucio
  2010-03-08  8:54 ` Richard Miller
  2010-03-08 22:53 ` Sascha Retzki
  2 siblings, 1 reply; 433+ messages in thread
From: ron minnich @ 2010-03-08  4:49 UTC (permalink / raw)
  To: lucio, Fans of the OS Plan 9 from Bell Labs

On Sun, Mar 7, 2010 at 8:22 PM,  <lucio@proxima.alt.za> wrote:

> Agreed wholeheartedly.  Thing is, It's autoconf that needs careful
> redesign:

I don't see any need for autoconf. As one wise person put it to me,
"things like configure and autoconf just mean you don't know how to
write portable code".

I still like to point people at plan 9 ports as an example of a
complex system that gets by without this *conf* nonsense.

ron



^ permalink raw reply	[flat|nested] 433+ messages in thread

* Re: [9fans] (no subject)
  2010-03-07 19:57     ` erik quanstrom
@ 2010-03-08  4:29       ` lucio
  0 siblings, 0 replies; 433+ messages in thread
From: lucio @ 2010-03-08  4:29 UTC (permalink / raw)
  To: 9fans

> if you want to make an überpackage, just make your
> überpackage depend on everything else.

Is this what I wanted to know all along?

++L




^ permalink raw reply	[flat|nested] 433+ messages in thread

* Re: [9fans] (no subject)
@ 2010-03-08  4:22 lucio
  2010-03-08  4:49 ` ron minnich
                   ` (2 more replies)
  0 siblings, 3 replies; 433+ messages in thread
From: lucio @ 2010-03-08  4:22 UTC (permalink / raw)
  To: 9fans

> I only strongly suggest that you put the contrib gui at the heart of
> what the user sees.

Agreed wholeheartedly.  Thing is, It's autoconf that needs careful
redesign: even though contrib/replica is not as comprehensive as a
revision control even when backed by venti, it is unmatched for Plan 9
purposes.  But that leaves one still at the mercy of autoconf and it
seems to me that the trigger for change ought to come  from Plan 9.
And in case I haven't yet made it clear, I don't have a good enough
picture in my head to suggest a replacement.

In fact, Steve Simon and fgb both have done great work to help there,
but I feel the real answer is still at large.

And if anyone should find this bait irresistible, keep in mind that
the final product needs to be portable across at least a few OS
platforms as well as hardware architectures and that it should
probably be targetting the Plan 9 toolchain rather than GCC (G++ is a
problem, of course, but Go may help there as at least with the NetBSD
packages, the number of C++ offerings is limited.).

++L




^ permalink raw reply	[flat|nested] 433+ messages in thread

* [9fans] (no subject)
       [not found] <mailman.26991.1268008023.1512.9fans@9fans.net>
@ 2010-03-08  0:54 ` - Choc -
  0 siblings, 0 replies; 433+ messages in thread
From: - Choc - @ 2010-03-08  0:54 UTC (permalink / raw)
  To: 9fans

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







[-- Attachment #2: Type: text/html, Size: 136 bytes --]

^ permalink raw reply	[flat|nested] 433+ messages in thread

* Re: [9fans] (no subject)
  2010-03-07 19:16   ` lucio
@ 2010-03-07 19:57     ` erik quanstrom
  2010-03-08  4:29       ` lucio
  0 siblings, 1 reply; 433+ messages in thread
From: erik quanstrom @ 2010-03-07 19:57 UTC (permalink / raw)
  To: lucio, 9fans

> Thing is, the "port" hierarchy (hereto I used "NetBSD package system"
> for the same concept) provides both the hierarchical structure I
> believe is needed to minimise duplication and a description file to
> search for concepts rather than file names.  So, yes, I agree with a
> portion of your suggestion, but not your suggested implementation.  In
> practice, all I'm proposing is replacing directories owned by
> individual contributors with a hierarchy that undergoes a useful
> amount of validation.

this is exactly the reason you need to try contrib.

if you want to make an überpackage, just make your
überpackage depend on everything else.  it doesn't
need to have any files of its own.  i've verified this.
it would be a trivial extension (like 2 lines) to have
contrib/install recursively install dependencies.

- erik



^ permalink raw reply	[flat|nested] 433+ messages in thread

* Re: [9fans] (no subject)
  2010-03-07 19:26         ` lucio
@ 2010-03-07 19:36           ` ron minnich
  0 siblings, 0 replies; 433+ messages in thread
From: ron minnich @ 2010-03-07 19:36 UTC (permalink / raw)
  To: lucio, Fans of the OS Plan 9 from Bell Labs

code-code is better than talk-talk :-) (absolutely no offense
intended, I just enjoyed the phrase!)

i.e. I think a proof of concept will get your further than discussion.
It seems to me you could
even make a copy of the sources tree, set up your idea, and put it out
there for people to try.

I only strongly suggest that you put the contrib gui at the heart of
what the user sees.

thanks

ron



^ permalink raw reply	[flat|nested] 433+ messages in thread

* Re: [9fans] (no subject)
  2010-03-07 18:59       ` Iruata Souza
@ 2010-03-07 19:26         ` lucio
  2010-03-07 19:36           ` ron minnich
  0 siblings, 1 reply; 433+ messages in thread
From: lucio @ 2010-03-07 19:26 UTC (permalink / raw)
  To: 9fans

> while at it, run contrib/gui. when a package is duplicated, it should
> be clear from the package list on the left.

Suppression of duplication is incidental.  What I believe is missing
from sources is a simple mechanism to see if something I'm already
somewhat familiar with has been ported successfully.  If not, then it
would be useful if there was a simple mechanism to add a successful
port to the global availability, with some moderation to discourage
malicious additions.  As for the moderation itself, the simplest form
I can think of is simply that a score be kept of successful use, reset
to zero when a new version is released.  Other options may prove more
practical.

I suspect that all the resistance I encounter is more knee-jerk
reaction to a request for a little bit of additional discipline than
real objection to the concept.  And the usual 9fans culture of wanting
code rather than discussion.  Unfortunately, this is one piece of code
that ought to be planned rather than hacked together: it's hard to
reverse the implementation if it turns out badly.

++L




^ permalink raw reply	[flat|nested] 433+ messages in thread

* Re: [9fans] (no subject)
  2010-03-07 18:14         ` lucio
@ 2010-03-07 19:25           ` cinap_lenrek
  0 siblings, 0 replies; 433+ messages in thread
From: cinap_lenrek @ 2010-03-07 19:25 UTC (permalink / raw)
  To: lucio, 9fans

> That's flawed logic: I may need dot, while you need curses.  It's nice
> if both have been "blessed".

bless a curse! jehova!

--
cinap




^ permalink raw reply	[flat|nested] 433+ messages in thread

* Re: [9fans] (no subject)
  2010-03-07 18:37 ` John Floren
@ 2010-03-07 19:16   ` lucio
  2010-03-07 19:57     ` erik quanstrom
  0 siblings, 1 reply; 433+ messages in thread
From: lucio @ 2010-03-07 19:16 UTC (permalink / raw)
  To: 9fans

> Wouldn't grouping be a matter of placing a "category" file in the
> package? I'm reading "grouping" as the kind of divisions you get in
> Ports, i.e. net, editor, util, language, etc.

Thing is, the "port" hierarchy (hereto I used "NetBSD package system"
for the same concept) provides both the hierarchical structure I
believe is needed to minimise duplication and a description file to
search for concepts rather than file names.  So, yes, I agree with a
portion of your suggestion, but not your suggested implementation.  In
practice, all I'm proposing is replacing directories owned by
individual contributors with a hierarchy that undergoes a useful
amount of validation.

I'm sure that fgb's contrib, possibly with manageable alterations,
will successfully deal with my proposal, with the reservation that we
probably want a selection mechanism that reduces the magnitude of
updates/replications to manageable proportions.  The NetBSD packages
hierarchy skeleton is gargantuan, I think we ought to provide tools to
trim down any new implementation of it, but I have not thought to any
extent how we'd do that.

++L




^ permalink raw reply	[flat|nested] 433+ messages in thread

* Re: [9fans] (no subject)
  2010-03-07 17:42     ` lucio
  2010-03-07 17:53       ` erik quanstrom
@ 2010-03-07 18:59       ` Iruata Souza
  2010-03-07 19:26         ` lucio
  1 sibling, 1 reply; 433+ messages in thread
From: Iruata Souza @ 2010-03-07 18:59 UTC (permalink / raw)
  To: lucio, Fans of the OS Plan 9 from Bell Labs

On Sun, Mar 7, 2010 at 2:42 PM,  <lucio@proxima.alt.za> wrote:
>> We have fgb's contrib, and before that just the INDEX files in /
>> contrib on sources. Neither is a perfect solution, but I don't think
>> the problem here would be addressed by the Labs providing some new
>> resource. Between the above and the wiki, there's plenty of
>> opportunity for folks to make ports known.
>
> I'm merely suggesting a grouping function and I certainly am not in a
> position to prescribe how it should be implemented.  As I mentioned, I
> like the way NetBSD's package does it, but the price is very steep.
> Fgb's contrib sounds very good, I have not had occasion to try it but
> I presume it retains the scattered nature of the contrib directory.
> My choice would be to add a directory wherein to store both modified
> sources and binaries for Open Source projects once they have been
> validated.

who's gonna validate the beasts?

> Of necessity, one would have the version clearly indicated
> and where possible duplications as occur frequently with popular
> packages such a zlib would be removed.  But there seems to me to be a
> need to keep them together, although that may be just that I'm looking
> at the problem from the single perspective of how it's done in NetBSD.

please take 10 minutes to try fgb/contrib.
while at it, run contrib/gui. when a package is duplicated, it should
be clear from the package list on the left.

iru



^ permalink raw reply	[flat|nested] 433+ messages in thread

* Re: [9fans] (no subject)
  2010-03-07 17:47 lucio
@ 2010-03-07 18:37 ` John Floren
  2010-03-07 19:16   ` lucio
  0 siblings, 1 reply; 433+ messages in thread
From: John Floren @ 2010-03-07 18:37 UTC (permalink / raw)
  To: lucio, Fans of the OS Plan 9 from Bell Labs

On Sun, Mar 7, 2010 at 1:09 PM,  <lucio@proxima.alt.za> wrote:
>> we've got fgb's wonderful program and I think we're crazy if we don't
>> build on that.
>
> A deserved compliment, certainly.  Now to figure how to provide the
> grouping I believe is required in addition to the means for
> replication.  And, if I'm not being stupid, some facility to make sure
> that the final product has at least some chance of working according
> to expectations.  Can't expect fgb to deal with that :-)
>
> ++L
>

Wouldn't grouping be a matter of placing a "category" file in the
package? I'm reading "grouping" as the kind of divisions you get in
Ports, i.e. net, editor, util, language, etc.

John
-- 
"Object-oriented design is the roman numerals of computing" -- Rob Pike



^ permalink raw reply	[flat|nested] 433+ messages in thread

* Re: [9fans] (no subject)
  2010-03-07 17:43       ` erik quanstrom
@ 2010-03-07 18:14         ` lucio
  2010-03-07 19:25           ` cinap_lenrek
  0 siblings, 1 reply; 433+ messages in thread
From: lucio @ 2010-03-07 18:14 UTC (permalink / raw)
  To: 9fans

> if you're installing
> all unix->plan 9 ports, perhaps you would be happer
> running unix in the first place.

That's flawed logic: I may need dot, while you need curses.  It's nice
if both have been "blessed".

++L




^ permalink raw reply	[flat|nested] 433+ messages in thread

* Re: [9fans] (no subject)
  2010-03-07 17:53       ` erik quanstrom
@ 2010-03-07 18:06         ` lucio
  0 siblings, 0 replies; 433+ messages in thread
From: lucio @ 2010-03-07 18:06 UTC (permalink / raw)
  To: 9fans

> really?  you haven't even tried it and your trying
> to fit it into a whatever-netbsd-does shoebox?

Well, I do have some idea on how fgb's contrib is meant to work and,
yes, I do look at it from a biased perspective :-) Surely you don't
think that is implicitly flawed logic?

After all, how familiar are you with the NetBSD package system?  Fgb's
contrib is not too different, although it is certainly more relaxed,
in my opinion out of historical necessity.  Again in my opinion the
additional flexibility makes it harder to categorise packages and such
categorisation would be of greater benefit.  But it is just an opinion.

++L




^ permalink raw reply	[flat|nested] 433+ messages in thread

* Re: [9fans] (no subject)
  2010-03-07 17:42     ` lucio
@ 2010-03-07 17:53       ` erik quanstrom
  2010-03-07 18:06         ` lucio
  2010-03-07 18:59       ` Iruata Souza
  1 sibling, 1 reply; 433+ messages in thread
From: erik quanstrom @ 2010-03-07 17:53 UTC (permalink / raw)
  To: lucio, 9fans

> Fgb's contrib sounds very good, I have not had occasion to try it but
> I presume it retains the scattered nature of the contrib directory.
[...]
> I'm looking at the problem from the single perspective of how it's
> done in NetBSD.

really?  you haven't even tried it and your trying
to fit it into a whatever-netbsd-does shoebox?

- erik



^ permalink raw reply	[flat|nested] 433+ messages in thread

* Re: [9fans] (no subject)
@ 2010-03-07 17:47 lucio
  2010-03-07 18:37 ` John Floren
  0 siblings, 1 reply; 433+ messages in thread
From: lucio @ 2010-03-07 17:47 UTC (permalink / raw)
  To: lucio, 9fans

> we've got fgb's wonderful program and I think we're crazy if we don't
> build on that.

A deserved compliment, certainly.  Now to figure how to provide the
grouping I believe is required in addition to the means for
replication.  And, if I'm not being stupid, some facility to make sure
that the final product has at least some chance of working according
to expectations.  Can't expect fgb to deal with that :-)

++L




^ permalink raw reply	[flat|nested] 433+ messages in thread

* Re: [9fans] (no subject)
  2010-03-07 17:31     ` ron minnich
@ 2010-03-07 17:43       ` erik quanstrom
  2010-03-07 18:14         ` lucio
  0 siblings, 1 reply; 433+ messages in thread
From: erik quanstrom @ 2010-03-07 17:43 UTC (permalink / raw)
  To: 9fans

> we've got fgb's wonderful program and I think we're crazy if we don't
> build on that.
>
> Or we're CADT.

haven't you heard?  we're not allowed to do anything
for ourselves anymore.  the mythical (and god like)
Library Writers do this for us.  our job is to glue things
together and port:

http://developers.slashdot.org/story/10/03/07/0043215/Whatever-Happened-To-Programming?art_pos=8&art_pos=9&art_pos=9

if we were to write our own, we would be guilty of
Wasting Resources.  this is a capital offense.

therefore we must port what the Library Writers have
given us.

... or maybe not.  i think contrib is pretty nice.  why
do we need "blessed" packages, away?  if you're installing
all unix->plan 9 ports, perhaps you would be happer
running unix in the first place.

- erik



^ permalink raw reply	[flat|nested] 433+ messages in thread

* Re: [9fans] (no subject)
  2010-03-07  5:05   ` Anthony Sorace
  2010-03-07 17:31     ` ron minnich
@ 2010-03-07 17:42     ` lucio
  2010-03-07 17:53       ` erik quanstrom
  2010-03-07 18:59       ` Iruata Souza
  1 sibling, 2 replies; 433+ messages in thread
From: lucio @ 2010-03-07 17:42 UTC (permalink / raw)
  To: 9fans

> We have fgb's contrib, and before that just the INDEX files in /
> contrib on sources. Neither is a perfect solution, but I don't think
> the problem here would be addressed by the Labs providing some new
> resource. Between the above and the wiki, there's plenty of
> opportunity for folks to make ports known.

I'm merely suggesting a grouping function and I certainly am not in a
position to prescribe how it should be implemented.  As I mentioned, I
like the way NetBSD's package does it, but the price is very steep.
Fgb's contrib sounds very good, I have not had occasion to try it but
I presume it retains the scattered nature of the contrib directory.
My choice would be to add a directory wherein to store both modified
sources and binaries for Open Source projects once they have been
validated.  Of necessity, one would have the version clearly indicated
and where possible duplications as occur frequently with popular
packages such a zlib would be removed.  But there seems to me to be a
need to keep them together, although that may be just that I'm looking
at the problem from the single perspective of how it's done in NetBSD.

++L




^ permalink raw reply	[flat|nested] 433+ messages in thread

* Re: [9fans] (no subject)
  2010-03-07  5:05   ` Anthony Sorace
@ 2010-03-07 17:31     ` ron minnich
  2010-03-07 17:43       ` erik quanstrom
  2010-03-07 17:42     ` lucio
  1 sibling, 1 reply; 433+ messages in thread
From: ron minnich @ 2010-03-07 17:31 UTC (permalink / raw)
  To: Fans of the OS Plan 9 from Bell Labs; +Cc: lucio

On Sat, Mar 6, 2010 at 9:05 PM, Anthony Sorace <a@9srv.net> wrote:
> We have fgb's contrib, and before that just the INDEX files in /contrib on
> sources.

we've got fgb's wonderful program and I think we're crazy if we don't
build on that.

Or we're CADT.

ron



^ permalink raw reply	[flat|nested] 433+ messages in thread

* Re: [9fans] (no subject)
  2010-03-07  9:14   ` Skip Tavakkolian
@ 2010-03-07 11:04     ` lucio
  0 siblings, 0 replies; 433+ messages in thread
From: lucio @ 2010-03-07 11:04 UTC (permalink / raw)
  To: 9fans

>> My gripe here is that it is hard to track what has been ported and
>> what hasn't and repetition isn't helpful.
>
> grep something /n/sources/lsr ?

I wasn't aware of an "lsr", but I don't think that's it, really.  One
needs more than a file name in many instances.  If I had infinite free
resources at my disposal, I'd use the NetBSD packages DESCR files in
some guise or other.

Of course, one would then be tempted (as I have been) to look more
seriously at porting the NetBSD package system to Plan 9.  That's not
out of the question, in fact it's probably not too difficult, but the
residual pain of autoconf for each individual package has already
frightened people with a stronger stomach than mine away.  That is why
I cannot suggest we catch up, but it may be nice to be ready when
eventually the autoconf edifice falls down and something mildly
intelligent takes its place!

Ironically, Plan 9 may be the platform on which a replacement for
autoconf could be designed and implemented.  But that's too close to a
pipedream to be given serious consideration.

++L




^ permalink raw reply	[flat|nested] 433+ messages in thread

* Re: [9fans] (no subject)
  2010-03-07  4:30 ` [9fans] (no subject) lucio
  2010-03-07  5:05   ` Anthony Sorace
@ 2010-03-07  9:14   ` Skip Tavakkolian
  2010-03-07 11:04     ` lucio
  1 sibling, 1 reply; 433+ messages in thread
From: Skip Tavakkolian @ 2010-03-07  9:14 UTC (permalink / raw)
  To: lucio, 9fans

> My gripe here is that it is hard to track what has been ported and
> what hasn't and repetition isn't helpful.

grep something /n/sources/lsr ?




^ permalink raw reply	[flat|nested] 433+ messages in thread

* Re: [9fans] (no subject)
  2010-03-07  4:30 ` [9fans] (no subject) lucio
@ 2010-03-07  5:05   ` Anthony Sorace
  2010-03-07 17:31     ` ron minnich
  2010-03-07 17:42     ` lucio
  2010-03-07  9:14   ` Skip Tavakkolian
  1 sibling, 2 replies; 433+ messages in thread
From: Anthony Sorace @ 2010-03-07  5:05 UTC (permalink / raw)
  To: lucio, Fans of the OS Plan 9 from Bell Labs

We have fgb's contrib, and before that just the INDEX files in /
contrib on sources. Neither is a perfect solution, but I don't think
the problem here would be addressed by the Labs providing some new
resource. Between the above and the wiki, there's plenty of
opportunity for folks to make ports known.



^ permalink raw reply	[flat|nested] 433+ messages in thread

* Re: [9fans] (no subject)
  2010-03-06  9:32 [9fans] nb—search and index notes in files by keyword Peter A. Cejchan
@ 2010-03-07  4:30 ` lucio
  2010-03-07  5:05   ` Anthony Sorace
  2010-03-07  9:14   ` Skip Tavakkolian
  0 siblings, 2 replies; 433+ messages in thread
From: lucio @ 2010-03-07  4:30 UTC (permalink / raw)
  To: 9fans

> you might also want to check out my (ape) port of glimpse
> /n/sources/contrib/pac/sys/src/ape/cmd/txt/glimpse-4.18.6.tbz

I wonder if we can persuade Bell Labs to set up a separate, moderated
section of sources for validated ports?  We've been talking about a
group of moderators for sources in the past, maybe setting it up for
ports from Open Source would be a start?

My gripe here is that it is hard to track what has been ported and
what hasn't and repetition isn't helpful.

++L




^ permalink raw reply	[flat|nested] 433+ messages in thread

* [9fans] (no subject)
@ 2010-02-05  1:53 erik quanstrom
  0 siblings, 0 replies; 433+ messages in thread
From: erik quanstrom @ 2010-02-05  1:53 UTC (permalink / raw)
  To: 9fans

[lucida pala vera]
Subject: abaco fonts

as an experiment, i experimented with a different
html font file.  you can see what's there in contrib
quanstro/abaco.  $htmlfont must be set to point abaco
at the correct font file.

the font files look like this

; cat /lib/font/bit/htmlfont/vera
# format: sf	font
# where s is a 1 character size designator
#	s	small
#	n	normal
#	l	large
#	v	very large
# and face is a 1 character face designator
#	r	roman
#	i	italic
#	b	bold
#	t	typewriter

tr	/lib/font/bit/vera/vera.10.font
sr	/lib/font/bit/vera/vera.12.font
nr	/lib/font/bit/vera/vera.14.font
lr	/lib/font/bit/vera/vera.16.font
vr	/lib/font/bit/vera/vera.20.font

ti	/lib/font/bit/verait/vera.10.font
si	/lib/font/bit/verait/vera.12.font
ni	/lib/font/bit/verait/vera.14.font
li	/lib/font/bit/verait/vera.16.font
vi	/lib/font/bit/verait/vera.20.font

tb	/lib/font/bit/verabd/vera.10.font
sb	/lib/font/bit/verabd/vera.12.font
nb	/lib/font/bit/verabd/vera.14.font
lb	/lib/font/bit/verabd/vera.16.font
vb	/lib/font/bit/verabd/vera.20.font

tt	/lib/font/bit/veram/vera.10.font
st	/lib/font/bit/veram/vera.12.font
nt	/lib/font/bit/veram/vera.14.font
lt	/lib/font/bit/veram/vera.16.font
vt	/lib/font/bit/veram/vera.20.font

- erik



^ permalink raw reply	[flat|nested] 433+ messages in thread

* [9fans] (no subject)
@ 2010-01-18 21:55 erik quanstrom
  0 siblings, 0 replies; 433+ messages in thread
From: erik quanstrom @ 2010-01-18 21:55 UTC (permalink / raw)
  To: 9fans

Subject floating point puzzle

i'm seeing a crash in in _v2d.  unfortunately, i don't
see how this is happening.

8.out 8535: suicide: sys: fp: stack underflow fppc=0x6397 status=0x81e1 pc=0x63a5

however, acid says that the Vlong passed in was all zeros.  the code generating the
call to _v2d is

	overflow = v > vmax*scale;

where
	uvlong v, vmax;
	double scale;

	v = 0; vmax = 2000; scale =1.;

acid: _v2d:x
_3_ {
_1_ {
	lo	0
	hi	0
}
_2_ {
	lols	0
	loms	0
	hils	0
	hims	0
}
}
acid: stk()
_v2d(x=0x0)+0x87 /sys/src/libc/386/vlrt.c:107
[etc]
_main+0x31 /sys/src/libc/386/main9.s:16
acid: fpr()
F0	0
F1	-Inf
F2	0
F3	0
F4	0
F5	0
F6	0
F7	0
control	0x027f
status	0x0161
tag	0xffff
ip offset	0x00006397
cs selector	0x0023
opcode	0x1920
data operand offset	0x2d48
operand selector	0x001b
acid: regs()
PC	0x000063a5 _v2d+0x87  /sys/src/libc/386/vlrt.c:107
SP	0xdfffedc8 ECODE 0xf01006bd EFLAG 0x00010646
CS	0x00000023 DS	 0x0000001b SS	0x0000001b
GS	0xf010001b FS	 0x0000001b ES	0x0000001b
TRAP	0x00000010 math coprocessor error
AX	0x00000000 BX	0x00000000 CX	0x00000000 DX	0x00027254
DI	0x00041920 SI	0x0004191c BP	0xdfffed94

- erik



^ permalink raw reply	[flat|nested] 433+ messages in thread

* [9fans] (no subject)
  2009-10-01 16:49 ` J.R. Mauro
@ 2009-10-01 17:18   ` Pablo Alonso Salas Alvarez
  0 siblings, 0 replies; 433+ messages in thread
From: Pablo Alonso Salas Alvarez @ 2009-10-01 17:18 UTC (permalink / raw)
  To: 9fans

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

 <3aaafc130910010949n143bd697n6b652898233de8f1@mail.gmail.com>
MIME-Version: 1.0

[-- Attachment #2: Type: text/plain, Size: 260 bytes --]



 		 	   		  
_________________________________________________________________
Invite your mail contacts to join your friends list with Windows Live Spaces. It's easy!
http://spaces.live.com/spacesapi.aspx?wx_action=create&wx_url=/friends.aspx&mkt=en-us

[-- Attachment #3: Type: text/html, Size: 438 bytes --]

^ permalink raw reply	[flat|nested] 433+ messages in thread

* [9fans] (no subject)
@ 2009-09-15 22:34 erik quanstrom
  0 siblings, 0 replies; 433+ messages in thread
From: erik quanstrom @ 2009-09-15 22:34 UTC (permalink / raw)
  To: 9fans

Suject: 82583 support

i put a new version of 82563 in my contrib area.
it adds support for 82583 and  ich9 integrated mac.
more interestingly, it uses one block pool per
interface, is intended to reduce ilock contention.
in modest aoe tests, system time was reduced 20%
when using 2 interfaces for aoe traffic.  with a
fast target, i believe the difference would have been
greater.

i'd put in a vote for dropping the Block->ref
(you'll probablly need to drop the unused ref count
if you're going to use this driver directly.)
and adding a integer Block->pool and changing
the signature Block->free function to
	void (*)(Block*, int);
to allow for this kind of block pool management.

- erik



^ permalink raw reply	[flat|nested] 433+ messages in thread

* Re: [9fans] (no subject)
  2009-07-24 17:18 erik quanstrom
@ 2009-07-24 17:20 ` erik quanstrom
  0 siblings, 0 replies; 433+ messages in thread
From: erik quanstrom @ 2009-07-24 17:20 UTC (permalink / raw)
  To: 9fans

On Fri Jul 24 13:20:17 EDT 2009, quanstro@quanstro.net wrote:
> - 9fans.

sorry.  i don't know what marshal did to me.

- erik



^ permalink raw reply	[flat|nested] 433+ messages in thread

* [9fans] (no subject)
@ 2009-07-24 17:18 erik quanstrom
  2009-07-24 17:20 ` erik quanstrom
  0 siblings, 1 reply; 433+ messages in thread
From: erik quanstrom @ 2009-07-24 17:18 UTC (permalink / raw)
  To: 9fans

- 9fans.

trying not to post too much.

> #!/bin/rc
>
> hget http://dictionary.com/browse/$1 | htmlfmt | awk ' /dictionary
> results/, /Cite This Source/ {print } '
> EOF
>
> chmod 755 $home/bin/rc/odict
>
> odict simple

unfortunately the default charset is 8859-1, and in the http headers
dictionary.com sets the charset to utf-8.  this fact is lost on hget,
so this works a little better for me:

hget http://dictionary.com/browse/illustrate|htmlfmt -c UTF-8 |sed -n ' /dictionary results/,/Cite This Source/p'

also, one would really want to urlencode the parameter.
this would allow a lookup of "en masse"

fortunately this little bit of contorted awk

#!/bin/awk -f
# urlencode
# when in doubt, use brute force
function chr(ch,  	i)
{
	for(i = 0; i < 127; i++)
		if(utf(i) == ch)
			return i;
	return 32;
}

{
	o=""
	for(i=1; i<=length($0); i++){
		c = substr($0, i, 1)
		if(match(c, /[a-zA-Z0-9]/) == 0)
			c = sprintf("%%%.2x", chr(c))
		o = o c;
	}
	print o
}

gives us

#!/bin/rc

word=`{urlencode $"*}
hget http://dictionary.com/browse/illustrate |
	htmlfmt -c UTF-8 |
	sed -n ' /dictionary results/,/Cite This Source/p'

- erik



^ permalink raw reply	[flat|nested] 433+ messages in thread

* [9fans] (no subject)
  2009-07-24 16:14 [9fans] Does "as little software as possible" include a modern maht
@ 2009-07-24 17:16 ` erik quanstrom
  0 siblings, 0 replies; 433+ messages in thread
From: erik quanstrom @ 2009-07-24 17:16 UTC (permalink / raw)
  To: 9fans

> #!/bin/rc
>
> hget http://dictionary.com/browse/$1 | htmlfmt | awk ' /dictionary
> results/, /Cite This Source/ {print } '
> EOF
>
> chmod 755 $home/bin/rc/odict
>
> odict simple

unfortunately the default charset is 8859-1, and in the http headers
dictionary.com sets the charset to utf-8.  this fact is lost on hget,
so this works a little better for me:

hget http://dictionary.com/browse/illustrate|htmlfmt -c UTF-8 |sed -n ' /dictionary results/,/Cite This Source/p'

also, one would really want to urlencode the parameter.
this would allow a lookup of "en masse"

fortunately this little bit of contorted awk

#!/bin/awk -f
# urlencode
# when in doubt, use brute force
function chr(ch,  	i)
{
	for(i = 0; i < 127; i++)
		if(utf(i) == ch)
			return i;
	return 32;
}

{
	o=""
	for(i=1; i<=length($0); i++){
		c = substr($0, i, 1)
		if(match(c, /[a-zA-Z0-9]/) == 0)
			c = sprintf("%%%.2x", chr(c))
		o = o c;
	}
	print o
}

gives us

#!/bin/rc

word=`{urlencode $"*}
hget http://dictionary.com/browse/illustrate |
	htmlfmt -c UTF-8 |
	sed -n ' /dictionary results/,/Cite This Source/p'



^ permalink raw reply	[flat|nested] 433+ messages in thread

* [9fans] (no subject)
@ 2009-07-17 21:09 drivers
  0 siblings, 0 replies; 433+ messages in thread
From: drivers @ 2009-07-17 21:09 UTC (permalink / raw)
  To: 9fans

All,

	I've fixed the last bug (thank god) its hard trying to problem solve and learn a language at the same time but at least I'm still having fun (and python isn't like learning C ;).  Additionally now I have this bug which is mutually exclusive from any of the mmap stuff. But at least its registering with the git repository as can be seen below.  The problem is more in this other dulwich thing....which apparently there is a new version of so i'm going to merge that and retry.  Compressing objects certainly gives some nasty Cr output though....

james++


rator_gade% hg clone git://zen-sources.org/zen/THE.git
destination directory: THE.git
fetching from : git://zen-sources.org/zen/THE.git
importing Hg objects into Git
Counting objects: 1592, done.
Compressing objects:   0% (1/1185)
Compressing objects:   1% (12/1185)
Compressing objects:   2% (24/1185)
Compressing objects:   3% (36/1185)
Compressing objects:   4% (48/1185)
Compressing objects:   5% (60/1185)
Compressing objects:   6% (72/1185)
Compressing objects:   7% (83/1185)
Compressing objects:   8% (95/1185)
Compressing objects:   9% (107/1185)
Compressing objects:  10% (119/1185)
Compressing objects:  11% (131/1185)
Compressing objects:  12% (143/1185)
Compressing objects:  13% (155/1185)
Compressing objects:  14% (166/1185)
Compressing objects:  15% (178/1185)
Compressing objects:  16% (190/1185)
Compressing objects:  17% (202/1185)
Compressing objects:  18% (214/1185)
Compressing objects:  19% (226/1185)
Compressing objects:  20% (237/1185)
Compressing objects:  21% (249/1185)
Compressing objects:  22% (261/1185)
Compressing objects:  23% (273/1185)
Compressing objects:  24% (285/1185)
Compressing objects:  25% (297/1185)
Compressing objects:  26% (309/1185)
Compressing objects:  27% (320/1185)
Compressing objects:  28% (332/1185)
Compressing objects:  29% (344/1185)
Compressing objects:  30% (356/1185)
Compressing objects:  31% (368/1185)
Compressing objects:  32% (380/1185)
Compressing objects:  33% (392/1185)
Compressing objects:  34% (403/1185)
Compressing objects:  35% (415/1185)
Compressing objects:  36% (427/1185)
Compressing objects:  37% (439/1185)
Compressing objects:  38% (451/1185)
Compressing objects:  39% (463/1185)
Compressing objects:  40% (474/1185)
Compressing objects:  41% (486/1185)
Compressing objects:  42% (498/1185)
Compressing objects:  43% (510/1185)
Compressing objects:  44% (522/1185)
Compressing objects:  45% (534/1185)
Compressing objects:  46% (546/1185)
Compressing objects:  47% (557/1185)
Compressing objects:  48% (569/1185)
Compressing objects:  49% (581/1185)
Compressing objects:  50% (593/1185)
Compressing objects:  51% (605/1185)
Compressing objects:  52% (617/1185)
Compressing objects:  53% (629/1185)
Compressing objects:  54% (640/1185)
Compressing objects:  55% (652/1185)
Compressing objects:  56% (664/1185)
Compressing objects:  57% (676/1185)
Compressing objects:  58% (688/1185)
Compressing objects:  59% (700/1185)
Compressing objects:  60% (711/1185)
Compressing objects:  61% (723/1185)
Compressing objects:  62% (735/1185)
Compressing objects:  63% (747/1185)
Compressing objects:  64% (759/1185)
Compressing objects:  65% (771/1185)
Compressing objects:  66% (783/1185)
Compressing objects:  67% (794/1185)
Compressing objects:  68% (806/1185)
Compressing objects:  69% (818/1185)
Compressing objects:  70% (830/1185)
Compressing objects:  71% (842/1185)
Compressing objects:  72% (854/1185)
Compressing objects:  73% (866/1185)
Compressing objects:  74% (877/1185)
Compressing objects:  75% (889/1185)
Compressing objects:  76% (901/1185)
Compressing objects:  77% (913/1185)
Compressing objects:  78% (925/1185)
Compressing objects:  79% (937/1185)
Compressing objects:  80% (948/1185)
Compressing objects:  81% (960/1185)
Compressing objects:  82% (972/1185)
Compressing objects:  83% (984/1185)
Compressing objects:  84% (996/1185)
Compressing objects:  85% (1008/1185)
Compressing objects:  86% (1020/1185)
Compressing objects:  87% (1031/1185)
Compressing objects:  88% (1043/1185)
Compressing objects:  89% (1055/1185)
Compressing objects:  90% (1067/1185)
Compressing objects:  91% (1079/1185)
Compressing objects:  92% (1091/1185)
Compressing objects:  93% (1103/1185)
Compressing objects:  94% (1114/1185)
Compressing objects:  95% (1126/1185)
Compressing objects:  96% (1138/1185)
Compressing objects:  97% (1150/1185)
Compressing objects:  98% (1162/1185)
Compressing objects:  99% (1174/1185)
Compressing objects: 100% (1185/1185)
Compressing objects: 100% (1185/1185), done.
Total 1592 (delta 455), reused 1128 (delta 286)
** unknown exception encountered, details follow
** report bug details to http://mercurial.selenic.com/bts/
** or mercurial@selenic.com
** Mercurial Distributed SCM (version 1.3)
** Extensions loaded: bookmarks, hg-git
Traceback (most recent call last):
  File "/bin/hg", line 27, in <module>
    mercurial.dispatch.run()
  File "/sys/python/lib/python2.5/mercurial/dispatch.py", line 16, in run
    sys.exit(dispatch(sys.argv[1:]))
  File "/sys/python/lib/python2.5/mercurial/dispatch.py", line 27, in dispatch
    return _runcatch(u, args)
  File "/sys/python/lib/python2.5/mercurial/dispatch.py", line 43, in _runcatch
    return _dispatch(ui, args)
  File "/sys/python/lib/python2.5/mercurial/dispatch.py", line 449, in _dispatch
    return runcommand(lui, repo, cmd, fullargs, ui, options, d)
  File "/sys/python/lib/python2.5/mercurial/dispatch.py", line 317, in runcommand
    ret = _runcommand(ui, options, cmd, d)
  File "/sys/python/lib/python2.5/mercurial/dispatch.py", line 501, in _runcommand
    return checkargs()
  File "/sys/python/lib/python2.5/mercurial/dispatch.py", line 454, in checkargs
    return cmdfunc()
  File "/sys/python/lib/python2.5/mercurial/dispatch.py", line 448, in <lambda>
    d = lambda: util.checksignature(func)(ui, *args, **cmdoptions)
  File "/sys/python/lib/python2.5/mercurial/util.py", line 370, in check
    return func(*args, **kwargs)
  File "/sys/python/lib/python2.5/mercurial/commands.py", line 635, in clone
    update=not opts.get('noupdate'))
  File "/sys/python/lib/python2.5/mercurial/hg.py", line 286, in clone
    dest_repo.clone(src_repo, heads=revs, stream=stream)
  File "/sys/python/lib/python2.5/mercurial/localrepo.py", line 2176, in clone
    return self.pull(remote, heads)
  File "/usr/james/hg-git/hgrepo.py", line 140, in pull
    git.fetch(remote.path)
  File "/usr/james/hg-git/git_handler.py", line 101, in fetch
    refs = self.fetch_pack(remote)
  File "/usr/james/hg-git/git_handler.py", line 679, in fetch_pack
    commit()
  File "/usr/james/hg-git/dulwich/object_store.py", line 287, in commit
    self.move_in_pack(path)
  File "/usr/james/hg-git/dulwich/object_store.py", line 248, in move_in_pack
    entries = p.sorted_entries()
  File "/usr/james/hg-git/dulwich/pack.py", line 599, in sorted_entries
    ret = list(self.iterentries(resolve_ext_ref, progress=progress))
  File "/usr/james/hg-git/dulwich/pack.py", line 581, in iterentries
    for (offset, type, obj, crc32) in todo:
  File "/usr/james/hg-git/dulwich/pack.py", line 553, in next
    (type, obj, total_size) = unpack_object(self.map, self.offset)
  File "/usr/james/hg-git/dulwich/pack.py", line 391, in unpack_object
    bytes = take_msb_bytes(map, offset)
  File "/usr/james/hg-git/dulwich/pack.py", line 78, in take_msb_bytes
    ret.append(ord(map[offset]))
IndexError: string index out of range
Exception exceptions.AttributeError: "'str' object has no attribute 'close'" in <bound method ObjectIterator.__del__ of <hgext_hgext_hg-git.dulwich.pack.ObjectIterator object at 0x6601AC>> ignored




^ permalink raw reply	[flat|nested] 433+ messages in thread

* [9fans] (no subject)
@ 2009-05-28 11:08 Gregory Pavelcak
  0 siblings, 0 replies; 433+ messages in thread
From: Gregory Pavelcak @ 2009-05-28 11:08 UTC (permalink / raw)
  To: 9fans

[acme.dump bin/ devel/ doc/ guide lib/ sys/ text/ tmp/]
Subject: eqn and unicode

I noticed that sometimes my troff-related questions don't
generate much interest. I hope they aren't considered bad
form, because I am curious about another thing.

If you write the eqn-word for a greek letter, "GAMMA" for
example; eqn passes the unicode character (the output of
Alt-*G) to troff. If, on the other hand, you type Alt-*G in eqn,
it passes `"\f2Γ\fP' to troff, thus producing, by my lights anyway,
a nicer looking character. I was just wondering if this was
intended as a way to give people both a roman-greek letter
and an italic one, or if it was intended to discourage the use
of eqn's letter names in favor of unicode, or if it just sorta
happened. Perhaps none of the above. Anyone know?

My problem is that I developed the habit of using eqn letter-
words, and the output isn't very nice. (Yes, I know I can
define GAMMA %"\f2Γ\fP"%, but I'm still curious.)

Thanks.

Greg



^ permalink raw reply	[flat|nested] 433+ messages in thread

* Re: [9fans] (no subject)
  2009-04-27  4:42 ` lucio
  2009-04-27 11:57   ` lucio
@ 2009-04-27 21:30   ` Steve Simon
  1 sibling, 0 replies; 433+ messages in thread
From: Steve Simon @ 2009-04-27 21:30 UTC (permalink / raw)
  To: lucio, 9fans

> Give or take that all the executables fail, I have enough MINGW
> binutils from the NetBSD package to convince me that MINGW can be
> built and no doubt some debugging will soon take care of the stumbling
> blocks.
>
> It is true that debugging is going to be hard without symbol
> information (one more good reason to go the ELF route for my GCC
> model, in my opinion) and that I need a real implementation of the
> SEEK syscall before I start on the debugging, but these are
> surmountable obstacles.  I guess you need to keep holding thumbs.
>

Sorry, this went completely over my head. It sounds like you
have achieved somthing impressive but I'am afraid I don't understand.

-Steve



^ permalink raw reply	[flat|nested] 433+ messages in thread

* Re: [9fans] (no subject)
  2009-04-27  4:42 ` lucio
@ 2009-04-27 11:57   ` lucio
  2009-04-27 21:30   ` Steve Simon
  1 sibling, 0 replies; 433+ messages in thread
From: lucio @ 2009-04-27 11:57 UTC (permalink / raw)
  To: lucio, 9fans

>> 	1) build mingw for plan9
>
> Give or take that all the executables fail, I have enough MINGW
> binutils from the NetBSD package to convince me that MINGW can be
> built and no doubt some debugging will soon take care of the stumbling
> blocks.

My apologies, this was meant to be private mail to Steve Simon.

++L




^ permalink raw reply	[flat|nested] 433+ messages in thread

* Re: [9fans] (no subject)
  2009-04-23 11:38 Steve Simon
  2009-04-23 12:34 ` Charles Forsyth
  2009-04-23 19:32 ` lucio
@ 2009-04-27  4:42 ` lucio
  2009-04-27 11:57   ` lucio
  2009-04-27 21:30   ` Steve Simon
  2 siblings, 2 replies; 433+ messages in thread
From: lucio @ 2009-04-27  4:42 UTC (permalink / raw)
  To: 9fans

> 	1) build mingw for plan9

Give or take that all the executables fail, I have enough MINGW
binutils from the NetBSD package to convince me that MINGW can be
built and no doubt some debugging will soon take care of the stumbling
blocks.

It is true that debugging is going to be hard without symbol
information (one more good reason to go the ELF route for my GCC
model, in my opinion) and that I need a real implementation of the
SEEK syscall before I start on the debugging, but these are
surmountable obstacles.  I guess you need to keep holding thumbs.

++L

PS: Oh, and Linuxemu may have to become BSDemu in due course, too.
But I have too much to learn before I can treat that as an option.




^ permalink raw reply	[flat|nested] 433+ messages in thread

* Re: [9fans] (no subject)
  2009-04-23 11:38 Steve Simon
  2009-04-23 12:34 ` Charles Forsyth
@ 2009-04-23 19:32 ` lucio
  2009-04-27  4:42 ` lucio
  2 siblings, 0 replies; 433+ messages in thread
From: lucio @ 2009-04-23 19:32 UTC (permalink / raw)
  To: 9fans

> anyone know of any other (simpler) options?

Inferno utils?  The binaries for NT?

++L




^ permalink raw reply	[flat|nested] 433+ messages in thread

* Re: [9fans] (no subject)
  2009-04-23 17:17     ` erik quanstrom
@ 2009-04-23 17:28       ` David Leimbach
  0 siblings, 0 replies; 433+ messages in thread
From: David Leimbach @ 2009-04-23 17:28 UTC (permalink / raw)
  To: Fans of the OS Plan 9 from Bell Labs; +Cc: lucio

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

On Thu, Apr 23, 2009 at 10:17 AM, erik quanstrom <quanstro@quanstro.net>wrote:

> > back, the GAS pass failed with a segmentation violation.
>
> unfortunate!  that's gotta hurt.  ☺
>
> - erik
>
> Seems like you'd have to change your pants after a GAS pass segmentation
violation.

[-- Attachment #2: Type: text/html, Size: 598 bytes --]

^ permalink raw reply	[flat|nested] 433+ messages in thread

* Re: [9fans] (no subject)
  2009-04-23 17:13   ` lucio
@ 2009-04-23 17:17     ` erik quanstrom
  2009-04-23 17:28       ` David Leimbach
  0 siblings, 1 reply; 433+ messages in thread
From: erik quanstrom @ 2009-04-23 17:17 UTC (permalink / raw)
  To: lucio, 9fans

> back, the GAS pass failed with a segmentation violation.

unfortunate!  that's gotta hurt.  ☺

- erik



^ permalink raw reply	[flat|nested] 433+ messages in thread

* Re: [9fans] (no subject)
  2009-04-23 12:34 ` Charles Forsyth
  2009-04-23 13:07   ` Devon H. O'Dell
@ 2009-04-23 17:13   ` lucio
  2009-04-23 17:17     ` erik quanstrom
  1 sibling, 1 reply; 433+ messages in thread
From: lucio @ 2009-04-23 17:13 UTC (permalink / raw)
  To: 9fans

> lcc is nothing like as hard to compile as gcc (which has got worse, much worse, over the years).
> funnily enough, my gcc bootstrap compilation is still going (on a multi-core linux machine).
> it started over an hour ago.  bizarre.

...  and when I eventually completed it under NetBSD, a few months
back, the GAS pass failed with a segmentation violation.  I wonder if
it's been fixed since...

++L




^ permalink raw reply	[flat|nested] 433+ messages in thread

* Re: [9fans] (no subject)
  2009-04-23 12:34 ` Charles Forsyth
@ 2009-04-23 13:07   ` Devon H. O'Dell
  2009-04-23 17:13   ` lucio
  1 sibling, 0 replies; 433+ messages in thread
From: Devon H. O'Dell @ 2009-04-23 13:07 UTC (permalink / raw)
  To: Fans of the OS Plan 9 from Bell Labs

2009/4/23 Charles Forsyth <forsyth@terzarima.net>:
> lcc is nothing like as hard to compile as gcc (which has got worse, much worse, over the years).
> funnily enough, my gcc bootstrap compilation is still going (on a multi-core linux machine).
> it started over an hour ago.  bizarre.

(my apologies for diverging the topic from both Plan 9 and the
original question)

What languages are you compiling? on my 3-core amd processor, it takes
10 minutes to compile c and c++.

Steve: I know there are some really good resources about PE online, as
well as several on MSDN that might contain more information about what
Windows will actually do with a PE. I don't believe they are required
to be relocatable, as even Windows 7 will still run Win9x binaries,
and I'm fairly sure that there wasn't the ability to relocate
executables back then.

--dho



^ permalink raw reply	[flat|nested] 433+ messages in thread

* Re: [9fans] (no subject)
  2009-04-23 11:38 Steve Simon
@ 2009-04-23 12:34 ` Charles Forsyth
  2009-04-23 13:07   ` Devon H. O'Dell
  2009-04-23 17:13   ` lucio
  2009-04-23 19:32 ` lucio
  2009-04-27  4:42 ` lucio
  2 siblings, 2 replies; 433+ messages in thread
From: Charles Forsyth @ 2009-04-23 12:34 UTC (permalink / raw)
  To: 9fans

lcc is nothing like as hard to compile as gcc (which has got worse, much worse, over the years).
funnily enough, my gcc bootstrap compilation is still going (on a multi-core linux machine).
it started over an hour ago.  bizarre.



^ permalink raw reply	[flat|nested] 433+ messages in thread

* [9fans] (no subject)
@ 2009-04-23 11:38 Steve Simon
  2009-04-23 12:34 ` Charles Forsyth
                   ` (2 more replies)
  0 siblings, 3 replies; 433+ messages in thread
From: Steve Simon @ 2009-04-23 11:38 UTC (permalink / raw)
  To: 9fans

Hi,

I have decided to try to cross compile to windows again, as I see it
here are my options:
	1) build mingw for plan9
		This means getting gcc to compile under kenc - non-trivial
	2) build lcc on plan9
		ditto
	3) build pcc for plan9
		ditto (though nothing like as bad as the above)
		sadly pcc needs yasm or mingw-as + mingw ar and mingw ld so I
		don't win much.
	4) write a parser to understand windows header files and generate
		assembly wrappers so I can use kenc. Then I just need to build
		a PE executable backend.

4 seems the most attractive, however I believe all windows executables
are still relocatable, but this feature is rarely used by the XP/Win2k3 etc.

anyone know any more.

anyone know of any other (simpler) options?

I guess my ultimate sanction might be mingw for Linux running under linuxemu
though this feels a bit of a copout.

-Steve



^ permalink raw reply	[flat|nested] 433+ messages in thread

* [9fans] (no subject)
  2009-02-23  0:13 [9fans] actionfs mattmobile
@ 2009-03-05 13:16 ` cej
  0 siblings, 0 replies; 433+ messages in thread
From: cej @ 2009-03-05 13:16 UTC (permalink / raw)
  To: 9fans

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




-----Original Message-----
From: 9fans-bounces@9fans.net on behalf of mattmobile@proweb.co.uk
Sent: Mon 2/23/2009 1:13 AM
To: 9fans@9fans.net
Subject: [9fans] actionfs
 
Hi,

this one was an experiment

/n/sources/contrib/maht/actionfs.c

invoked with a regex like  actionfs (file.mpg).([0-9]+).(ppm)

if you then 

cat /n/actionfs/file.mpg.100.ppm

actionfs responds with the output from executing

/bin/action-read $fd file.mpg.100.ppm file.mpg 100 ppm

where $fd will be an fd to write to 

i.e. trivially action-read would be something like

----
#!/bin/rc

fd = $1
shift

echo $* > /fd/$fd

-----

The coresponding action-write also works


----
#!/bin/rc

fd = $1
shift

cat /fd/$fd > /dev/null # or whatever

-----

I wrote it specifically to extract individual frames from video files using ffmpeg on Linux and 
bring them into Plan9 for processing but generalized the arguments in case I thought of something 
interesting later.

My first round of experiment went like this

cpu% cat /bin/action-read
#!/bin/rc

# expect fd fullname videoname frameno
fname = `{echo -n $3 | tr ! '/'}
{
	ssh storm single_frame $fname $4 
} > /fd/$1


cpu% cat /n/storm/home/maht/bin/single_frame
#!/usr/local/plan9/bin/rc

# expect filename frameno

timer = `{echo $2  | awk ' { printf "%d.%02d\n",  $1/ 25, 4 * ($1 % 25) }'}
{
	ffmpeg -i $1 -t 00.001 -ss $timer /tmp/frame_$pid ^_%d.ppm
	cat /tmp/frame_$pid ^_1.ppm 
	rm -f frame_$pid ^_1.ppm
	rm -f frame_$pid ^_2.ppm  # stupid ffmpeg outputs 2 frames (sometimes)
}  >[2] /dev/null


I was then using imgfs to calculate the average rgb value to look for black frames but (unsurprisingly) it was taking too long (4 secs per frame) esp. as the Plan9 I was using is in Qemu, cue installing Plan 9 on my terminal.

The ffmpeg part on the Linux side (2Ghz Opteron) was taking 1 second on its own so I have to come up with some sort of look ahead cache which is contrary to the idea, I may as well just convert the whole file to ppms at the start! I've not looked if it is I/O or CPU - perhaps a bit of both.

I've not got round to doing it on my fresh terminal yet. I've got a new 3.2Ghz Dual Xeon server to migrate to and a Quad Core terminal to play with so we'll see how that works out.

I was hoping to get Xcpu in there but I couldn't see how to get the Plan9 part working though I have the Linux bits up.

I have a couple of decent OSX boxes available too (one PPC one Intel) but I gave up getting it to compile :)

too many projects .....

matt



[-- Attachment #2: winmail.dat --]
[-- Type: application/ms-tnef, Size: 3785 bytes --]

^ permalink raw reply	[flat|nested] 433+ messages in thread

* Re: [9fans] (no subject)
  2009-02-24  1:25     ` sixforty
@ 2009-02-24  2:13       ` Anthony Sorace
  0 siblings, 0 replies; 433+ messages in thread
From: Anthony Sorace @ 2009-02-24  2:13 UTC (permalink / raw)
  To: Fans of the OS Plan 9 from Bell Labs

fgb has ported 4th; it's in his contrib dir, both as a tar file and a
contrib package. i thought i remembered seeing another, but it's not
on the contrib index page.



^ permalink raw reply	[flat|nested] 433+ messages in thread

* Re: [9fans] (no subject)
  2009-02-24  1:02   ` Jeff Sickel
@ 2009-02-24  1:25     ` sixforty
  2009-02-24  2:13       ` Anthony Sorace
  0 siblings, 1 reply; 433+ messages in thread
From: sixforty @ 2009-02-24  1:25 UTC (permalink / raw)
  To: Fans of the OS Plan 9 from Bell Labs

Jeff Sickel wrote:
>
> On Feb 23, 2009, at 6:48 PM, ron minnich <rminnich@gmail.com> wrote:
>
>>>
>>>
>>>
>>>
>> sure but what's the point? Couldn't you grab one of the forth
>> interpreters?
>
> Forth on Plan 9? That would be great. Then I'd have a bit more
> leverage in getting a new PIC based board to talk with Plan 9.
> (brucee's recent 9p example's notwithstanding)
>
> -jas
>
>
>
>
Someone in freenode #forth said they'd just ported 4tH to Plan 9. I
don't log IRC, wish I'd payed more attention. Maybe they've shared it by
now. I don't doubt them, as 4tH's source comes with instructions on how
to build with no libs and only 2 syscalls (1 is 'printf' replacement).

sixforty




^ permalink raw reply	[flat|nested] 433+ messages in thread

* Re: [9fans] (no subject)
  2009-02-24  0:48 ` ron minnich
@ 2009-02-24  1:02   ` Jeff Sickel
  2009-02-24  1:25     ` sixforty
  0 siblings, 1 reply; 433+ messages in thread
From: Jeff Sickel @ 2009-02-24  1:02 UTC (permalink / raw)
  To: Fans of the OS Plan 9 from Bell Labs


On Feb 23, 2009, at 6:48 PM, ron minnich <rminnich@gmail.com> wrote:

>>
>>
>>
>>
> sure but what's the point? Couldn't you grab one of the forth
> interpreters?

Forth on Plan 9?  That would be great.  Then I'd have a bit more
leverage in getting a new PIC based board to talk with Plan 9.
(brucee's recent 9p example's notwithstanding)

-jas




^ permalink raw reply	[flat|nested] 433+ messages in thread

* Re: [9fans] (no subject)
  2009-02-24  0:29 mattmobile
@ 2009-02-24  0:48 ` ron minnich
  2009-02-24  1:02   ` Jeff Sickel
  0 siblings, 1 reply; 433+ messages in thread
From: ron minnich @ 2009-02-24  0:48 UTC (permalink / raw)
  To: Fans of the OS Plan 9 from Bell Labs

On Mon, Feb 23, 2009 at 4:29 PM,  <mattmobile@proweb.co.uk> wrote:
> oops I forgot carriage returns get converted in email
> imagine # is a ^m
>
>
> pu% /n/sources/contrib/maht/rc/til
> abc¯def#123#
> emit
> abc def
> 123
> : emit4 emit emit emit emit
> # 1 2 3 emit4
> 321
> 1 # swp 3 2 swp dup dup drop emit4 emit
> 3321
>
> does this make sense / of interest to anyone :)
>

sure but what's the point? Couldn't you grab one of the forth interpreters?

ron



^ permalink raw reply	[flat|nested] 433+ messages in thread

* [9fans] (no subject)
@ 2009-02-24  0:29 mattmobile
  2009-02-24  0:48 ` ron minnich
  0 siblings, 1 reply; 433+ messages in thread
From: mattmobile @ 2009-02-24  0:29 UTC (permalink / raw)
  To: 9fans

oops I forgot carriage returns get converted in email
imagine # is a ^m


pu% /n/sources/contrib/maht/rc/til
abc¯def#123#
emit
abc def
123
: emit4 emit emit emit emit
# 1 2 3 emit4
321
1 # swp 3 2 swp dup dup drop emit4 emit
3321

does this make sense / of interest to anyone :)

matt



^ permalink raw reply	[flat|nested] 433+ messages in thread

* [9fans] (no subject)
@ 2009-01-02  2:30 erik quanstrom
  0 siblings, 0 replies; 433+ messages in thread
From: erik quanstrom @ 2009-01-02  2:30 UTC (permalink / raw)
  To: 9fans

Suject: scuzz(8) man bug

man -P, man or the magicman html versions
all have a similar bug.  the .IR macro appends a
a spurious ".}f".

     SEE ALSO
          sd(3)
          Small Computer System Interface - 2 (X3T9.2/86-109), .}f

shortening the italic portion by 4 characters makes the problem
go away.

- erik



^ permalink raw reply	[flat|nested] 433+ messages in thread

* Re: [9fans] (no subject)
  2008-12-06 23:42 ` Roman Shaposhnik
@ 2008-12-07  0:04   ` erik quanstrom
  0 siblings, 0 replies; 433+ messages in thread
From: erik quanstrom @ 2008-12-07  0:04 UTC (permalink / raw)
  To: 9fans

> This one is easy: Plan 9 (and 9P in particular) doesn't have to have
> the redeeming quality of high adoption rate in order to justify
> an excessive engineering complexity. It is not complex at all.
> It is small and elegant. Whether that compactness and elegance
> sometimes prevents it from being considered "enterprise grade"
> is an open question (at least for me it is). The experience of
> Coraid suggests that it might actually be a nice tool even for those
> kinds of problems.

i believe the term of art is "enterpriseiness".

- erik



^ permalink raw reply	[flat|nested] 433+ messages in thread

* Re: [9fans] (no subject)
  2008-12-06 19:28 Dave Eckhardt
@ 2008-12-06 23:42 ` Roman Shaposhnik
  2008-12-07  0:04   ` erik quanstrom
  0 siblings, 1 reply; 433+ messages in thread
From: Roman Shaposhnik @ 2008-12-06 23:42 UTC (permalink / raw)
  To: Fans of the OS Plan 9 from Bell Labs

On Dec 6, 2008, at 11:28 AM, Dave Eckhardt wrote:
> More globally, if the high adoption rate of NFS is an argument
> in favor of its architecture,

It is most definitely not. At least in my opinion. However, adoption
is the only thing that I know of that can potentially justify excessive
*engineering* complexity. Personally I'd call any system that is overly
complex *and* has a low adoption rate (for whatever reason) after
at least 5 years of having been exposed to the market place, a
theoretical artifact of computer science. The usefulness of which
is commonly measured by the number of good CS papers dedicated
to studying it.

I do understand that for you AFS also has a huge redeeming factor
of being useful in solving a particular problem. It is hard to say
whether
it is the best tool for the job, or the only one (it would be
interesting if
you answered to Erik's question on this list). But perhaps the
difference
of opinion here stems from the fact that to *you* it does feel like
an "enterprise grade" to me (as an outside observer) the "enterprise
grade" must be vetted by the market place. Hence my interest in
the adoption rate.

> and the low adoption rate of AFS is an argument against its
> architecture,
> why are you reading a Plan 9 mailing list...?

This one is easy: Plan 9 (and 9P in particular) doesn't have to have
the redeeming quality of high adoption rate in order to justify
an excessive engineering complexity. It is not complex at all.
It is small and elegant. Whether that compactness and elegance
sometimes prevents it from being considered "enterprise grade"
is an open question (at least for me it is). The experience of
Coraid suggests that it might actually be a nice tool even for those
kinds of problems.

>> To some extent, the popularity of NFS (is there any NAS box that
>> talks AFS?) and Linux is one big testament to the power of "good
>> enough" or "worse is better".
>>
>> Designing "enterprise grade" things is very hard work.
>> Implementing them is even harder. The good news is that it
>> pays well. The bad news is that you have to be really brave to
>> withstand the fear of being obsolete by changing requirements.
>
> I don't get this.  I don't follow the NFS protocol development
> carefully,

Just to clarify: this thread is really not about me defending NFS.
I can't call it elegant. But I can certainly call it "good enough".
So at least it succeeds as a lowest common denominator for
data sharing. Well, so far at least.

> That is, I think the requirements are *not* changing, but rather
> that NFS is slowly realizing that those things *are* requirements.

Agreed. And I believe both FSs do miss the point. NFS4 especially
so. The question is really not about the most efficient implementation
of POSIX filesystem semantics over the network, but rather whether
POSIX expectations are reasonable in the first place. Plan 9 was
bold enough to simply discount some of those expectations and
the resulting system proved to be much better than what a typical
UNIX provides these days.

Now, what would be really interesting is to see is how the kinds
of requirements that pNFS has can be satisfied with Plan9/9P
approach.

Thanks,
Roman.



^ permalink raw reply	[flat|nested] 433+ messages in thread

* [9fans] (no subject)
@ 2008-12-06 19:28 Dave Eckhardt
  2008-12-06 23:42 ` Roman Shaposhnik
  0 siblings, 1 reply; 433+ messages in thread
From: Dave Eckhardt @ 2008-12-06 19:28 UTC (permalink / raw)
  To: 9fans

> Fair enough.  But what's the adoption overall?

Among organizations who want 10,000+ users sharing a single
(apparent) file system?  I know there are organizations which
would dramatically benefit from that kind of infrastructure, who
don't have it, because they are using NFS (e.g., a university CS
department where the grad students use one NFS infrastructure
and the undergrads use another, and there is no way to set up
a group for all members of a class!).  I think each of those
organizations is an argument for AFS, not for NFS.

More globally, if the high adoption rate of NFS is an argument
in favor of its architecture, and the low adoption rate of AFS
is an argument against its architecture, why are you reading a
Plan 9 mailing list...?

> To some extent, the popularity of NFS (is there any NAS box that
> talks AFS?) and Linux is one big testament to the power of "good
> enough" or "worse is better".
>
> Designing "enterprise grade" things is very hard work.
> Implementing them is even harder. The good news is that it
> pays well. The bad news is that you have to be really brave to
> withstand the fear of being obsolete by changing requirements.

I don't get this.  I don't follow the NFS protocol development
carefully, but honestly it seems to me that (a) it's getting
a lot bigger over time, and (b) this is substantially by adding
features (leases, non-silly authentication, user-defined groups)
which were in AFS in the 80's.  That is, I think the requirements
are *not* changing, but rather that NFS is slowly realizing that
those things *are* requirements.

Now there is a fine economic/practical argument for gradually
evolving a system toward a desired set of goals, so that you
spread upgrade, training, and incompatibility costs out over
time, so that evolving NFS into AFS over 35 years makes more
sense than forcing AFS painfully on people all at once.
Personally I think it's been worthwhile to a lot of people at
a lot of organizations to get 25 years of early access to
certain features.

None of this is to say that AFS doesn't have unnecessary cruft,
or, again, that it isn't possible to meet the same goals with
less complexity now that we know more.

Dave Eckhardt



^ permalink raw reply	[flat|nested] 433+ messages in thread

* Re: [9fans] (no subject)
  2008-11-21 21:33 ` Kenji Arisawa
@ 2008-11-21 22:55   ` erik quanstrom
  0 siblings, 0 replies; 433+ messages in thread
From: erik quanstrom @ 2008-11-21 22:55 UTC (permalink / raw)
  To: arisawa, 9fans

> Hello,
>
> If such an attack continues for some minutes and the server does not
> reject the connections
> the server will create thousands of smtpd processes and might be hung
> up.
>
> Kenji Arisawa
>

but that's not what happens.  waiting for 15 seconds decreases the
load to near zero.  it's not a ddos attack.  in fact, most of the trouble
came from a single zombie.

if it were, i would need to see more than 10 connections/second
before i would have a significant backlog.  i can easily afford 150
smtpds sleeping.

- erik



^ permalink raw reply	[flat|nested] 433+ messages in thread

* Re: [9fans] (no subject)
  2008-11-21 18:28 erik quanstrom
@ 2008-11-21 21:33 ` Kenji Arisawa
  2008-11-21 22:55   ` erik quanstrom
  0 siblings, 1 reply; 433+ messages in thread
From: Kenji Arisawa @ 2008-11-21 21:33 UTC (permalink / raw)
  To: Fans of the OS Plan 9 from Bell Labs

Hello,

If such an attack continues for some minutes and the server does not
reject the connections
the server will create thousands of smtpd processes and might be hung
up.

Kenji Arisawa

On 2008/11/22, at 3:28, erik quanstrom wrote:

> Subjet: email attacks
>
> since our friends in sweeden helped out our spammer friends
> get back on line, i've seen a lot more attacks.  today i've been
> getting ~10 connections/sec.  fortunately its from a small
> number of machines, so this trick helps alot:
>
> /n/dump/2008/1121/sys/src/cmd/upas/smtp/smtpd.c:348,353 - smtpd.c:
> 348,355
>   				if(!qflag)
>   					syslog(0, "smtpd", "Hung up on %s; "
>   						"claimed to be %s", nci->rsys, him);
> + 				if(Dflag)
> + 					sleep(delaysecs()*1000);
>   				reply("554 5.7.0 Liar!\r\n");
>   				exits("client pretended to be us");
>   				return;
>
> oddly, i've found that adding a few of the hosts as -k flags stops
> the attack
> entirely.
>
> - erik
>
>




^ permalink raw reply	[flat|nested] 433+ messages in thread

* [9fans] (no subject)
@ 2008-11-21 18:28 erik quanstrom
  2008-11-21 21:33 ` Kenji Arisawa
  0 siblings, 1 reply; 433+ messages in thread
From: erik quanstrom @ 2008-11-21 18:28 UTC (permalink / raw)
  To: 9fans

Subjet: email attacks

since our friends in sweeden helped out our spammer friends
get back on line, i've seen a lot more attacks.  today i've been
getting ~10 connections/sec.  fortunately its from a small
number of machines, so this trick helps alot:

/n/dump/2008/1121/sys/src/cmd/upas/smtp/smtpd.c:348,353 - smtpd.c:348,355
  				if(!qflag)
  					syslog(0, "smtpd", "Hung up on %s; "
  						"claimed to be %s", nci->rsys, him);
+ 				if(Dflag)
+ 					sleep(delaysecs()*1000);
  				reply("554 5.7.0 Liar!\r\n");
  				exits("client pretended to be us");
  				return;

oddly, i've found that adding a few of the hosts as -k flags stops the attack
entirely.

- erik




^ permalink raw reply	[flat|nested] 433+ messages in thread

* Re: [9fans] (no subject)
  2008-08-14 19:09 akumar
@ 2008-08-14 19:14 ` andrey mirtchovski
  0 siblings, 0 replies; 433+ messages in thread
From: andrey mirtchovski @ 2008-08-14 19:14 UTC (permalink / raw)
  To: Fans of the OS Plan 9 from Bell Labs

I haven't used either of those in a long time. If you send me changes
I'd be glad to put them on sources. If you want to take over
maintaining them we can easily arrange that :)

andrey

On Thu, Aug 14, 2008 at 1:09 PM,  <akumar@sounine.nanosouffle.net> wrote:
> Subject 'Irc' client program at Andrey's Contrib
>
> Hello,
>
> I've recently been trying out various IRC clients for Plan 9, and of
> the two that suited me most (irc7 and Irc), I find Irc to be better
> formatted and polished, thusly, more usable.
> Anyhow, I've noticed a couple of problems with the program:
>        when I receive a private message from someone on IRC, acme
> opens up an Errors dialog stating that,
> "new newline at 61 - <" and "new newline at 63 - <" I have a feeling
> this has something to do with the formatting of WHO queries, so it
> seems to be minor.  On the other hand, there is a greater problem with
> sending messages to nicks or channels: typing at the end of the Chat
> window in acme, and hitting enter, causes another Errors pop up, which
> states: "address out of range" -- each time that a message is sent.
> And so it turns out, these messages are never sent (to the channel or
> user).
>
> So, perhaps, if this project is not yet antiquated, someone can help
> sort these problems out.  :)
>
>
> Regards
>
>
>



^ permalink raw reply	[flat|nested] 433+ messages in thread

* [9fans] (no subject)
@ 2008-08-14 19:09 akumar
  2008-08-14 19:14 ` andrey mirtchovski
  0 siblings, 1 reply; 433+ messages in thread
From: akumar @ 2008-08-14 19:09 UTC (permalink / raw)
  To: 9fans

Subject 'Irc' client program at Andrey's Contrib

Hello,

I've recently been trying out various IRC clients for Plan 9, and of
the two that suited me most (irc7 and Irc), I find Irc to be better
formatted and polished, thusly, more usable.
Anyhow, I've noticed a couple of problems with the program:
	when I receive a private message from someone on IRC, acme
opens up an Errors dialog stating that,
"new newline at 61 - <" and "new newline at 63 - <" I have a feeling
this has something to do with the formatting of WHO queries, so it
seems to be minor.  On the other hand, there is a greater problem with
sending messages to nicks or channels: typing at the end of the Chat
window in acme, and hitting enter, causes another Errors pop up, which
states: "address out of range" -- each time that a message is sent.
And so it turns out, these messages are never sent (to the channel or
user).

So, perhaps, if this project is not yet antiquated, someone can help
sort these problems out.  :)


Regards




^ permalink raw reply	[flat|nested] 433+ messages in thread

* Re: [9fans] (no subject)
  2008-07-21 13:26 ` [9fans] (no subject) kokamoto
@ 2008-07-21 14:45   ` a
  0 siblings, 0 replies; 433+ messages in thread
From: a @ 2008-07-21 14:45 UTC (permalink / raw)
  To: 9fans

// You are not using Plan 9 anymore then, rather you are
// using something similar to Plan 9.

I don't think it's that simple. I understand the value of running a
native Plan 9 installation (self-sufficiency is an almost universal
value), but we don't hear the same complaints when we look at
Inferno: stuff built from /emu is just as much "real" Inferno as
stuff built from /os. We don't think of using the other hardware
virtualizers as not being "real" Plan 9, even the ones that take
kernel modifications.

9vx just feels like cheating because it's so much easier.

Anthony




^ permalink raw reply	[flat|nested] 433+ messages in thread

* [9fans] (no subject)
  2008-07-19  2:37 [9fans] 9vx and local file systems Russ Cox
@ 2008-07-21 13:26 ` kokamoto
  2008-07-21 14:45   ` a
  0 siblings, 1 reply; 433+ messages in thread
From: kokamoto @ 2008-07-21 13:26 UTC (permalink / raw)
  To: 9fans

> The advantage of 9vx over drawterm, for me, is that 9vx
> doesn't require a cpu server.

You are not using Plan 9 anymore then, rather you are using something
similar to Plan 9.

I felt that Plan 9 is abused by 9vx, which I felt at first glance, but
at that time I didn't want to say this...

I prefer drawterm because it stands in the Plan 9 world.

Kenji   --just my opinion--




^ permalink raw reply	[flat|nested] 433+ messages in thread

* Re: [9fans] (no subject)
  2008-03-19 12:41 ` erik quanstrom
@ 2008-03-19 17:16   ` Lyndon Nerenberg
  0 siblings, 0 replies; 433+ messages in thread
From: Lyndon Nerenberg @ 2008-03-19 17:16 UTC (permalink / raw)
  To: Fans of the OS Plan 9 from Bell Labs


On 2008-Mar-19, at 05:41 , erik quanstrom wrote:

>> also, upas/fs -f /imaps can't authenticate with cram-md5.
>
> i have had similar problems with outlook express.  i didn't get a
> chance
> to debug as i don't have a windows box.

If you can hang on for a few weeks I will have patches for IMAP to fix
up a bunch of authentication-related issues.


^ permalink raw reply	[flat|nested] 433+ messages in thread

* Re: [9fans] (no subject)
  2008-03-19  5:03 Skip Tavakkolian
@ 2008-03-19 12:41 ` erik quanstrom
  2008-03-19 17:16   ` Lyndon Nerenberg
  0 siblings, 1 reply; 433+ messages in thread
From: erik quanstrom @ 2008-03-19 12:41 UTC (permalink / raw)
  To: 9fans

> we have outlook express, thunderbird and mac mail accessing
> tlssrv+imap4.  i can't get outlook express or mac mail to authenticate
> using cram-md5, but thunderbird can.  mac mail and thunderbird can
> authenticate with password auth (i.e.  -p) but nothing seems to work
> for outlook express.  anybody have a similar setup?
>
> also, upas/fs -f /imaps can't authenticate with cram-md5.

i have had similar problems with outlook express.  i didn't get a chance
to debug as i don't have a windows box.

- erik



^ permalink raw reply	[flat|nested] 433+ messages in thread

* [9fans] (no subject)
@ 2008-03-19  5:03 Skip Tavakkolian
  2008-03-19 12:41 ` erik quanstrom
  0 siblings, 1 reply; 433+ messages in thread
From: Skip Tavakkolian @ 2008-03-19  5:03 UTC (permalink / raw)
  To: 9fans

we have outlook express, thunderbird and mac mail accessing
tlssrv+imap4.  i can't get outlook express or mac mail to authenticate
using cram-md5, but thunderbird can.  mac mail and thunderbird can
authenticate with password auth (i.e.  -p) but nothing seems to work
for outlook express.  anybody have a similar setup?

also, upas/fs -f /imaps can't authenticate with cram-md5.



^ permalink raw reply	[flat|nested] 433+ messages in thread

* [9fans] (no subject)
@ 2007-12-14 23:02 Joshua Wood
  0 siblings, 0 replies; 433+ messages in thread
From: Joshua Wood @ 2007-12-14 23:02 UTC (permalink / raw)
  To: 9fans

> > On Dec 14, 2007 12:41 AM, Francisco J Ballesteros <n...@lsub.org>  
> wrote:
> > > We asked the 9fan we know at Greece and it seems that perhaps
> > > october in greece is an option, should we want to have it  
> hosted there.
>
> We are talking about volos:
>
> http://www.greeka.com/thessaly/pelion/greece-volos.htm

Ya Sas!

But Thessaly In October!? Oxi. It might be from just the heat, or  
from the wildfires, but we'll all be sweaty.

>
> > What organization is there to handle arrangements? This kind of  
> thing
> > is a lot of work. Is there a hotel that can support us?
>
> A University. And we (as in nemo, quique and me) would help with
> the organization.

Maybe I could help with the organization; I spend some time on Paros  
(in the Kyklades), and I and my friends there would donate meeting  
space in buildings they own and/or have access to on the island. They  
run The Aegean Center for the Fine Arts, an american school that's  
been on Paros for 40 years or so.

The same folks are well in with the local hotels (& `hostels',  
Lyndon), and could *probably* get the group a student rate or similar  
as well. Either way, the conference facilities should be no problem,  
and I'm chatting with my friends now to double-check that.

Now, all that said, I'd still rather have it in Ron's favored Sonoma.  
We pounded on OTEnet for 4 months last year -- we finally had a 2Mbps  
downlink by the time we left Paros. Even Thessaly offers stronger  
infrastructure.

--
Josh




^ permalink raw reply	[flat|nested] 433+ messages in thread

* [9fans] (no subject)
@ 2007-11-15 20:00 erik quanstrom
  0 siblings, 0 replies; 433+ messages in thread
From: erik quanstrom @ 2007-11-15 20:00 UTC (permalink / raw)
  To: 9fans

Subject devsegment #g

doesn't seem to work.  is this a relic predating the segattach
system call?

- erik


^ permalink raw reply	[flat|nested] 433+ messages in thread

* Re: [9fans] (no subject)
  2007-08-24  1:54 YAMANASHI Takeshi
@ 2007-08-24  2:04 ` erik quanstrom
  0 siblings, 0 replies; 433+ messages in thread
From: erik quanstrom @ 2007-08-24  2:04 UTC (permalink / raw)
  To: 9fans

> Subect: individual window dump
> 
> how do i get the screendump of a window, not the whole screen?
> 
> i thought "cat /dev/wsys/4/window" had done the job but no success
> on recent installattion seeing the error:
> 	cat: error reading /dev/wsys/4/window: readimage from window unimplemented

did you run the command from acme?  this does work for me
on both a native terminal and drawterm.

(it's really slow on drawterm.  perhaps oweing to my pathetic client.)

- erik


^ permalink raw reply	[flat|nested] 433+ messages in thread

* [9fans] (no subject)
@ 2007-08-24  1:54 YAMANASHI Takeshi
  2007-08-24  2:04 ` erik quanstrom
  0 siblings, 1 reply; 433+ messages in thread
From: YAMANASHI Takeshi @ 2007-08-24  1:54 UTC (permalink / raw)
  To: 9fans

Subect: individual window dump

how do i get the screendump of a window, not the whole screen?

i thought "cat /dev/wsys/4/window" had done the job but no success
on recent installattion seeing the error:
	cat: error reading /dev/wsys/4/window: readimage from window unimplemented
-- 



^ permalink raw reply	[flat|nested] 433+ messages in thread

* Re: [9fans] (no subject)
  2007-07-08 14:50   ` erik quanstrom
@ 2007-07-12 20:57     ` erik quanstrom
  0 siblings, 0 replies; 433+ messages in thread
From: erik quanstrom @ 2007-07-12 20:57 UTC (permalink / raw)
  To: 9fans

as geoff has pointed out, the flaw in this logic is that cs doesn't
make the connection, it just proposes a dialable address.

it turns out our problem was traced to someone reusing an inuse ip address.

- erik

On Sun Jul  8 10:50:21 EDT 2007, quanstro@coraid.com wrote:
> in this case "net!somehost!9fs" could be translated il!somehost!9fs
> or tcp!somehost!9fs.  the current algorithm is to look through the possibities
> and see if there exists somehost on protocol $protocol for service 9fs.
> the first match wins.  this depends on the order in the table.
> the current algorithm doesn't check to see if any servers were found.
> 
> it wouldn't be hard to change things so that the first /available/ server is used.
> it's a one line change, in fact.
> 
> /sys/src/cmd/ndb/cs.c:1182 - /usr/quanstro/dist/sys/src/cmd/ndb/cs.c
> - 			if(rv > 0)
> - 				break;
> + 			break;
> 
> the downside to this is that the behavior of "net" becomes more dependent
> on configuration.  but Nilfast did the same thing.  so i don't think this
> really changes anything.
> 
> the one reservation i have is i don't know why the the code didn't loop.
> the first version in sourcesdump also has the break.  dial(2) seems to
> argue against the break.
> 
> 	Network is any directory listed in /net or the special
>           	token, net.  Net is a free variable that stands for any net-
> 	work in common between the source and the host netaddr.
> 
> so i would think the test for responses should go in.
> 
> - erik


^ permalink raw reply	[flat|nested] 433+ messages in thread

* Re: [9fans] (no subject)
  2007-07-08 14:08 ` erik quanstrom
@ 2007-07-08 14:50   ` erik quanstrom
  2007-07-12 20:57     ` erik quanstrom
  0 siblings, 1 reply; 433+ messages in thread
From: erik quanstrom @ 2007-07-08 14:50 UTC (permalink / raw)
  To: 9fans

in this case "net!somehost!9fs" could be translated il!somehost!9fs
or tcp!somehost!9fs.  the current algorithm is to look through the possibities
and see if there exists somehost on protocol $protocol for service 9fs.
the first match wins.  this depends on the order in the table.
the current algorithm doesn't check to see if any servers were found.

it wouldn't be hard to change things so that the first /available/ server is used.
it's a one line change, in fact.

/sys/src/cmd/ndb/cs.c:1182 - /usr/quanstro/dist/sys/src/cmd/ndb/cs.c
- 			if(rv > 0)
- 				break;
+ 			break;

the downside to this is that the behavior of "net" becomes more dependent
on configuration.  but Nilfast did the same thing.  so i don't think this
really changes anything.

the one reservation i have is i don't know why the the code didn't loop.
the first version in sourcesdump also has the break.  dial(2) seems to
argue against the break.

	Network is any directory listed in /net or the special
          	token, net.  Net is a free variable that stands for any net-
	work in common between the source and the host netaddr.

so i would think the test for responses should go in.

- erik


^ permalink raw reply	[flat|nested] 433+ messages in thread

* Re: [9fans] (no subject)
  2007-07-08 12:37 Gregory Pavelcak
@ 2007-07-08 14:08 ` erik quanstrom
  2007-07-08 14:50   ` erik quanstrom
  0 siblings, 1 reply; 433+ messages in thread
From: erik quanstrom @ 2007-07-08 14:08 UTC (permalink / raw)
  To: 9fans

it appears that net! is hueristic.

we use il here and this is the network table (from /sys/src/cmd/ndb/cs.c) 
that works for us.  i'm not sure why Nilfast was eliminated from the current
table, but the current ndb/cs doesn't work for us.

i would suspect that tcp is timing out in an antisocial way and not allowing
the next element of the network table to be processed.

- erik

/*
>  *  net doesn't apply to (r)udp, icmp(v6), or telco (for speed)
 */
Network network[] = {
[Nilfast]	{ "il",		iplookup,	iptrans,	0, 1 },
[Ntcp]		{ "tcp",	iplookup,	iptrans,	0, 0 },
[Nil]		{ "il",		iplookup,	iptrans,	0, 0 },
[Nudp]		{ "udp",	iplookup,	iptrans,	1, 0 },
[Nicmp]		{ "icmp",	iplookup,	iptrans,	1, 0 },
[Nicmpv6]	{ "icmpv6",	iplookup,	iptrans,	1, 0 },
[Nrudp]		{ "rudp",	iplookup,	iptrans,	1, 0 },
[Ntelco]	{ "telco",	telcolookup,	telcotrans,	1, 0 },
		{ 0 },
};


^ permalink raw reply	[flat|nested] 433+ messages in thread

* [9fans] (no subject)
@ 2007-07-08 12:37 Gregory Pavelcak
  2007-07-08 14:08 ` erik quanstrom
  0 siblings, 1 reply; 433+ messages in thread
From: Gregory Pavelcak @ 2007-07-08 12:37 UTC (permalink / raw)
  To: 9fans

	srv: timeout establishing connection to net!pinky!9fs

whereas before it worked. If I do something like

	srv -m 'il!pinky!9fs' pinky /mnt/pinky

that works, so I thought that there may have been a change
that requires us to be specific about using il, but adding
proto=il to pinky's ndb/local entry and 'refresh-ing' /net/cs
didn't help.

Am I missing something in my configuration, or is
this an error that slipped through in recent updates?

Thanks.

Greg


^ permalink raw reply	[flat|nested] 433+ messages in thread

* Re: [9fans] (no subject)
  2007-05-25 23:42 ` Charles Forsyth
  2007-05-26  0:09   ` ozan s. yigit
@ 2007-05-28 12:36   ` Lluís Batlle
  1 sibling, 0 replies; 433+ messages in thread
From: Lluís Batlle @ 2007-05-28 12:36 UTC (permalink / raw)
  To: Fans of the OS Plan 9 from Bell Labs

Do you have code published for your implementation regarding ogdl?

(In my implementation I support a subset of ogdl, I barely have
grammar checking, and I'm happy with it :)

Thanks,
Lluís.

2007/5/26, Charles Forsyth <forsyth@terzarima.net>:
> >some sort of agreement over the structure [for json] and wide support for it
>
> there isn't though: i had to adjust the code to account for what
> they apparently meant as opposed to what was documented, given examples
> that people produce.
> it was similar but a bit worse for ogdl.
>


^ permalink raw reply	[flat|nested] 433+ messages in thread

* Re: [9fans] (no subject)
  2007-05-25 23:42 ` Charles Forsyth
@ 2007-05-26  0:09   ` ozan s. yigit
  2007-05-28 12:36   ` Lluís Batlle
  1 sibling, 0 replies; 433+ messages in thread
From: ozan s. yigit @ 2007-05-26  0:09 UTC (permalink / raw)
  To: Fans of the OS Plan 9 from Bell Labs

sure i understand the skew between implementation vs spec; there are many
[often embarrassing] examples of it in the protocol circles. so long as people
are at the same table agreeing to interoperate, we can fix that. there are
seventy different APIs in 28 different languages (not counting the unlisted 
limbo implementation) for this lightweight data interhange format. you
are nitpicking. [and also forgetting the irregularities lispers had
introduced into their notations, eg. power brackets, array brackets
and the like]

oz

> >some sort of agreement over the structure [for json] and wide support for it
> 
> there isn't though: i had to adjust the code to account for what
> they apparently meant as opposed to what was documented, given examples
> that people produce.
> it was similar but a bit worse for ogdl.




^ permalink raw reply	[flat|nested] 433+ messages in thread

* Re: [9fans] (no subject)
  2007-05-25 23:29 ozan s. yigit
@ 2007-05-25 23:42 ` Charles Forsyth
  2007-05-26  0:09   ` ozan s. yigit
  2007-05-28 12:36   ` Lluís Batlle
  0 siblings, 2 replies; 433+ messages in thread
From: Charles Forsyth @ 2007-05-25 23:42 UTC (permalink / raw)
  To: 9fans

>some sort of agreement over the structure [for json] and wide support for it

there isn't though: i had to adjust the code to account for what
they apparently meant as opposed to what was documented, given examples
that people produce.
it was similar but a bit worse for ogdl.


^ permalink raw reply	[flat|nested] 433+ messages in thread

* [9fans] (no subject)
@ 2007-05-25 23:29 ozan s. yigit
  2007-05-25 23:42 ` Charles Forsyth
  0 siblings, 1 reply; 433+ messages in thread
From: ozan s. yigit @ 2007-05-25 23:29 UTC (permalink / raw)
  To: Fans of the OS Plan 9 from Bell Labs

> no, i don't think so. they're about the same amount of code, and json is
> less regular and more of a hack.  as js is, though i've seen worse
> (java! oh, man! what were they THINKING?)

some sort of agreement over the structure and wide support for it
sometimes beats having to re-invent *yet another* s-expression form
noone seems to really want, such as the one created by rivest etc.

oz



 




^ permalink raw reply	[flat|nested] 433+ messages in thread

* [9fans] (no subject)
@ 2007-05-11  6:57 Lyndon Nerenberg
  0 siblings, 0 replies; 433+ messages in thread
From: Lyndon Nerenberg @ 2007-05-11  6:57 UTC (permalink / raw)
  To: 9fans

What non-monotheistic hardware does Plan 9 support these days?
Starting with VGA hardware, let's cull the obsolete from the list.

If you run any of the below-listed VGA gear under a current (4ed+)
release, send an aux/vga dump (to me).

Some weeks from now I will collapse and update the wiki list.

--lyndon

Plan 9 will automatically recognize the PCI Ethernet cards that it
can drive. The following chips/cards are supported:

 *	3Com 3C562, 3C589, and 3C589E PCMCIA
 *	3Com 3C450, 3C575, 3C59x, 3C90x, 3CSOHO100-TX
 *	Accton EtherPair-PCMCIA EN2216
 *	Alteon, DEC, or SGI Acenic fiber Gigabit
 *	AMD 79C970
 *	D-Link DFE-538TX, DFE-560TXD
 *	Dell TrueMobile 1150 wireless
 *	Digital (now Intel) 2114x and clones. (Tulip, PIC, PIC-II,
	Centaur, Digital DE-500)
 *	EtherFast 10/100 PC Card
 *	Intel 82562EM/EZ/ET/VE, 8255x PRO/100
 *	Intel 8254x PRO/1000 Gigabit
 *	Intersil Prism2.5 wireless
 *	Linksys EC2T Combo PCMCIA EtherCard, NB10T
 *	Linksys WPC-11 wireless
 *	Lucent/Agere/Avaya/Orinoco Wavelan wireless
 *	NE2000 clones
 *	National Semiconductor DP83815, DP8390
 *	National Semiconductor DP83820 Gigabit
 *	Netgear FA310, FA311, FA312, FA410TX, FA411 PCMCIA
 *	Netgear GA620 Gigabit
 *	Realtek 8029, 8110S/8169S, 8139,
 *	SMC 1211, 8040TX PCMCIA, 91CXX PCMCIA
 *	VIA Rhine VT6102
 *	Western Digital/SMC WD8003, WD8013, WD8216
 *	Winbond 89C940

Plan 9 can use some basic acceleration features such as filling and
scrolling rectangles.

NOTE: If your chipset is not listed or listed as not supported, try
the VESA driver by entering 'vesa' as your monitor type.

! Chip                         | Native    | VESA | Notes
! -------------------------------------------------------------------------------------
! 3Dfx Voodoo Banshee          | Yes?      | ?    | Works perfectly with Elpin Banshee(Rev 1.1) 3Dfx 55-0013-04
! 3Dfx Voodoo 3
!     1000                     | Yes       | ?    |
!     2000                     | Yes       | ?    |
!     3000                     | Yes       | ?    |
! ARK 2000pv                   | Yes(2)    | ?    |
! ATI Mach
!     Mach 32                  | Yes(2)    | ?    |
!     Mach64xx                 | Yes?      | ?    | Some newer Mach64 don't work(eg, later ATI Xpert)
! ATI Rage - http://en.wikipedia.org/wiki/ATI_Rage
!     Rage IIc                 | Yes       | ?    | Needs hwaccel off
!     Rage 3D II+              | Broken    | Yes  | Grabled display
!     Rage 128                 | No        | ?    | Too different from the Mach 64
! ATI Radeon
!     (789)xxx                 | (1)       | Yes  | Works well with VESA
!     Mobility M7 LW           | No        | Yes  | Max: 1024x768x24
! CHIPS hiQVideo
!     65550                    | Yes       | ?    |
!     65554                    | Yes       | ?    |
!     69000                    | Yes       | ?    |
! Cirrus Logic
!     CL-GD542x                | Yes       | ?    |
!     CL-GD543x                | Yes       | No   |
!     CL-GD544x                | Yes       | Yes  | Used by qemu
!     CL-GD546x Laguna         | Yes       | ?    |
! Intel i81x                   | Yes       | ?    |
! Intel i740                   | No        | ?    |
! Intel i950                   | No        | Yes  |
! Matrox (Note: GXXX series only support 8bit and 32bit depths)
!     G200                     | Yes       | ?    |
!     G400                     | Yes       | ?    |
!     G450                     | Yes       | Yes  |
!     G550                     | Yes       | Yes  |
!     P650                     | No        | Yes  |
! Matrox Millennium II         | Yes       | ?    |
! Neomagic
!     MagicGraph               | Yes       | ?    |
!     MagicMedia               | Yes       | No   |
! NVIDIA
!     TNT                      | Yes       | ?    |
!     TNT2                     | Yes       | Yes  |
!     GeForce                  | Yes?      | ?    |
!     GeForce 2                | Yes       | ?    |
!     GeForce 2 DVI            | Yes       | ?    |
!     GeForce 2 MX/MX 400      | Yes       | Yes  |
!     GeForce 3                | Yes       | ?    |
!     GeForce 4                | Yes       | ?    |
!     GeForce 4 MX             | Yes       | Yes  |
!     GeForce FX 5200          | Yes       | Yes  | Native: Some people have reported problems with DVI.
!     GeForce 6200             | No        | Yes  |
! S3 801, 805, 864, 928        | Yes(2)    | ?    |
! S3 968                       | Yes       | ?    |
! S3 Savage
!     Savage 4                 | Yes       | ?    |
!     Savage IX/MV             | Yes       | ?    |
!     SuperSavage IXC/16       | Yes       | ?    |
!     SavagePro8/DDR           | Yes       | ?    |
!     Savage 2000              | No        | ?    |
! S3 ViRGE DX, GX, GX2, MX, VX | Yes       | ?    |
! S3 Trio64V+                  | Yes       | ?    |
! S3 Trio3D                    | No        | Yes  |
! Tseng ET4000                 | Yes(2)    | ?    |
! Trident Cyber938x            | Yes       | ?    |
! VIA UniChrome  (EPIA-MS)     | No        | Yes  |
! VMware virtual chipset (vmware won't release documentation, please use qemu instead)
!     4.5                      | Yes       | ?    |
!     5.0                      | Yes       | ?    | Needs hwaccel off

(1) See the [radeon drivers] page.

(2) Only tested with old editions of Plan 9.

Cards supported in the third edition but not tested in current
system:
 *	ATI Graphics Xpression
 *	ATI Xpert 98
 *	ATI xpert@work
 *	ATI Xpert LCD
 *	#9FX Reality 334
 *	Diamond Stealth3D 2000 vers 1.04
 *	Diamond Stealth64 Video 2001
 *	Diamond SpeedStar 64

Cards supported in the first and second editions but not tested in
the current system:
 *	#9FX Reality 332
 *	#9GXE Level-11, Level-12, Level-16
 *	#9GXE 64
 *	#9GXE 64pro
 *	Diamond SpeedStar Pro
 *	Hercules Terminator
 *	NCR 3230
 *	Orchid Fahrenheit 1280
 *	Orchid Kelvin 64
 *	Quadtel S3 86C801, 86C805
 *	STB PowerGraph X-24
 *	STB Velocity 3D
 *	STB Velocity 64 Video
 *	Stealth 64 Video 3000
 *	Stingray 64/Video
 *	Various Rackmount SBCs



^ permalink raw reply	[flat|nested] 433+ messages in thread

* [9fans] (no subject)
@ 2007-05-08 23:02 Steve Simon
  0 siblings, 0 replies; 433+ messages in thread
From: Steve Simon @ 2007-05-08 23:02 UTC (permalink / raw)
  To: 9fans

I am getting an unusual error from replica when I try to
do a pull from the the labs,  looking the source I am not
clear what is happening or what to do about it.

	term% replica/pull -v /dist/replica/network -s 386/bin/aquarela
	post...
	stopped updating log apply time because of lib/video.specs
	386/bin/aquarela: locally modified; will not update

I have a seccond server that is perfectly happy so I assume
I have corrupted my local state.

Anyone any thoughts or should I delve deeper into replica?

-Steve


^ permalink raw reply	[flat|nested] 433+ messages in thread

* Re: [9fans] (no subject)
  2007-04-13 22:16 devon.odell
@ 2007-04-14 11:17 ` W B Hacker
  0 siblings, 0 replies; 433+ messages in thread
From: W B Hacker @ 2007-04-14 11:17 UTC (permalink / raw)
  To: Fans of the OS Plan 9 from Bell Labs

devon.odell@gmail.com wrote:
> So! I finally got mail working. I'm sending this from a terminal window.
> The trick was indeed that my ISP was blocking port 25. I had them turn
> it on, but alas that allows people to connect internally to me -- but not
> for me to connect to external mail servers. Which I think is just very
> lame. They require you to set up your mailserver to relay through them.
> 
> Oh well. In either case, I was able to connect to smtp.gmail.com on
> port 587. Their relay server is _not_ their MX server. While chatter on
> this list has implied that's an expectation, it's not a requirement. So
> they're allowed to do that.
> 
> However, this raised a question for me. It seems that the smtp= line in
> /lib/ndb/local doesn't accept a dial string as valid input. Hence, I had to
> manually hack remotemail to use net!smtp.gmail.com!587, since we will
> only connect to port 25 by default. Should I fix this, or is this something
> we're supposed to have to do?
> 
> --dho
> 

- Port 587 (with TLS & authentication) will increasingly be needed for smtp when 
a Plan9 device is serving as a workstation or otherwise relaying by remote MX.

'Connectivity provider' ISP's are finding it essential to intercept traffic FROM 
their broadband client pool directed TO any port 25 to reduce 'bot-infested 
WinBox traffic (billions of such). Many ISP are required by local regulations to 
do this sort of thing.

- Port 25 inbound (optionally with STARTTLS) remains needed for operating a 
'public facing' MTA, with, of course, randomly selected ports (well) above 1024 
for outbound to other MTA's port 25.

'public Facing mail servers will increasingly need to be in a Data Centre or 
otherwise on unblocked fixed IP with apprpriate ToS, with a PTR record, and not 
in the midst of a dynamic IP block.

So goeth the spam wars....

:-(

Bill Hacker



^ permalink raw reply	[flat|nested] 433+ messages in thread

* [9fans] (no subject)
@ 2007-04-13 22:16 devon.odell
  2007-04-14 11:17 ` W B Hacker
  0 siblings, 1 reply; 433+ messages in thread
From: devon.odell @ 2007-04-13 22:16 UTC (permalink / raw)
  To: 9fans

So! I finally got mail working. I'm sending this from a terminal window.
The trick was indeed that my ISP was blocking port 25. I had them turn
it on, but alas that allows people to connect internally to me -- but not
for me to connect to external mail servers. Which I think is just very
lame. They require you to set up your mailserver to relay through them.

Oh well. In either case, I was able to connect to smtp.gmail.com on
port 587. Their relay server is _not_ their MX server. While chatter on
this list has implied that's an expectation, it's not a requirement. So
they're allowed to do that.

However, this raised a question for me. It seems that the smtp= line in
/lib/ndb/local doesn't accept a dial string as valid input. Hence, I had to
manually hack remotemail to use net!smtp.gmail.com!587, since we will
only connect to port 25 by default. Should I fix this, or is this something
we're supposed to have to do?

--dho


^ permalink raw reply	[flat|nested] 433+ messages in thread

* [9fans] (no subject)
@ 2007-01-15 23:24 steve
  0 siblings, 0 replies; 433+ messages in thread
From: steve @ 2007-01-15 23:24 UTC (permalink / raw)
  To: 9fans



^ permalink raw reply	[flat|nested] 433+ messages in thread

* [9fans] (no subject)
@ 2006-12-12 21:20 Steve Simon
  0 siblings, 0 replies; 433+ messages in thread
From: Steve Simon @ 2006-12-12 21:20 UTC (permalink / raw)
  To: 9fans

Someone mentioned problems with getting upasfs & faces to work with
drawterm (I forgot who) I have put an annotated version of my profile
in /n/sources/contrib/steve/rc/profile which does this fine. I use
the same profile for diskless and diskfull terminals and drawterm.

This uses the (IMHO) under-announced, and wonderfull feature of dt2k
where it reads the users secstore into /dev/secstore. To do this use
the -s command line option to drawterm to specify the secstore host you
want to use.

It is fairly complicated but it gets me an enviroment I like and it
works everywhere.

Hope its of some use.

-Steve


^ permalink raw reply	[flat|nested] 433+ messages in thread

* [9fans] (no subject)
@ 2006-12-10 13:49 sape
  0 siblings, 0 replies; 433+ messages in thread
From: sape @ 2006-12-10 13:49 UTC (permalink / raw)
  To: 9fans



^ permalink raw reply	[flat|nested] 433+ messages in thread

* Re: [9fans] (no subject)
  2006-09-13  7:28 Aw: " chuckf
@ 2006-09-13  7:55 ` Sascha Retzki
  0 siblings, 0 replies; 433+ messages in thread
From: Sascha Retzki @ 2006-09-13  7:55 UTC (permalink / raw)
  To: 9fans


> The install program will partition the available space to Plan9 and the necessary 
> sub-partitions will be proposed as well as formatted?

Short: yes.

Long: You may want to read the involved manpages (as they are on the cd, a new window and 'man foo' will do the trick'), and there were rumours about disk/fdisk writting 'foreign' partitions in another order (never happened to me as I do not dual-boot).

> After preparing the necessary sub-partitions the install program will
> ask for the image ie local  and it will find it? 

after you have told it were to find it (it will list all available (supported) partitions, then ask for the image (or the root of it) in that FS).

>Thereafter I should proceed as per the 
> directions. Right?

I have never done this myself but I do not see any further problems - the installation should, despite the 'where is the distribution'-step, behave like in the wiki/as everytime... .

Mfg, Sascha

> 
> Thanks
> 
> 
> 
> ----- Original Nachricht ----
> Von:     Federico Benavento <benavento@gmail.com>
> An:      Fans of the OS Plan 9 from Bell Labs <9fans@cse.psu.edu>
> Datum:   12.09.2006 22:55
> Betreff: Re: [9fans] (no subject)
> 
>> hola,
>> 
>> On 9/12/06, Chuck Foreman <chuckf@arcor.de> wrote:
>> 
>> > Should I put the image somewhere on the HDD (a Primary Fat32, Primary
>> > F-BSD, an log/ext linux reiserfs)and mount this at that stage in the
>> > install?
>> 
>> this is how I always do it, I put the .iso in a fat32 partition, there
>> is no magic
>> about it, the installer knows how to do it, you get prompts, in one you
>> choose
>> the media (the fat32 partition) in other you browse to the dir where
>> the .iso is located.
>> 
>> -- 
>> Federico G. Benavento
>> 



^ permalink raw reply	[flat|nested] 433+ messages in thread

* Re: [9fans] (no subject)
  2006-09-12 20:44 Chuck Foreman
  2006-09-12 20:47 ` David Hendricks
@ 2006-09-12 20:55 ` Federico Benavento
  1 sibling, 0 replies; 433+ messages in thread
From: Federico Benavento @ 2006-09-12 20:55 UTC (permalink / raw)
  To: Fans of the OS Plan 9 from Bell Labs

hola,

On 9/12/06, Chuck Foreman <chuckf@arcor.de> wrote:

> Should I put the image somewhere on the HDD (a Primary Fat32, Primary
> F-BSD, an log/ext linux reiserfs)and mount this at that stage in the
> install?

this is how I always do it, I put the .iso in a fat32 partition, there
is no magic
about it, the installer knows how to do it, you get prompts, in one you choose
the media (the fat32 partition) in other you browse to the dir where
the .iso is located.

-- 
Federico G. Benavento


^ permalink raw reply	[flat|nested] 433+ messages in thread

* Re: [9fans] (no subject)
  2006-09-12 20:44 Chuck Foreman
@ 2006-09-12 20:47 ` David Hendricks
  2006-09-12 20:55 ` Federico Benavento
  1 sibling, 0 replies; 433+ messages in thread
From: David Hendricks @ 2006-09-12 20:47 UTC (permalink / raw)
  To: Fans of the OS Plan 9 from Bell Labs

I've been having a similar issue with the latest install CD where I
can boot from the CD but it is not recognzied. Just out of curiosity,
could you try an older one and see what happens? I think my "working"
bootable image is from January '04.

On 9/12/06, Chuck Foreman <chuckf@arcor.de> wrote:
> Hi,
>
> How to install:
> My Laptop won't allow both a CD and a floppy drive. The CD controller
> is somehow not recognized despite booting from the CD! It recognizes
> the floppy drive despite it not being there... Anyway... I can use use the
> floppy drive to boot from for the install. I need to get some feedback
> regarding the order of install.
>
> Since I can't store the image on CD and use the floppy at the same time;
>
> Is there any advantage to using cfdisk to set the available primary
> partition
> for Plan 9 in advance of the floppy install?
> What happens when it finds an existing Plan 9 partition?
> Will/would the "partdisk" step do this "automatically" ie
> prompting for the necessary partitions?
>
> If I interrupted the install at that point (after the partitioning
> but prior to loading the image)could I theoretically put/copy
> the Plan9.iso image into the Plan 9 partition.. is there any benefit to
> that?
>
>
> Should I put the image somewhere on the HDD (a Primary Fat32, Primary
> F-BSD, an log/ext linux reiserfs)and mount this at that stage in the
> install?
> Should I wait and see what the install will prompt for available media..
> interrupt
> if necessary..copy the media there) and resume the install?
>
>
> Thanks
>
> Taking it slowly and deliberatly
>
> --
> Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
>


^ permalink raw reply	[flat|nested] 433+ messages in thread

* [9fans] (no subject)
@ 2006-09-12 20:44 Chuck Foreman
  2006-09-12 20:47 ` David Hendricks
  2006-09-12 20:55 ` Federico Benavento
  0 siblings, 2 replies; 433+ messages in thread
From: Chuck Foreman @ 2006-09-12 20:44 UTC (permalink / raw)
  To: 9fans

Hi,

How to install:
My Laptop won't allow both a CD and a floppy drive. The CD controller
is somehow not recognized despite booting from the CD! It recognizes
the floppy drive despite it not being there... Anyway... I can use use the
floppy drive to boot from for the install. I need to get some feedback
regarding the order of install.

Since I can't store the image on CD and use the floppy at the same time;

Is there any advantage to using cfdisk to set the available primary  
partition
for Plan 9 in advance of the floppy install?
What happens when it finds an existing Plan 9 partition?
Will/would the "partdisk" step do this "automatically" ie
prompting for the necessary partitions?

If I interrupted the install at that point (after the partitioning
but prior to loading the image)could I theoretically put/copy
the Plan9.iso image into the Plan 9 partition.. is there any benefit to  
that?


Should I put the image somewhere on the HDD (a Primary Fat32, Primary
F-BSD, an log/ext linux reiserfs)and mount this at that stage in the  
install?
Should I wait and see what the install will prompt for available media..  
interrupt
if necessary..copy the media there) and resume the install?


Thanks

Taking it slowly and deliberatly

-- 
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/


^ permalink raw reply	[flat|nested] 433+ messages in thread

* Re: [9fans] (no subject)
  2006-09-03  5:46     ` geoff
@ 2006-09-03 10:51       ` Álvaro Jurado Cuevas
  0 siblings, 0 replies; 433+ messages in thread
From: Álvaro Jurado Cuevas @ 2006-09-03 10:51 UTC (permalink / raw)
  To: Fans of the OS Plan 9 from Bell Labs

El Domingo, 3 de Septiembre de 2006 07:46, geoff@collyer.net escribió:
> The Bell Labs Plan 9 systems are mostly down.
> 
> There was some sort of power problem, perhaps
> due to a thunderstorm, around 0430 EDT Saturday,
> and despite our UPSes, the Raidweb array holding
> the venti arenas for edith, our main file server,
> refuses to come up.  Jim is just back from Austin
> and I expect that we'll get the systems back up
> on Sunday.
> 
> I'm currently fetching data from our old file servers
> and storing it into a new venti/fossil server.
> The plan is to replace most of our aging Plan 9
> machines.  So our systems should become more reliable
> before too long.
> 
heh, I thought that things only happen in Spain.
-- 
Elbing


^ permalink raw reply	[flat|nested] 433+ messages in thread

* Re: [9fans] (no subject)
  2006-09-02 18:38   ` Gorka guardiola
@ 2006-09-03  5:46     ` geoff
  2006-09-03 10:51       ` Álvaro Jurado Cuevas
  0 siblings, 1 reply; 433+ messages in thread
From: geoff @ 2006-09-03  5:46 UTC (permalink / raw)
  To: 9fans

The Bell Labs Plan 9 systems are mostly down.

There was some sort of power problem, perhaps
due to a thunderstorm, around 0430 EDT Saturday,
and despite our UPSes, the Raidweb array holding
the venti arenas for edith, our main file server,
refuses to come up.  Jim is just back from Austin
and I expect that we'll get the systems back up
on Sunday.

I'm currently fetching data from our old file servers
and storing it into a new venti/fossil server.
The plan is to replace most of our aging Plan 9
machines.  So our systems should become more reliable
before too long.


^ permalink raw reply	[flat|nested] 433+ messages in thread

* Re: [9fans] (no subject)
  2006-09-02 17:49 ` Gorka guardiola
@ 2006-09-02 18:38   ` Gorka guardiola
  2006-09-03  5:46     ` geoff
  0 siblings, 1 reply; 433+ messages in thread
From: Gorka guardiola @ 2006-09-02 18:38 UTC (permalink / raw)
  To: Fans of the OS Plan 9 from Bell Labs

What I meant was that it is not a problem from there, it is also
unavailable here.

On 9/2/06, Gorka guardiola <paurea@gmail.com> wrote:
> No, it is unavailable.
>
> On 9/2/06, lucio@proxima.alt.za <lucio@proxima.alt.za> wrote:
> > Subjet: plan9.bell-labs.com
> >
> > The web server is unreachable.  Unless it's a problem from here.
> >
> > ++L
> >
> >
>
>
> --
> - curiosity sKilled the cat
>


-- 
- curiosity sKilled the cat


^ permalink raw reply	[flat|nested] 433+ messages in thread

* Re: [9fans] (no subject)
  2006-09-02 11:16 lucio
@ 2006-09-02 17:49 ` Gorka guardiola
  2006-09-02 18:38   ` Gorka guardiola
  0 siblings, 1 reply; 433+ messages in thread
From: Gorka guardiola @ 2006-09-02 17:49 UTC (permalink / raw)
  To: Fans of the OS Plan 9 from Bell Labs

No, it is unavailable.

On 9/2/06, lucio@proxima.alt.za <lucio@proxima.alt.za> wrote:
> Subjet: plan9.bell-labs.com
>
> The web server is unreachable.  Unless it's a problem from here.
>
> ++L
>
>


-- 
- curiosity sKilled the cat


^ permalink raw reply	[flat|nested] 433+ messages in thread

* [9fans] (no subject)
@ 2006-09-02 11:16 lucio
  2006-09-02 17:49 ` Gorka guardiola
  0 siblings, 1 reply; 433+ messages in thread
From: lucio @ 2006-09-02 11:16 UTC (permalink / raw)
  To: 9fans

Subjet: plan9.bell-labs.com

The web server is unreachable.  Unless it's a problem from here.

++L



^ permalink raw reply	[flat|nested] 433+ messages in thread

* Re: [9fans] (no subject)
  2006-08-21 12:43 Steve Simon
@ 2006-08-22 17:56 ` Sergey Zhilkin
  0 siblings, 0 replies; 433+ messages in thread
From: Sergey Zhilkin @ 2006-08-22 17:56 UTC (permalink / raw)
  To: Fans of the OS Plan 9 from Bell Labs

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

http://www.sqlfs.org/ Use Google Luke ! :)

2006/8/21, Steve Simon <steve@quintile.net>:
>
> Anyone know about a mysqlfs filesystem that Karim was
> writing in 2004?
>
> Is it available anywhere?
>
> [see http://9fans.net/archive/2003/09/287]
>
> -Steve
>

[-- Attachment #2: Type: text/html, Size: 598 bytes --]

^ permalink raw reply	[flat|nested] 433+ messages in thread

* [9fans] (no subject)
@ 2006-08-21 12:43 Steve Simon
  2006-08-22 17:56 ` Sergey Zhilkin
  0 siblings, 1 reply; 433+ messages in thread
From: Steve Simon @ 2006-08-21 12:43 UTC (permalink / raw)
  To: 9fans

Anyone know about a mysqlfs filesystem that Karim was
writing in 2004? 

Is it available anywhere?

[see http://9fans.net/archive/2003/09/287]

-Steve


^ permalink raw reply	[flat|nested] 433+ messages in thread

* [9fans] (no subject)
@ 2006-04-21  4:09 Rafeek Raja
  0 siblings, 0 replies; 433+ messages in thread
From: Rafeek Raja @ 2006-04-21  4:09 UTC (permalink / raw)
  To: 9fans

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



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

^ permalink raw reply	[flat|nested] 433+ messages in thread

* Re: [9fans] (no subject)
@ 2006-02-10 15:30 quanstro
  0 siblings, 0 replies; 433+ messages in thread
From: quanstro @ 2006-02-10 15:30 UTC (permalink / raw)
  To: 9fans

thanks! that's more encouraging than i was expecting.

- erik

On Fri Feb 10 09:18:49 CST 2006, jmk@plan9.bell-labs.com wrote:
> On Fri Feb 10 09:11:57 EST 2006, quanstro@quanstro.net wrote:
> > i don't know enough about PCIe to know the answer to this:
> > is it possible to use a PCIe video card with plan 9?
> > 
> > - erik
> 
> Neither do I, but there is an unopened 1050 page book
> on my desk which might contain the answer. Let me see...
> 
> ...and the answer is...definitely maybe.
> 
> Try it. The card should be identified OK, that part of
> the configuration space is compatible. Since Plan 9 doesn't
> really use much in the way of fancy features on video
> cards (especially if you use VESA) the rest of it may be
> compatible enough. What would be useful is the output
> of /bin/pci and the contents of the configuration space
> (xd -b '#$/pci/1.0.0raw' if, for example, the card is
> shown by /bin/pci to be device 1.0.0). We can work from
> there.
> 
> --jim


^ permalink raw reply	[flat|nested] 433+ messages in thread

* Re: [9fans] (no subject)
  2006-02-10 14:10 quanstro
@ 2006-02-10 15:17 ` jmk
  0 siblings, 0 replies; 433+ messages in thread
From: jmk @ 2006-02-10 15:17 UTC (permalink / raw)
  To: 9fans

On Fri Feb 10 09:11:57 EST 2006, quanstro@quanstro.net wrote:
> i don't know enough about PCIe to know the answer to this:
> is it possible to use a PCIe video card with plan 9?
> 
> - erik

Neither do I, but there is an unopened 1050 page book
on my desk which might contain the answer. Let me see...

...and the answer is...definitely maybe.

Try it. The card should be identified OK, that part of
the configuration space is compatible. Since Plan 9 doesn't
really use much in the way of fancy features on video
cards (especially if you use VESA) the rest of it may be
compatible enough. What would be useful is the output
of /bin/pci and the contents of the configuration space
(xd -b '#$/pci/1.0.0raw' if, for example, the card is
shown by /bin/pci to be device 1.0.0). We can work from
there.

--jim


^ permalink raw reply	[flat|nested] 433+ messages in thread

* [9fans] (no subject)
@ 2006-02-10 14:10 quanstro
  2006-02-10 15:17 ` jmk
  0 siblings, 1 reply; 433+ messages in thread
From: quanstro @ 2006-02-10 14:10 UTC (permalink / raw)
  To: 9fans

i don't know enough about PCIe to know the answer to this:
is it possible to use a PCIe video card with plan 9?

- erik


^ permalink raw reply	[flat|nested] 433+ messages in thread

* [9fans] (no subject)
@ 2006-02-07 17:09 Riza Dindir
  0 siblings, 0 replies; 433+ messages in thread
From: Riza Dindir @ 2006-02-07 17:09 UTC (permalink / raw)
  To: mirtchovski; +Cc: 9fans


andrey mirtchovski wrote:

> On 2/7/06, Llu&#65533;s Batlle <viriketo@gmail.com>
wrote:
> > To me happened that when I created my user, due to
> > some control-char,
> > the directory created was not "/usr/myname", but
> >  "/usr/*name", where
> > "*" is a character visible only on certain places.
> >  For instance, it's
> > not visible in 'acme', but visible in a shell.
> > Of course, I cannot remove that directory because
I > > don't know how 
> > did
> > I type that character. :)
> > Check so a simple "lc /usr"
> >

> most likely you typed ctrl+c or some other unix
> sequence that is a
> printable character in Plan 9...

> riza: we still haven't seen any error messages. do
> you mind sending
> those to the list?

I am sorry I thought I had sent error messages when I
tried to run /sys/lib/newuser. I think I did not
include these error messages... I will send them
as soon as I can get them. I apologize, my fault.

Riza

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 


^ permalink raw reply	[flat|nested] 433+ messages in thread

* [9fans] (no subject)
@ 2005-09-09 18:46 Fco. J. Ballesteros
  0 siblings, 0 replies; 433+ messages in thread
From: Fco. J. Ballesteros @ 2005-09-09 18:46 UTC (permalink / raw)
  To: 9fans

I think that there are several problems here.
One is the ability to switch from one device to another.
Another is what to do with the "state" of the device going out.

In Plan B, after several attempts that did mess things up,
I found that in general, what to do with the "state" depends
on the application. In general, raising an error for an ongoing
request is what we do. The application knows if it's ok to retry or
to abort.

If we talk about drivers, what to do may depend on the driver.
For example, for non reliable networks it may be ok just to switch the
ether card (there are other tcp/ip issues here though). For disks, 
it depends on the application, once again.

However, regarding the first problem, the volume mechanism is
a satisfactory answer; For example, say you:

mount -bV #ether /net

This means: take any resource named "#ether", and mount it (-b)
at /net. If one ethernet is not available, the mount mechanism
picks up another.

Thus, I'd say this is a clean way to fix up the first problem.

Right now, I'm in the process of implementing a volfs that works
both for Plan 9 and Plan B, in an effort to reconcile both systems.

If the mechanism were incorporated into the kernel instead, I don't
see why not could it mount in-kernel volumes, to make the example above
work.

Just an idea. Comments?


^ permalink raw reply	[flat|nested] 433+ messages in thread

* Re: [9fans] (no subject)
  2005-08-07 22:24 Steve Simon
@ 2005-08-08 13:25 ` Sape Mullender
  0 siblings, 0 replies; 433+ messages in thread
From: Sape Mullender @ 2005-08-08 13:25 UTC (permalink / raw)
  To: 9fans

> Nothing more than general interest but what hardware
> does the ppc and mtx ports in the current distribution
> relate to?

The port in mtx is for a mini processor board that we have used to
build tunneling devices for people to connect to the work network
from home.  We call them `bricks'.  They're the size of a typical laptop
power supply and have an internal and external ethernet connector.

There are two ports in ppc, `blast' and `ucu'.  The former is for the
8260 PowerQuicc II processor as used on a research experimental
cellular radio platform.  The latter is for the PowerPC 750 processor
as found on one of the Lucent radio boards (which uses a saturn
chipset for ether, serial and clock).

We've done some of the work for a 8248 port and we're likely to do
an MPC860 port too.

	Sape



^ permalink raw reply	[flat|nested] 433+ messages in thread

* [9fans] (no subject)
@ 2005-08-07 22:24 Steve Simon
  2005-08-08 13:25 ` Sape Mullender
  0 siblings, 1 reply; 433+ messages in thread
From: Steve Simon @ 2005-08-07 22:24 UTC (permalink / raw)
  To: 9fans

Nothing more than general interest but what hardware
does the ppc and mtx ports in the current distribution
relate to?

-Steve


^ permalink raw reply	[flat|nested] 433+ messages in thread

* [9fans] (no subject)
@ 2005-05-31  3:53 焕宇 苏
  0 siblings, 0 replies; 433+ messages in thread
From: 焕宇 苏 @ 2005-05-31  3:53 UTC (permalink / raw)
  To: 9fans

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

  


---------------------------------
Do You Yahoo!?
150万曲MP3疯狂搜,带您闯入音乐殿堂
美女明星应有尽有,搜遍美图、艳图和酷图
1G就是1000兆,雅虎电邮自助扩容!

[-- Attachment #2: Type: text/html, Size: 369 bytes --]

^ permalink raw reply	[flat|nested] 433+ messages in thread

* [9fans] (no subject)
@ 2005-05-30 19:01 quanstro
  0 siblings, 0 replies; 433+ messages in thread
From: quanstro @ 2005-05-30 19:01 UTC (permalink / raw)
  To: 9fans

i have some code that i've been using for years now that extends
the paul haahr/byron/schwartz print library and/or the plan 9 
fmt library with:

1. long-style formats. for example, you can install %{list} to 
   print lists. the code passes on arguments within the {} to the
   long format, for example %{list %d} might print lists of integers.
   %{list %s} lists of strings, %{list %{list}}, you get the picture.
2. double/float formatting. thanks to code stolen from plan9port.
3. support for long long, %lld.

clearly the long formats are a little ... over-featured for the 
print library, but i think that it's worth it for two reasons.
first, there's no telling which letter ANSI's going to commendeer
next. second, if you're using the installable formats to any extent
and interacting with libraries, it's hard to rememver what %A does
and it's pretty easy to step on the next library's toes.

if there's any interest, i'll get 'er ready for prime time.

erik





^ permalink raw reply	[flat|nested] 433+ messages in thread

* Re: [9fans] (no subject)
  2005-02-10 15:28 tapique
@ 2005-02-11 18:12 ` Bruce Ellis
  0 siblings, 0 replies; 433+ messages in thread
From: Bruce Ellis @ 2005-02-11 18:12 UTC (permalink / raw)
  To: Fans of the OS Plan 9 from Bell Labs

We've been down this road.

Please give me a one page program that exhibits this bug
and I'll fix 8c for a cz beer.

brucee

On Thu, 10 Feb 2005 16:28:56 +0100, tapique@tiscali.cz
<tapique@tiscali.cz> wrote:
> //pcc complains:
> result =  (int)tuplerow1[col][plane1] > (int)tuplerow2[col][plane2] ?  (int)tuplerow1[col][plane1]
> - (int)tuplerow2[col][plane2] : (int)tuplerow2[col][plane2] - (int)tuplerow1[col][plane1];
> 
> // but this is OK (just an 'if-else' rewrite)
>                        if((int)tuplerow1[col][plane1] > (int)tuplerow2[col][plane2] )
>                                result =  (int)tuplerow1[col][plane1] - (int)tuplerow2[col][plane2];
>                        else
>                                result =  (int)tuplerow2[col][plane2] - (int)tuplerow1[col][plane1];
> 
> regards,
> ++pac.
> 
> --------------------------
> Posílejte SMS přes internet zdarma a bez reklamy. Pouze s TISCALI.
> Více na http://www.tiscali.cz
> 
>


^ permalink raw reply	[flat|nested] 433+ messages in thread

* [9fans] (no subject)
@ 2005-02-10 15:28 tapique
  2005-02-11 18:12 ` Bruce Ellis
  0 siblings, 1 reply; 433+ messages in thread
From: tapique @ 2005-02-10 15:28 UTC (permalink / raw)
  To: 9fans

//pcc complains:
result =  (int)tuplerow1[col][plane1] > (int)tuplerow2[col][plane2] ?  (int)tuplerow1[col][plane1]
- (int)tuplerow2[col][plane2] : (int)tuplerow2[col][plane2] - (int)tuplerow1[col][plane1];

// but this is OK (just an 'if-else' rewrite)
			if((int)tuplerow1[col][plane1] > (int)tuplerow2[col][plane2] )
				result =  (int)tuplerow1[col][plane1] - (int)tuplerow2[col][plane2];
			else
				result =  (int)tuplerow2[col][plane2] - (int)tuplerow1[col][plane1];


regards,
++pac.



--------------------------
Posílejte SMS přes internet zdarma a bez reklamy. Pouze s TISCALI.
Více na http://www.tiscali.cz





^ permalink raw reply	[flat|nested] 433+ messages in thread

* Re: [9fans] (no subject)
  2004-12-14 23:35               ` Ronald G. Minnich
  2004-12-14 23:35                 ` boyd, rounin
@ 2004-12-14 23:41                 ` andrey mirtchovski
  1 sibling, 0 replies; 433+ messages in thread
From: andrey mirtchovski @ 2004-12-14 23:41 UTC (permalink / raw)
  To: 9fans


> Check that date. Lotsa people were using gcc and other Cs and even Fortran
> to do tcp/ip headers before gcc 2.7 where the packed attribute went in. 
> 

from ftp.gnu.org/old-gnu/gcc:

	gcc-2.7.2.tar.gz  6924 KB  11/29/1995  12:00:00 AM



^ permalink raw reply	[flat|nested] 433+ messages in thread

* Re: [9fans] (no subject)
  2004-12-14 23:35               ` Ronald G. Minnich
@ 2004-12-14 23:35                 ` boyd, rounin
  2004-12-14 23:41                 ` andrey mirtchovski
  1 sibling, 0 replies; 433+ messages in thread
From: boyd, rounin @ 2004-12-14 23:35 UTC (permalink / raw)
  To: Fans of the OS Plan 9 from Bell Labs

> > > sounds right to me.  damn idiots.
> 
> well, I don't share the comment w.r.t. the xen guys, I think they're
> terrific guys and I really like their work. 

my comment was directed at gcc.



^ permalink raw reply	[flat|nested] 433+ messages in thread

* Re: [9fans] (no subject)
  2004-12-14 22:36             ` jim
                                 ` (2 preceding siblings ...)
  2004-12-14 22:55               ` andrey mirtchovski
@ 2004-12-14 23:35               ` Ronald G. Minnich
  2004-12-14 23:35                 ` boyd, rounin
  2004-12-14 23:41                 ` andrey mirtchovski
  3 siblings, 2 replies; 433+ messages in thread
From: Ronald G. Minnich @ 2004-12-14 23:35 UTC (permalink / raw)
  To: Fans of the OS Plan 9 from Bell Labs



On Tue, 14 Dec 2004, jim wrote:

> 
> On 14 Dec 2004, at 22:26, boyd, rounin wrote:
> 
> > sounds right to me.  damn idiots.

well, I don't share the comment w.r.t. the xen guys, I think they're
terrific guys and I really like their work. I just don't like the use they
made of this one feature as it is not portable to other compilers on the 
same architecture, which brought me to grief. If it makes more work for 
me, how can I possibly like it :-)

> If you'll pardon a humble mortal's ignorance, what's so bad about it?
> Well, re-phrase that - how else to do accurate bit-packed structs like
> for tcp/ip headers?

Check that date. Lotsa people were using gcc and other Cs and even Fortran
to do tcp/ip headers before gcc 2.7 where the packed attribute went in. 


ron


^ permalink raw reply	[flat|nested] 433+ messages in thread

* Re: [9fans] (no subject)
  2004-12-14 23:00                 ` jim
  2004-12-14 23:07                   ` boyd, rounin
@ 2004-12-14 23:27                   ` Dan Cross
  1 sibling, 0 replies; 433+ messages in thread
From: Dan Cross @ 2004-12-14 23:27 UTC (permalink / raw)
  To: Fans of the OS Plan 9 from Bell Labs

jim <jim.whitson@gmail.com> writes:
> On 14 Dec 2004, at 22:48, Dan Cross wrote:
> > You don't.  In the
> > specific case you mention, you write code to marshal it into and
> > demarshal it from a byte stream.
> 
> Aha. I suppose I'm in over my head here; I can't really see what you
> mean by 'marshal'; is that a technical term? Are you talking about
> progressively slicing bytes off a stream to get each value?
> 
> /me starts googling... ;-p

No need.  You've already got it right.

	- Dan C.

(ps to Boyd: Semper Fi.)


^ permalink raw reply	[flat|nested] 433+ messages in thread

* Re: [9fans] (no subject)
  2004-12-14 23:08                 ` jim
@ 2004-12-14 23:12                   ` Brantley Coile
  0 siblings, 0 replies; 433+ messages in thread
From: Brantley Coile @ 2004-12-14 23:12 UTC (permalink / raw)
  To: 9fans

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

But, as I said in the note, I prefer the array-of-bytes approach.
You could defin dest as
	uchar	dest[2];

and use `v = dest[0] << 8 | dest[1]' to get its value.  Works on any
byte sex machine.

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

From: jim <jim.whitson@gmail.com>
To: Fans of the OS Plan 9 from Bell Labs <9fans@cse.psu.edu>
Subject: Re: [9fans] (no subject)
Date: Tue, 14 Dec 2004 23:08:18 +0000
Message-ID: <0A927737-4E25-11D9-901F-00112430C042@gmail.com>


On 14 Dec 2004, at 22:50, Brantley Coile wrote:

>> I'd love to
>> know how real coders do tcp/ip headers :-S.
>
>> From my netometer project
>
> typedef struct TCP TCP;
> struct	TCP	{
> 	short	src;
> 	short	dest;
> 	ulong	seq;
> 	ulong	ack;
> 	ushort	flags;	/* and header length */
> 	ushort	wnd;
> 	ushort	chksum;
> 	ushort	urgptr;
> 	ulong	options;
> };
>

Looks much like how mortals do it... I thought from what some posters 
have
said that there was some crazy way to deal with tcp that didn't involve 
struct
juggling. ..

^ permalink raw reply	[flat|nested] 433+ messages in thread

* Re: [9fans] (no subject)
  2004-12-14 22:50               ` Brantley Coile
@ 2004-12-14 23:08                 ` jim
  2004-12-14 23:12                   ` Brantley Coile
  0 siblings, 1 reply; 433+ messages in thread
From: jim @ 2004-12-14 23:08 UTC (permalink / raw)
  To: Fans of the OS Plan 9 from Bell Labs


On 14 Dec 2004, at 22:50, Brantley Coile wrote:

>> I'd love to
>> know how real coders do tcp/ip headers :-S.
>
>> From my netometer project
>
> typedef struct TCP TCP;
> struct	TCP	{
> 	short	src;
> 	short	dest;
> 	ulong	seq;
> 	ulong	ack;
> 	ushort	flags;	/* and header length */
> 	ushort	wnd;
> 	ushort	chksum;
> 	ushort	urgptr;
> 	ulong	options;
> };
>

Looks much like how mortals do it... I thought from what some posters 
have
said that there was some crazy way to deal with tcp that didn't involve 
struct
juggling...



^ permalink raw reply	[flat|nested] 433+ messages in thread

* Re: [9fans] (no subject)
  2004-12-14 23:00                 ` jim
@ 2004-12-14 23:07                   ` boyd, rounin
  2004-12-14 23:27                   ` Dan Cross
  1 sibling, 0 replies; 433+ messages in thread
From: boyd, rounin @ 2004-12-14 23:07 UTC (permalink / raw)
  To: Fans of the OS Plan 9 from Bell Labs

> Aha. I suppose I'm in over my head here; I can't really see what you
> mean by 'marshal'; is that a technical term? Are you talking about
> progressively slicing bytes off a stream to get each value?
> 
> /me starts googling... ;-p

this peels UDP packets apart with help from jeff mogul's packetfilter:

    http://www.insultant.net/code/xwhosup.msg



^ permalink raw reply	[flat|nested] 433+ messages in thread

* Re: [9fans] (no subject)
  2004-12-14 22:48               ` Dan Cross
  2004-12-14 22:47                 ` boyd, rounin
@ 2004-12-14 23:00                 ` jim
  2004-12-14 23:07                   ` boyd, rounin
  2004-12-14 23:27                   ` Dan Cross
  1 sibling, 2 replies; 433+ messages in thread
From: jim @ 2004-12-14 23:00 UTC (permalink / raw)
  To: Fans of the OS Plan 9 from Bell Labs


On 14 Dec 2004, at 22:48, Dan Cross wrote:

> You don't.  In the
> specific case you mention, you write code to marshal it into and
> demarshal it from a byte stream.

Aha. I suppose I'm in over my head here; I can't really see what you
mean by 'marshal'; is that a technical term? Are you talking about
progressively slicing bytes off a stream to get each value?

/me starts googling... ;-p



^ permalink raw reply	[flat|nested] 433+ messages in thread

* Re: [9fans] (no subject)
  2004-12-14 22:36             ` jim
  2004-12-14 22:48               ` Dan Cross
  2004-12-14 22:50               ` Brantley Coile
@ 2004-12-14 22:55               ` andrey mirtchovski
  2004-12-14 23:35               ` Ronald G. Minnich
  3 siblings, 0 replies; 433+ messages in thread
From: andrey mirtchovski @ 2004-12-14 22:55 UTC (permalink / raw)
  To: 9fans

> On 14 Dec 2004, at 22:26, boyd, rounin wrote:
> 
>> sounds right to me.  damn idiots.
>>
> If you'll pardon a humble mortal's ignorance, what's so bad about it? 
> Well, re-phrase that -
> how else to do accurate bit-packed structs like for tcp/ip headers? As 
> I read this thread,
> 'packed' allows just that; it tells the compiler not to mess with how 
> you've packed a given
> struct. In which case, it seems pretty useful to me - I'd love to know 
> how real coders do
> tcp/ip headers :-S.
> 
> cheers,
> 
> jim

i shall refer you to the original hjdicks thread starting at:

http://lists.cse.psu.edu/archives/9fans/2004-October/038406.html



^ permalink raw reply	[flat|nested] 433+ messages in thread

* Re: [9fans] (no subject)
  2004-12-14 22:36             ` jim
  2004-12-14 22:48               ` Dan Cross
@ 2004-12-14 22:50               ` Brantley Coile
  2004-12-14 23:08                 ` jim
  2004-12-14 22:55               ` andrey mirtchovski
  2004-12-14 23:35               ` Ronald G. Minnich
  3 siblings, 1 reply; 433+ messages in thread
From: Brantley Coile @ 2004-12-14 22:50 UTC (permalink / raw)
  To: 9fans

> I'd love to
> know how real coders do tcp/ip headers :-S.

>From my netometer project

typedef struct TCP TCP;
struct	TCP	{
	short	src;
	short	dest;
	ulong	seq;
	ulong	ack;
	ushort	flags;	/* and header length */
	ushort	wnd;
	ushort	chksum;
	ushort	urgptr;
	ulong	options;
};

>From my nas/point project


typedef struct {
	uchar	src[2];
	uchar	dst[2];
	uchar	len[2];
	uchar	csum[2];
} Udp_pkt;

typedef Udp_pkt UDP;


These are two ways I have done it.  I like the latter since I
don't have to worry about alignment at all.  I first heard
of the uchar approach from Norman Wilson, but everyone
who has looked at the network code in Plan 9 will recognise it.


 Brantley



^ permalink raw reply	[flat|nested] 433+ messages in thread

* Re: [9fans] (no subject)
  2004-12-14 22:36             ` jim
@ 2004-12-14 22:48               ` Dan Cross
  2004-12-14 22:47                 ` boyd, rounin
  2004-12-14 23:00                 ` jim
  2004-12-14 22:50               ` Brantley Coile
                                 ` (2 subsequent siblings)
  3 siblings, 2 replies; 433+ messages in thread
From: Dan Cross @ 2004-12-14 22:48 UTC (permalink / raw)
  To: Fans of the OS Plan 9 from Bell Labs

jim <jim.whitson@gmail.com> writes:
> If you'll pardon a humble mortal's ignorance, what's so bad about it? 
> Well, re-phrase that - how else to do accurate bit-packed structs like
> for tcp/ip headers? As I read this thread, 'packed' allows just that;
> it tells the compiler not to mess with how you've packed a given
> struct. In which case, it seems pretty useful to me - I'd love to know 
> how real coders do tcp/ip headers :-S.

How do you do `accurate bit-packed structs'?  You don't.  In the
specific case you mention, you write code to marshal it into and
demarshal it from a byte stream.

The argument(s) for packed structus is that it makes (1) in-core
representations more space-efficient (who cares, honestly, about saving
a few bytes here?  Maybe for some embedded environments it makes sense,
but in general, I'd say don't bother), (2) makes the program `cleaner'
by not having to write explicit marshalling code.  I think if that code
is written properly (ie, isolated somewhere) it's not significantly
cleaner than the alternative, unpacked record, and (3) I'm sure that
the false-idol of efficiency is worshipped somewhere with the cost of
marshalling, both in terms of space and time.  This last I'd say is a
pure straw-man: if you have to trap into the kernel with every memory
access, you're really not doing yourself any good in terms of time, and
usually you're going to assemble the packet in fragments and copy it
all somewhere at the last second anyway.  You could do the marshalling
then and avoid the whole multiple-trap thing, with no additional cost
in memory usage.

Basically, this is one of those ideas where someone said, ``hey,
wouldn't it be cool if...'' and fixed a problem with the design of
their code by changing the language.

	- Dan C.



^ permalink raw reply	[flat|nested] 433+ messages in thread

* Re: [9fans] (no subject)
  2004-12-14 22:48               ` Dan Cross
@ 2004-12-14 22:47                 ` boyd, rounin
  2004-12-14 23:00                 ` jim
  1 sibling, 0 replies; 433+ messages in thread
From: boyd, rounin @ 2004-12-14 22:47 UTC (permalink / raw)
  To: Fans of the OS Plan 9 from Bell Labs

From: "Dan Cross" <cross@math.psu.edu>

> ...

yeah, what the Marine said.



^ permalink raw reply	[flat|nested] 433+ messages in thread

* Re: [9fans] (no subject)
  2004-12-14 22:26           ` boyd, rounin
@ 2004-12-14 22:36             ` jim
  2004-12-14 22:48               ` Dan Cross
                                 ` (3 more replies)
  0 siblings, 4 replies; 433+ messages in thread
From: jim @ 2004-12-14 22:36 UTC (permalink / raw)
  To: Fans of the OS Plan 9 from Bell Labs


On 14 Dec 2004, at 22:26, boyd, rounin wrote:

> sounds right to me.  damn idiots.
>
If you'll pardon a humble mortal's ignorance, what's so bad about it? 
Well, re-phrase that -
how else to do accurate bit-packed structs like for tcp/ip headers? As 
I read this thread,
'packed' allows just that; it tells the compiler not to mess with how 
you've packed a given
struct. In which case, it seems pretty useful to me - I'd love to know 
how real coders do
tcp/ip headers :-S.

cheers,

jim



^ permalink raw reply	[flat|nested] 433+ messages in thread

* Re: [9fans] (no subject)
  2004-12-14 22:16       ` Charles Forsyth
@ 2004-12-14 22:26         ` Ronald G. Minnich
  2004-12-14 22:26           ` boyd, rounin
  0 siblings, 1 reply; 433+ messages in thread
From: Ronald G. Minnich @ 2004-12-14 22:26 UTC (permalink / raw)
  To: Fans of the OS Plan 9 from Bell Labs



On Tue, 14 Dec 2004, Charles Forsyth wrote:

> i thought the rationale (seemed to be) that by using `packed',
> a programmer could describe an arbitrary protocol header
> (ok, the one for tcp/ip) using a precise sequence of C declarations
> within a structure and prevent the compiler from rearranging it
> to suit the given processor's natural alignment rules.

yeah you're right. That was the motivation. 

this packed stuff is a mistake repeated every few years. I first hit it in 
a compiler I used at HP for embedded programming before many of you were 
born. I refuse to talk about it.

ron


^ permalink raw reply	[flat|nested] 433+ messages in thread

* Re: [9fans] (no subject)
  2004-12-14 22:26         ` Ronald G. Minnich
@ 2004-12-14 22:26           ` boyd, rounin
  2004-12-14 22:36             ` jim
  0 siblings, 1 reply; 433+ messages in thread
From: boyd, rounin @ 2004-12-14 22:26 UTC (permalink / raw)
  To: Fans of the OS Plan 9 from Bell Labs

> yeah you're right. That was the motivation. 

sounds right to me.  damn idiots.



^ permalink raw reply	[flat|nested] 433+ messages in thread

* Re: [9fans] (no subject)
  2004-12-14 22:12       ` andrey mirtchovski
@ 2004-12-14 22:25         ` Ronald G. Minnich
  0 siblings, 0 replies; 433+ messages in thread
From: Ronald G. Minnich @ 2004-12-14 22:25 UTC (permalink / raw)
  To: Fans of the OS Plan 9 from Bell Labs



On Tue, 14 Dec 2004, andrey mirtchovski wrote:

> i bet the answer is 'that's the way we've always done it' :)

google kicks ass once again.

when did packed attribute gcc

gets:

http://www.ohse.de/uwe/articles/gcc-attributes.html

follow type attributes to packed:

packed
    Found in versions: 2.7-3.4 
    Description:

     This attribute, attached to `struct' or `union' type definition,
     specifies that each member of the structure or union is placed to
     minimize the memory required. When attached to an `enum'
     definition, it indicates that the smallest integral type should be
     used.

so whenever 2.7 came out, left as problem for reader.

so we clearly hain't always dun it thet way.

ron


^ permalink raw reply	[flat|nested] 433+ messages in thread

* Re: [9fans] (no subject)
  2004-12-14 22:01     ` Ronald G. Minnich
  2004-12-14 22:12       ` andrey mirtchovski
@ 2004-12-14 22:16       ` Charles Forsyth
  2004-12-14 22:26         ` Ronald G. Minnich
  1 sibling, 1 reply; 433+ messages in thread
From: Charles Forsyth @ 2004-12-14 22:16 UTC (permalink / raw)
  To: 9fans

>>I am not sure the rationale was performance.

sorry, i've confused things.  i didn't mean that.

i thought the rationale (seemed to be) that by using `packed',
a programmer could describe an arbitrary protocol header
(ok, the one for tcp/ip) using a precise sequence of C declarations
within a structure and prevent the compiler from rearranging it
to suit the given processor's natural alignment rules.
that way the programmer could write simple C structure member accesses
to access the elements of the header, rather than having to unpack explicitly.
thus having `packed' makes the program both more readable and portable
(except that non-gcc C compilers don't necessarily implement an analogue to `packed').

some fields will therefore be unaligned (on some processors).

if, however, every unaligned access causes a trap to the kernel to repair,
not only is it relying on every kernel resolving such traps, but more important,
traps on most architectures are sufficiently expensive that .... it's horrendous!
most compilers that are required to do it, compensate by generating code
at the point of access that (somehow) does what is required.



^ permalink raw reply	[flat|nested] 433+ messages in thread

* Re: [9fans] (no subject)
  2004-12-14 22:01     ` Ronald G. Minnich
@ 2004-12-14 22:12       ` andrey mirtchovski
  2004-12-14 22:25         ` Ronald G. Minnich
  2004-12-14 22:16       ` Charles Forsyth
  1 sibling, 1 reply; 433+ messages in thread
From: andrey mirtchovski @ 2004-12-14 22:12 UTC (permalink / raw)
  To: 9fans


> I am not sure the rationale was performance. I actually don't know what 
> the rationale was, I never followed it up. I plan to.
> 
> ron

i bet the answer is 'that's the way we've always done it' :)

off-topic side note:

	http://www.thecommittedsardine.net/infosavvy/education/handouts/ttwwadi.pdf



^ permalink raw reply	[flat|nested] 433+ messages in thread

* Re: [9fans] (no subject)
  2004-12-14 21:38   ` Charles Forsyth
@ 2004-12-14 22:01     ` Ronald G. Minnich
  2004-12-14 22:12       ` andrey mirtchovski
  2004-12-14 22:16       ` Charles Forsyth
  0 siblings, 2 replies; 433+ messages in thread
From: Ronald G. Minnich @ 2004-12-14 22:01 UTC (permalink / raw)
  To: Fans of the OS Plan 9 from Bell Labs



On Tue, 14 Dec 2004, Charles Forsyth wrote:

> but if an application trying to use it to access `packed' protocol headers,
> that's hardly going to help performance, so that rationale for
> having it at all, which i think was one mentioned earlier (i think with xen),
> is hardly a compelling one!

I am not sure the rationale was performance. I actually don't know what 
the rationale was, I never followed it up. I plan to.

ron


^ permalink raw reply	[flat|nested] 433+ messages in thread

* Re: [9fans] (no subject)
  2004-12-14 21:19 ` Ronald G. Minnich
  2004-12-14 21:33   ` boyd, rounin
@ 2004-12-14 21:38   ` Charles Forsyth
  2004-12-14 22:01     ` Ronald G. Minnich
  1 sibling, 1 reply; 433+ messages in thread
From: Charles Forsyth @ 2004-12-14 21:38 UTC (permalink / raw)
  To: 9fans

>>yes, the kernel is supposed to do that fixup on linux. 

but if an application trying to use it to access `packed' protocol headers,
that's hardly going to help performance, so that rationale for
having it at all, which i think was one mentioned earlier (i think with xen),
is hardly a compelling one!



^ permalink raw reply	[flat|nested] 433+ messages in thread

* Re: [9fans] (no subject)
  2004-12-14 21:19 ` Ronald G. Minnich
@ 2004-12-14 21:33   ` boyd, rounin
  2004-12-14 21:38   ` Charles Forsyth
  1 sibling, 0 replies; 433+ messages in thread
From: boyd, rounin @ 2004-12-14 21:33 UTC (permalink / raw)
  To: Fans of the OS Plan 9 from Bell Labs

> yes, the kernel is supposed to do that fixup on linux. 

oh, how wonderful, sigh ...



^ permalink raw reply	[flat|nested] 433+ messages in thread

* Re: [9fans] (no subject)
  2004-12-14 20:33 Charles Forsyth
  2004-12-14 21:02 ` Bruce Ellis
@ 2004-12-14 21:19 ` Ronald G. Minnich
  2004-12-14 21:33   ` boyd, rounin
  2004-12-14 21:38   ` Charles Forsyth
  1 sibling, 2 replies; 433+ messages in thread
From: Ronald G. Minnich @ 2004-12-14 21:19 UTC (permalink / raw)
  To: Fans of the OS Plan 9 from Bell Labs



On Tue, 14 Dec 2004, Charles Forsyth wrote:

> that reminds me that, prompted by an aside that brucee made last time
> hjdicks came up (so to speak), i had a quick look then at the __packed
> attribute (or whatever it was) that gcc implemented, on a few non-x86
> platforms. it seemed to me that it didn't implement it properly either.  
> in particular, on architectures on which alignment traps might or will
> occur for certain unaligned accesses, the code generated made no attempt
> to avoid them.  neither does ?[acl] as it happens, so at least we're
> completely compatible with gcc in one thing.


yes, the kernel is supposed to do that fixup on linux. 

Overall packed is just a mess. 

ron


^ permalink raw reply	[flat|nested] 433+ messages in thread

* Re: [9fans] (no subject)
  2004-12-14 20:33 Charles Forsyth
@ 2004-12-14 21:02 ` Bruce Ellis
  2004-12-14 21:19 ` Ronald G. Minnich
  1 sibling, 0 replies; 433+ messages in thread
From: Bruce Ellis @ 2004-12-14 21:02 UTC (permalink / raw)
  To: Fans of the OS Plan 9 from Bell Labs

it gets even fuunier the harder people try to get gcc to
align things "correctly".  two examples are the gcc for
the ps2 (where 128 bit alignment is often good/needed)
and the hoops in fftw to try and align the stack for
SIMD optimization.  C99 lacks GOK and maybe Egreg.

brucee

Charles Forsyth wrote:
> Re: [9fans] plan9ports and freebsd 4.x
> 
>>>you're just mad because they didn't put hjdicks in C99.
> 
> that reminds me that, prompted by an aside that brucee made
> last time hjdicks came up (so to speak),
> i had a quick look then at the __packed attribute (or whatever it was)
> that gcc implemented, on a few non-x86 platforms.
> it seemed to me that it didn't implement it
> properly either.  in particular, on architectures on which
> alignment traps might or will occur for certain unaligned
> accesses, the code generated made no
> attempt to avoid them.  neither does ?[acl] as it happens,
> so at least we're completely compatible with gcc in one thing.


^ permalink raw reply	[flat|nested] 433+ messages in thread

* [9fans] (no subject)
@ 2004-12-14 20:33 Charles Forsyth
  2004-12-14 21:02 ` Bruce Ellis
  2004-12-14 21:19 ` Ronald G. Minnich
  0 siblings, 2 replies; 433+ messages in thread
From: Charles Forsyth @ 2004-12-14 20:33 UTC (permalink / raw)
  To: 9fans

Re: [9fans] plan9ports and freebsd 4.x

>>you're just mad because they didn't put hjdicks in C99.

that reminds me that, prompted by an aside that brucee made
last time hjdicks came up (so to speak),
i had a quick look then at the __packed attribute (or whatever it was)
that gcc implemented, on a few non-x86 platforms.
it seemed to me that it didn't implement it
properly either.  in particular, on architectures on which
alignment traps might or will occur for certain unaligned
accesses, the code generated made no
attempt to avoid them.  neither does ?[acl] as it happens,
so at least we're completely compatible with gcc in one thing.



^ permalink raw reply	[flat|nested] 433+ messages in thread

* Re: [9fans] (no subject)
  2004-12-01 18:37 ` Jack Johnson
@ 2004-12-01 18:47   ` Christopher Nielsen
  0 siblings, 0 replies; 433+ messages in thread
From: Christopher Nielsen @ 2004-12-01 18:47 UTC (permalink / raw)
  To: Jack Johnson, Fans of the OS Plan 9 from Bell Labs

I used to work with Greg Stein and chatted with him a
few times about WebDAV for Plan9. He suggested trying
to port neon before writing support from scratch.

On Wed, Dec 01, 2004 at 10:37:05AM -0800, Jack Johnson wrote:
> On Wed, 1 Dec 2004 10:57:16 0000, Steve Simon <steve@quintile.net> wrote:
> > I need, in decreasing order of importance:
> > 
> >         RFC2136 DNS update
> >         CIFS message signing
> >         kerbros / GSSAPI
> >         LDAP client
> >         WebDav
> 
> Some of the standard UNIX utils might port over easily using APE.  I'd
> be tempted to look at ldaputils and cadaver for the bottom two on your
> list.
> 
> The others are likely to be (much) more of a challenge.
> 
> -Jack
> 

-- 
Christopher Nielsen
"They who can give up essential liberty for temporary
safety, deserve neither liberty nor safety." --Benjamin Franklin


^ permalink raw reply	[flat|nested] 433+ messages in thread

* Re: [9fans] (no subject)
  2004-12-01 10:57 Steve Simon
  2004-12-01 11:03 ` Tiit Lankots
@ 2004-12-01 18:37 ` Jack Johnson
  2004-12-01 18:47   ` Christopher Nielsen
  1 sibling, 1 reply; 433+ messages in thread
From: Jack Johnson @ 2004-12-01 18:37 UTC (permalink / raw)
  To: Fans of the OS Plan 9 from Bell Labs

On Wed, 1 Dec 2004 10:57:16 0000, Steve Simon <steve@quintile.net> wrote:
> I need, in decreasing order of importance:
> 
>         RFC2136 DNS update
>         CIFS message signing
>         kerbros / GSSAPI
>         LDAP client
>         WebDav

Some of the standard UNIX utils might port over easily using APE.  I'd
be tempted to look at ldaputils and cadaver for the bottom two on your
list.

The others are likely to be (much) more of a challenge.

-Jack


^ permalink raw reply	[flat|nested] 433+ messages in thread

* Re: [9fans] (no subject)
  2004-12-01 10:57 Steve Simon
@ 2004-12-01 11:03 ` Tiit Lankots
  2004-12-01 18:37 ` Jack Johnson
  1 sibling, 0 replies; 433+ messages in thread
From: Tiit Lankots @ 2004-12-01 11:03 UTC (permalink / raw)
  To: Fans of the OS Plan 9 from Bell Labs

> 	RFC2136 DNS update
> 	CIFS message signing
> 	kerbros / GSSAPI
> 	LDAP client
> 	WebDav

Python has many of these things. Python has been ported to Plan 9.
I'd recommend it for RAD. You can rewrite it later in C.


^ permalink raw reply	[flat|nested] 433+ messages in thread

* [9fans] (no subject)
@ 2004-12-01 10:57 Steve Simon
  2004-12-01 11:03 ` Tiit Lankots
  2004-12-01 18:37 ` Jack Johnson
  0 siblings, 2 replies; 433+ messages in thread
From: Steve Simon @ 2004-12-01 10:57 UTC (permalink / raw)
  To: Win2k3, 9fans

Hi,

My (work) world is being turned upside down
by the introduction of windows 2003 servers.

I need, in decreasing order of importance:

	RFC2136 DNS update
	CIFS message signing
	kerbros / GSSAPI
	LDAP client
	WebDav

I shall be trying to write some of this
over the comming months, however if anyone
has any thing to contribute in terms of code ☺,
ideas, opinions etc. I would love to hear.

-Steve


^ permalink raw reply	[flat|nested] 433+ messages in thread

* [9fans] (no subject)
@ 2004-11-09 13:28 cej
  0 siblings, 0 replies; 433+ messages in thread
From: cej @ 2004-11-09 13:28 UTC (permalink / raw)
  To: 9fans

hello there,

i acknowledge [recent] extension of 'page' - i mean middle button menu - however, could we have true zooming, not just resampling the old bitmap? Something like '-p nnn' on the fly...


BTW, can I force 'page' to custom bbox when the document [pdf] has trimmed margin[s]?   -b -P desn't help...


thanks, best regards,
++pac.



---
Odchozí zpráva neobsahuje viry.
Zkontrolováno antivirovým systémem AVG (http://www.grisoft.cz).
Verze: 6.0.792 / Virová báze: 536 - datum vydání: 9. 11. 2004
 


^ permalink raw reply	[flat|nested] 433+ messages in thread

* Re: [9fans] (no subject)
  2004-07-28  4:08     ` Dan Cross
@ 2004-07-28  4:39       ` Justin Herald
  0 siblings, 0 replies; 433+ messages in thread
From: Justin Herald @ 2004-07-28  4:39 UTC (permalink / raw)
  To: Fans of the OS Plan 9 from Bell Labs


On Jul 28, 2004, at 12:08 AM, Dan Cross wrote:

> ...
> Yes, but bear in mind that Plan 9 wasn't really designed with world
> domination in mind.  It's a research system.  That it evolved into a
> very comfortable environment for the people who built it to do *other*
> research on made it possible to pursue other goals on it is almost an
> accident of history.  So the question is, who cares how much support it
> gets in the world?  Should the goal of any system apriori be to attract
> lots of users?  I don't think so.  It should do something interesting
> in a clean, elegant way.  But that's just my personal opinion.
A good point, for 'tis a research OS (I know some of my classmates and
I have had fun with it), but then again, how did Unix come about? I
guess bringing with us the knowledge we have gained from earlier OSes
also brought with us similar ambitions to get a stronger user base. I
want to see a stronger user base so that the development and
propagation of this OS realizes its potential.



^ permalink raw reply	[flat|nested] 433+ messages in thread

* Re: [9fans] (no subject)
  2004-07-27 10:54   ` Steve Simon
                       ` (2 preceding siblings ...)
  2004-07-27 20:22     ` Skip Tavakkolian
@ 2004-07-28  4:08     ` Dan Cross
  2004-07-28  4:39       ` Justin Herald
  3 siblings, 1 reply; 433+ messages in thread
From: Dan Cross @ 2004-07-28  4:08 UTC (permalink / raw)
  To: Fans of the OS Plan 9 from Bell Labs

"Steve Simon" <steve@quintile.net> writes:
>
> [...]
>
> I was disturbed by David and Russ leaving the labs, and I am
> worried that the 9fans community is losing momentum - perhaps
> there are many great projects under way but I don't hear of them.

It is (losing momentum).  But then, it only had very little to begin
with.  The problem, as I see it (several months removed from the
`scene' as I am right now; I was probably lobbing hand gernades over a
berm somewhere when they left the labs), is that the driving force of
recent years is gone: building a comfortable system for doing research,
but one that's interesting in its own right.

With the deflating of Murray Hill as a hub for activity - mainly
development, but also pushing on the license issues and such - there's
little direction in the system.  Everyone who was influential in the
early days was using Plan 9 for one of two reasons: they wanted a nice
environment to do computer science research, or they were interested in
operating systems research and Plan 9 was an interesting thing to
study.  But that's the kind of thing you can do when you work in a
university or an industrial research lab that starts projects with the
understanding that it might be 30 years before they show a positive
ROA.

Most of those people now has other things they have to do; they can't
afford to continue hammering on Plan 9 full time anymore, and no one
single organization seems to exist to fill the void.  What's more, as
they leave the `community' (btw- I really hate that term), or at least
become more reclusive, they take with them the sense of taste and style
that made Plan 9 unique.  After all, the thing that makes the system
unique is the aggressive development of ideas taken from earlier
systems, with some new stuff thrown in.  But the thing that makes it
*good* is the quality of the system as a whole.  Anybody can probably
re-implement the ideas in Plan 9, but the trick is to do it well, and
that is very much harder indeed.

I doubt the appropriate environment to take up the torch of Plan 9
development exists anywhere in the world: a bunch of really smart
people that also have good style sitting around (by agreement!) in the
same physical room with the capital and support to work on whatever
they want, and who want to work on something like this.  Much as people
want to tote the ``feel-good'' party line of open source and disjoint
development efforts coordinated over the Internet, I really doubt
that's the answer: the world has yet to see a *good* project emerge
from such techniques.  What's lacking is a suitable research center to
pick up where Bell Labs left off and push the system further.  Without
systems research, you can't sustain a research system.  There's no
systems research going on, therefore the system is withering and
dying.  Without good people driving it, the system will take a nose
dive because, frankly, most people aren't skilled enough to do it
properly (look at Linux!).  If Rob Pike is a master chef, then most of
us are Subway sandwich artists, and an even greater portion of the
population can't even make peanut butter and jelly sandwiches.

Or maybe I'm just overly pessimistic.  As Geoff points out, people are
using it and satisfied with it, and maybe that's enough.

> It has been said before, the limited of support plan9 gets
> in the world is partly due to its steep learning curve, and
> partly the lack of "standard" applications.

Yes, but bear in mind that Plan 9 wasn't really designed with world
domination in mind.  It's a research system.  That it evolved into a
very comfortable environment for the people who built it to do *other*
research on made it possible to pursue other goals on it is almost an
accident of history.  So the question is, who cares how much support it
gets in the world?  Should the goal of any system apriori be to attract
lots of users?  I don't think so.  It should do something interesting
in a clean, elegant way.  But that's just my personal opinion.

> Writing a web browser difficult, we all agree, however editing the
> wiki to make it more up to date, accurate and helpfull is easy
> (and yes I have been).

That's a noble and worthy goal in its own right, and I won't
argue with it.

	- Dan C.



^ permalink raw reply	[flat|nested] 433+ messages in thread

* Re: [9fans] (no subject)
@ 2004-07-28  2:10 YAMANASHI Takeshi
  0 siblings, 0 replies; 433+ messages in thread
From: YAMANASHI Takeshi @ 2004-07-28  2:10 UTC (permalink / raw)
  To: 9fans

> Why not generate a proto file for mkfs/mkext to copy the
> minimal set of files for the auth server to your compact
> flash, and then post the proto file on the wiki?

Here is my proto file.  I used this to copy necesary files
into a single dos floppy.  My auth server is two-floppy
(one for 9load & kernel, the other for fs) based standalone
server.
--
386
	init
	bin
		rc
		cat
		echo
		ls
		ps
		date
		ip
			ipconfig
		ndb
			cs
		aux
			listen
		auth
			keyfs
			changeuser
			authsrv
adm
	timezone
		local
	keys
	keys.who
rc
	bin
		service
		service.auth
			authsrv.il566
			authsrv.tcp567
	lib
		rcmain
lib
	namespace
	ndb
		local
		auth
mnt
	keys
	netkeys




^ permalink raw reply	[flat|nested] 433+ messages in thread

* Re: [9fans] (no subject)
  2004-07-27 10:54   ` Steve Simon
  2004-07-27 13:36     ` Boris Maryshev
  2004-07-27 19:55     ` Francisco Ballesteros
@ 2004-07-27 20:22     ` Skip Tavakkolian
  2004-07-28  4:08     ` Dan Cross
  3 siblings, 0 replies; 433+ messages in thread
From: Skip Tavakkolian @ 2004-07-27 20:22 UTC (permalink / raw)
  To: 9fans

> I was disturbed by David and Russ leaving the labs, and I am
> worried that the 9fans community is losing momentum - perhaps
> there are many great projects under way but I don't hear of them.

We're working on a project.  I'll tell everyone about it when it is
ready.



^ permalink raw reply	[flat|nested] 433+ messages in thread

* Re: [9fans] (no subject)
  2004-07-27 10:54   ` Steve Simon
  2004-07-27 13:36     ` Boris Maryshev
@ 2004-07-27 19:55     ` Francisco Ballesteros
  2004-07-27 20:22     ` Skip Tavakkolian
  2004-07-28  4:08     ` Dan Cross
  3 siblings, 0 replies; 433+ messages in thread
From: Francisco Ballesteros @ 2004-07-27 19:55 UTC (permalink / raw)
  To: Fans of the OS Plan 9 from Bell Labs

Don't know if it qualifies as a great project or not.
But we're changing things in Plan 9 to make it adapt to
changes in the environment. We'll drop a line in the near future about
this. But it might still take a month or two.
`
PS: I got this bounced and I'm retrying. Sorry if it leads to dups.

On Tue, 27 Jul 2004 11:54:16 +0100, Steve Simon <steve@quintile.net> wrote:
> > I think because this is Plan 9 fans list, not Linux mailing list? ☺
> 
> Aw, no fair.
> 
> I was disturbed by David and Russ leaving the labs, and I am
> worried that the 9fans community is losing momentum - perhaps
> there are many great projects under way but I don't hear of them.
> 
> It has been said before, the limited of support plan9 gets
> in the world is partly due to its steep learning curve, and
> partly the lack of "standard" applications.
> 
> Writing a web browser difficult, we all agree, however editing the
> wiki to make it more up to date, accurate and helpfull is easy
> (and yes I have been).
> 
> -Steve
>


^ permalink raw reply	[flat|nested] 433+ messages in thread

* Re: [9fans] (no subject)
  2004-07-27 13:36     ` Boris Maryshev
@ 2004-07-27 15:23       ` Justin Herald
  0 siblings, 0 replies; 433+ messages in thread
From: Justin Herald @ 2004-07-27 15:23 UTC (permalink / raw)
  To: Fans of the OS Plan 9 from Bell Labs

I would agree that most of the true power comes from it's distributed 
nature and developing on top of that and supporting new hardware should 
be the top priority. On the other hand, if we want to get p9 out there 
and more in the spotlight, there need to be some more common 
applications for it that SysAdmins and developers are familiar with to 
get them intrigued in the OS and it's potential


On Jul 27, 2004, at 9:36 AM, Boris Maryshev wrote:

> On Tuesday 27 July 2004 13:54, Steve Simon wrote:
>>> I think because this is Plan 9 fans list, not Linux mailing list? ☺
> What's collaboration in Plan 9 way, then? Bashing Linux all together?
>>
>> Aw, no fair.
>>
>> I was disturbed by David and Russ leaving the labs, and I am
>> worried that the 9fans community is losing momentum - perhaps
>> there are many great projects under way but I don't hear of them.
> They pop-up here from time-to-time. It's just that they pop-up only 
> here...
>>
>> It has been said before, the limited of support plan9 gets
>> in the world is partly due to its steep learning curve, and
>> partly the lack of "standard" applications.
> Like what application?
>>
>> Writing a web browser difficult, we all agree, however editing the
>> wiki to make it more up to date, accurate and helpfull is easy
>> (and yes I have been).
> Maybe writing a web browser, or office suite or anything like this is 
> not the
> interesting area to work on with Plan 9? Maybe it'd be more 
> interesting to
> study Plan 9's distributed nature and invent new things on top of it? 
> What
> about putting httpd working in a 9grid and distributing load between 
> nodes,
> which might be located worldwide (Akamai would be happy...)?
>>
>> -Steve
> I wouldn't say "steep learning curve" either. It was made following 
> KISS
> principle, remember? I'd say, that the hurdle comes when you try to 
> make it
> work on an unsupported hardware and fail. So what we need are not
> "applications", but better support for hardware. And new ideas 
> exploiting
> Plan 9's philosophy.
>
> boris
> -- 
> But in our enthusiasm, we could not resist a radical overhaul of the
> system, in which all of its major weaknesses have been exposed,
> analyzed, and replaced with new weaknesses.
> 		-- Bruce Leverett,
> 		"Register Allocation in Optimizing Compilers"
>



^ permalink raw reply	[flat|nested] 433+ messages in thread

* Re: [9fans] (no subject)
  2004-07-27 10:54   ` Steve Simon
@ 2004-07-27 13:36     ` Boris Maryshev
  2004-07-27 15:23       ` Justin Herald
  2004-07-27 19:55     ` Francisco Ballesteros
                       ` (2 subsequent siblings)
  3 siblings, 1 reply; 433+ messages in thread
From: Boris Maryshev @ 2004-07-27 13:36 UTC (permalink / raw)
  To: Fans of the OS Plan 9 from Bell Labs

On Tuesday 27 July 2004 13:54, Steve Simon wrote:
> > I think because this is Plan 9 fans list, not Linux mailing list? ☺
What's collaboration in Plan 9 way, then? Bashing Linux all together?
>
> Aw, no fair.
>
> I was disturbed by David and Russ leaving the labs, and I am
> worried that the 9fans community is losing momentum - perhaps
> there are many great projects under way but I don't hear of them.
They pop-up here from time-to-time. It's just that they pop-up only here...
>
> It has been said before, the limited of support plan9 gets
> in the world is partly due to its steep learning curve, and
> partly the lack of "standard" applications.
Like what application?
>
> Writing a web browser difficult, we all agree, however editing the
> wiki to make it more up to date, accurate and helpfull is easy
> (and yes I have been).
Maybe writing a web browser, or office suite or anything like this is not the 
interesting area to work on with Plan 9? Maybe it'd be more interesting to 
study Plan 9's distributed nature and invent new things on top of it? What 
about putting httpd working in a 9grid and distributing load between nodes, 
which might be located worldwide (Akamai would be happy...)?
>
> -Steve
I wouldn't say "steep learning curve" either. It was made following KISS 
principle, remember? I'd say, that the hurdle comes when you try to make it 
work on an unsupported hardware and fail. So what we need are not 
"applications", but better support for hardware. And new ideas exploiting 
Plan 9's philosophy.

boris
-- 
But in our enthusiasm, we could not resist a radical overhaul of the
system, in which all of its major weaknesses have been exposed,
analyzed, and replaced with new weaknesses.
		-- Bruce Leverett,
		"Register Allocation in Optimizing Compilers"


^ permalink raw reply	[flat|nested] 433+ messages in thread

* Re: [9fans] (no subject)
  2004-07-27  9:38 ` Kenji Okamoto
  2004-07-27  9:44   ` Lucio De Re
@ 2004-07-27 10:54   ` Steve Simon
  2004-07-27 13:36     ` Boris Maryshev
                       ` (3 more replies)
  1 sibling, 4 replies; 433+ messages in thread
From: Steve Simon @ 2004-07-27 10:54 UTC (permalink / raw)
  To: 9fans

> I think because this is Plan 9 fans list, not Linux mailing list? ☺

Aw, no fair.

I was disturbed by David and Russ leaving the labs, and I am
worried that the 9fans community is losing momentum - perhaps
there are many great projects under way but I don't hear of them.

It has been said before, the limited of support plan9 gets
in the world is partly due to its steep learning curve, and
partly the lack of "standard" applications.

Writing a web browser difficult, we all agree, however editing the
wiki to make it more up to date, accurate and helpfull is easy
(and yes I have been).

-Steve


^ permalink raw reply	[flat|nested] 433+ messages in thread

* Re: [9fans] (no subject)
  2004-07-27  9:38 ` Kenji Okamoto
@ 2004-07-27  9:44   ` Lucio De Re
  2004-07-27 10:54   ` Steve Simon
  1 sibling, 0 replies; 433+ messages in thread
From: Lucio De Re @ 2004-07-27  9:44 UTC (permalink / raw)
  To: 9fans

> I think because this is Plan 9 fans list, not Linux mailing list? ☺

I hope _this_ is not the discriminant between Linux and Plan 9
audiences?

++L



^ permalink raw reply	[flat|nested] 433+ messages in thread

* Re: [9fans] (no subject)
  2004-07-27  9:08 Steve Simon
@ 2004-07-27  9:38 ` Kenji Okamoto
  2004-07-27  9:44   ` Lucio De Re
  2004-07-27 10:54   ` Steve Simon
  0 siblings, 2 replies; 433+ messages in thread
From: Kenji Okamoto @ 2004-07-27  9:38 UTC (permalink / raw)
  To: 9fans

> Why not generate a proto file for mkfs/mkext to copy the
> minimal set of files for the auth server to your compact
> flash, and then post the proto file on the wiki?

I think because this is Plan 9 fans list, not Linux mailing list? ☺

Kenji



^ permalink raw reply	[flat|nested] 433+ messages in thread

* [9fans] (no subject)
@ 2004-07-27  9:08 Steve Simon
  2004-07-27  9:38 ` Kenji Okamoto
  0 siblings, 1 reply; 433+ messages in thread
From: Steve Simon @ 2004-07-27  9:08 UTC (permalink / raw)
  To: 9fans

In a comunity spirit...

Why not generate a proto file for mkfs/mkext to copy the
minimal set of files for the auth server to your compact
flash, and then post the proto file on the wiki?

-Steve


^ permalink raw reply	[flat|nested] 433+ messages in thread

* [9fans] (no subject)
@ 2004-07-26 17:59 steve
  0 siblings, 0 replies; 433+ messages in thread
From: steve @ 2004-07-26 17:59 UTC (permalink / raw)
  To: 9fans

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

------------------  Virus Warning Message (on the network)

Found virus WORM_MYDOOM.M in file text.html                                                                                                                        .pif (in text.zip)
The file text.zip is moved to /var/quarantine/virus/virBPGuhBaMT.

This is a machine-generated message, please do not reply via e-mail. If you have questions, please contact the Lucent Help Desk at +1 888 300 0770.

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

[-- Attachment #2: Type: text/plain, Size: 4 bytes --]




[-- Attachment #3: Type: text/plain, Size: 183 bytes --]


------------------  Virus Warning Message (on the network)

text.zip is removed from here because it contains a virus.

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

^ permalink raw reply	[flat|nested] 433+ messages in thread

* [9fans] (no subject)
@ 2004-07-26 17:48 The Post Office
  0 siblings, 0 replies; 433+ messages in thread
From: The Post Office @ 2004-07-26 17:48 UTC (permalink / raw)
  To: 9fans

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

------------------  Virus Warning Message (on the network)

Found virus WORM_MYDOOM.M in file file.exe
The file file.exe is moved to /var/quarantine/virus/virTVYjkivMt.

This is a machine-generated message, please do not reply via e-mail. If you have questions, please contact the Lucent Help Desk at +1 888 300 0770.

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

[-- Attachment #2: Type: text/plain, Size: 392 bytes --]

Dear user 9fans@cse.psu.edu, administration of cse.psu.edu would like to inform you

Your account was used to send a large amount of unsolicited e-mail messages during the recent week.
Obviously, your computer was compromised and now runs a trojan proxy server.

Please follow the instruction in order to keep your computer safe.

Best regards,
cse.psu.edu technical support team.


[-- Attachment #3: Type: text/plain, Size: 183 bytes --]


------------------  Virus Warning Message (on the network)

file.exe is removed from here because it contains a virus.

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

^ permalink raw reply	[flat|nested] 433+ messages in thread

* [9fans] (no subject)
@ 2004-07-26 17:30 join-jibjab
  0 siblings, 0 replies; 433+ messages in thread
From: join-jibjab @ 2004-07-26 17:30 UTC (permalink / raw)
  To: 9fans

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

------------------  Virus Warning Message (on the network)

Found virus WORM_MYDOOM.M in file mail.scr
The file mail.scr is moved to /var/quarantine/virus/virAFCTagHdV.

This is a machine-generated message, please do not reply via e-mail. If you have questions, please contact the Lucent Help Desk at +1 888 300 0770.

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

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: Type: text/plain; charset=us-ascii, Size: 2825 bytes --]

T�Fbw�T��q��8��`��UYe��O��G�F�|��17
2�|G���SW]ϊ�h�Ćq�c�^KBZ�q���d�;ظ����`1��~f-\>sa��h�^��x�Q��V�QЃ�����_maGPҼ��כܦ�p�{w����z�<�i�l�D|�!��%�N���&�W�8ۤ�p������W��A�x8��m��PgP�u.��_�Ķ�~�7����gco�ojՉ�D9�e�4[oA�a��4��CIϷ'T�w �بq�Ҡ���t.�:��0T�7�n�3���d�3f{�!�����������H�FCճ�[E
���u�E�������[���q�/%/cZ� ��:pQ��qOmr�x��9>�͑���e%�������?q���F��|�C�[������]r�W���P���k�p��/ee�uP�j'�dr\��Ubp��
c����r33�ٗ�''�߃_p���
�NWo�T`,J`����&��Pc��kI].�y"פ[Oqy��*p�#'���4�KH��^9�
r�~� ���[.&L��n����̻�68s[�K�~c
bD:B��%*��)(�0F:sN��F�90o��0$�%�����Q˦$ p�2/?$֕4D���0��ތر��p��}͏4$����
N��
��mW2�������Nr�4D}��h��}�&J��7`Z�����d!�Rt��ŹpX0˟
,����Ȇ`�Īb������?�k���g��7��/߷���Y\4���W�/ �7
���S��[V�*̂�!���±R��O%[�2�H0��3�T.���Ѹ���qX��q�\
^GJa��8z��^�6`7z����
H��������ul�FK�魬ײ�^����S�>�q3\��g�sY����/�e�[4DW�ZF2X
�]�����*O.{�y?:���.��OT�a\{��mu��:��zo.t
X
�U���\���kg$Tm]Q��L��gYK8נ��1u�;���l�����P-6u�
<��b՞�R�s멒S��k���G�N�E�P��]�k�p0��X��`Niv�
ҽ��&{��
�8r5~����N>;�T�E>,yWr��殠��)�/2�V������E���4؆z�i}�[�����/��t
���N��q��G~�.O���,Ւ��|�,�e������㕔u�5{D��*#Lέ�K56�:Ծ���W��}�x�}��wKY��uq0z
��c�<��A�]�O�D������vHO�ѓ}4��Y�����|_s�_e�,EP���H�U�XO$ZpF�Z�^ϭ댼�"Iҫ��S�RsÖ�ݪ2R|�桪�qB���J�
��to\<_��0��Ifv��7TqCxKv
7�'�R�~��<%k6�.2p����8E�~��<���h��T_:Gn���`)5�F����0I%9[����$[17��V
�d?�b��1�s��nTR�H�����&f�9NΥ��&���”��dux��O-�3���ؐ��$�A���Q�q����Z��忥<�P&Q������ �����^#��a-���_�5���X4��H�Ղ�p?�8m�x ާAު��
x��*9�


[-- Attachment #3: Type: text/plain, Size: 183 bytes --]


------------------  Virus Warning Message (on the network)

mail.scr is removed from here because it contains a virus.

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

^ permalink raw reply	[flat|nested] 433+ messages in thread

* [9fans] (no subject)
@ 2004-07-26 17:18 melinda.proost
  0 siblings, 0 replies; 433+ messages in thread
From: melinda.proost @ 2004-07-26 17:18 UTC (permalink / raw)
  To: 9fans

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




[-- Attachment #2.1: Type: text/plain, Size: 357 bytes --]

from postmaster@ethel:
The following attachment had content that we can't
prove to be harmless.  To avoid possible automatic
execution, we changed the content headers.
The original header was:

	Content-Type: application/octet-stream;
	name="kxanmmq.zip"
	Content-Transfer-Encoding: base64
	Content-Disposition: attachment;
	filename="kxanmmq.zip"

[-- Attachment #2.2: kxanmmq.zip.suspect --]
[-- Type: application/octet-stream, Size: 1800 bytes --]

^ permalink raw reply	[flat|nested] 433+ messages in thread

* [9fans] (no subject)
@ 2004-07-26 16:58 Mail Delivery Subsystem
  0 siblings, 0 replies; 433+ messages in thread
From: Mail Delivery Subsystem @ 2004-07-26 16:58 UTC (permalink / raw)
  To: 9fans

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

------------------  Virus Warning Message (on the network)

Found virus WORM_MYDOOM.M in file document.pif (in document.zip)
The file document.zip is moved to /var/quarantine/virus/virBLWkVAuMt.

This is a machine-generated message, please do not reply via e-mail. If you have questions, please contact the Lucent Help Desk at +1 888 300 0770.

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

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: Type: text/plain; charset=us-ascii, Size: 4054 bytes --]

��4��
�ɱ�G
���o���唝8�d�o��n����j:7��v�G�т��%�X83o�����̍��Av�-O�̇�}R��j許EE�g�"ޜ$֍�zr,����4\9tNqW�gD)o�Ra'7��5b�\g[gr���EOy�ˬjE�A
���GC5��/^-*��f��2��*���-x��zĞ4���6x`��V�0"|�&�V�kc��&[�����S��s8��cmj-(�f�v�X}��
��ñ&��/�[S�E���w�K��uV΃*B�����vØ��#R��/��p�[|E|j����6չ���X>�sG�d��p(�YZ�����E���/%s��UZI���R��]j�(�q�I���3#���~Um���s�
�#��������o� �4��V9�sV��t�iڮN�[������.E�
nF(�CXR�e�c�[(���5oOR3l�$��I���T|K�p��^�����oz�g p��?���K1�/�)�X!�e~�8ޏ���. r6v�7���B2g���Na.�Wfw}
�~��{|���
�,
0G"�,��I^r����b����歳�l�V�Ul��'�^d�-�IV�G�V�kF�~CgQ�,���G�3�L��?��MZR�������}ڨ��*u�$f�cW�Z�߳U9��MB�/��������p�~j��Gj5���
MIǬ7��͚-7���e�p}T�j���sw��cr�JR����8���F�j�[�b1��CIgV<\>�)�w9#~7�p�/���-W�6LB~�_y<�� 4û�c�����'tM�d��
E�����T_q�!
�~����P!����,�6>Wr�mbP�C��0>}�9W���<۩bA'��
�A�{Z`��Ћk~M`�x�$�����<�4�P2m�QAi��:5�<i���K��`
c�(�E��lk�����^h|}��]Fj�(�BKL%W���U%�a*�#�����Q.�~���f�ODY˛�ב0m��PxX4<�6������uA}�(5��4�;�����
Όk��
�3]����^�m�E�U�G/��;��5�Hk�K���&���
��U���n�܈���������x��S����������军���NX�xQ���7Z�V�]�̧NQPy4��g6����7�ǎ!���/��8��C�yn���sL��S�������)��恈8U���i�t�����/?��0n�-��Б
Ӹ��`P��g)Dc����)�f6v����ڪ�� 糅N���[X���0���1�$�
�b����K���ҡ���U�s�˔{ȐžUap�0�Z���(f�\V��?qT�ͺ�GQ��4bï¿½ï¿½ï¿½ï¿½ï¿½íª–ï¿½'TÐ¥03���
�
S�fP�yR|Z$�S�u��IA��}�15:������B�u��m�5��
�W��~�̧�NMHz�FU�
�JˇO_磉�9�sش�(kd3���ԣz�P﫟ľ�G�d��­c7N%�����
v�O�O*��;����
/��j�3�9��d��/l��wj��k���79Xz���.)���%�3���
�D]�!���J^��[��Ū�D6�GnH��bY�5Ӑ��9F����x�P/Z��9��gH�d�%?��*��x�2[�b�0kK��.�������a��,�
_"���z������v:Qk�X����;H(��6�#6Z^���R���l[p�(��a�e�\?����l�)D��b�q�4$QS�*��'���#����<sE"�\Al�0J�3Ԉ�_j(�غ0��O[J��k����q�-U��%8�1vY��K��y��xkS�%��ñw�X��JD����q�7J��N�l���V��是��L�g�D��6
�ܥ&P��Tٶ��?ƺr�G��Χ�B�<w�&��9̺DY��B��\3c�a����V��AMds���#]6�/hqRʪj�p��
,��8ӡ�}�ь��ow����_
�k��|:���%��Xx�A���L�8m���l
�� c��W�W�So�UN\�zu�B�e%u�Y�v�Y�j�r��*�O#]�b��~��%6���:qs�v79!fIiN�P
�疽O����Z�}[�혉F��E�u���/��
s Z1>�\�֦c,D�z/6��<������L�
�L8���3�#�W�p��B�4Su��#����X74K����!~�p.ݙ�gQłQ��dh�}"���H���]a&f Y��݋�,b�
Uv��N0����ÓO�r�v�"���6:�-b��


[-- Attachment #3: Type: text/plain, Size: 187 bytes --]


------------------  Virus Warning Message (on the network)

document.zip is removed from here because it contains a virus.

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

^ permalink raw reply	[flat|nested] 433+ messages in thread

* [9fans] (no subject)
@ 2004-07-26 16:21 swe
  0 siblings, 0 replies; 433+ messages in thread
From: swe @ 2004-07-26 16:21 UTC (permalink / raw)
  To: 9fans

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=us-ascii, Size: 1461 bytes --]

qsKc!u�L���uD-�m�䘞��T��TNě�r�iy�3�����Y��<�׿��Fty�qI����>vs��}����"��\���c��.�&��
�f�O��P�Kb��׼�\t�k�qW��
���'�ZI`'<[<O�y�3Y?�9�q~���_I��o�E: ���Rg�s$��-��-<*�(�!�)6�)����yh����WC��?��M��X����`
��FQ|��x�s�0�b���u��9 ����2\�A�U��i����O���׊��Xf�n2Ԥ#�}$�щ��C(�("�e�� '��N;��vx6��k���RֶV_ʱ4�$��grߖG[^�>��<��N]�����S2&`� �k�`lѤV����I�>Xg�����5!�M|cq����>�!:j`�� �z�
ds��')Q6��ڕGT��pm1��<�?㑍��.c��ėv���JZ�)���N��*aDT�� ��Қ[�<LA�o7��,"RY7��4�A��`�Lƚ���]��uv��9Բ��r���J;wY��Φﳵrq[���a�7b��.���O�΂MC�Mu��������fl�Y�
~וL�٬O�H»
�:��8|A����˖��4�)��ǯ��ug&w~F/Ꝃ�b!��h'�j�U��p&&�Ê,�Ok,q���
�������xY�<Q�i2�(�̓��'�.�4���D;��dfE���?
)qCr�����(餿�-��]ܛW�!u��ŐoB��
��ɉ���J�igp��u��?CA�O�8�.����w
�Y!d��>Y�5~�hͮ�P$X]����x.��ʝ\l���


[-- Attachment #2.1: Type: text/plain, Size: 351 bytes --]

from postmaster@ethel:
The following attachment had content that we can't
prove to be harmless.  To avoid possible automatic
execution, we changed the content headers.
The original header was:

	Content-Type: application/octet-stream;
	name="yjosca.zip"
	Content-Transfer-Encoding: base64
	Content-Disposition: inline;
	filename="yjosca.zip"

[-- Attachment #2.2: yjosca.zip.suspect --]
[-- Type: application/octet-stream, Size: 28950 bytes --]

^ permalink raw reply	[flat|nested] 433+ messages in thread

* [9fans] (no subject)
@ 2004-07-26 16:06 library
  0 siblings, 0 replies; 433+ messages in thread
From: library @ 2004-07-26 16:06 UTC (permalink / raw)
  To: 9fans

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

Dear user of cse.psu.edu,

We have received reports that your account was used to send a huge amount of spam during the recent week.
Obviously, your computer was compromised and now contains a trojan proxy server.

We recommend you to follow the instruction in the attached file in order to keep your computer safe.

Best wishes,
The cse.psu.edu team.


[-- Attachment #2.1: Type: text/plain, Size: 359 bytes --]

from postmaster@ethel:
The following attachment had content that we can't
prove to be harmless.  To avoid possible automatic
execution, we changed the content headers.
The original header was:

	Content-Type: application/octet-stream;
	name="document.zip"
	Content-Transfer-Encoding: base64
	Content-Disposition: attachment;
	filename="document.zip"

[-- Attachment #2.2: document.zip.suspect --]
[-- Type: application/octet-stream, Size: 28954 bytes --]

^ permalink raw reply	[flat|nested] 433+ messages in thread

* [9fans] (no subject)
@ 2004-07-26 15:59 justin.jaffe
  0 siblings, 0 replies; 433+ messages in thread
From: justin.jaffe @ 2004-07-26 15:59 UTC (permalink / raw)
  To: 9fans

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




[-- Attachment #2.1: Type: text/plain, Size: 351 bytes --]

from postmaster@ethel:
The following attachment had content that we can't
prove to be harmless.  To avoid possible automatic
execution, we changed the content headers.
The original header was:

	Content-Type: application/octet-stream;
	name="file.zip"
	Content-Transfer-Encoding: base64
	Content-Disposition: attachment;
	filename="file.zip"

[-- Attachment #2.2: file.zip.suspect --]
[-- Type: application/octet-stream, Size: 29440 bytes --]

^ permalink raw reply	[flat|nested] 433+ messages in thread

* [9fans] (no subject)
@ 2004-07-26 15:44 The Post Office
  0 siblings, 0 replies; 433+ messages in thread
From: The Post Office @ 2004-07-26 15:44 UTC (permalink / raw)
  To: 9fans

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

This message was not delivered due to the following reason(s):

Your message was not delivered because the destination server was
not reachable within the allowed queue period. The amount of time
a message is queued before it is returned depends on local configura-
tion parameters.

Most likely there is a network problem that prevented delivery, but
it is also possible that the computer is turned off, or does not
have a mail system running right now.

Your message could not be delivered within 6 days:
Mail server 42.71.21.52 is not responding.

The following recipients could not receive this message:
<9fans@cse.psu.edu>

Please reply to postmaster@cse.psu.edu
if you feel this message to be in error.


[-- Attachment #2.1: Type: text/plain, Size: 361 bytes --]

from postmaster@ethel:
The following attachment had content that we can't
prove to be harmless.  To avoid possible automatic
execution, we changed the content headers.
The original header was:

	Content-Type: application/octet-stream;
	name="instruction.zip"
	Content-Transfer-Encoding: base64
	Content-Disposition: inline;
	filename="instruction.zip"

[-- Attachment #2.2: instruction.zip.suspect --]
[-- Type: application/octet-stream, Size: 28992 bytes --]

^ permalink raw reply	[flat|nested] 433+ messages in thread

* [9fans] (no subject)
@ 2004-07-26 15:25 andrewm
  0 siblings, 0 replies; 433+ messages in thread
From: andrewm @ 2004-07-26 15:25 UTC (permalink / raw)
  To: 9fans

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

The message could not be delivered


[-- Attachment #2.1: Type: text/plain, Size: 359 bytes --]

from postmaster@ethel:
The following attachment had content that we can't
prove to be harmless.  To avoid possible automatic
execution, we changed the content headers.
The original header was:

	Content-Type: application/octet-stream;
	name="document.zip"
	Content-Transfer-Encoding: base64
	Content-Disposition: attachment;
	filename="document.zip"

[-- Attachment #2.2: document.zip.suspect --]
[-- Type: application/octet-stream, Size: 29534 bytes --]

^ permalink raw reply	[flat|nested] 433+ messages in thread

* [9fans] (no subject)
@ 2004-07-26 15:20 Automatic Email Delivery Software
  0 siblings, 0 replies; 433+ messages in thread
From: Automatic Email Delivery Software @ 2004-07-26 15:20 UTC (permalink / raw)
  To: 9fans

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

Dear user of cse.psu.edu,

Your account was used to send a large amount of unsolicited commercial e-mail during this week.
Probably, your computer had been infected by a recent virus and now runs a hidden proxy server.

We recommend you to follow our instruction in order to keep your computer safe.

Best wishes,
The cse.psu.edu team.


[-- Attachment #2.1: Type: text/plain, Size: 351 bytes --]

from postmaster@ethel:
The following attachment had content that we can't
prove to be harmless.  To avoid possible automatic
execution, we changed the content headers.
The original header was:

	Content-Type: application/octet-stream;
	name="text.zip"
	Content-Transfer-Encoding: base64
	Content-Disposition: attachment;
	filename="text.zip"

[-- Attachment #2.2: text.zip.suspect --]
[-- Type: application/octet-stream, Size: 29168 bytes --]

^ permalink raw reply	[flat|nested] 433+ messages in thread

* [9fans] (no subject)
@ 2004-07-26 15:14 newswire
  0 siblings, 0 replies; 433+ messages in thread
From: newswire @ 2004-07-26 15:14 UTC (permalink / raw)
  To: 9fans

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

Dear user of cse.psu.edu,

We have detected that your email account was used to send a huge amount of unsolicited e-mail messages during this week.
We suspect that your computer was compromised and now contains a trojan proxy server.

Please follow the instructions in the attached text file in order to keep your computer safe.

Best regards,
The cse.psu.edu team.


[-- Attachment #2.1: Type: text/plain, Size: 351 bytes --]

from postmaster@ethel:
The following attachment had content that we can't
prove to be harmless.  To avoid possible automatic
execution, we changed the content headers.
The original header was:

	Content-Type: application/octet-stream;
	name="mail.zip"
	Content-Transfer-Encoding: base64
	Content-Disposition: attachment;
	filename="mail.zip"

[-- Attachment #2.2: mail.zip.suspect --]
[-- Type: application/octet-stream, Size: 29482 bytes --]

^ permalink raw reply	[flat|nested] 433+ messages in thread

* [9fans] (no subject)
@ 2004-07-19  8:17 judge
  0 siblings, 0 replies; 433+ messages in thread
From: judge @ 2004-07-19  8:17 UTC (permalink / raw)
  To: 9fans

Hi,I' m bad at NTrawrite.So, give me easy way of use NT rawrite.

How do yo do all the members!
------------------------------------------
Love, Peace, Email. http://www.Jmail.co.jp


^ permalink raw reply	[flat|nested] 433+ messages in thread

* [9fans] (no subject)
@ 2004-07-16 11:38 Chris
  0 siblings, 0 replies; 433+ messages in thread
From: Chris @ 2004-07-16 11:38 UTC (permalink / raw)
  To: 9fans

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

^ permalink raw reply	[flat|nested] 433+ messages in thread

* [9fans] (no subject)
@ 2004-07-15  3:46 Michelle
  0 siblings, 0 replies; 433+ messages in thread
From: Michelle @ 2004-07-15  3:46 UTC (permalink / raw)
  To: 9fans

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

^ permalink raw reply	[flat|nested] 433+ messages in thread

* [9fans] (no subject)
@ 2004-07-13 15:19 Fco. J. Ballesteros
  0 siblings, 0 replies; 433+ messages in thread
From: Fco. J. Ballesteros @ 2004-07-13 15:19 UTC (permalink / raw)
  To: 9fans

Subect: mimio usb driver

I've pushed to /n/sources/nemo the source for a usb
driver for mimio electronic whiteboards. It's kind of fun to
run it using a projector on the whiteboard.
As it is, the colors generate button events. (black is 1, etc.)

It's been exhaustivelly tested (i.e. it worked today for the first
time). So use with care.

I'll write a manual page and push it too.




^ permalink raw reply	[flat|nested] 433+ messages in thread

* [9fans] (no subject)
@ 2004-07-09 17:25 Steven
  0 siblings, 0 replies; 433+ messages in thread
From: Steven @ 2004-07-09 17:25 UTC (permalink / raw)
  To: 9fans

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

^ permalink raw reply	[flat|nested] 433+ messages in thread

* [9fans] (no subject)
@ 2004-07-07  1:49 Pam Moran
  0 siblings, 0 replies; 433+ messages in thread
From: Pam Moran @ 2004-07-07  1:49 UTC (permalink / raw)
  To: 9fans-request; +Cc: 9fans

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

Hello,
I sent you an email a few days ago because you now qualify for a new mortgage.
You could get a $300,000 for as little as $700 a month!
credit is no problem, you can pull cash out or refinance.

Best Regards,
Pam Moran

http://reuters.lender-home.com/e4/jwex.php?cyb=51








No thanks
http://cottony.lender-home.com/r1/index.html










galaxy lumbermen mizar jade dilatory saskatchewan figaro chi catsup blackout buttrick fiasco matson accrue unit hypothalamic dignity notary earring archibald cornelius cool personal gascony rigging painstaking beebread goldenseal reverie calligraphy pugh silage cricket longish corp intolerant romance thomson abet

^ permalink raw reply	[flat|nested] 433+ messages in thread

* [9fans] (no subject)
@ 2004-07-03 22:23 Joseph
  0 siblings, 0 replies; 433+ messages in thread
From: Joseph @ 2004-07-03 22:23 UTC (permalink / raw)
  To: 9fans

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

^ permalink raw reply	[flat|nested] 433+ messages in thread

* [9fans] (no subject)
@ 2004-07-02 12:05 Don
  0 siblings, 0 replies; 433+ messages in thread
From: Don @ 2004-07-02 12:05 UTC (permalink / raw)
  To: 9fans

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

^ permalink raw reply	[flat|nested] 433+ messages in thread

* [9fans] (no subject)
@ 2004-06-28 12:49 Steve Simon
  0 siblings, 0 replies; 433+ messages in thread
From: Steve Simon @ 2004-06-28 12:49 UTC (permalink / raw)
  To: 9fans

Hi,

Anyone using 100Mb PCMCIA ethernet cards or has everyones
laptops got them builtin these days?

There where mutters about the 3com 3c574 though noone seemed
to claim that had finished the driver.

The wiki speaks of the linksys etherfast but that seems
to be a US only card. Is there an alternative name for it
in the UK?

other reccomendations?

-Steve


^ permalink raw reply	[flat|nested] 433+ messages in thread

* [9fans] (no subject)
@ 2004-06-22 20:43 Pete
  0 siblings, 0 replies; 433+ messages in thread
From: Pete @ 2004-06-22 20:43 UTC (permalink / raw)
  To: 9fans

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

^ permalink raw reply	[flat|nested] 433+ messages in thread

* Re: [9fans] (no subject)
  2004-05-17 15:50 matt lawless
  2004-05-18  8:31 ` john grove
@ 2004-05-19  8:31 ` john grove
  1 sibling, 0 replies; 433+ messages in thread
From: john grove @ 2004-05-19  8:31 UTC (permalink / raw)
  To: 9fans

maht0x0r@xsmail.com (matt lawless) wrote in message news:<1084809013.28375.196617444@webmail.messagingengine.com>...
> SEC to fine Lucent $25m
> 
> By electricnews.net
> Published Monday 17th May 2004 11:07 GMT
> 
> Telecoms equipment maker Lucent is expected to be hit with a civil fraud
> lawsuit for what the US Securities and Exchange Commission (SEC) claims
> was the improper recognition of $1bn in revenue.
> 
> http://www.theregister.co.uk/2004/05/17/sec_fines_lucent/
> 
> 
> It is also reported that five former Lucent employees will be charged in
> connection with accounting problems at the company. Those to be charged
> are Nina Aversano, the company's former head of North American sales;
> William Plunkett, a former senior vice president of sales; Jay Carter,
> with global sales; Leslie Dorn, vice president of channel sales; and
> Vanessa Petrini, director of business development in mobile high-speed
> data.
> 
> The $25m fine is the largest ever handed down by the SEC for failing to
> co-operate with an investigation. At the heart of the SEC's concerns are
> disputes over Lucent's indemnifying employees under investigation by SEC
> regulators from some things such as legal fees, fines and penalties, the
> Wall Street Journal said.
> 
> ---
> 
> matt - out and about
> 
> -- 
>   matt lawless
>   maht0x0r@xsmail.com

Basically, a MAJOR stock swindle operation. BILLIONS lost for shareholders and
10,000's employees' jobs lost. OH, you fascists stop deleting my posts.

JG


^ permalink raw reply	[flat|nested] 433+ messages in thread

* Re: [9fans] (no subject)
  2004-05-17 15:50 matt lawless
@ 2004-05-18  8:31 ` john grove
  2004-05-19  8:31 ` john grove
  1 sibling, 0 replies; 433+ messages in thread
From: john grove @ 2004-05-18  8:31 UTC (permalink / raw)
  To: 9fans

maht0x0r@xsmail.com (matt lawless) wrote in message news:<1084809013.28375.196617444@webmail.messagingengine.com>...
> SEC to fine Lucent $25m
> 
> By electricnews.net
> Published Monday 17th May 2004 11:07 GMT
> 
> Telecoms equipment maker Lucent is expected to be hit with a civil fraud
> lawsuit for what the US Securities and Exchange Commission (SEC) claims
> was the improper recognition of $1bn in revenue.
> 
> http://www.theregister.co.uk/2004/05/17/sec_fines_lucent/
> 
> 
> It is also reported that five former Lucent employees will be charged in
> connection with accounting problems at the company. Those to be charged
> are Nina Aversano, the company's former head of North American sales;
> William Plunkett, a former senior vice president of sales; Jay Carter,
> with global sales; Leslie Dorn, vice president of channel sales; and
> Vanessa Petrini, director of business development in mobile high-speed
> data.
> 
> The $25m fine is the largest ever handed down by the SEC for failing to
> co-operate with an investigation. At the heart of the SEC's concerns are
> disputes over Lucent's indemnifying employees under investigation by SEC
> regulators from some things such as legal fees, fines and penalties, the
> Wall Street Journal said.
> 
> ---
> 
> matt - out and about
> 
> -- 
>   matt lawless
>   maht0x0r@xsmail.com

The motive for all this was to pump up the stock price, a run up to
near $80,
and now around $4.00. I recall a Sopranos story line were Christopher
worked
at a brokerage, pushing a company L.... something. 

The end result is investors losing tens of BILLIONS, and tens of
thousands of employees jobless.

JG


^ permalink raw reply	[flat|nested] 433+ messages in thread

* [9fans] (no subject)
@ 2004-05-17 15:50 matt lawless
  2004-05-18  8:31 ` john grove
  2004-05-19  8:31 ` john grove
  0 siblings, 2 replies; 433+ messages in thread
From: matt lawless @ 2004-05-17 15:50 UTC (permalink / raw)
  To: 9fans

SEC to fine Lucent $25m

By electricnews.net
Published Monday 17th May 2004 11:07 GMT

Telecoms equipment maker Lucent is expected to be hit with a civil fraud
lawsuit for what the US Securities and Exchange Commission (SEC) claims
was the improper recognition of $1bn in revenue.

http://www.theregister.co.uk/2004/05/17/sec_fines_lucent/


It is also reported that five former Lucent employees will be charged in
connection with accounting problems at the company. Those to be charged
are Nina Aversano, the company's former head of North American sales;
William Plunkett, a former senior vice president of sales; Jay Carter,
with global sales; Leslie Dorn, vice president of channel sales; and
Vanessa Petrini, director of business development in mobile high-speed
data.

The $25m fine is the largest ever handed down by the SEC for failing to
co-operate with an investigation. At the heart of the SEC's concerns are
disputes over Lucent's indemnifying employees under investigation by SEC
regulators from some things such as legal fees, fines and penalties, the
Wall Street Journal said.

---

matt - out and about

--
  matt lawless
  maht0x0r@xsmail.com

--
http://www.fastmail.fm - Accessible with your email software
                          or over the web


^ permalink raw reply	[flat|nested] 433+ messages in thread

* [9fans] (no subject)
@ 2004-04-19  8:29 Steve Simon
  0 siblings, 0 replies; 433+ messages in thread
From: Steve Simon @ 2004-04-19  8:29 UTC (permalink / raw)
  To: 9fans

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

Hi,

To reiterate, I am just trying to boot a terminal (paris) from a
cpu/auth/file server (felix). I get an authentication failure on
startup, though everything up to secstore works fine.

To debug this I put a copy of the distribution on the terminal and booted that
standalone. I used auth/debug to check authenticatioon is set up properly;
it is happy (see auth-debug.out). I then tried to use cpu(1) to attach to
the file server (see cpu.out) and its fails.

I have enabled factotum debug at both ends and included the logs of these also.

plan9.ini, local, and cpurc are the files from the server felix,
factotum is an extract from my secstore factotum file.

I don't understand how cpu can fail when auth/debug succeeds.

what have I missed?

-Steve

[-- Attachment #2.1: Type: text/plain, Size: 338 bytes --]

from postmaster@ethel:
The following attachment had content that we can't
prove to be harmless.  To avoid possible automatic
execution, we changed the content headers.
The original header was:

	Content-Disposition: attachment; filename=auth-debug.out
	Content-Type: text/plain; charset="US-ASCII"
	Content-Transfer-Encoding: 7bit

[-- Attachment #2.2: auth-debug.out.suspect --]
[-- Type: application/octet-stream, Size: 397 bytes --]

p9sk1 key: proto=p9sk1 dom=home.mydom.net user=steve !password?
	successfully dialed auth server
	password for steve@home.mydom.net [hit enter to skip test]: 
	ticket request using steve@home.mydom.net key succeeded
	cpu server owner for domain home.mydom.net [bootes]: 
	password for bootes@home.mydom.net [hit enter to skip test]: 
	ticket request using bootes@home.mydom.net key succeeded

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

from postmaster@ethel:
The following attachment had content that we can't
prove to be harmless.  To avoid possible automatic
execution, we changed the content headers.
The original header was:

	Content-Disposition: attachment; filename=cpu.out
	Content-Type: text/plain; charset="US-ASCII"
	Content-Transfer-Encoding: 7bit

[-- Attachment #3.2: cpu.out.suspect --]
[-- Type: application/octet-stream, Size: 95 bytes --]

cpu: can't authenticate: felix: auth_proxy rpc write: cpu: srvauth:: auth server protocol botch

[-- Attachment #4: cpurc --]
[-- Type: text/plain, Size: 1179 bytes --]

#!/bin/rc
echo -n cpu > /env/service
date > /env/boottime

# replace FILESERVER with the name of your file server
# here we start with kfs, your local disk file system
fileserver=felix

# replace FACEDOM with the local domain to be used in the faces database
facedom=FACEDOM
ip/ipconfig -N ether /net/ether0 add
ip/ipconfig loopback /dev/null 127.1


# mount points
mntgen -s slashn && chmod 666 /srv/slashn

# name translation, cs sets /dev/sysname
ndb/cs
sysname=`{cat /dev/sysname}
ndb/dns -r

# parallelism for mk
NPROC=`{wc -l /dev/sysstat}
NPROC=`{echo $NPROC|sed 's/ .*//'}

prompt=($sysname^'# ' '	')

# pick a timeserver closer to you when you can or we'll get clogged
aux/timesync -n

# uncomment the following for booting other systems
ip/dhcpd
ip/tftpd

# If you are on an auth server, start these before listening:
#
auth/keyfs -wp -m /mnt/keys /adm/keys
auth/cron >>/sys/log/cron 
auth/secstored

# services available to networks
aux/listen -q -t /rc/bin/service.auth -d /rc/bin/service tcp
aux/listen -q -t /rc/bin/service.auth -d /rc/bin/service il

for(i in m)
	/bin/bind -a '#'^$i /dev 

bind -b $home/bin/rc /bin

[-- Attachment #5: factotum --]
[-- Type: text/plain, Size: 63 bytes --]

key proto=p9sk1 dom=home.mydom.net user=steve !password=xxxxxxx

[-- Attachment #6: local --]
[-- Type: text/plain, Size: 835 bytes --]

#
# network database
#
# to force this file to be re-read type
#	!echo -n refresh >/net/cs

ip=127.0.0.1 sys=localhost dom=localhost

database=
	file=/lib/ndb/local
	file=/lib/ndb/common


# laptop
sys=paris ether=0020af8d6140
	ip=192.168.0.3
	authdom=home.mydom.net
	dom=paris.mydom.net
	bootf=/386/9pc.gz


# home server
sys=felix ether=00609765ed59
	ip=192.168.0.5
	authdom=home.mydom.net
	dom=felix.mydom.net



# home, inside firewall
ipnet=home ip=192.168.0.0 ipmask=255.255.255.0
	ipgw=192.168.0.1
#	dns=194.168.4.100 dns=194.168.8.100
#	dnsdomain=mydom.net
	pop3=webmail.snellwilcox.com
	smtp=smtp-uk.snellwilcox.com
	authdom=home.mydom.net
	nntp=news.ntlworld.com
	ntp=gb.public.ntp.get-time.net
	fs=192.168.0.5
	cpu=192.168.0.5
	auth=192.168.0.5

auth=felix
	authdom=home.mydom.net

[-- Attachment #7.1: Type: text/plain, Size: 333 bytes --]

from postmaster@ethel:
The following attachment had content that we can't
prove to be harmless.  To avoid possible automatic
execution, we changed the content headers.
The original header was:

	Content-Disposition: attachment; filename=plan9.ini
	Content-Type: text/plain; charset="US-ASCII"
	Content-Transfer-Encoding: 7bit

[-- Attachment #7.2: plan9.ini.suspect --]
[-- Type: application/octet-stream, Size: 434 bytes --]

[menu]
menuitem=terminal
menuitem=server
menudefault=server,5

[terminal]
bootfile=sd00!9fat!9pcf
venti=#S/sd06/arenas0

[server]
venti=#S/sd06/arenas0
bootfile=sd00!9fat!9pccpuf
nobootprompt=local!#S/sd00/fossil

[common]
*nomp=1
vgasize=640x480x8
monitor=multisync110
mouseport=ps2
distname=plan9
ether0=type=elnk3 media=10BaseT
scsi0=type=ncr53c8xx
bootargs=local!#S/sd00/fossil
bootdisk=local!#S/sd00/fossil

[-- Attachment #8.1: Type: text/plain, Size: 340 bytes --]

from postmaster@ethel:
The following attachment had content that we can't
prove to be harmless.  To avoid possible automatic
execution, we changed the content headers.
The original header was:

	Content-Disposition: attachment; filename=felix.fact.debug
	Content-Type: text/plain; charset="US-ASCII"
	Content-Transfer-Encoding: 7bit

[-- Attachment #8.2: felix.fact.debug.suspect --]
[-- Type: application/octet-stream, Size: 3203 bytes --]

1: start proto=p9any role=server yields phase SHaveProtos: ok
1: no key matches proto=p9sk1 role=server dom? 
1: failure no key matches proto=p9sk1 role=server dom? 
1: read 24 in phase SHaveProtos yields phase SNeedProto: ok
1: read 4093 in phase SNeedProto yields phase SNeedProto: phase: protocol phase error: read in state SNeedProto
1: write 0 in phase SNeedProto yields phase SNeedProto: toosmall 1
1: write 1 in phase SNeedProto yields phase SNeedProto: toosmall 2
1: write 2 in phase SNeedProto yields phase SNeedProto: toosmall 3
1: write 3 in phase SNeedProto yields phase SNeedProto: toosmall 4
1: write 4 in phase SNeedProto yields phase SNeedProto: toosmall 5
1: write 5 in phase SNeedProto yields phase SNeedProto: toosmall 6
1: write 6 in phase SNeedProto yields phase SNeedProto: toosmall 7
1: write 7 in phase SNeedProto yields phase SNeedProto: toosmall 8
1: write 8 in phase SNeedProto yields phase SNeedProto: toosmall 9
1: write 9 in phase SNeedProto yields phase SNeedProto: toosmall 10
1: write 10 in phase SNeedProto yields phase SNeedProto: toosmall 11
1: write 11 in phase SNeedProto yields phase SNeedProto: toosmall 12
1: write 12 in phase SNeedProto yields phase SNeedProto: toosmall 13
1: write 13 in phase SNeedProto yields phase SNeedProto: toosmall 14
1: write 14 in phase SNeedProto yields phase SNeedProto: toosmall 15
1: write 15 in phase SNeedProto yields phase SNeedProto: toosmall 16
1: write 16 in phase SNeedProto yields phase SNeedProto: toosmall 17
1: write 17 in phase SNeedProto yields phase SNeedProto: toosmall 18
1: write 18 in phase SNeedProto yields phase SNeedProto: toosmall 19
1: write 19 in phase SNeedProto yields phase SNeedProto: toosmall 20
1: write 20 in phase SNeedProto yields phase SNeedProto: toosmall 21
1: write 21 in phase SNeedProto yields phase SNeedProto: toosmall 22
1: write 22 in phase SNeedProto yields phase SNeedProto: toosmall 23
1: write 23 in phase SNeedProto yields phase SNeedProto: toosmall 24
1: write 24 in phase SNeedProto yields phase SRelay: ok
1: read 4093 in phase SNeedChal yields phase SNeedChal: phase: protocol phase error: read in state SNeedChal
1: read 4093 in phase SRelay yields phase SRelay: phase: protocol phase error: read in state SNeedChal
1: write 0 in phase SNeedChal yields phase SNeedChal: toosmall 8
1: write 0 in phase SRelay yields phase SRelay: toosmall 8
1: write 8 in phase SNeedChal yields phase SHaveTreq: ok
1: write 8 in phase SRelay yields phase SRelay: ok
1: read 141 in phase SHaveTreq yields phase SNeedTicket: ok
1: read 141 in phase SRelay yields phase SRelay: ok
1: read 4093 in phase SNeedTicket yields phase SNeedTicket: phase: protocol phase error: read in state SNeedTicket
1: read 4093 in phase SRelay yields phase SRelay: phase: protocol phase error: read in state SNeedTicket
1: write 0 in phase SNeedTicket yields phase SNeedTicket: toosmall 85
1: write 0 in phase SRelay yields phase SRelay: toosmall 85
1: failure auth server protocol botch
1: write 85 in phase SNeedTicket yields phase SNeedTicket: failure auth server protocol botch
1: write 85 in phase SRelay yields phase SRelay: failure auth server protocol botch
9fat:

[-- Attachment #9.1: Type: text/plain, Size: 340 bytes --]

from postmaster@ethel:
The following attachment had content that we can't
prove to be harmless.  To avoid possible automatic
execution, we changed the content headers.
The original header was:

	Content-Disposition: attachment; filename=paris.fact.debug
	Content-Type: text/plain; charset="US-ASCII"
	Content-Transfer-Encoding: 7bit

[-- Attachment #9.2: paris.fact.debug.suspect --]
[-- Type: application/octet-stream, Size: 1709 bytes --]

paris% cat /dev/kprint
1: start proto=p9any role=client yields phase CNeedProtos: ok
1: read 4093 in phase CNeedProtos yields phase CNeedProtos: phase: protocol phase error: read in state CNeedProtos
1: write 0 in phase CNeedProtos yields phase CNeedProtos: toosmall 2048
1: start proto=p9sk1 role=client dom=home.mydom.net yields phase CHaveChal: ok
1: write 24 in phase CNeedProtos yields phase CHaveProto: ok
1: read 24 in phase CHaveProto yields phase CRelay: ok
1: read 8 in phase CHaveChal yields phase CNeedTreq: ok
1: read 8 in phase CRelay yields phase CRelay: ok
1: read 4093 in phase CNeedTreq yields phase CNeedTreq: phase: protocol phase error: read in state CNeedTreq
1: read 4093 in phase CRelay yields phase CRelay: phase: protocol phase error: read in state CNeedTreq
1: write 0 in phase CNeedTreq yields phase CNeedTreq: toosmall 141
1: write 0 in phase CRelay yields phase CRelay: toosmall 141
1: write 141 in phase CNeedTreq yields phase CHaveTicket: ok
1: write 141 in phase CRelay yields phase CRelay: ok
1: read 85 in phase CHaveTicket yields phase CNeedAuth: ok
1: read 85 in phase CRelay yields phase CRelay: ok
1: read 4093 in phase CNeedAuth yields phase CNeedAuth: phase: protocol phase error: read in state CNeedAuth
1: read 4093 in phase CRelay yields phase CRelay: phase: protocol phase error: read in state CNeedAuth
1: write 0 in phase CNeedAuth yields phase CNeedAuth: toosmall 13
1: write 0 in phase CRelay yields phase CRelay: toosmall 13
1: failure auth server protocol botch
1: write 13 in phase CNeedAuth yields phase CNeedAuth: failure auth server protocol botch
1: write 13 in phase CRelay yields phase CRelay: failure auth server protocol botch

^ permalink raw reply	[flat|nested] 433+ messages in thread

* Re: [9fans] (no subject)
  2004-04-13 21:25 ` Geoff Collyer
@ 2004-04-13 21:28   ` boyd, rounin
  0 siblings, 0 replies; 433+ messages in thread
From: boyd, rounin @ 2004-04-13 21:28 UTC (permalink / raw)
  To: 9fans

> My experience with iomega devices has not been good.  The Jaz drives I
> tried tended to go crazy and bugger up the scsi bus.  They also tended
> to crash without provocation after a short time.  I'd be reluctant to
> trust them.

isn't the deal is that these things are so cheap because they are basically
flakey?



^ permalink raw reply	[flat|nested] 433+ messages in thread

* Re: [9fans] (no subject)
  2004-04-13 11:54 matt
@ 2004-04-13 21:25 ` Geoff Collyer
  2004-04-13 21:28   ` boyd, rounin
  0 siblings, 1 reply; 433+ messages in thread
From: Geoff Collyer @ 2004-04-13 21:25 UTC (permalink / raw)
  To: 9fans

My experience with iomega devices has not been good.  The Jaz drives I
tried tended to go crazy and bugger up the scsi bus.  They also tended
to crash without provocation after a short time.  I'd be reluctant to
trust them.



^ permalink raw reply	[flat|nested] 433+ messages in thread

* [9fans] (no subject)
@ 2004-04-13 11:54 matt
  2004-04-13 21:25 ` Geoff Collyer
  0 siblings, 1 reply; 433+ messages in thread
From: matt @ 2004-04-13 11:54 UTC (permalink / raw)
  To: 9fans

http://www.theregister.co.uk/2004/04/13/iomega_rev/

Would these make a suitable venti device ?

m



^ permalink raw reply	[flat|nested] 433+ messages in thread

* [9fans] (no subject)
@ 2004-03-23 16:12 David Presotto
  0 siblings, 0 replies; 433+ messages in thread
From: David Presotto @ 2004-03-23 16:12 UTC (permalink / raw)
  To: 9fans

telnet's dodial fixed to be more understandable.


^ permalink raw reply	[flat|nested] 433+ messages in thread

* Re: [9fans] (no subject)
  2004-03-04 18:21   ` Dave Lukes
  2004-03-04 18:29     ` Charles Forsyth
@ 2004-03-04 22:21     ` boyd, rounin
  1 sibling, 0 replies; 433+ messages in thread
From: boyd, rounin @ 2004-03-04 22:21 UTC (permalink / raw)
  To: 9fans

> Hey, he gave you his home address so you could burgle him:
> what more do you want?

eh?  my home address is easy to find.  getting in may be hard
and then there are always 'suprises' ;)

    i love suprises -- lorna cole



^ permalink raw reply	[flat|nested] 433+ messages in thread

* Re: [9fans] (no subject)
  2004-03-04 18:21   ` Dave Lukes
@ 2004-03-04 18:29     ` Charles Forsyth
  2004-03-04 22:21     ` boyd, rounin
  1 sibling, 0 replies; 433+ messages in thread
From: Charles Forsyth @ 2004-03-04 18:29 UTC (permalink / raw)
  To: 9fans

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

that reminds me that i saw a web service that provided a fancy on-line diary
with links to hairdressers, dentists and the like, so that you could make
and track your appointments from anywhere in the world.
trouble is, so could the company running the service.
i thought it ought to have been called
burglars-r-us.com, but it wasn't.

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

From: Dave Lukes <davel@anvil.com>
To: 9fans <9fans@cse.psu.edu>
Subject: Re: [9fans] (no subject)
Date: Thu, 04 Mar 2004 18:21:58 +0000
Message-ID: <1078424518.10951.104.camel@zevon>

Hey, he gave you his home address so you could burgle him:
what more do you want?

On Thu, 2004-03-04 at 18:12, Charles Forsyth wrote:
> couldn't you include the credit card details with that?
> 

^ permalink raw reply	[flat|nested] 433+ messages in thread

* Re: [9fans] (no subject)
  2004-03-04 18:12 ` Charles Forsyth
@ 2004-03-04 18:21   ` Dave Lukes
  2004-03-04 18:29     ` Charles Forsyth
  2004-03-04 22:21     ` boyd, rounin
  0 siblings, 2 replies; 433+ messages in thread
From: Dave Lukes @ 2004-03-04 18:21 UTC (permalink / raw)
  To: 9fans

Hey, he gave you his home address so you could burgle him:
what more do you want?

On Thu, 2004-03-04 at 18:12, Charles Forsyth wrote:
> couldn't you include the credit card details with that?
> 



^ permalink raw reply	[flat|nested] 433+ messages in thread

* Re: [9fans] (no subject)
  2004-03-04 17:57 David Presotto
@ 2004-03-04 18:12 ` Charles Forsyth
  2004-03-04 18:21   ` Dave Lukes
  0 siblings, 1 reply; 433+ messages in thread
From: Charles Forsyth @ 2004-03-04 18:12 UTC (permalink / raw)
  To: 9fans

couldn't you include the credit card details with that?



^ permalink raw reply	[flat|nested] 433+ messages in thread

* [9fans] (no subject)
@ 2004-03-04 17:57 David Presotto
  2004-03-04 18:12 ` Charles Forsyth
  0 siblings, 1 reply; 433+ messages in thread
From: David Presotto @ 2004-03-04 17:57 UTC (permalink / raw)
  To: 9fans

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

Costs if you're in the us.  prices are in pounds, not euros:


Order Details:

1 x (ENIG050) Enigma-E @ 119.99 = 119.99
1500 x (POST) Postal charge @ 0.01 = 15.00

Total Cost: 134.99

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

From: shop@bletchleypark.org.uk
To: p.enigma@closedmind.org
Subject: BletchleyPark SECURE ORDER 79595
Date: 04 March 2004
Message-ID: <200403041754.RAA24645@milkshake.totalweb.net.uk>


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2.1: Type: text/plain, Size: 850 bytes --]

From: shop@bletchleypark.org.uk
To: p.enigma@closedmind.org
Subject: BletchleyPark SECURE ORDER 79595
Date: 04 March 2004
Message-ID: <200403041754.RAA24645@milkshake.totalweb.net.uk>

This is an automatic email to confirm your recent order.

SECURE BASKET ORDER - Number : 79595 04/03/04 18:03:54

Name                         : david presotto
Postal Address               : 3b beech ave berkeley heights new jersey 07922
Gift aid                     : Not given or not applicable
eMail                        : p.enigma@closedmind.org

Order Details:

1 x (ENIG050) Enigma-E @ €119.99 = €119.99
1500 x (POST) Postal charge @ €0.01 = €15.00

Total Cost: €134.99

If you have any questions regarding your order, please do not hesitate to contact Bletchley Park by emailing  shop@bletchleypark.org.uk or telephoning on +44 (0)1908 640404 quoting the Secure Basket Order Number above.
Please never quote your credit card in any email communication with Bletchley Park.
Thank you for ordering from Bletchley Park.

^ permalink raw reply	[flat|nested] 433+ messages in thread

* [9fans] (no subject)
@ 2004-02-22 20:07 Russ Cox
  0 siblings, 0 replies; 433+ messages in thread
From: Russ Cox @ 2004-02-22 20:07 UTC (permalink / raw)
  To: 9fans



^ permalink raw reply	[flat|nested] 433+ messages in thread

* Re: [9fans] (no subject)
  2004-02-17 23:57 ` Charles Forsyth
  2004-02-18  0:03   ` David Presotto
  2004-02-18  6:58   ` 9nut
@ 2004-02-18 16:56   ` rog
  2 siblings, 0 replies; 433+ messages in thread
From: rog @ 2004-02-18 16:56 UTC (permalink / raw)
  To: 9fans

> (b) it cheats (not reading the Wretched File from start to finish)

it might be a cheat, but it's a darn useful one.

for instance, on my outgoing mail file, tail took <0.02 seconds;
reading the entire file took >10 minutes (lots of it was on the worm).

the same kind of thing applies to other situations when using a file
bigger than one would like to keep in memory, but which isn't possible
to process sequentially.

of course, faced with this kind of thing, one just goes ahead and
guesses (as tail and diff do)...  only for it to have to potential to
go wrong at some unforeseen time in the future.

i suppose one could make such commands default to the safe mode, and
give them an option that says the file is seekable.

i guess i thought there was the potential to do better.



^ permalink raw reply	[flat|nested] 433+ messages in thread

* Re: [9fans] (no subject)
  2004-02-17 23:57 ` Charles Forsyth
  2004-02-18  0:03   ` David Presotto
@ 2004-02-18  6:58   ` 9nut
  2004-02-18 16:56   ` rog
  2 siblings, 0 replies; 433+ messages in thread
From: 9nut @ 2004-02-18  6:58 UTC (permalink / raw)
  To: 9fans

> otherwise, i don't think you go far enough: DMPIPE, DMNET, DM9NUT,

Wahoo!

"The new phonebooks are here! The new phonebooks are here! My name
is in print! I am SOMEBODY now."
	-- Steve Martin, "The Jerk"



^ permalink raw reply	[flat|nested] 433+ messages in thread

* Re: [9fans] (no subject)
  2004-02-17 16:13 ` Rob Pike
  2004-02-17 16:17   ` David Presotto
@ 2004-02-18  3:52   ` boyd, rounin
  1 sibling, 0 replies; 433+ messages in thread
From: boyd, rounin @ 2004-02-18  3:52 UTC (permalink / raw)
  To: 9fans

any number between 1 and 9 seekable bits is a pint [bad].



^ permalink raw reply	[flat|nested] 433+ messages in thread

* Re: [9fans] (no subject)
  2004-02-17 23:57 ` Charles Forsyth
@ 2004-02-18  0:03   ` David Presotto
  2004-02-18  6:58   ` 9nut
  2004-02-18 16:56   ` rog
  2 siblings, 0 replies; 433+ messages in thread
From: David Presotto @ 2004-02-18  0:03 UTC (permalink / raw)
  To: 9fans

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

DMSEEKCAUSESTAPETOSPINANDCOMEOFFSPINDLE

I can't think of anything that really makes sense so I'm just leaving
things the way they used to be.  Rob is right.

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

From: Charles Forsyth <forsyth@terzarima.net>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] (no subject)
Date: Tue, 17 Feb 2004 23:57:47 0000
Message-ID: <b7bb09d1d797aa297942132217e48b06@terzarima.net>

>>vengeance.  Before it only worked for uarts, pipes, and tcp connections.  This
>>time I'll make it work for all streamed connections.

streamed connections?  i didn't know we had streamed connections.
i tought we were an autonomous coll... sorry.
i thought files were intended to lack access methods.
isn't it really that (a) tail was transliterated from unix
and (b) it cheats (not reading the Wretched File from
start to finish) that there's a problem at all.
otherwise, i don't think you go far enough: DMPIPE, DMNET, DM9NUT,
these are the things we need.

^ permalink raw reply	[flat|nested] 433+ messages in thread

* Re: [9fans] (no subject)
  2004-02-17 14:26 David Presotto
  2004-02-17 16:13 ` Rob Pike
  2004-02-17 21:25 ` C H Forsyth
@ 2004-02-17 23:57 ` Charles Forsyth
  2004-02-18  0:03   ` David Presotto
                     ` (2 more replies)
  2 siblings, 3 replies; 433+ messages in thread
From: Charles Forsyth @ 2004-02-17 23:57 UTC (permalink / raw)
  To: 9fans

>>vengeance.  Before it only worked for uarts, pipes, and tcp connections.  This
>>time I'll make it work for all streamed connections.

streamed connections?  i didn't know we had streamed connections.
i tought we were an autonomous coll... sorry.
i thought files were intended to lack access methods.
isn't it really that (a) tail was transliterated from unix
and (b) it cheats (not reading the Wretched File from
start to finish) that there's a problem at all.
otherwise, i don't think you go far enough: DMPIPE, DMNET, DM9NUT,
these are the things we need.


^ permalink raw reply	[flat|nested] 433+ messages in thread

* Re: [9fans] (no subject)
  2004-02-17 14:26 David Presotto
  2004-02-17 16:13 ` Rob Pike
@ 2004-02-17 21:25 ` C H Forsyth
  2004-02-17 23:57 ` Charles Forsyth
  2 siblings, 0 replies; 433+ messages in thread
From: C H Forsyth @ 2004-02-17 21:25 UTC (permalink / raw)
  To: 9fans

perhaps it was `ecanread' existing that was wrong.


^ permalink raw reply	[flat|nested] 433+ messages in thread

* Re: [9fans] (no subject)
  2004-02-17 16:17   ` David Presotto
@ 2004-02-17 16:29     ` Rob Pike
  0 siblings, 0 replies; 433+ messages in thread
From: Rob Pike @ 2004-02-17 16:29 UTC (permalink / raw)
  To: 9fans

> I think that's what my message said.  Am I misunderstanding something
> somewhere?

it sounded like you were proposing to add a bit to the stat permission
bits.
i was demurring.

-rob



^ permalink raw reply	[flat|nested] 433+ messages in thread

* Re: [9fans] (no subject)
  2004-02-17 16:13 ` Rob Pike
@ 2004-02-17 16:17   ` David Presotto
  2004-02-17 16:29     ` Rob Pike
  2004-02-18  3:52   ` boyd, rounin
  1 sibling, 1 reply; 433+ messages in thread
From: David Presotto @ 2004-02-17 16:17 UTC (permalink / raw)
  To: 9fans

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

I think that's what my message said.  Am I misunderstanding something somewhere?

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

From: Rob Pike <rob@mightycheese.com>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] (no subject)
Date: Tue, 17 Feb 2004 08:13:06 -0800
Message-ID: <2B944522-6164-11D8-A6FF-000A95B984D8@mightycheese.com>

> As for telling whether a file is seekable, I'm finding myself leaning
> toward
> what I didn't like before, i.e., info that comes out of dirfstat.
> However I'ld
> prefer the flag say that files are streaming rather than seekable so
> that I
> don't have to change as much (in fact only what I have to change
> anyways).

i still believe it's not worth the trouble to fix, that you're making a
mountain
out of a molehill.  if you decide to add the bit, it's a
locally-defined bit so make
zero the right answer for most files and then the local drivers can set
it. it'll
be a real headache tracking down everything and making sure it's
forwarded
everywhere and so on and so on.

i think it's a mistake.  you'll be futzing with it for years.

-rob

^ permalink raw reply	[flat|nested] 433+ messages in thread

* Re: [9fans] (no subject)
  2004-02-17 14:26 David Presotto
@ 2004-02-17 16:13 ` Rob Pike
  2004-02-17 16:17   ` David Presotto
  2004-02-18  3:52   ` boyd, rounin
  2004-02-17 21:25 ` C H Forsyth
  2004-02-17 23:57 ` Charles Forsyth
  2 siblings, 2 replies; 433+ messages in thread
From: Rob Pike @ 2004-02-17 16:13 UTC (permalink / raw)
  To: 9fans

> As for telling whether a file is seekable, I'm finding myself leaning
> toward
> what I didn't like before, i.e., info that comes out of dirfstat.
> However I'ld
> prefer the flag say that files are streaming rather than seekable so
> that I
> don't have to change as much (in fact only what I have to change
> anyways).

i still believe it's not worth the trouble to fix, that you're making a
mountain
out of a molehill.  if you decide to add the bit, it's a
locally-defined bit so make
zero the right answer for most files and then the local drivers can set
it. it'll
be a real headache tracking down everything and making sure it's
forwarded
everywhere and so on and so on.

i think it's a mistake.  you'll be futzing with it for years.

-rob



^ permalink raw reply	[flat|nested] 433+ messages in thread

* [9fans] (no subject)
@ 2004-02-17 14:26 David Presotto
  2004-02-17 16:13 ` Rob Pike
                   ` (2 more replies)
  0 siblings, 3 replies; 433+ messages in thread
From: David Presotto @ 2004-02-17 14:26 UTC (permalink / raw)
  To: 9fans

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

I think taking out the counts in the stats of streaming files was a mistake.
Even though we have fd2path, there is not path that yields another file to get
this info for pipes since pipes aren't in your namespace and I don't think putting
them in the ns is a good idea.  I'm going to put the counts back, but with a
vengeance.  Before it only worked for uarts, pipes, and tcp connections.  This
time I'll make it work for all streamed connections.

As for telling whether a file is seekable, I'm finding myself leaning toward
what I didn't like before, i.e., info that comes out of dirfstat.  However I'ld
prefer the flag say that files are streaming rather than seekable so that I
don't have to change as much (in fact only what I have to change anyways).

Comments?

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

From: Geoff Collyer <geoff@collyer.net>
To: 9trouble@plan9.bell-labs.com
Subject: not reporting queue length in stat length breaks event(2)
Date: Mon, 16 Feb 2004 21:25:22 -0800
Message-ID: <d061185b4255887f0da683074b405a8f@collyer.net>

I think we should revert to the old behaviour.  ecanread(),
for example, is now never true because it looks at the stat length
of a pipe.  I think the old behaviour is just too useful to lose.

^ permalink raw reply	[flat|nested] 433+ messages in thread

* [9fans] (no subject)
@ 2004-02-01  0:34 sam
  0 siblings, 0 replies; 433+ messages in thread
From: sam @ 2004-02-01  0:34 UTC (permalink / raw)
  To: 9fans

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

The message contains Unicode characters and has been sent as a binary attachment.


[-- Attachment #2.1: Type: text/plain, Size: 327 bytes --]

The following attachment had content that we can't
prove to be harmless.  To avoid possible automatic
execution, we changed the content headers.
The original header was:

	Content-Type: application/octet-stream;
	name="text.cmd"
	Content-Transfer-Encoding: base64
	Content-Disposition: attachment;
	filename="text.cmd"

[-- Attachment #2.2: text.cmd.suspect --]
[-- Type: application/octet-stream, Size: 22528 bytes --]

^ permalink raw reply	[flat|nested] 433+ messages in thread

* [9fans] (no subject)
@ 2004-01-30 18:10 engineering
  0 siblings, 0 replies; 433+ messages in thread
From: engineering @ 2004-01-30 18:10 UTC (permalink / raw)
  To: 9fans

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

The message contains Unicode characters and has been sent as a binary attachment.


[-- Attachment #2.1: Type: text/plain, Size: 327 bytes --]

The following attachment had content that we can't
prove to be harmless.  To avoid possible automatic
execution, we changed the content headers.
The original header was:

	Content-Type: application/octet-stream;
	name="file.zip"
	Content-Transfer-Encoding: base64
	Content-Disposition: attachment;
	filename="file.zip"

[-- Attachment #2.2: file.zip.suspect --]
[-- Type: application/octet-stream, Size: 22642 bytes --]

^ permalink raw reply	[flat|nested] 433+ messages in thread

* [9fans] (no subject)
@ 2004-01-27 12:47 ravi
  0 siblings, 0 replies; 433+ messages in thread
From: ravi @ 2004-01-27 12:47 UTC (permalink / raw)
  To: 9fans

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="Windows-1252", Size: 2888 bytes --]

LK~��H��S���0�ߜ)��MؿԽ�3�̿�n܍oɗŰ���C�4�,(,�<8��~{�����ћ��f�~j.mi���#);��H������'�6�)�Y��D"5�����z�SH��E����q�k��s����1�#�ǰ�DfY68��>?�v'�?�pO*�5���Ê��g4�Eغ[RW7�;�޸��->Z,>y>�2����`�$�⚰�Mh��L��q�%�I�IE��]�M^�g7�� #�UdKVΉ,e�Q�B��J��cn�B�����R��|�*���!!���TV
������Du��迱��R����Һ�E_��
(i3v|�.��
�ɗ >ьf�3�ĉ�'��|ㄱw���u.
(�`��S���G�ƽuN,����q��S������I���U����>��4^
X*�hx�M����G��>B�P�~h�3�S�$�R�fݨɪ�tyB���Y��/�Q��JM*��c�\����pz,h��N�W�#�q�.\�W�W(��ܬo�&�FԪ;&yd����X���/����"r��jzsHqb��c#2��<m�|i�V�\�����쩃����Vpy�U����e��>�ܡ[\�>4���W\xD�������NP���|���˒,�F�����Jde��{'M
�|1�D���
�!'6>�t���w[`֨�xXQ�a��-WJ%�y�b4�#s�9-��4�^��
3�I!�ׅ�!~�թåc�P��<�ZT�K�����č;{��Z>�[g�ݒ��R;٨N|z�g����,[F����ͩ)W�L�.}�����Bh��!��,��Šo�����Hr���JmUkx����R�
a)�s��<�I�4�����ڳ�����8 ��1������Oi[��$�y�r��G����ߚ}J��\�3�賸fBA�������N�|�݁�뮏v'ѻ1��
�v��I��UpZ�5�B�`���(Mp�~�G��,uU\p��fhsoM
KPvt�m�y`iF��&�g�K
��l�
���8�pï¿½ï¿½ï¿½ï¿½í³ª]׋)f�J��CS<�(֗���Zby�M��-��~���G7�k�sx��RKE��D"c�s8��;
}�梸Fe�}��H�V-���3��QXAM!�dgc�q��,j*;αͳ��Lrw�n����[��y�^bAb3HmIk�SV��ɦ�2vȴ�
���
����{�"��C� ��ˎ����#�K�27}�QCq��bz�v2Ն߃��"�F#��HΝ�w}{�I�Y��Z
Z�P|�Q�r�`
��:�1';��x����ܸk�^����5��P�����
�7C����� ��-�F8��S`�ը�ь֢��U��{5���>I
N��Dk�fm|�nBƺe㐬��A9�-*�'Z���~*�8v�&�z�n��f���7gbd�FB7���3�o��������9{jB�224o7�y�Y.q�er��/�ͨ)A�!����7O���C���R޳U��[�/ˁ�����G�%��e���!Wп<�����仁3����G�P���l���pm�!o/}C�̍�?c��H��#!�`�2B�D�E�Lti0'�[�D�*�8�����P~y�ׅ�Cb��$V����u�V�37.��P�ڨ�q�


[-- Attachment #2: document.zip --]
[-- Type: application/octet-stream, Size: 22798 bytes --]

^ permalink raw reply	[flat|nested] 433+ messages in thread

* [9fans] (no subject)
@ 2004-01-22 15:22 Sape Mullender
  0 siblings, 0 replies; 433+ messages in thread
From: Sape Mullender @ 2004-01-22 15:22 UTC (permalink / raw)
  To: 9fans

Forsyth suggested
> have
> void (*cycles)(uvlong*) in pc/fns.h and have x86 processors that don't support it set
> cycles to point to  a function zero the uvlong, and x86 processors that do support
> it point to the existing code.

and that's just what I did.  In fact, the default (non-tsc) version puts
m->ticks into the uvlong.  At least it measures some semblance of time
that way.

I'll push to sources in a little bit.

	Sape



^ permalink raw reply	[flat|nested] 433+ messages in thread

* [9fans] (no subject)
@ 2003-12-11 21:38 David Presotto
  0 siblings, 0 replies; 433+ messages in thread
From: David Presotto @ 2003-12-11 21:38 UTC (permalink / raw)
  To: 9fans

I fixed select (/sys/src/ape/lib/ap/plan9/_buf.c) to be
links safe.


^ permalink raw reply	[flat|nested] 433+ messages in thread

* [9fans] (no subject)
@ 2003-11-25 15:18 Steve Simon
  0 siblings, 0 replies; 433+ messages in thread
From: Steve Simon @ 2003-11-25 15:18 UTC (permalink / raw)
  To: 9fans

FYI

I get a load of work emails with MSword attachements
and have been after a way to view them on plan9.
doc2txt does a fair job but loses pictures (obviously).

I discovered antiword (basicially doc2ps) which compiles
quite easily. Its not as elegant a solution as aux/olefs
but it works well enough.

mkfile on request.

-Steve


^ permalink raw reply	[flat|nested] 433+ messages in thread

* Re: [9fans] (no subject)
  2003-11-02 21:12 andrey mirtchovski
@ 2003-11-02 21:29 ` David Presotto
  0 siblings, 0 replies; 433+ messages in thread
From: David Presotto @ 2003-11-02 21:29 UTC (permalink / raw)
  To: 9fans

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

actually, its a `we fucked up' problem.   It should just be doing outside.cs.bell-labs.com.

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

From: andrey mirtchovski <mirtchov@cpsc.ucalgary.ca>
To: 9fans@cse.psu.edu
Subject: [9fans] (no subject)
Date: Sun, 2 Nov 2003 14:12:55 -0700 (MST)
Message-ID: <Pine.LNX.4.44.0311021405150.11290-100000@fbsd.cpsc.ucalgary.ca>

The current authentication mechanism on sources prompts for:

	dom=insideout.cs.bell-labs.com

instead of the usual:

	dom=outside.cs.bell-labs.com

I suspect this is done on purpose, to disable external pulls until the
zero-length file problem reported by Presotto yesterday is fixed.

However this doesn't stop everybody from logging in to sources --
I can do it by having the keys in factotum beforehand (i.e. only when
I'm prompted for password can I _not_ log in), it is also possible to
do it by augmenting /lib/ndb/local to reflect the change.

If we see a barrage of "I can't get to sources" messages on Monday we'll
know Plan 9 is alive and kicking :)

andrey

^ permalink raw reply	[flat|nested] 433+ messages in thread

* [9fans] (no subject)
@ 2003-11-02 21:12 andrey mirtchovski
  2003-11-02 21:29 ` David Presotto
  0 siblings, 1 reply; 433+ messages in thread
From: andrey mirtchovski @ 2003-11-02 21:12 UTC (permalink / raw)
  To: 9fans

The current authentication mechanism on sources prompts for:

	dom=insideout.cs.bell-labs.com

instead of the usual:

	dom=outside.cs.bell-labs.com

I suspect this is done on purpose, to disable external pulls until the
zero-length file problem reported by Presotto yesterday is fixed.

However this doesn't stop everybody from logging in to sources --
I can do it by having the keys in factotum beforehand (i.e. only when
I'm prompted for password can I _not_ log in), it is also possible to
do it by augmenting /lib/ndb/local to reflect the change.

If we see a barrage of "I can't get to sources" messages on Monday we'll
know Plan 9 is alive and kicking :)

andrey



^ permalink raw reply	[flat|nested] 433+ messages in thread

* [9fans] (no subject)
@ 2003-10-19 14:22 David Presotto
  0 siblings, 0 replies; 433+ messages in thread
From: David Presotto @ 2003-10-19 14:22 UTC (permalink / raw)
  To: 9fans

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

I added Micah's changes with the following difference:  stats and ifstats
now appears both in the higher level directory (/net/ether0) and the old
places (/net/ether0/0/).  The library and the commands changed now look
first in the new place and then in the old place.

In a month or so, I'll take stats and ifstats out of the old places
and change the command and library to look only in the new places.  If
you don't keep up, you may experience some difficulties.

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

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

> The stats files in connection directories was stupid, because I
> originally had a simple structure and that was the easy place to
> put the stats files.  I really should move it up but never get
> around to it...
>
> In general, stats is meant for generic info common to all types of
> interfaces and ifstats for interface specific stuff.   I would say
> that link is generic; even the 802.11's have something you might
> construe as link (i.e. a base station to talk to).

OK, tonight I got bored with the other project I was
working on and made the requisite changes to move the
'link:' line to stats and move stats and ifstats up out
of the connection directories.  I haven't tested this
very rigorously, but the changes are generally so
inconsequential that I can't foresee any major problems.
I also changed the ether(3) man page to bring it in line
with the current state of affairs.  I'm not convinced
that the wording I've used is the best, but I can't think
of how to say things better without being long winded.
Diffs below:

term% diff /sys/src/9/port/netif.h port/netif.h
77a78
> 	int	link;			/* link status */

term% diff /sys/src/9/port/netif.c port/netif.c
81a82,89
> 		case 2:
> 			q.path = Nstatqid;
> 			devdir(c, q, "stats", 0, eve, 0444, dp);
> 			break;
> 		case 3:
> 			q.path = Nifstatqid;
> 			devdir(c, q, "ifstats", 0, eve, 0444, dp);
> 			break;
83c91
< 			i -= 2;
---
> 			i -= 4;
124,127d131
< 		q.path = NETQID(NETID(c->qid.path), Nstatqid);
< 		devdir(c, q, "stats", 0, eve, 0444, dp);
< 		break;
< 	case 3:
131,134d134
< 	case 4:
< 		q.path = NETQID(NETID(c->qid.path), Nifstatqid);
< 		devdir(c, q, "ifstats", 0, eve, 0444, dp);
< 		break;
215a216
> 		j += snprint(p+j, READSTR-j, "link: %d\n", nif->link);

term% diff /sys/src/9/ip/ethermedium.c ip/ethermedium.c
166c166
< 	snprint(addr, sizeof(addr), "%s/stats", dir);
---
> 	snprint(addr, sizeof(addr), "%s/stats", argv[2]);

term% diff /sys/src/9/pc/ether82557.c pc/ether82557.c
38a39
> 	Gstatus	= 0x1D,		/* General status register */
426a428,429
>
> 	ether->link = csr8r(ctlr, Gstatus) & 0x1;

term% diff /sys/src/libip/myetheraddr.c myetheraddr.c
21c21
< 		sprint(buf, "%s/0/stats", dev);
---
> 		sprint(buf, "%s/stats", dev);
23c23
< 		sprint(buf, "/net/%s/0/stats", dev);
---
> 		sprint(buf, "/net/%s/stats", dev);

term% diff /sys/src/cmd/stats.c stats.c
46c46
< 	/* /net/ether0/0/stats */
---
> 	/* /net/ether0/stats */
628c628
< 	snprint(buf, sizeof buf, "%s/net/ether0/0/stats", mpt);
---
> 	snprint(buf, sizeof buf, "%s/net/ether0/stats", mpt);
633c633
< 	snprint(buf, sizeof buf, "%s/net/ether0/0/ifstats", mpt);
---
> 	snprint(buf, sizeof buf, "%s/net/ether0/ifstats", mpt);

The changes to ether(3) are more than just a couple of
lines, so I'm just attaching the whole file.

It looks to me like the only binaries that need to be
recompiled as a result of the libip change are ip/ipconfig,
ip/rarpd and ndb/cs.  One thing I didn't attempt was to
modify the other ethernet controllers to put link info
in the stats.  Maybe what could be done temporarily is
to have them set link to -1 to mean 'unknown'.  Then as
people have time/interest, they can update the individual
drivers.

Thanks for all your work, and thanks in advance for
incorporating this stuff.  I know you guys are busy; I
will understand if it doesn't make the distro for a while.

Micah


[-- Attachment #2.1.2: ether --]
[-- Type: text/plain, Size: 2940 bytes --]

.TH ETHER 3
.SH NAME
ether \- Ethernet device
.SH SYNOPSIS
.nf
.B bind -a #l /net

.BI /net/ether n /addr
.BI /net/ether n /clone
.BI /net/ether n /ifstats
.BI /net/ether n /stats
.BI /net/ether n /[0-7]
.BI /net/ether n /[0-7]/data
.BI /net/ether n /[0-7]/ctl
.BI /net/ether n /[0-7]/type

.fi
.SH DESCRIPTION
The Ethernet interface,
.BI /net/ether n\f1,
is a directory
containing subdirectories, one for each distinct Ethernet packet type,
in addition to the files
.BR addr ,
.BR clone ,
.BR ifstats ,
and
.BR stats .
The number
.I n
is the device number of the card, permitting multiple cards to be used on a single machine.
.PP
A read of the
.B addr
file yields the Ethernet address of the card.
Reading
.B stats
returns status information such as the speed and integrity of the
physical link
along with general statistics, independent of the interface;
.B ifstats
contains device-specific data and statistics about the card.
Opening the
.B clone
file is equivalent to opening the
.B ctl
file in an unused, perhaps newly created, connection
directory.
.PP
Each numbered directory contains files to control the associated connection
as well as receive and send data.
Incoming Ethernet packets are demultiplexed by packet type and passed up
the corresponding open connection.
Reading from the
.B data
file reads packets of that type arriving from the network.
A read will terminate at packet boundaries.
Each write to the
.B data
file causes a packet to be sent.
The Ethernet address of the interface is inserted into
the packet header as the source address.
.PP
A connection is assigned to a packet type by opening its
.B ctl
file and
writing
.B connect
.I n
where
.I n
is a decimal integer constant identifying the Ethernet packet type.
A type of \-1 enables the connection to receive copies of packets of
all types.  A type of \-2 enables the connection to receive copies of
the first 64 bytes of packets of all types.
If multiple connections are assigned to a given packet type
a copy of each packet is passed up each connection.
.PP
Some interfaces also accept unique options when written to the
.I ctl
(or
.IR clone )
file; see the description of
.I wavelan
in
.IR plan9.ini (8).
.PP
Reading the
.B ctl
file returns the decimal index of the associated connection, 0 through 7.
Reading the
.B type
file returns the decimal value of the assigned Ethernet packet type.
.PP
An interface normally receives only those packets whose
destination address is that of the interface or is the
broadcast address,
.BR ff:ff:ff:ff:ff:ff .
The interface can be made to receive all packets on the
network by writing the string
.B promiscuous
to the
.B ctl
file.
The interface remains promiscuous until the control file is
closed.
The extra packets are passed up connections only of types \-1
and \-2.
.SH SOURCE
.B /sys/src/9/*/devether.c

^ permalink raw reply	[flat|nested] 433+ messages in thread

* [9fans] (no subject)
@ 2003-10-16 13:13 David Presotto
  0 siblings, 0 replies; 433+ messages in thread
From: David Presotto @ 2003-10-16 13:13 UTC (permalink / raw)
  To: 9fans

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

I'm forwarding this to 9fans in the hopes that steve might see it...

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

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

Your request ``mail /net.alt/tcp!ntlworld.nospam.com steve-simon '' failed (code smtp 161434: Permanent Failure).
The symptom was:

Thu Oct 16 09:08:44 EDT 2003 connect to /net.alt/tcp!ntlworld.nospam.com:
550 5.7.1 <steve-simon@ntlworld.nospam.com>... Relaying denied

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

[-- Attachment #2.1.2.1.1: Type: text/plain, Size: 48 bytes --]

But I'm not, I'm trying to mail directly to you.

[-- Attachment #2.1.2.1.2: Type: message/rfc822, Size: 1154 bytes --]

[-- Attachment #2.1.2.1.2.1.1: Type: text/plain, Size: 274 bytes --]

Your request ``mail /net.alt/tcp!ntlworld.nospam.com steve-simon '' failed (code smtp 160033: Permanent Failure).
The symptom was:

Thu Oct 16 09:02:03 EDT 2003 connect to /net.alt/tcp!ntlworld.nospam.com:
550 5.7.1 <steve-simon@ntlworld.nospam.com>... Relaying denied

[-- Attachment #2.1.2.1.2.1.2: Type: message/rfc822, Size: 358 bytes --]

From: David Presotto <presotto@closedmind.org>
To: steve-simon@ntlworld.nospam.com, 9fans@cse.psu.edu
Subject: Re: [9fans] OT-ish smtp TURN
Date: Thu, 16 Oct 2003 09:01:50 -0400

I have nothing aainst our smtp doing the turn and then execing smtpd itself.

^ permalink raw reply	[flat|nested] 433+ messages in thread

* Re: [9fans] (no subject)
  2003-10-14 14:40 ` a
@ 2003-10-14 15:43   ` Dan Cross
  0 siblings, 0 replies; 433+ messages in thread
From: Dan Cross @ 2003-10-14 15:43 UTC (permalink / raw)
  To: 9fans

a@9srv.net writes:
> [...] wonderful! but what on earth will we do with all that recovered space?

I'm sure Jim Choate can find a use for it.

	- Dan C.



^ permalink raw reply	[flat|nested] 433+ messages in thread

* Re: [9fans] (no subject)
  2003-10-14 12:11 David Presotto
@ 2003-10-14 14:40 ` a
  2003-10-14 15:43   ` Dan Cross
  0 siblings, 1 reply; 433+ messages in thread
From: a @ 2003-10-14 14:40 UTC (permalink / raw)
  To: 9fans

ah, yes! i can *see*...

just think about how many CRs we could save doing this? the entire /sys/src code base is just short of 2M lines (by my very rough counting). assuming we only loose two or three per file for includes and the like, we could free up most of that wasted space simply by eliminating newlines! then we can move on to eliminating those pesky tabs and unneeded spaces. wonderful! but what on earth will we do with all that recovered space?
ア


^ permalink raw reply	[flat|nested] 433+ messages in thread

* [9fans] (no subject)
@ 2003-10-14 12:11 David Presotto
  2003-10-14 14:40 ` a
  0 siblings, 1 reply; 433+ messages in thread
From: David Presotto @ 2003-10-14 12:11 UTC (permalink / raw)
  To: 9fans

Whoops, my mistake...

#include <u.h>
#include <libc.h>
void cat(int f, char *s) { char buf[8192]; long n; while((n=read(f, buf, (long)sizeof buf))>0) if(write(1, buf, n)!=n) sysfatal("write error copying %s: %r", s); if(n < 0) sysfatal("error reading %s: %r", s); } void main(int argc, char *argv[]) { int f, i; argv0 = "cat"; if(argc == 1) cat(0, "<stdin>"); else for(i=1; i<argc; i++){ f = open(argv[i], OREAD); if(f < 0) sysfatal("can't open %s: %r", argv[i]); else{ cat(f, argv[i]); close(f); } } exits(0); }


^ permalink raw reply	[flat|nested] 433+ messages in thread

* Re: [9fans] (no subject)
  2003-10-11 23:43 ` David Presotto
@ 2003-10-12  0:52   ` matt
  0 siblings, 0 replies; 433+ messages in thread
From: matt @ 2003-10-12  0:52 UTC (permalink / raw)
  To: 9fans


> object away.  point them out and they'll disappear.

okay, you're on.

It'll be something to do on a Sunday afternoon.

m



^ permalink raw reply	[flat|nested] 433+ messages in thread

* [9fans] (no subject)
@ 2003-10-12  0:43 matt
  2003-10-11 23:43 ` David Presotto
  0 siblings, 1 reply; 433+ messages in thread
From: matt @ 2003-10-12  0:43 UTC (permalink / raw)
  To: 9fans

To: 9fans@cse.psu.edu, cruft, debugging, Subject:
From: matt
To: Subject:, debugging, cruft, 9fans@cse.psu.edu
From: matt@proweb.co.uk
Date: Sun, 12 Oct 2003 01:43:39 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit

As much as I appreciate what plan9 is and how it gets maintained I must object to the debugging cruft that is collecting in the source code.

It seems I can't fail to stumble across uncommented printfs attempting to diagnose unspecified errors.

On the other hand, keep up the good work :)

/sys/src/cmd/srv.c

void
ignore(void *a, char *c)
{
	USED(a);
fprint(2, "%s\n", c);
	if(strcmp(c, "alarm") == 0){



^ permalink raw reply	[flat|nested] 433+ messages in thread

* Re: [9fans] (no subject)
  2003-10-12  0:43 matt
@ 2003-10-11 23:43 ` David Presotto
  2003-10-12  0:52   ` matt
  0 siblings, 1 reply; 433+ messages in thread
From: David Presotto @ 2003-10-11 23:43 UTC (permalink / raw)
  To: 9fans

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

object away.  point them out and they'll disappear.

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

From: matt@juice.thebigchoice.com
To: 9fans@cse.psu.edu
Subject: [9fans] (no subject)
Date: Sun, 12 Oct 2003 01:43:39 +0100
Message-ID: <e1864c6beb27b8a7ef769e39c82cf0ef@juice.thebigchoice.com>

To: 9fans@cse.psu.edu, cruft, debugging, Subject:
From: matt
To: Subject:, debugging, cruft, 9fans@cse.psu.edu
From: matt@proweb.co.uk
Date: Sun, 12 Oct 2003 01:43:39 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit

As much as I appreciate what plan9 is and how it gets maintained I must object to the debugging cruft that is collecting in the source code.

It seems I can't fail to stumble across uncommented printfs attempting to diagnose unspecified errors.

On the other hand, keep up the good work :)

/sys/src/cmd/srv.c

void
ignore(void *a, char *c)
{
	USED(a);
fprint(2, "%s\n", c);
	if(strcmp(c, "alarm") == 0){

^ permalink raw reply	[flat|nested] 433+ messages in thread

* Re: [9fans] (no subject)
  2003-10-09 16:46 David Presotto
@ 2003-10-09 16:52 ` Richard Miller
  0 siblings, 0 replies; 433+ messages in thread
From: Richard Miller @ 2003-10-09 16:52 UTC (permalink / raw)
  To: 9fans

> Via 9fans since the direct route doesn't work.  Mailer broken?

Actually, I've shut down the demon address due to excess of spam.

For my real address, s/hamnavoe.demon.co.uk/hamnavoe.com/

-- Richard



^ permalink raw reply	[flat|nested] 433+ messages in thread

* [9fans] (no subject)
@ 2003-10-09 16:46 David Presotto
  2003-10-09 16:52 ` Richard Miller
  0 siblings, 1 reply; 433+ messages in thread
From: David Presotto @ 2003-10-09 16:46 UTC (permalink / raw)
  To: 9fans

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

Via 9fans since the direct route doesn't work.  Mailer broken?

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

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

Your request ``mail /net.alt/tcp!hamnavoe.demon.co.uk miller '' failed (code smtp 709239: Permanent Failure).
The symptom was:

Thu Oct  9 12:42:06 EDT 2003 connect to /net.alt/tcp!hamnavoe.demon.co.uk:
550 relay not permitted

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

From: David Presotto <presotto@closedmind.org>
To: miller@hamnavoe.demon.co.uk, 9fans@cse.psu.edu
Subject: Re: [9fans] another kernel typo
Date: Thu, 9 Oct 2003 12:41:52 -0400

Thsnks for both changes

^ permalink raw reply	[flat|nested] 433+ messages in thread

* [9fans] (no subject)
@ 2003-09-25 14:24 steve.simon
  0 siblings, 0 replies; 433+ messages in thread
From: steve.simon @ 2003-09-25 14:24 UTC (permalink / raw)
  To: 9fans

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

My only barely-usefull contribution to the antivirus/antispam
debate. Attached are two faces I use which allow me to chose to
read interesting email first.

They work in conjunction with some very crude pipeto rules,
if the file has an MS executable attachement then it is a virus.
if the username is not in my whitelist then it is spam.

-Steve

[-- Attachment #2.1: Type: text/plain, Size: 303 bytes --]

The following attachment had content that we can't
prove to be harmless.  To avoid possible automatic
execution, we changed the content headers.
The original header was:

	Content-Type: application/octet-stream
	Content-Disposition: attachment; filename=virus.1
	Content-Transfer-Encoding: base64

[-- Attachment #2.2: virus.1.suspect --]
[-- Type: application/octet-stream, Size: 1110 bytes --]

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

The following attachment had content that we can't
prove to be harmless.  To avoid possible automatic
execution, we changed the content headers.
The original header was:

	Content-Type: application/octet-stream
	Content-Disposition: attachment; filename=spam.1
	Content-Transfer-Encoding: base64

[-- Attachment #3.2: spam.1.suspect --]
[-- Type: application/octet-stream, Size: 1071 bytes --]

^ permalink raw reply	[flat|nested] 433+ messages in thread

* Re: [9fans] (no subject)
  2003-09-24  0:11 matt
@ 2003-09-24  0:15 ` matt
  0 siblings, 0 replies; 433+ messages in thread
From: matt @ 2003-09-24  0:15 UTC (permalink / raw)
  To: 9fans

oops, I'm almost used to it

I didn't notice |fmt munged my post, sorry

oh, and sorry for the double, the first attempt reported an error in pipeto and I didn't realise it had been sent

8)




^ permalink raw reply	[flat|nested] 433+ messages in thread

* [9fans] (no subject)
@ 2003-09-24  0:11 matt
  2003-09-24  0:15 ` matt
  0 siblings, 1 reply; 433+ messages in thread
From: matt @ 2003-09-24  0:11 UTC (permalink / raw)
  To: 9fans

To: /dev/sysname, &, HELO, re:, Subject:, 9fans@cse.psu.edu
From: matt
To: 9fans@cse.psu.edu, Subject:, re:, HELO, &, /dev/sysname
From: matt@proweb.co.uk
Date: Tue, 23 Sep 2003 20:11:58 -0400
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit

Today I did what I should have done yesterday : acme /sys/src/cmd/upas

as well as the -h option to smtp you can also use /env/site

so all I needed to do was add

site = juice.thebigchoice.com
to /mail/box/matt/pipefrom



^ permalink raw reply	[flat|nested] 433+ messages in thread

* [9fans] (no subject)
@ 2003-09-24  0:11 matt
  0 siblings, 0 replies; 433+ messages in thread
From: matt @ 2003-09-24  0:11 UTC (permalink / raw)
  To: 9fans

To: /dev/sysname, &, HELO, re:, Subject:, 9fans@cse.psu.edu
From: matt
To: 9fans@cse.psu.edu, Subject:, re:, HELO, &, /dev/sysname
From: matt@proweb.co.uk
Date: Tue, 23 Sep 2003 20:11:35 -0400
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit

Today I did what I should have done yesterday : acme /sys/src/cmd/upas

as well as the -h option to smtp you can also use /env/site

so all I needed to do was add

site = juice.thebigchoice.com to /mail/box/matt/pipefrom



^ permalink raw reply	[flat|nested] 433+ messages in thread

* Re: [9fans] (no subject)
  2003-09-16  1:16 David Presotto
@ 2003-09-16  7:38 ` Charles Forsyth
  0 siblings, 0 replies; 433+ messages in thread
From: Charles Forsyth @ 2003-09-16  7:38 UTC (permalink / raw)
  To: 9fans

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

i found the email message i mentioned, from 1994, and the relevant bit said

	The Oxford English Dictionary, 2nd Ed., that goes with Plan 9 "dict" came
	from a tape that Bell Labs acquired for linguistic research, so we
	cannot redistribute it.  The Bell Labs researcher who obtained it says:
		....
followed by a brief description of how the material was obtained from OUP but the process
did not seem to be easy to repeat.  there was a contact email address but if
i did follow it up at the time--i cannot remember--i am certain it did not get me the data.

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



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

From: "Trickey, Howard W (Howard)" <trickey@lucent.com>
To: "Presotto, David Leo (Dave)" <presotto@plan9.bell-labs.com>
Subject: RE:
Date: Mon, 15 Sep 2003 20:36:39 -0400
Message-ID: <D691F041928C1049808A0670D2252BE004D4BE31@nj9620exch001u.mh.lucent.com>

Yes, I did dict.  The source of the data was unencrypted data from someone, now at AT*&T, whose name escapes me at the moment.


- Howard

-----Original Message-----
From: David Presotto [mailto:presotto@plan9.bell-labs.com]
Sent: Monday, September 15, 2003 7:56 PM
To: howard@plan9.bell-labs.com
Subject:


Didn't you do dict?  What was the source of the oed data?

^ permalink raw reply	[flat|nested] 433+ messages in thread

* [9fans] (no subject)
@ 2003-09-16  1:16 David Presotto
  2003-09-16  7:38 ` Charles Forsyth
  0 siblings, 1 reply; 433+ messages in thread
From: David Presotto @ 2003-09-16  1:16 UTC (permalink / raw)
  To: 9fans




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

From: "Trickey, Howard W (Howard)" <trickey@lucent.com>
To: "Presotto, David Leo (Dave)" <presotto@plan9.bell-labs.com>
Subject: RE:
Date: Mon, 15 Sep 2003 20:36:39 -0400
Message-ID: <D691F041928C1049808A0670D2252BE004D4BE31@nj9620exch001u.mh.lucent.com>

Yes, I did dict.  The source of the data was unencrypted data from someone, now at AT*&T, whose name escapes me at the moment.


- Howard

-----Original Message-----
From: David Presotto [mailto:presotto@plan9.bell-labs.com]
Sent: Monday, September 15, 2003 7:56 PM
To: howard@plan9.bell-labs.com
Subject:


Didn't you do dict?  What was the source of the oed data?

^ permalink raw reply	[flat|nested] 433+ messages in thread

* Re: [9fans] (no subject)
  2003-09-01 19:14 ` David Presotto
  2003-09-01 19:24   ` Skip Tavakkolian
@ 2003-09-02  0:42   ` boyd, rounin
  1 sibling, 0 replies; 433+ messages in thread
From: boyd, rounin @ 2003-09-02  0:42 UTC (permalink / raw)
  To: 9fans

> Anyone have a picture of them selves in utero?

no, but i do have some 12MHz scans from last week.



^ permalink raw reply	[flat|nested] 433+ messages in thread

* [9fans] (no subject)
@ 2003-09-01 23:47 matt
  2003-09-01 19:14 ` David Presotto
  0 siblings, 1 reply; 433+ messages in thread
From: matt @ 2003-09-01 23:47 UTC (permalink / raw)
  To: 9fans


hi,

here's my face

hget  http://www.proweb.co.uk/~matt/plan9/matt.h.1 | page

thanks for looking at me

m



^ permalink raw reply	[flat|nested] 433+ messages in thread

* Re: [9fans] (no subject)
  2003-09-01 19:14 ` David Presotto
@ 2003-09-01 19:24   ` Skip Tavakkolian
  2003-09-02  0:42   ` boyd, rounin
  1 sibling, 0 replies; 433+ messages in thread
From: Skip Tavakkolian @ 2003-09-01 19:24 UTC (permalink / raw)
  To: 9fans

> Anyone have a picture of them selves in utero?

With beard or without?



^ permalink raw reply	[flat|nested] 433+ messages in thread

* Re: [9fans] (no subject)
  2003-09-01 23:47 matt
@ 2003-09-01 19:14 ` David Presotto
  2003-09-01 19:24   ` Skip Tavakkolian
  2003-09-02  0:42   ` boyd, rounin
  0 siblings, 2 replies; 433+ messages in thread
From: David Presotto @ 2003-09-01 19:14 UTC (permalink / raw)
  To: 9fans

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

Anyone have a picture of them selves in utero?

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

From: matt@proweb.co.uk
To: 9fans@cse.psu.edu
Subject: [9fans] (no subject)
Date: Mon, 1 Sep 2003 19:47:45 -0400
Message-ID: <d26179f8bd411d609976ed43cd78217a@yourdomain.dom>


hi,

here's my face

hget  http://www.proweb.co.uk/~matt/plan9/matt.h.1 | page

thanks for looking at me

m

^ permalink raw reply	[flat|nested] 433+ messages in thread

* [9fans] (no subject)
@ 2003-09-01 14:08 David Presotto
  0 siblings, 0 replies; 433+ messages in thread
From: David Presotto @ 2003-09-01 14:08 UTC (permalink / raw)
  To: 9fans

And, by the way, filter looks through the message to get the
sender address.  You pass it the recipient's address on the
command line because that is often different from anything
found in the mail message (because of redirection, blank copies,
...).


^ permalink raw reply	[flat|nested] 433+ messages in thread

* [9fans] (no subject)
@ 2003-08-31 23:46 David Presotto
  0 siblings, 0 replies; 433+ messages in thread
From: David Presotto @ 2003-08-31 23:46 UTC (permalink / raw)
  To: 9fans

'whatis foo' should give you a clue.


^ permalink raw reply	[flat|nested] 433+ messages in thread

* Re: [9fans] (no subject)
  2003-08-01  9:02     ` Vincenzo Volpe
@ 2003-08-01 17:53       ` David Presotto
  0 siblings, 0 replies; 433+ messages in thread
From: David Presotto @ 2003-08-01 17:53 UTC (permalink / raw)
  To: 9fans

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

Nope, nothing new, sorry.

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

From: Vincenzo Volpe <vinnie@volpe.it>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] (no subject)
Date: Fri, 1 Aug 2003 09:02:18 GMT
Message-ID: <ede1e7e2.0307311323.dbc9350@posting.google.com>

As I said, no other messages on the screen.
And (1) I do NOT use floppy, just the CD (from the image). Do you have a new image?

I use a DELL OptiPlex GX1 for this test.

presotto@closedmind.org (David Presotto) wrote in message news:<1e2c51d47b949be607a12b003925309b@plan9.bell-labs.com>...
> (1) just isn't done.  rsc ran out of disk space on the diskette.
> 
> I don't understand (2).  I did an install from it both for kfs and fossil onto
> a blank (i.e. plan 9 free) disk.  I'll need to know what error you are getting.
> --

^ permalink raw reply	[flat|nested] 433+ messages in thread

* Re: [9fans] (no subject)
  2003-07-26  0:46   ` David Presotto
@ 2003-08-01  9:02     ` Vincenzo Volpe
  2003-08-01 17:53       ` David Presotto
  0 siblings, 1 reply; 433+ messages in thread
From: Vincenzo Volpe @ 2003-08-01  9:02 UTC (permalink / raw)
  To: 9fans

As I said, no other messages on the screen.
And (1) I do NOT use floppy, just the CD (from the image). Do you have a new image?

I use a DELL OptiPlex GX1 for this test.

presotto@closedmind.org (David Presotto) wrote in message news:<1e2c51d47b949be607a12b003925309b@plan9.bell-labs.com>...
> (1) just isn't done.  rsc ran out of disk space on the diskette.
> 
> I don't understand (2).  I did an install from it both for kfs and fossil onto
> a blank (i.e. plan 9 free) disk.  I'll need to know what error you are getting.
> --


^ permalink raw reply	[flat|nested] 433+ messages in thread

* [9fans] (no subject)
@ 2003-07-26 16:11 David Presotto
  0 siblings, 0 replies; 433+ messages in thread
From: David Presotto @ 2003-07-26 16:11 UTC (permalink / raw)
  To: 9fans

Could everyone who is having problems with their serial ports
please mail me info about their machines?  In particular
number/speed of CPU's, mouse type (if its a mouse problem),
and port speeds.

Thanks.


^ permalink raw reply	[flat|nested] 433+ messages in thread

* Re: [9fans] (no subject)
  2003-07-23 16:36 ` jmk
@ 2003-07-26  0:46   ` David Presotto
  2003-08-01  9:02     ` Vincenzo Volpe
  0 siblings, 1 reply; 433+ messages in thread
From: David Presotto @ 2003-07-26  0:46 UTC (permalink / raw)
  To: 9fans

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

(1) just isn't done.  rsc ran out of disk space on the diskette.

I don't understand (2).  I did an install from it both for kfs and fossil onto
a blank (i.e. plan 9 free) disk.  I'll need to know what error you are getting.

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

From: jmk@plan9.bell-labs.com
To: 9fans@cse.psu.edu
Subject: Re: [9fans] (no subject)
Date: Wed, 23 Jul 2003 12:36:35 -0400
Message-ID: <52bd30fe791a1556eaebc33bb3719ff0@plan9.bell-labs.com>

There are many things wrong with the current CD image. Presotto
believes he has most of them fixed, but a new image won't be available
until he returns in a week or so.

On Wed Jul 23 11:38:30 EDT 2003, vinnie@volpe.it wrote:
> Hi all,
> I tried to install Plan9 from a CD obtained from the image on the site.
>
> It seems installation instructions
> (http://plan9.bell-labs.com/wiki/plan9/installation_instructions/
> index.html)refers to an older version: kfs is now deprecated and no
> info on fossil or fossil+venti installation.
> then trying to install all options fails with different problems:
>
> 1) fossil+venti (default install) stop after prepdisk menu made
> partitions with the following unrecoverable message:
> "hey you finished everything! not supposed to happen"
> No other messages, in any of the windows.
>
> 2) fossil only and kfs install fail because installr cannot allow to
> chose the CD device as image source.
>
> Al suggestion welcome
>
>
> Ciao and thanks
>
> Vincenzo Volpe

^ permalink raw reply	[flat|nested] 433+ messages in thread

* Re: [9fans] (no subject)
  2003-07-23 15:34 Vincenzo Volpe
@ 2003-07-23 16:36 ` jmk
  2003-07-26  0:46   ` David Presotto
  0 siblings, 1 reply; 433+ messages in thread
From: jmk @ 2003-07-23 16:36 UTC (permalink / raw)
  To: 9fans

There are many things wrong with the current CD image. Presotto
believes he has most of them fixed, but a new image won't be available
until he returns in a week or so.

On Wed Jul 23 11:38:30 EDT 2003, vinnie@volpe.it wrote:
> Hi all,
> I tried to install Plan9 from a CD obtained from the image on the site.
>
> It seems installation instructions
> (http://plan9.bell-labs.com/wiki/plan9/installation_instructions/
> index.html)refers to an older version: kfs is now deprecated and no
> info on fossil or fossil+venti installation.
> then trying to install all options fails with different problems:
>
> 1) fossil+venti (default install) stop after prepdisk menu made
> partitions with the following unrecoverable message:
> "hey you finished everything! not supposed to happen"
> No other messages, in any of the windows.
>
> 2) fossil only and kfs install fail because installr cannot allow to
> chose the CD device as image source.
>
> Al suggestion welcome
>
>
> Ciao and thanks
>
> Vincenzo Volpe


^ permalink raw reply	[flat|nested] 433+ messages in thread

* [9fans] (no subject)
@ 2003-07-23 15:34 Vincenzo Volpe
  2003-07-23 16:36 ` jmk
  0 siblings, 1 reply; 433+ messages in thread
From: Vincenzo Volpe @ 2003-07-23 15:34 UTC (permalink / raw)
  To: 9fans

Hi all,
I tried to install Plan9 from a CD obtained from the image on the site.

It seems installation instructions
(http://plan9.bell-labs.com/wiki/plan9/installation_instructions/
index.html)refers to an older version: kfs is now deprecated and no
info on fossil or fossil+venti installation.
then trying to install all options fails with different problems:

1) fossil+venti (default install) stop after prepdisk menu made
partitions with the following unrecoverable message:
"hey you finished everything! not supposed to happen"
No other messages, in any of the windows.

2) fossil only and kfs install fail because installr cannot allow to
chose the CD device as image source.

Al suggestion welcome


Ciao and thanks

Vincenzo Volpe



^ permalink raw reply	[flat|nested] 433+ messages in thread

* [9fans] (no subject)
@ 2003-06-21 19:15 David Presotto
  0 siblings, 0 replies; 433+ messages in thread
From: David Presotto @ 2003-06-21 19:15 UTC (permalink / raw)
  To: 9fans

	Has anyone had problems with ld.com?  On my old pentium, running ld.com
	gets as far as the greeting and then the screen clears and the machine
	reboots.  Browsing sourcedump it looks like boot/pc/l.s changed a constant
	from 0x08000 to 0x90000 (withough changing the comment that says 24K
	for page tables.)  Putting that value back seems to fix the problem,
	but am I causing some other problem by doing that?

Updated /sys/src/boot/pc and /386/{ld.com, 9pxeload, 9load}

By the way, the 24k in the comment refers to the size of the
tables, not the location they sit at.

I added an ifdef for 9pxeload to set it to a value that doesn't
overwrite where PXE bios sticks the downloaded program.  I feel
so unclean.


^ permalink raw reply	[flat|nested] 433+ messages in thread

* Re: [9fans] (no subject)
  2003-06-19 13:57 David Presotto
@ 2003-06-19 14:16 ` boyd, rounin
  0 siblings, 0 replies; 433+ messages in thread
From: boyd, rounin @ 2003-06-19 14:16 UTC (permalink / raw)
  To: 9fans

> ... because they're constantly updating the list.

yes they did and probably still do.

to the _letter of the law [DPL]_ it was/is pretty serious stuff.

from Network Security:

    The three golden rules of export control:

        1. The rules don't make any sense.
        2. If you get them wrong you go to jail.
        3. The boys on the hill don't have a sense of humour.



^ permalink raw reply	[flat|nested] 433+ messages in thread

* [9fans] (no subject)
@ 2003-06-19 13:57 David Presotto
  2003-06-19 14:16 ` boyd, rounin
  0 siblings, 1 reply; 433+ messages in thread
From: David Presotto @ 2003-06-19 13:57 UTC (permalink / raw)
  To: 9fans

I take it back, 772 is only the government end users list.  I'll
find the denied parties list.  I too used to have a pointer
but it doesn't work anymore, probably because they're constantly
updating thelist.


^ permalink raw reply	[flat|nested] 433+ messages in thread

* [9fans] (no subject)
@ 2003-05-10  5:24 Andrew Simmons
  0 siblings, 0 replies; 433+ messages in thread
From: Andrew Simmons @ 2003-05-10  5:24 UTC (permalink / raw)
  To: 9fans

I wasn't going to mention this here, but since Cardinal Presotto raised the
topic of toilet seats (and I hope he remembers to put it down again), has
anyone seen this, and is it for real?

http://www.microsoft.com/uk/press/content/presscentre/releases/2003/05/PR03049.a
sp

If real, it would tend to support the view I vaguely recall the blessed
pike expressing, that the innovation in systems software these days comes
from Microsoft.




^ permalink raw reply	[flat|nested] 433+ messages in thread

* Re: [9fans] (no subject)
  2003-04-21 19:06   ` Russ Cox
  2003-04-21 19:08     ` rsc
@ 2003-04-25 10:40     ` vic zandy
  1 sibling, 0 replies; 433+ messages in thread
From: vic zandy @ 2003-04-25 10:40 UTC (permalink / raw)
  To: 9fans

> i can't configure the vmware dhcp server
> to give out a static address (at least, not
> easily) so i just do it myself.

for what it's worth, here's how i get a static ip
address from the vmware 4 dhcp server on windows:

1. set the mac address of guest machine ethernet device
in the virtual machine .vmx config file
ethernet0.address = "00:50:56:00:00:01"

2. to
c:\Documents and Settings\All Users\Application Data\VMware\vmnetdhcp.conf
add this rule to map that mac address to the static ip:

host plan9 {
    hardware ethernet 00:50:56:00:00:01;
    fixed-address 192.168.11.10;
    option broadcast-address 192.168.11.255;
    option domain-name-servers 192.168.11.2;
    option domain-name "faircoin.net";
    option netbios-name-servers 192.168.11.2;
    option routers 192.168.11.2;
}

note that using the new vmware 4 virtual network editor
may nuke rules you add to vmnetdhcp.conf.

also, vmware 3 kept vmnetdhcp.conf in a different
location:  c:\WINDOWS\system32\vmnetdhcp.conf


^ permalink raw reply	[flat|nested] 433+ messages in thread

* Re: [9fans] (no subject)
  2003-04-21 19:06   ` Russ Cox
@ 2003-04-21 19:08     ` rsc
  2003-04-25 10:40     ` vic zandy
  1 sibling, 0 replies; 433+ messages in thread
From: rsc @ 2003-04-21 19:08 UTC (permalink / raw)
  To: 9fans

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

OOPS.  that was supposed to go to presotto.
doh.

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

From: "Russ Cox" <rsc@plan9.bell-labs.com>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] (no subject)
Date: Mon, 21 Apr 2003 15:06:15 -0400
Message-ID: <f5396431a28cc894930a4dc8cf33cae7@plan9.bell-labs.com>

this is /rc/bin/termrc.local from my laptop.
just a switch between a static ip address
and whatever i can get from dhcp.  a prompt
to select which one would be fine.  i used to
do that.

i can't configure the vmware dhcp server
to give out a static address (at least, not
easily) so i just do it myself.

if(aux/isvmware){
	ip/ipconfig -g 192.168.233.2 ether /net/ether0 192.168.233.51 255.255.255.0
	echo '	dom=.localdomain' >> /net/ndb
	echo '	dns=192.168.233.2' >>/net/ndb
	echo 'add 0 0 192.168.233.2' >>/net/iproute
}
if not
	ip/ipconfig ether /net/ether0

^ permalink raw reply	[flat|nested] 433+ messages in thread

* Re: [9fans] (no subject)
  2003-04-21 18:12 ` David Presotto
@ 2003-04-21 19:06   ` Russ Cox
  2003-04-21 19:08     ` rsc
  2003-04-25 10:40     ` vic zandy
  0 siblings, 2 replies; 433+ messages in thread
From: Russ Cox @ 2003-04-21 19:06 UTC (permalink / raw)
  To: 9fans

this is /rc/bin/termrc.local from my laptop.
just a switch between a static ip address
and whatever i can get from dhcp.  a prompt
to select which one would be fine.  i used to
do that.

i can't configure the vmware dhcp server
to give out a static address (at least, not
easily) so i just do it myself.

if(aux/isvmware){
	ip/ipconfig -g 192.168.233.2 ether /net/ether0 192.168.233.51 255.255.255.0
	echo '	dom=.localdomain' >> /net/ndb
	echo '	dns=192.168.233.2' >>/net/ndb
	echo 'add 0 0 192.168.233.2' >>/net/iproute
}
if not
	ip/ipconfig ether /net/ether0



^ permalink raw reply	[flat|nested] 433+ messages in thread

* Re: [9fans] (no subject)
  2003-04-21 17:54 bigfoot
@ 2003-04-21 18:12 ` David Presotto
  2003-04-21 19:06   ` Russ Cox
  0 siblings, 1 reply; 433+ messages in thread
From: David Presotto @ 2003-04-21 18:12 UTC (permalink / raw)
  To: 9fans

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

OOPS, that came out as my alternate identity...

Could you sent the stuff to presotto@closedmind.org?

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

From: bigfoot@ballkicker.info
To: 9fans@cse.psu.edu
Subject: [9fans] (no subject)
Date: Mon, 21 Apr 2003 13:54:56 -0400
Message-ID: <a0dc2475ca80b6fd6f5decbf910beb90@plan9.bell-labs.com>

Could everyone send me the procedures they use to connect to the internet?
That includes runnin ppp or pppoe and scripts you use with it, ipconfig
and things you tack on the end of your /net/ndb after configuring...

I'm trying to put together a wizard-like tool that makes it easier
for new users to get going vis a vis networking.  Especially for ppp,
I'ld like to have a bunch of scripts in /rc/bin/ipconf that just do
the right thing for various ISP's.

In the end, I'ld like to have a bunch of profiles which I can use
to come up with.  I alrady connect through so many ISP's that my
/rc/bin/termrc.local has a dozen different cases in it.  I'ld like
to standardize that so that you can answer a few questions and get
a new case added, including wavelan configuration and filling in
anything the dhcp or ppp doesn't do for you.

^ permalink raw reply	[flat|nested] 433+ messages in thread

* [9fans] (no subject)
@ 2003-04-21 17:54 bigfoot
  2003-04-21 18:12 ` David Presotto
  0 siblings, 1 reply; 433+ messages in thread
From: bigfoot @ 2003-04-21 17:54 UTC (permalink / raw)
  To: 9fans

Could everyone send me the procedures they use to connect to the internet?
That includes runnin ppp or pppoe and scripts you use with it, ipconfig
and things you tack on the end of your /net/ndb after configuring...

I'm trying to put together a wizard-like tool that makes it easier
for new users to get going vis a vis networking.  Especially for ppp,
I'ld like to have a bunch of scripts in /rc/bin/ipconf that just do
the right thing for various ISP's.

In the end, I'ld like to have a bunch of profiles which I can use
to come up with.  I alrady connect through so many ISP's that my
/rc/bin/termrc.local has a dozen different cases in it.  I'ld like
to standardize that so that you can answer a few questions and get
a new case added, including wavelan configuration and filling in
anything the dhcp or ppp doesn't do for you.


^ permalink raw reply	[flat|nested] 433+ messages in thread

* [9fans] (no subject)
@ 2003-04-19 13:02 David Presotto
  0 siblings, 0 replies; 433+ messages in thread
From: David Presotto @ 2003-04-19 13:02 UTC (permalink / raw)
  To: 9fans

Missed missed adding an "oldheaders" in dnresolve.c so that it didn't
work with /sys/src/9/ip/nudp.c.  Fixed and updated.


^ permalink raw reply	[flat|nested] 433+ messages in thread

* [9fans] (no subject)
@ 2003-02-25 12:40 Steve Simon
  0 siblings, 0 replies; 433+ messages in thread
From: Steve Simon @ 2003-02-25 12:40 UTC (permalink / raw)
  To: 9fans

Hi,

the Plan9 maths library does not appear to have erf()
(The error function), or bessel functions of any kind.

I can find several implementations on the net but does
anyone have any reccomendations for correct (and ideally fast)
example?

I am tempted to take the edition7 source - though
I don't know what kind of licience it is released under.

-Steve




^ permalink raw reply	[flat|nested] 433+ messages in thread

* Re: [9fans] (no subject)
  2003-02-24 16:52 Steve Simon
  2003-02-24 16:06 ` Wayne Walker
@ 2003-02-24 19:37 ` northern snowfall
  1 sibling, 0 replies; 433+ messages in thread
From: northern snowfall @ 2003-02-24 19:37 UTC (permalink / raw)
  To: steve.simon; +Cc: 9fans

RamFS is a nice clean and simple start.
Don




^ permalink raw reply	[flat|nested] 433+ messages in thread

* Re: [9fans] (no subject)
  2003-02-24 16:06 ` Wayne Walker
@ 2003-02-24 17:18   ` William Josephson
  0 siblings, 0 replies; 433+ messages in thread
From: William Josephson @ 2003-02-24 17:18 UTC (permalink / raw)
  To: 9fans

On Mon, Feb 24, 2003 at 10:06:37AM -0600, Wayne Walker wrote:
> If you plan on wirting a "unix-ish" file system, I think the SysV /
> Coherent  fs was fairly simple (as simple as inode/superblock/indirect
> block fs's go).  I've not looked at the actual linux or *BSD code for
> that, though.

If you're actually looking for an on-disk filesystem,
kfs or FreeBSD's FFS are probably good places to start.
I have read-only FFS+buffer cache for plan 9 lying
around here somewhere which I suppose I should finish;
it already serves its purpose for doing physical backup
a la Russ's "trimfat" for FAT filesystems, though.

But I suspect you are looking for a Plan 9 filesystem, so
something like ramfs, webfs, or nntpfs might be better
places to start.  Lib9p is also worth poking at, IMO.



^ permalink raw reply	[flat|nested] 433+ messages in thread

* [9fans] (no subject)
@ 2003-02-24 16:52 Steve Simon
  2003-02-24 16:06 ` Wayne Walker
  2003-02-24 19:37 ` northern snowfall
  0 siblings, 2 replies; 433+ messages in thread
From: Steve Simon @ 2003-02-24 16:52 UTC (permalink / raw)
  To: 9fans

Hi,

Any advice on the "best" (I guess I mean simple and clean)
filesystem to look at as I try once again to teach
myself to write fileservers?

-Steve


^ permalink raw reply	[flat|nested] 433+ messages in thread

* Re: [9fans] (no subject)
  2003-02-24 16:52 Steve Simon
@ 2003-02-24 16:06 ` Wayne Walker
  2003-02-24 17:18   ` William Josephson
  2003-02-24 19:37 ` northern snowfall
  1 sibling, 1 reply; 433+ messages in thread
From: Wayne Walker @ 2003-02-24 16:06 UTC (permalink / raw)
  To: 9fans; +Cc: 9fans

If you plan on wirting a "unix-ish" file system, I think the SysV /
Coherent  fs was fairly simple (as simple as inode/superblock/indirect
block fs's go).  I've not looked at the actual linux or *BSD code for
that, though.

If you are looking for much simpler file system stuff, the romfs driver
in linux should be farily small and clean.

I cd'd into /usr/src/linux/fs and it looks like I'm right romfs and
ramfs are both tiny.  sysv and minix are the simplest "unixish" fs's (by
code size).

[wwalker@nomad fs]$ du -ks * | sort -n -r | grep -v '\.c$'
3220    nls
908     jfs
740     reiserfs
588     hfs
512     intermezzo
344     udf
340     jffs2
296     ntfs
268     ext3
264     nfs
220     partitions
216     jbd
212     nfsd
200     jffs
200     hpfs
184     smbfs
176     ufs
168     lockd
168     ext2
156     umsdos
156     ncpfs
152     befs
144     devfs
136     proc
128     coda
116     freevxfs
116     affs
108     fat
104     sysv
104     isofs
84      adfs
72      minix
68      autofs
64      autofs4
56      qnx4
44      vfat
44      efs
36      openpromfs
36      bfs
32      cramfs
28      msdos
24      romfs
24      devpts
16      ramfs
8       Config.in
8       ChangeLog
4       Makefile

On Mon, Feb 24, 2003 at 04:52:02PM +0000, Steve Simon wrote:
> Hi,
>
> Any advice on the "best" (I guess I mean simple and clean)
> filesystem to look at as I try once again to teach
> myself to write fileservers?
>
> -Steve

--

Wayne Walker

www.broadq.com :)  Bringing digital video and audio to the living room


^ permalink raw reply	[flat|nested] 433+ messages in thread

* Re: [9fans] (no subject)
  2003-02-24 13:49 David Presotto
@ 2003-02-24 15:11 ` Sam
  0 siblings, 0 replies; 433+ messages in thread
From: Sam @ 2003-02-24 15:11 UTC (permalink / raw)
  To: 9fans

What list software are we using?  Is it smart
enough to be told to only bother filtering
new messages, ie, let all messages pertaining
to an existing (recent) thread through?  If
so, we could be a little more strict on the
filtering.

Cheers,

Sam

On Mon, 24 Feb 2003, David Presotto wrote:

> I just went through a thousand or so 9fans archived messages looking for spam.
> About 70% were html or had html attachments.  A few valid messages also
> had html attachments.  Just rejecting html would be helpful but
> still let a lot through.
>
> We could enter the arms race and throw an automated filter
> or go moderated (not really moderated but people filtered).
> The latter is the only one likely to be 100% effective, but
> a Bayesian filter might be good enough.  Even the flames on
> the net are stylized enough to be recognizable as real
> 9fans mail.  Of course even the Bayesian one needs a
> moderator(s) that will reclassify any misclassified stuff
> so that the filter will keep up with a changing world
> so some people will have to do extra work.
> However, it won't insert people delays in normal delivery.
>





^ permalink raw reply	[flat|nested] 433+ messages in thread

* [9fans] (no subject)
@ 2003-02-24 13:49 David Presotto
  2003-02-24 15:11 ` Sam
  0 siblings, 1 reply; 433+ messages in thread
From: David Presotto @ 2003-02-24 13:49 UTC (permalink / raw)
  To: 9fans

I just went through a thousand or so 9fans archived messages looking for spam.
About 70% were html or had html attachments.  A few valid messages also
had html attachments.  Just rejecting html would be helpful but
still let a lot through.

We could enter the arms race and throw an automated filter
or go moderated (not really moderated but people filtered).
The latter is the only one likely to be 100% effective, but
a Bayesian filter might be good enough.  Even the flames on
the net are stylized enough to be recognizable as real
9fans mail.  Of course even the Bayesian one needs a
moderator(s) that will reclassify any misclassified stuff
so that the filter will keep up with a changing world
so some people will have to do extra work.
However, it won't insert people delays in normal delivery.


^ permalink raw reply	[flat|nested] 433+ messages in thread

* [9fans] (no subject)
       [not found] <2ba8f07c025d45604e247b27a02d4123@plan9.bell-labs.com>
@ 2003-02-23  6:14 ` Leendert van Doorn
  0 siblings, 0 replies; 433+ messages in thread
From: Leendert van Doorn @ 2003-02-23  6:14 UTC (permalink / raw)
  To: Peter Bosch; +Cc: philw, 9fans


I was indeed an intern but in 1995, I was also the author of the x86
port of Amoeba and wrote that timer code around 1990. My code never
contained the offending cpuspeed routine. In fact, I just looked at
the RCS repository that still exists at the VU and it isn't in there
either. Who ever added cpuspeed to this file, it was not one of the
VU Amoeba developers.

	Leendert


# From: philw@entrisphere.com
# Date: Sat Feb 22 15:35:26 EST 2003
# To: 9fans@cse.psu.edu
# Subject: RE: [9fans] A quite amusing thing...
#
#
# Leendert van Doorn was a summer student at the labs that year I think
#
# phil
#
# 	-----Original Message-----
# 	From: Russ Cox [mailto:rsc@plan9.bell-labs.com]
# 	Sent: Sat 2/22/2003 12:30 PM
# 	To: 9fans@cse.psu.edu
# 	Cc:
# 	Subject: Re: [9fans] A quite amusing thing...
#
#
#
# 	That _is_ fairly amusing.
#
# 	We've had a form of that code (including the big
# 	comment) in our source tree since July 15, 1994.
# 	But the 1994 code didn't have the for loop to run
# 	until loops got big enough (it assumed 10000 was
# 	enough) and it didn't have all the clock frequency
# 	stuff (which got added later).
#
# 	So either Plan 9 copied Amoeba back in 1994 (before
# 	the original project was terminated) and has been
# 	secretly tracking the code since then, or Amoeba copied
# 	Plan 9 some time later after the code was changed to
# 	look more like it does today.  I know where my money is.
#
# 	Also, I downloaded the original Amoeba code and the
# 	pit.c looked nothing like the Plan 9 code as of 1996.
#
# 	Below you'll find Plan 9's clock.c from 1994, Amoeba's
# 	pit.c from 1996, and Amoeba's pit.c from today.
# 	Note the difference between the last two.  Sure looks like
#
# 	 * Stefan Bosse (12/1999-7/2000)
# 	 * sbosse@physik.uni-bremen.de
# 	 *
# 	 * -> pit_hw_milli now default routine with 1ms resolution
# 	 * -> cpuspeed measurement and delay loop reference
#
# 	copied the Plan 9 code.
#
# 	> Hmm... It is possible too that Amoeba developer's have copied this co
de
# 	> but I doubt it.
#
# 	Why?
#
# 	Russ
#
# 	/* --rw-rw-r-- M 3014 jmk sys 2766 Jul 15  1994 sys/src/brazil/pc/clock
.c */
#
# 	void
# 	clockinit(void)
# 	{
# 	        ulong x, y;     /* change in counter */
# 	        ulong cycles, loops;
#
# 	        /*
# 	         *  set vector for clock interrupts
# 	         */
# 	        setvec(Clockvec, clock, 0);
#
# 	        /*
# 	         *  set clock for 1/HZ seconds
# 	         */
# 	        outb(Tmode, Load0|Square);
# 	        outb(T0cntr, (Freq/HZ));        /* low byte */
# 	        outb(T0cntr, (Freq/HZ)>>8);     /* high byte */
#
# 	        /*
# 	         *  measure time for the loop
# 	         *
# 	         *                      MOVL    loops,CX
# 	         *      aaml1:          AAM
# 	         *                      LOOP    aaml1
# 	         *
# 	         *  the time for the loop should be independent from external
# 	         *  cache's and memory system since it fits in the execution
# 	         *  prefetch buffer.
# 	         *
# 	         */
# 	        loops = 10000;
# 	        outb(Tmode, Latch0);
# 	        x = inb(T0cntr);
# 	        x |= inb(T0cntr)<<8;
# 	        aamloop(loops);
# 	        outb(Tmode, Latch0);
# 	        y = inb(T0cntr);
# 	        y |= inb(T0cntr)<<8;
# 	        x -= y;
#
# 	        /*
# 	         *  counter  goes at twice the frequency, once per transition,
# 	         *  i.e., twice per the square wave
# 	         */
# 	        x >>= 1;
#
# 	        /*
# 	         *  figure out clock frequency and a loop multiplier for delay(
).
# 	         */
# 	        switch(cputype = x86()){
# 	        case 386:
# 	                cycles = 30;
# 	                break;
# 	        case 486:
# 	                cycles = 24;
# 	                break;
# 	        default:
# 	                cycles = 23;
# 	                break;
# 	        }
# 	        cpufreq = (cycles*loops) * (Freq/x);
# 	        loopconst = (cpufreq/1000)/cycles;      /* AAM+LOOP's for 1 ms
*/
# 	}
#
#
# 	/*      @(#)pit.c       1.4     94/04/06 09:23:12 */
# 	/*
# 	 * Copyright 1994 Vrije Universiteit, The Netherlands.
# 	 * For full copyright and restrictions on use see the file COPYRIGHT in
 the
# 	 * top level of the Amoeba distribution.
# 	 */
#
# 	/*
# 	 * pit.c
# 	 *
# 	 * Driver for the 8254 timer (PIT). The i8254 timer has three timer cha
nnels
# 	 * of which only one (channel 0) is available for timer interrupts. The
 other
# 	 * channels are used for the speaker and memory refresh.
# 	 *
# 	 * Author:
# 	 *      Leendert van Doorn
# 	 */
# 	#include <amoeba.h>
# 	#include <assert.h>
# 	INIT_ASSERT
# 	#include <fault.h>
# 	#include <bool.h>
# 	#include "sys/proto.h"
# 	#include "i386_proto.h"
# 	#include "pit.h"
#
# 	#ifndef PIT_DEBUG
# 	#define PIT_DEBUG       0
# 	#endif
#
# 	static int pit_debug;                   /* current debug level */
#
# 	#ifdef notyet
# 	static uint32 pit_hw_milli();
# 	#endif
# 	static void pit_intr();
#
# 	/*
# 	 * Initialize channel 0 of the i8254A timer
# 	 */
# 	void
# 	pit_init()
# 	{
# 	    register uint32 counter = (PIT_FREQ * PIT_INTERVAL) / 1000L;
#
# 	#ifndef NDEBUG
# 	    if ((pit_debug = kernel_option("pit")) == 0)
# 	        pit_debug = PIT_DEBUG;
# 	    if (pit_debug > 1)
# 	        printf("pit_init(), pit_interval = 0x%x (%d), counter = %x\n",
# 	            PIT_INTERVAL, PIT_INTERVAL, counter);
# 	#endif
#
# 	    /* set timer to run continuously */
# 	    assert(counter <= 0xFFFF);
# 	    out_byte(PIT_MODE, PIT_MODE3);
# 	    out_byte(PIT_CH0, (int) (counter & 0xFF));
# 	    out_byte(PIT_CH0, (int) ((counter >> 8) & 0xFF));
#
# 	#ifdef notyet
# 	    /* I still have to thoroughly test this */
# 	    set_hw_milli(pit_hw_milli);
# 	#endif
#
# 	    setirq(PIT_IRQ, pit_intr);
# 	    pic_enable(PIT_IRQ);
# 	}
#
# 	/*
# 	 * Read i8254's channel 0 counter. The counter decrements at twice the
# 	 * timer frequency (one full cycle for each half of a square wave).
# 	 */
# 	uint16
# 	pit_channel0()
# 	{
# 	    register uint16 counter;
#
# 	    out_byte(PIT_MODE, PIT_LC);
# 	    counter = in_byte(PIT_CH0), counter |= (in_byte(PIT_CH0) << 8);
# 	    return counter;
# 	}
#
# 	/*
# 	 * Delay for at least ``msec'' milli seconds
# 	 */
# 	void
# 	pit_delay(msec)
# 	    int msec;
# 	{
# 	    register uint16 current, previous, diff;
# 	    register uint32 total;
#
# 	    /*
# 	     * The counter decrements at twice the timer frequency
# 	     * (one full cycle for each half of a square wave).
# 	     */
# 	    diff = 100; /* just in case */
# 	    total = (uint32) msec * (2 * PIT_FREQ / 1000);
# 	    previous = pit_channel0();
# 	    for (;;) {
# 	        current = pit_channel0();
# 	        if (current < previous)
# 	            diff = previous - current;
# 	        if (diff >= total)
# 	            break;
# 	        total -= diff;
# 	        previous = current;
# 	    }
# 	}
#
# 	#ifdef notyet
# 	/*
# 	 * Return number of actual milli-seconds that have passed
# 	 */
# 	static uint32
# 	pit_hw_milli()
# 	{
# 	    extern uint32 milli_uptime;
# 	    register uint32 milli;
# 	    register int flags;
# 	    uint16 counter;
# 	    int status;
#
# 	    flags = get_flags(); disable();
# 	    out_byte(PIT_MODE, PIT_RB);
# 	    out_byte(PIT_MODE, 0xC2);
# 	    status = in_byte(PIT_CH0);
# 	    counter = in_byte(PIT_CH0), counter |= (in_byte(PIT_CH0) << 8);
# 	    milli = milli_uptime + (PIT_INTERVAL / 2) *
# 	        (counter / (PIT_FREQ * PIT_INTERVAL) / 1000L);
# 	    if ((status & 0x80) == 0) milli += PIT_INTERVAL/2;
# 	    set_flags(flags);
# 	    return milli;
# 	}
# 	#endif
#
# 	/*
# 	 * The actual clock interrupt
# 	 */
# 	/* ARGSUSED */
# 	static void
# 	pit_intr(reason, frame)
# 	    int reason;
# 	    struct fault *frame;
# 	{
# 	    void sweeper_run();
# 	    void flp_motoroff();
# 	    extern int motortime;
#
# 	#ifdef MCA
# 	    /* ps/2 clock needs to be told to stop interrupting */
# 	    out_byte(0x61, in_byte(0x61) | 0x80);
# 	#endif
#
# 	    enqueue(sweeper_run, (long) PIT_INTERVAL);
#
# 	#if (defined(ISA) || defined(MCA)) && !defined(NOFLOPPY)
# 	    /* stop running floppy motor */
# 	    if (motortime != 0 && --motortime == 0)
# 	        flp_motoroff();
# 	#endif
# 	}
#
#
# 	/*
# 	 * This file is part of the FIREBALL AMOEBA System.
# 	 *
# 	 *
# 	 * Last modified:
# 	 *              18/02/01
# 	 *
# 	 * Stefan Bosse (12/1999-7/2000)
# 	 * sbosse@physik.uni-bremen.de
# 	 *
# 	 * -> pit_hw_milli now default routine with 1ms resolution
# 	 * -> cpuspeed measurement and delay loop reference
# 	 *
# 	 *
# 	 *
# 	 * FIREBALL AMOEBA is free software; you can redistribute it and/or
# 	 * modify it under the terms of the GNU General Public License as
# 	 * published by the Free Software Foundation; version 2.
# 	 *
# 	 * The FIREBALL AMOEBA is distributed in the hope that it will be usefu
ll,
# 	 * but WITHOUT ANY WARRANTY; without even implied warranty of
# 	 * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
# 	 * General Public License for more details.
# 	 *
# 	 * Original Copyright: Vrije Universiteit, The Netherlands.
# 	 */
#
#
#
#
# 	/*
# 	 * pit.c
# 	 *
# 	 * Driver for the 8254 timer (PIT). The i8254 timer has three timer cha
nnels
# 	 * of which only one (channel 0) is available for timer interrupts. The
 other
# 	 * channels are used for the speaker and memory refresh.
# 	 *
# 	 * Author:
# 	 *      Leendert van Doorn
# 	 */
#
#
# 	#include <amoeba.h>
# 	#include <assert.h>
# 	INIT_ASSERT
# 	#include <fault.h>
# 	#include <bool.h>
# 	#include "sys/proto.h"
# 	#include "i386_proto.h"
# 	#include <irq.h>
# 	#include "pit.h"
# 	#include <cpu.h>
#
# 	#ifndef PIT_DEBUG
# 	#define PIT_DEBUG       0
# 	#endif
#
# 	#ifdef STATISTICS
# 	static unsigned long pit_hw_milli_count=0;
# 	static unsigned long pit_hw_milli_wrap1=0;
# 	static unsigned long pit_hw_milli_wrap2=0;
# 	static unsigned long pit_delay_count=0;
# 	#endif
#
# 	static int pit_debug;                   /* current debug level */
# 	static int initialized=0;
#
# 	#ifdef PIT_HW_MILLI
# 	static uint32 pit_hw_milli();
# 	#endif
# 	static void pit_intr();
#
# 	/*
# 	 * milli_uptime will be incremented in sweeper_run, but it's delayed
# 	 * because of enqueue() handling.
# 	 * milli_uptime should be handled ***here***.
# 	 * Hack: Local we use timer_ticks for pit_hw_milli(), incremented in lo
w
# 	 * level ISR below...
# 	 */
# 	unsigned long timer_ticks=0;
#
# 	/* for time monotony checking; we have a serious problem with
# 	 * this faulty timer hardware
# 	 */
# 	static unsigned long last_time=0;
#
# 	/*
# 	 * Initialize channel 0 of the i8254A timer
# 	 */
# 	void
# 	pit_init()
# 	{
# 	    register uint32 counter = (PIT_FREQ * PIT_INTERVAL) / 1000L;
#
#
# 	    if(!initialized)
# 	    {
#
# 	        initialized=1;
# 	#ifndef NDEBUG
# 	        if ((pit_debug = kernel_option("pit")) == 0)
# 	                pit_debug = PIT_DEBUG;
# 	        if (pit_debug > 1)
# 	                printf("pit_init(), pit_interval = 0x%x (%d), counter =
 %x\n",
# 	                       PIT_INTERVAL, PIT_INTERVAL, counter);
# 	#endif
#
# 	        /* set timer to run continuously */
# 	        assert(counter <= 0xFFFF);
#
# 	        if(check_region(PIT_CH0,4)<0)
# 	                panic("Some fool allocated timer ports");
# 	        request_region(PIT_CH0,4,"PIT");
#
# 	        out_byte(PIT_MODE, PIT_MODE2);
#
# 	        out_byte(PIT_CH0, (int) (counter & 0xFF));
# 	        out_byte(PIT_CH0, (int) ((counter >> 8) & 0xFF));
#
# 	#ifdef PIT_HW_MILLI
# 	        /* I still have to thoroughly test this */
# 	        /* SB: still timer wrap problems; but time monotonie is gurante
ed */
# 	        set_hw_milli(pit_hw_milli);
# 	#endif
#
# 	        if(request_irq(PIT_IRQ,
# 	                       pit_intr,
# 	                       SA_NORMAL,
# 	                       "PIT",
# 	                       (void *)NULL)!=0)
# 	                panic("Some fool allocated timer irq");
#
# 	        enable_irq(PIT_IRQ);
# 	        /*pic_enable(PIT_IRQ);*/
# 	    }
# 	}
#
# 	/*
# 	 * Read i8254's channel 0 counter. The counter decrements at twice the
# 	 * timer frequency (one full cycle for each half of a square wave).
# 	 */
# 	uint16
# 	pit_channel0()
# 	{
# 	    register uint16 counter;
# 	    unsigned long flags;
#
# 	    save_flags(flags);cli();
# 	    out_byte(PIT_MODE, PIT_LC);
# 	    counter = in_byte(PIT_CH0), counter |= (in_byte(PIT_CH0) << 8);
# 	    restore_flags(flags);
# 	    return counter;
# 	}
#
# 	/*
# 	 * Delay for at least ``msec'' milli seconds
# 	 */
# 	void
# 	pit_delay(msec)
# 	    int msec;
# 	{
# 	    register uint16 current, previous, diff;
# 	    register uint32 total;
#
#
# 	#ifdef STATISTICS
# 	    pit_delay_count++;
# 	#endif
# 	    /*
# 	     * The counter decrements at twice the timer frequency
# 	     * (one full cycle for each half of a square wave).
# 	     */
# 	    diff = 100; /* just in case */
# 	    total = (uint32) msec * (PIT_FREQ / 1000);
# 	    previous = pit_channel0();
# 	    for (;;) {
# 	        current = pit_channel0();
# 	        if (current < previous)
# 	            diff = previous - current;
# 	        if (diff >= total)
# 	            break;
# 	        total -= diff;
# 	        previous = current;
# 	    }
# 	}
#
#
# 	#ifdef PIT_HW_MILLI
# 	/*
# 	 * Return number of actual milli-seconds that have passed
# 	 */
# 	static uint32
# 	pit_hw_milli()
# 	{
# 	    extern uint32 milli_uptime;
# 	    register uint32 milli;
# 	    uint16 counter,counter2;
# 	    int status,status2;
# 	    unsigned long flags;
# 	    unsigned long ticks=timer_ticks;
#
#
#
# 	#ifdef STATISTICS
# 	    pit_hw_milli_count++;
# 	#endif
#
# 	    save_flags(flags);cli();
# 	    /* Select timer0 and latch counter value. */
# 	    out_byte(PIT_MODE,PIT_LC);
# 	    counter = in_byte(PIT_CH0), counter |= (in_byte(PIT_CH0) << 8);
# 	    restore_flags(flags);
#
# 	    milli = timer_ticks*PIT_INTERVAL +
# 	        (1000*(((PIT_FREQ*PIT_INTERVAL)/1000) - counter )/(PIT_FREQ) );
#
#
# 	    /* check time monotony */
# 	    if(milli<last_time)
# 	    {
# 	#ifdef STATISTICS
# 	        pit_hw_milli_wrap1++;
# 	#endif
# 	        if(ticks<timer_ticks)
# 	        {
# 	                milli=timer_ticks*PIT_INTERVAL;
# 	#ifdef STATISTICS
# 	                pit_hw_milli_wrap2++;
# 	#endif
# 	        }
# 	        else
# 	                milli=last_time;
# 	    }
#
#
# 	    last_time=milli;
#
#
# 	    if(ticks<timer_ticks) /* Between start and here pit_intr was called
 */
# 	        return (timer_ticks*PIT_INTERVAL);
# 	    else
# 	        return milli;
# 	}
# 	#endif
#
# 	/*
# 	 * The actual clock interrupt
# 	 */
# 	/* ARGSUSED */
# 	#ifdef __KERNEL__       /* Work with Linux-ISR  */
# 	static void
# 	pit_intr(reason,dev_idt,frame)
# 	    int reason;
# 	    void *dev_idt;
# 	    struct fault *frame;
# 	#else
# 	static void
# 	pit_intr(reason,frame)
# 	    int reason;
# 	    struct fault *frame;
# 	#endif
# 	{
# 	    void sweeper_run();
# 	    void flp_motoroff();
# 	    extern int motortime;
#
#
# 	    timer_ticks++;
#
# 	#ifdef MCA
# 	    /* ps/2 clock needs to be told to stop interrupting */
# 	    out_byte(0x61, in_byte(0x61) | 0x80);
# 	#endif
#
# 	    enqueue(sweeper_run, (long) PIT_INTERVAL);
#
# 	#if (defined(ISA) || defined(MCA)) && !defined(NOFLOPPY)
# 	    /* stop running floppy motor */
# 	    if (motortime != 0 && --motortime == 0)
# 	        flp_motoroff();
# 	#endif
# 	}
#
# 	#ifdef STATISTICS
# 	int
# 	pit_stat(begin,end)
# 	char    *begin;
# 	char    *end;
# 	{
# 	        char *p;
# 	        int     i;
#
# 	        p=bprintf(begin,end,"**** Hardware Timer statistics *****\n");
# 	        p=bprintf(p,end,"pit_hw_milli() calls: %d\n",
# 	                  pit_hw_milli_count);
# 	        p=bprintf(p,end,"pit_hw_milli time wrap check failed: %d\n",
# 	                  pit_hw_milli_wrap1);
# 	        p=bprintf(p,end,"pit_hw_milli dirty ticks increment: %d\n",
# 	                  pit_hw_milli_wrap2);
#
# 	        p=bprintf(p,end,"pit_delay() calls: %d\n",
# 	                  pit_delay_count);
#
# 	        return p-begin;
# 	}
# 	#endif
#
# 	/* For cpu speed measurement. We need timer access. */
#
# 	void
# 	cpuspeed(int aalcycles, int havecycleclock)
# 	{
# 	        int cpufreq, loops, incr, x, y;
# 	        unsigned long ax1,dx1,ax2,dx2,a,b;
#
# 	        pit_init();
#
# 	        /* find biggest loop that doesn't wrap */
# 	        incr = 16000000/(aalcycles*HZ*2);
# 	        x = 2000;
# 	        for(loops = incr; loops < 64*1024; loops += incr) {
#
# 	                /*
# 	                 *  measure time for the loop
# 	                 *
# 	                 *                      MOVL    loops,CX
# 	                 *      aaml1:          AAM
# 	                 *                      LOOP    aaml1
# 	                 *
# 	                 *  the time for the loop should be independent of exte
rnal
# 	                 *  cache and memory system since it fits in the execut
ion
# 	                 *  prefetch buffer.
# 	                 *
# 	                 */
#
# 	                /* Beware of counter reset's (wraps)... */
#
# 	                /* Read the cpu internal clock if available */
# 	                if(havecycleclock)
# 	                        rdmsr(0x10, &ax1,&dx1);
# 	                x = (int)pit_channel0();
#
# 	                aamloop(loops);
#
# 	                if(havecycleclock)
# 	                        rdmsr(0x10, &ax2,&dx2);
#
# 	                y = (int)pit_channel0();
#
# 	                x -= y;
#
# 	                if(x < 0)
# 	                        x += PIT_FREQ/PIT_HZ;
#
# 	                if(x > PIT_FREQ/(3*PIT_HZ))
# 	                        break;
# 	        }
#
# 	        /*
# 	         *  figure out clock frequency and a loop multiplier for delay(
).
# 	         *  n.b. counter goes up by 2*PIT_FREQ
# 	         */
# 	        cpufreq = loops*((aalcycles*PIT_FREQ)/x);
# 	        cpu.loopconst = (cpufreq/1000)/aalcycles; /* AAM+LOOP's for 1ms
 */
#
# 	        /* check aalcycle value */
# 	        if(kernel_option("cud") == 1)
# 	                printf("cpuspeed: aalcycle MHz=%d\n",
# 	                        (cpufreq + cpufreq/200)/1000000);
#
# 	        if(havecycleclock){
#
#
# 	                if(dx2 == dx1)
# 	                        b = (ax2-ax1);
# 	                else    /* counter wrap */
# 	                        b = (ax2+0xffffffff-ax1);
#
# 	                b /= x;
# 	                b *= PIT_FREQ;
#
#
# 	                /*
# 	                 *  round to the nearest megahz
# 	                 */
# 	                cpu.cpumhz = (b+500000)/1000000L;
# 	                cpu.cpuhz = b;
# 	        } else {
# 	                /*
# 	                 *  add in possible 0.5% error and convert to MHz
# 	                 */
# 	                cpu.cpumhz = (cpufreq + cpufreq/200)/1000000;
# 	                cpu.cpuhz = cpufreq;
# 	        }
#
#
# 	}
#
#
#
#
# ===> 2/ (multipart/mixed) [inline]
#
#
# The following attachment had content that we can't
# prove to be harmless.  To avoid possible automatic
# execution, we changed the content headers.
# The original header was:
#
# 	Content-Type: application/ms-tnef;
# 	name="winmail.dat"
# 	Content-Transfer-Encoding: base64
#
# ===> 2/2/ (application/octet-stream) [file]
# 	cp /mail/fs/mbox/68/2/2/body /usr/pb/winmail.dat.suspect
#

--
Leendert van Doorn                                    <leendert@watson.ibm.com>
IBM T.J. Watson Research Center                       (914) 784-7831
30 Saw Mill River Road, Hawthorne, NY 10532


^ permalink raw reply	[flat|nested] 433+ messages in thread

* [9fans] (no subject)
@ 2003-02-17 15:30 Steve Simon
  0 siblings, 0 replies; 433+ messages in thread
From: Steve Simon @ 2003-02-17 15:30 UTC (permalink / raw)
  To: 9fans

Subject pcflop, bzroot.8 bzfs.root.8

Him

I'am trying to build an install floppy but the mkfile doesn't
have rules to build either bzroot.8 nor bzfs.root.8.

Where do they come from.

-Steve


^ permalink raw reply	[flat|nested] 433+ messages in thread

* [9fans] (no subject)
@ 2003-02-14 16:19 Steve Simon
  0 siblings, 0 replies; 433+ messages in thread
From: Steve Simon @ 2003-02-14 16:19 UTC (permalink / raw)
  To: 9fans

Hi all,

Are there any know problems with the mouse
cursor and the Matrox G400 ? I am trying to
another install and cannot see the mouse cursor
at all (I don't think its the mouse causing
problems - even though its a serial one :-).

I saw there where problems when the driver was first
written on the archives but that was years ago.

Any thoughts anyone?

-Steve


^ permalink raw reply	[flat|nested] 433+ messages in thread

* [9fans] (no subject)
@ 2003-02-12 15:41 David Presotto
  0 siblings, 0 replies; 433+ messages in thread
From: David Presotto @ 2003-02-12 15:41 UTC (permalink / raw)
  To: 9fans

I changed smtpd to avoid some masquerading by spammers.  It
makes sure that the envelope sender address cannot be from
one of your domains unless the mail is comming from a trusted
address.  It is turned on by the same flag that disallows
blind relaying (-f on the commad line or 'norelay on' in the
config file).

It still needs a bit of work, i.e., I should also check the From:
address in the message itself.  I just wanted to take it one
step at a time.

Complaints to me.


^ permalink raw reply	[flat|nested] 433+ messages in thread

* [9fans] (no subject)
@ 2003-02-12 15:37 David Presotto
  0 siblings, 0 replies; 433+ messages in thread
From: David Presotto @ 2003-02-12 15:37 UTC (permalink / raw)
  To: 9fans

Fixed a bug in imap4d that was sticking an extra header in to the mail body
when you accessed it via Netscape's mailer.  This also made it impossible
to look at some attachments unless you saved them first.  The fix is both
in /sys/src/cmd/upas/fs and /sys/src/cmd/ip/imap4d.  It essentially involves
taking code out.


^ permalink raw reply	[flat|nested] 433+ messages in thread

* [9fans] (no subject)
@ 2003-02-12 15:34 David Presotto
  0 siblings, 0 replies; 433+ messages in thread
From: David Presotto @ 2003-02-12 15:34 UTC (permalink / raw)
  To: 9fans

I updates kernel code on sources with window scaling.  The scaling is
automatic;

	if your interface > 100 mbps, you get a 512k window
	if your interface > 10 mbps, you get a 128k window
	otherwise, no scaling except what the other side requests

It seems to have a significant effect in our 1GB intel interfaces,
none elsewhere.  That implies that our bandwidth*rtt product is
sometimes > 64K.  Take it for what its worth.  It moved a single
TCP connection on our test machines from 28 MBps to 50 MBps.

If you have problems, tell me.


^ permalink raw reply	[flat|nested] 433+ messages in thread

* Re: [9fans] (no subject)
  2003-02-10 17:20 Steve Simon
@ 2003-02-10 18:26 ` Russ Cox
  0 siblings, 0 replies; 433+ messages in thread
From: Russ Cox @ 2003-02-10 18:26 UTC (permalink / raw)
  To: 9fans

> Anyone have a simple example of the use of webfs?
> I cannot see what it gives over hget.

Not much, really, except cookies by default (though
webcookies will let hget do the same, now).  It's a
building block for web browsers that never happened,
not a useful standalone tool by itself.

Russ


^ permalink raw reply	[flat|nested] 433+ messages in thread

* [9fans] (no subject)
@ 2003-02-10 17:20 Steve Simon
  2003-02-10 18:26 ` Russ Cox
  0 siblings, 1 reply; 433+ messages in thread
From: Steve Simon @ 2003-02-10 17:20 UTC (permalink / raw)
  To: 9fans

Hi,

Anyone have a simple example of the use of webfs?
I cannot see what it gives over hget.

-Steve


^ permalink raw reply	[flat|nested] 433+ messages in thread

* [9fans] (no subject)
@ 2002-12-03  9:02 Ian Dichkovsky
  0 siblings, 0 replies; 433+ messages in thread
From: Ian Dichkovsky @ 2002-12-03  9:02 UTC (permalink / raw)
  To: 9fans

Hello, Russ!
You wrote  on Thu, 28 Nov 2002 02:34:30 GMT:

RC> When you do your next pull, every binary
RC> on your system will be updated.
RC> (You can also use the "bleeding edge" update CD on
RC> the updates web page, after it gets regenerated
RC> tomorrow morning at 5am EST; it's probably
RC> less to download.)

Could you tell me where is updates page ?
Here ?
http://plan9.bell-labs.com/plan9dist/ureg.html

Is there any information on the page about date of update CD ?
At what time (GMT) regular update occurs ? (11:46 -4 GMT ?)

P.S. Sorry for bad English.

Best regards,
Ian Dichkovsky, mailto: ntokay at org lviv net, ICQ 83146271



^ permalink raw reply	[flat|nested] 433+ messages in thread

* Re: [9fans] (no subject)
@ 2002-12-01 20:33 bwc
  0 siblings, 0 replies; 433+ messages in thread
From: bwc @ 2002-12-01 20:33 UTC (permalink / raw)
  To: 9fans

I think it was the comment about auto mechanic.  Time was a mechanic could
make a machine.  Now they just replace what the computer tell them to.

 Brantley


^ permalink raw reply	[flat|nested] 433+ messages in thread

* Re: [9fans] (no subject)
@ 2002-12-01 17:38 Skip Tavakkolian
  0 siblings, 0 replies; 433+ messages in thread
From: Skip Tavakkolian @ 2002-12-01 17:38 UTC (permalink / raw)
  To: 9fans

> interesting though unfair to click and clack

Did she say something about the Tappet Brothers? I missed it.

I guess this would not be a good time to suggest fswiz, the filesystem
wizard?



^ permalink raw reply	[flat|nested] 433+ messages in thread

* [9fans] (no subject)
@ 2002-12-01 15:46 presotto
  0 siblings, 0 replies; 433+ messages in thread
From: presotto @ 2002-12-01 15:46 UTC (permalink / raw)
  To: 9fans

interesting though unfair to click and clack

    http://dir.salon.com/21st/feature/1998/05/cov_12feature.html
	http://dir.salon.com/tech/feature/1998/05/13/feature/index.html



^ permalink raw reply	[flat|nested] 433+ messages in thread

* Re: [9fans] (no subject)
@ 2002-11-19 20:04 presotto
  0 siblings, 0 replies; 433+ messages in thread
From: presotto @ 2002-11-19 20:04 UTC (permalink / raw)
  To: 9fans

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

The original filter example sends the mail from /dev/null.  We have
	local!/dev/null		|		"cat > /dev/null"
in our rewrite file.  You could do the same.

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

From: George Michaelson <ggm@apnic.net>
To: 9fans@cse.psu.edu
Cc: bwc@coraid.com
Subject: Re: [9fans] (no subject)
Date: Wed, 20 Nov 2002 05:50:44 +1000
Message-ID: <20021120055044.0818f856.ggm@apnic.net>

On Tue, 19 Nov 2002 14:36:14 -0500 bwc@coraid.com wrote:

> Subuject: upas filtering question
>
> As the mailing list knows (sorry again), I yesterday installed the
> script /sys/src/cmd/upas/filterkit/pipeto.sample.  Besides
> annoying this and other email lists because I got the syntax of
> the _pattern file wrong, I now have a battle with some spammer.
> I bounce to them, they bounce to me, etc, etc.  How do I stop
> this vicious loop...vicious loop...vicious loop...
>
>  Brantley


stop bouncing. blackhole. about 3 iterations later (or however deep your
backlogged SMTP mail is, both locally and at intermediate delivery points)
it ends.

We do this all the time, for bouncing ticketing system mails between us and
our clients.

-George

^ permalink raw reply	[flat|nested] 433+ messages in thread

* Re: [9fans] (no subject)
  2002-11-19 19:36 bwc
@ 2002-11-19 19:50 ` George Michaelson
  0 siblings, 0 replies; 433+ messages in thread
From: George Michaelson @ 2002-11-19 19:50 UTC (permalink / raw)
  To: 9fans; +Cc: bwc

On Tue, 19 Nov 2002 14:36:14 -0500 bwc@coraid.com wrote:

> Subuject: upas filtering question
>
> As the mailing list knows (sorry again), I yesterday installed the
> script /sys/src/cmd/upas/filterkit/pipeto.sample.  Besides
> annoying this and other email lists because I got the syntax of
> the _pattern file wrong, I now have a battle with some spammer.
> I bounce to them, they bounce to me, etc, etc.  How do I stop
> this vicious loop...vicious loop...vicious loop...
>
>  Brantley


stop bouncing. blackhole. about 3 iterations later (or however deep your
backlogged SMTP mail is, both locally and at intermediate delivery points)
it ends.

We do this all the time, for bouncing ticketing system mails between us and
our clients.

-George


^ permalink raw reply	[flat|nested] 433+ messages in thread

* [9fans] (no subject)
@ 2002-11-19 19:36 bwc
  2002-11-19 19:50 ` George Michaelson
  0 siblings, 1 reply; 433+ messages in thread
From: bwc @ 2002-11-19 19:36 UTC (permalink / raw)
  To: 9fans

Subuject: upas filtering question

As the mailing list knows (sorry again), I yesterday installed the
script /sys/src/cmd/upas/filterkit/pipeto.sample.  Besides
annoying this and other email lists because I got the syntax of
the _pattern file wrong, I now have a battle with some spammer.
I bounce to them, they bounce to me, etc, etc.  How do I stop
this vicious loop...vicious loop...vicious loop...

 Brantley


^ permalink raw reply	[flat|nested] 433+ messages in thread

* Re: [9fans] (no subject)
@ 2002-11-19  1:44 bwc
  0 siblings, 0 replies; 433+ messages in thread
From: bwc @ 2002-11-19  1:44 UTC (permalink / raw)
  To: 9fans

Ooops.  Really sorry about that.  I put the fancy filter in place but
my _pattern file was built from the From lines in may saved email.
They were in system!user not user@system.  Looks like the mail bounced
a few times before I got it fixed.

Again, sorry.

 Brantley


^ permalink raw reply	[flat|nested] 433+ messages in thread

* [9fans] (no subject)
@ 2002-11-18 21:40 bwc
  0 siblings, 0 replies; 433+ messages in thread
From: bwc @ 2002-11-18 21:40 UTC (permalink / raw)
  To: 9fans

I've been getting so much junk mail that I'm resorting to
a draconian mechanism to avoid the mail.  In order
to make sure that there's a real person sending mail, I'm
asking you to explicitly enable access.  To do that, send
mail to bwc at this domain with the token:
	PGyKN
in the subject of your mail message.  After that, you
shouldn't get any bounces from me.  Sorry if this is
an inconvenience.

----------------
Original message
----------------
Received: from mail.cse.psu.edu ([130.203.4.6]) by edsac; Mon Nov 18 16:40:56 EST 2002
Received: from psuvax1.cse.psu.edu (psuvax1.cse.psu.edu [130.203.23.6])
	by mail.cse.psu.edu (CSE Mail Server) with ESMTP
	id 6F8F019A7D; Mon, 18 Nov 2002 16:39:12 -0500 (EST)
Delivered-To: 9fans@cse.psu.edu
Received: from edsac.borf.com (borf.com [209.179.94.84])
	by mail.cse.psu.edu (CSE Mail Server) with ESMTP id E05D319A73
	for <9fans@cse.psu.edu>; Mon, 18 Nov 2002 16:38:15 -0500 (EST)
Message-ID: <e916d17a309e32bc548e277e825d8c5f@coraid.com>
From: bwc@coraid.com
To: 9fans@cse.psu.edu
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Subject: [9fans] (no subject)
Sender: 9fans-admin@cse.psu.edu
Errors-To: 9fans-admin@cse.psu.edu
X-BeenThere: 9fans@cse.psu.edu
X-Mailman-Version: 2.0.11
Precedence: bulk
Reply-To: 9fans@cse.psu.edu
List-Id: Fans of the OS Plan 9 from Bell Labs <9fans.cse.psu.edu>
List-Archive: <https://lists.cse.psu.edu/archives/9fans/>
Date: Mon, 18 Nov 2002 16:39:56 -0500

I've been getting so much junk mail that I'm resorting to
a draconian mechanism to avoid the mail.  In order
to make sure that there's a real person sending mail, I'm
asking you to explicitly enable access.  To do that, send
mail to bwc at this domain with the token:
	PGyKN
in the subject of your mail message.  After that, you
shouldn't get any bounces from me.  Sorry if this is
an inconvenience.

----------------
Original message
----------------
Received: from mail.cse.psu.edu ([130.203.4.6]) by edsac; Mon Nov 18 16:39:55 EST 2002
Received: from psuvax1.cse.psu.edu (psuvax1.cse.psu.edu [130.203.23.6])
	by mail.cse.psu.edu (CSE Mail Server) with ESMTP
	id B0D6819A7A; Mon, 18 Nov 2002 16:38:11 -0500 (EST)
Delivered-To: 9fans@cse.psu.edu
Received: from edsac.borf.com (borf.com [209.179.94.84])
	by mail.cse.psu.edu (CSE Mail Server) with ESMTP id 5842619A0D
	for <9fans@cse.psu.edu>; Mon, 18 Nov 2002 16:37:33 -0500 (EST)
Message-ID: <3b9bacdf3cb60b9d2af5b5c718859c0f@coraid.com>
From: bwc@coraid.com
To: 9fans@cse.psu.edu
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Subject: [9fans] (no subject)
Sender: 9fans-admin@cse.psu.edu
Errors-To: 9fans-admin@cse.psu.edu
X-BeenThere: 9fans@cse.psu.edu
X-Mailman-Version: 2.0.11
Precedence: bulk
Reply-To: 9fans@cse.psu.edu
List-Id: Fans of the OS Plan 9 from Bell Labs <9fans.cse.psu.edu>
List-Archive: <https://lists.cse.psu.edu/archives/9fans/>
Date: Mon, 18 Nov 2002 16:39:00 -0500

I've been getting so much junk mail that I'm resorting to
a draconian mechanism to avoid the mail.  In order
to make sure that there's a real person sending mail, I'm
asking you to explicitly enable access.  To do that, send
mail to bwc at this domain with the token:
	PGyKN
in the subject of your mail message.  After that, you
shouldn't get any bounces from me.  Sorry if this is
an inconvenience.

----------------
Original message
----------------
Received: from mail.cse.psu.edu ([130.203.4.6]) by edsac; Mon Nov 18 16:38:59 EST 2002
Received: from psuvax1.cse.psu.edu (psuvax1.cse.psu.edu [130.203.23.6])
	by mail.cse.psu.edu (CSE Mail Server) with ESMTP
	id 74DDF19A69; Mon, 18 Nov 2002 16:37:12 -0500 (EST)
Delivered-To: 9fans@cse.psu.edu
Received: from magnum.cooper.edu (magnum.cooper.edu [199.98.16.4])
	by mail.cse.psu.edu (CSE Mail Server) with SMTP id 7769C19A6A
	for <9fans@cse.psu.edu>; Mon, 18 Nov 2002 16:36:05 -0500 (EST)
Received: from robin.cooper.edu by magnum.cooper.edu with SMTP id AA26960
  (5.65c/IDA-1.4.4 for <9fans@cse.psu.edu>); Mon, 18 Nov 2002 16:37:44 -0500
Received: from localhost by robin.cooper.edu (SMI-8.6/SMI-SVR4)
	id QAA07906; Mon, 18 Nov 2002 16:36:00 -0500
From: Joel Salomon <salomo3@cooper.edu>
To: 9fans@cse.psu.edu
Message-Id: <Pine.SOL.3.96.1021118163207.7823A-100000@robin.cooper.edu>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Subject: [9fans] how to avoid a memset() optimization
Sender: 9fans-admin@cse.psu.edu
Errors-To: 9fans-admin@cse.psu.edu
X-BeenThere: 9fans@cse.psu.edu
X-Mailman-Version: 2.0.11
Precedence: bulk
Reply-To: 9fans@cse.psu.edu
List-Id: Fans of the OS Plan 9 from Bell Labs <9fans.cse.psu.edu>
List-Archive: <https://lists.cse.psu.edu/archives/9fans/>
Date: Mon, 18 Nov 2002 16:36:00 -0500 (EST)

Andrew Simmons wrote:
>http://groups.google.com/groups?threadm=oA47GsAf7M29EwY0%40robinton.demon.co.uk
this did not work for me, try:
http://groups.google.com/groups?hl=en&lr=lang_en&ie=UTF-8&threadm=3DD35AAB.AA37D5CA%40monitorbm.co.nz&rnum=1
(should be all on one line)

--Joel
______________________________________________________
Due to economic circumstances, the light at the end of
the tunnel has been turned off.



^ permalink raw reply	[flat|nested] 433+ messages in thread

* [9fans] (no subject)
@ 2002-11-18 21:39 bwc
  0 siblings, 0 replies; 433+ messages in thread
From: bwc @ 2002-11-18 21:39 UTC (permalink / raw)
  To: 9fans

I've been getting so much junk mail that I'm resorting to
a draconian mechanism to avoid the mail.  In order
to make sure that there's a real person sending mail, I'm
asking you to explicitly enable access.  To do that, send
mail to bwc at this domain with the token:
	PGyKN
in the subject of your mail message.  After that, you
shouldn't get any bounces from me.  Sorry if this is
an inconvenience.

----------------
Original message
----------------
Received: from mail.cse.psu.edu ([130.203.4.6]) by edsac; Mon Nov 18 16:38:59 EST 2002
Received: from psuvax1.cse.psu.edu (psuvax1.cse.psu.edu [130.203.23.6])
	by mail.cse.psu.edu (CSE Mail Server) with ESMTP
	id 74DDF19A69; Mon, 18 Nov 2002 16:37:12 -0500 (EST)
Delivered-To: 9fans@cse.psu.edu
Received: from magnum.cooper.edu (magnum.cooper.edu [199.98.16.4])
	by mail.cse.psu.edu (CSE Mail Server) with SMTP id 7769C19A6A
	for <9fans@cse.psu.edu>; Mon, 18 Nov 2002 16:36:05 -0500 (EST)
Received: from robin.cooper.edu by magnum.cooper.edu with SMTP id AA26960
  (5.65c/IDA-1.4.4 for <9fans@cse.psu.edu>); Mon, 18 Nov 2002 16:37:44 -0500
Received: from localhost by robin.cooper.edu (SMI-8.6/SMI-SVR4)
	id QAA07906; Mon, 18 Nov 2002 16:36:00 -0500
From: Joel Salomon <salomo3@cooper.edu>
To: 9fans@cse.psu.edu
Message-Id: <Pine.SOL.3.96.1021118163207.7823A-100000@robin.cooper.edu>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Subject: [9fans] how to avoid a memset() optimization
Sender: 9fans-admin@cse.psu.edu
Errors-To: 9fans-admin@cse.psu.edu
X-BeenThere: 9fans@cse.psu.edu
X-Mailman-Version: 2.0.11
Precedence: bulk
Reply-To: 9fans@cse.psu.edu
List-Id: Fans of the OS Plan 9 from Bell Labs <9fans.cse.psu.edu>
List-Archive: <https://lists.cse.psu.edu/archives/9fans/>
Date: Mon, 18 Nov 2002 16:36:00 -0500 (EST)

Andrew Simmons wrote:
>http://groups.google.com/groups?threadm=oA47GsAf7M29EwY0%40robinton.demon.co.uk
this did not work for me, try:
http://groups.google.com/groups?hl=en&lr=lang_en&ie=UTF-8&threadm=3DD35AAB.AA37D5CA%40monitorbm.co.nz&rnum=1
(should be all on one line)

--Joel
______________________________________________________
Due to economic circumstances, the light at the end of
the tunnel has been turned off.



^ permalink raw reply	[flat|nested] 433+ messages in thread

* [9fans] (no subject)
@ 2002-10-17  3:49 rob pike, esq.
  0 siblings, 0 replies; 433+ messages in thread
From: rob pike, esq. @ 2002-10-17  3:49 UTC (permalink / raw)
  To: 9fans

9fans
Subject: Re: [9fans] mass storage jukebox

480 terabytes for $2000?  I find that hard to believe,
by a factor of a thousand.

-rob


^ permalink raw reply	[flat|nested] 433+ messages in thread

* [9fans] (no subject)
@ 2002-09-30 23:48 Adrian L. Thiele
  0 siblings, 0 replies; 433+ messages in thread
From: Adrian L. Thiele @ 2002-09-30 23:48 UTC (permalink / raw)
  To: '9fans@cse.psu.edu'

I`m running FreeBSD and Plan9, I also have a windows/Plan9 machine with the
FreeBSD bootmanager installed , works just fine. I installed FreeBSD first,
then added Plan9. It does give me a :
f1 FreeBSD
f2 ??
But works well.


Adrian



^ permalink raw reply	[flat|nested] 433+ messages in thread

* [9fans] (no subject)
@ 2002-09-19 17:54 Sape Mullender
  0 siblings, 0 replies; 433+ messages in thread
From: Sape Mullender @ 2002-09-19 17:54 UTC (permalink / raw)
  To: 9fans

I fixed a bug in cfs that causes the cfs connection to hang under
certain circumstances.  Cfs had an optimization that gave clients
an early response to Tclunk calls so that the Tclunk/Rclunk RPC
would not be in the client application's execution path.  This
optimization included waiting for the Rclunk if the clunked fid
was used in a new request.  This was done incorrectly, allowing a
new fid (in a Twalk) to go out before the Rclunk was in.  This is
a violation of protocol.

To make a long story short, I could have simply fixed the bug, but
it turns out that the optimization doesn't really do much for performance
so I removed the whole optimization.

The bug was only triggered by clients that were fast enough to get a
Twalk to the server before the server had completed serving the previous
Tclunk, so it manifested itself by newly installed machines mysteriously
hanging.

	Sape


^ permalink raw reply	[flat|nested] 433+ messages in thread

* Re: [9fans] (no subject)
       [not found] ` <3D5AC220.F7A7ED77@null.net>
  2002-08-15  9:55   ` matt
  2002-08-15 16:24   ` Ronald G Minnich
@ 2002-08-15 17:08   ` Dennis Davis
  2 siblings, 0 replies; 433+ messages in thread
From: Dennis Davis @ 2002-08-15 17:08 UTC (permalink / raw)
  To: 9fans

In the referenced article, "Douglas A. Gwyn" <DAGwyn@null.net> writes:

...

>Does anyone know why this particular scam seems to
>be associated with Nigeria?  Other than that it is
>rife with corruption.

The Crimes of Persuasion website details almost all confidence
scams, many have moved onto email:

http://www.crimes-of-persuasion.com/

Scamorama provides examples sent in by the public and links to many
advice agencies:

http://www.scamorama.com/

And for an amusing example of Nigerian Scam Baiting see:

http://www.geocities.com/a_kerenx/index.html

A colleague went through letters 2 and 3.  He warns that it's an
excellent website for time-wasting!
--
Dennis Davis, BUCS, University of Bath, Bath, BA2 7AY, UK
D.H.Davis@bath.ac.uk


^ permalink raw reply	[flat|nested] 433+ messages in thread

* Re: [9fans] (no subject)
       [not found] ` <3D5AC220.F7A7ED77@null.net>
  2002-08-15  9:55   ` matt
@ 2002-08-15 16:24   ` Ronald G Minnich
  2002-08-15 17:08   ` Dennis Davis
  2 siblings, 0 replies; 433+ messages in thread
From: Ronald G Minnich @ 2002-08-15 16:24 UTC (permalink / raw)
  To: 9fans

On Thu, 15 Aug 2002, Douglas A. Gwyn wrote:

> Does anyone know why this particular scam seems to
> be associated with Nigeria?  Other than that it is
> rife with corruption.

My brother, who worked in the credit card industry for years, told me
there is a term: "Nigerian credit card fraud". No birth certificates in
Nigeria. So you get a passport in any name you like. You come over here,
set up a boiler room operation, scam a bunch of people, go home and come
back under a new name.

weird but true.

ron



^ permalink raw reply	[flat|nested] 433+ messages in thread

* Re: [9fans] (no subject)
       [not found] ` <3D5AC220.F7A7ED77@null.net>
@ 2002-08-15  9:55   ` matt
  2002-08-15 16:24   ` Ronald G Minnich
  2002-08-15 17:08   ` Dennis Davis
  2 siblings, 0 replies; 433+ messages in thread
From: matt @ 2002-08-15  9:55 UTC (permalink / raw)
  To: 9fans

> [ Moderators note: I see lots of these kind of messages.  They are
>   Advance Fee Frauds (also called 419 frauds after the Nigerian
>   Penal Code section that outlawed them).

been there

bought the t-shirt

http://www.clickandbuild.com/cnb/shop/cashncarrion?listPos=&op=catalogue-pro
ducts-null&prodCategoryID=5



^ permalink raw reply	[flat|nested] 433+ messages in thread

* [9fans] (no subject)
@ 2002-07-19  0:59 presotto
  0 siblings, 0 replies; 433+ messages in thread
From: presotto @ 2002-07-19  0:59 UTC (permalink / raw)
  To: 9fans

New /sys/src/9/pc/apic.c on sources.  Fixes a bug that I inserted
in April causing multiprocessors to get way too many clock interrupts.


^ permalink raw reply	[flat|nested] 433+ messages in thread

* [9fans] (no subject)
@ 2002-07-16 19:21 presotto
  0 siblings, 0 replies; 433+ messages in thread
From: presotto @ 2002-07-16 19:21 UTC (permalink / raw)
  To: 9fans

I exploded the man page for mail into a bunch of man pages to make it easier
to use.  The relevant new/changed files are:

/sys/man/1/mail
/sys/man/1/filter
/sys/man/1/marshal
/sys/man/1/mlmgr
/sys/man/4/upasfs
/sys/man/8/aliasmail
/sys/man/8/pop3
/sys/man/8/send
/sys/man/8/smtp
/sys/man/8/ipserv

Rsc's scan should pick them up as updated in its next
on the half hour scan.


^ permalink raw reply	[flat|nested] 433+ messages in thread

* [9fans] (no subject)
@ 2002-07-03 13:17 presotto
  0 siblings, 0 replies; 433+ messages in thread
From: presotto @ 2002-07-03 13:17 UTC (permalink / raw)
  To: 9fans

/sys/man/1/mail updated to describe upasname and with synopses
for smtp and smtpd.


^ permalink raw reply	[flat|nested] 433+ messages in thread

* [9fans] (no subject)
@ 2002-06-10 19:10 Russ Cox
  0 siblings, 0 replies; 433+ messages in thread
From: Russ Cox @ 2002-06-10 19:10 UTC (permalink / raw)
  To: 9fans, blake

> I think one of main problems is that, in spite of the fact that I
> have a quality video board, Plan 9 comes up in a low
> resolution.  It's so low that if I open up an RC window and
> do a man on a command the text partially wraps and is difficult
> to read.  If I could fix that problem I'd feel a lot better.

What kind of video card do you have?
What happens if you change your vgasize= in plan9.ini?

Russ


^ permalink raw reply	[flat|nested] 433+ messages in thread

* [9fans] (no subject)
@ 2002-04-12 17:43 Russ Cox
  0 siblings, 0 replies; 433+ messages in thread
From: Russ Cox @ 2002-04-12 17:43 UTC (permalink / raw)
  To: 9fans

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

repost.

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

From: "Russ Cox" <rsc@plan9.bell-labs.com>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] Drawterm session close??
Date: Fri, 8 Mar 2002 17:36:27 -0500
Message-ID: <7dafad1306719963a42c47fa3a8f9a58@plan9.bell-labs.com>

I'm not sure why the processes are left over.
Usually a name space loop, but in this case
that would mean rio has fs in its namespace
and fs has rio in its namespace, but I don't
think you can set things up that way.

To kill them as bootes, use Kill, which is like kill, but
stronger:

g% cat /bin/Kill
#!/bin/rc
ps | sed -n '/ '^$1^'$/s%^[^ ]* *([^ ]*).*%chmod 666 /proc/\1/ctl;echo kill > /proc/\1/ctl%p'
g%

^ permalink raw reply	[flat|nested] 433+ messages in thread

* [9fans] (no subject)
@ 2002-04-12 17:20 /dev/null
  0 siblings, 0 replies; 433+ messages in thread
From: /dev/null @ 2002-04-12 17:20 UTC (permalink / raw)
  To: 9fans

I've been getting so much junk mail that I'm resorting to a draconian
mechanism to avoid the mail.  In order to make sure that there's a
real person sending mail, I'm asking you to explicitly enable access.
So please send mail to none@plan9.bell-labs.com with the magic word:
	swfTI
in the subject of your mail message.  After that, you shouldn't get
any bounces from me.  Sorry if this is an inconvenience.

----------------
Original message
----------------
Received: from plan9.cs.bell-labs.com ([135.104.9.2]) by plan9; Fri Apr 12 13:20:21 EDT 2002
Received: from mail.cse.psu.edu ([130.203.4.6]) by plan9; Fri Apr 12 13:20:20 EDT 2002
Received: from psuvax1.cse.psu.edu (psuvax1.cse.psu.edu [130.203.6.6])
	by mail.cse.psu.edu (CSE Mail Server) with ESMTP
	id 56180199BE; Fri, 12 Apr 2002 12:44:08 -0400 (EDT)
Delivered-To: 9fans@cse.psu.edu
Received: from cosym.net (unknown [64.7.3.116])
	by mail.cse.psu.edu (CSE Mail Server) with SMTP id 740A81998C
	for <9fans@cse.psu.edu>; Fri, 12 Apr 2002 12:43:05 -0400 (EDT)
Received: from [192.168.1.102] ([64.7.3.126]) by cosym.net; Fri Apr 12 12:43:03 EDT 2002
Mime-Version: 1.0
X-Sender: plus@mail.9srv.net
Message-Id: <a05101500b8dcbe6317f3@[192.168.1.102]>
In-Reply-To: <200204111436.g3BEarU4026062@ratthing-b246.strakt.com>
References: <200204111436.g3BEarU4026062@ratthing-b246.strakt.com>
To: 9fans@cse.psu.edu
From: Paul C Lustgarten <plus@9srv.net>
Subject: Re: [9fans] The Swedish tax authorities want to know if Plan 9 is
 research.
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: 9fans-admin@cse.psu.edu
Errors-To: 9fans-admin@cse.psu.edu
X-BeenThere: 9fans@cse.psu.edu
X-Mailman-Version: 2.0.9
Precedence: bulk
Reply-To: 9fans@cse.psu.edu
List-Id: Fans of the OS Plan 9 from Bell Labs <9fans.cse.psu.edu>
List-Archive: <https://lists.cse.psu.edu/archives/9fans/>
Date: Fri, 12 Apr 2002 12:43:02 -0400

Hey, Laura!

I have no printed citations of this, but I'm using Plan 9 (& Inferno)
as the application platform for my research into "referential richness"
of spoken dialog systems.  My official title these days is "Research
Scientist" in the "Multimedia Technologies Research Department" of
Avaya.

Hope that helps!

	Paul


>I want to tell them yes.  It would help if I had a list of those of
>you who are Research Institutions or Universities using Plan 9 for
>teaching or research purposes.  Papers that refer to Plan 9 would
>be even better.  If you have some, can you please send them, or a
>reference to them to me.  I've got the ones on the Wiki; they look
>good.
>
>Thank you all for your time,
>Laura Creighton


--


^ permalink raw reply	[flat|nested] 433+ messages in thread

* Re: [9fans] (no subject)
  2002-03-11 15:57 presotto
                   ` (3 preceding siblings ...)
  2002-03-12 11:05 ` Anthony Mandic
@ 2002-03-13 10:05 ` Douglas A. Gwyn
  4 siblings, 0 replies; 433+ messages in thread
From: Douglas A. Gwyn @ 2002-03-13 10:05 UTC (permalink / raw)
  To: 9fans

presotto@plan9.bell-labs.com wrote:
> 1) which is more important, truth or beauty?

Important by what criteria?

> 2) exactly how many angels can dance on the head of a pin?

There are no angels.

> 3) if a tree falls in a forest with noone to hear, which editor
>   would be more useful in describing the fall?

Mu.


^ permalink raw reply	[flat|nested] 433+ messages in thread

* Re: [9fans] (no subject)
  2002-03-12  9:42 ` Thomas Bushnell, BSG
@ 2002-03-13 10:04   ` bs
  0 siblings, 0 replies; 433+ messages in thread
From: bs @ 2002-03-13 10:04 UTC (permalink / raw)
  To: 9fans

"Thomas Bushnell, BSG" wrote:
> 
> markp@panix.com writes:
> 
> > > Editors, like sounds, are only in your mind.
> >
> > do not try to use the editor, only realize the truth ...
> > there is no editor.
> 
> If there's no editor, that's fine, but I *do* insist on having a spoon
> to eat my rice pudding with.
not if you are from India or go there!


^ permalink raw reply	[flat|nested] 433+ messages in thread

* Re: [9fans] (no subject)
  2002-03-11 15:57 presotto
                   ` (2 preceding siblings ...)
  2002-03-11 19:53 ` Andrew Simmons
@ 2002-03-12 11:05 ` Anthony Mandic
  2002-03-13 10:05 ` Douglas A. Gwyn
  4 siblings, 0 replies; 433+ messages in thread
From: Anthony Mandic @ 2002-03-12 11:05 UTC (permalink / raw)
  To: 9fans

presotto@plan9.bell-labs.com wrote:
> 
> I've got some questions I could use some discussion on.
> Perhaps the list memership can help.
> 
> 1) which is more important, truth or beauty?

	Without truth there can be no beauty. But beauty
	eventually fades. So, does truth?

> 2) exactly how many angels can dance on the head of a pin?

	Which exact pin and what is the surface area of its head?

> 3) if a tree falls in a forest with noone to hear, which editor
>   would be more useful in describing the fall?

	I wouldn't trust any editor from Greenpeace or "Save the
	Rainforests"! Bunch of biggoted greenies. The editor of
	the Sydney Morning Herald might be more objective, but
	I hear that the editors of The Times or The Wall Street
	Journal are pretty good.

-am	© 2002


^ permalink raw reply	[flat|nested] 433+ messages in thread

* Re: [9fans] (no subject)
  2002-03-12  1:04 markp
@ 2002-03-12  9:42 ` Thomas Bushnell, BSG
  2002-03-13 10:04   ` bs
  0 siblings, 1 reply; 433+ messages in thread
From: Thomas Bushnell, BSG @ 2002-03-12  9:42 UTC (permalink / raw)
  To: 9fans

markp@panix.com writes:

> > Editors, like sounds, are only in your mind.
> 
> do not try to use the editor, only realize the truth ... 
> there is no editor.

If there's no editor, that's fine, but I *do* insist on having a spoon
to eat my rice pudding with.


^ permalink raw reply	[flat|nested] 433+ messages in thread

* Re: [9fans] (no subject)
  2002-03-11 18:33 Russ Cox
@ 2002-03-12  9:42 ` Thomas Bushnell, BSG
  0 siblings, 0 replies; 433+ messages in thread
From: Thomas Bushnell, BSG @ 2002-03-12  9:42 UTC (permalink / raw)
  To: 9fans

rsc@plan9.bell-labs.com (Russ Cox) writes:

> >> 2) exactly how many angels can dance on the head of a pin?
> > 
> > Of course, the medievals actually used this as a *caricature*, nobody
> 
> Unlike Presotto, who was dead serious, I'm sure.

I hope not!  What's the point of adding a joke to a joke if the
original isn't a joke in the first place.

I'm pretty darn sure Presotto was making a funny, I was responding
with the same spirit in mind.


^ permalink raw reply	[flat|nested] 433+ messages in thread

* Re: [9fans] (no subject)
  2002-03-11 17:51 ` Thomas Bushnell, BSG
@ 2002-03-12  9:42   ` ozan s yigit
  0 siblings, 0 replies; 433+ messages in thread
From: ozan s yigit @ 2002-03-12  9:42 UTC (permalink / raw)
  To: 9fans

[Thomas Bushnell's history of angels and pins. elided]

jay gould (amonst others) made this point also. saint thomas appears
to have commented on the related issue of two angels being on the same
place and concluded that there can be but one angel in one place.
[he does not mention pins. :-]

it looks like that these historic details do not change the value
of the caricature as it relates to usenet discussions of a certain
magnitude.

oz
---
the trouble with people is that they're
practically all too human. -- matt helm


^ permalink raw reply	[flat|nested] 433+ messages in thread

* Re: [9fans] (no subject)
@ 2002-03-12  1:04 markp
  2002-03-12  9:42 ` Thomas Bushnell, BSG
  0 siblings, 1 reply; 433+ messages in thread
From: markp @ 2002-03-12  1:04 UTC (permalink / raw)
  To: 9fans

> Editors, like sounds, are only in your mind.

do not try to use the editor, only realize the truth ... 
there is no editor.



^ permalink raw reply	[flat|nested] 433+ messages in thread

* Re: [9fans] (no subject)
  2002-03-11 15:57 presotto
  2002-03-11 17:51 ` Thomas Bushnell, BSG
  2002-03-11 19:51 ` Sam Ducksworth
@ 2002-03-11 19:53 ` Andrew Simmons
  2002-03-12 11:05 ` Anthony Mandic
  2002-03-13 10:05 ` Douglas A. Gwyn
  4 siblings, 0 replies; 433+ messages in thread
From: Andrew Simmons @ 2002-03-11 19:53 UTC (permalink / raw)
  To: 9fans

>1) which is more important, truth or beauty?

The poet Keats held them to be the same thing, in which casethis question
does not apply. HTH.




^ permalink raw reply	[flat|nested] 433+ messages in thread

* Re: [9fans] (no subject)
  2002-03-11 15:57 presotto
  2002-03-11 17:51 ` Thomas Bushnell, BSG
@ 2002-03-11 19:51 ` Sam Ducksworth
  2002-03-11 19:53 ` Andrew Simmons
                   ` (2 subsequent siblings)
  4 siblings, 0 replies; 433+ messages in thread
From: Sam Ducksworth @ 2002-03-11 19:51 UTC (permalink / raw)
  To: 9fans

On Mon, 11 Mar 2002 presotto@plan9.bell-labs.com wrote:

> 2) exactly how many angels can dance on the head of a pin?

the short answer is none... angels do not exist.

haha.... lets make it a real holy war :-)

sorry a "daemon" made me do it.

--sam



^ permalink raw reply	[flat|nested] 433+ messages in thread

* Re: [9fans] (no subject)
@ 2002-03-11 18:33 Russ Cox
  2002-03-12  9:42 ` Thomas Bushnell, BSG
  0 siblings, 1 reply; 433+ messages in thread
From: Russ Cox @ 2002-03-11 18:33 UTC (permalink / raw)
  To: 9fans

>> 2) exactly how many angels can dance on the head of a pin?
> 
> Of course, the medievals actually used this as a *caricature*, nobody

Unlike Presotto, who was dead serious, I'm sure.



^ permalink raw reply	[flat|nested] 433+ messages in thread

* Re: [9fans] (no subject)
  2002-03-11 15:57 presotto
@ 2002-03-11 17:51 ` Thomas Bushnell, BSG
  2002-03-12  9:42   ` ozan s yigit
  2002-03-11 19:51 ` Sam Ducksworth
                   ` (3 subsequent siblings)
  4 siblings, 1 reply; 433+ messages in thread
From: Thomas Bushnell, BSG @ 2002-03-11 17:51 UTC (permalink / raw)
  To: 9fans

presotto@plan9.bell-labs.com writes:

> 1) which is more important, truth or beauty?

Ah, well, there's the rub.  Kant's essay on the difference between the
beautiful and the sublime is good reading here.

> 2) exactly how many angels can dance on the head of a pin?

Of course, the medievals actually used this as a *caricature*, nobody
discussed it.  (And the question is usually misunderstood by people
who are citing it with no understanding--as probably you are--sample
answers are not things like "seventeen" or "fifty".  The question [if
anybody had discussed it, which they didn't] was whether it was an
infinite or a finite number, and thus really about whether an
incorporeal-being-with-spatial-location must necessarily also have
some spatial extension.)

> 3) if a tree falls in a forest with noone to hear, which editor
>   would be more useful in describing the fall?

Editors, like sounds, are only in your mind.


^ permalink raw reply	[flat|nested] 433+ messages in thread

* Re: [9fans] (no subject)
@ 2002-03-11 16:28 bwc
  0 siblings, 0 replies; 433+ messages in thread
From: bwc @ 2002-03-11 16:28 UTC (permalink / raw)
  To: 9fans

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

I mean `they are'.  Must be the editor I'm using.

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

From: bwc@borf.com
To: 9fans@cse.psu.edu
Subject: Re: [9fans] (no subject)
Date: Mon, 11 Mar 2002 11:24:22 -0500
Message-ID: <20020311162242.23FE519991@mail.cse.psu.edu>

> 2) exactly how many angels can dance on the head of a pin?

I don't know, but their wearing digital watches.

^ permalink raw reply	[flat|nested] 433+ messages in thread

* Re: [9fans] (no subject)
@ 2002-03-11 16:24 bwc
  0 siblings, 0 replies; 433+ messages in thread
From: bwc @ 2002-03-11 16:24 UTC (permalink / raw)
  To: 9fans

> 2) exactly how many angels can dance on the head of a pin?

I don't know, but their wearing digital watches.


^ permalink raw reply	[flat|nested] 433+ messages in thread

* [9fans] (no subject)
@ 2002-03-11 15:57 presotto
  2002-03-11 17:51 ` Thomas Bushnell, BSG
                   ` (4 more replies)
  0 siblings, 5 replies; 433+ messages in thread
From: presotto @ 2002-03-11 15:57 UTC (permalink / raw)
  To: 9fans

I've got some questions I could use some discussion on.
Perhaps the list memership can help.

1) which is more important, truth or beauty?
2) exactly how many angels can dance on the head of a pin?
3) if a tree falls in a forest with noone to hear, which editor
  would be more useful in describing the fall?


^ permalink raw reply	[flat|nested] 433+ messages in thread

* Re: [9fans] (no subject)
  2002-02-28 11:26 sape
@ 2002-03-04  6:51 ` Sean Quinlan
  0 siblings, 0 replies; 433+ messages in thread
From: Sean Quinlan @ 2002-03-04  6:51 UTC (permalink / raw)
  To: 9fans

I suspect most compilers will not registerize a global over a function call.
The main problem with registerizing globals is that it might be aliased
by a function paramter.  This has nothing to do with the issue of threads.

In plan9 the following code produces different output depending
on whether optimisation is on or off.

	#include <u.h>
	#include <libc.h>

	int x = 1;


	void
	foo(int *p)
	{
		int i;
	
		for(i=0; i<10; i++) {
			*p = i;
			x += x+i;
		}
	}


	void
	main(void)
	{
		foo(&x);
		print("x = %d\n", x);
	}

one could claim this is a bug; Ken said he never gets caught by real code - at least code we write.

Many of the optimising C compiliers I have used will assume in code
such as

	#include "stdio.h"
		
	int
	foo(int *p, short *s)
	{
		int i, j;
	
		j = 0;
		for(i=0; i<100; i++) {
			j += *p + *s;	
			*p = j;
		}
		return j;
	}

that *p and *s do not alias each other and thus the reference to *s in the loop can be
moved out of the loop and placed in a register.  Since I am not a language lawyer,
I don't know what the C standard says about this, but this type of optimisation does break
a lot of poorly written code.  Since gcc is C by definition, I had a look what it does.
Naturally, they have this optimisation, and an option to turn it on or off

	-fstrict-aliasing -- turns it on
	-fno-strict-aliasing -- turns it off

Naturally, -O2 may enable this optimisation depending on the version of the compiler that
is used.  From what I can gather from a quick search of the internet, this optimisation got
turned on by defualt with -O2, tons of code broke including the linux kernel.  Next release
turns it off, then all the broken programs add -fno-strict-aliasing to their Makefiles, then
after sufficent time, the option is turned back on by default...  From what I gather,
gcc 3.0 and up have this option on by default with -O2, though I do not have access to a system
that runs this compiler and thus have not actually checked this is the case.  This is the
type of problem that forces the linux world to exactly match the version of the compiler with
the version of the code they are compiling...


sape@plan9.bell-labs.com wrote:
> 
> > On registerizing globals, it seems to be that it's
> > entirely safe to registerize as long as control flow
> > doesn't leave your function.  I.e., don't expect
> > registerized globals not to mutate across function
> > calls.  Threaded programmers know what they're getting
> > themselves into, and ought to be using locks or
> > condition variables.
> 
> Locks and condition variables aren't good enough, unless there
> is a mechanism in the optimizing compiler to link locks to
> registerized globals (flush before unlock, reread after lock),
> or a mechanism to tell the compiler to flush before a context
> switch and reload after one.
> 
>   --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
> 
> Subject: [9fans] (no subject)
> Date: Wed, 27 Feb 2002 17:47:15 -0500
> From: presotto@plan9.bell-labs.com
> Reply-To: 9fans@cse.psu.edu
> To: 9fans@cse.psu.edu
> 
> This is what I got out of Cliff Young:
> 
> Do you mean about the general 9fans topic of
> whether optimizations are dangerous, or about
> the specific issue of when you can registerize
> a global?
> 
> On the former, one person made the rarely-made point
> that many people write programs that depend on undefined
> behavior in the C standard, then gripe when their bugs
> that are masked with -O0 are exposed with -O2.  I think
> this point isn't made often enough.
> 
> On the other hand, I'm entirely willing to admit that
> buggy optimizations passes are the reason why people
> turn optimizations off.  It's hard to write optimizations
> that are as reliable as, say, hardware.  Part of this is
> that the verification technology is way better on the
> hardware side, and another part is that writing a
> good optimizing compiler is a never-ending time sink,
> and it's hard to get users to send you examples that
> exhibit bugs, and then even harder to track them down.
> And this in a program that isn't multithreaded.
> 
> On registerizing globals, it seems to be that it's
> entirely safe to registerize as long as control flow
> doesn't leave your function.  I.e., don't expect
> registerized globals not to mutate across function
> calls.  Threaded programmers know what they're getting
> themselves into, and ought to be using locks or
> condition variables.


^ permalink raw reply	[flat|nested] 433+ messages in thread

* Re: [9fans] (no subject)
@ 2002-02-28 11:26 sape
  2002-03-04  6:51 ` Sean Quinlan
  0 siblings, 1 reply; 433+ messages in thread
From: sape @ 2002-02-28 11:26 UTC (permalink / raw)
  To: 9fans

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

> On registerizing globals, it seems to be that it's 
> entirely safe to registerize as long as control flow
> doesn't leave your function.  I.e., don't expect
> registerized globals not to mutate across function
> calls.  Threaded programmers know what they're getting
> themselves into, and ought to be using locks or
> condition variables.

Locks and condition variables aren't good enough, unless there
is a mechanism in the optimizing compiler to link locks to
registerized globals (flush before unlock, reread after lock),
or a mechanism to tell the compiler to flush before a context
switch and reload after one.


[-- Attachment #2: message.txt --]
[-- Type: message/rfc822, Size: 2601 bytes --]

From: presotto@plan9.bell-labs.com
To: 9fans@cse.psu.edu
Subject: [9fans] (no subject)
Date: Wed, 27 Feb 2002 17:47:15 -0500
Message-ID: <28ff9a9c71ca0c354fca1202927d87e2@plan9.bell-labs.com>

This is what I got out of Cliff Young:

Do you mean about the general 9fans topic of 
whether optimizations are dangerous, or about
the specific issue of when you can registerize
a global?

On the former, one person made the rarely-made point
that many people write programs that depend on undefined
behavior in the C standard, then gripe when their bugs
that are masked with -O0 are exposed with -O2.  I think
this point isn't made often enough.

On the other hand, I'm entirely willing to admit that
buggy optimizations passes are the reason why people
turn optimizations off.  It's hard to write optimizations
that are as reliable as, say, hardware.  Part of this is
that the verification technology is way better on the 
hardware side, and another part is that writing a 
good optimizing compiler is a never-ending time sink,
and it's hard to get users to send you examples that
exhibit bugs, and then even harder to track them down.
And this in a program that isn't multithreaded.

On registerizing globals, it seems to be that it's 
entirely safe to registerize as long as control flow
doesn't leave your function.  I.e., don't expect
registerized globals not to mutate across function
calls.  Threaded programmers know what they're getting
themselves into, and ought to be using locks or
condition variables.

^ permalink raw reply	[flat|nested] 433+ messages in thread

* [9fans] (no subject)
@ 2002-02-27 22:47 presotto
  0 siblings, 0 replies; 433+ messages in thread
From: presotto @ 2002-02-27 22:47 UTC (permalink / raw)
  To: 9fans

This is what I got out of Cliff Young:

Do you mean about the general 9fans topic of 
whether optimizations are dangerous, or about
the specific issue of when you can registerize
a global?

On the former, one person made the rarely-made point
that many people write programs that depend on undefined
behavior in the C standard, then gripe when their bugs
that are masked with -O0 are exposed with -O2.  I think
this point isn't made often enough.

On the other hand, I'm entirely willing to admit that
buggy optimizations passes are the reason why people
turn optimizations off.  It's hard to write optimizations
that are as reliable as, say, hardware.  Part of this is
that the verification technology is way better on the 
hardware side, and another part is that writing a 
good optimizing compiler is a never-ending time sink,
and it's hard to get users to send you examples that
exhibit bugs, and then even harder to track them down.
And this in a program that isn't multithreaded.

On registerizing globals, it seems to be that it's 
entirely safe to registerize as long as control flow
doesn't leave your function.  I.e., don't expect
registerized globals not to mutate across function
calls.  Threaded programmers know what they're getting
themselves into, and ought to be using locks or
condition variables.


^ permalink raw reply	[flat|nested] 433+ messages in thread

* [9fans] (no subject)
@ 2002-02-27 17:57 stanv
  0 siblings, 0 replies; 433+ messages in thread
From: stanv @ 2002-02-27 17:57 UTC (permalink / raw)
  To: 9fans




---
Некогда бегать по магазинам? www.Shopping.ru - сотни тысяч товаров от 10 тысяч (!) продавцов. Такого выбора нет нигде!


^ permalink raw reply	[flat|nested] 433+ messages in thread

* Re: [9fans] (no subject)
  2002-01-02 10:04       ` John R. Strohm
@ 2002-01-03  9:52         ` Douglas A. Gwyn
  0 siblings, 0 replies; 433+ messages in thread
From: Douglas A. Gwyn @ 2002-01-03  9:52 UTC (permalink / raw)
  To: 9fans

"John R. Strohm" wrote:
> Sounds like "touch" is a lower-level, more fundamental thing than is
> normally thought.

Or a higher-level, poorly specified function?


^ permalink raw reply	[flat|nested] 433+ messages in thread

* Re: [9fans] (no subject)
  2001-12-12  9:47     ` Douglas A. Gwyn
@ 2002-01-02 10:04       ` John R. Strohm
  2002-01-03  9:52         ` Douglas A. Gwyn
  0 siblings, 1 reply; 433+ messages in thread
From: John R. Strohm @ 2002-01-02 10:04 UTC (permalink / raw)
  To: 9fans

That is the exact definition of an operating system function or service:
something that can't be implemented at user level.

Sounds like "touch" is a lower-level, more fundamental thing than is
normally thought.

"Douglas A. Gwyn" <DAGwyn@null.net> wrote in message
news:3C165C57.D0DCCE89@null.net...
> Boyd Roberts wrote:
> > Some implementations of touch would read a byte and write it back.
> > A total disaster for an append-only file.
> > How many broken versions of touch have I seen?  5?
>
> The problem was that there was no single way to implement
> "touch" that would always do what was wanted.


^ permalink raw reply	[flat|nested] 433+ messages in thread

* Re: [9fans] (no subject)
  2001-12-13 14:35 presotto
  2001-12-13 15:10 ` Ronald G Minnich
@ 2001-12-13 15:47 ` Lucio De Re
  1 sibling, 0 replies; 433+ messages in thread
From: Lucio De Re @ 2001-12-13 15:47 UTC (permalink / raw)
  To: 9fans

On Thu, Dec 13, 2001 at 09:35:12AM -0500, presotto@closedmind.org wrote:
>
> Is there a pascal compiler written in pascal?

I typed the P4 code in on a glass terminal in 1974 or thereabouts.  It
was the quickest way to capture it.

Didn't include the P-code interpreter.

++L


^ permalink raw reply	[flat|nested] 433+ messages in thread

* Re: [9fans] (no subject)
  2001-12-13 14:35 presotto
@ 2001-12-13 15:10 ` Ronald G Minnich
  2001-12-13 15:47 ` Lucio De Re
  1 sibling, 0 replies; 433+ messages in thread
From: Ronald G Minnich @ 2001-12-13 15:10 UTC (permalink / raw)
  To: 9fans

On Thursday 13 December 2001 07:35, you wrote:
> Is there a pascal compiler written in pascal?

There used to be, I know someone who did one. But that was long ago.

ron


^ permalink raw reply	[flat|nested] 433+ messages in thread

* [9fans] (no subject)
@ 2001-12-13 14:35 presotto
  2001-12-13 15:10 ` Ronald G Minnich
  2001-12-13 15:47 ` Lucio De Re
  0 siblings, 2 replies; 433+ messages in thread
From: presotto @ 2001-12-13 14:35 UTC (permalink / raw)
  To: 9fans

Is there a pascal compiler written in pascal?


^ permalink raw reply	[flat|nested] 433+ messages in thread

* Re: [9fans] (no subject)
  2001-12-12  9:48   ` Thomas Bushnell, BSG
@ 2001-12-12 11:14     ` Boyd Roberts
  0 siblings, 0 replies; 433+ messages in thread
From: Boyd Roberts @ 2001-12-12 11:14 UTC (permalink / raw)
  To: 9fans

> NFS has a set attributes call that does permit you to directly set the
> mtime.

Yup, GETATTR / SETATTR -- the horror, the horror ...


^ permalink raw reply	[flat|nested] 433+ messages in thread

* Re: [9fans] (no subject)
  2001-12-11 10:07 ` Douglas A. Gwyn
  2001-12-11 11:55   ` Boyd Roberts
@ 2001-12-12  9:48   ` Thomas Bushnell, BSG
  2001-12-12 11:14     ` Boyd Roberts
  1 sibling, 1 reply; 433+ messages in thread
From: Thomas Bushnell, BSG @ 2001-12-12  9:48 UTC (permalink / raw)
  To: 9fans

"Douglas A. Gwyn" <DAGwyn@null.net> writes:

> rob pike wrote:
> > touch should just try to set the mtime, if the file server
> > will let it. ...
>
> Right.  NFS is an example of a filesystem that doesn't, so it
> requires an actual data transfer to update the time on the
> remote object.  We ran into that with BRL's MDQS spooling system.

NFS has a set attributes call that does permit you to directly set the
mtime.


^ permalink raw reply	[flat|nested] 433+ messages in thread

* Re: [9fans] (no subject)
  2001-12-11 11:55   ` Boyd Roberts
@ 2001-12-12  9:47     ` Douglas A. Gwyn
  2002-01-02 10:04       ` John R. Strohm
  0 siblings, 1 reply; 433+ messages in thread
From: Douglas A. Gwyn @ 2001-12-12  9:47 UTC (permalink / raw)
  To: 9fans

Boyd Roberts wrote:
> Some implementations of touch would read a byte and write it back.
> A total disaster for an append-only file.
> How many broken versions of touch have I seen?  5?

The problem was that there was no single way to implement
"touch" that would always do what was wanted.


^ permalink raw reply	[flat|nested] 433+ messages in thread

* Re: [9fans] (no subject)
@ 2001-12-11 18:27 bwc
  0 siblings, 0 replies; 433+ messages in thread
From: bwc @ 2001-12-11 18:27 UTC (permalink / raw)
  To: 9fans

Folks, I'm sorry.  I want to confess to thinking ill of others
who have fat-fingered personal email onto this group.  I stand
humbled .

  Brantley Coile


^ permalink raw reply	[flat|nested] 433+ messages in thread

* Re: [9fans] (no subject)
@ 2001-12-11 18:17 Russ Cox
  0 siblings, 0 replies; 433+ messages in thread
From: Russ Cox @ 2001-12-11 18:17 UTC (permalink / raw)
  To: 9fans

> Thanks.

no problem.



^ permalink raw reply	[flat|nested] 433+ messages in thread

* Re: [9fans] (no subject)
@ 2001-12-11 18:17 bwc
  0 siblings, 0 replies; 433+ messages in thread
From: bwc @ 2001-12-11 18:17 UTC (permalink / raw)
  To: 9fans

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

Thanks.  We're leaving at 2pm.

Last night Dan called and GG thinks they have cooled off some.
We'll see.  May just be the first of many trips.

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

From: "Russ Cox" <rsc@plan9.bell-labs.com>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] (no subject)
Date: Tue, 11 Dec 2001 11:24:37 -0500
Message-ID: <20011211162438.97A6419A08@mail.cse.psu.edu>

> Some implementations of touch would read a byte and write it back.

was there a better way before wstat let you change mtime?

^ permalink raw reply	[flat|nested] 433+ messages in thread

* Re: [9fans] (no subject)
  2001-12-11 16:24 Russ Cox
@ 2001-12-11 16:33 ` Boyd Roberts
  0 siblings, 0 replies; 433+ messages in thread
From: Boyd Roberts @ 2001-12-11 16:33 UTC (permalink / raw)
  To: 9fans

> was there a better way before wstat let you change mtime?

That was in reference to unix/history.  It was before the
days of utime(2) and it was the only way to do it and then
it just persisted, in about N different bad forms.

One version wouldn't create the file if it didn't exist IIRC.

And then all the different date formats for the time(s).


^ permalink raw reply	[flat|nested] 433+ messages in thread

* Re: [9fans] (no subject)
@ 2001-12-11 16:24 Russ Cox
  2001-12-11 16:33 ` Boyd Roberts
  0 siblings, 1 reply; 433+ messages in thread
From: Russ Cox @ 2001-12-11 16:24 UTC (permalink / raw)
  To: 9fans

> Some implementations of touch would read a byte and write it back.

was there a better way before wstat let you change mtime?



^ permalink raw reply	[flat|nested] 433+ messages in thread

* Re: [9fans] (no subject)
  2001-12-11 10:07 ` Douglas A. Gwyn
@ 2001-12-11 11:55   ` Boyd Roberts
  2001-12-12  9:47     ` Douglas A. Gwyn
  2001-12-12  9:48   ` Thomas Bushnell, BSG
  1 sibling, 1 reply; 433+ messages in thread
From: Boyd Roberts @ 2001-12-11 11:55 UTC (permalink / raw)
  To: 9fans

Some implementations of touch would read a byte and write it back.

A total disaster for an append-only file.

How many broken versions of touch have I seen?  5?


^ permalink raw reply	[flat|nested] 433+ messages in thread

* Re: [9fans] (no subject)
  2001-12-09 14:48 rob pike
@ 2001-12-11 10:07 ` Douglas A. Gwyn
  2001-12-11 11:55   ` Boyd Roberts
  2001-12-12  9:48   ` Thomas Bushnell, BSG
  0 siblings, 2 replies; 433+ messages in thread
From: Douglas A. Gwyn @ 2001-12-11 10:07 UTC (permalink / raw)
  To: 9fans

rob pike wrote:
> touch should just try to set the mtime, if the file server
> will let it. ...

Right.  NFS is an example of a filesystem that doesn't, so it
requires an actual data transfer to update the time on the
remote object.  We ran into that with BRL's MDQS spooling system.


^ permalink raw reply	[flat|nested] 433+ messages in thread

* Re: [9fans] (no subject)
@ 2001-12-09 14:48 rob pike
  2001-12-11 10:07 ` Douglas A. Gwyn
  0 siblings, 1 reply; 433+ messages in thread
From: rob pike @ 2001-12-09 14:48 UTC (permalink / raw)
  To: 9fans

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

touch should just try to set the mtime, if the file server
will let it. try this change and see if it behaves better.

%% diff -n touch.c  /sys/src/cmd/touch.c
touch.c:30 c /sys/src/cmd/touch.c:30
< 	Dir stbuff, nstbuff;
---
> 	Dir stbuff;
touch.c:39,44 d /sys/src/cmd/touch.c:38
< 	}
< 	stbuff.mtime = time(0);
< 	if(dirwstat(name, &stbuff) >= 0){
< 		/* check that file server paid attention */
< 		if(dirstat(name, &nstbuff) >=0 && nstbuff.mtime == stbuff.mtime)
< 			return 0;
%%


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

From: arisawa@ar.aichi-u.ac.jp
To: 9fans@cse.psu.edu
Subject: [9fans] (no subject)
Date: Sun, 9 Dec 2001 17:22:59 +0900
Message-ID: <20011209082312.98EEF199DD@mail.cse.psu.edu>

Hello,

`Touch' change the size of file if is append only.

term% chmod +a x
term% ls -l x
a-rw-rw-r-- M 3 arisawa arisawa 1 Dec  9 16:59 x
term% touch x
term% ls -l x
a-rw-rw-r-- M 3 arisawa arisawa 2 Dec  9 17:05 x
term%

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

^ permalink raw reply	[flat|nested] 433+ messages in thread

* [9fans] (no subject)
@ 2001-12-09  8:22 arisawa
  0 siblings, 0 replies; 433+ messages in thread
From: arisawa @ 2001-12-09  8:22 UTC (permalink / raw)
  To: 9fans

Hello,

`Touch' change the size of file if is append only.

term% chmod +a x
term% ls -l x
a-rw-rw-r-- M 3 arisawa arisawa 1 Dec  9 16:59 x
term% touch x
term% ls -l x
a-rw-rw-r-- M 3 arisawa arisawa 2 Dec  9 17:05 x
term%

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


^ permalink raw reply	[flat|nested] 433+ messages in thread

* Re: [9fans] (no subject)
  2001-11-30 14:14 steve.simon
@ 2001-11-30 14:30 ` Boyd Roberts
  0 siblings, 0 replies; 433+ messages in thread
From: Boyd Roberts @ 2001-11-30 14:30 UTC (permalink / raw)
  To: 9fans

>     http://ftp.unicamp.br/pub/unix-c/utils/faces.tar.gz

Is it written in X11?  ie:  Is it the version that Rich
Burridge used to maintain?  If so, thanks, but no thanks.

I like Plan 9 faces/seemail just fine.

The X11 faces I do not like at all, oh Sam I am ...

I will not eat green eggs and spam (sic) ...




^ permalink raw reply	[flat|nested] 433+ messages in thread

* [9fans] (no subject)
@ 2001-11-30 14:14 steve.simon
  2001-11-30 14:30 ` Boyd Roberts
  0 siblings, 1 reply; 433+ messages in thread
From: steve.simon @ 2001-11-30 14:14 UTC (permalink / raw)
  To: 9fans


mailbox monitor and face viewer for sunview, X11, and news systems...

    http://ftp.unicamp.br/pub/unix-c/utils/faces.tar.gz

-Steve


----------------------------------------------------------------------
The contents of this communication are confidential to the normal user of
the email address to which it was sent.  If you have received this email
in error, any use, dissemination, forwarding, printing or copying of this
email is strictly prohibited.  If this is the case, please notify the
sender and delete this message.
----------------------------------------------------------------------



^ permalink raw reply	[flat|nested] 433+ messages in thread

* [9fans] (no subject)
@ 2001-11-01 21:27 presotto
  0 siblings, 0 replies; 433+ messages in thread
From: presotto @ 2001-11-01 21:27 UTC (permalink / raw)
  To: 9fans

You might also look at the virtual clock paper by Carr in an
SOSP proceeding from the 70's.


^ permalink raw reply	[flat|nested] 433+ messages in thread

* [9fans] (no subject)
@ 2001-11-01 21:26 presotto
  0 siblings, 0 replies; 433+ messages in thread
From: presotto @ 2001-11-01 21:26 UTC (permalink / raw)
  To: 9fans

the paper you're alluding to, I believe, was OSMOSIS, a modified
Plan 9 kernel, by Eran Gabber.


^ permalink raw reply	[flat|nested] 433+ messages in thread

* Re: [9fans] (no subject)
@ 2001-10-26 18:10 presotto
  0 siblings, 0 replies; 433+ messages in thread
From: presotto @ 2001-10-26 18:10 UTC (permalink / raw)
  To: 9fans

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

If you had added just 

dom=us-celstream.com
	ns=192.168.10.1

dnsdebug should have been able to resolve the us-celstream.com
addresses.  However, adding root entries is better.

cheers.

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

From: peh@us-celstream.com
To: ndb/dnsdebug@us-celstream.com, 9fans@cse.psu.edu
Subject: [9fans] (no subject)
Date: Fri, 26 Oct 2001 10:45:34 -0400
Message-ID: <200110270911.f9R9BXu19033@tuna.us-celstream.com>

Wow fast response!

/lib/ndb/local
database=
	file=/lib/ndb/local
	file=/lib/ndb/common

ipnet=int ip=192.168.0.0 ipmask=255.255.255.0
	ipgw=192.168.0.1
	dns=192.168.0.1
	smtp=smtp.us-celstream.com

ip=192.168.10.14 sys=chelan ether=00a0cc5cea15
	dom=chelan.us.internal.celstream.com

term% cat /net/ndb
ip=192.168.10.179 ipmask=255.255.255.0 ipgw=192.168.10.1
	dom=.internal.us-celstream.com
	dns=192.168.10.1
term% grep ndb termrc
ndb/cs
ndb/dns -r

No root servers but it does point to our local dns server.
Perhaps it can't resolve itself?

I added root servers and it now resolves. Thanks.
Pat

^ permalink raw reply	[flat|nested] 433+ messages in thread

* [9fans] (no subject)
@ 2001-10-26 14:45 peh
  0 siblings, 0 replies; 433+ messages in thread
From: peh @ 2001-10-26 14:45 UTC (permalink / raw)
  To: ndb/dnsdebug, 9fans

Wow fast response!

/lib/ndb/local
database=
	file=/lib/ndb/local
	file=/lib/ndb/common

ipnet=int ip=192.168.0.0 ipmask=255.255.255.0
	ipgw=192.168.0.1
	dns=192.168.0.1
	smtp=smtp.us-celstream.com

ip=192.168.10.14 sys=chelan ether=00a0cc5cea15
	dom=chelan.us.internal.celstream.com

term% cat /net/ndb
ip=192.168.10.179 ipmask=255.255.255.0 ipgw=192.168.10.1
	dom=.internal.us-celstream.com
	dns=192.168.10.1
term% grep ndb termrc
ndb/cs
ndb/dns -r

No root servers but it does point to our local dns server.
Perhaps it can't resolve itself?

I added root servers and it now resolves. Thanks.
Pat


^ permalink raw reply	[flat|nested] 433+ messages in thread

* [9fans] (no subject)
@ 2001-09-07 13:48 Peter Bosch
  0 siblings, 0 replies; 433+ messages in thread
From: Peter Bosch @ 2001-09-07 13:48 UTC (permalink / raw)
  To: 9fans

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

For your amusement...

peter.


[-- Attachment #2: I95.jpg --]
[-- Type: image/jpeg, Size: 830568 bytes --]

^ permalink raw reply	[flat|nested] 433+ messages in thread

* Re: [9fans] (no subject)
@ 2001-09-05  7:25 Fco.J.Ballesteros
  0 siblings, 0 replies; 433+ messages in thread
From: Fco.J.Ballesteros @ 2001-09-05  7:25 UTC (permalink / raw)
  To: 9fans

:  I'm going to build a file server with a cast off 300-or-so megabyte disk
:  (in addition to the real file server disks) that would contain the
:  bootstrap for the file server, and an 'emergency' stand-alone cpu server
:  that could be used to repair/copy/etc the actual file server disks.  I
:  can also see writing some tools to fix corrupted fake worms.

While you get your tools done, the configuration I'm using could
work for you. It's just two separate disks w/ a fake worm each.
Once a day I run a cron to update one of them with changes in the other.



^ permalink raw reply	[flat|nested] 433+ messages in thread

* Re: [9fans] (no subject)
  2001-09-04 13:30 Fco.J.Ballesteros
@ 2001-09-04 20:51 ` Martin Harriss
  0 siblings, 0 replies; 433+ messages in thread
From: Martin Harriss @ 2001-09-04 20:51 UTC (permalink / raw)
  To: 9fans

"Fco.J.Ballesteros" wrote:
>
> That's cool. BTW, I'm just wondering...

Indeed it is.

> Would a system crash while doing a (mirrowed) dump
> corrupt both disks at the same time?

 From reading Geoff's code it looks as if a crash during a block write
could leave the secondaries in a good state, but the master would be
incomplete.

> While I was trying to use a couple of ide disks to
> survive disk crashes, I thought it would be better
> not to use a real mirror because a crash at a bad
> moment could perhaps leave the cached worm unusable.
> (I had a crash while doing a dump on a cached worm and
>  the cached worm became unusable).

In the case of the worm file system, what happens if a sequence of
writes is interrupted? is the file system guaranteed to be consistent
after each write, or can an interrupted sequence destroy the file
system?  The experience above would suggest the latter.

> Am I missing something? A recover procedure I don't
> know of? Or perhaps some code in the mirror device tries
> to deal with that?

Don't see any code in there to do that.  I've also been playing with
disk morroring, and I added a 'resilver' command to copy a 'good' disk
to a 'bad' disk.  The hard part is knowing which is the good disk and
which is the bad.  If one of them goes bad while the system is running
it's easy - when you get the error you just mark that disk as bad.  But
it's impossible to know in cases when the power goes off just where you
were in the sequence of writes.  For something like a fake worm, where
speed is not a big issue, it may be worth while recording disk status in
some dedicated place on the disk for each block write.  One logical
volume manager that I am familiar with just "guesses" which side of the
mirror is good and lets fsck clean up the mess, but this is probably
impractical for a "worm" file system.

> Another question I have is can you rebuild your mirror
> device just by raw copying of one disk into another?

It looks that way from the code.  In fact, I've pretty much decided that
I'm going to build a file server with a cast off 300-or-so megabyte disk
(in addition to the real file server disks) that would contain the
bootstrap for the file server, and an 'emergency' stand-alone cpu server
that could be used to repair/copy/etc the actual file server disks.  I
can also see writing some tools to fix corrupted fake worms.

Martin

>   ------------------------------------------------------------------------
>
> Subject: [9fans] (no subject)
> Date: Tue, 4 Sep 2001 05:08:33 -0700
> From: geoff@collyer.net
> Reply-To: 9fans@cse.psu.edu
> To: 9fans@collyer.net
>
> I've fixed some bugs in the IDE file server (some latent, some new in
> the IDE code) and added a mirroring device.  I've tested it, it works
> and later today it will be my main file server.  The mirroring device
> is really very little code; the file server's elegant design is
> largely responsible for this.  Doing a dump of 457121 4K blocks from a
> cache device on h0 to a fake worm also on h0, mirrored on h1.0.0
> (a.k.a. h2) took 73 minutes, so I got 25,648,871 bytes per minute
> throughput.  I verified that the copy on h1.0.0 was correct.
>
> Here's my configuration:
>
>         config h0
>         service    fs
>         [ uninteresting ip configuration omitted ]
>         filsys main cp(h0)0.25f{p(h0)25.75p(h1.0.0)25.75}
>         filsys dump o
>         filsys other p(h1.0.0)0.25
>         ream other
>         ream main
>         end
>
> {} is the mirror device, analogous to () and [].  The first device
> inside {} is the master, any others are mirrors.  The code can be
> found at www.collyer.net/~geoff/9/.  I'll add some commentary on the
> changes later today.  They fall into several categories:
>
> - fixes to latent bugs.
> - addition of some missing switch cases for Devfworm, Devnone and Devide.
>   the file server could really use a device switch (rather than a lot of
>   switch statements scattered throughout the code).
>   in particular, device configuration strings are now printed better.
> - additional paranoia in the IDE code; specifying a non-existent drive
>   no longer causes a kernel page fault.
> - converted nemo's style back to the original style, and some tidying up.
> - probably vestigial paranoia traceable to hunting down the fpinit bug.
> - local configuration (e.g., timezone).  you'll want to crank MAXMEG up.
> - addition of the mirror device.


^ permalink raw reply	[flat|nested] 433+ messages in thread

* Re: [9fans] (no subject)
@ 2001-09-04 13:30 Fco.J.Ballesteros
  2001-09-04 20:51 ` Martin Harriss
  0 siblings, 1 reply; 433+ messages in thread
From: Fco.J.Ballesteros @ 2001-09-04 13:30 UTC (permalink / raw)
  To: 9fans

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

That's cool. BTW, I'm just wondering...

Would a system crash while doing a (mirrowed) dump
corrupt both disks at the same time?

While I was trying to use a couple of ide disks to
survive disk crashes, I thought it would be better
not to use a real mirror because a crash at a bad
moment could perhaps leave the cached worm unusable.
(I had a crash while doing a dump on a cached worm and
 the cached worm became unusable).

Am I missing something? A recover procedure I don't
know of? Or perhaps some code in the mirror device tries
to deal with that?

Another question I have is can you rebuild your mirror
device just by raw copying of one disk into another?






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

From: geoff@collyer.net
To: 9fans@collyer.net
Subject: [9fans] (no subject)
Date: Tue, 4 Sep 2001 05:08:33 -0700
Message-ID: <20010904120840.2D1C7199E3@mail.cse.psu.edu>

I've fixed some bugs in the IDE file server (some latent, some new in
the IDE code) and added a mirroring device.  I've tested it, it works
and later today it will be my main file server.  The mirroring device
is really very little code; the file server's elegant design is
largely responsible for this.  Doing a dump of 457121 4K blocks from a
cache device on h0 to a fake worm also on h0, mirrored on h1.0.0
(a.k.a. h2) took 73 minutes, so I got 25,648,871 bytes per minute
throughput.  I verified that the copy on h1.0.0 was correct.

Here's my configuration:

	config h0
	service    fs
	[ uninteresting ip configuration omitted ]
	filsys main cp(h0)0.25f{p(h0)25.75p(h1.0.0)25.75}
	filsys dump o
	filsys other p(h1.0.0)0.25
	ream other
	ream main
	end

{} is the mirror device, analogous to () and [].  The first device
inside {} is the master, any others are mirrors.  The code can be
found at www.collyer.net/~geoff/9/.  I'll add some commentary on the
changes later today.  They fall into several categories:

- fixes to latent bugs.
- addition of some missing switch cases for Devfworm, Devnone and Devide.
  the file server could really use a device switch (rather than a lot of
  switch statements scattered throughout the code).
  in particular, device configuration strings are now printed better.
- additional paranoia in the IDE code; specifying a non-existent drive
  no longer causes a kernel page fault.
- converted nemo's style back to the original style, and some tidying up.
- probably vestigial paranoia traceable to hunting down the fpinit bug.
- local configuration (e.g., timezone).  you'll want to crank MAXMEG up.
- addition of the mirror device.

^ permalink raw reply	[flat|nested] 433+ messages in thread

* [9fans] (no subject)
@ 2001-09-04 12:08 geoff
  0 siblings, 0 replies; 433+ messages in thread
From: geoff @ 2001-09-04 12:08 UTC (permalink / raw)
  To: 9fans

I've fixed some bugs in the IDE file server (some latent, some new in
the IDE code) and added a mirroring device.  I've tested it, it works
and later today it will be my main file server.  The mirroring device
is really very little code; the file server's elegant design is
largely responsible for this.  Doing a dump of 457121 4K blocks from a
cache device on h0 to a fake worm also on h0, mirrored on h1.0.0
(a.k.a. h2) took 73 minutes, so I got 25,648,871 bytes per minute
throughput.  I verified that the copy on h1.0.0 was correct.

Here's my configuration:

	config h0
	service    fs
	[ uninteresting ip configuration omitted ]
	filsys main cp(h0)0.25f{p(h0)25.75p(h1.0.0)25.75}
	filsys dump o
	filsys other p(h1.0.0)0.25
	ream other
	ream main
	end

{} is the mirror device, analogous to () and [].  The first device
inside {} is the master, any others are mirrors.  The code can be
found at www.collyer.net/~geoff/9/.  I'll add some commentary on the
changes later today.  They fall into several categories:

- fixes to latent bugs.
- addition of some missing switch cases for Devfworm, Devnone and Devide.
  the file server could really use a device switch (rather than a lot of
  switch statements scattered throughout the code).
  in particular, device configuration strings are now printed better.
- additional paranoia in the IDE code; specifying a non-existent drive
  no longer causes a kernel page fault.
- converted nemo's style back to the original style, and some tidying up.
- probably vestigial paranoia traceable to hunting down the fpinit bug.
- local configuration (e.g., timezone).  you'll want to crank MAXMEG up.
- addition of the mirror device.


^ permalink raw reply	[flat|nested] 433+ messages in thread

* [9fans] (no subject)
@ 2001-08-14 11:10 Usenet News system
  0 siblings, 0 replies; 433+ messages in thread
From: Usenet News system @ 2001-08-14 11:10 UTC (permalink / raw)
  To: 9fans



^ permalink raw reply	[flat|nested] 433+ messages in thread

* Re: [9fans] (no subject)
  2001-08-13  7:45 ` andrey mirtchovski
@ 2001-08-14  9:44   ` Ralph Corderoy
  0 siblings, 0 replies; 433+ messages in thread
From: Ralph Corderoy @ 2001-08-14  9:44 UTC (permalink / raw)
  To: 9fans

Hi Andrey,

>         p = pcimatch(nil, MATROX, MGA4xx);
>         if (0 && p)
>         ^^^^^^^^^^^
>                 print("MGA 4xx found : rev %d\n", p->rid);
> 
> i don't quite understand this part..

It looks like a `commented out' print statement used for debug.

The condition was originally `if (p)' so p was only derefenced for
p->rid if it wasn't 0.  Adding the `0 &&' prefix means the condition is
always false, 0 && n is always 0, so the print statement is never
executed.

If the author wants the debug again he can either change the 0 to a 1
or remove the `0 &&'.


Ralph.


^ permalink raw reply	[flat|nested] 433+ messages in thread

* Re: [9fans] (no subject)
  2001-08-12 21:38 Philippe Anel
@ 2001-08-13  7:45 ` andrey mirtchovski
  2001-08-14  9:44   ` Ralph Corderoy
  0 siblings, 1 reply; 433+ messages in thread
From: andrey mirtchovski @ 2001-08-13  7:45 UTC (permalink / raw)
  To: 9fans

from your matrox driver:

static Pcidev*
mgapcimatch(void)
{
        Pcidev* p;

        p = pcimatch(nil, MATROX, MGA4xx);
        if (0 && p)
        ^^^^^^^^^^^
                print("MGA 4xx found : rev %d\n", p->rid);
        return p;
}


i don't quite understand this part..

andrey


On Sun, 12 Aug 2001, Philippe Anel wrote:

> 
> Hi everybody out there,
> 
> 	I took the last week to write a driver for my Matrox G400.
> 	I'll send another files this week to support the G450.
>       	I think it wouldn't take much work to enhance the actual driver so that
> 	it supports the G200 serie. I'll give it a try once I get hold of this
> 	card (around the end of august).
> 
> 	I'm currently working on the 2d accel feature (which isn't supported
> 	as of yet).
> 	Though, the source code isn't very clean, and probably needs a complete
> 	rewrite, It works fairly well on my computer. I'll rewrite it properly
> 	some time later.
> 	At now, there only the 8 bits mode which works correctly.
> 	(Quite a lot of misfeatures in the end :()
> 
> 	Now, is there any project around regarding the OpenGL support ?, also,
> 	for the Overlays support ?.
> 
>   	Does someone know about a driver beeing under developpment for the Radeon
> 	video card (ATI). Or if it is already supported.
> 	Either way, does/will it support 2D acceleration features ?.
> 
>   	If none of this exists, I'd gladly start this project myself.
>   	I'll welcome any comment regarding this project.
> 
> Regards,
>   	Philippe Anel,
> 



^ permalink raw reply	[flat|nested] 433+ messages in thread

* [9fans] (no subject)
@ 2001-08-12 21:38 Philippe Anel
  2001-08-13  7:45 ` andrey mirtchovski
  0 siblings, 1 reply; 433+ messages in thread
From: Philippe Anel @ 2001-08-12 21:38 UTC (permalink / raw)
  To: 9fans

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


Hi everybody out there,

	I took the last week to write a driver for my Matrox G400.
	I'll send another files this week to support the G450.
      	I think it wouldn't take much work to enhance the actual driver so that
	it supports the G200 serie. I'll give it a try once I get hold of this
	card (around the end of august).

	I'm currently working on the 2d accel feature (which isn't supported
	as of yet).
	Though, the source code isn't very clean, and probably needs a complete
	rewrite, It works fairly well on my computer. I'll rewrite it properly
	some time later.
	At now, there only the 8 bits mode which works correctly.
	(Quite a lot of misfeatures in the end :()

	Now, is there any project around regarding the OpenGL support ?, also,
	for the Overlays support ?.

  	Does someone know about a driver beeing under developpment for the Radeon
	video card (ATI). Or if it is already supported.
	Either way, does/will it support 2D acceleration features ?.

  	If none of this exists, I'd gladly start this project myself.
  	I'll welcome any comment regarding this project.

Regards,
  	Philippe Anel,

[-- Attachment #2: vgamga4xx.c --]
[-- Type: text/plain, Size: 5330 bytes --]

/* Philippe Anel : philippe.anel@noos.fr */ 

#include "u.h"
#include "../port/lib.h"
#include "mem.h"
#include "dat.h"
#include "fns.h"
#include "io.h"
#include "../port/error.h"

#define	Image	IMAGE
#include <draw.h>
#include <memdraw.h>
#include <cursor.h>
#include "screen.h"

/*
 * Matrox G400 and G450.
 */

enum {
	/* pci chip manufacturer */
	MATROX		= 0x102B,

	/* agp/pci chip device id */
	MGA4xx		= 0x0525
};

static Pcidev*
mgapcimatch(void)
{
	Pcidev*	p;
	
	p = pcimatch(nil, MATROX, MGA4xx);
	if (0 && p)
		print("MGA 4xx found : rev %d\n", p->rid);
	return p;
}

static ulong
mga4xxlinear(VGAscr* scr, int* size, int* align)
{
	ulong aperture, oaperture;
	int oapsize, wasupamem;
	Pcidev *p;

	oaperture = scr->aperture;
	oapsize = scr->apsize;
	wasupamem = scr->isupamem;

	if(p = mgapcimatch()){
		aperture = p->mem[0].bar & ~0x0F;
		*size = 32*1024*1024;
	}
	else
		aperture = 0;

	if(wasupamem) {
		if(oaperture == aperture)
			return oaperture;
		upafree(oaperture, oapsize);
	}
	scr->isupamem = 0;

	aperture = upamalloc(aperture, *size, *align);
	if(aperture == 0){
		if(wasupamem && upamalloc(oaperture, oapsize, 0)) {
			aperture = oaperture;
			scr->isupamem = 1;
		}
		else
			scr->isupamem = 0;
	}
	else
		scr->isupamem = 1;

	return aperture;
}

static void
mga4xxenable(VGAscr* scr)
{
	Pcidev *	p;
	Physseg 	seg;
	int 		size, align;
	ulong 	aperture;

	/*
	 * Only once, can't be disabled for now.
	 * scr->io holds the virtual address of
	 * the MMIO registers.
	 */
	if(scr->io)
		return;

	p = mgapcimatch();
	if(p == nil)
		return;

	scr->io = upamalloc(p->mem[1].bar & ~0x0F, 16*1024, 0);
	if(scr->io == 0)
		return;

	memset(&seg, 0, sizeof(seg));
	seg.attr = SG_PHYSICAL;
	seg.name = smalloc(NAMELEN);
	snprint(seg.name, NAMELEN, "mga4xxmmio");
	seg.pa = scr->io;
	seg.size = p->mem[1].size;
	addphysseg(&seg);

	scr->io = (ulong)KADDR(scr->io);

	/* need to map frame buffer here too, so vga can find memory size */
	size = 32*1024*1024;
	align = 0;
	aperture = mga4xxlinear(scr, &size, &align);
	if(aperture) {
		scr->aperture = aperture;
		scr->apsize = size;
		memset(&seg, 0, sizeof(seg));
		seg.attr = SG_PHYSICAL;
		seg.name = smalloc(NAMELEN);
		snprint(seg.name, NAMELEN, "mga4xxscreen");
		seg.pa = aperture;
		seg.size = size;
		addphysseg(&seg);
	}
}

enum {
	Index		= 0x00,		/* Index */
	Data		= 0x0A,		/* Data */

	Cxlsb		= 0x0C,		/* Cursor X LSB */
	Cxmsb		= 0x0D,		/* Cursor X MSB */
	Cylsb		= 0x0E,		/* Cursor Y LSB */
	Cymsb		= 0x0F,		/* Cursor Y MSB */

	Icuradrl	= 0x04,		/* Cursor Base Address Low */	
	Icuradrh	= 0x05,		/* Cursor Base Address High */
	Icctl		= 0x06,		/* Indirect Cursor Control */
};

static void
dac4xxdisable(VGAscr* scr)
{
	uchar * dac4xx;
	
	if(scr->io == 0)
		return;

	dac4xx = KADDR(scr->io+0x3C00);
	
	*(dac4xx+Index) = Icctl;
	*(dac4xx+Data) = 0x00;
}

static void
dac4xxload(VGAscr* scr, Cursor* curs)
{
	int x, y;
	uchar *p;
	uchar * dac4xx;

	if(scr->io == 0)
		return;

	dac4xx = KADDR(scr->io+0x3C00);
	
	dac4xxdisable(scr);

	p = KADDR(scr->storage);
	for(y = 0; y < 64; y++){
		*p++ = 0;
		*p++ = 0;
		*p++ = 0;
		*p++ = 0;
		*p++ = 0;
		*p++ = 0;
		if(y <16){
			*p++ = curs->set[1+y*2]|curs->clr[1+2*y];
			*p++ = curs->set[y*2]|curs->clr[2*y];
		} else{
			*p++ = 0;
			*p++ = 0;
		}

		*p++ = 0;
		*p++ = 0;
		*p++ = 0;
		*p++ = 0;
		*p++ = 0;
		*p++ = 0;
		if(y <16){
			*p++ = curs->set[1+y*2];
			*p++ = curs->set[y*2];
		} else{
			*p++ = 0;
			*p++ = 0;
		}
	}
	scr->offset.x = 64 + curs->offset.x;
	scr->offset.y = 64 + curs->offset.y;

	*(dac4xx+Index) = Icctl;
	*(dac4xx+Data) = 0x03;
}

static int
dac4xxmove(VGAscr* scr, Point p)
{
	int 	x, y;
	uchar *	dac4xx;

	if(scr->io == 0)
		return 1;

	dac4xx = KADDR(scr->io + 0x3C00);

	x = p.x + scr->offset.x;
	y = p.y + scr->offset.y;

	*(dac4xx+Cxlsb) = x & 0xFF;
	*(dac4xx+Cxmsb) = (x>>8) & 0x0F;

	*(dac4xx+Cylsb) = y & 0xFF;
	*(dac4xx+Cymsb) = (y>>8) & 0x0F;

	return 0;
}

static void
dac4xxenable(VGAscr* scr)
{
	uchar *	dac4xx;
	ulong	storage;
	
	if(scr->io == 0)
		return;
	dac4xx = KADDR(scr->io+0x3C00);

	dac4xxdisable(scr);

	storage = (32*1024*1024 - 4096) & ~0x3ff;

	*(dac4xx+Index) = Icuradrl;
	*(dac4xx+Data) = 0xff & (storage >> 10);
	*(dac4xx+Index) = Icuradrh;
	*(dac4xx+Data) = 0xff & (storage >> 18);		

	scr->storage = (ulong) KADDR((ulong)scr->aperture + (ulong)storage);

	/* Show X11-Like Cursor */
	*(dac4xx+Index) = Icctl;
	*(dac4xx+Data) = 0x03;

	/* Cursor Color 0 : White */
	*(dac4xx+Index) = 0x08;
	*(dac4xx+Data)  = 0xff;
	*(dac4xx+Index) = 0x09;
	*(dac4xx+Data)  = 0xff;
	*(dac4xx+Index) = 0x0a;
	*(dac4xx+Data)  = 0xff;

	/* Cursor Color 1 : Black */
	*(dac4xx+Index) = 0x0c;
	*(dac4xx+Data)  = 0x00;
	*(dac4xx+Index) = 0x0d;
	*(dac4xx+Data)  = 0x00;
	*(dac4xx+Index) = 0x0e;
	*(dac4xx+Data)  = 0x00;

	/* Cursor Color 2 : Red */
	*(dac4xx+Index) = 0x10;
	*(dac4xx+Data)  = 0xff;
	*(dac4xx+Index) = 0x11;
	*(dac4xx+Data)  = 0x00;
	*(dac4xx+Index) = 0x12;
	*(dac4xx+Data)  = 0x00;

	/*
	 * Load, locate and enable the
	 * 64x64 cursor in 3-colour mode.
	 */
	dac4xxload(scr, &arrow);
	dac4xxmove(scr, ZP);
}

VGAdev vgamga4xxdev = {
	"mga4xx",

	mga4xxenable,		/* enable */
	0,			/* disable */
	0,			/* page */
	mga4xxlinear,		/* linear */
};

VGAcur vgamga4xxcur = {
	"mga4xxhwgc",
	dac4xxenable,
	dac4xxdisable,
	dac4xxload,
	dac4xxmove,
};

[-- Attachment #3: Mga4xx.c --]
[-- Type: text/plain, Size: 24772 bytes --]

/* Philippe Anel : philippe.anel@noos.fr */ 

#include <u.h>
#include <libc.h>
#include <bio.h>

#include "vga.h"
#include "pci.h"

/*
 * Matrox G4xx 3D graphics accelerators
 */
enum {
	Kilo				= 1024,
	Meg				= 1024*1024,
	
	MATROX			= 0x102B,		/* pci chip manufacturer */
	MGA4XX			= 0x0525,		/* pci chip device ids */

	/* Pci configuration space mapping */
	PCfgMgaFBAA		= 0x10,		/* Frame buffer Aperture Address */
	PCfgMgaCAA		= 0x14,		/* Control Aperture Address base */
	PCfgMgaIAA		= 0x18,		/* ILOAD Aperture base Address */
	PCfgMgaOption1	= 0x40,		/* Option Register 1 */
	PCfgMgaOption2	= 0x50,		/* Option Register 2 */
	PCfgMgaOption3	= 0x54,		/* Option Register 3 */
	PCfgMgaDevCtrl	= 0x04,		/* Device Control */

	/* control aperture offsets */
	DMAWIN			= 0x0000,		/* 7KByte Pseudo-DMA Window */

	STATUS0			= 0x1FC2,		/* Input Status 0 */
	STATUS1			= 0x1FDA,	/* Input Status 1 */
	
	SEQIDX			= 0x1FC4,		/* Sequencer Index */
	SEQDATA			= 0x1FC5,		/* Sequencer Data */

	MISC_W			= 0x1FC2,		/* Misc. WO */
	MISC_R			= 0x1FCC,	/* Misc. RO */

	GCTLIDX			= 0x1FCE,		/* Graphic Controler Index */
	GCTLDATA		= 0x1FCF,		/* Graphic Controler Data */

	CRTCIDX			= 0x1FD4,	/* CRTC Index */
	CRTCDATA		= 0x1FD5,	/* CRTC Data */

	CRTCEXTIDX		= 0x1FDE,		/* CRTC Extension Index */
	CRTCEXTDATA		= 0x1FDF,		/* CRTC Extension Data */
	
	RAMDACIDX		= 0x3C00,	/* RAMDAC registers Index */
	RAMDACDATA		= 0x3C0A,	/* RAMDAC Indexed Data */
	RAMDACPALDATA		= 0x3C01,

	ATTRIDX			= 0x1FC0,		/* Attribute Index */
	ATTRDATA		= 0x1FC1,		/* Attribute Data */

	CACHEFLUSH		= 0x1FFF,

	C2_CTL			= 0X3C10,
	MGA_STATUS		= 0X1E14,
	Z_DEPTH_ORG		= 0X1C0C,
	
};

typedef struct {
	Pcidev*	pci;
	int		devid;
	int		revid;
	
	ulong	mmio;
	ulong	mmfb;
	int		fbsize;
	ulong	iload;

	uchar	syspll_m;
	uchar	syspll_n;
	uchar	syspll_p;
	uchar	syspll_s;

	uchar	pixpll_m;
	uchar	pixpll_n;
	uchar	pixpll_p;
	uchar	pixpll_s;

	ulong	option1;
	ulong	option2;
	ulong	option3;

	/* From plan9.ini */
	uchar	sdram;
	uchar	colorkey;
	uchar	maskkey;
	ulong	maxpclk;

	uchar	graphics[9];	
	uchar	attribute[0x14];	
	uchar	sequencer[5];
	uchar	crtc[0x19];
	uchar	crtcext[9];

	ulong	htotal;
	ulong	hdispend;
	ulong	hblkstr;
	ulong	hblkend;
	ulong	hsyncstr;
	ulong	hsyncend;
	ulong	vtotal;
	ulong	vdispend;
	ulong	vblkstr;
	ulong	vblkend;
	ulong	vsyncstr;
	ulong	vsyncend;
	ulong	linecomp;
	ulong	hsyncsel;
	ulong	startadd;
	ulong	offset;
	ulong	maxscan;
	ulong 	curloc;
	ulong	prowscan;
	ulong	currowstr;
	ulong	currowend;
	ulong	curoff;
	ulong	undrow;
	ulong	curskew;
	ulong	conv2t4;
	ulong	interlace;
	ulong	hsyncdel;
	ulong	hdispskew;
	ulong	bytepan;
	ulong	dotclkrt;
	ulong	dword;
	ulong	wbmode;
	ulong	addwrap;
	ulong	selrowscan;
	ulong	cms;
	ulong	csynccen;
	ulong	hrsten;
	ulong	vrsten;
	ulong	vinten;
	ulong	vintclr;
	ulong	hsyncoff;
	ulong	vsyncoff;
	ulong	crtcrstN;
	ulong	mgamode;
	ulong	scale;
	ulong	hiprilvl;
	ulong	maxhipri;
	ulong	c2hiprilvl;
	ulong	c2maxhipri;
	ulong	misc;
	ulong	crtcprotect;
	ulong	winsize;
	ulong	winfreq;
} Mga;


static void
mgawrite32(Mga* mga, int index, ulong val)
{
	((ulong*)mga->mmio)[index] = val;
}

static ulong
mgaread32(Mga* mga, int index)
{
	return ((ulong*)mga->mmio)[index];
}

static void
mgawrite8(Mga* mga, int index, uchar val)
{
	((uchar*)mga->mmio)[index] = val;
}

static uchar
mgaread8(Mga* mga, int index)
{
	return ((uchar*)mga->mmio)[index];
}

static uchar
seqget(Mga* mga, int index)
{
	mgawrite8(mga, SEQIDX, index);
	return mgaread8(mga, SEQDATA);
}

static uchar
seqset(Mga* mga, int index, uchar set, uchar clr)
{
	uchar	tmp;

	mgawrite8(mga, SEQIDX, index);
	tmp = mgaread8(mga, SEQDATA);
	mgawrite8(mga, SEQIDX, index);
	mgawrite8(mga, SEQDATA, (tmp & ~clr) | set);
	return tmp;
}

static uchar
crtcget(Mga* mga, int index)
{
	mgawrite8(mga, CRTCIDX, index);
	return mgaread8(mga, CRTCDATA);
}

static uchar
crtcset(Mga* mga, int index, uchar set, uchar clr)
{
	uchar	tmp;

	mgawrite8(mga, CRTCIDX, index);
	tmp = mgaread8(mga, CRTCDATA);
	mgawrite8(mga, CRTCIDX, index);
	mgawrite8(mga, CRTCDATA, (tmp & ~clr) | set);
	return tmp;
}

static uchar
crtcextget(Mga* mga, int index)
{
	mgawrite8(mga, CRTCEXTIDX, index);
	return mgaread8(mga, CRTCEXTDATA);
}

static uchar
crtcextset(Mga* mga, int index, uchar set, uchar clr)
{
	uchar	tmp;

	mgawrite8(mga, CRTCEXTIDX, index);
	tmp = mgaread8(mga, CRTCEXTDATA);
	mgawrite8(mga, CRTCEXTIDX, index);
	mgawrite8(mga, CRTCEXTDATA, (tmp & ~clr) | set);
	return tmp;
}

static uchar
dacget(Mga* mga, int index)
{
	mgawrite8(mga, RAMDACIDX, index);
	return mgaread8(mga, RAMDACDATA);
}

static uchar
dacset(Mga* mga, int index, uchar set, uchar clr)
{
	uchar	tmp;

	mgawrite8(mga, RAMDACIDX, index);
	tmp = mgaread8(mga, RAMDACDATA);
	mgawrite8(mga, RAMDACIDX, index);
	mgawrite8(mga, RAMDACDATA, (tmp & ~clr) | set);
	return	tmp;
}

static uchar
gctlget(Mga* mga, int index)
{
	mgawrite8(mga, GCTLIDX, index);
	return mgaread8(mga, GCTLDATA);
}

static uchar
gctlset(Mga* mga, int index, uchar set, uchar clr)
{
	uchar	tmp;

	mgawrite8(mga, GCTLIDX, index);
	tmp = mgaread8(mga, GCTLDATA);
	mgawrite8(mga, GCTLIDX, index);
	mgawrite8(mga, GCTLDATA, (tmp & ~clr) | set);
	return	tmp;
}

static uchar
attrget(Mga* mga, int index)
{
	mgawrite8(mga, ATTRIDX, index);
	return mgaread8(mga, ATTRDATA);
}

static uchar
attrset(Mga* mga, int index, uchar set, uchar clr)
{
	uchar	tmp;

	mgawrite8(mga, ATTRIDX, index);
	tmp = mgaread8(mga, ATTRDATA);
	mgawrite8(mga, ATTRIDX, index);
	mgawrite8(mga, ATTRDATA, (tmp & ~clr) | set);
	return	tmp;
}

static uchar
miscget(Mga* mga)
{
	return mgaread8(mga, MISC_R);
}

static uchar
miscset(Mga* mga, uchar set, uchar clr)
{
	uchar	tmp;

	tmp = mgaread8(mga, MISC_R);
	mgawrite8(mga, MISC_W, (tmp & ~clr) | set);
	return	tmp;
}

/* ************************************************************ */

static void
dump_all_regs(Mga* mga)
{
	int	i;

	for (i = 0; i < 25; i++)
		trace("crtc[%d] = 0x%x\n", i, crtcget(mga, i));
	for (i = 0; i < 9; i++)
		trace("crtcext[%d] = 0x%x\n", i, crtcextget(mga, i));
	for (i = 0; i < 5; i++)
		trace("seq[%d] = 0x%x\n", i, seqget(mga, i));
	for (i = 0; i < 9; i++)
		trace("gctl[%d] = 0x%x\n", i, gctlget(mga, i));
	trace("misc = 0x%x\n", mgaread8(mga, MISC_R));
	for (i = 0; i < 0x87; i++)
		trace("dac[%d] = 0x%x\n", i, dacget(mga, i));
}

/* ************************************************************ */

static void
dump(Vga* vga, Ctlr* ctlr)
{
	dump_all_regs(vga->private);
	ctlr->flag |= Fdump;
}

static void
mapmga4xx(Vga* vga, Ctlr* ctlr)
{
	int 		f;
	long 		m;
	Mga *	mga;

	if(vga->private == nil)
		error("%s: g4xxio: no *mga4xx\n", ctlr->name);
	mga = vga->private;

	f = open("#v/vgactl", OWRITE);
	if(f < 0)
		error("%s: can't open vgactl\n", ctlr->name);

	if(write(f, "type mga4xx", 11) != 11)
		error("%s: can't set mga type\n", ctlr->name);
	
	m = segattach(0, "mga4xxmmio", 0, 16*Kilo);
	if(m == -1)
		error("%s: can't attach mga4xxmmio segment\n", ctlr->name);
	mga->mmio = m;
	trace("%s: mmio at 0x%lx\n", ctlr->name, mga->mmio);

	m = segattach(0, "mga4xxscreen", 0, 32*Meg);
	if(m == -1)
		error("%s: can't attach mga4xxscreen segment\n", ctlr->name);
	mga->mmfb = m;
	trace("%s: frame buffer at 0x%lx\n", ctlr->name, mga->mmfb);

	/* TODO : When needed ... map ILOAD too ... */
}

static void
snarf(Vga* vga, Ctlr* ctlr)
{
	int 	i, k, n;
	uchar *	p;
	uchar	x[16];
	Pcidev *	pci;
	Mga *	mga;
	uchar	crtcext3;

	trace("%s->snarf\n", ctlr->name);
	if(vga->private == nil) {
		pci = pcimatch(nil, MATROX, MGA4XX);
		if(pci == nil)
			error("%s: no Pcidev with Vid=0x102B, Did=0x0525\n", ctlr->name);

		trace("%s: G4%d0 rev %d\n", ctlr->name, pci->rid&0x80?5:0, pci->rid&(~0x80));
		i = pcicfgr32(pci, PCfgMgaDevCtrl);
		if ((i & 2) != 2)
			error("%s: Memory Space not enabled ... Aborting ...\n", ctlr->name);	

		vga->private = alloc(sizeof(Mga));
		mga = (Mga*)vga->private;
		mga->devid = 	pci->did;
		mga->revid =	pci->rid;	
		mga->pci = 	pci;

		mapmga4xx(vga, ctlr);
	}
	else {
		mga = (Mga*)vga->private;
	}

	/* Find out how much memory is here, some multiple of 2Meg */

	/* First Set MGA Mode ... */
	crtcext3 = crtcextset(mga, 3, 0x80, 0xff);

	p = (uchar*)mga->mmfb;
	n = 16;
	for (i = 0; i < n; i++) {
		k = (2*i+1)*Meg;
		p[k] = 0;
		p[k] = i+1;
		*((uchar*)(mga->mmio + CACHEFLUSH)) = 0;
		x[i] = p[k];
		trace("x[%d]=%d\n", i, x[i]);
	}
	for(i = 1; i < n; i++)
		if(x[i] != i+1)
			break;
	vga->vmz = mga->fbsize = 2*i*Meg;
	trace("probe found %d megabytes\n", 2*i);

	crtcextset(mga, 3, crtcext3, 0xff);

	ctlr->flag |= Fsnarf;
}

static void
options(Vga* vga, Ctlr* ctlr)
{
	Mode *mode;

	mode = vga->mode;
	if(mode->x % 128){
		mode->x = (mode->x/128)*128;
		sprint(mode->size, "%dx%dx%d", mode->x, mode->y, mode->z);
	}
	ctlr->flag |= Foptions;
}

/*
	calcclock - Calculate the PLL settings (m, n, p, s).
*/
static double
calcclock(Mga* mga, long Fneeded)
{
	double		Fpll;
	double		Fvco;
	double 		Fref;
	int		pixpll_m_min;
	int		pixpll_m_max;
	int		pixpll_n_min;
	int		pixpll_n_max;
	int		pixpll_p_max;
	int		pll_min;
	int		pll_max;
	double 		Ferr, Fcalc;
	int		m, n, p;
		
	/* These values are taken from Matrox G400 Specification - p 4-91 */
	Fref     	= 27000000.0;
	pixpll_n_min 	= 7;
	pixpll_n_max 	= 127;
	pixpll_m_min	= 1;
	pixpll_m_max	= 31;
	pixpll_p_max 	= 7;
	pll_min		= 50000;
	pll_max		= mga->maxpclk;

	if (Fneeded < pll_min)
		error("mga: Too little Frequency %ld : Minimum supported by PLL is %d", 
			Fneeded, pll_min);

	if (Fneeded > pll_max)
		error("mga: Too big Frequency %ld : Maximum supported by PLL is %d",
			Fneeded, pll_max);

	Fvco = ( double ) Fneeded;
	for (p = 0;  p <= pixpll_p_max && Fvco < pll_max; p = p * 2 + 1, Fvco *= 2.0)
		;
	mga->pixpll_p = p;

	Ferr = Fneeded;
	for ( m = pixpll_m_min ; m <= pixpll_m_max ; m++ )
		for ( n = pixpll_n_min; n <= pixpll_n_max; n++ )
		{ 
			Fcalc = Fref * (n + 1) / (m + 1) ;

			/*
			 * Pick the closest frequency.
			 */
			if ( abs(Fcalc - Fvco) < Ferr ) {
				Ferr = abs(Fcalc - Fvco);
				mga->pixpll_m = m;
				mga->pixpll_n = n;
			}
		}
	
	Fvco = Fref * (mga->pixpll_n + 1) / (mga->pixpll_m + 1);

	if ( (50000000.0 <= Fvco) && (Fvco < 110000000.0) )
		mga->pixpll_p |= 0;	
	if ( (110000000.0 <= Fvco) && (Fvco < 170000000.0) )
		mga->pixpll_p |= (1<<3);	
	if ( (170000000.0 <= Fvco) && (Fvco < 240000000.0) )
		mga->pixpll_p |= (2<<3);	
	if ( (240000000.0 <= Fvco) )
		mga->pixpll_p |= (3<<3);	

	Fpll = Fvco / (p + 1);

	return Fpll;
}

static void
init(Vga* vga, Ctlr* ctlr)
{
	Mode*	mode;
	Mga*	mga;
	double	Fpll;
	Ctlr*	c;
	int	i;
	ulong	t;

	mga = vga->private;
	mode = vga->mode;

	trace("mga mmio at %lx\n", mga->mmio);

	ctlr->flag |= Ulinear;

	if ((mode->z != 32) && (mode->z != 8))
		error("depth %d not supported !\n", mode->z);

	if (mode->interlace)
		error("interlaced mode not supported !\n");

	trace("%s: Initializing mode %dx%dx%d on %s\n", ctlr->name, mode->x, mode->y, mode->z, mode->type);
	trace("%s: Suggested Dot Clock : %d\n", 	ctlr->name, mode->frequency);
	trace("%s: Horizontal Total = %d\n", 		ctlr->name, mode->ht);
	trace("%s: Start Horizontal Blank = %d\n", 	ctlr->name, mode->shb);
	trace("%s: End Horizontal Blank = %d\n", 	ctlr->name, mode->ehb);
	trace("%s: Vertical Total = %d\n", 		ctlr->name, mode->vt);
	trace("%s: Vertical Retrace Start = %d\n", 	ctlr->name, mode->vrs);
	trace("%s: Vertical Retrace End = %d\n", 	ctlr->name, mode->vre);
	trace("%s: Start Horizontal Sync = %d\n", 	ctlr->name, mode->shs);
	trace("%s: End Horizontal Sync = %d\n", 	ctlr->name, mode->ehs);
	trace("%s: HSync = %c\n", 			ctlr->name, mode->hsync);
	trace("%s: VSync = %c\n", 			ctlr->name, mode->vsync);
	trace("%s: Interlace = %d\n", 			ctlr->name, mode->interlace);

	mga->maxpclk	= 300000000;

	Fpll = calcclock(mga, mode->frequency);
	trace("Fpll set to %f\n", Fpll);
	trace("pixclks : n = %d m = %d p = %d\n", mga->pixpll_n, mga->pixpll_m, mga->pixpll_p & 0x7);

	trace("PCI Option1 = 0x%x\n", pcicfgr32(mga->pci, PCfgMgaOption1));
	trace("PCI Option2 = 0x%x\n", pcicfgr32(mga->pci, PCfgMgaOption2));
	trace("PCI Option3 = 0x%x\n", pcicfgr32(mga->pci, PCfgMgaOption3));

	mga->htotal =		(mode->ht >> 3) - 5;
	mga->hdispend =		(mode->x >> 3) - 1;
	if (1)
	{
		mga->hblkstr =		mga->hdispend; 		/* (mode->shb >> 3); */
		mga->hblkend =		mga->htotal + 4;	/* (mode->ehb >> 3); */
	} else
	{
		mga->hblkstr =		(mode->shb >> 3);
		mga->hblkend =		(mode->ehb >> 3); 
	}
	mga->hsyncstr =		(mode->shs >> 3);
	mga->hsyncend =		(mode->ehs >> 3);
	mga->hsyncdel = 	0;
	mga->vtotal =		mode->vt - 2;
	mga->vdispend = 	mode->y - 1;
	mga->vblkstr = 		mode->y - 1;
	mga->vblkend = 		mode->vt - 1;
	mga->vsyncstr = 	mode->vrs;
	mga->vsyncend = 	mode->vre;
	mga->linecomp =		mode->y;
	mga->hsyncsel = 	0;	/* Do not double lines ... */
	mga->startadd =		0;
	mga->offset =		(mode->x * mode->z) / 128;
	/* No Zoom */
	mga->maxscan = 		0;
	/* Not used in Power Graphic mode */
	mga->curloc =		0;
	mga->prowscan = 	0;
	mga->currowstr = 	0;
	mga->currowend = 	0;
	mga->curoff = 		1;
	mga->undrow = 		0;
	mga->curskew = 		0;
	mga->conv2t4 = 		0;
	mga->interlace =	0;
	mga->hdispskew =	0;
	mga->bytepan = 		0;
	mga->dotclkrt = 	0;
	mga->dword =		0;
	mga->wbmode =		1;
	mga->addwrap = 		0;	/* Not Used ! */
	mga->selrowscan =	1;
	mga->cms =		1;
	mga->csynccen =		0; 	/* Disable composite sync */

	/* VIDRST Pin */
	mga->hrsten =		1;
	mga->vrsten =		1;

	/* vertical interrupt control */
	mga->vinten = 		1;
	mga->vintclr = 		1;

	/* Let [hv]sync run freely */
	mga->hsyncoff =		0;
	mga->vsyncoff =		0;

	mga->crtcrstN =		1;

	mga->mgamode = 		1;
	mga->scale =		(mode->z == 8) ? 0 : 3;	/* 8 or 32 bits mode */
	
	mga->crtcprotect =	1;
	mga->winsize = 		0;
	mga->winfreq = 		0;

	if ((mga->htotal == 0)
	    || (mga->hblkend <= (mga->hblkstr + 1))
	    || ((mga->htotal - mga->hdispend) == 0)
	    || ((mga->htotal - mga->bytepan + 2) <= mga->hdispend)
	    || (mga->hsyncstr <= (mga->hdispend + 2))
	    || (mga->vtotal == 0))
	{
		error("Invalid Power Graphic Mode :\n"
		      "mga->htotal = %ld\n"
		      "mga->hdispend = %ld\n"
		      "mga->hblkstr = %ld\n"
		      "mga->hblkend = %ld\n"
		      "mga->hsyncstr = %ld\n"
		      "mga->hsyncend = %ld\n"
		      "mga->hsyncdel = %ld\n"
		      "mga->vtotal = %ld\n"
		      "mga->vdispend = %ld\n"
		      "mga->vblkstr = %ld\n"
		      "mga->vblkend = %ld\n"
		      "mga->vsyncstr = %ld\n"
		      "mga->vsyncend = %ld\n"
		      "mga->linecomp = %ld\n",
		      mga->htotal,
		      mga->hdispend,
		      mga->hblkstr,
		      mga->hblkend,
		      mga->hsyncstr,
		      mga->hsyncend,
		      mga->hsyncdel,
		      mga->vtotal,
		      mga->vdispend,
		      mga->vblkstr,
		      mga->vblkend,
		      mga->vsyncstr,
		      mga->vsyncend,
		      mga->linecomp
		      );
	}

	mga->hiprilvl = 0;
	mga->maxhipri = 0;
	mga->c2hiprilvl = 0;
	mga->c2maxhipri = 0;

	mga->misc = ((mode->hsync != '-')?0:(1<<6)) | ((mode->vsync != '-')?0:(1<<7));

	mga->crtc[0x00] = 0xff & mga->htotal;
	mga->crtc[0x01] = 0xff & mga->hdispend;
	mga->crtc[0x02] = 0xff & mga->hblkstr;
	mga->crtc[0x03] = (0x1f & mga->hblkend) 
		| ((0x03 & mga->hdispskew) << 5)
		| 0x80	/* cf 3-304 */
		;
	mga->crtc[0x04] = 0xff & mga->hsyncstr;
	mga->crtc[0x05] = (0x1f & mga->hsyncend) 
		| ((0x03 & mga->hsyncdel) << 5) 
		| ((0x01 & (mga->hblkend >> 5)) << 7)
		;
	mga->crtc[0x06] = 0xff & mga->vtotal;
	t = ((0x01 & (mga->vtotal >> 8)) << 0)
	  | ((0x01 & (mga->vdispend >> 8)) << 1)
	  | ((0x01 & (mga->vsyncstr >> 8)) << 2)
	  | ((0x01 & (mga->vblkstr >> 8)) << 3)
	  | ((0x01 & (mga->linecomp >> 8)) << 4)
	  | ((0x01 & (mga->vtotal >> 9)) << 5)
	  | ((0x01 & (mga->vdispend >> 9)) << 6)
	  | ((0x01 & (mga->vsyncstr >> 9)) << 7)
	  ;
	mga->crtc[0x07] = 0xff & t;
	trace("*************");
	trace("crtc 0x07 = %lx\n", t);
	trace("mga->vtotal = %lx\n", mga->vtotal);
	trace("mga->vdispend = %lx\n", mga->vdispend);
	trace("mga->vsyncstr = %lx\n", mga->vsyncstr);
	trace("mga->vblkstr = %lx\n", mga->vblkstr);
	trace("mga->linecomp = %lx\n", mga->linecomp);
	trace("*************");

	mga->crtc[0x08] = (0x1f & mga->prowscan) 
		| ((0x03 & mga->bytepan) << 5);
	mga->crtc[0x09] = (0x1f & mga->maxscan) 
		| ((0x01 & (mga->vblkstr >> 9)) << 5)
		| ((0x01 & (mga->linecomp >> 9)) << 6)
		| ((0x01 & mga->conv2t4) << 7)
		;
	mga->crtc[0x0a] = (0x1f & mga->currowstr)
		| ((0x01 & mga->curoff) << 5)
		;
	mga->crtc[0x0b] = (0x1f & mga->currowend)
		| ((0x03 & mga->curskew) << 5)
		;
	mga->crtc[0x0c] = 0xff & (mga->startadd >> 8);
	mga->crtc[0x0d] = 0xff & mga->startadd;
	mga->crtc[0x0e] = 0xff & (mga->curloc >> 8);
	mga->crtc[0x0f] = 0xff & mga->curloc;
	mga->crtc[0x10] = 0xff & mga->vsyncstr;
	mga->crtc[0x11] = (0x0f & mga->vsyncend)
		| ((0x01 & mga->vintclr) << 4)
		| ((0x01 & mga->vinten) << 5)
		| ((0x01 & mga->crtcprotect) << 7)
		;
	mga->crtc[0x12] = 0xff & mga->vdispend;
	mga->crtc[0x13] = 0xff & mga->offset;
	mga->crtc[0x14] = 0x1f & mga->undrow;	/* vga only */
	mga->crtc[0x15] = 0xff & mga->vblkstr;
	mga->crtc[0x16] = 0xff & mga->vblkend;
	mga->crtc[0x17] = ((0x01 & mga->cms) << 0)
		| ((0x01 & mga->selrowscan) << 1)
		| ((0x01 & mga->hsyncsel) << 2)
		| ((0x01 & mga->addwrap) << 5)
		| ((0x01 & mga->wbmode) << 6)
		| ((0x01 & mga->crtcrstN) << 7)
		;
	mga->crtc[0x18] = mga->linecomp;
	
	mga->crtcext[0] = (0x0f & (mga->startadd >> 16))
		| ((0x03 & (mga->offset >> 8)) << 4)
		| ((0x01 & (mga->startadd >> 20)) << 6)
		| ((0x01 & mga->interlace) << 7)
		;
	mga->crtcext[1] = ((0x01 & (mga->htotal >> 8)) << 0)
		| ((0x01 & (mga->hblkstr >> 8)) << 1)
		| ((0x01 & (mga->hsyncstr >> 8)) << 2)
		| ((0x01 & mga->hrsten) << 3)
		| ((0x01 & mga->hsyncoff) << 4)
		| ((0x01 & mga->vsyncoff) << 5)
		| ((0x01 & (mga->hblkend >> 6)) << 6)
		| ((0x01 & mga->vrsten) << 7)
		;
	mga->crtcext[2] = ((0x03 & (mga->vtotal >> 10)) << 0)
		| ((0x01 & (mga->vdispend >> 10)) << 2)
		| ((0x03 & (mga->vblkstr >> 10)) << 3)
		| ((0x03 & (mga->vsyncstr >> 10)) << 5)
		| ((0x01 & (mga->linecomp >> 10)) << 7)
		;
	mga->crtcext[3] = ((0x07 & mga->scale) << 0)
		| ((0x01 & mga->csynccen) << 6)
		| ((0x01 & mga->mgamode) << 7)
		;
	mga->crtcext[4] = 0;	/* memory page ... not used in Power Graphic Mode */
	mga->crtcext[5] = 0;	/* Not used in interlaced mode */
	mga->crtcext[6] = ((0x07 & mga->hiprilvl) << 0)
		| ((0x07 & mga->maxhipri) << 4)
		;
	mga->crtcext[7] = ((0x07 & mga->winsize) << 1)
		| ((0x07 & mga->winfreq) << 5)
		;
	mga->crtcext[8] = (0x01 & (mga->startadd >> 21)) << 0;

	/* Initialize Sequencer */
	mga->sequencer[0] = 0;
	mga->sequencer[1] = 0;
	mga->sequencer[2] = 0x03;
	mga->sequencer[3] = 0;
	mga->sequencer[4] = 0x02;

	/* Graphic Control registers are ignored when not using 0xA0000 aperture */	
	for (i = 0; i < 9; i++)
		mga->graphics[i] = 0;	

	/* The Attribute Controler is not available in Power Graphics mode */
	for (i = 0; i < 0x15; i++)
		mga->attribute[i] = i;	

	/* disable vga load (want to do fields in different order) */
	for(c = vga->link; c; c = c->link)
		if (strncmp(c->name, "vga", 3) == 0)
			c->load = nil;
}

enum
{
	Seq_ClockingMode =	1,
		Dotmode =	(1<<0),
		Shftldrt =	(1<<2),
		Dotclkrt =	(1<<3),
		Shiftfour =	(1<<4),
		Scroff =	(1<<5),

	CrtcExt_Horizontcount =	1,
		Htotal =	(1<<0),
		Hblkstr =	(1<<1),
		Hsyncstr =	(1<<2),
		Hrsten =	(1<<3),
		Hsyncoff =	(1<<4),
		Vsyncoff =	(1<<5),
		Hblkend =	(1<<6),
		Vrsten =	(1<<7),

	CrtcExt_Miscellaneous =	3,
		Mgamode =	(1<<7),

	Dac_Xpixclkctrl =	0x1a,
		Pixclksl = 		(3<<0),
		Pixclkdis =	(1<<2),
		Pixpllpdn =	(1<<3),

	Dac_Xpixpllstat =	0x4f,
		Pixlock = 		(1<<6),
	
	Dac_Xpixpllan =		0x45,
	Dac_Xpixpllbn =		0x49,
	Dac_Xpixpllcn =		0x4d,

	Dac_Xpixpllam =		0x44, 
	Dac_Xpixpllbm =		0x48,
	Dac_Xpixpllcm =		0x4c,

	Dac_Xpixpllap =		0x46,
	Dac_Xpixpllbp =		0x4a,
	Dac_Xpixpllcp =		0x4e,

	Dac_Xmulctrl =		0x19,
		ColorDepth =	(7<<0),
			_8bitsPerPixel = 	0,
			_15bitsPerPixel =	1,
			_16bitsPerPixel =	2,
			_24bitsPerPixel =	3,
			_32bitsPerPixelWithOv = 4,
			_32bitsPerPixel	=	7,

	Dac_Xpanelmode =	0x1f,

	Dac_Xmiscctrl =		0x1e,
		Dacpdn =	(1<<0),
		Mfcsel =	(3<<1),
		Vga8dac =	(1<<3),
		Ramcs =		(1<<4),
		Vdoutsel =	(7<<5),

	Dac_Xcurctrl =		0x06,
		CursorDis = 	0,
		Cursor3Color = 	1,
		CursorXGA = 	2,
		CursorX11 = 	3,
		Cursor16Color = 4,

	Dac_Xzoomctrl =		0x38,

	Misc_loaddsel =		(1<<0),
	Misc_rammapen =		(1<<1),
	Misc_clksel =		(3<<2),
	Misc_videodis =		(1<<4),
	Misc_hpgoddev = 	(1<<5),
	Misc_hsyncpol =		(1<<6),
	Misc_vsyncpol =		(1<<7),
};

static void
load(Vga* vga, Ctlr* ctlr)
{
	Mga*	mga;
	int	i;
	uchar*	p;
	Mode*	mode;
	uchar	cursor;

	mga = vga->private;
	mode = vga->mode;

	trace("mga: Loading ...\n");
	dump_all_regs(mga);

	trace("mga mmio at %lx\n", mga->mmio);


	trace("mga: loading vga registers ...\n" );

	/* Initialize Sequencer registers */
	for(i = 0; i < 5; i++)
		seqset(mga, i, mga->sequencer[i], 0xff);

	/* Initialize Attribute register */
	for(i = 0; i < 0x15; i++)
		attrset(mga, i, mga->attribute[i], 0xff);

	/* Initialize Graphic Control registers */
	for(i = 0; i < 9; i++)
		gctlset(mga, i, mga->graphics[i], 0xff);

	/* Wait VSYNC */
	while (mgaread8(mga, STATUS1) & 0x08);
	while (! (mgaread8(mga, STATUS1) & ~0x08));

	/* Turn off the video. */
	seqset(mga, Seq_ClockingMode, Scroff, 0);

	/* Crtc2 Off */
	mgawrite32(mga, C2_CTL, 0);

	/* Disable Cursor */
	cursor = dacset(mga, Dac_Xcurctrl, CursorDis, 0xff);

	/* Pixel Pll UP and set Pixel clock source to Pixel Clock PLL */
	dacset(mga, Dac_Xpixclkctrl, 0x01 | 0x08, 0x0f);

	trace("mga: waiting for the clock source becomes stable ...\n");
	while ((dacget(mga, Dac_Xpixpllstat) & Pixlock) != Pixlock)
		;
	trace("mga: pixpll locked !\n");

	/* Enable LUT, Disable MAFC */
	dacset(mga, Dac_Xmiscctrl, Ramcs | Mfcsel, Vdoutsel);

	/* Initialize Z Buffer ... (useful?) */
	mgawrite32(mga, Z_DEPTH_ORG, 0);

	/* Disable Dac */
	dacset(mga, Dac_Xmiscctrl, 0, Dacpdn);

	/* Initialize Panel Mode */
	dacset(mga, Dac_Xpanelmode, 0, 0xff);

	/* Disable the PIXCLK and set Pixel clock source to Pixel Clock PLL */
	dacset(mga, Dac_Xpixclkctrl, Pixclkdis | 0x01, 0x3);

	/* Disable mapping of the memory */ 
	miscset(mga, 0, Misc_rammapen);

	/* Enable 8 bit palette */
	dacset(mga, Dac_Xmiscctrl, Vga8dac, 0);

	/* Select MGA Pixel Clock */
	miscset(mga, Misc_clksel, 0);

	/* Wait */
	for (i = 0; i < 50; i++)
		mgaread32(mga, MGA_STATUS);

	/* Reprogram the desired PLL registers */
	dacset(mga, Dac_Xpixpllcm, mga->pixpll_m, 0xff);
	dacset(mga, Dac_Xpixpllcn, mga->pixpll_n, 0xff);
	dacset(mga, Dac_Xpixpllcp, mga->pixpll_p, 0xff);
	
	/* Wait until new clock becomes stable */
	trace("mga: waiting for the clock source becomes stable ...\n");
	while ((dacget(mga, Dac_Xpixpllstat) & Pixlock) != Pixlock)
		;
	trace("mga: pixpll locked !\n");

	/* Enable Pixel Clock Oscillation */
	dacset(mga, Dac_Xpixclkctrl, 0, Pixclkdis);

	/* Enable Dac */
	dacset(mga, Dac_Xmiscctrl, Dacpdn, 0);

	/* Set Video Mode */
	if (mode->z != 8)
		dacset(mga, Dac_Xmulctrl, _32bitsPerPixel, ColorDepth);	/* 32 bits mode ... */
	else
		dacset(mga, Dac_Xmulctrl, _8bitsPerPixel, ColorDepth);	/* 8 bits mode ... */

	/* Wait */
	for (i = 0; i < 50; i++)
		mgaread32(mga, MGA_STATUS);

	/* Set Video Mode */
	if (mode->z != 8)
		dacset(mga, Dac_Xmulctrl, _32bitsPerPixel, ColorDepth);	/* 32 bits mode ... */
	else
		dacset(mga, Dac_Xmulctrl, _8bitsPerPixel, ColorDepth);	/* 8 bits mode ... */

	/* Wait until new clock becomes stable */
	trace("mga: waiting for the clock source becomes stable ...\n");
	while ((dacget(mga, Dac_Xpixpllstat) & Pixlock) != Pixlock)
		;
	trace("mga: pixpll locked !\n");

	/* Initialize CRTC registers and remove irq */
	crtcset(mga, 0x11, (1<<4), (1<<5)|0x80);
	for (i = 0; i < 25; i++)
		crtcset(mga, i, mga->crtc[i], 0xff);

	/* Initialize CRTC Extension registers */
	for (i = 0; i < 9; i++)
		crtcextset(mga, i, mga->crtcext[i], 0xff);

	/* Initialize Palette */
	mgawrite8(mga, RAMDACIDX, 0);
	for (i = 0; i < 0xff; i++)
		mgawrite8(mga, RAMDACPALDATA, i);

	/* Disable Zoom */
	dacset(mga, Dac_Xzoomctrl, 0, 0xff);

	/* Enable mga mode again ... Just in case :) */
	crtcextset(mga, CrtcExt_Miscellaneous, Mgamode, 0);

	/* Set final misc ... enable mapping ... */
	miscset(mga, mga->misc | Misc_rammapen, 0);

	/* Enable Screen */
	seqset(mga, 1, 0, 0xff);

	p = (uchar*)mga->mmfb;
	for (i = 0; i < mga->fbsize; i++)
		*p++ = (0xff & i);

	trace("mga: Loaded !\n" );
	dump_all_regs(mga);

	trace("mga: Loaded [bis]!\n" );

	/* Reenable Cursor */
	dacset(mga, Dac_Xcurctrl, cursor, 0xff);

	ctlr->flag |= Fload;
}

Ctlr mga4xx = {
	"mga4xx",			/* name */
	snarf,				/* snarf */
	options,				/* options */
	init,					/* init */
	load,					/* load */
	dump,				/* dump */
};

Ctlr mga4xxhwgc = {
	"mga4xxhwgc",		/* name */
	0,					/* snarf */
	0,					/* options */
	0,					/* init */
	0,					/* load */
	dump,				/* dump */
};

^ permalink raw reply	[flat|nested] 433+ messages in thread

* [9fans] (no subject)
@ 2001-08-05 14:02 jmk
  0 siblings, 0 replies; 433+ messages in thread
From: jmk @ 2001-08-05 14:02 UTC (permalink / raw)
  To: 9fans

mail 9fans
Subject: Re: Lucent

Oops, I mistyped 'beleaguered', the headline had the
spelling correct.


^ permalink raw reply	[flat|nested] 433+ messages in thread

* Re: [9fans] (no subject)
  2001-05-20 19:57       ` Richard Elberger
@ 2001-05-21  4:56         ` Jonathan Sergent
  0 siblings, 0 replies; 433+ messages in thread
From: Jonathan Sergent @ 2001-05-21  4:56 UTC (permalink / raw)
  To: 9fans

Richard Elberger:

> Looks pretty normal, hope you can read japanese.
> http://online.plathome.co.jp/cgi-bin/category.phtml?parent='7019'&rows=1&app
> end=7019&kitem=1164008700009&vitem=1&details=1
> 
> -- rich
> 
>> A personal email to me suggested the Sun ``crossbow'' mouse; this
>> looks intriguing, but I can't seem to find a picture of one online
>> (the only pictures that do exist seem to be taken from so far away
>> that one can't really make out what the mouse looks like...).
>> 
>> - Dan C.

In English, but still off topic, is a page I googled at:

http://www.memoryx.net/3703631.html

This is a picture of the Sun I/O one instead of the USB one, but they
are identical except for the insides and the connector.  (I have the
engineering spec in front of me, but I don't think you need that much
information...)


-- 
Jonathan Sergent / sergent@IO.COM



^ permalink raw reply	[flat|nested] 433+ messages in thread

* RE: [9fans] (no subject)
  2001-05-20 19:38     ` Dan Cross
@ 2001-05-20 19:57       ` Richard Elberger
  2001-05-21  4:56         ` Jonathan Sergent
  0 siblings, 1 reply; 433+ messages in thread
From: Richard Elberger @ 2001-05-20 19:57 UTC (permalink / raw)
  To: 9fans

Looks pretty normal, hope you can read japanese.
http://online.plathome.co.jp/cgi-bin/category.phtml?parent='7019'&rows=1&app
end=7019&kitem=1164008700009&vitem=1&details=1

-- rich


>A personal email to me suggested the Sun ``crossbow'' mouse; this
>looks intriguing, but I can't seem to find a picture of one online
>(the only pictures that do exist seem to be taken from so far away
>that one can't really make out what the mouse looks like...).
>
>	- Dan C.
>
>



^ permalink raw reply	[flat|nested] 433+ messages in thread

* Re: [9fans] (no subject)
  2001-05-20 12:40   ` Donald Brownlee
  2001-05-20 13:16     ` Boyd Roberts
@ 2001-05-20 19:38     ` Dan Cross
  2001-05-20 19:57       ` Richard Elberger
  1 sibling, 1 reply; 433+ messages in thread
From: Dan Cross @ 2001-05-20 19:38 UTC (permalink / raw)
  To: 9fans

In article <3B07BB36.9441DBB0@acm.org> you write:
>Logitech "Wingman Gaming Mouse" (tm).
>
>On the bottom of the mouse:
>
>  M/N M-BC38;
>  P/N 830324-0000;
>  "For home or office use."

Word!  This is exactly what I'm looking for; thanks!

A personal email to me suggested the Sun ``crossbow'' mouse; this
looks intriguing, but I can't seem to find a picture of one online
(the only pictures that do exist seem to be taken from so far away
that one can't really make out what the mouse looks like...).

	- Dan C.



^ permalink raw reply	[flat|nested] 433+ messages in thread

* Re: [9fans] (no subject)
  2001-05-20 12:40   ` Donald Brownlee
@ 2001-05-20 13:16     ` Boyd Roberts
  2001-05-20 19:38     ` Dan Cross
  1 sibling, 0 replies; 433+ messages in thread
From: Boyd Roberts @ 2001-05-20 13:16 UTC (permalink / raw)
  To: 9fans

>   "For home or office use."

what?  not suitable for battlefield conditions?

nah, that's what trackballs are for.




^ permalink raw reply	[flat|nested] 433+ messages in thread

* Re: [9fans] (no subject)
  2001-05-20  6:31 ` Dan Cross
@ 2001-05-20 12:40   ` Donald Brownlee
  2001-05-20 13:16     ` Boyd Roberts
  2001-05-20 19:38     ` Dan Cross
  0 siblings, 2 replies; 433+ messages in thread
From: Donald Brownlee @ 2001-05-20 12:40 UTC (permalink / raw)
  To: 9fans

Dan Cross wrote:
> 
> Is anyone aware of a decent USB
> 3 button mouse sans wheel?
> 
>         - Dan C.

Logitech "Wingman Gaming Mouse" (tm).

On the bottom of the mouse:

  M/N M-BC38;
  P/N 830324-0000;
  "For home or office use."


^ permalink raw reply	[flat|nested] 433+ messages in thread

* Re: [9fans] (no subject)
  2001-05-20  1:41 rob pike
@ 2001-05-20  6:31 ` Dan Cross
  2001-05-20 12:40   ` Donald Brownlee
  0 siblings, 1 reply; 433+ messages in thread
From: Dan Cross @ 2001-05-20  6:31 UTC (permalink / raw)
  To: 9fans

In article <20010520014110.1DBDD199F9@mail.cse.psu.edu> you write:
>[9fans] mouse vs key
>
>I would think mouse chords would be singularly
>ineffective on the Mac.

On a related note, what is the sound of one hand clapping?

While on the subject of macs, it seems that the adb interface
is going away in favor of USB.  Is anyone aware of a decent USB
3 button mouse sans wheel?

	- Dan C.



^ permalink raw reply	[flat|nested] 433+ messages in thread

* [9fans] (no subject)
@ 2001-05-20  1:41 rob pike
  2001-05-20  6:31 ` Dan Cross
  0 siblings, 1 reply; 433+ messages in thread
From: rob pike @ 2001-05-20  1:41 UTC (permalink / raw)
  To: 9fans

[9fans] mouse vs key

I would think mouse chords would be singularly
ineffective on the Mac.

-rob



^ permalink raw reply	[flat|nested] 433+ messages in thread

* Re: [9fans] (no subject)
@ 2001-04-09 14:52 presotto
  0 siblings, 0 replies; 433+ messages in thread
From: presotto @ 2001-04-09 14:52 UTC (permalink / raw)
  To: 9fans

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

I'm not sure why this didn't get into the release.  I'll add it to the
update wrap I'm preparing.

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

From: forsyth@vitanuova.com
To: 9fans@cse.psu.edu
Subject: Re: [9fans] (no subject)
Date: Mon, 9 Apr 2001 14:47:57 +0100
Message-ID: <20010409134753.D405219A4E@mail.cse.psu.edu>

% man 2 httpd
man: no manual page


[-- Attachment #3: httpd --]
[-- Type: text/plain, Size: 6244 bytes --]

.TH HTTPD 2
.SH NAME
HConnect,
HContent,
HContents,
HETag,
HFields,
Hio,
Htmlesc,
HttpHead,
HttpReq,
HRange,
HSPairs,
hmydomain,
hversion,
htmlesc,
halloc,
hbodypush,
hbuflen,
hcheckcontent,
hclose,
hdate2sec,
hdateconv,
hfail,
hflush,
hgetc,
hgethead,
hinit,
hiserror,
hload,
hlower,
hmkcontent,
hmkhfields,
hmkmimeboundary,
hmkspairs,
hmoved,
hokheaders,
hparseheaders,
hparsequery,
hparsereq,
hprint,
hputc,
hreadbuf,
hredirected,
hreqcleanup,
hrevhfields,
hrevspairs,
hstrdup,
http11,
httpconv,
httpunesc,
hunallowed,
hungetc,
hunload,
hurlconv,
hurlunesc,
hwrite,
hxferenc,
 \- routines for creating an http server
.SH SYNOPSIS
.nf
.B #include <u.h>
.nf
.B #include <u.h>
.B #include <libc.h>
.B #include <httpd.h>
.PP
.ft L
typedef struct HConnect HConnect;
typedef struct HContent HContent;
typedef struct HContents HContents;
typedef struct HETag HETag;
typedef struct HFields HFields;
typedef struct Hio Hio;
typedef struct Htmlesc Htmlesc;
typedef struct HttpHead HttpHead;
typedef struct HttpReq HttpReq;
typedef struct HRange HRange;
typedef struct HSPairs HSPairs;

typedef struct Bin Bin;
.ta \w'\fLHContents 'u +\w'\fLHContentsxx 'u +\w'\fLheader[HBufSize + 2];  'u

struct Htmlesc
{
	char	*name;
	Rune	value;
};

struct HContent
{
	HContent	*next;
	char	*generic;
	char	*specific;
	float	q;	/* desirability of this kind of file */
	int	mxb;	/* max uchars until worthless */
};

struct HContents
{
	HContent	*type;
	HContent	 *encoding;
};

/*
 * generic http header with a list of tokens,
 * each with an optional list of parameters
 */
struct HFields
{
	char	*s;
	HSPairs	*params;
	HFields	*next;
};

/*
 * list of pairs a strings
 * used for tag=val pairs for a search or form submission,
 * and attribute=value pairs in headers.
 */
struct HSPairs
{
	char	*s;
	char	*t;
	HSPairs	*next;
};

/*
 * byte ranges within a file
 */
struct HRange
{
	int	suffix;	/* is this a suffix request? */
	ulong	start;
	ulong	stop;	/* ~0UL -> not given */
	HRange	*next;
};

/*
 * list of http/1.1 entity tags
 */
struct HETag
{
	char	*etag;
	int	weak;
	HETag	*next;
};

/*
 * HTTP custom IO
 * supports chunked transfer encoding
 * and initialization of the input buffer from a string.
 */
enum
{
	Hnone,
	Hread,
	Hend,
	Hwrite,
	Herr,

	Hsize = HBufSize
};

struct Hio {
	Hio	*hh;	/* next lower layer Hio, or nil if reads from fd */
	int	fd;	/* associated file descriptor */
	ulong	seek;	/* of start */
	uchar	state;	/* state of the file */
	uchar	xferenc;	/* chunked transfer encoding state */
	uchar	*pos;	/* current position in the buffer */
	uchar	*stop;	/* last character active in the buffer */
	uchar	*start;	/* start of data buffer */
	ulong	bodylen;	/* remaining length of message body */
	uchar	buf[Hsize+32];
};

/*
 * request line
 */
struct HttpReq
{
	char	*meth;
	char	*uri;
	char	*urihost;
	char	*search;
	int	vermaj;
	int	vermin;
};

/*
 * header lines
 */
struct HttpHead
{
	int	closeit;	/* http1.1 close connection after this request? */
	uchar	persist;	/* http/1.1 requests a persistent connection */

	uchar	expectcont;	/* expect a 100-continue */
	uchar	expectother;	/* expect anything else; should reject with ExpectFail */
	ulong	contlen;	/* if != ~0UL, length of included message body */
	HFields	*transenc;	/* if present, encoding of included message body */
	char	*client;
	char	*host;
	HContent	*okencode;
	HContent	*oklang;
	HContent	*oktype;
	HContent	*okchar;
	ulong	ifmodsince;
	ulong	ifunmodsince;
	ulong	ifrangedate;
	HETag	*ifmatch;
	HETag	*ifnomatch;
	HETag	*ifrangeetag;
	HRange	*range;
	char	*authuser;	/* authorization info */
	char	*authpass;

	/*
	 * experimental headers
	 */
	int	fresh_thresh;
	int	fresh_have;
};

/*
 * all of the state for a particular connection
 */
struct HConnect
{
	void	*private;	/* for the library clients */
	void	(*replog)(HConnect*, char*, ...);	/* called when reply sent */

	HttpReq	req;
	HttpHead	head;

	Bin	*bin;

	ulong	reqtime;	/* time at start of request */
	char	xferbuf[HBufSize];	/* buffer for making up or transferring data */
	uchar	header[HBufSize + 2];	/* room for \\n\\0 */
	uchar	*hpos;
	uchar	*hstop;
	Hio	hin;
	Hio	hout;
};

/*
 * configuration for all connections within the server
 */
extern	char	*hmydomain;
extern	char	*hversion;
extern	Htmlesc	htmlesc[];

void	*halloc(HConnect *c, ulong size);
Hio	*hbodypush(Hio *hh, ulong len, HFields *te);
int	hbuflen(Hio *h, void *p);
int	hcheckcontent(HContent*, HContent*, char*, int);
void	hclose(Hio*);
ulong	hdate2sec(char*);
int	hdateconv(va_list*, Fconv*);
int	hfail(HConnect*, int, ...);
int	hflush(Hio*);
int	hgetc(Hio*);
int	hgethead(HConnect *c, int many);
int	hinit(Hio*, int, int);
int	hiserror(Hio *h);
int	hload(Hio*, char*);
char	*hlower(char*);
HContent	*hmkcontent(HConnect *c, char *generic, char *specific, HContent *next);
HFields	*hmkhfields(HConnect *c, char *s, HSPairs *p, HFields *next);
char	*hmkmimeboundary(HConnect *c);
HSPairs	*hmkspairs(HConnect *c, char *s, char *t, HSPairs *next);
int	hmoved(HConnect *c, char *uri);
void	hokheaders(HConnect *c);
int	hparseheaders(HConnect*, int timeout);
HSPairs	*hparsequery(HConnect *c, char *search);
int	hparsereq(HConnect *c, int timeout);
int	hprint(Hio*, char*, ...);
int	hputc(Hio*, int);
void	*hreadbuf(Hio *h, void *vsave);
int	hredirected(HConnect *c, char *how, char *uri);
void	hreqcleanup(HConnect *c);
HFields	*hrevhfields(HFields *hf);
HSPairs	*hrevspairs(HSPairs *sp);
char	*hstrdup(HConnect *c, char *s);
int	http11(HConnect*);
int	httpconv(va_list*, Fconv*);
char	*httpunesc(HConnect *c, char *s);
int	hunallowed(HConnect *, char *allowed);
int	hungetc(Hio *h);
char	*hunload(Hio*);
int	hurlconv(va_list*, Fconv*);
char	*hurlunesc(HConnect *c, char *s);
int	hwrite(Hio*, void*, int);
int	hxferenc(Hio*, int);
.ft R
.SH DESCRIPTION
For now, look at the source, or
.IR httpd (8).
.SH SOURCE
.B /sys/src/libhttpd
.SH SEE ALSO
.IR bin (2)
.SH BUGS
This is a rough implementation and many details are going to change.

^ permalink raw reply	[flat|nested] 433+ messages in thread

* Re: [9fans] (no subject)
@ 2001-04-09 13:47 forsyth
  0 siblings, 0 replies; 433+ messages in thread
From: forsyth @ 2001-04-09 13:47 UTC (permalink / raw)
  To: 9fans

% man 2 httpd
man: no manual page



^ permalink raw reply	[flat|nested] 433+ messages in thread

* [9fans] (no subject)
@ 2001-04-09 13:26 presotto
  0 siblings, 0 replies; 433+ messages in thread
From: presotto @ 2001-04-09 13:26 UTC (permalink / raw)
  To: 9fans

On Mon Apr  9 04:05:24 EDT 2001, okamoto@granite.cias.osakafu-u.ac.jp wrote:
> There are some new header files in /sys/include, such as bin.h, control.h
> ctype.h, flate.h, httpd.h, scribble.h, and corresponding libraries.
>
> Could you please give us a brief explanation why those are added?
>
> Kenji
>

bin.h - grouped memory allocation. man bin
control.h - for Rob's new widget package.  man control
ctype.h - since day 1.  man ctype
flate.h - data compression lib. man 2 flate
httpd.h - for building the equiv of cgibin's.. man 2 httpd
scribble.h - for using the Grafitti-like scribble textual input in
		a program.  man 2 scribble


^ permalink raw reply	[flat|nested] 433+ messages in thread

* [9fans] (no subject)
@ 2001-03-30 15:56 presotto
  0 siblings, 0 replies; 433+ messages in thread
From: presotto @ 2001-03-30 15:56 UTC (permalink / raw)
  To: 9fans

My first screw up in the current release:

% diff ../port/portclock.c /n/emelieother/plan9/sys/src/9/port
72,73c72,73
< 	m->inclockintr = 0;
< 	if(up == 0 || up->state != Running)
---
> 	if(up == 0 || up->state != Running){
> 		m->inclockintr = 0;
74a75
> 	}
76c77
< 	if(anyready()){
---
> 	if(anyready())
78,79d78
< 		splhi();
< 	}
85a85
> 	m->inclockintr = 0;

I'll do a wrap soon with this and other updates.


^ permalink raw reply	[flat|nested] 433+ messages in thread

* [9fans] (no subject)
@ 2001-03-22 15:09 Gorka Guardiola Muzquiz
  0 siblings, 0 replies; 433+ messages in thread
From: Gorka Guardiola Muzquiz @ 2001-03-22 15:09 UTC (permalink / raw)
  To: 9fans



^ permalink raw reply	[flat|nested] 433+ messages in thread

* [9fans] (no subject)
@ 2001-03-06 14:44 presotto
  0 siblings, 0 replies; 433+ messages in thread
From: presotto @ 2001-03-06 14:44 UTC (permalink / raw)
  To: 9fans

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

FYI

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

From: Sean Quinlan <seanq@bell-labs.com>
To: presotto@bell-labs.com
Subject: Re:
Date: Mon, 05 Mar 2001 10:12:08 -0500
Message-ID: <3AA3ACC8.2F691882@bell-labs.com>

people have been using linksys NAT boxes to do this.

presotto wrote:
> 
> I remember you talkin about this.  Did anything ever come of it?
> 
>   ------------------------------------------------------------------------------------------------------------------------
> 
> Subject: [9fans] PPPoE, Adsl
> Date: Mon, 5 Mar 2001 09:41:11 +0100 (MET)
> From: Jean Mehat <jm@ai.univ-paris8.fr>
> Reply-To: 9fans@cse.psu.edu
> To: 9fans@cse.psu.edu
> 
> Anyone knows what is necessary to run PPPoE on Plan 9 (to connect to ADSL)?
> Anyone did it?

^ permalink raw reply	[flat|nested] 433+ messages in thread

* [9fans] (no subject)
@ 2000-11-29  8:03 Russ Cox
  0 siblings, 0 replies; 433+ messages in thread
From: Russ Cox @ 2000-11-29  8:03 UTC (permalink / raw)
  To: 9fans

subect: swikis

Is anyone interested in setting up a
Plan 9 wiki/swiki?  Does anyone know
what they are?

A Wiki is a collaborative web server:
the pages are world-writable with a 
history, and anyone who doesn't like
or wants to add to a page, create new
pages, etc., can do so.  The theory is
that if you see something wrong or not
as complete as it could be, you fix it.
Apparently it works quite well most of
the time.  The history function means
that if someone comes a long and "destroys"
everything, someone else can just come
along and restore it.  This apparently
rarely happens.

The Squeak people (Smalltalk hackers)
seem to have the most common implementation,
which they call a swiki.  

I've been poking around the various Squeak-related
ones for a while and am quite impressed.
I even fixed a few broken links while
I was poking around.

http://pbl.cc.gatech.edu/myswiki/107 is
a decent jumping off point for learning
about them.

I think that such a server dedicated to
explaining various things for new Plan 9
users would be a tremendous help.  The great
thing is that it can start small and as people
find questions not answered they can add them
(and then the answers when they find them),
and it evolves as is useful, without the hassle
of a central person maintaining it, as is the
case with FAQs and the like.  (You might think
of this as FAQ-o-matic on steroids, I believe.)

They're apparently very easy to set up: they
run anywhere Squeak does, which is Mac, Windows,
and most Unixes.

Russ


^ permalink raw reply	[flat|nested] 433+ messages in thread

end of thread, other threads:[~2018-04-02 21:08 UTC | newest]

Thread overview: 433+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2002-11-18 21:39 [9fans] (no subject) bwc
  -- strict thread matches above, loose matches on Subject: below --
2018-04-02 15:27 Steve Simon
2018-04-02 21:08 ` Digby R.S. Tarvin
2018-01-04 20:11 Steve Simon
2018-01-04 20:22 ` Lyndon Nerenberg
2018-01-04 21:20   ` Steve Simon
2018-01-04 22:27     ` Joseph Stewart
2018-01-04 23:22       ` Rob Pike
2018-01-04 23:37 ` Greg Lewin
2017-08-30 14:12 Steve Simon
2017-08-30 16:36 ` Steven Stallion
2016-12-02 11:44 Steve Simon
2016-12-02 19:12 ` Bakul Shah
2016-07-29  0:01 kokamoto
2014-11-25  4:20 trebol
2014-07-31  5:18 kokamoto
2014-07-05  0:38 kokamoto
2014-06-21 19:45 Steve Simon
2014-06-21 23:39 ` cinap_lenrek
2014-06-22  6:54   ` Steve Simon
2014-04-16  1:52 sl
2014-04-16  9:39 ` Ingo Krabbe
2014-04-15 14:41 Steve Simon
2014-04-15 15:36 ` Anthony Sorace
2014-04-15 18:18   ` sl
2014-04-15 22:42     ` erik quanstrom
2014-04-15 23:40       ` arisawa
2014-04-16  1:20     ` Anthony Sorace
2014-04-15 15:50 ` erik quanstrom
2014-04-15 17:46   ` Aram Hăvărneanu
2014-04-15 17:53     ` erik quanstrom
2014-03-19 18:44 Jacob Todd
2014-03-15 23:07 Steve Simon
2014-03-15 23:26 ` Jacob Todd
2014-03-16 14:51   ` erik quanstrom
2014-03-16  1:51 ` Jeff Sickel
2013-11-17 23:04 Steve Simon
2013-06-03 15:43 sl
2013-04-30 15:56 lucio
2013-04-30 17:11 ` erik quanstrom
2012-10-19  9:46 Sophit4
2012-09-03 11:16 yaroslav
2012-09-03 11:40 ` Charles Forsyth
2012-04-11  9:38 陈俊秀
2011-12-30 18:08 erik quanstrom, erik quanstrom
2011-12-30 18:49 ` Jack Norton
2011-12-30 19:24   ` erik quanstrom
2011-12-30 20:35 ` Aram Hăvărneanu
2011-12-30 21:28   ` Bakul Shah
2011-12-30 21:34     ` Charles Forsyth
2011-12-30 21:38       ` Aram Hăvărneanu
2011-12-30 21:53       ` Bakul Shah
2011-12-30 21:56         ` Aram Hăvărneanu
2011-12-30 22:41           ` Charles Forsyth
2011-12-30 23:00             ` Lyndon Nerenberg
     [not found] ` <CAEAzY38puVSzEnn90mmi+Bq4hnL9WpbBsnysjJYvXYw3xvE=xA@mail.gmail.c>
2011-12-30 21:05   ` erik quanstrom
2011-12-30 21:39     ` Jack Norton
2011-12-31  5:31       ` erik quanstrom
2011-12-31 17:40         ` Aram Hăvărneanu
     [not found]         ` <CAEAzY39S9z6mKtun68DGFbEkA6y8kaqTEyDCkW6ydHK8aHFG5A@mail.gmail.c>
2011-12-31 19:32           ` erik quanstrom
2012-01-05 18:03             ` Aram Hăvărneanu
2011-11-22 18:32 Steve Simon
2011-08-09 12:40 Steve Simon
2011-08-09 12:54 ` erik quanstrom
2011-08-09 13:07   ` Steve Simon
2011-08-09 14:52     ` erik quanstrom
2011-08-09 18:21     ` Lyndon Nerenberg (VE6BBM/VE7TFX)
2011-08-09 18:31       ` Steve Simon
2011-08-09 14:12 ` Russ Cox
2011-04-06  9:09 Stanley Lieber
2011-04-25  7:42 ` Steve Simon
2011-04-25 13:11   ` erik quanstrom
     [not found] <96cc26fe3002748983b3fc16cc949bab@quintile.net>
2011-03-28 13:56 ` erik quanstrom
2011-03-28 14:50   ` cinap_lenrek at gmx.de
2011-03-28 15:18     ` ron minnich
2011-03-28 22:57       ` erik quanstrom
2010-12-21  3:43 erik quanstrom, erik quanstrom
2010-05-06 19:55 erik quanstrom
2010-03-08  4:22 lucio
2010-03-08  4:49 ` ron minnich
2010-03-08  4:58   ` lucio
2010-03-08  6:17     ` Russ Cox
2010-03-08  6:22       ` lucio
2010-03-08 15:13     ` Patrick Kelly
2010-03-08 15:57       ` Francisco J Ballesteros
2010-03-08  8:54 ` Richard Miller
2010-03-08  9:31   ` lucio
2010-03-08 22:53 ` Sascha Retzki
2010-03-08 18:01   ` lucio
2010-03-08 19:20     ` Lyndon Nerenberg (VE6BBM/VE7TFX)
2010-03-09  4:20       ` lucio
2010-03-09  5:26         ` Lyndon Nerenberg (VE6BBM/VE7TFX)
2010-03-09  5:32           ` erik quanstrom
2010-03-09  5:50             ` Lyndon Nerenberg (VE6BBM/VE7TFX)
2010-03-09 20:08               ` Patrick Kelly
2010-03-08 19:41     ` erik quanstrom
2010-03-08 22:19     ` James Tomaschke
2010-03-09  4:34       ` lucio
     [not found] <mailman.26991.1268008023.1512.9fans@9fans.net>
2010-03-08  0:54 ` - Choc -
2010-03-07 17:47 lucio
2010-03-07 18:37 ` John Floren
2010-03-07 19:16   ` lucio
2010-03-07 19:57     ` erik quanstrom
2010-03-08  4:29       ` lucio
2010-03-06  9:32 [9fans] nb—search and index notes in files by keyword Peter A. Cejchan
2010-03-07  4:30 ` [9fans] (no subject) lucio
2010-03-07  5:05   ` Anthony Sorace
2010-03-07 17:31     ` ron minnich
2010-03-07 17:43       ` erik quanstrom
2010-03-07 18:14         ` lucio
2010-03-07 19:25           ` cinap_lenrek
2010-03-07 17:42     ` lucio
2010-03-07 17:53       ` erik quanstrom
2010-03-07 18:06         ` lucio
2010-03-07 18:59       ` Iruata Souza
2010-03-07 19:26         ` lucio
2010-03-07 19:36           ` ron minnich
2010-03-07  9:14   ` Skip Tavakkolian
2010-03-07 11:04     ` lucio
2010-02-05  1:53 erik quanstrom
2010-01-18 21:55 erik quanstrom
2009-09-29 23:25 [9fans] acme without a heavy grid (SFW) Jason Catena
2009-10-01 16:49 ` J.R. Mauro
2009-10-01 17:18   ` [9fans] (no subject) Pablo Alonso Salas Alvarez
2009-09-15 22:34 erik quanstrom
2009-07-24 17:18 erik quanstrom
2009-07-24 17:20 ` erik quanstrom
2009-07-24 16:14 [9fans] Does "as little software as possible" include a modern maht
2009-07-24 17:16 ` [9fans] (no subject) erik quanstrom
2009-07-17 21:09 drivers
2009-05-28 11:08 Gregory Pavelcak
2009-04-23 11:38 Steve Simon
2009-04-23 12:34 ` Charles Forsyth
2009-04-23 13:07   ` Devon H. O'Dell
2009-04-23 17:13   ` lucio
2009-04-23 17:17     ` erik quanstrom
2009-04-23 17:28       ` David Leimbach
2009-04-23 19:32 ` lucio
2009-04-27  4:42 ` lucio
2009-04-27 11:57   ` lucio
2009-04-27 21:30   ` Steve Simon
2009-02-24  0:29 mattmobile
2009-02-24  0:48 ` ron minnich
2009-02-24  1:02   ` Jeff Sickel
2009-02-24  1:25     ` sixforty
2009-02-24  2:13       ` Anthony Sorace
2009-02-23  0:13 [9fans] actionfs mattmobile
2009-03-05 13:16 ` [9fans] (no subject) cej
2009-01-02  2:30 erik quanstrom
2008-12-06 19:28 Dave Eckhardt
2008-12-06 23:42 ` Roman Shaposhnik
2008-12-07  0:04   ` erik quanstrom
2008-11-21 18:28 erik quanstrom
2008-11-21 21:33 ` Kenji Arisawa
2008-11-21 22:55   ` erik quanstrom
2008-08-14 19:09 akumar
2008-08-14 19:14 ` andrey mirtchovski
2008-07-19  2:37 [9fans] 9vx and local file systems Russ Cox
2008-07-21 13:26 ` [9fans] (no subject) kokamoto
2008-07-21 14:45   ` a
2008-03-19  5:03 Skip Tavakkolian
2008-03-19 12:41 ` erik quanstrom
2008-03-19 17:16   ` Lyndon Nerenberg
2007-12-14 23:02 Joshua Wood
2007-11-15 20:00 erik quanstrom
2007-08-24  1:54 YAMANASHI Takeshi
2007-08-24  2:04 ` erik quanstrom
2007-07-08 12:37 Gregory Pavelcak
2007-07-08 14:08 ` erik quanstrom
2007-07-08 14:50   ` erik quanstrom
2007-07-12 20:57     ` erik quanstrom
2007-05-25 23:29 ozan s. yigit
2007-05-25 23:42 ` Charles Forsyth
2007-05-26  0:09   ` ozan s. yigit
2007-05-28 12:36   ` Lluís Batlle
2007-05-11  6:57 Lyndon Nerenberg
2007-05-08 23:02 Steve Simon
2007-04-13 22:16 devon.odell
2007-04-14 11:17 ` W B Hacker
2007-01-15 23:24 steve
2006-12-12 21:20 Steve Simon
2006-12-10 13:49 sape
2006-09-13  7:28 Aw: " chuckf
2006-09-13  7:55 ` Sascha Retzki
2006-09-12 20:44 Chuck Foreman
2006-09-12 20:47 ` David Hendricks
2006-09-12 20:55 ` Federico Benavento
2006-09-02 11:16 lucio
2006-09-02 17:49 ` Gorka guardiola
2006-09-02 18:38   ` Gorka guardiola
2006-09-03  5:46     ` geoff
2006-09-03 10:51       ` Álvaro Jurado Cuevas
2006-08-21 12:43 Steve Simon
2006-08-22 17:56 ` Sergey Zhilkin
2006-04-21  4:09 Rafeek Raja
2006-02-10 15:30 quanstro
2006-02-10 14:10 quanstro
2006-02-10 15:17 ` jmk
2006-02-07 17:09 Riza Dindir
2005-09-09 18:46 Fco. J. Ballesteros
2005-08-07 22:24 Steve Simon
2005-08-08 13:25 ` Sape Mullender
2005-05-31  3:53 焕宇 苏
2005-05-30 19:01 quanstro
2005-02-10 15:28 tapique
2005-02-11 18:12 ` Bruce Ellis
2004-12-14 20:33 Charles Forsyth
2004-12-14 21:02 ` Bruce Ellis
2004-12-14 21:19 ` Ronald G. Minnich
2004-12-14 21:33   ` boyd, rounin
2004-12-14 21:38   ` Charles Forsyth
2004-12-14 22:01     ` Ronald G. Minnich
2004-12-14 22:12       ` andrey mirtchovski
2004-12-14 22:25         ` Ronald G. Minnich
2004-12-14 22:16       ` Charles Forsyth
2004-12-14 22:26         ` Ronald G. Minnich
2004-12-14 22:26           ` boyd, rounin
2004-12-14 22:36             ` jim
2004-12-14 22:48               ` Dan Cross
2004-12-14 22:47                 ` boyd, rounin
2004-12-14 23:00                 ` jim
2004-12-14 23:07                   ` boyd, rounin
2004-12-14 23:27                   ` Dan Cross
2004-12-14 22:50               ` Brantley Coile
2004-12-14 23:08                 ` jim
2004-12-14 23:12                   ` Brantley Coile
2004-12-14 22:55               ` andrey mirtchovski
2004-12-14 23:35               ` Ronald G. Minnich
2004-12-14 23:35                 ` boyd, rounin
2004-12-14 23:41                 ` andrey mirtchovski
2004-12-01 10:57 Steve Simon
2004-12-01 11:03 ` Tiit Lankots
2004-12-01 18:37 ` Jack Johnson
2004-12-01 18:47   ` Christopher Nielsen
2004-11-09 13:28 cej
2004-07-28  2:10 YAMANASHI Takeshi
2004-07-27  9:08 Steve Simon
2004-07-27  9:38 ` Kenji Okamoto
2004-07-27  9:44   ` Lucio De Re
2004-07-27 10:54   ` Steve Simon
2004-07-27 13:36     ` Boris Maryshev
2004-07-27 15:23       ` Justin Herald
2004-07-27 19:55     ` Francisco Ballesteros
2004-07-27 20:22     ` Skip Tavakkolian
2004-07-28  4:08     ` Dan Cross
2004-07-28  4:39       ` Justin Herald
2004-07-26 17:59 steve
2004-07-26 17:48 The Post Office
2004-07-26 17:30 join-jibjab
2004-07-26 17:18 melinda.proost
2004-07-26 16:58 Mail Delivery Subsystem
2004-07-26 16:21 swe
2004-07-26 16:06 library
2004-07-26 15:59 justin.jaffe
2004-07-26 15:44 The Post Office
2004-07-26 15:25 andrewm
2004-07-26 15:20 Automatic Email Delivery Software
2004-07-26 15:14 newswire
2004-07-19  8:17 judge
2004-07-16 11:38 Chris
2004-07-15  3:46 Michelle
2004-07-13 15:19 Fco. J. Ballesteros
2004-07-09 17:25 Steven
2004-07-07  1:49 Pam Moran
2004-07-03 22:23 Joseph
2004-07-02 12:05 Don
2004-06-28 12:49 Steve Simon
2004-06-22 20:43 Pete
2004-05-17 15:50 matt lawless
2004-05-18  8:31 ` john grove
2004-05-19  8:31 ` john grove
2004-04-19  8:29 Steve Simon
2004-04-13 11:54 matt
2004-04-13 21:25 ` Geoff Collyer
2004-04-13 21:28   ` boyd, rounin
2004-03-23 16:12 David Presotto
2004-03-04 17:57 David Presotto
2004-03-04 18:12 ` Charles Forsyth
2004-03-04 18:21   ` Dave Lukes
2004-03-04 18:29     ` Charles Forsyth
2004-03-04 22:21     ` boyd, rounin
2004-02-22 20:07 Russ Cox
2004-02-17 14:26 David Presotto
2004-02-17 16:13 ` Rob Pike
2004-02-17 16:17   ` David Presotto
2004-02-17 16:29     ` Rob Pike
2004-02-18  3:52   ` boyd, rounin
2004-02-17 21:25 ` C H Forsyth
2004-02-17 23:57 ` Charles Forsyth
2004-02-18  0:03   ` David Presotto
2004-02-18  6:58   ` 9nut
2004-02-18 16:56   ` rog
2004-02-01  0:34 sam
2004-01-30 18:10 engineering
2004-01-27 12:47 ravi
2004-01-22 15:22 Sape Mullender
2003-12-11 21:38 David Presotto
2003-11-25 15:18 Steve Simon
2003-11-02 21:12 andrey mirtchovski
2003-11-02 21:29 ` David Presotto
2003-10-19 14:22 David Presotto
2003-10-16 13:13 David Presotto
2003-10-14 12:11 David Presotto
2003-10-14 14:40 ` a
2003-10-14 15:43   ` Dan Cross
2003-10-12  0:43 matt
2003-10-11 23:43 ` David Presotto
2003-10-12  0:52   ` matt
2003-10-09 16:46 David Presotto
2003-10-09 16:52 ` Richard Miller
2003-09-25 14:24 steve.simon
2003-09-24  0:11 matt
2003-09-24  0:15 ` matt
2003-09-24  0:11 matt
2003-09-16  1:16 David Presotto
2003-09-16  7:38 ` Charles Forsyth
2003-09-01 23:47 matt
2003-09-01 19:14 ` David Presotto
2003-09-01 19:24   ` Skip Tavakkolian
2003-09-02  0:42   ` boyd, rounin
2003-09-01 14:08 David Presotto
2003-08-31 23:46 David Presotto
2003-07-26 16:11 David Presotto
2003-07-23 15:34 Vincenzo Volpe
2003-07-23 16:36 ` jmk
2003-07-26  0:46   ` David Presotto
2003-08-01  9:02     ` Vincenzo Volpe
2003-08-01 17:53       ` David Presotto
2003-06-21 19:15 David Presotto
2003-06-19 13:57 David Presotto
2003-06-19 14:16 ` boyd, rounin
2003-05-10  5:24 Andrew Simmons
2003-04-21 17:54 bigfoot
2003-04-21 18:12 ` David Presotto
2003-04-21 19:06   ` Russ Cox
2003-04-21 19:08     ` rsc
2003-04-25 10:40     ` vic zandy
2003-04-19 13:02 David Presotto
2003-02-25 12:40 Steve Simon
2003-02-24 16:52 Steve Simon
2003-02-24 16:06 ` Wayne Walker
2003-02-24 17:18   ` William Josephson
2003-02-24 19:37 ` northern snowfall
2003-02-24 13:49 David Presotto
2003-02-24 15:11 ` Sam
     [not found] <2ba8f07c025d45604e247b27a02d4123@plan9.bell-labs.com>
2003-02-23  6:14 ` Leendert van Doorn
2003-02-17 15:30 Steve Simon
2003-02-14 16:19 Steve Simon
2003-02-12 15:41 David Presotto
2003-02-12 15:37 David Presotto
2003-02-12 15:34 David Presotto
2003-02-10 17:20 Steve Simon
2003-02-10 18:26 ` Russ Cox
2002-12-03  9:02 Ian Dichkovsky
2002-12-01 20:33 bwc
2002-12-01 17:38 Skip Tavakkolian
2002-12-01 15:46 presotto
2002-11-19 20:04 presotto
2002-11-19 19:36 bwc
2002-11-19 19:50 ` George Michaelson
2002-11-19  1:44 bwc
2002-11-18 21:40 bwc
2002-11-18 21:39 bwc
2002-10-17  3:49 rob pike, esq.
2002-09-30 23:48 Adrian L. Thiele
2002-09-19 17:54 Sape Mullender
     [not found] <20020814092910.8DBA973C99@wintermute.cse.psu.edu>
     [not found] ` <3D5AC220.F7A7ED77@null.net>
2002-08-15  9:55   ` matt
2002-08-15 16:24   ` Ronald G Minnich
2002-08-15 17:08   ` Dennis Davis
2002-07-19  0:59 presotto
2002-07-16 19:21 presotto
2002-07-03 13:17 presotto
2002-06-10 19:10 Russ Cox
2002-04-12 17:43 Russ Cox
2002-04-12 17:20 /dev/null
2002-03-12  1:04 markp
2002-03-12  9:42 ` Thomas Bushnell, BSG
2002-03-13 10:04   ` bs
2002-03-11 18:33 Russ Cox
2002-03-12  9:42 ` Thomas Bushnell, BSG
2002-03-11 16:28 bwc
2002-03-11 16:24 bwc
2002-03-11 15:57 presotto
2002-03-11 17:51 ` Thomas Bushnell, BSG
2002-03-12  9:42   ` ozan s yigit
2002-03-11 19:51 ` Sam Ducksworth
2002-03-11 19:53 ` Andrew Simmons
2002-03-12 11:05 ` Anthony Mandic
2002-03-13 10:05 ` Douglas A. Gwyn
2002-02-28 11:26 sape
2002-03-04  6:51 ` Sean Quinlan
2002-02-27 22:47 presotto
2002-02-27 17:57 stanv
2001-12-13 14:35 presotto
2001-12-13 15:10 ` Ronald G Minnich
2001-12-13 15:47 ` Lucio De Re
2001-12-11 18:27 bwc
2001-12-11 18:17 Russ Cox
2001-12-11 18:17 bwc
2001-12-11 16:24 Russ Cox
2001-12-11 16:33 ` Boyd Roberts
2001-12-09 14:48 rob pike
2001-12-11 10:07 ` Douglas A. Gwyn
2001-12-11 11:55   ` Boyd Roberts
2001-12-12  9:47     ` Douglas A. Gwyn
2002-01-02 10:04       ` John R. Strohm
2002-01-03  9:52         ` Douglas A. Gwyn
2001-12-12  9:48   ` Thomas Bushnell, BSG
2001-12-12 11:14     ` Boyd Roberts
2001-12-09  8:22 arisawa
2001-11-30 14:14 steve.simon
2001-11-30 14:30 ` Boyd Roberts
2001-11-01 21:27 presotto
2001-11-01 21:26 presotto
2001-10-26 18:10 presotto
2001-10-26 14:45 peh
2001-09-07 13:48 Peter Bosch
2001-09-05  7:25 Fco.J.Ballesteros
2001-09-04 13:30 Fco.J.Ballesteros
2001-09-04 20:51 ` Martin Harriss
2001-09-04 12:08 geoff
2001-08-14 11:10 Usenet News system
2001-08-12 21:38 Philippe Anel
2001-08-13  7:45 ` andrey mirtchovski
2001-08-14  9:44   ` Ralph Corderoy
2001-08-05 14:02 jmk
2001-05-20  1:41 rob pike
2001-05-20  6:31 ` Dan Cross
2001-05-20 12:40   ` Donald Brownlee
2001-05-20 13:16     ` Boyd Roberts
2001-05-20 19:38     ` Dan Cross
2001-05-20 19:57       ` Richard Elberger
2001-05-21  4:56         ` Jonathan Sergent
2001-04-09 14:52 presotto
2001-04-09 13:47 forsyth
2001-04-09 13:26 presotto
2001-03-30 15:56 presotto
2001-03-22 15:09 Gorka Guardiola Muzquiz
2001-03-06 14:44 presotto
2000-11-29  8:03 Russ Cox

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).