Welches Gastsystem?

VirtualBox schrieb:

Hallo und guten Morgen,

ich hätte folgende Frage:
Ich möchte mein System komplett virtuell aufsetzen. Entschieden habe ich mich für VirtualBox von Oracle. Gastsysteme wären 2 Linux und 1 Windows. Das Wirtsystem kann doch rech "klein" ausfallen - es braucht kein "Schnickschnack" wie Office, Browser, Mailsystem usw.
Gibts da eine Linuxdistribution, die so "mini" ist?

Vielen Dank im voraus...

Slackware kriegst du extrem mini.

Meine letzte Slackware Installation habe ich damals auf 120 MB Platzverbrauch runtergedrückt.

Slackware hat allerdings den Nachteil, dass es offiziell kein richtiges Paketmanagementsystem bietet.
Das Updaten wird also aufwendig.

Ich würde an deiner Stelle einfach ein Debian nehmen, das kann man auch klein kriegen.
Dann hast du auch ein System, dass man gut warten und pflegen kann.

Finnegan

Das kleinste was mir bisher untergekommen ist, ist Alpine Linux. Das waren in der Minimal-Version gerade mal 7,5MB.
War allerdings ein LXC-Container ohne eigenen Kernel.
Mit ein bisschen Software und Abhängigkeiten wirds natürlich schnell größer.

Danke für euere Tipps.

Das Alpine Linux scheint mir sehr interessant und ist auf ihrer Webseite nach erstem Querlesen gut dokumentiert.

Finnegan

VirtualBox schrieb:

Danke für euere Tipps.

Das Alpine Linux scheint mir sehr interessant und ist auf ihrer Webseite nach erstem Querlesen gut dokumentiert.

Hat allerdings auch ein paar Nachteile: Die Kommandozeilen-Tools von BusyBox sind zwar sehr klein,
aber auch oft um die weniger häufig verwendeten Funktionen beschnitten. Da kann man schon mal
auf Skripte stoßen, die z.b. davon ausgehen, dass ein Allerwelts-Tool eine bestimmte Funktion unterstützt
und das dann vor die Wand läuft. Man sollte aber auch problemlos die vollwertigen GNU-Varianten der
entsprechenden Tools installieren können (soche Sachen wie grep, sed, tar, etc).

hustbaer

Alpine verwendet musl libc = elendiges Drecksteil. Möchtegern binärkompatibel mit der glibc aber halt nicht wirklich.

Andrerseits ist Alpine quasi Standard bei Docker Images, d.h. man bekommt quasi alles was man braucht auch für Alpine, auch ohne dass man es selbst bauen muss.

Finnegan

hustbaer schrieb:

Alpine verwendet musl libc = elendiges Drecksteil. Möchtegern binärkompatibel mit der glibc aber halt nicht wirklich.

Ist die nicht-vorhandenen Binärkompatibilität der einzige Grund für die Einschätzung als "elendiges Drecksteil"?
Ich bin nämlich auf der Suche nach einer kleinen, kompakten C-Standardbibliothek, die sich ohne allzu viel Kopfschmerzen
statisch linken lässt um damit spezielle Programme zu bauen, die ohne irgendwelche externen Abhängigkeiten auf jedem
System mit einem Linux-Kernel laufen. Musl war einer der vielversprechenderen Kandidaten.

Mir ist allerdings auch schon aufgefallen, dass es bei Musl wohl ein paar Funktionen gibt, die sich etwas anders verhalten
als ihr glibc-Pendant. Das kann natürlich zu ekligen Bugs führen, wenn man größere Bibliotheken einbindet, die davon
ausgehen, auf einer glibc zu laufen. Werde wohl ein wenig damit experimentieren und gut testen.

Finnegan schrieb:

Ich bin nämlich auf der Suche nach einer kleinen, kompakten C-Standardbibliothek, die sich ohne allzu viel Kopfschmerzen
statisch linken lässt um damit spezielle Programme zu bauen, die ohne irgendwelche externen Abhängigkeiten auf jedem
System mit einem Linux-Kernel laufen.

Die BSD libc ist lizenztechnisch unkompliziert was statisches Linken betrifft.
https://en.wikipedia.org/wiki/C_standard_library#BSD_libc

Finnegan

computertrolls schrieb:

Die BSD libc ist lizenztechnisch unkompliziert was statisches Linken betrifft.
https://en.wikipedia.org/wiki/C_standard_library#BSD_libc

Ich habe allerdings ein paar Zweifel, ob es auch technisch unkompliziert ist, diese unter Linux zu verwenden.
Schliesslich ist die C-Standardbibliothek das Bindeglied zwischen OS und den höherleveligeren Programmen
und damit meistens sehr OS-spezifisch. Oder gibts die auch als Linux-Port?

