11 ms·

Setting up my new laptop: Nix style

184 points by rc00 4y ago

kevincox 4y ago
This is cool. I have my own script which is fully automated. However looking at their ISO building it is much cleaner, maybe I should refactor to that. https://kevincox.ca/2021/05/06/workstation-install-with-nixos/ https://kevincox.ca/2021/05/06/workstation-install-with-nixo... I think the really cool thing about NixOS is that once you have any sort of base system installed it is just one `nixos-rebuild` away from any other system. This means that once you have your config the amount of futzing around on a system that isn't set up the way you like it.
- SkyMarshal 4y ago
  Also, once you have your base install working, then futzing around is super cheap and almost riskless [1]. You can completely brick it, discard it, try again, and/or roll back to your working base system with very little cost in time and effort. It enables no-cost rapid iterations in your system config. [1]:the only risk is that once in a blue moon, a major version Nix upgrade will change Nix's database schema, and be incompatible with prior builds of lower versions, so you can't roll back to a lower version build after such an update. But afaik that's only happened a few times in Nix's history, is not a surprise, and is communicated well in advance.
Dedime 4y ago
I also ran NixOS on my framework for a while. As much as I loved the idea of Nix, it's also incredibly hard - I work with Linux day in and day out for work, and finding my way around Nix, configuring new packages / basic features, etc. just took too long for me. The biggest upside I found was the incredible resilience, it was nearly impossible to break my installation. I gave up after a short while using Nix and switched to Windows. It's not perfectly tuned like a minimal Linux install might be, but all of the hardware features work as expected and it has a pretty good battery life. If someone can find a way to do something like Nix, but simple, I'll be interested. Even if it's just a on-rails version of Nix.
- chironjit 4y ago
  I know you're getting bashed, but i understsnd your pain. I have a new framework too, and whats unsaid in this blog post is whether this setup works for a laptop. Specifically, i've noticed battery performance leaves lots to be desired and your mileage will vary by distros. Mine specifically, started with Zorin but noticed it didnt do well with idle power usage. Switched to PopOs as its my desktop daily driver, but kept getting random freezes. Gave up and went with stock ubuntu. Pretty much stable now, and perfect for a desktop but really not happy that a 2022 laptop only lasts 2 - 3 hours in usage. Not sure if its a linux issue but if Windows does solve it, wouldnt blame you for making that choice
- SkyMarshal 4y ago
  > If someone can find a way to do something like Nix, but simple, I'll be interested. Even if it's just a on-rails version of Nix. I doubt it's possible to substantially simplify Nix and still cover all the use and edge cases it does. Maybe GUIX since it had the benefit of learning from Nix and uses a more familiar (for HN anyway) Scheme, but I haven't looked at closely. It seems that if Nix/OS works for you, it works really well, but if there are use/edge cases where it doesn't then it can be a lot of added effort to wrangle it.
  - anon291 4y ago
    If NixOS doesn't work for you then using Nix to set up a virtual machine is invariably easier than the problems you'll certainly have in ~five years with any major linux distro. NixOS is the first truly rolling distro I've ever used where I never even think about upgrading / switching distros / re-installing linux to get rid of cruft.
  - rgoulter 4y ago
    > I doubt it's possible to substantially simplify Nix In general, I think there's always going to be a long tail of things which will be relatively difficult to achieve with Nix. But, I think it would be possible to make many cases much simpler, or have more common developer use cases well-trodden so that its rough edges get ironed out.
  - 4y ago
koalaman 4y ago
I really like nixos. I didn't get fluent with it, but I was learning and declarative environments is just so incredibly satisfying. I never had to do anything twice. I had to reinstall to change my HD layout and immediately I was back to the environment I had before. So happy. The language doesn't seem that bad to me either. Ultimately the biggest problem was package management. You'll eventually hit a dependency you need for work but doesn't exist or isn't kept up to date. Doing the work myself if just not something I have time for. I left the platform when I had to look at the Google Chrome update warning for two weeks without any updates. I get that these are all volunteers and I'm not mad. Until you have the marketshare that package owners are going to start ensuring your platform gets updates promptly you have no choice but provide best community effort. I just can't live in that kind of platform. For folks with motivation and lots of spare time to fix that problem with elbow grease, nixos is the best platform out there. I can't afford to wait on security updates for weeks to my browser and I don't have the time to maintain my own packages for common things I need fresh.
- whateveracct 4y ago
  It's pretty easy to track nixpkgs HEAD for chrome and stuff
