通篇充斥着偏见和立场。。

看第一条吧，Chrome 最近也改了圆角，Chrome 的书签栏设计乱改了好几版，Google 自己的设计语言也在不断改动。然后说 Mozilla 内部的开发路线 “至少早期” 是相对混乱的。

再看第二条，" Chrome 不断限制扩展插件的自由是事实，但是又有多少人记得 Firefox 当年在扩展上走的弯路" 我要换个立场来说，就可以改成 "Firefox 当年在扩展上走过很多弯路，才带来了现在的扩展生态，而 Chrome 却不断限制扩展插件的自由，来不及迁移新接口的插件就不能用了"。

再看第三条，Chrome 不清楚 Google 的 Cookie 这么大问题一句话带过，然后对 Firefox 默认主页浓墨重笔并在没有证据情况下推断带有 "中国特供版的私货"。实际上 Chrome 默认主页也好导航搜索也好，都是 Google 搜索。

后面内容懒得再评价了。我自己一直坚持用 Chrome，偶尔 Safari，但文章里的那些理由我一条都没吃到。。

@TomasKozey 从京东买了个兼容电池自己换上了。本想着换失败了就有理由买新机子了，结果用到现在还好好的。。

@ultimate010
巧了，我也是 14 款 15'mbp，只要有电源就插电源，循环也一百多次，损耗也非常小，也没外接显示器。几个月前就突然鼓包了，鼓得非常厉害，但从软件层面看怎么看都很健康。

@jiang1234321

0.1 和 0.9 用二进制表示的话，都是无限循环的，但内存中的 double 只有有限位数，所以要做截断并 rounding 到最近的一个二进制，这里损失了精度。

"0.1" 解析后是 0x1.999999999999ap-4
"0.9" 解析后是 0x1.ccccccccccccdp-1
"1" 解析后是 0x1p0
1-0.9 实际在内存中的计算是 0x1p0 - 0x1.ccccccccccccdp-1 = 0x1.9999999999998p-4

直接写的 0.1 和经过计算得到的 0.1 在内存中的数值不相同，相差 2 ulp。

0x1.999999999999ap-4 转换为十进制时，是 0.1000000000000000055511151231257827021181583404541015625，print 会截断到 0.10000000000000000，舍去结尾的 0，就是 0.1。

0x1.9999999999998p-4 转换为十进制时，是 0.09999999999999997779553950749686919152736663818359375，print 会截断到 0.09999999999999998。

上面的这些 0x 开头的数值是用 Hexadecimal 格式写的，等同于 double 在内存中的实际数据。

@CEBBCAT https://www.exploringbinary.com/topics/ 见 "Correctly Rounded Decimal to Floating-Point Conversion" 这部分的文章。

CSAPP 可以作为基础知识来了解一下，精度究竟是如何损失的、损失结果是怎么样的，这部分就没有介绍了。

把字符串解析为 IEEE754 浮点数，是非常复杂的事情，vc、gcc、jdk 甚至 libc 的 strtod 都出现过 bug。
IEEE754 浮点数运算，又是另一个话题了。

可以仔细看一下 IEEE754 浮点数标准与计算过程。精度损失主要集中在这几个地方：
1. 大部分十进制表示的小数，是不能完全精确的由二进制的 IEEE 浮点数表示出来，编辑器解析字符串的过程中会有 rouding 过程。
2. 打印的时候，二进制大部分情况也不会完全用十进制表示出来，printf 会做舍入和截断。
3. 浮点数计算的过程中，可能会有精度损失。
可以在 https://www.exploringbinary.com/floating-point-converter/ 转换来看看。

"0.1" 解析后是 0x1.999999999999ap-4
"0.9" 解析后是 0x1.ccccccccccccdp-1 (注意最后一位)
1-0.9 得到的结果是 0x1.9999999999998p-4 (注意最后一位)

1.0 / 3.0 * 3.0 这三个数都能精确表示为 IEEE 浮点数
1.0 / 3.0 得到结果 0x1.5555555555555p-2
再乘以 3.0 得到结果 0x1p0

@wohenyingyu03 年初《流感下的北京中年》那篇文章

买个 iPhone、iPad 装个抖音今日头条什么的，可能用几天就喜欢上了。。

简单说就是用户安全意识不够，导致 Apple ID 被盗，连累了支付宝。
支付宝不想背锅，又不能直接怼用户，就把锅甩回了苹果。

原装鼓包都把后盖快顶开了，着急换就在京东买的绿巨能，因为只有这个牌子能第二天送到。。
自己换电池感觉提心吊胆的，铲双面胶累得要死。换好到现在 3 个月了，没什么特别感觉。。

横竖屏切换在这种量级的 App 上添加支持，代价实在太高了，还会有一大坨 Bug。。
用得人又那么少，还被人喷没用、没脸，那... 不如砍掉吧~~

这些都是有损压缩啊，不能光看压缩比，也要对比一下质量吧。

不过既然都能接受有损了，不如换个其他格式～

如果苹果强制需要在 iPad 上实现不同设计，仅放大不让上架的话，估计大部分厂家就放弃 iPad 了。
反正用得人不多，开发和维护代价又太大。

http HEAD 能拿到 Content-Length 和 Last-Modified，可以当做文件大小和修改日期。
SHA1 除非存储平台预先计算好并提供对外接口，否则就得把文件完整下下来计算。

"剩余空间越大越快" 倒不至于，"剩余空间越小越慢" 倒是能找到一些相关性。