Comment by SwellJoe | Hacker News Reader

Comment by SwellJoe | Hacker News Reader

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

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.

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.

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

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.

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

> Is application dependency management in windows normally a problem?

It has its own name.

http://en.wikipedia.org/wiki/DLL_Hell

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.

> like DirectX, are packaged as redistributables that allow side-by-side installs.

No wonder everything gets so messy in the registry :)

Exactly, thank you.

How do they handle security updates? Does every app have to update all its own libraries in an e.g. heartbleed scenario?

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.

Not sure who "they" is here, ut in windows: pretty much, yes. You can't have it both ways. So you either have a centralized/shared lib environment where you may run into conflicts but you get centralized patching, or you have self contained applications where you need to patch each one but you never have lib dependency/upgrade issues. Simple as that.

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.

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.

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.

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.

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.

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.

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!

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

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

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.

That's actually a really good thought about the reason for MSI removal in Nano Server!

(And, TBH, my only experience with MSI was briefly working with a vaguely recent version of InstallShield several years ago. The fact that you can talk about the pain of MSI authoring probably indicates that you understand more about the topic than I do. I just clicked some buttons in the InstallShield UI, and skimmed some of the MSI developer docs. :) )

So too little too late?

Reply on news.ycombinator.com