Meine auch nicht.
Ich 30 Jahre ...
Also Bürojob?
Ich will mich mit dir nicht streiten. Ich habe nur was gegen diese vollkommen blöden Verkürzungen bei diesen Themen. Vor allem dann, wenn ich an der substanziellen Qualifikation der Aussagenden zu genau diesem Thema zweifle - nicht, weil ich das pauschal mache, sondern lese, was die Aussagenden so generell kommunizieren.
Pauschal
zu formulieren ist halt an der Realität gemessener Blödsinn für mich. Und ich finde, das sollte man als "Verantwortlicher der IT eines Unternehmens" eigentlich besser wissen.
Vorab: Der Hinweis auf die jahrelange Erfahrung im Systemhaus, und der Rolle als Verantwortlicher einer internen IT war nicht als Autoritätsargument gedacht, sondern lediglich als Kontext, aus welchem Blickwinkel ich auf das Thema schaue.
Thema:
Deine Kritik verkennt einfach, was moderne IT-Leitung bedeutet. Dass du meine Tätigkeit als reinen „Bürojob“ abtust, zeugt von einem eher theoretischen Bild aktueller Positionen. In einer internen IT-Abteilung bedeutet „Verantwortung“ eben nicht nur, Budgets in Excel-Tabellen zu schieben oder Powerpoint Folien zu zeigen!
Wenn nachts das Monitoring bei einem kritischen Cluster-Edge-Case anschlägt, die Hardware-Zertifizierung für neue Client-Generationen ansteht oder komplexe Migrationspfade im Lab evaluiert werden, bin ich oft genug selbst im Serverraum oder an der console. Wer glaubt, eine leitende Funktion entbinde einen von der technischen Realität an der Basis, hat vermutlich noch nie eine Abteilung durch eine echte Krisensituation geführt. Wäre dem so, hätte ich diese Position niemals angenommen.
Kommt oft genug vor das ich bei einem Neubau selbst die Switches in den Racks schraube und verkabel nur um sicherzustellen dass das HA Failover auch zu 100% funktioniert.
Wie dem auch sei, wir driften zu sehr ab.
Dass wir bei der Bewertung von Rolling Releases nicht zusammenkommen, liegt in der Natur der Sache:
- Scale matters: Es ist ein massiver Unterschied, ob man ein homogenes Setup betreut oder eine heterogene Landschaft mit hunderten Endpunkten und spezifischer Fachsoftware, die bei jedem Kernel-Sprung oder glibc-Update potenziell die Grätsche macht.
Risikomanagement Vs Feature Wunsch: In der Enterprise-Welt ist Vorhersehbarkeit und Zuverlässigkeit das höchste Gut. Ein "Bleeding Edge"-System mag für den versierten Einzelnutzer charmant sein, ist aber im Flottenmanagement oft schlicht ein unkalkulierbares Risiko, da wird mehr RHEL oder Ubuntu LTS eingesetzt.
Ob man das nun als „an der Realität gemessenen Blödsinn“ bezeichnet oder als notwendige Vorsicht aus jahrzehntelanger Betriebserfahrung, bleibt wohl Ansichtssache.
Da wir uns hier offensichtlich im Kreis drehen und die Argumente "auf beiden Seiten" hinreichend ausgetauscht sind, betrachte ich die Diskussion für mich als beendet. Wir haben hier einfach grundlegend verschiedene Ansätze, was Betriebssicherheit, Stabilität, Stress angeht.
PS: Wie ich bereits schrieb, verwende ich seit 2004 Archlinux und hab es auch schon unzähligen Anfängern empfohlen (Personen, die sich wirklich mit Linux auseinandersetzten, möchte, ohne keine Angst haben wenn etwas broken geht, den nur so lernt man am schnellsten), doch für Homelab/Server setzte ich auf Debian stable.
Ich wünsche dir weiterhin eine fehlerfreie Uptime mit deinen Systemen.
Und als Moderator bitte ich euch, dieses Gespräch entweder in einen eigenen Thread auszulagern oder per pn zu klären, aber das hat jetzt so gar nichts mit Fedora zu tun, danke
Von meiner Seite ist die Diskussion abgeschlossen. Ich möchte nur anmerken, dass der Austausch mit Tekkla durchaus zum Thema Linux und Rolling Releases beiträgt, da dabei zwei unterschiedliche Release-Systeme besprochen werden, da wir dabei Aspekte wie Stabilität, Risiko und langjähriger Praxis-Erfahrung besprechen, was gerade für Linux Neulinge von Interesse sein kann, um abzuwegen. Wenn du das anders siehst, lösche meine Beiträge. Danke.