@RickyC 开源不是别人义务为你劳动，是有协议限制的，不是随便转发、随便发、随便用的，所有开源代码都会带一个开源协议文件（大部分叫 LICENSE ），大部分开源代码还会在每一个源代码文件开头用注释写上开源协议。
开源协议是有法律效力的，你违规使用的话，小范围也许人家没精力管你，做大了的话是要吃官司的！
不同的开源协议有不同的限制，比如有的协议规定你使用了他的开源代码，那你的代码也必须得开源；有的协议虽然不要求你要开源，但你必须在项目中注明你用了他们的代码；有些协议规定了把开源代码拿过来改一改变成自己，不仅要注明原先代码的来源，还要注明改动的地方。
国产浏览器用的 Webkit 、Blink 内核是开源的没错，但要遵守 LGPL 、BSD 之类的协议，具体协议的内容可以去网上看。
GitHub 代码右上角会标明开源协议，里面会简单介绍协议的限制。

全家福 emoji 👨‍👩‍👧‍👦

我个人是不建议随时随地 rebase 的，3 楼解释的比较完整，历史记录是有用的，不是为了好看的。只有当必须 rebase 的时候（比如历史提交了敏感信息，需要退回去删掉），才 rebase 。
分支是需要被保护的，就限制了 push -f 这个万恶之源。

@xy19009188 我前一段也是一直闪退，卸载重装才好的……

Google： http://www.gstatic.com/generate_204 / http://maps.google.com/generate_204 / http://mt0.google.com/generate_204 / http://mt1.google.com/generate_204 / http://mt2.google.com/generate_204 / http://mt3.google.com/generate_204 / http://clients3.google.com/generate_204 / ...
V2ex： https://www.v2ex.com/generate_204 （不建议使用，因为只支持 https，不支持 http，连接相对耗费资源，对于 wifi 需要跳转认证的情况支持页不好）
小米： http://connect.rom.miui.com/generate_204
华为： http://connectivitycheck.platform.hicloud.com/generate_204
Vivo： http://wifi.vivo.com.cn/generate_204

@nereus 上个月 Let's Encrypt 发的博客里提到针对了 BGP 的攻击，说是大部分的 BGP 部署都不安全： https://letsencrypt.org/2020/02/19/multi-perspective-validation.html

@wdlth 套了 CDN，CDN 实现的 AnyCast

@Reficul #86 私钥是没放出来，但是也不排除可能有谁持有这个私钥。作为非权威机构，不能保证他们能够很安全地保存证书私钥。所以，在证书到期之前都算是一个定时炸弹……

@lintj #115 并没有劫持，只是之前 12306 匪夷所思的没有使用权威机构的数字证书，而是将首页设置为未加密的 HTTP 连接，然后在首页提供一个自签名的证书。如果不安装这个证书的话，在进入买票的页面的时候就会提示证书不受信任了。官方诱导用户去以 HTTP 协议下载根证书并安装为可信颁发机构。
如果不存在中间人的话，那装不装证书都 OK ；而如果存在中间人攻击，因为首页是 HTTP，所以首页的证书是很容易被替换的，也就是即便装了证书也不能保证安全，甚至后果更严重（安装了中间人的证书）。

确实至今 12306 的那个根证书没有发现被利用来做什么坏事（是没有发现，不敢 100% 说没有，不要产生恐惧，也不要放松警惕），这是好事，但是没人知道那个根证书弃用之后是怎么处理的，是否还有人持有证书和私钥文件？这不得而知，所以，至少在那个根证书过期之前，可能都是一个定时炸弹。

@AllenHua query 缩写成一个字母 q 很常见啊，谷歌、必应的搜索词参数就是 q，百度的是 word 缩写成 wd……

@zongren 不是没得选，因为 12306 没开 HSTS，所以只要点个忽略警告，仍然访问就行……
反正证书不正确，如果有劫持的，也肯定把要安装的根证书也替换了……
不装根证书相对来说更安全……

