Live data from Hacker News

NixOS 21.05

nixos.org

191–200 of 234 posts

Re: NixOS 21.05

#191

Earlier quoted context omitted.

Building the new configuration (and downloading or building dependencies), adding the bootloader entry, and activating the new configuration (stopping removed services, starting new services, reloading changed services, that kind of thing). You don't need to do all three: you can skip the bootloader if you want to try something temporarily, and you can skip activation if you want to wait with that until the next rebo…

Thats pretty incredible. So I can work on configs, switch back and forth until it's exactly right and then switch to it permanently. Where's a good place to start? Some of the configs people are throwing about are quite involved and look like they need a bunch of specialist knowledge. Thanks for taking the time to explain. Can't wait to start trying this out.

Just take a few minutes to skim the NixOS manual, then keep it in front of you on another device while you do an install. Enable a web browser, a desktop environment, and NetworkManager in your initial configuration.nix.

Then just start adding software that you want to be able to use. Search for it first in the NixOS options[1]. If you see it there, enable it and configure it using the options that make sense to you. If you don't see it there, search for it in the package collection[2], then use the name you find for it there to add it to `environment.systemPackages` in your `configuration.nix` file.

Just kinda take it easy and continue with that process until you have an environment that's more or less comfy. Then you're free to revisit your config and think about stuff like tying it in with your dotfiles, using Nix to manage your home directory, services you might want to run, etc.

1: https://search.nixos.org/options?channel=21.05&

2: https://search.nixos.org/packages?channel=21.05&

Re: NixOS 21.05

#192

Earlier quoted context omitted.

Could you briefly mention an example of something that is difficult/impossible without first learning about Nix internals, and allude to what kind of internals need to be learned?

As one example, IIRC, I can run "npm install -g" on other Linux distributions, but can't with Nixpkgs (since npm will try to install the package to the nix store). Yarn would install it to the home folder.

Fwiw you can use `npm install -g` if you configure NPM to use your homedir for globally installed packages, as well. It's just not the default behavior.

Re: NixOS 21.05

#193
post #7

I recently moved back to Arch from NixOS. I really love the idea, and the execution isn't necessarily bad, but it didn't make sense for me on the desktop. Straying off the beaten path quickly led to the sense that I was going to have to learn way more about Nix than I wanted to. I hope the documentation and community grows, because I definitely got the sense that it is the future arriving early!

> Straying off the beaten path quickly leads to a terrifying abyss. The contrast is remarkable. When everything you need is packaged and it just works, it's amazing. Hands down the best system management experience I've had. And then one day you learn you've been dancing on the edge of a cliff. I'm hooked; there's no going back now for me. But there's at least one project (TidalCycles) that I simply gave up on ever r…

J/w, have you ever packaged software for other distros? If yes, what made Nix more difficult here? If no, have you tried asking for help packaging TidalCycles on Matrix or Discourse?

I'm wondering whether that's some especially oddly-behaved software, or if what's lacking here is some onboarding (that maybe can solved for you with a little community engagement or something).

Re: NixOS 21.05

#194

Earlier quoted context omitted.

I'm glad we didn't yet stabilize because I am skeptical of a number of aspects to Nix. I suspect it's unduly popular because pure eval mode is a food idea, but there is little way to use it outside of flakes.

s/to nix/of flakes/, to be clear

what do you think of the strategy of stabilizing just the input schema for Nix flakes, which is all that's required for pure evaluation, then stabilizing each component of the output schema separately as those components are called for by specific features of the Nix/NixOS CLI?

Re: NixOS 21.05

#195
post #4

I recently moved my laptop, desktop, and a few servers from Arch Linux to NixOS with flakes and home-manager. It is amazing! The complete configuration for all machines is in a single git repository, I can share configuration between them, and a `flake.lock` file guarantees all machines are using the same version of everything. No more trying to remember what command I need to run to install and configure software an…

