RIP CentOS?

M

marce

Well-Known Member
RedHat hat wohl irgendwas falsches geraucht...

Nachruf auf CentOS | kofler.info

kofler.info

... damit dürfte der nächste Release-Update-Prozess zum EOL von CentOS 7 sich ein wenig in die Länge ziehen, wenn man nun gleich noch ein komplett neues OS evaluieren darf.

... oder darf man Oracle vertrauen?
... oder hofft man auf die Comunity? Sozusagen "CentOS 2.0 reloaded"
... oder daß RH noch ein Einsehen hat?


Parallele Diskussion in anderen Foren:
* https://linux-club.de/forum/viewtopic.php?f=104&t=123288
* https://www.linuxforen.de/forums/showthread.php?282436-RIP-CentOS
 
Ich fürchte, das dürfte mehr Leute betreffen als man sich vorstellt. Nicht unbedingt direkt als "ich nutze CentOS" - sondern auch im Hintergrund vieler Dienste, die man evtl. bei anderen Unternehmen bezieht...
 
Mein Beileid an die Leute mit CentOS 8 die nur ein Jahr zur migration auf etwas anderes haben wärend CentOS 7 Nutzer noch bis 2024 Zeit haben.
Da bin ich doch froh nach 6 wieder auf Debian/Ubuntu zurück gewechselt zu haben.
 
... oder darf man Oracle vertrauen?
Click to expand...
Oracle und IBM... Pest und Cholera.
Zumindest aktuell hat Oracle wohl ein berechtigtes Interesse daran ihren Redhat-Clon zu pflegen da er massiv auf deren Infrastruktur zum Einsatz kommt. Ob aber Oracle plötzlich entscheidet eine Lizenz zu verlangen analog zu Java würde mich bei starkem Interesseanstieg durch den Tot von Centos nicht wirklich wundern. Die Firma wird halt von BWL'ern regiert....

... oder hofft man auf die Comunity? Sozusagen "CentOS 2.0 reloaded"
Click to expand...
Schon in Arbeit, heisst "Rocky Linux" und wurde von den originalen Centos-Machern ins Leben gerufen.
Centos war ja ursprünglich ein Community-Projekt das später an Redhat übergeben wurde.

... oder daß RH noch ein Einsehen hat?
Click to expand...
IBM ist über alle Bereiche hinweg am bluten, die suchen aktuell deutlich nach neuen Einnahmequellen. Und Redhat ist so ziemlich die einzige Abteilung die kontinuierlich Geld verdient... dann muss das wohl ausgemolken werden.


Für Centos6 + Centos7 gibt es übrigens offizielle Upgrade-Paths to Oracle-Linux mit einem Shell-Skript. Für Centos8 muss man etwas basteln aber laut allen Berichten funktioniert es zuverlässig, die Quellen zu tauschen.
 
RockyLinux muss halt erst mal fertig sein und das bieten, was CentOS bisher geliefert hat. Ok, selbst da war das mit den Updates teilweise ein wenig zu lahm...

Noch eine etwas andere Meinung:
https://blog.koehntopp.info/2020/12/09/embracing-the-stream.html

Ja, er hat durchaus Recht. Teilweise. Nicht alles lässt sich auch beim agilsten DevOps-Prozess weg-containern und auch die Container müssen ja irgendwo laufen. Und solange nicht alles in der AWS oder Google-Cloud läuft braucht's halt immer noch irgendwelche Core-Systeme oder Hosts, auf denen die ganze Virtuelle Welt sich herumtreibt...
 
Ja, er hat durchaus Recht. Teilweise.
Click to expand...
Wenn ich alles weg-containern will mit Redhat-Tools, setze ich kein RHEL oder Centos ein sondern RHCOS oder FCOS (CoreOS) mit OKD4.
Da stellt sich die Frage der Paketverwaltung im Sinne von Centos gar nicht weil es schlicht keine klassischen Repositories mit yum gibt, sondern rpm-ostree.

