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

NixOS: A Personal Post-Mortem

nathan-kim.org

Post reply on HN
Print view View original

21–30 of 41 posts

Re: NixOS: A Personal Post-Mortem

#21

Post by JamesLeonis »

madjam002 wrote: post #4

I think the Nix language is a big barrier to entry for NixOS, I’ve used it quite a bit and still struggle to debug problems, I think lack of types or some basic type inference doesn’t help. That said I’ve had a very positive experience packaging NodeJS apps with Nix, the /nix/store lends itself very nicely to the mess that is node_modules as each NPM package can be stored once in the store and NodeJS can read the dep…

I am typing this on a NixOS Framework, and I'm coming to the same conclusions both you and the author. I too like many ideas NixOS presents but hit a conceptual wall when attempting to be productive. The OS is rock solid but it is difficult to learn the ins-and-outs needed to set up a developer box while also learning Nix itself.

Ironically I think the best way to learn Nix is to go backwards: Build a server on NixOS, then learn how to package your app in Nix for deployment, then use NixOS as a developer machine. Server configurations are (usually) much simpler, making the language and distro easier to learn.

Re: NixOS: A Personal Post-Mortem

#22

Post by i-use-nixos-btw »

I find the nix language beautiful.

The vast majority of the issues I have faced have been down to nixpkgs. Of course, nixpkgs is an incredible project, but it lacks direction, uses bad practices everywhere, and pretty much all of the flaws you’d expect on a vast monorepo with a somewhat laissez-faire management approach.

Oh, one other problem I had, I guess, was when MS removed a link to a Teams binary that was baked into nixpkgs, which meant I couldn’t rebuild my system without losing teams, until I fixed it with a custom derivation. I could also have fixed it by pinning the nixpkgs it came from to one with a working teams URL, but that seemed like too big of sledgehammer for a single application.

One of the key assumptions made by nixpkgs, and by many hermeticity-focused projects, is that URLs stay alive and unmodified. They don’t promise that something will always build. They promise that it will build perfectly, exactly as you specified, or not at all. There’s a nice security element to that I guess.

Nonetheless, NixOS is the best distro I’ve ever used. I certainly spent much more time fighting Arch, etc than I do NixOS - and I’ve never come across a problem I can’t work around with some nix code.

So my position, I guess, is that NixOS is the second best distribution for me. The best is the one that builds on NixOS and has learned some mistakes, thrown away some technical debt, etc.

Re: NixOS: A Personal Post-Mortem

#23

Post by rgoulter »

frozenport wrote: post #8

We were running nix in production and it was an absolute mess While the language is declarative your configuration is scattered, debuggers are absent, and you're ultimately interacting with a a layer on top of what the original package was designed to do. This makes it hard to figure the system out, how to debug, and occasionally support is missing.

> While the language is declarative your configuration is scattered...

I think it's worth being more precise here.

