Pets and Cattle: Systeme betreiben wie eine Rinderherde (Dirk Deimeke)
Ep. 03

Pets and Cattle: Systeme betreiben wie eine Rinderherde (Dirk Deimeke)

Episode description

Warum betreibt man Server heute wie eine Rinderherde statt wie ein gestreicheltes Haustier? Für Dirk Deimeke ist genau dieser Wandel der Kern seines Berufs. Er beschäftigt sich seit 1996 mit Linux, arbeitet heute bei der Swisscom in Zürich und schreibt seit über zehn Jahren am Standardwerk »Linux-Server – Das umfassende Handbuch« mit. Du erfährst, wie er über die Mathematik zur Systemadministration kam, warum Pets and Cattle mehr ist als ein geflügeltes Wort und wie ein Fachbuch mit 30 Kapiteln, mehreren Autor*innen und LaTeX-Repository über sieben Auflagen aktuell bleibt.

Themen der Folge

  • Faszination Kommandozeile und der Einstieg in Unix und Linux
  • Pets and Cattle: warum Systeme heute wie eine Rinderherde automatisiert werden
  • Ansible, Puppet und Terraform im praktischen Vergleich
  • Cloud, Cloud Act und die europäische Abhängigkeit von US-Anbietern
  • Distributionen wählen: Ubuntu für den Einstieg, Red Hat, SUSE und Canonical im Rechenzentrum
  • Open Core, Support-Modelle und die Rolle von Community-Distributionen
  • Der Schreibprozess im Autorenteam: LaTeX, Git-Repository und virtuelle Treffen
  • Tipps für angehende Fachbuchautor*innen

Über den Gast

Dirk Deimeke, Jahrgang 1968, beschäftigt sich seit 1996 aktiv mit Linux. 2008 in die Schweiz ausgewandert, arbeitet er heute bei der Swisscom (Schweiz) AG und verantwortet dort unter anderem den Aufbau eines Linux-Workplaces. Zwischen 2024 und 2025 absolvierte er an der Zürcher Hochschule eine Weiterbildung in moderner Führung – für ihn der Schritt vom Techniker zur Führungsperson. Dirk ist an den Podcasts BuzzZoom und TILpod beteiligt, die er mitgegründet hat, bloggt in Dirks Logbuch und hält Vorträge und Workshops auf Open-Source-Konferenzen. Er lebt mit seiner Frau, zwei Hunden und einem Pferd in einem kleinen Dorf vor den Toren von Zürich.

Links

Credits

Du hast Lust, noch mehr Neues zu lernen? In unseren Newslettern versorgen wir dich regelmäßig mit nützlichen Inhalten aus unseren Büchern und Wissensbeiträgen unserer Expert*innen. Aber natürlich auch mit Informationen rund um Neuerscheinungen, Buchempfehlungen, Rabatt-Aktionen, Events und vielem mehr. Melde dich jetzt an!

Download transcript (.vtt)
0:00

Dirk Früher haben wir unsere Systeme wie Haustiere verwendet. Wir haben sie gestreichelt, gehegt und gepflegt. Und was man heute macht, ist, man betreibt Systeme wie Rindviecher, von denen man eine ganze Herde hat. Und wenn mal ein Rindviech nicht mehr da ist, dann stellt man ein neues Rindviech dazu.

0:17

Christian Mein Gast heute ist Dirk Deimeke. Er studierte Mathematik, Informatik und Elektrotechnik in Bochum und Dortmund. Und nach seiner Uni-Zeit arbeitete er in verschiedenen Rollen, vor allem als System- und Datenbankadministrator. Im Jahr 2008 entstand die Idee für ein Linux-Adminbuch. 2011 erschien die erste Auflage mit dem Namen Linux-Server – Das Administrationshandbuch im damaligen Galileo-Verlag. Im Laufe der Jahre sind neue Inhalte dazugekommen und alte wurden überarbeitet oder gestrichen. Der Titel wurde auf Linux-Server – Das umfassende Handbuch, geändert. Mittlerweile gibt es die siebte Auflage und weitere kommen. 2008 ist Dirk in die Schweiz ausgewandert und arbeitet weiter im Linux- und Infrastrukturumfeld. Seit 2022 ist er bei der Swisscom in der Schokoladenhauptstadt Zürich tätig und verantwortet den Aufbau eines Linux-Workplaces. Zwischen 2024 und 2025 absolvierte er an der Zürcher Hochschule eine Weiterbildung in moderner Führung. Zeit bei der Swisscom war für ihn der Schritt vom Techniker zur Führungsperson, also weg von Bits und Bytes hin zu Menschenverantwortung und Zusammenarbeit. Er hat mehrfach auf IT-Konferenzen wie der Free-and-Open-Source-Software-Konferenz, der FrOSCon-Konferenz. Und den Chemnitzer Linux-Tagen gesprochen über Themen rund um Linux, Open Source, Arbeitskultur und den Wandel vom Techniker zur Führungskraft. Dirk bloggt und podcastet regelmäßig zu Linux und Open Source. Gemeinsam mit Sujeevan Vijayakumaran betreibt er den Podcast TILpod und mit Mario Hommel den Podcast BuzzZoom. Privat lebt er mit seiner Frau, zwei Hunden und einem Pferd, ruhig gelegen im Zürcher Oberland, wo es mehr Wiesen als Banken gibt. Doch jetzt geht's raus aus dem Schokoladenbrunnen. Hallo Dirk.

2:09

Dirk Hallo Christian.

2:11

Christian Schön, dass du da bist. Ich würde ganz gerne mal einsteigen bei deiner Lebensgeschichte. Ganz früh bei deinem Anfang. Jetzt nicht, wo du geboren bist, in welcher Krippe, das meine ich jetzt nicht. Sondern eher, was hat dich denn dazu verleitet, letztendlich im IT-Umfeld ein Studium zu machen?

2:31

Dirk Also erst mal, ich bin in einer Stadt geboren, die es heute nicht mehr gibt. Das ist vielleicht dann auch nochmal ganz interessant, weil es im Jahr 1974 eine Gemeindereform gab in Deutschland und ich bin vor 1974 geboren. Ja, was hat mich zu einem IT-Studium gebracht? Eigentlich war seit meiner Schulzeit klar, dass ich Mathematiker werde, weil ich immer sehr gut in Mathematik war, sogar mehr als sehr gut in Mathematik. Und dann bin ich ins Mathestudium gekommen und habe gelernt, dass Mathematik nicht das ist, was ich studieren wollte, sondern ich wollte eigentlich Rechnen studieren. Und da mich doch eine Faszination für Computer so ein Stück weit begleitet hat, wir waren, zur Erinnerung, wir waren da in den Anfängen, vorsichtig formuliert, da gab es noch Amiga und Atari ST.

3:14

Christian Och, das war ja schon weit.

3:17

Dirk Ja, also ich habe mit einem programmierbaren Taschenrechner angefangen, das war noch ein bisschen weiter früher, so 1982 glaube ich. Ähm, Und deswegen fand ich Informatik relativ spannend. Ich habe auch tatsächlich Mathematik mit Schwerpunkt Informatik, hieß es damals, und Nebenfach Elektrotechnik studiert. Schwerpunkt Informatik war, weil es in Bochum damals noch kein Informatikstudium gab. Und als ich dann gemerkt habe, dass ich Mathematik nicht machen wollte, was mich in meinen vier Semester gekostet hat, habe ich mich dann entschieden, Informatik zu studieren und dann halt nach Dortmund zu gehen.

3:49

Christian Spannend, spannend. Ich habe ja auch mit Informatik, ich habe ja auch mit Mathematik angefangen, bis ich dann auch gewechselt habe. Aber meine Begründung war vielleicht eher, dass die Informatiker und die Mathematiker, sehr ähnlich ticken und dass ich mal mit anderen Leuten etwas zu tun haben wollte. Und daher habe ich auch das Nebenfach gewechselt. Aber es stimmt schon, Mathematik, glaube ich, im Studium ist was ganz anderes als Mathematik in der Schule, so wie man da in Kontakt kommt. Ja, und dann bist du in die Linux-Systemadministration abgedriftet. Wie ist es dazu gekommen? Also, wie ist es zu Linux im Allgemeinen gekommen? War Windows noch nicht so weit?

4:30

Dirk Ein folgenschwerer Fehler, wie es sich angedeutet hat. Wie bin ich dazu gekommen? Also, erstmal generell hat mich eine Faszination für Kommandozeileninterfaces begleitet. Also ich fand es immer cool, wenn man auf der Kommandozeile viele Dinge tun konnte. Und das ging unter Windows nun wirklich nicht so toll. Also wer sich erinnern mag, mit später Command-Exe, wie hieß es denn früher, wie hieß das davor, weiß ich gar nicht, die Batch-Geschichten der Kommandozeilen-Interpreter. Das hat nicht wirklich Spaß gemacht. Und unter Linux oder Unix hat das richtig Spaß gemacht. Und deswegen bin ich erst über Unix, wo ich ein Software-Praktikum drauf gemacht habe an der Uni, später dann auch zu Linux gekommen. Und mich hat immer begeistert, dass es eine quelloffene Software ist und dass es Open Source ist und dass man selber Veränderungen vornehmen kann. Und ich komme aus einem finanziell schwächeren Haushalt. Ich fand immer gut, dass mit diesen Systemen Teilhabe möglich war. Also, dass es möglich war, ohne dass man einen dicken Geldbeutel hatte, auch, am Internet oder was. Das Internet war auch in den Kinderschuhen. Wir sind ja schon alt, wir sind ja weiß-graue Bärte. Dass es einfach möglich war, alles Mögliche zu machen, ohne dass man viel Geld in die Hand nehmen musste.

5:45

Christian Kommandozeile, das ist ja interessant. Aber benutzt du heute immer noch primär die Kommandozeile oder ist dein Alltag doch der Maus gewichen?

5:55

Dirk Also, ich benutze natürlich viele grafische Applikationen, aber die Kommandozeile, die Shell, ist das Erste, was ich öffne, wenn ich an meinen Rechner gehe. Also, ich habe eine grafische Oberfläche und das Erste, was ich öffne, ist ein Terminalfenster. Und ich mache auch tatsächlich viel in dem Terminalfenster. Ich habe mir ein Skript geschrieben, was mein Update durchführt mit allen möglichen Sachen. Also, alle Git-Repositories werden aktualisiert, alle Anwendungen werden aktualisiert, meine Dot-Files werden aktualisiert. Und dann habe ich ein weiteres Skript geschrieben, was mir so die ganzen Applikationen hochfährt, die ich so täglich brauche, wenn ich arbeite. Das kann man anders lösen, ja, aber ich habe es halt mit einem Skript gelöst, weil mir das Spaß macht.

6:31

Christian Ja, eigentlich auch eine spannende Frage. Also wie viel programmieren können muss man eigentlich, wenn man im Administrationsumfeld tätig ist? Also Skripten, selber natürlich sowas wie eine Shell-Sprache, Batch oder anderen Varianten versus vielleicht, was jetzt eher so Richtung Python geht, so Automatisierung. Wie viel Skripting muss man können, um als Systemadministrator arbeiten zu können?

7:00

