Google Drive 、One Drive 、Dropbox 早就已经这么做了，为什么你抵制的对象是苹果呢（而不是所有云服务）？
苹果是这几家中最后一个低头，同时采取了更多措施来视图保护隐私。

其实作为面试官没必要告诉候选人每道题是对是错 ... 毕竟是又不是面试官被面试。
毕竟难免会有自己不懂的地方，即时地评价很容易出这种问题，包括面试的结果也不应该当场给出。

@Anshi
@kop1989
著作权是天然获得的权利而不需要申请，著作权登记只是一种在法律上证明著作权的方式，但不是唯一的一种。

设计基于 Redis 的定时任务系统（ ZSET + Scripting ）
https://jysperm.me/2019/08/redis-cronjob-system/

是支持的：

M1 芯片之前对我来说最大的变数在于对 Docker 的支持，但就在前几天 Docker for Mac 也发布了 针对 M1 芯片的测试版本。测试版中默认会运行一个 ARM 架构的 Linux 虚拟机，默认运行 linux/arm64 架构的镜像（说起来在 M1 之前 linux/arm64 大概主要是被用在树莓派上吧）；对于没有提供 linux/arm64 架构的镜像则会自动使用 QEMU 来运行 x64_64 的镜像，性能就比较差了。

而使用 Docker for Mac 构建镜像则没有提升，这可能是因为构建的过程有很多零散的 IO，CPU 会有比较多的时间休息。而如果使用 Docker 去构建 x86_64 架构的镜像的话，性能损失就非常严重了（-61%）。

针对 M1 芯片的测试版本 https://docs.docker.com/docker-for-mac/apple-m1/
完整测评文章 https://jysperm.me/2021/01/macbook-air-apple-silicon/

发布这个时间胶囊时，预估的是 35 年后解开。

@neteroster

我也是想到了这个，这个概念可以叫「密码学时间胶囊（ Time Capsule Crypto-Puzzle ）」，实际上 RSA 算法的发明者之一就在 1999 年发布了这样一个时间胶囊：

https://people.csail.mit.edu/rivest/lcs35-puzzle-description.txt

最后在 20 年后的 2019 被人解开：

https://en.wikipedia.org/wiki/LCS35

你举的几个例子可能学 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 ）。