Follow Slashdot blog updates by subscribing to our blog RSS feed

 


Forgot your password?
Close
typodupeerror
×
Software

Zero Install Project Makes 1.0 Release 82

Posted by Unknown Lamer from the no-installation-fees dept.
tal197 writes "Zero Install, the decentralized cross-distribution software installation system, announced 0install 1.0 today after 8 years in development. 0install allows authors to publish directly from their own web-sites while supporting familiar features such as shared libraries, automatic updates, and digital signatures. Is this the end of the walled-gardens of traditional app stores and Linux distributions and the beginning of a true 'Web of Software'?"
This discussion has been archived. No new comments can be posted.

Zero Install Project Makes 1.0 Release More

Zero Install Project Makes 1.0 Release

Comments Filter:

  • The Future (Score:4, Insightful)

    by Nerdfest ( 867930 ) on Monday May 23, 2011 @02:49PM (#36221044)
    Sadly, things now look like they're heading in exactly the opposite direction.

    • ...the end of the walled-gardens of traditional app stores and Linux distributions and the beginning of a true 'Web of Software'?"

      No. It's not even going to be a blip on the radar. The walled garden approach, particularly as implemented by Apple, provides a (so far) safe and comfortable buying and operating environment for users; opening your system (any system - phone, computer, heck, even your watch) to what amounts to an anonymous and potentially shifting web of software repositories isn't going to fly

  • No (Score:1)

    by Anonymous Coward
    Considering that no-one uses it, I sincerely doubt it.
  • Just installed Firefox 4.0.1 on Debian Squeeze seconds after reading about this. Seems like a good way to get updated apps on a stable base.

    • deb http://mozilla.debian.net/ [debian.net] squeeze-backports
      # apt-get install -t squeeze-backports iceweasel

      Iceweasel 4 on Squeeze/Wheezy is fun. Fuck your newfangled installer.

    • Re: (Score:1)

      by AvitarX ( 172628 )

      If you have .NET and Microsoft Visual C++ 2008 Redistributable Package, I don't think you need admin for the initial set-up. The software list includes some very useful software (FileZilla, Notepad++, AviDemux, Audacity, UltraVNC (though I imagine if I need the server it is best to install as admin), VLC, and 7-zip (though I doubt it has the shell integration)) and I am likely to use it for some of those going forward (needing admin to update notepad++ is a nuisance). I just wish I could make a quicklaunch

  • It seems to work very similarly to other package management systems. The main difference is that it stores the downloaded dependencies in a user-owned cache, and that the application developer, instead of the particular distribution, defines the publically metadata package definition that lists all the dependencies. Are there any other differences?

    If this is right, I don't see wide adoption unless distributions start replacing their official package management systems with it. If you're trying to make a uni

    • Re: (Score:1)

      by Anonymous Coward

      why not just make a universal, self-contained application bundle, similar to the Mac OS X .app bundle, that contains all necessary dependencies without having to download them separately?

      Because then every application developer is responsible for patching every bug in every library they use. In the centralized-distribution model, only the maintainer of each library's package has to care about flaws in that library, and when they're patched, every other package that uses that library is fixed automatically.

      • i understand that, but on the mac project that i work on, we use an automated package management system to compile the dependencies, which we then include inside the app bundle. most of the time we don't have to patch anything, and if we do - to get something to compile - we just send the patch upstream. the main difference ends up being that we're the ones who run the compile/install command instead of our users. the benefit is that the user just drags and drops the application bundle into their applicatio

        • No, he doesn't mean patch "because my application broke!"

          You write an e-mail client.

          You give it to your user in a .app. It's v1.03 of MacMailGarbage.app.

          Now you release v1.04 of MacMailGarbage.app, your user has to download it.

          Now libsnmp is found to have a bug. Linux users update libsnmp. Apple users ... well, you have to rebuild MacMailGarbage.app with the new libsnmp, put it in the v1.04 .app, and ship it to your users. If you don't, then MacMailGarbage.app can be hacked by sending a deformed

          • Now libsnmp is found to have a bug. Linux users update libsnmp. Apple users ... well, you have to rebuild MacMailGarbage.app with the new libsnmp, put it in the v1.04 .app, and ship it to your users. If you don't, then MacMailGarbage.app can be hacked by sending a deformed HELO from the server, executing malware on the user's machine.

            You're assuming that Apple does not include such basic libraries in the OS. They do. It isn't normally an issue.

            Now libssl has a security hole. If you don't release a new version of MacMailGarbage.app, your users will be susceptible to rogue SNMP connections, possibly by a MitM.

            Again, SSL is a basic OS X API.

            Now libpng has a security hole. Again, Linux users update libpng. Mac users have to update...

            And again, PNG support is built into OS X. Not an issue. I understand your point in general, but 3 of the 3 examples you gave off the top of your head are not really issues at all. In practice, this is not a major concern for OS X developers or users.

            As far as I am concerned, .app software packaging is a HUGE advantage that OS X has over both WIndows and Linux. I w

      • If the operating system base you're installing on is stable and broad enough such that few libraries need be packaged with the user intalled application, then it is really not that much of an issue, like on OS X. But Linux is just too fragmented for it to really work. There's the LSB, but I don't think it is strong enough.

    • Re: (Score:3)

      by skids ( 119237 )

      Having multiple copies of shared libraries is bad for the system memory profile, not to mention bad for leaving lingering bugs long after they have been fixed in the library's mainline code.

      Which is why a solo approach to dependency management has sever limitations. Distros may have messy process, but they are on the right track in that a lot of collaboration, and the tools to make it smooth, is needed to do things right.

      • In 0install, it seems like you still have multiple install points unless you enable the system-wide cache that lets any user install into it. Otherwise there might end up being multiple copies anyway.

        as far as the lingering bugs go, this may be true. but if, for example, i'm writing a GUI front-end to a back-end library , it becomes my responsibility to update that package so that my own application is bug-free, no? and if there is no bug, then no harm, no foul in letting my library lag behind a little bit.

        • (but point taken about multiple copies in memory.)

          • Re: (Score:1)

            by AvitarX ( 172628 )

            Even still, how much of a burden is it?

            At least for single/few user desktops I can't see it as too much of an issue. I mean, how much memory is really wasted on a newish desktop?

            My total size thus far is 229MB (about half of that is eclipse), even if the wasted memory is 20-50MB an application it's not going to make too big of an impact on a single user system. And if one wants, it can even rely on LSB I believe, eliminating a lot of the need to include copies of base libraries, and a decent starting point

            • Re: (Score:2)

              by tal197 ( 144614 )

              ... And if one wants, it can even rely on LSB I believe, eliminating a lot of the need to include copies of base libraries, and a decent starting point (though I can't tell if 0Install allows that, I think ROX application directories do, and this looks like a way to replace them though.

              I'm not quite sure what you're asking here, but to be clear:

              0install always shares libraries and other dependencies. For example, if your program depends on Java then 0install will use the distribution's version of Java (if installed), or 0install may download a 0install package of Java, or it may get Java from your distribution (using PackageKit). A 0install package should never need to bundle libraries.

              On a multi-user system you can enable system-wide sharing. This is off by default because it requir

              • Re: (Score:1)

                by AvitarX ( 172628 )

                Interesting, I knew it shared amongst itself, but did not realize it shared with the distro (or how to make it do that).

                This should address all the complaints of wah, too many copies.

                As I said, I used it on Windows (and last night tried to use it to install ROX, but failed in getting a successful ROX session, and the programs didn't appear to run consistently).

                I really like that it doesn't use admin, and installs conveniently and neatly. For every application not integrated into the OS/Desktop environment i

        • Re: (Score:2)

          by lennier ( 44736 )

          if there is no bug, then no harm, no foul in letting my library lag behind a little bit.

          In my experience, the chance at any given moment that there is no security-critical bug in any library anywhere is approximately zero. Everything currently available has a bug. It's ony a matter of time until the black hats discover it (and chances are they already have).

          So if you ship your own copy of any system library, you're a botnet waiting to happen. At the very best, if yuo package your own yet-another-update-mechanism, you'll be yet another annoying always-running process sucking up CPU and Internet

          • Sure this is a big security issue for networked apps, especially those that listens on sockets.

            However for many desktop utility apps (graphics programs,etc) that has a tendency to depend on cutting edge libraries, it's a major hurdle for users to try them out (without borking up half their system to go cutting edge for that single app). This might even be a reason for why linux has never really succeeded on the desktop since you either get a flawed experience or an outdated experience.

            As for security, a 0in

      • It depends how it's handled. It's definitely bad for memory, but it really depends how it's handled. PCBSD seems to do pretty well with its PBIs which do include their own dependencies. So, you waste space, although not as much in the future with ZFS and dedupe, but you gain stability, you know that if you install a PBI that it won't screw up the rest of the computer via dependency issues.

      • Having multiple copies of shared libraries is bad for the system memory profile, not to mention bad for leaving lingering bugs long after they have been fixed in the library's mainline code.

        Depends on how much you are not sharing. If the OS base is strong enough and you only need to bundle minor auxiliary libraries with your app, it isn't a big deal. And even if you do package a bugged library with your application, it may not matter. The bug may not even apply to yoru application. As long as your application works and the bug isn't security related, there's no problem.

        Which is why a solo approach to dependency management has sever limitations. Distros may have messy process, but they are on the right track in that a lot of collaboration, and the tools to make it smooth, is needed to do things right.

        I have to strongly disagree. As an end user of LInux on the desktop for 12+ years and OS X for almost 4 now, I can honestly sa

    • This is actually a little weird compared to most other package management systems, from the looks of it. For one, you're never actually installing it (note: I'm just going to refer to Linux, because I'm not familiar with anything of the sort for Windows or Mac at all, but every big distribution of Linux has something). You install it to your local user's cache and run it from there, whereas most package management systems require you to login as root to install the package. The cool thing about that, is tha

      • This whole project is somewhat similar to Cameyo [cameyo.com]

        But as far as the kernel goes, that would be a really bad idea. You shouldn't be installing kernel modules in this fashion, even temporarily, I could see this as a means of soft upgrading to a new version to make sure that nobody pulls a Ubuntu on you. Mixing distros though would likely be a bad idea given the lack of agreement over aspects of OS design.

        • I actually agree with what you're saying. And looking into what you posted and 0install a bit more, it makes sense that you may have misunderstood exactly what I was thinking. Mind you, I was thinking outside of what 0install does here, so the kernel piece I mentioned would be more appropriate as something of a side to this.

          My thought is that this would actually be an interesting idea for managing apps within a distribution. Some of the core aspects such as kernel and stuff could be done in a more decentral

    • Like PCBSD does already?

    • why not just make a universal, self-contained application bundle, ... that contains all necessary dependencies without having to download them separately?

      In addition to many duplications of the dependencies in multiple clients of it (which has already been mentioned)...

      If any IP issues with the dependencies are discovered later, the trolls have far more people to go after.

      Why increase risk? By NOT shipping the dependencies the authors of the depending code are insulated from liability - while still having

  • "Is this the end of the walled gardens..." (Score:1, Insightful)

    by Anonymous Coward

    Is this the end of the walled-gardens of traditional app stores?

    Sure, provided 0install works on every popular platform that has a traditional app store.

    What's that? It doesn't run on any of those? Oh dear.

    • Re: (Score:2)

      by tal197 ( 144614 )

      What's that? It doesn't run on any of those? Oh dear.

      Yes, some platforms are so locked down that they won't let you run 0install. But it has been ported to all the common platforms that allow it (Linux, Unix, Mac OS X, Windows).

  • ...Windows will finally have an application manager that will auto update applications? InstallPad was an interesting idea that seemed to fall back into obscurity and hasn't been updated in years, and don't even get me started on the stupid BitComet (I think it's installed with BitComet, haven't used it in a long time) auto program updater.

    HEX

    • Re: (Score:1)

      by DogDude ( 805747 )
      It's not needed. Most apps do it themselves.

      • While some do, they usually make use of a constantly running update check task. (Adobe, Java, etc) Some check when the program runs, which is a bit better, but if I need to use the program I don't want to spend time updating. I'd rather have one program checking all my apps and drivers and installing updates automagically at night.

        HEX

  • Here's what a tool like this needs to be able to do, download the package which is then converted into a package format appropriate for the system (DEB, RPM, TGZ, etc.)

    Why has no one done this yet? I'm not saying it's going to be easy, but surely, I'm not the first to think of this.

    I know there is 'alien' but it's always seemed a bit hackish to me, and when packages get installed, it's not as if they get installed into the appropriate directories (e.g. if an RPM package installs its contents into /opt and

    • Re: (Score:2)

      by vlm ( 69642 )

      Here's what a tool like this needs to be able to do, download the package which is then converted into a package format appropriate for the system (DEB, RPM, TGZ, etc.)

      Why has no one done this yet?

      You're confusing what it means to be a file format with what it means to be a software package.

      A Debian package is only a Debian package because it was accepted into the archives because it follows a couple hundred pages of Debian Policy.

      I could put random atari2600 roms into a .DEB formatted file and install into C:\WAREZ\ , but that doesn't make it a "Debian package"

      • Er, no. It would still be a debian package. It just wouldn't be an official package.

        As well it wouldn't be that simple to do. The .deb file has more than just files, it is an 'ar' archive containing:

        1. debian-control - a simple file with the package version number
        2. data.tar.gz - this is what you seem to think a .deb or .rpm is, and only is (can be other compressors, such as lzma, bzip, xz - but it is always a tar archive)
        3. control.tar.gz - contains scripts for install, configuration, uninstall, etc - as well as t

    • The trouble is, you very quickly get into "do-what-I-mean" territory. If I'm building a binary package in whatever form for whatever distro I'm building it for, I'm expecting the system to be set up in certain ways with certain conventions. For instance, do the executables belong in /opt/foo/bin, /bin, /usr/bin, /usr/local/bin, or somewhere completely different? I as the package maintainer for an attempt at a generic distribution system certainly don't know, and any tool that tries to figure it out would fa

    • Why has no one done this yet?

      Because converting packages to different systems doesn't deal with the dependency hell found in most non-trivial Linux applications. The location of the binaries is actually the least of your concerns.

  • Isn't this basically the same thing as what Java was trying to do? The problem (if I'm reading this correctly) is that the Zero Install program needs to be on the user's computer for it to work...exactly the same as needing a JVM installed for Java to work.

    • Re: (Score:2)

      by tal197 ( 144614 )
      It's perhaps more like Java Web Start in concept, but it works with any language (including Java). There is the 0export [0install.net] tool to create self-extracting bundles, but yes in the normal case it assumes that 0install will already be on the machine.

  • We could create a massive installation architecture that requires whole new networks and languages.

    Or, we could just seek out reputable sources, download executables, and run stuff.

    Whatever happened to Tucows...hmmm... it's still in business. Their "spotlight program" is Registry Booster 2011. So sad.

  • ClickOnce [wikipedia.org] for Linux. Not exactly a new idea.
  • I grew up as a RiscOS user, which had this kind of application folder system.
    Package management is >much If you are going to have shared blobs of code like shared-objects/DLL you need package management, end of story.
    You want one copy of each, or a least one of each version, and you want to update that one file. Even on modern machines, you don't want to statically link everything, even if you did, think about updates. If one of these files need a fix, it's much easier to update that one file, then upd

    • Re: (Score:2)

      by tal197 ( 144614 )

      RISC OS application directories and Apple bundles have the nice property that you can install from anywhere, can have multiple versions and there are no conflicts between packages (e.g. both installing a "/usr/bin/convert"). But shared libraries are a pain because you have to install them manually, and upgrading a library needed to install program B can make program A stop working.

      Debian packages have the nice property that you get dependency handling and automatic updates, and shared libraries work bette

      • Re: (Score:2)

        by jabjoe ( 1042100 )
        In Debian (and no doubt other package managers) you can have A and B use different versions of a shared lib, but one uses the "somelib.so" and the other "somelib.1.0.so". Normally a version of lib is standardize as the version of a lib. Other versions are used with version number as part of the name. If there is a conflict, then yes you can have only one or the other, but I don't see how you get out of that. For instance /usr/bin/convert and /usr/local/bin/convert is still a conflict in my book, one (local)

        • Re: (Score:2)

          by tal197 ( 144614 )

          In the case of 0install, the command name (if any) is chosen by the user, not the package. So you might do something like this for shell use:

          $ 0alias convert-img http://image-editor.org/convert [image-editor.org]
          $ 0alias convert-text http://text-converter.com/convert [text-converter.com]

          If a package depended on one of these, it would express that in its dependencies. e.g.

          Make example.com/convert >= 1.3 available to me as 'convert'

          0install would ensure that example.com's convert command was in $PATH, but just for the program that n

  • Darn, I left the "Wild West" of Windows programs behind, and I am sure not going to start installing stuff from people I have no reason to trust now! I'll stick to the Linux repositories and a few (Very few) trusted applications from people and places I Know are trustworthy! I don't even have to get into the whole issue of multiple copies of the same files spread all over my system!

Slashdot Top Deals

Software production is assumed to be a line function, but it is run like a staff function. -- Paul Licker

Close