19 ms·

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

162 points by stargrave 8y ago

kstenerud 8y ago
This is far too narrow a view. It's not a question of whether to dynamically link or not, but WHERE and HOW to dynamically link. Think about it: If you were to force absolutely everything to be statically linked, your KDE app would have to include the ENTIRE KDE library suite, as well as the QT libraries it's based on, as well as the X window libraries those are based on, etc etc. You'd quickly end up with a calculator app that's hundreds of megabytes. But let's not stop there, because the linkage to the kernel is also dynamic, which is a no-no. So every app would now need to be linked to a specific kernel, and include all the kernel code. Now imagine you upgraded the kernel. You'd have to rebuild EVERY SINGLE THING on the system to build with that new kernel, or a new version of KDE or QT or X or anything in between. The kernel membrane is a form of dynamic linkage for a reason. Same goes for IPC. Dynamic linkage is useful and necessary; just not to such a microscopic level as it once was due to size constraints. The key is not to eliminate dynamic linkage, but rather to apply it with discretion, at carefully defined boundaries.
- dtech 8y ago
  Statically linking the OS is quite common nowadays [1], better known as containerization. For quite a while there has been a movement that every program or "executable" is statically linked. In your example, the "OS" is a program on it's own, it's controlled by a single vendor and released/updated at the same time. So dynamic linking it fine there For a downloadable program statically linking Qt would seem prudent however, otherwise an incompatible version on the OS would render the program unusable. You see this design decision nearly everywhere where legacy is not too big a concern: Go and Rust statically link its runtime and dedendencies in executables, JVM consumer apps are usually bundled with a specific JVM, containerization etc. [1] edit: masklinn correctly pointed out that usually the kernel is still shared between containers and the host OS
  - masklinn 8y ago
    > Statically linking the kernel and OS is quite common nowadays, better known as containerization. For quite a while there has been a movement that every program or "executable" is statically linked. Containers specifically do not statically link the kernel, the entire point is to have multiple isolated userlands use the same underlying kernel. That's why they're so cheap.
    - mapcars 8y ago
      >the entire point is to have multiple isolated userlands use the same underlying kernel. That's why they're so cheap. Ironically, this is what Plan9 does out-of-the-box. And even cheaper.
      - soraminazuki 8y ago
        Do you have any evidence to support your claim? My understanding is that containerized processes are theoretically the same as any other process on the system in terms of runtime performance.
        mapcars 8y ago
        In plan9 they are exactly the same, not theoretically. Isolation happens on a file system level (everything is a file, but truly, not a "special device file"). While it's practically not possible to compare performance, just the fact that this is a part of the initial design and a core of Plan9 vs adhoc feature (actually ported from Plan to Linux) is enough to speculate on performance. >Linux namespaces were inspired by the more general namespace functionality used heavily throughout Plan 9 from Bell Labs. https://en.wikipedia.org/wiki/Cgroups https://en.wikipedia.org/wiki/Cgroups
        masklinn 8y ago
        > While it's practically not possible to compare performance, just the fact that this is a part of the initial design and a core of Plan9 vs adhoc feature (actually ported from Plan to Linux) is enough to speculate on performance. It really doesn't. For all we know, because the plan9 version has to be more general it is much slower than the ad-hoc version.
- masklinn 8y ago
  > But let's not stop there, because the linkage to the kernel is also dynamic, which is a no-no. So every app would now need to be linked to a specific kernel, and include all the kernel code. > Now imagine you upgraded the kernel. You'd have to rebuild EVERY SINGLE THING on the system to build with that new kernel, or a new version of KDE or QT or X or anything in between. You could though, that's pretty much what unikernel systems do. You'll still likely have dynamic linkage of sort to the hypervisor or (ultimately) the hardware.
- kryptiskt 8y ago
  > Think about it: If you were to force absolutely everything to be statically linked, your KDE app would have to include the ENTIRE KDE library suite, as well as the QT libraries it's based on, as well as the X window libraries those are based on, etc etc. You'd quickly end up with a calculator app that's hundreds of megabytes. That is false. Static linking only links in the the parts that are actually used, which would be a small fraction of the total.
  - Vogtinator 8y ago
    Almost all parts end up being used though - for the vast majority it's not possible to prove that it's never used. KCalc would for instance pull in HTML rendering for the Help dialog, which would also add all available picture format plugins and also PDF writing support etc.
    - asark 8y ago
      Reads like a case for passing that off to whichever program responds to a request to open some help HTML.
      - jblwps 8y ago
        And as you begin to flesh out some kind of calling convention, you pretty quickly end up with what could very easily be called dynamic linkage of sorts, even if it's not strictly the linking of object files, etc.
        asark 8y ago
        Yeah, I figured that'd be a response, but if you're gonna call mime type handlers dynamic linking we may as well give up on using the term at all. I just don't think "I need to let the user open an HTML document, though not as any core part of my program's functionality" is a strong case for "well I guess I'll have to embed an entire HTML rendering engine if I statically link my deps".
- jacquesm 8y ago
  You are conflating a lot of terms that have nothing to do with each other. Static linking would never cross process boundaries, would optimize for modules that are actually called from the program that the libraries are being linked to and has absolutely nothing to do with IPC. Dynamic linking is useful, but not always necessary and not always appropriate and does not result in 'calculator apps that are hundreds of megabytes', it might be 10Mb or so, which is still large but not comparable.
  - pexaizix 8y ago
    KCalc with the KDE libs, Qt, X, libc, and all of their dependencies would become far bigger than 10 MB.
    - roblabla 8y ago
      Kcalc doesn’t use the whole qt library, the whole X library, the whole kDE library, or the whole C library. When you statically link, only the functions that are actually called are included. This can trim a lot of space.
      - tom_mellior 8y ago
        > When you statically link, only the functions that are actually called are included. This is not true in general. For this code: #include <stdio.h> int main(void) { puts("hello world\n"); return 0; } both GCC 7.3.0 and Clang 6.0.0[1] on my system generate an 828 KB binary when compiling with -static. The binary includes a whole bunch of stuff, including all the printf variants, many of the standard string functions, wide string functions, lots of vectorized memcpy variants, and a bunch of dlsym-related functions. By using -ffunction-sections -fdata-sections -Wl,--gc-sections (per https://news.ycombinator.com/item?id=19170667 https://news.ycombinator.com/item?id=19170667) I get this down to 804 KB. Still not quite what you suggest. [1] Clang might just be using the same linker as GCC here, and you might blame including the extra stuff on the linker.
        8y ago
