markusG hat geschrieben: ↑Mo 18 Jan, 2021 20:58
mash_gh4 hat geschrieben: ↑Mi 06 Jan, 2021 18:29
das problem mit der virtualisierung von mac OS ist leider nicht nur in den lizenzeinschränkungen zu sehen, die das ausdrücklich untersagen
Wäre ja kein Unterschied zum Hackintosh, oder? Wir gehen natürlich nur von der Theorie aus, ist ja in erster Linie ein Gedankenspiel.
naja -- im privaten mag das keine große rolle spielen, aber fü professionelle entwicklungs- und anwendungsszenarien ist das leider doch eine ganz entscheidende hürde, die das angebot an guten und ausgereiften lösungen massiv behindert [hat].
ein gutes bsp. dafür sind die auseinandersetzungen zw. corellium und apple während der letzten jahre vor gericht. (
https://www.heise.de/news/iOS-Virtualis ... 00847.html)
man muss in dem zusammenhang aber auch einfach ganz klar sehen, dass desktop-visuallisierung, wie sie dir hier vorschwebt, eine relativ unbedeutendes nischen-dasein führt, während die großen anstrengungen und optimierungen von virtualisierungslösungen eher den einsatz im server-umfeld betreffen, wo man damit die sicherheit bzw. zugriffsgrenzen von prozessen klar abstecken kann, und trotzdem vorhandene hardware möglichst gut und energiesparend auslasten kann. da aber apple auf servern praktisch überhaupt keine rolles spielt, ist es eben auch um derartige software nicht besonders rosig bestellt.
markusG hat geschrieben: ↑Mo 18 Jan, 2021 20:58
mash_gh4 hat geschrieben: ↑Mi 06 Jan, 2021 18:29sondern auch im weitestgehenden fehlen von paravirtualisierungstreibern auf seiten eines solchen gast-systems.
Wenn ich das richtig verstanden habe ist ja gerade der Gag an z.B. QEMU + KVM die Hardware durchgereicht werden kann und sich dann quasi wie ein Vanilla Mac verhält.
die virtualisierung kann in verschiedenen abstufungen relaisiert werden:
man kann natürlich alles bis hinunter zum prozessor komplett in software emulieren. ein gutes bsp. dafür sind virtualisierungslösungen, die direkt im browser linux od. ältere windows versionen via webassembly ausgführen können:
jslinux
sinnvollerweise nutzt man aber besser entsprechende virtulisierungsunterstützung direkt in der cpu, so wie es kvm unter linux sehr vorbildlich umsetzt, um unnötigen rechenaufwand dabei zu minimieren.
aber das gilt eben nicht nur für den prozessor bzw. die befehlsarchitektur, sondern durchaus auch für die emulierte hardware. hier nutzt man eben oft diese paravirtualisierten treiber um im zusammenspiel zwschen host- und gastsystem auch so dinge wie den netzwerkkarte od. lokale dateisysteme in möglichst effizienter und trotzem gut isolierter weise durchzureichen.
das bringt in der praxis ganz entscheidend performance-gewinn. in den meisten fällen kommt man damit bis auf ein paar prozent an die leistung bare metal installationen heran.
leider schaut's mit derartigen pravirtulaisierten triebern unter mac os nicht besonders gut aus. es gibt zwar ein paar wenige (bspw.
virtio-net-osx), aber generell ist der support für mac os deutlich unbefriediegender als bspw. für windows, wo derartige treiber auch für das herstellerseitig angebotene Hyper-V vorhanden sind, die aber auch von der virtualisierung unter linux genutzt werden können. dafür gibt's unter mac os eben leider keine entsprechung.
eine besonders knifflige angelegeheit, die hauptsächlich desktop-virtualisierungen berührt, betrifft das durchreichen von grarifikausgabe und GPU-beschleunigung zw. host und gast.
in einfacher form kann das etwa mittels virtio-vga/virt-gpu bzw.
qemu-virgil realisiert werden. leider fällt dabei aber weder die performance noch der funktionsumfang wirklich überzeugend aus. eine andere herangehensweise besteht darin, eine zusätzliche grafikkarte im rechner per PCI-passthrough vollständig einer virtuellen machine zu überantworten. auf diese weise kann man etwa unter qemu-KVM tatsächlich eine nvidia-karte mit den origianl-treibern im gastsystem vollständig und ohne negative auswirkungen auf die perfomance nutzen. damit die ausgfabe dann aber doch wieder am selben schirm erscheint. haben findige hacker bspw.
looking-glass entwickelt. die komplexität all dieser angesprochenen lösungen bzw. den einrichtungsaufwand derartiger GPU-virtualisierungs- und -passtrough-lösungen sollte man allerdings nicht unterschätzen.
wie gesagt, im server-umfeld spielt die grafikausgabe eine beinahe vernachlässigbare rolle. dort geht's eher darum all diese altlasten emulierter hardware möglichst zu minimieren. um die performance zu steigern und möglichst wenig systemressourcen zu blockieren (siehe:
firecracker,
nemu,
kata-containers).
natürlich kann man derartige virtualisierungsansätze auch nutzen, um das apple-betriesbssystem möglichst unabhängig von der tatsächlich verwendeten hardware nutzen zu können. es gibt auch ein paar community-projekte, die das entsprechende setup möglichst anwenderfreundlich und einfach machen wollen, trotzdem gibt's dabei jede menge probleme und den unübersehbaren widerstand von apple, der die ganze realativ aussichtslos erscheinen lässt. man muss sich also in dem zusammenhang wirklich fragen, ob es die mühen wert ist? gibt's wirklich anwendungen, die nur auf diesem betriebsystem zur verfügung stehen und es wert wären, solchen aufwand zu treiben? wie gesagt, mit allen anderen systemen verhält sich die sache mittlerweile deutlich einfach bzw. durchlässiger, und die erzielbare performance ist in der regel auch überall sonst höher...
markusG hat geschrieben: ↑Mo 18 Jan, 2021 20:58
Vorausgesetzt natürlich dass die Hardware unterstützt wird (also kein Nvidia* z.B.). Was mich bzgl. Hackintosh skeptisch macht ist dass wohl mit Big Sur der Kext Support eingestellt wurde wenn ich das richtig verstanden habe. Hab das so verstanden dass das bisher immer die Voraussetzung für einen Hackintosh gewesen ist?
ja -- die signierungspflicht von kernel-modulen und das immer schwieriger werdende installieren von software, die nicht über die apple-kontrollierten kanäle vertreiben wird, lässt die ganze sache immer unattraktiver werden.
mir persönlich reicht es schon, wie fürchterlich umständlich es ist, für das erstellen von freier software die notwendigen entwicklungsumgebungen für mac os einzurichten oder gar auf anderen betriebssystemen auf umwegen ausführen zu können. das macht es mehr oder weniger unmöglich, freie software, die prinzipiell auf jedem betriebsystem laufen würde, auch tatsächlich für mac benutzer bereitzustellen. die diesbezüglichen grenzen sind fast undurchdringbar -- entweder du bist drinnen od. draußen! im gegensatz dazu ist es mittlerweile wirklich kinderleicht geworden windows- od. android-software auch unter linux zu kompilieren, zu testen und bereitzustellen od. eben umgekehrt. auch die tatsächliche unterschied bzw. vorzüge und nachteile der verschiedenen gebräuchlichen betriebsysteme ebnen sich meines erachtens immer mehr ein. welches davon man tatsächlich benutzt, macht also meist ohnehin keinen großen unterschied mehr aus.