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?"

Comments

What about GNUstep?

[__aavhli5779]

I just perused the majority of that blog entry and...

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) .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.
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 ;)

Re:What about GNUstep?

[scrod]

Most of the important Adobe and Macromedia applications are developed in Carbon--not Cocoa, unfortunately. Even iTunes and QuickTime are still dependent on Carbon.

Re:What about GNUstep?

[Dr. Sp0ng]

What it's missing is a few crucial pieces which are slowly starting to fall together

No. What is missing is the final (and most important) piece of the cross-platform idea - Windows. I'm a Mac guy, and I love Cocoa, and I've been a Linux user since 1994 and a Solaris user befor that, but I understand the realities of the world today. For a development platform like GNUStep to succeed, it has to be able to run on Windows and, and here's the kicker, act like a native Windows application.

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.

I actually agree in this situation - the open source version, given the ability and cooperation from Apple, could flourish technically and allow cooperation between Apple and the free software community which extends past simply command line tools and support libraries, while Apple still eats its lunch on the interface and user experience side of things (in addition, just because Apple would allow third party developers to develop true cross-platform apps between itself and *nix (and, like I said earlier, Windows), there would not necessarily be a version of Final Cut Pro for Linux - you want the real Mac experience, for what Macs are really good for, you buy a Mac.

Wow, that's a long sentence.

Re:What about GNUstep?

[__aavhli5779]

That is indeed something that was pointed out in the article. Don't forget, however, Carbon is simply a stepping-stone API. It was created by Apple so their legacy developers wouldn't be caught out in the sands with a completely new OS and a completely new API. Apple knew that combination would be disastrous so they created a new API from scratch that was mostly source-compatible with the old one to allow for easy porting.

Carbon, however, will never be deployed on other platforms. It's a horrible, messy kludge composed of about 15 years of Macintosh API evolution plus the necessary changes to make it work on OS X. There's nothing about it that's appealing from a "beginning to code for" standpoint... it's just there for transition.

Cocoa has all that potential because it is a beautiful, clean API in a modern object-oriented language plus it already has cross-platform support in the form of GNUstep. The article decried the lack of interest in starting to code for Cocoa (and thus to create new Mac OS apps) by new developers precisely because it's only really supported on OS X and thus not attractive... I think GNUstep already proves that false to a degree and will do so further in the future.

Re:What about GNUstep?

[__aavhli5779]

No. What is missing is the final (and most important) piece of the cross-platform idea - Windows. I'm a Mac guy, and I love Cocoa, and I've been a Linux user since 1994 and a Solaris user befor that, but I understand the realities of the world today. For a development platform like GNUStep to succeed, it has to be able to run on Windows and, and here's the kicker, act like a native Windows application.

A salient point, and one on which you would find surprising agreement from the fine denizens of the gnustep-discuss mailing list.

It is recognized that GNUstep pretty much utterly fails on Win32 (at least in terms of the Application Kit... Foundation Kit is relatively functional but of course provides no GUI functionality). I foresee a future where the actual drawing of widgets and interaction with the user is abstracted away into different backend libraries on each platform, and interfaces are coded in XML which is parsed by XSLT stylesheets into the proper layouts for each platform.

I suggested this idea on gnustep-discuss and it received a lukewarm response, but I'm considering working on it myself, starting off with Nicola Pero's excellent Renaissance framework.

Re:What about GNUstep?

[Chucker23N]

Carbon, however, will never be deployed on other platforms. It's a horrible, messy kludge composed of about 15 years of Macintosh API evolution plus the necessary changes to make it work on OS X. There's nothing about it that's appealing from a "beginning to code for" standpoint... it's just there for transition.

Except for single applications like QuickTime Player for Windows and iTunes for Windows, which *do* essentially contain large chunks of Carbon.

Re:What about GNUstep?

[Anonymous Coward]

Exactly -- In the ultimate irony, Carbon ended up being cross-platform and OpenStep/Cocoa didn't.

Re:What about GNUstep?

[__aavhli5779]

Objective-C literally takes about 5 minutes to learn.

It adds a few keywords to C (it's in the single-digits, I believe) and one syntactic structure.

The idea that people aren't picking up Objective-C because they don't want to learn another language is preposterous. They're not picking it up because the only complete platform to develop with it is Apple's Cocoa, and that's just not large enough of a platform to be worthwhile to a lot of development houses. Once GNUstep is up to par (in my opinion it already is if you're willing to be a hacker, but that's obviously not true for most) I think exactly that raison-d'etre will be delivered.

Re:What about GNUstep?

[borgheron]

Check out wiki.gnustep.org for a list of applications and other information on GNUstep. There are around 40 (last I checked, not a complete list) applications which are currently in use on GNUstep and the number is growing.

I maintain Gorm (the IB clone), which is fully functional at this point. You've got to realize that the website is only updated every so often. So GNUstep is more complete than you think.

GJC

Re:What about GNUstep?

[borgheron]

This is very likely because Apple is in the middle of transitioning these applications themselves. :) Remember iTunes was available on Mac OS 9, I believe. So it would have to have been written using the old APIs.

GJC

Re:What about GNUstep?

[jcr]

Objective-C literally takes about 5 minutes to learn.

Well, I wouldn't go quite that far... When I've presented cocoa intro classes, I've generally covered the basics of Objective-C in a one-hour lecture.

My experience in learning Objective-C was that it took me about a day to be productive with it, and within a month I was an Obj-C language lawyer. Most people I've seen taking up Obj-C for the first time have a pretty good handle on it in about three days.

As for GNUStep, I'd say it's a commendable effort, but an unfunded volunteer project is always going to have difficulty tracking an API that a Fortune 500 company has under active development.

-jcr

Re:What about GNUstep?

[YellowBook]

The idea that people aren't picking up Objective-C because they don't want to learn another language is preposterous. They're not picking it up because the only complete platform to develop with it is Apple's Cocoa

Agree! I've often admired ObjC, but haven't really bothered to learn it yet. Perhaps if there were nicely done Gnome bindings, but the existing ones appear to be Gnome 1.x and have bitrotted. Gnome development is one place where I think ObjC could really shine, because you get the similarity to the underlying GObject model (in C) but you get generic programming and automatic memory management, too. Oh well.

Re:What about GNUstep?

[Anonymous Coward]

I've not really programmed before (I'm a doctor), but I've had a play with XCode and bought a few books. The fact that a programming dunce like me can create some small custom apps very quickly and with an elegant interface is great. There's something about the tools and the language which just seems very intuitive to me, and I like being able to link to command line Unix scripts and MySQL. Perhaps because this is my first foray into programming I can't see some of the shortfalls of this development environment, but I like it!

Re:What about GNUstep?

[putaro]

I don't care how long it takes to learn. The problem isn't the learning curve - it's that nothing else on the planet besides OS X has good support for it. Not only do you wind up with an app tied to the Cocoa UI framework but all of your code is in a language that doesn't have good support on any other platform.

I just did an app for OS X - we did it in Java/Cocoa. Works fairly well, looks like a good Mac application. And 90% of the code is directly portable to just about any other platform.

Re:What about GNUstep?

[Twirlip of the Mists]

Don't forget, however, Carbon is simply a stepping-stone API.

That's where you're wrong. Carbon is a full-fledged operating environment on Mac OS X, just like three out of the other four.

What are the other four, you ask? Well, we have Cocoa, of course, and Java. Then we have BSD; that's how programs like PostgreSQL can run with very little modification. Finally, the four environment, the red-headed stepchild, is Classic.

Four out of five of those environments are equal peers. Classic is meant to be a stepping-stone; nobody should be developing new Classic applications these days.

Carbon, however, will never be deployed on other platforms. It's a horrible, messy kludge composed of about 15 years of Macintosh API evolution plus the necessary changes to make it work on OS X.

Erm. Have you ever done any Carbon programming? Yes, it's inelegant compared to Cocoa, but so's everything else. Carbon is actually very clean. The kludgey stuff was in the classic Mac OS Toolbox API, and that's what got stripped out when Apple created Carbon.

Do you realize, for example, that the Mac OS Toolbox API was originally a Pascal API? You wanna talk about old-school.

Re:What about GNUstep?

[Twirlip of the Mists]

With ObjC, you're stuck with that @interface and [object message] crap, no matter what.

Let me see if I understand you. You're saying that you dislike Objective C because... the @ character is unattractive to you? What?

Re:What about GNUstep?

[mcc]

The problem is not that API it's the dev tool. This guy likes xcode. Xcode is great if you want to code in objective-c but it sucks if you want to code in java. It also does not support any other language.
Apple is actively trying to bring the Java support up to the same level of quality as the Objective C support and it's getting better with every release.

As far as "other languages" go, well, XCode has builtin support for C, C++, Objective C and Java. That's not exactly bad. And while these are the only language it comes in with builtin compile support for, it does contain highlighting semantics for a decent number of other languages. I use it to write Perl all the time (and really, what do you need out of a Perl dev tool besides syntax highlighting?).

XCode also happens to be very modular, so adding additional "support" to XCode for additional languages should be something third parties are perfectly capable of. I'm not sure if they could hook into CodeSense or a few of the more advanced features of the debugger, but if you're trying to add support for a language I'm just about certain you could easily define just about whatever syntax highlighting and build process rules that you would like. (Of course, good luck trying to find the documentation that describes how to do all this...)

Instead of wasting time and money on xcode apple should join the eclipse group and make sure there is a decent plug in for webobjects (yes I know about wolips) and objective c.

I'm really kind of going to have to assume from this statement that you are not a Cocoa developer. (Of course, if what you're telling us here is that you're a WebObjects developer, then that neatly explains your animosity toward XCode, since youall have kind of gotten the shaft lately).

For Cocoa developers, Apple's Developer tools are EXCELLENT and all fit together with each other and with XCode in a very pleasant manner. And they're getting better and more elaborate with every release. I would say that the developer tools are almost as much a reason to use Cocoa as the API itself. I routinely give XCode as one of the main things I like about OS X development. I'm not sure what Apple would stand to gain by throwing it all out and starting over with a different set of tools which, while nice, aren't exactly targetted for Apple's needs. XCode meanwhile is finely tuned to Cocoa development and is getting moreso all the time...

Finally they should give serious thought to abanding objective C. Yes it's a great language but let's admit that people don't want to spend time learning it. Switch to python or ruby or something and be done with it.

