* Will it run iPhone OS apps?
* No, because I'm not aiming to have compatible high level frameworks. Just think
about how much work is required to have a 100% compatible implementation of UIKit
or Celestial. HOWEVER, the CoreOS part should be 100% (or 99%) compatible. Just not
the higher level OS. If you're just interested in this because it will "run iOS apps"
please go away.
I think the submission title is deceptive -- by "fully binary compatible" the developer means that it runs executables compiled for iOS.
Sorry. Cool project, but the headline implied (to me) app compatibility. Your page was much more clear (he took the quote out of context); my beef was with the person who posted it on HN with a deceptive headline.
If it had instead said "full binary compatibility with DARWIN", or iOS 5 Darwin, it would have been clear.
And, by the way, if you hadn't said "go away" to people who wanted app compatibility, I might have been less annoyed by the deception. OF COURSE people want app compatibility. It's the core coolness of the project's potential! And maybe someday you'll get a crowd of people around you that can help achieve that. But telling them to go away isn't going to help.
Looking at the headline, my first thought wasn't that I'd be able to run arbitrary iOS apps, but that it was a project with that goal.
To me it was a bait-and-switch, where not only was it not a goal, but Christina is somewhat rude to people who thought it might be a goal (sorry Christina).
"I have this cool tech that could be used to run iOS apps -- and I have no intention of ever making it run iOS apps, because that's a crazy idea, now go away for even thinking about it!"
System emulators (ahem, WINE, but tons of others exist) that do the level of emulation Christina scoffs at have been around for a long time, and it's very much not a crazy idea to start one. By yourself, maybe it is, but given the amount of hype this generated quickly, there would obviously be other people willing to jump on board.
Really? You think this made #1 on the front page because people are excited that you can run ls from Darwin on a non-iPhone ARM7 system that's really running Linux? Which has its own ls?
No, people saw the headline and voted it up thinking that "binary compatibility" with iPhone meant compatibility with iPhone 5.0, not just with Darwin. I bet most didn't even read the article first.
Honestly, if there's not even an eventual goal to run iOS apps, I don't see the point. Linux is there underneath already, and just about anything you could compile for Darwin could be compiled for Linux. What iOS "binaries" exist (other than apps) that would make such an environment useful?
I understand (from the FAQ) that the author doesn't even ATTEMPT to justify the project's existence. That's FINE. Not slighting the developer. Sometimes you climb a mountain Because It's There (TM).
But the excitement around it was generated because of a deception.
>Really? You think this made #1 on the front page because people are excited that you can run ls from Darwin on a non-iPhone ARM7 system that's really running Linux? Which has its own ls? No, people saw the headline and voted it up thinking that "binary compatibility" with iPhone meant compatibility with iPhone 5.0, not just with Darwin. I bet most didn't even read the article first
Not that I agree with your explanation about why the article got upvotes, even if this was the case, it doesn't matter.
There was ABSOLUTELY no deception. The title uses a well known technical term, and uses it appropriately.
If _some_ people thought the title meant it can also run Cocoa Touch apps, instead of merely be binary compatible with them, that's _their bloody problem_.
This is Hacker News, they're supposed to know this kind of thing.
Should the title have been:
"Magenta - "It is fully binary compatible with iPhone OS 5.0, and by fully binary compatible, I mean it in the actual LITERAL technical way and NOT that iOS libraries are also implemented, which has nothing to do with 'binary compatibility' you newbs!", to avoid "deception"?
Dude, I've done most of the CS sequence in college (majored in cognitive science). I've been a professional programmer for 25 years. I do C/C++ development currently, and once upon a time created entire games in assembly language.
I read HN, Communications of the ACM, and other technical sites and blogs to keep up on the state of the art. I designed an SDK that was used in over a hundred commercial products based entirely on its technical merits, and people have been coming to me asking to pay to license my current (not yet public) SDK, based on the merits of my last one.
I submit that since I was deceived by the statement, that it was deceptive. Period.
And as Camillo pointed out, it's frequently applied to libraries. Correctly, I might add, when those libraries are built into shared objects. The ABI [1] needs to match, for example, for them to have binary compatibility.
A good example of such libraries would be the entire set of iOS libraries that would be implied by saying "binary compatible with iPhone OS 5.0."
See [2] if you don't believe me. "Binary compatibility" refers to the ability to run programs built for an OS, and not just the lowest levels of the OS, but the whole thing.
A clear title would be "Magenta: Binary compatible with Darwin (the iOS 5 kernel)." A better title might have been "Magenta: Run Darwin (iOS) binaries on top of Linux."
"Binary compatibility" is routinely applied to libraries as well. The point of contention is not the meaning of "binary compatibility", but that of "iPhone OS 5.0".
SomeCallMeTim's assumption that this would include the upper layers of the system is reasonable, especially given that the lower layer has its own name (Darwin) and it was not used. OTOH, given that there's no such thing as "iPhone OS 5" (it's been called iOS since version 4), I'd chalk it up to confusion rather than deception.
The fact that there aren't very many widely available useful programs other than iPhone apps that run on the iPhone goes a long way to implying that it runs iPhone apps. It's not like you can download grep from the app store.
>"Binary compatibility" is routinely applied to libraries as well
Wrongly. Only the lower lever is or is not "binary compatible", basically only how the code is loaded and how functions are called.
All the other stuff (libraries, apps) just take advantage of that, and whether higher level libraries exist or not has no bearing on whether a system is binary compatible with another.
Not only that, but a system can have all the libraries that another has, but still NOT be binary compatible with it.
For example, a simple OS X QT app can be ported to Windows with just a recompile, but the two environments are not binary compatible.
Availability of the same APIs and binary compatibillity are two things are what hackers (as in "Hacker News") call "orthogonal".
What you're trying to describe in the first paragraph is "having the same ABI". But that's not the only context where "binary compatibility" is used. In fact, in the fourth paragraph you are referencing the difference between source compatibility and binary compatibility: but in this case, binary compatibility requires not only a compatible ABI, but also the right set of system calls, libraries and assorted machinery that allows the compiled program to run.
