Zero Install Project Makes 1.0 Release

← Back to Stories (view on slashdot.org)

Zero Install Project Makes 1.0 Release

Posted by Unknown on Monday May 23, 2011 @07:47AM 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'?"

67 of 82 comments (clear)

Min score:

Reason:

Sort:

The Future by Nerdfest · 2011-05-23 07:49 · Score: 3, Insightful

Sadly, things now look like they're heading in exactly the opposite direction.
No by Anonymous Coward · 2011-05-23 07:49 · Score: 1

Considering that no-one uses it, I sincerely doubt it.
Works well by GuerillaRadio · 2011-05-23 07:54 · Score: 1

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.

--
If a man empties his purse into his head no man can take it from him. An investment in knowledge pays the best interest.
1. Re:Works well by lolcutusofbong · 2011-05-23 09:08 · Score: 1
  
  deb http://mozilla.debian.net/ squeeze-backports
  # apt-get install -t squeeze-backports iceweasel
  Iceweasel 4 on Squeeze/Wheezy is fun. Fuck your newfangled installer.
2. Re:Works well by AvitarX · 2011-05-24 10:19 · Score: 1
  
  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 for it.
  If it gets anything resembling wide support I am likely to use it on Linux for newer versions of stand-alone type software, and it looks like a great way to distribute commercial games. Essentially a more convenient getdeb.net, or ppa, depending on the type of software.
  
  --
  Wow, sent an e-mail as suggested when clicking on "use classic" banner, and got a fast response that addressed my msg
Not sure what the user benefits are by monoqlith · 2011-05-23 08:01 · Score: 1

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 universal system that can be used everywhere, 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? This way users drive adoption instead of distributions.
1. Re:Not sure what the user benefits are by Anonymous Coward · 2011-05-23 08:20 · Score: 1
  
  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.
2. Re:Not sure what the user benefits are by skids · 2011-05-23 08:34 · Score: 2
  
  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.
  
  --
  Someone had to do it.
3. Re:Not sure what the user benefits are by monoqlith · 2011-05-23 08:39 · Score: 1
  
  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 applications folder and the install is complete
  you're right about the application developer having to manage the dependencies - however, i guess i ask this: might that be a fair price to pay for the cleanest user-experience possible? package management of this kind seems to have making things easier for the developer, and not necessarily the user.
4. Re:Not sure what the user benefits are by crazycheetah · 2011-05-23 08:40 · Score: 1
  
  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 that for this, you can install things without ever going into root, and since you're technically installing it the same way as you would on Windows (finding it on a webpage, or I suppose, it would probably be a good theory to have this included on a CD and install it through this from the CD), it's actually a little bit more secure, because there won't be any weird place for it to do something weird. Of course, most distributions are pretty on top of things and keep any problematic things out in their package management systems, but with this, you're relying on the package managers as opposed to the distribution managers to let you install it so easy.
  This would probably be even better if they put together a main database of apps that support this, allowing the users to look through the apps more like the typical package management systems or app stores. I only looked at the webpage briefly, so I might be missing some way that they do this already, but it didn't look apparent just from what I saw on there.
  For people like me, it would be even more cool if they did enable a way to install things as root in such a way that they could include new kernels and stuff like that. I'm kind of thinking of my Gentoo box in that, but also that it would be an interesting concept to develop this into a whole new distribution over time--maybe start out similar to how Gentoo did, with being able to start almost from scratch (my days of Stage 1 Gentoo installs... I kind of miss those some times), but do it somehow better (less compiling yourself, and maybe build it up to Ubuntu status installs, some several years in the far future). I certainly wouldn't count on seeing that, but it is an interesting concept.
5. Re:Not sure what the user benefits are by bluefoxlucid · 2011-05-23 08:46 · Score: 2
  
  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 HELO from the server, executing malware on the user's machine.
  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.
  Now libpng has a security hole. Again, Linux users update libpng. Mac users have to update your MacMailGarbage.app specifically, because the system-wide libpng they installed isn't the one MacMailGarbage.app is using. Firefox.app also needs updating, because it contains a bad libpng version.
  You've made no new releases at all, but your users needed a new .app 3 times. And getting a .app from you doesn't make using any other software safe, as that other software could come in a .app with the same exact library exhibiting the same exact security hole, and so they could be hacked unless they update it.
  
  --
  Support my political activism on Patreon.
