[9fans] using acme/Mail from plan9port in Linux

[9fans] using acme/Mail from plan9port in Linux

[Lorenzo Bolla]

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

Hi all,

can anyone point me to a document (if any) that explains how to use
acme/Mail to read e-mail in Linux?
I couldn't find any useful information in the plan9port distribution and it
does not work "out-of-the-box".

Thanks for your help!
L.

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

Re: [9fans] using acme/Mail from plan9port in Linux

[Mathieu Lonjaret]

On Sat, Nov 21, 2009 at 10:33 PM, Lorenzo Bolla <lbolla@gmail.com> wrote:
> Hi all,
> can anyone point me to a document (if any) that explains how to use
> acme/Mail to read e-mail in Linux?
> I couldn't find any useful information in the plan9port distribution and it
> does not work "out-of-the-box".
> Thanks for your help!
> L.

1) build and install mailfs
cd $PLAN9/src/cmd/upas/
mk install
cd nfs
mk install

2) configuration
cd $PLAN9/log; chmod 666 smtp smtp.debug smtp.fail mail >smtp
>smtp.debug >smtp.fail >mail
cd $PLAN9/mail/lib
edit rewrite
optionnally edit remotemail

3) authentication
factotum
factotum -g 'proto=pass service=imap server=your.imap.server
user=you_there !password?'

4) run it!
mailfs -t your.imap.server (-t is for tls)
button 2 exec on  'Mail' in acme (without the quotes)
(you need the plumber running for everything to work as expected in acme)

hth,
Mathieu

Re: [9fans] using acme/Mail from plan9port in Linux

[Jason Catena]

I followed these excellent instructions to the end (mailfs:
imapconnect: Success) and get this error when I try to button-2-click
Mail in acme.

mailfs: imapconnect: Success
Mail: cannot mount mail: dial unix!/tmp/ns.jdc.192.168.1.102:0/mail:
connect /tmp/ns.jdc.192.168.1.102:0/mail: No such file or directory

mail is indeed not in the namespace directory.  These files are present.

/tmp/ns.jdc.192.168.1.102:0/acme
/tmp/ns.jdc.192.168.1.102:0/factotum
/tmp/ns.jdc.192.168.1.102:0/plumb

What should I run to make it present?  Does mailfs mislead me by
saying it succeeded?

Jason Catena




On Sat, Nov 21, 2009 at 16:27, Mathieu Lonjaret
<mathieu.lonjaret@gmail.com> wrote:
> On Sat, Nov 21, 2009 at 10:33 PM, Lorenzo Bolla <lbolla@gmail.com> wrote:
>> Hi all,
>> can anyone point me to a document (if any) that explains how to use
>> acme/Mail to read e-mail in Linux?
>> I couldn't find any useful information in the plan9port distribution and it
>> does not work "out-of-the-box".
>> Thanks for your help!
>> L.
>
> 1) build and install mailfs
> cd $PLAN9/src/cmd/upas/
> mk install
> cd nfs
> mk install
>
> 2) configuration
> cd $PLAN9/log; chmod 666 smtp smtp.debug smtp.fail mail >smtp
>>smtp.debug >smtp.fail >mail
> cd $PLAN9/mail/lib
> edit rewrite
> optionnally edit remotemail
>
> 3) authentication
> factotum
> factotum -g 'proto=pass service=imap server=your.imap.server
> user=you_there !password?'
>
> 4) run it!
> mailfs -t your.imap.server (-t is for tls)
> button 2 exec on  'Mail' in acme (without the quotes)
> (you need the plumber running for everything to work as expected in acme)
>
> hth,
> Mathieu
>
>

Re: [9fans] using acme/Mail from plan9port in Linux

[hugo rivera]

I configured mailfs so now I can read email, thanks.
But writing mail is not going so well:

$ cat $PLAN9/log/smtp.fail
myhost Mar 23 11:21:44 bad network /net/net!my.smtp.server!smtp (my.smtp.server)
myhost Mar 23 11:28:06 bad network /net/net!my.smtp.server!smtp (my.smtp.server)
myhost Mar 23 11:34:20 bad network /net/net!my.smtp.server!smtp (my.smtp.server)

after using marshal to send messages. The file
$PLAN9/mail/queue/hugo/E.XXXXXX contains a very similar error

smtp: bad network /net/net!my.smtp.server!smtp (my.smtp.server)

I've been playing around with files inside $PLAN9/mail/lib but no
success so far. Any tips are welcome! :-)

2009/11/21 Mathieu Lonjaret <mathieu.lonjaret@gmail.com>:
> On Sat, Nov 21, 2009 at 10:33 PM, Lorenzo Bolla <lbolla@gmail.com> wrote:
>> Hi all,
>> can anyone point me to a document (if any) that explains how to use
>> acme/Mail to read e-mail in Linux?
>> I couldn't find any useful information in the plan9port distribution and it
>> does not work "out-of-the-box".
>> Thanks for your help!
>> L.
>
> 1) build and install mailfs
> cd $PLAN9/src/cmd/upas/
> mk install
> cd nfs
> mk install
>
> 2) configuration
> cd $PLAN9/log; chmod 666 smtp smtp.debug smtp.fail mail >smtp
>>smtp.debug >smtp.fail >mail
> cd $PLAN9/mail/lib
> edit rewrite
> optionnally edit remotemail
>
> 3) authentication
> factotum
> factotum -g 'proto=pass service=imap server=your.imap.server
> user=you_there !password?'
>
> 4) run it!
> mailfs -t your.imap.server (-t is for tls)
> button 2 exec on  'Mail' in acme (without the quotes)
> (you need the plumber running for everything to work as expected in acme)
>
> hth,
> Mathieu
>
>



-- 
Hugo

Re: [9fans] using acme/Mail from plan9port in Linux

[Mathieu Lonjaret]

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

Hello,

if you haven't done so yet, you need to edit the
$PLAN9/mail/lib/rewrite file like that:

# send all mail to the gateway or mail server, $smtp,  for delivery
([^!]*)!(.*)	|	"$PLAN9/mail/lib/qmail '\s' 'xxx.xxx.xxx.xxx'" "'\2@\1'"

where xxx.xxx.xxx.xxx is the ip address of your smtp.  I think once I
had some resolution problem, that's why I set it by ip here instead of
by name.  Works fine enough so I never bothered to do it by name
afterwards.

hth,
Mathieu

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

From: hugo rivera <uair00@gmail.com>
To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net>
Subject: Re: [9fans] using acme/Mail from plan9port in Linux
Date: Tue, 23 Mar 2010 12:18:56 +0100
Message-ID: <138575261003230418y337542b0xb1b72afd72982e9a@mail.gmail.com>

I configured mailfs so now I can read email, thanks.
But writing mail is not going so well:

$ cat $PLAN9/log/smtp.fail
myhost Mar 23 11:21:44 bad network /net/net!my.smtp.server!smtp (my.smtp.server)
myhost Mar 23 11:28:06 bad network /net/net!my.smtp.server!smtp (my.smtp.server)
myhost Mar 23 11:34:20 bad network /net/net!my.smtp.server!smtp (my.smtp.server)

after using marshal to send messages. The file
$PLAN9/mail/queue/hugo/E.XXXXXX contains a very similar error

smtp: bad network /net/net!my.smtp.server!smtp (my.smtp.server)

I've been playing around with files inside $PLAN9/mail/lib but no
success so far. Any tips are welcome! :-)

2009/11/21 Mathieu Lonjaret <mathieu.lonjaret@gmail.com>:
> On Sat, Nov 21, 2009 at 10:33 PM, Lorenzo Bolla <lbolla@gmail.com> wrote:
>> Hi all,
>> can anyone point me to a document (if any) that explains how to use
>> acme/Mail to read e-mail in Linux?
>> I couldn't find any useful information in the plan9port distribution and it
>> does not work "out-of-the-box".
>> Thanks for your help!
>> L.
>
> 1) build and install mailfs
> cd $PLAN9/src/cmd/upas/
> mk install
> cd nfs
> mk install
>
> 2) configuration
> cd $PLAN9/log; chmod 666 smtp smtp.debug smtp.fail mail >smtp
>>smtp.debug >smtp.fail >mail
> cd $PLAN9/mail/lib
> edit rewrite
> optionnally edit remotemail
>
> 3) authentication
> factotum
> factotum -g 'proto=pass service=imap server=your.imap.server
> user=you_there !password?'
>
> 4) run it!
> mailfs -t your.imap.server (-t is for tls)
> button 2 exec on  'Mail' in acme (without the quotes)
> (you need the plumber running for everything to work as expected in acme)
>
> hth,
> Mathieu
>
>



-- 
Hugo

Re: [9fans] using acme/Mail from plan9port in Linux

[hugo rivera]

Great! now it works. Thank you very much; you answered in the exact
moment, otherwise frustration would have been too great :-)
One last thing (I hope): when I'm reading the mail on my imap server
with nedmail, and I want to save a message, I get

: 3 w /tmp/3
!message disappeared

and nothing gets written. Do you have any idea what's causing this?
and even better, how to solve it :-)

2010/3/23 Mathieu Lonjaret <mathieu.lonjaret@gmail.com>:
> Hello,
>
> if you haven't done so yet, you need to edit the
> $PLAN9/mail/lib/rewrite file like that:
>
> # send all mail to the gateway or mail server, $smtp,  for delivery
> ([^!]*)!(.*)    |       "$PLAN9/mail/lib/qmail '\s' 'xxx.xxx.xxx.xxx'" "'\2@\1'"
>
> where xxx.xxx.xxx.xxx is the ip address of your smtp.  I think once I
> had some resolution problem, that's why I set it by ip here instead of
> by name.  Works fine enough so I never bothered to do it by name
> afterwards.
>
> hth,
> Mathieu
>
>
> ---------- Mensaje reenviado ----------
> From: hugo rivera <uair00@gmail.com>
> To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net>
> Date: Tue, 23 Mar 2010 12:18:56 +0100
> Subject: Re: [9fans] using acme/Mail from plan9port in Linux
> I configured mailfs so now I can read email, thanks.
> But writing mail is not going so well:
>
> $ cat $PLAN9/log/smtp.fail
> myhost Mar 23 11:21:44 bad network /net/net!my.smtp.server!smtp (my.smtp.server)
> myhost Mar 23 11:28:06 bad network /net/net!my.smtp.server!smtp (my.smtp.server)
> myhost Mar 23 11:34:20 bad network /net/net!my.smtp.server!smtp (my.smtp.server)
>
> after using marshal to send messages. The file
> $PLAN9/mail/queue/hugo/E.XXXXXX contains a very similar error
>
> smtp: bad network /net/net!my.smtp.server!smtp (my.smtp.server)
>
> I've been playing around with files inside $PLAN9/mail/lib but no
> success so far. Any tips are welcome! :-)
>
> 2009/11/21 Mathieu Lonjaret <mathieu.lonjaret@gmail.com>:
>> On Sat, Nov 21, 2009 at 10:33 PM, Lorenzo Bolla <lbolla@gmail.com> wrote:
>>> Hi all,
>>> can anyone point me to a document (if any) that explains how to use
>>> acme/Mail to read e-mail in Linux?
>>> I couldn't find any useful information in the plan9port distribution and it
>>> does not work "out-of-the-box".
>>> Thanks for your help!
>>> L.
>>
>> 1) build and install mailfs
>> cd $PLAN9/src/cmd/upas/
>> mk install
>> cd nfs
>> mk install
>>
>> 2) configuration
>> cd $PLAN9/log; chmod 666 smtp smtp.debug smtp.fail mail >smtp
>>>smtp.debug >smtp.fail >mail
>> cd $PLAN9/mail/lib
>> edit rewrite
>> optionnally edit remotemail
>>
>> 3) authentication
>> factotum
>> factotum -g 'proto=pass service=imap server=your.imap.server
>> user=you_there !password?'
>>
>> 4) run it!
>> mailfs -t your.imap.server (-t is for tls)
>> button 2 exec on  'Mail' in acme (without the quotes)
>> (you need the plumber running for everything to work as expected in acme)
>>
>> hth,
>> Mathieu
>>
>>
>
>
>
> --
> Hugo
>
>



-- 
Hugo

Re: [9fans] using acme/Mail from plan9port in Linux

[Mathieu Lonjaret]

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

Nope, I hardly ever tried nedmail. Others like Erik might know.

jsyk, saving a message is dead easy from acme Mail, you just middle
click on "Save imapfoldername" ;) (assuming the imap folder already
exists)

Cheers,
Mathieu

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

From: hugo rivera <uair00@gmail.com>
To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net>
Subject: Re: [9fans] using acme/Mail from plan9port in Linux
Date: Tue, 23 Mar 2010 14:27:44 +0100
Message-ID: <138575261003230627kb81c42q7710df1af4283919@mail.gmail.com>

Great! now it works. Thank you very much; you answered in the exact
moment, otherwise frustration would have been too great :-)
One last thing (I hope): when I'm reading the mail on my imap server
with nedmail, and I want to save a message, I get

: 3 w /tmp/3
!message disappeared

and nothing gets written. Do you have any idea what's causing this?
and even better, how to solve it :-)

2010/3/23 Mathieu Lonjaret <mathieu.lonjaret@gmail.com>:
> Hello,
>
> if you haven't done so yet, you need to edit the
> $PLAN9/mail/lib/rewrite file like that:
>
> # send all mail to the gateway or mail server, $smtp,  for delivery
> ([^!]*)!(.*)    |       "$PLAN9/mail/lib/qmail '\s' 'xxx.xxx.xxx.xxx'" "'\2@\1'"
>
> where xxx.xxx.xxx.xxx is the ip address of your smtp.  I think once I
> had some resolution problem, that's why I set it by ip here instead of
> by name.  Works fine enough so I never bothered to do it by name
> afterwards.
>
> hth,
> Mathieu
>
>
> ---------- Mensaje reenviado ----------
> From: hugo rivera <uair00@gmail.com>
> To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net>
> Date: Tue, 23 Mar 2010 12:18:56 +0100
> Subject: Re: [9fans] using acme/Mail from plan9port in Linux
> I configured mailfs so now I can read email, thanks.
> But writing mail is not going so well:
>
> $ cat $PLAN9/log/smtp.fail
> myhost Mar 23 11:21:44 bad network /net/net!my.smtp.server!smtp (my.smtp.server)
> myhost Mar 23 11:28:06 bad network /net/net!my.smtp.server!smtp (my.smtp.server)
> myhost Mar 23 11:34:20 bad network /net/net!my.smtp.server!smtp (my.smtp.server)
>
> after using marshal to send messages. The file
> $PLAN9/mail/queue/hugo/E.XXXXXX contains a very similar error
>
> smtp: bad network /net/net!my.smtp.server!smtp (my.smtp.server)
>
> I've been playing around with files inside $PLAN9/mail/lib but no
> success so far. Any tips are welcome! :-)
>
> 2009/11/21 Mathieu Lonjaret <mathieu.lonjaret@gmail.com>:
>> On Sat, Nov 21, 2009 at 10:33 PM, Lorenzo Bolla <lbolla@gmail.com> wrote:
>>> Hi all,
>>> can anyone point me to a document (if any) that explains how to use
>>> acme/Mail to read e-mail in Linux?
>>> I couldn't find any useful information in the plan9port distribution and it
>>> does not work "out-of-the-box".
>>> Thanks for your help!
>>> L.
>>
>> 1) build and install mailfs
>> cd $PLAN9/src/cmd/upas/
>> mk install
>> cd nfs
>> mk install
>>
>> 2) configuration
>> cd $PLAN9/log; chmod 666 smtp smtp.debug smtp.fail mail >smtp
>>>smtp.debug >smtp.fail >mail
>> cd $PLAN9/mail/lib
>> edit rewrite
>> optionnally edit remotemail
>>
>> 3) authentication
>> factotum
>> factotum -g 'proto=pass service=imap server=your.imap.server
>> user=you_there !password?'
>>
>> 4) run it!
>> mailfs -t your.imap.server (-t is for tls)
>> button 2 exec on  'Mail' in acme (without the quotes)
>> (you need the plumber running for everything to work as expected in acme)
>>
>> hth,
>> Mathieu
>>
>>
>
>
>
> --
> Hugo
>
>



-- 
Hugo

Re: [9fans] using acme/Mail from plan9port in Linux

[erik quanstrom]

> Nope, I hardly ever tried nedmail. Others like Erik might know.
>
> jsyk, saving a message is dead easy from acme Mail, you just middle
> click on "Save imapfoldername" ;) (assuming the imap folder already
> exists)

i don't know about the current nedmail for p9p.  i'd guess
that's a path problem.  run ned in the debugger and set
a bp on open.  i'm guessing you'll find a path that needs
adjusting for p9p/mailfs' different fs structure.

