Re: [9fans] Man pages for add-ons
On Sun, Mar 28, 2010 at 9:59 PM, Ethan Grammatikidis
wrote:
> On 29 Mar 2010, at 00:28, hiro wrote:
>>
>> Following your logic we must be one of the luckiest mailing list around
>
> I was speaking of lunix & co, on the basis that given enough additional apps
> & things the same problems will arise.
>
>> We use ls -t. It's better than git for your task.
>
>
> ...
>
> Surely not.
>
> ...
>
> Why didn't I think of that?
>
> ...
>
> Oh so if ls -lt in bin you see things grouped... the -l is important..
> yes... Oh when stuff is scattered through bin lib and other dirs you need ls
> -lt `{ find * } . Agh! Horrendous way-too-long-to-read output... I can pipe
> it into less -S and search. Wait, no less. That's fair enough, I can search
> in terminal... no search in terminal.
>
> Do not want to post "fail, feature needed." No contextual output from diff,
> and it would be a weak solution anyway. Perhaps some script to take the
> output from ls, pick the timestamp of a specified filename, and output only
> lines matching that timestamp. I could write that with only a little pain.
> :s Huh, I think we have a solution, but it's not just ls -t. ... And to
> simplify: rather than write a script I could ls -l a known file, snarf the
> timestamp, and ls -lt `{ find * } | grep . Well, that's bearable.
>
> I hope my stream of consciousness is readable, it's rather late here.
>
> Speaking of late, remember you should never let make install run at midnight
> (or it breaks the above solution).
>
since we are trying so hard to create new problems for Plan 9, should
i assume the old ones have all been solved?
iru
Re: [9fans] Man pages for add-ons
On 29 Mar 2010, at 00:28, hiro wrote:
Following your logic we must be one of the luckiest mailing list
around
I was speaking of lunix & co, on the basis that given enough
additional apps & things the same problems will arise.
We use ls -t. It's better than git for your task.
...
Surely not.
...
Why didn't I think of that?
...
Oh so if ls -lt in bin you see things grouped... the -l is important..
yes... Oh when stuff is scattered through bin lib and other dirs you
need ls -lt `{ find * } . Agh! Horrendous way-too-long-to-read
output... I can pipe it into less -S and search. Wait, no less. That's
fair enough, I can search in terminal... no search in terminal.
Do not want to post "fail, feature needed." No contextual output from
diff, and it would be a weak solution anyway. Perhaps some script to
take the output from ls, pick the timestamp of a specified filename,
and output only lines matching that timestamp. I could write that with
only a little pain. :s Huh, I think we have a solution, but it's not
just ls -t. ... And to simplify: rather than write a script I could ls
-l a known file, snarf the timestamp, and ls -lt `{ find * } | grep
. Well, that's bearable.
I hope my stream of consciousness is readable, it's rather late here.
Speaking of late, remember you should never let make install run at
midnight (or it breaks the above solution).
--
Simplicity does not precede complexity, but follows it. -- Alan Perlis
Re: [9fans] Man pages for add-ons
> will be a lot of binaries with names that just don't make sense or > correlate to anything. Good luck uninstalling a package or cleaning up > when you upgrade one and find the new version doesn't install all the > same files so you're left with, for example, stray header files which > could screw up future compiles. Actually I use git on /usr/local which > both gives me an uninstall option and (with some rather long options) > a list of files installed with each commit. "All" I have to do is > remember to commit after each make install. > > I don't know if history came up because venti could offer similar to > what I use git for, but that would only work if you installed only one > package per day. Now on Gnunix if you can get an app going with just > one package install you can call yourself lucky! replica already tracks files and allows for uninstall. - erik
Re: [9fans] quote o' the day
On 3/25/10, blstu...@bellsouth.net wrote:
> It's this kind of intellectual ugliness that makes the
> teacher in me hang my head in shame. How could
> we be managing to produce a whole generation of
> programmers who actually buy into that stuff? And
> it's not as if it's a fad that's getting better. If anything
> it's getting worse. Somehow we've made it laudible
> to go to any lengths to avoid writing a line of real
> code and to run as far away from hardware as we
> can. That and worship at the alter of "code reuse"
> have created a world where if one abstraction is
> good, then 432 must be better. If a symbol appears
> that's not defined in 17 different places all surrounded
> by #ifdef's, then that's not "professional." Everyone
> is afraid to point out the nudity of the XML monarch
> for fear of being branded as one afraid of change.
>
> I humbly extend my apologies for any of this that
> might have been promulgated by any of my former
> students :(
>
> \end{soapbox}
>
> BLS
>
>
>
Hurts! He wants to know if it hurts!
Re: [9fans] quote o' the day
Sorry if I'm feeding the troll, but... On 29 March 2010 00:05, Eris Discordia wrote: > 1. ... not comment their code? Comments lie. Code can't. Hence clarity of code is better than commented theses. > 2. ... not include usage instructions? $ man cat > 4. ... not include a preamble introducing their file, automatically assuming > they work in "clean environs" where nobody except people they know on a > face-to-face basis commits to their code repository? It can be identified by its filename. > 5. ... not accommodate their user base insisting they know better what's > good for the users thereby dramatically cutting down the number of people > who may want to merely use, and not hack, their code? Every user wants something different and incompatible. One cannot accomodate them all. > 6. ... forget to see past appearances in others' code instead of simply and > rationally counting the lines of code in the body of function 'simple_cat' > for a proper comparison of equivalent functionality between a feature-heavy > 'cat' and a minimalist 'cat' each with its own merits? A feature-heavy 'cat' has no merits beyond the minimalist 'cat'. If you want more features, write a new program. See: cat -v considered harmful. > 7. ... avoid provisioning for a time when 'coreutils,' in order to become > feature-heavy, will inevitably contain copious amount of code that needs to > be amenable to automated testing and documentation? See above. A program becoming feature-heavy is a failure in and of itself. Less is more. > 8. ... avoid any secondary optimization of their first solution under the > illusion that every optimization counts as the dreaded "premature > optimization?" Simplicity is more important than efficiency. Optimisation should only be done when there is an identifiable bottleneck. Cat has no such bottleneck that I'm aware of. > 9. ... condescendingly refuse to write or maintain code that is capable of > cooperation with a dominant archaic design which can only be phased out > gradually? Why does it have to be phased out gradually? The problems of Unix are too deep to fix. > 10. ... allow themselves to be flattered by agreement from the close-knit > community of like-minded developers fully shutting their minds close to the > potential merits of functionally rival software? If it's better for the system's users, it's better for the system's users. Again, sorry. cls
Re: [9fans] quote o' the day
On 3/29/10, Eris Discordia wrote: >> In fact, we have both printed on paper hanging from the wall of the >> corridor near our office. Let's hope they learn. > > Learn to... > > 1. ... not comment their code? > > 2. ... not include usage instructions? > > 3. ... not heed that their code might need to compile on any one of a > number of platforms that are far from glitch-free? > > 4. ... not include a preamble introducing their file, automatically > assuming they work in "clean environs" where nobody except people they know > on a face-to-face basis commits to their code repository? > > 5. ... not accommodate their user base insisting they know better what's > good for the users thereby dramatically cutting down the number of people > who may want to merely use, and not hack, their code? > > 6. ... forget to see past appearances in others' code instead of simply and > rationally counting the lines of code in the body of function 'simple_cat' > for a proper comparison of equivalent functionality between a feature-heavy > 'cat' and a minimalist 'cat' each with its own merits? > > 7. ... avoid provisioning for a time when 'coreutils,' in order to become > feature-heavy, will inevitably contain copious amount of code that needs to > be amenable to automated testing and documentation? > > 8. ... avoid any secondary optimization of their first solution under the > illusion that every optimization counts as the dreaded "premature > optimization?" > > 9. ... condescendingly refuse to write or maintain code that is capable of > cooperation with a dominant archaic design which can only be phased out > gradually? > > 10. ... allow themselves to be flattered by agreement from the close-knit > community of like-minded developers fully shutting their minds close to the > potential merits of functionally rival software? > > > Never mind my trolling. I just needed to attention-whore. Continue, please. > > > > --On Thursday, March 25, 2010 22:17 +0100 Francisco J Ballesteros > wrote: > >> As a example for our students we use >> >> http://git.savannah.gnu.org/gitweb/?p=coreutils.git;a=blob;f=src/cat.c;hb >> =HEAD >> >> versus >> >> http://plan9.bell-labs.com/sources/plan9/sys/src/cmd/cat.c >> >> In fact, we have both printed on paper hanging from the wall of the >> corridor near our office. Let's hope they learn. >> >> >> On Thu, Mar 25, 2010 at 7:51 PM, wrote: in similar vein, there's this handful guide on how to make your life really hard in 11 easy steps: http://www.pixelbeat.org/docs/unix_file_replacement.html make sure you check out the final copy.c linked at the bottom of the page >>> >>> It's a sign of the apocalypse. The configuration of the 6th edition >>> kernel Lions presented was about 10,000 lines of code. This version >>> of cp is nearly 1/4 of that, and the function copy_internal() is over >>> 1000 lines long. I'm clearly not smart enough to function in a world >>> where cp is that complex... >>> >>> Back to real work...again...for real this time...I promise... >>> BLS >>> >>> >>> >> > > > > > > Without reading your post: No, just ... that sometimes less is more.
Re: [9fans] Man pages for add-ons
Following your logic we must be one of the luckiest mailing list around. We use ls -t. It's better than git for your task. On 3/29/10, Ethan Grammatikidis wrote: > On 28 Mar 2010, at 20:36, Federico G. Benavento wrote: >> I think it all comes down to simplicity, you install the app, you >> run the >> app, it looks like some of you would like to add complexity just >> because >> you think it's the right thing to do. > > > Well.. it's experience with Linux (and, I suppose, BSD). If you > install stuff from source it's not long before you almost have no idea > what's in /usr/local. You might remember what you installed, but there > will be a lot of binaries with names that just don't make sense or > correlate to anything. Good luck uninstalling a package or cleaning up > when you upgrade one and find the new version doesn't install all the > same files so you're left with, for example, stray header files which > could screw up future compiles. Actually I use git on /usr/local which > both gives me an uninstall option and (with some rather long options) > a list of files installed with each commit. "All" I have to do is > remember to commit after each make install. > > I don't know if history came up because venti could offer similar to > what I use git for, but that would only work if you installed only one > package per day. Now on Gnunix if you can get an app going with just > one package install you can call yourself lucky! > > -- > Simplicity does not precede complexity, but follows it. > -- Alan Perlis > > > > > >
Re: [9fans] quote o' the day
On Fri, Mar 26, 2010 at 5:54 AM, andrey mirtchovski wrote: > try as you might, the irony is unescapable (see the attached "helpful" > suggestion by google). It sounds like a competition. "Write a program that, when translated by Google into Czech, still produces valid output." -Jack
Re: [9fans] quote o' the day
In fact, we have both printed on paper hanging from the wall of the corridor near our office. Let's hope they learn. Learn to... 1. ... not comment their code? 2. ... not include usage instructions? 3. ... not heed that their code might need to compile on any one of a number of platforms that are far from glitch-free? 4. ... not include a preamble introducing their file, automatically assuming they work in "clean environs" where nobody except people they know on a face-to-face basis commits to their code repository? 5. ... not accommodate their user base insisting they know better what's good for the users thereby dramatically cutting down the number of people who may want to merely use, and not hack, their code? 6. ... forget to see past appearances in others' code instead of simply and rationally counting the lines of code in the body of function 'simple_cat' for a proper comparison of equivalent functionality between a feature-heavy 'cat' and a minimalist 'cat' each with its own merits? 7. ... avoid provisioning for a time when 'coreutils,' in order to become feature-heavy, will inevitably contain copious amount of code that needs to be amenable to automated testing and documentation? 8. ... avoid any secondary optimization of their first solution under the illusion that every optimization counts as the dreaded "premature optimization?" 9. ... condescendingly refuse to write or maintain code that is capable of cooperation with a dominant archaic design which can only be phased out gradually? 10. ... allow themselves to be flattered by agreement from the close-knit community of like-minded developers fully shutting their minds close to the potential merits of functionally rival software? Never mind my trolling. I just needed to attention-whore. Continue, please. --On Thursday, March 25, 2010 22:17 +0100 Francisco J Ballesteros wrote: As a example for our students we use http://git.savannah.gnu.org/gitweb/?p=coreutils.git;a=blob;f=src/cat.c;hb =HEAD versus http://plan9.bell-labs.com/sources/plan9/sys/src/cmd/cat.c In fact, we have both printed on paper hanging from the wall of the corridor near our office. Let's hope they learn. On Thu, Mar 25, 2010 at 7:51 PM, wrote: in similar vein, there's this handful guide on how to make your life really hard in 11 easy steps: http://www.pixelbeat.org/docs/unix_file_replacement.html make sure you check out the final copy.c linked at the bottom of the page It's a sign of the apocalypse. The configuration of the 6th edition kernel Lions presented was about 10,000 lines of code. This version of cp is nearly 1/4 of that, and the function copy_internal() is over 1000 lines long. I'm clearly not smart enough to function in a world where cp is that complex... Back to real work...again...for real this time...I promise... BLS
Re: [9fans] Man pages for add-ons
On 28 Mar 2010, at 20:36, Federico G. Benavento wrote: I think it all comes down to simplicity, you install the app, you run the app, it looks like some of you would like to add complexity just because you think it's the right thing to do. Well.. it's experience with Linux (and, I suppose, BSD). If you install stuff from source it's not long before you almost have no idea what's in /usr/local. You might remember what you installed, but there will be a lot of binaries with names that just don't make sense or correlate to anything. Good luck uninstalling a package or cleaning up when you upgrade one and find the new version doesn't install all the same files so you're left with, for example, stray header files which could screw up future compiles. Actually I use git on /usr/local which both gives me an uninstall option and (with some rather long options) a list of files installed with each commit. "All" I have to do is remember to commit after each make install. I don't know if history came up because venti could offer similar to what I use git for, but that would only work if you installed only one package per day. Now on Gnunix if you can get an app going with just one package install you can call yourself lucky! -- Simplicity does not precede complexity, but follows it. -- Alan Perlis
Re: [9fans] Man pages for add-ons
On Fri, Mar 26, 2010 at 08:21:02PM +, Ethan Grammatikidis wrote: > I'm thinking over the idea that we're bumping up against the practical > limits of hierarchal file systems as a means for organising stuff, but > I've no idea what else might work. I think most of you are making up problems and complicated situations that haven't happened (and probably won't happen) yet. -- I am a man who does not exist for others. pgpdTI1x6BX8V.pgp Description: PGP signature
Re: [9fans] Man pages for add-ons
> All this reminds me of one of my biggest gripes with unix, which may > be relevant to the discussion here. Both env vars and namespaces are > inherited, and while that's a strength it's also a weakness. I haven't > used Plan 9 enough to know if it's a problem for Plan 9, but using [...] > Perhaps if namespace changes only require restarting the plumber it > wouldn't be bad, but there's still the matter of entering the binds at > least twice too; once in lib/profile (which you have to go and open) > and once per relevant terminal window. if you have included basic in your plumbing rules, the plumbing "Local 9fs sources" will make /n/sources available to all newly started processes. acme interprets a string of the same format. so it's not even necessary to restart the plumber. likewise, you can plumb "Local echo -n someval > /env/somevar". - erik
Re: [9fans] Man pages for add-ons
> another concern I have is where are you going to put 3rd party drivers > a new location is going to be created, probably a directory per 3rd > party driver, when all this ends? i don't think this is on point, but since your brought it up, i run into a related problem all the time. how to organize stuff that clearly doesn't belong in the distribution, like experimental network stacks, etc. (i keep all the normal stuff like network drivers in the usual places.) what i settled on was a tiny little script ../port/dirdep which allows one to specify a "dir" section in the kernel config. one line of support was added in ../pc/mkfile. the script includes ../$dir/mkfrag if it exists so that all the add-hoc rules one needs can be included. this way you can build a kernel with, say, an xns stack, without major upheaval in ../pc/mkfile and you can build devices and whatnot directly from the included directory. - erik
Re: [9fans] Man pages for add-ons
I don't know how this search tangent come into play, but in Plan 9 I don't search for files as I already do know where they are. I just search for stuff inside those files which is trivial as, like I said, I already know where the files are. I certainly don't like the gnu crap of having a directory per application, in my opinion, it just complicates things. I don't use any lunix, so correct me if I got this wrong, the /opt thing it's just a lie, yes, you have the package in /opt, but you also have a wrapper script to launch that app in a known location like /usr/bin I think it all comes down to simplicity, you install the app, you run the app, it looks like some of you would like to add complexity just because you think it's the right thing to do. another concern I have is where are you going to put 3rd party drivers a new location is going to be created, probably a directory per 3rd party driver, when all this ends? On Sun, Mar 28, 2010 at 4:06 PM, Ethan Grammatikidis wrote: > On 27 Mar 2010, at 16:54, erik quanstrom wrote: I'm thinking over the idea that we're bumping up against the practical limits of hierarchal file systems as a means for organising stuff, but I've no idea what else might work. >>> >>> Google's approach is not to bother sorting things out. Use searches >>> to find data you want. You can still do some sorting in things like >>> gmail, but you don't need to. >> >> what google uses for its search tables or custom applications >> might not be that interesting in the context of a general purpose >> operating system. > > Yeah... I'm using OS X and I'm not impressed with its Spotlight filesystem > search, yet. It's just too general. > > -- > Simplicity does not precede complexity, but follows it. > -- Alan Perlis > > > > > > -- Federico G. Benavento
Re: [9fans] Man pages for add-ons
On 27 Mar 2010, at 16:54, erik quanstrom wrote: I'm thinking over the idea that we're bumping up against the practical limits of hierarchal file systems as a means for organising stuff, but I've no idea what else might work. Google's approach is not to bother sorting things out. Use searches to find data you want. You can still do some sorting in things like gmail, but you don't need to. what google uses for its search tables or custom applications might not be that interesting in the context of a general purpose operating system. Yeah... I'm using OS X and I'm not impressed with its Spotlight filesystem search, yet. It's just too general. -- Simplicity does not precede complexity, but follows it. -- Alan Perlis
Re: [9fans] Man pages for add-ons
On 27 Mar 2010, at 16:46, Tim Newsham wrote: enough. We say we deal with it with namespaces, but the bindings on a freshly-installed Plan 9 box already make a much longer list than any $PATH I can imagine! but you don't have a LD_LIBRARY_PATH, a MANPTH, or any number of other search paths. Or symlinks. What is the total length of all of your paths plus symlinks? PATHs on my box (including MANPATH and INFOPATH) total 27 entries. Symlinks, excluding libraries, Wine, and backups of old systems: 1, for a total of 28. Wine has 17 symlinks but what I do with Wine could almost as easily be done with a VM. There are 42 binds and mounts in my Plan 9 VM's namespace, but several seem to be no-ops (bind / /; bind /n /n), and it's a bit hard to filter out both those and the hardware and system mounts from the list. The number of functional dir-to-dir binds seems to be around 7. I feel like I'm missing something. Adding the number of mounts on my un*x box brings its total to 36, still lower than Plan 9's. All this reminds me of one of my biggest gripes with unix, which may be relevant to the discussion here. Both env vars and namespaces are inherited, and while that's a strength it's also a weakness. I haven't used Plan 9 enough to know if it's a problem for Plan 9, but using Linux outside the wonderful world of desktop environments I would regularly run into trouble because I'd have to change a variable, whether $BROWSER or $PATH or whatever, and for it to take full effect I'd have to log out & back in. I always have several things on the go at once: typically a couple dozen web pages open; several files of one sort or another; IRC and frequently another communication program; mail; a calendar; often a music player; you get the picture. In such an environment "re-logging" is a huge disruption. Perhaps if namespace changes only require restarting the plumber it wouldn't be bad, but there's still the matter of entering the binds at least twice too; once in lib/profile (which you have to go and open) and once per relevant terminal window. -- Simplicity does not precede complexity, but follows it. -- Alan Perlis
Re: [9fans] Man pages for add-ons: pax?
Wow, I really don't get that grammar. Could you perhaps sketch up some UML-diagram to make yourself clear? Or is it just my bad English? And again my question: do you guys actually try to fix an existing problem or are you making one up for scientific reasons? On 3/28/10, tlaro...@polynum.com wrote: > From the diverse input, wouldn't it be more logical to do the following: > > 1) All "contrib" packages write in /$objtype/bin, /rc/bin and /sys/man > (or /man, see 3). > > 2) It's up the user to "bind -c" in /$objtype/bin, /rc/bin and > /sys/man so that written files end where he wants. Depending on who > installs, so depending on the namespace, all flavors can be achieved > (system wide or individual). > > 3) Shouldn't /man and /rc/bin be, as /bin, "empty unwritable directories, > place holders", with an initial bind(1) (without "-c"; probably > $objtype agnostic either, since almost all programs are supposed to > exist in an $objtype flavor for man, and should not be a concern for rc) > of /sys/man and (new) /sys/rc/bin there? > > Note: in this scheme /rc/bin is more a mean (an undirection) so that rc > programs end in the correct place than something usefull at use time, > since it ends probably bind'ed in /bin. > -- > Thierry Laronde (Alceste) > http://www.kergis.com/ > Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C > >
Re: [9fans] native install
> 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
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] interesting qemu problem
ron minnich wrote: [..] I don't see why venti has gotten so memory hungry, this seems new behavior. I realize I can twist the knobs myself but geez, this is a 4 GB disk -- why does it think it needs nearly 400 MB RSS to deal with it? ron Please note that quite a lot of installation problems mentioned recently on the mailing list have been related to venti beeing very memory hungry. Without beeing able to contribute technically to a solution i propose to mitigate it by adding support for setting up venti parameters in the installation scripts, or by setting safe values by default and leave performance tweeking to the experienced. Regards, Jorge-León
Re: [9fans] more little hardware
Jack Johnson wrote: Thanks to Google's targeted ads: http://www.eglobalwireless.com/p-4333-new-7-mini-netbook-laptop-notebook-wifi-windows-2gb-hd.aspx Also might make a good Inferno device if WinCE isn't too firmly ensconced. -Jack Anybody interested in porting Inferno emu to WinCE? It should not be hard to do, and the tools are available for free. I could contribute some knowledge and ressources, though not much time. WinCE allows to replace the Windows Shell with something else via a simple registry setting ( targetting e.g. Mobile Phones with WinCE already installed). A lot of commercially evaluation boards provide WinCE board support packages which would allow one to create a new OS-Image with everything but the WinCE kernel stripped out and include inferno emu as "GUI-shell". Porting Plan9 from user space seems somewhat more involved to me (threads and graphics) while an Inferno emu for (Desktop) Windows already exists (and should require little porting effort to WinCE APIs). Regards, Jorge-León
Re: [9fans] native install
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] Man pages for add-ons: pax?
> 3) Shouldn't /man and /rc/bin be, as /bin, "empty unwritable directories, > place holders", with an initial bind(1) (without "-c"; probably > $objtype agnostic either, since almost all programs are supposed to > exist in an $objtype flavor for man, and should not be a concern for rc) > of /sys/man and (new) /sys/rc/bin there? one would need a place for the index files and the extra stuff at the top level. - erik
Re: [9fans] Man pages for add-ons: pax?
>From the diverse input, wouldn't it be more logical to do the following: 1) All "contrib" packages write in /$objtype/bin, /rc/bin and /sys/man (or /man, see 3). 2) It's up the user to "bind -c" in /$objtype/bin, /rc/bin and /sys/man so that written files end where he wants. Depending on who installs, so depending on the namespace, all flavors can be achieved (system wide or individual). 3) Shouldn't /man and /rc/bin be, as /bin, "empty unwritable directories, place holders", with an initial bind(1) (without "-c"; probably $objtype agnostic either, since almost all programs are supposed to exist in an $objtype flavor for man, and should not be a concern for rc) of /sys/man and (new) /sys/rc/bin there? Note: in this scheme /rc/bin is more a mean (an undirection) so that rc programs end in the correct place than something usefull at use time, since it ends probably bind'ed in /bin. -- Thierry Laronde (Alceste) http://www.kergis.com/ Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C
