Return to BSD News archive
Xref: sserve comp.os.386bsd.questions:11084 gnu.misc.discuss:15346
Path: sserve!newshost.anu.edu.au!harbinger.cc.monash.edu.au!msuinfo!agate!howland.reston.ans.net!swrinde!emory!cherry.atlanta.com!nntp.mindspring.com!usenet
From: rsanders@mindspring.com (Robert Sanders)
Newsgroups: comp.os.386bsd.questions,gnu.misc.discuss
Subject: Re: Taylor UUCP on FreeBSD???
Date: 22 Jun 1994 15:06:39 GMT
Organization: MindSpring Enterprises, Inc.
Lines: 72
Message-ID: <RSANDERS.94Jun22110639@hrothgar.mindspring.com>
References: <1994Jun13.040754.17764@kosman.uucp> <GOWEN.94Jun21084913@presto.cs.tufts.edu>
<2u73ti$egn@glitnir.ifi.uio.no>
<RSANDERS.94Jun21155032@hrothgar.mindspring.com>
<2u7tcb$6mr@pdq.coe.montana.edu>
NNTP-Posting-Host: msdem5.mindspring.com
In-reply-to: nate@bsd.coe.montana.edu's message of 21 Jun 94 23:33:31 GMT
In article <2u7tcb$6mr@pdq.coe.montana.edu> nate@bsd.coe.montana.edu (Nate Williams) writes:
>Well, that's a valid argument on Linux, but FreeBSD (and I suppose
>NetBSD) think that shared libraries belong in /usr/lib. I disagree,
As a FreeBSD developer, I'll give a quick WHY we did it that way.
1) / (root) should be small.
2) Given the above, putting the entire shared library in /root makes
no sense due to size, even offsetting the savings in the small
number of shared binaries.
Linux's shared libc and libm add up to about 280K (they look bigger,
but they contain holes). I really couldn't tell you for sure how much
space I save in /bin and /sbin with shared libraries, but I'm sure
it's close to that. FreeBSD may have a significantly larger libc.so
because of its more ELF-like dynamic linking.
3) Breaking up a standalone library for the root partition is wasteful
since the code will be also needed for other binaries.
Could you explain this a little more? I'm not sure I understand.
4) In the case of a bad crash using the Mach VM system in BSD systems you
*CAN* corrupt the running binary, which in the case of shared binaries
can be the shared library. (The way paging is done)
You mean a file mapped into memory in such a way that changes
shouldn't be committed to disk can still get corrupted? That's a bug.
5) ld.so doesn't NEED to be in /root, and there is less likely for
something bad to get hosed up when doing updates. The more dependant
you are on particular tools, the more likely one of them is to break.
Upon bootup there are 2 CRITICAL binaries. 'init' and 'sh' for
safety reasons should be linked static IMHO.
This is a different argument from whether or not the shared libraries
should be accessible at boottime and used by binaries on the root
partition. I have no argument with this.
>install bash as /bin/sh because ash just wouldn't cut several scripts
>we used.
Fix ash. :-)
Although I normally find the FreeBSD developers as reasonable as any
people on Usenet, this is definitely from left field. Let's compact
all this discussion into a quick dialogue:
user: "Hey, ash doesn't run some standard 'sh' scripts, but bash
does."
nate: "ash is smaller. You don't need the interactive bloat for
/bin/sh."
user: "Smaller, yes, but it doesn't work."
nate: "So fix ash."
It seems to me that as one of the principal developers of a respected
and important operating system, it should be more important to you
that things work than is apparent here. Admittedly, the lure of a
lean, fast system is a tempting one, but if it's just rushing headlong
to brokenness, I'll do without, thanks.
The fact is that you chose a broken ash over a much less broken bash
as your /bin/sh, and unless you plan to fix ash's bugs, it's not a
very wise decision. You want me to fix ash? Sure.
rm /bin/sh
ln /bin/bash /bin/sh
There. Now it works. :-)
-- Robert