- jstimpfle 8y ago
  > your KDE app would have to include the ENTIRE KDE library suite, as well as the QT libraries it's based on, as well as the X window libraries those are based on, etc etc. You'd quickly end up with a calculator app that's hundreds of megabytes. If you look at the transitive dependencies and then only link in the code that is actually reachable, I doubt that static linking has a significant impact. (I don't know to which degree this is possible with today's toolchains, but I suspect that many libraries have some inefficiencies there due to missing dependency information). As an uneducated estimate (from someone who has written compilers and GUIs entirely from scratch) I'd say 100K of additional statically linked object should be enough for almost any desktop application. > the linkage to the kernel is also dynamic Not an expert here, but you don't link to the kernel at all. The interface is via syscalls. At least on Linux, to help decrease inefficiencies at the syscall boundary, there is some magic involving the so-called VDSO, though - which is indeed dynamically linked, but shouldn't be very large either (On my system it seems the [vdso] and [vsyscall] mappings (both executable) both have size 8K. There is also a non-writeable and non-executable [vvar] of size 8K and I guess it links to live variables written by the kernel).
  - alexlarsson 8y ago
    > As an uneducated estimate (from someone who has written compilers and GUIs entirely from scratch) I'd say 100K of additional statically linked object should be enough for almost any desktop application. This is completely misguided. For a modern UI library it is very very hard to figure out what code is actually used. Say we load the ui description from an xml file. What controls get used in the app then? Maybe the xml has a webview control in it? Then we can't drop the webview dependency. Then your app needs to load an icon, which typically goes via some generic image loading API. What types of loaders are there? Can we get rid of the gif loader (and dependencies)? If any single image file reference is not hardcoded in the binary, again we can't. Want to script your application in lua/python/js, and let it call into the UI library? Then we have to assume that basically any code can be reached. Static linking like this just is not realistic.
    - jstimpfle 8y ago
      Yes I agree. I does not work with deep nested dependency chains where some choices are only decided at runtime (after loading additional text files). Maybe it's possible, though, if we remove a little flexibility and flatten the dependencies, such that the application hardcodes a little more of what actually happens (e.g. specificies the file formats for image loading, the format of the ui description, etc). This is the way I've done my own GUI application, where I simply coded what should happen, and created widgets as I needed them, and all the important decisions were known statically. But maybe this amount of specification is not what people expect from a standalone GUI library.
- crankylinuxuser 8y ago
  As a converse, its very "nice" to have programs in /sbin and some in /bin to be statically linked. And when I say nice, I mean absolutely essential. Ive had glibc go south before... And then nothing works. Its a "hope you can boot with rescue media and hope and pray the old glibc is in your apt/rpm cache". But having the rest of the system being dynamic linked makes a great deal of sense for the reasons you stated.
- jcelerier 8y ago
  > Think about it: If you were to force absolutely everything to be statically linked, your KDE app would have to include the ENTIRE KDE library suite, as well as the QT libraries it's based on, as well as the X window libraries those are based on, etc etc. no, because we had working LTO for a long time - every KDE app would contain only the exact code that it needs, down to the individual member function. Sure, all KDE apps would have a copy of QObject / QString / QWhatever - but most C++ code nowadays is in headers anyways . > You'd quickly end up with a calculator app that's hundreds of megabytes. The DAW I'm working on (340kloc), which can be built statically linked to Qt, LLVM, libclang, ffmpeg and a few others, is a grand total of 130 megabytes in that case. It's actually heavier when distributed as set of dynamically linked things (unless shipped by linux distros of course, and most of that size is useless LLVM things that I haven't found how to disable yet) : only accounting for the dependencies I have to ship, it would be 176 megabytes - plus 17 megabytes of the actual software. I'd argue that in that case dynamic linking actually takes less disk space overall because most people don't have LLVM installed on their machines and don't need to.
  - christina_b 8y ago
    Regular LTO for large sized projects (think Chromium sized), in my experience is by far the biggest bottleneck in the build process. It's partially the reason so much is being invested into development and improving parallel linking as well as techniques like ThinLTO that all aim at reducing the link times since often, LTO linking takes around 60-70% of all build time combined despite the heavy use of C++ code (although with no exceptions or RTTI). Unless you have build servers capable of rebuilding all Qt, WebKit etc. and performing an LTO link (which pulls in all build artifacts in form of bitcode archives/objects) in a reasonable amount of time (big reason buildlabs exist - it takes a long time), LTO is not likely to be suitable, it's an extremely expensive optimization that essentially defers all real compilation until the link step at which the linker calls back into libLLVM/libLTO and have them do all the heavy lifting. At the very least you need a workstation grade machine to be able to do that kind of stuff on regular basis, you really can't expect everyone to have that. And there's a reason libLLVM.so is usually dynamically linked, it cuts a massive amount of time spent on builds, which is especially useful while developing and it's a middle ground between building all LLVM and Clang libraries as shared objects and having to wait for static linking of various LLVM modules into every LLVM toolchain binary (which tends to result in the toolchain being much much bigger). The build cache with shared libLLVM.so for Clang/LLVM/LLD builds is around 6-7GB (Asserts/Test builds). Statically linking LLVM modules blows that up to 20GB. God forbid you actually do a full debug build with full debug information with that. That's a terrible argument against dynamic linking. That's not to say static linking is bad, in fact, recently it's been making a comeback for exactly that reason - LTO and next-generation optimizers. But saying LTO makes static linking viable for everyone including consumers is somewhat far fetched.
- asdkhadsj 8y ago
  > The key is not to eliminate dynamic linkage, but rather to apply it with discretion, at carefully defined boundaries. Question: In the right system, does discretion even matter? Eg, NixOS - where linked libraries and dependencies are defined by content addressing. Should we use discretion with linked libs in a system like that?
  - ingenieroariel 8y ago
    When I started developing in golang I used to prefer static binaries without cgo 100% of the time. Now that I have moved to NixOS and each binary can either use the one in the system or provide their own libc if it is different I feel much better about it. I don't think we need to use discretion in a system like that.
- Sir_Cmpwn 8y ago
  Several comments have already pointed out many ways that this take is incorrect, but I'll also mention that software like KDE is the antithesis of plan9 design and I bet I'll be 6 feet under before we see it ported.
- rb808 8y ago
  > You'd have to rebuild EVERY SINGLE THING on the system to build with that new kernel like containers? surely this is the same thing as you suggest, and is a good solution.
Tepix 8y ago
The page is down for me but archive.org comes to the rescue: https://web.archive.org/web/20190215103117/https://9p.io/wiki/plan9/why_static/index.html https://web.archive.org/web/20190215103117/https://9p.io/wik... Or if you prefer google groups: https://groups.google.com/forum/#!topic/comp.os.plan9/x3s1Ibaj_l8%5B51-75%5D https://groups.google.com/forum/#!topic/comp.os.plan9/x3s1Ib... The headline could use a "(2004)" suffix.
deleted 8y ago
[deleted]
pjc50 8y ago
This isn't so much an answer for 9p as a description of why GCC symbol versioning is confusing. > The symbol versioning breaks assumptions users have about how shared libaries work -- that they provide a link to one version of a function and if you replace the library all the programs get fixed. I've seen this problem in practice, for both naive users and very non-naive sysadmins.
glangdale 8y ago
There was a strange and mutually self-supporting pair of ideas in the Plan 9 community at the time: 1) "Shared libraries are bogus." 2) "Anyone who likes normal-looking user interfaces rather than plain boxes with text in them is a poopipants." Both of these propositions are contentious to say the least, but what bothered me was that two propositions were mutually supporting while being (to my mind) orthogonal. The obvious and most compelling example of a shared library on the Unixen at the time were all the various UI libraries (Motif and various other abominations; all of them huge and unwieldy). It seemed necessary to accept that these libraries were obviously Completely Unnecessary to buy into the Plan 9 idea that shared libraries didn't do anything worth mentioning. I'm sure it's possible to design a better UI library (or maybe even a wacky user level file system for user interfaces; in fact, my honours project in 1993!) but at the time the way people made interfaces that looked vaguely like what other people expected computer programs to look like was to use big-ass shared libraries on Linux. This was also the way (dragging in one of those godawful blobs like Motif etc) that anyone might have exerted themselves to port across a (not completely pitiful) web browser, but the degree of aggressive disinterest in supporting Other Peoples Code was extreme (Howard Trickey's "ANSI POSIX Environment" or "APE" didn't get much love as far as I could tell). It was quite undignified to watch people struggling with text-based web browsers or firing them up on non-P9 boxes because of the inability to support the web at the time.
- sprash 8y ago
  > 1) "Shared libraries are bogus." Starwman, nobody said that. Shared libraries make sense when a program wants to load additional code at run time. A classical example is loading and unloading plugins. For everything else, not so much. 2) "Anyone who likes normal-looking user interfaces rather than plain boxes with text in them is a poopipants." Most people I know use a tiling window manager with terminals. So plain boxes with text in them seems to make sense for many people.
  - glangdale 8y ago
    It's hard to recall conversations from 1994, but I came away with the overwhelming sense that the Plan 9 guys thought shared libraries were bogus - certainly that they were bogus for the non-plugin use case (which is the one that pertains to this discussion; libraries like Motif were not plugins). So you've accused me of raising a strawman (actually a "starwman" - "he'd like to cwome and mweet us, but he thinks he'd blow our mwinds") by raising a point absolutely not germane to the discussion, but you when refute my point with this devastating rebuttal: "For everything else, not so much". Most people I know also use the web and menus and buttons and dialog boxes and so forth and expect all this stuff to look vaguely like other computers do. The fact that the Plan 9 folks were trundling over to non-P9 machines to read the web seemed to suggest that they also liked seeing things that weren't just text in plain boxes. The point remains that these two propositions are both at the least contentious, and only by combining these unrelated points could anyone really seriously take Plan 9's approach to shared libraries (at the time) seriously.
