CentOS ist tot, lange lebe CentOS Stream

DEFCON2 schrieb:
Ich persönlich bin stinkesauer, dass mit nur einem Jahr Vorwarnung mal eben acht Jahre LTS zurückgenommen wurde und CentOS 8 damit vor Version 7 EOL ist. Keinen, der wie wir Zeit und Geld in das Upgrade investiert hat, wird das freuen. So geht es wohl, wenn Community Projekte von big money absorbiert werden.

Ich denke du bist hauptsächlich auf dich selber "stinkesauer". Wenn man mit der Ankündigugn ein Problem hat, hat man seine IT nicht im Griff ging wohl einfach den bequemen Weg. Server deployt man heute so, dass die Distirbution darunter eigentlich keine Rolle mehr spielt und man die beliebig switchen kann.

DEFCON2 schrieb:
Ok, danke für den Tipp, dass wir einfach auch RHEL bezahlen können, wir wären gar nicht auf diese Idee gekommen und unsere Bilanzierer sind schon ganz erleichtert, seit ich deinen Tipp weitergeleitet habe.

Genau das hättet ihr tun können - dann hättet ihr 10 Jahre Ruhe. Auch wenn dein Einwand hier schrecklich sarkastisch ist ;)

DEFCON2 schrieb:
Bleib mal auf den Teppich. Wir sind bislang ein Hybrid Modell von RHEL und CentOS gefahren, in sofern haben wir finanziell beigetragen, aber wie bei vielen anderen, die es so machen, sind die Abläufe nicht darauf ausgelegt, für jede Instanz $$$ zu bezahlen. Mein Hauptproblem ist nicht, dass wir grundsätzlich alles kostenlos brauchen, sondern dass sich nicht an die Vereinbarung gehalten wurde mit dem LTS und damit die bisherige Planung und vor allem den Migrationsaufwand torpediert wird.

PS: Wenn du denkst, dass man mal so eben in einem Arbeitstag dein Drop-In replacement einspielt, bist du wahrscheinlich nur für deine drei privaten Linux Kisten zuständig.
Es gibt keine "Vereinbarung". Keine wirkliche. Wenn ich die RHEL Sourcen nehmen, dort Logo und Name auswechsle und daraus ein eigenes "kim88OS" baue und auf der entsprechenden Webseite sage ich supporte das 10 Jahre lang. Dann kannst du mir blind vertrauen oder - was wohl inteligenter wäre - du vertraust mir nicht. ^^

Daher es gibt keinen bindenden Vertrag. Anders ist wenn du bei RHEL einen Vertrag abschliesst da könntest du z.b. auf Nichterfüllung klagen.

Du musst deine Kisten nicht innerhalb von einem Tag wechseln sondern hast noch ein Jahr Zeit. Würde dir empfehlen hier umzudenken und das ganze mit Ansible und Docker Container zu bauen - so das darunter liegende System nicht mehr so relevant ist. Dann könnt ihr dort Support kaufen wo Infrastruktur super kritisch ist - und beim Rest auch mit einem Debian, Ubuntu, etc rennen lassen. Wenn man das mit Ansible gut kann, muss man nach dem aufsetzen einer Distro noch einen einzelnen Command absetzen und die Kiste richtet sich 1:1 so ein wie man es braucht.

Marco01_809 schrieb:
ZFSonLinux ist ein Kernel-Modul und muss passend genau für die Kernel-Version gebaut werden. Fix verbauen kann man den afaik nicht, da die Lizenz von Linux und dem ursprünglichen ZFS Code inkompatibel sind.

Richtig, das Problem haben aber viele Module. Virtuallbox Modul fällt mir da spontan ein - aber auch andere. Dafür gibt es aber auch Lösungen wie z.B. kmod.
 
  • Gefällt mir
Reaktionen: foo_1337, cbtestarossa und snaxilian
Ich ignoriere mal deine Anschuldigungen, dass man bei uns einfach die "IT nicht im Griff hätte". Ganz so einfach, wie du es darstellst, ist es nämlich nicht überall. Und bzgl. Docker, frag z.B. mal einen Anbieter von kommerzieller closed-source Software für Nischenanwendungen nach Hilfe, wenn du anfängst deren für RHEL vermarktete Software über Docker zu verteilen...
 
DEFCON2 schrieb:
Und bzgl. Docker, frag z.B. mal einen Anbieter von kommerzieller closed-source Software für Nischenanwendungen nach Hilfe, wenn du anfängst deren für RHEL vermarktete Software über Docker zu verteilen...
Ja. Gammelsoftware ist ein Problem. Aber solange solchen Herstellern ihre Lösungen (trotz durchwachsener Qualität) abgekauft werden, werden die halt nix ändern (warum auch? die verdienen ja auch so ihre Kohle).
Somit seid ihr also nicht die armen Opfer, sondern Teil des Problems.

DEFCON2 schrieb:
wenn du anfängst deren für RHEL vermarktete
Jetzt verstehe ich Dein Rumgeheule wegen CentOS aber noch weniger.
Ihr kauft ne Software die nur für RHEL zertifiziert ist. Dann haltet ihr euch für schlau und sagt euch "RHEL nehm' ich aber nicht, sondern spare mir die Kohle und nehm CentOS". CentOS stellt aber alles um und nu beschwert ihr euch, weil eure Software nicht läuft die aber ohnehin nur für RHEL zertifiziert war?
Find ich ja extrem spannend :-)
 
  • Gefällt mir
Reaktionen: foo_1337 und snaxilian
Wir benutzen beides, CentOS und RHEL.

Es ist übrigens etwas despektierlich, gleich von Gammelsoftware zu sprechen. In Nischenanwendungen gibt es viel sehr gute Software, die einfach nur funktioniert und teils zertifiziert ist, da hat niemand Zeit und Geld das dauernd zu portieren, wie bei Feld Wald und Wiesen Software und Tools, die heute in Rust neu geschrieben wird und morgen dann in...?
 
Gammelsoftware meint ja auch nicht Software die gut funktioniert. Sondern zusammengeschustertes Zeug was vorne und hinten wackelt und wenn man nur eine Kleinigkeit ändert dann plötzlich alles zusammenbricht.
Und leider ist das äußerst verbreitet. Man könnte fast sagen, es ist die Ausnahme das man da mal was Solides bekommt.
 
  • Gefällt mir