With a NixOS system, the configuration and services can all be declared from a single starting point. (Which is a benefit you'd get from NixOS, or maybe Ansible).

With NixOS' modules, the options used to configure services can be set from any nix file, which may be annoying (but IME is more likely to be a help than a hindrance).

The actual configuration files used by running services will be in some not-obvious-to-find directory.

> ...you're ultimately interacting with a a layer on top of what the original package was designed to do. This makes it hard to figure the system out, how to debug, and occasionally support...

Yeah; when something doesn't go well with Nix / NixOS, you may need to understand any/all of what the Nix code is doing, what the package/service you're describing is trying to do, and how it runs in Linux.

Re: NixOS: A Personal Post-Mortem

#24

Post by rgoulter »

eisbaw wrote: post #17

My garbage can is a few meters away from my desk. That's too far -- guess I'll just litter on the floor -- it's more convenient. ... but soon the trash builds up. Upgrade the whole system? Dangerous. Upgraded and it kinda works, but you'd like to roll-back? Though luck. NixOS is definitely not for everybody - perhaps Developer workstation is the most tricky to get right. But for production server use, the repeatabili…

> ... perhaps Developer workstation is the most tricky to get right. ...

I think the biggest 'risk' is there's a long tail of stuff a developer might want to do. The more niche some task is, the more likely it is that the program you're trying to use makes assumptions about things in Linux being where things in Linux usually are.

But. I think 'developer workstation' is the use case most likely to benefit from NixOS desktop use. -- For servers, I think 'running containers' is an almost ubiquitous way of deploying applications.

Re: NixOS: A Personal Post-Mortem

#25

Post by lambdaloop »

Valodim wrote: post #5
lambdaloop wrote: post #2

I've had a rather similar experience with NicOS a few years ago. I did get comfortable with the language and even contributed a small package! I did like having a reproducible config file for my whole OS setup. However, everything was just a hassle to get working. Any program that's not in the package repos takes a day or two of fiddling to install. I just lost patience with it and have been on Ubuntu for the past fe…

The common advice is just using the steam-run wrapper. It will run the binary in an ubuntu-esque fhs environment, which is what must binaries you get expect. Worked every time for me. Granted, it's not ideal that this kind of hint is needed for such an important workflow. Oh well. All the rest still makes it easily worth it for me.

Ahh that's right, I remember using the steam-run wrapper a lot.

If I remember correctly, it would work in 80% of cases and fail on the last 20% (usually if some library is missing or if it has some strange binary installation procedure).

The 20% made it not worth it for me to use as a desktop environment. I still see the value in it for server configurations, though.

Re: NixOS: A Personal Post-Mortem

#27

Post by KingMachiavelli »

i-use-nixos-btw wrote: post #22

I find the nix language beautiful. The vast majority of the issues I have faced have been down to nixpkgs. Of course, nixpkgs is an incredible project, but it lacks direction, uses bad practices everywhere, and pretty much all of the flaws you’d expect on a vast monorepo with a somewhat laissez-faire management approach. Oh, one other problem I had, I guess, was when MS removed a link to a Teams binary that was baked…

> One of the key assumptions made by nixpkgs, and by many hermeticity-focused projects, is that URLs stay alive and unmodified. They don’t promise that something will always build. They promise that it will build perfectly, exactly as you specified, or not at all. There’s a nice security element to that I guess.

This shouldn't be the case since the main upstream substituter, cache.nixos.org, should have the derivation cached or at least the latest remote source/binary. MS Teams is an exception since it's licensed as "unfree" which likely prevent caching. I think there's a way to mark the remote src of the package as redistributible (if MS allows that) even if the final package/derivation is not destributible.

Since external sources are content addressed, you can always manually add the source file via the `nix store add-file` or `nix store prefetch-file`.

Re: NixOS: A Personal Post-Mortem

#28

Post by nathanckim18 »

throwaway17995 wrote: post #20

To edit it, you must edit your system Nix configuration in /etc/nixos/configuration.nix and then rebuild your system, which —get this — requires a network connection to complete! So somehow, to connect to the Internet, you must be able to connect to the Internet. I'll be pedantic and say that this isn't true, it's not required for you to be connected to the internet to rebuild your system when you're only changing /e…

Thanks for the comment, that's very interesting! I'm not sure why, but my experience was different -- I think I was running `nixos-unstable` which wanted to query upstream for updates, which I felt necessary because Zoom on the `nixos-stable` was outdated and I needed to join a colleague's video calls.

Thanks for the link, I'll also post two that I saw when I was trying to work this out: - https://discourse.nixos.org/t/rebuild-nixos-offline/3679/4 - https://superuser.com/questions/1688845/nixos-how-to-fix-net...

Re: NixOS: A Personal Post-Mortem

#29

Post by nathanckim18 »

zamalek wrote: post #6

It's sounds like one of the major problems here was using configuration.nix. Nix flakes provide a much better user experience, but they are currently "experimental" (seriously, its time to stabilize flakes) and you are not guided to use them at all. I have .envrc ignored in my global gitignore, and then I write 'use flake $HOME/my-nix-config#node' to .envrc. direnv then grabs that and does the rest. I no longer need…

Oh wow, that's a very neat config and one that I wish I had thought of, my main pain point was in trying not to clog up collaboration environments. Thanks for sharing!

Re: NixOS: A Personal Post-Mortem

#30

Post by nathanckim18 »

throwaway17995 wrote: post #19

What you might not be as familiar with is that these authentication sites often block you from visiting any domain at all, and then to access the authentication site on their own domain you must explicitly link their domain to an IP address through the /etc/hosts file.³ 3. I'm assuming on Mac and Windows this is taken care of for you somehow and it is a non-problem. I... have never had to do this in any distro or OS…

Thanks for the comment! For some reason this wasn't the case at some of the hotels/airports/cafes I was visiting, my browser wasn't automatically redirecting requests to the login screen.

I saw an entry like the below and thought a DNS configuration might have been the problem -- in retrospect, it could have been another issue, perhaps I set `networking.useDHCP = false` in my NixOS config, but I honestly cannot remember

https://askubuntu.com/questions/961557/ubuntu-17-no-redirect...

I'll update my post with a note about this

Post reply on HN