pfortuny 8y ago
This is the same people that “just say no” to syntax highlighting for instance.
- fao_ 8y ago
  For what it's worth, I said no to syntax highlighting three years ago and never looked back. Anecdotal, but I'm making much less errors and paying more attention to the code, now. I think a lot of code highlighting is basically ineffectual, though, given that it (almost always) highlights based on keyword-based regex, rather than the semantic meaning of the code.
  - stuross 8y ago
    take a look at https://github.com/tree-sitter/tree-sitter https://github.com/tree-sitter/tree-sitter
  - jakear 8y ago
    I use it as visual feedback from the parser. That is, if I’ve messed up a bracket placement while moving code around, all the code after that will be colored “oddly” and I can instantly tell both that I’ve made a mistake, and often where exactly that mistake is. I contest that they highlights based on keyword-based regex too. I haven’t formally analyzed TextMate grammars, but I believe the scoping behaviors take them into context free grammar territory.
  - zephyrfalcon 8y ago
    Granted there isn't much to be gained by making your code look like an angry fruit salad. But I do find it useful in some cases, e.g. to make comments stand out from the rest of the code. Also, unterminated block comments or strings will immediately show up as well. And if you are not very familiar with a language, it might help to highlight keywords, so you don't accidentally use them as variable names.
  - astine 8y ago
    "Anecdotal, but I'm making much less errors and paying more attention to the code, now." Could be correlation rather than causation. Presumably, you're a more experienced programmer now than you were three years ago and you might be making fewer errors and paying more attention regardless of whether you turned off syntax highlighting.
teddyh 8y ago
SunOS before 4.0, when it still used SunView¹ instead of X11, still did not have dynamic linking. Hence this email rant by John Rose titled Pros and Cons of Suns from 1987 (as included in the preface of The UNIX-HATERS Handbook²): […] What has happened? Two things, apparently. One is that when I created my custom patch to the window system, to send mouse clicks to Emacs, I created another massive 3/4 megabyte binary, which doesn’t share space with the standard Sun window applications (“tools”). This means that instead of one huge mass of shared object code running the window system, and taking up space on my paging disk, I had two such huge masses, identical except for a few pages of code. So I paid a megabyte of swap space for the privilege of using a mouse with my editor. (Emacs itself is a third large mass.) The Sun kernel was just plain running out of room. Every trivial hack you make to the window system replicates the entire window system. […] 1. https://en.wikipedia.org/wiki/SunView https://en.wikipedia.org/wiki/SunView 2. https://web.mit.edu/~simsong/www/ugh.pdf https://web.mit.edu/~simsong/www/ugh.pdf
- exitcode00 8y ago
  Oh my, each app is going to be 20 mb bigger! This mattered 30 years ago, but now I would say we have a huge problem for end users with all of these "Package managers" and "dependency managers" getting tangled up because there are 5 versions of Perl needing 3 versions of Python and so on... I would be a much more happy Linux user if was able to drag and drop an exe. 100mb be damned
  - bepvte 8y ago
    Thats what appimage is for, but if every single thing in /bin/ was 100mb you would have an OS much larger then windows
    - exitcode00 8y ago
      Doubt that, looking at my list of applications - I have 124. So, 100mb * 124 = 12.4 gb and I have half a terabyte of storage... Windows 10 requires 16 gb of storage. Heck most phones have 64 gb these days. We need to stop living in the past - this very issue has probably contributed to the scourge of Electron crap being thrown at our faces since it doesn't suffer from dependency hell they just throw a bunch of javascript into an encapsulated instance of chrome and call it a day.
snarfy 8y ago
In Linux, if libssl is compromised, you install a new libssl. In Plan 9, if libssl is compromised, you re-install Plan 9. That's static linking for you.
- IshKebab 8y ago
  Yeah that works if your app is in the Debian's software repository (and Ubuntu's and Red Hat's and Gentoo's and etc. etc.). If that is the case it is trivial to update all apps that depend on libssl anyway, even if they use static linking. In practice it is far easier for a lot of software to distribute Windows-like binaries where all but the most basic dependencies are included (e.g. Flatpak or Snappy). In that case dynamic linking doesn't help at all.
  - fao_ 8y ago
    Exactly. Modern Ubuntu systems rely on Snap or Flatpak for a lot of software. What these systems do (as I understand it) is package a large amount of the dynamic libraries that would be provided by the operating system, and stick them in a compressed file (or virtual file system, whatever). So what you essentially get is a 200MiB 'binary' without any of the benefits of dynamic linking (being able to swap out a library given a vulnerability without recompiling) OR static linking (a single file, with the extraneous code removed, etc. etc.).
    - vetinari 8y ago
      With flatpak, you can update the runtime (a bundle of libraries) independently of the app, so you can swap out a library with a vulnerability without recompiling.
      - IshKebab 8y ago
        That's not why runtimes exist though - it's too save disk space.
  - vetinari 8y ago
    Flatpak has a concept of runtimes, shared among multiple applications, which are basically a well-defined bundles of libraries. So yes, dynamic linking helps there.
nrclark 8y ago
Shared libraries are a pain for sure. They also have a lot of really nice advantages, including: - You can upgrade core functionality in one location - You can fix security bugs without needing to re-install the world - Overall, they take up less disk-space and RAM - They can take much less cache, which is significant today The cache aspect is one that I'm surprised not to see people talk about more. Why would I want to blow out my CPU cache loading 20 instances of libSSL? That slows down performance of the entire system.
- taeric 8y ago
  I think the dream is you could have one SSL process that others communicated with. Message passing at large.
  - otterley 8y ago
    It's not without cost, though. Moving messages around causes CPU data cache pressure and CPU cycles you wouldn't otherwise have spent if you merely referenced shared memory that's mapped into your process.
    - taeric 8y ago
      Right. I didn't mean that to be why it is correct. Just giving some comment to what was actually suggested. Static linking is not the only alternative to dynamic linking.
  - joejev 8y ago
    So, like some sort of shared library that my programs dynamically communicate with? How is this functionally different from a shared object?
    - AnIdiotOnTheNet 8y ago
      It isn't really. The actual big problem with shared libraries is that developers cannot be trusted not to change their interfaces or behavior and break things. That's true regardless of what mechanism you use to share code.
