Engineering Kiosk Episode #175 Von Lustig bis Traurig: Wenn Open Source Geschichten schreibt

#175 Von Lustig bis Traurig: Wenn Open Source Geschichten schreibt

tech-kultur open-source
Copy Link
Diese Episode in deiner Podcast-App hören...
Engineering Kiosk #175 Von Lustig bis Traurig: Wenn Open Source Geschichten schreibt bei Apple Podcasts Apple
Engineering Kiosk #175 Von Lustig bis Traurig: Wenn Open Source Geschichten schreibt auf Spotify Spotify
Engineering Kiosk #175 Von Lustig bis Traurig: Wenn Open Source Geschichten schreibt auf Amazon Music Amazon
Engineering Kiosk #175 Von Lustig bis Traurig: Wenn Open Source Geschichten schreibt auf Deezer deezer
Engineering Kiosk #175 Von Lustig bis Traurig: Wenn Open Source Geschichten schreibt auf YouTube YouTube

Shownotes / Worum geht's?

Die Transparenz von Open Source schreibt Geschichten, die erzählt werden wollen

50% des Begriffes “Open Source” besteht aus dem Wort “Open”. Ok. Für diese Erkenntnis muss man nun nicht studiert haben. Open bzw. Offen bzw. Transparenz bezieht sich dabei nicht nur auf den Source Code selbst, sondern i.d.R. auf alles, was das entsprechende Projekt betrifft. Dazu zählen u.a. für jedermann einsehbare Bug-Reports und Pull Requests. Wenn man dies nun mit weltweiter Kollaboration verschiedener Menschen und Kulturen mixt, ist eins vorprogrammiert: Kreativität, WTF-Momente, persönliche Schicksale und Geschichten, die erzählt werden wollen. 

Diese Episode erzählt einige dieser Open Source Geschichten. Wir sprechen darüber, wie man Douglas Crockford dazu bringt, über JavaScript Code zu streiten, wann für einen Pull Request eine eigene Torte gebacken wird und warum dies dann zu einem Merge führt, sowie wann und warum Unit Tests fehlschlagen, wenn diese in Australien ausgeführt werden. Es geht aber auch um traurige Seiten und persönliche Schicksale. Zum Beispiel eine Gefängnisverurteilung eines Maintainers von einem Projekt, welches 26 Millionen Downloads pro Woche hat, eine Krebserkrankungen mit verbundener Anteilnahme der Community und wie der Maintainer die Zukunft des Projektes sichert für die Zeit, wenn er nicht mehr da ist oder auch wie die Maidan-Revolution und der Ukraine-Krieg Open Source beeinflussen.

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

Das schnelle Feedback zur Episode:

👍 (top) 👎 (geht so)

Feedback

Sprungmarken

(00:00:00) Intro

(00:01:32) Open Source Stories und kreative Projekte

(00:05:09) Info/Werbung

(00:06:09) Open Source Stories und kreative Projekte

(00:11:44) Maintainer von Core.js muss ins Gefängnis

(00:19:06) Eine Torte für einen TypeScript Pull Request

(00:25:14) Krebs und die Proxmox Community Scripte

(00:30:52) Unit Tests schlagen fehl, wenn man diese in Australien ausführt

(00:38:54) Microsoft Calculator wird Exploit-Free gemacht

(00:41:33) Maidan-Revolution und der Ukraine Krieg

Hosts

Feedback

 

Transkript

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

Andy Grunwald (00:00:00 - 00:00:18) Teilen

Open Source ist ja so ein Dauerbrenner hier bei uns im Podcast, aber eigentlich ist Open Source ein Dauerbrenner für uns alle, denn wir alle hätten kein Mobilfunkgespräch oder WhatsApp oder ähnliches ohne WhatsApp. Ohne Open Source nicht WhatsApp. Okay, nochmal neu.

Wolfi Gassler (00:00:20 - 00:00:22) Teilen

Du kannst da gerade weitermachen.

Andy Grunwald (00:00:24 - 00:00:32) Teilen

Das tolle ist an Open Source ist das Wort Open Ÿousand, denn alles ist offen, alles ist transparent. Meine Güte, Open Source ist ja hier so ein Dauerbrenner im Podcast.

Wolfi Gassler (00:00:32 - 00:00:36) Teilen

Und irgendwie ist Open Source Dauerrenner, oder Dauerbrenner?

Andy Grunwald (00:00:36 - 00:00:51) Teilen

Dauerrenner, Dauerbrenner. Es ist auf jeden Fall dauerhaft da. Und es ist auf jeden Fall dauerhaft da für uns alle, denn wir könnten noch nicht mal eine WhatsApp Nachricht schicken, hätten wir kein Open Source. Und das tolle an Open Source ist ja, dass es open ist. Und somit ist es gleichzusetzen mit Transparenz.

Wolfi Gassler (00:00:51 - 00:00:56) Teilen

Warum können wir keine WhatsApp Message schicken, wenn man keine Open Source hat? Das ist ja kommerziell.

Andy Grunwald (00:00:56 - 00:01:01) Teilen

Ja, und du möchtest mir sagen, die nutzen nur proprietäre Libraries und alles selbst geschrieben bei WhatsApp?

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

Gute Frage.

Andy Grunwald (00:01:02 - 00:01:03) Teilen

Auf gar keinen Fall.

Wolfi Gassler (00:01:03 - 00:01:16) Teilen

Warte mal, müssten die nicht so ein licenses Zeug haben? App Info Licenses? Ja, du hast recht, ich habe gerade mal schnell aufgemacht. Das Licenses File startet schon mal mit apache License und dann ganz viele andere Sachen.

Andy Grunwald (00:01:16 - 00:01:59) Teilen

Und das Tolle an dieser Transparenz ist, dass diese Transparenz führt ab und zu mal zu lustigen Situationen, auch zu der Kreativität von Leuten. Bzw. Wird da die Kreativität von den Leuten erstmal wirklich sichtbar. Denn GitHub ist ja voll mit Software und GitHub ist teilweise auch voll mit echt lustigen Produkten oder Projekten. Ich habe da mal drei rausgesucht, um das mal ein bisschen zu verdeutlichen. Das erste ist fizz Bass. Kennt vielleicht jeder, wenn die. Man zählt hoch, eins, zwei, drei, vier, fünf. Und immer wenn eine Zahl durch drei teilbar ist, sagt man fis. Immer wenn eine Zahl durch fünf teilbar ist, sagt man bass. Und immer wenn eine Zahl durch drei und fünf teilbar ist, sagt man Fizzbas. Also eins, zwei, fis, vier, bass, fis, sieben und so weiter.

Wolfi Gassler (00:01:59 - 00:02:02) Teilen

Ist das ja duisburger Saufspiel, oder?

Andy Grunwald (00:02:02 - 00:03:36) Teilen

Das gibt es, glaube ich, international, aber da kann man auch sehr geile Saufspiele draus machen. Wir kennen das auch mit King Kong. Also Fizz ist King und Bass ist Kong. Aber wie dem auch sei. Da hat aber jemand fizz Buzz Enterprise Edition gebaut. Das bedeutet feinste Stereotypen, Java Architektur Patterns. Und wie heftig oder overengineeren kann man denn Fisbas? Und Dieses Projekt ist natürlich ein Traum für jeden Java Entwickler. Ein anderes schönes kreatives Projekt ist Trump Script. Ist ein Python Subdialekt. Man hat also der Sprache Python, zumindest der Syntax von Python, ein paar neue Keywords beigebracht und die Sprache ein bisschen, wie soll man sagen, umgeändert. Drei Features möchte ich euch ganz kurz nennen. In Trumpscript gibt es keine Floating Point Numbers, nur Ganzzahlen, also Integers, weil Amerika keine halben Sachen macht. Ist ja logisch, oder? Du sagst auch nicht, es ist etwas true oder false, sondern es gibt nur die Keywords fact and lie und alle Programme müssen mit america is great enden. Also wenn man ein bisschen Trump Script schreiben möchte. Ich glaube, da wäre jetzt wieder die Zeit. Und ein drittes Projekt hat was mit einem deutschen Autobau zu tun, Volkswagen. Und zwar ist die Punchline Volkswagen detects when your tests are being run in the CI server and make them pass. Auch schön. Also falls ihr mal ein bisschen Probleme mit eurer Testsuite habt, nutzt ihr einfach mal Volkswagen. Aber das war jetzt die lustige Seite. Leider zeigt Open Source ab und zu auch mal das wahre Leben. Man könnte fast sagen, open Source sorgt für eine Achterbahn der Gefühle.

