* Raul Miller said: > > you waste RAM instead of hd space. (Dynamic libs are loaded once, > > static libs are loaded for each binary.) It's a tradeoff, just like > > everything else in a distribution. > > I'm confused by this line of argument, but I'll try to break it down: > > (a) consider the possibility that the static versions will be > maintained by different maintainers than the dynamic versions (presumably > not updated as often either). [Perhaps I should do it, since I'm > so interested in the subject.] No need to do that, imho. It's just a matter of modifying the relevant packages that would produce a separate binary deb with -static appended and would contain all the needed binaries in a BINARYNAME.static form placed in the same dir as the dynamic ones. Once again, I'll gladly work on the patches and communicate with maintainers of the packages. > (b) the directory where something is stored has nothing to do with how > much ram the executable consumes. [Anyways, ram consumption has little > to do with point 2.] Exactly. [snip] > if we have both dynamic and static versions of these programs there's > the added complexity of deciding to switch which program you're using > under non-emergency circumstances -- which is a plausible argument in > favor of not having two distinct instances/versions of the same program.] Especially that you WON'T use the static versions under normal circumstances. > > Against the pros of dynamic linking, you have a single con: a damaged > > library can prevent programs from loading. But as I said earlier: > > what are the odds that a massive failure will affect only libraries? > > (1) This con is in a different class from the pros. More generally, > premature optimization is bad. > > (2) there are other potential failure modes besides massive disk failure > where these precautions would be vaild. Most of them being hardware-related, but also there are some human and software factor related. > > If even one of your static binaries is destroyed, you're in the same > > place that you were with a broken library. > > Again, not really. > > More likely you're forced to operate under degraded (inconvenient) > circumstances. But you've got more chances at working around the > problem if you have some working executables. Very true. You have just ONE binary missing not ALL of them. > > (E.g., a disk problem or a bad case of the dumbs wiped out /dev and > > /lib. You've got static bins, but mknod also got wiped out. Bummer.) > > Well, if sash is working you could use its built-in -mknod. And a bunch of other useful commands :)))) > > What do I think a machine needs to be reliable? Here's a couple for > > starters: 1) A backup root disk. It's easy, it's cheap in today's > > market, and it buys me protection from both hardware and human error. > > (Even static binaries quail in the face of rm.) 2) A serial console. > > If some disaster is pulling the rug out from under my server, I don't > > want to rely on its network interface. There's too much that can go > > wrong, and I can't boot over it. 3) A failover machine. Sometimes > > things really do break. > > In many circumstances these are good practices. And in many circumstances at least 2) is out of question and 1) is troublesome and still requires physical presence at the server. > However, this is far from complete. You wouldn't expect that a backup > root disk would replace a regular backups -- why expect it to replace > static binaries? Say, how many of us have zero-state snapshost of their systems?? :)) > > That's exactly right. That's why you don't screw around with a > > production system unless you have a way out. And that's why you don't > > run a production system unless you have a way to compensate for > > catastrophic failure. And that has nothing to do with static binaries. > > I disagree -- static binaries are just one of many ways to compensate > for catastrophic failure. Exactly. Just another possibility to find your way out - more ways out, less possibility you're hosed in case of trouble. > I agree that there are many classes of catastrophic failures which > static binaries can do nothing for. However, I've run into several > real life cases where static binaries have helped (or: would have > helped). Halleluiah! :))) These situations DO happen and they WILL be happening. marek
Attachment:
pgp7KXkJdFSiF.pgp
Description: PGP signature