wallstprog 8y ago
Obligatory link to Drepper's classics: https://akkadia.org/drepper/no_static_linking.html https://akkadia.org/drepper/no_static_linking.html https://www.akkadia.org/drepper/dsohowto.pdf https://www.akkadia.org/drepper/dsohowto.pdf Seems like the Plan 9 guys haven't heard of these? If done properly, dynamic linking is almost always better than static -- key word here is "properly", which doesn't always/often happen.
- linksnapzz 8y ago
  Yeah, no true scotsman links his executables dynamically. Also, this is the definitive classic take on Dr. Epper. http://linuxhaters.blogspot.de/2009/05/tribute.html http://linuxhaters.blogspot.de/2009/05/tribute.html
  - rleigh 8y ago
    This doesn't appear to be accessible without a Google account.
hollerith 8y ago
Most here seem to know that the motivation for adding DLLs to unix was to make it possible for the X windowing system to fit in the memory of a computer of that time, but many comment writers here seem not to know something that the participants in the discussion that is the OP all knew: Plan 9 has an alternative method for sharing code among processes, namely the 9P protocol, and consequently never needed -- and never used -- DLLs. So for example instead of dynamically linking to Xlib, on Plan 9 a program that wanted to display a GUI used 9P to talk to the display server, which is loosely analogous to a Unix process listening on a socket.
- AnIdiotOnTheNet 8y ago
  Problem with that is that it is less efficient than a shared library but also susceptible to the same issue, namely that if you change the interface then things break. Edit: It does of course get you extra functionality, like being usable over a network connection. Trade offs.
  - erikpukinskis 8y ago
    How is it less efficient?
    - AnIdiotOnTheNet 8y ago
      It involves syscalls and data copying. How could it not be less efficient?
      - moosingin3space 8y ago
        There are examples of very efficient IPC, just not in UNIX-land. If your IPC system is integrated with the scheduler, the difference between a dynamic library call and IPC can be minimized into irrelevance.
      - erikpukinskis 8y ago
        I was not certain that data serialization and copying is required. Is that always true? You can’t do IPC with some shared memory setup?
bakul 8y ago
The idea was that individual programs would be small and loosely coupled. That is, rather than drag in a giant library, abstract out its code in a separate server and talk to it via some protocol. This worked remarkably well on the whole. So the idea of not wanting to have 100 statically linked programs all weighing in at many megabytes kind of misses the point.
kilon 8y ago
I guess I am heretic for breaking my project to a collection of DLLs. Ironically I am doing it over a 2 mil lines of code statically linked code base. The statically linked code base takes 150 seconds to build and my much smaller project only 4 seconds. I have also designed it that way to do live coding in C and I have made a similar library for live coding python . I am addicted to DLLs , send help :D !
pjmlp 8y ago
The Plan 9 fans keep forgetting that the end of the road was Inferno not Plan 9, developed by the same devs, with all Limbo packages being dynamically loaded.
protomyth 8y ago
So, if you don't have dynamically linked libraries and you need a security patch in one of the libraries, how exactly is the system admin going to patch the system. I assume I would need to find every program that contains that library and recompile them?
- geggam 8y ago
  just like a container
  - protomyth 8y ago
    The whole point of containers is that they are all-in-one and prepared each time from some build mechanism. Tracking down every binary on an OS is a whole different thing, thus the creation of containers in the first place.
- ben509 8y ago
  If I'm an admin, I'm running my own package repo, and I'll rebuild everything that depends on it there.
deleted 8y ago
[deleted]
gcb0 8y ago
site is down now... but I hope it will be honest and just explain that "they did it just so they could do that one demo of tar'ing one process from one machine, 9p'ing it to another box, untar it and the process graphical UI would resume on the new host as if nothing had happened"
equalunique 8y ago
I would like to try Plan9. Is it feasible to get 9front running on a ThinkPad X220?
- Sir_Cmpwn 8y ago
  Yes. It should run perfectly, including WiFi et al.
joshe 8y ago
The new model of One Version, all updated together is interesting in this context. Examples are iOS, Chrome, Firefox and node_modules. All super complicated with many dependancies. Update everything, fix broken stuff. Only maintain the one blessed dependency graph. If you report an iOS or Chrome bug where you tried to revert a library upgrade and something broke, they'll just mark it "Won't fix: omg never ever look at this". The dependency graph when everyone isn't updating all at once is brutal. Half of Unix life is/was "well I need to update X, but can't because Y depends on old X. Now we'll just create this special environment/virtualenv/visor/vm with exactly the brittle dependency graph we need and then update it, um, never." We complain about One Version/Evergreen, and should, but it's got huge advantages. And might be an indicator that testing surface is the real complexity constraint. One Version's success a good indication that Plan 9 was at least not totally wrong.
- B-Con 8y ago
  Arch Linux's approach is similar. The only version of the OS that is blessed is the current version. Every package install should come with a full system update. Package downgrades aren't supported. In the case of an irreconcilable "X requires Z v1 but Y requires Z v2" they fork package Z.
newnewpdro 8y ago
What a load of FUD about updating dynamic libraries not actually fixing the code without rebuilding the dependent executables. Symbol versioning does not break things in this way. If you've replaced your only libc.so with a fixed one, there is no other libc.so for dynamically linked executables to link with at runtime. If the new one brought a needed fix, the bug is fixed everywhere using libc.so. It's not like the new library bundles old bits to fulfill old versions of symbols, that's madness. The only way I can see someone getting into a situation implied by the article is when they install multiple versions of a shared library simultaneously, keeping vulnerable versions around, and have executables continuing to use the old copies. This is an administrative failure, and says nothing of dynamic linking's value.
dtzWill 8y ago
This is actually an area of very current research. We have implemented a form of software multiplexing that achieves the code size benefits of dynamically linked libraries, without the associated complications (missing dependencies, slow startup times, security vulnerabilities, etc.) My approach works even where build systems support only dynamic and not static linking. Our tool, allmux, merges independent programs into a single executable and links an IR-level implementation of application code with its libraries, before native code generation. I would love to go into more detail and answer questions, but at the moment I'm entirely consumed with completing my prelim examination. Instead, please see our 2018 publication "Software Multiplexing: Share Your Libraries and Statically Link Them Too" [1]. 1: https://wdtz.org/files/oopsla18-allmux-dietz.pdf https://wdtz.org/files/oopsla18-allmux-dietz.pdf
- acqq 8y ago
  How does your tool handle the dynamic libraries loaded on demand during the life of the program? Specifically, where the application depending of the user input dynamically loads only one out of the set of shared libraries which all are made to be linked with the main application and use the same interface but are designed to be "the only one" loaded? That is, both the application and each in the set of the libraries expect to have only 1-1 relation (only one library loaded at the time)? Edit: OK, reading further your article, I've found: "our approach disables explicit symbol lookup and other forms of process introspection such as the use of dlsym, dlopen, and others." If you'd manage to implement that too then it seems that really big projects could be packed together.

