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 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...
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.
Apple DOES help the open source community. Both Konqueror and FreeBSD are much improved thanks to Apple's contributions.
That CSS file that blocks ads
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.
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
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!
python -c "x='python -c %sx=%s; print x%%(chr(34),repr(x),chr(34))%s'; print x%(chr(34),repr(x),chr(34))"
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.
-- Fighting mediocrity one bad post at a time.
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.
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.
Got Apathy?
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.
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.
"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.
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.
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.
.NET and Java are attracting developers, and Cocoa is not.
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
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.
...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.
You're completely off on your rationale and your information. Garage Band is a cunsumer-level application along the lines of iPhoto and iMove (since it's sold only as part of iLife). The full feature-rich version of Garage Band is Soundtrack, which is pro.
Funny you compare Garage Band to Acid, but don't compare iMovie or even Final Cut Express to Premiere.
Not since Marie-Antoinette played milkmaid has looking simple and honest been so fake and complicated.
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?
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.
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.
--
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.
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...
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).
DBM has really hit a new low with this "article". It is almost painful to read through with the gaping holes in logic and diction that would make a SMS junkie teenager blush.
According to DBM's logic Apple might have a real nice developer platform on their hands if they'd only port the base API to other platforms. I find this assertion to be pretty ridiculous. OpenStep already lost this battle a decade ago. The problem NeXT ran into with OpenStep was developers were already entrenched with native and proprietary APIs on their platforms of choice. Few developers were willing to drop all of their current code in order to develop OpenStep applications.
There's also the small problem of Apple's OpenStep derived frameworks (AppKit & Foundation Kit) being a tiny (though important) fraction of the frameworks available in OSX. If only Cocoa were ported to other platforms developers would have to write their own frameworks for advanced functionality. Instead of being able to leverage Apple's DiscRecording framework a developer would have to write, maintain, and package their own in order for their app to be as cross platform as Cocoa. Then the argument would be Apple ought to port their more advanced frameworks in order to draw in more developers.
If Cocoa were to be ported to Windows and Linux tomorrow it wouldn't magically bring oodles of developer talent to the Mac. Think of how many KDE and GNOME apps run on Linux, FreeBSD, Darwin/PPC, and Windows with no platform specific patches despite their common API usage. Only the simplest of Cocoa apps would run with only a recompile (or fat compile) on multiple platforms.
DBM doesn't pay nearly enough attention to Java in his little rant as he should. With Java Apple's already got a nice cross platform development environment to work with. Apple ships two J2EE environments, WebObjects and JBoss, as well as J2SE on their client systems. MacOS X is also bundled with a Java/Obj-C bridge which DBM almost totally ignores. The Java bridge gives OSX a serious advantage as a development and deployment platform for Java applications. With the Java bridge a developer can write a single cross platform application model and then stick a native Objective-C/Cocoa based GUI on top of it. Java's huge cross platform development base with a native Aqua GUI.
There's a few languages such as Python, Perl, and Ruby that can be bridged to Objective-C and can access Cocoa. That is not to mention C++ code can easily access Objective-C classes and thus Cocoa just as well as anything else. I don't really see Objective-C to be much of a hurdle in the development of Mac applications.
What it really comes down to is developers who don't want to abandon the APIs they are used to. All porting Cocoa would do is let Linux and Windows users run Mac applications. If everyone could run Mac applications on non-Mac computers the Mac would become a commodity item and Apple would be little more than an iPod manufacturer that happened to write some software. If Macs ran Windows there'd be no difference between a Mac and an HP. If PCs ran MacOS they'd be no different from Macs. In either case Apple would no longer have a whole product to sell. Without a whole product to sell Apple would either just be yet another software company or yet another hardware company. There's hundreds of each of those. Apple makes money by selling a whole computer product.
I'm a loner Dottie, a Rebel.
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?
Please correct me if I got my facts wrong.
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.
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*
Sticking feathers up your butt does not make you a chicken - Tyler Durden
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
I'm sure there are far more than 10,000 developers "earning their crust" developing for the Mac. In a good year, Apple can scrape 4,000 attendees to WWDC. Even if only a quarter of those actually make a living on the Mac, I still can't believe that that represents a tenth of the Mac development community. I work for a company that has a major Mac application. We sure as hell don't send a tenth of our Mac developers to WWDC. We send two or three out of about 60 engineers.
-S
> I suspect Apple doesn't want to give *nix users a reason to not switch to Apple. They are
... ah... 'comprehensive' item, what with it basically being an entire programming API, plus applications. So everyone who makes a change in the codebase has to test it on both Mac and Windows before they check it in. Now, that's a hassle right now. Imagine everyone having a Linux box on their desk too, and having to test it there? And maybe having to hire another QA team to test on, say, six flavors of Linux? (And which six?)
> forced to support QT on windows because if they don't, it won't stay relevent.
I can speak to this personally.
Two problems with Linux: code and support.
First off, Apple (for obvious reasons -- you may not agree with them, but they are obvious) most certainly doesn't want to ship QuickTime as a set of source files and let Jack Jones compile it on his machine. Thus, they'd have to ship binary versions for all the major Linuxes. And on MacOS X and Windows QuickTime isn't a normal application: it interacts with the kernel in peculiar ways, most notibly in the area of thread priority (pseudo-realtime-ness). On Linux, at least a few years ago, there was really a choice between having that kind of integration or putting up a product that skipped and jerked and didn't really work. (Processors being faster now, it might be okay, I have no idea.) If they wanted to do this on Linux, they'd have to ship an update with every kernel, or make people compile some 'driver' portion of QuickTime each time they updated their kernel. Yes, THAT would really speed adoption of desktop Linux.
Second: the entire QuickTime team, to varying degrees, works with two OSes already: Windows and MacOS X. For a while it was three: Windows, MacOS X/Carbon, and MacOS 9/Classic. There are people who know more about Windows and there are people who know less about Windows but everyone has a Windows machine on their desks and everyone tests their software on Windows. They tried, many years ago, to have a Windows 'team' to port QuickTime, but QuickTime is a very
Don't underestimate the difficulty of this. QuickTime isn't just some app that you can download and compile anywhere, nor is it something that is being withheld from you for marketing reasons. If someone else were to underwrite the development and testing of QuickTime, I'll bet Apple would be delighted to do it. However, if it's not going to increase their revenues AT ALL (those Linux people, they aren't known for being big spenders on crippleware, and most of the ones I know would never consider paying for a Mac when they can get Linux for free) and it's going to increase their costs by (whatever) a million per year, it's kind of a no-brainer as far as I (and apparently they) are concerned.
> Plus, I believe several companies license QT from Apple for use on
> embedded systems running Linux, so porting it is not cost prohibitive.
I hadn'd heard, but I could believe this... but do you see how your first statement doesn't at all lead to your second? Embedded system: one version of Linux, one kernel, no testing costs (the client picks most of them up), *AND* the development is underwritten by someone else.
-fred
Sign #11 of Slashdot overdose: You see the phrase 'moderate Republican' and you wonder if that would be a +1 or a -1.