Very Computer

It could cause big, big, big problems if you tried to use, say,
libc.so.x.y before you mounted /usr.

While many people have just one partition with a filesystem, it could
louse me up pretty good if libc got moved out of /lib and into
/usr/something.

Of course, I suppose it's a good idea to keep statically linked
copyies of mount, umount, etc... But if a change like this was made
without me seeing it, I'd be in big trouble since I assume that If
I've got / mounted I have my shared libs.

Ack!

Keep all the shared images in /lib!!!

--

____ "Nuke the unborn gay whales" -- Never seen on a protest sign
\bi/ |umop apisdn| First year comp sci major.  CRPG *.
 \/  1.5<kinsey<2.5 IRC Synger  Running Linux 0.99.15d. DOS is evil

+--- Dave Barr:
| There is no need for (in fact it is dangerous to have) shared
| libraries in /.  (what do you do if your shared lib is corrupted?
| You can't boot single-user safely..)
+---

What do you do if mkfs/mount is corrupted? You reinstall. There's
really no difference.

+---
| Since [FSSTND] says things in /bin and /sbin should be static anyway
+---

It does not! It says:

  Static ln and static sync are useful when things go wrong. [...]
  Note that these need not be statically compiled versions of the
  standard `ln' and `sync', but may be.

So _no_ binaries are required to be static according to FSSTND.

+---
| As such, under the Linux fsstnd, the root filesystem is a lot fatter
| than it should be.  Imagine all those duplicate copies of /lib and
| /bin for those diskless (and dataless) clients.
+---

Specifically - the FSSTND says that only files needed for restoring or
debugging a system should be kept in '/'. Perhaps /lib/libc is so
large that it will be of little benefit, but it isn't a big deal in
any case. I put together the files required by FSSTND:

  183     /sbin
  955     /bin
  289     /lib
  1710    /

That includes a fat kernel (Soundblaster, SCSI, c509, pc-speaker) and
a statically linked bash 1.13.5, which FSSTND doesn't require (I
didn't feel like recompiling :-)

Compare that to SunOS 4.1.3:

  1150    /sbin
  2478    /

That's with no bash, no tar, no ftp, no nothing. And I didn't even add
the binaries in /etc...

I think FSSTND is a good effort - a lot better than any other layout I
have seen!

(I do have some nits, though, e.g. loadkeys belongs in /usr/bin and
chown in /sbin, IMHO :-)

Kjetil T.

+--- Ren Cougnenc:
| I reformulate my question: Why is *only* the math shared library
| moved to /usr/lib, if there is something to move... ?
+-------

Uhm... only libc should be in /lib -- try
  ldd /sbin/* /bin/* | grep lib | grep -v libc

I trust you're not questioning that?  (libc's "make install" can't
just move X libraries and whatever people have put into their /lib :-)

Kjetil T.

: Ce brave H.J. Lu ecrit:

: > 14)      libm.so.x.y is moved to /usr/lib. Please clean up /lib.

: Just a question: why ?

: It is not important, I just want to understand why it is the only one
: moved from /lib to /usr/lib  :-)

Since none of the binaries that are needed for booting use math functions,
they won't break if the library is unavailable.  It can, therefore, be
moved off the root partition onto the user partition.  It is one of the
issues to make the root partition as small as possible.

Ciao

--
Paul van Spronsen -- Dept. of Computer Science  -- Voice:  +27 21 8084393

awk: can't load library '/lib/libm.so.4'
        No such library.

~# ldd /usr/bin/awk      
        /lib/libm.so.4 (4.0)
        /lib/libc.so.4 (Jump table 4.1)

~# awk -W version
Gnu Awk (gawk) 2.13, patchlevel 2
usage: awk [-F fs] [-v var=val] [-W gawk-opts] -f progfile [--] file ...
       awk [-F fs] [-v var=val] [-W gawk-opts] [--] 'program' file ...

~# mv /usr/lib/libm.so.4.5.21 /lib
~# ldconfig
~# chmod a+r /etc/ld.so.cache

Alvin.

Quote:> >| Since [FSSTND] says things in /bin and /sbin should be static anyway

> >It does not! It says:

> Yes it does (ok, at least for /bin)!

>    Section 3.1. /bin: essential command binaries (for use by all users)
>    [...]
>    The commands (static data) that are needed in single user mode
>    by the super user are stored in /bin.

The `static data' means, I think, just that the files are assumed not
to change during time.  It does not, I think, mean that the files
(programs) should be statically linked.

--

My name is Ozymandias, king of kings/Look on my works, ye Mighty, and despair!

:>Ce brave H.J. Lu ecrit:
:>
:>> 14)   libm.so.x.y is moved to /usr/lib. Please clean up /lib.
:>
:>
:>Just a question: why ?
:>
:>It is not important, I just want to understand why it is the only one
:>moved from /lib to /usr/lib  :-)
:
:It could cause big, big, big problems if you tried to use, say,
:libc.so.x.y before you mounted /usr.
:
:While many people have just one partition with a filesystem, it could
:louse me up pretty good if libc got moved out of /lib and into
:/usr/something.
:
:Of course, I suppose it's a good idea to keep statically linked
:copyies of mount, umount, etc... But if a change like this was made
:without me seeing it, I'd be in big trouble since I assume that If
:I've got / mounted I have my shared libs.
:
:Ack!
:
:Keep all the shared images in /lib!!!
:>
:>--

:
:
:--

:____ "Nuke the unborn gay whales" -- Never seen on a protest sign
:\bi/ |umop apisdn| First year comp sci major.  CRPG *.
: \/  1.5<kinsey<2.5 IRC Synger  Running Linux 0.99.15d. DOS is evil

    It seems silly to move something that a huge number of executables
    in / require to what is most likely a different partition on many
    systems.  So now you have to have two reliable partitions to do
    anything instead of one?  That's silly!

    My root partition is much, much safer then any other partition because
    virtually no files are created, written to, or otherwise modified on it.
    I've been able to shift most of the volatile files onto /var (with a
    partial mirror in the root to allow an emergency boot without mounting
    /var), and what few remain are hardly ever touched.  From my point of
    view, putting the shared libs on the root partition is the SAFEST
    thing you can possibly do with them.

    Also, maybe it's time to fix the stupid absolute-path requirements for
    shared libraries.  Have a shared-lib path for ld.so and make the
    references simply 'libc.so....' instead of '/lib/libc.so....'.  If
    you do that, then people can put the physical libraries whereever they
    like.

                                                -Matt

--

    1005 Apollo Way
    Incline Village, NV. 89451  ham: KC6LVW (no mail drop)
    USA                         Sandel-Avery Engineering (702)831-8000
    [always include a portion of the original email in any response!]

Name one binary within /bin or /sbin that uses libm.so.x.y.  There
aren't any!  Why waste 100k on the root partition for something you
don't need?

Quote:> I agree that shared libraries (indeed _all_ of /lib) should be put
> in /usr/lib.  SunOS has operated this way for many many years.
> There is no need for (in fact it is dangerous to have) shared
> libraries in /.  (what do you do if your shared lib is corrupted?
> You can't boot single-user safely..)

> If Linux ever is to have a consistent way to provide diskless and
> dataless configurations, it is imperative that /lib go the way of
> the dodo.  (indeed in SunOS, /lib is just a symlink to /usr/lib)

> The Linux filesystem Standard sorta leaves it open for future
> debauchery.  It says "Only the shared library images necessary to boot
> the system should be placed in /lib." and that "Shared libraries that
> are only necessary for binaries in /usr do not belong in /lib."

It means "demand paged shared library" rather than "shared library".
This will be cleared up in the next revision.

Quote:> Since it says things in /bin and /sbin should be static anyway, I'm
> left rather puzzled on what /lib is really for.  I'd rather have had
> /sbin for static, binary files needed during boot before /usr is
> mounted, and leave /bin as a symlink to /usr/bin for compatability.

Just where does the FSSTND say that binaries in /bin and /sbin should
be static?  This is not the case.  Before you quote things like this
please be more careful.

The only demand paged shared library which is needed in /lib is
libc.so.x.y.  All others should be stored in /usr/lib.

H.J. Lu's decision to move libm.so.x.y to /usr/lib is a good one.  It
moves something which isn't need in the root filesystem (/lib) into
/usr/lib.

Quote:> As such, under the Linux fsstnd, the root filesystem is a lot fatter
> than it should be.  Imagine all those duplicate copies of /lib and
> /bin for those diskless (and dataless) clients.

You really don't know what the hell you are talking about.

If you actually read the standard, you would know that it clearly
REDUCES the size of the root filesystem.  In fact, that is a major
goal of the FSSTND.  Compare the root filesystem with any FSSTND
conformant system (like Debian) to SLS or any other old distribution.

I would also like to point out that the decision to move libm.so.x.y
out of /lib is not a part of the FSSTND (although I personally feel
that it needed to be done).

Dan

--

NO, it doesn't.  Look up "static" in the dictionary.  In fact, just
try reading section 2 of the same document where "static data" is
defined:

        Static data includes binaries, libraries, documentation, and
        anything that does not change without system administrator
        intervention.

Quote:> The section you quoted is under "OPTIONAL files for /sbin:".
> Like I said, the confusion we see here is a direct result of the
> fact that the FSSTND is muddled.  It needs to be re-written.

When the first version of the standard was released, it was clear that
it was intended for developers.  No other person has some to the
ridiculous conclusions that you have come to now in 2 separate posts.

It was also made clear that changes would be made.  The next revision
will be much clearer.  At the time, it was considered most important
to get it out rather than make it totally perfect.

Quote:>> So _no_ binaries are required to be static according to FSSTND.
> No, the FSSTND doesn't seem to require much at all.  It's a
> recommendation.

It can't require anything.  Linux is free.  Do what you want.  Still,
many Linux developers are moving to the FSSTND because it works.

It doesn't recommend that any binaries be static.  Nothing on Linux
systems needs to be linked statically.  However, FSSTND does leave
this up to developer and administrator preference.

Dan

--

Quote:>(I do have some nits, though, e.g. loadkeys belongs in /usr/bin and
>chown in /sbin, IMHO :-)

loadkeys is needed (or may be needed) when repairing the system,
especially if you have eg a Dvorak keyboard on the console.

How is chown necessary for single-user mode, or is this hysterical
raisins?

--

"He'd never wanted much, except perhaps to be left alone and not woken up
 until midday"                             -- Moving Pictures, Terry Pratchett

[ / vs /usr discussion deleted ]

Quote:

>Now, could your Linux boot diskless or dataless as-is?

>--Dave

Is this the sole reason for moving shared libs to /usr?  Is anyone
*actually* booting Linux from a diskless PC?  and if so, why?

Disks are cheap and IMHO diskless workstations are a waste of network
bandwidth.

----
Mike Kenney
UW Applied Physics Lab

I tried to follow H. J. Lu's recommendation of putting libm.so.4 in to the
/usr/lib directory instead of the /lib directory as I have done for the
previous releases. However, some of the binaries expect to find libm.so.4 in
/lib instead of in /usr/lib (while others don't seem to have this problem). Why
is this? My guess is that the older versions of the compiler linked the
binaries with a hard value while the later versions uses some sort of table
that they can look up dynamically. The question, of course, is whether it's
possible to change the behavior of the old binaries without having to rebuild
them from scratch. Thanks.

--
=Howard Pan=                    These are the official views of
617-621-2964                            His Imperial Highness

There shouldn't be anything in the root partition that requires
libm.so.x.y.  If you refer to libc.so.x.y, it has not been removed
from /lib.  Only libm has been moved.

Quote:> My root partition is much, much safer then any other partition
> because virtually no files are created, written to, or otherwise
> modified on it.  I've been able to shift most of the volatile files
> onto /var (with a partial mirror in the root to allow an emergency
> boot without mounting /var), and what few remain are hardly ever
> touched.  From my point of view, putting the shared libs on the root
> partition is the SAFEST thing you can possibly do with them.

You only need one demand paged shared library on the root partition.
That is /lib/libc.so.x.y.  The safety of the root partition is not
just a function of writing/creating/modifying, but also size.  The
larger the root partition is, the greater the chance for a random
error to occur on it.

There are other reasons to reduce the size of the root partition, such
as allowing for diskless systems which can then mount /usr via NFS.

There are 1.5 megs of demand paged shared libraries (.so files) on my
system, not including libm.so.x.y and libc.so.x.y.  Why would you want
to increase the size of root by 1.5 megs for things which are not
needed for anything on your root partition?  It is much more sensible
to move them all to /usr/lib (and /usr/X386/lib).

Dan

--

Unless I have misunderstood, the FSSTND in no way prevents anyone
from doing this.  The result is still conforming to the FSSTND.

Quote:> If for adminstrative reasons you want to be able to be more
> self-sufficient in case /usr fails or is unavailable, then put
> static copies of binaries like fsck, tar, mv and cp in /sbin.

Those static copies make the root partition way too big, IMHO.

Quote:> That way those with diskless and dataless configurations
> are happier, and backups of host-specific files are easier and
> smaller since you just can back up the root filesystem without having
> to manually include or exclude files.

But people with no need for diskless and dataless configurations
(most of us) are less happy, since it complicates things for them.
An old optimization problem: should one optimize for the common
case, or for the especially troublesome special case?  As it is now,
the FSSTND is optimized more for the common case, in that it is for
the special case that needs more work by the distribution provider
and/or the system administrator.

--

My name is Ozymandias, king of kings/Look on my works, ye Mighty, and despair!

:
:
:> It seems silly to move something that a huge number of executables
:> in / require to what is most likely a different partition on many
:> systems.  So now you have to have two reliable partitions to do
:> anything instead of one?  That's silly!
:
:There shouldn't be anything in the root partition that requires
:libm.so.x.y.  If you refer to libc.so.x.y, it has not been removed
:from /lib.  Only libm has been moved.
:
:> My root partition is much, much safer then any other partition
:> because virtually no files are created, written to, or otherwise
:> modified on it.  I've been able to shift most of the volatile files
:> onto /var (with a partial mirror in the root to allow an emergency
:> boot without mounting /var), and what few remain are hardly ever
:> touched.  From my point of view, putting the shared libs on the root
:> partition is the SAFEST thing you can possibly do with them.
:
:You only need one demand paged shared library on the root partition.
:That is /lib/libc.so.x.y.  The safety of the root partition is not
:just a function of writing/creating/modifying, but also size.  The
:larger the root partition is, the greater the chance for a random
:error to occur on it.
:
:There are other reasons to reduce the size of the root partition, such
:as allowing for diskless systems which can then mount /usr via NFS.
:
:There are 1.5 megs of demand paged shared libraries (.so files) on my
:system, not including libm.so.x.y and libc.so.x.y.  Why would you want
:to increase the size of root by 1.5 megs for things which are not
:needed for anything on your root partition?  It is much more sensible
:to move them all to /usr/lib (and /usr/X386/lib).
:
:Dan
:
:--

    libc and libm have traditionally gone together, and just because
    most CURRENT boot-related binaries don't use libm is no reason
    to split them up.  libm or its equivalent is already necessary for
    booting on some machines (like the NeXT).

    If you are looking for a diskless workstation config all you need
    to do is make a few boot-related binaries static and put ALL your
    libraries under NFS!  That takes even less space.

    Splitting libc and libm is a mistake, and if it's going to be done
    I really, really, really would like a LIBPATH to be implemented and
    the absolute nature of ld.so's current library paths made relative.

    Sure I can put softlinks all over the place, but I'd rather have
    a clean setup.  LIBPATH would obviously default to /lib, /usr/lib,
    and /usr/local/lib.

    That is a request :-)  Then we can all go our merry way.

                                                -Matt

--

    1005 Apollo Way
    Incline Village, NV. 89451  ham: KC6LVW (no mail drop)
    USA                         Sandel-Avery Engineering (702)831-8000
    [always include a portion of the original email in any response!]