NixOS has one fatal flaw

This page summarizes the projects mentioned and recommended in the original post on news.ycombinator.com

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.
www.influxdata.com
featured
SaaSHub - Software Alternatives and Reviews
SaaSHub helps you find the best software and product alternatives
www.saashub.com
featured
  • cli

    GitHub’s official command line tool

    (Context: I'm pretty thick into Nix, and have been for about four years. Most of this post is focussed on the NixOS desktop experience, so DevOps nerds, ymmv.)

    Unpopular opinion: Nix is not that hard.

    What's "hard" from a nix-promotion strategy is motivating people to understand why they would want the benefits it offers. Mostly because Nix, especially with home-manager, dramatically worsens UX for several day-to-day tasks, simply by violating the Law of Least Surprise every couple of hours in normal use.

    I want a fully idempotent, version-locked, rewindable user environment, with a version-controlled central config, because I have half a dozen devices that, for reasons, I need to keep perfectly interchangeable with one another. Most users do not want this, for the simple fact that mutating their configs and differentiating them locally on specific machines is not a bug, but a feature.

    Even more than that, it's an expectation that most software developers share as well.

    Case in point: I filed a bug against the GitHub CLI last week. If any org has the scope and motivation to build software that's compatible with NixOS, an OS most of whose users are developers, it should be GitHub, which is, at least notionally, all about developers, developers, developers. A change in GH required a config format migration, which was sensibly done by opening the config .yml and rewriting it.

    Of course, this breaks NixOS not just in practice but in principle. NixOS/home-manager makes config files read-only. Surprise! https://github.com/cli/cli/issues/8462

    The response from GitHub was basically, "yeah, we knew this was going to happen, we mentioned it to the packagers at NixOS, but we did it anyway, because it was still the best way to proceed for us." (And they weren't wrong.)

    Now, once a month is an annoyance, but I run into these problems daily. I can't imagine any sane person -- which I am not -- would persist with using it.

    Why do I keep using NixOS, then? Because I am terribly and disproprotionately annoyed by small changes in my user experience, which I find disruptive to my workflow and hence threaten my success. For me, forbidding apps from mutating the config files I established for them is a selling point. Being able to version-control an idempotent declarative config for all of them at once is heaven.

    Unless you're like me, you'll hate NixOS. But some were meant for Nix.

    Because

  • 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.

    InfluxDB logo
  • garn

    garn is a build tool and environment manager that replaces justfiles/makefiles, docker, and the annoying parts of READMEs. The builders lingua franca.

    Garn [0] is most of that: simpler CLI, and Typescript for configuration, though lying on top of Nix.

    (Disclaimer: I work on garn)

    [0] https://github.com/garnix-io/garn

  • devenv

    Fast, Declarative, Reproducible, and Composable Developer Environments

    I don't think you can ever get Nix as simple as PNPM, simply because native libraries are sometimes annoying, need to be configured at build time to a greater degree and because the problem space it attacks is so much larger than PNPM, which only deals with the JS/Node.js ecosystem.

    However, I do think that there exist reasonable levels of abstraction that sacrifice some expressive power for simplicity and such systems could maybe expose a PNPM-like CLI. One example that comes to mind is devenv.nix [1]. While it doesn't yet have a CLI, its configuration file is YAML and relatively simple. I think there's more to be done in this space and I hope for tools that are easier to grasp in the future.

    > Nix package files evaluate down to configuration for the Nix package manager, but I haven’t ever seen a good explanation for the basic essentials underneath all the abstraction. Every guide I’ve learned from and all the package defs I’ve read seem to cargo cult many layers of mysterious config composing config. Without easy to learn essentials it’s difficult to grok the system as a whole.

    To me it sounds like the essential that you're referring to is the 'derivation' primitive, which is almost always hidden behind the mkDerivation abstraction from nixpkgs. This [2] blog post is an exploration of what exactly that means.

    I'd also love for the documentation situation to be much better, in particular in terms of official, curated resources. But I'm not convinced that you actually need to know the difference between derivation and mkDerivation to make effective use of Nix, because in practice you would always use the latter. That said, mkDerivation and the whole of nixpkgs is essentially a huge DSL (I believe this is what you meant when you said 'config composing config') that you do need to know and is woefully underdocumented.

    > I would love to adopt Nix for developer tooling for Notion’s engineers, but today it’s about infinity times easier to work around the limitations mentioned of Docker+Ubuntu+NPM than to work around the limitations of Nix.

    One approach I have taken to is to specify the environment in Nix, but then generate Docker devcontainers from it, so most people don't come into contact with Nix if they don't want to.

    [1] https://devenv.sh

    [2] https://ianthehenry.com/posts/how-to-learn-nix/derivations/

NOTE: The number of mentions on this list indicates mentions on common posts plus user suggested alternatives. Hence, a higher number means a more popular project.

Suggest a related project

Related posts

  • How to Initialize a Git Repository and Create a GitHub Repository Using the GitHub CLI

    1 project | dev.to | 2 Jul 2024
  • Ok Boomer! Instant GitHub Repo Creation in One Command 🚀

    1 project | dev.to | 1 Feb 2024
  • How do you handle secret rotation in kubernetes (i. e. with github access tokens)

    1 project | /r/kubernetes | 9 Dec 2023
  • pyaction 4.27.0 Released

    2 projects | dev.to | 8 Dec 2023
  • I (kind of) killed Mercurial at Mozilla

    12 projects | news.ycombinator.com | 21 Nov 2023

Did you konow that Go is
the 4th most popular programming language
based on number of metions?