毕业后就没怎么写过 C++ 了，几年没关注，现在都已经有原生协程了，有点感慨

当然以前也可以用 boost.context 之类的实现，只不过语法看上去并不优雅便是了

---

题外话，记得上学那会儿为了练手，搞了个 boost.asio 的 PHP binding ，用 PHP 的 generator 实现的协程：
https://web.archive.org/web/20201102142032/https://github.com/CismonX/php-asio/wiki/Basic-concepts-of-php-asio#231-generator

（不过由于水平太菜，做出来的东西性能还不如 AMPHP 之类的纯 PHP 实现，还有内存泄漏的问题不知道该怎么解决，早已删库跑路，哈哈）

@adoal #4

哈哈，点进来之前想的也是 Lynx 浏览器，毕竟每天都在用。虽然猜到这个帖子讨论的是完全不相关的东西。

这让我想起来之前在 V 站搜 Haiku ，本来想看的是 Haiku 操作系统相关的讨论，然而搜到的结果全都是某个 LLM 相关的🤣

对于独立开发者来说，一个简单有效的原则是「 eating your own dog food 」。

优先从自己的需求出发，做自己用得到，而且日常会去用的东西。这样永远不会是「伪需求」。哪怕全世界只有你一个人在用，那它也是「真实需求」。而且你自己是直接受益者。

@GeekGao #22

LLM 应用其实就是新时代的 SaaSS[^1]，隐私问题只是其中的弊端之一。

而且不像传统 SaaSS ，稍微学习折腾下就可以找到本地可用的替代品，LLM 应用是掌握在拥有拿钱堆出来的强大算力的 big corp 手中的，就算把所有的训练数据和程序都「开源」出来（事实上还没有），也不是一般人能用得起的，用几万块钱的顶级 PC 目前也只能跑个别人训练好的小模型玩玩。

不只一次听人说，LLM 就是资本利用自由软件来摧毁自由软件的「阳谋」。这话虽偏颇但不无道理。毕竟 LLM 训练时必定用到了海量的自由软件的源码和文档，反过来却没见到 LLM 对自由软件社区作出过什么突出贡献。至于资本引导控制用户的思维方式，让他们心甘情愿地用自由和隐私换取 LLM 的所谓「便利」，也就不必多提了。

虽然我从来不在自由软件社区以外的地方公开反对别人依赖 LLM 来做事，但在自己的工作和生活中是坚决抵制的，而且不认为这一点点的「不便利」对我而言是一种损失。

---

[^1]: https://www.gnu.org/philosophy/who-does-that-server-really-serve.html

很早以前搞过一个小工具，专治输入法前端「水土不服」的场景： https://www.nongnu.org/arif/
当年是因为 Wayland 对输入法的支持有坑，懒得折腾，就随手搞的这个工具。

不管什么平台，只要有个正常的终端模拟器，能显示中文，就一定能输入中文。

Firefox 用户路过。一直以为是预期内的行为。

MDN 文档只说会 scroll to ，并没有说要不要重新请求当前页面：
https://developer.mozilla.org/en-US/docs/Web/URI/Reference/Fragment#fragment
个人觉得不刷新是更符合直觉的。

或许可以加一个判断，如果用户没有手动修改 fragment 的值，且当前页面已经滚动到了对应位置，按下回车后触发刷新，似乎会更合理一些。

另：早在 20 多年前，Firefox 0.x 的时候，就有人提出这个问题了……
https://bugzilla.mozilla.org/show_bug.cgi?id=186371

如果是非常小的孩子的话，不如先给他推荐几个锻炼逻辑思维能力的解谜类游戏（比如 Zachtronics 家的 Opus Magnum 就是一个不错的选择）。如果他感兴趣，能玩得下去，这时候再让他接触 real-world programming 也不迟。

一上来就灌输冷冰冰的理论知识，可能反而会打击其对计算机相关领域的兴趣（回想起我小时候，家里让我练吉他，搞得手指千疮百孔。现在一看见吉他，手就开始隐隐作痛🤣）

可以试试 Pandoc

对我来说真正的「 macOS 穷鬼开发套餐」是本地跑个 OSX-KVM ，虽然图形性能很差，但拿来做调试已经足够了。

