Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

CocoaPods downloads max out five GitHub server CPUs

github.com

Post reply on HN
Print view View original

291–300 of 320 posts

Re: CocoaPods downloads max out five GitHub server CPUs

#291

Post by jscampbell05 »

odbol_ wrote: post #223
nostrademons wrote: post #100

Earlier quoted context omitted.

Well, the flip side is that the CocoaPods developers are all volunteers (right?). They aren't really deriving any benefit out of the work they do on CocoaPods, and if you ask them to take on financial or ongoing maintenance obligations for a volunteer project, they probably just won't do it. The major benefits of CocoaPods existence go to iOS developers, but there's a tragedy of the commons effect here, where no indi…

Ugh, I'm skeptical of giving Apple ownership of any kind of developer tool. We all saw how badly they screwed up TestFlight, and now you want to give them the only OSS package manager?

Amen to that. Fortunately the Swift Package manager (Which is also OSS) is ran by their open source swift team who so far is doing a great job of being open and delivering the best solutions for the job.

TestFlight on the other hand....

Re: CocoaPods downloads max out five GitHub server CPUs

#292

Post by [deleted] »

barkingcat wrote: post #181
ragall wrote: post #179

Earlier quoted context omitted.

If you plan to rehaul Homebrew, I suggest having by default 3 operations, "update", "fetch" and "install" because some people might find themselves in the situation of having bad connectivity(especially low bandwidth) and being able to fetch the sources, to compile later is very important. Especially having "install" issue synchronous "update" operations is bad if you're on a network with high packet loss, like tethe…

I know you're trying to suggest some good ideas, but never having used homebrew I think you should find out more about homebrew itself before suggesting things. I don't mean you have to be an expert at it, but just to know a bit about how it's used, and who it's used by before trying to suggest things to people. My comment isn't to pass judgement on your suggestion, but if you took a look at homebrew itself you'd be…

[deleted]

Re: CocoaPods downloads max out five GitHub server CPUs

#293

Post by mikemcquaid »

ragall wrote: post #179
mikemcquaid wrote: post #126

Earlier quoted context omitted.

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 plan to rehaul Homebrew, I suggest having by default 3 operations, "update", "fetch" and "install" because some people might find themselves in the situation of having bad connectivity(especially low bandwidth) and being able to fetch the sources, to compile later is very important. Especially having "install" issue synchronous "update" operations is bad if you're on a network with high packet loss, like tethe…

We do actually do that: `brew update`, `brew fetch` and `brew install` commands are separate. If you haven't already fetched the sources `brew install` will do them for you. What I'm considering is also making it do `brew update` for you too.

Re: CocoaPods downloads max out five GitHub server CPUs

#294

Post by mikemcquaid »

manyxcxi wrote: post #286
mikemcquaid wrote: post #126

Earlier quoted context omitted.

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…

Thank you for everything you do at Github and with Homebrew.

And thank you for taking the time to share some kind words.

Re: CocoaPods downloads max out five GitHub server CPUs

#295

Post by manyxcxi »

jenscow wrote: post #180
jethro_tell wrote: post #168

Earlier quoted context omitted.

Dabbling in the 'kind of customer we can afford to lose' territory.

Not really. Imagine the backlash github would receive here.

> Not really. Imagine the backlash github would receive

I don't know... I'm sure they'd get some, CocoaPods has a very large user base after all. But if GitHub laid out the reasons like they laid out the options to start this thread, I think they'd weather the storm fine and diffuse some people who show up to be angry.

I could see why GH would drop them and think they'd be well within their right and in good moral standing in my book. I just don't think they would unless the maintainers became incredibly hostile or proved unable to fix the problem or even band-aid it. GH just seems too culturally invested in making things like this work to a satisfactory conclusion. I have a feeling that the CocoaPods team will be schooled in a lot of things directly from the GitHub team as they work to resolve the performance issues, just look how informative the initial post was.

Re: CocoaPods downloads max out five GitHub server CPUs

#296

Post by mianos »

accatyyc wrote: post #288
mianos wrote: post #259

Earlier quoted context omitted.

"This repository experiences a huge volume of fetches (multiple fetches per second on average). We understand that part of the CocoaPods workflow is that its end users (i.e., not just the people contributing to CocoaPods/Specs) fetch regularly from GitHub"

Yes, but he means that "end users" of CocoaPods are actually developers. It's a package manager for libraries.

