3 ms·

You're simply making a statement without any proof. I specifically showed how easy it can be to deploy any application on Windows going back over 15 years. Ca

You're simply making a statement without any proof. I specifically showed how easy it can be to deploy any application on Windows going back over 15 years. Can the same be said of Linux distributions over the same time period ?

root_axis 8y ago
Ok. I'll give you the same steps for linux. 1) Install dependencies via package manager. 2) Execute binary. That's it. I don't need a "standard installer", I don't have to install application files to an arbitrary location blessed by the operating system, I can store configuration information in the home-directory or in the application directory or anywhere that makes sense for the application. This works in almost every linux system "going back over 15 years". Now explain to me how I'd deploy an application to Windows with a dependency on, e.g., two specific version of IIS, a MSSQL Database and a node application server to any Windows machine in the last 15 years.
- TimJYoung 8y ago
  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...
- ksk 8y ago
  You forgot a few steps.. 0.1) Convince every single library author to open source their code. 0.2) Convince them to submit (and maintain) the package across all Linux distributions. And many more.. Oh, and hope you don't depend on a specific package version, because you might run into dependency hell on Linux.. Everything is "easy" when you re-define the problems as non-problems for your particular use case.
  - root_axis 8y ago
    Huh? If the project is forced to rely on a closed-source library then that's just an engineering reality, it has nothing to do with the OS you're using. Ironically, this is a non-issue with docker since you can base your image off of whatever distro you need.
    - ksk 8y ago
      I'm not sure why you were confused. I just showed you a simple and common usecase where Linux deployment is not "trivial" as you boldly claimed. >Ironically, this is a non-issue with docker since you can base your image off of whatever distro you need. Maybe docker would help, but I do think suggesting docker in the comment thread of an article detailing how broken docker is is doubly ironical :^)

root_axis 8y ago

Ok. I'll give you the same steps for linux. 1) Install dependencies via package manager. 2) Execute binary. That's it. I don't need a "standard installer", I don't have to install application files to an arbitrary location blessed by the operating system, I can store configuration information in the home-directory or in the application directory or anywhere that makes sense for the application. This works in almost every linux system "going back over 15 years". Now explain to me how I'd deploy an application to Windows with a dependency on, e.g., two specific version of IIS, a MSSQL Database and a node application server to any Windows machine in the last 15 years.

TimJYoung 8y ago
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...
ksk 8y ago
You forgot a few steps.. 0.1) Convince every single library author to open source their code. 0.2) Convince them to submit (and maintain) the package across all Linux distributions. And many more.. Oh, and hope you don't depend on a specific package version, because you might run into dependency hell on Linux.. Everything is "easy" when you re-define the problems as non-problems for your particular use case.
- root_axis 8y ago
  Huh? If the project is forced to rely on a closed-source library then that's just an engineering reality, it has nothing to do with the OS you're using. Ironically, this is a non-issue with docker since you can base your image off of whatever distro you need.
  - ksk 8y ago
    I'm not sure why you were confused. I just showed you a simple and common usecase where Linux deployment is not "trivial" as you boldly claimed. >Ironically, this is a non-issue with docker since you can base your image off of whatever distro you need. Maybe docker would help, but I do think suggesting docker in the comment thread of an article detailing how broken docker is is doubly ironical :^)