Slashdot Mirror
Zero Install: The Future of Linux on the Desktop?
SiegeX writes "Zero Install ,which is apart of the ROX desktop environment is not just a new packaging system, it's a whole new way of thinking; a way that I believe is exactly what Linux needs to become a serious contender for Joe User's desktop. Zero Install uses an NFS to both run *and* install apps from. The apps are all self-contained in their own directory; binaries, docs, source code and all. Once the app has been downloaded its kept in a cache from that point on to minimize delay. The beauty becomes apparent when Zero Install is combined with ROX which runs the application by just clicking on the directory it was installed to. Deleting the application along with all the other misc files is as simple as removing the directory it's contained in. This method of partitioning applications in their own directories also allows installing multiple versions of any application trivial. This is something even the greatest of technophobes could understand and use with ease."
Someone should really point this out to Steve. I think using this type on installation on Macs would increase useability by leaps and bounds.
Karma: SELECT `karma` FROM `users` WHERE `userid`=138474;
Slashdot has previously covered Rox here.
But one thing I wonder about Zero Install: what if you launch an application, it needs a piece that you don't have cached, and the server hosting it is down? Is it possible for a maintainer to unpublish an application?
For anybody. It emulates the best aspects of the mac's "packaging" system (bundles) while also making it easy to get new stuff.
/software/openoffice /usr/software to install" instead of ./configure && make && make install. :)
... assuming they get over that, I'll be very happy once this is released.
Hopefully, this takes off in more of the 'newbie oriented' distros so that we can say "Just type cp
I still would like to know how they plan on fixing library dependencies, but
I *love* my PowerBook G4. Seriously, Apple has had this for years going back to the old System 9, 8, 7, etc.... it's nice to see someone major is finally trying to copy 'ole Steve Jobs's team. If you ever wondered what life would be like without the Windows Registry, this is it.
If construction was anything like programming, an incorrectly fitted lock would bring down the entire building...
Sorry folks, we have the technology right now to support multiple version of libraries at the same time, disk space is no longer an issue, and it just makes logical sense to keep everything related to an application together in a logical unit that can be administrated with minimal effort. The /bin, /lib, /usr structure has to go. Applications locking in to configuration files across the file-system has to go. It's simply painful to use, and something like Rox here is the first step in the right direction.
...
Not like this step hasn't been taken in the past by multiple other software solutions
It has been implemented in OS X. This is what happens when you drag a .app file (really, a folder. try to cd into one sometime) and copy it to any point on your hard disk (typically /Applications).
Reminds me of an old joke...
Microsoft: Where do you want to go today?
Linux: Where do you want to go tomorrow?
BSD (in this case, OS X): Are you guys coming or what?!?
After you download it, its cached. Basically you have to download the app anyway to run it. If you download say the new version of say GAIM it would be fantastic. I'd just drag it from the browser onto my desktop and then click it. Apt-Get is for nerds like you. Regular people want to accomplish a task in the least amount of steps. If you can bring the task to two steps, click n run, or drag n drop, this is what people want.
People don't exist to serve systems, systems exist to serve people.
Could there be a difference here? Hopefully they are not putting code into virus-writable directories, as often happens on Apple.
No, actually, not at all. Most programs on your windows pc that are 'installed' into Program Files still have obscure registry entries, and may require dlls and such in the \winnt and \winnt\system32 directories. You cant just remove a progam from the 'Program Files' folder, and have it gone.
"The natural progress of things is for liberty to yield and government to gain ground." - Thomas Jefferson
This sounds great. Im no linux guru and the hardest thing I find is to install a programme that requires other files but one version is required for one app and the other for another. In this age disk space is trivial and stability and ease of use much more important. Granted many people like tinkering with their systems but for me I just want to get my work done..(and then play games).
Also consider this, for the average person not only is this a more secure form of distribution, its more efficient, its easier, and for 99% of files people will download it just works. Unless you are going to compile your kernel or do serious changing to your machine you wont need apt get. Just to download GAIM, or KWORD or whatever, you only really need to drag drop and run, or even just click and run. I see nothing wrong with this, and you could give the browser enhanced UI features to embed some of the apps into it in the future.
People don't exist to serve systems, systems exist to serve people.
Flame as you want, but .Net assemblies not published to the GAC (Global Assembly Cache) are exactely like that: all of the application files are kept under a single directory and all you need to setup the app is a "xcopy" of its files.
.Net still have to catch on into the desktop, it is very much real on the server side. Gotta love it!
Delete the directoty and the app is gone.
This is here now, and altough
It's still very much like this in Windows, in fact, with the "Program Files" directory often containing everything (although "Documents and Settings" is becoming more used for user settings storage). Personally I like the idea. I've always been confused trying to locate various files which belong to a single application in *nix.
Most *n?x apps seem to store all the per-user settings in a dot-file or dot-folder in the user's home directory. In Windows, they're often strewn about in at least three places: C:/Documents and Settings/Me/Application Data/, C:/Documents and Settings/Me/Local Settings/Application Data/, and HKEY_CURRENT_USER in the registry. In addition, a lot of the apps I have installed on my Windows 2000 machine came bundled with peripherals, where the app and a device driver came as part of the same install, the app in C:/Program Files/ and pieces of the driver in various folders in C:/Windows/.
How does Rox handle it?
Bitch to whoever decided that that app should have an installer.
If MS Office can be a drag and drop install, almost anything can.
--
the strongest word is still the word "free"
Why can't we list repositories on a P2P network, let a user connect to this network to constantly update their respositories, in the same way that emule works?
I've tried eMule. I don't want to have to sit in a queue and wait for 1,759 other people to get something just because I told the file manager to start an app. What improvements would you make to the architecture of the network? No, BitTorrent doesn't scale well for small (<10 MB) files.
Besides, P2P doesn't work well for residential or university dorm users who can't take incoming connections.
As long as CPUs are so fast, RAM is so cheap, and disks are big ... and the net is relatively slow, thin clients will have only thin application.
.NET), but there is no need for a thin client to run a word processor or mail client or www browser. Religious wars aside, our desktop software is quite capable, and getting more so.
I *do* remember the good old days of VT100s, and they worked great; the thing that displaced VT100s in our research group was *Macintosh* --- those wascally little SEs and the occasional MacII had such nice software onboard, they were a delight to use. The Macs were in turn partially displaced by DEC RISC machines, which cost more but brought a lot of horsepower to the desktop.
We used to use a Beowulf in our current project, but the blasted Pentia got so fast there was no point. Our real-time processor now relaxes on a single machine.
It's not so hard to imagine the pendulum swinging back to thin clients (perhaps in the guise of wireless PDAs, or in a more sinister form via
Everything was just a matter of folder installs during the DOS days. You copy a binary and run a binary and delete a binary.
Believe it or not part of the reason why M$ went with the setup.exe installation was because software was harder to distribute around requiring the setup binaries.
Funny how things come around full circle.
Never underestimate the dark side of the Source
This sounds to me as though it has some similarities to the way the old Acorn Archimedes used to work (What? Oh, it was quite big over here in the UK ;)
An 'application' looked like a single file that started with a '!'. It ran as though it was one file, copied and moved as though it was one file. If you used a modifier to open it (Ctrl-click, or something similar), though, it actually opened up as a folder. The app was really made of a number of files - the icon that the application/folder would have, the actual programs, any config files, a script that was run when the program was launched, and another script that would be run as soon as the OS 'saw' the app.
Part of the config would tell the OS what file types the app could handle, so as long as the app had been 'seen' (ie, it's parent folder had been opened), the filetypes would be recognised until the next reboot.
PigPog.
Actually, it hasn't. Ask any Mac pro; applications started making "library" files that went into the System folder(or worse, programs like Norton Utilities insisted on putting libraries into the Extensions folder, which was not what Apple told developers it was for). Apple caved in and 9.x started sprouting "Application Support" folders, a "Libraries" folder, etc. Developers just couldn't wrap their brains around the single-file, applications-don't-mess-with-the-system-folder model. Often times, commercial programs would blatantly disregard Apple's filesystem guidelines. Often times extensions has such weird names, Cassidy&Greene developed an extension manager with a database of all the known files so you could figure out what the hell stuff was.
While you tout OS X as better than Linux or Windows, as an experienced long-time Mac user I saw OS X as a step down from the old MacOS with regards to filesystem simplicity. Applications now install stuff into zillions of different places. Virtually none of their installers ask if you want to install just for your user(ie using your Library, Application etc folders), or install system-wide(a few- VERY few- do). Application installers that have no business needing my password ask for it; why does Acrobat reader need sudo to install itself into Applications? Answer- it doesn't, but it's probably saving some prefs file somewhere it shouldn't.
Even worse...you can install packages using a "package system", but Apple will be damned if they'll give you a way to UNINSTALL a package, system or otherwise. Want to remove all the localization crap you forgot to turn off during system install? You have to download a third-party app to remove almost a gigabyte of files from your system, instead of just going into a "Software" panel and clicking remove. Windows has had it for years, with its only flaw being that it calls the developer's uninstall program, which often times doesn't work, especially if you've deleted the app folder but nothing else.
Another side effect of the multiple-files problem is added complexity; the # of files in the filesystem has ballooned enormously, because instead of an application being one big file with a resource fork, it's now at least 3 folders, and often times hundreds(or even thousands) of files. Moving an application used to be easy- you moved one big file, the Finder just did a straight copy very efficiently. Now it has to copy hundreds of small files, so it takes forever(and amusingly, copying just a bunch of raw non-app files takes about 5 times longer in the Finder than it does via cp or ditto).
Don't get too uppity about not having a registry. OS X uses a number of preference files, and even though they've changed to XML and the like, users are seeing the same problems with OS 9- corrupt preference files causing odd behavior. Remove the naughty pref file, things start working again. There are now third party utils that specialize in checking these prefs; if they can do it, why can't it be part of the bootup process?
Oh, and lastly- Apple has made it even more difficult to make a boot disk for your mac to do disk maintenance. It used to be you just copied over your system folder, removed all the extensions, control panels, prefs, etc you knew you didn't need. Now? You need some stupid shareware program to do it, and half of 'em still haven't been updated for 10.3.
Please help metamoderate.
Microsoft had this in the very beginning. It was called DOS and DOS applications were completely self contained. When an application was installed all of its files remained in the applications own directory. To move an application, even to another PC, you simply copied the directory. To delete the application you simply deleted the directory.
.NET strategy. One that installs applications into their own directory for easy management and removal. A new system that they conveniently choose to forget, is just like the system they used in 1982! Ooh, ahh. Consider me un-impressed!
Then Microsoft got smart (too smart for their own good) and decided it was more "efficient" to use shared libraries and that all such libraries should be kept in the %SYSTEMROOT% folder. This meant that applications stored files in one directory, libraries in the system directory and configuration files who knows where. That's better, isn't it?
After that Microsoft decided that it was too "troublesome" to have all of these separate configuration text files. They got smart here too (again too smart for their own good) and decided that it would be so much "better" to have all the settings in a single monolithic and monumentally fragile registry. (Watch out Gnome)
After all that, installing and removing applications became a nightmare. So they decided that it would be best to have a package management system that managed all installations and removals. They established standards that required the proper use of this package management system for the application to be "Windows certified". Unfortunately for them the package management system isn't so great, especially when it comes to the registry and while many vendors do obey the "Microsoft standard", many do not. In fact, the worst offender for not properly using the package management system, and there by polluting PCs with monumental amounts of cruft, is Microsoft themselves.
So, now Microsoft is trying to implement an "even better" system with their
The main one is that there are actually two installation systems being discussed in the article:
ROX application directories can be made available via Zero Install. In that case, running the application is a lot like running a program from a network share (but more aggressively cached). Or, you can DnD them onto your local disk manually (without Zero Install).
You can also use Zero Install for non-ROX type applications.
Secondly, when we say that application directories are self-contained, we mean that a single .tgz download corresponds to a single installed directory. Application directories can (and do) still depend on shared libraries (possibly other application directories).
Without Zero Install, after installing an application by drag-and-drop, running it may tell you that you need to install some other library before it will work.
With Zero Install, the application just tries to access it from its fixed location (URI) and it gets fetched.
The trouble stems if you have some kind of base package, which is extensible via some kind of plug-in architecture, traditionally implemented with DLLs under Windows, or shared object library repositories under Unix and varients. Do the plugins form their own "application" or are they part of the application which they extend? What if I want to manage groups of plugins from a common source, independent of the applications extended? Do all applications have to be so isolated that they can only rely on a common base operating system that can't be extended by third parties (which would then be locked into their own application spaces)? What about multiple users sharing the same applications: will their saved files be intermingled?
Blech. Sounds like the cure is worse than the disease.
But, nevertheless, the idea of organizing independent applications in a convenient hierarchy is a desirable one. The trouble is that the traditional filesystem only offers a single hierarchy in which to organize them and so we struggle to determine the best hierarchy to use. We really need to organize sets of files that compromise a related unit ("file set", if you will, and "application file set", for the specific case of end-user applications) in multiple hierarchies: a new one created for the file set being added, and existing ones that the file set affects.
"Symlinks!"
What's that?
"Symlinks!"
Well, O.K. symlinks kind of solve this problem: pick a cannonical location in the file system for your file set and symlink secondary links to the appropriate files. This is a good idea, and has been used for ages to separate the reference to a file in the filesystem from where it is actually stored, but there are drawbacks:
1. Symlinks are one-way. Typically you'll have an application directory full of files and subdirectories, and a bunch of links into that directory tree. What happens if you move or delete entries? Oh, woe to the who has broken symlinks.
2. The context in which the symlink is interpreted may restrict where the target may be. Consider startup scripts added under /etc/rc.d/... They' don't do much good if they link to files in filesystems that haven't yet been mounted. Some restriction to where things have to be canonically installed depending on how and when they will be used is apparent. Fortunately, we generally don't have complicated hierarchies of what parts of the filesystem are mounted, but rather just a few: boot, locally mounted, remotely mounted. So, this problem is managable: we can inagine /opt and /usr/opt: the former available on the root filesystem.
3. Application interaction. The trouble with having one application extend the capabilities of another (and the base O/S can be considered as "one application" from the perspective of third party software providers, other than the O/S provider) is that adding, moving, or removing files can or should affect running applications. Ideally, an action which would leave a symlink dangling should be picked up by any running applications that might care and either delayed until the application can cope, or vetoed. (And, I suppose, --force and --async are your friends here). Current practice in most package managers is to have pre-install, post-install, pre-deinstall, and post-deinstall scripts that try to deal with this inter-application issue. The problem is two fold: (1) the things necessary to be communicated to other applications are varied, and (2) the manner in which they are communicated differ between applications (never mind different versions of the same application). Ideally, the inter-application interface that deals with new, removed, or relocated external files should be (a) thin, and (b) supported by t
You could've hired me.
So if I'm right, part of this article is about something akin to OS X packages? You install an application by dragging-dropping it somewhere (preferably the Applications directory) and un-install by unceremoniously dropping it in the waste basket.
;-)
And if I get it, just like in OS X, this doesn't mean your application can't use or install other resources in the Library.
Pretty cool, that's 90% of my Linux gripes gone in one big swipe. I hope this can become mainstream. It also means I can stop posting on the importance of simple installers
I think, therefore I am...I think.
Anyone who calls 'apt' a more apt installation structure has forgotten how most users use software.
Most people don't want to learn a new packaging system. Most don't want to wait for someone else to package a program into the repos, assuming they even want to package it. The problem with Apt is it relies on someone else saying 'oh, that's great, I'll make some debs.' And it only works for someone with Debian or a Debian-compatable system like Lindows, Xandros, Knoppix, et al. A AppDir works on any distro that has ROX installed, so there's no more bullshit with having to package programs for 20 distros, or 20 versions of a distro. No 'Well, your using RedHat 8.2, which had this RPM, so here's a recompiled copy that works with that version, but if you have 9.1 it uses THIS RPM, which needs this recompile, or if-.' You just drop the AppDir in, and it works. No muss, no fuss.
Additionally, to install a deb you need to be root. Most people don't want or need to use root. 0install fixes that, and AppDirs make it easy even without 0install.
With AppDirs and 0install, you no longer have any of the problems software on GNU/Linux does. (Packaging for a number of distros and pushing it to the user with dependancies seamlessly) Apt only fixes one of those problems.
or simply run a STATICALLY compiled binary and not worry about dependancies...
All my binaries are statically compiled for the downloaders... and I NEVER get a complaint how my apps dont work, in fact I get more comments on how my linux apps binaries work every time no matter what and is a stark difference to most of the other linux stuff out there.
the typical response is "your binaires work every time... why can't other OSS developers do that?"
Do not look at laser with remaining good eye.
It is easier for moderators to mark things as a troll than to accept an OBVIOUS fact, since it flies in the face of the religion surrounding infallability of Apple.
But for a critical thinker who uses a personal OS X machine, (especially who has installed a fair amount of software):
Go to to your Applications directory and ls -la to see just how many are owned by the primary user instead of root. And then see if the primary user happens to also be a member of the Admin group, which has write access to all the files there owned by root/admin. This also applies to the Applications directory itself.
On my powerbook, taking installation defaults, over 95% of the apps installed in the Applications directory are writable by the primary user.
This seems inexcusable from a virus security perspective.
On Linux, 0% of my apps are writable by the primary user.
System security? Nothing. All code runs as you. As for your own security, it doesn't allow any attack that couldn't have been done without Zero Install too.
Reducing the security risk from traditional installation systems (APT, RPM, etc where you're running a downloaded install script as root) was an important goal for Zero Install.
See The Zero Install system
Here's the difference in a nutshell.
Statically linked binaries include all the libs and dependencies along with the binaries used to actually 'run' the program in one fat package. Depending on what it is you're packaging, it can add a shitload of weight to the package.
Dynamically linked binaries expect your system to contain dependencies already. They have the benefit of giving you a small, tight package but don't always work right away. IE you, the user, have to hunt down packages it needs or apt or rpm has to handle that for you.
It's a trade-off either route you choose. Statically linked binaries add bloat but usually work great without user or system intervention. Dynamically linked binaries are smaller and bloat-free but depend on you, your package manager or something else to make sure it works.
The typical stance of developers has been to build good packages that are small and dynamically linked. After all, what's the point of having 20 copies of a common system library that you may have had since your OS install? That's just bloat. Ultimately, the best developers, in my opinion, give you the choice when you go to download. Click here for static, here for dynamic.
Seriously, this rocks. Yeah, yeah, sure. Other projects have done things like this before. But I love this idea even more than Gentoo's system, which also rocks. So I read some of the site to try to answer some of my own first asked questions.
/uri/0install. If the required version isn't there, then instead of reporting an error (as traditional applications do), they run 0refresh. Software can be uncached when it hasn't been accessed for a long time (eg, months or years). If it's needed again, it gets refetched.
/uri/0install have directories by major version number, and ROX applications are linked correctly. Prepare to have much fun with compiler and linker flags finding all your include files and libraries when you convert your application to ROX.
Q. Do I have to add a bunch of crap to my $PATH?
A. No, you just use a shell that is application directory aware, and it will find the binary just fine if the application directory is in a directory in $PATH.
Q. Will it let me recompile critical applications, either to patch them or optimize them?
A Sure. Keep three different verions of Apache around, one with mod_perl, one with mod_rewrite, another with mod_php. Optimize for your new Sexium X CPU. Turn on full foo support, even though it's not recommended!
Q. What about apps with hardcoded pathnames?
A. Edit and recompile. HAND.
Q. What about libraries?
A. (From this page on the ROX Application directory system.) Applications link to libraries in
Q. What about versioning?
A. You can keep different versions of an application around in different directories. I couldn't find any information regarding library versioning. Hopefully libraries in
Q. DND Saving? What's that?
A. Rox aware apps support dragging files from a save box to a directory in a file browser to save. Finally, someone does this right.
- None can love freedom heartily, but good men; the rest love not freedom, but license. -- John Milton