Dirk Ich sage erst mal, was man nicht braucht, wenn man das Linux noch als Desktop-System verwendet, braucht man keine Kommandozeile kennen und man braucht auch nicht skripten und auch nicht programmieren können. Damit habe ich mein Team relativ überrascht, weil die dachten, als ich den Linux vorgestellt, Dass ich jetzt mit der Kommandozeile komme und als sie merkten, dass es nicht einmal die Kommandozeile aufgepoppt war, da waren sie relativ erstaunt, weil sich so in den Köpfen doch festgesetzt hat, dass man für ein Linux-System wirklich die Kommandozeile braucht, weil ohne die geht es nicht. Und zurück zu deiner Frage. Also man muss in jedem Fall Ablaufsteuerungen beherrschen, sage ich mal. Man muss verschiedene Programme nacheinander starten können, man muss Bedingungen einpflegen können und man muss abhängig von Bedingungen wieder andere Dinge tun können. Also Skripten muss man können. Ganz zu Beginn vielleicht die Shell-Skripte, die man lernen kann. Dann auch später habe ich sehr viel mit Perl gemacht, als ich es kennengelernt habe. Und wenn man in Richtung automatisierte Konfiguration geht und Konfiguration Management geht, dann kommt man an Python nicht vorbei oder wenn man sogar Puppet, benutzt, dann ist es eher Ruby. Also programmieren können, ist in der heutigen Zeit nicht mehr wegzudenken. Also wir betreiben Systeme heute mit den gleichen Methoden, mit denen Software-Developer auch Applikationen programmieren.

8:13

Christian Ja, ich glaube, dann laufen wir jetzt so langsam in Richtung DevOps. Wie würdest du denn den Unterschied noch ausmachen? Siehst du dich noch als klassischer Administrator oder würdest du dich, keine Ahnung, wie nennt man denn Leute, die DevOps machen, DevOpser? Keine Ahnung. Also, wie viel ist DevOps-Arbeit, kann man das überhaupt sagen? Ach, ich weiß es gar nicht. Also, wie viel klassische Systemadministration steckt noch in deiner Arbeit drin versus das, was im Allgemeinen heute vielleicht dem DevOps-Umfeld zugeordnet wird?

8:49

Dirk Also, die klassische Systemadministration gibt es nicht mehr. Punkt. Ich glaube, das ist das. Was es aber gibt, ist Plattformentwicklung, nennt sich das heute. Das drückt sich so ein bisschen durch die Jobtitel aus, die man als Lehrberuf in der Schweiz lernen kann. Das Pendant zum Fachinformatiker Systemintegration, den ich in Deutschland, als Lehrherr betreuen durfte, gab es in der Schweiz das Berufsbild des Systemtechnikers. Das ist klassisch das gleiche Pendant. Und dieser Systemtechniker, der wurde umbenannt in Plattformentwickler. Und das gibt, glaube ich, auch relativ gut die Entwicklung vor. Also man macht seine Systeme nicht mehr als Einzelkunstwerke, indem man einfach auf Next, Next, Next fertig klickt und man hat seine Systeme installiert, sondern man automatisiert den Systemaufbau, um nachvollziehbare Systeme zu bekommen. Zur Grenze von DevOps komme ich gleich da kommen wir in Richtung Container-Applikationen, oder Orchestrierungsumgebung der Punkt ist der, dass man versucht alles nachvollziehbar zu haben also wenn man sich überlegt, man hatte früher einen Großrechner das Ding steht in der Mitte, die Z-Series von IBM war da weltweit führen Z-Series für Zero Downtime die haben halt alle Hardware-Ressourcen in diesem Riesentrümmer drin gehabt und haben, wenn es Probleme gab, Hardware-Probleme gehabt hat einfach ein anderer Hardware-Part, die Aufgabe übernommen. Wir sind dann rüber zu kleinen Server-Betriebssystemen gekommen, wo es dann einen dicken Server in der Mitte gab. Davon gab es auf einmal aber auch mehrere, die eine Aufgabe getan haben. Und dann sind wir weiter zu virtuellen Maschinen gewechselt. Und es ist immer eine 1-zu-N-Beziehung. Das heißt, früher, es gab einen Großrechner, es gibt mehr Server, es gibt noch mehr virtuelle Maschinen, und dann gibt es noch viel, viel mehr Container. Und irgendwie hat sich die Belegschaft nicht daran angepasst, wie viele Configuration-Items sie verwalten mussten. Das heißt, man wurde dem Ganzen nur dadurch ja, dass man automatisiert hat und dass man sehr viel automatisiert hat. Gleiches zu Gleichem gemacht hat, was natürlich den Systembetrieb an der Stelle vereinfacht. Also zurück, man automatisiert so weit, dass man alles nachvollziehbar hat. Und man hat früher gesagt, Pets and Cattle. Also sprich, früher haben wir unsere Systeme wie Haustiere verwendet. Wir haben sie gestreichelt, gehegt und gepflegt. Und was man heute macht, ist, man betreibt Systeme wie Rindviecher, von denen man eine ganze Herde hat. und wenn mal ein Rindvieh nicht mehr da ist, dann stellt man ein neues Rindvieh dazu. Also es gibt dieses geflügelte Wort von Pets and Cattle halt. Und so muss man das, glaube ich, heute sehen. Durch den hohen Automatisierungsgrad hat man immer ein Basisbetriebssystem fertig und obendrauf packt man als Layer vielleicht dann noch die Applikation mit einer Mittelschicht vielleicht, wo die Runtime-Umgebung der Applikation drin ist.

11:36

Christian Ja. Lass uns mal drei Technologien uns genauer anschauen und vielleicht kannst du mal einordnen, und wofür man das benutzt und was so Anwendungsfelder sind. Also ich hätte einmal Ansible, Puppet und Terraform. Kannst du die mal einordnen, wofür die da sind, was man damit macht?

11:54

Dirk Ja, kann ich. Das trifft mich jetzt unvorbereitet, das macht aber gar nichts. Also mit Terraform, Terraform hat seinen großen Siegeszug, angetreten, dadurch, dass es eine Programmiersprache war oder HCL, das HashiCorp Configuration Language heißt die, glaube ich, eine Programmiersprache war, mit der man Cloud-Ressourcen zusammenkleben konnte. Also man konnte dadurch Systeme auf Infrastrukturbasis bauen. Man hat dadurch ein System hochfahren können und konnte dadurch dann einfach Systeme hinstellen, sage ich mal prompt. Ansible, mit Ansible kann man das auch. Also wenn es Ansible Runbooks oder Module gibt, mit denen man Cloud-Dinge tun kann, dann kann man das da genauso tun. Ansible ist aber eigentlich eher ein Tool, mit dem man so Basis-Installationen macht. Mittlerweile macht man damit auch viel, viel mehr. Einverstanden, man kann mit Ansible alles machen, auch Kaffee kochen, dafür gibt es bestimmt Plug-in. Aber prinzipiell war es erstmal dazu gedacht, System-Endzustände zu definieren und die Magie von Ansible hat im Hintergrund dazu geführt, dass die System-Endzustände auf dem Zielsystem irgendwie erreicht werden. Was dazu führt, dass diese ganzen Ansible-Playbooks halt idempotent sind. Das heißt, wenn man sie ein zweites Mal ausgeführt hat, hat sich am Endzustand ja nichts geändert und damit hat das Playbook auf dem Zielsystem nichts getan. Und Puppet ist vom Modell her nochmal unterschiedlich. Also Ansible ist so, dass man einen zentralen Ansible-Host hat, mit dem man sich via SSH auf Zielsysteme verbindet. Puppet läuft ein bisschen anders. Es gibt einen Marionettenspieler in der Mitte, den Puppet-Master. Und der Puppet-Master wird von den ganzen Puppet-Clients alle halbe Stunde im Default, angefragt, ob es eine neue Konfiguration gibt und dann spielt der Puppet Master die Konfiguration aus und das Zielsystem, also das System, was die Konfiguration empfängt, versucht sich dann auch in den Zustand zu versetzen, was in dieser Konfiguration angegeben wurde. Wir haben das mal eine ganze Zeit dazu verwendet, dass wir die Basisinstallation mit Ansible gemacht haben, wenn es eine Cloud-Ressource war, sogar mit Terraform, dann haben wir mit Ansible das Ganze normiert, sodass wir einen normierten Stand hatten und haben, da dann auch die Software installiert, die das System brauchte und haben mit Puppet die Konfiguration durchgeführt. Ob das jetzt der Weisheit letzter Schluss ist, weiß ich nicht, aber das ist halt eine Sache, so wie wir es damals eingesetzt haben.

14:15

Christian Ich höre jetzt immer wieder Cloud raus und Container und Automatisierung. Seit wann gibt es diesen Trend eigentlich? Ich habe so ein bisschen den Eindruck, dass man natürlich früher so seine eigene Hardware hatte und irgendwann ist das dann verschwunden. Also dann hat man vielleicht erst Server gemietet, wo man dann immer noch die gesamte Infrastruktur drauf gehabt hat und irgendwann kam es mal dazu, dass man sagte, eigentlich brauchen wir das gar nicht mehr selber aufbauen, das Betriebssystem und so. Wir können das einfach in die magische Cloud hochladen und die haben dann die Compute-Kapazitäten und die haben dann schon die Services. Wann fing das eigentlich an?

14:53

Dirk Also eine Jahreszahl kann ich dazu nicht nennen, aber da wäre vielleicht an der Stelle als allererstes, Amazon zu nennen, beziehungsweise AWS zu nennen, die gemerkt haben, dass sie neben dem, dass sie eigentlich Einzelhändler sind und Einzelversandhändler sind und gemerkt haben, dass sie sehr viel IT brauchen, um Einzelversandhändler zu sein, haben sie gesagt, das, was wir intern benutzen, können wir auch nach außen geben. Wir haben einen sehr, sehr hohen Automatisierungsgrad und wir können das, was wir da tun, auch an Endanwender verkaufen. Wir haben so viele Lehrkapazitäten, dass wir auch diese Lehrkapazitäten einfach an Interessierte verkaufen können. Und ich glaube, das war so der erste echte Cloud Provider, so dass man ihn als Cloud Provider nennen konnte. Wenn wir jetzt in die Rechenzentren zurückgehen, dann ist es heute ja sogar so weit, dass sich Virtualisierungsumgebungen Cloud nennen, also sprich, dass man, mit einer API auf eine Virtualisierungsumgebung zugreift und dort dann halt, automatisiert Dinge durchführt und dann ist es eine Private Cloud beispielsweise an der Stelle und das, wovon wir über Amazon sprechen oder Google Compute oder Azure, das sind wohl die drei größten oder es gibt noch tausend andere mehr, Das nennt man dann Global Public Cloud an der Stelle.

16:00

Christian Siehst du das eher positiv oder negativ oder neutral, dass die großen Cloud-Anbieter meistens in den USA sitzen?

16:10

Dirk Ich sehe es negativ, ehrlicherweise.

16:13

Christian Was haben wir denn für Alternativen? Und warum nehmen so wenig Unternehmen denn diese Alternativen vielleicht auch in Europa wahr? Warum haben wir uns in diese Lage gebracht eigentlich, auch politisch, dass wir hier in Europa so wenig große Cloud-Anbieter haben?

16:30

