Why has Plan 9 chosen statically linked binaries instead of dynamic ones? (2004)

Re:Why has Plan 9 chosen statically linked binaries instead ... by simias on Friday February 15, 2019 @08:32AM (#19170735)

If I'm not mistaken shared libraries are also shared (for the ro sections) in RAM. Saving 10MB on disk is mostly negligible nowadays but 10MB in RAM less so, and 10MB in cache is very much significant.

I really think that the linked post throws the baby out with the bath water, library versioning issues can be handled by the package manager to become effectively non-issue. DLL hell is a thing on Windows because it lacks a proper package manager. On a case-by-case basis applications that can't be packaged properly (proprietary binaries for instance) can be statically linked.

In my experience that's how it works on Linux and for the BSDs and as far as I'm concerned it hasn't caused many issues. Maybe I've just been lucky.

[ Parent | on HN ]

Re:Why has Plan 9 chosen statically linked binaries instead ... by robotresearcher on Friday February 15, 2019 @02:37PM (#19174016)

Shared libraries are shared in RAM between processes. But I believe the cache for each process is not shared. If three processes currently have the same shared lib code (or any shared memory) in their working set, they will each work it into cache independently. This sounds inefficient but is rare in practice and maintains process isolation. The added complexity of cache sharing would not be worth it.

If I have this wrong, someone please correct me.

[ Parent | on HN ]

Re:Why has Plan 9 chosen statically linked binaries instead ... by wmf on Friday February 15, 2019 @04:58PM (#19175098)

That is wrong for caches that are based on physical addresses.

[ Parent | on HN ]