V2EX › cnbatch 的所有回复 › 第 2 页 / 共 81 页

V2EX = way to explore

V2EX 是一个关于分享和探索的地方

现在注册

已注册用户请登录

1 2 3 4 5 6 7 8 9 10 ... 81

❮

❯

85 天前

回复了 Tucao 创建的主题 › 宽带症候群 › 电信限速投诉后进入了一个更加高级的限速模式

OP 测速有点“狂暴”
怎么说呢，UDP 一上来就 100M ，明显不妥，须知道 UDP 测速是没有拥塞控制的，流量远超签约带宽被中间节点一刀切地丢包都不奇怪

正确做法是从小流量往大流量逐个试，比如试 5 次，100K 、1M 、3M 、10M 、20M 慢慢来，这样才可以试出真实的速度，同时看得出网络通畅情况

86 天前

回复了 cnbatch 创建的主题 › .NET › 知乎网友：“VS2026 还是跑在 .NET Framework 4.8 上，看来 .NET LTS 只有三年的问题还真把微软自己的脖子卡住了”

@LuJyKa 目前 Windows 环境确实是 .Net Framework 4.8 比 .Net Core 更好，不但有兼容性、能用新语法，而且还不怕各种安全审计软件的扫描

有些审计软件扫到过期的 .Net Core 就生成一份违规报告，倒不如 .Net Framework 4.8 更加省心省力

94 天前

回复了 tangmanger 创建的主题 › 数据库 › 你们平时手撸 SQL 多吗？还是 ORM 优先

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

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

95 天前

回复了 VforGeek 创建的主题 › NAS › 运营商网间 QoS 怎么应对？

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

95 天前

回复了 VforGeek 创建的主题 › NAS › 运营商网间 QoS 怎么应对？

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

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

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

100 天前

回复了 SpaceTime 创建的主题 › 职场话题 › 意向换行业, 求助业内大佬给一点建议

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

103 天前

回复了 LXGMAX 创建的主题 › 程序员 › 不要轻易升级 Visual Studio

可能是因为 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

103 天前

回复了 wuruxu 创建的主题 › 程序员 › 除了浏览器, 还有哪些应用，大家会开很多 tab 的情况？

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

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

104 天前

回复了 ceeji 创建的主题 › NAS › QNAP 的 NAS 把我坑惨了

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

105 天前

回复了 hwdq0012 创建的主题 › 程序员 › zsh 的 file 工具和 Linux 自带 file 相比，还比较含蓄了

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

FreeBSD 的输出：
b: symbolic link to a

NetBSD 的输出：
b: symbolic link to a

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

105 天前

回复了 hwdq0012 创建的主题 › 程序员 › zsh 的 file 工具和 Linux 自带 file 相比，还比较含蓄了

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

105 天前

回复了 JasonLaw 创建的主题 › 程序员 › 广州汇丰的考勤也越来越严格了，一周最少要去公司两天

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

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

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

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

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

106 天前

回复了 tellmeworld 创建的主题 › 程序员 › 有没有家里小孩学完市面上的 Python 课程的，接下来可以做什么？

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

106 天前

回复了 JasonZhou 创建的主题 › Windows › 各位有没有碰到过 Win11 有概率无法复制文件的问题

用命令行复制呢？

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

106 天前

回复了 JasonLaw 创建的主题 › 程序员 › 广州汇丰的考勤也越来越严格了，一周最少要去公司两天

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

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

另外，建议尽量低调

107 天前

回复了 nickytsui1862 创建的主题 › 宽带症候群 › 广州电信，下单申请移机刚付完款公网 ipv4 直接没了

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

108 天前

回复了 cnbatch 创建的主题 › 程序员 › 人工写代码不能随便抄开源代码，就连 AI 输出代码都不能随便输出？

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

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

109 天前

回复了 cnbatch 创建的主题 › 程序员 › 人工写代码不能随便抄开源代码，就连 AI 输出代码都不能随便输出？

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

113 天前

回复了 zanx817 创建的主题 › 宽带症候群 › 从应用角度来说， IPv6 是否可以说，彻底失败啦？

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

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

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

113 天前

回复了 zanx817 创建的主题 › 宽带症候群 › 从应用角度来说， 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 差不多

1 2 3 4 5 6 7 8 9 10 ... 81

❮

❯