News Linux-Container unter macOS: Apple Container 1.0 auf Swift-Basis erschienen

[werty1st]

Wäre schön wenn dieser Overhead durch die Linux VM wegfallen würde und man keine 100gb VM disk image Datei mehr braucht wo alle die docker Images liegen die man so nutzt. Zum Arbeiten an sich ist man auf MacOS ja nicht so dringend auf ein Linux System angewiesen wie unter Windows. Daher sehe ich den Vorteil eines persistenten Linux System unter MacOS nicht so sehr.

 

[andy_m4]

Unter FreeBSD gibt es ja bereits podman, oder funktioniert podman unter MacOS nicht, wegen dem Mach Kernelanteil?

So würde ich das auch sehen. MacOS X hat zwar FreeBSD-Anteile, es hat aber nicht den jail-syscall.
Zudem bräuchte man ja auch die Linux-"Emulation", die MacOS X auch nicht kennt.

Bleibt also realistischerweise nur der Umweg über eine VM. Und so sind die Apple-Container auch implementiert, wenn ich das richtig verstehe:
https://github.com/apple/container/...erview.md#how-does-container-run-my-container

Podman? Ja das das läuft auch unter BSD

Wobei das noch in einem eher frühen Stadium zu sein scheint:

The FreeBSD port of the Podman container engine is experimental and should be
used for evaluation and testing purposes only.

https://cgit.freebsd.org/ports/tree/sysutils/podman/pkg-message#n5

Unter BSD nutzt man klassicherweise Jails

Wobei Jails ist erst mal nur ein Mechanismus ist, der Isolation erlaubt.
Der kann z.B. von Container-Lösungen benutzt werden.
Wenn man also ein Schichtenmodell hätte, ständen Jails und Container auf unterschiedlichen Ebenen und sind daher nicht direkt vergleichbar.

btw.: Hat nur FreeBSD Jails. OpenBSD und NetBSD nicht (allenfalls noch DragonflyBSD, weil das aus FreeBSD hervorgegangen ist; das ist aber nicht on par mit den Jails aus FreeBSD). Von daher kann man nicht sagen "Unter BSD".

Microsoft’s WSL hat nur eine Aufgabe, Migrationen auf Linux zu verhindern.

Weiß nicht, ob man das so sagen kann. Microsoft ist ja inzwischen in erster Linie ein Cloud-Unternehmen geworden und dann ist es fast egal, was auf irgendwelchen PCs läuft.

Es ist nun mal so, das Linux viel nachgefragt wird und auch in Microsofts Azure-Cloud das breit angeboten wird. Und dann ist es nur folgerichtig, das man sozusagen als Service für die Windowsler ein Kompatibilitätslayer anbietet. Und das ist ja auch nicht grundsätzlich neu. Es gab schon früher die Windows-Services for UNIX.

Wer nicht mehr auf Microsoft angewiesen ist, der kann ja problemlos weg und der wird durch WSL auch nicht daran gehindert. Wer noch Windows-Kram hat und daher auf ein installiertes Windows angewiesen ist, dem erspart die WSL Dualboot bzw. irgendwie sich selbst eine VM zu erstellen.

 

[rzweinig]

Wobei das in der Praxis eine untergeordnete Rolle spielt. Weil die Referenz ist einfach aufgrund der normativen Kraft des Faktischen Linux.
Kaum ein Hahn kräht danach, ob etwas der Single-Unix-Specification entspricht. Wohl aber wird häufig nachgefragt, ob etwas Linux-kompatibel ist.

Ich weiß jetzt nicht wo die Überheblichkeit her kommt, die in den Posts mitschwingt, MacOS ist nun mal NICHT mit Linux kompatibel daher braucht man ja eine VM/Container.
Es gibt Überschneidungen so das man Komponenten der POSIX Familie wieder verwenden kann, so hat es auch einen X11 server (ich glaube aber mit anderen Namen) mehr aber auch nicht.

