Posts

Der Ersatzschlüssel entscheidet, wie gut das Schloss ist

Microsoft stellt die Anmeldung um. Passkeys werden zur Standardmethode, SMS und Sprachanruf verschwinden als MFA-Verfahren, Sicherheitsfragen fallen 2027 aus der Passwort-Selbstbedienung. In den Meldungen dazu steht meist, Passkeys seien sicherer. Das ist richtig und erklärt nichts. Interessant wird es eine Ebene tiefer. Warum ein Passkey nicht phishbar ist Ein SMS-Code ist ein Inhaberpapier. Wer ihn hat, kommt rein. Der Nutzer bekommt die Aufgabe, ihn von einem Kanal in einen anderen zu transportieren, und genau diese Aufgabe ist der Angriffspunkt. Ein Proxy zwischen Nutzer und echter Anmeldeseite fragt den Code ab und reicht ihn weiter. Die Kryptografie bleibt intakt, der Mensch ist das Transportmittel. Beim Passkey läuft der entscheidende Schritt unterhalb des Menschen. Der Dienst schickt eine Challenge, der Authenticator sucht das passende Schlüsselpaar über die gehashte RP-ID der aufrufenden Seite und die Credential-ID. Steht der Nutzer auf einer Lookalike-Domain, ist die RP-ID...

Macht Eis nicht dick? Der Aufwärmkosten-vs-Nutzlast-Irrtum

35 Grad, die Sonne knallt auf Pfaffenhofen, vor der Eisdiele steht die Schlange bis um die Ecke. Der perfekte Tag für einen hartnäckigen Sommer-Mythos. Eis mache nicht dick, weil der Körper mehr Energie aufwenden müsse, um das kalte Eis auf Körpertemperatur zu erwärmen, als das Eis an Kalorien liefere. Klingt elegant. Ist aber falsch, und zwar nicht knapp, sondern um eine Größenordnung. Rechnen wir es durch. Um 100 g Wasser-Eis vom Tiefkühler (rund minus 10 Grad) auf Körpertemperatur (37 Grad) zu bringen, braucht man drei Posten: das Eis von minus 10 auf 0 Grad anwärmen (etwa 2,1 kJ), es schmelzen (Schmelzwärme, der mit Abstand größte Posten, etwa 33 kJ wenn man die gesamte Masse als gefrorenes Wasser annimmt) und das Schmelzwasser von 0 auf 37 Grad erwärmen (etwa 15 kJ). Macht in Summe gut 50 kJ, also etwa 12 kcal. Und das ist schon die großzügige Obergrenze, denn echtes Speiseeis ist kein reiner Eisblock. Zucker, Fett und eingeschlagene Luft senken den Anteil gefrorenen Wassers, die...

16 Gigabyte sind das neue Rechenzentrum

Google hat am 3. Juni Gemma 4 12B veröffentlicht. Ein offenes Modell, Apache-2.0-Lizenz, zwölf Milliarden Parameter, multimodal: Text, Bild, Video und nativer Ton in einem einzigen, encoderfreien Transformer. Die technisch interessanteste Eigenschaft steht aber nicht im Benchmark-Teil der Ankündigung, sondern in den Systemanforderungen: Das Modell läuft komplett lokal auf einem Laptop mit 16 GB Speicher. Kein API-Schlüssel, keine Cloud-Anbindung, kein Datenabfluss. Wer die letzten Jahre KI-Features gebaut oder eingekauft hat, kennt das Standardmuster: Modell beim Anbieter, Daten gehen über die Leitung, zurück kommt die Antwort. Das Muster hat Gründe: Die großen Modelle waren lokal schlicht nicht zu betreiben. Genau diese Prämisse bröckelt. Gemma 4 12B erreicht laut ersten unabhängigen Tests Werte nahe der doppelt so großen Modellklasse und schafft auf einer gewöhnlichen RTX 4060 rund 21 Token pro Sekunde. Das ist keine Demo-Geschwindigkeit, das ist Arbeitsgeschwindigkeit für viele Auf...

EOL ist ein Datum, kein Vorschlag