Wolfi Gassler (00:03:36 - 00:03:41) Teilen

Moment, ich finde es eigentlich sehr lustig, die nächste Geschichte, die kommt, aber ich will nicht schon alles vorwegnehmen.

Andy Grunwald (00:03:41 - 00:03:41) Teilen

Zweitausendein.

Wolfi Gassler (00:03:41 - 00:03:43) Teilen

Aber vielleicht sind wir da anderer Meinung.

Andy Grunwald (00:03:43 - 00:04:10) Teilen

Diese Episode ist jetzt mal eine kleine Zusammenstellung von sehr lustigen Dingen, die in der Open Source Welt passiert sind. Z.B. sehr, sehr lustige Pull Requests, erstaunliche Pull Requests oder Issues, die auch zu Transparenz gesorgt haben, aber leider dann auch mal ein paar Downer sozusagen, also ein paar Pull Requests oder Projekt Stories, die so mal das wahre Leben zeigen. Deswegen, wir starten direkt mal mit was Positivem. Wolfgang, bist du bereit?

Wolfi Gassler (00:04:11 - 00:04:16) Teilen

Jetzt hast du gesagt, es kommt was Negatives, aber es ist eine persönliche Geschichte, also schieß einfach mal los.

Andy Grunwald (00:04:16 - 00:04:26) Teilen

Ich bin. Nein, es ist natürlich was positives, womit wir starten, denn wir wollen mit einer positiven Meinung hier rein starten. So, pass auf. Und zwar kennst du Awesome Lists auf GitHub?

Wolfi Gassler (00:04:27 - 00:04:38) Teilen

Repositories, die Links sammeln zu einem gewissen Thema, die sehr cool sind, z.B. zu allen Ressourcen, zu Redis, zu coolen MySQL Projekten, whatever.

Andy Grunwald (00:04:38 - 00:05:34) Teilen

Genau, sind einfach, ich sag mal, wie die ersten Suchmaschinen, ja, eine Link Liste und die erste Story geht um eine awesome List für statische Code Analyse Tools. Das positive an diesen Listen ist, man kriegt eine gute Übersicht zum Einstieg, oft kategorisiert, doch die klassische Herausforderung ist immer, wie hält man diese up to date und auch somit relevant? Denn diese Listen sind halt nur relevant, wenn sie auch up to date sind. Auf jeden Fall bei dieser Awesome List für statische Code Analysen ging es genau um diese Frage, wie hält man es up to date? Es wurde ein Issue erstellt Anfang 2019, das gesagt hat, JShint und JSLint sind outdated und diese sollen jetzt hier nicht mehr gelistet werden und ESLint sei der Nachfolger. Du merkst schon, es geht um JavaScript. Soweit würde ich erst mal sagen, faire Kritik finde ich ja cool, wenn jemand da durchguckt und sagt hey, die Tools sind all of date. Zweitausendein der haupt Maintainer, unser guter Freund Matthias Endler, Produzent vom Rust Production Podcast.

Wolfi Gassler (00:06:34 - 00:06:36) Teilen

War bei uns auch in Episode 98.

Andy Grunwald (00:06:36 - 00:08:18) Teilen

Zu Gast, wer da mal reinhören möchte. Auf jeden Fall der haupt Maintainer sagte Hör mal du, ja, ich bin kein JavaScript Dev, deswegen kann ich das schlecht beurteilen. Hat dann, ich sag mal kurz in die Projekte ja, es sind und Jazzlin reingeguckt, wann wurden die das letzte mal angefasst? Wann wurden die das letzte mal released? Und hat dann ein paar Leute getaggt. Z.B. ich wurde getaggt und ein anderer Maintainer von dem Repository, so um nach unseren Meinungen zu fragen. Hey, was was denkt ihr darüber? Und Douglas Crockford, also der Autor von JS Lind wurde auch getaggt. Man muss wissen, Douglas Crockford ist nun nicht der Autor von JS Lindt, sondern er hat JavaScript selbst auch mitentwickelt und ist der Erfinder von Jason. Also ich würde mal sagen, dieser Mensch hat Ahnung von JavaScript. Wie gesagt, ich wurde auch getaggt, nach meiner Meinung gefragt und ich bin ebenfalls keine JavaScript Dev, deswegen habe ich das eigentlich dasselbe gemacht. Ich habe andere JavaScript Devs getaggt und die nach ihren Meinungen gefragt. Nach zwei, drei Tagen hatte man eine Lösung. Man entfernt diese beiden Projekte nicht, sondern man führt ein neues Symbol ein, so ein Warn Ausrufezeichen für Projekte, die gegebenenfalls out of date sind. Dann war das Issue eigentlich schon durch. Einen Tag später, Douglas Crockford selbst kommt in den Pull request und sagt hey, JS Lindt ist immer noch up to date und das kann hier drin bleiben, das wird noch maintained und so weiter und so fort. Ÿousand danach gab es so einen kleinen Schlagabtausch mit dem originalen Autor des Issues, dass ein gewisser Code Teil von ihm nicht ordentlich detektet wird. Und ja, Douglas Crockford hat sich da so ein bisschen, ich sag mal, einen Schlagabtausch unterzogen und dann auch alle Argumente des originalen Autors entkräftet. Ergebnis JS Lind und JS Hind sind immer noch gelistet. Mit einem Verweis auf dieses Issue kann dann jeder selber sagen, ob er oder sie das noch einsetzen möchte.

Wolfi Gassler (00:08:18 - 00:08:35) Teilen

Du hast es jetzt so ruhig erzählt, aber die haben sich ja ziemlich in die Haare gekriegt und sind da aufeinander losgegangen und haben dann diskutiert, was da okay ist und was nicht okay und was jetzt falscher JS Code ist und falscher Syntax und richtiger Syntax. Also da ist schon aufgegangen, was man übrigens sehr oft sieht in so Issues.

Andy Grunwald (00:08:36 - 00:09:20) Teilen

Ja, aber ich würde auch mal sagen, die Sprache verzeiht einem auch sehr viel. Und wenn der Compiler da nicht meckert, dann ist beides richtig, meines Erachtens nach. Aber auf jeden Fall haben die beiden sich da, wie gesagt, in die Haare bekommen. Warum erzähle ich diese Story? Das ist eine ganz schöne Geschichte, weil Douglas Crockford, ich meine, der Kollege hat die Hauptsprache mitgeschrieben und ich hätte nie gedacht, dass dieser Mensch da mal vorbeikommt in dem GitHub Issue und sagt seine Meinung, ob das Tool noch up to date ist oder nicht. Also mein Learning ist auf jeden Fall einfach mal die Leute taggen, egal wer es ist, es sind auch nur Menschen und wenn sie Zeit haben, dann melden sie sich auch zu Wort. Und das zweite Learning, man kann einfach mit jedem reden und Open Source und Technologie verbindet halt. Fand ich auf jeden Fall super schön und ich habe super gegrinst, als Douglas Crockford auf einmal auf dieses Issue kommentiert hat. Hätte ich nicht gedacht.

Wolfi Gassler (00:09:20 - 00:09:32) Teilen

Und wie hast du jetzt den Stil empfunden von Douglas Crockford, den Schreibstil und wie er argumentiert hat? Komm da mal mit was Persönlichem um die Ecke, nicht nur nur so sachlich über einen Issue erzählen.

Andy Grunwald (00:09:32 - 00:09:35) Teilen

Ich glaube, wenn ich das neutral formulieren müsste, könnte man sagen, du sollst es.

Wolfi Gassler (00:09:35 - 00:09:39) Teilen

Eben nicht neutral formulieren, du sollst es so formulieren, wie du es denkst.

Andy Grunwald (00:09:39 - 00:10:12) Teilen

Ne, neutral würde ich sagen, sehr opinionated aus meiner Sichtweise. Hätte ein bisschen empathischer sein können. Stimmt schon. Ÿousand ein bisschen an die Hand nehmen können, wie es denn ordentlich zu schreiben wäre und so weiter und so fort. Auf der anderen Seite, der originale Issue Auto hat sich auch nicht die Zeit genommen und hat ordentlich das Problem erklärt. Also die, ich würde mal sagen, beide waren da so ein bisschen schuld. Ich sage jetzt nicht, dass der eine das Arschloch war oder der andere das Arschloch. So weit möchte ich nicht gehen, sondern niemand hat sich wirklich die Zeit genommen und hat den Respekt auf den Tisch gelegt. Um die andere Person zu verstehen.

