I have to say that that "surprisingly simple" thing is happening more and more for me on NixOS as well.
Recently a customer wanted me to use Fedora (I never visited the RPM side of the world before), and after truly the worst installer I've ever used, the actually system was nice. I do like Cockpit.
But then I needed to install an initrd that would me unlock the full disk encryption via SSH (it's a remote headless box). It took me half a day and a forum post to get it to work. I wrote a full page of notes for next time. Then the Firewall: I hit a bug (plus user error) which left me wrestling with a non-existent Tailscale interface for a while (it warns you for non-existing interfaces, but not with only a case mismatch, it then lets you do everything as if the interface exists), but after some hours I was done setting the zones, another page of notes and commands to enter to get to the desired state.
These configurations are both 1 or 2 lines in a NixOS config file. And that "work" is now done for all my NixOS servers.
You could argue that NixOS hides a lot of complexity, but so do Dracut and Firewalld of course. Nix is difficult, it's a high level abstraction. But it also just a bunch of key-values, and write-once, deploy everywhere.
> So do we want to do: We want to build one disk image that boots on x86_64, ARM AArch64, and RISC-V 64-bit. We limit ourselves here to UEFI platforms, which makes this pretty straight forward.
It kind of feels like this should have been the default across all architectures - a single disk that supports multiple instruction sets. 32 bit? 64 bit? Intel x86? Intel x86_64? RISC-V? Imagine how much simpler it would be for the end-user.
I still believe to this day that it has been a massive mistake to not ship ARM devices with some form of BIOS/UEFI chip to allow the system to boot without a bootable image.
Not surprised that it's easy to do with NixOS, but that is a brute force method, it's just easy to implement with the way NixOS works.
I remember I had G4 Mac mini and one of the first gen intel macbook pros - you could have use one of them as a hard-drive and boot from it via Firewire. Work magically.
7 comments
[ 3.8 ms ] story [ 23.3 ms ] threadRecently a customer wanted me to use Fedora (I never visited the RPM side of the world before), and after truly the worst installer I've ever used, the actually system was nice. I do like Cockpit.
But then I needed to install an initrd that would me unlock the full disk encryption via SSH (it's a remote headless box). It took me half a day and a forum post to get it to work. I wrote a full page of notes for next time. Then the Firewall: I hit a bug (plus user error) which left me wrestling with a non-existent Tailscale interface for a while (it warns you for non-existing interfaces, but not with only a case mismatch, it then lets you do everything as if the interface exists), but after some hours I was done setting the zones, another page of notes and commands to enter to get to the desired state.
These configurations are both 1 or 2 lines in a NixOS config file. And that "work" is now done for all my NixOS servers.
You could argue that NixOS hides a lot of complexity, but so do Dracut and Firewalld of course. Nix is difficult, it's a high level abstraction. But it also just a bunch of key-values, and write-once, deploy everywhere.
Those ternary blobs tend to be cross-platform, I hear.
It kind of feels like this should have been the default across all architectures - a single disk that supports multiple instruction sets. 32 bit? 64 bit? Intel x86? Intel x86_64? RISC-V? Imagine how much simpler it would be for the end-user.
I still believe to this day that it has been a massive mistake to not ship ARM devices with some form of BIOS/UEFI chip to allow the system to boot without a bootable image.
I haven't looked deep into it, but my impression is that most system recovery images target just x86_64 and maybe 32-bit x86 if they're cheeky.
https://github.com/nix-darwin/nix-darwin
Great project, but I had to discontinue using it on my dev machine because of some issues getting the correct versions of dependencies installed.
I remember I had G4 Mac mini and one of the first gen intel macbook pros - you could have use one of them as a hard-drive and boot from it via Firewire. Work magically.