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?"

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.

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

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

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

- 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

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/

I like it.

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.

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.

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.

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

> 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 '' --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 ` 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...

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