NixOS/fr: Difference between revisions
Created page with "==== Architectures 32-bit x86 ====" |
Created page with "Le support des architectures 32-bit x86 (par exemple <code>i686</code>) est en déclin. Même si la plupart des paquets devraient toujours compiler et s'exécuter, la disponibilité de leur cache est significativement réduite <ref>https://discourse.nixos.org/t/limited-cache-availability-for-i686-32-bits-x86-architecture/37626</ref>. L'ISO 32-bit x86 n'est dorénavant plus proposée en tant qu'image prête à l'emploi, mais peut toujours être compilée manuellement." |
||
| Line 36: | Line 36: | ||
==== Architectures 32-bit x86 ==== | ==== Architectures 32-bit x86 ==== | ||
Le support des architectures 32-bit x86 (par exemple <code>i686</code>) est en déclin. Même si la plupart des paquets devraient toujours compiler et s'exécuter, la disponibilité de leur cache est significativement réduite <ref>https://discourse.nixos.org/t/limited-cache-availability-for-i686-32-bits-x86-architecture/37626</ref>. | |||
L'ISO 32-bit x86 n'est dorénavant plus proposée en tant qu'image prête à l'emploi, mais peut toujours être compilée manuellement. | |||
<div lang="en" dir="ltr" class="mw-content-ltr"> | <div lang="en" dir="ltr" class="mw-content-ltr"> | ||
Revision as of 00:30, 22 November 2025
NixOS est une distribution Linux basée sur Nix un gestionnaire de paquets et un système de construction. À l'échelle du système, il supporte la programmation déclarative au travers d'une gestion de configuration ainsi que les mises à jour atomiques et les "retours en arrière" (rollbacks), bien qu'il puisse aussi supporter des paquets impératifs ainsi que la gestion des utilisateurs. Dans NixOS, tous les composants de la distribution — y compris le noyau Linux, les paquets installés et les fichiers de configuration système — sont construits par Nix depuis des fonctions pures appelées expressions Nix.
Depuis que Nix met des exécutables en cache, cela permet d'avoir un compromis unique entre une approche orientée autour de l'exécutable présente dans des distributions comme Debian et une approche orientée autour du code source utilisée dans des distributions comme Gentoo. Les binaires peuvent être utilisés comme des composants standard, tandis que les paquets sur-mesure et les modules peuvent être utilisés automatiquement quand un binaire pré-compilé n'est pas disponible.
Stable NixOS releases are delivered twice a year (around the end of May and the end of November). NixOS was created by Eelco Dolstra and Armijn Hemel, and initially released in 2003. It is community developed and maintained under the stewardship of the NixOS Foundation.
Installation
Pour un guide d'installation complet, voir le chapitre "Installation" du guide de NixOS. Ce wiki inclut aussi des alternatives ou des guides supplémentaires, comme : Utiliser NixOS comme système de bureau.
La plupart des utilisateurs vont installer NixOS via une des images ISO. Les variantes "graphique" et "minimale" de l'ISO sont disponibles pour chaque architecture supportée ; les images "graphiques" sont adaptées pour les utilisateurs souhaitant installer un environnement de bureau, et les images "minimales" sont conçues pour les utilisateurs souhaitant installer NixOS comme serveur, ou désirant des images ISO de taille réduite. Les images ISO sont des images hybrides qui peuvent être gravées sur des supports optiques ou copiées sur une clé USB et utilisées telles quelles. Voir le guide d'installation pour plus de détails.
En supplément des images ISO, la page de téléchargement apporte un certain nombre de méthodes alternatives pour installer NixOS. Cela inclut :
- Des machines virtuelles au format OVA (compatible avec VirtualBox),
- Amazon EC2 AMIs,
Additionally, many existing Linux installations can be converted into NixOS installations using nixos-infect or nixos-in-place; this is particularly useful for installing NixOS on hosting providers which do not natively support NixOS.
Architectures système
NixOS fournit de manière native le support pour la plupart des appareils x86_64, ainsi que les appareils ARM64 génériques.
Architectures 32-bit x86
Le support des architectures 32-bit x86 (par exemple i686) est en déclin. Même si la plupart des paquets devraient toujours compiler et s'exécuter, la disponibilité de leur cache est significativement réduite [1].
L'ISO 32-bit x86 n'est dorénavant plus proposée en tant qu'image prête à l'emploi, mais peut toujours être compilée manuellement.
64-bit x86 architectures
Most x86_64 devices should run NixOS without issues.
32-bit ARM architectures
- Main article: NixOS on ARM
NixOS isn't officially supported on ARM32 devices (e.g. armv6 and armv7l), however, for some of these devices, there may be community support.
64-bit ARM architectures
- Main article: NixOS on ARM
As long as a device supports the generic systemd boot process, NixOS should run out of the box. However, specific devices with proprietary bootloaders may have issues running it.
MIPS architectures
- Main article: NixOS on MIPS
There used to be limited support for MIPS architectures in NixOS, and remnants of this support may still be found in Nixpkgs. However, there is no official support.
RISC-V architectures
- Main article: RISC-V
NixOS does not provide official support for RISC-V devices. However, several devices may benefit from community support.
Usage
Declarative Configuration
One of NixOS's defining features is its declarative configuration model, where the entire system state — including installed packages, system services, and settings — is described in configuration files. The primary file is typically located at /etc/nixos/configuration.nix.
Changes to the configuration are applied atomically using nixos-rebuild switch, ensuring reproducibility and the ability to roll back to previous states. Most users track their configuration files in a version control system, enabling consistent and portable system setups. These shortcomings are often rectified after-the-fact if at all by configuration management solutions such as Puppet, Ansible or Chef. These tools reconcile system configuration with a description of the expected state. However, these tools are not integrated into the operating system design and are simply layered on top, and OS configuration may still vary where an aspect of OS configuration has not been specified in the description of expected state.
Unlike conventional distributions, where system configuration is often scattered across manually edited files, NixOS integrates configuration management directly into the operating system. This eliminates configuration drift and makes NixOS particularly well-suited for automated, reproducible deployments.
For more details and examples on NixOS configurations, see NixOS system configuration.
Imperative Operations
While NixOS is typically configured declaratively as much as possible, these are a few domains where imperative operations are still necessary; these include user environment management and channel management.
User Environments
In addition to declarative system configuration, NixOS users can utilize Nix's imperative nix-env command to install packages at the user level, without changing the system state. See the user environments section of the Nix article for more information.
Channels
In the Nix ecosystem, channels are a mechanism for distributing collections of Nix packages and NixOS module definitions. A channel represents a curated, versioned set of package definitions and system configurations, typically corresponding to a particular release or the latest available development state.
When using channels, your system or user environment pulls package definitions and options from a URL pointing to a specific snapshot of the Nix Packages collection (Nixpkgs) and associated NixOS modules.
For more information on using and configuring nix channels, refer to channel branches.
Internals
Comparison with traditional Linux Distributions
Main Article: Nix vs. Linux Standard Base
The main difference between NixOS and other Linux distributions is that NixOS does not follow the Linux Standard Base file system structure. On LSB-compliant systems software is stored under /{,usr}/{bin,lib,share} and configuration is generally stored in /etc. Software binaries are available in the user environment if they are placed in one of the LSB's /bin directories. When a program references dynamic libraries it will search for the required libraries in the LSB folders (/lib, /usr/lib).
In NixOS however /lib and /usr/lib do not exist. Instead all system libraries, binaries, kernels, firmware and configuration files are placed in the Nix store. The files and directories in /nix/store are named by hashes of the information describing the built data. All of the files and directories placed in the Nix store are immutable. /bin and /usr/bin are almost absent: they contain only /bin/sh and /usr/bin/env respectively, to provide minimal compatibility with existing scripts using shebang lines. User-level environments are implemented using a large number of symbolic links to all required packages and auxiliary files. These environments are called profiles and are stored in /nix/var/nix/profiles, each user having their own profiles. Structuring the system in this way is how NixOS obtains its key advantages over conventional Linux distributions, such as atomicity and rollback support.
Usage of the Nix store
A lot of confusion for newcomers arises from the fact that configuration is stored in the read-only /nix/store tree along with all the installed packages. This fact makes it impossible to manually edit system configuration; all configuration changes must be performed by editing the /etc/nixos/configuration.nix file and executing nixos-rebuild switch. NixOS provides the module system for editing all required configurations. Users should first use the option search tool to check if the option they need exists before attempting to manually add files or configuration via low-level NixOS features like activation scripts.
The system purity makes it possible to keep system configuration in a central place, without the need to edit multiple files. This configuration can be distributed or version controlled as desired. It also provides for determinism; if you provide the same inputs, the same version of Nixpkgs and the same /etc/nixos/configuration.nix you will get the exact same system state.
Modules
The NixOS module system as defined in Nixpkgs provides the means necessary to customize the configuration of the OS. It is used to enable and customize services such as nginx, enable firmware and customize the kernel.
All module configuration is generally performed by adding options to /etc/nixos/configuration.nix. Most of the examples in the wiki show how this file can be used to configure the OS.
The NixOS module system implements a typing system which allows typechecking of option settings. It also enables options defined in multiple places to be merged automatically. This allows you to spread your configuration over multiple files, and the options you set across all of those files will be merged together:
{
imports = [
./basic-webserver.nix
./blog.nix
];
}
{
services.nginx.enable = true;
services.nginx.virtualHosts."example.com" = {
root = "/var/www/example.com";
};
}
{
services.nginx.virtualHosts."blog.example.com" = {
root = "/var/www/blog.example.com";
};
}
See the Modules section of the NixOS Manual for more details.
Generations
Every time the system state is rebuilt using nixos-rebuild switch, a new generation is created. You can revert to the previous generation at any time, which is useful if a configuration change (or system update) turns out to be detrimental.
You can roll back via:
$ nix-env --rollback # roll back a user environment
$ nixos-rebuild switch --rollback # roll back a system environment
NixOS also places entries for previous generations in the bootloader menu, so as a last resort you can always revert to a previous configuration by rebooting. To set the currently booted generation as the default run
$ /run/current-system/bin/switch-to-configuration boot
Because NixOS keeps previous generations of system state available in case rollback is desired, old package versions aren't deleted from your system immediately after an update. You can delete old generations manually:
# delete generations older than 30 days
$ nix-collect-garbage --delete-older-than 30d
</div>
<div lang="en" dir="ltr" class="mw-content-ltr">
# delete ALL previous generations - you can no longer rollback after running this
$ nix-collect-garbage -d
List generations:
# as root
$ nix-env --list-generations --profile /nix/var/nix/profiles/system
Switch generations:
# as root switch to generation 204
$ nix-env --profile /nix/var/nix/profiles/system --switch-generation 204
delete broken generation(s):
# as root delete broken generations 205 and 206
$ nix-env --profile /nix/var/nix/profiles/system --delete-generations 205 206
You can configure automatic garbage collection by setting the nix.gc options in /etc/nixos/configuration.nix. This is recommended, as it keeps the size of the Nix store down.
See also
- NixOS modules, a library for modular Nix expressions which powers the declarative configuration of NixOS.
- NixOS VM tests, a library for creating reproducible infrastructure tests, based on Nixpkgs, NixOS, QEMU and Perl.
- NixOS & Flakes Book (Ryan4yin, 2023) - 🛠️ ❤️ An unofficial NixOS & Flakes book for beginners.