162 points by stargrave 8y ago

This is far too narrow a view. It's not a question of whether to dynamically link or not, but WHERE and HOW to dynamically link. Think about it: If you were to force absolutely everything to be statically linked, your KDE app would have to include the ENTIRE KDE library suite, as well as the QT libraries it's based on, as well as the X window libraries those are based on, etc etc. You'd quickly end up with a calculator app that's hundreds of megabytes. But let's not stop there, because the linkage to the kernel is also dynamic, which is a no-no. So every app would now need to be linked to a specific kernel, and include all the kernel code. Now imagine you upgraded the kernel. You'd have to rebuild EVERY SINGLE THING on the system to build with that new kernel, or a new version of KDE or QT or X or anything in between. The kernel membrane is a form of dynamic linkage for a reason. Same goes for IPC. Dynamic linkage is useful and necessary; just not to such a microscopic level as it once was due to size constraints. The key is not to eliminate dynamic linkage, but rather to apply it with discretion, at carefully defined boundaries.

dtech 8y ago
Statically linking the OS is quite common nowadays [1], better known as containerization. For quite a while there has been a movement that every program or "executable" is statically linked. In your example, the "OS" is a program on it's own, it's controlled by a single vendor and released/updated at the same time. So dynamic linking it fine there For a downloadable program statically linking Qt would seem prudent however, otherwise an incompatible version on the OS would render the program unusable. You see this design decision nearly everywhere where legacy is not too big a concern: Go and Rust statically link its runtime and dedendencies in executables, JVM consumer apps are usually bundled with a specific JVM, containerization etc. [1] edit: masklinn correctly pointed out that usually the kernel is still shared between containers and the host OS
- masklinn 8y ago
  > Statically linking the kernel and OS is quite common nowadays, better known as containerization. For quite a while there has been a movement that every program or "executable" is statically linked. Containers specifically do not statically link the kernel, the entire point is to have multiple isolated userlands use the same underlying kernel. That's why they're so cheap.
  - mapcars 8y ago
    >the entire point is to have multiple isolated userlands use the same underlying kernel. That's why they're so cheap. Ironically, this is what Plan9 does out-of-the-box. And even cheaper.
    - soraminazuki 8y ago
      Do you have any evidence to support your claim? My understanding is that containerized processes are theoretically the same as any other process on the system in terms of runtime performance.
      - mapcars 8y ago
        In plan9 they are exactly the same, not theoretically. Isolation happens on a file system level (everything is a file, but truly, not a "special device file"). While it's practically not possible to compare performance, just the fact that this is a part of the initial design and a core of Plan9 vs adhoc feature (actually ported from Plan to Linux) is enough to speculate on performance. >Linux namespaces were inspired by the more general namespace functionality used heavily throughout Plan 9 from Bell Labs. https://en.wikipedia.org/wiki/Cgroups https://en.wikipedia.org/wiki/Cgroups
        masklinn 8y ago
        > While it's practically not possible to compare performance, just the fact that this is a part of the initial design and a core of Plan9 vs adhoc feature (actually ported from Plan to Linux) is enough to speculate on performance. It really doesn't. For all we know, because the plan9 version has to be more general it is much slower than the ad-hoc version.
masklinn 8y ago
> But let's not stop there, because the linkage to the kernel is also dynamic, which is a no-no. So every app would now need to be linked to a specific kernel, and include all the kernel code. > Now imagine you upgraded the kernel. You'd have to rebuild EVERY SINGLE THING on the system to build with that new kernel, or a new version of KDE or QT or X or anything in between. You could though, that's pretty much what unikernel systems do. You'll still likely have dynamic linkage of sort to the hypervisor or (ultimately) the hardware.
kryptiskt 8y ago
> Think about it: If you were to force absolutely everything to be statically linked, your KDE app would have to include the ENTIRE KDE library suite, as well as the QT libraries it's based on, as well as the X window libraries those are based on, etc etc. You'd quickly end up with a calculator app that's hundreds of megabytes. That is false. Static linking only links in the the parts that are actually used, which would be a small fraction of the total.
- Vogtinator 8y ago
  Almost all parts end up being used though - for the vast majority it's not possible to prove that it's never used. KCalc would for instance pull in HTML rendering for the Help dialog, which would also add all available picture format plugins and also PDF writing support etc.
  - asark 8y ago
    Reads like a case for passing that off to whichever program responds to a request to open some help HTML.
    - jblwps 8y ago
      And as you begin to flesh out some kind of calling convention, you pretty quickly end up with what could very easily be called dynamic linkage of sorts, even if it's not strictly the linking of object files, etc.
      - asark 8y ago
        Yeah, I figured that'd be a response, but if you're gonna call mime type handlers dynamic linking we may as well give up on using the term at all. I just don't think "I need to let the user open an HTML document, though not as any core part of my program's functionality" is a strong case for "well I guess I'll have to embed an entire HTML rendering engine if I statically link my deps".
jacquesm 8y ago
You are conflating a lot of terms that have nothing to do with each other. Static linking would never cross process boundaries, would optimize for modules that are actually called from the program that the libraries are being linked to and has absolutely nothing to do with IPC. Dynamic linking is useful, but not always necessary and not always appropriate and does not result in 'calculator apps that are hundreds of megabytes', it might be 10Mb or so, which is still large but not comparable.
- pexaizix 8y ago
  KCalc with the KDE libs, Qt, X, libc, and all of their dependencies would become far bigger than 10 MB.
  - roblabla 8y ago
    Kcalc doesn’t use the whole qt library, the whole X library, the whole kDE library, or the whole C library. When you statically link, only the functions that are actually called are included. This can trim a lot of space.
    - tom_mellior 8y ago
      > When you statically link, only the functions that are actually called are included. This is not true in general. For this code: #include <stdio.h> int main(void) { puts("hello world\n"); return 0; } both GCC 7.3.0 and Clang 6.0.0[1] on my system generate an 828 KB binary when compiling with -static. The binary includes a whole bunch of stuff, including all the printf variants, many of the standard string functions, wide string functions, lots of vectorized memcpy variants, and a bunch of dlsym-related functions. By using -ffunction-sections -fdata-sections -Wl,--gc-sections (per https://news.ycombinator.com/item?id=19170667 https://news.ycombinator.com/item?id=19170667) I get this down to 804 KB. Still not quite what you suggest. [1] Clang might just be using the same linker as GCC here, and you might blame including the extra stuff on the linker.
      - 8y ago
