我支持 rewrite everything in Rust ，也支持 ISO C working group 宣布 deprecate C 然后当场解散（虽然后者大概率不会很快发生）

但是如果说要在一个发展了 30 余年，全球数亿人在使用的庞大项目中引入新的接口和编程范式，并需要所有项目维护者注意配合，那还是要保持怀疑的态度，谨慎对待

而且从之前接触过的一些案例来看，这些不一定是“乱码”，可能带有加密后的追踪信息。某些小说网站就是靠这个抓盗版的。

再加上知乎有用隐水印追踪用户的前科，不能完全排除这个可能。

如果你没有做好安全措施的话，搞不好现在某些正在看这个帖子的人已经知道你的真实身份了

反爬。很早以前就发现了

浏览器的安全/隐私特性开的越多，越容易触发。比如我这边用了 arkenfox user.js 后，100% 触发

具体规则懒得研究了，反正我也不看知乎

@blacklinux #23
@Diphia #25

不具备 plausible deniability 和 forward secrecy

只要在被审查的信道中传输，如果你是被盯上的目标，第一时间就会暴露
然后攻击者用一把 5$ wrench 就能让你交出 key ，解密之前发过的所有信息

@me1onsoda #41 #42

上大学的时候辅导员劝我们不要“转码”的时候就是这么说的。他认为计算机和软件技术不应该当作一个专业来学，而是应该在学好我们自己专业的基础上，额外地学习计算机技术，从而提升科研、生产效率。

他还说，除非你能成为那一小撮负责顶尖核心技术的研究人员，如果没有点计算机之外的其他专业技能兜底，等到互联网泡沫破碎的那一天，就只能去从事基础体力劳动，985 本硕就当白读了。

辅导员的观点虽然有些极端，但现在来看还是有先见之明的，从今年的码农就业形势就能看出点端倪。可惜当年年轻气盛不听劝，仍然走上了“转码”的不归路。。。

其实这两者之间没有一个明显的界限

根据个人经验来看，如果分享类的帖子里出现以下行为，更容易被移入“推广”节点：

1. 频繁发布同一个项目，哪怕只有微小的更新甚至没有更新
2. 标题党（如果内容还是有点干货的，也许会被饶恕）
3. 引流。比如前面还在分享，后面突然摆出加群二维码，或者留下自己其他无关项目的链接等
4. 过于露骨的商业行为。比如正文中全是没有营养的商业宣传话术，还有“留邮箱送码”（污染评论区）

相比之下，与该项目是否是个人项目或者是否开源无关（虽然这类项目的作者更有可能是抱着较为纯粹的目的去分享的）

热知识，微信还有“已读回执”专利

程序员如果反应不过来的话，属实英语有点差了

我们上小学时，对于 API 、PDF 、HTML 这种常见的缩写早已烂熟于心，甚至同学之间喜欢拿来互相考（小孩子嘛，觉得这种缩写逼格高）

----

印象里那会儿有个英语学习软件收录的一篇文章里就有 #9 这种有趣的 meme 缩写，印象比较深的比如：

IBM: I Blame Microsoft
OS/2: Obsolete soon too

当时为了理解这些缩写，甚至专门去图书馆借书了解了一下计算机软件发展史（没错，那会儿我们小县城基本没有接入互联网，查东西基本得靠书）

大厂是这样的

之前在大厂做内部系统的时候，就连“修正界面上错别字”这种不涉及任何逻辑变更的改动，都需要分别找十几个业务方同步，等他们都确认无影响后才能上线，共耗时 5 个工作日。可想而知，那些涉及到逻辑变更的改动，要多久才能上线

至于为什么要这么做，那就不得不提当年的生产事故。有个业务方在获取数据的时候不去调 rpc 接口，而是直接爬 web 页面。有次我们修改了文案而没有通知下游，导致他们的爬虫获取到的数据错乱，影响生产环境，直接损失数百万元。最后我们全组背锅，绩效 C （意味着年终奖少了 10k+，而且一年内没有晋升资格）。那个业务方也没好到哪里去，据说裁了十几人

牢星真的是拉胯啊

记得去年这个时候还泄露过固件签名私钥来着

@cnbatch #118

也不能算是 glibc 的锅。glibc 的文档里明确指出 free() 是 AS-Unsafe 的： https://sourceware.org/glibc/manual/2.39/html_node/Freeing-after-Malloc.html

而且 POSIX 也没有要求 free() 必须是 async-signal-safe 的。有这个要求的函数列举在这里： https://pubs.opengroup.org/onlinepubs/9699919799/functions/V2_chap02.html

如果一定说是谁的过失，那只能是“将 OpenSSH 移植到 Linux”或者“认为 OpenSSH 在 Linux 上可用”的人，没有充分意识到（或者从测试用例中感知到）不同 libc 实现的差异，从而导致了兼容性缺陷

----

就好比某用户从二道贩子手里买了个进口家电，只支持 110V 交流电，但是二道贩子自己给改装了个国标插头，用户直接插到 220V 市电上，引发了安全事故。这时候用户是应该谴责电网（ glibc ），还是原厂家（ OpenSSH ），还是二道贩子（移植者）呢？

当然还是那句话，开源软件是 provided as is, without any warranty 的，用户应当为自己的安全负责。真出了安全事故，不管是 glibc 还是 OpenSSH 还是任何一个 Linux 发行版的负责人都没有义务补偿他。

That's the price you have to pay for freedom.

@drymonfidelia #6

啊，这个文件是每次启动时生成的，如果你跑完 freebsd-update install 后没有重启，这个文件并不会更新

那你可以跑一下 freebsd-version -u 看下版本号（其实 /etc/os-release 中看到的 VERSION 就是用这个命令获取的，见 /etc/rc.d/os-release ）

@drymonfidelia #4

理论上是没问题的

再看下 /etc/os-release 里的 VERSION 是不是 14.0-RELEASE-p8

14.0-RELEASE-p8 已经修复，但只是打了 patch ，并没有全量更新到 openssh 9.8p1： https://github.com/freebsd/freebsd-src/commit/70eb00f17b310f599b60939c1afa326c7b2c390c

你看一下 /usr/src/crypto/openssh/version.h ，只要 SSH_VERSION_FREEBSD 的值为 "FreeBSD-20240701" 就没问题（保险起见，再看一下 /usr/sbin/sshd 的 mtime ），重启一下服务就好