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.
nonguix
-
The Pre-Scheme Restoration project is now underway
There is also the "secret" nonguix channel which packages nonfree things for Guix: https://gitlab.com/nonguix/nonguix
It's a funny problem but because it's antithetical to the original project's spirit you won't hear about it from any official Guix sources and so it's relatively unknown.
-
Nix – A One Pager
Their software freedom policy seems to be similar to Debian. All free by default, allow separate nonfree addon. In the case of Guix you can find that here: https://gitlab.com/nonguix/nonguix .
- Guix on the Framework 13 AMD
-
Write Guix package definitions in a breeze: Introducing Guix Packager
The GUIX community has a non-free package repo, you just add it as a GUIX channel and problem solved:
https://gitlab.com/nonguix/nonguix
- The many issues plaguing Nix
- Nonguix
-
My Void experience, so you don't have to
Yes, being a GNU project Guix has a strict free software only policy. The biggest channel (repo) with proprietary stuff for Guix is called nonguix. It has the vanilla kernel, Nvidia drivers and a number of other proprietary packages including Steam, Chrome and the like. I don't know what the state of ZFS on Guix is though as I don't care for it myself, but I can see why its inclusion would be questioned with regards to licensing.
-
Differences between nixos and guix?
Since Guix is a GNU project, it doesn't support proprietary software (Steam, Discord, Zoom...). Third-party repos are available for it.
- Cannot install firefox in guix
-
I'm not fond of nix syntax, how difficult will it be to switch to guix
There's a git lab repo for non-free/libre software that you can add as a channel when installing. I used the following guide that shows you how to do this.
nixpkgs
- 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.
- Ask HN: What are you working on (August 2024)?
-
Managing NixOS on DigitalOcean with Colmena
So, we will create our own custom image that is supported by the DigitalOcean NixOS module.
What are some alternatives?
guix-nonfree - Unofficial collection of packages that are not going to be accepted in to guix
asdf - Extendable version manager with support for Ruby, Node.js, Elixir, Erlang & more
zfsbootmenu - ZFS Bootloader for root-on-ZFS systems with support for snapshots and native full disk encryption
Home Manager using Nix - Manage a user environment using Nix [maintainer=@rycee]
com.valvesoftware.Steam
git-lfs - Git extension for versioning large files
guix-nonfree
spack - A flexible package manager that supports multiple versions, configurations, platforms, and compilers.
nixos-hardware - A collection of NixOS modules covering hardware quirks.
easyeffects - Limiter, compressor, convolver, equalizer and auto volume and many other plugins for PipeWire applications
flake - My computing life in Nix.
waydroid - Waydroid uses a container-based approach to boot a full Android system on a regular GNU/Linux system like Ubuntu.