- winterqt 4y ago
  With regards to your Chrome issue: 1. How often did you update your Nixpkgs channel/flake input/etc? 2. What branch (nixos-XX.XX or unstable) were you using? 3. Were you using Chromium or Google Chrome? Chrom{e,ium} gets updated pretty quickly, but depending on a lot of factors, it may take time to make it into a channel. It should really never take 2 weeks though, which is why I ask the first question. You can also always track HEAD (or even a bump PR!) as the other commenter mentioned, though you might not want to do this if you're not using Google Chrome, as you probably don't want to build the browser ;)
  - koalaman 4y ago
    It's possible there was something wrong with my flake config as it was a cargo culted hack job. I tried updating using unstable and it made no difference. I looked at nixpkgs head for chromium and I didn't see any update PRs landed or incoming. I asked on the community chat and whoever was the knowledgeable person answering questions at the time did confirm that it looked out of date. I'm sure I could have found a way if I persevered and ramped up properly. I just don't have that kind of time. Maybe after I retire I can pick up where I left off. I do suspect there's a big opportunity to build a shallower ramp onto nixos.
the_duke 4y ago
I switched to NixOS two years ago , and have installed it on about 6 personal machines, both latpops and desktops. I don't bother with building a custom ISO. The way I do it: * Boot with the default ISO * Format the disk * Git clone my dotfiles repo with all the configs * Generate the hardware config and extend my flake.nix with the new machine. * Install with my dotfiles config * Reboot (aka profit!) I can complete the whole process in about 10 minutes (on a fast CPU and with a good network). Customizing the config up front, building the custom ISO , and writing it to a USB stick takes up way more time than just doing the above.
- infogulch 4y ago
  I guess ISOs are more useful if you're commissioning a fleet of identical machines.
- anon291 4y ago
  I don't even do that. My workflow is really easy. 1. Use netboot.xyz to boot Nixos 2. Copy over nix configurations. I use nix flakes, so I can pre-build all my packages on another machine and debug the config in a more comfortable environment. 3. Run nixos-install (and generate a hardware config if needed). 4. Reboot
- bmcgee84 4y ago
  Nothing wrong with the workflow you described, done much the same in the past myself.
- abrouwers 4y ago
  Out of curiosity, how often do you "set things up from scratch?". It's such a rare thing for me, that usually dumping my list of installed packages / installing those, and then bringing in modified configs, is way less work than learning something as complex as Nix.
- indemnity 4y ago
  I'm trying to get something like this, but here's my situation: - I have two M1 Macs, running MacOS - I have a Ryzen desktop that dual-boots Windows 11 and NixOS 22.11 I would like to have one dotfiles repo with all my configs and home-manager setup, as well as the system / hardware config for the bare-metal NixOS installations. I have gotten these working independently, but I still can't quite make the leap in a single repo to: - Having some config be machine-specific - Having other config be OS-specific - On a particular machine (same OS - macOS), having some slightly different config, because it's a work machine vs personal (e.g. different .gitconfig setups). Can all of the above be addressed with Nix? There seems to be an assumption either you have gone all-in using NixOS (e.g. in a VM inside host OS, or bare-metal), or you are just using the package manager (+ a subset of home-manager), e.g. macOS or WSL inside Windows. But on the whole, 80% of what I want to set up and configure is machine-agnostic (NeoVIM, fish shell, basic CLI utilities, etc), and I use direnv/shell.nix in individual project folders to load the tooling for that project.
jjtheblunt 4y ago
If you type "uname" at a NixOS prompt, what does it say?
- Enzime 4y ago
  $ uname Linux $ uname -a Linux phi-nixos 6.0.7 #1-NixOS SMP PREEMPT_DYNAMIC Thu Nov 3 15:00:35 UTC 2022 x86_64 GNU/Linux
  - jjtheblunt 4y ago
    thanks
