[9fans] (no subject)

[9fans] (no subject)

[presotto]

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.

Re: [9fans] (no subject)

[Digby R.S. Tarvin]

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

[9fans] (no subject)

[Steve Simon]

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

Re: [9fans] (no subject)

[Greg Lewin]

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?

Re: [9fans] (no subject)

[Rob Pike]

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

Re: [9fans] (no subject)

[Joseph Stewart]

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

Re: [9fans] (no subject)

[Steve Simon]

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

Re: [9fans] (no subject)

[Lyndon Nerenberg]

> 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

[9fans] (no subject)

[Steve Simon]

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

Re: [9fans] (no subject)

[Steven Stallion]

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
>

[9fans] (no subject)

[Steve Simon]

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

Re: [9fans] (no subject)

[Bakul Shah]

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

[9fans] (no subject)

[Steve Simon]

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

[9fans] (no subject)

[kokamoto]

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

[9fans] (no subject)

[trebol]

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.

[9fans] (no subject)

[kokamoto]

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

[9fans] (no subject)

[kokamoto]

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

Re: [9fans] (no subject)

[Steve Simon]

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

Re: [9fans] (no subject)

[cinap_lenrek]

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

[9fans] (no subject)

[Steve Simon]

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

Re: [9fans] (no subject)

[Ingo Krabbe]

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

Re: [9fans] (no subject)

[sl]

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

Re: [9fans] (no subject)

[Anthony Sorace]

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

Re: [9fans] (no subject)

[arisawa]

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
> 

Re: [9fans] (no subject)

[erik quanstrom]

thanks for the confirmation!

- erik

Re: [9fans] (no subject)

[sl]

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

Re: [9fans] (no subject)

[erik quanstrom]

> 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

Re: [9fans] (no subject)

[Aram Hăvărneanu]

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

Re: [9fans] (no subject)

[erik quanstrom]

> 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

Re: [9fans] (no subject)

[Anthony Sorace]

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

[9fans] (no subject)

[Steve Simon]

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

[9fans] (no subject)

[Jacob Todd]

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

Re: [9fans] (no subject)

[erik quanstrom]

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

Re: [9fans] (no subject)

[Jeff Sickel]

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
> 

Re: [9fans] (no subject)

[Jacob Todd]

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

[9fans] (no subject)

[Steve Simon]

Subject Drawterm windows audio?

Anyone added an audio driver to windows or osx drawterms?

-Steve

[9fans] (no subject)

[Steve Simon]

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

Re: [9fans] (no subject)

[sl]

> 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

Re: [9fans] (no subject)

[erik quanstrom]

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

[9fans] (no subject)

[lucio]

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

[9fans] (no subject)

[Sophit4]

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

Re: [9fans] (no subject)

[Charles Forsyth]

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

[9fans] (no subject)

[yaroslav]

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

[9fans] (no subject)

[陈俊秀]

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

Re: [9fans] (no subject)

[Aram Hăvărneanu]

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

Re: [9fans] (no subject)

[erik quanstrom]

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

Re: [9fans] (no subject)

[Aram Hăvărneanu]

> 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

Re: [9fans] (no subject)

[erik quanstrom]

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

Re: [9fans] (no subject)

[Lyndon Nerenberg]

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

Re: [9fans] (no subject)

[Charles Forsyth]

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

Re: [9fans] (no subject)

[Aram Hăvărneanu]

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

You don't.

-- 
Aram Hăvărneanu

Re: [9fans] (no subject)

[Bakul Shah]

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.

Re: [9fans] (no subject)

[Jack Norton]

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

Re: [9fans] (no subject)

[Aram Hăvărneanu]

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

Re: [9fans] (no subject)

[Charles Forsyth]

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

Re: [9fans] (no subject)

[Bakul Shah]

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
> 

Re: [9fans] (no subject)

[erik quanstrom]

> 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

Re: [9fans] (no subject)

[Aram Hăvărneanu]

