HackerReposA FIELD GUIDE TO OPEN SOURCE
ProSponsor the shelf♧ 0
← Back to top all-time
divnix
digga
Nix2021–2022
divnix / digga

digga

A flake utility library to craft shell-, home-, and hosts- environments.

5Distinct people
7Mentions
0Explicit recommenders
1KGitHub stars
REPOSITORY AT A GLANCE

What to know before exploring

What it is

A flake utility library to craft shell-, home-, and hosts- environments.

GitHub

Where it is used

No documented product use has been verified yet.

What people are saying

No recommendation phrase was found in the indexed comments.

No classified warning is attached to this page. Read the discussions before treating silence as approval.

Also in these discussions

No other repository is repeatedly linked in the same discussions.

This week on Hacker News

Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 3:56:07 PM UTC.

No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.

Mentions over time

HN mentions by month7 dated mentions

Observed mentions: 2021-02-20 10:07:07 UTC to 2022-02-19 09:45:13 UTC.

01232021-02-01 00:00:00 UTC to 2021-03-01 00:00:00 UTC (exclusive): 1 mentions; 1 submissions, 0 commentsFeb 20212021-03-01 00:00:00 UTC to 2021-04-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2021-04-01 00:00:00 UTC to 2021-05-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2021-05-01 00:00:00 UTC to 2021-06-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2021-06-01 00:00:00 UTC to 2021-07-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2021-07-01 00:00:00 UTC to 2021-08-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2021-08-01 00:00:00 UTC to 2021-09-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 commentsAug 20212021-09-01 00:00:00 UTC to 2021-10-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2021-10-01 00:00:00 UTC to 2021-11-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2021-11-01 00:00:00 UTC to 2021-12-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2021-12-01 00:00:00 UTC to 2022-01-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2022-01-01 00:00:00 UTC to 2022-02-01 00:00:00 UTC (exclusive): 3 mentions; 0 submissions, 3 comments2022-02-01 00:00:00 UTC to 2022-03-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 commentsFeb 2022

Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.

View mention counts and date ranges
UTC ranges include their start and exclude their end. Select a period to filter the source evidence.
PeriodStart (UTC)End (exclusive, UTC)MentionsSubmissionsComments
Feb 20212021-02-01 00:00:00 UTC2021-03-01 00:00:00 UTC110
Mar 20212021-03-01 00:00:00 UTC2021-04-01 00:00:00 UTC000
Apr 20212021-04-01 00:00:00 UTC2021-05-01 00:00:00 UTC000
May 20212021-05-01 00:00:00 UTC2021-06-01 00:00:00 UTC000
Jun 20212021-06-01 00:00:00 UTC2021-07-01 00:00:00 UTC000
Jul 20212021-07-01 00:00:00 UTC2021-08-01 00:00:00 UTC000
Aug 20212021-08-01 00:00:00 UTC2021-09-01 00:00:00 UTC101
Sep 20212021-09-01 00:00:00 UTC2021-10-01 00:00:00 UTC000
Oct 20212021-10-01 00:00:00 UTC2021-11-01 00:00:00 UTC101
Nov 20212021-11-01 00:00:00 UTC2021-12-01 00:00:00 UTC000
Dec 20212021-12-01 00:00:00 UTC2022-01-01 00:00:00 UTC000
Jan 20222022-01-01 00:00:00 UTC2022-02-01 00:00:00 UTC303
Feb 20222022-02-01 00:00:00 UTC2022-03-01 00:00:00 UTC101

What Hacker News says