than3 4y ago
Great, another Nix tutorial. Sounds great, isn't. A lot of magical thinking going on in that group. If you know anything about computers, you know for them to operate deterministically, uniqueness of the next potential state is an important characteristic. They use hashes (galois fields) that aren't unique to ID packages (by definition), and as far as I have been told (when asking about this), they don't do anything to check for collisions. Yes the probability is extremely remote, but probability isn't likelihood. What happens when a collision does occur, maybe the software won't work. So how critical is the software? Will it break the system? Can the system clean it up and recover (no, because its non-deterministic, more time). These are questions anyone worth their salt would ask when they value stability and many Linux systems run for months of uptime or more. They have two fundamental problems, they violate determinism, but that failure doesn't hit until there is a package collision, and its non-deterministic which means its not easily characterized (you spend a lot of time), and you need some form of mutability for package security updates, and configurations. If you can't adjust your software easily its stealing your time.
- stouset 4y ago
  I don’t think you quite appreciate how remote the possibility of a SHA-256 collision is. Barring a catastrophic break, there will never be a collision witnessed across the full lifespan of humanity.
  - than3 4y ago
    I don't think you understand the difference and fluidity of what a distribution is and how it differs from likelihood curves. You've made some significant assumptions, one of those assumptions is that the brute force way is the most efficient way or put another way there is no optimal way to calculate collisions better than brute force. That line of thinking is very flawed. Has shown to be flawed many times in the past several decades, and shouldn't even be up for debate given the evidence and deprecation of various cryptographic functions (as vulnerabilities become known publicly). We all know vulnerabilities were known before the deprecation because detection is a lagging process. Also note, as far as the respondents of the project I've spoken with have said, they do not even check for existing collisions. So if a collision did occur, you wouldn't even know it without specialized knowledge.
deleted 4y ago
[deleted]
BHSPitMonkey 4y ago
> I was able to go from a blank slate to a copy of my desktop config on my new laptop without doing anything more than sticking in a USB drive, booting up and grabbing an IP address from said laptop. ... And all that stuff you did via SSH after grabbing the IP address?
- bmcgee84 4y ago
  Yup
temptemptemp111 4y ago
[dead]
You-Are-Right 4y ago
[dead]
puffoflogic 4y ago
After a day and a half of usage it became painfully obvious to me that nix is unusable. There are at least four competing ways to use the nix language to configure software. Each of them individually tickles my sense of very neat engineering but together they are a nightmare, with unique shims that must be used between every combination. Much worse, nix does not do any actual package management, i.e., dependency management. There is no way to derive a common-denominator configuration for a dependency shared between two dependent packages, each with their own configuration requirements (a la portage). Nix style is to install the dependency twice. It achieves that wonderfully, which is essential for development environments, but it should permit the shared dependency model for the "base system".
- YoshiRulz 4y ago
  > There is no way to derive a common-denominator configuration for a dependency shared between two dependent packages, each with their own configuration requirements (a la portage). Nix style is to install the dependency twice. I've never used Portage; what did you mean by this? If you recompiled a library with different flags then you'd expect it to produce a different result. To use the exact same library in multiple packages, change their `buildInputs` by overriding their argument attrsets (`aPkg.override { aLib = aLibModified; }`). To replace it in every consuming package, use an overlay `final: prev: { aLib = prev.aLib.overrideAttrs { ... }; }`.
  - puffoflogic 4y ago
    Software which actually manages dependencies should be able to figure out the correct collection of configuration options for the common dependency on its own. It should also be able to detect conflicts between user-requested configuration and dependency requirements (while still allowing an expert user to ignore any stated requirements). Portage does all of this. Nix does not. Nix seems great for deploying VMs and other kinds of managed images, where the cost of manually managing dependencies is amortized. But it is not useful for a development machine. That is a shame, because the other thing that Nix ought to be good at is creating development environments. I wish that Portage's abilities (or any other comparable software; e.g. Cargo does much the same kind of resolution but on a different scale) were explicitly considered and designed into Nix (-the-package-manager), because the features would complement each other incredibly well. Portage's biggest drawback is that, although USE flags are managed declaratively, the system as a whole is, shall we say, aggressively stateful - every problem I've ever had with it is when it fails to find a path from the state it's in to the state I'm requesting.

