B) Apparently this is a better-marketed expansion of the long-established maloader, which already works for many of the use cases that people bring up when they hear about this project (such as running parts of Xcode).
Designing live performance environments in Max is awesome, but laptops just are not designed for the rigors of the road. They are delicate creatures that stand in awkwardly, at best, for musical instruments. Max running on the Receptor would be incredible, and hopefully not too challenging considering the environment is largely self-contained with very few external dependencies.
What features does pd not have that you need? (Alternatively, if you really do need max/msp, for the price of the receptor you could buy a pair of mac minis and have redundancy if one of them dies on the road -- obviously the receptor isn't just a computer, but laptops aren't the only alternative).
It is not OS X, but the Classic Macintosh System translated on the fly to native code. Because it didn't get enough funding, and lack of interest, and very few buyers it sort of went DOA. I am sure if they had enough funding they could have modified it to OS X translation. Maybe someone should help them do a Kickstarter project?
Having worked on a translation layer for a large API (my project Alky converted Windows games to run on Linux and OS X), building something like this solo is just asking for pain. An open source project with solid direction is much more likely to end well. Also, Executor really couldn't be changed to support OS X; totally different architecture, no processor emulation, etc.
At the end of the day, it's really just API translation; not a technically difficult project, just an incredibly intensive one.
They're really not comparable at all. Executor is a 68k emulator + APIs for OS7; the tough part there is doing the emulation properly, and then just implementing all the APIs. Darling is just a binary loader + APIs; the loader is trivial but there are a bajillion APIs. Probably 3-4 orders of magnitude more complexity in Darling, simply due to how much is in OS X.
I do think they're on the right track, though. Hoping to lend a hand when I get some free time.
I remember it well. I still remember the Webcrawler/Yahoo/Altavista search that took me to it. I just had this inkling that it was something that HAD to exist. Sure enough, it did. And the demo version was awesome. Even more awesome was the clean room techniques they used to develop it.
Well it is an example of emulating the old Classic 68K Mac and running software apps for that platform.
I felt it is related to the OS X emulation effort, they'd just have to add in a PowerPC emulation and then do the Macintosh system ROM a bit to run Mac OS X code, potentially.
I thought it might be of use to those looking to run old 68K Mac apps.
Well this OS X emulation layer is not ready for prime time yet. Don't expect it to run 100% of your Mac OS X apps.
I'd really rather see more projects that focus on cross compiling XCode source code on Linux, so that companies can take their OS X software apps and cross compile them for Linux with little to no changes in the source code. I'd much rather trust native Linux code than OS X emulated code.
I'd also like to see some 'byteswap' projects that take the machine language of OS X apps and convert them to Linux format by converting each API or system interrupt, etc from OS X to Linux for apps that don't have the source code anymore.
Also anyone remember the Apple Darwin Project? I guess it stopped releasing binary install ISOS and instead releases the source code. You got the core of OS X right there, and it would be a good place to start to see the migration from Darwin to Linux right there.
Develop iOS apps on Linux, run iOS apps on Linux, or both?
I think Apple would restrict development requirements in the App Store to ban iOS apps created with a Non-Apple compiler on a Non-Apple platform just like they banned Adobe Flash and iOS apps made with Flash.
Not only that but Apple would sue anyone who made an environment to run iOS apps on a non-Apple operating system.
I kind of have a Love-Hate relationship with Apple because of that. I feel that iOS apps should be made on any platform and be allowed to run on any platform. Android is the complete opposite of iOS/Apple, any platform and any language can develop Android apps, you can choose more than just one store to buy apps from, and there is this Bluestack app http://bluestacks.com/ that runs Android apps on Windows and there is a beta for Mac OS X IIRC. Not only that but there is an Android for PC OS: http://www.android-x86.org/download
I'm talking specifically about developing. I have to continuously switch between Ubuntu and Mac (and very rarely Windows) and I would prefer to do all of my work on my perfectly capable linux box instead of purchasing expensive Apple equipment just to run XCode. I definitely appreciate Android not forcing you to develop on any specific platform, but at $2k a MacBook Pro, I don't see Apple changing their policy anytime soon.
For now people want to develop for the App Store and they pay for the expensive machinery to get a piece of the action. If the Google Play Store ever becomes the trendy target market and Apple's position is threatened, I imagine they might consider opening up.
If you want to develop apps for iOS on Linux, use something like MOAI or Love2D, or COCOS2D, and so on .. I use Linux as my main development machine, and regularly deploy directly to Android and iOS devices from this very seat. Of course, it helps that I'm using cross platform tools designed just for this task, but in case you didn't know it - its very possible to use Linux to develop for all Mobile platforms. The tools are out there ..
Well, I must confess that what I propose isn't necessarily native iOS development - but rather, VM-based.
In my case, I'm using MOAI (http://getmoai.com). If you check my comment history, you will see I'm quite the MOAI fanboix, and I've given a fair bit of details about how it works - so please check my history for more info.
In a nutshell, I use Linux to develop MOAI applications, and I use the Linux-native MOAI host to test/develop/code for it. It works like this: Fire up SublimeText2, write Lua code for the MOAI framework, run the MOAI host with that Lua code on my local Linux DAW. Check in the MOAI Lua code to my repo - wait for my build server on OSX to check it out, package it into an .ipa file, run it on the iOS devices plugged into my Macbook.
You would still need XCode somewhere to deploy to iOS - but you can do all the development on Linux or Windows, and the MOAI app won't just run on iOS - but also Linux, OSX native, Chrome Native Client, Android and iOS.
And before you worry that performance won't be great - performance is great. :) And there is no greater feeling in the world right now than to be developing an app on Linux, and in a few seconds watching that same app being deployed immediately on Android and iOS devices in my lab, without too much fuss. Same look, same feel, same app: completely different platforms.
I really encourage you to check it out - and as long as you can convince someone to run the XCode build phase for you, somewhere, you can deploy to iOS simply as another target architecture, alongside all the other archs that your Linux machine can support (in my case my Linux machine also builds the Android product..)
Thanks for explaining that, very instructive. I'm not sure I'm quite ready to invest that kind of time into the transition, but it's something to keep in mind for sure. It arguably looks a lot less straightforward than development on Apple hardware, but perhaps I'm looking at it the wrong way.
Oh its a lot more straightforward. For starters, you only need three things: a decent text editor, the MOAI host executable, and the MOAI SDK docs. All of these things can be found on Windows, Mac, Linux ..
Second of all, the MOAI API and programming environment is a lot, lot nicer than Objective-C/XCode/Frameworks.
But I say this, of course, with 4 years of experience in Mobile development, and 2 years with MOAI specifically. Of course I'm overlooking the training period I've been through - for a newcomer it may indeed look like a lot of hassle. But I swear, once you have spent a couple days building an app in Linux with MOAI, and then simply deploy it straight to Windows/OSX/Android/iOS targets, the value is obvious. I simply won't go back to XCode/Android/&etc. now - its just too fun to be building apps this way. One set of code, develop on your platform of choice, deploy all the way to the walled garden, and back again, around about the massive fields of Linux/Windows/OSX, and so on.
Can someone with a better understanding of this project Summarize it's goals? For example, would I be able to run Xcode on a Linux machine using this project when it is mature?
I think it's the same idea that Wine has for win32 applications, but for OS X applications instead: Provide a binary executable loader and an implementation of all the standard frameworks and libraries, so you can run unmodified mac apps on x86/x64-based Linux.
Edit:
For your Xcode example, in short, yes. (Although - that's probably one of the most difficult apps of them all to bring up, since it integrates and depends on iTunes, mobiledevice/mobilesupport libraries, debugger tools etc.)
And if your company has dreams of becoming a larger successful company, you are going to have to pull it out anyway. Its cheaper in the long run just to buy a Mac Mini or an older MacBook. I'd even argue its cheaper time-wise just to get the hardware instead of dealing with an unstable build server if you go the hackintosh route.
Why doesn't Apple make it possible to use its development environment (required for developing products to run on its hardware) in a VM? This seems like a user-unfriendly decision.
I'm curious which set of hackintosh instructions you used. I tried a long time ago to install Snow Leopard on a VirtualBox VM using iBoot, but I couldn't get iBoot to work correctly on the VM. I'd love to have an OSX VM for browser testing and CI.
Using VMWare Player is a much easier install. I run it on VMWare Workstation 8 (it may even work on 9, I don't plan on spending the money to upgrade right now) There is one little Unlocker tool to run that tells VMWare to go ahead and boot OSX. Lion runs extremely well for me. Yes this violates their EULA.
What is the purpose of this, other than just to see if it can be done? I can't think of any software that would be worthwhile emulating that doesn't already have a Linux or Windows version (which is covered by Wine), other than xcode.
From my /Application folder (the italic ones are vital to my workflow): AirServer/AirParrot, Charles, Coda, CodeBox, Day One, Kaleidoscope, Keynote, Messages/FaceTime, MindNode Pro, Mou, Numbers, OmniFocus, OmniPlan, OmniGraffle Professional, Opacity, QuickSilver, SourceTree, TextMate, Transmit, VoodooPad, Xcode (and InterfaceBuilder and Instruments)
Most of them have Windows/Linux equivalents, but for me aren't nearly as good as Mac versions (your mileage certainly varies).
Codekit, Creative Suite, Evernote, Finder, Fontbook, iTunes, Reeder, Soulver, Sparrow, Quicktime. You could run photoshop.exe in Wine but there are bugs. There are alternatives to the other apps though, but they are not as polished.
Finder? Really? I would never imagine anyone would miss using Finder.
That's the bit of MacOS I found hardest to get used to. Looks good, but it's completely basic and featureless, and missed the versatility of KDE's Dolphin for quite a while until I found out about TotalFinder.
Despite TotalFinder being a great improvement over vanilla Finder, I still miss some of Dolphin's features such as: the ability to browse remote locations (FTP, SSH) and the ability to run a terminal window within dolphin for the folder you are viewing.
I run a Linux desktop and a Mac laptop. Alfred is the biggest reason I enjoy my OS X computer more. Huge thanks to anyone who can suggest a Linux alternative.
Another vote for kupfer here, I'm a huge fan of it, and install it instantly on receipt of a new linux workstation .. terrific tool, lots of nice plugins and very usable.
>What is the purpose of this, other than just to see if it can be done? I can't think of any software that would be worthwhile emulating that doesn't already have a Linux or Windows version (which is covered by Wine), other than xcode.
It's not about having a "Linux or Windows version", it's about how good OS X's version is. For some people, there are NO alternatives.
I would suggest to these people: get a Mac. If you're seriously fretting over having no alternatives, then you should be getting the Real Thing. Is it really worth trying to "stick to the man" or waste time trying to deal with all the inevitable bugs when running on a non-native platform?
If you seriously want to spend a couple hundred bucks for a netbook to run Linux and this OS X emulation layer, you're not going to get any serious work done for A) slowness and B) bugs. You'll have a cool toy, you can stick your tongue out at Apple, but you're not going to be designing, developing and compiling that Next Big Multimillion Dollar iOS Game.
Hell, even Mr. Linux himself (you know, that Torvalds dude) uses a MacBook Air. If he wants to run OS X, he can just dual boot.
It won't run native OS X code, but you can compile code with Objective-C or other languages to run on GNUStep between Linux, Windows, and Mac OS X. It is based on NextStep, or OpenStep that Steve Jobs had at Next before Apple bought them out and turned it into Mac OS X.
Runs the PowerPC Mac OS X on PowerPC Linux systems.
Most that I know of aren't emulators but virtual machines for the PowerMac/CHRP platform that happen to run the PowerPC Mac OS X on them.
There would be more I am sure, and for Intel Macs, but Apple can just threaten lawsuits to discourage more of it. If the ability to run Mac OS X apps on other platforms exists, Apple stands to lose a lot of money on hardware sales. The Hackintosh market, for example uses cheap PC hardware to run Mac OS X on a non-Apple branded computer.
I don't think we'll see more simply because once Apple made the transition to Intel, it became somewhat "easy" to install an Intel supported version of OSX on vanilla hardware. I don't think it's the lawsuits keeping the emu guys at bay, I think it's just the "why bother" factor. If it's nostalgia, I completely understand.
I did install OSX 10.2 Jaguar a couple of weeks ago on PearPC because my son is obsessed with the different releases that came out before he was born. I wanted to show him all that pin-stripey goodness.
I heard to fight the Hackintosh crowd that Apple is considering migrating Mac OS X to ARM based devices for their next Macintosh evolution. That way they can control what devices run Mac OS X better, and since iOS is Mac OS X based and runs on ARM chips it would be easier to port Mac OS X to ARM based Macintosh systems and possibly have a virtual machine on ARM Mac OS X to run iOS apps as well.
They of course would have to buy a chip maker that can make 64 bit ARM CPUs with at least quad core to save on costs. I think Apple wants to get rid of buying chips from Samsung because of the iOS vs. Android lawsuits.
nit: in the manufacturing and business worlds, two years (let's give benefit of the doubt and presume to assume that "until 2014" is "until 31 Dec 2014") is not enough time to be leisurely. I do suspect, however, with their PA Semi purchase, that Apple is in a good position to know who to buy and how to buy them and it wouldn't be a strenuous search.
All assuming, of course, that Apple is interested in such a purchase.
This would be a sad move, but it is completely their call. It might open the door to emulators being back in style. vMac and Basilisk were my weapons of choice. And there was Shapeshifter/Sheepshaver on the Amiga... Good times.
http://news.ycombinator.com/item?id=4893022
B) Apparently this is a better-marketed expansion of the long-established maloader, which already works for many of the use cases that people bring up when they hear about this project (such as running parts of Xcode).