[HN Gopher] macOS in QEMU in Docker
___________________________________________________________________
macOS in QEMU in Docker
Author : lijunhao
Score : 528 points
Date : 2024-07-31 04:51 UTC (18 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| cranberryturkey wrote:
| Does this work with kde/wayland?
| rzzzt wrote:
| It looks like the "vnc-version" Dockerfiles will set up an Xvnc
| server and direct QEMU's output to it, and you can connect to
| that using a VNC client. The standard version sets up X11
| forwarding over SSH and/or you can pass the host's X11 socket
| and corresponding DISPLAY variable directly to the container.
|
| QEMU also has its own built-in remote access capabilities
| (SPICE and VNC-based) but the former needs guest support.
| duskwuff wrote:
| It looks like it's running macOS under qemu (i.e. contained in
| a window), so I don't see any reason why it wouldn't.
| slivanes wrote:
| I wonder if progress will halt once newer versions of MacOS
| without Intel support are released?
|
| Can I run docker inside this container to get MacOS to run inside
| MacOS? ;)
| vbezhenar wrote:
| Theoretically you can always run qemu in full emulation mode.
| itsTyrion wrote:
| And practically even a minimal debian install takes minutes
| to boot to TTY with qemu-aarch64 on AMD64
| fragmede wrote:
| I mean you can just do that in any supported vm program.
| ProfessorZoom wrote:
| we must go deeper
| dariosalvi78 wrote:
| Can this run xcode?
| slivanes wrote:
| According to the readme on github, yes, although it takes about
| an extra 30GB of drive space.
| XiS wrote:
| I tried this last year. It works though it's pretty slow.
|
| I really hate having to also support the Apple ecosystem.
| Development, CI/CD integration is really poor without having to
| buy the hardware.
| keyle wrote:
| I run full apple hardware and < 2 years old and the damn
| thing is still pretty slow.
| KronisLV wrote:
| I have an M1 MacBook Air and the iPhone 2022 SE, so far the
| performance of both is pretty good!
|
| However, the prices are definitely outside my regular
| budget (needed it for an iOS app project cause of walled
| garden ecosystem) and I only got the 8 GB MacBook which in
| hindsight very much feels like a mistake, even with the
| exorbitant pricing for the 16 GB model.
|
| For the price of the 8 GB model I could have gotten a nice
| laptop with 32 GB of RAM built in. That said, I don't hate
| the OS, it's all quite pleasant and performs well.
| prmoustache wrote:
| He is meaning the performance of MacOS in docker is
| pretty slow on "native" MacOS hardware, not that his 2y
| old hardware has become slow.
| evnix wrote:
| Next time, just get a mac mini and plug in an external
| ssd
| pzo wrote:
| Honestly development in xcode is poor even on apple hardware.
| jayd16 wrote:
| Is it needs to emulate Intel macos, I wonder how many more
| xcode versions will be supported. Is the full release of 16
| even going to support Intel?
| prmoustache wrote:
| Is the redistribution of MacOS images allowed by the license or
| is this project distributing illegal copies in plain sight on
| docker hub?
| meatjuice wrote:
| This is clearly illegal
| diggan wrote:
| "Illegal" might be a bit strong, "Against the EULA" a bit
| more realistic, which may or may not be illegal, depending on
| the context and involved country.
| scintill76 wrote:
| I'm not a lawyer, but pretty sure unauthorized
| redistribution of copyrighted material is a crime (in the
| US.) This docker image contains Apple copyrighted files,
| probably, but anyone feel free to explain if I'm wrong.
| tombert wrote:
| I suspect that it probably doesn't matter; Apple has
| generally not cared about Hackintoshes as long as you
| aren't selling pre-made Hackintoshes. Apple probably
| doesn't really mind for stuff like this, since this
| probably isn't realistically eating much into Apple's
| market.
| hadlock wrote:
| You need to prove commercial intent to profit
|
| If a choir teacher distributes the lyrics to a Britney
| Spears song to their students for practice, there is
| nothing illegal about this
|
| If a choir teacher starts a website britneylyrics.com and
| puts ads on the website, that would qualify
|
| The EULA might prohibit redistribution, but you don't
| need to accept an EULA to copy-paste files, as far as I
| know.
| caconym_ wrote:
| My understanding is that commercialization certainly
| weakens a fair use argument, but that its absence does
| not automatically make a reproduction and/or distribution
| fair use.
| scintill76 wrote:
| I think you're right for the definition of criminal
| infringement. I still think this image is civilly liable
| for infringing Apple's copyright (not a crime as I
| originally said.)
|
| > The EULA might prohibit redistribution
|
| I don't think it matters. Copyright law automatically
| forbids copying. Well, assuming Apple complied with any
| requirements to have a valid copyright, which seems a
| safe bet.
| yao420 wrote:
| Idk but Correlium virtualizes iOS instances and was sued by
| Apple before settling the case.
| nine_k wrote:
| So, to clarify things: it's QEMU running in a container, and
| macOS running under QEMU inside it.
|
| This is really nice WRT the ease of installation: no manual setup
| steps and all.
|
| This likely expressly violates the [macOS EULA], which says:
| _<<you are granted a limited, non-exclusive license to install,
| use and run one (1) copy of the Apple Software on a single Apple-
| branded computer at any one time>>_ -- because the point is to
| run it not on a Mac. So, pull it and keep it around; expect a C
| &D letter come any moment.
|
| [macOS EULA]:
| https://www.apple.com/legal/sla/docs/macOSMonterey.pdf (Other
| versions contain the same language.)
| jbverschoor wrote:
| (iii) to install, use and run up to two (2) additional copies
| or instances of the Apple Software, or any prior macOS or OS X
| operating system software or subsequent release of the Apple
| Software, within virtual operating system environments on each
| Apple-branded 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
| macOS Server; or (d) personal, non-commercial use
| nine_k wrote:
| Indeed. That would cover a conventionally installed VM, like
| VirtualBox.
|
| But this is packaged as a Docker image, and Docker is Linux-
| specific. Linux is not officially supported by Apple on their
| hardware, and is certainly not prevalent on it. I doubt that
| the intended target audience of this project is limited to
| Asahi Linux.
| prmoustache wrote:
| > I doubt that the intended target audience of this project
| is limited to Asahi Linux.
|
| I guess that part of the license is meant to automatically
| disqualify an apple branded computer running a linux distro
| as host OS from running MacOS in a VM: "on each Apple-
| branded computer you own or control that is already running
| the Apple Software"
|
| Some smart ass might argue that "already running the Apple
| software" doesn't mean at the exact same time but more like
| "I am still running it sometimes as dual boot" but I am not
| sure this would pass the court test.
|
| And since I believe docker on MacOS runs on linux VM, so
| this would be running qemu on top of a linux vm on top of
| MacOS.
|
| I can't see any legit use of this. Anyone who would need
| automatized and disposable environments for CI/CD would
| simply use UTM on mac minis:
| https://docs.getutm.app/scripting/scripting/
| rbut wrote:
| Docker can run on macOS (albeit in a VM), but its still
| running on a Mac "that is already running the Apple
| Software". So its a perfectly valid option for Mac owners,
| even if its a VM + container + VM deep.
| monocasa wrote:
| This requires kvm exposed in the container. Does docker
| on mac support kvm?
| nine_k wrote:
| AFAICT, with QEMU, access to KVM is only required if you
| care about performance %) Otherwise it can emulate
| everything for you.
| monocasa wrote:
| This dockerfile explicitly enables kvm in a way that will
| cause qemu to fail if it's not present.
| exe34 wrote:
| I run Linux on a Mac book air, so this would allow me to
| run macos in a controlled environment if I could think of a
| good reason to do so.
| EspadaV9 wrote:
| Not sure that would be the case since it also includes
| this part
|
| > that is already running the Apple Software
|
| Running Linux on Apple hardware would not follow that
| part of the EULA.
| exe34 wrote:
| good thing I can't think of any reason to run macos.
| ramses0 wrote:
| The Tao of Programming, 7.3:
|
| """ "Corporate Headquarters has commanded," continued the
| magician, "that everyone use this workstation as a
| platform for new programs. Do you agree to this?"
|
| "Certainly," replied the master, "I will have it
| transported to the data center immediately!" And the
| magician returned to his tower, well pleased.
|
| Several days later, a novice wandered into the office of
| the master programmer and said, "I cannot find the
| listing for my new program. Do you know where it might
| be?"
|
| "Yes," replied the master, "the listings are stacked on
| the platform in the data center." """
|
| https://quasi.in/digital/ttop.html#Book7
| exe34 wrote:
| well put.
| Modified3019 wrote:
| I don't understand what this is trying to say.
| pzo wrote:
| Some unfortunately needs Xcode for building iOS or macOS
| apps locally even if you are coding in unity, flutter,
| react native, qt, unreal
| rfoo wrote:
| I believe it matches the base term, as you are allowed to
| run only one copy of the Apple software on an Apple
| hardware, unconditionally.
|
| It could be in a VM.
| thfuran wrote:
| And I guess once you've booted the VM, you are suddenly
| permitted to boot two more, as long as you have a lawyer
| on retainer just in case.
| jkaplowitz wrote:
| Docker actually ships their easy-to-use and commercially
| supported Docker Desktop product for macOS, which uses
| Apple's standard virtualization framework under the hood. I
| think it then runs the Docker containers within a Linux VM
| that it manages.
|
| For people who want an open-source CLI solution rather than
| a commercial product which for larger businesses requires
| payment, there's also colima which does roughly the same
| thing.
|
| So, lots of people very successfully use Docker on macOS,
| including on Apple hardware.
|
| This particular software would need nested virtualization
| to be highly performant, but at least on M3 or newer Macs
| running macOS 15 or newer, this is now supported by Apple's
| virtualization framework:
|
| https://developer.apple.com/documentation/virtualization/vz
| g...
|
| So, if that's not easy to do in a useful and performant way
| now, it will absolutely be possible in the foreseeable
| future. I'm sure that the longtime macOS virtualization
| product Parallels Desktop will add support for nested
| virtualization quite soon if they haven't already, in
| addition to whatever Docker Desktop and colima do.
|
| (Tangent: Asahi Linux apparently supports nested
| virtualization on M2 chips even though macOS doesn't.)
| nine_k wrote:
| Running Linux in a VM (for Docker) to run an emulator
| (QEMU) in it to run macOS in that looks to me like a
| senseless waste of resources. Linux and Docker add no
| value into the mix here.
|
| The same result can be achieved by running macOS right in
| the VM. This can be extra efficient since both the host
| OS and the guest OS are macOS, and the VM could use this
| fact.
|
| It may make sense to run macOS in an emulator like QEMU
| under macOS, if the host version us ARM and the guest
| version is x64 (or vice versa). But I don't see where
| Linux and Docker would be useful in this case.
| jkaplowitz wrote:
| I agree the particular combo I was discussing is likely
| not very useful when compared to just directly
| virtualizing macOS directly, except in niche cases.
|
| One such case, however, is when the user is already
| managing Linux Docker containers for other parts of their
| development or testing workflow and wants to manage macOS
| containers with the same tooling. That's legitimate
| enough, especially when it ends up supporting nested
| virtualization of the same architecture and not true
| emulation, to keep the performance penalty modest enough.
| wildzzz wrote:
| So basically you can run macOS however you want as long as
| you're already running macOS on Apple hardware.
|
| The question I've always had is how enforceable is that
| really? Obviously the whole point of Apple making macOS
| freely available is to run it on Apple hardware. They don't
| give it out for free to run on other hardware but can they
| really do anything about that other than require you to enter
| a serial number to download an image? If they really cared,
| they would just do something like hashing the serial number
| and current date and time against a secret key (maybe inside
| a read-only portion of the TPM) and only Apple would be able
| to verify that the hardware is legit. You would need to
| somehow expose the TPM to the hypervisor to be able to
| generate hashes for macOS to verify it's license. Clearly
| this is not a huge problem for Apple because they would
| already be doing this if it was an issue.
| obituary_latte wrote:
| Probably as enforceable as any other EULA. Windows surely
| has similar language. I'd guess that somewhere buried deep
| in the agreements, or somewhere, it says they can audit
| your usage somehow. Does it ever happen? I'd be curious to
| know.
| naikrovek wrote:
| Windows doesn't have similar language. Not directly,
| anyway. Depending on the edition of Windows you purchase
| and how your overall license agreement works, you get
| anywhere from zero to ten VM licenses per paid Windows
| license.
|
| I'm omitting a few details for brevity (MS licensing is
| nuts when you get into the weeds).
| angulardragon03 wrote:
| It's sort of enforceable - Apple's own virtualisation
| framework that lots of VM providers use (on Apple Silicon)
| actually enforces a hard cap of two guests, and won't allow
| you to spawn more.
|
| With other hosts, it's kind of an Adobe approach - you
| either weren't gonna buy a Mac anyways, or you might be
| tempted to buy a Mac after using macOS in a VM.
| Realistically, it's not worth Apple coming after you unless
| you're an enterprise making your money by breaking the
| EULA.
| pjmlp wrote:
| Via surprise audits from organisations like BSA, in
| collaboration with the police.
|
| https://www.bsa.org/
| skeaker wrote:
| For organizations, sure, but has this ever been done to
| an individual?
| pjmlp wrote:
| Individuals most likely not.
| znpy wrote:
| > you are granted a limited, non-exclusive license to install,
| use and run one (1) copy of the Apple Software on a single
| Apple-branded computer at any one time>>
|
| In that case... If I run Asahi Linux on my apple-silicon
| macbook pro as main operating system and then run macOS in a
| container I should be fine.
| prmoustache wrote:
| See the rest of the license, the host must be "already
| running the MacOS operating system" which I understand as
| host OS, not as capable of still running it because the sshd
| hasn't been wiped of a MacOS install.
| m463 wrote:
| You can run linux on a mac. In fact older intel used macs are
| inexpensive and run pretty well with little noise.
|
| ubuntu installs and runs easily. Other versions of linux - it
| depends.
| dqh wrote:
| Ubuntu 24.04 is a disaster in my mid-2015 MBP. Ubuntu 22.04
| is surprisingly good though.
| resource_waste wrote:
| To be fair, I'm not sure any linux veterans are using
| Ubuntu. Its a popular OS, but its not a good OS. (Think
| terrible pop music that teenagers will still listen to)
|
| Even Debian has lost its favorability by having sooo much
| legacy bloat, bugs, and outdated kernels that wont run
| Nvidia GPUs(2023) or other recent peripherals.
|
| I'd be much more curious how Fedora or OpenSUSE hold up.
| skeledrew wrote:
| How do you define "veteran"? I've been a Linux-only user
| for 10 years, and 9.5 of it is strictly with Kubuntu.
| resource_waste wrote:
| Feeling old when I say I'm at 18 years.
|
| But I think its an experience thing rather than 'years'
| thing. If you only used Ubuntu for 10 years, you wont
| know what modern linux is like.
|
| You sound like a Kubunutu expert, not a linux expert.
| skeledrew wrote:
| What is it that makes one a "Linux expert"? Knowing
| bash/awk well? Embracing the pain that some other distros
| are? Using Vim? If it's any of those then I'm definitely
| no expert, as I primarily use Python whenever bash starts
| to get even a bit complex, selected Kubuntu because I
| didn't have to deal with a bunch of source issues I had
| with Ubuntu (due to licensing; also avoided Arch as I
| heard it's a nightmare, but occasionally work on a CentOS
| box as part of my job), and do almost everything re text
| in Emacs.
| mynameisvlad wrote:
| "Sorry a decade of use is not enough to be considered an
| expert. Also your experience is useless because it's on a
| distro I don't like."
|
| This is just pointless gatekeeping doubled down on at
| this point. People can be experts and use Kubuntu. People
| can be veterans and use Ubuntu. People can be absolute
| beginners and use Arch or OpenSUSE or literally any other
| distro. Use of distro is in no way shape or form
| indicative of experience other than that some are easier
| to get started with for absolute beginners than others.
| But that doesn't make them any less good.
|
| It's a personal choice with each options having its own
| pros and cons. Not some indicator of experience or
| knowledge.
| dqh wrote:
| I've been continually using Linux for various purposes
| since the late 90s, and recently wrote a non-trivial
| kernel module for an embedded device. So I'm veteran-ish.
|
| I tried Ubuntu on my MBP because I thought its popularity
| would mean the best chance of things working out of the
| box. I'm long past having time to spend on getting basic
| things working.
| elliotto wrote:
| Who cares lol
| mosselman wrote:
| I don't think Apple would feel very threatened by this
| indeed. I share the who cares lol
| user_7832 wrote:
| > So, to clarify things: it's QEMU running in a container, and
| macOS running under QEMU inside it.
|
| A bit tangential but is this more performant/"better" than
| running MacOS on say Hyper-V? I understand my zen 4 laptop
| anyway won't allow GPU acceleration, I'm only looking to run a
| few apps (and maybe Safari) on it.
| ptspts wrote:
| My guess is that macOS on Hyper-V is faster.
| actionfromafar wrote:
| How much of these EULAs are actually enforceable though, and in
| which jurisdictions?
|
| Also, wouldn't it be the end user potentially in violation of
| the EULA, not the git repo provider?
|
| Edit: agreed about OS images, that does not look legit.
| 7bit wrote:
| GitHub repost are taken down all the time because they offer
| means to violate EULAs. See youtube-dl which was taken down
| couple of months back.
| hoistbypetard wrote:
| This youtube-dl?
|
| https://github.com/ytdl-org/youtube-dl
|
| Did it get taken down again? The takedown I remember was a
| few years ago, and GitHub announced some policy changes to
| make it harder for that to happen when they very loudly
| reinstated it:
|
| https://github.blog/news-insights/policy-news-and-
| insights/s...
| nine_k wrote:
| Fair. But the docker image provider would be in violation,
| never having received a license to redistribute macOS images.
| Without these, the seamless usability aspect is gone, though
| the repo remains pretty useful because it automates all other
| steps.
| windexh8er wrote:
| It's trivial to build these containers by grabbing the
| install images from Apple directly. Beyond that this is all
| covered in the documentation.
|
| I guess I'm curious why you're so focused on this violating
| anything? Apple clearly doesn't care as folks like myself
| have used it for years. Apple's target market is hardware
| buyers, not people who do things like this. If this
| actually impacted sales, sure - but Apple doesn't sell OSX
| anymore.
|
| As an aside the sickcodes work is great for people wanting
| to leverage Apple's "Find My" network with non-Apple
| devices by leveraging OpenHaystack [0].
|
| [0] https://github.com/seemoo-lab/openhaystack
| rty32 wrote:
| I assume EULA is mainly intended for preventing companies
| from running Hackintosh at a massive scale than aimed at
| individuals -- although build your
| business/infrastructure based on Hackintosh is a very
| questionable business and technical decision by itself.
| manojlds wrote:
| Why are you talking as though this is a new project. It's been
| around for years
| hundchenkatze wrote:
| > expect a C&D letter come any moment.
|
| This repo is 4 years old... I don't think it's coming.
| promiseofbeans wrote:
| Hey, not if you run it on a mac running Asahi
| riiii wrote:
| I like the moaning sound the EULA makes when it gets violated.
| ctoth wrote:
| Can I get a whole bunch of Apple stickers and brand the heck
| out of an old Dell r630 Server and run this on it? Or how about
| a cattle brand with an Apple logo?
| arilotter wrote:
| i remember making this joke a decade ago on the tonymacx86
| forums, lots of people did it for the lulz
| sangnoir wrote:
| > because the point is to run it not on a Mac.
|
| Says who? My Mac Mini runs Linux as the host OS, this project
| allows me to run MacOS as a guest OS on Apple hardware on
| demand.
| misiek08 wrote:
| How many levels possible? Did anyone already try? I mean MacOS
| running on docker on MacOS running on docker on MacOS running on
| docker on MacOS...
| hda111 wrote:
| Will not work with Docker on Mac:
| https://github.com/moby/hyperkit/issues/127
| Izmaki wrote:
| I really hate when "USB Passthrough" is used in situations when,
| at best, a "USB over ethernet proxy" is what is happening. That's
| not passthrough... It introduces a whole range of disadvantages
| that regular passthrough does not (and advanced passthrough might
| not) have.
| arghwhat wrote:
| Eh? QEMU USB passthrough is true USB passthrough. The problems
| with USB passthrough stem from issues related to USB
| controllers themselves and how device enumeration works, with
| the only better solution being PCIe passthrough of entire USB
| controllers... Which then present a different set of problems.
| Speaking from experience in large VM test farms with a
| significant amount of forwarded hardware.
|
| (However, "USB over ethernet proxy" is also a true passthrough,
| just one with higher latency than VirtIO.)
| ThatMedicIsASpy wrote:
| On proxmox with a USB DAC/AMP it is impossible to get correct
| audio without pcie passthrough of the usb controller
| Izmaki wrote:
| Yeah, isochronous mode is unfortunately not supported for
| USB passthrough on Proxmox. There were experimental
| implementations in oVirt back in the days (that is:
| experimental implementations in a non-prod, only-for-
| evaluation solution...).
| m463 wrote:
| I've run into this too. And I had to do a bunch of
| investigation into iommu groups to find a controller that
| wasn't shared.
| Izmaki wrote:
| I skimmed the README only and just saw the big section of USB
| over ethernet with the video image and everything, not the
| tiny mentioning of VFIO above it. Lol.
|
| But tell me please, which problems do you have with PCIe
| passthrough?
|
| Also speaking from experience in large VM test farms with a
| significant amount of forwarded hardware. I've never
| experienced problems with hundreds of machines doing exactly
| this, for years.
| arghwhat wrote:
| PCIe passthrough has a few quirks:
|
| 1. VMs operate on a _copy_ of certain PCIe descriptors
| obtained during enumeration /when forwarding was setup,
| meaning that some firwmare updates that depend on these
| changing cannot work correctly. The exact details have left
| my memory.
|
| 2. Foo states that only happen when forwarding. Hardware
| that seems so stable when used directly that bugs would
| seem inconceivable enter into broken states when forwarded
| and fail to initialize within the VM.
|
| Hardware and drivers are both full of bugs, and things
| become "fun" when either get surprised. You can deal with
| it when you're doing the forwarding your own hardware and
| using your own drivers so discovered issues can be debugged
| and sorted out, but it's much less fun when you're
| forwarding stuff from other vendors out of necessity.
|
| Dealt with this one just this morning.
|
| 3. Reset bugs. Hardware reset and sequencing is a tricky
| area (speaking from old FPGA experience), and some devices
| cannot recover without a full power cycle.
|
| In some cases, I can recover the device by stopping the
| forward, removing the device (echo 1 >
| /sys/bus/pci/devices/.../remove), rescanning and letting
| the host kernel temporarily load drivers and initialize the
| device, and then forward it again. Did that today.
|
| 4. Host crashes. Yay.
|
| Forwarding a single device on a user machine that still
| gets regular reboots tends to work fine, but things get
| hairy when you scale this up. I've had to do a lot of
| automation of things like handing devices back to the
| hypervisor for recovery and firmware management.
| Izmaki wrote:
| Strange... Sounds like you may be doing too many things
| manually or that what you're testing is the device that
| is connected directly to USB?
|
| In my case I need 3rd party USB devices (that always just
| work((tm))) to communicate and interact with hardware.
| Been automating/running literally hundreds of these
| configurations without a single issue related to USB or
| PCI passthrough. Even got switchable HUBs for USB in the
| mix sometimes, too (for power cycling specific USB
| devices). Works fine as well.
| arghwhat wrote:
| "Manually"? There is only QEMU/KVM, how many layers you
| put in between does not matter. Proxmox is just a pile of
| perl scripts doing the same.
|
| My experience is in testing both USB downstream devices
| and PCIe devices developed in-house. Some of the
| forwarded devices might be 3rd-party devices like hubs,
| relays for power cycling and USB isolators to simulate
| hot-plug, but the DUTs are stuff we manufacture.
|
| In the USB test scenarios (we have about ~100 such
| machines, on average connected to a dozen DUTs, some
| more), the symptom of failure is generally that the
| entire controller can discover downstream devices but
| permanently fail to communicate with any of them, or that
| the controller itself fails to initialize entirely.
|
| The PCIe test scenarios is not something I actively work
| with anymore, but involves a server room full of machines
| with 4-7 DUTs each and much more custom handling - such
| as hot-unplugging the device from the VM, resetting and
| firmware updating the device, and hot-plugging it back as
| part of the test running in that VM - as testing PCIe
| devices themselves exercise many more issues that you
| don't see with standardized hardware.
|
| I have done this for about a decade, so I've been through
| a few iterations and tech stacks. One can find things
| that work, but it's not in any way or form guaranteed to
| work.
| JayDustheadz wrote:
| Can this be launched on an M1 Mac? I'm trying to find a way to
| run a Big Sur VM on my M1 Mac on Monterey/Ventura.
| dyllon wrote:
| Couldn't you use UTM to run a macOS VM?
| JayDustheadz wrote:
| Sadly it doesn't look like it: https://mac.getutm.app/ "Note
| that macOS VM support is limited to ARM based Macs running
| macOS Monterey or higher."
| orbat wrote:
| Have you run into Viable
| https://eclecticlight.co/virtualisation-on-apple-silicon/ or
| VirtualBuddy https://github.com/insidegui/VirtualBuddy ? I
| think at least Viable has some limitations though
|
| Edit: "some" limitations is putting it lightly. From
| https://eclecticlight.co/2022/11/17/lightweight-virtualisati...
| which is apparently still current:
|
| > Apple's current implementation of lightweight virtualisation
| still has no support for Apple ID, iCloud, or any service
| dependent on them, including Handoff and AirDrop. Perhaps the
| most severe limitation resulting from this is that you can't
| run the great majority of App Store apps, although Apple's free
| apps including Pages, Numbers and Keynote can still be copied
| over from the host and run in a guest macOS.
|
| Same deal with VirtualBuddy, apparently the root of the problem
| is that some sort of hardware validations fail in VMs
| https://github.com/insidegui/VirtualBuddy/discussions/27
| bspinner wrote:
| Checkout tart: https://tart.run/quick-start/
|
| It uses Apples Virtualization framework and works well, besides
| issues with virtiofs. But those can be worked around with
| virtual block devices aka images.
| hamandcheese wrote:
| +1 for Tart (and seconded on avoiding virtiofs - which as a
| virtualization.framework problem, not and indictment on
| Tart's quality).
| Starmina wrote:
| Try VirtualBuddy https://github.com/insidegui/VirtualBuddy
| nottorp wrote:
| > Docker-OSX now has a Discord server & Telegram! The Discord is
| active on #docker-osx and anyone is welcome to come and ask
| questions, ideas, etc.
|
| No forum eh? Everyone should come to the live channels and ask
| the same questions again :)
| 42lux wrote:
| Discussions are open on their repo...
| replete wrote:
| The only chance at GPU acceleration is passing through a
| supported dGPU (>= AMD RX 6xxx @ 14.x, no chance modern nvidia)
| with PCI passthrough. Intel iGPUs work up to Comet lake, and some
| Ice Lake, but anything newer will not work.
|
| Apple Silicon build of MacOS probably not going to be emulatable
| any time soon, though there is some early work in booting ARM
| darwin
|
| Also Intel VT-x is missing on AMD, so virtualization is busted on
| AMD hosts although some crazy hacks with old versions of
| virtualbox can make docker kind of work through emulation
| steve1977 wrote:
| > Also Intel VT-x is missing on AMD, so virtualization is
| busted on AMD hosts
|
| Wouldn't that work with AMD-V?
| zamalek wrote:
| Yeah I would expect it too. As far as I know, AMD has had
| better luck with hackintoshes and VMacs.
| replete wrote:
| AMD is far more complicated than Intel based machines in
| this regard. There's never been an apple computer with an
| AMD CPU...
| replete wrote:
| Nope. There's only ever been Intel x86 apple computers so x86
| mac software is Intel specific. Most things work fine on AMD,
| but some things don't work without hacks, such as digital
| audio workstations, some adobe applications etc. And you
| can't run hypervisors on an AMD hackintosh, the work around
| for docker is to install an old version of virtualbox and
| make it emulate instead.
| synchrone wrote:
| Any word if this would run the iOS simulator?
|
| Edit: it actually does!
| arusahni wrote:
| Looking forward to kicking the tires on this to validate
| functionality in Safari.
| bckr wrote:
| Let's say I wanted to run a headless Logic Pro for programmatic
| music production. Would I use this? Or should I containerize the
| application itself? It's okay if I have to run it on Apple
| hardware.
| replete wrote:
| Depends on whether you have plugins requiring GPU acceleration,
| as there is none
| adamgordonbell wrote:
| Not to be confused with native Mac OS "containers":
|
| https://darwin-containers.github.io/
|
| This parent project is VMs of OSX with a docker interface, I
| think.
|
| Darwin containers are runc reimplemented in terms of MacOS
| chroot, so you do some isolation on native macs in a docker
| style.
| xandrius wrote:
| I'd love to try and see if it's possible to simply build for iOS.
| Say Unity, React Native, etc.
|
| This could be pretty awesome in terms of freedom, even if the
| build takes 5x more.
| arcanemachiner wrote:
| I did this. I had to share my USB port over Docker somehow
| (black magic I guess, instructions in the repo) and I was able
| to build iOS apps and run them on an iPhone.
| flawn wrote:
| What was the speed like?
| arcanemachiner wrote:
| For a basic Flutter app: tolerable
| ProfessorZoom wrote:
| That would impressive if you could build for React Native iOS
| (with native Swift modules) and run it on a simulator in this
| on a Windows machine
| airstrike wrote:
| At glacial speeds, indubitably.
| arilotter wrote:
| you can! you can also run it on a real iOS device using this
| tech. it's explicitly documented in the repo :)
| shepherdjerred wrote:
| Cross-compiling is likely a better approach:
| https://github.com/tpoechtrager/osxcross
|
| This is how Godot targets iOS:
| https://github.com/godotengine/build-containers/blob/main/Do...
|
| Here's a Docker image with the tools preinstalled, though
| you'll need some tweaks to target iOS:
| https://github.com/shepherdjerred/macos-cross-compiler
|
| While at RStudio (now called Posit), I worked on cross-
| compiling C/C++/Fortran/Rust on a Linux host targeting
| x86_64/aarch64 macOS. If you download an R package with native
| code from Posit Package Manager (https://p3m.dev/client/), it
| was cross-compiled using this approach :)
| mjlee wrote:
| Huh, why does this repo have its own glibc? Let's check the
| commit history: Self-host in the repo glibc to
| emphasize the temporariness of this patch sickcodes
| committed Feb 12, 2021
|
| Seriously though, this is great.
| pmarreck wrote:
| Now I just need a flake.nix that does the same thing lol (I don't
| like Docker...)
| daft_pink wrote:
| This would be awesome to run iCloud sync on my homeserver.
| Currently, there is no good way to physically backup iCloud on a
| homeserver/nas, because it only runs on windows/apple.
| toomuchtodo wrote:
| This might assist you in syncing this data and then either
| storing locally or pushing elsewhere for backups:
|
| https://github.com/steilerDev/icloud-photos-sync
|
| https://github.com/icloud-photos-downloader/icloud_photos_do...
| bm3 wrote:
| How would this help with that? What would this let you do
| that's different than just rsync'ing your iCloud folder from a
| connected Mac/PC to your NAS?
| dang wrote:
| Related:
|
| _Docker-OSX: Run macOS VM in a Docker_ -
| https://news.ycombinator.com/item?id=34374710 - Jan 2023 (110
| comments)
|
| _macOS in QEMU in Docker_ -
| https://news.ycombinator.com/item?id=23419101 - June 2020 (186
| comments)
| cheptsov wrote:
| If this receives support for an Apple GPU, it will be incredibly
| significant!
| croemer wrote:
| Note that this project currently provides only x86-64 Docker
| images, and not for aarch64.
| cheptsov wrote:
| I wonder if the project makes it possible to run macOS inside a
| container on a macOS host?
| replete wrote:
| No apple silicon emulators exist yet, and probably wont for
| years
| mappu wrote:
| Qemu can somewhat do it already, with limitations - see
| https://youtu.be/oZqFYJVOUQo?si=wKaK6vLzfomESerY
| replete wrote:
| Yes but the host he's using is Apple Silicon, I think what
| he's talking about is QEMU using Apple's Hypervisor
| Framework, which is what vmware Parallels, etc also use
| nowadays. Booting an apple silicon version of MacOS on non-
| Apple hardware probably isn't going to possible for a while
| as it would require emulation.
|
| In 2021 Blackberry, surprisingly, wrote this article about
| getting emulating the XNU kernel and getting it running on
| non-apple hardware, but its just a terminal:
|
| https://blogs.blackberry.com/en/2021/05/strong-arming-
| with-m...
|
| Someone would have to write something that can
| emulate/abstract the apple iGPU to get anywhere near a
| usable GUI - I'm no expert but I don't think this is going
| to happen anytime soon, so when Intel releases of MacOS
| stop happening apple hardware might be the only way to
| virtualize MacOS for a while
| evanhughes wrote:
| For some reason I was convinced this wouldn't work, I was wrong.
| I guess docker can run any image so that makes sense.
| shortformblog wrote:
| I did an interview with Sick Codes a while back where he talked
| about his approach to this product:
| https://www.vice.com/en/article/akdmb8/open-source-app-lets-...
|
| Also wanna point out the existence of OSX-PROXMOX, which does
| something similar for Proxmox home servers:
| https://github.com/luchina-gabriel/OSX-PROXMOX
|
| I've personally been using the latter on my HP Z420 Xeon; it's
| very stable, especially with GPU passthrough.
___________________________________________________________________
(page generated 2024-07-31 23:00 UTC)