281–290 of 297 posts
Earlier quoted context omitted.
If you listen closely you can hear the sound of all bower-dependent builds on earth failing in synchrony
why only bower-dependent?
Earlier quoted context omitted.
Been there. Done that. No backups. Recovered all the data by using open file handles in /proc/. Not a fun two hours. Shit happens. Live and learn.
Have you written a blog post about that /proc/ trick? sounds like an interesting read
Earlier quoted context omitted.
I didn't say it was solved, but they are very close. IPFS is essentially a global p2p git repo, with a cryptographically controlled branch namespace.
That sounds very cool. I was just pointing out how divorced these ideas still are from the way we actually program and implement things on the web. In an ideal world, a link to a source code repository (or a link to anything for that matter...) would never fail because there would be automatic mirrors to at least provide read-only access to it. It sort of forces one to ask whether this is the result of fundamental mi…
Earlier quoted context omitted.
Companies/people don't learn on their mistakes. Almost everything is on GitHub nowadays. This makes it a SPOF even if Git itself is distributed. More companies should host their projects on premises. There are good open source alternatives to GitHub: Apache Allura, Fossil, GitBucket, GitLab, Phabricator, and Redmine.
... GitHub Enterprise ...
"We're investigating a significant network disruption effecting all http://github.com services." - https://twitter.com/githubstatus/status/692508939792039936
> effecting all http://github.com services Guess they're too busy working on the issue to notice the misuse of "effecting" instead of "affecting."
Apparently they can see into the future and know for a fact that they'll still be having issues in a few hours. January 28, 2016 00:00 EST The status is still red at the beginning of the day January 27, 2016 20:02 EST We're continuing to investigate a significant network disruption affecting all github.com services.
... or you're in a different timezone. It's 11am on the 28th where I am.
Earlier quoted context omitted.
I did that too. Destroyed out Zabbix database. Neither that Zabbix server, nor the other one monitoring the server I destroyed, could alert us that anything had gone wrong for over an hour. I finally realized it when I couldn't login... I was able to painstakingly rebuild the server after 9 hours without anyone noticing. To this day one of my biggest fuck ups and prouder accomplishments.
Are you saying that once you break something, you should break your monitoring as well, but do it very quickly since it may be too late? :)
Earlier quoted context omitted.
Yeah, I am confused by the existence of a status report for a time 3.5hrs in the future. Guess they're just trying to get ahead of the game and set some realistic expectations.
Maybe it's GMT mistakenly labeled as PST?
Earlier quoted context omitted.
That sounds very cool. I was just pointing out how divorced these ideas still are from the way we actually program and implement things on the web. In an ideal world, a link to a source code repository (or a link to anything for that matter...) would never fail because there would be automatic mirrors to at least provide read-only access to it. It sort of forces one to ask whether this is the result of fundamental mi…
Content addressed links at least make this possible. With http you have to reach a particular server. If that server is down, the link is broken. With ipfs all you need is at least one machine on the entire network to be serving a file and the link will work and as an added bonus you can verify the hash of what you get so a mitm attack on that link is impossible.
