Timeline for Belated ascendancy of dynamic linkers
Current License: CC BY-SA 4.0
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 |