Re: Putting variables into files section?

[Adam Ophir Shapira <red_angel techno-info com>]

John Aldrich wrote:

> Adam: 
> I see a small problem with what you're trying to do -- it completely violates 
> the spirit of the FHS, which is a common standard for where things should 
> go... i.e. /usr/local/bin or /usr/bin instead of wherever the heck a program 
> developer decides something out to go. Think a bit about what <boxenv> would 
> do to such a system....just when things are starting to be standardized 
> across multiple distributions of linux, your idea would basically toss that 
> out of the window...
>
> Just thought I'd point that out. :-)
> 	John

 Actually, it appears as though you misunderstand <boxenv>.

 Under <boxenv> things don't go wherever the *developer* wants to
put them. It's not up to the developer but instead up to the administrator
or end-user (whichever of them is installing the program).

 And the programs won't go into just random locations. They will go
into *specific* locations. The only thing that <boxenv> would change
is this: instead of those specific locations being hardcoded for all
time-and-space, they would be based now on preference variables.

 This FHS is a nice thing when all is ideal: but it unfortunately
has no way whatsoever of dealing with what happens when you really
*can't* install something where it's "supposed" to go for one reason
or another. One reason could be that things are "supposed" to go
into "/usr/bin" or "/usr/local/bin", but I happen not to be the
sys-admin, and therefore don't have *permission* to write to those
directories. (And if you can't see why that limitation is a bad
thing, then you've been on a pedestal too long.)

 And, I have also seen cases where even the sys-admin wasn't able
to install programs at the same location where they are "supposed"
to go.

 Yes, standardization is a good thing: if it's done right. But
what you describe definitely *not* the right way to go about
standardizing things, because it takes away the ability of individual
users to do things on their own, without having to depend on the
sys-admin to blow their nozes for them.

 And in <boxenv>, things don't get installed haphasardly. They are
based on preference variables: and if program B relies on program A,
then program B can *read* thos preference varaibles to find *out*
where program A is.

 You say I should think about what <boxenv> would do to such a
system: so I'll just turn the tables and ask you to figure out
why that system is worth protecting from what <boxenv> would do
to it. But as for my part of the thinking: I thought and I figured
that if <boxenv> forces people to re-evaluate that FHS system you
talked about, then that's a good thing.

 The ability of users to be as self-reliant as system-security
concerns allow is an ability that must be defended with vigilence.
And <boxenv> supports that ability, while your FHS is nothing
short of a head-on *attack* on that ability: whether that attack
is done on purpose or not.

    Thanks,
         Adam