First, there are python bindings for Cocoa already; I don't know if anyone's managed to integrate them into XCode yet. Second, I totally fail to see how-- if people won't bother to learn Objective C because they can't be bothered to get used to square brackets for method calls-- Apple is going to have any better luck at all with convincing people to learn Python, which is totally unlike anything the vast majority of people are used to. (Yes, it's a quick learn, but the problem with ObjC isn't getting people to learn it, the problem is getting people to WANT to learn it.)

Re:What about GNUstep?

[EccentricAnomaly]

I just did an app for OS X - we did it in Java/Cocoa. Works fairly well, looks like a good Mac application. And 90% of the code is directly portable to just about any other platform.

Couldn't you do the same with Objc and C++? The C or C++ part of your code would be protable and the Cocoa parts wouldn't be... heck ObjC is part of gcc, so the Frameworks stuff is really the only part of a 'pure' Cocoa app that isn't portable...

And a Java/Cocoa app is just as tied to the frameworks as an Objc/Cocoa app.

I have never figured out the benefit of using Java/Cocoa unless you really like to use Java for everything.

Re:What about GNUstep?

[CRCulver]

What is GNUStep -- a couple old NeXTHeads (god bless em) weekend project? How long has it been it '85% complete'? 7 years?

Most GNUstep developers nowadays never had the opportunity to use a NeXT system. They're attracted by the ease of programming with the elegant Cocoa API, but don't have a Mac. And it's no weekend project. There's work going on in the IRC channel or on the mailing list 24 hours a day.

There have also been changing definitions of "85% complete. At first it was implementing OpenStep. That's pretty much done now. Now the "85% complete" refers to implementing Cocoa extensions, which isn't really necessary for the point of the project. GNUstep can pretty fairly be called complete.

How many applications run on it? Five?

Another poster has already pointed out the many programs available. However, there are two reasons why it may seem there are few GNUstep applications available. The first is that GNUstep is often used by business for internal use. The second is that some developers put together an app just to fill their own needs. For example, I am the developer of Charmap, a Unicode character map built in OpenStep. I did it because I wanted a character map that gave abundant information but didn't have the bulk or the treat-uses-like-idiots philolosophy of gucharmap. Now, the app is useful, and in fact there's nothing like it on Mac OS X, so it is being ported and advertised in some circles. But I'm not in such a hurry because the project started as something to fill a personal need.

There's something else that needs saying: all OpenStep apps are GNUstep apps. GNUstep implements the OpenStep standard, so right away there are tens if not hundreds of OpenStep codebases that will compile with minimum effort on systems with GNUstep installed.

How many are actually complex and competitive with GTK/QT apps? Only the Mail.app AFAICT.

I find GWorkspace hella competitive with file managers like Nautilus. It does everything I want from a file manager, but has low memory footprint and doesn't try to cram a browser in.

Even Cocoa developers don't use it.

Sure they do. The developer of Books, for example, has chosen GNUstep for the non-OS X version. Developers want greater exposure for their apps, but why lose the entire codebase moving to GTK2 or QT?

Re:What about GNUstep?

[rixstep]

We've been running Macs in the family exclusively for over two years. None of us have ever had a crash. Not a one. I think it's the language. Sure, there's more, but this discussion of desktops sidesteps the issue of languages.

C is a great language. Obj-C proves that by its deferential treatment. Apple say you can learn Obj-C in two hours. Obj-C builds on Smalltalk.

C++ builds on Simula. As does Smalltalk. But Alan Kay doesn't exactly like C++, and he's the one invented both Smalltalk and the term object orientation. So that should give you a clue.

C++ is incredibly complex. It puts ordinary programming grunts in a tailspin. It doesn't even have dynamic binding. It's the quintessential simple idea that gets hairy and tangled by the time it's half done. Without a doubt C++ is responsible for most of the woes in software development today.

Obj-C makes it all simple again. The precise clear relationships you had in C, that were somewhat lost when you needed 150% more code because you needed a GUI, are back again. It's clear, it's clean, and it's rugged. NeXTSTEP has a history interwoven with Obj-C, and Apple and NeXT made additions to the language, and Interface Builder marks the first and only time these technologies have come together, but Obj-C can stand in its own right.

In short, I don't think it's relevant to port a desktop to Linux. I don't think it's a good idea, and I don't think it will give Apple any market benefits.

But the entire world would benefit if they got the language Obj-C more out in front.

Re:What about GNUstep?

[roard]

Obviously, you are a troll (you don't know what you're talking about and are unnecessary rude about GNUstep). I will respond nonetheless because some could genuinely ask why there is effectively so few applications.

First, as previously noted, there isn't just "5" applications but around 40. As you say, yes, it's not that much, for such an old project. But it could be interesting to know something: the majority of theses apps are very recent (

Now, the reason why there is so few applications is quite simple: for many years, the graphic part of GNUstep -- eg, the AppKit implementation -- was sub-optimal. And we didn't have a good InterfaceBuilder equivalent. But actually, we have an AppKit implementation that is useable (not perfect, but nearly complete, and complete enough that we start to have applications), and moreover, we have a very good InterfaceBuilder equivalent with GORM (available on the GNUstep cvs). Add on top of that the buzz around Cocoa (OpenStep and Objective-C), and it explains the recent interest of developers for GNUstep.

By the way, the reason of the slow progresses of GNUstep, is, like in many cases, the lack of developers. We don't have as much developers, by far, than GNOME or KDE. This lack of developers is mainly because few developers in the free software community knew about NeXT/OpenStep/Objective-C in the early years of the project -- and this is why we have more and more developers at the moment, because more and more people know about OpenStep/Objective-C, due to MacOSX.

The second reason of the slow progresses is simply because, contrary to KDE or GNOME, the project's goal is to implement a (complex) specification, and without the full (or nearly full) implementation, it was difficult to use GNUstep (contrary to KDE/GNOME, where it was possible to create desktops incrementaly). Now that the implementation is more or less complete, we start to see applications that uses it.

Re:What about GNUstep?

[drunkenbatman]

I own the poor blog thats linked in the article... you might be interested in knowing there's a redux article here that should probably clear up a lot of these posts & questions.

C'mon now...

[TiMac]

...what's the chance of Apple porting any libraries to Linux, and allowing anyone to run anything without buying a new Mac, every subsequent OS version, etc?

They won't even port Quicktime!

Re:C'mon now...

[minus_273]

actually its done already, its called GNUSTEP . If only the interface got an improvemnt. It woudl be really nice if we got nice modern look like KDE or GNOME.. then there could be Linux/OSX cross platform .app files :) There is a reason why the .app folders keep binaries in a folder listed by architecture .. NEXT used to use this for "cross platform" binaries.

Re:C'mon now...

[spectre_240sx]

You have to admit, though, that apple makes it quite hard for people to stay with previous versions of the OS. It seems that every time I want to install a new piece of software (often times development based) it requires panther. I've run into this many times and it gets quite annoying to say the least.

Re:C'mon now...

[Anonymous Coward]

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.

Re:C'mon now...

[tyrione]

Who the hell would port the subgraphics engine for Quartz/Quartz Extreme to Linux? Apple has been offered Billions for QuickTime and turned it down-ask Avid about it.

What Apple should do is open up the .NIB and help GNUstep folks by providing the Cocoa Hooks for KDE and Company.

GNUstep UI is a partial hack of Openstep--I used to support that beautiful OS at NeXT and Apple and trust me it is a hack, but don't blame the folks for not having the money to pay Keith Ohlfs to help.

Apple has helped with WebKit Core but if it would provide PDO(Portable Distributed Objects) on Linux you'd see a nice bedfellow who would help improve the computing landscape for both as benefactors.

More and more of Apple's applications are becoming Cocoa only Applications and come WWDC bet your ass with the lack of Carbon Sessions and multitude of Cocoa Sessions, Apple's promise of Carbon as a Transition API back in 1998 WWDC will come to peak with I am bettin' an End of Life (EOL) tag on it.

Re:C'mon now...

[tunah]

They do it for windows.

Apple

[simontek2]

I would love to see Apple Port i-Tunes, and such to linux. With OS-X being basically BSD, Their wouldn't be much work to do so. I know it would give them a leg up. I would purchase a copy of Quicktime, if it was for linux.

Re:Apple

[FlipmodePlaya]

I don't see why they don't do this. I understand that they don't want the majority of their apps on Linux, as doing that would take away incentive to buy a Mac. However, as proven when they ported it to Windows, iTunes needs as large of a user base as it can get. How could Apple be hurt by expaning said user base to a community that loves digital music, and has gone as far as to hack their way into iTMS goodness? Personally, I just want to be able to run such a great media player natively...

Re:Apple

[CptChipJew]

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).

Re:Apple

[dzym]

Keep in mind that porting iTunes to win32 increased their potential userbase tenfold. Porting to linux? Pah. Yeah, they can add a number of users to their base that's even smaller than their native userbase. Sounds like a winning idea to me.

Re:Apple

[spectre_240sx]

It's also an up and coming userbase though. Linux is growing very quickly among the younger crowd and getting them interested in macintosh software is a good way to increase their userbase down the road.

Re:Apple

[simontek2]

true, I forgot the Carbon part. And since I haven't developed anything for mac. I wouldn't have known the dash. But since they were able to port it too win32, why would it be more a pain to develop to linux. And everyone getting on my @ss bout lack of users, part of the problem is lack of Real software. OpenOffice is nice for Documents, but not html, I rather have Macromedia Dreamweaver. There are others too. I love my linux box, but it can't do everything out of the box, requires major tweaking to get DVD's to run, or to burn a decent CD. We need more companies to Develop.

Re:Apple

