Slashdot Mirror
Apple and Independent Developers
Corleone writes "We've seen a realization recently that Microsoft isn't standing still with Longhorn, and countering Longhorn has been pushed to the forefront. That is why I found the concept of Apple being the larger danger in Rhapsody in Yellow so ironic. The author skirts the scary question: would Apple porting their frameworks to Linux give them undue influence over the direction of the free operating system movement? This is after recent reports saying missing programs are the biggest thing holding Linux back on the desktop. Macromedia has interest in their tools on Linux, surely many others are too. This would seem to allow thousands of companies a simple path to the Linux market but with Apple as the gateway. If not Apple, what of Microsoft porting their engine?"
I just perused the majority of that blog entry and...
.NIB compatibility. Apple never released the specs for their NIB (NeXTStep Interface Builder) format in which Cocoa interfaces are saved. Thus GNUstep had to create their own (first .gmodel, and then .gorm), neither of which are compatible with Apple's, which requires developers to reimplement interface files on each platform (trust me, this is a royal pain in the ass). However, a framework called Renaissance, which builds on OS X and GNUstep and allows you to specify your interfaces in XML, is starting to take hold. All it lacks is a graphical interface builder, and word on the grapevine is that such a thing is coming soon.
;)
No mention of GNUstep?
GNUstep is a complete reimplementation of the OPENSTEP (i. e. Cocoa) frameworks which works on GNU/Linux, BSD, and several other *NIX platforms... it already provides the portability necessary and an environment to develop apps against that framework for free.
What it's missing is a few crucial pieces which are slowly starting to fall together:
1)
2). $$$. GNUstep has no major corporate backer. Most of the people who work on it work on it because they love it. KDE, Gnome, and Mono all have the Novell monstrosity behind them. GNUstep has nothing.
3). Lack of distributed objects compatibility. See (1)
4). Outdated interface. The OPENSTEP look is, needless to say, passe. Apple did well redesigning their interface completely. GNUstep still looks like OPENSTEP did 10 years ago. This needs to change.
If Apple were to throw their weight behind GNUstep ( a tough decision, but an interesting one which could potentially bode well for both Apple and the free software community ) we could have the outcome the author asks for... Apple pushing a disruptive technology based on their own frameworks into free software, and taking hold of the market. Pipe dream? Maybe. But we can dream
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...
Gekido's Lair
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.
With OS-X being basically BSD, Their wouldn't be much work to do so.
Actually, porting iTunes to Linux or BSD would be a horrific experience, as iTunes written in Carbon (Porting that to Linux would be a nightmare).
Vonal Declosion
Gnustepweb is a framework that is supposedly compatible with WebObjects.
The parent post has a really, really good point. GNUStep has oh, so much potential and it's getting close to ready.
Like it or lump it, Apple has produced the most cohesive *nix environment out there. They've got support from the important corporate software vendors. Vendors want to port to Linux, but damn, the myriad gui toolkits and serious lack of complete frameworks is daunting for commercial entities.
I know choice is good, but is Cocoa/Aqua that unexpressive to code in? The proliferation of apps for the Mac would seem to point to the contrary. Why must we reinvent the boring stuff (i.e. toolkits and frameworks) over and over? Couldn't we just adopt a proven successful model, run with it, then tweak where needed?
I just built GNUStep from NetBSD's excellent cross-platform package management/build system, pkgsrc. GNUStep is pretty cool. It's like a slightly primative, somewhat ugly Mac. Other than that, it's very, very similar. It's clear people are starting to write useful apps with it. It's got a finder-like app called GWorkspace. It's got a pretty decent mail application that runs on both MacOS and GNUStep.
-Peter
. Penguins Surely Ca
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.
I am the Alpha and the Omega-3
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.
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.
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.
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.)
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.
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).
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.
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.
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.
.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.
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