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."
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.
-- johntracy.com, because everybody else is wrong.
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.
"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.
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.
No one has to be the main server, let groups of people host to each other. Use mirrors, or use P2P on the school or work network. Client server need not be used in a LAN, or on college campus where I'm sure theres a lot of other linux users. For people at work I'm sure they have their own private servers. For people at home you pay a fee, big deal.
People don't exist to serve systems, systems exist to serve people.
Yes, someone should indeed point that out to Steve Jobs. Many Mac applications these days come with installers that drop bits all over the file system, and many of those don't come with clean uninstallers, making the problem worse.
I wouldn't want to try that over the Internet.
Maybe I'm missing something?
You know, the list of single items that is what is needed to get Linux to JoeUser's desktop? I'm sure the concept was there already is not the exact tools to do it with.
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?
Sorry folks, we have the technology right now to support multiple version of libraries at the same time
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.
May we never see th
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?
Installing different packages in their own directories... this is nothing new. /opt tree is for.
/opt tree for simplicity, but kept on keeping all the files together in /usr and /usr/local. That's a hell to clean up when your rpm or apt doesn't work.
Indeed, this has been specified in the FHS (Filesystem Hierarchy Standary) long long time ago. This is what the
Indeed, I've always been wondering why major Linux distributors haven't been using the
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.
and you say linux isn't copying OS X.
I'm surprised OS X isn't mentioned at the top.
You only get the performance hit when you try to run an app that lacks local components for the first time.
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.
Just running an X server as a thin client used to be the future, but the present way UIs are presented to the user from a server is 95% of the time in a web browser, and if that changes, it's not going to be back to what used to be future (X).
Trees can't go dancing
So do them a big favor
Pretend dancing stinks!
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
The anti-apple prejudices will go away, but it will take time... For a lot of us, Mac OS 9 was really awful...yet from the little I had the chance to play with OS X(not that much...but chances if I spent more time it would get better), I was delightfully impressed...and if I had money Id get a Mac right here right now. its the kind of same thing that happened with Windows, from Win9x to WinNT5+...it doesnt crash that much anymore, but its still suffering from the bad experiences of the old days... Mac's reputation will recover, probably faster...
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.
Virus-writable directories? As often happens? WTF are you babbling about? Name ONE example.
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.
Finally we have found the holy grail that for so many years all Linux users and developers have sought after:
.foo is something Windows is trying to copy in XP now, but many programs still have their own idea about where to store custom data.
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
One reason you might want to support multiple versions of a library is that when a major upgrade to a library occurs, say going from libc2.3 to libc3, backwards compatibility is not assured. If one of the applications you are using can not use libc3, you as the user get to have the joy of re-compiling it to see if it will work with the new libc. If it doesn't, having a copy of the old libc2.3 lying around to run that application against would be handy. No?
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
You never know...
Everything is copying OS X. Everything has always been copying OS X. When Napoleon rolled across Europe, it was because he'd seen the Apple Development Team approaching the NeXT compound and about to break down the door with a battering ram.
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.
---
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.
Win a signed Stephen Carpenter ESP Guitar from the Deftones: http://def-tag.com/?r=0008781
The day that linux gets standardized installers that are just "click and install" with some options (like a windows installers) and a standardized install directory (a "program files" directory) is the day that thousands apon thousands flock to linux.
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.
This is an example of Linux *regressing* to better fit the model of Mac/Windows. We've already got a much superior installation method: APT. What we need is a simple GUI for APT (or Yum or whatever) not a complex "app folder" system. APT is about as simple as installation can get. You double-click a program, and its installed and right in your programs menu. No manually searching for an installer, opening up the "applications folder", dragging & dropping, etc. Think about it: that requires so many more extra concepts for the user to learn! They have to first understand the filesystem (many users do not). Then they have to understand the concept of installer images. Then they have to understand how to drag & drop (many users do not). Then they have to understand the concept of a special "applications folder." Contrast this to the a GUI front-end for APT. Users would just have to understand how to start a program (which they already do), how to select the program they want, and how to double-click. It reuses existing concepts so much better.
A deep unwavering belief is a sure sign you're missing something...
Or in %sysroot% itself. Or in the maze of subdirectories (other than System32) under %sysroot%. Or in hidden files/directories in the root directory. But yeah, other than that, it's Program Files, the registry, or System32. :)
Dragging and dropping WHAT from WHERE to WHERE?
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 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 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.
Can someone actually explain why we use the unix file structure still? (ignoring backwards compatability and any stupid hardcoding) sure its nice having libraries and docs in various organised places, but surely theres a better structure that makes more sense for everyone and could still be technically superior? or maybe im wrong and unix filestructure is just so good i dont fully understand its hidden clockwork beauty yet?
This comment does not represent the views or opinions of the user.
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.
After install issues, the next pain in managing application is in its configuration.
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
I think the idea is that the type of user we're talking about is not likely to be compiling from source. If deb or rpm gave the same sort of freedom as your average configure script, then we'd be on to something...
we speak the way we breathe --Fugazi
One thing I don't really find logical in Windows ( heh, only one?? :-) ) is the invention of the registry.
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?
Beware: In C++, your friends can see your privates!
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.
You make the assumtion someone knows how to compile software. The massive, overwelming majority do not.
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.
I always thought that Mac OS suffered in the marketplace because it ran on propietary hardware that only came from one manufacturer, whereas x86 PC hardware was produced by loads of companies and hence the competition drove the price down. If Mac OS X was available for x86 I'd buy it. But it's not, and I don't have the money to shell out to buy a Mac, as well as my x86 PC that I've effectively had (via loads of upgrades) since a while before Windows 95 came out...
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.
A program, not to program. The noun, not the verb. By this, he meant that people are far more likely to be using Internet Explorer or Quake than the stuff like the Dock and Finder, which are only used for short periods of time while they make their way to the programs.
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.
"Never attribute to malice that which can be adequately explained by stupidity." -- Hanlon's Razor
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
There was more to it than that, but you are partly correct.
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.
But modern distributions like debian and gentoo have dependency checking, so if your attempt to upgrade libraryX is going to break appFOO, the upgrade tool itself will complain. So we've already got that functionality, IF you use applications that adhere to the local packaging system. And if you don't, well then you're obviously smart enough to fix the problem, right? Just compile the application and statically link to its older libc.
/bin /usr /lib etc. seems to come up all the time from people who refuse to do ANY of the following:
./configure && make install
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.
while you have valid complaints ... the point he was making was that their offering was better than microsoft's at the time. you'd have at least as much fun trying to do the same thing on an MS OS from the same era.
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.
set softtabstop=4 shiftwidth=4 expandtab nocp worlddomination
If the users don't have enough memory to run the program, they won't buy it and the developer won't get their money. If the users do have enough memory to run the program, then there isn't any problem with it using more memory. I don't see anything unethical about writing a program that uses lots of memory, as long as you are honest about its memory usage on the box. Whether the users want to buy a memory hogging program is up to them to decide.
I don't care if it's 90,000 hectares. That lake was not my doing.
Risc OS has used this approach since the mid/late 1980's when the OS was launched on the Acorn Archimedes.
:-).
Hardly a coincidence -- ROX == Risc OS on X
(read the SF project pages)
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?
Tech Public Policy stuff
Whoever thought this was new has obviously never heard of encaps. Basically the same idea, but it's been around for about 5 years longer. Look at www.encap.org for starters. (I'm not going to write a lot since nobody will read this anyway.)
Applications do not cache passwords. If you see the nice prompt asking you for an administrative password, it should be coming from the system. (There are ways of verifying this... Set your account to use the Blue colour scheme, set your (real) root account to use the Graphite colour scheme. Any dialogue boxes or windows with Graphite widgets are running as root)
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.
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.