Linked by Thomas Leonard on Tue 16th Jan 2007 00:32 UTC
General Development In the Free and Open Source communities we are proud of our 'bazaar' model, where anyone can join in by setting up a project and publishing their programs. Users are free to pick and choose whatever software they want... provided they're happy to compile from source, resolve dependencies manually and give up automatic security and feature updates. In this essay, I introduce 'decentralised' installation systems, such as Autopackage and Zero Install, which aim to provide these missing features.
Thread beginning with comment 202127
To read all comments associated with this story, please click here.
Great article, but...
by Moochman on Tue 16th Jan 2007 12:10 UTC
Moochman
Member since:
2005-07-06

This article was really well thought-out and delivered--it's not just some publicity piece. It's clear that the developer/author has taken a lot of time to think about installation and use cases, and is making the next generation of Linux installation technologies a reality. I especially like the idea that different versions of libraries should be matched to different versions of programs, albeit without the needlessly inefficient app-folder method. I wish the author the best of luck, and hope that Zero Install catches on!

However, one flaw I see in your implementation is the cryptographically-derived naming of folders. In the beginning of the article, you point out that non-hash-derived identifyers are much more easily user-readable, yet later on you claim that end-user "Alice" will be willing to go to the Gimp homepage, look up the appropriate hash and compare it to hash-name of the folder that "Bob" installed on the hard drive. Yeah, right! Not only does that sound like the exact opposite of the user-friendly goals you set out with, but it's also incredibly insecure to assume user vigilance as a means of security! All the hash-naming of folders would serve to do is make the end user more confused.

Likewise, the certificate verification dialogue box doesn't seem too user-comprehensible or foolproof--especially considering that the user is told the database is "Unreliable"! A whiteboarding system (either independent or distro-specific) would be much more reliable, but of course then the sytem is practically as centralized as was supposed to be avoided!

It seems as though achieving ease-of-use, decentralization, and security all at once really is an elusive goal...

Reply Score: 3

RE: Great article, but...
by tom1 on Tue 16th Jan 2007 12:38 in reply to "Great article, but..."
tom1 Member since:
2005-07-12

However, one flaw I see in your implementation is the cryptographically-derived naming of folders. In the beginning of the article, you point out that non-hash-derived identifyers are much more easily user-readable, yet later on you claim that end-user "Alice" will be willing to go to the Gimp homepage, look up the appropriate hash and compare it to hash-name of the folder that "Bob" installed on the hard drive. Yeah, right!

I should have been clearer: the installation system does this on behalf of Alice. It gets the hash from the XML file describing the Gimp; all Alice has to do is find the link to the XML file.

Likewise, the certificate verification dialogue box doesn't seem too user-comprehensible or foolproof--especially considering that the user is told the database is "Unreliable"!

Right. Ideally, there should be multiple feeds for this information. Currently, there's only mine, which is "unreliable" because I don't have the resources to check out people's keys or offer any compensation if I'm wrong.

This is certainly an area where a commercial company could add value, but without having to start their own distribution (as they'd have to do now).

Reply Parent Score: 2

RE[2]: Great article, but...
by Moochman on Tue 16th Jan 2007 22:17 in reply to "RE: Great article, but..."
Moochman Member since:
2005-07-06

I should have been clearer: the installation system does this on behalf of Alice. It gets the hash from the XML file describing the Gimp; all Alice has to do is find the link to the XML file.

Aha ok. Although I still feel like having some sort of real-name identifier there would help the administrator find the folder in case of a problem. Why can't the directory name be the program name (as opposed to the URL)--i.e. gimp-2.3-- so it can be installed off of CD? I don't understand what about making the folder a hash makes it more secure than, say, storing the hash information in a separate protected file within the program's folder.

Right. Ideally, there should be multiple feeds for this information. Currently, there's only mine, which is "unreliable" because I don't have the resources to check out people's keys or offer any compensation if I'm wrong.

Aha. Cleared up, although as it is now it's clearly not a long-term solution. My only gripe with the model is that in an office setting, users might not be able to install any software they wanted, since they would be probably be locked into a list of software on a predefined whiteboard server. However, I suppose that the problem of "missing software" would probably be much scarcer than in today's repository model, since hosting such a whiteboard server that certifies URLs rather than individual versions of programs is undoubtedly much easier than having to package and test every new iteration of software by hand.

Reply Parent Score: 1