Determinate Nix is the "corporate" version. It's run by big names in the Nix ecosystem but there's perennial concerns about them not upstreaming improvements, trying to shove features in, whatever. I don't know if it has any compelling benefits over cppnix.
Lix I like because it feels like they're trying to fix a lot of the papercuts that are involved in the ecosystem, untangle the gnarly codebase, and so on. AFAIK there are no incompatibilities between it and cppnix unless you do weird stuff.
Guix has the advantage of using a proper language and first class home-manager(-equivalent) support. The biggest downside is that it's a gnu project so nonfree software support will always be secondary, and IIRC there were still enough sharp edges when I tried it that I went back to Lix. But I wish them well and hope they succeed!
So I'd say either Lix (if you want to be able to interop with the broader Nix ecosystem) or Guix (if you like Scheme, copyleft, or a more cohesive system).
AFAIK none of snix/tvix/etc are usable as a replacement for the cppnix binary in the way Lix/Detsys Nix are.
I do like the channel determinate offers with the built-in dependency cooldown. I haven't checked recently to see if that's available from anywhere else
I see how cooldowns may protect you in say npm, cargo or pip where releases get yanked on the regular, but I fail to see how using a 2-week out of date nixpkgs does any help
I mean I'm pretty sure that if a malicious package was merged to nixpkgs it would yanked or patched pretty quick? Or am I not understanding what you mean?
Lix because I trust the dev team more than any other Nix-like, with Guix as a close second in that regard. Not Guix because I don't like lisp and I do like the convenience of the world's largest package repository.
if you aren't sure, just use the primary implementation (nix / cppnix). it's the most well-supported, with the largest community around it, and the most nix developers and nix / nixos contributors working on it. the vast majority of people working on nixos use nix.
detnix is for detsys to move faster and do things specific to their clients' needs without being impeded by the development cadence of upstream nix, and to do things that upstream nix wouldn't accept for various reasons. there is effectively no reason to use this unless you're a client of detsys because the benefits don't really manifest without a support contract. they have a few cool things that won't be upstreamed, but you aren't going to find help in the main nix/nixos support channels using them, and they are arguably less battle-tested by nature of simply having fewer users that only do things on the happy path.
lix has a bunch of objectives, but at the present moment it's effectively upstream nix with some decent dreams (e.g., "demoting" flakes from core into a form of plugin system, and levelling the playing field for alternative implementations of similar ideas) and, in various areas, cleaned-up code. largely they haven't deviated far enough from upstream nix yet for it to matter from an end-user perspective, but right now there's no point locking in to using it if you're in a position where you're asking this question. the improvements between (cpp)nix and lix are cyclical, with a lot of them in one ending up in the other, because there is significant development overlap. it's also a bit more "community-focused", but said community is very small.
guix the implementation is an entirely different story. it's for guix the operating system, and has a bunch of different expectations entirely. the only similarity is that it uses some components of the nix store. a sibling comment mentions that it uses a "proper language" which is an implication i'd suggest isn't quite correct—nix is indeed a "proper language". "it uses a general-purpose language" would be more apt: nix the language is focused exclusively on package management, whereas guix uses a full scheme (guile, specifically). if you're interested in nix/nixos, guix is not the thing for this. if you're interested in the guix ecosystem, guix is the only thing for this, but that comes with significant tradeoffs in general usability and mainstream-ness (e.g., the init system, the package ecosystem, the attitudes towards "non-free" things).
snix (superseding tvix) and co. are reimplementations from scratch that aren't "there" enough to be used day-to-day yet. they are working hard on closing this gap but it's a massive job.
i just use (cpp)nix, but i keep a close eye on lix and snix. once lix figure out the flakes thing and a decent alternative crops up i'll probably migrate to that, because flakes do have material deficiencies that can't really be fixed without a massive amount of work due to how tightly they are wound into the the nix implementation. snix interests me "because rust" and also because a greenfield implementation has the opportunity to fix many things that would require large refactors otherwise, but it has a long way to go from at this moment.
there is effectively no reason to use this unless you're a client of detsys because the benefits don't really manifest without a support contract.
Macs are a reason to use detsys nix without being a detsys client. Because their corporate clients are often macOS users, detsys nixd plays more nicely with Apple macOS updates, whereas cppnix traditionally requires manual intervention after updates. I haven’t checked whether this is still true, but it’s why I recommend detsys nix to all my coworkers on macs.
I chose Lix because I like the idea of Nix with community-first principles that takes Rust seriously, and really I only chose it over Guix because Nix is more popular and will have more industry usage as time goes on. Guix is probably cooler but being Lisp it'll never be popular enough that a guy like me could get employed to work with it.
Guix for the community, documentation, and it turned out that I found the embedded domain specific language in scheme to be more ergonomic for my tastes. I used Nix for a year prior to my switch in 2015.
I just use regular nix because it does everything I need and just works. I have no motivation to move off. The internal politics are of no interest to me and none of the others offer a compelling technical reason to move.
The community around it is overall pretty nice. There's been a lot of tension lately around genAI use (sound familiar?) but it's still one of the FOSS communities that I resonate with most strongly
The fact that they try to keep things written in Scheme as much as possible makes jumping around the source very approachable. I imagine that if I were using Nix, I might get used to nixlang but have trouble reading through the C++ source of the tooling itself. In Guix, both of those are Guile Scheme. (As is the init system, and there's some neat things you can do there)
The UX always meshed better with how my brain expected it to work. I could never quite get used to the arguments that e.g. the nix-env command took. Nix seems to have improved this with their (still experimental?) nix command, but I think I'd already been using Guix for a while by the time that came out
Just regular nix. I'm not really involved in the nix community so I'm only vaguely aware of the drama, meaning I have no reason to switch until one of the forks starts offering a clear technical improvement.
For me personally I like Lix because the people in it give me good vibes from how I've seen them interact. I get the feeling that in the Lix spaces people feel very accepted which is always a good indicator of a great community.
Also even though I don't know how to use Gerrit them using it gives me the impression that they care a lot about how the software is developed and built which is important to me.
Integrating Rust and focus on good error messages are examples of other things I like about it.
This is not saying Nix is the opposite but the things I care about seem to be emphasized in Lix and that's why I like it.
Regarding Determinate Nix I just trust them less because of the financial interest they have. If hope they have good intentions but I don't want to rely on it since I've been disillusioned about companies having my interest in mind in general. I just hope they do good work and upstream that.
I switched back from Lix to Nix because I encountered some error that I don't remember, unfortunately. Now I wish I'd written it down. I will give it another try when I have a spare day.
Just use upstream nix. I was using Lix but they kept on breaking or removing features that worked fine and that I'm using. Even if you don't use those features, a dependency might. Lix made sense back when upstream was unstable between releases and Lix promised stability. Since then, upstream has improved and new releases dont cause concern about regressions; on the other hand Lix diverged from its 2.18 compatibility promise and has been deliberately introducing regressions. Stuff like erroring if rec is used on an attrset with computed keys.
NixOS has forked back the Rust installer. The Dix installer used to support upstream Nix but doesn’t any longer. It also installs their proprietary daemon.
I use NixOS, with occasional thoughts about moving to guix, because nix-the-language is awful, but then I don’t because I like the size of the nix community.
I use NixCpp since I want BLAKE3 hashes & Lix doesn’t support it. Otherwise, at least for now, Lix aligns more with some of my beliefs & I would like to try it again. NixCpp has been improving too tho.
I could see NixCpp being better/leaner/cleaner if it could shed the baggage of Flakes being merged prematurely. That feature IMO needs to be label “experiment failed” & moved out into a plugin (Lix’s goal) or separate project such that 1) the binary is not concerned with input pinning, schemas, or the extra maintenance burden of forge-specific support in fetchTree (largely to facilitate in adding input pinning / refreshing to the binary) 2) those that wish to use/adopt/contribute to flakes can iterate independent of the binary 3) alternatives can be on equal footing as I think the design has a lot of flaws (but it’s hard to compete with “just enable this flag”). There just so many bad patterns that have resulted from when flakes ergonomics push projects into heavy coupling; the way folks use flakes get their otherwise stable code completely locked behind an unstable feature that is non-trivial to evaluate (since flake.nix isn’t valid Nix).
I’d like to try Guix in theory but I don’t care for LISPs & it’s as simple as that for me, an ML-family fan (I believe there are non-LISP-y way to use it, but technically you can skip Nix the language by compiling to the .drv files too).
I've been on NixOS for about 10 years. I just reinstall git and other programs whenever they stop working (presumably after GC sweeps a .so dependency away?), never bothered with flakes or home-manager or whatever, don't understand the configuration language. I get screenfuls of "xx dependency is out of date, use xy" messages on system updates. It's low-maintenance and high-maintenance at the same time, if that makes sense.
I've been thinking of switching to something simpler. I don't think there are any Nix features that are unique, important to me, and outweigh the rest of it. I kept starting to try Guix (so I can actually write software packages for my own computer!) but every spare machine I could test a new OS on is 32-bit, so they're getting Haiku or NetBSD for fun, and I guess I'll have to set aside a sunday to just jump ship.
quasi_qua_quasi | 12 hours ago
Determinate Nix is the "corporate" version. It's run by big names in the Nix ecosystem but there's perennial concerns about them not upstreaming improvements, trying to shove features in, whatever. I don't know if it has any compelling benefits over cppnix.
Lix I like because it feels like they're trying to fix a lot of the papercuts that are involved in the ecosystem, untangle the gnarly codebase, and so on. AFAIK there are no incompatibilities between it and cppnix unless you do weird stuff.
Guix has the advantage of using a proper language and first class home-manager(-equivalent) support. The biggest downside is that it's a gnu project so nonfree software support will always be secondary, and IIRC there were still enough sharp edges when I tried it that I went back to Lix. But I wish them well and hope they succeed!
So I'd say either Lix (if you want to be able to interop with the broader Nix ecosystem) or Guix (if you like Scheme, copyleft, or a more cohesive system).
AFAIK none of snix/tvix/etc are usable as a replacement for the cppnix binary in the way Lix/Detsys Nix are.
Zavec | 9 hours ago
I do like the channel determinate offers with the built-in dependency cooldown. I haven't checked recently to see if that's available from anywhere else
pbsds | 2 hours ago
I see how cooldowns may protect you in say npm, cargo or pip where releases get yanked on the regular, but I fail to see how using a 2-week out of date nixpkgs does any help
dxo | 2 hours ago
you think nixpkgs is immune to supply chain attacks?
pbsds | 2 hours ago
It isn't. For cooldowns to add security, someone has to apply security patches or yank releases, otherwise it is nothing but an artificial delay.
dxo | 55 minutes ago
I mean I'm pretty sure that if a malicious package was merged to nixpkgs it would yanked or patched pretty quick? Or am I not understanding what you mean?
polywolf | 12 hours ago
Lix because I trust the dev team more than any other Nix-like, with Guix as a close second in that regard. Not Guix because I don't like lisp and I do like the convenience of the world's largest package repository.
arcayr | 11 hours ago
if you aren't sure, just use the primary implementation (nix / cppnix). it's the most well-supported, with the largest community around it, and the most nix developers and nix / nixos contributors working on it. the vast majority of people working on nixos use nix.
detnix is for detsys to move faster and do things specific to their clients' needs without being impeded by the development cadence of upstream nix, and to do things that upstream nix wouldn't accept for various reasons. there is effectively no reason to use this unless you're a client of detsys because the benefits don't really manifest without a support contract. they have a few cool things that won't be upstreamed, but you aren't going to find help in the main nix/nixos support channels using them, and they are arguably less battle-tested by nature of simply having fewer users that only do things on the happy path.
lix has a bunch of objectives, but at the present moment it's effectively upstream nix with some decent dreams (e.g., "demoting" flakes from core into a form of plugin system, and levelling the playing field for alternative implementations of similar ideas) and, in various areas, cleaned-up code. largely they haven't deviated far enough from upstream nix yet for it to matter from an end-user perspective, but right now there's no point locking in to using it if you're in a position where you're asking this question. the improvements between (cpp)nix and lix are cyclical, with a lot of them in one ending up in the other, because there is significant development overlap. it's also a bit more "community-focused", but said community is very small.
guix the implementation is an entirely different story. it's for guix the operating system, and has a bunch of different expectations entirely. the only similarity is that it uses some components of the nix store. a sibling comment mentions that it uses a "proper language" which is an implication i'd suggest isn't quite correct—nix is indeed a "proper language". "it uses a general-purpose language" would be more apt: nix the language is focused exclusively on package management, whereas guix uses a full scheme (guile, specifically). if you're interested in nix/nixos, guix is not the thing for this. if you're interested in the guix ecosystem, guix is the only thing for this, but that comes with significant tradeoffs in general usability and mainstream-ness (e.g., the init system, the package ecosystem, the attitudes towards "non-free" things).
snix (superseding tvix) and co. are reimplementations from scratch that aren't "there" enough to be used day-to-day yet. they are working hard on closing this gap but it's a massive job.
i just use (cpp)nix, but i keep a close eye on lix and snix. once lix figure out the flakes thing and a decent alternative crops up i'll probably migrate to that, because flakes do have material deficiencies that can't really be fixed without a massive amount of work due to how tightly they are wound into the the nix implementation. snix interests me "because rust" and also because a greenfield implementation has the opportunity to fix many things that would require large refactors otherwise, but it has a long way to go from at this moment.
adriano | 3 hours ago
Macs are a reason to use detsys nix without being a detsys client. Because their corporate clients are often macOS users, detsys nixd plays more nicely with Apple macOS updates, whereas cppnix traditionally requires manual intervention after updates. I haven’t checked whether this is still true, but it’s why I recommend detsys nix to all my coworkers on macs.
jaculabilis | 12 hours ago
I just use regular Nix.
WilhelmVonWeiner | 11 hours ago
I chose Lix because I like the idea of Nix with community-first principles that takes Rust seriously, and really I only chose it over Guix because Nix is more popular and will have more industry usage as time goes on. Guix is probably cooler but being Lisp it'll never be popular enough that a guy like me could get employed to work with it.
allana | 12 hours ago
Guix for the community, documentation, and it turned out that I found the embedded domain specific language in scheme to be more ergonomic for my tastes. I used Nix for a year prior to my switch in 2015.
zaphar | 5 hours ago
I just use regular nix because it does everything I need and just works. I have no motivation to move off. The internal politics are of no interest to me and none of the others offer a compelling technical reason to move.
jfred | 4 hours ago
I use Guix for a couple different reasons:
nix-envcommand took. Nix seems to have improved this with their (still experimental?)nixcommand, but I think I'd already been using Guix for a while by the time that came outWeetHet | 8 hours ago
Lix because
log-format=multiline-with-logsand I'm more comfortable with their codebase, so I can patch it or contribute easierbarrucadu | 5 hours ago
Just regular nix. I'm not really involved in the nix community so I'm only vaguely aware of the drama, meaning I have no reason to switch until one of the forks starts offering a clear technical improvement.
bhoot | 12 hours ago
I run Guix on my machines and servers.
I like the community and its ethos. The contributors are absolutely brilliant.
I was fascinated with Scheme, wanted to try one, and found that Guix is a brilliant way to use a Scheme practically.
Since the community is small, one has a lot of space to shine. Not that I have grabbed this opportunity yet, thanks to my infant.
I love their experiments:
Guix built its own init system Shepherd, and keeps it working against non-trivial shifts like Gnome's increasing dependency on systemd.
Love
guix deploy. I used it to deploy a guix system on Hetzner VPS. I had to use a patched version though, the stock hetzner script was buggy then.vforvaline | 7 hours ago
Regular Nix, anxiety that I'll hit a very weird niche scenario where Nix and Lix aren't identical stops me from switching to Lix 😅️
ginkogruen | 6 hours ago
For me personally I like Lix because the people in it give me good vibes from how I've seen them interact. I get the feeling that in the Lix spaces people feel very accepted which is always a good indicator of a great community. Also even though I don't know how to use Gerrit them using it gives me the impression that they care a lot about how the software is developed and built which is important to me. Integrating Rust and focus on good error messages are examples of other things I like about it.
This is not saying Nix is the opposite but the things I care about seem to be emphasized in Lix and that's why I like it.
Regarding Determinate Nix I just trust them less because of the financial interest they have. If hope they have good intentions but I don't want to rely on it since I've been disillusioned about companies having my interest in mind in general. I just hope they do good work and upstream that.
msangi | 8 hours ago
I use Lix because I like the community building it and because of their focus on cleaning up the codebase/experimental features
tngl | 4 hours ago
I switched back from Lix to Nix because I encountered some error that I don't remember, unfortunately. Now I wish I'd written it down. I will give it another try when I have a spare day.
accelbread | 4 hours ago
Just use upstream nix. I was using Lix but they kept on breaking or removing features that worked fine and that I'm using. Even if you don't use those features, a dependency might. Lix made sense back when upstream was unstable between releases and Lix promised stability. Since then, upstream has improved and new releases dont cause concern about regressions; on the other hand Lix diverged from its 2.18 compatibility promise and has been deliberately introducing regressions. Stuff like erroring if rec is used on an attrset with computed keys.
wink | 3 hours ago
Ex-nixpkgs user here (never the OS).
I really want to try out Guix on real (or virtualized) hardware, mostly in order to avoid nix, the language.
pepegar | 5 hours ago
determinate nix bc/ of the installer. I didn't give much thought to it.
toastal | 3 hours ago
https://github.com/NixOS/nix-installer
NixOS has forked back the Rust installer. The Dix installer used to support upstream Nix but doesn’t any longer. It also installs their proprietary daemon.
jfb | 5 hours ago
I use NixOS, with occasional thoughts about moving to guix, because nix-the-language is awful, but then I don’t because I like the size of the nix community.
thisalex | 5 hours ago
Lix + nix-darwin
pbsds | 3 hours ago
I switch between lix and nix depending on which has the better eval speed. Right now I'm on nix.
jaculabilis | 3 hours ago
You might also check out fix.
toastal | 3 hours ago
I use NixCpp since I want BLAKE3 hashes & Lix doesn’t support it. Otherwise, at least for now, Lix aligns more with some of my beliefs & I would like to try it again. NixCpp has been improving too tho.
I could see NixCpp being better/leaner/cleaner if it could shed the baggage of Flakes being merged prematurely. That feature IMO needs to be label “experiment failed” & moved out into a plugin (Lix’s goal) or separate project such that 1) the binary is not concerned with input pinning, schemas, or the extra maintenance burden of forge-specific support in
fetchTree(largely to facilitate in adding input pinning / refreshing to the binary) 2) those that wish to use/adopt/contribute to flakes can iterate independent of the binary 3) alternatives can be on equal footing as I think the design has a lot of flaws (but it’s hard to compete with “just enable this flag”). There just so many bad patterns that have resulted from when flakes ergonomics push projects into heavy coupling; the way folks use flakes get their otherwise stable code completely locked behind an unstable feature that is non-trivial to evaluate (sinceflake.nixisn’t valid Nix).I’d like to try Guix in theory but I don’t care for LISPs & it’s as simple as that for me, an ML-family fan (I believe there are non-LISP-y way to use it, but technically you can skip Nix the language by compiling to the
.drvfiles too).tentacloids | an hour ago
I've been on NixOS for about 10 years. I just reinstall git and other programs whenever they stop working (presumably after GC sweeps a
.sodependency away?), never bothered with flakes or home-manager or whatever, don't understand the configuration language. I get screenfuls of "xx dependency is out of date, use xy" messages on system updates. It's low-maintenance and high-maintenance at the same time, if that makes sense.I've been thinking of switching to something simpler. I don't think there are any Nix features that are unique, important to me, and outweigh the rest of it. I kept starting to try Guix (so I can actually write software packages for my own computer!) but every spare machine I could test a new OS on is 32-bit, so they're getting Haiku or NetBSD for fun, and I guess I'll have to set aside a sunday to just jump ship.