10 ms·

CocoaPods downloads max out five GitHub server CPUs

826 points by jergason 11y ago

superuser2 11y ago
Just last night, all my pod installs were timing out after ~30ish minutes. That explains it.
- jessaustin 11y ago
  Should we infer from your behavior that such a timeframe is fairly normal for cocopod? If I ran an "npm i" (or "pip install", etc.) that didn't respond for a minute, I would suspect a problem and kill it. How can any development process that takes longer than that be practical?
  - superuser2 11y ago
    Indeed, I was killing and restarting the process for a while, trying to get it to be more verbose, etc. Eventually I decided to try letting it run, and that didn't work either. I don't know what's normal; last night was one of my first iOS projects.
  - draw_down 11y ago
    Seriously. I regularly `npm i`, run tests, switch branches, blow away node_modules, then `npm i` again. It's really important for it to be quick. Then again, there is caching to help.
- joeblau 11y ago
  I installed from scratch last night on a server and it took ~5 mins.
onli 11y ago
Note how perfect that response from mhagger is. A clear, honest sounding assurance of what Github wants to deliver. A perfectly comprehensible description of what is the problem, and where it is coming from. And then suggestion how to fix it the project actually can work on, plus mentioning changes to git itself that Github is trying to make that would help. It not only shows great work going on behind the scenes (and if that is untrue, it at least gives me that impression, which is what counts), but also explains it in a great way.
- dankohn1 11y ago
  Yes, it's a hugely positive advertisement for the essential role that Github plays in the open source community. Also impressive is the followup message from a Github API developer (and Homebrew maintainer) offering access to a beta API that Homebrew is working with to reduce load. https://github.com/CocoaPods/CocoaPods/issues/4989#issuecomment-193801376 https://github.com/CocoaPods/CocoaPods/issues/4989#issuecomm...
  - arrakeen 11y ago
    taking a look at homebrew's implementation of this new API feature, i fail to see how it would dramatically reduce fetches for their (homebrew's) use case. from what i understand, it will only be called when the user manually invokes `brew update`. how often are users calling this command over and over? that being said, i do believe it could help cocoapod's use case since the fetches are done automatically (as i understand it)
    - ropiku 11y ago
      It's also being used in scripts. In our Mac CI environment (for iOS builds) we update homebrew to have the latest xctool.
    - barkingcat 11y ago
      brew update is being called over and over again in most use cases - if only to check for example, if the latest openssl release patching a critical exploit is out yet. (of course on the mac openssl is packaged with the system, but if you are using the brew version, or are compiling other software against openssl from brew, you'll need to check for updates diligently) It is also being used in scripts, etc. Since from the user's point of view it's a no-op if there are no updates, there is no reason not to do it on a schedule.
    - mikemcquaid 11y ago
      Hello! I'm the Homebrew maintainer and GitHub employee who wrote this. The main thing this API does for Homebrew is make no-ops really fast for `brew update`. As you point out this results in no speedup (in fact a tiny slowdown) for the case where you only run it where you know you have changes. Where it becomes useful is if you are using multiple taps (Homebrew's 3rd-party repositories) which update infrequently or if you want to run `brew update` automatically in e.g. a project bootstrap script that's run frequently. In the medium to long-term I'd like to consider Homebrew running `brew update` automatically before you `brew install` (https://github.com/Homebrew/homebrew/issues/38818 https://github.com/Homebrew/homebrew/issues/38818). For us to ever be able to do that `brew update`'s no-op case needs to be extremely fast.
jdcarter 11y ago
Wow, really impressive response from GitHub. The right amount of technical detail coupled with balanced tone--halfway between "we support you" and "you make us crazy." One correction to the post title: it's not maxing five nodes, but five CPUs.
- justinclift 11y ago
  Yeah, 5 cpu's is an order of magnitude difference. ;)
  - joshribakoff 11y ago
    Wait, so the CPU isn't the big white tower sitting under my desk?!
    - minsight 11y ago
      According to my mother, that's "The hard drive".
- dang 11y ago
  Ok, we replaced "nodes" with "server CPUs" in the title.
zoul 11y ago
Another reason I consider https://github.com/Carthage/Carthage https://github.com/Carthage/Carthage a better solution of the dependency management problem.
- cballard 11y ago
  And https://github.com/apple/swift-package-manager https://github.com/apple/swift-package-manager once it's ready, which is similar to Carthage in structure (decentralized!).
  - kylef 11y ago
    Swift Package Manager will also have a centralised package index in the future, here's a quote from their [package manager proposal][1]: > We would like to provide a package index in the future, and are investigating possible solutions. [1]: https://github.com/apple/swift-package-manager/blob/master/Documentation/PackageManagerCommunityProposal.md https://github.com/apple/swift-package-manager/blob/master/D...
- joeblau 11y ago
  I really like Carthage's architecture, but there are two things I don't like about it. 1. You can't edit the frameworks unless you open a separate project, re-edit and recompile. With Pods, you can edit the Pod in your workspace. 2. Carthage doesn't go the last mile to bundle the framework into your project. If they addressed those two things, I feel like Cocoapods would probably start losing a lot of steam. Although, after watching some videos about what the goals of Carthage were from the creators, I doubt that those two things will be addressed so I'm waiting for Swift's Package Manager.
  - zoul 11y ago
    I consider both points a feature. I think the Xcode project of the dependency should be a black box, I just want to get the resulting framework to add to my workspace.
- arr2bee2 11y ago
sdegutis 11y ago
I love how this was like the perfect storm of things that could go wrong, and how it seems like mhagger is just amazed more than anything else.
- revelation 11y ago
  Hardly. Do they hit edge cases? Yes! Is using GitHub for your CDN a dick move and going to cause problems, regardless? Yes! The response from mhagger is unnecessarily apologetic, and I predict we'll see an official update from GitHub on this soon.
  - zeveb 11y ago
    > Is using GitHub for your CDN a dick move and going to cause problems, regardless? Yes! I don't know about that. Both oh-my-zsh[1] and emacs prelude[2] use git repos as their code distribution mechanisms, and that works really well. I think the real issues here are exactly what is called out in the issue: poor usage of git, and poor directory layout. [1] https://github.com/robbyrussell/oh-my-zsh https://github.com/robbyrussell/oh-my-zsh [2] https://github.com/bbatsov/prelude https://github.com/bbatsov/prelude
    - pjc50 11y ago
      Are either of those anywhere near as popular?
    - revelation 11y ago
      They are using GitHub for their intended purpose, hosting their code. That is perfectly fine. What is not perfectly fine is using GitHub as your package host, CocoaPods/Specs is the equivalent of Debians APT using one big GitHub repo to host all their packages. It has 92567 commits and 6872 contributors.
      - masklinn 11y ago
        OTOH Homebrew also uses github as its package host and has a respectable 62000 commits and 5600 contributors and github seems to be just fine with it. The big differences seems to be in the way they do their thing: I'm reasonably sure homebrew just git clones then updates the local repository normally[0], it has "only" 2500 files in Library/Formula, and because of its different subject it is way less write-active, CocoaPod has 1k commits/week which look to be increasing pretty much constantly, homebrew is around 350 with ups and downs. Also not sure it matters, but homebrew has lots of commits updating existing formula, cocoapod changes are almost solely addition (publishing a new version of a package adds a new spec and doesn't touch the old one) [0] which is exactly the bread and butter of github
zymhan 11y ago
I've always found Github's business model interesting. What if a massive open-source organization (e.g. Fedora, Apache) decided to use it for all of their development, integrating it with continuous builds and all the associated pulls. Of course this isn't likely to happen for a number of reasons, but there are large open source projects that could put a significant load on their infrastructure if they chose to use Github as their main code versioning system.
- Anderkent 11y ago
  Presumably they'd get load-limited to the same degree and eventually be forced to move to something they control.
- athenot 11y ago
  It's the same business model that Jira used in the past, when the alternatives were Mantis, Trac and Bugzilla. They had[1] one of the better and well designed issue trackers, free for OSS projects. That turned into a great way to champion adoption within paying customers' organizations. [1] In my opinion, they have since lost that edge on the UI.
  - stevoski 11y ago
    I remember seeing this new much improved UI for bug tracking on OSS, and thinking, "Thank goodness they're no longer using Bugzilla". And then using it a bit, and thinking, "I've got to get that bug tracker into the org I'm working for." Yep, it was Jira. It was a great strategy they used!
- consp 11y ago
  I think they should do 'ok' though it won't make you wealthy: - They collect money from businesses (who pay quite well) - They collect money from private repos (like I have for lots of my config files, no, no passwords/keys in there ;) for e.g. tex files. - The large companies probably pay some form of 'support'
- discreditable 11y ago
  > What if a massive open-source organization (e.g. Fedora, Apache) decided to use it This one is pretty big. https://github.com/torvalds/linux https://github.com/torvalds/linux
Gratsby 11y ago
From CocoaPods.org: > CocoaPods is a dependency manager for Swift and Objective-C Cocoa projects. It has over ten thousand libraries and can help you scale your projects elegantly. The developer response: > [As CocoaPods developers] Scaling and operating this repo is actually quite simple for us as CocoaPods developers whom do not want to take on the burden of having to maintain a cloud service around the clock (users in all time zones) or, frankly, at all. Trying to have a few devs do this, possibly in their spare-time, is a sure way to burn them out. And then there’s also the funding aspect to such a service. -- So they want to be the go-to scaling solution, but they don't want to have to spend any time thinking about how to scale anything. It should just happen. Other people have free scalable services, they should just hand over their resources. Thank goodness Github thought about these kinds of cases from the beginning and instituted automatic rate limiting. Having an entire end user base use git to sync up a 16K+ directory tree is not a good idea in the first place. The developers should have long since been thinking about a more efficient solution.
- geofft 11y ago
  I think the word "scale" is used to mean different things in the two sentences you quoted. In the first case, "scale" is about package management and dependency tracking, helping an individual software project approach large scale (many third-party dependencies with possibly conflicting requirements, new developers who need to get up-to-speed quickly, etc.). In the second case, "scaling" is about distribution of the CocoaPods metadata to large numbers of users, each with their own (possibly small) software project. Sentence 1 would still be true if CocoaPods was only used by ten companies developing the ten biggest (in terms of lines of code) Objective-C projects, but there would no longer be a need to scale in the sense of sentence 2.