Ich liebe diesen Schlusssatz:
It’s 2020. Act like it.
Click to expand...
Genau, wenn die ganze Welt brennt, dann soll auch mein Server betroffen sein und nicht wacker-stabil vor sich hin ackern!

Nicht alles lässt sich auch beim agilsten DevOps-Prozess weg-containern
Click to expand...
Also gehen tut es schon, sinnvoll ist es nur nicht. Mir sträubt es wenn Datenbanken oder andere massive IO-lastig persistente Datenspeicheroperationen in Container geschmissen werden, am besten noch mit NFS oder gar CIFS Mountpoint...
Dazu legt man eine dedizierte virtuelle oder physische Machine an oder lebt mit den grotesken Leistungsproblemen. Wo wir wieder beim Problem wären, welches Betriebssystem setzt man dafür ein. Centos ja wohl nicht mehr :)
 
Natürlich geht immer alles. Dass wir hier nur über sinnvolles reden hatte ich eigentlich vorausschauend angenommen...

... und natürlich ist 2020 und Container, max. Abstraktion vom OS und Virtualisierung bis in's letzte Fitzelchen ist StateOfTheArt - das verneint aber nicht die Notwendigkeit von brauchbaren LTS-Betriebssystemen.
 
Die DevOps sind wie Mechatroniker. Weder Elektriker noch Schlosser, aber die gleiche Zeit für die Ausbildung.
Genau den gleichen Schwachsinn kann man in der IT sehen. Um Kosten zu sparen, machen die Entwickler noch den Job des Administrators.

Mir gehen die DevOps mit ihren scheiß Containern tierisch auf den Sack!
Die tun so, als ob es die Lösung für alle Probleme sei.

Was machen die DevOps, wenn Docker den Dienst einstellt?
 
DeaD_EyE said:
Was machen die DevOps, wenn Docker den Dienst einstellt?
Click to expand...
Na, auf eine der anderen CRI(-O) kompatiblen Engines umsatteln - fast alle Container-Systeme basieren bei Linux-Hosts eh im Grund auf RunC oder Containerlib, genau wie bei Paravirtualisierung unter Linux fast immer libvirt zum Einsatz kommt.


Die tun so, als ob es die Lösung für alle Probleme sei.
Click to expand...
Wie ist das Sprichwort, wenn du einen Hammer hast sieht alles nach Nägel aus? So ähnlich ist es mit allem. Die einen m(iss/ge)brauchen Excel/Access für alles, die anderen Container.


Die DevOps sind wie Mechatroniker. Weder Elektriker noch Schlosser, aber die gleiche Zeit für die Ausbildung.
Click to expand...
Fairerweise muss man aber dazu sagen dass genau wie bei Mechatronik die Übergänge und Bedürfnisse sehr fließend sind. Administratoren dringen zB mit Full-Stack Monitoring in den Bereich der Entwickler ein, umgedreht wollen die Entwickler mehr Kontrolle über die Ausführung.
Und wie auch bei den Mechantroniker gibt es plötzlich Bereiche (zB die nachfolgende Wartung) die plötzlich keine der beiden Seiten übernehmen will. Installation macht Spass, Wartung nicht :D


Genau wie die Automatisierung das manuelle Bearbeiten von Daten abgelöst hat, löst diese nun auch das manuelle Verwalten der Bearbeitungsserver ab. Aber ob das ein schlechtes Zeichen ist wenn Administratoren eher die Systemplanung und -steuerung statt den täglichen Kleinkram durchführen und mühselig die zig unterschiedlichen exotischen Abhängigkeiten eines jeden Entwicklers im gleichen System balancieren?