Reaktionen: foo_1337
Du kennst aber schon Lustre, ZFS, CUDA etcpp? Das sind alles Dinge, die du gegen den jeweiligen Kernel baust. Genau deswegen hat bei uns auch keiner Bock auf rolling update. Das ist ja jetzt teilweise schon ein Grauß. Und selbst mit RHEL und vollem Support dauert es manchmal ziemlich lange bis komplexe bugs gefunden, verstanden und dann auch noch gefixed sind. Wenn dein Reproducer nämlich lautet:

Nehmen Sie bitte ein 10 Mio Lustre und dazu dann 900 clients, die Software XY mit Inputset Z laufen lassen, dann stirbt das nach 5 Stunden, dann bist du auch mit RHEL+Lustre Support voll am Arsch....

Da war/ist es mit CentOS schon sehr sehr praktisch, wenn man "einfach" mal nen Cluster mit 100-300 Maschinen hochziehen kann mit genau dem Softwaresetting vom Kunden und das nachstellen kann.

DEFCON2 schrieb:
Ich persönlich bin stinkesauer, dass mit nur einem Jahr Vorwarnung mal eben acht Jahre LTS zurückgenommen wurde und CentOS 8 damit vor Version 7 EOL ist. Keinen, der wie wir Zeit und Geld in das Upgrade investiert hat, wird das freuen. So geht es wohl, wenn Community Projekte von big money absorbiert werden.
Dito. Der Umstieg auf RHEL/CentOS8 war schon echt nen Krampf. Ich sage nur NetworkManager.... Das Ding macht echt nen Spaß...

Und ja, wenn man komplette Deployments from scratch machen muss für ne große Anzahl von Knoten, dann ist Ansible nicht mehr praktikabel in meinen Augen. X tausend Knoten ohne Platten damit zu deployen. GZ viel Spaß. Klar, das geht, aber es dauert und Zeit ist Geld...

Rocky Linux ist wohl aktuell die interessanteste Option. Oracle würde ich nicht mit der Beiszange anfassen. Da muss man nur darauf warten, dass die mit irgend nem Vendor lockin um die Ecke kommen...

foo_1337 schrieb:
Ich habe sogar privat mehr als 3 Kisten, aber kein CentOS :D
CentOS 8 Support gibt es bis Ende 2021. Das sollte mehr als ausreichend Zeit sein, ohne Hau Ruck Aktionen. Und wenn man nicht ohnehin schon seine Hosts mit Ansible & Co bespielt, ist es jetzt höchste Zeit, darüber nachzudenken. Dann muss man auch kein Drop-In Replacement ausführen, sondern kann relativ schmerzfrei direkt neu deployen. Man braucht eben nur Disziplin, sonst ist es Essig mit Ansible.
"Ausreichend" Zeit? Dir ist schon klar, das Stand jetzt niemanden klar ist, wohin die Reise gehen wird?

Dann muss man die Migration entwickeln, muss es testen, muss Migrationspläne mit den Kunden abstimmen, muss dann Maintenance anberaumen etcpp. Da ist nen Jahr um, so schnell kannste gar nicht Support sagen. Zumal das normale Geschäft ja weiter läuft...

Was manche hier wohl auch vergessen ist, das es den akademischen Bereich noch gibt. Da wird sehr viel CentOS eingesetzt, weil RH da einfach zu einem gewissen Grad ziemlich am Rad dreht... Wenn ihr die Cluster node Lizenzen für RHEL7 kennt, dann wisst ihr was ich meine. Die gibt es ja z.B. nicht mehr für 8. Also die extra repos etcpp. Da ist soooo viel Umbruch, selbst bei RHEL.

Zwischen 7 und 8 gibt es einfach einen Bruch. Punkt, da muss man glaub nicht drüber diskutieren, und daran haben sicherlich mehr als genug Firmen zu knabbern. Da jetzt noch so nen Hammer wie das mit CentOS drauf zu packen ist mehr als beschissen. Und ja 1 Jahr ist quasi nichts....

Vor allem, was macht man, wenn Rocky Linux etc nichts wird? Es gibt wie gesagt mehr als genug Institutionen die sich RHEL nicht leisten können und auch nicht werden, weil RHEL bei weitem nicht das bringt, was es kostet.

Für Firmen ist das ne beschissene Situation, weil du wenns dumm läuft weiter RHEL supporten musst und dazu dann eine neue Distro, die halt nicht mehr RHEL basiert ist. DAS klingt doch nach viel Spaß oder nicht?

Ich kanns voll verstehen, warum viele nur noch am kotzen sind.
 
Skysnake schrieb:
´Rocky Linux ist wohl aktuell die interessanteste Option.
Ja, wenn man relativ schnell wieder in die gleiche Situation wie jetzt kommen will vermutlich schon.

Skysnake schrieb:
"Ausreichend" Zeit? Dir ist schon klar, das Stand jetzt niemanden klar ist, wohin die Reise gehen wird?
Wenn man anscheind so sehr wie du schreibst auf CentOS angewiesen ist, sollte man einfach das Geld in die Hand nehmen und RHEL Lizenzen kaufen. Dann ist die Reise sehr klar.

Skysnake schrieb:
Dann muss man die Migration entwickeln, muss es testen, muss Migrationspläne mit den Kunden abstimmen, muss dann Maintenance anberaumen etcpp. Da ist nen Jahr um, so schnell kannste gar nicht Support sagen. Zumal das normale Geschäft ja weiter läuft...
Siehe oben. Wäre dann vielleicht günstiger, wenn man einfach die RHEL Lizenz kauft.
Skysnake schrieb:
Was manche hier wohl auch vergessen ist, das es den akademischen Bereich noch gibt. Da wird sehr viel CentOS eingesetzt, weil RH da einfach zu einem gewissen Grad ziemlich am Rad dreht
Da gab es ja mal noch ein Scientific Linux.. jetzt rate mal, wieso das nicht mehr weiterentwickelt wird
Skysnake schrieb:
Für Firmen ist das ne beschissene Situation, weil du wenns dumm läuft weiter RHEL supporten musst und dazu dann eine neue Distro, die halt nicht mehr RHEL basiert ist. DAS klingt doch nach viel Spaß oder nicht?

