Hardware-Erkennung

Ein herkömmliches Installationsprogramm bietet Ihnen dieselben Dialoge an, unabhängig davon, ob Ihr Laptop eine Intel-iGPU oder eine NVIDIA-Karte hat, ob Sie auf physischer Hardware oder in einer VM arbeiten und ob Ihre CPU von RETBleed betroffen ist oder nicht. Es wird erwartet, dass Sie das wissen.

Ditana passt die Dialoge an Ihre Hardware an. Entscheidungen, die Sie nicht brauchen, werden ausgeblendet oder mit sicheren Voreinstellungen vorbelegt; Entscheidungen, die Sie tatsächlich brauchen, erscheinen mit sinnvollen Empfehlungen.

Das Prinzip der Erkennung

Alle Abfragen, die die Wissensbasis speisen, stehen in einer einzigen Datei: hardware-detection.kdl. Jeder Detektor ist eine Zeile Raku, die einmal beim Start des Installationsprogramms läuft und dem Rest der Wissensbasis einen Wert bereitstellt – meist einen booleschen Wert. Abfragen, die mehr als eine Zeile brauchen, befinden sich in der Engine des Installationsprogramms: Dort wird die Grafikkarte mit den Listen abgeglichen, die NVIDIA veröffentlicht, und dort werden auch das NVMe-Blockformat, rotierende Datenträger und die EFI-Partition ermittelt.

Einige typische Beispiele aus der aktuellen Datei:

- name="uefi" \
  detect="'/sys/firmware/efi'.IO.e"

- name="intel-cpu" \
  detect="'/proc/cpuinfo'.IO.lines.first(* ~~ /vendor_id/).contains('GenuineIntel')"

- name="virtual-environment" \
  detect="run('systemd-detect-virt', '-q').exitcode eq 0"

- name="is-retbleed-vulnerable" \
  detect="given '/sys/devices/system/cpu/vulnerabilities/retbleed'.IO
            { .e && .slurp.chomp ne 'Not affected' }"

Jeder liest aus /sys/ oder /proc/ oder ruft über die Shell ein Standardwerkzeug auf – keine proprietäre Hardware-Abstraktionsschicht, keine undurchsichtige Datenbank. Wenn Sie wissen möchten, was Ditana erkennt und wie, passt die Antwort auf einen Bildschirm, und Sie müssen die Datei dafür nicht verlassen.

Von der Erkennung zur Entscheidung

Detektoren handeln nicht selbst. Sie stellen Werte bereit, auf die andere Einstellungen in ihren Ausdrücken in default-value oder available verweisen. Die Kette lautet immer: erkennen → entscheiden → installieren.

Ein anschauliches Beispiel sind die Schutzmassnahmen gegen CPU-Schwachstellen. Jede vom Kernel gemeldete Schwachstelle (Spectre v2, Meltdown, MDS, TAA, MMIO Stale Data, L1TF, RETBleed, SRSO, GDS, RFDS) hat einen eigenen Detektor. Die zugehörige Einstellung für die Schutzmassnahme verweist dann als Standardwert auf diesen Detektor:

- name="kernel-option-retbl" \
  dialog-name="CPU Vulnerability Mitigation Options" \
  short-description="Enforce Retbleed Mitigation (retbleed=auto,nosmt)" \
  default-value="`is-retbleed-vulnerable`"

Ist Ihre CPU nicht betroffen, ist das Kontrollkästchen zunächst nicht aktiviert. Ist sie betroffen, ist es zunächst aktiviert. Nach CPU wird nichts gefiltert: Jede Schutzmassnahme wird in jedem Fall aufgeführt, sodass Sie auch sehen, was Ihre CPU laut der Erkennung nicht braucht. Das Einzige, was sie tatsächlich aus dem Dialog entfernt, ist die Wahl von mitigations=off, die jede von ihnen sinnlos macht – siehe wie Einstellungen voneinander abhängen. Die vollständige Begründung für jede einzelne Schwachstelle finden Sie auf der Seite CPU-Schutzmassnahmen.

Fallstudie: Wayland-Kompatibilität

Manche Erkennung braucht weniger naheliegende Quellen. Moderne Wayland-Compositors wie Niri brauchen zwingend 3D-Hardwarebeschleunigung – Software-Rendering (llvmpipe, softpipe) genügt nicht; der Compositor stürzt ab oder verweigert den Start.

Statt anhand des GPU-Herstellers zu raten, fragt Ditana den Kernel, welcher DRM-Treiber für das Rendering-Gerät tatsächlich aktiv ist:

- name="has-wayland-compatible-gpu" \
  detect="given dir('/sys/class/drm').grep(*.basename.starts-with('renderD')).first
            { $_ ?? ($_ ~ '/device/driver').IO.resolve.basename
                    ~~ any(<amdgpu radeon i915 xe nvidia nouveau virtio-pci virtio_gpu>)
                  !! False }"

Steht der Treiber Ihres Systems nicht auf dieser Liste – vmwgfx unter VMware, hyperv_fb unter Hyper-V, bochs-drm in manchen QEMU-Konfigurationen –, ergibt has-wayland-compatible-gpu den Wert False. Die Option Niri verschwindet aus der Auswahl der Desktop-Umgebung, und Ghostty (das OpenGL 4.3+ braucht, was Software-Rasterizern nicht zur Verfügung steht) ist nicht mehr verfügbar:

- name="install-ghostty" \
  available="`install-desktop-environment AND has-wayland-compatible-gpu`"

Ein Detektor, mehrere Einstellungen, die ihn nutzen. Eine an Hardware geknüpfte Option später hinzuzufügen, ist meist eine einzige Änderung im Feld available der nutzenden Einstellung – an der Erkennungslogik muss nichts geändert werden.