而且我不理解在休眠之前 freeze cgroup 有什么用

那是已知问题，FUSE 会导致 systemd 无法 freeze cgroup

主要是 javafx 不支持，hmcl 基于 javafx

我也用的是 hmcl，能用（ 不过我不是 hidpi 显示器

hmcl 是 X11 应用程序

是的

Linux 休眠应该是（可以）不依赖固件的

没这回事

github actions 有一个 container 属性的

这应该是最 trivial 的做法了（

严格来说可能也算滥用，但这种一般就没那么严格

那不清楚了

我记得说是只有上游打包才不算滥用，你这种自己打别人的包给自己用的就算滥用（

就怕号没了（ github 号不是一个简单的帐号，它也提供 sso

或者在 archlinuxcn 里维护一个包

自己本地编译呗

可以做到但这算滥用吧（

aur 只分发 PKGBUILD，为什么要用 github actions（

要打什么包

那不至于，及时更新就行了

你发现有新版就去 flag 一下其实是好事

那只是没人关注（

有新版就 flag 很正常吧

单纯为了绕过反对意见而改名的

好像就是改了个名字

忍受旧 bug 甚至是安全漏洞，且通常无法得到上游支持

在那之前 futex 一直无法在单线程中和 epoll 之类的等待 fd 的 api 结合使用，而 io_uring 统合了二者

说到这个，顺便一提，io_uring 已经支持 futex 两年了 https://www.phoronix.com/news/IO_uring-FUTEX-Linux-6.7 https://man.archlinux.org/man/io_uring_enter.2#IORING_OP_FUTEX_WAIT

谁知道呢（

这句话就足以看出 wine 开发者的无奈了（

太真实了

邮件的观点是这样的，我就是说我觉得这个要求很没道理

草，那我没注意过（

所以我一开始就质疑 ntsync 的必要性

我也不是很理解

There is also an optional flag allowing to close the source handle at the same time. This is insane, of course—to allow a process to close another process's handles without its knowledge—but we need to implement it.

是 safety 而不是 security 吧。按我理解主要是防止内存损坏导致破坏 wine 的行为

但正是因为 Windows api 的这种离奇古怪几乎没人用的奇怪行为，导致 Linux 不得不提供内核支持来兼容，就很离谱

是的

（另外我指的是耐心看完邮件。可以说 wait all 问题是几个问题里最不重要最容易解决的一个

我记得之前看过一个 benchmark，其实 esync、fsync、ntsync 之间基本没有可测量的性能差异，只是 ntsync 更容易实现语义正确性

这种几乎没有程序使用的接口，用慢速用户空间模拟我觉得是可以接受的

啊，那是我记错了，因为几乎没有程序使用 wait all 包括 Windows 程序在内，所以就没实现 https://lwn.net/Articles/962628/

不着急，先从基础开始慢慢来

所以我建议你耐心看完再说（

需要树外补丁

当时 futex2 没合并进主线

https://docs.kernel.org/userspace-api/futex2.html

你真的信 AI 吗（

看了这篇以后你就对 Windows 那沟槽的 api 设计有直观理解了

邮件很长，建议找空闲时间阅读（ https://lore.kernel.org/lkml/[email protected]/

futex2 已经解决了 wait all 问题了，但问题不在这里

你等一下我把那篇邮件找出来

* （这是个典型的网上流传的误解（

（这是个典型的误解（

不是

内核支持的 ntsync 就是因为这个原因诞生的

Windows api 还有一堆离谱的边缘行为

所以说 Linux 的接口一致性确实好一些，学习成本明显更低

（所以很多时候需要抛弃斗蛐蛐思维

好的设计只能让简单的事情保持简单，复杂的事情成为可行，而不可能让复杂的事情变得简单

没有银弹

那也不是

意思是，现实世界的复杂性不是靠一个抽象能消除的

我觉得没多大区别吧

比如你要给设备发 NVMe 指令，这该怎么抽象（

是这样的

io_uring 也有相当于 ioctl 的 cmd 操作

当需要极端的灵活性时必定需要某种类似 ioctl 的东西，总不能给每个设备都开几个新 syscall 吧（

Linux 更重要的优势其实是开源

也不好说，要看情况

* 那倒不是，但是一致性确实更好一些。另外 Windows 也有 handle，本质和文件描述符一回事

那倒不是，但是一致性确实更好一些。另外 Windows 也有 handle，本质一回事

https://github.com/kraj/musl/blob/master/arch/x86_64/syscall_arch.h

github 的 ui 方便一些

https://github.com/bminor/musl 仓库怎么没了？这个组织下现在只剩一个 glibc 镜像了

所以 libc 都依赖了不符合标准的编译器拓展才能实现

也正是通过这两种方法调用内核没法被 strace 看到

那也是编译器支持的。要说不符合 ISO C 的话所有 libc 都不符合，因为 strict aliasing 限制你没法实现 malloc

另外，用户空间和内核通信的方式也不止有 syscall，还有 vdso 以及 io_uring

怎么可能不需要。你说的可能只是很多时候不需要切换地址空间刷 TLB

这样你不需要自己写汇编，直接调用 C 函数就行了

是 C 语言的函数把 syscall 包装了一层。发起系统调用需要汇编，libc 把发起 read 系统调用的汇编代码封装在 read 函数里，供你调用

这很正常（

libc 提供 read 函数，这个函数内部去调用 read 系统调用

严格来说是的，C 语言调用的是 libc 提供的包装函数，包装了一层

只不过很多时候 syscall 的函数签名与 C 语言有很大重叠，可以用 C 函数签名简单表示

不是，是 system call，它有一套自己的调用约定，不依赖 C 语言且不能被 C 编译器自动识别

niri 我不清楚，sway 我没记错的话是暴露给所有客户端，但只有一个客户端独占，先到先得。不过我没有亲自尝试验证过

kexec 也是重启，只是重启内核不重启硬件

我的意思是 ffmpeg 后端也应该表现得一样好才合理

啊，那感觉可以翻一翻源码了

按理说是不应该的，不过我没用过 firewalld（ 看看日志？

相关 issue https://github.com/swaywm/sway/issues/2333

不过它也不能决定暴露或隐藏某些协议，只是给 ipc 提供了沙箱信息 https://github.com/swaywm/sway/pull/8521

其实我觉得 security context 协议本该设计成类似 Linux unshare 那样的东西

* sway 配置文件可以针对 security context 做一些配置

sway 配置文件可以做一些配置

目前还没有可移植的办法

（其实剪贴板同步这种事我觉得本来应该 Xwayland 自己做的