 |
kuanatV2EX 第 634702 号会员，加入于 2023-06-19 11:38:40 +08:00今日活跃度排名 10176 |
| Go 语言的错误处理语法，不改了！ Go 编程语言 • kuanat • 168 天前 • 最后回复来自 bunny189 | 68 |
| Jetbrains 发布了 Kotlin 官方 LSP Visual Studio Code • kuanat • 185 天前 • 最后回复来自 ExplodingFKL | 1 |
| 全闪 NAS 的一些心得体会 NAS • kuanat • 195 天前 • 最后回复来自 idontunderstand | 25 |
| 我转发了一张图到前端群，大周末的群里已经爆炸了 程序员 • kuanat • 319 天前 • 最后回复来自 zbowen66 | 108 |
| 基于 Go 语言谈软件开发效率 Go 编程语言 • kuanat • 325 天前 • 最后回复来自 phoulx | 15 |
| Zed Linux vim 模式输入法切换 Zed • kuanat • 2 天前 • 最后回复来自 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 最近回复了
4 天前 回复了 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 被发现的可能。迁移到这套配置很久了，我依旧没有遇到过静默出错的情况。
14 天前 回复了 ZXCDFGTYU 创建的主题 › 职场话题 › 利用面试搞电信诈骗的事情又开始了 |
简单看了一下，似乎没什么可挖掘的，也就 ucoilk_cn 这个域名了，有备案。
应用本身用了不知道什么的简单抽取壳，反正比较简单，可以自吐也可以手动解密。解密在 so 层，没有任何防御的 aes 加密。字符串做了混淆。总体来说防了个寂寞，连 ssl 都没有。
看子域名估计诈骗的事没少干，感觉举报或者 ddos 都不好制裁，改头换面就又回来了。似乎扒一下接口塞垃圾数据可能还有点用。
应用本身用了不知道什么的简单抽取壳，反正比较简单，可以自吐也可以手动解密。解密在 so 层，没有任何防御的 aes 加密。字符串做了混淆。总体来说防了个寂寞，连 ssl 都没有。
看子域名估计诈骗的事没少干，感觉举报或者 ddos 都不好制裁，改头换面就又回来了。似乎扒一下接口塞垃圾数据可能还有点用。
14 天前 回复了 ZXCDFGTYU 创建的主题 › 职场话题 › 利用面试搞电信诈骗的事情又开始了 |
看看有没有暴躁老哥逆向挖掘一下给它举报了
17 天前 回复了 YUX 创建的主题 › 分享创造 › 我用 Zig 重写（并重新设计）了 frp 和 rathole |
楼上说米氏对比法太逗了……
能具体说一下二进制文件体积的比较标准吗？因为我看这个项目里 build 设定里面是动态+strip 。
再就是原始 run_benchmarks 的结果有吗？从测试脚本看，这个更多是加密协议之间的对比。
能具体说一下二进制文件体积的比较标准吗？因为我看这个项目里 build 设定里面是动态+strip 。
再就是原始 run_benchmarks 的结果有吗？从测试脚本看，这个更多是加密协议之间的对比。
17 天前 回复了 renchong 创建的主题 › 程序员 › 有在用 flutter 的朋友吗，官方为何连这样基础的功能都不支持？ |
以我个人的体验来说，Flutter 的质量、社区生态算是比较好的了……问就是 bug 太多修不过来。
跨平台 UI 本来就是妥协方案，只能说强依赖这样的方案不是很理智，类比到现实就是一个便宜的替代方案不能期待它提供 100% 的体验。
跨平台 UI 本来就是妥协方案，只能说强依赖这样的方案不是很理智，类比到现实就是一个便宜的替代方案不能期待它提供 100% 的体验。
18 天前 回复了 bczhc 创建的主题 › Android › MIUI 13 如何关闭系统的 compose key |
@bczhc #2
看你这个回复基本上就是系统的 bug 了。小米的软件 bug 多到离谱，而且大多数时候管杀不管埋……
关键是从这个表现来看，在进入到 InputMethodService 之前就被拦截了，连拯救一下的机会都没有。
看你这个回复基本上就是系统的 bug 了。小米的软件 bug 多到离谱，而且大多数时候管杀不管埋……
关键是从这个表现来看，在进入到 InputMethodService 之前就被拦截了，连拯救一下的机会都没有。
18 天前 回复了 pbk 创建的主题 › 中州韻 › 自用 Squirrel [鼠鬚管] Rime MacOS 全局记录 ascii 模式的版本，有需要的自取 |
我来解释一下 Rime 作者为什么不接受这个实现方式，以及作者期望的可能的实现方式。
按照作者的术语习惯，librime 核心部分称为后端，也叫算法引擎，weasel/squirrel/ibus-rime 这些官方应用称为前端。这里忽略掉操作系统的输入法框架细节，搞清楚两个事情即可，一个是前端和后端之间是通过 ipc 通信的，另一个是像获取并维护输入焦点信息、输入法状态本身的管理是在前端完成的。
实际上只有 librime 后端才是输入法状态的真实来源，squirrel 这个前端只有逻辑上的 get/set 接口。由于 macOS/Linux 的输入法框架都是基于 ipc 的，所以 librime 后端实现了 Session 机制，用于区分不同的输入焦点目标。
现在 squirrel 前端的实现非常 naive ，对于每个输入目标焦点，都通过 createSession 来创建一个新的 session 。你现在的实现思路是，通过 squirrel 暴露的 set 接口，控制 librime 后端每个 session 的实际状态。
作者认为更好的方法是，在 squirrel 层面实现一个 session 复用机制，而不是每个输入焦点都用 createSession 来创建新的 ipc 连接。
这种实现方式也非常直接，我这里拿 fcitx5-rime 这个基于 fcitx5 框架的 rime 前端做例子。
fcitx5-rime 逻辑上不区分具体的 ascii 还是简繁或者其他什么状态，只关心是不是要在不同的输入焦点目标之间“共享状态”，有全局共享/应用内共享/不共享三个逻辑层次。
具体实现层面上，fcitx5-rime 维护了一个与 librime 后端之间的 ipc 连接池，对接到了 librime session 相关 api 。根据用户设定的共享状态，选择性创建或者复用 session 。
我不用 macOS 很久了，只是大致看了一下 issue 和代码，有可能说错，但我感觉这个大致的思路是没问题的。
按照作者的术语习惯，librime 核心部分称为后端，也叫算法引擎，weasel/squirrel/ibus-rime 这些官方应用称为前端。这里忽略掉操作系统的输入法框架细节，搞清楚两个事情即可，一个是前端和后端之间是通过 ipc 通信的，另一个是像获取并维护输入焦点信息、输入法状态本身的管理是在前端完成的。
实际上只有 librime 后端才是输入法状态的真实来源，squirrel 这个前端只有逻辑上的 get/set 接口。由于 macOS/Linux 的输入法框架都是基于 ipc 的，所以 librime 后端实现了 Session 机制，用于区分不同的输入焦点目标。
现在 squirrel 前端的实现非常 naive ，对于每个输入目标焦点，都通过 createSession 来创建一个新的 session 。你现在的实现思路是，通过 squirrel 暴露的 set 接口，控制 librime 后端每个 session 的实际状态。
作者认为更好的方法是，在 squirrel 层面实现一个 session 复用机制，而不是每个输入焦点都用 createSession 来创建新的 ipc 连接。
这种实现方式也非常直接，我这里拿 fcitx5-rime 这个基于 fcitx5 框架的 rime 前端做例子。
fcitx5-rime 逻辑上不区分具体的 ascii 还是简繁或者其他什么状态，只关心是不是要在不同的输入焦点目标之间“共享状态”，有全局共享/应用内共享/不共享三个逻辑层次。
具体实现层面上，fcitx5-rime 维护了一个与 librime 后端之间的 ipc 连接池，对接到了 librime session 相关 api 。根据用户设定的共享状态，选择性创建或者复用 session 。
我不用 macOS 很久了，只是大致看了一下 issue 和代码，有可能说错，但我感觉这个大致的思路是没问题的。
18 天前 回复了 ervqq 创建的主题 › 奇思妙想 › Linux 下有没有类似 Time Machine 的软件或者解决方案 |
我用 btrfs subvolumes 方案很久很久了。
准确来说 TM 的功能是两部分，一部分是类似 subvolumes 的本地快照，另一部分是备份快照到非本地设备上。
Snapper 只是自动化创建快照这个工作，备份快照本身可以用 btrfs send/receive 功能。
准确来说 TM 的功能是两部分，一部分是类似 subvolumes 的本地快照，另一部分是备份快照到非本地设备上。
Snapper 只是自动化创建快照这个工作，备份快照本身可以用 btrfs send/receive 功能。
19 天前 回复了 bczhc 创建的主题 › Android › MIUI 13 如何关闭系统的 compose key |
Android 系统在语言和输入法相关设置里有个物理键盘的设定，可以点进去看看是否有切换键盘布局的选项，如果有的话切换到不使用 AltGr/Compose 的布局。印象 aosp 中有过，但我不是很确定。
这个问题说起来比较复杂。Android 系统的输入栈在内核部分和 Linux 是没有区别的，但之后就完全不一样了。因为是针对移动平台设计的，关于键盘布局的设定是和输入法、语言强绑定的。从底层修改这个按键和功能的映射是可行的，可以参考一下 https://github.com/keymapperorg/KeyMapper 这个应用。
简单说 Android 输入栈有两层，最底层和 Linux 处理输入设备一样，在内核态完成 scan code 到名义按键的映射，比如 scan code 1 代表 esc 按键。上面一层是按键和具体功能的映射，比如 A 按键的效果是 a 字符，有 shift 修饰的时候产生 A 字符。
如果你的系统可以获得 root 的话，可以看一下 /system/usr/keylayout/ 和 /system/usr/keychars/ 两个路径的文件。前者包含不同设备的 .kl 定义，代表 scan code 到名义按键的映射，后者包含 .kcm 定义，即名义按键到实际功能的映射，也就是一般所说的布局。可以检查一下是否正常。
如果你可以用 onKeyDown 获得 COMPOSE 事件的话，可以在编写的代码里强行当作 alt 来处理。
这个问题说起来比较复杂。Android 系统的输入栈在内核部分和 Linux 是没有区别的，但之后就完全不一样了。因为是针对移动平台设计的，关于键盘布局的设定是和输入法、语言强绑定的。从底层修改这个按键和功能的映射是可行的，可以参考一下 https://github.com/keymapperorg/KeyMapper 这个应用。
简单说 Android 输入栈有两层，最底层和 Linux 处理输入设备一样，在内核态完成 scan code 到名义按键的映射，比如 scan code 1 代表 esc 按键。上面一层是按键和具体功能的映射，比如 A 按键的效果是 a 字符，有 shift 修饰的时候产生 A 字符。
如果你的系统可以获得 root 的话，可以看一下 /system/usr/keylayout/ 和 /system/usr/keychars/ 两个路径的文件。前者包含不同设备的 .kl 定义，代表 scan code 到名义按键的映射，后者包含 .kcm 定义，即名义按键到实际功能的映射，也就是一般所说的布局。可以检查一下是否正常。
如果你可以用 onKeyDown 获得 COMPOSE 事件的话，可以在编写的代码里强行当作 alt 来处理。
Select Language