nix-cabal-simplest
nixpkgs
nix-cabal-simplest | nixpkgs | |
---|---|---|
1 | 1,006 | |
2 | 18,417 | |
- | 2.1% | |
0.0 | 10.0 | |
over 3 years ago | 1 day ago | |
Shell | Nix | |
MIT License | MIT License |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
nix-cabal-simplest
-
What's all the hype with Nix?
Not sure what kind of project you have, but for any starter this will be enough for a long run: https://github.com/avanov/nix-cabal-simplest It works no worse than Stack, probably even better, since Stack doesn't support all Cabal stanzas.
nixpkgs
-
Epic Allows Internet Archive to Distribute Unreal and Unreal Tournament Forever
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
-
Scooter: Interactive Find and Replace for the Terminal
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.
- Release Schedule for NixOS 24.11
-
NixOS Is Not Reproducible
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
-
The abysmal state of GNU/Linux and a case against shared object libraries
> 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.
-
NixOS is a good server OS, except when it isn't
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
- Exercise has 2M users but no money in the bank
-
Why I self host my servers (and what I've recently learned)
> 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
- Interactive NixOS Tests
-
Emacs-like editor written in Common Lisp
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.