hustbaer

Finnegan schrieb:

hustbaer schrieb:

Alpine verwendet musl libc = elendiges Drecksteil. Möchtegern binärkompatibel mit der glibc aber halt nicht wirklich.

Ist die nicht-vorhandenen Binärkompatibilität der einzige Grund für die Einschätzung als "elendiges Drecksteil"?

Jain.
Das Ding hat bzw. hatte auch lästige Bugs. z.B. dass statisch initialisierte rekursive Mutexen halt leider doch nicht rekursiv lockbar sind - deadlockt einfach beim 2. Lock. War mit ner relativ alten Version, ich kann nicht sagen ob der Bug noch aktuell ist.

Grundsätzlich ist aber davon auszugehen dass die musl mehr Bugs enthält, einfach weil weniger User und daher auch weniger Bug-Reports. Und wenn es um Dinge geht die keine klaren Bugs sind sondern eher "Meinungsverschiedenheiten" zwischen musl und glibc, muss man davon ausgehen dass die meisten Anwendungen wohl eher das Verhalten der glibc erwarten werden. Einfach weil die meisten gegen die glibc entwickelt wurden.
(Nicht dass die glibc jetzt so megamässig toll wäre, die hat auch Sachen drin wo's mir Angst und Bange wird, aber i.A. funktioniert die trotzdem recht stabil.)

Mit Docker relativiert sich das natürlich, da immer mehr Software und vor allem auch immer mehr Instanzen davon mit musl laufen. Aber ich kann mir nicht vorstellen dass musl auch nur annähernd gleichgezogen hat. Was diesbezüglich das grösste Ärgernis ist, ist dass Docker als defacto Standard mit Alpine auf ein musl System setzt, und man daher immer extra Builds für Docker benötigt -- zumindest sofern man die libc nicht statisch linken möchte. Da kann jetzt die musl direkt nichts dafür, aber ärgerlich bleibt es dennoch.

Dass die musl kein total unverwendbarer Haufen ist sollte damit auch klar sein. Ich neige manchmal bloss dazu Dinge etwas krass zu formulieren

Finnegan schrieb:

Ich bin nämlich auf der Suche nach einer kleinen, kompakten C-Standardbibliothek, die sich ohne allzu viel Kopfschmerzen
statisch linken lässt um damit spezielle Programme zu bauen, die ohne irgendwelche externen Abhängigkeiten auf jedem
System mit einem Linux-Kernel laufen. Musl war einer der vielversprechenderen Kandidaten.

Auf diese Anwendung bezogen kann ich nicht viel sagen. Probleme mit thirdparty Libs könnte es dennoch geben, aber der Teil dass du deinen eigenen Code kompatibel zu beiden Versionen halten musst entfällt damit ja schonmal - du verwendest dann ja nur/immer musl.

Viel genauer als "Probleme könnte es dennoch geben", was zugegebenermassen nicht viel wert ist, kann ich es leider auch nicht einschätzen.

Finnegan

hustbaer schrieb:

Viel genauer als "Probleme könnte es dennoch geben", was zugegebenermassen nicht viel wert ist, kann ich es leider auch nicht einschätzen.

Jo danke für die Info. Ich habe da auch so meine Pappenheimer, die mir schon viel Ärger bereitet haben - wenn ich ehrlich bin,
sogar fast jede Software die ich auf ein wenig unorthodoxe Weise eingesetzt habe. Es ist schon erschreckend, wie viele (tatasächliche)
Bugs in selbst weit verbreiteter Software stecken, wenn man sie ein wenig außerhalb der ausgetretenen Pfade benutzt. Manchmal
denke ich mir ich sollte besser Tester werden, bei dem Talent das ich habe mit meinen Use Cases Bugs aufzudecken, mit denen sonst
kaum jemand Probleme hat

Gerade die von dir erwähnten Mutexe wecken schlechte Erinnerungen. Hatte mal eine Menge Spass mit einem besonders schwer
festzunagelnden Deadlock in GStreamer. Spätestens seitdem halte ich Multithreaded C-Programe mit ihren ganzen quer über
den Code gesprenkelten locks und unlocks für absoluten Wahnsinn (besonders als jemand der ansonsten RAII gewohnt ist).

Ich werde wohl mal schauen was auf mich zu kommt. Eigener Code macht mir wenig Sorgen, aber die ganzen C-Bibliotheken lassen
mich schon etwas zweifeln. Die schaffen garantiert ne exzellente "Coverage"