9 ms·

NixOS - Declarative configuration OS

244 points by wamatt 13y ago

denysonique 13y ago
Interesting, how is it different from Gentoo Linux?
- vitno 13y ago
  check this page out to understand the underlying philosophy: http://nixos.org/nix/ http://nixos.org/nix/
- durbatuluk 13y ago
  gentoo need slot support for similar behavior
mbell 13y ago
What linux needs is another package manager...
- zaphar 13y ago
  Nix is an experimental Research OS exploring what you can do with a pure functional package manager. This is interesting. You are probably being downvoted because your comment looks like a poor attempt to cash in on the "What linux needs is another..." meme for some easy karma. But let's take you at face value. Maybe you were serious in your assertion. While Ubuntu, Debian, Fedor, Gentoo, and many other distros use very mature, robust and all around awesome package managers I still run into issues where a package is uninstallable because of some other package that it depends on is pinned, or the wrong version, or any number of other reasons. Nix fixes exactly this problem while still maintaining many of the same benefits as the other package manager. So maybe Linux does need another package manager. Or at least it needs people willing to play around with solving issues in the current package managers in a "research" setting perhaps?
  - deleted 13y ago
    [deleted]
    - pekk 13y ago
      Improve in what way? This puts any design change off the table forever. I don't see anything wrong with a rethink, as long as it's motivated. Maybe the motivation has not been well-stated - but maybe you haven't made it any clearer that dpkg or rpm are the optimal package managers (barring a few little 'improvement' patches here or there). Just blasting the project in the most generic terms is avoiding the necessary thinking about what the goals should be and what are good ways of achieving them.
      - deleted 13y ago
        [deleted]
    - v13inc 13y ago
      I think this comment from jacques_chester [1] does an excellent job at explaining why it is important to break free from this mindset periodically. It is all about busting out of local maxima in the efficiency of our tools. [1] https://news.ycombinator.com/item?id=5727876 https://news.ycombinator.com/item?id=5727876
      - jacques_chester 13y ago
        Local maxima, exactly. We often lose sight of how and why we are at a particular maxima and assume that the current layering is the only acceptable layering. But sometimes it's just accidents, or was just the shortest path to a working system, or lots of little local solutions that agglomerated into larger global solutions. Every once in a while punching through the old layers is useful. Not always. Sometimes. Having a sense of history makes this easier ... and harder. Sometimes the outcome is so stunningly obviously better that everyone slaps their foreheads and wonders how it could have been any other way. Other times ... well, other times we all spend our workdays arguing about it on HN.
    - smilekzs 13y ago
- banachtarski 13y ago
  And fewer asshats.
- noonespecial 13y ago
  What linux needs is a better package manager. I'm not convinced that the entire solution space has been explored yet so I welcome all newcomers.
laurentoget 13y ago
http://audio-video.gnu.org/video/ghm2009/ghm2009-dolstra-large.ogg http://audio-video.gnu.org/video/ghm2009/ghm2009-dolstra-lar... this talk by Eelco is a good introduction for hacker types. And the motivation is at the beginning of the talk.
yowmamasita 13y ago
This "Multi-user package management" is a really neat feature, I wonder if there are other distro's having that.
- aphexairlines 13y ago
  Multi-user and multi-aplication (different applications can depend on different versions of a shared library). Here's another example that's not public, and not really a distro, but... http://stackoverflow.com/questions/3380795/what-does-amazon-use-for-its-build-and-release-system http://stackoverflow.com/questions/3380795/what-does-amazon-...
- lholden 13y ago
  GoboLinux works in a very similar manner, though I'm not sure the distro has seen any love in a few years.
- drdaeman 13y ago
  I've read dpkg has `dpkg -i --force-not-root --root=$HOME/.local package.deb` options, but I haven't ever tried those myself.
