NUR 103 MB: Kleines & sicheres Alpine Linux getestet - Alpine Linux vs Raspberry Pi OS vs DietPi

Рет қаралды 7,857

U-Labs

Күн бұрын

Пікірлер: 15

@matthiaslorber4271 3 жыл бұрын

Top Video 👍🏻

@kwinsch7423 2 жыл бұрын

Package "libc6-compat" bietet glibc compatibilität. Es installiert ein glibc parallel zu musl. Damit sind die meisten vorkompilierten Binaries ausführbar. Der Speicherplatzvorteil ist dann allerdings weg...

@herrnietschke 2 жыл бұрын

Gut erklärt.

@dom1niceu 3 жыл бұрын

Heute Alpine wie du installiert, wie du nur in VBOX unter einem x64 System :) sehr nice das du nochmal detailliert paar Sachen erklärst, bei der ISO kannst du das ganze als sys installieren dann liegt das System direkt auf der Platte ohne commits vorher zu tätigen btw. Danke anyway ....

@ULabs 3 жыл бұрын

Gerne :) Alpine unterstützt genau genommen sogar drei Installationsvarianten: Diskless Mode ist die von mir gezeigte Variante, bei der das komplette Betriebssystem in den RAM geladen wird und Änderungen nur durch den commit permanent in dem Tar-Gz-Archiv gespeichert werden. Data Disk Mode ist ein Mittelweg, hier liegt das Betriebssystem ebenfalls komplett im Arbeitsspeicher, allerdings wird /var gemountet. Was du meinst ist der System Disk Mode, der das OS klassisch auf ein Laufwerk installiert. Sowohl klassisch als auch diskless haben beide ihre Vor- und Nachteile. Vor allem wenn man viele Schreiboperationen hat die sich nicht (sinnvoll) auslagern lassen, ist eine klassische Installation möglicherweise die bessere Alternative. Gerade auf dem Pi halte ich diskless für sinnnvoller, vorausgesetzt es ist genug Arbeitsspeicher vorhanden: SD-Karten sind relativ langsam und Schreiboperationen können die Lebensdauer verkürzen. Das geht natürlich auch mit einer klassischen Installation, da muss man aber wiederum ein paar Dinge verbieten. Zusätzlich kann man viele Änderungen die sich im Nachhinein als problematisch herausstellen, durch einen Neustart ohne commit einfach wieder rückgängig machen. All das lässt sich natürlich ebenfalls auf einer klassischen Installation umsetzen. Zum Beispiel mit einer Ramdisk, die man in /var/log einhängt, dann werden die schon mal nicht auf die Karte geschrieben. Oder man installiert gleich auf einer SSD, die für höhere Schreiblasten ausgelegt und zudem schneller ist. Für den Pi fand ich es interessant, diese Möglichkeiten direkt Out-of-the-Box zu haben.

@dom1niceu 3 жыл бұрын

@@ULabs das stimmt alles soweit :) hab beim Pi auch viel mit tempfs (RAM Drive MNT) gearbeitet um sinnlose Schreibzyklen zu vermeiden, daher echt ne nice Sache das sowas möglich ist auf einen einfachen Weg :D Fetzt schon das ganze hab sogar gesehen das es echt viele Pakete gibt also was so gängig ist :) selbst Mumble gab es wo ich staunte, PHP8.x liegt auch schon bereit echt nit schlecht für Python gerade da ich nen Matrix Server hoste könnte das vllt. sogar sinnvoll sein in ferner Zukunft.... Also nicht das Docker Alpine nicht bereit verwendet größtenteils, bin bei mir aber noch auf klassischer KVM Virt unterwegs, da ich im Heimgebrauch es als ausreichend bewerte mit paar VMs.

@derallli1 3 жыл бұрын

Wenn ein Debian stable Pakete nach 2 Tagen einfach durchreichen würde, wäre es für viele Anwendungen keine Option mehr. Für bleeding edge gibt es andere Distributionen (und auch einen Debian fork dafür).

@ULabs 3 жыл бұрын

Bei Alpine gibt es kein "einfach durchreichen". Auch dort werden die Pakete in einem eigenen Zweig getestet und erst dann in Main/Community bereitgestellt. Zwei Tage ist ein Extrembeispiel, bei anderen brauchen die auch etwas länger. Dennoch sind die mit Updates tendenziell deutlich schneller wie Debian. Das wollte ich damit aufzeigen, weil es man für einige Anwendungszwecke ja eben doch aktuellere Software möchte bzw. diese Vorteile bietet. Wobei das ja auch nur ein Teilaspekt von Alpine ist, der sich in die weiteren Ziele und Eigenheiten einreiht. Das sollte keine Aufforderung an Debian sein, deren Releasezyklen massiv zu verkürzen. Dies hat seine Daseinsberechtigung, eben so wie z.B. RHEL und deren Forks wie Rocky Linux, bei denen eine Hauptversion ~10 Jahre lang mit Bugfixes/Sicherheitsupdates versorgt wird. Für Projekt A sind solche stabileren und eher konservativen Distributionen besser, für andere machen Alternativen mehr Sinn. Gegebenenfalls kann man auch auf Container zurückgreifen. Damit ist die Wahl der Distribution zweitrangig, weil auch auf einem älteren CentOS aktuellere Software darin ausgeführt werden kann. In der Hinsicht bietet die Linux-Welt den Vorteil, dass man die Wahl hat. Kann manchmal auch die Qual der Wahl sein. Aber ich muss mich eben nicht in das vom Hersteller vorgegebene zwängen, wenn das für meinen Anwendungsfall nicht passt.