[9fans] Man pages for add-ons

[9fans] Man pages for add-ons

[tlaronde]

Hello,

Since I can finally find some time here and there, I'm back to TeX and
al.

>From namespace(4), the man pages are supposed to be under /sys/man.

What is the canonical way for added ("opt", "pkg" ?) stuff. Letting
the user adapt his profile to bind the added stuff he wants appearing in
his namespace?

More generally, what is the policy for add-ons? Providing rc(1)
fragments to bind the added stuff?

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

Re: [9fans] Man pages for add-ons

[erik quanstrom]

>  From namespace(4), the man pages are supposed to be under /sys/man.

the old tex put the man pages (both of them) in /sys/man/1pub.
one could just as easily put them in /sys/man/1.

> What is the canonical way for added ("opt", "pkg" ?) stuff. Letting
> the user adapt his profile to bind the added stuff he wants appearing in
> his namespace?

i hope we don't reinvent the 1000 bin directories of unix.  it's all
so cute having /bin /usr/bin /sbin /usr/sbin /usr/local/bin /opt/$fu/bin.
but ever so useless.  i have been on systems where the fact that
/usr/yp/bin (or whatever it was) wasn't in the default path was used
as a "security" mechanism.  but that points to the real problem.
it's just too archane an alchemy for users to remember.

i vote for putting the binaries in /$objtype/bin or /$objtype/bin/tex.
in the latter case, it would be tex/tex or tex/mf.

- erik

Re: [9fans] Man pages for add-ons

[tlaronde]

On Thu, Mar 25, 2010 at 09:37:15AM -0400, erik quanstrom wrote:
>
> i vote for putting the binaries in /$objtype/bin or /$objtype/bin/tex.
> in the latter case, it would be tex/tex or tex/mf.

I'm inclined to this kind of stuff too, since it's easy to "rm -fr" if
everything is simply in the same place.

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

Re: [9fans] Man pages for add-ons

[erik quanstrom]

> I'm inclined to this kind of stuff too, since it's easy to "rm -fr" if
> everything is simply in the same place.

replica should make such concerns moot.

- erik

Re: [9fans] Man pages for add-ons

[EBo]

erik quanstrom <quanstro@quanstro.net> said:

> > I'm inclined to this kind of stuff too, since it's easy to "rm -fr" if
> > everything is simply in the same place.
>
> replica should make such concerns moot.

I've taken a quick look at the docs, but it is intended to be a per-package
management tool?  Typically my concerns are setting up canonical
versions/'dates which are known to be stable so testing can be done on
multiple known code revisions.  How does one do that with replica?


  EBo --

Re: [9fans] Man pages for add-ons

[Steve Simon]

>> i vote for putting the binaries in /$objtype/bin or /$objtype/bin/tex.
>> in the latter case, it would be tex/tex or tex/mf.

> I'm inclined to this kind of stuff too, since it's easy to "rm -fr" if
> everything is simply in the same place.

I assume you mean /$objtype/bin/tex, this looks a good fit to me too,
however if you use contrib then you can just do:

	contrib/remove tex

which will print commands to remove exactly the files that
where installed, unless they have changed in which case it will
print a commented out command (i.e. if another package overwrote
and updated a shared file).

-Steve

Re: [9fans] Man pages for add-ons

[lucio]

> i vote for putting the binaries in /$objtype/bin or /$objtype/bin/tex.
> in the latter case, it would be tex/tex or tex/mf.

Ideal most of the time, but I have this gut feeling that one ought to
keep utilities distinct if they are not part of the distribution.  At
minimum they make it easier when rebuilding the system to remember
what one has added.  It's easy enough to bind /386/pub to /bin, but it
would be nice if there was a firm convention; /386/bin is pretty firm.

Judgement call, I guess.

++L

Re: [9fans] Man pages for add-ons

[Tim Newsham]

>> i vote for putting the binaries in /$objtype/bin or /$objtype/bin/tex.
>> in the latter case, it would be tex/tex or tex/mf.
>
> Ideal most of the time, but I have this gut feeling that one ought to
> keep utilities distinct if they are not part of the distribution.  At
> minimum they make it easier when rebuilding the system to remember
> what one has added.  It's easy enough to bind /386/pub to /bin, but it
> would be nice if there was a firm convention; /386/bin is pretty firm.

Bind your own directory on /bin with the creation flag set?

I don't see why the package system or package author should
choose where to put the files if they can let the user choose
for themselves.

> ++L

Tim Newsham | www.thenewsh.com/~newsham | thenewsh.blogspot.com

Re: [9fans] Man pages for add-ons

[lucio]

> Bind your own directory on /bin with the creation flag set?
>
Nice idea, I like it.

> I don't see why the package system or package author should
> choose where to put the files if they can let the user choose
> for themselves.

I guess I'm not leadership material: I keep looking for somebody to
lay down rules I don't have a visceral negative reaction to.

++L

Re: [9fans] Man pages for add-ons

[erik quanstrom]

On Thu Mar 25 15:39:43 EDT 2010, lucio@proxima.alt.za wrote:
> > Bind your own directory on /bin with the creation flag set?
> >
> Nice idea, I like it.

on the other hand, doing this on a per-package basis
could quickly lead to chaos.  to avoid this a whole set
of standards would likely be created on how where
you put things.  which puts us right back at square one.

- erik

Re: [9fans] Man pages for add-ons

[EBo]

> i vote for putting the binaries in /$objtype/bin or /$objtype/bin/tex.
> in the latter case, it would be tex/tex or tex/mf.

I'm a total plan9 newbie, but I hate polluting / with every single
application.  I do prefer to have all apps in a single package directory
/$some_dir/$objtype/bin  where $some_dir is /opt, /pkg, /contrib, etc.  I do
not know if this would fit in well with the plan9 way though...

Re: [9fans] Man pages for add-ons

[Jacob Todd]

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