- Kapura 11y ago
  It seems like a classic example of ignoring the negative externalities. Luckily, we live in a connected world where it is sometimes easy to trace the after-effects. I understand the desire to personally maintain as few of one's own servers as possible, but when the result is negative effects on the service hosting the project and a worse experience for the end-user, it might be time to start looking over what google cloud offers.
pjc50 11y ago
This reply: https://github.com/CocoaPods/CocoaPods/issues/4989#issuecomment-193810378 https://github.com/CocoaPods/CocoaPods/issues/4989#issuecomm... "Not having to develop a system that somehow syncs required data at all means we get to spend more time on the work that matters more to us, in this case. (i.e. funding of dev hours)" In other words, using github as a free unlimited CDN lets them be as inefficient as they like. Such as having 16k entries in a directory ( https://github.com/CocoaPods/Specs/tree/master/Specs https://github.com/CocoaPods/Specs/tree/master/Specs ) which every user downloads. Package management and sync seems to suffer really badly from NIH. Dpkg is over 20 years old and yum is over a decade old. What's up with this particular wheel that people keep reinventing it seemingly without improvement?
- superuser2 11y ago
  Perhaps because Cocoapods is not an OS package manager or anything close to it. It installs libraries within the context of an XCode project, regardless of the host system or what is installed for other projects.
  - pjc50 11y ago
    It is a package manager, though? The fundamental idea of downloading a list of available options of which the user picks some, and the system pulls in dependencies, is almost exactly how dpkg and yum work. The location to which the packages are installed is a detail.
    - pretz 11y ago
      CocoaPods is much more akin to RubyGems or PyPI or CPAN, all of which are established as useful tools outside of OS level package managers. There's a need for a iOS/Cocoa package manager (that understands Xcode!) and CocoaPods has so far been the most successful.
    - masklinn 11y ago
      A language package manager must be able to "install" the same packages over and over again (and possibly "install" multiple versions of the same package in the same environment), and the ability to push packages is generally considered part of their duty, not so for OS package managers, you don't use dpkg to send a package to debian's repositories. > The fundamental idea of downloading a list of available options of which the user picks some, and the system pulls in dependencies, is almost exactly how dpkg and yum work. If you reduce it to the fundamentals you don't need yum or dpkg either to do that, just a dependency solver and curl.
pavlov 11y ago
I've never really understood CocoaPods. Dragging a framework into Xcode was never much trouble, and the amount of 3rd party libraries in a OS X / iOS project ought to be fairly small, so the gains are trivial. The potential downsides seem much more annoying. Do you really want to have your dependencies on an overloaded central server somewhere?
- Moto7451 11y ago
  Until recently iOS only supported statically linked libraries which could lead to issues if you needed to use multiple components that had a shared dependency that you needed to upgrade for one reason or another. You couldn't touch the embedded version. Additionally there was no native package manager which made sharing libraries a clumsy affair. Cocoapods makes both cases easier.
  - seanalltogether 11y ago
    This is correct. Starting with iOS 8 they finally allowed linking against custom frameworks which is why Carthage is now becoming much more popular. CocoaPods solved a critical problem of getting dependencies linked in, while creating a new problem of having your xcodeproj file and build settings be managed by them. I'll be happy enough to drop them for new projects going forward.
    - jallmann 11y ago
      > Starting with iOS 8 they finally allowed linking against custom frameworks I don't keep up with iOS development enough to know if anything has changed with respect to static/dynamic linking in iOS 8, but it has always been possible to use custom frameworks in iOS (eg, frameworks you build yourself, unless the community has another definition for 'custom framework'). The framework directory structure is a bit unorthodox, but it's really just your statically built library (absent any '.a' suffix) alongside any header files in a Headers folder. Again, not sure if this has changed with any support for dynamic linking.
      - 11y ago
deleted 11y ago
[deleted]
jrochkind1 11y ago
What an unusually reasonable discussion. good on everyone.
iBotPeaches 11y ago
This bug report is a great step in the direction for GitHub. As of this comment there are 3 different GitHub staff members responding and providing feedback to the CocoaPods team. From the previous "Dear GitHub" messages and responses, this seems like perfect community involvement.
wpeterson 11y ago
It's totally reasonable to host your code on github and to build a package manager that loads the content of a package from it's github repo. What seems insane is to use a single github repo as the universal directory of packages and their versions driving your package manager. There's a reason rubygems has their own servers and web services to support this use case for the central library registry, even if the source for gems are all individually projects hosted on github.
- lucaspiller 11y ago
  I assume they modelled it after Homebrew, which has been working fine doing exactly that for the last 7 years. That only has 3,000 packages vs 15,000 for CocoaPods or 115,000 for RubyGems.
  - philippnagel 11y ago
    In case somebody is interested in such figures (I certainly am) - NPM has 249,838 as of today [0]. [0]: https://www.npmjs.com https://www.npmjs.com
- caf 11y ago
  I wonder whether you could use a DHT for the package directory.
Negative1 11y ago
When he says approaches similar to 'other packaging systems', which ones is he referring to? I can see why this is a bad approach but am unfamiliar with what would be considered a better practice (outside of just hosting a .tar on CloudFront).
- wpeterson 11y ago
  RubyGems.org has their own web server and web services for publishing library versions and to allow the clients to fetch libraries and query the universal registry.
  - s_kilk 11y ago
    Same goes for almost any language-specific package manager you could name: Rust/Cargo, Clojure/Clojars, Node/npm, Elixir/hex, Python/PyPi. No matter which way you slice it, what CocoaPods is doing is a bit daft, especially at their scale.
    - kuschku 11y ago
      Or even the Java community, where you have MavenCentral, JCenter, etc.
    - steveklabnik 11y ago
      Small note: Cargo _does_ use an index (not the source code), in git, on GitHub. However, we're already doing the directory layout that they recommend in-thread, so we shouldn't have this specific problem.
- JonnieCache 11y ago
  Probably homebrew, which is also heavily based on github, although not to the same extent as CocoaPods apparently is. It's mentioned further downthread. The main difference is that homebrew actually updates the git tree to provide updated versions of package specs. CocoaPods adds a new directory and some files for each package version, causing the repo to balloon.
