Πώς έφτιαξα το ThinkPad T480 μου ως πλήρως declarative NixOS σύστημα

Πρόλογος

Υπάρχουν στιγμές που ένα Linux setup παύει να είναι απλώς «η εγκατάσταση που έχω στον υπολογιστή μου» και γίνεται κάτι πιο προσωπικό. Κάτι σαν τεχνικό ημερολόγιο, εργαλείο δουλειάς, πειραματικό εργαστήριο και backup plan μαζί.

Αυτό ακριβώς έγινε με το ThinkPad T480 μου.

Το συγκεκριμένο laptop δεν είναι τυχαίο για εμένα. Είναι το μηχάνημα που έχω δουλέψει, πειράξει, στήσει και ξαναστήσει αρκετές φορές. Έχει Libreboot, δουλεύει σε legacy BIOS/SeaBIOS περιβάλλον, και για αρκετό καιρό ήταν στημένο με Guix. Το Guix το εκτιμώ πολύ. Έχει καθαρή φιλοσοφία, Scheme, ωραία λογική και πολύ ισχυρή άποψη για το τι σημαίνει αναπαραγώγιμο σύστημα.

Όμως κάποια στιγμή ήθελα να πάω ένα βήμα παραπέρα πρακτικά: να έχω ένα πλήρες καθημερινό workstation, με KDE Plasma 6, ελληνικό/αγγλικό πληκτρολόγιο, themes, panel, shortcuts, εφαρμογές, scripts, εργαλεία ανάπτυξης, λίγα AI εργαλεία, ήχο, containers, διαδικασία επαναφοράς και οδηγίες ανάκτησης, όλα δηλωμένα σε αρχεία.

Όχι «κρατάω σημειώσεις τι έκανα». Όχι «τρέχω ένα script που αντιγράφει ρυθμίσεις από εδώ κι από εκεί». Όχι «άμα χαλάσει θα θυμηθώ».

Ήθελα κάτι πιο δυνατό:

Έχω ένα private repo.
Έχω ένα USB stick με NixOS installer.
Έχω το T480.

Από αυτά και μόνο μπορώ να ξαναχτίσω ΟΛΟ το σύστημα.

Και αυτό τελικά κατάφερα με NixOS, flakes, Home Manager, plasma-manager και αρκετή επιμονή.

Τι εννοώ όταν λέω πλήρως declarative

Η λέξη «declarative» ακούγεται πολλές φορές λίγο θεωρητική. Στην πράξη, για το δικό μου setup σημαίνει κάτι πολύ συγκεκριμένο:

Δεν σκέφτομαι το σύστημα ως μια σειρά από χειροκίνητα βήματα. Το σκέφτομαι ως περιγραφή κατάστασης.

Δηλαδή δεν λέω:

sudo apt install αυτό
flatpak install εκείνο
άνοιξε KDE settings
πάτα εδώ
διάλεξε theme
κατέβασε model
φτιάξε shortcut
αντέγραψε script

Αντίθετα, λέω:

Το σύστημα πρέπει να έχει αυτά τα packages.
Το desktop πρέπει να έχει αυτό το theme.
Το keyboard πρέπει να έχει us και gr.
Το Caps Lock πρέπει να αλλάζει layout.
Το Plasma panel πρέπει να έχει αυτούς τους launchers.
Το shortcut Shift+Meta+V πρέπει να τρέχει το VoxTyper.
Το whisper model πρέπει να υπάρχει στο σωστό path.
Τα scripts μου πρέπει να εμφανίζονται στο ~/scripts.

Και μετά το εφαρμόζω με ένα rebuild:

sudo nixos-rebuild switch --flake ~/dev/guix-2-nix#t480

Αυτό είναι το σημείο που λες: «ωραία, τώρα ο υπολογιστής είναι όντως περιγεγραμμένος ως κώδικας».

Το ακόμα πιο ωραίο είναι ότι αυτό δεν αφορά μόνο το βασικό λειτουργικό. Αφορά και το περιβάλλον του χρήστη. Δηλαδή το Home Manager τρέχει μέσα από το ίδιο NixOS flake, οπότε το ίδιο rebuild εφαρμόζει μαζί τις ρυθμίσεις συστήματος και τις ρυθμίσεις χρήστη.

Γιατί NixOS μετά από Guix

Το Guix με βοήθησε να σκεφτώ σωστά. Με έβαλε στη νοοτροπία ότι το σύστημα δεν πρέπει να είναι μια μαύρη τρύπα από χειροκίνητες αλλαγές. Μου άρεσε και μου αρέσει η καθαρότητα του μοντέλου του.

Όμως στην καθημερινότητα ήθελα κάτι πιο βολικό για το συγκεκριμένο laptop και τον συγκεκριμένο τρόπο που δουλεύω στο desktop. Το NixOS μου έδωσε:

