There is a simpler solution out there using Hashicorps' Packer and the great build scripts from timsutton (
can build images for Fusion and Parallels, too.):
I used OS X in VMware and Virtualbox (running Xcode) and the experience was awful. Mainly because 3D support is not available and OS X makes a heavy use of graphics acceleration.
Same experience here. I usually don't have an Apple computer underhand, but I maintain cross-platform software for which I publish OSX binaries. I wish Apple gave some consideration to this situation, which is less of a problem for other plaforms which can be virtualized properly. After going though hoops running unstable VMs on old versions of VirtualBox, I ended up getting a vaguely stable build process up and running. But it was a pain.
"Doesn't Apple have any consideration for this situation?"
They do; buy a Mac.
EDIT: That sounds harsh, but it is their business model. That is the cost of entry to the Apple eco-system. I would argue that the running through hoops was your choice. The obvious choice is to not build for their platform.
Let me just drop this link: http://macincloud.com/ ...you could totally use the iOS simulator, or compile the .ipa(iOS app binary) and send it to yourself via testflight or even faster, on a jailbroken device, just FTP/scp/whatever the .ipa to your physical location and install it on your device. But yeah, other than this cloud solution I completely agree on the price-of-entry point. Considering the salaries we're getting these days, allocating $1,000 for an iOS device and a macmini doesn't seem unreasonable. Around $1,600 if you need a macbook. That's how Apple rolls. Take it or leave it. If you're just wanting to learn to hack around with things, or just can't afford Apple hardware right now, then sure... hack around with OSX on non-Apple hardware. But if you're a professional paid engineer and serious about app development, dealing with this hack'ish OSX environment is a waste of time. Just by a macmini or sign up with macincloud. Spend your time developing your app, not pulling your hair out on whatever brokeness of OSX-on-NonApple-hardware you'll encounter.
The new mac minis (Late 2014) are terrible (google and see), and are not useable for anything other than web browsing. I recently had to dump this new mac mini and switch to a Macbook Pro for mac/iOS dev as they severely underpowered and limited entry level mac-minis, not to mention the craziness of soldering the ram (when form factor isn't an issue, compare to previous models), making basic upgrades impossible.
In conclusion, running Yosemite on VMs, especially AMD is really hard, and not worth it in the long run. Buy a mac instead, but AVOID the latest mac minis and get some other non-crippled model.
When I'm fixing a bug in a piece of open source software reported by a user running it on a Mac, my inclination to actually pay money to fix that bug hovers around zero.
But you do need to buy their software (or you did, until very recently), at least their operating system. In this case, Apple only sells their software in combination with hardware.
$500 for a Mac (with a license to all their "free" software) is not terribly far from $200 for Windows 8 Pro.
> $500 for a Mac (with a license to all their "free" software) is not terribly far from $200 for Windows 8 Pro.
Amazon: Windows 8.1 OEM, $89.99
Amazon: Windows 8.1, $99.97
Amazon: Windows 8.1 Pro, $174.99
Windows 8.1 Pro provides no tools you really need for software development[0][1] (although client hyper-v is nice), you can develop on the standard edition of 8.1 just fine.
Incorrect on all counts - You have never needed to buy Microsoft's software in order to build something for Windows. There have always been free options from Microsoft and others.
And you don't need to pay for Windows either because Microsoft has given away 6 month trials of every version of Windows since forever. (And they give you an option to re-up the trial time without reinstalling so you can get like a year out of a free trial of Windows no problem.
That kind of consideration is synonymous with "give us more money" in my book. For developers who are willing to develop for iOS but don't use Macs, why not give them a bone and let them develop on a VM? Apple still makes money if the app sells.
And this isn't just greed. If you look at the quality of Apps on the App Store it's very often quite obvious who is building for the platform and who doesn't understand the platform and is just trying to cash in on it.
Apple wants high quality apps, not apps from people who just want to cash in. (And the people who aren't willing to spend $600 for a mac mini because they're being cheap are not likely to invest the much more expensive development time to make a good app.)
As an enterprise developer who only has to touch Apple products as a function of my job, I can say that they're very enterprise developer unfriendly. Everything in their ecosystem is centered around the individual experience and the journey sucks if you're a cog in the wheel of a big corporation.
I have $10000 in Apple products at the finger tips and I have no desire to touch any of them.
> I used OS X in VMware and Virtualbox (running Xcode) and the experience was awful. Mainly because 3D support is not available and OS X makes a heavy use of graphics acceleration.
For desktop use it's probably true, but you can enable SSH and log in to run build-jobs and test-runs with Xcode and friends just fine.
I run Yosemite Zone on a Lenovo W530 just fine, 13Gb RAM Allocated to OSten. Sure it's a little slow but it's usable. Still I agree, on slower hardware it's useless. I'm buying a Macbook Air 2011 next week since I need something faster and the Lenovo is a company machine.
Note that if you do this with 10.10, performance will be terrible because of graphics accelerations issues.
From what I understand, 10.9 generally works fine in VMs, but there was a change in the underlying graphics engine in 10.10 that works fine on real hardware but plays merry havoc with VMs.
It seems the image must be created on an existing OS X installation. Is a pre-baked image portable to virtualbox running on other host OS:es? (Yes I know, Eula yada yada).
I know of some images that are available at The Pirate Bay, but they are only for VMware and also require some kind of patch to the virtualisation software for a reason I do not know.
"VMware" is the company, not the product. You can run many versions of OS X as a guest on VMware Fusion and VMware ESXi when the "physical system is an Apple-labeled computer." [1] Installation does not require a hacked ISO or other modified installer however the current ESXi instructions do say to install Mountain Lion first in the VM then install Yosemite on top of it.
I don't know what VMware's software does or doesn't do but its documentation just reiterates what OS X's EULA says. VirtualBox's documentation does the same thing [1] and goes further to caution "These license restrictions are also enforced on a technical level. Mac OS X verifies whether it is running on Apple hardware, and most DVDs that that come with Apple hardware even check for an exact model. These restrictions are not circumvented by VirtualBox and continue to apply."
BTW, if you're going to count on Oracle (who owns VirtualBox) for supporting software freedom, you're going to have a bad time.
> VMware plays fiddle to apple's artificially restrictive licencing
VMware merely passes relevant host information to the guest.
For OS X this is something (can't remember) that satisfies the "Dont Steal Mac OS X" kext. For Windows and PCs with embedded license signature keys (again, can't remember the name, SLIC or something like that) then they're passing that (making virtualized Windows+Office OEM licenses activate against the original hardware†). VirtualBox does not (or did not last time I had to patch it), and it's a pain, putting you in all sorts of legal grey areas for something the license allows.
Summary: important system binaries (such as Finder.app) are encrypted with a key held in the SMC. The OS transparently decrypts them, but needs access to that key to do so.
It is possible to convince QEMU to run OS X: http://www.contrib.andrew.cmu.edu/~somlo/OSXKVM/ (though I've not tried this myself). They do require you to provide the relevant key yourself, I imagine for legal reasons.
You can also use FakeSMC, which is a kext that emulates a real SMC and therefore allows you to bypass that limitation. It's a mandatory requirement for Hackintosh installations.
I'm thinking about getting a MBP (have one at work) because the hardware is shiny and OSX is useful/needed for some things (iOS development, Unity development).
However I'd much rather run Linux as the base OS. That setup wouldn't violate the EULA. I guess I'll spin up a VB-image on this OSX-MBP and see how it goes :)
Useful.
I would guess you'll probably get at best mediocre battery life not running OS X as the host OS.
If you happen to have any issues with hardware (that are actually hardware issues) it will also most likely be a lot harder (i.e. more involved) to get support from an Apple Store.
Also, from reading the quoted text about the "virtualisation" clause in the EULA - it may only be "acceptable" (by Apple's terms) to virtualise OS X on top of OS X (emphasis mine):
> to install, use and run up to two (2) additional copies or instances of the Apple Software within virtual operating system environments on each Mac Computer you own or control that is already running the Apple Software
I also understand, that if you bootcamp to get windows/linux that the thunderbolt ports aren't completely compliant... Ie you'll see issues connecting/disconnecting devices after booting (like the wired ethernet).
Also, there's no way to install firmware updates released by apple unless you're running OS X on the hardware - though you can keep a crappy USB drive around to boot from to accomplish this OK.
Consider running OS X as host OS and Linux as a guest OS in VirtualBox. Unless you are going to play games in Linux, you should have a good experience.
There's not much downside to OS X for a Linux fan. Yeah it's BSD but most important unix programs you can get via brew, etc. And of course you can run Linux in a VM at native speed without much problem... run a dozen of them if you want to simulate a distributed system (Which is what I do before pushing out to the cloud.)
Now I remember why I don't like VirtualBox. There's always some problem when I use it. In this case, I followed the exact instructions. I have a non-functioning trackpad in the guest, which sometimes happens, and sometimes not. In the OS X installer, I also can't select the disk to install to. And when I powered down the VM and powered it up again, I get an error message "Error loading kernel cache (0x9)". That seems to be fixed when you follow the FAQ for "Stuck on boot".
The non-functioning trackpad I can get around, by rebooting until it works. Anybody had the problem where you can't select the target disk in the installer?
Edit: got it. You have to format the disk. In the installer, go to Disk Utility and "erase" the disk. This formats and partitions it.
I don't know what the downvote is for, from the SLA [1]:
(iii) to install, use and run up to two (2) additional copies or instances of the Apple Software
within virtual operating system environments on each Mac Computer you own or control that is
already running the Apple Software, for purposes of: (a) software development; (b) testing during
software development; (c) using OS X Server; or (d) personal, non-commercial use.
> It's not, you're allowed to install OS X in virtual machines granted it is on a apple device.
I was with you until you said something about restrictions. No court of law anywhere has said that you running standard X86 code in a standard X86 environment is illegal.
But can you run any x86 code in any x86 environment, even when not licensed for it?
Taken literally, your stance would mean that software licenses have no legal standing and binaries can be copied to anyone to be run anywhere -- it's just "running standard x86 code in a standard x86 environment" after all.
Indeed. Software licenses exist because copyright on its own is insufficient to define the relationship between vendors and customers.
I'm not saying that EULAs are good. But they're not obviously invalid just because common sense suggests you should be able to run some software on some hardware.
If Apple's EULA is unenforceable, how about Oracle's licensing agreements? Or the GPL? These are complicated questions.
Before those question exist, you got to answer even more complicated questions like if a license is a contract, if there is meeting of the minds, and what impact consumer protection laws has.
When it comes to an EULA, is that a contract or an license? Is there a meeting of the minds when one party has not read it or can't possible understand it even if they tried? If we then agree its a contract which both party must follow, how was the details of that contract communicated during the sale of the product? Are there parts which conflicts with contract/consumer protection laws, and what impact does that have to the contract as a whole?
A license agreement however is a bit easier if we agree that it is not a contract. If a person want to distribute a copyrighted work, then the law require them to seek permission from the copyright author. That permission is then granted through a license on specific conditions, conditions which the distributor has to prove in court if the permission is ever disputed. If the license would somehow be found to be invalid, then the distributor would be found distributing without a valid proof of permission.
Many people are of the second interpretation that licenses are not contract, which mean GPL and EULA's are under completely different legal theory and law. A contract can be unenforceable, and it doesn't impact the theory of software licenses.
Somehow I imagine you take a rather different stance when it comes to the many aspects of the GPL or AGPL that haven't been tested in court. On those issues the position of the FSF is very much 'illegal till proven otherwise' (that's if you actually succeed in getting Eben Moglen to give a straight answer).
That's one of the most often repeated bits of nonsense regarding the GPL, the FSF has always been more than willing to test these aspects in court it's just that nobody has felt sure enough they would prevail in such a lawsuit that they bothered to follow through on it.
Effectively this is testimony to how well the GPL has been put together from a legal point of view, it is bad contracts, agreements and licenses that are tested in court.
So you think the FSF/SFLC wanted to go to court over this case, where Moglen was giving private legal advice to linux developers that was very much in conflict with copyright law[1]? I don't.
Uncertainty over what adaption means serves their purposes. Uncertainty about the legality of taking somebody else's code and just relicensing it as GPL also serves their purpose. As does uncertainly over what results in a combined or derivative work with GPL binaries. The more solidly those lines are drawn then the less risk people face when calling GPL code from GPL incompatible code. That means people are more likely to do all the kinds of things that RMS fears (e.g. proprietary IDEs that call out to gcc and all that kind of thing, which RMS was talking about recently in relation to emacs interfacing with gcc).
The problem they face is that ultimately they can't create a license that prevents interoperation with proprietary code without also violating freedom zero. The only real way they have to discourage people from doing that is legal uncertainty. That is why it's very difficult to get a straight answer from the FSF or SFLC about what constitutes a combined work (other than them just claiming everything in the world is a combined work, which is the usual nonsense reply you will get). If they answer the question then it's them flagging up the best way to get around the GPL.
For example the FSF claim that distributing FooApp that links to a user chosen library at runtime and calls frobulate() requires FooApp to be GPL licensed, even if the developer of FooApp doesn't distribute the library with the app (or at all), so long as there exists a library implementing frobulate() that is GPL licensed. If you really press them on this point then they will argue that it depends if other non-GPL libraries also implement frobulate(). Of course that creates a large loophole - just create a very basic crappy implementation of the API and make it available, with the expectation that users will actually use the superior GPL library. So it's worth noting that the FSF doesn't actually accept that argument when it comes the readline and editline. Distributing a binary containing the symbols for the readline API [2] is a GPL violation as far as they are concerned. Yet they have not taken anybody to court over this yet even though the FSF owns the copyright for readline.
You can easily find people with quite different views on what the linking clauses in the GPL mean[3], so it's clear that there is a great deal of confusion out there. Nobody really knows what it means till it gets tested in court and the FSF have no interest in getting this cleared up because there is a non-zero chance that the courts don't agree with the FSF's interpretation of title 17. Once the red line is drawn over what is and isn't a combined work then people will be free to work around the GPL with minimal legal risk.
That much legal uncertainty is not the sign of a well written license, if you think the aim of a license is to clearly enumerate what rights people have. If you think a software license is a political weapon then you probably don't care that some people are being scared away from doing things they have a legal right to do with your code (but that you don't like).
I would take Theo de Raadt suspisions with a large grain of salt, especially when he is arguing that BSD licensed software can only be used with other BSD licenses software. The whole point of permissive licensed software is that you can use it under a different license, and many proprietary software companies would get quite angry if they suddenly had to close down shops because Theo has a new theory. They would also likely stop funding bsd projects.
Sure, I live in the UK and I live in constant fear of the mighty US drone army. Our laws (a great deal of which predate the existence of the US) have no meaning.
(iii) to install, use and run up to two (2) additional copies or instances of the Apple Software
within virtual operating system environments on each Mac Computer you own or control that is
already running the Apple Software, for purposes of: (a) software development; (b) testing during
software development; (c) using OS X Server; or (d) personal, non-commercial use.
Unless you are talking about the modification of the installation media. That, I am unclear on.
What I don't understand is: If Apple allows people to visualise OS X, why do they make doing so such a pain in the ass?
I looked into virtualising OS X so I could test an installer on a clean machine image, but the instructions always involve downloading patched ISOs from torrent sites. Seemed to me testing like that would make me less professional, not more professional :)
Installing OSX 10.7 and later in VMWare Fusion on OSX is trivial. If I recall correctly, VMWare does it automatically if you just pass it the Installer from the app store.
Installing 10.6 requires a bit of hackery unless you have a copy of the server version.
I have a bunch of VMs for testing my OS X apps on older versions of the OS.
Apple only permits you to virtualize their OS on Mac hardware. They make it purposely difficult on everything else as they want every developer to have to buy into the hardware ecosystem to be able to build software for OS X and iOS.
Apple allows people to virtualise OS X as a guest OS on top of an OS X host OS, on Mac Hardware.
Both commercial virtualisation platforms of OS X (VMWare Fusion and Parallels Desktop) have very easy "Create OS X VM from Recovery Partition" functionality.
Apple didn't make it a pain in the ass - if you need patched ISOs to install, it sounds like you're trying to do something they specifically don't allow.
I managed to install OS X Yosemite on Windows VMWare Workstation 10 using a commonly available VMWare patch and a USB stick for the installation, created using the standard createinstallmedia command.
Yes. Those legally binding EULAs with the associated EULA-violations we've constantly heard people getting jailed over.
How about you Mac-heads come to terms with Macs being bog standard X86 hardware and OSX being a bog standard X86 OS, and that running a bog standard X86 OS on bog standard X86 hardware is absolutely within everyone's legal right to do?
There's nothing special about your hardware nor OS. Get over it.
In the meantime I will virtualize OSX to get the Mac-specific parts of my build and tests running, and leave everything else on proper Linux.
You seem strangely hostile toward the people stating that it is a violation of the EULA, but none of these people are saying that they enjoy the EULA and none of them are expressing disapproval of you for violating the EULA.
> Yes. Those legally binding EULAs with the associated EULA-violations we've constantly heard people getting jailed over.
Businesses care about software EULAs, but no end-user is getting jailed for running OS X on x86 hardware, however, people who sell hackintosh computers have been sued and lost in court [1][2]. Also, it is unlikely anyone would go to jail over this (due to criminal law versus tort law), however it is quite likely a company egregiously violating OS X's EULA and profiting from it would be sued and lose in court.
> How about you Mac-heads come to terms with Macs being bog standard X86 hardware and OSX being a bog standard X86 OS
"Mac-heads" know this; however, "Mac-heads" may or may not support Apple's EULA terms. I don't think that any Mac fans enjoy the fact that they cannot legally run OSX in more places.
> running a bog standard X86 OS on bog standard X86 hardware is absolutely within everyone's legal right to do
See [1] and [2] again. I disagree with the outcome of the Psystar court case and it's clear that you do too, however, it has, in fact, been tested in court and unfortunately the courts decided that it is not "within everyone's legal right to do".
> In the meantime I will virtualize OSX to get the Mac-specific parts of my build and tests running, and leave everything else on proper Linux.
I will too, and I highly doubt Apple will ever go after you or I for doing so, however, it may be unwise for a business to do so at a significant scale (but Apple may still turn a blind eye so as not to be hostile towards developers which enhance the platform).
As a final note, I am a 100% Linux user, I try to avoid using proprietary software, I do not enjoy using OS X, I do not like Apple's business practices, and I also think you should be able to run OS X in a VM legally, however, in the current version of the United States, that is not the case.
> Being a properly free and unrestricted environment to work with and work in is not
So why didn't you say that? You said "I was referring to Linux as a proper, unrestricted Unix-environment"
To be pedantic, Linux is the kernel. The environment, is the GNU userland, which is specifically NOT UNIX.
Yes I know it's Unix-like. But when you start your complaint with "it's not proper" try to at least know what you want it to be and what you don't want.
OS X is a "proper UNIX" operating system.
GNU/Linux distributions are free unix-like operating systems.
At the very least, it's less hassle than linux thanks largely to well supported hardware. As for the beauty of the hardware and software, it becomes less so with every passing year.
> I can buy any Thinkpad and boot Ubuntu with all hardware detected and functional.
Until you try to hook up an external screen, then all bets are off. I know because I recently attempted to do just that (w530, ubuntu 14.04 LTS). Compare that to buying a macbook pro and it's no contest. The hardware is simply better supported.
That's a straw man argument. If you buy a purpose build hardware for Ubuntu support, you will get a similar working result. As well as on many other configurations. On the other hand OS X only truly supports Apple hardware. Almost every Hacintosh build suffers from some kind of incompatibility.
> On the other hand OS X only truly supports Apple hardware.
I don't care about pendantics. I care if I can plug a monitor into my laptop and have the damned thing work. Guess which one doesn't require me to battle with video drivers and make changes to the bios just to use the displayport?
Since Virtual Box supports EFI boot, and since we did not fiddle with the ISO in this process, that means this process will not work on incompatible older Macbooks, right?
Ah thanks for the reminder. I had looked at that page previously when it just covered 10.9. I see that it has been updated with instructions for 10.10. Wonderful.
Because you need multiple types of Torx security screwdrivers and have to literally disassemble the thing 100% (including removing the HSF and pulling out multiple tiny ribbon cables) to get the hard drive out; and it completely voids your warranty to do so. And hopefully you made a USB install stick first, since they don't ship with install media anymore.
I'm sure the next iteration of the Mini will go to 32GB/64GB(+$100)/128GB(+$300) M.2 SSD options, all conveniently soldered onto the mainboard as well.
> And hopefully you made a USB install stick first, since they don't ship with install media anymore.
As if anybody actually does that any more? I just bought a new ThinkPad and it didn't even come with a manual, just a little sheet of paper telling me where to find the PDFs.
I extended the life of an iMac by booting from an external SSD over Thunderbolt. I couldn't face the replacement process at home. Performance is very good.
https://github.com/timsutton/osx-vm-templates
e.g.
https://gist.github.com/rmoriz/37b671afe53c984b2f85