Ich kanns voll verstehen, warum viele nur noch am kotzen sind.
Ich nicht. RHEL wollen aber nicht dafür zahlen wollen. Stattdessen verlässt man sich auf ein Community Projekt mit wenig Leuten und jetzt schon beschissenem Support was Security betrifft (siehe unten).
Sorry, aber man wusste von Anfang an, worauf man sich hier einlässt. Und wenn man im Jahre 2020 nicht auf Infrastructure as Code / Immutable Infrastructure setzt sondern brav seine VMs streichelt und so lange frickelt bis man nicht mehr weiß, was eigentlich gemacht wurde, hat man ohnehin etwas falsch gemacht. Ich kann alle RHEL / CentOS VMs (und natürlich auch das Bare Metal Zeugs) neu deployen, jeweils CentOS mit RHEL und umgekehrt austauschen. Und wenn ich Oracle wollte (nicht mit deren Kernel), ginge das auch ohne weiteres. Und da ist es völlig egal, wie komplex die Software ist, die darauf läuft. Die Komplexität wird in Code gerendert. So ist das auch nachvollziehbar und reproduzierbar. Für alle Kollegen.

So, nun nochmal zum Patchzyklus:
1609198966418.png


Jedes Mal, wenn RHEL ein neues Minor-Release einführt, pausiert CentOS (und übrigens auch Oracle Linux) die Update-Versorgung, bis die eigene Variante des Minor-Release fertig ist. CentOS-Anwender mussten daher ihre Systeme von Nov. 2019 bis Jan. 2020 (71 Tage) und von April 2020 bis Juni 2020 (48 Tage) ohne Updates betreiben.

Wer hier bisher für kritische bzw. exposed Systeme CentOS eingesetzt hat, wusste dies entweder nicht (trifft vermutlich auf die meisten zu) oder handelt einfach nur grob fahrlässig.

TL;DR: CentOS nutzt man nicht produktiv. Wer das bisher gemacht hat ist selbst schuld und bekommt aktuell leider dafür die Quittung.
 
Zuletzt bearbeitet von einem Moderator:
  • Gefällt mir
Reaktionen: kim88
Du verstehst es nicht.

Das sind Systeme, die

1. Hinter ne Firewall stehen
2. Auf die nur begrenzt User nach Antrag zugriff bekommen
3. die zu 90% single user sind
4. die zu 100% bare metal systeme sind
5. die je nach Kunde nach jedem User geputzt werden
6. Kein privilegierter Zugriff durch User möglich ist
7. dort wo kritische Sachen wie LDAP etc laufen haben nur root User zugriff

Das sind fast ausschließlich Kisten durch Steuergelder finanziert, bei denen es kack egal ist ob das Ergebnis heute da ist oder morgen. Wenn es unter kritische Infrastrucktur fällt läuft da auch RHEL drauf. Das ist eingepreist. Der Großteil will/brauch aber einfach so viel Ompf für sein Geld wie er bekommen kann.

Wenn du dir da die Cluster Lizenz holst von RHEL ist das auch "nur" self service support. Willst du ernsthaft den Leuten die normale RHEL subscription ans Bein binden? Dann sind die Cluster aber mal schnell zweistellige Prozent kleiner. Und für was? Dafür, dass da praktisch nichts aus den normalen Repos drauf läuft? Gute Idee. Btw. DU zahlst das dann mit. Ich hab echt kein Problem damit, wenn das jährliche Budget entsprechend für Bildung und Forschung angehoben wird. Macht mir die Arbeit einfacher.

Dir sollte aber klar sein, dass die mit dem gesparten Geld aber auch Leute in Forschung und Lehre bezahlen, die dann an dem neuen Shit arbeiten und eben auch das Debugging übernehme, das du sonst gar nicht machen kannst ohne Zugriff auf das System. Da werden dann auch oft genug Bugs gemeldet und gefixed.

Wir reden hier einfach nicht über 10 Server, wo auf jedem was anderes läuft und wenn der mal steht, dann fallen pro Minute x tausend € Schaden an wie bei Banken, Onlineshops etcpp. Sondern wenn das Ding steht ist der Schaden der, der durch den Ausfall der Rechenzeit entsteht. Fertig. Das wars. Da musst du komplett anders rechnen als im Enterprise Segment.

Und das wusste auch RedHat. Die sind ja auch dadurch so stark geworden, WEIL es eben CentOS als leichten inkomplizierten Einstieg gibt/gegeben hat, der einem erstmal alle Türen offen hält. Jetzt muss RedHat das über ihr Lizenzmodel abbilden und das sieht dann schnell auch für die nicht mehr gut aus.

Wie willst du denn bitte ein vernünftiges Lizenzmodell für nen Cluster mit x tausend Knoten machen, wo dann insgesamt vielleicht 5 unterschiedliche Setups betrieben werden. Management, login, Visualisierung/Postprocessing und Compute. Das wars dann auch schon. Und wie gesagt, die Probleme auf die du da stößt sind oft irgendwelche abgefackten Raceconditions, die mit genau deiner Hardware mit genau der Firmware auftreten. Und das mit ner Wahrscheinlichkeit von 0.x-2% Wenn überhaupt. Und das eben auch nur, wenn du gleichzeitig nen Großteil der Maschine benutzt. Sprich es gibt wie oben beschrieben keine Reproducer.

Wo ist also dein Mehrwert? Was die Leute brauchen ist nen stabiles System, was möglichst zeitnah mit Security updates versorgt wird. Wobei es wenns ganz hart auf hart kommt, die Kiste halt aus gemacht wird. Habe ich schon mehrfach erlebt. Das ist zwar bitter, aber vertretbar unterm Strich. Je nachdem kann man die Zeit dann auch für Forschung nutzen, für die es sonst keine Ressourcen gibt...

Achso und sag mal bitte noch, was die RHEL Lizenz dir bei den Lustre oder Mellanox Problemen hilft. Ach ja richtig nichts. Weil da heißt es dann wird noch nicht supported, ist noch zu neu. Nehmen Sie bitte das Alte. Kostet dann halt x % an Performance...