[Trurl's Machine]

It's also an up and coming userbase though. Linux is growing very quickly among the younger crowd and getting them interested in macintosh software is a good way to increase their userbase down the road.

It's also a "down-with-IP", "information wants to be free", "I don't want to pay for watching this movie", "I don't want to pay for this song", "down with even the most liberal forms of DRM" userbase.

Re:Apple

[HeghmoH]

With OS-X being basically BSD, Their wouldn't be much work to do so.

Why do clueless people continue to state this idiotic premise? I'm not even going to correct it, I just want to say how displeased I am to see it showing up every time Apple is mentioned. To people who will comment in the next Apple article: get a clue, and don't post this stupid thing again!

Re:Apple

[SYFer]

I agree with you.

I also think that one of the benefits Apple has enjoyed since the introduction of OSX is a certain cultural buzz that comes from their association with the *X movement in general. Instead of being a completely proprietary also-ran platform, they are now though of as "Unix under the hood" and they get additional street cred for that--even from people who barely know what that means.

Association and cooperation with the the *X world enhances their positioning as a slightly subversive, cutting edge, forward-looking company and OS.

I think *X is a little like the Seattle grunge-rock scene was vis a vis mainstream rock back in the early 90s and I think that Apple has consistently, through their marketing at least, sought to occupy that kind of space on some level.

To me, it makes sense for Apple to spend more time on this market--even if the case isn't quite there yet in terms of the kind of hard numbers that uaually drive mainstream marketing departments.

Re:Apple

[squiggleslash]

While this is true, it would also give Linux users one less reason to create libre iTunes clones, reverse engineering the various protocols and pseudo-DRM features of the original.

How many tools to hack the various copy-prevention schemes of RealPlayer do we have? Pretty much none, despite the wealth of content only available via Real's player. Seems likely to me that this is because, in large part, because Real distributes a Linux/ix86 player that supports all of this, so it just isn't a high priority thing to get done. The nearest I've seen to anyone "hacking" this is the MPlayer crew, and all they've done is call the Real libraries to play Real content, they haven't touched the streaming portion.

For all the propaganda about Linux users just being thieves and pirates who want all their stuff for free, for the most part most Linux users, developers, etc, are happy "enough" if they can merely access and view the same content they can view on other platforms. It's arguable that tools like DeCSS would have either not been developed, or would at least have been ignored by the wider community, if a free or cheap-enough DVD player had been released for Linux before it had been written. About the only hack I can imagine anyone would have done anyway would have been to remove region locking. And maybe the thing in my journal, but only now, because disk prices have only recently reached a point that this would be worthwhile.

I think there are good reasons for Apple to consider releasing anything that "locks content" for Linux. Their past experience should show them that burying their heads in the sand and pretending that most people who'd want the content would be willing to switch to a Mac to get it, and the experience of Real Networks (positive) and Microsoft (WMA, everyone's reverse engineered it) and the DVD CCA (negative) and themselves (QuickTime/Soresen) should show them they can't really ignore that market, much as the size of it means they want to on commercial grounds.

Re:Apple

[squiggleslash]

