@asdblue MV3 的问题不是生态不成熟。对扩展作者来说，MV3 相比 V2 有更少的功能和更多的限制，有些插件可能永远都没法升级到 MV 了。

finder 最幽默的是，默认不显示路径栏，又没有“上一级”按钮：
一个应用程序用 finder 打开了一个文件夹，那好，现在我怎么知道我在哪个文件夹里？这个文件夹位于文件系统的什么位置？我甚至没法一眼判断我当前哪个硬盘里。
当然我可以打开路径栏，或者打开“分栏”视图，或者用 Command + ⬆️ 一级一级按过去，但是为什么，这种基础功为什么不是默认打开的？

omv web 那个好像是 mbadm 组的。装回 omv ，或者用别的 linux ，跑一下：
mdadm --assemble --scan
没问题的话应该就找回来了。
现在不玩 omv 了，可能不太准确。

omv 上的 raid 是怎么组的呢？如果是 zfs ，装一个有 zfs 的系统，zpool import 应该就能看见了，再 zpool import -f <POOL_NAME> 应该就有了。

这个主机的 m2 口应该都是 pcie 的，协议没问题。
但是 m2 ssd 是 m key 的，m2 网卡一般是 a + e key ，接口不兼容，需要搞一个转接板。搜 m2 nvme 转 wifi 可以搜到，类似这种： https://e.tb.cn/h.hxe2i6HQfD5mrwm?tk=VCuS4nbojw5
注意有些网卡是 cnvi 协议的，那些也用不了。

unraid 不是有虚拟机吗，虚拟机开一个飞牛，把 unraid nfs 挂到飞牛里不好吗？
都已经在用 unraid 了，换飞牛又要重新导数据，飞牛又不支持直接挂载已经有数据的硬盘做内部空间。

https://wiki.archlinux.org/title/NVIDIA#DRM_kernel_mode_setting
https://www.reddit.com/r/linux_gaming/comments/1dnccoq/ubuntu_2404_wayland_on_nvidia_troubleshoot_guide/
https://askubuntu.com/questions/1369250/how-do-i-enable-wayland-on-ubuntu-21-10-nvidia

....

@feikaras 如果架构层面想删就删，那就更坐实了微软的不思进取。

从产品层面，现在的控制面板绝对不能删：新的设置界面没有涵盖所有功能 。删掉了控制面板，Windows 就缺少功能了。所以微软为什么不做一个能涵盖旧控制面板功能，具有现代 UI 的设置界面呢？如果不是架构不允许，那就只有不想做了。

微软开发了一套新界面，这套界面只实现了老界面 50% 的功能就发布了。“反正我们又没删老界面，如果出了问题，用户可以用老界面嘛。”

保持兼容性是一个好事情，其他系统没必要做。只要遵循 semvar ，不兼容更新放在主版本，对历史版本长期提供修复更新。如果有兼容性风险，用户可以选择不更新主版本。
当你大力推动用户升级主版本，包含新功能的小版本自动推送的时候，你就不得不保持兼容性。（“用户可以关”不是借口，你不能在自动更新没出 bug 的时候默不作声，更新出了 bug 就质问用户你怎么不关自动更新）。

梳理一下我的观点：
Windows 的架构优秀 -> 架构能支撑微软做好产品 -> 微软没把产品做好 -> 微软不在乎产品
Windows 的架构垃圾 -> 大版本迭代的时候应该调整架构 -> 新的架构能支撑微软做好产品 -> 微软没把产品做好 -> 微软不在乎产品
Windows 的架构垃圾 -> 大版本迭代的时候应该调整架构 -> 为了兼容性，微软不调整架构 -> 微软可以不发布大版本 -> 微软一定要发布大版本，在大版本为了兼容性不调整架构，又在大版本中塞不兼容的更新（ XP -> Vista ，TPM 2.0 ）-> 旧的架构不能支撑微软做好产品 -> 微软没把产品做好 -> 微软不在乎工程质量，也不在乎产品

Windows NT 有一套优秀且先进的的底子。微软从来不缺好的技术，也不缺好设计，更不缺钱。微软只是不在乎。

只看数据量还好，优先检查有没有对应数据生成 dom ？比如每个浮点数都对应一个 div 放在页面上。
一千万个浮点数不一定会卡死页面，但一千万个 div 肯定能卡死页面，必须上 virtualizer

所谓 Windows 向后兼容性做的好，我看来完全是 Windows 产品质量差，不在乎用户。

总有人说 Windows 要照顾企业用户、要照顾第三方，必须做好向后兼容。

第一，需要可靠性的企业用户根本不可能跟着你升级 Windows 大版本。真正给企业用户用的 debian 、rhel 是怎么做的？大版本根本不动，同时提供长时间的修复更新。微软真正给企业用户用的有 Windows Server 和 LTSC 。

