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.