Live data from Hacker News

Introducing PackageManagement in Windows 10

blogs.technet.com

131–140 of 221 posts

Re: Introducing PackageManagement in Windows 10

#131

Earlier quoted context omitted.

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 platf…

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

Re: Introducing PackageManagement in Windows 10

#132
post #91

Earlier quoted context omitted.

> I currently have Jenkins build an OS image every two weeks, just so our Deployment Server has an up to date image. Ya, lots of tools have made this easier recently, but thinking about it, doesn't WSUS handle this? I haven't been a Windows admin for a while, but I thought with WSUS it was install, join and forget while it did it's thing. Maybe it's been too long ...

WSUS just caches updates locally, so you can download once and have the WSUS server distribute copies to your forest. It's a GPO that points your domains to the WSUS server. And I've only used Octopus to automate WU installs.

> WSUS just caches updates locally

New updates do supersede others though, if they're marked to do so from Microsoft. That should cover at least some of the .Net point release updates and the like.

Re: Introducing PackageManagement in Windows 10

#133

Earlier quoted context omitted.

> Ever want to... That's because Bash is used to tie together separate programs that do the work. PowerShell, on the other hand, is a .NET shell and more equivalent to the shells in Python, Node, Ruby, the JVM, etc, all of which provide ways to work with JSON and many different data structures.

That's a false distinction. bash has a (primitive, idiosyncratic) language built-in. So does PS. They also are both designed to glue together independent programs via the pipe abstraction. The difference is that PS has much more modern language constructs and capabilities. The fact that it hooks into the .NET API as well is only a convenience.

> They also are both designed to glue together independent programs via the pipe abstraction

PowerShell and its object pipeline are focused on cmdlets which are not arbitrary programs, they are .NET classes, and PowerShell objects are .NET objects.

Unix shells like sh and bash are focused on tying together separate programs and only have a very minimal set of built-in commands.

The focus of each one is very different, despite PowerShell's syntax.

Piping objects between cmdlets in PowerShell is analogous to working with objects in Python, Ruby, Perl, etc, not like Unix pipes.

Re: Introducing PackageManagement in Windows 10

#134
post #36

Earlier quoted context omitted.

You do if those scripts can affect the system and need to run as root. Powershell is incredibly powerful (and dangerous) and some security isn't the worst thing.

the irony of this is that if ms were to leave powershell open to run any scripts from anywhere at any time, they'd be ridiculed for lax security policies.

why? .cmd and .bat can run any time, and can do just as much damage as powershell.

Re: Introducing PackageManagement in Windows 10

#135
post #87

Earlier quoted context omitted.

It's like they wanted sudo and user accounts with arbitrary permissions but had no idea how to do that, so they did UAC and this stuff instead.

Windows has an analogy to sudo, called runas UAC is designed to solve a different problem, users on Windows historically ran as administrator, and much legacy software requires it, UAC is designed to provide an apparent administrator environment to the software but catch what the software is using, and give the user a chance to approve privilege escalation.

runas is more of a su analogy than a sudo one.

Re: Introducing PackageManagement in Windows 10

#136
post #74

Earlier quoted context omitted.

If you want to do advanced stuff in your scripts, you've never been limited on unix systems to just sh or bash, but on Windows you still don't have a good shell for interactive use.

How is it fair to give the example of the Python shell in Unix but not in Windows when it runs in both?

What? Python isn't the kind of thing you would use as an everyday interactive system shell; it's a scripting language that can incidentally be used interactively but isn't well-suited for that, especially without extras like ipython. And quite aside from that, every unix-like desktop OS comes with Python pre-installed; Windows doesn't.

Re: Introducing PackageManagement in Windows 10

#137
post #135
post #87

Earlier quoted context omitted.

Windows has an analogy to sudo, called runas UAC is designed to solve a different problem, users on Windows historically ran as administrator, and much legacy software requires it, UAC is designed to provide an apparent administrator environment to the software but catch what the software is using, and give the user a chance to approve privilege escalation.

runas is more of a su analogy than a sudo one.

I disagree, the -u option for sudo gives you nearly identical functionality.

Re: Introducing PackageManagement in Windows 10

#138
post #38

Earlier quoted context omitted.

It's a disaster. The proper way to do it is distro packages, but for some reason every language, framework, ecosystem and individual developer wants to reinvent this particular wheel. I really don't understand why.

It's because individual tools usually don't want to be tied to assumptions made by one particular distro. I actively avoid using distro packages for 3rd party development libraries and such, especially when a good tool for accessing upstream sources (eg pip) is available. I use packages for certain tools and platforms, and libraries if I feel the library is really something I want to be a standard part of the system…

One technical reason is that I might use two different versions of the same library in different projects and apt-get only allows me to have one at the time. I think npm and gem are brilliant on this regard.

Best of both words: docker. I consider docker an application packager.

Re: Introducing PackageManagement in Windows 10

#139

Perhaps I missed it, but the article doesn't mention this in any way: Windows ABSOLUTELY needs a way to go from 'Fresh Install' to 'Fully upgraded' with minimal interaction. Linux can do this: run `apt-get dist-upgrade` in Ubuntu, and you get all of the most recent updates. However, in Windows, you install 3 updates, restart, install 5 updates, restart, install 110 updates, restart....

One of the core issues with breaking this pattern is that you're installing a new feature on this reboot, then installing all of its patches on the next reboot. So you install 186 updates on a fresh install. This includes .NET 4.5 (or 4.5.1 or 4.5.2), and requires a reboot. Now you're done right? You just installed 168 updates, how many updates can there be? On your next reboot, you get another 60 updates, of which 2…

This is also compounded by how long those updates take because they somehow managed to make writing files to disk a CPU-bound process at some point in the mid-2000s. If you have 50MB of updates to install on any other operating system it will take a few seconds but on Windows XP+ it will run at a few hundred KB/s while using 100% of a CPU which can run SHA-512 at well over 1Gbps.

Re: Introducing PackageManagement in Windows 10

#140
post #138

Earlier quoted context omitted.

It's because individual tools usually don't want to be tied to assumptions made by one particular distro. I actively avoid using distro packages for 3rd party development libraries and such, especially when a good tool for accessing upstream sources (eg pip) is available. I use packages for certain tools and platforms, and libraries if I feel the library is really something I want to be a standard part of the system…

One technical reason is that I might use two different versions of the same library in different projects and apt-get only allows me to have one at the time. I think npm and gem are brilliant on this regard. Best of both words: docker. I consider docker an application packager.

Docker is definitely one answer.
Post reply on HN