Comment Re:In other words (Score 5, Insightful) 124
Some notes:
https://github.com/microsoft/w...
It's basically a Wayland implementation that is exported via RDP protocol.
Some notes:
https://github.com/microsoft/w...
It's basically a Wayland implementation that is exported via RDP protocol.
Better get used to it.
It's still a long slide to the bottom.
'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
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...
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.
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.
[FYI -- I'm @FearTheCowboy everywhere else, my
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.
âoeMr. Burns, Your Campaign Seems To Have the Momentum of a Runaway Freight Train. Why Are You So Popular?â
I do have one question. Why, exactly, do you think that this sort of approach is likely to be easier than doing what Apple did and simply exposing a Posix API that is actually useful?
Because, even if we could get a great POSIX experience on Windows, it leaves out Windows developers.
One of my goals is to get Windows developers in the OSS game.
On top of that, there is a hell of a lot of non-POSIX open source software on Windows that needs fixing too.
Look at it this way: Would you respect someone who told you the best way to get FireFox running on Linux was to use some sort of Windows emulation layer... Like WINE? no, because FireFox *can* compile for Linux. Same thing with nearly all Open Source I encounter. I want to get the OSS quality and experience on Windows to exceed commercial developers... it needs the most love.
Like I tell people:
Working as an open source software developer at Microsoft is like being a preacher in Vegas. I figure I'm in the single most important place in the universe that I can be.
That's the trouble with the six digit generation. Too Lazy.
Us 5-digit generation look down at you with disdain.
Now, get off my lawn!
It's 2010 and you are still doing *that*.
*sigh*
You know, that'd be funny if it was so damn sad.
think you had no choice to choose the BSD license instead of the GPL. Had you chosen GPL, it is likely the project would have been immediately rejected by Microsoft.
That's not true actually.
I didn't tell anyone what license I was going to use until a few days ago, by which time they'd already signed the agreement.
In addition to that; as a Microsoft employee for Microsoft, I've contributed code to GPL, LGPL, BSD, PHP and Apache licensed projects.
I'm busted.
I dunno man, I wrote that blog post a really long time ago, and then got stuck in red-tape. It's possible I never even proof-read it.
*sigh*
Old programmers never die, they just hit account block limit.