Comments for Garrett Serack: Open Source Development at Microsofthttps://blogs.msdn.microsoft.com/garretts
View from deep inside Microsoft's Open Source Software LabTue, 05 May 2015 13:38:14 +0000hourly1Comment on 10 things about OneGet that are completely different than you think. by Garrett Serack, MSFThttps://blogs.msdn.microsoft.com/garretts/2015/05/05/10-things-about-oneget-that-are-completely-different-than-you-think/#comment-1714
Tue, 05 May 2015 13:38:14 +0000https://blogs.msdn.microsoft.com/garretts/2015/05/05/10-things-about-oneget-that-are-completely-different-than-you-think/#comment-1714@Rory,

As we proceed, that's exactly the kind of thing that we'd like to implement. At the very least, we're going to work with the community to set standards for how a provider should behave, and then we (as a community) can review and decide what providers are validated.

Further to that, we'd actually like to make the whole notion of trust "pluggable". Some companies may require that software in their own enterprise be on an approved list, or signed by some key, or some other criteria. Rather than forcing a one-solution-for-everyone approach, the providers can be hooked into this notion of trust verification, and we can offer far greater flexibility than that.

I'm actually looking to squeeze in smartscreen filtering as soon as I can to provide at least an initial vet of the files coming into the system.

]]>Comment on 10 things about OneGet that are completely different than you think. by Rory McCunehttps://blogs.msdn.microsoft.com/garretts/2015/05/05/10-things-about-oneget-that-are-completely-different-than-you-think/#comment-1704
Tue, 05 May 2015 13:26:02 +0000https://blogs.msdn.microsoft.com/garretts/2015/05/05/10-things-about-oneget-that-are-completely-different-than-you-think/#comment-1704Interesting and good clarification on what you're doing with OneGet/PackageManagement. A challenge I can see with your approach is that people might think that an "MS Approved" solution addresses the big issue of "can I trust software downloaded via this mechanism".

Now from what you've said here I guess the answer is that you're delegating that to the repository providers and letting users make their own decisions on trusting those providers.

That's kind of a shame (to me) as there was an opportunity here for MS to create a system that allowed for "apt-get" style installation of packages with a known provenance. Instead we're left making decisions about community supported repositories who, unfortunately, don't have the kind of resources necessary to thoroughly vet software in the repository.

To use Chocolatey as an example, I recently used it to install windirstat, and noticed that it's just downloading the file over an unencrypted HTTP connection from sourceforge. No package signing, no HTTPS connection….

]]>Comment on 10 things about OneGet that are completely different than you think. by Garrett Serack, MSFThttps://blogs.msdn.microsoft.com/garretts/2015/05/05/10-things-about-oneget-that-are-completely-different-than-you-think/#comment-1694
Tue, 05 May 2015 13:12:40 +0000https://blogs.msdn.microsoft.com/garretts/2015/05/05/10-things-about-oneget-that-are-completely-different-than-you-think/#comment-1694@eosfor,

In the ARP table, there are more than just MSI installations, so, yes absolutely, we need the Programs provider, it's there to provide inventory of all the items in Add/Remove programs.

Now, slightly more pointed question would be, given that there is an out-of-box 3rd party MSI PowerShell module, why do we need a MSI provider for OneGet?

Well, a couple of reasons; first, the MSI PowerShell module isn't included in Windows. Second, for all of it's power, it's doesn't work as the plugin to OneGet itself, which means that the common commands wouldn't be there for MSI files.

