Re: RFC
Jim Knoble wrote:
> This is a problem the distributions need to solve. The LSB should not
> `legislate' a solution. Let's spend our efforts doing things more
> crucial.
I was relying to a post as to why to use /opt instead of /usr. Of
course LSB cant really stop distributions from bloating /usr. Of
course it can suggest a solution to the problem, and put forward
argument that is supported by a concensus.
> : To save disk space many things can be shared, as /usr/local
> : should be local to a machine, /opt is the natural place for such
> : sharing to occur.
>
> Actually, /usr/ is really supposed to be the preeminent sharable
> hierarchy. That's why all the mutable stuff got moved to the /var/
> hierarchy (e.g, logs moved from /usr/adm/ to /var/log/, mail spools
> moved from /usr/spool/mail/ to /var(/spool)?/mail/, etc.), and why
> architecture-independent stuff lives in /usr/share/ while
> architecture-dependent stuff lives in /usr/lib/. Putting `local'
> system-specific binaries in /usr/local/ is nonsensical; then you end up
> having to export /usr/bin/, /usr/lib/, and /usr/share/ separately (not
> to mention /usr/X11R6/ and whatnot).
Really?, I had always been under the impression it was to allow
/usr to be mounted read-only.
If /usr is supposed to contain an OS distribution, but /usr is
also shared, I guess that makes Linux a distributed OS :)
> Here's what should be done with /usr/local/:
>
> rm -rf /usr/local/
How about:
[BASH]/usr$ ln -s /local .
> System-specific binaries (and libraries and scripts and configuration)
> ought to go in a completely different tree. Sun's /space/local/ would
> work, as would a simple /local/ (which is what i use).
<snip>
> : Personally I think it would be good that if you accidentely
> : destoryed your root partition, you didn't have to overwrite
> : 500+MB of perfectly fine /usr during a reinstall. :)
>
> Machines, busses, and storage devices are all large and fast enough
> nowadays that an extra 15 minutes and 500 MB are trivial. If you trash
> only your root partition by mistake, those extra 15 minutes will help
> you remember not to do again next time. If it's the disk's fault, you
> really should be replacing the disk anyway. If it's because your
> machine was cracked or trojaned, you ought to be spending too much time
> trying to track down the unwelcome visitor to care about those extra 15
> minutes. Get over it.
I disagree.
> : NOTE 1: That said, if you want to mount /usr you might want a
> : subset of /usr on your local machine for redundancy, so that if
> : your network falls over you can still get a system running.
>
> Nothing that is required to get a system running without a network has
> any business even being in the /usr/ hierarchy. If you need it to get
> a system running, it needs to live in /bin/. Plain and simple.
I meant running and usable. Things in /bin are only to be used to
get a machine running so you can reconfigure it to work again. If
your network has fallen over you don't have to reconfigure the
client do you?
Cheers,
Daniel.
Reply to:
- References:
- RE: RFC
- From: "Robert W. Current" <rob@entropy.current.nu>
- Re: RFC
- From: Michael Stone <mstone@cs.loyola.edu>
- Re: RFC
- From: Daniel Bradley <daniel@dstc.qut.edu.au>
- Re: RFC
- From: Jim Knoble <jmknoble@pobox.com>