@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 应用生态的卡顿、缓慢、碎片化几乎都是由于应用商店技术审查不力、较高的开放性和商业竞争导致的。

水过了 https://www.v2ex.com/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 的原因）。

@strobber16 > 没有速记机一样思路的输入法

你要找的是不是宫保拼音： https://github.com/rime/home/wiki/ComboPinyin

另外可以看看这个问题： https://www.zhihu.com/question/653936085 ，大致总结一下就是：

1. 普通键盘对并击的支持很不好，只能用专门的速录机或特制键盘
2. 普通键盘并击的最好历史大赛成绩也和五笔打字员差不多，甚至不一定能超过双拼
3. 打字超过 100 字/分钟，就快要超过思考码字的速度了，再加快已经只有速录的意义了。权衡一下，学习并击的成本不值得

分享一下之前的调研结果。本人小鹤双拼 4 年使用者。

输入速度受平均码长、击键速度、是否有重码、退格概率等影响。

1. 从平均码长（单位：按键/字）上来说：

全拼（已考虑缩写和智能补全）[1]：2.98
小鹤双拼 [2]：2.50
自然码 [3]：2.20 左右
五笔 [4]：2.17~2.48
小鹤音形 [2]：1.80~2.20

结论：即便考虑上你说的「全拼支持首字母缩写」，全拼也依然无疑是码长最长的输入方式。而形码通常能探到下限，接近 2 键/码。

2. 击键速度在主观方面取决于个人练习，客观方面取决于输入方案的键位是否合理、打起来是否不卡手。可以在 [5] 量化评测不同方案的输入移动距离、手指使用频率等。

3. 我个人感觉，重码和选码是最影响输入速度的方面，甚于打字方案本身。因为识别汉字和按数字键选择永远比肌肉记忆慢一个数量级。形码或辅助码在这方面有优势。不过我自己没有用过形码，就不多做评价了。

4. 退格概率主要受输入方案的容错率的影响。一般来说，越是紧凑编码的方案，对输入精准性的要求就越高。所以，这方面全拼反而是最有优势的：无论是 shuang 还是 shuagn 都很容易被输入法自动纠错，但双拼或形码经常就必须退格，对输入速度有一定负面影响。

总体来说，「全拼的平均速度最快，但双拼和形码的上限更高」。如果追求极致的输入速度，经过足够练习后，双拼是能够远超过全拼的。

[1] https://zhuanlan.zhihu.com/p/82897751
[2] https://zhuanlan.zhihu.com/p/491861664
[3] https://xbeta.info/input-skills.htm
[4] https://www.zhihu.com/question/432465117
[5] https://macroxue.github.io/shuangpin/eval.html

借楼问问 supabase 相比直接用 postgresql 有什么优势？我没搞明白这个的优点