You can bet any big/little endian issues are resolved, as Apple has ported Quicktime and iTunes to Windows using Carbon (or Carbon's immediate predecessor.)

Great, the two minute between postings regardless of how many postings you've made recently thing has kicked in so let's find a joke to cut and paste. Please ignore the below if you're reading this because it's labelled "Informative" or "Insightful", but carry on if you're trying to find out what's "+5 Funny" about Quicktime and big-endian issues.

A gynecologist became fed up with malpractice insurance and overwork. Hoping to try another career where skillful hands would be beneficial, he decided to change careers and become a mechanic. He went to a local technical college, signed up for evening classes, attended diligently, and learned all he could. When the time for the practical exam approached, the gynecologist prepared carefully for weeks and completed the exam with tremendous skill. When the results came back, he was surprised to find that he had obtained a score of 150%. Fearing an error, he called the instructor, saying "I don't want to appear ungrateful for such an outstanding result, but I wondered if there is an error which needs adjusting."

The instructor said, "During the exam, you took the engine apart perfectly, which was worth 50% of the total mark. You put the engine back together again perfectly, which is also worth 50% of the mark." The instructor went on to say, " I gave you an extra 50% because you did all of it through the muffler."

(Interestingly this joke actually did have something to do with endian issues, and I punched it up at random. Hmmm.)

Re:Apple

[Twirlip of the Mists]

With OS-X being basically BSD, Their wouldn't be much work to do

Every time a Slashdotter posts this, God kills a kitten.

linux can learn alot from apple

[abandonment]

this is a good thing, not a bad thing.

seriously, linux is already a larger presence than apple in the market, there are major players that have just entered, and haven't even begun to reach their full capacity (novell in particular) and in general - linux could definitely learn a thing or two from apple, particularly in the interface and ease of use department.

i don't see how apple could become any more of a threat than it is currently, and if anything, it becomes a powerful marketing force to help promote linux/opensource in general - we want them on our side after all...

Re:linux can learn alot from apple

[the_2nd_coming]

the linux presence in the market is an estimation. if you go on pure factual numbers from statements, Linux is still behind.

Re:linux can learn alot from apple

[the_2nd_coming]

yes it does. when you count up the DOCUMENTED deployments of Linux, Macs are still ahead of them.

Yeah

[CptChipJew]

Except the biggest thing holding Linux back is that it's not easy enough for the average user that isn't particularly computer literate.

Linux needs to be easier to setup, be easier to use, and have less trouble with various devices (e.g. audio).

Re:Yeah

[the_2nd_coming]

Linux, if it wants to gain more share int he desktops, needs to become much more froendly with the Digital cameras, DV cameras, and scaners.

it then needs high quality photo apps and Video editing apps.

after that, it needs high quality DVD authoring apps.

all of these apps need to work together smoothly and there needs to be a workflow the exists between them so you can export from one into the other from each app. oh and fix the GIMP... maybe par it down and use it as a base for the photo application, get a red-eye, touch-up and enhance, plus a few other simple things going. then get the app set up so you can upload to clubphoto and snapfish, etc.

if you make the consumer applications for making bad home videos, touching up and ordering bad home photos, and collecting music files, all in an nice integrated workflow, then consumers will come.

Re:Yeah

[deinol]

Easier to use, yes. Easier to set up? No.

I have worked in a computer store as a tech before I moved on to becoming a consultant for small businesses. If someone made a linux distro that was easy to use for an average user (web browser, e-mail client, office suite), people could start using it.

I trained monkey, I mean, tech, can install linux just as easily as windows. The "average" user comes into the store or hires a consultant and pays $79+ to have windows reinstalled. The "average" user doesn't install windows at all. Or if they do, it is on a click once to restore your hard drive to factory settings sort of deal.

Sure, while a real linux power user is going to want an costumizable install, the average user needs a one-click install that is easy and intuitive to get started with.

Re:Yeah

[burns210]

i want 1 thing from linux, a standard config setup, and a way to access that in 3 ways...

1. gui. this should be windows like, checkboxes, textboxes, menu items... lickable guiness
2. command line, with flags, recompiling(if i have to), or sub commands of something to tweak an app.
3. text file config editting. just open it in vi or openoffice.org and change the 1 to a 0.

They all should work, on all apps, they should be able to switch from 1 to 3 to 2 seamlessly without hickups, and they should have clear documentation on what the hell each thing means.

Re:Yeah

[MasonMcD]

Linux, if it wants to gain more share int he desktops, needs to become much more froendly with the Digital cameras, DV cameras, and scaners.

it then needs high quality photo apps and Video editing apps.

after that, it needs high quality DVD authoring apps.

all of these apps need to work together smoothly and there needs to be a workflow the exists between them so you can export from one into the other from each app. oh and fix the GIMP... maybe par it down and use it as a base for the photo application, get a red-eye, touch-up and enhance, plus a few other simple things going. then get the app set up so you can upload to clubphoto and snapfish, etc.

But now you've described a lot of Apple's value-add, and frankly why they're a 10 billion dollar company. That stuff is really, really hard. Not that linux coders aren't up to the task, but to coordinate all that would be a nightmare.

And likely, if any programmers showed such facility for herding the cats and whipping up some inter-app processes, they'd be snapped up in a VC minute by Apple or MS.

Re:Yeah

[Twirlip of the Mists]

this should be windows like, checkboxes, textboxes, menu items... lickable guiness

I'm all for it. But... how do you get the beer to come out of the screen? Some kind of custom video driver?

Apple frameworks on Linux would be excellent

[vijayiyer]

I am looking to write some software for a project of mine. Being a Mac user, I will write a Mac version. Understanding market realities, I will have to write a Windows version. I'd love to have a Linux version which would be a straight recompile, but that's not possible yet. I'm aware of and considering GNUStep, but I really would like a straight recompile. Apple hardware would likely sell itself if it didn't have fewer available software titles, and having excellent cross-platform development tools would result in greater software availability.

Re:Apple frameworks on Linux would be excellent

[Anonymous Coward]

I'd love to have a Linux version which would be a straight recompile, but that's not possible yet.

Don't be so sure. Write once. Compile anywhere. wxWidgets.

(Oh, and it works, too. AOL Communicator uses it.)

Re:Apple frameworks on Linux would be excellent

[jared_hanson]

Check out Qt (no not QuickTime). That toolkit provides an incredible amount of useful utilites and is very high quality. It runs on Linux, Mac OS X, and Windows. With a little bit of care, you can build applications that recompile to any of the aforementioned OSs.

As much as I respect Cocoa and Objective-C development on OS X, the one thing Apple really needs is a high quality C++ toolkit. Even though the benefits of Obj-C are worth it, it can be quite hard to convice developers to learn a completely different language to develop in (native language, so don't tell me Java). I'd really like to see Apple partner with Trolltech and include Qt by default in OS X and eliminate or reduce the fees for developers who target Qt/OS X.

Re:Apple frameworks on Linux would be excellent

[Queer Boy]

Java is a native language when using Project Builder.

Re:Apple frameworks on Linux would be excellent

[The Vulture]

I have to give a thumbs-up to wxWidgets as well. At the moment, I'm using it for a personal project, that is being developed in Linux, but the Windows market is a much larger audience (most people have a Windows machine at their desk, not a Linux or UNIX machine).

The code, using only wxWidgets calls (and other code that compiles in MinGW) compiles very cleanly under Windows (although using net-snmp does add a couple of steps more convoluted than "./configure;make;make install"). I used to use Qt, but switched in part to the lack of a GPL'd version (yes, I know that it has been ported, but it's not TrollTech's official Win32 tree), and the API in wxWidgets is comparable. Plus, wxWidgets uses the Windows native widgets, unlike Qt, which TrollTech says are done via a "style".

-- Joe

Re:Apple frameworks on Linux would be excellent

[Graymalkin]

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.

Re:Apple frameworks on Linux would be excellent

[Twirlip of the Mists]

The idea of write-once-compile-anywhere is a pipedream. We've all known this since the early 1990's when we saw the failure of projects like Java AWT.

If you use a cross-platform GUI framework, you're going to produce substandard applications. That's pretty much the end of that.

So the user interface will have to be native for each target platform. That's fine. If you use the model-view-controller paradigm, the largest fraction of your application code can remain unchanged across platforms; only the view, the UI, needs to change.

Re:Apple frameworks on Linux would be excellent

[jcr]

Mindshare doesn't pay the bills. For example, Java has an enormous amount of mindshare, but it's not translating into massive revenues to Sun.

-jcr

Re:Apple cant do any worse

[LOL WTF OMG!!!!!!!!!]

Apple DOES help the open source community. Both Konqueror and FreeBSD are much improved thanks to Apple's contributions.

Apple Success

[KajiCo]

Personally i believe that Apple owes alot of it's success to linux and the rest of the open source community. I personally use my Mac now than my PC for the simple fact that I have the ease of use of Windows ( and better security than Windows), and the power of Unix. I have used linux before, and frankly it still has a long way to go before i consider it my OS of choice, however with my Mac, i can just as easily use the commercial software i need while at the same time still getting an education in the unix enviornment.

To me Apple has been my gateway to opensource projects, and a greater understanding of 'nix line of OSes, i've been able to understand the structure better and faster than i could while using linux directly. Most of the software i run on my Mac is opensource.

Re:Apple Success

[LanceDBoyles]

. . . I have the ease of use of Windows. . .

Cough! (puts down his whiskey)

Pardner, Them's fightin' words in these parts.

Re:Apple Success

[int69h]

How exactly does Apple owe any of its success to Linux? Steve Jobs was in the Unix market before Linux was even a glimmer in Mr. Torvald's eye. Also , let's not forget Apple's previous Unix, AUX, or the fact that OSX IS BSD! The do however owe alot to the Opensource community. (Apache, FreeBSD, GNU, etc.)

Re:Apple Success

[DannyO152]

I agree with sibiling posts about Linux keeping Unix alive and introducing it into consumer markets. I was introduced to Unix in 2000 and while we were using Solaris in the lab, it was loopback Mandrake on my machine at home. And I discovered that I prefer unix-like operating systems to Windows.

But let me add this point. Linux and GNU have created an ecosphere for developers who want to scratch itches. With Linux, there is a minimal barrier of entry, no one whines at you when you decide to move a piece of code (such as the os) to a different cpu, no one resists or makes your life difficult if you choose to stay with kernel 2.2.x, and, when combined with its adherence to the unix tradition of giving you the tools to solve your problems, it provides a place to go when its time for code as recreation (re-creation!).

Linux gave the GNU tools a huge boost and, in some sense, a more-or-less philosophically compatible home. And this in turn meant when Apple was ready to take NextStep prime time, as you note, darwin could include or add nfs, samba, xml-parsing, apache, X11, and so on. Linux also meant there would be consumers who would see that Apple's inclusion of open source and free software was totally cool.

damn that hurt my head.

[l0ungeb0y]

Last time I read a drunken rant by a blogger EVAR!!!!

I read and read and read...
but still don't quite get it all.

I think he's whinging about the lack of developer exodus from the wintell .NET camp on over to CoCoa/Objective C.

Well durrr... I think it comes down to wanting to fill your pocket with something more than lint.

Not intending to troll, and I'm typing this on one of my 2 powerbooks, it's just that not many a 3rd party have gotten rich developing for Apple platforms. And when people do have a successfull product, Apple has tended to come up with their own version in house that kills the 3rd party app. On occasion, Apple has been known to be nice and just acquire said tech, but lately, they've taken no prisoners. Most the big apple apps these days are apps that used to be made by third parties. Most are rather raw at this time such as Garage Bad (Acid Wannabe) while Final Cut has slaughtered Premier.

When looking at Apples treatment of 3rd party apps and developers, their monolithic approach and the fact that in the last 5 years they've gone through a MAJOR OS change and have now migrated their processor architecture to 64-bit I'd expect most people to be keenly interested but taking a wait and see tact.

Surely, OS X is a beautiful OS and Apple puts out some sexy hardware, but with ~5% marketshare, not many are exactly looking at OS X as *the* platform to be developing for when it comes to reaching the masses and driving your sales figures.

Hopefully the G5 will catch on when they release the die-shrink to 90nm and the speed boosts to both 2.5ghz and 3.0ghz over the course of the summer. Personally, I've been waiting for that boost myself and plan on buying one when the 3ghz comes out.

But when it comes to 3rd party development for OS X desktop software? I'm not holding my breath waiting for a glut of new 3rd party apps anytime soon.

Re:damn that hurt my head.

[Queer Boy]

Most are rather raw at this time such as Garage Bad (Acid Wannabe) while Final Cut has slaughtered Premier.

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.

Re:damn that hurt my head.

[droleary]

But when it comes to 3rd party development for OS X desktop software? I'm not holding my breath waiting for a glut of new 3rd party apps anytime soon.

If by "anytime soon" you mean "a constant stream for the last 5 years", then there really is no need for you to hold your breath. For example, check out our Mac Aggregate Tracker, which lists new releases from a number of sites. You'll see 3rd party updates numbering over a hundred most weekdays. Exactly how much more 3rd party development do you need?

And OSS Web Objects to complete the picture.

[pschmied]

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

Re:And OSS Web Objects to complete the picture.

[quigonn]

GNUStep is pretty cool. It's like a slightly primative, somewhat ugly Mac.

What you call "ugly Mac" is what I call NeXTstep/OpenStep look and feel. Of course it looks primitive, but that's late 80's GUI design, and IMHO pretty progressive compared to the other GUIs that were around at that time.

Re:And OSS Web Objects to complete the picture.

[Anonymous Coward]

> Gnustepweb is a framework that is supposedly compatible with WebObjects.

Well, sorta. First off, it's a clone of WO4.5, not 5.x. It's Objective-C only, which to my view is a good thing. I loathe and despise Java WebObjects. The web side is pretty good, but the database back end is - well - full of holes. Shame really. I'm using it for putting out websites at the moment, but there are a few things that are holding it back. These are:

Lack of graphical tools for putting together pages. It's OK if you know WO, and aren't afraid of editing by hand, but there's no WO Builder.

As I said before, the database back end (EOF clone) is lacking. Particularly, it doesn't handle inheritance at all (which can be worked around), and doens't seem to like flattened attributes either. There's also no EOModeler clone. And there's a bug that's been outstanding in KeyValueCoding for - well, forever, as faar as I can see - that breaks eogenerator. Looking at the gdl2 code, all I can say is that it's hacky. I mean, kudos to the guys and all, but, particularly around EOEntity and EOModel, it sucks. They've been optimised, highly prematurely IMO, and about a third of the most important functionality still doesn't work. Once I've delivered the projects I have on the go at the moment, I'm gonna rewrite the whole EOEntity and EOModel handling side, and drop it into their hands.

Still, all said and done, it's a lot better than nothing.

Ok, one sec...

[dimator]

This eventually meandered (alcohol was involved) into a much larger topic:

What the hell is going on with independent development & the Mac?

ONLY geeks talk about Macs and technology when they are drunk!

Re:who needs apple

[jared_hanson]

the important thing is the applications, not the underlying toolkits and frameworks

Applications are created using the underlying toolkits and frameworks. The higher the quality of these frameworks, the better the applications will be. The easier the frameworks are to develop with, more applications will be developed more quickly.

Its a chicken and egg sort of thing where the egg definately comes first.

no dev model

[b17bmbr]

as a java/perl/php/web developer, and linux screwer arounder in C, using linux since '97 (honestly) and a recovering VB luser, i noticed that apple deveopment sits in between the two big models. one, the pure commercial, big shop model with apps like dreamweaver, photoshop, and the movie stuff, and the open source and *nix model. look around at some mac apps from small developers. they all wnat $5 or $10 and they're not very good. since they won't be boxed item software, they could but don't take advantage fo the open source model. while macs have probably more pure desktop share than linux (it's close at least), there ar 100X more linux developers, and the real movement in OS X dev is on the BSD front, the fink and darwin projects. i came to the conclusion that small mac developers don't "get it". i have played with cocoa/obj-c a it is an unbelievable combo. it is truly phenomenal. anyways, the problem isn't apple's developer programs, it's mac developers. at least with linux, if i have a really shitty app, 1) it's open source and 2) there are 20 other like apps that are open source.

although windows doesn't have huge open source legions, it has 90%+ of the desktop market, so 90% + of the developers will target it, and, the tools ar not that expensive, really. plus, there has been nothing like VB to amke us all think we're uber hackers!!! the only thing that would have sustained a huge mac deevlopment process is open source, and it never happened.

Not going to happen

[g3head]

Seems to me that the article is forgetting that Apple has been, and probably will always be, a hardware company. It's certainly not going to change as long as Jobs still has influence at Apple. Any attempt to change that has failed misserably (the clone era) or died an obscure death (attempts at porting the Mac OS to x86, some of which were successful to a degree)

Even the rare bit of software that Apple has developed has been serving some other purpose, like iTunes and iTMS selling iPods. So to apple the question is going to be "What will we sell if we port the frameworks?" If it isn't overpriced hardware theres no chance in hell of it happening.

Furthermore what Apple has done with Darwin and keeping that open source has been tied down with conditions and restrictions that to barely support open source development.

Sure it would be great to see Apple throwing its weight behind *nix to form an alliance that could present a channenge to Microsoft, but in reality its never going to happen.

Re:Not going to happen

[Queer Boy]

Seems to me that the article is forgetting that Apple has been, and probably will always be, a hardware company.

Oh, God, someone else declaring themselves an Apple authority without knowing what the hell they are talking about.

Apple is a widget company. They are hardware and software, relying on both to sell the other. Just like Sun, SGI and Sony. Apple is not now, nor have they ever been, nor will they ever be anything but a widget company. They want you to buy it all or nothing, and have had a very good and successful go of that.

Only in America will people say you are a failure for not making ENOUGH of a profit.

you need a mac to develop on one..

[js3]

Many developers don't develop mac software because they down own a mac. If I had a mac I would probably start writing a bit of code here and there but as a dude who only has a PC I have zero interest in developing for the mac. It has everything to do with market share. Unless I have an application that I feel would be useful on the mac and will bring in lots of money there is no reason for me to write for the hell of it. I'm sure this applies to many small-medium sized software development houses too

Cocoa for Windows exists

[goMac2500]

When OS X originally was announced, it wasn't called OS X at all, it was called Rhapsody. Carbon didn't exist under it, it was pure Cocoa. The plan called for the following 1) Rhapsody for Mac: a full fledged Rhapsody OS for Mac, 2) Rhapsody for x86, a full fledged OS for x86, 3) Yellow Box for Mac OS, a layer to run Cocoa programs under OS 9, and 4) Yellow Box for Windows, a layer to run Cocoa apps under Windows. Sadly Apple morphed Rhapsody into OS X, killing all the other versions except for the Mac version. These days you can still find Rhapsody x86 on some peer to peer servers.

