jonringer117

Hi Hexa,

Since you were a moderator at the time of my ban, would care to expand as to why I was banned, and what you meant by "purge the Nazis?"

(Thanks for all your work on rust)

There is some work to get nix to work with Windows, this is mostly being done by john ericson.

However, the real issue is that nixpkgs (the repository containing all nix expressions) heavily assume unix paradigms.

There could be a "nix-windows repository" in the medium to far future, but it will likely be very divergent from the current nix+nixpkgs story of today.

There's nothing wrong with the fundamentals of Nix.

But working with nixpkgs is quite difficult for most. Which is why I'm attempting to address those issues in a fork, Ekapkgs.

The repos will eventually expose optional flake entry points, so it will be compatible with flakes and non-flakes.

If you're curious, https://www.reddit.com/r/NixOS/comments/1gatci0/announcing_t....

That there's an established clique? I agree.

Well, the activity around changing the status quo was done in a github issue [1]. Which sat around for many months after proposing the Apache Software Foundation's sponsorship policy of "state of nexus". Which didn't give a basis in which to exclude Anduril from sponsoring again.

Obviously there's the "people were angry last time, they will likely be angry this time". But that's projecting personal/political views into a sponsorship.

What should have been the right course of action? I'm not sure. "Tech is easy, people are hard"

1: https://github.com/NixOS/foundation/issues/110

For those that are curious about an alternative perspective on this matter, I detailed much of my personal views in my reddit suspension post. I don't have much context on the EU NixCon 2023 events, but I've been actively involved with the project for 2019, 2020, 2021, beginning of 2022, and late 2023.

https://www.reddit.com/r/NixOS/comments/1cd5fod/in_case_im_u...

There's a lot of issues right now around communication, moderation, and community.

- One of the release managers (myself) was banned/suspended [1]

- Attempts to assert control on the board's decision-making by proxy group [2]

- Use of social media to target individuals [3]

1: https://www.reddit.com/r/NixOS/comments/1cd5fod/in_case_im_u...

2: https://discourse.nixos.org/t/objection-to-minority-represen...

3: https://github.com/NixOS/foundation/pull/133

Correct, there was an open letter [1].

And to clarify above, there was no "contributors of this company" dynamic to the outrage.

"jobs" are things which come and go, not a lot of people are will to burn their personal image for a [potentially] uncaring company. And I'm certainly not one of them either.

[1] https://nixos-users-against-mic-sponsorship.github.io/

Nice, really interesting usage of nixpkgs :). Almost a command line friendly version of docker build.

I like it.

Compost takes 20 days to 20 months depending on the feed stock. The main issue with compost is that it can be effective in high-intensity operations like market gardens, but it's much less effective on large acre operations (corn, soy, wheat, etc).

Not to mention that compost is really difficult to come by now.

Unless a farmer is making compost on the side, they can't really treat it as a known input.

I would also argue that chronic over-usage of ammonia-based fertilizers and over-tiling has contributed to degradation to much of the world's farming soil. Which has given rise to many adverse effects such nutrient runoff, poor water infiltration, soil erosion, and downstream effects.

For external users, probably the most exciting "feature" is the use of a calamares installer for the gnome and plasma isos.

This likely wouldn't work on practice. Nix is aggressively lazy, so if you just want a single package, you don't have to evaluate the builds of all 60k+ packages, just the package you wanted and its dependencies.

This just might be me as a functional-programming-maximalist, but I do not like imperative languages for configuration management. You implicitly have to hold the execution state of all actions to know what is going on.

Builds break over time[0]. Generally this is from big updates like gcc, glibc, llvm, openssl, etc.

Most software which is maintained upstream and within nixpkgs is fine. But there's a bunch of "cruft" that you accumulate over time.

[0] https://hydra.nixos.org/jobset/nixpkgs/trunk

P.S. The link above builds for x86_64-linux, aarch64-linux, aarch64-darwin, x86_64-darwin, which also contributes to the failure rate.

Oh, nix-env.... The tool which attempted to bridge the worlds of nix and traditional package managers. But has all of the quirks of both.

Copying my comment from reddit[0]:

For clarity, Arch has about 10k packages, AUR has around 60k packages. I believe this post is "just" about the 10k.

I’d like to see someone do this for Ubuntu, Debian, and NixOS and watch them suffer.

Speaking for NixOS:

