Journal Je teste Nixos : Ă©pisode 1 l'installation

Posté par  (site web personnel) . Licence CC By‑SA.
Étiquettes :
44
11
juin
2026

Bonjour Nal,

Cela faisait fort longtemps que je n'avais pas testé de distribution.

Au début du millénaire, j'étais jeune, beau (je le suis toujours d'après ma maman) et surtout j'avais du temps libre : je testais alors Knoppix, Gentoo et une petite nouvelle Ubuntu qui restera ma distrib préférée avant que Canonical ne lent chie… l'anshi… la bousille en mettant des pubs dans le terminal et des logiciels privateurs pour les paquets.

Depuis je n'installais plus que Debian Stable sur toutes mes machines.

Intrigué par le choix de la DINUM de Nixos, j'ai profité de la récupération d'un vieux PC portable pour tester cette distribution.

Un clavier AZERTY en vaut deux

Armé d'un CDd'une clef USB, je boote sur la distribution live… je lance l'installeur et PAF :

  1. impossible d'installer Nixos hors ligne ;
  2. l'étape de configuration du clavier se fait APRES la connexion, il faut donc taper son mot de passe WIFI en qwerty sur un clavier azerty comme en 1742 ?

J'ai failli arrêté là, mais heureusement le bureau du live cdusb est KDE et on peut changer la disposition du clavier.

Toutefois un tel comportement n'est pas de bon augure : il n'y a que des stazuniens qui développent Nixos ?

Des chiffres et des lettres

La suite de l'installeur est par contre une très bonne surprise: la distribution propose le chiffrement du disque et la gestion de l'hibernation (via swap). Je ne savais pas que c'était possible !

Victor boote

Je choisis un bureau KDE Plasma, je reboote et… Ça marche ! Wayland, pipewire, systemd… Je suis sûr un vrai Linux moderne !

Je veux tester le son via mon casque audio pour ne pas réveiller bébé… et PAF !

Le bluetooth n'est pas activé, mal géré… J'ai pu le faire tomber en marche en:

  1. ajoutant hardware.bluetooth = { enable = true; powerOnBoot = true;} dans mon /etc/nixos/configuration.nix ;
  2. installant un paquet kdePackages.bluedevil pour avoir une IHM ;
  3. ajoutant un autre paquet kdePackages.bluez-qt parce que paquet bluedevil ne déclare pas la lib dont il a besoin…

Bref c'est mal foutu : personne n'aime les touffes bleues chez les développeurs de Nixos ?

Qui apt ?

Maintenant que j'ai un beau bureau prêt pour le bureau, j'ai voulu tester LA friture n°1 de Nixos : la gestion des paquets modernes, agiles, révolutionnaires et… PAF !

  • la recherche de paquets en ligne de commande est une fonctionnalitĂ© expĂ©rimentale, la doc indique de taper une commande longue CMB nix --extra-experimental-features "nix-command flakes" search nixpkgs nomdupaquet : heureusement il est possible d'activer ces fritures dans /etc/nixos/configuration.nix ;
  • d'ailleurs tout se fait par modification de /etc/nixos/configuration.nix suivi d'un nixos-rebuild switch, mais par dĂ©faut l'Ă©diteur de texte est… heu ben c'est quoi dĂ©jà ? vi ? non ? ed ? non plus ? ah nano… Mmh comment fait pour quitter dĂ©jà ? Ah oui en coupant (CTRL-X) ! Quitte Ă  prendre un Ă©diteur non standard, j'aurais aimĂ© que Nixos choisisse micro qui a le bon goĂ»t d'avoir des raccourcis normaux.
  • d'après les logs, lors des installations je vois que beaucoup de tĂ©lĂ©chargements sont fait directement depuis github : ce n'est pas très rassurant pour la souverainetĂ© (coucou la DINUM).

Je comprends l'intérêt d'une configuration centralisée et reproductible, mais je ne suis pas sûr d'en profiter plus que ça à l'usage.