subprotocol 13y ago
Interesting, sounds like puppet/chef at the OS level.
- jacques_chester 13y ago
  I've long suspected that something like this was the logical end point. Ever since I found myself writing a Puppet manifest that created an Upstart entry. Configuration engines have tended to emphasise bits-at-rest. "Make sure these packages are installed, that these files are present, that this is what's in /etc". Process management engines emphasise bits-in-flight. "Make sure Wordpress is running. Wordpress relies on PHP, nginx and MySQL". Generally speaking, config engines assume that the bits-at-rest are correctly arranged to ensure correct runtime performance. And process management assumes that someone else has supplied the bits-at-rest which can be reified into an operational system. Configuration engines tend to stray a bit into ensuring that software is up and running (eg, cfengine polls services every 5 minutes), but stop well short of the final conclusion of process management: insertion into the init hierarchy. Why the separation? It's historical. Each local problem was solved in isolation (broken server config / crashing server processes) and they've each grown at the edges towards each other. Just as ZFS collapsed several historical layers of file system tools into a single layer, it's been long overdue for the concept of defining a model of a system's various configurations with a detect-and-correct mechanism to be a universal framework that applies across an entire system.
  - bensummers 13y ago
    Solaris' SMF and fault management framework is a very good step towards what you're after, plus it's mature and suitable for use in production. http://www.oracle.com/technetwork/articles/servers-storage-admin/intro-smf-basics-s11-1729181.html http://www.oracle.com/technetwork/articles/servers-storage-a... Don't let the XML configuration put you off. I suspect they'd have used JSON if they were doing it again, but it's from the era when XML was the default structured text based format. If you want to play with this (and IPS as mentioned above), try OmniOS: http://omnios.omniti.com/ http://omnios.omniti.com/
    - 13y ago
durbatuluk 13y ago
I tried this distro 2 times since I heard of this rootless package administration. I give up because of poor documentation in both situations. I would love to see this approach in arch or gentoo (without the butthurt of slots)
- davorak 13y ago
  That is too bad it has worked fairly well on vmware for me. I have also enjoyed using the nix package manager on my macbook as well. The documentation can be lite on examples but it is very forgiving distribution to experiment with and I do not see to bump in to corner cases as often as I have on other linux flavors/package manager.
binarycrusader 13y ago
Some of the ideas seen in NixOS can also be seen in the Image Packaging System (Atomic Upgrades, Reliable Upgrades) project: https://java.net/projects/ips/pages/Home https://java.net/projects/ips/pages/Home Disclaimer: I'm also one of the IPS authors, so I agree with some of NixOS' ideas :-)
- davorak 13y ago
  I read one article and skimmed the other under "Background reading" but I could not spot what the core philosophy or mechanic of how you are producing atomic and reliable upgrades. I try to stay abreast of package systems which have the same or close feature set as nix. If you have a moment to explain the core mechanic or a reference it would be much appreciated.
  - binarycrusader 13y ago
    The "no scripting zone" and "no more installer magic" background posts have some of the philosophy. But really a lot of the atomic and reliable aspects are the result of integration with ZFS. When the user upgrades packages, we create a backup boot environment (clone of the root file system) and then update the packages. If anything goes wrong, the user can just reboot to the backup be. When updating the system (that is, packages that require the kernel to be reloaded/system rebooted), we create a clone of the root file system (a boot environment) and update the clone. When the update finishes, the admin can then reboot the system at their leisure. If you'd like to know more, I'll try to answer your questions. You can email me at $myusername at gmail dot com.
    - binarycrusader 13y ago
      If anyone is wondering, I suspect you could take IPS and integrate with btrfs instead. The abstractions are generic and btrfs is growing the required functionality as time goes on.
      - laumars 13y ago
GigabyteCoin 13y ago
After playing around with Arch for the last few weeks, this is incredibly interesting to myself. Does anybody have any experience/testaments to post about this OS?
- davorak 13y ago
  Sure, nixos is very forgiving to experiment with because you can easily rollback to a pervious configuration. Modify a library and something stops working fixing it is as simple as `nix-env --rollback` for a user package and `nixos-rebuild --rollback` if something was changed with the system configuration a restart may be needed if some systems are touched but it has not happened often and when it is needed it is specified. I enjoy how easy it is to set up different profiles with different sets of libraries/compilers for development. It has made it worth while to try out old libraries that only work on old compilers. It also made it easier for me to test against the HEAD of the complier repo for testing forward compatibility or new compiler features. Since everything is nicely encapsulated once I have an environment working on my laptop I can use `nix-copy-closure` to move it to another remote server. `Nixops` a more recent offering just renamed from `charon` also allows for deterministic building of ec2 instances.
