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

We can do that thing you like

[Anonymous Coward]

Everything except open-sourcing the code that is.

Re:We can do that thing you like

[khasim]

Installing via the command line is nice. But it isn't what I want.

I want a package system that locks the files down so that package X owns abc.dll and will not allow package Y to overwrite it.

And searchable. What package installed abc.dll? What packages depend upon that package?

Re:We can do that thing you like

[mysidia]

They're late comers to this party: We already have community repos. Chocolatey and BoxStarter. Why would we need OneGet?

It's Internet Explorer vs Netscape all over again :)

Re:We can do that thing you like

[mwvdlee]

I guess if you could set up your own repository, this could be a useful tool for enterprises.

Re:We can do that thing you like

[His name cannot be s]

Actually, to be perfectly clear, OneGet isn't really a package manager.

It's a package-manager-manager -- It's a unified way of installing packages of software regardless of the how-it's-implemented-on-the-back-end.

The first real package provider plugin is a Chocolatey one. Why re-invent the wheel when the wheel already works?

The purpose here is to leverage all these different sources of software using a common set of commands and APIs.

Anything that can be represented as a 'source' of software can be plugged in on the back end. I'm aiming for plugins for NPM, Ruby Gems, Python, on top of the expected MSI, Chocolatey, NuGet, etc...

Plugins can be written by anyone, and I'm going to great lengths to make it as simple as possible -- it's about ~15 or so functions to implement and we can plug in virtually any package format or service into OneGet.

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:We can do that thing you like

[Anonymous Coward]

What this article forgot to mention is that this project actully IS Open Source, under tha Apache v1.2 licence and hosted on GitHub.
https://github.com/OneGet/oneget

Re:We can do that thing you like

[Anonymous Coward]

Wow, that's pretty nice. A GitHub repository with full C# source code and Visual Studio project files.

Re:We can do that thing you like

[tehlinux]

>Why would we need OneGet?

