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

181–190 of 320 posts

Re: CocoaPods downloads max out five GitHub server CPUs

#181

Post by barkingcat »

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…

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 able to make better non-generic suggestions.

Re: your suggestion - It's a generically seemingly good thing to separate out fetch from install, but as a user of homebrew, it's not very applicable because when homebrewing things you're likely already connected to the internet, and it's hard to predict when you want to brew install something before hand. If you have the internet capacity to fetch something, it'd be just as easy to brew install it there on the spot.

By extension, it's important to run brew update before installing just to make sure the package index is up to date, so I agree with the dev above, integrating brew update step before brew install would be a good thing - except - perhaps print out on console the exact version number that's going to be installed. Current behaviour does put the version # in the file name of the package being installed, but it could be listed in a more obvious way.

Often times I do a brew info, find the version and details on it before brew install. If the installation step then installs a new version (because of the brew update step), then it's a bit strange that I didn't get the version I was intending to get.

Re: CocoaPods downloads max out five GitHub server CPUs

#182

Post by whitehat2k9 »

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.

Re: CocoaPods downloads max out five GitHub server CPUs

#183

Post by WillAbides »

paradite wrote: post #171

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 s…

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.

Re: CocoaPods downloads max out five GitHub server CPUs

#185

Post by jallmann »

seanalltogether wrote: post #91
Moto7451 wrote: post #66

Earlier quoted context omitted.

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.

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.

> 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.

Re: CocoaPods downloads max out five GitHub server CPUs

#186

Post by ragall »

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…

It's not always that easy, I've found myself having to go to a place with high-bandwidth internet to fetch stuff, and being able to stay there only a few minutes. Or before boarding a plane(you don't really want to pay for internet on an intercontinental flight), etc... Also, while you might do things as-needed, it's not that difficult to always remember to run an update every time you run brew. And I wasn't even proposing to make it the default, just to make it possible to run those 3 things separately.

Re: CocoaPods downloads max out five GitHub server CPUs

#187

Post by [deleted] »

ragall wrote: post #186
barkingcat wrote: post #181

Earlier quoted context omitted.

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…

It's not always that easy, I've found myself having to go to a place with high-bandwidth internet to fetch stuff, and being able to stay there only a few minutes. Or before boarding a plane(you don't really want to pay for internet on an intercontinental flight), etc... Also, while you might do things as-needed, it's not that difficult to always remember to run an update every time you run brew. And I wasn't even pro…

[deleted]

Re: CocoaPods downloads max out five GitHub server CPUs

#188

Post by avar »

toomuchtodo wrote: post #111
aikah wrote: post #43

Earlier quoted context omitted.

When a package manager monopolizes that much resources from Github at the expense of others there is no reason to "commit" all resources to this one project. Thus cocoapods getting rate limited because of the obvious bandwidth abuse going on here. mhagger answer is pretty straight forward. EDIT: the upside is that cocoapods will have to either rethink there architecture in order to eat less resources or move to their…

> EDIT: the upside is that cocoapods will have to either rethink there architecture in order to eat less resources or move to their own paid infrastructure because their package manager will soon be less than functional given the aggressive rate limiting github is performing. I'd like to see both happen: * CocoaPods refactoring to be more efficient * GitHub providing open source projects the option to buy reserved ca…

    > GitHub providing open source projects
    > the option to buy reserved capacity.
I have no affiliation with GitHub, but I'd guess that if you were paying for one of their $200/month organization plans[1] you'd be having a very different conversation with them about rate limiting.

1. https://github.com/pricing

Re: CocoaPods downloads max out five GitHub server CPUs

#189

Post by knorker »

manyxcxi wrote: post #116
onli wrote: post #2

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 (an…

I was astonished at how selfish/myopic/whatever alloy's response was. To be blunt, you're abusing the shit out of SOMEONE ELSE'S product that you're not even paying for. Your first question shouldn't be to see what Github can do for you to make it so you don't have to make changes. You should be falling over yourself investigating all available avenues for reducing load. It's an incredibly entitled way to think about…

Yeah. "That's your problem, and we don't want to change anything because that's a non-zero cost for us just to fix a cost on your side."

And what the hell was with the quotes around "free"? Are you paying? No? Then there's no quotes about it.

Re: CocoaPods downloads max out five GitHub server CPUs

#190

Post by fpgaminer »

GitTorrent: 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.

Post reply on HN