GitHub 的新文本编辑器并不完全开源,看起来并没有人在意这一点。 Samuel Greenwald 认为“任何 IT 领袖如果没有开源观念,那注定会失败。” 然而即使你的开源观念打了折扣、不那么纯粹,其实大众也并不会刁难你。特别是在你祭出古怪反复的许可证花招时,即使是开源界最精明的精英也可能被忽悠住。 例如就拿GitHub来说。GitHub 刚刚发布了Atom文本编辑器,获得了很多赞赏。虽然有
以我的经验来看,刚接触Git和GitHub时,最困扰的一件事情就是尝试解决下面的问题:在Git和GitHub上,我能做什么? Git教程往往不会解决这个问题,因为它集中篇幅来教你Git命令和概念,并且不认为你会使用GitHub。GitHub帮助教程一定程度上弥补了这一缺陷,但是它每篇文章的关注点都较为狭隘,而且没有提供关于"Git vs GitHub"问题的概念性概述。 如果你是习惯于先理解概念,
构建一个健壮的系统需要为故障而设计。作为 GitHub 的网站可靠性工程师(SRE),我们一直在寻求通过冗余来帮助缓解问题,今天将讨论最近我们所做的工作,以便支持你通过 DNS 来查找我们的服务器。 大型 DNS 提供商在其服务中构建了多级冗余,出现导致中断的问题时,可以采取措施来减轻其影响。最佳选择之一是把你的 区域 zone 的权威服务分割到多个服务提供商中。启用 分割权威 split aut
在 GitHub,我们最近从头改进了 DNS。这包括了我们如何与外部 DNS 提供商交互以及我们如何在内部向我们的主机提供记录。为此,我们必须设计和构建一个新的 DNS 基础设施,它可以随着 GitHub 的增长扩展并跨越多个数据中心。 以前,GitHub 的 DNS 基础设施相当简单直接。它包括每台服务器上本地的、只具备转发功能的 DNS 缓存服务器,以及一对被所有这些主机使用的缓存服务器和权威