Red Hat Linux 9.0 »Shrike« und 8.0.x »Phoebe« Review

Von Agon S. Buchholz, Dezember 2002 ff.

Distributionen : Allgemein : Red Hat : Versionen : 9.0 : Review : Übersicht
23-Dec-2002/09-Jan-07

Übersicht

Bis Mitte März 2003 waren drei Betaversionen von Red Hat Linux 8.1/ 9.0 (»Phoebe«) erschienen -- 8.0.92, 8.0.93 und 8.0.94 -- die ich auf drei verschiedenen Systemen verwende; die Freigabe des Psyche- Nachfolgers ist für Ende März (RHN- Abonnenten) bzw. Anfang April 2003 (Download und Packages) angekündigt.

Testumgebung

Zu den Testsystemen gehört

• ein SMP- Rechner mit einem Tyan Tiger MP S2460 Mainboard (ca. 2002) und zwei AMD Athlon 1900+ CPUs mit 1024 MB RAM ECC registered,
• ein PC mit CU-BX(E)- Board und einer Intel Pentium III/700 CPU mit 512 MB RAM (ca. 2000) und insgesamt sechs (!) IDE- Kanälen sowie
• ein älterer Rechner mit einem Gigabyte GA-5AX Board (ca. 1998) und einer AMD K6-2/300 CPU mit 512 MB RAM.

Die Rechner sind mit 512 bis 1024 MB RAM bestückt, verfügen teilweise über IDE- und teilweise über SCSI- Massenspeicher mit mindestens einer und bis zu sechs Festplatten sowie die übliche Ausstattung mit Netzwerk-, Grafik- und Soundkarten; weitere spezielle Hardware wie ISDN-, Firewire- oder Framegrabber- Karten ist derzeit nicht installiert.

Das SMP- System wurde von Red Hat Linux 7.3 über Red Hat Linux 8.0 »Psyche« auf die »Phoebe«- Betaversionen aktualisiert; die offiziellen Releases wurden jeweils von CD-ROM eingespielt, das Psyche- System über das APT-Reopsitory von Fedora online aktualisiert; der Rechner ist als Workstation konfiguriert. Bei den anderen Rechnern handelt es sich um frische Installationen von CD-RW bzw. via NFS, der Rechner mit PIII/700 dient u.a. als Fileserver und ist als Server mit Software-RAID konfiguriert. Auf Besonderheiten der jeweiligen Hardware werde ich innerhalb des Erfahrungsberichtes eingehen.

Als Testumgebung dient ein kleines heterogenes LAN mit zehn PCs, Masquerading und festen IP-Nummern, die über ein Gateway (dedizierter Rechner unter Fli4L) mit dem Internet verbunden sind. Im LAN befinden sich ausserdem fünf Windows- Clients, darunter zwei Windows XP- Installationen und zwei Windows 2000- Rechner sowie ein System unter Debian GNU/Linux in der Variante Testing/ Unstable; gelegnetlich läuft noch ein 486er Notebook unter einer älteren Red Hat Linux- Version, das jedoch nicht in den Test einbezogen wird.

Zu den verwendeten Protokollen im LAN gehören u.a. NTP (Synchronisierung der Systemzeit vom Gateway), HTTP (Zugriff auf einen Intranet- Webserver), SMB (Datenaustausch zwischen Windows- und Linux- Rechnern) sowie NFS (Datenaustausch zwischen den Linux- Rechnern). Auf den Windows- Hosts läuft Cygwin und SSH, aber weder NFS noch das X Window System. Rudimentäre Fernadministration der Windows- Rechner von einem Linux- Host aus wird über VNC abgewickelt, das ist aber so langsdam, dass es nur für "Notfälle" benutzbar ist. Die RDP- basierten Terminal Services funktionieren von meinen Linux- Hosts leider nicht.

Was bleibt gleich?

Die mit »Psyche« eingeführte Desktop- Oberfläche Bluecurve bleibt in den Betaversionen weitgehend erhalten, wurde jedoch verfeinert und teilweise erweitert.

Der traditionelle Schwerpunkt von Red Hat auf Gnome als Standard- Desktop wird ebenfalls beibehalten, die Unterstützung für KDE jedoch verbessert. Unter Gnome fehlt beispielsweise weiterhin ein brauchbares Launch Feedback für gestartete Applikationen (die Entsprechung für die ungeliebte Sanduhr unter Windows).

Ebenfalls weitergeführt wird der GTK- basierte graphische Installer (Anaconda), der mittlerweile (theoretisch) sogar die Einrichtung eines Software-RAID- Arrays erlaubt; alternativ steht bei der Installation weiterhin eine textbasierte Version mit automatischer Hardwareerkennung (boot: linux text) bzw. weitgehend ohne Autokonfiguration (boot: text expert) zur Auswahl; für die Hardware- Erkennung ist weiterhin Kudzu zuständig, der ja dank GPL auch beispielsweise in Knoppix hervorragende Arbeit leistet.

Die Unterstützung von Systemen mit Intel i386/ i486- CPUs scheint Red Hat endgültig aufgegeben zu haben; auch die 8.0.94 setzt mindestens einen Rechner mit Intel Pentium- CPU voraus.

Zusammenfassend ist festzustellen, dass Red Hat viel Wert auf Kontinuität, Stabilität und Produktpflege zu legen scheint. Ebenfalls bemerkenswert ist die bewährte Red Hat- Strategie, nur als stabil geltende Versionen zu integrieren; Backports vom 2.5er- Entwicklerkernel à la SuSE oder abgefahrene 2.4.21-pre2- Kernel à la Mandrake Linux 9.1 sucht man also auch weiterhin bei Red Hat Linux vergeblich.

Was ist neu?

Red Hat implementiert in 8.0.94 zahlreiche Aktualisierungen, darunter die topaktuellen Desktop- Umgebungen Gnome 2.2 und KDE 3.1; die Auswahl an alternativen Desktops wie XFce oder GNUstep ist jedoch reichlich limitiert.

