3 ms·

That's certainly not been my experience with Linux. Simply trying to get something to work over multiple distributions is a very frustrating exercise, especial

That's certainly not been my experience with Linux. Simply trying to get something to work over multiple distributions is a very frustrating exercise, especially if we're talking anything with a UI, and backwards-compatibility with prior versions is a big issue: https://unix.stackexchange.com/questions/137434/are-there-any-linux-distributions-that-focus-on-binary-backward-compatibility https://unix.stackexchange.com/questions/137434/are-there-an... Edit: also just found this, which does a way better job than I could of describing the issues: https://github.com/phusion/holy-build-box#problem-introduction https://github.com/phusion/holy-build-box#problem-introducti... Re: Standard installers: you aren't required to use an installer, but it makes things easier. You could just copy the .exe to a directory and run it. Most utilities work that way. Re: \Program Files: you aren't required to install your application there, it's just good practice. Re: installing other products with dependencies: you would install them just like any other product and would use their installer. It's up to them to make sure that they keep their dependencies in order. I, for one, certainly won't defend MS in terms of how they distribute their applications. I personally think they're a rat's nest of overly-complicated dependencies, but that is not determined/caused by Windows itself.

root_axis 8y ago
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...

root_axis 8y ago

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...