> and a few servers The problem I see with NixOS on a typical personal server is that you have to setup all these things using nix expressions, from which the actual configuration files are generated. That means if you e.g. want to install postfix, instead of learning about main.cf you have to learn the syntax of the nix configuration wrapper for postfix, and postfix having hundreds if not thousands of options, many…

I run several personal NixOS servers. it's definitely doable without custom expressions (I can't remember the last time I had to write one).

lots of services defined in the NixOS options will have an "escape hatch" option named something like `extraConfig`. this usually lets you append verbose text to a complex config file, like in the case of Postfix where the options couldn't conceivably cover everything.

you can also always just write a static file to /etc if you want or need to:

    environment.etc.foo-config = {
      target = "foo.conf";
      text = ''
        enable_spline_reticulator = true
      '';
    };
as well as running one-off systemd services declaratively:

    systemd.services.foo = {
      after = [ "network-online.target" ];
      wantedBy = [ "multi-user.target" ];

      serviceConfig = {
        ExecStart = ''
          ${pkgs.foo}/bin/food \
            --config /etc/foo.conf
        '';
        User = "foo";
        Restart = "on-failure";
      };
    };
(both of those examples are copied more or less straight from my daily driver NixOS 20.09 laptop before I made the details generic)

another useful escape hatch is that you can run Docker/Podman containers declaratively. I have some things I want the flexibility to upgrade on a different cadence than NixOS itself (such as my family's "production" Jellyfin server) that I just run as standalone Docker containers with volume mounts for their data.

Re: NixOS 21.05

#196
post #167

Earlier quoted context omitted.

The claim that Chrome was not updated on the unstable branch for weeks is wrong. The two releases in question are: 88.0.4324.96 on Jan 19: https://chromereleases.googleblog.com/2021/01/stable-channel... 88.0.4324.146 on Feb 2: https://chromereleases.googleblog.com/2021/02/stable-channel... The commits updating them in nixpkgs are: https://github.com/NixOS/nixpkgs/commit/5b6d3c4b13e50540d044... https://github.com/NixO…

I appreciate your digging into that. The interval of time during which I was most concerned about unpatched holes in Nixos-unstable's google-chrome was the days leading up to Mar 12.

Chrome stable 89.0.4389.90 was released on March 12: https://chromereleases.googleblog.com/2021/03/stable-channel...

Version bump in nixpkgs: https://github.com/NixOS/nixpkgs/commit/5f8b95113983c8f31d63... on March 13 (one day later)

Released in nixos-unstable on Mar 16 11:11:22 UTC (four days later)

Backport to 20.09: https://github.com/NixOS/nixpkgs/commit/26ba8cd77b5a4408799f... on March 13 (one day later)

Released in nixos-20.09 on Mar 16 16:31:31 UTC (four days later)

Again, four days is not great for a Chrome zero-day. NixOS doesn't have a professional security team, and if you need that assurance, maybe you can't use it. But please don't exaggerate and muddy the facts.

Most of the delay is due to hydra having to build everything that came in ahead of that change on the master branch, and sometimes the master branch is just broken.... I wish there was a fast-track process that could bump urgent security changes ahead of other ones, but it seems like it could complicate things a lot.

Of course, as I said above, it's relatively easy for you to update your local install without waiting for all that, if you're aware of the release and its severity.

Re: NixOS 21.05

#197
post #151
post #118

Earlier quoted context omitted.

Yes, it's extremely powerful once you truly understand Nix. There are efforts to improve documentation, but it still is lacking (I think the biggest problem is that Nix is so big, not just the OS but it can be utilized as a build system). Just with NixOS is not exactly clear how can you for example build your custom image. I think https://nix.dev/ is approaching the documentation from the right direction. There are a…

If you want to build custom images just use https://github.com/nix-community/nixos-generators It's documentation is on point.

Would it be possible to add a minimalistic image that contains app, kernel and essential packages? Like what you would get when building a docker container or using the not-os repo that I mentioned earlier.

I think having mini images would be awesome.

Re: NixOS 21.05

#198

I must admit, I'm curious about the idea but I don't yet "get" it. Reproducible builds sound like a great idea at first, but this has the same problem as Docker containers: you inadvertently become a package/distro maintainer. How does one update the system regularly with security updates? Are we locking by semver somehow (like node, etc.)? And who decides which version ranges to lock to, etc. etc.? Honestly, I'd pro…

> but this has the same problem as Docker containers: you inadvertently become a package/distro maintainer. How does one update the system regularly with security updates? Are we locking by semver somehow (like node, etc.)? And who decides which version ranges to lock to, etc. etc.? That is not true in the case of NixOS. NixOS is an ordinary distribution: it has a release (which seems to be maintained for a year, rec…

(which seems to be maintained for a year, receiving security patches)

Releases are maintained until one month after the next release. So, 21.05 will be maintained until a month after 21.11 is released.

Re: NixOS 21.05

#199
post #125

Earlier quoted context omitted.

I like to use nix-env (or more often, now, `nix profile`) for a persistence level in between nix-shell and really adding something to my home-manager or NixOS config. I let my profile build up 10-20 things installed, then every few weeks I decide what belongs in my declared config and uninstall everything in the profile. Imo entirely removing imperative package management would be a mistake, although imperatively man…

> I let my profile build up 10-20 things installed, then every few weeks I decide what belongs in my declared config and uninstall everything in the profile. I'm curious what you get out of this that you don't get from just adding/removing packages in your home-manager config? Is it just a matter of it being quicker to do nix-env -iA instead of updating your config and running home-manager switch? Or is there some ot…

I do have that use case as well. Taking a parallel from git, it's kind of a working/staging area/stash. There's a feeling of zero commitment. It could be I try out some unknown package, or that I have a temporary one-shot need that still lasts longer than a nix-shell -p.

But mostly I use it as a beachhead for people to eventually jump ship, helping them climb the first step of the ladder:

"see? It's easy to install and use, you'll be quite autonomous. And if you feel it's not your thing just ignore it or rm -rf /nix"

Then I bait them with e.g shell.nix just enough to tease their curiosity.

So instead of feeling overwhelmed by a whole new arch and contractually tied by configs they feel free, empowered, and curious.

Re: NixOS 21.05

#200
post #188

Earlier quoted context omitted.

> I let my profile build up 10-20 things installed, then every few weeks I decide what belongs in my declared config and uninstall everything in the profile. I'm curious what you get out of this that you don't get from just adding/removing packages in your home-manager config? Is it just a matter of it being quicker to do nix-env -iA instead of updating your config and running home-manager switch? Or is there some ot…

> Is [the benefit of this approach] just a matter of it being quicker to do nix-env -iA instead of updating your config and running home-manager switch? That's definitely a factor. I think since I keep my Nix configurations in source control, somehow modifying the configuration feels more ‘official’, and it also usually comes with extra steps like committing and pushing. The other thing I like is that it makes it ver…

> or even what version number a package has

In the context of within nix packages that's correct. In the context of nix usage that is not.

I start a project, I need it to use Ruby 2.7.x, OpenSSL 1.1, node 14.x because that's what the project is compatible with, and I need that to happen on both Darwin, Linux, on whatever cpu arch. Pinning the hashes of "whatever I built it with" won't work.

Worse, some software such as e.g Ruby encodes their platform at build time (because it matters, because #ifdefs) so currently I'm on darwin20 but specifying "ruby" pulls in RUBY_PLATFORM==darwin17. Nix is currently helpless in face of that.

> and it doesn't involve rebuilding my whole system

True. One thing I'm 100% sure is that nix-env -i will do just that and nothing else, whereas nixos-rebuild switch might include something else pending I might have forgotten about because it relies on globals.

Post reply on HN