Die durch Bluecurve für Gnome und KDE vereinheitlichte Menüstruktur wurde überarbeitet und aufgeräumt; es gibt deutlich weniger Menüeinträge wie Kategorie/ Extras/ Mehr Extras. Das ist eine ansehnliche Verbesserung, aber Red Hat Linux fällt hier gegenüber der extrem konsistenten Menü- Strukturierung bei Debian GNU/Linux noch immer deutlich ab.

Der Dateimanager Nautilus wirkt subjektiv performanter -- nur auf dem SMP- System wirkt die Gesamtperformance beider Desktop- Umgebungen von Release zu Release schleppender; vermutlich kehrt jetzt bei den Linux- Desktops das Problem früherer Windows- Versionen ein, die nach längerem (mehrjährigen) Betrieb derart mit DLLs und Registry- Einträgen zugemüllt wurden, dass sie auch immer träger wurden. Das Problem ist bei Windows- Systemen seit Windows 2000 hinreichend gelöst, daher ist wohl davon auszugehen, dass auch die Linux- Desktops dieses Problem früher oder später in den Griff bekommen.

Eine weitere wichtige Neuerung von »Phoebe« ist XFree 4.3, das in der 8.0.94 noch in einer Betaversion ausgeliefert wird; die neue XFree- Version verfügt über zahlreiche interessante Neuerungen, darunter auch die Möglichkeit, die Bildschirmauflösung im laufenden Betrieb zu wechseln. XFree ist in der Ende Februar verfügbaren Version zufriedenstellend stabil mit Standard- Grafikkarten wie der noch halbwegs aktuellen Matrox Millennium G550 oder älteren Elsa- Karten mit Nvidia TNT2- Chipsatz; aktuelle 3D- Grafikkarten verwende ich unter Linux nicht, daher kann ich hierzu keine Aussagen machen, leider steht mir auch keine Matrox Parhelia zur Verfügung.

Natürlich wurde auch der Kernel aktualisiert; Red Hat "wagt" den Sprung von 2.4.18 auf 2.4.20, was seit dem Release am 28-Nov-2002 der aktuellste stabile Kernel ist; von Rawhide war Ende Februar 2003 2.4.20-2.54 verfügbar.

Zusammenfassed ist also festzustellen, dass Red Hat wirklich Up2date ist; nicht nur die Desktop- Umgebungen werden in den aktuellsten Versionen integriert, sondern auch X11, der Kernel und natürlich zahllose Anwendungspakete wie Mozilla, OpenOffice.org und Evolution. Das Mitte März freigegebene Release von Mozilla 1.3 wurde bisher nicht über Rawhide oder Fedora bereitgestellt, existiert jedoch bei mozilla.org unter ftp.mozilla.org/pub/mozilla/releases/mozilla1.3/Red_Hat_8x_RPMS/gtk2/i386 als Binary für Red Hat Linux 8.0.

Installation

Der Installationsmechanismus ist weitgehend identisch mit dem der Vorversion und weiterhin GTK- basiert (vgl. Review zu Red Hat Linux 8.0); die Firstboot- Prozedur wurde jedoch stark überarbeitet und erweitert; in 8.0.94 traten jedoch Darstellungsprobleme durch überdimensionierte Fenster auf -- sicherlich leicht zu beheben bis zum endgültigen Release.

Ein ernsthaftes Problem scheint 8.0.94 mit der Einrichtung eines Software-RAID- Arrays zu haben; der dafür zuständige Disk Druid funktioniert überhaupt nicht so, wie er laut Dokumentaton sollte. Auf mehreren Systemen gelang es mir nicht, ein System mit einer bootfähigen 6GB- Platte und einem Array aus vier 80GB- IDE-Platten für /home einzurichten; Anaconda hing immer während des anschliessenden Einrichtens des Arrays. Ich dachte zunächst, die läge am Asus CU-BX(X), welches über zwei normale IDE- Kanäle sowie über zwei zusätzliche Promise ATA- Kanäle verfügt, also insgesamt vier separate IDE- Kanäle; dasselbe Problem trat dann aber auch bei dem Tyan- Board mit einer 6GB und drei 80GB-Platten auf.

Ich mag Red Hats Disk Druid mittlerweile überhaupt nicht mehr, da es sich um eine Einweg- Lösung handelt; das Tool kann man bei der Installation nutzen, später nie wieder. Ein Äquivalent zu der ausgezeichneten Festplattenverwaltung unter Windows- Systemen existiert allerdings in keiner GNU/Linux- Distribution. Ich empfehle daher, Disk Druid zu vermeiden und zunächst nur ein rudimentäres Basis- System aufzusetzen; ein Software-RAID- Array sollte -- wenn es denn sein muss -- später von Hand mit den raidtools oder mdadm eingerichtet werden, das sind zuverlässige Tools, die wirklich funktionieren. Bei Red Hat Linux steht dafür kein graphisches Tool mehr zur Verfügung, angesichts der schlechten Erfahrungen mit Disk Druid ist das aber wohl auch besser so. Wer unter Linux ernsthaft IDE- RAIDs betreiben will, sollte ausserdem ernsthaft über einen echten Hardware RAID- Controller nachdenken.

Software-RAID verärgert unter Linux ohnehin, da es nicht möglich ist, von einem RAID Level 5- Array zu booten, für produktiven Fileserver empfehle ich daher die Verwendung eines zuverlässigen IDE-basierten Hardware-RAID- Controllers, beispielsweise eines Modells aus der 3ware Esclade- Serie; diese Geräte sind bootfähig und unterstützen sowohl Hot Swap als auch Hot Spare.

Weitere Probleme traten beim Tyan- Board bei einer gemischten IDE-/ SCSI- Konfiguration auf; beim Booten von einem IDE- CD-ROM- Laufwerk traten zahllose Fehler auf dem IDE-Bus auf, die zu diversen Resets und schliesslich zum Abbruch der Installation führten; dies tritt weder bei einem reinen IDE-, noch bei einem reinen SCSI- System und auch nur beim Tyan- Board auf.

