@julyclyde https://peps.python.org/pep-0011/#tier-3

看起来是在这里写入的： https://gitee.com/openeuler/security-tool/blob/master/security.conf#L113-123

理论上来说，/etc/motd 是被 login(1) 打印的，/etc/issue 是被 getty 打印的，/etc/issue.net是被 telnetd(8) 打印的。初看是冗余设计，但实际上面向是三个不同场景：

- /etc/motd：显示在登录后需要提示的今日消息（ message of the day ），由管理员设定，相当于管理员的公告；
- /etc/issue：从 getty 登录（例如实体机上）时显示的信息，用于识别机器的身份；
- /etc/issue.net：从 telent 登录时显示的信息，也用于识别机器的身份。

而要在 SSH 登录时显示的信息，则在 /etc/sshd_config 的 Banner 项中设置。

之所以会打印两遍，是因为上面的配置还写了 `Banner /etc/issue.net`。所以你看到的分别是 /etc/motd 和 /etc/issue.net 。

至于为什么这么配置？安全的事你少管（狗头）……

另外，Python 3.14 已正式在 Tier 3 级别支持 Emscripten 平台。这将允许在 WebAssembly （ wasm32-unknown ）上运行 Python 。

@PrinceofInj > 从 jvm 切换到 art

Android 从来没有使用过（上面评论里定义的） JVM 。Android 4.4 之前使用的虚拟机是 Dalvik 。同样的，JVM 字节码（.class ）需要再编译为 Dalvik 字节码（.dex ）才能运行。与 ART 不同的是，Dalvik 只支持 JIT ，而 ART 支持 AOT ，因此以更长的安装和 OTA 后首次启动时间换取了更快的运行速度。

至于说「没什么变化」，可以直接参考早期的一些研究测量： https://www.diva-portal.org/smash/get/diva2:852736/FULLTEXT01.pdf 。性能差异从 +5%~95% 不等。体感终究是不准确的。

@RichardLuo0 最后一句是说：

应用商店技术审查不力 => 卡顿、缓慢
（系统）较高的高开放性和（国内厂商间）商业竞争 => 碎片化

https://sourceforge.net/p/veracrypt/discussion/general/thread/e34d4ee198/

Mounir IDRASSI （ VeraCrypt 原作者）

我很高兴现在告诉大家，我和我的家人已经在日本定居，具体来说是神户市。这次搬家对我们个人和职业生涯来说都标志着一个重要的新篇章。为了澄清并消除任何猜测，我妻子是日本人，我们结婚已经十多年了。从 VeraCrypt 成立之初，她就一直是我们坚定而持续的支持，我们共同决定搬迁，是为了家人的幸福。