EDIT sagt:
Nur mal so als kleines Rechenbeispiel. Ne einfache subscription kostet ca 800€ im Jahr. Bei 5 Jahren sind da 4000€ pro Server. Bei 2000 Servern sind das mal schlappe 8Mio€ an Lizenzkosten Sind wir mal Gnädig und geben 50% discount. Sind aber noch immer 4Mio die da auf der Rechnung stehen und oft werden die Server dann auch noch ein sechstes oder siebtes Jahr betrieben. Dann kommen da nochmal pro Jahr 1,6Mio oben drauf... Nur um mal eine Relation dafür zu bekommen, um welche Summen es sich da dreht. Dafür kann man so einige Admins einstellen die dann auch genug Zeit haben bugs selbst zu fixen, oder was meinst du? Vor allem schau dir mal an, wie die SLAs da sind. Toll ist das jetzt noch nicht wirklich. Eigentlich willste da den 24/7 Support. Da bist aber dann bei rund 1300€ macht die Rechnung nicht wirklich besser, wobei man dann wirklich nen richtigen Mehrwert bekommt.
 
Zuletzt bearbeitet:
Skysnake schrieb:
Du kennst aber schon Lustre, ZFS, CUDA etcpp? Das sind alles Dinge, die du gegen den jeweiligen Kernel baust. Genau deswegen hat bei uns auch keiner Bock auf rolling update.
Ich nehme mal an, die Antwort galt mir.
Ähm nein. Ich meinte jetzt nicht, das man einfach blind auf CentOS Stream setzen sollte und alle Software damit nicht klar kommt ist schlecht.
Übrigens setze ich ZFS auf Linux selbst genau aus dem Grund nicht ein. Es ist mir dort zu wacklig mit dem out-of-tree Kernelmodul. Ich hab viel ZFS im Einsatz. Nicht ein Rechner davon ist aber eine Linux-Büchse.

Skysnake schrieb:
Da war/ist es mit CentOS schon sehr sehr praktisch, wenn man "einfach" mal nen Cluster mit 100-300 Maschinen hochziehen kann mit genau dem Softwaresetting vom Kunden und das nachstellen kann.
Mit CentOS Stream sind ja RHEL-kompatible Distributionen nicht verschwunden. Daher versteh ich die Aufregung nicht.

Skysnake schrieb:
Dito. Der Umstieg auf RHEL/CentOS8 war schon echt nen Krampf. Ich sage nur NetworkManager.... Das Ding macht echt nen Spaß...
Die gefällt also RHEL nicht. Und trotzdem heulst Du rum, weil CentOS wegfällt? :-)

Skysnake schrieb:
Willst du ernsthaft den Leuten die normale RHEL subscription ans Bein binden? Dann sind die Cluster aber mal schnell zweistellige Prozent kleiner. Und für was? Dafür, dass da praktisch nichts aus den normalen Repos drauf läuft? Gute Idee. Btw. DU zahlst das dann mit. Ich hab echt kein Problem damit, wenn das jährliche Budget entsprechend für Bildung und Forschung angehoben wird. Macht mir die Arbeit einfacher.
Ehrlich gesagt versteh ich immer nicht das Geheule um die Kosten. Wenn ich etwas haben will, dann muss ich eben den Preis bezahlen den mein Gegenüber haben will. Freilich wäre es besser für mich, wenn ich alles kostenlos kriegen würde.
Warum regst Du Dich nicht auf, das Du die Hardware nicht kostenlos bekommst? Die bieten Dir auch kein Support für CUDA und Co sondern nur für die Hardware ansich. Schweinerei das die Hersteller für ihre Hardware Geld haben wollen. :-)

Und ich meine, im Falle von Linux und Open-Source hat man ja noch das große Glück das man das tatsächlich kostenlos bekommt. Vielleicht nicht immer die Wunschdistribution. Aber selbst da gibts noch Alternativen.

Ist noch gar nicht so lange her, da hatten wir in der Uni sündhaft teure UNIX-Workstations zu stehen. Ganz einfach weils nix anderes gab. Heute ist man schon in der komfortablen Situation das Du vieles für sehr viel weniger Geld kriegst (auf der Software-Seite sogar kostenlos).
 
  • Gefällt mir
Reaktionen: kim88 und foo_1337
Skysnake schrieb:
Du verstehst es nicht.
[...]
Nur mal so als kleines Rechenbeispiel. Ne einfache subscription kostet ca 800€ im Jahr. Bei 5 Jahren sind da 4000€ pro Server. Bei 2000 Servern sind das mal schlappe 8Mio€ an Lizenzkosten Sind wir mal Gnädig und geben 50% discount.
Nein, du verstehst es nicht. Du bzw. deine Firma baut ein Geschäftsmodell auf einem Produkt auf, welches im Prinzip Geld kostet. Um dies zu vermeiden, nehmt ihr ein Community Projekt, welches von einer Hand voll Leuten gepflegt wird und verlasst euch darauf. Nun haben diese Leute keinen Bock mehr bzw. der Hauptponsor hat andere Pläne und die meisten Member überzeugt.
Und ihr jammert jetzt ernsthaft darüber rum? Ganz ehrlich: Selbst schuld! Damit muss man rechnen, ganz einfach. Da du die ganze Zeit von Kunden sprichst, stimmt eure Kalkulation anscheinend nicht.
Eine andere Alternative, falls deine Rechnung stimmen sollte: Baut euren RHEL Klon einfach selbst.

BTW: Die "Geldgeilen" Idioten steuern der Open Source bzw. Linux Community schon seit Jahrzehnten soviel bei wie kein anderer. Glücklicherweise gibt es genug Firmen, die die Lizenzen bezahlen. Am Ende kommt es uns allen zu Gute.

Ergänzung ()

andy_m4 schrieb:
Übrigens setze ich ZFS auf Linux selbst genau aus dem Grund nicht ein. Es ist mir dort zu wacklig mit dem out-of-tree Kernelmodul. Ich hab viel ZFS im Einsatz. Nicht ein Rechner davon ist aber eine Linux-Büchse.
Sehe ich genau so, ich fahre bisher auch alle ZFS Setups unter FreeBSD.
 
Zuletzt bearbeitet von einem Moderator:
  • Gefällt mir
Reaktionen: kim88
foo_1337 schrieb:
Baut euren RHEL Klon einfach selbst.
Eben. Die Quelltexte sind ja frei verfügbar. Was anderes machen CentOS und Co ja auch nicht.
Das ist dann aber nicht mehr mundgerecht und vorgekaut, sondern nur kostenlos. Also nix für ähm gehobene Ansprüche. :-)