- jrn 13y ago
  took me a while to figure out. nix-env -qa * | grep "package you are looking for" nix-env -i "package" need to add different channels if you are grabbing packages from places other than nix-pkgs. I had a hard time, getting some haskell packages to work, because nixos symlinks all the binaries, and there was some encryption library dependency, hard coded in a cabal file, and it was a headache/ gave up. Eelco also provides a pathelf utility for modifiying dynamic linker in elf files, I haven't used it. I'm on ubuntu again but I can't remember why. Oh ya, I couldn't get Blackberry's SDK working on nixos. Anything that doesn't go through nix-pkgs, will take some work. I didn't get to the point where I was writing nix-expressions.
- edwintorok 13y ago
  If you run it in a VM (KVM/QEMU) you might need to set some CPU flags for the VM (otherwise GMP will assume your CPU has some instructions that it doesn't actually have in the VM): https://github.com/NixOS/nixos/issues/120#issuecomment-14776203 https://github.com/NixOS/nixos/issues/120#issuecomment-14776... Other than that it works fairly well (in a VM), and you don't need to wait for it to compile all the packages like with Gentoo: if the build server has a binary then it will download that.
noonespecial 13y ago
We seem to be heading for a future where every application is run in a virtualized OS, configured and launched on demand.
- skrebbel 13y ago
  We seem to be heading for a future where the only application run locally is a web browser.
  - TheLegace 13y ago
    Ya I very much doubt that. It just looks more people who barely do anything productive are on the Internet just using Youtube and Netflix. While the people who are developing say something like Youtube(or god forbid something more useful and complicated) are left to fend for themselves, because hey what do they matter.
  - tensor 13y ago
    We seem to be making the same unrealistically broad generalizations over and over, never learning from our past.
  - kryptiskt 13y ago
    We seem to be heading for a future where every website says "Don't look at this, download our app!".
  - Zigurd 13y ago
    There are at least three reasons that won't happen: 1. Horses for courses: Once you get past superficial similarity, the Web isn't a universal application runtime. It is more appropriate for some kinds of apps, such as publication media, form-filling, etc. than others, such as apps with fine-grained interactivity, apps with significant endpoint computation, etc. 2. Nobody has cracked the "write once, test everywhere" curse of multiple implementations of a standard, never mind a standard as complex, and with such a long legacy tail as Web browsers. Web app frameworks still devote a lot of code to compatibility. "Native" also means "a single vendor's runtime." 3. Operating systems are different, and there are varying approaches to portability. Running in a universal runtime is one approach, and it has inherent compromises. For example, Microsoft has applications for editing Office documents for Windows, Mac OS X, and for Web browsers. Which one has limitations both in terms of integrating OS features and UI conventions, and it terms of functionality?
oakaz 13y ago
That's exactly what the Linux community needs: abstractions made for people who want to save time.
- vdm 13y ago
  IOW, not "the super-engineer, an idealised and imaginary extension of the Unix hackers of the era that gave birth to Unix, GNU, and finally Linux." http://www.listbox.com/member/archive/182179/2013/05/sort/time_rev/page/1/entry/1:75/20130508172342:8CF96552-B825-11E2-98EE-8CBB5940B2DC/ http://www.listbox.com/member/archive/182179/2013/05/sort/ti...
  - drivebyacct2 13y ago
    In my mind, it's a much better engineered solution to have a centralized, repeatable set of configurations than to have them spread out wherever in the filesystem.
    - qu4z-2 13y ago
      Whenever I hear "centralized configurations" I think of the Registry and shudder. But the issue there isn't the centralization, so it's probably unfair.
foohbarbaz 13y ago
This is a move in the right direction: === On NixOS, you do not need to be root to install software. In addition to the system-wide ‘profile’ (set of installed packages), all user have their own profile in which they can install packages. Nix allows multiple versions of a package to coexist, so different users can have different versions of the same package installed in their respective profiles. If two users install the same version of a package, only one copy will be built or downloaded, and Nix’s security model ensures that this is secure. Users cannot install setuid binaries. === Requirement to be administrator to install software is the root of all evils in managing OS. As far as keeping everything in a special location (/nix or whatever), this reminds me SCO OpenServer 5: they had all the files somewhere in /var; /bin, /sbin and everything else were just symlinks. It did not work all that well.
- dEnigma 13y ago
  >[...]the root of all evils[...] Pun intended? ;)
- alcidesfonseca 13y ago
  Why did it now work all that well in SCO OpenServer 5?
- gnoway 13y ago
  It was mostly in /opt, although there were also some things in /var.
