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.
It is not about having access to all iOS Cocoa Touch etc libraries, or running iOS apps.