4 ms·

I was going to say, "Finally! They've gotten it right after all these years of sucking so hard as to be unusable on servers." But, I did some digging into the g

I was going to say, "Finally! They've gotten it right after all these years of sucking so hard as to be unusable on servers." But, I did some digging into the github for OneGet (https://github.com/OneGet/oneget https://github.com/OneGet/oneget)... And, they haven't gotten it right. Windows package management still sucks so hard as to make the OS unusable on servers (and annoying as hell on the desktop). This is seemingly a simple-minded downloader, with none of the capabilities I would expect of a modern package manager. Sure, it's nice that it can download and install stuff from the command line (and it's idiotic that it's been so difficult to do that in the past), pulling from a variety of sources. But to imply that this is somehow comparable to apt or yum is disingenuous, at best. I'm guessing it's simply ignorance; Windows folks usually have no idea what they're missing (if they did, they couldn't possibly tolerate how bad it is). I can find no mention of dependency resolution, for starters, which is the core reason apt and yum are magnificent. Nothing about querying for what files or commands are provided by which packages. Basic validation tools (i.e. if I uninstall or upgrade X, will Y break?), also seem to be missing. In short: It's simply not a package manager in the sense we mean when we speak of apt or yum. "Lipstick on a pig" is a saying that might apply here.

alkonaut 12y ago
Is application dependency management in windows normally a problem? Apart from the odd runtime, I expect Windows applications to be pretty much self contained, and not dependent on any system-wide libraries (which is a huge benefit I think). For development it's a different story, there you can have several levels of dependencies, but there NuGet at least appears at least as powerful as similar options on other platforms.
- SwellJoe 12y ago
  "but there NuGet at least appears at least as powerful as similar options on other platforms" That seems unlikely (i.e. can we upgrade the whole OS with NuGet?), but it does look like it is, at least, aware of some of the problems an actual package manager solves.
  - alkonaut 12y ago
    Not sure if I was unclear, I was referring to NuGet package management for development, comparing it to e.g. similar systems such as npm.
    - SwellJoe 12y ago
      No, I understood. It seems like NuGet is an acceptable substitute for npm...but neither is an acceptable substitute for apt or yum (whether for development or whatever).
- ioddly 12y ago
  > Is application dependency management in windows normally a problem? It has its own name. http://en.wikipedia.org/wiki/DLL_Hell http://en.wikipedia.org/wiki/DLL_Hell
  - mdlowman 12y ago
    DLL hell certainly used to be a big issue in Windows. But I disagree that it remains a major factor; Windows apps are increasingly bundled and Windows system functions that used to be the cause of these issues, like DirectX, are packaged as redistributables that allow side-by-side installs.
    - ekianjo 12y ago
      > like DirectX, are packaged as redistributables that allow side-by-side installs. No wonder everything gets so messy in the registry :)
    - PeterLindt14 12y ago
      Exactly, thank you.
    - thrownaway122 12y ago
      How do they handle security updates? Does every app have to update all its own libraries in an e.g. heartbleed scenario?
      - useerup 12y ago
        There's the WinSxS and the GAC (Global Assembly Cache). In SxS actually means side-by-side. Both WinSxS and the GAC supports multiple versions of the same libraries, and the program manifests set up policies for which library versions they require/accept. An application may for instance say that it accepts any newer "minor" version. For security patching you can replace a library with a new "build". So if an application uses libraries placed in WinSxS or the GAC it will pick up any centrally patched libraries without the risk of jumping to a too new version with breaking changes. The new version can exist alongside older versions and they can all be patched - for security reasons or otherwise. A vendor can also distribute libraries alongside the application - in the application library itself. In that case the responsibility for patching is placed squarely on the vendor of that application.
- tomc1985 12y ago
  Just want to note that Windows has a whole mess of dependency-management, much of it provided by the service that handles those MSI installer files.
gnoway 12y ago
As long as there is no single prevalent native package format for Windows, packaging is going to suck on Windows. That's why this tool exists, but I don't think attacking a big mess with more complexity is the right approach. I hope I'm wrong, but I think this will end up 'successful' only in the way NuGet is 'successful' - there's not really any competition. What I'd hoped for is that MS would commit to extending MSI to handle new use cases and provide actual good tools to make authoring MSI less painful. Maybe some kind of marketing or outreach to get ISVs to use MSI instead of the various alternatives. But for some reason they don't do that, and now it looks like one of the things cut to make Nano Server is Windows Installer (MSI), so I don't think it's going to happen.
- simoncion 12y ago
  Wait. Are you saying that MSFT is going to walk away from the everything-and-the-kitchen-sink installer format that is MSI? This is actually (seriously!) a bit surprising to me!
  - gnoway 12y ago
    http://blogs.technet.com/b/windowsserver/archive/2015/04/08/microsoft-announces-nano-server-for-modern-apps-and-cloud.aspx http://blogs.technet.com/b/windowsserver/archive/2015/04/08/... "To achieve these benefits, we removed the GUI stack, 32 bit support (WOW64), MSI and a number of default Server Core components."
    - simoncion 12y ago
      You probably have far more expertise in this area, but I don't see this as solid evidence that MSFT is walking away from MSI. I mean, they also removed WOW64 and the GUI. It would be absurd to think that MSFT would ever drop support for the GUI in every version of Windows Server. :)
      - gnoway 12y ago
        I don't, my earlier thoughts should indicate that I have less (or none). Thinking about this more it's more likely that Nano Server won't have packages at all: the container will be the package. You'll build the image and it will have whatever it has. If you need to add/remove 'packages' you will build a new image. So, no need for package management inside the container -> no need for MSI.
