Slashdot Mirror
Dynamic Root Support For FreeBSD Now Available
Dan writes "FreeBSD's Gordon Tetlow has committed his enhancements to enable users to build /bin
and /sbin dynamically linked on FreeBSD. His reason to do this is two-fold. One is to give better support for PAM and NSS in the base system. The second is to save some disk space. Currently (on his x86 box), /bin and /sbin are 32 MB. With a dynamically linked root (and some pruning of some binaries), the /bin, /lib, and /sbin come out to 6.1 MB. This should be great for people with 2.x and 3.x era root partitions that are only about 50 MB. Gordon says that there will be a performance hit associated with this. He did a quick measurement at boot and his boot time (from invocation of /etc/rc to the login prompt) went from 12 seconds with a static root to 15 seconds with a dynamic root."
not only will this affect performance, but it will also make it impossible to recover a server if you accidentally delete /usr,
there are less and less reasons to use seperate partitions for root directories, and this is *NOT GOOD*
Mostly because very, very few people think that this is a good idea.
Programming can be fun again. Film at 11.
This is just an option. The default way is still via static binaries.
This won't change for some time (wheather it will change at all still has to be discussed).
I'd imagine that if NetBSD and OpenBSD don't already have this ability it will be a matter of time as the BSD's share much between each other. Just look at the realpath vulnerability that they all were affected by.
Only 'flamers' flame!
Does slashdot hate my posts?
Not that Dragonfly doesn't look interesting, but, erm, I guess I'll give it some time to mature before I consider it for any critical system. My next update will definitely be to FBSD 5-STABLE.
Programming can be fun again. Film at 11.
"Because Linux does it" is not always a good reason to do something. Linux developers tend to throw anything and everything they can into the mix. BSD developers tend to watch what others do, research the pros/cons, then develop a plan on how to do it right ... before tackling the coding.
:)
Hence, while Linux distros tend to get things first, BSD tends to get things right.
...was that, in earlier *nixes, sbin programs were always statically linked, to avoid problems with requiring
Not necessarily FreeBSD, but just some flavor of Unix. The versions of Digital Unix (under different names) which I teethed on were designed like this.
It's always annoyed me that Linux's [/usr]/sbin was dynamically linked.
You cannot apply a technological solution to a sociological problem. (Edwards' Law)
Not really, The binary is smaller, the execution loader caches the common code, both in memory and from disk. By increasing the amount of common code, those utilities should actually load faster.
This is a boring sig
It's good that they are trying to save disk space, but why don't they just rewrite them so they don't use libc? Linux assembly.org is working on such a project, though it doesn't have to be in assembly. I've done some work using direct syscalls in Linux with C (look at /usr/include/asm--start with unistd.h). I haven't looked at FreeBSD in this way yet, but I think it can be done. At the very least, simple utilities like cp and ln could be written this way. Save disk space and be staticly linked--good all the way around.
Yeesh, lighten up, eh? There's a reason for the :) in the above post.
:D
All I was saying was that "Because Linux has it" is not a good enough reason to implement a feature. That would be like saying "Why doesn't Linux support VBScript in the kernel? MS Windows has it, so it must be good."
As to my credentials, what does that have to do with anything??
Ah well, what can one expect when posting to Slashdot?
BSD is Dead??
http://uptime.netcraft.com/perf/reports/Hosters
I guess Linux-Kiddies can't read.
Choke on it and die.
It really depends if your a pesimist, or an optimist. Yes 3 units of 12 is indeed 25%, and since it is 3 units over 12 to 15 it could be seen as an additional 25% extra time. The more correct way to look at it is from the point of view for the number 15. aka the boot was an entire 1/5 faster without dynamic bins.
/bin and /sbin stuff static, but thats what /rescue is for with the crunched bins. Besides, this will only lead to a more optimised ld program and linking system there after. Not having the entire bulk of libc repliated allover the place in /bin and /sbin is entirly acceptible to me. Architecturally speaking that is a big faux pax to leave such a clutter. This is why elf was devised in the first place, and slow to implement Operating Environments is partly to blame for the hindering of cool features like dynamic linking tricks such as thosed used in pam and nss. This is, after all, the reason we have libraries.
Besides, there have also been improvements in caching libs in conjunction with linking so that dynamic bin's always load faster. It could also be possible to make certain
It isn't a lie if you belive it.
How about some utils which are written in assembly and are not dependent upon other libs? They're faster and smaller. You may want to look at LinuxAssembly.org's asm utils. They say it works for FreeBSD and other BSDs, though I haven't tested this myself (yet). When I tried them in Linux a few years ago, they weren't quite complete, but being small and independent has its advantages. When it's complete (maybe it is now?), I imagine these programs will be the choice for those who want to save disk space or speed up their system. Such a project would work in C. If it was in C, it would probably get more developers on board too...
Hence, while Linux distros tend to get things first, BSD tends to get things right.
:-). More recently, first to implement IP6, Serial ATA, Hyperthreading, etc. I would have to check, but I think they got USB and Firewire first as well.
Actually, BSD gets a lot things first. First to have a commercial support, first to have a free and complete operating system, and first to get sued by obnoxious companies
A Government Is a Body of People, Usually Notably Ungoverned
Riiiiight. Thats under a meg a minute. Clearly this is a fabricated post. Show me some ps and vmstat/etc output, and i will newfs freebsd off right away.
NetBSD was the first (free unix-like OS) to have USB indeed.
And destroy the portability of the system to other archs while you are at it...
Subsequent runs of said binaries will be just as fast (and perhaps faster) as your cache usage will be optimized with libc mapped once.
Isn't this the tradeoff for lots of neat optimizations? A little extra overhead at the start for amortized gains?
THIS THING CAN TURN ON A DIME, MACROSSZERO STYLE ALSO FUCK BETA, ~NYORON
Yes, these programs don't work on non-IA32 systems, but if someone needs to save space or wants more speed and they have an IA32 system, why not use them? The same thing could be done in C, thus preserving portability...
enable users to build /bin and /sbin dynamically linked on FreeBSD
/bin or /sbin; for some executable library $L in /lib; there exists some subroutine $p in $P and some object $l in $L such that $p uses $l.
/bin or /sbin. The new behavior is achieved by removing the arbitrary, stupid prohibition.
I am having difficulty parsing this, and neither the article nor the comments here help me. This is my best guess. Someone please correct me.
SITUATION: For some executable program $P in
OLD BEHAVIOR: When building $P, static-linker resolves name "$l", yielding an address or the desired data.
NEW BEHAVIOR: When executing $P, dynamic-linker resolves name "$l", yielding an address or the desired data.
DETAILS OF CHANGE: The kernel enforced the old behavior by examining every request sent to the generic 'dynamic-link' facility and blocked any requests which involved programs which happened to be in
ALTERNATIVE DETAILS OF CHANGE: The old behavior was enforced by the build scripts for $P and $L; we didn't want our super-important $P to be disturbed if something as lame as the dynamic linker crapped out on us. The new behavior is achieved by changing some compiler flags. We will all die when the dynamic linker craps out.
But not as we know it.
I fail to see the benefit of this.
/bin and /sbin, only those critical
to basic system functioning (or better yet,
something like a FreeBSD equivalent to
BusyBox (which I've used to create embedded
Linux distros that needed to fit in 8MB of
flash and have basic X functionality),
for a whopping 300k).
A 25% absolute performance penalty, at the relative "gain" of 82% of a small part of the filesystem. However, compared to even an incredibly small (by today's standards) 1GB partition, you talk about saving only 2.5% of the total disk space. On any reasonable drive, this would equal far less than 1% savings.
Now, in an embedded environment, such a savings might make a noticeable difference. However, in an embedded environment, you wouldn't have every app ever considered useful in
As for "people with 2.x and 3.x era root partitions"... C'mon, really... Throw in the "older means better" towel and upgrade. Seriously. I have single OGG files (of full CDs) larger than 50MB. Hell, I gave up on DOS 3.3 because of the 32MB partition limit nearly a decade ago. Upgrade. Upgrade. Upgrade! Sometimes "obsolescence" doesn't need to have the word "planned" in front of it, you just need to accept that PC-level hardware has vastly improved since limitations like that seemed even remotely acceptible.
So... Can someone explain why this matters, beyond the "because we can" factor?
Arrgh! If you're not going to statically link the stuff, don't put it in /sbin! Arrrgh.
Bill Stewart
New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks
Actually, there's overhead in the loader - resolving symbols and checking libraries takes a while.
Eh. It's not exactly universal though. OpenBSD doesn't even do MP, much less hyperthreading (if you think these are two very different issues, go read the god damn IA-32 System Developer Manual). Acttually, I think NetBSD is the same deal right now. FreeBSD has MP though.
====
Crudely Drawn Games