Slashdot Mirror
/bin And /sbin Now Dynamically Linked In FreeBSD
Dan writes "Gordon Tetlow just committed a patch in FreeBSD current to change /bin and /sbin from statically to dynamically linked. The reason to do this is two-fold. This feature brings support for loadable PAM and NSS modules to base system utilities located in those directories. It also reduces the storage requirements for the root filesystem due to the use of shared libraries. This feature can be disabled in a buildworld by defining the Makefile (make.conf) variable WITHOUT_DYNAMICROOT. Note that statically-linked, crunched executables are available in the /rescue directory for use during system repair and recovery operations."
The reason behind having /bin and /sbin as static linked is so that if you upgraded the libc and it failed, you still have a working system.
/bin or /sbin . With the old system, you didnt have to shut down to do a libc recovery. Now you do.
Be aware that now with this syetm, you wont be able to mv the crunched static exec's to
Baaaad.
I'm still somewhat surprised that this got committed now, shouldn't 5.2 be released Really Soon Now? This looks like something that ought to be tested in -CURRENT for a good while.
Programming can be fun again. Film at 11.
Of course it is.
/bin && /sbin binaries are treated in a release as significant as FreeBSD, is definitely news for nerds, stuff that matters.
/sbin has been a significant issue in Unix-user/-admin land for many, many years. This change now sets in place a new scheme for administrators to understand and work around - with the new linking flag, admins can set up systems in new and interesting ways.
... and thus, this *IS* important news for slashdot.
...
How the
The static nature of
Any FreeBSD admin who now doesn't understand the reasoning and potential problems of this new linking scheme will *definitely* need to learn it and understand it if they want to continue doing a good admin job in the future.
One good way to learn about this and use it is to read the comments from slashdot readers about this issue
Just because SCO/MICROSOFT/LINUX isn't in the article, doesn't mean its not important
; -- the corruption of government starts with its secrets. a truly free people keep no secrets. --
You do realize this was posted in the BSD section of Slashdot, right?
So why they did it now not centuries ago? I mean dynamic linking has been known widely used concept for a while now.
Because, if you read the article, the script to make this possible in the FreeBSD build process has been recently introduced, and is a good tool to do this with.
It doesn't matter if 'dynamic linking' is old technology or not - the fact that this change has been made (and, it appears, generally accepted) is news.
; -- the corruption of government starts with its secrets. a truly free people keep no secrets. --
It might even serve as a 'news item' that is a clear warning to some FreeBSD users who don't follow all the newsgroups and discussion threads, but who would view this as a negative thing for FreeBSD when made aware of it. For which reason it's an excellent topic heading/article for Slashdot to cover.
It's always seemed to me like FreeBSD is the 'compromise for Performance' BSD version. They make no pretense of being widely cross-platform, and do things like this, which break basic 'rules' of the UNIX system, for tweaky/performance reasons. The thing this sort of thing reminds me of is when Microsoft pulled the graphical subsystem into the Windows NT kernal layer 'to enhance performance.'
A Good Intro to NetBS
I don't agree with you. This will make patching and updating the system far easier than before and it will reduce disk space requirements, which should always be a goal no matter how big hard drives get. My only concern would be in regards to a performnace hit.
And yes, you do sound like a troll.
One of the main advantages of this is that you can replace libraries with security loopholes without having to rebuild everything. There have been several cases of bugs in the standard libraries that have required the statically compiled programs in /bin to be rebuilt.
I thought *nix was designed as:
/ - minimum required to boot and repair system
If your system ever became damaged, you booted to / and fixed it. If / is too large, then audit what's in there and make sure it contains the bare minimum required.
Adding /rescue is unnecessarily cluttering up the system.
Is the Original Unix Way the One True Way? Let us go back to before dynamic linkers ever existed. Let us give up SMP. Let us return to our roots, as technologically advanced as Windows 95.
/bin and /sbin could be harmful, so they put static (but crunched) binaries in /rescue. Stick ANY Linux distribution in and see if they do the same. No, Linux just screws you over if you hose ld-linux or libc. (Unless you've had the foresight to install sash.)
To stop evolving is to die. They knew having a dynamically linked
Rather than camping out in the past and watching the world race on ahead of them, FreeBSD is providing flexibility (at a small cost to performance, in this case) while taking care to avoid erasing past wisdom. I can't see how that compares to putting GDI into the Windows kernel.
__CmdrTHAC0__
In Soviet Russia, Spanish Inquisition doesn't expect YOU!!
Yeah, you sure do sound like a troll, with such an adversarial tone. Also by claiming to know what 99% of users want. (Don't forget, 87% of statistics are made up on the spot.)
If I were to say anything about 99% of users, it's that they'll never hose the system to the point where they'll need to care.
And incidentally, for those upgrading by CVSup from an earlier release, they'll be recompiling the system anyway.
Finally, would you mind justifying exactly why this is so bad, for us poor, unenlightened masses?
__CmdrTHAC0__
In Soviet Russia, Spanish Inquisition doesn't expect YOU!!
You have obviously never installed a freeBSD system.
The FIRST thing that I do after installing from a release is to cvsup the latest sources.
This requires me to rebuild the world.
From my experience with freebsd, well over 75% of admins do this. And the other (less than) 25% probably don't even patch, so they won't care anyway.
SO, if you don't want it, put the option in right before you update.
Not Free(as in beer). Free(as in "I'm free to beat you over the head for being a dumbass")
Let me guess -- you don't understand why the article is important, therefore you feel the need to insult the article poster.
May we never see th
M-x ispell-buffer
Didn't the Amiga Operating System do this nearly two decades ago?
If not, how does this differ?
Please consider making an automatic monthly recurring donation to the EFF
I thought one of the reasons we have /sbin is so that we can run the binaries there without having dynamic libraries involved.
/sbin statically-linked, anyway?
Reasons being:
1) Size: Running in single-user mode or small kernels that don't use dynamically-linked libraries.
2) Security: No risk of library-path-based security exploits.
Am I missing something here? Why isn't
Kris
Kriston
How would you go about doing all this yourself in some Linux distribution?
Just recompile all the system tools with dynamic linkage and you're done?
Anyway, my root partition is only 20 Mb, and that's including root's home(not that there is anything there now...). Do I really have to?
How do you get this into Linux? Why, do what they've been doing for years -- copy the BSD source, remove the copyright, and call it Linux.
okay, maybe it's just me, and maybe I'm wrong. But I was under the impression that /bin /sbin's primary reason for existance was the same hole this /rescue directory will be filling? And how does it use LESS space (as if space were an issue anymore compared to speed in which case static is USUALLY, not always, better anyway), to simply move the static versions of the binaries in /bin and /sbin to /rescue and add dynamic versions to /bin and /sbin.
/rescue now becomes as fundementally critical as /bin and /sbin have been before it certainly counts as part of the base system. If you move the static binaries, and add something, isn't that BIGGER than just the static binaries?
Since
They make no pretense of being widely cross-platform, and do things like this, which break basic 'rules' of the UNIX system, for tweaky/performance reasons.
Huh???
No, I would say that FreeBSD is the 'Stable over features'BSD version. The interface has not changed, your shell scripts, mounts, etc, etc will work just fine.
BTW, this was done for anything but performance. If anything, this will hurt performance of those binaries (but then again, how often do you really really use those binaries anyway???). It was done to allow more functionality(sp) for the system.
BWP
BSD isn't dead. The next Windows will be based on it. Read more.
The Uncoveror: It's the real news.
I wonder if anyone screaming about what a HORRIBLE idea this is and how it will cause cancer in kittens, has actually tried it? Obviously the FreeBSD developers are not dumb, and root will always be able to get on to use /rescue, and the advantages are a lot more sophisticated than just saving some space on the root partition.
It's pretty knee-jerk to scream about it if you don't actually know how it's been implemented.
J
"FreeBSD update" doesn't work for those of us tracking 5.x-RELEASE, and it only provides binary updates for the IA32 (i386-family) port.
I'm proud of my Northern Tibetian Heritage
Actually, no. Dynamically linked binaries are slower than statically linked ones.
(8-DCS)
I agree that patching will be easier, unless you patch a library bug that shows up in the new /recovery tools. I'm not so sure about making the overall disk space requirement smaller, if the /recover tools are even close to the full set of stuff that is now dynamically linked the total disk use is higher. The only saving grace there is you might not put /recover on the same disk partition as /. Not really a win.
So patching is in some cases better, total disk space usage is probably up, and performance is probably down a little bit (unmemorable unless you are looking for it). Not in my opinion a good change, but not bad enough to send me scurrying off to AnotherBSD, not by a long shot. In the grand scheme of things it is a tiny change.
The last paper I read on dynamic linking showed about a 2% penalty on RISC CPUs and a bit over 10% on CISCs (losing one of 16+ registers to hold a libs base pointer hurts less then losing one of "about 4 to 8" registers!). That was a long time ago though, around when Sun added them to SunOS, maybe the early 90s or late 80s. Very short running programs (ls and echo) were hurt a lot more. Oddly enough some very small programs (like cat and echo) were larger as dynamic linked code (more disk space used to record the static code to invoke the dynamic linker, and to hold the symbols to link).
It mattered to me more then too. I didn't have SunOS source so any lib bug I wanted to fix, or lib call I wanted to improve wasn't gonna happen for the static programs.
Why do you do it?
Just to have something new and shiny in your hands?
In case of production system one have to use RELEASE, as it was thorough tested. The need for upgrade arise in case of security issues or performance improvements. And then one have to recompile only parts affected.
So far I do not know anybody who rebuild the world for production system.
In case one tracking CURRENT and it's definitely not a production - it may be some support system, though, it's just easier to cvsup and make world. And just revert back in case something went wrong - it happens...
YOU obviously haven't seen my server racks. And, you don't know who I am either. I have been using unix longer than you've been alive, likely, and I've certainly installed FreeBSD a few times.
Anyway, as others have stated, in a production enviroment, its incredably stupid to run with the bleeding edge.
When you have several thousand customers accessing your servers, you can't exactly turn them off, recompile the OS, and reboot.
Sure, you could build extra redundant servers, grab new sources on off-peak hours... but by then you could have just used another system instead.
And if you seriously think its a good idea to only grab new sources once (upon install), then well, thats just silly!
> but then again, how often do you really really use those binaries anyway???
/bin/ls! Surely no one could ever care about its performance!
You're right. I never use