sly010 11y ago
I would be interested to know what are the other top GitHub repositories. Afaik the Nix package manager uses a similar model (using a GitHub repo as a database), however they periodically release snapshots and the default configuration uses those instead of git.
- vbezhenar 11y ago
  I'm not sure how DefinitelyTyped works, but their repository https://github.com/DefinitelyTyped/DefinitelyTyped https://github.com/DefinitelyTyped/DefinitelyTyped is huge and may be they use that github repository as a single distribution point.
  - WorldMaker 11y ago
    People interact with DefinitelyTyped in a set of ways, from currently most common to least common: 1. NuGet packages, which are built from the GitHub repository but then redistributed over a non-Github CDN (NuGet's) 2. tsd management tool (https://github.com/Definitelytyped/tsd https://github.com/Definitelytyped/tsd), which looks like it prefers Github's CDN raw URLs rather than full/shallow git clones 3. typings management tool (https://github.com/typings/typings https://github.com/typings/typings) with "ambient" typings searches (`--ambient` flag), which I believe also prefers Github's CDN raw URLs, as it essentially forked from TSD That said, it's past time to move beyond the giant huge DefinitelyTyped repo, and I for one heartily recommend people migrate to typings which has better support for NPM and other module and package management systems, as well as smaller unit/module-focused Github repositories.
SuperKlaus 11y ago
In fact, they are maxing out five CPUs - not five nodes, big difference.
fokinsean 11y ago
I found the solution humorous. Ironically shallow clones are causing the problems, so fetch the max :) $ git fetch --depth=2147483647
- alblue 11y ago
  The problem is that the initial clone is depth=1, then subsequent fetches are depth=MAX. If you did clone depth=MAX in the first place it is faster to serve. Shallow (depth=1) can be converted into a full clone with the above.
web007 11y ago
I keep coming back to point #4 - who ever thought that 16k objects in a single directory would be a good idea? Ever since FAT that's been a bad idea, and while modern FSes will handle it without completely melting down it's still going to cause long access operations on anything to do with it. Even Finder or `ls` will have trouble with that, and anything with * is almost certainly going to fail. Is the use-case for this something that refers to each library directly, such that nobody ever lists or searches all 16k entries?
- acdha 11y ago
  I do think that your last sentence is the answer: if you're using a package manager instead of working with the directory heavily, this isn't a visible problem which is going to motivate people to work on it. The other side to consider: “one directory per package” is a very simple policy and it feels right in many ways to people (e.g. Homebrew has a similar structure because it's a natural fit for the domain). If the filesystem and basic tools like ls work just fine (which is certainly the case on OS X, where even "ls -l" or the Finder take less than a second on a directory of that size), isn't there a valid argument that the answer should be some combination of fixing tools which don't handle that well or encouraging people to learn about things like `find` instead of using wildcards which match huge numbers of files?
  - web007 11y ago
    One directory per package is completely sensible, just not all in one bunch. It's even fine if the mapping is to a flat namespace at something like the HTTP level - I can mod_rewrite /abcdefg to /a/b/c/abcdefg no problem. My only objection is to file- or directory-level structures that are this flat. I might be mentally deficient, but I can't even process anything that's structured this way. As loathe as I am to admit anything about Perl is good, CPAN got this right. 161k packages by 12k authors, grouped by A/AU/AUTHOR/Module. That even gives you the added bonus of authorship attribution. Debian splits in a similar way as well, /pool/BRANCH/M/Module/ and even /pool/BRANCH/libM/Module/ as a special case. Tooling can be considered part of the problem in this case. Because the tooling hides the implementation, nobody (in the project) noticed just how bad it was. I hadn't seen modern FS performance on something of this scale, apparently everything I've worked with has been either much smaller or much larger. Ext4 (and I assume HFS+) is crazy-fast for either `ls -l` or `find` on that repo. It seems like tooling is part of the solution as well, but from the `git` side. Having "weird" behavior for a tool that's so integral to so many projects scares me a little, but it's awesome that Github has (and uses) enough resources to identify and address such weirdness.
spoiler 11y ago
I find it amusing how GitHub's contact[1] form has (probably a recent addition): > GitHub Support is unable to help with issues specific to CocoaPods/CocoaPods. --- [1]: https://github.com/contact https://github.com/contact
- deleted 11y ago
  [deleted]
- sehr 11y ago
  I'm seeing something similar, only with Carthage instead of CocoaPods
- jrgifford 11y ago
  It's pretty nifty - it seems to pull in from your history, and then show `user/repo` for the most recent one you've looked at.
- synunlimited 11y ago
  Looks like this shows the last project you looked at before heading to the contact page. I refreshed the leaf repo and then refreshed the contact page and it mentioned the leaf project at the top.
- jdreaver 11y ago
  I think that contact page remembers the last repo you visited. I went to it in incognito mode and is wasn't there. That's a pretty neat feature!
- paulclinger 11y ago
  They seem to be doing this based on the last repository visited (for some popular once). Try visiting another repository before going to the contacts page and the message will change or disappear.
riscy 11y ago
> Scaling and operating this repo is actually quite simple for us as CocoaPods developers whom do not want to take on the burden of having to maintain a cloud service around the clock (users in all time zones) or, frankly, at all. The CocoaPods developers seem to be missing the entire point of git: it's a _distributed_ revision control system. Setup a post-recieve hook on Github to notify another server, that is setup with a basic installation of git, to pull from Github so as to mirror the master repo. Then, have your client program randomly choose one of these servers to pull from at the start of an operation. Simple load balancer to solve this problem.
- justinclift 11y ago
  Rackspace is also known to sponsor significant resources for larger projects whom ask nicely. GlusterFS is one I used to be involved with doing this, and there are definitely others. If CocoaPods reach out to Rackspace and/or other hosting providers, there's a decent chance they'll be able to pull together a good solution. :) The downside though, is they'll need to figure out some way to keep it monitored/maintained. :/
  - voltagex_ 11y ago
    Last I checked, Rackspace wasn't accepting any more projects.
ak217 11y ago
I love GitHub's response, but I would urge the project more strongly to use modern CDN solutions. CDNs are dirt cheap and incredibly powerful nowadays, for the data sizes that we're talking about here.
- thecodemonkey 11y ago
  How would you define "dirt cheap"? One of the most popular CDN's out there (Akamai) charges $3,500/month for 10TB/month. Who's going to foot that bill? :)
  - deleted 11y ago
    [deleted]
  - neoncontrails 11y ago
    10TB Amazon AWS is around $85-100, depending on how international your users are.
    - ak217 11y ago
      I believe that's off by an order of magnitude - that's actually the price per 1 TB. Also, you can turn off distribution into remote PoPs that charge more than $85/TB.
  - ak217 11y ago
    That's a list price that they charge those who don't care to negotiate. CloudFlare starts at $0 and doesn't meter/charge for bandwidth. CloudFront charges 9 cents per GB and is integrated with other AWS APIs (which can be very useful). Both those solutions could be managed with a donation pool, I would try the CloudFlare free tier first.
    - teraflop 11y ago
      CloudFlare's terms of service specifically forbid using it as a file hosting service.
  - 11y ago
nimish 11y ago
hopefully we can now move to using real artifact repositories.
xemdetia 11y ago
As a current maintenance developer/systems guy I can definitely feel the tempered annoyance from mhagger here. It's definitely nice to not remind yourself that it's not only your set of recurring issues in front of you that people have to deal with.
indygreg2 11y ago
I help run Mozilla's version control infrastructure and the problems described by the GitHub engineer have been known to me for years. Concerns over scaling Git servers are one of the reasons I am extremely reluctant to see Mozilla support a high volume Git server to support Firefox development. Fortunately for us, Firefox is canonically hosted in Mercurial. So, I implemented support in Mercurial for transparently cloning from server-advertised pre-generated static files. For hg.mozilla.org, we're serving >1TB/day from a CDN. Our server CPU load has fallen off a cliff, allowing us to scale hg.mozilla.org cheaply. Additionally, consumers around the globe now clone faster and more reliably since they are using a global CDN instead of hitting servers on the USA west coast! If you have Mercurial 3.7 installed, `hg clone https://hg.mozilla.org/mozilla-central` https://hg.mozilla.org/mozilla-central` will automatically clone from a CDN and our servers will incur maybe 5s of CPU time to service that clone. Before, they were taking minutes of CPU time to repackage server data in an optimal format for the client (very similar to the repack operation that Git servers perform). More technical details and instructions on deploying this are documented in Mercurial itself: https://selenic.com/repo/hg/file/9974b8236cac/hgext/clonebundles.py https://selenic.com/repo/hg/file/9974b8236cac/hgext/clonebun.... You can see a list of Mozilla's advertised bundles at https://hg.cdn.mozilla.net/ https://hg.cdn.mozilla.net/ and what a manifest looks like on the server at https://hg.mozilla.org/mozilla-central?cmd=clonebundles https://hg.mozilla.org/mozilla-central?cmd=clonebundles. A number of months ago I saw talk on the Git mailing list about implementing a similar feature (which would likely save GitHub in this scenario). But I don't believe it has manifested into patches. Hopefully GitHub (or any large Git hosting provider) realizes the benefits of this feature and implements it.
- _yy 11y ago
  Wow, this is pretty cool. Reminds me of the performance optimizations Facebook has done with Mercurial: https://code.facebook.com/posts/218678814984400/scaling-mercurial-at-facebook/ https://code.facebook.com/posts/218678814984400/scaling-merc... Mercurial was designed to be easy to extend, and it shows.
  - rjbwork 11y ago
    Git was created and designed to support Linus' workflow when developing the Linux kernel. Hg was designed to be a DVCS system.
soheil 11y ago
I was up until 2am last night trying to publish my Pod [1] and Github kept timing out. I had no idea it was just CocoaPods repo because my other repos were working fine. I accepted defeat, went to bed and everything was working great in the morning. [1] https://github.com/soheil/SwiftCSS https://github.com/soheil/SwiftCSS
rmoriz 11y ago
CocoaPods (and Homebrew) mainly exist because of a lack of tooling in the typical Apple ecosystem. So I would blame Apple for not supporting the community with money or tooling. Letting GitHub with its limited amount of funding pay the bill isn't a nice move. Apple dev relations should throw some money at GitHub so they can provide some dedicated resources or offer to pay the cost of other solutions (like a 3rd party CDN/AWS/Google Cloud/…).
- Gorbzel 11y ago
  CocoaPods exists because developers want to learn how to "build apps" but lack the resources to intelligently include and link to 3rd party code in their projects. CocoaPods doesn't enable anything not otherwise configurable via git submodules and Xcode project hierarchies / build settings. Therefore, it's not Apple's problem. In fact, I've talked to a non-trivial amount of engineers (both in Cupertino and long time Cocoa devs) that disapprove of the shortcuts that Cocoapods takes all over, software architecture be damned. Reasonable parties can agree to disagree, but I do include 3rd party framework inclusion without a dependency manager as an interview screen for prospective iOS hires. Since you mention developer relations, I'll assume you're not actually arguing that this is Apple's technical responsibility, but that they should throw around some $ to grease the wheels to make dependency inclusion better. As a platform vendor, funding hosting costs for some project that you don't agree with just to "support the community" is a bad idea. Better idea is to allocate resources to setup a structure that can fix the issue in a technically agreeable way while also benefitting from the independence a FOSS project provides. In doing so, you are correct that it'd be preferable for Apple to fund/use well-known FOSS standards, such as Github. In conclusion, Apple should setup a FOSS project to address the current inconveniences associated with third party package inclusion and should involve and pay Github somehow. Oh wait...https://github.com/apple/swift-package-manager https://github.com/apple/swift-package-manager
  - rmoriz 11y ago
    well, same could be said about Homebrew vs. Macports (which is hosted and maintained by Apple). Afaik even a lot of Apple developers don't use macports anymore… Afaik the swift package manager works only for swift code, so it's not an replacement. Also it's a very bad habit to try to stand over the users that supply software for your most valuable product. We've seen a lot of stories lately that indie app development is dead. We also regularly see how weak Apple is in web services (cloud sync). So either developers invest a lot of time to build something that works (and maybe even share it on GitHub) or they will stick with the holy Apple solution and provide a crappy user experience and go bankrupt. Companies like Google or Amazon (AWS) do a very good propag^developer releations job, IMHO way better than Apple ever did (in the last 10 years).
speps 11y ago
Why is everyone talking about CocoaPods where the title is CoacoaPods anyway? :)
- rtkwe 11y ago
  The title was misspelled and has been fixed. It's CocoaPods right on Github.
kodablah 11y ago
Has any consideration been given to Bintray[1] as an alternative store for this stuff? 1 - https://bintray.com/ https://bintray.com/
joeblau 11y ago
I just installed Cocoapods last night and tried to clone down the repo. It took about 5 minutes and I thought to myself "Is my 150MB/s connection slow?" This definitely clears up what was going on.
noahlt 11y ago
Go's package manager, `go get`, also downloads from GitHub. I don't know the details of how `go get` and CocoaPods work, but I would be interested in learning why one is unscalable and the other seems to work.
- miralabs 11y ago
  probably on separate repos which something like npm and bower does as well.