Das letzte auffällige Installationsproblem bei der 8.0.94 bietet Grub, der sich zwar problemlos auf /dev/hda2 installieren liess, von dort aber nicht booten konnte. Auch dieses Problem trat nur in einer Konfiguration auf, beim Asus CU-BX(X) mit insgesamt sieben IDE- Geräten an den vier IDE- Kanälen, davon drei gejumpert als Slaves und vier als Master. Das ältere Gigabyte- Board wollte die 80GB IDE- Platten gar nicht erkennen und hing bereits nach dem POST, das liess sich aber durch ein BIOS- Update problemlos beheben.

Grundsätzlich erscheinen mir komplexe IDE- Konfigurationen unter Linux instabil zu sein, nicht nur unter Red Hat Linux; unter Windows 2000 Server lassen sich problemlos die wildesten Hardware-RAIDs bauen, beispielsweise mit bis zu acht IDE- Platten unterschiedlicher Grösse an einem Asus CU-BX(X)- Board, dort können dann Teile der Platten als RAID Level 5 und andere Teile als RAID Level 0 laufen, das ist stabil und problemlos. Linux gerät anscheinend leicht aus dem Tritt, wenn sich die IDs von SCSI- Platten ändern, bei dem IDE- Array hatte ich nach der manuellen Einrichtung allerdings keinen Ärger -- und habe auch kene Platten mehr ausgetauscht.

Upgrade

Beim Versuch, Mitte April den Fileserver mit dem Software RAID Level 5 Array von 8.0.94 Phoebe auf Shrike zu aktualisieren, meldet der Installer:

»Die Partitionstabelle auf Gerät hde ist nicht lesbar. Um neue Partitionen zu erstellen, muss die Tabelle initialisiert werden, was den Verlust ALLER DATEN auf dieser Festplatte bewirkt.

Diese Operation überschreibt alle in der vorangegangenen Installation gewählten Optionen der zu ignorierenden Laufwerke.

Möchten Sie diese Festplatte initialisieren und ALLE DATEN löschen?«

Dieselbe Fehlermeldung folgt für die Laufwerke hdf, hdg und hdi sowie hdk. Ich traue meinen Augen nicht, so schlecht kann doch das Final Release eines Betriebssystems im Jahr 2003 gar nicht sein...

Die Laufwerke hde, hdf, hdg, hdi und hdk gehört zum Array, der Installer hat darauf absolut nichts zu suchen: Das komplette Betriebssystem läuft vollständig von einer separaten Festplatte.

Nachdem ich alle Warnhinweise verneint habe rödelt der Rechner eine Weile auf den Platten und meldet:

»Fehler beim Mounten des Geräts md0 als /raid: Das Argument ist ungültig.

Das heißt, dass diese Partition nicht formatiert worden ist.

Drücken Sie OK, um ihr System neu zu starten«.

Nachdem das System wochenlang stabil lief, hatte ich nicht mit solchen Problemen gerechnet, aber bei GNU/Linux muss man wohl grundsätzlich mit dem schlimmsten rechnen.

Plötzlich bekommt eine Aussage aus Mohammed J. Kabirs Buch Red Hat Linx 8 Server eine ganz neue Bedeutung:

»I can't recommend software RAID as a tested solution with anything close to the confidence I have in hardware RAID« (S. 110).

... und es erklärt vielleicht auch, warum es in dem ausgezeichneten Band Handbuch zur Linux Systemverwaltung von Evi Nemeth, Garth Snyder und Trent Hein der Terminus "RAID" gar nicht erst auftaucht.

Dasselbe gilt übrigens auch für den Band Red Hat Linux 8 Unleashed von Bill Ball; hier wird das Thema RAID im Kapitel »Choosing a Backup Strategy« (!) am Rande und in nur zwei Absätzen abgehandelt (S. 330-331).

Oder anders fomuliert: Wenn schon RAID unter Linux, dann doch lieber hardware- basiert, damit das Betriebssystem nicht daran herumpfuschen kann. Oder noch besser: Software RAID unter Microsoft Windows betreiben, da funktioniert's zuverlässig und lässt sich auch updaten.

Konfiguration

Red Hat baut die Palette an graphischen Konfigurationstools quantitativ und qualitativ weiter aus; mittlerweile gibt es 76 Einstellungsmöglichkeiten unter Preferences, System Tools und System Settings.

Funktional ist jedoch kaum eins dieser Tools sinnvoll zu benutzen; das Tool für den Apache httpd beispielsweise unterstützt weiterhin nur die grundlegende Funktionalität dieses mächtigen Webservers und kann noch immer keine httpd.conf parsen; manuelle Änderungen in der Konfigurationsdaei werden beim nächsten Start des GUI- Tools gelöscht.

Ich liebe graphische Konfigurationstools -- aber nur, wenn sie denn zuverlässig sind und einen brauchbaren Funktionsumfang bereitstellen; solche systemweiten Tools gibt es in keiner aktuellen Linux- Distribution, weder bei Red Hat noch anderswo. Die GUI-Konfigurationstools, die Red Hat derzeit anbietet, schaden mehr als sie nutzen; auf die Kommandozeile und einen SSH- fähigen CLI- Texteditor à la GNU Emacs oder Vi/Vim kann m.E. weder derzeit noch in absehbarer Zeit weiterhin kein Red Hat- Administrator verzichten.

Der nachträgliche Einbau eines zusätzlichen Promise Ulta-100 TX2 IDE-Controllers war problemlos; es wird automatisch der Treiber des On-board- Controllers verwendet. Auf dem CU-BX(E)- System stehen dann sechs vollwertige IDE- Kanäle zur Verfügung, die beispielsweise für ein Software-RAID genutzt werden können.

