[Musik]
Hallo und herzlich willkommen zur fünften Folge des Focus on Linux Podcasts.
Und nein, euer Podcast funktioniert ordnungsgemäß.
Wir haben diesmal eine Folge in der Mitte des Monats und nicht zum Monatsende.
Wir haben uns nämlich überlegt, wir probieren mal was, wir machen heute mal ein Experiment.
Und das sowohl thematischer als auch technischer Natur.
Und wir planen jetzt in Zukunft in regelmäßigen Abständen auch zur Mitte des Monats freie Folgen zu veröffentlichen.
Das heißt, da geht es dann nicht um die üblichen News, die ihr schon kennt vom Monatsende,
sondern da überlegen wir uns einfach ein freies Thema, holen uns ein paar Gäste rein und sprechen dann über dieses Thema.
Und heute haben wir auch schon ein sehr spannendes Thema, wie ich finde.
Und zwar reden wir heute über 20 Jahre Red Hat Enterprise Linux.
Das Ganze mache ich natürlich wieder nicht alleine, sondern ich freue mich heute auch wieder ein paar Gäste vorstellen zu können.
Und da wäre zunächst mal der Markus Schreier von Red Hat.
Dankeschön, Christian. Ja, Markus Schreier mein Name.
Ich bin seit acht Jahren bei Red Hat, habe ungefähr 1995 angefangen in der IT.
Bin aber relativ spät erst zu den Open Source angekommen, wie schon erwähnt vor acht Jahren ziemlich genau.
Sehr schön. Super. Dann haben wir auch mit dabei den Thomas Blutauer.
Ja, hallo Christian. Erstmal vielen Dank für die Einladung.
Und ja, auch ich beschäftige mich schon seit über 20 Jahren mit Linux. Red Hat auch mittlerweile müsste es sein.
Und ja, vielen Dank nochmal für die Einladung auf jeden Fall.
Sehr gerne. Ich freue mich schon sehr mit dir, über die Anfänge zu reden.
Du hast dir auch, wie wir festgestellt haben, einen Artikel über Fedora Core 1 geschrieben damals.
Da müssen wir uns auf jeden Fall gleich mal zu austauschen.
Definitiv. Richtige Berühmtheit hat er erlangt.
Genau, richtig. Soviel zu unserem thematischen Experiment.
Jetzt kommen wir zu unserem technischen Experiment, denn unser dritter Gast heute ist niemand Geringes,
als der Enrico Baatz gestern oder vorhin noch in Hamburg jetzt auf der A1 und live zugeschaltet.
Grüß dich.
Moin. Ja, ich habe gedacht, das klappt hier alles wunderbar und habe mir extra genug Pufferzeit eingeplant,
habe aber nicht damit gerechnet, dass uns hier auf A1 zwischendurch eine Vollsperrung ereilt.
Und jetzt stehe ich hier 20 Kilometer vor dem, wo ich eigentlich hin will und bewege mich in Schrittgeschwindigkeit.
Dementsprechend habe ich die Hoffnung, dass ihr als Zuhörer natürlich ein bisschen Nachsicht mit meiner Tonqualität habt.
Mal sehen, wie wir das am Ende zusammenschneiden.
Genau, ja, und das ist mal wieder kaum geht das echte Leben fern ab, das Homeoffice wieder los.
Schon fällt einem auch auf, dass es ja so unangenehme Dinge wie eben Vollsperrungen und Staus gibt.
Und daher Deutschland bekanntlicherweise, was das Internet anbelangt, ein Entwicklungsland leider ist.
Müssen wir gucken, wie wir das technisch hinkriegen. Aber wir sind optimistisch.
Andere Podcasts kriegen das auch hin. Von daher denke ich mal, sind wir ambitioniert und motiviert, das heute auch mit euch hinzukriegen.
Wenn die Tonqualität natürlich zwischendrin mal Hänge haben sollte, wir versuchen das Beste, seht es uns nach, dann könnt ihr das verbuchen, als sie waren stets bemüht.
Aber neben schlechtem Internet ist ja auch das typisch deutsch, sich schon mal vorab für alles zu entschuldigen, was theoretisch hätte schiefgehen können.
Aber ich hoffe, wir kriegen das hin. Aber sag mal, freie Folge heißt das, wir releasen die dann noch unter eine Open Source Lizenz oder?
Das ist ein guter, guter Punkt. Da sollten wir auf jeden Fall eine eigene Lizenz zu machen, die SVA Public License oder so.
Eine neue ist immer gut.
Genau. Also es geht tatsächlich darum, einfach mal über freie Themen zu reden.
Das heißt, liebe Zuhörer, wenn ihr hier Ideen habt an Themen, die ihr hier mal gerne hören möchtet, dann könnt ihr das natürlich sehr gerne uns auch mitteilen.
Wir haben jetzt für die nächsten paar Monate schon einen Backlog aufgebaut, aber sind natürlich immer dankbar für neue Ideen.
Und wenn ihr das tun wollt, dann könnt ihr das ganz einfach per E-Mail an podcast@sva.de oder gerne auch über Social Media, wo wir diese Folge vermutlich auch bewerben werden.
Das wäre dann der Twitter-Händel SVA_FocusOn.
Wir gucken mal, wie es ankommt. Vielleicht gibt es nicht jeden Monat so eine freie Folge, aber geplant ist es auf jeden Fall erst mal.
Gut, so viel zu unseren Gästen und da würde ich vorschlagen, lasst uns doch gleich mal in das Thema einsteigen.
20 Jahre Red Hat Enterprise Linux. Das ist echt eine ganz schön lange Zeit.
Und ich muss zugeben, als ich mich da belesen habe, war ich ein bisschen verwundert, weil mir kam das gar nicht so lange vor, dass es schon so lange Rell gibt.
Aber es sind tatsächlich, es werden jetzt diesen Mai 20 Jahre. Ehrer, wie die Zeit vergeht. Wie hat das denn überhaupt angefangen?
Ich glaube, das ist mein Stichwort. Red Hat selber gegründet 1993. Das war der Mark Ewing.
Der hatte immer eine rote Kappe auf, war Techie und hat auf verschiedenen Veranstaltungen seine eigene Linux-Distribution erstellt, hat die mittels CDs verteilt, verkauft.
Und dann gab es einen zweiten Menschen, den Bob Young, der Computerteile verschifft hat, verkauft hat und eben auch diese Linux-Distribution, die dann immer wieder ausverkauft war.
Und 1995 haben die beiden dann sich zusammengetan und haben Red Hat Software gegründet, wobei der Bob Young da der CEO wurde.
1999 ist, glaube ich, noch ein ganz wichtiges Ereignis. Da ist Red Hat dann an die Börse gegangen.
Und schon 2001 wurde dieses Verkaufen von dem Betriebssystem als Päckchen, was man irgendwie aus dem Regal nehmen kann, eingestellt, obwohl es eigentlich das Flaggschiff war.
Der damalige CEO, der Matthew Salik, das war ein Open Source Enthusiast, ein Open Source Evangelist.
Und der hat damals schon dieses Subscription Modell eingeführt und hat sich dem Open Source sehr, sehr stark verschrieben und das eben auch weit vorangebracht.
Genau. Ich glaube, das reicht als Überblick.
Ja, irre. Ich finde das total interessant, weil Red Hat ja auch eine der ersten Distributionen damals war.
Natürlich gab es noch ein paar, die früher da waren. Also die älteste noch aktive ist ja immer noch Slackware.
Aber 1993 bzw. 1995 ist natürlich echt schon ziemlich früh. Also wir haben ja letztes Jahr auch gerade erst das 30-jährige Jubiläum von Linux gefeiert.
Und total spannend, wie die ganzen Distributionen früher auf diese Kisten gesetzt haben, die man dann verkauft hat, als es halt noch nicht so usus war, sich eben große Isos über das Internet runterzuladen.
Was war denn so für euch der Einstieg in die Red Hat Welt damals?
Gilt das auch mir, die Frage?
Das gilt allen, ja.
Fange ich vielleicht einfach an. Ziemlich spannend. SAP hat damals auch, also das war so Anfang/Mitte der 90er, als meine IT-Karriere anfing.
Und SAP hat da auch irgendwie den Weg von Mainframes in die Linux-Welt vollzogen.
Ich habe das damals gar nicht so überblickt, was da alles passiert, aber die ersten SAP-Installationen, die ich hatte, die waren tatsächlich auf einem Red Hat Linux.
Weil einfach das, das die supportete Plattform war, das hat sich dann relativ schnell geändert.
Dann hat man ganz lange Red Hat im SAP-Umfeld gar nicht mehr gesehen. Heute hat sich das zum Glück wieder gedreht.
Aber das waren so meine ersten Berührungspunkte. Da haben wir dann wirklich sehr manuell noch Hochverfügbarkeit aufgesetzt.
Und solche Dinge, das war eigentlich eine ganz spannende Zeit.
Wie war das bei dir, Thomas?
Ich habe relativ früh angefangen. Ich musste gerade noch mal überlegen, weil ich die erste Linux-Distribution genommen habe.
Ich glaube, das war sogar ein RHEL 7, mit dem ich angefangen habe.
Da kann ich mir noch ganz gut an die Installation erinnern. Das ewige Vorsitzen vor dem Rechner gucken.
Die Werbe-Banner, die da angezeigt wurden, sich anschauen.
Da komme ich auch gleich noch mal zu. Und zwar wurde da immer die Zertifizierung, das Zertifizierungsprogramm angeboten.
Und dann ganz klassisch so einen LAMP-Server aufzusetzen. Das heißt Linux, Apache, MySQL und PAP.
Und den auch konfigurieren, im Kernel, also Module kompilieren und so. Da fing das bei mir eigentlich relativ früh an.
Das war kurz nach der Ausbildung, wo ich da die ersten Schritte mit Red Hat Linux gemacht habe.
Und das hat mich halt ziemlich fasziniert. Deshalb bin ich immer noch bei dem Thema geblieben und immer noch dran.
Und Punkt war halt der Open-Source-Gedanke, der dahinter ist, der mich da auch noch mal sehr stark gefesselt hat.
Und seitdem begleite ich das Thema eigentlich kontinuierlich weiter und nehme das auch immer weiter mit.
Also jede Distribution austesten, ausprobieren, rumspielen. Jedes neue RHEL-Version, die ich da auch mitnehme.
Und da sind meine Erfahrungen immer wieder weiter ausgebaut.
Sehr schön. Du meinst aber glaube ich Red Hat Linux 7, oder?
Ja, genau. Red Hat, etaprassistisch. Red Hat Linux 7.
Ich finde das auch interessant, wie sich so gewisse Taipos auch relativ lange immer noch am Leben halten.
Es ist auch ganz häufig so, wenn irgendwo nach Personal gesucht wird, dass da Red Hat Linux geschrieben wird, statt RHEL.
Oder Red Hat in der alten Schreibweise, wo halt die Leertaste fehlt zwischen dem D und dem H.
Also so manche Sachen, die kriegst du aus den Leuten nicht raus.
Ich habe ja in beiden Sachen Erfahrung. Für mich ist das nicht so wild.
Von daher, genau. Das sind ja bürgerliche Kategorien. Red Hat oder Red Hat in der Preislinux.
Wie war das bei dir damals, Enrico?
Ja, also ich sag mal, ich hab mit Linux im privaten Bereich angefangen.
Da gab's, ich sag mal wenig Red Hat, was man so auf DVDs in Zeitschriften gefunden hat.
Und war eher so bei Debian und Ubuntu anfangs zu Hause, weil ich da einfach Stellen Zugang zu hatte.
Und dann irgendwann habe ich halt das Hobby zum Beruf gemacht und dachte hier Informatik und so.
Das machst du mal jetzt als Ausbildung. Und in größeren Unternehmen findet man halt Enterprise Distribution.
Oder ich hatte dann so die Erfahrung gemacht, dass es da ja manche Enterprise Distribution gibt,
wo es sehr einfach war, auch mal so zumindest damals Bleeding Edge Sachen zu installieren.
Und es gab andere, da war das ein Handstand.
Und deswegen bin ich dann irgendwann auch dann zu Rell gekommen bzw. habe auch mit Fedora CentOS damals
mit verschiedenen Projekten gearbeitet und so Dinge gemacht, die man damals so getan hat.
So Verfügbarkeits, also primary, standby, HA-Systeme gebaut für Datenbanken, für NFS-Server.
Später dann größere Dinge. Ja, aber das waren so die Anfänge.
Ich glaube, das älteste Rell-System, das da so mit bei war oder was mein Einstieg war, war so Rell 5.
Also auch jetzt nicht uralt. Also meine Historie reicht ja keine 20 Jahre zurück.
Aber schon so, dass ich heute echt keine Lust mehr hätte, das nochmal so zu machen, wie das damals war.
Rell 5 ist doch noch fast neu. Ja, je nachdem, wie man fragt.
Du hast doch gerade erst aus dem Support gelaufen vor fünf Jahren.
Ja, kann ich nachempfinden. Das ist bei mir ähnlich. Also ich habe auch als Heranwachsender so mit 15 angefangen, mich mit
Lidding zu beschäftigen, war da zwar schon bei RPM-basierten Distros, war da aber doch eher im grünen statt im roten Lager.
Und habe dann irgendwann privat angefangen, mich mit Debian und Ubuntu habe ich mich näher beschäftigt.
Das war auch so mein Einstieg damals, Ubuntu 5.5.10. Und irgendwann kam dann halt die erste Ausbildung.
Und wie das dann halt so ist, man hat sich zu Hause privat mit Lidding beschäftigt, geht dann eben ins Büro und stellt fest,
oh, das ist ja ein ganz anderes Lidding, mit dem ich da arbeiten muss. Und das hat eben Rell.
Und dann habe ich mich damit beschäftigt. Und damals war aktuell Rell 5, Rell 6 ist vereinzelt ausgerollt worden.
Und ja, dann habe ich mich einfach mit dem Thema beschäftigt, eingelesen, auch so die ersten Schulungen und Zertifizierungen mir eben angeschaut.
Und wie das so ist, manchmal räubt man ja auf in so einem Rechenzentrum und da kommen dann auf einmal Server zum Vorschein,
die man schon längst tot geglaubt hätte. Und in dem Fall war es ein hochproduktiver Webserver,
auf dem irgendeine total wichtige Anwendung lief und die Hardware ist kaputt gegangen.
Und dann kam eines Tages der Chef zu mir und sagte, hier Christian, das ist hier so eine Red Hat-Kiste,
mach doch da mal eine VM draus. Kannst du auch machen hier P2V, dann können wir die Hardware nämlich wegfeuern.
Und dann war das irgend so ein alter Dell PowerEdge 1850, der aus dem letzten Loch Pfiff,
Platte kurz vorm Sterben in eine VM konvertieren ging dann ja auch, dank verschiedener Konvertierung Tools.
Aber es war ein Rell 3.6. Und das lief halt nicht so unter VM-Ware.
Und dann musste ich echt so manuell, habe ich mich sehr, sehr drauf oder sehr darüber gefreut,
dass ich das, was ich im LPG gelernt habe, so manuell machen können, kompilieren, selbst ein Modul übersetzen,
konnte ich dann gewinnbringend einsetzen und habe dann dieses sehr, sehr veraltete und ungepatchte System
dann doch noch mal halbwegs portabel in eine VM konvertieren können.
Quasi IT-Padiativmedizin.
Da muss ich aber sagen, also die Erfahrung, weil ich da so lange dabei bin, das ist ja spannend,
immer wenn ich genauso Herausforderungen hatte oder mal in einem alten System zu arbeiten,
was halt überhaupt nicht mehr supportet ist und irgendwo vergessen wurde und super wichtig ist,
wie du es gerade gesagt hattest, dadurch, dass ich da mehrere Jahre dann immer mit diesem Betriebssystem gearbeitet habe,
auch als sie gerade rausgekommen sind, du hast dich sofort wieder heimisch gefühlt oder irgendwie so zuhause gefühlt quasi.
Weil du hattest die Befehle, du wusstest noch, wie der Aufbau war, das hat sich ins Gehirn so reingebrannt,
dass du das nie wieder vergisst. Also ich glaube, bei einem Retet 3 oder so, Rell 3, würde ich glaube ich auch noch klarkommen
und dann würde eine Erinnerung wieder hochkommen, wie die Maschinen früher konfiguriert wurden und sowas,
weil das hat mich bisher immer begleitet. Also sobald ich auf einem alten System war, wusste ich,
ah okay, warte mal, das läuft ja ganz anders hier. Hier muss noch mal ein bisschen rumtricksen.
Das fand ich immer schon spannend, wenn ich mal so ein altes System vor mich gesetzt bekommen habe, um damit ein bisschen rumzuspielen.
Absolut. Was waren denn da so eure endesten Maschinen, die ihr entweder selbst hattet oder bei Kunden gesehen habt?
Markus, du bist ja auch viel bei Kunden unterwegs und hast da bestimmt auch schon die ein oder andere wilde Leiche gesehen.
Naja, das ist keine Linux-Anekdote. Also ich war bei einer Bundesbehörde, die ich jetzt nicht näher beziffern möchte.
Und da war SCO im Einsatz und die hatten was selbstgebautes.
Leider waren die Entwickler wohl nicht mehr auffindbar oder nicht mehr zugreifbar.
Die hatten also keine Möglichkeit, da wegzukommen. Das war also eine spezifische Applikation, um ihre eigenen Dinge, die sie da verwalten, eben zu verwalten.
Also wirklich eine einmalige Software. Da gibt es auch kein Standard-Tool.
Da kann man keinen SAP einsetzen oder kein Salesforce oder Microsoft 365. Das passte da alles nicht.
Und die wussten also nicht, wie sie da wegkommen. Die haben also von allen alten Rechnern dann einfach die im Lager aufgehoben, um dann nochmal eine Platte irgendwie wiederzuverwenden oder so was.
Und irgendwann wurde das dann in eine VM migriert, wobei VM-Ware dann da nicht so ganz klar kam.
Also der Host, auf dem die VM lief, hatte dann immer 100% Anschlag, weil irgendwie das Eideln oder einfach den Prozessor in einen Stop-Mode setzen, das ging halt irgendwie nicht.
Aber immerhin es lief und wir wurden hardwareunabhängig.
Immerhin ein Problem weniger. Dafür ein anderes dazubekommen, aber wenigstens die Hardware abgelöst.
Wie war das bei dir, Thomas? Was war so das älteste Red Hat, das du irgendwo in freier Wildbahn mal administrieren musstest?
Ich hatte es ja gerade schon erwähnt, dass ich da länger mit unterwegs war. Ich bin gerade überlegen, aber ich habe das ja alles mit aufgebaut.
Ich weiß gar nicht mehr, wann ich wieder auf dieses Thema draufgegangen bin.
Die eher größte Änderung, die ich noch habe, oder die, die mir die Schweißperlen immer noch auf die Stirn bringen, ist, als ich mein Red Hat 3 auf Red Hat 4 updaten musste.
Das war mein erster Einsatz als Konsultant oder als Berater. Schön nach München hingeflogen.
Klassiker, Auto gemietet, Navi, kostet 30 Euro. Nee, das wird zu teuer. Kein Navi genommen, mit Karten losgefahren, natürlich verfahren.
Dann irgendwann mit einer Nacht im Hotel angekommen zum Kunden, den ganzen Tag gefummelt und dann irgendwie kurz vor den letzten Schritten hat das Red Hat gemackert.
Moment, hier gibt es keine zusätzlichen Pakete oder die Pakete können nicht installiert werden, weil die nicht da sind. Da muss ich da auch nochmal schnell gucken.
Und im Hintergrund immer das Flugzeug, was eigentlich quasi schon auf mich gewartet hatte. Das war ein bisschen stressvoll.
Aber das hat mich so ein bisschen geprägt in dem ganzen Thema. Auch das Thema Upgrades vom Betriebssystem und so hat mich da sehr stark beeinflusst.
Was man vielleicht machen sollte und was nicht. Lief aber am Ende. Ich habe es noch hinbekommen. Ich glaube, ich war ziemlich pünktlich am Flughafen.
Vielleicht schon ein paar Minuten, fast zu spät. Aber ich habe den Flug noch nach Hause bekommen. Das war ganz gut.
Und ja, dafür den ersten Einsatz. Da hätte ich auch gerne darauf verzichten können. Aber lief. Also hat funktioniert.
Aber wie gesagt, das waren halt so viele Faktoren, die dann noch mal zwischengespielt haben. Ich glaube, das muss ein Red Hat 3 auf 4 gewesen sein.
Also in der Enterprise Umgebung. Interessant, weil eigentlich machen wir da mit Werbung, dass wir jetzt ein In-Place-Upgrade von 6 auf 7 können und von 7 auf 8.
Und vorher das eben nicht ging. Also du hast da schon das Unmögliche möglich gemacht.
In-Place-Upgrade war es nicht. Also es war wirklich, du konntest ja von den CD's oder DVD's, CD's waren das damals, konntest du ein Offline-Update machen. Das heißt, du hast die CD reingesteckt und dann gesagt, ich will ein Upgrade von dem Betriebssystem machen.
Und dann hat er das halt mit einem Update-Mechanismus aktualisiert und da fehlte dann zum Beispiel ein Repo oder ein Repo gar nicht zur Verfügung oder ist halt stecken geblieben.
Das ging schon lange. Also das hat schon immer funktioniert. Aber jetzt nicht direkt auf dem Betriebssystem, sondern offline mehr oder weniger.
Aber auch das hatte, also das hat mehr oder weniger gut geklappt zu dem Zeitpunkt. Aber da habe ich so meine ersten Erfahrungen da mitgemacht.
Das hat schon immer so funktioniert. Das ist so eine schöne Phrase. Aber am Ende ist es dann doch vielleicht so, dass vieles von dem, was immer funktioniert hat, dann doch zu dem Problem geführt hat.
Also ich bin, auch wenn es Upgrades irgendwie über Distributionen weit geht, klar, also Service Packs und so, easy.
Wenn du eine Major Version wechselst, bin ich immer noch der Meinung, ist eigentlich auch einfach guter Stil, dass wenn man es kann, dass man einfach auch bei einem Clean Install startet, statt die Artefakte der letzten 20 Jahre noch 20 Jahre vor sich herzuschieben.
Und die Backup Files im System zu haben und irgendwie irgendwelche RPM Safe Sachen, weil da der Demon 30 mal das Config Format geändert hat oder so.
Das ist ja, weil es keiner mehr so richtig, woran es jetzt gelegen hat, weißt du.
Ja, das ist ja genau der Punkt. Das heißt, wenn du das eine Update machst, verleitet es sich ja dazu, noch ein zweites zu machen und ein drittes auf dem gleichen System.
Und dann weißt du gar nicht mehr, wie die ursprüngliche Config auszusehen hätte.
Und bist ja nur noch am rumfuschen quasi, dass du das System halt wieder lauffähig bekommst, was überhaupt nichts mehr mit der aktuellen Distribution zu tun hat. Und das ist halt ein paar Mal passiert.
Das habe ich da auch mittlerweile ganz stark von Abrat überhaupt, ein Update zu machen, wie du es gerade erwähnt hast, einfach ein Clean Install.
Ja, aber das ist vielleicht auch einfach das Marketing Versprechen. Guck mal hier, du kannst Upgraden. Und diejenigen, die sagen, Upgraden, das klingt doch jetzt erstmal irgendwie easy.
Dahinter sollte aber stehen, in Klammern, solltest du auch. Also einfach, um einfach seine Systeme clean zu halten.
Ist verlangt.
Ich habe da so zwei Katten. Na ja, klar, natürlich, weil es halt einfach erstmal einfacher klingt.
Aber ich glaube, so auf Dauer hat man dann doch irgendwie Probleme, die man sich da reinzieht, die einfach vielleicht nicht so da wären, wenn man mal sich überlegt hätte, wie installieren wir eigentlich clean?
Was brauchen wir eigentlich tatsächlich wirklich, statt die Sachen immer mitzuschleppen, statt sie eben auch mal neu zu installieren?
Ich glaube immer, wenn man gut in der Lage ist, sein System reproduzierbar neu aufzusetzen, dann sollte man eher den Weg gehen.
Und wenn man es nicht kann, sollte man sich fragen, warum das eigentlich so ist und vielleicht proaktiv was dafür tun, dass man das kann.
Es gibt natürlich Situationen, da geht das nicht. Das ist bei mir das Beispiel für das älteste System.
Ich weiß leider nicht mehr, welche Version es war. Es war definitiv auch Red Hat und es war ein Festplatten im Megabyte Bereich.
Wow.
Der Grund war aber nicht, dass wir irgendwie Anfang oder Ende der 90er unterwegs waren, sondern der Grund ist ein anderer.
Ich habe solche Systeme häufig im Embedded-Bereich gesehen.
Heißt, wenn es um Maschinensteuerung geht und das Beispiel, was mir da im Nacken sitzt, das ist eben etwas, was nicht per P2V einfach auf WMWR gehoben werden konnte,
weil dort Hardware verbaut wurde, die einfach nötig war, um eine Maschine zu steuern.
Und die war nicht klein, sondern da ging es bei einem Stahlwerk um einen Hochofen.
Und da sind das dann halt Systeme, die genau aufeinander abgestimmt sind, wo es keine Treiber irgendwie für die uralten Karten, die es da gibt,
geschweige denn in neuer Hardware überhaupt, was waren das damals, Isar oder so Karten, die da drin waren, die notwendig waren, um einfach so einen Hochofen am Leben zu halten.
Das ist dann natürlich der Bereich, von dem wir, glaube ich, so Sachen wie Never Touch a Running System doch ganz gut kennen,
weil wenn es ausfällt, dann tut das einfach richtig weh und mal eben schnell ein bisschen replacen geht halt auch nicht,
weil da hängt halt auch noch ein Millionen Euro teurer Hochofen hinten dran, der das auch nicht mag, wenn er einfach so replacet wird.
Aber das waren so die Sachen und da so was zu haben und dann eine Festplatte zu haben, die ausfällt im Megabyte-Bereich, wo das noch kein Sata war, sondern hier diese, was waren das, Isar?
Nee, hier die IDE, was waren das? Nee, nach IDE, wo du mehrere Platten ranstecken konntest an so einem Bus, mehr als zwei, nicht Primary und Master.
Scuzzy, das Ganze, also sowas dann. Und wenn du so eine Platte dann versuchst, irgendwo noch gebraucht zu schießen, also da bist du nicht im Bereich, wo du das einfach liegen hast,
sondern irgendwann sind die Platten kaputt und dann bist du halt auch echt nur noch auf gut Glück dabei, bei eBay danach zu suchen,
so wie du, Christian, auf viele von deinen gebrauchten Notebooks dann halt suchst und auf ein Glücksfund hoffst, dass du dir dann doch und alles sicherst, was halt irgendwie geht.
Das ist schon echt verrückt, was in dem Bereich da manchmal so liegt.
Ich wollte gerade sagen, hier so Isar und Scuzzy, was sie hier abtut, das ist ja Hardware, die bei mir im Einsatz ist, tagtäglich, Leute.
Ja klar, also Firewire ist das schnellste, was geht, ne?
Genau, richtig.
Ja.
Aber das ist halt echt, also bei sowas kommt man halt echt ins Schwitzen und ich kann mich nicht daran erinnern, dass das eine schöne Zeit war oder schön war, diese Systeme, wenn sie kaputt waren, wieder zusammen zu flicken.
Klar fühlt sich das gut an, wenn man es geschafft hat, aber ich kann mich, also ich habe bewusst, glaube ich, die Version, die das war, verdrängt.
Ich habe mal mehrere Wochen dafür gebraucht, um Tokenringtreiber zu kompilieren und den in das Linux mit reinzubringen.
Ist doch voll easy, ich verstehe ein Problem gar nicht.
Wow.
Ja, so, meine erste Erfahrung, da hatte ich auch gar keine Ahnung mit Linux und gar keine Erfahrung gesammelt und da fing es halt an, ja, ich will das Netzwerk zum Laufen bekommen, ich will den Rechner ins Netzwerk reinbringen.
Wir hatten tatsächlich noch ein Tokenring, als ich da angefangen hatte.
Das wurde nach und nach abgebaut, aber für den Spielrechner war das ganz gut, um da reinzukommen war auch interessant, aber da kann man schon Zeit rein verbuttern.
Und dann weißt du am Ende nicht mehr, wie es geht oder wie du das gemacht hast oder wie du dahin gekommen bist, aber das Problem hat man heute ja auch noch manchmal.
Ja, dann hast du ja never touch a running system und lässt es einfach stehen.
Ja, war ein Spielsystem das erste, das war ja gerade ganz okay.
Ja, was ich in der Vorbereitung ganz interessant fand auch, wir haben ja gerade so ein bisschen über die Geschichte von Red Hat gesprochen,
dass Red Hat auch einfach durch die vielen Akquisitionen, die es so gab, eben auch intern das Portfolio verbreitet hat und auch Knowledge aufgebaut hat.
Also die Liste ist relativ lang, die kann man sich auf Wikipedia auch durchlesen, wenn ihr da mal Interesse dran habt.
Wir können ja mal so ein paar Highlights rausgreifen. Was ich zum Beispiel total spannend fand, war im Jahr 2000 hat Red Hat eben Cygnus Solutions aufgekauft.
Das ist eine Firma, die hat Support angeboten für den GNU C-Compiler, für den GNU Debugger, für Binutils, also für so diese drei großen Core Pakete kann man sagen.
Schlappe 674 Millionen US Dollar hat das Ganze gekostet.
Drei Jahre später hat man sich eben mit Sistina Software was eingekauft, wo GFS, LVM und der Device Mapper gebaut wurde.
J-Boss ist ein relativ bekanntes Produkt von Red Hat, was ja der Mittelware ist, die auch 420 Millionen gekostet hat und so zieht sich das eigentlich die Jahre über durch.
Also Cluster ist ja auch recht bekannt, also Cluster FS wurde auch gekauft.
Ansible 2015, jetzt ganz aktuell auch Stackrocks, Core OS war vorher ein Thema.
Ja und aktuell ist natürlich auch immer noch das Thema, dass ja 2019 Red Hat selbst dann auch gekauft wurde, nämlich eben für 34 Milliarden US Dollar von IBM.
Das war auf jeden Fall ein sehr spannender Deal. Wie war das so für euch damals, Markus?
Habt ihr da so eine Vorahnung gehabt oder wart ihr genauso überrascht, wie wir das eigentlich waren?
Also ich hatte zumindest keine Vorahnung. Ich habe kurz vor der Veröffentlichung für 125 Euro oder Dollar meine Mitarbeiteraktien verkauft, um dann eine Woche später zu erfahren, dass sie 190 wert waren.
Also ich hatte keine Vorahnung.
Krass.
Aber ansonsten ja, ich glaube aus heutiger Sicht kann man sagen, dass das für beide Firmen von Vorteil war.
Also ich meine, dass IBM sich was dabei gedacht hat, da gehen wir von aus.
Aber wir sind die einzige Firma, die von IBM aufgekauft wurde, die nach wie vor einen CEO hat, also die quasi eigenständig als Firma in der Firma existiert,
wo Produktentscheidungen einfach weitestgehend selbstständig oder selbstständig von uns getroffen werden, wo Personalentscheidungen, die Personalstruktur eine Red Hat eigene Entscheidung ist.
Also insofern sind wir da selbstständig. Ich habe auch nach wie vor einen Red Hat Ausweis und bin Red Hat Mitarbeiter.
Also insofern ist das aus meiner Sicht extrem gut gewesen.
Wir haben jetzt IBM als einen der wichtigsten Partner natürlich, aber wir behandeln ihn oder wir behandeln die IBM wie einen Partner.
Und das ist, glaube ich, auch extrem notwendig.
Ich habe, ich persönlich arbeite mit anderen Hardware-Herstellern zusammen und da war natürlich so eine gewisse Furcht, ob denn die Zusammenarbeit da noch stattfinden wird oder wo da die Reise hingeht.
Aber die Furcht hat sich auch gelegt. Also auch die anderen Partner, die eben teilweise mit IBM konkurrieren an unterschiedlichen Stellen, die sehen diese Gefahr heute nicht mehr.
Und das, glaube ich, ist ein gutes Zeichen.
Absolut, ja. Es ist auch interessant, dass das wirklich intern noch ein Unterschied ist, also dass wirklich dann die Mutterfirma da auch nochmal als Partner wahrgenommen wird.
Das ist, glaube ich, nicht das, was die Leute erwartet hätten. Und es ist auch, glaube ich, nicht das, was so der pöbelnde Mob im Internet ist.
Es gab da ja auch lange wirklich aktive Shitstorms, was man da erwartet hätte.
Von daher, ich denke auch, dass das ein gutes Zeichen ist, so wie du es gerade geschildert hast.
Also es ist wohl so, ich weiß nicht, ich kann da nicht für alles sprechen, aber soweit ich das mitkriege, sind die IBM wird natürlich darauf incentiviert,
Red Hat Produkte zu verkaufen. Und das ist sicherlich für unser Mitbewerb auch von Nachteil.
Aber das macht natürlich Sinn, weil der Gewinn, den Red Hat macht, natürlich auch in den Gewinn reinfließt, den eine IBM am Ende macht.
Aber umgekehrt eben nicht. Also den Gewinn, den eine IBM macht, der hat mit dem Red Hat Anteil nichts zu tun.
Das heißt, unser Sales Team wird nicht darauf incentiviert, IBM Produkte zu verkaufen oder mit anzubieten,
sondern wir werden wirklich nur, wir fokussieren uns ausschließlich auf die Red Hat Produkte und die an den Markt zu bringen.
Und ob wir das zusammen mit IBM oder zusammen mit HPE oder zusammen mit irgendeinem anderen Softwarelieferanten machen,
der eben irgendwie die Applikationen unten drauf liefert, das ist uns überlassen bzw. im Zusammenarbeit mit dem Kunden natürlich wird das definiert.
Da spielt aber IBM keine Rolle oder keine andere wie jeder andere Partner auch.
Ich glaube, es wäre noch mal ein bisschen was anderes gewesen, wenn IBM eine große und weit verbreitete Linux Distribution gehabt hätte.
Du siehst das jetzt sehr aus dem Hardware Bereich, was ich auch verstehe für mich.
Ich bin da so in diesem Software, Middleware und so Containerbereich unterwegs.
Und da hat man schon gemerkt, wo es einfach 100% Überschneidungen gab.
Damals ist IBM Cloud Private bei IBM und das OpenShift bei Red Hat oder wenn es um die Application Server geht, da gab es dann halt 100% Überschneidungen.
Und da hat man schon gemerkt, uiuiui, der Markt ist jetzt erst mal für einen ganz kleinen Moment eingefroren.
Ich hätte gesagt locker ein Jahr, war das für mich so gefühlt zumindest.
Bis sich dann überhaupt rauskristallisiert hat, welches Produkt wird eigentlich jetzt gerade strategisch weitergetrieben oder wo gehen bestimmte Produktzweige halt auch auf, damit nicht einfach die doppelte Arbeit reinfließt.
Und da hat sich dann, ich weiß nicht, das ICP wurde dann abgekündigt und OpenShift war dann die führende Plattform.
Dafür dann eben mit den Applikationsbundles sozusagen.
Da finde ich hat sich sehr viel konsolidiert, was eben auch immer so seine Zeit braucht, wo ich aber im Nachhinein froh drum bin, dass es genau so gelaufen ist, wie es gelaufen ist und sich nicht andere Produkte durchgesetzt haben.
Also da hätte es aus meiner Sicht hätte es auch schlimmer laufen können.
Auf alle Fälle. Aber ich glaube, das war ja genau der Grund, warum Red Hat gekauft wurde, wegen OpenShift.
Also IBM hat mit der IBM Cloud Plattform nicht wirklich ganz vorne mitgespielt.
Und das ist, denke ich, der Hauptgrund, warum IBM Red Hat gekauft hat, weil sie das gerne ändern wollten, weil das auch, denke ich, strategisch extrem wichtig ist, da ganz vorne mit dabei zu sein.
Und man sieht es durchaus auch, dass IBM da schon auftritt, was ja auch wahr ist aus IBM Sicht, dass sie da eben ein Produkt mehr oder die Produkte von Red Hat eben auch in ihrem Portfolio haben.
Und so werden, das ist auch interessant, so werden wir auch wahrgenommen.
Also es gibt große Kunden, die quasi so die Listen abgehen, wie viel Millionen oder wie viel Milliarden Umsatz habe ich mit diesem Dienstleister und da war Red Hat immer zu klein, um mit am Tisch zu sitzen.
Das hat sich jetzt geändert. Also auch da dürfen wir jetzt mitreden.
Und das ist sicherlich auch für Red Hat extrem von Vorteil, weil da einfach wahrgenommen wird, dass da ein gewisses Gewicht dahinter ist.
Das stimmt. Wir können ja mal einen kleinen Überblick geben, über was denn jetzt so die Korrelation ist. Was hat es denn mit dem Red Hat Linux auf sich? Wann kam Red Hat Enterprise Linux mit ins Spiel?
Wir wollen Thomas auch die Möglichkeit geben, über Fedora Core 1 zu reden. Da ist er ja, wie wir gleich erfahren werden, absoluter Profi drin.
Deswegen können wir ja nochmal einen kleinen Blick in die Vergangenheit werfen. Wie war das denn? Wer hat das eigentlich damit angefangen?
Und da muss man sagen, das erste Produkt von Red Hat war ja Red Hat Linux, dass man auch so in Boxen kaufen konnte.
Ich habe hier auch noch eine schöne Red Hat Linux 6.1 Box hier bei mir im Schrank stehen.
Und das war vor allen Dingen damals für Privatanwender*innen gedacht. Das heißt, das wurde 1995 veröffentlicht bis 2003 und wurde dann eben 2003 zugunsten Red Hat Enterprise Linux eingestellt.
Der Zusatz Enterprise hat dann eben verdeutlicht, dass es hier vor allen Dingen um das Business geht.
Und das deckt sich ja auch so ein bisschen mit dem, was Markus gerade sagte. Man wollte halt eben auch einfach bei den Großen mitspielen und wollte halt ein sehr stabiles Produkt für Geschäftskund*innen bauen.
Die Community fand das nicht ganz so gut. Aber der Vorteil war, aus der letzten Red Hat Linux Version damals, das war die Version 9,
da entstand dann eben 2003 Fedora Core 1. Was hat es denn damit so auf sich und was für eine Rolle spielt denn Fedora heute so? Klär uns doch mal auf, Thomas.
Ja, gerne. Genau, also mit der Fedora Version, mit der ersten, Fedora Core 1 hieß sie damals ja noch, war es halt so, dass aus dem Red Hat 9 genau eine freie Version gemacht wurde,
die halt mit dem Namen Red Hat nicht mehr so viel zu tun hatte und auf der Basis genau ein Community Projekt veröffentlicht wurde, was halt zu dem Zeitpunkt noch sehr nah an Red Hat 9 dran war.
Es gab einige Anpassungen, einige Feature-Anpassungen und die Idee war halt Community-technisch das Thema voranzutreiben und die Features, die sich halt so ein bisschen etabliert haben,
auch in die Enterprise-Version mit reinzubringen und die Enterprise-Version damit ein bisschen stabil zu halten. Du hast ja gerade auch schon gesagt,
ich habe gerade noch mal aufs Datum geguckt und tatsächlich mich lange auf diesen Artikel vorbereitet, weil die Beta-Version von der einer Version schon sehr lange da war
und ich schon geahnt habe, wie das finale Produkt aussehen wird, tatsächlich einen Block-Eintrag dazu geschrieben zu dem Zeitpunkt.
Das war, da jetzt in Januar 2004 habe ich das veröffentlicht, sogar ziemlich um Mitternacht, als das Ganze rausgekommen ist und habe da so einen kleinen Überblick gegeben,
was sich da gemacht hat, genau, und auch wie die ganze Installation ist, da bin ich ein bisschen raufgegangen aus der Anwendersicht, was sich geändert hat,
die Logos haben sich geändert, die Software-Pakete geupdatet, also wie das halt früher bei einem normalen Red Hat Update war und habe das auch zusammengefasst,
wie man das wieder so nutzen kann, dass man sich auch wieder MP3s anhören kann und solche Thematiken, wo man sich früher nochmal extra Pakete installieren musste,
damit das überhaupt möglich ist, weil das natürlich nicht als Open Source veröffentlicht wurde. Und genau, das war 2004, wo ich das Ganze geschrieben habe,
dann wurde das Ganze auch auf ProLinux veröffentlicht damals. Auf ProLinux, nur fürs Protokoll. ProLinux ist seit vier Jahren offline, also da merkt man schon, wie lang das her ist.
Und ja, dann habe ich den Artikel halt auch irgendwann wieder vergessen, aber für eine Vorbereitung, ich war froh, dass ich mal so einen Block-Eintrag geschrieben hatte.
Und genau, und dann eben ein paar Jahre später, das muss so acht, neun Jahre später gewesen sein, google ich einfach mal nach meinem Namen, gucke so nach und sehe so,
was man so macht. Ja, wo taucht der denn auf? In dem Buch? Das ist interessant. Und das war die Administration und Installation oder so.
Und da hat der Autor tatsächlich zu dem Zeitpunkt, wo ich diesen Block-Eintrag geschrieben habe und der ist immer nur so zwei, drei Stunden auf der Startseite
ein Screenshot gemacht, um zu zeigen, wie Firefox aussieht. Und durch die OCR-Erkennung bin ich damit in dieses Buch reingekommen und Google hat mich dadurch identifizieren können.
Oder dadurch habe ich diesen Beitrag wiederfinden können, den ich damals geschrieben hatte. Das heißt, als kleiner Mitautor fühle ich mich da jetzt auch verantwortlich.
Das war wirklich, das muss ein Zeitraum von drei bis vier Stunden gewesen sein, wo das Ding veröffentlicht wurde und er so einen Screenshot gemacht hat.
Ist auf jeden Fall spannend. Und genau, dadurch ist so ein kleiner Screenshot, also mit meinem Namen auch, bei der Artikel, der immer mit meinem Namen bezeichnet wurde,
mit in das Buch reingekommen und auch so einen kleinen Überblick gegeben, was das Ganze tut. Und ja, damit bin ich auch in dem Buch erwähnt worden,
obwohl der Autor wahrscheinlich gar nicht weiß, dass es mich gibt. Zu richtigen Zeit, am richtigen Ort gewesen. Du hast mal wieder einen Trendsetter.
Definitiv. Gut vorbereitet. Ich glaube, da saß ich einen halben Monat dran im Artikel, gut erst mal vorzuschreiben, zu gucken, wie er veröffentlicht werden kann. Die Beta-Version tausendmal durchgetestet,
dann in der virtuellen Maschine die Screenshots gemacht, weil anders ging das ja nicht damals. Hat aber funktioniert, war interessant und so stoppert man über seine alten Sachen wieder drüber.
Wir werden auf jeden Fall den Artikel verlinken in den Show Notes und wir haben auch für die Vorbereitung, und wir haben ja auch, bevor diese Podcast-Folge erscheint, haben wir auch noch selbst in unserem SV-Ablok einen Artikel veröffentlicht zu dem Thema "20 Jahre Rell".
Und da habe ich mal die ganzen alten Releases, also auch Red Hat Linux 9, Fedora Core 1, Rell 4 und so mal installiert und Screenshots eben erstellt. Den verlinken wir euch auch.
Da könnt ihr ein bisschen in Nostalgie schwelgen und euch die alten Releases mal angucken mit so einem schönen alten GNOME-Desktop und so.
Genau. Ja, und welche Rolle spielt denn Fedora heutzutage noch? Also das war damals das erste Community-Projekt. Ist das heute immer noch so ein Thema oder hat sich das gewandelt?
Das ist ja aus der Sicht, wie das ja immer noch weiterentwickelt in der Richtung. Das heißt, immer noch da. Die Release-Zyklen sind halt sehr kurz bei Fedora in dem Thema.
Heißt, die haben ja glaube ich jedes halbe Jahr ein neues Release. Mittlerweile bin ich auch nicht mehr so ganz tief in der Fedora-Thematik drin.
Aber das ist ein Punkt, der mich auch als Privatanwender früher schon so ein bisschen gestört hat, weil man relativ häufig seine Betriebssysteme updaten musste.
Ich hatte mal einen Router laufen auf Fedora Core zu Hause und musste halt jedes Jahr mal dran, um ein Update zu machen.
Da lief wieder die Hälfte nicht. Das, was Enrico vorhin erwähnt hatte, dass man da wieder neue Treiber kompilieren musste.
Ich hatte glaube ich sogar mal eine ISDN-Karte dranhängen und da musste ich das halbe System austauschen, damit das überhaupt wieder lief.
Bis ich da dann irgendwann so ein bisschen abgewandelt bin. Also wie gesagt als Server ist es eher uncool, aber ich glaube als Desktop hat sich es glaube ich etabliert bei einigen Leuten.
Oder Kollegen, die ich halt kenne, scheint auch stabiler geworden zu sein. Aber das waren so die Punkte, wo ich da mit dem Fedora zu tun gehabt habe.
Ich weiß nicht, Christian, ob du momentan noch in dem Thema drin bist, ob du die aktuellen Versionen gerade noch auf dem Schirm hast?
Tatsächlich ja. Also bei uns ist es ja auch so, wir haben ja intern die Kollegen und Kolleginnen können ja an Betriebssysteme einsetzen, was sie für richtig halten.
Das heißt, man kann ein Windows-Rechner bekommen, man kann aber auch einfach auf dem Rechner direkt Linux installieren.
Und wir haben tatsächlich in der ganzen SVA circa so 30-40 Leute, die eben Linux auf dem Desktop einsetzen.
Und da bin ich auch natürlich immer mit dabei und schaue mir an, dass der VPN-Kline auf den aktuellen Distries eben funktioniert.
Und wir berichten ja auch immer in dem Podcast über die neuen Distributionen und die teste ich dann auch immer.
Und jetzt warte ich auch auf die neue Fedora 36-Version, die jetzt ja eigentlich schon zweimal rauskommen sollte und jetzt aber für nochmal eine Woche verschoben wurde.
Da bin ich auf jeden Fall auch mal gespannt und ja, finde ich es schön.
Also es ist ja wirklich so, dass bis heute Red Hat immer noch der größte Sponsor von Fedora ist.
Also ich meine, der Name und das Logo von Red Hat ist ja nicht von der Hand zu weisen, dass es da einen kausalen Zusammenhang zu geben scheint.
Und was ich halt auch gut finde, dass es gibt natürlich bei so einem Open Source Projekt trotzdem eine Management Board.
Und da sind die Red Hat Angestellten eben in der Minderheit.
Also es ist wirklich ein Community Projekt. Red Hat unterstützt das. Red Hat profitiert auch davon, weil ja das Rell eben auch maßgeblich von den Features profitiert.
Aber das ist ein reines Community-Ding. Also wenn die Community der Meinung ist, wir feuern jetzt System D raus und nehmen keine Ahnung Open, RC oder was auch immer, dann könnte man das tun, theoretisch.
Also schon eine feine Sache.
Wie ist denn das mit den Updates momentan? Ist das besser geworden?
Ich muss zugeben, so Upgrades bin ich auch kein Freund von. Also wie ihr vorhin schon schon sagtet, lieber ehrlich neu installieren.
Also ich würde mir lieber den Installationsprozess automatisieren als Upgrades zu fahren.
Hab mal, ja ich hab von der 34 auf die 35 geupgradet oder so. Hab mir auch die Betas angeschaut und muss zugeben, die Betas sind eigentlich immer schon relativ stabil nutzbar.
Aber so eine Upgrade Org von mehreren Releases habe ich jetzt noch nicht gemacht.
Ich hatte mir mal überlegt, ob ich mal so ein Upgrade Marathon machen sollte, irgendwie Fedora 18 und dann hoch auf die 36.
Aber so hart war meine Langeweile am Wochenende dann doch nicht. Deswegen habe ich die Idee dann wieder verworfen.
Du wärst ja ein paar Stunden unterwegs, ne?
Ja, auf jeden Fall.
Also ich habe durchaus Kollegen, die auf ihrem Notebook eben auch mit Fedora arbeiten, einfach als ihr Arbeitsnotebook.
Und das scheint relativ reibungslos zu funktionieren. Ich selber bin da ein bisschen konservativ. Eben auch ob der Update und ob der Tatsache,
dass ich dann eventuell beim Kunden gerade nicht in der Lage bin, das zu tun, was ich tun will, das ist mir zu risikoreich.
Aber ich weiß, dass es Leute gibt und wie eben schon erwähnt wurde, ja Fedora ist natürlich das Upstream Projekt von Red Hat Enterprise Linux.
Insofern ist das für Red Hat extrem wichtig und letztendlich kann man in Fedora sehen oder daraus ahnen, was dann in dem nächsten Rell-Release vorhanden sein könnte.
Das passt nicht eins zu eins, aber so die Richtung ist auf alle Fälle erkennbar.
Absolut. Also zum Beispiel auch DNF war ja schon seit vielen Fedora Versionen drin. Das konnte man sich schon mal anschauen.
Und deswegen war man dann nicht mehr so ganz vor den Kopf gestoßen, wenn man dann auf einmal sieht, dass eben der Paketmanager jetzt eine andere ist.
Man konnte damit schon mal ein bisschen rumspielen. Manche Ideen kommen dann doch nicht in die Enterprise Version rein.
Also es gab auch mal so ein, ich habe jetzt den Namen auch wieder vergessen, so ein Storage Management Layer, so eine CLI, die dann halt eben für dich das ganze LVM und File System Management machen sollte.
Aber das war jetzt nicht so von Erfolg gekrönt, glaube ich. Das ist dann gar nicht reingekommen. Aber dafür macht man das ja.
Da wird man einfach mal ein bisschen experimentieren kann.
Was ich schon immer mal wissen wollte, wenn jetzt jemand bei Red Hat anfängt und jetzt keine Sonderwünsche hat, kriegt man dann erst mal so ein Thinkpad mit Fedora hingestellt oder wie muss ich mir das vorstellen?
Also als ich angefangen hatte, hatte ich zwei Möglichkeiten. Entweder ein Thinkpad mit einem eigenen sogenannten CSB Computer Standard Bild.
Das war letztendlich ein Rell, vorgefertigt von unserer IT-Abteilung. Das war die eine Möglichkeit.
Die zweite Möglichkeit wäre ein MacBook gewesen, wobei mein Manager mir sehr deutlich gesagt hat, dass als SA ja eigentlich nur ein Linux-System infrage kam, was ich dann auch gefolgsam gewählt habe.
Also insofern ja, die meisten kriegen ein Linux-System. Wir haben auch Kollegen, die dann eher im Backoffice sind.
Die können auch ein Windows-System wählen. Die sind aber in der Minderheit.
Also ich kenne genau von allen Red Hat Kollegen, die ich kenne, kenne ich genau einen, der ein Windows-System hat.
Genau einer, der es über die Probezeit geschaffte.
Aber es gibt sehr viele, und das muss ich schon auch gestehen, die ein MacBook haben. Also ich gehöre da mittlerweile auch dazu.
Und das ist aber dann so eine Fragestellung. Also es gibt innerhalb meiner Kollegin dann eher so wirklich einen Entwicklungsbereich, die das nicht nachvollziehen können, warum ich ein MacBook habe.
Ich selber brauche halt die Kompatibilität zu meinen Kunden und zu meinen Partnern und habe das deswegen so gewählt.
Da ist doch bestimmt ein Red Hat drauf, oder?
Lass uns das erinnern.
Der Desktop-Hintergrund, der läuft.
Der Desktop-Hintergrund, schön mit dem Red Hat-Lokomotor.
Ja, das ist manchmal nicht so einfach. Also ich bin da auch kein Freund von Schwarz- oder Weißmalen, weil es ist halt einfach nicht so einfach.
Klar könnte man für alles Linux benutzen und ich habe das auch lange mitgemacht, dass ich halt eben lange auf proprietäre Tools angewiesen war.
Also ich meine, wer kennt das nicht? Man hat irgendwelche Corporate-Vorlagen, wenn man Kundendokumentationen erstellt.
Und dann schickt dir ein Kunde irgendein Excel-Sheet, irgendeine Wörtertei und da ist dann noch irgendwas dran.
Und dann wird das zerschossen, wenn du das in LibreOffice aufmachst. Oder es wird nicht zerschossen, du schickst es zurück, aber dann wird es beim Kunden zerschossen.
Das ist halt alles eine fürchterliche Baustelle. Das ist nicht das Problem oder nicht das Verschulden der Open-Source-Szene, sondern hat eben eher der Anbieter von proprietären Tools.
Aber man muss halt auch mit den Leuten spielen können. Also man geht ja nicht seinem Job nach, weil man einfach nur mit der Technik arbeiten will, sondern man will damit ja auch Geld erwirtschaften.
Und das heißt natürlich auch, man will in einer absehbaren Zeit auch irgendwie diesen ganzen Dokumentations-Wirbar hinter sich bringen.
Also ist alles nicht so einfach. Da könnten wir, glaube ich, mal eine Sonderepisode zu machen. Linux auf dem Desktop, eben beruflichen Kontext.
Was funktioniert, was funktioniert nicht? Ich glaube, das ist ein sehr umfangreiches Thema.
Ich glaube, als Schlusswort kannst du dazu sagen, do whatever works for you.
Also das Tool, was du am besten beherrschst, sollte eben das sein, was du für deine Arbeitszwecke verwendest.
Und wenn du halt den Tourist-Tag auf dem Windows ganz gut unter Kontrolle hast und damit halt produktiv arbeiten kannst, dann ist das genauso okay.
Wie jemand sagt, guck mal, ich hab hier, ich hab nicht mal eine GUI, ich hab das alles hier auf dem Terminal. Das läuft für mich.
Ist doch okay. Wenn du dein Werkzeug unter Kontrolle hast und damit genau das machen kannst, was du brauchst, um Wertschöpfung zu schaffen, ist das doch völlig wertfrei.
Und wird natürlich irgendwann eingeschränkt, wenn je größer das Team wird, dass man da kompatibel zueinander sein möchte.
Da muss man vielleicht ein bisschen mehr Aufwand treiben. Aber ansonsten, weiß ich nicht, ich nehme ja auch nicht aus dem Baumarkt das Werkzeug,
mit dem ich mich gar nicht auskenne und versuche mit der Flex irgendwie eine Schraube rein zu drehen. Klappt halt nicht, ja.
Ja, absolut. Das ist richtig. Also ich hab's ganz einfach eliminieren können.
Ich hab halt eben einfach meine Dokumentation nicht mehr in einem "what you see is what you get" gebaut, sondern ich hab dafür jetzt Askidoggen, Markedown und Deal with it.
Aber ich denke, du hast das. Und mit dem WI hoffentlich. Natürlich.
Ja, schön wäre auch, wenn du einfach sagen würdest, hey, statt das jetzt so zu machen, hast du den Workaround gefunden, du arbeitest einfach nicht mehr. Frührente.
Genau, ich schreib einfach keine Doku mehr, weil das ist ja auch ein Wiederverkaufswert, den man damit fördert.
Ja. Nee, Quatsch. Gut. Lasst uns mal kurz so ein bisschen über die Versionshighlights schauen.
Also jetzt haben wir so ein bisschen Überblick gehabt, woher das Ganze kommt. Und ich hab mal so ein bisschen zusammengetragen oder wir haben zusammengetragen, was denn so die Highlights der Version waren.
Wir müssen ja nicht auf alles so im Detail eingehen. Dafür haben wir ja, wie gesagt, auch den Blogpost, den wir nochmal verlinken werden für die Zuhörenden in den Show Notes.
Aber den Anfang hat der gemacht, Rell 2.1. Und das wurde eben von 2002 bis 2005 vermarktet.
Steht hier. Sieben Jahre Support gab es, also nochmal zwei Jahre und top.
Kam mit dem GNOME 1.4er Desktop und war das erste Rell mit dem X3-Datalsystem, was schon journaling konnte.
Das war wirklich ein Highlight, weil X2, gerade wenn man so ein Notebook hatte, wo der Akku auch gerne mal ausgefallen ist, da hat man sich gerne, glaube ich, schon mal was zerschossen.
Aber Berühmspunkte hatte ich damit nie und ich hab auch keine ISO mehr gefunden, um sich das mal anzugucken.
Also das ist jetzt wirklich schon so alt, da gibt es nicht mal mehr historische ISOs irgendwo im Internet.
Das Problem hab ich momentan tatsächlich auch schon ein paar Mal gehabt. Bis wohin bist du denn gekommen bei den ISOs?
Also ich hab eine Rell 3 ISO hab ich noch rumliegen.
Rumliegen oder gefunden? Die Netz verschwinden die.
Das gab irgendwo so ein Mehror von irgendeiner Uni und die haben in irgendeinem Unterordner irgendwie ihr Backup von alten ISOs nicht gelöscht und das hat Google indexiert.
Und dann hab ich dann halt so einen schönen Mehror von alten Red Hat ISOs gefunden. Hab ich mir mal gezogen, sicherheitshalber.
Sehr schön. Ja, ich hatte keine Ahnung, ich hatte mal eine alte Version gesucht und die ja auch partout nicht gefunden, so wie du mit 2.1 jetzt gerade.
Und ja, das ist schade, historisch gesehen, dass man da nur noch ganz schwierig rankommt.
Absolut, ja. Aber irgendwann muss man dann auch mal die Vergangenheit Vergangenheit sein lassen. Das muss ich mir dann auch eingestehen.
Ja. 2003 kam dann auch schon Rell 3 raus. Da hatte ich ja auch mal wirklich kurze Bührungspunkte mit gehabt mit diesem kleinen Experiment mit dem alten Rell 3.6 Server.
Das wurde bis 2007 vermarktet. Es gab dann insgesamt und das war auch schon wieder ein Highlight bis zu 11 Jahre Support.
Da gab es nämlich schon den ELP, den ich glaube, das war Extended Lifecycle Support müsste das heißen.
Und mittlerweile sind wir ja bei 13 Jahren und ich glaube, das wird auch relativ häufig genutzt, Markus, oder?
Also diese Kunden, die es nicht schaffen, nach den zehn Jahren wirklich Systeme abzulösen, die gibt es ja wirklich da draußen, oder?
Ja, die gibt es und nicht zu wenig. Und da gibt es auch immer viele Gründe.
Ganz häufig ist es so, dass die Kunden vielen Regulatorien unterliegen und dann irgendwelche Audit-Dämonen auf dieser Version irgendwie unterwegs sind.
Und dann dauert es eben, bis der Hersteller dieser Software eben einen neuen Demon bereitstellt für die neue Rell-Version.
Und so gibt es einfach extrem viele Abhängigkeiten, bevor die überhaupt loslegen können, ein neues Standardbild zu bauen.
Und dann ist der Prozess, bis dieser Standardbild eben einfach ausgerollt ist und getestet ist und so weiter, der ist dann einfach lang.
Und insofern schaffen das die Kunden tatsächlich nicht immer ganz plump könnte man sagen, na ja, musste deine Prozesse optimieren.
Aber letztendlich, die Realität sieht anders aus. Und die Kunden, an die ich da so denke, das sind jetzt keine kleinen Kunden.
Und das sind auch keine Kunden, denen ich unterstellen würde, dass sie ihre Prozesse nicht im Griff haben. Das würde ich mich nicht trauen.
Also das ist durchaus eine Notwendigkeit auf alle Fälle. Es hat auch was mit Planungssicherheit zu tun.
Da haben wir uns ja auch jetzt noch mit Rell 8 neu aufgestellt, dass wir eben auch definierte Zyklen rausdefiniert haben, dass wir alle drei Jahre einen Major Release rausgeben.
Das geht alles in Richtung Planungssicherheit und bietet natürlich auch dem Kunden die Chance, so zu planen, dass er eben nicht in den external lifecycle support laufen muss.
Absolut. Und ich meine, man würde sowas ja nicht anbieten, wenn es da kein Need für gäbe.
Also diese Kunden gibt es eben, die sehr lange Projektlaufzeiten haben und dann kann man das gegen extra Münzen nochmal verlängern um drei Jahre.
Es ist auf jeden Fall nett, dass es da mit Rell 3 schon elf Jahre waren und war auch die erste Version mit SATA-Support, haben wir hier aufgeschrieben.
Und Thomas hat hier notiert, auch später gab es iSCSI, LVM und Software-Rate. Und da hast du irgendwie auch schon Bürgungspunkte mit gehabt damals, oder? Wie war das?
Genau, iSCSI viel mit gespielt. Ich glaube, das war aber noch in der späteren Version, wo ich SCSI-Features, SCSI-3 Reservations für SAP-Systeme brauche, die ich mit iSCSI nachgebildet habe, weil das anders nicht ging, weil das virtuelle Maschinen waren.
Und sich damit komplette Demo-Umgebung aufbauen konnte für eine SAP-Umgebung, die ich quasi virtuell gefaked habe, um bestimmte Use-Cases abzubilden und damit später auch zusammen mit der RETTA zum Beispiel ziemlich komplexe HA-Funktionalitäten mit abzubilden und zu entwickeln.
War auf jeden Fall spannend und die Features haben einem halt weitergeholfen, um sehr spezielle Use-Cases, muss man schon sagen, abzubilden, die so nicht machbar wären.
Und war sehr interessant, wie tief man da in die SCSI-Thematiken reinkommen konnte und was man da gerade auch mit iSCSI sehr gut abbilden konnte.
Das heißt, du kannst die ganzen SCSI-Commandos, die wie SCSI-STOP, die kannst du alle auswendig noch, kannst du fließend sprechen?
Quasi, ja. Ich nagel mich jetzt nicht drauf fest, aber...
Thomas kann dich so nicht nur E-Mails per SMTP schicken, der kann auch iSCSI per TANIT.
Wow.
Nein, so schlimm ist dann auch wieder...
Spannend. Ja.
Und es hat auch gar nicht lange gedauert. 2005 kam dann auch schon REL4 raus. Also diese Planungssicherheit, die Markus gerade besprochen hat.
Früher gab es ja doch mal Schwankungen zwischen den Releases, wenn wir da mal so durchgucken.
Aber es ist jetzt ja ab REL8 dann doch deutlich vorhersehbarer geworden.
Aber bei REL4 ging es auch relativ schnell. Da gab es dann auch jetzt zwölf Jahre Support in Summe.
Und was für mich so ein bisschen das Highlight war, das war die erste Version, die mit SE Linux kam.
Und das ist ja, wenn man sich mit Leuten unterhält, die Red Hat administrieren, gibt es ja die, die sagen, SE Linux, ja super, hat mir schon ein paar Mal irgendwie den Arsch gerettet.
Und es gibt die Leute, die sagen, das erste, was ich mache, ist, dass ich SE Linux ausschalte.
Genau diese beiden Lager kannst du, glaube ich, den Leuten einkategorisieren.
Also das war schon recht früh mit drin, das wusste ich gar nicht. Ich dachte, das wäre erst so mit REL6 oder REL5 reingekommen.
Aber das war tatsächlich schon in REL4 mit drin.
Das war früh dabei, aber das war das erste, was du halt gemacht hast, deaktivieren.
Weil das war halt noch lange nicht so weit, dass halt alles lief, wenn du es aktiviert hast.
Das sieht mittlerweile anders aus, das muss man auch sagen.
Aber zu dem Zeitpunkt wusste keiner, wie es funktioniert.
Zweitens war es dann ein komplett neues Feature. Und das hatte ich zu dem Zeitpunkt bei der Arbeit so ein bisschen gehindert.
Du wolltest ja deine Sachen erst mal laufen lassen, du musst erst mal lernen, wie du überhaupt die Systeme konfigurierst.
Und dann denkst du, du hast alles richtig konfiguriert, aber das lief trotzdem nicht.
Und dann irgendwann schaltest du SE Linux aus, dann lief es doch.
War ein holpriger Start, sag ich mal so.
Es hat ein bisschen gedauert, aber mittlerweile, und wenn man da ein paar Mal ein bisschen mitgearbeitet hatte, funktioniert es sehr gut mittlerweile.
Das muss man sagen, weil es auch ausgearbeitet ist. Man hat halt sehr viel mittlerweile mit integriert.
Und lernen muss man es ja auch durch die ganze Schulung, die ich damit gemacht habe.
Oder Prüfung, die ich gemacht habe, da musste ich auch mit beschäftigen.
Und die minimalen Konfigurationen lernen, um die Schulung zu bestehen.
Um dann mit den anderen Sachen zu kämpfen. Damit musste man sich dann gezwungenermaßen doch beschäftigen.
Ich finde das eigentlich auch ein ganz netter Slogan, es zu sagen.
Applikationen vom Starten abhalten, das können wir schon seit 2005.
Wie sieht das bei dir eigentlich aus? Bist du auch so ein SE-Linungsdeaktivierer, Enrico, oder hältst du das prinzipiell für eine gute Sache?
Ja nee, permisse reicht mir schon.
Je nachdem wo du deine Systeme hochfährst, ob du die vorkonfektioniert kriegst oder nicht, bist du vielleicht gewöhnt, dass du Systeme mit einer deaktivierten Firewall und permissive SE-Linungsbekommenst.
Und wenn du das erste Mal von scratch so eine Kiste installierst und merkst, wieso geht das nicht?
TELNET Local Host klappt doch alles, wieso komme ich hier nicht Firewall-mäßig ran, was ist denn das alles?
Wieso geht denn das SSH nicht durch? Hä, kein Ping ist was mit meinem Netzwerk kaputt? Nee, ist halt die Firewall.
Gut, ist natürlich auch immer so, dass sich hier zwischen den Versionen die Firewall-Tools, oder zumindest die Interfaces zu den Firewall-Modulen geändert hat.
Und dasselbe ist dann eben auch für SE-Linux. Du kommst im Zweifel von einer anderen Distro, denkst dir da ja ob Patchy installieren, mal eben kurz eine neue Vhost-Configuration,
und meine Files liegen halt nicht unter www.html, sondern unter /data/webseitenname irgendwas und wunders sich dann, dass das halt nicht geht.
Ich glaube gerade die, die von anderen Distros kommen und dann mal eine Standardinstallation durchziehen,
denen wird da halt einfach was zwischen die Beine geworfen, wo sie vorher noch nicht mal wussten, dass es das halt gibt.
Und da ist man dann schnell irritiert und möchte eigentlich zu seinem Ziel kommen, sein Use-Case oder seine Applikation oder whatever zum Laufen zu bringen.
Und das ist dann häufig auch gerade deswegen wird es deaktiviert, weil du nicht weißt, was es ist.
Das hält dich vom Arbeiten ab, also warum soll ich irgendwas nehmen, was mich vom Arbeiten abhält.
Und da muss man halt dann aber vielleicht mal drauf eingehen sagen, guck mal.
Übrigens, es gibt eine schöne MOTD, die sagt hier auf diesem System ist eine Firewall und ein SE-Linux aktiv.
Hier gibt es das 2 Minuten YouTube-Video, was dir erklärt, wie du das für deine Zwecke nutzt und nicht das gegen dich spielen lässt.
Kannst aber auch viel umfuschen mit das SE-Linux.
Also ich hatte mal ein Projekt gehabt, da habe ich einen Browser über das SE-Linux so abgeschnitten, dass der halt nur auf eine IP-Adresse zugreifen durfte.
Du kannst ziemlich viele Schweinereien damit machen.
Also es ist sehr machtmächtig.
Damit kommen wir wieder zu dem Satz, den ich in der Pre-Show schon hatte und damit gehen Props raus an Florian.
"Gut gefuscht ist keine schlechte Arbeit."
Ist was dran, ja. Also ich finde, das ist aber auch besser geworden.
Also ich kann mich dran erinnern, ich war damals auch so Team SE-Linux abdrehen, bis ich es mal verstanden habe.
Ich war dann auf einer Konferenz, wo auch jemand einen Vortrag zu dem Thema gehalten hat.
Und es gibt ja bei Red Hat auch den Dan Welsh, der ja auch sehr viel Communityarbeit da investiert.
Der hat zum Beispiel das SE-Linux-Colorbook rausgebracht, wo man als Erwachsener Katzen ausmalen kann.
Und somit da dann quasi auch den SE-Linux-Part lernt und weiß, dass die Katze das Hundefutter nicht essen darf.
Und umgekehrt, weil die Flex das verhindert und so.
Das ist sehr, sehr marketingtechnisch sehr, sehr gut umgesetzt.
Und ich weiß noch, früher musste man wirklich sehr viel selbst rumbassen und kompilieren.
Also was du gerade sagtest hier, Webseite liegt in /data/standarduse-case.
Da bin ich auch reingefallen, habe mir selbst Module kompiliert und hast nicht gesehen.
Und mittlerweile ist es einfach mit einem File-Type einfach getan, den du setzt.
Das definierst du einmal und dann ist es rekursiv für die Dateien drin.
Das ist schon besser geworden.
Und was mich mal interessieren würde, du bist ja auch viel im Sub-Kontext unterwegs, Markus.
Ich weiß noch, früher als ich Linux-Admin war für eine Sub-Landschaft,
da war Sub- und LC-Linux auch immer so ein sehr leidiges Thema.
Ist das denn immer noch so oder ist das besser geworden?
Das ist sehr viel besser geworden.
Also einerseits technisch funktioniert hat das dann schon eine ganze Weile.
Meine Kollegen in Walldorf oder um genauer zu sein in St. Leon Roth
haben da viel investiert und viel Engineering-Aufwand reingesteckt, damit das auch funktioniert.
Der eben erwähnte Permissive Mode, das noch so am Rande, der hilft natürlich auch extrem weiter.
Das heißt, ich kriege dadurch ein sehr gutes Logging, ohne dass ich irgendwo eine Funktionalität eingegrenzt habe.
Ich kann quasi in so einem Modus, in dem nichts kaputt geht oder in dem noch alles funktioniert,
eben sicherstellen, dass meine LC-Linux-Konfiguration richtig eingerichtet ist.
Und dann kann ich jetzt auf Enforcing schalten.
Also insofern, wenn man ein gescheites Handling dafür hat, eine gescheite Art mit SELinux umzugehen,
dann wird man dem auch her und die Logfiles, die helfen extrem.
Die sagen mir, wenn SELinux irgendwo zugeschlagen hat und dann kann ich das auch abstellen.
Am Anfang April, also gar nicht so lange her, hat mein Kollege Riccardo eben auch einen Artikel zu SELinux und Sapana geschrieben.
Also insofern zieht das jetzt auch offiziell in diese Welt ein.
Da hatte, glaube ich, der SAP Support genau so eine Situation erlebt, wie ihr sie gerade geschildert habt,
dass er sich eben nicht so gut auskannte.
Und da eben die Funktionalität am Ende des Tages auch wichtig ist, war das eben lange Zeit gar nicht supported.
Mittlerweile ist es supported, mittlerweile kennen sich wahrscheinlich auch genügend Leute damit aus.
Und man muss auch wirklich mal festhalten, das kann wirklich sehr, sehr helfen, wenn es um Security geht.
Also es ist kein Mythos, es ist wirklich so.
In meinem ersten Job hatte ich auch Web-Server unter meiner Verantwortung, die in der DMZ standen.
Und irgendeine Applikation sollte auf dem System installiert werden, die halt partout nicht mit SELinux zu betreiben war,
weil die Anwendung einfach short war.
Man muss es wirklich mal so sagen, wie es auch war.
Und wie das so ist, ich habe natürlich gesagt, nö, SELinux werde ich nicht deaktivieren, das ist eine potentielle schlechte Anwendung.
Ich sehe da Gefahr, dass das ausgenutzt wird.
Und das ist natürlich passiert, was passieren musste.
Das Ganze wurde zum Chef eskaliert, Chef sagte, na komm, mach halt mal, wir gucken es uns an.
Und das hat keinen Tag gedauert und dann war der Web-Server gehackt und wurde für Spam missbraucht.
Und dann meinte ich wirklich so, ich habe es euch doch gesagt.
Ich weiß, das sagt man nicht und das ist auch nicht wirklich sehr zielfördernd, in so einer Diskussion Tollchozo als Argument in den Ring zu werfen.
Aber es war halt so vorhersehbar und es ist halt wie erwartet eingetreten.
Und da muss ich sagen, seitdem schätze ich SELinux wirklich sehr, weil es einfach diese Art von Angriffe vorher sehr vehement verhindert hat.
Und kaum hat man es deaktiviert, weil die Kiste auf einmal offen.
Einschränken, also beschränkt halt sehr viel ein, dass solche Angriffe nicht weiter ausarbeiten kannst, auch wenn es Lücken gibt.
Und das fand ich halt bei SELinux auch immer sehr faszinierend.
Also es ist ein super Tool aus der Sicht.
Das ist halt, erstmal, du musst es einmal verstehen und wenn das der Fall ist, wie du es gerade gesagt hast, klappt das.
Ich hatte es gerade gesagt, wie stark man Applikationen einschränken kann, wenn man eigene Plugins-Module, heißt es da, glaube ich, schreibt.
Also es ist sehr viel möglich, aber du musst halt jemanden haben, der sich damit auskennt und das Konzept verstehen.
Und da muss man einmal durch, leider.
Genau. Und dieses Coloring Book, was du Christian eben angesprochen hast, ich sehe das gar nicht so sehr als Marketing.
Ich sehe das tatsächlich als ein Buch, was mir erklärt, wie das funktioniert.
Wenn ich das Prinzip einmal verstanden habe, dann kann ich damit auch umgehen.
Also das ist wirklich eine sehr leicht zugängliche, aber sehr lesenswerte Lektüre.
Absolut. Ich freue mich ja immer, wenn irgendwo Katzenbilder drauf sind.
Also viele wissen ja auch, ich bin ja bei der SVA nebenberuflich auch Entschuldigungsbeauftragter.
Also wir bieten ja auch Schulungen zum Thema Internet und Memes an.
Und da muss ich natürlich immer, wenn ich irgendwo Katzen sehe, dann freue ich mich da immer sehr drüber.
Gut, 2007 kam auch schon die nächste Version raus.
Das war eben REL5. Das war für mich so der Einstieg ins professionelle Berufsleben, kann man sagen.
Da habe ich auch viel mit REL5 zu tun gehabt. Das wurde zehn Jahre lang vermarktet.
Und war die erste Distribution, die jetzt auch schon 13 Jahre ELS eben hatte, den Extended Lifecycle Support, über den wir ja schon gesprochen haben.
Und was ich überhaupt nicht mehr auf dem Radar hatte, das war die erste Version mit Yam statt Up-to-Date.
Also Up-to-Date war ja lange der Standard-Paket-Manager. Und ja, den konnte man mögen oder man konnte ihn nicht mögen.
Ich fand den nicht ganz so knorke. Und Yam war jetzt eben das Tool, das uns ja dann auch bis heute noch begleitet in angepasster Version.
Und kam das nicht sogar eigentlich von Yellow Dog, also dieser Distribution für die PlayStation.
Deswegen auch der Name Yam. Ist doch Yellow Dog Update Manager. Genau, Yellow Dog Update Manager. Tatsache.
Hast du mit Up-to-Date gearbeitet?
Ich habe nie mit Up-to-Date großartig zu tun gehabt. Ich habe mal irgendwo eine REL3, REL4-Kiste gesehen.
Habe halt gesehen, die Repos waren alle nicht mehr verfügbar. Und dann hat das Experiment für mich auch an der Stelle geendet.
Ich weiß nicht, wie es bei euch aussieht.
Das ging ja früher nicht anders, ne?
Du hast früher eher von DVD installiert. Also wie gesagt, das Internet war da noch nicht ganz so ausgebaut.
Und da musstest du die DVD-Images mal einbinden und darüber installieren.
Ich kann mich aber auch gar nicht mehr so richtig dran erinnern, wie ich Up-to-Date installieren konfiguriert habe.
Da hat Yam einen viel Arbeit umgenommen.
Absolut. Es hat es einfach so viel einfacher gemacht. Das ganze Repo-Management ist einfach viel besser geworden.
Und ist ja auch bis REL7 auch drin gewesen. Mit REL8 kam jetzt eben der Nachfolgednf mit rein, der aber auch abwärtskompatibel ist.
Das heißt, man hat einfach ein Symbol gemacht oder in ein Hartlink von Yam auf DNF und dann merkt man keinen Unterschied.
Das sind so ein bisschen aus der Kategorie der Geschichten aus längst vergangenen Zeiten.
Also Dinge, wenn man heute erzählt, damals gab es kein Internet, dann kann sich das glaube ich die aktuelle Generation der Administrierenden auch nicht vorstellen,
dass das mal so war oder dass es mal eine Zeit lang gab, wo man nicht sagen konnte, ich stehe vor einem Problem.
Was mache ich? Ja, Google.
Also ich meine, du musstest mal überlegen, dass es eine Zeit gab, wo Abhängigkeiten zwischen Paketen nicht automatisch aufgelöst wurden durch so etwas wie ein Paketenmanager.
Was das für ein Hessell war, überhaupt Dinge zu installieren. Also Hölle.
Stimmt, als man RPM direkt benutzt hat.
Da kommen gerade Indrucks. Kriegswunder.
Die würden dich gar nicht mehr im Kopf haben.
Oder Kundensysteme, wo es gar nicht normal war, dass du da überhaupt Repositories angebunden hast.
Das ist übel, was das für ein Handstand manchmal war.
Von daher, wir sind schon in einer tollen Zeit, was das angeht.
Und das weiß ich nicht, ob man sich das noch bewusst machen muss.
Ich denke, für diejenigen, die es miterlebt haben, ist das nochmal schön zu sehen, wie das damals war und fühlt sich so erinnert.
Aber es sind echt schon viele, viele, viele Probleme gelöst, um die wir uns heute keine Gedanken mehr machen müssen.
Deswegen schaffen wir uns vielleicht auch manchmal neue Probleme.
Das stimmt, ja.
Was ich auch ganz interessant fand, in REL 5.6 ist ja damals auch X4 reingekommen.
Und später gab es auch PCI 3.0 Support, die KVM, die Köln-Wittlermaschine ist mit reingekommen.
Und, was ja auch viele nicht mehr wissen, wo wir gerade beim Thema sind, Dinge, die schon lange her sind.
REL 5 war die letzte Version, die den Intel Iternium 2 Prozessor unterstützte.
Könnt ihr euch noch daran erinnern, damals TM?
Inneren ja, aber ich habe nie eine Iternium 2 Installation durchgeführt.
Ich glaube, einmal hatte ich einen Server gehabt, aber da ist das...nein.
Also inneren ja, aber die war halt immer als Reservation mit angeboten worden.
Aber installiert habe ich tatsächlich nie einen.
Waren auch nicht so stark verbreitet, wenn ich mich so zurück erinnere.
Ja, also das kam halt ganz, ganz drauf an.
Ja, da nicht, aber ich sage mal so, lange Zeit hatten Leute eben Iternium-Server auf den Oracle-Leaf, auf den Sub-Leaf.
Das war eine gute Combo, die hat sehr lange sehr gut funktioniert.
Aber ja, proprietäre Hardware, die in den Nischen da seien, fristet in Zeiten, wo offene Systeme immer wichtiger wurden.
Da war das natürlich absehbar, dass das irgendwann ein eher geschlossenes Buch sein würde.
Und das hat Susi genauso gemacht und der Iternium selbst wird jetzt ja auch nicht mehr hergestellt.
Und auch Oracle muss, glaube ich, nur noch bis 2023 Support liefern für Iternium.
Und die anderen Betriebssysteme, die darauf noch laufen, namentlich OpenVMS beispielsweise oder Nonstop, die sind auch schon auf x86 oder werden gerade noch auf x86 migriert.
Also das ist einfach wirklich ein Rendikt der Vergangenheit.
Interessant, dass sich da anscheinend immer die nicht ganz so starke Lösung durchsetzt.
Also der Iternium war sicherlich die bessere CPU.
Wir haben ganz am Anfang schon Token Ring gehört, war sicherlich das bessere Protokoll gegenüber TCP/IP.
Nichtsdestotrotz, es hat sich immer das durchgesetzt, was nicht ganz so optimal war.
Aber es tut genau seinen Zweck, wenn man weiter zurückgehen will und von der IT weggehen will.
VHS hat sich durchgesetzt, falls euch das noch was sagt und nicht Video 2000.
Aber aus heutiger Sicht auch egal.
Also sind beide weg.
History Show wird das heute.
Ich glaube auch, ja.
Die Museums-Show.
Wenn ihr so alte Leute einladet, wie mich, das wird da passieren.
Das kennen wir ja alle noch.
Also ich kenne Token Ring ja auch.
Ich habe es selbst nie benutzt, aber man kannte es zumindest.
Und du hast da wirklich ein Stück weit echt recht.
Also ich meine, es gibt ja auch den Unix-Nachfolger Plan 9.
Und der ist ja auch architektonisch bedeutend vorteilhafter gegenüber Unix.
Also Unix oder generell diese ganze Unix-Design-Philosophie.
Die hat natürlich auch Punkte, die optimierungsbedürftig wären.
Aber es hat sich einfach so verbreitet und das ist jetzt auch in Form von Linux so omnipräsent,
da jetzt noch mal einen ganz brachialen Bruch des Designs hinzulegen.
Das kannst du vergessen.
Und ich glaube, ziemlich genauso wird das eben auch bei den von dir angesprochenen Architekturen eben sein.
Das hat halt einfach nicht genügend Drive aufgenommen.
In der Zwischenzeit ist der X86 als billiges Massenprodukt einfach salonfähig geworden,
weil man da auch dann auf einmal Taktraten aufrufen konnte, was vorher nicht denkbar war.
Ja und dann das, was die breite Masse nutzt.
Und Power und Mainframe sind ja auch noch dabei.
Das ist das Richtige, ja.
Aber das ist ja, ich würde sagen, kein Massenprodukt.
Das ist aber auch kein Nischenprodukt.
Das ist irgendwas dazwischen, das aber eine sehr, sehr treue Userbase hat, glaube ich.
Ich glaube, so kann man es ganz gut zusammenfassen.
Da gibt es ja auch Genügensprüche.
Auf die Dauer hilft nur Power oder das Z mit Mainframe steht für zukunftssicher.
Solche Dinge fallen ja durchaus öfter mal.
Absolut, ja.
Was ich noch interessant fand, und das ist, glaube ich, ein gutes Stichwort,
um noch mal so ein bisschen über Stabilität statt Innovation zu reden,
was ja auch eins der Mantras von Red Hat ist.
In RHEL 5 war auch mal dieses Compis Fusion und diesen AIGLX X Server enthalten.
Das waren diese lustigen 3D-Desktops, wo dein GNOME-Desktop so ein Würfel war,
den du verschieben konntest und so Fenster, die so gewackelt haben,
wenn du so rübergezogen hast und wenn du sie zugemacht hast,
dann sind die so in Flammen aufgegangen.
Das war so die Zeit, wo ich privat auch viel Genügens genutzt habe.
Und das ist sogar in RHEL gelandet.
Das war für mich ganz untypisch damals, weil, wie gesagt,
RHEL steht ja eigentlich für Stabilität statt Feature Ritis oder Innovation.
Also, ich muss ein bisschen widersprechen.
RHEL steht für Stabilität, Haken dran, das ist garantiert so.
Auch weit bevor ich bei Red Hat war, habe ich Distributionen verglichen
und habe immer festgestellt, die Red Hat Distribution ist ein bisschen älter
mit allen Dingen, die da sind.
Wenn sie überhaupt da sind, sind sie ein klein bisschen älter als der Mitbewerb.
Ich habe das mittlerweile schätzen gelernt, muss ich gestehen,
weil es dadurch eben tatsächlich eine Stabilität einhergeht.
Viele Bugs, die mit einem neuen Feature oder mit einer neuen Version einhergehen,
wandern in Red Hat gar nicht rein.
Aber Bug-Fixes werden zurückportiert auf die ältere Version.
Also, nur weil die Version älter ist, heißt das nicht,
dass sie deswegen unsicherer ist oder weniger sicher ist.
Das ist insofern eine ziemlich gute Kombination.
Es gibt viele Beispiele, wo der Rest der Linux-Welt eben patchen musste
und die Red Hat-Kollegen oder die Red Hat-Nutzer nicht,
weil dieses Problem da gar nicht auftrat.
Also, insofern Stabilität auf alle Fälle.
Aber spätestens, also das Mantra bei Rell 8,
ich weiß nicht, ob euch das bewusst ist, das war
"Schneller zu Hello World" war quasi das Mantra von Rell 8.
Und da ging es eben genau um die Agilität und der Spagat einerseits stabil zu bleiben an der Basis
und andererseits aber auch agil und schnell zu sein bei den Dingen,
die für einen Entwickler wichtig sind.
Und ich glaube, mittlerweile haben wir das ganz gut hingekriegt.
Ich hätte auch gesagt, dass das bei den vorherigen Releases durchaus der Fall war.
Also, jetzt klar nicht featureitis im Sinne von immer alles raushauen und reinbauen
und dann schnell wieder wegschmeißen, das ist klar.
Aber ich hatte bei einem Rell oder CentOS-System nie wirklich krasse Probleme,
zeitgenössische Workloads an Start zu bringen.
Also mit dem Rell 6 war ich schon in der Lage, eine aktuelle PHP-Version irgendwie raufzubringen
und dann aktuellen Webserver mit zu verheiraten.
Was ich bei anderen Enterprise-Distributionen oder Unix-Systemen echt...
Das war nicht so, dass das einfach lief und dass du das in 5 Minuten am Laufen hattest.
Da hast du echt ordentlich für gearbeitet.
Und bei CentOS oder Rell, da wusstest du einfach, ok, du installierst das.
Du kriegst jetzt nicht die latest version, aber wenigstens das PHP-Major-Release, was du haben wolltest.
Und wenn du das nicht in den Upstream-Repos gekriegt hast, gab es halt immer noch Apple.
Wo halt dann auch schon ganz gute Möglichkeiten waren, um mit den Sachen, die man damals so gemacht hat,
auch an Start zu kommen, ohne irgendwelche Sachen selbst kompilieren zu müssen.
Also da waren immer irgendwo Pakete verfügbar.
Man hat das echt gut an Start gekriegt.
Und das, weiß ich nicht, das würde ich da schon highlighten.
Jetzt bin ich aber auch eher so im Server-Backend-Bereich unterwegs.
Also ich brauch da keine GUI für das, was ich mach.
Von daher weiß ich nicht, wie sich das so für Desktop-User anfühlt.
Aber aus dem Server-Bereich kann ich schon sagen, gab es andere Distros,
wo ich mir eher die Hände über dem Kopf zusammengeschlagen hab, wenn das der Fall war.
Hast du auch Software-Collections genutzt?
Das auch, ja. Aber jetzt gar nicht so primär.
Aber das ist natürlich auch eine schöne Zusammenfassung, dass du einfach sagen kannst, guck mal,
Bildtools installieren und dann hast du erstmal alles, was du brauchst, um das so machen zu können.
Auch eine feine Sache.
Ich fand's immer ein bisschen sperrig, muss ich gestehen, weil es doch sehr eigen war.
Also wenn man sich damit angefreundet hatte, ging's.
Aber man musste es halt kennen. Alle anderen wussten irgendwie nicht, was da gerade passiert.
Aber das war schon so einer der Schritte, wo wir wirklich versucht haben, diesen Spagat hinzukriegen
und einerseits diese 10 oder 13 Jahre Stabilität beizubehalten
und trotzdem Leuten zu ermöglichen, eine neuere Version von Python oder von MySQL oder sowas
eben bereitzustellen, ohne dass das Versprechen verletzt wurde.
Der Vorteil war ja auch durch die Verbreitung von Red Hat, dass viele dafür entwickelt wurden
oder dass Red Hat auch läuft.
Wie du es gerade erwähnt hast, dass in Rico viele Distributionen gar nicht darauf vorbereitet waren,
weil die weder keiner kannte oder die Versionsstände hatten, die völlig inkompatibel mit anderen Thematiken waren.
In Richtung Red Hat war es häufig so, dass es auch wirklich geguckt wurde, dass es da läuft und dass es da auch funktional ist.
Aber die Stabilität finde ich super wichtig, also wenigstens der Basis-Kern.
Das ist jetzt mit den neuen Versionen auch immer noch mal ein bisschen in Fokus gerutscht.
Weil ich will ein System haben, wo ich weiß, das läuft erstmal die Basis, also Kernel etc., dass da nicht viel gemacht wird.
Und wenn ich halt zusätzliche Software haben will, wie wir es gerade gesagt haben, eine neue PAP-Version oder sowas,
als Beispiel, dass die halt immer noch mal neu installiert werden kann,
ist eigentlich ein ziemlich kluger Schachzug gewesen, dass man das Ganze so ein bisschen auftrennt und in verschiedenen Bereichen anbietet.
Weil die Apple-Konferenzation, die du gerade erwähnt hast, Enrico, wenn du da zu viel rumgefuscht hast,
hast du das System auch so konfiguriert, dass du Nachrichtenkompatibilitäten hast, wo du nichts mehr machen konntest,
habe ich auch schon auf einigen Systemen gesehen.
Und dann ist auch nicht mehr nachvollziehbar gewesen, was du eigentlich auf dem System getan hast.
Aber wie gesagt, es geht halt definitiv in die richtige Richtung.
Und die Probleme sind halt erkannt worden jetzt gerade auch von der Red Hat.
Es macht halt immer mehr Spaß, mit den Themen zu arbeiten.
Und die Probleme, wo man sich früher jahrelang mit rumgeschlagen hat, verschwinden nach und nach.
Gleiche Thema auch mit System D zum Beispiel.
Das ist eine Anpassung, die ich halt am Anfang auch, man muss sich wieder umleeren, gedacht habe.
Aber sobald man merkt, oh guck mal, du kannst ein Service in deinem eigenen Verzeichnis anpassen,
in deinem MTC-Verzeichnis.
Und du musst nicht gleich irgendwie in das USRB in irgendwas Verzeichnis reingehen, um da eine Konferenzation zu machen.
Das ist eine Kleinigkeit, aber das sind so Probleme, mit denen du nicht tagtäglich rumgeschlagen hast.
Weil wenn du dann die Software updatest, wird das nicht gleich wieder überschrieben oder so.
Das dauert, ja, es sind viele Sachen, die man einfach nicht versteht vielleicht.
Aber die auf lange Sicht die Stabilität eigentlich von dem Betriebssystem ganz stark erhöhen.
Ich finde auch das Schöne ist ja, dass nicht alles auf einmal irgendwie einem über den Zaun geworfen wird.
Also ich fand auch App Streams, was wir jetzt in RHEL 8 haben, ist eine tolle Sache.
Ich habe auch die Software Collections schon ab RHEL 6 genutzt.
Das war ja auch eins der Heilnachtsführer RHEL 6.
Und ich hatte nämlich genau das Problem, ich sollte produktive Webserver bereitstellen.
Damals hatten wir noch viele RHEL 5 und versucht da mal neue PHP Versionen drauf zum Laufen zu kriegen.
Das war echt gar nicht mal so einfach.
Und jetzt mit den App Streams in RHEL 8 ist das halt bedeutend einfacher geworden.
Ich glaube, das hat auch wirklich noch mal der Verbreitung von RHEL so ein bisschen einen Drive gegeben.
Weil gerade im Webbereich hat man vorher eigentlich sehr ungern Red Hat basierte Betriebssysteme eingesetzt.
Weil halt das Ganze, brauchst einen neuen Python Stack, eine neue PHP Version.
Das war immer alles ein bisschen fummelig, aber ist jetzt halt einfach viel einfacher geworden.
Das muss man ganz ehrlich sagen.
Wenn du das so betrachtest, dann bist du ja hier nicht nur in einem Releasewechsel von einem Betriebssystem unterwegs.
Sondern ich meine, wenn man ein bisschen auf die Zeiten so achtet, wir fangen da an irgendwie bei 2000, sind dann so bei 2007, 2010 oder so 2014.
Das sind ja auch einfach Dinge, die hardware-seitig komplett anders waren.
Ich meine Anfang und Ende der 90er, da gab es halt nur große, riesige Schränke, wo ordentlich Computing Power drin war.
Dann geht es weiter, dass wir irgendwie Virtualisierung zwischendurch möglich gemacht haben.
Und wir sind dann in Systemen, wo es halt nicht mehr tragbar war, dass du ein Jahres- oder Quartalsrelease hast.
Sondern dass sich auch Unternehmen irgendwie mit der Zeit schneller entwickeln wollen, agiler werden, andere Methoden einführen und Dinge wie DevOps auf einmal so aufpoppen.
Was auch bedeutet, viel mehr Geschwindigkeit, Dynamik und Flexibilität in den Systemen, die wir hier, wenn man die Zeitlinie zumindest von der Betrachtung, die man so in der IT im Wandel hat, mitbetrachtet, ist das ja auch die logische Konsequenz, die man daraus ableiten kann.
Absolut. Was wir hier vielleicht noch kurz zusammenfassen können, Software-Collections, das kam mit RHEL 6. RHEL 6 kam im Jahr 2010 raus, war die letzte Version mit 32-Bit-Intel- bzw. AMD-Support.
Und berachte auch... Schon so lange her? Ja, das ist schon richtig lange her. Oh Gott. Irre, ne? Fühlt man sich alt.
Wird auch noch bis 2024 supported und hatte diesen neuen Completely Fair Scheduler, also auch so ein tickles kernel, der eine höhere Energieeffizienz eben auch mit sich brachte.
Das war wirklich ein Thema, also auch gerade als Desktop-User hat man das wirklich gemerkt, weil die CPU halt nicht mehr periodisch aufwachen musste, sondern es On-Demand-Interrupts gab.
Das war echt ein Thema. Genauso wie die C-Groups, die RHEL 6.1 drin war, die sind heute nicht mehr wegzudenken.
Gerade wenn wir mal in das ganze Containerspektrum reindenken, du wirst das ja sehr gut wissen, was ich meine damit.
Enrico, du hast ja jeden Tag damit zu tun. Ohne C-Groups hätten wir heute keine Container-Technologie. Das gab es auch alles schon recht früh in RHEL 6.1.
Und auch neu damals war neben den Software-Collections auch Red Hat Insights, was es mit RHEL 6.7 gab. Hast du da viel mit zu tun, Markus? Du bist ja in dem Bereich unterwegs.
Ja, auf alle Fälle. Also Red Hat Insights, das war anfangs noch als eigenes Produkt unterwegs. Wir bieten das jetzt mit RHEL an.
Das heißt, jeder, der eine Red Hat Enterprise Linux-Subscription hat, hat auch Zugriff oder kann auch Red Hat Insights nutzen.
Wir sagen, das ist ein proaktives System, welches eben wirklich auf die vorhandene Installation abgestimmt Meldungen kundtut, wo Probleme auftreten können, Warnungen eben kundtut und gleich einen Skript liefert, einen Ansible-Playbook liefert, um dieses Problem zu beheben.
Letztendlich basiert das zum Großteil auf unserer Knowledge-Base-Datenbank, also auf den Dingen, die wir bei Kunden schon an Problemen festgestellt haben, setzen eine Regel dafür auf, damit eben andere Kunden davor gewarnt werden.
Aber es fließt eben auch das Know-how von unserem Quality-Engineering ein, also bevor das Produkt eben beim Kunden ankommt, wenn da schon Dinge erkannt werden, auf die man aufpassen muss, was Konfiguration oder Installation oder sonst was angeht.
Security-Advisories fließen da ein und so weiter. Also all diese Dinge werden dann über Insights wahrgenommen und dann im Zweifelsfall auch gemeldet, also finde ich extrem wichtig.
Vielleicht noch ein Aspekt in Richtung Sicherheit. Ich habe immer wieder Diskussionen mit IT-Lern, die dann sagen, da werden meine IT-Daten in die Cloud auch zu Red Hat geladen. Das ist richtig.
Aber die meisten dieser IT-ler arbeiten bei Unternehmen, die Microsoft 365 einsetzen, wo genau die unternehmenskritischen Daten in der Cloud sind oder die Salesforce einsetzen, wo die Kundendaten in der Cloud sind.
Und wenn ich jetzt die technische Konfiguration eines Servers an Red Hat schicke, der ja die ja eh quasi, den man eh vertrauen muss, weil sie das Betriebssystem liefern, dann ist das eben im Verhältnis nicht so kritisch.
Aber nichtsdestotrotz, wenn es jemand trotzdem kritisch sieht, kann man es auch entsprechend konfigurieren und bestimmte Dinge weglassen, nicht mitschicken und so weiter.
Da bist du ganz schnell bei so einem "What about-ism". Andere machen es ja auch, warum sollten wir es nicht auch tun dürfen.
Ich glaube viel eher, wenn man mal ein bisschen drauf guckt, was dann so die Mehrwerte sind, die draus generiert werden, dann ist das vielleicht viel interessanter.
Wir reden zwar immer darüber, dass wenn ich Support kaufe, dann habe ich vielleicht auch eine Möglichkeit auf die Roadmap einzuwirken oder auch Dinge für mich gefixt zu bekommen, je nachdem wie viel Geld ich da halt einwerfe.
Ich glaube aber auch, je mehr ich als Hersteller weiß, was meine Benutzer eigentlich mit den Systemen machen und wo der Fokus drauf liegt, desto besser kann ich für die eigentlich auch neue Mehrwerte schaffen.
Weswegen ich das eigentlich eine sehr wichtige Sache finde, jetzt nicht nur zu sagen, ja das ist alles total unsicher und böse, wenn da irgendwie in der Cloud Daten gesammelt werden.
Ich hoffe, dass wir aus diesem dunklen Zeitalter der Cloud Adoption so langsam rauskommen, wo auch Banken und medizinische Use Cases durchaus tragbar sind und Cloud Rechenzentrum für die meisten.
Ich denke, wenn ich zumindest die Rechenzentren mal angucke, die ich so bei Kunden sehe, würde ich sagen, jedes Rechenzentrum bei Amazon oder Google oder Microsoft hat deutlich höhere Standards und einen deutlich besseren Betreuungszyklus als das, was man selbst irgendwie bauen kann.
Also von daher, dass Sicherheit und gefühlte Sicherheit sind da zwei ganz verschiedene Dinge und auch mal ein bisschen Einblick gewähren, dass was man da so tut, ist glaube ich eine gute Sache, um eine Produktentwicklung auch besser voranzutreiben.
Wobei Insights eben tatsächlich darum geht, dem Kunden zu helfen und weniger darum, eine Erkenntnis zu erlangen, was die Kunden damit machen.
Also das interessiert uns natürlich auch, aber das ist etwas, was wir eher dann darüber abdecken, dass wir wissen, welche Subscriptions ein Kunde gekauft hat und daraus ableiten.
Oder dass wir wissen, welche Support Cases er geöffnet hat. Also wenn ein Support Case gegen REL5 geöffnet hat, wissen wir, dieser Kunde hat REL5 im Einsatz und vielleicht macht ein Update irgendwann Sinn.
Aber das wird nicht über Insights gelöst, ganz bewusst nicht, weil wir eben hier wirklich auch das Vertrauen schaffen wollen.
Ja, 2014 hatten wir dann auch hier, REL7 ist schon gerade kurz angedeutet worden, Thomas hat kurz das Thema System D angerissen.
Das würde ich glaube ich gar nicht weiter vertiefen wollen, weil dann können wir uns glaube ich noch zwei Stunden drüber unterhalten.
Was jetzt besser ist, das gute alte Sys5-Init oder System D. Ich glaube, wir können jetzt nach einigen Jahren sagen, dass es mehr gut als mehr schlecht war.
Ich würde es nicht mehr missen wollen. Und neues Standard-Dataisystem ist dann XFS geworden.
Das wurde auch versucht mit Stratas ein bisschen flexibler zu machen, ist nach wie vor aber nur eine Technik und Preview, hat jetzt auch nicht so viel Akzeptanz.
Würde ich so sagen, zumindest kriege ich das so in meinem näheren Umfeld mit. Und auch eine große Änderung in REL7, die Thomas sehr betroffen hat.
Sein Lieblings-Desktop KDE wurde abgekündigt.
Ja, ganz schlimm. Ich war schon immer genauer ein User, lag einfach nur daran, dass KDE mir immer abgestürzt ist.
Ich weiß nicht, was ich falsch gemacht habe, aber deshalb hat mich das nicht wirklich betroffen, muss ich sagen.
Und wenn dann, nutze ich trotzdem weiter GNOME.
Ja, also war für mich schon ein bisschen überraschend. Ich muss aber auch zugeben, ich habe KDE nie groß bei Desktop-Usern, die Red Hat einsetzen, gesehen.
Also die hatten auch meistens einen GNOME-Desktop und ich glaube, das war dann auch die Motivation von Red Hat, das eben einzustellen,
damit man die Entwicklungsressourcen dann doch bündeln und effizienter nutzen kann.
Nichtsdestotrotz kann man sich das ja immer noch optional installieren, wenn man will.
Es gibt halt keine vorkombinierten Pakete und keinen Support von Red Hat mehr dafür.
Aber ich muss auch zugeben, ich sehe mich da auch so ein bisschen wieder.
Nicht, dass ich was gegen KDE hätte, aber ich habe da bisher einfach nie so richtig den Bezug zu finden können.
Sehe aber trotzdem, dass sich da viel getan hat.
Also seit KDE 3.5, was irgendwie der letzte Desktop-Art, den ich eingesetzt habe, mit KDE 4 und jetzt KDE Plasma 5, da hat sich schon viel getan.
Vielleicht sollten wir da mal eine Sonderfolge zumachen und da mal beleuchten, was da eigentlich die Unterschiede sind.
Unterschiede gab es auch bei der Datenbank, denn MySQL wurde abgelöst und zwar durch MariaDB.
Was war denn da so der Hintergrund, Markus?
Das finde ich ein ziemlich spannendes Thema und das ist eigentlich gar kein Red Hat-Thema, aber das ist symptomatisch für Open Source.
Letztendlich gehört MySQL der Firma Oracle und da hat der Eigentümer einfach die Entwicklung in eine Richtung treiben wollen, die offensichtlich von der Community nicht mitgetragen wurde.
Und dann entsteht eben relativ schnell ein Fork, ein anderer Zweig, nennt sich ein bisschen anders und dann geht dort die Entwicklung weiter.
Natürlich sind da nicht alle 100% der Leute da rübergelaufen.
Insofern haben beide ein bisschen verloren, aber Fakt ist, dass ein Hersteller nicht irgendwie eine Community übersteuern kann.
Und das finde ich ist eine ganz wichtige Sache, dass man da sehr plakativ wahrnehmen kann, weil ja doch, ich hatte es vorhin erwähnt,
diese Angst da ist, dass das Red Hat vielleicht von IBM übersteuert wird und wir vielleicht nur noch auf Power entwickeln und die ganze x86-Welt dann nicht mehr existiert oder sowas.
Das wird nicht passieren. Das ist nicht unsere Intention, das ist nicht die Intention von IBM.
Aber selbst wenn sie es wäre, würde es nicht funktionieren, weil dann einfach die Community in eine andere Richtung weiterläuft ohne uns.
Also insofern dieses Umgehen mit diesen Communities. Wir hatten vorhin gehört, das ist Red Hat auch sehr stark in Fedora involviert und das sponsert da sehr viel natürlich.
Aber wir haben nicht, also wir übersteuern nicht. Also wir geben nicht die Richtung vor und alle anderen müssen folgen, sondern wir sind wirklich ein Teil der Community.
Und das ist glaube ich etwas, was Red Hat auszeichnet, was wir wirklich seit 1993 machen, seit 1995 machen und wo wir relativ gute Erfolge verzeichnen, dass wir da eben mit allen anderen gut zusammenarbeiten können.
War das eigentlich mit dem Fork von MySQL und MariaDB wirklich so, dass es einen validen Grund gab, dass Oracle etwas umgestellt hat oder war das einfach der Präventivschlag,
dass die böse große Oracle jetzt kommt und auf einmal alles lizenztechnisch umsteht und deswegen vermutlich alles irgendwann böse wird?
Ist da tatsächlich was in der Richtung passiert oder war das einfach der Präventivschlag, falls es denn mal irgendwann so sein sollte?
Schwer zu sagen, bin ich nicht tief genug drin. Also ich meine, dass es Verwerfungen gab oder Unstimmigkeiten ist offensichtlich, sonst wäre das nicht passiert.
Und im Prinzip die Frage, die ist Wasser auf meinem Plädoyer, man muss eben schon aufpassen, dass man gar nicht in so einen Ruf gerät. Und dann hat man das Problem nicht.
Lässt sich manchmal nicht verhindern, er war ja auch mit Docker in. Die Stocker war ja auch Bestandteil von RHEL7, aber ab RHEL7.6 gab es ja auch Podman als Alternative aus den eigenen Reihen.
Und da gab es ja glaube ich auch das eine oder andere Zerwürfnis, aber es gab glaube ich auch technische Gründe oder wie war das damals?
Also in erster Linie würde ich hier die technischen Gründe in den Vordergrund stellen. Also Docker, das Binary, benötigt Route-Rechte und muss als Demon laufen.
Und wenn man das verhindern kann, dann ist das aus Sicherheitssicht sicherlich begrüßenswert. Und die kleinen Tools, Podman, Builder und Scopio, die sind eben sehr viel kleiner, sehr viel leichter, wartbar, sehr viel besser auf Sicherheitslücken zu überprüfen, weil eben überschaubar.
Und brauchen eben kein Demon und brauchen auch keine Route-Rechte, damit ein Container läuft. Insofern ist das rein aus technischer Sicht sicherlich die richtige Richtung.
Bezüglich Kompatibilität ist es ja so, dass der Docker-Container ja durch die Open-Container-Initiative definiert ist und sowohl ein Docker-Container letztendlich OCI-kompatibel ist.
Und solange man einen OCI-kompatiblen Container hat, funktioniert also Podman, Builder und Scopio entsprechend. Insofern ist es technisch gar kein Problem, es ist halt nur sicher.
Docker hat halt über die Jahre immer versucht, mehr und mehr und mehr in so einen Single-Package reinzubringen. Wenn du halt irgendwie keinen Swarm-Scheduler dabei haben wolltest und einfach wirklich nur einen Container laufen lassen wolltest, ist das Ding halt immer mehr aufgebläht worden.
Und es haben sich ja selbst so manche Dekore-Entwickler von damals zurückgezogen und sind halt ins Mobi-Projekt gegangen und sind halt weiter weg von der Docker-Korp, irgendwo auch gerückt.
Ich meine, es ist halt so. Manchmal gehen Wege auseinander, manchmal werden geschäftliche Ziele den Community-Zielen vorangestellt und das sorgt halt dann dafür, dass Konsequenzen daraus gezogen werden.
Ich meine, auch damals als Docker halt da war und die verschiedenen Komponenten da drin sein sollten, hat sich dann Rocket als Alternative erarbeitet, das war ja damals so im CoreOS-Projekt passiert ist, was dann ja auch von Red Hat akquiriert wurde, wo dann halt auch heute das Fedora CoreOS mit wieder ein Projekt ist, was ich dann im Fedora-Kontext wieder deutlich besser und häufiger...
Also kenne und auf dem Schirm habe. Und natürlich ist das auch da so, dass sich hier eine komplett eigene Container-Runtime aus Gründen für Red Hat gelohnt hat, was aber nicht bedeutet, dass die...
Also wer jetzt halt gerne mit Docker arbeitet, der kann halt irgendwie trotzdem gerne noch Docker installieren, das funktioniert auch. Und dadurch, dass halt viel Standardisierung auch geschaffen wurde, sind Container halt heute eher ein standardisiertes Produkt, die über einen RFC quasi beschrieben werden und sich dann genauso verhalten und von verschiedenen Tools implementiert werden können.
Absolut. Ja, ich meine, die Firma, die Firma Docker, die hat es halt nicht wirklich geschafft aus ihrem total genialen Beitrag. Also ohne das, was damals geleistet wurde, wäre ja diese ganze Container-Technik heute gar nicht da, wo sie steht.
Aber sie hat es halt nicht geschafft, das irgendwie monetär irgendwie zu Geld zu machen. Und das ist sicherlich ein Problem für eine Firma und dass sie dann Mittel und Wege sucht, das doch irgendwie hinzukriegen, ist völlig legitim.
Und dass das dann vielleicht nicht mit Community-Zielen übereinstimmt, führt eben dann dazu, dass sich die Community woanders hinwendet, wie ja eben schon erwähnt. Das ist ja genau das, was passiert. Da würde ich sagen, dass Red Hat da einfach zum gewissen Grad vielleicht auch einfach Glück hat, dass wir in der Lage sind, einmal wirklich den Open Source-Gedanken durch unsere ganze Firmengeschichte unverändert stark zu vertreten.
Und trotzdem damit Geld zu verdienen.
Absolut. Ja. Ein weiteres letztes Feature, das ich in RHEL 7 noch ganz interessant fand, war das Kern-Live-Patching K-Patch. Das ist ja in RHEL 7.1 eingeführt worden.
Und Suze hat ja parallel auch eine eigene Technik namens, erst mal kurz überlegen, dass ich das nicht falsch sage, K-Graft entwickelt. Also es gibt K-Graft von Suze, K-Patch von Red Hat und K-Splice von Oracle. Die Tools von Red Hat und Suze nehmen und nutzen dieselbe Kerninfrastruktur.
Das finde ich ein technisch total spannendes Thema, habe ich auch bei vielen Kundinnen tatsächlich so auch gesehen. Und denke, das ist auf jeden Fall eine Funktion, die es gebraucht hat, weil es ja doch immer mal Use Cases gibt, wo man wirklich hohe Verfügbarkeits-SLAs hat, die man einhalten muss. Und für so eine sehr kritische Kernlücke nicht rebooten zu müssen. Das ist glaube ich eine feine Sache. Habt ihr damit schon mal zu tun gehabt?
Ja klar, ist natürlich ein spannendes Feature, aber auch da, weißt du so wie bei den alten Versionen, sich einfach Lohnsysteme architektonisch so aufzustellen, dass man sie einfach neu installieren kann, wenn eine Major Version kommt, bin ich auch der Meinung, dass wenn du wirklich richtig hoch verfügbare Systeme schaffen möchtest, dass du dich dann vielleicht auch von dem Kontext, also eine Maschine innerhalb deines Clusters sollte
Clusters sollte nicht dafür verantwortlich sein, dass ein User tatsächlich einen Impact spürt und
da kann man applikationsseitig einiges tun, dass das eben möglich ist. Und ich glaube, das ist so,
dass es da einige Relikte vergangener Zeiten gibt, bei denen das irgendwie nicht so ist und wo
dann versucht wird Workarounds zu schaffen, um es dann halt doch irgendwie sicherer und besser zu
gestalten. Aber meine ganz persönliche Meinung ist, dass es so systemkritikalitätstechnisch schon
besser ist, nicht davon abhängig zu sein, dass mein System nie durchbooten muss und dass ich
alles irgendwie live gepatcht kriege. Aber ich weiß nicht, ob ihr das anders seht. Du hast es
gerade gesagt, die alten Softwarekomponenten oder die Software, die halt von früher noch am
Laufen ist und da gibt es eine ganze Menge von, das darf man nicht unterschätzen, haben die
Klassefunktionalitäten vielleicht auch noch gar nicht, die du erwähnt hattest, oder ist das
sau schwierig, dass die sau schwierig zu konfigurieren sind, weil das macht das ganze Konzept halt noch
mal komplexer. Da muss man darauf aufpassen. Ich glaube, dafür ist das Patching von dem Colonel,
das Live-Patching eine ziemlich gute Sache, um solche Umgebung halt weiter laufen zu lassen,
weil es einfach noch genug Software gibt, die nicht dafür ausgelegt ist, also zu tun. Und ich
rede jetzt mal aus dem SAP-Bereich. Da geht es ja auch teilweise darum, dass Terabyte an Daten
irgendwo im RAM gespeichert sind. Wenn da eine Maschine mal neu starten muss, bist du einfach mal
20-30 Minuten unterwegs, um die ganzen Sachen richtig zu migrieren. Aufzupassen, wenn eine andere
Maschine hochkommt, dann hast du ja auch wieder ein Risiko, um das Ganze mit einzubinden. Da gibt es
immer noch die klassischen Patch-Tage, würde ich fast sagen, in dem ganzen Umfeld. Also tendenziell
von den Punkten, die du gerade erwähnt hast, gebe ich dir völlig recht, aber ich glaube,
das ist auch so eine Thematik, um die alten Software-Komponenten oder alte Software,
die halt noch läuft, noch weiter laufen zu lassen. Auch in einem ganz klassischen Modell,
um da aber auch zusätzlich Sicherheit noch mal zu gewährleisten. Weil machen wir uns nichts vor,
wenn wir jetzt auch Pakete updaten, müssen ja die Services darunter auch neu gestartet werden. Wenn
die Libraries im Backward ausgetauscht worden sind, macht vielleicht auch nicht unbedingt jeder in
dem ganzen Kontext, das ist eigentlich sau viel Arbeit. Und da, wie du es gerade gesagt hast,
ein Neustart wäre wesentlich einfacher und komfortabler in der Richtung. Aber ja, ich
hatte es gerade schon ein paar Mal erwähnt, ich denke, das wird eher auf die alten Software-Komponenten
zurückzuführen sein, die es immer noch gibt und die immer, also wie gesagt, von der Komplexität
vielleicht so aufgebaut sind, dass es nicht so einfach möglich ist, ein Cluster daraus zu machen.
Ich meine technologisch ist das schon cool, was da so geht. Aber ich glaube, also das eine ist halt
ein Funktionalitätsproblem, also irgendwie tatsächlich ein Bug, der dazu führt, dass ein
System halt nicht so funktioniert, wie du es dir erhoffst. Und das dann halt rauszukriegen,
ist halt gut, dass das ist. Der andere Bereich, auf den ja auch viel immer eingegangen wird,
ist der Sicherheitsaspekt. Also was ist denn, wenn ich angreifbar bin, weil eine Komponente
irgendwie einen Fehler drin hat, der ausgenutzt werden kann oder eine Schwachstelle drin hat. Und
da finde ich ehrlich gesagt mittlerweile viel interessanter, was da so einzelne Tools so im
Sicherheitskontext bieten, die dann, wo sich das auch Live-Patching nennt, aber denen geht es eher
darum zu schauen, dass zwischen dem Prozess und den Syscalls, die da macht, eine Ebene sich
zwischengeschoben wird. Und dann, statt jetzt die Library zu patchen, einfach die einzelnen Syscalls,
die charakteristisch für das Ausnutzungsverhalten ist, dass die schon bei der Anfrage beim Kernel
halt blockiert werden und du darüber dann quasi einen Funktionalitätspatching mit reinbekommst.
Also das finde ich spannend, wie es da, wie da mittlerweile so gerade auf Containerebene,
die Zwischenschicht zwischen dem Container und dem Kernel genutzt wird, um auf der Ebene Dinge
abzufangen, die potenziell bösartig sind, statt jetzt hinzugehen und die einzelnen, die einzelnen
Libraries auszutauschen und darauf zu versuchen, möglichst viel in den neuen Prozesskontext mit
einzuflegen von dem, was vorher da war. Also das Konzept ist halt superspannend, wenn man sich das
anguckt, das kann auch nur jedem empfehlen, was da passiert und warum das ein Live-Patching ermöglicht.
Du hast ja gerade erwähnt, also auf die Idee muss man erst mal kommen, dass das so funktionieren kann
und wenn man sich das mal anschaut, also es lohnt sich auf jeden Fall da mal reinzuschauen.
Ja, ich denke, ich denke tatsächlich, dass das also einfach zwei unterschiedliche Welten sind. Also
wenn wir von Containertechnik reden, Microservices, Scale Out, da ist die Hochverfügbarkeit eben in
der Applikation und wenn da von 100 Servern 10 ausfallen, dann ist das nicht schlimm, aber
wir haben eben auch Anwendungen, wo es dann in erster Linie denke ich an Datenbanken, die dann
auch so Konsistenzanforderungen haben, Atomic, also Veränderungen, die atomar durchgeführt werden
müssen, da kann ich nicht auf ein verteiltes System zugreifen, da muss eine Veränderung einfach
instanzierisch da sein in den Daten und wenn ich an so einer Stelle unterwegs bin, dann ist eben
Scale Up, große Maschinen, stand heute noch die einzige Möglichkeit und dann fängt an Live-Patching
auch einfach relevant zu werden und ich glaube, dass wir da immer weiter wegkommen und es immer
weniger Anwendungsfälle gibt und wir immer mehr in Scale Out Architekturen gehen, sonst würde ja
OpenShift auch nicht so durch die Decke gehen und Containerisierung nicht in aller Munde sein, aber
ganz weg ist wahrscheinlich kritisch, da sehe ich zumindest heute noch nicht. Das stimmt wohl, also
ich denke auch, ich sehe sowas bei einigen Use Cases, wo es sinnvoll ist, wenn du wirklich
Maschinen hast, die du nicht verteilen kannst, weil deine Applikation einfach nicht geklastert
werden kann und so weiter und du einfach hohe SLAs hast, da ist es durchaus sinnvoll, ich würde
jetzt nicht unbedingt die PHP-Webanwendungen in so einen Live-Patching-Cluster heben, das wäre dann
mit Kanonen auf Spatzen geschossen, da gibt es einfach elegantere Wege, da habt ihr auf jeden
Fall alle alle recht. Last but not least, REL 8 2019 erschien, bis 2031 wird es noch unterstützt,
über die Prominenz der Änderung haben wir auch schon so ein bisschen gesprochen, das war einfach
die Aufteilung in Base OS und AppStream, das war das modulare Konzept, da hat Markus ja schon gesagt,
man will einfach, man hat gemerkt, Kundinnen wollen eben einen neueren Python oder PHP-Stack haben,
der muss nicht unbedingt 13 Jahre gepflegt werden, da tut es vielleicht auch einfach mal so zwei,
drei Jahre und das ist eine sehr, sehr tolle Sache, die da mit eingekommen ist, man braucht
jetzt keine Software-Collections mehr, ist einfach Teil des Repositories und das heißt, man kann
einfach per Jamdnf als Modul diverse Programmiersprachen aktivieren, die sind dann in
mehreren Versionen vorrätig und das hat vieles auf jeden Fall einfacher gemacht. Wir haben auch
schon kurz angerissen, dnf ersetzt jetzt eben jam, der Name ist aber gleich geblieben, bessere
Auflösung von Konflikten ist ein Feature gewesen, das sich daraus ergeben hat, es läuft auch
bedeutend schneller. Wir haben Wayland, was der Standard ist, wir haben aber immer noch den
x11 Server als Fallback, wir haben die Möglichkeit, Firmware-Updates einzuspielen und Firewall,
die ist unsere neue Firewall und IP-Tables wurde durch nftables ersetzt, das war ja auch so ein
Relikt, das sehr lange drin war, das sehr vehement in allen verschiedenen Situationen drin war,
aber irgendwann muss man dann alte Zöpfe doch mal abschneiden. Das gilt auch für den Wirt-Manager.
Jetzt sag mir aber nicht, dass ich F-Config nicht mehr nutzen kann.
F-Config ist ja eigentlich schon seit Mitte der 90er abgekündigt, das interessiert nur
keinen, das ist das große Problem. Die gute alte Zeit. Ja, und damit haben wir glaube ich
zusammengekehrt, was jetzt so die letzten Änderungen der letzten REL-Versionen waren.
REL 9 steht ja auch vor der Tür, wenn ich recht informiert bin, ist es ja so, dass ja die neue
REL 9-Version auf der Ratchet Summit potenziell angekündigt werden soll und das dürfte ja auch
diesen Monat stattfinden. Hast du da Insights, Markus? Ja, das wird stattfinden, da gehe ich ganz stark
davon aus, da wird viel kommen. Ich meine, die REL 9 Beta ist draußen, das heißt, das ist auch
irgendwie kein Geheimnis mehr, dass da was kommt. Wir haben einen definierten Lifecycle,
und daran halten wir uns auch, also insofern ist da sehr stark davon auszugehen, dass das auch
passiert. Und ich glaube, dass das wirklich auch wieder wert ist, dass wir aber da jetzt nicht,
also zumindest habe ich bisher bei meinen Recherchen jetzt noch nichts entdeckt, wo ich sagen würde,
wow, das ist jetzt total überraschend. Also so ein Schritt wie zum System D von Sys5 in it,
werde ich glaube ich in REL 9 jetzt nicht sehen. Aber das Ziel ist es eben einfach tatsächlich,
überall stabil zu laufen, überall verfügbar zu sein. Vielleicht ein Aspekt noch, unser Produktpalette
ist ja sehr viel größer als nur REL. Was wir aber feststellen, ist, dass es fast kein Produkt gibt,
wo nicht REL irgendwie unten drunter läuft. Also auch REL Core OS haben wir eben gerade gehört,
basiert auf REL, nutzt die gleichen Treiber und ohne REL Core OS wäre OpenShift nicht denkbar. Also
insofern ist dieses REL auch auf ganz lange Zeit weiter da. Wir haben über KVM gehört und die
Virtualisierungsschicht, wir hatten eine eigene Virtualisierung Software, REV nannte die sich. Die
gibt es auch noch, die ist auch noch zu kaufen. Wir werden aber sehen, dass die Virtualisierung
in OpenShift wandert und siehe da, es werden die gleichen Tools, eben die gleiche Funktionalität,
die wir in REL sehen, wird da eben auch genutzt. Wir haben C Groups genannt, auch das ist etwas,
was eben dann aus dem Kern oder aus dem REL kommt, um eben auf höheren Ebenen, auf der Containerebene
dann Funktionalität abzubilden. Insofern ist dieses Ecosystem, finde ich, da extrem spannend,
wie die Dinge da zusammenpassen. Absolut, da werden wir auf jeden Fall auch berichten,
wenn ein REL neu draußen ist. Da bin ich auf jeden Fall auch schon mal gespannt und da haben wir es
ganz. Kannst du schon mal anfangen, Blog-Eintrag zu schreiben, vielleicht hast du auch mal ein
Buch erwähnt oder so. Genau, gute Idee, dann kann ich es so wie hier du machen und kriege dann auch
irgendwann lande ich in einem Buch. Wir werden auf jeden Fall berichten und bin auf jeden Fall sehr
gespannt. Die Beta habe ich mir auch schon angeschaut und ich bin vor allen Dingen auch sehr gespannt,
was die nächsten 20 Jahre REL so mit sich bringen werden und ich glaube, damit können wir den Sack
auch zumachen. Mich würde mal interessieren, was würdet ihr euch für die nächsten 20 Jahre REL
wünschen? Gibt es da irgendwas, wo ihr sagt, das sollte auf jeden Fall passieren? Gibt es irgendetwas,
das ihr dem Unternehmen wünscht? Und da würde mich mal interessieren, wie siehst du das, Markus,
als jemand, der jeden Tag mit den Produkten zu tun hat. Gibt es was auf deiner Wishlist,
was ganz oben steht? Ohje, schwierige Frage. Also ich habe mich jetzt schon auf die Rente so langsam
eingestellt, die keine 20 Jahre mehr entfernt ist. Insofern kann ich das schwer abschätzen. Ich
denke, dass der Weg, den wir da eingeschlagen haben, dass der sehr genial ist. Ich würde mir
innerhalb der Red Hat manchmal noch mehr Abstimmung wünschen zwischen den einzelnen Sparten, aber im
Prinzip passt das alles extrem gut zusammen und ich glaube, wenn das so weiter läuft,
die nächsten 18 Jahre würden mir schon reichen, dann ist alles gut. Wunderbar. Wie sieht es bei
dir aus, Thomas? Hast du Wünsche? Das ist schwierig. Das kann ich Markus nur anschließen. Das ändert sich
momentan ja so viel. Wo fange ich an? Genau, also wenn man überlegt, wie das vor 20 Jahren aus habe,
ich das Ganze gemacht habe, so gewisse Sachen sind immer noch dabei geblieben, gerade Installation
und so. Aber mittlerweile, wer installiert noch in Red Hat? Das heißt, du holst irgendwo ein Image,
guckst, was irgendwo eine Instanz ist. Also solche Sachen sind alle weggefallen und das hat sich halt
mit den Techniken drum herum ergeben, weil sich halt alles komplett geändert hat. Wünsche technisch,
puh, ist halt superschwierig überhaupt jetzt was einzuschätzen. Also viele Probleme, die ich früher
hatte, sind in aktuellen Versionen halt weg. Die hätte ich, wenn ich so tief jetzt in den System
nochmal arbeiten würde, nicht. Die wären halt viel einfacher zu lösen gewesen und da bin ich
schon mal froh drüber. Und zukünftige Wünsche ist halt superschwer gerade einzuschätzen. Also es
sind da viele Entwicklungen da, Score ist etc. Aber ich kann es gar nicht sagen. Ich lasse mich einfach
mal überraschen über deinen Block-Eintrag zum Beispiel. Wie sieht das bei dir aus Enrico? Naja,
ihr merkt ja, dass wir mit jedem Release uns immer weniger Gedanken machen müssen über die Probleme,
die wir damals mal hatten. Und das wiederum bedeutet ja, wenn wir das weiterspinnen, dann
müssen wir uns in Zukunft weniger Gedanken über die Probleme machen, die wir heute haben. Also
gerade sowas wie Container. Es wird eine Welt nach Containern geben und was sich gerade so abzeichnet,
ist, dass es stark in Richtung WebAssembly geht. Wir sprechen heute darüber, dass wir Plattformen
schaffen als Runtime-Environment für Applikationen, die sich dann alles, was sie an Infrastruktur
haben möchten, da so SS-Service rausholen. Und die nächste Iterationsstufe dessen ist ja dann
eigentlich, dass wir noch weiter weg von Anwendung und von Source Code selbst kommen und dass wir
einfach nur noch sagen, guck mal, wir gehen Richtung Serverless, wir gehen Richtung Systeme,
die versuchen zu verstehen, was ich eigentlich von denen will, ohne dass ich viel koden muss,
um da halt Dinge umzusetzen. Ich glaube einfach, dass wir uns weiter entfernen werden von so
Betriebssystemen, Coresachen, von Containern, wie wir sie heute verstehen, von Prozessen. Das wird
immer mehr in den Hintergrund rücken, weil es einfach eine Plattform oder eine Umgebung für uns
macht und wir uns einfach auf das konzentrieren können, was eigentlich schon immer am Anfang dieser
Nahrungskette steht und zwar Business Use Cases. Wir werden hinkommen und werden sagen, ich habe
hier Daten, die kriege ich irgendwo her und die sollen irgendwo hin, mach bitte System. Und wir
schaffen momentan eben Systeme, die es Applikationslogik erlaubt, das für uns umzusetzen. Und ich glaube,
dass wir so mit Themen wie Low-Code oder Robotic Process Automation damit die nächsten Generationen
von Anwendungen haben, die es wieder wie damals mit Kobol, den Mathematikern oder Buchhaltern des
Unternehmens erlauben, sich Werkzeuge zu schaffen, um Dinge zu automatisieren. Und da geht es ja heute
auch hin, dass wir irgendwie lustige Chatbots bauen wollen, dass wir irgendwelche Workflows in
Tools wie irgendwo ein M365 einbauen, um Umfragen zu machen, Dinge zu automatisieren, die für ein
Unternehmen wichtig sind. Ich glaube, da geht es Stück für Stück mehr hin, weiter weg von den
Sachen, die wir heute als Probleme haben, hin zu Plattformen, die uns schon fertige Werkzeuge
bieten, um das standardisierter zu lösen. Ehrlich gesagt freue ich mich da schon sehr drauf, dass wir
klar immer noch unten drunter diesen ganzen Stack an Technologien haben, dass der aber einfach immer
mehr convenient wird und es einfacher wird und damit auch das lokale Rechenzentrum immer mehr zu
dem wird, was wir heute als Warenkorb in Cloud-Umgebungen einfach sehen. Du kannst das
konsumieren, das ist fertig, du klickst dir das zusammen oder baust dir dann ein Terraform oder
whatever Skript dafür und dann geht es ab. Und da freue ich mich schon drauf, wenn das alles einfacher
wird, wenn es nicht mehr ein, zwei Tage dauert, eine Containerplattform ordentlich durch zu installieren
oder mehrere Monate, sondern dass einfach sagen kannst, guck mal hier, das will ich jetzt machen und
das läuft da einfach drauf. Das klingt vernünftig, ja. Hast du denn was, was du dir wünscht, sagen wir Christian?
Also ich habe viel Technik kommen und gehen sehen und egal, welche das jetzt war, dann muss ich
wirklich sagen, ich fand es immer gut, dass Red Hat immer auch den Open-Source-Gedanken nicht
vergessen hat. Also wirklich für jedes kommerzielle Tool gibt es in irgendeiner Art und Form halt ein
kostenloses Upstream, sei es jetzt Satellite, sei es OpenShift, sei es Red Hat Virtualization, was auch immer.
Das finde ich gut. Red Hat pusht das ganze Thema Open Source, ist damit sehr erfolgreich. Das würde
ich mir wünschen, dass das die nächsten 20 Jahre auch so weiter läuft. Ich finde auch gut, was so in
Richtung neuer Themen gemacht wird, also gerade so das Thema alternative Paketformate mit Flatpak
kam ja auch ursprünglich, soweit ich weiß, von Red Hat. Ich würde mir wünschen, dass Red Hat als sehr
dominante Firma oder als als Firma, die ein gewisses Momentum aufgebaut hat, vielleicht auch das ganze
Thema Liebungsaufentestung noch mal ein bisschen vorwärts bringt, auch wenn das andere Distributionen
vielleicht mehr verfolgen. Ich glaube aber, mit so einem Momentum kann man da ein bisschen was reißen
und da kann ich einfach nur sagen, ich hoffe, dass das die nächsten 20 Jahre genauso positiv weiter
verläuft. Und ich freue mich schon, die Rente mit REL23 eingehen zu können oder so. Gut, so Leute,
jetzt haben wir, wir sind knapp unter der zwei Stundenmarge, wenn ich jetzt hier die Uhr richtig
im Blick habe. Ich glaube, wir haben thementechnisch auf jeden Fall alles abgedeckt. Wir haben nun
guten Rundumschlag liefern können, was eben in der Vergangenheit passiert ist, wo Red Hat herkommt,
was passiert ist, wohin die Reise gehen kann. Und da möchte ich auf jeden Fall an euch, Markus,
Thomas und Enrico, vielen Dank sagen. Es hat mir sehr viel Spaß mit euch gemacht. Es war sehr schön,
so eine Sonderepisode mit euch aufzunehmen und vielen Dank fürs Mitmachen. Ja, auch von meiner
Seite aus. Dankeschön für die Einladung. Ja, ebenfalls herzlichen Dank. Bis zum nächsten Mal.
Freue mich drauf. Ja, danke dir und bis zum nächsten Mal. Ja, sehr, sehr gerne. Und liebe Zuhörer,
wenn ihr es bis hierhin durchgehalten habt, dann freuen wir uns natürlich sehr. Wir hoffen,
dass uns das Experiment geglückt ist, sowohl technischer als auch thematischer Natur. Und wenn
ihr Feedback habt, Ideen, Themen, die ihr hier auch mal gerne hören möchtet oder vielleicht habt ihr
die eine oder andere Geschichte mit Red Hat Enterprise Linux 3, die ihr beisteuern wollt,
dann könnt ihr das sehr gerne tun. Entweder per E-Mail an podcast@sva.de oder eben über unseren
Twitter-Händel @sva_focuson. Und in dem Sinne auch von meiner Seite vielen Dank fürs Zuhören und
bis zu einer der nächsten Episoden. Bis dahin, ciao. Tschüss.
Tschüss.