Content addressable systems are a bad idea: consider hash collisions. In normal use, hash collisions are extremely unlikely. However, with billions upon billions of data blocks being checked by hash, the odds of a collision go up drastically, and you end up getting the wrong data. Occasional data corruption is never acceptable for conventional filesystems, so why should it be acceptable for content-addressable ones?
That's simply not true. It might be good idea under some circumstances, but there's nothing stopping you from distributing an application linked against the system MSVCRT.DLL.
or for a big library that a few people all use small pieces of might actually decrease.
You seem to be under the mistaken impression that if a library is dynamically linked, then the entire library must be loaded before any program can use a portion of the library. That's not true.
Consider a library with symbols A, B, and C, with programs P and Q. Program P uses symbol A from the library, and program Q uses symbol B from the library.
If these programs are statically linked and are run simultaneously, the memory image of P will be P+A, and the memory image of Q will be Q+B. The code for C will not be loaded because it's not linked into any program.
If the programs are linked dynamically, then the memory image of P is stillP+A, and likewise Q is still Q+B. Only the used portion of a library is paged in from disk.
When you create a shared library, it is essential to mark all symbols except those meant to be used by other modules as invisible. Try using -fvisibility=hidden. Otherwise, symbols from other modules (or the main program) can override the ones in your shared library, wreaking havoc. On ELF platforms, all symbols are visible by default. This is a Bad Thing. Windows actually got this one right, and forces programmers to mark which symbols in a DLL are exported.
sometimes that's just not possible so you have to work with what you've got.
The only time something like this should not be possible is when you're working with some plugin system that needs to support old plugins. (Consider in-process Windows Shell Namespace Extensions).
If there's anything we've learned over the past 20 years, it's that shared-library plugin systems are a really bad idea due to the issues you've just described. It's almost always better to execute plugins out-of-process and communicate over restricted IPC mechanisms. That's the direction modern browsers are heading in.
everyone having their own DLL would be the same as just statically linking everything. you'd have tons of code duplicated and loaded. have no easy way to patch common code system wide.
Actually, using private, but separate DLLs is much better than static linking. First of all, if there's a vulnerability, it's much easier to find the vulnerable code.
Also, just to play devil's advocate, private DLLs don't necessarily require more memory and disk use. it'd be possible for the operating system to notice two applications are using identical versions of a DLL and to share their pages, even if the two applications are using DLLs that reside in separate files. That'd help on the memory pressure front.
The operating system could even statically link identical copies of the same DLL (or use a copy-on-write approach) to cut down on disk use.
The SxS system also has some additional security since it uses signatures for the DLLs when loading your process, so it's much harder for a hacker to replace the library you're using behind your back (by setting LD_LIBRARY_PATH for example).
Funny, it's only proprietary software authors that think this way. Over here in the free world, application flexibility is seen as a Good Thing. LD_* hacks might not be the most elegant way to implement certain functionality, but the approach certainly makes hard things possible.
And again, the SxS signing approach doesn't actually add any real security. Someone wanting to modify an application will find a way to do it regardless of any special "don't modify me" bits the application might contain.
(Go ahead and moderate this troll. That doesn't make it any less true.)
Also note that two DLLs loaded into a process can reference different major versions of the same third DLL without a name clash (leading to two versions of it being loaded), while that's AFAIK not possible with shared libraries.
This is a terrible idea due to the two versions potentially clashing in other ways (think different definitions of the same shared data structure), but if you really want to do it, OS X's two-level namespace feature can do that.
Everyone (even Windows programmers) should read Ulrich Drepper's piece on how to write shared libraries. (Warning: PDF.) (Likewise, even free software developers should read Raymond Chen's blog.)
Why would you need to statically link your libc in order to eliminate unreferenced symbols in your own program? GNU ld can do that without having to link statically. You might be saying that thanks to unreferenced symbol elimination, linking libc isn't that onerous, and you might be right. But your program should never be smaller after static linking.
Honestly there are now very problems which can't be solved more quickly and far more effectively in managed code. The difference is even bigger when talking multithreaded code.
Writing "managed" code has nothing to do with using sane concurrency abstractions. You can do one without the other. Hell, you can easily write buggy managed code that relies on raw semaphores and deadlocks often, and you can write elegant message-passing C++ code. The key is the abstraction, not the runtime mechanism.
The only downside is that "advanced" users can't fuck with the application and try to make it use the wrong DLL. I see that as an added bonus.
The rest of your post makes sense (though Unix-style versioning can do the same thing), but this point is wrong. Don't fool yourself or anyone else into thinking you can't modify any application regardless of this stuff. Of course you can: all the SxS stuff might do is make it a touch more difficult.
problems associated with incompatible versions of libraries.
We'll never get rid of the problem with incompatible libraries until processes stop communicating with each other. What if two processes communicate over a shared memory segment where one version is using a data structure with an extra struct field? What about window message differences, drag-and-drop, and file formats? Sure, static linking might paper over some problems, but it won't free programmers from having to think about backwards compatibility.
It'd be more massive if everything were statically linked.
Remember, shared libraries didn't come first. The world began with static libraries, and shared libraries came later. There were good reasons for the switch, and those reasons apply even today.
I read the linked article, and don't see anything exciting. How is this any different from the shared libraries that have been used in the Unix world for 23 years? "Private assemblies" can be achieved with rpath or a simple manipulation of LD_LOAD_PATH (see Mozilla). And what does the asymmetric cryptography buy you over simply using the appropriate soname?
Do we expect anything other than a locked-down proprietary anti-consumer mess out of Sony? After all, these are the people who gave us MiniDisc and the infamous anti-piracy rootkit.
That's all well and good, but if this company's product works, it will market it using well-endowed young female sales representatives to doctors who will use it regardless of whether the patient needs it, and charge unconscionably high rates to insurance companies, who will either outright refuse to approve the beads, revoke the coverage of anyone prescribed the treatment, or simply charge the cost to everyone in the form of yet another year-over-year 20% premium increase.
So while I'm sure the technology is sound, our system of distribution ensures that only the wealthiest will receive it. How is that just?
Absolutely right. What we consider liquid and solid depends on our local environment. In the outer planets of our solar system, water is a rock. It behaves just like rocks here on Earth do: it faults tectonically, crystallizes in various forms, and differentiates into crust, mantle, and core. These bodies have "hydro-"logical cycles made up of methane, which is normally a gas for us.
It's not unusual at all for something we consider to a be a "rock" actually form the hydrological cycle for a much warmer body.
AFAIK, the law states that under penalty of perjury, the issuer of a DMCA takedown notice must be the holder of the copyright on the work in question. There's no requirement that the notice itself be legitimate.
Slashdot Mirror
Content addressable systems are a bad idea: consider hash collisions. In normal use, hash collisions are extremely unlikely. However, with billions upon billions of data blocks being checked by hash, the odds of a collision go up drastically, and you end up getting the wrong data. Occasional data corruption is never acceptable for conventional filesystems, so why should it be acceptable for content-addressable ones?
That's simply not true. It might be good idea under some circumstances, but there's nothing stopping you from distributing an application linked against the system MSVCRT.DLL.
You seem to be under the mistaken impression that if a library is dynamically linked, then the entire library must be loaded before any program can use a portion of the library. That's not true.
Consider a library with symbols A, B, and C, with programs P and Q. Program P uses symbol A from the library, and program Q uses symbol B from the library.
If these programs are statically linked and are run simultaneously, the memory image of P will be P+A, and the memory image of Q will be Q+B. The code for C will not be loaded because it's not linked into any program.
If the programs are linked dynamically, then the memory image of P is still P+A, and likewise Q is still Q+B. Only the used portion of a library is paged in from disk.
When you create a shared library, it is essential to mark all symbols except those meant to be used by other modules as invisible. Try using -fvisibility=hidden. Otherwise, symbols from other modules (or the main program) can override the ones in your shared library, wreaking havoc. On ELF platforms, all symbols are visible by default. This is a Bad Thing. Windows actually got this one right, and forces programmers to mark which symbols in a DLL are exported.
I see you've been working with C++ templates recently.
Read this.
The lesson? Writing good software is hard. There's no silver bullet.
Oops. Correct link. (I wish Slashdot would warn about obviously incorrect links.)
What's to stop you from substituting a key of your choice into the executable? What's to stop you from patching the code that verifies the signatures?
The only time something like this should not be possible is when you're working with some plugin system that needs to support old plugins. (Consider in-process Windows Shell Namespace Extensions).
If there's anything we've learned over the past 20 years, it's that shared-library plugin systems are a really bad idea due to the issues you've just described. It's almost always better to execute plugins out-of-process and communicate over restricted IPC mechanisms. That's the direction modern browsers are heading in.
Actually, using private, but separate DLLs is much better than static linking. First of all, if there's a vulnerability, it's much easier to find the vulnerable code.
Also, just to play devil's advocate, private DLLs don't necessarily require more memory and disk use. it'd be possible for the operating system to notice two applications are using identical versions of a DLL and to share their pages, even if the two applications are using DLLs that reside in separate files. That'd help on the memory pressure front.
The operating system could even statically link identical copies of the same DLL (or use a copy-on-write approach) to cut down on disk use.
Funny, it's only proprietary software authors that think this way. Over here in the free world, application flexibility is seen as a Good Thing. LD_* hacks might not be the most elegant way to implement certain functionality, but the approach certainly makes hard things possible.
And again, the SxS signing approach doesn't actually add any real security. Someone wanting to modify an application will find a way to do it regardless of any special "don't modify me" bits the application might contain.
(Go ahead and moderate this troll. That doesn't make it any less true.)
This is a terrible idea due to the two versions potentially clashing in other ways (think different definitions of the same shared data structure), but if you really want to do it, OS X's two-level namespace feature can do that.
Just like in the physical world, bad packaging can fuck up an otherwise good product.
Incidentally, on Fedora, the scenario you describe doesn't occur.
Everyone (even Windows programmers) should read Ulrich Drepper's piece on how to write shared libraries. (Warning: PDF.) (Likewise, even free software developers should read Raymond Chen's blog.)
Why would you need to statically link your libc in order to eliminate unreferenced symbols in your own program? GNU ld can do that without having to link statically. You might be saying that thanks to unreferenced symbol elimination, linking libc isn't that onerous, and you might be right. But your program should never be smaller after static linking.
Writing "managed" code has nothing to do with using sane concurrency abstractions. You can do one without the other. Hell, you can easily write buggy managed code that relies on raw semaphores and deadlocks often, and you can write elegant message-passing C++ code. The key is the abstraction, not the runtime mechanism.
The rest of your post makes sense (though Unix-style versioning can do the same thing), but this point is wrong. Don't fool yourself or anyone else into thinking you can't modify any application regardless of this stuff. Of course you can: all the SxS stuff might do is make it a touch more difficult.
We'll never get rid of the problem with incompatible libraries until processes stop communicating with each other. What if two processes communicate over a shared memory segment where one version is using a data structure with an extra struct field? What about window message differences, drag-and-drop, and file formats? Sure, static linking might paper over some problems, but it won't free programmers from having to think about backwards compatibility.
It'd be more massive if everything were statically linked.
Remember, shared libraries didn't come first. The world began with static libraries, and shared libraries came later. There were good reasons for the switch, and those reasons apply even today.
I read the linked article, and don't see anything exciting. How is this any different from the shared libraries that have been used in the Unix world for 23 years? "Private assemblies" can be achieved with rpath or a simple manipulation of LD_LOAD_PATH (see Mozilla). And what does the asymmetric cryptography buy you over simply using the appropriate soname?
Do we expect anything other than a locked-down proprietary anti-consumer mess out of Sony? After all, these are the people who gave us MiniDisc and the infamous anti-piracy rootkit.
That's all well and good, but if this company's product works, it will market it using well-endowed young female sales representatives to doctors who will use it regardless of whether the patient needs it, and charge unconscionably high rates to insurance companies, who will either outright refuse to approve the beads, revoke the coverage of anyone prescribed the treatment, or simply charge the cost to everyone in the form of yet another year-over-year 20% premium increase.
So while I'm sure the technology is sound, our system of distribution ensures that only the wealthiest will receive it. How is that just?
Absolutely right. What we consider liquid and solid depends on our local environment. In the outer planets of our solar system, water is a rock. It behaves just like rocks here on Earth do: it faults tectonically, crystallizes in various forms, and differentiates into crust, mantle, and core. These bodies have "hydro-"logical cycles made up of methane, which is normally a gas for us.
It's not unusual at all for something we consider to a be a "rock" actually form the hydrological cycle for a much warmer body.
AFAIK, the law states that under penalty of perjury, the issuer of a DMCA takedown notice must be the holder of the copyright on the work in question. There's no requirement that the notice itself be legitimate.