Dirk Ich sage vielleicht erst mal, warum ich es negativ finde. Ich finde negativ, dass es durch regulatorische Bedingungen durchaus möglich ist, dass aus Amerika auf Daten auch in deutschen Rechenzentren zugegriffen werden. Der Cloud Act erlaubt es, dass ein amerikanisches Mutterunternehmen Zugriff auf seine Tochterunternehmen haben muss, egal in welchem Land sie sind und damit auch Zugriff auf die Daten, die von diesem Tochterunternehmen gehostet werden, bekommen muss. Das ist eine regulatorische Vorbedingung, ohne die geht es einfach nicht. Man kann sicherlich durch Verschlüsselung dem so ein Stück weit entgegenwirken, aber wir alle wissen, wenn man die Daten hat und man rennt da wirklich mit dem, Kopf gegen die Wand, irgendwann geht die Wand kaputt, also eine Brute-Force-Attacke klassisch. Man kann sowas an irgendeinem Punkt wirklich entschlüsseln und dann da auch weitermachen. Und wenn man so Rechenkapazitäten in Form einer NSA hat, dann ist da sehr viel möglich an der Stelle. Unser großes Problem, aber das wird ja schon fast politisch in Europa, ist es halt. Dass die Technologieunternehmen in Amerika deutlich weiter sind als in Europa, und dass man gerne an dieser Hochtechnologie teilnehmen wollte und deswegen sehr stark auf amerikanische Cloud-Provider gesetzt hat. Es ist, glaube ich, auch in der Branche relativ unumstritten, dass AWS technologisch führend ist, aber die anderen amerikanischen Cloud-Unternehmen, rüsten nach und sind zwischenzeitlich gleich auf. In Sachen Volumen überholt, glaube ich, gerade Microsoft mit Azure relativ viele, weil das Basis von M365 ist. Aber man möchte halt an dieser Technologiebewegung gerne mitmachen. Man möchte da halt gut sein an der Stelle. Es gibt europäische Cloud-Provider, die gar nicht so wahnsinnig bekannt sind und die auch gar nicht in dem Umfang konfigurierbar sind. Wie es die amerikanischen Cloud-Provider sind, glaube ich. Also ich möchte einen Hetzner nennen, die eine eigene Cloud haben und ich möchte vielleicht OVH aus Frankreich nennen, die ein relativ großer Infrastruktur-Provider sind. Otto bietet, glaube ich, seine Ressourcen. Otto, der Versandhändler, bietet, glaube ich, seine Ressourcen auch in Form von Cloud an. Zalando hatte das mal vor. Ich weiß gar nicht, ob sie es durchgeführt haben. Es gibt europäische Alternativen, die aber lange nicht so weit sind wie die amerikanischen Provider an der Stelle. Und vielleicht liegt es auch regulatorisch daran, dass wir in Zentraleuropa haben, wir regulieren erst und machen dann. Und in Amerika wird erst gemacht und dann reguliert. Das ist ein kleiner Unterschied.

19:03

Christian Erst tun und dann fragen? Oder erst fragen und dann tun?

19:07

Dirk Und besser fragen nach Vergebung als nach Erlaubnis. Also bei uns ist es eher, wir fragen um Erlaubnis und in Amerika ist es wie wir fragen um Vergebung. Aber die regulatorischen Bedingungen sind halt andere. In Amerika kann man erst mal machen und erst wenn es dazu kommt, wenn es zu Problemen kommt, wird ein Regulatorium nachgeworfen. Bei uns ist erst die Regel da und dann wird gemacht. Das ist vielleicht der große Unterschied.

19:29

Christian Eigentlich, glaube ich, haben wir das gleiche Problem im Moment auch mit KI-Anbietern. Also eigentlich vielleicht eine ähnliche Form. Vielleicht denkt man in Europa so, oh, wie sieht das mit dem Datenschutzrecht aus? Woher kommen überhaupt die Daten, mit denen die LLMs gefüttert werden? Und in den USA, wie, ja, da stecken fünf Millionen Bücher drin. Ist egal, hier. Bezahlen können wir später dazu. Mich hat das damals schon mal gewundert, dass bei europäischen Lösungen man so darauf bestanden hat, dass die Server in Europa stehen. Aber für mich hat das nie das Problem gelöst. Wenn es amerikanische Unternehmen und selbst die Server in den USA leben, gibt es trotzdem durch die Regeln Möglichkeiten, dass die Daten ins Ausland fließen.

20:09

Dirk Ja, definitiv.

20:11

Christian Das bringt mich so ein bisschen so auf Sicherheit. Du hast gerade Verschlüsselung erwähnt. Wie könnt ihr das bei euch im Unternehmen regeln, zum Beispiel Patches aufzuspielen, das System zu aktualisieren? Weil ich glaube, es gibt hier so einen Konflikt zwischen ich will mein System immer aktualisieren. Auf der anderen Seite haben wir aber dieses Stichwort oder Sprichwort Never Change a Running System.

20:34

Dirk Never even touch.

20:35

Christian Ja, also eigentlich will man ja niemals dran gehen, wenn man sagt, oh, dieses fragile System läuft gerade und wenn ich da irgendwas bewege, dann fällt es um und läuft, nie wieder startet, nie wieder. Auf der anderen Seite kommen irgendwie Security-Hinweise täglich rein, man muss das aktualisieren und das und das und das. Wie macht ihr sowas in der Praxis bei euch im Unternehmen?

20:52

Dirk Also ich bin jetzt nicht in dem Unternehmen, in dem ich gerade bin, bin ich nicht im Infrastrukturbereich beschäftigt. Aber ich kann vielleicht sagen, wie das so gemeinhin gemacht wird. Es ist so, dass die Linux-Anbieter, die Distributionsanbieter regelmäßig Patches zur Verfügung stellen. Und dabei sind Security-Patches dabei und Hotfixes dabei, die einfach Fehler beheben. Und diese Patches unterliegen einem Review-Zyklus und werden dann für Systeme freigegeben und in der Regel ist es so, dass die Systeme automatisiert gepatcht werden. Am Anfang des Monats werden vielleicht Development- und Testsysteme gepatcht und mit einer zeitlichen Verzögerung von 1, 2, 3 Wochen dazwischen werden dann die Produktionssysteme gepatcht. So, man hofft auf diesem Weg halt sicher zu sein, dass Sachen, die man vorher schon mal in Dev und Test ausgerollt hat, dass die später die Produktion nicht runterreißen.

21:41

Christian Aber völlig, heutzutage ist also völlig automatisiert. Also es guckt nicht wirklich jemand drüber und sagt, ich weiß nicht, ob ich jetzt diesen Linux-Patch einspielen sollte, ich warte mal lieber. Sondern da muss man einfach sagen, da hat man gar keine Zeit zu sich, damit individuell auseinanderzusetzen. Das wird einfach drüber gebügelt, Feierabend. Und dafür hat man den Servicevertrag zum Beispiel und dann wird das gemacht.

22:00

Dirk Ja, genau. Also was natürlich bei dieser Patch, also wenn die Patches reviewt werden, werden natürlich auf interne Testsysteme zuerst ausgerollt, um zu gucken, ob da alles tut. Aber die Konstellationen sind halt unterschiedlich. Man hat nicht jedes Kundensystem gleich nachgebaut. Und da vertraut man halt darauf, dass die Kunden halt ihre Development-, Test-, Quality-Systeme, was sie auch immer alles haben, entsprechend auf dem gleichen Stand haben, sodass sie die Tests auch selber durchführen können. Es hilft ja nichts zu sagen, dass das Betriebssystem läuft. Eigentlich muss die Applikation, die auf dem Betriebssystem läuft, laufen. Das ist, glaube ich, der Stoß, den man einmal verstanden haben muss. Wenn das Betriebssystem läuft, ich komme aus solchen Gegenden, wo der Systembetrieb ganz klar gesagt hat, mein Ding läuft, das ist alles andere, das ist nicht mehr mein Problem. Ich glaube, aus dem Alter und aus der Situation sind wir mittlerweile auch raus, glücklicherweise.

22:47

Christian Wenn du jetzt Privatpersonen empfehlen müsstest, ein Linux-System aufzusetzen, zu betreiben, anzufangen, wie würdest du da bei den vielen Linux-Systemen auswählen?

22:58

Dirk Ich habe vor ein paar Jahren einen Vortrag auf den Chemnitzer Linux-Tagen dazu gehalten. Den Link können wir sicherlich in die Sendungsnotizen packen. Da gibt es auch ein Video von. Ich würde einem potenziellen Anfänger raten, auf ein System zu setzen, was mit Ubuntu als Basis daherkommt. Also die Idee dahinter, auf Ubuntu zu setzen, ist, dass man da eine Basis hat, die sehr gut dokumentiert ist, wo man sehr viele Informationen auch im Internet darüber findet. Und letzten Endes ist es so, dass man jemanden kennen muss, der vielleicht jemanden kennt, der einem wirklich bei gezielteren Problemen weiterhelfen kann. Meiner Ansicht nach ist das auch einer der Erfolge von Windows, dass man da immer jemanden findet, der Ahnung hat oder jemanden kennt, der jemanden kennt, der Ahnung hat. Und alle Probleme kann man heutzutage nicht mehr selber lösen. Dazu sind die Computer viel zu komplex und auch die Anwendungssoftware viel zu komplex geworden. Das heißt, man ist auf Support angewiesen und bei Ubuntu kriegt man, glaube ich, relativ viel Support. Es ist nicht das beste System. Was das beste System ist, entscheidet glücklicherweise jeder selber, weil es sehr viele Wahlmöglichkeiten gibt. Und das Gute ist, dass man die Wahlmöglichkeiten hat. Und das Schlechte ist auch, dass man die Wahlmöglichkeiten hat. Weil man muss wählen. An irgendeiner Stelle muss man sich entscheiden und sich überlegen, womit man beginnen möchte. Ich selber bin auf dem Desktop-Distributions-Hopper. Das heißt, ich wechsle regelmäßig meine Desktop-Distributionen. Einfach, weil es mir Spaß macht, zu wechseln. Und ich kann dann mit dem gleichen Programm, mit einer anderen Distribution auch noch weiterarbeiten.

24:25

Christian Also ich habe jetzt verstanden, wenn man es eher privat nutzen möchte, Ubuntu, weil die Dokumentation gut ist. Ich habe sogar den Ubuntu-Font bei mir auf meinen Folien drauf. Der hat so einen gewissen Charakter. Wenn man jetzt mal auf die Unternehmensseite wechselt, also nehmen wir mal an, ich möchte für meinen Lakritz-Shop einen Server wählen. Mache ich das auch mit Ubuntu? Oder würdest du sagen, naja, wenn man es schon irgendwie seriös macht, als Unternehmen macht, dann greift man zu anderen Lösungen, weil kommerzieller Support ist besser oder die Frequenz der Security-Updates ist besser. Also würde man dann was anderes nehmen? Und warum? Was wären solche Kriterien, dass man sagt, naja, in dem Fall wäre Ubuntu dann aber vielleicht nicht mehr so gut?

25:08

Dirk Das kann ich mit einem sehr, sehr definitiven Kommt darauf an beantworten.

25:11

Christian Wow. Ähm ...

25:15