Actually, in the text, I guess no one voting me down has actually read it, he pretty clearly defines the developers as the people who contribute to the packages, not the people who download and use them. It's like saying, as an IDE user, you are a developer of the project, you are not, you are an end user of a developer product. The end users, in this case, software developers, are using it as a CDN. It's pretty clearly stated in multiple places, github is not a CDN.

Re: CocoaPods downloads max out five GitHub server CPUs

#297

Post by SlashmanX »

mianos wrote: post #296
accatyyc wrote: post #288

Earlier quoted context omitted.

Yes, but he means that "end users" of CocoaPods are actually developers. It's a package manager for libraries.

Actually, in the text, I guess no one voting me down has actually read it, he pretty clearly defines the developers as the people who contribute to the packages, not the people who download and use them. It's like saying, as an IDE user, you are a developer of the project, you are not, you are an end user of a developer product. The end users, in this case, software developers, are using it as a CDN. It's pretty clea…

Except the original quote in this comment chain was "Discounting the fact that CocoaPods is used by millions of iOS developers." so that's what 'developers' was referring to in the comment you originally replied to

Re: CocoaPods downloads max out five GitHub server CPUs

#298

Post by cballard »

odbol_ wrote: post #223
nostrademons wrote: post #100

Earlier quoted context omitted.

Well, the flip side is that the CocoaPods developers are all volunteers (right?). They aren't really deriving any benefit out of the work they do on CocoaPods, and if you ask them to take on financial or ongoing maintenance obligations for a volunteer project, they probably just won't do it. The major benefits of CocoaPods existence go to iOS developers, but there's a tragedy of the commons effect here, where no indi…

Ugh, I'm skeptical of giving Apple ownership of any kind of developer tool. We all saw how badly they screwed up TestFlight, and now you want to give them the only OSS package manager?

If you're upset about Apple TestFlight, why not just use HockeyApp?

Re: CocoaPods downloads max out five GitHub server CPUs

#299

Post by [deleted] »

mynameisvlad wrote: post #48
orclev wrote: post #45

Earlier quoted context omitted.

It seems particularly galling that their response to GitHub was to essentially throw their hands up and say "We don't want to change anything, fix it for us". I think GitHub had a near perfect response to this, they analyzed the problem, came up with a set of changes that could be made to help fix it (both short and long term), and pointed to steps they've taken to help out. CocoaPods on the other hand (or at least o…

Yeah, I'd have to agree. I was not at all impressed by the CocoaPods response here, especially since it was made clear by the GitHub staff that CocoaPods is using up a lot of CPU and terabytes of bandwidth. If you get all that for free, I'd expect you to be a little more open to changes that make it easier for your provider to continue giving you all that for free.

[deleted]

Re: CocoaPods downloads max out five GitHub server CPUs

#300

Post by onli »

nickpsecurity wrote: post #240
tptacek wrote: post #139

Earlier quoted context omitted.

I don't know, it sounded to me like he just didn't totally understand what Github was saying. By the end of the thread, it seemed like everyone was agreeing. I wouldn't be comfortable using words like "selfish" to describe any of what I read. I certainly don't think the barb about your willingness to employ people who write things on Github issues threads that you disagree with is helping anyone understand any part o…

Really? Alloy specifically said they were blasting a free service's infrastructure for their own benefit. Told about the issues, the response was basically Alloy et al wanted to invest no time or money into a better situation. Even cited HR and funding benefits. That's selfish to the point that it could be a textbook example of an externality. Fortunately, like you said, things got agreeable by the end with Alloy tak…

> Told about the issues, the response was basically Alloy et al wanted to invest no time or money into a better situation.

That's actually not true.

https://github.com/CocoaPods/CocoaPods/issues/4989#issuecomm... is the answer we are talking about, aren't we? What alloy is doing there is:

1. Thanking mhagger for the response

2. Asking for additional explanations

3. He explains then why the project is taking the route they took, the benefits for them. Explaining alone does not mean unwillingness to change. It just makes sure it is clear why it is like it currently is. Yes, that mentions the time and money benefit, but so what – it's honest, and it is valid to limit expectations on what is possible now.

4. He then indeed asks for a discussion on how to improve the current system without changing it completely. But this does not mean not investing time, to the contrary: He actively invites a continuation of a discussion and already there makes clear that he is indeed willing to work on a better solution, and that is the core point making this a constructive answer.

How the discussion continues in my eyes clearly shows that the negative interpretation of this first answer, in your comment and this thread, is wrong. That's not someone blocking change, not even at first, that is someone asking for clarification and even clearer tasks to do. That's not a bad thing at all.

Post reply on HN