我的意思是没必要等 umount.target 来 umount 移动硬盘

udisksctl power-off 应该足以发送停转指令

只是 umount 移动硬盘，不是根分文件系统

我觉得应该在 Before=umount.target 调用 udisksctl unmount 和 udisksctl power-off 就行了

USB 硬盘应该用 udisksctl 吧？

但是才一百多个连接就不行了吗（

这河里吗 https://wiki.archlinux.org/index.php?title=Wayland&diff=prev&oldid=865727

不论是压缩内存还是换出到硬盘都只适合处理较冷的内存，热的内存还得真正的物理内存

working set 超出内存大小了 swap 也救不了（

不一定，有的时候会卡死，有的时候会触发 OOM killer

局域网开一个 CacheServer（

webkit2gtk 实际上也并不轻量

最吃性能的还得是浏览器（

它又不在 pidns 里面

主进程退出之前可能会造出来很多僵尸进程

那样行为会有问题的，绝大部分程序不会想到自己要成为 pid 1

我觉得这是徒劳（

开了 pidns 的话在沙盒内也会有一个 fork 出来的 bwrap 进程，cmdline 和父进程一样但是作为 pidns 内的 pid 1 进程，只收养孤儿进程

不太清楚

但这个确切行为也没那么重要，弄清楚顺序就足够了

可能是对根目录的处理？算了不瞎猜了（

那就是内核行为了，我也不是很清楚具体原因，总之确实是这么个行为，可能是安全措施吧

因为 bwrap 的 --bind 实际上是 rbind，非特权 user namespace 只允许 rbind

后挂载的挂载点会覆盖先挂载的，而不是“自动合并”

是 --bind / / 把之前的挂载点覆盖掉了

明显顺序错了（

需要用 580xx，你可以翻一下之前的新闻

不要总想搞个大新闻（ nix 重点是对于包版本的处理，让每个包都依赖特定版本的依赖项，且不同版本可以共存。这个项目只是随便搞了个声明包名而已，没什么价值

pyinfra 的子集罢了

看上去这个包等于是 vendor 了一份 cef-bin 吗

不是很清楚了（

不过我没尝试 umu-launcher

00000000002536d0 g DF .text 0000000000000059 Base PyType_GetBaseByToken 0000000000242170 g DF .text 000000000000009e Base _PyType_GetBaseByToken_Borrow

GTK 搞 libadwaita，Qt 搞 QML，我们都有美好的未来.jpg（

不过这个问题挺奇怪的，就算是有 LD_PRELOAD 之类的环境变量我也不太能想象是什么原因（

我开了 testing 仓库试了一下直接运行 from _ctypes import CFuncPtr 无法复现

参阅： https://peps.python.org/pep-0689/

回复错上下文了？

下划线开头的 api 没有稳定性保证吧

我也不是很确定，你可以打上 patch 试一下，尤其是看 WAYLAND_DEBUG 上收的事件有没有什么区别（

[m.image] * 我之前有个问题让 gemini 联网搜索，因为我想 Google 自家的也许搜索做得更好，结果给我一堆幻觉，我指出它提供的 URL 实际上并不存在，然后它思考了好长时间最终给我来了一句：

给我气笑了

[m.image] 我之前有个问题让 genimi 联网搜索，因为我想 Google 自家的也许搜索做得更好，结果给我一堆幻觉，我指出它提供的 URL 实际上并不存在，然后它思考了好长时间最终给我来了一句：

wayland 协议不区分 response 和 signal，只有 event，就不得不用 roundtrip 来区分哪些是被合成器立即回复的事件

看了下那有可能就是缺少 roundtrip 的问题 https://lists.sr.ht/~whynothugo/public-inbox/patches/67617

way-secure 的代码我还是没看出来哪里有问题（

是这样的，wayland 没有设计一个授权 api，大部分合成器默认不做限制直接暴露特权协议。目前只能用 security context 限制并希望合成器会做限制

终于

哦，那我猜大概是因为 dbus 没有 Wayland 那样的 new_id 消息

request object 是什么？我怀疑 Wayland 并不是没有类似的东西，只是不叫这个名字