foo_1337 schrieb:
ich fahre bisher auch alle ZFS Setups unter FreeBSD.
Und mit FreeBSD 13 wandert dann ja auch OpenZFS ganz offiziell ins System. Das bringt dann auch so Sachen wie Verschlüsselung (also ohne den Umweg über GELI), ZSTD-Kompression (gzip-Niveau bei lz4 Geschwindigkeit) und persistenten L2ARC.
 
  • Gefällt mir
Reaktionen: foo_1337
Nochmals. Wir bieten sowohl RHEL 7 und 8 an als auch CentOS 7 und 8. Das entscheidet am Ende der Kunde durch seine Ausschreibung. Scientific Linux hatten wir auch schon, genau wie SLES wenn ich die sourcen richtig im Kopf habe.

RHEL ist auch bisher nicht weg zu diskutieren, wobei sich das nun eventuell ändert.

Stand heute gibt es mehr als genug Unis etc die CentOS einsetzen. Z.b. https://www.hpc.uni-freiburg.de/nemo

Ansonsten ist sowohl SLES als auch RedHat als auch Scientific Linux bisher im Einsatz auf so Kisten.

Selbst Jülich als eines unserer drei Tier1 Center in Deutschland verwendet CentOS. https://www.fz-juelich.de/ias/ias-5/EN/VNU-Keylab/Equipment/Equipment.html und wohl auch auf JUWELS nem Top7 System der Welt...

Und wie gesagt, das hat seine Gründe.

Und bezüglich unserer Firma, wir melden Bugs und arbeiten am Debuggibg mit, sowie an der Lösung von Problemen soweit möglich, aber viel machen auch unsere Kunden direkt.

Was man hier auch nicht unterschlagen darf ist das durch diesen Bereich ein ganz erträglicher Output an Spezialisten für RHEL generiert wird.

Das wird RedHat verlieren, wenn Rocky oder eine der anderen Alternativen nicht vernünftig abläuft.

Den einen oder anderen werden Sie damit aber vergrault haben.

Das man über eine komplette Branche derart abwertend spricht ist ziemlich anmaßend. Wovor allem mit dem Verweis man solle doch selbst nen Fork machen... die sehen sich alle als Teil der CentOS community und tragen ihren Teil bei, aber keiner von denen hat die originäre Aufgabe sich um sowas zu kümmern. Die würden es sicherlich gerne machen, wenn Sie das Geld dafür bekommen würden. Bekommen sie aber NICHT und damit wäre es Veruntreuung wenn sie es dennoch machen würden...

Sorry, aber wie gesagt, ihr habt es nicht verstanden. Kommt mal von euren Enterprise Klitschen runter, wo ne Hand voll Server betreut werden und vieles/alles Virtualisiert ist. Die sind nicht der Nabel der Welt.

Und bezüglich Nvidis und Mellanox. Da zahlt man eben nicht nur für die Hardware sondern auch substanziell für die Software dazu. Könnt ihr euch wohl nur nicht vorstellen...

Und genau die freuen sich über CentOS aktuell, weil sie den Markt kennen und so nur ein OS supporten müssen.
Ergänzung ()

Nur nochmals der Vollständigkeit halber von den Top10 Systemen der Top500 setzen drei auf CentOS.
7. Juwels(Atos)
8. HPC5 (Delll) Eni also Öl Multi...
9. Frontera (Dell) das schnellste CPU online Uni System...

Bei Dell und Atos muss also ganz offensichtlich auch die Kalkulation nicht stimmen... Gelle....

Ich hoffe du merkst dass das einfach bullshit war, ist und bleibt...
 
Zuletzt bearbeitet:
Du hast den Kern meiner Aussage nicht verstanden. Ich wiederhole es gerne nochmals:
Wer sich auf ein Projekt verlässt, das aus einer Hand voll Contributoren besteht, hat ein Problem. Dell und Atos sind sich dem sicher bewusst und haben einen Plan B. Und du kannst auch noch 100 andere Beispiele bringen. Das alles ändert nichts an dieser Tatsache. Du merkst doch gerade selbst, was das für eine Auswirkung auf euch hat. Was hilft es dir dann zu sagen: "Dell und Atos machen das auch so"? Ist so wie früher in der Schule, als man versucht hat von der eigenen schlechten Note abzulenken und gesagt hat: Der XYZ hat auch ne 5.

Offensichtlich hat dein AG noch keinen Cent an CentOS (welch Wortspiel) gespendet. Wow, Bugs reporten, klasse! Ich bin froh, dass mein AG, also die "Enterprise Klitsche mit ein paar VMs" das anders sieht. Und glaube mir, wenn ich nur ein paar VMs hätte, würde ich mir keinen Stress bzgl. Automatisierung, Pipelines und Testing machen.

Und ganz ehrlich: Das mit dem selbst gebauten RHEL Klon ist kein Scherz. Schau doch mal an, wie viele Forks es auf Github gibt und wieviele Unternehmen Mitarbeiter dafür abstellen. Wenn ich von etwas so abhängig bin, brauche ich Leute, die das weiter pflegen können, falls der Maintainer keinen Bock mehr hat oder anderweitige Pläne damit hat.

In Zeiten von containerd, k8s, microservices spielen die Distros sowieso eine untergeordnete Rolle. Vielleicht sollte sich die HPC Branche mal daran orientieren. Ist ohnehin nur noch eine Frage der Zeit, bis auch diese Dinosaurier untergehen. Vor allem dann, wenn sie nichts daran ändern. Alleine wenn ich oben schon Lustre lese.... Die haben es bis heute nicht geschafft, aufgrund ihres unsauberen Codes, in den Mainline Kernel importiert zu werden. Das sind alles bescheuerte Hacks, die wackelig^10 sind. Ich habe vor vielen Jahren, zu RHEL4 Zeiten, recht viele Systeme mit GPFS gehabt. Zur damaligen Zeit war das super und es gab nur sehr wenig vergleichbares. Heute ist sowas aber legacy, genauso wie eigentlich auch NFS. Object Store ist der Weg, der zwar auch seine Nachteile hat, aber so viel besser ist als traditionelle Clusterfilesysteme. Vor allem ist er viel Fehlertoleranter und sowohl im Ops wie auch im Dev Bereich deutlich einfacher zu handlen.
 
  • Gefällt mir
