I'm surprised that people are confused. Is there a regional difference in the way this would be phrased? In my (US) experience, "engaged with" unambiguously means working together, while "engaged to" unambiguously means getting married.
I immediately thought engaged -> married. I didn't even pay attention to the with/to conjunction. Anything "engaged" means marriage to me unless presented as something that is not a person. I get it now, and it makes sense, but I have a feeling there are a lot of people who would think, programmer finds female programmer that is excellent at what she does and wants to "engage" her.
How much "non practical" mathematics from the last couple of hundred years has turned out to be useful in physics problems and other areas (or just inspired other bits of maths that have had uses) over the last few decades?
If you are doing something new then there is no such thing as science purely for science's sake.
This is really weird. When there is a submission about some guy's project, do we evaluate his potential as a mate? Does that become the top comment? What in the world is going on here?
It seems even more creepily weirdly personal if "engaged" was a freudian slip rather than the intentionally self deprecating humor of trying to sound like a horny cyber stalker. I assumed because of the rest of the gushing it was meant to be a humorous parody of a horny cyber stalker.
Is there a chance you guys are not native english speakers? I'm Canadian and didn't find anything odd about the sentence. I think the context made it clear that he was talking about contributing.
Is there a chance you guys are not native english speakers?
Yes, it's commonplace for someone to "want to be engaged with brilliant people" without bringing marriage into the picture. I've seen that on cover letters a number of times.
Indeed. "Engaged with" doesn't ever describe a marriage proposal in any case, so it's hard to imagine a native speaker being confused. (The idiom is "engaged to".)
I love it: hacking for the sake of hacking, just to have fun.
Christina's announcement reminds me a little bit of Linus Torvalds's 'this won't amount to anything' post to comp.os.minix on August 25, 1991.[1]
I'm by no means suggesting or implying that Magenta will be as successful as Linux or anything like that, just that the announcements posted by Christina and Linus strike me as very similar in tone and attitude :-)
The legal route would to be to provide an installer that downloads e iOS frameworks from Apple, so you aren't redistributing anything. However, it would still be quite a bit of work: iOS has a not-insignificant layer of drivers in the not-yet-recreated IOKit kernel framework (although some are open source), and likely many other low-level layers that would need to be recreated.
However, it's certainly possible, but as 'mparlane says, it would be a lot of (difficult) work.
IMO if it's not illegal at the moment, apple will add another clause to their next EULA to make it so if project gains any traction. (Similar to the way they prohibit use of OS X on non-apple hardware.)
It's a time intensive thing and not illegal if it's your own code/implementation. The google/oracle case shows that the api is not copyrightable but the implementation is.
Which is what Git does: every commit actually is a directory/file tree and a small note a.k.a. `commit message'. You could re-create the effect by hand, by placing `.commit' file in root of the multiple directories you speak of.
However, Git (and any other DVCS) does the bookkeeping and keeps you from missing that one small detail at 4AM.
Also, it's much faster to git-commit than to copy 150MB of sources by hand; mostly because Git avoids work where sensible. Ditto for git-diff.
I can understand and sympathize with "no github, I don't like github" or "I don't like git", or "I don't like social networking" or "I don't like horny virgin hacker boys cyber stalking my every edit" but what the hell?
I'm the only maintainer of this project. I find revision control redundant, since it takes extra steps to set up and use while being of very little value. I'm reasonably good at maintaining my tree without needing any fancy revision control systems (git/svn/whatever).
It might provide little direct value to your development process, but the real question is, why are you posting this project on the internet?
Do you think there is a chance it will be useful to others, and that they might contribute back patches that you will find useful? If so, it makes sense to make that as easy as possible. Otherwise you are sabotaging your own goals and putting unnecessary barriers between you and your potential contributors.
Sign-up aside, all you would need to do is type "git init" and then set up a one-line script that will do a commit and push it to github. If you want to be nice, you'll type in a message. Voila, you now have a way to:
* let people subscribe to your project
* automatically maintain and announce your changelog
* let them fork your project, make changes, and send those changes back to you as a diff which you can comment on online
* merge those changes back into your tree with a single click / command
Additionally, while you might be confident managing a single code tree, there are things that filesystems don't do well, like branching. I find being able to try new things and setting them aside for a while is invaluable. It lets me be bold and work on whatever I fancy, without having to worry about what I was doing before.
Don't think of git as revision control, think of it as a little robot that lets you do controlled operations on code trees, like you can with files.
This is Hacker News; we try to stay civil, so I don't think many people are going to "hate" you for not using (understanding?) version control.
Then again, I don't think many people will take you or your project seriously after this, either. Many of us went past folders and tarballs for version control back in 1992, and personally, there's no way I'm going to touch an OS Kernel that is distributed in a zip file. That is not how you do open source -- for what it's worth, you may want to keep your tarballs to yourself: that'd serve the same practical purpose.
I'm going to take christina_b seriously because this is a seriously complex problem, and it's impressive that she's gotten so far with it.
I don't expect that any of the people saying "you should use github to get contributors" actually have the wherewithal to contribute.
Moreover, while I disagree with her stance about SCM, I find it incredibly bikeshed-y that people are talking about that instead of about the technical details of how such a thing is implemented.
Don't any of you have questions or comments about this other than cheerleading, or a bikeshed about SCM? I posted some similar projects that have taken different approaches.
That makes sense if it's just you, but you must be losing a lot of potential contributors by not being on Github, let alone not using any version control.
Are you just not that interested in contributions from the public? If so, I think it's possible you're greatly underestimating community interest in the project.
I find I'm always happy I used hg when I get the inevitable sneaky bug in unrelated code. Being able to easily step back through history and run my tests at every step to see where they fail has been very useful many times.
I use hg locally on personal projects also. I very rarely actually need to go back to a prior version, but it gives me more confidence to try different things, knowing I can easily revert to a working version.
I hate you! More seriously git is super easy to begin to use, and even more so for small projects and / or projects with a small number of contributors.
Setup? git init; git add . (if no unwanted binary in the tree)
Something interesting has been done? git commit -am "rock more"
New source file? git add file; git commit -m "new foobar module"
What value does it bring? Great revert capability, bisecting bugs, and so over. I agree most of the time I don't need it, but well, when I do it is handy. It is like being insured.
To elaborate, it's rude to take someone else's project, and under the same name, publish it elsewhere. This has been a rule of open-source for a very long time.
If you're going to fork someone else's project, either rename, or call your github fork a mirror (and treat it purely like one).
This has most certainly not been the rule of open source, its almost the opposite of the 'rules' of open source.
The author may not be interested in managing contributions or using source control, that is their prerogative, but as long as the license permits it if people want to work on the source code and collaborate with others, it is completely fine (and encouraged) for them to fork it
Putting a version of an open source project into version control is not a fork, you could argue the same way that distributions are forking all software because they put them in packages. To fork you have to write code.
Putting it into public version control and accepting patches is a fork -- name it something new. If it's just a mirror, then call it that, and don't accept patches.
This is basic OSS politeness and the cultural norm. Only recently has Github trained people to think its OK to take someone else's work, keep the name, and siphon off interest/contributors.
If you want to fork, then do so. Treat it like the new project it is, instead of trading off the name and efforts of someone else, and operating independently of their development standards and norms.
Or, be polite, and accept that the choice of VCS is a stupid reason to fork someone else's project.
How could you test exploits, when the underlying os core is linux, not darwin, and all higher level libraries are completely different implementations as well?
As cool as this project is, virtualizing OS X -- or emulating an ARM system for iOS -- is much more likely to be useful for testing iOS internals / lower-level bits without requiring Apple hardware.
But if she could get this working on Android it would be huge. I guarantee you could get a million off Kickstarter if you decided to be a little evil and stoke the fanboy flames a bit on Engadget/Reddit etc.
We can easily virtualize this and run it aside Android on Galaxy Nexus.
But that would be meaningful only if it was possible to run iOS apps:
"
* 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 wonder if it would be possible to port the binary ios stack.
"I'm not aiming to have compatible high level frameworks" doesn't mean it won't happen, just that it isn't one of her personal targets. The beauty of an open release is that if others want it enough they can work on it.
Let her concentrate on the bit she finds interesting (the core) and that will provide a nice stable platform for others to build the higher level stack on top of if they wish.
Of course there are probably legal issues hidden in there somewhere, so care will need to be taken especially if importing binaries rather than building your own API compatible versions.
While this won't have anything like the scale of Linux, I don't think the comparison some have made regarding the "shape" of the project is exaggerated. She seems to have the right attitude to be the "benevolent dictator" over something significantly wider than she could do alone.
- https://github.com/shinh/maloader -- A user-space Mach-O binary loader. The only goal was to be able to run Apple's binary toolchain on Linux, which it is able to do.
It's very possible to implement the necessary kernel APIs to run Mac / iOS Darwin binaries. Where you run into trouble is the massive software stack that sits on top of those OS APIs.
Without $10M or more to spend on development, it's simply not feasible to produce full binary-compatible replacements for Apple's software frameworks. The best you can hope for is to copy over Apple's software from a real installation, and then run it atop your own kernel.
I love hacks like this, so god speed to christina_b. This is awesome.
To those of you telling the Christina to put her work on github to get contributors, I don't think that is particularly helpful advice. The barrier to entry on a project like this has nothing to do with the SCM being used.
"This project is dead due to a lack of interest from users."
Do they really mean "lack of interest from other developers"?
They shouldn't be doing it for users, they should be doing it for themselves, and to their credit, I think that's often why they do what they do. They have more common sense than the usual. That's why their work is so good. (It's also because they have more of a cathedral-like structure, and not just with respect to the kernel.)
Who are these "users" we need interest from? How do we measure interest? Among OS's NetBSD's user base (non-corporate) is very small.
This developer chose the Linux kernel not to please users by making the "popular choice" or because it is necessarily the easiest to work with. As the blurb says, it's a matter of driver support.
In the case of the NetBSD project, users and developers were the same people, and there wasn't much interest.
When looking for people with the necessary skills to contribute, you'll find that the majority qualified individuals are Mac OS X kernel/systems engineers, who already have Apple hardware, and don't have any particular need to support an alternative clone of their existing target platform.
This was certainly the case with the NetBSD project. When it was contemporary, I kept tabs on it, but never bothered to contribute -- Mac OS X worked fine for me.
Revisiting the problem space now, my development time would be better spent working on the open source alternatives (such as Android), rather than attempting to clone Apple's stack. It's just too big. Personally I work with Android on OMAP4 hardware.
From what I understand it is a version of Linux that can run binaries compiled for the iPhone on an ARM chip but doesn't provide any of the higher level Cocoa libraries (i.e. no GUI stuff)
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.
Palm-sized "UNIX". A true opens source "UNIX phone". No company-controlled virtual machines or high level GUI frameworks. Lower complexity, less bloat, same communication functionality.
Yep, that's how the binaries for it are currently built: with the iPhone SDK. However, higher-level stuff hasn't been developed (e.g. graphics), and the native iOS libraries would need emulation of additional lower-level services (like IOKit for hardware interaction) to run.
This guy has basically built an OS from scratch that can run on iPhones and supports iPhone apps without having to recompile them. Currently, only the base layer has been built so graphics/sound etc do not work but the goal is to emulate the entire iPhone OS.
It's based on the linux kernel and the Darwin OS which is the open source core of the Mac OS X.
Think of it as WINE project for iOS. He's building the libraries that iOS code depends on just like WINE recreated all the Windows DLLs so that Windows programs could run on Linux/OSX
It's not quite what you describe, but Ivan Vučica is currently working on a GSoC project to implement a subset of UIKit with parts of Quartz and CoreAnimation in GNUstep.
"This proposal covers implementing a flexible animation API compatible with a certain popular existing desktop and mobile platform, as well as adding APIs compatible with a popular mobile platform. This will allow extremely user-friendly interfaces, as well as allow development or porting of applications that use CoreAnimation or UIKit API on platforms that don't yet support it."
* 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.
whois crna.cc: WhoisGuard protected. WhoisGuard is in L.A; a subpoena and "Christina" could find the ICS logo on her site and a DMCA takedown notice for distributing "tools used to violate copyright."
crna.cc says "Will it run iPhone OS apps? * No". But Apple is already suing Samsung for the Galaxy Tab, Nexus S, and Epic 4G [1] [2], so unless nobody is interested in taking this idea to completion, Apple could be an enormous target for cloners.
To me, it's obvious: unlike hardware, where there are still effective barriers to competition, software like iOS is inherently vulnerable to cloning, copying, and being replaced.
Then why haven't they taken down GNUStep and Chameleon?
Oh right, because APIs are not copyrightable or patentable and it's absolutely meaningless to attempt to assert ownership over such things.
The reason why you're the only one "theorizing" about what Apple will do is because most other people here recognize how patents and copyrights work and why there is a dispute between Apple and Samsung.
I suspect you know far less than you think you do about how patents and copyrights actually work. Otherwise you should realize how amazingly silly and oblivious it is to claim that the attempt to assert ownership over such things as APIs is meaningless. It is wrong (on that we agree), but we have ample evidence that even the attempt is far from meaningless:
* highly opinionated
* driven by personal interest
* not afraid to go down the worm hole and come up with little public recognition and enormous personal gain
This is the sort of project that makes me grin:
* highly engrossing project page
* mysterious motivations
* unknown implications
* legally ambiguous
I love this shit. Keep it up, Christina.