Dirk Im Unternehmensbereich ist es so, dass man meist bezahlte Software hat und die bezahlte Software setzt ein bestimmtes zugrunde liegendes Betriebssystem voraus. Die meisten Zertifizierungen für Betriebssystemen gibt es wahrscheinlich für Red Hat Enterprise Linux, was relativ weit vorne ist und gibt es auch für SUSE Linux Enterprise Server, wenn man im Rechenzentrum guckt. Gibt es auch zum Teil für Ubuntu, aber schon weniger und es gibt sie auch zum Teil für Debian, aber auch wieder weniger. Von daher würde ich immer schauen, bei Debian gibt es einen Community-Support, bei Ubuntu den Support durch die Herstellerfirma Canonical, bei SUSE Linux Enterprise Server durch SUSE und bei Red Hat Enterprise Linux halt durch Red Hat und diesen Support zahlt man auch. Also man muss sich davon lösen, dass man ein komplett gratis Betriebssystem, mit kompletten Support bekommt, ohne dass man was dafür zahlen muss. Aber der Bestimmer, was man da einsetzt, ist zum einen die Software, die ich auf dem System einsetzen möchte, dafür zertifiziert. Und zum anderen beißt sich das vielleicht mit dem, was ich sonst im Rechenzentrum stehen habe. Meistens ist Software für mehrere Betriebssysteme zertifiziert und man sucht sich ja jetzt nicht jedes System einzeln aus und sagt, ach, das lasse ich unter Debian laufen, das lasse ich unter Ubuntu laufen, das lasse ich unter Red Hat Enterprise Linux laufen und das unter SUSE Linux Enterprise Server. Und weil ich da auch einen deutschsprachigen Support bekomme, Manjaro habe ich noch nicht im Rechenzentrum, das tue ich jetzt auch noch ins Rechenzentrum, sondern ich erinnere nochmal an Pets and Cattle. Man reduziert Betriebskosten dadurch, dass man eine relativ einheitliche Basis hat. Man muss einfach gucken, dass man auf möglichst breiter Basis einheitlich ist. Und das kann man, glaube ich, nur durch die drei kommerziellen Systeme, Red Hat, SUSE und Canonical, Schrägstrich Ubuntu, machen, weil man da kommerziellen Support bekommt. Und meiner Erfahrung nach ist Red Hat... Wenngleich auch manchmal ein bisschen altbacken, das System, was die weiteste Zertifizierungsverbreitung hat.

27:24

Christian Mir ist aufgefallen, jetzt wo ich an einem C-Buch arbeite und ich viel Tools einsetze, also nicht nur in den verschiedenen Compiler, sondern auch Profiling-Tools und so weiter, dass ich ein bisschen genervt bin von den verschiedenen Möglichkeiten, das zu installieren. Jeder hat irgendwie seinen eigenen Installer. Du bist der Fachmann. Warum ist das so fürchterlich? Warum hat jeder sein eigenes Kommando, wenn ich Software installieren möchte?

27:51

Dirk Weil das historisch gewachsen ist. Weil, ja, weiß ich nicht, Ubuntu hat ja die Basis in Debian. Debian hat ein eigenes Softwarepaket gehabt, gehörte zu den großen ersten Distributionen. Red Hat ist eine zweite relativ große Distribution. Die haben sich halt parallel angefangen zu entwickeln und da hat ja jeder sein eigenes Ding getan. Und so gibt es halt die großen Paketformate, Debian-Pakete, .deb, und Red Hat Package Manager-Paketformate, Das sind RPMs, die durch entsprechende Tools installiert werden können. Und sie sind eigentlich nie dazu gekommen, das zu vereinheitlichen, weil jeder von sich geglaubt hat, dass er das bessere Format hat und keiner ein Stück weit abgeben wollte von dem, was er getan hat. Ich meine, die Hardcore-Leute, die laden sich den Quelltext runter und kompilieren selber. Das geht natürlich auch noch. Und das geht vor allem auch dann gut, und ich komme darauf zurück, wenn man eine stabile Basis hat. Also wenn man eine weitverbreitete Basis hat, dann funktioniert das auch ganz gut.

28:48

Christian Also als Autor ist das extrem lästig, weil dann musst du immer so einen Menüpunkt, nicht so einen Menüpunkt, sondern so eine Unterteilung machen. Also bei dem Betriebssystem muss ich das schreiben, bei dem Betriebssystem muss ich das schreiben.

28:58

Dirk Das müssen wir Buch auch, ja.

29:01

Christian Ja, stimmt, genau, da kommen wir auch nochmal zu. So ein anderer Knackpunkt ist irgendwie mit dem systemd versus, wie heißt die Alternative nochmal?

29:11

Dirk System V Boot.

29:12

Christian Ja, was hat es damit auf sich? Das ist ja auch irgendwie so ein Glaubenskrieg. Warum das Ganze, warum ist das so irgendwie extrem, warum wird im Linux-Umfeld häufig so extrem fast schon religiös argumentiert? Also das ist für mich auch so ein Beispiel. Warum?

29:31

Dirk Weil man es kann. Es gibt halt viele Leute, die sind, die mögen keine Veränderung. Und alles, was ihren Status Quo verändert, dem sehen sie skeptisch entgegen. Ja. Und ich bin auch mittlerweile der Meinung, dass man nicht mehr jeden Scheiß mitmachen muss, um es mal vorsichtig zu sagen, sondern dass man auch da mal ein bisschen Wasser denn rein runterfließen lassen muss. System V Init-Skripte hatten halt den großen Nachteil, dass das alles uneinheitlich war und dass alle selbstgeschriebene Skripte verwendet haben. Es gibt zwar ein Framework, was man so verfolgen soll, aber man muss nicht. Und was das Schlimmste ist, System V Boot ist Single-Threaded. Und jetzt sind wir in einer Welt, wo wir mit Multicore-Architekturen zu tun haben, also unsere Produktionstrümmer haben 192, 384 Cores. Und wenn ich mir überlege, dass nur ein Core davon benutzt wird, um das System hochzufahren, dann ist das absolute Verschwendung. Man möchte ja parallelisieren und das bietet halt systemd. systemd erlaubt eventabhängige Starten von Software und erlaubt auch parallelisierte Starten von Software. Und das, was bei systemd, glaube ich, der Hauptknackpunkt für viele ist, das Init-System mit System V oben drauf, das ist ein System, was einzig und allein dem Zweck dient, den Rechner hochzufahren und die Systemdienste zu starten. systemd ist aber eine Suite, ein großes Potpourri vom Programm, die im Prinzip dazu dienen können, das komplette System zu managen. Und wenn man systemd und Init vergleicht, also diese beiden Boot-Systeme, dann ist es halt so, dass man Äpfel und Birnen vergleicht. Man hat auf der einen Seite ein System, was nur dazu gedacht ist, ein System in eine Lage zu versetzen, dass man damit arbeiten kann. Und auf der anderen Seite hat man ein System, was auf Events reagieren kann, zum Beispiel, was dadurch dazu führen kann, dass wenn man einen USB-Stick in einen Rechner steckt, das automatisch via systemd der Virenscanner angeschmissen wird und, der USB-Stick geprüft wird. Das geht unter System V auch, indem man udev-Rules da vergibt an der Stelle, aber es ist halt aus diesem Framework rausgenommen und, Also, ich glaube, der Hauptkritikpunkt für viele, die das nicht mögen, ist halt, dass es viel, viel mehr ist als nur Init.

31:54

Christian Ja.

31:54

Dirk Glaube ich.

31:55

Christian Das heißt aber dann auch, dass letztendlich auch die Arbeit als Systemadministrator sich über die Jahre auch durchaus gewandelt hat. Also, das heißt, es kommen neue Tools, man muss sich auch dann ja mit verändern. Also kann man nicht nur sagen, das haben wir vor 20 Jahren so gemacht, das bleibt so, sondern das sind ja auch tatsächlich ziemlich fundamentale Bewegungen dann. Noch ein anderes Thema, was ich spannend finde, ist, viele Linux-Systeme sind ja schon Open Source, es gibt kommerzielle Unterstützung, aber ich habe so ein bisschen den Eindruck, dass in der Landschaft sich das so ein bisschen verschiebt, so zu so einem Hybrid-Modell. Ja, der Kern ist frei und open source, aber dann flanscht man noch was kommerzielles daran und damit verdienen wir unser Geld. Ist das zu beobachten? Ist das nur ein Bauchgefühl oder stimmt das tatsächlich?

32:44

Dirk Wo fangen wir an? Also bei der Linux-Distribution ist es so, dass alles, was du da bekommst, open source ist. Das, was du bezahlst, ist der Support und dass du regelmäßig Patches, getestete Patches bekommst. Das ist das, was du bezahlst. Aber das System selber ist und bleibt Open Source und die Urheberrechte sind und bleiben bei den Herstellern der Software. Natürlich bringt jeder Hersteller dann noch ein paar eigene Tools mit. Die meisten Hersteller im Distributionsbereich bieten die auch als Open Source an, dass man die weiterverwenden kann. Aber der Kernpunkt, womit sie ihr Geld verdienen, ist mit Support und mit getesteten, Aktualisierungen, sage ich mal so. Und mit der Garantie, dass sie über die Laufzeit des Systems bei Red Hat und SUSE und mittlerweile sogar bei Ubuntu 10 Jahre bis maximal 13 Jahre, dass sie in dieser Zeit API-Kompatibilität gewährleisten. Das heißt, dass man eine Software, die man an Tag 1 einer Distribution aufgespielt hat, 13 Jahre lang auf dem gleichen System weiterverwenden kann. Und da kommen wir dann zu dem Problem, wo dann du auch eine Rolle spielst, Christian. Kein Mensch möchte, aber erst recht kein Softwareentwickler und deswegen, Christian, möchte mit 13 Jahren alten Bibliotheken arbeiten.

34:00

Christian Oh Gott, das stimmt.

34:01

Dirk Niemand. Und deswegen ist es halt so, dass man schauen muss, das machen wir auch schon seit Jahren, dass man das Betriebssystem und die Applikationen, die darauf laufen, voneinander entkoppelt. Also jetzt klassisch in deinem Beispiel wäre das, dass wir Applikationen immer angeraten haben, dass wir eigenes Java mitbringen. Sodass sie, wenn wir patchen, ist ihre Runtime-Umgebung für die Applikationen davon nicht betroffen. Oder auf einem sehr, sehr tiefen Layer, wovon der Distributionshersteller aber garantiert, dass sich dieser Layer nicht so verändert, dass es API-Brüche gibt, also dass da irgendwelche Kompatibilitätsprobleme auftauchen. Was oben drauf läuft, ist dann wieder egal. Da ist dann der Softwareentwickler selber gefordert und wenn es eine Java-Version gibt, die eine bestimmte Kernel-Version oder eine bestimmte glibc-Version unten drunter voraussetzen würde, dann muss der Softwareentwickler sehen, ob die mit diesem vorhandenen Betriebssystem überhaupt machbar ist oder ob es dafür was Neueres braucht.

35:02

