- Basé sur le gestionnaire de paquets Nix, NixOS permet de définir l’ensemble du système comme du code et de le restaurer à tout moment dans un état déterministe et reproductible
- Tous les réglages et paquets sont gérés dans un unique fichier de configuration déclaratif, ce qui permet de reconstruire le même environnement à partir d’une source unique même sur une nouvelle machine
- Il propose des versions stables publiées tous les 6 mois, les mises à jour automatiques, ainsi que la possibilité de tester les logiciels les plus récents via le canal unstable si nécessaire
- Il fournit des environnements de développement isolés permettant d’expérimenter différents langages et outils sans polluer le système, tout en conservant une expérience de développement cohérente entre macOS et Linux
- Il s’adapte aussi à l’ère du coding avec les LLM, où les outils changent vite, et garantit une cohérence jusqu’au déploiement grâce à un modèle de build déterministe et en couches plus robuste que Docker
La philosophie et l’attrait de NixOS
- Le cœur de NixOS n’est pas la distribution Linux, mais le gestionnaire de paquets Nix
- NixOS est le résultat d’un gestionnaire de paquets fonctionnel, déterministe et reproductible qui permet de configurer l’ensemble du système d’exploitation selon les entrées fournies en Nix DSL
- Il permet de reconstruire le système, de ne modifier qu’une partie, puis de faire un rollback si le résultat ne convient pas
- Alors que la plupart des systèmes d’exploitation deviennent plus instables avec le temps, NixOS permet de définir et de construire l’état du système
- Cela évite l’accumulation d’états flous causés par l’installation de paquets, les changements de configuration ou l’ajout et la suppression d’outils
- En définissant le système comme du code, on peut reproduire à tout moment exactement le même résultat
Configuration déclarative et gestion depuis une source unique
- Dans NixOS, il est possible de définir l’ensemble du système — paquets, configuration, mapping clavier, etc. — dans une configuration déclarative unique
- Jusqu’aux comportements détaillés, comme les réglages d’extensions GNOME ou le mapping clavier, qui peuvent être décrits en Nix DSL
- Même sur un nouvel ordinateur, il est possible de reconstruire l’ensemble du système à partir d’une source unique
- Cela permet de maintenir un état système cohérent sans configuration manuelle ni scripts dispersés
Stabilité et gestion des mises à jour
- NixOS conserve un cycle de publication prévisible de 6 mois et prend en charge les mises à jour automatiques
- Cela réduit les problèmes d’instabilité, de notifications intrusives ou de dérive du système souvent rencontrés lors des mises à niveau d’un OS classique
- Si nécessaire, on peut activer le canal unstable pour tester de manière expérimentale les logiciels les plus récents
- Même sur un portable HP, la compatibilité matérielle et la stabilité sont élevées, avec une utilisation immédiate sans configuration supplémentaire
Expérimentation et isolation des environnements de développement
- NixOS offre un environnement d’expérimentation sûr et peu coûteux
- Les paquets ne sont pas installés directement dans le système, mais exécutés dans des environnements shell isolés
- Grâce au Nix DSL, les dépendances, les étapes de build et les artefacts sont définis déclarativement, ce qui permet de préserver un environnement de développement sans pollution
- Le même gestionnaire de paquets Nix peut être utilisé sur macOS comme sur Linux, assurant une gestion cohérente des outils de développement et des dépendances
- Il existe aussi un support communautaire pour FreeBSD
Une bonne adéquation avec l’ère du coding assisté par LLM
- Les outils de développement basés sur les LLM exigent souvent de changer rapidement de versions spécifiques d’utilitaires, de compilateurs et de runtimes
- Nix répond à ce besoin en traitant les outils comme des entrées déclaratives et en les exécutant dans des environnements isolés
- Par exemple, pour construire un agent Rust de transcription vocale, Nix peut charger automatiquement la toolchain Rust et créer un environnement de build isolé
- Il ne modifie pas l’environnement système (
~/.cargo, ~/.rustup, PATH, etc.)
- Avec
flake.nix et nix flake check, il devient possible de figer l’environnement d’expérimentation d’un agent sous forme d’artefact reproductible
- Une session temporaire peut ainsi être transformée en unité de build vérifiable
Déploiement et modèle de développement cohérent
- Nix propose une méthode de build d’images plus déterministe et en couches que Docker
- Avec
dockerTools.buildLayeredImage, on peut créer des images Docker petites et reproductibles
- La même configuration permet d’obtenir le même résultat sur d’autres architectures
- Ce même modèle s’applique de manière cohérente aux portables, shells, dépendances de projet, pipelines CI et artefacts de déploiement
- Au lieu d’assembler plusieurs outils, on peut gérer l’ensemble du système logiciel avec une seule manière de penser
Conclusion
- NixOS est une implémentation d’un système déclaratif, reproductible, réversible et stable
- Il permet d’expérimenter et d’effectuer des mises à niveau sans crainte, tout en évitant de polluer le système même dans des environnements d’outils en évolution rapide
- Il offre à la fois stabilité et flexibilité, y compris dans les flux de développement modernes comme les agents de coding basés sur les LLM
- NixOS est la forme qui met le plus complètement en pratique cette philosophie au quotidien
8 commentaires
Moi aussi, j’ai utilisé NixOS pendant environ six mois il y a longtemps, puis je suis retombé sur Arch parce que je n’arrivais pas à résoudre, malgré tous mes googlages, une tâche toute simple qui ne demande normalement aucune recherche sur d’autres OS. J’ai fini par trouver sur un forum NixOS la solution qu’un certain expert NixOS ? avait documentée, et en voyant que ce hack de plusieurs dizaines de lignes était le commentaire le plus liké, j’ai eu l’impression que mon avenir sur NixOS s’annonçait bien sombre...
Et puis, je ne me souviens plus très bien, mais il y avait cette histoire de
flakeou d’une autre fonctionnalité, présentée comme une best practice à un endroit, comme expérimentale à un autre, et parfois comme les deux à la fois, et voir ça durer depuis des années m’a clairement fait comprendre que le chemin allait être semé d’embûches..Bien sûr, l’expérience de pouvoir coder facilement tout l’environnement de bureau était agréable
Firebase Studio utilise aussi Nix
Oh... je vois !
Cela dit, R.I.P. Firebase Studio T_T
C’est beaucoup trop difficile, j’ai essayé un peu puis j’ai abandonné 😭
(I use Arch btw)
Ceux qui connaissent l’utilisent discrètement, haha
Un setup reproductible implémenté avec un langage fonctionnel déclaratif
La courbe d’apprentissage est vraiment déraisonnable. En échange de la garantie de reproductibilité, il exige un niveau élevé.
Même avec
flake, c’est compliqué.Il semble aussi utiliser SQLite en interne, et comme les performances sont assez irrégulières, il y a une certaine fluctuation du temps nécessaire pour reproduire à nouveau un environnement.
Réactions sur Hacker News
Je pense que NixOS est sans égal en matière de compatibilité avec les outils d’IA
Sur d’autres OS, il est difficile de confier la configuration du système à une IA, mais avec NixOS, sa structure déclarative et réversible le rend digne de confiance
Je ne confierais pas à Claude ou Codex le passage de Pulseaudio à Pipewire ni l’installation de Hyprland, mais avec NixOS, j’aurais assez confiance pour le confier même à Grok
Le point clé, c’est la stabilité qui permet de vérifier les changements à l’avance et de revenir en arrière à tout moment
Si vous êtes développeur, je vous recommande d’essayer NixOS en rêvant d’un « desktop Linux géré par l’IA ». Vous pouvez commencer en disant à Claude : « Fais-moi une configuration Gnome basée sur Flake que je puisse démontrer dans une VM »
C’est impressionnant de voir Claude ajuster de façon déclarative les paramètres dconf de GNOME
Cela dit, comme l’IA ne comprend pas toujours le contexte complexe de l’écosystème Nix, elle produit parfois des résultats à côté de la plaque
On sent que la structure lambda peu conventionnelle de Nix et les portées implicites entre modules sont difficiles, non seulement pour les humains mais aussi pour l’IA
C’est pourquoi il est important de définir clairement la structure et les patterns du projet. Malgré cela, créer des templates basés sur Nix reste agréable et productif
Est-ce qu’on a vraiment besoin d’un LLM pour installer Hyprland ? Un simple
sudo dnf install hyprlandsuffitJ’ai l’impression que ce n’est pas tant que Nix est « compatible IA », mais plutôt que les gens utilisent des LLM parce qu’il est pénible à manipuler directement
Je gérais la configuration de plusieurs machines sous forme de « profils métier » et je déployais automatiquement les dépôts et paramètres nécessaires à chaque machine
Un collègue utilisait Windows à l’origine, mais maintenant il utilise NixOS au quotidien
Toute la configuration matérielle est aussi gérée de manière déclarative, et mes réglages sont dans un dépôt public GitHub. Les retours sont les bienvenus
Quand je déplace ma configuration vers une nouvelle structure ou que je crée plusieurs environnements de test WM/DE, Claude gère la plupart des tâches répétitives
Maintenant, le système est totalement stable, donc j’ai presque plus rien à faire manuellement
Il est difficile d’avoir ce niveau de confiance avec d’autres OS
À la place, je gérais mes environnements de développement avec des scripts Docker, mais maintenant j’ai l’impression que Nix et l’IA vont parfaitement ensemble
Je pense qu’on verra apparaître beaucoup de logiciels plus faciles à manipuler pour l’IA
Après 30 ans sur Windows, je suis passé complètement à Nix il y a un an
Je n’ai désormais plus aucune envie de revenir à Windows
J’adore le fait que toute la configuration de l’OS tienne dans un dépôt Git
Développer sans Nix est aussi inefficace que coder sans Git
Une fois la configuration en place, préparer un nouveau système devient très simple
J’aimerais pouvoir exécuter chaque application dans un environnement indépendant sans impact sur le système global
Je pense que NixOS est l’une des voies possibles vers ce futur
Les GPU Nvidia fonctionnent aussi très bien, et c’est bien plus stable que Gamescope
J’aimerais davantage aimer NixOS, mais le plus gros problème reste le manque de documentation
Les informations sont éparpillées entre plusieurs forums, de vieux blogs et des issues
Les deux sont mis à jour, mais quand on cherche, il n’est jamais clair lequel est le plus récent
Cloner nixpkgs et le lire directement est le plus rapide
J’ai essayé NixOS comme OS pour ordinateur portable, et les avantages comme les inconvénients étaient très nets
La configuration déclarative et les snapshots sont révolutionnaires, mais la distinction paquets/services et le concept de Flake m’ont paru confus
Lors de l’installation de KDE, seule une configuration minimale était installée, ce qui demandait des réglages supplémentaires, et la documentation changeait selon les versions, donc c’était difficile à suivre
Au final, j’ai abandonné parce que j’avais besoin d’une machine stable, mais ça me semble être un excellent choix pour les administrateurs système
L’installateur de Determinate Systems active Flake par défaut
On peut déplacer la configuration de
/etc/nixosdans un dépôt Git, puis déployer une configuration complète avec la commandenixos-install --flake <repo>Si on utilise aussi Home-manager, on peut gérer de manière déclarative jusqu’au répertoire utilisateur
Les fichiers de
/etcpeuvent être gérés avecenvironment.etc, et les fichiers de.configavec les options de home-managerLiens associés : option environment.etc, options home-manager
mkOutOfStoreSymlink, je suis tombé sur une réponse du genre « c’est simple, donc ça n’a pas besoin de documentation », ce qui m’a fait rireMalgré tout, les avantages de NixOS sont tellement grands que je suis en train de migrer complètement du homelab → au laptop → au desktop
Cela dit, la situation de la documentation reste désespérante
Autrement dit, il joue au niveau de Nix le rôle de package.json et du fichier lock
J’aimais déjà NixOS depuis longtemps, mais je l’aime encore plus depuis l’ère des LLM
Si je demande à Codex : « Modifie cette configuration serveur pour que le certificat wildcard fonctionne », c’est réglé en 5 minutes
La gestion reproductible des serveurs n’a jamais été aussi simple
Depuis mon passage à NixOS, l’époque où je gérais tout avec apt ou brew me paraît relever de la technologie de l’âge de pierre
Ça se marie aussi très bien avec des outils d’IA comme Copilot
Pour résoudre les problèmes, il faut une compréhension plus profonde que sur une distribution Linux classique
En contrepartie, c’est une structure où l’on paie toute la complexité en une seule fois, au départ
Le meilleur, c’est de pouvoir faire des installations temporaires avec nix-shell, ou voir tous les paquets installés dans un seul fichier de configuration
Grâce aux snapshots automatiques, expérimenter ne fait pas peur. En cas d’erreur, il suffit de redémarrer sur la génération précédente
Avant, modifier des paramètres du noyau me faisait peur, mais maintenant j’essaie sans hésiter
J’aime Lisp, donc j’ai aussi envisagé Guix System, mais en pratique NixOS est plus utilisable
J’aimerais simplement que NixOS n’ait pas cette structure de système de fichiers si particulière
C’est une approche pensée pour résoudre le problème de l’utilisation simultanée de plusieurs versions de Python, mais pour moi ce n’est pas nécessaire
Je veux juste garder la même configuration sur toutes mes machines
En ce moment, j’expérimente des images Fedora bootc et Podman, mais l’absence d’un effet immédiat comme
nixos-rebuild switchest gênanteAu final, c’est un compromis entre Nix, facile à expérimenter, et Fedora avec un système de fichiers standard
Le plus grand avantage de NixOS, c’est la reproductibilité déterministe du cache CI
Pas besoin de reconstruire les paquets à chaque fois, et la configuration des environnements de développement est simple
Par exemple, Tangled a construit tout son système de CI avec Nix, ce qui a complètement résolu les problèmes de cache de GitHub Actions
Je n’utilise pas tout le système, mais j’aime beaucoup devenv.sh
Ça permet de mettre en place un environnement de développement bien plus simplement qu’avec des conteneurs locaux
C’est dommage qu’il n’existe pas une méthode simple pour aligner les versions comme avec le
.tool-versionsde asdfDans l’univers Nix, on dit que « c’est une mauvaise approche », mais moi je veux quand même figer les versions individuellement
pkgs.mkShell, donc je me demande pourquoi utiliser devenv plutôt que çaJ’aime aussi NixOS, mais je préfère Guix
Je suis plus à l’aise avec le langage Guile, et la documentation est meilleure. Je considère les deux systèmes comme des projets frères
Le fait d’utiliser un vrai langage de programmation (Scheme) est un gros avantage
C’est une base bien plus puissante qu’un simple langage de configuration