@HongwahZhu

临时解决方法：chmod 777 /dev/kvm

长久解决方法：ls -l /dev/kvm 看看是属于哪个组的，如果是 root 组就配置 udev

我猜测是可能是和某些软件公司有 py 交易嘛，这么多年了连个 Linux/BSD 系的客户端都不出，还天天更新加密算法啧啧

@nyanyh 说下我的看法，手写 Makefile 感觉比 cmake 舒服多了，autoconf 都比 cmake 舒服

@plko345 这个问题是 Chrome 的问题，打开 Chrome 地址栏输入 chrome://flags/#ignore-gpu-blacklist 然后将此选项改为 Enabled，重启浏览器进入 chrome://gpu/ 确认 Video Decode 为 Hardware accelerated

fcitx + Google pinyin 好用

usermod -a -G kvm `whoami`

@c3824363 并不完全是，你要是要求不高可以试试 mutter 这个窗口管理器，支持 wayland，但这个窗口管理器定制性似乎不高，个人感觉最完美的话需要用 libwayland 库写一个窗口管理器，各种调整都得自己做，比如调整分辨率的通信协议，以前都是 X 在管理，wayland 里各家实现都不一样

AMD 用户路过
换开源驱动 nouveau 吧，虽然性能不行但是质量好，也符合各种规范（ KMS 什么的）

没有，换 Xorg 吧
或者自己开发一个
非把把图形服务器和窗口管理器弄到一个进程里去，现在知道麻烦了吧

fcitx 默认是 ctrl + space

工具链，简单说就是各种工具用管线连接一起

markdown to HTML 的工具： https://linux.die.net/man/1/markdown

你再找个 HTML to epub 的工具就 OK 了

”采用的用户态驱动和 I/O 协议栈模式......发送 I/O 的工作都是直接在用户态做的，不牵扯到系统调用“

用户空间驱动应该影响更严重啊

毕竟驱动和应用程序通信时还是需要内核调用，而且需要更多次，并且还有上下文切换的巨额开销。

比如我一个服务器网络应答吧，我最终是调用 write/send/...系统调用，最终调用网络驱动程序，但是如果这个驱动是在用户空间中实现的，首先上下文切换的开销是免不了的，另外用户空间也需要事先阻塞在一个系统调用上，然后再读取、调用、阻塞，相当于调用了最少 2 倍的系统调用

除了硬件异常（如缺页异常）以外，用户空间与内核交互最终都需要通过系统调用，其实系统调用本质上也是一种软件中断（异常）

我读书少你不要骗我

@iwtbauh 简单说，内核中有 amdgpu 驱动，用户空间的 X 服务器里还有一层驱动

在 Debian 上分别属于包 linux-image-xxx 和 xserver-xorg-video-amdgpu 和 xserver-xorg-video-radeon

我不知道在 fedora 上是什么

@plko345 并不一定，其实最早的时候显卡驱动是不在内核的，2.x 甚至 3.x 时代的内核文档里甚至还写了“如果你正在找关于显卡驱动开发的文档，你应该去 XFree86 项目或者 X.org 项目“，2.x 时代是由用户空间直接映射显存，显卡驱动都是由 X 服务器管理的。后来有了 framebuffer，但这个 PC 上显卡主要还是用户空间驱动程序。现在有了 KMS （内核显示模式设置）和 DRM （直接渲染管理器），但是还是需要一层用户空间驱动程序，所以现在是内核一层驱动 + X 服务器一层驱动共同工作

lsmod | grep amdgpu
lsmod | grep radeon

glxinfo | grep OpenGL

grep "amdgpu" /var/log/Xorg.0.log
grep "radeon" /var/log/Xorg.0.log

刚出的时候是不支持 WinXP 等旧系统的（除了 Firefox ），所以有人说打不开很正常吧

外国用这家签证书的网站： https://www.debian.org

@LosLord 现在版本的 vs 确实好很多了，旧版本 MSVC 对于 UTF-8 字符编码的源码文件支持太糟糕了。

但是就算源代码文件是 UTF-8，如果我没记错，MSVC 可能还是会把字符编译前转换成 ANSI （中文系统上就是 GBK 系），这就很难受。