Slashdot Mirror
Apple and Independent Developers
Corleone writes "We've seen a realization recently that Microsoft isn't standing still with Longhorn, and countering Longhorn has been pushed to the forefront. That is why I found the concept of Apple being the larger danger in Rhapsody in Yellow so ironic. The author skirts the scary question: would Apple porting their frameworks to Linux give them undue influence over the direction of the free operating system movement? This is after recent reports saying missing programs are the biggest thing holding Linux back on the desktop. Macromedia has interest in their tools on Linux, surely many others are too. This would seem to allow thousands of companies a simple path to the Linux market but with Apple as the gateway. If not Apple, what of Microsoft porting their engine?"
I just perused the majority of that blog entry and...
.NIB compatibility. Apple never released the specs for their NIB (NeXTStep Interface Builder) format in which Cocoa interfaces are saved. Thus GNUstep had to create their own (first .gmodel, and then .gorm), neither of which are compatible with Apple's, which requires developers to reimplement interface files on each platform (trust me, this is a royal pain in the ass). However, a framework called Renaissance, which builds on OS X and GNUstep and allows you to specify your interfaces in XML, is starting to take hold. All it lacks is a graphical interface builder, and word on the grapevine is that such a thing is coming soon.
;)
No mention of GNUstep?
GNUstep is a complete reimplementation of the OPENSTEP (i. e. Cocoa) frameworks which works on GNU/Linux, BSD, and several other *NIX platforms... it already provides the portability necessary and an environment to develop apps against that framework for free.
What it's missing is a few crucial pieces which are slowly starting to fall together:
1)
2). $$$. GNUstep has no major corporate backer. Most of the people who work on it work on it because they love it. KDE, Gnome, and Mono all have the Novell monstrosity behind them. GNUstep has nothing.
3). Lack of distributed objects compatibility. See (1)
4). Outdated interface. The OPENSTEP look is, needless to say, passe. Apple did well redesigning their interface completely. GNUstep still looks like OPENSTEP did 10 years ago. This needs to change.
If Apple were to throw their weight behind GNUstep ( a tough decision, but an interesting one which could potentially bode well for both Apple and the free software community ) we could have the outcome the author asks for... Apple pushing a disruptive technology based on their own frameworks into free software, and taking hold of the market. Pipe dream? Maybe. But we can dream
With OS-X being basically BSD, Their wouldn't be much work to do so.
Actually, porting iTunes to Linux or BSD would be a horrific experience, as iTunes written in Carbon (Porting that to Linux would be a nightmare).
Vonal Declosion
Gnustepweb is a framework that is supposedly compatible with WebObjects.
The parent post has a really, really good point. GNUStep has oh, so much potential and it's getting close to ready.
Like it or lump it, Apple has produced the most cohesive *nix environment out there. They've got support from the important corporate software vendors. Vendors want to port to Linux, but damn, the myriad gui toolkits and serious lack of complete frameworks is daunting for commercial entities.
I know choice is good, but is Cocoa/Aqua that unexpressive to code in? The proliferation of apps for the Mac would seem to point to the contrary. Why must we reinvent the boring stuff (i.e. toolkits and frameworks) over and over? Couldn't we just adopt a proven successful model, run with it, then tweak where needed?
I just built GNUStep from NetBSD's excellent cross-platform package management/build system, pkgsrc. GNUStep is pretty cool. It's like a slightly primative, somewhat ugly Mac. Other than that, it's very, very similar. It's clear people are starting to write useful apps with it. It's got a finder-like app called GWorkspace. It's got a pretty decent mail application that runs on both MacOS and GNUStep.
-Peter
. Penguins Surely Ca
Don't be so sure. Write once. Compile anywhere. wxWidgets.
(Oh, and it works, too. AOL Communicator uses it.)
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.
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.
Java is a native language when using Project Builder.
Not since Marie-Antoinette played milkmaid has looking simple and honest been so fake and complicated.
You're completely off on your rationale and your information. Garage Band is a cunsumer-level application along the lines of iPhoto and iMove (since it's sold only as part of iLife). The full feature-rich version of Garage Band is Soundtrack, which is pro.
Funny you compare Garage Band to Acid, but don't compare iMovie or even Final Cut Express to Premiere.
Not since Marie-Antoinette played milkmaid has looking simple and honest been so fake and complicated.
As of MacOS 10.1 you've been able to call Objective-C class libraries from C++ code. It is also possible to call C++ class libraries from Objective-C code. Then of course it is possible to mix C++ and Objective-C code in the same source files. So...Cocoa is entirely accessible from C++ code.
Cocoa has been designed to work well with just about any OO language you throw at it. See the numerous bridges between OO languages and Cocoa.
I'm a loner Dottie, a Rebel.
The Finder's Carbon.
...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.
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?
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.
-"I'm one of those Mac people that will break a bottle on the bar and hold it to your throat for bad-mouthing my system"
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.
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!)
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.
NetNewsWire into Yojimbo!
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.
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
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
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.
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
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.