随着此次转型，我还在日本以 AMCrypto 的名义推出了一项新业务 ( https://amcrypto.jp )。IDRIX 将继续在法国以最低限度的规模运营，但我的主要业务将通过 AMCrypto 在日本开展。作为此次转型的一部分，您可能会注意到网站链接和资源的一些变化。例如，https://veracrypt.jp 已经上线。虽然它目前是现有网站的镜像，但未来将逐渐成为 VeraCrypt 的主要中心。

我想向大家保证，我对 VeraCrypt 及其社区的承诺将一如既往。开发和支持工作将继续进行，我对新环境带来的机遇感到兴奋。

再次感谢您一直以来的支持、耐心和理解。我期待着恢复正常运营，并继续与大家携手合作，让 VeraCrypt 更加完善。

2025-04-21

@dxppp 感谢。不过我看到官方论坛上有人说：

> You're better off not using Kindle Create. It's full of glitches, and its main purpose in life is to lock people into the KDP mini-verse...
>... the majority would say do not use kindle create

所以我不确定 Kindle Create 有没有其他设备的兼容性问题？

@EngAPI @anzu 感谢，我去了解一下 Sigil 和 pdf-craft

ebookPK 看了下官网，有种上古神器的感觉，先收藏了

@KMpAn8Obw1QhPoEP pandoc 这种通用工具转换后的 compliance 如何？我总感觉这种支持越广的「多面手」，对每一个特定格式的支持就越差

贫道掐指一算，观施主今日之困惑，实乃天时、地利、人和三未能圆满所致。待贫道为您细细解来。

i9-14900K 的生辰八字曰：癸卯年壬戌月丁未日丙午时，命中水（癸、壬）火（丁、丙、午）土（戌、未）三足鼎立，唯独五行缺金。

Windows 商业气息浓厚，在五行中偏金，而 14900K 命里缺金，遇上 Windows 这块「巨金」，二者一拍即合，金火相济，自然顺风顺水，安装无碍。

Linux 崇尚自由、灵活与定制，属木，象征着生长、变化与生机。按理说，木能生火，本是好事。但问题在于，14900K 这把火，是丙午劫财之烈火，实在太过旺盛。

且今日之柱为「丁未」（乙巳年 乙酉月 丁未日），与 14900K 的生日「丁未」完全相同！此谓之「伏吟」，意味着其本身的特性被无限放大。也就是说，它今天火旺性燥，更不愿意去适应 Linux ，固执己见。

所谓「道法自然」，寻一「金」或「水」日，此为「天时」；借庚金以固本（更新固件），择吉木以共生（换发行版），此为「地利」；待准备妥当，心平气和，再行尝试，此为「人和」。届时，天时地利人和齐备，定能达成「木火通明」之佳境。

善哉，善哉。

----

（随手一写，仅供娱乐。有参考 Gemini ）

@humbass 选择了单线程模型，就很难去做基于内存共享的多线程了。

不过，不管是 Node.js 还是和它类似建模的 Dart ，确实是提供了基于消息传递的多线程实现：Worker threads 和 Isolates ，并不是没做。所以我不太清楚你说的「应该要提供」是什么意思。

@2bad4u 知识性错误：Android 跑的不是传统意义上的 JVM ，是 ART 。ART 最多能算是一种 JVM 的 reimplementation ，但在资源消耗和启动速度上差异极大。几乎可以说，除了都是从 Java/Kotlin 语言编译，ART 和 OpenJDK VM 没有多少实际相似点。

一个例子是，Android 实现 Java 8+ 的新语法特性，几乎都是靠 D8/R8 解糖来实现的： https://developer.android.com/studio/write/java8-support ，并且对支持的 Java 特性也有明确的清单。

因此，通过把 Android 描述成「一个 LINUX 上面跑了一堆 JVM 」并不能说明架构臃肿，可以说「桌面 Java VM 冷启动慢、占用大」，但和 ART 没什么关联性。国内 Android 应用生态的卡顿、缓慢、碎片化几乎都是由于应用商店技术审查不力、较高的开放性和商业竞争导致的。

水过了 t/1163189

@Cu635 微信官网： https://linux.weixin.qq.com/

@klesh 不支持 Wayland 。张小把 Qt 砍得只剩 xcb 后端了，只能 XWayland 来运行。不过我目前没发现有兼容性问题，输入法之类的都正常

1. 这个在参数里写的很清楚了：「支持移动/联通/电信/广电 5G/4G 等网络。双卡使用说明：支持 5G SA 」，https://www.vivo.com.cn/vivo/param/iqooz10turboplus

我也同意楼上，倒不是什么 v 不 vivo 、i 不 iqoo 的问题，是这个价位现在基本都在砍 NSA 。其他品牌也差不多

2. 你自己发的链接说得挺清楚了，这个没得洗，就是国内厂商懒，都没兼容 OAuth 2.0 （或称 Modern Auth ），微软去年把 Basic Auth 协议停了，国内直接摆烂不跟进了。

技术客服倒是也不算说错，Basic Auth 在个人账号上确实被微软限制了。

我比较好奇「系统自带邮箱支持 Exchange ActiveSync 」是哪里说的，是 iQOO 官方吗？

@alleluya #89 如果你是指抽象的输入方案，确实打不出；如果你是指官方开发的「小鹤音形输入法」这个软件，那它是能打出的。

就好比：「全拼方案」本身也打不出不会读的字，但「搜狗输入法」可以打出。「 u 或 ` + 拆字」是一个实际软件的辅助功能，而不是加进音码方案定义的东西。所以我不太清楚你想问什么。

@alleluya #87 小鹤音形=小鹤双拼+小鹤形码。实际上是要求你一个字既会读又会写，从两个角度筛选来获得低重码率。如果只会写要用纯形码才能打出来，比如五笔。

至于你说的拆字，这种就属于不同输入法方案的附带小功能了。例如万象拼音，假设不认识「雨辰」合起来的字，用反撇号引导：「`yuif 」（ yuif 是小鹤双拼的 yu chen ）就能找到 震、、 等等。

@w568w 笔误：5 中的「继承了 GraalVM JIT 」应为「继承了 GraalVM AOT Cache 」。

> GraalVM for JDK 24 是作为 Oracle Java SE 产品组件获得许可和支持的最后一个 GraalVM 版本

我从上面的 Reddit 帖子摘一些内容吧，我也差点被误导了：

1. GraalVM for JDK 根本没死，死的是「 Java SE 产品中的 」 GraalVM 。Oracle 的 GraalVM 项目负责人也证实了这一点。鲜为人知的是，Oracle JDK 包含了 GraalVM JIT （即在运行时使用 Graal 编译器进行即时编译的选项）。看起来，这个选项可能并没有取得预期的商业成功，因此 Oracle 从 Java SE 中移除了 GraalVM JIT ；

2. GraalVM for JDK ，尤其是其中的 Native-image 和 Truffle 项目，没有任何停止或删除；

3. Oracle 将不会再投资这个项目了，因此可以预见维护会放缓。但是亚马逊、微软、IBM 、Red Hat 均有贡献，不至于因为 Oracle 离场被扼杀；

4. 这意味着购买 Oracle Java SE 商业版本的用户将不再获得该产品中包含的 GraalVM JIT 和 Native-image 的技术支持。它将成为一个独立的组件；

5. Project Leyden 是另一个故事：它确实继承了 GraalVM JIT ，但和 Native-image 没有直接关系（而后者才是大部分 Java 用户使用 GraalVM 的原因）。