3 ms·

What if you have binaries compiled from proprietary code bases from umpteen vendors using different compilers and compiler options and what-not, and they all us

by _yosefk 12y ago

What if you have binaries compiled from proprietary code bases from umpteen vendors using different compilers and compiler options and what-not, and they all use the Internet for self-updating and stuff and they all need to be patched? How are you going to do that? Also - weakly related - what if you want to use a plugin from vendor A inside the program of vendor B, and they live in the same address space - how are you doing it without dynamic loading?

zzzcpan 12y ago
I don't see a problem with proprietary code bases.
wtbob 12y ago
> What if you have binaries compiled from proprietary code bases… Then don't do that. Seriously, RMS, ESR and others have written a plethora of well-reasoned essays indicating why proprietary software is a poor choice.
- GFK_of_xmaspast 12y ago
  ESR advocating for something is reason enough to seriously consider the alternative.
- eropple 12y ago
  So you're admitting that this isn't a solution and you need to change the rules of the game to make it work. Well, I'm convinced.
  - wtbob 12y ago
    'Doctor, it hurts when I stab myself in the eye!' 'Well, don't stab yourself in the eye.'
FreezerburnV 12y ago
Chances are, if you're using those binaries, they have their own versions of whatever libraries they depend on already baked into themselves somehow. So even if they depend on OpenSSL, and you update OpenSSL on your system, they're probably still going to end up using a version from a year ago regardless of what you do.
kryptiskt 12y ago
> What if you have binaries compiled from proprietary code bases from umpteen vendors using different compilers and compiler options and what-not, and they all use the Internet for self-updating and stuff and they all need to be patched? How are you going to do that? The proprietary code isn't going to chance using system libs beyond libc, because of portability. So they likely still need to be patched separately.

by _yosefk 12y ago

zzzcpan 12y ago

I don't see a problem with proprietary code bases.

wtbob 12y ago

> What if you have binaries compiled from proprietary code bases… Then don't do that. Seriously, RMS, ESR and others have written a plethora of well-reasoned essays indicating why proprietary software is a poor choice.

GFK_of_xmaspast 12y ago
ESR advocating for something is reason enough to seriously consider the alternative.
eropple 12y ago
So you're admitting that this isn't a solution and you need to change the rules of the game to make it work. Well, I'm convinced.
- wtbob 12y ago
  'Doctor, it hurts when I stab myself in the eye!' 'Well, don't stab yourself in the eye.'

FreezerburnV 12y ago

Chances are, if you're using those binaries, they have their own versions of whatever libraries they depend on already baked into themselves somehow. So even if they depend on OpenSSL, and you update OpenSSL on your system, they're probably still going to end up using a version from a year ago regardless of what you do.

kryptiskt 12y ago

> What if you have binaries compiled from proprietary code bases from umpteen vendors using different compilers and compiler options and what-not, and they all use the Internet for self-updating and stuff and they all need to be patched? How are you going to do that? The proprietary code isn't going to chance using system libs beyond libc, because of portability. So they likely still need to be patched separately.