Am 30. Juni 2026 endet der OSS-Support für Spring Boot 3.5. Ab dem 1. Juli gibt es aus der Community keine Bugfixes und keine Sicherheits-Patches mehr für diese Linie. Wer weiterläuft, läuft auf eigenes Risiko. Und genau hier fängt das Missverständnis an. Eine End-of-Life-Version verändert ihr Verhalten am Stichtag nicht. Sie startet am 1. Juli genauso schnell, antwortet genauso zuverlässig und besteht dieselben Tests wie am Tag davor. Das ist das Tückische daran. Es gibt kein Warnlicht, keinen Performance-Einbruch, keinen Absturz, der zur Migration zwingt. Alles fühlt sich stabil an. Und „stabil“ ist exakt das Wort, mit dem sich der Aufschub rechtfertigen lässt. Was sich ändert, ist unsichtbar. Sicherheitslücken werden nicht weniger, nur weil eine Version aus dem Support fällt, eher im Gegenteil. Neue CVEs werden weiter gefunden, auch in transitiven Abhängigkeiten. Der Unterschied: Für eine gepflegte Linie kommt ein Fix, für eine EOL-Linie nicht. Die Lücke bleibt offen. Aus einer Ab...

Die ehrlichste Zeile Code

Im Juni 2025 haben die Go-Maintainer eine Entscheidung getroffen, die auf den ersten Blick wie Aufgeben aussieht - und auf den zweiten wie Reife. Seit Jahren stört sich die halbe Go-Community an einer Sache: der Fehlerbehandlung. Nach fast jedem Funktionsaufruf dieselbe Geste: `if err != nil { return err }`. Drei Anläufe in sieben Jahren sollten das beheben: erst das check/handle-Modell aus dem Go-2-Entwurf, dann die try()-Funktion, zuletzt ein „?"-Operator nach Rust-Vorbild. Keiner hat es in die Sprache geschafft. Im Juni 2025 zogen die Maintainer einen Schlussstrich: keine neue Syntax für Fehlerbehandlung, die offenen Proposals werden geschlossen. Die drei Zeilen bleiben. Der elegante Gegenentwurf Java löst dasselbe Problem scheinbar schöner. Eine Methode wirft eine Exception, irgendwo weiter oben fängt sie jemand. Dazwischen muss niemand etwas tun. Checked Exceptions sollten genau das erzwingen: der Compiler verlangt, dass man sich kümmert. In der Praxis endet das oft in ein...

Legacy ist eine Entscheidung, keine Altlast

Diese Woche gab es bei uns eine Diskussion, die in keinem Feature-Plan steht und trotzdem über Jahre nachwirkt: Wie gehen wir mit dem Support für die ältere Generation eines Produkts um, wenn die neue längst im Einsatz ist. Keine Frage, die man auf einer Folie schön darstellen kann. Aber eine, die jeden Betrieb früher oder später einholt. Legacy ist kein Zustand, sondern eine Entscheidung Der Begriff Legacy klingt nach Staub und Stillstand. Tatsächlich ist Legacy meist das, was zuverlässig läuft und Geld verdient. Das Problem ist nicht der alte Code an sich, sondern die fehlende Entscheidung, wie lange und wie gut man ihn noch trägt. Gartner beziffert das: Wer technische Schulden ignoriert, gibt bis zu 40% mehr für Wartung aus. Premium-Support für End-of-Life-Systeme kostet schnell das Doppelte bis Dreifache des regulären Supports. Wer nichts entscheidet, entscheidet sich für die teuerste Variante. Die alte Generation ist ein Vertrauenstest In der Enterprise-Welt laufen Anwendungen...

PaaS-Komfort, Hyperscaler-Risiko: Was der Railway-Outage gestern Nacht gezeigt hat

Acht Stunden Outage gestern Nacht. Mein Go-Stack auf Railway war nicht erreichbar - das Frontend lief, das Backend war tot. Ursache: Google Cloud hat Railways Produktions-Account fälschlich in einen Suspend-Status verschoben. Automatisierte Aktion, keine Vorwarnung, und eine Reihe weiterer Kunden traf es im selben Schwung mit. Was PaaS verspricht - und was nicht Railway, Render, Fly.io und Konsorten verkaufen Developer Experience. Push-to-deploy, automatische Build-Pipelines, fertige Datenbanken. Das ist real und gut. Was sie nicht abstrahieren: die Infrastruktur unter der Plattform. Railway läuft auf GCP. Wenn dort ein Compliance-Filter falsch konfiguriert ist, geht Railway offline. Ohne Vorwarnung, ohne Eskalationspfad für den einzelnen Kunden. Die Lieferketten-Frage Vor fünf Jahren war „auf welchem Cloud-Provider seid ihr" eine sinnvolle Frage. Heute braucht es zwei: Auf welchem Provider seid ihr direkt - und auf welchem Provider sitzt eure PaaS? Bei vielen Java-Stacks ist ...