NixOS on prgmr and Failing to Learn Nix –

N.B. That was too years ago. Not that the manuals are dramatically better since though :D.

While indeed written a while ago, I found the article well-written and bringing up reasonable points.

  • The installer apparently needs more than 1.25 GB of RAM. That seems surprising, I wonder if we could improve that.
  • bitlbee-mastodon has since been packaged in nixpkgs, weeslack hasn’t. It’s unfortunate they ran into problems trying to package things, but hard to learn from without more details.
  • The issue that example from the nix manual doesn’t actually work is still open, might be worth a look.
  • The manual conflates ‘just packaging’ and ‘packaging for contributing to nixpkgs’. I think it might actually be good to focus on the ‘nixpkgs’ scenario, as it’s easy to use a fork of the nixpkgs, and packaging like that provides a nice smooth path into eventually actually contributing your packages.
  • nix-shell documentation: I agree we can do better there (I think things have improved somewhat but could improve more).
  • "nix-shell polluting the working directory and carrying state between build attempts" sounds weird, not sure what was going on there.

The author closes with 2 issues they expected to have, but acknowledges that since they didn’t get seriously into using NixOS this is mostly speculation. It’s still interesting to look at those issues because they say something about first impressions (perhaps even before people try NixOS).

  • nixpkgs derivations generating configuration files: nixpkgs puts a ‘layer’ between the way you configure your system and the actual configuration files - for example, to configure grub you now potentially have to learn both the nixpkgs-level options, the actual grub configuration format, and how those fit together. I was also concerned about this when I first read about NixOS, but in practice it has never been a problem for me.
  • The Nix language being a custom DSL. While it’s true that this causes additional work and things like debugging and tool support are not great, it seems to work out well. Using a general-purpose language would have advantages, but also disadvantages.

Nix is a build system, it builds things, it just happens to be an entire operating system too. Trying to write a ‘manual’ to nixos is like trying to describe every mistake and blunder… and ‘in hind sight this way was not great’… on how unix and associated tooling has evolved in it’s 50 year lifespan. The intrinsic problem with library paths, versioning, dynamic vs static binaries , configuration, ABI compatibility, file system layout… I’m astounded it works as well as it ‘seems’ to.

Every other distro out there follows the same unix paradigm, someone will write a ‘redhat package manager’ then ‘apt get with super cow powers’, and then another one, that apparently fixes those problems with <insert a distro your not using’> .

Packaging tools are one thing, but it’s not better with language build tools either, they all want to do there own thing, in their own way. I’ve forgotton how many ‘defacto’ build systems golang has gone thru.

Developers write code, and as the language might be well defined , how to assemble that software to make it ‘do some kind of job’… … no one can really decide how to ‘build’ software, so we get a mish mash of reimplementations of the same idea’s…but someone how those idea’s are ‘better’ … Nix seems the only thing that’s different , that i can run today. Should applications decide how to package and upgrade themselves, or is that the job of the operating system? Nix goes hardcore on the latter.

I wish i could write a nixos for dummies, but i don’t think it’s possible… because it’s not for dummies… it’s actually for people who care about building things from source and are busy people that can’t wait for gentoo to compile, and probably want to be able to build things not only today, but X years in the future. How you translate that to the ‘does it run on windows brigade’ , only god can help them now.

Nix has it’s work cut out for it to go mainstream…but just look as what people are doing with it…, if you going to ‘rebel’ against the ‘the way it’s always been done’ expect resistance…

Every critique of nix/nixos i’ve seen it basically ‘I don’t know functional programming works’ and 'This is not like <insert any other distro out thier (except guix :wink: ) and i don’t understand it. ’

I guess you have to have seen the 35 years of unix evolution to appreciate the beauty of nix’s design… you gotta be pretty brave to rip up the rule book, reject the status quo , and refuse to ‘do what the others are doing’… to start again with a level of backwards compatibility that actually seems to work.

Lets hope a lot of devops and developers and everyone inbetween can get switched on to nix, this talk at nixcon this year was especially inspiring thanks Aden…

real world problems being solved with something… ‘new’?

We say ‘GNU’s not Unix, Nix is not (like) anything…’

so what does nix mean to me…

## nix


*sentence substitute*

**1.**  another word for [no](

**2.**  be careful! watch out!


**3.**  a rejection or refusal

**4.**  nothing at all


( *tr* ) to veto, deny, reject, or forbid (plans, suggestions, etc)

[C18: from German, colloquial form of  *nichts*  nothing]


Weeslack is packaged under the name wee-slack, it seems.