- karaziox 11y ago
  Because cloning the dependency is not the issue here. CocoaPods is keeping its index in a git repo that is updated by the user as a way to get the latest index. This is the repo that incur a lot of requests from everyone. Go get on the other hand doesn't keep any index. It just uses the url to download the dependency because of the mapping "url==project name" that exists with go projects.
debacle 11y ago
Why aren't the packages distributed? Composer is incredibly distributed and likely doesn't cause nearly the same headaches for GitHub. Seems like a poor design decision on the CocoaPods side.
- donarb 11y ago
  What package? My project may have a dependency on a specific commit that's between point releases. The problem is not packages, it's the index, containing 16000 subdirectories,
  - debacle 11y ago
    So the packages themselves aren't part of the repository?
    - kmm 11y ago
      No, only references to the repositories themselves are. The total Specs repo is only 300 megabyte, which comes to about 18 kilobyte per package on average. It's still absolutely ludicrous to use git for it, or worse, to bother github with it.
tjdetwiler 11y ago
Rust's cargo does something similar, however it looks like they were much more conscious of git-scalability (ex: limiting the directories in a single level, only appending lines to files to make diffs small). https://github.com/rust-lang/crates.io-index https://github.com/rust-lang/crates.io-index
- wycats 11y ago
  For what it's worse, both of these characteristics indeed weren't an accident. At the time, I wrote a script that hammered git commits into a repository using different strategies and looked at what the git repository would look like after 100,000 and a million commits. The "one version per file, nested in a flat structure" had serious issues. There may still be scaling limits with the Cargo approach, but if we reach them, we have plans to create a new registry with a new initial commit and let the old registry age out, then rinse/repeat. At the moment, we haven't hit limits yet (with about 1/3 of the packages that Cocoapods has).
mikeash 11y ago
The criticism against CocoaPods here seems awfully harsh. Think about it from their perspective. GitHub advertises a free service, and encourages using it. Partly it's free because it's a loss leader for their paid offerings, and partly it's free because free usage is effectively advertising GitHub. CocoaPods builds builds their project on this free service, and everything is fine for years. Then one day things start failing mysteriously. It looks like GitHub is down, except GitHub isn't reporting any problems, and other repositories aren't affected. After lots of headscratching, GitHub gets in touch and says: you're using a ton of resources, we're rate limiting you, you're using git wrong, and you shouldn't even be using git. That's going to be a bit of a shock! Everything seemed fine, then suddenly it turns out you've been a major problem for a while, but nobody bothered to tell you. And now you're in hair-on-fire mode because it's reached the point where the rate-limiting is making things fail, and nobody told you about any of these problems before they reached a crisis point. It strikes me as extremely unreasonable to expect a group to avoid abusing a free service when nobody tells them that it's abuse, and as far as they know they're using it in a way that's accepted and encouraged. If somebody is doing something you don't like and you want them to stop, you have to tell them, or nothing will happen! I'm not blaming GitHub here either. I'm sure they didn't make this a surprise on purpose, and they have a ton of other stuff going on. This looks like one of those things where nobody's really to blame, it's just an unfortunate thing that happened. (And just to be clear, I don't have much of a dog in this fight on either side. My only real exposure to CocoaPods is having people occasionally bug me to tag my open source repositories to make them easier to incorporate into CocoaPods. I use GitHub for various things like I imagine most of us do, but am not particularly attached to them.)
- martinald 11y ago
  I entirely agree with this. GitHub gets so much advertising + community from open source projects like this. Also, I'm amazed this is even a problem. 5 CPUs is not a lot in the scheme of things (even if they mean physical instead of cores). TBs of bandwidth are also virtually free compared to a company the size of Github. Even better: they are getting basically real world loadtested for free and finding loads of pain points, which may hit paying customers. Unless I'm missing something, fire more metal at the problem. Many companies would love to be able to have every single cocoapod user (which is nearly every iOS developer) have to type github.com into their terminal for the cost of a bunch of servers + some bandwidth. Pretty strange, unless this is hitting some really bad area of their service that can't easily be scaled out of (but i would be surprised)
iamleppert 11y ago
Amazing to me that people create inefficient systems like this and then complain when they are rate limited.
paradite 11y ago
I have been seeing this trend of GitHub getting "abused" for purposes other than hosting source code. - My school uses GitHub to host and track our software engineering project (which still can be argued as OSS). - People using GitHub issue system as a forum. - Friends uploading pdfs to GitHub. - Recently people posted on HN about using GitHub to generate a status page. I think this is a really bad trend and people should stop doing that.
- WillAbides 11y ago
  The school example and friends uploading pdfs to GitHub are both uses that GitHub encourages. Using GitHub Issues as a forum and a source for generating status pages are both ok from a use/abuse perspective, but you may not have the best experience since that isn't what Issues is intended for.
  - takluyver 11y ago
    The issue tracker on new repos has a 'question' tag by default, so Github are gently encouraging using issues as a forum. Though my inner cynic says that makes sense for them - issues tie a project to Github more than the git repo itself does. It should be fine to come up with new ways to use Github, as long as it's not causing excessive load.
whitehat2k9 11y ago
Only the Apple development community would think it's OK to have 16,000 subdirectories in one place and abuse GitHub as a free CDN instead of putting some actual effort in and develop their own repository infrastructure - you know, like almost every other package manager in existence.
- mayli 11y ago
  It should be "Apple or Ruby development community", homebrew is using similar tech stack distributing the `Formula`.
  - whitehat2k9 11y ago
    I guess it's no coincidence that those two hispter communities are closely related.
fpgaminer 11y ago
GitTorrent: http://blog.printf.net/articles/2015/05/29/announcing-gittorrent-a-decentralized-github/ http://blog.printf.net/articles/2015/05/29/announcing-gittor... Imagine a world where GitTorrent is fully developed, includes support for issue tracking, and has a nice GUI client that makes the experience on-par with browsing github.com. I mention this not as an "Everybody bail out of GitHub and run to GitTorrent!!!" sort of statement, because I believe GitHub's response here was excellent and confidence inspiring. But it's an unnatural relationship for community supported, open source projects to host themselves on commercial platforms such as GitHub. GitHub primarily hosts them to promote its business. That's not necessarily a bad thing, but it results impedance mismatches like demonstrated here. That isn't to say that a mature GitTorrent would replace GitHub. Rather, I envision GitHub becoming a supernode in the network, an identity provider, and a paid seed offering, all alongside their existing private repo business. Honestly, once I scrape a few projects off my plate, I'm inclined to dive into GitTorrent, see where it's at in development, and see if I can start contributing code. It just seems like such a cool and useful idea.
- cyphar 11y ago
  My main issue with Free Software projects using GitHub is that it's proprietary, not that it's commercial. Admittedly, I think GitTorrent is a really cool idea, but I'm wondering if a distributed filesystem might be a more elegant solution than using both BitTorrent and Bitcoin.
maaku 11y ago
Using Github as your CDN is a dick move. Kudos to GH for not banning the project out-right, but CocoaPods should seriously reconsider what they are doing.
Const-me 11y ago
I don’t think GitHub acts wisely here. Short term sure, they’re doing the right thing, implementing a nice way to manage the free rider problem without hurting them too much. But long term it’s different. Financially, one average programmer = $80k/year, one average cloud server = $4k/year. And, GitHub has hundreds of millions of venture capital. More than enough to provision a few more servers, even if they will be installing new servers just for those pods. The way they act now will lead to someone will develop a decentralized git+torrent hybrid. When that happens, sure, those pods will no longer consume precious GitHub’s resources. However, for the rest of the github users, there will be no reason to stay on GitHub either.
- cyphar 11y ago
  The way CocoaPods is using git is bad, so they'd probably run into some problems no matter how they host it. If you know anything about filesystems, they start to have pathologies when you have many entries in the same directory (which is why git has it's object store in the format prefix/object). In addition, it looks like git has it's own pathologies with such large numbers of dentries. Having 16000 entries in your "specs" directory is not a good idea. No matter how you store it. Not to mention that "just buy another server for this one project" sounds like something CocoaPods should pay for.
  - Const-me 11y ago
    >The way CocoaPods is using git is bad Very likely true, but I don’t see how’s that related. >they start to have pathologies when you have many entries in the same directory Only true for inefficient filesystems like FAT. For NTFS, 16k entries is nothing, the performance fill start to degrade (due to directory fragmentation) at around 100k entries: http://stackoverflow.com/a/291292/126995 http://stackoverflow.com/a/291292/126995 >"just buy another server for this one project" sounds like something CocoaPods should pay for. I don’t think that’s how 21 century economy works in this case. Github’s value is likely between $0.75B and $2B. Bad PR caused by this story will exceed 10 years TCO of that extra server.
rcthompson 11y ago
Reading the issue, it seems that one of the problems is a single directory with lots and lots of files in it, which is something of a pathological case for Git. Now, this could be "fixed" by splitting the files in that directory into subdirectories, but the one giant directory will still exist in all the past commits. So would this actually fix anything, or just keep it from getting worse?
- cyphar 11y ago
  Filesystems also have the same pathology, which is why git's object store is of the form prefix/object.
  - rcthompson 11y ago
    In a filesystem, you can address the problem by reorganizing the directory structure. And you can do the same for future Git commits. But unless I'm mistaken, that colossal directory is stuck in the git history unless you actually rewrite that history, which would require everyone who cloned the repo to either rebase or re-clone the repo. Maybe it's not a problem because the cost is only paid when one checks out one of those old commits, which would happen rarely?
kmm 11y ago
Funny thing is that the repo is only 7 MB gzipped (or 4 with lzma). Not that surprising, since it's just metadata of course. They say they have about 1 million fetches/clones per week, so that would make about 16 TB per month. I'm not sure how much bandwidth costs, but wouldn't some sympathetic CDN host that for free, since they're OSS?
voltagex_ 11y ago
It's difficult to run an open source project on a budget of $0. You're always relying on the goodwill of others.
rdancer 11y ago
tl;dr: "Using GitHub as your [free-of-charge] CDN is not ideal, for anybody involved."
LoneWolf 11y ago
While I do not have much knowledge on the subject, why not using rsync?

