[Nix-dev] Porting NixOS

[Eelco Dolstra]

Hi,

Daniel Clark wrote:

> I'm in the process of seeing how hard it would be to port NixOS to
> non-intel architectures / boot loaders other than grub. Specifically
> I'm working with a Loongson 2f machine, which is a mipsel64 (64-bit
> MIPS little-endian) machine that uses the PMON 2000 boot loader.

It shouldn't be too hard (as long as you don't go the cross-compilation route,
as Armijn mentioned - I think Nix would be very suitable for cross-compilation
work like building embedded device images, but it just hasn't been done yet).
There are basically two things that have to be done:

- Add support for the boot loader.  Probably not so hard for the initial attempt
(e.g. just booting a specific configuration without support for rollbacks from
the boot loader).

- Create a pure stdenv for the platform, i.e. a stdenv that doesn't have runtime
or build-time dependencies on anything outside of the Nix store (e.g.
/lib/ld-linux.so or /usr/bin/gcc).  This is more work as it needs to be
bootstrapped on an existing Linux distribution for the platform.

The most important step is creating statically linked binaries which are then
used to build the stdenv (see
pkgs/stdenv/linux/bootstrap/{i686,x86_64,powerpc}).  There is a Nix expression
that generates these binaries (pkgs/stdenv/linux/make-bootstrap-tools.nix), but
it will probably need tweaking for new platforms (it uses a fairly ad-hoc mix of
dietlibc and static linking against glibc, since dietlibc tends to have
different bugs on every platform).  I can add some documentation to the manual
about this.

BTW, since there is a pure stdenv for powerpc-linux already, it should be fairly
easy to port NixOS to powerpc machines.

> At the moment I'm just starting to play with the build tools - I have
> nix built, and am working on compiling nixpkgs. Before I start down a
> path of naive stupidity, I thought I'd ping the list and see if anyone
> more familiar with the project had given thought on an architecture
> that would allow NixOS to revert to previous configurations as part of
> the normal boot process, instead of via a boot loader (even if PMON
> 2000 could be made to work like grub does, I think it would be too
> annoying to have to redo that integration with every random boot
> loader out there - there are more than you would think).

The main problem here is that the kernel is also part of the configuration, so
you can't change it after the kernel has already been loaded (well, maybe with
kexec...).

> I'd also like to know if there is any interest amongst the NixOS
> developers to make NixOS a distribution that would be compliant with
> the FSF/GNU Project's Guidelines for Free System Distributions [1] and
> thus recommendable by the Free Software Foundation, and if not if
> there would be any major objections to someone creating a NixOS
> variant that would be (as far as I can tell the Nix package management
> system would make such a fork much less disruptive and able to give
> back to core NixOS than other package management systems).

I don't think I would like separating the Nix expressions for non-free packages
from Nixpkgs, since that would make live more difficult for users who do want to
use a non-free package (say the NVIDIA driver), but it would be a good idea (as
discussed before) to have a meta attribute to mark non-free packages.  Then the
system can automatically warn you if there are any non-free packages in the
dependency graph of a particular configuration.  This would also help us to
prevent non-free packages from being distributed (in binary form) in the Nixpkgs
channel, which has happened accidentally in the past (e.g. Java 5 due to free
packages having it as a dependency).

OTOH when we have such an attribute, we can easily generate a Nixpkgs
distribution that doesn't contain non-free packages.

> I also think that Nix is just better suited than Debian for a
> operating system for people who really, really care about using only
> Free Software (think rms), as it looks like it is provable that a
> piece of software is derived only from other pieces of free software,
> and also possible to easily audit a distribution to make sure binaries
> that are not actually derivable from available free software sources
> are not included.

Yes, with the meta attribute you could really audit this.  In fact, with a
meta.license attribute you could conceivable do things like verify that
GPL-licensed packages aren't used in non-GPL packages, or whatever.  (A formal
calculus of licenses!)

-- 
Eelco Dolstra | http://www.st.ewi.tudelft.nl/~dolstra/