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."
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
This is the true power of Unix + X.. Running applications remote from the workstation..
.. most everything that a data center does, this improves it..
This aids in system management, resource control, data security, platform independence,
It *is* the future.. ( and ironically the past.. remember VT100's and 3270's ? ) as is its the right way to do computing..
---- Booth was a patriot ----
This layout of program storage reminds me of The Olden Days on DOS, when the whole program was in one directory. 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.
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
epkg is a related utility that I found very useful...
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.
I do something similar to this already.
I keep all of my Java apps on a Samba share on my fileserver. Then, I set up aliases pointing at my standard version that I'm using.
Then, from whatever system I use or plug into my network, I map the drives and I have all of my apps with no hassle.
I've done this connecting Slackware, Redhat, win2k, and win98 systems to my network. It removes all the nastiness of having to maintance multiple copies.
Hear hear (though I'm sure their UI people are already aware of it---ZI has been in development for a while now). Certainly commercial app developers should like it because it gives the user a very easy way to try the "trial version". This would lead to more trials, presumably meaning more sales. It goes without saying that Free Software people should like it just from a usability standpoint.
The only way it could *suck* is if Microsoft is the first company to use it in a big way.
Sounds a lot like Java Net Start to me.
Free as in mason.
I remember reading an article by Dvorak where he was looking at computers in a consumer electronics retail chain. As he was standing there, a young man walked into the store, jacked his iPod into a mac on display with firewire, drag and dropped the Office.X folder from the mac to his iPod, unjacked and walked out.
;)
Unfortunately, ease of use can obviously be abused, but in such ingenious ways.
[snicker]
Seriously, as an Apple user, I'm glad to see a Linux desktop system copying the MacOS instead of Windows. I've felt for some time that it is a huge mistake for KDE and GNOME to try so hard to make themselves look like Windows when, in OS X, there is a much better example of a Unix-based desktop. Why waste your time copying less than the best?
Yeah, yeah, user familiarity, etc. Look, folks, I guarantee you that if all you've ever used is Windows, if you sit down at a good OS X machine, it will take you about half an hour to get used to the differences and be up to speed -- and after that you'll be discovering new and better ways to do things and saying, "That's so cool! Why didn't Microsoft ever think of that?" If a Linux desktop can have some nifty non-Windows features too (and I really don't care if the developers rip them off from Apple or come up with them on their own) it will do a lot more to enhance Linux desktop growth than just coming up with a system that's "like Windows, only not exactly."
Next response I anticipate: "Yeah, well, if Mac OS X is so much better, how come it hasn't beat Windows in the marketplace?" The answer, of course, is that there is a lot of mindless anti-Apple prejudice, and regrettably I don't expect that to change any time soon. But anti-Linux prejudice is much milder, I think. A good Linux desktop with Mac OS X's best features (and maybe some of its own) especially if it were backed by IBM, could be the best shot at breaking the Windows stranglehold on the corporate desktop.
The correlation between ignorance of statistics and using "correlation is not causation" as an argument is close to 1.
Risc OS has used this approach since the mid/late 1980's when the OS was launched on the Acorn Archimedes.
The only shared libraries are the ones built into the OS. (The OS was on ROM, so version incompatibilties didn't really exist like they would with the disk based OS's we use today).
Their where special files placed in each directory (!boot and !run)
!boot was executed when the filemanager loaded the directory and was responsible for replacing the applications default 'dir' icon with one that represented the application function.
!run was executed when the user launched the program by double clicking on the folder.
It was possible to open the directory rather than execute the application, IIRC a shift key was used in conjunction with a mouse click.
Disclaimer: It's about 15 years since I used the above system, so details may be inaccurate.
Apple has had this for years going back to the old System 9, 8, 7, etc...
.
How come the system folder on my MacOS machines is full of all sorts of 'preferences' and assorted debris and croft? Yours isn't??
I was hoping maybe people here were talking exclusively about MacOS 10, because I *know* for a fact that apps spatter stuff all over in the system folder on older MacOS versions. Now I find more handwaving and mistruths and wonder if 10 does the same messy things. .
---
Look, folks, I guarantee you that if all you've ever used is Windows, if you sit down at a good OS X machine, it will take you about half an hour to get used to the differences and be up to speed
True.
and after that you'll be discovering new and better ways to do things and saying, "That's so cool! Why didn't Microsoft ever think of that?"
Uh, I had the opposite response. "Why in the f*&k did they do it that way?!" Keyboard control is practically nonexistant. And Finder blows... Damn I hate the way it works. It doesn't allow to see where you are in the filesystem very well. It's just awkward and slow to use.
The killer feature Apple has is that they have a GUI for everything in the system and it hides a lot of complex stuff so the end-user doesn't have to worry about every little detail (of course sometimes that backfires when I simply can't do something because it's hiding the details).
Back on topic...
I've found ROX is very similar to Finder. I hate it also.
The ROX "all in one directory" is the exact same concept as Apple bundles. I can't believe how many people don't even know what they are. I guess that's what happens when you hide all the details. Anyway, the bundle concept is pretty cool. Just copy/move a directory to install your application.
The ratio of people to cake is too big
I really hope you're right, and I'm glad to hear that you're so impressed with OS X. The reason I'm gloomy about the anti-Apple prejudice going away is that honestly, I can't remember a time when the Mac OS wasn't better than the comparable Windows version available at the time. Yeah, OS 9 sucked, but Windows ME sucked ever so much harder, and with teeth. OS 8 was mediocre, but it was competing against Windows 98, for God's sake! System 7 was quite good, albeit rather bare-bones by modern standards -- but compared to Windows 3.1 and 95, it was a thing of beauty and a joy forever. (I think I have the timelines right; apologies if I'm forgetting something.) Etc.
And yet at every point in this history, the Mac was struggling against the dual prejudice of "M4XZ 5UX0RZ" from the script-kiddie brigade (and don't underestimate these people; even now, I suspect that Aunt Tillie is likely to go to her 17-year-old nephew for computer buying advice) and "Apple makes toys" from the suits. And even now, that the Mac OS has an industrial-strength Unix base and the hardware actually offers better price/performance than any comparable brand-name PC at all but the lowest of the low end, you still hear variants of these tired old prejudices trotted out every day.
My advice for the Linux desktop developers is: please, please, rip off everything you can from the OS X desktop. But don't never admit to anyone where you got the idea. We Apple geeks will know regardless, and sit back in our half-bitter, half-proud glory. We've got plenty of practice. [1/2 g]
The correlation between ignorance of statistics and using "correlation is not causation" as an argument is close to 1.
Since everyone seems to be giving examples of earlier systems which install in this way, I should add that this is usual on the Amiga too.
Application specific files and user preferences all live in the program's directory. However, 3rd party libraries and so on tend to be stored in the system folders, which IMO gives the best of both worlds - applications can share common code, but application specific code and data are easily removed, and not strewn about all over the place (libraries tend to be small on the Amiga, so the fact that you might acquire libraries over time that aren't being used by any installed applications isn't that great a problem, and anyway there is probably more bloat in having multiple copies of a library).
According to your criterea liux is coming along.
Linux already has great compatibility with 90% of the hardware on market (more then windows probably), you can already call somebody when things go wrong. Moneydance is an excellent and easy to use program for balancing your check book, zip files are handled automatically by all the file managers, mozilla is better then IE in every respect including speed and ease of use. I don't edit pictures much but I imagine there are a few applications for that well.
It sounds to me like all we have to do is to get a handful games to attract the 16 year olds and we are there!.
BTW. There is not a comp-usa in my neigborhood but there is a best buy. I went in there to ask about some mac games and software and they told me that they don't carry anything for the mac but that I could check out their web site and maybe they would have some there. Apparently in this regard both the Mac and Linux platforms are suffering.
Maybe we can start some sort of a boycott of stores that don't carry Linux distributions. I mean if the republicans can call for a boycott ot heinz ketchup because the wife of the democratic candidate owns a part of the company we can call for a boycott of best but don't you think?
evil is as evil does
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.
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.
.files in ~. I like to keep it tidy. Why can't we have a standard that says all config files are kept in ~/settings/ with default files in /settings/? Or at least make it user configurable. I also don't like the . prefix to make files hidden; feels like a nasty hack. If you keep the files tidied away I don't think it's even needed.
And, dammit, this is as messy as hell. I don't like having hundreds of
</rant>
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.
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.
Exactly. And you have no way of knowing what it's doing with that password. If you're hooked up to the Net, chances are it's (then or later) being cached somewhere inside apple.com, too. Do you know of a way to convince me otherwise? If not, a sensible person would just assume that the password is now known to Apple.
Similarly, when I first got my Powerbook, it had to be sent in for repairs after about a week. (The screen wouldn't come to life.) They wanted my password, of course, and I gave it to them. No problem, I thought; when I got it back, I'd just change my password.
Lotta good that did me. Yeah, I can use my new password when I log in. But nearly everything in the system that asks me for my password will only accept the original one. I've found a few places that packages cache the password, and changed those. It lasts for a while, then one day it wants my original password again. I've found it necessary to keep a record of all the passwords I've used, because I generally have to try them one at a time until I find which one works with a given app.
Your password is cached all over the place by OSX packages, so the only sensible approach is to assume that it's public knowledge, at least to Apple insiders.
This is one reason that I'd never use OSX for any sensitive applications. I have to assume, from the way it handles passwords, that OSX systems are open to anyone at Apple, and to anyone able to bribe the right people at Apple, and to any intruder who knows where they are cached on my machine.
I'd like to be proved wrong. But a mere assertion that I shouldn't worry my little head about it won't convince me. I want proof.
So far, I've never seen linux software playing fast and loose with passwords like this. I mean, mozilla will cache passwords for you, but it asks,you can say "No", and it apparently honors that. And it doesn't ask for local passwords, only those demanded by web sites.
Also, there are some linux apps that ask you for the root password because they need to run something as root. But you never have to give the root password. You can always kill the app and start it again under sudo. Then it won't know the password, and won't ask for it because it already has the right permissions, so you know the password couldn't be cached.
Those who do study history are doomed to stand helplessly by while everyone else repeats it.
>> Deleting the application along with all the other misc files
>> is as simple as removing the directory it's contained in.
[...]
>> This is something even the greatest of technophobes could understand and use with ease
This is an understatement.
This is what the greatest of technophobes ALWAYS BELIEVED TO BE THE CORRECT PROCEDURE FOR UNINSTALLING APPLICATIONS.
Kudos to developers for aligning reality to perception!
could you please explain the difference (static or whatever) for those of us who might not know? thanks in advance! Whichever, I'm all in favor of apps that just work and not needing dependencies.
Let's say you have downloaded and installed some 20 programs packaged as Appdirs. If each package is supposed to be virtually self-contained across all distros, you're going to have to include _all_ dependencies. And therefore you lose all advantages of having shared libraries. You've got 20 copies of libc, 10 copies of gtk, 15 copies of X runtimes, and so on?
How big is each appdir?
Defenestrate Windows...
You know, there ARE other desktops out there besides Windows and Mac OSX. I don't think its quite fair to say the KDE and Gnome developers are trying to copy Windows. I see a lot of (good) ideas taken from other window managers and desktops, such as multiple desktops, window listing, etc.
What people like in a desktop is subjective. I, for one, tend to use the mouse as little as possible and find most Mac desktops to be a bit mouse-intensive. Other people may work differently and never notice.
I do agree with you on your overall point however; OSS should be pursuing the best of the closed-source technologies. And I believe the serious projects are doing just that. Both Gnome and KDE are already prettier and more useable than Windows, and I would love to see them catch OSX in the eye-candy department.
Oh, and while we're at it, can I get fast user switching (OSX) and key-chain-binding (Waimea)?
Look at my karma - I'm bad, just like Michael Jackson!
Now as for shared libraries, this should be handled by a COM broker, with Apps registering uses of component API's. If no app wants an API then all implementations of that API are unnecessary and can be removed.
Back in the early 1990s when Microsoft started pouring more money into Windows than DOS,
rule #1 put sales and complexity above easy installs, easy backups, and easy uninstalls.
It was unAmerican if you could unarchive FOO.SEA or FOO.ARC or FOO.ZIP into directory
[FOO] containing FOO.SRC, FOO.INI, FOO.EXE and FOO.DOC
But Windows could drop little icons on the desktop so users could find FOOBLOAT.EXE !
I don't think it is a silly statement. I stopped using Linux because of all the library dependancies. It was absurd- every application I wanted to install requried a library I couldn't find or figure out how to use. And then there were the applications built to work with specific distributions (and hence not others). Don't get me started on those!
It's a good start -- I've used it as the "official" organizational standard when building an internal custom GNU/Linux distribution.
But, it still enforces a particular hierarchy, generally to keep the traditional operating system components playing nice as new applications are added. There is no guarantee that it will be the most appropriate hierarchical organization in all cases: what about multiple versions of different applications that one wants to install simultaneously and their interdependencies? What about forked applications with different version number namespaces?
While the FHS is good, and useful, it is but one hierarchy. To impose it is not good geek style, though neither is it wise to reinvent a perfectly good wheel. What we really need is a way to organize the files that make up applications in multiple hierarchies, as appropriate, letting each application also define an application-specific hierarchy as appropriate for it's novel organizational needs. This does not, of course, mean that application must define their own hierarchies -- emphasis should be on using existing, perfectly functional ones (not the least of which is the OS core, generally represented by something like the FHS) where possible. Leverage and reuse is the name of the game here.
The issue really becomes one of managing all the different file hierarchies, and the effect that a file change or removal has on all the hierarchies in which it participates. Package management addresses these issues in the package management space, or hierarchy, as it were, but I find that it does so as a layer above the filesystem, requiring an all or nothing approach to reap the benefits. Furthermore, as application packages all installed "above" a core operating system, it strikes me that the core operating system should provide some facilities to simplify applicaiton interaction.
I'm not sure that this means moving package management into the O/S and adding a layer of insulation above the filesystem. Instead, files in the filesystem should have attributes reflecting the various hierarchies or views as the parent responder suggests, in which the file participates: the file and directory hierarchy is but one such view, after all, and this view remains a useful one.
I keep thinking that "callbacks" to application managers that can be registered on individual file changes within the filesystem remain the appropriate architectural model on which to build. Note that I would not necessarily think that individual applications be permitted to directly manage common "hot" files, like configuration files under /etc: the formats differ (though an XML-ized /etc can help here, bootstrapping it is a hassle). Instead, the O/S provides a set of interfaces to manage the configurable aspects it offers: /etc/services, for example, does is not generally edited by packages installers and deinstallers, but rather, an O/S facility is provided to manage changes to it, and other such configuration files: applications, after all, should know the configuraion changes they wish to make to other applications or the operating system.
This reduces the filesystem callback requirements to ones of create, move, or remove alone, and not change. That should simplify things.
Food for thought...
You could've hired me.
NeXTstep utilized a very similar sounding packaged application directory approach. There, if you "ran" a directory named "XXX.app", it ran the executable within that directory named "XXX". I was just discoving xnix, so I don't remember all of the details, but I believe it used static libs, and depending on how you manipulated a .app it worked like a directory or as a unit. Putting the parent directory of XXX.app in the path allowed execution of the program.
It did work quite well, and I found the idea very effective compared to Windoze, Dos, and SunOS approaches. You could just drag a package around, and the file compartmentalization was quite a step forward. I eventually hacked a similar capability under Dos using 4dos and executable extensions.
it might even be 15 years ago.
At CMU they had this thing called AFS, depot, and emt. It did all of this, and more.
openAFS, Coda, or even NFSv4, depot (or stow) could all be used to really build something interesting. (emt could be improved, but it wouldn't be hard).
Cool idea, but why just stop at the desktop?
Everyone I know who was into the Macintosh were strictly users with little idea of knowing how the software worked and no inclination to learn how to write their own software. Everyone with an interest in writing software were using other computers and operating systems.
I can second that as well as the parent. I've only met a few people who had any interest in developing software on the Mac, several people who were interested in developing multimedia on the Mac, and countless many people who just want a computer that worked like an appliance.
I think another factor worth mentioning is gaming. I seem to recall Apple discouraging people from developing game software for a while since Apple wanted the Mac to be respected in the work environment, hence a lot of more science and educational apps. So, DOS ended up being the game platform, which worked out quite well since DOS developers had many more potential customers.
I still want an Apple. I've wanted one for years, but I'm locked in, and I still see Apple as "benevolent dictator" that go back to the way it was when Steve really got overbearing.