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
BSD people are losers who need to feel "different". It is much like self-proclaimed homosexuals. You have an empty spot in your psyche which requires your constant need always to be associated with the peculiar and different. Your most important concern in life is hardly the operating system itself. It is the need to feel "special". Maybe your momma didn't cuddle you enough, who knows.
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
Nice troll. Excellent lack of supporting evidence. Good use of capalization for effect.
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
BSD people are losers who need to feel "different". It is much like self-proclaimed homosexuals. You have an empty spot in your psyche which requires your constant need always to be associated with the peculiar and different. Your most important concern in life is hardly the operating system itself. It is the need to feel "special". Maybe your momma didn't cuddle you enough, who knows.
And the fact that you feel the need to make disparaging comments about an operating system whose logo isn't a fattened penguin speaks volumes about your psyche.
(I'm anticipating a mature "Fuck you!" response, as is typical of you trolls.)
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.
Is there good directions for doing this?
Really I have looked.
(installing from a release is to cvsup the latest sources) that is and rebuild world.
I have googled and read The Complete FreeBSD book.
I just install over the internet using the latest builds. That way you don't need to recompile until *new* security anouncments come out.
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
OpenBSD is the only pure BSD remaining.
BSD isn't dead. The next Windows will be based on it. Read more.
The Uncoveror: It's the real news.
Have you ever seen an animal backed into a corner and fighting for its life? That is the situation FreeBSD finds itself in. The FreeBSD fans are in a state of desperation, and even the mildest criticism of their hobby horse results in wild and paranoid outburts from the faithful. They will find an alibi and excuse for everything. Truth has nothing to do with it.
It sucks. What if you hose your floppy drive and can't boot from a floppy. Then you are really fucked. You might have to go down to Fry's and buy a new one.
We are talking about a dead operating sytem here. FreeBSD is on its last legs. It has been abandoned by everyone save for a few die hard hobbyists. Fella, it's dead. FreeBSD, that is. It's dead.
NetBSD just isn't stable enough. Sorry, but I need more stability than NetBSD can offer.
You know, NetBSD just isn't stable enough. Sorry, but I need more stability than NetBSD can offer.
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 is dying. It is a joke for losers.
This patch should have been committed on April 1st right ?
And the delay would be an inside joke....
Fuck you!
I can think of nothing more stable than a desiccated corpse.
What is "Everything" in that sentence? I've installed dozens of BSD servers and have always been able (eventually) to get what I was trying to achieve working. Once working, it runs forever and is rock-solid. The "truth" is, it is the most reliable operating system, period. I have no alibi or excuse required.
"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.
A correctly set up Linux machine can be exactly as stable as a correctly set up BSD server. I mean "exactly" to be literal, as either one will run literally forever unless its hardware dies or it loses power.
Very often you have to spend a lot of time to setup Linux correctly. And second thing is upgradability, which is a mess in a Linux world.
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!
I don't want to start a jihad here, but what is the deal with you abacus fanatics? I've been sitting here at my freelance gig in front of a abacus box (8 rows, 12 beads each) for about 20 minutes now while it attempts to copy a 17 Meg file from one folder on the hard drive to another folder. 20 minutes. At home, on my Pentium Pro 200 running TI99/4a, which by all standards should be a lot slower than this abacus box, the same operation would take about 2 minutes. If that. In addition, during this file transfer, Netscape will not work. And everything else has ground to a halt. Even Emacs Lite is straining to keep up as I type this.
I won't bore you with the laundry list of other problems that I've encountered while working on various abacus machines, but suffice it to say there have been many, not the least of which is I've never seen a abacus box that has run faster than its Windows counterpart, despite the abacus machines faster chip architecture. My ti 99 4/a with 8 megs of ram runs faster than this 800 mhz machine at times. From a productivity standpoint, I don't get how people can claim that an abacus is a "superior" machine.
Abacus addicts, flame me if you'd like, but I'd rather hear some intelligent reasons why anyone would choose to use an abacus over other faster, cheaper, more stable systems.
no factual evidence to support superiority claims
arrogant attitude
etc.
Rebuilding world is like playing with yourself. In the end your are left with a big wad of jizz.
Are you stupid, or do you just play that on the 'Net?
/bin and /sbin has been moved into /rescue. Only the few utils needed to RESCUE a b0rked system are in there. Maybe 10% of the bins from /bin and /sbin. And, they have been crunched down to a smaller size.
/bin and /sbin no longer include a copy of every single lib they need. There is only 1 copy of each lib on the harddrive now, and only 1 copy in RAM. Do you see the space savings now?? If not, you really shouldn't be posting on here, you need to take a few elementary courses in math.
Not every single binary in
The bins in
So much for slashdot being a place for nerds.
The record is clear on one thing: no operating system has ever come back from the grave. Efforts to resuscitate *BSD are one step away from spiritualists wishing to communicate with the dead. As the situation grows more desperate for the adherents of this doomed OS, the sorrow takes hold. An unremitting gloom hangs like a death shroud over a once hopeful *BSD community. The hope is gone; a mournful nostalgia has settled in. Now is the end time for *BSD.
For a production system, you track the RELENG branch using CVSUP, not the STABLE branch or the CURRENT branch. This adds patches to the system to fix security holes that may have been found since the release of the RELEASE version.
If you were a BSD admin you'd know what I'm talking about, but since your question suggests otherwise, just stfu and rtfm.
M'kay? thnx.
You sure pump yourself up to be an all knowing kinda guy don't ya. What about patching holes that have been found since the release of the RELEASE branch ? How do you do that wise guy ?
If you say you've been using UNIX longer than 21 years, (and FreeBSD since the time it was created) it sure as hell doesn't seem like it.
To answer my above question, you'd use the RELENG cvsup tag to upgrade the system the first time you install it. And yes this does require a buildworld and a buildkernel and an installkernel.
Here's the relevant cvsup tag for 4.9-RELEASE:
RELENG_4_9
The release branch for FreeBSD-4.9, used only for security advisories and other seriously critical fixes.
Now go fuck yourself oldtimer.
Damn, you couldn't have said that any better. Isn't that a fact!
Junk article. Junk web site. Hardly credible.
So don't do anything. You already have
the feature.
How come you have to change your shell? Don't you only have a system failure every once in a great great great while? It seems to me that you don't really have to change anything and once your disks are trashed is having a staticly linked binary in another directory going to cause you grief? I just don't understand the problem here.
Consider that because of the many troubles of Walnut Creek, abysmal sales and so on, FreeBSD went out of business and was taken over by BSDI who sell another troubled OS. Now BSDI is also dead, its corpse turned over to yet another charnel house.
All major marketing surveys show that *BSD has steadily declined in market share. *BSD is very sick and its long term survival prospects are infinitesimally dim. If *BSD is to survive at all it will be among hobbyist dilettante dabblers. In truth, for all practical purposes *BSD is already dead. It is a dead man walking.
Most reliable? You've obviously never used VMS. Cretin. And why do you think QNX is used in nuclear power plants?
Think outside your little bedroom, kiddo.
You still have a terrible grasp of English, though.
Whatever you say, kid.
C-x C-c
# vim
FreeBSD is a faggot OS for gay homosexual faggots butt boys.
I've just installed FreeBSD 5.2 Beta and had a first hand look at this new dynamically linked /bin and /sbin and I have nothing good to say about it.
/recover directory weighs in at a whopping 475.8 MB! This is not tollerable!
/recovery, and I can say for the first time since I discovered FreeBSD, "this sucks," so much so in fact that I am seriously tempted to go back to the Linux and GNU world. At least with their solution, I could say that I expected it.
While it seems to be true that the dynamic situation has cut back these two dirs from ~33 MB to ~4 MB, the new
Add the insulting fact that a corrupted libc now requires that I reboot my machine so that I can use this new behemoth
Sure I could recompile the base system without the dynamic stuff, but like one other poster here said,
"Or, FreeBSD could just NOT BE STUPID OUT OF THE BOX."
I'm sure that you guys thought that this would be a good idea, but in one move you've managed to suckify FreeBSD to the point that it is no better than the many Linux distributions out there.
This is a sad day for me. Although I doubt that my request would be granted, perhaps this could be rectified by offering two versions of the -RELEASE isos, one dynamically linked, and the other not.
> 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