7 sources
I used Arch for a long time but I always find that I couldn't keep a consistent configuration across multiple machines. The machine I used most often would quickly grow numerous augmentations and changes that I would be missing on my laptop and desktop. There are tools like etckeeper and numerous dotfile managers but most lacked the capability to recognize the machine's state/hardware (e.g. laptop, desktop, server, etc.) or only managed dotfiles but not /etc. Overtime the best configuration tended to be just using the defaults because getting used to a tmux.conf on one machine would just become an annoyance one I was on a machine without it. (Plus now you need to use about 12 different configuration languages :)) A huge advantage Nix has over any other configuration tool is that is a single source of truth. A normal dotfiles repo doesn't
Read the rest
know anything about the actual programs or OS so it's very easy for it to become incompatible with a machine's actual state. On Nix, tools like home-manager [1] especially when used in a flake-template like devos [2] just solves this problem really well. It's very easy to make a change, switch to the new configuration, and then commit the change. Managing bespoke services and scripts is very easy because one file in Nix can create a service with a script's contents, create a user, install necessary packages, etc. I think (desktop) Linux is partly a niche market because the management can be very complex. Nix is certainly very complex itself but its structured enough that it can create very simple systems. There are already several NixOS based OS's that are basically just configuration templates. I could certainly see a more user-friendly distro being released using Nix as the foundation. [1] https://github.com/nix-community/home-manager [2] https://github.com/divnix/devos
In Nix: An idea whose time has come
For the system, I like the devos template: https://github.com/divnix/devos The idea of flakes is how you define inputs, and you define the system (and packages, and shell etc.) in the outputs using the inputs. The inputs are git repos which point to other flakes. You can mix and match these as much as you want (see the devos repo for examples) and when you build the derivation, it generates a lockfile for exact commits in that point in time what were used in the given inputs. You commit the lockfile and in the other systems where you pull your config from the repo, it uses exactly those commits and installs the same versions as you did in your other systems. This was quite annoying and hard to do before flakes. Now it's easy. The problem what people face with building their system as a flake is combining the packages so you can point to `
Read the rest
jq` from the unstable nixos and firefox from the stable train. I think this aspect needs better documentation so it wouldn't be so damn hard to learn (believe me, I know). Luckily there are projects like devos that give a nice template for people to play with (with documentation!) Another use for flakes is to create a development shell for your repo, an example what I did a while ago: https://github.com/pimeys/nix-prisma-example Either have `nix-direnv` installed, enter the directory and say `direnv allow`, or just `nix develop` and it will gather, compile and install the correct versions of packages to your shell. Updating the packages? Call `nix flake update` in the directory, commit the lockfile and everybody else gets the new versions to their shell.
In The Curse of NixOS
There isn't a GUI (although nix-gui [1] is in progress) but there is a very good and decently mature flake template called Devos [2] for accomplishing most of what you ask. It basically lets you write very simple profiles to group configuration settings together and then you can assign those profiles to machines or users. Things could still be improved but I found Devos to be good enough that NixOS is usable for personal and even some production use. Once I get around to it, I'll move/mirror my configs to Github which should serve as good examples. [1] https://github.com/nix-gui/nix-gui [2] https://github.com/divnix/devos
In The Curse of NixOS
https://github.com/divnix/devos is something close to a framework. I agree that language is too simple. Also I think some degree of IDE / language server support would help a lot. Refactoring modules, writing and importing custom functions was a bad experience for me - some arcane stacktraces were common, using repl was too verbose and with no clear way to debug whole configuration.
In The Curse of NixOS
I only briefly looked at Guix. I think there is an arguement that it has a better language. Besides that I'm not sure what one gains compared to NixOS. Overall Guix looked nice but it is very opinionated on the free-software issue which really hurts its adoptability. It is also a niche sibling of an already niche distro so I doubt it would be used in (real) production any time soon. The community & related projects around NixOS are also very compelling. Structured flakes like devos [1] and developer tools like direnv/nix-shell make getting started very easy. I'm not sure if the same can be said about Guix (I'll admit I having been keeping a close eye on it). The darwin (MacOS) compatability is also a huge selling point since a lot of MacOS developers already need tools like Homebrew. [1] https://github.com/divnix/devos
In Why Valve Is Switching from Debian to Arch for Steam Deck's Linux OS

MAKE YOURSELF AT HOME

A few shortcuts

/
Search the collection
?
Open this guide
Esc
Close dialogs and navigation

Your saved repositories and interests stay in this browser.