0install Reaches 2.0

tal197 writes "Zero Install, the decentralized cross-platform software installation system, announced 0install 2.0 today after 2 years in development. 0install allows authors to publish directly from their own web-sites, while supporting familiar features such as shared libraries, automatic updates, dependency handling and digital signatures. With more than one thousand packages now available, is this finally a viable platform?"

Comments

Over 1000?!

[L4t3r4lu5]

That's 1/9th any kind of milestone I will accept as important or impressive. Come back later.

Slashvertisement?

[UnoriginalBoringNick]

As the third of tal197's four slashdot submissions was entitled "Zero Install Project Makes 1.0 Release", can I assume this is just an advertisement?

Re:Slashvertisement?

[Sez Zero]

No; 0install isn't a commercial project.

You know you can advertise a non-commercial project, right?

Re:Slashvertisement?

[dcooper_db9]

The best kind of ad, in my opinion. One of the reasons I follow slashdot is to learn about new developments in IT.

A succesful project needs to attract enough developers to keep it going, and that means promotion of one kind or another. The commercial world can buy advertising. Slashdot is providing a valuable service by helping non-profit projects reach out to potential contributors and consumers.

This project is interesting to me because it tackles a problem I'd been considering recently. I use Canonical's repositories to update my software. In many cases Canonical does not include the most recent version of an application in their stable repositories. For example, I found that the stable repositories were a full two releases behind the stable release of KDE. That meant it was not just missing new features, but also missing important bug fixes. The repositories also have Samba 4 Alpha 18 aproximately three months after Samba 4.0 was released. Sometimes I can get the updates from backports, other times I have to go looking for a PPA. Sometimes the newest release isn't even available from a PPA or it's impossible to determine if the PPA is trustworthy.

I'm not knocking Canonical for this. They provide an important and valuable service by reviewing each project and (hopefully) addressing problems before including them in the stable repositories. Many smaller projects have limited resources for testing and while I trust their intentions they might miss something Canonical would catch. But in the case of KDE and Samba, I trust that both organizations have done a reasonable job of testing before they release a stable version. I'd prefer to bypass the central repositories and download new versions directly. It appears that with Zero Access installed I could do that (for supported projects) easily and with minimal risk to my system.

Re:A viable platform

[shadowrat]

i think the parent was pointing out that apple is never going to allow a 3rd party package manager on ios. because of their success, it looks like the other players (ms, google, etc) are trying to get a similar ecosystem. So, while the project seems like a good idea, the bleak future may be devoid of platforms where such a project could be installed anyway.

Great Ideas Fail All The Time

[Anonymous Coward]

It's similar in concept to a decentralized app store or repository. It sounds like a great idea. It sounds like it free your system from the "clutches" of your distro's repository.

But, like many other great ideas, it fails in the cold daylight of reality.

In order for it to work, the software developer has to not only publish their software on the Zero Install system, they have to publish their software for ALL the distros on it. But, we all know well that most software developers regard this as far too cumbersome an undertaking and will instead publish only a single or couple of binaries. That leaves out countless other distros and causes the Zero Install concept to fall apart.

But, there's another issue. Most distro repositories don't simply have 1,000 apps. They have multiple thousands of apps. And all of those apps are compiled specifically for that distro and therefore "guaranteed to work" with your distro.

Simply put Zero Install lacks enough apps, for enough different distros, for anyone to really care about it. It's a niche player in a shrinking pool.

I am reminded of an RPM based alternative package manager distro that was "so much better" and was adoopted by several big players. It might have had live kernel patching too. Yet I cannot remember the name or find it with my Google foo. It was supposed to change everything because it was so much better and, although I'm sure it's still around, "nobody" uses it.

Re:Great Ideas Fail All The Time

[Yfrwlf]

You're confused and don't understand what Zero Install is. Maybe the feature list needs to be worded better, but it is infinitely better than "an RPM alternative" because it can run ALONG SIDE an existing package manager. Zero Install can be used on ANY DISTRO and can ADD TO that distro, so it will expand the number of packages that are accessible to users. If I release my software for Zero Install it means any user will be able to install it easily, get automatic updates, uninstall it easily, potentially share libraries with other programs, etc. That is better than a bunch of binaries laying around because you don't get all those features and nice cleanup with just releasing an archive of a binary your users run, and then you'd have to implement automatic updates in your binary as well.

So who cares if Zero Install doesn't have every app under the sun yet, the key part is that every app it does have will be available for anyone to use in any distro as long as those files and dependencies are hosted.

No more "you can't run this because you don't have glib.blahblahpoop", as long as it was packaged with the dependencies it will work for all Linux users.

Linux needs to be a proper single platform to unify community software efforts. I don't want my software to go unused and to not be of help to anyone just because 1970's UNIX fragmentation BS gets in the way of things.

Re:No.

[Timmmm]

I don't think it is designed to be the one-repository-to-rule-them-all, debian style. In fact I think it is partly a reaction to the fact that that model doesn't work well in many cases.

Interesting technology, needs PR

[loufoque]

The technology is interesting. It's fully decentralized, works even on Windows, offers Mac-style drag and drop images, uses a full SAT solver for dependency resolution...

What it needs is better marketing.

Re:What a name

[Jeremi]

I understand the benefits of shared libraries, but storage space is dirt-cheap today and I think a lot of problems might be solved simply by letting lots of pieces of software bundle their favorite versions of dependent libraries.

Or, how about this: Instead of linking to shared libraries by their filenames, applications specify the shared libraries they'd like to link to via md5 hashes of the libraries' contents. The linker checks its shared-library database-index (which could just be a directory whose directory-entries are md5 hash codes) to see if it has a shared library with that md5 hash installed; if yes, it links the application process to it; if no, it auto-downloads the shared library with that hash from the web repository, installs it, and then links the application process to it.

The advantages would be:

No library collisions, ever (well, to the extent that md5 hashes are unique, anyway).
No version mismatches, ever (each app will always run using the libraries it was built against, and no others).
No mucking about with LD_LIBRARY_PATH (as all shared libraries are auto-stored for you
No manually installed missing libraries (they will instead be installed as necesary, on demand)
No space wasted by multiple copies of the same library present on your disk at once

Some possible disadvantages:

No way to "patch" behavior of multiple applications by upgrading only a shared library they link to (you'd have to upgrade each of the applications instead, so that they reference the new library version's md5 hash)

Possible security issues from auto-installing shared libraries with malicious code (although arguably you either trust a developer enough to install his program, or you don't; the mechanics of how different parts of the program are installed aren't necessarily relevant)