826 points by jergason 11y ago

superuser2 11y ago

Just last night, all my pod installs were timing out after ~30ish minutes. That explains it.

jessaustin 11y ago
Should we infer from your behavior that such a timeframe is fairly normal for cocopod? If I ran an "npm i" (or "pip install", etc.) that didn't respond for a minute, I would suspect a problem and kill it. How can any development process that takes longer than that be practical?
- superuser2 11y ago
  Indeed, I was killing and restarting the process for a while, trying to get it to be more verbose, etc. Eventually I decided to try letting it run, and that didn't work either. I don't know what's normal; last night was one of my first iOS projects.
- draw_down 11y ago
  Seriously. I regularly `npm i`, run tests, switch branches, blow away node_modules, then `npm i` again. It's really important for it to be quick. Then again, there is caching to help.
joeblau 11y ago
I installed from scratch last night on a server and it took ~5 mins.

onli 11y ago

Note how perfect that response from mhagger is. A clear, honest sounding assurance of what Github wants to deliver. A perfectly comprehensible description of what is the problem, and where it is coming from. And then suggestion how to fix it the project actually can work on, plus mentioning changes to git itself that Github is trying to make that would help. It not only shows great work going on behind the scenes (and if that is untrue, it at least gives me that impression, which is what counts), but also explains it in a great way.

dankohn1 11y ago
Yes, it's a hugely positive advertisement for the essential role that Github plays in the open source community. Also impressive is the followup message from a Github API developer (and Homebrew maintainer) offering access to a beta API that Homebrew is working with to reduce load. https://github.com/CocoaPods/CocoaPods/issues/4989#issuecomment-193801376 https://github.com/CocoaPods/CocoaPods/issues/4989#issuecomm...
- arrakeen 11y ago
  taking a look at homebrew's implementation of this new API feature, i fail to see how it would dramatically reduce fetches for their (homebrew's) use case. from what i understand, it will only be called when the user manually invokes `brew update`. how often are users calling this command over and over? that being said, i do believe it could help cocoapod's use case since the fetches are done automatically (as i understand it)
  - ropiku 11y ago
    It's also being used in scripts. In our Mac CI environment (for iOS builds) we update homebrew to have the latest xctool.
  - barkingcat 11y ago
    brew update is being called over and over again in most use cases - if only to check for example, if the latest openssl release patching a critical exploit is out yet. (of course on the mac openssl is packaged with the system, but if you are using the brew version, or are compiling other software against openssl from brew, you'll need to check for updates diligently) It is also being used in scripts, etc. Since from the user's point of view it's a no-op if there are no updates, there is no reason not to do it on a schedule.
  - mikemcquaid 11y ago
    Hello! I'm the Homebrew maintainer and GitHub employee who wrote this. The main thing this API does for Homebrew is make no-ops really fast for `brew update`. As you point out this results in no speedup (in fact a tiny slowdown) for the case where you only run it where you know you have changes. Where it becomes useful is if you are using multiple taps (Homebrew's 3rd-party repositories) which update infrequently or if you want to run `brew update` automatically in e.g. a project bootstrap script that's run frequently. In the medium to long-term I'd like to consider Homebrew running `brew update` automatically before you `brew install` (https://github.com/Homebrew/homebrew/issues/38818 https://github.com/Homebrew/homebrew/issues/38818). For us to ever be able to do that `brew update`'s no-op case needs to be extremely fast.

jdcarter 11y ago

Wow, really impressive response from GitHub. The right amount of technical detail coupled with balanced tone--halfway between "we support you" and "you make us crazy." One correction to the post title: it's not maxing five nodes, but five CPUs.

justinclift 11y ago
Yeah, 5 cpu's is an order of magnitude difference. ;)
- joshribakoff 11y ago
  Wait, so the CPU isn't the big white tower sitting under my desk?!
  - minsight 11y ago
    According to my mother, that's "The hard drive".
dang 11y ago
Ok, we replaced "nodes" with "server CPUs" in the title.

zoul 11y ago

Another reason I consider https://github.com/Carthage/Carthage https://github.com/Carthage/Carthage a better solution of the dependency management problem.

cballard 11y ago
And https://github.com/apple/swift-package-manager https://github.com/apple/swift-package-manager once it's ready, which is similar to Carthage in structure (decentralized!).
- kylef 11y ago
  Swift Package Manager will also have a centralised package index in the future, here's a quote from their [package manager proposal][1]: > We would like to provide a package index in the future, and are investigating possible solutions. [1]: https://github.com/apple/swift-package-manager/blob/master/Documentation/PackageManagerCommunityProposal.md https://github.com/apple/swift-package-manager/blob/master/D...
joeblau 11y ago
I really like Carthage's architecture, but there are two things I don't like about it. 1. You can't edit the frameworks unless you open a separate project, re-edit and recompile. With Pods, you can edit the Pod in your workspace. 2. Carthage doesn't go the last mile to bundle the framework into your project. If they addressed those two things, I feel like Cocoapods would probably start losing a lot of steam. Although, after watching some videos about what the goals of Carthage were from the creators, I doubt that those two things will be addressed so I'm waiting for Swift's Package Manager.
- zoul 11y ago
  I consider both points a feature. I think the Xcode project of the dependency should be a black box, I just want to get the resulting framework to add to my workspace.
arr2bee2 11y ago

sdegutis 11y ago

I love how this was like the perfect storm of things that could go wrong, and how it seems like mhagger is just amazed more than anything else.

revelation 11y ago
Hardly. Do they hit edge cases? Yes! Is using GitHub for your CDN a dick move and going to cause problems, regardless? Yes! The response from mhagger is unnecessarily apologetic, and I predict we'll see an official update from GitHub on this soon.
- zeveb 11y ago
  > Is using GitHub for your CDN a dick move and going to cause problems, regardless? Yes! I don't know about that. Both oh-my-zsh[1] and emacs prelude[2] use git repos as their code distribution mechanisms, and that works really well. I think the real issues here are exactly what is called out in the issue: poor usage of git, and poor directory layout. [1] https://github.com/robbyrussell/oh-my-zsh https://github.com/robbyrussell/oh-my-zsh [2] https://github.com/bbatsov/prelude https://github.com/bbatsov/prelude
  - pjc50 11y ago
    Are either of those anywhere near as popular?
  - revelation 11y ago
    They are using GitHub for their intended purpose, hosting their code. That is perfectly fine. What is not perfectly fine is using GitHub as your package host, CocoaPods/Specs is the equivalent of Debians APT using one big GitHub repo to host all their packages. It has 92567 commits and 6872 contributors.
    - masklinn 11y ago
      OTOH Homebrew also uses github as its package host and has a respectable 62000 commits and 5600 contributors and github seems to be just fine with it. The big differences seems to be in the way they do their thing: I'm reasonably sure homebrew just git clones then updates the local repository normally[0], it has "only" 2500 files in Library/Formula, and because of its different subject it is way less write-active, CocoaPod has 1k commits/week which look to be increasing pretty much constantly, homebrew is around 350 with ups and downs. Also not sure it matters, but homebrew has lots of commits updating existing formula, cocoapod changes are almost solely addition (publishing a new version of a package adds a new spec and doesn't touch the old one) [0] which is exactly the bread and butter of github

zymhan 11y ago

I've always found Github's business model interesting. What if a massive open-source organization (e.g. Fedora, Apache) decided to use it for all of their development, integrating it with continuous builds and all the associated pulls. Of course this isn't likely to happen for a number of reasons, but there are large open source projects that could put a significant load on their infrastructure if they chose to use Github as their main code versioning system.

Anderkent 11y ago
Presumably they'd get load-limited to the same degree and eventually be forced to move to something they control.
athenot 11y ago
It's the same business model that Jira used in the past, when the alternatives were Mantis, Trac and Bugzilla. They had[1] one of the better and well designed issue trackers, free for OSS projects. That turned into a great way to champion adoption within paying customers' organizations. [1] In my opinion, they have since lost that edge on the UI.
- stevoski 11y ago
  I remember seeing this new much improved UI for bug tracking on OSS, and thinking, "Thank goodness they're no longer using Bugzilla". And then using it a bit, and thinking, "I've got to get that bug tracker into the org I'm working for." Yep, it was Jira. It was a great strategy they used!
consp 11y ago
I think they should do 'ok' though it won't make you wealthy: - They collect money from businesses (who pay quite well) - They collect money from private repos (like I have for lots of my config files, no, no passwords/keys in there ;) for e.g. tex files. - The large companies probably pay some form of 'support'
discreditable 11y ago
> What if a massive open-source organization (e.g. Fedora, Apache) decided to use it This one is pretty big. https://github.com/torvalds/linux https://github.com/torvalds/linux

Gratsby 11y ago

From CocoaPods.org: > CocoaPods is a dependency manager for Swift and Objective-C Cocoa projects. It has over ten thousand libraries and can help you scale your projects elegantly. The developer response: > [As CocoaPods developers] Scaling and operating this repo is actually quite simple for us as CocoaPods developers whom do not want to take on the burden of having to maintain a cloud service around the clock (users in all time zones) or, frankly, at all. Trying to have a few devs do this, possibly in their spare-time, is a sure way to burn them out. And then there’s also the funding aspect to such a service. -- So they want to be the go-to scaling solution, but they don't want to have to spend any time thinking about how to scale anything. It should just happen. Other people have free scalable services, they should just hand over their resources. Thank goodness Github thought about these kinds of cases from the beginning and instituted automatic rate limiting. Having an entire end user base use git to sync up a 16K+ directory tree is not a good idea in the first place. The developers should have long since been thinking about a more efficient solution.

