News Red Hat: Enterprise Linux schließt seine Quellen für Dritte

[rarp]

@Kaito Kariheddo stimmt das? Wirst du in Wurstsemmel bezahlt?

Erst ab 100 Kommentaren, hab ich gehört. Darunter gibt's Trockenbrot.

 

[LochinSocke]

Für das erfolgreiche Diablo 4 Windows vs Linux Benchmark Teil vor einigen Wochen, gab es sogar Ketchup auf die Semmel.

 

[flaphoschi]

Was halt ohne Subscription nicht geht, sind die Updates und die Einbindung von Spezialrepos.

Keine Updates. Keine Spezialrepos?

Dein Argument ist damit keins.

Das sind zwei Argumente?

Testen muss leicht und unkompliziert sein. Je mehr man sich abkapselt und künstliche Restriktionen aufbaut, um so schwerer wird Unterstützung. Keine Accounts, keine Registrierung, direkt zugängliche Images mit Updates und Quellen zum nachlesen und anpassen und testen. Da wird man sich jetzt mehr auf Fedora konzentrieren dürfen.

 

[M-X]

Installiert euch mal keine Kindergarten Distribution wie Ubuntu, Mint, OpenSuse.

Wow was für ein pseudoelitäres Geschwafel . Linux hat sich als Bezeichnung einfach durchgesetzt.

 

[Kaito Kariheddo]

Da hier im Verlauf mehrere Thesen in den Raum geworfen wurden und am Ende sowieso jeder seine eigene Ansicht darüber hat, will ich einmal und endgültig festhalten wie es sich verhält und jegliche Unklarheit beseitigen: Ich werde in Karotten bezahlt und wenns gut lief noch ne Schoki oben drauf !

 

[Brand10]

Ganz einfach. Durch zufriedene Kunden!
Und diese Kunden sind eben nicht irgendwer.
Aber du weißt es sicher besser.

Wir sind Enterprise Kunde mit über 5000 Mitarbeitern und ich arbeite seit über 15 Jahren mit SLES und RHEL. Ich weiß absolut wovon ich spreche! Leider sind wir zu groß, als das ich alleine daran etwas ändern könnte, aber ich gebe mein bestes! Die Support Verträge sind keinen Cent Wert, ebenso deren Security Versprechen.

Davon abgesehen hat das nichts mit Kundenzufriedenheit zu tun. Genauso wie SLES war RHEL einfach nur das erste für Firmen konzipierte Linux mit Support-Verträgen und festen Releases! Sie hatten nicht dieses Frickel-Image anderer Distributionen. Das ist der einzige Grund warum es überhaupt gekauft wurde. Heute ist RHEL selbst ein einziges Gefrickel. Deren Knowledge Base zu z.B. RHEL 8 ist teilweise schlichtweg falsch und passt nicht zum System. Einfaches Beispiel: nameserver restart!
Weiterer Kritikpunkt von mir: Die Knowledge Base ist gar nicht öffentlich einsehbar. Nur mit Support-Login.

Systemd ist mittlerweile zum Standard geworden. Und das ist auch gut so. Ich hatte zu meiner Uni-Zeit für Scientific Linux mal Init.d-Startskripte schreiben müssen. Das war fürchterlich. Unter jeder Distribution anders, manche nutzten noch die SXX-/KXX-Notation für die Reihenfolge. Parallelisierung war gar nicht möglich.

Podman versucht die Sicherheitsprobleme von Docker zu lösen. Ansich ist der Ansatz richtig.

Und mit dem Support haben wir bisher relativ gute Erfahrungen. Wenn ich einen Bugreport bei Red Hat erstellt hatte, wurde der auch bearbeitet. Mit Suse waren die Erfahrungen auch nicht besser.

Was verleitet Dich also zu dieser Aussage?


Als Unternehmen oder Behörde willst für die Produkte, die du kaufst, Herstellersupport haben. Im Linux-Enterprise-Umfeld bieten das Red Hat, SuSE und Canonical an. Gerüchten zu Folge soll es aber bisher noch niemand geschafft haben, einen Ubuntu-Supportvertrag abzuschließen. SuSE ist 'ne eher kleine Bude, die sich auf Cluster und SAP-Support spezialisiert hat. Bleibt nur noch Red Hat übrig.