Reaktionen: kim88
foo_1337 schrieb:
Wer sich auf ein Projekt verlässt, das aus einer Hand voll Contributoren besteht, hat ein Problem.
Dann können wir hier aber direkt Schluss machen. Dann funktioniert die weltweite IT-Industrie grundsätzlich nicht.
Endlos viele zentrale Softwares, Bibliotheken, Server u.s.w. werden ausschlielich von Frewilligen gepflegt.
Ich behaupte man kann nicht mehr sinnvoll Software entwickeln oder Services betreiben ohne sich auf Projekte von freiwilligen Contributoren zu verlassen.
 
  • Gefällt mir
Reaktionen: Astrogath
Das ist richtig, aber ich muss mir dessen bewusst sein und einen Plan B haben. Wir haben damals den Apache 1.3 auch noch inhouse weitergepflegt, weil 2.x längere Zeit für diverse Dinge nicht gepasst hat. Und ja, so ist es auch insbesondere bei node.js im Zusammenhang mit npm/yarn, php composer und vielen anderen Dingen. Aber da der Kollege hier sich schon über den ach so kompilzierten Umstieg von RHEL7 auf RHEL8 beschwert hat, fehlen mir da einfach die Worte.
In dem Bereich in dem ich mich seit ein paar Jahren hauptsächlich Bewege, kannst du nach jedem Release (und die kommen mehrfach jährlich) Changelogs studieren und meistens Anpassungen vornehmen, weil irgendwelche APIs deprecated werden etc. LTS wird bald in vielen Bereichen zum Relikt werden. Und ja, das kostet Ressourcen, bringt aber auch in der Regel einen Benefit. Der klassische Sysadmin wird halt immer mehr verdrängt, auch wenn das vielen nicht passt. Wenn du nicht Coden kannst, hast du in einigen Jahren einfach verloren.

Edit: Ah, die HPC Fraktion scheint sich bereits solche Gedanken zu machen: https://scalability.org/2020/12/the-future-of-linux-distributions-in-the-age-of-docker-and-k8s/

Aber ihr könnt es ja jetzt besser machen. Unterstützt Rocky Linux, wenn euch das wichtig ist. Kurtzer kommt ja selbst aus diesem Bereich. Wenn ihr wieder nur konsumiert und das Ding nach ein paar Jahren im Attic landet, ist die "Szene" selbst schuld.
https://github.com/rocky-linux/rocky#contributing
 
Zuletzt bearbeitet von einem Moderator:
  • Gefällt mir
Reaktionen: kim88
Marco01_809 schrieb:
Dann können wir hier aber direkt Schluss machen. Dann funktioniert die weltweite IT-Industrie grundsätzlich nicht.
Tut sie ja auch nicht, da alle voneinander abschreiben und sich oft herzlichst wenig um Abhängigkeiten kümmern. Sobald der Updater und das MVP (minimal valuable product) steht wird es auf den Markt geworfen und reift als Bananenware beim Kunden.
Du glaubst gar nicht in wie viel Software veraltete Libraries und Abhängigkeiten vorhanden sind weil die Hersteller nur verzögert oder manchmal auch erst auf Druck der Öffentlichkeit mitbekommen, dass Sie veraltete Software als Abhängigkeit ausliefern obwohl es für die Abhängigkeit bereits neue und korrigierte Versionen gibt.
 
  • Gefällt mir
Reaktionen: andy_m4
Und du meinst jetzt ernsthaft, das Atos und Dell ne Alternative für diese Art von Kunden haben?

Träum weiter. Die Alternative stand jetzt ist auf Centos7 zurück gehen oder halt zu warten was aus den anderen Projekten wird. Wenn WIR eins machen würden, wäre das auch zum scheitern verurteilt, genau wie von Atos, Dell etc. Einfach weil die Konkurrenz nicht mitmachen würde. Da muss jemand unabhängiges den Hut auf haben.

Und dir ist schon klar, das Bugs abseits von Abweichungen zu RHEL nicht von CentOS gefixed werden sondern bei Redhat eingetütet werden müssen...

Wir leisten mit x Millionen an Lizenzgebühren an RedHat sicherlich einen angemessenen Beitrag. Wer jetzt aber nen Cluster hat und auf CentOS8 gesetzt hat, der ist am Arsch. Für den gibt es genau 0 € neues Geld. Der hat also nur die Möglichkeit zu migrieren. Am ehesten wohl auf Centos7 weil man damit Zeit gewinnt. Es wird wohl nicht für die gesamte Nutzungsdauer reichen aber wie gesagt man hat dann wirklich Zeit.

Was meinste was passieren würde wenn NGINX morgen den Betrieb einstellen würde oder Apache oder Wordpress etc. Da rauchen dann aber auch viele Köpfe....

Wie gesagt, für uns ist es an sich kein Problem, aber für die Kunden die jetzt im Regen stehen und kurzfristig schauen müssen was sie tun.

Im HPC Umfeld benutzt du halt leading edge Hardware und benutzt auch wirklich die Features. Zudem muss am Ende halt auch immer die Performance stimmen und wenn du durch einen neuen MikroCode von Intel mal eben zweistellige Memorybandbreite verlierst bei Stream, dann ist das nicht mehr lustig. Vor allem bis man mal die Ursache gefunden hat..

Wir haben die letzten Jahre so einige Firmware, Hardware und Software Bugs gefunden. Deswegen ist alles was auch nur wie Rolling release aussieht die Pest.

Von 99% wirst du aber nie was hören, weil der ganze Mist nur unter NDAs läuft. Ich hatte z.B. vor ein paar Jahren wohl nen Hardwarebug in nem Chip gefunden, der wohl nicht fixbar ist. Der Hersteller hat Monate gebraucht bis er es verifizieren konnte ... seltsamerweise wurde es dann auch relativ still um den Chip... man hat aber nie die Gründe erfahren... Seltsam nicht...

Wie gesagt, wir nehmen uns in der Branche sicherlich auch mit CentOS bisher etwas raus, aber wir geben auch sehr viel zurück, wovon alle profitieren. Und vor allem nutzen wir ja hundert oder tausendfach die gleichen Systeme. Da für jedes die Lizenz ab zu drücken ist nicht realistisch. Ob ich jetzt 5 oder 5000 Server betreibe macht kaum einen Unterschied was den Support anbelangt. Ich mach es eher sogar noch einfacher weil Dinge mit niedriger Statistik dennoch häufig auftreten und damit überhaupt vernünftig reproduziert werden können.

Und bezüglich Container. Guter Witz. Erzähl das mal so manchen ISVs...

