Live data from Hacker News

My First Impressions of Nix

mtlynch.io

341–350 of 354 posts

Re: My First Impressions of Nix

#341
post #154

The problem the author hit with the Raspberry Pi is that the ARM image is meant for a standard environment (e.g UEFI ), like VMs. e.g it'll boot on Fusion or kvm because they provide UEFI, a well known device tree, and don't require any firmware at that stage. Pis (and many such ARM boards) don't have that so they won't be bootable. But there are Pi images built on Hydra. If one uses that then it boots right away. It…

Author here. I'm working on a follow-up post specifically about NixOS on the Pi 4, but there are several gotchas to the process. The biggest issue I've run into is that the latest versions of the NixOS SD card images don't work on the Pi 4. You can boot to them, but when you run nixos-install, they fail with a message about hardware.raspberry-pi."4".fkms-3d.enable. The link you shared declares itself to be out of dat…

> You can boot to them,

That is the only part I wanted to draw attention to: ARM boot is a peculiar beast and very surprising when you don't know about it, especially when you're used to PC (BIOS or UEFI) booting.

> but when you run nixos-install,

If one intents to run from the SD card that was just booted then the process should be changing configuration.nix to one's liking and nixos-rebuild switch to that (which is a testament to the power of nix: one can pivot to an entirely new "install" on the spot).

Or maybe you attempted to do an install on another block device, e.g to boot straight from USB?

> they fail with a message about hardware.raspberry-pi."4".fkms-3d.enable.

Does that error also appear with nixos-rebuild switch? If so, then pi4 support is borked in nixos. Otherwise, assuming the install to USB process, maybe nixos-generate-config was run and produced a non-functional hardware-configuration.nix? (which would be a bug too)

