We continue our countdown of the 10 make-or-break features that will determine the success or failure of Microsoft Windows 10 in the enterprise, with a look at how administrators will be able to install applications throughout organizations in a manner that’s more like Linux distributions.
The first question you may be asking is, “Success or failure — isn’t Windows 10 going to be free?”
No, not really. Microsoft is giving away Windows 10 Home and Windows 10 Pro as free upgrades to consumers who have corresponding licensed versions of Windows 7 and 8.1 already installed.
Note: not Vista, not XP and not 8.0. Yes, we hop over one step.
But enterprise licensees are involved in Software Assurance programs which may entitle them to Windows 10 upgrades, as something they’ve already paid for.
Repackaging the Packages
Second on your list of questions (my, you’re just full of questions today): Why is being more like Linux better? It’s an architectural issue which, on the surface, has to do with ease of maintenance.
Underneath the surface, it’s one of the many sticking points that stalled the advance of Windows Server some years ago, and enabled Linux to take full command of the back office.
That changing of the guard led to a drying up of the Windows desktop application market.
Quick: Besides Microsoft Office, Adobe Creative Suite, and Microsoft Visual Studio, name a desktop productivity application you’ve had installed in the last five years. No, those apps you run in your browser don’t count.
In the world of virtualization, master images are rarely snapshots of clean operating system builds without any applications installed.
Clean builds of Windows are easy enough to generate using Setup. No, a master image or “golden image” also contains the applications in their pristine, just-installed, never-before-used state.
Maintaining these golden images is one of the perennial headaches among administrators. For server-side software, most of which now is run in Linux, Red Hat Package Manager (RPM) blazed new trails back in 1995, by automating the process of keeping the latest builds for applications in a common repository.
From there, applications are downloaded as packages that are then compiled, distributed and as necessary, updated.
It’s a dramatic simplification for a process that should, at least on paper, be far more complex than distributing Windows applications.
Back in the Vista timeframe, Microsoft responded by producing what it called a “Package Manager.” Uh-huh. In 2010, Microsoft followed up by producing what it called a “Package Manager” for .NET applications, specifically for developers. With the open-sourcing of .NET and a change in Microsoft’s culture, this device has since been “spun-off” as a non-branded repository called NuGet.
Then with Windows 8, Microsoft took another step forward by producing what it called a “Package Manager” for those Metro/Modern/whatzit classes of apps (WinRT is the technical name) that several dozen people actually installed. You sense a sort of theme here.
With Windows 10, Microsoft plans to produce what it calls a “Package Manager.” To shorten things somewhat, it will be called OneGet. This is not just a case of “the fourth time’s the charm.”
Microsoft’s plan this time is to create a sort of “automation overlord” that binds together all the previous package managers, including NuGet, into one set of command-line tools (called “command-lets,” but spelled cmdlets) that plug into the Windows admin’s tool of choice, PowerShell.
This overlord will be called “OneGet,” and although it will need individual plug-ins (like drivers, in a way) for each type-specific package manager it oversees, it ensures that admins will handle all types of applications exactly the same way.
NuGet, its supporting tools (one of which is called “Chocolatey”... get it?) and other package managers each have their own repositories for maintaining rapid availability to the latest code.
This is somewhat unlike the Linux world, where repositories have become more centralized. Still, with these plug-ins, OneGet should be able to manage these diverse repositories as if they were just one.
“Think of this [OneGet] as a preview of the thing that is going to allow you to deploy Word, or... Flash or Adobe Reader, or whatever,” said technology author Mark Minasi, during a session at last month’s Ignite 2015 conference in Chicago. “This is the first step towards making your life easier.”
What was really important about Minasi’s comment was the ellipsis. It has actually been a while since a new Windows-based application mattered.
Office 365 is an important service, and SharePoint is breaking new ground in the data-sharing department. But these are server-based applications whose advancements are all happening on the server side, not the client side.
If it’s going to mean something for enterprises to have desktop applications again, admins and DevOps professionals must want to manage them again. Environments such as VMware have changed the way they approach this problem, from maintaining the euphemistic “application lifecycle management” to deploying a concept called “App Volumes” that adds a second layer of abstraction between the operating system and the applications it thinks it manages.
Every time VMware successfully wedges another layer of abstraction into the mix, it gives itself one more system that IT departments will pay it money to be able to control.
If an operating system is to become meaningful again in people’s lives and work, it has to stop allowing itself to be separated from the user every time a layer of abstraction removes it one more step from the processor.
The OneGet project holds out the promise (albeit an unfulfilled one just yet) that the operating system will become a welcome proving ground for real programs once again — that the client can do more than just run a Web browser.
One thing you can be assured of: If the world of applications retreats behind the browser permanently, it will be completely out of the IT department’s control forever, and therefore, out of the customer’s control as well.