News Linux-Distribution für Profis: Red Hat Enterprise Linux 9 als Beta erschienen

Wölkchen schrieb:
...Red Hat würde nicht so viele Ressourcen in die Entwicklung von Desktop-Technologien stecken, wenn dem nicht so ist. ...
Genau das war auch mein Gedanke. Deswegen bin ich auch davon ausgegangen, dass wir hier über eine Desktop-Version reden und nicht von einer nackten Server-Installation.
 
Ich hab eine zeitlang CentOS verwendet und fand es vor allem wegen der RedHat Dokumentation einfach genial.
Sich nicht durch halbgare oder nicht aktuelle Dokus, die hoffentlich trotzdem funktionieren wühlen zu müssen war richtig angenehm.
Schade dass es so eingestampft wurde, aber naja gute Dokumentation ist halt anstrengende Arbeit, die die wenigsten gerne freiwillig machen und das kostet eben.
 
Salamimander schrieb:
So ein Quark.

RHEL wird primär eingekauft, um einen Schuldigen zu haben, wenn etwas schief geht. Und RHEL selbst sagt dann fast immer: Tja, können wir nix für, liegt am Paket XY. Der Support war, meiner Erfahrung nach, bisher noch nie wirklich hilfreich.
Kann ich definitiv nicht bestätigen.

Gerade beim Kerngebiet RHEL ist der Red Hat Support ziemlich gut. Red Hat hat in den meisten Bereichen eigene Entwickler die wissen wovon sie sprechen. Wir hatten einen seltenen XFS-Bug, der laufend Filesysteme zerschossen hat. Bei Google 0 Ergebnisse. Red Hat stellt den Großteil der XFS Entwickler und die haben den Bug schnell gefunden und einen Patch geliefert.

Bei anderen Red Hat Produkten lässt der Support seit der Übernahme durch IBM aber merklich nach.
 
Gut, klar, wenn man explizit auf XFS setzt und da in einen EDGE Case rennt, mag der support hilfreich sein, er ist es ja auch bei OpenShift. Nur ist das leider die Ausnahme, hast du ja selbst bemerkt :|. Unsere Lósung bei XFS: ext4 nutzten ... :D
 
Wanderer101 schrieb:
Genau das war auch mein Gedanke. Deswegen bin ich auch davon ausgegangen, dass wir hier über eine Desktop-Version reden und nicht von einer nackten Server-Installation.
Ein Terminal Server, auf den die Clients per Remote Desktop draufkommen, ist technisch auch ein Server.
 
Salamimander schrieb:
Gut, klar, wenn man explizit auf XFS setzt und da in einen EDGE Case rennt, mag der support hilfreich sein, er ist es ja auch bei OpenShift. Nur ist das leider die Ausnahme, hast du ja selbst bemerkt :|. Unsere Lósung bei XFS: ext4 nutzten ... :D
XFS ist Standard bei RHEL ... nix mit Edge-Cases. EXT4 hat nichts mehr im Enterprise-Umfeld zu suchen.

RHEL ist immer noch das Best-Selling-Product von Red Hat und dementsprechend auch der größte Batzen bei dem Support anfällt. Und dort sind sie Klasse.
 
Ich sagte nicht, das man unter RHEL ext4 nutzten sollte. Und das man ext4 nicht im Enterprise Umfeld nutzten sollte, ist wieder so ein Stammtisch Ding. Genau dieses rumgezicke basierend auf Glaube und Mythen ist der Grund, warum Windows es noch immer so leicht im Desktopbereich hat.
 
Wo soll das Problem mit ext4 sein? Auf den unter meiner Verwaltung stehenden knapp 70 Webservern läuft ext4.. Noch nie Probleme damit gehabt. Auf den galeraclustern gleiches Spiel.

Wieso muss bei Linux eigentlich immer alles in Glaubenskriege ausarten? Es kommt immer entscheidet auf den Einsatzzweck an.
Und btw. Nur weil die Amerikaner meinen (ja RHLE ist ein US Amerikanisches Produkt), das xfs das Maß aller Dinge ist, muss ich das nicht auch so sehen.
 
Muffknutscher schrieb:
Wieso muss bei Linux eigentlich immer alles in Glaubenskriege ausarten?
Wieso versuchst du es im gleichen Atemzug in einen abstrusen Kulturkampf mit Amerikanern umzumünzen?
 
