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

21–30 of 95 posts

Re: My experience with NixOS

#21

Post by catern »

kalium-xyz wrote: post #20
arianvanp wrote: post #17

Earlier quoted context omitted.

I would say Nix's cloud native story is "best in class". you can take any nixos configuration and turn it into a cloud image https://github.com/nix-community/nixos-generators You can take any nix package and turn it into a docker image https://news.ycombinator.com/item?id=20720922 https://news.ycombinator.com/item?id=18111954 You can even use Nix to create and deploy cloud resources ala Terraform: github.com/nixos/ni…

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 cool to use Pulumi to orchestrate deployment of Nix/NixOS stuff.

Re: My experience with NixOS

#22

Post by arianvanp »

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 think I might agree. I've been experimenting with making NixOps piggyback on terraform providers (https://github.com/NixOS/nixops/issues/1242#issuecomment-607...) in my spare time. I think this is the same mechanism as Pulumi uses now that I'm reading up on it. Perhaps I should create a Nix frontend for Pulumi instead... Interesting.

Re: My experience with NixOS

#23

Post by haolez »

wyager wrote: post #11
haolez wrote: post #3

Forgive me for using buzzwords, but what's the "cloud native" story on NixOS? Can I easily create containers and update my orchestrator's deployment? Can I abstract things like AWS Lambdas into this immutable build structure?

Not having used it, maybe NixOps is the thing you want.

I think it's more geared towards creating VM instances. I'm thinking about other resources as well, such as Lambdas.

Re: My experience with NixOS

#24

Post by dragonsh »

kalium-xyz wrote: post #18
dragonsh wrote: post #2

NixOS is good, if you found not enough documentation, try Guix and may be GuixSD. It uses guile (scheme) and has fantastic documentation. [1] Earlier Nix had additional NixOps but that too now is available with Guix deploy. I am waiting when I can run Guix within a lxd container, shepherd init still has some rough edges with LXD container init. Both are great piece of software and a new take on building OS and distri…

I don't see why you say that NixOS does not have enough documentation, a commonly cited problem is the lack of tooling rather than the lack of documentation which would be fair. NixOS has the most extensive documentation out there for any linux distribution which I've used [0] and each package is documented and contains the information of any option it offers from the nix code itself and the tooling [1]. Furthermore…

In the blog post if you read the person complained about it, so said can give a try to Guix. I think both Nix and Guix are good, personally I like Guix being familiar with lisp and scheme feels very natural to work with Guix, with Nix need to learn new declarative syntax.

Linux kernel itself is GPL, so not sure what’s the issue with Guix. Obviously Guix package repository only support libre software, but if you need to use proprietary repository try Guix-nonfree[1].

I am happy Guix and GuixSD exist. Check the gnu Guix mailing list archive both have same roots but are sufficiently different[2].

[1] https://github.com/guix-users/guix-nonfree

[2] https://lists.gnu.org/archive/html/guix-devel/2019-09/msg002...

Re: My experience with NixOS

#25

Post by lidHanteyk »

rkangel wrote: post #19
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…

Do you have any evidence to support your assertion that it was an issue with an organisation rather than the technology? Not all technologies are good. Not all organisations are good. Sometimes it's one. Sometimes it's the other.

Sure. Given code which works for a lot of people, versus some organization composed of people, the fault is probably with people and not with code. This follows from the formal properties of code as mathematical objects, plus the property of probabilistically-checked proofs: If code works for a lot of people, then the code is expected to work generally with high probability.

Moreover, there are lots of folks having professional success with Nix, and having consumed enough of their stories, I think that the stumbling blocks that the parent identified are faults of their organization and not of Nix in particular. To see this, first replace "Nix" with "Brand X" and note that the complaints are generic to any community-developed software which doesn't have B2B resellers. Then, consider your own experience learning Nix, and note that usability, poor documentation, and a feeling that things are deliberately cryptic are all common to learning any new tool or programming language.

We can comfortably conclude that Nix did not prevent itself from being adopted by the parent's organization. Indeed, it would seem that Nix made itself extremely attractive and adoptable, else it would not have been under consideration!

Re: My experience with NixOS

#26

Post by sergiovmdo »

throwaway894345 wrote: post #6
dragonsh wrote: post #2

NixOS is good, if you found not enough documentation, try Guix and may be GuixSD. It uses guile (scheme) and has fantastic documentation. [1] Earlier Nix had additional NixOps but that too now is available with Guix deploy. I am waiting when I can run Guix within a lxd container, shepherd init still has some rough edges with LXD container init. Both are great piece of software and a new take on building OS and distri…

