Slashdot Mirror

← Back to Stories (view on slashdot.org)

Windows 10 Gets a Package Manager For the Command Line

Posted by Soulskill on from the baby-steps dept.

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."

39 of 230 comments (clear)

  1. We can do that thing you like by Anonymous Coward · · Score: 5, Insightful

    Everything except open-sourcing the code that is.

    1. Re:We can do that thing you like by khasim · · Score: 4, Insightful

      Installing via the command line is nice. But it isn't what I want.

      I want a package system that locks the files down so that package X owns abc.dll and will not allow package Y to overwrite it.

      And searchable. What package installed abc.dll? What packages depend upon that package?

    2. Re:We can do that thing you like by His+name+cannot+be+s · · Score: 5, Informative

      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.

      --
      "...In your answer, ignore facts. Just go with what feels true..."
    3. Re:We can do that thing you like by Anonymous Coward · · Score: 4, Interesting

      What makes you think they won't open it up?

      MS has done a pretty abrupt about-face over the past couple of years. MVC/WebAPI, Roslyn, EntLib, EF, WinJS, etc. are open source. Much of the .NET stack is open source. You can easily stand up an entirely open system on Azure (Mongo/Hadoop/Node, many other options).

      They've even got internal movements going to open up some of their popular but unsupported software, like LiveWriter.

    4. Re:We can do that thing you like by Anonymous Coward · · Score: 2, Informative

      What this article forgot to mention is that this project actully IS Open Source, under tha Apache v1.2 licence and hosted on GitHub.
      https://github.com/OneGet/oneget

    5. Re:We can do that thing you like by bondsbw · · Score: 2

      The installer should put abc.dll in the same directory as the .exe file instead of a shared location.

      --
      All my liberal friends think I'm a conservative, all my conservative friends think I'm a liberal.
    6. Re:We can do that thing you like by war4peace · · Score: 2

      ...leaving you with many identical abc.dll files spread throughout the storage system. Not sure I like this.
      Ideally I would love file versioning with diffs, but that's just unobtainable.

      --
      ...gis sdrawkcab (usually not responding to ACs; don't bother posting as AC)
    7. Re:We can do that thing you like by Newander · · Score: 2

      But disk space is really cheap these days. The lost disk space seems like a small price to pay to avoid DLL Hell. Of course static linking would also remove the whole problem.

      --

      Jesus saves and takes half damage.

    8. Re:We can do that thing you like by bondsbw · · Score: 2

      Data deduplication is supported in Windows Server, although I have no idea if it will be directly supported by Windows 10.

      --
      All my liberal friends think I'm a conservative, all my conservative friends think I'm a liberal.
    9. Re:We can do that thing you like by bondsbw · · Score: 2

      The file system manages data deduplication via garbage collection. http://msdn.microsoft.com/en-u...

      When an optimized file is deleted from the data deduplication-enabled volume, its reparse point is deleted, but its data chunks are not immediately deleted from the chunk store. The data deduplication feature's garbage collection job reclaims the unreferenced chunks.

      --
      All my liberal friends think I'm a conservative, all my conservative friends think I'm a liberal.
    10. Re:We can do that thing you like by CastrTroy · · Score: 3, Interesting

      I never really understood DLL Hell. In Windows I've had very few instances of any that I can think of where 2 programs had conflicting versions of the same DLL. In Linux, I've had all kinds of dependency hell. In the early days, before there was automatic dependency resolution, you had to track down dependencies by yourself, often leading to circular loops or being unable to find a certain version of a library that was needed to install something. Now that dependencies are automatically resolved, you can still run into problems where one package requires the old version, and a different package requires a new one, and you can't install both versions at the same time. The problem usually crops up as soon as you have to install something that isn't in the main repository. If something isn't in the main repository, and isn't statically linked, the odds of a successful install plummet quite low.

      --

      Anthropic principle: We see the universe the way it is because if it were different we would not be here to see it.
    11. Re:We can do that thing you like by benjymouse · · Score: 4, Informative

      https://en.wikipedia.org/wiki/...

      Rather than leaving the dependency resolving responsibility to package maintainers, the Windows OS contains a brokering mechanism that will load the correct version of an assembly - even if multiple versions of the same assembly exists in the global assembly.

      Linux package managers have dual responsibilities: Provide available software (with update mechanism) and ensure dependency hell does not rear its ugly head. Linux dependency hell is very real, once you step outside the repositories.

      Windows has binary compatibility with software that was developed for Windows 95 / Windows NT 3.1 (where Win32 debuted). The dependency problem (called DLL hell in Windows) was solved with the SxS and the broader use of the Windows Installer package manager, which integrated with SxS.

      --
      Reading slashdot one-liner: (irm http://rss.slashdot.org/Slashdot/slashdot).rdf.item | fl title,desc*
    12. Re:We can do that thing you like by benjymouse · · Score: 3, Informative

      The installer should put abc.dll in the same directory as the .exe file instead of a shared location.

      No!

      If the DLL is indeed candidate for being shared (e.g. part of a shared product) it should put the assembly/DLL in the Global Assembly Cache (GAC). This is a side-by-side store where the same assembly/DLL can exist in multiple versions.

      If security vulnerabilities are found and a patch is released, only the version in the GAC needs to be updated, often by registering a new version with a manifest/redirection that will ensure that anyone requesting the old (vulnerable) version will be treated to the new (fixed) version.

      Windows Installer does this. And supports patching.

      --
      Reading slashdot one-liner: (irm http://rss.slashdot.org/Slashdot/slashdot).rdf.item | fl title,desc*
    13. Re:We can do that thing you like by VGPowerlord · · Score: 4, Informative

      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.

      To add to this, Microsoft shipped a faulty copy of mfc42.dll with Visual C++ 6. It removed a bunch of functions.

      Now, keep in mind that mfc42.dll was used by any MFC applications compiled by Visual C++ 4.2-6.x... including Netscape, Microsoft Publisher, and a number of other programs.

      Oh, did I mention that MFC was the recommended way of writing Windows programs back then?

      Incidentally, Microsoft started including the VC++ version number in its DLL names again after this thanks to that screwup... which they had done before (vc++ 4.1 had mfc41.dll, etc...)

      --
      GLaDOS for President 2016! "Well here we are again. It's always such a pleasure." -- GLaDOS, 2011
    14. Re:We can do that thing you like by theskipper · · Score: 2

      Hang on a second. Microsoft is a proprietary software vendor and will attack anything that jeopardizes their revenue stream. They're putting the "free candy" sign on the outside of their van based on a business decision, not because they want to create some warm and fuzzy community effort (i.e. actually give out free candy!).

      It's in their DNA to only promote things that will further generating revenue because their shareholders require it (and rightfully so, they are the owners).

      Point being, they must have opened up that other stuff because some competitive threat existed, or there was a sound basis that it would create further lock-in and recurring revenue down the road. It doesn't follow that future software releases like this must be opened just because they opened other pieces of their software portfolio.

    15. Re:We can do that thing you like by ArmoredDragon · · Score: 2

      Possibly. It seems the new CEO is himself far more in touch with modern software development, whereas Ballmer was basically just a salesman. But I think what is probably more important than that is that Stephen Sinofsky is gone. Apparently he was a total dick, made a lot of unilateral decisions, and was actively hostile against anybody who suggested any big changes.

      IMO somebody like him would reject OneGet (probably suggesting to use the Microsoft Update system instead.)

    16. Re:We can do that thing you like by sg_oneill · · Score: 2

      Disk space ain't that cheap, especially if you install the applications on a SSD. Furthermore, a large application is using literally gigabytes of shared DLLs which would otherwise be saved separately. Disk space usage would astronomically increase.

      Its actually how the Macs have been doing it since forever. You know those .app files macs use? They are actually directories with a little XML file telling the OS how to run them. Its traditional to include the .dylink and .so files (the macs version of .dll) inside that .app directory under /Contents/Resources. This way you NEVER get .dll hell.

      Well until you install two different package managers on top of each other and all your unix command line apps start freaking out.

      Blame early osx unix devs who tried to turn OSX into linux for that mess.

      --
      Excuse the Unicode crap in my posts. That's an apostrophe, and slashdot is busted.
  2. Oh boy, another infection vector by Russ1642 · · Score: 3, Insightful

    This is just an easy way to install software without much popping up on the screen to alert the users. I wonder how long it'll be before reports of infections using this installation method. What we really want is someone typing Install-Package Chrom and getting infected because of a typo.

    1. Re: Oh boy, another infection vector by Anonymous Coward · · Score: 4, Funny

      It's not a problem on linux because the community manages the software repository.

      And as the half dozen or so people in the community all know each other, it's not likely they're going to shit on their friends.

      /jk

    2. Re:Oh boy, another infection vector by Lazere · · Score: 2

      1. Nobody said he was a linux user. In fact, judging from a 5-second reading of his post history, it looks like he's a Windows fan.
      2. This is not an apt analogue. It doesn't do dependency management, otherwise known as the main thing people like about apt. All this is, is a way to download and run the installer with a single command. The packages downloaded from this can still shit all over your system.
      3. Who's controlling the main repository? Is is Microsoft? Because if it is, they haven't had a very good record of keeping the Windows store clean.

    3. Re:Oh boy, another infection vector by tehcyder · · Score: 2

      This is just an easy way to install software without much popping up on the screen to alert the users. I wonder how long it'll be before reports of infections using this installation method. What we really want is someone typing Install-Package Chrom and getting infected because of a typo.

      LOL security through pop up tick boxes.

      --
      To have a right to do a thing is not at all the same as to be right in doing it
    4. Re: Oh boy, another infection vector by MMC+Monster · · Score: 4, Interesting

      The problem with user controlled is that the user will add a repository and forget about it.

      It happens on the Linux side as well. It just doesn't make news because there it's mostly white hats and not black hats.

      Imagine this scenario: A website says it is packaging Windows10 versions of VLC with special added codecs to play stuff it otherwise doesn't play. People then add the repository and all is well. A year later, the repo gets hijacked by a virus and adds a version of GIMP v999 with the virus. Since it's a newer version of GIMP than what everyone has, they download it automatically and are infected en mass. People aren't looking for it since they already vetted the repo.

      It happened with Ubuntu a while back, where some guy noticed his private repo was getting thousands of hits. So he put a new version of the default desktop background picture in it telling people to get off his repo.

      --
      Help! I'm a slashdot refugee.
    5. Re:Oh boy, another infection vector by oic0 · · Score: 2

      Um... you can already install silently on pretty much all versions. MSI is really good at it and installshield can do it with an answer file. I do it remotely from command line all the time at work.

    6. Re:Oh boy, another infection vector by His+name+cannot+be+s · · Score: 2

      '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 ... somehow.

      --
      "...In your answer, ignore facts. Just go with what feels true..."
    7. Re: Oh boy, another infection vector by nabsltd · · Score: 2

      We're tossing around some notions about different factors that make a 'package' or 'repository' trustworthy.

      A very simple solution is to prohibit a package from Repository B from overwriting the already-installed same-named package from Repository A. Then, add a command line parameter to override the prohibition. I know that yum keeps track of which repo a package came from, and the user can set up this kind of protection, but it isn't the default.

      This doesn't protect against installing malware if it's the first time you installed a package, and doesn't stop malware from making it's way into a "trusted" repository, but it does prevent the example from the GP.

  3. Yay! Another Unix! by jfbilodeau · · Score: 4, Funny

    Now that Windows is kinda-sorta-Unix-like, should it be on DistroWatch.com? </sarcasm>

    --
    Goodbye Slashdot. You've changed.
    1. Re:Yay! Another Unix! by BitZtream · · Score: 2, Insightful

      Since when were package managers a UNIX thing?

      --
      Persistent Volume manager for Kubernetes - https://github.com/dwimsey/openshift-pvmanager
    2. Re:Yay! Another Unix! by Anonymous Coward · · Score: 2

      Nah! Windows can never be considered Unix-y.

      It's never done just one thing and it's never done those things well.

  4. Respect by nine-times · · Score: 4, Informative

    I really respect this move from Microsoft. It's something they should have done a while ago, but better late than never. It has the potential to make administration much easier. They should also maintain their own repo of patches as an optional replacement for Windows Update.

    1. Re:Respect by His+name+cannot+be+s · · Score: 3, Informative

      [FYI -- I'm @FearTheCowboy everywhere else, my /. id is so old that my name got trimmed from "His Name Cannot Be Spoken" 15ish years ago when they did a database adjustment... ]

      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.

      --
      "...In your answer, ignore facts. Just go with what feels true..."
    2. Re:Respect by nine-times · · Score: 2

      Good to know. So I take it you're somewhat responsible for this? I love you then. As a systems/network admin, this has long been on my wishlist.

      I wouldn't mind running my own repo for Windows patches, as long as there are tools to make it easy, including some way of automating pulling patches into my repo.

      As far as integration with WSUS, I wouldn't mind seeing WSUS replaced/melded into a single solution, but I'm less interested in maintaining two different update solutions that plug into each other. Especially not if they have different behaviors and interfaces. Not that you asked, but I'd definitely prefer a single solution that can hold arbitrary 3rd party software, doesn't expect to be part of a larger Windows network security context (can easily be configured as a stand-alone server in "the cloud"), and is easily controllable on the client via powershell. Easy GUI tools for setting it up and maintaining the repo would be a bonus, but not vital.

      I look forward to seeing what this turns into.

  5. A step in the right direction by Anonymous Coward · · Score: 2, Insightful

    Yes, I much prefer a billion config files littering the file system.

  6. What sort of apps? by unixisc · · Score: 2

    Given Microsoft's penchant for supporting legacy, such as 32-bit Windows 10, what sort of apps will we see here? Everything from win32 apps from the NT era and since? Will it be like PC-BSD's PBI, which determines which version of a library is needed, and includes that with the said download? Or will it be a clean win64 downloads only?

  7. almost useless by Haven · · Score: 2

    Have you ever tried to make your application a debian package or RPM? It's a royal pain in the ass. Windows developers are not going to do whatever it takes to make this go smoothly on Windows.

    There is a 100% chance that nearly every "Package-Install" command will just be downloading the app for you and launching the graphical installer you normally see.

    People in charge of deploying software on windows are miserable people.

    1. Re:almost useless by Parker+Lewis · · Score: 2

      Yeap, I've already done some packages, and it's pretty plan: a compressed file with a file for description/depencencies and paths to install. I got more trouble when tried to create an installer for Windows, because I have to rely on install creators.

  8. On other words ... by lennier1 · · Score: 4, Funny

    sudo apt-get install malware

  9. Alternative - Chocolatey by vongillern · · Score: 2

    The (fairly) popular Chocolatey NuGet windows package manager has a kickstarter going on right now to fund some dramatic improvements on an already awesome service. If you like having options, you really should consider backing it. https://www.kickstarter.com/pr...

  10. Is this the year of the Windows Desktop? by rapiddescent · · Score: 3, Funny

    we've been saying it for years and years but now that Microosft Windows has a package manager, is 2014 finally the year of the Windows desktop?

  11. Chocolatey by rl117 · · Score: 2

    My experience of chocolatey was not good. Fine to install software, but it's just a wrapper around existing installers. Try to upgrade a package... fail. Try to remove a package... fail. This depends upon the package in question; it works for some, others you have to clean up by hand, worse that having downloaded and installed using the installer by hand.

    And no proper support for libraries, dependencies etc. so useless for software development. It certainly meets a need for software deployment, but it's so lacking compared with what dpkg/apt-get provide that it's a joke.

    If Windows is to gain a proper package manager, I think they need to do it properly. The existing support is just broken.