Für RHEL hast du festgelegte Support-Zyklen. Softwarehersteller von Drittsoftware müssen bei der Auslieferung an Unternehmen oder Behörden ebenfalls die Funktion ihrer Software auf Basis einer bestimmten Plattform garantieren. Also wird die Enterprise-Plattform verwendet, die die o.g. Support-Zyklen bietet. Und das ist nun mal Red Hat.

Woher kommt Deine Verachtung gegenüber Red Hat?

1.) systemd ist einfach nur eine Alternativ zum veralteten init.d. Der Ansatz ist aber katrastrophal, weil systemd komplett gegen zahlreiche Linux Philosphien verstößt! Anstatt einfach nur init.d zu ersetzen, enthält es mittlerweile DNS Server, DHCP Funktionen, etc.!

systemd-resolvd hat DNS Anfragen eine Zeit lang bei falscher Konfiguration (weiß nicht ob es heute immernoch so enthalten ist) hart-codiert an Google Nameserver weitergeleitet ohne das Du als Admin etwas davon mitbekommen hast! Die Begründung des Entwicklers: Sie wollten ein funktionierendes System sicherstellen... Lächerlich!

Canonical (Ubuntu) hatte mal "upstart" als Alternative zu init.d entwickelt. DAS war ein sauberes und innovatives System (Event getriggert), konnte sich aber gegen die Marktmacht von RedHat leider nicht durchsetzen!

2.) Der Ansatz von podman ist richtig. Die Umsetzung, wie fast alles bei RedHat aber schlecht! Da sind Bugs enthalten, die bei docker schon vor Jahren gelöst wurden. Man meldet Bugs bei RedHat, die Tickets bleiben locker 6 Monate offen und unbearbeitet. Bis vor kurzem hat nichtmal "restart: always" in podman-compose funktioniert! Die Services blieben nach dem Systemstart einfach down.

3.) Hersteller Support... Es gab zu Zeiten von RHEL7 eine vom BSI als kritisch gemeldete Sicherheitslücke, ahnliches Level wie log4shell. Hat RedHat nicht interessiert. Die haben die Lücke einfach runter gestuft und über ein halbes Jahr ignoriert. Das hatte zur Folge, dass unser Unternehmen RHEL7 kurzfristig lange vor Support Ende "gebanned" hat. Erst ein weiteres halbes Jahr später hat RedHat reagiert. Wahrscheinlich weil auch der Druck von anderen Unternehmen zugenommen hatte. Soviel zum völlig unnützen Support!

 

[Kuristina]

Sie wollten ein funktionierendes System sicherstellen

Find ich einen guten Ansatz. Ich bin gerade noch rechtzeitig von grub auf systemd umgestiegen, bevor ein grub Update vor paar Monaten ? bei vielen ein Desaster ausgelöst hat. Glück gehabt. ^^

 

[up.whatever]

Ich bin gerade noch rechtzeitig von grub auf systemd umgestiegen

Entweder meinst du systemd-boot statt systemd, oder du bringst gerade etwas gewaltig durcheinander.

 

[Kuristina]

Entweder meinst du systemd-boot

Wenn ich von grub gewechselt bin, wirds wohl systemd-boot sein. 🙂

 

[kim88]

Was spricht eigentlich gegen die Fedora Nutzung als Server?

Viel zu kurze Support Laufzeiten. ~13 Monate pro Version ist nichts was du auf einem Server haben willst. Es geht ja nicht nur um den Aufwand das Fedora zu aktualisieren (das ist der kleinste Teil). Aber wenn dann auch noch neue Programmversionen kommen musst du ja auch deine Anwendungen die auf dem server laufen an die neuen Versionen anpassen.

Da bist im Grunde nur noch permanent damit beschäftigt deine Software auf dem jeweilig aktuellen Fedora betriebsbereit zu halten. Statt die Software weiter zu entwickeln.

SLES-Repos gibt es auch nur gegen Cash oder Dev-Account.

Die Sourcen können aber auch dritte Anfragen und um die geht es. Binärpakete sind hier nicht relevant.

Testen muss leicht und unkompliziert sein. Je mehr man sich abkapselt und künstliche Restriktionen aufbaut, um so schwerer wird Unterstützung. Keine Accounts, keine Registrierung, direkt zugängliche Images mit Updates und Quellen zum nachlesen und anpassen und testen. Da wird man sich jetzt mehr auf Fedora konzentrieren dürfen.

