Introducing PackageManagement in Windows 10

SEARCH is the reason package management is so broken. If a developer intends a particular piece of software to be installed as a dependency, he should convey that to the users, rather than a vague criteria for which the user might hopefully get the right thing. The search needs to return only one result - the right one. If several package managers keep a package of the same name and version, we shouldn't need to keep adding criteria to narrow down our search until we get the right one (and someone could later add a package which meets all those criteria after you've published).

The heart of the problem is making a SEARCH which will always return one result, and to do this we either need to add N criteria which are collectively guaranteed to be unique - or to just stick a unique identifier there to begin with and treat the rest as information queryable from the content.

The use of a hash as an identifier solves several other problems such as having multiple repositories whereby each one could host packages of the same name and such. While we continue to rely on search without some means of uniquely identifying packages, we continue to have the social burden of making sure our repositories don't conflict with other peoples (usually the "official distro" repo - but when we're talking of unifying packages, that's a lot of repositories which could conflict. Unless we add our "vendor" flag into the mix, etc)

How do they handle security updates? Does every app have to update all its own libraries in an e.g. heartbleed scenario?

I'm not sure that anybody is advocating taking that route as the way forward...

That's all fine and well but the thing is -

Is it possible to unify package management un-intrusively or not? Call the un-intrusive path A nd the intrusive path B.

A) If we were to to it in such a way that did not require us to modify all the existing package managers out there then how do we do that? I think the solutions (a database of unique hashes and so on) you are coming up with might be a way forward. But don't we still have the problem of communicating with the underlying package managers?

B) What sort of intrusion? Would package managers have to adhere to some kind of standard or API or expose a minimum amount of surface area? How would you get package manager maintainers to sign up to something like that? A summit? Who would fund such a summit? Then we'd still need something to implement that API. Somebody elsewhere mentioned PackageKit, would this fit the bill? If not, is there something else that would? And would we still need to track installs and so on with something like what you're proposing.

Remember this would ideally would on Debian-like (.deb apt-get) and RPM-like (.rpm yum) and Gentoo (.pkg emerge) and so on and so forth ad nauseum ... I mean, I'm running Ubuntu so after the Great Request for the Unification of Managing Packages Summit (GRUMPS) I want to still be using Synaptic but I want to be able drill down into sub-package managers. See what I mean?

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

Both correct and horribly wrong.

PowerShell is indeed focused on cmdlets (and functions) and it's pipeline concept is focused on objects. It is also correct that cmdlets are not arbitrary programs.

However, cmdlets are not .NET classes. It is true that you can implement a cmdlet through a .NET class that derives from the base Cmdlet class. But that is just one way to create a cmdlet that can be recognized by PowerShell. You can build cmdlets using PowerShell itself. There is nothing in the PowerShell specification (http://www.microsoft.com/en-us/download/confirmation.aspx?id...) that require a cmdlet to be a .NET class.

If you use PowerShells (rich) introspection function to enquire about a cmdlet, there is nothing objective to give it away as either .NET class based or advanced function based (advanced functions are cmdlets). Yes, you can see if a module (distribution unit of cmdlets, providers, functions etc) are "binary" or "script". That merely reinforces the argument that cmdlets are not classes.

Indeed, PowerShell will now dynamically create a new type of cmdlets based on an Open Management Infrastructure (OMI) implementation. Think managed routers, switches, Linux boxes etc. If they expose a REST service that complies with OMI, PowerShell can query the capabilities and create cmdlets in-session for each individual type of equipment. PowerShell has since v3 been able to create WMI/CIM cmdlets.

The point is that your assertion that cmdlets are .NET classes is both factually wrong, and grossly misleading. Saying that PowerShell cmdlets are .NET classes is like saying that Yum packages are just archives. Sure, you can pick one apart and say "look! it's a .NET class". I can pick a Yum package apart and say: "look! it's just an archive with some files in it!".

That said, it is true that PowerShell builds upon .NET. It is implemented using .NET and the object model is based on .NET. PowerShell's type system is a superset of .NETs - because an administrators tool needs more ad-hoc typing.

We have gotten so used to think that sh shells were developed with pipelines like that (streams stdin/stdout) because the commands are like that. In reality, the commands and the (first) shells were developed in tandem so that the commands would fit the shell and vice versa.

What Microsoft is doing with PowerShell is challenge that commands must be "like that". If we make the commands "richer" and allow them to use a higher level protocol (objects) for inter-command communication, an even smarter shell can be built. Yes, it does create some friction with traditional commands. PowerShells solution is to regard those as "cmdlets" that just consume sequences of strings (which are objects) and produce sequences of strings.

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

PowerShell is focused on tying together separate cmdlets and only has a very minimal set of build-on commands. See?

(Aside: Actually, PowerShell is more terse than any sh shells: It has 0 (zero) "built-in" commands. What it is has is a module concept with auto-discovery. The seemingly "built-in" are not built in. Those cmdlets comes from modules that are distributed alongside the PowerShell binary, and PowerShell auto-loads them as it will any module that is placed in the correct location. sh shells needs commands like e.g. "cd" that manipulate the environment to be built-in. You could never implement "cd" as an external command. In PowerShell "cd" (alias for the Set-Location cmdlet) is distributed through the Microsoft.PowerShell.Management module)

> The focus of each one is very different, despite PowerShell's syntax. Piping objects between cmdlets in PowerShell is analogous to working with objects in Python, Ruby, Perl, etc, not like Unix pipes.

No it is not. A pipeline is exactly that: A temporary communications channel that is set up for the duration of the (compound) command, and through which multiple objects flow. In PowerShell the individual cmdlets - like commands in a sh pipeline - are active a the same time. From the PowerShell spec: "A pipeline is a series of one or more commands each separated by the pipe operator | (U+007C). Each command receives input from its predecessor and writes output to its successor."

Re: Python, Ruby, Perl, etc: You can create a pipeline concept for those languages as well. See for instance pypi (https://code.google.com/p/python-pipelines/). But it is like you want to portrait PowerShell pipelines as mere method invocations. They are considerably more.