Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

My experience with NixOS

blog.patchgirl.io

Post reply on HN
Print view View original

71–80 of 95 posts

Re: My experience with NixOS

#71

Post by takeda »

throwaway894345 wrote: post #66
beefee wrote: post #50

Earlier quoted context omitted.

Nix has a way of exposing complex and low-quality build systems. Many pieces of the Python ecosystem fall into this category. For example, it wasn't Nix's fault that psycopg2 had a dependency on postgresql C header files, nor was it Nix's fault that the postgresql headers had to be rearranged for psycopg2's build to work. Nix basically reveals the full complexity of the package's actual build environment, and for som…

It's not Nix's fault, but that doesn't make it cheaper to deal with. Whatever you want to say, `pip install psycopg2` just works because someone else already dealt with the packaging problem.

That's the cost of full reproducibility though. If Nix would not expect the postgresql package listed in dependencies and instead relied on what's currently installed on your system we would get to the starting point. Where something works on one person's computer but doesn't on another.

Yes it is harder, but if you incorporate nix definitions in your source code (you need to pin nixpkgs though) then everyone will get exact same versions of the packages and your code works on everyone's computer.

Re: My experience with NixOS

#72

Post by Ericson2314 »

takeda wrote: post #64
lidHanteyk wrote: post #10

Earlier quoted context omitted.

To me, this is a success story; your organization wasn't sufficiently flexible to adopt new technologies which require rethinking the fundamentals of package management. Take this as a warning sign and re-orient your organization. I do wonder about the "deliberately cryptic" nature of Nix's expression language. It is, in fact, deliberately designed for simplicity, to be a basic syntax for a language that is purely fu…

Agree, nix itself is actually fairly simple. What it is hard though is functional programming, an that's the biggest road block for developers that are used to imperative programming. Places that use functional language for their code base don't have problems picking it up. It is especially big in Haskell community, because Haskell is also lazily evaluated. People might wonder why not use language that more people ar…

Yes people often blame the Nix langauge when they should blame Nixpkgs. I needs some more refactoring than we've been able to give it (though thankfully we've been able to give a lot of refactoring in absolute terms). I think static types what's needed to get us over the hill on this one.

Re: My experience with NixOS

#73

Post by takeda »

mouldysammich wrote: post #48
rudolph9 wrote: post #33

Earlier quoted context omitted.

It’s really great that functional package managers are getting all this attention! Nix package manager can run on Arch and Gentoo and OpenSUSE also.

nix doesn't have a package on OpenSUSE so you need to manually instlal, guix does have one though

Nix doesn't really come with packages to be installed, you can create one though.

You install it by running this installation script: https://nixos.org/nix/install

It should work on any Linux and OS X.

Re: My experience with NixOS

#74

Post by Ericson2314 »

berti wrote: post #67
beefee wrote: post #50

Earlier quoted context omitted.

Nix has a way of exposing complex and low-quality build systems. Many pieces of the Python ecosystem fall into this category. For example, it wasn't Nix's fault that psycopg2 had a dependency on postgresql C header files, nor was it Nix's fault that the postgresql headers had to be rearranged for psycopg2's build to work. Nix basically reveals the full complexity of the package's actual build environment, and for som…

Read your way down this thread and note that every defence of Nix is merely shifting the blame in it's entirety to some other part of the ecosystem. Rightly or wrongly that's a big problem for Nix if it intends to gain widespread acceptance.

Almost every language build system ecosystem does someting quite wrong---it's irked me for a while. I hope to within the next year or two find the time/budget to pick one language and make it work properly, and integrate with Nix perfectly.

I think not everything knows what they are missing, and by doing one complete demo we'll be able to raise the bar and give the other languages a good jolt.

Re: My experience with NixOS

#75

Post by cttet »

bamboozled wrote: post #61
downerending wrote: post #59

Earlier quoted context omitted.

> I recently switched to NixOS and have essentially configured my OS from scratch in less than a week That doesn't exactly scream ease of use .

You can get up and running in probably a day (you need to learn a few things), I'm guessing what they mean is, configured exactly how they want. I had a similar experience with NixOS and I love it.

And getting things like bluetooth/screen light adjustment/and a list of annoying things right on a laptop.

Re: My experience with NixOS

#76

Post by iso-8859-1 »

takeda wrote: post #56
therein wrote: post #47

Earlier quoted context omitted.

I made the switch from Arch about a week ago. So far, great experience. I love the fact that my system state is reproducible and if I use version control on my dotfiles, I basically have a full backup of the look and feel of my workstation. VFIO with GPU passthrough works flawlessly. Setting up FDE with LUKS during and after the install was a breeze as well. Really enjoyed the whole experience. Being able to switch b…

What you are trying to do doesn't look like an overlay, but an override[1]. you can do something like this: let new_electrum = pkgs.electrum.overrideAttrs (oldAttrs: rec { name = "${oldAttrs.pname}-${version}"; version = "4.0.0a"; src = fetchurl { url = "https://download.electrum.org/${version}/Electrum-${version}.tar.gz"; sha256=pkgs.lib.fakeSha256; }; }) in Unfortunately there is no https://download.electrum.org/4.…

