Skip to main content
18 events
when toggle format what by license comment
Mar 29, 2021 at 21:55 answer added John Doty timeline score: 2
Mar 28, 2021 at 12:51 comment added Incnis Mrsi @FrancisDavey: mapping the program’s binary to one chunk of RAM for multiple running processes is a related, but distinct problem. An OS may intelligently map files but lack a dynamic linker. On the other hand, dynamic linker doesn’t per se save RAM in a way discussed here; it can be achieved only in conjunction to sane semantics of memory management which relies on the OS kernel.
Mar 28, 2021 at 12:43 comment added Francis Davey At least by the 1980's, IBM's MVS had a "link pack area" which allowed shared libraries in memory as far as I recall. One fo the editors on our mainframe lived in it so even with many people using it, there was only one copy in RAM.
Mar 28, 2021 at 6:50 comment added TripeHound @another-dave ...you get a kitchen sink whose make and model you're not quite certain of. And you're not sure if the small leak in the mixer-tap that you have to compensate for is still present, or indeed that the mixer-tap hasn't been replaced with separate hot and cold taps!
Mar 28, 2021 at 1:58 comment added dave I don't have the stats as to what is 'usual', but on the code I work on, it's basically one process per container. Sure, the libraries are still shared objects, but that's just because that's what is available. I cast an envious eye at my Go brethren. It seems to me that how shared libraries work is, you call one routine, you get the kitchen sink in your address space. Maybe in a different forum we could discuss declining standards of modularity :-)
Mar 28, 2021 at 1:53 comment added Austin Hemmelgarn @another-dave Containerization is reducing the attractiveness of the classical system-wide shared library approach, not shared libraries in general. Most containers that do not involve fully statically linked platforms (like Go) are still built using shared libraries because it’s unusual to have only one process running, and therefore is still beneficial to use shared libraries to reduce your runtime memory footprint.
Mar 28, 2021 at 1:48 answer added Leo B. timeline score: 6
Mar 27, 2021 at 23:36 history became hot network question
Mar 27, 2021 at 20:57 answer added supercat timeline score: 1
Mar 27, 2021 at 20:02 comment added tofro Microsoft was pretty much memory-constrained with Windows 1.x targetting machines << 1MB of RAM - They were practically forced to do something to save on scarce memory. That pressure was probably not so high for UNIX-y OSs that could expect a bit more elbow room (due to their target selling price and higher-end machines to run on).
Mar 27, 2021 at 19:54 comment added dave Containerization is, I think, also reducing the attractiveness of shared libraries.
Mar 27, 2021 at 18:37 comment added Kelvin Sherlock Not entirely retro-computing. Dynamic vs static linking is an active debate today. Rust and Go prefer static linking.
Mar 27, 2021 at 16:54 comment added dave I think your viewpoint on what was common when depends very much on the systems you were using. Thompson was long unconvinced of the merits of shareable library images. On the other hand, VMS embraced the idea (though V1.0 only permitted one per process, but that was just a temporary limitation). TOPS-10 had "shareable high segments" forever, as far as I know.
Mar 27, 2021 at 16:41 answer added Raffzahn timeline score: 4
Mar 27, 2021 at 16:31 answer added Brian H timeline score: 19
Mar 27, 2021 at 15:58 comment added davidbak Especially since the concept was used in Multics at the dawn of the multitasking/virtual memory age ...
Mar 27, 2021 at 15:35 review First posts
Mar 27, 2021 at 15:51
Mar 27, 2021 at 15:29 history asked Incnis Mrsi CC BY-SA 4.0