geofft 11y ago
I think the word "scale" is used to mean different things in the two sentences you quoted. In the first case, "scale" is about package management and dependency tracking, helping an individual software project approach large scale (many third-party dependencies with possibly conflicting requirements, new developers who need to get up-to-speed quickly, etc.). In the second case, "scaling" is about distribution of the CocoaPods metadata to large numbers of users, each with their own (possibly small) software project. Sentence 1 would still be true if CocoaPods was only used by ten companies developing the ten biggest (in terms of lines of code) Objective-C projects, but there would no longer be a need to scale in the sense of sentence 2.
Kapura 11y ago
It seems like a classic example of ignoring the negative externalities. Luckily, we live in a connected world where it is sometimes easy to trace the after-effects. I understand the desire to personally maintain as few of one's own servers as possible, but when the result is negative effects on the service hosting the project and a worse experience for the end-user, it might be time to start looking over what google cloud offers.

pjc50 11y ago

This reply: https://github.com/CocoaPods/CocoaPods/issues/4989#issuecomment-193810378 https://github.com/CocoaPods/CocoaPods/issues/4989#issuecomm... "Not having to develop a system that somehow syncs required data at all means we get to spend more time on the work that matters more to us, in this case. (i.e. funding of dev hours)" In other words, using github as a free unlimited CDN lets them be as inefficient as they like. Such as having 16k entries in a directory ( https://github.com/CocoaPods/Specs/tree/master/Specs https://github.com/CocoaPods/Specs/tree/master/Specs ) which every user downloads. Package management and sync seems to suffer really badly from NIH. Dpkg is over 20 years old and yum is over a decade old. What's up with this particular wheel that people keep reinventing it seemingly without improvement?

superuser2 11y ago
Perhaps because Cocoapods is not an OS package manager or anything close to it. It installs libraries within the context of an XCode project, regardless of the host system or what is installed for other projects.
- pjc50 11y ago
  It is a package manager, though? The fundamental idea of downloading a list of available options of which the user picks some, and the system pulls in dependencies, is almost exactly how dpkg and yum work. The location to which the packages are installed is a detail.
  - pretz 11y ago
    CocoaPods is much more akin to RubyGems or PyPI or CPAN, all of which are established as useful tools outside of OS level package managers. There's a need for a iOS/Cocoa package manager (that understands Xcode!) and CocoaPods has so far been the most successful.
  - masklinn 11y ago
    A language package manager must be able to "install" the same packages over and over again (and possibly "install" multiple versions of the same package in the same environment), and the ability to push packages is generally considered part of their duty, not so for OS package managers, you don't use dpkg to send a package to debian's repositories. > The fundamental idea of downloading a list of available options of which the user picks some, and the system pulls in dependencies, is almost exactly how dpkg and yum work. If you reduce it to the fundamentals you don't need yum or dpkg either to do that, just a dependency solver and curl.

pavlov 11y ago

I've never really understood CocoaPods. Dragging a framework into Xcode was never much trouble, and the amount of 3rd party libraries in a OS X / iOS project ought to be fairly small, so the gains are trivial. The potential downsides seem much more annoying. Do you really want to have your dependencies on an overloaded central server somewhere?

Moto7451 11y ago
Until recently iOS only supported statically linked libraries which could lead to issues if you needed to use multiple components that had a shared dependency that you needed to upgrade for one reason or another. You couldn't touch the embedded version. Additionally there was no native package manager which made sharing libraries a clumsy affair. Cocoapods makes both cases easier.
- seanalltogether 11y ago
  This is correct. Starting with iOS 8 they finally allowed linking against custom frameworks which is why Carthage is now becoming much more popular. CocoaPods solved a critical problem of getting dependencies linked in, while creating a new problem of having your xcodeproj file and build settings be managed by them. I'll be happy enough to drop them for new projects going forward.
  - jallmann 11y ago
    > Starting with iOS 8 they finally allowed linking against custom frameworks I don't keep up with iOS development enough to know if anything has changed with respect to static/dynamic linking in iOS 8, but it has always been possible to use custom frameworks in iOS (eg, frameworks you build yourself, unless the community has another definition for 'custom framework'). The framework directory structure is a bit unorthodox, but it's really just your statically built library (absent any '.a' suffix) alongside any header files in a Headers folder. Again, not sure if this has changed with any support for dynamic linking.
    - 11y ago

deleted 11y ago

[deleted]

jrochkind1 11y ago

What an unusually reasonable discussion. good on everyone.

iBotPeaches 11y ago

This bug report is a great step in the direction for GitHub. As of this comment there are 3 different GitHub staff members responding and providing feedback to the CocoaPods team. From the previous "Dear GitHub" messages and responses, this seems like perfect community involvement.

wpeterson 11y ago

It's totally reasonable to host your code on github and to build a package manager that loads the content of a package from it's github repo. What seems insane is to use a single github repo as the universal directory of packages and their versions driving your package manager. There's a reason rubygems has their own servers and web services to support this use case for the central library registry, even if the source for gems are all individually projects hosted on github.

lucaspiller 11y ago
I assume they modelled it after Homebrew, which has been working fine doing exactly that for the last 7 years. That only has 3,000 packages vs 15,000 for CocoaPods or 115,000 for RubyGems.
- philippnagel 11y ago
  In case somebody is interested in such figures (I certainly am) - NPM has 249,838 as of today [0]. [0]: https://www.npmjs.com https://www.npmjs.com
caf 11y ago
I wonder whether you could use a DHT for the package directory.

Negative1 11y ago

When he says approaches similar to 'other packaging systems', which ones is he referring to? I can see why this is a bad approach but am unfamiliar with what would be considered a better practice (outside of just hosting a .tar on CloudFront).

wpeterson 11y ago
RubyGems.org has their own web server and web services for publishing library versions and to allow the clients to fetch libraries and query the universal registry.
- s_kilk 11y ago
  Same goes for almost any language-specific package manager you could name: Rust/Cargo, Clojure/Clojars, Node/npm, Elixir/hex, Python/PyPi. No matter which way you slice it, what CocoaPods is doing is a bit daft, especially at their scale.
  - kuschku 11y ago
    Or even the Java community, where you have MavenCentral, JCenter, etc.
  - steveklabnik 11y ago
    Small note: Cargo _does_ use an index (not the source code), in git, on GitHub. However, we're already doing the directory layout that they recommend in-thread, so we shouldn't have this specific problem.
JonnieCache 11y ago
Probably homebrew, which is also heavily based on github, although not to the same extent as CocoaPods apparently is. It's mentioned further downthread. The main difference is that homebrew actually updates the git tree to provide updated versions of package specs. CocoaPods adds a new directory and some files for each package version, causing the repo to balloon.

sly010 11y ago

I would be interested to know what are the other top GitHub repositories. Afaik the Nix package manager uses a similar model (using a GitHub repo as a database), however they periodically release snapshots and the default configuration uses those instead of git.

vbezhenar 11y ago
I'm not sure how DefinitelyTyped works, but their repository https://github.com/DefinitelyTyped/DefinitelyTyped https://github.com/DefinitelyTyped/DefinitelyTyped is huge and may be they use that github repository as a single distribution point.
- WorldMaker 11y ago
  People interact with DefinitelyTyped in a set of ways, from currently most common to least common: 1. NuGet packages, which are built from the GitHub repository but then redistributed over a non-Github CDN (NuGet's) 2. tsd management tool (https://github.com/Definitelytyped/tsd https://github.com/Definitelytyped/tsd), which looks like it prefers Github's CDN raw URLs rather than full/shallow git clones 3. typings management tool (https://github.com/typings/typings https://github.com/typings/typings) with "ambient" typings searches (`--ambient` flag), which I believe also prefers Github's CDN raw URLs, as it essentially forked from TSD That said, it's past time to move beyond the giant huge DefinitelyTyped repo, and I for one heartily recommend people migrate to typings which has better support for NPM and other module and package management systems, as well as smaller unit/module-focused Github repositories.

SuperKlaus 11y ago

In fact, they are maxing out five CPUs - not five nodes, big difference.

fokinsean 11y ago

I found the solution humorous. Ironically shallow clones are causing the problems, so fetch the max :) $ git fetch --depth=2147483647

alblue 11y ago
The problem is that the initial clone is depth=1, then subsequent fetches are depth=MAX. If you did clone depth=MAX in the first place it is faster to serve. Shallow (depth=1) can be converted into a full clone with the above.

web007 11y ago

I keep coming back to point #4 - who ever thought that 16k objects in a single directory would be a good idea? Ever since FAT that's been a bad idea, and while modern FSes will handle it without completely melting down it's still going to cause long access operations on anything to do with it. Even Finder or `ls` will have trouble with that, and anything with * is almost certainly going to fail. Is the use-case for this something that refers to each library directly, such that nobody ever lists or searches all 16k entries?

acdha 11y ago
I do think that your last sentence is the answer: if you're using a package manager instead of working with the directory heavily, this isn't a visible problem which is going to motivate people to work on it. The other side to consider: “one directory per package” is a very simple policy and it feels right in many ways to people (e.g. Homebrew has a similar structure because it's a natural fit for the domain). If the filesystem and basic tools like ls work just fine (which is certainly the case on OS X, where even "ls -l" or the Finder take less than a second on a directory of that size), isn't there a valid argument that the answer should be some combination of fixing tools which don't handle that well or encouraging people to learn about things like `find` instead of using wildcards which match huge numbers of files?
- web007 11y ago
  One directory per package is completely sensible, just not all in one bunch. It's even fine if the mapping is to a flat namespace at something like the HTTP level - I can mod_rewrite /abcdefg to /a/b/c/abcdefg no problem. My only objection is to file- or directory-level structures that are this flat. I might be mentally deficient, but I can't even process anything that's structured this way. As loathe as I am to admit anything about Perl is good, CPAN got this right. 161k packages by 12k authors, grouped by A/AU/AUTHOR/Module. That even gives you the added bonus of authorship attribution. Debian splits in a similar way as well, /pool/BRANCH/M/Module/ and even /pool/BRANCH/libM/Module/ as a special case. Tooling can be considered part of the problem in this case. Because the tooling hides the implementation, nobody (in the project) noticed just how bad it was. I hadn't seen modern FS performance on something of this scale, apparently everything I've worked with has been either much smaller or much larger. Ext4 (and I assume HFS+) is crazy-fast for either `ls -l` or `find` on that repo. It seems like tooling is part of the solution as well, but from the `git` side. Having "weird" behavior for a tool that's so integral to so many projects scares me a little, but it's awesome that Github has (and uses) enough resources to identify and address such weirdness.

spoiler 11y ago

I find it amusing how GitHub's contact[1] form has (probably a recent addition): > GitHub Support is unable to help with issues specific to CocoaPods/CocoaPods. --- [1]: https://github.com/contact https://github.com/contact

deleted 11y ago
[deleted]
sehr 11y ago
I'm seeing something similar, only with Carthage instead of CocoaPods
jrgifford 11y ago
It's pretty nifty - it seems to pull in from your history, and then show `user/repo` for the most recent one you've looked at.
synunlimited 11y ago
Looks like this shows the last project you looked at before heading to the contact page. I refreshed the leaf repo and then refreshed the contact page and it mentioned the leaf project at the top.
jdreaver 11y ago
I think that contact page remembers the last repo you visited. I went to it in incognito mode and is wasn't there. That's a pretty neat feature!
paulclinger 11y ago
They seem to be doing this based on the last repository visited (for some popular once). Try visiting another repository before going to the contacts page and the message will change or disappear.

riscy 11y ago

> Scaling and operating this repo is actually quite simple for us as CocoaPods developers whom do not want to take on the burden of having to maintain a cloud service around the clock (users in all time zones) or, frankly, at all. The CocoaPods developers seem to be missing the entire point of git: it's a _distributed_ revision control system. Setup a post-recieve hook on Github to notify another server, that is setup with a basic installation of git, to pull from Github so as to mirror the master repo. Then, have your client program randomly choose one of these servers to pull from at the start of an operation. Simple load balancer to solve this problem.

justinclift 11y ago
Rackspace is also known to sponsor significant resources for larger projects whom ask nicely. GlusterFS is one I used to be involved with doing this, and there are definitely others. If CocoaPods reach out to Rackspace and/or other hosting providers, there's a decent chance they'll be able to pull together a good solution. :) The downside though, is they'll need to figure out some way to keep it monitored/maintained. :/
- voltagex_ 11y ago
  Last I checked, Rackspace wasn't accepting any more projects.

ak217 11y ago

I love GitHub's response, but I would urge the project more strongly to use modern CDN solutions. CDNs are dirt cheap and incredibly powerful nowadays, for the data sizes that we're talking about here.

thecodemonkey 11y ago
How would you define "dirt cheap"? One of the most popular CDN's out there (Akamai) charges $3,500/month for 10TB/month. Who's going to foot that bill? :)
- deleted 11y ago
  [deleted]