Wolfi Gassler (00:10:12 - 00:13:20) Teilen

Ein anderes Szenario oder Repository, wo der Umgangston teilweise auch nicht sehr zweitausendeinundzwanzig nett war, ist ein recht bekannter Fall aus 2019. Und zwar geht es da um das Projekt Core JS. Also das ist so eine JavaScript Library eigentlich so eine Polyfill, so ein paar Standardfunktionen, die man in JavaScript auch ständig braucht. Eigentlich sehr bekanntes, großes Projekt, hat zu damaligen Zeiten 26 Millionen Downloads jede Woche gehabt, also schon sehr weit verbreitet. Und zur damaligen Zeit gab es eigentlich nur einen Haupt Maintainer zweitausendein, Dennis Buschkarev. Und der hatte das Problem, was glaube ich ganz viele Open Source Repositories haben, man macht etwas, es wird extrem viel eingesetzt, alle verwenden das, haben den Vorteil und du bekommst eigentlich sehr wenig und denkst dir dann irgendwann, okay, ich muss auch von irgendwas leben. Und da gibt es natürlich mehrere Möglichkeiten, wie man dem Ganzen begegnet. Wir haben im Podcast ja auch schon oft darüber gesprochen, was der Dennis gemacht hat. Er hat über den npm package manager, den sie im JavaScript Eco System gibt, hat der Messages ausgespuckt, wenn man Code js verwendet, dass er eben gerne an dem Projekt weiterarbeiten will und dementsprechend natürlich auch irgendwie finanzielle Ressourcen braucht. Also es machen ganz viele Projekte, da bekommt man am Ende so eine Message. Was er ein bisschen übertrieben hat, ist, er hat es nicht nur einmal ausgegeben, sondern er hat sich da nach jedem Package reingehackt und hat nach jedem Package, das du installiert hast, diese Message ausgegeben. Also man hat da wirklich dann hunderte solche Messages gehabt von ihm. Er braucht Geld, er braucht Geld. Und wie man sich gut vorstellen kann, diese ganz vielen Messages, diese Spenden Messages, die haben natürlich extremen Unmut auch in der Community ausgelöst. Also da gab es dann wirklich viele Messages, die gesagt haben, er muss das stoppen, er soll das aufhören zu machen. Und er hat dann genau so reagiert, wie man vielleicht auch nicht idealerweise reagiert. Er hat gemeint, er braucht halt das Geld, er hat da auch gerade Anwaltskosten zu zahlen und einen Gerichtsprozess und er wird es nicht ändern. Und er hat es sogar auf stur geschalten, weil er hat dann später mal geschrieben, das war eigentlich nur so ein Test und weil sich so viele Leute beschwert haben, lastet es gerade absichtlich drin, was natürlich noch mehr Öl in dieses Feuer geschüttet hat. Und man kann das nachlesen in dem Issue, da ist es wirklich abgegangen. Also Die Leute haben sich wirklich beschwert. Klarerweise haben auch viele ihm beigestanden und haben sowas geschrieben wie Open Source Maintenant sind gar nicht schuldig und die bekommen eh nichts. Und er hat auch Support bekommen. Aber natürlich seine Art das zu kommunizieren, war dann schon eine schwierige. Und was ich jetzt so nebenbei nur erwähnt habe, dass er eigentlich so einen Gerichtsprozess an der Backe hatte, das hat sich dann herausgestellt, dass das eigentlich ein viel größeres Problem ist für dieses ganze Projekt, denn das war nicht nur ein kleiner Gerichtsprozess, sondern ein Gerichtsprozess, wo er verurteilt werden hätte können bzw. Dann auch verurteilt wurde und ins Gefängnis musste. Und zwar 18 Monate lang, weil das war ein Autounfall und am Ende ist eine Person leider gestorben und dementsprechend hat er 18 Monate im Gefängnis verbringen müssen und er war der einzige Maintainer. Und bei einem Projekt von 26 Millionen Downloads jede Woche bekommt da die Aussage.

Andy Grunwald (00:13:20 - 00:13:24) Teilen

Buzz Factor mit dem Autounfall eine ganz neue Bedeutung.

Wolfi Gassler (00:13:24 - 00:13:26) Teilen

Ah, der war wieder deep.

Andy Grunwald (00:13:26 - 00:13:36) Teilen

Also wir grinsen jetzt. Ist natürlich nicht toll, wenn man einen Autounfall oder einen Torradunfall hat, aber Ÿousand, die Kombination mit einer Person maintained eine so große genutzte Library.

Wolfi Gassler (00:13:36 - 00:15:21) Teilen

Naja gut, aber du hast recht, es ist natürlich der berühmte Bassfaktor. Und das interessante war auch, dass er eigentlich nicht wirklich mit dem rausgerückt ist, sondern ein anderer Contributor in der Community hat eigentlich darauf aufmerksam gemacht, hey, wir haben da ein Problem, wie geht denn das weiter mit der Entwicklung überhaupt? Also wenn du ins Gefängnis gehen musst, was passiert dann? Oder die Option zumindest da ist, dass es passiert. Zweitausendein. Und es gab dann auch wieder eine sehr lange Diskussion hin und her. Und es hat sich dann aber so ein Site Maintainer gefunden, der schon Schreibrechte hatte auf das Projekt. Und der hat eigentlich dann die ganzen Wogen geglättet, hat die Leute beruhigt, auch mit ein paar anderen Contributern gemeinsam und hat gesagt, okay, ich habe Schreibzugriffe, ich habe das gecheckt mit dem Original Maintainer und der wird eine Zeit weg sein. Im Endeffekt war es dann zweitausendein, Februar bis Okt. 2020, also fast ein ganzes Jahr, wo wirklich die Commits bei null gestanden sind. Ich habe das noch mal nachgeschaut in der History, kann man ja schön nachverfolgen, also da geht der Strich einfach noch auf null runter und danach geht er aber wieder nach oben. Das heißt, Maintainer ist dann auch wieder zurückgekommen. Danach hat das ganze Projekt weitergeführt und es ist immer noch ein super aktives Projekt. Also das war eigentlich nur eine kleine Pause dazwischen und es hat sich eigentlich alles wieder erholt. Und mit der anderen Person, die sich scheinbar sinnvoll verstanden haben, auch die hat alle ganz gut abgeholt und hat es abgeschwächt und hat es dann sinnvoll eben dieses Jahr weitergeführt. Aber die Gefahr war natürlich schon da, dass das Projekt vielleicht stirbt, weggefuckt wird. Insofern ist es schon wichtig, da natürlich immer eine Person am Ruder zu haben, die das irgendwie weiter betreut. Man hätte es natürlich auch weiter aufstellen können, aber wenn ich den mal so einschätze, die Nachrichten, die er so geschrieben hat, ist es jetzt vielleicht nicht die Person, die gerne ein großes Team um sich hat.

Andy Grunwald (00:15:21 - 00:15:37) Teilen

Könnte man ja fast als BDFL ohne B bezeichnen, oder? Also nicht kein wohlwollender Diktator, sondern vielleicht so ein Diktator von Core Js. Also ich meine, die Spendenaufrufe nach jedem Package Install, das klingt ja schon fast brutal.

Wolfi Gassler (00:15:37 - 00:15:42) Teilen

Ja, war es auch. Also ich glaube, es ist schon auch ein stures Kerlchen, würde ich mal sagen.

Andy Grunwald (00:15:42 - 00:15:47) Teilen

Das ist jetzt deine neutrale Ausdrucksweise, die du mir gerade vorgeworfen hast, bei Douglas Crockford oder Ÿousand.

Wolfi Gassler (00:15:47 - 00:15:53) Teilen

Ja, ich kann auch andere Kommentare zitieren, wie z.B. looks like the karma police got him.

Andy Grunwald (00:15:53 - 00:16:21) Teilen

Boah, also nur wegen ein paar Konsole Outputs ins Knast zu gehen, weiß ich nicht, ob das jetzt Karma ist. Aber gut, was zeigt uns das Learning von der ganzen Thematik, würde ich mal sagen. Wir müssen mal ein bisschen darauf achten, dass, Achtung, Core Projekte mal ein bisschen weiter aufgestellt sind, auf mehrere Schultern verteilt sind und natürlich, dass das reale Leben einfach jeden treffen kann. Kann. Ich weiß jetzt natürlich nicht, was das für ein Unfall war, in welchem Land das war und Co. Aber das kann eigentlich jeden treffen.