184 points by rc00 4y ago

This is cool. I have my own script which is fully automated. However looking at their ISO building it is much cleaner, maybe I should refactor to that. https://kevincox.ca/2021/05/06/workstation-install-with-nixos/ https://kevincox.ca/2021/05/06/workstation-install-with-nixo... I think the really cool thing about NixOS is that once you have any sort of base system installed it is just one `nixos-rebuild` away from any other system. This means that once you have your config the amount of futzing around on a system that isn't set up the way you like it.

SkyMarshal 4y ago
Also, once you have your base install working, then futzing around is super cheap and almost riskless [1]. You can completely brick it, discard it, try again, and/or roll back to your working base system with very little cost in time and effort. It enables no-cost rapid iterations in your system config. [1]:the only risk is that once in a blue moon, a major version Nix upgrade will change Nix's database schema, and be incompatible with prior builds of lower versions, so you can't roll back to a lower version build after such an update. But afaik that's only happened a few times in Nix's history, is not a surprise, and is communicated well in advance.

Dedime 4y ago

I also ran NixOS on my framework for a while. As much as I loved the idea of Nix, it's also incredibly hard - I work with Linux day in and day out for work, and finding my way around Nix, configuring new packages / basic features, etc. just took too long for me. The biggest upside I found was the incredible resilience, it was nearly impossible to break my installation. I gave up after a short while using Nix and switched to Windows. It's not perfectly tuned like a minimal Linux install might be, but all of the hardware features work as expected and it has a pretty good battery life. If someone can find a way to do something like Nix, but simple, I'll be interested. Even if it's just a on-rails version of Nix.

chironjit 4y ago
I know you're getting bashed, but i understsnd your pain. I have a new framework too, and whats unsaid in this blog post is whether this setup works for a laptop. Specifically, i've noticed battery performance leaves lots to be desired and your mileage will vary by distros. Mine specifically, started with Zorin but noticed it didnt do well with idle power usage. Switched to PopOs as its my desktop daily driver, but kept getting random freezes. Gave up and went with stock ubuntu. Pretty much stable now, and perfect for a desktop but really not happy that a 2022 laptop only lasts 2 - 3 hours in usage. Not sure if its a linux issue but if Windows does solve it, wouldnt blame you for making that choice
SkyMarshal 4y ago
> If someone can find a way to do something like Nix, but simple, I'll be interested. Even if it's just a on-rails version of Nix. I doubt it's possible to substantially simplify Nix and still cover all the use and edge cases it does. Maybe GUIX since it had the benefit of learning from Nix and uses a more familiar (for HN anyway) Scheme, but I haven't looked at closely. It seems that if Nix/OS works for you, it works really well, but if there are use/edge cases where it doesn't then it can be a lot of added effort to wrangle it.
- anon291 4y ago
  If NixOS doesn't work for you then using Nix to set up a virtual machine is invariably easier than the problems you'll certainly have in ~five years with any major linux distro. NixOS is the first truly rolling distro I've ever used where I never even think about upgrading / switching distros / re-installing linux to get rid of cruft.
- rgoulter 4y ago
  > I doubt it's possible to substantially simplify Nix In general, I think there's always going to be a long tail of things which will be relatively difficult to achieve with Nix. But, I think it would be possible to make many cases much simpler, or have more common developer use cases well-trodden so that its rough edges get ironed out.
- 4y ago

koalaman 4y ago

I really like nixos. I didn't get fluent with it, but I was learning and declarative environments is just so incredibly satisfying. I never had to do anything twice. I had to reinstall to change my HD layout and immediately I was back to the environment I had before. So happy. The language doesn't seem that bad to me either. Ultimately the biggest problem was package management. You'll eventually hit a dependency you need for work but doesn't exist or isn't kept up to date. Doing the work myself if just not something I have time for. I left the platform when I had to look at the Google Chrome update warning for two weeks without any updates. I get that these are all volunteers and I'm not mad. Until you have the marketshare that package owners are going to start ensuring your platform gets updates promptly you have no choice but provide best community effort. I just can't live in that kind of platform. For folks with motivation and lots of spare time to fix that problem with elbow grease, nixos is the best platform out there. I can't afford to wait on security updates for weeks to my browser and I don't have the time to maintain my own packages for common things I need fresh.