Re:Cocoa for Windows exists

[necro2607]

Indeed, I just recently installed and ran Rhapsody on an x86 system of mine. The networking didn't work properly (due to lack of a proper driver), but it was kind of cool, and I suppose in some way ironic, to have an Apple OS running on an Intel processor... :)

It was interesting, but it felt kind of awkward with the NeXT influence just kind of thrown in there, because it didn't really fit in with the Mac OS interface.

You can definitely see how Rhapsody became Mac OS X, as Rhapsody was based upon the Mach kernel just like Rhapsody, and NeXT before it. I think one place where Apple made a large change is when they decided to have the UNIX side further integrated into the Mac OS itself, creating a closer-knit combination of the two, rather than having them so seperate and awkward-feeling as it was with Rhapsody.

Of course, you can see that many NeXT and Rhapsody elements survived, like the layout of the File Manager which is almost identical in OS X to what was in Rhapsody and NeXT.

For some screenshots go here or here.

Also, here's something pretty interesting: screenshots of Mac OS X server before the Aqua GUI was added, still existant on the Apple website!

Re:You cannot polish a turd.

[uroshnor]

"Apple putting their framework on Linux would be akin to putting a Ferrari body around a Lada engine."

You appear to forget that even Lamborghini make tractors.

Developer-friendliness

[captaineo]

Microsoft realized early on that in order for their platform to dominate, they MUST recruit as many third-party developers as possible. This is one of the main reasons, if not THE main reason, that Windows acquired its huge desktop market share. (make fun of Steve Ballmer for his "DEVELOPERS! DEVELOPERS! DEVELOPERS!" monkey dance if you want, but that's why he's a billionaire). Microsoft bends over backwards to help developers. They give away excellent development tools with excellent documentation and support, just so that you'll write Windows programs. They nearly kill themselves checking backwards compatibility with every Windows release, just to make sure your poorly-written Windows program doesn't break when Windows XP comes out.

Apple seems to care about its users somewhat, but not at all about its developers. There just isn't the same level of outreach nor the same "developers come first" attitude as Microsoft. And not nearly as much care about compatibility. e.g. how many OSX programs broke with the OSX 1.2 and 1.3 updates?

Both companies offer excellent APIs that are specific to their platforms (e.g. DirectX on Windows and Cocoa on Mac). But Microsoft has an advantage here. If you write your program to use Windows-exclusive APIs, you still have 90% of the potential market. But if you use Apple-specific APIs, you cut yourself down to 10%. THAT is why .NET and Java are attracting developers, and Cocoa is not.

Any rational desktop software company will develop for Windows first, and then, if it seems worthwhile, they'll make a Mac port. There is a small market for Mac-only stuff but I don't think it's a reasonable business strategy to support ONLY the Mac. For one thing, Apple has a habit of shipping free products by surprise that demolish the market for an established Mac vendor. (how'd you like to be a Mac-only calendar/email application developer the day after iCal and Mail came out? or MetroWerks' Mac team after Xcode?). This is outright developer-hostile behavior.

Re:Developer-friendliness

[Anonymous Coward]

Hmm...no sign of a developers tools CD in my XP pro box, but in my panther box...aha, there it is! My _free_ developers tools.

Re:Developer-friendliness

[Anonymous Coward]

No!!! Both companies don't offer excellent API's. Use both and you'll know why Apple is more developer friendly. Besides, Apple provides Developer tools right in the box of the OS. That's a huge first step to being developer friendly. IMHO, cleaning out bad or old school APIs are a good thing.

As far as Microsoft being ISV friendly. They've screwed over quite a few of theirs -- Stacker and Citrix comes to mind.

Re:Developer-friendliness

[SJ]

You should clarify the fact that "Microsoft bends over backwards to help developers."

It should have read "Microsoft bends over backwards to help developers that do not occupy a space that Microsoft wants."

Look at how much MS shat on Real, Netscape, Apple, Citrix, Corel and god knows how many other companies because they were in a space MS wanted.

Re:Developer-friendliness

[HeghmoH]

And not nearly as much care about compatibility. e.g. how many OSX programs broke with the OSX 1.2 and 1.3 updates?

Roughly zero. Apple is very good about not breaking apps, and they basically never break apps that don't rely on undocumented behavior.

If you go to http://home.earthlink.net/~mrob/pub/missile20.html , you'll find a Mac clone of Missile Command that was written for the original 1984 Macintosh. I just downloaded it and tried it out for kicks; it works perfectly in Classic on OS X 10.3.

how'd you like to be a Mac-only calendar/email application developer the day after iCal and Mail came out? or MetroWerks' Mac team after Xcode?

Mail shipped with the OS since the beginning, so that one doesn't make a lot of sense. (And what is Outlook Express, chopped liver?) I'm totally unfamiliar with Mac calendar apps, so I can't comment on that. But the CodeWarrior thing I can comment on, namely that CodeWarrior's Mac version is still being sold and still going strong. I haven't heard of any sackings, plans to cancel the product, or any other lamentations from them.

Of course, Microsoft's tactics of using legal and illegal bundling to kill all competition in various application spaces e.g. browsers is no problem at all.

Re:Developer-friendliness

[Anonymous Coward]

Read the EULA, apparently it doesn't allow you to develop commercial software or possibly even FOSS software (says internal use only). Also, it apparently does not include the IDE/GUI tools. And it further restricts its use to only for Windows platforms. Free yes, practical hardly.

None of these limitations exist with Apple's free tools. Use them for anything you want, even for other platforms (if practical of course).

Nice start on MS part but hardly where everyone else is right now. If they wanted to be close too even they would release Visual C++ Standard as a free download. Last I checked that was more than $100 US.

BC

Re:Developer-friendliness

[Jodka]

Its obvious from your post that you are a phony expert, only posing as a developer, whith no actual experience. Perhaps you should include disclaimer, "I am not a real software developer but I play one on Slashdot".

"both companies offer excellent APIs that are specific to their platforms (e.g. DirectX on Windows and Cocoa on Mac)."

There is first piece of evidence that you don't have clue what you are talking about: DirectX and Cocoa are not comparaible APIs. DirectX is the Microsoft's graphics API for video games. A comparable API on OS X would be the combination of Core Graphics and OpenGL, aka Core OpenGL. Cocoa is an Object C object library, not a Graphics API optimized for video game programming.

"Apple seems to care about its users somewhat, but not at all about its developers. There just isn't the same level of outreach nor the same 'developers come first' attitude as Microsoft."

If you actually developed on Windows and OS X, or had even attemped it, the first thing you would notice is that all of Apple's development tools are excellent and free, including Project Builder/Xcode and debugging tools such as Shark. Microsoft's Visual Studio.net costs $1000.00 per workstation. If you install on both home and office machines, its $2,000.00. I have the full set of Apple development tools installed on my laptop, desktop at home and desktop at work. Total cost: $0.00. The comparable setup for Windows would cost me $3000.00. For that reason I only have Visual Studio installed on one computer at work. Oh, and Visual Studio required that I sit and feed the damn thing six CDs over the course of hours. Apple developer tools only takes a moment to install from a downloaded package.

Then there is the issue of support. Apple hosts free topic-specific mailing lists and Apple's own programmers who develop the OS post replies to these lists. Thus if you develop for Apple, you can get good answers straight from the developers for free. I haven't found anything comparible offered by Microsoft.

"Apple has a habit of shipping free products by surprise that demolish the market for an established Mac vendor. (how'd you like to be a Mac-only calendar/email application developer the day after iCal and Mail came out? or MetroWerks' Mac team after Xcode?)"

First of all, third-party developers do not have god-given right to monopoly. Others can and will compete, possibly among them the OS vendor itself. Maybe its doesn't work that way on the Planet of Make-Believe Developers where you come from, but down here on earth its just a fact of life.

Secondly, how is this meaninfully different than what Micosoft does ? How would you like to be developer working at Netscape the day before Internet Explorer was announced ? Not to mention that Microsoft not only expands into new markets but takes the opprotunity to establish closed standard (MS Office document formats) or pervert existing standards (Java, Kerberos). Apple helps develoers by adhering to open information interchange formats. Microsoft is downright adversarial, making enemies of developers by promoting closed document formats accessible only by Micrsoft applications.

Re:Developer-friendliness

[schwatoo]

But the CodeWarrior thing I can comment on, namely that CodeWarrior's Mac version is still being sold and still going strong. I haven't heard of any sackings, plans to cancel the product, or any other lamentations from them.

Actually CodeWarrior has become something of a joke on Mac OS X. CodeWarrior used to be the premier dev environment on the Mac but ever since OS X was released it has been declining in usefulness and popularity. This coincides (extremely roughly) with MetroWerks being bought by Motorola and CodeWarrior being aimed mainly at embedded systems. If you do legacy development then of course CodeWarrior is the dev environment to use - but for any new development I think most developers are choosing xcode

Re:Developer-friendliness

[MoneyT]

So microsoft is developer friendly, but I don't get a disk, I have to go looking for the tools, and then they don't even provide me with an IDE?

Yes microsoft may love it's developers, but Apple is learning fast and doing things better (again)

What was this about?

[GnuPooh]

Is it just me, or is the point of this article confusing at best? The Blog starts out talking about how there should be lots of Mac developers, but there probably isn't that many. Then goes in to a history of OSs over the last few years, esp. the ones that didn't make it.

But I'm most confused about what the Slashdot poster is saying....what does Longhorn have to do with this blog? I'm an experienced developer and I can't follow how any of these things are connected. It just seems like rambling buzzwords from Mac lovers.

Why I...

[Anonymous Coward]

