我的建议是坚守 Magic Keyboard 2，或者 HHKB Hybrid 。

HHKB 跟 MacBook 键盘布局基本一致（假如你在 Mac 中也交换了 Caps 和 Ctrl ），日常无缝切换。

我觉得 B 站跟 YouTube 还是不一样，不能这样一一对应。

外接显示器必然会走独立显卡，想风扇没声音是不可能的，深夜想安静的话只有用内置屏幕。

BTW，我换了 M1…

保温壶盖的材料应该不至于老化到掉渣，倒是橡胶圈 /硅胶圈几年就该换了，一个是老化不保温，一个是用久了沾了味道。

老式的软木塞热水瓶的话，软木塞更是消耗品啊，反正便宜又好买…

讲真这个级别的机器还是得有个 UPS 的，不怕一万就怕万一

我倒是觉得尽量白板调试，然后重写重新提交。

毕竟刷 Leetcode 的目的单纯就是为了应付面试，实际面试的时候也不会给你机器上调试的机会。

@benmaowang 可以 Wine，效果可以。

楼主你有心思研究投资是好事，但如果你的目标是跟截图里几位那样 10 倍以上的收益，我觉得还是暂时不要开始投资为好。

自己跟服务器商量好就行了…

在你的 .zshrc 里加上

setopt completealiases

感觉定位有点奇怪

一般需要缝合怪的主要是移动的时候，旅行、出差、图书馆咖啡馆之类的，但这些地方一般也用不上外接显示器。能摆得下显示器的地方也不在乎多一两个 hub 。

Rosetta 2 转译的可以用，没有遇到什么问题。目前还没有原生的。

扫端口这种完全没办法，除非上独立防火墙，否则只能让他扫了。

我觉得按照目前的大众硬件水平，二次验证的 https 登录和基于足够强度 key 的 ssh 还是安全的。

@Harry1993 抱歉，我不知道有什么正常一点的方法，因为依赖关系是写在它们包的定义文件里的——macports 的 Portfile 、homebrew 的 formula 。

我能想到可行的 hack 只有在安装之前手工编辑一下包定义文件，去掉对 go 的依赖，然后确保自己编译的 go 在 PATH 里。等安装好再复原包定义文件。

@Harry1993 类似 cask 的支持在 macports 里其实是没有的，你看到的 iTerm2 也是 macports 自己编译的版本。换句话说，只有开源的 app 才有收录进 aqua 下的可能。

@czhu 现在 macOS 系统的方向是 base system 尽量可能小而且 read only 。系统给提供的库已经非常少，而且并不推荐第三方软件使用了。

现在即使是 homebrew，需要在包管理器内部解决的依赖也是越来越多，homebrew 使用 keg only 来解决跟系统包重复的问题。从这个角度的话，macports 选择的方向没有什么问题。

Homebrew 的 Apple Silicon 进度的话，我自己的尝试，到今天（ 2020-12-13 ）为止，如果你按照推荐安装在 /opt/homebrew 下的话，很多包也已经有了 arm64 的 bottled，剩下的自己编译也基本可以。剩下还有问题的只有 go 和 rust 的依赖，这个只能等上游发布新版本了。

不过 Homebrew 这次的操作有点迷，如果它坚持 arm64 只能安装在 /opt/homebrew 的话，无异于放弃了一直以来宣传的无缝便利（因为所有的包在 /usr/local 下）。

各种信息都表明 docker 、虚拟机、原生 homebrew 这些都只是短期时间问题。我甚至觉得在 Apple 出 32G 以上内存机器之前就能解决。

感觉完全从源代码编译的话，到可用应该不需要太久？