Im Juli habe ich hier über meinen neuen Laptop geschrieben und dabei eine Sache besonders gelobt: den Kernel. 6.17 auf einer Ubuntu-24.04-Basis, deutlich frischer als alles, was dort hingehört. Dass ein kleiner Hersteller so etwas hebt, schien mir der eigentliche Mehrwert gegenüber „Ubuntu selbst installieren”.
Sechs Wochen später stand Maximilian Arnold, bei TUXEDO technischer Leiter für Qualitätssicherung und Installationen, auf der FrOSCon und erklärte, warum genau dieses Heben das Problem ist. Wer lange genug Pakete auf eine alternde Basis zurückportiert, baut irgendwann eine zweite Distribution gegen die erste. Man kämpft dann nicht mehr für die Aktualität, sondern gegen den Unterbau. Sein Satz von der Folie: „Stable heißt ein Stück weit auch bekannte Probleme.”
Die Antwort darauf ist ein Basiswechsel. TUXEDO OS zieht von Ubuntu nach Debian Testing um, und seit dem 16. August gibt es dafür eine offene Beta mit öffentlichem Fehler-Tracker. Ich hätte darüber schreiben können, was in der Ankündigung steht. Stattdessen habe ich die ISO geladen, eine virtuelle Maschine gebaut und nachgesehen – verschlüsselt installiert, 556 Updates eingespielt und das System anschließend mutwillig zerstört, um zu sehen, ob es wieder hochkommt.
Was sich in einer virtuellen Maschine beurteilen lässt, ist nicht das Gerät, sondern die Konstruktion darunter. Und die ist interessanter, als ich erwartet hatte.
Warum Debian die gute Nachricht ist
Der Wechsel klingt nach Geschmacksfrage, ist aber keine. Arnold beschreibt in seiner Antwort auf einen kritischen Einwand aus dem Publikum, worum es geht: nicht mehr über die LTS-Frage immer weiter vom Upstream wegzudriften, sondern „näher hingehen an Upstream”.
Das ist die Bewegung, die zählt. Eine Hersteller-Distribution kann auf zwei Arten Mehrwert schaffen: indem sie mehr selbst baut, oder indem sie weniger selbst bauen muss. System76 hat sich für den ersten Weg entschieden und mit COSMIC einen kompletten Desktop in Rust geschrieben. TUXEDO geht in die andere Richtung. Arnolds Formel für die eigenen Eingriffe lautet „so wenig wie möglich, aber so viel wie notwendig”.
Für jemanden, der ein Gerät gekauft hat, weil er einer Firma Geld geben wollte, deren Geschäft Linux ist, ist das die bessere Nachricht von beiden. Je weniger zwischen mir und dem Upstream steht, desto weniger kann sich zwischen uns schieben.
Dazu kommt ein Detail, das erst beim Nachlesen wirkt. Wer die alte Basis behält, landet auf dem offiziellen Upgrade-Pfad in Kubuntu 26.04 – und dort werde man, so Arnold, „unter anderem mit Snap-Paketen Vorlieb nehmen müssen”. TUXEDO OS bringt bis heute bewusst kein Snap mit. Wer beim Alten bliebe, bekäme also genau das zurück, wovon der Kauf einmal wegführen sollte. Der Wechsel nach Debian ist auch eine Entscheidung dagegen.
Zwei Partitionen, fünf Subvolumes
Die Installation nimmt Vorgaben, die ich durchweg übernommen habe. Was dabei entsteht, sieht so aus: genau zwei Partitionen. Eine knapp ein Gigabyte große EFI-Partition, und dahinter ein LUKS2-Container, der alles andere enthält. Keine separate /boot-Partition.
Darin liegt ein Btrfs mit fünf Subvolumes nach openSUSE-Muster – @, @home, @root, @var@log und @.snapshots, dazu ein eigenes .snapshots unterhalb von /home. Zwei Entscheidungen darin sind klüger, als sie aussehen. Dass die Logs ein eigenes Subvolume bekommen, heißt: Ein Rollback dreht sie nicht mit zurück. Wer ein kaputtes Update rückgängig macht, kann hinterher noch nachlesen, was schiefging. Und weil /home getrennt liegt, fasst ein Systemrollback keine Nutzerdaten an.
Nirgends erwähnt, aber überall aktiv: compress=zstd:3. Transparente Komprimierung als Vorgabe. Bei einem System, das vor und nach jeder Paketoperation Snapshots anlegt, ist das kein Detail, sondern der Grund, warum das Verfahren überhaupt tragbar bleibt. Nach Installation und 556 Updates waren 12 Prozent von 80 GB belegt.
Die eleganteste Stelle der ganzen Installation ist aber die, über die im Vortrag gar nicht geredet wurde.
Wie man eine Passphrase einmal tippt
Dass /boot mit im verschlüsselten Volume liegen darf, ist neueren GRUB-Versionen zu verdanken, die Argon2 beherrschen. Der Header bestätigt es: PBKDF: argon2id, 1 GiB Speicherhärtung pro Versuch, AES-XTS mit 512-Bit-Schlüssel.
Auffällig war etwas anderes. Bei der Installation habe ich eine Passphrase vergeben, im Header stehen aber zwei belegte Keyslots mit unterschiedlichen Parametern. Das sah zunächst nach einer Schwächung aus – ein zweiter Slot mit niedrigeren Kosten. Es ist das Gegenteil.
Slot 1 ist keine Passphrase, sondern eine Schlüsseldatei: 2048 Byte Zufall, eingebettet in die initramfs. Und die initramfs liegt, weil es keine separate /boot-Partition gibt, selbst im verschlüsselten Volume. Der Ablauf ist damit: GRUB fragt die Passphrase ab und entsperrt über Slot 0. Danach liest der Kernel die initramfs, findet dort die Schlüsseldatei und entsperrt über Slot 1. Man tippt genau einmal.
Ohne den Argon2-fähigen GRUB ginge das nicht. Dann läge die initramfs samt Schlüsseldatei unverschlüsselt auf der Platte, lesbar für jeden, der das Gerät in die Hand bekommt. Erst die Kombination beider Bausteine ergibt den Komfort. Das ist sauber gedacht – und es ist der Punkt, an dem ich beim Nachmessen zum ersten Mal beeindruckt war.
Wer für was bürgt
„Continuous Debian” nennt TUXEDO das Verfahren. Arnold beschreibt es knapp: „Wir haben also mit Debian Testing die Quelle, aber nicht daraus eine ungefilterte Auslieferung.” Zwischen Debian und dem Gerät sitzt eine Kontrollschicht, die täglich Unterschiede abgleicht und bei kritischen Paketen – Firmware, GRUB, systemd – manuell freigibt. Betroffen seien bis zu 30 Pakete am Tag. Der Grund für den Aufwand klingt nach Erfahrung: Der Integritätscheck sei „eine bitterböse Lehre” aus den Jahren als Ubuntu-Mirror-Betreiber.
Auf dem installierten System sind das sechs Paketquellen, verteilt auf drei Hosts – und kein einziger Eintrag zeigt auf deb.debian.org. Der Mirror ist also real, nicht bloß angekündigt.
Der schönste Befund des ganzen Nachmittags steht aber nicht in den URLs, sondern in den Signed-By-Zeilen:
| Quelle | Signiert mit |
|---|---|
mirrors.tuxedocomputers.com/debian | debian-archive-keyring.gpg |
alle txos.* und deb.tuxedocomputers.com | tuxedo-archive-keyring.gpg |
TUXEDO signiert die Debian-Pakete nicht um. Für Debian-Inhalte bleibt Debian die bürgende Instanz; der eigene Schlüssel deckt nur, was TUXEDO selbst baut. Wer prüfen will, ob ein Paket unterwegs verändert wurde, kann das an der ursprünglichen Signatur tun. Das ist eine bewusste Entscheidung gegen den bequemeren Weg, und sie ist genau die richtige.
Snapshots, die von selbst passieren
Das Versprechen lautet: vor und nach jeder Paketoperation ein Snapshot. Ich habe die erste große Aktualisierung absichtlich über die grafische Oberfläche laufen lassen, nicht über das Terminal – 556 Pakete, 2,4 GiB, gefahren von Discover.
Es hat funktioniert. Ein pre-Snapshot um 14:43:13, ein post-Snapshot um 14:48:13, sauber aneinandergebunden. Der Haken hängt an libapt und nicht am apt-Kommando, der grafische Updater fällt also nicht durch das Raster. Ein zweiter Durchlauf ohne zu erledigende Arbeit erzeugte kein Snapshot-Paar – der Auslöser reagiert auf tatsächliche Änderungen, nicht auf jeden Aufruf. Auch das ist mitgedacht.
Bei der Installation legt das System zusätzlich einen benannten Snapshot „Factory Image” an, markiert als wichtig und von der automatischen Aufräumung ausgenommen. Ein Werkszustand, zu dem man immer zurückkann. Im Vortrag kam er nicht vor.
Im GRUB-Menü taucht die ganze Sammlung als eigener Eintrag auf, nicht versteckt hinter „Advanced options”:
Alle Snapshots mit Datum, Typ und Beschreibung – direkt im Bootmenü auswählbar.
Eine Kuriosität steckt in der Beschreibungsspalte. Die beiden Snapshots des Discover-Laufs sind mit synaptic beschriftet – einem Programm, das an dieser Transaktion überhaupt nicht beteiligt war. Bei einem Kommandozeilen-Vorgang steht dort korrekt install +3 pkg. Das Feld folgt also dem Vorgang, nur beim grafischen Updater greift es daneben. Folgenlos, solange man es weiß. Wer allerdings vor einem Rollback anhand der Beschreibung entscheidet, worauf er zurückgeht, liest ein falsches Etikett.
Und weil sie im Vortrag zweimal fällt, hier auch: „Snapshots sind keine Backups.” Ein kaputter Systemzustand lässt sich damit zurückdrehen, eine kaputte Platte nicht.
Der Rollback, der nichts tat
Bis hierhin war es Nachlesen. Der eigentliche Test kam danach, und in einer VM darf man dafür grob werden: rm -rf /usr/lib/systemd /usr/bin/systemctl /sbin/init. Neustart. Das System bleibt hängen, wie es soll.
Der beworbene Weg funktioniert zunächst genau wie beschrieben. GRUB fragt die Passphrase ab, das Snapshot-Menü erscheint, ein intakter Stand bootet durch, das System ist voll benutzbar. Der Snapshot selbst ist schreibgeschützt – der Rettungsstand kann nicht versehentlich verändert werden. Auch das ist richtig gebaut.
Dann snapper rollback. Der Befehl läuft durch, legt die erwarteten Stände an, setzt das Standard-Subvolume um. Neustart – und die Maschine bootet wieder das kaputte System. Keine Fehlermeldung, kein Hinweis, dieselbe Störung wie zuvor. Für den Nutzer sieht der Rollback aus, als hätte er schlicht nichts getan.
Die Ursache liegt in TUXEDOs eigenem Paket tuxedo-btrfs 0.4.1-3-tux2, und sie ist bemerkenswert klein. Drei Zeilen. Ein Plugin für Snapper rechnet einen Pfad mit sed 's|@|/.|' um und produziert dabei //..snapshots statt /.snapshots, weil der vorhandene Punkt stehen bleibt. Ein zweites Skript lädt eine Konfigurationsdatei, die es nicht gibt – sie wurde offenbar umbenannt, ohne das Skript nachzuziehen. Im selben Skript fehlt einem Subvolume-Pfad der Punkt: @snapshots statt @.snapshots. Beide Skripte laufen unter set -e, also bricht jeder dieser Fehler den Vorgang für sich allein ab.
Ich habe anschließend von Hand nachgeholt, was die Skripte tun sollten – die fstab im Ziel korrigiert, das Ziel eingehängt, im chroot update-grub und grub-install. Ergebnis: Der Rollback funktioniert exakt wie versprochen. Konstruktion, Snapshot-Verwaltung, GRUB-Integration und Subvolume-Umschaltung sind alle in Ordnung. Kaputt sind drei Zeilen.
Genau deshalb gibt es Betas. Ich habe den Befund mit Reproduktion, Zeilennummern und je einem Einzeiler als Korrekturvorschlag als Issue #70 im offenen Tracker hinterlegt.
Die Antwort kam nach zwei Stunden
Und damit wird der Test zum zweiten Mal interessant, weil sich die eigentliche Frage erst jetzt stellt: Was passiert mit so einem Bericht?
Zwei Stunden später antwortete Torsten Wohlfarth, Entwickler bei TUXEDO. Zuerst mit einem Einwand – der Weg über snapper rollback sei gar nicht der vorgesehene, weil das hier kein openSUSE sei; dafür gebe es sudo tuxedo-rollback. Und dann, in einem zweiten Kommentar: „But thanks for your fixes, we will include them.”
Der Einwand stimmt. Es gibt dieses Kommando, es liegt als /usr/sbin/tuxedo-rollback auf jedem installierten System, und ich habe es schlicht nicht gefunden. Es ruft intern denselben snapper-Aufruf auf wie ich – erledigt den Bootloader-Teil danach aber über ein anderes Skript, das die drei gemeldeten Fehler nicht enthält. Der Weg, den ich getestet hatte, war nicht der vorgesehene.
Also habe ich die virtuelle Maschine noch einmal angeworfen und es richtig gemacht: zerstören, in einen intakten Snapshot booten, sudo tuxedo-rollback. Und diesmal arbeitet das Werkzeug sichtbar. Es legt eine Sicherung an, erzeugt die beschreibbare Kopie, patcht die fstab im Ziel, geht in ein chroot und schreibt den Bootloader neu. Am Ende meldet es: „Rollback completed successfully. You have to reboot immediately!”
Nach dem Neustart kam kein Bootmenü. Auch keine Passphrase-Abfrage. Es kam das hier:
GNU GRUB version 2.14-3
grub> _
Warum die Maschine stehenblieb
Die Ursache ließ sich an der GRUB-Kommandozeile direkt auslesen. Das Werkzeug hatte die EFI-Konfiguration neu geschrieben, und zwar so:
search --no-floppy --fs-uuid --set=root b023bf4f-017f-4de0-a7e5-90991345533c
set prefix=($root)/@.snapshots/9/snapshot/boot/grub
configfile $prefix/grub.cfg
Drei Zeilen, in denen eine fehlt. Die gesuchte Dateisystem-UUID liegt innerhalb des verschlüsselten Containers, und den hat GRUB an dieser Stelle noch gar nicht geöffnet. Also findet search nichts, $root bleibt auf der EFI-Partition stehen, und configfile greift ins Leere. Der Beweis dauerte einen Befehl:
grub> cryptomount -a
Enter passphrase for hd0,gpt2:
Slot "0" opened
grub> search --no-floppy --fs-uuid --set=root b023bf4f-…
grub> echo root ist $root
root ist crypto0
Vorher zeigte $root auf die EFI-Partition, nachher auf den entschlüsselten Datenträger – derselbe unveränderte search-Befehl, nur eben mit geöffnetem Container davor. Danach lud das Menü anstandslos, das System bootete durch, und der Zielzustand war vollständig korrekt: richtiges Subvolume, sauber gepatchte fstab, systemctl is-system-running meldet running. Der Rollback selbst hatte alles richtig gemacht. Nur der Weg dorthin war verstellt.
Wichtig ist die Einschränkung, ohne die dieser Befund falsch wird: Ich habe verschlüsselt installiert. Auf einem System ohne Verschlüsselung findet search sein Ziel ohne Umweg, und die drei Zeilen dürften genau so funktionieren, wie sie gedacht sind. Der Satz lautet also nicht „tuxedo-rollback ist kaputt”, sondern: es hinterlässt auf verschlüsselten Installationen eine Maschine, die nicht mehr von selbst startet. Dass ich Prüfpunkt B damals auf einer verschlüsselten Installation bestanden habe, war rückblickend die Entscheidung, die diesen Fehler überhaupt sichtbar gemacht hat.
Das ist unangenehmer als der erste Fund. Beim ersten tat der Rollback nichts – ärgerlich, aber der alte Zustand war noch da. Hier steht man vor einem grub>-Prompt und muss wissen, was cryptomount ist. Für ein Feature, dessen Zweck ausdrücklich ist, Leuten ohne tiefe Systemkenntnis einen Rückweg zu geben, ist das die falsche Stelle zum Straucheln.
Der Befund ist noch am selben Abend als Nachtrag in dasselbe Issue gewandert – mit Rohtext, mit der ausdrücklichen Einschränkung auf verschlüsselte Systeme und ohne Triumph. Denn er ändert nichts an dem, was mich an diesem Abend am meisten überzeugt hat: Ein Fremder installiert eine vier Tage alte Beta, zerlegt sie mutwillig, meldet drei Zeilen Code – und bekommt noch am selben Abend eine sachliche Antwort, einen berechtigten Einwand und die Zusage, die Korrekturen zu übernehmen. Genau das meint Arnolds Satz, Vertrauen entstehe, wenn der Prozess offen ist. Der Prozess war offen genug, dass sich der Einwand nachprüfen ließ – und dabei kam ein zweiter Fehler ans Licht, den ohne diesen Austausch niemand gesucht hätte.
Was noch im Bau ist
Zwei Dinge sind mir aufgefallen, die über eine kaputte Zeile hinausgehen – und beide gehören in den Zusammenhang gestellt, in den Arnold sie selbst gestellt hat.
Der installierte TUXEDO-Kernel 7.1.6.2-tuxedo-amd64 liegt in keinem Repository. apt policy führt als einzige Quelle den lokalen Paketstatus. Über die Paketverwaltung ist er damit nicht aktualisierbar, und die 556 Updates haben ihn folgerichtig nicht angefasst. Gleichzeitig steht Debians eigener Kernel in 7.1.8-1 auf TUXEDOs Spiegel bereit – also in der Version, die laut Issue-Tracker eine AMD-Grafikregression auf meinem eigenen Gerätetyp behebt.
Der zweite Punkt ist der Sicherheitskanal, und die Frage dahinter ist nicht neu: Schon im Juli, direkt nach der Ankündigung, hatte GNU/Linux.ch nachgehakt, wie ein Hersteller die Sicherheitsversorgung stemmen will, wenn Debian Testing anders als Ubuntu LTS kein garantiertes Sicherheitsarchiv mitbringt.
Ein eigener Kanal existiert inzwischen – und das ist an sich schon bemerkenswert, denn Debian Testing hat regulär nichts Vergleichbares. Zum Messzeitpunkt enthält er sechs Pakete, alle aus einer Quelle: flatpak, in derselben Version wie der reguläre Spiegel. Seine Metadaten stammen vom 13. August, also von drei Tagen vor dem Beta-Start.
Das klingt nach einer Lücke zwischen Anspruch und Wirklichkeit, ist aber eher eine Baustelle mit angeschlagenem Schild. Arnold hat in genau diesem Punkt keine fertige Zusage gemacht, sondern eine angekündigte: „Wir werden es innerhalb der Open Beta der Reihe nach aufziehen” – mit dem Ziel, am Ende sagen zu können, „was können wir denn uns wirklich zusagen”. Was ich gemessen habe, ist demnach nicht ein gebrochenes Versprechen, sondern der Zwischenstand eines angekündigten Aufbaus, vier Tage nach Beginn.
Bemerkenswert bleibt für mich etwas anderes: dass sich all das von außen nachmessen ließ, an einem Nachmittag, ohne Sonderzugang. Arnold sagt an einer Stelle, Vertrauen sei in einem Sicherheitskontext „ja nur da, wenn der Prozess offen ist”. Dass die Prüfung überhaupt möglich war, ist der beste Beleg für seinen Satz.
Firefox, VSCodium und die Sache mit Signal
Der Punkt, der mich beim Kauf am meisten interessiert hat, ist der unspektakulärste: ein System, das keine Werbung schiebt und nichts nach Hause funkt. Hier liefert die Beta am deutlichsten.
Der mitgelieferte Firefox bringt eine Richtlinien-Datei mit, die Telemetrie abschaltet, dazu die Normandy-Studien. Sieben KI-Funktionen stehen auf blocked, einschließlich des Sammeleintrags – also auch alles, was später dazukommt. Die Werbeinhalte auf der Neuer-Tab-Seite sind aus.
Zwei Vorgaben gehen über das Versprochene hinaus. Global Privacy Control ist aktiviert – das ist kein Weglassen, sondern ein aktives Datenschutzsignal an jede besuchte Seite. Und das Nachladen des OpenH264-Plugins von Cisco ist unterbunden, ein stiller Drittanbieter-Abruf weniger.
Am wichtigsten aber: Alle diese Einstellungen sind als Vorgaben gesetzt, nicht als Sperren. Jede lässt sich ändern. Das ist der Unterschied zwischen Datenschutz und Bevormundung, und TUXEDO steht auf der richtigen Seite davon.
VSCodium kommt wie zugesagt aus dem eigenen Repository, ohne Fremdquelle und ohne Microsoft-Telemetrie. Bei Signal stimmt die Zusage dagegen nicht ganz: signal-desktop existiert in keinem der sechs Archive. Der Weg dorthin führt über Flathub, das als System-Remote vorkonfiguriert ist.
Das ist kein Betrug, aber eine Verschiebung. Ein Drittanbieter-Repository im apt-Sinn braucht es tatsächlich nicht – dafür einen Drittanbieter-Dienst mit eigener Vertrauenskette, eigener Signierung und eigener Update-Strecke. Der Fremdanbieter verschwindet nicht, er wechselt die Ebene. Nebenbei erklärt das, warum ausgerechnet flatpak das einzige Paket im Sicherheitskanal ist: Wenn Flatpak der Auslieferungsweg für Fremdsoftware ist, ist es die sicherheitskritischste Komponente dieses Weges. Die Auswahl ist also nicht zufällig. Sie ist nur sehr klein.
Fazit
War der Nachmittag die Mühe wert? Ja – und zwar weil er das Gegenteil dessen ergeben hat, was ein Beta-Test üblicherweise ergibt. Nicht eine Liste von Ärgernissen, sondern ein System, dessen Aufbau durchdacht ist bis in Stellen hinein, über die niemand geredet hat: die Komprimierung, die Logs außerhalb des Rollbacks, die getrennten Signaturschlüssel, die Schlüsseldatei in der verschlüsselten initramfs. Das sind keine Marketingpunkte. Das sind die Entscheidungen von Leuten, die das Ding selbst benutzen wollen.
Und das Kaputte war überschaubar. Drei Zeilen in einem veralteten Skript, eine fehlende Zeile im neuen, ein falsches Etikett in einer Spalte, ein Kernel, der seinen Weg ins Repository noch nicht gefunden hat, und eine Dokumentation, die auf den älteren von zwei Wegen zeigt. Für eine Beta, die vier Tage alt ist, ist das eine gute Bilanz. Arnolds Bitte an sein Publikum lautete ausdrücklich: „bitte nutzt diese Open Beta nicht auf Produktivsystemen” – die VM war also nicht Vorsicht, sondern die vorgesehene Benutzung.
Am meisten hängengeblieben ist mir aber nicht, was ich gemessen habe, sondern was danach passiert ist. Zwei Stunden zwischen einem Fehlerbericht von einem Unbekannten und einer Antwort, die ihn ernst nimmt, ihm in einem Punkt widerspricht und die Korrekturen zusagt – das ist die Sorte Beleg, die sich nicht in einer Konfigurationsdatei nachlesen lässt. Dass der Widerspruch dann seinerseits einen Fehler zutage förderte, ist kein Argument gegen den Austausch. Es ist der Austausch.
Für wen lohnt sich das Hinschauen? Für alle, die ein TUXEDO-Gerät haben und wissen wollen, worauf ihr System im Frühjahr steht. Der Umstieg soll ohne Neuinstallation gelingen, und die alte Basis wird bis 2029 mit Sicherheitsupdates versorgt – Eile ist nicht geboten. Wer aber jetzt eine Stunde und eine virtuelle Maschine übrig hat, bekommt einen sehr genauen Eindruck davon, wohin die Reise geht.
Im Juli habe ich geschrieben, das Kontrast-Angebot von Apple habe die Frage geschärft: Wie viel ist mir Souveränität wert? Damals war die Antwort in Euro und Rechenleistung zu zahlen. Diesmal fällt sie leichter. Ein Hersteller, der seine eigene Zwischenschicht dünner macht statt dicker, der fremde Signaturen stehen lässt statt sie zu ersetzen, und der auf einen Fehlerbericht am selben Abend antwortet, beantwortet sie zu einem guten Teil selbst. Der Kernel 6.17, den ich im Juli gelobt habe, war ein Symptom. Debian ist die Behandlung.
Quellen
Vortrag und Berichterstattung
- Von Ubuntu zu Debian, ein neuer Upstream für TUXEDO OS – Maximilian Arnolds Vortrag auf der FrOSCon, 16.08.2026, 56 Minuten. Alle Zitate stammen von dort
- TUXEDO OS wechselt auf Debian Testing – Samuel Rüegger auf GNU/Linux.ch, Juli 2026: die Einordnung, die die Sicherheitsfrage aufgeworfen hat
Der Fehlerbericht
- Issue #70 – der gemeldete Rollback-Defekt mit Reproduktion, dazu der Nachtrag zu
tuxedo-rollbackauf verschlüsselten Systemen - Open-Beta-Tracker – der öffentliche Fehler-Tracker der Beta
Basis und Bausteine
- Debian – die neue Grundlage, bezogen als Testing über TUXEDOs eigenen Spiegel
- Btrfs – das Dateisystem, auf dem Subvolumes und Snapshots beruhen
- Snapper – die Snapshot-Verwaltung aus dem openSUSE-Umfeld, hier vor und nach jeder Paketoperation aktiv
- TUXEDO Computers – Hersteller von Gerät und Distribution
Anwendungen und Standards aus Prüfpunkt I
- VSCodium – der telemetriefreie VS-Code-Build, hier aus TUXEDOs eigenem Repository
- Signal – kommt nicht als Debian-Paket, sondern über Flathub
- Global Privacy Control – das Datenschutzsignal, das im mitgelieferten Firefox aktiviert ist
Zum Vergleich
- COSMIC – System76s Antwort auf dieselbe Frage: mehr selbst bauen statt weniger
Das Titelbild enthält das Debian Open Use Logo, © 1999 Software in the Public Interest, Inc., verwendet unter CC BY-SA 3.0 und für diese Illustration umgefärbt. „Debian” ist eine eingetragene Marke von Software in the Public Interest, Inc.
Getestet wurde die Open Beta vom 16. August 2026 (TUXEDO-OS-DEBIAN-202608131141.iso) in einer VirtualBox-VM mit UEFI, 8 GB RAM und Vollverschlüsselung. Alles, was Hardware betrifft – Lüftersteuerung, Akkulaufzeit, Suspend, Grafikstack –, lässt sich so nicht beurteilen und kommt in diesem Text bewusst nicht vor. Der erste Teil dieser Geschichte, die Kaufentscheidung, steht in Ein neuer Anfang auf Linux: Das Tuxedo InfinityBook Pro 14.