有如果有合规检查的话，那就一律用 ORM ，并且是合规认可的 ORM ，一旦出现 SQL 漏洞之类的，可以甩锅

不需要合规检查，那就怎么简单怎么来，短语句手写，“长篇大论”式语句可以交给 ORM

@cnbatch 没写完就发出去
换成移动网络访问 10086.cn 网站，1 秒加载完成

目前来看，很难应对
通用的做法，要么找三网 BGP 的机房中转，要么境外绕一圈

因为不同地区的 QoS 策略并非完全一致，HTTP 欺骗头不是每个区域的运营商都有效（或许北京有效也说不定，需要自己试试）

我用广东电信宽带访问广东移动 10086.cn 网站，本身就已经是 TCP + 真实 HTTPS ，晚高峰时照样卡顿，一分多钟才加载完成

觉得 WPF 比较难的话，还有兜底技术：WinForm ，拖控件就能干活，唯一麻烦的是自定义控件（比如速度表盘之类），找些开源库可以缓解麻烦
工厂 GUI 用 WinForm 并不少，对于 OP 来说应该不难适应

可能是因为 17.14.11 删掉了好几个旧版 SDK：
10.0.18362.0
10.0.20348.0
10.0.22000.0

如果 Fluent UI 库硬编码指定使用其中一个，那么肯定会出错

如果可以自己手动改 SDK 版本，那应该可以解决

升级前最好阅读一下 Release Notes
https://learn.microsoft.com/en-us/visualstudio/releases/2022/release-notes

如果不限于 macos 的话，那就是

文件资源管理器
文本编辑器、代码编辑器、IDE 界面
命令行窗口，不仅仅多 Tab ，更经常多窗口多 Tab
WinSCP 和 FileZilla
Paint.NET

不放心的话，硬盘拔下来插到其他电脑，再扫描一遍坏道，过了就可以放心用

mac 的内置命令行工具应该很久都没更新过了，上游的工具都早已迭代了很多个版本

FreeBSD 的输出：
b: symbolic link to a

NetBSD 的输出：
b: symbolic link to a

OpenBSD 的输出：
b: symbolic link to 'a'

@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 取代”

可以同时去投诉两个网站