qznc 13y ago
Rhe Red Hat/Fedora package manager yum also provides a rollback mechanidm. No user installation, though.
- davorak 13y ago
  Does it also provide multiple versions of the same package running side by side? That is one of the more useful features of nix to me.
  - qznc 13y ago
    Installing multiple versions is not the problem. The problem is configuring packages with respect to their dependencies. Nix enables per user installations and different users can use different versions of a package. What Nix cannot do (as far as i know), is using multiple versions as the same user. For example, Flash once broke due to change in the GNU libc. Can Nix use a different libc version for a specific browser plugin?
    - nbp 13y ago
      Nix can do that, you can easily use nix-env to create a new profile instead of using the default one stored in ~/.nix-profile . I am using multiple tool-chains stored in multiple profiles for my development process.
    - davorak 13y ago
      nbp is correct it is not a problem for the same user to install multiple versions of the same package. > Can Nix use a different libc version for a specific browser plugin? Are you asking about the case where the browser depends on a newer version of libc then the plugin?
topbanana 13y ago
I'm not a Linux expert, but it seems some dependency issues won't be resolved by this e.g. Glibc conflicts. Or would it?
- davorak 13y ago
  Is there something special about glibc conflicts that goes beyond normal versioning conflicts? Package A could depending on glibc-2.13 and package b could depend on glibc-2.17. No conflicts would because by both running at the same time.
  - topbanana 13y ago
    I had a hell of a time installing something in Ubuntu that required a particular glibc version that was differnt to the system--wide one. Like I said, I'm not Linux expert and I probably missed a trick. I ended up using a different distro. Would this new distro have helped?
    - chubot 13y ago
      I think in the Nix world, you would have two or more different glibc versions at different paths. Then the applications are configured to link against the required versions. Nix has extra build metadata that calls GNU configure as far as I can tell, and that is where this knowledge would lie. So you can run two programs side by side with different glibc versions in Nix. On Ubuntu, I think this is mostly not possible, as you have found.
      - qznc 13y ago
        As far as i understand Nix, two users could have different glibc versions, but two programs of a single user?
        chubot 13y ago
        Two different versions will definitely live at different paths, since the path contains the content hash. The path doesn't have much to do with the user name; that's a separate issue.
ztzg 13y ago
For those with a penchant for parentheses, there is also GNU Guix, which just had a second alpha release: http://lists.gnu.org/archive/html/bug-guix/2013-05/msg00034.html http://lists.gnu.org/archive/html/bug-guix/2013-05/msg00034.... It shares concepts and some bits with NixOS, but replaces the configuration language with Guile, an implementation of Scheme.
yarou 13y ago
Having installed NixOS over a year ago, I was really impressed with the package manager. It's wonderful to be able to have multiple versions of GCC, haskell, etc side by side, so you can debug some of the reasons why your program works in one user's version/environment but not the other's. The actual papers are an interesting read as well.
snowpalmer 13y ago
The way they install multiple versions of applications and manage the dependencies reminds me of GoboLinux. I like the direction of this. Really like how they named everything though in Gobo. http://wiki.gobolinux.org/index.php?title=The_GoboLinux_Filesystem_Hierarchy http://wiki.gobolinux.org/index.php?title=The_GoboLinux_File...
- gw 13y ago
  I remember playing with Gobo several years back. Although renaming system directories makes it a bit more approachable to newcomers, it also makes it less language independent and less recognizable to the users who typically need to use it (sys admins and such). However, the general idea of installing things in a self-contained directory was fantastic, and I'm happy to see another operating system trying something similar. I used to use PC-BSD regularly, whose package manager also does this: http://www.pcbsd.org/en/package-management/ http://www.pcbsd.org/en/package-management/
  - snowpalmer 13y ago
    Interesting. I never knew PC-BSD did this. Been probably 10 years since I gave a BSD variant a try.
brini 13y ago
Interesting critique by a Debian developer: http://lists.debian.org/debian-devel/2008/12/msg01027.html http://lists.debian.org/debian-devel/2008/12/msg01027.html
- cwp 13y ago
  Not interesting at all. He doesn't understand what nix is doing or why, and just points out all the ways that it's different from Debian.
deleted 13y ago
[deleted]
drivebyacct2 13y ago
KDE4? Systemd? Experimental? Centralized, versioned configuration? Sounds very, very cool. Worthy of being installed on something around here...
gfxmonk 13y ago
For a more application-level (rather than OS-level) approach that shares a lot of good ideas with NixOS, there's also ZeroInstall (http://0install.net http://0install.net). There's a comparison with Nix at http://0install.net/comparison.html#Nix http://0install.net/comparison.html#Nix.

