[linux-l] Slackware (war rpm)

Jan Krüger jk at microgalaxy.net
Do Apr 8 23:51:53 CEST 2004


Olaf 'Rübezahl' Radicke wrote:
> Ich habe Slackware noch nicht benutzt, aber
> aber ich halte die vorgetragenen Argumente für
> Mumpitz.
> Wie soll das gehen in einer Firma
> mit > 1 000 Desktops.

Slackware bietet sehr leicht zu beherrschende Automatisierungshilfen.
zb. TAGFILES können beim Mass-Deployment sehr hilfreich sein.
Die erwähnte Einfachheit des Systems, läßt einige Probleme, die man 
mit "advanced" Distris hat, gar nicht erst entstehen. Dies hat mich 
geradezu verblüfft.
Was es leider von Hause aus nicht kann, ist pxeboot.

> a) Die nicht vorhandene Hartwareerkennung

hatte keiner so gesagt. Lediglich wurde darauf hingewiesen, daß die 
Hardwareunterstützung nicht so "breit" ist.

> soll ein 
> Vorteil sein ? 

Wenn man erhöhte Stabilität/Performance durch vendor-patch-vermeidung 
als Vorteil sieht ---> Ja

Wenn man lieber den USB-Printer mit TV und mp3 frisch vom ALDI-Markt 
für nur 1,99 Euro nutzen möchte ---> Eher nicht

 > Also > 1 000 X Kernel kompilieren oder was?

Erstmal Slackware ausprobieren und dann wundern.
Ordentliche Systemplanung ist auch von Vorteil, insbesondere, wenn sie 
  die vorhandene oder anzuschaffende Hardware mit einbezieht.

> b) Der Vorschlag Lib-Konflikte mit Doppelinstalationen
> unter /opt zu lösen, macht das auch nicht gerade 
> homogen.

homogen von wo aus betrachtet oder auf welcher ebene? Ist homogenität 
auf lib-ebene überhaupt das Ziel?

Das Ziel ist, also meines, das System zu nutzen bzw. nutzen zu lassen.
Der Fokus liegt also eindeutig auf der zufriedenstellenden 
Nutzbarkeit. Für einen Admin, sofern er nicht mit Job-security pokert, 
  kann dies bedeuten: Stabilität, Sicherheit, geringer Aufwand usw.
Für einen Nutzer: Funktionalität, Stabilität, usw.
(Je nach Anforderungen, variabel auszulegen)
Die Anforderung, daß alle Programme eine bestimmte lib-Version zu 
nutzen haben ist bei heutigen Festplattenpreisen weit hinten 
angestellt und auch gar nicht durchsetzbar. Es gibt zb. Software, 
deren Autoren sich weigern von gtk1 auf gtk2 umzusteigen, weil sie 
sich die Frage stellen "Wozu?" und so kommt es, daß bei vielen Distris 
sowohl gtk1, gtk2 und bald womöglich auch noch gtk3 bzw. mono dabei 
sein werden...

>  Und beim nächsten mal wird dann unter 
> /opt/opt/opt* installiert und wenn die Platte Nicht mehr
> reicht eine zweite unter /opt2 eingehangen oder was?

Das obliegt ganz den verwalterischen Fähigkeiten des Administrators.

verschiedene Strategien sind denkbar und in hohem Maße 
automatisierbar, zb. habe ich ja schon auf /package verwiesen. Eine 
Anzahl weiterer Software-Verwaltungsstrategien ist im Netz beschrieben.

Gruß
Jan



Mehr Informationen über die Mailingliste linux-l