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

NixOS 21.05

nixos.org

Post reply on HN
Print view View original

161–170 of 234 posts

Re: NixOS 21.05

#161

Post by Mic92 »

deckard1 wrote: post #102

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…

Within a release there are no version bumps, only if you live on unstable or switch to a new release you would get them. The problem of an actual snapshot of your entire system is that you don't really now what should be in there and it collects a lot of cruft/state. With NixOS you can write little modules for services and move those between VM/Machines, whatever floats your boat. IMHO this type of config management sucks less than ansible/chef etc because you are not fighting against the package manager. The configuration holds the ground truth on what is installed on the system.

Re: NixOS 21.05

#162

Post by Mic92 »

jpe90 wrote: post #64

What do experienced nix-ers tend to do when they need to use software that's not up to date or available in nixpkgs? Are you guys knowledgeable enough to package everything yourselves, or do you just use buildFHSUserEnv until someone else works out the kinks? I didn't get a chance to figure out how to do the latter, but I'm curious because I've struggled as a new user.

I run [nix-update](https://github.com/Mic92/nix-update/) to update stuff. If you want to package something new, first identify the programming language/buildsystem the project is using and than look for a similar project in nixpkgs.

Re: NixOS 21.05

#164

Post by sorbits »

Mic92 wrote: post #150
sorbits wrote: post #148

Earlier quoted context omitted.

The thing with a lot of server software (like postfix) is that configuration is usually spread across many files. And then there is the re-use of things between services, for example DKIM’s generated public key should be made available as a TXT record by the DNS server, the SSL certificate kept up-to-date by the web server should be used by both the smtp and imap servers, though it may need to include the full chain,…

I do have all these things ( https://github.com/Mic92/dotfiles/blob/master/nixos/eve/modu... , https://github.com/Mic92/dotfiles/blob/master/nixos/eve/modu... , https://github.com/Mic92/dotfiles/blob/master/nixos/eve/modu... ...). Especially things like ACME work a lot better the NixOS-provided curated and unit-tested acme module compared to setting up it yourself. You can also use the Nixos simple mail server setup…

Appreciate the links, thanks!

Re: NixOS 21.05

#165

Post by adkadskhj »

kaba0 wrote: post #154
adkadskhj wrote: post #131

Earlier quoted context omitted.

As a new NixOS user currently set up with home manager and flakes - i'd probably switch in a heartbeat if someone gave me a nice nix-like package manager that also handled dotfiles. As much as i love the feeling of NixOS, i really want something like a Lockfile as seen in Rust (and other languages). Ie if i could define a `Cargo.toml`, which includes versions of packages or `*` if i don't care - and then it gets buil…

I don’t really understand your problem as in NixOS it is precisely the easiest to handle some packages from this repo and anothers from another. You can just add a single line of an alternative repo like altNixpkgs = “reference repo either by url or path” in the let in “block” and instead of pkgs.something just use altNixpkgs.pkgs.something. Also, I usually manage my home packages separately from my global config. Th…

> I don’t really understand your problem as in NixOS it is precisely the easiest to handle some packages from this repo and anothers from another. You can just add a single line of an alternative repo like altNixpkgs = “reference repo either by url or path” in the let in “block” and instead of pkgs.something just use altNixpkgs.pkgs.something.

Yea, i actually do that for a couple of my dependencies. My problem is there are dozens or hundreds in my OS that instantly upgrade if i change my `nixpkgs` ref. And i have no clue what version _any_ of those are at, off hand.

Eg lets say i want to fix my X - because when i updated my `nixpkgs` pointer Xorg was using a lot of CPU for some reason. There's no lockfile that says what version X is at, or what dependencies X is using or associated with. Is it one package? Is it a half dozen? I could open the repo and dig through the configs to locate it and _try_ to infer what the hell version it's at, and what dependencies it has.. and then find what they're at and so forth - but it's convoluted imo. Much easier in Cargo.lock, for example - something i've done dozens of times before.

In short, basically everything in my OS broke when i updated my nixpkgs ref, and it's non-obvious and maybe non-trivial to understand what versions everything is at. To incrementally try to un-screw my system when i change my nixpkgs.

As i move forward, any packages i install i'm tempted to bind them to very specific inputs. So that when i want to upgrade one thing, only that one thing changes. But this workflow seems difficult in NixOS. Despite it being the workflow that i want.

Well, maybe not difficult - but lots of LOC. Adding dozens of inputs just to change versions of stuff without breaking other things seems like a lot of work for a dependency management system.. imo.

Re: NixOS 21.05

#166

Post by adkadskhj »

casept wrote: post #160
adkadskhj wrote: post #131

Earlier quoted context omitted.

As a new NixOS user currently set up with home manager and flakes - i'd probably switch in a heartbeat if someone gave me a nice nix-like package manager that also handled dotfiles. As much as i love the feeling of NixOS, i really want something like a Lockfile as seen in Rust (and other languages). Ie if i could define a `Cargo.toml`, which includes versions of packages or `*` if i don't care - and then it gets buil…

Given that you already have flakeified everything, it's not that hard to pull in a different version of nixpkgs and cherry-pick packages from it. I have a (somewhat complex) setup utilizing this: https://github.com/casept/nixos-config

Yea, i actually do that now. My problem is the dozens of packages i didn't hand pick all broke. So basically i need to hand pick everything. And in doing so, it feels like a lot more work than simply specifying what versions i want during the package install.

Re: NixOS 21.05

#167

Post by dnr »

hollerith wrote: post #66

I ran Nixos for a few months from Dec 25 to Mar 12 of this year. During that time there were 2 zero-day exploits published for Chrome that went unpatched for weeks on Nixos. (Specifically the package named google-chrome went unpatched.) This was on the "unstable" branch of Nixos, the branch that became the stable branch today, which is the occasion of this story on HN we are commenting on. Digression: the reason I ch…

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/NixOS/nixpkgs/commit/4fe69d33aeb6dac647e4...

The first landed in master on Jan 19 (the same day), the second landed in master on Feb 3 (one day late).

The way nix works, the CI has to build and verify a large chunk of packages before it gets promoted to unstable. So when did they hit nixos-unstable? It's not possible to tell from git alone, but the history of the channel is archived here: https://channels.nix.gsc.io/

I did the search and the first release hit nixos-unstable on Jan 21 18:20:45 (UTC), and the second on Feb 6 08:30:17 (UTC). So around two days and four days.

The backports to nixos-20.09 hit that branch on Jan 26 16:55:17 and Feb 6 13:45:20, so seven days and four days.

I'm not sure what the parent commentor was doing that led to them missing these updates.

To be clear, this is not a great record. I was running nixos-20.09 and I updated my system ahead of the channels (which is fairly easy, not at all difficult as the parent comment implies). But it's not "weeks", and it's not that bad for a volunteer project.

Re: NixOS 21.05

#168

Post by kaba0 »

adkadskhj wrote: post #165
kaba0 wrote: post #154

Earlier quoted context omitted.

I don’t really understand your problem as in NixOS it is precisely the easiest to handle some packages from this repo and anothers from another. You can just add a single line of an alternative repo like altNixpkgs = “reference repo either by url or path” in the let in “block” and instead of pkgs.something just use altNixpkgs.pkgs.something. Also, I usually manage my home packages separately from my global config. Th…

> I don’t really understand your problem as in NixOS it is precisely the easiest to handle some packages from this repo and anothers from another. You can just add a single line of an alternative repo like altNixpkgs = “reference repo either by url or path” in the let in “block” and instead of pkgs.something just use altNixpkgs.pkgs.something. Yea, i actually do that for a couple of my dependencies. My problem is the…

Thank, I get it now. Not a solution but perhaps try git bisecting the working and non-working version. It’s never a good thing to hunt down a bug but when one has to, the immutable nature of nixos actually makes it a very handy process.

Re: NixOS 21.05

#169

Post by mason55 »

pxc wrote: post #141
gugagore wrote: post #27

Earlier quoted context omitted.

It sounds like nix provides an escape hatch [1] out of the declarative framework into something imperative, e.g. running `apt install $package`. And that seems like it would really ease adoption, since I would assume that it would allow a gradual adoption of the declarative mindset. [1] https://wiki.c2.com/?EscapeHatch

nix-env isn't meaningfully an escape hatch, since you can still only use it with stuff that's packaged in Nix's peculiar way. Here's an overview of the escape hatches that are currently around in NixOS for package management, meaning you can use them to avoid packaging something natively for Nix, or to run pre-built software for other distros or targeting multiple distros: • flatpak — use flatpak to install stuff jus…

> Basically every module also has an ‘extraConfig’ type of option

This is actually changing so that the additional config can be merged/validated even if it can't be typed

https://github.com/NixOS/rfcs/blob/master/rfcs/0042-config-o...

Re: NixOS 21.05

#170

Post by foolmeonce »

alias_neo wrote: post #12
nitsky wrote: 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…

So if I understand correctly, I could declaratively specify my workstation, say I want vim, podman, codium, kubectl, curl, tmux, firefox, zettlr. I could put this in a configuration and have my workstation anywhere I can grab that from? Is there some way I can boot-to-git-configuration? So I could do this in RAM on someone else's hardware, like a network boot?

With nixops you also define define your configurations in nix (and can have interdependencies between them) then start machines or virtual machines as blank nixos installs and add their ssh key and address for nixops to reconfigure and manage.

I ultimately find it easier to have one host that is keeping track of all configurations and pushing my changes to all hosts since I otherwise end up with a lot of machines with different changes I've been working on.

Post reply on HN