需要自己编译吗

（其实只要别长时间保持正在写入的单个文件处于不一致的状态，自动同步就应该都没问题。至少 syncthing 是会等待几秒内一个文件不再有写入才开始同步

* 有备份应该就没事，我是用 syncthing 同步的。keepass 数据库这种数据写入时间窗口很短的文件，一般来说对同步软件还是比较友好的，不像 sqlite 那种

有备份应该就没事，我是用 syncthing 同步的。keepass 数据库这种输入写入时间窗口很短的文件，一般来说对同步软件还是比较友好的，不像 sqlite 那种

是吗，我不太懂 C++，但我听说的是 libc++ 的实现比 libstdc++ 更好

拆 GNU 的台没有好结果的。没有 GNU 替代品的话，这些东西恐怕就给你闭源了

有生之年系列，它进步的速度还没 rust 自己快

不过 arch 目前还是用 gcc 的

内核文档的 rust 页面建议使用 clang 编译

而 rust 基于 llvm

gcc 自己的 lto 很好。但是 lto 没法跨编译器，因为 lto 本质是链接时由编译器干活

？

假如将来有 rust 编写的必要的驱动，且发现了混合 gcc 和 rust 编译的内核会存在某种无法修复的问题，那 gcc 编译内核就基本上成了不受支持的情况了，那就很坏了

会的

所以我个人观点一直是在 gccrs 可用之前，rust 不应该进入上游内核。当然我的观点也没用

防君子不防小人

https://t.me/archlinuxcn_offtopic/8090625

内核文档的 rust 页面是说推荐用 clang，但是混合 gcc 和 rust 到底有什么问题（除了 lto 之外）我也不是很清楚（

区分人类和机器真难啊（

这样一想，的确如果爬虫的算力比服务器算力大得多的话，工作量证明也不是个很有效的方案（

是

但是如果你连 btrfs 挂载都没搞清楚，当时你怎么安装的系统（

其实如果你是和 chat AI 对话，并以对待任何网上的随机命令的态度认真理解了每条命令的作用再执行，而不是无脑复制粘贴，那大概不会有事。更容易出事的是 AI agent

加上这个的话，我已经听说过三个不同的被 AI 删数据的案例了（

我记得阿里云 ip 是被上游 anubis 直接 ban 的

不返回错误这个决定是 portal 的实现做的，还是 xdg-desktop-portal 自身做的特殊处理？

草，这样吗

我其实也没遇到过，一开始是听说，后来看一些源码确认了这一点

* 过拟合了。目前只有 Qt 能在 Wayland 合成器崩溃后幸存

过拟合了。目前只有 Qt 能下 Wayland 合成器崩溃后幸存

因为 waydroid 是个 privileged lxc

古人云，独在异乡为异客

另外 xdg-open 脚本里针对 flatpak 的实现就是 gdbus 命令行调用 OpenURI

flatpak 有一个 xdg-open 命令的实现的

要说 C 语言的实现的话，其实编译器更接近这个描述。不过编译器加上 libc 才算完整的实现

不是，glibc 相当于是 C 语言标准库和 POSIX 库的实现，此外还有一些别的 syscall 封装和不符合上述两个标准的函数

有些数据不管怎么建表都麻烦吧（ 而且正确设计合适的表也需要花费心思

* sql 面对嵌套层级较多的数据确实不方便

sql 面对嵌套层级较多的数据确实不发版

sqlite 也支持 json，不过就是没有以键值存储而是整个存储的，每次查询都需要解析

那就只能出问题来群里问了

看运气，短的几小时，长的十几年

那还是去隔壁 Android 群问问吧，我确实不太懂

好吧（

我还以为新版 Android 已经换 nftables 了

那也行，都差不多

那 Android 的 wifi 热点是用什么做的 NAT，ebpf 吗，不太了解

没有吗，我不清楚。你有 root 权限那自己写 nftables 也行吧，不太了解盲猜的（

另外你要能接受 NAT66 的话那应该也是可行的

要不在隔壁 @archlinuxcn_android 群问？