Having a look at the keep-*s options can lead to easy wins on the small stuff. For instance, keep-derivations is true by default, which is why you are retaining those drv files. Of course, those do contain useful metadata but 22.3M is 22.3M, right?
As others have said building from another machine means you won’t need the build sources on that machine at any time. But you should consider also that you might be able to remove packages from the system closure in that scenario also. Git is 52.7M and might be there just as a means for nix to grab your configuration. Or maybe not, maybe you use it for further purposes. The point being that you are likely to make the biggest gains by attacking the closure size.[1] You might be able to architect things in a way that makes certain packages unnecessary. In fact, just using nix at all has that effect.
Making more use of nix shells means that you don’t really need any significant cli tools permanently installed short of nix given an internet connection. That could mean no vim, no git, no htop, and so on for as much convenience as you are willing to sacrifice, make it all ephemeral.[2] And man-db? Plus the bazillion man pages from n packages? Pshaw! Docs, who needs those!? documentation.enable = false.[3]
I mean, the closure itself is 1.5G which is above your target of 1G. So we’re doing this either way. ↩︎
I suppose you could have a devshell which would install all these, to mitigate the loss of convenience. The real drawback is that you are adding build-time every time you want to use these after a gc. Better to leave them in the closure, especially if you expect to use them more than once a week or something. ↩︎
Since you’re going to mostly (always?) be accessing this remotely, you can probably use the docs on your main machine most of the time anyway. Again, slight inconvenience. ↩︎
This already begs the question, what kind of VM? qemu? cloud-hypervisor as microvm? virtualbox? All those already have slightly different requirements and we would need to micro manage those settings. The best for a minimal kernel for your requirements would be your config.
This probably decreases performance and makes it a lot more intransparent what python code is run which will in turn will make debugging harder.
yep and I closed it with won’t fix as that’s just how golang works, sadly. Binaries are kinda big and most of the dependencies come in from sops upstream and they would need to refactor there file structure to allow omitting optional dependencies. Also if some of the dependencies use templating then go disabled tree shaking as any public function could be called inside there.
It is not that easy. If icu4c wouldn’t be so incompatible with every major version then we only would have one but there are often breakages and we need like 4 versions. I think the best way to help that is to help removing the oldest versions and update dependencies. Or you go through your config with nix-tree and try to remove older versions and update packages and their dependencies.
Adding to the bloat-rant, I’m a new NixOS user and I’ve been toying a lot in the last 2 weeks.
And on the disk usage… I must say I’m quite surprised.
I have 3 machines with the same config, bar a couple of drivers, and the disk usage is widely different.
The machine I’m toying a lot with, which happens a to be a VM where I tried building live CDs, SDs etc… has 80Gb foot print. While the other 2 in the 40Gb.
I understand the 40G come from all the builds etc. But the problem is: I can’t clean seem to clean with gc or nh?
It feels kind of odd to me. There’s no way to actually clean, and worries me about what that means overtime. Granted, it’s easy to reinstall, but that’s not the goal either.
40GB I can see happening if you’re, say, running two different nixpkgs instances in the same generation and install big GUI package closures. Or if you just don’t do garbage collects.
80GB seems well beyond excessive. Open a thread in Help and show your homework, maybe we can help.
The size of the store is not the footprint of the system!
The footprint of the system is its closure size, to be determined by nix path-info -Sh /run/current-system.
Anything beyond that in store use, is caused by something else, and if a GC doesn’t delete stuff, it is still rooted, so you have to identify the GC roots hindering stuff from being deleted.
sudo nix-store --gc --print-roots can help to identify those.