Really tho', both the MSI powershell module and the OneGet MSI provider use the same underlying DTF libraries to implement their functionality, with the MSI PowerShell module having a much richer interface.

]]>Comment on 10 things about OneGet that are completely different than you think. by eosforhttps://blogs.msdn.microsoft.com/garretts/2015/05/05/10-things-about-oneget-that-are-completely-different-than-you-think/#comment-1684
Tue, 05 May 2015 11:53:52 +0000https://blogs.msdn.microsoft.com/garretts/2015/05/05/10-things-about-oneget-that-are-completely-different-than-you-think/#comment-1684Msi PowerShell module has an option to uninstall software. Do you really need to implement Program provider?
]]>Comment on 10 things about OneGet that are completely different than you think. by Garrett Serack, MSFThttps://blogs.msdn.microsoft.com/garretts/2015/05/05/10-things-about-oneget-that-are-completely-different-than-you-think/#comment-1674
Tue, 05 May 2015 11:31:30 +0000https://blogs.msdn.microsoft.com/garretts/2015/05/05/10-things-about-oneget-that-are-completely-different-than-you-think/#comment-1674@Peter,

Yes, it's named "PackageManagement" a subtle difference from "PackageManager" to be sure, but a difference none-the-less.

And yes, if you're happy using the existing package management commands, by all means, continue to use them, and completely ignore this.

However, there are users that aren't aware of how to use them (or in some ways, even get one of them onto their system). And, as we get more and more providers involved, it offers some consistency for users to use the same commands, regardless of where or how their software is installed. At some point in the future, it'll be nice to be able to say "update-package *" and have it do that for all the software you have installed, regardless how it got there.

And that being said, there are a number of providers being implemented that don't currently have a standalone version, and their first incarnation is as a OneGet provider.

]]>Comment on 10 things about OneGet that are completely different than you think. by Peterhttps://blogs.msdn.microsoft.com/garretts/2015/05/05/10-things-about-oneget-that-are-completely-different-than-you-think/#comment-1664
Tue, 05 May 2015 11:21:22 +0000https://blogs.msdn.microsoft.com/garretts/2015/05/05/10-things-about-oneget-that-are-completely-different-than-you-think/#comment-1664So… let me get this straight. In point #1 you're saying it's not a package manager and in point #10 you're saying it's going to be renamed to package management?!

Honestly, after reading this article I'm left with "so, what's the point of this thing?" It seems like the lowest common denominator between various installers (can't really call any of them a package manager). If I want to install Node and Python modules, then why wouldn't I use their respective package managers and get all their features rather than a subset?

I wrote a OneGet tutorial for normal Windows 10 users, have just finished updating it. I would appreciate a fact check, if the tut and the video in it contain any factual errors. I know you are a busy geek nowadays but trying to translate Geek lingo to English is a bit risky making me a somewhat worried if I got the facts right. The tut: http://www.tenforums.com/…/2742-powershell-oneget-install-apps-command-line.html

]]>Comment on OneGet (it’s in the Windows 10 Preview!) by Xuminhttps://blogs.msdn.microsoft.com/garretts/2015/01/27/oneget-its-in-the-windows-10-preview/#comment-1653
Tue, 27 Jan 2015 13:45:25 +0000https://blogs.msdn.microsoft.com/garretts/2015/01/27/oneget-its-in-the-windows-10-preview/#comment-1653Very useful tip on how to discover hidden providers.
]]>Comment on CoApp FAQ: A few important distinctions. by rogerdpackhttps://blogs.msdn.microsoft.com/garretts/2010/07/29/coapp-faq-a-few-important-distinctions/#comment-1613
Fri, 06 Aug 2010 11:29:03 +0000https://blogs.msdn.microsoft.com/garretts/2010/07/29/coapp-faq-a-few-important-distinctions/#comment-1613suggestion: also support mingw as well as MSVC. Why not, right?
]]>Comment on What’s this ‘CoApp’ all about? by Vivienhttps://blogs.msdn.microsoft.com/garretts/2010/04/07/whats-this-coapp-all-about/#comment-1603
Tue, 13 Apr 2010 07:19:32 +0000https://blogs.msdn.microsoft.com/garretts/2010/04/07/whats-this-coapp-all-about/#comment-1603I maintain an application which I cross compile on Linux for Windows. The reason I don’t generate MSI or others is that they don’t work fine in a cross compiling environment.

Do you plan to make the software being able to work on Linux in a cross compiling environment?