Wolfi Gassler (00:16:21 - 00:16:49) Teilen

Ja, vor allem das Kritische ist ja eigentlich, wenn du nicht vorgesorgt hast und keine weitere Personen hast mit Schreibzugriffen, weil wenn du zufällig sofort weg bist, in dem Fall hatte der ja Zeit, da war die Gerichtsverhandlung, er hatte das teilweise kommuniziert, da waren die Diskussionen, das hat alles ein paar Monate gedauert. Da hast du ja noch Möglichkeiten, aber wenn jetzt wirklich irgendwas passiert, dann hast du die einzige Möglichkeit, dass du weg forkst. Und das ist natürlich schon dann schade, wenn du nur so reagieren kannst und da weniger Möglichkeiten dann hast.

Andy Grunwald (00:16:49 - 00:17:02) Teilen

Naja, dank Open Source ist das Forking ja möglich. Aber ich meine, da hatten wir in einer eigenen Episode ja auch darüber gesprochen, was für Herausforderungen dann Forking hat bei einem Projekt, was 26 Millionen Downloads jede Woche hat, nämlich die Adoption dann dessen.

Wolfi Gassler (00:17:02 - 00:17:20) Teilen

Ja, und es ist auch so, du brauchst z.B. auf npm auch Schreibrechte. Also das ist gar nicht nur im originalen Repo, du brauchst ja auch an anderer Stelle vielleicht Zugriff und musst da eingreifen, weil sonst musst du womöglich das ganze Package umbenennen, ein neues Package überhaupt daraus generieren, das neue anmelden und so weiter. Also da hängt ja auch ganz viel dran.

Andy Grunwald (00:17:20 - 00:17:27) Teilen

Aber ich bin jetzt mal hier wieder für die gute Laune zuständig. Du bringst ja hier irgendwie nur Tragödien mit in den Podcast, Wolfgang.

Wolfi Gassler (00:17:28 - 00:17:34) Teilen

Es hat ja im Positiven geendet. Also das Projekt existiert noch und ist auch noch sehr lebendig und wird weitergeführt.

Andy Grunwald (00:17:34 - 00:17:39) Teilen

Und weil ich für die guten Nachrichten zuständig bin, ich bewege mich ja jetzt gerade außerhalb meiner Komfortzone, denn weil du.

Wolfi Gassler (00:17:39 - 00:17:41) Teilen

Die positiven Nachrichten hast.

Andy Grunwald (00:17:41 - 00:18:02) Teilen

Nee, nee, weil die erste Story über JavaScript ging und die zweite geht jetzt über TypeScript. Also das ist ja schon auch außerhalb meiner Komfortzone. Wie gesagt, die zweite Story geht über TypeScript. Und zwar geht es zurück auf ein Problem aus dem Jahre 2000. Vierzehnte. Für alle Neulinge oder für alle Leute, die noch nicht so lange dabei sind, ja, TypeScript ist älter als 10 Jahre.

Wolfi Gassler (00:18:02 - 00:18:08) Teilen

Jetzt schließt nicht von dir auf andere, nur weil du es vor einem halben Jahr mal kennengelernt hast, heißt es ja nicht, dass das alle glauben.

Andy Grunwald (00:18:08 - 00:19:30) Teilen

Ich nutze es ja selbst immer noch nicht. Aber 2014 bzw. Auch noch im APR. 2016 sagte die Typescript Spezifikation folgendes, dass wenn du eine Klasse hast, die von einer anderen Klasse erbt, dann muss im Konstruktor der Kindsklasse sofort die Superfunktion aufgerufen werden. Also dass der Konstruktor der Mutterklasse, von der geerbt wird, sofort ausgeführt wird, und zwar als erster Call Ÿousand als allererster Call, aber nur in Anführungszeichen, wenn es eine Kindsklasse ist, haben wir geklärt, weil sonst gibt es ja kein super Call. Und wenn Parameter im Konstruktor deklariert werden oder wenn die enthaltene Klasse Instanzvariablen mit initialisiert, du konntest also nicht Argumente im Konstruktor in der Kindsklasse entgegennehmen, die erst transformieren und dann erst an die super Methode übergeben. Da hat der Compiler gemeckert. Das eigentliche Problem war, weswegen diese Spezifikation so geschrieben war, ist, die Variable this, also wenn man sich auf Instanzvariablen innerhalb der eigenen Klasse beziehen möchte, war vor dem Super Call noch nicht initialisiert. Du merkst schon, es geht halt ziemlich viel in den Compiler rein. Im Jan. 2019 hat jemand einen Pull Request eröffnet, der genau dies umgeht. Der sagte also, man kann Datentransformationen vor dem Super Call in der Kindsklasse machen und dann erst an den Super Call.

Wolfi Gassler (00:19:30 - 00:19:36) Teilen

Weitergeben, solange man nicht des Punkt irgendeine Variable macht, weil die kommt ja von der Mutterklasse, oder? Wahrscheinlich.

Andy Grunwald (00:19:36 - 00:20:15) Teilen

Genau, solange man Sys nicht vor super nutzt, weil die Initialisierung von Sys selbst wurde nicht verschoben. Sys ist erst nach dem super Call in der Kindsklasse initialisiert. Aber ich meine, das ist ein klassischer Fall. Deine Kindsklasse hat im Konstruktor irgendwelche Argumente, du musst die umformatieren, weiß ich nicht, die Mutterklasse empfängt nur XML und du kriegst Jason rein oder sowas, dass du die dann entsprechend umformatierst und dann erst an die Superklasse weitergibst. Also das ist ja ein gang und gäbe, ich sag mal in der VRB. Zugegeben, der Pull Request war jetzt nicht gerade klein, der hat 5500 Zeilen hinzugefügt, schraubt ein bisschen am Compiler rum und es ist halt ein sehr komplexer Pull request. Aber ein Großteil der Änderungen sind, bevor.

Wolfi Gassler (00:20:15 - 00:20:21) Teilen

Du da alle Details verschweigst, es wurde auch 317 Zeilen wurden gelöscht und verkleinert.

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

Ja gut, das ist so wie die Landau Notation Zweitausendein. Diese Kleinigkeiten werden einfach weboptimiert, weil ganz im Ernst, ob 317 Zeilen gelöscht werden, interessiert bei 5500 hinzugefügten Zeilen eigentlich gar keinen. Denn wir wissen alle, bei dieser Größe sagt jeder eh, looks good for Me. Zugegeben, sehr komplexer Pull Request, aber der Großteil der Änderungen sind ein Unit bzw. Integrationstests. Jetzt fragt man sich natürlich, gut, Anfang 2019 wird dieser Pull request eröffnet, großer Change Ÿousand, hat der überhaupt eine Chance reinzugehen? Initial würde ich sagen, relativ schwierig, wenn du kein Backing von Microsoft hast oder von TypeScript Maintainern. Zugegeben, 160 Kommentare später. Und drei Jahre später wird die ganze Sache dann gemerged, nämlich am 14. Jan. 22. Während der Zeit, während diesen drei Jahren hat der Maintainer eine unglaubliche Ausdauer bewiesen. Er hat immer wieder für PR Reviews gepusht, auf Änderungswünsche reagiert, Konflikte mit dem Brain Branch gelöst und so weiter. Und das sieht man dadurch, dass die original Pull Request Nachricht immer editiert wurde, Resolve Conflicts und so weiter. Nach zwei Jahren hat er mal gesagt, ja, wir sind glaube ich, fairly close to merging. Und dann war es soweit. Der Pull Request wurde am Elfter Jan. 2019 eröffnet. Am dreizehnter Jan. 2022, also Ÿousand, zwei Tage und drei Jahre später, kam der Maintainer rum und hat einen Kuchen für den Pull Request gebaut bzw. Gebacken. Ich würde eher sagen, eine Torte mit dem Typescript Logo und mit der Pull Request Number drin, so nach dem Motto Ready for merch. Und zwei Tage später wurde dann der ganze Pull request gemerged und die Spezifikation angepasst.

Wolfi Gassler (00:22:03 - 00:22:17) Teilen

Was mich ja interessieren würde, ist, wenn du drei Jahre daran wechselst, wie viele Stunden und Zeit investierst du nur in Rebase und Auflösen von Konflikten? Vor allem bei 5000 Zeilen Code, da hast du ja immer Konflikte wahrscheinlich.

Andy Grunwald (00:22:17 - 00:23:02) Teilen

