SilverKeeper (http://www.silverkeeper.com/) from LaCie is the only free backup solution for OS of which I am aware. While not as full-featured as Retrospect, it's not bad if all you want to backup is your/User directory and maybe a few other things. You can set up specified things to backup, and then restore them or synchronize them. (In fact, its synchronization feature makes it extremely handy with an iPod, where you can use it to ensure that the Documents folder on both devices is always the same without having to delete the folder on the iPod and then recopy it each time.) If you need to backup everything on the disk, however, pretty much your only choice is going to be to use the extremely buggy ditto command with the command line utilities for manipulating.dmgs, or alternatively to purchase Retrospect..Mac's backup solution is awful and does not seem, IMVHO, to offer anything over SilverKeeper. You'd be better of spending that $100 on Retrospect anyway if that is the only thing you are interested in.
No no no, that's not technical enough. Refer to it as an image compression algorithm wherein a specific sequence of ASCII characters sent from server to client signals that an image stored on the client is to be used at the location of the specified ASCII stream. This is much broader and should nail a lot of people, including people who try to view a website on the same machine that's serving the content (such as most webmasters).
I seriously doubt they had to ask permission per se, but the US gets a little bit jumpy when rockets fire up from places like Khazakistan. So, I suspect that this had more to do with, "Yo, US, we're launching this really big rocket in a bit, and it won't be an ICBM, so you don't need to nuke us."
I left out my friend's name because I thought it would be rude to bring him into a post of which he was not aware, out of respect. Would you do any different?
"Hi, I have a friend named Jack McCourmic, lives at 985 W. 9th St. and he has this $50,000 theater setup in his basement that is really awesome. The back door's unlocked usually during the day hours, but that's OK be most people think he has a security dog."
I promise you that he has complained quite a bit, and the system has been fixed several times yet keeps breaking. You could figure that out from my post; if he weren't getting the equipment fixed repeatedly, then the speakers would not keep failing. They would have failed once.
I sincerely hope for Escient's sake you are not a service rep. If you were, a far, far better way to handle the situation would have been to email me from an escientsolutions.com account with your apologies that the system was not performing as specified and offer to help the friend get in touch with the appropriate people at Escient, whether or not he had already done that. As-is, I'm forced to conclude that this kind of immature behavior may have something to do with the unreliable nature of the system...
A friend of mine has a home theater system designed by Escient with full Dolby surround speakers, a nice projection screen about twelve feet wide or so, and so forth. Just like Scott Jones, it is also highly automated. Automated features it has (I am not making any of these up):
Blowing the speaker system about once per month, completely automated.
Firing DVDs at high speed out of the changer as someone walks by
Shutting the curtains in front of the screen, usually during highly suspenseful and/or very cool scenes
While the theater setup is cool, Escient's stuff, at least in that theater, always has something a bit off with it even when it's mostly working. I honestly don't know whether anyone except Escient offers that kind of thing (since I live in Indiana, Escient does seem to be the only option here), but if there are multiple options for you, I would at least consider them before going with Escient. I should emphasize that the theater is not mine and I have only had extensive experience with that one, but since there aren't a ton of these lying around, I thought I'd give my two cents anyway.
How do you know that the iPod player doesn't have a dedicated MP3 chip that takes an MPEG audio bitstream on one set of pins and produces WAV audio on another? (It does.)
While you're entirely correct, there are two ARMs in there that ought to have enough power to handle Ogg, provided that Apple were to license the integer-based version of the libraries. What I don't know again is whether the ARMs are really connected to the sound board in any real way, or whether all of the MP3 decoding happens on a daughterboard that essentially just receives a "Play" signal and then a datastream. If the ARMs do have sufficient bandwidth, and if Apple really wanted, they could at least theoretically add Ogg support without an overhaul to the hardware. (Incidentally, the MP3 chip that iPod uses allows real-time MP3 encoding, which in theory would let you use the iPod as the largest lecture recorder ever if Apple ever attaches a mic port.)
Re:Might he be onto something?
on
GUIs for Everyone
·
· Score: 3, Interesting
The two big things that killed OpenDoc were ActiveX and JavaBeans. Apple looked at them, decided it wasn't worth continuing to use OpenDoc, and let it go by the wayside. ActiveX and JavaBeans, while perhaps not as powerful, offer practically exactly the same feature set. (The only two things that OpenDoc offered "free" that they don't have are network collaboration and versioning, but either could be added without a whole lot of effort if anyone really cared, and JavaBeans have supported network transparency for quite awhile now.)
More than that, though, neither OpenDoc nor any of the other technologies really seemed to catch on. If you check, you'll discover that you can embed a Quattro Pro spreadsheet in Word, or a Word document into a WordPerfect file, and chances are really good that you can edit them afterwards. KParts in KDE provide the same functionality. But end users really don't seem to care or to make use of it. The problem, the reason they don't care, is that the entire system must be oriented around documents, or the idea really doesn't work terribly well because vendors can still support some extra functionality through integration. I can click a button in Word and an Excel spreadsheet pops up, but I have to go through a clutsy and unintuitive Insert Object menu to get a CorelDraw document in place. The only way to overcome this would be to replace even the applications themselves by documents, not at all unlike, oh, I don't know, maybe Mozilla, where the browser browser itself is just a big document that ties together a bunch of components through XML...
GNUstep has Java bindings. It's called JIGS and has been around for quite awhile. The API is extremely similar to Cocoa's Java binding; the biggest difference is the package name. Try it out and please help contribute to GNUstep if you would like to see it get wider adoption.
I honestly think that this entire post is well-written flamebait. Here's why:
WWDC did not have a single session on programming Quartz in Java.
True, but that's due to the combination of the fact that Quartz is C-based at low-level (we're talking device drivers here) and the fact that ObjC and Java share exactly the same API at the high level, so both languages are discussed in any particular session. Part of the whole deal with Java and ObjC on OS X is that they share practically identical APIs wherever possible, meaning that once you are familiar with Cocoa, you very rarely need to worry about the documentation to see what the Java version of a particular Cocoa function call is. So, for example, to access Quartz' bezier curves, you would just do
The rest of the Cocoa API is similarly exposed. Further, in practically all of the documentation, they either alternate between ObjC and Java examples, or else, show both side by side. Quartz, Cocoa, AppleScript, QuickTime, etc. are all completely supported. Interface Builder can directly generate Java Controller classes to handle UI events and can tie the GUI to those methods, and Apple is working on a version that will be able to natively handle Swing as well. What, specifically, did you find lacking?
On the side, I got contradictory information about how to program in Cocoa using two different bridges across obj-c and java.
There are exactly two Cocoa-Java bridges: Apple's and GNUstep's. Both use JNI to call out to their respective APIs. I fail to see how you could be confused about which bridge to use on which platform...
The rest of OS X and Cocoa (GUI) stayed in obj-c. Doh.
Again, all of Cocoa is available from Java. Did you want them to actually rewrite Cocoa in Java? What's your complaint here?
I even spoke with their then new head of software tools and engineering. As a smalltalk guy (skeptical of java and obj-c), he claimed that obj-c won him over. No love for Java there. Just more "not Apple's target market". It's hard to swallow paying thousands to go to a developer conference and have some pinheaded honcho tell you that despite Apple's "best platform for Java" campaign, that Java programmers are not allowed to program in Cocoa (OS X native) since Java Cocoa is not Apple's target market. What arrogance!
That's right, but for the wrong reason. Programmers at Apple aren't supposed to write in 100% Pure Java for what I hope are obvious reasons (they wouldn't take full advantage of the OS X user experience). Most (but not all) applications at Apple destined for OS X, meanwhile, are not written in Java due to the fact that users find the speed unacceptable. That's why Apple's VM team is so arrogant: specifically in order to allow Apple and others to write OS X-specific apps in Java using the Cocoa bindings without a performance penalty, Apple's been trying to squeeze every last ounce of performance they can out of the VM. They aren't there yet, and, unlike some companies, they care enough about the end-user experience to keep Java off the front line until the 15% performance gap can be closed.
Most of your post sounds essentially like you didn't read up sufficiently before going to get the most out of the conference, quite frankly. I encourage you to take another look at Java in OS X.
Actually, it happened over twenty years ago with the release of Smalltalk-76. But who's counting? At least the good ideas keep getting another chance in the sunlight before getting politely brushed under the carpet again.
Ditto. However, I hate to bring this up, but the real key is not going to be supporting this in Linux, but in making Mac OS X and Windows support it. Given that ICANN is going to be much more friendly to Microsoft than, say, the GNU Directory, I'm not sure that it's going to be easy either to convince them to support this or even to make it realtively easy to be added by a third party unless you figure out some way to convince businesses that it's in their best interest to have such a scheme. Further, you're still going to run into problems with copyright, even if it's not run by such an insane agency but instead decided on a per-case basis by the courts. Instead of simply complaining to ICANN that jaguarenthusiastsclub.com violates the Jaguar trademark, you'll get complains to ICANN, GNU Directory, Free Directory, Apple.Mac directory, and so forth, and if those complaints aren't resolved, you'll simply have a whole spate of lawsuits. Unless at least these two problems can be resolved in some relatively simple way, I think we still need yet another solution.
Object filing system, so for instance you can have people, and money as objects, and multiple directory hierarchies. I won't go into too much detail here.....
BFS can do this already. It's the way they implemented mail on BeOS: it was just a bunch of textfiles in a folder, but with attributes for To, From, Date Received, and so forth attached. You could also make a very simple database using that aspect of BeOS, and there were a few custom BeOS webservers designed that took advantage of that fact specifically to allow very simple databases without an engine. Amazingly, OpenBeOS already has a fully working replacement for BFS that has all of the features and seems to match the speed. It's still in alpha, but you should go check it out.
GUI based on Mozillas Gecko - with some optimisation that would be the most kickass graphics engine imaginable
Don't get me wrong here, but why? Gecko is designed to be an HTML viewer. Why do you want that as your GUI? I swear, I am not trying to start a flamewar; I honestly don't understand this one.
Total network transparency: Linux is pretty good, but imagine having network swap, if you run out of hard disk space, objects that haven't been accessed for a while are swapped out to other computers. Net result: huge amounts of disk space.
Knowledge representation based APIs. Most operating systems use huge data structures passed to functions to control them. Windows is big offender, not sure about Linux (depends on desktop I think). However, the web is heading towards being based on AI knowledge representation systems - the semantic web. If the OS was internally built on logical assertions and RDF-style abstract data structures, it'd be in prime position for ultratight web integration.
That's over my head, but it sure sounds good, so go over to OpenBeOs and add it!
It wouldn't be that hard to make if you were able to (and allowed) to make a small nuclear reactor. But of course, nuclear=bad, so that will never happen.
Nevertheless, you can read about how a lightsabre could work, ranging from plausible to implausible theories, as well as an introduction to kendo (the sword techniques the Jedi use) at this site: http://www.synicon.com.au/sw/ls/sabres.htm#index.
That really pissed me off, it was such a tease. When I saw the explosion and heard no sound, I said to myself "OMG, this is like the first movie since 2001 (the space oddessy) to get this right." I was so excited; it really made me feel like I was in space. Then a second later, boom. *sigh*
I actually didn't see a problem with this. While I'd have to watch it again, I thought the explosion noise was simultaneous with the actual arrival of the shockwave. If so, you could indeed hear noise; it would be the wave hitting your ship and causing the hull to vibrate at the same frequency as the peaks and troughs of the explosion. Seems reasonable to me.
Actually, current compiler technology can probably optimize quite well for a VLIW architecture. The only catch is that for it to work properly, you will need to profile your code. But with that data, a good compiler that can figure out where to optimize shouldn't be that hard to write.
What I really don't get, though, is why no one is focusing on using JITs with these. It strikes me that this is the ideal platform for a JIT, where it can recode parts of the program on-the-fly based on where the bottlenecks are and so forth. I mean, wasn't this the whole point of a just-in-time compiler in the first place? IBM's Java runtime can rival C++ in speed if it is allowed to run for a reasonable length of time, allowing the code to become truly optimized, and since Intel is targeting this thing in a server environment where applications will run for a similarly long length of time I fail to see why they aren't going that route. This has the additional benefit that as our understanding of how to optimize for VLIW improves, the programs do not need to be recompiled, but instead can immediately get the benefit. (I am fully aware that Itanium is supposed to do some of this type of optimization itself, but current specs are utter crap, to put it lightly.)
Interestingly, Sun's MAJC architecture does exactly that, expecting that a JVM or similar virtual machine will run on top. I have no clue what happened to that chip, but it struck me that it had much better potential to kick ass than Intel's Itanium despite having similar designs precisely because it was designed for a JIT to be on top.
No, but I'm sure we would. The dominant culture at the time of a field's inception tends to define that particular field. Have you noticed that biology is still heavily Latin, that music is heavily Italian, that a number of math symbols are French (natural log as ln being the best example), and that martial arts are almost all Asian languages? In those fields, Americans must familiarize themselves at least with the foreign terminology, if not with the languages themselves, and I'm sure that if the Chinese had developed the Internet that we would add whatever Chinese words to our language that we had to in order to use the technology.
As for the alphabet itself: I think that the Chinese use the Roman alphabet when they need to write a word phonetically, and at any rate know that there is a specific way to write Chinese sounds in roman. Regardless, however, I suspect that we would probably simply familiarize ourselves with their alphabet, or, better yet, nonsensically map our characters onto theirs, so that an "m" was this glyph and a "y" was that one, thus allowing us to use the system but with our words. In other words, do exactly what we are doing, only the other way around...
Talking of usability testing, do you have any data to back this up?
Sun's GNOME Usability Test made that point, and KDE's panels are similar enough to GNOMEs that I assumed the comparison was fair.
Oh, I almost forgot, there is a KDE panel applet that includes a small webserver, that can be switched on or off with a mouseclick. I think it's included with KDE3 or if not then with 3.1
It's not on my KDE 3 system, but that may be because I left out a package or something. Even if it is, though, my point doesn't really stand changed; KDE is improving with leaps and bounds, but it's just not entirely there, yet.
Re. transparent file access: that wasn't really my point. The iDisk in OS X is extremely thoroughly integrated, such that applications assume that it's there and you can easily send a file to your iDisk even if it's not mounted. Further, the very structure of the iDisk is critical for much of this to work properly. iPhoto assumes that a folder named Photos exists on your iDisk (just like your home directory, I might add), and HomePage assumes that it will find photos there if for your photos page. KDE doesn't need a central service to dupliate this functionality, but a standard disk format and easy way to essentially point to the iDisk (kDisk?) server of your choice would be a really simple and actually very nice addition.
Switch to root and try again. The whole UNIX directory structure is there, the finder simply hides it. Fine - I can make a version of Konqueror that hides it all as well, would that make it easier to use? Perhaps. I don't know to be honest. It might be something to look into.
I know it's still there; hell, I rely on it being there in some of the apps I write that in turn call the standard Unix tools in/usr/bin. The key is that the USER doesn't need to know, EVER. The/etc files are entirely obsoleted by NetInfo. Applications the typical user needs can be placed anywhere on the disk without any problem, and can be installed and deinstalled simply by drag and drop. I actually run with all files and directories exposed, but still find the OS X structure far easier for general apps.
Again, I appreciate that everything is improving, but you've got to understand that it's not quite there yet. That was my only point, and I honestly look forward very eagerly to when KDE and friends are on-par or surpass Apple's offerings. That's the point where no one will any longer be able to deny that open source desktops are around the corner.
We have Aqua. Or about 95% of the look. (Not the underlying technology, but then, does it matter?)
No, looks are everything! So I took off this Porsche Boxter chasis and stuck it on a Chevy Lumina, and I was wondering if you'd be interested...
On a slightly more serious note, it's very clear you haven't used OS X. Looks are NOT everything. If you honestly believe that the KDE 3 user experience is on par with Mac OS X, then I truly hope you stay out of usability testing. It's getting better all of the time, as is GNOME, but it's just not there yet. For example, the KDE configuration system is far more complex than System Preferences. Sure, it's because you get a lot of extra customization, but it overwhelms newbie users. (And, on a similar note, any user who really wants to customize things that badly in OS X need merely get the TinkerTool Panel installed and he can configure a number of out-of-the-way system settings.) KDE lacks any functionality close to an iDisk, and you cannot configure things such as webserving with the click of a button like you can in OS X. The excedingly simple directory structure of OS X is completely lacking in all Linux distros. (I.e., while the full structure is, of course, there, the user needn't worry about it. ~/Preferences houses all the user's prefs,/Applications holds all of the pretty Aqua apps which can simply be dragged there to install and to the trash to remove, etc. "./configure ; make ; make install" just cannot compare to this, and even.rpms and.debs are nowhere close, in my opinion.) Font managing is trivial, upgrades can be performed with a single button click or automatically while you sleep, etc., etc., etc.
Just because it looks like a duck does not mean that it quacks like a duck.
Apple has its own language (Objective-C), its own answer to J2EE (WebObjects), its own, extremely scalable server operating system (Mac OS X Server), and its own CPU (PowerPC). It will likely have its own graphics hardware soon (the purchase of Raycer) and may soon also have heavy iron, if the rumor mills are to be believed. (Certainly it would be relatively easy to design one.) I fail to see what Apple would gain out of this relationship.
Slashdot Mirror
SilverKeeper (http://www.silverkeeper.com/) from LaCie is the only free backup solution for OS of which I am aware. While not as full-featured as Retrospect, it's not bad if all you want to backup is your /User directory and maybe a few other things. You can set up specified things to backup, and then restore them or synchronize them. (In fact, its synchronization feature makes it extremely handy with an iPod, where you can use it to ensure that the Documents folder on both devices is always the same without having to delete the folder on the iPod and then recopy it each time.) If you need to backup everything on the disk, however, pretty much your only choice is going to be to use the extremely buggy ditto command with the command line utilities for manipulating .dmgs, or alternatively to purchase Retrospect. .Mac's backup solution is awful and does not seem, IMVHO, to offer anything over SilverKeeper. You'd be better of spending that $100 on Retrospect anyway if that is the only thing you are interested in.
No no no, that's not technical enough. Refer to it as an image compression algorithm wherein a specific sequence of ASCII characters sent from server to client signals that an image stored on the client is to be used at the location of the specified ASCII stream. This is much broader and should nail a lot of people, including people who try to view a website on the same machine that's serving the content (such as most webmasters).
I seriously doubt they had to ask permission per se, but the US gets a little bit jumpy when rockets fire up from places like Khazakistan. So, I suspect that this had more to do with, "Yo, US, we're launching this really big rocket in a bit, and it won't be an ICBM, so you don't need to nuke us."
I sincerely hope for Escient's sake you are not a service rep. If you were, a far, far better way to handle the situation would have been to email me from an escientsolutions.com account with your apologies that the system was not performing as specified and offer to help the friend get in touch with the appropriate people at Escient, whether or not he had already done that. As-is, I'm forced to conclude that this kind of immature behavior may have something to do with the unreliable nature of the system...
- Blowing the speaker system about once per month, completely automated.
- Firing DVDs at high speed out of the changer as someone walks by
- Shutting the curtains in front of the screen, usually during highly suspenseful and/or very cool scenes
While the theater setup is cool, Escient's stuff, at least in that theater, always has something a bit off with it even when it's mostly working. I honestly don't know whether anyone except Escient offers that kind of thing (since I live in Indiana, Escient does seem to be the only option here), but if there are multiple options for you, I would at least consider them before going with Escient. I should emphasize that the theater is not mine and I have only had extensive experience with that one, but since there aren't a ton of these lying around, I thought I'd give my two cents anyway.The two big things that killed OpenDoc were ActiveX and JavaBeans. Apple looked at them, decided it wasn't worth continuing to use OpenDoc, and let it go by the wayside. ActiveX and JavaBeans, while perhaps not as powerful, offer practically exactly the same feature set. (The only two things that OpenDoc offered "free" that they don't have are network collaboration and versioning, but either could be added without a whole lot of effort if anyone really cared, and JavaBeans have supported network transparency for quite awhile now.)
More than that, though, neither OpenDoc nor any of the other technologies really seemed to catch on. If you check, you'll discover that you can embed a Quattro Pro spreadsheet in Word, or a Word document into a WordPerfect file, and chances are really good that you can edit them afterwards. KParts in KDE provide the same functionality. But end users really don't seem to care or to make use of it. The problem, the reason they don't care, is that the entire system must be oriented around documents, or the idea really doesn't work terribly well because vendors can still support some extra functionality through integration. I can click a button in Word and an Excel spreadsheet pops up, but I have to go through a clutsy and unintuitive Insert Object menu to get a CorelDraw document in place. The only way to overcome this would be to replace even the applications themselves by documents, not at all unlike, oh, I don't know, maybe Mozilla, where the browser browser itself is just a big document that ties together a bunch of components through XML...
GNUstep has Java bindings. It's called JIGS and has been around for quite awhile. The API is extremely similar to Cocoa's Java binding; the biggest difference is the package name. Try it out and please help contribute to GNUstep if you would like to see it get wider adoption.
Most of your post sounds essentially like you didn't read up sufficiently before going to get the most out of the conference, quite frankly. I encourage you to take another look at Java in OS X.
Granted, eWorld tanked, but you know which company used exactly the same software as eWorld and made it?
AOL.
Actually, it happened over twenty years ago with the release of Smalltalk-76. But who's counting? At least the good ideas keep getting another chance in the sunlight before getting politely brushed under the carpet again.
Ditto. However, I hate to bring this up, but the real key is not going to be supporting this in Linux, but in making Mac OS X and Windows support it. Given that ICANN is going to be much more friendly to Microsoft than, say, the GNU Directory, I'm not sure that it's going to be easy either to convince them to support this or even to make it realtively easy to be added by a third party unless you figure out some way to convince businesses that it's in their best interest to have such a scheme. Further, you're still going to run into problems with copyright, even if it's not run by such an insane agency but instead decided on a per-case basis by the courts. Instead of simply complaining to ICANN that jaguarenthusiastsclub.com violates the Jaguar trademark, you'll get complains to ICANN, GNU Directory, Free Directory, Apple .Mac directory, and so forth, and if those complaints aren't resolved, you'll simply have a whole spate of lawsuits. Unless at least these two problems can be resolved in some relatively simple way, I think we still need yet another solution.
Be honest. Don't you think those people who were literally shooting down metric road signs might have had something to do with it too?
Anyone else think that it's a somewhat odd coincidence that searching for her brings up an image of the "I'm feeling lucky" button?
It wouldn't be that hard to make if you were able to (and allowed) to make a small nuclear reactor. But of course, nuclear=bad, so that will never happen.
Nevertheless, you can read about how a lightsabre could work, ranging from plausible to implausible theories, as well as an introduction to kendo (the sword techniques the Jedi use) at this site: http://www.synicon.com.au/sw/ls/sabres.htm#index.
Actually, current compiler technology can probably optimize quite well for a VLIW architecture. The only catch is that for it to work properly, you will need to profile your code. But with that data, a good compiler that can figure out where to optimize shouldn't be that hard to write.
What I really don't get, though, is why no one is focusing on using JITs with these. It strikes me that this is the ideal platform for a JIT, where it can recode parts of the program on-the-fly based on where the bottlenecks are and so forth. I mean, wasn't this the whole point of a just-in-time compiler in the first place? IBM's Java runtime can rival C++ in speed if it is allowed to run for a reasonable length of time, allowing the code to become truly optimized, and since Intel is targeting this thing in a server environment where applications will run for a similarly long length of time I fail to see why they aren't going that route. This has the additional benefit that as our understanding of how to optimize for VLIW improves, the programs do not need to be recompiled, but instead can immediately get the benefit. (I am fully aware that Itanium is supposed to do some of this type of optimization itself, but current specs are utter crap, to put it lightly.)
Interestingly, Sun's MAJC architecture does exactly that, expecting that a JVM or similar virtual machine will run on top. I have no clue what happened to that chip, but it struck me that it had much better potential to kick ass than Intel's Itanium despite having similar designs precisely because it was designed for a JIT to be on top.
Perhaps Bill feels a need to compensate for something?...
No, but I'm sure we would. The dominant culture at the time of a field's inception tends to define that particular field. Have you noticed that biology is still heavily Latin, that music is heavily Italian, that a number of math symbols are French (natural log as ln being the best example), and that martial arts are almost all Asian languages? In those fields, Americans must familiarize themselves at least with the foreign terminology, if not with the languages themselves, and I'm sure that if the Chinese had developed the Internet that we would add whatever Chinese words to our language that we had to in order to use the technology.
As for the alphabet itself: I think that the Chinese use the Roman alphabet when they need to write a word phonetically, and at any rate know that there is a specific way to write Chinese sounds in roman. Regardless, however, I suspect that we would probably simply familiarize ourselves with their alphabet, or, better yet, nonsensically map our characters onto theirs, so that an "m" was this glyph and a "y" was that one, thus allowing us to use the system but with our words. In other words, do exactly what we are doing, only the other way around...
Re. transparent file access: that wasn't really my point. The iDisk in OS X is extremely thoroughly integrated, such that applications assume that it's there and you can easily send a file to your iDisk even if it's not mounted. Further, the very structure of the iDisk is critical for much of this to work properly. iPhoto assumes that a folder named Photos exists on your iDisk (just like your home directory, I might add), and HomePage assumes that it will find photos there if for your photos page. KDE doesn't need a central service to dupliate this functionality, but a standard disk format and easy way to essentially point to the iDisk (kDisk?) server of your choice would be a really simple and actually very nice addition.
I know it's still there; hell, I rely on it being there in some of the apps I write that in turn call the standard Unix tools in
Again, I appreciate that everything is improving, but you've got to understand that it's not quite there yet. That was my only point, and I honestly look forward very eagerly to when KDE and friends are on-par or surpass Apple's offerings. That's the point where no one will any longer be able to deny that open source desktops are around the corner.
On a slightly more serious note, it's very clear you haven't used OS X. Looks are NOT everything. If you honestly believe that the KDE 3 user experience is on par with Mac OS X, then I truly hope you stay out of usability testing. It's getting better all of the time, as is GNOME, but it's just not there yet. For example, the KDE configuration system is far more complex than System Preferences. Sure, it's because you get a lot of extra customization, but it overwhelms newbie users. (And, on a similar note, any user who really wants to customize things that badly in OS X need merely get the TinkerTool Panel installed and he can configure a number of out-of-the-way system settings.) KDE lacks any functionality close to an iDisk, and you cannot configure things such as webserving with the click of a button like you can in OS X. The excedingly simple directory structure of OS X is completely lacking in all Linux distros. (I.e., while the full structure is, of course, there, the user needn't worry about it. ~/Preferences houses all the user's prefs,
Just because it looks like a duck does not mean that it quacks like a duck.
Is it just me, or is this the plot to Star Wars III?
Apple has its own language (Objective-C), its own answer to J2EE (WebObjects), its own, extremely scalable server operating system (Mac OS X Server), and its own CPU (PowerPC). It will likely have its own graphics hardware soon (the purchase of Raycer) and may soon also have heavy iron, if the rumor mills are to be believed. (Certainly it would be relatively easy to design one.) I fail to see what Apple would gain out of this relationship.