• τεράστιο οικοσύστημα πακέτων στο nixpkgs,
• flakes για καθαρό «κλείδωμα» των εκδόσεων των inputs,
• Home Manager για ρυθμίσεις χρήστη,
• plasma-manager για KDE Plasma 6 ρυθμισμένο από αρχεία,
• πολύ καλή υποστήριξη για Plasma/Wayland,
• εύκολη ενσωμάτωση custom derivations,
• δυνατό rollback μέσω generations,
• και ένα πιο πρακτικό μονοπάτι για να επαναφέρω ολόκληρο workstation.

Το σημαντικό για εμένα δεν ήταν να «αλλάξω distro». Ήταν να πετύχω ένα επίπεδο αναπαραγωγιμότητας που να πιάνει το πραγματικό μου desktop, όχι μόνο το /etc.

Με το Guix είχα ήδη την ιδέα. Με το NixOS κατάφερα να την κάνω ολοκληρωμένο καθημερινό σύστημα.

Το hardware: ThinkPad T480 με Libreboot

Το μηχάνημα για το οποίο είναι φτιαγμένο όλο αυτό είναι ένα Lenovo ThinkPad T480. Στην περίπτωσή μου δουλεύει με Libreboot/SeaBIOS, άρα η εγκατάσταση γίνεται με legacy BIOS και όχι με UEFI.

Αυτό έχει σημασία, γιατί η εγκατάσταση δεν είναι η κλασική «EFI partition και systemd-boot». Το setup μου είναι:

• legacy BIOS boot,
• GRUB,
• μικρό bios_grub partition,
• ξεχωριστό /boot,
• LUKS2 για encrypted root,
• Btrfs subvolumes,
• NixOS 26.05,
• KDE Plasma 6 σε Wayland.

Το disk layout που χρησιμοποιώ είναι περίπου έτσι:

/dev/nvme0n1p1   1 MiB    bios_grub
/dev/nvme0n1p2   1 GiB    ext4  /boot
/dev/nvme0n1p3   rest     LUKS2 -> Btrfs

Btrfs subvolumes:
  @      -> /
  @home  -> /home
  nix    -> /nix

Το repo ως πηγή αλήθειας

Η καρδιά του setup είναι ένα private git repo. Το κρατάω private γιατί περιέχει και πράγματα που δεν πρέπει να κυκλοφορούν δημόσια, όπως SSH-related restore υλικό. Στο άρθρο δεν θα βάλω τέτοια δεδομένα. Αυτό που έχει σημασία είναι η αρχιτεκτονική.

Η βασική δομή είναι:

guix-2-nix/
├── flake.nix
├── hosts/
│   └── t480/
│       ├── default.nix
│       └── hardware.nix
├── modules/
│   ├── boot.nix
│   ├── locale.nix
│   ├── desktop-plasma.nix
│   ├── networking.nix
│   ├── services.nix
│   ├── containers.nix
│   ├── filesystems.nix
│   └── nix-settings.nix
├── home/
│   └── lef/
│       ├── home.nix
│       ├── plasma.nix
│       ├── shell.nix
│       ├── scripts.nix
│       ├── ssh.nix
│       ├── git.nix
│       ├── cursor.nix
│       └── fonts-themes.nix
├── packages/
│   ├── voxtyper.nix
│   ├── whisper-model.nix
│   ├── ngrok.nix
│   ├── opencode-bin.nix
│   ├── dracula-sddm.nix
│   ├── dracula-cursors.nix
│   ├── penrose-splash.nix
│   └── wttr-athens-plasmoid.nix
├── install/
│   ├── INSTALL.md
│   ├── flash-nixos-usb.sh
│   ├── partition-legacy-luks-btrfs.sh
│   ├── mount.sh
│   └── merge-hardware.sh
├── scripts/
│   ├── reconf.sh
│   ├── re-nh.sh
│   ├── verify-setup.sh
│   ├── verify-keyboard.sh
│   ├── verify-audio.sh
│   └── sec-audit.sh
├── docs/
│   └── REPRODUCE.md
├── notes/
└── archive/
    └── flatpak-reference/

Το flake.nix είναι το κεντρικό σημείο εκκίνησης. Εκεί δηλώνω τα inputs:

• nixpkgs από NixOS 26.05,
• home-manager,
• plasma-manager.

Και από εκεί χτίζεται το nixosConfigurations.t480.

Αυτό είναι σημαντικό: δεν έχω ξεχωριστό χειροκίνητο βήμα για το Home Manager. Το Home Manager είναι module μέσα στο NixOS configuration. Άρα το ίδιο nixos-rebuild switch ενεργοποιεί και το περιβάλλον του χρήστη.

Markdown map: πώς συνδέονται τα Nix αρχεία

Αυτό είναι το νοητικό μοντέλο που με βοήθησε περισσότερο. Όταν το δεις έτσι, το NixOS setup παύει να μοιάζει «μαγικό» και γίνεται μια καθαρή αλυσίδα δηλώσεων: ποιο αρχείο εισάγει ποιο module, ποια ρύθμιση επηρεάζει ποιο κομμάτι του συστήματος και πώς όλα καταλήγουν στο τελικό desktop.