Wenn du dir den Pull request mal ganz genau ansiehst, dann sind am Compiler recht wenig Änderungen und die meisten Änderungen sind wirklich neue Tests. Deswegen würde ich sagen, die Rebase Thematiken, ich glaube, die hält sich nur in Grenzen, aber es ist immer noch drei Jahre. Meine Frage ist eher, wie viel nervt dich dieses kleine Ding, dass du drei Jahre investierst oder immer mal wieder über drei Jahre, um das wirklich zu fixen? Deswegen, Ausdauer zahlt sich aus. Manchmal brauchen gute Dinge einfach länger. Und mein Key Learning ein Kuchen bzw. Eine Torte führt zu einem PR Merch. Also vielleicht fange ich doch an, mehr zu backen. Den PR verlinken wir euch natürlich auch in den Show Notes. Da könnt ihr mal diese leckere Torte, die ich auch echt gerne mal probieren würde, weil die sieht wirklich gut aus. Aber ich finde das schön. Ich habe noch nie einen Open Source Maintainer gesehen, der für seinen eigenen Pull Request eine drei Jahrestorte gebacken hat.

Wolfi Gassler (00:23:02 - 00:23:12) Teilen

Vor allem, ich backe ja wirklich gerne, aber wenn ich mal diese Torte anschaue, das ist wirklich große Klasse. Das ist eins, zwei, drei, vier, fünf, sechs, sieben, acht. Acht Schichten, Hut ab.

Andy Grunwald (00:23:12 - 00:23:20) Teilen

Ja, und verschiedene Farbspektren und auch dieses Blau von Typescript kommt dabei. Also das Ding ist wirklich ein Traum. Aber das sieht mir so aus mit dem Karton darunter, als hätte die bestellt, oder?

Wolfi Gassler (00:23:21 - 00:23:25) Teilen

Ja, hätte jetzt auch gesagt, ist keine selbstgebackene Tote, außer sehr gut.

Andy Grunwald (00:23:25 - 00:23:42) Teilen

Aber auch das zeichnet das Leben Torten bestellen für Pul Request. Und weil ich im Intro schon eine Achterbahn der Gefühle eingeleitet habe, kommen wir jetzt wieder von einem hoch, leider vielleicht zu einem Tief. Und das Tief wird mal wieder präsentiert vom grimmigen Wolfgang.

Wolfi Gassler (00:23:42 - 00:24:19) Teilen

Ja, irgendwie habe ich die schlechten Geschichten abgestaubt, eindeutig. Aber eigentlich ist es vielleicht auch eine schöne Geschichte, würde ich fast sagen. Es ist eine traurige Geschichte, aber auch eine schöne Geschichte. Und zwar geht es um eine sehr kürzliche Situation, die aufgetreten ist bei den Proxmox Community Scripts. Also das sind so helper Scripts, damit man in der Virtualisierungsumgebung Proxmox by the way ist wie eine Firma, muss ich immer gerne dazu sagen natürlich, dass man eben gewisse Software und einen Stack leichter hochfahren kann. Ist das eigentlich so ähnlich wie Helm Charts? Andy? Ich bin ja nicht so im kubernetes Game drin.

Andy Grunwald (00:24:19 - 00:24:53) Teilen

Ja und nein. Wenn du vielleicht 2000 Schritte zurückgehst, dann könnte man mit einem zugekniffenen Auge die Proxmox Community Scripts mit predefined Helm Charts vergleichen. Aber im Endeffekt ist es dafür da, Open Source Lösungen wie z.B. grafana, Prometheus, Home Assistant oder Paperless NGX in LXC Container oder Virtual Maschinen zu installieren und auch zu updaten und ich sag mal Standardinstallationen von diesen Open Source Tools zu betreiben. Und das geht halt wirklich binnen Minuten. Also wer ein Proxmox hat und so ein Skript nutzt und dann mit Heimautomatisierung spielen möchte, der zweitausendein baut dann ein Home Assistant innerhalb von 2 Minuten auf.

Wolfi Gassler (00:24:53 - 00:26:51) Teilen

Und gestartet wurde dieses ganze Projekt vom Usernamen ttxter oder ttaxter, keine Ahnung, ob es da eine offizielle Aussprache gibt. Und was ich so mitbekommen habe, auch jetzt so im Nachgang, weiß zumindest niemand offiziell, wer das eigentlich war und ist und wie er wirklich geheißen hat. Und man merkt schon, ich habe gesagt, wie er geheißen hat. Er hat nämlich relativ kürzlich im Okt. 2024 in einem Issue verkündet, dass er in der Klinik ist und vermutlich nur mehr einen Monat zu leben hat, weil er Blinddarmkrebs hat. Und er möchte jetzt sein Projekt, was auch sehr weit verbreitet ist, auf neue Beine stellen. Und er hat dann wirklich in einem sehr kurzen Absatz, aber meiner Meinung nach auch sehr gelungenen, geschrieben, dass man jetzt möglichst schnell wichtige Entscheidungen treffen muss, damit man vorwärts kommt. Und er will da zweitausendein möglichst die Community einbinden und gemeinsam eine Entscheidung finden, damit das Projekt gut weiterleben kann. Es waren natürlich ganz viele Messages, die sich bedankt haben bei ihnen für seine Arbeit und so weiter, aber man hat dann auch wirklich sehr schnell in einem anderen Issue genau diese Sachen geklärt. Zieht man das Projekt um, eben auch gemeinsam mit ihm, forgt man das Ganze, wird es übernommen? Wie schaut es aus? Hat sich dann recht schnell herauskristallisiert. Man macht eine neue Organisation auf GitHub, damit man auch Unterprojekte anlegen kann, macht eine neue Webseite. Es haben sich sehr schnell Leute auch gefunden, die da mithelfen und man hatte da wirklich innerhalb kürzester Zeit, die auch wirklich sehr begrenzt war, eigentlich diese gesamte Übernahme geklärt. Und dann ist es eigentlich sehr schnell gegangen am dreizehnter November, also ich hab gesagt, Anfang Oktober hat er das verkündet und am dreizehnter November hat dann seine Frau, von der weiß man den Vornamen zumindest Angie, hat probiert als nicht technische Person irgendwie auf GitHub einen Post zu machen. Sie hat dazu geschrieben, sie hofft, dass das überhaupt irgendwer lesen kann, weil sie hat keine Ahnung, was sie da eigentlich genau macht und hat dann eben gesagt, dass ihr Mann verstorben ist und hat sich nochmal bei der Community bedankt.

Andy Grunwald (00:26:51 - 00:27:22) Teilen

Die ganze Community, muss man dazu sagen, hat auf diesen Post reagiert. Aktuell sind es 512 Kommentare, wirklich ein paar echt schöne Kommentare, wie z.B. dein Ehemann war mein Start into home Lab und Coding. Das ganze Issue ist mehr oder weniger wie so eine Art Kondolenzbuch. Also schon schon faszinierend und glaube ich wirklich schön zu lesen für Angie, was ihr Mann da eigentlich bewirkt hat. Und ich bin mir nicht sicher, ob ihr auch bewusst war, was ihr Mann da wirklich dann gemacht hat bzw. Welchen Effekt er auf so viele Leute und so viel Leben hatte.

Wolfi Gassler (00:27:22 - 00:28:17) Teilen

Ein Comentainer hatte dann auch noch die Coffee Adresse noch mal gepostet in dem Issue, dass man dort spenden kann und die Frau noch das empfangen wird, das Geld. Und ich habe gerade jetzt mal nachgeschaut, es sind alleine gestern wieder acht oder neun Spenden gewesen. Also das ist noch super aktiv. Es bedanken sich ganz viele Leute, auch mit einer kleinen Kaffeespende, die jetzt eben an die Frau zurückgeht. Und jetzt ist das ganze Projekt in einer neuen Organisation, nennt sich Community Scripts und wird dort wirklich weiter gepflegt. Da wurden auch neue Governance Strukturen geschaffen und Genehmigungsverfahren wieder contributed wird und so. Es ist jetzt wirklich auf sehr breiten Beinen aufgestellt mit mehreren Leuten, zweitausendein. Auch ein Kollege von Andy und mir arbeitet da mittlerweile aktiv daran. Also es ist wirklich eigentlich am Ende eine schöne Geschichte, wie die Community das übernommen hat und sich um dieses Projekt kümmert. Auch wenn natürlich der Ausgangsfall sehr traurig ist.

Andy Grunwald (00:28:18 - 00:28:38) Teilen

