实在不习惯的话 systemd-journald 提供 ForwardToSyslog 选项...

为了防止 CA 签有问题的证书被用于 mitm，于是 HSTS 有 Certificate Pinning 的扩展。

编译的时候发生混沌 /软件包版本混沌有个很直接的解决方案：自己搭建 dist-git/koji 等一套软件包编译打包系统。软件包管理就能解决找出没有被满足的依赖、以及提示冲突的老包。而不是一股脑 make install，然后谁也不记得哪些文件是哪些软件的。

并且上游有包(印象中 openmpi 就在 centos 有打包)并且能满足需求就直接用呗。就算是 CERN 的集群都有安装 EPEL 包...虽然大家用软件都是直接去 cvmfs 上面 source 的。

可以，但是难度 _可能_ 跟自己琢磨实现高的多

@kele1997 docker 的特权模式对应的不是用户，而是 root capabilities 以及 seccomp 的东西。至少在支持 rootless 之前 docker 是这样做的...你可以通过 docker 里面的 root 用户创建文件，外面看所有者还是 root 。但是要是你通过非特权 docker 里面的进程访问设备，就会被 seccomp 拦下来。

@ReputationZh
https://www.kernel.org/doc/Documentation/filesystems/ext4.txt

印象中 ro 依然会做 log replay, 你应该 ro,noload 来避免任何写入
日志当然在文件系统里面，只不过不是文件
日志是为了保证操作事务性的机制，需要事务性的写入操作才需要日志
3 的问题就太宽泛了...难以回答

我直接把 ssh 映射到公网，并且加上禁止 root 登录，禁止密码登陆。跑了一年多了，一直有看到扫描（每天 2000+次登录尝试），但是没被黑掉过

让我想起这个项目 https://github.com/springzfx/cgproxy，不过 cgproxy 是一个 daemon，监听 cgroup 然后对于设置的 slice 等应用代理

突然对你用的框架很感兴趣，我正好想要写一个支持量纲检的物理库

有一点想要提到的，其实 systemd-resolved 提供的 127.0.0.53 只是一个 failback，默认情况下解析会通过 glibc 的 nss 扩展借助 dbus 完成解析。那个 127.0.0.53 一般是给 golang 程序那些 nss 管不到的程序做解析的。不过在 Ubuntu 上那个 nss 模块默认没开，于是修改 resolved.conf 可能有效果，在 Fedora 上可能对于大部分程序就会不好使了。

systemd-resolved 获得上游 DNS 配置的方法有很多，默认情况下会从 network manager，比如 systemd-networkd 或者 NetworkManager 取得。但是也可以手动配置，确实通过 network manager 层面配置更可靠

至于 #2 提到的，要不试试 FallbackDNS 配置，我建议的配置是
1. 有线网通过 NM 设置 DNS
2. 无线网通过 NM 禁用 DNS
3. 设置 FallbackDNS，在有线网断开的时候 resolved 没有 DNS 配置就会使用 FallbackDNS

git 只是在文本层面处理代码，它管不到代码里面的逻辑，你需要的是测试用例

之前去维修，表示了顾虑，然后维修人员在我面前进行的屏幕检测（

Linux 下使用，因为 chrome/chromium 对于 wayland 以及硬件加速支持很糟糕于是弃用，一直用的 Firefox，加上 Google 要禁止发行版的 chromium 带的 key，我可能会逐步完全抛弃 chrome/chromium

下划线只是为了避免不必要的冲突，至于一堆 template...嗯，因为人家叫做 STL

@lp101799 这就是可信计算方案，需要用到特殊的操作系统提供的接口，并且要求一个额外的主密码 /TPM 二选一，成本也很高

@czfy 腾讯那个回应就扯...为什么恶意登录在登陆后 10 分钟检查，为什么恶意登录检查指标是电商搜索...

@bin456789 接上，拿着一个 token 去 Google 服务器拿密码的设计，一方面需要时刻联网，另一方面这个 token 也不可能受到密码学级别的保护，然后依然可以被恶意程序拿走，总体上，你要么使用主密码保护，要么用上奇妙的可信计算途径，否则保护都会是掩耳盗铃，只是掩耳的力度不一样