- erik

Re: [9fans] using acme/Mail from plan9port in Linux

[Steve Simon]

> when I'm reading the mail on my imap server
> with nedmail, and I want to save a message, I get
>
> : 3 w /tmp/3
> !message disappeared

I have no idea if this is related but in the early days with gmail it would
automaticially remove messages when they where downloaded so they disappeared
as fast as you tried to read them.

Perhaps your imap server is doing somthing similar?

-Steve

Re: [9fans] using acme/Mail from plan9port in Linux

[David Leimbach]

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

On Tue, Mar 23, 2010 at 8:13 AM, Steve Simon <steve@quintile.net> wrote:

> > when I'm reading the mail on my imap server
> > with nedmail, and I want to save a message, I get
> >
> > : 3 w /tmp/3
> > !message disappeared
>
> I have no idea if this is related but in the early days with gmail it would
> automaticially remove messages when they where downloaded so they
> disappeared
> as fast as you tried to read them.
>
> Perhaps your imap server is doing somthing similar?
>

Did gmail stop doing that?


>
> -Steve
>
>

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

Re: [9fans] using acme/Mail from plan9port in Linux

[Steve Simon]

> Did gmail stop doing that?

I think there as a fix, perhaps gmail now
supports imap, or perhaps there was an option to disable
this mode of operation?

I rarely use my gmail account, prefering nedmail ☺

-Steve

Re: [9fans] using acme/Mail from plan9port in Linux

[Russ Cox]

> I have no idea if this is related but in the early days with gmail it would
> automaticially remove messages when they where downloaded so they disappeared
> as fast as you tried to read them.
>
> Perhaps your imap server is doing somthing similar?

That was with POP3, not with IMAP.

As to the original question, when I run acme Mail on
plan9port I don't bother to set up the upas mail queues,
which frankly I don't trust on top of a Unix file system.
Instead you can create a $HOME/bin/pipefrom that
sends the mail via the system mailer, maybe even
on another machine.

This is my current version, which is a bit more complex
than it needs to be, but you get the idea.  You could
drop the ssh if you trust your local mail installation
to be configured properly.

Russ

#!/usr/local/plan9/bin/rc

host=swtch.com  # where to relay via ssh

