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
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
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.
Sounds a lot like Java Net Start to me.
Free as in mason.
[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.
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).
I note the rather skeptical responses, and while I agree with you in broad I think the picture is going to vary slightly.
As has been pointed out, the primary weakness of a network based thin client system is there exists a single point of failure. So I would propose the following for a corporate computer network:
Two mainframe systems, in physically remote locations, each completely capable of handling the corporate network. The mainframe's will serve as the core of the network, but the thin clients will be slightly more than just monitors.
A powerful thin client (I suppose thin client might not be the proper term) is what is needed to handle the reality of an iffy network. The thin client needs to be able to function independantly in the short term. It needs to be able to hold all of it's currently-in-use software and data in memory, and be engineered to make an emergency dump to some local nonvolital memory in case of a power failure. The key benefits to this "thick client" setup are a) because it is not an independant PC with the ability to boot and load software on its own, it is not a candidate for theft b) All data is preserved automatically at a central location except in the case of an emergency, and even then it is recoverable c) software updates only have to be performed one place to be deployed company wide d) maintainance is simpler since the thin clients can in theory be made without moving parts (i.e. hard drive) if they use solid state memory for the Gig or two of non-volital emergency storage they will need. They will be more expensive than a true thin client, but I rather suspect in bulk the economics would work and certainly maintainance costs would provide more than enough incentive.
"I object to doing things that computers can do." -- Olin Shivers, lispers.org
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.