@Garmor Lesen hilft? Nur weil ich es nicht so sehe wie ein Unternehmen ist das ein Kulturkampf? Und weil es zig andere distributionen auch nicht so sehen? Versuch doch einfach nicht was rein zu interpretieren wo es nichts gibt.
 
Salamimander schrieb:
Ich sagte nicht, das man unter RHEL ext4 nutzten sollte. Und das man ext4 nicht im Enterprise Umfeld nutzten sollte, ist wieder so ein Stammtisch Ding. Genau dieses rumgezicke basierend auf Glaube und Mythen ist der Grund, warum Windows es noch immer so leicht im Desktopbereich hat.
Das ist kein Glaube und Mythos, sondern ein Fakt. Journaling-Filesysteme sind nicht mehr state of the art.
 
Welches Linux FS ist denn kein Journaling -FS?
 
Muffknutscher schrieb:
Welches Linux FS ist denn kein Journaling -FS?
Du hast in der Hinsicht recht dass ich mich nicht ganz korrekt ausgedrückt habe.

Natürlich ist XFS auch ein Journaling-Filesystem. Aber zumindest ist dort das Journaling so implementiert, dass es vor allem bei schnellen IO-Devices besser performt als ext4. Auch im SAN-Bereich ist XFS deutlich performanter. Bei 0815 Konsumener-HDDs ist vermutlich ext4 etwas vorne, aber wir reden ja vom Enterprise-Bereich.

Aber um auf die ursprüngliche Frage zurückzukommen: transaktionale Filesysteme wie ZFS.

Es ist echt bedauerlich das ZFS in den Händen von Oracle liegt. Eine Integration in den Kernel-Upstream würde so viele Filesystem-Probleme obsolet machen....
 
Termy schrieb:
Nicht ganz richtig, es gibt auch RHEL Workstation.
Wieviel Verbreitung das in "freier Wildbahn" in den Firmen hat würde mich aber auf jeden Fall auch mal interessieren ^^
Bei meinem Ex-Arbeitgeber (Autoindustrie) hatten wir RHEL für die Simulationsworkstations. Crashsimulationen, FEM-Simulationen... all sowas haben wir damit gemacht.
 
  • Gefällt mir
Reaktionen: Termy
zatarc schrieb:
Du hast in der Hinsicht recht dass ich mich nicht ganz korrekt ausgedrückt habe.

Natürlich ist XFS auch ein Journaling-Filesystem. Aber zumindest ist dort das Journaling so implementiert, dass es vor allem bei schnellen IO-Devices besser performt als ext4. Auch im SAN-Bereich ist XFS deutlich performanter. Bei 0815 Konsumener-HDDs ist vermutlich ext4 etwas vorne, aber wir reden ja vom Enterprise-Bereich.

Aber um auf die ursprüngliche Frage zurückzukommen: transaktionale Filesysteme wie ZFS.

Es ist echt bedauerlich das ZFS in den Händen von Oracle liegt. Eine Integration in den Kernel-Upstream würde so viele Filesystem-Probleme obsolet machen....
Wir haben damals mit FusionIO und Postgres getestet. XFS brachte keinen Vorteil.