6. Re:Not sure what the user benefits are by monoqlith · 2011-05-23 08:52 · Score: 1
  
  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.
  in other words, my interest as a developer in ensuring the smoothest experience possible for my users is enough to guarantee that i fix all the bugs that might impact that experience, including those in my dependencies.
7. Re:Not sure what the user benefits are by hedwards · 2011-05-23 08:58 · Score: 1
  
  No. I've used Windows and I've never had trouble with viruses. It's because I'm careful and have antivirus software. The reason why it's a problem for some people is that they're not careful and install from untrusted sources.
  Personally, I like FreeBSD's ports as well as some of the better Linux repository systems. RPM can rot in hell for all I care, hopefully they've finally managed to figure out that making users download each item for an update isn't the way to go, especially without providing a list of dependencies for the entire process.
  But, the reason why those systems work isn't because of the centralized nature, it's because you've got folks paying attention, monitoring and in some cases auditing them. There's no inherent reason why a malware package couldn't make it into ports other than people keeping an eye on what they're adding.
  The bigger issue by far is the lack of a centralized means of identifying which applications are out of date and tracking vulnerabilities. If you had something like that, then central or no, things would likely be a lot more secure.
8. Re:Not sure what the user benefits are by hedwards · 2011-05-23 09:00 · Score: 1
  
  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.
9. Re:Not sure what the user benefits are by hedwards · 2011-05-23 09:03 · Score: 1
  
  This whole project is somewhat similar to Cameyo
  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.
10. Re:Not sure what the user benefits are by yarnosh · 2011-05-23 09:14 · Score: 1
  
  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.
11. Re:Not sure what the user benefits are by yarnosh · 2011-05-23 09:31 · Score: 2
  
  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 would not trade it away. It is one of those things that keeps me using OS X.
12. Re:Not sure what the user benefits are by monoqlith · 2011-05-23 09:31 · Score: 1
  
  (but point taken about multiple copies in memory.)
13. Re:Not sure what the user benefits are by yarnosh · 2011-05-23 09:34 · Score: 1
  
  Everything you say applies to servers, not desktop end users. As a user, I most certainly do want to latest and greatest. In fact, that's what always made using Linux on the desktop so frustrating for me. I felt so straight jacketted by centralized package management.
14. Re:Not sure what the user benefits are by yarnosh · 2011-05-23 09:42 · Score: 1
  
  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 say that the OS X model kicks ass. I hate feeling straight jacketted by a centralized package system on a desktop system. I know that in theory a good central repository should be better, but in practice the .app model found on OS X is superior. It is bad enough that I have to rely on Macports for my commandline stuff. I dont' want that to leak into my desktop app experience.