Das Integrieren einer AVM ISDN- Karte, beispielsweise um einen Fax- Server oder ein SMS- Gateway zu betreiben bzw. die Aktivität auf dem ISDN- Bus zu visualisieren, ist aussichtslos unter Red Hat Linux und wird es wohl auch bleiben. Heimanwender haben aber immerhin mittlerweile recht gute Chancen, eine ISDN- Karte zur Internet- Einwahl verwenden zu können. Abhilfe schafft ein (Hardware-) Modem oder ein externer Terminaladapter wie das ZyXEL 2864ID; für die Benutzung von letzterem muss man sich allerdings intensiv mit AT- Codes auseinandersetzen, wie vor 15 Jahren unter MS-DOS; Konfigurations- oder Verwaltungstools gibt es für Windows, aber natürlich nicht für GNU/Linux.

Aktualisierung und Erweiterung

Das Software- Paradies, das beispielsweise Debian GNU/Linux mit seinen rund 8.710 mit einem simplen apt-get install einstallierbaren Softwarepaketen (Stand: Anfang 2003) bietet, ist bis auf weiteres für Red Hat Linux wohl eine Utopie; daran ändern auch die wenigen Dutzend Pakete von Freshrpms und Fedora grundlegend nichts. Möglicherweise bessert sich die Situation bei Fedora Linux im Lauf der Zeit, aber das ist sicherlich eine langwierige Angelegenheit.

Derzeit steht als halbwegs komfortabler Upgrade- und Erweiterungsmechanismus nur APT-RPM mit relativ wenigen APT-Repositories zur Verfügung, zum Beispiel:

[root@lx /]# cat /etc/apt/sources.list

# Planet CCRMA - Programme für Audio- und Videoverarbeitung (incl. neuer Kernel)

rpm http://freesoftware.ircam.fr/mirrors/planetccrma/apt redhat/9/en/i386 planetccrma
rpm http://www-ccrma.stanford.edu/planetccrma/apt redhat/9/en/i386 planetccrma


# KDE 3.1.4 von RedHat, Evolution (Ximian) 1.4.4, XFCE4rc4, MLDonkey,
# GIMP-1.3.17, OpenHBCI & Co ...

rpm http://vlugnet.org/apt redhat/9/en/i386 inoupdates vlugrpms
rpm-src http://vlugnet.org/apt redhat/9/en/i386 inoupdates vlugrpms


# Pakete von Matthew Hall, u.a. GNOME 2

rpm http://people.ecsc.co.uk/~matt/downloads/apt redhat-9-i386 gnome extras depends
rpm-src http://people.ecsc.co.uk/~matt/downloads/apt redhat-9-i386 gnome extras


# Fedora Linux repositories for Red Hat Linux 9 repository
# University of Hawaii Honolulu, Hawaii, USA

rpm http://download.fedora.us/fedora redhat/9/i386 os updates stable
rpm-src http://download.fedora.us/fedora redhat/9/i386 os updates stable