Und auf der anderen Seite hast du schon mal nen Container gesehen, der binaries spezifisch für eine CPU Generation hat? Und dann jeweils noch für Mellanox EDR, HDR und FDR mit und ohne global offloading mit und ohne GPUs hat?

Nicht wirklich, es gibt seit 2018/2019 Bestrebungen dahin, aber die Leute kämpfen extrem mit riesigen images und das sind jetzt nicht die 30Mio Zeilen Code Monster die die da aktuell verwenden...

DAS ist nämlich eine der Sachen die vergessen wird. In HPC optimierst du auf die jeweilige Hardware und teils sogar wirklich auf die spezifische Maschine. Container kannste da nicht bauen die dann auch wirklich Performant sind. Vor allem bist du auch schnell bei Midleware die eben lizenziert ist und gar nicht verpackt werden kann/darf...

Der Container Workshop auf der ISC19 war da scjo sehr ernüchternd...
Ergänzung ()

Ps noch was aus der Nähkiste. Klar wird Singularity benutzt und ist auch durchaus nen Blick Wert. Off Record wird aber auch recht unverhohlen gesagt, dass das auch im Wesentlichen dafür ist um Leute an HPC überhaupt heran zu führen. Also gerade auch Leute aus den LifenScience Bereichen. Da nimmt man dann auch teils zweistellige Performanceverluste in Kauf weil die ansonsten halt gar nichts machen könnten in der Zeit die sie haben, da die Einstiegshürden zu hoch sind oder Sie halt noch ineffizienter wären.
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: snaxilian
Skysnake schrieb:
Nochmals. Wir bieten sowohl RHEL 7 und 8 an als auch CentOS 7 und 8. Das entscheidet am Ende der Kunde durch seine Ausschreibung.
Wo ist denn dann Dein Problem?
Wenn der Kunde sagt, was er haben will kriegt der Kunde was er haben will muss dann aber auch mit den Implikationen leben.
Also ist doch für Dich alles super.

Blöd ist halt nur, wenn Du mit dem Tipp um die Ecke kommst "Psssst. Ich hab ne super Idee wie ihr Geld sparen könnt" und das dann in die Binsen geht.
Soviel wie Du lamentierst könnte man ja fast denken, das sei so gewesen. :-)

Skysnake schrieb:
Stand heute gibt es mehr als genug Unis etc die CentOS einsetzen.
Das verbietet ihnen ja auch keiner.

Skysnake schrieb:
Und wie gesagt, das hat seine Gründe.
Was ich bloß nicht verstehe:
Wenn es doch so viel Bedarf an einem freien RHEL gibt, warum tun sich die dann nicht alle zusammen und jeder von denen wirft einen kleinen Beitrag in nen Topf und damit finanziert man dann einen freien RHEL-Klon. Oder man unterstützt bestehende Projekte.
Stattdessen sich einfach bei einem freien Projekt zu bedienen und dann noch rummäkeln, wenn die ihren Dienst einstellen ist mir da ein wenig billig.
Es ist Open Source! Ihr alle habt es selbst in der Hand. Nur müsste man dann auch mal den Hintern hoch kriegen statt immer nur Ansprüche zu stellen.

Scientific-Linux ist ja übrigens genau aus der Überlegung heraus entstanden. Universitäres Umfeld. Die wollten auch ein RHEL ohne die Subskription-Gebühr. Also haben die sich gesagt, wir bauen uns unser RHEL-Linux einfach aus den Redhat-Quellen und fertig.
Die haben dann halt irgendwann leider den Fehler gemacht zu sagen: Wozu selbst machen? Gibt ja CentOS.

Skysnake schrieb:
Wir leisten mit x Millionen an Lizenzgebühren an RedHat sicherlich einen angemessenen Beitrag. Wer jetzt aber nen Cluster hat und auf CentOS8 gesetzt hat, der ist am Arsch. Für den gibt es genau 0 € neues Geld
Der kann auch einfach einen anderen RHEL-Klon nutzen. Im Grunde ist ja das schöne an diesen Klonen, das es sich im wesentlichen darauf beschränkt ein neues Package-Repository zu konfigurieren.

Skysnake schrieb:
Das man über eine komplette Branche derart abwertend spricht ist ziemlich anmaßend.
Och weißte. Das leiste ich mir einfach. :-)

Skysnake schrieb:
Wovor allem mit dem Verweis man solle doch selbst nen Fork machen... die sehen sich alle als Teil der CentOS community und tragen ihren Teil bei, aber keiner von denen hat die originäre Aufgabe sich um sowas zu kümmern. Die würden es sicherlich gerne machen, wenn Sie das Geld dafür bekommen würden. Bekommen sie aber NICHT und damit wäre es Veruntreuung wenn sie es dennoch machen würden...
Der "Fehler" war schon im vorhinein einfach blind davon auszugehen, das das mit CentOS schon alles glattgehen würde. Wobei ansich die Entscheidung auf CentOS zu setzen gar nicht verkehrt ist. Wie gesagt. CentOS bzw. RHEL ist nun mal eine lang-unterstützte Distribution. Zu CentOS gibt es kompatible Alternativen.
Insofern war ja es im Prinzip nicht verkehrt es so zu machen.

Skysnake schrieb:
Sorry, aber wie gesagt, ihr habt es nicht verstanden. Kommt mal von euren Enterprise Klitschen runter, wo ne Hand voll Server betreut werden und vieles/alles Virtualisiert ist.
Das ist ja das Lustige. Umso mehr Systeme beteiligt sind, umso eher lohnt es sich dann auch RHEL-Linux selbst zu klonen. :-)
Wenn ich nur ne handvoll Server hätte, würde ich dann vermutlich einfach stumpf die Distribution wechseln. Bei einem größeren Umfeld welches dann auch noch auf RHEL-Linux abgestimmt ist, hab ich viel eher was davon dann auch bei RHEL oder einem Klon davon zu bleiben oder den sogar notfalls selbst auf die Beine zu stellen.

Skysnake schrieb:
Und genau die freuen sich über CentOS aktuell, weil sie den Markt kennen und so nur ein OS supporten müssen.
Genau da ändert sich aber nix wenn man einen anderen RHEL-Klon einsetzt. Das ist der Vorteil bei Klonen. :-)