jstimpfle 8y ago
> your KDE app would have to include the ENTIRE KDE library suite, as well as the QT libraries it's based on, as well as the X window libraries those are based on, etc etc. You'd quickly end up with a calculator app that's hundreds of megabytes. If you look at the transitive dependencies and then only link in the code that is actually reachable, I doubt that static linking has a significant impact. (I don't know to which degree this is possible with today's toolchains, but I suspect that many libraries have some inefficiencies there due to missing dependency information). As an uneducated estimate (from someone who has written compilers and GUIs entirely from scratch) I'd say 100K of additional statically linked object should be enough for almost any desktop application. > the linkage to the kernel is also dynamic Not an expert here, but you don't link to the kernel at all. The interface is via syscalls. At least on Linux, to help decrease inefficiencies at the syscall boundary, there is some magic involving the so-called VDSO, though - which is indeed dynamically linked, but shouldn't be very large either (On my system it seems the [vdso] and [vsyscall] mappings (both executable) both have size 8K. There is also a non-writeable and non-executable [vvar] of size 8K and I guess it links to live variables written by the kernel).
- alexlarsson 8y ago
  > As an uneducated estimate (from someone who has written compilers and GUIs entirely from scratch) I'd say 100K of additional statically linked object should be enough for almost any desktop application. This is completely misguided. For a modern UI library it is very very hard to figure out what code is actually used. Say we load the ui description from an xml file. What controls get used in the app then? Maybe the xml has a webview control in it? Then we can't drop the webview dependency. Then your app needs to load an icon, which typically goes via some generic image loading API. What types of loaders are there? Can we get rid of the gif loader (and dependencies)? If any single image file reference is not hardcoded in the binary, again we can't. Want to script your application in lua/python/js, and let it call into the UI library? Then we have to assume that basically any code can be reached. Static linking like this just is not realistic.
  - jstimpfle 8y ago
    Yes I agree. I does not work with deep nested dependency chains where some choices are only decided at runtime (after loading additional text files). Maybe it's possible, though, if we remove a little flexibility and flatten the dependencies, such that the application hardcodes a little more of what actually happens (e.g. specificies the file formats for image loading, the format of the ui description, etc). This is the way I've done my own GUI application, where I simply coded what should happen, and created widgets as I needed them, and all the important decisions were known statically. But maybe this amount of specification is not what people expect from a standalone GUI library.
crankylinuxuser 8y ago
As a converse, its very "nice" to have programs in /sbin and some in /bin to be statically linked. And when I say nice, I mean absolutely essential. Ive had glibc go south before... And then nothing works. Its a "hope you can boot with rescue media and hope and pray the old glibc is in your apt/rpm cache". But having the rest of the system being dynamic linked makes a great deal of sense for the reasons you stated.
jcelerier 8y ago
> Think about it: If you were to force absolutely everything to be statically linked, your KDE app would have to include the ENTIRE KDE library suite, as well as the QT libraries it's based on, as well as the X window libraries those are based on, etc etc. no, because we had working LTO for a long time - every KDE app would contain only the exact code that it needs, down to the individual member function. Sure, all KDE apps would have a copy of QObject / QString / QWhatever - but most C++ code nowadays is in headers anyways . > You'd quickly end up with a calculator app that's hundreds of megabytes. The DAW I'm working on (340kloc), which can be built statically linked to Qt, LLVM, libclang, ffmpeg and a few others, is a grand total of 130 megabytes in that case. It's actually heavier when distributed as set of dynamically linked things (unless shipped by linux distros of course, and most of that size is useless LLVM things that I haven't found how to disable yet) : only accounting for the dependencies I have to ship, it would be 176 megabytes - plus 17 megabytes of the actual software. I'd argue that in that case dynamic linking actually takes less disk space overall because most people don't have LLVM installed on their machines and don't need to.
- christina_b 8y ago
  Regular LTO for large sized projects (think Chromium sized), in my experience is by far the biggest bottleneck in the build process. It's partially the reason so much is being invested into development and improving parallel linking as well as techniques like ThinLTO that all aim at reducing the link times since often, LTO linking takes around 60-70% of all build time combined despite the heavy use of C++ code (although with no exceptions or RTTI). Unless you have build servers capable of rebuilding all Qt, WebKit etc. and performing an LTO link (which pulls in all build artifacts in form of bitcode archives/objects) in a reasonable amount of time (big reason buildlabs exist - it takes a long time), LTO is not likely to be suitable, it's an extremely expensive optimization that essentially defers all real compilation until the link step at which the linker calls back into libLLVM/libLTO and have them do all the heavy lifting. At the very least you need a workstation grade machine to be able to do that kind of stuff on regular basis, you really can't expect everyone to have that. And there's a reason libLLVM.so is usually dynamically linked, it cuts a massive amount of time spent on builds, which is especially useful while developing and it's a middle ground between building all LLVM and Clang libraries as shared objects and having to wait for static linking of various LLVM modules into every LLVM toolchain binary (which tends to result in the toolchain being much much bigger). The build cache with shared libLLVM.so for Clang/LLVM/LLD builds is around 6-7GB (Asserts/Test builds). Statically linking LLVM modules blows that up to 20GB. God forbid you actually do a full debug build with full debug information with that. That's a terrible argument against dynamic linking. That's not to say static linking is bad, in fact, recently it's been making a comeback for exactly that reason - LTO and next-generation optimizers. But saying LTO makes static linking viable for everyone including consumers is somewhat far fetched.
asdkhadsj 8y ago
> The key is not to eliminate dynamic linkage, but rather to apply it with discretion, at carefully defined boundaries. Question: In the right system, does discretion even matter? Eg, NixOS - where linked libraries and dependencies are defined by content addressing. Should we use discretion with linked libs in a system like that?
- ingenieroariel 8y ago
  When I started developing in golang I used to prefer static binaries without cgo 100% of the time. Now that I have moved to NixOS and each binary can either use the one in the system or provide their own libc if it is different I feel much better about it. I don't think we need to use discretion in a system like that.
Sir_Cmpwn 8y ago
Several comments have already pointed out many ways that this take is incorrect, but I'll also mention that software like KDE is the antithesis of plan9 design and I bet I'll be 6 feet under before we see it ported.
rb808 8y ago
> You'd have to rebuild EVERY SINGLE THING on the system to build with that new kernel like containers? surely this is the same thing as you suggest, and is a good solution.

Tepix 8y ago

The page is down for me but archive.org comes to the rescue: https://web.archive.org/web/20190215103117/https://9p.io/wiki/plan9/why_static/index.html https://web.archive.org/web/20190215103117/https://9p.io/wik... Or if you prefer google groups: https://groups.google.com/forum/#!topic/comp.os.plan9/x3s1Ibaj_l8%5B51-75%5D https://groups.google.com/forum/#!topic/comp.os.plan9/x3s1Ib... The headline could use a "(2004)" suffix.

deleted 8y ago

[deleted]

pjc50 8y ago

This isn't so much an answer for 9p as a description of why GCC symbol versioning is confusing. > The symbol versioning breaks assumptions users have about how shared libaries work -- that they provide a link to one version of a function and if you replace the library all the programs get fixed. I've seen this problem in practice, for both naive users and very non-naive sysadmins.

glangdale 8y ago

There was a strange and mutually self-supporting pair of ideas in the Plan 9 community at the time: 1) "Shared libraries are bogus." 2) "Anyone who likes normal-looking user interfaces rather than plain boxes with text in them is a poopipants." Both of these propositions are contentious to say the least, but what bothered me was that two propositions were mutually supporting while being (to my mind) orthogonal. The obvious and most compelling example of a shared library on the Unixen at the time were all the various UI libraries (Motif and various other abominations; all of them huge and unwieldy). It seemed necessary to accept that these libraries were obviously Completely Unnecessary to buy into the Plan 9 idea that shared libraries didn't do anything worth mentioning. I'm sure it's possible to design a better UI library (or maybe even a wacky user level file system for user interfaces; in fact, my honours project in 1993!) but at the time the way people made interfaces that looked vaguely like what other people expected computer programs to look like was to use big-ass shared libraries on Linux. This was also the way (dragging in one of those godawful blobs like Motif etc) that anyone might have exerted themselves to port across a (not completely pitiful) web browser, but the degree of aggressive disinterest in supporting Other Peoples Code was extreme (Howard Trickey's "ANSI POSIX Environment" or "APE" didn't get much love as far as I could tell). It was quite undignified to watch people struggling with text-based web browsers or firing them up on non-P9 boxes because of the inability to support the web at the time.

