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

51–60 of 102 posts

Re: Reflections on NixOS

#51

Post by fizzbatter »

bfrog wrote: post #42

funnily enough I tried the same sort of switcheroo a few weeks ago as well and just ran into too many issues for it to be useful for me at the moment as well. I tried to contribute back fixes for the the problems I ran into, but just couldn't figure out how to fix all the problems I had with the way things were being done :( PostGIS and a few Gnome 3 desktop issues basically drove me back to Arch where stuff just wor…

Yup, same. Nix was awesome, and i was convinced that for my laptop (OSX) and my home server, it was all going to be NixOS and Nixpkgs from here on out.

Then i started running into external dependencies.. one after another, having to patch them to make them work with nix.. it was just such a headache, and honestly i was in way over my head. I am not that well trained of a linux user, but Nix sort of required me to be. So, i had to backoff for now.

I really hope i can use it again soon.

Re: Reflections on NixOS

#52

Post by jorams »

radarsat1 wrote: post #45
mbrock wrote: post #16

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 s…

> 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?

"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.

Re: Reflections on NixOS

#53

Post by teh »

davexunit wrote: post #34
teh wrote: post #25

Earlier quoted context omitted.

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,…

>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). This is a common misunderstanding. Guix is not just a new config layer on top of Nix, it's a new implementation of the concepts pioneered by Nix. The only component that is shared between Nix and Guix is the daemon (written in C++), and they have diverged quit…

Apologies for misrepresenting - my Guix knowledge is clearly out of date!

OTOH disagree with many of your choices and the assumptions you based them on. But I also think that this would easier to discuss in a civilized face-to-face than over the lossy, easy-to-misinterpret medium of text on the Internet!

Re: Reflections on NixOS

#54

Post by gravypod »

dezgeg wrote: post #35
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.

Containers don't handle the case where two different versions (or otherwise conflicting variants) occur in the whole dependency tree. For instance, consider program A with direct dependencies B and C, where B needs version X of /usr/bin/D but C needs version Y of /usr/bin/D.

I just remembered that the thing I was talking about was SubUser [0]. You can read their manifesto since it better describes everything that they are looking for. Their solution is to keep file revisions so if you need an older version of a file it is still there.

[0] - http://subuser.org/

Re: Reflections on NixOS

#55

Post by gravypod »

seagreen wrote: post #30
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…

Is there any real advantage to that opposed to say running this on my arch machine...

   yaourt -Qe|grep -v "(base"|grep -v "(xorg"|grep -v "lib32"|cut -f 2 -d "/"|cut -f 1 -d " " > package_list.txt
Then to reinstall...

   pacman -S package_list.txt
And copy in my home directory. After a reboot everything should work the same way I have it setup (I keep every change I possibly can in my home directory. It's everything aside from two scripts that aren't actually needed)

The difference is I generate my config via usage, not via definition. I don't actually know what I need to use my computer, I've just always used it. I can back everything up and create essentially the same machine (since my distro Manjaro is rolling) every time I need it.

For me, this is a solution that is a bandaid fix for a completely different problem: the lack of rolling distributions and the lack of storing old versions. These are both package manager and os developer problems. Once we leave the space of OS revisions rather then having "The OS" and having it up to date or out of sync with the main os we will fix these problems.

I don't know, am I seeing something wrong?

Re: Reflections on NixOS

#56

Post by aseipp »

gravypod wrote: post #55
seagreen wrote: post #30

Earlier quoted context omitted.

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…

Is there any real advantage to that opposed to say running this on my arch machine... yaourt -Qe|grep -v "(base"|grep -v "(xorg"|grep -v "lib32"|cut -f 2 -d "/"|cut -f 1 -d " " > package_list.txt Then to reinstall... pacman -S package_list.txt And copy in my home directory. After a reboot everything should work the same way I have it setup (I keep every change I possibly can in my home directory. It's everything asid…

You don't get features like transactional rollback to prior revisions of your system definition, which is never an important feature (until it suddenly is). This also seamlessly allows non-privileged multi-user package management without duplication of programs or anything like that, so you don't need to poke your system admin or alternatively pollute $HOME (and in turn pollute your bash/zsh config for library paths, require fixing up include paths for anything you compile using $HOME stuff, etc). This feature is actually particularly important, because it allows you to set up individual, 'hermetic' (or 'pure') build environments for every project, using 'nix-shell', even on multi-user machines.

If the project supports Nix, you can just go in and run 'nix-shell', and your machine is magically populated with the needed dependencies to build it (or using already existing ones), and you drop into a new `bash` with a cleaned environment and custom $PATH for that project. You can then leave that shell (after you submit your patch to an upstream project or whatever) and garbage collect the installed dependencies.

The model also permits things like transparent, remote multi-system/architecture builds (why build the Linux kernel in my chosen configuration on my laptop when I have a 16 core server somewhere else, why SSH into my OSX machine to run a build when Nix can do it with the same description, etc,) -- and in the future when binary determinism is worked out, a single checkout of the Nixpkgs repository will (hopefully) be able to serve as completely-reproducible build chain, allowing anyone to produce identical binaries and identical Nix packages. (And since Nix works on any Linux system, you can run that build anywhere).

NixOS of course supports general container technology as you mentioned in your first post, so you can also use that to your hearts desire.

In practice NixOS is quite powerful but there are still many glitches and user-facing UX issues that are problematic. It is definitely not for everyone.

Re: Reflections on NixOS

#57

Post by tombert »

I used NixOS for about six months, and while I think the core of NixOS is great, but I never liked KDE and how much it kind of forces it on you.

Gnome support is kind of horrible, and it felt like I either had to commit to something incredibly low-level like XMonad, or KDE.

Re: Reflections on NixOS

#58

Post by zzzcpan »

iElectric2 wrote: post #7
infinity0 wrote: post #5

Earlier quoted context omitted.

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?

Because that's fundamental to Nix. We're giving up on some current habits to get the freedom we want. This won't ever change, but people might. I'm not blaming them, I feel their pain. This is common in technology all around, think about driving a car for 25 years with manual transmission and then trying automatic transmission.

While some things are fundamental for Nix's architecture, user interfaces are not. You don't even have to force people to learn the language, you can get apt-getish experience for generating .nix files with git-like commits or whatever. There are no limits in making it user-friendly and respecting people's habits and familiarity (which is actually a core concept for interfaces, that you seem to confuse with new technology).

Re: Reflections on NixOS

#59

Post by vertex-four »

tombert wrote: post #57

I used NixOS for about six months, and while I think the core of NixOS is great, but I never liked KDE and how much it kind of forces it on you. Gnome support is kind of horrible, and it felt like I either had to commit to something incredibly low-level like XMonad, or KDE.

I don't think many NixOS users use desktop environments, generally speaking, and NixOS users tend to wind up being NixOS contributors as it stands right now. XFCE's available, though, for something lightweight.

Re: Reflections on NixOS

#60

Post by dbcurtis »

People need to stop thinking of NixOS as another Unix-alike, because it isn't, in very much the same way that MacOS used to be a Unix-alike, but isn't any more, either.

NixOS is rebuilding important pieces of the foundation. Why? To address a basket of problems we have been complaining about with Unix for a very long time. Is it worth the hassle? Well, have you ever lived through a kitchen remodel in your house? That's a hassle, too, but you end up with a better kitchen.

IMHO NixOS is pointing the way forward, but is probably not the last word in next-generation operating systems. The existence of NixOS and Guix (and similar) are exciting, because they are part of the ferment creating the thing on which we will eventually converge.

Post reply on HN