4 ms·

I think the original reason for shared libraries, and the only true one is that it’s meant to save hard drive (and maybe memory) space. But the ratio between as

by bsaul 6y ago

I think the original reason for shared libraries, and the only true one is that it’s meant to save hard drive (and maybe memory) space. But the ratio between assets vs code is now so big (media files, or data in data intensive algorithms) with code representing nothing, i don’t think any optimisation is really worth it anymore.

teruakohatu 6y ago
There are also security implications. Update one shared lib with a security patch and all applications that use it are now using a patched version.
- posix_me_less 6y ago
  This is very often repeated argument in favor of giving control over shared libraries to the distribution, but it is mostly distribution's marketing. In practice, most users don't really care about security. That very small portion of users who do care about security, don't wait 2 weeks or more for distribution to make fixes available, they fix it/mitigate it themselves as soon as possible. It is true that it is easier to fix one version of a library than 10 different versions. But if you need 10 different versions for different applications, you probably do not need to patch all 10 of them.
  - ithkuil 6y ago
    Most people don't care about security ... until they do. Most people don't understand security and are not equipped with the necessary knowledge to correctly judge risk. As long as security is just something that gets in the way to get some job done, most people will just plow ahead, since not getting the job done right now has a high and easy to understand cost.
- brundolf 6y ago
  It's become increasingly common for desktop applications to aggressively and/or automatically update themselves the same way the OS does, often without even having to go through a "wizard" prompt of any kind. Off the top of my head Chrome, Firefox, VSCode, and Slack (probably my four most-used non-system applications) automatically update themselves whenever I restart them (and prompt me to do so when applicable). Not to mention the fact that an increasing fraction of consumer-facing software now lives in the browser, where updating implicitly happens every time you go to use it. Regardless of how you feel about these trends, they make out-of-date applications much less of a concern than they used to be.
auggierose 6y ago
Shared libraries are also important for apps that want to load plugins via the shared library mechanism.
pavlov 6y ago
That's absolutely not true for desktop GUI apps because so many of them are written in Electron these days. Even small desktop accessories carry their own copy of the Electron and Chromium libraries, usually around 150 MB. It would be a tremendous improvement to use a shared browser engine for this, but developers are resistant.
- posix_me_less 6y ago
  Shared browser engine or any other library would be ideal and in a single project a preferable way. But in practice it is hard to synchronize requirements of different applications, because they are different projects and different people on different schedules. 100 times 150 MB is still only 15GB, a minor part of hard drive, a very acceptable price for 100 functioning independent applications.
  - pavlov 6y ago
    How many of those apps are running simultaneously? Often quite a few. The memory footprint of the engine is larger than the code size on disk. Users may be wasting gigabytes of RAM on trivial desktop tools. The point of the web is to support multiple user agents rather than forcing the user to a specific browser. I don’t understand why that shouldn’t apply to web apps running on the desktop.
    - posix_me_less 6y ago
      > The memory footprint of the engine is larger than the code size on disk. Users may be wasting gigabytes of RAM on trivial desktop tools. That may be the case. Usually it is not a problem, there is mmap and swap and unneeded parts are paged out of physical RAM. If it becomes a problem, one has to change tools or get more RAM.
AnIdiotOnTheNet 6y ago
Not for the vast majority of libraries at any rate, but for libraries that most OSs consider part of their core platform (a concept eschewed by Linux Desktop) they are still a good idea.
jabirali 6y ago
I’m not a lawyer, but I recall seeing a comment that one reason companies currently prefer dynamically linked apps in bundles like Snap and Flatpak over static linking, is that dynamic linking permits more open-source libraries to be used without legal issues. I think it had to do with what legal precedents had been set for linking GPL/LGPL libraries with non-GPL binaries?

by bsaul 6y ago

teruakohatu 6y ago

There are also security implications. Update one shared lib with a security patch and all applications that use it are now using a patched version.

posix_me_less 6y ago
This is very often repeated argument in favor of giving control over shared libraries to the distribution, but it is mostly distribution's marketing. In practice, most users don't really care about security. That very small portion of users who do care about security, don't wait 2 weeks or more for distribution to make fixes available, they fix it/mitigate it themselves as soon as possible. It is true that it is easier to fix one version of a library than 10 different versions. But if you need 10 different versions for different applications, you probably do not need to patch all 10 of them.
- ithkuil 6y ago
  Most people don't care about security ... until they do. Most people don't understand security and are not equipped with the necessary knowledge to correctly judge risk. As long as security is just something that gets in the way to get some job done, most people will just plow ahead, since not getting the job done right now has a high and easy to understand cost.
brundolf 6y ago
It's become increasingly common for desktop applications to aggressively and/or automatically update themselves the same way the OS does, often without even having to go through a "wizard" prompt of any kind. Off the top of my head Chrome, Firefox, VSCode, and Slack (probably my four most-used non-system applications) automatically update themselves whenever I restart them (and prompt me to do so when applicable). Not to mention the fact that an increasing fraction of consumer-facing software now lives in the browser, where updating implicitly happens every time you go to use it. Regardless of how you feel about these trends, they make out-of-date applications much less of a concern than they used to be.

auggierose 6y ago

Shared libraries are also important for apps that want to load plugins via the shared library mechanism.

pavlov 6y ago

That's absolutely not true for desktop GUI apps because so many of them are written in Electron these days. Even small desktop accessories carry their own copy of the Electron and Chromium libraries, usually around 150 MB. It would be a tremendous improvement to use a shared browser engine for this, but developers are resistant.

posix_me_less 6y ago
Shared browser engine or any other library would be ideal and in a single project a preferable way. But in practice it is hard to synchronize requirements of different applications, because they are different projects and different people on different schedules. 100 times 150 MB is still only 15GB, a minor part of hard drive, a very acceptable price for 100 functioning independent applications.
- pavlov 6y ago
  How many of those apps are running simultaneously? Often quite a few. The memory footprint of the engine is larger than the code size on disk. Users may be wasting gigabytes of RAM on trivial desktop tools. The point of the web is to support multiple user agents rather than forcing the user to a specific browser. I don’t understand why that shouldn’t apply to web apps running on the desktop.
  - posix_me_less 6y ago
    > The memory footprint of the engine is larger than the code size on disk. Users may be wasting gigabytes of RAM on trivial desktop tools. That may be the case. Usually it is not a problem, there is mmap and swap and unneeded parts are paged out of physical RAM. If it becomes a problem, one has to change tools or get more RAM.

AnIdiotOnTheNet 6y ago

Not for the vast majority of libraries at any rate, but for libraries that most OSs consider part of their core platform (a concept eschewed by Linux Desktop) they are still a good idea.

jabirali 6y ago

I’m not a lawyer, but I recall seeing a comment that one reason companies currently prefer dynamically linked apps in bundles like Snap and Flatpak over static linking, is that dynamic linking permits more open-source libraries to be used without legal issues. I think it had to do with what legal precedents had been set for linking GPL/LGPL libraries with non-GPL binaries?