244 points by wamatt 13y ago

denysonique 13y ago

Interesting, how is it different from Gentoo Linux?

vitno 13y ago
check this page out to understand the underlying philosophy: http://nixos.org/nix/ http://nixos.org/nix/
durbatuluk 13y ago
gentoo need slot support for similar behavior

mbell 13y ago

What linux needs is another package manager...

zaphar 13y ago
Nix is an experimental Research OS exploring what you can do with a pure functional package manager. This is interesting. You are probably being downvoted because your comment looks like a poor attempt to cash in on the "What linux needs is another..." meme for some easy karma. But let's take you at face value. Maybe you were serious in your assertion. While Ubuntu, Debian, Fedor, Gentoo, and many other distros use very mature, robust and all around awesome package managers I still run into issues where a package is uninstallable because of some other package that it depends on is pinned, or the wrong version, or any number of other reasons. Nix fixes exactly this problem while still maintaining many of the same benefits as the other package manager. So maybe Linux does need another package manager. Or at least it needs people willing to play around with solving issues in the current package managers in a "research" setting perhaps?
- deleted 13y ago
  [deleted]
  - pekk 13y ago
    Improve in what way? This puts any design change off the table forever. I don't see anything wrong with a rethink, as long as it's motivated. Maybe the motivation has not been well-stated - but maybe you haven't made it any clearer that dpkg or rpm are the optimal package managers (barring a few little 'improvement' patches here or there). Just blasting the project in the most generic terms is avoiding the necessary thinking about what the goals should be and what are good ways of achieving them.
    - deleted 13y ago
      [deleted]
  - v13inc 13y ago
    I think this comment from jacques_chester [1] does an excellent job at explaining why it is important to break free from this mindset periodically. It is all about busting out of local maxima in the efficiency of our tools. [1] https://news.ycombinator.com/item?id=5727876 https://news.ycombinator.com/item?id=5727876
    - jacques_chester 13y ago
      Local maxima, exactly. We often lose sight of how and why we are at a particular maxima and assume that the current layering is the only acceptable layering. But sometimes it's just accidents, or was just the shortest path to a working system, or lots of little local solutions that agglomerated into larger global solutions. Every once in a while punching through the old layers is useful. Not always. Sometimes. Having a sense of history makes this easier ... and harder. Sometimes the outcome is so stunningly obviously better that everyone slaps their foreheads and wonders how it could have been any other way. Other times ... well, other times we all spend our workdays arguing about it on HN.
  - smilekzs 13y ago
banachtarski 13y ago
And fewer asshats.
noonespecial 13y ago
What linux needs is a better package manager. I'm not convinced that the entire solution space has been explored yet so I welcome all newcomers.

laurentoget 13y ago

http://audio-video.gnu.org/video/ghm2009/ghm2009-dolstra-large.ogg http://audio-video.gnu.org/video/ghm2009/ghm2009-dolstra-lar... this talk by Eelco is a good introduction for hacker types. And the motivation is at the beginning of the talk.

yowmamasita 13y ago

This "Multi-user package management" is a really neat feature, I wonder if there are other distro's having that.

aphexairlines 13y ago
Multi-user and multi-aplication (different applications can depend on different versions of a shared library). Here's another example that's not public, and not really a distro, but... http://stackoverflow.com/questions/3380795/what-does-amazon-use-for-its-build-and-release-system http://stackoverflow.com/questions/3380795/what-does-amazon-...
lholden 13y ago
GoboLinux works in a very similar manner, though I'm not sure the distro has seen any love in a few years.
drdaeman 13y ago
I've read dpkg has `dpkg -i --force-not-root --root=$HOME/.local package.deb` options, but I haven't ever tried those myself.

subprotocol 13y ago

Interesting, sounds like puppet/chef at the OS level.

