@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 的老项目并不多

Github 找了下，“练手”项目会用得比较多，大型项目也有在用，只是不算广泛

Linux 内核除了 1 楼提到的，还有类似这种：
https://github.com/torvalds/linux/blob/0e39a731820ad26533eb988cef27ad2506063b5b/include/linux/seqlock.h#L252

#define __seqprop(s, prop) _Generic(*(s), \
seqcount_t: __seqprop_##prop, \
__seqprop_case((s), raw_spinlock, prop), \
__seqprop_case((s), spinlock, prop), \
__seqprop_case((s), rwlock, prop), \
__seqprop_case((s), mutex, prop))

用 _Generic 辅助做拼接


NetBSD 的 indent 用到了：
https://github.com/NetBSD/src/blob/80dbdd9020fb73df509a4d01b0eac6b73d43b29e/usr.bin/indent/args.c#L56

#define get_offset(name, type) \
_Generic((&opt.name), type *: offsetof(struct options, name))

应该是用作类型安全的 offsetof


FreeBSD 自身暂时仍未用到 _Generic ，但引用的第三方工具用到了

https://github.com/freebsd/freebsd-src/blob/d888317796190bec350aea3701b8aed3bfdad4c8/contrib/tzcode/private.h#L870

# define TIME_T_MIN \
_Generic((time_t) 0, \
signed char: SCHAR_MIN, short: SHRT_MIN, \
int: INT_MIN, long: LONG_MIN, long long: LLONG_MIN, \
default: TIME_T_MIN_NO_PADDING)

对应的来源应该是这个
https://github.com/eggert/tz/blob/main/private.h

@HarveyLiu 好奇问问，Debian 运行在虚拟机内，CPU 是 AMD ，那么也会有性能提升吗？

我虚拟机内有 Debian 12 ，过多几天再升级

这段时间先观望下各种踩坑经历、解决方式，有备无患

说起“摆烂”，我是出于这种考虑：从 BSD 到 GPL ，可以直接全盘照抄。然而从 GPL 到 BSD ，这是行不通的，必须净室重写，虽然不是从头开始，但也算不上多么简便。可见 GPL 抄 BSD 代码比起 BSD 抄 GPL 代码简单得多。

除此以外，Hurd 不选择从 Linux 抄代码而是从 NetBSD 抄代码，出乎我意料。

@gullitintanni 要求高？我可没提过任何要求，单纯做评价。

再说了，目前 NetBSD 和 OpenBSD 几乎也是纯用爱发电，社区捐赠长期低迷，仍能一早就支持了 64 位硬件，即使是长期近乎荒废状态的 Haiku 系统也都有 64 位版本、RISC-V 版本。

而同样的状况下，GNU/Hurd 到现在才支持 64 位，至少我是觉得挺唏嘘的。

我倒是很乐意它能发展到跟 Linux 分庭抗礼，多一个选择总不是坏事。

既然操作对象是 Windows ，那就不要用 Linux 思维去干这种事
楼上各位给出的 WinPE 迁移方案都适合，照做就行