Linux auf M1-Macs: Erster Boot-Erfolg macht Hoffnung auf mehr

Apple hat mit dem Wechsel zu ARM-Chips im letzten Jahr eine neue Epoche der Macs eingeläutet. Zu den Vorteilen der M1-Macs zählen – je nach Anwendungsgebiet – große Leistungszuwächse und eine längere Akkulaufzeit bei Mobilrechnern. Doch die neuen Chips bringen auch Nachteile im Vergleich zu ihren Intel-Vorgängern mit sich. Dazu gehört die eingeschränktere Kompatibilität zu Windows oder Linux. Während Nutzer die besagten Betriebssysteme auf Intel-Macs relativ problemlos installieren und verwenden können, gilt es bei M1-Macs (noch) hohe Hürden zu überwinden. Bei Linux gab es diesbezüglich vor Kurzem einen ersten Erfolg. Die Virtualisierungsspezialisten von Corellium brachten den Linux-Kernel auf Apples M1-Chip zum Laufen.


Das Unternehmen teilte via Tweet ein Foto, das den erfolgreichen Boot-Vorgang dokumentiert – inklusive des lapidaren Kommentars: „Da wir heute noch etwas Zeit übrig hatten, haben wir Linux auf den M1 portiert.“ Der dazu verwendete Programmcode soll Open Source werden. Zudem ist eine Veröffentlichung geplant.


Quelle: Twitter

Allerdings gibt es bei Apples M1 noch einige Einschränkungen gegenüber anderen Chip-Plattformen. Der Linux-Kernel für M1-Chips unterstützt bislang nur einen Prozessorkern. Zudem fehlt der USB-Support. Zu den weiteren Herausforderungen beim Linux-Port zählen darüber hinaus weiterhin die Treiber für die Grafikeinheit des Apple-Chips. Wie lange es noch zu einem vollwertigen Linux-Port dauert, kann derzeit nicht abgeschätzt werden. Aufgrund des proprietären Grafikchips und Apples Geheimhaltungspolitik bezüglich der eigenen Chips wird es nativ möglicherweise auch in Zukunft nicht funktionieren.

Gerichtsstreit zwischen Apple und Corellium
Corellium hat vor wenigen Wochen bereits für Schlagzeilen im Zusammenhang mit Apple gesorgt. Genauer gesagt ging es um eine Klage Apples gegen das Startup. Das Unternehmen aus Cupertino wirft Corellium Urheberrechtsverletzung vor, da das Startup den Betrieb von iOS innerhalb einer virtuellen Maschine auf Apple-fremden Geräten ermöglicht.

Die Klage wurde Ende 2020 vom zuständigen Gericht in Florida abgewiesen. Jedoch muss sich Corellium möglicherweise doch auf juristischen Ärger einstellen: Die Umgehung der Sicherheitsmaßnahmen in iOS zum Zwecke der Virtualisierung könnten eine Verletzung des Digital Millennium Copyright Act (DMCA) bedeuten – und so strafrechtlich relevant sein. Das Gericht prüft momentan etwaige Verstöße.

Kommentare

pünktchen
pünktchen18.01.21 16:53
Man sollte denken wo keine Verletzung des Urheberrechts da auch keine Umgehung von Massnahmen zum Schutz eben dieses Rechtes, aber da kommt dann das Ungetüm DMCA daher und erlaubt allen Firmen die Reichweite ihres Rechtes selbst festzulegen.
+4
Moka´s Onkel
Moka´s Onkel18.01.21 17:16
Das Urteil bzw. die Klageabweisung in Florida war erstinstanzlich. Apple ficht so etwas sicher bis zum Supreme Court durch.
0
macStefan18.01.21 17:27
Moka´s Onkel
Das Urteil bzw. die Klageabweisung in Florida war erstinstanzlich. Apple ficht so etwas sicher bis zum Supreme Court durch.

