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