I have. I would sometimes do a nixpkgs-review[1] of the mass "rebuild" PRs for Nixpkgs[2]. Hard to know how long it took to build as I would just let it "cook" on my build server while I did other things. The other thing is that nix gives unique names to all built packages and utilizes "maximal sharing" thereof, so everything gets memo-ized[3] on future runs.

The scale of the official nixpkgs repository is 4-6x greater than that of Arch (AUR is the user repository). 9.6k Arch packages vs 59.4k Nixpkgs packages according to repology[4]

Lastly, installing packages in nix is different. Everything goes into the nix store, which is relatively "inert". I don't need to worry about "hooks" or stateful logic being executed affecting my system. "But then how do you create services and other meaningful abstractions needed to make an OS? I thought NixOS was a distribution" It is, and it's down through NixOS modules[5] in the form of a configuration.nix. The NixOS modules can compose the verticals in my system to deliver something coherent and amazing.

Server used:

    OS: NixOS 22.05 (Quokka) x86_64
    Kernel: 5.10.91
    CPU: AMD Ryzen Threadripper 3990X (128) @ 2.900GHz
    Memory: 125913MiB / 257687MiB

Impressive trolling.

deepSeq is basically useless because of how almost every datastructure is ciruclar

Circular references will cause "infinite recursion", and these will cause evaluation errors. So valid nix code will not contain circular references. Compositions of derivations create merkel DAGs. There are also fixed points, but deepSeq can still handle those scenarios.

trace is almost useless because you can never know if a statement is a value or a computation.

use of trace creates a thunk. So it will always be a thunk.

Derivations actually put something in your store when you evaluate them.

No. Instantiation will create store derivations, realizations will perform a build, and successful builds create store paths. `nix-instantiate '<nixpkgs>' --eval -A hello.version` Evaluates the expression, but doesn't produce a store derivation.

Except that I don't need to know this for apt or any other package manager.

You're also probably not creating your own .deb's. You would seek other options.

Nix is the only one that forces me to learn endless minutia about every single language.

Eventually you will to learn your problem domain. Just because you do python dev on ubuntu, doesn't eventually you will eventually need to know how python finds modules.

Haha. HAHA. HAHHAHAHAHHA. Oh sorry. That wasn't laughter. That was me trying to hide my tears.

Hmm, I can't see your face. So don't worry about saving it.

show-trace is about as useless of an addition as I can imagine.

Pretty useful for me, but I also use for work, and free time.

Nix totally creates a file on your disk in this case. Yes, it doesn't "build" the package as in, it doesn't compile it or fetch it. But it actually does do something on your machine.

Sure?

The terminology around nix is just disastrously bad.

Because the terms don't align exactly with other existing terms. Haskell has similar issues, where the terminology is foreign for many, but accurate.

And conda works perfectly without this hack.

Well, conda tries to solve different things. It's definitely not a generic package manager. For supporting python use cases, conda does what it does.

Also, using escalated privileges to install packages is the norm for almost all other package managers. user-level installation is definitely the exception.

I get it, nix people love nix and love to make excuses for its horrible failures. But seriously, other package managers do this beautifully. Can't we just sometimes accept reality?

Do what? FHS? How many borked distribution upgrades have occurred because of FHS incoherence.

And that was 20 years ago. The 2.0 CLI is still a mess.

`nix-*` commands makes sense in context of a phd thesis. The `nix <cmd>` 2.0 cli, is definitely more ergonomic. Most package manager cli's until about 5 years ago were also pretty bad. Still remember having to use dpkg on ubuntu to fix some issues.

Oh boy... how I wish this was true!

It is true, that's why I said it.

Haskell is such a mess in Nix that there are two entire incompatible toolchains.

nixpkgs' haskellPackages is reflective of all hackage packages, and works well for consumption. If you're eluding to haskell.nix, that's a bit more complex and magical.

Both of which are incredibly hard to use by the way.

This makes sense that it's hard for you.

And Python packages which are pure are also a disaster!

The python package ecosystem is a hot mess for all distros [0] [1]. The "I can selectively choose small version ranges of dependencies to satisfy my singular use case" doesn't integrate well to distro's trying to present a coherent package set.

[0] https://drewdevault.com/2021/11/16/Python-stop-screwing-dist... [1]: https://blogs.gentoo.org/mgorny/2021/11/07/the-future-of-pyt...

terraform is more about reconciliation of a configuration, and moving a state closer to a desired end state. NixOS is congruent configuration management. There's a 1 to 1 correlation of configuration to reality, with no configuration drift.