Fedora ist wirklich nicht die Alternative zu Red Hat und Co. Wie oben bereits erwähnt viel zu kurze Supportdauer. Bei Fedora kommt noch erschwerend dazu das sie Programmversionen auch während eines Releases gerne mal aktualisieren - das auf einnem produktiven Server zu haben ist Gift.

Und oft hat man auch nicht gross die Wahl, da die Hardware die Distribution diktiert. Es ist gut möglich, dass du dir einen professionelles HP Server Setup reinlegst. HP sagt das ganze Ding ist zertifiziert für Red Hat Linux 8.

Dann solltest du auch das benutzen, weil du sonst den Support von HP verlierst.

 

[netzgestaltung]

also ich glaub, das wort support hab ich noch nie so oft gehört... aber wer hat den jemals wirklich irgendwo mal angerufen und dann hilfe bekommen? ich kenne das nur von gerüchten - es fällt mir wirklich schwierig, dem so einen wert bei zu messen. ich betreue einen RHEL 7 server und da gibts kein PHP 7.4 - nur 7.2 mit externen paketquellen will der betrieb den server nicht mehr servisieren und es wurde extra eine supportverlängerungslizenz gekauft, damit die den nicht updaten müssen. das ist alles das gegenteil von leiwand. ich würde lieber einen server betreiben, der regelmäßig updates bekommt. das ist mmn eine der wichtigsten sicherheitspolicies.

 

[andy_m4]

Anstatt einfach nur init.d zu ersetzen, enthält es mittlerweile DNS Server, DHCP Funktionen, etc.!

Wobei man dazu sagen muss, das man diese zusätzlichen Bestandteile ja nicht nutzen muss. systemd ist in so weit modular, das man diese Bestandteile nicht mal mitliefern muss. Wenn das trotzdem da ist, dann ist das die Entscheidung der jeweiligen Distribution.
Gibt trotzdem noch Dinge die in systemd fest drin sind, wo es streitbar ist ob man die in systemd reinpackt oder nicht (sowas wie Daemon-Supervision). Aber Deine Beispiele sind da eher nicht so geeignet.

Canonical (Ubuntu) hatte mal "upstart" als Alternative zu init.d entwickelt. DAS war ein sauberes und innovatives System (Event getriggert)

Na ja. UpStart hatte schon ein paar Schwächen. Also gerade das Event-System. Die Idee ansich ist gut. Die Umsetzung so lala. UpStart nötigt einem auf, Abhängigkeiten zwischen den Events und Abhängigkeitspfade kleinteilig per Hand festzulegen. systemd machts ja eher umgekehrt. Das legt sehr viel Wert auf "Requires" und löst quasi alles vorhergehende selbstständig auf.
So ein bisschen, wie beim Paketmanagement. Wenn Du da ein Programm installierst, kümmert sich der Paket-Manager ja auch darum, das alle benötigten Bibliotheken usw. mit installiert werden.

Find ich einen guten Ansatz.

Naja. Kommt drauf an. Der geschilderte Fall von systemd-resolvd ist da eher nicht so gut.
Wenn meine DNS-Konfiguration kaputt ist, dann merke ich das nicht sofort, weil der systemd-resolvd halt einfach den Fallback-Server nimmt und somit ne kaputte Konfiguration zunächst nicht auffällt.
Das ist schon nicht so schön, aber prekär wird es natürlich, wenn der jenige z.B. aus Datenschutzgründen einen bestimmten DNS-Server benutzt. Fällt der aus oder ist ein Fehler in der Konfiguration kriegt man das nicht nur nicht unmittelbar mit, sondern es werden auch noch Daten geleakt. Und spätestens das ist dann nicht mehr so lustig.

Ich find auch die Argumentation dafür schwierig. Selbst beim alterwürdigen UNIX-Resolver, ganz klassisch über die /etc/resolv.conf konfiguriert, konnte man Fallback-Server angeben. Da ist also gar nicht die Notwendigkeit irgendwie fest etwas im Quelltext zu hinterlegen. Vor allem weils ja auch die Fehlersuche erschwert.

 

[kim88]

also ich glaub, das wort support hab ich noch nie so oft gehört... aber wer hat den jemals wirklich irgendwo mal angerufen und dann hilfe bekommen?

Geht ja weniger um "anrufen" und Support erhalten -> und das kommt sicher auch oft vor. Sondern eben um Sicherheitsupdates.