Christian Wie siehst du die Spaltung bei den anderen Werkzeugen, wie zum Beispiel, jetzt haben wir über Ansible Puppet schon kurz besprochen oder Terraform. Also wie stark verändert sich das, was vielleicht ursprünglich Open Source war, hin zu vielleicht wird wer weggenommen, es kommerzialisiert sich. Also zum Beispiel im Java-Umfeld ist mir aufgefallen, man hat relativ lange und gut mit Flyway arbeiten können. Das ist so ein Daten- und Migrationstool. Das war eigentlich immer frei gewesen. Und plötzlich wird das quasi, gab es eine feindliche Übernahme und plötzlich sind die interessanten Migrationen, dafür muss man dann eben jetzt Geld ausgeben oder man bekommt nur, sagen wir mal, alte Datenbanken oder alte Schematas unterstützt, die dann funktionieren, für alles andere muss ich bezahlen. Das finde ich merkwürdig. Deswegen meine Frage, wie erlebst du das bei den anderen Produkten, die man jetzt neben dem Betriebssystem noch einsetzt? Vielleicht Produkte, die früher völlig selbstverständlich Open Source war, gute Community und plötzlich schnappt sich ein Unternehmen diese Technologie und es wird gefühlt geschlossener.

36:10

Dirk Ich sehe eine Tendenz zu OpenCore, dass der Kern einer Anwendung frei bleibt, aber alles, was die Anwendung interessant und angenehm zu nutzen macht, das muss man bezahlen. Es gibt da sehr viele Beispiele, für GitLab sei mal als Beispiel genannt, was in der Basisversion OpenCore ist, was man frei benutzen kann. Es gibt eine Community Edition, die man auf jedem Server einsetzen kann. Bei Grafana ist es genau das Gleiche, beispielsweise, um da mal zwei Beispiele zu nennen. Beispielsweise, um mal zwei Beispiele zu nennen, auch sehr schön, um an der Stelle mal zwei Beispiele zu nennen, wo halt das Basisding Open Source ist, aber das, was man an zusätzlichen Funktionen haben möchte und was man vielleicht auch im heutigen Lifecycle Management braucht, das kostet dann auf einmal Geld. Die Tendenz gibt es. Die Frage muss man sich ja erlaubt zu stellen, arbeiten Menschen daran, die auch vielleicht Familie haben, die ihre Familie ernähren müssen, wie sollen sie das tun? Und wenn wir alle altruistisch unterwegs wären und alles, was wir machen, freistellen würden und wir arbeiten 100% an diesen Dingen, wie sollen wir unsere Familie ernähren? Und das beißt sich an der Stelle und irgendwoher muss das Geld ja kommen. Da gibt es einmal im Großen und Ganzen das Modell zu sagen, ich hole mir das über Support und über Stabilität, durch sehr, sehr guten Support. Die andere Möglichkeit wäre halt zu sagen, ich biete Premium-Funktionen an oder Funktionen jenseits des Kerns an, die ich dann mir explizit bezahlen lasse.

37:37

Christian Ich überlege gerade, wie ich dir danken kann für diese eigentlich fantastische Überleitung zur Autorentätigkeit. Eigentlich passt das jetzt ganz gut zusammen, mal dazu überzuleiten. Letztendlich ist es ja auch etwas, was man traditionell erstmal frei hat, eine Dokumentation, aber natürlich sind gewisse Sachen in Buchform doch dann irgendwie auch besser. Erzähl mir ein bisschen davon. Wie ist es dazu gekommen, zu dem Buch?

38:03

Dirk Ja, was soll ich sagen? Die Geschichte dieses Buches ist eine Geschichte von Missverständnissen. Nein, ich war sehr aktiv in der Ubuntu-Community und jemand, der auch in der Community sehr aktiv war, der damalige Projektleiter von ubuntuusers, der war schon Autor im damaligen Galileo-Verlag. Und hat er mich gefragt, ob ich mir vorstellen könnte, mit ihm ein Buch zusammen, über Linux Server zu schreiben. Und ich fand die Idee eigentlich total klasse, dass ich mit ihm zusammen daran gearbeitet habe. Dann hat er sich entschieden, eine Dissertation zu machen, stand für das Buch nicht mehr zur Verfügung. Und dann ist es dazu gekommen, dass wir mit dem Verlag zusammen einfach geschaut haben, dass wir Autoren finden, die an so einem Projekt miteinander arbeiten wollen. Weil mir alleine habe ich es nicht so getraut in dem Umfang.

38:49

Christian Das ist ja auch viel. Also wie viele Seiten hat jetzt das Buch?

38:52

Dirk Ich glaube 1300 irgendwas oder knapp um die 1300.

38:56

Christian Ja, und an jeder Ecke bewegt sich ja irgendwas. Das ist ja absolut verrückt, da immer auf dem letzten Stand zu bleiben.

39:03

Dirk Ja, plus die Sache natürlich, die du auch schon kurz angesprochen hast. Du musst ja nicht nur die Befehle reinschreiben, wie man Software installiert. Du hast ja auch noch unterschiedliche Versionen der Software auf verschiedenen Distributionen. Das heißt, und du hast Unterschiede zwischen RPM-basierten und Debian-basierten Distributionen, wo die Konfigurationsdateien liegen. Also sprich, ein großer Teil des Geschreibsels ist zum Beispiel auch da festzustellen, wo sind die Unterschiede und das auch mit zu dokumentieren, was man wo und an welcher Stelle tun muss.

39:35

Christian Ja, ich fand immer so die Idee reizvoll, so eine Art interaktives Buch zu haben, was ich dann starte und dann ist da so eine Art Checkbox oder so ein Dropdown-Menü, dann kann ich dann sagen, ich habe jetzt Version Bla mit Betriebssystem Blub und dann wird das Buch nur für mich gemacht mit genau den Inhalten und den Rest, der interessiert mich ja gar nicht, der linkt ja nur ab, aber, das ist natürlich eine schwierige Entscheidung. Wie habt ihr euch letztendlich darauf geeinigt, welche Distribution in den Mittelpunkt setzt? Nehmt ihr alle großen, sagen wir mal Red Hat, Fedora damals, Ubuntu und Debian gleichwertig mit oder habt ihr gesagt, wir gucken erst auf die Consumer-Seite oder wir gucken eher auf die Business-Seite? Wie habt ihr das entschieden?

40:17

Dirk Das hat sich so ein bisschen entwickelt. Ich meine, die Zielsetzung unseres Buches ist so der erfahrene Linuxer, der auf irgendwelche Wege angefangen hat, Server-Administrator zu werden. Oder der Server-Administrator im Nebenberuf geworden ist, der also nicht hauptberuflich damit arbeitet. Weil wir wollten eine klare Abgrenzung haben. Ein Buch, was so viele verschiedene Themen hat, wie das Linux-Server-Buch, was wir haben, das kann nicht so in die Tiefe gehen. Und wir haben gesagt, ein professioneller User, der Tag ein, Tag aus nur Systemadministration macht, der kauft sich Fachbücher zu den spezifischen Themen, die wir, im Buch behandeln. Das Buch ist jetzt in einer Breite so, dass jemand, der sich einen virtuellen Server oder einen Root-Server im Internet kriegt, der kann ihn damit betreiben. Und er könnte auch einen Server betreiben, den er geerbt hat. Aber wenn er hauptberuflich damit arbeitet, dann würde ich dann noch tiefergehende Literatur empfehlen an der Stelle. Die kommt aber nicht in einem einzelnen Buch. Wir haben rund 30 Kapitel. Das heißt, 30 unterschiedliche Themengebiete. Man kann sich jetzt vorstellen, bei 30, das sind wir mit 40 Seiten pro Kapitel plus minus. Also im Schnitt, wohlgemerkt, es gibt Kapitel, die sind deutlich länger, es gibt Kapitel, die sind deutlich kürzer. Mit 30 verschiedenen Themen und 40 Seiten können wir nicht so in die Tiefe gehen, dass wir das alles wirklich bis ins letzte Detail auseinandernehmen.

41:36

Christian Ja, also letztendlich hätte man dann in den 40 Kapiteln jeweils auch 40 spezielle Bücher.

41:42

Dirk Oh, die gibt es ja auch. Ja, die gibt es ja auch, genau.

41:45

Christian Aber ich sehe das eigentlich aus dem Softwareumfeld auch häufig, dass manchmal gar nicht so viel nötig ist, um Leuten jetzt einen Einstieg zu geben. Klassisches Beispiel in Java wäre Testen mit JUnit. Eigentlich kann man das in 10 Minuten erklären, wie man so einen einfachen Testfall schreibt und es gibt auch tatsächlich kein JUnit Buch, also es gibt schon welche aber die sind alle relativ alt, jetzt kein modernes und das wundert mich eigentlich, weil JUnit ist ein Framework, ein Library, die jeder irgendwie benutzt, aber trotzdem gibt es da keine aktuelle Literatur was irgendwie komisch ist und das heißt faktisch reichen einfach so ein paar Seiten mal so nebenbei um einzusteigen und dann kann man zum Beispiel auf die Referenzdokumentation zurückgreifen. Deswegen, wie gesagt, manchmal reicht eine kurze Einführung, um einen auf den Weg zu bringen und das muss manchmal gar nicht so tief sein. Dann wird es auch schnell langweilig, dass man sagt, warum soll ich das jetzt lesen? Weil viele, glaube ich, die Bücher auch durchaus linear durchlesen und dann zu einem Punkt kommen, so, mein Gott, nochmal, das ist aber sehr speziell. Ob ich das brauche, weiß ich nicht. Und dann wird es langweilig, die Leute fangen an zu blättern und dann legen sie das Buch zur Seite, das bringt dir auch nichts.

42:53

Dirk Ja, genau. Also es gibt natürlich viele solche Beispiele. Pytest unter Python wäre auch noch so ein Beispiel. Was man in den Grundzügen sehr schnell verstanden hat. Wenn es ins Detail geht, muss man vielleicht die Community fragen oder heutzutage fragt man dann irgendwelche Large Language Models und wie man Sachen umsetzt und merkt sehr, sehr schnell, dass die auch nicht immer richtig liegen. Aber ja. Ein Buch hat vielleicht an der Stelle den Vorteil, dass es von Leuten geschrieben wird, die damit zu tun haben, die Erfahrungen damit bringen und die genau wissen, worauf sie hinweisen müssen. Wie heißt es so schön? Neue Besen kehren gut, das beziehe ich mal auf AI, aber die Alten wissen, wo der Dreck steckt. Also es spielt gerade in der Systemadministration spielt Erfahrung eine megagroße Rolle. Wenn man genügend Erfahrung hat, riecht man, woher Probleme kommen können. Das wirst du für deinen Bereich genauso haben, denke ich mal.

43:42

Christian Das merke ich immer dann, wenn ich ein Java-Fortgeschrittenen-Seminar gebe, wenn mir dann auffällt, was ich rede und im Hinterkopf sofort schon weiß, ach, eigentlich wirst du das nie brauchen. Weil das sind ganz viele Sachen, die heute vom Framework abgenommen werden, wo man das eigentlich nicht so programmieren muss. Also Threading zum Beispiel, da kann man tief einsteigen, aber normalerweise lautet die Richtlinie, vom Threading machst du einen großen Bogen. Du lädst alles auf das Framework ab, was irgendwie mit Threading angeht und hältst schön deine Finger da irgendwie raus, um irgendwelche selber Synchronisationen oder sowas zu machen. Und an einem Kurs stellt man es irgendwie vor, weil es ein Teil der Standardbibliothek ist. Aber das sind halt auch so Punkte, wo ich dann innerlich denke, so unwahrscheinlich, dass es jemals benutzt wird.