Updates through Windows Update? (I didn't actually read TFA)

Re:We can do that thing you like

[bondsbw]

The installer should put abc.dll in the same directory as the .exe file instead of a shared location.

Re:We can do that thing you like

[war4peace]

...leaving you with many identical abc.dll files spread throughout the storage system. Not sure I like this.
Ideally I would love file versioning with diffs, but that's just unobtainable.

Re:We can do that thing you like

[Anonymous Coward]

Not really. For home users (and I'd imaging small offices) Windows Update is handled via BITS / WUAUSERV. For large enterprises, there's whatever the heck WSUS is called these days - isn't it part of config manager or something. For medium business there's CT Offline Update.

But anyway, this for Windows components is a pretty well-solved problem. It's when third-party software enters the mix that things get messy. I'm hoping for something scriptable / extendable that will allow the easy maintenance/deployment of my internal software repository to targetted machines and which doesn't require AD.

Perhaps the Ninite guys should take note - this could end up eating the breakfast of their business-class tool.

Re:We can do that thing you like

[Newander]

But disk space is really cheap these days. The lost disk space seems like a small price to pay to avoid DLL Hell. Of course static linking would also remove the whole problem.

Re:We can do that thing you like

[Anonymous Coward]

I was gonna say that! Chocolatey rocks. MS is always a day late and a dollar short. For every new thing they do, there's always a better alternative. All their latest stuff is a major let down. Everything we're getting excited about is 3rd party stuff, like chocolatey, boxstarter, vagrant, scriptcs and what not. And now, Classic Start Menu is a necessity to make Windows 8.x or 10 usable.

Re:We can do that thing you like

[bondsbw]

Data deduplication is supported in Windows Server, although I have no idea if it will be directly supported by Windows 10.

Re:We can do that thing you like

[war4peace]

Disk space ain't that cheap, especially if you install the applications on a SSD. Furthermore, a large application is using literally gigabytes of shared DLLs which would otherwise be saved separately. Disk space usage would astronomically increase.

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

[NotInHere]

Thats something very odd by Microsoft. I just think: WTF? Microsoft and Open source? and even more: Microsoft and open source that ships with windows?? Really, something has moved in redmond.

Re:We can do that thing you like

[bondsbw]

The file system manages data deduplication via garbage collection. http://msdn.microsoft.com/en-u...

When an optimized file is deleted from the data deduplication-enabled volume, its reparse point is deleted, but its data chunks are not immediately deleted from the chunk store. The data deduplication feature's garbage collection job reclaims the unreferenced chunks.

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.

Re:We can do that thing you like

[Mr. McGibby]

Typical MS. They just love create stuff in which other people can do stuff, instead of just doing the stuff. Can they create a package mangement tool? NO! They have to do something on top of that. For the love of pete, just *do* something. Stop doing stuff that allows other people to do stuff (that they will never do).

Re:We can do that thing you like

[benjymouse]

https://en.wikipedia.org/wiki/...

Rather than leaving the dependency resolving responsibility to package maintainers, the Windows OS contains a brokering mechanism that will load the correct version of an assembly - even if multiple versions of the same assembly exists in the global assembly.

Linux package managers have dual responsibilities: Provide available software (with update mechanism) and ensure dependency hell does not rear its ugly head. Linux dependency hell is very real, once you step outside the repositories.

Windows has binary compatibility with software that was developed for Windows 95 / Windows NT 3.1 (where Win32 debuted). The dependency problem (called DLL hell in Windows) was solved with the SxS and the broader use of the Windows Installer package manager, which integrated with SxS.

Re:We can do that thing you like

[benjymouse]

In Linux, I've had all kinds of dependency hell.

Yes, Linux never solved dependency hell, it has been swept under the rug that is distro+version specific repositories. The problem is still very, very real, but if you constrain yourself to the repositories of the distro + version that you use, the package maintainers will have ensured that the package dependencies do not conflict with each other and with the version of the ABI that your distro+version is on.

DLL hell was *very* real in the Windows 9x days. Side-by-side assemblies was introduced with Windows 98SE (IIRC) - but really only became de rigueur with Windows XP. During the 9x days, software developers took advantage of the fact that nothing prevented them from writing files to the system directories. When they encountered a problem where they needed a DLL - they simply installed it in the system directory - often overwriting whatever was there before. Obviously this caused all sorts of problems where only the latest installed product had a robust state.

Re:We can do that thing you like

[benjymouse]

The installer should put abc.dll in the same directory as the .exe file instead of a shared location.

No!

If the DLL is indeed candidate for being shared (e.g. part of a shared product) it should put the assembly/DLL in the Global Assembly Cache (GAC). This is a side-by-side store where the same assembly/DLL can exist in multiple versions.

If security vulnerabilities are found and a patch is released, only the version in the GAC needs to be updated, often by registering a new version with a manifest/redirection that will ensure that anyone requesting the old (vulnerable) version will be treated to the new (fixed) version.

Windows Installer does this. And supports patching.

Re:We can do that thing you like

[VGPowerlord]

DLL hell was *very* real in the Windows 9x days. Side-by-side assemblies was introduced with Windows 98SE (IIRC) - but really only became de rigueur with Windows XP. During the 9x days, software developers took advantage of the fact that nothing prevented them from writing files to the system directories. When they encountered a problem where they needed a DLL - they simply installed it in the system directory - often overwriting whatever was there before. Obviously this caused all sorts of problems where only the latest installed product had a robust state.

To add to this, Microsoft shipped a faulty copy of mfc42.dll with Visual C++ 6. It removed a bunch of functions.

Now, keep in mind that mfc42.dll was used by any MFC applications compiled by Visual C++ 4.2-6.x... including Netscape, Microsoft Publisher, and a number of other programs.

Oh, did I mention that MFC was the recommended way of writing Windows programs back then?

Incidentally, Microsoft started including the VC++ version number in its DLL names again after this thanks to that screwup... which they had done before (vc++ 4.1 had mfc41.dll, etc...)

Re:We can do that thing you like

[theskipper]

Hang on a second. Microsoft is a proprietary software vendor and will attack anything that jeopardizes their revenue stream. They're putting the "free candy" sign on the outside of their van based on a business decision, not because they want to create some warm and fuzzy community effort (i.e. actually give out free candy!).

It's in their DNA to only promote things that will further generating revenue because their shareholders require it (and rightfully so, they are the owners).

Point being, they must have opened up that other stuff because some competitive threat existed, or there was a sound basis that it would create further lock-in and recurring revenue down the road. It doesn't follow that future software releases like this must be opened just because they opened other pieces of their software portfolio.

Re:We can do that thing you like

[Hamsterdan]

Sure, if you're not using a SSD

Re:We can do that thing you like

[Hadlock]

We're already assigning resources to see how we can leverage this next year at our office/windows shop.

Re: We can do that thing you like

[Anonymous Coward]

This is already possible with chocolatey

Re:We can do that thing you like

[operagost]

"...a man can not have his cake and eat his cake."
- Thomas Howard, Duke of Norfolk

Re:We can do that thing you like

[ArmoredDragon]

Possibly. It seems the new CEO is himself far more in touch with modern software development, whereas Ballmer was basically just a salesman. But I think what is probably more important than that is that Stephen Sinofsky is gone. Apparently he was a total dick, made a lot of unilateral decisions, and was actively hostile against anybody who suggested any big changes.

IMO somebody like him would reject OneGet (probably suggesting to use the Microsoft Update system instead.)

Re:We can do that thing you like

[gbjbaanb]

Na, there's always been a few open source projects in MS, I think they're semi-official projects that someone started and released in a way to sell more of the tools.

Wix was the first, it is an xml-baased editor that creates installer packages.

Then they did ASP.NET MVC Razor 5 (or whatever its called) which is basically a web-site project template with some 'magic' framework code. I think this ships with Visual Studio now.

And now they have OneGet... fair enough. I doubt anyone at Microsoft will be too unhappy its open source, its not exactly critical to the base platform, but it keeps the consumers of Windows happy - and they have already bought Windows so the Microsoft suits are happy too.

Re:We can do that thing you like

[Anonymous Coward]

I haven't seen that problem since they introduced the DLL cache donkies years ago.

Re:We can do that thing you like

[Anonymous Coward]

It ain't about the space. One library maintained as a package in it's own right means that when a security flaw is patched that every application linking the library gets fixed. If every application carries it's own local copy then each application must become aware of the problem and issue an update. Guess which is more likely.

The downside is libraries that break things when they update, thus requiring every program that linked to it to get complaints from users and issue an update. The solution to that problem is holding library maintainers to stricter standards.

Re:We can do that thing you like

[Anonymous Coward]

Then a vulnerability is found in abc.dll and you can't just patch it in a system directory. Besides if you're going to have your own copy anyway, why not just statically link?

Re:We can do that thing you like

[Anonymous Coward]

Of course a company wants to make money. It is the same reason why Red Hat uses open source: it is actually good for their business. Microsoft has just noticed the same thing.

Re:We can do that thing you like

[Anonymous Coward]

> I want a package system that locks the files down so that package X owns abc.dll

Don't worry, keep the faith, MS will invent Docker in a decade or two.

Re:We can do that thing you like

[sexconker]

...leaving you with many identical abc.dll files spread throughout the storage system. Not sure I like this.
Ideally I would love file versioning with diffs, but that's just unobtainable.

Windows has attempted to do this with WinSxS. Every fucking thing in the world installs its own versions of shit and the WinSxS folder allegedly keeps track (and copies) of what shit uses what version of other shit. This has been in place since Vista. The other options are DLL hell or every application shipping with everything it needs to run.

Re:We can do that thing you like

[NotInHere]

From the last weekly meeting of oneget developers I can tell that the chief developer wants to integrate oneget into the traditional Microsoft update UI.

Re:We can do that thing you like

[disambiguated]

Typical programmers.
FTFY.

Besides, if you think that's bad, you should see what happens when they actually do do something. <grin/>

Re:We can do that thing you like

[Anonymous Coward]

Everything except open-sourcing the code that is.

You mean this not open sourced code at https://github.com/OneGet/oneget that's released under the standard Apache 2.0 license? That not-open-source code?

Re:We can do that thing you like

[Anonymous Coward]

I want a package system that locks the files down so that package X owns abc.dll and will not allow package Y to overwrite it.

And searchable. What package installed abc.dll? What packages depend upon that package?

MSI installers already do all of this. The information's not exposed by UIs, but the data and APIs are all there.

MSI's are a bitch to author, though.

Re:We can do that thing you like

[bruce_the_loon]

De-duplication doesn't work that way. The system tracks duplicates at block level and if a configured cluster size of blocks is identical, the file block stream is chained through a single copy of the blocks. If a new version of the file appears, it will fail the block check and will have space allocated to it. If more copies of the new version then appear, they will be chained through the single copy of the new version.

If you delete a single instance of a de-duped file, it is handled the same way as multiple hard links to a file on a unix file system. The FAT entry (if you don't mind the archaic reference) is removed and the reference count to the data is decreased by one. No blocks are freed for overwrite if other FAT entries reference the blocks. So NO, an installer deleting one instance of a de-duped DLL will not remove the contents of the file from disk as the blocks are referenced by other files.

Re:We can do that thing you like

[Anonymous Coward]

Can you give any example? Don't think I've ever seen an application use "several gigabytes" of DLL files....... That's a looooot of code

Re:We can do that thing you like

[SeaFox]

Ironically, it sounds like Microsoft is the victim of FUD being spread by open-source zealots like the original poster AC you're replying to.

Re:We can do that thing you like

[Immerman]

"I'd like to see a man eat his cake without having it."

Re: We can do that thing you like

[Arterion]

Are you seriously complaining because they aren't implementing a new proprietary package management system? Holy smokes, Microsoft just can't catch a break!

There's always msiexec if you want a Microsoft way to do command line package management. While it may seem arcane, it's totally functional. You can do a lot with group policies and logon scripts. There's even a way to add a repository of sorts for desktops using active directory. And to be clear on this, you can literally download a ".msi" file and it's not wildly different from a rpm or deb package. Most exe installers just are just wrappers for an msi anyway.

And then there's there's the app store in Windows 8, too.

Re:We can do that thing you like

[Anonymous Coward]

This is virtually impossible in windows without breaking backwards compatibility. As long as windows allows dynamic allocation of resources, determining the resources that that application depends upon is nearly impossible. The only effective way to do this is to disable api sich ad LoadLibrary(Ex) and the like. Which would break thousands of existing programs.

Re:We can do that thing you like

[mysidia]

As long as they're going to build and provide plugins for the common use cases, who cares? It could be pretty cool. Sounds like a more flexible architecture if they can support multiple package systems.

On the other hand, it might just be unneeded complexity. Frankly, in a lot of places I like things that are SIMPLE, Reliable, and Fast. I prefer programs that do one thing well and work with other programs using standard text-based communications to meet the rest of needs instead of attempting to accomadate every possible use case within one piece of software ----- a plugin architecture with proprietary interactions is not necessarily "working well" with other programs; it's kind of the opposite idea, expanding one program with addons.

It makes sense for a PACKAGE system to support multiple kinds of storage repositories, like Yum or APT does.... you can have your CD-based Repos, FTP based Repos, and private mirrors.

I'm not sure it makes sense for a package management system to support arbitrary backend plugins.

Re:We can do that thing you like

[godefroi]

Only works for .NET applications. What about native applications?

Re: We can do that thing you like

[Anonymous Coward]

if you want open source then get Linux.

Re:We can do that thing you like

[Zyst]

The main problem I have as a Chocolatey early adopter is that it still lacks an uninstall function, and once you have a respectable amount of packages installed through Chocolatey the update 'Chocolatey is going to determine all packages available for an update. You may not see output for a while...' can take upwards of 5 minutes, even when there's nothing to update. When Chocolatey updates a package it keeps both the old and the new version, my hope with the Windows version of it is that it includes this functionality. Basically I'm hoping the official Windows version will be a better, stronger and faster version of Chocolatey, that also improves on its base functionality. I am aware this won't mean much to the average user but it was enough to convince me to at least try it out over adamantly sticking with Windows 7.

Re:We can do that thing you like

[shutdown -p now]

Microsoft is actively trying to move away from being a "software vendor", and become a hardware and services company. Services, in particular, means cloud. And to sell cloud, you need to offer people what they want in it, which includes open source, Linux etc.

Re:We can do that thing you like

[shutdown -p now]

You haven't been looking too closely for the past few years then. Quite a lot of .NET is open source these days, for example. TypeScript is open source. F# is open source. Python Tools and Node.js Tools for Visual Studio are open source.

Re:We can do that thing you like

[NotInHere]

Yeah, I know of codeplex, but open source stuff that ships with windows is still rare, is it?

Re:We can do that thing you like

[shutdown -p now]

Kinda. Thing is, the trend lately has been to decouple stuff. So for example, where Entity Framework used to be shipped in box with .NET (which in turn ships in box with Windows), it is now a NuGet package - and open source; but it doesn't ship with Windows anymore. In a similar vein, ASP.NET is a part of .NET Framework, and hence also ships in the box - but ASP.NET MVC, its replacement, is, again, an independent NuGet package. And .NET itself is moving into the same direction in general, being detangled from the OS and becoming more like Mono, a separate redistributable runtime that you can just put alongside the app.

I don't know if the same is going to happen with C# and VB command line compilers. Today, they also ship as part of .NET, so any Windows install since Vista comes with those compilers. The new ones were rewritten from scratch as part of the Roslyn project, and that is open source, but they might also want to stop shipping them as OS components.

I admit that I don't know much about the F/OSS MS story outside of development and admin stack, but there it's very heavy - VS does ship with a bunch of F/OSS stuff in the box, including some of its own components, and more so as time goes by. A bunch of Azure stuff, SDKs and admin tools, is also open sourced.

By the way, most new MS open source projects (and some of the older ones) have moved to GitHub, so that's the latest and greatest, not so much CodePlex anymore.

Re:We can do that thing you like

[sg_oneill]

Disk space ain't that cheap, especially if you install the applications on a SSD. Furthermore, a large application is using literally gigabytes of shared DLLs which would otherwise be saved separately. Disk space usage would astronomically increase.

Its actually how the Macs have been doing it since forever. You know those .app files macs use? They are actually directories with a little XML file telling the OS how to run them. Its traditional to include the .dylink and .so files (the macs version of .dll) inside that .app directory under /Contents/Resources. This way you NEVER get .dll hell.

Well until you install two different package managers on top of each other and all your unix command line apps start freaking out.

Blame early osx unix devs who tried to turn OSX into linux for that mess.

Package source?

[Anonymous Coward]

And what is the source of these going to be? Is it going to be like the app store with 30 thousand DOWNLOD VLC apps that come with shitloads of spyware?

Re:Package source?

[unity]

It says right in the summary that it is open to any software repository. I'd be surprised if CodePlex isn't supported immediately.

Great! Just a few more things please

[Anonymous Coward]

* Make the OS kernel along with its applications open source
  * Create a better file hierarchy
  * Document your filesystems

Then I'm ready to test it.

Oh boy, another infection vector

[Russ1642]

This is just an easy way to install software without much popping up on the screen to alert the users. I wonder how long it'll be before reports of infections using this installation method. What we really want is someone typing Install-Package Chrom and getting infected because of a typo.

Re: Oh boy, another infection vector

[mattc65]

Inexperienced Linux user here but whilst I agree with you why is this not a problem on linux

Re:Oh boy, another infection vector

[Anonymous Coward]

Windows lacks an apt analogue: "OMG Windows is so shit it doesn't have apt"
Windows adds an apt analogue: "OMG Windows is so shit everyone knows package managers are a massive vulnerability"

Re:Oh boy, another infection vector

[Anonymous Coward]

And if Crom doesn't help you, well, fuck you Crom.

Re: Oh boy, another infection vector

[jeffclay]

It's not a problem on linux because the community manages the software repository. If it is found that a package owner (someone who creates the .deb or .rpm packages from the source of the original project) is adding malicious code, the package will be removed rather quickly, package owner probably banned and who knows what else. I doubt Microsoft would allow that level of scrutiny in whatever repo system they setup for this.
Anybody else is welcome to chime in if I'm incorrect on this.

Re:Oh boy, another infection vector

[Anonymous Coward]

This is just an easy way to install software without much popping up on the screen to alert the users. I wonder how long it'll be before reports of infections using this installation method. What we really want is someone typing Install-Package Chrom and getting infected because of a typo.

How dreadful! Maybe those Linux guys should consider taking such a horrible security risk out of distros then. </sarcasm>

Re: Oh boy, another infection vector

[Anonymous Coward]

It's not a problem on linux because the community manages the software repository.

And as the half dozen or so people in the community all know each other, it's not likely they're going to shit on their friends.

/jk

Re: Oh boy, another infection vector

[Anonymous Coward]

I have no idea how this will work but i'm certain they will get it wrong. Will they allow me and only to control where packages come from for example? Will it track individual files? What about versioning? Can I create my own packages? Is the package format open?

Re:Oh boy, another infection vector

[Lazere]

1. Nobody said he was a linux user. In fact, judging from a 5-second reading of his post history, it looks like he's a Windows fan.
2. This is not an apt analogue. It doesn't do dependency management, otherwise known as the main thing people like about apt. All this is, is a way to download and run the installer with a single command. The packages downloaded from this can still shit all over your system.
3. Who's controlling the main repository? Is is Microsoft? Because if it is, they haven't had a very good record of keeping the Windows store clean.

Re: Oh boy, another infection vector

[goarilla]

If Microsoft maintains an app-repo they will scrutinise it otherwise there is no point in using it. Yes there will be
attempts to subvert it and get malicious software in there. Just like with the Apple App Store.
And sometimes they will succeed but overall this is a brave move of them.
Just like their new implemention of Virtual Desktops. I applaud it.

Re:Oh boy, another infection vector

[tehcyder]

This is just an easy way to install software without much popping up on the screen to alert the users. I wonder how long it'll be before reports of infections using this installation method. What we really want is someone typing Install-Package Chrom and getting infected because of a typo.

LOL security through pop up tick boxes.

Re: Oh boy, another infection vector

[His name cannot be s]

Well, considering that the chocolatey provider for OneGet points to the community-controlled repository, I'll have to take that as a win :)

The concept of curated repositories is one that we're really trying to come up without screwing it up.

Regardless, with OneGet, the *user* maintains control. Which repositories they connect to, what software they install.

Re:Oh boy, another infection vector

[lippydude]

Linux uses a list of approved Repositories, does OneGet work the same way?

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: Oh boy, another infection vector

[NatasRevol]

And how long until all a virus does is point to a different repo & install unmanaged software? Just like android & third party repos.

Re: Oh boy, another infection vector

[His name cannot be s]

You've got a really good point.

We're tossing around some notions about different factors that make a 'package' or 'repository' trustworthy.

I'm sure we can do some stuff with signed repositories and signed packages to detect when things 'change' and/or keep unsigned repositories 'untrusted'.

Really, our first target for this stuff is developers and admins, not my mom...

Re:Oh boy, another infection vector

[oic0]

Um... you can already install silently on pretty much all versions. MSI is really good at it and installshield can do it with an answer file. I do it remotely from command line all the time at work.

Re: Oh boy, another infection vector

[Anonymous Coward]

Because the people who manage the repositories do so by name and reputation. That, coupled with the fact that ALL of said process of management, is documented online. In short, it's almost impossible to falsify yourself to get into a position to manage a distro repository, and start doing nefarious things while going unnoticed. Thus why the attack vector for such a thing is the server directly, or a single package itself. For example, see attack and compromise of kernel.org servers, yet the linux kernel itself was unharmed.

Call it the community monitoring itself, but people put there name and reputation out there for these systems. Microsoft can hide behind, well, variable anonymity in such a system. And most likely, will. Who runs the software repo's for Microsoft? Well Microsoft. But who exactly? Don't know. It's the same thing you see with Windows Updates, when those go south. Who do you contact? Microsoft. But who? Just Microsoft.

Re:Oh boy, another infection vector

[His name cannot be s]

'Approved' isn't the right word.

OneGet has the notion of 'trusted' repositories. We're likely to expand this concept a bit in the future, but for now, that's what it is.

Built-in package sources from reputable sources may be marked as 'trusted' by default, but the majority of sources should be 'untrusted' until the user makes that change.

The real trick is getting package provider plugins to tell OneGet the truth if a repository is trusted or not.

I suspect that we're going to have to introduce a level of trust with the package providers too, and expose this to the user ... somehow.

Re: Oh boy, another infection vector

[MrNaz]

Perhaps you could have a two tier level of trust where repositories that are from signed approved vendors are automatically permitted, but unlisted ones require specific admin permission to install from. Of course, power users could mark an unlisted certificate as trustworthy to prevent the auth request, but it would prevent installs from silently coming in from hijacked repositories in the scenario described above.

Re:Oh boy, another infection vector

[i.r.id10t]

But are there any dependency issues in Windows? Been ages since I've used it, but I don't recall having to chase down DLL files, other installers, etc. to get something to install or run properly....

(oh, and on the similar story the other day I got a -1 troll for asking if we could check out c:\windows\system32\drivers\etc\apt\sources.list)

Re:Oh boy, another infection vector

[AmiMoJo]

I really doubt most clueless users will suddenly be taking to the command line to install stuff. In any case, this doesn't bypass the usual security warnings like UAC prompts or the need for the administrator password.

Personally I welcome it as it means Internet Explorer will no longer be required to download Chrome every time I do a fresh install.

Re: Oh boy, another infection vector

[NJRoadfan]

You have to provide a superuser password to install packages in Linux. On Windows you would get a UAC prompt.

Re: Oh boy, another infection vector

[Anonymous Coward]

Unless you're using sudo on Linux, in which case you just have to type your own password.

And unless your Windows user account isn't in the Administrators group, in which case that UAC prompt will ask you for a superuser's username and password.

Re: Oh boy, another infection vector

[nabsltd]

We're tossing around some notions about different factors that make a 'package' or 'repository' trustworthy.

A very simple solution is to prohibit a package from Repository B from overwriting the already-installed same-named package from Repository A. Then, add a command line parameter to override the prohibition. I know that yum keeps track of which repo a package came from, and the user can set up this kind of protection, but it isn't the default.

This doesn't protect against installing malware if it's the first time you installed a package, and doesn't stop malware from making it's way into a "trusted" repository, but it does prevent the example from the GP.

Re: Oh boy, another infection vector

[benjymouse]

I'm sure we can do some stuff with signed repositories and signed packages to detect when things 'change' and/or keep unsigned repositories 'untrusted'.

Suggestion: For "trusted" repositories, toenable automatic updating, developers must sign the original install package with a certificate. Self-issued certs could be ok for this part. Any subsequent updates must be signed with the *same* certificate. If not, it will *not* automatically update - even if the repository is "trusted". OneGet clients will only allow auto-update if the product/vendor names are the same and the certificate public key is the same. Otherwise a warning should be issued and the local administrator should choose whether to trust the new cert going forward.

Re:Oh boy, another infection vector

[SeaFox]

I really doubt most clueless users will suddenly be taking to the command line to install stuff.

The problem isn't so much clueless users, but users who think they're not.

Re:Oh boy, another infection vector

[Anonymous Coward]

Linux uses every repository you tell it to use. By default only the distributions own repositories are enabled. You can add others anytime. Best example is Adobe with the Adobe Reader. They provide a small script which adds their repository to apt or yum and then you can install and update Adobe Reader like any other linux program. At least that was the way some years ago.

Re: Oh boy, another infection vector

[nine-times]

Still, honestly, this is the problem that I'd rather have. For me, I'd rather have the danger of the administrator of the computer making a stupid decision than to be forced into a walled garden.

And I'm not saying this as some kind of advocate of anything. I just control thousands of computers professionally, and I'm willing to take responsibility for which repository I connect to, rather than having to choose from only Microsoft-approved repositories.

Re: Oh boy, another infection vector

[Anonymous Coward]

That's a troll. But it's a funny troll. Duly modded up, well played sir!

Re: Oh boy, another infection vector

[Kjella]

It hardly matters at all, since if you added the repository you probably set it up to prefer at least one package from there. So unless you got a very fancy SELinux setup all the attacker has to do is bump the version number of that package and his malware installation script will run as root and be able to change any file at will.

Re: Oh boy, another infection vector

[Anonymous Coward]

zypper in openSUSE does this. If you do an update, it will not update packages across repositories. When packages are installed, they are pinned to the repository it was downloaded from. If you want to upgrade to the latest package, no matter what, you need to do a dist-upgrade.

Re: Oh boy, another infection vector

[Anonymous Coward]

Like linux doesn't have this problem. I'm more worried about their announcement about only running code signed by a specific vendor list. If a virus manages to get around this they'll wreck your PC pretty easily.

Re: Oh boy, another infection vector

[nabsltd]

It hardly matters at all, since if you added the repository you probably set it up to prefer at least one package from there.

Yes, if a repository that you get a crucial package from is pwned, you are hosed.

But, by locking packages to a repository, you won't update openssh from "Joe's Repository for Cool Games", since the current version comes from a more official repository that hopefully will have better security (and more eyes on it).

Yay! Another Unix!

[jfbilodeau]

Now that Windows is kinda-sorta-Unix-like, should it be on DistroWatch.com? </sarcasm>

Re:Yay! Another Unix!

[BitZtream]

Since when were package managers a UNIX thing?

Re:Yay! Another Unix!

[BenLutgens]

"Now that Windows is kinda-sorta-Unix-like"

Wtf?

Re:Yay! Another Unix!

[Anonymous Coward]

Since every last one of them (even OSX) except for windows had one?

Re:Yay! Another Unix!

[Anonymous Coward]

Nah! Windows can never be considered Unix-y.

It's never done just one thing and it's never done those things well.

Re:Yay! Another Unix!

[war4peace]

That would make it a non-Windows thing, not a Linux thing.

Re:Yay! Another Unix!

[Anonymous Coward]

Actually you mean Unix and all of the ones in that category have a some kind of package manager.

Re:Yay! Another Unix!

[Anonymous Coward]

Windows has been kinda-sorta-Unix like since NT 3.1 (remember, it's supposed to be POSIX compliant)

Growing up?

[Anonymous Coward]

They grow up so... err... slow?

A step in the right direction

[Anonymous Coward]

Now if Microsoft would just shit-can the registry.

Re:A step in the right direction

[Anonymous Coward]

You have to be kidding me. They don't litter the filesystem more than the registry is littered with entries. They go in /etc (you, my Windows boy, can read it as /registry) and after that it's not much different. Except that you can edit it with any text editor you prefer and can migrate settings in bulk from one machine to another easily.

Re:A step in the right direction

[Megol]

Except there is no common storage format for configurations. Except there is no per configuration setting ACL permission. Except the text files aren't protected against corruption.

There are many reasons to complain about the registry - too bad almost no-one ever mentions any real problem when complaining.

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:A step in the right direction

[NatasRevol]

There's no common storage format for configurations?

Hmm, I guess that's why no one uses XML for it.

Re:A step in the right direction

[Anonymous Coward]

They go in /etc (you, my Windows boy, can read it as /registry)

Except the junk in my home directory which is sprinkled all around in ~/.appname/, ~/.config/, ~/kde/, and so on, with various different file formats.

Re:A step in the right direction

[Blaskowicz]

They go in /etc, /etc/foo, /etc/default, /etc/alternatives, /usr/share/something, ~/.foo, ~/.config, ~/.config/bar and possibly other things and god help you if you have both dconf and gconf installed.

Some stuff is special : output resolutions are added with xrandr --newmode, xrandr --addmode and not by editing a configuration file (you did so in the times xorg.conf was not hidden). Or some stuff takes effect when you rebuild the initramfs, fine.
I'm not especially complaining (complexity is complex) but it's not really easy. Ah yes, forgot about /etc/xdg. It would be better if the system explained what the fuck do /etc/default and /etc/xdg mean. Sorry, I'll classify it as guru stuff.

Re:A step in the right direction

[savuporo]

You actually have audit log for seeing what exactly failed - but by default its not logging at very granular level. You can turn it on to be waay verbose, drown in the logs and then use arcane filtering techniques to figure out what happened. Or use something like ProcMon / ProcExp combo to try and trace the issue.

The situation is much different where for unix daemon failures you either spend about an hour trying to get the strace command line just right so that the correct bit of failure information is actually captured and visible, or spend another hour doing a rebuild from source, and try to get it launched in foreground with gdb with all the correct environment settings - set by a dozen or more different env, etc and shell script wrappers.

This is the pinnacle of computing today.

Re:A step in the right direction

[DocHoncho]

It's a good thing they don't have something like %APPDATA%, otherwise there would be the worst of both worlds! A registry crammed full of cruft and detritus AND a hundred thousand vendor whatever files laying about.

"Should we put this config option in the registry or the config file?"
"Flip a coin!"

Re:A step in the right direction

[Anonymous Coward]

As opposed to going belly-up in Windows, then your SOL.

And we both know that your scenario is not the norm.

Re:A step in the right direction

[jandrese]

Typically on Linux you will have a far more usable log (Error: Unable to open 'foo': Permission denied), and SELinux does come with auditd which gives you a specific log whenever it blocks something. Some distros even come with a GUI that will pop up and tell you what was rejected and why. It's still a pain in the ass, but it's not the hopeless nightmare you get on a hardened Windows box.

Seriously, Windows Developers, we really really don't need the "this API call worked normally" messages spamming the logs like crazy. Or at least if you're going to do that, make sure you also log API failures and TELL ME WHAT FAILED. "Error: an error occurred" is a useless message. Give me something I can stick into Google at least, even if it is some stupid number.

Re:A step in the right direction

[operagost]

You've pretty much set up a straw man, huh? The Windows application log is accessible by programs, so if a developer doesn't use it, it's their fault. Your hand waving of the obvious solution to registry manipulation errors is pathetic.

Re:A step in the right direction

[Anonymous Coward]

dconf/gconf is a registry wannabe, and not really a representative for the config file school of thought.

As for the rest of the stuff, it can be a mess, but still tons better than the registry. No one cares if they make a mess in the registry, because no one ever looks there anyway.

if app store only then this will be next to useles

[Anonymous Coward]

if app store only then this will be next to useless

Respect

[nine-times]

I really respect this move from Microsoft. It's something they should have done a while ago, but better late than never. It has the potential to make administration much easier. They should also maintain their own repo of patches as an optional replacement for Windows Update.

Re:Respect

[His name cannot be s]

[FYI -- I'm @FearTheCowboy everywhere else, my /. id is so old that my name got trimmed from "His Name Cannot Be Spoken" 15ish years ago when they did a database adjustment... ]

I have had thoughts on how to do this; I suspect that while we may not set up a repo to do that, I may hack out the instructions on how that could be done easily if one wanted to maintain their own.

It really boils down to how much time I can throw at that.

Of course, we also want it to plug into WU and WSUS, but that'll be a bit more down the road.

Re:Respect

[goarilla]

Is this technology supposed to replace Windows Installer and MSI packages or does it built on it ?

Re:Respect

[armanox]

I would imagine build on it.

Re:Respect

[nine-times]

I'm under the impression that this is not a new package format, and so you'd still have MSI files, but it's a method for automated download/installation of MSI files (and perhaps other files) based on a repository and install list.

Re:Respect

[nine-times]

Good to know. So I take it you're somewhat responsible for this? I love you then. As a systems/network admin, this has long been on my wishlist.

I wouldn't mind running my own repo for Windows patches, as long as there are tools to make it easy, including some way of automating pulling patches into my repo.

As far as integration with WSUS, I wouldn't mind seeing WSUS replaced/melded into a single solution, but I'm less interested in maintaining two different update solutions that plug into each other. Especially not if they have different behaviors and interfaces. Not that you asked, but I'd definitely prefer a single solution that can hold arbitrary 3rd party software, doesn't expect to be part of a larger Windows network security context (can easily be configured as a stand-alone server in "the cloud"), and is easily controllable on the client via powershell. Easy GUI tools for setting it up and maintaining the repo would be a bonus, but not vital.

I look forward to seeing what this turns into.

A step in the right direction

[Anonymous Coward]

Yes, I much prefer a billion config files littering the file system.

What sort of apps?

[unixisc]

Given Microsoft's penchant for supporting legacy, such as 32-bit Windows 10, what sort of apps will we see here? Everything from win32 apps from the NT era and since? Will it be like PC-BSD's PBI, which determines which version of a library is needed, and includes that with the said download? Or will it be a clean win64 downloads only?

Re:What sort of apps?

[AmiMoJo]

The current repository is added to by users. Microsoft seem like they want to keep it that way, although of course I'm sure they will take over maintenance of their own products. I had a quick look and Visual Studio is already on there.

Difference between this and DISM?

[Anonymous Coward]

Windows has had a command line package manager for quite some time now named DISM. It's usually described as an offline package management tool but works just fine on live systems.

Does this replace DISM or is this just a re-branding/update?

Re: Difference between this and DISM?

[Anonymous Coward]

Dism only installs packages that are part of windows

We already had this?

[MachineShedFred]

which enable administrators and power users comfortable with the command line to install software packages without the need for a graphical installer.

Haven't we already had this since like Windows 2000 in the form of msiexec.exe /i \\path\to\package.msi /qb- ?

I guess they added wget to it in order to download it from the Microsoft Store, and that makes it newsworthy?

Re:We already had this?

[angryargus]

AKA "silent mode" installs that people who actually know anything about Windows have been using for automated installs for almost as long as Linux has existed. MSFT was already providing apps/CLIs like dism for their own packages.

Re:We already had this?

[armanox]

Think of it this way - your command is using "rpm -hiv /path/to/package.rpm"

Microsoft is adding "yum install package" to the options list.

Re:We already had this?

[metrix007]

We had command line tools for managing packages, but not for searching and installing from a repository.

call me crazy

[Pro923]

But I'd still usually rather browse to a piece of software that I want and click on it. I always assumed that yum was a workaround for a way to install things when you don't actually have a GUI.

Windows 20 will be POSIX compatible

[Anonymous Coward]

After Microsoft has copied every good idea UNIX/Linux has.

Re:Windows 20 will be POSIX compatible

[Dracos]

LOL, no it won't. Whatever MS copies is always so badly reimplemented that there's no way they could achieve POSIX compliance.

Re:Windows 20 will be POSIX compatible

[gweihir]

You already can do POSIX. Just use Cygwin. Of course that is not a solution MS will find palatable, as it exposes those doing it to a far saner and productive environment.

Re:Windows 20 will be POSIX compatible

[Blaskowicz]

Microsoft deprecated their POSIX layer (after making it artificially unavailable in Windows 7 Pro whereas XP Pro could run it)
Ironically, Windows 10 won't be POSIX compatible while earlier Windows version were (not sure about 8.1)

It pissed me off to not be able to install the "Unix" shell in Windows 7 Pro. I only wanted a toy environment with *sh, grep, less, wget, sed etc. and some simple programs, but still. It had a terrible reputation but it would have been interesting to have it. Cygwin sucks and a Virtualbox VM with file system passthrough just to run cat and ls sucks.

Re:Windows 20 will be POSIX compatible

[Anonymous Coward]

Linux isn't even fully POSIX compliant, which is OK because nobody really gives a fuck about POSIX anyway except the rubes that just like to throw the word around as if it means something. When will Linux copy a desktop that's fast and smooth but isn't a buggy clone of Windows 95?

Re:Windows 20 will be POSIX compatible

[i.r.id10t]

The gnu32 utils were the textutils, fileutils,etc. collections compiled for Win32. I would imagine you can still find them on the interwebs somewhere.

Re:Windows 20 will be POSIX compatible

[gbjbaanb]

That would be here

almost useless

[Haven]

Have you ever tried to make your application a debian package or RPM? It's a royal pain in the ass. Windows developers are not going to do whatever it takes to make this go smoothly on Windows.

There is a 100% chance that nearly every "Package-Install" command will just be downloading the app for you and launching the graphical installer you normally see.

People in charge of deploying software on windows are miserable people.

Re:almost useless

[Aqualung812]

There is a 100% chance that nearly every "Package-Install" command will just be downloading the app for you and launching the graphical installer you normally see.

Tell me more about this 100% chance of a graphical installer on Windows Core (non-GUI).

If they have to make it work in core, why would it fire up a graphical installer?

I'll take any bet that it is something less than 100%....

Re:almost useless

[goarilla]

If it knows how to wrap the different installers' (nullsoft,installshield,etc...) /silent options, then it's fine by me.

Re:almost useless

[NatasRevol]

What percentage of windows installs are Windows Core? Can you round it up to 1%?

Re:almost useless

[Anonymous Coward]

I hope you're not trying to claim that Windows Core installs are rare-- on the contrary, Windows Core is generally how Windows servers are installed and configured in enterprise environments.

Re:almost useless

[advantis]

I can say I have. I couldn't wrap my head around RPM, but I didn't try that hard. Debs on the other hand are easy as pie. It takes me about 5 minutes to refresh my memory on dh_make (man dh_make), then create a deb using dpkg-buildpackage -rfakeroot -b -us -uc (if you actually want signatures it still doesn't get much harder). No pain in the ass at all, royal or otherwise.

Re:almost useless

[NatasRevol]

Relative to ALL windows installs?

Yes, they are rare.

Re:almost useless

[phantomfive]

Have you ever tried to make your application a debian package

Yes, it's essentially a compressed directory, combined with a dependency list and a version number. You don't even need the specialized Debian tools to build them, although they make things easier. I'm kind of surprised you found it difficult, actually.

Re:almost useless

[Anonymous Coward]

We tested our graphical installer on Core. It works just fine. Now the application didn't on Windows Server 2008 but did on Windows Server 2008 r2 (it turns out event the server side components depend on System.Windows.Forms being there and will crash if they can't load structs from it).

Re:almost useless

[AmiMoJo]

There is a 100% chance that nearly every "Package-Install" command will just be downloading the app for you and launching the graphical installer you normally see.

Most of them download the MSI and do a silent install. There will still be UAC/admin password prompts, unless you disable them first. Many programs provide MSI installers already because they are very popular with organizations that want to deploy software over their network.

Re:almost useless

[Parker Lewis]

Yeap, I've already done some packages, and it's pretty plan: a compressed file with a file for description/depencencies and paths to install. I got more trouble when tried to create an installer for Windows, because I have to rely on install creators.

Re:almost useless

[Aqualung812]

Oh, so if it is only useful on most enterprise server installs, it must not be worth messing with, eh?

Have you considered the powershell itself is also "rare" if you looking at all windows installs?

Re:almost useless

[NatasRevol]

Well, PowerShell comes with the OS in Win8, W2k12, so a lot less rare than Core installs.

Re:almost useless

[Aqualung812]

So, now it isn't 100%, just something greater than 99%, eh?

I've worked in two enterprises that use core everywhere they can, so I see the value.
Since there is no credible source of how widespread any internal server OS is deployed, we can't actually talk stats. We can share personal notes, and mine is that two companies I've worked for with servers measured in the 1,000's would use this a lot.

Re:almost useless

[NatasRevol]

Guess you couldn't interpret 'can you round it up to 1%' as no you cant.

People in enterprise always forget how many people work outside of enterprise.
~Half the country works in a company of less than 500 people. And that the number of companies greater than 500 people is only about 0.5% of all companies out there. How many Core installs do you think are in the 99.5% of companies, made up of less than 500 people? Is it even non-zero?

http://www.census.gov/econ/sma...

And I never said it has no value, just that it's not a significant deterrent.

Re:almost useless

[ferventcoder]

The new version of chocolatey (executable, due out in q4 2014) knows how to do this with logging, language, silent options, and what can be passed to uninstall as well. You should take a look at the kickstarter we have going for Chocolatey.

Re:almost useless

[ferventcoder]

FPM is a pretty phenomenal tool for making packages across most platforms stupid simple.

Re:almost useless

[Anonymous Coward]

Hello, person who has never used Ninite.

Re:almost useless

[advantis]

This one? It sounds awesome just by reading the project description.

On other words ...

[lennier1]

sudo apt-get install malware

Re:On other words ...

[Anonymous Coward]

Yeah because they will let just anyone publish packages in repositories that are configured by default. This is not a problem with Linux package managers, why does everyone assume it will be a problem with Windows?

Re:On other words ...

[Svartalf]

Because it's been a problem up to this point...not the corporate repository- just about any twit could make an installer/injector that was transparently fire and forget for Windows. Because of the design, it's a bit harder with most Linux distributions whether you're talking about RPM, DEB, or any other packaging system. But, for windows, whether it was GUI or not, it's just simply there. If it wasn't, you wouldn't need AVG/Avast/Avira/etc. or MalwareBytes/etc.

As such, it's a joke. Not liking it? Get Microsoft to get their act together or switch OSes...

Re:On other words ...

[wed128]

History. the current Microsoft app store is a mess.

Re:On other words ...

[Barlo_Mung_42]

All app stores are a mess.

Re:On other words ...

[NatasRevol]

No, the viruses will have the installer point to their own repos. Probably named similarly. WindowsInstllServer for example

And that's all they need to do.

Re:On other words ...

[lennier1]

Yeah because they will let just anyone publish packages in repositories that are configured by default. This is not a problem with Linux package managers, why does everyone assume it will be a problem with Windows?

Like intentionally malicious USB drivers that will nuke the hardware people bought? All it needs is some crazy asshole with the keys to the castle.

Re:On other words ...

[Culture20]

iexplore.exe
FTFY

Re:On other words ...

[StormReaver]

sudo apt-get install malware

Being Microsoft, I can almost guarantee that this package manager has done almost everything wrong.

Clap clap clap

[DarkOx]

Real leadership here. Basically the Chocolatey folks did it for them and only after facing the threat of not controlling the dominate package manager on their own platform do they finally after decades offer a solution.

Basically what this tells me is they were trying to avoid competing with their App Store clone BS and are now having their hand forced. Way to go MS way to go.

Re:Clap clap clap

[Anonymous Coward]

The word is "dominant," idiot.

Re:Clap clap clap

[ferventcoder]

And if you look really closely you will see OneGet is a package manager aggregator that just uses Chocolatey as one of it's providers.

Chocolatey?

[K. S. Kyosuke]

As in, the guy from Sev Trek: Forager? ;-)

Alternative - Chocolatey

[vongillern]

The (fairly) popular Chocolatey NuGet windows package manager has a kickstarter going on right now to fund some dramatic improvements on an already awesome service. If you like having options, you really should consider backing it. https://www.kickstarter.com/pr...

Re:Alternative - Chocolatey

[ferventcoder]

And OneGet will use Chocolatey as one of its providers, so it's a win all over the place.

Is this the year of the Windows Desktop?

[rapiddescent]

we've been saying it for years and years but now that Microosft Windows has a package manager, is 2014 finally the year of the Windows desktop?

Re:Is this the year of the Windows Desktop?

[Anonymous Coward]

They are indeed catching up with some of the niceties of Linux world. Windows 8 introduced ISO mounting, Windows 10 introduced MKV support and package management. Then there is of course PowerShell, Git support in Visual Studio, and things like that. Lots of nice geek features.

Convergence of features is good

[gweihir]

The reason I expect this has been delayed for so long is that features like these will make windows administrators more at home on Unix and Linux. It does show (as other things do as well), that for professional work, Unix had it right all along. On the other hand, this convergence makes (hopefully) working on Windows less of a pain.

Of course I am talking about convergence with regard to work-flows, processes, etc. and not about actual concrete services being the same.

command line for Windows?

[Anonymous Coward]

I haven't used the MS-Dos command window since Windows 98 came out. I don't think I have even edited autoexec.bat and config.sys any more. Just saying.

Re:command line for Windows?

[Mr_Wisenheimer]

Windows NT does not use the DOS command line. It uses CMD and POWERSHELL. It also (until Windows 10) had an SUA UNIX subsystem that could implement shells such as BASH.

Windows ME was the last version of Windows to run using the Dos command interpreter. Starting with Windows XP, Command.com was removed from all 64 bit versions of Windows, so your computer probably does not even have a DOS command line.

Re:command line for Windows?

[Anonymous Coward]

Start > All Apps > Windows System > Windows PowerShell

Re:command line for Windows?

[Blaskowicz]

It's fine to ignore it but it can be used for a single purpose it, that is to run the ping command. Very useful.

Re:command line for Windows?

[devent]

It's still the same old DOS terminal. I mean, really, how hard can it be for Microsoft to develop something like Konsole or Yakuake?
Freely resizable window, freely choseable fonts and font sizes, fully supported copy and past, clickable URLs, etc.

Re:command line for Windows?

[Mr_Wisenheimer]

The CMD terminal has always supported customizable fonts and font-sizes. Copy and paste was not exactly power-user friendly, but it has also always been fully supported. The Powershell terminal (which can also run CMD) is fully resizable.

There are various reasons why Microsoft chose not to support these things from the beginning of Windows NT (primarily because NT was supposed to do away with DOS except for legacy applications and so did not implement a proper terminal shell), but even before 6.0 they started working toward a fully-implemented text shell as an integral part of windows, which was fully implemented with 6.0 (Vista and 2008).

Supposedly, Windows 10 is supposed to bring serious improvements to the terminal itself, which is probably one of the reasons that the Windows UNIX subsystem (which supports UNIX shells such as BASH) is being taken completely out of Windows 10 in favor of Powershell.

Back when NT ran almost exclusively on lower end hardware and Unix ran almost exclusively on higher end hardware, I do not think Microsoft saw much of an advantage in rewriting the NT kernel to fully support a text-console interface. Now that NT is running on higher-end hardware and *NIX (mostly Linux) is running on lower end hardware, they are seeing the advantages in having the same tools as their competition.

Re:command line for Windows?

[whereiswaldo]

Yes, a proper terminal and a proper shell are two huge strikes against Windows in my opinion. Adding a package manager is a nice step forward for them, though. Too little, too late for me, but will be handy in those situations when I must use Windows.

Re:command line for Windows?

[devent]

What is this Powershell terminal you speak of? If I google it, I find only

I'm not talking about the language itself, but the fact that to use Powershell I appear to have to use a single window that I can't set to the width of the screen, doesn't have tabs, has primitive cut and paste (seriously? No keyboard shortcuts and keyboard only highlighting line by line?). There's no history that can persist between sessions.

http://www.theregister.co.uk/2...

And some third party terminals like
https://code.google.com/p/cone...

Re:command line for Windows?

[Mr_Wisenheimer]

You should be able to resize the size of the window with the mouse. The output width and height is dynamically changeable in the settings.

If you want the other advanced features, you have to either use a third party program or wait for Windows 10, which adds some and perhaps all of them.

Simply put: O_o

[Svartalf]

Heh... How long did it take them to get to that? 20 *YEARS* (RHL 1.0 - November 1994) now?

Seriously Microsoft. Took you long enough.

Re:Simply put: O_o

[Kurrelgyre]

Damned when they do, damned if they don't, eh?

Re:Simply put: O_o

[war4peace]

Not as long as it (would) take Linux to offer a really good Desktop solution.

Re:Simply put: O_o

[Anonymous Coward]

Heh... How long did it take them to get to that? 20 *YEARS* (RHL 1.0 - November 1994) now?

Considering it took Linux about the same time to move to the equivalent of svchost & the registry with systemd, I wouldn't crow too hard.

Snarky, but I have felt over the bit that people who don't like Unix (poettering et al, sincerely aren't fans of Unix) have been pushing Linux closer to Microsoft/Sun/Apple choices while Microsoft is making Windows more Unix-y via powershell and additions like a package manager. It's a little surreal for someone who *is* a fan of Unix to watch competitors move closer towards its ideals while Linux is led away from them by Redhat.

Re:Simply put: O_o

[Khomar]

Not as long as it (would) take Linux to offer a really good Desktop solution.

Yeah, Microsoft made a really good desktop solution and then developed a really broken one. Take that, Linux!

Ballmer left 10 years too late

[Anonymous Coward]

Imagine if MS had done all this stuff a decade ago. Ballmer's tenure gave them an insurmountable hill to climb. The new guy has done more in a few months than MS did in a decade.

Re:if app store only then this will be next to use

[wed128]

RTFA...it doesn't look that way

call me crazy

[Anonymous Coward]

The power of these tools isn't installing stuff on a single computer, interactively. The power is installing things remotely, or in bulk.

Browse to 7zip.com, click download, click download, run, etc...

Or type "choco install 7zip"

Now... do that over multiple computers. Don't forget to "skip" the spam (No, I do not want Ask with my program).

This is the same reason Ninite is nice.

command line branding?

[pr0nbot]

Isn't putting branding in a command's name a bit of a hostage to fortune?

If this had come out 10 years ago, would we all be laughing at having to use get.NET / OLEget / ActiveGet / Get95 / etc ?

Those who don't understand UNIX

[Anonymous Coward]

are doomed to reinvent it, poorly.

Re:Those who don't understand UNIX

[Blaskowicz]

including UNIX

One of the ways Linux is ahead of Windows. . .

[Mr_Wisenheimer]

. . . is that a lot of its software is automatically managed. Windows updates is great (it generally works better than the Linux versions), but it only updates Microsoft components. Other installed programs are responsible for updating themselves, often installing hidden processes that boot at start-up for that purpose.

Linux package managers are nice because they manage a pretty wide-variety of software. Their biggest flaw is that you usually still have to update packages you install yourself manually.

If Windows goes with a central package manager for commercial programs as a standard, this would be a big improvement for everyone. Adding it to Windows Update would be useful to the general consumer.

Re:One of the ways Linux is ahead of Windows. . .

[war4peace]

For most well known Windows applications, I'm using Ninite for both automated batch install and automated batch update.

Royality for Open Source!

[Anonymous Coward]

Micro$oft should pay a royalty fee of 10$, to open source projects, on every copy of windows 10+ for including this idea in their software. It's pay back time Micro$oft!

almost useless

[Anonymous Coward]

For the record, I'm a huge Linux fan. Been using it for 10+ years both professionally and personally.

I currently work primarily in the Windows space. You have no idea what you are talking about. Like the guy below mentioned, server core has no GUI and is the default install for Windows server now.

Yes, Windows is late to the party, but the vision behind Jeffrey Snover and Powershell is pretty impressive. Now you get the best of both worlds...you can work on Windows and Linux and automate / scale everything. Well some of us can. Others will cling onto what little they know and spout nonsense.

And sshd?

[Culture20]

Sorry, but psexec-ing into SMB is not the same.
While I'm talking about sysinternals tools, maybe a 64 bit version of psinfo? Psinfo -s still only shows the 32 bit programs installed on a system, ignoring the 64 bit versions.

Re:wget prior to 1.16 Security Vuln !!

[Anonymous Coward]

Thankfully yum and apt don't recursively grab directories from ftp.

Systemd is meeting them halfway

[Anonymous Coward]

Luckily for Windows, systemd is moving Unix towards the windows quagmire method of doing things.

Praise Jesus

[LordThyGod]

Its a little less a piece of shit now. Still some unpleasant odors here and there. I have no doubt God really is on our side, but nice to see some goddamn proof every now and then.

windows is finally growing up.

[Murdoch5]

Big deal Linux has had this for a long time.

Re:wget prior to 1.16 Security Vuln !!

[Anonymous Coward]

RPM and DEB packages can still include an installation script that may run arbitrary commands as root.

can we have....

[Anonymous Coward]

package remove IE

Nah, that wouldn't let us remove this steaming pile of pig shite.

Re:can we have....

[VGPowerlord]

package remove IE

Nah, that wouldn't let us remove this steaming pile of pig shite.

Part of that IE is just an application built on top of the mshtml.dll rendering engine. This rendering engine is an embedded control for other applications and is also used by vendors other than Microsoft (such as Symantec).

Some vendors (such as Valve) have realized that's a fucking terrible idea and switched over to embedding other browsers (Chrome Embedded Framework in the case of Steam).

So, when you say "remove IE" do you mean just remove the executable or do you remove the DLL, breaking any applications that rely on it?

Incidentally, the embedded control is also why you should keep the version of IE up to date on Windows even if you don't use IE.

Chocolatey

[rl117]

My experience of chocolatey was not good. Fine to install software, but it's just a wrapper around existing installers. Try to upgrade a package... fail. Try to remove a package... fail. This depends upon the package in question; it works for some, others you have to clean up by hand, worse that having downloaded and installed using the installer by hand.

And no proper support for libraries, dependencies etc. so useless for software development. It certainly meets a need for software deployment, but it's so lacking compared with what dpkg/apt-get provide that it's a joke.

If Windows is to gain a proper package manager, I think they need to do it properly. The existing support is just broken.

Re:Chocolatey

[ferventcoder]

I agree with you, so much that we are doing a kickstarter that supports us making improvements that fix all of this. I invite you to check out what we've done so far (fixed the upgrade/uninstall) with the new chocolatey (a totally rewritten client that is due out in Q4 2014). We've even implemented package moderation to increase the quality of packages on the community feed - https://www.kickstarter.com/pr...

Re:Chocolatey

[rl117]

Great, thanks for letting us know! I'll take a look once it's out.

Chocolatey is making improvements to meet needs

[ferventcoder]

So OneGet is a package manager aggregator. One of the providers is Chocolatey, which is attempting to make improvements to become a true package manager (wrt to cleaning up everything when uninstalled no matter where crap ends up, pinning, and a couple of other things it still doesn't do, everything else is covered) - we have a kickstarter going now to make those improvements a reality, which in turn will make OneGet that much better. https://www.kickstarter.com/pr...

I'm really glad for this. One more thing though...

[Anonymous Coward]

For a long time, I wasn't aware of any easy way to automate downloading files. I could automate by writing batch files thanks to my old DOS skills, but the best command line program for that was FTP. FTP did support input from a file, but didn't necessarily handle firewalls well. I could run the web browser (IExplore.exe) to point to a file, but then the user was prompted, so that wasn't automated. That was in the 1990s.

More recently, I took a look at this again and found that I could use VBScript to use an HTTP object, and could automatically download files with HTTP. But, since Windows Script Host is not being developed (Microsoft has known bugs that'll freeze a program and won't fix them), that's not a solution I have been feeling real comfortable with.

If this thing supports some decent security, permitting downloading of remote files, this could resolve one of the must-gets that I always want before I really feel that a Windows machine is decently customized for me to be a bit comfortable with it.

Now, the other really-super-cool thing that would be useful is a way to remotely control command lines. A built-in SSH terminal would allow me to interoperate even more, so I can control precious machines on the other side of the Internet. PuTTY is PuTTY's License is like BSD / MIT / similar, so Microsoft could include that just as well as they included Telnet.exe way back in the day. Obviously, Telnet.exe is worthless (because of the biggest problem which is security, and nobody liked it anyway because it didn't handle screen-cursor control codes suitably). If Microsoft can just add that feature next, it will eliminate much of the must-have downloading that I frequently feel a need to start doing whenever I start heavily using a new machine.

Inferior security design

[fquestie]

This package manager comes 18 years after Linux package managers, and still it has an inferior security design.

The Chocolatey repository and format basically promote the download and execution of installers. Even the Chocolatey packages of FLOSS software like Firefox, VLC and Filezilla are downloading and executing (with administrator privileges) installers. They are not, like I would expect it for security reasons, unpacking compressed file archives, which are also available for such FLOSS programs.

The popularity of secure package managers are one of the many reasons why viruses have a hard time spreading broadly on Linux. Yes, Linux package managers are of course also running with root privileges, but they are mainly unpacking the package archive, thus avoiding to execute as root any installer from the upstream program. Any virus payload in user programs would only be executed by low-privileged users. As on a typical Linux system almost all executables are non-writable for low-privileged users, a virus executed by such user will be unable to spread into other programs on the system.

Also I didn't find checksums or signatures in the Chocolatey packages. Thus, also inferior protection against download errors and man in the middle attacks...

Re:Inferior security design

[Anonymous Coward]

The most common Linux package formats contain pre/post install scripts (this includes Debian and Redhat) which are run are root. So, no sorry.

Re:Inferior security design

[fquestie]

The most common Linux package formats contain pre/post install scripts (this includes Debian and Redhat) which are run are root. So, no sorry.

Abuse of the Debian and Redhat packages pre/post install scripts as virus vectors would require a security breach at the Debian/Redhat package maintainer or repository.

Chocolatey packages could spread viruses in many more cases: these packages are most often pointers to installers at websites. The package maintainer hopefully checks the security of the upstream installer at the moment of packaging. But none of the Chocolatey packages I inspected use a mechanism, such as checksums or signatures, to detect upstream changes. Such setup allows many more man in the middle attack scenarios. And finally such infected installer will get executed with administrator privileges.
Note: all Chocolatey packages of my small sample were following this unsafe model, but in theory they can be safer: they could prefer to download compressed archives instead of installers, and they could check the checksum of downloads.

Seems busted to me.

[synapse7]

Anybody get this to work? I was looking at a screen like the screenshot on extremetech.com and it said xFirefox(whatever that is) was installed, but if I look for firefox it is nowhere to be found.

lol why

[Anonymous Coward]

I can just use my mouse and index finger for everything, thank you.

Credit where credit's due

[blandthrax]

How-To Geek reported on this first:

http://www.howtogeek.com/20033...

From the ET article: "OneGet was originally rolled out as part of the Windows Management Framework 5.0 preview for Windows 8.1, and it’s being actively worked on to try and ship it as a standard tool in Windows 10. As far as we’re aware, it will only be available through PowerShell — a command-line utility that’s mostly used by power users and IT admins. If you don’t know your way around PowerShell (and indeed, it’s a much more complex beast than cmd or most Linux shells), you can still theoretically use OneGet through the standard cmd command line with @PowerShell. HowToGeek has some more details on OneGet and its implementation in Windows 10, if you’re interested." (emphasis mine)

I get humor out of this

[rikkards]

"It's a missing feature Linux advocates have long used to argue against Windows in terms of automation and scale."

As head of our distribution department with 100,000 Windows machines under us I find that slightly inaccurate.

UnxUtils

[OutOnARock]

I use UnxUtils .... gives me all the GNU userland I want, no alternate shells needed

http://unxutils.sourceforge.ne...

Add the install directory to the Windows path and there you go!

Re:Windows 10 should just be a distro based off Li

[Anonymous Coward]

Why?

Code name: "Palmala Handerson"

[Zymergy]

Tell me this is not the Perfect name for the new package manager: "Palmala Handerson"...

Well, shoot

[vandamme]

Why don't they just release their own Linux distro.

Very strange: I had the opposite experience.

[Anonymous Coward]

I saw the exact opposite experience: With windows, each game I installed overwrote DLLs needed by other games. It was a nightmare. Often the graphics DLLs were downgraded. Getting anything to work was impossible. You had to pick the game you were going to play on that computer and stick to it.

With Linux, I can happily put 10 versions of the same library on the system concurrently. I can use ldd to see what libraries an existing executable needs. Oftentimes the newer shared libraries were a drop-in replacement, a superset of the old libraries. But when they weren't, it was trivial to set up a shell script using LD_LIBRARY_PATH & exec. And to snag older libraries off the repos and use rpm2cpio | cpio to install them wherever I liked.

This is all like trivial stuff. Barely noticeable. Negligible time hit.

Just to give you an idea how little DLL-hell hits Linux: I've had old linux systems die of hardware failure. I just dd'ed the drive image over to another box, booted off fedora in rescue mode, chroot'ed to the drive image, and BAM! Everything works again. Right down to the very outdated mysql database fired up via /etc/init.d.