OS X emulation layer for Linux
darling.dolezel.info
darling.dolezel.info
Summary:
* It can run basic console programs like Midnight Commander, vim
or bash, so compatibility of system API is rather good.
* Dynamic loader is being refactored, because it can not unload
dynamic libraries now. In the future there will be API that
would allow loading OS X library into native code.
* There is a FUSE module for read-only access to .dmg files, so
that it is not necessary to unpack them.
Right now the target application that should work is Angry Birds.
Edit: For the record, I am a fan of Obj-C, not an iOS developer, and would love to see more movement on GNUStep. I just need the time...
1. Those who use it unwillingly, and happily use some other environment when not targeting Apple platforms.
2. Those who are big Apple fans and don't see the point of targeting non-Apple platforms in the first place.
I'm sure there are exceptions, but not enough for GNUStep to get traction.
By the time iOS rolled around, GNUStep and Obj-C on Linux seemed completely dead and, with no pressing need to write software for a handheld on one platform and a desktop on another, it's stayed that way.
GNUStep missed the opportunity to cash in on more people working in Obj-C.
And if category #2 really has total overlap with "ObjC fans" then I think you have a mistaken correlation in your statistics. You're measuring Apple developers, not people particularly enthused with Objective C as a language.
I think I agree with what the poster upthread was hinting at: ObjC is a fine language, but when compared to other more modern tools in the same space (C++, Java, C#, D, Go, maybe Haskell, etc...) it really doesn't have much to recommend it. People who tend to be language "fans" have more glittery toys to attract them.
Note the emphasis.
Much simpler than C++. Much more dynamic than any of the languages you mention. Can use straight C anyplace you need performance, with no FFI. Finally has some decent syntax for JSON types (NSDictionary/Array/Number), which some of those languages have and some don't. Performant collection classes.
http://ridiculousfish.com/blog/posts/array.html
Block syntax (Java famously lacks, those other languages have some equivalent).
An outstanding UI library, unfortunately tied to Apple devices.
I think Objective-C has stood up brilliantly to the test of time. The potential for Ruby-like flexibility with C-like performance, it's not an accident the software behind Apple's rise to the most valuable company in the world (for a time), was written in Objective-C.
I disagree about it being there when Apple rose to power, though. I think it was an accident, like so many other accidents of history. NeXT provided Apple with a solid base for the future, but IMO they could have done it decently well with Be instead. The most important thing they got from Next was Steve Jobs. ObjC just happened to be in the right place at the right time to be chosen as the GUI programming language by NeXT, and NeXT just happened to be in the right place at the right time to leverage their technology into a takeover of Apple under the leadership of a guy who was ready to change the world.
Do you think Apple could have iterated as rapidly on iOS GUI applications, while keeping performance fast and resource usage low, if everything was written in C++? Java? C#? Objective C seems to hit a sweet spot for experimenting with innovative new UI concepts in a constrained hardware environment.
Java... harder to say. I would say that no, Apple could not have done as good a job using Java as the basis of iOS, because Apple doesn't seem to be very good at the things needed to make a language like Java run fast. Perhaps if they had contracted out the right bits to Sun rather than pulling a Google and building their own VM, it could have worked OK.
I think that Objective-C is a pretty good language when you take into account the context of running on a UNIX system with lots of pre-built C libraries around, because of the ease of talking to C. Perhaps even the best choice, in that limited context. But I don't think much of Apple's rise can be attributed to that choice of language, even if it did end up being a decent one.
Or bought Sun, incorporated Solaris into Darwin. They had the cash.
BeOS, while a nice operating system, was notoriously difficult to program for, largely due to the use of an asynchronous API.
> because Apple doesn't seem to be very good at the things needed to make a language like Java run fast. Perhaps if they had contracted out the right bits to Sun rather than pulling a Google and building their own VM, it could have worked OK.
The "Apple" JVM pretty much is a licensed Sun JVM with extra bits. It's also of comparable speed to the Sun JVM; the performance gap between Apple Java 1.6 and Sun/Oracle Java 1.7 on a mac is comparable to that between Sun/Oracle 1.6 and 1.7 on Linux.
> But I don't think much of Apple's rise can be attributed to that choice of language, even if it did end up being a decent one.
Certainly not entirely. However, one advantage that iOS did have early on was that it wasn't totally horrible to write for, which had been a traditional affliction of smartphone OSes. Possibly they'd have come up with a decent C++ API, of course, but then again possibly they'd have come up with something like the Symbian API.
We were this close to having iPhone being a LispOS.
In the alternate universe where Apple bought Be, nobody can take advantage of most of the existing C libraries, because they were written expecting to be used in a synchronous programming model.
I don't think this would have worked. As cool as Be is, and as much as, fundamentally, it is a better operating system in most ways than NeXT. Be does things 'The Right Way'. But sadly, Worse is Better. You have to optimise for the programmers you have. not the ones you wish you had. Be was ahead of its time, and it's still ahead of its time.
Had it not been for mobile I think Obj-C would have quietly died out but it happens to embody a pretty good set of compromises for small, resource constrained devices. Recent developments like ARC and blocks make it a lot more pleasant to use now than it was even a few years ago.
Group 3: Those who use it because they like the language itself and would happily target non-Apple platforms if it was a tenable solution.
Beyond that, encountering a 'substantial number' of them is irrelevant. I've not personally encountered a substantial number of people who like programming in Perl, but it is not inconceivable that such people exist.
"I'm sure there are exceptions, but not enough for GNUStep to get traction."
When we're talking about why GNUStep never took off, "substantial number" is highly relevant.
Anyway, this is a pretty silly line of disagreement. :)
It really is a lot easier to write Objective-C code than C++ if you have access to all that Foundation and the associated frameworks provide, but getting it to compile for your target system is not exactly easy. Many of those components simply do not exist outside of OS X.
I'm not even concerned about GUI bindings, as I imagine those would be really awkward.
I remember trying it around the same time as I tried Enlightenment 16, around 2001 or 2002, and at the time the user and development community felt quite small, much less active than E's.
GNUstep is old. It predates the revival of Apple and the return of Steve Jobs. In the late '90s the Linux community declared war on Microsoft and decided the best way to destroy them would be to make a clone of Windows. Hence the focus on KDE and GNOME. Meanwhile, less attention was given to projects like Window Maker and GNUstep. IMO, the Linux community bet on the wrong horse. But then again, who the hell was using ObjC other than NeXT? No one, that's who. We may as well be talking about Tcl/Tk or Motif at that point. NeXT/GNUstep/ObjC were all seen as an obsolete curiosity. Kinda like Amiga was. So unfortunately, GNUstep never really gained momentum.
I must say, Window Maker was my preferred desktop up until 2006 or so. Before that, it was AfterStep. So yeah, I might be a bit bitter over the whole situation.
I was eventually able to gain access to a Mac to be able to develop, and it made things much more easier.
The potential issue you refer to would also prevent implementing the Cocoa API with Qt.
(EDIT: Gave Cocotron an 'a' it didn't deserve!)
This project is akin to Wine. It allows to run OS X binaries on Linux, without recompiling.
The Cocotron blog hasn't been updated in a while, but the project is still alive: http://code.google.com/p/cocotron/source/list
I find pretty interesting the UNIX terminal and X11 (Xquartz) where you can ssh to your remote box or vm with linux and load GUI apps locally while code is running in the remote box (like a sandbox).
Example command:...
ssh user@1.2.3.4 -X
iceweasel
...
and browser GUI will launch in your OSX (also work on linux) ( the magic is the parameter -X , i discovered that recently, very useful, hope it helps someone )