Die würden sogar vor den internationalen Seegerichtshof ziehen, wenn es ihnen etwas nutzen würde
+6
MacRS18.01.21 17:47
Aus meiner Sicht wäre es viel besser, wenn macOS/iOS etc. Linux als Unterbau hätte. Sie könnten sich einiges an Arbeit sparen hätten ein besseres Betriebssystem als BSD und die Tool-Chain wäre dann auch wieder auf dem gleichen Level. Das hätte schon große Vorteile für den Nutzer. Ich vermute mal, dass das lizenzrechtlich wohl nicht gehen würde, oder?
-16
Retrax18.01.21 18:09
MacRS
Aus meiner Sicht wäre es viel besser, wenn macOS/iOS etc. Linux als Unterbau hätte. Sie könnten sich einiges an Arbeit sparen hätten ein besseres Betriebssystem als BSD
Könntest Du das bitte etwas näher erläutern?
Ich verstehe es nicht.
Danke.
+8
Florian Lehmann18.01.21 18:10
MacRS
Aus meiner Sicht wäre es viel besser, wenn macOS/iOS etc. Linux als Unterbau hätte. Sie könnten sich einiges an Arbeit sparen hätten ein besseres Betriebssystem als BSD und die Tool-Chain wäre dann auch wieder auf dem gleichen Level. Das hätte schon große Vorteile für den Nutzer. Ich vermute mal, dass das lizenzrechtlich wohl nicht gehen würde, oder?

Du meinst so wie mit Android Automotive?
Die Frage ist nur, warum macht das Tesla und VW nicht und Daimler mit MBUX auch nicht?
BMW aber schon - und die haben aktuell noch Linux 😅
-1
MacRS18.01.21 18:16
Florian Lehmann
MacRS
Aus meiner Sicht wäre es viel besser, wenn macOS/iOS etc. Linux als Unterbau hätte. Sie könnten sich einiges an Arbeit sparen hätten ein besseres Betriebssystem als BSD und die Tool-Chain wäre dann auch wieder auf dem gleichen Level. Das hätte schon große Vorteile für den Nutzer. Ich vermute mal, dass das lizenzrechtlich wohl nicht gehen würde, oder?
Du meinst so wie mit Android Automotive?
Die Frage ist nur, warum macht das Tesla und VW nicht und Daimler mit MBUX auch nicht?
BMW aber schon - und die haben aktuell noch Linux 😅
Keine Ahnung, was ist denn bei Android Automative?
+2
ilig
ilig18.01.21 18:16
MacRS
Ich möchte mich Retrax anschließen. Ich verstehe es auch nicht.
Danke
0
Perdiste puesto primero18.01.21 18:18
macRS
Dir ist schon klar, dass der „Unterbau“ von macOS/iOS Darwin ist? Von BSD ist „lediglich“ das Userland, und inwiefern das schlechter wäre, als das von Linux wüsste ich jetzt nicht.
+4
MacRS18.01.21 18:34
Perdiste puesto primero
macRS
Dir ist schon klar, dass der „Unterbau“ von macOS/iOS Darwin ist? Von BSD ist „lediglich“ das Userland, und inwiefern das schlechter wäre, als das von Linux wüsste ich jetzt nicht.
Ich bitte diese "Unschärfe" zu entschuldigen. Das ist natürlich völlig richtig. Andererseits ist "Linux" ja streng genommen auch nur ein Kernel, aber umgangssprachlich meint man damit einen bestimmten Teil des Betriebssystems. Der Teil, den Apple von Linux übernehmen sollte, entspricht dem Umfang von Darwin.
In meiner Wahrnehmung wird das alles nicht in dem gleichen Tempo, der gleichen Qualität und der gleichen Priorität vorangetrieben wie andere Themen und das wäre auch gar nicht so schlimm, wenn man hier einfach auf einen Linux-Unterbau setzen würde.
-3
Michael Lang18.01.21 18:39
MacRS
Perdiste puesto primero
macRS
...und das wäre auch gar nicht so schlimm, wenn man hier einfach auf einen Linux-Unterbau setzen würde.

