Comment Re:Worth a try? (Score 1) 61
I have an idea the
If you try to install a program that needs a library that is only available through your distribution, then 0install will offer to install it using PackageKit, if PackageKit is available.
I have an idea the
If you try to install a program that needs a library that is only available through your distribution, then 0install will offer to install it using PackageKit, if PackageKit is available.
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.
Of course, that's not an issue for programs written in Python, Ruby, Java, etc.
For C, you can also publish a source version and let the users compile (with 0install handling the build dependencies). Also, if someone wants to set up a build farm for a particular platform, they can use these source packages to create binaries automatically (e.g. for PPC binaries).
Producing separate binaries for different distributions (e.g. Ubuntu and Fedora) isn't necessary; one binary should work everywhere. The exception would be if the distributions compiled the libraries with incompatible options, but that doesn't tend to happen these days. If it does, specify the dependency as distribuion="0install" to force the use of a 0install version rather than the distribution package.
- It's designed for browser support, which is necessary to prevent phishing attacks and improve ease of use. It's hard for your browser to log in to OpenID sites (e.g. the Firefox OpenID plugin(s) fail on several sites which use fancy login UIs).
Auto-login is always problematic in security terms, even if it is exceptionally convenient.
I don't think anyone is suggesting auto-login (the browser logs the user in without action from the user). The issue is whether the browser can provide a login button in the chrome which, when clicked, allows the browser to handle the rest of the process securely (e.g. not displaying any random phishing site that the web-page tries to send you to). If you need to authenticate, the browser needs to ask for the password in a way that clearly shows it's OK to enter it (e.g. in a clearly-marked popup).
I think the main differences are that it uses email addresses instead of an URL (which people don't "get" as being your identity token)
Once it's ready (supporting primary IdP's), the ID doesn't need to be an email address (just an ID with an email-like structure).
and it doesn't give the authorities full power to access your accounts (since the private key for authentication is stored on the browser).
I don't think so. That key is only accepted because it's signed by your IdP, which can just as easily sign another one if the authorities request it. The main advantages I see are:
- Verifying a login doesn't tell you're IdP who signed in to the site. The site only requests the IdP certificate, not your personal one.
- It's designed for browser support, which is necessary to prevent phishing attacks and improve ease of use. It's hard for your browser to log in to OpenID sites (e.g. the Firefox OpenID plugin(s) fail on several sites which use fancy login UIs).
- Putting more of the logic in the browser simplifies the protocol (although they seem to be adding extra complexities quite fast).
... 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).
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.
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).
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.
I think there's a world market for about five computers. -- attr. Thomas J. Watson (Chairman of the Board, IBM), 1943