不过如今我直接选择不兼容 macOS 。与其去折腾适配一个连我自己都不会去用的 nonfree 的操作系统，还不如把精力花在改善软件在自由生态下的用户体验。

@loveour #5

CodeWeavers 招聘 Wine 开发者有一条硬性要求就是「不能接触过微软的代码或者逆向过他们的软件」。现在去官网就能看到。

乍一看似乎他们觉得微软的代码过于「屎」，开发者哪怕看一眼就会变得「不干净」🤣。或许确实有这层因素在里面，但主要还是为了规避侵权风险。

作为曾经的应聘者，给这家公司点个赞

之前和他们的创始人聊过，也关注过他们的产品和社交账号。是国内为数不多真正拥抱自由/开源软件的公司，各方面的价值观和我比较匹配

可惜当时到了 homework 的面试阶段时，因为已经有其他公司 offer 了，就没有选择继续。如果现在让我重新选择的话，我会毫不犹豫地选择 Fyde （然而人生没有如果）

后来也推荐过能力强且价值观匹配的（前）同事去应聘，不知道他最后有没有去

或许以后我们还有机会可以共事（现在的我是赋闲在家，一边写小说一边做自己的项目，偶尔给其他项目贡献点代码的懒散状态，暂时不想打工，哈哈）

@codehz #30

但这种写法按标准[^1]会得到一个「实现定义」的值。

> The value of an integer character constant containing more than
> one character (e.g., 'ab'), or containing a character or escape
> sequence that does not map to a single-byte execution character,
> is implementation-defined.

考虑到可移植性，通常不建议使用。
除非你写的代码只应用于特定实现，且该实现对此有明确定义。

比如在 GCC[^2] 中：

> The compiler evaluates a multi-character character constant
> a character at a time, shifting the previous value left by the
> number of bits per target character, and then or-ing in the
> bit-pattern of the new character truncated to the width of a
> target character.

[^1]: ISO/IEC 9899:1999 §6.4.4.4/10
[^2]: https://gcc.gnu.org/onlinedocs/cpp/Implementation-defined-behavior.html

---

声明：本回答并非使用 LLM 生成。

对于 jq 用户来说，这种需求其实挺简单。fromjson 函数完美解决

https://i.imgur.com/q6e1qyK.png

@llmice #3

IANAL ，但看上去确实没有遵守原作品的许可证 CC BY-ND （原作者未指定版本，这里默认 4.0 ）。
因为按版权法，译作通常被视为衍生作品。而许可证中的「禁止演绎」条款禁止分发这类作品。

参考：
- https://creativecommons.org/licenses/by-nd/4.0/
- https://creativecommons.org/faq/#when-is-my-use-considered-an-adaptation
- https://en.wikipedia.org/wiki/Derivative_work

楼主显然是知道这一点的，所以才会到原作品的 GitHub 仓库中提 issue 请求许可： https://github.com/cosmicpython/book/issues/354

@w568w #1

我之前在用 TypeScript 的类型系统实现 Unlambda 解释器的时候也发现了这个问题。跑个简单的字符串翻转都会超过限制，几乎完全不可用。

当时看到有人提了个 patch 来放宽这个限制，但并没有被官方接受： https://github.com/microsoft/TypeScript/pull/29602

没办法最后只能在 README 里让用户手动魔改 tsc/tsserver 代码（

可惜 C# 的类型系统不支持像 TypeScript 和 C++ 那样直接操作 string literal ，还得需要一个额外的编译器来将 Brainfuck 代码编译成那一坨「中间表示」。

（翻了一下楼主历史发言，原来楼主曾经在 .NET 社区提过相关 proposal 甚至还给出了参考实现，哈哈失敬失敬）

@julyclyde #32

是的。见： https://github.com/torvalds/linux/blob/v6.13/include/linux/sched.h#L1025

这里的 pid 就是用户态的 tid ，tgid 则是用户态的 pid

@julyclyde #27

不过线程不共享 PID 已经是遥远的过去了（ LinuxThreads 早在 glibc 2.4 ，也就是 2006 年的时候就不再受支持）。

Linux 2.4 引入了 thread group 的概念，并支持了 CLONE_THREAD 。基于新内核特性的 NPTL （沿用至今的 glibc pthreads 实现）就没有这样的限制。