Microsoft Aims to Bring apt/rpm-like Tools to Windows

[anyweb]

Now this is interesting. Microsoft developer Garrett Serack has acknowledged that it is generally easier to roll out a, for instance, complex stack of open source server software on Linux than it is on Windows. He also offers a solution - he's working on a project to bring package management to Windows. This project will be community-driven, and Serack has the full blessing from Microsoft.

 

via osnews.com

[Dungeon-Dave]

Interesting article.

 

Firstly, I'm not convinced he's fully understood the open-source/apt concepts there (I get the impression from his text that "open source" means "I compile it myself").

 

Package managers like DPKG and RPM work in a specific manner: they check a (machine-centralised) database that dependencies are satisfied, extract compiled files into a specific location, then update the database(s) accordingly. This is similar to the add/remove programs + registry concept of Windows, with minor exceptions: MSI packages sometimes offer the user the option to customise some settings where RPM/DPKG do not. I'm not convinced that all MSI packages follow strict protocol:

- some prefer to follow bad behaviour of installing pre-requisite software, rather than check the registry for necessary dependencies, resulting in library duplication (referred to as DLL hell) or version forks,

- many don't completely remove themselves during the uninstall, leaving orphaned records in the registry, broken shortcuts, obsolete directories, etc.

 

Secondly, he's right to identify particular challenges that exist in the Windows world. For the centralised database - such as the registry - to work effectively, there needs to be communication and consistency between vendors, and more stringent control over standards within Windows - such as removing many user-customisable options. This means that Firefox and Mozilla know exactly where Java is installed under Windows, because Sun/Oracle have agreed and documented how/where it is done, and exposed this information in the consistent manner that aids vendors dependent upon a particular version of Java. This means that there needs to be more tools available to interrogate and manipulate the registry - a simple error message of "This may impact on the registry" isn't enough: where will it impact? How will it impact?

 

Thirdly, APT and YUM are front-ends to the DPKG/RPM systems, that solve the dependency hell scenarios of old. They rely upon centralised repos of vendor-supplied packages, all with pre-requisite information properly version-controlled and tightly verified, reducing variance and possibility for error. For the end-user of a Linux distro, they can install a package, knowing files will be put standard locations. They can run a command like YUM or APT-GET, knowing it will download the package appropriate to their OS distro AND version, downloading and installing pre-requisite information. And those package management tools don't just provide detailed information about the software installed on their machines: they can also be used to interrogate repos for lists of available software; many graphical package managers provide this functionality, offering the change to try out new applications based upon their description.

 

For this last part to work properly, Windows needs an overhaul of the way they present/conceal information. Many Microsoft fanbois nurture their belief that software installation under Windows is much easier than Linux: download the .MSI, double-click to install, and it appears in Add/Remove programs with suitable shortcuts found in their quicklaunch/desktop/start menu. Far easier than downloading raw source, compiling manually - using commands, of all horrors - then wondering why no shortcuts appear. Unfortunately the Microsoft mindset still remains that Windows is aimed at novice users, and that more detailed technical information will only frighten them - meaning that to try to obtain information about software is unnecessarily difficult in Windows. Yes, I can see from Add/Remove Programs what is installed... now, tell me WHEN it was installed. How about the directory location where each package is installed to, or what files it added to your system when it was installed? Here's a file I've picked at random... what package does this belong to?

 

It's ironic that systems like APT/DPKG and YUM/RPM - designed for techies and geeks - have made life easier for novices. They work pretty well, due to the concerted community effort. Yet that designed with the novice in mind (.msi) ultimately end up making things harder for everyone around, to the point that Garrett suggests a rethink should be considered.

 

So, should I sneer at Windows because it's - once again - stealing an idea from the Linux community? No. At fundamental level, DPKG/RPM were derived from the Windows camp, because it is a set of integrated processes that worked better than the arduous manual-compile cycle. Garrett has simply spotted that there is a better way of doing things, and his proposal can only make life easier all around. I think he's to be commended and supported. I hope he's successful in his endeavour.

[anyweb]

great reply, but i really hope this suceeds, i just love the ease (in general) of installing software in linux,

 

yum install some_package

 

that's just so nice, i really hope it makes it to Windows

[Dungeon-Dave]

I like the fact that the package managers expose the software contents (when it was installed, where to, what package does this file belong to etc) and front-ends (apt, aptitude, yum etc) can query online repos for packages directly from the command line.

 

I find it MUCH easier to redirect the output of commands into text files for an email than try to take a screen grab of something graphical. Text files also allow comparisons at different times for version control and diagnostic analysis.