@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 发送

apprise

sqlite 文档 FAQ 里就写道

“Threads are evil. Avoid them. ”

sqlite 没有并发，一切写入都是单线程。如果你硬是开多线程那么之后造成互相竞争锁更慢

koreader

mdbook 然后往什么 github pages 之类的免费平台一挂就完事了

猫好，夸夸

photoprism 不是支持 heic 吗，元数据也能读

window.mycache ={}
你在制造原本就不存在的问题

这个是 sway 桌面的配置文件，位置在家目录的 .config/sway/config