if(! ~ $#upasname 1)
	upasname=rsc+bounces@swtch.com

echo $* >>/home/rsc/pipefrom.log
. /usr/local/plan9/bin/9.rc

if(~ $1 -x){
	shift
	echo $*
	exit 0
}
if(~ $1 -*){
	echo 'cannot deal with options' >[1=2]
	exit 1
}

ipaddr=`{/sbin/ifconfig | sed -n 's/.*inet addr:([^ ]*) .*/\1/p'}
if(~ $#ipaddr 0){
	echo not online >[1=2]
	exit offline
}

exec ssh $host sendmail -f $upasname $* rsc+outbox@swtch.com

Re: [9fans] using acme/Mail from plan9port in Linux

[hugo rivera]

Thanks a lot!

2010/3/23 Russ Cox <rsc@swtch.com>:
>> I have no idea if this is related but in the early days with gmail it would
>> automaticially remove messages when they where downloaded so they disappeared
>> as fast as you tried to read them.
>>
>> Perhaps your imap server is doing somthing similar?
>
> That was with POP3, not with IMAP.
>
> As to the original question, when I run acme Mail on
> plan9port I don't bother to set up the upas mail queues,
> which frankly I don't trust on top of a Unix file system.
> Instead you can create a $HOME/bin/pipefrom that
> sends the mail via the system mailer, maybe even
> on another machine.
>
> This is my current version, which is a bit more complex
> than it needs to be, but you get the idea.  You could
> drop the ssh if you trust your local mail installation
> to be configured properly.
>
> Russ
>
> #!/usr/local/plan9/bin/rc
>
> host=swtch.com  # where to relay via ssh
>
> if(! ~ $#upasname 1)
>        upasname=rsc+bounces@swtch.com
>
> echo $* >>/home/rsc/pipefrom.log
> . /usr/local/plan9/bin/9.rc
>
> if(~ $1 -x){
>        shift
>        echo $*
>        exit 0
> }
> if(~ $1 -*){
>        echo 'cannot deal with options' >[1=2]
>        exit 1
> }
>
> ipaddr=`{/sbin/ifconfig | sed -n 's/.*inet addr:([^ ]*) .*/\1/p'}
> if(~ $#ipaddr 0){
>        echo not online >[1=2]
>        exit offline
> }
>
> exec ssh $host sendmail -f $upasname $* rsc+outbox@swtch.com
>
>



-- 
Hugo

Re: [9fans] using acme/Mail from plan9port in Linux

[Russ Cox]

Sorry, I wrote $HOME/bin/pipefrom
but in fact I meant $HOME/mail/pipefrom.

Russ

[9fans] VIA Rhine II support?

[EBo]

Searching the net reveled that Stephan got his VIA Rhine II ethernet working a
couple of years ago.  Where can I find the patch or drivers?

  EBo --

[9fans] native install

[EBo]

I just wanted to take a moment to thank Iru and Erik for their help with
getting Plan 9 installed natively on my 4 machines.  While I'm still having
some difficulties with SATA/IDE issues, and non-supported ethernet devices, at
least now I can test native support as well as hosted inferno, plan9port, and 9xv.

  Thanks!

  EBo --

Re: [9fans] VIA Rhine II support?

[Federico G. Benavento]

the drivers are in /sys/src/9/pc, ethervt6102.c and ethervt6105m.c
check the device ID on those to see if they match yours, if they don't
it might be an easy fix or a hard fix...


On Wed, Mar 24, 2010 at 6:50 AM, EBo <ebo@sandien.com> wrote:
>
> Searching the net reveled that Stephan got his VIA Rhine II ethernet working a
> couple of years ago.  Where can I find the patch or drivers?
>
>  EBo --
>
>
>



-- 
Federico G. Benavento

Re: [9fans] native install

[David Leimbach]

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

I'm glad there's another person out there with 4 machines running plan 9.
 That's really great.  I never got beyond 2 :-)

Dave

On Wed, Mar 24, 2010 at 2:59 AM, EBo <ebo@sandien.com> wrote:

> I just wanted to take a moment to thank Iru and Erik for their help with
> getting Plan 9 installed natively on my 4 machines.  While I'm still having
> some difficulties with SATA/IDE issues, and non-supported ethernet devices,
> at
> least now I can test native support as well as hosted inferno, plan9port,
> and 9xv.
>
>  Thanks!
>
>  EBo --
>
>

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

Re: [9fans] native install

[Richard Miller]

> I'm glad there's another person out there with 4 machines running plan 9.

Six here.  Only three actually switched on at this moment.

Re: [9fans] native install

[Francisco J Ballesteros]

About 4 * 40 here (students) plus
our terminals and servers (4, 5 people, depends).

On Wed, Mar 24, 2010 at 4:17 PM, Richard Miller <9fans@hamnavoe.com> wrote:
>> I'm glad there's another person out there with 4 machines running plan 9.
>
> Six here.  Only three actually switched on at this moment.
>
>
>

Re: [9fans] native install

[andrey mirtchovski]

64 at one time. 0 now.

Re: [9fans] native install

[erik quanstrom]

On Wed Mar 24 11:24:04 EDT 2010, nemo@lsub.org wrote:
> About 4 * 40 here (students) plus
> our terminals and servers (4, 5 people, depends).
>
> On Wed, Mar 24, 2010 at 4:17 PM, Richard Miller <9fans@hamnavoe.com> wrote:
> >> I'm glad there's another person out there with 4 machines running plan 9.
> >
> > Six here.  Only three actually switched on at this moment.

i have 3 cpu servers running (two for testing), 1 terminal, 1 ken fs,
and 1 coraid storage unit.

coraid runs 8 cpu servers in production, 3 ken fs file servers
(one backup) and 3 coraid storage units.  coraid also
runs a large number of testing boxes.  about 20 people
run a terminal, 9vx or drawterm.

- erik

Re: [9fans] native install

[Steve Simon]

Only two, one home and one work,

Drawterm is usually active
on another two or three Mac/PCs.

-Steve

Re: [9fans] native install

[Gabriel Diaz Lopez de la Llave]

hello

from 1 to 3. . .vmware or qemu (all of them).. . .i'm thinking in buying a modern PC in which i can run it natively...suggestions?

gabi

El 24/03/2010, a las 17:05, Steve Simon escribió:

> Only two, one home and one work,
> 
> Drawterm is usually active
> on another two or three Mac/PCs.
> 
> -Steve
> 

Re: [9fans] native install

[Steve Simon]

I recently built a machine using a dualcore atom card from supermicro
its quick, draws very little power and is rock solid.

email me for the details if you like.

-Steve

(Thanks to erik for 9atom bits).

Re: [9fans] native install

[EBo]

> from 1 to 3. . .vmware or qemu (all of them).. . .i'm thinking
> in buying a modern PC in which i can run it natively...suggestions?

While I have not bought one yet (money's a little tight at the moment), take a
look at http://open-pc.com/.  At least since everything is open, even if the
device drivers are not available there is still a chance <grumble, grumble...
#!@#!$! BROADCOM $#@*!@(*&$>

Re: [9fans] native install

[Lyndon Nerenberg (VE6BBM/VE7TFX)]

I have three native machines:

 Supermicro 5015A-H w/500GB IDE: fossil/venti/auth/dhcpd/tftpd

 Supermicro 5015A-H (diskless): CPU server

 Via EPIA-EK (1GHz C3 Eden-N processor) (diskless): terminal

When I move back onto the boat I will be adding another CPU server
with a whack of serial ports that will talk to all the comm and nav
gear.  For this I'm leaning towards a PC/104+ system; they're small,
very low power, and have oodles of I/O expansion capability (like ADCs
that can hook up to the engine sensors for things like water/oil
pressure and temperature, tank levels, etc.).

--lyndon

Re: [9fans] native install

[John Floren]

On Wed, Mar 24, 2010 at 4:11 PM, EBo <ebo@sandien.com> wrote:
>
>> from 1 to 3. . .vmware or qemu (all of them).. . .i'm thinking
>> in buying a modern PC in which i can run it natively...suggestions?
>
> While I have not bought one yet (money's a little tight at the moment), take a
> look at http://open-pc.com/.  At least since everything is open, even if the
> device drivers are not available there is still a chance <grumble, grumble...
> #!@#!$! BROADCOM $#@*!@(*&$>
>

I think for 360 Euro, I could build a better, Plan 9-compatible
machine and *not* donate money to the KDE project while I'm at it.

Should there be something on the wiki/elsewhere where people can post
the specs of computers they are using and what hardware works/doesn't
work? The supported hardware list tends to be a bit vague; I'd like
something where I could look at a list of components for an entire
Plan 9 compatible machine, or see if anybody else is still using
component X.

John

Re: [9fans] native install

[erik quanstrom]

> Should there be something on the wiki/elsewhere where people can post
> the specs of computers they are using and what hardware works/doesn't
> work? The supported hardware list tends to be a bit vague; I'd like
> something where I could look at a list of components for an entire
> Plan 9 compatible machine, or see if anybody else is still using
> component X.

i believe a few complete machines *have* been posted.
i know i mentioned two.

- erik

Re: [9fans] native install

[David du Colombier]

I have the following Plan 9 File servers at home, with the following
motherboards :

 - one Supermicro X7SLA-H, with 3 TB of storage, my new main fileserver,
 - two Intel S815EBM1, one is running 9grid.fr, other is used for testing.

I have also many CPU servers and terminals. Most are old IBM machines
(xSeries, ThinkCentre, ThinkPad).

Of course, I have also a SheevaPlug and few iPAQ running Plan 9.

At work, I am currently using four FabiaTech FX5624 as File or CPU server.
They are running Plan 9 really fine.

--
David du Colombier

Re: [9fans] native install

[Skip Tavakkolian]

at 9netics and rangboom (different locations), there are 4 cpus, 2
kenfs, multiple terms (vmware) and drawterm.

for a project at a client's site, there are: 7+ cpus (sheevaplug,
laptops), a cpu+auth+fossil/venti server and term (vmware) and
drawterm.

Re: [9fans] native install

[Jacob Todd]

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

On Wed, Mar 24, 2010 at 04:19:59PM -0400, John Floren wrote:
> I think for 360 Euro, I could build a better, Plan 9-compatible
> machine and *not* donate money to the KDE project while I'm at it.
> 
> Should there be something on the wiki/elsewhere where people can post
> the specs of computers they are using and what hardware works/doesn't
> work? The supported hardware list tends to be a bit vague; I'd like
> something where I could look at a list of components for an entire
> Plan 9 compatible machine, or see if anybody else is still using
> component X.
> 
> John
> 
My Dell Inspiron 1000 mostly works. I haven't tested the PC Card slot. Audio
most likely doesn't work, and the sis900 driver doesn't work and I haven't
tested the other sis900 driver from here[1]. Everything else is fine.

[1]http://mirtchovski.com/lanlp9/sis900/index.html

-- 
I am a man who does not exist for others.

[-- Attachment #2: Type: application/pgp-signature, Size: 205 bytes --]

Re: [9fans] native install

[erik quanstrom]

> My Dell Inspiron 1000 mostly works. I haven't tested the PC Card slot. Audio
> most likely doesn't work, and the sis900 driver doesn't work and I haven't
> tested the other sis900 driver from here[1]. Everything else is fine.

could you define "doesn't work"?  any errors?

- erik

Re: [9fans] native install

[Maht]

>
> I'd like
> something where I could look at a list of components for an entire
> Plan 9 compatible machine, or see if anybody else is still using
> component X.
>
> John
>
>
If it's been thrown in the trash, it should work great!

I mean that as a slur against the upgrade cycle rather than Plan9, I
have a pile of PIIIs that run Plan9 great.

I've had problems with Qemu recently, I went back to v. 0.8

That said, I've used Proxmox with great success on modern VT enabled chips

http://pve.proxmox.com/wiki/Main_Page

It lets you run some OSes in VT mode alongside Qemu instances. The
virtual networking is brill too, each VM gets it's own IP like it was a
machine on the LAN, no messing about with port redirection.

Re: [9fans] native install

[Federico G. Benavento]

1 MSI G31TM-P21 /Q8200/500GB  cpu/everything server
(the full specs are somewhere in the list)

+ a constant drawterm running on win laptop

--
Federico G. Benavento

Re: [9fans] native install

[Jacob Todd]

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

On Thu, Mar 25, 2010 at 09:25:19AM -0400, erik quanstrom wrote:
> the output of /n/sources/contrib/quanstro/sosether
> would be useful.
> 
> - erik
> 

pci
0.4.0:	net  02.00.00 1039/0900   4 0:00001801 256 1:e4003000 4096

interfaces


kmesg:

Plan 9
E820: 00000000 0009f400 memory
E820: 0009f400 000a0000 reserved
E820: 000dc000 00100000 reserved
E820: 00100000 0ddf0000 memory
E820: 0ddf0000 0ddff000 acpi reclaim
E820: 0ddff000 0de00000 acpi nvs
E820: 0de00000 0e000000 reserved
E820: 0e000000 10000000 reserved
E820: fec00000 fec10000 reserved
E820: fee00000 fee01000 reserved
E820: fff80000 100000000 reserved
126 holes free
00019000 0009f000 548864
0040f000 05ae6000 91058176
91607040 bytes free
cpu0: 2191MHz GenuineIntel PentiumIV/Xeon (cpuid: AX 0x0F29 DX 0xBFEBFBFF)
ELCR: 06B8
#y0: 2 slot Intel 82365SL: port 0x3E0 irq 5
ns83815: auto neg timed out
#u/usb/ep1.0: ohci: port 0xE0000000 irq 9
#u/usb/ep2.0: ohci: port 0xE0001000 irq 10
#u/usb/ep3.0: ehci: port 0xE0002000 irq 3
222M memory: 91M kernel data, 131M user, 502M swap
usbd...usb/disk... root is from (tcp, local)[local!#S/sdC0/fossil]: 
user[none]: jake
time...
fossil(#S/sdC0/fossil)...version...time...

init: starting /bin/rc

The 'ns83815: autneg timed out' was the message being printed.

I've also noticed that the man page for plan9.ini(8), it says
>On the SiS controllers, the Ethernet address is not
>detected properly; specify it with an ea= attribute.

Is ea= supposed to be set to the actual ip address (the man page says physical
network adress)? If so that's probably my problem.

-- 
I am a man who does not exist for others.

[-- Attachment #2: Type: application/pgp-signature, Size: 205 bytes --]

Re: [9fans] native install

[Jacob Todd]

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

On Wed, Mar 24, 2010 at 09:35:39PM -0400, erik quanstrom wrote:
> could you define "doesn't work"?  any errors?
> 
> - erik
> 
When I boot plan 9, the message `probing ether' is printed and then `auto neg
something' is printed a second or two after that. I can find out what the actual
message is later.

-- 
I am a man who does not exist for others.

[-- Attachment #2: Type: application/pgp-signature, Size: 205 bytes --]

Re: [9fans] native install

[erik quanstrom]

> When I boot plan 9, the message `probing ether' is printed and then `auto neg
> something' is printed a second or two after that. I can find out what the actual
> message is later.

the output of /n/sources/contrib/quanstro/sosether
would be useful.

- erik

Re: [9fans] native install

[Jacob Todd]

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

On Thu, Mar 25, 2010 at 11:43:36AM -0400, erik quanstrom wrote:
> > I've also noticed that the man page for plan9.ini(8), it says
> > >On the SiS controllers, the Ethernet address is not
> > >detected properly; specify it with an ea= attribute.
> > 
> > Is ea= supposed to be set to the actual ip address (the man page says physical
> > network adress)? If so that's probably my problem.
> 
> ea is supposed to be an ethernet address.  ethernet
> addresses have the format
> 	ea=112233445566
> where 1-6 are *lowercase* hex digits.  the first
> byte & 0x80 should be 0.
> 
> - erik
> 
Sorry for my ignorance, but how would I find out the ethernet address(es)?

-- 
I am a man who does not exist for others.

[-- Attachment #2: Type: application/pgp-signature, Size: 205 bytes --]

Re: [9fans] native install

[Steve Simon]

> When I boot plan 9, the message `probing ether' is printed and then `auto neg
> something' is printed a second or two after that. I can find out what the actual
> message is later.

If the message is printed by the kernel rather than 9load you can find
it by typing:

	cat /dev/kmesg

-Steve

Re: [9fans] native install

[erik quanstrom]

> I've also noticed that the man page for plan9.ini(8), it says
> >On the SiS controllers, the Ethernet address is not
> >detected properly; specify it with an ea= attribute.
>
> Is ea= supposed to be set to the actual ip address (the man page says physical
> network adress)? If so that's probably my problem.

ea is supposed to be an ethernet address.  ethernet
addresses have the format
	ea=112233445566
where 1-6 are *lowercase* hex digits.  the first
byte & 0x80 should be 0.

- erik

Re: [9fans] VIA Rhine II support?

[Harri Haataja]

On 24 March 2010 12:24, Federico G. Benavento <benavento@gmail.com> wrote:
> the drivers are in /sys/src/9/pc, ethervt6102.c and ethervt6105m.c
> check the device ID on those to see if they match yours, if they don't
> it might be an easy fix or a hard fix...
>
> On Wed, Mar 24, 2010 at 6:50 AM, EBo <ebo@sandien.com> wrote:
>> Searching the net reveled that Stephan got his VIA Rhine II ethernet working a
>> couple of years ago.  Where can I find the patch or drivers?

As with other things Via, I'd recommend avoiding Rhine chips like the plague.

-- 
I appear to be temporarily using gmail's horrible interface. I
apologise for any failure in my part in trying to make it do the right
thing with post formatting.

Re: [9fans] native install

[erik quanstrom]

> > > Is ea= supposed to be set to the actual ip address (the man page says physical
> > > network adress)? If so that's probably my problem.
> >
> > ea is supposed to be an ethernet address.  ethernet
> > addresses have the format
> > 	ea=112233445566
> > where 1-6 are *lowercase* hex digits.  the first
> > byte & 0x80 should be 0.
> >
> > - erik
> >
> Sorry for my ignorance, but how would I find out the ethernet address(es)?

the hardware is supposed to know it.  if it doesn't the hardware
is having trouble talking to its eeprom/flash.  in this case, you
can get by by making one up.  though officially, they're allocated
in blocks,  c.f. etheroui(1), wwnoui(1) — contrib quanstro/oui.
the database is in /lib/oui.

- erik

Re: [9fans] VIA Rhine II support?

[EBo]

> As with other things Via, I'd recommend avoiding Rhine chips like the plague.

this is not a new buy, but an 8 year old laptop I'm playing with.  At least
the Rhine chip has better support than Broadcom as far as I can tell.  Now
*THAT* is company I avoid like a plague...

Re: [9fans] native install

[Steve Simon]

> Sorry for my ignorance, but how would I find out the ethernet address(es)?

A long shot, somtimes its printed on the card (PCI or PCMCIA),
but othertimes it is not. The important fact is that you must not
use the same address as any other device on the same physical network.

-Steve

Re: [9fans] native install

[Jorden Mauro]

Someone should put this whole thread on the wiki

Re: [9fans] native install

[Federico G. Benavento]

if the ethernet address is broken you can try to see if the nic
is still usable by setting promiscuous mode on...

I had the a problem years ago with andrey's sis900 driver
(the one in the distribution didn't work with my nic), when
I changed from a terminal to a 9pcf kernel it stopped working!

somehow it wasn't getting the eaddr right, after some debugging
I noticed that the distribution driver worked, but only when
snoopy was running... I'm a network ignorant and I was even
more ignorant then, so I didn't notice that snoopy reported
0xFFFFFFF or something for address and it worked because
snoopy turns promiscuous mode on.

so I checked the lunixes driver and found out how to write the
ether address correctly to the device and got it working,
but ironically a day later geoff pushed his version of the driver
for kenfs which was a merge of andrey's and charles' driver...



--
Federico G. Benavento

Re: [9fans] native install

[Georg Lehner]

David Leimbach wrote:
> I'm glad there's another person out there with 4 machines running plan
> 9.  That's really great.  I never got beyond 2 :-)
> [..]
file/auth/cpu server at home: DFI-ACP Board: G5C100-N, Intel 945GM ICH7M
installable only eriks 9atom.iso

file/auth/cpu server at work: some inherited development workstation,
spec currently
not available.

When/if i get Linux and Windows to work seemlessly with the fileserver i
will possibly have
a permanently running drawterm.

Until today i'm just a stubborn believer in Plan9. Real world experience
with this system
is, that nothing else works (out of the box) and nobody else uses it,
besides people working
with and for Plan9 just for the sake of it.

Regards,

    Jorge-Le�n


P.S.: Though the interface is really brilliant, it does not work out
well for a lefty with a
   german keyboard layout :-/

Re: [9fans] native install

[erik quanstrom]

> Until today i'm just a stubborn believer in Plan9. Real world experience
> with this system is, that nothing else works (out of the box) and nobody else uses it,
> besides people working with and for Plan9 just for the sake of it.

speaking only for myself:
	http://www.coraid.com.  thousands of installed systems.

> P.S.: Though the interface is really brilliant, it does not work out
> well for a lefty with a
>    german keyboard layout :-/

you can change the layout:

kbmap(1), kbin(3), kbmap(3).

- erik

Re: [9fans] native install

[maht]

> Until today i'm just a stubborn believer in Plan9. Real world
> experience with this system
> is, that nothing else works (out of the box) and nobody else uses it,
> besides people working
> with and for Plan9 just for the sake of it.
Sorry to hear you think like that. I've been using Plan9 for about 10
years as my day to day work environment for non-Plan9 based coding, I
can't remember anything that hasn't worked aside from kit without drivers.

A shame that the tool doesn't suit your needs but blaming the tool is a
bit much.

Re: [9fans] native install

[Georg Lehner]

erik quanstrom wrote:
>> P.S.: Though the interface is really brilliant, it does not work out
>> well for a lefty with a
>>    german keyboard layout :-/
>>
>
> you can change the layout:
>
> kbmap(1), kbin(3), kbmap(3).
>
> - erik
Ok, i know kbmap :)

This 'leftys are poor people' feeling comes from MS-Windows and their
GUI-philosophy-follower
which define Ctrl+V, Ctrl+X and Ctrl+C as shortcuts.  These are on the
left side of the keyboard,
so i have to move the left hand between keyboard and mouse frustratingly
often.

I apologize for blaming rio et al for something that they never have done...

Would right/left-handed dvorak be a good choice to keep one hand on the
mouse and the other
on the keyboard?

Best Regards,

    Jorge-Le�n

Re: [9fans] native install

[Georg Lehner]

maht wrote:
>
>> Until today i'm just a stubborn believer in Plan9. Real world
>> experience with this system
>> is, that nothing else works (out of the box) and nobody else uses it,
>> besides people working
>> with and for Plan9 just for the sake of it.
> Sorry to hear you think like that. I've been using Plan9 for about 10
> years as my day to day work environment for non-Plan9 based coding, I
> can't remember anything that hasn't worked aside from kit without
> drivers.
Would you be willing to elaborate about your working setups as far as
non-Plan9 based coding is
concerned.

I would also be happy to hear about how non-coding activities are
typically handled by using
a Plan9 system.

The recent survey of how Plan9 inventors use Plan9 today (it seems
mostly they don't) has
cast some shadow of doubt on me that day to day computer work is ideally
done on a Plan9
terminal.

Regards,

    Jorge-Le�n

Re: [9fans] native install

[erik quanstrom]

> I would also be happy to hear about how non-coding activities are
> typically handled by using a Plan9 system.

what non-coding activities?  ☺

- erik

Re: [9fans] native install

[michael block]

On Mon, Mar 29, 2010 at 13:57, Georg Lehner <jorge-plan9@magma.com.ni> wrote:
> Would right/left-handed dvorak be a good choice to keep one hand on the
> mouse and the other on the keyboard?

it works alright for web browsing or if you're just typing english
(and probably german as well), but you really have to stretch for
non-alphabetic keys so it's less suitable for programming or anything
but simple rc commands. i mapped many of the special keys to the numpad,
but that might not work so well for a lefty

Re: [9fans] native install

[maht]

On 29/03/2010 21:07, Georg Lehner wrote:
> maht wrote:
>>
>>> Until today i'm just a stubborn believer in Plan9. Real world
>>> experience with this system
>>> is, that nothing else works (out of the box) and nobody else uses
>>> it, besides people working
>>> with and for Plan9 just for the sake of it.
>> Sorry to hear you think like that. I've been using Plan9 for about 10
>> years as my day to day work environment for non-Plan9 based coding, I
>> can't remember anything that hasn't worked aside from kit without
>> drivers.
> Would you be willing to elaborate about your working setups as far as
> non-Plan9 based coding is
> concerned.
>
>

I edit text, sometimes I run programs over it and it is changed, I write
these programs. The environment of Plan9 is very much suited to this
activity. I use it to control the activities of the Windows / Linux /
*BSD / OSX machines in my empire.

I connect them together with 9p tunnelled over ssh, Plan9 <> Plan9, SMB,
bit of ftp, AoE. I jump around through firewalls and other tunnels all
for the precious 9p, the Queen of Kings.

I sit at a non Plan9 terminal and wonder how the savages manage.

Re: [9fans] native install

[ron minnich]

On Mon, Mar 29, 2010 at 1:58 PM, Corey <corey@bitworthy.net> wrote:

> Plan9: an old-school IDE and a file server wrapped into one.
>
> The mind reels.
>
> Sometimes, less is _not_ more.
>
>

OK, that's it, we're not going to let you use it any more.

:-)

ron

Re: [9fans] native install

[Corey]

On Monday 29 March 2010 13:07:23 Georg Lehner wrote:
> The recent survey of how Plan9 inventors use Plan9 today (it seems
> mostly they don't) has cast some shadow of doubt on me that day 
> to day computer work is ideally done on a Plan9 terminal.
> 

Day to day computer work will not generally be done on a Plan9 terminal until
Glenda finally overcomes her profoundly crippling case of automysophobia.

Unfortunately however, it appears that she is surrounded by folks who are
single-mindedly determined to keep her inside a sterile plastic bubble -
according to these people, linux and gnu are, apparently, the boogey men 
that will certainly 'get her' should she ever leave the confines of the 
artificial cocoon that's been built up around her.

9fans: keep on worrying over 'contamination' from the real world, in the mean
time, Plan 9 is a precious little snowflake that is neigh useless outside of 
an extraordinarily narrow variety of use cases:

On Monday 29 March 2010 13:16:59 erik quanstrom wrote:
> > I would also be happy to hear about how non-coding activities are
> > typically handled by using a Plan9 system.
> 
> what non-coding activities?  ☺
> 

Plan9: an old-school IDE and a file server wrapped into one.

The mind reels.

Sometimes, less is _not_ more.

Re: [9fans] native install

[erik quanstrom]

> Day to day computer work will not generally be done on a Plan9 terminal until
> Glenda finally overcomes her profoundly crippling case of automysophobia.
>
> Unfortunately however, it appears that she is surrounded by folks who are
> single-mindedly determined to keep her inside a sterile plastic bubble -
> according to these people, linux and gnu are, apparently, the boogey men
> that will certainly 'get her' should she ever leave the confines of the
> artificial cocoon that's been built up around her.

unless you're going to do something about this, you're just
trolling.

imho, it just doesn't make sense to add this kind of stuff
to plan 9.  it dimishes something very valuable in plan 9
(simplicity) and we already know where to get gnu stuff.

> On Monday 29 March 2010 13:16:59 erik quanstrom wrote:
> > > I would also be happy to hear about how non-coding activities are
> > > typically handled by using a Plan9 system.
> >
> > what non-coding activities?  ☺
> >
>
> Plan9: an old-school IDE and a file server wrapped into one.
>
> The mind reels.
>
> Sometimes, less is _not_ more.

i find plan 9 to be a very effective environment.  i use it
all day, every day.

if you don't, the logical choices are to (a) do something about
it or (b) do something else.

- erik

Re: [9fans] native install

[Patrick Kelly]

On Mar 29, 2010, at 4:16 PM, erik quanstrom wrote:

>> I would also be happy to hear about how non-coding activities are
>> typically handled by using a Plan9 system.
>
> what non-coding activities?  ☺

Surely you have played mahjongg at least once!

> - erik
>

Re: [9fans] Plan ? (was: native install)

[Corey]

On Monday 29 March 2010 14:09:32 erik quanstrom wrote:
> > Day to day computer work will not generally be done on a Plan9 terminal
> > until Glenda finally overcomes her profoundly crippling case of
> > automysophobia.
> >
<snip>
>
> unless you're going to do something about this, you're just
> trolling.
>

(c8=

Heheh... when it's critical of other existing projects and systems -
which goes on all the time here - it's o.k.; but when it's critical of
plan 9, it's known as 'trolling'.

<wink>

> i find plan 9 to be a very effective environment.  i use it
> all day, every day.
>
> if you don't, the logical choices are to (a) do something about
> it or (b) do something else.
>

In any given social environment, communicating dissatisfaction of
the status quo is often the logical first step towards choices (a)
and/or (b) - due to the fact that going off on one's own to work
alone in a vacuum on a major undertaking is generally recognized
as an inherently ill-fated strategy.

> imho, it just doesn't make sense to add this kind of stuff
> to plan 9.  it dimishes something very valuable in plan 9
> (simplicity) and we already know where to get gnu stuff.
>

Understood, and appreciated.

I guess the situation is that there appears to be plenty of people who
_imagine_ something "very valuable" in seeing the base Plan 9 concepts
and idioms being applied within a different context beyond that of
rigorous 'radical purity and simplicity' - yet after 15 years, there still is
no experimental general purpose Plan 9 distributions/projects under way.

Is it that the core Plan 9 design concepts[1] are in fact inappropriate or
uninteresting for anything beyond that which Plan 9 currently provides?

The answer continues to blow in the wind.

[1] http://en.wikipedia.org/wiki/Plan_9_from_Bell_Labs#Design_concepts

Re: [9fans] Plan ? (was: native install)

[erik quanstrom]

> Heheh... when it's critical of other existing projects and systems -
> which goes on all the time here - it's o.k.; but when it's critical of
> plan 9, it's known as 'trolling'.
>
> <wink>
>

actually, yes.

> > i find plan 9 to be a very effective environment.  i use it
> > all day, every day.
> >
> > if you don't, the logical choices are to (a) do something about
> > it or (b) do something else.
> >
>
> In any given social environment, communicating dissatisfaction of
> the status quo is often the logical first step towards choices (a)
> and/or (b) - due to the fact that going off on one's own to work
> alone in a vacuum on a major undertaking is generally recognized
> as an inherently ill-fated strategy.

except that these same arguments have been going on for as long
as i have read this list and no one has done anything about it.
after 15+ years, i think it's fair to ask "where's the beef?"

- erik

Re: [9fans] Plan ? (was: native install)

[Corey]

On Monday 29 March 2010 17:24:08 erik quanstrom wrote:
> > In any given social environment, communicating dissatisfaction of
> > the status quo is often the logical first step towards choices (a)
> > and/or (b) - due to the fact that going off on one's own to work
> > alone in a vacuum on a major undertaking is generally recognized
> > as an inherently ill-fated strategy.
>
> except that these same arguments have been going on for as long
> as i have read this list and no one has done anything about it.
> after 15+ years, i think it's fair to ask "where's the beef?"
>

"Where's the beef?" is certainly a fair and reasonable thing to ask.

What I'm wondering, however, is "_what's_ the beef?"

As you said, these arguments have indeed been going on for some
time - so, why only talk and no action? It's weird.

I can't help but wonder: where's the crux of the inertia?

Are the core Plan 9 design concepts in fact ineffective or unsuitable for
building a general purpose computing environment?

I find that very hard to believe - but there's over 15 years of evidence
which seems to imply just that.

No one's willing to spearhead a "General Purpose 9" experiment, and no
one's interested in collaborating on and contributing to such a project?

"If you want [general purpose], you know where to get it." seems to
be the period that ends all such discussion.

Re: [9fans] Plan ? (was: native install)

[Iruata Souza]

On Mon, Mar 29, 2010 at 10:21 PM, Corey <corey@bitworthy.net> wrote:
> On Monday 29 March 2010 17:24:08 erik quanstrom wrote:
>> > In any given social environment, communicating dissatisfaction of
>> > the status quo is often the logical first step towards choices (a)
>> > and/or (b) - due to the fact that going off on one's own to work
>> > alone in a vacuum on a major undertaking is generally recognized
>> > as an inherently ill-fated strategy.
>>
>> except that these same arguments have been going on for as long
>> as i have read this list and no one has done anything about it.
>> after 15+ years, i think it's fair to ask "where's the beef?"
>>
>
> "Where's the beef?" is certainly a fair and reasonable thing to ask.
>
> What I'm wondering, however, is "_what's_ the beef?"
>
> As you said, these arguments have indeed been going on for some
> time - so, why only talk and no action? It's weird.
>
> I can't help but wonder: where's the crux of the inertia?
>
> Are the core Plan 9 design concepts in fact ineffective or unsuitable for
> building a general purpose computing environment?
>
> I find that very hard to believe - but there's over 15 years of evidence
> which seems to imply just that.
>
> No one's willing to spearhead a "General Purpose 9" experiment, and no
> one's interested in collaborating on and contributing to such a project?

would you invite us for that experiment or keep talking, talking,
talking... and talking?


> "If you want [general purpose], you know where to get it." seems to
> be the period that ends all such discussion.
>

a bunch of special purpose crap put together does not make a general
purpose one.

iru

Re: [9fans] Plan ? (was: native install)

[Jacob Todd]

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

On Mon, Mar 29, 2010 at 06:21:54PM -0700, Corey wrote:
> Are the core Plan 9 design concepts in fact ineffective or unsuitable for
> building a general purpose computing environment?
> 
> I find that very hard to believe - but there's over 15 years of evidence 
> which seems to imply just that.
There's fifteen years of evidence of people *not* applying the core Plan 9
concepts to anything. Not applying a concept isn't proof it's ``ineffective''
or ``unsuitable''.
> 
> No one's willing to spearhead a "General Purpose 9" experiment, and no 
> one's interested in collaborating on and contributing to such a project?
It would seem not. We're happy here, where things are sane.
> 
> "If you want [general purpose], you know where to get it." seems to
> be the period that ends all such discussion.
> 

-- 
I am a man who does not exist for others.

[-- Attachment #2: Type: application/pgp-signature, Size: 205 bytes --]

Re: [9fans] Plan ? (was: native install)

[Iruata Souza]

On Mon, Mar 29, 2010 at 9:20 PM, Corey <corey@bitworthy.net> wrote:
> Is it that the core Plan 9 design concepts[1] are in fact inappropriate or
> uninteresting for anything beyond that which Plan 9 currently provides?
>

[1] /sys/doc

Re: [9fans] Plan ? (was: native install)

[Patrick Kelly]

>>
> "Where's the beef?" is certainly a fair and reasonable thing to ask.

I got hungry and ate it.

> What I'm wondering, however, is "_what's_ the beef?"

Beef comes from the cow.

> As you said, these arguments have indeed been going on for some
> time - so, why only talk and no action? It's weird.

Those of you who desire features haven't implemented anything. Those
of us who use Plan 9 or even just it's tools don't find a need for
anything else. When we do need something, we write it.

> I can't help but wonder: where's the crux of the inertia?

I ate that too.

> Are the core Plan 9 design concepts in fact ineffective or
> unsuitable for
> building a general purpose computing environment?

Should that statement be valid, the creation of UNIX in the first
place is an utter pointless failure; are you willing to say that? Your
justifying the Windows way and slanderizing one of the most
revolutionary changes to systems there was. Plan 9 took that change to
the next level, so you'd be slanderiIng us even more.

Plan 9 is general purpose. There's no reason you can write software
for, say, office suites, graphics edition, audio editing, MIDI,
gaming, or anything else. We just don't have the need for it.

Should you need something, please bring it up. We would be happy to
actually discuss something, so far you don't seem to actually want that.

> I find that very hard to believe - but there's over 15 years of
> evidence
> which seems to imply just that.

Read up on why Plan 9 was written. We've been succeeding for 20 years
so far. We may not be wide spread, but many prefer that.

> No one's willing to spearhead a "General Purpose 9" experiment, and no
> one's interested in collaborating on and contributing to such a
> project?

I am, although I'm paying attention to numerous psychological
concerns, and a large documentation base about language design (most
from Backus).

I prefered to wait to announce this, but we have been disgraced long
enough by people who aren't willing to actually do anything.

I would also also prefer to design the entire toolchain and kernel
myself, then let others in. Mostly I'm doing this to proove we need to
pay more attention to psychological issues in computing, and to show
we should actually read research papers about language/system design.
Should the ideas turn out valid, it'll turn it into a system
specializing in multimedia, specifically professional audio. Plan 9 is
general purpose enough to remain compatable with, even though there's
significant design differences. File oriented design really helps. Yet
you called this a flaw.

Yes I know what I'm getting into.

> "If you want [general purpose], you know where to get it." seems to
> be the period that ends all such discussion.

File oriented, non-specialized; sounds like Plan 9.

Re: [9fans] Plan ? (was: native install)

[Rahul Murmuria]

Well, most of Plan 9's ideas have been trickling down into "general
purpose" operating systems for years! I don't see what others here
claiming failure of Plan 9 are referring to.

In order to bring new technology to mass consumption, you don't bring
the masses to drive the formula 1 race car... you instead try and
adapt the new concepts into the Toyotas and Hondas...

--
Rahul Murmuria

Re: [9fans] Plan ? (was: native install)

[Corey]

Multiple responses following, so that I'm not accused of spamming the list.

On Monday 29 March 2010 19:02:23 Iruata Souza wrote:
> On Mon, Mar 29, 2010 at 10:21 PM, Corey <corey@bitworthy.net> wrote:
<snip>
> > No one's willing to spearhead a "General Purpose 9" experiment, and no
> > one's interested in collaborating on and contributing to such a project?
>

<raises hand>

I'm interested. My qualifications are limited, but I'd be willing to find a
way to contribute.

But first I'd want to know exactly what was meant by "general purpose",
and what's there to gain from it. I'd also want to know where to begin,
and what technical challenges and architectural changes would be involved.
If it's simply about porting gtk, firefox and open office to plan 9, then
forget it. Finally, it's important to establish that this project, whatever
it's called, does not aim to somehow infect Plan 9 proper.

Unfortunately, that's precisely the sort of initial hypothetically-scoped,
collaborative bootstrap process which invariably elicits characteristic 9fans
quips of the usual fare: "talk, talk, talk - where's the code?", "if you want
X you know where to get it.", "Plan 9 _is_ a general purpose o.s.", et cetera.

On Monday 29 March 2010 19:07:07 Jacob Todd wrote:
> > No one's willing to spearhead a "General Purpose 9" experiment, and no
> > one's interested in collaborating on and contributing to such a project?
>
> It would seem not. We're happy here, where things are sane.
>

Where things are sane.

A "general purpose" graphical operating environment built on the Plan 9 kernel
and user space, implemented using the intrinsic Plan 9 conceptual models - is
inherently insane?

Insane, or impossible?

Who knows. Such an effort can't even be properly discussed here - let alone
leave the starting gates.

On Monday 29 March 2010 19:17:03 Patrick Kelly wrote:
> On Mon, Mar 29, 2010 at 10:21 PM, Corey <corey@bitworthy.net> wrote:
> > Are the core Plan 9 design concepts in fact ineffective or
> > unsuitable for building a general purpose computing environment?
>
> Should that statement be valid, the creation of UNIX in the first
> place is an utter pointless failure; are you willing to say that?
<snip>
> Plan 9 took that change to the next level, so you'd be slanderiIng us
> even more.
>

Plan 9 took it to the next level... and then... what happened after that?

> Plan 9 is general purpose. There's no reason you can write software
> for, say, office suites, graphics edition, audio editing, MIDI,
> gaming, or anything else. We just don't have the need for it.
>

"We" don't have the need for those things - because they are already
fulfilled via other operating systems. Plan 9 is, effectively, a purely
auxiliary OS - by design. And we like it that way. We'd rather use *nix,
windows or a mac to do those things than to use Plan 9 for them. But,
as we're using other platforms to do all those things we can't do under
Plan 9, we scornfully complain about how naively designed and horribly
bloated those programs are - yet after fifteen years, "we" still fail to prove
how those things could be better implemented under the superior Plan 9
approach. And we like it that way: distributing files, and programming kenc
in rio with acme under 9term - we feel that Plan 9 has successfully reached
its zenith.

On Monday 29 March 2010 20:10:59 Rahul Murmuria wrote:
> Well, most of Plan 9's ideas have been trickling down into "general
> purpose" operating systems for years!

You're implying that, via the "trickle down" process, Plan 9 will become
completely obviated.

Which Plan 9 ideas would you say have not yet been fully and properly
integrated into other operating systems? And why haven't they?

> I don't see what others here claiming failure of Plan 9 are referring to.
>

(for the record, I'm not claiming that Plan 9 has failed - quite the contrary)

> In order to bring new technology to mass consumption, you don't bring
> the masses to drive the formula 1 race car... you instead try and
> adapt the new concepts into the Toyotas and Hondas...
>

Or you try and adapt the formula 1 race car (or the Jeep, or the HMMWV...)
into something better suited for a somewhat more generic market/use-case.

Re: [9fans] Plan ? (was: native install)

[Steve Simon]

> No one's willing to spearhead a "General Purpose 9" experiment, and no
> one's interested in collaborating on and contributing to such a project?
>
> "If you want [general purpose], you know where to get it." seems to
> be the period that ends all such discussion.

I wouldn't quite agree, the discussions usually end one of three ways:

- somone wants somthing like gnome, and are encouraged to run linux.

- somone wants "the community" to port smthing like gnome and noone is
  interested so they get bored and go away.

- somone wants to write some code to solve a problem they have with plan9
  and the just get on with it and tell the list when its done.

An example:

I need SVN support at work, cinap has wrapped up his linuxemu with the snv
client and the apropriate shared libraries (thanks cinap). This allows me to
continue using plan9 (as I do every day, all day).

In parallel I now have written a webdav client which I hope will become
a DeltaV/SVN client for plan9. I feel its worth writing as I think it is
interesting to try and fit the plan9 file model to SVN's version control model.

I wanted it, I got on with it and wrote it.

> I can't help but wonder: where's the crux of the inertia?

An interesting question. If you can garner enthusism from the list
perhaps you can be "the one" to spearhead a new burst of enthusism?

-Steve

Re: [9fans] Plan ? (was: native install)

[hugo rivera]

I agree with Steve.
I like the community approach to this matter: if plan9 doesn't have
what you need, do it yourself; if you do something that might be
useful for others share it and see what happens.
Being a newbie myself I find very hard to write my own utilities, but
that's a good way to learn ;-)


2010/3/30 Steve Simon <steve@quintile.net>:
>> No one's willing to spearhead a "General Purpose 9" experiment, and no
>> one's interested in collaborating on and contributing to such a project?
>>
>> "If you want [general purpose], you know where to get it." seems to
>> be the period that ends all such discussion.
>
> I wouldn't quite agree, the discussions usually end one of three ways:
>
> - somone wants somthing like gnome, and are encouraged to run linux.
>
> - somone wants "the community" to port smthing like gnome and noone is
>  interested so they get bored and go away.
>
> - somone wants to write some code to solve a problem they have with plan9
>  and the just get on with it and tell the list when its done.
>
> An example:
>
> I need SVN support at work, cinap has wrapped up his linuxemu with the snv
> client and the apropriate shared libraries (thanks cinap). This allows me to
> continue using plan9 (as I do every day, all day).
>
> In parallel I now have written a webdav client which I hope will become
> a DeltaV/SVN client for plan9. I feel its worth writing as I think it is
> interesting to try and fit the plan9 file model to SVN's version control model.
>
> I wanted it, I got on with it and wrote it.
>
>> I can't help but wonder: where's the crux of the inertia?
>
> An interesting question. If you can garner enthusism from the list
> perhaps you can be "the one" to spearhead a new burst of enthusism?
>
> -Steve
>
>



-- 
Hugo

Re: [9fans] Plan ? (was: native install)

[Gabriel Diaz Lopez de la Llave]

hello

This way (dot-it-your-self-way) we will "only" have one-man projects. . .

slds.

gabi

El 30/03/2010, a las 12:19, hugo rivera escribió:

> I agree with Steve.
> I like the community approach to this matter: if plan9 doesn't have
> what you need, do it yourself; if you do something that might be
> useful for others share it and see what happens.
> Being a newbie myself I find very hard to write my own utilities, but
> that's a good way to learn ;-)
> 
> 
> 2010/3/30 Steve Simon <steve@quintile.net>:
>>> No one's willing to spearhead a "General Purpose 9" experiment, and no
>>> one's interested in collaborating on and contributing to such a project?
>>> 
>>> "If you want [general purpose], you know where to get it." seems to
>>> be the period that ends all such discussion.
>> 
>> I wouldn't quite agree, the discussions usually end one of three ways:
>> 
>> - somone wants somthing like gnome, and are encouraged to run linux.
>> 
>> - somone wants "the community" to port smthing like gnome and noone is
>>  interested so they get bored and go away.
>> 
>> - somone wants to write some code to solve a problem they have with plan9
>>  and the just get on with it and tell the list when its done.
>> 
>> An example:
>> 
>> I need SVN support at work, cinap has wrapped up his linuxemu with the snv
>> client and the apropriate shared libraries (thanks cinap). This allows me to
>> continue using plan9 (as I do every day, all day).
>> 
>> In parallel I now have written a webdav client which I hope will become
>> a DeltaV/SVN client for plan9. I feel its worth writing as I think it is
>> interesting to try and fit the plan9 file model to SVN's version control model.
>> 
>> I wanted it, I got on with it and wrote it.
>> 
>>> I can't help but wonder: where's the crux of the inertia?
>> 
>> An interesting question. If you can garner enthusism from the list
>> perhaps you can be "the one" to spearhead a new burst of enthusism?
>> 
>> -Steve
>> 
>> 
> 
> 
> 
> -- 
> Hugo
> 

Re: [9fans] Plan ? (was: native install)

[hugo rivera]

I don't agree. I think that more than one person can be involved in
any given project.


2010/3/30 Gabriel Diaz Lopez de la Llave <gdiaz@rejaa.com>:
> hello
>
> This way (dot-it-your-self-way) we will "only" have one-man projects. . .
>
> slds.
>
> gabi
>




--
Hugo

Re: [9fans] Plan ? (was: native install)

[Francisco J Ballesteros]

Ok, but please, put the limit in two man per project, three at most.


On Tue, Mar 30, 2010 at 12:40 PM, hugo rivera <uair00@gmail.com> wrote:
> I don't agree. I think that more than one person can be involved in
> any given project.
>
>
> 2010/3/30 Gabriel Diaz Lopez de la Llave <gdiaz@rejaa.com>:
>> hello
>>
>> This way (dot-it-your-self-way) we will "only" have one-man projects. . .
>>
>> slds.
>>
>> gabi
>>
>
>
>
>
> --
> Hugo
>
>

Re: [9fans] Plan ? (was: native install)

[Patrick Kelly]

On Mar 30, 2010, at 6:33 AM, Gabriel Diaz Lopez de la Llave wrote:

> hello
>
> This way (dot-it-your-self-way) we will "only" have one-man  
> projects. . .

Do it yourself refers to the community doing anything they need. Most  
things are so trivial that one or two people can do it. That doesn't  
mean there has never been a multi person collaboration.

> slds.
>
> gabi
>
> El 30/03/2010, a las 12:19, hugo rivera escribió:
>
>> I agree with Steve.
>> I like the community approach to this matter: if plan9 doesn't have
>> what you need, do it yourself; if you do something that might be
>> useful for others share it and see what happens.
>> Being a newbie myself I find very hard to write my own utilities, but
>> that's a good way to learn ;-)
>>
>>
>> 2010/3/30 Steve Simon <steve@quintile.net>:
>>>> No one's willing to spearhead a "General Purpose 9" experiment,  
>>>> and no
>>>> one's interested in collaborating on and contributing to such a  
>>>> project?
>>>>
>>>> "If you want [general purpose], you know where to get it." seems to
>>>> be the period that ends all such discussion.
>>>
>>> I wouldn't quite agree, the discussions usually end one of three  
>>> ways:
>>>
>>> - somone wants somthing like gnome, and are encouraged to run linux.
>>>
>>> - somone wants "the community" to port smthing like gnome and  
>>> noone is
>>> interested so they get bored and go away.
>>>
>>> - somone wants to write some code to solve a problem they have  
>>> with plan9
>>> and the just get on with it and tell the list when its done.
>>>
>>> An example:
>>>
>>> I need SVN support at work, cinap has wrapped up his linuxemu with  
>>> the snv
>>> client and the apropriate shared libraries (thanks cinap). This  
>>> allows me to
>>> continue using plan9 (as I do every day, all day).
>>>
>>> In parallel I now have written a webdav client which I hope will  
>>> become
>>> a DeltaV/SVN client for plan9. I feel its worth writing as I think  
>>> it is
>>> interesting to try and fit the plan9 file model to SVN's version  
>>> control model.
>>>
>>> I wanted it, I got on with it and wrote it.
>>>
>>>> I can't help but wonder: where's the crux of the inertia?
>>>
>>> An interesting question. If you can garner enthusism from the list
>>> perhaps you can be "the one" to spearhead a new burst of enthusism?
>>>
>>> -Steve
>>>
>>>
>>
>>
>>
>> -- 
>> Hugo
>>
>
>

Re: [9fans] Plan ? (was: native install)

[Steve Simon]

> This way (dot-it-your-self-way) we will "only" have one-man projects. . .

True, if  anyone feels that a project is too big for them then
by all means put a shout out on the list and see if anyone there wants to help.

I only make the point (which has been made so many times before on this list)
that all that counts is code. Talking about writing code doesn't cut it,
if people want more code to exist then they need to write it.

I am not discounting discussing how things should be implemented, this is often
a great way to formulate ideas (even if its just how _not_ to do things), but
discussing why there isn't more software kinda misses the point doesn't it?

-Steve

Re: [9fans] Plan ? (was: native install)

[tlaronde]

On Tue, Mar 30, 2010 at 01:34:12PM +0100, Steve Simon wrote:
> > This way (dot-it-your-self-way) we will "only" have one-man projects. . .
>
> True, if  anyone feels that a project is too big for them then
> by all means put a shout out on the list and see if anyone there wants to help.

Everything can not always be done as a collaboration; and the main
possibilities are in parallele works. This implies a kind of
independance.

Indeed, when there are several people working on the "same" thing, it's
because the thing has been thought, is consistent (hence: thought
by very few people, with one leading), so that it's an organized
hierarchy of "one man" works.

Take the example of TeX, METAFONT (the conversion of WEB/Pascal to
something compilable on the majority of systems).

When I started looking at what was going on, trying to make sense of the
thing, it was not possible to be several doing this; and since I didn't
know at the beginning, I couldn't obviously explain.

Now I know. But it would take me all the time to explain to someone
else, hence we would not be 2 doing the work, but 1 explaining without
doing, and the other trying to do without having understood by doing...

And the "collaborative" effort shows in the web2c result: things that
are common between all the pieces written by D.E.K. are implemented with
slight divergences for TeX and METAFONT, with variations in names, in
parameters and so on, because some have worked on TeX, while others
worked on METAFONT etc. The main task now is cleaning and deleting and
having the strict minimum of code.

And you can compare. Donald Knuth has done the work, the majority: the
code. And a bunch of people have contributed chunks for the compilation
framework. On one side, you have code (result) and consistency; on the
other side, you have _inhumanity_ since you have increasing of the
entropy that is disorder: order is unnatural, and is the mark of human
activity. "Open source" seems very natural in this sense: the bazaar...
--
Thierry Laronde (Alceste) <tlaronde +AT+ polynum +dot+ com>
                 http://www.kergis.com/
Key fingerprint = 0FF7 E906 FBAF FE95 FD89  250D 52B1 AE95 6006 F40C

Re: [9fans] Plan ? (was: native install)

[Patrick Kelly]

> On one side, you have code (result) and consistency; on the
> other side, you have _inhumanity_ since you have increasing of the
> entropy that is disorder: order is unnatural, and is the mark of human
> activity. "Open source" seems very natural in this sense: the
> bazaar...

Until you factor in one little detail. It's all been engineered, yet
is still entropic. I guess it just goes to show that given a project
where 1 engineer would suffice, 20 won't make it any better. 20 people
may be able to make something faster, but it lacks that human quality,
order and care; it's like why grandma's cookies are so much better.

I'll take grandma's cookies over factory ones any day.

Re: [9fans] Plan ? (was: native install)

[Albert Skye]

> order is unnatural

The Origins of Order: Self-Organization and Selection in Evolution
by Stuart A. Kauffman

http://www.amazon.com/Origins-Order-Self-Organization-Selection-Evolution/dp/0195079515

Re: [9fans] Plan ? (was: native install)

[David Leimbach]

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

On Tue, Mar 30, 2010 at 10:07 AM, Albert Skye <mistlail@yahoo.co.uk> wrote:

> > order is unnatural
>
> The Origins of Order: Self-Organization and Selection in Evolution
> by Stuart A. Kauffman
>
>
> http://www.amazon.com/Origins-Order-Self-Organization-Selection-Evolution/dp/0195079515
>
>
Why have facts when speculation is more fun.

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

Re: [9fans] Plan ? (was: native install)

[tlaronde]

On Tue, Mar 30, 2010 at 10:07:11AM -0700, Albert Skye wrote:
> > order is unnatural
>
> The Origins of Order: Self-Organization and Selection in Evolution
> by Stuart A. Kauffman
>
> http://www.amazon.com/Origins-Order-Self-Organization-Selection-Evolution/dp/0195079515

order is unnatural for things lacking a conscience or a soul (in french,
non animated; I don't know if the sense is correct in english). Entropy.

For human societies, the less organized they are, the less human
they are---the ones with the less conscience are the ones who kill, who
steal, who stock exchange and so on. Do you want to live in Somalia,
in the City, etc.?

When it is forbidden to forbid, egoism rules, hence non-egoists die.

Without a conscience, you don't know that you are and can be a part of
the whole; a part of an organized whole. Nobody knows everything
by his own genius, but because there are things he inherited from the
previous ones; and he can go farther, by taking over (the relay). Not by
sitting on the bleachers with two pounds of pop-corn.

In software, when there is no more someone who understands the whole and
is able to keep the whole as an entity, pieces start being taken apart,
because savages want to put a graffiti on the building; the same way a
dog urinate on things that emerge to tell: "it's mine".

Back to software: how many developers are we _really_ relying upon the
work? For myself, if I count the original ones (Unix/C, Plan9, TeX and
al., CERL GRASS [ancestor of KerGIS]), this is less than 20... for something
like a bit more than half a century of "computer science"... And for each
piece of software I really use, there were a maximum of 3 core people
involved, with one leading.

And to "maintain" this, some claim there are "communities" with
hundreds, if not thousands of "developers"---when for the huge majority,
it will be enough to call them programmers.

And there is even "software creationism": the thing exists, not when
there is working code, but as soon as you have written that it will be
delivered under the holy licence.

I'm getting old...
--
Thierry Laronde (Alceste) <tlaronde +AT+ polynum +dot+ com>
                 http://www.kergis.com/
Key fingerprint = 0FF7 E906 FBAF FE95 FD89  250D 52B1 AE95 6006 F40C

Re: [9fans] Plan ? (was: native install)

[Nick LaForge]

I am utterly depressed that this pedestrian crap can so easily get a
rise out of several 9fans after all these times.

Re: [9fans] Plan ? (was: native install)

[Jack Johnson]

On Mon, Mar 29, 2010 at 6:17 PM, Patrick Kelly <kameo76890@gmail.com> wrote:
> Read up on why Plan 9 was written. We've been succeeding for 20 years so
> far.

I think this is an interesting comment in light of the evolution
thread.  Most people (incorrectly) equate evolution with progress.
Whether or not other more popular OSes are evidence of progress, it's
interesting to consider the idea of success.  The millipede has been
around with relatively few upgrades for the past 420 billion years or
so.  It would be hard to call it unsuccessful, even though it can't
(yet?) effectively run, jump, or fly.

-Jack

Re: [9fans] Plan ? (was: native install)

[Jack Johnson]

On Tue, Mar 30, 2010 at 10:23 AM, Jack Johnson <knapjack@gmail.com> wrote:
> On Mon, Mar 29, 2010 at 6:17 PM, Patrick Kelly <kameo76890@gmail.com> wrote:
> around with relatively few upgrades for the past 420 billion years or

s/billion/million/

-Jack

Re: [9fans] Plan ? (was: native install)

[Patrick Kelly]

On Mar 30, 2010, at 14:23, Jack Johnson <knapjack@gmail.com> wrote:

> On Mon, Mar 29, 2010 at 6:17 PM, Patrick Kelly
> <kameo76890@gmail.com> wrote:
>> Read up on why Plan 9 was written. We've been succeeding for 20
>> years so
>> far.
>
> I think this is an interesting comment in light of the evolution
> thread.  Most people (incorrectly) equate evolution with progress.
> Whether or not other more popular OSes are evidence of progress, it's
> interesting to consider the idea of success.  The millipede has been
> around with relatively few upgrades for the past 420 billion years or
> so.  It would be hard to call it unsuccessful, even though it can't
> (yet?) effectively run, jump, or fly.

I think the millipede can run, may be that's just the centipede. Both
are rediculously well adapted, yet haven't really advanced.

This analogy is worth of a beer. +1

> -Jack
>

Re: [9fans] Plan ?

[William Cowan]

Patrick Kelly <kameo76890@gmail.com> wrote:

> On Mar 30, 2010, at 14:23, Jack Johnson <knapjack@gmail.com> wrote:

>> On Mon, Mar 29, 2010 at 6:17 PM, Patrick Kelly
>> <kameo76890@gmail.com> wrote:
>>> Read up on why Plan 9 was written. We've been succeeding for 20
>>> years so
>>> far.
>>
>> I think this is an interesting comment in light of the evolution
>> thread.  Most people (incorrectly) equate evolution with progress.
>> Whether or not other more popular OSes are evidence of progress, it's
>> interesting to consider the idea of success.  The millipede has been
>> around with relatively few upgrades for the past 420 billion years or
>> so.  It would be hard to call it unsuccessful, even though it can't
>> (yet?) effectively run, jump, or fly.

> I think the millipede can run, may be that's just the centipede. Both
> are rediculously well adapted, yet haven't really advanced.

What it does is definitely effective, but it's not much like running, more like
swimming with a hundred or so lightly coordinated arms.

Bill

> This analogy is worth of a beer. +1

>> -Jack

[9fans] bootiso.s fixed

[cinap_lenrek]

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

found it!

the problem was the LBPB() to load byte 0 from the pvd for comparsion.
i loaded it into rBX instead of rBL.  found this out after dumping the
buffer and noticed that the contents where the same on t23 and amd
machine.

it all works now. tested on t23, bochs, and amd machine and its
blazing fast :)

updated the tarballs:

/n/sources/contrib/cinap_lenrek/tuttleboot.tgz
http://9hal.ath.cx/usr/cinap_lenrek/tuttleboot.tgz

attached the file and the diff to this mail...

--
cinap

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

#include "x16.h"
#include "mem.h"

/*
 * simple Plan 9 bootblock for ISO9660 that can load a uncompressed a.out kernel
 * image. looks for 386/9pcload. if heres no 386 it searches 9pcload in the root.
 * this is a non floppy emulation el torito bootblock!
 *
 * Diagnostics are:
 *	♥	alive!
 *	?	i/o error, will retry
 *	!	i/o error, giving up
 *	F	bad a.out magic
 *	S	could not find the file
 *
 */

#define DATA32SEL	SELECTOR(1, SELGDT, 0)
#define EXEC32SEL	SELECTOR(2, SELGDT, 0)
#define EXEC16SEL	SELECTOR(3, SELGDT, 0)

#define FARRET \
	BYTE $0xCB
#define SWAPB(r) \
	BYTE $0x0F; BYTE $(0xC8|r)
#define XORAL(i) \
	BYTE $0x34; BYTE $i

/* 2048 byte sectors */
#define SECTSHIFT	0x0B
#define BY2SECT	(1<<SECTSHIFT)

/*
 * Data is kept on the stack, indexed by rBP.
 */
#define Xdap		0x00	/* disc address packet */
#define Xdrive		0x12	/* boot drive, passed by BIOS or MBR */
#define Xentry		0x14	/* a.out entry, text, data*/
#define Xtextsz		0x18
#define Xdatasz	0x1c
#define Xload		0x20	/* load pointer */
#define Xcount		0x24	/* # of sectors to load */
#define Xbuf		0x28
#define Xtotal		(Xbuf+BY2SECT)

/* a.out header offsets */
#define Amagic	0x00
#define Atextsz	0x04
#define Adatasz	0x08
#define Aentry		0x14
#define Aouthdr	0x20

TEXT magic(SB), $0
	/* jmp .+ 0x3E  (_start0x40); nop; nop; nop; nop; nop; nop */
	BYTE $0xEB; BYTE $0x3E; BYTE $0x90; BYTE $0x90
	BYTE $0x90; BYTE $0x90; BYTE $0x90; BYTE $0x90

TEXT bipvd(SB), $0
	LONG $0x00000000
TEXT bibootfile(SB), $0
	LONG $0x00000000
TEXT bibootfilelen(SB), $0
	LONG $0x00000000
TEXT bichecksum(SB), $0
	LONG $0x00000000
TEXT bireserved(SB), $0
	LONG $0x00000000
	LONG $0x00000000
	LONG $0x00000000
	LONG $0x00000000
	LONG $0x00000000
	LONG $0x00000000
	LONG $0x00000000
	LONG $0x00000000
	LONG $0x00000000
	LONG $0x00000000

_start0x40:
	CLI

	/* be carefull! do not trash rDL until we reached start() */
	LWI(magic-Xtotal(SB), rSP)
	MW(rSP, rBP)
	LWI(start(SB), rAX)

_farret16:
	CLR(rCX)
	MTSR(rCX, rDS)
	MTSR(rCX, rES)
	MTSR(rCX, rSS)
	PUSHR(rCX)
	PUSHR(rAX)
	FARRET

TEXT return16(SB), $0
	MFCR(rCR0, rAX)
	XORAL(1)
	MTCR(rAX, rCR0)
	LWI(return16ret(SB), rAX)
	JMP _farret16

TEXT return16ret(SB), $0
	STI
	RET

TEXT start(SB), $0
	STI

	SBPB(rDL, Xdrive)

	/* alive! */
	LWI(0x0E03, rAX)
	BIOSCALL(0x10)

	/* A20! we has to enable itt! */
	LWI(0x2401, rAX)
	BIOSCALL(0x15)

	/* find the primary volume descriptor */
	CLR(rDX)
	LWI(0x0010, rAX)

	LWI(0xFF, rCX)
	CLR(rBX)
_nextpvd:
	CALL16(BIOSread(SB))
	LBPB(Xbuf, rBL)
	CMPI(1, rBX)
	JEQ _pvdfound
	CLR(rBX)
	ADDI(1, rAX)
	ADC(rBX, rDX)
	LOOP _nextpvd

	CALL16(srcherror(SB))

_pvdfound:
	/* load lba and length of root directory */
	LBPW((Xbuf+156+2), rAX)
	LBPW((Xbuf+156+4), rDX)
	LBPW((Xbuf+156+10), rCX)
	LBPW((Xbuf+156+12), rBX)

	CALL16(walk(SB))
	CALL16(srcherror(SB))

TEXT load(SB), $0
	CLR(rCX)
	SBPWI(0xFFFF, Xcount+0)
	SBPWI(0xFFFF, Xcount+2)
	CALL16(BIOSread(SB))

_loop:
	PUSHA
	CALL16(BIOSread(SB))
	CALL16(movehigh(SB))
	POPA
	ADDI(1, rAX)
	ADC(rCX, rDX)
	JMP _loop

TEXT BIOSread(SB), $0

	LWI(5, rDI)			/* retry count (ATAPI ZIPs suck) */

_retry:
	PUSHA
	PUSHS(rDS)
	PUSHS(rES)
	PUSHS(rFS)
	PUSHS(rGS)

	SBPW(rAX, Xdap+8)
	SBPW(rDX, Xdap+10)
	SBPWI(0x0010, Xdap+0)	/* reserved + packet size */
	SBPWI(0x0001, Xdap+2)	/* # of blocks to transfer */
	MW(rBP, rSI)
	ADDI(Xbuf, rSI)
	SBPW(rSI, Xdap+4)		/* transfer buffer :offset */
	MFSR(rSS, rSI)			/* transfer buffer seg: */
	SBPW(rSI, Xdap+6)

	MW(rBP, rSI)			/* Xdap == BP */
	LBPB(Xdrive, rDL)
	LWI(0x4200, rAX)

	BIOSCALL(0x13)
	JCC _readok

_reset:
	LWI((0x0E00+'?'), rAX)
	BIOSCALL(0x10)

	/* reset the drive */
	LBPB(Xdrive, rDL)
	CLR(rAX)
	BIOSCALL(0x13)

	POPS(rGS)
	POPS(rFS)
	POPS(rES)
	POPS(rDS)
	POPA

	DEC(rDI)
	JNE _retry

TEXT ioerror(SB), $0
	LBI('!', rAL)
	JMP _error

TEXT fmterror(SB), $0
	LBI('F', rAL)
	JMP _error

TEXT srcherror(SB), $0
	LBI('S', rAL)
	JMP _error

_error:
	/* print error code */
	LBI(0x0E, rAH)
	BIOSCALL(0x10)

	/* wait for almost any key */
	CLR(rAX)
	BIOSCALL(0x16)

	/* reset */
	LWI(0x0472, rBX)		/* warm-start code address */
	LWI(0x1234, rAX)		/* warm-start code */
	POKEW				/* MOVW	AX, ES:[BX] */
	FARJUMP16(0xFFFF, 0x0000)

_readok:
	POPS(rGS)
	POPS(rFS)
	POPS(rES)
	POPS(rDS)
	POPA

	RET

TEXT walk(SB), $0
	PUSHR(rAX)
	PUSHR(rDX)
	PUSHR(rCX)
	PUSHR(rBX)

	CALL16(BIOSread(SB))
	MW(rBP, rBX)
	ADDI(Xbuf, rBX)
	MW(rBX, rDI)

TEXT walknext(SB), $0
	MW(rDI, rSI)

	MW(rSI, rAX)
	SUB(rBX, rAX)
	CMPI(BY2SECT, rAX)
	JGE _nextsector
	CLR(rCX)
	LXB(0, xSI, rCL)
	ORB(rCL, rCL)
	JEQ _nextsector
	ADD(rCX, rDI)

	PUSHI(walktest(SB))
	RET

_nextsector:
	POPR(rBX)
	POPR(rCX)
	POPR(rDX)
	POPR(rAX)

	OR(rCX, rCX)
	JNE _contwalk
	OR(rBX, rBX)
	JEQ _retwalk
	DEC(rBX)
_contwalk:
	SUBI(BY2SECT, rCX)

	CLR(rDI)
	ADDI(1, rAX)
	ADC(rDI, rDX)
	PUSHI(walk(SB))
_retwalk:
	RET

TEXT walktest(SB), $0
	PUSHA

	LXW(2, xSI, rAX)
	LXW(4, xSI, rDX)
	LXW(10, xSI, rCX)
	LXW(12, xSI, rBX)

	PUSHA
	CLR(rCX)
	LXB(25, xSI, rCL)
	ANDI(2, rCX)
	POPA
	JEQ _notdir

	PUSHA
	LWI(dirname(SB), rDX)
	CALL16(cmpiname(SB))
	POPA
	JNE _skipdir

	ADDI((2*12), rSP)
	PUSHI(walk(SB))
	RET

_notdir:
	PUSHA
	LWI(filename(SB), rDX)
	CALL16(cmpiname(SB))
	POPA
	JNE _skipdir

	CALL16(load(SB))
	/* no return */

_skipdir:
	POPA
	PUSHI(walknext(SB))
	RET

TEXT cmpiname(SB), $0
	CLR(rBX)
	CLR(rAX)

	CLR(rCX)
	LXB(32, xSI, rCL)
	ADDI(33, rSI)
	MW(rDX, rDI)

	PUSHR(rDI)
	PUSHR(rCX)
_lenloop:
	LXB(0, xDI, rAL)
	OR(rAX, rAX)
	JEQ _endlen
	DEC(rCX)
	INC(rDI)
	JMP _lenloop
_endlen:
	OR(rCX, rCX)
	POPR(rCX)
	POPR(rDI)
	JNE _ret

_cmploop:
	LXB(0, xSI, rAL)
	LXB(0, xDI, rBL)
	CMPI('a', rAX)
	JLT _nocasea
	CMPI('z', rAX)
	JGT _nocasea
	ADDI(('A' - 'a'), rAX)
_nocasea:
	CMPI('a', rBX)
	JLT _nocaseb
	CMPI('z', rBX)
	JGT _nocaseb
	ADDI(('A' - 'a'), rBX)
_nocaseb:
	CMP(rAX, rBX)
	JNE _ret
	INC(rSI)
	INC(rDI)
	LOOP _cmploop
	OR(rCX, rCX)
_ret:
	RET

TEXT movehigh(SB), $0
	CLI
	LGDT(tgdtptr(SB))

	MFCR(rCR0, rAX)
	XORAL(1)
	MTCR(rAX, rCR0)

	FARJUMP32(EXEC32SEL, movehigh32(SB))

TEXT movehigh32(SB), $0
	/* upper bits seem to be fucked */
	ANDL $0xFFFF, BP
	ANDL $0xFFFF, SP

	MOVL $DATA32SEL, AX
	MOVW AX, DS
	MOVW AX, ES
	MOVW AX, SS

	MOVL Xload(BP), DI
	MOVL Xcount(BP), BX

	MOVL BP, SI
	ADDL $Xbuf, SI

	CMPL BX, $0
	JEQ _boot
	JGT _movedata

	MOVL Amagic(SI), AX
	CMPL AX, $0xeb010000
	JNE _fmterror

	MOVL Aentry(SI), DI
	SWAPB(rDI)
	ANDL $~0xF0000000, DI
	MOVL DI, Xentry(BP)
	SUBL $Aouthdr, DI

	MOVL Atextsz(SI), BX
	SWAPB(rBX)
	MOVL BX, Xtextsz(BP)

	MOVL Adatasz(SI), CX
	SWAPB(rCX)
	MOVL CX, Xdatasz(BP)

	ADDL CX, BX
	ADDL $(BY2SECT-1), BX
	SHRL $SECTSHIFT, BX

_movedata:
	MOVL $BY2SECT, CX
	REP; MOVSB
	DECL BX

	MOVL DI, Xload(BP)
	MOVL BX, Xcount(BP)

_return:
	/* Move back to 16 bit code segment from protected mode */
	BYTE $0xEA; LONG $return16(SB); WORD $EXEC16SEL

_fmterror:
	/* patch the 16 bit caller pc to point to the error function */
	MOVL $fmterror(SB), AX
	MOVW AX, 0(SP)
	JMP _return

_boot:
	/*
	 * we have to move the data segment to a page aligned
	 * address.
	 */
	MOVL Xentry(BP), SI
	MOVL SI, AX
	ADDL Xtextsz(BP), SI
	MOVL SI, DI
	ADDL $(BY2PG-1), DI
	ANDL $(~(BY2PG-1)), DI
	MOVL Xdatasz(BP), CX
	DECL CX
	ADDL CX, SI
	ADDL CX, DI
	INCL CX
	STD
	REP; MOVSB
	JMP *AX

TEXT	tgdt(SB),$0
         /* null descriptor */
         LONG     $0
         LONG     $0

         /* data segment descriptor for 4 gigabytes (PL 0) */
         LONG     $(0xFFFF)
         LONG     $(SEGG|SEGB|(0xF<<16)|SEGP|SEGPL(0)|SEGDATA|SEGW)

         /* exec segment descriptor for 4 gigabytes (PL 0) */
         LONG     $(0xFFFF)
         LONG     $(SEGG|SEGD|(0xF<<16)|SEGP|SEGPL(0)|SEGEXEC|SEGR)

         /* exec segment descriptor for 4 gigabytes (PL 0) 16-bit */
         LONG     $(0xFFFF)
         LONG     $(SEGG|(0xF<<16)|SEGP|SEGPL(0)|SEGEXEC|SEGR)

TEXT	tgdtptr(SB),$0
         WORD     $(4*8)
         LONG     $tgdt(SB)

TEXT dirname(SB), $0
	BYTE $'3'; BYTE $'8'; BYTE $'6'; BYTE $'\z'

TEXT filename(SB), $0
	BYTE $'9'; BYTE $'p'; BYTE $'c'; BYTE $'l'
	BYTE $'o'; BYTE $'a'; BYTE $'d'; BYTE $'\z'

[-- Attachment #3: Type: text/plain, Size: 1880 bytes --]

/n/dump/2010/0407/usr/cinap_lenrek/code/tuttleboot/sys/src/boot/pc/bootiso.s:120,133 - bootiso.s:120,135
  	CLR(rDX)
  	LWI(0x0010, rAX)

- 	LWI(100, rCX)
+ 	LWI(0xFF, rCX)
+ 	CLR(rBX)
  _nextpvd:
  	CALL16(BIOSread(SB))
- 	LBPB(Xbuf, rBX)
+ 	LBPB(Xbuf, rBL)
  	CMPI(1, rBX)
  	JEQ _pvdfound
+ 	CLR(rBX)
  	ADDI(1, rAX)
- 	ADC(rCX, rDX)
+ 	ADC(rBX, rDX)
  	LOOP _nextpvd

  	CALL16(srcherror(SB))
/n/dump/2010/0407/usr/cinap_lenrek/code/tuttleboot/sys/src/boot/pc/bootiso.s:158,167 - bootiso.s:160,174
  	JMP _loop

  TEXT BIOSread(SB), $0
+
  	LWI(5, rDI)			/* retry count (ATAPI ZIPs suck) */

  _retry:
  	PUSHA
+ 	PUSHS(rDS)
+ 	PUSHS(rES)
+ 	PUSHS(rFS)
+ 	PUSHS(rGS)

  	SBPW(rAX, Xdap+8)
  	SBPW(rDX, Xdap+10)
/n/dump/2010/0407/usr/cinap_lenrek/code/tuttleboot/sys/src/boot/pc/bootiso.s:170,187 - bootiso.s:177,195
  	MW(rBP, rSI)
  	ADDI(Xbuf, rSI)
  	SBPW(rSI, Xdap+4)		/* transfer buffer :offset */
- 	MFSR(rES, rSI)			/* transfer buffer seg: */
+ 	MFSR(rSS, rSI)			/* transfer buffer seg: */
  	SBPW(rSI, Xdap+6)

  	MW(rBP, rSI)			/* Xdap == BP */
  	LBPB(Xdrive, rDL)
- 	LBI(0x42, rAH)
+ 	LWI(0x4200, rAX)
+
  	BIOSCALL(0x13)
- 	JCC _popret
+ 	JCC _readok

  _reset:
  	LWI((0x0E00+'?'), rAX)
- 	BIOSCALL(0x10)
+ 	BIOSCALL(0x10)

  	/* reset the drive */
  	LBPB(Xdrive, rDL)
/n/dump/2010/0407/usr/cinap_lenrek/code/tuttleboot/sys/src/boot/pc/bootiso.s:188,194 - bootiso.s:196,207
  	CLR(rAX)
  	BIOSCALL(0x13)

+ 	POPS(rGS)
+ 	POPS(rFS)
+ 	POPS(rES)
+ 	POPS(rDS)
  	POPA
+
  	DEC(rDI)
  	JNE _retry

/n/dump/2010/0407/usr/cinap_lenrek/code/tuttleboot/sys/src/boot/pc/bootiso.s:219,226 - bootiso.s:232,244
  	POKEW				/* MOVW	AX, ES:[BX] */
  	FARJUMP16(0xFFFF, 0x0000)

- _popret:
+ _readok:
+ 	POPS(rGS)
+ 	POPS(rFS)
+ 	POPS(rES)
+ 	POPS(rDS)
  	POPA
+
  	RET

  TEXT walk(SB), $0

Re: [9fans] bootiso.s fixed

[ron minnich]

nice. It's nice to see the spirit of assembly language hacking is not
being lost :-)

ron

Re: [9fans] bootiso.s fixed

[Iruata Souza]

i guess this email was for me. ;]

On Wed, Apr 7, 2010 at 7:52 PM,  <cinap_lenrek@gmx.de> wrote:
> found it!
>
> the problem was the LBPB() to load byte 0 from the pvd for comparsion.
> i loaded it into rBX instead of rBL.  found this out after dumping the
> buffer and noticed that the contents where the same on t23 and amd
> machine.
>
> it all works now. tested on t23, bochs, and amd machine and its
> blazing fast :)
>
> updated the tarballs:
>
> /n/sources/contrib/cinap_lenrek/tuttleboot.tgz
> http://9hal.ath.cx/usr/cinap_lenrek/tuttleboot.tgz
>
> attached the file and the diff to this mail...
>
> --
> cinap
>
> #include "x16.h"
> #include "mem.h"
>
> /*
>  * simple Plan 9 bootblock for ISO9660 that can load a uncompressed a.out kernel
>  * image. looks for 386/9pcload. if heres no 386 it searches 9pcload in the root.
>  * this is a non floppy emulation el torito bootblock!
>  *
>  * Diagnostics are:
>  *      ♥       alive!
>  *      ?       i/o error, will retry
>  *      !       i/o error, giving up
>  *      F       bad a.out magic
>  *      S       could not find the file
>  *
>  */
>
> #define DATA32SEL       SELECTOR(1, SELGDT, 0)
> #define EXEC32SEL       SELECTOR(2, SELGDT, 0)
> #define EXEC16SEL       SELECTOR(3, SELGDT, 0)
>
> #define FARRET \
>        BYTE $0xCB
> #define SWAPB(r) \
>        BYTE $0x0F; BYTE $(0xC8|r)
> #define XORAL(i) \
>        BYTE $0x34; BYTE $i
>
> /* 2048 byte sectors */
> #define SECTSHIFT       0x0B
> #define BY2SECT (1<<SECTSHIFT)
>
> /*
>  * Data is kept on the stack, indexed by rBP.
>  */
> #define Xdap            0x00    /* disc address packet */
> #define Xdrive          0x12    /* boot drive, passed by BIOS or MBR */
> #define Xentry          0x14    /* a.out entry, text, data*/
> #define Xtextsz         0x18
> #define Xdatasz 0x1c
> #define Xload           0x20    /* load pointer */
> #define Xcount          0x24    /* # of sectors to load */
> #define Xbuf            0x28
> #define Xtotal          (Xbuf+BY2SECT)
>
> /* a.out header offsets */
> #define Amagic  0x00
> #define Atextsz 0x04
> #define Adatasz 0x08
> #define Aentry          0x14
> #define Aouthdr 0x20
>
> TEXT magic(SB), $0
>        /* jmp .+ 0x3E  (_start0x40); nop; nop; nop; nop; nop; nop */
>        BYTE $0xEB; BYTE $0x3E; BYTE $0x90; BYTE $0x90
>        BYTE $0x90; BYTE $0x90; BYTE $0x90; BYTE $0x90
>
> TEXT bipvd(SB), $0
>        LONG $0x00000000
> TEXT bibootfile(SB), $0
>        LONG $0x00000000
> TEXT bibootfilelen(SB), $0
>        LONG $0x00000000
> TEXT bichecksum(SB), $0
>        LONG $0x00000000
> TEXT bireserved(SB), $0
>        LONG $0x00000000
>        LONG $0x00000000
>        LONG $0x00000000
>        LONG $0x00000000
>        LONG $0x00000000
>        LONG $0x00000000
>        LONG $0x00000000
>        LONG $0x00000000
>        LONG $0x00000000
>        LONG $0x00000000
>
> _start0x40:
>        CLI
>
>        /* be carefull! do not trash rDL until we reached start() */
>        LWI(magic-Xtotal(SB), rSP)
>        MW(rSP, rBP)
>        LWI(start(SB), rAX)
>
> _farret16:
>        CLR(rCX)
>        MTSR(rCX, rDS)
>        MTSR(rCX, rES)
>        MTSR(rCX, rSS)
>        PUSHR(rCX)
>        PUSHR(rAX)
>        FARRET
>
> TEXT return16(SB), $0
>        MFCR(rCR0, rAX)
>        XORAL(1)
>        MTCR(rAX, rCR0)
>        LWI(return16ret(SB), rAX)
>        JMP _farret16
>
> TEXT return16ret(SB), $0
>        STI
>        RET
>
> TEXT start(SB), $0
>        STI
>
>        SBPB(rDL, Xdrive)
>
>        /* alive! */
>        LWI(0x0E03, rAX)
>        BIOSCALL(0x10)
>
>        /* A20! we has to enable itt! */
>        LWI(0x2401, rAX)
>        BIOSCALL(0x15)
>
>        /* find the primary volume descriptor */
>        CLR(rDX)
>        LWI(0x0010, rAX)
>
>        LWI(0xFF, rCX)
>        CLR(rBX)
> _nextpvd:
>        CALL16(BIOSread(SB))
>        LBPB(Xbuf, rBL)
>        CMPI(1, rBX)
>        JEQ _pvdfound
>        CLR(rBX)
>        ADDI(1, rAX)
>        ADC(rBX, rDX)
>        LOOP _nextpvd
>
>        CALL16(srcherror(SB))
>
> _pvdfound:
>        /* load lba and length of root directory */
>        LBPW((Xbuf+156+2), rAX)
>        LBPW((Xbuf+156+4), rDX)
>        LBPW((Xbuf+156+10), rCX)
>        LBPW((Xbuf+156+12), rBX)
>
>        CALL16(walk(SB))
>        CALL16(srcherror(SB))
>
> TEXT load(SB), $0
>        CLR(rCX)
>        SBPWI(0xFFFF, Xcount+0)
>        SBPWI(0xFFFF, Xcount+2)
>        CALL16(BIOSread(SB))
>
> _loop:
>        PUSHA
>        CALL16(BIOSread(SB))
>        CALL16(movehigh(SB))
>        POPA
>        ADDI(1, rAX)
>        ADC(rCX, rDX)
>        JMP _loop
>
> TEXT BIOSread(SB), $0
>
>        LWI(5, rDI)                     /* retry count (ATAPI ZIPs suck) */
>
> _retry:
>        PUSHA
>        PUSHS(rDS)
>        PUSHS(rES)
>        PUSHS(rFS)
>        PUSHS(rGS)
>
>        SBPW(rAX, Xdap+8)
>        SBPW(rDX, Xdap+10)
>        SBPWI(0x0010, Xdap+0)   /* reserved + packet size */
>        SBPWI(0x0001, Xdap+2)   /* # of blocks to transfer */
>        MW(rBP, rSI)
>        ADDI(Xbuf, rSI)
>        SBPW(rSI, Xdap+4)               /* transfer buffer :offset */
>        MFSR(rSS, rSI)                  /* transfer buffer seg: */
>        SBPW(rSI, Xdap+6)
>
>        MW(rBP, rSI)                    /* Xdap == BP */
>        LBPB(Xdrive, rDL)
>        LWI(0x4200, rAX)
>
>        BIOSCALL(0x13)
>        JCC _readok
>
> _reset:
>        LWI((0x0E00+'?'), rAX)
>        BIOSCALL(0x10)
>
>        /* reset the drive */
>        LBPB(Xdrive, rDL)
>        CLR(rAX)
>        BIOSCALL(0x13)
>
>        POPS(rGS)
>        POPS(rFS)
>        POPS(rES)
>        POPS(rDS)
>        POPA
>
>        DEC(rDI)
>        JNE _retry
>
> TEXT ioerror(SB), $0
>        LBI('!', rAL)
>        JMP _error
>
> TEXT fmterror(SB), $0
>        LBI('F', rAL)
>        JMP _error
>
> TEXT srcherror(SB), $0
>        LBI('S', rAL)
>        JMP _error
>
> _error:
>        /* print error code */
>        LBI(0x0E, rAH)
>        BIOSCALL(0x10)
>
>        /* wait for almost any key */
>        CLR(rAX)
>        BIOSCALL(0x16)
>
>        /* reset */
>        LWI(0x0472, rBX)                /* warm-start code address */
>        LWI(0x1234, rAX)                /* warm-start code */
>        POKEW                           /* MOVW AX, ES:[BX] */
>        FARJUMP16(0xFFFF, 0x0000)
>
> _readok:
>        POPS(rGS)
>        POPS(rFS)
>        POPS(rES)
>        POPS(rDS)
>        POPA
>
>        RET
>
> TEXT walk(SB), $0
>        PUSHR(rAX)
>        PUSHR(rDX)
>        PUSHR(rCX)
>        PUSHR(rBX)
>
>        CALL16(BIOSread(SB))
>        MW(rBP, rBX)
>        ADDI(Xbuf, rBX)
>        MW(rBX, rDI)
>
> TEXT walknext(SB), $0
>        MW(rDI, rSI)
>
>        MW(rSI, rAX)
>        SUB(rBX, rAX)
>        CMPI(BY2SECT, rAX)
>        JGE _nextsector
>        CLR(rCX)
>        LXB(0, xSI, rCL)
>        ORB(rCL, rCL)
>        JEQ _nextsector
>        ADD(rCX, rDI)
>
>        PUSHI(walktest(SB))
>        RET
>
> _nextsector:
>        POPR(rBX)
>        POPR(rCX)
>        POPR(rDX)
>        POPR(rAX)
>
>        OR(rCX, rCX)
>        JNE _contwalk
>        OR(rBX, rBX)
>        JEQ _retwalk
>        DEC(rBX)
> _contwalk:
>        SUBI(BY2SECT, rCX)
>
>        CLR(rDI)
>        ADDI(1, rAX)
>        ADC(rDI, rDX)
>        PUSHI(walk(SB))
> _retwalk:
>        RET
>
> TEXT walktest(SB), $0
>        PUSHA
>
>        LXW(2, xSI, rAX)
>        LXW(4, xSI, rDX)
>        LXW(10, xSI, rCX)
>        LXW(12, xSI, rBX)
>
>        PUSHA
>        CLR(rCX)
>        LXB(25, xSI, rCL)
>        ANDI(2, rCX)
>        POPA
>        JEQ _notdir
>
>        PUSHA
>        LWI(dirname(SB), rDX)
>        CALL16(cmpiname(SB))
>        POPA
>        JNE _skipdir
>
>        ADDI((2*12), rSP)
>        PUSHI(walk(SB))
>        RET
>
> _notdir:
>        PUSHA
>        LWI(filename(SB), rDX)
>        CALL16(cmpiname(SB))
>        POPA
>        JNE _skipdir
>
>        CALL16(load(SB))
>        /* no return */
>
> _skipdir:
>        POPA
>        PUSHI(walknext(SB))
>        RET
>
> TEXT cmpiname(SB), $0
>        CLR(rBX)
>        CLR(rAX)
>
>        CLR(rCX)
>        LXB(32, xSI, rCL)
>        ADDI(33, rSI)
>        MW(rDX, rDI)
>
>        PUSHR(rDI)
>        PUSHR(rCX)
> _lenloop:
>        LXB(0, xDI, rAL)
>        OR(rAX, rAX)
>        JEQ _endlen
>        DEC(rCX)
>        INC(rDI)
>        JMP _lenloop
> _endlen:
>        OR(rCX, rCX)
>        POPR(rCX)
>        POPR(rDI)
>        JNE _ret
>
> _cmploop:
>        LXB(0, xSI, rAL)
>        LXB(0, xDI, rBL)
>        CMPI('a', rAX)
>        JLT _nocasea
>        CMPI('z', rAX)
>        JGT _nocasea
>        ADDI(('A' - 'a'), rAX)
> _nocasea:
>        CMPI('a', rBX)
>        JLT _nocaseb
>        CMPI('z', rBX)
>        JGT _nocaseb
>        ADDI(('A' - 'a'), rBX)
> _nocaseb:
>        CMP(rAX, rBX)
>        JNE _ret
>        INC(rSI)
>        INC(rDI)
>        LOOP _cmploop
>        OR(rCX, rCX)
> _ret:
>        RET
>
> TEXT movehigh(SB), $0
>        CLI
>        LGDT(tgdtptr(SB))
>
>        MFCR(rCR0, rAX)
>        XORAL(1)
>        MTCR(rAX, rCR0)
>
>        FARJUMP32(EXEC32SEL, movehigh32(SB))
>
> TEXT movehigh32(SB), $0
>        /* upper bits seem to be fucked */
>        ANDL $0xFFFF, BP
>        ANDL $0xFFFF, SP
>
>        MOVL $DATA32SEL, AX
>        MOVW AX, DS
>        MOVW AX, ES
>        MOVW AX, SS
>
>        MOVL Xload(BP), DI
>        MOVL Xcount(BP), BX
>
>        MOVL BP, SI
>        ADDL $Xbuf, SI
>
>        CMPL BX, $0
>        JEQ _boot
>        JGT _movedata
>
>        MOVL Amagic(SI), AX
>        CMPL AX, $0xeb010000
>        JNE _fmterror
>
>        MOVL Aentry(SI), DI
>        SWAPB(rDI)
>        ANDL $~0xF0000000, DI
>        MOVL DI, Xentry(BP)
>        SUBL $Aouthdr, DI
>
>        MOVL Atextsz(SI), BX
>        SWAPB(rBX)
>        MOVL BX, Xtextsz(BP)
>
>        MOVL Adatasz(SI), CX
>        SWAPB(rCX)
>        MOVL CX, Xdatasz(BP)
>
>        ADDL CX, BX
>        ADDL $(BY2SECT-1), BX
>        SHRL $SECTSHIFT, BX
>
> _movedata:
>        MOVL $BY2SECT, CX
>        REP; MOVSB
>        DECL BX
>
>        MOVL DI, Xload(BP)
>        MOVL BX, Xcount(BP)
>
> _return:
>        /* Move back to 16 bit code segment from protected mode */
>        BYTE $0xEA; LONG $return16(SB); WORD $EXEC16SEL
>
> _fmterror:
>        /* patch the 16 bit caller pc to point to the error function */
>        MOVL $fmterror(SB), AX
>        MOVW AX, 0(SP)
>        JMP _return
>
> _boot:
>        /*
>         * we have to move the data segment to a page aligned
>         * address.
>         */
>        MOVL Xentry(BP), SI
>        MOVL SI, AX
>        ADDL Xtextsz(BP), SI
>        MOVL SI, DI
>        ADDL $(BY2PG-1), DI
>        ANDL $(~(BY2PG-1)), DI
>        MOVL Xdatasz(BP), CX
>        DECL CX
>        ADDL CX, SI
>        ADDL CX, DI
>        INCL CX
>        STD
>        REP; MOVSB
>        JMP *AX
>
> TEXT    tgdt(SB),$0
>         /* null descriptor */
>         LONG     $0
>         LONG     $0
>
>         /* data segment descriptor for 4 gigabytes (PL 0) */
>         LONG     $(0xFFFF)
>         LONG     $(SEGG|SEGB|(0xF<<16)|SEGP|SEGPL(0)|SEGDATA|SEGW)
>
>         /* exec segment descriptor for 4 gigabytes (PL 0) */
>         LONG     $(0xFFFF)
>         LONG     $(SEGG|SEGD|(0xF<<16)|SEGP|SEGPL(0)|SEGEXEC|SEGR)
>
>         /* exec segment descriptor for 4 gigabytes (PL 0) 16-bit */
>         LONG     $(0xFFFF)
>         LONG     $(SEGG|(0xF<<16)|SEGP|SEGPL(0)|SEGEXEC|SEGR)
>
> TEXT    tgdtptr(SB),$0
>         WORD     $(4*8)
>         LONG     $tgdt(SB)
>
> TEXT dirname(SB), $0
>        BYTE $'3'; BYTE $'8'; BYTE $'6'; BYTE $'\z'
>
> TEXT filename(SB), $0
>        BYTE $'9'; BYTE $'p'; BYTE $'c'; BYTE $'l'
>        BYTE $'o'; BYTE $'a'; BYTE $'d'; BYTE $'\z'
> /n/dump/2010/0407/usr/cinap_lenrek/code/tuttleboot/sys/src/boot/pc/bootiso.s:120,133 - bootiso.s:120,135
>        CLR(rDX)
>        LWI(0x0010, rAX)
>
> -       LWI(100, rCX)
> +       LWI(0xFF, rCX)
> +       CLR(rBX)
>  _nextpvd:
>        CALL16(BIOSread(SB))
> -       LBPB(Xbuf, rBX)
> +       LBPB(Xbuf, rBL)
>        CMPI(1, rBX)
>        JEQ _pvdfound
> +       CLR(rBX)
>        ADDI(1, rAX)
> -       ADC(rCX, rDX)
> +       ADC(rBX, rDX)
>        LOOP _nextpvd
>
>        CALL16(srcherror(SB))
> /n/dump/2010/0407/usr/cinap_lenrek/code/tuttleboot/sys/src/boot/pc/bootiso.s:158,167 - bootiso.s:160,174
>        JMP _loop
>
>  TEXT BIOSread(SB), $0
> +
>        LWI(5, rDI)                     /* retry count (ATAPI ZIPs suck) */
>
>  _retry:
>        PUSHA
> +       PUSHS(rDS)
> +       PUSHS(rES)
> +       PUSHS(rFS)
> +       PUSHS(rGS)
>
>        SBPW(rAX, Xdap+8)
>        SBPW(rDX, Xdap+10)
> /n/dump/2010/0407/usr/cinap_lenrek/code/tuttleboot/sys/src/boot/pc/bootiso.s:170,187 - bootiso.s:177,195
>        MW(rBP, rSI)
>        ADDI(Xbuf, rSI)
>        SBPW(rSI, Xdap+4)               /* transfer buffer :offset */
> -       MFSR(rES, rSI)                  /* transfer buffer seg: */
> +       MFSR(rSS, rSI)                  /* transfer buffer seg: */
>        SBPW(rSI, Xdap+6)
>
>        MW(rBP, rSI)                    /* Xdap == BP */
>        LBPB(Xdrive, rDL)
> -       LBI(0x42, rAH)
> +       LWI(0x4200, rAX)
> +
>        BIOSCALL(0x13)
> -       JCC _popret
> +       JCC _readok
>
>  _reset:
>        LWI((0x0E00+'?'), rAX)
> -       BIOSCALL(0x10)
> +       BIOSCALL(0x10)
>
>        /* reset the drive */
>        LBPB(Xdrive, rDL)
> /n/dump/2010/0407/usr/cinap_lenrek/code/tuttleboot/sys/src/boot/pc/bootiso.s:188,194 - bootiso.s:196,207
>        CLR(rAX)
>        BIOSCALL(0x13)
>
> +       POPS(rGS)
> +       POPS(rFS)
> +       POPS(rES)
> +       POPS(rDS)
>        POPA
> +
>        DEC(rDI)
>        JNE _retry
>
> /n/dump/2010/0407/usr/cinap_lenrek/code/tuttleboot/sys/src/boot/pc/bootiso.s:219,226 - bootiso.s:232,244
>        POKEW                           /* MOVW AX, ES:[BX] */
>        FARJUMP16(0xFFFF, 0x0000)
>
> - _popret:
> + _readok:
> +       POPS(rGS)
> +       POPS(rFS)
> +       POPS(rES)
> +       POPS(rDS)
>        POPA
> +
>        RET
>
>  TEXT walk(SB), $0
>

Re: [9fans] bootiso.s fixed

[erik quanstrom]

at what point do we cry uncle and write
an x86 16 bit loader/assembler?

- erik

Re: [9fans] bootiso.s fixed

[David Leimbach]

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

On Wed, Apr 7, 2010 at 5:08 PM, ron minnich <rminnich@gmail.com> wrote:

> nice. It's nice to see the spirit of assembly language hacking is not
> being lost :-)
>
> ron
>
>
I actually miss it a great deal.  I did more of that in college though than
I've ever had to do professionally, and the rust is surely there on my old
skills.

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

Re: [9fans] bootiso.s fixed

[David Leimbach]

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

On Thu, Apr 8, 2010 at 7:29 AM, erik quanstrom <quanstro@quanstro.net>wrote:

> at what point do we cry uncle and write
> an x86 16 bit loader/assembler?
>
> - erik
>
> I'd rather have an EFI loader working for Plan 9, but that's because i've
got all these macs laying around now...  (old 32bit iMac upstairs is just
dying for some Plan 9).

I wonder if it will boot with rEFIt though.

Dave

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

Re: [9fans] bootiso.s fixed

[ron minnich]

On Thu, Apr 8, 2010 at 2:29 PM, erik quanstrom <quanstro@quanstro.net> wrote:
> at what point do we cry uncle and write
> an x86 16 bit loader/assembler?

Never :-)

I still like the current approach because it works but at the same
time discourages people from using it :-)

ron

Re: [9fans] bootiso.s fixed

[erik quanstrom]

> Never :-)
>
> I still like the current approach because it works but at the same
> time discourages people from using it :-)

i'm sorry, but that's fairly silly.
should we also get rid of the
assembler because we want to
discourage its use?  and clearly
we have successfully minimized
the amount of asm while having
an assembler,.

the amount of 16 bit code that
currently exists would easily justify
the effort in writing a proper assembler.

and consider, interfacing with undi
and other annoying tasks would be a
heck of a lot easier with a proper 4a.

- erik

Re: [9fans] bootiso.s fixed

[Federico G. Benavento]

didn't russ write a 8086 assembler?

On Thu, Apr 8, 2010 at 3:17 PM, erik quanstrom <quanstro@quanstro.net> wrote:
>> Never :-)
>>
>> I still like the current approach because it works but at the same
>> time discourages people from using it :-)
>
> i'm sorry, but that's fairly silly.
> should we also get rid of the
> assembler because we want to
> discourage its use?  and clearly
> we have successfully minimized
> the amount of asm while having
> an assembler,.
>
> the amount of 16 bit code that
> currently exists would easily justify
> the effort in writing a proper assembler.
>
> and consider, interfacing with undi
> and other annoying tasks would be a
> heck of a lot easier with a proper 4a.
>
> - erik
>
>



-- 
Federico G. Benavento

Re: [9fans] bootiso.s fixed

[ron minnich]

If it matters that much just port nasm.

ron

Re: [9fans] bootiso.s fixed

[erik quanstrom]

On Thu Apr  8 15:06:21 EDT 2010, rminnich@gmail.com wrote:
> If it matters that much just port nasm.

why would you prefer to port something
with an alien syntax into the system?  also,
you'd need to link with regular .8s  so at
the end of the day, it would be easier to
write 4a than to port nasm.

- erik

Re: [9fans] bootiso.s fixed

[Jorden M]

On Thu, Apr 8, 2010 at 10:35 AM, David Leimbach <leimy2k@gmail.com> wrote:
> I wonder if it will boot with rEFIt though.
>

rEFIt is enough to fool all the other bootloaders.

Re: [9fans] bootiso.s fixed

[cinap_lenrek]

i'm really sorry for this mail fuckup.  that mail was intended to go
to muzgo.  was too lazy to remember his email address so i usually
just search for muzgo in acme mail and clicked on the first hit and
changed subject and mail body and then hitting reply without noticing
the wrong address.

with muzgos 9pcload kernel and a couple of few rc scripts 16 bit
assembler will be kept on a absolute minimum.  the biggest is pxe with
600 lines of assembly code but just because it switches the enviroment
back to its entry state for the pxe bios calls.

a real 16 bit assembler would have been nice and would have saved some
time as it often happens that your jumps get too far away and then
invalid opcodes are produced but you get used to it.  bochs really is
at great help here as it contains a debugger and disassembler.

anyway. not mutch to tell. muzgo will announce it when its done.

--
cinap

Re: [9fans] native install

[Tom West]

I'm going to be buying something soon. I'd like to follow your lead.

Thanks,

Tom West
On Mar 24, 2010, at 3:48 PM, Steve Simon wrote:

> I recently built a machine using a dualcore atom card from supermicro
> its quick, draws very little power and is rock solid.
>
> email me for the details if you like.
>
> -Steve
>
> (Thanks to erik for 9atom bits).
>

Re: [9fans] native install

[EBo]

Actually I would like to see this too.  Maybe if you could post the specs to
the list it would generally be helpful.

> I'm going to be buying something soon. I'd like to follow your lead.
> > I recently built a machine using a dualcore atom card from supermicro
> > its quick, draws very little power and is rock solid.
> >
> > email me for the details if you like.

Re: [9fans] native install

[erik quanstrom]

On Fri Apr  9 16:21:35 EDT 2010, ebo@sandien.com wrote:
> Actually I would like to see this too.  Maybe if you could post the specs to
> the list it would generally be helpful.

here's what i've recently tested with 9atom:

1: (atom 330)
	supermicro x7sla-h motherboard
	supermicro 502l-200b chassis
	2gb (2x1gb) memory

and 2: (pineview d510, my terminal)
	supermicro x7spa-h motherboard
	same chassis
	4gb (2x2gb sodimm)

i recently tested a
	supermicro x8sil-f motherboard
	xeon x3440 2.53ghz processor
	4gb (2x2) memory
	tested outside a chassis.

this is really a fast setup.  i was getting <3sec
kernel builds (even compiling the myricom driver).
i'm sure my slow fs was holding things back.

cavets:
1.  use 2gb dimms.  there are strange requirements
for multiple dimms per channel.

2.  use a recent 9atom, otherwise the board can't
find any pci devices.

- erik

Re: [9fans] native install

[Gabriel Diaz]

Hello erik,

Saturday, April 10, 2010, 4:26:09 AM, you wrote:

> On Fri Apr  9 16:21:35 EDT 2010, ebo@sandien.com wrote:
>> Actually I would like to see this too.  Maybe if you could post the specs to
>> the list it would generally be helpful.

> here's what i've recently tested with 9atom:

> 1: (atom 330)
>         supermicro x7sla-h motherboard
>         supermicro 502l-200b chassis
>         2gb (2x1gb) memory

> and 2: (pineview d510, my terminal)
>         supermicro x7spa-h motherboard
>         same chassis
>         4gb (2x2gb sodimm)

> i recently tested a
>         supermicro x8sil-f motherboard
>         xeon x3440 2.53ghz processor
>         4gb (2x2) memory
>         tested outside a chassis.

> this is really a fast setup.  i was getting <3sec
> kernel builds (even compiling the myricom driver).
> i'm sure my slow fs was holding things back.

> cavets:
> 1.  use 2gb dimms.  there are strange requirements
> for multiple dimms per channel.

> 2.  use a recent 9atom, otherwise the board can't
> find any pci devices.

> - erik


I  have  an  ASUS P6T SE with a Core i7 and 4gb of ram and it can boot
with 9atom.iso and install. But something is happening that prevent it
to   boot  after  the install (i got a register dump. may be something
wrong happened when doing the format of 9fat :?).  Network also works.
And Vesa works at 1280x900x8 with an ati hd 5750. Monitor is  samsung p2250.

I'll  report if i  get it booting, but i think it should boot if was able
to install and the live cd works, no?


--
Best regards,
 Gabriel                            mailto:gdiaz@rejaa.com

Re: [9fans] native install

[erik quanstrom]

> I  have  an  ASUS P6T SE with a Core i7 and 4gb of ram and it can boot
> with 9atom.iso and install. But something is happening that prevent it
> to   boot  after  the install (i got a register dump. may be something
> wrong happened when doing the format of 9fat :?).  Network also works.
> And Vesa works at 1280x900x8 with an ati hd 5750. Monitor is  samsung p2250.
>
> I'll  report if i  get it booting, but i think it should boot if was able
> to install and the live cd works, no?

yes, that does sound like some sort of screw up.

could you send
- pci/lspci output,
- a screenshot of the register dump, and
- a sha1sum of the kernel (so i know which kernel
you've got).

- erik

Re: [9fans] native install

[Gabriel Diaz]

Hello erik,

Saturday, April 10, 2010, 2:54:01 PM, you wrote:

>> I  have  an  ASUS P6T SE with a Core i7 and 4gb of ram and it can boot
>> with 9atom.iso and install. But something is happening that prevent it
>> to   boot  after  the install (i got a register dump. may be something
>> wrong happened when doing the format of 9fat :?).  Network also works.
>> And Vesa works at 1280x900x8 with an ati hd 5750. Monitor is  samsung p2250.
>> 
>> I'll  report if i  get it booting, but i think it should boot if was able
>> to install and the live cd works, no?

> yes, that does sound like some sort of screw up.

> could you send
> - pci/lspci output, 
> - a screenshot of the register dump, and
> - a sha1sum of the kernel (so i know which kernel
> you've got).

> - erik


This is the 9load panic (manually transcribed):

PBS2. . . Plan 9 From Bell Labs
no vga; serial console only
cpu0: 2675MHz i7 loop 142773
apm ax=f000 cx=f000 dx=40 di=100 ebx=ffff esi=0
found 11 e820 entries
flags=10a07 trap=e ecode=2 pc=0x800377ff
            ax 8002c391 bx 00000000 cx ffffffff dx 80047fac
            si 00000001 di 8004ad88 bp 80061c20
            cs 0010 ds 008 es 0008 fd 0008 gs 0008
            cr0 800000011 cr2 8942443 cr3 0000c000
panic: exception/interrupt 14
press almost any key. . .

I  installed  again  to  see  if i missed some odd behaviour the first
time,  but  seems  there  are  no  noticeable error messages. Also the
install  speed  is  fine,  there  is  no  huge load of interrupts when
installing and no missed interrupt messages.

The   interrupt   14  was  associated  with  sdC and sdD.

sdC0 is the sata dvd drive
sdD0 is the sata hard disk
sdE0 is the ide dvd drive from which i boot plan9, this is attached to
some jmicron thing which claims to be ide to sata bridge

When booting using the pccd.gz kernel, i get some missed irq messages,
also  a  disk/format  of  the  9fat  partition  takes  ages,  and when
completed,  the  9fat  partition is not readable.

sha1 hash of
     9pcflop.gz is D5F5E6F48DAA0D0FC604A1A9B27BD8B240673309
     9pccd.gz is 85FEE0ADC5FE00BEEF8F448D5F6AE416B1844A9D


I'll install a linux so i can send a lspci.

slds.


-- 
Best regards,
 Gabriel                            mailto:gdiaz@rejaa.com

Re: [9fans] native install

[erik quanstrom]

> This is the 9load panic (manually transcribed):
>
> PBS2. . . Plan 9 From Bell Labs
> no vga; serial console only
> cpu0: 2675MHz i7 loop 142773
> apm ax=f000 cx=f000 dx=40 di=100 ebx=ffff esi=0
> found 11 e820 entries
> flags=10a07 trap=e ecode=2 pc=0x800377ff
>             ax 8002c391 bx 00000000 cx ffffffff dx 80047fac
>             si 00000001 di 8004ad88 bp 80061c20
>             cs 0010 ds 008 es 0008 fd 0008 gs 0008
>             cr0 800000011 cr2 8942443 cr3 0000c000
> panic: exception/interrupt 14
> press almost any key. . .
>
> I  installed  again  to  see  if i missed some odd behaviour the first
> time,  but  seems  there  are  no  noticeable error messages. Also the
> install  speed  is  fine,  there  is  no  huge load of interrupts when
> installing and no missed interrupt messages.
>
> The   interrupt   14  was  associated  with  sdC and sdD.

is this a freshly download cd?  some changes were made
apr  3 that should fix this problem.  this line is the tipoff:

> no vga; serial console only

- erik

Re: [9fans] native install

[Gabriel Diaz Lopez de la Llave]

hello

I have it booting now. I did a disk/format using the 9load from the cdboot image, and the 9pcf kernel from the iso.

Now i'm getting messages about caught missed ide interrupts. . .and this slows down disk operations a lot,  i guess first fossil dump to venti  will take ages.

now i'm stuck at version...time line. . . .i'll try if enabling dma could solve anything, but not sure when i will be able to access the console. . .

can i enable dma from the plan9.ini?

thanks.

gabi


El 10/04/2010, a las 21:38, erik quanstrom escribió:

>> This is the 9load panic (manually transcribed):
>> 
>> PBS2. . . Plan 9 From Bell Labs
>> no vga; serial console only
>> cpu0: 2675MHz i7 loop 142773
>> apm ax=f000 cx=f000 dx=40 di=100 ebx=ffff esi=0
>> found 11 e820 entries
>> flags=10a07 trap=e ecode=2 pc=0x800377ff
>>            ax 8002c391 bx 00000000 cx ffffffff dx 80047fac
>>            si 00000001 di 8004ad88 bp 80061c20
>>            cs 0010 ds 008 es 0008 fd 0008 gs 0008
>>            cr0 800000011 cr2 8942443 cr3 0000c000
>> panic: exception/interrupt 14
>> press almost any key. . .
>> 
>> I  installed  again  to  see  if i missed some odd behaviour the first
>> time,  but  seems  there  are  no  noticeable error messages. Also the
>> install  speed  is  fine,  there  is  no  huge load of interrupts when
>> installing and no missed interrupt messages.
>> 
>> The   interrupt   14  was  associated  with  sdC and sdD.
> 
> is this a freshly download cd?  some changes were made
> apr  3 that should fix this problem.  this line is the tipoff:
> 
>> no vga; serial console only
> 
> - erik
> 

Re: [9fans] native install

[erik quanstrom]

> I have it booting now. I did a disk/format using the 9load from
> the cdboot image, and the 9pcf kernel from the iso.
> Now i'm getting messages about caught missed ide interrupts. . .
> and this slows down disk operations a lot,  i guess first fossil dump
> to venti  will take ages. now i'm stuck at version...time line. . . .i'll
> try if enabling dma could solve anything, but not sure when i will
> be able to access the console. . .
> can i enable dma from the plan9.ini?

sorry about the "missed ide interrupts" botch.  it seemed better
than not booting at all.

you can set "*sdXXdma=on" in your plan9.ini.  but i don't think
that's the real problem.

i'd guess that your southbridge isn't in the list of routable southbridges
and needs to be added.  but in addition, i would do the following

1.  remove the "*nomp=1" line from plan9.ini
2.  switch to ahci mode.  (assuming this is indeed a sata drive
that is connected to the ich sata ports and not some marvell
or sis addon chip.)
3.  send your pci output offline.

- erik

Re: [9fans] native install

[Gabriel Diaz Lopez de la Llave]

hello

Seems I fell again in the bios ahci set up trap. Checking the BIOS options seems it was in Enhaced Ide mode instead of Enhaced AHCI mode.

Now the iso works perfectly. For those of you looking for a "modern" PC to run plan9, this is what i have:

* asus P6T SE
* Core i7 (4 core works)
* 4GB DDR3 RAM
* ati hd5750 (works in vesa 1280x960x8)
* hard disk WD caviar 300 GB
* realtek GB network (works)

9atom from this weekend boots and install with no problems setting up AHCI mode first.

slds.

gabi

El 11/04/2010, a las 14:37, Gabriel Diaz Lopez de la Llave escribió:

> hello
> 
> I have it booting now. I did a disk/format using the 9load from the cdboot image, and the 9pcf kernel from the iso.
> 
> Now i'm getting messages about caught missed ide interrupts. . .and this slows down disk operations a lot,  i guess first fossil dump to venti  will take ages.
> 
> now i'm stuck at version...time line. . . .i'll try if enabling dma could solve anything, but not sure when i will be able to access the console. . .
> 
> can i enable dma from the plan9.ini?
> 
> thanks.
> 
> gabi
> 
> 
> El 10/04/2010, a las 21:38, erik quanstrom escribió:
> 
>>> This is the 9load panic (manually transcribed):
>>> 
>>> PBS2. . . Plan 9 From Bell Labs
>>> no vga; serial console only
>>> cpu0: 2675MHz i7 loop 142773
>>> apm ax=f000 cx=f000 dx=40 di=100 ebx=ffff esi=0
>>> found 11 e820 entries
>>> flags=10a07 trap=e ecode=2 pc=0x800377ff
>>>           ax 8002c391 bx 00000000 cx ffffffff dx 80047fac
>>>           si 00000001 di 8004ad88 bp 80061c20
>>>           cs 0010 ds 008 es 0008 fd 0008 gs 0008
>>>           cr0 800000011 cr2 8942443 cr3 0000c000
>>> panic: exception/interrupt 14
>>> press almost any key. . .
>>> 
>>> I  installed  again  to  see  if i missed some odd behaviour the first
>>> time,  but  seems  there  are  no  noticeable error messages. Also the
>>> install  speed  is  fine,  there  is  no  huge load of interrupts when
>>> installing and no missed interrupt messages.
>>> 
>>> The   interrupt   14  was  associated  with  sdC and sdD.
>> 
>> is this a freshly download cd?  some changes were made
>> apr  3 that should fix this problem.  this line is the tipoff:
>> 
>>> no vga; serial console only
>> 
>> - erik
>> 
> 
> 

Re: [9fans] native install

[erik quanstrom]

> 9atom from this weekend boots and install with no problems setting up AHCI mode first.
>

please send your pci output anyway.  ide should work.
even if *nomp=1 so to do that we'll need to do the pcirouting
stuff, and for that we need a southbridge pci vid/did.

- erik