The ROX System Monitor displays a large window containing two bar charts. One shows the Free/Used space on each mounted filesystem, and the other shows a list of processes with Shared/Unshared/Paged-out memory. A popup menu allows processes to be paused, resumed, or killed. The aim is to show the information you normally want from a system viewer without the clutter.
ROX-Session is a simple and easy-to-configure session manager. It allows you to change window managers without logging out (and copes with window managers crashing) and provides a graphical configuration box for your X settings (default font, cursor blinking, mouse behavior, etc.). The default session starts ROX-Filer managing the background and one panel, but it can be easily reconfigured for other purposes.
Archive is a fully drag-and-drop multi-format archiver. Drag a directory onto it to create an archive. Drag an archive onto it to extract to a directory. It can also compress and decompress streams (for example, you could drag a .gz file onto Archive and from Archive into your text editor).
Zero Install is a decentralized cross-distribution software installation system. It allows software developers to publish programs directly from their own Web sites, while supporting features familiar from centralized distribution repositories such as shared libraries, automatic updates, and digital signatures. It is intended to complement, rather than replace, the operating system's package management. 0install packages never interfere with those provided by the distribution.
0release is a program to generate source and binary releases automatically. With minimal configuration, 0release will generate a source tarball release candidate, build it to create a binary archive, upload them to your Web server, check the uploads, and tag the release in GIT and update the version number. It can run unit-tests and custom actions, such as building documentation, etc. For Zero Install users, it can also upload a signed XML metadata file about the release, allowing these users to upgrade automatically. Releases are signed with your GPG key.
Re: Two Holes and complex builds?
> 1) Setuid()/setgid() binaries?
> Certainly root isn't running any installation scripts written by unknown
> parties, but a non-trivial class of applications exist (email) that tend to
> rely on setuid()/setgid(). I took a quick look at my system here and Mutt
> and KDE are the standout setuid()/setgid() offenders.
Mutt isn't setuid here (Debian/unstable). Any idea why it would be? For KDE, the only thing I can think of is kpppd. The solution is for such programs to go through sudo, giving the admin a central point to configure all root access. Of course, sudo itself can't be in Zero Install (we don't allow setuid binaries under /uri/0install, for obvious reasons).
As an admin, this means you don't have to worry about packages installing setuid binaries behind your back, of course.
> 2) Hacked originating sites =
> comprimised 0install clients. GPG keys are nice and all, but how many people
> actually walk around with their GPG private keys on a floppy disk or USB
> keychain drive? IIRC a few months ago there was a site/source comprimise where
> the MD5 signatures matched the tar but the binaries had a trojan inserted.
Modifying MD5 sums to match binaries is trivial if you have access to the site (to be secure, you need some way to verify the MD5 sums themselves are correct, which zero install does with GPG).
As for breaking the GPG: yes, you could find out who admins the site, find their personal machine, get through the firewall/NAT, break into their machine (assuming they're running sshd on their laptop), install a keystroke logger, get the GPG passphrase and private key, break into the server and upload your trojaned build.
But it's a lot of work. Consider that most software doesn't come with a digital signature at all, and most people don't check them even if they do, and zero install will usually be more secure.
> For that matter, the 0install system can be used as a kind of Denial of Service
> engine in a "dumb-user" environment: all one has to do is set up
> a teaser website where the list of dependencies includes huge lists of
> large files; if left unattended at home/small/medium size sites it can
> saturate the Internet access pipe until the disk is filled.
That's true of your web cache, too, of course. Note that the user has to run the software (and leave it running while it downloads everything), the daemon process doesn't follow dependancies itself. For most home machines, you could achieve the same thing by telling a user to run 'wget -r' on a big site.
(you could also put per-user quota limits in the fetching daemon, but the system isn't big enough that we've had a problem yet)
> 3) Complex builds can strike the system
> down. Ex: PHP4 with all its extensions.
> Say extension #1 in PHP4 depends on
> liba; extension #2 in PHP4 depends on
> libc, which in turn depends on libb and
> liba, and for whatever reason two
> different versions of liba are specified
> between the two extensions. Boom.
However, it would be 'Boom' for everyone, not just your system, so it would get fixed ;-)
Mike Hearn (autopackage.org) is working on implementing the solaris linker behaviour, which allows this situation without problems.
Re: Internet Required
> So, since a very large number of users
> can't use the Internet for software
> distribution, what about them? There's
> a reason people buy CDs of software
> versus doing network installs, even for
> single, small apps.
> Unless 0install has a clean, easy,
> simple way of handling these cases as
> well as the network, it's going to force
> and require multiple ways of
> distributing software.
The layout of the cache directory (/var/cache/zero-inst) is fairly simple, with one directory per site. So, I upgrade the cache on my (non-networked) laptop by copying the /var/cache/zero-inst/rox.sourceforge.net directory across on a zip disk.
A CD based installer can easily do something similar.
You need to be root for this, of course, but that's no worse than RPM, etc.