Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Virtualize OS X on Linux

grodola.blogspot.com

Post reply on HN
Print view View original

81–90 of 143 posts

Re: Virtualize OS X on Linux

#81

Post by tavert »

vetinari wrote: post #65
kxyvr wrote: post #36

Earlier quoted context omitted.

Paradoxically, I find it easier to port applications to Windows than MacOS. Due to the efforts from the Cygwin and MSYS groups, just about every build script ports naturally to Windows. As long as I use MinGW, the resulting application is native and can be distributed. On MacOS, there's a bunch of quirks that make it harder to port. Environment variables are different enough to require duplication in scripts (DYLD_LI…

I usually avoid MinGW, because it links your binaries agains msvcrt.dll. It really shouldn't do it - https://blogs.msdn.microsoft.com/oldnewthing/20140411-00/?p=...

The mingwpy project is slowly working towards making mingw capable of linking to the new ucrt, but it isn't ready yet - http://mingwpy.github.io/issues.html#the-vs-14-2015-runtime

I'm sure they'd appreciate help.

A funny footnote to that article is now with Windows 10 and the ucrt, Windows is "a Microsoft Visual C/C++ Run-Time delivery channel" once again.

Re: Virtualize OS X on Linux

#82

Post by pjmlp »

pimeys wrote: post #50
eberkund wrote: post #31

Earlier quoted context omitted.

You get all the Unix goodness you would get from Linux combined with the commercial polish you're used to from Windows (even more so).

For me "all the Unix goodness" is a proper package manager, an environment I can modify as much as I want and nowadays too an environment that doesn't have yearly big updates, but a rolling release. My desktop has stayed exactly the same[0] for almost seven years already. My configs follow me from job to job and from computer to computer. I don't want or need changes, just an editor and a proper *nix kind of operatin…

Do you want a Sun-3?

Re: Virtualize OS X on Linux

#83

Post by kxyvr »

tavert wrote: post #80
kxyvr wrote: post #67

Earlier quoted context omitted.

I haven't tried in awhile, but is the best option just to use VC directly at this point?

If everything is using cmake, and you don't need any inline assembly or fortran for scientific code, then maybe. But you end up in a parallel universe where everything that touches MSVC is just needlessly different than every other platform. If mingw gcc is working for you, then it's much easier for dev skills to transfer between building for Windows and building for unix. If you do need inline assembly and/or Fortra…

Well, and that's the trick. Originally, I shied away from VC because I link into LAPACK. Even if I hook into a precompiled library from a manufacturer, they use the same name mangling scheme as Fortran. In order to figure that out, both autotools and CMake compile a small Fortran program and check, which means that I need a Fortran compiler. Technically, I could set a macro to the name mangling by hand since there's only four possibilities, but it's a little irritating. I suppose that I could use VC for the C++ pieces and gfortran for the Fortran pieces, but it's always been easier just to use MinGW.

Re: Virtualize OS X on Linux

#84

Post by BHSPitMonkey »

glandium wrote: post #38
Svenstaro wrote: post #2

Don't Apple EULAs forbid emulating OSX on non-Apple hardware? I might be mistaken, of course, but I think I recall something like that.

IIRC, it's even worse than that, the EULA forbids running OSX as a guest OS under a host OS that is not OSX.

The solution is simple: Virtualize macOS on Linux, and then Virtualize macOS on your macOS VM. The inner guest is totally legitimate!

Re: Virtualize OS X on Linux

#86

Post by wila »

awalton wrote: post #48
glandium wrote: post #38

Earlier quoted context omitted.

IIRC, it's even worse than that, the EULA forbids running OSX as a guest OS under a host OS that is not OSX.

I don't think this is correct - the Mac OS X server license said as long as it was running on Xserve hardware you were okay - we run and support macOS VMs on ESXi: https://kb.vmware.com/selfservice/microsites/search.do?langu...

The linked KB article only talks about VMware Fusion not ESXi :)

I am aware about the statement that ESXi running on Mac Hardware is supposed to be legal.

However if you install bootcamp on your hardware, install Windows in the bootcamp partition and then use VMware Workstation/Player to try and run OS X / macOS you can't. That is not legal.

This has always confused me.

apple hardware -> ESXi -> macOS == OK

apple hardware -> macOS -> Fusion -> macOS == OK

apple hardware -> Windows -> Workstation -> macOS == not OK

Re: Virtualize OS X on Linux

#87

Post by lucb1e »

Svenstaro wrote: post #2

Don't Apple EULAs forbid emulating OSX on non-Apple hardware? I might be mistaken, of course, but I think I recall something like that.

Sure just like games' EULAs say "no copying!!1" but the law perfectly allows for copying for personal use (e.g. backup purposes) and everyone does it anyway.

Re: Virtualize OS X on Linux

#88

Post by q3k »

pjmlp wrote: post #82
pimeys wrote: post #50

Earlier quoted context omitted.

For me "all the Unix goodness" is a proper package manager, an environment I can modify as much as I want and nowadays too an environment that doesn't have yearly big updates, but a rolling release. My desktop has stayed exactly the same[0] for almost seven years already. My configs follow me from job to job and from computer to computer. I don't want or need changes, just an editor and a proper *nix kind of operatin…

Do you want a Sun-3?

A modern version of a Sun-3 with up-to-date hardware? Yes, please.

Re: Virtualize OS X on Linux

#90

Post by pjmlp »

q3k wrote: post #88
pjmlp wrote: post #82

Earlier quoted context omitted.

Do you want a Sun-3?

A modern version of a Sun-3 with up-to-date hardware? Yes, please.

This http://i.imgur.com/aMHU8vu.png doesn't need a modern version.

Hence my remark, the original workstation where twm was created is good enough.

Post reply on HN