whateveracct 4y ago
It's pretty easy to track nixpkgs HEAD for chrome and stuff
winterqt 4y ago
With regards to your Chrome issue: 1. How often did you update your Nixpkgs channel/flake input/etc? 2. What branch (nixos-XX.XX or unstable) were you using? 3. Were you using Chromium or Google Chrome? Chrom{e,ium} gets updated pretty quickly, but depending on a lot of factors, it may take time to make it into a channel. It should really never take 2 weeks though, which is why I ask the first question. You can also always track HEAD (or even a bump PR!) as the other commenter mentioned, though you might not want to do this if you're not using Google Chrome, as you probably don't want to build the browser ;)
- koalaman 4y ago
  It's possible there was something wrong with my flake config as it was a cargo culted hack job. I tried updating using unstable and it made no difference. I looked at nixpkgs head for chromium and I didn't see any update PRs landed or incoming. I asked on the community chat and whoever was the knowledgeable person answering questions at the time did confirm that it looked out of date. I'm sure I could have found a way if I persevered and ramped up properly. I just don't have that kind of time. Maybe after I retire I can pick up where I left off. I do suspect there's a big opportunity to build a shallower ramp onto nixos.

the_duke 4y ago

I switched to NixOS two years ago , and have installed it on about 6 personal machines, both latpops and desktops. I don't bother with building a custom ISO. The way I do it: * Boot with the default ISO * Format the disk * Git clone my dotfiles repo with all the configs * Generate the hardware config and extend my flake.nix with the new machine. * Install with my dotfiles config * Reboot (aka profit!) I can complete the whole process in about 10 minutes (on a fast CPU and with a good network). Customizing the config up front, building the custom ISO , and writing it to a USB stick takes up way more time than just doing the above.

infogulch 4y ago
I guess ISOs are more useful if you're commissioning a fleet of identical machines.
anon291 4y ago
I don't even do that. My workflow is really easy. 1. Use netboot.xyz to boot Nixos 2. Copy over nix configurations. I use nix flakes, so I can pre-build all my packages on another machine and debug the config in a more comfortable environment. 3. Run nixos-install (and generate a hardware config if needed). 4. Reboot
bmcgee84 4y ago
Nothing wrong with the workflow you described, done much the same in the past myself.
abrouwers 4y ago
Out of curiosity, how often do you "set things up from scratch?". It's such a rare thing for me, that usually dumping my list of installed packages / installing those, and then bringing in modified configs, is way less work than learning something as complex as Nix.
indemnity 4y ago
I'm trying to get something like this, but here's my situation: - I have two M1 Macs, running MacOS - I have a Ryzen desktop that dual-boots Windows 11 and NixOS 22.11 I would like to have one dotfiles repo with all my configs and home-manager setup, as well as the system / hardware config for the bare-metal NixOS installations. I have gotten these working independently, but I still can't quite make the leap in a single repo to: - Having some config be machine-specific - Having other config be OS-specific - On a particular machine (same OS - macOS), having some slightly different config, because it's a work machine vs personal (e.g. different .gitconfig setups). Can all of the above be addressed with Nix? There seems to be an assumption either you have gone all-in using NixOS (e.g. in a VM inside host OS, or bare-metal), or you are just using the package manager (+ a subset of home-manager), e.g. macOS or WSL inside Windows. But on the whole, 80% of what I want to set up and configure is machine-agnostic (NeoVIM, fish shell, basic CLI utilities, etc), and I use direnv/shell.nix in individual project folders to load the tooling for that project.

jjtheblunt 4y ago

If you type "uname" at a NixOS prompt, what does it say?

Enzime 4y ago
$ uname Linux $ uname -a Linux phi-nixos 6.0.7 #1-NixOS SMP PREEMPT_DYNAMIC Thu Nov 3 15:00:35 UTC 2022 x86_64 GNU/Linux
- jjtheblunt 4y ago
  thanks

than3 4y ago