sprash 8y ago
> 1) "Shared libraries are bogus." Starwman, nobody said that. Shared libraries make sense when a program wants to load additional code at run time. A classical example is loading and unloading plugins. For everything else, not so much. 2) "Anyone who likes normal-looking user interfaces rather than plain boxes with text in them is a poopipants." Most people I know use a tiling window manager with terminals. So plain boxes with text in them seems to make sense for many people.
- glangdale 8y ago
  It's hard to recall conversations from 1994, but I came away with the overwhelming sense that the Plan 9 guys thought shared libraries were bogus - certainly that they were bogus for the non-plugin use case (which is the one that pertains to this discussion; libraries like Motif were not plugins). So you've accused me of raising a strawman (actually a "starwman" - "he'd like to cwome and mweet us, but he thinks he'd blow our mwinds") by raising a point absolutely not germane to the discussion, but you when refute my point with this devastating rebuttal: "For everything else, not so much". Most people I know also use the web and menus and buttons and dialog boxes and so forth and expect all this stuff to look vaguely like other computers do. The fact that the Plan 9 folks were trundling over to non-P9 machines to read the web seemed to suggest that they also liked seeing things that weren't just text in plain boxes. The point remains that these two propositions are both at the least contentious, and only by combining these unrelated points could anyone really seriously take Plan 9's approach to shared libraries (at the time) seriously.

pfortuny 8y ago

This is the same people that “just say no” to syntax highlighting for instance.

fao_ 8y ago
For what it's worth, I said no to syntax highlighting three years ago and never looked back. Anecdotal, but I'm making much less errors and paying more attention to the code, now. I think a lot of code highlighting is basically ineffectual, though, given that it (almost always) highlights based on keyword-based regex, rather than the semantic meaning of the code.
- stuross 8y ago
  take a look at https://github.com/tree-sitter/tree-sitter https://github.com/tree-sitter/tree-sitter
- jakear 8y ago
  I use it as visual feedback from the parser. That is, if I’ve messed up a bracket placement while moving code around, all the code after that will be colored “oddly” and I can instantly tell both that I’ve made a mistake, and often where exactly that mistake is. I contest that they highlights based on keyword-based regex too. I haven’t formally analyzed TextMate grammars, but I believe the scoping behaviors take them into context free grammar territory.
- zephyrfalcon 8y ago
  Granted there isn't much to be gained by making your code look like an angry fruit salad. But I do find it useful in some cases, e.g. to make comments stand out from the rest of the code. Also, unterminated block comments or strings will immediately show up as well. And if you are not very familiar with a language, it might help to highlight keywords, so you don't accidentally use them as variable names.
- astine 8y ago
  "Anecdotal, but I'm making much less errors and paying more attention to the code, now." Could be correlation rather than causation. Presumably, you're a more experienced programmer now than you were three years ago and you might be making fewer errors and paying more attention regardless of whether you turned off syntax highlighting.

teddyh 8y ago

SunOS before 4.0, when it still used SunView¹ instead of X11, still did not have dynamic linking. Hence this email rant by John Rose titled Pros and Cons of Suns from 1987 (as included in the preface of The UNIX-HATERS Handbook²): […] What has happened? Two things, apparently. One is that when I created my custom patch to the window system, to send mouse clicks to Emacs, I created another massive 3/4 megabyte binary, which doesn’t share space with the standard Sun window applications (“tools”). This means that instead of one huge mass of shared object code running the window system, and taking up space on my paging disk, I had two such huge masses, identical except for a few pages of code. So I paid a megabyte of swap space for the privilege of using a mouse with my editor. (Emacs itself is a third large mass.) The Sun kernel was just plain running out of room. Every trivial hack you make to the window system replicates the entire window system. […] 1. https://en.wikipedia.org/wiki/SunView https://en.wikipedia.org/wiki/SunView 2. https://web.mit.edu/~simsong/www/ugh.pdf https://web.mit.edu/~simsong/www/ugh.pdf

exitcode00 8y ago
Oh my, each app is going to be 20 mb bigger! This mattered 30 years ago, but now I would say we have a huge problem for end users with all of these "Package managers" and "dependency managers" getting tangled up because there are 5 versions of Perl needing 3 versions of Python and so on... I would be a much more happy Linux user if was able to drag and drop an exe. 100mb be damned
- bepvte 8y ago
  Thats what appimage is for, but if every single thing in /bin/ was 100mb you would have an OS much larger then windows
  - exitcode00 8y ago
    Doubt that, looking at my list of applications - I have 124. So, 100mb * 124 = 12.4 gb and I have half a terabyte of storage... Windows 10 requires 16 gb of storage. Heck most phones have 64 gb these days. We need to stop living in the past - this very issue has probably contributed to the scourge of Electron crap being thrown at our faces since it doesn't suffer from dependency hell they just throw a bunch of javascript into an encapsulated instance of chrome and call it a day.

snarfy 8y ago

In Linux, if libssl is compromised, you install a new libssl. In Plan 9, if libssl is compromised, you re-install Plan 9. That's static linking for you.

IshKebab 8y ago
Yeah that works if your app is in the Debian's software repository (and Ubuntu's and Red Hat's and Gentoo's and etc. etc.). If that is the case it is trivial to update all apps that depend on libssl anyway, even if they use static linking. In practice it is far easier for a lot of software to distribute Windows-like binaries where all but the most basic dependencies are included (e.g. Flatpak or Snappy). In that case dynamic linking doesn't help at all.
- fao_ 8y ago
  Exactly. Modern Ubuntu systems rely on Snap or Flatpak for a lot of software. What these systems do (as I understand it) is package a large amount of the dynamic libraries that would be provided by the operating system, and stick them in a compressed file (or virtual file system, whatever). So what you essentially get is a 200MiB 'binary' without any of the benefits of dynamic linking (being able to swap out a library given a vulnerability without recompiling) OR static linking (a single file, with the extraneous code removed, etc. etc.).
  - vetinari 8y ago
    With flatpak, you can update the runtime (a bundle of libraries) independently of the app, so you can swap out a library with a vulnerability without recompiling.
    - IshKebab 8y ago
      That's not why runtimes exist though - it's too save disk space.
- vetinari 8y ago
  Flatpak has a concept of runtimes, shared among multiple applications, which are basically a well-defined bundles of libraries. So yes, dynamic linking helps there.

nrclark 8y ago

Shared libraries are a pain for sure. They also have a lot of really nice advantages, including: - You can upgrade core functionality in one location - You can fix security bugs without needing to re-install the world - Overall, they take up less disk-space and RAM - They can take much less cache, which is significant today The cache aspect is one that I'm surprised not to see people talk about more. Why would I want to blow out my CPU cache loading 20 instances of libSSL? That slows down performance of the entire system.

taeric 8y ago
I think the dream is you could have one SSL process that others communicated with. Message passing at large.
- otterley 8y ago
  It's not without cost, though. Moving messages around causes CPU data cache pressure and CPU cycles you wouldn't otherwise have spent if you merely referenced shared memory that's mapped into your process.
  - taeric 8y ago
    Right. I didn't mean that to be why it is correct. Just giving some comment to what was actually suggested. Static linking is not the only alternative to dynamic linking.
