用 Homebrew 来卸载

即使你的软件不是用 homebrew 安装的，你也可以用它来卸载（加 --force ），还可以加上 --zap 让 homebrew 把所有关联的数据文件都删除（可以用 brew cat 查看具体包括哪些文件），如 brew uninstall --cask --force --zap zoom

https://pbs.twimg.com/media/FABwbTiVQAgZPrG?format=jpg&name=large

对于开发者服务来说，每个 API 、每个参数都有大量的细节，和面向终端用户的产品很不一样。图形界面改了，用户自己会去适应，但调用 API 的程序不会自己适应，还是要开发者来改。

对于类似 LeanCloud 这种提供了十多种不同语言 SDK 、上百个 API 接口、加一起可能有几千个参数的服务来说，其实「下线功能」这种事情是经常会发生的。

对于客户端来说，能做的就是尽量遵守 Semantic Versioning （语义化版本号），把不兼容改动都放在 major （大版本）的更新里，甚至提前几个版本就开始打印警告，对于不兼容的改动提供详细的迁移文档（应该换成哪些 API 来替代）；要及时在文档和 Demo 中将即将废弃的接口去掉，如果整个 Demo 都不再支持的话也要在 GitHub 上修改 README 后 archive 掉。

对于服务端来说接口一旦下线就彻底无法使用，通常要更加慎重，比如需要在客户端去掉该接口比较长时间以后、从监控看到接口的使用量很小的情况下再下线；提前将功能的入口（如文档）去掉，避免新的开发者使用。

确实有时候迫于业务方向或者法规要求，还是会有一些比较生硬的「下线」，但无论如何还是要将这个事情提前通知到开发者。如果只是一个小功能最好能精确通知到受影响的用户，通知的时候态度还是要坚决，要约定明确的下线时间，否则开发者不会当回事；如果是整个产品的下线则应该有公开的公告，最好是能由 CEO 或者高层负责人在其中介绍一下前因后果。

对于涉及数据的应用要提供导出数据的方式和文档；涉及到费用的要为开发者退款，最好是在「从通知到下线」这个过渡期不再收取费用。

说到服务下线有个有趣的做法是「提前下线一小段时间来起到通知的作用」然后再恢复给开发留出迁移的时间，GitHub 就曾经这么做过 https://developer.github.com/changes/2018-11-05-github-services-brownout

NFT 提供的是一种技术上的可能性、一种标准和规范，其上的应用需要一个构建秩序的过程，这个过程中也会发生很多离谱的事情。就好像智能合约构建了这么多年，现在圈内人已经不会去质疑 Ethereum 作为基础设施的价值了，大家的关注点已经到了智能合约之上的 NFC 、DeFi 等概念上。

就和其他很多事情一样，作为用户应该用脚投票，不认可这个交易费的话就尽量寻找主网之外的替代品。

Gas 费主要和交易数量（ TPS ）相关，是因为有越来越多的人希望进行交易，而全网打包能力有限才越来越高的。和币价有一些技术上的关联，但更主要的是因为币价和交易数量往往是强相关的，也就是价格上涨时会有更多人关注到密码货币。

除了 Ethereum 主网之外也有其他 Layer2 或者兼容 EVM 的独立网络可以选择嘛，它们之间是一种竞争关系。Ethereum 高昂的费用肯定是一个负面因素，但大家目前还是非常认可 Ethereum 在智能合约领域的地位，就算贵也要尽可能上主网。就好像 Bitcoin 并不能支持智能合约，但因为大家认可它的地位，所以价格依然十分坚挺。

这种「平均 CPU 使用率」图表完全不能代表使用体验，起码要看 p95 或 p99 的 CPU 使用率。

不管是电脑还是手机，其实 CPU 设计上就是为了那「千分之一」的时间能快一点，所以才会设计成高突发性能、然后跑一段时间降频。

当然值不值得为此升级这确实因人而异。

POSIX 的约定 https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap12.html
一个试图规范化参数说明的开源项目（包含各个语言的解析器） http://docopt.org

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 握手的时候会有随机数来避免重放攻击，所以中间人也只能转交一次，或者不转交。