beachstartup 12y ago
package management is going to suck on windows as long as permissions sucks on windows. multiple times, i've been unable to delete my own damn files as administrator on windows machines, leaving me angry and frustrated. i've also been stuck in a catch-22 in the extended acl/permissions dialogs, unable to exit. all the googling in the world couldn't help me - it was just fuckin' broke. sane package management can't exist on such a system. an assertion impossible to prove, but i'm right so far.
- SwellJoe 12y ago
  As I understand it, one of the difficult problems on Windows is the file locking semantics. When a library is loaded in memory it cannot be replaced on disk. So updates require a reboot to put new files into place. This might be the cause of the effect you describe (administrator being unable to delete files). It has been about ten years since I maintained some Windows installation packages for a reasonably large project (originally built with a proprietary package builder when I took it over from the previous maintainer and then I ported it to build using a fork of the Python MSI builder). So my understanding of Windows package management and the pains of making things work reasonably is weak and out of date. So take this guess with a grain of salt. I might even be describing what happens and why wrong I dunno...I avoid working on Windows as much as possible, so my ignorance is high. I can really only speak to the comparison of OneGet to apt or yum, which is absurd on its face. And, I have observed the interesting level of denial that kicks in whenever criticism is leveled at an OS based on weak package management. There's always a lot of "well, I just do this ridiculously unwieldy thing and pretend like it isn't a ridiculous and unwieldy thing to do, so I don't see why I would want something like apt or yum". This tread has been no exception. It's like I'm insulting them personally when I say the workflow they are having inflicted on them by their OS is suboptimal.
j_m_b 12y ago
So too little too late?
PeterLindt14 12y ago
Haters gonna hate. Where comes all your frustrations from? I've never had any issues with dependencies on Windows. If some C++ redestributables are missing, they are commonly installed by the installer. .NET Framework the same. For development NuGet.
- rando289 12y ago
  And when a library has a security update, the software which contains it does not get updated, because it's repackaged by 10,000 different software companies that don't care or don't have the resources, and they sit side by side, and disk usage is way bigger than linux. This is partly fixed by the fact that installing software is such a pita and hard to automate that you don't install much 3rd party software on windows.

alkonaut 12y ago

Is application dependency management in windows normally a problem? Apart from the odd runtime, I expect Windows applications to be pretty much self contained, and not dependent on any system-wide libraries (which is a huge benefit I think). For development it's a different story, there you can have several levels of dependencies, but there NuGet at least appears at least as powerful as similar options on other platforms.

SwellJoe 12y ago
"but there NuGet at least appears at least as powerful as similar options on other platforms" That seems unlikely (i.e. can we upgrade the whole OS with NuGet?), but it does look like it is, at least, aware of some of the problems an actual package manager solves.
- alkonaut 12y ago
  Not sure if I was unclear, I was referring to NuGet package management for development, comparing it to e.g. similar systems such as npm.
  - SwellJoe 12y ago
    No, I understood. It seems like NuGet is an acceptable substitute for npm...but neither is an acceptable substitute for apt or yum (whether for development or whatever).
ioddly 12y ago
> Is application dependency management in windows normally a problem? It has its own name. http://en.wikipedia.org/wiki/DLL_Hell http://en.wikipedia.org/wiki/DLL_Hell
- mdlowman 12y ago
  DLL hell certainly used to be a big issue in Windows. But I disagree that it remains a major factor; Windows apps are increasingly bundled and Windows system functions that used to be the cause of these issues, like DirectX, are packaged as redistributables that allow side-by-side installs.
  - ekianjo 12y ago
    > like DirectX, are packaged as redistributables that allow side-by-side installs. No wonder everything gets so messy in the registry :)
  - PeterLindt14 12y ago
    Exactly, thank you.
  - thrownaway122 12y ago
    How do they handle security updates? Does every app have to update all its own libraries in an e.g. heartbleed scenario?
    - useerup 12y ago
      There's the WinSxS and the GAC (Global Assembly Cache). In SxS actually means side-by-side. Both WinSxS and the GAC supports multiple versions of the same libraries, and the program manifests set up policies for which library versions they require/accept. An application may for instance say that it accepts any newer "minor" version. For security patching you can replace a library with a new "build". So if an application uses libraries placed in WinSxS or the GAC it will pick up any centrally patched libraries without the risk of jumping to a too new version with breaking changes. The new version can exist alongside older versions and they can all be patched - for security reasons or otherwise. A vendor can also distribute libraries alongside the application - in the application library itself. In that case the responsibility for patching is placed squarely on the vendor of that application.
