Pascal Garber – Logbuch

Ein neues jumplink.eu mit neuem Look

2026-10-30T00:00:00Z

Es war mal wieder Zeit für ein Redesign. Das alte Design war mir zu grau, zu textlastig und nicht mehr aktuell:

Der Look

Vom Pixelart-Look wollte ich mich nicht trennen, aber ich wollte mehr Farbe und Leben in die Seite bringen. Ich lebe in Cuxhaven, deshalb steht oben auf jeder Seite der Blick vom Deich: Himmel, Meer und am Horizont die Kugelbake, das Wahrzeichen der Stadt. Ist dein System auf den dunklen Modus gestellt, ist es Abend mit Mond und Sternen, sonst Tag.

Die Szene bewegt sich. Die Wellen laufen, tagsüber ziehen Containerschiffe, Kutter und Möwen vorbei, nachts Sternschnuppen und Flugzeuge. Wer in seinem System weniger Bewegung eingestellt hat, sieht stattdessen ein ruhiges Standbild.

Auf der Startseite stehe ich selbst als Pixelfigur vor dem Wasser. Die Figur ist mit KI entstanden, aber lokal auf meinem eigenen Rechner: mit ComfyUI, dem Modell FLUX.2 Klein 4B und der LoRA pixel-art-sprite_limbicnation.

Sonst bleibt die Seite ruhig: Text steht frei auf dem Hintergrund, fast ohne Kästen, gesetzt in Adwaita Sans, der Schrift von GNOME. Eine Pixelschrift gibt es nur noch für meinen Namen im Himmel. Ein paar Begriffe habe ich mir aus den Rollenspielen geliehen, die ich mag: Im Lebenslauf stehen Quests und Gegenstände, die Fähigkeiten bilden einen kleinen Fähigkeitenbaum, und der Blog heißt Logbuch.

Übrigens, ein kleiner Hinweis: Wer auf den Mond oder die Sonne klickt, wechselt zwischen Tag und Nacht. Vielleicht kommen mit der Zeit noch ein paar weitere kleine Spielereien dazu. :)

Die Seite setzt keine Cookies, hat kein Tracking und lädt nichts von fremden Servern. Die alte Seite bleibt im Repository unter dem Tag v2-riba erhalten.

Learn 6502 Assembly als GNOME-App

2026-10-29T00:00:00Z

Der 6502 ist der Prozessor von Commodore 64, NES und Apple II. Nick Morgans easy6502 ist ein Web-Tutorial, das seine Assemblersprache Schritt für Schritt erklärt. Daraus habe ich eine native GNOME-App gemacht: Learn 6502 Assembly.

Das steckt drin:

Ein interaktives Tutorial, das die Kernkonzepte durchgeht.
Ein Code-Editor mit Syntaxhervorhebung.
Ein Assembler und ein Debugger, die Register, Flags und Speicher zeigen, während der Code läuft.
Ein virtuelles Display, auf dem man das Ergebnis sieht und mit dem sich kleine Spiele und Grafiken bauen lassen.

Die App ist in TypeScript mit GJS und libadwaita geschrieben und wird mit gjsify gebaut. Das Repository enthält mehr als die Desktop-App: Assembler, Simulator und Disassembler stecken in einem eigenen Paket, @learn6502/core, und derselbe Code treibt auch eine Web-Version und eine Android-App an. Tutorial-Inhalte und Übersetzungen sind ebenfalls eigene Pakete, übersetzt wird auf Weblate.

Die App gibt es auf Flathub. Der Code steht unter GPL-3.0, der Tutorialtext unter CC BY 4.0, wie im Original.

Warum gjsify

2026-10-28T00:00:00Z

GNOME-Apps lassen sich in JavaScript schreiben. Die Laufzeit heißt GJS und basiert auf SpiderMonkey. GJS ist aber weder Node.js noch ein Browser: Es gibt kein node:fs, kein fetch, kein <canvas> und kein npm-Ökosystem. Viele Bibliotheken, ob HTTP-Client, Game-Engine oder Krypto-Bibliothek, setzen APIs voraus, die GJS nicht hat.

gjsify schließt diese Lücke. Es baut die Node.js-, Web- und DOM-APIs auf GNOMEs eigenen Bibliotheken nach:

Im Code	gjsify setzt es um auf
`node:fs`, `node:net`, `node:crypto`	Gio, GLib
`fetch`, `WebSocket`, `XMLHttpRequest`	Soup 3
`<canvas>` 2D und WebGL	Cairo, Gtk.GLArea
WebRTC, WebAudio, `<video>`	GStreamer
`node:sqlite`	libsqlite3

Damit stehen die Standard-APIs in GJS zur Verfügung. Bibliotheken, die für Node.js oder den Browser geschrieben wurden, laufen jetzt direkt unter GJS, ohne Browser-Engine und ohne Node.js-Laufzeit. Es gibt keinen Zwischenserver, kein mitgeliefertes Chromium und keinen Aufruf von Node. Heraus kommt eine echte GTK-4- und Adwaita-App, die sich als Flatpak ausliefern lässt und trotzdem die Sprache der übrigen JavaScript-Welt spricht.

Und andersherum

Wer lieber mit Node.js oder Bun arbeitet, kann das weiter tun. Dafür habe ich auch den umgekehrten Weg gebaut: Die GJS-APIs, also GTK, Adwaita und alles andere, was GObject Introspection anbietet, stehen auch unter diesen Laufzeiten zur Verfügung. So laufen alle nativen APIs unter allen Laufzeiten.

Und sie verhalten sich dort gleich. Das stelle ich mit Tests sicher: Dieselben Tests prüfen die Node.js-APIs, die Web-APIs, die GObject-Introspection-APIs und die GJS-Laufzeit-APIs auf jeder Laufzeit, und das Ergebnis muss überall genau dasselbe sein. Deshalb lässt sich die Laufzeit während der Entwicklung einfach wechseln, ohne den Code anzufassen.

Das öffnet auch andere Systeme: Mit gjsify lassen sich GJS-Apps für macOS und Windows ausliefern, als .app und .dmg beziehungsweise als Programmordner und .msi.

Was ich davon wollte

Zuerst nativ auf GNOME. GJS ist das Hauptziel.
Das Ökosystem, unverändert. Der Test ist, ob npm-Pakete so laufen, wie sie sind. Die Game-Engine Excalibur.js, WebTorrent, socket.io, three.js, axios und das Anthropic-MCP-SDK laufen über gjsify auf GJS, geprüft mit ihren eigenen Upstream-Tests.
Ein Quelltext, mehrere Laufzeiten. GJS, Node.js, Bun, der Browser und NativeScript. Jedes Paket gibt an, welche davon es erreicht, und der Build wählt die passende Implementierung.
Kein Node.js nötig. Installieren, Bauen, Starten, Testen, Veröffentlichen und der Flatpak-Schritt laufen auf GJS selbst.

Warum ich meine Apps so baue

TypeScript, das Web und sein Werkzeug kenne ich gut, und ich will GNOME-Apps schreiben, ohne das zu verlassen. ts-for-gir liefert mir Typen für GTK und jede andere introspektierbare Bibliothek, gjsify die APIs und die Werkzeugkette. Meine eigenen Apps wie Beifahrer, Steuererklärung und Learn 6502 Assembly sind der erste Test: Fehlt etwas, behebe ich es in gjsify, statt es in der App zu umgehen.

Der Code liegt auf GitHub, die Dokumentation auf gjsify.org.