15. Re:Not sure what the user benefits are by Lennie · 2011-05-23 09:51 · Score: 1
  
  That is why people on Ubuntu add a ppa for the app they care about (just geeks, most users don't care btw).
  
  --
  New things are always on the horizon
16. Re:Not sure what the user benefits are by yarnosh · 2011-05-23 10:02 · Score: 1
  
  But the "latest and greatest" aspect is just part of it. I want to be able to install any version I want/need, sometimes with two different versions side by side (Firefox 3 and FIrefox 4, for example). Also, I like being able to run an app from wherever I want. Hell, on OS X, I can launch most apps right from the compressed disk image it came in. I do that kind of things with little games I want to try out or whatever. Or I can carry an app around on a USB stick. It is just so handy, especially if you have to work on other Macs. I would never ever go back to centralized package management. As an end user, centralized package mangement actually gives me very little other than a single place to look for apps. But who cares? The Google is strong with me.
17. Re:Not sure what the user benefits are by WorBlux · 2011-05-23 10:18 · Score: 1
  
  Or upgrade to something with a rolling release.
18. Re:Not sure what the user benefits are by yarnosh · 2011-05-23 10:38 · Score: 1
  
  Still amounts to a straight jacket. You get latest software, but you still are forced to run whatever happens to be in the repo and what happens to be current for you your distribution and it installs only where the package dictates that it be installed. Also, you are forced to update things you may not want to because that's what your latest and greatest software happened to built against. It is all so tightly coupled. Overall it is just a bad user experience for anyone who may not want to do things exactly as the package maintainers think you should.
19. Re:Not sure what the user benefits are by crazycheetah · 2011-05-23 11:15 · Score: 1
  
  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 decentralized location as well, but it would have to be watched over a bit further than this. One of the things that bugs me at times about the current state of most Linux distributions is the fact that you still do have to install everything under root; this is generally OK, knowing that if I stick to the package managers, they have all been looked at by the distribution and I am getting it all from my distribution's servers, but it can get a little bothersome in some situations (I recognize some distributions have ways about this anyway, but they tend to be something most users are probably going to skip ever learning).
  As I said, that thought is something a good ways off, but it is an interesting concept that stuck me as I was reading over it. There is, of course, several challenges to make that even reasonable, but I consider it an idea that some might find interesting to experiment with.
20. Re:Not sure what the user benefits are by lennier · 2011-05-23 12:10 · Score: 1
  
  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 connectivity that your users will swear at - instead of magically having your bugs fixed with no fuss and effort by the normal system update process.
  Why be that guy?
  
  --
  You are not a brain: http://books.google.com/books?id=2oV61CeDx-YC
21. Re:Not sure what the user benefits are by WorBlux · 2011-05-23 12:31 · Score: 2
  
  Not all rolling releases are binary-only. Gentoo lets you do source based if you want. Keywords let you use pulse audio on every application if you want, or not have that library at all on the system. It's fairly straightfoward how to keep multiple versions of a package as well. To get custom locations you can copy the ebuild to an overlay and change a couple of the options that get passed to the configuration tool if your into that sort of thing. There are also methods to use versions that are newer of older than the latest stable I don't see how it could get any more flexible unless you're going to do it all by hand or use a separate prefix for every application statically link to libraries within, but either of those options seems fairly inefficient.
22. Re:Not sure what the user benefits are by Ungrounded+Lightning · 2011-05-23 12:33 · Score: 1
  
  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 an incentive to help wich the legal battle where the loss would pull the libraries out from under their products.
  
  --
  Bantam Dominique roosters crow a four-note song. Once you've heard it as "Happy BIRTHday" you can't NOT hear it that way
23. Re:Not sure what the user benefits are by yarnosh · 2011-05-23 14:28 · Score: 1
  
  Keywords let you use pulse audio on every application if you want, or not have that library at all on the system.
  Right, because the sound library my applications use is exactly the kind of thing I should be thinking about as a user. Why the hell should I have to care what audio library I'm using? Why is that still an issue on Linux? It is 2011 for Chrissake.
  Yes, I used Gentoo years ago and it was the biggest waste of tme of all the Linux distributions... once I got past the novelty of compiling everything tuned for my CPU. I'm getting too old for that shit.
  
  It's fairly straightfoward how to keep multiple versions of a package as well.
  More straight forward than just dragging, dropping, and renaming app bundles?
  
  To get custom locations you can copy the ebuild to an overlay and change a couple of the options that get passed to the configuration tool if your into that sort of thing.
  Or... I could copy the app bundle with my mouse. Hmmm.
  
  There are also methods to use versions that are newer of older than the latest stable
  Are any of those methods easier than just, you know, copying an app bundle? You see where I'm going here?
24. Re:Not sure what the user benefits are by yarnosh · 2011-05-23 14:39 · Score: 1
  
  I don't see how .app packaging is any different from statically compiled binaries.
  It is different because they are dynamically linked (for the most part) against system libraries. THe point is that OS X is a broad, stable target unlike the highly fragmented Linux distributions. A Linux developer can't even depend on you having GTK+ on your system, must less the correct version of it. If I target OS X 10.5, on the other hand, I know exactly what GUI libraries will be available and there's no need to statically link or code in libraries dependencies for a package manager to work out.
  The one draw back to all this is that applications are not terribly backward compatible. Currently it seems like many applications don't' support anything older than OS X 10.5, which is fine with me since I have no reason NOT to run at least 10.5.
  
  Besides, that greatly favors popular libraries and ignores libraries which may not be pre-installed whereas package management with external libraries are neutral to this.
  And I should care... why?
25. Re:Not sure what the user benefits are by yarnosh · 2011-05-23 14:54 · Score: 1
  
  Eh, you do know you can build your apps from source against whatever damn libraries you please, right?
  
  Sure, and then you suddenly lose any benefit that you might have gained from package management. In fact, this is one of the things that annoyed me so much about running Linux. If I wanted to do anything outside of the package manager, I was prtty much on my own and my system suddenly became 10 times harder to maintain. If for some reason I wanted to upgrade the base system, I'd have to go back and recompile all that custom shit by h and.
  
  We've got a few nifty little things like make, gcc, and gnu autopuke that can make that happen for you. And at least on Debian and slackware systems, it's barely any more work at all to rebuild an entire package, then install it through your existing package manager, so you're not even confronted with the issue of dependency resolution not knowing about locally installed apps.
  Have you actually tried backporting packages on Debian systems? You know there are strict dependencies, so you can't usually just backport your main app. You also have to backport many of the dependencies. And then you might find out that one f those dependencies won't build clearly and you spend half a day trying to figure that out. It is hell.
  
  So this "straitjacket" is completely optional, and you can get out of it at any time, it doesn't seem much like a straitjacket.
  Except that it turns out that being out of the straight jacket is worse than the straight jacket. OUt of the frying pan and into the fire, so to speak.
  
  Maybe you've been using one system that makes this stuff hard (Redhat, maybe? I haven't so much as diddled with an RPM-based distro since '99), but the oldschool distroes all make it easy, because they're made by hackers who wouldn't want to be constrained that way themselves.
  I've used half a dozen or more distributions including Debian, Gentoo, Ubuntu, Redhat, CentOS, and Slackware. These hackers have designed themselves into the straight jacket of package management because the alternative is worse and they are too disorganized to do any better. Package management is all about constraining yourself. That's why it works. That's how it works.
26. Re:Not sure what the user benefits are by mdmkolbe · 2011-05-23 15:54 · Score: 1
  
  Besides, that greatly favors popular libraries and ignores libraries which may not be pre-installed whereas package management with external libraries are neutral to this.
  And I should care... why?
  Because if developers choose what libraries to use mainly based on whether the library is likely to be already installed, then new but useful libraries are unlikely to become popular enough to become a standard install. In addition it becomes tempting for the developer to just implement the libraries functionality, but of course that is a drain on application developer time and is likely to have bugs that were already shaken out of the library. In an ideal world, developers would choose what library to use solely based on how well the library does the job. The real world already falls short of that (e.g. API stability and likelihood of the library still being maintained down the road are major concerns), but we should try to avoid making the situation worse than it already is.
  However, I'm not sure I agree with the GP that static linking favors popular libraries. Usually I'd only dynamic link against a library if I think it's already popular enough to already be installed.
27. Re:Not sure what the user benefits are by yarnosh · 2011-05-23 16:58 · Score: 1
  
  Because if developers choose what libraries to use mainly based on whether the library is likely to be already installed, then new but useful libraries are unlikely to become popular enough to become a standard install.
  
  So? I'd rather have a consistent development target, even if it is mediocre, than a mishmash of incomparable libraries like we find on Linux. That's definitely not a good situation to be in. You end up installing all the libraries and all of you apps look and behave differently.
  
  In addition it becomes tempting for the developer to just implement the libraries functionality, but of course that is a drain on application developer time and is likely to have bugs that were already shaken out of the library. In an ideal world, developers would choose what library to use solely based on how well the library does the job.
  Except that doesn't happen. People choose libraries for all sorts of reasons. Mainly it is just whatever you're comfortable with or what you want to tinker with or whatever aligns with your programming language of choice. Like C? GTK. Like C++? Qt. That's about as far as most developers get, I think. Better just to tell them what they have to use if they want to develop for the platform. Apple has done such a great job at this. Though Apple does support languages other than Objective-C out of the box.
  
  The real world already falls short of that (e.g. API stability and likelihood of the library still being maintained down the road are major concerns), but we should try to avoid making the situation worse than it already is.
  OS X does not really fall very short in this regard. Cocoa is a sane, stable development platform.
  On Linux the situation is pretty bad and it is precisely because there is so much fragmentation and "choice." The solution is to declare one definitive set of libraries that makes up the core that everyone uses and you can add auxiliary libraries as needed. This is kind of what LSB does, but it doesn't go nearly far enough. Linux needs a well defined target for desktop apps. No more of this Qt/GTK split. Hell, linux apps can't even decide on a sound library for crying out loud.. What is this, 1995? It doesn't have to be perfect. Just decide on SOMETHING.
28. Re:Not sure what the user benefits are by adolf · 2011-05-23 18:18 · Score: 1
  
  Right, because the sound library my applications use is exactly the kind of thing I should be thinking about as a user. Why the hell should I have to care what audio library I'm using? Why is that still an issue on Linux? It is 2011 for Chrissake.
  Indeed, it is 2011. Linux distributions could just emulate Windows 7/Vista by eliminating all fancy sound card functions altogether, while moving backward in terms of hardware functionality and at the same time and presenting a simple (but very limited) API for software to deal with.
  Would that be preferable?
  As a current Windows 7 user (at least on the desktop), who has from time to time done reasonably serious audio work under both Windows and Linux (and FreeBSD for that matter), I'd like to say that I'd prefer choice.
  YMMV.
  
  --
  Kid-proof tablet..
29. Re:Not sure what the user benefits are by whizzter · 2011-05-24 00:28 · Score: 1
  
  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 0install system like this could black-list insecure library versions until they get upgraded by the authors.
30. Re:Not sure what the user benefits are by yarnosh · 2011-05-24 01:15 · Score: 1
  
  I could be mistaken, but it is my understanding that Windows is rather sophisticated in terms of utilizing audio hardware wheres on Linux they're still trying to figure out a common way to mix audio from different applications. So I'm not saying Linux should just copy or emulate Windows, but all that "choice" is crippling Linux on the desktop. And it isn't like there's no choice on Windows. There's a dozen different libraries and APIs for audio.
31. Re:Not sure what the user benefits are by adolf · 2011-05-24 10:30 · Score: 1
  
  Windows has gone backward with audio hardware support for entertainment with Vista and 7, and has done a very thorough job of making things as dumb as possible, by crippling Directsound.
  It used to be sophisticated, and support all kinds of hardware acceleration for reverberation, filtering, occlusion, and surround sound (both actual and simulated) with just about any number of speakers.
  Now, it's up to developers to implement these functions in software, and the CPU does the heavy lifting (which admittedly isn't very heavy these days, but I buy dedicated sound hardware for a reason).
  It has pretty much killed the market for sound cards, and the development of new consumer-accessible DSP tech, since they all do the same thing these days, no matter how fancy or capable the underlying hardware is: As far as software is concerned, they all just play back audio.
  Unless you count clever hacks like Creative's Alchemy, that is. But by the time we start comparing platform-specific audio hacks between Linux and Windows the discussion has turned pretty well moot.
  
  --
  Kid-proof tablet..
