> Also bei mir kommt das so schnell nicht in Frage. Ich komme mit Linux
> (insbesondere mit dem Paketmanagement der RPM-basierten
> Distributionen) überhaupt nicht klar, habe bei besagten
> Distributionen von furchtbaren Update-Problemen gehört und habe kein
> gutes Gefühl angesichts der undurchsichtigen Zuständigkeiten bei der
> Entwicklung.
>
You’re right, man!
Ich habe mit Linux 0.99 begonnen, kurz ausgesetzt und bin seit 1.2.3
eigentlich ständig dabei - anfangs noch auf einem SX50 mit 4 MB RAM
(nachdem auch der fünfte, von einem Kollegen mit sagenhaft schnellem
DX4/100 kompilierte Kernel bei mir kommentarlos ausstieg fanden wir
dann heraus, dass die FPU-Emulation einzuschalten eine gute Idee
gewesen wäre :)). Damals war es noch eine Slackware, eine in der
Verzeichnisstruktur fehlerhafte CD aus einem Sybex-Buch …
Irgendwann landete ich bei RedHat und war damit lange Zeit zufrieden.
Die RPM machten das Installieren leicht, nachdem ich immer weniger
Zeit hatte, alles selbst zu compilieren. Und da ich ausschließlich
mit Servern arbeitete, gab es auch selten größere Probleme. SuSE
mochte ich nicht - erstens landeten da viele Konfigurationen
irgendwo, wo ich sie erst nach langwieriger Suche fand, zweitens
spuckte mir das unsägliche suseconfig immer wieder in die Suppe. Also
RedHat.
Von Version zu Version nahmen die Probleme zu. Zumindest bei meinen
regelmäßigen Versuchen, eine WS aufzubauen, bei den Servern habe ich
bisher Glück gehabt. So gewöhnte ich mich mit der Zeit daran, dass
ein simples “rpm -ivh” mir zuerst einmal einen ganzen Sack an
unresolved dependencies offenbarte, ich also erst einmal herausfinden
musste, welche Pakete denn bitte vorher zu installieren seien (die
natürlich wieder unresolved dependencies hatten). Ich gewöhnte mich
auch daran, dass ein “–nodeps” oftmals der letzte Ausweg war, und
dass, wenn dann das eine oder andere Programm auf prähistorischen
Library-Versionen bestand, ein SymLink in /usr/libs oftmals die
Rettung brachte (was das u.U. für Stabilität usw. bedeutete, will ich
lieber nicht ermessen).
Bis zur RH9. Nicht nur störte mich massiv, dass man zahllose für
einen Server sinnfreie Pakete, die zwangsweise mitinstalliert wurden,
mit dem Knüppel erschlagen musste. Ich habe auch einen kompletten Tag
damit verbracht, Wine nachzuinstallieren und dann auch zum Laufen zu
bekommen, und einen weiteren, um auf Samba 3.x upzugraden (und es
dann wieder zu entsorgen, weil XP-Clients reproduzierbar auf viele
freigegebene Files nicht zugreifen konnten).
Oh, sicher, ich hätte mich durch Lesen der Man-Pages up to date
halten können. Nur dummerweise war ich inzwischen aus den
SysAd-Schuhen herausgewachsen und machte sowas eigentlich nur deshalb
selbst, damit ich weiß, was ich den Kollegen an der Konsole mit einem
“installier mal ein XXX” eigentlich zumute. So habe ich mich auch
nicht intensiv darum gekümmert, warum der 2.4 Kernel versuchte, mir
IDE-Laufwerke als SCSI-EMulation zu verkaufen - gewundert hab ich
mich schon, aber es funktionierte wenigstens, so what.
Bei meinen fortgesetzten WS-Installationsversuchen landete ich
schließlich bei der Erkenntnis: “Mach eine Vollinstallation und fass
sie nie wieder an. Versuch nicht einmal, etwas upzugraden oder
zusätzlich zu installieren, danach laufen Dutzende andere Sachen
nicht mehr.”
Debian hatte ich bis vor ein paar Wochen gemieden. Irgendwie hatte
ich halt die fixe Idee, es sei unhandlich, veraltet, kompliziert. Bis
mich die o.g. Wine-Erfahrung tapfer werden ließ. EIne Mini-Woody
installiert, “man apt-get” … “und das soll funktionieren?”
Es funktioniert. Und ich bin von dem Konzept ziemlich begeistert.
Automatisches Auflösen von Paketabhängigkeiten, Installation aus
einem Sack verschiedener Quellen … it works!
Dennoch, ich denke, das Problem ist bei Linux systemisch. Wenn Pakete
aus allen Himmelrichtungen zusammenkommen, sind Inkompatibilitäten
kaum vermeidbar. Da hat es der große Konkurrent aus Redmond mit
seinem monolithischen Aufbau leichter. Was, ich gebe es zu, für mich
bisher der Grund war, auf meinen WS weiterhin auf Windows zu setzen:
Außer dem NET-Framework und der libpcap für Win wurde ich bisher nie
gezwungen, bei (den bei mir reichlichen) Neuinstallationen erstmal
irgendwelche Vorbedingungen zu erfüllen. Kaufen resp. Herunterladen,
“Setup.exe” oder den MSI-Installer starten, geht. Zu mehr - auch
zeitlichem Einsatz - habe ich bei einer Workstation keine Zeit (und
auch keine Lust). Und das nach einer Neuinstallation notwendige
Security Review (vernünftigen Mailer und Browser installieren, mit
einer personal Firewall den IE fesseln und knebeln, unnötige Services
dauerhaft erlegen usw.) ist in nicht mal einer Stunde durch (und auch
in gleicher Zeit anderen zu vermitteln - etwa meiner Frau
beizubringen, wie sie die o.e. RPM-Probleme lösen sollte, würde wohl
etwas länger dauern).
Ich bezeichne mich inzwischen auch auf dem Server nicht mehr als
“Vollprofi” - zuviel ist in den letzten 2 Jahren an mir
vorbeigallopiert, während ich meine Zeit statt in einer Shell in
absolut sinnfreien “Meetings” verbrachte und dort dafür zu sorgen
trachtete, dass meine “Konsolen-Ritter” ungestört arbeiten konnten.
Und auf dem Desktop war ich es noch nie. Aus dieser Sicht bevorzuge
ich für Server immer noch Unix - sei es Linux, sei es Solaris (das
IMO oft einfacher zu handhaben ist, vor allem bei Upgrades usw -
klar, es ist auch wesentlich “monolithischer” in der Herkunft als
Linux, da fällt sowas leicht), von mir aus auch *BSD (das mich nie
gemocht hat - vermutlich, weil ich viel zu wenig Zeit damit
verbrachte). Aber auf dem Desktop … gestern abend: Aus Bockigkeit
RH9 installiert mit KDE, ohne GNOME (ich mag GNOME eben nicht).
Nessus aus dem CVS von nessus.org geholt, Installer angetreten …
“without GUI, GTK missing”. Hm. GTK aus dem Netz geholt, “prm -ivh
…” - “unresolved dependenci…”. Ok. Nessud läuft auf dem Server,
mit NessusWX läßt sich auch gut arbeiten. Ohne dass mich ein
Installer von der Seite anmaulte.