Zero Install: The Future of Linux on the Desktop? 718
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."
waste? (Score:3, Insightful)
Isn't this already being done with apt_get? I just think Linux needs a more user friendly updating service. I hate to say it, but windows is much better at taking completely computer stupid people and having them screw up their own pc's, instead of having to call a family member to do it for them.
This is why... (Score:5, Insightful)
Arrrggg....Joe dont care ! (Score:4, Insightful)
While I appreciate the posters enthusiasm this is not a panacea for oe User putting Linux on the desktop. What is in my opinion is a scale of compatibilty with both hardware and software. I mean Joe User (or Joe Six Pack) Only cares if he can do what he need to with apps he wants to. NOT what someone else tells him is a better application. He wants to play his games, surf the web, doodle with his digital checks and balance his checkbook, Tell me of any GOOD applications the average computer illeterate could use to do his checkbook, edit his pictures etc that is as brainless as developers make them for Windows/Mac ? ZIP , There are GREAT apps for doing all those things but in general they are for much more sophisticated users. When Jp can go to CompUsa and buy anything he wants , games, tools, etc, that will run on Linux and has some support number he can call when he breaks shit THEN Joe will use Linux on the desktop.
Consider most people do have broadband now (Score:5, Insightful)
Re:This sounds perfect... (Score:4, Insightful)
use P2P instead of client server. (Score:1, Insightful)
Re:Someone should tell Apple (Score:5, Insightful)
Hmm.. (Score:0, Insightful)
I wouldn't want to try that over the Internet.
Maybe I'm missing something?
Isn't this one already on the list? (Score:2, Insightful)
My list contains 1 item. One word actually. Unification
The average computer user is not an IT person. They have problems when you upgrade their machine from 2000 to XP. Even if you give them XP with the old GUI.
They would not be OK having to know 3 or 4 different desktops just to stay marketable.
Likewise, 3 or 4 mail clients, 3 or 4 office suites, this is bad for them.
This might change in 10 or 15 years when the business world is dominated by people that grew up using personal computers. But right now that isn't the case.
And I fully realize my list is mine and yours may differ. But isn't that the problem?
Re:Well duh... (Score:4, Insightful)
Why would you want to do that?
On my Fedora box, if I upgrade glibc to fix a bug, I want *all* my applications to benefit.
Oh, and disk space is not the reason for having shared libraries -- memory usage is.
Don't bitch to Steve (Score:5, Insightful)
If MS Office can be a drag and drop install, almost anything can.
Why I dislike about installing softwareunder Linux (Score:3, Insightful)
I thought I've done it in my LFS two years ago? (Score:2, Insightful)
Indeed, this has been specified in the FHS (Filesystem Hierarchy Standary) long long time ago. This is what the
[pathname.com]
Indeed, I've always been wondering why major Linux distributors haven't been using the
duplicate detection, copy on write (Score:4, Insightful)
Something like Zero Install should be combined with some form of duplicate file detection or duplicate block detection and sharing. Furthermore, to avoid a lot of tricky bookkeeping, there should be copy-on-write. And that kind of functionality really is best implemented in the file system itself. So, something to think about for the next major release of "ext". (Note that Microsoft is implementing something like this, but they certainly weren't the first to come up with it.)
Note that the same thing should also happen on downloads: you only download application components you don't already have locally. NFS isn't a good protocol for that, but WebDAV could handle it.
YAWN. That is SO 4 years ago (Score:2, Insightful)
I'm surprised OS X isn't mentioned at the top.
Zeroinstall. (Score:1, Insightful)
It goes over the net, and runs it ( Yeah, slow loading, yadda yadda ). But as it's doing this, downloading the app, getting libs, etc, it's building a local cache. The second time you run the app, it uses the local copy.
So executing a app you don't have 'installed' installs the app. After that, it's just like running the app off your local hd.
The future? not anymore (Score:2, Insightful)
Piggyback on which P2P network? (Score:4, Insightful)
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.
Re:No, The future is thin clients (Score:4, Insightful)
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
Re:Someone should tell Apple (Score:2, Insightful)
Like the DOS days (Score:4, Insightful)
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.
Re:Could there be a difference here? (Score:1, Insightful)
Solitaire and the Sims both work in Linux (Score:3, Insightful)
And those are the worlds most popular games. Games is not the major issue. The major issue is being able to download your porn, being able to surf the web, being able to burn pirated software, movies and DVDs, being able to get on AIM or some IM client, and occassionally use a word processor.
This is what 99% of internet users do. They don't run some esoteric application by Microsoft, 99% of people don't use all the features of word or office. Most of them wouldnt know the difference between Word Perfect, Star Office and Microsoft Office. Most people just think "I need to use the word processor." or "I need to get on AIM" or "I need to browse the web."
Simply name the App Web Browser, Word Processor, Instant Messager and 99% of users will know exactly what it is and what its for. They don't give a damn who makes it as long as it works and its easy to use. Functionality is what Linux needs, ease of use is what Linux needs, Eye candy is what Linux needs.
Linux does not need more apps, right now Linux has just the right amount of apps to work as a typical desktop machine for 99% of the population. Instead of building more Apps, its time to refine the apps already in development and make them more intuitive.
Yeaaah (all excited jumping up and down) (Score:2, Insightful)
It is exactly what Linux needs to become a serious contender for Joe User's desktop.
I wonder how many times have we read that on Slashdot. I wonder how this one slipped past the editors again. And it is boring, not important and proven wrong. There has never been, is not and will never be exactly what Linux needs to become a serious contender for Joe User's desktop. Let alone a single little thing being exactly what Linux needs to become a serious contender for Joe User's desktop.
Apart from that I dread this technology where glibc will have to be included in every app. The beauty of free software is the fragmentation. Everyone makes a little app that is perfect at what it does and small enough that one person can write and maintain it. And bigger apps just bundle them together like libs (think of all the GUI cd burning apps that are frontends to at least cdrecord, mkisofs and cdparanoia, if not to many more small apps). Also the ability to upgrade and keep the custom settings and data for one the new one in
And that is only half of what is wrong with this post (I am sorry, but I did't even RTFA). Please don't get me started on NFS.
'nuff said
Re:This is why... (Score:2, Insightful)
"hehe, I love my mom! +5 insightful, please!"
Re:Well duh... (Score:5, Insightful)
Granted as the last application requiring the old library is upgraded to being able to use the new library, the old library should be eliminated, but when a major upgrade breaking backwards compatibility happens, most people do not want to wait days or months for the application they have been using to be upgraded. They usually want to be able to continue to do the work that they need to do.
Then again, I could be wrong. Perhaps most other people are happy to sit around on their thumbs.
-Rusty
Re:YAWN. That is SO 4 years ago (Score:2, Insightful)
When Moses came down from the mountain, he wasn't carrying a stone tablet, he had a PowerBook.
Michaelangelo didn't do a single original thing in his life. He just travelled forward in a time machine (invented at Apple) and cribbed ideas off a blackboard in the Apple R&D facility.
----------
The 'everything was invented here' frenzy of Applebots rivals the chauvanism of Soviet-era Communist-Party/Russian-nationalists.
Re:Someone should tell Apple (Score:3, Insightful)
I think Linux would win a lot more converts if KDE and GNOME where less like Windows. Especially in regards to Lindows, I think it will eventually end up making Linux a generic Window in the eyes of potential users. Just go into any $1 or less store and you'll see what I mean, a great deal of the packaging resembles name brand packaging found in grocery stores. Sure you might get some loyal users just looking for a cheap replacement. But most users when given the choice are going to go with the name brand stuff.
standardized installs (Score:2, Insightful)
People give up on linux because they don't know how to install apps and games. They download stuff then say, "WTF is this shit? How do I use this?" Then, after realizing 90% of linux apps are like this just give up on linux.
Even when people can learn to install stuff they often don't know where the hell to install it to (people are used to not having to organize programs themselves, just throw em wherever it wants to go). We don't need fancy caching of downloaded apps and shit. We just need some standardization of the installers (shortcuts on the desktop or popup menu couldn't hurt either). That's what your average computer user wants.
Screw drag & drop (Score:2, Insightful)
Re:Going back in time? (Score:2, Insightful)
Re:This sounds perfect... (Score:4, Insightful)
Are you all guys seriously claiming that first
a) finding right foo for your system,
b) downloading foo,
c) knowing where it went,
d) knowing where to drag it,
e) actually dragging it
is simpler than cryptic
a) "install foo"?
Even if you automate all those steps and make a piece of software that has just a list of available applications and a place to drag it, you still need to know how start that, and it's not radically different or easier from how it's already done in most of cases (eg. checkbox in front of name and install button somewhere).
Microsoft had it and lost it. (Score:5, Insightful)
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
Re:This is why... (Score:5, Insightful)
Classic Mac OS used the resource fork for storing associated files, but still had an OS wide location for preference files (MacHD:System:Preference). Sure, no registry, but frankly, LOTS of OS's don't have a registry.
Mac OS X has bundles which resemble AppDir's (That Rox uses) a great deal, but OS X got them from NeXT not OS 9, and NeXT got it from RISC, which is the OS that Rox is trying to emulate in the first place. Mac OS emulation is the farthest thing from Thomas's mind, I assure you.
The real interesting technology isn't the AppDir's anyway, it's ZeroInstall, which allows you to view the internet as a file system from which you can directly run applications.
Plugins break this model (Score:5, Insightful)
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
Explinations? (Score:2, Insightful)
Re:Screw drag & drop (Score:2, Insightful)
I'd also like to add, when I first saw this a while ago, I just glanced over it and said I have ports/apt-get/portage so I don't need this. However, even with a GUI, those programs would require a rewrite to do what zero-install does. I see it filling a purpose for a group of users. Choice is good.
Re:Well duh... (Score:4, Insightful)
I propose we set aside a location on the system to hold subdirectories each dedicated to a single software package. Let's call it /opt.
Managing configurations ... (Score:2, Insightful)
Sample configurations for specific type of deployment (such as home use, enterprise, high performance etc.) are extremely valuable.
A similar mechanism is very much appreciated - though this also requires active involvements from user community.
-vinod
Re:Why I dislike about installing softwareunder Li (Score:2, Insightful)
Re:Screw drag & drop (Score:4, Insightful)
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.
Re:User settings storage in win32 (Score:4, Insightful)
Why did Microsoft make this move? Not only is it "all eggs in one basket" so it becomes unsafe in case it would crash, but it's also hard to clean it when the installer don't do the job to 100%, which it almost never do. Often I simply don't dare to, since it could be spread out in more places than HKCU\Software\Company\blah.
I'm not really interested in Microsoft bashing -- just an answer to why the app settings aren't stored in their respective folders. The OS settings could be stored in a win.ini just like before, or any other file structure that might be faster to navigate (like a hash table).
I think the registry *is* pretty fast and that's one reason, but it still isn't reason enough since the apps could just store in their directories with a similar structure via the standard registry API's. Why in a single multi-Megabyte mess?
What about shared libraries and memory? (Score:4, Insightful)
However, memory isn't so abundant. When loading up an app, is the system intelligent enough to recognize that a given library was already loaded into memory from a different directory, and therefore it won't load another copy of the same library?
Wrong (Score:2, Insightful)
Most just want to grab a binary, or a AppDir that will compile itself without you even needing to know how, and run it.
Let's stop pretending it's the user's fault for not knowing how to compile software, and move to something that works across the board already.
Re:Screw drag & drop (Score:4, Insightful)
BTW, I don't doubt APT is good (have no idea) but the OS X install process is as simple as it gets, anybody could do it, since you don't have to learn new concepts, all concepts are borrowed from the real world.
I don't know many Windows users (or non technical Linux users) who can manage an OS or even application install - without running in weird problems, I know no mac user who can't and doesn't do those things on his own.
Re:Someone should tell Apple (Score:5, Insightful)
Moderator trolls. (Score:5, Insightful)
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.
Re:You should get out more (Score:3, Insightful)
Which is basically true. I suppose most people could probably even manage to use Bash to launch programs if they could still run their other programs just as well.
Re:Screw drag & drop (Score:3, Insightful)
Re:Screw drag & drop (Score:2, Insightful)
Your assuming that a deb was even made. This requires the programmer A) has debian, and B) wants to make a deb. Or that someone else will make one. Which brings us back to the original problem.
But you only make one. With debs you have to make them for Debian, then a RPM for RedHat, another for Fedora, another for Mandrake, another for SuSE, another fo-
Regardles, AppDirs aren't installers. They are self-contained, and you just click on the AppDir to run it, regardless of where it is. Uninstalling is just a right-click, and delete. Most just check that it's compiled if it's C/C++/etc, and runs if it's compiled or just run if it is in Python/Ruby/etc.
Re:What about shared libraries and memory? (Score:3, Insightful)
This way you could still have systemwide shared libraries that are updatable, but it wouldn't be manditory to use them if it was a problem.
I think that's largely what you're advocating.
Partial solution (Score:4, Insightful)
However, it still seems that the folders created there are owned by you, so this is rather imperfect solution.
Fast user switching is theoretically a better one, but not on my 12" PBook with 1024x768 resolution due to an almost Dock-class UI design failure.
*) A Panther feature. In Jaguar you're forced to use a terminal in this case.
Re:Someone should tell Apple (Score:4, Insightful)
The big reason was that enough of the details of the Windows operating system were available that people could actually do something. Apple wanted to be the single source for most of the software as well.
From Apple's point of view, users were basically consumers of both hardware and software products.
With the PC and many other competing systems, the barriers to entry were much lower -- you could also be a producer of software as well.
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.
With OSX, I think there is finally room for the technically savvy users to do something more with their Macintosh systems than to just run programs from Apple and other software vendors.
Re:Well duh... (Score:2, Insightful)
Short form is, this argument about
1) Use apt-get/dpkg/etc to install things
2)
Funny they hate 'make install' but have no trouble double-clicking an InstallShield that will do God-knows-what to their Windows system.
Re:Someone should tell Apple (Score:1, Insightful)
Re:Don't bitch to Steve (Score:3, Insightful)
You think people write installers for fun? They usually write them because they don't have a choice, because the OS lacks some piece of functionality or other that lets the system adapt dynamically.
Besides, Mac-style drag-and-drop installs have their own problems: they don't get updated properly and they don't verify or deal with dependencies on install; they just dump the mess into the user's lap.
If MS Office can be a drag and drop install, almost anything can.
You got it backwards: the bigger and less integrated a package is, the less it needs an installer. After all, a 500M package can just carry all its own libraries with it and not worry about the fact that it will be out of sync with the rest of the world.
Re:Moderator trolls. (Score:5, Insightful)
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.
That sounds reasonable, until you remember that such places are writable only after the user authenticates. This means entering the administrator password, allowing installer X or operation Y in the Finder to go ahead and write to that directory. I don't see how that's any less secure than what most moderately experienced Linux users do - ./configure ; make ; sudo make install
Re:This is also what Microsoft is trying (Score:3, Insightful)
Exactly.
Companies can easily make a setup.exe that will install and work properly on Windows 95, Windows Server 2003 and everything inbetween. When we get a system that will do that for all versions of Linux (with the same cpu architecture), we'll have something. Then, add the ability to install that same package to only be available by a single user without root privs, and you have a winner.
Re:Well duh... (Score:3, Insightful)
Re:Someone should tell Apple (Score:1, Insightful)
Hardly a coincidence -- ROX == Risc OS on X
(read the SF project pages)
Why not solve BOTH of Linux's major problems? (Score:3, Insightful)
The big problems are to make it possible for an average user to install and deinstall first applications, then, peripherals.
In general, any OS is going to need the same kind of information from any class of peripherals. Why can't someone write software to decode the Windows driver information formats and turn the information into something that can be used to configure Linux to use these peripherals?
If someone plugs a USB scanner or digital camera or printer in, why shouldn't Linux ask for, first a native Linux driver, and if this isn't available, a Windows driver disk?
Wouldn't it be nice to be able to buy peripherals based on price and performance and not have to worry if it's usable with Linux or not?
Wouldn't it be easier to write a translation application or several than for the Open Source community to write thousands of drivers individually and for the rest of us to attempt to find them and then try to figure out if that driver will actually work with the distro one is running?
encaps (Score:3, Insightful)
Re:It's not quite that simple (Score:4, Insightful)
As for asking for the original password, that is because of Keychain. That one is encrypted with your original password.
As for apple.com caching the password... Well, it is quite simple to prove/disprove that: put the OS X machine behind a firewall, and log any attempts to connect to a machine in apple.com network.
Re:You should get out more (Score:4, Insightful)
I'm sure most people you've met haven't paid for Microsoft Office, which merely strengthens my point. Most people pirate their software. That's why $500 PCs seem like such a bargain; people aren't paying for the software they install on it.
What's funnier is all the people, including yourself, trying to tell me about OpenOffice (as if I didn't already know). Face facts, people. The average person installs a pirated copy of Microsoft Office. Stop fooling yourself because you aren't fooling anybody else. You and I both know that 99% of those $500 PCs are going to be running $2000+ worth of pirated software within the week.
The point, as always, is that with a Mac you are fully legit from the start. With the $500 PC, unless you run Linux and OpenOffice (which by all reliable sources is less than 1% of the desktop market) then you're up for at least another $500 to get the basic necessities of software. Anybody who mentions "OpenOffice" and "Linux" is ignoring the reality of the situation.