nixpkgs VS spack

Noticed it wasn't on Nixpkgs, so... https://github.com/NixOS/nixpkgs/pull/399843

https://github.com/nixos-bsd/nixbsd This is a very cool project that I hope will get upstreamed into NixOS proper, eventually.

I always thought InitWare would be good for that. See https://github.com/NixOS/nixpkgs/issues/26850 --- we've been discussing this before NixBSD existed, even!

If you are currently involved in managing packages for a Linux distribution, then you might want to use the instructions outlined in the GitHub repo to help you build packages for your distributions. My colleague James Ward has recently done this for NixOS (you can see his PR here)

You can do this with vanilla Firefox using policies.json[1]. Check out `DisableAppUpdate` attribute.

If you're using Firefox from nixpkgs this is already disabled by default[2].

[1]: https://support.mozilla.org/en-US/kb/customizing-firefox-usi...

[2]: https://github.com/NixOS/nixpkgs/blob/nixos-24.11/pkgs/appli...

Ah, this is awesome! I currently run k3s on a decently spec-ed NixOS rig. I tried getting k3s to recognize my Nvidia GPU but was unsuccessful. I even used the small guide for getting GPU in k3s to work in nixpkgs[0], but without success.

For now I’m just using Docker’s Nvidia container runtime for containers that need GPU acceleration.

Will likely spend more time digging into your findings — hoping it results in me finding a solution to my setup!

[0] https://github.com/NixOS/nixpkgs/blob/master/pkgs/applicatio...

- Method 1: doesn't really improve layer caching, but it provides a familiar way (via Dockerfile) to use Nix packages. As with any Dockerfile, the creator is in charge of creating layers and making sure those layers are as small (cleaning cache, ...).

- Method 2: Nix language is used to describe (in a declarative way) what the end image should look like. Layers are then calculated based on the dependency tree (or as Nix calls it, dependency closure). The algorithm that creates layers[1] makes sure that there is higher likelihood of cache hits without the user needing to worry about layers, but you can even roll-up your own algorithm that fits your project better.

- Method 3: Using Flox you would get sort of both. An easy way to configure the final docker image via toml configuration and using Method 2 under the hood.

There are other ways how to improve caching efficiency, but those are very use case specific (eg. big "builder" images) and would probably require a completely separate blog post.

[1] https://github.com/NixOS/nixpkgs/blob/63f0da03a3b2c323ea924b...

I spent a while messing around with https://github.com/ansiwave/nimwave, which I enjoyed but I haven't gotten very far. Though I've been avoiding the front end for so long, I don't know what reasonable feels like in that space anyway.

My Nim journey was stalled by this bug in its nix toolchain: https://github.com/NixOS/nixpkgs/issues/308593. I guess that's the price we pay for straying from the beaten path.

The build will actually fail if Gixy finds any issues.

[1]: https://github.com/NixOS/nixpkgs/blob/nixos-24.11/nixos/modu...

You could use a package manager that packages C, C++, Fortran and Python packages such as Spack: here's the py-shapely recipe [1] and here is geos [2]. Probably nix does similar.

[1]: https://github.com/spack/spack/blob/develop/var/spack/repos/...

Just out of curiosity, have you checked out Spack, https://github.com/spack/spack, which has a lot of HPC users. Support for mixing and matching both system and from source dependencies has been extremely useful in my work.

> Are we talking about the same autotools?

Yes. Instead of figuring out how to do something particular with every single software package, I can do a --with-foo or --without-bar or --prefix=/opt/baz-1.2.3, and be fairly confident that it will work the way I want.

Certainly with package managers or (FreeBSD) Ports a lot is taken care of behind the scenes, but the above would also help the package/port maintainers as well. Lately I've been using Spack for special-needs compiles, but maintainer ease also helps there, but there are still cases one a 'fully manual' compile is still done.

> Suffice it to say, I prefer to work with handwritten makefiles.

Having everyone 'roll their own' system would probably be worse, because any "mysteriously failure" then has to be debugged specially for each project.

Have you tried Spack?

* https://spack.io

* https://spack.readthedocs.io/en/latest/

Well, good luck with that, cause it's broken.

Previous release miscompiled Python [1]

Current release miscompiles bison [2]

[1] https://github.com/spack/spack/issues/38724

[2] https://github.com/spack/spack/issues/37172#issuecomment-181...

gh is available via Homebrew, MacPorts, Conda, Spack, Webi, and as a…

> I can't count the number of times I've seen people say "md5 is fine for use case xyz" where in some counterintuitive way it wasn't fine.

I can count many more times that people told me that md5 was "broken" for file verification when, in fact, it never has been.

My main gripe with the article is that it portrays the entire legal profession as "backwards" and "deeply negligent" when they're not actually doing anything unsafe -- or even likely to be unsafe. And "tech" knows better. Much of tech, it would seem, has no idea about the use cases and why one might be safe or not. They just know something's "broken" -- so, clearly, we should update.

> Just use a safe one, even if you think you "don't need it".

Here's me switching 5,700 or so hashes from md5 to sha256 in 2019: https://github.com/spack/spack/pull/13185

Did I need it? No. Am I "compliant"? Yes.

Really, though, the main tangible benefit was that it saved me having to respond to questions and uninformed criticism from people unnecessarily worried about md5 checksums.

[1] https://github.com/spack/spack/blob/develop/var/spack/repos/...