 | kuanatV2EX 第 634702 号会员，加入于 2023-06-19 11:38:40 +08:00今日活跃度排名 7312 |
| Linux 漫谈（一） 10 Linux kuanat 1 小时 30 分钟前 最后回复来自 zzxx3322 | 17 |
| Go 语言的错误处理语法，不改了！ Go 编程语言 kuanat 197 天前 最后回复来自 bunny189 | 68 |
| Jetbrains 发布了 Kotlin 官方 LSP Visual Studio Code kuanat 214 天前 最后回复来自 ExplodingFKL | 1 |
| 全闪 NAS 的一些心得体会 NAS kuanat 225 天前 最后回复来自 idontunderstand | 25 |
| 我转发了一张图到前端群，大周末的群里已经爆炸了 程序员 kuanat 348 天前 最后回复来自 zbowen66 | 108 |
| 基于 Go 语言谈软件开发效率 Go 编程语言 kuanat 354 天前 最后回复来自 phoulx | 15 |
| Zed Linux vim 模式输入法切换 Zed kuanat 31 天前 最后回复来自 weixiangzhe | 4 |
| 一个好用的、纯软件的扩展屏方案 分享发现 kuanat 2024-06-04 22:45:38 PM 最后回复来自 kuanat | 2 |
| V2EX 是否会考虑增加专栏功能？ V2EX kuanat 2024-04-29 12:49:46 PM 最后回复来自 kuanat | 5 |
| 分享一些 Go 在全栈开发中的经验 13 Go 编程语言 kuanat 2024-07-23 15:46:51 PM 最后回复来自 GeekGao | 43 |
kuanat 最近回复了
7 小时 24 分钟前 回复了 kuanat 创建的主题 Linux Linux 漫谈（一） |
@hronro
@craftsmanship
就只发在 V2EX 上，我认为文章内容的价值是一方面，这里的讨论同样重要。对我自己来说这些内容更多是总结整理，放在这里比放在个人博客更有生命力。（我确实没有写博客的习惯）
@craftsmanship
就只发在 V2EX 上，我认为文章内容的价值是一方面，这里的讨论同样重要。对我自己来说这些内容更多是总结整理，放在这里比放在个人博客更有生命力。（我确实没有写博客的习惯）
9 小时 46 分钟前 回复了 kuanat 创建的主题 Linux Linux 漫谈（一） |
2 天前 回复了 d0r1an 创建的主题 推广 开源了一个类似 SQLite 设计哲学的容器运行时 BoxLite - 嵌入式、无守护进程、硬件级隔离 |
我感觉这个实现和 podman/macOS 非常像啊，应该是基于 libkrun 的封装吧。
没来得及看代码，请教几个问题。如果是 rust 的库，那调用 gvisor 网络栈应该是直接打包二进制子进程的形式吧，有考虑过用 go 吗？问这个主要是我不清楚它运行时需要哪些依赖，有没有可能做到完全的静态链接。
对 oci 镜像的支持是如何实现的？我能想到的是找个临时路径展开，不过这样做好像比较麻烦，其他方案要支持 macOS 比较难。
这个实现里有跑 guest 应用吗？感觉处理 tty 也比较麻烦。
没来得及看代码，请教几个问题。如果是 rust 的库，那调用 gvisor 网络栈应该是直接打包二进制子进程的形式吧，有考虑过用 go 吗？问这个主要是我不清楚它运行时需要哪些依赖，有没有可能做到完全的静态链接。
对 oci 镜像的支持是如何实现的？我能想到的是找个临时路径展开，不过这样做好像比较麻烦，其他方案要支持 macOS 比较难。
这个实现里有跑 guest 应用吗？感觉处理 tty 也比较麻烦。
5 天前 回复了 lusxh 创建的主题 程序员 同志们，技术问题来了，大家讨论下， jwt 续签为什么要使用双 token |
在讨论安全之前，要先定义什么是安全，或者说要应对的威胁模型是什么。
- 如果是 token 伪造，那 session （也就是你说的 token+redis ）和 JWT （双 token ）没区别，都是后端签发的。
- 如果说是身份冒用，两者也没区别，只要持有合法 token 就视作有效。
- 如果指的是 token 撤销，那么 session 比 jwt 好一点，因为它可以实时撤销，而 jwt 只能等它过期。
“性能也不见得差”这句话有毛病。session 方案的逻辑是有个中心化的实时鉴权后端，要负责对所有业务请求进行身份认证。现实里这个单点是极其脆弱的，水平扩展能力也非常有限。
由此诞生的 JWT 之类的方案，并不是要做得比 session 更安全，而是要解决 session 方案的性能瓶颈。
准确来说，解决性能瓶颈靠的是通过无状态 AccessToken ，将鉴权转移到每个业务单元，业务单元只需要解码而不需要实时后端查询。
为了让 JWT 方案也能达到和 session 方案一样的安全水平，那就要将 AccessToken 的有效期设定得越短越好。
但是 JWT 方案是无状态的，如果要获得新的 AccessToken 是无法像 session 一样自动更新的，必须要走一遍完整的登录验证过程。
所以就有了 RefreshToken ，它解决的是方便获得短时效 AccessToken 的问题。这个“双”token 的重点是方便。
PS 稍微补充一点：如果是 web 应用场景，RefreshToken 多数存储于 HttpOnly/Secure/SameSite=Strict cookies 中，防止 js 读取，也避免 XSS 攻击（因为即便后端被注入恶意代码，这个代码被当前用户执行后也无法获得 cookie 内容）。AccessToken 存储于内存变量中，通过 js 代码以 header 的形式传递，这样可以防止 csrf 攻击（因为跨域的时候不可能带上这个 header ）。
- 如果是 token 伪造，那 session （也就是你说的 token+redis ）和 JWT （双 token ）没区别，都是后端签发的。
- 如果说是身份冒用，两者也没区别，只要持有合法 token 就视作有效。
- 如果指的是 token 撤销，那么 session 比 jwt 好一点，因为它可以实时撤销，而 jwt 只能等它过期。
“性能也不见得差”这句话有毛病。session 方案的逻辑是有个中心化的实时鉴权后端，要负责对所有业务请求进行身份认证。现实里这个单点是极其脆弱的，水平扩展能力也非常有限。
由此诞生的 JWT 之类的方案，并不是要做得比 session 更安全，而是要解决 session 方案的性能瓶颈。
准确来说，解决性能瓶颈靠的是通过无状态 AccessToken ，将鉴权转移到每个业务单元，业务单元只需要解码而不需要实时后端查询。
为了让 JWT 方案也能达到和 session 方案一样的安全水平，那就要将 AccessToken 的有效期设定得越短越好。
但是 JWT 方案是无状态的，如果要获得新的 AccessToken 是无法像 session 一样自动更新的，必须要走一遍完整的登录验证过程。
所以就有了 RefreshToken ，它解决的是方便获得短时效 AccessToken 的问题。这个“双”token 的重点是方便。
PS 稍微补充一点：如果是 web 应用场景，RefreshToken 多数存储于 HttpOnly/Secure/SameSite=Strict cookies 中，防止 js 读取，也避免 XSS 攻击（因为即便后端被注入恶意代码，这个代码被当前用户执行后也无法获得 cookie 内容）。AccessToken 存储于内存变量中，通过 js 代码以 header 的形式传递，这样可以防止 csrf 攻击（因为跨域的时候不可能带上这个 header ）。
5 天前 回复了 PeterTerpe 创建的主题 Android 红米 K50 刷入 LineageOS 22.1 后 |
6 天前 回复了 stinkytofux 创建的主题 Linux 原来 Linux 桌面才是最封闭的系统. |
@charles0 #51
我觉得“wayland 显示协议层面实现安全性”和“wayland 因为安全性拒绝了（应用获知窗口位置功能）实现”是有差别的。wayland 从来没有保证过什么。
就我个人的理解 wayland 协议就是一个特化的二进制 ipc ，它拒绝大多数非必须的功能提案进入核心（ foundation ），安全性是这个设计框架的副作用。
实现了 wayland 协议的合成器，一样可以实现 wayland 标准之外的功能，比如让应用获得自身位置，或者让非焦点应用获得全局键盘输入，让它变得更像 xorg ，让它变得不安全。这些功能写成提案就变成了所谓的扩展协议，如果 wayland 不认可，那就变成了私有协议。
我想表达的意思是，wayland 的设计好坏不能单纯以纸面上的协议 specs 来评价，也不能单纯以各种合成器已实现的部分做评价。
Wayland 的发展是有过重大转型的，原本的设想是 kdbus （也就是 dbus 的内核实现）为基础，但后来内核拒绝了 kdbus ，导致 Wayland 不得不依赖 systemd/dbus/pipewire/portal 一系列机制打补丁。现在 wayland 的样子很大原因是为了落地而做的妥协。
现在 linux 的现实就是，上面提到的这些底层机制，几乎绝大部分都是红帽员工写的，没得选。既然没得选，评价好或者不好就不那么有意义了。或许有人会说 xorg 也是一个选择，现实情况是没人想维护了，很难说用爱发电的 x11libre 能走多远。
我觉得“wayland 显示协议层面实现安全性”和“wayland 因为安全性拒绝了（应用获知窗口位置功能）实现”是有差别的。wayland 从来没有保证过什么。
就我个人的理解 wayland 协议就是一个特化的二进制 ipc ，它拒绝大多数非必须的功能提案进入核心（ foundation ），安全性是这个设计框架的副作用。
实现了 wayland 协议的合成器，一样可以实现 wayland 标准之外的功能，比如让应用获得自身位置，或者让非焦点应用获得全局键盘输入，让它变得更像 xorg ，让它变得不安全。这些功能写成提案就变成了所谓的扩展协议，如果 wayland 不认可，那就变成了私有协议。
我想表达的意思是，wayland 的设计好坏不能单纯以纸面上的协议 specs 来评价，也不能单纯以各种合成器已实现的部分做评价。
Wayland 的发展是有过重大转型的，原本的设想是 kdbus （也就是 dbus 的内核实现）为基础，但后来内核拒绝了 kdbus ，导致 Wayland 不得不依赖 systemd/dbus/pipewire/portal 一系列机制打补丁。现在 wayland 的样子很大原因是为了落地而做的妥协。
现在 linux 的现实就是，上面提到的这些底层机制，几乎绝大部分都是红帽员工写的，没得选。既然没得选，评价好或者不好就不那么有意义了。或许有人会说 xorg 也是一个选择，现实情况是没人想维护了，很难说用爱发电的 x11libre 能走多远。
7 天前 回复了 stinkytofux 创建的主题 Linux 原来 Linux 桌面才是最封闭的系统. |
我感觉大多数人可能并不了解一个桌面系统是要有多复杂，所以会产生误解。之前我写过一篇介绍 wayland 合成器的，等有空我完整写一下关于桌面的。
简单回答一下这个帖子里提到的一些问题。我不是为了评价它是好是坏，只是尽量补充些信息。
- 全局热键
底层逻辑是非焦点应用不能获得键盘输入。所以 wayland 核心协议（ foundation ）没有，实际 org.freedesktop.portal.GlobalShortcuts 是属于 XDG Desktop Portal 的一部分，之前是 flatpak 沙盒环境的实现。或者再底层一点，wayland 只涉及二进制高性能 IPC ，其他的都走 dbus 。目前 KWin/Mutter 都支持了，hyprland/sway 虽然不直接支持，但对于用户来说反倒更简单，只是对应用来说缺少注册机制。
- 应用获知自己的位置，XY 坐标系
底层逻辑是窗口位于哪里是用户和合成器的事情，而不是应用程序的事情。安全考量是防止 UI 欺骗和覆盖攻击。这个问题协议层面无解，但作为合成器来说以私有协议方式实现这个功能不难，至于为什么不做可以去问开发者。
- 远程键鼠
X11 的方式是无限制的事件注入。Wayland 认为这种无鉴权无溯源的方式不安全。目前有两个解决思路，一个是走 XDG Portal 通过 libei(emulated input) 完成，另一个是 uinput 创建虚拟设备。这个只能说是软件更新没跟上，至少我用的 wayvnc 和 gnome rdp 都很正常。
- 类 macOS 统一权限/碎片化
历史原因不存在这个基础，实际上现在 systemd/dbus/wayland 这三个支柱，80% 代码都是 RH 出钱雇人做的，最大公约数就这水平了。不同于现实世界的标准之争，资本或者组织先确定标准，再去搞实现。Wayland 的现状是反正总有人不满意，纸面上的协议没什么意义，一堆私有协议最后卷剩下的那个才是真正的标准。
- 输入法
这个提过很多次了，fcitx5 实现了所有可以支持的协议，主要合成器也都支持至少一种协议，剩下就是软件自己的问题了。问题是输入法这协议都是老外最早设计的，他们根本不懂，所以只能我辈努努力改变现状了。
PS
我知道很多人有 RPA 或者自动化的需求，如果是开发者，在合成器基础上手搓“私有协议”不是很难的事情，如果是普通用户，基于 sway IPC 可以达到几乎任意想要的效果。如果是楼主这种开发应用发现没有办法适配我能理解，如果只是单纯抱怨那就没意思了。
简单回答一下这个帖子里提到的一些问题。我不是为了评价它是好是坏，只是尽量补充些信息。
- 全局热键
底层逻辑是非焦点应用不能获得键盘输入。所以 wayland 核心协议（ foundation ）没有，实际 org.freedesktop.portal.GlobalShortcuts 是属于 XDG Desktop Portal 的一部分，之前是 flatpak 沙盒环境的实现。或者再底层一点，wayland 只涉及二进制高性能 IPC ，其他的都走 dbus 。目前 KWin/Mutter 都支持了，hyprland/sway 虽然不直接支持，但对于用户来说反倒更简单，只是对应用来说缺少注册机制。
- 应用获知自己的位置，XY 坐标系
底层逻辑是窗口位于哪里是用户和合成器的事情，而不是应用程序的事情。安全考量是防止 UI 欺骗和覆盖攻击。这个问题协议层面无解，但作为合成器来说以私有协议方式实现这个功能不难，至于为什么不做可以去问开发者。
- 远程键鼠
X11 的方式是无限制的事件注入。Wayland 认为这种无鉴权无溯源的方式不安全。目前有两个解决思路，一个是走 XDG Portal 通过 libei(emulated input) 完成，另一个是 uinput 创建虚拟设备。这个只能说是软件更新没跟上，至少我用的 wayvnc 和 gnome rdp 都很正常。
- 类 macOS 统一权限/碎片化
历史原因不存在这个基础，实际上现在 systemd/dbus/wayland 这三个支柱，80% 代码都是 RH 出钱雇人做的，最大公约数就这水平了。不同于现实世界的标准之争，资本或者组织先确定标准，再去搞实现。Wayland 的现状是反正总有人不满意，纸面上的协议没什么意义，一堆私有协议最后卷剩下的那个才是真正的标准。
- 输入法
这个提过很多次了，fcitx5 实现了所有可以支持的协议，主要合成器也都支持至少一种协议，剩下就是软件自己的问题了。问题是输入法这协议都是老外最早设计的，他们根本不懂，所以只能我辈努努力改变现状了。
PS
我知道很多人有 RPA 或者自动化的需求，如果是开发者，在合成器基础上手搓“私有协议”不是很难的事情，如果是普通用户，基于 sway IPC 可以达到几乎任意想要的效果。如果是楼主这种开发应用发现没有办法适配我能理解，如果只是单纯抱怨那就没意思了。
7 天前 回复了 yiyiniu 创建的主题 程序员 请教 国产化改造这个项目栈用哪种搭配最合适呢？ |
先看许可采购名录，再从里面挑。有些要求严格的比如银河麒麟和麒麟信安就不是一个东西，保密级别高的只能用后者。
SpringBoot+MySQL 是没什么压力的，ARM 都可以，性能也基本够用。你要是不知道怎么报价，先去找软件厂家问采购价，然后再根据采购价往上加。麒麟系统是提供 jdk 的，1.8 版本什么的都有，可以省钱。另外东方通什么的可能比你想象中要贵得多，因为有些国产化的要求是连中间件一起的，没得选。
多数这种项目最后会卡在数据库优化上，有自己的工程师可以试试看，搞不定就要付费请厂家的人。就我个人经验来说，金仓的工程师水平是比较高的，他们家 oracle 兼容比较好。至于 MySQL 这种国产几个都没什么压力，自动化迁移工具都很成熟。
SpringBoot+MySQL 是没什么压力的，ARM 都可以，性能也基本够用。你要是不知道怎么报价，先去找软件厂家问采购价，然后再根据采购价往上加。麒麟系统是提供 jdk 的，1.8 版本什么的都有，可以省钱。另外东方通什么的可能比你想象中要贵得多，因为有些国产化的要求是连中间件一起的，没得选。
多数这种项目最后会卡在数据库优化上，有自己的工程师可以试试看，搞不定就要付费请厂家的人。就我个人经验来说，金仓的工程师水平是比较高的，他们家 oracle 兼容比较好。至于 MySQL 这种国产几个都没什么压力，自动化迁移工具都很成熟。
26 天前 回复了 devloperchen 创建的主题 Android Android Studio 编译太慢了 |
先考虑提升硬件看看。
以全量编译 aosp 为例，在公司老的 e5 服务器上，大概要四个半小时左右。放到同事今年新买的笔记本上，70w 性能模式大概只要两个小时不到，从 32g 升级到 64g 内存之后，又能提升接近 15 分钟。后面增量编译大概在 10~20 分钟不等。
以全量编译 aosp 为例，在公司老的 e5 服务器上，大概要四个半小时左右。放到同事今年新买的笔记本上，70w 性能模式大概只要两个小时不到，从 32g 升级到 64g 内存之后，又能提升接近 15 分钟。后面增量编译大概在 10~20 分钟不等。
34 天前 回复了 Licsber 创建的主题 NAS 好像遇到文件静默损坏了，单比特翻转 |
首先明确一个逻辑，就是判断一个写入行为是否正确，只能靠写入之后的再次读取来验证，但这个验证仅能代表这一次尝试读取时的结果，很可能下一次再读取就出错了。基于这个逻辑，所有的存储介质还有软件，都是不做这个检测的，而是在写入的时候，附带写入一个校验码，那么下次读取的时候，如果校验码和数据本身不一致，就认为之前写入的数据出错了。
如果这个静默错误发生在硬盘内部，比如因为宇宙射线或者某种原因造成的，那么硬盘固件会向操作系统汇报读取出错。根据你的描述来看，没有任何软件层面的提示，而是你人为校验的时候发现的，那就说明硬盘内部的校验信息和硬盘上实际的写入数据是一致的，由此可以判断，数据在进入硬盘之前就已经发生了变化。
再往上一层就是 xfs 文件系统了，由于 xfs 不像 zfs/btrfs 有数据块校验，同时会在读取的时候强制做验证，所以比较大的概率是，上一次写入时，xfs 获得的数据已经是错误的了，这个错误大概率是发生在内存中的静默错误。根据描述来看，硬件平台是没有 ecc 内存的，那么这种出错也就不可知了。
关于 bitrot 我在网上看到过很多次了，只是我个人从来没有遇到过，无论是很多年前组的 nas ，还是近几年接触维护过的带 ecc 内存的服务器，当然也有可能是遇到了但我不知道……
我目前的应对方案是 cpu 开启内存加密，因为内存是 ddr5 本身有系统不可见的内部 ecc ，开内存加密可以让 1bit 的错误传播到最多 256bit ，提高发现的概率。文件系统方面都是 btrfs ，同时也采用 luks 加密，底层存储都是 btrfs raid1 ，都会大幅提高 bitrot 被发现的可能。迁移到这套配置很久了，我依旧没有遇到过静默出错的情况。
如果这个静默错误发生在硬盘内部，比如因为宇宙射线或者某种原因造成的，那么硬盘固件会向操作系统汇报读取出错。根据你的描述来看，没有任何软件层面的提示，而是你人为校验的时候发现的，那就说明硬盘内部的校验信息和硬盘上实际的写入数据是一致的，由此可以判断，数据在进入硬盘之前就已经发生了变化。
再往上一层就是 xfs 文件系统了，由于 xfs 不像 zfs/btrfs 有数据块校验，同时会在读取的时候强制做验证，所以比较大的概率是，上一次写入时，xfs 获得的数据已经是错误的了，这个错误大概率是发生在内存中的静默错误。根据描述来看，硬件平台是没有 ecc 内存的，那么这种出错也就不可知了。
关于 bitrot 我在网上看到过很多次了，只是我个人从来没有遇到过，无论是很多年前组的 nas ，还是近几年接触维护过的带 ecc 内存的服务器，当然也有可能是遇到了但我不知道……
我目前的应对方案是 cpu 开启内存加密，因为内存是 ddr5 本身有系统不可见的内部 ecc ，开内存加密可以让 1bit 的错误传播到最多 256bit ，提高发现的概率。文件系统方面都是 btrfs ，同时也采用 luks 加密，底层存储都是 btrfs raid1 ，都会大幅提高 bitrot 被发现的可能。迁移到这套配置很久了，我依旧没有遇到过静默出错的情况。
Select Language