login
Search
Luke Mewburn recently announced that the -current branch of NetBSD has recently switched to being a fully dynamically linked system. That is to say, even binaries in /bin and /sbin are dynamically linked to libraries in /lib. The end result is a smaller / (root) directory, saving about 11.5 MB on an i386 system. A new /rescue directory adds around 2.5 MB of statically linked "rescue" binaries, so the net space savings is still around 9 MB.
Work is actively being done to speed the start-up times of dynamically linked binaries, which is typically slower then that of statically linked binaries. Read on for the full explanation, and links to much discussion on the change.
From: Luke Mewburn
To: None current-users AT netbsd.org
Subject: HEADS UP: fully dynamic linked system now the default
Date: 09/23/2002 01:25:59
As mentioned a few weeks ago, we've switched to a fully dynamically
linked system by default.
The net outcome:
+ /bin and /sbin are dynamically linked, along with the small
number of programs in /usr/* that were still statically
linked.
+ The shared libraries that are required by /bin and /sbin
are installed in /lib, with symlinks from /usr/lib for
compatibility purposes.
+ The dynamic linker is installed in /libexec, with a symlinks
from /usr/libexec for compatibility purposes.
+ Less disk space used on `/'. On the i386, the savings are
in the order of 11.5 MB (4.5 MB versus 16 MB). If the space
consumed by /rescue is counted only in the "new" system,
there's still a 9 MB saving.
+ Specific rescue tools are provided in /rescue, rather than
overloading /bin and /sbin for that purpose.
+ The kernel's "-a" bootloader option now also prompts for the
path to init(8), so "/rescue/init" can be used if /sbin/init
won't start due to an unexpected failure.
+ Whilst dynamic linked programs start up slower that statically
linked programs, there is active work in progress to resolve
this issue.
If you don't want this behaviour, set MKDYNAMICROOT=no in mk.conf(5).
Luke.
FreeBSD is cool
Go FreeBSD. After removing Perl from the base system
they must have a tiny base system.
When the FSF bring out GNU 1.0 I hope they take
example from FreeBSD (as well as debian).
my mistake
Oops, I somehow misread the title.
Good to here this news from the NetBSD crowd then.
> and NetBSD never had perl in the base system.
good too :)
NetBSD
This has nothing to do with FreeBSD if you read the article you should have noticed "NetBSD" being mention several times. As for GNU 1.0 well it was late back in 1991 so i think you will be waiting awhile ;)
Really?
Hi!
What makes you so sure that GNU 1.0 is so far away?
Cheers,
GNU/Wolfgang
Horrible Action
A big step towards Linux, and a big step backwards for all system administrators.
Nobody needed dynamically linked executables in root (/), and the explanations are mere silly excuses for unpleasant and unnecessary actions.
Discussion results in the mailing lists have been ignored, and nobody cares about what the users think... Silly...
Actually
I thought most administrators would actually be more worried about data integrity - that is, if a disk (or essential system file) was found to be corrupted they wouldn't even really bother trying to fix it but rebuild from backups? Who knows what else could be corrupted?
I bet you have never used NetBSD
What are cons of this change, can you explain?
Then set M
Then set MKDYNAMICROOT=n in mk.conf(5). What's wrong with one more selectable option?
Blargh
dll-enabled root w00h00! sounds just like windos, 'course it won't boot to a BSOD when the shit comes loose, but rather, a black panic.
sounds good, keep up the... work.
i'll be on the other side of the fence
-z
Oh...kay
I'd rather just not have loose shit flying around my system to start with, dlls or no dlls.
Are the netbsd people in a reverse universe ?
Where disk space is reducing rather than increasing ?
I've got 80 000 MB on my Linux box (actually 160 000 MB in a RAID 1 config), who cares about saving 9 MB here or there. I'm all for being efficient, I just don't see the point of doing this. There might be some value if they squeezed the root file system down to less than 1.44 MB (obviously to fit on a floppy), but until then, why bother ? Futher, its not a no-cost change, with non-obvious benefits, the dynamic linking actually slows things down !
netbsd must be perfect these days, this sounds like work for works sake, rather than achieving anything useful. Sort of like a mouse running around in a wheel.
This change would make a lot of sense on an embedded system - but where is that clarification ? I would guess the majority of netbsd users are not embedded users, so this change should probably default to off, and be available for embedded people to switch on. You optimise for the common case, not the other way around.
Contrast this change to netbsd with the article refered to on slashdot at extreme tech about how "good" the *BSDs are vs Linux. (I'm not strongly anti-BSD, I quite like OpenBSD, its just a joke to see something as frivilously useless as this on the same day as I read an article on how wonderful *BSDs are compared to Linux).
Yet another bullshit
Slow things down? Are you still using a real i386? How can you feel the difference of 0.1s loading time between dynamic binaries vs. static?
Sounds funny
It slows things down? Are you still using a real i386?
Funny
...how the people are ranting about that feature. It's not like it's forced onto you. Read the last line of the article damnit.
Can't see the wood for the trees
To summarise my comment (people haven't read that properly either)
a) this change only provides the benefit of reducing disk space - but the disk space it saves is irrelevant these days
b) the cost of this change is performance - I agree most people wouldn't notice the performance drop, however, I would always think that a saving 10s of megs of disk space is not worth a performance drop of any level
c) by default it is on (yes it can be switched off, but that is not the point) - they are not optimising for the common case.
d) The change they have made would be relivant if they defaulted it to off, and let people with embedded targets switch it on.
So, on a super duper 2.4 Ghz Pentium IV, with a brand new 320GB Maxtor hardrive, netbsd :
* saves 10MB of disk space - what, you mean I actually have 319 990 MB left for my MP3s, rather than 319 980 MB - WOW! What an improvement ! I'll be able to store so many more MP3s (hmm, urm, about two actually)
* is slower
and this is by default !
note that dynamicly linked binaries are likely to actually be faster than staticly linked binaries - if the dynamic library is in the file system cache, you don't read it from disk everytime a binary is loaded. But, by the fact that it is being mentioned, maybe there is a much bigger problem in netbsd's file system / dynamic library caching.
Re: Can't see the wood for the trees
a) this change only provides the benefit of reducing disk space - but the disk space it saves is irrelevant these days
Huh? You really don't see the wood for the trees! Dynamically linked binaries can make use of dl*(), which has never been possible with static binaries!
b) the cost of this change is performance - I agree most people wouldn't notice the performance drop, however, I would always think that a saving 10s of megs of disk space is not worth a performance drop of any level
Performance drop is no longer important with Gig-hertz processors available nowadays. Are you using an Apple II?
You never use NetBSD - What you're saying is basically FUD.
what's the most comonly used binary?
well, /bin/ls ?
if /bin/ls now runs slower on my imaginative "2GHz Athlon/4GB/6x75GB" meanmachine(TM), i wouldn't lose anything anyway because it's a 2GHz cpu?
but if it had 10000 users logged in?
uhhuhuh uh huh. NO it's not a 386/16MHz, because i need a FASTER machine, get it?
I just don't like it. btw, is ld.so in / ? no? someone please explain the benefit of this...
-z