Our organization tried Nix for many years. Most of our problems were around usability, lack of documentation (including zero docstrings or type annotations in nixpkgs), and the overt unfamiliarity of the Nix expression language (asking a whole organization to learn something that seems deliberately cryptic isn't a recipe for success), and a long tail of other things. Still, at its core Nix for package management seem…

qweqweqwe

Re: My experience with NixOS

#27

Post by yjftsjthsd-h »

golergka wrote: post #7

I'm yet to see a backend app architecture that both is elegant and effective from developer perspective and at the same time doesn't push her to make unneccessary database calls for each request when business logic becomes significantly complex.

> doesn't push her to make unneccessary database calls for each request when business logic becomes significantly complex.

Are you objecting to holding all state in a database, or something else? If so, the only real alternative is to have individual servers hold state, which seems like a poor choice; one way or another you're going to hit the CAP theorem, and databases are well-optimized for getting you the best results from CAP that you're going to.

Re: My experience with NixOS

#28

Post by throwaway894345 »

lidHanteyk wrote: post #25
rkangel wrote: post #19

Earlier quoted context omitted.

Do you have any evidence to support your assertion that it was an issue with an organisation rather than the technology? Not all technologies are good. Not all organisations are good. Sometimes it's one. Sometimes it's the other.

Sure. Given code which works for a lot of people, versus some organization composed of people, the fault is probably with people and not with code. This follows from the formal properties of code as mathematical objects, plus the property of probabilistically-checked proofs: If code works for a lot of people, then the code is expected to work generally with high probability. Moreover, there are lots of folks having p…

I don't think Nix works for a lot of organizations as a package manager. It works for a lot of individuals for a different use case (NixOS). If you're mostly installing existing packages from nixpkgs onto a NixOS box, that probably works very well--users don't need to know much about the expression language or the nature of their dependency tree. If you're using it as a development tool, users are going to need to intimately understand Nix, its expression language, and their entire dependency tree. Further, how well Nix works for your development use case largely depends on which language you're using, how well that language is supported by Nix (is it compiled or interpreted, does nixpkgs have good coverage for your language's ecosystem, etc). Notably, working with Haskell or Go in Nix is probably quite easy, while working with Python is quite hard.

As an example, I recall trying to build a package for psycopg2 (it wasn't in nixpkgs at the time, and even if it were, for one reason or another we couldn't directly use many packages from nixpkgs), the most popular Python library for interacting with a Postgres database; however, that required me to write packages for a bunch of C libraries that I didn't understand at all, including fishing random header files out of the Postgres source code. No one in our organization including our Nix veterans could figure out how to build it correctly, and it ultimately caused us to move away from Nix (it was among the last straws).

Besides, just because it didn't work for us doesn't imply that there's a problem with our personnel (by several industry key metrics, our devops capability is excellent), but rather that the effort required to implement Nix successfully was greater than the work required to use other tooling. We could use C++ instead of Python for our organization, but just because we don't doesn't imply that our organization is incompetent; rather that Python's tradeoffs are more appropriate for our problems. In effect, Nix creates more problems than it solves for us, which is unfortunate because the problems it solves are really important problems, and many of the problems it creates are utterly unnecessary (add docstrings, use a more familiar expression language--maybe Starlark [https://go.starlark.net], provide and document 'escape hatches' so users can use system dependencies where it's prohibitively difficult to hermetically package things, etc).

Re: My experience with NixOS

#29

Post by mbakke »

dragonsh wrote: post #2

NixOS is good, if you found not enough documentation, try Guix and may be GuixSD. It uses guile (scheme) and has fantastic documentation. [1] Earlier Nix had additional NixOps but that too now is available with Guix deploy. I am waiting when I can run Guix within a lxd container, shepherd init still has some rough edges with LXD container init. Both are great piece of software and a new take on building OS and distri…

GNU Guix 1.1.0 was released just hours ago, so now is a good time to try it: https://news.ycombinator.com/item?id=22877788 :-)

Rumor has it that Guix will be included in a future Debian release too. It is already available in Arch, Gentoo, and OpenSUSE.

Re: My experience with NixOS

#30

Post by ymse »

dragonsh wrote: post #24
kalium-xyz wrote: post #18

Earlier quoted context omitted.

I don't see why you say that NixOS does not have enough documentation, a commonly cited problem is the lack of tooling rather than the lack of documentation which would be fair. NixOS has the most extensive documentation out there for any linux distribution which I've used [0] and each package is documented and contains the information of any option it offers from the nix code itself and the tooling [1]. Furthermore…

In the blog post if you read the person complained about it, so said can give a try to Guix. I think both Nix and Guix are good, personally I like Guix being familiar with lisp and scheme feels very natural to work with Guix, with Nix need to learn new declarative syntax. Linux kernel itself is GPL, so not sure what’s the issue with Guix. Obviously Guix package repository only support libre software, but if you need…

The vanilla Linux kernel contains many proprietary firmware blobs, which is why GNU and Guix uses the "Linux-Libre" fork.

There is a maintained nonfree Guix channel here if you don't care about such blobs or need other proprietary software: https://gitlab.com/nonguix/nonguix

Post reply on HN