第二，从来没有人逼着微软发布新版本，如果担心第三方不兼容，你大可以不发布新版本折腾大伙。实际上微软根本不担心第三方不兼容，每次大版本更新都强迫用户升级硬件，硬件第三方就不是第三方了？微软只是借助发布新版本强迫用户升级他们内置了更多广告和遥测的新版本而已。

第三，所谓控制面板、资源管理器、explorer.exe 太底层了改不动、删不掉，不也正是 Windows 代码质量差的证明吗？ UI 层的东西和系统底层耦合过深，当然不好改了。这种屎山微软每次发布大版本都有机会迭代掉它，但微软只是视而不见。

我觉得这不是偷懒，这是 Windows 如今根本不在乎产品质量，不在乎用户体验，只想在现有 Windows 用户上竭泽而渔的体现。

@gigishy lz 说分不清数据冷不冷热不热，其实根本不是个问题。

1. 所有数据都在方便访问的地方保存一份，比如本地硬盘，或者 NAS 上，这是你的热数据，需要的时候随时来取。
2. 同时，定期把这份数据备份到另一个地方，比如磁带机，或者云服务的冰山存储、归档存储，这是你的冷数据。
正常情况完全没有访问冷数据的必要，所有数据只从热数据里读取。只有在热数据遭遇损失 / 需要撤销热数据上的更改时，才访问冷数据，从冷数据中恢复数据。
3. 当然，如果是自建的冷数据方案（磁带机），还需要定期校验冷数据的有效性，别放坏了。

@ExplodingFKL nfs / smb / webdav 是由宿主机提供还是 VM 提供？一台 AIO ，各种服务是应该由 VM 提供还是应该由宿主机提供？

@laminux29 如果有得选谁想直通呢，PVE 自身对 smart 信息的展示有限，很多玩家不想在 PVE 本体上跑各种服务，或者有监控磁盘状态的需求，那就只能在 VM 上 跑 NAS ，让 VM 直接管理硬盘。

手动装了太多次 arch ，已经刻在 DNA 里了

1. fdisk 分区
2. mkfs 格式化
3. 把盘在 /mnt 里挂好
4. 改 mirrorlist
5. pacstrap -K /mnt base linux linux-firmware
6. genfstab -U /mnt >> /mnt/etc/fstab
7. arch-chroot /mnt
8. 改时区 ln -sf /usr/share/zoneinfo/Asia/Shanghai /etc/localtime
9. 改 locale ，写好 /etc/locale.gen ，locale-gen ，写 /etc/locale.conf
10. 改 /etc/hostname
11. passwd 改 root 密码，装 sudo ，改 /etc/sudoers 允许 wheel 用户组 sudo ，给自己创建一个用户，加进 wheel 组里
12. 把其他要装的包装了，如果需要无线网记得装 iwd / wpa_supplicant ，写 systemd-networkd 配置把网络配好
13. 别忘了装 bootloader ！一定记得要装 bootloader ！每次装 arch 都会忘记装 bootloader ，重启对着 uefi 瞪眼才想起来没装 bootloader 。

@um6uih 你再仔细看看呢😂它是 mac mini 2014 ，4G 内存，闲鱼上都不要 400 块钱……可比 n100 准系统便宜。

Mac 长年火狐，页面滚动体感比 Chrome 系流畅很多。打个比方 Firefox 像是在滑玻璃，Chrome 系像是在滑塑料。

Windows 下冷启动确实很慢。

搭车问纯自用，tailscale + 自建 derp 与自建 wireguard 区别大吗？既然 tailscale 底层也是用 wiregurad 的话。

感谢大家 原来 Linux 对 NTFS 支持已经很稳定了吗。我还停留在 NTFS-3g 会损坏 NTFS 的版本…
@yinmin 感谢大佬 解惑了
@laminux29 也想过 NAS + SMB 的方案，目前确实没条件上 NAS T^T

不一定要多用 useMemo ，但一定要少用 useEffect 。
见到很多 React 新人 useEffect 的时候，会创建很多多余的 state ，比如下面这种代码：

```
const [lightColor, setLightColor] = useState<'red' | 'yellow' | 'green'>('red');
const [canPass, setCanPass] = useState<boolean>(false);

useEffect(() => {
if (lightColor === 'green') setCanPass(true);
else setCanPass(false);
}, [lightColor]);
```

这里 canPass 不该是一个 state ，根本就是一个 computed value ，用 useMemo 才对：

```
const [lightColor, setLightColor] = useState<'red' | 'yellow' | 'green'>('red');
const canPass = useMemo(() => lightColor === 'green', [lightColor]);
```

大多数场合 useMemo 也是多余的，遇到性能问题再优化就可以：

```
canPass = lightColor === 'green';
```

所以我给 React 新人的建议都是：少用 useEffect ，如果遇到了必须 useEffect 的 case ，看看 ahooks 等库里有没有现成的 hook 。