一种情况是一楼说的 Content-Length, 还有一种是 Transfer-Encoding=chunked
详见 https://zh.wikipedia.org/wiki/%E5%88%86%E5%9D%97%E4%BC%A0%E8%BE%93%E7%BC%96%E7%A0%81

这种不可逆、不可冻结的代价就是整个比特币系统必然是低效的，就好像一个充分民主的社会也必然是低效的一样。

SQL 可以说是一个标准，实现了 SQL 的数据库在核心概念上都差不多，可以说是过去很多年前辈们所实践出的适用于大多数场景的解决方案；但 NoSQL 的概念可能就千差万别了，分别适用于各种具体的情况。

想请问作为固态硬盘，是否有比机械硬盘更好的抗震和抗跌落性能呢？

我现在觉得可能编译执行和解释执行是一个程度问题，取决于语言的设计和实现上，在编译阶段和运行阶段之间建立了多么强的抽象或隔离。

默默地继续往 Github 上传密码（ https://github.com/jysperm/passwords ），如果对浏览器插件没那么高要求， Git + PGP 绝对是值得信赖的技术。

@AirSc 青云香港节点

用 Vagrant 的话可以考虑把所有初始化开发环境的脚本都写到 Vagrantfile 里，然后连带各种资源和配置文件一起放到一个 Git 仓库里，这就是使用 Vagrant 的意义呀。

说到这个话题，我还有一个想法，就是写一个爬虫去检查域名的过期时间、 SSL 证书的过期时间，然后给域名的管理员（如果 whois 信息中有的话）发邮件提醒，邮件中可附带域名和 SSL 的推广链接，也许可以赚点小钱。

我觉得还是应该彻底抛弃「密码」这种设计，而转用高强度的密钥来进行身份认证，现在密钥无法投入使用的原因我觉得主要有两个：一是容易泄露，密钥也需要作为一个文件被存储在电脑或手机（下面简称设备）中，这意味着设备上的第三方程序也可以访问你的密钥，如果为密钥设置密码的话，就不符合前面抛弃密码的初衷了；二是容易丢失，按照一般的原则，密钥不应当在设备之间传输，因此一旦设备故障，就彻底失去了其中存储的密钥，如果设备丢失则密钥将会落入他人手中。

我也有一些想法来解决这两个问题：一是操作系统甚至硬件来提供密钥相关的基础设施，例如将密钥存储在难以复制的设备上（例如类似 SIM 卡的芯片），操作系统提供访问密钥的接口，密钥自始至终不经过用户空间，硬件上提供指示灯或物理按键，以便用户确认访问密钥的行为是否是操作系统发出的。

至于丢失的问题，我觉得现在很多人都有至少两个以上的设备了，甚至我有五个智能设备，用户可以将这些设备（也可以关联家人和朋友的设备）关联起来，设置「同时使用我的手机和电脑可以吊销 iPad 的密钥」、「同时使用我父母和某个朋友的设备可以重置我的某个帐号的密钥」之类的。

当然我这个脑洞开得有点大，其中涉及到软件和硬件的重新设计、标准的建立之类的，基本希望不大了。

@djyde 今天听了差不多一半，还是非常看好你们的，也想有机会加入你们，虽然我的前端经验甚少，不过 Node.js 也算 JavaScript 嘛（而且似乎你们的节目确实也提到了 Node.js ）。请问还有其他的联系方式么，比如邮件，我可以提供关于我的更多一些信息。

还没有听，我最近也有自己录一档播客的冲动，但最后还是没有行动，所以看到你已经行动起来我还是挺高兴的。我之所以自己想录是因为最近在听几档中文的技术类播客，但我真的觉得内容上太水了，当然这并不能怪他们，因为毕竟他们也没说自己有干货。如果我来录的话，我希望每一期都是有提纲的、有口误和跑题的片段要剪辑掉、不聊提纲外且自己不了解的话题。虽然你也强调了可能没有「干货」，但我还是希望你能够认真地对待，不知道你怎么看。

@babytomas 是的， https://jysperm.me/2015/12/summary-of-2015 这篇日志的最后一段有讲

感觉可以直接换了，下次找工作慎重一些

可行是可行，但这是一种恶性循环，自动打码的技术越高级，就会有更加变态的验证码。的确有一些环节是需要缺人电脑前是一个真正的人的，所以还是更有效的人机识别方案才能治本。

可以的，见这里的例子 https://atom.io/docs/v1.3.2/behind-atom-keymaps-in-depth