Jump to content

Nix vs. Linux Standard Base: Difference between revisions

Partial copy edit
imported>Nix
(add OSTree comparison)
(Partial copy edit)
 
(3 intermediate revisions by 2 users not shown)
Line 1: Line 1:
This article is a comparison between the way [[Nix]] install packages to the filesystem hierarchy, and the [https://en.wikipedia.org/wiki/Linux_Standard_Base Linux Standard Base] (LSB) standard which most conventional Linux distributions, package managers and installers follow.
This article is a comparison between the [[Nix package manager]] and the [https://en.wikipedia.org/wiki/Linux_Standard_Base Linux Standard Base] (LSB) standard that the package managers of most conventional Linux distributions follow.


== Package Installation ==
== Package Installation ==


In most distributions, asking for a package to be installed, means having all its files available in the root filesystem (<code>/{,usr}/{bin,etc,lib,sbin,...}</code>).
In most distributions, files of an installed package are stored under <code>/{,usr}/{bin,etc,lib,...}</code>.


With Nix, the installed files of a package go into a ''profile'' (as if it was a rootfs), and you can have as many profiles as you want. There is the notion of each user having at least one profile, so `~/.nix-profile` points to the last version of the profile the user chose (last generation).
With Nix, the files of a package go into a ''profile'' (as if it was a rootfs), and users can have as many profiles as they want.


By default, the only part of the system made aware of the contents of the user profile is the PATH. The user PATH is set through bashrc to include `~/.nix-profile/bin`. So, by default, installing a Nix package means "having it in the PATH". A simple operation like <code>nix-env -i firefox</code> is meant to update the nix store, then generate a new profile in the store having all the programs ''installed'' plus the new one, and updating the symlink `~/.nix-profile`, so `~/.nix-profile/bin` will contain a symlink to the executable of firefox. Then a user can type <code>firefox</code> and have it running.
By default, the only part of the system made aware of the contents of the user profile is the PATH. The user PATH is set through bashrc to include `~/.nix-profile/bin`. So, by default, installing a Nix package means "having it in the PATH". A simple operation like <code>nix-env -i firefox</code> is meant to update the nix store, then generate a new profile in the store having all the programs ''installed'' plus the new one, and updating the symlink `~/.nix-profile`, so `~/.nix-profile/bin` will contain a symlink to the executable of firefox. Then a user can type <code>firefox</code> and have it running.
Line 31: Line 31:


== Modifying a Package ==
== Modifying a Package ==
In LSB distributions, after installing a package, you would go to /usr/whatever and edit the files you want to change.
In LSB distributions, files installed under {{ic|/usr}} can be edited by the user as needed.


With Nix, any files inside the store (/nix/store, where all nix installed files end up; ~/.nix-profile is a symlink to a store path), are meant to be read-only. That is, nix expects those files only under her control, and it is a requirement to allow rollbacks and reproducibility. Of course the owner of the nix store can change files there, but then you cannot expect rollbacks or reproducibility. "nix-store --verify --check-contents" will tell you if there are files modified in the store (since the creation of each store path). Although modifying a file in the store seems like an easy quick fix, it should be regarded as bad as modifying the memory of a running process, because it has almost all the analogous downsides.
Files in the Nix store ({{ic|/nix/store}}) are meant to be read-only and changes are only done using the {{ic|nix}} commands. {{ic|nix-store --verify --check-contents}} can be used to ensure integrity of the store data.


For a discussion of methods to make (durable) changes to Nix packages, see [[Modifying a Package]]
To make changes to Nix packages properly, see [[Modifying a Package]].


== See also ==
== See also ==


[https://ostree.readthedocs.io/en/stable/manual/related-projects/#nixos-nix OSTree comparison to NixOS] &mdash; OSTree, a project to offer FHS-compatible "stores" was in large part inspired by NixOS.
* [https://ostreedev.github.io/ostree/related-projects/#nixos--nix OSTree comparison to NixOS] &mdash; OSTree, a project to offer [https://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard FHS]-compatible "stores", was in large part inspired by NixOS.


[[Category:Pedias]]
[[Category:Pedias]]
142

edits