Windows 10 Gets a Package Manager For the Command Line
aojensen writes: ExtremeTech reports that the most recent build of Windows 10 Technical Preview shows that Windows is finally getting a package manager. The package manager is built for the PowerShell command line based on OneGet. OneGet is a command line utility for PowerShell very similar to classic Linux utilities such as apt-get and yum, which enable administrators and power users comfortable with the command line to install software packages without the need for a graphical installer. ExtremeTech emphasizes that "you can open up PowerShell and use OneGet to install thousands of applications with commands such as Find-Package VLC and Install-Package Firefox." It's a missing feature Linux advocates have long used to argue against Windows in terms of automation and scale. The package manage is open to any software repository and is based on the Chocolatey format for defining package repositories."
LOL, no it won't. Whatever MS copies is always so badly reimplemented that there's no way they could achieve POSIX compliance.
. . . is that a lot of its software is automatically managed. Windows updates is great (it generally works better than the Linux versions), but it only updates Microsoft components. Other installed programs are responsible for updating themselves, often installing hidden processes that boot at start-up for that purpose.
Linux package managers are nice because they manage a pretty wide-variety of software. Their biggest flaw is that you usually still have to update packages you install yourself manually.
If Windows goes with a central package manager for commercial programs as a standard, this would be a big improvement for everyone. Adding it to Windows Update would be useful to the general consumer.
Not as long as it (would) take Linux to offer a really good Desktop solution.
...gis sdrawkcab (usually not responding to ACs; don't bother posting as AC)
In Linux, I've had all kinds of dependency hell.
Yes, Linux never solved dependency hell, it has been swept under the rug that is distro+version specific repositories. The problem is still very, very real, but if you constrain yourself to the repositories of the distro + version that you use, the package maintainers will have ensured that the package dependencies do not conflict with each other and with the version of the ABI that your distro+version is on.
DLL hell was *very* real in the Windows 9x days. Side-by-side assemblies was introduced with Windows 98SE (IIRC) - but really only became de rigueur with Windows XP. During the 9x days, software developers took advantage of the fact that nothing prevented them from writing files to the system directories. When they encountered a problem where they needed a DLL - they simply installed it in the system directory - often overwriting whatever was there before. Obviously this caused all sorts of problems where only the latest installed product had a robust state.
Reading slashdot one-liner: (irm http://rss.slashdot.org/Slashdot/slashdot).rdf.item | fl title,desc*