You can use GitHub's automatic generation of archives even for specific git commits.

There is no version 4.0.0a of Electrum, it has not been released, it is misleading to refer to it.

Re: My experience with NixOS

#77

Post by iso-8859-1 »

therein wrote: post #53
rtu8lu wrote: post #51

Earlier quoted context omitted.

I have something like this in my overlays.nix: self: super: let callPackage = super.callPackage; in { darktable = callPackage ./pkgs/darktable { inherit (super) darktable; }; } And my default.nix in pkgs/darktabele looks like this: { darktable, fetchurl, ... }: darktable.overrideAttrs (_: rec { version = "3.0.0"; src = fetchurl { url = "https://github.com/darktable-org/darktable/releases/download/release-${version}/d…

Thank you. I was able to move forward similarly as well. Good to see the solution I arrived at isn't too far from yours. self: super: { electrum = super.electrum.overrideAttrs(old: rec { preBuild = old.preBuild + '' # Patch unnecessarily tight dependency on ecdsa version substituteInPlace ./contrib/requirements/requirements.txt --replace 'ecdsa>=0.14' 'ecdsa>=0.13' additionalInputs = with super.python37Packages; [ py…

how do you know the dependency bound is too tight?

Re: My experience with NixOS

#78

Post by Filligree »

dmix wrote: post #52
therein wrote: post #47

Earlier quoted context omitted.

I made the switch from Arch about a week ago. So far, great experience. I love the fact that my system state is reproducible and if I use version control on my dotfiles, I basically have a full backup of the look and feel of my workstation. VFIO with GPU passthrough works flawlessly. Setting up FDE with LUKS during and after the install was a breeze as well. Really enjoyed the whole experience. Being able to switch b…

How well does Gnome work with NixOS? Ideally newer versions...

It's mostly fine, but you have to restart the shell to have it notice package changes. `Alt-F2 r` works.

Re: My experience with NixOS

#79

Post by takeda »

DethNinja wrote: post #35

Could someone summarise what is the advantage of NixOS compared to something like Ansible or Saltstack + any other Linux distribution?

It's similar n some way, but totally rethinking the problem.

Ansible or saltstack are essentially programs that configure your system in specific way. Ansible takes more of a list of things what to change and how, while saltstack tries to be declarative.

NixOS is essentially a Linux system described using Nix language. Whenever you make change and run nixos-rebuild, as name suggests it actually rebuilds your entire system from scratch, it is just smart enough to not do work that was already done.

Benefits of it is that you will always get to the same state no matter what. Another benefit that is quite annoying with saltstack/ansible if you remove specific application/service/whatever once you rebuild the system, it is gone, like it was never there.

You also get Nix benefits, nix never leaves anything in half state changes are atomic, either they are applied successfully or not, if a change broke something, you can easily rollback. Things like for example changing KDE to Gnome or replacing Xorg with Wayland is no harder than replacing emacs with vim (or vim with emacs, if I upset you).

The way how Nix works allows different packages using even conflicting libraries. For example you can have two applications using different openssl version etc.

If you have one application and you need to apply a custom patch to it or maybe even use a different version. In traditional OS good sysadmins would create a custom RPM package an install it. In Nix you just override the definition, and if a cached build is not available, Nix will be smart enough to compile the code (this means no need for artifactory and uploading custom packages there, though to prevent recompiling every time, you should set up a caching server (there's also caching as a service option if you don't want to manage it) or you can even use S3 bucket.

Basically Nix and NixOS is rethinking how building/deploying/packaging does it offers many benefits, CMS like ansible/saltstack/chef/puppet/cfengine etc are no longer needed. It can be used for having comon developement environment, can be used for building, ci/cd etc.

Re: My experience with NixOS

#80

Post by takeda »

catern wrote: post #21
kalium-xyz wrote: post #20

Earlier quoted context omitted.

I switched to using Pulumi from NixOps because of the lack of tooling in the Nix ecosystem (also NixOps is frequently broken in all sorts of ways due to not having as large a community). Is there some ideal way to work with it to get it to behave without having to make your own tooling or would you consider my approach to instead create support for Nix in Pulumi (which I have not done as of yet but there are terrafor…

I think it would be great to have a Pulumi-based Nix deployment stack. I think Nix/Nixpkgs/NixOS are great, and by far the best way to package applications. But NixOps, I think, is a mistake - it's an over-extension, the technologies behind Nix are perfect and way better than anything else for package management, but merely OK for host management. I actually think Pulumi has some better ideas for this, so it would be…

I used NixOps myself as well. The way it was designed it's more like equivalent of Vagrant, and to me it was only useful to work locally for testing before deploying it properly.

I haven't tried it but perhaps the teraform plugins are more useful for actual deployment. I wish there was some kind of integration with CloudFormation.

Post reply on HN