Na dann schlag das mal Apple vor
- Das größte Maul und das kleinste Hirn,wohnen meist unter derselben Stirn. - Hermann Oscar Arno Alfred Holz, (1863 - 1929), deutscher Schriftsteller
0
MacRS18.01.21 18:48
Michael Lang
MacRS
Perdiste puesto primero
macRS
...und das wäre auch gar nicht so schlimm, wenn man hier einfach auf einen Linux-Unterbau setzen würde.

Na dann schlag das mal Apple vor
Meine Frage ging eher in Richtung rechtliche Implikationen als technische Machbarkeit/Aufwand/Wahrscheinlichkeit. Das Steve Linus nicht ich noch mal fragen wird, ist mir schon klar.
+1
pünktchen
pünktchen18.01.21 18:52
MacRS
Aus meiner Sicht wäre es viel besser, wenn macOS/iOS etc. Linux als Unterbau hätte. ... Ich vermute mal, dass das lizenzrechtlich wohl nicht gehen würde, oder?

Doch das ginge schon. Gibt ja auch sonst kommerzielle Software die auf Linux läuft. Das kann auch ruhig das komplette Userland sein.

Allerdings denke ich dass macOS schon auf einige technische Besonderheiten von Mach angewiesen ist die sich bei Linux so nicht finden. Das wäre nicht gerade ein kleines Unterfangen.
+1
don.redhorse18.01.21 18:58
MacRS

eher friert die Hölle zu.

Wieviel Software hat Apple schon tot laufen lassen, weil der Quellcode unter GPL3 gestellt wurde. Denke da nur mal an SAMBA, also SMB. Deswegen hat Apple doch erst SMB X "entwickelt", weil es eben nur der BSD Lizenz unterliegt. Bei GPL muss alles OpenSource sein und alles Dokumentiert werden (grob gesagt). Bei BSD ist das viel freier und für solch verdongelten Unternehmen wie Apple viel einfacher zu Nutzen.

Ist nur ein Grund. Ein weiterer ist der ganz andere Ansatz. Während Linux einen monolithischen Kernel hat, ist Darwin ein Hybride aus dem XNU und dem (free)BSD Kernel (und noch anderen Bestandteilen). MacOS ist ein zertifiziertes UNIX.

Ich denke mal so ganz einfach ist es nicht Darwin gegen Linux zu tauschen.
+6
MacRS18.01.21 19:01
pünktchen
MacRS
Aus meiner Sicht wäre es viel besser, wenn macOS/iOS etc. Linux als Unterbau hätte. ... Ich vermute mal, dass das lizenzrechtlich wohl nicht gehen würde, oder?

Doch das ginge schon. Gibt ja auch sonst kommerzielle Software die auf Linux läuft. Das kann auch ruhig das komplette Userland sein.

Allerdings denke ich dass macOS schon auf einige technische Besonderheiten von Mach angewiesen ist die sich bei Linux so nicht finden. Das wäre nicht gerade ein kleines Unterfangen.
Z.B. bei den Tools, die Apple auf der Kommandozeile anbietet, habe ich schon das Gefühl, dass sie eher nach lizenzrechtlichen als nach inhaltlichen Aspekten ausgewählt werden, nehmen wir z.B. die Shell
+2
MacRS18.01.21 19:05
don.redhorse
MacRS

eher friert die Hölle zu.

Wieviel Software hat Apple schon tot laufen lassen, weil der Quellcode unter GPL3 gestellt wurde. Denke da nur mal an SAMBA, also SMB. Deswegen hat Apple doch erst SMB X "entwickelt", weil es eben nur der BSD Lizenz unterliegt. Bei GPL muss alles OpenSource sein und alles Dokumentiert werden (grob gesagt). Bei BSD ist das viel freier und für solch verdongelten Unternehmen wie Apple viel einfacher zu Nutzen.

Ist nur ein Grund. Ein weiterer ist der ganz andere Ansatz. Während Linux einen monolithischen Kernel hat, ist Darwin ein Hybride aus dem XNU und dem (free)BSD Kernel (und noch anderen Bestandteilen). MacOS ist ein zertifiziertes UNIX.

