[9fans] how about intel D510MO

[9fans] how about intel D510MO

[Alex]

Hi everyone, I've been playing plan9 in qemu for sometime now. the
only computer I have is a PS3/ubuntu9.04, and I'm thinking about buy a
low cost x86 board for plan9. Is intel D510MO a good choise?

Re: [9fans] how about intel D510MO

[John Barham]

On Thu, Apr 1, 2010 at 3:13 AM, Alex <zhaodu1@gmail.com> wrote:
> Hi everyone, I've been playing plan9 in qemu for sometime now. the
> only computer I have is a PS3/ubuntu9.04, and I'm thinking about buy a
> low cost x86 board for plan9. Is intel D510MO a good choise?

I can't comment on how this motherboard runs Plan 9 but I'm using it
as a headless Linux server to run venti and do Go programming.  I put
it into a mini-box.com M350 enclosure w/ their 80W picoPSU-80 power
supply (selling in a kit for $69).  Add some RAM and a hard drive and
you have a very compact, reasonably powerful system.  Since the board
is passively cooled w/ a heat sink and the PSU plugs right into the
board, the only noise comes from the HD.  Most sites rate the idle
power draw at ~20 watts.  Overall I'm very pleased w/ it.  I should
note though that the case does get warm above the heat sink.

However since the Atom doesn't support ECC RAM (for that matter
neither does the mighty Core i7) I'm somewhat cautious about trusting
it as an always on file server without additional checksums in
software.  Pretty much all AMD chips support ECC RAM, although of
course mobo/BIOS support is a different matter.

  John

Re: [9fans] how about intel D510MO

[erik quanstrom]

> However since the Atom doesn't support ECC RAM (for that matter
> neither does the mighty Core i7) I'm somewhat cautious about trusting
> it as an always on file server without additional checksums in
> software.  Pretty much all AMD chips support ECC RAM, although of
> course mobo/BIOS support is a different matter.

i think you're right.  ecc hardware is hard to live without.
i have not used ecc memory with amd hardware.  so i can't
comment on that.  but  if you want ecc with intel hardware,
you just need to get the xeon version of the processor:

socket 1156 core iX	xeon [elwx]3[45]xx
socket 1366 core i7	xeon [elwx][35][56]xx

you can get the xeon versions at a similar price
to the core iX versions, but usually the frequency
is a bit lower.

ecc motherboards can be competitive, too.  it
looks like newegg is selling the x8sil for $159.
it comes with two fairly nice i82574 nics.  i can
verify that this motherboard works correctly.

- erik

[9fans] 9vx patch to read environment var PLAN9

[EBo]

The following is a little patch to 9vx which uses getenv to read the
environmental variable PLAN9 to set "plan 9 root" on startup if it has not
been overloaded on the command line or in the CWD.  I would enjoy any feedback.

Best regards,

  EBo --

=====================================================================

diff -r 8184025094f4 src/9vx/main.c
--- a/src/9vx/main.c    Mon Oct 05 02:53:41 2009 -0400
+++ b/src/9vx/main.c    Sun Apr 11 11:59:03 2010 -0500
@@ -10,6 +10,8 @@

 #include       "u.h"
 #include       "libvx32/vx32.h"
+#include       <stdlib.h>
+#include       <string.h>
 #include       <sys/mman.h>
 #include       <signal.h>
 #include       <pwd.h>
