你举的几个例子可能学 JS 写浏览器插件会更合适。

屏幕亮度 Pro 要高一点，其他应该没区别了。如果希望用时间久一点，建议加内存（可以考虑舍弃 Pro 或存储空间）。
我的 M1 Air 测评 https://jysperm.me/2021/01/macbook-air-apple-silicon

@helloworld000 #4 销量同时决定了软件生态，另外你怎么知道我不是苹果的（小）股东呢 ...

因为响应也是加密的，中间人只能把请求转交过去而看不到响应的内容；同时因为 https 握手的时候会有随机数来避免重放攻击，所以中间人也只能转交一次，或者不转交。

@BostonCorbett 热插拔主要看硬件的支持，群辉低端的型号应该也是不支持的，文章中的 Gen10 也是不支持热插拔。

@calpes unraid 起步价就 $59，打消了尝试的念头
@ntgeralt 文章中有提，ZFS 的 raidz （ RAID5 ）因为有定期的数据校验，会比普通的 RAID5 更健壮一点，当然也要综合盘位数量和容量，数量越多、容量越大，重建的风险越高。

@felixcode FaceTime 是漏洞并不是故意为之；被发到 Google 和腾讯的数据只是一个 4 字节的散列值
@levn 苹果七成以上的收入来自硬件销售

www.samba.org/samba/docs/current/man-html/smb.conf.5.html

www.samba.org/samba/docs 这里点「 Samba man pages in html 」不就可以链接过去嘛 ...

LeanCloud 了解一下？

简单来说就是代替构造函数

>为什么要顺序地尝试获取所有实例里的锁呢？同时尝试获取会存在什么问题呢？

同时获取可能会死锁（每个客户端成功在一半的实例加锁），所有客户端都顺序访问就不会出现死锁了。

>键是在不同时间被设置的，所以也会在不同的时间失效。这样子还能够保证 mutual exclusion 属性吗？

按我的理解这个 TTL 只是为了避免出现加锁后（因进程崩溃）没有解锁的情况，在一定时间后自动解锁，这本来就是一个特殊情况下的措施，其实在发生达到 TTL 时，锁的有效性就已经得不到保证了（你不知道是进程真的崩了还是暂时卡住了），所以这个 TTL 差个几毫秒并不是那么重要。

正常的应用中不应该出现「期望在获取到锁之后的 ttl 时间内都能够唯一拥有锁」的情况，应该（比如在时间用掉了一半的时候）不断地续期，在结束后主动地释放锁。

备份这个课还是要上的，不管用的是什么设备，都要将设备本身的存储当作临时存储，想想至少 macOS 提供了一个 Time Machine （虽然 Windows 也有，但可靠性和易用性不如 Time Machine ）。

刚在 App Store 买了 Medis 支持一下，感觉开源但不提供编译好的版本，让大家去 App Store 买也是个不错的盈利模式。

用 Medis 主要是因为平时项目里用的都是 ioredis，用一个基于 ioredis 的 GUI 显得非常亲切（虽然实际上对使用没什么影响）。

headless 的 service 其实就可以当服务发现来用，用 DNS 协议查 headless 域名即可。

Promise.all 或 Promise.allSettled

可以加 iptables 规则来匹配从某个容器出去的流量，然后可以从 iptables 的计数器里查到被这个规则匹配的流量。

@Senventise
@TPOB
我觉得用「资格」更准确一点。

@Anhedonia 所以还是类似 Sketch 那种订阅结束之后可以继续使用最后一个版本比较合理，这样如果软件一直没有令人满意的更新就可以直接退订了。