[9fans] hack for /usr/$user/lib/face

[9fans] hack for /usr/$user/lib/face

[matt]

I wasn't content with binding because that meant potentially keeping two sets of .dict files in sync

So I've added an extra routine to facedb.c so that it looks in /usr/$user/lib/face/48x48x* before it looks in /lib/face

I'm not sure of the best way to post it so it's here :

http://www.proweb.co.uk/~matt/plan9/facedb.c

Re: [9fans] hack for /usr/$user/lib/face

[okamoto]

> So I've added an extra routine to facedb.c so that it looks in 
>/usr/$user/lib/face/48x48x* before it looks in /lib/face

By the way, is there anyway to make some portion of the user's file
 avoid from writing to venti, such those private or secret portrait
of someone. ☺  Of course, this should be set by that user, not 
system administrator.

Kenji

Re: [9fans] hack for /usr/$user/lib/face

[Russ Cox]

okamoto@granite.cias.osakafu-u.ac.jp wrote:

>>So I've added an extra routine to facedb.c so that it looks in 
>>/usr/$user/lib/face/48x48x* before it looks in /lib/face
>>    
>>
>
>By the way, is there anyway to make some portion of the user's file
> avoid from writing to venti, such those private or secret portrait
>of someone. ☺  Of course, this should be set by that user, not 
>system administrator.
>  
>

Put them on a different file server and bind them into your name space
in your profile.

Re: [9fans] hack for /usr/$user/lib/face

[boyd, rounin]

> So I've added an extra routine to facedb.c so that it looks in
>/usr/$user/lib/face/48x48x* before it looks in /lib/face

isn't that what bind is for?

Re: [9fans] hack for /usr/$user/lib/face

[David Presotto]

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

we'ld need a deep bind or a hell of a lot of binds to personalize
the database.  as soon as someone writes a deep bind, I'll get rid
of this.  perhaps someone has?

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

From: "boyd, rounin" <boyd@insultant.net>
To: <9fans@cse.psu.edu>
Subject: Re: [9fans] hack for /usr/$user/lib/face
Date: Tue, 2 Sep 2003 16:48:21 +0200
Message-ID: <01a101c37161$41d5c180$b9844051@insultant.net>

> So I've added an extra routine to facedb.c so that it looks in
>/usr/$user/lib/face/48x48x* before it looks in /lib/face

isn't that what bind is for?

Re: [9fans] hack for /usr/$user/lib/face

[andrey mirtchovski]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 559 bytes --]

On Tue, 2 Sep 2003, David Presotto wrote:

> we'ld need a deep bind or a hell of a lot of binds to personalize
> the database.  as soon as someone writes a deep bind, I'll get rid
> of this.  perhaps someone has?

I use the attached monstrosity to bind the entire /sys/src/cmd/ tree in
$home/kern/cmd (some 300+ binds)..

this could be automated via du + test, but dealing with non-existing
directories in the bind-ee location is uncertain -- should they be
created?

and it still won't allow me to do a 'cd $home/kern/cmd; mk all' :)

andrey

