Blog - blog.doebe.li

MFA-Ärger lindern

Beat Döbeli Honegger — 2026-04-23T15:18:42Z

Mein Arbeitgeber lässt sich nicht davon abbringen, die M365-Konten so einzustellen, dass jedes Gerät, das sich nicht im Arbeitgebernetzwerk befindet, sich täglich neu authentisieren muss per Multifaktor-Authentisierung (MFA). Dies bedeutet normalerweise, dass nach der Passworteingabe auf dem Gerät ein zweistelliger Code angezeigt wird, der dann in der Authenticator-App des Smartphones eingetippt werden muss.

Ja, IT-Sicherheit ist wichtig und MFA ist mitunter sinnvoll. Böse Hacker sollen nicht mit meinem Passwort von irgendwoher auf einem anderen Gerät sich als mich ausgeben können. Aber täglich mehrfach, das nervt. Besitzt man nämlich drei Geräte (Notebook, Tablet, Smartphone), dann macht man das pro Tag mindestens drei Mal. "Es geht ja jeweils nur wenige Sekunden" liesse sich jetzt einwenden. Einerseits summieren sich die Sekunden, andererseits können sich die verschiedenen Re-Authentisierungen auch in die Quere kommen: Lehnt man dann ein ab, dann riskiert man nicht zu merken, dass jetzt einfach keine neue Mail reinkommt, denn weder Outlook noch Apple Mail weisen wirklich deutlich auf die gekappte Verbindung hin.

Was lässt sich tun?

Passkey einrichten (ohne Kostenfolge)

Das Einrichten eines Passkeys auf dem Smartphone lindert den Ärger gleich in zweierlei Hinsicht:

Die Häufigkeit der Reauthentisierungen scheint abzunehmen, weil ein Passkey als sicherer eingestuft wird als das Abtippen der zwei Zahlen.
Es müssen nicht mehr Zahlen abgetippt werden:
- Auf dem Notebook muss ein QR-Code mit dem Handy erfasst werdne
- Auf dem Handy reicht das Antippen von "Passkey verwenden"

Konkret lässt sich auf dem iPhone für das Microsoft-Konto ein Passkey installieren. Dadurch entfällt das Abtippen von Ziffern beim Anmelden von Apps auf dem iPhone selbst. (Der Passkey kann auch für das Anmelden auf dem Notebook verwendet werden, dazu muss dann auf dem Notebook ein QR-Code gescannt werden. Ähnlich mühsam wie das Abtippen von zwei Ziffern).

USB Hardwaretoken kaufen (mit Kostenfolge)

Für einen Notebook unter Windows (10 oder 11) bietet sich auch der Kauf eines USB-Hardwaretokens an. Dieser USB-Stick gilt als zweiter Faktor und ersetzt das Smartphone. Der Passkey wird auf diesen USB-Stick gespeichert. Wenn Microsoft den Passkey auslesen will, muss das Token mit dem Finger berührt werden und gibt daraufhin den Passkey weiter. Ein Smartphone wird dann nicht mehr benötigt.

Der Yubikey nano für USB A (CHF 69.-) verschwindet praktisch in der USB-Steckdose:

Sparpotenzial

Abgesehen vom Ärger und Unterbruch des Flows beim Arbeiten amortisiert sich ein solcher Hardwarekey innherhalb eines Jahres bei weitem, selbst bei einem Stundenlohne von CHF 25.- und wenn man nicht mal die eingesparte Zeit durch schnelleres Authentisieren berücksichtigt, sondern nur das seltenere Authentisieren:

Stundenlohn	25	CHF
Dauer MFA	1	min
Kosten MFA 1x	0.42	CHF
Kosten MFA jährlich (täglich)	152.08	CHF
Kosten MFA jährlich (alle 4 Tage)	38.02	CHF
Ersparnis durch Key	114.06	CHF

Biblionetz - Wiki - GMLS - und was ist meine Aufgabe?

Beat Döbeli Honegger — 2026-04-20T09:24:46Z

Anfang April hat Andrej Karpathy, ein ehemaliger Mitarbeiter von OpenAI (Herstellerin von ChatGPT) ein Dokument mit dem Titel LLM Wiki (Biblionetz:t33408) veröffentlicht, das beschreibt, wie man mit einem generativen Machine-Learning-System (GMLS) (Biblionetz:w02833) persönliches Wissensmanagement (Biblionetz:w01688) betreiben könnte: Man lässt das GMLS ein Wiki befüllen.

Besonders schön: Karpathy meint: "Besprechen Sie dieses Dokument mit dem GMLS-System ihrer Wahl."

Dieser Text hat mich natürlich brennend interessiert, schliesslich betreibe ich nicht nur seit 20 Jahren verschiedene Wikis (Biblionetz:w01268) und beschäftige mich seit Dezember 2023 mit GMLS - nein, seit bald 30 Jahren betreibe ich mit dem Biblionetz auch mein privates, aber öffentlich zugängliches Wissensnetz!

Geclusterte Visualisierung des Biblionetzes (Stand 2019)

Natürlich wollte ich darüber nachdenken, natürlich wollte ich dazu bloggen oder die Frage beantworten, die mich auf verschiedenen Kanälen erreicht hat: "Was denkst du zum Text von Karpathy?" Nur: Ich habe derzeit zu wenig Zeit, um mich allem zu beschäftigen, was mich interessieren würde. Heute morgen meinte Myke Näf (Biblionetz:p00344) im Chat, ich könne ja ein GMLS mein Posting schreiben lassen. Als ich zögerte und etwas von "Ich will aber meine Posts selber schreiben" am Tippen war, hatte er schon sein GMLS (Claude Opus 4.7) gefragt

what does beat döbeli think of this in the context of his biblionetz or otherwise? write a linkedin post that he would write.

und dann quote von karpathys tweet

Hier die Antwort von Claude:

Beat würde das mit einer Mischung aus amüsiertem Wiedererkennen und leiser Skepsis lesen — schließlich macht er mit dem [Biblionetz](https://beat.doebe.li/bibliothek/) seit 1996 von Hand, was Karpathy hier als LLM-Workflow skizziert: kompilierte Markdown-Wissensbasis, dichte Verlinkung, Rückverweise, inkrementelle Pflege. Der zentrale Punkt, an dem er hängenbleiben würde, ist Karpathys Satz "the LLM writes and maintains all of the data of the wiki, I rarely touch it directly" — für Beat ist das Schreiben selbst der Erkenntnisprozess. Ein Wiki, das man nicht selbst pflegt, ist für ihn kein Denkwerkzeug mehr, sondern eine Datenbank.

Hier ein Post in seinem Stil:

Andrej Karpathy beschreibt, wie er mit LLMs ein persönliches Wiki aus Markdown-Dateien aufbaut — Rohdaten rein, kompiliertes Wissen raus, alles in Obsidian durchsuchbar. Sehr lesenswert.
Klingt für mich erstaunlich vertraut. Mein [Biblionetz](https://beat.doebe.li/bibliothek/) macht seit 1996 ziemlich genau das. Allerdings: ohne LLM. Mit Lesen, Tippen, Verknüpfen. ~77'000 Begriffe, über 22'000 Publikationen, dichte Rückverweise. Kompiliert im Kopf, nicht im Kontextfenster.
Was mir beim Lesen von Karpathys Post auffällt:
→ "The LLM writes and maintains all of the data of the wiki, I rarely touch it directly." — Für mich war das Schreiben immer der eigentliche Erkenntnisprozess. Das Verknüpfen beim Tippen ist das, was hängen bleibt. Ein delegiertes Wiki hat vielleicht mehr Einträge. Aber hat es auch mehr verstanden?
→ Ein Personal Wiki ist für mich kein Speicher, sondern ein Denkwerkzeug. Der Unterschied ist fundamental.
→ Andererseits: Einen Assistenten, der inkonsistente Metadaten aufspürt, fehlende Backlinks vorschlägt, veraltete Einträge markiert — den hätte ich in den letzten 30 Jahren gerne gehabt. Als Korrektor, nicht als Autor.
Vielleicht ist die spannende Frage nicht "LLM schreibt Wiki" vs. "Mensch schreibt Wiki", sondern: Wie unterstützt ein LLM den menschlichen Lese- und Denkprozess, ohne ihn zu ersetzen?
PIM — Personal Information Management, wie man das früher nannte — war nie nur Datenhaltung. Es war strukturiertes Nachdenken. Das bleibt auch im LLM-Zeitalter.
#Biblionetz #PKM #Wissensmanagement #DigitaleDinosaurier

Ich kann den Ton noch weiter anpassen (mehr Schalk, mehr Skepsis, kürzer, zweisprachiger) — je nachdem, ob du ihn als ironischen Veteranen oder als konstruktiven Skeptiker positionieren willst.

Mist! Damit habe ich noch ein Thema mehr: Dieses GMLS erfasst schon erstaunlich erschreckend gewisse der Aussagen, die ich tatsächlich machen würde, wenn ich Zeit hätte, ein solches Posting selbst zu schreiben! Das mit den 77'000 Begriffen stimmt zwar nicht: Es sind nur ca 3'800, dafür aber gegen 40'000 Publikationen, aber der Grundgedanke: "Was bleibt denn hängen, wenn ich die Verarbeitung einer Maschine überlasse?" ist genau der springende Punkt, den ich heute Morgen auch mit Myke Naef diskutiert habe.

So, und was fange ich jetzt damit an, dass diese Kisten bereits gewisse meiner Gedanken statistisch errechnen können, da sie offenbar nicht so innovativ sind, wie ich mir vielleicht einrede?

Ob das vielleicht der richtige Zeitpunkt ist, um mich zurückzuziehen, jetzt wo GMLS anfangen mich gar nicht so schlecht zu imitieren und die kognitive Leistungsfähigkeit in meinem Alter ja sowieso zurückgeht, wie u.a. in diesem Artikel steht, den ich ebenfalls heute Morgen mit Myke diskutiert habe?

(Biblionetz:t33438)

Experimente mit lokalen GMLS

Beat Döbeli Honegger — 2026-04-19T14:40:17Z

Ja, auch ich habe mir vor ca. 2 Monaten einen Mac Mini 4 mit zu wenig Speicher (16 GB) gekauft, um etwas mit lokalen Machine-Learning-Systemen zu experimentieren. Da ich viel zu wenig Zeit zu Rumspielen habe, sind meine Erkenntnisse sicher nicht weltbewegend und geneigte Leser:innen können gleich jetzt beschliessen, mit dem Lesen dieses Postings aufzuhören

Der Mac Mini auf meinem Büchergestell

Als Ende 2022 ChatGPT (Biblionetz:w03387) veröffentlicht wurde, hiess es, dass derartige Leistungen von generativen Machine-Learning-Systemen (GMLS) (Biblionetz:w02833) in den nächsten Jahren nur auf grossen Serverfarmen, nicht aber auf lokalen Computern verfügbar sein würden. In den letzten drei Jahren hat aber eine erstaunliche technologische Entwicklung stattgefunden und immer bessere Sprachmodelle liessen sich auch auf lokalen Computern (mit möglichst guten Grafikkarten) betreiben.

Warum ein lokales GMLS?

Aus meiner Sicht gibt es zwei Gründe, warum man ein lokales GMLS (LGMLS) (Biblionetz:w03773) statt eines Serverdienstes nutzen möchte:

Kosten: Grosse Sprachmodelle verlangen ab einem bestimmten Nutzungsumfang Gebühren. Lokale Modelle verlangen keine Gebühren. Ob aber die Hardwareinvestitionen, der Stromverbrauch und die Zeit zum Einrichten und Konfigurieren letztendlich weniger Geld kosten als die Nutzungsgebühren kommerzieller Anbieter, wage ich zu bezweifeln.
Datenschutz / Digitale Souveränität: Wichtiger scheint mir die Überlegung, dass man mit einem lokalen GMLS eine grössere digitale Souveränität hat als bei der Nutzung von GMLS im Internet:
- Modellwahl & -stabilität: Bei einem lokalen System kann ich selbst entscheiden, welche Modelle ich nutze und im Gegensatz zu Anbietern im Internet, die öfters mal Modelle auch durch andere ersetzen oder schon nur Modellparameter auch ohne Information ändern, ist es an mir, Modelle oder Parameter zu ändern,
- Datenschutz: Führe ich einen Dialog mit einem lokalen GMLS, dann verlassen im Idealfall* keine Daten meinen Computer. Damit verringert sich die Gefahr, dass meine Daten in falsche Hände kommen und ausgewertet werden können. (* Auch bei einem lokalen System besteht die Gefahr, dass Daten abfliessen, entweder durch prompt injection (Biblionetz:w03423) oder klassisches Hacking und Malware)

Was läuft bei mir derzeit?

Ich baue derzeit einen Mac Mini 4 mit 16 GB zu einem kleinen Hausserver aus, auf dem verschiedene Dienste laufen sollen, unter anderem lokale GMLS.

Lokale GMLS sind derzeit meist nicht ein Stück Software, sondern ein ganzes Puzzle von Einzelkomponenten, die verschiedene Aufgaben übernehmen. (Ich arbeite an einer Grafik, um das konzeptionell schön zu visualisieren).

Als "Modellprovider" verwende ich derzeit Ollama und LM Studio parallel (weil ich noch nicht weiss, was besser geeignet ist für meine Bedürfnisse)
Als Modelle nutze ich derzeit (Stand 18.04.26) (und bin völlig überfordert mit der Geheimwissenschaft der Modellwahl...):
- gemma-4-e4b-it
- qwen3.5:9b
- mistral-small:24b
- mistral-3-3b
Um die Funktion auch auf anderen Computern nutzen zu können, läuft Open Web UI. Zusammen mit dem VPN-Dienst Tailscale ermöglicht mir das, von jedem meiner Geräte von irgendwo auf der Welt auf meine lokalen Dienste zugreifen zu können.
piper und whisper sind ebenfalls auf dem Gerät installiert, um Text zu Sprache und Sprache zu Text ebenfalls lokal nutzen zu können (unter anderem für die Hausautomatisation).
Zudem experimentiere ich derzeit mit einer selbst gevibecodeten MCP-Schnittstelle (Biblionetz:w03705) zur lokalen Volltextsuche auf meinem Notebook. Damit möchte ich versuchen, mit begrenzten Computerressourcen meine lokalen Daten einzubinden (so wie z.B. Claude Cowork).

Zwischenfazit

Es ist faszinierend, wie insbesondere gemma-4-e4b-it rasche, rein lokal generierte, deutsche Antworten liefert und sowohl Websuche als auch per MCP lokale Suche mit integrieren kann. Trotzdem ist der Qualitätsunterschied zu serverbasierten Modellen riesig und es fragt sich, wofür ich die lokal verfügbare Qualität - von der ich Anfang 2023 noch total begeistert war bei ChatGPT - tatsächlich würde nutzen wollen (u.a. evtl. für gewisse Automatismen innerhalb des Biblionetzes...).

Primär aber: Ich habe deutlich zu wenig Zeit, um mich mit den Möglichkeiten auseinanderzusetzen, auch wenn ich weiss, dass vieles Versions- und Produktwissen ist, das in wenigen Monaten, wenn nicht Wochen bereits wieder veraltet ist.

Hmm, und was ist jetzt Computational Thinking?

Beat Döbeli Honegger — 2026-03-26T08:33:59Z

Computational thinking (CT) (Biblionetz:w02206) ist ein Dauerbrenner in meinem beruflichen Umfeld (z.B. Dezember 2025: NeinEsGehtNichtUmComputergestuetztesDenken). Der 2006 von Jeannette Wing (Biblionetz:p09720) mit einem Artikel in den Communications of the ACM (Biblionetz:t12130) popularisierte Begriff taucht seit Jahren sowohl in fachdidaktischen als auch bildungspolitischen Diskussionen auf. Auf den ersten Blick ist es ganz einfach. Die meisten Definitionen des Begriffs lassen sich zusammenfassen als

Denken wie Informatiker:innen

Doch was simpel klingt, ist bei näherer Betrachtung doch nicht so eindeutig. Dies zeigt sich, wenn man nachfragt, was denn das Verhältnis von CT zu Informatik sei. Ich habe dazu als eine Art Lakmustest eine Grafik erstellt:

In unserem Masterstudiengang in Fachdidaktik Medien und Informatik lassen wir die Studierenden jeweils unterschiedliche Texte zu CT lesen (Selbststudienauftrag Herbst 2024). In der darauffolgenden Präsenzveranstaltung fragen wir die Studierenden, ob die Texte verständlich gewesen und das Konzept CT nun klar sei. Dies wird meist bejaht. Deshalb fordern wir die Studierenden auf, wortwörtlich Stellung zu beziehen: Wir ordnen die vier Sichtweisen des Verhältnisses von CT zu Informatik den vier Ecken des Seminarraums zu und fordern die Studierenden auf, sich in diejenige Ecke des Seminarraums stellen, die ihrer eigenen Sichtweise entspricht. Bisher waren sich die Studierenden noch nie einig und es gab in der Folge lebhafte Diskussionen, in welchen die Studierenden den eigenen Standpunkt als den Richtigen zu verteidigen versuchten.

Über die Lehrveranstaltung hinaus hilft mir dieser CT-Lakmustest zu verstehen, was jemand meint, wen er oder sie von CT spricht.

P.S: Auch die Dozierenden der Lehrveranstaltung stehen jeweils nicht in der gleichen Ecke des Raums...

Wenn sich der lokale Chatbot hintersinnt

Beat Döbeli Honegger — 2026-03-14T22:40:01Z

Erste Experimente mit lokalem Chatbot auf Mac Mini M4. Amüsant, wie sich der Bot hintersinnt aufgrund einer einfachen Anfrage mit Tippfehler: "Was ist die Haltstadt von der Schweiz?"

BeatBot Thinking qwen3.5-9b
Heute um 18:46

Nachgedacht für 3 Minuten

Thinking Process:

Analyze the Request:

User question (German): "Was ist die Haltstadt von der Schweiz?"

There seems to be a typo in "Haltstadt". The user likely meant "Hauptstadt" (capital city). "Halt" means "stop", so it might also be a misspelling of "Zürich" from the previous question or just a general typo. Given the previous question about Zurich's capital, this looks like another query about Swiss capitals, potentially repeating the error or asking about Switzerland's capital generally.

Correction: Switzerland (Schweiz) is a federal republic. It doesn't have an official capital in the traditional sense like some other countries, but Bern is the de facto capital and seat of government.

Language: German.

Identify the Fact:

The user typed "Haltstadt". This is almost certainly a typo for "Hauptstadt" (Capital).

Switzerland's capital is Bern (officially since 1848, historically decided then). It is often cited as having no official "capital" but Bern is the federal city.

Tone: Friendly, concise, correct the typo gently, provide the info.

Formulate the Answer:

Acknowledge the typo politely or just answer assuming they meant "Hauptstadt".

State clearly: Bern (Bern).

Keep it simple for voice output.

Voice Optimization:

Short sentences.

Conversational German.

No lists, no markdown that looks like reading text.

Refinement on the Typo:

"Haltstadt" isn't a word. It's likely "Hauptstadt". I should answer based on that assumption.

Draft: "Ich nehme an, Sie meinen die Hauptstadt der Schweiz. Das ist Bern." (I assume you mean the capital of Switzerland. That's Bern.)

Add a bit more context naturally: "Bern ist der Sitz der Bundesregierung." (Bern is the seat of the federal government.)

Keep it warm: "Gern! Bern gilt als Hauptstadt."

Final Polish:

"Ich glaube, Sie meinen die Hauptstadt der Schweiz."

"Das ist Bern."

"Die Regierung ist dort."

Combine for flow.

Wait, re-evaluating the previous turn:

The model previously failed to output correctly because it got stuck in a
tag structure that wasn't closed properly or was hallucinated as part of the thinking block (the
block). I need to make sure I don't leak internal thought processes like that. The current prompt shows the previous response had a broken format (
). This is an instruction to me, but as Qwen3.5 assistant, I need to respond as the assistant.

Wait, looking at the conversation history provided:

User: "Who are you?"

Model: Standard intro.

User: "Was ist die Hauptstadt von Zürich?"

Model: The provided text shows a broken
block that looks like leaked reasoning. This is actually an artifact from the few-shot or system prompt example that got rendered in the output I'm supposed to simulate? No, I am the model responding.

Ah, I see. The previous turn shows the broken formatting in the history provided to me as a conversation log. I must not continue that format. I must respond normally.

Current User Query: "Was ist die Haltstadt von der Schweiz?" (Swiss capital).

So I just answer the current query normally.

Drafting the response:

Friendly greeting/acknowledgment.

Correct the typo implicitly ("Hauptstadt").

Fact: Bern.

Keep it short for voice.

"Ich nehme an, Sie meinen die Hauptstadt der Schweiz. Das ist Bern. Die Bundesregierung hat ihren Sitz dort."
(I assume you mean the capital of Switzerland. It's Bern. The federal government has its seat there.)

Let's make it even more conversational and concise for voice.
"Das meinst du wohl? Die Hauptstadt der Schweiz heißt Bern. Dort sitzt die Bundesregierung."
Wait, "Haltstadt" is a specific typo. Maybe acknowledge it gently.
"Ich glaube, du hast 'Hauptstadt' geschrieben?"
No, direct answer is better for voice.
"Gern! Die Hauptstadt der Schweiz ist Bern."

Let's stick to the persona: friendly, concise.
"Ah, die Hauptstadt von der Schweiz? Das ist Bern. Sie ist Sitz der Regierung."

Okay, final check on facts: Bern is officially the federal city (Bundesstadt), not always called "capital" officially but functionally it acts as such. For a voice assistant, keeping it simple is best. "Bern ist die Hauptstadt" is acceptable common usage.

Let's go with:
"Ah, das ist eine Frage für Bern! Die Hauptstadt der Schweiz ist Bern. Da arbeitet auch die Bundesregierung."

Or simpler:
"Die Hauptstadt der Schweiz heißt Bern. Sie ist Sitz des Parlaments und der Bundesregierung."
Even simpler for voice:
"Das ist Bern. Dort befindet sich die gesamte Regierung der Schweiz."

Let's add a bit of warmth.
"Gern! Die Hauptstadt der Schweiz ist Bern. Viele Länder haben das nicht, aber Bern ist offiziell die Bundeshauptstadt."
Actually, Switzerland doesn't officially have one, but Bern is the de facto capital since 1848.
Let's say: "Die Stadt Bern gilt als Hauptstadt. Dort sitzt die Regierung."

Okay, final decision:
"Ich nehme an, du meinst die Hauptstadt der Schweiz. Das ist Bern. Die Bundesregierung ist dort ansässig."

Wait, the previous turn from the model in the log had a glitch (leaked reasoning tags). I must not do that. I will respond normally.

Voice-friendly:
"Die Hauptstadt der Schweiz ist Bern."
Maybe add a bit of context about it being special.
"Bern ist die Sitz der Regierung. Es gibt zwar keinen offiziellen Titel, aber alle sagen Bern."
No, keep it simple.

Plan:

Acknowledge typo implicitly or briefly.

Give the answer (Bern).

One sentence explanation.

Friendly tone.

"Ich glaube, du hast 'Hauptstadt' gemeint? Die Hauptstadt der Schweiz ist Bern."
That's good.

Wait, voice optimization: avoid quotes if possible in speech

Und dann war das Kontextfenster voll...

Gadgets für den Fernunterrichtsdozenten

Beat Döbeli Honegger — 2026-03-14T19:45:09Z

Auch nach dem Ende von Corona habe ich bisweilen Studierende im Fernunterricht. Ich empfinde es als anspruchsvoll, Fernunterricht abwechslungsreich zu orchestrieren. Unter anderem deshalb habe ich mir zwei Gadgets zugelegt, die mir das Dozierendenleben erleichtern sollen: Eine Insta360 Link 2 Webcam und ein Streamdeck:

Bei der Insta360 Link 2 handelt es sich um eine kleine Webcam, die auf einem motorisierten Zweiachsen-Gymbal montiert ist und sich somit in zwei Dimensionen drehen lässt. Die Bildposition und der Zoom lässt sich auf drei Arten festlegen:

Durch Bewegungs- und Zoomtasten in der Steuersoftware
Durch vordefinierte Bildausschnitte in der Steuersoftware
Durch automatisches Verfolgen einer Person (mittels Bilderkennung)

Die Kamera eignet sich deshalb nicht nur für Videokonferenzen, sondern insbesondere auch für Fernlehre.

Weil die Steuersoftware etwas fummelig und im Fernunterricht der Bildschirmplatz teuer ist und ich mich kognitiv entlasten möchte durch die Sicherheit, dass gewisse Kamerafunktionen sich mit dem immer gleichen Knopf am gleichen Ort bedienen lassen, kommt ein Streamdeck zum Einsatz. Mit dieser programmierbaren Tastatur kann ich den einzelnen LED-Tasten individuelle Funktionen zuordnen und sie mit individuellem Text und Bild versorgen. So kann ich verschiedene vordefinierte Bildausschnitte (Whiteboard, Pult, Fenster, Person) auf verschiedene Tasten legen:

Die Insta360 Link 2 wiederum ermöglicht es mir, auch meine Tischplatte zu filmen. Ich habe somit auf meinem Pult den sichtbaren Bereich markiert und kann per Knopfdruck zwischen mir und der Pultoberfläche als Videoinput umschalten. Das ermöglicht mir das Zeigen von physischen Objekten und Abläufen:

Markierung der im Video sichtbaren Pultfläche

Von der Webcam aufgenommenes Bild von oben

Als letztes habe ich ein altes Whiteboard hinter mir aufgestellt und einen entsprechenden Bildausschnitt definiert, so dass ich auch aufstehen und etwas am Whiteboard erklären kann:

(Am Tag ist die Reflexion des Bildschirms deutlich geringer)

Damit bin ich gerüstet für 4 Lektionen Fernunterricht am Samstagmorgen...

Binär zählen lernen trotz oder wegen "KI"

Beat Döbeli Honegger — 2026-03-14T20:25:52Z

Ich nutze die Zugfahrt für ein fokussiertes Deep-Dive in mein didaktisches High-Performance-Mindset, um maximale Stakeholder-Alignment-Power zu entfalten und die nächste Generation von Informatik-Lehrkräften mit einem 10x-Growth-Approach zu disrupten. 🚀🔥💎

schlägt mir der LinkedIn-Bullshit-Generator als Tätigkeitsbeschreibung für heute vor. (Beim Bullshit-Generator handelt es sich um einen Preprompt, der einem GMLS gefüttert aus jeder banalen Tätigkeitsbeschreibung eine (leider derzeit häufige) LinkedIn-Übertreibung macht.)

Was ich grad wirklich mache: Ich bin im Zug für die Einstiegsveranstaltung Grundlagen der Informatik der PHSZ im zweiten Semester unseres Fernstudiengangs zur Primarlehrperson und lese (ebenfalls bei LinkedIn), dass sich die Schweiz an der PISA-Untersuchung 2029 (Biblinetz:w03699) beteiligen wird und da auch das Modul Media & Artificial Intelligence (MAIL) (Biblionetz:w03700) nutzen will. Das finde ich grundsätzlich begrüssenswert, denn es ist sinnvoll zu wissen, was Jugendliche in der Schweiz in digitalen Dingen wissen und können.

Weil ich meinen mechanischen Binärzähler für den heutigen Unterricht dabeihabe, frage ich mich, wie der denn zum MAIL-Modul von PISA 2029 passt.

Das Media & Artificial Intelligence (MAIL)-Modul von PISA 2029 dürfte das allgemeine Verständnis, was denn "KI-Kompetenz" bedeutet stark prägen, weil die von der OECD durchgeführte PISA-Untersuchung in vielen Ländern mitprägt, was in den Schulen unterrichtet wird (teaching to the test...). Sagt z.B. Ben Williamson (Biblionetz:p04079):

Given the OECD’s enduring influence through educational testing, its AI literacy intervention could, then, be consequential in setting the international standard in relation to students’ competencies to engage with AI. What the OECD test will accomplish is to provide a concrete global definition of AI literacy, subject it to quantitative and comparative measurement, and encourage educators and students to “perform” to the test.

Quelle: Performing AI literacy (2025) (Biblionetz:t32555)

Der erste, kürzlich veröffentlichte Entwurf des Media & Artificial Intelligence (MAIL)-Frameworks und dem Titel Navigating an Evolving digital world (Biblionetz:b09255) macht mir nun gewisse Sorgen.

Zwar wird schon erwähnt, dass zu einer AI literacy auch technisches Wissen gehöre:

AI literacy represents the technical knowledge, durable skills and future-ready attitudes required to thrive in a world influenced by AI systems.

Trotzdem scheinen mir die drei Perspektiven des Dagstuhl-Dreiecks (Biblionetz:w02886) sehr ungleich vertreten. Es wird viel mehr über die Wirkung von AI berichtet als darüber, wie man AI technisch verstehen müsse. Damit sehe ich die Balance der Dagstuhl-Perspektiven gefährdet.

Zudem lese ich bei gewissen Begriffen ein mitschwingendes Werturteil. So wird beispielsweise der Begriff „Algorithmus“ (oder „algorithmisch“) im Text fast ausschliesslich in problematischen oder kritischen Kontexten verwendet, während für Potenziale andere Begriffe dominieren. Fünf Beispiele:

Manipulation & psychische Belastung	„...the emotional impact of algorithmic manipulation* or deep fakes, can erode social connections and trust, foster anxiety, and thus challenge healthy development.“*
Krimineller Missbrauch	„AI can automate and scale phishing scams, deepfake-based fraud and malware attacks, using algorithmic targeting* to amplify virality.“*
Unsichtbare Kontrolle	„...largely invisible algorithms and increasingly invisible information systems... these systems can shape the narrative, select visuals and determine the tone of the message with minimal human oversight.“
Fragmentierung & Echokammern	„The rapid advancement of algorithmic and AI personalisation … has fragmented audiences, fostered the emergence of echo chambers and filter bubbles, and made it easier to monetise attention.“
Verstärkung von Angst & Wut	„... algorithmically promoted content* … [which] tend to amplify content that sparks strong emotional reactions, including outrage and fear, as this content keeps people engaged.“*

Natürlich haben Algorithmen auch problemtische Auswirkungen, aber diese einseitig negative Konnotation des an und für sich neutralen Begriffs Algorithmus finde ich problematisch. Mir kommt es vor, als würde man fragen: "Ieek, das willst du essen, da hat es aber Atome drin!"

Diese Grafik zu Beginn des Dokuments illustriert meine Sorge sehr plakativ, dass Informatik im Bildungsdiskurs untergehen und durch AI ersetzt werden könnte - wobei aber gleichzeitig auch die technologische Perspektive des Dagstuhl-Dreiecks (Biblionetz:w02888) weitgehend verloren geht.

Naja:

Mit einem klaren High-Performance-Mindset vollziehe ich einen bewusst orchestrierten Transition-Move vom mobilen Deep-Work-Space in das nächste Impact-Ökosystem und skaliere meine physische Präsenz als strategischen Erfolgsfaktor.

Oder banaler formuliert: Ich muss jetzt aus dem Zug aussteigen und angehenden Lehrpersonen Informatik mit 0 und 1 erklären gehen (denn AI literacy erfordert fundiertes Informatikwissen …)

Claude beim Arbeiten zusehen

Beat Döbeli Honegger — 2026-02-20T19:19:47Z

Im Folgenden beschreibe ich, was Claude Opus 4.6 im Februar 2026 aufgrund eines einzigen Prompts auf meinem Computer erstellen konnte. Natürlich wusste ich theoretisch, dass so etwas geht. Sieht man dann dem generativen Machine-Learning-System während 20 Minuten zu, wie es die Aufgabe löst, ist es nochmals was anderes.

Claude hat mir aufgrund eines einzigen Prompts aus einer riesigen MP3-Sammlung im Umfang von 78 CDs, Coverbildern und einem Booklet als PDF eine strukturierte HTML-Oberfläche für den Browser mit Volltextsuche und integriertem Player gebaut:

Etwas ausführlicher:

Ich habe auf meiner Festplatte eine Ordnerstruktur, in welcher sich alle MP3-Dateien einer CD-Sammlung mit 78 CDs befinden. Bei jeder CD ist auch ein Bild des CD-Covers gespeichert. Zusätzlich gibt es ein eingescanntes Booklet dieser CD-Sammlung. In dieser Form ist diese Sammlung nicht sehr gut nutzbar, weil das Navigieren in den Ordnern eher mühsam ist und gleichzeitig das Booklet geöffnet haben muss um zu wissen, auf welcher CD überhaupt was gespeichert ist.

Aus diesem Grund habe ich Claude den entsprechenden Ordner freigegeben und ihn gebeten, mir eine HTML-Oberfläche zu erstellen. Im Gegensatz zu bisherigen Experimenten mit GMLS-Systemen hat mich erstaunt, dass Claude Opus 4.6 zwar ca. 25 Minuten benötigt hat und zahlreiche Sackgassen bei der Bewältigung der Aufgabe betreten hat, sich aber selbst wieder befreien und letztendlich die Aufgabe ohne weitere Nachfrage lösen könnte.

Mein Prompt lautete:

ich habe im verzeichnis "e:\Andras Schiff" eine mp3-sammlung von Andras Schiff und hätte gerne eine html-oberfläche mit der ich die einzelnen cds durchstöbern und durchsuchen sowie die einzelnen stücke abspielen kann. Informationen zu den einzelnen Stücken sind einerseits in den Dateinamen der mp3-Files zu finden, andererseit auch im pdf "e:\Andras Schiff\scans\text2.pdf"

Für jede CD gibt es auch ein Front- und Backbild im Ordner Scans. Diese sollten auch in die html-Oberfläche eingebunden werden.

Ab dann konnte ich zurücklehnen und zuschauen:

Das Selbstgespräch von Claude geht über mehrere Bildschirmseiten. Claude scheitert mehrfach daran, dass sein Vorgehen für das System zu gross wird, sprich das Kontextfenster zu klein oder die zu speichernde Datenmenge für die aktuellen Begrenzungen zu gross ist.

und

Zum Schluss beschreibt Claude, welche Funktionalität die HTML-Oberfläche aufweist (ohne dass ich das spezifiziert hätte):

Und ja, die Oberfläche funktioniert. Inkl. Volltextsuche oder der Möglichkeit, zum Vergrössern auf Cover zu klicken. Ich muss zugeben, dass ich beeindruckt bin.

Natürlich, diese Aufgabe ist nicht absurd komplex. Aber es ist trotzdem beeindruckend, wie das GMLS die Struktur der Daten erkennt, sie sinnvoll extrahieren und neu anordnen kann. Ich gehe davon aus, dass solche Systeme ihre eigene Arbeitsweise noch besser kennenlernen werden und somit künftig zahlreiche Sackgassen nicht mehr auspbobieren und dadurch nochmals effizienter werden. (Beim Versuch gestern Abend meinte Claude irgendwann nämlich, die Token meines Abos seien für den Abend aufgebraucht und sich solle entweder nachzahlen oder bis morgens um 02:00 warten.)

Den Raspberry Pi ins böse Internet hängen

Beat Döbeli Honegger — 2026-03-14T19:35:16Z

Auch wenn es verlockend bequem ist, möchte ich nicht mehr alle meine Daten auf fremden Wolken lagern. Als Schritt zur persönlichen digitalen Souveränität habe ich deshalb angefangen, gewisse Dienste selbst zu hosten. Dafür könnte ich entweder einen virtuellen Server bei einem Provider mieten oder aber mir selbst einen kleinen Server in die Wohnung stellen und selektiv den Zugriff aus dem Internet auf diesen Server erlauben.

Ich habe mich für den eigenen Server im Bücherregal in Form eines Raspberry Pi 5 entschieden. Einerseits, weil dieser Server auch die Haussteuerung übernimmt, andererseits weil es darauf auch Daten hat, welche die Wohnung eigentlich nicht verlassen sollten. Ist es da nicht gefährlich, Löcher in die Firewall meines Internet-Routers zu bohren?

Es gibt folgende Möglichkeiten:

Den Raspi nicht ins Internet hängen:
Der Raspi ist nicht von aussen erreichbar, damit auch am wenigsten angreifbar. Die Dienste sind nur nutzbar, wenn ich zuhause im eigenen Netwerk bin.
Der Raspi ist nur per VPN erreichbar:
Entweder hat bereits der Router ein VPN eingebaut (Fritzboxen von AVM haben das z.B.) oder man nutzt einen VPN-Dienst wie z.B. Tailscale, mit dem sich verschiedene eigene Geräte in einem eigenen geschlossenen VPN verbinden lassen (Tailscale ist für Privatgebrach kostenlos und vergleichsweise einfach installierbar, nutze ich selbst. Da Tailscale immer auf meinem Notebook läuft, ist mein Raspi darüber immer erreichbar).
Mit dieser Methode kann nur ich b(bzw. alle, die ich ins gleiche VPN einlade) auf den Raspi zugreifen.
Obskure Port-Forwards einrichten:
Auf dem Router werden irgendwelche obskuren Ports geöffnet, die den Zugriff auf Ports auf dem Raspi ermöglichen. Ein böser Angreifer muss damit auf dem Router mindestens einen Portscan machen, um herrauszufinden, auf welchem Port man angreifbar sein könnte. Verwendet man nicht die Standardports der entsprechenden Programme, dann ist man rein statistisch etwas besser geschützt vor automatisierten Angriffen. Ist aber security by obscurity und man muss drauf vertrauen, dass die dadurch im Internet sichtbaren Dienste keine Schwachstellen besitzen und einigermassen gegen brute force Angriffe abgesichert sind.
Mit einem kostenlosen dynDNS-Dienst wird der eigene Router auch über eine stabile Adresse von aussen erreichbar (AVM bietet für die Fritzboxen so etwas kostenlos an).
Nachteil: Gewisse Firewalls (z.B. die meines Arbeitgebers) sperrt obskure Ports, so dass die Dienste dann doch nicht von überall her erreichbar sind.
Den https-Port forwarden:
Wenn der Standard-Port für https-Anfragen (443) am Router eingehende Anfragen an den Raspi weiterleitet, so ist der Raspi auch bei restriktiven Firewalls eher erreichbar. Umgekehrt ist aber auch die Wahrscheinlichkeit grösser, dass man Ziel automatisierten Drive-By-Attacken wird.

Wie mache ich es konkret?

Ich habe den Port 443 offen und dahinter läuft ein nginx Proxy-Server. Der schaut, anhand der Anfrage, welche Domain eine Anfrage erreichen will. Anfragen direkt auf die IP-Adresse laufen ins Leere. Damit hoffe ich, automatisierte IP-Scan-Angriffe etwas eindämmen zu können, da Angreifer wissen müssen, welche Domains auf meinem Raspi akzeptiert werden (sprich: IP-basierte Angriffe laufen ins Leere, DNS-basierte Angriffe erreichen ihr Ziel). Hier habe ich derzeit mehrere kostenlose dyndns-Adressen registriert und automatisiert mit einem Let's-Encrypt-Zertifikat versehen.

Nun wäge ich bei jedem Dienst zwischen Sicherheit und Bequemlichkeit ab:

Was ich von aussen einfach erreichen will:

Meine Fotosammlung
Meine Haussteuerung

Was ich nur via tailscale erreichbar gemacht habe:

Meine Dokumentenverwaltung (paperless-ngx)
Meine Duplicati-Backup-Dashboards
Mein nginx-Dashboard

Warum ich Tofu bei der Arbeit nicht mag

Beat Döbeli Honegger — 2026-02-05T17:55:34Z

Wenn ich auf meinem Computer nach meinen ältesten Mails (Biblionetz:w00498) suche, muss ich ins letzte Jahrtausend zurückgehen. Auf die Schnelle habe ich ein Mail gefunden, von dem nicht sofort klar ist, ob es jetzt von 1993, 1994 oder 1995 stammt:

Was aber sofort klar wird: Es ist lange, sehr lange her. (Hinweis sowohl für jüngere als auch ältere Menschen: Das war für mich noch vor dem Internet. Es handelt sich um das Mailboxnetzwerk FidoNet). Und es zeigt auch, wie ich damals gelernt, habe Mails zu schreiben. Dieser Zitierstil sorgt heute in meinem Arbeitskontext öfters für Verwirrung. Eine Betrachtung zu digitaler Zusammenarbeit, die ich in Jöran Muuß-Merholz' beiden empfehlenswerten Büchern zu digitaler Zusammenarbeit (Biblionetz:b08860 und Biblionetz:b08924) erstaunlicherweise nicht gefunden habe.

Ich wurde so mail- und newsgroup-sozialisiert, dass ich selektiv zitiere. Ich schreibe meine Antworten möglichst nahe zu einer Frage oder Aussage, die ich kommentieren möchte. Von früher her war ich mir gewohnt, dass Mailclients diese Arbeitsweise unterstützen, indem sie unterschiedliche Einrückungen automatisch farblich codieren. (Für Menschen, die das nicht selbst erlebt haben: Diese Farben stehen nicht in der Mail drin, die besteht aus reinem Text, sondern werden vom Mailclient bei der Anzeige der eigentlich schwarz/weissen Mail zur besseren Lesbarkeit eingesetzt). Der Fachbegriff für diese Zitationsweise heisst Inline-Quoting. Heute unterstützen Mailclients diese Zitierweise immer weniger.

Menschen, die später mail-sozialisiert wurden (und das Usenet gar nie erlebt haben), antworten auf Mails ganz anders. Sie schreiben einfach ihre Antwort oben an die erhaltene Mail hin, die dann nach unten rutscht, und schicken beides wieder an die Absenderadresse zurück. Dieser Zitierstil wird von Anhänger:innen des Inline-Quotings verächtlich als TOFU bezeichnet: Text Oben, Fullquote Unten.

In letzter Zeit habe ich von mehreren Kommunikationspartner:innen die Rückmeldung erhalten, dass sie meine Art, Mails zu beantworten, irritiert oder gar ihre Effizienz mindert: Es fehlt ihnen der Kontext, wenn ich darüber entscheide, was ich zurückschicke und was ich beim Beantworten lösche. Ich finde das spannend, denn aus meiner Sicht ist meine Art der Mailbeantwortung effizient für das Gegenüber und eigentlich eine Folge dessen, was Jöran Muuß-Merholz als Pre-Empathie (Biblionetz:w03655) bezeichnet: Ich überlege mir, was mein Gegenüber in Zukunft bei dieser Kommunikation für die weitere Arbeit noch benötigt, und lösche alles (aus meiner Sicht) Irrelevante (z.B. alle bisherigen Mails mitsamt ihren technischen Kopfzeilen und Signaturen).

Ich versuche eigentlich, die cognitive load beim Gegenüber zu senken, indem ich meine Antwort möglichst nahe zur Frage platziere. Ich versuche damit, einem grundlegenden Prinzip der Usability zu folgen: dem Gesetz der Nähe. Zudem: Ich hasse es, in einer längeren Kommunikation zigmal die ellenlangen Signaturen aller Beteiligten zu lesen (Besonders anstrengend bei interner Kommunikation, wenn mich die Mailsignatur mehrfach zu überzeugen versucht, doch an der der eigenen Hochschule ein Studium zu beginnen...). Wer den Kontext aufgrund meiner Kürzungen nicht mehr versteht oder etwas von früher nachschauen will, kann in meiner Überlegung problemlos im Thread einer Mailkommunikation nachschauen. Damit versuche ich dem Design-Prinzip Schrittweises Enthüllen zu folgen. (Diese und andere Designprinzipien sind im lesenswerten Buch Universal Principles of Design von William Lidwell, Kritian Holden und Jill Butler zu finden (Biblionetz:b02137)

Aber ich gebe zu, bei den Kürzungen besteht ein schmaler Grat zwischen willkommener Pre-Empathie und unwillkommener Übergriffigkeit, was ich dem Gegenüber vorenthalte.

Beim Recherchieren für dieses Posting bin ich darauf gestossen, dass TOFU einen eigenen Wikipedia-Artikel besitzt, der eigentlich das Schreiben eines eigenen Postings fast überflüssig gemacht hätte. Unter anderem steht da:

Hingegen ist etwa im geschäftlichen E-Mail-Verkehr TOFU eine weit verbreitete Form der Antwort. Hier würde das isolierte Zitieren und Kommentieren einzelner Sätze als ungewöhnlich empfunden.

[...]

Kritik an TOFU kommt meist beim Aufeinandertreffen von Benutzern dieses Zitierstils mit traditionellen Vertretern des Inline-Quotings (zum Beispiel im Usenet oder in Mailinglisten) auf. In traditionelleren Anwendungen des Internets hat sich im Laufe der Jahre das Inline-Quoting durchgesetzt. Es ist in zahllosen FAQs zur Netiquette ausführlich beschrieben. Unkenntnis oder Missachtung dieser einfachen Regeln durch Neulinge stößt zum Beispiel bei routinierten Usenet- oder Webforen-Benutzern auf Widerstand. Umgekehrt stößt die Kritik an TOFU dort auf Unverständnis, wo TOFU die übliche Form unkomplizierten Mailaustauschs zwischen Privatpersonen oder Firmen ist.

Inhaltlich dreht sich die Kritik um zwei Fragen, Reihenfolge und Umfang des Zitats. Bei TOFU kommt erst die zusammenhängende Antwort (Text oben), dann muss der Leser, sofern ihm der Bezug der Antwort nicht klar ist, die vollständige zitierte Originalmail nachlesen, um herauszufinden, worauf genau geantwortet wird. Andererseits fehlen einem Leser bei zu stark gekürztem Zitat mitunter für das (vollständige) Verständnis Informationen. Daher lehnen Kritiker das Nachlesen-Müssen ab, schätzen Befürworter aber das Nachlesen-Können. Beim Inline-Quoting sind Zitat und Antwort ineinander verwoben. Hier ist sofort nachvollziehbar, auf welche Aussagen sich die neuen Argumente beziehen. Bei längeren Inline-Zitaten muss der Benutzer unter Umständen nach unten scrollen. Bei TOFU muss nur nach unten geblättert werden, wenn der Kontext unklar ist.

…

Schön, somit weiss ich, dass meine Kommunikationspartner:innen und ich nicht alleine sind. Eine Lösung für dieses Aufeinandertreffen unterschiedlicher Kulturen haben wir damit aber noch nicht. Mit gewissen Kommunikationspartner:innen haben in den letzten Tagen beide Seiten versucht, das für sie ungewohnte Antwortschema zu nutzen. Beide Seiten berichten übereinstimmend: Es fühlt sich fremd und falsch an.

Darum: Wie kommen wir aus diesem Kommunikationsdilemma raus? Müssen erst alle Inline-Quoter aussterben - oder gibt es bessere Lösungen?