Great, another Nix tutorial. Sounds great, isn't. A lot of magical thinking going on in that group. If you know anything about computers, you know for them to operate deterministically, uniqueness of the next potential state is an important characteristic. They use hashes (galois fields) that aren't unique to ID packages (by definition), and as far as I have been told (when asking about this), they don't do anything to check for collisions. Yes the probability is extremely remote, but probability isn't likelihood. What happens when a collision does occur, maybe the software won't work. So how critical is the software? Will it break the system? Can the system clean it up and recover (no, because its non-deterministic, more time). These are questions anyone worth their salt would ask when they value stability and many Linux systems run for months of uptime or more. They have two fundamental problems, they violate determinism, but that failure doesn't hit until there is a package collision, and its non-deterministic which means its not easily characterized (you spend a lot of time), and you need some form of mutability for package security updates, and configurations. If you can't adjust your software easily its stealing your time.

stouset 4y ago
I don’t think you quite appreciate how remote the possibility of a SHA-256 collision is. Barring a catastrophic break, there will never be a collision witnessed across the full lifespan of humanity.
- than3 4y ago
  I don't think you understand the difference and fluidity of what a distribution is and how it differs from likelihood curves. You've made some significant assumptions, one of those assumptions is that the brute force way is the most efficient way or put another way there is no optimal way to calculate collisions better than brute force. That line of thinking is very flawed. Has shown to be flawed many times in the past several decades, and shouldn't even be up for debate given the evidence and deprecation of various cryptographic functions (as vulnerabilities become known publicly). We all know vulnerabilities were known before the deprecation because detection is a lagging process. Also note, as far as the respondents of the project I've spoken with have said, they do not even check for existing collisions. So if a collision did occur, you wouldn't even know it without specialized knowledge.

deleted 4y ago

[deleted]

BHSPitMonkey 4y ago

> I was able to go from a blank slate to a copy of my desktop config on my new laptop without doing anything more than sticking in a USB drive, booting up and grabbing an IP address from said laptop. ... And all that stuff you did via SSH after grabbing the IP address?

bmcgee84 4y ago
Yup

temptemptemp111 4y ago

[dead]

You-Are-Right 4y ago

[dead]

puffoflogic 4y ago

After a day and a half of usage it became painfully obvious to me that nix is unusable. There are at least four competing ways to use the nix language to configure software. Each of them individually tickles my sense of very neat engineering but together they are a nightmare, with unique shims that must be used between every combination. Much worse, nix does not do any actual package management, i.e., dependency management. There is no way to derive a common-denominator configuration for a dependency shared between two dependent packages, each with their own configuration requirements (a la portage). Nix style is to install the dependency twice. It achieves that wonderfully, which is essential for development environments, but it should permit the shared dependency model for the "base system".

YoshiRulz 4y ago
> There is no way to derive a common-denominator configuration for a dependency shared between two dependent packages, each with their own configuration requirements (a la portage). Nix style is to install the dependency twice. I've never used Portage; what did you mean by this? If you recompiled a library with different flags then you'd expect it to produce a different result. To use the exact same library in multiple packages, change their `buildInputs` by overriding their argument attrsets (`aPkg.override { aLib = aLibModified; }`). To replace it in every consuming package, use an overlay `final: prev: { aLib = prev.aLib.overrideAttrs { ... }; }`.
- puffoflogic 4y ago
  Software which actually manages dependencies should be able to figure out the correct collection of configuration options for the common dependency on its own. It should also be able to detect conflicts between user-requested configuration and dependency requirements (while still allowing an expert user to ignore any stated requirements). Portage does all of this. Nix does not. Nix seems great for deploying VMs and other kinds of managed images, where the cost of manually managing dependencies is amortized. But it is not useful for a development machine. That is a shame, because the other thing that Nix ought to be good at is creating development environments. I wish that Portage's abilities (or any other comparable software; e.g. Cargo does much the same kind of resolution but on a different scale) were explicitly considered and designed into Nix (-the-package-manager), because the features would complement each other incredibly well. Portage's biggest drawback is that, although USE flags are managed declaratively, the system as a whole is, shall we say, aggressively stateful - every problem I've ever had with it is when it fails to find a path from the state it's in to the state I'm requesting.