Marco01_809 schrieb:
Dann können wir hier aber direkt Schluss machen. Dann funktioniert die weltweite IT-Industrie grundsätzlich nicht.
Endlos viele zentrale Softwares, Bibliotheken, Server u.s.w. werden ausschlielich von Frewilligen gepflegt.
Ich behaupte man kann nicht mehr sinnvoll Software entwickeln oder Services betreiben ohne sich auf Projekte von freiwilligen Contributoren zu verlassen.
Ja. Ist ja alles richtig. Sagt ja auch keiner, das man das nicht mehr nutzen soll. Aber wenn man es denn schon nutzt, dann sollte man auch ein Mindestmaß an Verantwortung zeigen. Man hat ja schon eine Menge Geld/Ressourcen gespart in dem man den Teil den man sich genommen hat nicht selbst entwickeln musste. Jetzt dann zusätzlich auch noch zu sparen in dem man das jeweilige Projekt nicht unterstützt und im gleichen Atemzug quasi zu fordern, das es doch bitte bis ans Ende aller Tage gepflegt werden möge ist dann doch schon ziemlich assig.

Und in der Praxis läuft es ja sogar noch ne Ecke schlimmer, wie von snaxilian schön dargestellt. Wenn von denen dann jemand rumheult weil irgendein Projekt eingestellt wurde, dann hält sich mein Mitleid ziemlich arg in Grenzen.

Skysnake schrieb:
Was meinste was passieren würde wenn NGINX morgen den Betrieb einstellen würde oder Apache oder Wordpress etc. Da rauchen dann aber auch viele Köpfe....
Dann haben viele Open Source einfach nicht verstanden. Open Source setzt man primär nicht deshalb ein, weil es kostenlos ist. Das ist zwar auch ganz nett, aber letztlich nur ein Nebeneffekt.

Nein. Open Source setzt man (strategisch) deshalb ein, weil man nicht nur die Möglichkeit hat umfangreiche Anpassungen vorzunehmen, sondern notfalls auch das Projekt dann weiter führen kann, wenn der ursprüngliche Autor/Hersteller das nicht mehr tut. Bei Closed-Source bin ich aufgeschmissen (da kann ich höchstens hoffen, das als letzter Akt wenigstens noch die Quelltext offengelegt wird).

Bei Open Source kann ich es notfalls selbst machen. Und wenn ich es nicht selbst kann oder will kann ich jemanden beauftragen. Wenn sehr viele das Programm nutzen kann ich sogar darauf hoffen, das jemand anders das Projekt weiter führt oder ich kann mich mit Leidensgenossen zusammenschließen und gemeinsam etwas auf die Beine stellen, um das Projekt am Leben zu erhalten.
 
  • Gefällt mir
Reaktionen: snaxilian und foo_1337
Ne, du liegst mit deinem "Verdacht" völlig daneben. Das wird von den Kunden durch die Ausschreibung vorgegeben. An sich könnte man also sagen ich bin da fein raus. Aber real bleibt es dann halt an meinen Kollegen und mir hängen, mit den Kunden die Migration zu vollziehen. Die ganze Arbeit für Centos8 Installationen ist jetzt halt für die Tonne und es ist jetzt nicht so als ob wir nur Däumchen drehen würden...

Aber das ist am Ende vom Tag nicht DAS Problem. Das Problem ist Die Zeit die einem jetzt noch bleibt in Kombination mit dem Zeitpunkt. RedHat hat andere Dinge versprochen und jetzt so knall auf Fall kommt das nach einer der großen Messen der Branche. Und das während der Corona Pandemie, wo schon eh viel extra läuft.... RedHat tut sich da keinen gefallen, weil Sie sich gerade ihren Ruf für Stabilität und Verlässlichkeit ruinieren. Das werden die noch zu spüren bekommen weil Leute aufgrund mangelndem Vertrauens abwandern werden.

Die haben allen halt richtig ein Eig gelegt vor Weihnachten... die Leute hinter rocky Linux werden das sicherlich wuppen, aber werden die das unter den aktuellen Verhältnissen ohne Messen/Konferenzen etcpp auch innerhalb der nächsten 3 Monate schaffen? Ich habe meine Zweifel.

Und genau das ist doch das Problem. Stand jetzt gibt es keine Alternative zu CentOS. Oracle wird von genug abgelehnt werden und das zu Recht. Scientific Linux hat man zugunsten CentOS aufgegeben, was an sich die richtige Entscheidung war. Vor allem eben auch wegen den Versprechungen von RedHat.

Hätte RedHat NIE die Versprechen bezüglich CentOS8 haben, hätte keiner Centos8 eingesetzt und die Kunden und damit wir keinen Stress. Ne Alternative würde sich finden. Und RedHat würde sicherlich allgemein mit gewissen Fragezeichen versehen, aber erst mal weiter eingesetzt. Die Frage ist ob einer ernsthaft schon auf RedHat8 gegangen wäre. Die Motivation war ja das man mit dem 8er erstmal wieder Ruhe hat. So wird SLES aber deutlich interessant als bisher. Die Bewertung könnte sich zukünftig also ändern.

Ist das so unverständlich dass das ein Problem ist?

Gehen wir mal davon aus das Rocky in 3 Monaten den ersten build raus wirft und man ihnen genug Vertrauen schenkt. Dann bleiben 9 Monate um die ganze Migration zu planen mit jedem Kunden, Wartungsfenster zu vereinbaren und die Kunden zu migrieren. Da steckt durch die Verifikation nen Arsch an Arbeit dahinter und jeder will ja vor Supportende fertig sein...

Parallel muss man aber ja auch an Plan B arbeiten weil Rocky kann ja auch ne Bruchlandung hinlegen. Und das ist leicht. Reicht ja schon wenn sie die ganzen Prozesse nicht bis Q3 hinbekommen. Also selbst wenn ALLES wie bei Centos läuft in Q122 bringt das keinem etwas. Und das Wissen die Leute auch. Ist die Frage ob das nicht auch den einen anderen abhält. Mich würde es nicht überraschen.

Es gibt also sehr viel Unsicherheit und damit Arbeit nur weil RedHat sich nicht mehr für ihr Gewäsch von vor ein paar Monaten interessiert. Das schafft echt Vertrauen bezüglich Vendor lockin... das drängt einem einfach sofort das Gebahren von Oracle ins Gedächtnis und das ist nicht positiv...
 
Zurück
Oben