tomc1985 12y ago
Just want to note that Windows has a whole mess of dependency-management, much of it provided by the service that handles those MSI installer files.

gnoway 12y ago

As long as there is no single prevalent native package format for Windows, packaging is going to suck on Windows. That's why this tool exists, but I don't think attacking a big mess with more complexity is the right approach. I hope I'm wrong, but I think this will end up 'successful' only in the way NuGet is 'successful' - there's not really any competition. What I'd hoped for is that MS would commit to extending MSI to handle new use cases and provide actual good tools to make authoring MSI less painful. Maybe some kind of marketing or outreach to get ISVs to use MSI instead of the various alternatives. But for some reason they don't do that, and now it looks like one of the things cut to make Nano Server is Windows Installer (MSI), so I don't think it's going to happen.

simoncion 12y ago
Wait. Are you saying that MSFT is going to walk away from the everything-and-the-kitchen-sink installer format that is MSI? This is actually (seriously!) a bit surprising to me!
- gnoway 12y ago
  http://blogs.technet.com/b/windowsserver/archive/2015/04/08/microsoft-announces-nano-server-for-modern-apps-and-cloud.aspx http://blogs.technet.com/b/windowsserver/archive/2015/04/08/... "To achieve these benefits, we removed the GUI stack, 32 bit support (WOW64), MSI and a number of default Server Core components."
  - simoncion 12y ago
    You probably have far more expertise in this area, but I don't see this as solid evidence that MSFT is walking away from MSI. I mean, they also removed WOW64 and the GUI. It would be absurd to think that MSFT would ever drop support for the GUI in every version of Windows Server. :)
    - gnoway 12y ago
      I don't, my earlier thoughts should indicate that I have less (or none). Thinking about this more it's more likely that Nano Server won't have packages at all: the container will be the package. You'll build the image and it will have whatever it has. If you need to add/remove 'packages' you will build a new image. So, no need for package management inside the container -> no need for MSI.

beachstartup 12y ago

package management is going to suck on windows as long as permissions sucks on windows. multiple times, i've been unable to delete my own damn files as administrator on windows machines, leaving me angry and frustrated. i've also been stuck in a catch-22 in the extended acl/permissions dialogs, unable to exit. all the googling in the world couldn't help me - it was just fuckin' broke. sane package management can't exist on such a system. an assertion impossible to prove, but i'm right so far.

SwellJoe 12y ago
As I understand it, one of the difficult problems on Windows is the file locking semantics. When a library is loaded in memory it cannot be replaced on disk. So updates require a reboot to put new files into place. This might be the cause of the effect you describe (administrator being unable to delete files). It has been about ten years since I maintained some Windows installation packages for a reasonably large project (originally built with a proprietary package builder when I took it over from the previous maintainer and then I ported it to build using a fork of the Python MSI builder). So my understanding of Windows package management and the pains of making things work reasonably is weak and out of date. So take this guess with a grain of salt. I might even be describing what happens and why wrong I dunno...I avoid working on Windows as much as possible, so my ignorance is high. I can really only speak to the comparison of OneGet to apt or yum, which is absurd on its face. And, I have observed the interesting level of denial that kicks in whenever criticism is leveled at an OS based on weak package management. There's always a lot of "well, I just do this ridiculously unwieldy thing and pretend like it isn't a ridiculous and unwieldy thing to do, so I don't see why I would want something like apt or yum". This tread has been no exception. It's like I'm insulting them personally when I say the workflow they are having inflicted on them by their OS is suboptimal.

j_m_b 12y ago

So too little too late?

PeterLindt14 12y ago

Haters gonna hate. Where comes all your frustrations from? I've never had any issues with dependencies on Windows. If some C++ redestributables are missing, they are commonly installed by the installer. .NET Framework the same. For development NuGet.

rando289 12y ago
And when a library has a security update, the software which contains it does not get updated, because it's repackaged by 10,000 different software companies that don't care or don't have the resources, and they sit side by side, and disk usage is way bigger than linux. This is partly fixed by the fact that installing software is such a pita and hard to automate that you don't install much 3rd party software on windows.