nixpkgs VS Emu68

A recent engine recreation : https://github.com/dpjudas/SurrealEngine

Quick start instructions also pull UT from the archive https://github.com/NixOS/nixpkgs/pull/337069

I opened a PR for it: https://github.com/NixOS/nixpkgs/pull/356310

In the meantime you can also add packages that aren't yet in nixpkgs using pkgs.callPackage.

Improving the interaction with language ecosystems was one of the motivating reasons for how I approached the [rework][1] of Darwin support in nixpkgs. A lot of Rust stuff was simply impossible to build due to their SDK needs and how hard it was to override the SDK correctly, but that’s fixed now (with a few remaining cases that will be fixed in the final staging cycle before 24.11). I expect other ecosystems to benefit similarly, especially since Darwin support looks more like a native toolchain while still being built and provided by nixpkgs.

For example, Zed and Wezterm (previously failing intermittently on x86_64-darwin) now build on Darwin. Someone even has [Firefox building from source][2]. PyTorch will be able to support MPS, and MoltenVK will be able to use Metal 3 features if your system supports them.

[1]: https://github.com/NixOS/nixpkgs/pull/346043

> Using shared libraries is optimizing for a very different set of constraints than nixos, which iirc keeps like 90 versions of the same thing around just so everyone can have the one they want.

This isn't really true. One version of nixpkgs (i.e. a specific commit of https://github.com/NixOS/nixpkgs) generally has one version of every package and other packages from the same nixpkgs version depending on it will use the same one as a dependency. Sometimes there are multiple versions (different major versions, different compile time options, etc.) but that is the same with other distros as well.

In that sense, NixOS is very similar to a more traditional distribution, just that NixOS' functional package management better encapsulates the process of making changes to its package repository compared to the ad-hoc nature of a mutable set of binary packages like traditional distros and makes it possible to see and rebuild the dependency graph at every point in time while a more traditional distro doesn't give you e.g. the option to pretend that it's 10 days or months ago.

You only really get multiple versions of the same packages if you start mixing different nixpkgs revisions, which is really only a good idea in edge cases. Old ones are also kept around for rollbacks, but those can be garbage collected.

Maybe I'm missing something, but the only branch in github:nixos/nixpkgs I can see receiving fixes is the 24.05 branch getting fixes backported from unstable. The last commit I can see to the 23.11 branch is about 3 months ago

This would imply only 9 months of security patches before I would need to upgrade the server. That is of course a far less risky process with NixOS, so perhaps that is ok, but it is a lot more work than the 5 years you get (free) with Ubuntu/Debian

https://github.com/NixOS/nixpkgs/branches/active

> manually handling such containers

Well not by hand of course. virtualisation.oci-containers is pretty darn good. Podman+systemd provides some local sandboxing. Network-wide firewall prevents odd traffic from happening.

> No reproducibility etc

Images can be pinned to specific versions providing some reproducibility guarantees. Same goes for configs mounted as volumes.

There is also some software (libedgetpu using bazel as a prime example IME) with a complicated build process. Packaging it is a major PITA and the nixpkgs issue[1] is a graveyard of attempts to do so. I just build it using a container and push the binary version to the node with coral tpu.

[1]: https://github.com/NixOS/nixpkgs/issues/188719

Has anyone used this? I was just thinking the other day that it would be nice to have an emacs-like editor written in such a way that it made performance and parallelism easier, especially around multithreading.

A real killer feature would be some kind of emacs-lisp compatibility layer so that you could load existing third-party emacs modules, but I imagine the complexity of that is so off the charts that it would be unrealistic.

Has anyone successfully packaged it for NixOS? I see this aborted attempt here: https://github.com/NixOS/nixpkgs/issues/250777 (linked from https://github.com/lem-project/lem/issues/890). If not, I guess I might just try patching the binaries rather than trying to build it from scratch, since I don't have any experience building common lisp projects in nix.

As well as the Apollo FPGA emulated one there's an ARM based emulator https://github.com/michalsc/Emu68

AIUI this is the motivation behind Emu68:

https://github.com/michalsc/Emu68

To run 680x0 AROS (and maybe real AmigaOS via PiStorm) on bare-metal on the Raspberry Pi.

See:

https://www.patreon.com/posts/i-owe-you-some-20956961