#58 Software-Updates, alte Software, Long Term Support und End of Life-Dates

Alte Software akzeptieren oder lieber jedem Update hinterherjagen?

Podcast als Video: https://youtu.be/94RZcJefzR8

Das ist die Balance, die jeder finden muss. Wann update ich Software? Wie lange kann ich alte Software betreiben? Ab wann ist alte Software ein wirkliches Risiko? Sollte ich bei jeder neuen Major-Version direkt updaten? Bringt es überhaupt etwas, eine alte Software auf etwas Neues zu migrieren, ohne neue Funktionalität zu bekommen? Welche Risiken verbergen sich hinter den Updates? Ist der klassische Spruch "Never touch a running system" noch aktuell oder sogar ein Fehler? All das und weitere Themenbereiche wie Long-Term-Support, End of Life-Dates, die Software-Metrik Dependency Drift, Dependabot und rostende Software besprechen wir in dieser Episode.

Bonus: Warum früher alles besser war, sogar die Zukunft und warum Legacy immer das Geld verdient.

Unsere aktuellen Werbepartner findest du auf https://engineeringkiosk.dev/partners

Das schnelle Feedback zur Episode:

👍 (top) 👎 (geht so)

Das tiefere Feedback (gerne auch als Voice Message)

Email: stehtisch@engineeringkiosk.dev
Mastodon: https://podcasts.social/@engkiosk
Twitter: https://twitter.com/EngKiosk
WhatsApp +49 15678 136776

Gerne behandeln wir auch euer Audio Feedback in einer der nächsten Episoden, einfach Audiodatei per Email oder WhatsApp Voice Message an +49 15678 136776

Sprungmarken

(00:00:00) Intro

(00:01:26) Video-Podcast

(00:02:02) Alte Technologien (16-Bit Applikationen, PHP und JQuery und JavaScript-Abhängigkeiten) und Version Pinning

(00:07:37) Was oder Wer ist dependabot?

(00:09:00) Ist Subversion alte Software? Und was bringt es nach git umzusteigen?

(00:12:49) Migrationen ohne neue Funktionalität und Software an die sich niemand ran traut

(00:16:16) Wann weiß ich, wann ich die Software updaten sollte? End of Life-Dates

(00:21:30) Software rostet: Updates für Blackbox-artige Software und nächtliche CI runs sind

(00:27:08) Sollten Support / End of life dates auch an Kunden kommuniziert werden?

(00:29:04) Long Term Support (LTS) / Extended Long Term Support (ELTS)

(00:35:38) Dependency- und Version-Drift oder Software-Aging

(00:38:02) Arten und Zeit-Intervalle von Software-Auslieferung

(00:40:53) Wie lang fasst man ein System nicht mehr an und das Jahr 2038 mit den Unix-Timestamps

(00:47:04) sqlite bietet Support bis zum Jahr 2050

(00:53:26) Zusammenfassung, Schrödingers Backup und Feedback

Hosts