- neoncontrails 11y ago
  10TB Amazon AWS is around $85-100, depending on how international your users are.
  - ak217 11y ago
    I believe that's off by an order of magnitude - that's actually the price per 1 TB. Also, you can turn off distribution into remote PoPs that charge more than $85/TB.
- ak217 11y ago
  That's a list price that they charge those who don't care to negotiate. CloudFlare starts at $0 and doesn't meter/charge for bandwidth. CloudFront charges 9 cents per GB and is integrated with other AWS APIs (which can be very useful). Both those solutions could be managed with a donation pool, I would try the CloudFlare free tier first.
  - teraflop 11y ago
    CloudFlare's terms of service specifically forbid using it as a file hosting service.
- 11y ago

nimish 11y ago

hopefully we can now move to using real artifact repositories.

xemdetia 11y ago

As a current maintenance developer/systems guy I can definitely feel the tempered annoyance from mhagger here. It's definitely nice to not remind yourself that it's not only your set of recurring issues in front of you that people have to deal with.

indygreg2 11y ago

I help run Mozilla's version control infrastructure and the problems described by the GitHub engineer have been known to me for years. Concerns over scaling Git servers are one of the reasons I am extremely reluctant to see Mozilla support a high volume Git server to support Firefox development. Fortunately for us, Firefox is canonically hosted in Mercurial. So, I implemented support in Mercurial for transparently cloning from server-advertised pre-generated static files. For hg.mozilla.org, we're serving >1TB/day from a CDN. Our server CPU load has fallen off a cliff, allowing us to scale hg.mozilla.org cheaply. Additionally, consumers around the globe now clone faster and more reliably since they are using a global CDN instead of hitting servers on the USA west coast! If you have Mercurial 3.7 installed, `hg clone https://hg.mozilla.org/mozilla-central` https://hg.mozilla.org/mozilla-central` will automatically clone from a CDN and our servers will incur maybe 5s of CPU time to service that clone. Before, they were taking minutes of CPU time to repackage server data in an optimal format for the client (very similar to the repack operation that Git servers perform). More technical details and instructions on deploying this are documented in Mercurial itself: https://selenic.com/repo/hg/file/9974b8236cac/hgext/clonebundles.py https://selenic.com/repo/hg/file/9974b8236cac/hgext/clonebun.... You can see a list of Mozilla's advertised bundles at https://hg.cdn.mozilla.net/ https://hg.cdn.mozilla.net/ and what a manifest looks like on the server at https://hg.mozilla.org/mozilla-central?cmd=clonebundles https://hg.mozilla.org/mozilla-central?cmd=clonebundles. A number of months ago I saw talk on the Git mailing list about implementing a similar feature (which would likely save GitHub in this scenario). But I don't believe it has manifested into patches. Hopefully GitHub (or any large Git hosting provider) realizes the benefits of this feature and implements it.

_yy 11y ago
Wow, this is pretty cool. Reminds me of the performance optimizations Facebook has done with Mercurial: https://code.facebook.com/posts/218678814984400/scaling-mercurial-at-facebook/ https://code.facebook.com/posts/218678814984400/scaling-merc... Mercurial was designed to be easy to extend, and it shows.
- rjbwork 11y ago
  Git was created and designed to support Linus' workflow when developing the Linux kernel. Hg was designed to be a DVCS system.

soheil 11y ago

I was up until 2am last night trying to publish my Pod [1] and Github kept timing out. I had no idea it was just CocoaPods repo because my other repos were working fine. I accepted defeat, went to bed and everything was working great in the morning. [1] https://github.com/soheil/SwiftCSS https://github.com/soheil/SwiftCSS

rmoriz 11y ago

CocoaPods (and Homebrew) mainly exist because of a lack of tooling in the typical Apple ecosystem. So I would blame Apple for not supporting the community with money or tooling. Letting GitHub with its limited amount of funding pay the bill isn't a nice move. Apple dev relations should throw some money at GitHub so they can provide some dedicated resources or offer to pay the cost of other solutions (like a 3rd party CDN/AWS/Google Cloud/…).

Gorbzel 11y ago
CocoaPods exists because developers want to learn how to "build apps" but lack the resources to intelligently include and link to 3rd party code in their projects. CocoaPods doesn't enable anything not otherwise configurable via git submodules and Xcode project hierarchies / build settings. Therefore, it's not Apple's problem. In fact, I've talked to a non-trivial amount of engineers (both in Cupertino and long time Cocoa devs) that disapprove of the shortcuts that Cocoapods takes all over, software architecture be damned. Reasonable parties can agree to disagree, but I do include 3rd party framework inclusion without a dependency manager as an interview screen for prospective iOS hires. Since you mention developer relations, I'll assume you're not actually arguing that this is Apple's technical responsibility, but that they should throw around some $ to grease the wheels to make dependency inclusion better. As a platform vendor, funding hosting costs for some project that you don't agree with just to "support the community" is a bad idea. Better idea is to allocate resources to setup a structure that can fix the issue in a technically agreeable way while also benefitting from the independence a FOSS project provides. In doing so, you are correct that it'd be preferable for Apple to fund/use well-known FOSS standards, such as Github. In conclusion, Apple should setup a FOSS project to address the current inconveniences associated with third party package inclusion and should involve and pay Github somehow. Oh wait...https://github.com/apple/swift-package-manager https://github.com/apple/swift-package-manager
- rmoriz 11y ago
  well, same could be said about Homebrew vs. Macports (which is hosted and maintained by Apple). Afaik even a lot of Apple developers don't use macports anymore… Afaik the swift package manager works only for swift code, so it's not an replacement. Also it's a very bad habit to try to stand over the users that supply software for your most valuable product. We've seen a lot of stories lately that indie app development is dead. We also regularly see how weak Apple is in web services (cloud sync). So either developers invest a lot of time to build something that works (and maybe even share it on GitHub) or they will stick with the holy Apple solution and provide a crappy user experience and go bankrupt. Companies like Google or Amazon (AWS) do a very good propag^developer releations job, IMHO way better than Apple ever did (in the last 10 years).

speps 11y ago

Why is everyone talking about CocoaPods where the title is CoacoaPods anyway? :)

rtkwe 11y ago
The title was misspelled and has been fixed. It's CocoaPods right on Github.

kodablah 11y ago

Has any consideration been given to Bintray[1] as an alternative store for this stuff? 1 - https://bintray.com/ https://bintray.com/

joeblau 11y ago

I just installed Cocoapods last night and tried to clone down the repo. It took about 5 minutes and I thought to myself "Is my 150MB/s connection slow?" This definitely clears up what was going on.

noahlt 11y ago

Go's package manager, `go get`, also downloads from GitHub. I don't know the details of how `go get` and CocoaPods work, but I would be interested in learning why one is unscalable and the other seems to work.

miralabs 11y ago
probably on separate repos which something like npm and bower does as well.
karaziox 11y ago
Because cloning the dependency is not the issue here. CocoaPods is keeping its index in a git repo that is updated by the user as a way to get the latest index. This is the repo that incur a lot of requests from everyone. Go get on the other hand doesn't keep any index. It just uses the url to download the dependency because of the mapping "url==project name" that exists with go projects.

