3 ms·
> Consider self-hosted alternatives like I have said before. This assumes that your self-hosted Git service will have better uptime than Github.
by toomanybeersies 5y ago
> Consider self-hosted alternatives like I have said before.
This assumes that your self-hosted Git service will have better uptime than Github.
- 1337shadow 5y ago> This assumes that your self-hosted Git service will have better uptime than Github. Piece of cake. But it will also have better performance.
- detaro 5y agoNot even that necessarily, control of downtime is also worth something. i.e. lots of downtime is tied to system changes/updates, especially in a conservative setup, which you can schedule as appropriate on a self-hosted setup.
- rightbyte 5y agoYe ... I mean most messups happen when stuff is changed, which you can choose to not to do on a release day etc.
- rvz 5y agoSomeone said the same thing to me more than a year ago [0] and here we are the same issues once again. This is why it makes no sense to go 'all in' or try to "centralize everything to GitHub". At least (if you're a company or an organisation) have a self-hosted backup and don't jump into the 'goin all in' hype train. [0] https://news.ycombinator.com/item?id=22868406 https://news.ycombinator.com/item?id=22868406
- toomanybeersies 5y ago> This is why it makes no sense to go 'all in'... I completely agree with you, to reiterate what I said last time we had this discussion 3 months ago: > I wouldn't call it prudent to go all-in on any cloud service [0] I've never used Github as anything more than a managed git service with a nice web interface. At work, any time the topic of moving our CI/wiki/project management/issue tracking onto GitHub has come up, I've been vocally opposed. If GitHub went down, and didn't come back up, it would be trivial to migrate to Gitlab/CodeCommit/Bitbucket. The most time consuming thing would be setting up new web hooks for our CI. [0] https://news.ycombinator.com/item?id=26302232 https://news.ycombinator.com/item?id=26302232