jacques_chester 13y ago
I've long suspected that something like this was the logical end point. Ever since I found myself writing a Puppet manifest that created an Upstart entry. Configuration engines have tended to emphasise bits-at-rest. "Make sure these packages are installed, that these files are present, that this is what's in /etc". Process management engines emphasise bits-in-flight. "Make sure Wordpress is running. Wordpress relies on PHP, nginx and MySQL". Generally speaking, config engines assume that the bits-at-rest are correctly arranged to ensure correct runtime performance. And process management assumes that someone else has supplied the bits-at-rest which can be reified into an operational system. Configuration engines tend to stray a bit into ensuring that software is up and running (eg, cfengine polls services every 5 minutes), but stop well short of the final conclusion of process management: insertion into the init hierarchy. Why the separation? It's historical. Each local problem was solved in isolation (broken server config / crashing server processes) and they've each grown at the edges towards each other. Just as ZFS collapsed several historical layers of file system tools into a single layer, it's been long overdue for the concept of defining a model of a system's various configurations with a detect-and-correct mechanism to be a universal framework that applies across an entire system.
- bensummers 13y ago
  Solaris' SMF and fault management framework is a very good step towards what you're after, plus it's mature and suitable for use in production. http://www.oracle.com/technetwork/articles/servers-storage-admin/intro-smf-basics-s11-1729181.html http://www.oracle.com/technetwork/articles/servers-storage-a... Don't let the XML configuration put you off. I suspect they'd have used JSON if they were doing it again, but it's from the era when XML was the default structured text based format. If you want to play with this (and IPS as mentioned above), try OmniOS: http://omnios.omniti.com/ http://omnios.omniti.com/
  - 13y ago

durbatuluk 13y ago

I tried this distro 2 times since I heard of this rootless package administration. I give up because of poor documentation in both situations. I would love to see this approach in arch or gentoo (without the butthurt of slots)

davorak 13y ago
That is too bad it has worked fairly well on vmware for me. I have also enjoyed using the nix package manager on my macbook as well. The documentation can be lite on examples but it is very forgiving distribution to experiment with and I do not see to bump in to corner cases as often as I have on other linux flavors/package manager.

binarycrusader 13y ago

Some of the ideas seen in NixOS can also be seen in the Image Packaging System (Atomic Upgrades, Reliable Upgrades) project: https://java.net/projects/ips/pages/Home https://java.net/projects/ips/pages/Home Disclaimer: I'm also one of the IPS authors, so I agree with some of NixOS' ideas :-)

davorak 13y ago
I read one article and skimmed the other under "Background reading" but I could not spot what the core philosophy or mechanic of how you are producing atomic and reliable upgrades. I try to stay abreast of package systems which have the same or close feature set as nix. If you have a moment to explain the core mechanic or a reference it would be much appreciated.
- binarycrusader 13y ago
  The "no scripting zone" and "no more installer magic" background posts have some of the philosophy. But really a lot of the atomic and reliable aspects are the result of integration with ZFS. When the user upgrades packages, we create a backup boot environment (clone of the root file system) and then update the packages. If anything goes wrong, the user can just reboot to the backup be. When updating the system (that is, packages that require the kernel to be reloaded/system rebooted), we create a clone of the root file system (a boot environment) and update the clone. When the update finishes, the admin can then reboot the system at their leisure. If you'd like to know more, I'll try to answer your questions. You can email me at $myusername at gmail dot com.
  - binarycrusader 13y ago
    If anyone is wondering, I suspect you could take IPS and integrate with btrfs instead. The abstractions are generic and btrfs is growing the required functionality as time goes on.
    - laumars 13y ago

GigabyteCoin 13y ago

After playing around with Arch for the last few weeks, this is incredibly interesting to myself. Does anybody have any experience/testaments to post about this OS?

