@byby 偶尔比如停电了，铜线电话还能打通，光猫没了交流电就关机了。

openwrt 我玩过，有些型号是可编程交换机，可以 lan 口拆出来改成第二个 wan ，luci 图形界面就能设置

很久以前看到说 UTXO 模型相对账户模型来说只需要交易间能保证偏序关系，不需要全序关系，以太那样有图灵完备智能合约的需要后者。但不是很明白

之前还看到过 bromite webview ，但我没刷。

screencam 录屏内录音频

解除 flag secure 截屏限制

ida pro 动态调试

哦还有，之前看到说 Android 14 qpr2 会导致一些用了梆梆企业加固的 app 挂掉，尤其是银行类 app 。

楼主没在用 lsposed 么？
我是 k40 ，在用 los20 。
看楼上提到 lsposed 有问题我感觉最好暂时还是停在 los20 。

嘛算了，我点下沉了

@fairytale HM-SMR 和 F2FS 本来我也想提但搜了一下发现我有一点记错了所以没提，f2fs 我误以为是直接对接裸设备的（而且还是跟既存系统不兼容不能吃不能碰、一碰就报错吓你一跳的裸设备），但搜了一下看到说闪存上它不是这样。

然后我想确实如你所说，如果作为用户真的想要掌控这些技术细节，那么选企业级产品就好，企业 QLC 盘就不搞 SLC cache ，SLC 就是 SLC （比如听起来高大上的 SCM XL-Flash ） QLC 就是 QLC ，然后上层怎么搞都可以随心所欲了。

@sujin190 我好像不太明白你说的“每 bit 随机”是什么意思，据我所知虽然闪存的擦除和写入最小单元不一样但都是基于 block 的，好像只有傲腾 DCPMM 才能按字节寻址。

但看你的回复，我想了想，突然意识到我都忘了现有体系下一个设备内部的块大小是固定一致的不会忽大忽小，比如请求读一个 LBA 就只会返回 512 字节；不会请求读这个地址返回 512 字节，下一个地址就返回 1536 字节了，甚至从来没人想到过考虑过未来会出现这种状况。

（嘛我记得也有设备不是 512 而是 4096 ，528 等等其他数字，但一个设备还是只有一个固定的数值）

然后，想要实现我的想法需要在接口协议层面引入新的 TLC 模式读写命令。

于是，这种“压缩”的兼容性就基本完蛋了……

同一块盘插到老系统上，会各种报错：

首先是文件系统驱动发现自己不认识新的“压缩方式”；

其次就算某个文件系统实现无视这一点试图强行去读，因为接口协议层面引入了新的 TLC 模式读取命令，主控那边发现主机没有按照新命令读取，拒绝返回数据。

某种程度上可以聊以自慰的是，写入的时候，如果还是用老的写入命令，那应该可以不报错，所以（呃还得假设格式化程序不会先读取检查什么再写）如果在老系统上格式化了，那格式化还是可以正常完成，会变成一块纯 SLC 的盘。

除此之外不用多说，现有的各种直接读 block 的实用工具，像 DiskGenius 一样做数据恢复和备份的软件，也会全部挂掉……

（乐观估计的话，也许没设为压缩的文件在老系统上说不定还能读，逃）

（嘛很显然还是不应该只折算 3 倍然后就搅和到一起磨损均衡了，TLC 模式对磨损比 SLC 敏感得多，如果不想太快就失去 TLC 模式写入的能力，那还需要特别处理，比如预留一部分空间不磨损……但相比闭着眼全盘 SLC cache 的现状我感觉至少不会更差吧）

@povsister 哦还有，我也没有隐含说比如主机指定 TLC 模式写进去，那个文件的物理存储位置就固定不准挪动了。只要 SLC 模式的写入多折算 3 倍（大概），都可以算进磨损平衡里一起搅和

@povsister “是用 TLC 还是 SLC 模式写入”这个当然在主控固件里也还是有一套算法来管理的……不过你确实可以吐槽说硬件/软件这两个相对的概念使用不妥

还有……现在一提到“压缩”通行的理解全都是指代算法实现的“数据压缩”，但我确实觉得 3 个 bit 挤进一个存储单元这种事情你叫他“物理压缩”好像问题也不大啊？“压缩”这个概念本来不就是从物理世界借用过来的嘛……