zfs 开加密，zfs send 发送快照，或者使用 rsync 限制速度同步 .zfs 快照目录里的文件，压缩用 zfs 透明压缩

我是很严重的螨虫过敏，在家里流鼻涕流得我想死
高温清洗晒被子除螨仪有点用，但治标不治本，过两天又开始过敏
我的方法是，羊毛被+聚酯纤维，避免棉材质，家里抽湿机控制湿度在 60-75 左右，勤打扫吸尘保持干净，多锻炼身体
一旦有螨虫过敏发生，要立即找到源头并果断丢掉那件家具。

挺好的，至少不是“我花三个小时用 cursor 写了一个 xxx”

> 本地跑 Python ，比较慢

使用 faster-whisper + 显卡

> 识别中文的时候，时间戳只能精确到 1 秒，而不是 0.1 秒（明明识别日语的时候都可以精确到 0.1 秒），导致字幕展示时间不精确，不能用

开启 word level timestamp ，默认是不开的

> 翻译

使用 https://heimoshuiyu.github.io/whisper-web/ 转录同时利用 GPT 翻译字幕

牛，问下检索是怎么做的？调用哪家的 API 吗

跑 whisper 自建语音输入

难道不是研究怎么在合约里加后门吗

golang 吉祥物好看吗

@Moonkin 并不是“大部分人都喜欢有人工管理的社区”。我觉得只是在“严格审查的大规模社区”和“没人管的孤独模拟器”之间找到一个平衡点

@aloxaf 缓存问题你说的对，但我指的是在有写缓存的方案之上创建 btrfs 或 zfs ，上层的文件系统调用 fsync()写入数据时，下层的写缓存设备在数据实际写入磁盘之前就向文件系统报告已经写入完成，并且可能改变实际的写入顺序。这相当于破坏了日志文件系统的一致性

noatime 我开了，数据库目录我也 +C 了，btrfs defrag 有一些改善，但不多，现在想也可能是因为我元数据用 raid1c3 的原因（

在 btrfs raid1 模式下，文件被分成多个片段，每个片段写入到任意两个设备中，不管池里有多少设备，如果写入分布均匀，同时坏两块盘，那么几乎可以肯定会有数据和它的副本位于这两块坏盘上，这些数据就损坏了。也就是说，btrfs raid1 只能容忍坏两块盘，坏两块盘必丢数据，数据很有可能分布在各个文件中，盘越多风险越高

@Moonkin 每个 instance 的管理员当然能能管理自建的实例，在他的 instance 上他想干什么都可以。实例规则只是君子协定。如果你想保证没有人能删帖那么最好自建实例，然后用过直接关注或者中继到其他实例，别人除了 block 没有任何办法。

第一条不熟悉，不清楚。

第二条，我也是这样，但是我发现我有一个显示器（ HDMI 接口）即使关掉了（但不断电）系统也会认为它还连接着。我就可以放心关掉显示器并使用远程。或者干脆插个显示诱骗器在显卡上。

fediverse

首先 btrfs 就有点灵车属性，把 btrfs 放在任何方案之上都是灵上加灵，灵车漂移。数据损坏不是丢几天数据这么简单的问题，如果硬件或其他故障，缓存里的数据不一定能写回 btrfs ，可能破坏 btrfs 元数据，导致整个文件系统出问题。

zfs 资源消耗大是事实，但 op 有 64G 内存我认为是资源充裕。我在树莓派和系统盘上使用 btrfs ，在 32G 内存的 nas 上使用 zfs 。

我的 nas 曾经是 4x4T 的 btrfs raid1 ，小文件比较多，ls 一个 10000+文件的目录需要 5 秒以上，sqlite3 数据库经常需要 30s 写一个 transaction 。迁移到 zfs 后这些问题都不存在。要说性能下降，btrfs 比 zfs 更严重。

没有 ECC 使用任何文件系统的风险是一样的，zfs 没有什么特殊的地方。

op 有 4 个盘，考虑到 btrfs raid5/6 是灵车，只能用 raid1 。btrfs raid1 的意思是吧数据块放在任意两个设备上，那么 4 块盘坏任意两块就会导致 **全部** 数据丢失。而且目前 btrfs raid1 没有实现读取的加速，读取是根据 pid 数字选择设备，除非你有多进程，否则读取就是单盘的速度。

综上，简单需求 / 资源受限 / 设备大小不一致或者未来会经常增减设备 的情况下才考虑使用 btrfs

debian 我甚至开测试仓库

太酷辣

systemd 就是大而全，contab 是小而美。用哪个自古以来就是一个争议话题。我的意见是，如果任务简单就使用 contab ，如果任务可能超时、需要依赖其他组件、有特定启动顺序、需要自动重试之类就用 systemd

@kyonn 是的，让 chatgpt 给你写个 fastapi 接收 “webhook 或特定格式的输入”然后用 apprise 发送