4 ms·
“It never works out” - hmm, seems like it worked out just fine, worked great to get the operation of the ground and when scale became an issue it was solvable b
by jama211 10mo ago
“It never works out” - hmm, seems like it worked out just fine, worked great to get the operation of the ground and when scale became an issue it was solvable by moving to something else. It served its purpose, sounds like it worked out to me.
- swiftcoder 10mo agoYou appear to have glossed over the two projects in the list that are stuck due to architectural decisions, and don't have any route to migrate off of git-as-database?
- hombre_fatal 10mo agoBe more specific because I just see a list of workarounds deployed once they had the scale to warrant them, supporting the OP’s claim.
- swiftcoder 10mo agoRead the vcpkg section, it explicitly states that they have no horizontal on a solution. The nix section also doesn’t explain any potential solution.
- deleted 10mo ago[deleted]
- baobun 10mo agoThe issues with nixpkgs stem from that it is a monorepo for all packages and doubling as an index. The issues are only fundamental with that architecture. Using a separate repo for each package, like the Arch User Repos, does not have the same problems. Nixpkgs certainly could be architected like that and submodules would be a graceful migration path. I'm not aware of discussion of this but guess that what's preventing it might be that github.com tooling makes it very painful to manage thousands of repos for a single project. So I think it can be a lesson not to that using git as a database is bad but that using github.com as a database is. PRs as database transactions is clunky and GitHub Actions isn't really ACID.
- yawaramin 10mo agoIt's not a monorepo though? It's a package index, it has the package metadata. It doesn't have the actual source code of the projects themselves.
- baobun 10mo agoPoint being it carries both the index (versions/pointers) and full metadata + build instructions for all packages in single repo. The index could be split from the build and the package build defs could live in independent repos (like go or aur). It would probably take some change to nix itself to make that work and some nontrivial work on tooling to make the devex decent. But I don't think the friction with nixpkgs should be seen as damning for backing a package registry with git in general.
- jama211 10mo agoIt’s a fair criticism, and this article does serve well as a warning for people to try and avoid this issue from the start.
- lijok 10mo agoNooo you don’t get it - it didn’t scale from 0 to a trillion users so it’s a garbage worthless system that “doesn’t scale”.
- zephen 10mo ago^^^ Poe's Law may or may not apply to the above comment.
- efitz 10mo agoWhen you start out with a store like git, with file system semantics and a client that has to be smart to handle all the compare and merge operations, then it’s practically impossible to migrate a large client base to a new protocol. Takes years lots of user complaints to and random breakage. Much better to start with an API. Then you can have the server abstract the store and the operations - use git or whatever - but you can change the store later without disrupting your clients.
- jama211 10mo agoThat costs hosting money no? That might be a bigger problem for someone starting than scalability
- leoh 10mo agoI couldn't agree more strongly. There is a huge opportunity to make git more effective for this kind of use-case, not to abandon it. The essay in question provides no compelling alternative; it therefore reaches an entirely half-baked conclusion.
- jama211 10mo agoA good point!