颁发者 [email protected] ？拿自签名的证书来劫持？
看起来像是你所在的地方的“小学生”干的，也许可以举报一波……
我觉得更高端的劫持是拿前两年铁道部的证书来劫持，毕竟以前 12306 买票骗你说要装根证书，而好多人傻呼呼地都装了……现在正好用来劫持……

query 不是大部分直接缩写为 q 吗？

执行一个 js 来显示广告？怕不是只用来显示广告而已哦，还可以顺带 xss 一波……
除非站长 100% 信任你，不然谁敢加载你的 js ？
审阅过代码，没问题？谁知道你会不会哪天悄悄地就把脚本给换了？
那提供静态 js，用户可以下载到本地，审阅无误之后再用？能力不弱的人，肯定没几天就破解了，只显示图片不显示广告……需求、用户量越大，破解速度越快……
加载 js 来显示广告这就是行不通……
除非你和大部分图床一样，只提供图片链接，然后在你服务端返回图片的时候强行在图片上附加广告……但我觉得，强迫症肯定是受不了的……

我觉得不爽的点是同音字问题，需要配合输入法，补全就很难受了。
比如要打一个词，要么用输入法打完（有词库还稍微好一些），要么输入一两个字，然后 IDE 补全，但是输入一个字是比较痛苦的，特别是常用的多音字比较多的时候……
至今没有一个体验能比得过易语言那个 IDE 的中文编辑器，自动调整全角半角符号、输入首字母自动补全，这些功能我觉得是使用中文编程最基本的体验了……

应该可以通过 HTTP header 中的 host 、HTTPS TLS 中的 SNI 来匹配访问的网站吧……
v2ray 好像可以？然后用 iptables 的 redirect ？

@cruii 你觉得 av 号用的少仅仅是你不用这个功能，具体 av 号用的人多不多我没统计过我不知道，你没统计过也不要瞎说。
但是可以确定的是，B 站官方也知道有大量的人在使用 av 号，所以他们在改用 bv 号之后需要专门发一篇文章公告，不然他们改了就改了，用得着通知用户？
甚至，在公告中 https://www.bilibili.com/blackboard/activity-BV-PC.html，专门提到了他们的“BV 号直通车”功能，给出了相关的使用用例。
由此可见使用视频 id 的人不在少数，只不过你不在这个人群中而已。
再说一下 av 相比 bv 的一个使用场景优势：有人给你手机上发了个视频链接，然后你想在电脑上看，8 位的 av 号可以很方便的快速输入，而 10 位的 bv 号，比现在最大的 av 号长不说，你还要区分大小写、区分 0OoiIlL 这些。
> #112 “明知一个东西逐渐用得少了还要硬留着，难道这就是产品的优点吗”
抱歉，至少 B 站知道这个功能还要保留，不能删，甚至专门提出来。
吐槽的点只是 B 站新的 bv 号没 av 号好用了。

按照 B 站成立至今累计递增的 av 号速度来看，B 站成立至今十多年的时间，递增的 av 最大也才到 8 位，预计未来一百年，av 号长度都最多涨两位，简单的小学算术问题罢了。
> #112 “今天我 av 号 8 位数字，明年 10 位，后年 15 位，年年加 n 位”
> #112 “一律填写 av 号的上百个数字而不是编码后的 10 位英文数字组合，你觉得这种需求合理吗”
> #117 “那我改成明年 9 位 后年 10 位，现在能懂了吗”
抱歉，你这一句话的前提就是在胡说八道，未来很长一段时间 av 号都到不了 10 位，明显比 bv 短不说，还不容易混淆 0OoiIlL 这些！

产品是为用户而存在，用户才是上帝，用户有权利对使用的产品说三道四，特别是付费用户。
敢情改的、砍的不是你常用的功能，你就不让别人发声？事不关己高高挂起？这是键盘侠的行为。

命令行

== 的话，没问题，>= 容错率更高，但容错意味着隐藏 Bug，所以在写代码特时候，用 >= 的时候也要思考，即使不正常地出现了 > 的情况，会不会对后续程序造成影响，如果会造成影响，一定要抛个异常。

建议看内核源码 https://www.kernel.org/