Man könnte sogar fast sagen, das Projekt ist lebendiger denn je, wenn man sich einfach mal die Releases anschaut, tägliche Releases, da gehen so viele Changes rein. Also aus Open Source Perspektive geht da schon sehr viel ab, aus menschlicher Perspektive natürlich unglaublich schade, aber auch schön, dass diese Arbeit, ich sag mal, in dieser Form weiterleben kann.

Wolfi Gassler (00:28:38 - 00:29:20) Teilen

Und da sieht man halt den Unterschied, wie Leute reagieren, weil bei Core JS wäre das natürlich auch eine Möglichkeit gewesen, das auf breite Beine aufzustellen, da hätten sich sicher auch Leute gefunden. Also da sieht man halt unterschiedliche Herangehensweisen. Aber das Grundproblem, dass es natürlich, gerade wenn es nur einen Maintainer gibt, dass das alles mit einem hohen Risiko auch verbunden ist. Natürlich, weil es kann jederzeit etwas passieren. Und in dem Fall haben die Maintainer immer noch dafür sorgen können, dass etwas passiert. Immerhin. Aber das ist schon ein großes Problem. Darüber sprechen wir ja oft genug in der Open Source Welt, wenn es nur einen Maintainer gibt oder einen aktiven Maintainer, dass das durchaus ein hohes Risiko ist. Vor allem, wenn man halt auf diese Software wirklich dann viel aufbaut, unter Umständen.

Andy Grunwald (00:29:20 - 00:29:41) Teilen

Weg von den traurigen Sachen, wieder hin zu etwas mehr oder weniger Ÿousand amüsantem. Und ich weiß nicht, was ich mit dieser Sprache habe, aber alle guten Dinge sind drei. Douglas Crockford war JavaScript, dann der Kuchen zu Typescript und jetzt habe ich mir wieder ein JavaScript Projekt ausgesucht. Aber ich muss auch sagen, vielleicht ist es auch einfach die Sprache. Vielleicht gibt es einfach solche guten Pull Requests einfach nicht in Go oder in Java, sondern vielleicht gibt es.

Wolfi Gassler (00:29:41 - 00:29:49) Teilen

Das hast du dir ja nur absichtlich ausgesucht, weil der Douglas Crockford so unfreundlich war zu dir. Und jetzt suchst du dir die ganzen JavaScript Fälle raus, die da irgendwie schief gelaufen sind.

Andy Grunwald (00:29:49 - 00:30:17) Teilen

Ich hatte mit Douglas Crocodile ja gar nichts am Hut, deswegen, vielleicht war das auch mein Glück, dass ich keine JavaScript schreibe. Aber es geht um Unit Tests und es geht um Down under, also um Australien. Im Nov. 2013, also schon ein bisschen was her, wurde bei dem Projekt angularjs, und zwar AngularJS Version eins, ein Issue eröffnet. Die unit Tests schlagen fehl, wenn sie in Australien ausgeführt werden. Was würdest du denken, wenn du solches Issue bekommst, Wolfgang?

Wolfi Gassler (00:30:17 - 00:30:23) Teilen

Ich würde mir denken, nein, sicher nicht. Wieder 99 % der Fehler sitzen vor dem Bildschirm.

Andy Grunwald (00:30:23 - 00:31:53) Teilen

Da waren Stack Trace dabei, das hat natürlich sehr geholfen. Der erste Maintainer, der das genommen hat, hat gesagt Hä, komisch, aber ich kriege denselben Stacktrace. Hat den Stacktrace einfach komplett umgedreht wegen Down Under und hat gesagt Hahaha, gut, war ein kleiner Witz. Aber was war das Problem in dem Stacktrace von dem Unit Test? Und zwar ist das ein Unit Test, der so ein bisschen mit Zeitzonen rumrechnet. Das bedeutet, der eigentliche Fehler war ein Off by one Error. Und jetzt ist die Zeit wichtig. Da wurden Offsets miteinander abgezogen, also subtrahiert, und das Ergebnis war negativ. Man hat also geschrieben new date und dann eine negative Anzahl an Sekunden. Das Issue wurde am neunzehnter Nov. 2013 eröffnet, November, Australien bedeutet, die sind im Sommer, das bedeutet Daylight Saving Time Daylight Summer Time, die Sommerzeit in Australien, läuft von Anfang Oktober bis Anfang April. Außer in Brisbane, weil in Brisbane gibt es seit 1992 keine Zeitverschiebung mehr. Also man ist in Sydney, hat Sommerzeit und in Brisbane hat man die nicht. Die unit Tests wurden hier in Sydney ausgeführt, deswegen hatte man das Problem. Es war aber noch nicht klar, warum. Dann hat sich da jemand reingenerdet und zwar hat festgestellt, das ist gar kein angularjs Problem, das ist ein natives JavaScript Problem. Warum? Daylight Saving in Australien ist 1971 gestartet. Merkst du was, Wolfgang?

Wolfi Gassler (00:31:53 - 00:31:54) Teilen

Ein Jahr nach der Unix Timestamp.

Andy Grunwald (00:31:54 - 00:32:59) Teilen

So sieht es aus. Happy Birthday. Und zwar, also das ist ein Grund, ja. Der zweite Grund ist die damalige ECMAscript Spezifikation. ECMAScript 05.01. Nur mal ganz kurz so zum aktuellen Zeitpunkt. Wir sind bei ECMAScript 2024. 2025 ist gerade in Draft, also schon ein bisschen was her. Die damalige Spezifikation zum Thema Daylight Saving Time Adjustments war zu ungenau. Die damalige Situation hatte zur Folge, dass verschiedene JavaScript Engines Datumsangaben vor 1970 anders gehandhabt haben. Ich rede von Spider Monkey, ich rede von WebKit, ich rede von der V, also eh alle, die hatten drei verschiedene Verhalten. Was hatten die für Verhalten, wenn du dieses New date und dann mit einer negativen Zahl da rein startest? Manche JavaScript engines sind irgendwie im Jahr 2013 ausgekommen, manche haben 1969 gemacht. Also das Verhalten war komplett unterschiedlich pro JavaScript Engine, das muss man sich mal vorstellen.

Wolfi Gassler (00:32:59 - 00:33:01) Teilen

Und das war auch im Standard nicht definiert.

Andy Grunwald (00:33:01 - 00:33:12) Teilen

Nein, es war zu ungenau definiert. Also die Definition hat den engines Freiheiten gelassen, weswegen die Spider Monkey, Webkit und V unterschiedlich verhalten haben. Die aber alle korrekt waren laut Spezifikation. Ja, ja.

Wolfi Gassler (00:33:12 - 00:33:16) Teilen

Also es war kein falsches Verhalten, sondern es war nur nicht sauber definiert im Standard.

Andy Grunwald (00:33:16 - 00:34:11) Teilen

Genau, es war halt frei. Das hatte zur Folge, dass also diese beiden Sachen in Kombination, dass auf einer bestimmten JavaScript Engine in Australien, nämlich von Oktober bis April, diese Unit Tests fehlgeschlagen sind mit einem Off by One Error, weil man vom Offset 10 ausging. Aber es war das Offset 11, nämlich in der Sommerzeit. Außer in Brisbane halt. Das Issue selbst wurde in Angular eins nie gelöst, denn das Repository ist inzwischen archiviert. Also Angular eins gibt es nicht mehr. Jetzt sind wir neun Jahre weiter. Ich habe das mal mit ECMAScript 2024 versucht. Die ganze Thematik ist jetzt eindeutig besser spezifiziert. Und in Node JS, wo du das Problem damals reproduzieren, konntest. Wenn du jetzt mit einer negativen Zahl, also mit einer negativen h new date machst, zweitausendein, dann kommst du bei 1969 aus. Das ist dann jetzt richtig gehandhabt und genauer spezifiziert. Aber ist eine schöne Geschichte, finde ich. Eine schöne Debugging Story.

Wolfi Gassler (00:34:11 - 00:34:15) Teilen

Und was ist jetzt die korrekte Vorgehensweise? Also was sollte rauskommen bei minus eins.

Andy Grunwald (00:34:15 - 00:34:27) Teilen

Bei New Date minus einer Stunde sollte 1969 der ein und dreiigster Dez. 1969 rauskommen. Also die JavaScript engines hatten kein korrektes Handling für Zeiten vor 1970.

Wolfi Gassler (00:34:27 - 00:34:29) Teilen

Aber warum 1969?

