Slashdot Log In
Zero Install: The Future of Linux on the Desktop?
Posted by
michael
on Sat Apr 03, 2004 12:33 PM
from the plug-and-play dept.
from the plug-and-play dept.
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."
This discussion has been archived.
No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
Full
Abbreviated
Hidden
Loading... please wait.
Someone should tell Apple (Score:5, Funny)
Could there be a difference here? (Score:5, Interesting)
Could there be a difference here? Hopefully they are not putting code into virus-writable directories, as often happens on Apple.
Parent
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.
Parent
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
Parent
Re:Could there be a difference here? (Score:5, Informative)
I install Mozilla on OSX. It says, rather than using an install program, I should just drag the icon into a directory, such as the applications directory, making it writable by any unprivileged program the user may execute.
This is not unlike I have seen for other programs for Mac as well.
When I try to take the initiative and protect these directories, the programs often stop working, because the program writes these directories when run by the user.
I am told by admins that program directories on OS X should generally be made user-writable.
When I do a default install Eclipse on OS X, it places the user workspace underneath the Eclipse program directory, not naturally leading to program directories that are not virus writable. I run it on Linux, and the workspace is separated from the program directory off of my home directory, and the eclipse stuff installs nicely into a protected area.
Parent
Re:Could there be a difference here? (Score:5, Interesting)
When I do a default install Eclipse on OS X, it places the user workspace underneath the Eclipse program directory, not naturally leading to program directories that are not virus writable. I run it on Linux, and the workspace is separated from the program directory off of my home directory, and the eclipse stuff installs nicely into a protected area.
Eclipse 3.0M8 is what you're looking for. It lets you choose the workspace location without fuss.
Parent
Re:Someone should tell Apple (Score:5, Insightful)
Parent
Don't bitch to Steve (Score:5, Insightful)
If MS Office can be a drag and drop install, almost anything can.
Parent
Re:Someone should tell Apple (Score:5, Interesting)
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.
Parent
Re:Someone should tell Apple (Score:5, Interesting)
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.
Parent
Re:Someone should tell Apple (Score:4, Interesting)
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]
Parent
Re:Someone should tell Apple (Score:5, Insightful)
Parent
Re:Someone should tell Apple (Score:4, Interesting)
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.
Parent
Potential for unpublishing apps? (Score:5, Interesting)
Slashdot has previously covered Rox here [slashdot.org].
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?
This sounds perfect... (Score:5, Interesting)
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
Re:This sounds perfect... (Score:4, Insightful)
Parent
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).
Parent
Re:This sounds perfect... (Score:5, Informative)
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"?
[ b) enter root password and hope it doesn't mess up your system ]
a) You don't have to find the right version for your system, just run the application. It will try to access the appropriate binary and that will get cached. /var/cache/zero-inst/gimp.org/bin/gimp). You shouldn't care though, any more that you care about the structure of squid's web cache.
b) Downloading happens automatically, just like viewing a web page through a web cache.
c) It goes in the cache directory, whose structure mirrors the URI scheme (eg
d) Drag it where you want it. On your desktop, panel, start menu, etc.
e) You could just run it where it is, without creating a short-cut at all.
Parent
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.
Parent
This is why... (Score:5, Insightful)
It's not quite that simple (Score:5, Informative)
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.
Parent
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.
Parent
Well duh... (Score:5, Interesting)
Not like this step hasn't been taken in the past by multiple other software solutions
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.
Parent
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
Parent
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.
Parent
A good idea, here's why... (Score:5, Funny)
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?!?
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.
Yes (Score:5, Informative)
This is also what Microsoft is trying (Score:5, Informative)
Delete the directoty and the app is gone.
This is here now, and altough
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
Parent
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.
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.
If you have Knoppix try klik (Score:5, Informative)
Similarities to Archimedes (Score:5, Informative)
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.
Clearing up a few things... (Score:5, Informative)
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.
Re:What about security? (Score:5, Informative)
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 [sourceforge.net]
Parent
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
OS X package? (Score:5, Interesting)
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
Libraries, Preferences Other Issues. (my mini FAQ) (Score:5, Informative)
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 [sourceforge.net] 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.
Re:waste? (Score:5, Informative)
Parent
Consider most people do have broadband now (Score:5, Insightful)
Parent
Re:waste? (Score:5, Interesting)
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?"
Parent
Re:static or what? (Score:5, Informative)
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.
Parent
You only have to download once (Score:4, Interesting)
Parent
Re:I thought we wanted people to reuse code? (Score:4, Informative)
The apps are all self-contained in their own directory; binaries, docs, source code and all. * * * This method of partitioning applications in their own directories also allows installing multiple versions of any application trivial.
What happened to the idea that we wanted programmers and users to share libraries and code? To solve rather than avoid dependancy problems?
Applications are self-contained in that everything from a single package is in a single directory, rather than being spread over /usr/bin, /usr/share, etc. They can still depend on other packages.
Without Zero Install, this means that although installing an individual package is quite easy, you may then have to install dependant packages in a similar fashion. With Zero Install, you get automatic dependancy resolution and freedom from install scripts.
Parent
Re:apps contained in their own directories.... (Score:5, Informative)
Parent
User settings storage in win32 (Score:5, Informative)
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?
Parent
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
Parent
Re:No, The future is thin clients (Score:4, Interesting)
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.
Parent