5 ms·
Just look at git adoption. Git's selling point is that it's decentralized and distributed... but just look at the shitshow that happens whenever GitHub goes do
by amyjess 5y ago
Just look at git adoption.
Git's selling point is that it's decentralized and distributed... but just look at the shitshow that happens whenever GitHub goes down. Git may allow for developers to all pull from each other, but in practice your employer will always have a canonical repo that's blessed as the official source, and if that one becomes unavailable for any reason work grinds to a halt. And that goes double if your company's deployment process is tied to GHA.
- greyhair 5y agoSmall organizations use github. Really large organizations have their own git servers. I have worked on both sides of that.
- amyjess 5y agoI used to work for a company that used on-prem BitBucket. And even there, "Stash is down" caused development to grind to a halt. Yeah, sure, our outages weren't synchronized with the rest of the world's outages, but the end result is the same: productivity depends on the uptime of our authoritative repo. That all the developers have clones of that repo on our own boxes is irrelevant... nobody's going to bother pointing our remotes at each other's workstations or reconfiguring Jenkins.
- threeseed 5y agoI’ve worked for a number of very large, enterprise companies. They use Github Enterprise. Even banks are moving to SaaS first for their core applications.
- spookthesunset 5y agoIt’s not really lack of repo access that makes GitHub outages bad. It’s all the “value-add” stuff on top of the repo that makes outages suck. You’ve got workflows bolted on top that block forward progress when it goes down. Hooks for when push requests happen, when commits happen, etc. You’ve got code reviews in your workflow that cannot happen when the service is down. Basically there is much more to a service like GitHub / gitlab than just “write code, commit”. These services enable powerful workflows. When those go down all you can do is write code locally. The rest of the pipeline is dead in the water, which in many cases makes your overall ability to work virtually impossible.
- oblio 5y agoAnd it's going to be the same with cryptocurrencies. All the interesting stuff for normal people is built on top.
- 0ldskool 5y agowell the case is that if github keeps going down and becomes completely unreliable you can take your decentralized code and more it to a different provider. Those other providers will also have value added stuff and you will not lose the core of your business/work (your source code). If it was a pure central authority + protocol you would be doomed to live and die with them. Imagine if instead of git + github you had some source code protocol that only allowed you to checkout the latest commit of some branch. All code history needed to be viewed by connecting to the central servers. Why not make it even worse, you could only view+edit a specific file of the latest commit on your machine. All other files must live on the central server, you are not allowed to build/compile code locally either... Centralization is the process of you giving up control to a "trusted" entity. If they fail you lose everything
- oblio 5y agoOk... how does that help cryptocurrencies, though?
- NationalPark 5y agoI think that's mainly cultural, actually. "Github is down" is seen as "take the day off". But it actually is pretty easy to work around a remote being temporarily down. Developers can use their local copies of code and merge them when the remote is back up. Or whoever has the latest commits can start a temporary git server in an EC2 instance and tell the developers on slack to update their remote URLs. Of course, if your build process is tied into github actions or something, that will still be broken. But that problem also exists for any other 3rd party build/deploy service you might use, independent of git-the-VCS-tool.
- amyjess 5y ago> I think that's mainly cultural, actually. Yes, that's my point. It doesn't matter if your protocol is decentralized as long as your business processes rely on having a blessed authoritative repo, which most do. Yes, you can point your remotes somewhere else, but in practice nobody bothers.