Ich habe mit Redhat 6 angefangen. Später mal ein paar Jahre Debian. Mittlerweile nehme ich für fast alles Scientific Linux (RHEL 5 Clone). Die Kisten laufen tadellos, absolut stressfrei und das kann noch Jahre lang so weiterlaufen.
Gebe Dir absolut recht SE-Linux ist wirklich verdammt gut wie auch das original RHEL. Für Kunden nehmen ich jedoch ausschliesslich RHEL (Supportbedingt) Für Server die so oder so oft gewartet werden müssen jedoch Debian, teilweise auch nur Debian (je nach gusto) Aber schon die Wahl zu haben zwischen zwei so ausgereiften Distributionen wählen zu können ist Paradisisch
Die Aussage kann ich (persönlich) absolut nicht stehen lassen. Für Desktop-Einsatz auf nur halbwegs moderner Hardware ist RHEL5 verstaubter Müll (2.6.18 - zig Probleme, Packageversorgung null Material für nix sobald es nur ein kleines bisschen esoterischer wird, Druckersupport in jeder Hinsicht für die Tonne).
Die Grundaussage _MUSS_ also mit einem "auf Servern" versehen werden, um stehengelassen zu werden.
Gottseidank scheint RHEL6 ein kräftiges Update (zumindest kernelseitig, auf 2.6.3x) zu machen, da haben sie wohl aus der eindeutig zu verstaubten Version gelernt.
Die Subscriptions haben wir erneuert, wir geben RHEL da nochmal eine Chance: RedHat ist eben die mit Abstand beste Adresse, um Kernel-Entwicklung finanziell zu fördern.
Ähm RHEL impliziert in der Regel Serversysteme weil es genau da ein Kriterium sein kann dass die Kisten über Wochen und Monate ohne sie anzufassen laufen und ihr Verhalten nach Möglichkeit niemals ändern.
Es ist etwas völlig anderes ob dich auf einem Desktop eine Änderung ankotzt nach einem Update der Software oder auf einem Server der ein paar hundert Domains hostet.
Muss sowieso jeder für sich eintscheiden, ich persönlich setzte seit Jahren Fedora für Desktop und Server ein weil ich eben auch auf Servern aktuelle Softwarepakete brauche und/oder haben will und der Aufwand wenn man eine brauchbare Infrastruktur aufzieht auch überschaubar bleibt.
Auf einem Virtualisierungs-Host landet aber in jedem Fall RHEL wenn VMware-ESXi aus Sicherheitsgründen kein Thema ist (Nö ich mag den Hypervisor nicht auf einer Public-IÜ haben) weil mir das OS darunter in dem Zusammenhang Scheißegal ist, das muss nur stabil laufen und VMware ausführen, Systemmails schicken können und SSH zur Verfügung stellen, aus das war es auch schon
Das ist übrigens eine vertrottelte Aussage weil das alles andere als ein "normaler" 2.6.18-Kernel ist und es verdammt nochmal bei RHEL nicht sein DARF dass sich die Kernel-Version ändert weil die Modul-Schnittstellen über den ganzen Zeitraum binärkompatibel bleiben weswegen du zB niemals VMware-Module ompilieren musst bevor die Software läuft.
Genau deswegen setzt man RHEL ein und wenn jemand dann von "verstaubter Müll" spricht ist das nicht die Schuld vn RHEL sondern von einem Anwender der zu dumm ist seine Anforderungen zu definieren und die richtige Distri auszuwählen
2.6.18 ist so alt, dass der SATA-Support ziemlich unbrauchbar ist. Resultat ist ein schneckenlahmes 5MB/s dank schlechter SATA-Emulation per Legacy-PATA. Und das auf mittelalten Kisten. Dass RedHat natürlich eine gewisse (von manchen Leuten evt. als zu hoch empfundene da nicht ausreichend Mainline-konform) Menge Custom-Patching im Kernel drin hat, das löst die Sache nicht grundlegend.
Und wenn man das Problem dann abstellen will, dann stellt man fest, dass ein neuerer Custom-Kernel _GAR NICHT_ ohne extremste Klimmzüge geht (nash-root-device-Problem, sehr bekannter Bug).
Der 2.6.18er war zu Release (März 2007) schon ein halbes Jahr alt (Sept. 2006). Das ist einfach zu alt, wenn man sich bewusst ist, den gleichen Kernel über den gesamten Zeitraum der neuen Version halten zu müssen (Kernelmodule etc.). Dann sollte man eben bei Release schmerzhaft nah an die aktuelle Version herangehen (<= 2, 3 Monate Abstand), sonst hat man nämlich _später_ wesentlich mehr Probleme. Also ungefähr das, was Ubuntu so macht.
Fazit: Entweder ein halbwegs aktueller Kernel (also 2.6.2[34567]) als _Basis_ der jeweiligen Serie, oder wenigstens problemloser Eigenbau, falls man sich in der misslichen Lage wiederfinden sollte, das zu benötigen, oder - als letzter Anker - ein halbwegs aktueller vorgefertigter Ersatzkernel (und dann eben _kein_ 2.6.22). Da alles nicht der Fall war: Panne.
Im Übrigen war mein Posting (und dementsprechend auch zum Teil dessen Inhalt) primär als _Antwort_ auf die sehr verallgemeinernde Aussage "bei weitem die beste Linuxdistrie" gemünzt, was für Desktops eben emphatisch NICHT gilt und somit insgesamt die allgemeine Bewertung schlechter sein muss. Mein Reply war somit absolut nicht serverbezogen.
Kein Thema, auf Servern oder in der VM hat RHEL seinen Haupteinsatzbereich (und da wird entsprechende ABI-Kompatibilität auch verlangt), aber nach den wirklich vielfältigen Fehlschlägen lokal (also schwache Distri-Infrastruktur??) fürchte ich persönlich um jeden nur leicht esoterischen Einsatzzweck. Bei Debian gibt's zu den reinen Knochen noch ein ganzes Stück mehr Fleisch dazu, IMHO. Naja, mit RHEL6 wird das dann besser.
> 2.6.18 ist so alt, dass der SATA-Support ziemlich unbrauchbar ist. > Resultat ist ein schneckenlahmes 5MB/s dank schlechter SATA-Emulation per Legacy-PATA. > Und das auf mittelalten Kisten.
Was setzt du bitte für eine Scheiss-Hardware ein?
[:/var/cache]$ dd if=/dev/zero of=bench.bin 469585+0 Datensätze ein 469585+0 Datensätze aus 240427520 Bytes (240 MB) kopiert, 8,01609 Sekunden, 30,0 MB/s
[:/var/cache]$ uname -a 2.6.18-164.15.1.el5 #1 SMP Wed Mar 17 11:30:06 EDT 2010 x86_64 x86_64 x86_64 GNU/Linux
Und ja das ist eine Kiste mit SATA-Platten, die mickrigen 30 MB/Sek. kommen übrigens vom hier verwendeten Deadline-Scheduler welcher auf einem VMware-Host die bessere Wahl ist
> Dass RedHat natürlich eine gewisse (von manchen Leuten evt. als zu hoch empfundene da nicht > ausreichend Mainline-konform) Menge Custom-Patching im Kernel drin hat, das löst die Sache > nicht grundlegend.
Doch tut sie verdammt nochmal Wenn RHEL für deine Hardware und deine Anforderungen nicht passt liegt das immer noch nicht an RHEL sondern an einem blöden Admin der zwar weiss dass es das falsche ist aber es trotzdem einsetzt
> Und wenn man das Problem dann abstellen will, dann stellt man fest, > dass ein neuerer Custom-Kernel _GAR NICHT_ ohne extremste Klimmzüge geht > (nash-root-device-Problem, sehr bekannter Bug).
Wer dass auf einem RHEL macht und damit sein Geld verdient gehört erschossen RHEL verwendet man dort wo Zertifizierungen für darauf laufende Software notwendig sind und die kann man sich in den Arsch schieben wenn manchenanfängt selbst den Kernel zu backen
> Der 2.6.18er war zu Release (März 2007) schon ein halbes Jahr alt (Sept. 2006). > Das ist einfach zu alt
Ach informier dich doch mal ein wenig bevor du dich hier so lächerlich machst
2.6.18 war ein LTS-Kernel genauso wie 2.6.27 und 2.6.32 Und genau einen aus dieser Linie verwendet man für eine Enterprise-Distri um nicht schon vor dem Final-Release sämtlihe Backports pflegen zu müssen weil es von dieser Linie keinerlei Upstream-Support mehr gibt
Mach dich mal schlau wie lange XEN einen 2.6.18 vorausgesetzt hat Schau dich mal um: JEDE LTS-Distri hat zu der Zeit 2.6.18 verwendet
Aber wenn du alles besser weisst warum bringst du nicht selbst eine LTS-Distri raus die dann weltweit eingesetzt wird und alles besser macht?
> Im Übrigen war mein Posting (und dementsprechend auch zum Teil dessen Inhalt) > primär als _Antwort_ auf die sehr verallgemeinernde Aussage "bei weitem die beste Linuxdistrie" > gemünzt
Nochmal: Der OP ist davon ausgegangen dass es nichts neues ist dass RHEL primär ein Server-OS ist
> was für Desktops eben emphatisch NICHT gilt
Muss man das bei einer Server-Distri extra anführen?
> Kein Thema, auf Servern oder in der VM hat RHEL seinen Haupteinsatzbereich
Eben, also warum dann der Aufstand? Kein Mensch sieht RHEL als Desktop-Distri
> aber nach den wirklich vielfältigen Fehlschlägen lokal (also schwache Distri-Infrastruktur??) > fürchte ich persönlich um jeden nur leicht esoterischen Einsatzzweck.
Mein Gott RHEL will doch gar nicht für jeden Einsatzzweck perfekt geeignet sein
> Bei Debian gibt's zu den reinen Knochen noch ein ganzes Stück mehr Fleisch dazu
Dafür ist es ansonsten oftmals unbrauchbar weil die Pfeifen bei Debian meinen auch alles backporten zu müssen aber oftmals nichts davon verstehen und im Gegensatz dazu die Redhat-Entwickler Upstream arbeiten
Das hochgelobte Paketmanagment von Debian ist beschissen bis zum geht nicht mehr weil es kein sauberes Multilib-System unterstützt wo auf RHEL ein "yum install bla.i386 bla.x86_64" überhaupt kein Problem ist und auch sonst hat apt im Vergleich zu YUM wenn man mit letzterem umgehen kann nur Nachteile, vom beschissenen bauen von Paketen ganz zu sprechen wo unter Redhat-Systemen EIN SPEC-File, das Source-Archiv und optionale Patchfiles alles regeln
> Naja, mit RHEL6 wird das dann besser.
Für Luete wie dich nicht weil du müsstest jetzt schon bitterlich zu weinen beginnen dass sie auf einem veralteten 2.6.32-Kernel aufsetzen.
Die Luete die das entscheiden haben aber mehr Ahnung von der materie als du jemals haben wirst weil ein nicht unwesentlicher Teil der Kernel-Arbeit wie auch des GCC und der glibc von Redhat kommen sowie auch nicht wenige Apache-Security-Fixes in den letzten Jahren von RHEL/Fedora-Maintainern beigesteuert wurden.
Dagegen sehen die meisten anderen Distris verdammt alt aus und gerade beim totpatchen ist Debian Weltmeister (openssl, suhosin....)
Da oben gab es eine _allgemeine_ Aussage. Und die konnte ich so definitiv NICHT stehenlassen nach meinen zigfachen Erfahrungen. Und um nix anderes ging es mir.
> kommen übrigens vom hier verwendeten Deadline-Scheduler welcher > auf einem VMware-Host die bessere Wahl ist
Sicher nicht nur dort, wenn man sich so anschaut, wie komplex CFQ ist und somit häufig noch "etwas danebenliegt" (wird aber besser). Deadline war wohl traditionell in vielen Fällen tauglicher.
> Was setzt du bitte für eine Scheiss-Hardware ein?
Nix zertifiziertes, nix wirklich gutes (HP-Desktop-Schrott), aber es sollte mit einer überlegenen Distribution trotzdem annehmbar laufen (zumal es alles Intel-Stangenware ist). Was es in jeder Hinsicht nicht tut, da SÄMTLICHE Fallbacks in diesem Fall nicht verfügbar waren (und das war ja längst nicht das einzige lächerlich schwer lösbare Problem, was ich mit RHEL hatte, sonst hätte ich das nicht so geschrieben).
Nochmal zum Mitschreiben: RHEL ist eine Server-Distribution und ganz nebenbei ist das mit den 30 MB/Sek. oben ein abolsut billiger, selbst zusammengestekcter Server in der 1.000,- Preisklasse mit derzeit 155 Tagen Uptime als VMware-Host
Weiss Gott was du für Probleme mit RHEL hast, wir haben keine, auch nicht auf einer internen Gurke (Shuttle Box) die früher mal Telefonanlage war und jetzt plötzlich ein RHEL verpasst bekommen hat um selbige mittlerweile virtualisierte als Backup zu fahren.
So und jetzt sag mir mal warum du überall Probleme hast und ich bis jetzt jedes Linux auf jeder Hardware installiert habe die gerade da war und alles läuft...
"RHEL ist eine Server-Distribution" -- auf das Wort "Server-Distribution" wird dann also plötzlich jedesmal verwiesen, wenn man das mal auf "anderer", "nicht konformer" Hardware verwendet hat und feststellen musste, dass von den üblicherweise 3 verschiedenen _grundlegenden_ Software-Problemlösungsmöglichkeiten (die, die auf "guten" Distributionen vorhanden sind) exakt NULL funktionieren.
"selbst zusammengestekcter" -- genau das ist der Punkt, damit ist man IMHO häufig vermutlich Faktor 3 so zuverlässig wie der absolut unterirdisch grottige, totoptimierte Mainstream-Kistenschieber-Mist. Würde ich zumindest so formulieren, nach dem, was mir da so untergekommen ist
"So und jetzt sag mir mal warum du überall Probleme hast und ich bis jetzt jedes Linux auf jeder Hardware installiert habe die gerade da war und alles läuft..." Soll ich da jetzt ein "dann hat man wohl nicht ausreichend Feld-Erfahrung" hinterherschmeißen? ;) Ich hatte hier neulich auch wieder so ein Schlüsselerlebnis, wo von 4 Live-CDs (Knoppix, GRML, Ubuntu, ...) exakt eine vollständig gebootet hat, mit 3 verschiedenen Problemen bei den anderen (und nein, da war nicht nur eine etwas komische Hardware schuld - z.B. musste man bei kartenspezifischem Framebuffer-Treiber eine Auflösungs-Option manuell anders konfigurieren, damit man was entziffern konnte -, da war eindeutiger Bockmist dabei wie ein hängenbleibendes gpm-Init usw.).
Zentrale Aussage: man kann vollständig Glück haben (heute der Normalfall), aber dann gibt es wieder so Fälle wo ein Notebook bei 3 verschiedenen Hardware-Kategorien (WLAN, Audio, Grafik) völlig versagt und sich jeder fragt "wie kann das sein" - aber es ist ein legitimer Fall!! (der natürlich auch bei z.B. Windows 7 häufiger vorkommt, das nur nebenbei) Wie gesagt, man könnte das eigentlich höchstens unter Feld-Erfahrung abhaken. Oder man ist eben mit ausreichend homogener/bekannter/supporteter Hardware in seinem Umfeld gesegnet, dann sind die Arbeitstage wohl eher langweilig. Glückspilz
Kindchen ich lass mir die Hardware auch kundenspezifisch zusammenstellen mit Angaben wie "das in der Version muss drauf laufen", "die Leistung muss garantiert sein" etc. womit wenn dem nicht so ist der Dienstleister eine übergebraten bekommt und mit der nächsten Kiste zur Tür rein kommen darf.
Oder man kauft einfach Markenware wie HP und merkt irgendwann warum das Zeug teurer als viele Alternativen ist - Es läuft einfach, egal ob ich da ein aktuelles Fedora oder ein RHEL drauf installiere.
Und in Serverumgebungen wo man für 2 Hosts und einem SAN mit dazugehörigem Kleinzeug schon mal deutlich > 20.000 hinlegt kauft man erst recht Hardware für die jemand garantiert dass sie tut was sie soll.
Alles andere ist Kinderspielzeug und NICHT Ziel einer Enterprise-Distri
Wie der Poster vor mir meinte - du solltest dringend Deine Anforderungen überprüfen. RHEL ist nicht für Spielereien gedacht, sondern ein Enterprise-Produkt, das vor allem durch garantierte Binärkompatibilität besticht. Die von dir genannte Probleme sind gerade die Stärken. Außer der Unsinn mit Problemen im Kernel und dem Drucker.
Hi
Ich habe mit Redhat 6 angefangen. Später mal ein paar Jahre Debian. Mittlerweile nehme ich für fast alles Scientific Linux (RHEL 5 Clone). Die Kisten laufen tadellos, absolut stressfrei und das kann noch Jahre lang so weiterlaufen.
Gebe Dir absolut recht SE-Linux ist wirklich verdammt gut wie auch das original RHEL.
Für Kunden nehmen ich jedoch ausschliesslich RHEL (Supportbedingt)
Für Server die so oder so oft gewartet werden müssen jedoch Debian, teilweise auch nur Debian (je nach gusto)
Aber schon die Wahl zu haben zwischen zwei so ausgereiften Distributionen wählen zu können ist Paradisisch
Sry nicht SE.....tztz ich meinte natürlich SL...sorry
Ich freue mich schon auf CentOS / SL 6
Kommt darauf an, welche Version von Gnome wird denn ausgeliefert? 2.30 und ich mache Luftsprünge!
Wohl nur Gnome 2.28:
http://www.phoronix.com/scan.php?page=article&item=rhel6_benchmarks_beta&num=1
Schade, dann wird es wieder nichts mit CentOS für mich, noch länger möchte ich mir Evolution mit Bonobo nicht antun.
Danke für den Hinweis!
Die Aussage kann ich (persönlich) absolut nicht stehen lassen.
Für Desktop-Einsatz auf nur halbwegs moderner Hardware ist RHEL5 verstaubter Müll (2.6.18 - zig Probleme, Packageversorgung null Material für nix sobald es nur ein kleines bisschen esoterischer wird, Druckersupport in jeder Hinsicht für die Tonne).
Die Grundaussage _MUSS_ also mit einem "auf Servern" versehen werden, um stehengelassen zu werden.
Gottseidank scheint RHEL6 ein kräftiges Update (zumindest kernelseitig, auf 2.6.3x) zu machen,
da haben sie wohl aus der eindeutig zu verstaubten Version gelernt.
Die Subscriptions haben wir erneuert, wir geben RHEL da nochmal eine Chance: RedHat ist eben die mit Abstand beste Adresse, um Kernel-Entwicklung finanziell zu fördern.
Ähm RHEL impliziert in der Regel Serversysteme weil es genau da ein Kriterium sein kann dass die Kisten über Wochen und Monate ohne sie anzufassen laufen und ihr Verhalten nach Möglichkeit niemals ändern.
Es ist etwas völlig anderes ob dich auf einem Desktop eine Änderung ankotzt nach einem Update der Software oder auf einem Server der ein paar hundert Domains hostet.
Muss sowieso jeder für sich eintscheiden, ich persönlich setzte seit Jahren Fedora für Desktop und Server ein weil ich eben auch auf Servern aktuelle Softwarepakete brauche und/oder haben will und der Aufwand wenn man eine brauchbare Infrastruktur aufzieht auch überschaubar bleibt.
Auf einem Virtualisierungs-Host landet aber in jedem Fall RHEL wenn VMware-ESXi aus Sicherheitsgründen kein Thema ist (Nö ich mag den Hypervisor nicht auf einer Public-IÜ haben) weil mir das OS darunter in dem Zusammenhang Scheißegal ist, das muss nur stabil laufen und VMware ausführen, Systemmails schicken können und SSH zur Verfügung stellen, aus das war es auch schon
> verstaubter Müll (2.6.18)
Das ist übrigens eine vertrottelte Aussage weil das alles andere als ein "normaler" 2.6.18-Kernel ist und es verdammt nochmal bei RHEL nicht sein DARF dass sich die Kernel-Version ändert weil die Modul-Schnittstellen über den ganzen Zeitraum binärkompatibel bleiben weswegen du zB niemals VMware-Module ompilieren musst bevor die Software läuft.
Genau deswegen setzt man RHEL ein und wenn jemand dann von "verstaubter Müll" spricht ist das nicht die Schuld vn RHEL sondern von einem Anwender der zu dumm ist seine Anforderungen zu definieren und die richtige Distri auszuwählen
Doppeldaumen hoch!!!
Genau auf den Reply hab ich gewartet.
Das "verstaubter Müll" war sehr ernst gemeint.
2.6.18 ist so alt, dass der SATA-Support ziemlich unbrauchbar ist.
Resultat ist ein schneckenlahmes 5MB/s dank schlechter SATA-Emulation per Legacy-PATA.
Und das auf mittelalten Kisten.
Dass RedHat natürlich eine gewisse (von manchen Leuten evt. als zu hoch empfundene da nicht ausreichend Mainline-konform) Menge Custom-Patching im Kernel drin hat, das löst die Sache nicht grundlegend.
Und wenn man das Problem dann abstellen will, dann stellt man fest, dass ein neuerer Custom-Kernel _GAR NICHT_ ohne extremste Klimmzüge geht (nash-root-device-Problem, sehr bekannter Bug).
Der 2.6.18er war zu Release (März 2007) schon ein halbes Jahr alt (Sept. 2006).
Das ist einfach zu alt, wenn man sich bewusst ist, den gleichen Kernel über den gesamten Zeitraum der neuen Version halten zu müssen (Kernelmodule etc.). Dann sollte man eben bei Release schmerzhaft nah an die aktuelle Version herangehen (<= 2, 3 Monate Abstand), sonst hat man nämlich _später_ wesentlich mehr Probleme. Also ungefähr das, was Ubuntu so macht.
Fazit: Entweder ein halbwegs aktueller Kernel (also 2.6.2[34567]) als _Basis_ der jeweiligen Serie, oder wenigstens problemloser Eigenbau, falls man sich in der misslichen Lage wiederfinden sollte, das zu benötigen, oder - als letzter Anker - ein halbwegs aktueller vorgefertigter Ersatzkernel (und dann eben _kein_ 2.6.22). Da alles nicht der Fall war: Panne.
Im Übrigen war mein Posting (und dementsprechend auch zum Teil dessen Inhalt) primär als _Antwort_ auf die sehr verallgemeinernde Aussage "bei weitem die beste Linuxdistrie" gemünzt, was für Desktops eben emphatisch NICHT gilt und somit insgesamt die allgemeine Bewertung schlechter sein muss. Mein Reply war somit absolut nicht serverbezogen.
Kein Thema, auf Servern oder in der VM hat RHEL seinen Haupteinsatzbereich (und da wird entsprechende ABI-Kompatibilität auch verlangt), aber nach den wirklich vielfältigen Fehlschlägen lokal (also schwache Distri-Infrastruktur??) fürchte ich persönlich um jeden nur leicht esoterischen Einsatzzweck. Bei Debian gibt's zu den reinen Knochen noch ein ganzes Stück mehr Fleisch dazu, IMHO.
Naja, mit RHEL6 wird das dann besser.
> Das "verstaubter Müll" war sehr ernst gemeint.
Und ist völliger Schwachsinn
> 2.6.18 ist so alt, dass der SATA-Support ziemlich unbrauchbar ist.
> Resultat ist ein schneckenlahmes 5MB/s dank schlechter SATA-Emulation per Legacy-PATA.
> Und das auf mittelalten Kisten.
Was setzt du bitte für eine Scheiss-Hardware ein?
[:/var/cache]$ dd if=/dev/zero of=bench.bin
469585+0 Datensätze ein
469585+0 Datensätze aus
240427520 Bytes (240 MB) kopiert, 8,01609 Sekunden, 30,0 MB/s
[:/var/cache]$ uname -a
2.6.18-164.15.1.el5 #1 SMP Wed Mar 17 11:30:06 EDT 2010 x86_64 x86_64 x86_64 GNU/Linux
Und ja das ist eine Kiste mit SATA-Platten, die mickrigen 30 MB/Sek.
kommen übrigens vom hier verwendeten Deadline-Scheduler welcher
auf einem VMware-Host die bessere Wahl ist
> Dass RedHat natürlich eine gewisse (von manchen Leuten evt. als zu hoch empfundene da nicht
> ausreichend Mainline-konform) Menge Custom-Patching im Kernel drin hat, das löst die Sache
> nicht grundlegend.
Doch tut sie verdammt nochmal
Wenn RHEL für deine Hardware und deine Anforderungen nicht
passt liegt das immer noch nicht an RHEL sondern an einem blöden
Admin der zwar weiss dass es das falsche ist aber es trotzdem einsetzt
> Und wenn man das Problem dann abstellen will, dann stellt man fest,
> dass ein neuerer Custom-Kernel _GAR NICHT_ ohne extremste Klimmzüge geht
> (nash-root-device-Problem, sehr bekannter Bug).
Wer dass auf einem RHEL macht und damit sein Geld verdient gehört erschossen
RHEL verwendet man dort wo Zertifizierungen für darauf laufende Software
notwendig sind und die kann man sich in den Arsch schieben wenn manchenanfängt
selbst den Kernel zu backen
> Der 2.6.18er war zu Release (März 2007) schon ein halbes Jahr alt (Sept. 2006).
> Das ist einfach zu alt
Ach informier dich doch mal ein wenig bevor du dich hier so lächerlich machst
2.6.18 war ein LTS-Kernel genauso wie 2.6.27 und 2.6.32
Und genau einen aus dieser Linie verwendet man für eine Enterprise-Distri
um nicht schon vor dem Final-Release sämtlihe Backports pflegen zu müssen
weil es von dieser Linie keinerlei Upstream-Support mehr gibt
Mach dich mal schlau wie lange XEN einen 2.6.18 vorausgesetzt hat
Schau dich mal um: JEDE LTS-Distri hat zu der Zeit 2.6.18 verwendet
Aber wenn du alles besser weisst warum bringst du nicht selbst
eine LTS-Distri raus die dann weltweit eingesetzt wird und alles besser macht?
> Im Übrigen war mein Posting (und dementsprechend auch zum Teil dessen Inhalt)
> primär als _Antwort_ auf die sehr verallgemeinernde Aussage "bei weitem die beste Linuxdistrie"
> gemünzt
Nochmal: Der OP ist davon ausgegangen dass es nichts neues ist
dass RHEL primär ein Server-OS ist
> was für Desktops eben emphatisch NICHT gilt
Muss man das bei einer Server-Distri extra anführen?
> Kein Thema, auf Servern oder in der VM hat RHEL seinen Haupteinsatzbereich
Eben, also warum dann der Aufstand?
Kein Mensch sieht RHEL als Desktop-Distri
> aber nach den wirklich vielfältigen Fehlschlägen lokal (also schwache Distri-Infrastruktur??)
> fürchte ich persönlich um jeden nur leicht esoterischen Einsatzzweck.
Mein Gott RHEL will doch gar nicht für jeden Einsatzzweck perfekt geeignet sein
> Bei Debian gibt's zu den reinen Knochen noch ein ganzes Stück mehr Fleisch dazu
Dafür ist es ansonsten oftmals unbrauchbar weil die Pfeifen bei Debian
meinen auch alles backporten zu müssen aber oftmals nichts davon
verstehen und im Gegensatz dazu die Redhat-Entwickler Upstream arbeiten
Das hochgelobte Paketmanagment von Debian ist beschissen bis zum geht nicht
mehr weil es kein sauberes Multilib-System unterstützt wo auf RHEL
ein "yum install bla.i386 bla.x86_64" überhaupt kein Problem ist und
auch sonst hat apt im Vergleich zu YUM wenn man mit letzterem umgehen
kann nur Nachteile, vom beschissenen bauen von Paketen ganz zu sprechen
wo unter Redhat-Systemen EIN SPEC-File, das Source-Archiv und optionale
Patchfiles alles regeln
> Naja, mit RHEL6 wird das dann besser.
Für Luete wie dich nicht weil du müsstest jetzt schon bitterlich zu weinen
beginnen dass sie auf einem veralteten 2.6.32-Kernel aufsetzen.
Die Luete die das entscheiden haben aber mehr Ahnung von der materie als
du jemals haben wirst weil ein nicht unwesentlicher Teil der Kernel-Arbeit wie auch des GCC
und der glibc von Redhat kommen sowie auch nicht wenige Apache-Security-Fixes
in den letzten Jahren von RHEL/Fedora-Maintainern beigesteuert wurden.
Dagegen sehen die meisten anderen Distris verdammt alt aus und gerade
beim totpatchen ist Debian Weltmeister (openssl, suhosin....)
> Kein Mensch sieht RHEL als Desktop-Distri
Da oben gab es eine _allgemeine_ Aussage. Und die konnte ich so definitiv NICHT stehenlassen nach meinen zigfachen Erfahrungen. Und um nix anderes ging es mir.
> kommen übrigens vom hier verwendeten Deadline-Scheduler welcher
> auf einem VMware-Host die bessere Wahl ist
Sicher nicht nur dort, wenn man sich so anschaut, wie komplex CFQ ist und somit häufig noch "etwas danebenliegt" (wird aber besser). Deadline war wohl traditionell in vielen Fällen tauglicher.
> Was setzt du bitte für eine Scheiss-Hardware ein?
Nix zertifiziertes, nix wirklich gutes (HP-Desktop-Schrott), aber es sollte mit einer überlegenen Distribution trotzdem annehmbar laufen (zumal es alles Intel-Stangenware ist). Was es in jeder Hinsicht nicht tut, da SÄMTLICHE Fallbacks in diesem Fall nicht verfügbar waren (und das war ja längst nicht das einzige lächerlich schwer lösbare Problem, was ich mit RHEL hatte, sonst hätte ich das nicht so geschrieben).
>> Was setzt du bitte für eine
>> Scheiss-Hardware ein?
> Nix zertifiziertes, nix wirklich gutes
> (HP-Desktop-Schrott)
Nochmal zum Mitschreiben:
RHEL ist eine Server-Distribution und ganz nebenbei ist das mit den 30 MB/Sek. oben ein abolsut billiger, selbst zusammengestekcter Server in der 1.000,- Preisklasse mit derzeit 155 Tagen Uptime als VMware-Host
Weiss Gott was du für Probleme mit RHEL hast, wir haben keine, auch nicht auf einer internen Gurke (Shuttle Box) die früher mal Telefonanlage war und jetzt plötzlich ein RHEL verpasst bekommen hat um selbige mittlerweile virtualisierte als Backup zu fahren.
So und jetzt sag mir mal warum du überall Probleme hast und ich bis jetzt jedes Linux auf jeder Hardware installiert habe die gerade da war und alles läuft...
"RHEL ist eine Server-Distribution" -- auf das Wort "Server-Distribution" wird dann also plötzlich jedesmal verwiesen, wenn man das mal auf "anderer", "nicht konformer" Hardware verwendet hat und feststellen musste, dass von den üblicherweise 3 verschiedenen _grundlegenden_ Software-Problemlösungsmöglichkeiten (die, die auf "guten" Distributionen vorhanden sind) exakt NULL funktionieren.
"selbst zusammengestekcter" -- genau das ist der Punkt, damit ist man IMHO häufig vermutlich Faktor 3 so zuverlässig wie der absolut unterirdisch grottige, totoptimierte Mainstream-Kistenschieber-Mist. Würde ich zumindest so formulieren, nach dem, was mir da so untergekommen ist
"So und jetzt sag mir mal warum du überall Probleme hast und ich bis jetzt jedes Linux auf jeder Hardware installiert habe die gerade da war und alles läuft..."
Soll ich da jetzt ein "dann hat man wohl nicht ausreichend Feld-Erfahrung" hinterherschmeißen?
;)
Ich hatte hier neulich auch wieder so ein Schlüsselerlebnis, wo von 4 Live-CDs (Knoppix, GRML, Ubuntu, ...) exakt eine vollständig gebootet hat, mit 3 verschiedenen Problemen bei den anderen (und nein, da war nicht nur eine etwas komische Hardware schuld - z.B. musste man bei kartenspezifischem Framebuffer-Treiber eine Auflösungs-Option manuell anders konfigurieren, damit man was entziffern konnte -, da war eindeutiger Bockmist dabei wie ein hängenbleibendes gpm-Init usw.).
Zentrale Aussage: man kann vollständig Glück haben (heute der Normalfall), aber dann gibt es wieder so Fälle wo ein Notebook bei 3 verschiedenen Hardware-Kategorien (WLAN, Audio, Grafik) völlig versagt und sich jeder fragt "wie kann das sein" - aber es ist ein legitimer Fall!!
(der natürlich auch bei z.B. Windows 7 häufiger vorkommt, das nur nebenbei)
Wie gesagt, man könnte das eigentlich höchstens unter Feld-Erfahrung abhaken. Oder man ist eben mit ausreichend homogener/bekannter/supporteter Hardware in seinem Umfeld gesegnet, dann sind die Arbeitstage wohl eher langweilig. Glückspilz
Kindchen ich lass mir die Hardware auch kundenspezifisch zusammenstellen mit Angaben wie "das in der Version muss drauf laufen", "die Leistung muss garantiert sein" etc. womit wenn dem nicht so ist der Dienstleister eine übergebraten bekommt und mit der nächsten Kiste zur Tür rein kommen darf.
Oder man kauft einfach Markenware wie HP und merkt irgendwann warum das Zeug teurer als viele Alternativen ist - Es läuft einfach, egal ob ich da ein aktuelles Fedora oder ein RHEL drauf installiere.
Und in Serverumgebungen wo man für 2 Hosts und einem SAN mit dazugehörigem Kleinzeug schon mal deutlich > 20.000 hinlegt kauft man erst recht Hardware für die jemand garantiert dass sie tut was sie soll.
Alles andere ist Kinderspielzeug und NICHT Ziel einer Enterprise-Distri
Wie der Poster vor mir meinte - du solltest dringend Deine Anforderungen überprüfen. RHEL ist nicht für Spielereien gedacht, sondern ein Enterprise-Produkt, das vor allem durch garantierte Binärkompatibilität besticht. Die von dir genannte Probleme sind gerade die Stärken. Außer der Unsinn mit Problemen im Kernel und dem Drucker.