44:26

Dirk Ja, das ist vermutlich so. Das gilt aber im Serverbereich genauso. Also man kann es bis ins Letzte ausdiskutieren und jedes einzelne Bit und Byte und jeden einzelnen Kern- und Parameter besprechen, wovon man bei 90 Prozent weiß, dass sie eh nie gebraucht werden.

44:39

Christian Wie war denn die Abstimmung dann von den Kapiteln und den Inhalten im Buch? Das ist ja jetzt genau so ein Punkt, den man in der Gruppe, ihr habt ja zu mehreren geschrieben, ihr schreibt weiter mit mehreren. Das ist ja durchaus eine Frage, dass man sich irgendwie erstmal einigen muss, welche Themen wollen wir grundsätzlich aufnehmen, was ist so tief, wo wollen wir vielleicht ein bisschen Tiefe wegnehmen, wo wollen wir in die Breite gehen. Das ist ja permanent eigentlich eine Diskussion. Wie macht ihr das? Setzt euch zusammen, einmal im Jahr, zweimal im Jahr. Große Skype- oder Discord-Runde. Kaffee, Kuchen.

45:12

Dirk Ja, fast so. Also das allererste, als wir das allererste Buch geschrieben haben, mit der allerersten Gruppe, haben wir uns tatsächlich in Person getroffen in Stuttgart und haben also unsere Ideen durchdiskutiert, was jeder so für Vorstellungen hatte. Von dieser ersten Gruppe ist nur noch einer tatsächlich übrig und das bin ich. Und selbst der Lektor hat mittlerweile dreimal gewechselt. Das ist ja auch relativ lang. 2009 haben wir uns das erste Mal getroffen und danach haben wir uns nur noch virtuell getroffen. Wir haben eine Mailing-Liste zusammen, auf der wir uns abstimmen, wo wir Sachen miteinander besprechen. Und wir haben halt einmal pro Buch wirklich ein virtuelles, physisches Treffen, wo wir alle anwesend sind, also so wie wir jetzt miteinander sprechen. Jetzt das nächste wird über Open Talk stattfinden, wo wir einfach darüber diskutieren, was zu machen ist, wir haben schon Ideen, wir haben, benutzen Dokumente, an denen wir gemeinsam arbeiten, also bei meinem Fall jetzt CryptPad als Beispiel, und sprechen dann darüber bei der ersten Auflage gab es natürlich einen Riesenkampf das möchte ich nicht verhehlen, was überhaupt in das Buch rein soll und wie tief wir eigentlich gehen wollen und, ich habe dir die Frage noch nicht beantwortet, wie wir dazu gekommen sind, welche Distributionen wir einsetzen. Die Idee war, dass wir Server-Distributionen nutzen, die man gezielt auf dem Server einsetzen kann und auch die, die man sich selber installieren darf. Von daher waren die kommerziellen Distributionen ausgeschlossen, aber wir haben immer die Open-Source-Pendance dazu genommen. Also am Anfang waren es Debian, Ubuntu, CentOS und OpenSUSE. Mittlerweile ist ja CentOS eine Rolling oder eine Rolling möchte ich nicht sagen, aber CentOS Stream ist ja mittlerweile nicht mehr direkt an einen Red Hat angelehnt, sodass wir uns dafür Rocky Linux für den Community Fork entschieden haben, und wir wollten einfach Distributionen haben, die möglichst 90% aller Fälle abdecken. Dass es immer noch irgendwelche Installationen gibt von Distributionen, die halt nicht in diesem Muster sind, steht mal außen vor, aber wir wollten halt eine möglichst breite Breite damit abdecken. Damit haben wir zwei Debian-basierte Distributionen gehabt und zwei RPM-basierte Distributionen gehabt an der Stelle, genau. Und jetzt wollte ich dir die eigentliche Frage noch beantworten, wie es zu den Inhalten kam. Wir haben relativ hart gefightet und ich habe relativ gegen den Widerstand aller durchgesetzt, dass es ein Kapitel der Administrator gibt. Und alle Leute haben gesagt, du spinnst, das gehört nicht ins Buch. Und tatsächlich war das Kapitel das Kapitel, was die meisten positiven, das meiste positive Feedback bekommen hat, nachdem das Buch erstmalig erschienen ist. Und wo man merkt, der Stefan Kania, der ein langer Wegbegleiter ist, der ist halt als Dozent unterwegs gegeben, der hat Samba-Schulung gegeben und ist auch verantwortlich für den Samba-Teil und alles, was rund um Kerberos ist. Der hat das als Lehrer weitergegeben und ich habe den Teil, den ich gemacht habe, aus der Erfahrung als Sysadmin weitergegeben. Also ich weiß, dass als SysAdmin die Rolle des, Systemadministrators nicht so einfach definiert ist. Und deswegen haben wir die im Buch einfach definiert und darüber dann auch sehr viel Feedback bekommen, glücklicherweise.

48:26

Christian Ich habe das Buch ja auch angefangen, von vorne nach hinten und nicht jetzt in der Mitte. Und das war das erste Kapitel und auch, muss ich sagen, das hat mir auch sehr gut gefallen. Etwas, was ich auch spontan nicht unbedingt in so einem Buch erwartet hätte. Ich hätte jetzt irgendwie gleich gedacht so, okay, wie installiert man Linux? Wie wähle ich eine Partition aus? Das sind, glaube ich, so die klassischen Anfänge. Und plötzlich beginnt das Buch mit der Frage, was macht ein Systemadministrator? Was sind eigentlich die Rollen? Was sind die Verantwortlichkeiten? Und ich dachte so, okay, da habe ich jetzt noch nie so richtig drüber nachgedacht, weil ich glaube, dass es, dass man so ein intuitives Verständnis für so ein Berufsbild hat. Also auch ich fand die Zusammenfassung schon sehr, sehr gut. Also bleibt drin. Ich glaube, jetzt ist sogar auch ein Update des Buches geplant. Wie wird sich das entwickeln? Kannst du da schon was zu sagen, was sich ändern wird, was neu hinzukommt, ob was wegkommt?

49:16

Dirk Also gerade das Kapitel der Administrator wird sich groß ändern, weil man so heute so nicht mehr arbeitet. Wir haben zu Beginn gesprochen über Terraform, Ansible und Puppet. Wir sind heute deutlich näher daran, das alles zu automatisieren. Man konnte früher Administrator sein, ohne dass man programmieren konnte. Das ist heute auch nicht mehr der Fall. Also heute muss man programmieren können und auch skripten können, um Sachen automatisieren zu können. Das wird ein paar Änderungen erfahren an der Stelle. Wir werden natürlich neuere Versionen mit draufnehmen. Wir werden den FTP-Server beispielsweise rausschmeißen, weil kein Mensch setzt heute meinen FTP-Server auf.

49:49

Christian Solche Sachen.

49:51

Dirk Also das Ganze wird ein bisschen moderner werden und wird ein paar modernere Themen natürlich noch erweitert werden. Und eine Sache, die vielleicht dann auch noch speziell ist bei Linux-Systemadministrationen, ist, dass sich an der Basis relativ wenig ändert. Gut, du hast angesprochen von System V Init auf systemd, das war natürlich ein Riesenschritt, aber solche Riesenschritte passieren nicht alle Jahre.

50:14

Christian Ja.

50:16

Dirk Und ob ich jetzt, sage ich mal, die Datenbank MariaDB in Version 10.3. Irgendwas habe oder in 11.2. irgendwas, das macht keinen, für die Tiefe des Buches macht es keinen so großen Unterschied an der Stelle.

50:30

Christian Ja, kann ich mir vorstellen. Vor allen Dingen, weil die Produkte ja durch ihre Features sich eher unterscheiden und weniger durch den administrativeren Teil.

50:38

Dirk Ja, genau. Genau, genau. Und wo du das gerade gesagt hast, das wollte ich noch ergänzen, ist, man findet in dem Buch keine Installationsanleitung für ein Linux-System.

50:46

Christian Genau, das findet man nicht. Das heißt, ihr geht einfach davon aus, dass die Leute das schon können.

50:51

Dirk Wir gehen davon aus, dass sie einfach ein System installiert haben. Wie gesagt, sie haben es geerbt, irgendwoher.

50:58

Christian Plötzlich, zack, ist es da.

51:00

Dirk Oder sie haben einen virtuellen Server vom Cloud-Provider ihrer Wahl zur Verfügung gestellt bekommen.

51:04

Christian Ja, wo ich dann klicke, was möchte ich haben und bums, ist das fertig.

51:07

Dirk Genau.

51:07

Christian Genau, ja. Mich interessiert so ein bisschen so dein Schreibprozess, wie du schreibst, wie du das in einen Alltag integrierst. Wie ist das bei dir? Du machst die Tür zu, sagst Hund und Frau und Pferd, ihr bleibt heute draußen. Wie geht's dann weiter?

51:22

Dirk Also ganz zu Beginn war es so, dass ich die Macht der weißen Seite kennengelernt habe. Ich glaube, das kennt jeder. Ich wusste vorher nicht, was eine Schreibhemmung ist. Mittlerweile weiß ich das auch. Ich mache mir halt im Vorfeld schon relativ viele Gedanken, wenn ich weiß, dass eine neue Auflage ansteht, was sich verändern möchte. Und wir sprechen auch im Team durch, was die Leute denken. Das sind ja alle gestandene Linuxer. Was die Leute denken, was in das Buch rein soll. Und jeder hat da Schwerpunkte. Und auch jemand, der das Kapitel vielleicht nicht gerade zu Papier bringt, weiß vielleicht, dass ich in einem bestimmten Bereich des Buches Dinge getan habe, die auf jeden Fall Einfluss nehmen sollten ins Buch. Also ich mache mir im Vorfeld Gedanken darüber, was da rein muss und dann mache ich mir Gedanken darüber, wie es mit ehrlicherweise möglichst geringem Aufwand in die bestehende Geschichte passt. Ich möchte nicht das komplette Kapitel from scratch neu schreiben müssen, sondern wenn es ein spezifisches Feature gibt, was interessant ist und was mit reingenommen werden soll, dann überlege ich, an welcher Stelle ich das gut mit reinnehmen kann. Und die grundlegende Entscheidung ist ja, packe ich das mitten mit rein oder nehme ich das im Nachgang noch mit dazu? Also wir haben zum Beispiel, ich habe das Kapitel über Versionskontrollsysteme geschrieben, wir haben mit Gitolite begonnen, das war ein Git-Server auf Kommandozeilen-Ebene, einfach auf Shell-Basis. Und wir haben jetzt neu als Beispiel Gitea drin, und das wird sich wahrscheinlich Richtung Forgejo verändern, um den eigenen Git-Server aufzumachen. Das ist ein Thema, was man ans Ende eines Kapitels mit dazu machen kann. Wenn man aber, nehmen wir ein Beispiel MariaDB, wenn man jetzt merken würde, dass sich was am Replikations- Algorithmus ändern würde oder an der Maßnahme ändern würde, wie die Replikationen funktionieren. Dann muss das natürlich mitten im Kapitel mit aufgenommen werden. Und dann muss man auch schauen, dass es durch das Kapitel durchgezogen wird und auch auf das Neue bezogen wird.