Wolfgang Gassler (https://mastodon.social/@woolf)
Andy Grunwald (https://twitter.com/andygrunwald)

Feedback (gerne auch als Voice Message)

Email: stehtisch@engineeringkiosk.dev
Mastodon: https://podcasts.social/@engkiosk
Twitter: https://twitter.com/EngKiosk
WhatsApp +49 15678 136776

Transkript

Das Transkript wurde automatisiert per Speech-to-Text erstellt und kann daher Fehler enthalten.

Andy Grunwald (00:00:04 - 00:01:22)

Sollten wir alte Software akzeptieren oder lieber jedem Update hinterherjagen? Das ist die Balance die jeder von uns finden muss. Wann update ich Software? Wie lange kann ich alte Software betreiben? Wann ist alte Software ein wirkliches Risiko? Sollte ich bei jeder neuen Major Version direkt updaten? Bringt es überhaupt was eine alte Software auf etwas Neues zu migrieren ohne neue Funktionalitäten zu bekommen? Und welche Risiken verbergen sich hinter den Updates? Und final, ist der klassische Spruch Never Touch a Running System eigentlich noch aktuell oder sogar ein Fehler? All das und weitere Themenbereiche wie Long Term Support, End of Life Dates, die Softwaremetrik Dependency Drift, Dependabot und Rostendes Software besprechen wir in dieser Episode. Viel Spaß! Moment! Bevor der Spaß losgeht, müsst ihr noch was wissen. Wir haben diese Episode direkt bei Andi in Duisburg aufgenommen. Und weil wir so viel Spaß daran hatten, haben wir auch noch eine Kamera mitlaufen lassen. Ihr könnt also jetzt direkt in die SnowNotes gehen, auf den Link dort klicken und könnt uns nicht nur hören, sondern auch sehen, falls das wirklich jemand wollen sollte. Und noch zur Info, durch das andere Setup ist auch die Tonqualität eine andere. Ich vermute immer noch, es liegt an den ganzen Stahlwerken in Duisburg und die hatten irgendwie Einfluss auf die Mikros. Aber jetzt wirklich zum Content und viel Spaß quasi fast live aus Duisburg.

Wolfi Gassler (00:01:25 - 00:01:29)

So, Andi, wie fühlst du dich bei unserem ersten Video-Podcast?

Andy Grunwald (00:01:29 - 00:01:40)

Also, wenn man mit Podcast anfängt, dann spricht man ja eigentlich so ins Nichts hinein. Und später hört man seine eigene Stimme. Und das fühlt sich fremd an. Und wenn ich jetzt weiß, dass ich gefilmt werde, fühlt sich noch komischer an.

Wolfi Gassler (00:01:40 - 00:01:43)

Ich hab schon gedacht, du sprichst vor mir, dass ich ein Nichts bin.

Andy Grunwald (00:01:44 - 00:01:46)

Ja, also ich mach das ja hier nicht freiwillig, aber nun gut.

Wolfi Gassler (00:01:46 - 00:01:53)

So ist das Leben. Wir machen alles für YouTube, Spotify, den bösen Big Giants.

Andy Grunwald (00:01:53 - 00:01:57)

Supportet unsere Plattform überhaupt Videos über Spotify oder müssen wir das da rein injecten irgendwie?

Wolfi Gassler (00:01:57 - 00:02:06)

Spotify, gute Frage, ob wir das einbauen können. Werden wir noch herausfinden, aber heute geht es mal um alte Technologien oder vermeintlich alte Technologien würde ich fast sagen.

Andy Grunwald (00:02:06 - 00:02:09)

Wieso vermeintlich alte? Was ist alte Technologie für dich?

Wolfi Gassler (00:02:09 - 00:02:25)

Also alte Technologie. Ich habe jetzt gerade gelernt, kürzlich, dass eine Firma eine zentrale Softwarekomponente einsetzt, die auf einem 16-Bit-System läuft, beziehungsweise auf einem alten virtualisierten Windows und die Applikation ist auf 16-Bit. Das ist noch nicht alt.

Andy Grunwald (00:02:25 - 00:02:26)

Haben Waschmaschinen mehr?

Wolfi Gassler (00:02:26 - 00:02:30)

Moderne schon. Du sprichst über WLAN mit deiner Waschmaschine.

Andy Grunwald (00:02:30 - 00:02:41)

Ja, aber ich kann mir schon vorstellen, dass der Hauptchip immer noch so irgendwie 16-Bit operiert und die dann einfach, weil die die alte Software nicht updaten wollten, irgendwie einen neuen Chip daneben gesetzt haben oder so, der dann irgendwie so an die Sensoren mit angeklemmt ist.

Wolfi Gassler (00:02:42 - 00:02:48)

Ja, das glaube ich nicht. Da läuft sicher irgendein Linux drauf, irgendein modernes Ding. Wahrscheinlich so ein kleiner Raspberry Pi oder so.

Andy Grunwald (00:02:48 - 00:02:51)

Aber wenn du jetzt mal von Webtechnologien mal sprechen würdest, was würdest du sagen.

Wolfi Gassler (00:02:51 - 00:03:08)

Okay, ist alte Software? Ja, ich verwende ja selber quasi noch so an einer Stelle für ein Side-Project, PHP. Es läuft zwar eigentlich schon auf PHP 7, glaube ich, oder so, aber ist eigentlich der Code ist von PHP 5 mit Register Globals und diesen ganzen bösen Sachen.

Andy Grunwald (00:03:08 - 00:03:13)

Achso, da hast du aber auch gut Einfallstore, oder? Also ich meine, Register Global is on, oder wie das damals hieß?

Wolfi Gassler (00:03:13 - 00:03:20)

Ja, ich glaube, irgendwann ist es dann abgeschafft worden. Ich bin mir gar nicht sicher, ob das noch überhaupt möglich ist, oder ob wir das mal gefixt haben in irgendeiner Form.

Andy Grunwald (00:03:20 - 00:03:21)

Wie sieht es mit jQuery aus?

Wolfi Gassler (00:03:21 - 00:03:27)

Ist das alles für dich? Ja, jQuery ist überall noch im Einsatz, also wird noch verwendet in neuen Projekten.

Andy Grunwald (00:03:27 - 00:03:30)

Nutzt man da nicht Lodash, Backbone, oder?

Wolfi Gassler (00:03:30 - 00:03:32)

Ja, das ist auch schon alles ein alter Hut.

Andy Grunwald (00:03:32 - 00:03:32)

Ähnliches?

Wolfi Gassler (00:03:33 - 00:03:48)

Ich habe bei einer Applikation noch Marionette. Das war dann irgendwie auf Backbone so eine Aufsatzkatastrophe. Und jetzt mal das zum Bild zu bringen, das ist das Schlimmste. Wenn du jetzt noch ein Bild brauchst und da irgendwas bilden musst, weil du irgendwie einen Wert änderst, das ist eine absolute Katastrophe.

Andy Grunwald (00:03:49 - 00:04:05)

Da kann ich eine schöne Story von neulich erzählen, wirklich von neulich. Ende 2020 habe ich eine kleine Quiz-Applikation, so ein Mehr-Step-Formular-Quiz in Vue.js gebaut. Und das ging dann leider nicht online und dann wurde ich jetzt vor den letzten Tagen kontaktiert. Hey Andi.

Wolfi Gassler (00:04:05 - 00:04:07)

Die ging nicht online, weil du sie programmiert hast?

Andy Grunwald (00:04:07 - 00:04:40)

Nee, nee, nee. Die lief schon ordentlich, so ist das nicht. Aus irgendwelchen Gründen ging die halt nicht online. sondern wurde ich auf jeden Fall die Tage kontaktiert und gesagt, hey, okay, wir würden das Ding jetzt gerne online bringen. Doch irgendwas klappt da nicht mehr. Also Hintergrund war, das Ding schreibt auch irgendwelche E-Mail-Adressen per PHP dran, das bedeutet, das ist so ein AJAX-Request und dann muss ja mit aktuellen AJAX-Requests an die Domain das freischalten, wer da wohin Request machen darf und so weiter und so fort. Und auf jeden Fall habe ich das dann versucht mal eben zu fixen. Mal eben. Ich habe mir diese JavaScript-Applikation runtergeladen, Git-Clone, npm install und alles ist mir um die Ohren geflogen.

Wolfi Gassler (00:04:40 - 00:04:42)

Warum? Die sind nur ein Jahr alt.

Andy Grunwald (00:04:42 - 00:05:02)

Ja, fast anderthalb Jahre inzwischen, ja. Aber irgendwie die ganzen JavaScript-Pakete darunter hatten irgendwie ganz viele Sicherheitslücken und wurden die Tags upstream, also auch im Git-Repositor, irgendwie gelöscht. Dann die damalige JavaScript-Version oder Vue.js-Version und so weiter ist nicht mehr mit neuen Node-Versionen kompatibel und so weiter und so fort.

Wolfi Gassler (00:05:02 - 00:05:05)

Und du hast die Versionen gepinnt damals, die Libraries?

Andy Grunwald (00:05:05 - 00:05:11)

Ich habe ganz genau auf die letzte Versionsnummer gepinnt. Ich hoffe, das macht ihr auch alle, weil meines Erachtens nach sollte man das tun.

Wolfi Gassler (00:05:11 - 00:05:15)

Wie macht man das am besten? Gehst du da alle Libraries durch oder machst du das mit einem Befehl?

Andy Grunwald (00:05:15 - 00:05:29)

Naja, immer welchen Library ich einbinde, sage ich, okay, ich nehme die Version 1.0.3. Also ohne Tilde, ohne Dach davor oder ähnliches. Weil ich kann ja nicht sagen, nur jedes Paket, was ich nutze, folgt Semantic Version.

Wolfi Gassler (00:05:29 - 00:05:35)

Aber wenn du npm add machst, dann wird dir da ja irgendwie nicht die genaue Version eingefügt.

Andy Grunwald (00:05:35 - 00:05:40)

Ich gebe zu, ich habe noch nie npm add benutzt. Ich habe immer das Package.json-File und dann habe ich das zu mir eingetragen.

Wolfi Gassler (00:05:40 - 00:05:43)

Und die Nummer gepinnt.

Andy Grunwald (00:05:43 - 00:07:08)

Also anders, warum sollte man das machen oder warum bin ich ein sehr großer Freund davon? Ist ganz einfach. Wenn man Version pinnt, dann kann man in der Regel davon ausgehen, dass jeder die gleiche Version installiert hat, also auch das CI-System. Die zweite Geschichte, weil nur wenn du eine Tilde hast oder ähnliches, also Tilde Version 1.0.3, dann kann das sein, dass ich eine Version mit 1.0.3 installiert habe, du aber eine Version 1.0.4 und das CI-System 1.0.5. weil es dann unter anderem ja auch andere Versionen zulässt anhand von Semantic Versioning. Und das willst du eigentlich nicht. Du willst überall immer den gleichen Bild. Eine kleine Korrektur. Das Argument zur Installation von verschiedenen Versionen ist nur halbgültig. Jeder aktuelle Package-Manager unterstützt neben der Definition von euren Dependencies bei JavaScript z.B. in der Package.json auch ein sogenanntes Log-File, der Package-Log.json. In diesem Log-File werden spezifische Versionen für die Installation festgehalten, um genau das Problem der unterschiedlichen Software-Paket-Versionen zu lösen. Es wird empfohlen, dieses Logfile ebenfalls mit ins Versionskontrollsystem einzuchecken. Das habe ich in der Diskussion vergessen zu erwähnen. Wenn ihr also das Logfile nicht eingeschickt habt, dann könnt ihr in das Problem von verschiedenen Softwarepaketen rennen. Das ist die erste Baustelle und die zweite Baustelle ist halt, dass du die Upgrades explizit machst. Also ich bin kein Freund von Überraschungen, besonders nicht bei der Softwareentwicklung.

Wolfi Gassler (00:07:08 - 00:07:16)

Und darum haben wir bei unserem Projekt bei EngineeringQS überall diesen Dependabot, der uns ständig nervt, wenn Version 3.4.1 Alpha auf.

Andy Grunwald (00:07:16 - 00:07:17)

3.4.1 Beta.

Wolfi Gassler (00:07:22 - 00:07:55)

Upgradet, ein Issue erstellt, ein Pull-Request erstellt und man den dann durchwinken muss. So, glaube ich, schaffst du es ja nur, dass wenn du diese grüne, diese Heatmap auf GitHub, die zeigt, wann du wie oft irgendwas machst, damit die möglichst grün wird, indem du möglichst viele PRs durchwinkst, weil das sind auch Activities und dann wird dein Graph auf GitHub grüner und wenn du dann Codeprints verwendest, was mein Kollege Matthias und ich ja damals programmiert haben, dann kannst du dir ein schönes T-Shirt machen, mit dem Grafen, der sehr grün leuchtet. Das ist dein Hintergrund. Habt ihr T-Shirts verkauft?

Andy Grunwald (00:07:55 - 00:07:57)

Ich habe ja ein Poster von euch damals bekommen, aber T-Shirts habt ihr nicht verkauft?

Wolfi Gassler (00:07:57 - 00:08:16)

Ah, Blödsinn, T-Shirts. Jetzt sage ich selber schon T-Shirts. Weil wir so oft über T-Shirts gesprochen haben vom Engineering Kiosk, natürlich, wer ein Poster verkauft. Du hast es ja schon an der Wand hängen. Das hätten wir da hinten eigentlich für alle, die es übrigens jetzt noch nicht mitbekommen haben, wir machen ja auch ein Video, Hinter uns hätte man das aufhängen können, dein GitHub-Code-Profil.

Andy Grunwald (00:08:16 - 00:08:57)

Aber hol mir die Leute mal ganz kurz ab. Was ist Dependabot? Dependabot ist ein Bot, der auf sein GitHub-Repository guckt und schaut nach, welche Sprache nutzt du bzw. welchen Dependency-Manager. Also für JavaScript die Package.json und für PHP die Composer.json und für Go die Modules.gomod heißt das, glaube ich, jetzt gerade eben. Ich bin Go-Programmierer und weiß gerade nicht, wie der Package-Manager von Go heißt. Aber wie dem auch sei, Der schaut dann danach und sagt, okay, gibt es ein Upgrade von deinen Dependencies? Und dann macht er einen Pull-Request und raise die Version und raise die Dependency. Und ich bezeichne Dependabot als den besten Mitarbeiter, weil er ackert einfach nur so wie ein Tier. Also die Performance-Reviews von Dependabot sind immer top-notch.

Wolfi Gassler (00:08:58 - 00:08:59)

Er ist ja kostengünstig.

Andy Grunwald (00:08:59 - 00:09:15)

Der Nachteil ist halt natürlich, und das kommt leider bei JavaScript sehr zur Geltung, ist, dass ein simples JavaScript-Projekt mehrere hundert Dependencies haben kann und dass der Release-Zyklus von diesen JavaScript-Paketen halt enorm agil ist, nennen wir es mal. Man könnte auch sagen...

Wolfi Gassler (00:09:15 - 00:09:17)

Katastrophal.

Andy Grunwald (00:09:17 - 00:09:31)

Könnte man sagen. Auf jeden Fall merge ich da halt schon pro Woche 10 Pull-Requests oder sowas. Und ich habe, weiß ich nicht, 9 aktive Dependencies eingetragen. Also jetzt echt nicht viele für ein Jahresgrip-Projekt, aber ich glaube die Subdependencies, die knallen rein. Nun gut.

Wolfi Gassler (00:09:31 - 00:09:38)

Ich muss mir endlich mal einen Filter erstellen, damit meine E-Mails weniger werden. Damit ich die von dir und deinem Dependabot nicht mehr bekomme.

Andy Grunwald (00:09:39 - 00:09:43)

Naja, zurück zur alten Software. Ist Subversion alte Software?

Wolfi Gassler (00:09:44 - 00:09:55)

Das ist eine gute Frage und wir haben ja jetzt gerade am Wochenende ein kleines Community-Treffen gehabt mit einigen HörerInnen in Brüssel auf der FOSDEM.

Andy Grunwald (00:09:55 - 00:09:56)

Nicht letztes Wochenende.

Wolfi Gassler (00:09:56 - 00:10:00)

Ah ja, dieses Wochenende. Also wir nehmen jetzt gerade auf, vor ein paar Tagen waren wir in Brüssel.

Andy Grunwald (00:10:01 - 00:10:02)

Genau.

Wolfi Gassler (00:10:02 - 00:10:04)

Letztes Wochenende, dieses Wochenende.

Andy Grunwald (00:10:04 - 00:10:07)

Was sagt ihr? Wir nehmen kurz nach der FOSDEM auf, genau.

Wolfi Gassler (00:10:07 - 00:10:10)

War wohl letztes Wochenende dann? Oder habt ihr da in Deutschland schon wieder einen anderen Begriff?

Andy Grunwald (00:10:10 - 00:10:15)

Nee, letztes Wochenende war wirklich das vergangene und dieses Wochenende ist das kommende Wochenende.

Wolfi Gassler (00:10:15 - 00:11:01)

Ja, genau. Okay, dann reden wir eben gleich. Auf jeden Fall haben wir da ein kleines Community-Treffen gehabt, sind einige Leute gekommen, war super cool, super nett. Und da haben wir auch gelernt, dass ein Unternehmen gerade auf Git umgestellt hat von SVM. Wir haben da auch mit ein paar Leuten gesprochen und alle haben irgendwie gemeint, so spät und um Gottes Willen gibt es das überhaupt noch. Aber das ist die Frage, ist SVN überhaupt alt? Vor allem die Frage ist, die haben ja die letzten Jahre auch entwickeln können. Warum sind sie nicht bei SVN geblieben? Also wir könnten jetzt natürlich fragen, was der Grund war, aber es würde mich auch interessieren, wenn es die letzten Jahre funktioniert hat, warum steigt man auf Git um? Vor allem man muss ja auch die ganzen Tools womöglich umbauen. die rundherum um dieses ganze SVN-System arbeiten.

Andy Grunwald (00:11:01 - 00:11:09)

Das ist aber jetzt mal eine interessante Frage. Glaubst du wirklich, es gibt in dem modernen Open-Source-Ökosystem mehr Tools, die immer noch mit Subversion arbeiten als mit Git?

Wolfi Gassler (00:11:09 - 00:11:11)

Na, mehr sicher nicht.

Andy Grunwald (00:11:11 - 00:11:24)

Ja, aber wenn die zum Beispiel eine komplette Modernisierung und eine Annäherung an den existierenden Open-Source-Stack haben möchten, zum Beispiel als Ziel, dann wird es ja mit hoher Wahrscheinlichkeit mehr Support im Open-Source-Ökosystem für Git geben als für Subversion, oder?

Wolfi Gassler (00:11:25 - 00:11:54)

Das kann natürlich sein, aber wenn du deine CI, CD irgendwie rund um SVN angepasst hast und aufgebaut hast, musst du natürlich das alles mit umstellen. Das heißt, das hängt ja alles hinten dran nochmal. Es ist ja womöglich nicht nur SVN, sondern alle Leute müssen sich umgewöhnen, du müsst einen neuen Workflow einbauen in die Köpfe der ganzen ProgrammiererInnen und du musst vielleicht irgendwelche Tools im Hintergrund austauschen, du musst deinen Server austauschen, Backup, was auch alles hinten dran hängt. Das heißt, du musst es komplett neu aufstellen. Ist ein großes Projekt, würde ich sagen.

Andy Grunwald (00:11:55 - 00:11:59)

Also die Gründe für das Upgrade von Subversion nach Git kenne ich jetzt leider auch nicht.

Wolfi Gassler (00:11:59 - 00:12:05)

Der Grund... Ja, aber wann würdest du updaten grundsätzlich? Oder würdest du sagen, sofort immer auf Git?

Andy Grunwald (00:12:05 - 00:12:30)

Ne, das jetzt nicht. Also ich denke, du hast Use Cases für alles. Was ich mir aber gut vorstellen kann, ist zum Beispiel Teil der Flexibilität und der Remote Arbeit. Bei Subversion brauchst du für jeden Befehl eine Konnektivität zum Server. Sogar für einen SVN-Log musst du eine Konnektivität zum Server haben. Und wenn du jetzt mal vielleicht sogar deinen Mitarbeitern erlauben möchtest, von Mallorca zu.

Wolfi Gassler (00:12:30 - 00:12:33)

Arbeiten, oder... Ja, auch da gibt es Internet.

Andy Grunwald (00:12:33 - 00:12:34)

Ja, das ist richtig.

Wolfi Gassler (00:12:34 - 00:12:36)

Im 19. Bundesland, 18., 19., 20., wievieltes Bundesland?

Andy Grunwald (00:12:39 - 00:12:40)

Das 17.

Wolfi Gassler (00:12:40 - 00:12:41)

Bundesland.

Andy Grunwald (00:12:41 - 00:12:43)

Bayern und Franken ist dabei aber ein Bundesland.

Wolfi Gassler (00:12:44 - 00:12:49)

Das brauchst du mir nicht erzählen, solange du Österreich nicht als Bundesland mitrechnest.

Andy Grunwald (00:12:49 - 00:12:56)

Wenn man zum Beispiel seinen Mitarbeitern mal erlauben möchte, um aus dem Zug zu arbeiten, da gibt es dann offiziell kein Internet mehr.

Wolfi Gassler (00:12:56 - 00:13:03)

Das kenne ich leider zu gut, vor allem wenn man durch Deutschland fährt. Sobald man in Österreich oder in Holland zum Beispiel wieder ist, ist das alles schon besser.

Andy Grunwald (00:13:04 - 00:13:06)

Dann denke ich halt schon macht das Sinn.

Wolfi Gassler (00:13:06 - 00:13:10)

Ja, aber trotzdem du machst ja, ja gut, du kannst natürlich offline committen.

Andy Grunwald (00:13:11 - 00:13:11)

Nein, bei Subversion nicht.

Wolfi Gassler (00:13:12 - 00:13:16)

Ja, ja, na, ich sag bei Git kannst du wenigstens offline committen, wenn du wirklich committen willst.

Andy Grunwald (00:13:16 - 00:13:27)

Du hast halt eine komplette Kopie von deinem Repository lokal, ja, und somit, wo du halt bei Subversion den Code lokal hast, aber immer wenn du auf einen anderen Branch wechseln möchtest, dann brauchst du halt Konnektivität im Server.

Wolfi Gassler (00:13:28 - 00:13:53)

Aber die Frage ist ja immer, macht es Sinn, auf was Neues zu wechseln, ohne dass ich Funktionalität dazugewinne? Also, wenn ich jetzt eine 16-Bit-Anwendung habe auf einem alten Server oder virtualisiert, ist ja egal, und ich habe die alte 16-Bit-Anwendung und die funktioniert und in meinem ganzen Ecosystem ist das irgendwie eingebunden, alles funktioniert. Sollte ich dann wegmigrieren oder nicht? Das hängt ja auf irgendeinem kleinen Server im Eck. Da ist Sicherheit auch egal.

Andy Grunwald (00:13:53 - 00:14:01)

Naja, also klar, das Sicherheitsthema ist immer ganz vorne parat. Aber wird diese Änderung noch verändert?

Wolfi Gassler (00:14:01 - 00:14:02)

Diese Änderung?

Andy Grunwald (00:14:02 - 00:14:05)

Diese Applikation. Wird diese Applikation, deine 16-Bit-Applikation noch weiterentwickelt?

Wolfi Gassler (00:14:05 - 00:14:08)

Ja, die greift niemand mehr natürlich an, sonst zerbricht sie.

Andy Grunwald (00:14:08 - 00:14:12)

Ja, okay. So, und darauf basiert dein Business?

Wolfi Gassler (00:14:12 - 00:14:18)

Ja, ein Teil zumindest. Aber wenn das eine Blackbox ist, die funktioniert.

Andy Grunwald (00:14:18 - 00:14:31)

Ja, und was passiert, wenn die nicht mehr funktioniert? Ja, das ist eine gute Frage. Ich glaube, darum geht es halt. Ich glaube, es geht halt, jetzt mal angenommen, du hast irgendeine Blackbox in der Ecke stehen, weil ich habe ja schon mal erwähnt.

Wolfi Gassler (00:14:31 - 00:14:32)

Die Legacy verdient das Geld.

Andy Grunwald (00:14:32 - 00:14:55)

Die Legacy verdient das Geld und ich bin fest davon überzeugt, dass jede Firma, irgendwo einen Rechner in der Ecke stehen hat, der Staub fängt, der sich keiner mehr traut anzufassen, aber jeder weiß, wenn der Stecker von dem Ding gezogen wird, dann bricht hier, dann funktioniert irgendwas nicht und das fällt irgendwie nach Monaten erst auf, nach, keine Ahnung, vielleicht auch bei der Steuerprüfung oder so, das ist völlig egal, ja, aber das führt zum Desaster.

Wolfi Gassler (00:14:55 - 00:14:59)

Aber macht das Sinn? Also ist das ein Problem oder ist es kein Problem?

Andy Grunwald (00:15:00 - 00:16:05)

Ah, ich denke, dass das solche Elemente sind, die wirklich geschäftsschädigend sein könnten. Da redet man ja auch von Risiken von Business Continuity. Ja? So nach dem Motto, wenn du zentrale Prozesse hast oder wenn du Prozesse hast oder Applikationen oder irgendwas, was 20, 25 Prozent deines Revenue macht oder ausmacht oder beziehungsweise dafür irgendwie verantwortlich ist und dafür gebraucht wird und das sich keiner mehr traut anzufassen, ja? Und da ist vielleicht ein Mitarbeiter dann noch, der weiß wie es geht, dann hat der natürlich den Hebel in der Hand. Also der Junge oder die Dame hat dann die Firma in der Hand. Und oh, ich möchte 300.000 verdienen, no problem, weil du hast ja keine andere Möglichkeit. Und du schießt ja halt selbst ins Knie in der Hinsicht. Und jetzt, was ist, wenn die Person dann jetzt zum Beispiel gar nicht geht, sondern vielleicht sogar einen Unfall hat? Also irgendwie was Unvorhergesehenes passiert. Boof. Und dann bricht das Revenue 20% ein. Ich bin mir nicht sicher, ob jede Firma das verkraften kann. Dann führt es zu Entlassungen und dann geht das Schneeballsystem los.

Wolfi Gassler (00:16:05 - 00:16:19)

Ja, ganz oft sind es ja auch irgendwie Elemente, die jetzt nicht so im absoluten Kern fürs Business notwendig sind. Also was ist, wenn das drei Tage stehen darf, weil das irgendeine Abrechnungsgeschichte ist im Hintergrund oder keine Ahnung, irgendeine Verwaltungssache?

Andy Grunwald (00:16:20 - 00:16:29)

Ja, okay, aber wir reden ja von Elementen. Wenn die drei Tage stehen, auch in drei Tagen findest du ja niemanden, der das mit einer heißen Schrecknadel anfasst.

Wolfi Gassler (00:16:29 - 00:16:30)

Wahrscheinlich nicht, ja.

Andy Grunwald (00:16:30 - 00:16:55)

Ich persönlich denke, keiner möchte daran arbeiten. Ja, weil es ist alt, es ist nicht dokumentiert, es ist sehr wahrscheinlich auch unglaublich komplex. Mein liebstes Beispiel, vielleicht ganz viel Code mit Bitshifting, dann würde ich das nicht verstehen. Ich denke aber, man muss sich dieser dreckigen Geschichte stellen. Ich denke, man sollte sich diese Putzhandschuhe anziehen, die echt viel Säure abkönnen und dann da richtig tief in den Dreck reingehen.

Wolfi Gassler (00:16:55 - 00:17:41)

Aber die Frage ist ja immer, okay, wenn es jetzt ganz alt ist, dann sind wir beide der Meinung, das muss weg. Aber jetzt haben wir einen ganz großen Bereich zwischendrin. Zwischen ganz alt und natürlich super hipster neu. Ja. Wo in diesem Bereich weiß ich wann, wo ich umsteigen soll? Wann mache ich das Upgrade, das Update? Und vor allem, es hängt ja auch immer ganz viel dran. Ich kann ja sagen, ich update eine Software und das kennen wir ja alle. Wir updaten eine Versionsnummer höher auf von der Datenbank zum Beispiel und plötzlich bricht alles zusammen, weil die irgendein neues Flag eingeführt haben und der ganze Rattenschwanz, alles was irgendwie zur Datenbank connectet, inklusive allen Analytics-Tools, Reporting-Tools und so weiter, die brechen alle zusammen wegen dem kleinen, kleinen Update.

Andy Grunwald (00:17:43 - 00:19:00)

Ich glaube, da gibt es nicht die eine Antwort. Ich halte mich da immer an ein paar Ankern fest. Wir haben jetzt diese zwei Extreme. Ganz alte Software auf der linken Seite und hipster Software. Das bedeutet, jedes Nuller-Release nehme ich mit am Releasetag. Gehen wir mal in das eine Extrem. Gehen wir mal in diese Nuller-Release-Geschichte. Gehen wir mal sagen, okay, jetzt gerade kommt eine neue Versionsnummer raus und ich wechsle sofort auf die neue Versionsnummer und puff, gleich am selben Tag, vielleicht auch ein paar Minuten später nach Release, bin ich persönlich kein Fan von, weil besonders wenn dieses Release größere neue Features dabei hat, ist es Es mag zwar sehr gut getestet sein, aber es kommt halt immer wieder vor, dass da halt mal ein Bug drin ist, weil niemand kann verhindern, bugfreie Software zu schreiben. Und man weiß ja gar nicht, ob die Software Semantic Versioning folgt oder nicht. Also das bedeutet bei großen neuen Features die Hauptversion raisen oder vielleicht sogar bei Breaking Changes die Hauptversion raisen und so weiter und so fort. Also auf dem kompletten Extrem bin ich jetzt nicht. Ich bin aber jetzt auch nicht auf der anderen Seite, dass man sagen würde, ich nutze das so lange, wie es mir reicht. Und damit meine ich jetzt, wer heute noch eine MySQL 5.5, 5.6, 5.7 oder Ähnliches betreibt, meines Erachtens ist das grob fahrlässig. Wie alt ist diese Version?

Wolfi Gassler (00:19:01 - 00:19:07)

Gute Frage, aber schon einige 2016, na 2014 ist 8 rausgekommen, oder?

Andy Grunwald (00:19:10 - 00:19:15)

Und ich glaube, die haben noch nicht mal als kompletten Funktionsumfang für JSON-Datentypen und ähnliches, oder?

Wolfi Gassler (00:19:15 - 00:19:19)

Ja, auf keinen Fall. Da war noch gar nichts da. Das ist alles mit 8.

Andy Grunwald (00:19:19 - 00:19:21)

Oder die ganze MySQL-GIS-Geschichte.

Wolfi Gassler (00:19:21 - 00:19:40)

Das war alles später, ja. Oder diese... Ja, GIS teilweise vielleicht, aber es ist alles auf jeden Fall erst später gekommen. Aber das sind ja Features. Die Features sind jetzt weniger relevant. Ob ich jetzt ein Feature habe, was ich sowieso nicht nutze, ob ich das jetzt habe oder nicht, ist dann irrelevant. Aber es geht halt um die Security-Klamotte zum Beispiel oder die Sicherheit.

Andy Grunwald (00:19:40 - 00:20:58)

Die Security-Geschichte auf der einen Seite, aber woran ich mich immer so festhalte, ist dieses Supported Services, dieses End of Life, EOL. Weil jede Software hat in der Regel, also jede größere Software, jeder etabliertere Software, Viele Code-Pakete haben es jetzt nicht. Die haben meist so ein EOL-Scheme. Das bedeutet, jede Version, die released wird, wird für zwei Jahre oder ähnliches supported. Du hast dann also so ein Sliding-Window. Kommt immer was Neues raus, verschiebt sich dieses Sliding-Window von supported Versionen. Wie zum Beispiel bei der Sprache Golang. Das ist ganz interessant. Bei der Golang, ich glaub, da kam jetzt Version 1.20 raus, jetzt vor kurzem. Und was dann supportet wird, ist Version 1.20 und 1.19. Und just in dem Moment, wo 1.20 rauskam, ist der Support für 1.18 verfallen. Das bedeutet, für 1.18 gehen keine Security-Fixes mehr ein. Zugegeben, ich weiß gerade nicht, ob es nur die aktuelle und eine davor oder zwei davor waren. Du hast halt dieses Sliding-Window. Umso mehr Versionen released werden, umso schneller werden die alten Versionen dann halt, ich sag mal, gedroppt, nennt man das vom Support. Und das ist halt so der Anker, an dem ich festhalte, wo man sich so ein bisschen schützt. Man springt nicht auf jede neue Hipster-Version und nicht auf jede neue Nuller-Version. Aber man sollte auch aufpassen, dass man aus diesem EOL-Window nicht rauskommt.

Wolfi Gassler (00:20:59 - 00:21:13)

Aber wie du sagst, in vielen Bereichen hast du es gar nicht. Wenn du dann mit JavaScript hantierst oder so, was nach eineinhalb Jahren komplett nicht mehr zum Bauen geeignet ist, weil einfach alle Versionen weg sind oder irgendwie ein Problem ist.

Andy Grunwald (00:21:14 - 00:21:39)

Naja, aber bei Javascript-Paketen hast du es wahrscheinlich nicht, aber sehr wahrscheinlich, also hoffe ich mal, und da muss ich jetzt sagen, weiß ich gerade nicht, ich hoffe mal, es ist für Node so. Also was ich zum Beispiel öfter sehe in Chainshocks ist, dass der Support für Node.js in Version 16 gedroppt wurde. So, da hast du doch dein mehr oder weniger EUL ja schon. Und wenn du dann halt upgraden möchtest auf React, weiß ich nicht, wo sind wir da? 15, 17, 2?

Wolfi Gassler (00:21:39 - 00:21:40)

Keine Ahnung.

Andy Grunwald (00:21:40 - 00:22:09)

Auf die neue React-Version. Dann wird die React-Version irgendeine Subdependency haben, die nicht mehr auf Node.js 16 läuft. Und das ist ja unter anderem dann so dein EUL-Window, dein implizit definiertes EUL-Window, was ich dann sehr schade finde, weil es ja nirgendwo steht und keiner weiß, was das wirkliche EUL-Window ist. Aber dann mit dem Abschaffen des Supports von Node.js Version 16 hinkst du dann hinterher und das ist dann die Kette, der du folgst. Das bedeutet, du kannst dann gar nicht auf die neue React-Version hochgehen.

Wolfi Gassler (00:22:09 - 00:22:39)

Aber die Frage, die sich mir stellt, ist halt immer, wenn ich jetzt irgendwo eine Software habe, die älter ist, die abgeschlossen ist, Blackbox-artig abgeschlossen ist, die jetzt auch nicht direkt weiterentwickelt, weil sie irgendwie was abgeschlossenes macht oder das Projekt abgeschlossen ist. Warum sollte mir die Mühe machen, ständig da Updates zu fahren, Zeit zu investieren, immer wieder alle drei Monate neue Versionen einspielen, höher zu gehen, höher zu gehen, höher zu gehen, wenn es ja so auch läuft.

Andy Grunwald (00:22:40 - 00:23:01)

Also, ich sage immer, oder nicht ich, der Spruch kommt nicht von mir, sondern ich habe ihn irgendwann in meiner Laufbahn mal aufgefasst, Software rostet. Und unter gewissen Umständen ist das vielleicht auch gar nicht falsch, das was du sagst. Das bedeutet, du hast ja die Box und die läuft, Blackbox, und ich gehe jetzt nicht davon aus, dass das was Proprietäres ist von irgendeiner Firma, sondern das ist irgendwann mal Software, die ihr inhaus geschrieben habt.

Wolfi Gassler (00:23:02 - 00:23:04)

Ja, aber vielleicht auch was Proprietäres, ist ja egal.

Andy Grunwald (00:23:05 - 00:23:10)

Naja, bei Proprietär muss ich halt schon gucken, ist die Firma noch dahinter und so weiter und so fort.

Wolfi Gassler (00:23:10 - 00:23:14)

Ja, aber die will mir ja vielleicht auch eine neue Version verkaufen. Muss ich unbedingt auf die neue Version kommen?

Andy Grunwald (00:23:14 - 00:23:19)

Nee, musst du nicht, aber dann gehst du ja eine aktive Entscheidung ein, dass du ein Risiko entgehst.

Wolfi Gassler (00:23:19 - 00:23:20)

Was für ein Risiko?

Andy Grunwald (00:23:22 - 00:23:23)

Wer weiß, was morgen ist? Wer weiß?

Wolfi Gassler (00:23:24 - 00:23:24)

Ja, aber das ist immer so.

Andy Grunwald (00:23:25 - 00:23:32)

Okay, bestes Beispiel. Du hast eine Software für Rechnungsstellungen, ja? 19% Mehrwertsteuer. So. Und auf einmal, was kam?

Wolfi Gassler (00:23:32 - 00:23:34)

Du meinst dieses Corona-Zeug?

Andy Grunwald (00:23:34 - 00:23:46)

So sieht's aus. Ich glaube, wir, Deutschland, hat mal einen sehr agilen Move gemacht und hat, glaube ich, innerhalb von drei Monaten gesagt, ja, pass mal auf, in drei Monaten gilt für ein Jahr 16% Mehrwertsteuer. War doch irgendwie sowas, ne?

Wolfi Gassler (00:23:46 - 00:23:50)

Ja, aber die gute Software kann das vielleicht einfach in einem Setting einstellen.

Andy Grunwald (00:23:50 - 00:23:51)

Wir reden ja über alte Software.

Wolfi Gassler (00:23:51 - 00:24:02)

Ja, sogar. Also, ich habe eine ganz alte Software zum Rechnungslegungsschreiben. Ist irgendeine Open-Source-Software. Keine Ahnung. Ich brauche die ganz, ganz selten. Also, das generiert mir halt da BDF oder so. Die kann es zum Beispiel.

Andy Grunwald (00:24:02 - 00:24:05)

Okay. Aber deine Blackbox-Software kann das jetzt nicht.

Wolfi Gassler (00:24:05 - 00:24:07)

Okay. Gehen wir mal davon aus, ich kann es nicht.

Andy Grunwald (00:24:07 - 00:24:11)

Und du stellst ungefähr 2000 Rechnungen pro Monat. Was machst du?

Wolfi Gassler (00:24:11 - 00:24:13)

Dann hast du wahrscheinlich ein Problem, ja.

Andy Grunwald (00:24:13 - 00:24:19)

Studenten anheuern, die 19 auf 16 runterrechnen.

Wolfi Gassler (00:24:19 - 00:24:36)

Im Idealfall hast du Zugriff noch auf die Datenbank, weil die schreibt dir in die Datenbank und dann schreibst du in einen Trigger, der mit dem Befehl alle Rechnungen innerhalb von einem gewissen Datum nach unten schreibt. So machen das viele. Irgendwelche Dirty Hacks, damit diese Blackbox noch weiter läuft.

Andy Grunwald (00:24:36 - 00:24:54)

Genau, solche Moves kannst du machen, aber es ist ja eine Blackbox, deswegen kennst du ja den ganzen Funktionsumfang mit hoher Wahrscheinlichkeit gar nicht, deswegen weißt du ja gar nicht, was dein Trigger eigentlich so für Nachwehen hat und vielleicht sogar gegebenenfalls Dateninkonsistenzen erzeugt, die dann erst fünf Jahre down the line irgendwie auffällig werden.

Wolfi Gassler (00:24:55 - 00:25:34)

Aber dann kommt ja eigentlich alles wieder zurück, dass man sagt, okay, ich kann die Software nicht mehr ändern und adaptieren, sogar wenn sie Open Source ist. Also wie gesagt, ich arbeite ja teilweise auch mit eigener Software von mir, die extrem alt ist, die ich dann selber gar nicht mehr bauen kann. Ich ändere einen Wert, weil hin und wieder muss man halt irgendeine Kleinigkeit ändern, dann probiere ich das zu bauen und dann sehe ich, dass meine ganze Pipeline tot ist, weil sie seit zwei Jahren halt nicht mehr gelaufen ist. irgendwie ein Bild fällt oder irgendeine dumme Javascript-Library. Javascript-Libraries sind eine Katastrophe, ja. Also ich habe auch schon irgendwas auf GitHub selber dann runtergefoggt und irgendwie gebildet, damit ich diese dumme uralte Lippe, die mir irgendeinen Grafen malt oder so noch.

Andy Grunwald (00:25:34 - 00:26:19)

Aber genau um das Problem, was du jetzt gerade beschreibst zu gehen, empfehle ich zum Beispiel, lass deine CI-Pipeline, und deine CI-Pipeline heißt jetzt nicht unbedingt immer deine Unit-Tests, sondern eigentlich nur ein Make-Install, also installiere deine Dependencies aus deinem Package-Manager jede Nacht. Das bedeutet, lass deine Software jede Nacht nur bauen. Der Grund ist ganz einfach, genau das, was du sagst. Wenn du zum Beispiel nicht überall lokale Mirror hast von deinen Dependencies, also lokal in-house, sondern wirklich noch auf das Original Goaling-Repo gehst oder auf GitHub oder woher auch immer du deine Dependencies siehst, npm.org heißt das, glaub ich, ja, aber es gibt nicht. Doch. Und die löschen eine Version. LeftPad jetzt zum Beispiel. Dann kriegst du das am nächsten Tag sofort mit.

Wolfi Gassler (00:26:20 - 00:26:25)

Ja, aber das letzte Verrasst du, dass ich eine CI-Pipeline habe, die das irgendwie bauen kann.

Andy Grunwald (00:26:26 - 00:26:26)

Genau.

Wolfi Gassler (00:26:26 - 00:26:32)

Wenn ich von bauen spreche, kann es ja auch einfach nur ein npm build sein, was ich lokal auf meiner Commandline ausführe.

Andy Grunwald (00:26:32 - 00:26:41)

Also in der CI-Pipeline muss jetzt kein Jenkins oder GitHub Actions oder CircleCI sein, das reicht für mich auch irgendwo ein Cronjob auf irgendeiner Linux-Node, der ein Make-Install macht.

Wolfi Gassler (00:26:41 - 00:26:42)

Ja, aber das müsste ich dann einrichten.

Andy Grunwald (00:26:42 - 00:26:47)

Genau. Und dann, wenn das Ding fehlschlägt, weißt du halt, oh, du hast eine externe Abhängigkeit.

Wolfi Gassler (00:26:47 - 00:26:49)

Und der muss mir dann irgendwie ein E-Mail schreiben oder so.

Andy Grunwald (00:26:49 - 00:27:18)

Ja, aber wenn ein Kron fehlschlägt, ist ja im Haus-Linux-System drin Mail. Und wenn du dann ein Mail eingerichtet hast, ja, also das geht ja schon mit Wortmitteln alles. Ist zwar jetzt nicht mehr das aktuellste Prometheus-Alerting, ja, das verstehe ich auch, aber es funktioniert. Aber wenn du es halt jede Nacht bauen lässt, auch wenn du keine Änderungen hattest und du hast externe Dependencies und Da verändert sich was, was du eh nicht unter Kontrolle hast. Dann kriegst du am nächsten Tag einen Ping und kannst sofort reagieren, anstatt zwei Jahre down the line, so wie du das schon gesagt hast.

Wolfi Gassler (00:27:18 - 00:27:32)

Würdest du dann empfehlen, also übrigens nur nochmal zur Erklärung, ich bin kein Fan von alter Software, ich stelle da nur Davis Advocates Fragen. Nur, dass das auch klar ist. Es sind alles Side-Projects von mir, die ganz, ganz unwichtig sind.

Andy Grunwald (00:27:32 - 00:27:37)

Also das glaube ich dir gerade nicht. Ich glaube, du weinst der Software hinterher, weil früher alles besser war.

Wolfi Gassler (00:27:38 - 00:28:07)

Früher war sowieso alles besser, sogar die Zukunft. Sehr schön, sehr schön. Jetzt hast du mich durcheinander gebracht. Was wollt ihr eigentlich fragen? Ah genau, ob du jetzt empfehlen würdest, dass man jetzt auch als kleiner Softwareentwickler anfängt, dem Kunden solche Fenster vorzugeben, dass man sagt, okay, Support bis dorthin oder mein Window, wenn ihr mich nicht zahlt, dass ich euch das höher ziehe auf höhere JavaScript-Versionen, dann läuft der Support aus, kann ich nichts garantieren.

Andy Grunwald (00:28:07 - 00:28:08)

So als Freelancer?

Wolfi Gassler (00:28:08 - 00:28:18)

Als Freelancer, es ist ja so viel Software draußen, die so eher im kleinen Rahmen ist, was jetzt nicht irgendwie wo große Enterprise dahinter steckt. Ich hätte es noch nie gesehen irgendwo, keine Ahnung.

Andy Grunwald (00:28:19 - 00:28:22)

Was ist die klassische Gewährleistung in Deutschland? 3 Jahre?

Wolfi Gassler (00:28:22 - 00:28:23)

Gewährleistung?

Andy Grunwald (00:28:23 - 00:28:27)

Ich rede jetzt nicht von Garantie. Ich glaube 3 Jahre.

Wolfi Gassler (00:28:27 - 00:28:46)

Gewährleistung ist sowieso nur ein halbes Jahr. Gewährleistung ist 2 Jahre. Aber das hilft ja auch wenig, weil es geht ja darum, dass du irgendwie denen dann weiterhelfen willst. Es geht ja um Weiterentwicklung. Eine Gewährleistung heißt ja, du machst irgendwas, du garantierst, dass das funktioniert eine gewisse Zeit.

Andy Grunwald (00:28:46 - 00:29:22)

Ja, richtig. Und ich frage das mit dem Hintergrund, gegebenenfalls, weil du fragst mich ja gerade, macht es Sinn oder würde ich empfehlen, dass ein Freelancer in irgendeiner Art und Weise sagt, okay, pass mal auf, ich schreibe jetzt Software und EOL, also End of Life für diese Art von Software, für diese Version ist in einem Jahr. Ab und zu würde ich sagen, das kann sogar Selbstschutz sein, dass der Kunde nicht einfach in drei Jahren ankommt und ich kann keinen Dienstlohn mehr machen. Wie zum Beispiel jetzt bei diesem Quiz, was ich gerade erzählt habe. Weißt du, warum nicht? Also ob ich es empfehlen würde oder nicht. Ich glaube, es kommt immer ganz an die Software drauf an. Und ich glaube, da gibt es auch verschiedene, also rechtlich gesehen, verschiedene Vertragsarten.

Wolfi Gassler (00:29:22 - 00:29:32)

Naja, grundsätzlich garantierst du mit Software gar nichts. Wenn sich irgendwie was darunter liegend ändert. Du hast ja keine Verpflichtung zu garantieren, dass was in der Zukunft funktioniert mit Software.

Andy Grunwald (00:29:32 - 00:30:19)

Okay, da können wir uns erst streiten und wir werden, glaube ich, nie richtig zu der Antwort kommen, weil ich bin kein Anwalt und du nicht. Und vielleicht hört uns jemand zu und kann uns mal was dazu sagen. Das wäre, glaube ich, ganz toll. Oder schaut uns sogar zu. Auf jeden Fall, was ich, glaube ich, machen würde, ich würde die Frage umdrehen. Ich würde versuchen, dem Kunden eine LTS-Version zu verkaufen. Oder am besten eine E-LTS. LTS steht für Long-Term Support, bieten auch ziemlich viele Software-Produkte an. Beispiel das Contact-Management-System Typo 3, released im ganz normalen Release-Zyklus. Und ich glaube, die Versionen sind ein halbes Jahr oder ein Jahr normalerweise supported. Und die LTS-Version, die kommt dann irgendwie so alle zwei oder drei Jahre raus, die ist dann für drei Jahre supported. Und dann kannst du bei der Typo 3 GmbH auch noch die E-LTS kaufen. Und die E-LTS hat dann nochmal zwei Jahre auf die LTS-Version drauf.

Wolfi Gassler (00:30:19 - 00:30:22)

Aber was garantiert die, die LTS oder E-LTS?

Andy Grunwald (00:30:23 - 00:30:30)

Security-Fixes und Bug-Fixes teilweise sogar. Das bedeutet, du kriegst zwei Jahre weitere Security-Fixes.

Wolfi Gassler (00:30:30 - 00:30:32)

Aber nur Security-Fixes?

Andy Grunwald (00:30:32 - 00:31:00)

Ja, also es kommt dann auf den E-LTS-Vertrag drauf an und den du ja auch dann selbst schließen kannst und den kannst du dann auch selbst formulieren. Aber so würde dann dein Kunde eigentlich eine neue Subscription kaufen und dich dann auch aktiv für diese Arbeit bezahlen, dass du das dann länger maintainst. Und lustiger Fun-Fact. Es gibt sehr, sehr viele Firmen und auch unter anderem sehr viele deutsche Geldautomaten, die immer noch Windows XP und Windows 2000 betreiben. Quizfrage. Ist Windows XP und Windows 2000 noch aktiv supported von Microsoft?

Wolfi Gassler (00:31:01 - 00:31:01)

Gute Frage, ja.

Andy Grunwald (00:31:02 - 00:31:11)

Was meinst du eigentlich, wie sich die gerade so die Hände reiben und mit sowas die Taschen voll machen? Weil du glaubst doch wohl nicht, dass sie das for free tun, oder?

Wolfi Gassler (00:31:11 - 00:31:49)

Ja, du musst halt auch noch Menschen finden, die Spaß haben an diesem alten Zeug zu arbeiten. Weil es ist ja das nächste, was glaube ich ganz viele vergessen. Gerade jetzt, wo es immer wichtiger wird, Leute zu halten und die Retention zu erhöhen, dass die Leute nicht weglaufen. Wenn du alte Software hast und diese Blackboxen in den Ecken oder auch nur User von der Software sogar, also es kann ja sein, dass das dann andere Abteilungen auch betrifft, wo die User dir dann irgendwann weglaufen, weil sie sagen, das User-Interface ist eine Katastrophe, die Software ist 20 Jahre alt. Ich bin doch nicht, keine Ahnung, in die HR-Abteilung gegangen, damit ich mit irgendeiner Software arbeite, die 20 Jahre alt ist.

Andy Grunwald (00:31:49 - 00:32:13)

Ja, aber pass auf. Der Punkt ist ganz einfach. Legacy verdient das Geld. Ja? Und Microsoft macht sich die Taschen voll, weil die immer noch etliche Tausende und Millionen von Euro jedes Jahr von Großkonzernen kriegen, damit die einfach deren Windows 2000 und Windows XP weiter betreiben. Und die Gründe sind, weil die eine Blackbox im Keller stehen haben, die jetzt nur noch irgendwie eine Zertifizierung im Bankwesen für Windows XP oder ähnliches.

Wolfi Gassler (00:32:13 - 00:32:33)

Aber das ist ja eine gute Frage. So Geldautomaten oder sowas. Warum mache ich da keinen Update? Also was habe ich denn für einen Vorteil, dass ich dieses alte Ding habe? Habe ich da irgendwelche Schnittstellen von dieser Hardware, die dann auf 16-Bit laufen und nur mehr auf diesem Windows XP? Oder sind das DLLs, wo die Firmen pleite gegangen sind und keiner weiß, wie die DLLs funktionieren?

Andy Grunwald (00:32:33 - 00:32:47)

Bei Geldautomaten kann ich jetzt gerade nicht sagen, was der Grund ist, aber es würde mich mal auch interessieren, also wer jetzt irgendwie bei der Bank IT arbeitet, ja bei der Sparkasse, Volksbank oder Commerzbank, Deutsche Bank und wirklich an diesem System arbeitet, schreibt uns mal eine E-Mail, stetisch at engineeringkiosk.dev, ich würde mich wirklich freuen.

Wolfi Gassler (00:32:47 - 00:32:48)

Ja, definitiv.

Andy Grunwald (00:32:48 - 00:33:04)

Was ich aber sagen kann ist zum Beispiel im Datenbankenbereich, Da kriegen Datenbankfirmen, die sowas, also Database as a Service zum Beispiel, kriegen Anfragen. Könnt ihr mal bitte unsere Version, die wir gerade betreiben, noch ein halbes Jahr lang weiter betreiben? Wir schaffen es nicht abzugraden.

Wolfi Gassler (00:33:05 - 00:33:07)

Ein halbes Jahr verstehe ich ja, aber.

Andy Grunwald (00:33:07 - 00:33:11)

Wir sprechen da eher von Windows 2000.

Wolfi Gassler (00:33:12 - 00:33:39)

Aber da sind wir wieder bei diesem Rattenschwanz, der dranhängt. Weil wahrscheinlich so viele andere Komponenten in irgendeiner Form darauf zugreifen, dass du die auch alle ändern müsstest. Und die hängen ja dann auch wieder irgendwo dran. Und da hängen dann ganz viele Firmen dahinter, manche Firmen gibt es vielleicht gar nicht mehr, manche haben irgendwie das System geändert, manche Schnittstellen gibt es nicht mehr und so hast du dieses kaskadierende Problem dann bei einem Update. Und ich glaube, davor haben ja auch wirklich viele Angst und darum macht man dann lieber keinen Update.

Andy Grunwald (00:33:40 - 00:33:57)

Ja, aber deswegen sage ich es auch, Software rostet. Und dieser Spruch wird wahrer, umso älter diese Software ist. Es wird ja nicht leichter. Umso mehr, also ein bisschen Flugrost kriegst du mal eben so abgeschwirbelt. Aber wenn sowas richtig, richtig hart verrostet ist, da hilft auch keine Cola mehr.

Wolfi Gassler (00:33:58 - 00:34:21)

Ja, aber die Frage ist immer, schweißt du irgendwas, noch einen kleinen Teil oder holst du dir ein neues Auto? Und da ist ja dann auch der Unterschied, wie lange wartest du, weil es gibt ja auch viele Argumentationen, dass man sagt, okay, man wartet so lange, bis es nur irgendwie geht, bis es gar nicht mehr geht und dann tausche ich einfach die komplette Blackbox inklusive dem Zeug, was dranhängt, aus. Dann habe ich wenigstens einmal nur diesen Aufwand zum Austauschen und nicht am Weg ständig.

Andy Grunwald (00:34:22 - 00:35:20)

Ja, aber das ist eine lustige Geschichte. Wenn du das so machst, dann kriegst du sehr wahrscheinlich echt viel für dein Geld, weil du nutzt das ja echt lange. Das bedeutet, es hat sich 35 Mal rentiert. Aber du bringst dich auch in eine Situation, wenn das Item, was du da austauschen möchtest, wichtig für dich ist, dann bringst du dich automatisch selbst in eine Drucksituation. Und was ist, wenn just in diesem Moment dein Item, was du austauschen möchtest, im Suezkanal stecken bleibt? Jetzt sagst du, passiert ja eh nicht. Gut, haben wir jetzt mal kurz. Oder was ist, wenn auf einmal ein Virus in China ausbricht und du keine Chips mehr bekommst? Also du glaubst ja wohl nicht, dass die Autobauer gerade alle Teile auf Lager haben wie Noche und Löcher, oder? Also ich glaube, die warten jetzt gerade alle noch. Und das zieht sich ja schon alles zwei, drei Jahre. So, der Punkt ist ganz einfach. In der Zukunft passieren Sachen, die du einfach nicht vorhersehen kannst. Aber du weißt, du hast ein Risiko. Und meine Frage ist gerade einfach nur, du entscheidest dich gerade aktiv dazu, das Risiko nicht zu tacklen. Und wenn du das als Geschäftsführer tust, dann könnte man sogar sagen, du handelst echt fahrlässig.

Wolfi Gassler (00:35:20 - 00:35:32)

Ja, kommt aufs Risiko drauf an, ja. Aber du gehst ja ständig Risikos ein, also auch finanzielle, weil du überlegst, ok, verdient sich das, irgendwas auszutauschen, neu zu machen, alt zu lassen, wie auch immer.

Andy Grunwald (00:35:32 - 00:36:26)

Ja, aber richtig, und deswegen gehe ich ja die ganze Kette durch und sage, ok, wie wichtig ist dieses Item denn da auszutauschen, weil machen wir uns nichts vor. Wenn das Item für die Buchung des Kickertisches im Büro zuständig ist, dann kann man den Kickertisch halt gerade mal für ein paar Monate nicht buchen, sondern muss da hingehen und gucken, ob der frei ist. Also dann ist es halt nicht so wichtig. Aber dann würde ich das auch nicht als Risiko nennen. Natürlich, als Geschäftsführer balanciert man immer Risiken, das ist der Job eines Geschäftsführers oder einer Geschäftsführerin, aber wenn da 10, 15, 20 Prozent Revenue dran hängen und jetzt kommt's, vielleicht ist diese Box da noch nichtmals direkt für das Revenue zuständig, sondern irgendwo down the line, ja? Subdependency von Subdependency von Subdependency. Ja, dann würde ich sagen, happy birthday, hast du gewonnen. Aber wir sind ja in der heutigen Industrie, arbeiten wir sehr viel mit datengetriebenen Entscheidungen. Bist ja auch ein riesen Fan von. Hatten wir glaube ich irgendwo mal eine Episode drüber gemacht, richtig?

Wolfi Gassler (00:36:26 - 00:36:27)

Hatten wir eine Episode, natürlich.

Andy Grunwald (00:36:27 - 00:36:33)

So. Und wusstest du, dass es eine Metrik zum Softwarealterungsprozess gibt?

Wolfi Gassler (00:36:33 - 00:36:34)

Und zwar?

Andy Grunwald (00:36:34 - 00:36:50)

Nennt sich Dependency Drift. Und zwar, wie weit driftet deine existierende Versionsnummer oder deine existierenden Dependencies vom Upstream-Stand ab. Und umso weiter, umso mehr driftet die away, wenn du so möchtest. Das ist eine Metrik für Software Aging.

Wolfi Gassler (00:36:50 - 00:36:57)

Und die geht auf die Versionsnummern? Weil eigentlich müsste man theoretisch mit dem Alter arbeiten, weil es gibt natürlich... Also.

Andy Grunwald (00:36:57 - 00:37:17)

Anders, die Definition ist halt jetzt sehr einfach für dieses Format jetzt hier. Unten drunter, wie die jetzt definiert ist, müsste man jetzt noch mal gucken, so nach dem Motto, okay, ist es die Versionsnummer? Von welcher Software reden wir? Hat diese Software einen festen Release-Zyklus? Es gibt Software, die wird zweimal im Jahr immer dann released.

Wolfi Gassler (00:37:17 - 00:37:42)

Das hat sich ja jetzt auch eigentlich extrem geändert, dass du früher hattest du ja Releases, die irgendwie einmal im Jahr oder sogar noch seltener hast du irgendwie große Releases gehabt. Und wenn du die jetzt anschaust, auch so Dinge wie Datenbanken zum Beispiel, was wirklich wichtige Software ist, sogar die sind jetzt auf so einen kleinen Zyklus runtergekommen, dass das wirklich alle paar Monate kommen da irgendwelche Versionen raus, Security-Patches und und und.

Andy Grunwald (00:37:42 - 00:38:40)

Ja gut, aber dann sagst du, okay, jetzt in der Dependency Drift, ja, und wenn ich jetzt sage Dependency Drift, dann, also ich denke, der bessere Name wäre vielleicht ein Version Drift oder irgendwie sowas, da wir ja nicht über nur Dependencies reden, weil wenn du jetzt den Datenbank nimmst, zum Beispiel Postgre, dann nimmst du hier die ganze Datenbank, ja, du kümmerst dich ja nicht um den Dependency Drift von den Dependencies von Postgre, sondern um Also du hast ja hoffentlich keine PostgreSQL 7 mehr im Einsatz, wo jetzt gerade 15 aktuell ist oder gerade sogar 16 in den Startlöchern steht. Auf jeden Fall, vielleicht kommt dann auch nochmal das Datum da rein, also wann, wie alt ist die Version usw. Der Punkt ist jedoch, schau halt nach, dass du eine gesunde Balance in deinem Dependency oder Version Drift findest, in deinem Software Aging, dass du halt nicht in diese beiden Extreme abdriftest, weil immer nur Upgrade, Upgrade, Upgrade ist halt auch nicht geil. Klar, jetzt sagt man so, neueste Software fixt alle Security-Bugs, aber neueste Software kann auch neue Security-Bugs haben oder sogar Regressions.

Wolfi Gassler (00:38:40 - 00:38:49)

Was ja wirklich interessant ist, ist eigentlich, dass im IT-Administrator-Umfeld ist es ja gang und gäbe, da hast du deine TLS.

Andy Grunwald (00:38:49 - 00:38:49)

Meine was?

Wolfi Gassler (00:38:50 - 00:39:55)

TLS, Long Term LTS. LTS? LTS, nicht TLS. LTS-Versionen, du hast Enterprise-Versionen, du hast wirklich auf Hardware-Ebene irgendwie ein Support, du schließt Support-Verträge ab. Das ist ja alles sehr üblich in der Welt. Aber wenn du in die Software-Entwicklung gehst, existiert das Ganze nicht mehr. Also das, was es eigentlich in der klassischen IT-Welt, in dieser Administrator-Welt, wo alles früher nur noch Hardware war, eigentlich gibt und Standard ist, Wenn du in die Softwareentwicklung gehst, wird es immer weniger und umso mehr du in Richtung Web gehst, umso weniger wird es. Und im Web hast du fast überhaupt keinen Support mehr oder alles ist Web und fluide und schnell und es gibt gar nicht mehr so Überlegungen. Außer wenn du im absoluten Enterprise-Umfeld bist dann schon. Aber es gibt da irgendwie viel weniger Informationen. Du findest heutzutage ja nicht mal mehr irgendwelche System Requirements oder was für Browser unterstützt wird. Sogar das wird ja nicht mehr angegeben bei ganz vielen Software-Produkten.

Andy Grunwald (00:39:55 - 00:40:32)

Einer der Gründe ist relativ einfach zu erklären. Und zwar ist es die Art und Weise, wie du dieses Item, diese Enterprise-Software, diese Hardware, shippst und ausliefern kannst. Hardware muss die Hardware zum Kunden. Die muss ausgetauscht werden. Das bedeutet, da wird ein System vom Netz genommen und das muss da rein und da muss jemand Geld für zahlen und dann musst du auch die Abhängigkeit zum Kunden haben, weil der Kunde muss das auch wollen und einen Termin vereinbaren und so weiter. Enterprise Software, die on-premise gehostet wird, ist genau dasselbe. Web-Software wird zentral gehostet, wo du den Server selbst unter Kontrolle hast. Du hast es in der Hand, wann du was updatest.

Wolfi Gassler (00:40:32 - 00:41:12)

Das bedeutet, Ja, das hast du ja bei Linux genauso, da gibt's auch LTS-Versionen. Also die Grundbasis hat dieses Vorgehen von LTS, von Support, und da ist auch sehr gut beschrieben, wie lange wird was supported, was spielt miteinander. zusammen, was funktioniert nicht, lauter Dinge, die ganz gut beschrieben sind. Aber umso weiter das im Stack nach oben geht, umso schlechter werden diese Beschreibungen. Und wenn du dann eben bis nach oben im Web angekommen bist, heutzutage ist es wirklich schwierig zu finden, was für Browser wird supported. Früher war das noch angegeben, dass nur Internet-Explorer supported wird. Das war immer der Klassiker im Business-Umfeld. Heutzutage nicht mal das mehr.

Andy Grunwald (00:41:12 - 00:41:18)

Aber würdest du sagen, der Spruch, never touch a running system, war ein Fehler? Weil auch ich habe ihn früher gesagt.

Wolfi Gassler (00:41:20 - 00:41:41)

Ja, es gibt viele Sprüche, die man sagt. Auch Legacy verdientes Geld ist ein netter Spruch, aber... Bitte? Ist der beste Spruch, sorry, Andi. Ist der beste Spruch, natürlich, Legacy, die verdient Geld. Aber es stimmt natürlich schon, never touch a running system, kann natürlich in gewissen Bereichen schon sinnvoll sein. Die Frage ist halt immer, wie lang greift man ein System nicht mehr an?

Andy Grunwald (00:41:41 - 00:41:52)

Naja, bei einem Bug, der bald auftreten wird, da ist es relativ einfach, die Frage zu beantworten, wie lang fasst man ein System nicht mehr an. Ich sage nur das Jahr 2038.

Wolfi Gassler (00:41:52 - 00:42:54)

Das stimmt natürlich, ganz allgemein. Ich glaube, heutzutage ist das definitiv veraltet. Das kannst du vielleicht bei Hardware noch nachdenken, ob du in diese Richtung gehst, dass du never touch a running system. Aber sobald du im Software-Bereich bist, wo diese Zyklen so schnell geworden sind, wo du auch CI, CD hast, dass du ständig was bauen kannst, testen kannst. Test Coverage hast, wo du einfach Sachen durchtesten kannst, da ist es ja nur meine Ausrede, weil wenn du immer alles sofort updaten kannst und ändern kannst, ist es ja gut und das sollte sicher das Ziel sein. Und dann ist halt die Frage immer, wie komplex ist es und gehe gewisses Risiko ein, weil im Endeffekt ist es ja nur Schulden, die du machst und Schulden bauen sich halt auf und Schulden können Sinn machen. Wenn du ein Haus kaufst, macht es Sinn, Schulden aufzunehmen, aber du musst halt umgehen mit den Schulden. Du musst sie wieder abbauen. Du musst sie handeln können. Du kannst nicht zu viele Schulden machen. Und da ist dann halt der Spielraum, in dem man sich bewegen kann.

Andy Grunwald (00:42:54 - 00:42:58)

Naja, aber wie jetzt auch bei finanziellen Schulden, gibt es ja gute Schulden und es gibt ja schlechte Schulden.

Wolfi Gassler (00:42:58 - 00:43:04)

Ja, beziehungsweise wenn du keine Schulden machen musst, ist es das Beste, aber im Leben ist es halt schwierig.

Andy Grunwald (00:43:04 - 00:43:13)

Also bei der aktuellen Inflation hoffe ich doch mal, dass wir alle ein bisschen Schulden haben, weil das kommt dann nämlich deinem Schuldenkonto mehr oder weniger zugute.

Wolfi Gassler (00:43:14 - 00:43:18)

Wenn du fixe Zinsen hast, aber das ist wieder ein anderes Thema.

Andy Grunwald (00:43:18 - 00:44:05)

Aber holen wir mal die Hörerinnen und Hörer und die Zuschauer ab, das Jahr 2038 Problem. Das habe ich jetzt gerade mal erwähnt. Und was passiert da? Und zwar für alle, die sich damit noch nicht auskennen, für jede Applikation, die ein Unix Timestamp speichert, und die Unix Timestamp sind die Anzahl der Sekunden vom 01.01.1970 bis jetzt, Und für jede Applikation, die diesen Wert, einen Unix-Timestamp, in einem vorzeitbehafteten 32-Bit-Integer speichert, was, ich würde mich aus dem Fenster lehnen, sehr viele Systeme betreffen wird, wird im Jahr 2038 der 32-Bit-Integer-Bereich gesprengt. Weil wir dann bei einer Billion Sekunden, glaube ich, sind. Irgendwie sowas. Und somit hast du dann Integer-Overflow und die ganze Sache fängt wieder bei Null an, was dann für viele Systeme schlecht sein kann.

Wolfi Gassler (00:44:06 - 00:44:07)

Aber 38 ist noch lang hin.

Andy Grunwald (00:44:07 - 00:44:09)

Ist es wirklich so? 15 Jahre?

Wolfi Gassler (00:44:09 - 00:44:13)

Ja, ist schon noch einiges an Zeit.

Andy Grunwald (00:44:13 - 00:44:17)

Kannst du dich noch an Silvester 1999 erinnern?

Wolfi Gassler (00:44:17 - 00:44:28)

Natürlich. Alle waren verrückt. Wir hatten bei der Feuerwehr Bereitschaft, weil alle Angst hatten, dass die Welt untergeht. Wir haben wirklich wegen diesem dummen Y2K-Bug Bereitschaft gehabt.

Andy Grunwald (00:44:28 - 00:44:29)

Kannst du uns nochmal erklären, was da passiert ist?

Wolfi Gassler (00:44:29 - 00:45:06)

Du meinst, weil alle mittlerweile zu jung sind, dass sich niemand mehr ans Jahr 2000 erinnern kann? Ja, das war die alte Variante, wo man Jahreszahlen nur in zwei Ziffern dargestellt hat oder zwei Stellen dargestellt hat. Also 1998 war dann 98 und irgendwann ist es dann halt wieder 00 geworden bei 2000 und dann haben halt alle Angst gehabt vor diesem Y2K-Bug, dass irgendwas passiert. Aber es war so stark in den Medien, dass es wahrscheinlich alle irgendwie gecheckt haben und getestet und wahrscheinlich weil die Unix Timestamp auch viel verwendet wird und bei der war das natürlich kein Problem damals, wenn du das abspeicherst.

Andy Grunwald (00:45:07 - 00:45:12)

Ich kann mich noch an Aufkleber erinnern, bitte über Silvester die Computer ausschalten und solche Geschichten.

Wolfi Gassler (00:45:14 - 00:45:15)

Ja, ich glaube die Banken haben damals.

Andy Grunwald (00:45:16 - 00:45:18)

Zumindestens... Also es wurden Systeme runtergefahren?

Wolfi Gassler (00:45:18 - 00:45:51)

Eben, die hatten irgendwie so einen Buffer, die haben alles runtergefahren und dann waren ein paar Stunden offline oder irgend sowas, ja. Da hat es durchaus sowas gegeben. Aber 38 wird natürlich spannend, weil Unix Timestamp ist schon sehr wichtig und ist wirklich überall drin und die kann man auch nicht so einfach ändern, weil bei dem Y2K-Bug war das ja eher die Custom-Software, die man selber geschrieben hat oder Applikationssoftware. die halt das irgendwo unter zwei Stellen speichert in der Datenbank. Aber da bricht das ganze System ja nicht zusammen. Aber mit der Unix-Timestamp, die ist überall. Und das ist natürlich schon dann ein Problem.

Andy Grunwald (00:45:51 - 00:47:27)

So, und jetzt muss man natürlich gucken, das betrifft ja jetzt nicht nur Systeme, die die aktuelle Datei, aktuelle Zeit speichern. Das betrifft ja auch Systeme, die zwei Zeitpunkte miteinander vergleichen. Ja? Und da kommt es jetzt natürlich an gute Programmierung an. Wie zum Beispiel, wenn du zwei Sachen miteinander vergleichen möchtest, wie zum Beispiel, weiß ich nicht, Runtime oder sowas, wie schnell wurde etwas oder ähnliches. Oder du willst alle fünf Sekunden ein Event ausführen. Irgendwie sowas, was halt statisch ist, was jetzt eigentlich gar nicht an deine aktuelle Zeit gebunden ist, sondern weil du nur was nach einer gewissen Zeitdistanz machen möchtest. Sehr, sehr, sehr viele Programmierer nutzen dafür Time, also nutzen dafür den Unix-Timestamp. Was aktuell klappt, was aber in zwei Situationen immer auf die Nase fällt. Im Jahr 2038 auf jeden Fall, weil du dann auf einmal den einen Punkt wieder auf Null resettest. Und bei einer Leap Second. Das sind diese klassischen Leap Second-Bug, wo auf einmal die Zeit nicht nach vorne geht, sondern einfach mal rückwärts läuft um eine Sekunde. Für solche Events, also einfach alle 5 Sekunden irgendwie das Ausführen oder ähnliches, nutzt man eigentlich die Monotic Clock. Wenn du sowas nutzt, dann bist du zeitunabhängig, weil die Monotic Clock ist die CPU Clock. Das bedeutet, es wird auf der CPU gezählt, Sekunde 1, Sekunde 2 und so weiter und du bist nicht abhängig von der Unix Epoch Time. Ich lehne mich aus dem Fenster, sehr viele Applikationen vergleichen sowas. Nutzen die Unix Timestamp von 2038, vergleichen die gegen 0 oder was weiß ich, teilen durch 0 und das sind alles Bugs. Versucht die mal herauszufinden. Versucht die mal zu debuggen. Versucht die mal zu reproduzieren.

Wolfi Gassler (00:47:27 - 00:47:34)

Aber ich lehne mich mal weiter aus dem Fenster und glaube, dass 38 nicht mehr viel Software unterwegs sein wird, die es jetzt gibt aktuell.

Andy Grunwald (00:47:34 - 00:47:36)

Nichts hält so lange wie ein gutes Provisorium.

Wolfi Gassler (00:47:37 - 00:47:43)

Das stimmt, aber mit dem Speed, wo wir jetzt weitergehen in die Zukunft, wird es schwierig werden, meiner Meinung nach. Hoffe ich zumindest.

Andy Grunwald (00:47:43 - 00:47:57)

Ich habe in der Vorbereitung für diese Episode mal nachgeschaut, wie lange man eigentlich eine Software betreiben kann, beziehungsweise supporten kann. Was meinst du, war der Gewinner?

Wolfi Gassler (00:47:57 - 00:48:01)

Wenn du Windows 2000 sagst, dann sind es ja jetzt schon 20 Jahre.

Andy Grunwald (00:48:01 - 00:48:35)

Ich habe noch was heftigeres gefunden, was mich sehr beeindruckt und zwar ist es unsere Lieblingsdatenbank SQLite. SQLite hat im Jahr 2016 versprochen, dass sie die aktuelle SQLite Version bis 2050 supporten. Inklusive der Stabilität und Rückwärtskompatibilität der C-API und des On-Disk-Formats. Das bedeutet, Daten, die jetzt von SQLite auf Disk geschrieben werden, können mit der Version, die 2049 rauskommt, noch gelesen werden.

Wolfi Gassler (00:48:36 - 00:48:46)

Da hat er sich viel vorgenommen. Es ist eigentlich nur ein Hauptentwickler. Natürlich ist es eine Community mittlerweile, aber eine Person dahinter.

Andy Grunwald (00:48:46 - 00:49:14)

Den Link posten wir auch in die Shownotes. Lest euch das mal durch. Die haben so ein kleines Manifesto geschrieben. Die haben sich da auch wirklich Gedanken drüber gemacht. So nach dem Motto, okay. Jetzt haben wir 2023, das bedeutet 27 Jahre wird die ganze Sache auf jeden Fall noch supportet. Und die haben sich dann Gedanken gemacht, was heißt das denn eigentlich, wenn ich eine Software 27 Jahre noch supporte? Ich meine, das, worüber wir gerade sprechen, haben sie 2016, also das war dann irgendwie... 34 Jahre. Und das ist recht interessant und da muss ich einfach nur sagen Hut ab. Also ich meine, dieser Mensch muss für.

Wolfi Gassler (00:49:14 - 00:49:18)

Sein Leben... Ja, noch haben sie es nicht durchgezogen. Wir müssen jetzt mal abwarten bis 2049.

Andy Grunwald (00:49:18 - 00:49:47)

Also offen gesprochen, da steht auch ein Satz, wir wissen natürlich nicht, was in der Zukunft passiert und so weiter und so fort, aber da steht, wenn es uns möglich ist, diese Software noch so lange zu betreiben, dann sorgen wir dafür, dass halt mindestens die C-API und das Discrete-Format rückwärtskompatibel ist. Und wow. Ich glaube, da ist sich wirklich jemand bewusst, wo und wie diese SQLite-Datenbank überall eingesetzt wird. Und ich glaube, das ist uns gerade nicht bewusst.

Wolfi Gassler (00:49:48 - 00:49:56)

Also, wie wir schon immer gesagt haben, SQLite super Datenbug. Sollte mal verwenden. Bei MySQL ist das garantiert nicht garantiert.

Andy Grunwald (00:49:56 - 00:50:00)

Um Gottes Willen, MySQL garantiert noch niemals ein Upgrade auf die letzte meiner Version.

Wolfi Gassler (00:50:00 - 00:50:04)

Also von daher... Ja, das ist dein persönlicher Fight, den du da gerade führst mit MySQL.

Andy Grunwald (00:50:04 - 00:50:33)

Ja, das ist richtig. Ich renne in letzter Zeit immer in so meiner Bugs bei MySQL. Zusammengefasst sollte man bei der ganzen Versions-Upgrade-Geschichte einfach nicht in die zwei Extremen fallen. In die eine gar nicht mehr upgraden und zwar verrosten lassen und in die andere einfach nicht jeder neuen Version hinterherjuckeln oder hinterherhypen. Von daher, ich glaube, wenn man sich im gesunden Mittelfeld bewegt, dann kommt man gut voran. Man muss sich dafür natürlich auch Strategien und Zeitfenster zurechtlegen, um auch schwierige Komponenten wie Datenbank und Co. zu upgraden.

Wolfi Gassler (00:50:33 - 00:51:06)

Ich glaube, was man sich aber auch im Klaren sein muss, dass diese Update-Zyklen, die in der Vergangenheit waren, einfach immer kleiner werden. Egal in welcher Branche, in welcher Software. Definitiv, wenn man sich die letzten Jahrzehnte anschaut, der Trend ist einfach in die Richtung immer schnellere Updates, weil auch das passieren muss einfach mit Security und gar nicht nur Features, aber alles, was da irgendwie dranhängt. Es wird einfach alles schnelllebiger und schneller. Und ich glaube, man kann, egal welchen Speed man gefahren ist vor x Jahren, er wird jetzt schneller sein. Also da bin ich hundertprozentig überzeugt.

Andy Grunwald (00:51:06 - 00:51:21)

Ich glaube, ich hatte das schon mal erwähnt im Podcast, glaube ich auch. In meinem Studium habe ich den Produktlebenszyklus vom Volkswagen Golf durchgenommen. Und schaut euch mal einfach an, wann der Golf 1 released wurde, der Golf 2 und jetzt der Golf 6 und wo sind wir jetzt, Golf 8 oder 9 oder so, weiß ich gerade auch nicht mehr.

Wolfi Gassler (00:51:21 - 00:51:22)

Ja, du bist der Deutsche.

Andy Grunwald (00:51:22 - 00:51:25)

Ja, aber ich fahre noch ein altes Auto, deswegen. Auf jeden Fall.

Wolfi Gassler (00:51:25 - 00:51:26)

Einfach ein Golf.

Andy Grunwald (00:51:26 - 00:51:39)

Ja, aber ein Golf 6, ist richtig, aber das ist auch schon 13 Jahre alt. Wie dem auch sei, schaut euch mal die Jahre zwischen den Releases an. Und die werden immer kürzer. Und das unterstreicht genau das, was der Wolfgang gerade gesagt hat. Egal wo, alles wird immer schnelllebiger.

Wolfi Gassler (00:51:39 - 00:52:23)

Ja, und vor allem, weil wir jetzt gerade bei Autos noch sind. Früher hat man einmal ein Auto gekauft, das war's. Und jetzt fangst du an mal updaten und bevor du losfahren kannst, kannst du einen 20-Minuten-Update fahren und da gibt es Geschichten aus dem E-Auto-Sektor auch, wo du musst dann wirklich warten, bis das Ding fertig updatet hat und davor darfst du nicht weiterfahren oder es funktioniert dann gar nicht mehr und du kriegst das Auto nicht mehr auf. Also da gibt es schon Horror-Geschichten, aber auch da sieht man, es wird einfach alles komplexer und die Update-Zyklen gehen nach unten und ich glaube, mit dem muss man sich einfach befassen und wirklich daran arbeiten, dass man da schneller wird mit den Update-Zyklen. Weil wenn man den Zug verpasst, irgendwann wird man mal ein konkretes Problem haben und dann hat man wirklich ein großes Problem womöglich.

Andy Grunwald (00:52:23 - 00:52:57)

Ich weiß gar nicht, ob man da immer so schneller werden muss oder ob man sich einfach nur eine gute Strategie zur Hand legen sollte. Ich denke, die Nutzung von Long-Term-Support-Versionen, LTS-Support-Versionen, ist völlig valide. Und früher in meiner Agenturzeit haben wir das sehr, sehr oft gemacht. Das bedeutet, wir sind auf die nächste LTS-Version gegangen und hatten zwei Jahre Ruhe und sind danach auf die nächste LTS-Version gegangen. Klar, das Upgrade hat mehr Zeit gekostet als kontinuierlich upgraden. Das ist genauso wie, wenn du einmal im Jahr dein Auto saugst, wirst du da einfach länger fürs Auge brauchen, als wenn du es jede Woche fünf Minuten machst. Das ist einfach so.

Wolfi Gassler (00:52:57 - 00:53:39)

Aber ich glaube halt auch, dass du in Zukunft einfach mehr Probleme haben wirst von, auch wenn es LTS ist, du bekommst so die Security-Updates, aber wenn du dann auf eine nächste Version aufsteigst, wirst du viel mehr Probleme haben, weil du einfach viel mehr Breaking Changes hast. Durch diese Schnelllebigkeit gibt es natürlich auch immer mehr Breaking Changes in den Versionen. Du kannst natürlich argumentieren, okay, mach es trotzdem dann nur einmal, das muss man abwägen, ist eh ganz klar. Aber auch da, glaube ich, wird es schwieriger. Und das, was man früher gemacht hat, die Update nur alle drei, vier, fünf Jahre, das wird, glaube ich, auch immer, immer schwieriger, weil das Zeug immer komplexer wird. Und da hilft mir auch ein Long-Term-Support nichts. Weil ich bekomme zwar die Security-Updates, aber das Umsteigen wird dann einfach schwieriger.

Andy Grunwald (00:53:40 - 00:54:55)

Ja, das ist richtig, aber besonders durch so Varianten wie LTS-Versionen oder E-extended LTS-Versionen wird's mit hoher Wahrscheinlichkeit auch immer spezialisierte Dienstleister dafür geben, die dann das Upgrade mit dir machen. Und cool, klar, du zahlst die ganze Geschichte, ja, aber wird's immer möglich sein, da auch immer noch für eine alte Version noch Support zu kriegen und dann wird's halt richtig teuer, aber hey, das ist dann, ich sag mal, der Tradeoff, den du machst, ja. Wie dem auch sei, falls ihr immer nur am Zahn der Zeit bleiben wollt, schaut euch auf jeden Fall unseren besten Mitarbeiter an, den Dependabot oder eine andere Software, nämlich Renovatebot. Könnt ihr euch auch ins Git-Repository einklinken. Macht das ähnlich wie Dependabot und die Details sind ein bisschen anders, aber beide Software-Systeme helfen euch, eure Dependencies up-to-date zu halten. Und jagt nicht jedem Trend hinterher. Also nur weil jetzt eine neue Versionierung kommt, sagen wir, das Wolfgang Versionskontrollsystem heißt das nicht, dass ihr da von Git wechseln müsst. Soviel dazu. Ich hoffe, ich bin sehr vielen Leuten, die immer der nächsten Nuller-Version nachjagen, nicht auf den Schlips getreten und wenn doch, tut es mir leid. Und natürlich immer noch die Best-Practice, die wir auch erwähnt haben. Version-Pinning, meines Erachtens nach Best-Practice. Und lasst eure Software jede Nacht einmal bauen, damit ihr einfach externe Dependencies schnell identifiziert, wenn diese fehlen.

Wolfi Gassler (00:54:56 - 00:55:10)

Ist genau wie beim Backup. Ein Backup ist nur dann ein sinnvolles Backup, wenn du den Restore immer regelmäßig machst. Das ist beim Bild dasselbe. Nur zu wissen, dass man den Source-Code hat und dass es vielleicht eigentlich bauen könnte, heißt noch lange nicht, dass es schlussendlich baut.

Andy Grunwald (00:55:10 - 00:55:12)

Und bis dahin ist es Schrödingers Backup, oder?

Wolfi Gassler (00:55:12 - 00:55:24)

Genau, Schrödingers Backup ist sowieso immer gut. Schrödingers bauen, Schrödingers Backup. Falls ihr noch irgendwelche Infos habt, vor allem zu dem ganzen Bankomat Thema, bitte schickt uns das, falls ihr da irgendwie einen Einblick habt.

Andy Grunwald (00:55:24 - 00:55:26)

Ich hab das schon wieder vergessen.

Wolfi Gassler (00:55:26 - 00:56:02)

Und falls ihr Feedback habt, schickt uns das bitte auch. Wir haben auch jetzt unten in der Episode immer so einen Link, wo ihr einfach schnell sagen könnt, ist cool, war weniger cool, einfach um uns so ein bisschen schnelles Feedback zu geben. Und drückt gerne mal den Thumbs Down, den Daumen nach unten, auch wenn es euch nicht so super gefallen hat, hilft uns auch einfach, da besseres Feedback zu bekommen. Und sonst auf allen üblichen Kanälen, die unten in den Show Notes stehen. Und, nachdem wir jetzt ja auch ein Video haben, vielleicht da unten sind auch irgendwelche Thumbs Up Knöpfe. Es heißt ja immer, wenn es euch gefallen hat, Thumbs Up, wenn es euch nicht gefallen hat, zweimal Thumbs Down. Also sagen wir auch diesen Standardspruch scheinbar.

Andy Grunwald (00:56:02 - 00:56:03)

Ich würde jetzt mehr als einmal.

Wolfi Gassler (00:56:06 - 00:56:29)

Aber ist ja für uns auch jetzt ein neues Format. Lasst uns auch mal wissen, was ihr davon hält. Eventuell bringen wir auch eine kleine unterschiedliche Variante von Podcast und Video raus. Wir werden uns das mal genauer anschauen. Aber würde uns auf jeden Fall interessieren, ob euch dieses Format auch gut gefällt, ob ihr auf YouTube auch sowas hört oder ob ihr sowieso nur auf den Podcast Plattformen seid. Lasst uns das auch gerne wissen.

Andy Grunwald (00:56:29 - 00:56:32)

Der Wolfgang hat genug gebrabbelt. Ich verarsche mir nämlich. Tschüss, bis zum nächsten Mal.