Sander van der Burg

I'm a NixOS user and I know Gobolinux is a few years older, this blogpost (from 2011) was actually useful for me at the time when I decided to pick NixOS for my workstations: https://sandervanderburg.blogspot.com/2011/12/evaluation-and-compariso… Nowadays I'm also playing with Guix as well, I kinda love that everything can be unified in a more decent language (Guile Scheme) than Nix: https://guix.gnu.org/

Here is a recent blog post where somebody tried to install Debian on an Amiga 4000 with an 68040 running at 25 MHz. https://sandervanderburg.blogspot.com/2025/01/running-linux-on-my-amig… I didn't find what Debian version they tried but I think it's implied it's a recent version. They ran into memory issues. They had only 48MB while the recommendations are to use 64MB. It did boot though until it threw errors because of memory constraints. They got a working system by trying Debian 3.1 though.

Probably the definitive document making the case for Nix (and Guix by extension) is Eelco Dolstra's PhD thesis [0] . The introduction is a good read by itself. I have never used Guix/GuixSD but have heard good things about it. Behind the scenes it uses the Nix package manager and offers a subset of Nix packages licensed as free software. Whereas Nix/NixOS uses the Nix expression language, Guix/GuixSD uses a Guile Scheme front-end. I've heard the Guix CLI is quite nice and a bit more polished than Nix's but Nix is currently in the process of overhauling the CLI. See [1] for a more detailed comparison. Both of these projects have very active development but don't have the volume of listings as you would find in e.g. AUR or the Debian repos. That said, I've been pleased and actually surprised at just how many packages exist. If you can't find what you want, contributing new packages isn't too hard (often just a case of finding something similar in the repos and changing the relevant values). You can check the current Nix [2] and Guix [3] packages here to see if enough of your needs are covered before giving one of them a try. [0] http://grosskurth.ca/bib/2006/dolstra-thesis.pdf [1] http://sandervanderburg.blogspot.com/2012/11/on-nix-and-gnu-guix.html [2] https://nixos.org/nixos/packages.html [3] https://www.gnu.org/software/guix/packages/

May be of interest - here's what running Linux and NetBSD on Amiga is like these days: https://sandervanderburg.blogspot.com/2025/02/running-netbsd-on-my-ami… https://sandervanderburg.blogspot.com/2025/01/running-linux-on-my-amig…

DeluxePaint used IFF. Here's a good writeup https://sandervanderburg.blogspot.com/2012/06/iff-file-format-experime…

Much more in-depth article about Nix and Docker, covers how they overlap, contrast and complement one another: https://sandervanderburg.blogspot.com/2020/07/on-using-nix-and-docker-…

This blogpost has a comparison of Gobolinux and Nix: http://sandervanderburg.blogspot.com.br/2011/12/evaluation-and-compari… Maybe some of the experts here on HN can comment on how accurate and up to date it is?

Interesting, I didn't know about GoboLinux, but it reminded me of Nix. Here's a comparison: http://sandervanderburg.blogspot.nl/2011/12/evaluation-and-comparison-…

The Nix manual is a good start: http://nixos.org/nix/manual/#chap-quick-start Then there are a lot tutorial about setting up a development environment for a particular language. See: go: http://lethalman.blogspot.it/2015/02/developing-in-golang-with-nix-pac… haskell: https://ocharles.org.uk/blog/posts/2014-02-04-how-i-develop-with-nixos… python: http://datakurre.pandala.org/2015/10/nix-for-python-developers.html node.js: http://sandervanderburg.blogspot.it/2014/10/deploying-npm-packages-wit… I recommend reading Luca Bruno's blog for learning Nix internals and more advanced topics.

As far as I know there are channels with nix-expressions (which are the package definitions), which are descriptions of how gather the source-code or binaries from specific URLs. npm2nix for example only uses npm to gather the the packages from the registry, but uses Nix for all the other stuff. [0] [0]: http://sandervanderburg.blogspot.de/2014/10/deploying-npm-packages-wit…

Yes: http://sandervanderburg.blogspot.com/2015/04/an-evaluation-and-compari…

I don't think Canonical has even done its homework before going full-steam on Snappy. They seem to have completely ignored the Nix and Guix projects, which also offer atomic installation and rollback of software, but without many of the flaws that Snappy seems to have like application bundling (duplication of dependencies amongst packages), package namespace issues (identifying packages by name+version+developer, not a cryptographic hash identifying the precise build), duplicating packages in home directories via unprivileged package installation, and more. Pretty much anything Snappy can do, Nix and Guix do better and then some. This blog post from a Nix hacker does a good comparison to show the issues: http://sandervanderburg.blogspot.com/2015/04/an-evaluation-and-compari…

I looked closely at Nix and there is a lot to like there. The thing that turned me off is that it is just too complex. Going from something like Dockerfiles to Nix is just a huge leap. Example: http://sandervanderburg.blogspot.com/2014/07/managing-private-nix-pack… A lesson from Docker is that we have to make this dead simple. It has to be something you can grok in 15-60m.

Why the extra effort on the GNU Project's part to create Guix? What are the advantages over just adopting Nix? Doesn't this mean that everything the Nix project packages has to be repackaged for Guix, and vice-versa? I found this comparison at http://sandervanderburg.blogspot.com/2012/11/on-nix-and-gnu-guix.html

You just plug Nix into a service manager that you have Nix bring along for you. Many years ago, I did this for a proof-of-concept at work with supervisord[1] and flake.nix. Devenv[2] builds in[3] support for process-compose[4], which GP mentioned. A few years ago, one long-time Nixer even created[5] a framework, nix-processmgmt[6] that abstracts over various service managers including supervisord and s6[7], which can both be used in a self-contained way regardless of the init system on the host. There are a ton of other open-source process supervisors you can use to manage long-lived processes in a portable way, too, notably Foreman[8] and various clones written in languages other than JS, and GNU Shepherd[9]. In the course of writing this post, I discovered one called dinit[10] which looks sort of similar to s6 and the GNU Shepherd in that it supports both pure usermode operation as well as functioning as an OS's init system. Anyway, all of 'em are in Nixpkgs, so you can pick them up and use them without any packaging work, too. Service orchestration and containers are basically orthogonal concerns. Before Docker was born, there were already plenty of portable tools for standalone "process supervision", "service management", whatever you wanna call it. So it is after Docker, as well. If I needed this for one of my dev environments I would take a look at process-compose to decide if it's acceptable to me. If it isn't, then after surveying the contemporary landscape of…