@@ -224,12 +226,13 @@
 findroot(void)
 {
        static char cwd[1024];
+       static char plan9[1024];
        int i;
        char buf[1024];
        char *dir[] = {
                cwd,
-               "/Users/rsc/9vx",
-               "/home/rsc/plan9/4e"
+               plan9,
+               "/usr/local/plan9"
        };

        if(getcwd(cwd, sizeof cwd) == nil){
@@ -237,6 +240,9 @@
                panic("getcwd: %r");
        }

+       if(getenv("PLAN9") != nil)
+               strncpy(plan9, getenv("PLAN9"), sizeof plan9);
+
        for(i=0; i<nelem(dir); i++){
                snprint(buf, sizeof buf, "%s/386/bin/rc", dir[i]);
                if(access(buf, 0) >= 0)

Re: [9fans] 9vx patch to read environment var PLAN9

[erik quanstrom]

recommend using a different environment variable
other than PLAN9, since that is taken by p9p to mean
something else.

- erik

Re: [9fans] 9vx patch to read environment var PLAN9

[Devon H. O'Dell]

2010/4/11 erik quanstrom <quanstro@quanstro.net>:
> recommend using a different environment variable
> other than PLAN9, since that is taken by p9p to mean
> something else.

Agreed. PLAN9ROOT seems good.

--dho

> - erik
>
>

Re: [9fans] 9vx patch to read environment var PLAN9

[erik quanstrom]

> Agreed. PLAN9ROOT seems good.

suggest 9vxroot instead.  there are enough plan9y
things floating around that it makes sense to me
to specify which plan9y root you're talking about.

and there's no reason to shout.  :-)

- erik

Re: [9fans] 9vx patch to read environment var PLAN9

[EBo]

I thought p9p uses it for the root of the Plan 9 tree?  At least that is what
the ebuilds imply.  Maybe I am using the wrong term for what PLAN9 points to.

  EBo --


erik quanstrom <quanstro@quanstro.net> said:

> recommend using a different environment variable
> other than PLAN9, since that is taken by p9p to mean
> something else.
>
> - erik
>



--

Re: [9fans] 9vx patch to read environment var PLAN9

[Devon H. O'Dell]

2010/4/11 EBo <ebo@sandien.com>:
> I thought p9p uses it for the root of the Plan 9 tree?  At least that is what
> the ebuilds imply.  Maybe I am using the wrong term for what PLAN9 points to.

That's true, but in the case of 9vx, the tree it points to contains
actual plan 9 binaries, whereas p9p binaries are compiled for the host
system. Since it is very feasible that someone may run p9p and 9vx on
the same machine (I do, for instance), it would be a good idea to not
overload the env var.

--dho

>  EBo --
>
>
> erik quanstrom <quanstro@quanstro.net> said:
>
>> recommend using a different environment variable
>> other than PLAN9, since that is taken by p9p to mean
>> something else.
>>
>> - erik
>>
>
>
>
> --
>
>
>
>
>

Re: [9fans] 9vx patch to read environment var PLAN9

[EBo]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1078 bytes --]

Got it!  Changed.  I'll also change it along the lines of Erik's suggestion.

As a note, I thought that 9vx ran on top of the p9p stuff.

  Thanks again,

  EBo --


"Devon H. O'Dell" <devon.odell@gmail.com> said:

> 2010/4/11 EBo <ebo@sandien.com>:
> > I thought p9p uses it for the root of the Plan 9 tree? �At least that is what
> > the ebuilds imply. �Maybe I am using the wrong term for what PLAN9 points to.
>
> That's true, but in the case of 9vx, the tree it points to contains
> actual plan 9 binaries, whereas p9p binaries are compiled for the host
> system. Since it is very feasible that someone may run p9p and 9vx on
> the same machine (I do, for instance), it would be a good idea to not
> overload the env var.
>
> --dho
>
> > �EBo --
> >
> >
> > erik quanstrom <quanstro@quanstro.net> said:
> >
> >> recommend using a different environment variable
> >> other than PLAN9, since that is taken by p9p to mean
> >> something else.
> >>
> >> - erik
> >>
> >
> >
> >
> > --
> >
> >
> >
> >
> >
>



--

Re: [9fans] 9vx patch to read environment var PLAN9

[Devon H. O'Dell]

2010/4/11 erik quanstrom <quanstro@quanstro.net>:
>> Agreed. PLAN9ROOT seems good.
>
> suggest 9vxroot instead.  there are enough plan9y
> things floating around that it makes sense to me
> to specify which plan9y root you're talking about.

I was going to suggest that, but you can't start env. var. names with
numbers in many shells.

--dho

> and there's no reason to shout.  :-)
>
> - erik
>
>

Re: [9fans] 9vx patch to read environment var PLAN9

[erik quanstrom]

> I was going to suggest that, but you can't start env. var. names with
> numbers in many shells.

i'd forgotten about that.  unix really has gotten
crunchy.

- erik

Re: [9fans] 9vx patch to read environment var PLAN9

[EBo]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 211 bytes --]


> I was going to suggest that, but you can't start env. var. names with
> numbers in many shells.

That's why I named it vx9root (not to screem).  ;-)

> > and there's no reason to shout. �:-)

[9fans] /sys/lib/newuser patch

[EBo]

I'm playing around with 9vx and have split up (re)building 9vx from the the
9vx root file system provided in the tarball 9vx-0.12.tar.gz

When I first start 9vx from a clean build and run /sys/lib/newuser it builds
the user directory in /$user instead of /usr/$user.  The problem appears to
arize from the following:

========================
user=`{cat /dev/user}
home=/usr/$user
if(test -f $home/lib/profile){
	echo user directories already made
	exit no
}
cd $home
========================

When we try to cd to $home, it does not exist (as checked by the previous if),
and $cwd is set to / by default...  The following patch simply makes $home
before cd'ing to it.

Is this supposed to be the expected nehaviour?

  EBo --

=========================
--- a/sys/lib/newuser	2008-06-30 08:44:02.000000000 -0500
+++ b/sys/lib/newuser	2010-04-11 15:36:41.865384817 -0500
@@ -6,6 +6,7 @@
 	echo user directories already made
 	exit no
 }
+mkdir $home
 cd $home
 x='$'
 mkdir bin bin/rc bin/mips bin/386

Re: [9fans] /sys/lib/newuser patch

[erik quanstrom]

> When we try to cd to $home, it does not exist (as checked by the previous if),
> and $cwd is set to / by default...  The following patch simply makes $home
> before cd'ing to it.
>
> Is this supposed to be the expected nehaviour?
>
>   EBo --
>
> =========================
> --- a/sys/lib/newuser	2008-06-30 08:44:02.000000000 -0500
> +++ b/sys/lib/newuser	2010-04-11 15:36:41.865384817 -0500
> @@ -6,6 +6,7 @@
>  	echo user directories already made
>  	exit no
>  }
> +mkdir $home
>  cd $home
>  x='$'
>  mkdir bin bin/rc bin/mips bin/386

newuser assumes that your home directory exists, and on a
normal plan 9 install, it's likely not possible to create anything
in /usr without doing it on the fs console.

- erik

Re: [9fans] /sys/lib/newuser patch

[EBo]

> newuser assumes that your home directory exists, and on a
> normal plan 9 install, it's likely not possible to create anything
> in /usr without doing it on the fs console.

Maybe I am missing something here, but this is not a normal plan9 install, but
9vx.  There I can create a user's directory in $9vx_root/usr provided that the
permissions are open.

in the base system that came with 9vx I get an error that /src/fscons does not
exist when running "con -l /srv/fscons".

So, how is the initial setup supposed to be done on 9vx which defaults to a
$user instead of glenda

  EBo --

Re: [9fans] /sys/lib/newuser patch

[Iruata Souza]

On Sun, Apr 11, 2010 at 7:04 PM, EBo <ebo@sandien.com> wrote:
>
>> newuser assumes that your home directory exists, and on a
>> normal plan 9 install, it's likely not possible to create anything
>> in /usr without doing it on the fs console.
>
> Maybe I am missing something here, but this is not a normal plan9 install, but
> 9vx.  There I can create a user's directory in $9vx_root/usr provided that the
> permissions are open.
>
> in the base system that came with 9vx I get an error that /src/fscons does not
> exist when running "con -l /srv/fscons".
>
> So, how is the initial setup supposed to be done on 9vx which defaults to a
> $user instead of glenda
>

create the user dir on the host machine. run 9vx -u $user and then run
/sys/lib/newuser.

you seem to be following the wiki instructions on how to add a new
user. they are not valid for 9vx, since it usually uses the hosts
filesystem.

iru

Re: [9fans] /sys/lib/newuser patch

[Anthony Sorace]

On a "real" plan 9 system, you create the user at the file server
console, then log in as that user and run newuser. That first step
creates /usr/$user. The analogue in 9vx is at least 'mkdir /usr/
$user', and (less likely) possibly creating the actual user in the
unix world, depending on your intended setup.

Rather than see newuser create the dir if it doesn't exist, I'd rather
see it exit with an error in that case.

On Apr 11, 2010, at 18:04, "EBo" <ebo@sandien.com> wrote:

>
>> newuser assumes that your home directory exists, and on a
>> normal plan 9 install, it's likely not possible to create anything
>> in /usr without doing it on the fs console.
>
> Maybe I am missing something here, but this is not a normal plan9
> install, but
> 9vx.  There I can create a user's directory in $9vx_root/usr
> provided that the
> permissions are open.
>
> in the base system that came with 9vx I get an error that /src/
> fscons does not
> exist when running "con -l /srv/fscons".
>
> So, how is the initial setup supposed to be done on 9vx which
> defaults to a
> $user instead of glenda
>
>  EBo --

Re: [9fans] 9vx patch to read environment var PLAN9

[Russ Cox]

Why isn't 9vx -r yourdir good enough?

Russ

Re: [9fans] 9vx patch to read environment var PLAN9

[EBo]

> Why isn't 9vx -r yourdir good enough?

it is if you want to force all users to specify the root directory every
single time they run 9vx, or if you want to use an alternative root.  If I use
a standard install locations then we can either change "/Users/rsc/9vx" and
"/home/rsc/plan9/4e" or I can simply run a sed script during the build phase.
 Setting up a $root9vx (what I have changed it to) seemed the cleanest approach.

  EBo --

Re: [9fans] /sys/lib/newuser patch

[EBo]

Anthony Sorace <a@9srv.net> said:

> On a "real" plan 9 system, you create the user at the file server
> console, then log in as that user and run newuser. That first step
> creates /usr/$user. The analogue in 9vx is at least 'mkdir /usr/
> $user', and (less likely) possibly creating the actual user in the
> unix world, depending on your intended setup.
>
> Rather than see newuser create the dir if it doesn't exist, I'd rather
> see it exit with an error in that case.

and have the 9vx tutorial explain that the user needs to create the directory
by hand if the file serve console is not working.  OK, this works for me, and
concurs with what Erik was saying.

  EBo --

Re: [9fans] /sys/lib/newuser patch

[EBo]

> create the user dir on the host machine. run 9vx -u $user and then run
> /sys/lib/newuser.
>
> you seem to be following the wiki instructions on how to add a new
> user. they are not valid for 9vx, since it usually uses the hosts
> filesystem.

is there already a 9vx specific tutorial?

  EBo --

Re: [9fans] /sys/lib/newuser patch

[EBo]

Anthony Sorace <a@9srv.net> said:

> On a "real" plan 9 system, you create the user at the file server
> console, then log in as that user and run newuser. That first step
> creates /usr/$user. The analogue in 9vx is at least 'mkdir /usr/
> $user', and (less likely) possibly creating the actual user in the
> unix world, depending on your intended setup.
>
> Rather than see newuser create the dir if it doesn't exist, I'd rather
> see it exit with an error in that case.

Following on several peoples advice and a suggested code snippet from Erik
I've added the following before the check for profile:

if(! test -d $home){
	echo no home directory $home
	exit homeless
}
if(! ls -ld $home >[2=] | grep -s '^d-rwx.* '$user){
	echo bad permissions
	exit homeless
}

I could add the 'mkdir /usr/ $user' to newuser, but then as Erik points out it
would be a special case for 9vx and not work for native plan9.  This way it
works if the file server console was never run, so possibly a general solution.

  EBo --

Re: [9fans] 9vx patch to read environment var PLAN9

[Francisco J Ballesteros]

you could also use a script to call 9vx as you please.



On Mon, Apr 12, 2010 at 5:22 AM, EBo <ebo@sandien.com> wrote:
>
>> Why isn't 9vx -r yourdir good enough?
>
> it is if you want to force all users to specify the root directory every
> single time they run 9vx, or if you want to use an alternative root.  If I use
> a standard install locations then we can either change "/Users/rsc/9vx" and
> "/home/rsc/plan9/4e" or I can simply run a sed script during the build phase.
>  Setting up a $root9vx (what I have changed it to) seemed the cleanest approach.
>
>  EBo --
>
>
>
>

Re: [9fans] 9vx patch to read environment var PLAN9

[EBo]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1303 bytes --]

Francisco J Ballesteros <nemo@lsub.org> said:

> you could also use a script to call 9vx as you please.

That is what I did for the first prototype.  I thought this would be a beeter
solution.

Out of curiosity, have I hit a nerve or something.  Have I somehow offended?
I'm just a bit confused by some of the responses.

I could easily understand the reluctance if there are some standardization
issues with getenv on the targeted platforms I do not know about.  I could
also understand if I was proposing to put it in some weird location, but both
of the hard-coded paths in 9vx main.c are obviously in RSC's home directories
and not more generic locations like /home/9vx, $home/9vx, /usr/local/9vx, /opt...

  EBo --


> On Mon, Apr 12, 2010 at 5:22 AM, EBo <ebo@sandien.com> wrote:
> >
> >> Why isn't 9vx -r yourdir good enough?
> >
> > it is if you want to force all users to specify the root directory every
> > single time they run 9vx, or if you want to use an alternative root.  If
I use
> > a standard install locations then we can either change "/Users/rsc/9vx" and
> > "/home/rsc/plan9/4e" or I can simply run a sed script during the build phase.
> >  Setting up a $root9vx (what I have changed it to) seemed the cleanest
approach.
> >
> >  EBo --

Re: [9fans] /sys/lib/newuser patch

[erik quanstrom]

> Following on several peoples advice and a suggested code snippet from Erik
> I've added the following before the check for profile:
>
> if(! test -d $home){
> 	echo no home directory $home
> 	exit homeless
> }
> if(! ls -ld $home >[2=] | grep -s '^d-rwx.* '$user){
> 	echo bad permissions
> 	exit homeless
> }

you must also exit if ~ $user none.  i'd also recommend
aborting if ~ $home /.  you don't want none making
files in /.  on a regular plan 9 system, that's no worry, but
9vx, ...

- erik

Re: [9fans] 9vx patch to read environment var PLAN9

[erik quanstrom]

> That is what I did for the first prototype.  I thought this would be a beeter
> solution.
>
> Out of curiosity, have I hit a nerve or something.  Have I somehow offended?
> I'm just a bit confused by some of the responses.

no.  i don't think anyone's offended.  and i personally
think the env variable is fine.

but i can see the objection to complication.

if i were you, the question i'd why have a list of
hardcoded roots at all?  none are even in the
user's home directory.

- erik

Re: [9fans] /sys/lib/newuser patch

[EBo]

erik quanstrom <quanstro@quanstro.net> said:

> > Following on several peoples advice and a suggested code snippet from Erik
> > I've added the following before the check for profile:
> >
> > if(! test -d $home){
> > 	echo no home directory $home
> > 	exit homeless
> > }
> > if(! ls -ld $home >[2=] | grep -s '^d-rwx.* '$user){
> > 	echo bad permissions
> > 	exit homeless
> > }
>
> you must also exit if ~ $user none.  i'd also recommend
> aborting if ~ $home /.  you don't want none making
> files in /.  on a regular plan 9 system, that's no worry, but
> 9vx, ...

The reason I did not include ~ $home / is that the first two lines of code in
newuser are:

user=`{cat /dev/user}
home=/usr/$user

so home can never be just / (unless I am missing something here), but the ~
$user none is a very good point.  Thanks!

  EBo --

Re: [9fans] /sys/lib/newuser patch

[hiro]

On 4/12/10, erik quanstrom <quanstro@quanstro.net> wrote:
>> Following on several peoples advice and a suggested code snippet from Erik
>> I've added the following before the check for profile:
>>
>> if(! test -d $home){
>> 	echo no home directory $home
>> 	exit homeless
>> }
>> if(! ls -ld $home >[2=] | grep -s '^d-rwx.* '$user){
>> 	echo bad permissions
>> 	exit homeless
>> }
>
> you must also exit if ~ $user none.  i'd also recommend
> aborting if ~ $home /.  you don't want none making
> files in /.  on a regular plan 9 system, that's no worry, but
> 9vx, ...
>
> - erik
>
>

Can't we then fix 9vx?
(Stepping in to the tradition of concern of reception: This is not a
rhetoric question)

Re: [9fans] /sys/lib/newuser patch

[erik quanstrom]

> Can't we then fix 9vx?
> (Stepping in to the tradition of concern of reception: This is not a
> rhetoric question)

it's not 9vx, but #Z.  and no, #Z is going to be limited by
the underlying system.

- erik

Re: [9fans] /sys/lib/newuser patch

[EBo]

> you must also exit if ~ $user none.  i'd also recommend
> aborting if ~ $home /.  you don't want none making
> files in /.  on a regular plan 9 system, that's no worry, but
> 9vx, ...

I also tried to add test -z $user for the null string.  It turns out that
user=`{cat /dev/user} dies with the error "rc (newuser): null list in
concatenation".  Is this an appropriate failure mode, or is there some
workaround to do a null username? or is this getting to complicated?

  EBo --

Re: [9fans] /sys/lib/newuser patch

[hiro]

I have not the slightest idea about the complexity involved; And I
think I misunderstand how much of plan9 is actually running in a
sandbox. But what if we wanted to have a working security system for
multiple users in 9vx. Would it be - or is it - possible?

On 4/12/10, erik quanstrom <quanstro@labs.coraid.com> wrote:
>> Can't we then fix 9vx?
>> (Stepping in to the tradition of concern of reception: This is not a
>> rhetoric question)
>
> it's not 9vx, but #Z.  and no, #Z is going to be limited by
> the underlying system.
>
> - erik
>
>

Re: [9fans] /sys/lib/newuser patch

[Devon H. O'Dell]

2010/4/12 hiro <23hiro@googlemail.com>:
> I have not the slightest idea about the complexity involved; And I
> think I misunderstand how much of plan9 is actually running in a
> sandbox. But what if we wanted to have a working security system for
> multiple users in 9vx. Would it be - or is it - possible?

Yes, it is possible, but it probably requires writing something to use
PAM (or whatever authentication mechanism is set up) on the host
system. I have a few ideas for this.

--dho

> On 4/12/10, erik quanstrom <quanstro@labs.coraid.com> wrote:
>>> Can't we then fix 9vx?
>>> (Stepping in to the tradition of concern of reception: This is not a
>>> rhetoric question)
>>
>> it's not 9vx, but #Z.  and no, #Z is going to be limited by
>> the underlying system.
>>
>> - erik
>>
>>
>
>

Re: [9fans] /sys/lib/newuser patch

[erik quanstrom]

> 2010/4/12 hiro <23hiro@googlemail.com>:
> > I have not the slightest idea about the complexity involved; And I
> > think I misunderstand how much of plan9 is actually running in a
> > sandbox. But what if we wanted to have a working security system for
> > multiple users in 9vx. Would it be - or is it - possible?
>
> Yes, it is possible, but it probably requires writing something to use
> PAM (or whatever authentication mechanism is set up) on the host
> system. I have a few ideas for this.

iirc, 9vx doesn't have devcap.

the problem you're addressing can't be addressed well through #Z.
unix systems act differently than plan 9 ones do. there are a host
of locking, etc. questions that #Z doesn't handle either.   it would be easier
to use a plan 9 fs (ken fs, cwfs, fossil).  then you wouldn't need to
deal with unix authentication.

- erik

Re: [9fans] /sys/lib/newuser patch

[Devon H. O'Dell]

2010/4/12 erik quanstrom <quanstro@quanstro.net>:
>> 2010/4/12 hiro <23hiro@googlemail.com>:
>> > I have not the slightest idea about the complexity involved; And I
>> > think I misunderstand how much of plan9 is actually running in a
>> > sandbox. But what if we wanted to have a working security system for
>> > multiple users in 9vx. Would it be - or is it - possible?
>>
>> Yes, it is possible, but it probably requires writing something to use
>> PAM (or whatever authentication mechanism is set up) on the host
>> system. I have a few ideas for this.
>
> iirc, 9vx doesn't have devcap.

It does not. (Yet).

> the problem you're addressing can't be addressed well through #Z.
> unix systems act differently than plan 9 ones do. there are a host
> of locking, etc. questions that #Z doesn't handle either.   it would be easier
> to use a plan 9 fs (ken fs, cwfs, fossil).  then you wouldn't need to
> deal with unix authentication.

Probably true. However, I'm confident that there are ways to address
it -- and still, one of the cool things about 9vx is the local FS
access. When I was doing my 9vx autoprovisioner, the instances would
start in a chrooted sandbox, which was the best way I could figure to
deal with the permissioning issues at that point in time (without lots
o hacking).

--dho

> - erik
>
>

Re: [9fans] /sys/lib/newuser patch

[hiro]

And the users are running in single sandboxes?

On 4/12/10, erik quanstrom <quanstro@quanstro.net> wrote:
>> 2010/4/12 hiro <23hiro@googlemail.com>:
>> > I have not the slightest idea about the complexity involved; And I
>> > think I misunderstand how much of plan9 is actually running in a
>> > sandbox. But what if we wanted to have a working security system for
>> > multiple users in 9vx. Would it be - or is it - possible?
>>
>> Yes, it is possible, but it probably requires writing something to use
>> PAM (or whatever authentication mechanism is set up) on the host
>> system. I have a few ideas for this.
>
> iirc, 9vx doesn't have devcap.
>
> the problem you're addressing can't be addressed well through #Z.
> unix systems act differently than plan 9 ones do. there are a host
> of locking, etc. questions that #Z doesn't handle either.   it would be
> easier
> to use a plan 9 fs (ken fs, cwfs, fossil).  then you wouldn't need to
> deal with unix authentication.
>
> - erik
>
>

Re: [9fans] /sys/lib/newuser patch

[hiro]

and what is src/9vx/a/devcap.c ?

On 4/12/10, erik quanstrom <quanstro@quanstro.net> wrote:
>> 2010/4/12 hiro <23hiro@googlemail.com>:
>> > I have not the slightest idea about the complexity involved; And I
>> > think I misunderstand how much of plan9 is actually running in a
>> > sandbox. But what if we wanted to have a working security system for
>> > multiple users in 9vx. Would it be - or is it - possible?
>>
>> Yes, it is possible, but it probably requires writing something to use
>> PAM (or whatever authentication mechanism is set up) on the host
>> system. I have a few ideas for this.
>
> iirc, 9vx doesn't have devcap.
>
> the problem you're addressing can't be addressed well through #Z.
> unix systems act differently than plan 9 ones do. there are a host
> of locking, etc. questions that #Z doesn't handle either.   it would be
> easier
> to use a plan 9 fs (ken fs, cwfs, fossil).  then you wouldn't need to
> deal with unix authentication.
>
> - erik
>
>

Re: [9fans] /sys/lib/newuser patch

[erik quanstrom]

> > the problem you're addressing can't be addressed well through #Z.
> > unix systems act differently than plan 9 ones do. there are a host
> > of locking, etc. questions that #Z doesn't handle either.   it would be easier
> > to use a plan 9 fs (ken fs, cwfs, fossil).  then you wouldn't need to
> > deal with unix authentication.
>
> Probably true. However, I'm confident that there are ways to address
> it -- and still, one of the cool things about 9vx is the local FS
> access. When I was doing my 9vx autoprovisioner, the instances would
> start in a chrooted sandbox, which was the best way I could figure to
> deal with the permissioning issues at that point in time (without lots
> o hacking).

that is cool.  but i think it's a mistake to get carried away.
#Z just isn't a regular plan 9 file system.  locks don't work.
users and groups work differently.  (and of course, 9vx
is run by exactly 1 unix user so i don't see how pam helps.)
authentication works differently, there's no append-only
mode, etc.

- erik

Re: [9fans] /sys/lib/newuser patch

[Anthony Sorace]

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

On Apr 12, 2010, at 11:23, hiro wrote:

> and what is src/9vx/a/devcap.c ?


As far as my system and (as far as I can tell) the
Mercurial repository: fictional. Something you'd
like to share with the class?


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 201 bytes --]

Re: [9fans] /sys/lib/newuser patch

[EBo]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 840 bytes --]


> On Apr 12, 2010, at 11:23, hiro wrote:
>
> > and what is src/9vx/a/devcap.c ?
>
> As far as my system and (as far as I can tell) the
> Mercurial repository: fictional. Something you'd
> like to share with the class?

Hunting on the we it looks like Ron Cox is the goto person for that
(http://bitbucket.org/rsc/vx32/changesets/ dated 2009-12-27):

"To make it possible to log into 9vx using drawterm a device #� (devcap) is
needed, otherwise auth_chuid() will fail, because it cannot open #�/capuse."

"This patch adds `9/port/devcap.c' from Plan 9 to 9vx/a, with only a few
adaptions (see a/devcap.ed)."

So if I am reading this correctly, it is in a vx32 repository but not in the
9vx one.  I could be totally off base with that one, but thought the info
might be useful for tracking down.


  EBo --

Re: [9fans] /sys/lib/newuser patch

[Anthony Sorace]

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

On Apr 12, 2010, at 22:53, EBo wrote:

>> On Apr 12, 2010, at 11:23, hiro wrote:
>>
>>> and what is src/9vx/a/devcap.c ?
>>
>> As far as my system and (as far as I can tell) the
>> Mercurial repository: fictional. Something you'd
>> like to share with the class?
>
> Hunting on the we it looks like Ron Cox is the goto person for that
> (http://bitbucket.org/rsc/vx32/changesets/ dated 2009-12-27):

Ah, my bad. I was looking at the old, pre-bitbucket repository (in my
defense, still linked from swtch.com/9vx). I take it back.


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 201 bytes --]

Re: [9fans] /sys/lib/newuser patch

[EBo]

> > Hunting on the we it looks like Ron Cox is the goto person for that
> > (http://bitbucket.org/rsc/vx32/changesets/ dated 2009-12-27):
>
> Ah, my bad. I was looking at the old, pre-bitbucket repository (in my
> defense, still linked from swtch.com/9vx). I take it back.

hmmm... the sources I am building 9vx from are:

  http://hg.pdos.csail.mit.edu/hg/vx32/http://code.swtch.com/9vx.

Should I be building them from http://bitbucket.org/rsc/vx32?

  EBo --

Re: [9fans] /sys/lib/newuser patch

[EBo]

EBo <ebo@sandien.com> said:

>
> > > Hunting on the we it looks like Ron Cox is the goto person for that
> > > (http://bitbucket.org/rsc/vx32/changesets/ dated 2009-12-27):
> >
> > Ah, my bad. I was looking at the old, pre-bitbucket repository (in my
> > defense, still linked from swtch.com/9vx). I take it back.
>
> hmmm... the sources I am building 9vx from are:
>
>   http://hg.pdos.csail.mit.edu/hg/vx32/http://code.swtch.com/9vx.
>
> Should I be building them from http://bitbucket.org/rsc/vx32?

yep.  Just verified it.  The bitbucket sources are a superset and seem to be
moved sometime after 2009/10/05.

Thanks Anthony for bringing that to my attention!

  EBo --

Re: [9fans] 9vx patch to read environment var PLAN9

[Skip Tavakkolian]

> but both
> of the hard-coded paths in 9vx main.c are obviously in RSC's home directories

it's not hardcoded; you can use -r as Russ said.  the difference is:
"use default unless -r is given" vs.  "use default unless
getenv(NINEROOT) is given".  -r makes it very obvious what the root is
and probably will work better for un-unix-like environments.

but at any rate, you have the sources and are free to change things
locally to suit your taste.

Re: [9fans] 9vx patch to read environment var PLAN9

[EBo]

Skip Tavakkolian <9nut@9netics.com> said:

> > but both
> > of the hard-coded paths in 9vx main.c are obviously in RSC's home directories
>
> it's not hardcoded;

What?  The findroot code reads:

static char*
findroot(void)
{
	static char cwd[1024];
	int i;
	char buf[1024];
	char *dir[] = {
		cwd,
		"/Users/rsc/9vx",
		"/home/rsc/plan9/4e"
	};

	if(getcwd(cwd, sizeof cwd) == nil){
		oserrstr();
		panic("getcwd: %r");
	}

	for(i=0; i<nelem(dir); i++){
		snprint(buf, sizeof buf, "%s/386/bin/rc", dir[i]);
		if(access(buf, 0) >= 0)
			return dir[i];
	}
	return nil;
}

"/Users/rsc/9vx","/home/rsc/plan9/4e" are most certainly hard coded locations,
and will likely only be default on rsc's machines.

> you can use -r as Russ said.  the difference is:
> "use default unless -r is given" vs.  "use default unless
> getenv(NINEROOT) is given".  -r makes it very obvious what the root is
> and probably will work better for un-unix-like environments.

Put another way, what are the default locations?

Also, it would probably be "use default unless getenv(NINEROOT) or -r is
given".  Also, getenv works on Windoz.  What un-unix-like environments are you
referring to?

> but at any rate, you have the sources and are free to change things
> locally to suit your taste.

true, but will these patches be accepted upstream?  If I was looking to just
build this for myself I would not be bothering any of you, I'm trying to
figure out what would be useful to include upstream.  I guess I should not
have posted this to the list, but simply taken it up with Russ off-list since
it is his code.

  EBo --

Re: [9fans] 9vx patch to read environment var PLAN9

[Skip Tavakkolian]

> What?  The findroot code reads:

read the code again; findroot doesn't come into play.

Re: [9fans] 9vx patch to read environment var PLAN9

[EBo]

Skip Tavakkolian <9nut@9netics.com> said:

> > What?  The findroot code reads:
>
> read the code again; findroot doesn't come into play.

it most certainly does!

in main...

	if(!bootboot){
		if(localroot == nil && (localroot = findroot()) == nil)
			panic("cannot find plan 9 root; use -r");

So, if you do not specify localroot (via -r) then it uses findroot.  Findroot
first checks the cwd, and then two hardcoded paths.  This means that unless
the program is run from the 9vx's associated Plan 9 root, or the programs were
installed in "/Users/rsc/9vx" or "/home/rsc/plan9/4e", then you are requiring
all users on a system to run 9vx with -r and know where that root is always.

Is it unreasonable to expect that an invocation of "9vx" to actually run?

  EBo --

Re: [9fans] 9vx patch to read environment var PLAN9

[Skip Tavakkolian]

>> > What?  The findroot code reads:
>>
>> read the code again; findroot doesn't come into play.
>
> it most certainly does!

the whole point was that given -r, findroot doesn't come into play.

if NINEROOT is not set, what does your version of 9vx do (without -r)?

Re: [9fans] 9vx patch to read environment var PLAN9

[EBo]

> >> > What?  The findroot code reads:
> >>
> >> read the code again; findroot doesn't come into play.
> >
> > it most certainly does!
>
> the whole point was that given -r, findroot doesn't come into play.
>
> if NINEROOT is not set, what does your version of 9vx do (without -r)?

In short it fails with the error "cannot find plan 9 root; use -r"

Here is the specific sequence:

  If the 9vx invocation is in the root directory use `cwd`

    -> here is where I checked for NINEROOT

  try "/Users/rsc/9vx"

  try "/home/rsc/plan9/4e"

  fail with error "cannot find plan 9 root; use -r"


  EBo --

Re: [9fans] /sys/lib/newuser patch

[maht]

On 12/04/2010 06:34, EBo wrote:
> if(! ls -ld $home>[2=] | grep -s '^d-rwx.* '$user){
> 	echo bad permissions
> 	exit homeless
> }
>
>
surely : echo bad permissions >[1=2]

Re: [9fans] /sys/lib/newuser patch

[EBo]

> surely : echo bad permissions >[1=2]

I think you may be right.

Re: [9fans] 9vx patch to read environment var PLAN9

[Ethan Grammatikidis]

On 13 Apr 2010, at 06:20, EBo wrote:

> Skip Tavakkolian <9nut@9netics.com> said:
>
>>> but both
>>> of the hard-coded paths in 9vx main.c are obviously in RSC's home
>>> directories
>>
>> it's not hardcoded;
>
> What?  The findroot code reads:
>
> static char*
> findroot(void)
> {
> 	static char cwd[1024];
> 	int i;
> 	char buf[1024];
> 	char *dir[] = {
> 		cwd,

I don't usually like to say "why bother", but given 9vx could be
launched with the appropriate parameter from a 2 line shell script
(including the #!), why are you even debating this?

--
Simplicity does not precede complexity, but follows it. -- Alan Perlis

Re: [9fans] 9vx patch to read environment var PLAN9

[EBo]

> I don't usually like to say "why bother", but given 9vx could be
> launched with the appropriate parameter from a 2 line shell script
> (including the #!), why are you even debating this?

wow...  I can understand people not liking checking the environmental
variables as it does increase the complexity, but I would have thought that
changing the default lookup from /home/rcs... would not have been a problem.
I guess I was wrong about that.

Re: [9fans] 9vx patch to read environment var PLAN9

[Federico G. Benavento]

hardcode your own path and let the next sucker repeat the story

On Wed, Apr 14, 2010 at 3:10 PM, EBo <ebo@sandien.com> wrote:
>
>> I don't usually like to say "why bother", but given 9vx could be
>> launched with the appropriate parameter from a 2 line shell script
>> (including the #!), why are you even debating this?
>
> wow...  I can understand people not liking checking the environmental
> variables as it does increase the complexity, but I would have thought that
> changing the default lookup from /home/rcs... would not have been a problem.
> I guess I was wrong about that.
>
>



-- 
Federico G. Benavento

Re: [9fans] 9vx patch to read environment var PLAN9

[lucio]

> hardcode your own path and let the next sucker repeat the story

I dunno, it would seem to me that the sequence:

	-r option? yes: use argument
		no: $NINEROOT set? yes: use value
			no: use $HOME/9vx (or somesuch)

would be pretty much acceptable.  I guess if there is no $HOME (or
$home, I don't see much point arguing over that, try both if you feel
that way inclined) one can use /usr/rsc or /home/rcs, but that seems a
bit outlandish.

++L

Re: [9fans] 9vx patch to read environment var PLAN9

[erik quanstrom]

> > I don't usually like to say "why bother", but given 9vx could be
> > launched with the appropriate parameter from a 2 line shell script
> > (including the #!), why are you even debating this?
>
> wow...  I can understand people not liking checking the environmental
> variables as it does increase the complexity, but I would have thought that
> changing the default lookup from /home/rcs... would not have been a problem.
> I guess I was wrong about that.

relax.  it is unfortunte that there's too much resistance
to improving on the initial cut.

- erik

Re: [9fans] 9vx patch to read environment var PLAN9

[EBo]

> hardcode your own path and let the next sucker repeat the story

fair enough, and now for the heart of the question that I have been dancing
around all along (actually I thought it was obvious) -- what is the best way
to fix this section of code so that we can be done with it once and for all?
Remove all hard coded paths and require -r and startup from root dir?  ok.
add the env variable?  ok.  do whatever I am going to do and never post my
patches to start another flame drizzle (as compared to an all out flame war)?
 So, what's to be done?

Re: [9fans] 9vx patch to read environment var PLAN9

[Skip Tavakkolian]

>> I don't usually like to say "why bother", but given 9vx could be
>> launched with the appropriate parameter from a 2 line shell script
>> (including the #!), why are you even debating this?
>
> wow...  I can understand people not liking checking the environmental
> variables as it does increase the complexity, but I would have thought that
> changing the default lookup from /home/rcs... would not have been a problem.
> I guess I was wrong about that.

the point is that any default is bound to be wrong.  my guess is that
'/home/rsc/...' default was introduced early in the development and
before '-r' was added.  it might be more useful to lobby for a default
location like '/usr/lib/9vx'.

secondly writing

$ NINEROOT=/usr/ebo/9vxroot 9vx

is less pleasant than:

$ 9vx -r /usr/ebo/9vxroot

it's true that NINEROOT can be set and forgotten about, but the same
argument could be made for writing a shell function that aliases 9vx
to '9vx -r ...' etc -- and probably in the same place, e.g. .profile.

Re: [9fans] 9vx patch to read environment var PLAN9

[EBo]

> relax.  it is unfortunte that there's too much resistance
> to improving on the initial cut.

Don't worry I'm relaxed, just seriously amazed and trying to figure this out.

The issue that will eventually stress me out however is the fact that these
discussions have hamstrung my productivity to probably less than 10% my
normal.  Learning the plan9 way is so far more than worth it, and I hope it
will continue to be.

  EBo --

Re: [9fans] 9vx patch to read environment var PLAN9

[EBo]

> the point is that any default is bound to be wrong.  my guess is that
> '/home/rsc/...' default was introduced early in the development and
> before '-r' was added.  it might be more useful to lobby for a default
> location like '/usr/lib/9vx'.
>
> secondly writing
>
> $ NINEROOT=/usr/ebo/9vxroot 9vx
>
> is less pleasant than:
>
> $ 9vx -r /usr/ebo/9vxroot
>
> it's true that NINEROOT can be set and forgotten about, but the same
> argument could be made for writing a shell function that aliases 9vx
> to '9vx -r ...' etc -- and probably in the same place, e.g. .profile.

excellent, some constructive feedback, and thank all of you who have done so.

We already have -r so that we can either alias 9vx, or write a two line
wrapper as also previously suggested.

Now lets debate if there should be any hard coded paths in the program.  Where
are the most appropraite locations?  We could of course open up the /opt
/usr/local debate again, but there is also putting it into /usr/share/9vx and
/usr/lib/9vx as suggested. We could hash out what is suggested with the Linux
Standard Base, or throw the whole thing out the window.

What I have decided to do for my current work is to put it in /usr/local.
Why?  I am working on Tvx, and their standard install is in /usr/local/${package}

I'll take consensus on the NINEROOT and ${home}/ if people do not mind that
complexity.

  EBo --

Re: [9fans] 9vx patch to read environment var PLAN9

[Ethan Grammatikidis]

On 14 Apr 2010, at 19:38, EBo wrote:

>
>> hardcode your own path and let the next sucker repeat the story
>
> fair enough, and now for the heart of the question that I have been
> dancing
> around all along (actually I thought it was obvious) -- what is the
> best way
> to fix this section of code so that we can be done with it once and
> for all?
> Remove all hard coded paths and require -r and startup from root
> dir?  ok.
> add the env variable?  ok.  do whatever I am going to do and never
> post my
> patches to start another flame drizzle (as compared to an all out
> flame war)?
> So, what's to be done?

Watching yet another 'flame drizzle' (good term, btw) is precisely
what made me grumpy, sorry about that. I get really tired of watching
them but don't do any good when I get involved, so I don't know what
to do really. Perhaps if I only comment if I can think of something
positive.

If I do have a constructive comment on this subject, I can't see any
harm in adding both /usr/local/9vx and /opt/9vx to the hard-coded
paths as these are paths on the host system, not plan 9, and thus
*shouldn't* start up that old debate again. I think /usr/local and /
opt are both commonly used for odd binary trees, P9p being a prime
example with build instructions suggesting /usr/local/plan9 and more
than one Linux distro choosing /opt/plan9.

I'm not so sure about /usr/lib or /usr/share. I'd tolerate both (I've
stopped caring about the unix filesystem hierarchy), but speaking as a
long-time Linux user they don't feel right, especially not /usr/share.
If you do put them in they probably won't draw any trouble as just
hard-coded paths hidden in the source.

Is there any harm in putting in as many hard-coded paths in as might
be reasonable?

--
Simplicity does not precede complexity, but follows it. -- Alan Perlis

Re: [9fans] 9vx patch to read environment var PLAN9

[Patrick Kelly]

> I'm not so sure about /usr/lib or /usr/share. I'd tolerate both (I've stopped caring about the unix filesystem hierarchy), but speaking as
> a long-time Linux user they don't feel right, especially not /usr/share.
> If you do put them in they probably won't draw any trouble as just hard-coded paths hidden in the source.
> 
> Is there any harm in putting in as many hard-coded paths in as might be reasonable?

Define reasonable. For me, that’s just 1 single spot. But it seems the Linux people are very insistent on Freedom meaning do what you want, even if it's against the build suggestions.
I say stick to one hardcoded path, and make everyone else stop doing it their own way, and stick to one simple, consistent solution.

Re: [9fans] 9vx patch to read environment var PLAN9

[Russ Cox]

I don't mind adding more directories to the list in findroot,
and something like /usr/local/9vx is certainly a better entry
in that list than /home/rsc/plan9/4e (sorry).

What I didn't understand was the rationale behind putting
in a new environment variable when there is already a
command-line option.  The argument about being right
for the users is bogus: the amount of work required to
make all users have the right environment variable setting
is about the same as the amount of work required to
make all users pass the right -r flag.

Russ

Re: [9fans] 9vx patch to read environment var PLAN9

[EBo]

> I don't mind adding more directories to the list in findroot,
> and something like /usr/local/9vx is certainly a better entry
> in that list than /home/rsc/plan9/4e (sorry).

no apologies necessary.  I actually liked Ethan Grammatikidis' last comments
regarding adding standard the standard locations.

> What I didn't understand was the rationale behind putting
> in a new environment variable when there is already a
> command-line option.  The argument about being right
> for the users is bogus: the amount of work required to
> make all users have the right environment variable setting
> is about the same as the amount of work required to
> make all users pass the right -r flag.

what I had meant is simply that when a user tries to run a program which has
been installed system wide it should simply work.  If writing a shell script
around the exe is considered a better way to go about it then I'm good with it.

  EBo --

Re: [9fans] 9vx patch to read environment var PLAN9

[EBo]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 527 bytes --]


> Define reasonable. For me, that’s just 1 single spot. But it seems
> the Linux people are very insistent on Freedom meaning do what you
> want, even if it's against the build suggestions.
> I say stick to one hardcoded path, and make everyone else stop doing
> it their own way, and stick to one simple, consistent solution.

Two possible guides are:

Linux Standard Base <http://www.linuxfoundation.org/collaborate/workgroups/lsb>

and

Filesystem Hierarchy Standard <http://proton.pathname.com/fhs/>

Re: [9fans] 9vx patch to read environment var PLAN9

[Ethan Grammatikidis]

On 15 Apr 2010, at 07:48, EBo wrote:
> what I had meant is simply that when a user tries to run a program
> which has
> been installed system wide it should simply work.

A good goal, but I'm not sure an environment variable is a good way to
achieve it. At the very least it means, in a typical Linux
distribution, an additional file in each of /etc/profile.d, /etc/
zprofile.d, /etc/cshlogin.d (or whatever they call it) and etc. for
each shell the user might possibly want.

Then there's the matter of users who commit the heinous crime of
preferring a display manager over startx, which raises questions over
when where or even _if_ system-wide environment variables will be set
at all. Display managers are still the truculent beasts they were 10
years ago.

Then too there's the possibility that some poor [l]user will get the
notion that the environment variable is the right way to set the
parameter, and get in a muddle when half his open xterms (that he's
had open for the past month) still have the old setting. Better to let
him write a script, at least he can stick it in ~/bin. (Yes, it
happened to me, more than once, and rather converted me to wrapper
scripts.)

If some distro wants to stick a default 9vx tree in some _really_
weird place, let them patch the source!

--
Simplicity does not precede complexity, but follows it. -- Alan Perlis

Re: [9fans] 9vx patch to read environment var PLAN9

[Balwinder S Dheeman]

On 04/14/2010 09:55 PM, Ethan Grammatikidis wrote:
>
> On 13 Apr 2010, at 06:20, EBo wrote:
>
>> Skip Tavakkolian <9nut@9netics.com> said:
>>
>>>> but both
>>>> of the hard-coded paths in 9vx main.c are obviously in RSC's home
>>>> directories
>>>
>>> it's not hardcoded;
>>
>> What?  The findroot code reads:
>>
>> static char*
>> findroot(void)
>> {
>>     static char cwd[1024];
>>     int i;
>>     char buf[1024];
>>     char *dir[] = {
>>         cwd,
>
> I don't usually like to say "why bother", but given 9vx could be
> launched with the appropriate parameter from a 2 line shell script
> (including the #!), why are you even debating this?


Just to add more complications ;)

--
Balwinder S "bdheeman" Dheeman        Registered Linux User: #229709
Anu'z Linux@HOME (Unix Shoppe)        Machines: #168573, 170593, 259192
Chandigarh, UT, 160062, India         Plan9, T2, Arch/Debian/FreeBSD/XP
Home: http://werc.homelinux.net/      Visit: http://counter.li.org/

Re: [9fans] 9vx patch to read environment var PLAN9

[Ethan Grammatikidis]

On 15 Apr 2010, at 08:39, EBo wrote:

>
>> Define reasonable. For me, that’s just 1 single spot. But it seems
>> the Linux people are very insistent on Freedom meaning do what you
>> want, even if it's against the build suggestions.
>> I say stick to one hardcoded path, and make everyone else stop doing
>> it their own way, and stick to one simple, consistent solution.
>
> Two possible guides are:
>
> Linux Standard Base <http://www.linuxfoundation.org/collaborate/workgroups/lsb 
> >
>
> and
>
> Filesystem Hierarchy Standard <http://proton.pathname.com/fhs/>

I deliberately avoided referring to these two... _interesting_  
documents. I studied the FHS at some length some years ago, not the  
latest version but the one before. As I understood it, it provides no  
possible place for a 9vx tree, for a plan9port tree, for a GNUStep  
tree, in short, for anything which does not conform precisely to the  
same layout of directories it specifies for /usr. The requirements  
for /opt at least have been softened in the latest version, so that a  
distro could 'legitimately' install 9vx or p9p under /opt, but I doubt  
it could be put anywhere else.

I won't comment on the LSB except to say that between the way Linux  
has been going lately and the almost perversely obsolete document the  
LSB was the last time I looked at it, I don't really want to know  
anything about it, least of all if it's been brought up to date.

I deliberately used the phrase "commonly used" in my earlier email  
because at the end of the day that's the only useful guide. In any  
case these standards are only made by taking common use and  
constraining it within (sometimes perverse) reasoning.

-- 
Simplicity does not precede complexity, but follows it. -- Alan Perlis

Re: [9fans] 9vx patch to read environment var PLAN9

[Ethan Grammatikidis]

On 15 Apr 2010, at 09:44, Balwinder S Dheeman wrote:

> On 04/14/2010 09:55 PM, Ethan Grammatikidis wrote:
>>
>> On 13 Apr 2010, at 06:20, EBo wrote:
>>
>>> Skip Tavakkolian <9nut@9netics.com> said:
>>>
>>>>> but both
>>>>> of the hard-coded paths in 9vx main.c are obviously in RSC's home
>>>>> directories
>>>>
>>>> it's not hardcoded;
>>>
>>> What?  The findroot code reads:
>>>
>>> static char*
>>> findroot(void)
>>> {
>>>    static char cwd[1024];
>>>    int i;
>>>    char buf[1024];
>>>    char *dir[] = {
>>>        cwd,
>>
>> I don't usually like to say "why bother", but given 9vx could be
>> launched with the appropriate parameter from a 2 line shell script
>> (including the #!), why are you even debating this?
>
>
> Just to add more complications ;)

Did you choose the word "complications" because in watchmaking it
denotes extra (and often near-pointless) features? :D

In the minute space within a wristwatch complications are wonderful
things, particularly when the whole watch is mechanical, but in a
computer... A computer is a working machine, a mechanical wristwatch
today is first and foremost art.

Speaking of watches, I can't resist sharing these for those who have
time to waste:
http://watchismo.blogspot.com/2010/03/hodinkee-shares-baselworld-videos-of.html
http://watchismo.blogspot.com/2010/03/rebellion-t-1000-vertical-roller.html
http://watchismo.blogspot.com/2010/03/4n-mvt01-four-numbers-disc-watch-by.html

I wonder if anything is signified by the seeming inability of the
watchmaking fraternity to make a simple website? MB&F are about the
most seminal group in the field, but they use flash for a very simple
menu: http://www.mbandf.com/

>
> --
> Balwinder S "bdheeman" Dheeman        Registered Linux User: #229709
> Anu'z Linux@HOME (Unix Shoppe)        Machines: #168573, 170593,
> 259192
> Chandigarh, UT, 160062, India         Plan9, T2, Arch/Debian/FreeBSD/
> XP
> Home: http://werc.homelinux.net/      Visit: http://counter.li.org/
>

--
Simplicity does not precede complexity, but follows it. -- Alan Perlis

Re: [9fans] 9vx patch to read environment var PLAN9

[EBo]

> > Just to add more complications ;)
>
> Did you choose the word "complications" because in watchmaking it
> denotes extra (and often near-pointless) features? :D

Those watches are amazing!

Speaking for simplicity, the first time I saw the Salisbury cathedral clock
<http://en.wikipedia.org/wiki/Salisbury_cathedral_clock> I wanted to go out
and build one.  So, if you know anyone with dimensional drawings I should soon
have my forge up and running again ;-)

  EBo --

Re: [9fans] 9vx patch to read environment var PLAN9

[Devon H. O'Dell]

2010/4/15 EBo <ebo@sandien.com>:
>
>> Define reasonable. For me, that’s just 1 single spot. But it seems
>> the Linux people are very insistent on Freedom meaning do what you
>> want, even if it's against the build suggestions.
>> I say stick to one hardcoded path, and make everyone else stop doing
>> it their own way, and stick to one simple, consistent solution.
>
> Two possible guides are:
>
> Linux Standard Base <http://www.linuxfoundation.org/collaborate/workgroups/lsb>
>
> and
>
> Filesystem Hierarchy Standard <http://proton.pathname.com/fhs/>

But the world isn't Linux.
http://www.freebsd.org/cgi/man.cgi?query=hier&sektion=7

--dho

Re: [9fans] 9vx patch to read environment var PLAN9

[EBo]

> But the world isn't Linux.
> http://www.freebsd.org/cgi/man.cgi?query=hier&sektion=7

I never said it was, but if you look at FeeBSD's /usr/local you will also see
they are in agreement.

  EBo --

Re: [9fans] 9vx patch to read environment var PLAN9

[Balwinder S Dheeman]

On 04/15/2010 03:46 PM, Ethan Grammatikidis wrote:
>
> On 15 Apr 2010, at 09:44, Balwinder S Dheeman wrote:
>
>> On 04/14/2010 09:55 PM, Ethan Grammatikidis wrote:
>>>
>>> I don't usually like to say "why bother", but given 9vx could be
>>> launched with the appropriate parameter from a 2 line shell script
>>> (including the #!), why are you even debating this?
>>
>> Just to add more complications ;)
>
> Did you choose the word "complications" because in watchmaking it
> denotes extra (and often near-pointless) features? :D
>
> In the minute space within a wristwatch complications are wonderful
> things, particularly when the whole watch is mechanical, but in a
> computer... A computer is a working machine, a mechanical wristwatch
> today is first and foremost art.
>
> Speaking of watches, I can't resist sharing these for those who have
> time to waste:
> http://watchismo.blogspot.com/2010/03/hodinkee-shares-baselworld-videos-of.html
>
> http://watchismo.blogspot.com/2010/03/rebellion-t-1000-vertical-roller.html
> http://watchismo.blogspot.com/2010/03/4n-mvt01-four-numbers-disc-watch-by.html
>
>
> I wonder if anything is signified by the seeming inability of the
> watchmaking fraternity to make a simple website? MB&F are about the most
> seminal group in the field, but they use flash for a very simple menu:
> http://www.mbandf.com/

Please don't compare apples with oranges.

I'm sure you have not read, "Program design in the UNIX® environment"
(http://werc.homelinux.net/links/reference_material/unix_prog_design.pdf);
these notes are still valid today and are applicable to Plan9
environment also :)

--
Balwinder S "bdheeman" Dheeman        Registered Linux User: #229709
Anu'z Linux@HOME (Unix Shoppe)        Machines: #168573, 170593, 259192
Chandigarh, UT, 160062, India         Plan9, T2, Arch/Debian/FreeBSD/XP
Home: http://werc.homelinux.net/      Visit: http://counter.li.org/

Re: [9fans] 9vx patch to read environment var PLAN9

[hiro]

Plan 9 is not trying to be compatible to linux.

While some people make life on earth as exciting as possible, others
are trying to fly to Mars.

On 4/15/10, Balwinder S Dheeman <bsd.SANSPAM@cto.homelinux.net> wrote:
> On 04/15/2010 03:46 PM, Ethan Grammatikidis wrote:
>>
>> On 15 Apr 2010, at 09:44, Balwinder S Dheeman wrote:
>>
>>> On 04/14/2010 09:55 PM, Ethan Grammatikidis wrote:
>>>>
>>>> I don't usually like to say "why bother", but given 9vx could be
>>>> launched with the appropriate parameter from a 2 line shell script
>>>> (including the #!), why are you even debating this?
>>>
>>> Just to add more complications ;)
>>
>> Did you choose the word "complications" because in watchmaking it
>> denotes extra (and often near-pointless) features? :D
>>
>> In the minute space within a wristwatch complications are wonderful
>> things, particularly when the whole watch is mechanical, but in a
>> computer... A computer is a working machine, a mechanical wristwatch
>> today is first and foremost art.
>>
>> Speaking of watches, I can't resist sharing these for those who have
>> time to waste:
>> http://watchismo.blogspot.com/2010/03/hodinkee-shares-baselworld-videos-of.html
>>
>> http://watchismo.blogspot.com/2010/03/rebellion-t-1000-vertical-roller.html
>> http://watchismo.blogspot.com/2010/03/4n-mvt01-four-numbers-disc-watch-by.html
>>
>>
>> I wonder if anything is signified by the seeming inability of the
>> watchmaking fraternity to make a simple website? MB&F are about the most
>> seminal group in the field, but they use flash for a very simple menu:
>> http://www.mbandf.com/
>
> Please don't compare apples with oranges.
>
> I'm sure you have not read, "Program design in the UNIX® environment"
> (http://werc.homelinux.net/links/reference_material/unix_prog_design.pdf);
> these notes are still valid today and are applicable to Plan9
> environment also :)
>
> --
> Balwinder S "bdheeman" Dheeman        Registered Linux User: #229709
> Anu'z Linux@HOME (Unix Shoppe)        Machines: #168573, 170593, 259192
> Chandigarh, UT, 160062, India         Plan9, T2, Arch/Debian/FreeBSD/XP
> Home: http://werc.homelinux.net/      Visit: http://counter.li.org/
>
>

Re: [9fans] 9vx patch to read environment var PLAN9

[Ethan Grammatikidis]

On 15 Apr 2010, at 16:38, hiro wrote:

> Plan 9 is not trying to be compatible to linux.

What does this have to do with the present discussion? We are
discussing something which has to run on linux, and on *BSD and other
things: 9vx.

--
Simplicity does not precede complexity, but follows it. -- Alan Perlis

Re: [9fans] 9vx patch to read environment var PLAN9

[Ethan Grammatikidis]

On 15 Apr 2010, at 15:29, Balwinder S Dheeman wrote:
>
> Please don't compare apples with oranges.
>
> I'm sure you have not read, "Program design in the UNIX® environment"
> (http://werc.homelinux.net/links/reference_material/unix_prog_design.pdf 
> );
> these notes are still valid today and are applicable to Plan9
> environment also :)

I don't understand why you're bringing this up. Does my reply to hiro  
answer this too?

-- 
Simplicity does not precede complexity, but follows it. -- Alan Perlis

Re: [9fans] 9vx patch to read environment var PLAN9

[hiro]

Your point is valid. Back to work...

On 4/16/10, Ethan Grammatikidis <eekee57@fastmail.fm> wrote:
>
> On 15 Apr 2010, at 15:29, Balwinder S Dheeman wrote:
>>
>> Please don't compare apples with oranges.
>>
>> I'm sure you have not read, "Program design in the UNIX® environment"
>> (http://werc.homelinux.net/links/reference_material/unix_prog_design.pdf
>> );
>> these notes are still valid today and are applicable to Plan9
>> environment also :)
>
> I don't understand why you're bringing this up. Does my reply to hiro
> answer this too?
>
> --
> Simplicity does not precede complexity, but follows it. -- Alan Perlis
>
>
>

Re: [9fans] 9vx patch to read environment var PLAN9

[erik quanstrom]

> > Plan 9 is not trying to be compatible to linux.
>
> What does this have to do with the present discussion? We are
> discussing something which has to run on linux, and on *BSD and other
> things: 9vx.

sorry for adding to this thread.

i think the original point is valid.  while 9vx does live in
a unix world, it has not been the tradition for such tools
to get overly compunctious about toeing the "standard"
line.  there isn't much agreement what the standards are,
and they change too often.

- erik

Re: [9fans] how about intel D510MO

[Pavel Klinkovsky]

> Is intelD510MOa good choise?
I am trying to make intel D510MO to be my home server now.

Here are several notes (to save your time):
- Configure SATA to IDE mode in BIOS.
- Install Erik's 9atom.iso.
- Set *sdC0dma=on in plan9.ini.
- Disable automatic blanking of the screen.

The Plan9 works on this MB, but running just one core (instead of 4) -
missing MP table.

That's all for now.

Pavel

Re: [9fans] how about intel D510MO

[erik quanstrom]

On Thu Apr  1 06:21:58 EDT 2010, zhaodu1@gmail.com wrote:
> Hi everyone, I've been playing plan9 in qemu for sometime now. the
> only computer I have is a PS3/ubuntu9.04, and I'm thinking about buy a
> low cost x86 board for plan9. Is intel D510MO a good choise?

i don't know, but the prior generation of atom motherboards
from intel were a very poor choice for plan 9 since they didn't
provide proper mp interrupt tables and.  this made it very
difficult to use both processors and we were also missing some
irq routing information that caused some bad interactions with
the southbridge.  there's a chance there's no similar irq routing
problem on the current motherboard, but i'd recommend something
else.

i am currently running a supermicro x7spa-h (d510 processor)
as my terminal and an x7sla-h as a test mule.

- erik