davorak 13y ago
Sure, nixos is very forgiving to experiment with because you can easily rollback to a pervious configuration. Modify a library and something stops working fixing it is as simple as `nix-env --rollback` for a user package and `nixos-rebuild --rollback` if something was changed with the system configuration a restart may be needed if some systems are touched but it has not happened often and when it is needed it is specified. I enjoy how easy it is to set up different profiles with different sets of libraries/compilers for development. It has made it worth while to try out old libraries that only work on old compilers. It also made it easier for me to test against the HEAD of the complier repo for testing forward compatibility or new compiler features. Since everything is nicely encapsulated once I have an environment working on my laptop I can use `nix-copy-closure` to move it to another remote server. `Nixops` a more recent offering just renamed from `charon` also allows for deterministic building of ec2 instances.
jrn 13y ago
took me a while to figure out. nix-env -qa * | grep "package you are looking for" nix-env -i "package" need to add different channels if you are grabbing packages from places other than nix-pkgs. I had a hard time, getting some haskell packages to work, because nixos symlinks all the binaries, and there was some encryption library dependency, hard coded in a cabal file, and it was a headache/ gave up. Eelco also provides a pathelf utility for modifiying dynamic linker in elf files, I haven't used it. I'm on ubuntu again but I can't remember why. Oh ya, I couldn't get Blackberry's SDK working on nixos. Anything that doesn't go through nix-pkgs, will take some work. I didn't get to the point where I was writing nix-expressions.
edwintorok 13y ago
If you run it in a VM (KVM/QEMU) you might need to set some CPU flags for the VM (otherwise GMP will assume your CPU has some instructions that it doesn't actually have in the VM): https://github.com/NixOS/nixos/issues/120#issuecomment-14776203 https://github.com/NixOS/nixos/issues/120#issuecomment-14776... Other than that it works fairly well (in a VM), and you don't need to wait for it to compile all the packages like with Gentoo: if the build server has a binary then it will download that.

noonespecial 13y ago

We seem to be heading for a future where every application is run in a virtualized OS, configured and launched on demand.

skrebbel 13y ago
We seem to be heading for a future where the only application run locally is a web browser.
- TheLegace 13y ago
  Ya I very much doubt that. It just looks more people who barely do anything productive are on the Internet just using Youtube and Netflix. While the people who are developing say something like Youtube(or god forbid something more useful and complicated) are left to fend for themselves, because hey what do they matter.
- tensor 13y ago
  We seem to be making the same unrealistically broad generalizations over and over, never learning from our past.
- kryptiskt 13y ago
  We seem to be heading for a future where every website says "Don't look at this, download our app!".
- Zigurd 13y ago
  There are at least three reasons that won't happen: 1. Horses for courses: Once you get past superficial similarity, the Web isn't a universal application runtime. It is more appropriate for some kinds of apps, such as publication media, form-filling, etc. than others, such as apps with fine-grained interactivity, apps with significant endpoint computation, etc. 2. Nobody has cracked the "write once, test everywhere" curse of multiple implementations of a standard, never mind a standard as complex, and with such a long legacy tail as Web browsers. Web app frameworks still devote a lot of code to compatibility. "Native" also means "a single vendor's runtime." 3. Operating systems are different, and there are varying approaches to portability. Running in a universal runtime is one approach, and it has inherent compromises. For example, Microsoft has applications for editing Office documents for Windows, Mac OS X, and for Web browsers. Which one has limitations both in terms of integrating OS features and UI conventions, and it terms of functionality?

oakaz 13y ago

That's exactly what the Linux community needs: abstractions made for people who want to save time.

vdm 13y ago
IOW, not "the super-engineer, an idealised and imaginary extension of the Unix hackers of the era that gave birth to Unix, GNU, and finally Linux." http://www.listbox.com/member/archive/182179/2013/05/sort/time_rev/page/1/entry/1:75/20130508172342:8CF96552-B825-11E2-98EE-8CBB5940B2DC/ http://www.listbox.com/member/archive/182179/2013/05/sort/ti...
- drivebyacct2 13y ago
  In my mind, it's a much better engineered solution to have a centralized, repeatable set of configurations than to have them spread out wherever in the filesystem.
  - qu4z-2 13y ago
    Whenever I hear "centralized configurations" I think of the Registry and shudder. But the issue there isn't the centralization, so it's probably unfair.

foohbarbaz 13y ago

This is a move in the right direction: === On NixOS, you do not need to be root to install software. In addition to the system-wide ‘profile’ (set of installed packages), all user have their own profile in which they can install packages. Nix allows multiple versions of a package to coexist, so different users can have different versions of the same package installed in their respective profiles. If two users install the same version of a package, only one copy will be built or downloaded, and Nix’s security model ensures that this is secure. Users cannot install setuid binaries. === Requirement to be administrator to install software is the root of all evils in managing OS. As far as keeping everything in a special location (/nix or whatever), this reminds me SCO OpenServer 5: they had all the files somewhere in /var; /bin, /sbin and everything else were just symlinks. It did not work all that well.

dEnigma 13y ago
>[...]the root of all evils[...] Pun intended? ;)
alcidesfonseca 13y ago
Why did it now work all that well in SCO OpenServer 5?
gnoway 13y ago
It was mostly in /opt, although there were also some things in /var.

qznc 13y ago

Rhe Red Hat/Fedora package manager yum also provides a rollback mechanidm. No user installation, though.

