3 ms·

The other main argument is so that bug fixes can be deployed to all affected applications by replacing a shared DLL. The importance of this aspect is also going

by wzdd 16y ago

The other main argument is so that bug fixes can be deployed to all affected applications by replacing a shared DLL. The importance of this aspect is also going away now that pretty much everything automatically updates itself via the Internet.

ciupicri 16y ago
Why should I waste bandwidth because DLLs aren't shared anymore?
- roel_v 16y ago
  It's a trade off between using bandwidth (+ the extra hassles for the auto update infrastructure etc., but that is carried by the vendor) and reducing the risk of deployment issues that may not be caught by QA because they are machine-specific. Plus, application dll's are in the magnitude of 100's of kilobytes - I 'waste' more bandwidth with the POP3 polling that my phone does each week than that. I would say that in this context the amount 'wasted' is so small that it can hardly be called a true 'waste'. (I rinse my cup before pouring in new coffee. Is that 'wasted' water? Technically yes, since it goes into the dishwasher at the end of the day anyway and reusing the cup during one day doesn't pose a health risk. That 'waste' won't prevent me from doing so though).
  - ciupicri 16y ago
    Of course it's a trade off, I didn't deny that. I see it just like (micro) optimizations: in some cases it's worth doing it, in others it's not. Regarding the size of DLLs, some of them are indeed small, but others have a couple of megabytes, e.g. XUL (from Mozilla Firefox), Qt, GTK+. Multiply this with the number of applications and it can be come an issue if you have a slow Internet connection.
- tomjen3 16y ago
  Because bandwidth is cheap. Programmers and system administers are not. And neither is your time when you have to fix the broken system.
viraptor 16y ago
> pretty much everything automatically updates itself via the Internet But will the vendor care about every update from the system the program is running on? What happens if someone discovers a bug, your system is updated, but vendor a) doesn't care (or doesn't exist anymore) b) linked statically to some library? You're left with no protection against a known vulnerability, even though the patches are available and published.

by wzdd 16y ago

ciupicri 16y ago

Why should I waste bandwidth because DLLs aren't shared anymore?

roel_v 16y ago
It's a trade off between using bandwidth (+ the extra hassles for the auto update infrastructure etc., but that is carried by the vendor) and reducing the risk of deployment issues that may not be caught by QA because they are machine-specific. Plus, application dll's are in the magnitude of 100's of kilobytes - I 'waste' more bandwidth with the POP3 polling that my phone does each week than that. I would say that in this context the amount 'wasted' is so small that it can hardly be called a true 'waste'. (I rinse my cup before pouring in new coffee. Is that 'wasted' water? Technically yes, since it goes into the dishwasher at the end of the day anyway and reusing the cup during one day doesn't pose a health risk. That 'waste' won't prevent me from doing so though).
- ciupicri 16y ago
  Of course it's a trade off, I didn't deny that. I see it just like (micro) optimizations: in some cases it's worth doing it, in others it's not. Regarding the size of DLLs, some of them are indeed small, but others have a couple of megabytes, e.g. XUL (from Mozilla Firefox), Qt, GTK+. Multiply this with the number of applications and it can be come an issue if you have a slow Internet connection.
tomjen3 16y ago
Because bandwidth is cheap. Programmers and system administers are not. And neither is your time when you have to fix the broken system.

viraptor 16y ago

> pretty much everything automatically updates itself via the Internet But will the vendor care about every update from the system the program is running on? What happens if someone discovers a bug, your system is updated, but vendor a) doesn't care (or doesn't exist anymore) b) linked statically to some library? You're left with no protection against a known vulnerability, even though the patches are available and published.