Auch verstehe ich das hier überhaupt nicht, wenn du dann auf einem link verweist wo genau das belegt ist?!?
Mann mus hier doch nicht alles mit quellen unterfüttern wie erzeugen ja kein Wiki Eintrag.

Man darf Behauptung übrigens durchaus belegen ;-)

 

[andy_m4]

Ich weiß jetzt nicht wo die Überheblichkeit her kommt, die in den Posts mitschwingt,

Ich weiß nicht, wie jetzt solche sehr vage formulierten Vorwürfe weiter helfen.
Vielleicht sollten wir uns darauf beschränken auf Sachebene zu reden und den Fühli-Fühli-Kram weglassen.

MacOS ist nun mal NICHT mit Linux kompatibel daher braucht man ja eine VM/Container.

Ich hab auch nichts anderes behauptet.
Im Gegenteil!
Ich hab ja sogar dargelegt, warum man für Linux-Kompatibilität eine VM braucht und den FreeBSD-Mechanismus eben nicht übernehmen kann, allen FreeBSD-Anteilen in MacOS X zum Trotz.

Der X-Server ist noch mal eine andere Baustelle über die man auch reden kann. Darum ging es aber auch erst mal gar nicht, weils quasi schon vorher scheitert.

Mann mus hier doch nicht alles mit quellen unterfüttern wie erzeugen ja kein Wiki Eintrag.

Naja. Wenn man Dinge behauptet, ist es schon gut, wenn man das auch unterfüttert.
Ob man das nun muss ... ja. Muss man nicht. Das war aber auch gar nicht meine Forderung.

 

[flaphoschi]

Es ist nun mal so, das Linux viel nachgefragt wird und auch in Microsofts Azure-Cloud das breit angeboten wird. Und dann ist es nur folgerichtig, das man sozusagen als Service für die Windowsler ein Kompatibilitätslayer anbietet. Und das ist ja auch nicht grundsätzlich neu. Es gab schon früher die Windows-Services for UNIX.

Wer nicht mehr auf Microsoft angewiesen ist, der kann ja problemlos weg und der wird durch WSL auch nicht daran gehindert. Wer noch Windows-Kram hat und daher auf ein installiertes Windows angewiesen ist, dem erspart die WSL Dualboot bzw. irgendwie sich selbst eine VM zu erstellen.

Leider sind die Unternehmen und Behörden blöd genug sich Microsoft eigenes Cloudzeug zuzulegen, Teams, Outlook und Konsorten. Dann heißt es wieder, man könne ja nicht weg migrieren und WSL liefert die Ausrede.

Was falsch ist. Kann man, man muss sich vorbereiten und einen harten Schnitt machen. Wichtig, alles was Kompatibilität verweigert sofort ersetzen. Ja nicht mit VM, Dual-Boot und WINE die Lage noch schlimmer machen. Ich habe das auch oft genug probiert, wenn deren API nicht per EU-Regulierung offen sind (z.B. Exchange) ist man chancelos.

Die Windows-Services vor UNIX (wir erinnern uns, Windows ist ZUNIX-Kompatibel) waren das Feigenblatt um Windows in US-Behörden rein zu bekommen. Hat Microsoft entfernt, als sie geglaubt haben die Monopolstellung wäre unangreifbar und diese Linux “kein Problem”.

Microsoft ist Windows tatsächlich egal (merkt man). Hauptsache die Anwender sind im Vendor Lock-in. Daher kaum Schmerz und ein Linuxserver zu verwenden, wenn dieser den Vendor Lock-in bereitstellt…

 

[andy_m4]

Dann heißt es wieder, man könne ja nicht weg migrieren und WSL liefert die Ausrede.

Ich denke, Du überhöhst damit die WSL ein wenig.

Denn Linux ist ja letztlich nur ein Werkzeug.
Wichtig für Entscheidungen sind ja Ziele und Anforderungen. Und die können beispielsweise darin bestehen, das man sagt, das man mehr Datensourveränität haben will. Oder mehr Unabhängigkeit von einzelnen Herstellern.

