3 ms·

There is a big difference between deploying code you control and deploying other people's code you do not control. There are plenty of windows binaries that fai

There is a big difference between deploying code you control and deploying other people's code you do not control. There are plenty of windows binaries that fail to run on one version of Windows or another and obviously DLL hell is a thing so I just presumed you were referring to the resources at a developer's disposal for packaging their own software for ease of deployment into a production system and not suggesting that any ol' windows binary "just works" on any version of Windows, because that is definitely not true. Regardless of the OS you have to support your target platforms.

TimJYoung 8y ago
I was referring to deploying one's own application. Obviously, anyone can screw up anything, so the fact that an application installation won't work on a particular OS instance/version can very well be an issue with the application, and not the OS. But, that's basically my point: it's okay if the application screws something up, but the OS should present consistent and backward-compatible APIs for application binaries, and any application-specific libraries should be bundled with the application and installed into application or user-specific locations. You mention DLL hell: this really stopped being an issue in Windows XP because of two things: 1) MS made it so that you cannot very easily drop DLLs into system directories anymore, and strongly discouraged anyone from doing so going forward. 2) MS made an effort to add features like assemblies to allow versioning, etc. to be used in the case where you absolutely, positively needed to do the above: https://msdn.microsoft.com/en-us/library/windows/desktop/aa367757(v=vs.85).aspx https://msdn.microsoft.com/en-us/library/windows/desktop/aa3... However, almost no one besides MS uses assemblies (.NET uses them extensively) because they're complicated to manage and they're not necessary (this is the lesson that Docker advocates are not learning). Global, shared user libraries are a feature for a past that no longer exists where disk space was at a premium. Linux distributions need to a) figure out what a standard Linux API consists of, and b) make the changes necessary to keep these standard APIs in place across all distributions (with backward-compatibility). The browser vendors were able to do this pretty well, and JS in the browser wouldn't work at all without it. Finally, my motivation here isn't to bash Linux because "yay Windows !", rather it's my frustration of watching this go on year after year with Linux, each year hoping that this kind of thing would get resolved and that I might be able to start targeting Linux wholesale. I just cannot understand why this is not a priority...

TimJYoung 8y ago

I was referring to deploying one's own application. Obviously, anyone can screw up anything, so the fact that an application installation won't work on a particular OS instance/version can very well be an issue with the application, and not the OS. But, that's basically my point: it's okay if the application screws something up, but the OS should present consistent and backward-compatible APIs for application binaries, and any application-specific libraries should be bundled with the application and installed into application or user-specific locations. You mention DLL hell: this really stopped being an issue in Windows XP because of two things: 1) MS made it so that you cannot very easily drop DLLs into system directories anymore, and strongly discouraged anyone from doing so going forward. 2) MS made an effort to add features like assemblies to allow versioning, etc. to be used in the case where you absolutely, positively needed to do the above: https://msdn.microsoft.com/en-us/library/windows/desktop/aa367757(v=vs.85).aspx https://msdn.microsoft.com/en-us/library/windows/desktop/aa3... However, almost no one besides MS uses assemblies (.NET uses them extensively) because they're complicated to manage and they're not necessary (this is the lesson that Docker advocates are not learning). Global, shared user libraries are a feature for a past that no longer exists where disk space was at a premium. Linux distributions need to a) figure out what a standard Linux API consists of, and b) make the changes necessary to keep these standard APIs in place across all distributions (with backward-compatibility). The browser vendors were able to do this pretty well, and JS in the browser wouldn't work at all without it. Finally, my motivation here isn't to bash Linux because "yay Windows !", rather it's my frustration of watching this go on year after year with Linux, each year hoping that this kind of thing would get resolved and that I might be able to start targeting Linux wholesale. I just cannot understand why this is not a priority...