flake.nix
  |
  |-- inputs
  |     |-- nixpkgs        -> πακέτα NixOS και system modules
  |     |-- home-manager   -> περιβάλλον χρήστη ως NixOS module
  |     '-- plasma-manager -> ρυθμίσεις KDE Plasma μέσω Home Manager
  |
  '-- nixosConfigurations.t480
        |
        |-- hosts/t480/hardware.nix
        |     |-- disk UUIDs
        |     |-- btrfs mounts
        |     |-- kernel modules
        |
        |-- hosts/t480/default.nix
        |     |-- hostname t480
        |     |-- χρήστης
        |     |-- εισάγει τα modules/*.nix
        |     '-- system.stateVersion
        |
        |-- modules/boot.nix
        |     |-- GRUB legacy BIOS
        |     '-- επιλογές εκκίνησης
        |
        |-- modules/locale.nix
        |     |-- en_US + el_GR locales
        |     |-- timezone Europe/Athens
        |     '-- XKB us,gr + Caps Lock toggle
        |
        |-- modules/desktop-plasma.nix
        |     |-- Plasma 6
        |     |-- SDDM Dracula
        |     |-- PipeWire
        |     |-- rtkit
        |     '-- XDG portals
        |
        |-- modules/networking.nix
        |     |-- NetworkManager
        |     '-- Tailscale
        |
        |-- modules/services.nix
        |     |-- OpenSSH
        |     |-- printing
        |     |-- avahi
        |     '-- power profiles
        |
        |-- modules/containers.nix
        |     '-- Podman + Docker compatibility
        |
        '-- home-manager.users.<user>
              |
              '-- home/lef/home.nix
                    |
                    |-- εισάγει τα home modules
                    |     |-- plasma.nix
                    |     |-- shell.nix
                    |     |-- scripts.nix
                    |     |-- ssh.nix
                    |     |-- git.nix
                    |     |-- cursor.nix
                    |     '-- fonts-themes.nix
                    |
                    |-- home.packages
                    |     |-- native nixpkgs εφαρμογές
                    |     |-- εργαλεία ανάπτυξης
                    |     |-- KDE/GTK themes
                    |     '-- δικά μου packages από packages/*.nix
                    |
                    |-- home.file
                    |     |-- dotfiles
                    |     |-- scripts
                    |     |-- whisper model
                    |     '-- αρχεία/πόροι χρήστη
                    |
                    |-- home.activation
                    |     |-- εφαρμογή theme
                    |     |-- προσθήκη pager
                    |     '-- προσθήκη wttr widget στο panel
                    |
                    '-- systemd.user.services / timers
                          |-- random wallpaper
                          '-- υπηρεσίες εργαλείων σε επίπεδο χρήστη

archive/flatpak-reference/
  |
  '-- παλιό υλικό μετάβασης/αναφοράς
        |-- δεν εφαρμόζεται στο νέο σύστημα
        |-- δείχνει τι υπήρχε πριν ως Flatpak
        '-- βοηθάει να θυμάμαι τι αντικαταστάθηκε από native Nix packages

Και αν το δούμε ως ροή εφαρμογής:

nixos-rebuild switch --flake .#t480
  |
  |-- διαβάζει flake.lock και nixpkgs
  |-- χτίζει το νέο NixOS σύστημα
  |-- εφαρμόζει boot, services, users, Plasma system packages
  |-- ενεργοποιεί Home Manager για τον χρήστη
  |-- εγκαθιστά home.packages
  |-- γράφει dotfiles μέσω home.file
  |-- περνάει KDE config μέσω plasma-manager
  |-- τρέχει activation hooks
  '-- δημιουργεί νέα generation για rollback

Αυτό είναι το πιο ωραίο σημείο του NixOS για εμένα. Το σύστημα δεν είναι «ένα install». Είναι μια σειρά από immutable generations που μπορώ να αλλάξω, να δοκιμάσω και να γυρίσω πίσω.

Η επαναφορά από USB stick

Ένα από τα πράγματα που ήθελα από την αρχή ήταν να μπορώ να επαναφέρω το laptop από το μηδέν.

Όχι απλώς να κρατάω backup των αρχείων μου. Να μπορώ να πάρω ένα άδειο δίσκο, ένα NixOS installer USB και το repo, και να φτάσω πάλι σε λειτουργικό desktop.

Τη διαδικασία εγκατάστασης την έχω χωρίσει σε φάσεις.

Phase 0: NixOS installer USB
  -> partition disk
  -> setup LUKS + Btrfs
  -> mount filesystems
  -> clone/copy repo
  -> generate hardware config
  -> merge UUIDs into flake
  -> nixos-install --flake .#t480

Phase 1: πρώτη εκκίνηση
  -> set user password if needed
  -> ./setup.sh --apply
  -> reboot

Phase 2: έλεγχος
  -> ./setup.sh --finish
  -> verify keyboard
  -> security/audio checks

Το πρώτο script είναι καταστροφικό, όπως πρέπει να είναι ξεκάθαρο:

DISK=/dev/nvme0n1 bash install/partition-legacy-luks-btrfs.sh

Αυτό φτιάχνει partitions, LUKS και Btrfs subvolumes.

Μετά:

DISK=/dev/nvme0n1 bash install/mount.sh

Και μετά το σημαντικό NixOS κομμάτι:

nixos-generate-config --root /mnt
bash install/merge-hardware.sh /mnt/etc/nixos/hardware-configuration.nix
nixos-install --flake /mnt/home/<user>/dev/<repo>#t480

Στο πραγματικό άρθρο δεν χρειάζεται να βάλω τα δικά μου UUIDs. Αντίθετα, θα το δείξω έτσι:

# [PLACEHOLDER ΚΩΔΙΚΑ: καθαρισμένο hosts/t480/hardware.nix]
{
  fileSystems."/" = {
    device = "/dev/disk/by-uuid/<BTRFS-UUID>";
    fsType = "btrfs";
    options = [ "compress=zstd" ];
  };

  fileSystems."/home" = {
    device = "/dev/disk/by-uuid/<BTRFS-UUID>";
    fsType = "btrfs";
    options = [ "subvol=home" "compress=zstd" ];
  };
}

Το merge-hardware.sh είναι ένα από αυτά τα μικρά scripts που δεν είναι εντυπωσιακά, αλλά σου λύνουν τα χέρια. Παίρνει τα UUIDs από το generated hardware config και τα περνάει στα σωστά αρχεία του repo. Έτσι δεν μένω να κάνω copy-paste UUIDs μέσα στη βιασύνη του installer.

Το setup.sh δεν εγκαθιστά «πράγματα». Καλεί το flake.

Ένα σημείο που το θεωρώ σημαντικό: το setup.sh δεν είναι το κλασικό bootstrap script που πάει και κάνει δέκα άσχετα πράγματα με χειροκίνητο τρόπο.

Δεν κάνει flatpak install. Δεν κατεβάζει themes με curl στο home. Δεν αντιγράφει τυχαία dotfiles. Δεν πατάει ρυθμίσεις του KDE με το ζόρι.

Το βασικό του job είναι να τρέξει:

sudo nixos-rebuild switch --flake "$REPO_DIR#t480"

και μετά να κάνει verification.

Αυτό για εμένα είναι σωστό design. Αν κάτι λείπει, δεν το «φτιάχνω με script». Το προσθέτω στο σωστό .nix αρχείο και ξαναχτίζω.

KDE Plasma 6, αλλά ρυθμισμένο από αρχεία

Εδώ είναι ένα σημείο που νομίζω θα ενδιαφέρει αρκετό κόσμο.

Το KDE είναι παραδοσιακά ένα desktop που το ρυθμίζεις με το ποντίκι. System Settings, κλικ, dropdowns, themes, shortcuts, panels, window rules. Αυτό είναι βολικό, αλλά έχει ένα πρόβλημα: μετά δεν ξέρεις τι ακριβώς άλλαξες.

Με το plasma-manager κατάφερα να δηλώσω μεγάλο μέρος του Plasma setup σε Nix αρχεία.

Στο δικό μου plasma.nix δηλώνω πράγματα όπως:

• cursor theme,
• icon theme,
• splash screen,
• window decorations,
• keyboard layouts,
• locale formats,
• virtual desktops,
• KWin rules,
• global shortcuts,
• top panel,
• default browser,
• VoxTyper shortcut.

Ένα απλοποιημένο παράδειγμα:

# [PLACEHOLDER ΚΩΔΙΚΑ: καθαρισμένο home/<user>/plasma.nix]
programs.plasma = {
  enable = true;

  workspace = {
    cursor = {
      theme = "Dracula-cursors";
      size = 24;
    };
    iconTheme = "Dracula";
    splashScreen = {
      engine = "KSplashQML";
      theme = "Illusion";
    };
    windowDecorations = {
      library = "org.kde.kwin.aurorae.v2";
      theme = "__aurorae__svg__Monochrome";
    };
  };

  input.keyboard = {
    layouts = [
      { layout = "us"; displayName = "us"; }
      { layout = "gr"; displayName = "gr"; }
    ];
    options = [ "grp:caps_toggle" "grp:led:caps" ];
  };
};

Το αποτέλεσμα είναι ότι σε καθαρή εγκατάσταση δεν χρειάζεται να θυμάμαι πώς είχα ρυθμίσει το desktop. Το Plasma έρχεται σχεδόν όπως το θέλω.

Λέω «σχεδόν» γιατί το KDE/Plasma έχει και τις ιδιοτροπίες του. Κάποια πράγματα είναι καλύτερο να δηλώνονται καθαρά στο Nix, ενώ κάποια άλλα θέλουν μικρά activation hooks ή scripts που μπορούν να ξανατρέξουν με ασφάλεια.

Παράδειγμα: έχω ένα δικό μου wttr Athens widget στο panel. Το έφτιαξα ως Plasma applet, το πακετάρισα με Nix και μετά έχω script που το βάζει στη σωστή θέση στο πάνω panel. Δεν ήθελα να αντικαθιστώ όλο το panel σε κάθε rebuild, γιατί θέλω να μπορώ να κρατάω και μικρές χειροκίνητες αλλαγές χωρίς να τις διαλύει το σύστημα.

Αυτό είναι ένα πρακτικό μάθημα: declarative δεν σημαίνει πάντα «όλα με τον ίδιο τρόπο». Σημαίνει ότι ξέρω ποια είναι η πηγή αλήθειας και έχω επαναλήψιμο τρόπο να φτάσω στο αποτέλεσμα.

Ελληνικά, αγγλικά και Caps Lock toggle

Ένα από τα πρώτα πράγματα που θέλω σε κάθε Linux setup είναι σωστό keyboard.

Στο δικό μου σύστημα έχω:

• us,gr layouts,
• Caps Lock ως layout toggle,
• Caps Lock LED όταν είμαι στα ελληνικά,
• locale σε en_US.UTF-8, αλλά ελληνικά formats για ώρα, νόμισμα, τηλέφωνο κλπ.

Το system-level κομμάτι είναι στο modules/locale.nix:

# [PLACEHOLDER ΚΩΔΙΚΑ: καθαρισμένο modules/locale.nix]
{
  i18n.defaultLocale = "en_US.UTF-8";
  i18n.supportedLocales = [
    "en_US.UTF-8/UTF-8"
    "el_GR.UTF-8/UTF-8"
  ];

  time.timeZone = "Europe/Athens";

  services.xserver.xkb = {
    layout = "us,gr";
    options = "grp:caps_toggle,grp:led:caps";
  };
}

Και το Plasma-level κομμάτι υπάρχει επίσης στο plasma.nix, ώστε το KDE να μην έρθει μετά και κάνει τα δικά του.

Αυτό είναι γενικό μοτίβο στο NixOS + Plasma: πολλές φορές χρειάζεται και ρύθμιση συστήματος και ρύθμιση desktop, ώστε η συμπεριφορά να είναι σωστή παντού.

Native Nix apps αντί για Flatpak layer

Στο παλιότερο setup μου υπήρχε Flatpak layer. Δεν το θεωρώ κακό. Το Flatpak λύνει πολλά προβλήματα σε κλασικές διανομές, ειδικά για desktop apps.

Όμως στο συγκεκριμένο NixOS setup ήθελα κάτι άλλο: οι εφαρμογές μου να είναι μέρος της ίδιας δηλωτικής περιγραφής του συστήματος.

Σήμερα οι εφαρμογές μου μπαίνουν κυρίως από home.packages:

# [PLACEHOLDER ΚΩΔΙΚΑ: καθαρισμένο home.packages]
home.packages = with pkgs; [
  git
  tmux
  emacs
  brave
  vscode
  code-cursor
  dino
  thunderbird
  mpv
  vlc
  jq
  fzf
  nh
  nvd
  whisper-cpp
];

Το παλιό υλικό για τα Flatpak δεν το πέταξα. Το κράτησα στο archive/flatpak-reference/ για ιστορικούς λόγους και για να θυμάμαι τη μετάβαση. Εκεί βλέπω π.χ. ποιες Flatpak εφαρμογές αντικαταστάθηκαν από native Nix packages.

Παραδείγματα:

Flatpak παλιά              Native Nix τώρα
------------------------------------------------
com.visualstudio.code      pkgs.vscode
im.dino.Dino               pkgs.dino
io.github.kotatogram       pkgs.kotatogram-desktop
com.system76.Popsicle      pkgs.popsicle

Το κέρδος είναι ότι δεν έχω άλλο ένα επίπεδο που αλλάζει ανεξάρτητα από το υπόλοιπο σύστημα. Δεν έχω Flathub remotes, overrides, runtime versions και ξεχωριστά exports. Όλα περνάνε από Nix.

Το κόστος είναι ότι χάνω το μοντέλο απομόνωσης του Flatpak. Αυτό είναι συνειδητό tradeoff. Οι native Nix εφαρμογές τρέχουν ως κανονικές εφαρμογές του χρήστη. Άρα εγκαθιστώ μόνο ό,τι εμπιστεύομαι από nixpkgs ή από δικά μου derivations με κλειδωμένες πηγές.

Flatpak migration map

Το Flatpak κομμάτι δεν εξαφανίστηκε από τη μνήμη του project. Το κράτησα ως αρχείο αναφοράς, αλλά όχι ως ενεργό κομμάτι του συστήματος.

Παλιό μοντέλο
  |
  |-- ρύθμιση συστήματος με Guix
  |-- Flatpak apps
  |-- Flatpak overrides
  |-- runtime/export paths
  '-- επιπλέον audio/portal workarounds

Νέο μοντέλο
  |
  |-- NixOS modules
  |-- Home Manager home.packages
  |-- Plasma Manager desktop config
  |-- PipeWire + rtkit + XDG portals σε NixOS module
  '-- archive/flatpak-reference μόνο ως ιστορική τεκμηρίωση

Αυτή η μετάβαση ήταν σημαντική γιατί με βοήθησε να κόψω ένα ξεχωριστό επίπεδο πολυπλοκότητας. Στο παλιό μοντέλο είχα εφαρμογές που έρχονταν από αλλού, runtime permissions που ζούσαν αλλού και overrides που έπρεπε να θυμάμαι. Στο νέο μοντέλο, αν θέλω μια εφαρμογή, ψάχνω πρώτα αν υπάρχει στο nixpkgs. Αν υπάρχει, μπαίνει στο home.packages. Αν δεν υπάρχει όπως τη θέλω, φτιάχνω derivation στο packages/.

Το ίδιο ισχύει και για τον ήχο. Δεν βασίζομαι σε Flatpak-specific audio bridges. Η στοίβα ήχου είναι native μέρος του NixOS configuration: PipeWire, συμβατότητα με PulseAudio, rtkit και portals, όλα δηλωμένα στο modules/desktop-plasma.nix.

Ήχος, PipeWire και portals

Ο ήχος ήταν από τα σημεία που ήθελα να είναι σωστός, όχι «έτυχε και παίζει».

Στο modules/desktop-plasma.nix έχω PipeWire με ALSA, συμβατότητα με PulseAudio και JACK:

# [PLACEHOLDER ΚΩΔΙΚΑ: καθαρισμένο PipeWire setup]
services.pipewire = {
  enable = true;
  alsa.enable = true;
  alsa.support32Bit = true;
  pulse.enable = true;
  jack.enable = true;
};

services.pulseaudio.enable = false;
security.rtkit.enable = true;

Το security.rtkit.enable = true αποδείχτηκε σημαντικό. Για απλή αναπαραγωγή ήχου μπορεί να μη φανεί αμέσως. Αλλά σε full-duplex WebRTC καταστάσεις, όπως browser calls ή εφαρμογές μηνυμάτων με μικρόφωνο, το PipeWire χρειάζεται σωστό realtime scheduling. Χωρίς rtkit μπορεί να έχεις περίεργα προβλήματα: το YouTube να παίζει, αλλά το μικρόφωνο σε call να συμπεριφέρεται λάθος.

Επίσης δήλωσα ρητά XDG portals:

xdg.portal = {
  enable = true;
  extraPortals = [
    pkgs.xdg-desktop-portal-gtk
    pkgs.kdePackages.xdg-desktop-portal-kde
  ];
  config.common.default = "kde";
};

Αυτό βοηθάει σε file pickers, screen sharing, άδειες για μικρόφωνο/κάμερα και γενικά στο να συμπεριφέρονται σωστά οι native desktop εφαρμογές σε Plasma/Wayland.

Έχω και verify-audio.sh, γιατί δεν θέλω να θυμάμαι κάθε φορά τι πρέπει να κοιτάξω. Το script κάνει βασικούς ελέγχους για PipeWire, rtkit και portals.

Custom packages: όταν κάτι δεν υπάρχει όπως το θέλω

Ένα από τα πράγματα που μου αρέσουν στο Nix είναι ότι μπορώ να πω: «οκ, αυτό δεν υπάρχει όπως το θέλω στο nixpkgs, θα το πακετάρω εγώ».

Στο repo έχω διάφορα custom derivations.

Μερικά παραδείγματα:

• voxtyper.nix: δικό μου push-to-talk εργαλείο υπαγόρευσης,
• whisper-model.nix: κατεβάζει δηλωτικά το whisper model,
• ngrok.nix: binary derivation με κλειδωμένη πηγή,
• opencode-bin.nix: binary derivation για το OpenCode CLI,
• dracula-sddm.nix: SDDM Dracula theme για Plasma 6,
• dracula-cursors.nix: cursor theme από KDE Store με fixed-output hash,
• penrose-splash.nix: splash screen,
• wttr-athens-plasmoid.nix: δικό μου Plasma weather widget.

Το μοτίβο είναι πολύ ωραίο:

# [PLACEHOLDER ΚΩΔΙΚΑ: απλοποιημένο custom package]
{ pkgs, lib, ... }:

pkgs.stdenv.mkDerivation {
  pname = "my-tool";
  version = "1.0";

  src = pkgs.fetchurl {
    url = "https://example.org/my-tool.tar.gz";
    sha256 = "<sha256>";
  };

  installPhase = ''
    mkdir -p $out/bin
    cp my-tool $out/bin/my-tool
  '';
}

Και μετά στο home.nix:

let
  my-tool = pkgs.callPackage ../../packages/my-tool.nix { };
in {
  home.packages = [ my-tool ];
}

Από εκεί και πέρα, το δικό μου εργαλείο είναι κανονικό package στο προφίλ μου.

VoxTyper: offline dictation με Whisper

Το VoxTyper είναι από τα αγαπημένα μου μικρά projects μέσα σε αυτό το setup.

Η ιδέα είναι απλή:

Πατάω Shift+Meta+V
  -> ξεκινάει ηχογράφηση
Πατάω ξανά Shift+Meta+V
  -> σταματάει
  -> περνάει ο ήχος από whisper.cpp
  -> γράφει ή αντιγράφει το κείμενο

Το ωραίο είναι ότι το μοντέλο δεν το κατεβάζω με το χέρι. Είναι δηλωμένο σε Nix:

# [PLACEHOLDER ΚΩΔΙΚΑ: καθαρισμένο whisper-model.nix]
pkgs.fetchurl {
  url = "https://huggingface.co/.../ggml-base.bin";
  sha256 = "<sha256>";
  name = "whisper-ggml-base.bin";
}

Και μετά το Home Manager το βάζει στο σωστό path:

home.file.".local/share/whisper/ggml-base.bin".source = whisperModel;

Το shortcut είναι επίσης δηλωμένο μέσω plasma-manager:

programs.plasma.hotkeys.commands.voxtyper = {
  name = "VoxTyper";
  key = "Shift+Meta+V";
  command = "/etc/profiles/per-user/<user>/bin/voxtyper";
};

Αυτό για εμένα είναι η ουσία του setup: ακόμα και μια μικρή δική μου ροή εργασίας γίνεται μέρος του συστήματος. Δεν είναι «ένα script κάπου στο home». Είναι package, shortcut, model και έλεγχος ότι όλα εφαρμόστηκαν σωστά.

Scripts που γίνονται μέρος του συστήματος

Στο repo υπάρχει ο φάκελος scripts/. Με το Home Manager, κάθε .sh αρχείο γίνεται εκτελέσιμο στο ~/scripts/.

Το home/lef/scripts.nix κάνει ουσιαστικά αυτό:

# [PLACEHOLDER ΚΩΔΙΚΑ: απλοποιημένο scripts.nix]
home.file = mapScriptsFromRepoToHomeScripts;

Άρα όταν προσθέτω ένα νέο script, αρκεί να το έχω προσθέσει στο git και να κάνω rebuild.

Μερικά scripts που χρησιμοποιώ:

• reconf.sh: γρήγορο nixos-rebuild switch,
• re-nh.sh: rebuild μέσω nh με καλύτερο preview,
• verify-setup.sh: ελέγχει ότι το δηλωτικό setup εφαρμόστηκε,
• verify-keyboard.sh: έλεγχος keyboard layout,
• verify-audio.sh: έλεγχος PipeWire/rtkit/portals,
• sec-audit.sh: βασικός έλεγχος ασφαλείας,
• day-to-day.sh: αποτύπωση αλλαγών από το ζωντανό σύστημα πίσω στο repo.

Το αγαπημένο μου για καθημερινή χρήση είναι το nh:

nh os switch ~/dev/guix-2-nix --ask

Μου δείχνει diff πριν ενεργοποιήσει το νέο σύστημα. Αυτό είναι τεράστια βοήθεια, γιατί πριν κάνω switch μπορώ να δω ποια packages αλλάζουν, ποιες εκδόσεις ανεβαίνουν και τι περίπου θα συμβεί.

Για cleanup χρησιμοποιώ τη λογική:

nh clean all --keep 10 -e pkexec

Θέλω πάντα να κρατάω έναν ελάχιστο αριθμό παλιών generations για rollback. Δεν θέλω ένα garbage collection που βασίζεται μόνο στην ηλικία να μου σβήσει όλες τις παλιές γενιές επειδή πέρασε ένας ήσυχος μήνας.

AI εργαλεία, OpenCode, MCP και LSP

Ένα μικρό αλλά χρήσιμο κομμάτι του setup είναι και η ενσωμάτωση εργαλείων AI/ανάπτυξης.

Έχω το OpenCode δηλωμένο ως package, χρησιμοποιώ OpenAI-compatible gateway, και έχω πειραματιστεί και με δωρεάν μοντέλα, όπως το Big Pickle. Δεν θέλω να γίνει αυτό το άρθρο ανάλυση για AI εργαλεία, αλλά για εμένα έχει σημασία ότι και αυτά εντάσσονται στο ίδιο συνολικό setup του workstation.

Έχω επίσης MCP/LSP ρυθμίσεις για εργαλεία όπως Cursor και OpenCode, καθώς και language servers για Nix, Bash, Markdown, YAML, TypeScript, Python κλπ. Τα σχετικά αρχεία ρυθμίσεων περνάνε μέσα από Home Manager ως dotfiles.

Το νόημα είναι το ίδιο: ακόμα και το περιβάλλον ανάπτυξης δεν είναι «άνοιξα το IDE και κάτι ρύθμισα». Είναι δηλωμένο στο repo όσο γίνεται περισσότερο, ώστε μετά από ένα rebuild να έχω ξανά τα ίδια εργαλεία, τις ίδιες ρυθμίσεις και την ίδια βάση για δουλειά.

Μυστικά δεδομένα και το tradeoff

Επειδή το repo είναι private και φιλοξενείται σε δικό μου self-hosted git server βασισμένο σε Forgejo, έχω επιλέξει να κρατάω εκεί και κάποια SSH αρχεία που βοηθούν στην επαναφορά. Αυτό είναι πρακτικό, αλλά έχει tradeoff.

Στο Nix/Home Manager, όταν βάζεις τέτοια αρχεία μέσω home.file, μπορούν να περάσουν από το Nix store. Το Nix store είναι αναγνώσιμο από τον root. Άρα αυτό δεν είναι μοντέλο που θα πρότεινα έτσι αβίαστα για περιβάλλον παραγωγής ή για πολυχρηστικό σύστημα.

Για το δικό μου προσωπικό laptop είναι συνειδητή επιλογή, με private repo και συγκεκριμένο μοντέλο απειλών στο μυαλό μου. Μελλοντικά, η πιο σωστή λύση θα ήταν sops-nix ή κάτι αντίστοιχο.

Στο άρθρο αυτό κρατάω μόνο την αρχιτεκτονική ιδέα:

private repo
  -> encrypted/controlled access
  -> υλικό επαναφοράς
  -> το Home Manager περνάει τα αρχεία στη θέση τους

Δεν θα βρεθούν κλειδιά, fingerprints, known hosts, IPs ή tokens, ακόμα και σε private GitHub repositories. Μέγα λάθος όσοι δεν προσέχουν.

Έλεγχος: δεν εμπιστεύομαι απλώς ότι «έπαιξε»

Ένα καλό declarative setup θέλει και έλεγχο.

Το verify-setup.sh ελέγχει πράγματα όπως:

• υπάρχει nixos-rebuild,
• υπάρχει το flake.nix,
• τα αναμενόμενα εκτελέσιμα είναι στο PATH,
• εφαρμόστηκε η ρύθμιση πληκτρολογίου,
• υπάρχει η ρύθμιση του Plasma,
• υπάρχει το VoxTyper shortcut,
• υπάρχει το whisper model,
• υπάρχουν scripts στο ~/scripts,
• υπάρχουν βασικά dotfiles,
• υπάρχουν MCP/LSP tools.

Έτσι μετά από επαναφορά ή μεγάλο rebuild δεν κάθομαι να ψάχνω με το μάτι. Τρέχω συγκεκριμένους ελέγχους.

bash ~/scripts/verify-setup.sh
bash ~/scripts/verify-keyboard.sh
bash ~/scripts/verify-audio.sh
bash ~/scripts/sec-audit.sh

Μερικά πράγματα που έμαθα

Πρώτο μάθημα: το declarative setup θέλει πειθαρχία. Είναι εύκολο να πεις «έλα μωρέ, θα το αλλάξω από το GUI». Το δύσκολο είναι μετά να γυρίσεις και να περάσεις την αλλαγή στο Nix config.

Δεύτερο μάθημα: το KDE μπορεί να ρυθμιστεί πολύ περισσότερο απ' όσο νόμιζα μέσα από scripts και δηλωτικά αρχεία. Όχι πάντα τέλεια, όχι πάντα χωρίς κόπο, αλλά γίνεται. Και όταν γίνει, αξίζει.

Τρίτο μάθημα: τα μικρά βοηθητικά scripts είναι χρυσός, αρκεί να μην αντικαθιστούν το declarative μοντέλο. Τα scripts μου δεν είναι «πηγή αλήθειας». Είναι εργαλεία που εφαρμόζουν ή ελέγχουν την πηγή αλήθειας.

Τέταρτο μάθημα: το rollback σε NixOS αλλάζει την ψυχολογία. Δοκιμάζεις πιο άνετα, γιατί ξέρεις ότι υπάρχει προηγούμενη generation.

Πέμπτο μάθημα: τα private δεδομένα θέλουν σκέψη. Το ότι κάτι είναι εύκολο να μπει σε Home Manager δεν σημαίνει ότι είναι και η καλύτερη πρακτική ασφαλείας. Για προσωπικό laptop μπορεί να είναι αποδεκτό. Για αλλού, θέλει sops/age/secrets management.

Επίλογος

Αυτό το setup δεν το βλέπω απλώς ως «έβαλα NixOS στο laptop». Το βλέπω ως μια προσπάθεια να πάρω όλο το καθημερινό μου περιβάλλον και να το κάνω αναπαραγώγιμο.

Το λειτουργικό, το desktop, το πληκτρολόγιο, τα themes, τα packages, τα scripts, το voice typing, τα εργαλεία ανάπτυξης, η διαδικασία επαναφοράς, ακόμα και η τεκμηρίωση, όλα ζουν στο ίδιο repo και αλληλοσυνδέονται.

Το ωραίο είναι ότι πλέον το laptop δεν είναι ένα μοναδικό, εύθραυστο αποτέλεσμα πολλών χειροκίνητων αλλαγών. Είναι ένα σύστημα που μπορώ να περιγράψω, να χτίσω, να ελέγξω, να σπάσω, να γυρίσω πίσω και να ξαναστήσω.

Και αυτό για εμένα είναι η πραγματική δύναμη του NixOS.

Δεν είναι απλώς package manager. Δεν είναι απλώς distro. Είναι ένας τρόπος να πεις:

Αυτός είναι ο υπολογιστής μου.
Όχι ως ανάμνηση.
Όχι ως checklist.
Ως κώδικας.

Και ναι, μετά από αρκετό ψάξιμο, σπάσιμο, διάβασμα, rebuilds και μικρές νίκες, μπορώ πλέον να πω ότι το T480 μου είναι πολύ κοντά σε αυτό που ήθελα από την αρχή: ένα πλήρως declarative προσωπικό Linux workstation.