苹果的解决方案是把状态栏加宽，我干……

@monkeydev 跨 Windows *nix 不要使用 zip，换 tar 或者 7z.
zip 格式设计时没有考虑存储文件系统编码。*nix 下文件名、文件夹名都是 UTF-8 编码，中文 Windows 下大概是 GBK 之类的。直接解压对方压缩的 zip 时，会使用自己文件系统的编码，解压必然失败。

如果非要死磕 zip:

- 少量 GUI app （如 macOS 下 Entropy 和 The Unarchiver ）对 zip 解压加入了编码猜测支持，而不是直接使用当前文件系统的编码。
- 某些 TUI 支持解压 zip 时指定编码，如 unzip-iconv (patch 版 unzip, -O, -I 参数)，unarchive (The Unarchiver 应用底层命令行工具，-e gb18030)

更正：

- bitbucket 还需要指定 HostKeyAlgorithms +ssh-rsa
- 另外上条回复末尾 bitbucket 不支持椭圆曲线应该是错误的，不能只依据 host key algorithms 判断

@chengfeng 基本是正确的。严格来说不是 RSA 被废弃，RSA 公钥仍然安全，废弃的只是认证过程中的 ssh-rsa 签名格式，或者说哈希算法。

自从 OpenSSH 7.2，rsa-sha2-* 取代 ssh-rsa 作为默认的 ssh host key algorithm 签名算法。8.2 时通知 ssh-rsa 之后将废弃，8.8 正式废弃了 ssh-rsa.

https://security.stackexchange.com/a/226133/203193
> The RFC8332 RSA SHA-2 signature algorithms rsa-sha2-256/512. **These algorithms have the advantage of using the same key type as "ssh-rsa" but use the safe SHA-2 hash algorithms.** These have been supported since OpenSSH 7.2 and are already used by default if the client and server support them.

另外影响的只是 ssh-rsa hash 算法格式，RSA 公钥（即 id_rsa 文件）仍然使用 ssh-rsa 格式。 因为 RSA 公钥不依赖 hash 函数。

https://www.ietf.org/rfc/rfc8332.txt
> Since RSA keys are not dependent on the choice of hash function, the new public key algorithms reuse the "ssh-rsa" public key format as
defined in [RFC4253]:

https://superuser.com/a/1488613/733022
> RSA keys themselves are neither "SHA1" nor "SHA2" - the key format doesn't involve any hash algorithm at all. The private key just consists of two large numbers, and unlike certificates, there is no attached signature.

https://superuser.com/a/1556861/733022
> The key format has not changed. The only thing that changes is the signature format that's sent during each authentication handshake.

---

回归原问题，OpenSSH 8.8 客户端默认不提供 ssh-rsa hash function，而远端服务端不接受非 ssh-rsa 外的 rsa-sha2-*. 协商失败。

目前已知受影响的有 gitee.com, bitbucket.org.

测试方法： ssh -T [email protected] -vv 或者 ssh -T [email protected]. -vv 开启 debug2 级别日志。在结果中检索 'host key algorithms'，注意有 2 条匹配，一条客户端的，一条服务端的。

gitee: ssh-rsa,ssh-dss,ecdsa-sha2-nistp256,ssh-ed25519. OpenSSH 服务端没有支持 rsa-sha2-*.
bitbucket 就更狠了: ssh-rsa,ssh-dss. 根本就不支持任何椭圆曲线签名算法。

fzf 配置好后自带此功能，不过触发通过 ssh ** 双星后按 Tab 补全。
补全内容来自文件 ~/.ssh/config ~/.ssh/config.d/* /etc/ssh/ssh_config
源码在 https://github.com/junegunn/fzf/blob/master/shell/completion.bash

export GIT_SSH_COMMAND="ssh -vvv"

Firefox nightly 更新太频繁了，还是换 iceraven 比较好
https://github.com/fork-maintainers/iceraven-browser/releases

@FlyPuff 应该先开 Team 这样会有 15 刀免费试用，然后兑 250 刀 HAPPYHOUR coupon 。退了 Team 再兑 1000 刀 和 500 刀的 coupon 。

否则 credit 高于 200 需要自己掏 Team Plan 的 10 刀月费。这样拿到 1740 而不是 1750.

总计可以拿 1750 刀，有额外 250 刀 coupon 需要开通 Team Plan 才能兑换。https://www.ozbargain.com.au/node/654695

错了，用 dnsmasq 应该不是 Windows，总之把 OS 级别的自动代理检测关了。

在没有使用 dnsmasq 之前，操作系统默认拿到的是路由器下发的 DNS 服务器，通常是路由器自己运行了一个转发 DNS 。路由器知道自己 DHCP 服务下有哪些客户端，可能用这些信息作为对 .lan 的响应。如果没有匹配也不会将 .lan 转发给公共 DNS 服务器。

把 Windows 的自动检测代理关了试试？

另外，.lan 属于本地域名，应该配置 dnsmasq 不向上游转发，可能之前你没配置对导致向外部 DNS 转发查询了。

@forgottencoast 你是说那个 B 站视频，我记得本来价值就不大，没有大纲比较啰嗦，倍速随便听听就好。

感觉我回的还是有点歪了，业务上的设计问题，框架、库关系好像也不大。设计好项目还是得参考现成的、流行的同类型项目源码。

方向错了。计算机导论、算法不属于你作为后端的技能点。以前听别人扯淡提到过类似观点， [程序员如何避免青春饭-哔哩哔哩] https://b23.tv/npQo6N

计算机科学导论、编译器原理、TCP 协议等属于底层基础，你干活是应用层的事，中间隔着好几层对于你没有任何影响。
算法属于八股（至少对后端来说是这样），只在面试会用到。考算法和高考、考研没太大区别，考完可能完全用不到，是学习能力的一种考察方式罢了。

设计模式可以读读，但平时写的时候可能想不起来。建议多翻一翻自己常用框架、库的源码，看看行家们是如何设计项目的，能对应到哪种设计模式。近朱者赤，近墨者黑，研究行业大师们写的东西总能混到点经验。注意自顶向下，从应用层往下打。一些反例：研究框架原理直奔 socket 连接创建；研究网络协议直接 TCP 。

关键词 rhinoshield

类图的不知道，关系追踪试试 https://github.com/CoatiSoftware/Sourcetrail

感觉 Outlook 别名账户半残，邮箱号变了但发件人名字强制使用账户资料里的姓名。

未必，Homebrew 只是个包管理工具，软件包本身不支持 arm64 可能它也没辙，仍有少部分包不支持 arm. https://github.com/Homebrew/brew/issues/10152

“m1 的 homebrew”一词本身可能有歧义。在 m1 上，Homebrew 分为 native arm install 和 Rosetta 2 install. 现在默认安装的应该是前者（表现为使用 /opt/homebrew 路径），其安装的包也大多是支持 arm 的。如果遇到不支持 arm 的包，会安装失败。这个时候唯一方案是再安装一份 rosetta homebrew，我的理解就是安装 x86 包，通过 Rosetta 2 兼容运行在 ARM CPU 上。