> 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

Re: [9fans] (no subject)

[erik quanstrom]

> 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

Re: [9fans] (no subject)

[Jack Norton]

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

[9fans] (no subject)

[erik quanstrom, erik quanstrom]

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

[9fans] (no subject)

[Steve Simon]

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

Re: [9fans] (no subject)

[Steve Simon]

> auth/newns


Aha!

excellent, this is just what I need.

thanks

-Steve

Re: [9fans] (no subject)

[Lyndon Nerenberg (VE6BBM/VE7TFX)]

> 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

Re: [9fans] (no subject)

[erik quanstrom]

> 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

Re: [9fans] (no subject)

[Russ Cox]

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

Re: [9fans] (no subject)

[Steve Simon]

> 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

Re: [9fans] (no subject)

[erik quanstrom]

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

[9fans] (no subject)

[Steve Simon]

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

Re: [9fans] (no subject)

[erik quanstrom]

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

Re: [9fans] (no subject)

[Steve Simon]

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

[9fans] (no subject)

[Stanley Lieber]

> 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

[9fans] (no subject)

[erik quanstrom]

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

[9fans] (no subject)

[ron minnich]

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

ron

[9fans] (no subject)

[cinap_lenrek at gmx.de]

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>

[9fans] (no subject)

[erik quanstrom]

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

[9fans] (no subject)

[erik quanstrom, erik quanstrom]

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

[9fans] (no subject)

[erik quanstrom]

- erik

Re: [9fans] (no subject)

[Patrick Kelly]

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

Re: [9fans] (no subject)

[Lyndon Nerenberg (VE6BBM/VE7TFX)]

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

Re: [9fans] (no subject)

[erik quanstrom]

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

Re: [9fans] (no subject)

[Lyndon Nerenberg (VE6BBM/VE7TFX)]

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

There is: it's called POSIX.

Re: [9fans] (no subject)

[lucio]

> 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

Re: [9fans] (no subject)

[lucio]

> 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

Re: [9fans] (no subject)

[Sascha Retzki]

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

Re: [9fans] (no subject)

[James Tomaschke]

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

Re: [9fans] (no subject)

[erik quanstrom]

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

Re: [9fans] (no subject)

[Lyndon Nerenberg (VE6BBM/VE7TFX)]

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

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

Re: [9fans] (no subject)

[lucio]

> 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

Re: [9fans] (no subject)

[Francisco J Ballesteros]

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

Re: [9fans] (no subject)

[Patrick Kelly]

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

Re: [9fans] (no subject)

[lucio]

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

Re: [9fans] (no subject)

[Richard Miller]

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

s/redesign/annihilation/

Re: [9fans] (no subject)

[lucio]

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

Touche'.

++L

Re: [9fans] (no subject)

[Russ Cox]

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

Re: [9fans] (no subject)

[lucio]

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

Re: [9fans] (no subject)

[ron minnich]

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

Re: [9fans] (no subject)

[lucio]

> 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

Re: [9fans] (no subject)

[lucio]

> 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

[9fans] (no subject)

[- Choc -]

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







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

Re: [9fans] (no subject)

[erik quanstrom]

> 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

Re: [9fans] (no subject)

[ron minnich]

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

Re: [9fans] (no subject)

[lucio]

> 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

Re: [9fans] (no subject)

[cinap_lenrek]

> 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

Re: [9fans] (no subject)

[lucio]

> 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

Re: [9fans] (no subject)

[Iruata Souza]

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

Re: [9fans] (no subject)

[John Floren]

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

Re: [9fans] (no subject)

[lucio]

> 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

Re: [9fans] (no subject)

[lucio]

> 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

Re: [9fans] (no subject)

[erik quanstrom]

> 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

Re: [9fans] (no subject)

[lucio]

> 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

Re: [9fans] (no subject)

[erik quanstrom]

> 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

Re: [9fans] (no subject)

[lucio]

> 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

Re: [9fans] (no subject)