Und dann guckt man, was man machen kann. Und dann kann Linux ein Werkzeug dafür sein, das man das erreicht. Allerdings eine Entscheidung für Linux allein oder gegen Microsoft hilft einem ja nicht weiter.
Wenn man Datensourveränität haben will und deshalb auf seinen Rechnern flächendeckend Linux einführt und dann aber trotzdem seinen Kram auf Google-Servern hostet, hat man das Ziel verfehlt.

Insofern ist Linux allein so oder so kein Heilmittel.
Und dementsprechend ist die Rolle von WSL auch eher klein. Mal davon abgesehen: Selbst wenn es die WSL nicht gäbe, wäre es ja ein Leichtes eine VM mit Linux aufzusetzen. Man braucht also die WSL als Ausrede gar nicht. In the nutshell ist die WSL ja auch nur eine seamless Linux-VM.

Kann man, man muss sich vorbereiten und einen harten Schnitt machen. Wichtig, alles was Kompatibilität verweigert sofort ersetzen.

Ja eben. Aber das liegt ja an der strategischen Ausrichtung. Wenn ich da eh nicht wirklich Bock drauf hab, wird auch die WSL weder was befördern noch behindern.

 

[Mordi]

Ich kann auch nicht ganz diese Rufe nachvollziehen, dass WSL einzig und allein dazu da sei, die Verbreitung von Linux einzuschränken. Die Zeiten wo Linux für MS Sodom und Gomorrha war sind vorbei, der Konzern und sein Fokus hat sich gewandelt und große Teile des Cloudgeschäfts würden ohne Linux gar nicht funktionieren.
Soweit ich weiß zielt WSL2 auch gar nicht darauf ab als Server genutzt zu werden, sondern eher als lokale Linux Arbeitsumgebung für Devs und Admins - anstatt dass die sich Extra eine "große VM" hochziehen müssen.

 

[andy_m4]

sondern eher als lokale Linux Arbeitsumgebung für Devs und Admins

Ergänzung dazu:
So sagt es sogar Microsoft selbst (also zumindest das mit den Devs):
https://learn.microsoft.com/de-de/windows/wsl/faq#f-r-wen-ist-wsl-geeignet-

 

[steirerblut]

Jetzt müsste man bei Apple endlich mal die Watchdog Timeouts / Kernel Panic und APFS hinbekommen.
Das hier erwartet wird das Prozesse alle 30-60 einchecken ist nicht mehr Zeitgemäß. Wenn ich mir anschaue wie viel länger ein npnm install/deploy am Macbook trotz 13+Gbps Filesystem werkelt und wieviel langsamer zB Codex CLI mit zig Prozessen trotz potenter CPU mit super Performance mit zig Threads läuft ist das Teils schon merkwürdig.
Selbst der 4 Jahre alte 300 Euro Linux Mini PC mit billiger PCIE 3.0 SSD ist da schneller. Schon klar das MacOS jetzt kein Serverbetriebssystem mit hardwarenahen/prozessisolierten Scheduling+Watchdogs ist, wenn das selbe aber seit gefühlt 30 Jahren unter Unix keine Probleme gibt könnt ma das ja einfach rüber kopieren oder Watchdogs auf den Base Thread setzen, oder oder oder.
Aber najo, das perfekte Betriebssystem gibts eh dort wie da nicht.

 

[andy_m4]

mit zig Prozessen trotz potenter CPU mit super Performance mit zig Threads läuft ist das Teils schon merkwürdig

Offenbar wird aber bei Apple am Scheduler geschraubt. Und zumindest bei iOS wird das ja anscheinend schon benutzt.

 

[steirerblut]

@andy_m4 Ja soweit ich das verstanden hab liegts ja primär am restriktiven Prozessmonitoring des Watchdogs. Mal schauen, wär natürlich fein wenn wenn Apple da mal nach bessern würde. Schnell genug sind die Teile ja. jetzt nur noch die Zügel loslassen.