...would like to have a Mac:

1. You open the box, plug it in, use it. End of story,
2. I know that it's built on *BSD,
3. It's not Windows.

Why I don't have a Mac:

1. Too expensive, can't afford it.

Why I would like to be using Linux:

1. It's free,
2. It's not MS Windows (therefore stable and secure).

Why I don't use Linux:

1. My must-have applications won't run on it (or at least not without some geek-tweak),
2. Experienced Linux users seem to be more interested in pissing-contests than helping new users.

Why I wish I didn't have to use MS Windows:

1. It sucks, it really does, no matter what MCSEs might shriek in its defence. I'm so sick of having to dance naked in the virus and spyware minefield every time I boot it up.

Why I use MS Windows:

1. What else am I gonna use? Refer previous sections.

When Apple drops their prices then I'll buy a Mac; or when Linux developers stop trying to be so damn 133t and focus on user-friendliness; and the must-use applications (or equivalents) I need become available for that OS, I'll give Linux another try.

You can sneer at me and all the others like me for being n00b luser whatevers (and most of you apparently think you have to), but not everybody has the free time necessary to learn all the arcane rules of the High Priest's OS.

Re:Why I...

[xirtam_work]

It's not all that expensive any more. Check out the new eMac. It's got everything you'd need to get started on the Mac platform.

Don't worry about the 'lack of expansion' because you can plug in more hard drives via fire wire and the memory can be expanded easily as well.

as for the 17" crt monitor it's fine.

there's no need to drop thousands on a Mac, especially if it's your first one.

over on wired.com there was an article the other day about people making windows xp look like os x. one of the reasons used to justify there actions was 'i have $3000 pc, i can't afford a mac'. for less than $1000 you can get a mac with a dvd writer (superdrive) and a ton of great software including development tools.

