Hacker News Reader

Comment by peterwwillis | Hacker News Reader

Oh man... if only we had all statically-compiled Linux systems these days. Sure it'd be a pain to deploy changes in libraries, but less dependency-breaking consequences means you can push a patch to a single application without testing a whole suite of dependent apps.

The really hacky solution to that seems to be building versioned packages in versioned directory paths (e.g. "/opt/lib/db/4/4.2/4.2.52/libdb.so") and mess with linker paths and create a sprawling tree of symlinks and wrappers for weird use cases. With a custom package manager it works really well: run 6 conflicting versions of the same library and just build apps against the library you know works, instead of fighting to get everything running on one compatible library.

View on HN

And the exactly corresponding security problem: when a problem is found in a library, you'll have to update all your applications, not just the library, otherwise you'll have an insecure system.

> Oh man... if only we had all statically-compiled Linux systems these days.

Would you mind buying me a memory upgrade when this happens? I'll need one.

I honestly have no clue how much extra memory this would cost. I can see it being a big issue on embedded systems. But, with 512 megs being considered very low on modern desktop/server systems, I always thought the vast majority of recent memory use was data rather than code.

Roughly how many processes are you running? Can anyone give a wild-assed guess how much memory it take to boot and load gmail in FireFox on a statically linked Linux?

You shouldn't see that much difference, at least on a system designed for static linking (modern GNU/Linux is explicitly not such a system, see http://www.akkadia.org/drepper/no_static_linking.html). There's still quite a bit of potential for interprocess resource-sharing.

If you somehow managed to get a statically linked Firefox (I think it would be very difficult, given the degree to which Drepper has abandoned the idea) on a modern Linux system, though, the resource usage would admittedly probably be quite impressive.

You'd need a bigger hard drive rather than more memory: dynamically shared libraries are paged-in to be used just as statically linked libraries are and are also paged-out when not in use, in just the same way.

Thus, to run a dynamically linked program you need to use the same amount of memory as you would a statically linked program.

However, if you are lucky (or have enough RAM), there is a chance that you won't have to load the page containing the library as it may already be in memory.

So there is a valid argument that to take full advantage of dynamically linked libraries you need more memory than for statically linked libraries.

While not exactly what you are proposing, NixOS does something similar. It's not perfect, but it's far from hacky.

http://nixos.org/

Reply on news.ycombinator.com