davorak 13y ago
Does it also provide multiple versions of the same package running side by side? That is one of the more useful features of nix to me.
- qznc 13y ago
  Installing multiple versions is not the problem. The problem is configuring packages with respect to their dependencies. Nix enables per user installations and different users can use different versions of a package. What Nix cannot do (as far as i know), is using multiple versions as the same user. For example, Flash once broke due to change in the GNU libc. Can Nix use a different libc version for a specific browser plugin?
  - nbp 13y ago
    Nix can do that, you can easily use nix-env to create a new profile instead of using the default one stored in ~/.nix-profile . I am using multiple tool-chains stored in multiple profiles for my development process.
  - davorak 13y ago
    nbp is correct it is not a problem for the same user to install multiple versions of the same package. > Can Nix use a different libc version for a specific browser plugin? Are you asking about the case where the browser depends on a newer version of libc then the plugin?

topbanana 13y ago

I'm not a Linux expert, but it seems some dependency issues won't be resolved by this e.g. Glibc conflicts. Or would it?

davorak 13y ago
Is there something special about glibc conflicts that goes beyond normal versioning conflicts? Package A could depending on glibc-2.13 and package b could depend on glibc-2.17. No conflicts would because by both running at the same time.
- topbanana 13y ago
  I had a hell of a time installing something in Ubuntu that required a particular glibc version that was differnt to the system--wide one. Like I said, I'm not Linux expert and I probably missed a trick. I ended up using a different distro. Would this new distro have helped?
  - chubot 13y ago
    I think in the Nix world, you would have two or more different glibc versions at different paths. Then the applications are configured to link against the required versions. Nix has extra build metadata that calls GNU configure as far as I can tell, and that is where this knowledge would lie. So you can run two programs side by side with different glibc versions in Nix. On Ubuntu, I think this is mostly not possible, as you have found.
    - qznc 13y ago
      As far as i understand Nix, two users could have different glibc versions, but two programs of a single user?
      - chubot 13y ago
        Two different versions will definitely live at different paths, since the path contains the content hash. The path doesn't have much to do with the user name; that's a separate issue.

ztzg 13y ago

For those with a penchant for parentheses, there is also GNU Guix, which just had a second alpha release: http://lists.gnu.org/archive/html/bug-guix/2013-05/msg00034.html http://lists.gnu.org/archive/html/bug-guix/2013-05/msg00034.... It shares concepts and some bits with NixOS, but replaces the configuration language with Guile, an implementation of Scheme.

yarou 13y ago

Having installed NixOS over a year ago, I was really impressed with the package manager. It's wonderful to be able to have multiple versions of GCC, haskell, etc side by side, so you can debug some of the reasons why your program works in one user's version/environment but not the other's. The actual papers are an interesting read as well.

snowpalmer 13y ago

The way they install multiple versions of applications and manage the dependencies reminds me of GoboLinux. I like the direction of this. Really like how they named everything though in Gobo. http://wiki.gobolinux.org/index.php?title=The_GoboLinux_Filesystem_Hierarchy http://wiki.gobolinux.org/index.php?title=The_GoboLinux_File...

gw 13y ago
I remember playing with Gobo several years back. Although renaming system directories makes it a bit more approachable to newcomers, it also makes it less language independent and less recognizable to the users who typically need to use it (sys admins and such). However, the general idea of installing things in a self-contained directory was fantastic, and I'm happy to see another operating system trying something similar. I used to use PC-BSD regularly, whose package manager also does this: http://www.pcbsd.org/en/package-management/ http://www.pcbsd.org/en/package-management/
- snowpalmer 13y ago
  Interesting. I never knew PC-BSD did this. Been probably 10 years since I gave a BSD variant a try.

brini 13y ago

Interesting critique by a Debian developer: http://lists.debian.org/debian-devel/2008/12/msg01027.html http://lists.debian.org/debian-devel/2008/12/msg01027.html

cwp 13y ago
Not interesting at all. He doesn't understand what nix is doing or why, and just points out all the ways that it's different from Debian.

deleted 13y ago

[deleted]

drivebyacct2 13y ago

KDE4? Systemd? Experimental? Centralized, versioned configuration? Sounds very, very cool. Worthy of being installed on something around here...

gfxmonk 13y ago

For a more application-level (rather than OS-level) approach that shares a lot of good ideas with NixOS, there's also ZeroInstall (http://0install.net http://0install.net). There's a comparison with Nix at http://0install.net/comparison.html#Nix http://0install.net/comparison.html#Nix.