p.s. don't forget to drop in some more ram, you're going to need at least 512mb (but don't buy the ram from apple - they are definately too expensive on that!)

Re:Why I...

[vonFinkelstien]

You probably don't need a G5 or a PowerBook.

Go to a Mac web-dealer that has used and refurbished Macs. Find an iMac, eMac or iBook that suits you.

Get an instant Apple loan (We're talking $20 - $50/month).

Enjoy your Mac for 4-6 years (assuming it is not an ancient used one).

Re:Why I...

[dustmite]

"Windows PCs are only cheaper than Macs if your time has no value".

Underlying assumption wrong?

[bullitB]

The stated assumption of this rant is:

"But as far as big, high-quality apps... there just aren't many, and those that are being released are from the usual suspects. Nothing much new."

My question is, couldn't this could really be said for any platform (except maybe Linux, and even then mostly via porting)? What major, big, commercial, ground breaking applications have been release on Windows in the last 3 years that weren't there before? The Mac has lost Framemaker and Premiere, but what successful new applications has Windows gained? Is this really an effect of a larger fallout in the software development world?

Apple supported GNUstep would be a fine thing

[gsdali]

We would love to port the products of the company I work for to OS X and Linux. Mainly so we can leverage whatever the best processor available at any time is. Unfortunately without compatibility products in certain areas it won't happen. If GNUstep and cocoa were in sync this would take care of a lot of issue. OpenSource products already solve most of the other cross compatibility issues. The overarching set of frameworks is the big hurdle.

Apple could swing a lot of converts with a write once, compile everywhere system. I'm not interested in Aqua on windows or Linux, in fact I'd prefer the interface to be OS consistent, (one of the big swing gui and X11 on OS X issue). Being able to produce an app for which ever platform the customer wants or has the best processors.

If we'd had an OS X based solution for our core product (a broadcast playout system) we could shift a lot of Macs and a lot of copies of final cut pro. The all Mac workflow isn't necessary but it looks attractive, especially with XSan, XServes, Motion, even iMovie thrown into the mix (it may seem hard to believe but there are some people using iMovie to edit for broadcast and for cuts only editing why the hell not). However the activation energy hump to port to OS X is too high at the moment, we can't afford to develop for two platforms unless we get a little help. We can't afford to move to OS X exclusively, what if another processor bottleneck happens as happened before the arrival of the G5, we'd feel much safer if we had Xeon, Opteron and PPC as options in case one stalls.

So come on Apple, you will sell more hardware, more crown jewels software if you make cross platform a doddle.

Re:Apple supported GNUstep would be a fine thing

[Warhaven]

Apple could swing a lot of converts with a write once, compile everywhere system. I'm not interested in Aqua on windows or Linux, in fact I'd prefer the interface to be OS consistent, (one of the big swing gui and X11 on OS X issue). Being able to produce an app for which ever platform the customer wants or has the best processors.

There's a company here that sort of does this for DirectX based games - write once, compile for both Windows / OS X, with very little modification (if any) to the code. Unfortunately, I still won't see many of my favorite DirectX-based games on OS X, despite ease of portability. It always runs into the requirements of more tech support, coders, and personell to address Macintosh-related issues and bugs, which all adds up to more costs.

No one "Gets it" yet

[curtlewis]

Long ago, when operating systems were primitive, it was all about applications. And in many ways, that is still important. But it's more than that in the modern technological world we live in.

You can put all the applications in the world you want on Linux and it will still suck the sweat off rhinocerious testicles as a desktop system because the GUI is still very primitive. Sure, you have have a lot of flash with Gnome and KDE, but they still lack the detail of Windows, OS X or the old Mac OS.

Linux HAS come a long way with Plug and Play, but it still has a long way to go. I'd love to play with Linux on a laptop, but I know I just can't go buy any laptop and have a hope of it actually working. And then wireless would be problemative, not to mention the inferior power management. A good part of this is Catch 22. There are often no drivers, or inferior ones, for a product because little attention is given to Linux drivers. That is slowly changing, but not fast enough.

When Linux can handle a USB memory card reader with ease, multiple types of digital cameras, desktop integration of CD and DVD burning (which I don't use, but many ppl like this), effortless setup of audio cards (which is still a nightmare) and similar modern ease of use features, it will be close to being a desktop competitor. But for now, it sits as a workstation and server OS with limited appeal.

The offtopic parable of mister Lamborghini...

[CaptainCheese]

Actually, once upon a time, Lamborghini only made tractors. And mister ferrari lived nearby.

Then one day, mister Ferrari said something rude about mister lamborghini and the quality of his tractors.

Mister Lamborghini took it personally.

Nowadays, of course, Lamborghini and Ferrari still live within a couple of miles of each other.

But mister Lamborghini makes better cars.

The biggest problems with Cocoa

[coolsoldier]

I develop with Cocoa on OS X, and while it's is remarkably easy to program in once you're used to it, it's more than a little, shall we say, messy.

The classes contain endless numbers of "convenience" functions that don't really belong where they are. Witness that the STRING class has methods like stringByAppendingPathComponent, and similar other functions that should be in a separate class for paths. Meanwhile, Attributed strings do not respond to any of the standard string methods, although they do respond to methods to do things like load RTF files.

The problem is that Cocoa is not straightforward enough to be easy to program in without an intimate familiarity with the API. It's just too different from anything else out there. Now that I'm used to programming in it, I can develop an application faster than I ever could with windows APIs, but the learning curve makes it difficult.

The other thing about Cocoa, which the article doesn't quite get to saying explicitly, is that the design of the API itself actually makes it very difficult to get apps to the mac from other platforms.

Cocoa is designed to be easy for porting applications to other platforms. But you can't port applications to other platforms because Cocoa isn't available for other platforms. What Apple needs for their existing strategy to work is an API that is easy to port existing programs to. They sort of have this with carbon (hence why most applications that get ported from windows are written using carbon APIs), but they don't take advantage of a lot of features (like system services, and automatic spell checking) that only work with Cocoa programs.

It would be nice if Apple would port their APIs (or at least support something like GNUStep), but if they won't, then they need to make their "strong" API something that can easily be ported to. There are oddities in Cocoa that make incorporating code from anywhere else almost impossible.

In short, Apple's programming tools and their corporate strategy are incompatible. The article frames this as a problem with Apple's strategy, but it could just as easily be seen as the tools not fit for the job. Apple started out with Rhapsody to try and make the mac the premier program for development but somewhere in between changed their focus to getting existing software to the mac. Unfortunately, they didn't change the tools to match.

Re:The biggest problems with Cocoa

[Kplusplus]

I already explained this but I'll do it again. Cocoa's classes are simple because the methodoligies and design paradigms are simple to follow. The string methods for dealing with paths are best served as part od NSString because an extra class is useless to do something so trivial and hiding it in non member functions ensures that people will always initially overlook them.

As for your gripe with NSAttributedString, it does not inherit from NSString, so why would you expect it to act the same? It's convenience methods are where all that magical "free" functionality comes from. They can load RTF and even Word documents because they are stylized text, so the formatting is non trivial and important.

You don't need an intimate knowledge of the APIs you need to know how to program and everything is unbelievably obvious. Cocoa is not designed to be to port applications to other platforms now from other platforms. Cocoa is designed to make Application Development to easy and so fast that much smaller groups can produce much larger apps.

Also your conclusion shows a lack of understanding of the article if you read it at all. Rhapsody did start out in idea to be the über development platform but those developers for whom it was being made complained about things they wanted, ie. not rewriting their apps and apple provided exactly what they wanted in the form of Carbon, having lost the entire multi-platform portability due to the majority of their apps going to be carbon, why continue to support all the other platforms. The tools are well designed, you merely lack the skillset to wield them effectively. As is the problem with OS nowadays, it puts too much power into the hands of people unable to wield them effectively.

Re:You cannot polish a turd.

[FrYGuY101]

So did Porsche.

Re:

[aixou]

I should start a toilet paper company and pay Ferrari to allow me to put their name on the TP.

"Wipe better, take curves faster, and have a smoother finish than with any of the other leading brands. "

Since Ferrari already has their name on a Laptop, why not?

What Apple could do...

[PurifyYourMind]

...in addition to porting development frameworks is lend guidance on the user interface front. Maybe create a base of minimum usability standards to which window managers, toolkits, distribution installation screens, etc. could refer. Not just the lack of programs, but the lack of consistent program interfaces (e.g. see the recent article on Slashdot about GIMP contrasted with Photoshop) is another thing holding Linux back from the desktop.

Oh but for Rhapsody....

[iwbcman]

Firstly, that blog was intense. Bordering, due to it's length, on the edge of unreadability, it was fascinating-not due to it's indepth-ness, but that it lightly touched on so many interrelated threads. (the wideness of the wide is the "depth" of the superficial)
He dared mention Rhapsody, for the love of gawd, HE DARED to MENTION it. Dazed,confused and oft bitterly disilussioned developers and dreamers bitten once by that dream never really have recovered- I loved her, she was so beautiful, but she was a....lie. Has enough time passed to heal the wounds of betrayal, could it be her beauty was just premature(ie. not 16 yet)
Rhapsody promised more than any other computing project worth mentioning in the last 20 years. It was friggin incredible. The entire landscape of desktop computing would be markedly different today if Rhapsody had ever materialized. But no. Apple killed it, killed the best project that they ever actually came up with.
The author of the blog appears to not have a clue about Linux-land. Neither did he mention GNUstep, nor did he acknowledge what is now being developed at X.org-ie.cairo+opengl+xdamages+xfixes+xcomposite. in other words the tech that will bring the GUI desktop of the Linux world into the 21st century-farther along that trajectory in fact than either Acqua or Longhorn.
If Apple would just open up their API's new apps could be developed for a combined market-Apple + Linux. Now is the time to overcome the desire for attaining windows compatibility-if app developers could count on a market of Apple and Linux users this would push both Apple and Linux beyond the effects of the chicken-egg dilemna which both have been struggling with
The propietary parts of Aqua are being realized now, in an opensource form, in cairo, which is in a state of very active development. If the GNUstep coders use cairo as the basis of their new developments they finally have an answer to the display postcript issues which have dogged them.There is already a great deal of convergence going on between the MACOSX and Linux world-if nothing more than the GNU utilities which compose our common toolkits.
Now is the time for Apple to heal wounds with the development community. They should open up their API's, provide exact documentation as to the point where cocoa and OpenStep meet and where the specific differences lie and they should support GNUstep as the basis for developing cross platform apps. With the developments at X.org ongoing GNUstep could be made very viable for such purposes in short order,ie GNUstep + cairo >= cocoa
I'm sure this is all just pipe-dream stuff, but combining the markets for Apple and desktop Linux just make sense for both Apple and Linux users....




Now someone with more of a clue about these issues-go ahead shoot this idea down...

Re:Oh but for Rhapsody....

[Kplusplus]

You seem to not realize something about your own post, all those efforts are catch up efforts to catch up to the tech that Apple has created and been improving with each OS revision, the tech MS claims will be in Longhorn. But the real problem is that you think they will exceed Apple's efforts, as of date, no OSS copy has ever surpassed the original. OpenOffice from all discussion is always mentioned as good enough or just as good, never better than Microsoft Office. We all know the GIMP is a joke in camparison to Photoshop. RhythmBox is still slow and lack A LOT of features before it is anywhere near iTunes. There are plenty more, but you get the idea, that copies are just that or even worse, poor subsititutes. OSS needs to provide better ORIGINAL products, not catch up solutions. What could Apple possible have to gain from working with GNUStep? Other than letting OSS into it's coolness and gaining absolutely nothing in return after all, GNUStep still looks basically like OpenStep did in the 80s, and combnied Linux + apple market share won't move Macs, Insanely great mac apps do that. Also your naive if you think that GNUStep's only problem is it's drawing system as taht is completely independent of the API. GNUStep won't be a threat to Apple until it is more than "just good enough" or "about the same" it has to be amazing and magnitudes better than Cocoa before it starts moving Apple to do anything. Too bad or you that 7 year long stretch from 70% done to 70% done isn't helping any.

Re:The real problems of Mac development

[Kplusplus]

3% market share: Yes, if we repeat it enough then it must be true.

Developers don't trust Apple or Jobs: I'll admit developers might be squirmish due to past history, but the point of the article was getting NEW developers people who have yet to work with Apple and can't develop any of these distrusts.

Too Many APIs: Only an idiot would claim this as a problem. If you think everything is held together with duct tape you need to be introduced to a little document called SystemOverview.pdf trust me OS X is held together by much more sophisticated glues than duct tape. If the glue that held OS C together was duct tape, them that which holds Linux together would be happy thoughts and good wishes, Almost all those APIs interact with each other of one relies on the other. There is no MacOS API, nor NeXTStep, only Carbon and Cocoa.

As for appliances, that same argument must hold for Compaq/HP then as they now sell A LOT more types of media players than computers.

Thanks again for trolling.

That's not entirely true

[fdobbie]

Carbon is emphatically *NOT* a stepping-stone API.

Apple continues to improve and evolve the Carbon API, dropping a lot of their legacy cruft and encouraging developers to move their applications forwards. While it does ease porting, if you just do the minimum so your old apps compile and run on OS X, you do not really have a Mac OS X application - it probably won't look and feel completely right.

Carbon also works completely differently under the hood. As time goes on, Apple exposes these improvements through entirely new API, for example the HIView stuff that appeared in 10.2. Things like QuickDraw are largely going away for a lot of uses, with more modern alternatives like Quartz 2D or OpenGL recommended depending on your needs.

It's also important to note that Cocoa is actually implemented using Carbon in some cases, and we're starting to see the reverse also be true.

You can't say that Carbon, at its heart, is a "horrible, messy kludge". It's actually a fully-featured modern procedural API for creating native applications that provide a full Mac OS X look and feel.

Having said that, it's highly unlikely that Carbon will see the light of day on other platforms, purely because of the effort involved in writing something comparable and the sheer size of the API.

Apple seems to be pushing Carbon as its lower-level application development API, and Cocoa as its application framework (as a replacement to MacApp, the former C++ framework that was based on Carbon).

Re:That's not entirely true

[mav[LAG]]

Soldier on battlement: Are you suggesting Cocoa nuts migrate?

Re:That's not entirely true

[huchida]

Carbon also works completely differently under the hood. As time goes on, Apple exposes these improvements through entirely new API, for example the HIView stuff that appeared in 10.2.

Offtopic, but couldn't they have possibly come up with a better name than "HIView?"

Re:That's not entirely true

[robertchin]

Except for the parts that still take pascal strings!

Bottled Water

[Graymalkin]

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.

Re:Bottled Water

[Graymalkin]

I really don't think this rant nor your rant regarding the G5 were very well thought through. I consider it a low for you as there's times when you've got some fairly insightful rants about various topics. The squandered G5 rant was not one of them.

Your redux falls into the same logical traps as your original rant. You assume that a multi-platform API will cause developers to run out and buy Macs to do their development on. This simply does not follow. If the API is cross platform as OpenStep was there is little preventing a developer from firing up vi/emacs/pico/Notepad and grabbing the header files they need to write some code. I don't think you'd expect Java developers to go drop money on a Sun workstation when they can do it just as well at home on their $699 Windows or Linux PC. XCode isn't really enough to draw developers by the thousands to the Mac. You'd see a quick and dirty KDevelop or GBuilder fork to handle Cocoa development before you saw anyone buying a Mac to do it.

Both your rant and Redux fail to explain exactly what sort of functionality you'd expect out of the new Yellow Box. AppKit is nice but contains very little in the way of advanced functionality on its own. NSSound might be a decent class for playing simple audio files in an app but it doesn't hold a candle to the classes in CoreAudio. As such Apple would need to port CoreAudio to make Yellow Box a viable system to write audio editing/playback applications on. If they didn't do so the app's developer would need to write their own framework and bundle it with their app. They would need to put all that extra work into building their own frameworks when they could have just gone the Win32 route and been able to use DirectSound.

You point as WebObjects as if it were the best example of a Yellow Box application available. WO is a viable Yellow Box "application" because it is built mostly of its own utility frameworks. WebObjects is an entire set of frameworks on its own, it just uses Yellow Box for a base system to run on. It could have very well been written to sit on top of POSIX or Win32. WebObjects doesn't rely on system frameworks in the same way say iChat AV or OmniWeb do. Without Quicktime iChat wouldn't be such a fancy application. Without WebKit OmniWeb 4.5 and up wouldn't be doing a whole lot of anything.

You're also missing the small issue of why exactly developers would even bother with Cocoa/YB when they've got existing codebases with hundreds and thousands of man-hours invested into them. If Linux and MacOS aren't large enough blips on a developer's radars right now to garner any interest having Cocoa available isn't going to phase them. I don't know many developers that like tossing themselves into new APIs all of the time. All APIs and implementations have quirks, successful developers have learned to recognize and work around such quirks. Version 1.0 of SomeApp might have sucked but version 3.4 is really sweet because the developers are familiar with the target platform. Version 1.0 of SomeCocoaApp will likely suck and be extremely expensive to develop. It won't matter that the app has a 4% larger number of potential buyers if it sucks.

In all of your ranting you entirely ignored a fairly large group of developers. Not all developers write in C++ and ship their products in a box with brightly colored packaging. Macs have turned into excellent systems for internet/intranet development. Out of the box a Mac running OSX has a copy of Apache, Perl, PHP, and Java. With a few quick terminal commands it will have MySQL up and running. Portable Unix systems with warranties and hardware support that run all of the services and programs the servers in the NOC run; who the hell do you think bought the millions of laptops Apple sold last year? Macs can run all of the backend software the servers are running along with the front end apps like Dreamweaver and GoLive the design department is running.

Rhapsody was a much better idea in 1996 than it is in 2004. When Rhapsody was first floated Windows de

Misconception about Carbon

[spearway]

May be you should do a bit of research.

The ancestor to Carbon is the port environment that was developper by Apple for QuickTime. and is still used today. This is never said but when you install QT on Windows you install Carbon as a side effect. You can even compile against it!! Take the include file on a Mac and compile link against the QT lib you will get a working application.

Just to say that Carbon already exist on Windows what is missing is the support.

What GNUStep Needs

[RAMMS EIN]

Joining the discussion about GNUStep that has evolved here. Despite what the proponents say, GNUStep has a LONG way to go. It seems that the OpenStep API implementation is fairly complete, but that's far from all there is to it. What we need is:

- Eye candy/themes. The interface is very usable but also very ugly. You cannot please everyone with one interface, so I say themes are the way to go.

- Compatibility with Cocoa. Seriously, they are both implementations of the OpenStep API, but hardly compatible. Each has its own extensions, interface files are completely incompatible (and let's face it - it's all about the GUI; that's what distinguishes OpenStep from the rest)

- Stability - I can't speak for everyone, but GNUStep has never worked reliably for me. I tested GWorkspace about a week ago, and it crashed or went catatonic every few minutes. It also didn't at all nicely integrate with WindoMaker. I would have expected much better from such a central app.

I don't know _what_ is wrong with GNUStep. OpenStep is great, alledgedly much nicer than GTK, so how come GTK has lots of developers and is very robust and complete, whereas GNUStep remains in alpha after all this time?

When Apple released OS X and started touting Cocoa, I expected developers to rally behind GNUStep en masse. As far as I can see, that hasn't happened. How come? It's not like there aren't obvious benefits. So where is the action?

Re:What GNUStep Needs

[borgheron]

GNUstep has been in alpha a while because it's fairly complex and we've also got only a handfull of developers. Whereas KDE has hundreds of developers, we have 30. :) It hardly seems fair to compare one to the other.

Also, you should look further than any one app (in your case GWorkspace) to gauge the stability of GNUstep as a whole. There are many apps which run reliably and are completely stable under GNUstep. I, personally, haven't had a problem with GWorkspace recently.

GJC

It's over guys... deal with it.

[tacocat]

I love all this discussion about GNUstep and such. Personally I'm partial to WindowMaker which I believe is or can be a part of GNUstep. Not sure, it's early

But this talk of Microsoft porting their framework to Linux... Why? Seriously... Why? I just don't see why anyone with an eye on technical factors give this any consideration at all.

It's Over because Linux and Apple have clearly broken the beach heads to Fortress Microsoft and now it's time to prepare for their big defensive resistence push as we eat their market share and profit margins.

What got me to originally consider Linux wasn't the interoperability or ease of use or feature rich desktops. It was the freedom from Microsoft and the freedom from Corporate PHB's trying to run the show. Do you have any idea how much Marketing Hype is integrated into every software manual?

What's going to keep me there is the same thing. Microsoft could release Office XP for Linux tomorrow morning in both RPM and DEB packages and I simply would not touch it. Too my Hype and too many Hooks to use safely. So if Microsoft isn't really involved in the article, don't give them any airtime. Their current direction shows they are Loosers. If they can honestly change their tune then maybe the won't be Loosers.

And don't give me that "Corporations have to make money and that's all Microsoft does" crap. RedHat and SuSE makes money and they haven't been convicted multiple times in multiple countries.

hmmm... wrong

[Ender Ryan]

That is patently ridiculous. Apple supports QT on Windows. They have free downloads for Windows. It wouldn't cost any more to have free downloads for a couple *nixes.

I suspect Apple doesn't want to give *nix users a reason to not switch to Apple. They are forced to support QT on windows because if they don't, it won't stay relevent.

Plus, I believe several companies license QT from Apple for use on embedded systems running Linux, so porting it is not cost prohibitive.

But who gives a "flying fuck" anyway? I believe the Xine developers already reverse-engineered the codec and have a native version for Linux. Oh, right... Patents... *sigh*

Disruptive technology

[scottyboy]

Oddly enough, I reckon the disruptive technology on Mac OS X won't come from Apple - it will be C# and Mono... more specifically the PPC JIT. Give it another year and you'll start noticing quite a few .NET apps running on Mac OS X.

Cocoa is a great technology, but it isn't agile enough. By that I mean that it's more monolithic application/client oriented, wheras the .NET framework blurs the boundary between client and server, or native app vs. sandboxed web app. vs ASP.NET web pages. Furthermore the C# developer base is growing rapidly.

Re:Disruptive technology

[Rascasse]

Are you kidding me? Do you have any experience whatsoever programming in Obj-C with the Cocoa framework? Cocoa has had distributed objects that were Internet-enabled going on 10 full years. You can write to remote objects as if they were local ones with a sparse amount of code. There are definitely some drawbacks to using Obj-C/Cocoa vs C#. Mainly, the developer has to worry about garbage collection. But as far as blurring the client/server model, I would argue they are neck and neck.

Price myth!

[jo_ham]

Not this old sock again.

Macs are pretty competitively priced for the hardware and software that you get.

Sure, they can't compete with Dell for the "3Ghz PC with 17" TFT for $400! Theres nothing wrong with it, honest! We didn't use the cheapest, crappiest parts we could find to offset the cost of the CPU and LCD panel, really!"

You'll be hard pressed to find a better value laptop than an iBook (or even a Powerbook, excluding the 17" which is a bit overkill).

The dekstops vary more, but an eMac is as close as you'll get to budget - and it's pretty good value for money.

Re:What about GNUstep? Xcode supports other langs!

[acidvoid]

Well, I use Xcode to write standard C/C++ GLUT OpenGL apps. What do you mean "It also does not support any other language"? Geesh, go read some stuff.

Xcode takes a little getting used to, but once you learn it (and I am only part-way there) it is quite nice and has (in my case) made life a little easier in some respects, and yes also harder in some others.

Troll.

So dumb.

[seanbry]

First thing, Apple already has an open source link, FreeBSD, BSD whichever one. Why would it port itself to Linux when most things will compile with very little or no changes. The only thing that is a problem is binary releases. But just give the source and you needn't worry about those things. Apple has no need to switch to linux. Why switch from Unix to a Unix clone?

Microsoft, bring themselves to Linux, I highly doubt that. Microsoft might make a move on the PPC architechture. But this is speculation because of the XBOX 2 hardware specs include PPC 970 derivatives, if not actual 970's. But that is just speculation.

The third desktop

[argent]

This is pointing in too many directions, and none of them are terribly useful for Apple. You have Java, you have .NET and C#, you have KDE, Apple can follow these, but where's the win?

The thing is, there's a third desktop on Linux that's got potential. It's not doing very well right now, because it's not as cool as KDE and Gnome, but it should be very interesting to Apple. And that's GNUstep.

Apple could throw a little of the old NeXT code they're not using any more, like the NeXT file manager, over the Open Source wall into GNUstep land... and all of a sudden the third Linux desktop will be OS X junior, *and* a viable framework for people to develop for Linux and Windows for on their Powerbooks... without the bad press of Java...

Re:Carbon is still required, however

[bjohnson]

Symlinks are aliases, but aliases aren't necessarily symlinks.

Foex:

johnson% touch test1
johnson% touch test2

ls -l test*
-rw-r--r-- 1 johnson staff 0 May 2 08:13 test1
-rw-r--r-- 1 johnson staff 0 May 2 08:13 test2

No probls, right?

Now command-option drag test1 to make an alias.
do ln -s test2 test2_ln

On the desktop they both look like aliases.

ls -l test*
-rw-r--r-- 1 johnson staff 0 May 2 08:13 test1
-rw-r--r-- 1 johnson staff 0 May 2 08:15 test1 alias
-rw-r--r-- 1 johnson staff 0 May 2 08:13 test2
lrwx------ 1 johnson staff 5 May 2 08:16 test2_ln -> test2

Note the *alias* is a separate file, whereas the symlink shows properly.

Dumbass

Nice conclusion...

[Frobozz0]

I have no idea how the poster got to their conclusion that Apple would be a gateway OS to Linux. There is no reason to run Linux on the Desktop if OS X runs it's libraries. And that's a good thing. OS X is a polished OS with critical applications available to it. If anything, the ability to capture that stragglers from the Linux camp would help Apple immensely.

Cat and Kaboodle

[polyp2000]

What would be more interesting, is not porting the framework to linux. That doesnt make a lot of sense since there is darwin. Of course stuff like cocoa might be useful for open source developers wanting to write applications for different platforms. However other frameworks existing for the open source *nixes. And besides I suspect there is a lot of dependancies with aqua and what else.

What would be far more interesting would be if they were to port the whole kaboodle to x86 hardware. They had a bash with rhapsody. Apple have got themselves some respect in the past few years despite some dodgy *iPod* battery practices from time to time. With long wait for longhorn, and microsoft getting such bad practices. It could be a good time to think about this, the main problem of course being cross architecture. If someone were to solve the cross architecture binary incompatibility issue it would surely put quite a large spannner in the works.

nick ...

underestimates number of developers

[sjf]

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

Re:hmmm... wrong

[FredFnord]

> I suspect Apple doesn't want to give *nix users a reason to not switch to Apple. They are
> 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 ... 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?)

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

Re:hmmm... wrong

[mcc]

That is patently ridiculous. Apple supports QT on Windows. They have free downloads for Windows. It wouldn't cost any more to have free downloads for a couple *nixes.

Wha?

You are saying that developing from the ground up a port of a very complicated and optimized set of libraries and GUI applications onto a platform which not only does Apple have zero infrastructure for in terms of personell which know how to develop for it, not only is this platform the single most diverse in terms of hardware and software configurations in the world, but also you can't assume the presence of a usable GUI widget toolkit and there isn't even really a single totally universally accepted method of sound playback... would be something that would be zero cost to Apple?

I'm sorry... it would be lovely to have QuickTime on Linux. And there is no really justified reason why Apple doesn't just let the MPlayer people go under NDA and add support for the unsupported quicktime codecs, or provide those Xine people you mentioned with a limited license to use the relevant patents on UNIX. But the fact is that porting quicktime itself to UNIX in any form would be an absolutely huge undertaking. Did you notice how many *months* it took them just to port iTunes to Windows? And look at all the problems they've had with getting QT/iTunes to act like a "normal" Windows application (file associations, minimize to taskbar, etc). Just think of how much trouble they'd have trying to get Quicktime, a closed-source app, to be a good userland "citizen" on UNIX, which is not merely slightly different from MacOS as Windows is, but relatively totally alien?

Yeah, Real managed UNIX ports, but RealPlayer is at least an order of magnitude less complexity than the complicated multimedia management API that is QuickTime, and Real doesn't have to drag around a significant portion of their operating system API with them every time they port. QuickTime is much more complicated than just "open up a movie and play it".

Re:Carbon is still required, however

[putaro]

Hmmm...and you're so right you felt the need to post anonymously.

Aliases are a lot more than symlinks. They're kind of a hybrid between hard links and symlinks plus some extra stuff. An alias contains a file ID, plus the path to the file plus info about the volume it's mounted from. If you rename a file or move a file the alias will still point to it. If you delete the file and make a new one with the same name, the path will resolve and it will point to it. If the volume is unmounted it will attempt to remount it.

Dumbass