[ron minnich]

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

Re: [9fans] (no subject)

[lucio]

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

Re: [9fans] (no subject)

[Skip Tavakkolian]

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

Re: [9fans] (no subject)

[Anthony Sorace]

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.

Re: [9fans] (no subject)

[lucio]

> 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

[9fans] (no subject)

[erik quanstrom]

[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

[9fans] (no subject)

[erik quanstrom]

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

[9fans] (no subject)

[Pablo Alonso Salas Alvarez]

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

[9fans] (no subject)

[erik quanstrom]

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

Re: [9fans] (no subject)

[erik quanstrom]

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

[9fans] (no subject)

[erik quanstrom]

- 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

[9fans] (no subject)

[erik quanstrom]

> #!/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'

[9fans] (no subject)

[drivers]

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

[9fans] (no subject)

[Gregory Pavelcak]

[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

Re: [9fans] (no subject)

[Steve Simon]

> 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

Re: [9fans] (no subject)

[lucio]

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

Re: [9fans] (no subject)

[lucio]

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

Re: [9fans] (no subject)

[lucio]

> anyone know of any other (simpler) options?

Inferno utils?  The binaries for NT?

++L

Re: [9fans] (no subject)

[David Leimbach]

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

Re: [9fans] (no subject)

[erik quanstrom]

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

unfortunate!  that's gotta hurt.  ☺

- erik

Re: [9fans] (no subject)

[lucio]

> 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

Re: [9fans] (no subject)

[Devon H. O'Dell]

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

Re: [9fans] (no subject)

[Charles Forsyth]

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.

[9fans] (no subject)

[Steve Simon]

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

[9fans] (no subject)

[cej]

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

Re: [9fans] (no subject)

[Anthony Sorace]

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.

Re: [9fans] (no subject)

[sixforty]

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

Re: [9fans] (no subject)

[Jeff Sickel]

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

Re: [9fans] (no subject)

[ron minnich]

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

[9fans] (no subject)

[mattmobile]

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

[9fans] (no subject)

[erik quanstrom]

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

Re: [9fans] (no subject)

[erik quanstrom]

> 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

Re: [9fans] (no subject)

[Roman Shaposhnik]

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.

[9fans] (no subject)

[Dave Eckhardt]

> 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

Re: [9fans] (no subject)

[erik quanstrom]

> 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

Re: [9fans] (no subject)

[Kenji Arisawa]

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

[9fans] (no subject)

[erik quanstrom]

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

Re: [9fans] (no subject)

[andrey mirtchovski]

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

[9fans] (no subject)

[akumar]

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

Re: [9fans] (no subject)

[a]

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

[9fans] (no subject)

[kokamoto]

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

Re: [9fans] (no subject)

[Lyndon Nerenberg]

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.

Re: [9fans] (no subject)

[erik quanstrom]

> 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

[9fans] (no subject)

[Skip Tavakkolian]

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.

[9fans] (no subject)

[Joshua Wood]

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

[9fans] (no subject)

[erik quanstrom]

Subject devsegment #g

doesn't seem to work.  is this a relic predating the segattach
system call?

- erik

Re: [9fans] (no subject)

[erik quanstrom]

> 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

[9fans] (no subject)

[YAMANASHI Takeshi]

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

Re: [9fans] (no subject)

[erik quanstrom]

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

Re: [9fans] (no subject)

[erik quanstrom]

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

Re: [9fans] (no subject)

[erik quanstrom]

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 },
};

[9fans] (no subject)

[Gregory Pavelcak]

	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

Re: [9fans] (no subject)

[Lluís Batlle]

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

Re: [9fans] (no subject)

[ozan s. yigit]

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.

Re: [9fans] (no subject)

[Charles Forsyth]

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

[9fans] (no subject)

[ozan s. yigit]

> 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



 

[9fans] (no subject)

[Lyndon Nerenberg]

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

[9fans] (no subject)

[Steve Simon]

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

Re: [9fans] (no subject)

[W B Hacker]

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

[9fans] (no subject)

[devon.odell]

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

[9fans] (no subject)

[steve]

[9fans] (no subject)

[Steve Simon]

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

[9fans] (no subject)

[sape]

Re: [9fans] (no subject)

[Sascha Retzki]

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

Re: [9fans] (no subject)

[Federico Benavento]

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

Re: [9fans] (no subject)

[David Hendricks]

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

[9fans] (no subject)

[Chuck Foreman]

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/

Re: [9fans] (no subject)

[Álvaro Jurado Cuevas]

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

Re: [9fans] (no subject)

[geoff]

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.

Re: [9fans] (no subject)

[Gorka guardiola]

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

Re: [9fans] (no subject)

[Gorka guardiola]

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

[9fans] (no subject)

[lucio]

Subjet: plan9.bell-labs.com

The web server is unreachable.  Unless it's a problem from here.

++L

Re: [9fans] (no subject)

[Sergey Zhilkin]

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

[9fans] (no subject)

[Steve Simon]

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

[9fans] (no subject)

[Rafeek Raja]

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



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

Re: [9fans] (no subject)

[quanstro]

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

Re: [9fans] (no subject)

[jmk]

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

[9fans] (no subject)

[quanstro]

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

[9fans] (no subject)

[Riza Dindir]

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 

[9fans] (no subject)

[Fco. J. Ballesteros]

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?

Re: [9fans] (no subject)

[Sape Mullender]

> 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

[9fans] (no subject)

[Steve Simon]

Nothing more than general interest but what hardware
does the ppc and mtx ports in the current distribution
relate to?

-Steve

[9fans] (no subject)

[焕宇 苏]

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

  


---------------------------------
Do You Yahoo!?
150万曲MP3疯狂搜，带您闯入音乐殿堂
美女明星应有尽有，搜遍美图、艳图和酷图
1G就是1000兆，雅虎电邮自助扩容！

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

[9fans] (no subject)

[quanstro]

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

Re: [9fans] (no subject)

[Bruce Ellis]

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

[9fans] (no subject)

[tapique]

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

Re: [9fans] (no subject)

[andrey mirtchovski]

> 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

Re: [9fans] (no subject)

[boyd, rounin]

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

Re: [9fans] (no subject)

[Ronald G. Minnich]

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

Re: [9fans] (no subject)

[Dan Cross]

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

Re: [9fans] (no subject)

[Brantley Coile]

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

Re: [9fans] (no subject)

[jim]

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

Re: [9fans] (no subject)

[boyd, rounin]

> 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

Re: [9fans] (no subject)

[jim]

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

Re: [9fans] (no subject)

[andrey mirtchovski]

> 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

Re: [9fans] (no subject)

[Brantley Coile]

> 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

Re: [9fans] (no subject)

[Dan Cross]

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.

Re: [9fans] (no subject)

[boyd, rounin]

From: "Dan Cross" <cross@math.psu.edu>

> ...

yeah, what the Marine said.

Re: [9fans] (no subject)

[jim]

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

Re: [9fans] (no subject)

[Ronald G. Minnich]

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

Re: [9fans] (no subject)

[boyd, rounin]

> yeah you're right. That was the motivation. 

sounds right to me.  damn idiots.

Re: [9fans] (no subject)

[Ronald G. Minnich]

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

Re: [9fans] (no subject)

[Charles Forsyth]

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

Re: [9fans] (no subject)

[andrey mirtchovski]

> 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

Re: [9fans] (no subject)

[Ronald G. Minnich]

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

Re: [9fans] (no subject)

[Charles Forsyth]

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

Re: [9fans] (no subject)

[boyd, rounin]

> yes, the kernel is supposed to do that fixup on linux. 

oh, how wonderful, sigh ...

Re: [9fans] (no subject)

[Ronald G. Minnich]

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

Re: [9fans] (no subject)

[Bruce Ellis]

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.

[9fans] (no subject)

[Charles Forsyth]

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.

Re: [9fans] (no subject)

[Christopher Nielsen]

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

Re: [9fans] (no subject)

[Jack Johnson]

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

Re: [9fans] (no subject)

[Tiit Lankots]

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

[9fans] (no subject)

[Steve Simon]

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

[9fans] (no subject)

[cej]

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
 

Re: [9fans] (no subject)

[Justin Herald]

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.

Re: [9fans] (no subject)

[Dan Cross]

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

Re: [9fans] (no subject)

[YAMANASHI Takeshi]

> 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

Re: [9fans] (no subject)

[Skip Tavakkolian]

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

Re: [9fans] (no subject)

[Francisco Ballesteros]

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
>

Re: [9fans] (no subject)

[Justin Herald]

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

Re: [9fans] (no subject)

[Boris Maryshev]

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"

Re: [9fans] (no subject)

[Steve Simon]

> 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

Re: [9fans] (no subject)

[Lucio De Re]

> 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

Re: [9fans] (no subject)

[Kenji Okamoto]

> 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

[9fans] (no subject)

[Steve Simon]

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

[9fans] (no subject)

[steve]

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

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

[9fans] (no subject)

[The Post Office]

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

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

[9fans] (no subject)

[join-jibjab]

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

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

[9fans] (no subject)

[melinda.proost]

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

[9fans] (no subject)

[Mail Delivery Subsystem]

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

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

[9fans] (no subject)

[swe]

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

[9fans] (no subject)

[library]

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

[9fans] (no subject)

[justin.jaffe]

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

[9fans] (no subject)

[The Post Office]

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

[9fans] (no subject)

[andrewm]

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

[9fans] (no subject)

[Automatic Email Delivery Software]

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

[9fans] (no subject)

[newswire]

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

[9fans] (no subject)

[judge]

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

[9fans] (no subject)

[Chris]

[-- Attachment #1: Type: text/html, Size: 565 bytes --]

[9fans] (no subject)

[Michelle]

[-- Attachment #1: Type: text/html, Size: 570 bytes --]

[9fans] (no subject)

[Fco. J. Ballesteros]

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.

[9fans] (no subject)

[Steven]

[-- Attachment #1: Type: text/html, Size: 567 bytes --]

[9fans] (no subject)

[Pam Moran]

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

[9fans] (no subject)

[Joseph]

[-- Attachment #1: Type: text/html, Size: 538 bytes --]

[9fans] (no subject)

[Don]

[-- Attachment #1: Type: text/html, Size: 518 bytes --]

[9fans] (no subject)

[Steve Simon]

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

[9fans] (no subject)

[Pete]

[-- Attachment #1: Type: text/html, Size: 555 bytes --]

Re: [9fans] (no subject)

[john grove]

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

Re: [9fans] (no subject)

[john grove]

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

[9fans] (no subject)

[matt lawless]

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

[9fans] (no subject)

[Steve Simon]

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

Re: [9fans] (no subject)

[boyd, rounin]

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

Re: [9fans] (no subject)

[Geoff Collyer]

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.

[9fans] (no subject)

[matt]

http://www.theregister.co.uk/2004/04/13/iomega_rev/

Would these make a suitable venti device ?

m

[9fans] (no subject)

[David Presotto]

telnet's dodial fixed to be more understandable.

Re: [9fans] (no subject)

[boyd, rounin]

> 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

Re: [9fans] (no subject)

[Charles Forsyth]

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

Re: [9fans] (no subject)

[Dave Lukes]

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

Re: [9fans] (no subject)

[Charles Forsyth]

couldn't you include the credit card details with that?

[9fans] (no subject)

[David Presotto]

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

[9fans] (no subject)

[Russ Cox]

Re: [9fans] (no subject)

[rog]

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

Re: [9fans] (no subject)

[9nut]

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

Re: [9fans] (no subject)

[boyd, rounin]

any number between 1 and 9 seekable bits is a pint [bad].

Re: [9fans] (no subject)

[David Presotto]

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

Re: [9fans] (no subject)

[Charles Forsyth]

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

Re: [9fans] (no subject)

[C H Forsyth]

perhaps it was `ecanread' existing that was wrong.

Re: [9fans] (no subject)

[Rob Pike]

> 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

Re: [9fans] (no subject)

[David Presotto]

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

Re: [9fans] (no subject)

[Rob Pike]

> 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

[9fans] (no subject)

[David Presotto]

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

[9fans] (no subject)

[sam]

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

[9fans] (no subject)

[engineering]

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

[9fans] (no subject)

[ravi]

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

[9fans] (no subject)

[Sape Mullender]

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

[9fans] (no subject)

[David Presotto]

I fixed select (/sys/src/ape/lib/ap/plan9/_buf.c) to be
links safe.

[9fans] (no subject)

[Steve Simon]

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

Re: [9fans] (no subject)

[David Presotto]

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

[9fans] (no subject)

[andrey mirtchovski]

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

[9fans] (no subject)

[David Presotto]

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

[9fans] (no subject)

[David Presotto]

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

Re: [9fans] (no subject)

[Dan Cross]

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.

Re: [9fans] (no subject)

[a]

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?
ア

[9fans] (no subject)

[David Presotto]

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); }

Re: [9fans] (no subject)

[matt]

> object away.  point them out and they'll disappear.

okay, you're on.

It'll be something to do on a Sunday afternoon.

m

[9fans] (no subject)

[matt]

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){

Re: [9fans] (no subject)

[David Presotto]

[-- 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){

Re: [9fans] (no subject)

[Richard Miller]

> 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

[9fans] (no subject)

[David Presotto]

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

[9fans] (no subject)

[steve.simon]

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

Re: [9fans] (no subject)

[matt]

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)

[9fans] (no subject)

[matt]

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

[9fans] (no subject)

[matt]

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

Re: [9fans] (no subject)

[Charles Forsyth]

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

[9fans] (no subject)

[David Presotto]

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

Re: [9fans] (no subject)

[boyd, rounin]

> Anyone have a picture of them selves in utero?

no, but i do have some 12MHz scans from last week.

[9fans] (no subject)

[matt]

hi,

here's my face

hget  http://www.proweb.co.uk/~matt/plan9/matt.h.1 | page

thanks for looking at me

m

Re: [9fans] (no subject)

[Skip Tavakkolian]

> Anyone have a picture of them selves in utero?

With beard or without?

Re: [9fans] (no subject)

[David Presotto]

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

[9fans] (no subject)

[David Presotto]

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

[9fans] (no subject)

[David Presotto]

'whatis foo' should give you a clue.

Re: [9fans] (no subject)

[David Presotto]

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

Re: [9fans] (no subject)

[Vincenzo Volpe]

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

[9fans] (no subject)

[David Presotto]

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.

Re: [9fans] (no subject)

[David Presotto]

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

Re: [9fans] (no subject)

[jmk]

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

[9fans] (no subject)

[Vincenzo Volpe]

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

[9fans] (no subject)

[David Presotto]

	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.

Re: [9fans] (no subject)

[boyd, rounin]

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

[9fans] (no subject)

[David Presotto]

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.

[9fans] (no subject)

[Andrew Simmons]

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.

Re: [9fans] (no subject)

[vic zandy]

> 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

Re: [9fans] (no subject)

[rsc]

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

Re: [9fans] (no subject)

[Russ Cox]

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

Re: [9fans] (no subject)

[David Presotto]

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

[9fans] (no subject)

[bigfoot]

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.

[9fans] (no subject)

[David Presotto]

Missed missed adding an "oldheaders" in dnresolve.c so that it didn't
work with /sys/src/9/ip/nudp.c.  Fixed and updated.

[9fans] (no subject)

[Steve Simon]

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

Re: [9fans] (no subject)

[northern snowfall]

RamFS is a nice clean and simple start.
Don

Re: [9fans] (no subject)

[William Josephson]

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.

[9fans] (no subject)

[Steve Simon]

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

Re: [9fans] (no subject)

[Wayne Walker]

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

Re: [9fans] (no subject)

[Sam]

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

[9fans] (no subject)

[David Presotto]

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.

[9fans] (no subject)

[Leendert van Doorn]

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

[9fans] (no subject)

[Steve Simon]

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

[9fans] (no subject)

[Steve Simon]

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

[9fans] (no subject)

[David Presotto]

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.

[9fans] (no subject)

[David Presotto]

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.

[9fans] (no subject)

[David Presotto]

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.

Re: [9fans] (no subject)

[Russ Cox]

> 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

[9fans] (no subject)

[Steve Simon]

Hi,

Anyone have a simple example of the use of webfs?
I cannot see what it gives over hget.

-Steve

[9fans] (no subject)

[Ian Dichkovsky]

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

Re: [9fans] (no subject)

[bwc]

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

Re: [9fans] (no subject)

[Skip Tavakkolian]

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

[9fans] (no subject)

[presotto]

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

Re: [9fans] (no subject)

[presotto]

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

Re: [9fans] (no subject)

[George Michaelson]

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

[9fans] (no subject)

[bwc]

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

Re: [9fans] (no subject)

[bwc]

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

[9fans] (no subject)

[bwc]

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.

[9fans] (no subject)

[bwc]

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.

[9fans] (no subject)

[bwc]

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.

[9fans] (no subject)

[rob pike, esq.]

9fans
Subject: Re: [9fans] mass storage jukebox

480 terabytes for $2000?  I find that hard to believe,
by a factor of a thousand.

-rob

[9fans] (no subject)

[Adrian L. Thiele]

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

[9fans] (no subject)

[Sape Mullender]

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

Re: [9fans] (no subject)

[Dennis Davis]

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

Re: [9fans] (no subject)

[Ronald G Minnich]

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

Re: [9fans] (no subject)

[matt]

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

[9fans] (no subject)

[presotto]

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.

[9fans] (no subject)

[presotto]

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.

[9fans] (no subject)

[presotto]

/sys/man/1/mail updated to describe upasname and with synopses
for smtp and smtpd.

[9fans] (no subject)

[Russ Cox]

> 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

[9fans] (no subject)

[Russ Cox]

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

[9fans] (no subject)

[/dev/null]

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


--

Re: [9fans] (no subject)

[Douglas A. Gwyn]

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.

Re: [9fans] (no subject)

[bs]

"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!

Re: [9fans] (no subject)

[Anthony Mandic]

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

Re: [9fans] (no subject)

[Thomas Bushnell, BSG]

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.

Re: [9fans] (no subject)

[Thomas Bushnell, BSG]

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.

Re: [9fans] (no subject)

[ozan s yigit]

[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

Re: [9fans] (no subject)

[markp]

> Editors, like sounds, are only in your mind.

do not try to use the editor, only realize the truth ... 
there is no editor.

Re: [9fans] (no subject)

[Andrew Simmons]

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

Re: [9fans] (no subject)

[Sam Ducksworth]

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

Re: [9fans] (no subject)

[Russ Cox]

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

Re: [9fans] (no subject)

[Thomas Bushnell, BSG]

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.

Re: [9fans] (no subject)

[bwc]

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

Re: [9fans] (no subject)

[bwc]

> 2) exactly how many angels can dance on the head of a pin?

I don't know, but their wearing digital watches.

[9fans] (no subject)

[presotto]

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?

Re: [9fans] (no subject)

[Sean Quinlan]

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.

Re: [9fans] (no subject)

[sape]

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

[9fans] (no subject)

[stanv]

---
Некогда бегать по магазинам? www.Shopping.ru - сотни тысяч товаров от 10 тысяч (!) продавцов. Такого выбора нет нигде!

Re: [9fans] (no subject)

[Douglas A. Gwyn]

"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?

Re: [9fans] (no subject)

[John R. Strohm]

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.

Re: [9fans] (no subject)

[Lucio De Re]

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

Re: [9fans] (no subject)

[Ronald G Minnich]

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

[9fans] (no subject)

[presotto]

Is there a pascal compiler written in pascal?

Re: [9fans] (no subject)

[Boyd Roberts]

> NFS has a set attributes call that does permit you to directly set the
> mtime.

Yup, GETATTR / SETATTR -- the horror, the horror ...

Re: [9fans] (no subject)

[Thomas Bushnell, BSG]

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

Re: [9fans] (no subject)

[Douglas A. Gwyn]

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.

Re: [9fans] (no subject)

[bwc]

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

Re: [9fans] (no subject)

[Russ Cox]

> Thanks.

no problem.

Re: [9fans] (no subject)

[bwc]

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

Re: [9fans] (no subject)

[Boyd Roberts]

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

Re: [9fans] (no subject)

[Russ Cox]

> Some implementations of touch would read a byte and write it back.

was there a better way before wstat let you change mtime?

Re: [9fans] (no subject)

[Boyd Roberts]

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?

Re: [9fans] (no subject)

[Douglas A. Gwyn]

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.

Re: [9fans] (no subject)

[rob pike]

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

[9fans] (no subject)

[arisawa]

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

Re: [9fans] (no subject)

[Boyd Roberts]

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

[9fans] (no subject)

[steve.simon]

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

[9fans] (no subject)

[presotto]

You might also look at the virtual clock paper by Carr in an
SOSP proceeding from the 70's.

[9fans] (no subject)

[presotto]

the paper you're alluding to, I believe, was OSMOSIS, a modified
Plan 9 kernel, by Eran Gabber.

Re: [9fans] (no subject)

[presotto]

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

[9fans] (no subject)

[peh]

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

[9fans] (no subject)

[Peter Bosch]

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

For your amusement...

peter.


[-- Attachment #2: I95.jpg --]
[-- Type: image/jpeg, Size: 830568 bytes --]

Re: [9fans] (no subject)

[Fco.J.Ballesteros]

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

Re: [9fans] (no subject)

[Martin Harriss]

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

Re: [9fans] (no subject)

[Fco.J.Ballesteros]

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

[9fans] (no subject)

[geoff]

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.

[9fans] (no subject)

[Usenet News system]

Re: [9fans] (no subject)

[Ralph Corderoy]

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.

Re: [9fans] (no subject)

[andrey mirtchovski]

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

[9fans] (no subject)

[Philippe Anel]

[-- 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 */
};

[9fans] (no subject)

[jmk]

mail 9fans
Subject: Re: Lucent

Oops, I mistyped 'beleaguered', the headline had the
spelling correct.

Re: [9fans] (no subject)

[Jonathan Sergent]

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

RE: [9fans] (no subject)

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

Re: [9fans] (no subject)

[Dan Cross]

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.

Re: [9fans] (no subject)

[Boyd Roberts]

>   "For home or office use."

what?  not suitable for battlefield conditions?

nah, that's what trackballs are for.

Re: [9fans] (no subject)

[Donald Brownlee]

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

Re: [9fans] (no subject)

[Dan Cross]

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.

[9fans] (no subject)

[rob pike]

[9fans] mouse vs key

I would think mouse chords would be singularly
ineffective on the Mac.

-rob

Re: [9fans] (no subject)

[presotto]

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

Re: [9fans] (no subject)

[forsyth]

% man 2 httpd
man: no manual page

[9fans] (no subject)

[presotto]

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

[9fans] (no subject)

[presotto]

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.

[9fans] (no subject)

[Gorka Guardiola Muzquiz]

[9fans] (no subject)

[presotto]

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

[9fans] (no subject)

[Russ Cox]

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