News 02/26 –

GitHub Preisänderungen // MongoBleed // State of HTML

08.01.2026

// Podcast
// News 02/26

Shownotes

CN: Suizid // Die programmier.bar ist aus der Winterpause zurück – zumindest Fabi und Jan! Wie immer haben die beiden die wichtigsten Tech-News der letzten Wochen für euch zusammengefasst.

Jan berichtet über die angekündigte Preisänderung bei GitHub und darüber, warum das „neue“ Preismodell absurder wirkt, je länger man sich damit beschäftigt. Das hat am Ende offenbar auch GitHub selbst eingesehen.

Dass MongoDB-Admins und -Entwickler:innen vielleicht keine ruhigen Feiertage hatten, könnte an der MongoBleed-Sicherheitslücke gelegen haben. Fabi hat sich die Schwachstelle genauer angesehen und klärt auf, was eigentlich passiert ist.

Außerdem sprechen die beiden über den State of HTML 2025 Report, der Ende des letztes Jahres erschienen ist, und diskutieren alte Vorurteile und neue Trends in der Community.

Und wir erfahren, warum ausgerechnet Age of Empires II den Durchbruch im AI-Coding-Agent-Game bringen könnte.

---

In dieser Folge sprechen wir auch über Suizid. Wenn auch ihr oder Menschen in eurem Umfeld Hilfe benötigen, dann wendet euch an folgende Stellen:

Telefonseelsorge (0800 111 0 111)
Nummer gegen Kummer (116 111)
Im Notfall: Polizei (110) oder Rettungsdienst (112)

Darüber hinaus gibt es diverse Beratungsstellen für Suizidgefährdete und deren Angehörige.

Download

/transkript/programmierbar/news-02-26-github-preisaenderungen-mongobleed-state-of-html

