coding in a complicated world
看了《你需要知道的 AI 内存知识》，我才知道：
JavaScript hashing speed comparison: MD5 versus SHA-256（Daniel Lemire, 2025-01-11）通过 JavaScript 基准测试对比了 MD5 与 SHA-256 在 Node.js 23 和 Bun 运行时下的哈希性能，核心结论颠覆了“MD5 更快”的传统认知：
md5Hash 和 sha256Hash 进行基准测试，底层实际调用 OpenSSL 实现。这是采用的 JavaScript 做的基准测试，但是结论说明的是通用硬件现象：现代 CPU（ARM/x86）有 SHA-256 硬件指令加速，而 MD5 无优化，任何语言调底层实现都如此。
因此，在现代处理器上，SHA256 性能大幅优于 MD5 的结论在所有语言上都是通用的。
波斯湾是一个几乎封闭的内海，三面被陆地包围——北岸伊朗、南岸阿拉伯半岛，只有东南角留了一个约150公里长的狭长缺口，这就是霍尔木兹海峡。
波斯湾夹在伊朗高原与阿拉伯半岛之间，面积约24万平方公里，平均水深仅40米，却蕴藏着全球近一半的原油和约三分之一的天然气。
这片海域唯一的出海通道是霍尔木兹海峡——长约150公里，最窄处仅约33公里，全球近20%的石油日运输量（约2000万桶）必须经此通过，因此它被称作"世界油阀"。
霍尔木兹海峡北岸全线属伊朗，控制着格什姆岛、霍尔木兹岛等扼守航道的关键岛屿；南岸则分属阿曼和阿联酋——阿曼的穆桑达姆半岛是一块飞地，恰好嵌在海峡最窄处，主航道反而贴近阿曼一侧，这使得阿曼虽非主要产油国，却成了航道安全的关键方。
波斯湾沿岸八国则共同围成这圈"世界油库"：伊朗（东北岸）、伊拉克、科威特、沙特阿拉伯、巴林、卡塔尔、阿联酋、阿曼（南岸）。其中除伊朗外，其余六国均为海合会成员。
根据1982年《联合国海洋法公约》，沿海国可主张不超过12海里的领海。伊朗与阿曼均采用12海里基线。
关键几何事实是：海峡最窄处仅约21海里，而伊朗从北岸向南延伸12海里、阿曼从穆桑达姆半岛向北延伸12海里，两国领海在最窄处重叠约3海里。
💡 这意味着海峡最狭窄地带及主要航道上，没有一滴水属于公海，甚至不属于专属经济区——任何过往船只、潜艇都处在伊朗或阿曼的主权水域之内。
波斯湾各国自1950年代起陆续通过双边协定解决大陆架划界，如沙特—巴林、伊朗—科威特、伊朗—沙特等。2001年国际法院还对卡塔尔诉巴林案作出判决，明确了两国的领海与大陆架边界。
但迄今仍有三处主要海洋争端未解：
海峡水域虽属沿岸国主权范围，但依据国际法院1949年《科孚海峡案》确立的习惯法，和平时期连接两片公海的国际海峡，外国船舶享有无害通过权，沿岸国不得单方面阻断。
真正有争议的是《海洋法公约》创设的过境通行权——比无害通过更宽松，不允许沿岸国事前审批。《公约》缔约国（如阿曼）原则上受其约束；但伊朗从未批准《海洋法公约》，且自1974年起就持续反对过境通行制度，因此在习惯国际法层面，伊朗并不当然受该条款约束。这也是美伊每次对峙时法理争执的根源——美方主张"过境通行"，伊方坚持"无害通过+沿岸国监管权"。
按12海里领海规则，伊朗对本国岸侧及近岸岛屿向外12海里内享有领海主权，可管航安、环保、无害通过。但霍尔木兹是伊朗+阿曼两岸领海咬合、无公海，且属“用于国际航行的海峡”，和平时期须保障外国船无害通过（伊朗不认过境通行但认此习惯法）。故伊朗有法理管自家领海，无法理独控全海峡、禁航或单方收费。
初审被拒，原因：
初审通过之后，备案进入 “管局审核中-短信校验中” 状态。
几分钟之后就会收到工信部短信验证码，需要进入指定链接输入验证码、手机号、身份证后六位进行核验。
短信核验之后过一会儿，备案进入 “管局审核中-人工审核中” 状态。
AI 总结了 The Git Commands I Run Before Reading Any Code，可以作为参考。
PS：其中部分命令的有效性是建立在提交规范执行良好的基础之上。我过去经手的项目全部没有提交规范。😂
Five git log commands that diagnose a new codebase before you open a single file: code churn hotspots, bus factor, bug clusters, and crisis patterns.
1. 变更热点 列出去年改动最频繁的 20 个文件，榜首常是团队"无人敢碰"的那个。高变更本身不糟，但若叠加"无人愿拥有"，便是代码库拖累的最强信号——每次修改都是补丁叠补丁，小改动的影响范围不可预测。微软 2005 年研究证实，变更率指标比复杂度更能预测缺陷。
git log --format=format: --name-only --since="1 year ago" | sort | uniq -c | sort -nr | head -20
2. 总线因子 按提交数排名贡献者。一人占 60%+ 即为风险；若其已离职半年便是危机。长尾同样关键：30 位贡献者中仅 3 位近一年活跃，说明建造者已非维护者。注意 squash-merge 会压缩作者信息，下结论前需确认合并策略。
git shortlog -sn --no-merges
3. Bug 集群 形态同变更热点，但过滤含 bug 关键词的提交。同时出现在两张列表的文件风险最高：反复出错、反复修补却从未根治。此法依赖提交信息规范。
git log -i -E --grep="fix|bug|broken" --name-only --format='' | sort | uniq -c | sort -nr | head -20
4. 提交节奏 按月统计提交数。稳定节奏健康；单月减半常因有人离职；6–12 个月下滑曲线揭示团队失速；周期性尖峰后沉寂则是批量发布模式。这是团队数据，而非代码数据。
git log --format='%ad' --date=format:'%Y-%m' | sort | uniq -c
5. 回滚与热修频率 一年中偶发回滚正常；若每几周一次，说明团队不信任部署流程，背后是测试不可靠、缺预发环境或回滚困难。零结果同样值得玩味。
git log --oneline --since="1 year ago" | grep -iE 'revert|hotfix|emergency|rollback'
从官网下载的钉钉 deb 文件，安装之后竟然无法启动。
-> % ll ~/Downloads/com.alibabainc.dingtalk_8.1.0.6021101_amd64.deb
-rw-rw-r-- 1 catroll catroll 387M 2026-07-10 21:39:31 /home/catroll/Downloads/com.alibabainc.dingtalk_8.1.0.6021101_amd64.deb
-> % apt install ~/Downloads/com.alibabainc.dingtalk_8.1.0.6021101_amd64.deb
一边查看日志（journalctl --user -f），一边点击钉钉图标，可以看到以下错误日志：
7月 10 21:49:27 eqr com.alibabainc.dingtalk.desktop[361857]: ubuntu
7月 10 21:49:27 eqr com.alibabainc.dingtalk.desktop[361857]: ubuntu branch
7月 10 21:49:27 eqr com.alibabainc.dingtalk.desktop[361857]: preload_libs=./libgbm.so ./plugins/dtwebview/libcef.so
7月 10 21:49:27 eqr com.alibabainc.dingtalk.desktop[361873]: ERROR: ld.so: object './libgbm.so' from LD_PRELOAD cannot be preloaded (cannot open shared object file): ignored.
7月 10 21:49:27 eqr com.alibabainc.dingtalk.desktop[361873]: Run Main is_gpu=0 is_zygote=0 is_render=0 is_crashpad_handler=0 cmd : ./com.alibabainc.dingtalk
7月 10 21:49:27 eqr com.alibabainc.dingtalk.desktop[361873]: Load /opt/apps/com.alibabainc.dingtalk/files/8.1.0-Release.6021101//dingtalk_dll.so failed! Err=/opt/apps/com.alibabainc.dingtalk/files/8.1.0-Release.6021101//dingtalk_dll.so: cannot enable executable stack as shared object requires: Invalid argument
7月 10 21:49:27 eqr systemd[4607]: Started app-gnome-com.alibabainc.dingtalk-361857.scope - Application launched by gnome-shell.
经过 AI 的一番分析，结论是：
钉钉 deb 包依赖的 ELF 动态链接配置与当前系统环境不匹配。patchelf 修正了二进制的解释器、RPATH 或依赖库路径，使程序能正确加载运行时库之后就可以启动了。
sudo apt install -f patchelf
sudo patchelf --clear-execstack /opt/apps/com.alibabainc.dingtalk/files/8.1.0-Release.6021101/dingtalk_dll.so
1. 混合（Blending）：打好地基
将乳脂（奶油/牛奶）、糖、乳化剂、奶粉混合加热。这一步决定了冰淇淋的“底子”好不好，乳脂越高，口感越顺滑。
2. 均质（Homogenization）：打碎脂肪
通过高压把牛奶中的大脂肪球打成微米级的小球。这一步是为了防止脂肪上浮，让口感变得细腻、均匀，没有粗糙感。
3. 老化（Aging）：让蛋白质休息
将混合物迅速降温至4℃左右静置4小时以上。目的是让蛋白质充分吸水膨胀，这样后面打入空气时才不容易塌陷，质地更稳定。
4. 凝冻（Freezing）：魔法发生的地方
这是最关键的一步！在-6℃至-10℃的凝冻机里疯狂搅拌。
5. 硬化（Hardening）：定型
如果是硬冰淇淋（如哈根达斯），会放入-30℃的冷库急冻，固定形状。
我之前下载 deb 文件都用 gdebi 安装，但是今天升级 curosr 的时候报错：Breaks existing package 'cursor' conflict
-> % ll ~/Downloads/cursor_3.10.17_amd64.deb
-rw-rw-r-- 1 markjour markjour 187M 2026-07-07 03:35:12 /home/markjour/Downloads/cursor_3.10.17_amd64.deb
> % sudo gdebi ~/Downloads/cursor_3.10.17_amd64.deb
[sudo: authenticate] 密码：
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Reading state information... Done
此软件包不可安装
Breaks existing package 'cursor' conflict: cursor ( )
因为 Cursor 打包的时候声明和已经安装的 cursor 冲突。
-> % apt info ~/Downloads/cursor_3.10.17_amd64.deb | cat
Package: cursor
Version: 3.10.17-1783235114
Priority: optional
Section: devel
Maintainer: Cursor <hi@cursor.com>
Installed-Size: 908 MB
Provides: cursor
Depends: ca-certificates, libasound2 (>= 1.0.17) | libasound2t64 (>= 1.0.17), libatk-bridge2.0-0 (>= 2.5.3) | libatk-bridge2.0-0t64 (>= 2.5.3), libatk1.0-0 (>= 2.11.90) | libatk1.0-0t64 (>= 2.11.90), libatspi2.0-0 (>= 2.9.90) | libatspi2.0-0t64 (>= 2.9.90), libc6 (>= 2.14), libc6 (>= 2.16), libc6 (>= 2.17), libc6 (>= 2.2.5), libc6 (>= 2.25), libc6 (>= 2.28), libcairo2 (>= 1.6.0) | libcairo2t64 (>= 1.6.0), libcups2 (>= 1.6.0) | libcups2t64 (>= 1.6.0), libcurl3-gnutls | libcurl3-nss | libcurl4 | libcurl3, libdbus-1-3 (>= 1.9.14) | libdbus-1-3t64 (>= 1.9.14), libexpat1 (>= 2.1~beta3) | libexpat1t64 (>= 2.1~beta3), libgbm1 (>= 17.1.0~rc2) | libgbm1t64 (>= 17.1.0~rc2), libglib2.0-0 (>= 2.39.4) | libglib2.0-0t64 (>= 2.39.4), libgtk-3-0 (>= 3.9.10) | libgtk-3-0t64 (>= 3.9.10), libgtk-3-0 (>= 3.9.10) | libgtk-3-0t64 (>= 3.9.10) | libgtk-4-1 | libgtk-4-1t64, libnspr4 (>= 2:4.9-2~) | libnspr4t64 (>= 2:4.9-2~), libnss3 (>= 2:3.30) | libnss3t64 (>= 2:3.30), libnss3 (>= 3.26) | libnss3t64 (>= 3.26), libpango-1.0-0 (>= 1.14.0) | libpango-1.0-0t64 (>= 1.14.0), libudev1 (>= 183), libx11-6 | libx11-6t64, libx11-6 (>= 2:1.4.99.1) | libx11-6t64 (>= 2:1.4.99.1), libxcb1 (>= 1.9.2) | libxcb1t64 (>= 1.9.2), libxcomposite1 (>= 1:0.4.4-1) | libxcomposite1t64 (>= 1:0.4.4-1), libxdamage1 (>= 1:1.1) | libxdamage1t64 (>= 1:1.1), libxext6 | libxext6t64, libxfixes3 | libxfixes3t64, libxkbcommon0 (>= 0.5.0) | libxkbcommon0t64 (>= 0.5.0), libxkbfile1 (>= 1:1.1.0) | libxkbfile1t64 (>= 1:1.1.0), libxrandr2 | libxrandr2t64, xdg-utils (>= 1.0.2)
Recommends: libvulkan1
Conflicts: cursor
Replaces: cursor
Homepage: https://cursor.com
Download-Size: 195 MB
APT-Manual-Installed: yes
APT-Sources: /home/markjour/Downloads/cursor_3.10.17_amd64.deb
Description: The AI Code Editor.
于是改用 apt 安装成功：
-> % sudo apt install ~/Downloads/cursor_3.10.17_amd64.deb
注意，选中 'cursor' 而非 '/home/markjour/Downloads/cursor_3.10.17_amd64.deb'
将被升级：
cursor
摘要：
升级：1，安装：0，卸载：0，不升级：0
下载大小：0 B / 195 MB
所需的空间：16.5 MB / 625 GB 可用
获取:1 /home/markjour/Downloads/cursor_3.10.17_amd64.deb cursor amd64 3.10.17-1783235114 [195 MB]
正在预设定软件包 ...
(正在读取数据库 ... 系统当前共安装有 381608 个文件和目录。)
准备解压 .../cursor_3.10.17_amd64.deb ...
正在解压 cursor (3.10.17-1783235114) 并覆盖 (3.5.17-1779246638) ...
正在设置 cursor (3.10.17-1783235114) ...
正在处理用于 desktop-file-utils (0.28-1build1) 的触发器 ...
正在处理用于 gnome-menus (3.38.1-1ubuntu1) 的触发器 ...
正在处理用于 shared-mime-info (2.4-5build3) 的触发器 ...
注意： 由于文件'/home/markjour/Downloads/cursor_3.10.17_amd64.deb'无法被用户'_apt'访问，已脱离沙盒并提权为根用户来进行下载。 - pkgAcquire::Run (13: 权限不够)
alias ll="LC_ALL=c ls -hlAF --group-directories-first"
ls 命令我经常会加上 --group-directories-first 参数，将文件夹排在前面。
PS：ls 默认就会按照字母顺序排序。
PS：ls 默认会忽略前导小数点，比如排序 a .b c 这样。我加上 LC_ALL=c 之后就会 .b a c 这样排序。
现在突然发现我的 ll 命令不按文件名称排序了，经过一番研究，原来是现在的 Ubuntu 26.04（我大概在两个月前从 25.04 升级过来）改用了 Rust 重构版本的 coreutils，也就是说一百多个命令都替换成了 Rust 版本。
然后这个版本在处理 --group-directories-first 参数的时候存在兼容问题，甚至可以说是 BUG：这个参数会导致排序规则失效（哪怕加上 Rust 版本新加的 --sort=name 也没有用）。
-> % apt-file search "/usr/bin/ls" | grep -E "bin/ls$"
coreutils-from-busybox: /usr/bin/ls
coreutils-from-gnu: /usr/bin/ls
coreutils-from-toybox: /usr/bin/ls
coreutils-from-uutils: /usr/bin/ls
-> % apt list --installed | grep coreutils
coreutils-from-uutils/resolute,now 0.0.0~ubuntu25 all [已安装，自动]
coreutils/resolute,now 9.5-1ubuntu2+0.0.0~ubuntu25 all [已安装，自动]
gnu-coreutils/resolute,now 9.7-3ubuntu2 amd64 [已安装，自动]
rust-coreutils/resolute,now 0.8.0-0ubuntu3 amd64 [已安装，自动]
关键是 coreutils-from-uutils 直接 Break coreutils-from-gnu，替换了相关文件，而不是通过软链接实现。
现在除非重新安装 coreutils 包覆盖回去，没有别的办法。
我不是 Linux 专家，所以要尊重社区的决定，没到万不得已，不能 Break 他们的设计。
那就只好这样了，暂时不用 --group-directories-first 参数。
阿里巴巴宣布，自 2026 年 7 月 10 日起，全面禁止员工在办公及研发环境下使用 Anthropic 旗下 Claude 系列产品（含 Claude Code），并要求全员卸载清理，同时推荐使用阿里自研 AI 编程工具 Qoder 作为替代方案。
此前，阿里曾鼓励员工使用海内外 AI 辅助编程工具，Claude Code 是程序员高频使用的编码助手，相关外部模型调用费用可走企业报销。
此次变动主要可能基于三方面考量：