[-- Attachment #2: Type: TEXT/PLAIN, Size: 2091 bytes --]

#!/bin/rc

#cmd
bind -c 	$home/kern/cmd  			$home/kern/cmd 
bind -ca 	/sys/src/cmd 				$home/kern/cmd 

for(i in cc 1a 1c 1l 2a 2c 2l 5a 5c 5i 5l 6a 6c 6l 7a 7c 7l 8a 8c 8l 9660srv 9a 9c 9l 9nfs acid acme astro auth aux awk bitsy bzip2 cdfs cfs con cpp cvs db dict diff disk dossrv eqn execnet exportfs ext2srv faces fax fossil getflags grap graph grep gs gzip hoc htmlfmt iostats ip jpg ka kc ki kl lex lp map mk ndb page paqfs pic plot plumb postscript proof qa qc ql ratfs rc replica rio rtstats sam samterm scat scuzz snap spell spin srvold9p ssh syscall tapefs tbl tcs telco troff troff2html upas usb va vac vc venti vi vl vnc vt webfs wikifs) {
	bind -c $home/kern/cmd/$i		$home/kern/cmd/$i
	bind -ca /sys/src/cmd/$i		$home/kern/cmd/$i
}

for (i in mnihongo flashfs na vga) {
	bind -c $home/kern/cmd/aux/$i		$home/kern/cmd/aux/$i
	bind -ca /sys/src/cmd/aux/$i		$home/kern/cmd/aux/$i
}

# bzip2's lib
	bind -c $home/kern/cmd/bzip2/lib	$home/kern/cmd/bzip2/lib
	bind -ca /sys/src/cmd/bzip2/lib		$home/kern/cmd/bzip2/lib

for(i in 9660 kfs prep) {
	bind -c $home/kern/cmd/disk/$i		$home/kern/cmd/disk/$i
	bind -ca /sys/src/cmd/disk/$i		$home/kern/cmd/disk/$i
}

for(i in bin doc examples icclib jpeg lib libpng man obj src zlib) {
	bind -c $home/kern/cmd/gs/$i		$home/kern/cmd/gs/$i
	bind -ca /sys/src/cmd/gs/$i			$home/kern/cmd/gs/$i
}

for(i in ftpfs dhcpd httpd ppp imap4d snoopy) {
	bind -c $home/kern/cmd/ip/$i		$home/kern/cmd/ip/$i
	bind -ca /sys/src/cmd/ip/$i			$home/kern/cmd/ip/$i
}

	bind -c $home/kern/cmd/plot/libplot	$home/kern/cmd/plot/libplot
	bind -ca /sys/src/cmd/plot/libplot		$home/kern/cmd/plot/libplot


 for (i in buildtables common cropmarks devpost.add download g3p9bit grabit hardcopy mcolor misc mpictures p9bitpost picpack postbgi postdaisy postdmd postgif postio postmd postprint postreverse posttek printfont psencoding psfiles tcpostio tests text2post tr2post trofftable) {

	bind -c $home/kern/cmd/postscript/$i		$home/kern/cmd/postscript/$i
	bind -ca /sys/src/cmd/postscript/$i		$home/kern/cmd/postscript/$i

}

Re: [9fans] hack for /usr/$user/lib/face

[boyd, rounin]

du -a | sed ... | rc

Re: [9fans] hack for /usr/$user/lib/face

[Russ Cox]

David Presotto wrote:

>we'ld need a deep bind or a hell of a lot of binds to personalize
>the database.  as soon as someone writes a deep bind, I'll get rid
>of this.  perhaps someone has?
>

a deep bind doesn't solve this, really.  i have my own face database
and i keep them in a directory "rsc/" so that i don't have to worry about
the deep bind.  the problem is that there's one database per bit depth.
if you've got two different directory hierarchies, merging the databases
can't be done automatically with a bind.

Re: [9fans] hack for /usr/$user/lib/face

[david presotto]

You're right of course.  Merging the .dicts and the .machinelist is also not
solved by
binds.   I forgot to get my brain our of neutral.  Only has one gear anyways
and that
one is starting to slip.  I realized my mistake driving up to Boston.

----- Original Message -----
From: "Russ Cox" <rsc@plan9.bell-labs.com>
To: <9fans@cse.psu.edu>
Sent: Tuesday, September 02, 2003 1:05 PM
Subject: Re: [9fans] hack for /usr/$user/lib/face


> David Presotto wrote:
>
> >we'ld need a deep bind or a hell of a lot of binds to personalize
> >the database.  as soon as someone writes a deep bind, I'll get rid
> >of this.  perhaps someone has?
> >
>
> a deep bind doesn't solve this, really.  i have my own face database
> and i keep them in a directory "rsc/" so that i don't have to worry about
> the deep bind.  the problem is that there's one database per bit depth.
> if you've got two different directory hierarchies, merging the databases
> can't be done automatically with a bind.
>
>
>
>

Re: [9fans] hack for /usr/$user/lib/face

[Dan Cross]

> You're right of course.  Merging the .dicts and the .machinelist is also
> not solved by binds.   I forgot to get my brain our of neutral.  Only has
> one gear anyways and that one is starting to slip.  I realized my mistake
> driving up to Boston.

Is there a reason one can't get rid of the .dict files entirely?  Why
not name the image files after the email address?  Now that we have
long file names, there shouldn't be an issue with file name size.  I
suppose the only real two issues would be matching domainnames (e.g.,
user@foo1.bar.com, user@foo2.bar.com, user@foo3.bar.com are probably
all the same person and should use the same picture, etc), and it might
be convenient to have the same picture for multiple mailboxes at
different domains (e.g., presotto@bell-labs.com and
presotto@closedmind.org are the same person).  I can't think of a
particularly good solution to that without some sort of index.  Perhaps
making filenames regular expressions or something (I don't like that,
it does away with a simple walk and turns it into a linear scan of a
big directory).

	- Dan C.

Re: [9fans] hack for /usr/$user/lib/face

[Fco.J.Ballesteros]

> be convenient to have the same picture for multiple mailboxes at
> different domains (e.g., presotto@bell-labs.com and

Now that we have venti, we can store the same image 10k times in
the file system and be sure that the file would be stored just once.

So this is not a problem. I think I like the idea of a
/lib/face/domain/^(unknown usr1 usr2 ...)
hierarchy; just tired of merging .dicts.

Re: [9fans] hack for /usr/$user/lib/face

[Geoff Collyer]

Russ and I wrote ovfs using lib9p for 3rd ed. but never updated it
for 4th ed. and the new lib9p.  Dan Cross has a copy and may have
updated it to 4th ed. by now.  I never got it working under heavy
load but I didn't fully understand the libthread model of threads
at the time and probably went overboard with locking (ovfs appeared
to deadlock itself under load).

Re: [9fans] hack for /usr/$user/lib/face

[okamoto]

> Russ and I wrote ovfs using lib9p for 3rd ed. but never updated it
> for 4th ed. and the new lib9p.  Dan Cross has a copy and may have
> updated it to 4th ed. by now.

If we use another file system for no archiving, as the other file svstem
I'm using, it's neccessary to make it everyone writable.   If not, we have
so many isolated files or directories in that 'other' file system.   On the other
hand, if we have some mechanism to make a file or directory avoid archiving,
it's very easy to maintain that tree by individual users.

The ovfs is for such purpose?

Kenji

Re: [9fans] hack for /usr/$user/lib/face

[Geoff Collyer]

ovfs was originally meant to allow overlaying of the contents of one
file server's main file system onto another one, but I can see plenty
of other uses for it.

I and everybody I've talked to about this says `Yeah, when I first
heard about Plan 9's binds, I assumed that they were recursive', thus
letting a user customise the system easily and extensively with
something like

	bind -b /usr/$user /

Maybe we're all dolts, but I think that something about the way binds
are explained sets people's expectations to be at odds with the
reality of bind's implementation.  Or maybe we just extrapolate what
appears to be an obvious extension (though of course it isn't, given
the implementation).

Re: [9fans] hack for /usr/$user/lib/face

[okamoto]

> I and everybody I've talked to about this says `Yeah, when I first
> heard about Plan 9's binds, I assumed that they were recursive', thus
> letting a user customise the system easily and extensively with
> something like
>
> 	bind -b /usr/$user /

I don't want all my personal mails are archived to venti, and something
other must be in the same situation.   Everybody has his/her peronal
matters in his/her home directory, and operating system should allow
this, I think.

Kenji

Re: [9fans] hack for /usr/$user/lib/face

[Geoff Collyer]

I've found it valuable to have mail archived.  If your mail is that
sensitive, perhaps you should be using PGP for it (and anything else
private).

Re: [9fans] hack for /usr/$user/lib/face

[okamoto]

> I've found it valuable to have mail archived.  If your mail is that
> sensitive, perhaps you should be using PGP for it (and anything else
> private).

No, I don't think so.
We could be able to select to archive or not by ourselves.
I know we can do it by making /usr/okamoto hieralchie
on other file system, and bind it if neccessary.   However,
It looks not so beautiful solution to me.

Kenji

[9fans] hack for /usr/$user/lib/face

[matt]

>>By the way, is there anyway to make some portion of the user's file
>> avoid from writing to venti, such those private or secret portrait
>>of someone. ☺  Of course, this should be set by that user, not 
>>system administrator.
>>  
>>
> 
> Put them on a different file server and bind them into your name space
> in your profile.

You could even write a script to download them from a web page and build your lib/face in a ramfs 


You can also choose to get rid of the
a/ b/ c/ d/ ... z/ folders, 
facesdb doesn't care about the directory names. It does a linear search through the .dict and then walks to $dir/$face

so in .dict
proweb.co.uk/matt 9fans/matt.1

works just fine

then you can 

bind -bc /n/ftp/secret_faces/9fans /usr/$user/lib/face/48x48x8/9fans

and keep a secret matt.1 on your ftp place

[9fans] hack for /usr/$user/lib/face

[matt]

>>By the way, is there anyway to make some portion of the user's file
>> avoid from writing to venti, such those private or secret portrait
>>of someone. ☺  Of course, this should be set by that user, not 
>>system administrator.
>>  
>>
> 
> Put them on a different file server and bind them into your name space
> in your profile.

You could even write a script to download them from a web page and build your lib/face in a ramfs 


You can also choose to get rid of the
a/ b/ c/ d/ ... z/ folders, 
facesdb doesn't care about the directory names. It does a linear search through the .dict and then walks to $dir/$face

so in .dict
proweb.co.uk/matt 9fans/matt.1

works just fine

then you can 

bind -bc /n/ftp/secret_faces/9fans /usr/$user/lib/face/48x48x8/9fans

and keep a secret matt.1 on your ftp place

[9fans] hack for /usr/$user/lib/face

[matt]

the bind is defeated by the .dict files

if you want to keep /lib/face in step with /n/sources/plan9/lib/face then once you have a replica of it you will have to rebuild your bound version of the .dict files


unless you know different?