debacle 11y ago

Why aren't the packages distributed? Composer is incredibly distributed and likely doesn't cause nearly the same headaches for GitHub. Seems like a poor design decision on the CocoaPods side.

donarb 11y ago
What package? My project may have a dependency on a specific commit that's between point releases. The problem is not packages, it's the index, containing 16000 subdirectories,
- debacle 11y ago
  So the packages themselves aren't part of the repository?
  - kmm 11y ago
    No, only references to the repositories themselves are. The total Specs repo is only 300 megabyte, which comes to about 18 kilobyte per package on average. It's still absolutely ludicrous to use git for it, or worse, to bother github with it.

tjdetwiler 11y ago

Rust's cargo does something similar, however it looks like they were much more conscious of git-scalability (ex: limiting the directories in a single level, only appending lines to files to make diffs small). https://github.com/rust-lang/crates.io-index https://github.com/rust-lang/crates.io-index

wycats 11y ago
For what it's worse, both of these characteristics indeed weren't an accident. At the time, I wrote a script that hammered git commits into a repository using different strategies and looked at what the git repository would look like after 100,000 and a million commits. The "one version per file, nested in a flat structure" had serious issues. There may still be scaling limits with the Cargo approach, but if we reach them, we have plans to create a new registry with a new initial commit and let the old registry age out, then rinse/repeat. At the moment, we haven't hit limits yet (with about 1/3 of the packages that Cocoapods has).

mikeash 11y ago

The criticism against CocoaPods here seems awfully harsh. Think about it from their perspective. GitHub advertises a free service, and encourages using it. Partly it's free because it's a loss leader for their paid offerings, and partly it's free because free usage is effectively advertising GitHub. CocoaPods builds builds their project on this free service, and everything is fine for years. Then one day things start failing mysteriously. It looks like GitHub is down, except GitHub isn't reporting any problems, and other repositories aren't affected. After lots of headscratching, GitHub gets in touch and says: you're using a ton of resources, we're rate limiting you, you're using git wrong, and you shouldn't even be using git. That's going to be a bit of a shock! Everything seemed fine, then suddenly it turns out you've been a major problem for a while, but nobody bothered to tell you. And now you're in hair-on-fire mode because it's reached the point where the rate-limiting is making things fail, and nobody told you about any of these problems before they reached a crisis point. It strikes me as extremely unreasonable to expect a group to avoid abusing a free service when nobody tells them that it's abuse, and as far as they know they're using it in a way that's accepted and encouraged. If somebody is doing something you don't like and you want them to stop, you have to tell them, or nothing will happen! I'm not blaming GitHub here either. I'm sure they didn't make this a surprise on purpose, and they have a ton of other stuff going on. This looks like one of those things where nobody's really to blame, it's just an unfortunate thing that happened. (And just to be clear, I don't have much of a dog in this fight on either side. My only real exposure to CocoaPods is having people occasionally bug me to tag my open source repositories to make them easier to incorporate into CocoaPods. I use GitHub for various things like I imagine most of us do, but am not particularly attached to them.)

martinald 11y ago
I entirely agree with this. GitHub gets so much advertising + community from open source projects like this. Also, I'm amazed this is even a problem. 5 CPUs is not a lot in the scheme of things (even if they mean physical instead of cores). TBs of bandwidth are also virtually free compared to a company the size of Github. Even better: they are getting basically real world loadtested for free and finding loads of pain points, which may hit paying customers. Unless I'm missing something, fire more metal at the problem. Many companies would love to be able to have every single cocoapod user (which is nearly every iOS developer) have to type github.com into their terminal for the cost of a bunch of servers + some bandwidth. Pretty strange, unless this is hitting some really bad area of their service that can't easily be scaled out of (but i would be surprised)

iamleppert 11y ago

Amazing to me that people create inefficient systems like this and then complain when they are rate limited.

paradite 11y ago

I have been seeing this trend of GitHub getting "abused" for purposes other than hosting source code. - My school uses GitHub to host and track our software engineering project (which still can be argued as OSS). - People using GitHub issue system as a forum. - Friends uploading pdfs to GitHub. - Recently people posted on HN about using GitHub to generate a status page. I think this is a really bad trend and people should stop doing that.

WillAbides 11y ago
The school example and friends uploading pdfs to GitHub are both uses that GitHub encourages. Using GitHub Issues as a forum and a source for generating status pages are both ok from a use/abuse perspective, but you may not have the best experience since that isn't what Issues is intended for.
- takluyver 11y ago
  The issue tracker on new repos has a 'question' tag by default, so Github are gently encouraging using issues as a forum. Though my inner cynic says that makes sense for them - issues tie a project to Github more than the git repo itself does. It should be fine to come up with new ways to use Github, as long as it's not causing excessive load.

whitehat2k9 11y ago

Only the Apple development community would think it's OK to have 16,000 subdirectories in one place and abuse GitHub as a free CDN instead of putting some actual effort in and develop their own repository infrastructure - you know, like almost every other package manager in existence.

mayli 11y ago
It should be "Apple or Ruby development community", homebrew is using similar tech stack distributing the `Formula`.
- whitehat2k9 11y ago
  I guess it's no coincidence that those two hispter communities are closely related.

fpgaminer 11y ago

GitTorrent: http://blog.printf.net/articles/2015/05/29/announcing-gittorrent-a-decentralized-github/ http://blog.printf.net/articles/2015/05/29/announcing-gittor... Imagine a world where GitTorrent is fully developed, includes support for issue tracking, and has a nice GUI client that makes the experience on-par with browsing github.com. I mention this not as an "Everybody bail out of GitHub and run to GitTorrent!!!" sort of statement, because I believe GitHub's response here was excellent and confidence inspiring. But it's an unnatural relationship for community supported, open source projects to host themselves on commercial platforms such as GitHub. GitHub primarily hosts them to promote its business. That's not necessarily a bad thing, but it results impedance mismatches like demonstrated here. That isn't to say that a mature GitTorrent would replace GitHub. Rather, I envision GitHub becoming a supernode in the network, an identity provider, and a paid seed offering, all alongside their existing private repo business. Honestly, once I scrape a few projects off my plate, I'm inclined to dive into GitTorrent, see where it's at in development, and see if I can start contributing code. It just seems like such a cool and useful idea.

cyphar 11y ago
My main issue with Free Software projects using GitHub is that it's proprietary, not that it's commercial. Admittedly, I think GitTorrent is a really cool idea, but I'm wondering if a distributed filesystem might be a more elegant solution than using both BitTorrent and Bitcoin.

maaku 11y ago

Using Github as your CDN is a dick move. Kudos to GH for not banning the project out-right, but CocoaPods should seriously reconsider what they are doing.

Const-me 11y ago

I don’t think GitHub acts wisely here. Short term sure, they’re doing the right thing, implementing a nice way to manage the free rider problem without hurting them too much. But long term it’s different. Financially, one average programmer = $80k/year, one average cloud server = $4k/year. And, GitHub has hundreds of millions of venture capital. More than enough to provision a few more servers, even if they will be installing new servers just for those pods. The way they act now will lead to someone will develop a decentralized git+torrent hybrid. When that happens, sure, those pods will no longer consume precious GitHub’s resources. However, for the rest of the github users, there will be no reason to stay on GitHub either.

cyphar 11y ago
The way CocoaPods is using git is bad, so they'd probably run into some problems no matter how they host it. If you know anything about filesystems, they start to have pathologies when you have many entries in the same directory (which is why git has it's object store in the format prefix/object). In addition, it looks like git has it's own pathologies with such large numbers of dentries. Having 16000 entries in your "specs" directory is not a good idea. No matter how you store it. Not to mention that "just buy another server for this one project" sounds like something CocoaPods should pay for.
- Const-me 11y ago
  >The way CocoaPods is using git is bad Very likely true, but I don’t see how’s that related. >they start to have pathologies when you have many entries in the same directory Only true for inefficient filesystems like FAT. For NTFS, 16k entries is nothing, the performance fill start to degrade (due to directory fragmentation) at around 100k entries: http://stackoverflow.com/a/291292/126995 http://stackoverflow.com/a/291292/126995 >"just buy another server for this one project" sounds like something CocoaPods should pay for. I don’t think that’s how 21 century economy works in this case. Github’s value is likely between $0.75B and $2B. Bad PR caused by this story will exceed 10 years TCO of that extra server.

rcthompson 11y ago

Reading the issue, it seems that one of the problems is a single directory with lots and lots of files in it, which is something of a pathological case for Git. Now, this could be "fixed" by splitting the files in that directory into subdirectories, but the one giant directory will still exist in all the past commits. So would this actually fix anything, or just keep it from getting worse?

cyphar 11y ago
Filesystems also have the same pathology, which is why git's object store is of the form prefix/object.
- rcthompson 11y ago
  In a filesystem, you can address the problem by reorganizing the directory structure. And you can do the same for future Git commits. But unless I'm mistaken, that colossal directory is stuck in the git history unless you actually rewrite that history, which would require everyone who cloned the repo to either rebase or re-clone the repo. Maybe it's not a problem because the cost is only paid when one checks out one of those old commits, which would happen rarely?

kmm 11y ago

Funny thing is that the repo is only 7 MB gzipped (or 4 with lzma). Not that surprising, since it's just metadata of course. They say they have about 1 million fetches/clones per week, so that would make about 16 TB per month. I'm not sure how much bandwidth costs, but wouldn't some sympathetic CDN host that for free, since they're OSS?

voltagex_ 11y ago

It's difficult to run an open source project on a budget of $0. You're always relying on the goodwill of others.

rdancer 11y ago

tl;dr: "Using GitHub as your [free-of-charge] CDN is not ideal, for anybody involved."

LoneWolf 11y ago

While I do not have much knowledge on the subject, why not using rsync?