Andy Grunwald (00:34:29 - 00:34:30) Teilen

Voll schräg.

Wolfi Gassler (00:34:30 - 00:34:35) Teilen

Ich würde jetzt eher erwarten, dass sie die Akt. Weil New Date ohne Parameter gibt mir die aktuelle Zeit zurück.

Andy Grunwald (00:34:35 - 00:34:36) Teilen

Minus einer Stunde.

Wolfi Gassler (00:34:36 - 00:34:40) Teilen

Ja eben, da würde ich jetzt sagen, die aktuelle Zeit minus 1 Stunde und nicht 1969.

Andy Grunwald (00:34:40 - 00:34:45) Teilen

Nein, das ist. Also es geht immer nur vom aktuellen 01.01.1970 aus.

Wolfi Gassler (00:34:45 - 00:34:46) Teilen

Schreck, schreck.

Andy Grunwald (00:34:46 - 00:34:51) Teilen

Aber wenn du New Date null machst, dann kommt ja auch der 01.01.1970 raus.

Wolfi Gassler (00:34:51 - 00:35:14) Teilen

Okay, JavaScript ist immer wieder eigenartig, aber es wird wahrscheinlich Gründe haben. Falls jemand die Gründe kennt, kommt mal bei uns in der Discord Community vorbei und erklärt uns das bitte. Also es ist nicht sehr intuitiv, würde ich sagen. Also wenn du den ganzen Unix Timestamp Background nicht hast und du machst was mit null, warum 1970? Also finde jetzt als Anwender, also als Programmierer irgendwie nicht so ein benutzerfrei.

Andy Grunwald (00:35:15 - 00:35:18) Teilen

Sorry, aber du kommst jetzt gerade total überraschend rüber. Wir reden von JavaScript.

Wolfi Gassler (00:35:18 - 00:35:22) Teilen

Ja, ich bin ja großer JavaScript Fan und trotzdem sage ich das.

Andy Grunwald (00:35:22 - 00:35:41) Teilen

Und du sagst, das ist nicht intuitiv. Nennen wir mal das Type Handling von JavaScript ist intuitiv. Da ist nichts intuitiv. Ja, das ist wie aus. Das ist auswendig lernen, wie damals in der Schule. Irgendwie ganz komische Regeln oder wie wenn du als Ausländer Deutsch lernst. Ob das jetzt der, die, das Nutella ist, weiß bis heute keiner.

Wolfi Gassler (00:35:41 - 00:35:44) Teilen

Also umfahren und umfahren.

Andy Grunwald (00:35:44 - 00:35:45) Teilen

Ja, ganz genau.

Wolfi Gassler (00:35:45 - 00:35:48) Teilen

Dich umfahren oder die Stange umfahren. Ja.

Andy Grunwald (00:35:48 - 00:36:28) Teilen

Was aber an dieser ganzen Bug Thematik recht interessant ist, als ich es gelesen habe, kam mir eine neue Frage auf. Wie viele bugs kommen denn auf, wenn die EU bzw. Die Länder in der EU sich mal auf eine Zeitzone einigen? Denn es wurde ja schon entschieden, dass wir entweder nur Sommerzeit oder nur Winterzeit haben. Nur wir wissen ja noch nicht, welche Zeit es wird. Ich bin mir nicht sicher, ob wir das jemals erfahren werden, aber es ist eine andere Thematik. Das bedeutet ja dann eigentlich, dass wir eine Zeit haben, ähnlich wie in Australien. 1971 wurde Daylight Saving Times eingeführt, außer in Brisbane. Und jetzt kommt die EU mit 2040 und schafft die Daylight Sailing Time ab. Also wie viele bugs kommen dann da und wie viele Engines haben denn damit Probleme? Zweitausendein. Bis wann ist der Code denn dann angepasst? Das ist ja der Horror.

Wolfi Gassler (00:36:28 - 00:36:37) Teilen

Ja, Zeit wird uns ewig verfolgen, glaube ich. Also ein so einfaches Konstrukt eigentlich, das in der Programmierwelt einfach so komplex ist.

Andy Grunwald (00:36:37 - 00:37:22) Teilen

Ja, ich glaube, das ist auch das Key Learning. Zeit und Datumshandling ist einfach hart und es wird einfach nie einfacher. Und die Politik hat da auch ihren Senf zugegeben. Aber wer ein bisschen mehr über Zeit und Datumshandling lernen möchte, der kann mal in die Episode 107 und dreiig reinschalten. Da haben wir über ganz viel über die Schaltsekunde gesprochen und in Episode 144, der kann mal sehen, wie Zeit Synchronisation mittels den Protokollen NTP und PTP funktioniert. Harter Tobak, würde ich mal sagen. Und bei der Recherche zu diesem, zu dieser Debugging Story bin ich auf ein Repository gestoßen, das nennt sich Debugging Stories. Das ist eine awesome List für solche Art von kruden Bugs. Verlinken wir natürlich auch in den Shownotes. Also wer mal einen lustigen Sonntag haben möchte, der kann sich gerne mal ein paar Stories durchlesen. Das ist teilweise echter Mindfuck. Ÿousand.

Wolfi Gassler (00:37:22 - 00:39:16) Teilen

Und kleiner Spoiler, wir werden ja bald eine Episode haben, wo es auch wieder in einem kleinen Teil um Zeit geht und zwar um Zeit auf hoher See, weil auf hoher See am Meer ist die Zeit auch wieder ganz anders geregelt. Also die Zeit ist wirklich ein ständiges Problem. Aber wenn wir schon beim Berechnen sind, man kann ja auch ganz klassisch mathematisch rechnen. Und ihr kennt ja wahrscheinlich alle den Microsoft Calculator. Und jetzt werden sich wahrscheinlich viele fragen, was hat der Microsoft Calculator mit Open Source zu tun? Zweitausendein. Und das Interessante ist, der Microsoft Kalkulator ist Open Source, zumindest ist Open Source geworden mit Lizenz in der Microsoft Organisation. Auf GitHub gibt es den Calculator und man kann sich den Code anschauen. Da gibt es auch Issues, z.B. einen Issue Nr. 61, der ein paar Sachen beschreibt, dass es Probleme mit dem Speichermanagement gibt. Und da gibt es einen super Fix für den Ischio mit der Nr. 61. Und zwar hat er jemanden Fix PR erstellt, der im Titel heißt fix dieses Problem Nr. 61 und auch andere Probleme von dem ganzen Calculator. Und zusätzlich spart er auch noch Maintenance Resourcen ein in Zukunft. Und dann geht es weiter, dann steht der Description of the change, remove all source files, how changes were validated. Also wie wird erkannt, ob der Change korrekt verläuft? Der ganze Code bildet nicht mehr. Also er hat im Prinzip alle Dateien gelöscht, um dieses Memory Problem zu lösen. Was aber dann cool ist, er beschreibt nämlich auch darunter, warum er diesen PR erstellt hat, weil er wollte damit danken, dass Microsoft auch das ganze open source hat und contributed. Und er hat sich gedacht, das ist der beste Weg eigentlich zu den Maintainern irgendwie einen Kanal aufzubauen und wirklich mal danke zu sagen, so dass es möglichst viele Leute sehen. Abschließend hat er auch noch gesagt, als Linux User kann zwar eh nix damit anfangen, aber er findet es trotzdem cool, dass es Open source wird.

Andy Grunwald (00:39:16 - 00:39:26) Teilen

Kurz zum schmunzeln ist es natürlich, hat auch ziemlich viele Downvotes, mehr Downvotes als upvotes und. Aber nun gut, war jemand mit einem schlechten Humor, würde ich mal sagen.

Wolfi Gassler (00:39:26 - 00:39:50) Teilen

Ich finde das sehr erfrischend, solche Sachen. Da wird mal was anderes gemacht und einmal auf Closed setzen ist jetzt auch nicht so schwierig. Und die haben sich vielleicht wirklich gefreut, dass sich jemand mal die Mühe macht, auch sowas zu erstellen. Ein Danke ist ja noch mal schneller geschrieben, aber da einen eigenen PR und so weiter aufzusetzen und eine Geschichte zu schreiben, finde ich eigentlich sehr sympathisch. Die Zeit muss man auch erstmal investieren. Ist ein schönes Danke meiner Meinung nach.

Andy Grunwald (00:39:50 - 00:40:00) Teilen

Ich fasse mal du nennst diesen PR unerwartet. Apropos unerwartet, da habe ich mir selbst die Überleitung hingebogen. Unerwartet ist auch das nächste der Überleitungen.

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