- joejev 8y ago
  So, like some sort of shared library that my programs dynamically communicate with? How is this functionally different from a shared object?
  - AnIdiotOnTheNet 8y ago
    It isn't really. The actual big problem with shared libraries is that developers cannot be trusted not to change their interfaces or behavior and break things. That's true regardless of what mechanism you use to share code.

wallstprog 8y ago

Obligatory link to Drepper's classics: https://akkadia.org/drepper/no_static_linking.html https://akkadia.org/drepper/no_static_linking.html https://www.akkadia.org/drepper/dsohowto.pdf https://www.akkadia.org/drepper/dsohowto.pdf Seems like the Plan 9 guys haven't heard of these? If done properly, dynamic linking is almost always better than static -- key word here is "properly", which doesn't always/often happen.

linksnapzz 8y ago
Yeah, no true scotsman links his executables dynamically. Also, this is the definitive classic take on Dr. Epper. http://linuxhaters.blogspot.de/2009/05/tribute.html http://linuxhaters.blogspot.de/2009/05/tribute.html
- rleigh 8y ago
  This doesn't appear to be accessible without a Google account.

hollerith 8y ago

Most here seem to know that the motivation for adding DLLs to unix was to make it possible for the X windowing system to fit in the memory of a computer of that time, but many comment writers here seem not to know something that the participants in the discussion that is the OP all knew: Plan 9 has an alternative method for sharing code among processes, namely the 9P protocol, and consequently never needed -- and never used -- DLLs. So for example instead of dynamically linking to Xlib, on Plan 9 a program that wanted to display a GUI used 9P to talk to the display server, which is loosely analogous to a Unix process listening on a socket.

AnIdiotOnTheNet 8y ago
Problem with that is that it is less efficient than a shared library but also susceptible to the same issue, namely that if you change the interface then things break. Edit: It does of course get you extra functionality, like being usable over a network connection. Trade offs.
- erikpukinskis 8y ago
  How is it less efficient?
  - AnIdiotOnTheNet 8y ago
    It involves syscalls and data copying. How could it not be less efficient?
    - moosingin3space 8y ago
      There are examples of very efficient IPC, just not in UNIX-land. If your IPC system is integrated with the scheduler, the difference between a dynamic library call and IPC can be minimized into irrelevance.
    - erikpukinskis 8y ago
      I was not certain that data serialization and copying is required. Is that always true? You can’t do IPC with some shared memory setup?

bakul 8y ago

The idea was that individual programs would be small and loosely coupled. That is, rather than drag in a giant library, abstract out its code in a separate server and talk to it via some protocol. This worked remarkably well on the whole. So the idea of not wanting to have 100 statically linked programs all weighing in at many megabytes kind of misses the point.

kilon 8y ago

I guess I am heretic for breaking my project to a collection of DLLs. Ironically I am doing it over a 2 mil lines of code statically linked code base. The statically linked code base takes 150 seconds to build and my much smaller project only 4 seconds. I have also designed it that way to do live coding in C and I have made a similar library for live coding python . I am addicted to DLLs , send help :D !

pjmlp 8y ago

The Plan 9 fans keep forgetting that the end of the road was Inferno not Plan 9, developed by the same devs, with all Limbo packages being dynamically loaded.

protomyth 8y ago

So, if you don't have dynamically linked libraries and you need a security patch in one of the libraries, how exactly is the system admin going to patch the system. I assume I would need to find every program that contains that library and recompile them?

geggam 8y ago
just like a container
- protomyth 8y ago
  The whole point of containers is that they are all-in-one and prepared each time from some build mechanism. Tracking down every binary on an OS is a whole different thing, thus the creation of containers in the first place.
ben509 8y ago
If I'm an admin, I'm running my own package repo, and I'll rebuild everything that depends on it there.

deleted 8y ago

[deleted]

gcb0 8y ago

site is down now... but I hope it will be honest and just explain that "they did it just so they could do that one demo of tar'ing one process from one machine, 9p'ing it to another box, untar it and the process graphical UI would resume on the new host as if nothing had happened"

equalunique 8y ago

I would like to try Plan9. Is it feasible to get 9front running on a ThinkPad X220?

Sir_Cmpwn 8y ago
Yes. It should run perfectly, including WiFi et al.

joshe 8y ago

The new model of One Version, all updated together is interesting in this context. Examples are iOS, Chrome, Firefox and node_modules. All super complicated with many dependancies. Update everything, fix broken stuff. Only maintain the one blessed dependency graph. If you report an iOS or Chrome bug where you tried to revert a library upgrade and something broke, they'll just mark it "Won't fix: omg never ever look at this". The dependency graph when everyone isn't updating all at once is brutal. Half of Unix life is/was "well I need to update X, but can't because Y depends on old X. Now we'll just create this special environment/virtualenv/visor/vm with exactly the brittle dependency graph we need and then update it, um, never." We complain about One Version/Evergreen, and should, but it's got huge advantages. And might be an indicator that testing surface is the real complexity constraint. One Version's success a good indication that Plan 9 was at least not totally wrong.

B-Con 8y ago
Arch Linux's approach is similar. The only version of the OS that is blessed is the current version. Every package install should come with a full system update. Package downgrades aren't supported. In the case of an irreconcilable "X requires Z v1 but Y requires Z v2" they fork package Z.

newnewpdro 8y ago

What a load of FUD about updating dynamic libraries not actually fixing the code without rebuilding the dependent executables. Symbol versioning does not break things in this way. If you've replaced your only libc.so with a fixed one, there is no other libc.so for dynamically linked executables to link with at runtime. If the new one brought a needed fix, the bug is fixed everywhere using libc.so. It's not like the new library bundles old bits to fulfill old versions of symbols, that's madness. The only way I can see someone getting into a situation implied by the article is when they install multiple versions of a shared library simultaneously, keeping vulnerable versions around, and have executables continuing to use the old copies. This is an administrative failure, and says nothing of dynamic linking's value.

dtzWill 8y ago

This is actually an area of very current research. We have implemented a form of software multiplexing that achieves the code size benefits of dynamically linked libraries, without the associated complications (missing dependencies, slow startup times, security vulnerabilities, etc.) My approach works even where build systems support only dynamic and not static linking. Our tool, allmux, merges independent programs into a single executable and links an IR-level implementation of application code with its libraries, before native code generation. I would love to go into more detail and answer questions, but at the moment I'm entirely consumed with completing my prelim examination. Instead, please see our 2018 publication "Software Multiplexing: Share Your Libraries and Statically Link Them Too" [1]. 1: https://wdtz.org/files/oopsla18-allmux-dietz.pdf https://wdtz.org/files/oopsla18-allmux-dietz.pdf

acqq 8y ago
How does your tool handle the dynamic libraries loaded on demand during the life of the program? Specifically, where the application depending of the user input dynamically loads only one out of the set of shared libraries which all are made to be linked with the main application and use the same interface but are designed to be "the only one" loaded? That is, both the application and each in the set of the libraries expect to have only 1-1 relation (only one library loaded at the time)? Edit: OK, reading further your article, I've found: "our approach disables explicit symbol lookup and other forms of process introspection such as the use of dlsym, dlopen, and others." If you'd manage to implement that too then it seems that really big projects could be packed together.