up.whatever schrieb:
Nicht nur. Doku & Knowledge-Base sind hervorragend und umfangreich. Das ist imho genau das, was Debian fehlt, konsistente, geprüfte, strukturierte, datumsversehene und aktuelle Dokumentation. Außerdem Schulungen mit umfangreichen Unterlagen (und Prüfungen). Darin lernt man selbst als alter Hase noch neues.
up.whatever schrieb:
Bei RHEL bist du mit entsprechender Lizenz nicht auf die Community angewiesen, sondern kannst im Problemfall direkt beim Hersteller Tickets eröffnen. Ebenso ist viel kommerzielle Software seitens deren Hersteller nur für den Betrieb auf RedHat getestet und unterstützt.
Das mit den Tickets stimmt; man wird geradezu ermuntert, welche zu eröffnen. Ob das dann auch wirklich weiterhilft, hängt aber ein bisschen davon ab, wen man am anderen Ende erwischt. Wir haben nach etlichen Iterationen in manchen Fällen auch schon selbst Lösungen erarbeitet und dann dort eingereicht ...
up.whatever schrieb:
Klar, das meiste bekommst du auch irgendwie auf Debian zum laufen, aber dann bist du auf dich alleine gestellt, wenn Probleme auftauchen. Privat ist das akzeptabel, aber wenn du damit dein Geld verdienst, denkst du unter Umständen anders darüber.
Es muss einem aber auch klar sein, dass die wirklich interessanten RH-Produkte teuer und ineinander verzahnt sind bzw. aufeinander aufbauen. Das heißt, man ist dort, wie bei jedem anderen größeren Hersteller, auf dem Weg in einen Vendor-Lock-in und stellt rasch fest, dass es nach der initialen Investition - bei entsprechendem eigenen Wachstum - Sinn ergibt, weitere Münzen nachzuwerfen. Nur eine Anmerkung.
up.whatever schrieb:
Der große Vorteil von Debian ist das riesige Software Repository. Wenn du bei RedHat zum Betrieb eigener Software spezielle Pakete benötigst, landest du ganz schnell bei EPEL und dort ist dann Schluss mit Support. In solchen Fällen kann auch Debian in der Firma sinnvoll sein, falls qualifizierte Mitarbeiter vorhanden sind, die im Problemfall selber troubleshooting machen können.
EPEL ist ein zweischneidiges Schwert. Es gibt veraltete und schlecht gepflegte Pakete darin, und mehr als einmal ist uns passiert, dass ein Paket, auf dass wir setzten, dann doch nicht in den gewünschten Versionen vorlag - oder Knall auf Fall aus EPEL verschwand. Das ist natürlich etwas, was man auf gar keinen Fall will.
IMHO ist es sinnvoller, RPM-Paketbau zu lernen und dann selbst zu paketieren. Das lässt sich mit Jenkins, Ansible, GitLab & Co. (oder Koji, wenn man es denn so groß aufziehen will) gut automatisieren und ist in Abhängigkeit von der Umgebung womöglich zuverlässiger und effizienter. Ist natürlich szenarioabhängig.
Tipp: Es gibt eine kostenlose Red Hat Developer Subscription, in der 16 Lizenzen für RHEL sowie weitere für Infrastruktur-Add-ons enthalten sind.
Disclaimer: Im Herzen bleibe ich Debianer. Aber auch dort hatte ich rasch eigene Paketversionen gebaut. 😛