And about Home Manager, the reason why I think it's over-hyped is because it provides a declarative approach to something that was... already declarative. Your $XDG_CONFIG directory does not need a leaky Nix abstraction on top of it

I don't really agree, I spent about 30mins to get my home-manager config to support an m1 mac [0]. I don't really want to think how long it would take me to look up all of the homebrew package names, and learn a new package manager. Instead, I just pushed all of the linux-specific items into their own bin, a little more logic, and I was able to get back to a comfortable terminal + git + vim settings.

Also, nix exposes congruent configuration management[1]. The state of my system is an exact reflection of the configuration. With other tools like ansible, vagrant, etc, I would get reconciliation configuration which is close on initial install but configuration drift is an ever-present concern; not to mention that large recipes and playbooks can take a very long time to run. Going the homebrew route would be divergent configuration, it would be very hard for me to get back to a certain configuration. With nix (and by extension home-manager), I can version control the configuration, improve it, roll it back, w/e I want.

Why would I write my i3 config in Nix??

You do get some type checking, although the iteration time would probably be similar. You could also just do `xsession.windowManager.i3.extraConfig = builtins.readFile ./i3.config;` if you really just wanted to wholesale read in your existing profile.

I'd rather just use `nix-env` personally.

nix-env is a double edge sword. You can rollback (somewhat, I believe it's just a stack of all changes), which is an improvement. However, nix only retains the "derivation name" to try and management. But for packages like python38, if you try to upgrade it, it will determine that `python-3.11-a3` is the package which is the most up-to-date. I try to discourage using nix-env.

[0] https://github.com/jonringer/nixpkgs-config/commit/37ddfefa1... [1]: https://blog.flyingcircus.io/2016/05/06/thoughts-on-systems-...

I generally use `nix repl` for this.

I have an example of myself looking at what my configuration.nix renders to while debugging a module I was adding to nixpkgs/NixOS.

https://youtu.be/bkDYmvKINm8?t=1949

`nix.gc.automatic` is implemented as a systemd timer to run `nix-collect-garbage` periodically.

`nix.optimise` is just a nix conf option. Meaning anytime nix creates a store path, it will automatically dedup files by hardlinking them to a `/nix/store/.links/` path. There's no timer involved with `nix.optimise`. You can manually force existing paths to be "optimised" by doing `nix-store --optimise`

Python has pyenv, NodeJS has nvm, Terraform has tfenv, and the list goes on.

Nix makes these all largely irrelevant, in a consistent way. If anything I would say this supports nix's usage.

Then if you're running on a server/VM/cloud, it seems to me that you should be treating your systems as cattle instead of pets. I never update packages on servers, I build a new image/instance, test it, and replace the server.

You can do this is nix as well. You can take a configuration.nix and ship it as a version controlled file, an iso image, pxe boot image, ami, vhd, or other formats.

I wonder if some of the benefits of NixOS were either solutions looking for problems or solutions where better solutions rose to prominence.

I don't think so: https://blog.flyingcircus.io/2016/05/06/thoughts-on-systems-...

I haven't even started talking about containerization, either!

Containers generally take an impure process and create a "snapshot-in-time". Nix allows you to "hydrate" your configuration in a reproducible and repeatable fashion. OCI images can only really be layered, can't be composed, and commands like `sudo apt-get install` or `pip install` also makes the runtime behavior dependent on when the image was created.

Because it's a domain-specific-language, optimized for packaging software.

The relevant passage:

Its only purpose is to describe components and compositions. A component is created through the derivation primitive operation, which accepts all information necessary to build the component. This includes its dependencies, which are other derivations or sources.

Full phd thesis: https://edolstra.github.io/pubs/phd-thesis.pdf

Currently, there's 8.7k stars, 7.2k forks. And 2000+ maintainers have added themselves: https://repology.org/repository/nix_unstable

So, I would say a pretty large portion.

Also, the contribution model for nixpkgs is just opening a PR, so it's a fairly low (non-technical) barrier-to-entry for most contributors.

- You can't print anything because the language is lazy. Forcing any values to print them can and will result in random operations happening on your store. You can never know which values are safe to inspect. This kills debugging.

`lib.deepSeq` can be used to fully evaluate a thunk. `lib.trace` can be used to emit a log each time a value gets evaluated.

- Everything in Nix is recursive, datastructures contain copies of themselves as hacks to avoid building proper APIs. So again, you can't print anything, even if you're sure that printing the object won't do something crazy to your store.

derivations are just a dictionary of information, passed to a `derivation` function; which communicates to nix that it should be built/realised. There is a minimal API for a derivation, which is just `name` and `builder` in attr set. In general, the builder will refer to script which may have additional levers. For example, `stdenv.mkDerivation` also expects a src.

- There are almost no APIs and no uniformity in Nix. Packages are given total freedom to do anything. The Python ecosystem works totally differently from the Haskell one which works totally differently from the C++ one. It's insane. They use different datastructures, functions, etc. To do the same thing.

"Just because two things are similar, doesn't mean they're the same". I wouldn't expect building openssl to look similar to building ripgrep, a python package, or a node package. Each domain has it's own oddities. Python for example expects packages to be installed at `${prefix}/lib/python-${python.majorVersion}.${python.minorVersion}/site-package`

- The Nix language has impossible error messages. You will get stuck. You can't view values and you can't get error messages. There's no moving forward from that unless you ask someone.

This has significantly improved with nix 2.4+. `--show-trace` will now show you an entire stack trace with files and line numbers.

- Laziness in Nix is different from laziness in Haskell. In Haskell, it's mostly about performance improvements and some cool tricks here and there. In Nix, laziness fundamentally means something: you build up packages and you force them to install them.

For haskell, I think it was originally a side-effect of how they implemented the language. For nixpkgs, this is still important because nixpkgs is just a large dictionary (attr set). However, doing something like `nix-shell -p cargo`, will avoid having to evaluate all of nixpkgs, just what I need for cargo.

Also, nix doesn't build a package when it evaluates it. Building is done as part of realization (which many commands do implicitly).

https://book.divnix.com/ch04-02-realise-a-derivation.html

- You cannot install Nix in your home account without root permissions (yes, there are hacks, but they break terribly). So Nix is actually less isolated and less portable than something like Anaconda!

This is because `/nix` needs to exist, and can't be a symlink. sudo only needs to be done once. user installs can be performed after that.

- The commandline experience is terrible. Nothing makes any sense. Not the names of the tools. Not their arguments. Why sometimes something is a binary and other times it's a mode of another tool, etc.

The `nix-*` commands are a carry-over from the phd days of nix. Where they are reflect closely to the underlying nix machinery. The nix 2.0 `nix <cmd>` cli tries to better reflect "user scenarios", but still kind of a WIP. So I agree, cli is probably one of the weakest aspects of nix right now.

- In exchange for making some hard things easy, Nix makes a lot of easy things very hard. Sure, it will manage an isolated environment. But, now you want a package from pip that isn't in Nix? There is literally no way for you to figure out how to do this, you need to find a tutorial online, hope it's up to date enough to work, and follow it step by step. And.. there's a good chance you misunderstood what the tutorial was doing and won't have the correct environment at the end.

Depends on the toolchain. Rust and Go builds are almost trivial to support now. Python and other ecosystems which rely on a lot of impure behavior will have the most impedance mismatch with nix.

Mixing a nix python packages with venv is described here: https://nixos.org/manual/nixpkgs/stable/#how-to-consume-pyth...

It's not a hashmap, or a map, or an object. No. It's an attrset. Riiiiight.

This was intentional. Most hashing algorithms don't guarantee a stable ordering of keys. Nix was inspired by a research project called Aterm, which did have this property. Also, you can do things like reference other keys in an attr set, which many other dictionary data structures don't support.

It's not a build script, it's a derivation.

Derivation encapsulates everything which goes into a building something. Dependencies, env vars, flags, sources, patches, the build script, package version, and package name all get packed into a derivation. These paramaters get hashed which is how the hash for the store path gets determined.

Derivations can be thought of an unambiguous build "recipe", which has already resolved based upon all configurable inputs (dependencies, build platform, host platform, target platform) .

https://book.divnix.com/ch04-01-create-a-derivation.html#ins...

Nix is optimized for creating reproducible builds.

All builtins functions can how render doc with `:doc` in the `nix repl`. I think there's work to make this possible with any arbitrary function.

Glad someone found them useful :)

NixOS is BestOS :)

Release channels.

If you follow one for nixpkgs, it means that the infrastructure has at least attempted all possible builds. If you're starting to build something, it's likely broken. However, that's usually not the case. https://hydra.nixos.org/jobset/nixos/release-21.05

Outside of configuring your system, almost everything from NixOS is applicable to other distro's. The only notable exception I can think of are video drivers, and you will need nixGL for that.

Otherwise, I would recommend looking at home-manager, it's essentially NixOS but for any linux distro, or even darwin with nix-darwin. https://github.com/nix-community/home-manager