Wie immer.

Andy Grunwald (00:40:01 - 00:40:47) Teilen

Retrospektiv muss man sagen, die ganze Story ist sehr, sehr scheiße eigentlich ausgegangen, würde ich mal fast sagen. Beziehungsweise läuft auch immer noch die Scheiße, aber dazu jetzt gleich mehr. Und zwar geht es um PHP. Es geht um Doctrine. Doctrine ist ein Object Relational Mapper, ein URM für PHP. Und dieser ORM ist so aufgebaut, dass es z.B. für eigene Datentypen eigene Pakete gibt. Und es geht um ein Projekt, das nennt sich Doctrine enum Bundle. Das fügt Enam Datentyp Support für den ORM Doctrine hinzu. Nur mal kurz zur Erinnerung, ein Enum ist ein Aufzählungstyp. Also wenn eine Variable eines Datentyps nur bestimmte Werte annehmen kann. Z.B. boolean ist ein Enum, weil es nur true oder false sein kann. Oder du hast einen Datentyp Farbe und der kann nur rot, gelb oder blau sein. Das ist z.B. ein Enum. Und der Pull Request, um den es jetzt hier geht.

Wolfi Gassler (00:40:47 - 00:40:54) Teilen

Mir zieht es gerade alle Datenbanknägel auf, wenn du sagst, boolean ist Enam. Aber okay, sei mal dahingestellt, für Die.

Andy Grunwald (00:40:54 - 00:41:04) Teilen

Erklärung reicht es ja. Boolean ist ein eigener Datentyp, es ist kein Enum. Aber du könntest dir einen eigenen Boolean Enum basteln, indem du sagen könntest, okay, ich habe einen Enam, der nur tun sein kann.

Wolfi Gassler (00:41:04 - 00:41:11) Teilen

In MySQL ist es ja sogar eigentlich ein tiny int Boolean wert, nicht mal einen echten Boolean. Aber bitte will nicht abdriften.

Andy Grunwald (00:41:11 - 00:45:17) Teilen

Genau, genau. Du sagst jetzt gerade schon, Boolean gibt es gar nicht in MySQL. Und in sqlite gibt es z.B. keine Enums für ein Object Relational Mapper. Aber eine ganz interessante Thematik, denn eine OAM soll natürlich eine Datenbankabtraktion sein, damit man sich unten mit den Details der Datenbank gar nicht auseinandersetzen muss. Also in Postgres gibt es z.B. in Enum, in MySQL gibt es Inam, aber nicht in SQLite. Und dieser Pull Request führt das halt ein. Und zwar gibt es nämlich ein Workaround, wenn es keinen in Namen gibt. Und zwar kannst du sagen, wenn einer gewissen Zeichenkette in einer anderen Liste ist. Das bedeutet, du nimmst das Textfeld, du speicherst den Inam einfach in einem Textfeld und checkst dann diesen Wert gegen eine andere Liste. Ist ja mehr oder weniger ein Enam in performant. Aber hey, wir reden von einem ORM. Der ganze Podcast wurde im Jan. 2014 erstellt und 1 Stunde nachdem der PR erstellt wurde, kam eine Antwort vom Maintainer sehr schnell. Hätte ich mit der folgenden Antwort jetzt nicht erwartet, dass sie so schnell kommt. Und er sagt, pass auf, ich schaue mir den Pull request an, danke dafür, aber ich schaue mir den später an. Sehr, sehr später. Warum? Ich komme aus der Ukraine und wir haben gerade eine Revolution. Sorry, buff, Ende. Wenn man sowas liest, denkt man sich, uff, okay, wir erinnern uns, vor 10 Jahren war die Maidan Revolution in der Ukraine. Was ist da eigentlich passiert? Der Präsident hat das Assoziierungsabkommen mit der EU nicht unterschrieben, aufgrund von russischem Druck. Ich musste erstmal nachgucken, was das Assoziierungsabkommen denn eigentlich ist. Vor 10 Jahren war mir das anscheinend noch nicht so bewusst. Und zwar, das Assoziierungsabkommen ist die Förderung der schrittweisen Annäherung zwischen den EU Mitgliedsstaaten und der Ukraine auf der Grundlage gemeinsamer Werte. Schaffung eines geeigneten Rahmens für einen intensiveren politischen Dialog in allen Bereichen von beidseitigem Interesse. Russland hatte kein Interesse, dieses Abkommen zu unterzeichnen und deswegen Druck auf den Präsidenten von der Ukraine ausgeübt. Daraufhin sind Demonstrationen losgegangen. Bei den Demonstrationen hat die Polizei dann Demonstranten verprügelt. Diese brutale Aktion weckte dann den Widerstand der breiten Bevölkerung. Anfang Januar, also wirklich ein paar Tage vor dem Pull request, Ÿousand, hat dann das ukrainische Parlament das Versammlungs und Meinungsfreiheitsgesetz eingeschränkt. Und ab da ging die ukrainische Revolution los. Das bedeutet, der Präsident hat das Land verlassen, ist geflohen, Russland hat die Halbinsel Krim annektiert, Wladimir Putin hat Ukraine den Krieg erklärt. Und ja, weswegen sage ich, die Scheiße läuft immer noch. Eigentlich sagt man, dass die Maidan Revolution der Triggerpunkt für den aktuellen Ukraine Russland Konflikt ist. Oder Krieg. Und gut, die Story ist jetzt nicht so super ausgegangen oder beziehungsweise läuft immer noch, hab ich ja gesagt. Was ich aber damit mal zeigen möchte ist, dass das eigene Problem vielleicht nicht immer gerade das wichtigste ist und dass jedes Leben auch anders ist. Und open Source ist bei weitem nicht das wichtigste. Ist natürlich schon beachtlich und ja, vielleicht auch mal muss man da mal schlucken, wenn man solche Kommentare liest. Aus der Open Source Perspective muss man aber sagen, während die Revolution dann ongoing war, wurde der Pull request auch gemerged. Ÿousand und die Kommunikation in diesem Pull Request bezüglich der Revolution ging dann noch bis zum 5. Sep. Weiter, also schon noch knapp ein Jahr. Da ging es dann die ganze Zeit darum, okay, wie ist denn der aktuelle Stand? Weil die Medien Coverage zu der Zeit war etwas wild, würde man sagen. Und da hat man dann Firsthand Information bekommen aus einem Pull Request in GitHub. Es gibt natürlich unzählige andere Stories, die sich auf GitHub Issues und Pull Request irgendwie abgezeichnet haben, aber Ÿousand, wir hoffen, dass die paar Storys euch mal so einen recht transparenten Einblick und eine Achterbahn der Gefühle verschaffen haben. Open Source ist wild. Open Source ist breit gefächert von sehr schönen Stories, wie z.B. dass Torten gebacken werden oder dass Key Maintainer oder Sprachautoren wie z.B. douglas Crockford sich einfach in Pulverquest zu Wort melden. Aber leider auch ein paar Tragödien, wie z.b. wenn jemand an Krebs stirbt, zweitausendein jemand ins Gefängnis muss oder.

Wolfi Gassler (00:45:17 - 00:45:19) Teilen

Ja, oder ein ganzer Krieg ausbricht, ja.

Andy Grunwald (00:45:20 - 00:45:49) Teilen

Für sein Land kämpft und dann jetzt leider fast 10 Jahre später oder acht Jahre später dann der Krieg immer noch läuft. Behaltet das alles mal im Hinterkopf, wenn ihr nächstes Mal auf Feedback von einem wartet. Denn ihr kennt das Leben nicht, was auf der anderen Seite abgeht. Und deswegen sagen wir natürlich auch, Kommunikation ist key. Respektvolle Kommunikation ist key und notwendig für die ganze Thematik. Denn zweitausendein, wie man auch an der Proxmox Skript Geschichte sieht, ist auch Community Key für den Erfolg.

Wolfi Gassler (00:45:49 - 00:45:51) Teilen

Das hast du sehr schön zusammengefasst.

Andy Grunwald (00:45:51 - 00:46:03) Teilen

Das war's von uns. Wir wünschen euch ein schönes Weihnachtsfest. Kommt gut ins neue Jahr und habt ein paar ruhige Tage. Und vielleicht findet ihr auch mal wieder Zeit, ein bisschen open Source zu hacken. Tschüss, viel Spaß. Bye bye.

Wolfi Gassler (00:46:03 - 00:46:03) Teilen

Ciao.