@chingyat 是 mac 的命令行工具版本太旧了

昨晚花了点时间在小红书搜了下相关信息，发现一个有意思的现象

抱怨者、讨论者绝大多数贵公司员工，没人安慰。须知道通常比较离谱的事情，总有陌生人出来安慰的。

为什么没人安慰？看看那些专发金融新闻的账号就知道了。

其中一个人是这么写的：
“汇丰银行 WFH 大缩水，一看只需要在公司 3 天”
“是谁破防了？”

陌生人只会觉得贵公司仍然能维持 WFH 属实羡煞旁人，不会觉得“差”，只觉得那是恢复到 2020 年之前的寻常工作时间

个人认为接下来可以学音乐（唱歌、乐器），既有趣又实用，终身受益

用命令行复制呢？

而且如果 PE 能复制，或许需要考虑下是不是杀毒软件在捣乱

看了下相关新闻，虽然他们想越来越严格，但是工位短缺

HSBC Asks Managing Directors to Work in Office Four Days a Week
https://www.bloomberg.com/news/articles/2025-07-29/hsbc-asks-managing-directors-to-work-in-office-four-days-a-week

HSBC considers three-day return to office for all employees
https://www.thebanker.com/content/424d4000-6c3c-424b-ba5a-39ddcf57211d

HSBC leases new Canary Wharf office after return-to-office desk shortage
https://www.thetimes.com/business-money/companies/article/hsbc-stays-at-canary-wharf-after-post-pandemic-downsizing-error-fzdpk5jv0

另外，建议尽量低调

移机完成后，公网 IPv4 试试能不能要回来

@lixile 一百多个字符确实短得离谱，要是像 8L 提到的那种特殊情况，AI 的输出说不定频繁“撞墙”没法看

看得出目前业界对于相似度的判断标准算不上成熟，实在粗暴又死板，十分无奈

@wunonglin 我发这个帖不是“想不通”，而是吐槽 Github 的限制过于死板
2L 已经提到了可能的后果

对于 64 位版本 IP 地址还可以多讲一段

地址位长扩充后，意味着现有 IPv4 的协议报文的 Header 装不下这么长的地址，必须使用新的 Header ，这样一来跟 IPv6 的状况一模一样

于是又可以再重新讲刚才提到过的，都搞成这样了，不如索性直接扩充到 128bit——也就是现在的 IPv6

我有一段时间也曾经思考过，如果真的出了 64 位的 IP 地址会不会更好一些

经过简单推理，发现推广步骤其实跟 IPv6 没什么区别：

1 、提出草案
2 、标准化
3 、现有操作系统向网络栈源码添加新版 IP 地址的支持
4 、告知业界，可以切换到新版地址
5 、业界发现，现有程序需要修改源码才可以支持新版 IP 地址

这样一来，无论新版 IP 地址方案是否激进，推广起来的难度都是相同的

除非 64 位版本 IP 地址仍然采用点分十进制，并且现有程序经过重新编译+简单修改就能支持新版 IP 地址，那么推广难度才会降低，但会带来其他麻烦事

考虑到继续沿用点分十进制可以较容易地兼容现有 IPv4 地址
192.168.0.1 以 16 进制表示就是 C0 A8 00 01

那么扩充到 64 位版本，看起来就像是这样的：
00C0 00A8 0000 0001 依然是 192.168.0.1

至于地址范围、子网掩码，那就一点都不好看了：
IPv4: 192.168.0.0 ~ 192.168.0.255 / 255.255.255.0
64bit 版 IP: 192.168.0.0 ~ 192.168.65535.65535 / 65535.65535.65535.0

然后会见到这种地址：
65432.23456.12345.54321
加上端口号，那就是：
65432.23456.12345.54321:10443

