this post was submitted on 07 Sep 2026
276 points (98.9% liked)

Programmer Humor

33777 readers
1536 users here now

Welcome to Programmer Humor!

This is a place where you can post jokes, memes, humor, etc. related to programming!

For sharing awful code theres also Programming Horror.

Rules

founded 3 years ago
MODERATORS
Feyter@programming.dev
anzo@programming.dev
BurningTurtle@programming.dev
pylapp@programming.dev
276
Can't get closed as duplicate if nobody can find the duplicates (lemmy.world)
submitted 1 month ago* (last edited 1 month ago) by qaz@lemmy.world to c/programmer_humor@programming.dev
27 comments fedilink hide all child comments
 

I swear someones just using it as a harder drive at this point

top 27 comments
sorted by: hot top controversial new old
[–] onlinepersona@programming.dev 54 points 1 month ago (2 children)

nixpkgs as a mono repo might've been a mistake, honestly. shithub wasn't made for monorepos. It doesn't have a permissions system for it.

So many PRs get a bunch of inane comments that have nothing to do with the functionality to please somebody's ego, the CODEOWNERS file is nearly worthless as "package maintainers" don't even have the last say on their own packages, docs are nearly the last of the priorities making it difficult for pretty much anybody but the christened cream of the crop to make changes. It almost seems like the entire thing was made for "job security" - only a few people really understand what's going on and thus make the decisions. That of course introduces a bottle-neck.

Even if more people wanted to contribute, they ~~wouldn't be~~ aren't able to. I think the decision makers like it that way.

[–] qaz@lemmy.world 8 points 1 month ago* (last edited 1 month ago)

The entire thing consists of 6 million objects and is 5GiB. I feel like at this point they should just split the common code into a repo and have the packages in submodule buckets grouped by name like some sort of hashmap multirepo (only half kidding).

[–] into_highest_invite@lemmygrad.ml 4 points 1 month ago (1 children)
[–] onlinepersona@programming.dev 3 points 1 month ago (1 children)

I do wonder how nix could solve the nixpkgs problem. In order to build it actually requires the recipes to calculate the hash with which it builds the store path.

Fixed output hashes could be part of the solution. A map of package and version to hash and outPath maybe? But for building from scratch e.g new packages, where would the recipes be stored? I think it would have to be in git, but where would that be stored? A monorepo again? Then we'd be back at nixpkgs.

[–] into_highest_invite@lemmygrad.ml 1 points 1 month ago (1 children)

honestly, having just tested it, i think the solution might be as simple as --depth=1. for me, the clone time of some repos went from several minutes down to instant. even without that, there's no reason in my mind why the filesystem can't be used as a database, just with its own non-git tooling.

i was gonna be shocked that nix doesn't store its own output hashes but then i realized guix doesn't either. it seems really odd to me for a reproducible build package manager not to do that. i wonder what caused that decision.

[–] onlinepersona@programming.dev 2 points 1 month ago (1 children)

Isn't that part of the problem described in the article? A shallow clone? Github has trouble with exactly that.

Maybe it's time the community stepped in an provided alternative solutions to nixpkgs. We can talk about them here, but in the end somebody has to implement them.

[–] into_highest_invite@lemmygrad.ml 2 points 1 month ago* (last edited 1 month ago) (1 children)

no shallow is --shallow. the difference is --depth refers to the history (as reported by, e.g. git log), whereas shallow will only check out the root of the repository and any paths explicitly specified. i guess the article is describing some sort of problem with users who convert their shallow repository to a regular full repo. i wouldn't know a lot about that.

[–] onlinepersona@programming.dev 2 points 1 month ago (1 children)

This is the documentation from git clone --help

--depth=<depth>

Create a shallow clone with a history truncated to the specified number of commits. Implies --single-branch unless --no-single-branch is given to fetch the histories near the tips of all branches. If you want to clone submodules shallowly, also pass --shallow-submodules.

[–] into_highest_invite@lemmygrad.ml 1 points 1 month ago

oh that's my fault. i confused shallow with sparse (--sparse). my bad.

[–] db2@lemmy.world 28 points 1 month ago (1 children)

You underestimate the free time people who live on those forums have. They've probably got every single one memorized.

[–] onlinepersona@programming.dev 5 points 1 month ago

Probably have a list of reasons why they shouldn't be in the community either. "They said master branch is OK: drama time!"

[–] lime@feddit.nu 22 points 1 month ago (2 children)

there are so many strange issues with nix that i'm sort of regretting not going for guix as my user mode package manager.

[–] jdr@lemmy.ml 11 points 1 month ago (2 children)

Guix is amazing and what I use for everything, but apart from basic language issues I'm don't find it any easier than Nix.

[–] programmerlexi@sh.itjust.works 3 points 1 month ago (1 children)

How did you make Guix work for you? Every time I've tried to use it, it was terrible (90 minutes for reconfigure and required internet access, just to remove GNOME).

[–] jdr@lemmy.ml 2 points 1 month ago

Make sure you have working substitute servers for each repo, nonguix is pretty handy, and LLMs can be good at finding config bugs

[–] lime@feddit.nu 2 points 1 month ago (1 children)

the big difference is i haven't heard of any security issues in it.

[–] onlinepersona@programming.dev 6 points 1 month ago

Not enough people use it to be a target.

[–] vividspecter@aussie.zone 8 points 1 month ago (1 children)

Guix is lovely but it has a lot fewer packages and a few of its own quirks too. It's still on my list to test again when I get some time, though.

[–] onlinepersona@programming.dev 1 points 1 month ago (1 children)

Does guix even use git? Are they still on cvs and mailing lists?

[–] hitwright@lemmy.dbzer0.com 7 points 1 month ago (1 children)

Guix always used git. Also after some lenghty discussion, main development moved to codeberg. The "pull request" development model is now available with AGit

[–] onlinepersona@programming.dev 2 points 1 month ago

I'm surprised they moved away from mailing lists. That took a lot of growth.

[–] statelesz@slrpnk.net 17 points 1 month ago (2 children)

Why is it not in here?

[–] onlinepersona@programming.dev 9 points 1 month ago

Too obscure, I imagine

[–] douglasg14b@lemmy.world 5 points 1 month ago

Weird that 996 is on the list, as the point of them using GitHub is to use it as durable forum software, not as a software project issue board like the other items on this list.

[–] somegeek@programming.dev 10 points 1 month ago* (last edited 1 month ago)

Guix gang wya

[–] AusatKeyboardPremi@lemmy.world 7 points 1 month ago

Thank you for introducing me to suckerpinch.

[–] MonkderVierte@lemmy.zip 4 points 1 month ago

There should be enforced categorizing at least.