Ich denke mal so ganz einfach ist es nicht Darwin gegen Linux zu tauschen.
Ja das klingt mir schon sehr nach Lizenzproblemen.
+1
MacRS18.01.21 19:21
eher friert die Hölle zu.
+3
pünktchen
pünktchen18.01.21 20:31
MacRS
Z.B. bei den Tools, die Apple auf der Kommandozeile anbietet, habe ich schon das Gefühl, dass sie eher nach lizenzrechtlichen als nach inhaltlichen Aspekten ausgewählt werden, nehmen wir z.B. die Shell

Richtig, allerdings wird der Linux Kernel unter GPLv2 und nicht unter GPLv3 veröffentlicht. Damit hat Apple kein Problem. Und das wird wohl auch so bleiben, Linus Torvalds teilt die Ziele der GPLv3 nicht. Und wenn einzelne Programme im Userspace wie eben Bash die Lizenz wechseln kann Apple das Programm so wie bisher auch ersetzen.
0
pünktchen
pünktchen18.01.21 21:19
PS - halb OT fand ich im Zusammenhang interessant: Darling is a translation layer that lets you run macOS software on Linux
+1
freeroot
freeroot18.01.21 22:30
Das wäre klasse denn dann könnte man das coole Gerät frei verwenden.
vertrauen sie mir, ich habe einen mac 8-)
0
MacRS18.01.21 23:31
pünktchen
PS - halb OT fand ich im Zusammenhang interessant: Darling is a translation layer that lets you run macOS software on Linux
Technisch sehr interessant, aber irgendwie unnütz, solange grafische Programme nicht laufen.
0
maybeapreacher
maybeapreacher19.01.21 09:05
Lizenztechnisch UND technisch einfacher dürfte es sein mit dem Darwin Kernel das FreeBSD Userland zu nehmen, oder gleich ganz auf einen FreeBSD Unterbau zu setzen. Der ist ein richtiges Unix, die Tools etc sind extrem ausgereift und werden sehr gut weiter entwickelt. Und zusätzlich lässt die BSD Lizenz die kommerzielle Verwendung von Codeteilen zu ohne dass das Endprodukt OpenSource werden muss. Außerdem sind Sachen wie das Sandboxing das Apple ja auch gern nutzt bereits seit vielen Jahren Teil des FreeBSD Kernels.

Aber letzten Endes ist das alles nur Wunschgedanken, Apple wird nichts dergleichen tun, nicht mit Linux, nicht mit FreeBSD.
+1
MacRS19.01.21 09:13
Der ist ein richtiges Unix, die Tools etc sind extrem ausgereift und werden sehr gut weiter entwickelt.
Das ist halt einfach total exotisch, das nutzt keine Sau, Linux wird mit deutlich mehr Aufwand weiterentwickelt und ob das ein richtiges Unix ist, ist völlig irrelevant.
0
pünktchen
pünktchen19.01.21 09:18
Technisch dürfte das ziemlich egal sein, die verschiedenen BSD Kernel sind XNU auch nicht ähnlicher als der Linux Kernel. Ob die Lizenz nun BSD oder GPLv2 ist kann einem auch egal sein wenn es gerade darum geht auf einem standardisierten Unterbau aufzubauen. Solange man da nichts proprietäres draus baut stört doch die Pflicht den Code offen zu legen nicht.

Mir ist nur unklar was das bringen soll. MacRS meint "ein besseres Betriebsystem", nur wieso? Selbst wenn der Linuxkernel sagen wir im Schnitt 20% fixer wäre, was bringt das wenn alles was drüber läuft für XNU optimiert ist? Da sind die 20% ganz schnell wieder verloren. Wäre es nicht einfacher wenn nötig XNU zu verbessern als die viel grössere Menge Code der oberen Schichten von macOS und der ganzen Anwendungsprogramme? Da spart man eben keine Arbeit, das ergibt zusätzliche Arbeit.

