Apple continues to be slightly behind the curve when it comes to new tech.
Translation: I know squat about actual, currently shipping Apple products, but based on my 5 minutes with a Quadra years ago, I'll make sweeping generalizations. What are these USB & FireWire things people are talking about? Isn't that 70s technology? DVD-RAM? AltiVec? Positively neanderthal!
I've been watching 3dfx getting their toes wet with MacOS drivers for their cards, but with Apple bundling a card with every Mac, they won't continue developing their drivers for very long.
Translation: though second-guessing Apple's plans with simplistic assumptions has proven wildly off target every single time, I can safely say that 3dfx's public announcements about Mac support and this whole Voodoo 5 thing are a fad. Right?
Matrix was in the Mac video card game for a while (up to Millennium II), but dropped development when Apple did their exclusive bundling agreement.
Translation: Not only can I not get the product name right, but I'll confuse the bumbling, ill-managed pre-Jobs Apple with the focussed, tightly-run Apple of today. They're still "beleaguered", aren't they?
Apple sealed their long-term fate in the desktop computer business when they killed the clones.
Translation: I am *so* with the program. What is this iMac thing people are talking about? Boy, they're never going to sell more than 10,000 of those beach toys!
Apple is at the mercy of Motorola for their G4. The economies of scale prevent this chip from competing with the I86s and Athlons. Motorola can't scale the mhz up on it given the volumne of sales.
Translation: Not content to flaunt my ignorance on Apple's current product lineup or market position, I'll now post drivel about microprocessors I know even less about. Didn't IBM stop making G3s and bail on the G4? After all, mhz depends solely on "the volumne of sales", not irrelevant things like chip design, pipeline depth, or fabrication process. I'm so happy I sold my AAPL stock at that high of $22. What's a two-for-one split?
Apple is selling very few computers at a high profit margin, and very few copies of its OS at $99 a pop.
Translation: A 38% year-over-year growth in units shipped? What's that? Top-five spots in the consumer markets worldwide? Who knows? What's this OS X thing I hear about? Isn't X-Windows 20 years old? Too bad I flunked economics.
If any folks out there think Apple isn't greedy and arrogant, just try and become an Apple reseller!
Translation: How dare they be a for-profit and take pride in their work! The money-grubbing swine! I'll stick with noble charities like Microsoft & Sun. I heard CompUSA, Sears, and other Mac retailers absolutely hate Apple! In fact, they're clearing out their inventories of poorly-selling Macs in the next two weeks, before a big Apple announcement! Let's hope Apple is allowing cloning again and resurrecting the Lisa!
So what's Apple's problem with having a GPL'ed package management system? I know many companies have an aversion to the GPL, but how does having a free and open package management system hurt them?
Apple's problem is the viral nature of the GPL. This topic has been bludgeoned to death far too often. Here's the gist - the GPL's definition of "derivate works" is too vague. If the Operating System relies on the package management system to work, it might theoretically be construed as a "derivate work". Yes, it sounds idiotic, but what matters is how it can be cast legally. And the GPL has never been tested in court. Apple, understandably, is reluctant to use an install system that might cause their entire product to be placed under the GPL.
Actually, it looked like an ugly hack using dotfiles, to me. What happens if the dotfile gets replaced/deleted/etc.? Doesn't sound like a very good solution to me.
Sounds like you didn't bother to actually read up on it. There are no dotfiles involved. Speaking as a Mac OS X developer, it's a very good solution. Not perfect, but given the constraints, very good.
What's the speed of running an app in the Classic environment? Does the environment work roughly the same way that the Blue Box did in Rhapsody?
Anybody who can legitimately answer this has signed an NDA that forbids them from talking about performance issues currently. However, note that the Classic environment is *not* an emulator. So the machine code for an application runs directly on the hardware. Classic is essentially Rhapsody's "Blue Box" unboxed. It lets uncarbonized applications coexist much more smoothly with the rest of the system.
IMHO, they should have used something like the BeOS filesystem, so they could keep resource forks, etc.
Apple seems to have given this issue a lot of thought. Firstly, they are not constraining the filesystem to be UFS. Mac OS X can boot and root off HFS+ (and probably will by default). Secondly, the application environments have some fairly nifty infrastructure to carry around the meta-data that sits in the resource fork around on filesystems that do not support forks, and translate back and forth. It's actually quite neat. Poke around the Mac OS X developer documentation on apple.com for details.
Since you are primarily Macintosh-based, I'm going to describe things from that perspective, assuming that you wish to continue to support the Mac.
The short answer is that there is currently no "complete" solution. By "complete", I mean:
Comprehensive APIs with UI support.
RAD tool.
Good database access.
Actually shipping and available right now.
Before the knees of Java-heads start jerking, let us examine how the obvious candidate falls short:
100% Pure Java Though Java written only to Sun's API is in theory useable for a cross-platform app, there are a few pragmatic issues -- the APIs are very poor and complex, the UI layer (Swing, née AWT) sucks ass, VM idiosyncracies are rampant, and performance may be a problem (though improvements are constantly being made). On the up side, there are several RAD environments for Java, your development and deployment platforms can be (more or less) different, and database access is reasonably solid (JDBC).
More or less everything else out there is incomplete in terms of the three main criteria you have stated (UI APIs, RAD tool, DB access).
Apple's Cocoa/Yellow Box/OpenStep Frameworks For just the Mac, the Cocoa frameworks that are a part of Mac OS X are by far the best solution. They are vastly more sophisticated, complete and robust that anything else on any platform (with the possible exception of some SmallTalk environments). Cocoa has top notch UI support (the AppKit), an eminently usable RAD environment (ProjectBuilder, InterfaceBuilder et al.) and DB access that is about 2 generations ahead of anything else (Enterprise Objects Framework). Cocoa is also completely cross-platform technically, and has been so for several years (at one point running on Mach (m68k, i386, hp-pa, sparc) & Windows (i386). So what's the problem? Apple does not currently license Cocoa for anything other than the Mac, and has indicated no plans to do so. This prevents people for whom cross-platform development is essential from using what is without a doubt the most advanced application development environment in existence. Yes, it sucks. Harrass leadership@apple.com about it.
So what are other people in the same predicament doing? Though there isn't currently a perfect, off-the-shelf answer, there are many things one can do to get close:
Ensure that your app design & architecture are modular - break all the database stuff and business logic out into a "model", which has no UI and can therefore be highly portably written in Objective-C, or C, or C++, or whatever. Java, with JDBC, may be viable as a cross-platform solution here.
Abstract all UI and "controller" behavior into as thin a layer as possible, so that it is easier to implement it against different UI layers (Carbon, MFC, GTK, whatever). The main obstacle you face here is having to implement the UI code natively for each platform. The various abstraction layers that are commercially or freely available tend to take a least common denominator approach, and hence sacrifice quality, speed and flexibility. Unless you don't care about you UI very much, they are not all that useful.
Other random notes: If GNUStep ever gets close to complete, your Cocoa code should trivially port to anything supported by GNUStep. Currently, the non-UI layer (Foundation) is production quality. Also, if your database schema is complex/demanding, you really, really should take a look at EOF, which is now a part of Apple's WebObjects product.
Wow, this is news - MacOS 9 has plug-and-play, a smooth UI and lots of apps. Linux is powerful and supports lots of PC hardware. Say it ain't so! CNet is so 31337.
Bah. Such comparisons are worse than useless. Best tool for the job at hand and all that.
Not quite. "Darwin" == "Mac OS X Core". They are one and the same. Really. Darwin is not some watered down "lite" version of the Core Operating System. Rather, it is the core.
Slashdot Mirror
Translation: I know squat about actual, currently shipping Apple products, but based on my 5 minutes with a Quadra years ago, I'll make sweeping generalizations. What are these USB & FireWire things people are talking about? Isn't that 70s technology? DVD-RAM? AltiVec? Positively neanderthal!
I've been watching 3dfx getting their toes wet with MacOS drivers for their cards, but with Apple bundling a card with every Mac, they won't continue developing their drivers for very long.
Translation: though second-guessing Apple's plans with simplistic assumptions has proven wildly off target every single time, I can safely say that 3dfx's public announcements about Mac support and this whole Voodoo 5 thing are a fad. Right?
Matrix was in the Mac video card game for a while (up to Millennium II), but dropped development when Apple did their exclusive bundling agreement.
Translation: Not only can I not get the product name right, but I'll confuse the bumbling, ill-managed pre-Jobs Apple with the focussed, tightly-run Apple of today. They're still "beleaguered", aren't they?
Apple sealed their long-term fate in the desktop computer business when they killed the clones.
Translation: I am *so* with the program. What is this iMac thing people are talking about? Boy, they're never going to sell more than 10,000 of those beach toys!
Apple is at the mercy of Motorola for their G4. The economies of scale prevent this chip from competing with the I86s and Athlons. Motorola can't scale the mhz up on it given the volumne of sales.
Translation: Not content to flaunt my ignorance on Apple's current product lineup or market position, I'll now post drivel about microprocessors I know even less about. Didn't IBM stop making G3s and bail on the G4? After all, mhz depends solely on "the volumne of sales", not irrelevant things like chip design, pipeline depth, or fabrication process. I'm so happy I sold my AAPL stock at that high of $22. What's a two-for-one split?
Apple is selling very few computers at a high profit margin, and very few copies of its OS at $99 a pop.
Translation: A 38% year-over-year growth in units shipped? What's that? Top-five spots in the consumer markets worldwide? Who knows? What's this OS X thing I hear about? Isn't X-Windows 20 years old? Too bad I flunked economics.
If any folks out there think Apple isn't greedy and arrogant, just try and become an Apple reseller!
Translation: How dare they be a for-profit and take pride in their work! The money-grubbing swine! I'll stick with noble charities like Microsoft & Sun. I heard CompUSA, Sears, and other Mac retailers absolutely hate Apple! In fact, they're clearing out their inventories of poorly-selling Macs in the next two weeks, before a big Apple announcement! Let's hope Apple is allowing cloning again and resurrecting the Lisa!
Apple's problem is the viral nature of the GPL. This topic has been bludgeoned to death far too often. Here's the gist - the GPL's definition of "derivate works" is too vague. If the Operating System relies on the package management system to work, it might theoretically be construed as a "derivate work". Yes, it sounds idiotic, but what matters is how it can be cast legally. And the GPL has never been tested in court. Apple, understandably, is reluctant to use an install system that might cause their entire product to be placed under the GPL.
Sounds like you didn't bother to actually read up on it. There are no dotfiles involved. Speaking as a Mac OS X developer, it's a very good solution. Not perfect, but given the constraints, very good.
Anybody who can legitimately answer this has signed an NDA that forbids them from talking about performance issues currently. However, note that the Classic environment is *not* an emulator. So the machine code for an application runs directly on the hardware. Classic is essentially Rhapsody's "Blue Box" unboxed. It lets uncarbonized applications coexist much more smoothly with the rest of the system.
IMHO, they should have used something like the BeOS filesystem, so they could keep resource forks, etc.
Apple seems to have given this issue a lot of thought. Firstly, they are not constraining the filesystem to be UFS. Mac OS X can boot and root off HFS+ (and probably will by default). Secondly, the application environments have some fairly nifty infrastructure to carry around the meta-data that sits in the resource fork around on filesystems that do not support forks, and translate back and forth. It's actually quite neat. Poke around the Mac OS X developer documentation on apple.com for details.
The short answer is that there is currently no "complete" solution. By "complete", I mean:
Before the knees of Java-heads start jerking, let us examine how the obvious candidate falls short:
100% Pure Java
Though Java written only to Sun's API is in theory useable for a cross-platform app, there are a few pragmatic issues -- the APIs are very poor and complex, the UI layer (Swing, née AWT) sucks ass, VM idiosyncracies are rampant, and performance may be a problem (though improvements are constantly being made). On the up side, there are several RAD environments for Java, your development and deployment platforms can be (more or less) different, and database access is reasonably solid (JDBC).
More or less everything else out there is incomplete in terms of the three main criteria you have stated (UI APIs, RAD tool, DB access).
Apple's Cocoa/Yellow Box/OpenStep Frameworks
For just the Mac, the Cocoa frameworks that are a part of Mac OS X are by far the best solution. They are vastly more sophisticated, complete and robust that anything else on any platform (with the possible exception of some SmallTalk environments). Cocoa has top notch UI support (the AppKit), an eminently usable RAD environment (ProjectBuilder, InterfaceBuilder et al.) and DB access that is about 2 generations ahead of anything else (Enterprise Objects Framework). Cocoa is also completely cross-platform technically, and has been so for several years (at one point running on Mach (m68k, i386, hp-pa, sparc) & Windows (i386). So what's the problem? Apple does not currently license Cocoa for anything other than the Mac, and has indicated no plans to do so. This prevents people for whom cross-platform development is essential from using what is without a doubt the most advanced application development environment in existence. Yes, it sucks. Harrass leadership@apple.com about it.
So what are other people in the same predicament doing? Though there isn't currently a perfect, off-the-shelf answer, there are many things one can do to get close:
Other random notes: If GNUStep ever gets close to complete, your Cocoa code should trivially port to anything supported by GNUStep. Currently, the non-UI layer (Foundation) is production quality. Also, if your database schema is complex/demanding, you really, really should take a look at EOF, which is now a part of Apple's WebObjects product.
Handy-dandy URLs
Mac OS X Developer Documentation
GNUStep, a free implementation of the OPENSTEP spec.
Java 2 Documentation
Bah. Such comparisons are worse than useless. Best tool for the job at hand and all that.
Not quite. "Darwin" == "Mac OS X Core". They are one and the same. Really. Darwin is not some watered down "lite" version of the Core Operating System. Rather, it is the core.