Aber zumindest mit ZFS sind wir uns einig, DAS ist die eigentliche Lösung. BTRFS ist leider tot :(
 
zatarc schrieb:
Es ist echt bedauerlich das ZFS in den Händen von Oracle liegt.
Ähm das ist allenfalls die halbe Wahrheit. Ja. Es gibt eine ZFS-Implementation von Oracle.
Aber das, was außerhalb von Solaris üblicherweise eingesetzt wird ist OpenZFS und das liegt eben nicht in den Händen von Oracle (beide ZFS-Implementierungen sind auch inzwischen inkompatibel zueinander).

Und das OpenZFS kein Teil von Linux ist liegt auch nicht an Oracle oder OpenZFS, sondern an den Linux-Taliban aus irgendwelchen obskuren Lizenzgründen (und gegen die Interessen der User!) die Aufnahme in den Linux-Kernel verweigern.

In der Praxis ist das aber meist nicht wirklich ein Problem, denn das OpenZFS-Projekt stellt regelmäßig Patches für neu erscheinende Linux-Kernel zu Verfügung. Sicher nicht am Tag 1 einer neuen Kernel-Version. Aber mal ehrlich? Wer von euch verwendet schon direkt den Kernel von kernel.org? Die meisten Leute nehmen den Kernel, den ihre Distribution mitliefert. Und zumindest bei die großen Distributionen ist die ZFS-Integration kein allzu großes Problem. Wer wirklich ZFS unter Linux einsetzen will und keine Ausreden sucht es nicht zu tun, der kann das auch machen.
 
andy_m4 schrieb:
Ähm das ist allenfalls die halbe Wahrheit. Ja. Es gibt eine ZFS-Implementation von Oracle.
Aber das, was außerhalb von Solaris üblicherweise eingesetzt wird ist OpenZFS und das liegt eben nicht in den Händen von Oracle (beide ZFS-Implementierungen sind auch inzwischen inkompatibel zueinander).
Wenn ich von ZFS (auf Linux) rede, dann meine ich natürlich auch OpenZFS. DAS ZFS gibt es natürlich nicht für Linux.
andy_m4 schrieb:
Und das OpenZFS kein Teil von Linux ist liegt auch nicht an Oracle oder OpenZFS, sondern an den Linux-Taliban aus irgendwelchen obskuren Lizenzgründen (und gegen die Interessen der User!) die Aufnahme in den Linux-Kernel verweigern.
Das ist die wahre Halbwahrheit ;).
OpenZFS verwendet die CDDL Lizenz. Diese ist nun mal nicht mit GPLv2 kompatibel. Die Bedenken der Kernel-/Linux-Community sind absolut nachvollziehbar, vor allem wenn man Oracle damit einen Hebel gibt alles lahmzulegen. Niemand vertraut Oracle.
Für eine Integration in den Upstream-Kernel müsste Oracle aktiv werden und Teile des Codes, der noch aus Sun-Zeiten stammt, relizenzieren. Tun sie halt nicht.
andy_m4 schrieb:
In der Praxis ist das aber meist nicht wirklich ein Problem, denn das OpenZFS-Projekt stellt regelmäßig Patches für neu erscheinende Linux-Kernel zu Verfügung. Sicher nicht am Tag 1 einer neuen Kernel-Version. Aber mal ehrlich? Wer von euch verwendet schon direkt den Kernel von kernel.org? Die meisten Leute nehmen den Kernel, den ihre Distribution mitliefert. Und zumindest bei die großen Distributionen ist die ZFS-Integration kein allzu großes Problem. Wer wirklich ZFS unter Linux einsetzen will und keine Ausreden sucht es nicht zu tun, der kann das auch machen.
Natürlich ist das ein Problem in der Praxis. Eine Integration in den Upstream-Kernel ist ein must-have, wenn man ZFS wirklich überall haben will. Außer Ubuntu traut sich keiner Distribution ZFS fest zu intergrieren. Bei allen anderen Distributionen muss man nach jedem Kernel-Update das ZFS-Modul rekompilieren und hoffen, dass noch alles funktioniert. Das ist kein Enterprise-tauglicher Ansatz.

Auch im Konsumer-Bereich macht das kein Spaß. Der Kernel von Fedora ist zum Beispiel meist zu neu für OpenZFS. Man muss dann immer warten bis das OpenZFS-Projekt nachzieht und den neusten Kernel unterstützt.

Mit einer Upstream-Integration gäbe es diese Probleme nicht und jede Distribution hätte von Haus aus ZFS-Support
 
  • Gefällt mir
Reaktionen: up.whatever
zatarc schrieb:
Wenn ich von ZFS (auf Linux) rede, dann meine ich natürlich auch OpenZFS. DAS ZFS gibt es natürlich nicht für Linux.

Das ist die wahre Halbwahrheit ;).
OpenZFS verwendet die CDDL Lizenz. Diese ist nun mal nicht mit GPLv2 kompatibel. Die Bedenken der Kernel-/Linux-Community sind absolut nachvollziehbar, vor allem wenn man Oracle damit einen Hebel gibt alles lahmzulegen. Niemand vertraut Oracle.
Für eine Integration in den Upstream-Kernel müsste Oracle aktiv werden und Teile des Codes, der noch aus Sun-Zeiten stammt, relizenzieren. Tun sie halt nicht.

