On Mon, May 21, 2012 at 10:11:32AM +0200, Felix Lange wrote: > Hi, > > I am currently evaluating Nix and it's universe of tools > for a company project and after playing with it for a while, > I'd like to discuss my considerations with the list. > > Our company, Travelping GmbH, is a producer of specialized telecommunications > equipment. The firmware for our devices is based on a custom Linux > distribution, TPLINO. In the project I'm working on, we're basically looking > for a new underpinning of TPLINO. We've been working with OpenWRT > for about 5 years now and there are some areas where it doesn't > satisfy our requirements anymore. > > Comparing to the alternatives provided by Yocto and Gentoo, > the Nix package manager seemed particularly attractive > for its ability to reliably generate whole system _configurations_ > and the advanced upgrade/rollback features. > > A closer look at Nix has revealed some questions: > > Cross Compilation > There seems to be some work in the nixpkgs tree that deals with > cross builds (pkgs/top-level/release-cross.nix). It would be interesing > to hear from the people who are behind this. Are cross > builds alive and supported?
Yes. A major problem we have is that we still don't cross-build *perl*, because it looks like not trivial. OpenWRT in this respect has some in-svn big files describing each system they cross-build too. Therefore, one troublesome piece to cross-build is nix itself. But many other programs cross-build fine. I wrote most of the cross-building pieces, and I use them both for preparing binaries for already-deployed OpenWRT systems, and also for full-prepared systems (nanonixos for the nanonote). http://viric.name/cgi-bin/nanonixos/doc/trunk/doc/home.wiki > Nix's binary size and runtime requirements: > Our usual size limit for images is 8MB compressed. With an image > that small, we need to be really picky about what goes in > and what doesn't. Quick measurement shows that Nix + libraries > take ~10MB on disk. AFAIK, Nix also requires the C++ STL. > > The size is only a problem for small devices which > have a very limited amount of flash memory available. > Those devices might also not be able to execute > Nix expressions because their CPU power and main memory is > limited. It seems Nix wasn't really designed to > run in resource-constrained environments. > > Has anybody run into similar issues before? Nix evaluation still requires quite a lot of RAM. In the Nanonote (32MB of RAM) I don't think I can't get evaluation far away. > Remote installation of packages: > As a follow-up thought to the last one, would it be possible > to update an installation remotely, with only a very limited set of > tools being present? I've looked at Disnix, and the README says > that all target hosts need to have Nix (and Nixpkgs) installed, > which is unfortunate but understandable given its intended > use case (server/cluster deployment). > > The Nix store file structure seems simple > enough to allow remote management. Is this correct? In nanonixos I use a very easy remote installation of packages. See http://viric.name/cgi-bin/nanonixos/artifact/ddf64d608c252cd3e655c56fe37228701bda7ef4 > Configuration changes: > System configuration (networking, services...) is not part of Nixpkgs > but is kept in the NixOS tree. This is good, because we have very > specific needs in terms of network configuration and implement > it ourselves anyway. > > How does Nix handle pre/post upgrade scripts? As far as I understand, > the Nixpkgs tree only contains build instructions, any output is created > at compile time. Nanonixos supplies a bit of this, in a simple way. Take a look of the files there: http://viric.name/cgi-bin/nanonixos/dir?ci=0faacb2bb92031a5 Feel free to clone the repository too. So as you see there is some work to do: * perl * nix cross-building with perl support (I think recent versions of nix don't cross-build anything at all, but we could do some effort for it) * nanonixos is a very simple remote deployment of a systemv GNU/Linux. Could be made more fancy like nixos. Regards, Lluís. _______________________________________________ nix-dev mailing list [email protected] http://lists.science.uu.nl/mailman/listinfo/nix-dev
