-
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
-
-
-
-
-
SaaSHub
SaaSHub - Software Alternatives and Reviews. SaaSHub helps you find the best software and product alternatives
-
-
-
> because of a lack of volunteers to maintain all of nixpkgs
They need some serious shakeup from that side in my opinion. I've had PRs open for trivial things for >1mth. Issues, security stuff, new packages. They don't even document how to mark something as a security issue. PRs that mention CVE do that, but otherwise I couldn't find anything so for example https://github.com/NixOS/nixpkgs/pull/161198 which includes a security fix is still waiting.
If they can't pull off the reviews with 577 people (https://github.com/orgs/NixOS/people), there's they need to start dropping rejecting new ones or relaxing the automerge rules - at the very least on simple version bumps. Flakes at least provide some solution for easily including the 3rd party software without merging.
> And I don't mean a lack of documentation — what I mean is that the obvious decisions that have been taken (naming everything "Nix", using Haskell as a base for the syntax, ...)
I agree that the name is bad and has always been bad. I wonder what they were thinking. But the syntax of the Nix language is not based on Haskell. It would be better if it were, but the Nix syntax is actually based on trying to twist a functional language into looking like a Unix-style configuration file. It's horrible, and conceptually big details like "this is a function" is hidden in very subtle syntax (a single colon). The liberal use of semicolons and the use of space-separated lists is another concession to looking like a config file. I feel Nix would have been better if it didn't try to cater to older conventions in this way. Sometimes the old ways are just bad. Incidentally, one of the big advantages of Guix (a Nix fork/derivative) is that it uses Scheme as its declaration/configuration language.
I switched to Nix some years ago on my desktop system. While I was initially quite frustrated at lots of the paper cuts - particularly the byzantine design of Nixpkgs itself which is built around manual programming with fixed-point combinators - I was carried through by two things:
1) I was intellectually convinced that the basic premise was sound.
2) Getting a basic desktop system running doesn't require you to understand all the complexity. NixOS works really well out of the box with its standard settings, and making basic configuration changes and adding/removing packages doesn't require you to know anything about the Nix language or the design of Nixpkgs.
Not much later I was able to do pretty radical things like changing the version of LLVM used by Mesa on my system, to work around a defect in AMDs GPU drivers[0]. I have no idea how I would do something like that on Debian. Even better, when this workaround later became unnecessary, I just removed the pertinent parts from my configuration file, and it was like it was never there. My system is fully declarative and not soiled by the remnants of previous hacks.
[0]: https://github.com/athas/dotfiles/blob/d495aeb85fe38569eb212...
I know of least three approaches:
1. For per-user configuration there is home-manager which symlinks dotfiles to Nix store based on a single "home.nix" derivation (state). Home-manager is usable outside of NixOS and, in my opinion, it is better than most dotfiles managers. https://github.com/nix-community/home-manager
2. In NixOS /etc is composed in the same way from the system derivation.
3. Outside of NixOS, I think, one can build systemd units which refer directly to configuration files in Nix store. Probably one can add config paths into wrappers, but it will be very fragile and won't scale.
We use naersk[0] for Rust projects in our Nix monorepo (for example [1]). It's pretty hands-off in terms of the Nix code needed (you don't need to pin hashes inside of the Nix code as long as you have a Cargo lockfile) and all the existing tooling keeps working fine.
The main drawback of it is that it currently builds all of your dependencies in one big derivation, so any dependency changes cause a full rebuild. There's some other project I saw fly by which attempts to do a similar thing but split each crate into a separate derivation, but I forgot what it's called and have no experience with it.
[0]: https://github.com/nix-community/naersk
[1]: https://cs.tvl.fyi/depot/-/blob/ops/journaldriver/default.ni...
What’s powerful about nix is the language IMO. I was able to build an automatic WireGuard setup[1] with tagging that automatically works on each new machine thanks to the ability to do config as code. Just provide some basic config for each machine and the code turns it into an interface with peers.
The issue to me isn’t the language persay (it’s really a tiny surface area language, see the built in/lib functions [2]) but the tooling built around packaging is a hodgepodge mess of semi-documented workarounds (with Nixpkgs blessed ways vs used libraries) and is extremely difficult to approach and understand.
[1]: https://github.com/jordanisaacs/dotfiles
> Nix goes the other: what if we built a system around this concept.
This is what I'm referring to. There isn't anything currently as far as I'm aware that takes it as far as Nix. Sure, Arch has archinstall and there is also cloud-init.
There are examples of using JSON to help manage that:
https://github.com/archlinux/archinstall/blob/master/example...
But, ultimately I believe a lightweight Go/Rust tool that takes a YAML file and does essentially the same thing will prevail.
a) buildGoModule is a higher-level function that will return the result of mkDerivation in a way that reuses everything that is common to Go modules. So it makes perfect sense from the perspective of a maintainer who wants to reduce the size of nixpkgs as much as possible, which is already one of the largest Git repositories on GitHub.
b) Nixpkgs library functions like buildGoModule, with the need to maintain the separate vendor hash, come from a desire to write pure Nix functions without network access, i.e. there is no need to re-download the vendored dependencies if they already exist in the local Nix store cache. Indeed, the fact that there is only a single vendor hash represents a pragmatic compromise; whenever any dependency changes, the entire vendored dependency tree needs to be re-downloaded and rebuilt; if the hashes of the individual dependencies were tracked, then Nix would understand to only download the dependencies which had changed. The reason why Nix can't compute the dependency hashes of each dependency internally, and only then try to check the Nix store and see if they exist there, is because Nix does not yet support recursive calls: https://github.com/NixOS/nix/issues/13 (nearly ten years old). However, the RFC for adding support was finally merged: https://github.com/NixOS/rfcs/pull/92 and so support will come soon enough.
So basically:
a) buildGoModule is a higher-level function that will return the result of mkDerivation in a way that reuses everything that is common to Go modules. So it makes perfect sense from the perspective of a maintainer who wants to reduce the size of nixpkgs as much as possible, which is already one of the largest Git repositories on GitHub.
b) Nixpkgs library functions like buildGoModule, with the need to maintain the separate vendor hash, come from a desire to write pure Nix functions without network access, i.e. there is no need to re-download the vendored dependencies if they already exist in the local Nix store cache. Indeed, the fact that there is only a single vendor hash represents a pragmatic compromise; whenever any dependency changes, the entire vendored dependency tree needs to be re-downloaded and rebuilt; if the hashes of the individual dependencies were tracked, then Nix would understand to only download the dependencies which had changed. The reason why Nix can't compute the dependency hashes of each dependency internally, and only then try to check the Nix store and see if they exist there, is because Nix does not yet support recursive calls: https://github.com/NixOS/nix/issues/13 (nearly ten years old). However, the RFC for adding support was finally merged: https://github.com/NixOS/rfcs/pull/92 and so support will come soon enough.
So basically: