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

Reflections on NixOS

zenhack.net

Post reply on HN
Print view View original

21–30 of 102 posts

Re: Reflections on NixOS

#21

Post by wtbob »

dorfsmay wrote: post #9
iElectric2 wrote: post #3

Disclaimer: I'm core NixOS developer It's great to see such articles as they dive deep into psychology when it comes to new technology. It's really hard to unlearn. It takes effort to realize that the promised gain is bigger than the pain coming from doing what we're used to doesn't work.

I would love to hear your thoughts on Guix.

I love that Guix chose a nice, clean (i.e., S-expression-based) representation for all of its code and data, but it's unfortunate that they chose Scheme instead of Lisp.

Re: Reflections on NixOS

#22

Post by lil1729 »

teh wrote: post #20
lil1729 wrote: post #17

I used nixos for a few weeks and then went back to Debian. * I share the concern of the author on symlinks farm. It is scary! I would like it to be dealt with in the filesystem layer (Plan 9 had a snapshot based filesystem - fossil - years ago). Symlinks have all sorts of weird semantics on different Unix machines. * Another of my gripe with nixos is that it makes Unix, a single user machine! Sure, packages need not…

> Symlinks have all sorts of weird semantics on different Unix machines. Is there any other implementation than posix in the wild these days?

http://www.weirdnet.nl/apple/rename.html

Yes, I know it is fixed. But who knows what one runs into!

And this: http://blog.moertel.com/posts/2005-08-22-how-to-change-symli...

Re: Reflections on NixOS

#23

Post by chriswarbo »

infinity0 wrote: post #5
iElectric2 wrote: post #3

Disclaimer: I'm core NixOS developer It's great to see such articles as they dive deep into psychology when it comes to new technology. It's really hard to unlearn. It takes effort to realize that the promised gain is bigger than the pain coming from doing what we're used to doesn't work.

It sounds like you're blaming the users for not "unlearning" enough to be able to use NixOS. As long as you have that attitude, you'll be driving away users. How do you think you can improve your software to make it easier for users to "unlearn" stuff you think is bad?

It's really a collective problem caused by user requirements (e.g. needing packages X, Y and Z), upstream practices (e.g. assumptions made by developers of X, Y and Z) and NixOS's unconventional approach (almost everything living in /nix/store/-).

There's no need to blame anyone, we're just caught in an accident of history. If there is a cause of problems, it's Nix's unconventional approach; but if Nix didn't take that approach it would be just another run-of-the-mill distro with no distinguishing features.

I'd rather live in a world where I can choose whether or not to use NixOS's features, at the expense of its rough edges.

Re: Reflections on NixOS

#24

Post by bendlas »

Avid NixOSer here. While it's sad, that we're not there yet in terms of user-friendliness, I still think, given the radical approach, NixOS takes, it's increadibly feature-complete. I find it easy to tweak, too, but that might be due to previous experience with functional systems.

For the specific suggestions in the article, I'm not convinced that they are possible, while retaining the same benefits:

- Filesystem snapshots are not enough to deal with, e.g. slightly different builds of the same shared library

- Namespaces, however are. In fact, there is buildFHSEnv in nixos, to take advantage of those.

- Hiding of runtime dependencies is done with the intent to minimize "accidental success", because that leads to unstable systems.

- Also a package could, e.g. depend on a patched version of Python2.7, that you'd never want to accidentally end up on the system path.

Having packaged some, I do feel the author's pain though. I wonder, if we couldn't get rid of a lot of upstream grind, by encouraging usage of fhs-env namespaces.

Re: Reflections on NixOS

#25

Post by teh »

dorfsmay wrote: post #9
iElectric2 wrote: post #3

Disclaimer: I'm core NixOS developer It's great to see such articles as they dive deep into psychology when it comes to new technology. It's really hard to unlearn. It takes effort to realize that the promised gain is bigger than the pain coming from doing what we're used to doesn't work.

I would love to hear your thoughts on Guix.

Guix comes up on every Nix thread on HN and it's a bit frustrating. Guix runs on Nix technology with a new config language for packages & a different philosophy about what can go into its core package set (it's a GNU project).

My personal take is that the difference isn't large enough to warrant a new distribution and if you want to choose you should go with the momentum and that's with core Nix (10-30x contributors, 10-100x packages, depending on how you count).

People also think scheme is better than Nix as a language, but if you reason backwards from the requirements that's not at all clear to me. I think Nix-the-language would be better off with types, but the lazy, functional & pure parts are necessary for the concept.

Re: Reflections on NixOS

#26

Post by chriswarbo »

wtbob wrote: post #21
dorfsmay wrote: post #9

Earlier quoted context omitted.

I would love to hear your thoughts on Guix.

I love that Guix chose a nice, clean (i.e., S-expression-based) representation for all of its code and data, but it's unfortunate that they chose Scheme instead of Lisp.

I much prefer Scheme (and Racket) to the other Lisps I've tried (Common Lisp and Emacs Lisp), since it emphasises functional programming.

Since the ideas of Nix come from functional programming (e.g. conceptually, the Nix store contains all packages, the "install" commands just force their evaluation) Scheme seems like a closer fit.

Re: Reflections on NixOS

#27

Post by gravypod »

Correct me if I'm wrong but isn't the better solution to this containerization? The application will in a literal sense own the system.

You also get inherent security (unless someone figures out how to escape their vm).

I member someone had a website talking about this. The use of a file system with revision tracking, containerization for security, and sending files between VMs to make things work.

Re: Reflections on NixOS

#28

Post by akavel »

lil1729 wrote: post #17

I used nixos for a few weeks and then went back to Debian. * I share the concern of the author on symlinks farm. It is scary! I would like it to be dealt with in the filesystem layer (Plan 9 had a snapshot based filesystem - fossil - years ago). Symlinks have all sorts of weird semantics on different Unix machines. * Another of my gripe with nixos is that it makes Unix, a single user machine! Sure, packages need not…

Why do you believe it makes Unix a single user machine??? I'm not aware of any reason for such statement, can you elaborate?

Re: Reflections on NixOS

#29

Post by digi_owl »

dorfsmay wrote: post #9
iElectric2 wrote: post #3

Disclaimer: I'm core NixOS developer It's great to see such articles as they dive deep into psychology when it comes to new technology. It's really hard to unlearn. It takes effort to realize that the promised gain is bigger than the pain coming from doing what we're used to doesn't work.

I would love to hear your thoughts on Guix.

Not OP, but i would go with Guix for two simple reasons.

1. both the packaging format and the init format is scheme.

2. because of the second part of 1, no systemd.

That said, i am already a happy user of similar(ish) distro, Gobolinux.

Re: Reflections on NixOS

#30

Post by seagreen »

gravypod wrote: post #27

Correct me if I'm wrong but isn't the better solution to this containerization? The application will in a literal sense own the system. You also get inherent security (unless someone figures out how to escape their vm). I member someone had a website talking about this. The use of a file system with revision tracking, containerization for security, and sending files between VMs to make things work.

The great things about NixOS is that you can describe the entire state of your system in configuration files, and then after running `rebuild` know that what's on your computer _exactly_ matches that configuration.

Can you do that with containers?

For instance, I'm on NixOS `16.09.git.20f009d (Flounder)`. Here's my configuration: https://github.com/seagreen/vivaine. I know my machine exactly matches the combination of that NixOS version + those config files. My impression is that this is messier with containers because while you can make a snapshot and know the snapshot is frozen, as you modify snapshots over time they'll begin accumulating cruft due to things like installing programs, uninstalling them, snapshotting, but still having some leftovers from the install. I'd like to hear from someone with more container experience here though.

Post reply on HN