das verneint aber nicht die Notwendigkeit von brauchbaren LTS-Betriebssystemen.
Click to expand...
RHEL gibt es ja weiterhin, kostet nur halt eine Kleinigkeit. Vernünftiger LTS-Support und halbwegs akzeptabel verständlicher Support ist halt nicht geschenkt. Wenn es nicht RHEL sein soll, dann muss man sich auf die Gutmütigkeit von Millionären und das hoffentlich erfolgreiche Canonical-Konzept vertrauen. Ohne eine strukturierte und finanziell stabile Grundstruktur ist LTS praktisch nicht garantierbar.
 
Oh Mann...!
Was mach(t)en bloss die ganzen Big-Player mit ihren Rolling-Release-Systemen?
Allein die FreeBSD einsetzenden Big-Player sind demnach ja völlig durchgeknallt dass sie keine völlig veralteten, vor Sicherheitslücken und anderer Bugs strotzenden LTS-Binary-Distros einsetzen...

Hello? It's realy 2020!
Release Early, Release Often.
(LTS-)Binary-Distros sind sowas von 1990er/2000er und gehören endlich verboten!
Security first, Bugfixes second, Features third, Comfort fourth, Everything else last!
 
Ich nutze zwar kein FreeBSD, weiß aber aus Berichten darüber, dass sich dort nicht viel ändert, alles aus einem Guss stammt und Konfigurationsdateien scheinen sich auch fast nie geändert zu haben. Also sind die Updates unter den BSD-Derivaten eher langweilig.

Ich nutze Arch Linux als Hauptsystem... Also die Probleme von Rolling Releases unter Linux sind mir bekannt.

d4f said:
Fairerweise muss man aber dazu sagen dass genau wie bei Mechatronik die Übergänge und Bedürfnisse sehr fließend sind.
Click to expand...
Als ich damals meine Ausbildung zum Elektriker Fachrichtung Betriebstechnik gemacht habe, ist der Mechatroniker eingeführt worden.
Die damalige Ausbildung der Mechatroniker bestand darin, alles als Black-Box zu betrachten. Das ist das Konzept der Ausbildung.

Seit ca. 10 Jahren bin ich bei einem Unternehmen, dass didaktische Systeme für die Mechatroniker herstellt.
Die können gar nicht so viel wissen wie ein Elektriker oder Schlosser, da sie mehr mit Automatisierung und Softwareproblemen zu kämpfen haben.

Wenn man Arbeitskräfte braucht, die alles können, muss auch die Ausbildungszeit verlängert werden.
Bezüglich Ausrichtung auf die Zukunft (kein Great Reset), werden wir zukünftig Fachkräfte benötigen, die Vollblutautomatisierer sind und Roboter warten und programmieren können. Das kann man nur, wenn man das entsprechende Basiswissen hat, dass einem Mechatroniker nicht vollständig vermittelt werden kann. Allein aus zeitlichen Gründen.

Ähnlich sehe ich den Unterschied zwischen Administrator und Entwickler.
Der Administrator kennt sein System sehr genau, sogar besser als der Entwickler.
Dafür weiß der Administrator nicht, was der Entwickler so macht.
Um diesen Disput zu bereinigen, hat man die DevOps erfunden.
Der Admin kann Sachen, die der Entwickler gar nicht kennt und umgekehrt.
Beide haben ihre speziellen Fähigkeiten und verbessern sie stetig.

Letztendlich ist es aus Kostengründen gemacht worden.
Es ist doch viel günstiger nur einen Mitarbeiter mit der Aufgabe zu betreuen, als zwei.
So zumindest die Theorie.
 
Security first, Bugfixes second, Features third, Comfort fourth, Everything else last!
Click to expand...
Ist es mittlerweile nicht eher Features First? Wärend man Sicherheit durchaus mit einem .dot release erledigen kann kommen aber alle paar wochen ein major Release mit Feature änderungen und neuen Bugs. Reaktionszeit ist beim patching zwar schneller aber man introduced auch schneller neue Lücken/Bugs?
 
You must log in or register to reply here.
Back
Top