Windows 10 Gets a Package Manager For the Command Line

aojensen writes: ExtremeTech reports that the most recent build of Windows 10 Technical Preview shows that Windows is finally getting a package manager. The package manager is built for the PowerShell command line based on OneGet. OneGet is a command line utility for PowerShell very similar to classic Linux utilities such as apt-get and yum, which enable administrators and power users comfortable with the command line to install software packages without the need for a graphical installer. ExtremeTech emphasizes that "you can open up PowerShell and use OneGet to install thousands of applications with commands such as Find-Package VLC and Install-Package Firefox." It's a missing feature Linux advocates have long used to argue against Windows in terms of automation and scale. The package manage is open to any software repository and is based on the Chocolatey format for defining package repositories."

Comments

Re:We can do that thing you like

[Anonymous Coward]

What makes you think they won't open it up?

MS has done a pretty abrupt about-face over the past couple of years. MVC/WebAPI, Roslyn, EntLib, EF, WinJS, etc. are open source. Much of the .NET stack is open source. You can easily stand up an entirely open system on Azure (Mongo/Hadoop/Node, many other options).

They've even got internal movements going to open up some of their popular but unsupported software, like LiveWriter.

Re:A step in the right direction

[jandrese]

Text files don't get corrupted unless you're trying to edit them with a malfunctioning tool. The idea that per-config ACL is considered a good thing is also quite dubious to me. I've seen what happens when people harden Windows systems. Windows permissions are way too complex for their own good. SELinux is almost as bad, except that it at least will tell you when it is blocking something and sometimes even suggest what you need to do to fix it, unlike the silent failures that are common in Windowsland.

A common occurrence on a hardened Windows box: You sit down and double click an application to start it. The application immediately exits and maybe puts up a box that says "Error", but has no useful diagnostic information whatsoever. So you go to check the windows event viewer, before you remember that no useful information is ever allowed to touch the Windows event log. If you're lucky there will be an entry in the log for your application, but it will just say "Error: An unspecified error has occurred".

Turns out an inherited permission on a registry key was blocking a write to value the application was trying to do to keep track of launches.

Re: Oh boy, another infection vector

[MMC Monster]

The problem with user controlled is that the user will add a repository and forget about it.

It happens on the Linux side as well. It just doesn't make news because there it's mostly white hats and not black hats.

Imagine this scenario: A website says it is packaging Windows10 versions of VLC with special added codecs to play stuff it otherwise doesn't play. People then add the repository and all is well. A year later, the repo gets hijacked by a virus and adds a version of GIMP v999 with the virus. Since it's a newer version of GIMP than what everyone has, they download it automatically and are infected en mass. People aren't looking for it since they already vetted the repo.

It happened with Ubuntu a while back, where some guy noticed his private repo was getting thousands of hits. So he put a new version of the default desktop background picture in it telling people to get off his repo.

Re:We can do that thing you like

[war4peace]

In which case it would make no sense for each application to try and store the DLL locally. I shiver when I imagine an application being uninstalled and removing deduplicated DSLLs that every other application uses, simply because its developer was cutting corners or incompetent.

Re:We can do that thing you like

[CastrTroy]

I never really understood DLL Hell. In Windows I've had very few instances of any that I can think of where 2 programs had conflicting versions of the same DLL. In Linux, I've had all kinds of dependency hell. In the early days, before there was automatic dependency resolution, you had to track down dependencies by yourself, often leading to circular loops or being unable to find a certain version of a library that was needed to install something. Now that dependencies are automatically resolved, you can still run into problems where one package requires the old version, and a different package requires a new one, and you can't install both versions at the same time. The problem usually crops up as soon as you have to install something that isn't in the main repository. If something isn't in the main repository, and isn't statically linked, the odds of a successful install plummet quite low.