On Thu, Mar 25, 2010 at 06:52:02PM -0600, EBo wrote:
> 
> > i vote for putting the binaries in /$objtype/bin or /$objtype/bin/tex.
> > in the latter case, it would be tex/tex or tex/mf.
> 
> I'm a total plan9 newbie, but I hate polluting / with every single
> application.  I do prefer to have all apps in a single package directory 
> /$some_dir/$objtype/bin  where $some_dir is /opt, /pkg, /contrib, etc.  I do
> not know if this would fit in well with the plan9 way though...
> 
You wouldn't be `polluting' / with every single application. Binaries would
either go in $user/bin and would be then be bind-ed to /bin, or binaries would
just go in /$objtype/bin. No `pollution' here.

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

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

Re: [9fans] Man pages for add-ons

[ron minnich]

having just gone through this process once, I've found I would much
rather leave / untouched by human hands, and put my additional  bits
in /usr/rminnich and bind it over to where it needs to go.

But then I run mostly single-user machines.

ron

Re: [9fans] Man pages for add-ons

[EBo]

> > I'm a total plan9 newbie, but I hate polluting / with every single
> > application.  I do prefer to have all apps in a single package directory
> > /$some_dir/$objtype/bin  where $some_dir is /opt, /pkg, /contrib, etc.  I do
> > not know if this would fit in well with the plan9 way though...
> >
> You wouldn't be `polluting' / with every single application. Binaries would
> either go in $user/bin and would be then be bind-ed to /bin, or binaries would
> just go in /$objtype/bin. No `pollution' here.

Following on what Ron said earlier, I prefer to leave / untouched.  If
programs are installed into /$app_name/..., you end up with variants of
/acme/*, /rc/*, /tex/*, /troff/*, /tex/*, /my_fav_pub_app/...  That is what I
meant by pollution.  Do you consider this desirable?  Maybe we are talking
apples and oranges here.  I'm also talking about system wide apps on a
multiuser system.  So, for example, your /$objtype/bin would look something
like /sys_apps/$objtype/bin, and /sys_aps would contain all system wide,
non-OS distributed, applications.

Hope I have not offended here.

  EBo --

Re: [9fans] Man pages for add-ons

[Federico G. Benavento]

ok, what about libraries, are you going to add a new place for included
files or have a script that sets the namespace for every library a
program you want to compile needs?

think about python for instances, it's needs zlib, bzip2, openssl and
it couldn't depend even on more stuff (like libxml, sqlite, curses,
etc), but I tried
to keep it simple, but usable and then you also have the configuration
files, binds are find, but you need a big amount of them to get something
going....

in the end you have to think in the actual usage.

I chose to "pollute" /sys/src/cmd with non standard packages for all of
the above reasons and some that don't come to my mind right now.

but there was the precedent of the .iso.bz2 packages like perl, TeX,
python, even the old X11 port.

contrib allows -r to choose the root so you can live without "polluting"
/, but then you have to work your bind magic, do it and tell me
how it goes when you want to run configure to port something


--
Federico G. Benavento

Re: [9fans] Man pages for add-ons

[erik quanstrom]

> ok, what about libraries, are you going to add a new place for included
> files or have a script that sets the namespace for every library a
> program you want to compile needs?
>
> think about python for instances, it's needs zlib, bzip2, openssl and
> it couldn't depend even on more stuff (like libxml, sqlite, curses,
> etc), but I tried
> to keep it simple, but usable and then you also have the configuration
> files, binds are find, but you need a big amount of them to get something
> going....
>
> in the end you have to think in the actual usage.
>
> I chose to "pollute" /sys/src/cmd with non standard packages for all of
> the above reasons and some that don't come to my mind right now.

+1.  anyone who suggests a recursive union directory
as a solution needs a "talk", and a good read of
http://lwn.net/Articles/325369/
warning.  the author doesn't completely understand qids. nor
the implications of unions on the uniqueness of
qid.path.

- erik

Re: [9fans] Man pages for add-ons

[Anthony Sorace]

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

	Unix has two camps for approaching this problem /usr/local and /opt.
While they're almost never followed well on modern unix systems, the
idea is basically a global local overlay vs. a per-package overlay.

	The /usr/local approach takes all packages not part of the base
system and creates a "local root", a global mirror of (roughly) the
root file system. Those poor souls don't have bind to work with, so
everything ends up "knowing" to look in /bin and /usr/local/bin, /etc
and /usr/local/etc, and so on. Packages from multiple sources are all
intermixed in one /usr/local, so you've basically got the base system
vs. everything else. EBo's /sys_aps is basically a recreation of /usr/
local.

	The /opt model creates per-package trees under /opt, for example /opt/
SomePackage. Within, it gets a similar looking overlay, but specific
to that package. It's then up to the user or site admin to determine
which packages get installed. Based on a similar (but much shorter)
conversation on inferno-list, a few of us are trying out this model
for third-party packages within Inferno.

	The Plan 9 approach today is either install everything in / (/386/
bin, /sys/include, &c) or in your personal home dir and bind as
needed. The later is irritating on multi-user systems, and the former
can make maintenance a lot harder. Replica's -c and -s help, but it
still requires more vigilance from the admin than it seems like it
ought to.

	Personally, I've always preferred the /opt model, as it makes it
easier to tell at a glance what's installed and to work with
components individually. The (non-)overlay can get unwieldy on Unix,
but our namespaces make that much easier for us. It also give both
admins and users package-level control over what gets included.

	Like I said, I and a few others have started playing with this in
Inferno. If it works reasonably there, I intend to try something
similar in Plan 9. Anyone likes to beat me to it, I'd love to hear
about your results.

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

Re: [9fans] Man pages for add-ons

[Federico G. Benavento]

I think it also needs to be noticed that "base system" in lunixes implies
a huge a mount of stuff

On Fri, Mar 26, 2010 at 2:59 AM, Anthony Sorace <a@9srv.net> wrote:
>        Unix has two camps for approaching this problem /usr/local and /opt.
> While they're almost never followed well on modern unix systems, the idea is
> basically a global local overlay vs. a per-package overlay.
>
>        The /usr/local approach takes all packages not part of the base
> system and creates a "local root", a global mirror of (roughly) the root
> file system. Those poor souls don't have bind to work with, so everything
> ends up "knowing" to look in /bin and /usr/local/bin, /etc and
> /usr/local/etc, and so on. Packages from multiple sources are all intermixed
> in one /usr/local, so you've basically got the base system vs. everything
> else. EBo's /sys_aps is basically a recreation of /usr/local.
>
>        The /opt model creates per-package trees under /opt, for example
> /opt/SomePackage. Within, it gets a similar looking overlay, but specific to
> that package. It's then up to the user or site admin to determine which
> packages get installed. Based on a similar (but much shorter) conversation
> on inferno-list, a few of us are trying out this model for third-party
> packages within Inferno.
>
>        The Plan 9 approach today is either install everything in /
> (/386/bin, /sys/include, &c) or in your personal home dir and bind as
> needed. The later is irritating on multi-user systems, and the former can
> make maintenance a lot harder. Replica's -c and -s help, but it still
> requires more vigilance from the admin than it seems like it ought to.
>
>        Personally, I've always preferred the /opt model, as it makes it
> easier to tell at a glance what's installed and to work with components
> individually. The (non-)overlay can get unwieldy on Unix, but our namespaces
> make that much easier for us. It also give both admins and users
> package-level control over what gets included.
>
>        Like I said, I and a few others have started playing with this in
> Inferno. If it works reasonably there, I intend to try something similar in
> Plan 9. Anyone likes to beat me to it, I'd love to hear about your results.
>



-- 
Federico G. Benavento

Re: [9fans] Man pages for add-ons

[EBo]

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

> 	Unix has two camps for approaching this problem /usr/local and /opt.
> While they're almost never followed well on modern unix systems, the
> idea is basically a global local overlay vs. a per-package overlay.
>
> 	The /usr/local approach takes all packages not part of the base
> system and creates a "local root", a global mirror of (roughly) the
> root file system. Those poor souls don't have bind to work with, so
> everything ends up "knowing" to look in /bin and /usr/local/bin, /etc
> and /usr/local/etc, and so on. Packages from multiple sources are all
> intermixed in one /usr/local, so you've basically got the base system
> vs. everything else. EBo's /sys_aps is basically a recreation of /usr/
> local.
>
> ...

Actually no.  I am advocating for the /opt (per-package) model.  Sorry that
was not clear.  I simply called it sys_apps in an attempt to make it clear
that I was talking about installed system wide apps.  Sorry for not being clearer.

  EBo --

Re: [9fans] Man pages for add-ons

[Federico G. Benavento]

other thing that deserves noticing is that there are 2 kind of needs
for packages, some people want to develop or like knowing what's
going on, so replica works for us as we get to see what files were
modified and when.

contrib(1) was written with this kind of user in mind, try to convince
erik to drop replica and you'll hear the justifications :)

on the other hand you people that don't care about the source and
just want to run their apps, for those a package system that with
only runtime stuff makes more sense.


on lunixes you have binary packages and then you use svn/hg/whatever
to get the source and get synced.

to me this is the real question, not where do we put the binaries, the latter
is just a convention and taste related, while the first is an actual problem
for some.


--
Federico G. Benavento

Re: [9fans] Man pages for add-ons

[EBo]

"Federico G. Benavento" <benavento@gmail.com> said:

> other thing that deserves noticing is that there are 2 kind of needs
> for packages, some people want to develop or like knowing what's
> going on, so replica works for us as we get to see what files were
> modified and when.
>
> contrib(1) was written with this kind of user in mind, try to convince
> erik to drop replica and you'll hear the justifications :)

;-) I'm learning more about these things all the time.

> on the other hand you people that don't care about the source and
> just want to run their apps, for those a package system that with
> only runtime stuff makes more sense.

I see this as a little more complicated for two reasons.  1) administrating
distributed systems with group supplied applications that are widely used but
not part of the OS, and 2) maintenance and development cycles.  How do you
propose managing the source/executables for ver 1.* (stable) 2.* (stable), 2.*
(experimental), and maybe even 1.* (backport)?  Even for my personal stuff I
have had lack of versioning bite me -- I was working on a spatially-explicit
modeling project, and had made some updates.  One of the ecologists came in
and asked me for some data which was not generated in the original modeling
runs, so I added it... only to find that the new version of could not read the
old input...  Took days to reconstruct everything.  To make matters worse,
this was in response to a review in a good journal, so time was of the
essence.  So, in this case I had maybe 20 users at 6 universities in 3
countries running at least two incompatible versions.  When I talk to these
people I needed to know which they were using, and fix any bugs for the
appropriate version.  I cannot expect them to stop what they are doing and
simply upgrade at my whim.  I should also note that it often takes 1.5 to 5
years from the start of an ecological field project to when it is published.
So, users might be using a given version of software for years before they
complete their projects.

As a note, I do not care how these things are accomplished, only that I can.
It may be that there are ways (replica & contrib) which allow for this level
of control, but I have yet to figure it out.

> on lunixes you have binary packages and then you use svn/hg/whatever
> to get the source and get synced.
>
> to me this is the real question, not where do we put the binaries,
> the latter is just a convention and taste related, while the first
> is an actual problem for some.

I see this as another very important, but separate, issue.

  EBo --

Re: [9fans] Man pages for add-ons

[erik quanstrom]

> I see this as a little more complicated for two reasons.  1) administrating
> distributed systems with group supplied applications that are widely used but
> not part of the OS,

one of the key bits of plan 9 is that the fileserver has always been a
network fileserver.  at coraid we have ~35 plan 9 machines in athens
(including testing, &c) and one fileserver.

> and 2) maintenance and development cycles.  How do you
> propose managing the source/executables for ver 1.* (stable) 2.* (stable), 2.*
> (experimental), and maybe even 1.* (backport)?

we don't do that.  you're supposing more testing cycles than there are
development cycles for plan 9.

> Even for my personal stuff I
> have had lack of versioning bite me -- I was working on a spatially-explicit
> modeling project, and had made some updates.  One of the ecologists came in
> and asked me for some data which was not generated in the original modeling
> runs, so I added it... only to find that the new version of could not read the
> old input...  Took days to reconstruct everything.

another key tenent of the plan 9 world is the dump filesystem.
i run ken's fileservers so i speak to that.  each day, a "dump" of
the filesystem is taken.  that dump is a read-only archive.  modern
lingo for such a beast might be a "persistent snapshot".  these are
never erased.  see bind(1) and history(1) for interesting applications.
using fossil+venti is the same except you can also have ephemerial
snapshots and the dump schedule is more flexible.

while this is not version control, it works so well that almost nobody
bothers with actual version control.  i feel really vulnerable on
linux without the dump.

> To make matters worse,
> this was in response to a review in a good journal, so time was of the
> essence.  So, in this case I had maybe 20 users at 6 universities in 3
> countries running at least two incompatible versions.  When I talk to these
> people I needed to know which they were using, and fix any bugs for the
> appropriate version.  I cannot expect them to stop what they are doing and
> simply upgrade at my whim.  I should also note that it often takes 1.5 to 5
> years from the start of an ecological field project to when it is published.
> So, users might be using a given version of software for years before they
> complete their projects.

the plan 9 model is different.  it's the one true version model.
great care is taken in development to avoid creating regressions.
so the extra work of maintaing many versions is avoided.  it may
not work for you, but give it a try before you say it doesn't work.

- erik

Re: [9fans] Man pages for add-ons

[erik quanstrom]

> 	The Plan 9 approach today is either install everything in / (/386/
> bin, /sys/include, &c) or in your personal home dir and bind as
> needed. The later is irritating on multi-user systems, and the former
> can make maintenance a lot harder. Replica's -c and -s help, but it
> still requires more vigilance from the admin than it seems like it
> ought to.

could you give an example?

- erik

Re: [9fans] Man pages for add-ons

[Lyndon Nerenberg (VE6BBM/VE7TFX)]

You're making this way more complicated than it needs to be.

For 3rd party stuff, I put the source tree in /usr/lyndon/src/<foo>,
adjust the mkfiles to install in /usr/lyndon/bin/$objtype, and say
'mk install'. I keep a shadow man tree under /usr/lyndon/lib/man,
and then bind it all on top of the system directories:

bind -a $home/bin/rc		/bin
bind -a $home/bin/rcaux		/bin/aux
bind -a $home/bin/$cputype	/bin
bind -a $home/lib/man/1		/sys/man/1
bind -a $home/lib/man/2		/sys/man/2
bind -a $home/lib/man/3		/sys/man/3
bind -a $home/lib/man/4		/sys/man/4
bind -a $home/lib/man/5		/sys/man/5
bind -a $home/lib/man/6		/sys/man/6
bind -a $home/lib/man/7		/sys/man/7
bind -a $home/lib/man/8		/sys/man/8

(I use this for contrib packages as well, after getting burned a few
times with contrib stuff breaking builds in /sys/src.  Rather than
use the package tool I copy the sources into $home/src and build as
above.  The extra work is minimal.)

If you need to distinguish between your own and site-wide 3rd-party
bits, create a new user to own the public 3rd party code, mirror the
above structure, and do the appropriate binds in the system-wide
namespace files.

The only time I contemplate using a /bin/<foo> subdirectory is when
there are significant command name collisions.  Over the last 10+
years it's only happened to me once.  It's almost always easier to
just rename the conflicting file.

To use Plan 9 properly you must understand what namespaces provide,
and how to manipulate them.

--lyndon

Re: [9fans] Man pages for add-ons

[erik quanstrom]

> bind -a $home/bin/rc		/bin
[...]
>
> (I use this for contrib packages as well, after getting burned a few
> times with contrib stuff breaking builds in /sys/src.  Rather than
> use the package tool I copy the sources into $home/src and build as
> above.  The extra work is minimal.)

how is this less work than fixing or removing
broken packages?  that problem needs to be
dealt with one way or the other.

also this method is unwieldy with a many user
system.  even on a single user system, doesn't it
suck when you can find a few programs that
are in your own bin?

would you extend this to groups of users?
(please say no!)

been there.  (late 80s.  mt xinu bsd.)  done that.
burned the tee shirt.

- erik

Re: [9fans] Man pages for add-ons

[ron minnich]

On Fri, Mar 26, 2010 at 9:55 AM, erik quanstrom
<quanstro@labs.coraid.com> wrote:
>> bind -a $home/bin/rc          /bin
> [...]
>>
>> (I use this for contrib packages as well, after getting burned a few
>> times with contrib stuff breaking builds in /sys/src.  Rather than
>> use the package tool I copy the sources into $home/src and build as
>> above.  The extra work is minimal.)
>
> how is this less work than fixing or removing
> broken packages?  that problem needs to be
> dealt with one way or the other.

Well, I've done both and this is less work. So I just measured the two
quantities. :-)

ron

Re: [9fans] Man pages for add-ons

[erik quanstrom]

> > how is this less work than fixing or removing
> > broken packages?  that problem needs to be
> > dealt with one way or the other.
>
> Well, I've done both and this is less work. So I just measured the two
> quantities. :-)

adding contrib packages to the BUGGERED list
seems even easier.  but seems wrong to me.

in theory, the guy who owns the package
should fix this, resulting in zero work for you.
also, if everyone is putting in the same work
to work around the same broken packages, i
don't see how we're not wasting time, over all.

- erik

Re: [9fans] Man pages for add-ons

[Lyndon Nerenberg (VE6BBM/VE7TFX)]

> also this method is unwieldy with a many user
> system.

It is? Why? If a user wants personal source and binaries, they set
it up. It doesn't impact me one way or the other.

For system-wide stuff I still keep the code in /usr/lyndon/src, but
adjust the mkfiles to install directly into the system directories (which
is usually the default, anyway).

> even on a single user system, doesn't it
> suck when you can find a few programs that
> are in your own bin?

Sorry, I can't parse that this early in the morning.

Re: [9fans] Man pages for add-ons

[erik quanstrom]

> > even on a single user system, doesn't it
> > suck when you can find a few programs that
> > are in your own bin?
>
> Sorry, I can't parse that this early in the morning.

sorry.  forgot "when you're running as the hostowner".

- erik

Re: [9fans] Man pages for add-ons

[Lyndon Nerenberg (VE6BBM/VE7TFX)]

>> > even on a single user system, doesn't it
>> > suck when you can find a few programs that
>> > are in your own bin?
>>
>> Sorry, I can't parse that this early in the morning.
>
> sorry.  forgot "when you're running as the hostowner".

I still don't get it. Why would finding things I put in my own bin
suck?

Re: [9fans] Man pages for add-ons

[erik quanstrom]

> >> > even on a single user system, doesn't it
> >> > suck when you can find a few programs that
> >> > are in your own bin?
> >>
> >> Sorry, I can't parse that this early in the morning.
> >
> > sorry.  forgot "when you're running as the hostowner".
>
> I still don't get it. Why would finding things I put in my own bin
> suck?

you would not find them.  the hostowner, unless that's you,
would be unwise to bind your bin into /bin.

- erik

Re: [9fans] Man pages for add-ons

[Lyndon Nerenberg (VE6BBM/VE7TFX)]

> you would not find them.  the hostowner, unless that's you,
> would be unwise to bind your bin into /bin.

They're *personal* binaries. The hostowner doesn't need them.

Re: [9fans] Man pages for add-ons

[erik quanstrom]

> > you would not find them.  the hostowner, unless that's you,
> > would be unwise to bind your bin into /bin.
>
> They're *personal* binaries. The hostowner doesn't need them.

multiply by several levels of bindings and it will become
a large mental burden to remember what's available where.

- erik

Re: [9fans] Man pages for add-ons

[Lyndon Nerenberg (VE6BBM/VE7TFX)]

> multiply by several levels of bindings and it will become
> a large mental burden to remember what's available where.

Practice says otherwise. The only change to the binds since I set
it up (years ago) was adding $home/bin/rcaux->/bin/aux last fall.

Re: [9fans] Man pages for add-ons

[erik quanstrom]

On Fri Mar 26 14:10:18 EDT 2010, lyndon@orthanc.ca wrote:
> > multiply by several levels of bindings and it will become
> > a large mental burden to remember what's available where.
>
> Practice says otherwise. The only change to the binds since I set
> it up (years ago) was adding $home/bin/rcaux->/bin/aux last fall.

why do you presume i haven't tried this?

- erik

Re: [9fans] Man pages for add-ons

[Lyndon Nerenberg (VE6BBM/VE7TFX)]

> why do you presume i haven't tried this?

Because you claim it doesn't work. I have evidence it does work.

Arm wrestle at 5? :-)

Re: [9fans] Man pages for add-ons

[Ethan Grammatikidis]

On 26 Mar 2010, at 18:44, erik quanstrom wrote:

> On Fri Mar 26 14:10:18 EDT 2010, lyndon@orthanc.ca wrote:
>>> multiply by several levels of bindings and it will become
>>> a large mental burden to remember what's available where.
>>
>> Practice says otherwise. The only change to the binds since I set
>> it up (years ago) was adding $home/bin/rcaux->/bin/aux last fall.
>
> why do you presume i haven't tried this?

Same old same old "it works for me so you don't need more". Maybe
we'll become a part of the gnu project soon.

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

Re: [9fans] Man pages for add-ons

[erik quanstrom]

> Same old same old "it works for me so you don't need more". Maybe
> we'll become a part of the gnu project soon.

please stop trolling.

- erik

Re: [9fans] Man pages for add-ons

[Ethan Grammatikidis]

On 26 Mar 2010, at 21:30, erik quanstrom wrote:

>> Same old same old "it works for me so you don't need more". Maybe
>> we'll become a part of the gnu project soon.
>
> please stop trolling.

I guess I overreacted, sorry.

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

Re: [9fans] Man pages for add-ons

[Federico G. Benavento]

one of the reasons I wrote contrib was that I got tired of
explaining people how the whole process of how to install
a program.

; 9ffs sources
; fcp /n/sources/contrib/dude/thing.tgz /tmp
; cd /tmp
; gunzip < thing.tgz | tar x
; cd thing
; mk install

simple right? but when you've spent tons of 15 minutes
parcels you start getting tired and you write some code.

so the bind magic might work great for those who know
how to get it going, but random newbie won't get it
that fast.

so
; contrib/install dude/thing

seemed reasonable, it has the -r to choose a different
root.

lotte%  wc -l /rc/bin/contrib/*
     19 /rc/bin/contrib/cat
    122 /rc/bin/contrib/create
     97 /rc/bin/contrib/install
    105 /rc/bin/contrib/list
     35 /rc/bin/contrib/local
    132 /rc/bin/contrib/pull
     83 /rc/bin/contrib/push
     41 /rc/bin/contrib/remove
    634 total
lotte% wc -l /sys/src/cmd/contrib/*.c
    455 /sys/src/cmd/contrib/gui.c
lotte%

the real solution is that you want to have a centralized
repository with just binary packages and easy to use
set of tools to use it.

but then that requires some effort and I don't see
any solution in the near future.

one can easily say, "hey, use namespaces!", but
you get someone to reply "hey, write your own driver!"
in the end everything is easy for those who know
how to do it.

--
Federico G. Benavento

Re: [9fans] Man pages for add-ons

[Lyndon Nerenberg (VE6BBM/VE7TFX)]

> in the end everything is easy for those who know
> how to do it.

And god forbid people actually learn anything.

Re: [9fans] Man pages for add-ons

[Ethan Grammatikidis]

On 26 Mar 2010, at 17:34, Lyndon Nerenberg (VE6BBM/VE7TFX) wrote:

>> in the end everything is easy for those who know
>> how to do it.
>
> And god forbid people actually learn anything.

Oh, yeah, lets all learn about namespaces and the counterintuitive
things they do and don't do, and compiling and everything to do when
it goes wrong, and a billion other things JUST to save devs having to
work out a good solution!

If anything, this attitude is why I stopped using Linux. It's worse
than the ever-growing complexity we ridicule so often on this list.

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

Re: [9fans] Man pages for add-ons

[erik quanstrom]

> Oh, yeah, lets all learn about namespaces and the counterintuitive
> things they do and don't do, and compiling and everything to do when
> it goes wrong, and a billion other things JUST to save devs having to
> work out a good solution!

mmm.  i don't know of any counterintuative things
that namespaces do.  do you have an example?
further, you're going to have to know how namespaces
work to use plan 9 interactively or as a developer.

i think the valid — and deep — question here is how
complicated a namespace one wishes to construct.
i see practical limits to how many entries a human can
understand.  the machine of course, doesn't care.

- erik

Re: [9fans] Man pages for add-ons

[Ethan Grammatikidis]

On 26 Mar 2010, at 21:32, erik quanstrom wrote:

>> Oh, yeah, lets all learn about namespaces and the counterintuitive
>> things they do and don't do, and compiling and everything to do when
>> it goes wrong, and a billion other things JUST to save devs having to
>> work out a good solution!
>
> mmm.  i don't know of any counterintuative things
> that namespaces do.  do you have an example?
> further, you're going to have to know how namespaces
> work to use plan 9 interactively or as a developer.

I wish I could put my finger on a specific example. Coming from Linux  
I really struggled to understand how name spaces and file servers  
worked together for some time. One day it just clicked, and I think it  
was well worth learning, but compiling stuff isn't in the same class,  
it's a means to an end and more of a chore. I take the perspective  
that computers should reduce chores as much as they possibly can. ;)

>
> i think the valid — and deep — question here is how
> complicated a namespace one wishes to construct.
> i see practical limits to how many entries a human can
> understand.  the machine of course, doesn't care.

Indeed, and a limit which varies from person to person, hence why I'm  
fighting namespace growth. ;) You could say I'm trading one complexity  
for another: arguing for growing system directories instead. I find a  
good package manager helps a great deal with the filesystem. When you  
can query to find which package a file comes from, then query on the  
package name to find the docs, config files, executables, anything you  
want by filename and then some, that's quite a help with organising.

You know... /opt style might not be so bad after all. It may make the  
namespace a long list, but it would be a list which could very easily  
be grepped for package name and I'm sure quite a simple script could  
find which package a file in the 'bound tree' is really in.

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

Re: [9fans] Man pages for add-ons

[lucio]

> You could say I'm trading one complexity
> for another: arguing for growing system directories instead.

It's hard and not always possible to replace complexity with
simplicity.  Sometimes, even in Plan 9, the choice is to simplify by
convention rather than refinement, there are quite a few heuristics in
Plan 9 that could be replaced by configuration arguments, say, but
then the namespace definitions would be insufferably large.

My favourite example is acme: I'd love message templates in Mail, but
it's almost impossible to create such things without adding
complexity.

So, yes, one trades one complexity for another.  Considering that the
computer is a general-purpose tool that can be programmed to execute
an infinite number of tasks, wildly different and simultaneous, it is
hard to condone simplification for the sake of permitting access to
users who just want to be able to use it.  Not because access should
not be permitted, obviously, but because it restricts what those in
the know can do.  If you want an example, consider the mobile phone:
there are many, many functions I would dearly like my particular
handset (Sony-Ericsson C905) to perform, but are prohibited to me by
the manufacturer, not by my skills and abilities.

I think there are ethical issues here that need exploring and this
type of discussion seldom reaches any conclusions, probably because
we're all busy, result oreiented technologists.  This is the realm of
philosophy and I wish more people would focus not so much on the
technology, but on the long-term effect of different technological
alternatives.

I guess that's just me.

++L

Re: [9fans] Man pages for add-ons

[Tim Newsham]

> worth learning, but compiling stuff isn't in the same class, it's a means to
> an end and more of a chore. I take the perspective that computers should
> reduce chores as much as they possibly can. ;)

You're saying this on the mailing list for an operating system
intended to support programmers and programming.

> -- Alan Perlis

Tim Newsham | www.thenewsh.com/~newsham | thenewsh.blogspot.com

Re: [9fans] Man pages for add-ons

[Lyndon Nerenberg (VE6BBM/VE7TFX)]

> Oh, yeah, lets all learn about namespaces and the counterintuitive
> things they do and don't do, and compiling and everything to do when
> it goes wrong, and a billion other things JUST to save devs having to
> work out a good solution!

Look, if you're too damned lazy (or stupid) to give yourself a handjob,
there are people who will do it for you, for a fee.

Re: [9fans] Man pages for add-ons

[ron minnich]

On Fri, Mar 26, 2010 at 9:45 AM, Lyndon Nerenberg (VE6BBM/VE7TFX)
<lyndon@orthanc.ca> wrote:
> You're making this way more complicated than it needs to be.
>
> For 3rd party stuff, I put the source tree in /usr/lyndon/src/<foo>,
> adjust the mkfiles to install in /usr/lyndon/bin/$objtype, and say
> 'mk install'. I keep a shadow man tree under /usr/lyndon/lib/man,
> and then bind it all on top of the system directories:
>
> bind -a $home/bin/rc            /bin
> bind -a $home/bin/rcaux         /bin/aux
> bind -a $home/bin/$cputype      /bin
> bind -a $home/lib/man/1         /sys/man/1
> bind -a $home/lib/man/2         /sys/man/2
> bind -a $home/lib/man/3         /sys/man/3
> bind -a $home/lib/man/4         /sys/man/4
> bind -a $home/lib/man/5         /sys/man/5
> bind -a $home/lib/man/6         /sys/man/6
> bind -a $home/lib/man/7         /sys/man/7
> bind -a $home/lib/man/8         /sys/man/8
>
> (I use this for contrib packages as well, after getting burned a few
> times with contrib stuff breaking builds in /sys/src.  Rather than
> use the package tool I copy the sources into $home/src and build as
> above.  The extra work is minimal.)
>


I'm doing the same here, same reasons. Works fine. And, yes, I had the
same issues with contrib stuff breaking mk nuke all in /sys/src. I
don't put any contrib src in /sys any more -- unless it is via bind.

thanks

ron

Re: [9fans] Man pages for add-ons

[erik quanstrom]

> I'm doing the same here, same reasons. Works fine. And, yes, I had the
> same issues with contrib stuff breaking mk nuke all in /sys/src. I
> don't put any contrib src in /sys any more -- unless it is via bind.

why does one routinely do mk nuke?

- erik

Re: [9fans] Man pages for add-ons

[tlaronde]

Well, it won't probably answer the questions of any one, but for the
"package" I'm working on, these are true:

1) Compilation is a separate step (One can cross compile on a MATRIX for
a distinct TARGET).

2) Sources are read-only and the compilation is done elsewhere.

3) Space requirements are low since the framework knows how to remove
intermediate products on the run if needed. (I was tired to compile
things that need 2 Gig to end installing 200 Mega---NetBSD comes to
mind; gcc the same etc.)

4) Once compilation is done, you create a package that is simply a
tarball with the stuff that needs to be installed, a script and a _map_
that tells : this thing here shall be put there, with owner: owner:group
and permissions: permissions.

5) The map is generally relative to a $TARGETOPTDIR that one can set as
one wants. User can also just provide another completely different map
if one wants.

Conclusion: it should be relatively easy for anyone to end with the
stuff where one wants.

There will be a default:

a) If there is some kind of majority.

b) If not, conform to where _I_ want to install for my own personal
use ;)
--
Thierry Laronde (Alceste) <tlaronde +AT+ polynum +dot+ com>
                 http://www.kergis.com/
Key fingerprint = 0FF7 E906 FBAF FE95 FD89  250D 52B1 AE95 6006 F40C

Re: [9fans] Man pages for add-ons

[lucio]

> 4) Once compilation is done, you create a package that is simply a
> tarball with the stuff that needs to be installed, a script and a _map_
> that tells : this thing here shall be put there, with owner: owner:group
> and permissions: permissions.

Should this be a proto?  Just in case you've overlooked the option, no
offence intended.

++L

Re: [9fans] Man pages for add-ons

[Steve Simon]

> > 4) Once compilation is done, you create a package that is simply a
> > tarball with the stuff that needs to be installed, a script and a _map_
> > that tells : this thing here shall be put there, with owner: owner:group
> > and permissions: permissions.
>
> Should this be a proto?  Just in case you've overlooked the option, no
> offence intended.


Indeed you could have a proto file to describe this, you could even
have a program that unpacks the tar and installs only files that
don't exist in the current file system, warning you if the local
file has changed - you would have to use ISOs though as tar doesn't
support all the plan9 permissions.

you could call it contrib and base it on an underlieing file synchronisation
system called replica...

Distributing tars has a big disadvantage over replica (even if that access
a remote ISO), image a big package, say TeX, and the author fixes a bug in
a macro file, or changes the permissions on a file. replica will pull this one
file, a tar would have to be re-copied.

[deep breath]

I really don't understand why people don't line contrib and want to put stuff
in /opt or $home/bin. Plan9 is susposed to be all about understanding
the problems in traditional OSs and comming up with new and innovative
solutions to them.

Why did we ever need /usr/local or /opt?

I used to create them because when the OS vendor would supply a new release
they would overwrite my files if I put it in /bin, it also allowed
me to easily wrap up the changes I had written to the OS when I moved
machines/jobs.

On plan9 OS upgrades use replica which takes care not to stomp over your
changes, and when I move jobs I just take some DVDs of my venti with me.

you want to know which file make up a package, contrib/list -v will tell you
you want to know which files you have changed WRT the destribution?
replica/changes.

I don't see the problem, the OS and /sys etc is not sacrosanct, and as has
been said if somthing doesn't work, venti is your friend.

if people are worried about releasing bleeding edge packages vs stable ones,
create two contrib packages, or even better, release only test working features
and then contrib/push out new ones as they appear.

-Steve

Re: [9fans] Man pages for add-ons

[lucio]

> On plan9 OS upgrades use replica which takes care not to stomp over your
> changes, and when I move jobs I just take some DVDs of my venti with me.

I guess there would be less resistance if contrib (by a more
appopriate name, I think fgb concurs here) was part of the base
distribution.

I haven't had occasion to use contrib myself and the only qualm I have
is that trying to access an ISO image remotely is going to be painful
(please tell me I'm wrong) at the end of a 64kbps Internet link.

++L

Re: [9fans] Man pages for add-ons

[Federico G. Benavento]

> I guess there would be less resistance if contrib (by a more
> appopriate name, I think fgb concurs here) was part of the base
> distribution.
>

not really, if contrib was part of the distribution the guys at the labs
would get the mails I get about contrib support.

they way I see it, Plan 9, the official distribution is a research operating
system, not an end user product, in an ideal world some guys would
step out and say, hey let's make a end user Plan 9 distribution and
maintain it, give support to the users, get a pkg system going with
what the user wants, and all the other things that end user products
offer, this is what I tried to imply in the previous posts...

this requires effort, one that I'm not going to make
nor ask anyone either.


--
Federico G. Benavento

Re: [9fans] Man pages for add-ons

[erik quanstrom]

> not really, if contrib was part of the distribution the guys at the labs
> would get the mails I get about contrib support.

there are a few things in contrib that probably should
be in the distribution.

keep up the good work.

- erik

Re: [9fans] Man pages for add-ons

[Anthony Sorace]

> I really don't understand why people don't line contrib and want to
> put stuff in /opt or $home/bin.

That's a false dichotiomy. I quite like replica/contrib, but I also
think there's some value to /opt packages. They answer two different
questions.

> Plan9 is susposed to be all about understanding the problems in
> traditional OSs and comming up with new and innovative solutions to
> them.

Agreed. That doesn't, of course, mean that all our answers will end up
being different.

I like the idea of having non-base stuff installed somewhere other
than / because it reduces the risk of getting exclusions wrong when
updating, allows easier comparisons between local and vendor packages,
reduces package interaction risks, allows easier interrogation of
which packages are locally installed, and allows (easier) finer-
grained control over which packages are "active" by default versus
simply provided locally as options.

This has all gotten a bit theoretical. Like I said, a few of us have
been playing with this in inferno, and I expect to try the same thing
in Plan 9 soon. I'll report any interesting findings.

Re: [9fans] Man pages for add-ons

[tlaronde]

On Sat, Mar 27, 2010 at 06:15:17AM +0200, lucio@proxima.alt.za wrote:
> > 4) Once compilation is done, you create a package that is simply a
> > tarball with the stuff that needs to be installed, a script and a _map_
> > that tells : this thing here shall be put there, with owner: owner:group
> > and permissions: permissions.
>
> Should this be a proto?  Just in case you've overlooked the option, no
> offence intended.

The bit of lacking information that leads to false conclusions: I
use my own framework (built for KerGIS) that is at the moment
strictly POSIX oriented. Hence, at least as a first step---since
if it's far more easy to redo the work from an old Web2c than to
try to deal with the present monstruosity, it's still some work...---,
the Plan9 flavor will come in an APE fashion---for the building
framework and the installation framework (sh(1)), simply because it's
there; for code per se, I'm tidying TeX things for C89, period.---.

There are numerous things that are a problem to deal with on Unix like
systems, and that are far easier on Plan9. That's probably why we are
here? But I'm still using Unices, so TeX has to install on Unices and
Plan9.

So, what I wanted to say is: it will probably not be pure Plan9 at
first (for installation); but it should be trivial to adapt to whatever
one sees fit, and it will need less time to anyone to adapt than to
argue about taste.
--
Thierry Laronde (Alceste) <tlaronde +AT+ polynum +dot+ com>
                 http://www.kergis.com/
Key fingerprint = 0FF7 E906 FBAF FE95 FD89  250D 52B1 AE95 6006 F40C

Re: [9fans] Man pages for add-ons: pax?

[tlaronde]

>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) <tlaronde +AT+ polynum +dot+ com>
                 http://www.kergis.com/
Key fingerprint = 0FF7 E906 FBAF FE95 FD89  250D 52B1 AE95 6006 F40C

Re: [9fans] Man pages for add-ons: pax?

[erik quanstrom]

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

[hiro]

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, tlaronde@polynum.com <tlaronde@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) <tlaronde +AT+ polynum +dot+ com>
>                  http://www.kergis.com/
> Key fingerprint = 0FF7 E906 FBAF FE95 FD89  250D 52B1 AE95 6006 F40C
>
>

Re: [9fans] Man pages for add-ons

[Anthony Sorace]

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

> You're making this way more complicated than it needs to be.

I don't know what you're replying to, but your "simpler" version
starts with what ron suggested and for multi-user setups recreates
the /usr/local model. Or was this to the earlier man subdir question?

No recursive binds are needed in either case. The list of binds would
be shorter with /usr/local than /opt, but that doesn't seem like much
of a win to me. Includes in /lib/namespace for each package should
make it even less of an issue. Our file server at the labs had >350
lines in /lib/namespace and the overlay worked very well.


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

Re: [9fans] Man pages for add-ons

[Ethan Grammatikidis]

On 26 Mar 2010, at 05:02, EBo wrote:
> I'm also talking about system wide apps on a
> multiuser system.  So, for example, your /$objtype/bin would look
> something
> like /sys_apps/$objtype/bin, and /sys_aps would contain all system
> wide,
> non-OS distributed, applications.

This is just how I imagine /usr became the way it is in modern unix,
and look how first /usr/local (or similar) and then /opt was added
because it wasn't 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!

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.


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

Re: [9fans] Man pages for add-ons

[Tim Newsham]

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

Also, is the size of the namespace list an issue?

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

Tim Newsham | www.thenewsh.com/~newsham | thenewsh.blogspot.com

Re: [9fans] Man pages for add-ons

[erik quanstrom]

> Also, is the size of the namespace list an issue?

how does history(1) work in the face of a complicated namespace?
we get buy now because the rules are pretty simple.  if you want to
find how the modifications to /386/lib/libc.a, you know where that
is.  if you bind 100 packages on top of /386/lib, it becomes necessary
to deconstruct namespaces continually.  the abstraction of namespace
starts to break down.

i think it makes more sense to optimize for the common case —
using packages, rather than the uncommon questions like "what's
in this package".

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

- erik

Re: [9fans] Man pages for add-ons

[Federico G. Benavento]

On Sat, Mar 27, 2010 at 1:54 PM, erik quanstrom <quanstro@quanstro.net> wrote:
>> Also, is the size of the namespace list an issue?
>
> how does history(1) work in the face of a complicated namespace?
> we get buy now because the rules are pretty simple.  if you want to
> find how the modifications to /386/lib/libc.a, you know where that
> is.  if you bind 100 packages on top of /386/lib, it becomes necessary
> to deconstruct namespaces continually.  the abstraction of namespace
> starts to break down.
>

this also breaks plumbing while debugging with acid unless quirky
namespace is global, but then if it's global why do you need the binds!


-- 
Federico G. Benavento

Re: [9fans] Man pages for add-ons

[erik quanstrom]

> > how does history(1) work in the face of a complicated namespace?
> > we get buy now because the rules are pretty simple.  if you want to
> > find how the modifications to /386/lib/libc.a, you know where that
> > is.  if you bind 100 packages on top of /386/lib, it becomes necessary
> > to deconstruct namespaces continually.  the abstraction of namespace
> > starts to break down.
> >
>
> this also breaks plumbing while debugging with acid unless quirky
> namespace is global, but then if it's global why do you need the binds!

in order for a namespace to be non-empty, it will need binds or mounts
somewhere.  even a "global" (i'm assuming by global you mean in /lib/namespace)
bind will not work well with history.  since the namespace isn't fancy enough
to do rewriting based on pattern matching.  (thank god!).

i suppose you could write a script, but such a script would need to generate
a set of binds for each day of the dump.  are you ready for a 350*(1 + 2136)
line namespace?

- erik

Re: [9fans] Man pages for add-ons

[hiro]

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

I still don't see the problem, i.e. what you are trying to do.

27.03.2010 19:13 schrieb am "erik quanstrom" <quanstro@quanstro.net>:

> > how does history(1) work in the face of a complicated namespace?
> > we get buy now because the ...
in order for a namespace to be non-empty, it will need binds or mounts
somewhere.  even a "global" (i'm assuming by global you mean in
/lib/namespace)
bind will not work well with history.  since the namespace isn't fancy
enough
to do rewriting based on pattern matching.  (thank god!).

i suppose you could write a script, but such a script would need to generate
a set of binds for each day of the dump.  are you ready for a 350*(1 + 2136)
line namespace?

- erik

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

Re: [9fans] Man pages for add-ons

[Lyndon Nerenberg (VE6BBM/VE7TFX)]

> if you want to
> find how the modifications to /386/lib/libc.a, you know where that
> is.  if you bind 100 packages on top of /386/lib, it becomes necessary
> to deconstruct namespaces continually.  the abstraction of namespace
> starts to break down.

Dump deals with 'physical' paths; you have to think of history and
friends in that light. This is why you can't, e.g., 'history /bin/rc'.
This doesn't mean history is broken. Dumps and snapshots are tied directly
to fossil/venti/kenfs et al, and work in that context.

Re: [9fans] Man pages for add-ons

[erik quanstrom]

> > if you want to
> > find how the modifications to /386/lib/libc.a, you know where that
> > is.  if you bind 100 packages on top of /386/lib, it becomes necessary
> > to deconstruct namespaces continually.  the abstraction of namespace
> > starts to break down.
>
> Dump deals with 'physical' paths; you have to think of history and
> friends in that light. This is why you can't, e.g., 'history /bin/rc'.
> This doesn't mean history is broken. Dumps and snapshots are tied directly
> to fossil/venti/kenfs et al, and work in that context.

physical path!?

You know that
Ken uses paths,
Rob uses paths,
and just think,
you can use paths, too.
A path is a path
and no amount of money
can get you a better path....
All the paths are the same and
all the paths are good.

with apologies to andy worhol.

- erik

Re: [9fans] Man pages for add-ons

[Tim Newsham]

>> Also, is the size of the namespace list an issue?
>
> how does history(1) work in the face of a complicated namespace?
> we get buy now because the rules are pretty simple.

Hmm.. your scripts to setup your namespace also exist in the
wayback machine, no?
Perhaps this is a good argument for
http://pdos.csail.mit.edu/~baford/vxa/ ?

> what google uses for its search tables or custom applications
> might not be that interesting in the context of a general purpose
> operating system.

I'm just pointing out that searching unorganized files is
another alternative.  I'm not sold on this approach, myself.

> - erik

Tim Newsham | www.thenewsh.com/~newsham | thenewsh.blogspot.com

Re: [9fans] Man pages for add-ons

[erik quanstrom]

> >> Also, is the size of the namespace list an issue?
> >
> > how does history(1) work in the face of a complicated namespace?
> > we get buy now because the rules are pretty simple.
>
> Hmm.. your scripts to setup your namespace also exist in the
> wayback machine, no?
> Perhaps this is a good argument for
> http://pdos.csail.mit.edu/~baford/vxa/ ?

you've got to be able to get at the history to begin
with.  *that's* the problem.  lyndon's right, history
doesn't work even on the usual union directories.
compounding the problem doesn't seem like the
right way to go.

- erik

Re: [9fans] Man pages for add-ons

[Lyndon Nerenberg (VE6BBM/VE7TFX)]

> you've got to be able to get at the history to begin
> with.  *that's* the problem.  lyndon's right, history
> doesn't work even on the usual union directories.
> compounding the problem doesn't seem like the
> right way to go.

Should history work on /env, too?

Dump is tool for a specific type of file server. There's nothing
broken here, move along ...

Re: [9fans] Man pages for add-ons

[erik quanstrom]

> Should history work on /env, too?
>
> Dump is tool for a specific type of file server. There's nothing
> broken here, move along ...

what's the fileserver behind /bin?

- erik

Re: [9fans] Man pages for add-ons

[Lyndon Nerenberg (VE6BBM/VE7TFX)]

> what's the fileserver behind /bin?

Whatever you want it to be. That's the beauty of Plan 9.

But if you can't remember how you organized your shit, George
Carlin has a number of self-help records ;-)

Re: [9fans] Man pages for add-ons

[Ethan Grammatikidis]

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

[Federico G. Benavento]

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
<eekee57@fastmail.fm> 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

[erik quanstrom]

> 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

[Ethan Grammatikidis]

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

[hiro]

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 <eekee57@fastmail.fm> 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] Man pages for add-ons

[Ethan Grammatikidis]

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

[Iruata Souza]

On Sun, Mar 28, 2010 at 9:59 PM, Ethan Grammatikidis
<eekee57@fastmail.fm> 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 <timestamp>. 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

[Patrick Kelly]

>since we are trying so hard to create new problems for Plan 9, should
>i assume the old ones have all been solved?

Sadly I think this is just people adding complexity because, 'that’s how Linux does it', and must be correct. Either that or they desire complexity for familiarity; an even more chilling possibility.

I'm truly baffled.

"Let us not trust the good people who developed this system to know what they were doing. We are users with little systems development experience, and clearly know more than them."

At least that’s the message I'm getting from all of this... downright disgraceful.

>iru

Re: [9fans] Man pages for add-ons

[Ethan Grammatikidis]

On 29 Mar 2010, at 10:07, Patrick Kelly wrote:

>> since we are trying so hard to create new problems for Plan 9, should
>> i assume the old ones have all been solved?
>
> Sadly I think this is just people adding complexity because, 'that’s  
> how Linux does it', and must be correct. Either that or they desire  
> complexity for familiarity; an even more chilling possibility.

On my part I guess I'm assuming complexity will come, whether we like  
it or not. I don't find it easy to believe that we can avoid  
complexity forever, and I get the feeling some relatively rapid growth  
is coming. Could Plan 9 grows to the point of having many GUI  
applications and many facilities to support those apps and it still  
get by without any sort of package manager? Heh, actually I hope we  
can. I was involved with maintaining a linux distro for a few years  
and even given a much saner base system I'm not keen on taking up  
package maintenance again. A script or two to help find what was  
installed might be just the thing, and let "upstream" sort out whether  
their code works with anyone else's.

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

Re: [9fans] Man pages for add-ons

[Patrick Kelly]

>On my part I guess I'm assuming complexity will come, whether we like
>it or not. I don't find it easy to believe that we can avoid
>complexity forever, and I get the feeling some relatively rapid growth
>is coming.

Yes, but should that complexity be needless? I understand that as features
are added, they add complexity. But does the complexity added always justify
the addition of the feature? Features should be carefully thought out, not
added because someone foresees an unlikely or avoidable problem, or wants
the system to do everything for oneself.

>Could Plan 9 grows to the point of having many GUI
>applications and many facilities to support those apps and it still
>get by without any sort of package manager?

In my opinion, package managers are only a solution for systems that are
already a mess. I've said it before, I downright hate Windows, but it gets
by just fine without a package manager; Just install and uninstall
'scripts'. Those scripts wouldn't even need to be necessary on Plan 9, or
any system that doesn't maliciously abuse a central configuration system.

>Heh, actually I hope we
>can.

As do I.

>I was involved with maintaining a linux distro for a few years
>and even given a much saner base system I'm not keen on taking up
>package maintenance again. A script or two to help find what was
>installed might be just the thing, and let "upstream" sort out whether
>their code works with anyone else's.

People doing some actual work, *gasp*.
Heck, it's more sane than some solutions I've heard.

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

Re: [9fans] Man pages for add-ons

[Connor Lane Smith]

Hey,

On 29 March 2010 13:14, Patrick Kelly <kameo76890@gmail.com> wrote:
> In my opinion, package managers are only a solution for systems that are
> already a mess. I've said it before, I downright hate Windows, but it gets
> by just fine without a package manager; Just install and uninstall
> 'scripts'. Those scripts wouldn't even need to be necessary on Plan 9, or
> any system that doesn't maliciously abuse a central configuration system.

Installing a program on Windows tends to involve finding a webpage,
downloading an (unsigned) binary, and executing it. It doesn't get by
just fine: there's no difference between installing trustworthy
software, and trojans etc. That's one of Windows' many security flaws.

A package manager should, imo, just hget a url, confirm its origin
with factotum, untar, and mk install. That's simple enough I think.
It's more about the repository than the manager, really.

I don't think Plan 9 needs a package manager in its current state
(with contrib, etc), but I think systems with more software benefit
from them.

cls

Re: [9fans] Man pages for add-ons

[Patrick Kelly]

>-----Original Message-----
>From: 9fans-bounces@9fans.net [mailto:9fans-bounces@9fans.net] On Behalf Of Connor Lane Smith
>Sent: Monday, March 29, 2010 8:42
>To: Fans of the OS Plan 9 from Bell Labs
>Subject: Re: [9fans] Man pages for add-ons
>
>Hey,
>
>On 29 March 2010 13:14, Patrick Kelly <kameo76890@gmail.com> wrote:
>> In my opinion, package managers are only a solution for systems that are
>> already a mess. I've said it before, I downright hate Windows, but it gets
>> by just fine without a package manager; Just install and uninstall
>> 'scripts'. Those scripts wouldn't even need to be necessary on Plan 9, or
>> any system that doesn't maliciously abuse a central configuration system.
>
>Installing a program on Windows tends to involve finding a webpage,
>downloading an (unsigned) binary, and executing it. It doesn't get by
>just fine: there's no difference between installing trustworthy
>software, and trojans etc. That's one of Windows' many security flaws.

I was speaking strictly in terms of binary management within the system. Does no one understand what context is?

Your confusing package management with security.

You can easily put trojans, viruses, spyware, or anything you feel like into a package to be distributed via package management. Just because UNIX's security system is better, doesn’t mean package management can't be abused like installers for Windows or OS X can be. Windows has security issues (severe ones), but its program management is fine.

>A package manager should, imo, just hget a url, confirm its origin
>with factotum, untar, and mk install. That's simple enough I think.
>It's more about the repository than the manager, really.
>
>I don't think Plan 9 needs a package manager in its current state
>(with contrib, etc), but I think systems with more software benefit
>from them.
>
>cls

Re: [9fans] Man pages for add-ons

[Connor Lane Smith]

On 29 March 2010 14:05, Patrick Kelly <kameo76890@gmail.com> wrote:
> I was speaking strictly in terms of binary management within the system. Does no one understand what context is?

A package manager's main duty is to handle repositories and
dependencies. If we're looking at nothing more than management of
local binaries then yes, systems without it get along fine. But if you
look at the bigger picture it becomes obvious why a package manager is
necessary and isn't just for "systems that are already a mess." This
is called putting things in context.

Thanks,
cls

Re: [9fans] Man pages for add-ons

[Steve Simon]

> A package manager's main duty is to handle repositories and
> dependencies. If we're looking at nothing more than management of
> local binaries then yes, systems without it get along fine. But if you
> look at the bigger picture it becomes obvious why a package manager is
> necessary and isn't just for "systems that are already a mess." This
> is called putting things in context.

Interestingly I know of two binary package dependencies in all the
packages we have.

Everything depends on the kernel, abaco depends on webfs, and thats it;
not having shared libraries saves us from much dependency misery.

There are a few sourcecode dependencies (one contrib needs another
in order to compile), but these are reported when you install or pull
such a package by the contrib software.

The bottom line on the package managment is the same as most protracted
debates on 9fans:

	if you don't like whats there change or replace it. if its better people
	will migrate to it, if not it will be orphaned. If you just talk and write
	no code you will be ignored.

This is not a threat, just a statment of how 9fans works.

-Steve

Re: [9fans] Man pages for add-ons

[Georg Lehner]

Patrick Kelly wrote:
> [..] In my opinion, package managers are only a solution for systems that are
> already a mess. I've said it before, I downright hate Windows, but it gets
> by just fine without a package manager; Just install and uninstall
> 'scripts'. Those scripts wouldn't even need to be necessary on Plan 9, or
> any system that doesn't maliciously abuse a central configuration system. [..]
As a MS-Windows end user one gets inevitably to know that  a 'Windows
Installer'
is required to install new Software and that there are some rules all well
behaved "packages" abide, since an installed application is made visible
in the start menu and uninstallable via the control panel.  There is more to
Windows 'package managment' then 'scripts' - there are rules, conventions.

It seems to me, that a few more scripts, conventions and rules for
system, contrib
and third-party applications will ease setting up and administering
Plan9 systems.

I am very greatful to Federico G. Benavento for implementing contrib and
really
looking forward for Anthony Sorace's experience with third-party
packages installed
in /opt in Inferno.

This thread also has given some very good examples and insight on how
the proven
Plan9'ers get their work done - thanks for the lessons learned.

The solution that feels 'right' will inevitable emerge and this thread
has surely been a step
forward in the right direction.


Best Regards,

    Jorge-Le�n

Re: [9fans] Man pages for add-ons

[Patrick Kelly]

On Mar 29, 2010, at 3:29 PM, Georg Lehner wrote:

> Patrick Kelly wrote:
>> [..] In my opinion, package managers are only a solution for  
>> systems that are
>> already a mess. I've said it before, I downright hate Windows, but  
>> it gets
>> by just fine without a package manager; Just install and uninstall
>> 'scripts'. Those scripts wouldn't even need to be necessary on Plan  
>> 9, or
>> any system that doesn't maliciously abuse a central configuration  
>> system. [..]
> As a MS-Windows end user one gets inevitably to know that  a  
> 'Windows Installer'
> is required to install new Software and that there are some rules  
> all well
> behaved "packages" abide, since an installed application is made  
> visible
> in the start menu and uninstallable via the control panel.  There is  
> more to
> Windows 'package managment' then 'scripts' - there are rules,  
> conventions.

Which tend to be ignored, after all the registry might be abused at a  
higher rate than some illegal drugs. At any rate, the installer does  
little more than extract the files, possibly add some registry keys,  
and create an uninstaller. Certain, although few, programs also add a  
line to %PATH%.

I've seem less sane management systems.

Security is still to be desired though, on the bright side,  
Singularity had some nice sides, and "Midori" could be promising if  
Balmer... never mind.

> It seems to me, that a few more scripts, conventions and rules for  
> system, contrib
> and third-party applications will ease setting up and administering  
> Plan9 systems.

A few scripts, should they be deemed necessary, might not be a bad  
idea. Only assuming they are actually deemed necessary. As of right  
now, I'm not aware of anything that complex, may be someone else is.

> I am very greatful to Federico G. Benavento for implementing contrib  
> and really
> looking forward for Anthony Sorace's experience with third-party  
> packages installed
> in /opt in Inferno.
>
> This thread also has given some very good examples and insight on  
> how the proven
> Plan9'ers get their work done - thanks for the lessons learned.

Yes, I might gather up all of the information and combine it in some  
way for future reference for the negligent. Anyone who wishes to learn  
about sane management could benefit from it as well.

> The solution that feels 'right' will inevitable emerge and this  
> thread has surely been a step
> forward in the right direction.

At least we discussed it. I feel confident that very little, if any,  
changes need to be made to the existing system.

>
> Best Regards,
>
>   Jorge-León
>
>

Re: [9fans] Man pages for add-ons

[blstuart]

I've been avoiding getting into this discussion, largely because
I fail to understand just why it seems to be an issue at all,
much less a big deal.  But once again, against my better judgement
I allow my big mouth to open.

> On my part I guess I'm assuming complexity will come, whether we like
> it or not. I don't find it easy to believe that we can avoid
> complexity forever,

Well, considering Plan 9 has been around for well over 20 years
(longer btw than UNIX had been around when the guys at the
Labs decided to start from scratch), it has appeared to me over
that time that the Plan 9 community has done a good job of
choosing what complexity should be there and what shouldn't.
Given the history, I'd need something pretty compelling to
justify expending effort on that assumption.

> and I get the feeling some relatively rapid growth
> is coming.

What kind of growth do you have in mind?  That's important
because it affects what, if anything, should be done to
accomodate that growth.  It seems to me we might have
0, 1, 2, or 3 of these types of growth:

1) growth of the complexity and source code of inidividual apps,
a la, the implementions of cat and cp recently discussed
2) growth in the number of end-user applications along the lines
of:
> Could Plan 9 grows to the point of having many GUI
> applications and many facilities to support those apps
3) growth in the number of end users in the community

None of which I think are too likely:
1) The GNU, we never met a command line option or abstration
we didn't like, approach is anathema to the aesthetic of the
Plan 9 community.  I find it extremely difficult to imagine
the poeple in this community sitting idly by while the system
is made ugly in the same way others have been.
2) I don't really know what kind of GUI apps and facilities
are needed.  A web browser that has sold its soul at the
crossroads so that it it might include javascript, java, css,
flash, xml, the kitchen sink, and whatever other abominations
you can imagine, that such a web browser might find use.
But other than that I can't really think of anything that I
use often enough to miss in Plan 9.  But certainly if you
need something enough that you're motivated to write it,
then by all means do so.  If others find it useful, they'll
use it, but either way you've still met your own need.
This is where your observation fits in:
>  A script or two to help find what was
> installed might be just the thing,
If, in the course of using the system, you feel the need for
this kind of script, then write it and see what happens.  But
the approach that says, "I'll write this because I know everyone
will need it and we'll make sure it becomes policy" will fall
flatter than Wile E Coyote after the anvil misses the Roadrunner
and lands on him.
3) The Plan 9 community is very happy to welcome those
who share its aesthetic and who make productive contributions.
It's also quite welcoming of those who seek to learn from the
experience and expertice of the community.  But those who
come upon the community with the agendas: "why don't you
have my favorite xyz app; you need to write it," "here's what
you're doing wrong," and "your OS has no value unless it has
millions of users"... well, the two things that come to mind
are perpetual September and an old phrase about grandmothers
and sucking eggs.

The bottom line is for anyone who has a good idea, just
implement it and we'll have something to discuss.  The
amount of time and effort that too often goes into these
discussions is far greater than what it would take to just
write the app and see whether it was useful.

Returning to the underside of my rock...

BLS

Re: [9fans] Man pages for add-ons

[erik quanstrom]

> 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] Man pages for add-ons

[Federico G. Benavento]

; grep $pattern /dist/replica/client/*.db


On Sat, Mar 27, 2010 at 1:46 PM, Tim Newsham <newsham@lava.net> 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?
>
> Also, is the size of the namespace list an issue?
>
>> 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.
>
> Tim Newsham | www.thenewsh.com/~newsham | thenewsh.blogspot.com
>
>



-- 
Federico G. Benavento

Re: [9fans] Man pages for add-ons

[Ethan Grammatikidis]

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

[erik quanstrom]

> 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

[Jacob Todd]

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

On Fri, Mar 26, 2010 at 08:21:02PM +0000, 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.

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

Re: [9fans] Man pages for add-ons

[Steve Simon]

As far as packaging stuff up look at fgb's contrib system,
bootstratp your self into the delightful world of 3rd party packages
by typing:

	9fs sources
	/n/sources/contrib/fgb/root/rc/bin/contrib/install fgb/contrib
	contrib/gui

man contrib will tell you about the tools and how to create
packages of your own.

I have a text contrib package on there but I will remove it when you
have your updated release working.

-Steve

Re: [9fans] Man pages for add-ons

[tlaronde]

On Thu, Mar 25, 2010 at 02:07:46PM +0000, Steve Simon wrote:
> As far as packaging stuff up look at fgb's contrib system,
> bootstratp your self into the delightful world of 3rd party packages
> by typing:
>
> 	9fs sources
> 	/n/sources/contrib/fgb/root/rc/bin/contrib/install fgb/contrib
> 	contrib/gui
>
> man contrib will tell you about the tools and how to create
> packages of your own.

I will look at this. Since I use my own framework (very simple but
for cross-compiling), it will probably end in a script and a map (where
to put the stuff, with what name, owner and permissions) "fgb's contrib"
compliant.

> I have a text contrib package on there but I will remove it when you
> have your updated release working.

There is no urge ;) Normally, even LaTeX user's will be able to use this
stuff, since it's "simply" macros --- TeX uses argv[0] to know what
format to load; hence "latex" is not a program, but a hint for what
"compiled" version of the macros to put in memory.

But we will need to verify first that the new version delivers what it
is supposed to...

And the hard part is done---understanding what goes on; putting the
translation stuff apart; building libraries for duplicated things
etc.---, but I'm still cleaning things and going back to Knuth's books
to understand what to keep and what to delete in the change files. With
one or two hours per day at maximum, this will still take some
weeks (I think).

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

Re: [9fans] Man pages for add-ons

[Ethan Grammatikidis]

On 25 Mar 2010, at 11:49, tlaronde@polynum.com wrote:

> Hello,
>
> Since I can finally find some time here and there, I'm back to TeX and
> al.
>
> From namespace(4), the man pages are supposed to be under /sys/man.
>
> What is the canonical way for added ("opt", "pkg" ?) stuff. Letting
> the user adapt his profile to bind the added stuff he wants
> appearing in
> his namespace?

I know this isn't exactly what you're asking, but man-page namespace
pollution has been something of an issue for years on unix. For
example in Linux GPM and XFree86 both provided mouse(5), which was a
big problem for me when I was first learning the system.

I would like to see Plan 9 man support subdirs as rc does. For
instance you can run ip/ping as a command, so why can't you look up ip/
ping(1)? Man pages for add-ons would have their own subdirs under the /
sys/man tree, and you would reference them with a syntax like package/
pagename.


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

Re: [9fans] Man pages for add-ons

[erik quanstrom]

> I would like to see Plan 9 man support subdirs as rc does. For
> instance you can run ip/ping as a command, so why can't you look up ip/
> ping(1)? Man pages for add-ons would have their own subdirs under the /
> sys/man tree, and you would reference them with a syntax like package/
> pagename.

man already supports sections like 1a 1b 1tex or what have you.
i see no need to make life more complicated.

- erik