Is Nix eating the world? We have seen lots of unbelievable projects using it on HN recently. It feels like anyone serious about complex systems and building software are embracing it.
I use it extensively also via nixpkgs, though somehow I have yet to make the leap to full NixOS.
One consideration for anyone who hasn’t jumped in, is that I have nixpkgs on Linux, MacOS, and Win11 hosts. I’ve found that incredibly useful.
Opt-in state:
https://github.com/nix-community/impermanence
https://grahamc.com/blog/erase-your-darlings
Ease of setting up a real-time audio on Linux:
https://github.com/musnix/musnix
Generating virtual machines/installators from a configuration:
https://github.com/astro/microvm.nix
https://github.com/nix-community/nixos-generators
It's interesting to scroll through nix-darwin options, I wasn't even aware of some useful macOS options before:
https://daiderd.com/nix-darwin/manual/index.html
A neat collection of music information retrieval packages in one place (and the ease of creating your own package registry):
https://news.ycombinator.com/item?id=40010991
https://news.ycombinator.com/item?id=39720007
https://news.ycombinator.com/item?id=39692801
https://news.ycombinator.com/item?id=39658684
https://news.ycombinator.com/item?id=39004785
I didn’t find these via HN search, I found them in my bookmarking account. I have a slightly strange way of bookmarking - I send emails to a dedicated email account, so these I found there looking for Nix in a search.
does it work for 10k bmarks?
Also plenty of projects here: https://github.com/nix-community/awesome-nix
really useful.
We've also been thinking about ways to make nixpkgs available there. Adding `lib` at least in some fashion would be quite useful, I think.
The goals they list are:
> Creating an alternative implementation of Nix that is fully compatible with nixpkgs.
No explanation needed.
> More efficient Nix language evaluation, leading to greatly increased performance.
The Nix language is evaluated whenever doing the Nix equivalent of installing a package, or rebuilding your configuration. Note that most of the time it's "fast enough" but the authors of Tvix are doing more with the Nix language (which leads into)
> No more strict separation of evaluation and build phases: Generating Nix data structures from build artefacts ("IFD") should be supported first-class and not incur significant performance cost.
and
> Well-defined interaction protocols for how the three different components (evaluator, builder, store) interact.
As it currently works, the Nix language is evaluated to something called a derivation, which is a specific format for defining how to build something (including a list of dependencies). The derivation is then used to actually build the artifact. This is about when you want the metaphorical snake to eat its tail and have the results of a derivation be more nix language to evaluate.
> A builder implementation using OCI instead of custom sandboxing code.
Hermetic builds require some sandboxing; Using OCI containers seems like an obvious choice, but didn't exist when Nix was first created.
> Hermetic builds require some sandboxing; Using OCI containers seems like an obvious choice, but didn't exist when Nix was first created.
Presumably this would make this implementation Linux-only, since OCI isn't natively supported outside of Linux?
A complete non-starter, never in a thousand years am I gonna use something that requires a Docker installation for building derivations.
Using this for what Nix is doing is absolute madness. Docker is madness in general, but dragging it into Nix's core is madness cubed.
if you don't want docker-contributed code, here are some alternative implementations of the spec: https://github.com/opencontainers/runtime-spec/blob/main/imp... I believe nix could use one of these with some volunteer effort? Perhaps you could even be the one to purge the Docker heresy from the project!
It is an attempt at an open-source "just good enough" Docker clone.
You understand the difference?
huh?
working on a project that I'd love to run by you in the men's health space.
came across a comment you made on a previous post, so figured I'd reach out.
amitthakrarcoaching@gmail.com
The location of the store is not really the main blocker in those sorts of situations, IMHO.
A project funded by the EU to bring Nix to Windows.
(edit: typo and clarity)
In Russian, "tvix" is pronounced, roughly, "tweaks" (but with a German - hard "v" - W sound), which to a Russian probably sounds super clever, given what Tvix is (Nix, tweaked).
In English though, how is it pronounced? I'd like to propose "t-f-icks", because it at least sounds like a candy we think the Lebowski nihilists might well have been ordering at a diner.
I've noticed when talking to English native speakers that Brits seem to get it right away and say something close to "твикс", whereas Americans almost always say "tee-vix" ("тивикс") and need serious convincing work to switch over to how we say it.
naming is hard :)
0. https://www.thestreet.com/etffocus/market-intelligence/rip-t...
(kindof like tuh-veeex run together)
...as the candy bar etymology in their logo implies.
It feels like things are heating up, and "soon" is on the horizon.
{ pkgs, ... }: {
services.postgres = {
enable = true;
package = pkgs.postgresql_15;
initialDatabases = [{ name = "mydb"; }];
extensions = extensions: [
extensions.postgis
extensions.timescaledb
];
settings.shared_preload_libraries = "timescaledb";
initialScript = "CREATE EXTENSION IF NOT EXISTS timescaledb;";
};
}But it looks like a good choice for running tests in CI.
devenv.sh autogenerates Nix specifications of container images for each of the development environments you define with it, and exposes them in a Nix flake for you. But if you don't explicitly ask Nix to build those for you, it doesn't.
My team's most complex devenv environment passes through some packages from Nixpkgs, exposing them in the flake, defines 3 or 4 development environments ('devShells') and also exposed (and includes in some of those devShells) some custom packages that just live in that repo and not in Nixpkgs.
Our simplest just uses all built-ins and defaults, exposes no packages, doesn't have a custom flake... there's basically nothing to it. It just uses devenv/Nixpkgs built-ins to add OpenTofu with some Terraform plugins to the path and plugs a Terraform linter into the project's pre-commit hooks.
There is some support for running long-lived processes via process-compose, which is inspired by docker-compose, but we don't yet need it for anything so we don't use it. (In the past I've rolled my own solution for this with Nix, direnv, and supervisord. Today I'd probably just use devenv.)
What I love about devenv is how cleanly it integrates with the wider Nix ecosystem in a no-nonsense way, as well as its great docs. I like that it
- it uses the Nix module system for configuration, based on a standard implementation (flake-parts) shared by other projects
- what it builds in, i.e., pre-commit hooks integration, exists in a separate repo also usable on its own via flake-parts
- the docs and the tool both support flakes-based setups, non-flakes setups
- if you want to let devenv automagically set up a flake for you, you can, but you can also use most of its features with a handwritten flake.nix customized to your liking
- while it exposes some configuration via yaml for simple uses, the full power of Nix is always available
- it takes care of all the little details you'd have to deal with if rolling your own (e.g., garbage collection, direnv integration) in a sensible way
I hope that helps you get a sense of what using devenv is like for simple use cases as well as what the more complex stuff might look like!
I'd describe this as "(language-specific) package management".
"Requiring root privileges" is more/less equivalent to "packages get installed in a system-wide location".
There are some C or C++ specific package managers.. but, essentially what's missing is the ecosystem/culture for providing a packages for those. -- e.g. With the Rust, packages use Cargo.
> Is this nix/tvix/guix an equivalent of pip?
Nix and guix are system package managers.
Since they're powerful tools, one popular use case is for providing dependencies for C projects.
Nix practically requires root for its installation. (i.e. installing it without root may be possible, but I'd think it's impractical). Although once installed, it can provide packages without needing root.
https://nixos.wiki/wiki/Development_environment_with_nix-she...
IIRC, Nix names things like "$unreadable_hash$pkg_name" which makes tab completion impossible in the case someone wants/needs to go spelunking in that directory.
I just checked on my laptop and I have, for example, over 400 stdenv-linux build outputs in there.
(this'd still suffer from the common fail of flat folders, should've used proper nesting, but not as much as hash-first)
My usecase for interacting directly with the store is that I want to look at some specific store path, so I already know the hash from somewhere and can autocomplete on the first characters with much higher precision than first completing drv names, and then moving on to the right hash.
You seem to have some other kind of use-case. What is it?
And 2_of_name + 2_of_hash is giving you higher precision in one match as it has more info to match against the full path vs just 2_of_hash
Spelunking in nix store dirs directly is usually unnecessary, though. You can debug/tinker with your derivations in nix shell (or, confusingly as always, nix-shell).
in this case typing is evaluation. so tvix promises doing typing faster.
1: https://aphyr.com/posts/342-typing-the-technical-interview
[1] https://lobste.rs/s/ypwgwp/tvix_we_are_rewriting_nix#c_zvtze...
Many users have a poor understanding of what Flakes _actually_ are: They are a bit of UX glue on top of existing Nix features:
- Input/output schemas for `flake.nix`
- A lock file format
- CLI features to work with the two above
It's entirely feasible to build out a Flake user interface & evaluation support on top of Tvix without making it a first-class evaluator feature. See https://github.com/edolstra/flake-compat for prior art.
The key point of Tvix _not_ having support for Flakes is to not make special snowflake evaluator features that are tied in with it.
Except that it rolls its own CA store[1], which is also not a stable Nix feature. One could argue that it has to roll its own store because Nix wants to own the store, but implementing a shadow version of an experimental feature makes the "they're just targeting stable features" part ring rather hollow.
> The key point of Tvix _not_ having support for Flakes is to not make special snowflake evaluator features that are tied in with it.
That's not really how I read the authors' defense of this choice. It seems like they made it because they disagree with the design decision, and I consider that more defensible than the position you offer. I just wish they would make this information more central, and I will keep posting it in news items about Tvix because no one else is going to. There is no indication that the "Nix" they implement is many years old now, and when they do[2] indicate it, they are vague about why.
[1] https://cs.tvl.fyi/depot/-/blob/tvix/castore/docs/data-model...
[2] https://cs.tvl.fyi/depot/-/blob/tvix/README.md#compatibility
I follow some chats with lots of Nix beginners, and the amount of people that are now stuck in a flakes tarpit and have no understanding of the fundamentals of Nix (and no path to get there, really, in the course of normal usage) is depressing. Just the other day I saw someone post a 40 line Nix code snippet using flakes, pulling in 2 git repos apart from nixpkgs (because the barebones flakes are barely even usable without support libraries), all to make a simple nix-shell with a single package in there - and it didn't even work and they were unsure how to proceed with debugging.
In almost all chats with flakes proponents it also eventually turned out that what they want is something like niv, but integrated into the Nix binary, not all of the additional stuff that is attached to flakes.
Anyways, adisbladis' point is that Tvix does not need to support flakes in any way. If you really want to add these complications to your Nix code, you can implement everything flakes do in pure Nix (using e.g. the flakes-compat thing linked above).
He seemed quite opinionated on flakes, but the only bad thing that I can see to flakes is that you cannot pass args to them, for imo no valid reason, you have to use the file+file protocol and update the inputs each time to have a reasonable way to pass parameters...
I do not see a path forward for them in Tvix before we get to fix them layer by layer, which Nix is trying to do (slowly?).
At some point, once we stabilize a bunch of things, I have some plans to do what I call the right design of Flakes, but it does not involve modifying completely the core of the interpreter to leak this implementation detail everywhere, but more make this a library concept.
(That said, the tooling around flakes is so much nicer that I still use and recommend them.)
asking nix to accept arbitrary args in flakes like asking to so random patch of rust code during compilation. to patch use cargo patch. that is analogy of flakes, when you thing how flakes make nix statically typed.
That's going to be a no from me.
Now, let's put the risk at the root of the build system, and leave the lead devs in a country known to coerce, threaten, torture, poison and kill its dissidents.
That's a no from me, dawg. Look outside, it's not 2015 anymore.
Unfortunately… if that’s going to happen, I’d rather have it happen without first having huge security breaches.
It's a war, things have changed.
This is a product whose major contributors live in a state prone to very persuasive forms of coercion. Worse, this is a _build system_. Moreover, it's one of the most reticulate build systems on the planet -- I doubt more than a few hundred senior engineers would be able to spot a Jia-Tan-style compromise in the Nix machinery, let alone a remix/workalike of it.
There is currently a war going on. Not a 'war on' drugs, or cancer, or a 'culture war', or any of the other phenomena that Americans routinely nowadays call a 'war', but an actually-actual conflagration involving grads, kinzhals, and, easily, the futures of a couple of well-intentioned engineers in Moscow.
I expect the creators of this product are sincere, serious, smart, kind, generous, funny, honorable people. Yet it is simply too plausible that the FSB could come by and lean on them (or their uncle, or mother, or sister, or...) and have a little something extra put at the very root of the tree, from where it could be folded into any (or every) part of the system.
Open source across international borders is a peacetime phenomenon, as we are all about to discover, methinks. I hope I'm wrong.