Du kannst eine Applikation deployen und kannst die im Grunde 10 Jahre nicht mehr anfassen und laufen lassen weil Sicherheit gewährleistet wird ohne das Programm-Versionen angehoben werden.

 

[Kuristina]

Wenn meine DNS-Konfiguration kaputt ist.. ...sondern es werden auch noch Daten geleakt.

Kann ich nachvollziehen. Das kann für einige schon problematisch sein. Mir persönlich ist das aber egal, ob da Google Nameserver genutzt werden oder nicht. Hauptsache alles funktioniert und spart mir Zeit.

 

[pseudopseudonym]

Installiert euch mal keine Kindergarten Distribution wie Ubuntu, Mint, OpenSuse.

Warum? Nenn mir einen Grund!
Du nennst doch sogar schon ein Gegenargument:

Selber machen.

Ich will ein System, das möglichst unauffällig mich meine Arbeit machen lässt. Ich will nicht erst einen Kochtopf schmieden, um warm essen zu können. Genau das können die "Kindergarten"-Distros ganz gut. Ich instaliers, spiel mein Homeprofil ein, mach noch etwas apt install und die Sache ist durch. Wo genau bekomme ich jetzt mehr?

 

[mae]

Hier geht es aber nicht direkt um den Code, sondern - wie ich es verstehe- die Paketquellen.

Das wiederum ist dann zulässig die abzukapseln.

Fuer GPL-Pakete bezweifle ich das. Die SRPMs sind "derived work".

Was aber zulaessig ist: Dass sie die SRPMs nicht oeffentlich verfuegbar machen, sondern nur an ihre Kunden weitergeben. Die Kunden duerfen die unter GPL stehenden Pakete dann zwar weitergeben, aber die auf nicht sharealike-Lizenzen basierenden nicht unbedingt. Ob man auf sowas dann eine Distribution wie Alma aufbauen kann, bezweifle ich.

 

[Pummeluff]

1.) systemd ist … katrastrophal, weil systemd komplett gegen zahlreiche Linux Philosphien verstößt!

Dazu gab es jahrelange breite Diskussionen. Lassen wir mal die Philosophie außen vor, dann erfüllt Systemd den Zweck zum Starten von Diensten wesentlich angenehmer als die Sys-V-Skripte von früher. Zu Upstart kann ich nichts sagen. Damit hab ich nie gearbeitet.

Anstatt einfach nur init.d zu ersetzen, enthält es mittlerweile DNS Server, DHCP Funktionen, etc.!

Ja, auch die Kritik ist berechtigt. Aber auch hier nutz ich Systemd-Networkd schon zufrieden seit vielen Jahren. Denn auch hier war es der Fall, dass jede Distribution ihre eigenes Süppchen bei der Netzwerkkonfiguration gekocht hat.

Die schlimmste Katastrophe ist noch immer der NetworkManager. Mit dem Ding hatte ich schon soviel Ärger. Und das nehm ich Red Hat tatsächlich übel, dass diese Krankheit ausgerechnet seit RHEL 8 zur obligatorischen Kernkomponente bei der Netzwerkverwaltung ernannt wurde.

systemd-resolvd hat DNS Anfragen eine Zeit lang bei falscher Konfiguration (weiß nicht ob es heute immernoch so enthalten ist) hart-codiert an Google Nameserver weitergeleitet

RHEL verwendet systemd-resolved nicht.

Deine Kritiken sind mit Sicherheit berechtigt, erscheint mir durchaus aber überzogen.

Poetterings Projekte waren und sind durchaus umstritten. Aber wenigstens ist er mal die grundlegendem Probleme angegangen. Auch Pulseaudio war so eine Katastrophe. Mittlerweile hat aber die Ablösung Pipewire einen durchaus brauchbaren Status erreicht. Die ganzen damaligen Soundserver (arts, ESD, usw.) sind damit obsolet geworden. OSS hat sich damals über die Lizenz selbst ins Aus geschossen.

 

[andy_m4]

Denn auch hier war es der Fall, dass jede Distribution ihre eigenes Süppchen bei der Netzwerkkonfiguration gekocht hat.

Ich finds ja immer interessant, wie die Dinge passend zur jeweiligen Situation umgedeutet werden. :-)
Sonst schätzt man ja an der Linux-Welt immer die Vielfalt. Passt einem irgendwas grad nicht in den Kram, ist ausgerechnet an der Stelle Vielfalt aber doof und es muss vereinheitlicht werden. :-)