Das führt jedoch zu folgender Sackgasse (Stand: 23-Okt-2003:

[root@lx /]# apt-get upgrade
Lese Paketlisten... Fertig
Erzeuge Abhängigkeitsbaum... Fertig
Sie werde `apt-get -f install' ausführen wollen um diese zu beheben.
Die folgenden Pakete besitzen unerfülte Abhängigkeiten:
MySQL-server: Obsoletes: mysql
Obsoletes: mysql-server
mysql: Im Konflikt: MySQL
mysql-server: Im Konflikt: MySQL-server aber 4.0.15-0 ist installiert
E: Unerfüllte Abhängigkeiten. Versuche -f zu benutzen.

Das führt zu:

[root@lx /]# apt-get -f upgrade
Lese Paketlisten... Fertig
Erzeuge Abhängigkeitsbaum... Fertig
Korrigiere Abhängigkeiten ... Fertig
Die folgenden Pakete werden upgegradet werden:
lame libmad
Die folgenden Pakete werden ENTFERNT:
MySQL-server
2 Pakete upgegradet, 0 neu installiert, 1 entfernt und 0 nicht upgegradet.
Muss 0B/538kB an Archiven holen.
Nach dem Auspacken werden 25,5MB Plattenplatz freigegeben werden.
Wollen Sie fortsetzen? [J/n]
Checking GPG signatures...
Unsigned /var/cache/apt/archives/lame_3.93.1-1_i386.rpm: sha1 md5 OK
Unsigned /var/cache/apt/archives/libmad_0.15.0b-2_i386.rpm: sha1 md5 OK
E: Error: 2 unsigned packages
0 unknown signatures
0 illegal/corrupted signatures

Nicht nur die fehlenden Signaturen bei lame und libmad generieren hier ein Problem:

[root@lx /]# apt-get install mysql-server
Lese Paketlisten... Fertig
Erzeuge Abhängigkeitsbaum... Fertig
mysql-server ist bereits die neueste Version.
Sie möchten `apt-get -f install' ausführen um diese zu beheben:
Die folgenden Pakete besitzen unerfülte Abhängigkeiten:
MySQL-server: Obsoletes: mysql
Obsoletes: mysql-server
mysql: Im Konflikt: MySQL
mysql-server: Im Konflikt: MySQL-server aber 4.0.15-0 wird installiert werden
E: Unerfüllte Abhängigkeiten. Versuchen Sie 'apt-get -f install' ohne Pakete(oder geben Sie eine Lösung an)

Der Lösungsvorschlag, apt-get -f install auszuführen, bringt auch nicht das gewünschte Ergebnis:

[root@lx /]# apt-get -f install
Lese Paketlisten... Fertig
Erzeuge Abhängigkeitsbaum... Fertig
Korrigiere Abhängigkeiten ... Fertig
Die folgenden Pakete werden ENTFERNT:
MySQL-server
0 Pakete upgegradet, 0 neu installiert, 1 entfernt und 2 nicht upgegradet.
Muss 0B an Archiven holen.
Nach dem Auspacken werden 25,4MB Plattenplatz freigegeben werden.
Wollen Sie fortsetzen? [J/n]
Checking GPG signatures...
Führe RPM aus (-e)...

Statt -- wie angefprdert -- das System zu aktualisieren, entfernt die Paketverwaltung eine kritische Komponente, den MySQL- Daemon.

Die Aktualisierung scheitert aber weiterhin:

[root@lx /]# apt-get upgrade
Lese Paketlisten... Fertig
Erzeuge Abhängigkeitsbaum... Fertig
Die folgenden Pakete werden upgegradet werden:
lame libmad
2 Pakete upgegradet, 0 neu installiert, 0 entfernt und 0 nicht upgegradet.
Muss 0B/538kB an Archiven holen.
Nach dem Auspacken werden 136kB Plattenplatz freigegeben werden.
Wollen Sie fortsetzen? [J/n]
Checking GPG signatures...
Unsigned /var/cache/apt/archives/lame_3.93.1-1_i386.rpm: sha1 md5 OK
Unsigned /var/cache/apt/archives/libmad_0.15.0b-2_i386.rpm: sha1 md5 OK
E: Error: 2 unsigned packages
0 unknown signatures
0 illegal/corrupted signatures

Kurzum, die Paketverwaltung und Systemaktualisierung über APT-RPM ist für Endanwender in diesem Zustand unbrauchbar. Das betrifft nicht nur Vorab- und Betaversionen wie »Phoebe«, sondern auch die »stabile« Produktionsversion »Shrike«.

Weitere Probleme fängt man sich übrigens bei Mischung verschiedener inkompatibler APT-Repositories ein, ausserdem gerät man immer in die Dependency Hell, sobald der Ximian Desktop oder Ximian Red Carpet ins SPiel kommen. All diese vermeintlichen »Arbeitserleichterungen« sind nur zu sich selbst kompatibel und (zer-) stören alternative Paketverwaltungsmechanismen, statt diese zu ergänzen. Die Paketverwaltung von Debian GNU/Linux ist derzeit der einzige Mechanismus unter allen verfügbaren Linux- Distributionen, die diese Problematik halbwegs im Griff hat.

Kompatibilität und Interoperabilität

Die meisten RPMs für Red Hat Linux 8.0 funktionieren auch unter 8.0.94; es gibt keinen massiven Bruch in der Binärkompatibilität wie beim Sprung von Red Hat Linux 7.3 auf 8.0; das hängt sicherlich auch damit zusammen, dass sowohl Gnome 2.2 als auch KDE 3.1 binärkompatibel zu ihren Vorgängerversionen sind; zu den Ausnahmen gehört beispielsweise der Phoebe- httpd, der nicht unter Psyche läuft.

Mitte März tauchten dann Gerüchte auf den Mailinglisten <psyche-list@redhat.com> und <phoebe-list@redhat.com> auf, nach denen der Psyche- Nachfolger die Versionsnummer 9.0 (und nicht 8.1) tragen soll; begründet wurde dies u.a. mit der durch NPTL (Native POSIX Thread Library) eingeschränkten Binärkompatibilität. Dieser Schritt war eigentlich erst nach Freigabe von Kernel 2.6 erwartet worden.

Mit NPTL ist Red Hat Linux 9 jedoch immer binärkompatibel zu älteren Versionen. Probleme gibt es beispielsweise mit älteren Java- Umgebungen; nur die aktuelle Java-Ausgabe von Sun funktioniert wie erwartet. Zu den weiteren kritischen Komponenten zählen die 3D- Grafikkartentreiber von Nvidia; es existiert allerdings bereits ein Update für Red Hat Linux 9.

Die Interoperabilität mit Windows- Systemen steht und fällt mit Samba; hier gibt es keine nennenswerten Verbesserungen, Samba ist mehr schlecht als recht in die Desktop- Oberflächen integriert, es gibt allerdings ein neues GUI- basiertes Verwaltungstool für Samba; in Nautilus kann man mit dem Konstrukt smb:/// auf Freigaben in einer Windows Workgroup zugreifen, hier gibt es jedoch regelmässig Abstürze und Deadlocks.

Der Zugriff auf Windows XP- Shares von Red Hat- Rechnern aus ist durchaus möglich, aber recht wackelig; besser funktioniert es i.d.R. umgekehrt; nach etwa einer Woche Betrieb war der Software- RAID- Server nach einem Neustart von den Windows- Systemen im LAN nicht mehr sichtbar, er konnte jedoch noch auf die Windows- Freigaben zugreifen. Es ist allerdings etwas bizarr, von einem Windows XP- Rechner aus per SSH auf einen Linux- Rechner zuzugreifen, um von dort die Funktionalität von Samba zu testen... Im Verlauf der Testphase konnte das Array von Windows 2000- oder XP- Cleints nicht mehr über SMB angesprochen werden, der Rechner tauchte nie wieder in der Windows-  Netzwerkumgebung auf.

Nach "längerer" Uptime (8-14 Stunden) scheinen die Verbindungen jedoch komplett wegzubröseln, auch ein Neustart von smbd bzw. nmbd hilft da nicht -- ein Neustart des Betriebssystems dagegen schon; auch das ist wohl eine Eigenschaft, die Linux von älteren Windows- Versionen geerbt zu haben scheint. Überhaupt scheint sich GNU/Linux immer mehr alten Windows- Notnägeln anzunähern: Wenn irgendwas nicht mehr funktioniert, probier's mit einem Neustart; hilft das nicht, installier' das Betriebssystem neu.

Die Stabilität von Samba unter 8.0.94 ist m.E. nicht mit nativen Windows- Servern vergleichbar; selbst unser CIFS- Server, ein Filer F720 von NetApp, war da erheblich stabiler. Wer Vergleiche mit der Windows- Welt mag: die Standardeinstellungen produzieren in etwa dieselbe wackelige Netzwerkumgebung, die ich zuletzt unter Windows 95/ 98- Workgroups erlebt habe. M.E. ist jede Default- Installation von Windows NT 4.0/ 2000 oder 2003 Server deutlich stabiler.

Anzumerken ist zu der Option "Neuinstallation", dass es hier gravierende Unterschiede zwischen Windows- und Red Hat- Systemen gibt; sind auf einem Windows- System wichtige Systemdateien beschädigt, kann man den Rechner i.d.R. durch eine Neuinstallation retten; Windows erkennt die vorhandene Installation und stellt einen definierten Zustand her. Dabei gehen keine Daten verloren. Ein Red Hat- System kann man durch eine solche Neuinstallation nicht reparieren; man kann zwar eine Update- Installation durchführen, die behebt aber keinerlei Fehler. Was kaputt ist, bleibt auch danach noch kaputt.

Internationalisierung und Lokalisierung

Red Hat Linux hat eine bewegte Geschichte bei der Internationalisierung und Lokalisierung hinter sich; etwa seit der 7.0- Version ist RHL auch in brauchbarer Form an deutsche Gewohnheiten angepassst. Durch die Umstellung auf UTF-8 in Red Hat Linux 8.0 ergaben sich einige Rückschritte durch nicht ausreichend angepasste Programme; beispielsweise erfreuen die Startmeldungen mit diversen unpassenden Sonderzeichen; etliche Systemprogramme scheinen noch nicht Unicode- (UTF-8) clean zu sein.

Inkonsistenzen und Fehler

Anscheinend wurden wieder nicht konsequent alle mitgelieferten Pakete aktualisiert; so wird beispielsweise eine veraltete Version von X-CD-Roast ausgeliefert:

»Another RedHat 8.1 beta was released and this time it includes a current release of X-CD-Roast. But please note that the package seems to be broken and RedHat decided to remove the non-root-mode again. Just use the RPMs I do provide on my page to avoid problems« (T. Niederreiter am 02-Feb-2003 auf www.xcdroast.org).

Mit dem Update auf die Version 8.0.94 fiel bei dem SMP- System der KDE- Desktop aus; wählt man im GDM den Sitzungstyp "KDE", folgt die Fehlermeldung:

Could not start kdeinit. Check your installation.

Danach terminiert X11, startet neu und zeigt wieder den GDM. Gnome funktioniert dagegen weitgehend reibungslos; das Problem liess sich auch durch Installation der aktualisierten KDE 3.1.1- Pakete nicht beheben, trat aber auf den anderen Systemen nicht auf.

Völlig sinnlos erscheint mir die neue CD-Brennfunktion von Nautilus; man kann zunächst komfortabel Dateien in einem Ordner zusammenstellen und daraus ein ISO- Image erzeugen, damit aber nichts mehr anfangen; es gibt weder eine kontextsensitive Online- Hilfe (die gibts unter Gnome nirgends), noch überhaupt einen Eintrag zum Brennen von CDs über Nautilus im Hilfesystem. Selbst wenn diese Funktion implementiert sein sollte -- die Benutzerführung ist horrend schlecht.

Während das Software- RAID- System unter 8.0.94 insgesamt weitgehend problemlos lief, ergab sich doch ein recht gravierendes Problem: Der Rechner fährt nicht herunter, sondern hängt während der Shutdown- Prozedur reproduzierbar mit der Meldung:

Unmounting file systems:

Dieser Fehler liess sich bis einschliesslich 8.0.94 nicht beheben.

Ein weiteres Problem trat auf dem Software- RAID- Rechner durch die Verwendung eines KVM- Switches auf: Sporadisch verweigerte das System Tastatureingaben, hatte jedoch keine Probleme mit der Mausbenutzung (was leider unter einem Linux- System keine echte Alternative ist). Der Fehler trat wiederholt, aber nicht reproduzierbar auf; Abhilfe schafft hier nur ein shutdown -h now mit anschliessendem Ausschalten des Rechners. Ähnliche Probleme traten nach Berichten von Teilnehmern auf der Phoebe- Mailingliste mehrfach bereits während der Installation auf.

Mitte März wurde auf der Mailingliste <phoebe-list@redhat.com> verstärkt von Problemen mit der Paketverwaltung berichtet; die aktualisierten RPM- Pakete (rpm-*.71.i386.rpm) verursachten auf den Rechnern mehrerer Listenteilnehmer gravierende Probleme (Segmentation Fault bei mehr oder weniger allen RPM- Operationen):

• bugzilla.redhat.com/bugzilla/show_bug.cgi?id=86163.

Ein paar Tage traf es dann auch meine Installation auf dem SMP- System; sämtliche auf RPM aufsetzenden Tools (Paketverwaltungs- GUI, APT-RPM, Synaptic und rpm selbst) wurden mit einem Schlag disfunktional -- ein gravierendes Problem, das anscheinend unter bestimmten Bedingungen auch schon unter Red Hat Linux 8.0 aufgetreten war.

Ein Lösungsvorschlag von Warren Togami <warren@togami.com>:

• Fallback auf eine ältere Version von rpm und popt (z.B. popt-1.8-0.70.i386.rpm und rpm-4.2-0.70.i386.rpm) von einer älteren Red Hat- CD oder von people.redhat.com/jbj/test-4.2.
• Erstellen eines Arbeitsverzeichnisses:

mkdir temp
cd temp

• Extrahieren der Dateien aus den RPM-Paketen:

rpm2cpio ../rpm-4.2-0.70.i386.rpm | cpio --extract -d

• Kopieren der Binärdateien in die entsprechenden Systemverzeichnisse und Überschreiben der Dateien von rpm-4.2-0.71.
• Wiederholen derselben Prozedur für popt.
• Der Paketdatenbank den Fallback bekannt machen:

rpm -Uvh rpm*0.70*.i386.rpm popt*0.70.i386.rpm --oldpackage

Was fehlt?

Unterstützung für APT-RPM oder ein mit APT vergleichbares System für Online- Aktualisierung und -Erweiterung.

Up2date wäre ein potentieller Kandidat, unterstützt aber weiterhin nur die "offiziellen" Red Hat- Server. Das inoffizielle Current ist derzeit noch nicht für 8.0.94 benutzbar.

Das Software- Paradies, das beispielsweise Debian GNU/Linux mit seinen rund 8.710 mit einem simplen apt-get install einstallierbaren Softwarepaketen (Stand: Anfang 2003) bietet, ist bis auf weiteres für Red Hat Linux wohl eine Utopie; daran ändern auch die wenigen Dutzend Pakete von Freshrpms und Fedora grundlegend nichts.

Vernünftige Unterstützung von ISDN.

Red Hat Linux bietet eine sehr begrenzte Unterstützung für ISDN; insbesondere ISDN- Karten wie beispielsweise die verbreiteten Produkte von AVM sind kaum benutzbar; beispielsweise ist es faktisch nicht möglich, mit Red Hat Linux und einer aktiven ISDN- Karte einen Fax- Server zu betreiben, jedenfalls ist mit keine erfolgreiche (wahl aber zahllose gescheiterte Versuche) Installation bekannt.

Menschenlesbares Hardwareverzeichnis und -konfigurationstool.

Ausser /proc gibt es m.W. unter GNU/Linux kein konsistentes und zentrales Tool zum Überblicken der installierten Hardware und zum Konfigurieren der grundlegenden Features, bestenfalls distributionsspezifische Tools wie Yast2 unter SuSE Linux. Etwas so praktisches wie der auf jeder Installation an derselben Stelle vorhandene Windows- Gerätemanager fehlt völlig; die Tools zum Konfigurieren sind inkonsistent und über das gesamte Betriebssystem verstreut oder gar nicht erst vorhanden.

Vernünftige Unterstützung von lm_sensors oder anderen Systemen für Hardware- Monitoring.

Unter Windows ist das System- Monitoring mit Tools wie MotherBoard Monitor 5 (MBM 5) oder den Monitorin- Programmen der Board- Hersteller problemlos möglich, die Sensoren auf Motherboards oder die Diode im Die der CPU auszulesen, und das auf jedem geeigneten System und ohne Konfigurationsmarathone des Kernels auf jedem neuen System aufs neue. Red Hat Linux braucht ein autokonfigurierendes lm_sensors.

Vernünftige ACPI- Unterstützung, im Kernel oder sonstwo.

Es ist weder zeitgemäss noch akzeptabel, dass beispielsweise AMD Athlon- CPUs unter Linux 20W kontinuierlich mehr Strom verbrauchen als unter Windows und in einem SMP- Board bestenfalls mit Wasserkühlung vernünftig betrieben werden können, oder dass Notebooks unter Linux nur 30% der Zeit betrieben werden können, die unter Windows XP möglich ist, oder dass Rechner nach dem Shutdown nicht sauber heruntergefahren werden und und und...

Vorkonfigurierte Terminal- Services.

Knoppix hat es vorgemacht: ein vorkonfigurierter, sofort lauffähiger und vollwertiger Terminal- Server ist mit Linux mittlerweile realisierbar. Entsprechende Projekte gibt es, beispielsweise der Red Hat- basierte K12LTSP oder das Linux Terminal Server Project (LTSP); diese Funktionalität sollte Red Hat Linux von Hause aus bereitstellen.

MP3- und DeCSS- Unterstützung (oder lizenzrechtlich unbedenkliche, kompatible Alternativen).

Auch unter Red Hat Linux sollte es möglich sein, DVDs anzusehen oder MP3s anzuhören -- zumindest wenn ernsthaft der Desktop- Markt angepeilt werden sollte. Mich stört das Fehlen beider Funktionalitäten allerdings nicht, da Ogg ohnehin das bessere Audio- Format ist und sich DeCSS und MP3- Funktionalität problemlos nachrüsten lassen.

Graphischer Bootvorgang.

Weiterhin gibt es keinen graphischen Bootvorgang. Und das ist gut so.

Aufgabenorientiertes Arbeiten.

Spätestens mit Windows 2000 Server stellt Microsoft die Server- Systeme konsequent auf das aufgabenorientierte Arbeiten um, besonders drastisch wird dies bemerkbar in Windows .NET Server 2003, wo dieses Konzept bis zum Erbrechen durchdekliniert wird.

Dennoch -- man gewöhnt sich schnell daran, und stellt dann auch fest, das dieses Konzept wirklich hilft und das Arbeiten merklich beschleunigt: Der Umsetzungsschritt "wie und mit welchem Tool löse ich Aufgabe xy?" wird verkürzt auf die pure Ausführung der Aufgabe.

Das geht natürlich nur mit wiederkehrenden und häufigen Tasks, jedoch ist Windows hier dem aktuellen status quo von Red Hat Linux zwei Evolutionsschritte voraus:

• Schritt 1: vollwertige, funktionierende und stabile GUI- Tools,
• Schritt 2: aufgabenorientiertes Arbeiten.

Weitere Defizite.

Es gibt natürlich noch diverse weitere Defizite, die meisten davon sind jedoch systembedingt und liegen nur begrenzt im Einflussbereich von Red Hat; auch der weltweite Marktführer im Linux- Business hat beispielsweise nur vergleichsweise begrenzte Einflussmöglichkeit auf die Schaffung, Umsetzung und Einhaltung von konsistenten Usability- Richtlinien in Open Source- Programmpaketen; auch hier hat Microsoft als Monopolist einen faktischen (und für den Anwender nützlichen) Vorteil.

Fazit

Red Hat Linux ist in der aktuellen Betaversion 8.0.94 mit erheblichem Abstand die beste verfügbare Linux- Distribution; geboten wird eine gut abgewogene Kombination aus aktuellen Komponenten und grösstmöglicher Stabilität -- alles natürlich in Relation zur Aktualität; mehr Stabilität strebt Red Hat nur mit den Produkten Advanced Server und Advanced Workstation an.

Verbesserungsmöglichkeiten gibt es in grosser Zahl; ich gehe daher davon aus, dass spätestens Anfang Juni die nächste Runde im Versionskarussell mit der Vorbereitung von Red Hat Linux 8.2 oder 9.0 eingeläutet wird; möglicherweise steht dann auch Kernel 2.6 und damit ACPI- Unterstützung zur Verfügung.

Der von Red Hat eingeschlagene Weg, zunehmend graphische Konfigurationstools mitzuliefern, ist wegweisend; die Integration separater Programme für spezielle Aufgaben ist dabei weit stärker UNIX- like, als dies beispielsweise SuSE oder United Linux mit Yast2 praktizieren. Allerdings muss Red Hat noch viel Entwicklungsarbeit in die GUI- Tools stecken, bevor diese produktiv einsetzbar werden.

Andere Distributionen bieten bessere Detaillösungen als Red Hat; beispielsweise ist die Paketverwaltung von Debian GNU/Linux dem RPM- Mechanismus weit überlegen; mehrere Distributionen wie Mandrake, Lycoris und Xandros bieten erheblich besser vorkonfigurierte Desktop-Umgebungen, breitere Unterstützung für alternative Window- Manager, aktuellere Programmversionen usw.; Red Hat Linux bietet derzeit jedoch das ausgewogenste Verhältnis aller Komponenten, ragt in keinem Bereich besonders hervor, leistet sich aber auch -- als derzeit einzige grössere  Linux- Distribution -- keine nennenswerten Schwächen bei einer wichtigen Systemkomponente.

Red Hat Linux bleibt wohl auch in der Version 8.1 eine konkurrenzlose Allround- Distribution, die gleichzeitig für Server- wie auch Desktop- Installationen einsetzbar ist.

Andererseits sprechen die gravierenden Mängel dieser ausgewogenen Distributionen gegen GNU/Linux: Als Vorzeige- Distribution wird nicht nur Red Hat, sondern ein nicht unerheblicher Teil der Linux- Welt and Red Hat Linux 9 gemessen. In meinem Fall wurden von drei Testsystemen zwei während der mehrmonatigen unbenutzbar. Das Dual-System weigerte sich abwechselnd, Gnome (8.0.93) bzw. KDE (8.0.94) zu starten; kurz vor Veröffentlichund von Shrike bootete der Rechner dann gar nicht mehr. Der SMP- Rechner war unter Linux auch praxisuntauglich, da der Kernel kein ACPI unterstützt, die CPUs daher konstant unter Vollast und bei rund 80°C liefen -- und das trotz massiver Kühlung.

Natürlich kann man die Zuverlässigkeit eines Betriebssystems nicht an Betaversionen ablesen, einige Indikatoren bieten Betaversionen jedoch schon. Umso gravierender war die Unmöglichkeit, den Fileserver mit dem Software RAID Level 5 Array von 8.0.94 auf Shrike zu aktualisieren. Gerade ein RAID- Array ist eine höchst sensible Einrichtung, die ausschliesslich der Erhöhung der Datensicherheit dient. Gerade hier sollte ein Betriebssystem keine so gravierenden Mängel aufweisen.

Mein persönliches Fazit lautet derzeit: GNU/Linux ist unbrauchbar. Der ausgereifteste und benutzerfreundlichste Vertreter einer Linux- Distribution, Red Hat Linux, ist für mich weder für den Desktop- Einsatz (SMP- System), noch serverseitg (als Fileserver mit Software RAID) zu gebrauchen. Ein Betriebssystem, das ich nicht problemlos aktualisieren kann, richtet mehr Schaden an, als es jemals produktiv leisten kann. Schade.

Andere Meinungen

OSnews.com zur Betaversion von Red Hat Linux 8.0.94:

»Overall, even by being a beta, I feel that the Red Hat 8.x series are the strongest releases today in the Linux world and Red Hat, Inc. the leading Linux power which brings Linux one step beyond to the corporate desktop and the server space. It is the most consistent, polished Linux desktop available, it has major support by developers and companies who partner with Red Hat, Inc. and its server side is also strong compared to other Linux solutions today« (Quelle: www.osnews.com/story.php?news_id=2881; Zugriff: 22-Feb-2003).

Diskussion

Siehe Kefk Network GNU/Linux Wiki:

• www.kefk.net/Linux/Wiki/ow.asp?ReviewRedHatLinux.

Netmarks

[shrike-list]: "Release Notes", von Bill Nottingham, Mon, 31 Mar 2003 10:47:37 -0500,
listman.redhat.com/pipermail/shrike-list/2003-March/000009.html.

Weitere Reviews: siehe

• Netmarks zu Red Hat Linux 9.0 »Shrike« und 8.0.x »Phoebe«

Anmerkungen

Forum: (Anmerkungen in diesem Forum: )

Neue Anmerkung verfassen

Darstellungsmodus : Alle | Voransicht | Nur Titel | Aktualisieren

Besuchen Sie 2eNetWorX und Open Source & Free Software für weitere freie Software-Projekte unter Win32.

[ Zurück ] [ Weiter ]

	URL: http://www.kefk.net/Linux/Distributionen/Allgemein/Red-Hat/Versionen/9/Review/index.asp.
	Translate this page to  English French  Service provided by Google.
	Website: About | Index | Inhalt | Site Map | Suchen | Wer ist online? | What's new?. Thematisch verwandte Subsites: Apple | BSD | Open Source | Project »Tark« | Software | UNIX | Windows | Wissen. Mirrors: Connected | DAHB | Debian-Howto | Jargon File | Linuxfibel | Linux-Buch | RUTE | SelfLinux | TeX.
	Ergänzungen, Kommentare und Fragen: Kontakt | Foren | Wiki. E-Mail: echo "asb at keNOSPAMfk.net"| sed -e "s/ at /@/" -e "s/NOSPAM//". Registered Linux user: #34377 <http://counter.li.org>.
	Copyright | Credits | Disclaimer | Impressum | Rechtliche Hinweise | Wayback Machine.