手动输入的难度确实比 IPv6 低，然而会有这些缺点：
第一：127.0.0.0 这个范围会造成更加严重的地址浪费
第二：容易使人混淆，输入 IP 地址的时候，可能会搞不清楚自己输入的是 IPv4 还是 64bit 版 IP
第三：程序容易出 bug ，而且 debug 的时候容易搞不清楚到底是否正确提供了 64bit 版 IP 的支持
第三点解释：例如读取到地址是 192.168.2.5 ，需要与这个地址通信；但很显然的是，程序自身不需要读取子网掩码，那么这时候应该把地址交给 IPv4 栈呢，还是交给 64bit 版 IP 栈呢？必然会混淆、混乱

既然容易出 bug ，那就不如改成冒号？于是地址范围、子网掩码就变成
192:168:0:0 ~ 192:168:65535:65535 / 65535:65535:65535:0

同样的加上端口号：
65432:23456:12345:54321:10443
Log 里面大量出现这种文字，一定会眼花
无论是运维还是程序员，都未必能一眼看出写 Log 的代码是否正确记录了端口号

那就加上中括号吧，于是就变成
[65432:23456:12345:54321]:10443

说实话，都搞成这样了，不如索性直接扩充到 128bit——也就是现在的 IPv6

---

当然啦，还可以做另一种点分方式：
例如前面提到的 00C0 00A8 0000 0001 ，这样写：0.192.0.168.0.0.0.1
子网掩码：255.255.255.255.255.255.255.0

长一些的地址：
65432.23456.12345.54321 变成 255.152.91.160.48.57.212.49
对应 16 进制：FF 98 5B A0 30 39 D4 31

程序倒是能正确选择哪个网络栈了，但用户的眼花程度其实跟 IPv6 差不多

@msg7086
还有 itsfoss 的这句
Other changes include the removal of GNU Screen and Byobu terminal multiplexers in favor of Tmux.
同样引导着读者认为是“screen 和 byobu 被删、由 tmux 取代”

可以同时去投诉两个网站

我标题直接写着，“默认不再提供”，意思明显就是“不再预装”呀

而且新闻原文还真的想让读者认为是 wget 被 curl 取代：
this change won’t be too impactful as wcurl is a sufficient drop-in replacement.

所以我还是要重讲同样的话：那也是原文小编的锅，不妨直接投诉小编

为了防止 bug 从“修好-重现-再修好-再重现”来回出现，我从 Win10 起已经改用多个“键盘布局”的方式，多年下来发现其实这样更省心
反正 Shift+ALT 按起来不算慢

@msg7086 wget 原本待在 default seed 当中好好的，现在从 default seed“换座”到主仓库待着，default seed 空出来的位置改成 wcurl 占用，至少对于 default seed 而言，相应位置就是“wcurl 取代 wget”了

而且我从来没提到“删除”二字

如果说原文提到“删除” (Removed)，那也是原文小编的锅，不妨直接投诉小编

@cnbatch 手滑
“（预防措施）” -> （预防措施：手动安装 wget ）

@w568w 有没有别名映射暂时是个谜，新闻没讲

omgubuntu 网站有一句话是这么说的：
However, those who rely on scripts or dependencies that expect wget may want to reinstall wget, even if only as a precaution.

如果需要用 wget 的脚本有可能无法正常运行（预防措施），看得出新闻小编也不知道有没有别名

但 wget 本体肯定不再默认安装的了

还有另一个做法：走一趟电信营业厅，用他们的免费 WiFi 上传数据
如果速度不行，多跑几个营业厅，总有速度快的

既然都是电信，并且在路由器直接 ping 两地都丢包，开热点 ping 也丢包，那就直接找电信，由他们来解决

个人观点：

Linux 源码对于 _Generic 的大部份用法基本上就是常规“重载”式用法，而最值得关注的是使用 _Generic 做拼接，这个实用性不错

NetBSD 的 _Generic 配合 offsetof 非常好，起到了强制类型安全的作用，值得推广

比较遗憾的是，升级到 C11 的老项目并不多