53:14

Christian Aber jetzt mal zurück zum eigentlichen Schreibprozess. Also auf der einen Seite machst du dir Gedanken und sagst, okay, das und das habe ich geschrieben und ich weiß, dass ich das und das integrieren muss. Nimmst du dir dann Zeit, dass du sagst, okay, jetzt mache ich genau diese Änderung fertig? Und setze mich so lange hin, bis das fertig ist. Oder wie integrierst du den Schreibprozess selber in deinen Alltag?

53:36

Dirk Also ich bin ja abhängig Beschäftigter. Das heißt, ich bin zwar relativ frei in meiner Zeiteinteilung, aber ich muss natürlich auch meine Pflichtstunden pro Woche dem Unternehmen widmen, was ich auch gerne mache. Aber ich nehme dann Inseln raus, an denen ich mir Zeit nehme, wo ich sagen muss, diese Stunde, diese zwei Stunden setze ich mich jetzt ans Buch. Und das weiß meine Frau, die Hunde wissen es natürlich nicht, aber meine Frau hält die dann in Schach. Auf Stichwort kommt der eine Hund. Und die nehme ich mir Zeit und dann gucke ich, wie weit ich in diesem Zeitfenster komme. Und ich versuche dann, einen Punkt zu hinterlassen. Wir haben das Buch in LaTeX geschrieben. Ziel ist, alles, was committed ist und was gepusht ist im Git-Repo, muss sich übersetzen lassen, sodass der Schreibprozess der anderen nicht gehemmt ist. Und ich verlasse das Projekt dann in dem Zustand, wie ich da fertig werde, setze mir einen Marker im Quelltext, wo ich dann weiterarbeiten muss und arbeite dann an der Stelle irgendwann weiter.

54:36

Christian Also Buchschreiben wie Softwareentwicklung.

54:39

Dirk Also gerade wenn es LaTeX ist, ist es ja nichts anderes. LaTeX ist ja der Quelltext, der einfach übersetzt wird. Genau.

54:45

Christian Und bist du dann primär oder nur mit deinen eigenen Kapiteln, bei Änderung oder würdest du dir nicht die Freiheit rausnehmen zu sagen, so ja, bei dem und dem ändere ich jetzt mal das und das?

54:59

Dirk Da wir einen Kollegen hatten, der mit Git nicht so gut zurechtgekommen ist, haben wir das Buch mit einem Hauptdokument und vielen Includes bearbeitet. Also jedes Kapitel ist ein eigener Include in einem Hauptdokument und jeder hat einfach an seinem Include gearbeitet. Und wenn man Änderungen hatte, hat man demjenigen, der das Kapitel geschrieben hat, Bescheid gesagt, dass er die Änderungen durchführen soll.

55:18

Christian Okay, also eigentlich nicht verteilt.

55:21

Dirk Das ist nicht ganz so, wie es in der Softwareentwicklung heutzutage läuft. Also wo man es mit einem Pull- oder Merge-Request machen würde, nee, das ist richtig. Aber weil um Pull- oder Merge-Requests durchführen zu können, muss man noch ein bisschen Basiswissen mitbringen und da auch vielleicht eine innere Blockade für lösen an der Stelle.

55:36

Christian Ich glaube, die Leute müssen dafür auch gemacht sein, dass sie akzeptieren, dass sie, wenn sie morgens ihr Buch aufmachen, dass es dann plötzlich eine Änderung irgendwo gibt. Dann muss man auch sagen, ja, okay, finde ich gut, akzeptiere ich. Viele haben ja doch irgendwie so, mein Text, nur ich darf ändern. So was in der Softwareentwicklung eigentlich verpönt ist, dass es so ein Ownership gibt. Eigentlich sollte jedem Code oder jeder Code allem gehören. Ich glaube, als Autorenteam ist es deutlich schwieriger zu sagen, hey, das ist doch alles unser. Jeder kann irgendwas ändern. Wahrscheinlich würde das nur zum Streit führen.

56:08

Dirk Ja, also mein Arbeitstag beginnt dann mit einem Git-Pull, natürlich, um mich selber auf den aktuellen Stand zu bringen. Die zu Beginn gesprochenen Update-Skripte, ich pulle jeden Morgen alle meine Repositories, die ich habe. Aber wenn ich anfange, am Buch zu arbeiten, pulle ich vorher auch nochmal. Und dann schreibe ich halt, ja. Und manchmal klappt es halt besser, meine Stichpunkte in Fließtext zu übersetzen, und manchmal klappt es halt nicht so gut.

56:30

Christian Was nutzt du für einen TeX-Editor?

56:33

Dirk Also ich habe eine ganze Zeit Visual Studio Code benutzt als TeX-Editor. Dann habe ich eine ganze Zeit lang Vim auf der Kommandozeile benutzt. Und im Moment bin ich in der Testphase von Zed, das ist ein neuartiger Editor. Atom habe ich eine Zeit lang benutzt. Aber auf der Kommandozeile bin ich Vim-Fan. Das finde ich auf jedem System und bei grafischen Editoren bin ich noch so ein bisschen auf der Suche. Im Moment ist es Zed, also Zed als Editor.

57:04

Christian Du hattest, glaube ich, mal gesagt, dass ihr von TeX weg müsst, auch wenn ihr es nicht wirklich wollt. Wie wird es dann in der Zukunft werden?

57:14

Dirk Also Grundlage ist, dass der Verlag generell mit XML arbeitet. Und der ganze Workflow im Verlag oder bei den Dienstleistungen des Verlages ist meines Wissens nach, da würde ich gerne eine Korrektur erbitten, falls ich da mit jetzt großen Mist erzähle, ist auf Word-Dokumente ausgelegt. Ich habe unter Linux, ich schreibe unter Linux, ich habe unter Linux kein Word.

57:37

Christian Das hätte mich jetzt gewundert, wenn du jetzt gesagt hast, nur für das Schreiben benutze ich jetzt extra einen Windows-PC, den ich auch komplett administriere, so nebenbei.

57:48

Dirk Aber das scheint in unserer TeX-Ecke nicht so selten zu sein. Also einer unserer Autoren schreibt in DocBook und hat sich Konvertierungen geschrieben, um das in LaTeX zu übersetzen. Also er hat auch nicht nativ in LaTeX geschrieben. Und ein weiterer Autor, der relativ viele Bücher veröffentlicht hat, der hat einen Workflow, der von Markdown ausgeht und der Markdown dann in ein, Satzformat verändert, was der Verlag dann weiterverarbeiten kann und an diesem Markdown-Workflow wollen wir uns beteiligen. Annähern, da wollen wir dran teilhaben. Das wollen wir halt genauso machen. Weil einer der Autoren, der zu Beginn geflucht hat gegen LaTeX, der hat am Ende gesagt, ich möchte nie wieder ein Buch mit Word schreiben. Den haben wir also bekehrt, weil gerade größere Dokumente und vielseitige Dokumente doch mit LaTeX schöner sind an der Stelle. Und wir wollen einfach auch etwas haben, was man sauber versionskontrollieren kann, was man so gut in einem Git-Repository ablegen kann. Also ein Quelltext-basiertes Format.

58:42

Christian Ja, also Änderungsverfolgung in Office ist schon mal was Großartiges. Wenn man natürlich dann irgendwie plötzlich jede Formatänderung drin hat, weil die Sprache geändert wurde, dann kann man schon mal fluchen. Aber das finde ich erstmal grundsätzlich gut, dass es eine Versionsverwaltung oder eine Versionsverfolgung gibt. Ich würde langsam zum Ende kommen und dich jetzt nochmal fragen, du hast ja jetzt als Autor lange, lange Erfahrung, wenn jetzt Menschen ein Buch schreiben wollen, ich möchte auch ein Buch schreiben, das ist mir die Frage, warum sollte man ein Buch schreiben und wie geht man dann vor, was würdest du Neuautoren, raten zur Motivation, dass einem klar sein muss, wenn ich ein Buch schreibe, dann muss ich vorbereitet sein auf das und das und ich werde dann Millionär und muss nie wieder arbeiten. Und kann dann auf die Seychellen ziehen für immer. Was würdest du neuen Autoren raten? Oder welchen Zahn würdest du denen ziehen?

59:35

Dirk Ich habe natürlich auch darüber schon einen Vortrag gehalten. Davon gibt es allerdings keine Videoaufzeichnung. Da können wir vielleicht nur die Slides teilen. Erstmal die Erwartungen zurückschrauben. Als Autor eines Fachbuches wird man nicht reich. Also ich kann von der Open Source Press sagen, der Dr. Christoph Wirz, der früher der Verlagsleiter von Open Source Press war, der hat mal ein Beispiel vorgegeben. Der hat gesagt, dass man vom Verlagsnetto 11% als Autor ausgeschüttet bekommt. Jetzt muss man wissen, wie der Buchhandel funktioniert. Meine Frau ist gelernte Buchhändlerin, von daher bin ich da ein bisschen im Thema. Das Verlagsnetto ist etwas unter 50% vom Verkaufspreis. Von diesen etwas unter 50 Prozent bekommt man also 10 Prozent oder 11 Prozent, und den Rest steckt sich der Verlag in die Tasche. Halt, stopp, der Verlag hat auch Ausgaben. Der Verlag setzt Lektoren ein, der Verlag setzt Korrektoren ein, der Verlag kümmert sich um den Satz und das Drucken. Das Drucken selber ist gar nicht so teuer, wie man eigentlich denken würde. Deswegen sind E-Books nicht so viel billiger, wie man denken würde, weil das gedruckte Buch an sich nicht so teuer ist. Ich würde jedem erstmal sagen, die Erwartungen zurückzuschrauben, was den finanziellen Output angeht. Wenn ich mir angucke, was ich für das erste Buch an Zeit aufgewendet habe und was ich am Ende rausbekommen habe, dann war das so weit unter Mindestlohn, dass es schon fast kriminell ist. Was ich aber sagen kann, ist, dass man in der heutigen Zeit, es ist ja leider so, dass die Sachen, die die meiste Reputation bringen, auch am schlechtesten bezahlt sind. Frag mal Krankenschwestern, Polizisten und Feuerwehrleute. Das ist halt so, dass man, wenn man ein Buch in seinem Lebenslauf hat, das bringt schon eine Menge Reputation. Man wird als Fachmann in seinem Bereich angesehen. Und das ist zumeist auch so. Also die Leute, die Bücher schreiben, geben einen Bruchteil ihres Wissens im Fachbuch bekannt. Sie haben darüber hinaus noch eine Menge Wissen. Und sie haben gelernt, das didaktisch so zu formulieren, dass es verstehbar ist. Hoffentlich.

1:01:37

Christian Ja, hoffentlich, genau. Wenn man da anfängt zu schreiben, weiß man das noch vielleicht nicht so richtig.

1:01:44

