BB menu reorg and upstream packages

[Rob Landley]

On Monday 27 March 2006 3:25 am, Ole-Egil Hvitmyren wrote:
> On Debian:
> olegil at olegil:~$ sudo update-alternatives --list pager
> /bin/more
> /usr/bin/less
> /usr/bin/w3m
> /usr/bin/pg
>
> Do you think it's coincidence that more lives in /bin while less lives
> in /usr/bin?

Yes.

> What happens when the user puts /usr on a separate 
> partition which for some reason doesn't work one day?

This hasn't been a real-world consideration for at least 10 years.  (Attached 
is a rant I wrote about this over a year ago.)

The retroactive justifications people have done for this historical issue is 
one of my pet peeves...

> Right, he'll at 
> least have the option to use "more".

Assuming his inittab isn't set to bring up X, he's set up root access without 
sudo, he doesn't need a text editor like vim, doesn't need ssh, his init 
scripts don't use anything in /usr (obscure commands like yes, tee, uniq, 
tail, wc...)

There's a reason rescue disks were invented.

By the way, if we're talking about busybox, keep in mind it's the SAME BINARY.  
So talking about a / vs /usr split is kind of silly.

> A pager is a necessary tool, and "more" is the fallback when all other
> pagers fail, ergo more is a necessary tool.

If your system is that deeply horked, I find a nice copy of busybox comes in 
handy.  YMMV.

Rob
-- 
Never bet against the cheap plastic solution.
-------------- next part --------------
Flimsy rationalizations for all of my design mistakes:

Filesystem:

Our directory hierarchy is a bit idiosyncratic: some redundant directories have
been merged, with symlinks from the standard positions pointing to their new
positions.

The set "bin->usr/bin, sbin->usr/sbin, lib->usr/lib" all serve to consolidate
all the executables under /usr.  This has a bunch of nice effects: making a
a read-only run from CD filesystem easier to do, allowing du /usr to show
the whole system size, allowing everything outside of there to be mounted
noexec, and of course having just one place to look for everything.  (Normal
executables are in /usr/bin.  Root only executables are in /usr/sbin.
Libraries are in /usr/lib.)

For those of you wondering why /bin and /usr/sbin were split in the first
place,  the answer is it's because Ken Thompson and Dennis Ritchie ran out
of space on the original 2.5 megabyte RK-05 disk pack their root partition
lived on in 1971, and leaked the OS into their second RK-05 disk pack where
the user home directories lived.  (/usr was what /home is today.)

The real reason we kept it is tradition.  The execuse is that the root
partition contains early boot stuff and /usr may get mounted later, but these
days we use initial ramdisks (initrd and initramfs) to handle that sort of
thing.  The version skew issues of actually trying to mix and match different
versions of /lib/libc.so.* living on a local hard drive with a /usr/bin/*
from the network mount are not pretty.

I.E. The seperation is just a historical relic, and I've consolidated it in
the name of simplicity.

The one bit where this can cause a problem is merging /lib with /usr/lib,
which means that the same library can show up in the search path twice, and
when that happens binutils gets confused and bloats the resulting executables.
(They become as big as statically linked, but still refuse to run without
opening the shared libraries.)  This is really a bug in either binutils or
collect2, and has probably been fixed since I first onticed it.  In any case,
the proper fix is to take /lib out of the binutils search path, which we do.
The symlink is left there in case somebody's using dlopen, and for "standards
compliance".

Similarly, all the editable stuff has been moved under "var", including
tmp->var/tmp, and etc->var/etc.  (Whether /etc really needs to be editable is
an issue to be revisited later...)  Remember to put root's home directory
somewhere writeable (I.E. /root should move to either /var/root or
/home/root), and life is good.

Other detail: /tmp is much less useful these days than it used to be.  Long
ago in the days of little hard drive space and even less ram, people made
extensive use of temporary files and they threw them in /tmp because ~home
had an ironclad quota.  These days, putting anything in /tmp with a predictable
filename is a security issue (symlink attacks, you can be made to overwrite
any arbitrary file you have access to).  Most temporary files for things
like the printer or email migrated to /var/spool, where there are persistent
subdirectories with known ownership and permissions.

The result of all this is that a running system can have / be mounted read only
(with /usr living under that), /var can be ramfs/tmpfs with a tarball extracted
into it, /dev can be ramfs/tmpfs managed by udev (with /dev/pts as devpts under
that: note that /dev/shm naturally inherits /dev's tmpfs), /proc can be procfs,
/sys can bs sysfs.  Optionally, /home can be be an actual writeable filesystem on a hard drive or the network.