Who uses NixOS? Who are you people? (And good-bye)

Help
21

I use Haskell nearly on a daily basis and I am extremely happy about this language. I don’t think it is fair to say something should be removed just because you do not like it. I like Haskell and don’t want it to be removed.

2 Likes
22

I agree with you in this aspect. I asked myself quite often already. Why do we need another language just to configure a system? Couldn’t we use Haskell? (Haha). More seriously: couldn’t we use TOML, Dhall? And I think part of the community is moving towards this idea. See, for example, GitHub - tweag/nickel: Better configuration for less.

Maybe you jumped on the train a little bit too early? For me, it was definitely worth jumping on this train earlier than later.

4 Likes
23

You’re right, which is why we’re thinking about having TOML as an alternative configuration language for Nix. See https://github.com/tweag/nix-ux/blob/66520b10a8b978b6ec99d073867458b912631b8d/my-hello-toml/nix.toml for a small example. But this is currently blocked on the need to have something like the NixOS module system built into Nix.

12 Likes
24

nixos.org says “if a package works on one machine, it will also work on another”. I don’t think this is accurate,

I’ve also found this particularly annoying… when I started learning Nix/NixOS I wasted quite a bit of time to this as it muddled my mental model of what Nix/NixOS can/can’t do (particularly on non-NixOS systems), how it compares to docker, etc.

I get that reproducibility is hard to sell but there has to be a better way than lying about what Nix does :slight_smile:

2 Likes
25

In general, nixpkgs are close to byte reproducible. The only situation where is works on one machine and not on another would be runtime assumptions not being satisfied (e.g. gnome needing certain services, GIO_MODULES, Qt plugins/modules). Some of which can be fixed at the package level, some which can not.

5 Likes
26

The only situation where is works on one machine and not on another would be runtime assumptions not being satisfied (e.g. gnome needing certain services, GIO_MODULES, Qt plugins/modules). Some of which can be fixed at the package level, some which can not.

Yep, and runtime is a big part of the claim “if a package works on one machine, it will also work on another”, at least the way I (and the OP) interpret it.
IME runtime issues are particularly bad on non-NixOS systems e.g. the need for nixGL, I’ve also had nix packages randomly crashing on Ubuntu.

3 Likes
27

That might be sign of the application’s non-deterministic behavior. Which can’t be fixed on OS level whatsoever.

28

This plot suggests you get good at NixOS very quickly, and then your progress stops (“Steep learning curve” is actually a misnomer)

29

If I were marketing NixOS, I’d target security. All the pieces fit:

2 Likes
30

I think that should not be relevant for this argument. Even if NixOS packages would be perfectly reproducible that doesn’t mean that it’s not as buggy or even buggier than some other OS.

And I think that premises of this discussion are already very confused. If someone’s expectations weren’t met then that’s unfortunate, but this is not a technical argument at all. This is psychology at best. Such arguments are just a fuel for flame wars.

2 Likes
31

That might be sign of the application’s non-deterministic behavior. Which can’t be fixed on OS level whatsoever.

Exactly! So why make a claim that can’t possibly be satisfied? :wink:

1 Like
32

Because we are human? Natural language is such ambiguous. Let’s use formal logic instead :stuck_out_tongue_winking_eye:

33

I included it because, if the packages are the same between two people (e.g. pantheon calendar), then the only reason why it would work on one machine, and fail on another would be an assumption is invalidated outside of the context of the package.

The only options would be:

  • Create a nixos module to make those assumptions true (but the package in isolation may still be broken)
  • Patch / wrap the package to remove external assumptions (which may not be possible, e.g. gnome services)
    • Ask upstream to remove the assumptions (which is just upstream patching it, which may not be possible).

Ultimately the issue is that a lot of software is not meant to be used in isolation, and nix can only do so much to make these assumptions “true”.

5 Likes
34

It says learning curve up at the top. A steep learning curve means that you must overcome the learning curve to be productive. Nix is very different of a philosophy from other package managers, and so you do need to “relearn” everything about package management as nothing carries over from other offerings.

Not sure why I’m entertaining this thread, your comments are consistently inflammatory.

Sorry your use cases with nix were not great? Hope you find a place to call home, as you already mentioned you were leaving this community.

4 Likes
35

In my experience the «works here but not there» problems fall into three cases:

  • Ones that get reduced to «works under one user here, but not under another on the same machine» by just creating fresh users (a big improvement on debugging experience!)
  • Ones where the task is in terms of controlling hardware and the hardware is different (oh well…)
  • Nvidia

Please do not discount that fact that the axis are labeled clearly wrong, though! The correct labeling of a learning curve is «Ox = tasks accomplished, Oy = effort spent learning». The picture labels the axes… it’d better not.

I would say that they are not so much inflammatory as demonstrating the fact that our positioning is bad at telling upfront to people whether they will get any benefit from Nix.

A lot of people are not in the situation where they suffer from package conflict, or want to bisect system upgrades, or have system configuration demands that can actually benefit from the configuration being in a Turing-complete language (which is hugely valuable for some use cases!), or want to set up a lot of complicated environments for the same user. Many of such people do not stand to gain enough from using Nix that is worth the effort learning things. Some people run setups where reinstalling Ubuntu LTS from scratch every time a release happens, «forever», is less effort than ever learning Nix.

We have not yet found how to describe Nix to make this distinction clear. Some people among those who had little to gain fron Nix, spend effort learning and get annoyed. I think we should not treat this annoyance not as inflammatory. It usually demonstrates a lack of use case, and sometimes also a lack of prerequisite experience, but not intention to create a flamewar.

12 Likes
36

While true that assumption may be dangerous in practice. It doesn’t take Heisenbugs into account.

I used to work with some web application which worked fine for four years before it crashed. As you can guess it contained a bug in its calendar routine which only manifested itself on leap years. That’s a true story.

1 Like
37

I would still consider these external to “package X”. You don’t have any control over these at build time, and you only have limited options at runtime (wrapping, patchelf+runpath).

38

I would also say that Nix improves the debugging of the first case a lot, and the two other are unsolvable in software.

2 Likes
39

Thanks for your knowledgeable and patient answer @jonringer, just a related tip though: each ZFS dataset has a hidden .zfs directory where snapshots are mounted, which makes it easy to view their content before doing a rollback or a clone.

1 Like
40

And he went on about how upsetting it was.

I think we watched a different video.

I watched past the diamond analogy (nothing inspires confidence in the audience quite like telling them you lack the eloquence needed to describe a diamond, even after prepping for a talk). But I couldn’t get past the expressly “emotional argument”. What happened to using logic to convince people?

Anyway, I’m out of here. It feels weird talking about NixOS if I’m not going to use it. Good luck, everyone.