Fabi: Hallo und herzlich willkommen zu der ersten programmier.baren News im Jahr 2026. Das ist die Kalenderwoche 0 2. Wir haben heut 3 Themen für euch dabei. Einerseits hat GitHub 'n paar gemacht, die nicht allen gefallen. MongoDB hat eine durchaus kritische Sicherheitslücke zu Weihnachten, na ja, zu Weihnachten wurde sie geleakt und wir haben noch den State of HardML 2025. Mein Name ist Fabian Fink und mit mir im Studio ist wie immer
Jan: Day, Jan, Gregor im Getriebe. Moin moin und frohes Neues.
Fabi: Moin moin, frohes Neues. Heute sind wir zu zweit. Der Rest befindet sich noch im Urlaub. Ich weiß gar nicht, wo sie alle alle rum machen, Skifahrenübersee. Wir werden's nächste Woche oder übernächste Woche erfahren. Aber bevor wir erfahren, wann wo unsere anderen Mitglieder dieses Podcasts hier so waren, lass uns doch mal direkt in die Themen einsteigen. Jan, GitHub hat Preisänderungen gemacht. Was was genau haben Sie immer gemacht und was hältst Du so davon?
Jan: Ja, GitHub hat ein, ich sag mal, verfrühtes Weihnachtsgeschenk an sich selbst machen wollen und an der Preisschraube gedreht. Und bevor wir darüber sprechen, wie erfolgreich das war und wie das angekommen ist, lass uns einfach kurz darüber sprechen, was Sie so vorgestellt haben. Es gab einen Blogpost Mitte Dezember, wo Sie sagten haben so, ja, also wir ändern hier was am Pricing, aber es wird für die allermeisten Leute natürlich erst mal günstiger, weil so fangen ja diese ganzen Announcements immer an. Indem gesagt haben, na ja, wir werden dafür sorgen, dass unsere Runner, also es geht hauptsächlich die die Runner und warum? Kommen wir auch gleich noch mal zu. Im Schnitt 40 Prozent günstiger werden so über alle Größen und Tears quasi hinweg. Und das ist ja erst mal sehr erfreulich. Und sie haben dann gesagt so, na ja, für 96 Prozent der Customer wird das irgendwie alles ganz gut laufen. 4 Prozent sind aber vielleicht von Änderungen betroffen, wo's auch nach oben gehen kann. Und da waren sind dann die Leute schon hellhörig geworden, weil es ging eben nicht nur diese Price Reduction von den normalen Rundern, sondern es ging auch darum, dass wenn ihr GitHub fremde Runners für eure Action, also eures CICD Sachen nutzt, dass GitHub dafür jetzt einen Aufschlag von 0.02 Cent pro Minute im Prinzip einsammeln möchte. Das heißt, wenn ihr nicht die, also je nachdem, wie viel ihr da an GitHub zahlt, paar Cent pro Minute für große kleine Runner, Wenn ihr das nicht nutzen wollt, weil ihr 'n günstigen externen dritten Anbieter gefunden habt und GitHub an der Stelle bisher leer ausgegangen ist, haben die jetzt gesagt, nein, nein, dafür, dass diese Runner bei uns in die Plattformen integriert werden, da wollen wir jetzt zukünftig auch Geld für haben und haben da eben diese 0.002 Dollar 0 0 pro Minute, also 0.2 Cent pro Minute an Preis eingeführt oder angekündigt und gesagt, das startet dann ab dem ersten März. Mhm. So. Da ging dann natürlich die die Diskussion los und ich glaub auch bei uns im im News Channel hier im internen Slack war das durchaus heiß debattiert, kann man vielleicht sagen. Es gab zwar auch Leute, die gesagt haben, na ja, also ehrlicherweise fallen da ja auch für GitHub Kosten an, ja? Sie müssen irgendwie an externe Infrastruktur sich connecten, sie müssen Logs persistieren, sie stellen da Tooling für zur Verfügung und das muss ja am Ende auch irgendwie alles bezahlt werden und so. Und das ist sicherlich 'n Grund, den man nachvollziehen kann, ja. Aber da gibt's, glaub ich, 2 Punkte, die das son bisschen relativieren für mich und deshalb mein Gesamteindruck war, je länger ich mich damit beschäftigt hab, desto absurder ist es eigentlich geworden, ne. Mhm. Weil diese 0.2 Cent pro Minute entsprechen 1 zu 1 dem günstigsten Runner Tier bei GitHub. Also Du kannst für 0.2 Cent die Minute den kleinsten Runner bei GitHub kaufen oder dich von GitHub freikaufen, irgendwo anders deinen Runner benutzen zu können. Und das ist ja schon son bisschen, na ja, schwierig in der Kommunikation und im Verhältnis, ja, wenn sie halt sagen, na ja, für das Geld, das brauchen wir, unsere Kosten für Logs und Infrastruktur und bla bla bla abzudecken. Wenn Du bei Github aber für dasselbe Geld Logs, Infrastruktur und Comput Power für die Zeit kaufen kannst, ja? Sicherlich nicht viel, da geht's die kleinste Instanz, aber trotzdem. So. Zum anderen haben Sie, nachdem das mit diesem ganzen Pricing dann in der Community, ich sag mal, etwas sauer aufgestoßen ist, noch son paar FAQs dazu veröffentlicht und da stand so, hey, war so 1 dieser FAQ Punkte. Also wieso soll ich dafür bezahlen, fremde Hardware nutzen zu dürfen oder meine eigene Hardware sogar, ja? Mhm. Und da war dann die Erklärung von GitHub original so drunter, wo sie gesagt hat, na ja, diese diese Runnergebühr oder das, was wir mit den mit den Action Runners verdienen, das sorgt dafür, dass wir GitHub weiterentwickeln können und finanziert halt diese Plattform. Wo ich mir denk so, das klingt irgendwie wirtschaftlich fragwürdig, weil die Weiterentwicklung der Plattform und den Betrieb der Plattform, den solltet ihr ja eigentlich über meine Membership Fee und dem Betrieb der Plattform, den solltet ihr ja eigentlich über meine Membership Fee finanzieren können. Mhm. Ja? Und nicht dafür, dass irgendjemand anderes, was usagegetriebenes irgendwie noch abrechnet, parallel. Und schwierig so. Ja, also wenn Sie mehr Geld brauchen, ist das sicherlich 'n fairer Punkt und jeder muss wirtschaften, aber da müssen Sie vielleicht an Ihrem allgemeinen Membership Pricing irgendwie arbeiten und nicht versuchen, Leuten Geld aus der Tasche zu ziehen dafür, dass sie ihre eigene Hardware anschmeißen. Ja, schwierig. Sie haben dann, wie gesagt, diese Änderung erst mal pausiert, nicht zurückgenommen, sondern sie haben jetzt gesagt, na, wir setzen dieses Pricing Modell jetzt erst mal aus und denken dann noch mal drüber nach, die Preisänderungen für die eigenen Runner, also diese initial angekündigten 40 Prozent Reduction on Average, die werden trotzdem kommen oder sind jetzt quasi schon gekommen Anfang des Jahres. Und dieses andere Pricing Modell, da schauen Sie jetzt noch mal drüber. Sie haben gleichzeitig eine Diskussion, eine Community Diskussion aufgemacht, wo man son bisschen Feedback dalassen kann und seine eigenen Gedanken dazu gerne loswerden kann. Ich hab mir das mal durchgelesen. Ich muss sagen, es ist in Anbetracht der Emotionalität, mit der diese Diskussion sonst auf Social Media und auf Twitter und wo überall geführt wurde, ist dieses diese Community Diskussion relativ sachlich. So, ja? Und da sind auch 'n paar echt interessante Vorschläge dabei, ja, wo Leute gesagt haben, na gut, wenn ihr Infrastrukturkosten habt oder Anbindungskosten für diese ganzen Third Party Runner, dann macht das doch irgendwie vielleicht als 'n optionales Add on, ja? Ihr wollt irgendwie, wenn ich jetzt 'n Dashboard haben will, meine Third Party Runner zu verwalten, dann zahl ich halt monatlich 5 Dollar pauschal drauf oder 2 Dollar pauschal drauf oder so was, das zu finanzieren. Andere Leute haben bemängelt, dass dieses minutengetriebene Pricing vielleicht einfach nicht eine sinnvolle Größe ist. Man sollte es vielleicht eher an den tatsächlichen Kosten, also wie viel Netzwerklast geht da hin und her, wie viel Logstoreage brauchst Du, wie viel keine Ahnung was, ja? Und nicht einfach nur an an stupider Zeit. Andere haben das auch noch mal genommen, zu bemängeln, dass minutengenaue Abrechnung bei GitHub und Runners vielleicht schon outdated ist, weil sekundengenau vielleicht fairer wäre. Viele Actions laufen gar nicht so lange. Es ist kein Incentive, irgendwie effizient zu arbeiten, wenn Du jede angebrochene Minute bezahlen musst so ungefähr. Also da sind durchaus 'n paar coole Sachen drin, durchaus auch 'n paar berechtigte Einwände da drin. Und jetzt müssen wir mal schauen, wie sich das so ändert, ja. Aber die wichtigste Nachricht ist vielleicht, da wird was kommen, aber erst mal nicht jetzt und wie genau, schauen wir mal. Der erste Griff war wahrscheinlich daneben.
Fabi: Ist es denn so, dass man auch ab der ersten Minute zahlt? Da gibt's da aber auch irgendwie sone Art Freeet hier, weil wenn ich mir jetzt vorstelle, wahrscheinlich geh ich zu irgend 'nem externen GitHub oder 'n Actionshoster oder irgendwie Infrastrukturhoster, dann haben wir meistens auch irgendwelche Free Tears irgendwie am Anfang für die ersten Minuten und so. Das heißt, ich zahl für die vielleicht nichts, muss aber dann an GitHub was abdrücken dafür, dass ich die den Free Tier von irgend 'nem Service nutze. Ich frag mich so, ist damit auch der Free Tier von manchen externen Service son bisschen ad absurdum geführt, weil's den effektiv gar nicht gibt, weil ich dann bei GitHub bezahlen muss, wenn ich 'n Free Tier von 'nem externen Service benutze. Haben Sie dazu irgendwas geglaubt?
Jan: Ja, also es hätte es hätte einen Free Tier gegeben. Das war schon angekündigt, auch in diesen FAQs war so, ja, ja, das wird Teil von deinem Free Useage Quote bla bla bla sein, aber Ja. Mehr Details waren da noch nicht drin. Ich kann mir vorstellen, dass die da halt auch was machen, ne, und zu sagen, na ja, die ersten, weiß nicht, 1100, wie auch immer, Minuten, da bockt uns das noch nicht, aber wenn Du halt wirklich massiv Last irgendwie bei uns aus der Plattform rausnimmst, dann wollen wir halt trotzdem da irgendwie Wert abschöpfen. Und was wir auch gesagt haben, ist, dass es für Open Source Repositories weiterhin auch kostenlos sein wird, so wie die Runner dafür auch bisher kostenlos waren. Aber ja. Schau, also wie gesagt, jetzt ist ja alles wieder auf der Tabelle und schauen wir mal, aber ja.
Fabi: Ja, Cress Changes, der letzten großen Minister diskutiert haben bei Unity, ist auch nicht so gut gelaufen.
Jan: Ja, ich musste tatsächlich auch genau an diese Unity Diskussion denken, die ja auch gesagt haben, so, hey, wir wollen irgendwie mehr Geld und sich son absolutes Pressing Modell überlegt haben und dann das auch nicht so ganz durchsetzen konnten.
Fabi: Na ja, sie haben sie immerhin probiert, haben sie nur wieder zurückgerollt dann.
Jan: Ja, also Unity war so gesehen ein Müh konsequenter, weil sie es überhaupt erst mal ausgerollt hatten. Ja. Und nicht 2 Monate vorher schon wieder zurückgenommen haben.
Fabi: Hast Du in dem Zuge irgendwas zu zahlen eigentlich irgendwie gesehen, wie viel überhaupt von so Runners, also GitHub Actions auf externen Runners läuft so prozentmäßig so? Also wahrscheinlich
Jan: Ach so. Ist diese
Fabi: 4 Prozent teurer? Sind das auch die, die wirklich externe Runner nutzen? Kann man das so als Verhältnis nehmen? Das einfach sagen so, die, die externe Runner haben, für die wird's teurer, deswegen die 4 Prozent versus 96 Prozent oder?
Jan: So hab ich das auf alle Fälle gelesen, aber Sie haben auch gesagt, von diesen 4 Prozent, die betroffen sind, werden nur 15 Prozent wiederum mehr draufzahlen. Also das sind dann 0.5 Prozent oder so der der insgesamt GitHub User, ja.
Fabi: Weil alle anderen in dem, also in dem Free User Quoter sind oder wie wie kann man denn dann nicht mehr draufzahlen?
Jan: Na ja, wenn Du halt einfach nur bei den normalen GitHubbrunnern bist und keine externen nutzt, dann bist Du ja quasi
Fabi: Ich meine, bei den von den, wenn die 4 Prozent, die extern sind, aber davon nur fuffzehn fuffzehn Prozent mehr zahlen, heißt das, die anderen 85 Prozent von diesen 4 Prozent, die sind einfach irgendwie Ja,
Jan: vielleicht irgendwie irgendwie drin gewesen oder so, ne. Das Und Sie sagten auch so, der der Medienimpact auf deine Rechnung wär so 13 Dollar. Jetzt ist natürlich, also, ne, Medien, da heißen, dass im Top Tier das irgendwie sich Tausende Dollars dreht.
Fabi: Und ich hatte hier, ich hab einen Reddit Post in Devops Reddit Subreddit, der hat gesagt, hier, also dreieinhalbtausend pro Monat extra. Also das wahrscheinlich dann kein Medianuser, dreieinhalbtausend mehr, die Sie die Sie zahlen. Also die, der stand da wohl bisschen was drauf. Ich weiß aber nicht, welche
Jan: Und ich mein, also weil man muss ja auch immer sagen, ne, wenn das jetzt nur so 13 Dollar im Schnitt bei so 4 0.5 Prozent der User wären, ja, dann würden sie's ja auch nicht machen, weil das ist ja das ist ja Peanuts für Microsoft am Ende, so, ja? Also es muss ja schon irgendwie 'n großer Hebel sein, weil wahrscheinlich war Ihnen ja schon klar, was für 'n Shitstorm Sie irgendwie damit beschwören würden. Und dann muss er da viel zu holen gewesen sein.
Fabi: Aber war's das frag ich mich. War's das so? Weil ich mein, wenn's viel zu holen gibt und bei scheinbar bei so wenigen User was zu holen gibt, dann muss, also entweder Sie haben's wirklich antizipiert, es gibt den Shitstorm oder Sie dachten, na gut, es sind so wenige User, dass das eigentlich kein Shitstorm auslösen kann, weil's zu wenig Leute betrifft son bisschen. Also kann ich kann mir auch forschen, dass es die andere Diskussion gab.
Jan: Also ich hätte auch gedacht, also ich wär eigentlich davon ausgegangen, sie hätten das irgendwie antizipiert und wahrscheinlich einfach nur unterschätzt, so. Mhm. Also dass dass dieses also zwischen dem initialen Announcement und der Rücknahmelagen 72 Stunden so. Also ich glaub, unterschätzt haben sie es auf jeden Fall.
Fabi: Aber ich meine, wenn Du auch so sagst, ich find's denen ja wirklich eigentlich so ein, die müssen ja der Hebel von ein paar Usern muss ja so groß sein, dass sie 'n paar User so stark melken, dass sie das überhaupt anfangen. Wenn sie sagt, wenn deine nur deine Zahlen son bisschen stimmen, 'n halber Prozent der User betrifft's überhaupt mehr, von denen der Median sind nur 13 Dollar. So, also was welche Beträge unterhalten wir uns da? So viel so viel kann's ja am Ende gar nicht sein. Also vielleicht war's auch mehr einen Politikum und irgendwie so so bisschen, bevor es noch größer wird, sitzen wir mal 'n paar Grenzen und machen's unattraktiver, als dass es jetzt wirklich darum ging, jetzt grade sofort mehr Geld zu verdienen.
Jan: Das kann natürlich sein, ne, dass es nur darum ging, so im Sinne die Blutung zu stoppen. Wir haben ja in den letzten, boah, ich glaub so 12, 20 Monaten schon immer mehr von diesen Anbietern gesehen, die so hochgepoppt sind im Sinne von hier, wir bieten dir besseres Pricing für Action Runner für GitHub an Ja. Mit teilweise echt kompetitivem Pricing, so, ja. Ja. Ich
Fabi: glaub, auf der, ich hab ja noch bei uns immer einen internen Channel durchaus, bei uns wurd sie allein auch mehr Thema, ne. Sie wird auch gemeint, auf der Google Next dieses Jahr war's auch Cloud Run Pools, so die man dann wohl verbinden kann, was dann irgendwie neu announced wurde so. Wir haben jetzt auch grade 'n Part von Unity. Beim neuen Projekt wollen wir auch mal 'n anderen externen Hoster dafür ausprobieren, weil wir Probleme hatten mit den GitHub Action Runner. Und also allein bei uns dieses Jahr gefühlt war das vorher keinerlei Thema und dieses Jahr hab ich also bin ich noch 2 weitere Channels zumindest, wo sich darüber unterhalten wurde, während welche auf ABS laufen und so. Also vielleicht ist das auch einfach 'n Teil der der Rechnung gewesen und gar nicht unbedingt direkt jetzt mehr so viel mehr Geld einzunehmen.
Jan: Ja, ja, ja. Also ich glaub tatsächlich, dieses Feature wurde ja mal irgendwann gebaut, damit Du deine eigenen Runner mitbringen kannst, ja im Sinne von, wenn Du halt echt krass eigene Hardwareanforderungen hast. Du brauchst irgendwie, weiß nicht, dicke GPUs oder krass viel Memory oder so und dann kannst Du deine eigenen Kisten daran connecten. Ich glaube, sie hatten gar nicht so sehr auf dem Schirm, dass da son Businessfeld irgendwie drumherum an Ihnen an Ihnen vorbei entsteht, ja.
Fabi: Ja. Ja, interessant. Mal schauen, was da was da kommt. Wir werden's auf jeden Fall beobachten und euch erzählen, falls da noch mehr entsteht.
Jan: Die Frage ist ja, wer mehr geschwitzt hat zwischen den Jahren. GitHub Kunden oder Mongo de Bezus Admins?
Fabi: Das konnte sich nicht nehmen lassen, die die guten Überleitungen. Perfekt. Genau, ich glaub also, die sus Admins haben wir, glaube ich, einige geschwitzt, vor allem nicht nur zwischen den Jahren, sondern direkt an Weihnachten. Also wir unterhalten über den MongoDB Exploit, weil an Weihnachten wurde der Mongoblied Exploit 2025, wahrscheinlich ist das 1 der letzten, man weiß es gar nicht, 14847. Und ist 'n Memory leak Exploit, der heißt Mongo Bleat, weil er ähnlich funktioniert wie Hartblied, 10 Jahre zuvor. Ich weiß gar nicht, Jan, hat dir Hartblied was gesehen?
Jan: 10 Jahre ist das schon her, Hartblied.
Fabi: Ja, ich glaube, 2, 15 oder so was war's, also eine Open SSL Memory Leak und der hatte durchaus einiges an Impact, weil das Krasse bei diesem Memory Leak bei MongoBeat, wir können auch gleich mal uns über den Hab Lied unterhalten, wie der damals funktioniert hat, ist es so, dass er in einem unauthentifizierten Zustand funktioniert hat. Das heißt, man musste gar nicht wirklich auf 'ner MongoDB Instanz irgendwie authentifiziert sein, hat im Grunde genommen bei jeder MongoDB Instanz funktioniert, die so offen im Internet erreichbar war und eine der betroffenen Versionen hatte. Und die Schwachstelle, die dafür ausgenutzt war wurde, war die Message, die im Grunde genommen immer stattfindet, wenn man mit MongoDB kommuniziert. Dafür wurde genutzt als Decompression Standard und im Grunde genommen einfach, einfach 'n bisschen was über der an Daten über die Leitung zu sparen so, wurde diese Message Decompression genutzt. Und die im Grunde genommen so funktioniert, dass da eine Nachricht mitgeschickt wurde, weil derjenige, die diese Nachricht schickt mit diesem Algorithmus, kann er auch in einem weiteren Feld sagen, wie groß die Nachricht ist so. Also die Nachricht könnte beispielsweise 500 Byte lang sein, aber ich könnte trotzdem in einem sagen, die Nachricht ist eigentlich 8000 Bytes lang. Und der Algorithmus hat dem komplett vertraut und hat gesagt, ja, alles klar, okay, wenn hier drin steht, dass es 8000 Bytes lang, alles klar, dann reservier ich meinen Baffer, der 8000 Bytes groß ist. Und was dann im Grunde genommen passiert ist, dass die Nachricht eigentlich nur 500 Bides groß war, wurde einfach im uninitialisierten Memory einfach da reingeschrieben. Der wurde auch nicht überschrieben und dadurch konnte einfach, was da im Memory steht, einfach mitgelegt werden. Also im Grunde genommen geht's da verschiedenste Daten. Also jetzt dieses dieses Feld hieß, da hat man das im Endeffekt definiert und dann konnte mit verschiedenen Offsets einfach immer probiert werden, verschiedene Speicherbereiche dann in diesen in diesen Memory Bereich zu zu schreiben. Und das Krasse ist halt, dass damit alle möglichen Daten von der MongoDB Instanz damit geleakt werden konnten, also grade auch interne Logs und irgend 'n State so. Und ich mein, wenn man das einmal macht, sozusagen einmal diese Anfrage, dann steht da erst mal eine Nonsens drin. Aber dadurch, dass man mit offsets probiert, halt einfach die verschiedensten Bereiche durchzugehen, kann's am Ende wirklich sein, dass wir hier über Passwörter, allgemeine Logs und so was sprechen. Und das hatte, also erst mal war das Interessante, dass es so ein supereinfacher Exploit war. Also es gibt auch eine in diesem CWI dafür, wo man einfach einen Docker Compose Befehl hochfahren kann, da 'n kleines Python Script ausführt. Also man, auch das wurde schon direkt an Weihnachten mit geleakt. Oh. Sodass man's einfach supereinfach ausprobieren konnte. Im Grunde genommen konntest Du sagen, kannst dieses Python Script nehmen und kannst das auf jequwede MongoDB Instanz einfach loslassen. Und da gab's auf jeden Fall auch 'n paar Fälle. Also Ubisoft ist davon betroffen gewesen, Rainbow Six gab's auf jeden Fall einige, denn Rainbow Six Siege so. Es gab 4 verschiedene Angreifer wohl, die Ubisoft attackiert haben und es gab wohl im, da wurden Ingame Währungen als auch Ingame Items im Wert von 3 Trillionen Dollar, also Moment mal, Billion im Deutschen, Billion Dollar geleakt sozusagen. Es wurden irgendwie, es gab gibt's gab so Videoaufnahmen, wo einfach Leute von Servern gebannt wurden und so. Und Ubisoft hat, glaub ich, samstags dann alle Server runtergenommen und so. Und die haben irgendwie wohl über diese über diesen MongoDB, Mongo Bleed Exploit, auch irgendwie Zugriff bekommen zu irgendwelchen GitHub Repository so. Ich weiß, wie's genau funktioniert, weiß ich nicht. Gibt gibt da 'n paar, also wie sie an diese ganzen Daten kamen. Aber es war wohl, Ubisoft hat's sehr stark getroffen. Also wie gesagt, die Server waren zeitweise komplett down. Und die gute Nachricht erst mal, es gibt für alle betroffenen Version Fixes, also von 5 bis zur Version 8 ist im Endeffekt der letzte letzte Patrodies, da ist der Fix mit drin und das ist auch, wenn man sich denn die Zeile anguckt, so ist es wirklich einfach nur eine Zeile, die einfach nur jetzt kurz umgeschrieben wurde, anstatt auf das Punkt zu schauen, schaut man einfach auf die Länge des der Message. Und damit ist das ganze ganze gefixt. Aber der Impact davon ist halt so krass, weil's halt wie gesagt im unauthentifizierten Zustand einfach, ich muss nur irgendeine Nachricht schicken. Und so hat's ja damals auch beim Hardbeat funktioniert aufm SSL, ne. Da wurd ja der Hardbeat Bug, da wurde der TLS Hardbeat ausgenutzt, der im Grunde genommen die ganze Zeit sone sone Verbindung offen hält und im Endeffekt eigentlich nur son Ping Pong Message ist. Also wenn ich an irgend 'nem Server eine Nachricht schicke, muss er in diesem Hart Beat mit derselben Nachricht wieder antworten. Da war halt genau das gleiche Prinzip so. Es gab halt eine eine, was da mitgeschickt wurde. Und wenn das halt länger war als die eigentliche Nachricht, dann wurde auch da und initialisierter Memory einfach mit reingeschrieben und und geleakt, weshalb damals auch so wirklich so Private Secrets und so weiter einfach geleakt werden konnten. Das war schon grade mit OpenSS ja noch mal sehr viel weitreichender so, weil's halt OpenSSL ein allgemeiner Standard war und nicht eine Datenbanktechnologie wie MongoDB hier, aber es ist eigentlich 1 zu 1 das gleiche Problem an oder der gleich die gleiche Art von Bug, weswegen sie auch beide heißen, Mongo und Hartblied. Auf jeden Fall, ich glaube für die Admins von MongoDB, susmins auf jeden Fall keine schöne Weihnachtszeit, aber ich glaub für MongoDB selbst, also auch wenn der Fix ihrer Seite sehr einfach dann, war, glaub ich, auch
Jan: keine sonderlich schöne Zeit, vor allem weil's auch, gerade auch was MongoDB angeht, auch noch
Fabi: irgendwie 'n paar schöne Zeit, vor allem, weil's auch, grade auch was MongoDB angeht, auch noch irgendwie 'n paar andere Themen gehabt. Wir haben auch bei uns im internen Channel in den News ging auch noch ein weiterer Post rum, dass auch MongoDB grade eine Klage am Hals hat, weil sich eine ehemalige Mitarbeiterin bei ihnen das Leben genommen hat, wär jetzt grade 30 Jahre alt geworden. Und MongoDB hat wohl, sie war son bisschen also für im Endeffekt mentale Probleme in Behandlung auf jeden Fall irgendwie zurückkommt und sie hat irgendwie darum gebeten, noch ein bisschen verlängert, dass sie ihre Behandlung noch beenden kann. So MongoDB hat sie dann am Ende gefeuert und sie hat sich das Leben genommen, weshalb ihre Eltern jetzt eine Klage gegen MongoDB eingereicht haben. Was auf jeden Fall, glaub ich, keine schönen Zeiten für die Firma grade sind. Ja, so, keine schöne Weihnachtszeit dafür auf jeden Fall. Hast Du eine MongoDB Instanz am Laufen?
Jan: Ich hab tatsächlich inzwischen 'n Jahr noch mal geguckt, ich hatte mal 'n paar am Laufen, die sind aber mittlerweile alle alle runtergefahren. Und das waren auch alles nur Docker Container, das war relativ einfach so. Aber ich bin ja eigentlich großer Freund von NoiseQL Datenbanken, umso ärgerlicher das das ganze Spiel.
Fabi: Ja, auf jeden Fall. Ich hab auch zumindest kein Produktivsystem aktuell mit MongoDB, aber eigentlich auch fern gewesen, aber auf jeden Fall 2 Nachrichten, die das nicht attraktiver machen. Aber gut, ich mein, der Mongo beliebt war so auf jeden Fall krass, aber hätte auf jeden Fall passieren können, wenn's Open SSL bei Open SL passiert, dann braucht man sich nicht dafür zu schämen.
Jan: Ja, ich glaub auch, das ist eine Art von Lücke, die die einem nicht peinlich sein muss. So, da gibt's, glaub ich, andere Kategorien von Fehlern, die Du machen kannst in deiner Software, die dann Tür und Tor aufmachen, wo's schlimmer wird so, ja. Aber das ist, ja. Wird wird dieser jetzt noch irgendwie benutzt oder ist er damit quasi obsolet geworden, wenn das jetzt nicht mehr verwendet wird, die Nachrichtenlänge zu bestimmen?
Fabi: Gute Frage, hatte ich mich auch gefragt. Auf jeden Fall an der Stelle wird es nicht mehr benutzt so. Ich kann's dir gar nicht genau genau sagen, vielleicht Also ich hab mir den Code nicht komplett angeschaut so. Also im Endeffekt ist wirklich nur dieses eine Return Statement, was dann was dann die Länge übergibt und damit dann den damit dann eine Waffe initialisiert. Aber ob es überhaupt noch genutzt wird, ich bin jetzt nicht die Zet Lip, den Zet Lip Code komplett durch, sondern hab mir nur den Change angeguckt, da ist es wirklich 'n One Liner.
Jan: Na dann. Ja,
Fabi: dann. Jan, wenn Du, willst Du noch willst Du noch eine weitere Überleitung machen oder wollen wir Nee,
Jan: mach ruhig, mach ruhig. Ich will ja Kommt alles auf HTML 2025. Das war also so gekonnt, Fabi, das hätte ich besser nicht selber machen können.
Fabi: Ja, wirklich, da merkt man da merkt man, dass ich einfach lange aus der Übung bin, aber ich bin einfach Naturtalent, was Übergänge angeht, so. Ja,
Jan: das kam einfach gemerkt schon. Fließend war das. Ja. Wir wollen einmal sprechen über den State of HTML Report 2025. Der ist grad noch Ende letzten Jahres bei mir durch die News Bubble gekommen. Und vielleicht bevor wir im Detail darüber sprechen, was da so rausgefallen ist, kleiner Disclaimer, wie das ja öfter bei diesen Service ist, also Sie sprechen zwar mit Tausenden Entwicklerinnen da draußen, aber wie statistisch repräsentativ das ist, muss man wahrscheinlich mit 'nem kleinen Körnchen Salz nehmen, insbesondere was so einzelne geografische Regionen angehen. Und man muss wahrscheinlich auch dazu sagen, dass diese Service immer son bisschen, wie sagt man, positiv überindiziert sind, weil die Leute, die daran teilnehmen, ja, vielleicht schon son bisschen mehr 'n Faible für Community und Engagement und 'n bisschen News konsumieren und aktuell bleiben und so, ja. Also ich würde mal davon ausgehen, dass der globale Schnitt von Webentwicklerinnen son bisschen konservativer Schrägstrich pessimistischer sich entwickelt als das, was wir jetzt hier gleich sehen.
Fabi: Und die wichtigste Frage noch vorab, ein Körnchen Salz mit einem Körnchen Salzteam, hast Du das einfach 1 zu 1 übersetzt oder gibt's diesen Spruch wirklich im Deutschen?
Jan: Ich hab tatsächlich, ich hab das so mental 1 zu 1 übersetzt. Gibt's das nicht? Find ich's gut?
Fabi: Ich weiß es nicht. Also ich glaub, ich hab mir's auch schon 'n paar Mal im Podcast benutzt, dann hab ich einfach Greens of Salt gesagt. Also man muss es mit einem grain of salt nehmen, weil ich dann dachte, das gibt bestimmt im Deutschen. Aber mit einem kleinen Körnchen Salz nehmen, vielleicht sollten wir's aber jetzt einführen so. Also keine Ahnung, ob's das gibt, aber ich fand's gut.
Jan: Jetzt gibt's das einfach.
Fabi: Ja, nehmt nehmt das Körnchen Salz und hört dem Jan zu.
Jan: Genau. Also Fokus war son bisschen Nutzung von diversen HTML Features im Prinzip abzufragen und gleichzeitig das das Sentiment dazu. Und das war irgendwie ganz interessant. Also wenn man sich den Report mal anguckt, wir verlinken den auch in den Shownotes, sieht man im Prinzip immer, also hier zum Beispiel Lazyloading, ja? Ist irgendwie 'n 'n Feature, ich hab mir insbesondere 'n Performance halt mal angeguckt. Lazyloading, ist irgendwie als Feature wird von 70 Prozent der Leute da draußen irgendwie verwendet. 29 Prozent davon empfinden das durchaus positiv und irgendwie, weiß nicht, ein Prozent hat da 'n bisschen was zu meckern, weil's nicht funktioniert. Und das finde ich irgendwie viel cooler als nur sozusagen, na ja, 70 Prozent der Leute nutzen das irgendwie, weil es der halt son bisschen noch son Indiz dafür gibt, wie wie das halt angenommen wird, ne. Ist das mehr so ein, oh, wir müssen das alle benutzen oder finden wir das auch mega cool, dass das halt irgendwie da ist und haben da Spaß irgendwie dran und können da andere Leute für begeistern? Hab ich das ja
Fabi: letztes Jahr auch schon so gemacht oder ist das jetzt neu in diesem Jahr? Weißt Du das?
Jan: Das war, glaub ich, letztes Jahr auch so. Okay. Aber den Report gibt's ja jetzt, glaub ich, schon 3 oder 4 Jahre oder jetzt im dritten Jahr und ich weiß nicht, ob sie's schon ganz am Anfang gemacht haben. Ein ein Feature, was Neues ist, kommen wir auf alle Fälle gleich am am Ende drauf. Ja, also, irgendwie super weit vorne mit dabei, 70 Prozent, Source Sets, Image Zizers irgendwie auch, ja, megacool. Wobei ich so son bisschen enttäuscht bin, so. 70 Prozent, also da da muss doch mehr gehen irgendwie, hab ich mir gedacht. Also das war das war das Performance Feature, was die meisten Leute hier irgendwie nutzen und feiern. Da dachte ich so, also Leute da draußen, mehr mehr lazy loading, ja? Auf dem ganz anderen Ende des Spektrums war Blocking, Blockdrendering. Also Du kannst ja mittlerweile in deinen Links, die Du so angibst, ja, also 'n 'n Skriptlink, 'n 'n Styling und so weiter, kannst Du mittlerweile auch sagen, das soll meinen Rendervorgang blockieren, ja? Mhm. Und das ist so mit 1 der großen Newcomer des Jahres, das auch sehr positiv angenommen wurde. Und da frag ich mich auch so, muss das wirklich sein? Also sollen wir wirklich wieder zurück zum Blockierenden, also zum zum Rendering blockieren? Wir haben so gute Fortschritte mit asynchron gemacht und so. Da warte ich noch da drauf, dass mir vielleicht jemand da draußen mal erklären kann, warum wir das unbedingt brauchen und warum das cool ist. Wenn ihr da wenn ihr das benutzt, so, wenn ihr bei den 6 Prozent seid, die das benutzen, könnt ihr mir gerne mal erklären, eine E-Mail schreiben an Podcast at Programmier Punkt bar, warum das 'n wichtiges Feature ist und warum ihr nicht mehr ohne Leben könnt. Hab ich nämlich nicht ganz verstanden.
Fabi: Vielleicht gibt's auch noch Auch gut dafür, dass es nur 6 Prozent benutzen.
Jan: Fair, fair. Aber die 6 Prozent, die es benutzen, die feiern's zumindest richtig. Also die wird's irgendwie schon schon kritisch gewesen sein. Es gab auch eine eigenen Umfrageteil zu Web Components. Das fand ich auch beeindruckend schon. 50 Prozent Usage und auch relativ positives Sentiment hätt ich jetzt auch noch nicht gedacht. Mich ist Web Components immer noch so ein sehr neues Ding, was sehr wenige Leute benutzen, weil die allermeisten ja noch irgendwie auf oder View oder keine Ahnung halt andere Komponentensysteme da setzen. Von daher cool. Warum benutzen das nicht mehr als 50 Prozent? Das wurden auch zu jedem Feature so die Pain Points abgefragt. Mhm. Da wurde halt maßgeblich bemängelt, dass es halt sehr komplex im Schreiben ist. Nicht nur im Sinne von logisch komplex, sondern auch einfach viel Boilerplate Code, den Du halt irgendwie dafür schreiben musst, so Komponenten anzulegen und so was. Und tatsächlich die Leute bemängelt haben, dass es schwierig ist, da irgendwie Accessibility korrekt mit umzusetzen, was ja eigentlich sehr positiv ist, dass das den Leuten irgendwie wichtig ist und nicht einfach nur runterfällt und zu sagen, na ja, wir wollen unbedingt diese Componons benutzen und ob die jetzt accessible sind oder nicht, das ist erst mal egal. Von daher kann man das, glaub ich, auch positiv sehen, so. Dann mein ich check grade eben schon, ne, viele Leute benutzen View, React und so weiter. Es gab 'n eigenen Abfragebereich zu HTML Re Use, also was benutzt Du, HTML Blöcke wiederverwenden zu können? Mhm. Da View, React, also alle so diese componentbasierten JS Libraries mit über 70 Prozent Usage ganz weit oben. Und dann auf Platz Nummer 2, ja? Ältere Menschen wie wir werden sich daran erinnern, Server Side Rendering und Server Side Templateing, ja, feiert sein Comeback mit irgendwie 50 Prozent Usage, was vor 'n paar Jahren, glaube ich, auch niemand geglaubt hätte, so, ja. Aber Everything Old is new again, so.
Fabi: Aber ist wahrscheinlich auch auf auf diese Frameworks zurückzuführen so, oder?
Jan: Also Ja, natürlich, ne. React macht ja Server Side Rendering und so, das spielt ja alles irgendwie mit rein bestimmt. Aber trotzdem, dass es als Ansatz halt irgendwie wiederkommt, finde ich finde ich cool. Man kann solche Trends wie View und Dragct halt auch einfach aussetzen. Wenn man vor 10 Jahren gesagt hat, wir bleiben bei Server Side Rendering hat man jetzt wieder recht. So, man hat einfach nur 10 Jahre Web Development verpasst.
Fabi: Oh. Ja, Du kannst auch wieder bei PHP bleiben.
Jan: User, ja? Ich hab's extra nicht gesagt. Clientsite Templatesing immer noch auf Platz 3 und dann auf Platz 4 erst Web Components, ja? Und ich glaub, man sieht halt schon auch, dass viele Leute das zwar benutzen, haben wir eben gesagt, aber dass diese diese Component Frameworks libraries halt einfach massiv festhalten da oben. So, ja? Also ich glaube, die die bringen einfach so viel Usability und Framework magic mit, dass da reine Web Components das noch ganz, ganz lange schwer haben werden, irgendwie gegen anzuarbeiten. Was wird noch abgefragt? System Capabilities, so welche modernen Browser APIs werden irgendwie benutzt? Da war überhaupt nicht viel Nennenswertes dabei. War so meine erste Reaktion, na ja gut, vielleicht ist es einfach die falsche Zielgruppe, ne? Die Leute, die Web Apps machen, sind vielleicht nicht die, die die Web Bluetooth und Web NFC API und hast Du alles nicht gesehen irgendwie nutzen, aber ich hab mir da mal son paar Demografiedaten von der Umfrage angeguckt und ja, natürlich die allermeisten Leute bauen hier irgendwie Web Apps, weit über 80 Prozent der Teilnehmerinnen, aber rund ein Viertel der Leute baut damit auch Desktops App, Desktop Apps oder Mobile Apps, also so wie wir, ne, in sonem hybriden Ansatz und für die sind ja doch viele von diesen Native Browsercapabilities irgendwie wichtig. Ich hab vorhin ein Feature angesprochen, was neu ist dieses Jahr in der Umfrage oder zumindest ich letztes Jahr nicht wahrgenommen hab. Und zwar gibt's son in der Webseite integrierten Query Builder. Also ihr könnt im Prinzip bei jedem bei jedem Chart könnt ihr da in den Query Builder reingehen und sagen, oh, filter mir mal das hier raus oder ich will hier irgendwie noch mal das genauer sehen oder hier noch was dazu nehmen, eine andere Dimension reinnehmen und so weiter. Und da hab ich mal 'n paar lustige Sachen mitgemacht. Einkommen zum Beispiel hab ich mal verglichen. Ich hab gesagt, okay, gib mir alle Einkommensdaten, aber nur aus Deutschland, so, ja. Da liegt das Average bei ungefähr 80000 Euro und relativ normal verteilt in sonem Peak zwischen 50 und 100000 Euro und jeweils 20 Prozent drüber und 20 Prozent drunter, ja? Also gute Normalverteilung. Wir sind damit 'n gutes Stück besser als der der Durchschnitt über über die Welt hinweg und ungefähr im Schnitt 100000 Euro weniger als in den USA. So. Wenn man da mal die Vergleiche ranziehen Die haben andere Kostenstruktur, ne. Ich find das immer schwierig, wenn man jetzt sagt so, boah, als Developer wirst Du in den USA auf jeden Fall reich und kannst viel Geld verdienen. Ja, Du kannst da gut leben, aber Du musst auch mit ganz anderen Kosten rechnen, so. Ich fand's superinteressant zu sehen, hab ich auch 'n bisschen reingepik, dass die Frage, ob Du einen Uniabschluss hast, gar nicht so kritisch ist und insbesondere gar nicht kritisch ist, was für 'n Uniabschluss Du hast. Also der Unterschied zwischen, hast Du einen Uniabschluss in Informatik oder Anything related oder hast Du, so wie ich, irgend 'n Uniabschluss, der halt komplett fachfremd ist, ist so im Schnitt 2000 Dollar Unterschied auf dein Average gerechnet, so. Mhm. Also wichtig ist, dass Du was studiert hast, weil das macht schon was aus, aber was Du studiert hast, ist am Ende gar nicht mehr so wichtig nach 'n paar Jahren, so. Ja, ja. Ja.
Fabi: Ja. Ja, aber ich mein, wenn's in 1 Profession auch wirklich nicht relevant ist so, dann ist es doch am Ende auch bei uns so. Also ich würd auch sagen, das, was wichtig für meinen Job
Jan: ist, hab ich nicht in meinem Studium gelernt. Hunderte Informatikstudentinnen, die uns zuhören, fangen gerade das Heulen an, Fabio, weil Du das gesagt hast.
Fabi: Ja, das ist dann, jetzt haben sie noch Zeit zuzuhören, abzubrechen.
Jan: Bank lieber 'n Job an. Ja. Karriereberatung, weil der Programmierer war.
Fabi: Haben wir haben wir sogar im im AI Recap so könnt ihr auch noch mal, haben wir da auch 'n bisschen Karriereberatung macht, was will den sozusagen grade Studenten oder Leuten, die davorstehen, empfehlen würden, jetzt zu machen. Also falls ihr noch weitere Karriereberatung wollt, dann den AI Recap vom von letzter Woche hören.
Jan: Ja sowieso. Also in dieser Survey haben auch Leute gesagt, so die größte Challenge in meinem Job ist dauerhaft in Formed About new Features irgendwie zu bleiben und was kann ich konsumieren, da irgendwie ganz vorne mit dabei zu sein? Da auch, ja? Podcast, reine Empfehlung. Insbesondere natürlich programmier.bar, aber Podcasts generell können da, glaube ich, viel viel helfen. Ein ein Vergleich, den ich mit dem Query Builder hier noch machen wollte, aber leider zeitlich nicht mehr geschafft hab, war, es gibt son paar Leute in meiner Bubble, mit denen für ich schon sehr lange eine Diskussion darüber, was der Unterschied zwischen einem Software Engineer und einem Software Developer ist, ne. Mhm. Und wer will, kann jetzt mal den HTML Survey Report aufmachen und schauen, wer davon tatsächlich mehr verdient, Engineers oder und wo eigentlich der Unterschied darin liegt. Da kann man nämlich auch 'n paar coole Sachen rausfinden, aber das spoilern wir hier nicht. Könnt ihr selber mal schauen. Ja, also ich
Fabi: finde, ist ja diese, also man muss ja wirklich sagen, was die da gemacht haben mit dem QueryBudern, dass man das irgendwie alles son bisschen filtern kann, sich eigene Graphen bauen kann, ist schon superinteressant, ne. Also mega zu spielen.
Jan: Das ist mega cool.
Fabi: Das ist
Jan: Und also oder auch wie sie's gemacht haben, es ist sehr zugänglich auch so. Also nicht nur, dass es überhaupt geht, sondern auch wie einfach es geht und wie wie selbstverständlich so. Das ist ganz nice. Ja, schaut da mal rein, spielt mal 'n bisschen damit und wenn ihr andere coole Erkenntnisse oder zumindest lustige Korrelationen findet, lasst es uns gerne wissen. Yes.
Fabi: Sehr cool. Jan, damit haben wir die erste News Folge in diesem Jahr bestritten. Mal gucken, also den die 1 26 gab's ja nicht. Mal gucken, ob wenn jeder Kilowatt dieses Jahr sonst eine Folge hinbekommen hat, wenn wir die I irgend einen Ausblick geben, irgendwas auf das Du dich dieses Jahr freust? Ist das erste die erste richtige Folge in diesem Jahr, die wir in diesem Jahr auch wirklich aufnehmen so.
Jan: Okay, pass auf. Wir haben, falls ihr den Jahresrückblick noch nicht gehört habt, so, da hab ich son bisschen, da haben wir ja über AI und Tooling und so was alles gesprochen, ne.
Fabi: Mhm.
Jan: Und ich hab gesagt, 20 26 wird derjenige groß rauskommen, der es schafft, son UI zu bauen über wie kann ich halt mehrere AI Agents gleichzeitig an meinem Projekt arbeiten lassen, woran sehe ich, wer gerade Input braucht, wer gerade woran arbeitet, ne, son bisschen vielleicht wie son Kanban Board für meine Agents oder wie auch immer. Aber wer wer dieses Problem löst, der wird, glaube ich, richtig, richtig Impact haben können dieses Jahr. Das war so mein mein irgendwie für die nächsten 12 Monate, weil wir ja auch über Antimether und so was von Google gesprochen hatten. Anyway, ich hab vor ein paar wenigen Tagen auf, ich glaube, Blues Guy oder so, einen Screenshot gesehen, wie sich jemand ein UI gebaut hat, so mehrere Agents parallel verwalten zu können und so rumbefehlen zu können. Und er hat einfach das Age of Empires UI nachgebaut, so wo jeder Dorfbewohner ein Agent ist und Du siehst so, wie er an 'nem Gebäude arbeitet, was quasi sein sein Task ist und und so was. Und da dachte ich, okay, hatte ich nicht so auf meinem Schirm, ja, aber hey, wenn
Fabi: das die
Jan: Lösung dafür ist, dann bin ich auch voll dabei.
Fabi: Also Game Gaming Fight Development sozusagen, also am Ende so, Du baust zwar dein Job ist eigentlich, 'n Spiel zu spielen, irgendwie Agents zu orchestrieren so und das wird in 'ner Game UI gemacht. Ja, also jeder, der
Jan: weiß ich nicht, Ready Player One oder so mal gelesen hat oder den Film geguckt hat, so, der weiß ja das so. Gamification für Arbeit, das kann schon funktionieren. Ja. Und jetzt mein ich natürlich nicht Ready Player One, sondern ich meinte, Enders game, aber egal.
Fabi: Dann pack das doch mal, das würd ich gern sehen, diese UI. Pack das mal in die Shownotes. Findest Du das noch?
Jan: Bestimmt, ich hab's, glaub ich, auch bei uns im Channel irgendwo geteilt. Ich pack, wir packen das noch dazu. Wenn ihr mehr Age of Empires in eurem Leben braucht, bin ich immer der richtige Ansprechpartner.
Fabi: Sehr gut. Also dann auf mehr Age of Empires im Jahr 2026 und auf noch sehr viele weitere Folgen der programmier.bar. Vielen Dank fürs Zuhören, Jan. Vielen Dank, dass Du da warst. Wir hören uns nächste Woche wieder. Macht's gut.
Jan: Danke. Tschau, bab. Tschau.