Arun Isaac <[email protected]> writes: > Hi Phong, > >>> Users would see progress bars like "Resolving deltas:" [...] Nix >>> already solved the client-side problem. The package manager fetches >>> expressions as tarballs via channels, >> >> Authentication of Guix channel tarballs would be nice, of course it's >> not as good as full history authentication, but from an user PoV speed >> could be an important tradeoff. > > Something like this would be very nice. It would be much preferable if > every user didn't have to hit the git repo. > >>> The [nixpkgs] repository totals 83GB with half a million tree objects >>> and 20,000 forks. A local clone is only 2.5GB. The rest is GitHub’s >>> fork network storing every pull request branch and merge commit. >> >> Sounds like a GitHub problem to me /s >> >> But really, this is not a problem inherent to Git. Something like AGit >> could help with garbage collectibility on Codeberg's side, >> and this was not an issue when we were using git:send-email. > > True. Although Codeberg would probably run into the same problems as > GitHub, and possibly sooner considering GitHub must have put a lot of > engineering into their infrastructure. >
Codeberg doesn’t have (yet) the same deduplication that Github has, with our 389 forks and ~500M per repository, that’s almost 200G! >>> Databases have CHECK constraints and UNIQUE constraints; git has >>> nothing, so every package manager builds its own validation layer. >>> Databases have locking; git doesn’t. Databases have indexes for >>> queries like "all packages depending on X"; with git you either >>> traverse every file or build your own index. >> >> This is funny because it precisely describe Guix d-; > > :-) > >> The problem with developing directly on a database though is there's >> no colaborative tooling for it AFAIK. > > Agreed. > >> In brief, aside from guix pull it does not seem to me like there is >> much can be done without going back to the drawing board, but I'm no >> expert on this and wish to be corrected. > > At some point, sooner or later, we might have to go back to the drawing > board, and that process will be painful. But, I am no expert on this > topic either. Hopefully, someone like Ludo could comment. > > Regards, > Arun
signature.asc
Description: PGP signature