Die ganzen damaligen Soundserver (arts, ESD, usw.) sind damit obsolet geworden.
OSS hat sich damals über die Lizenz selbst ins Aus geschossen.

Ähm. OSS lässt sich eher mit einem ALSA vergleichen denn mit einem Soundserver.
Und die Lizenz war sicher nicht das wirklich primäre Problem. Man hätte ja einfach die letzte freie Version als Basis für eigene Entwicklungen nehmen können, wie man es bei anderen Projekten auch gemacht hat.
OSS gibt es übrigens nach wie vor (inzwischen auch längst wieder Open-Sourced), wenngleich es im Linux-Bereich eine eher untergeordnete Rolle spielt (Anm.: OSS läuft auch auf anderen Systemen; ALSA ist Linux-only ; ist hinsichtlich dessen ein bisschen so wie mit systemd )

 

[flaphoschi]

Fedora ist wirklich nicht die Alternative zu Red Hat und Co. Wie oben bereits erwähnt viel zu kurze Supportdauer. Bei Fedora kommt noch erschwerend dazu das sie Programmversionen auch während eines Releases gerne mal aktualisieren - das auf einnem produktiven Server zu haben ist Gift.

Sehe ich genau so. Fedora ist und soll auch keine Alternative zu RHEL sein. Es ist die Version für Privatanwender und entwicklungsnahe Begleitung. So ist Arch die passende Distribution für mein System im Privaten und der Arbeit. Mit entsprechendem Aufwand kann man auch Serverdienste betreiben.

Beim Kunden oder im Rechenzentrum heißt die Antwort RHEL oder SLES. Das “Enterprise” ist relativ Aussagekräftig. Wenig Fehler, direktes Sorgentelefon, reine Fehlerbehebung und neue Features nur auf Verlangen.

Die Situation bei Microsoft ist insoweit interessant, dass man sich als Privatanwender keine Ruhe mehr kaufen kann. Nur noch bei Enterpriselizenz hat man Kontrolle. Der Rest bekommt Zwangsupdates und jedes halbe Jahr ein Majorupgrade.

Bei Fedora muss man das nicht, da darf man freilich bestimmen was man bekommt. Updates oder Upgrade oder Stillstand. Ich installiere das gerne auf privaten Computern die ich nicht betreue. Relativ ungepatches System (anders als bei Ubuntu) und somit nahe an Upstream. Und die Anwender können das mit einem Klick selber gut warten.

Ergänzung (25. Juni 2023)

Sonst schätzt man ja an der Linux-Welt immer die Vielfalt. Passt einem irgendwas grad nicht in den Kram, ist ausgerechnet an der Stelle Vielfalt aber doof und es muss vereinheitlicht werden. :-)

Falsche Darstellung.

Bei Linux schätzen die Leute Flexibilität, Wahlmöglichkeiten und Standardisierung. Forks ohne weiterführenden Nutzen, Inkompatibilität und halbe Lösungen nicht.

Die Menge macht das Gift? Nö.
Es ist die Frage nach dem Nutzen.

Das Nebeneinander zwischen GNOME, XFCE, KDE und Fenstermanagern ist gut. Zwei Forks von GNOME, einen von KDE, einen eigenen Loginmanager und dann noch einen eigenen Displayserver - das will niemand.

Und weil Linux, GCC, LIBC, und LIBSTD++ und die Coreutils stabil sind - hat man sich dem nächsten Level mit Systemd (Systemverwaltung) gewidmet. Warum? Entwickler und Admins wollen eine einheitliche API für die Systemverwaltung.

Aber wenn etwas ersetzt werden muss? Dann setzt sich die Lösung auch durch. So hat Systemd etwa SysVinit und Upstart ersetzt. Und Wayland tut es mit X11. Mir ist ja schon weg. Und Unity wurde auch wieder von GNOME ersetzt. Vielleicht ersetzt irgendwann mal etwas Systmed? Sehe dafür derzeit jedoch keinen Bedarf.

PS: Oft hat Canonical eine eigene Lösung und die Entwicklergemeinschaft begrüßte diese nicht. Unity, Mir, Upstart, Snap…und ich erwarte das Snap wieder gehen muss. Manchmal mag eine konkurrierende Idee förderlich sein. Aber Canoical verfolgt zu oft eigene Ziele und verschwendet Ressourcen.

 

[Pampersbomber]

Danke, IBM.

/s