(it's been a while since I tried nixos on Pis, last time it did work OOTB for me on 3 and 4, save for a kernel / device tree bug for 3 that kills the virtual console)

> outdated

I agree, all the spread out bits are confusing. The ARM boot situation is common an issue enough that I would expect that to be part of the manual.

> Author here.

Thanks for the article, I enjoyed it!

Re: My First Impressions of Nix

#342

Earlier quoted context omitted.

That's just not true. Nixpkgs has the largest package database of any distribution. It contains many closed source application that work flawlessly. Hell I can even run Vivado or Quartus on it which are two of the worst of the worst proprietary pieces of software on it. I also have packaged proprietary libraries for hardware we use at my company with no issues.

It is answered at the end of my blog post: > I don’t care about anything that’s not packaged by the distribution > This is totally fine. Just note that you are using a niche OS with a limited set of applications available. Yes, Nixpkgs is large, but it does not package every piece of software out there, and you either at mercy of distribution maintainers to keep it packaged, or do it yourself. There is no way to disi…

The point is that with NixOS you are in a much better boat then all other distributions. Because the chances that an application is working on NixOS compared to $insert_distribution_here is much higher. I do agree that windows/OSX are superior here.

Re: My First Impressions of Nix

#343
post #318
post #154

The problem the author hit with the Raspberry Pi is that the ARM image is meant for a standard environment (e.g UEFI ), like VMs. e.g it'll boot on Fusion or kvm because they provide UEFI, a well known device tree, and don't require any firmware at that stage. Pis (and many such ARM boards) don't have that so they won't be bootable. But there are Pi images built on Hydra. If one uses that then it boots right away. It…

This comes down to ideological reasons. The engineer that is/was leading the embedded integration subproject feels like the platform support components (filesystem partitioning, bootloader, devicetree config, etc.) of installing a distribution on the hardware should not be a concern of the distribution itself[1]. I don't necessarily agree on all points as most distributions approach this quite differently, but it's a…

Thanks for that link, very interesting to have first party insights!

I seemed to have gathered as much from what has been happening at the code level but it's nice to get the insider version instead of whatever I think I have vaguely understood.

You can see similar things happening with Asahi Linux, pushing stuff to m1n1+uboot to have a uniform boot interface when reaching the kernel, plus (ultimately) using a mainline kernel.

Re: My First Impressions of Nix

#344

Earlier quoted context omitted.

You can think of the function inputs as: 1. All the package definitions in nixpkgs 2. Any external sources When a package is updated in nixpkgs, input #1 changes.

I mean, I get that, but that means that the reproducibility of my build depends on the whims of the nixpkgs maintainers, it's not a property guaranteed by the package manager.

You can pin the commit of nixpkgs. Why should reproducibility hold when nixpkgs changes?

Re: My First Impressions of Nix

#345

Earlier quoted context omitted.

NixOS is just a super barebones distro where everything is configured with Nix. You can also use Nix on Ubuntu or some other distro.

Bare bones as in by default you don't get much unless you turn it on

Right, it's just bash, Nix and systemd by default.

Re: My First Impressions of Nix

#346

Earlier quoted context omitted.

> You do not need FP to use pure functions. They are independent from FP. You can be OOP maniac and still use them. This is not true. OOP is fundamentally built around impure operations. Objects are persistent references that you send messages to or that you call methods on (depending on your OOP language of choice). A persistent reference that is stable across different invocations (as opposed to a new reference bei…

You definitely can write method CalculateSomething which is both: pure and oop viable

Sure in the same way you can create an object in FP by sticking functions in a data structure or create functions in a logic programming language by constructing certain relations.

Heck you can even build "objects" in C.

And all of these methods are indeed used in those languages.

But none of those capture the spirit of object-orientation, in the same way that CalculateSomething is not object-oriented, unless it in turn generates a mutable object. That's not to say it's bad code or that it is uncommon, even in say Java. Simply that it's not object-oriented (and these days Java is getting less and less object-oriented anyways, with records and pattern matching explicitly separating data from functions).

Indeed in Java materials and blog posts from > 5 years ago, using pure methods of the form `CalculateSomething` was generally something used begrudgingly, where too many of those methods was specifically called out as an anti-pattern (e.g. the dreaded "utility class").

Re: My First Impressions of Nix

#347

Earlier quoted context omitted.

The biggest barrier to adoption unfortunately is not people's inability to explain what the tool is in my opinion. It's that the tool is incredibly complicated, extremely hard to walk someone through compared to alternative projects, and honestly... In my opinion the problem it attempts to solve doesn't really exist. I'll take an "impure" os or package manager over a pure one any day if complexity is a thousand fold…

You can continue spending your time messing around with your system then. I learned nix in a short amount of time and it has supercharged my development workflows and reduced the overall complexity. I have too much stuff to get done to not use it.

supercharged!!!

how much faster are your development workflows now, versus before? like 100x?

how complex were your previous development workflows? what did that complexity manifest as? how has nix made it less complex?

i'm excited to learn more

Re: My First Impressions of Nix

#348
post #282

Earlier quoted context omitted.

> Part of the difficulty is it means different things to different people. That's definitely how it seems to me. The pro-Nix stuff I see is generally about the theory much more than the practice. Which was also my experience with functional languages when their hype cycle was last on the rise. On the one hand, that's fine. I like ideas, and I think taking an idea and running with it can be really interesting. You can…

This is probably a pretty good read on the situation. People who have really thrived with Nix are often at the intersection of 'FP people' and 'extremely stubborn Linux people', and that's because sometimes it takes getting your hands dirty and fighting a build system that belongs to a package you've never used before to get the Big Ideas to pay out. When the footwork is already relatively familiar to you, it makes i…

Thanks! Really helpful comment. Especially this bit:

> People who have really thrived with Nix are often at the intersection of 'FP people' and 'extremely stubborn Linux people'

As an extremely stubborn Linux person, that makes total sense to me. But I also almost never recommend Linux to average folks, because I'm keenly aware how far along certain bell curves I am. I would love it if more advocates reflected on whether the personal characteristic that makes a technology great for them is one that makes it bad for others.

Thanks also for the pointers to projects inspired by Nix. I'll check them out.

Re: My First Impressions of Nix

#349

Earlier quoted context omitted.

I'm not sure. Well, I mean, there are weird folks out there who may start doing large-scale things without understanding what they're building upon (Kubernetes is not exactly an OS, but is a notorious example), but they could make the same mess with any technology. They're just unlikely to pick Nix, NixOS or NixOps (or any alternative to it), because mainstream tutorials won't cover it [yet]. The deployment and learn…

nix rebuild does ssh on remote machines all possible ways, why colmena? if you need cloud infra, can use terranix. base image from nixos generators. reconfiguration nix remote rebuild.

This is definitely an option. But isn't colmena just a nice wrapper on top of the same things nixos-rebuild uses (nix-build, nix-copy, etc) plus some nice-to-haves for easier eval REPL?

I mean, yes, I suppose I can use `nixos-rebuild --fast --build-host foo --target-host foo --flake ".#foo" switch` and maybe even wrap that in a the flake itself (`flake run .#deploy-foo`), but why should I reinvent this wheel, if I can just `colmena apply --on foo` and let it do what I mean?

I definitely will consider nixos-rebuild if colmena won't support something I want. Just like I'm currently considering trying out colmena because deploy-rs can't do `activate test` and messes up `/boot/loader/loader.conf`, which I don't fancy as I want to eventually have a "one-shot reboot into a new generation and if something fails too badly, watchdog will eventually panic (or I'll ask someone to cycle the power) and reboot back to a good generation" ultimate magic rollback. Worst that would happen is that I'll learn a new tool (aka learn what it can't do for me) and won't use it.

No cloud infra here, all bare metal and one tiny auxiliary VPS.

Re: My First Impressions of Nix

#350

Nix reminds me about that xkcd comic about standards. It seems to be to be solving a problem solved in a much better way by other alternatives with the mindset of IT from a bygone era. I may just not really be the target demo, or maybe am just a huge idiot, but I struggle to see the appeal, especially when you hear about the occasional horror stories about complex and/or broken environments, or the vim-like overhead…

> or the vim-like overhead to learn it properly. In my opinion, it's somewhat simpler than learning how to do Debian packaging properly (with emphasis on "properly", following all the modern best practices). Quite a lot of folks that run Nix or NixOS write themselves decent derivations that could be (and frequently are) contributed to nixpkgs (of course, there are a lot of quirks/hacks as well). But I think quite a f…

Ah, I will concede I probably am just a huge idiot then. I suppose I don't often find myself needing to bootstrap a linux OS in this way.
Post reply on HN