# OrientOS -- USB-Abbild, 12.09.2026 (zweiter Beleg) orientos-usb.img 136.314.880 Oktette (130 MiB), GPT, EFI 96 MiB + Wurzel 32 MiB SHA256 f47f85f5fccbe8d89ea66c6a8db21befc4f16b15a0411ff3542d85ceaedc50da auf den Stick: sudo dd if=orientos-usb.img of=/dev/sdX bs=4M conv=fsync status=progress Gebaut aus `main` in /root/osum-merge11, Commit `3ce22f3`. Der erste Beleg (SHA256 7c9e2ef5...) liegt daneben unter orientos-abbild/. ## Die zwei Punkte, die Justin im ersten Beleg noch gesehen hat ### (a) DEBUGZEILEN IM TERMINAL -- WEG, GEMESSEN Justins Befund am ersten Beleg: auf dunkel-05-kontrollzentrum.png standen im Terminalfenster Zeilen wie `explorer: krumm n=2 fold=0` und `bg=...`. Er hat auch gezaehlt: 160 `ulib.say` in taskbar.fi, 38 in explorer.fi. WARUM ES BEIM ERSTEN MAL NICHT GEREICHT HAT. Ich hatte nur `taskbar.say_text` hinter den Schalter gelegt -- EIN Ausgang von vielen. Die uebrigen ~200 Aufrufe liefen weiter, und deshalb war die Meldung danach immer noch im Bild. Diesmal an der Stelle, an der alle durchmuessen: jedes dieser Programme hat eine EIGENE `say()`-Huelle auf `ulib.say`. Die ist jetzt geschaltet, und `sayn()`/`nl()` stehen daneben, damit niemand mit `ulib.` daran vorbeikommt. taskbar 160 sayn + 64 nl umgehaengt explorer 38 sayn + 55 nl settings 47 sayn + 13 nl launcher 10 sayn + 20 nl desktop 13 sayn + 10 nl qs 57 sayn + 21 nl NICHT GELOESCHT, SONDERN GESCHALTET. Die Zaehler (`fui=`, `fuix=`, `rect id=`, `text ... base=`) waren mehrfach der Schluessel zur Fehlersuche und bleiben verfuegbar. Zwei Wege, sie einzuschalten, beide gab es schon: die Datei `/etc/uitrace` (mit der `wlib` seit Runde LOOK dasselbe tut) oder das Wort `debug` auf der Programmzeile. GEMESSEN, derselbe Lauf, night/dark, Zeilen auf der seriellen Leitung: ohne Schalter mit uitrace=yes taskbar: 0 38 explorer: 0 0 settings: 0 0 launcher: 0 17 desktop: 0 7 wlib: 0 17 UND IM BILD, das ist der Beweis, den Justin sehen wollte. Gezaehlt werden helle Bildpunkte rechts von Spalte 22 im Terminalfenster (x 24..584, y 40..420) -- links davon steht, was die Shell selbst schreibt, rechts stand der Schwall: ALT (erster Beleg, dunkel-05-kontrollzentrum.png) 13.213 NEU (dunkel-07-terminal-sauber.png) 1.141 Das sind 91 % weniger. Die verbliebenen 1.141 liegen ALLE in den Zeilen 64..94, also den ersten zwei Textzeilen, und sind der Startgruss der Shell (`osum`, mit der Mono-Schrift zu 92 % wiedergefunden) -- kein Programm-Mitschnitt. Gegenprobe mit `tools/usbimg/searchtext.py` im ganzen Bild: `wlib` NICHT gefunden (bester Wert 72 %), `krumm` NICHT gefunden (69 %), `taskbar:` NICHT gefunden (64 %), `explorer:` NICHT gefunden (63 %). Genau die Zeichenketten aus Justins Befund sind weg. ### (b) DER TOOLTIP UEBER DER UHR -- WEG, GEMESSEN Zuerst der Befund am ALTEN Bild, in Zahlen statt in Worten: Blase "no network" x 1140..1215 y 730..753 Taskleiste ab y 760 Uhr (Text ab x=1204) Tinte x 1205..1269 Die Blase stand also mit ihrem rechten Ende IN der Uhrenspalte. Meine Aussage der letzten Runde ("sechs Punkte Luft, kein Ueberlapp moeglich") war an einer 28 Punkte hohen Leiste gerechnet -- diese ist 40 hoch. Das war mein Fehler, und er ist der Grund, warum ich diesmal jede Zahl aus dem Bild nehme und nicht aus dem Quelltext. DIE PLATZIERUNG LIEGT JETZT IN fUi, nicht als Sonderfall in der Leiste: `wave2.tooltip_place`, Commit `e7cb0ec8` im Firn-Repo. Damit gilt sie fuer jeden, der eine Blase zeigt. Die Regel: bevorzugte Seite zuerst, bei Platzmangel KIPPEN statt klemmen (klemmen ist genau das, was eine Blase in die Leiste schiebt), waagrecht auf dem Zeiger zentriert und aus einer reservierten Spalte heraus. Was die Leiste beisteuert, sind die zwei Rechtecke, die nur sie kennt: ihr eigenes und das Uhrfeld. GEMESSEN am neuen Bild, dieselbe Ansicht, dieselbe Blase: ALT Blase x 1140..1215 ueberlappt die Uhr (ab 1205): JA NEU Blase x 1114..1189 ueberlappt die Uhr: NEIN Sie ist 26 Punkte nach links gewandert und endet 16 Punkte vor der Uhr. Sie steht jetzt genau ueber dem Netzsymbol (Tinte x 1166..1190), also ueber dem Ding, von dem sie spricht. ## Abnahme -- aus echten Laeufen Kern baut 6047 Symbole, 5.032.592 Oktette check-ui.sh PASSED (166 Dateien, 0/0/0, 14 begruendete Ausnahmen) Oberflaeche sechs Ansichten hell und dunkel, je `fehler=0` FARBTON night/dark PASSED, alle sechs Ansichten warme Punkte 0 von 1.494.439 = 0,00 % ### Helligkeit (mittlere Leuchtdichte 0..255) hell 245,2 241,9 240,8 241,0 240,4 242,9 dunkel 14,8 17,3 22,4 23,6 27,0 25,3 Zwei sauber getrennte Baender; keine Flaeche, die im dunklen Modus hell geblieben waere. ### fUi-Zaehler hell fui=715 fuix=4 fuig=40000 dunkel fui=717 fuix=4 fuig=40000 `fuig` zerlegt sich in `no_bereit=0, no_leer=4, no_band=0, no_art=0`: alle vier Ablehnungen sind Flaechen ohne Ausdehnung, die fUi zu Recht nicht malt. Kein Fall von "fUi war nicht bereit", keiner von "falsche Art". ### Die Marke taskbar: marke n=24 x=12 y=8 ink=301 (hell und dunkel identisch) Der Rueckfallweg im Symbolfont kommt in beiden Mitschnitten null mal vor. ## (c) DER fUi-PIN -- GEHOBEN `vendor/firn/COMMIT` stand auf `0e45acaf` (fUi 7963 Zeilen), jetzt auf `e7cb0ec8` (8822 Zeilen + `tooltip_place`). Der Sprung geht ueber `55497b7f`, den Stand mit der Text-Erweiterung: Buchstabenabstand, Zeilenhoehe, Wortabstand, Kerning an/aus, echtes Fett und Kursiv aus dem Style, Umriss, Schatten, Verlauf. Der fuer uns wichtige Teil ist nicht die Liste, sondern `advance_of`: `text_width`, `text_fits_upto` und `text` rechnen jetzt ueber EINE gemeinsame Stelle statt in drei Kopien -- genau die Bauart, an der in Welle 3 der abgeschnittene Dateiname entstanden ist. NACHGEZOGEN UEBER `fetch-firnc.sh`, nicht von Hand. `vendor/firn/lib/` ist gitignored und wird aus `COMMIT` neu ausgepackt; eine Handaenderung waere beim naechsten Aufruf spurlos weg. Genau deshalb steht `tooltip_place` im fUi-Repo und nicht im Osum-Baum -- ich habe es einmal falsch herum probiert, und der naechste `--force`-Lauf hat es gelaeutert: die Datei war weg. WAS SICH MESSBAR AENDERT, mit Zahlen statt mit Gefuehl: Symbole 6047 -> 6047 (gleich) Symbolzeilen 73444 -> 73446 (+2) Abbild 5.032.576 -> 5.032.592 Oktette (+16) check-ui.sh PASSED -> PASSED alle sieben Programme mit Oberflaeche uebersetzen unveraendert Zeilenmessung Balken 227,5 / Text 226,5 -- vorher wie nachher Der Uebersetzer selbst wechselt mit (76 Dateien, +10.964 Zeilen in `compiler/`), deshalb ist er neu gebaut und die ganze Abnahme neu gefahren worden, nicht nur der Kern. ## Offen * UEFI: der Kern startet (kein Textmodus-Abbruch), aber `hwdiag` meldet die Firmware als `?` statt `UEFI` und nennt keinen Rahmenpuffer. Ein Loch im BERICHT, nicht im Start. Vorbestehend. * `launcher: name [Search]`: der Name kommt aus `assets/apps/launcher.osp/INFO`, und ein Programmbuendel hat keine sprachabhaengige Fassung. Vorbestehend seit `c101990`. * `kein Netz` wird im Bild nicht gefunden, weil die Leiste ohne Netzkarte keinen Statusbereich zeichnet -- der Pruefabschnitt sucht Text, der nicht dasteht. * `tools/design/capture.sh` braucht `uitrace=yes`, weil `drive.py` seine Klickziele aus den `rect`-Zeilen liest. Die sechs Ansichten dieses Belegs sind deshalb MIT Schalter aufgenommen; der Beweis fuer das stille Terminal ist `dunkel-07-terminal-sauber.png` aus `tools/look/shot.sh` OHNE Schalter. Sauberer waere, wenn `drive.py` seine Ziele aus dem Fensterserver statt aus dem Mitschnitt naehme -- das ist der naechste Schritt, nicht dieser.