Dirk Aber auch da müsste es vielleicht am Lektor noch mal abprallen, wenn es nicht so wäre an der Stelle. Also es ist gut, dass es da noch die Rettungsinstanzen gibt, nenne ich sie mal. Also man wird als Fachperson gesehen in dem Bereich. Und das ist, glaube ich, ein nicht wegzudiskutierender großer Vorteil. Und gerade wenn man vielleicht selbstständig ist, wie du, ich glaube, du bist selbstständig, Christian, oder?

1:02:07

Christian Ja, schon seit 30 Jahren. Ich habe nie was anderes gemacht.

1:02:10

Dirk Ja, dann ist das natürlich gut, wenn du Vorträge halten willst oder wenn du Schulungen gibst, sagen kannst, ich könnte auch mein Buch dazu kaufen. Oder ihr könnt euch von meiner Qualität überzeugen, wenn ihr euch das Buch anguckt. Und ich glaube, das Buch hat auch immer noch eine Daseinsberechtigung, weil es didaktisch aufbereitet und recherchiert ist. Also im Gegensatz zu vielen, vielen Artikeln, die man sagen kann, ich sage häufig Stack Overflow Admins oder Copy-Paste Admins, Leute, die irgendwas kopieren und einfügen und nicht wissen, was sie tun. Wenn man Grundlagen lernen möchte, kommt man am Buch heute, glaube ich, nicht vorbei. Oder an einer Grundlagenschulung.

1:02:49

Christian Das passt ganz gut dazu, dass ich heute, morgen noch ein Video, ich will jetzt nicht sagen am Klo geguckt habe, aber ich glaube das war so, von einem YouTuber, der sich mit AI-Slop beschäftigt hat und gesagt hat, dass YouTube, also Google das überhaupt nicht juckt, was da hochgeladen wird. Hauptsache es wird geteilt und geliket und die Qualität wird schlecht und dass die Original- oder das Autoren oder YouTuber oder. Videoblogger darunter leiden, weil sie sich viel Mühe machen, ordentliche Texte auszuarbeiten, das Material vorzubereiten. Das dauert ja Tage oder Wochen oder vielleicht sogar Monate, irgendwie über ein Thema zu recherchieren, das dann aufzubereiten. Und plötzlich kommt dann so ein AI-generiertes Video daher, welches irgendwie auch noch falsch ist. Und irgendwas zusammenfasst, was dann an falsche Informationen im Internet rumschwirrt. Und die Leute hören das, weil es vielleicht angenehm durch eine KI-Stimme erzählt wird, mit so einer Musik im Hintergrund. Aber da sind Fehler drin, das merken sich Menschen. und haben dann eine falsche Vorstellung von irgendwelchen Dingen. Sein Thema war, glaube ich, irgendwie Geschichtstexte oder so. Es gibt ja immer so einen KI-Kanal, irgendwie bla bla bla zum Einschlafen, also Geschichte zum Einschlafen. Alles KI generiert. Und der Mensch, der das quasi eigentlich beruflich macht, hört sich das an und sagt, das ist schlecht, das ist fürchterlich. Und da sind Fehler drin. Aber der Kanal ist total beliebt. Und ich glaube, das ist auch für uns Autoren eine mögliche Gefahr, dass unsere Bücher durch den Verlag einen gewissen Preis haben müssen, dass vielleicht auch Administratoren, in meinem Fall Programmierer, nicht mehr bereit sind, das Geld zu bezahlen, meinen, sie würden mit KI bessere Antworten bekommen oder zumindest vielleicht günstigere Antworten bekommen. Aber die weisen einem nicht wirklich auf Fehler hin oder enthalten Fehler oder enthalten schwere Sicherheitslücken. Also letztendlich ein dummer Teufelskreislauf.

1:04:50

Dirk Ja, klar. Ja, also ich meine, wir sehen das auch in der Politik, dass die Themen, dass die Leute, die am lautesten sind, noch die meiste Medienpräsenz haben. Das leben wir, glaube ich, im Internet genauso. Und die Leute, die die meiste Beachtung finden, sind nicht unbedingt die Leute, die die Antworten haben. und, ich möchte an der Stelle auch nicht zu politisch werden, aber man muss sich überlegen, wem man sein Vertrauen schenkt, sage ich mal. Man würde vielleicht aus einem YouTube-Video sich überlegen, zu sagen, ja, ich würde damit ausprobieren, eine bestimmte technische Umsetzung zu machen. Würde ich dir meine Kinder anvertrauen? Würde ich dir meine Finanzen anvertrauen? Oder würde ich da mein ganzes Geld draufsetzen? Das vielleicht eher nicht.

1:05:41

Christian Ja, also ich bin ja auch froh, dass ich in einem Bereich bin, wo das Risiko, wenn ich Mist erzähle, sehr gering ist. Ich habe einen Freund, der bei O2 die Datenbank gepflegt hat und er sagte, Voraussetzung war, ich muss ein Gewerbe anmelden, GmbH, damit ich, sagte er, abgesichert bin, damit ich Kohle habe, falls mir irgendwas passiert. Und O2 sagt, du hast unsere Datenbank zerschossen, wir verklagen dich, also braucht er Kohle. Und deswegen musste er ja tatsächlich aus Rechtsgründen die GmbH gründen. Ich hatte immer Glück in meinem Umfeld, Java, mein Gott, wenn ich mal irgendwas Falsches erzähle, wie, oh, ein Int-Datentyp ist 6-Byte, dann wird da keiner irgendwie, wird kein Leben dadurch geopfert. Also relativ risikofrei. In deinem Bereich sieht es natürlich schon mal ein bisschen anders aus, aber trotzdem, wenn man als lehrende Kraft tätig ist, glaube ich, ist das Risiko eher geringer.

1:06:40

Dirk Ich glaube, es unterscheidet sich auch nochmal, ob man selbstständig tätig ist oder nicht selbstständig tätig ist. Also ich habe natürlich eine Haftpflichtversicherung und... Wenn ich nicht grob fahrlässig handele, ist relativ viel schon abgedeckt im Vorfeld. Das ist nochmal was anderes, als wenn ich damit mal wirklich unmittelbar mein Geld verdiene. Ich glaube, das spielt jetzt nochmal eine andere Rolle. Habe ich mich aber noch nicht mit auseinandergesetzt, ehrlicherweise.

1:07:06

Christian Hatten wir nicht bei Intel, dass Intel beklaut wurde mit 14.000 Dokumenten? Oder war das nicht Intel?

1:07:15

Dirk Von meiner ersten Arbeitgeberin sind auch eine Menge Datensätze verschwunden und als Steuer-CD weiterverkauft worden. Also sowas gibt es natürlich auch, ja.

1:07:24

Christian Dann würde ich sagen...

1:07:28

Dirk Ich wollte noch zwei, drei Tipps mitgeben. Entschuldige bitte. Wenn man eine Idee hat, ein Buch zu schreiben, sollte man einen Verlag finden, mit dem man das machen möchte und sollte sich vorher vielleicht mal Gedanken darüber machen, ob es das Buch vielleicht schon gibt. Wenn es das Buch schon gibt, sich überlegen, was der Mehrwert ist, dass man noch ein weiteres Buch zu dem Thema veröffentlicht.

1:07:46

Christian Ja, ich glaube, das ist wahr. Vor allen Dingen bei dem gleichen Verlag, wenn die dort schon ein identisches Buch haben, dann werden die wahrscheinlich nicht motiviert sein, noch ein Konkurrenzbuch aufzunehmen. Es sei denn, die wollen das dann einstellen. Das passiert auch schon mal, wenn die Autoren das Buch nicht weiterpflegen wollen. Das gibt es. Dann wäre der Tipp eher, bei einem anderen Verlag mal nachzufragen, Technikverlag, die möglicherweise damit ein Konkurrenzprodukt besetzen können. Aber das wird natürlich auch schwierig. Und ich sag mal, wir haben mit Rheinwerk einen großen Verlag, der super Werbung für unsere Bücher macht. Jetzt die Java-Insel, die habe ich vor zwei Wochen das Update abgegeben. Das müsste gerade im Druck sein, die kommende Version. Und ich habe sofort vom Marketing-Team eine E-Mail bekommen mit so einer langen Liste, wo man das Buch bewerben wird. Und ich bekomme, glaube ich, auch ein-, zweimal im Jahr immer auch eine Liste, wo das Buch beworben wurde. Also da steht dann mal Linux-Ausgabe, so und so viel, so und so viel. Drei Viertel Werbung und so weiter. Und ich glaube, das ist auch ein Grund, warum man sich immer gut überlegen muss, irgendwas im Selbstverlag zu veröffentlichen. Kann man machen, aber das ganze Marketing, diese große Maschine, die dahinter sitzt, das kann man als Einzelperson unmöglich ersetzen.

1:09:08

Dirk Ich würde auch zwei Tipps an der Stelle auch noch mitgeben wollen. Der eine Tipp ist, wenn man Selbstverlag machen möchte, sollte man sich auf jeden Fall ein Korrektorat leisten. Und damit verbunden, Bücher immer in seiner Muttersprache zu schreiben. Als ich meine erste Korrekturfahne, der ersten Auflage vom Admin-Buch bekommen habe, habe ich gedacht, ich wäre kein deutscher Muttersprachler.

1:09:34

Christian Das war das Bild, was du mal in deiner Präsentation geteilt hast. Kann das sein?

1:09:37

Dirk Ja, das kann sein. Ja, das ist ein anderes Bild gewesen, aber das sah bei mir tatsächlich so ähnlich aus. Und man lernt dann auch Korrekturzeichen, das ist auch nochmal ein anderes Thema an der Stelle, aber schreibt es bitte in eurer Muttersprache und, leistet euch jemanden, der es fachlich und auf Sprache korrigieren kann. Beides wichtig.

1:10:03

Christian Finde ich noch nicht so ein schönes Schlusswort. Hast du noch ein besseres Schlusswort für mich?

1:10:07

Dirk Man wird berühmt und zu Vorträgen eingeladen. Wenn man Bücher schreibt. Nein, also es macht Spaß. Und es macht Spaß, seinen eigenen Namen gedruckt im Regal stehen zu sehen. Und wenn man in der Buchhandlung geht und sieht, da steht der eigene Name im Regal, das hat schon was und das macht was mit einem. Das ist schon wirklich toll. Und wenn man das Buch in der Hand hat, ist es auch wirklich toll. Aber der Weg dahin ist ein sehr langer und ein sehr steiniger. Also es ist wirklich Arbeit. Das macht man nicht mal ebenso nebenbei, wie man Blogartikel rausrotzt. Das ist wirklich viel Arbeit. Und gerade wenn es in Richtung Abgabetermin geht, dann wird es immer stressiger. Gewohnheitsgemäß wissen wir ja, dass wir am effizientesten sind, je näher wir am Abgabetermin sind. Und da ist schon wirklich viel zu tun an der Stelle. Aber alleine die Selbstbestätigung, die Befriedigung, das eigene Buch gedruckt in den Händen zu halten, das hat was. Das hat wirklich was. Auch in der heutigen Zeit, wo wir fast alles nur noch digital lesen.

1:11:01

Christian Ja, das kann ich bestätigen. Ja, dann danke ich für dieses tolle Gespräch und wünsche dir alles Gute.

1:11:07

Dirk Tschüss. Ja, gleichfalls Christian. Dankeschön.