What If GitHub Is the Devil?
daniel.haxx.se
daniel.haxx.se
> We could bounce back on a new platform and development would go on within days.
But agreeing on a platform takes longer, so might as well build up some alternatives now.
I think this completely misses Daniel's point. He's not talking about centralization.
Discovery is based on network effect and network effect alone: that can be present in a centralized / federated / decentralized system; the only question is which of these systems currently owns the network effect.
In this case, it's inarguably Github.
One could argue that curl has a bit enough following that they "use their influence for good" that's a different prerogative based question.
> But agreeing on a platform takes longer, so might as well build up some alternatives now.
Alternatives are easy to find, and perhaps more importantly, they come and go. If you're not planning on migrating immediately, looking at the current set of alternatives is a waste of time; they may change.
So apparently the EUGDPR doesn't mean shit when you're Microsoft.
This corrupt system is pissing me off.
This also made me delete all my accounts associated with Microsoft, like LinkedIn etc. Microsoft is evil and so is Google. They need to be broken up into smaller parts. They have too much power.
What also happened was Google then actively went after my adsense earnings. All of a sudden I received warnings and sites being deactivated for monetization. The webmaster console also started showing errors and my sites were delisted!
Because I didn't take no for an answer when Ian Lance Taylor spoke the verdict of God on the documentation needing a more readable font?
Fuck github and Microsoft and Google
Actually, running gitlab on a ubuntu server is a no brainer, upgrading is as simple as running apt upgrade -y every couple of weeks or something (gitlab's packages run their chef recipes under the hood), uptime will most certainly be on-par with github, and probably even better which is our case.
Time to clone, fetch, push, will be much faster, it's common to find dedicated servers with at least 100Mbps of dedicated bandwidth. CI will be much faster too because dedicated, you will have no wait time, so you easily get back the little time that you have spent running apt upgrade.
> we would lose the “network effect”
You can still have github mirrors, gitlab supports it fine, it's what we do, also, gitlab supports auth via github, gmail and whatever, so you don't have to require a new username/password setup to use your instance.
> We would also lose the easy integration with cool services like the many different CI and code analyzer jobs we run.
If you want CI beyond docker, ie. on windows and macos, which I suppose would be the case for most major projects, then I believe self hosting will be a bit harder. However, for docker based CI then gitlab ci runner is extremely easy.
For code analyzers it's lagging a bit behind github I believe but you know, we were already using those before they became available as github services: just add a linter and a static analyzer such as for security or to compute mccabe indexes in CI jobs it still works well. For coverage you can just generate HTML and copy it in a public artifact that gitlab pages will serve, same for documentation.
So for me, these arguments against self hosting seem a bit weak, there is one that would seem stronger but is not mentioned: someone would actually have to pay for the server. My conclusion is that GitHub's best feature is that you don't have to pay for anything, which I can understand would overweight the fact that it's sub-optimal on every other aspect for a lot of OSS hackers.
Nice article though, even though I enjoy the benefits of running open source services on dedicated servers because I get my time back everyday I interact with the said service, I would definitely not go as far as "github is the devil" or something, it's just not my favorite solution, by far, but it's still pretty cool to have amongst the many choices for code hosting!
If this is your conclusion, I don’t see how you’ve come to it based on what you wrote.
Gitlab might be a no-brainer to run on your own server, but you still have to maintain it, patch it and put it back in case the server stops working. It might never happen in practice, but it’s a risk. And in practice, the cost of a small/medium server on a VPS is anyway the same (or higher) cost you would pay for a paid plan on Github which comes with much better uptime overall.
> Time to clone, fetch, push, will be much faster, it's common to find dedicated servers with at least 100Mbps of dedicated bandwidth
This depends on the number of users who use your Gitlab instance. It would not be the case for medium sized companies. For your own use case, fine. But for a project like curl? That might be pulled constantly from all around the world?
GitHub best feature is, actually, the amazing user experience it provides, which is often overlooked and compared against the myriad of features Gitlab provides - despite Gitlab being way, way less user friendly than Github.
As for user friendliness I prefer gitlab but I get your point, UX would be a bit better for certain types of users in GitHub but a bit better for other types of users in GitLab.
I do understand your point about bandwidth, because in Europe we get great, cheap, unmetered bandwidth, which is something that I don't ever see on american providers on cheap servers, even on oneprovider.com, but on scaleway you do get unmetered bandwidth from 200 to 500 Mbit/s for 7.20€/month here https://www.scaleway.com/en/virtual-instances/development/ however, this small instance might not run gitlab really well, you should go for Gitea if you were to self host a git server on this server. Anyway, I mean that I get that Americans and Europeans don't have the same relation with bandwidth.
So of course, everything is going to depend on many external factors. YMMV for sure, but just for the sake of the example I have tried cloning curl from both github.com and my gitlab server: it's 1m52.233s vs 1m30.256s that's probably a 20% difference. It's true that GitHub has made a lot of efforts to improve speed because it used to be a lot worse.
For you 20% might not be a lot, or even meaningless, but I really spend a lot of time pushing and pulling across a bunch of repos, say 30 minutes a day 22.5 days a month, that's 135 minutes I make a month, considering I spend around two times 10 minutes per months running the server upgrade, I'm left with a benefit of 115 minutes per months, that's 23 hours a year: a complete day, and 9.6 days after 10 years ... sorry, I would understand this seems far fetched to you, I plead guilty to being the kind that optimizes this kind of things on the long term, a Lean Sensei.
BUT, I have paid for my server, so really, that'd be the only downside from my POV.
As for the git usage of the curl project, what I got from github insights is, for the last 24h: Excluding merges, 2 authors have pushed 5 commits to master and 5 commits to all branches. On master, 7 files have changed and there have been 153 additions and 38 deletions.
I don't /feel/ like they'd be saturating 100Mbps.
And there's also self hosted CI, I just can't live with non-dedicated CI hardware, can't wait, can't stand even paid hosted CI, too slow, and my devs also love that CI just instantly "jumps" on their patches to start crunching them. Because CI is on a simple dedicated server, docker cache also just works without the network bottleneck. But then again, keep in mind I'm not talking about "big corporate setups" here, if you have hundreds of devs then it's not the same story.
I maintain our big companies githib enterprise host and we are working on finally convincing security to let us move to github.com. There are more features there and it's one less thing my team has to maintain or risk dealing with downtime. Let the experts do that, it's cheaper and more reliable in the end.
As for "let the experts do that", you really make it sound like running a service on a linux box is something "for experts" which clearly is a fallacy. Unless you mean that "running nmap to check that your firewall works is something for experts", not sure where you place the bar for what you call "experts", is making a systemd service or timer or starting a container better left to "experts" ? I'm sincerely wondering what the criteria are in the definition of "expert" in the Hacker News standard.
Hosting a version control system on his own vs just git cloning and pushing to github.com is more work. He doesn't want that. That's really all it is.
Copy and paste to avoid the referral-based content.