32. Re:Not sure what the user benefits are by AvitarX · 2011-05-24 10:51 · Score: 1
  
  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 (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.
  
  --
  Wow, sent an e-mail as suggested when clicking on "use classic" banner, and got a fast response that addressed my msg
33. Re:Not sure what the user benefits are by WorBlux · 2011-05-24 11:58 · Score: 1
  
  Right, because the sound library my applications use is exactly the kind of thing I should be thinking about as a user. Why the hell should I have to care what audio library I'm using? Why is that still an issue on Linux? It is 2011 for Chrissake.
  Because they provide different functionality and advantages. A lot of the time distros will guess which is best for thier user. kitchen-sink or media-server distros will use pulse, slim will use just plain alsa, and and studio/artsy distros will use jack.
  
  Yes, I used Gentoo years ago and it was the biggest waste of tme of all the Linux distributions... once I got past the novelty of compiling everything tuned for my CPU. I'm getting too old for that shit.
  That's not even the biggest advantage though. Constructing from a small base up, along with being able to define system wide use flags makes it relatively easy to customize a system to your needs and expectations.
  
  More straight forward than just dragging, dropping, and renaming app bundles?
  Nope, but both packages will link or compile against the newest libraries for it's dependencies rather than keeping old and potentially insecure libraries.
  
  Or... I could copy the app bundle with my mouse. Hmmm..
  Sure if you really had the hankering to do so, but I'm not even sure of the advantages unless you don't have root access of the matching.
  
  Are any of those methods easier than just, you know, copying an app bundle? You see where I'm going here?
  Sure.
  echo "www-client/firefox-9999" >> /etc/portage/package.USE
  emerge -uD world
  Will install the daily build of firefox. Sure the first time takes a little longer, but the the second or third time you go to update it your out ahead because you don't have to go find the bundle, and copy/install it where you want it. In fact from that point on you don't have to even think about it. Every time you update the system, you will have the daily build of Firefox with it. See where I'm going here?
34. Re:Not sure what the user benefits are by mdmkolbe · 2011-05-24 12:37 · Score: 1
  
  I'm sorry but as a developer myself, my experience completely contradicts your claims. Perhaps this is because when I think of libraries, I'm thinking about things for implementing application internals (e.g. SSL, HTML parsing, B-trees, hashtables, lightweight atomic persistent storage (e.g. Berkly-DB or SQLite)) rather than GUI libraries. While I agree that very few developers would re-implement GTK or Qt, in my experience, developers do often reimplement functionality with things like strings, HTTP or HTML handling or particularly B-trees or hashtables.
  It seems you object to a "mishmash" because it leads to an inconsistent user experience. I agree that is a problem, but only for user facing libraries that affect the user experience. In other areas there is no real reason to force all developers into the same libraries. Why should we decide? I'm sorry but the world is a better place because the world didn't stop at Berkley-DB and was ready to welcome competators like SQLite and will be ready to welcome whatever replaces SQLite. To paraphrase you, "Why should we be stuck in 1995? It doesn't have to all be the same. Just use something that works."
  (At this point we could digress into "Cathedral vs Bazaar", and how competition has in the long run improved, for example, browsers despite causing developer headaches in the mean time, ... but I think we're reaching the limits of the productivity of this discussion.)
  To reiterate, I agree that consistency of user experience is a valid concern for standardizing libraries, but it isn't the only concern and it isn't always a concern.
35. Re:Not sure what the user benefits are by yarnosh · 2011-05-24 16:28 · Score: 1
  
  Because they provide different functionality and advantages. A lot of the time distros will guess which is best for thier user. kitchen-sink or media-server distros will use pulse, slim will use just plain alsa, and and studio/artsy distros will use jack.
  But almost nobody cares. That's what I'm saying. I'd rather just have it work and not have to think about it. I have never worried about the underlying sound architecture on any other major platform besides LInux. Linux makes it an issue where it should not be. It is choice for the sake of choice, not for the sake of the user.
  
  That's not even the biggest advantage though. Constructing from a small base up, along with being able to define system wide use flags makes it relatively easy to customize a system to your needs and expectations.
  Meh, it is overrated. I spent years and years tinkering with Linux, making it do what I wanted, customizing it to my "needs" until I realized that I wasn't actually getting that much done. I had fun and I learned a lot, but ultimately what I really needed was something that just worked. I also learned that sometimes it is more efficient to adapt to a system than try to make the system adapt to you. So... I use OS X. One of the least flexible systems in terms of doing things differently than Apple intended, but I love it. It just fucking works.
  
  Nope, but both packages will link or compile against the newest libraries for it's dependencies rather than keeping old and potentially insecure libraries.
  A theoretical problem, not a practical concern in the vast majority of cases. So basically Gentoo makes me jump through a dozen hoops for only theoretical gains. Yay.
  
  Or... I could copy the app bundle with my mouse. Hmmm..
  Sure if you really had the hankering to do so, but I'm not even sure of the advantages unless you don't have root access of the matching.
  The advantage is that it is way simpler and requires far less commitment. I think it is one of those things where you don't see the use in something until it is just so easy to do that you find ways to take advantage of it. Want to take an app on the go? Just copy the app bundle to a thumbdrive. No installers, no package managers, no compilers. Run it right from the thumbdrive. Could not get simpler.
  
  Sure.
  echo "www-client/firefox-9999" >> /etc/portage/package.USE
  emerge -uD world
  Will install the daily build of firefox. Sure the first time takes a little longer, but the the second or third time you go to update it your out ahead because you don't have to go find the bundle, and copy/install it where you want it. In fact from that point on you don't have to even think about it. Every time you update the system, you will have the daily build of Firefox with it. See where I'm going here?
  First of all, I'm not normally going to keep the nightly build. More often than not I'm just trying it out and I want to run it side by side with the stable version of the browser. I don't really want to commit to installing it. I just want to plunk it on my desktop and run. I cetainly dont' want wait 30 minutes for the damn thing to compile. It is an unnecessary step. Let someone else do the compiling. The compiling is what annoyed me most about Gentoo. The most I ever have to think about when using the Firefox app bundle is backing up my profile.
36. Re:Not sure what the user benefits are by tal197 · 2011-05-24 23:38 · Score: 1
  
  ... 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 requires adding a new sudo rule, and adding one automatically would be rude (the admin should be in charge of the sudoers file).
37. Re:Not sure what the user benefits are by AvitarX · 2011-05-25 00:24 · Score: 1
  
  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 it would be my preferred method of distribution, and the fact that it can bundle dependencies (I suppose as other packages) makes it a good way to distribute closed source binaries across distributions (my Loki games suffered from issues with the new glibc not too long after release for example, if the old one was bundled, perhaps as an auto compile, I wouldn't even of known).
  I really want this to be the recommended way to distribute things that don't integrate into the desktop environment (and based on the list of included feeds, think it could become that).
  It actually makes me feel the need to try and get it going for UFO:AI.
  
  --
  Wow, sent an e-mail as suggested when clicking on "use classic" banner, and got a fast response that addressed my msg
38. Re:Not sure what the user benefits are by tal197 · 2011-05-25 21:54 · Score: 1
  
  You raise an excellent set of points. So how does 0install fix this? Firstly, you don't need to find packagers for each distribution. You create one XML file, which allows everyone to run the program. When the new GCC comes out and breaks your program, you just change the version restriction in your XML: <requires interface='.../gcc'> <version before='4.6'/> Likewise with the new libpng, and bdb. Other programs will start using the newer versions, but your program will stay with the version that works. You can then work on fixing the bugs and getting a new release out in your own time, without having to rush. For example, I distribute a lot of Python programs using 0install. They all started "#!/usr/bin/env python". When ArchLinux decided that "python" would now be Python 3, they all broke. But by adding a few lines to my 0install feed, I got them working again: <runner interface='http://repo.roscidus.com/python/python'> <version before='3'/> </runner>
"Is this the end of the walled gardens..." by Anonymous Coward · 2011-05-23 08:08 · Score: 1, Insightful

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.
1. Re:"Is this the end of the walled gardens..." by tal197 · 2011-05-23 19:57 · Score: 1
  
  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).
Does this mean... by Jonah+Hex · 2011-05-23 08:22 · Score: 1

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

--
Horror & SciFi Erotic Nudes
1. Re:Does this mean... by Jonah+Hex · 2011-05-23 08:47 · Score: 1
  
  Thanks AC, I will definitely check out Secunia PSI. Anyone else want to chime in on it?
  
  --
  Horror & SciFi Erotic Nudes
2. Re:Does this mean... by DogDude · 2011-05-23 11:05 · Score: 1
  
  It's not needed. Most apps do it themselves.
  
  --
  I don't respond to AC's.
3. Re:Does this mean... by Jonah+Hex · 2011-05-24 04:17 · Score: 1
  
  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
  
  --
  Horror & SciFi Erotic Nudes
Probably won't gain wide acceptance by ndogg · 2011-05-23 08:27 · Score: 1

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 is converted to DEB, it's still going to be installed into /opt instead of /usr.)

--
// file: mice.h
#include "frickin_lasers.h"
1. Re:Probably won't gain wide acceptance by vlm · 2011-05-23 08:50 · Score: 1
  
  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"
  
  --
  "Science flies us to the moon. Religion flies us into buildings." - Victor Stenger
2. Re:Probably won't gain wide acceptance by dkleinsc · 2011-05-23 08:51 · Score: 1
  
  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 fall flat on its face as soon as it got anything other than a list of well known setups.
  For instance, let's say I build a tool that understands where Red Hat / CentOS, Fedora, Debian, Ubuntu, SuSE, and Slackware all like to put stuff. If I put this on a Arch or Gentoo or SourceMage box and it's going to promptly fail. So while my tool would be possibly handy for those others I just mentioned, it still doesn't solve the problem.
  Short version: Different boxes => different setups => different correct configurations => different tools to set up those configs.
  
  --
  I am officially gone from /. Long live http://www.soylentnews.com/
3. Re:Probably won't gain wide acceptance by yarnosh · 2011-05-23 09:45 · Score: 1
  
  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.
4. Re:Probably won't gain wide acceptance by X0563511 · 2011-05-23 09:48 · Score: 1
  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:
  
  debian-control - a simple file with the package version number
  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)
  control.tar.gz - contains scripts for install, configuration, uninstall, etc - as well as the metadata file that says what the package is etc
  This is the difference between a distro package (.deb, .rpm etc) and a simple archive (.zip, .rar, .tar.gz) which you seem to think they are.
  --
  For large sets, this will be our guide even unto death, for the LORD will work for each type of data it is applied to...
Isn't this basically what Java was supposed to do? by Anonymous Coward · 2011-05-23 09:07 · Score: 1

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.
We could create a massive install arch., or... by istartedi · 2011-05-23 09:25 · Score: 1

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.

--
For all intensive purposes, "whom" is no longer a word. That begs the question, "who cares"?
Also known as... by RightSaidFred99 · 2011-05-23 09:47 · Score: 1

ClickOnce for Linux. Not exactly a new idea.
self-contained application bundle by nurb432 · 2011-05-23 10:10 · Score: 1

Like PCBSD does already?

--
---- Booth was a patriot ----
Is this... by fyngyrz · 2011-05-23 16:18 · Score: 1

...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 without being weighed down by almost instant malware problems.
Like it or not, Apple's found one of the significant inflection points for getting software to its customers; make it safe, apply strict limits (sometimes limits that really aren't very compatible with the ideas of liberty we're supposed to revere), and encourage low cost.

Sadly, things now look like they're heading in exactly the opposite direction.
That's exactly right: things are heading in the opposite direction. When it comes to consumer devices, you're going to be dealing with what makes the masses comfortable; and that will very rarely be technically or socially optimum solution(s).

--
I've fallen off your lawn, and I can't get up.
Re:Isn't this basically what Java was supposed to by tal197 · 2011-05-23 20:01 · Score: 1

It's perhaps more like Java Web Start in concept, but it works with any language (including Java). There is the 0export tool to create self-extracting bundles, but yes in the normal case it assumes that 0install will already be on the machine.
Give me Debian package management any day by jabjoe · 2011-05-23 21:01 · Score: 1

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 update every program built statically against it. Use version number as part of the filename and have a sym link without the version number to the latest version. If something needs a specific version, it can be built to link to that not the latest. You can do as many version levels of this as required. Seriously, this is much better centrally managed and updated. You can even list all applications that use the file, even before anything is installed. I wouldn't go back to an application folder system if you paid me to. Windows has some central management with the manifest stuff and add/remove programs, but compared with Debian package management, it's an over-complex mess or a fraction of the power. Other package manager might be as good as Debian's, but so far, none have impressed me as much.
1. Re:Give me Debian package management any day by tal197 · 2011-05-23 23:53 · Score: 1
  
  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 better. The system automatically installs a library version that works with A and B, if possible, or refuses to install B if there is no such version.
  0install combines the best of both systems: you can get software from anywhere, have multiple versions at once and there are no conflicts. But you also get dependency handling, updates and shared libraries. It automatically installs a library version that works with A and B, if possible, or installs two different versions of the library in parallel if not.
2. Re:Give me Debian package management any day by jabjoe · 2011-05-24 03:51 · Score: 1
  
  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) overrides the other even if it's not overwritten it. You could hack something up with chroot, but it all starts getting ugly. Unless I'm missing something of course.
3. Re:Give me Debian package management any day by tal197 · 2011-05-24 04:17 · Score: 1
  
  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
  $ 0alias convert-text http://text-converter.com/convert
  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 needed it.
  It's similar with libraries. A library's files are only in scope for programs that depend on that library.
Re:Do not trust. by tal197 · 2011-05-24 00:27 · Score: 1

0install does not touch any files outside of ~/.config/0install.net/ and ~/.cache/0install.net/ by default, and it won't let packages change things at install time either. This is necessary so that it can be used with sandboxes.
The only exceptions are that it will make a configuration change that you request explicitly. For example, if you ask it to add Firefox 4 to your Network menu then it will do that, or if you ask it to add a "firefox4" shell command to run it then it will create a "firefox4" script in your $PATH.
You might be interested in the EBox sandboxing demo (the challenge is to create a package that accesses a user's files without the user's permission).
I for one won't use it! by DadLeopard · 2011-05-24 08:05 · Score: 1

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!