3 ms·

I use NixOS since last spring and I adore it so much that I almost credit it with making me like computers again. It's a kind of bumpy ride sometimes but for m

by mbrock 10y ago

I use NixOS since last spring and I adore it so much that I almost credit it with making me like computers again. It's a kind of bumpy ride sometimes but for me there's no other distribution that's even close. Packaging the Nix way does require patching upstream and that's probably inevitable. It would be nice to help with the documentation situation, though I'd note that the NixOS manual and the Nixpkgs manual are seriously helpful and quite comprehensive; it's just that there's another type of guide that would really help.

mbrock 10y ago
One fun thing I'm doing recently with NixOS is automatically deploying my system setup to a Hetzner server. NixOps deployment takes the server from scratch to finished clone of my laptop -- with a bit of server-specific configuration -- with zero manual intervention.
nextos 10y ago
GuixSD is close. It's the internal DSL (using Guile Scheme as host) version of Nix (which is an external DSL). Both have their own advantages. For example, I really like some of the reproducible binary efforts Guix has made [1]. And I prefer the way Guix packages some things. In Nix, I often found installing a seemingly innocent piece of software like mutt ended up installing python (!) by pulling all possible dependencies of mutt (like gpg), and in turn pulling all possible dependencies of gpg, which brought some X11 bindings and finally python. But Nix has some amazing stuff like NixOps. And it might be more mature. I know some corps like Logicblox use it for their deployments. [1] https://www.gnu.org/software/guix/manual/html_node/Invoking-guix-challenge.html https://www.gnu.org/software/guix/manual/html_node/Invoking-...
radarsat1 10y ago
> Packaging the Nix way does require patching upstream and that's probably inevitable. Not to familiar with Nix, can you explain why? Anything that can't be handled simply by applying small patches to the upstream during packaging?
- jorams 10y ago
  "patching upstream" in this context means "applying patches to the upstream during packaging". Nix and Guix require programs to work with a directory layout that differs significantly from the standard. Simple things like `#!/bin/python` don't work anymore, because they aren't explicit enough.
  - mbrock 10y ago
    Yeah, thanks. To add to that, the Nixpkgs "standard library" includes lots of convenient tools for patching like this, and much of the common stuff is done automatically by the standard package function. The #nixos IRC channel is a good place to ask if you run into trouble when packaging something. Generally, making NixOS packages is really delightful. Even the patching stuff is straightforward and easy to use. Now that I've learned the basics, I routinely make small packages. With many typical packages the only thing you need to do is specify how to fetch the source, plus the list of build dependencies, and there are built-in functions for fetching from HTTPS or Git.
  - radarsat1 10y ago
    Ah ok, that clarifies things. Thanks.
Chattered 10y ago
Your first sentence is very close to something I've said to others. NixOS is the first time I've been excited about an OS since first discovering Linux back in 2003. The OP mentions "the ability to do controlled per-user changes in an ad-hoc fashion". I assume they are referring to the use of "nix-env", which some members of the community frown upon. I've adopted the policy of not using it. My system is defined entirely by various ".nix" files, and for launching simple applications, such as firefox, I just have my xmonad configuration bind "C-SHIFT-F" to "nix-shell -p firefox --run firefox". For programs where I have more complicated environments, I have a "shell.nix" file in $HOME which contains a bunch of derivations that I commonly use, and I use "nix-shell -A" to enter them. For development, all of my projects now include a "default.nix" file. Typing "nix-shell" in the project directory then brings in my project's dependencies as well as the tools I want when developing on that project, such as a suitable Emacs with the appropriate packages already installed. I find I move these move ".nix" files frequently between different machines, and I really appreciate that I am put into reproducible development environments wherever they are. To reiterate what others have said below: the Nix package manager makes sure to share build inputs. If I start a new project and include a bunch of stuff in my "default.nix" that I use elsewhere, it costs nothing to enter the new environment.

by mbrock 10y ago

mbrock 10y ago

One fun thing I'm doing recently with NixOS is automatically deploying my system setup to a Hetzner server. NixOps deployment takes the server from scratch to finished clone of my laptop -- with a bit of server-specific configuration -- with zero manual intervention.

nextos 10y ago

GuixSD is close. It's the internal DSL (using Guile Scheme as host) version of Nix (which is an external DSL). Both have their own advantages. For example, I really like some of the reproducible binary efforts Guix has made [1]. And I prefer the way Guix packages some things. In Nix, I often found installing a seemingly innocent piece of software like mutt ended up installing python (!) by pulling all possible dependencies of mutt (like gpg), and in turn pulling all possible dependencies of gpg, which brought some X11 bindings and finally python. But Nix has some amazing stuff like NixOps. And it might be more mature. I know some corps like Logicblox use it for their deployments. [1] https://www.gnu.org/software/guix/manual/html_node/Invoking-guix-challenge.html https://www.gnu.org/software/guix/manual/html_node/Invoking-...

radarsat1 10y ago

> Packaging the Nix way does require patching upstream and that's probably inevitable. Not to familiar with Nix, can you explain why? Anything that can't be handled simply by applying small patches to the upstream during packaging?

jorams 10y ago
"patching upstream" in this context means "applying patches to the upstream during packaging". Nix and Guix require programs to work with a directory layout that differs significantly from the standard. Simple things like `#!/bin/python` don't work anymore, because they aren't explicit enough.
- mbrock 10y ago
  Yeah, thanks. To add to that, the Nixpkgs "standard library" includes lots of convenient tools for patching like this, and much of the common stuff is done automatically by the standard package function. The #nixos IRC channel is a good place to ask if you run into trouble when packaging something. Generally, making NixOS packages is really delightful. Even the patching stuff is straightforward and easy to use. Now that I've learned the basics, I routinely make small packages. With many typical packages the only thing you need to do is specify how to fetch the source, plus the list of build dependencies, and there are built-in functions for fetching from HTTPS or Git.
- radarsat1 10y ago
  Ah ok, that clarifies things. Thanks.

Chattered 10y ago

Your first sentence is very close to something I've said to others. NixOS is the first time I've been excited about an OS since first discovering Linux back in 2003. The OP mentions "the ability to do controlled per-user changes in an ad-hoc fashion". I assume they are referring to the use of "nix-env", which some members of the community frown upon. I've adopted the policy of not using it. My system is defined entirely by various ".nix" files, and for launching simple applications, such as firefox, I just have my xmonad configuration bind "C-SHIFT-F" to "nix-shell -p firefox --run firefox". For programs where I have more complicated environments, I have a "shell.nix" file in $HOME which contains a bunch of derivations that I commonly use, and I use "nix-shell -A" to enter them. For development, all of my projects now include a "default.nix" file. Typing "nix-shell" in the project directory then brings in my project's dependencies as well as the tools I want when developing on that project, such as a suitable Emacs with the appropriate packages already installed. I find I move these move ".nix" files frequently between different machines, and I really appreciate that I am put into reproducible development environments wherever they are. To reiterate what others have said below: the Nix package manager makes sure to share build inputs. If I start a new project and include a bunch of stuff in my "default.nix" that I use elsewhere, it costs nothing to enter the new environment.