La suite numérique au prochain numéro

C'est tout pour aujourd'hui Nal, je te tiendrais au courant de la suite de mes aventures avec Nixos dans un autre journal !

++

  • # Rabbit hole

    Posté par  (Mastodon) . Évalué à 5 (+3/-0).

    Bienvenu dans le trou du lapin. Je ne sais pas si tu es complétement tombé dedans (je reconnais quelques grincements de dents que je me souviens avoir eu au début), mais une fois en chute libre, difficile de revenir à une distribution non déclarative. En tout cas c'est mon expérience.
    Surtout si on a à gérer plusieurs machines, c'est tout de même drôlement chouette, comme paradigme. Moi je gère ma machine, mon serveur à la maison, le laptop de ma compagne, le fixe de ma mère à distance, et la configuration WSL du PC de mon boulot à travers de home-manager (oui, je sais, mais j'ai pas le choix), tout à partir d'un flake unique, et c'est super chouette :)

  • # Pas prĂŞt pour le desktop ?

    Posté par  (Mastodon) . Évalué à 5 (+2/-0). Dernière modification le 11 juin 2026 Ă  10:05.

    Si j'ai bien compris l'intérêt d'une telle distribution c'est plutôt pour faire des VM facilement reproductibles, avec versionnement, gestion de conf etc. plutôt que pour tous les jours non ?

    En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.

    • [^] # Re: Pas prĂŞt pour le desktop ?

      Posté par  (Mastodon) . Évalué à 6 (+4/-0).

      Ça dépend de ce que tu appelles "tous les jours" ou "prêt pour le desktop".

      Ce n'est pas fait (et n'a jamais prétendu être fait) pour que Mme ou M. Michu (ou leur fils Kevin) puisse administrer leur machine familiale facilement.

      C'est plutĂ´t fait pour :

      • comme tu dis, des VM reproductibles, serveurs, etc. Machines de tests ou de prod. Le mot clĂ© est "reproductible".

      • daily-driver pour un dĂ©veloppeur qui Ă  la fois aime bidouiller (rabbit-hole comme je disais plus haut), et Ă  la fois a envie de stabilitĂ© entre deux pĂ©riodes de bidouillage (snapshots des gĂ©nĂ©rations, gestion TRES fine des versions, rollback facile, etc). Moi j'ai mes crises de geekerie, et mes pĂ©riodes plutĂ´t longues oĂą je n'ai aucune envie de toucher Ă  mon OS. Je trouve satisfaction pour ces deux cas avec Nix.
        Petit ajout pour le dev : la gestion de différents environnements avec nix-shell, flakes, etc… Tellement bon :p

      • Des machines administrĂ©es. Entreprise, administration, ou famille Michu qui a dĂ©lĂ©guĂ© l'administration de ses machines Ă  un des membres qui s'y connait, Mireille Michu par exemple. Ou Jean-Pascal Michu, choisissez qui vous voulez.

      • [^] # Re: Pas prĂŞt pour le desktop ?

        Posté par  (site web personnel) . Évalué à 2 (+2/-2).

        Mireille Michu par exemple. Ou Jean-Pascal Michu, choisissez qui vous voulez

        moi dans la famille Michu, je choisis Dominique ou Sydney (qui parle bien Anglais), de l'intérêt des prénoms épicènes ;-) sinon, tu as quelques prénoms bretons (celtes quoi, les écossais ayant des accointances étant aussi représentés) si tu as l'âme régionaliste : Aëlig, Anaël, Isabeau, Lénaïck, Yannick (?!).

      • [^] # Re: Pas prĂŞt pour le desktop ?

        Posté par  . Évalué à 1 (+1/-0).

        Pour ceux qui trouve que /etc/configuration.nix c’est trop énervant: nix profile add nixpkgs#lenomdupackage

        Pourquoi quand j’ai installé nixos, la configuration du clavier était bien l’une des premières étapes, entre le fuseau horaire et les logiciels non libre ?

        • [^] # Re: Pas prĂŞt pour le desktop ?

          Posté par  (Mastodon) . Évalué à 5 (+3/-0).

          Pour ceux qui trouve que /etc/configuration.nix c’est trop énervant: nix profile add nixpkgs#lenomdupackage

          Alors ça, ça marche, mais à mon humble avis, c'est une très mauvaise idée.

          En gros, c'est une sorte de sudo apt install bidule, sans le sudo (donc c'est seulement installé pour le profile, donc pour l'utilisateur).
          C'est une installation impérative, on perds tous les avantages de nixos : la reproductibilité, la centralité de la configuration, etc. Si quelque-chose casse, bon courage pour comprendre pourquoi et comment !
          Si on part comme ça, autant installer ubuntu et installer des trucs via flatpack ou je ne sais quel truc qu'ils ont maintenant sous ubuntu.

          Si le but c'est de tester un logiciel avant de décider si oui ou non on l'ajoute à sa configuration permanente, on peut faire nix-shell -p bidule, tester le logiciel depuis ce shell, et il disparait à la fermeture du terminal.

      • [^] # Re: Pas prĂŞt pour le desktop ?

        Posté par  . Évalué à 3 (+1/-0).

        qu'est ce qui garanti la reproductivité ? on peut garantir que c'est toujours la même version de chaque paquet qui est installé ?

        • [^] # Re: Pas prĂŞt pour le desktop ?

          Posté par  (Mastodon) . Évalué à 3 (+1/-0).

          Alors je ne suis pas un spécialiste, mais voilà ce que j'en ai compris :

          nixpkgs est un dépôt git de définitions de packages. C'est du code, versionné.

          Du coup, quand tu "compiles" ta config écrite en langage nix, cette "compilation" (en fait ça s'appelle "dérivation" dans le jargon) sera faite à partir de deux facteurs, en gros. 1: ton code de configuration, 2: le commit précis du dépôt nixpkgs à partir duquel tu as construit ton système. Donc si tu re-réunis ces deux facteurs à l'identique (il existe des systèmes pour gérer finement ça, comme flake), tu auras exactement le même résultat, au bit près je crois.

          Après, s'il y a des gurus NixOS pour me corriger, j'ai sans doute approximé à outrance.

          • [^] # Re: Pas prĂŞt pour le desktop ?

            Posté par  . Évalué à 3 (+2/-0).

            2 choses.
            Soit c'est reproductible, soit c'est conforme Ă  la version exacte.
            Le mode de base c'est reproductible fonctionnellement. Faire à la version exact, n'a que peut d’intérêt sauf sur un flake.nix ou un shell.nix pour avoir un environnement de développement 100% conforme au pré-requis.

            Le code suivant fait en sorte que hypridle est actif et toujours configuré avec ces options :
            services.hypridle = {
            enable = true;
            settings = {
            general = {
            lock_cmd = "pidof hyprlock || hyprlock";
            before_sleep_cmd = "pidof hyprlock || hyprlock";
            after_sleep_cmd = "hyprctl dispatch dpms on";
            };

                  listener = [
        {
          timeout = 900;
          on-timeout = "pidof hyprlock || hyprlock";
        }

        {
          timeout = 930;
          on-timeout = "hyprctl dispatch dpms off";
          on-resume = "hyprctl dispatch dpms on";
        }
      ];
    };
  };

    • [^] # Re: Pas prĂŞt pour le desktop ?

      Posté par  (Mastodon) . Évalué à 4 (+6/-4).

      Ah, et petit ajout, au risque de se faire moinser, d'un truc que j'expérimente un peu ces temps ci : comme toute la conf est dans un dépôt, dans un langage donné et documenté, la possibilité de déléguer des tâches d'écriture de module et de débugguage, factorisation, implémentation, etc. dans son système à un agent IA, tout en gardant la sécurité de pouvoir fallback (entre les générations et entre les commits sur le dépôt de la conf), je suis en train de tester ça disais je, et j'avoue être assez impressionné.

      • [^] # Re: Pas prĂŞt pour le desktop ?

        Posté par  (site web personnel) . Évalué à 4 (+3/-1).

        j'aurais plutôt vu des typologies de distribution pour un poste selon son utilisation ( des spins dans le langage de Fedora, mais là plutôt comme un ansible pour déployer et bénéficier de toute la conf' pour une activité donnée) :

        • Ă©quivalent de la clef AgrĂ©g avec plein de logiciels de Maths
        • la mĂŞme chose pour physicien et chimiste, voire data scientist
        • un PC gamer : soit orientĂ© RTS1, soit FPS2, soit petits jeux pour patienter entre deux rĂ©unions (on a bien dit pas pendant ! :p), soit jeux pour enfants (et grands nenfants)
        • une clĂ© rescue avec tous les outils, similairement une clĂ© admin sys/rĂ©seau pour diagnostiquer ce qui ne va pas (et sa dĂ©clinaison pentesting pour Ă©valuer ce qui peut ĂŞtre amĂ©liorĂ©)
        • bref, toutes les thĂ©matiques imaginables demandant un ensemble cohĂ©rent d'outils/logiciels, permettant de l'adapter au contexte (par exemple dans notre fablab il y aurait "rĂ©installer un portable robot thymio avec tout l'environnement scratch/python dĂ©jĂ  prĂŞt :D)

        1. RTS ou jeux de stratégie pour celleux qui aiment réfléchir ↩

        2. FPS pour dégommer du monstre ↩

        • [^] # Re: Pas prĂŞt pour le desktop ?

          Posté par  . Évalué à 2 (+0/-0).

          Tout Ă  fait d'accord.

          L'audio :)

          "Si tous les cons volaient, il ferait nuit" F. Dard

        • [^] # Re: Pas prĂŞt pour le desktop ?

          Posté par  (Mastodon) . Évalué à 2 (+0/-0). Dernière modification le 11 juin 2026 Ă  14:15.

          Oui, c'est un peu ce que j'ai fait avec mon setup familial : en fonction de l'host cible, ce ne sont pas les mêmes modules qui sont sélectionnés. Que ce soit le desktop (KDE plasma vs i3 pour mon laptop), les outils CLI + les services pour le serveur, les outils CLI sans les services web, + des outils de dev spécifiques pour le home-manager du pc du boulot… Le tout avec des modules partagés avec tout ou partie des hôtes (ex bluetooth, partagé par tous sauf serveur et WSL).

          Je n'ai pas encore de profil PC gamer, mon fils n'a que 6 ans, mais ça va venir… Il a bien un module minecraft, mais activé sur ma session, pas la peine qu'il ait la sienne pour le moment :)

    • [^] # Re: Pas prĂŞt pour le desktop ?

      Posté par  (site web personnel) . Évalué à 8 (+5/-0).

      Je préfère utiliser une même distribution sur mes ordinateurs personnels, professionnels, sur le bureau, sous mon bureau, dans un datacentre, sur une machine physique, sur une machine virtuelle… Si ça pouvait aussi tourner sur mon téléphone, ma console et ma voiture, ce serait génial :-)

      Ce post est offensant ? Prévenez moi sur https://linuxfr.org/board

    • [^] # Re: Pas prĂŞt pour le desktop ?

      Posté par  (site web personnel) . Évalué à 2 (+2/-2).

      J'en suis plutĂ´t content pour un usage de tous les jours sur un ordi fixe avec un peu de Nginx.

      Par rapport à Debian ça m'a permis d'avoir qqchose de très très stable mais un peu plus moderne. Je n'ai pas de "doute" dans les debugs à me dire "ah mais un fichier a du rester altéré lors de telle ou telle bidouille" -> parfois activer un nouveau truc est un peu relou, parfois très simple, mais une fois activé c'est activé. Définitif.

      Par ex. activer un sous domaine avec renouvellement automatique des certificats ça prends 30 sec. (Effectivement chercher un paquet en ligne de commande c'est expérimental. Oui c'est n'imp).

      Les mises Ă  jours sont un peu lentes en temps machine (vieil ordi), mais triviales en temps homme.

      j'ai un peu galéré pour compil du Rust (il y a bcp trop de méthodo différentes sous NixOS pour établir un environnement de dév Rust), mais une fois que j'ai choisi mon outil c'était une affaire passée. Je dirai qu'après quelques mois parsemés de petites galères, on passe à du quasi 0 maintenance - attention à l'espace disque une fois de temps en temps, un peu comme avec du flatpak.

      Et oui j'ai un peu usé l'IA plus récemment, laquelle sait débug NixOS à merveille - comme c'est un monde à part, documenté mais parfois difficile d'accès, la capacité d'outil de recherche de l'IA fait merveille et rend NixOS ultra simple (pour quand on a pas le temps de s'amuser à trouver par soi même parce qu'il y a une fichue échéance)

    • [^] # Re: Pas prĂŞt pour le desktop ?

      Posté par  . Évalué à 5 (+3/-0).

      Je "gère" un parc de plusieurs centaines d'ordis portables sous Ubuntu 24.04, et je dois dire que la promesse de NixOS permettrait de simplifier plein d'aspects, liés à la dérive qui s'opère avec le temps1 et les "petites modifs locales" occasionnelles.

      1. parfois provenant de mises à jour depuis Ubuntu 16 -> 18 -> 20 -> 22 -> 24. ↩

  • # bloub

    Posté par  (courriel, site web personnel) . Évalué à 5 (+3/-0).

    La suite de l'installeur est par contre une très bonne surprise: la distribution propose le chiffrement du disque et la gestion de l'hibernation (via swap). Je ne savais pas que c'était possible !

    J'ai ma swap sur LVM sur LUKS avec support de l'hibernation depuis des années sous Debian stable…
    Il y a peut être des subtilités si on veut utiliser Secure Boot cela dit.

    pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

  • # DĂ©pendance Ă  GitHub

    Posté par  . Évalué à 7 (+7/-0).

    d'après les logs, lors des installations je vois que beaucoup de téléchargements sont fait directement depuis github : ce n'est pas très rassurant pour la souveraineté (coucou la DINUM).

    NixOS repose effectivement beaucoup (trop) sur GitHub. Après, nous pourrions tout de même relativiser…

    Pour vulgariser, lorsque tu installes ou modifies NixOS, nixos-rebuild réalise principalement 3 étapes:

    1. Lire ta configuration afin de générer une recette de build. On parle d'évaluation, et cela peut être fait manuellement via la commande nix-instantiate qui génère des "derivations".
    2. Éxecuter la recette issue de l'évaluation pour construire le script de déploiement. On parle de build/realization et cela peut être fait manuellement via la commande nix-store --realize derivation.drv. Dans le cas de NixOS, lorsque tu buildes ta configuration, Nix construit un script (nommé switch-to-configuration) qui a pour rôle de modifier ton systeme à chaud (écrire dans /etc, installer le bootloader, …).
    3. Executer le script switch-to-configuration pour installer ou mettre à jour ton système.

    Seules les Ă©tapes 1. et 2. ont besoin d'Internet.

    Concernant l'étape 1., Nix a besoin du dépot nixpkgs qui contient les recettes de build des paquets NixOS. Ce dépot est hebergé sur GitHub et par défault, nixos-rebuild va donc récupérer les recettes de GitHub. Cependant, si tu clones ce dépot ailleurs, tu pourrais te passer de GitHub.

    Concernant l'étape 2., nixos-rebuild va d'abord chercher des binaires préconstruits (la magie de la transparence source/binary) sur cache.nixos.org. Cela t'évite de builder localement tous les paquets dont tu as besoin. Si le paquet dont tu as besoin n'existe pas dans le cache NixOS, alors il va le construire localement. Si les sources de ce paquet sont sur GitHub, alors Nix va récupérer ces sources depuis GitHub [1].
    Ce cache n'est pas hebergé sur GitHub, mais sur le S3 d'AWS :/
    Il serait possible de se passer de ce S3 en rebuildant tous les paquets nécessaires localement ou en ayant une CI qui construit ces paquets et les expose comme cache.nixos.org.

    En conclusion, par défaut, NixOS est effectivement fortement dépendant de services extra européens mais les outils existent pour s'en passer. Et à l'échelle d'un état, ce n'est pas insurmontable (des entreprises utilisant Nix le font déjà).

    [1] une idée pourrait être de fallback sur Softwre Heritage si GitHub n'est pas la, mais il n'y a rien de très concret coté Nix pour l'instant (Guix est plus avancé sur ce sujet).

    • [^] # Re: DĂ©pendance Ă  GitHub

      Posté par  (Mastodon) . Évalué à 5 (+3/-0).

      En conclusion, par défaut, NixOS est effectivement fortement dépendant de services extra européens mais les outils existent pour s'en passer. Et à l'échelle d'un état, ce n'est pas insurmontable (des entreprises utilisant Nix le font déjà).

      Est-ce que l'on sait si Securix et Bureautix feront ça ? Ce sont les deux systèmes développés par la DINUM si j'ai bien compris, basés sur Nix.

  • # Nina

    Posté par  (site web personnel) . Évalué à 4 (+2/-0).

    Utilitaire pour, entre autres, chercher des paquets en ligne de commande : https://discourse.nixos.org/t/nina-a-helper-that-makes-nixos-a-cozier-place-to-live-search-install-generations-services-flakes-multi-machine-management-etc/78070

    oui cela reste une recherche en ligne, mais au moins rester dans le terminal …

  • # zero traca et zero blabla (j'abuse un peu ;-)

    Posté par  . Évalué à 3 (+2/-0).

    J'utilise tous les jours professionnellement et personnellement Nixos depuis 2023 je pense.
    Nixos seul, c'est bien. Nixos+home-manager c'est mieux.

    Installation facile, j'utilise du bluetooth sans pb toute la journée sur mon laptop.

    J'écoute de la musique pour travailler, toute la journée. Aucun problème non plus.

    Ma stack est un peu complexe : poste chiffré, Nitrokey pour déchiffrement du disque, pour le 2FA du login. Hyprland+hypridle+hyprlock. Si tu retire la clé, le lock screen est exécuté.

    Je dis pas que c'est facile tout le temps, mais lorsque c'est fait, ça marche très bien.

    Pour les paquets, perso, j'utilise fortement : https://home-manager-options.extranix.com/?query=programs.git&release=release-25.11 et https://search.nixos.org/packages

    Je l'utilise pour mon poste perso, pro et qq vps.

    Autre très très gros avantage : agenix. Agenix permet de stocker dans un fichier age (donc chiffrement par une clé SSH) les secrets. Tu peux sans risque avoir tout ta conf dans un depot git, y compris un mot de passe ;-)

    Dispo Ă©galement sop, mais trop complexe pour mon usage (je partage pas de secret avec d'autres personnes).

    Autre projet sympas : https://github.com/elitak/nixos-infect
    ça permet de transformer n'importe quel vm/machine en nixos. Utilisé avec succès sur les VPS ovh et hetzner. Tu installes en debian et tu transformes en nixos. Après tu pousses tes modules et tu gagnes ton temps :)

    J'abuse de nix-shell pour des tests et j'utilise un peu flake pour avoir un truc reproductible parfaitement (genre quand je veux tester une version exact de Postgresql en parallèle de celui qui tourne déjà sur mon poste), mais j'en ai pas trop l'usage.

    Ajoute à cela la nouvelle version tous les 6 mois et un changelog complet, pour tous les jours c'est très bien.

    A++

Envoyer un commentaire

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.