Wenn XNU nun völliger Müll und nicht mehr zu flicken wäre, gut. Aber da sehe ich keine Anhaltspunkte für.
+2
awk19.01.21 09:39
MacRS
Aus meiner Sicht wäre es viel besser, wenn macOS/iOS etc. Linux als Unterbau hätte. Sie könnten sich einiges an Arbeit sparen hätten ein besseres Betriebssystem als BSD und die Tool-Chain wäre dann auch wieder auf dem gleichen Level. Das hätte schon große Vorteile für den Nutzer. Ich vermute mal, dass das lizenzrechtlich wohl nicht gehen würde, oder?

Das halte ich für eine ganz schlechte Idee. Damit würde Apple seine Unabhängigkeit aufgeben und allein dem Fortschritt, oder man könnte auch sagen dem Diktat, von Linus Torvalds unterliegen. Nicht falsch verstehen, ich habe nichts gegen Linus Torvalds, ganz im Gegenteil.
Das wäre auch nicht gut für Linux. Das würde krachen im Gebälk, ohne Ende.
Linux ist ein feines System für Server, die Desktop Versionen waren bisher alles Rohrkrepierer. Selbst das viel mit Vorschusslorbeeren bedachte Ubuntu hatte keinen Erfolg und ist mit seinen Vorschlägen an der Open Source Gemeinde gescheitert. Desktop Linux wird es niemals aus der Bedeutungslosigkeit heraus schaffen.
Google bedient sich zwar des Linux Kernels, macht aber sonst sein eigenes Ding. Die werden wissen warum.
+2
LoCal
LoCal19.01.21 10:09
awk
Google bedient sich zwar des Linux Kernels, macht aber sonst sein eigenes Ding. Die werden wissen warum.

Und selbst bei google muss man sagen, dass sie noch den Linux-Kernel nutzen. Die Bestrebungen bei google deuten sehr darauf hin, dass sie zumindest langfristig nicht mehr auf Linux setzen werden. Und interessanterweise ist Fuchsia auch nicht unter GPL sondern BSD-Lizenz.
Ich hab zwar keine Lösung, doch ich bewundere dein Problem
+2
pünktchen
pünktchen19.01.21 10:45
Google behauptet dem sei nicht so, es handele sich eher um ein Experiment. Dabei soll der Name Fuchsia eine Anspielung auf Apples Talingent OS sein:
Google’s official repository for Magenta states that “Pink + Purple == Fuchsia.” According to public statements by Fuchsia team members, Purple refers to Project Purple, which was the original iPhone project. And Pink is a reference to Taligent, Apple's failed experiment to replace its classic Mac OS with a new operating system.
+1
pünktchen
pünktchen19.01.21 11:19
Der Artikel erwähnt übrigens auch den vielleicht entscheidenden Nachteil von Linux:

One downside of the Linux kernel that Android relies on today is that it lacks a stable application binary interface (ABI) for software drivers. ...

This matters to the silicon vendors who write drivers for Android’s fork of Linux. Without a stable ABI, they must write and update drivers for each new version of Android in order for the kernel to continue operating with their hardware.

XNU hingegen verfügt mit dem I/O-Kit über ein stabiles Interface für Treiber.
+2
pünktchen
pünktchen28.01.21 10:40
Corellium hat die technischen Einzelheiten inzwischen auf ihrem Blog geschildert:

How We Ported Linux to the M1

(mit Anleitung wie man selbst Linux auf seinem M1 Mac installiert)

Anscheinend hat Apple sich durchgehend für eigene Lösungen entschieden die natürlich nicht dokumentiert sind was eine gewisse Hürde darstellt.

Ähnlich bei der GPU des M1 um die sich Alyssa Rosenzweig kümmert:

Dissecting the Apple M1 GPU, part I part II

Also ich denke spätestens wenn Apple den Support der M1 Macs einstellt sollte Linux perfekt drauf laufen.

PS - siehe auch Asahi Linux
0

Kommentieren

Sie müssen sich einloggen, um die News kommentieren zu können.