Slashdot Mirror
Apple and Independent Developers
Corleone writes "We've seen a realization recently that Microsoft isn't standing still with Longhorn, and countering Longhorn has been pushed to the forefront. That is why I found the concept of Apple being the larger danger in Rhapsody in Yellow so ironic. The author skirts the scary question: would Apple porting their frameworks to Linux give them undue influence over the direction of the free operating system movement? This is after recent reports saying missing programs are the biggest thing holding Linux back on the desktop. Macromedia has interest in their tools on Linux, surely many others are too. This would seem to allow thousands of companies a simple path to the Linux market but with Apple as the gateway. If not Apple, what of Microsoft porting their engine?"
I just perused the majority of that blog entry and...
.NIB compatibility. Apple never released the specs for their NIB (NeXTStep Interface Builder) format in which Cocoa interfaces are saved. Thus GNUstep had to create their own (first .gmodel, and then .gorm), neither of which are compatible with Apple's, which requires developers to reimplement interface files on each platform (trust me, this is a royal pain in the ass). However, a framework called Renaissance, which builds on OS X and GNUstep and allows you to specify your interfaces in XML, is starting to take hold. All it lacks is a graphical interface builder, and word on the grapevine is that such a thing is coming soon.
;)
No mention of GNUstep?
GNUstep is a complete reimplementation of the OPENSTEP (i. e. Cocoa) frameworks which works on GNU/Linux, BSD, and several other *NIX platforms... it already provides the portability necessary and an environment to develop apps against that framework for free.
What it's missing is a few crucial pieces which are slowly starting to fall together:
1)
2). $$$. GNUstep has no major corporate backer. Most of the people who work on it work on it because they love it. KDE, Gnome, and Mono all have the Novell monstrosity behind them. GNUstep has nothing.
3). Lack of distributed objects compatibility. See (1)
4). Outdated interface. The OPENSTEP look is, needless to say, passe. Apple did well redesigning their interface completely. GNUstep still looks like OPENSTEP did 10 years ago. This needs to change.
If Apple were to throw their weight behind GNUstep ( a tough decision, but an interesting one which could potentially bode well for both Apple and the free software community ) we could have the outcome the author asks for... Apple pushing a disruptive technology based on their own frameworks into free software, and taking hold of the market. Pipe dream? Maybe. But we can dream
With OS-X being basically BSD, Their wouldn't be much work to do so.
Actually, porting iTunes to Linux or BSD would be a horrific experience, as iTunes written in Carbon (Porting that to Linux would be a nightmare).
Vonal Declosion
Gnustepweb is a framework that is supposedly compatible with WebObjects.
The parent post has a really, really good point. GNUStep has oh, so much potential and it's getting close to ready.
Like it or lump it, Apple has produced the most cohesive *nix environment out there. They've got support from the important corporate software vendors. Vendors want to port to Linux, but damn, the myriad gui toolkits and serious lack of complete frameworks is daunting for commercial entities.
I know choice is good, but is Cocoa/Aqua that unexpressive to code in? The proliferation of apps for the Mac would seem to point to the contrary. Why must we reinvent the boring stuff (i.e. toolkits and frameworks) over and over? Couldn't we just adopt a proven successful model, run with it, then tweak where needed?
I just built GNUStep from NetBSD's excellent cross-platform package management/build system, pkgsrc. GNUStep is pretty cool. It's like a slightly primative, somewhat ugly Mac. Other than that, it's very, very similar. It's clear people are starting to write useful apps with it. It's got a finder-like app called GWorkspace. It's got a pretty decent mail application that runs on both MacOS and GNUStep.
-Peter
. Penguins Surely Ca
I'm tired of hearing all you people whine about Quicktime. Quicktime is a wrapper, it supports many codecs. WHat you're refering to is the Sorenson codec Apple uses for their .Mov files, this is licensed technology. Which means Apple would have to pay for every *nix copy downloaded. I don't see this happening.
Besides, quicktime has a poor interface currently, and unless you go pro, is annoyance ware.
You're completely off on your rationale and your information. Garage Band is a cunsumer-level application along the lines of iPhoto and iMove (since it's sold only as part of iLife). The full feature-rich version of Garage Band is Soundtrack, which is pro.
Funny you compare Garage Band to Acid, but don't compare iMovie or even Final Cut Express to Premiere.
Not since Marie-Antoinette played milkmaid has looking simple and honest been so fake and complicated.
As of MacOS 10.1 you've been able to call Objective-C class libraries from C++ code. It is also possible to call C++ class libraries from Objective-C code. Then of course it is possible to mix C++ and Objective-C code in the same source files. So...Cocoa is entirely accessible from C++ code.
Cocoa has been designed to work well with just about any OO language you throw at it. See the numerous bridges between OO languages and Cocoa.
I'm a loner Dottie, a Rebel.
DBM has really hit a new low with this "article". It is almost painful to read through with the gaping holes in logic and diction that would make a SMS junkie teenager blush.
According to DBM's logic Apple might have a real nice developer platform on their hands if they'd only port the base API to other platforms. I find this assertion to be pretty ridiculous. OpenStep already lost this battle a decade ago. The problem NeXT ran into with OpenStep was developers were already entrenched with native and proprietary APIs on their platforms of choice. Few developers were willing to drop all of their current code in order to develop OpenStep applications.
There's also the small problem of Apple's OpenStep derived frameworks (AppKit & Foundation Kit) being a tiny (though important) fraction of the frameworks available in OSX. If only Cocoa were ported to other platforms developers would have to write their own frameworks for advanced functionality. Instead of being able to leverage Apple's DiscRecording framework a developer would have to write, maintain, and package their own in order for their app to be as cross platform as Cocoa. Then the argument would be Apple ought to port their more advanced frameworks in order to draw in more developers.
If Cocoa were to be ported to Windows and Linux tomorrow it wouldn't magically bring oodles of developer talent to the Mac. Think of how many KDE and GNOME apps run on Linux, FreeBSD, Darwin/PPC, and Windows with no platform specific patches despite their common API usage. Only the simplest of Cocoa apps would run with only a recompile (or fat compile) on multiple platforms.
DBM doesn't pay nearly enough attention to Java in his little rant as he should. With Java Apple's already got a nice cross platform development environment to work with. Apple ships two J2EE environments, WebObjects and JBoss, as well as J2SE on their client systems. MacOS X is also bundled with a Java/Obj-C bridge which DBM almost totally ignores. The Java bridge gives OSX a serious advantage as a development and deployment platform for Java applications. With the Java bridge a developer can write a single cross platform application model and then stick a native Objective-C/Cocoa based GUI on top of it. Java's huge cross platform development base with a native Aqua GUI.
There's a few languages such as Python, Perl, and Ruby that can be bridged to Objective-C and can access Cocoa. That is not to mention C++ code can easily access Objective-C classes and thus Cocoa just as well as anything else. I don't really see Objective-C to be much of a hurdle in the development of Mac applications.
What it really comes down to is developers who don't want to abandon the APIs they are used to. All porting Cocoa would do is let Linux and Windows users run Mac applications. If everyone could run Mac applications on non-Mac computers the Mac would become a commodity item and Apple would be little more than an iPod manufacturer that happened to write some software. If Macs ran Windows there'd be no difference between a Mac and an HP. If PCs ran MacOS they'd be no different from Macs. In either case Apple would no longer have a whole product to sell. Without a whole product to sell Apple would either just be yet another software company or yet another hardware company. There's hundreds of each of those. Apple makes money by selling a whole computer product.
I'm a loner Dottie, a Rebel.
I'm sure there are far more than 10,000 developers "earning their crust" developing for the Mac. In a good year, Apple can scrape 4,000 attendees to WWDC. Even if only a quarter of those actually make a living on the Mac, I still can't believe that that represents a tenth of the Mac development community. I work for a company that has a major Mac application. We sure as hell don't send a tenth of our Mac developers to WWDC. We send two or three out of about 60 engineers.
-S
> I suspect Apple doesn't want to give *nix users a reason to not switch to Apple. They are
... ah... 'comprehensive' item, what with it basically being an entire programming API, plus applications. So everyone who makes a change in the codebase has to test it on both Mac and Windows before they check it in. Now, that's a hassle right now. Imagine everyone having a Linux box on their desk too, and having to test it there? And maybe having to hire another QA team to test on, say, six flavors of Linux? (And which six?)
> forced to support QT on windows because if they don't, it won't stay relevent.
I can speak to this personally.
Two problems with Linux: code and support.
First off, Apple (for obvious reasons -- you may not agree with them, but they are obvious) most certainly doesn't want to ship QuickTime as a set of source files and let Jack Jones compile it on his machine. Thus, they'd have to ship binary versions for all the major Linuxes. And on MacOS X and Windows QuickTime isn't a normal application: it interacts with the kernel in peculiar ways, most notibly in the area of thread priority (pseudo-realtime-ness). On Linux, at least a few years ago, there was really a choice between having that kind of integration or putting up a product that skipped and jerked and didn't really work. (Processors being faster now, it might be okay, I have no idea.) If they wanted to do this on Linux, they'd have to ship an update with every kernel, or make people compile some 'driver' portion of QuickTime each time they updated their kernel. Yes, THAT would really speed adoption of desktop Linux.
Second: the entire QuickTime team, to varying degrees, works with two OSes already: Windows and MacOS X. For a while it was three: Windows, MacOS X/Carbon, and MacOS 9/Classic. There are people who know more about Windows and there are people who know less about Windows but everyone has a Windows machine on their desks and everyone tests their software on Windows. They tried, many years ago, to have a Windows 'team' to port QuickTime, but QuickTime is a very
Don't underestimate the difficulty of this. QuickTime isn't just some app that you can download and compile anywhere, nor is it something that is being withheld from you for marketing reasons. If someone else were to underwrite the development and testing of QuickTime, I'll bet Apple would be delighted to do it. However, if it's not going to increase their revenues AT ALL (those Linux people, they aren't known for being big spenders on crippleware, and most of the ones I know would never consider paying for a Mac when they can get Linux for free) and it's going to increase their costs by (whatever) a million per year, it's kind of a no-brainer as far as I (and apparently they) are concerned.
> Plus, I believe several companies license QT from Apple for use on
> embedded systems running Linux, so porting it is not cost prohibitive.
I hadn'd heard, but I could believe this... but do you see how your first statement doesn't at all lead to your second? Embedded system: one version of Linux, one kernel, no testing costs (the client picks most of them up), *AND* the development is underwritten by someone else.
-fred
Sign #11 of Slashdot overdose: You see the phrase 'moderate Republican' and you wonder if that would be a +1 or a -1.