@bbao 别啊，我现在工作了，虽然时间不长。或许是看到了我的历史帖子，那是我注册 v 站的十周年纪念，不是说今年（

@geelaw #34 其实 936 是包含了平片假名的，只要没有生僻字勉强还行（
所以我也很好奇其他 posix 程序是怎么移植过来的，毕竟大多数 API 都是 char *，到最后一步再转成 LPCWSTR 么，好像也有问题。

好在 Windows 10 1903 往后可以通过 manifest 指定 code page 为 UTF-8 (65001)了，以后 ANSI API 应该还有发展空间：
https://learn.microsoft.com/en-us/windows/apps/design/globalizing/use-utf8-code-page

@geelaw #5
@yk000123 #29

抱歉，其实是因为完整的代码逻辑很长，这里是我随手举的例子，没有完全说明清楚。传入的路径是标准化后的绝对路径（如 realpath() 处理后的字符串），所以不考虑 ./ ../ // 等情况了。移植到 Windows 上是做了 #ifdef _WIN32 处理的, Linux 上不做反斜杠判断。

@geelaw #6
Linux 上确实可以不是 UTF-8 ，正如中文 Windows 上也不一定是 GBK （可以手动改成实验状态的 UTF-8 ），但可以认为已经成为了事实上的标准。绝大多数用户使用默认配置就是这种情况了。

@w568w #12
在 UTF-8 上应该是可靠的（只要不是去数字符数的话）。这里的困境是：我也知道有问题，但是似乎没有办法简单解决。正如需求就是简单的数斜杠，那么真的需要引入一个 Unicode 库吗，其实我自己也是怀疑的（？）
另外 mbtowc()，wc 是 widechar 吧，不是 NULL 空终止。

@minami #22
其实是说我的代码有 BUG 啦，这个代码确实学艺不精，其实我也想知道 *应该* 怎么写，或许你也可以举个例子 hhh 这是很多人都会犯的错误。但在 UTF-8 ，它是允许你这么遍历的。一个是方便我这种懒人，二是让那些欧美地区人写的这类代码也能正常跑在中文上。
比如说 strstr() 找子串，GBK 是用不得的。utf-8 在不引入第三方库下就能这么找，是不是挺省事？；）

应该和我一样，之前有发帖：/t/1118730

@hronro 使用 WebRTC 的话 是可以 UDP 的

@ysc3839 #14
不应该，可以重新执行一下：
~/.vscode-server/code-latest --patch-now

上面会显示被修改的文件。比对一下就知道了。

也可以确认下 VSCode 客户端和服务端的版本号是否匹配：
~/.vscode-server/code-latest --version

不同版本的 server 路径不一样。

@yanqiyu 这不就是 NFS 嘛，D-state 还 kill 不掉（悲）

@est #29 其实这不是解压软件的问题，而是 OS 抛出错误后，应用继续往上抛了而已。我来解释一下实现重试的难点。

假设应用通过 fopen()打开文件，fread()到一半出错了，这个时候如果重新 fopen()，会面临一个版本问题：我重新读的文件还是原来那个吗？有没有被修改过？这些应用都不能判断。

虽然这些是 corner case ，不过一旦遇到都是 bug ，可能造成数据丢失。最保险的做法就是将错误原样抛出去，fail-fast 思想。

这个应当是 OS 层面的责任，比如 macOS 在 SMB 连接断开时，应用尝试 read()并不会立即失败，而是阻塞住直到连接恢复（或者超时几分钟后失败），通过 SMB 协议确保读到的文件没有发生改变。我不太熟悉 Windows 上的机制，不过可以确定这个在应用层是没法处理的。

这种情况网不行也没什么好办法啊，网络会中断就先解决网络问题。

或者 NAS 和电脑之间套一层 WireGuard ，物理链路中断时，WireGuard 并不会断，等恢复就好了。

要么就 NAS 电脑网线直连，配静态 ip 传输。

要么就把电脑硬盘拆下来，塞 NAS 里内部传输。

@tt0411 #9 是的，我这里就是简化了所有步骤：

- 将 patchelf 做成了 libpatchelf 静态编译进去 (libpatchelf/libpatchelf.h)
- 自带编译好的 glibc 和 libstdc++
- 修改了 glibc ，将系统目录改为当前目录，这样改 .interp 就行了，不用再改 rpath 。事实上这么做也更安全。(patches/glibc.patch)

然后加上了额外的功能，就是自动处理插件。官方的方案只能让 server 能用，实测很多 native 插件还是不行的。

做的就是一个开箱即用，不用配参数。

@hanxiV2EX #3 因为我写 C 和 C++，还是需要旧 glibc 编译的，所以 docker 这条路就行不通了🤦‍♂️

@nagisaushio #1

其实原先我也是直接 patchelf 的，但是插件会有些问题。

比如 C/C++ 这个插件，就算 SSH 插件能正常用了，但它还是没法启动 gdb 调试，因为插件里 OpenDebugAD7 这个二进制也需要最新的 glibc 。https://github.com/microsoft/vscode-cpptools/issues/13219

所以这个还做了额外的工作，使用 inotify 监控 extensions.json ，检测到安装新插件时，自动给插件打补丁。然后还判断是否为 glibc 的二进制，排除使用 musl 的二进制（有些还是 musl 动态链接的）。

@phithon 似乎是 GitHub 的防火墙配置错了？现在国内又可以正常访问了😂

有可能就是群发的。N 年前我读初中时就收过类似邮件，当时还挺高兴。后来网上查了一下发现是群发的，对方是用爬虫抓取的 GitHub 信息。

这类 AI 公司可能在爬虫基础上还加了 AI 分析，投放更精准😂

挺合理的，而且我会把为什么出 bug 、bug 是什么样的表现、怎么修的等大致思路等等都写上。
以后遇到类似问题或需要复盘的时候，翻找起来很容易。很多时候，人的记性没想象的那么好，多写点没什么坏处。
除非是开发的一次性工具，用完就再也不维护的那种，那就随意了。

感谢各位的回复和建议，现在我 C++和 Java 的简历两边投，看谁愿意接受了😂

我把 C 的岗位（如内核开发）算进来的原因是，我在 C++招聘信息板块看，确实看到了这些。HR 不做区分，而且也明确会招 C++开发，即使工作语言是 C 。虽然现在两个语言互不隶属，但是大多数 C++开发者去写 C 是没有问题的（尤其像我这种因为项目规范禁用 STL 、RTTI 的 C++98 开发）。因此我也考虑 C 岗位。描述中产生了混淆，非常抱歉。#61 @slideclick

另外赞同 #50 @metmit 的说法，国产 DB 非常卷，而且基本只招对 DB 内核有深入了解的人（我就不大行）。好些需求技术含量并不高，比如支持国密，支持 GB18030 ，都是在调库，这些工作也不会专门社招个人来做。

@javak #3 算不上牛人 hhh 其实内核部分也分层，我目前也就熟悉做不同 SQL 方言的语法兼容解析，对象元数据等等比较浅层次的，数据存储、执行器、优化器等等深层次的理解还是很令人头大。

@wogogoing #4 TiDB 应该是 Go 语言吧，也不大一样。投过别的数据库厂商，可能是学历或者是经验不足，面试机会都拿不到：（

@BD8NCF #5 感谢，这也是一个方法，我去了解了解 Qt 。

@miniaoes #6 哈哈哈，其实我目标就是能跳槽，C++ 能互相匹配的岗位很少，Java 通用性强多了

@L4Linux #7 果然还是学历啊，是低了点...