Natürlich ist das ein Problem in der Praxis. Eine Integration in den Upstream-Kernel ist ein must-have, wenn man ZFS wirklich überall haben will. Außer Ubuntu traut sich keiner Distribution ZFS fest zu intergrieren. Bei allen anderen Distributionen muss man nach jedem Kernel-Update das ZFS-Modul rekompilieren und hoffen, dass noch alles funktioniert. Das ist kein Enterprise-tauglicher Ansatz.

Auch im Konsumer-Bereich macht das kein Spaß. Der Kernel von Fedora ist zum Beispiel meist zu neu für OpenZFS. Man muss dann immer warten bis das OpenZFS-Projekt nachzieht und den neusten Kernel unterstützt.

Mit einer Upstream-Integration gäbe es diese Probleme nicht und jede Distribution hätte von Haus aus ZFS-Support
Debian läuft ganz wunderbar mit ZFS, siehe Proxmox. Aber da wirst du sicherlich wieder schreien das sei ja nicht Enterprise, weil es KEIN Vermögen ohne realen Mehrwert kostet 🤷🏻‍♂️
 
Salamimander schrieb:
Debian läuft ganz wunderbar mit ZFS, siehe Proxmox. Aber da wirst du sicherlich wieder schreien das sei ja nicht Enterprise, weil es KEIN Vermögen ohne realen Mehrwert kostet 🤷🏻‍♂️
Ja und? ZFS und Fedora funktionieren auch ... wenn OpenZFS denn den Kernel schon unterstützt. Als Fedora 34 raus kam, musste man knapp 3 Monaten warten bis es eine stabile OpenZFS-Version gab, die den 5.12er Kernel supportet hat. Wenn du Lust hast deine Daten einer beta/rc-Version von OpenZFS anzuvertrauen, dann tu das. Meine Vorstellung von "funktioniert wunderbar" ist = ich muss mich nicht nach jedem Kernel-Update drum kümmern, dass das ZFS-Modul noch funktioniert.

Dazu kommt der ganze Versions-Hickhack. Jede Distribution liefert eine andere Version, die wider rum mit einer anderen Kernel-Version zusammenspielen muss. (Debian z.B. "nur" 2.0.3 statt 2.1.X)

Und ja, Debian ist per Definition keine Enterprise-Distribution. Vielleicht solltest du mal Google fragen was Enterprise-Distributionen sind.
 
Du solltest deine arg überhebliche Art überdenken und schauen wo die Diskussion gestartet ist. Es spielt bei der Enterprise Tauglichkeit im Übrigen erstmal keine Rolle, ob sich eine Distro als solche ausgibt, sondern es spielt Primär der Bedarf des Unternehmens eine Rolle. Ich bin mir bei dir allerdings 100% sicher, dass du von echter Bedarfsanalyse, die über ein einzelnes Projekt hinaus geht, wenig bis keine Erfahrung hast. Per „Definition“, die du da als Allgemeingültig ansiehst (was sie nicht ist), arbeiten also Amazon, Google und Co offenbar komplett Enterprise Unfähig. Viele Punkte, die du hier nicht mal bennenen kannst, sondern ab und an nur anschneidest (werde doch mal endlich konkret!), spielen im Enterprise Umfeld kaum noch, oder durch Legacy Gründen eine Rolle. Es kann dir schlicht egal sein! Nehmen wir doch mal Kubernetes:
Beim aufsetzten des Clusters brauchst du ein stabiles Grundsystem mit Docker, Container.IO oder was auch immer noch von K8s Supported wird. Dieses Grundsystem wird soweit gehärtet, dass SSH für den Betrieb nur im absoluten Notfall eine Rolle spielt. FS? Quasy egal. Kommt eh ins Overlay. Kernel? K8s Requirements anschauen. Am Ende wieder quasy egal. Support? Wird dir bei K8s nicht helfen. OpenShift anstatt native K8s? Kann man machen, man spart einmalig Zeit, das war es aber auch schon. Aber klar, wenn man Angst um seinen Job als grummeliger 90er Jahre Admin hat, spricht man aktuellen Technologien einfach die Tauglichkeit ab. Ist ja einfacher als sich damit auseinander zu setzten 🙄
 
Zurück
Oben