分区 大小 文件系统 挂载点
分区 1 512M vfat /boot/efi
分区 2 512M ext4 /boot
分区 3 剩余所有空间 btrfs /

如果不需要 btrfs 的各种特性，想根目录也用 ext4 ，那么后两个分区可以合并成一个。

如果是笔记本，需要开启休眠特性的话，还得分一个大于等于内存大小的 swap 。
服务器上如果需要用 swap ，只要不是开机就需要大量 swap 就可以用 swap 文件来实现。

方案是为需求服务的，如果你有频繁调整存储卷的需要，就可以考虑使用 LVM ，否则的话徒增一个抽象层，增加一定的使用和故障恢复成本。

对了，如果需要用 btrfs 的快照功能（备份、恢复、版本控制会比较方便），根目录要挂在 btrfs 分区的子卷上。

没有万金油方案，一切都可以按照你的需求来调整。

服务软件提供 docker compose 的目的在于可以让普通用户不需要去关心部署和连接数据库等组件，一键运行一整套可以用的服务。

容器的一种使用思路是不同服务之间互相隔离，不光是服务本身隔离，数据库和中间件等也可以进行隔离，这样就不会在发生故障的时候互相影响，也不会在一个服务受到网络攻击后导致所有服务受到影响。一部分企业应用场景是可以接受每个服务跑自己的单独的数据库服务的开销成本的，来换取这种隔离带来的各种好处，可以更加灵活地调整每台服务器上部署的容器种类和数量（所以出现了 k8s 这种调度工具）。
但你的需求不一定是这样的，比如你无法接受同时运行多个数据库实例所产生的开销，或者不适合你的管理方式，那么你就完全没必要遵循这样的设计惯例。

当你有特殊需求的时候，比如你需要在另一台服务器上跑数据库，又或者是你需要统一管理所有服务的数据库（比如做主从备份会比较方便），你就可以写自己的 docker compose 配置文件，或者使用命令参数直接部署服务容器，然后通过服务配置文件，或者容器环境变量（取决于容器镜像是否提供这种能力）来配置要连接的数据库的地址、用户名、密码。

如果你要用 Postgres ，你就避免不了了解这个数据库的使用方式，包括如何管理用户（角色）和权限，多搜些教程看看吧。

目前主力机稳定使用 Manjaro+Gnome ，近两年没滚挂过，可靠性比 Arch 高一大截，还能用 AUR 。
主流 DE 都挺好的，看个人喜好，我现在在 Docker 机上跑了个 xfce+xrdp ，能满足基本远程登陆使用。

之前听说有一家专门做 Linux 电脑的品牌做了个 Pop!_OS ，一直还没试。

其实发行版基本就是社区按照自己的口味组合和配置一套环境出来，东西在各个发行版的软件源里都有，动手能力强可以不拘泥于用哪个发行版。

我们公司以前用 CentOS ，后来容器化了之后宿主机就无所谓用啥了，红帽宣布改变 CentOS 策略之后我们很容易就换了 Debian 作为宿主机，再后来就用云厂商自己的发行版，功能、性能都会好一些。

现在 RHEL 的意义主要还是一整套付费支持服务，还是有很多企业需要的，特别是用私有云的，一方面可以降低运维成本，另一方面可以提高服务质量，花钱就能解决问题。

稳不稳主要看固件吧，我之前 R4S 换了四五个固件才找到个稳定的，跑了小一年了。

要考虑个人文件的备份问题，要么就是同机跨盘备份，要么就是跨机备份。注意，RAID 并不解决数据完整性问题，还是要备份。

个人认为稳定性需求是网络设备>存储设备>服务设备，所以我目前的方案是 R4S 做路由负责网络功能、独立 NAS 设备负责存储和提供文件访问、独立服务器用于运行各种服务（ NFS 挂载 NAS 的文件系统）。

不想折腾的话，还是推荐用白群晖做存储，可以考虑额外搞个硬件编解码能力强的设备来播放 NAS 上的视频文件，这样只要你内网带宽足够，就不会有体验问题。

RAID 保障的不是数据的完整性，而是数据的可用性，是在设备故障的一定程度的时候可以不中断对数据的访问。
保障数据完整性的核心方法是备份，多备份几份，放在不同的地方。

如果你想要保证数据完整不丢失，就多买几块盘备份数据，或者备份数据放到网盘上。
如果你想要提高访问速度，就考虑使用 SSD ，或者组 RAID0 之类的提速方案。
如果你想要确保数据 7x24 小时可访问，就多几台服务器负载均衡提供相同的数据。
如果你希望少量硬盘损坏可以不用停止服务器提供服务，就使用 RAID 的冗余方案。

这属于是因为不信任法律的实施所以想要采取非法手段，但又同时要参考法律规定的边界。
有些自相矛盾了。

Token 也可以放在 HTTP 的 response 头里，比如用 authorization 头来返回给客户端。
客户端不管是浏览器页面还是 App ，都可以做一个统一的请求拦截器，负责管理 token ，在登陆成功后自动读取返回的 token 信息并存储在本地，拦截每一个发送的请求自动读取本地存储的 token 信息加在 authorization 头里，根据认证策略自动刷新即将过期的 token 。

比如你前端页面使用 axios 发送请求的话，可以看一下 axios 的 interceptors 相关文档。

srt 兼容性最好，一般和视频文件名一样就可以自动加载。电视默认播放器不支持的话可以装个支持的播放器试试。
自己部署一些视频串流服务如 Plex 、Jellyfin 之类的可以在串流过程中自动把字幕烧录到画面上。

能满足你的需求就没必要换，除非你就是想折腾，或者发掘一些新需求。

我一开始奔着 MergerFS 去用 OMV ，不过因为 OMV 本身是基于 Debian 的，所以我额外在 Debian 基础上做了很多配置和优化，可以说我目前实际上用的是 Debian 。

另一台服务器曾经用来当过几年 HTPC ，跑的 Win10 ，用来连电视看电影和玩游戏，但基本每运行一到两周就会出现莫名其妙的问题，重启可以解决，感觉可能是有内存错误的 bug （所以一般服务器跑 Windows 我都推荐用 Server 版，尽量不要用个人版）。后来也换了 Debian 用来跑 Docker 容器，稳定很多。

尝试过 PVE （也是基于 Debian 的），但发现一方面虚拟机配置需要调整的时候也没那么容易，另一方面当时家用显卡直通以及 vGPU 方案都很麻烦，综合衡量下来我的需求，包括 AI 画图和 Jellyfin 转码，其实 nvidia-docker 就完全可以满足，还能更灵活。PVE 可能更适合跑不同的平台（比如 Windows 和黑苹果）的需求，或者比较彻底的隔离（比如用不同 kernel 的 Linux 发行版）的需求。

曾经在服务器上跑过旁路网关，用来给部分设备提供透明代理能力，但后来发现网络设备的可用性要求要远高于普通服务器，折腾服务器的时候网络不可用就挺烦的，于是后来我搞了个独立设备跑 OpenWrt 来当主路由，所有网络相关的功能都放在上面，除了透明代理还有 DDNS 、OpenVPN 以及连回家用的加密代理等，也稳定运行了小一年了。

所有这些设备我最早弄的是 NAS ，当时基于最简单的存储需求，不需要在 NAS 上跑任何其他服务，所以用了个 J 系列的工控版，只有 4 个 SATA 口，虽然跑存储绰绰有余，但后来有了跑服务的需求发现这个配置跑服务会很吃力，于是就用一台淘汰的游戏 PC 来当服务器，用 NFS 来操作 NAS 上的文件。后来觉得这样故障隔离、性能隔离还挺好，就一直是这种方案了。

https://github.com/ACL4SSR/ACL4SSR/tree/master/Clash/Ruleset
里面找 Steam 的两个规则文件看一看

作为一个 16 年 Linux 用户，我不会去推荐一个人用 Linux 换掉 Windows 或 macOS ，拿工资的才会有动力将产品做得好用、可靠、支持好，Linux 生态中大部分还都是用爱发电或者企业为了自己的业务而开发顺便贡献社区，也就意味着要从找客服解决问题变成在邮件组、社区论坛提问以及自行 Hack 。

当传统商业操作系统没法满足你的需求，或者你希望能从 DIY 的过程中获得满足感，Linux 就值得尝试。

目前因为国内系统国产化，以及 Steam Deck 的大火，还有 Linux 生态本身的长期积淀，确实 Linux 的体验越来越好了，但目前距离商业系统对常规需求的满足方面，确实还存在一些距离。

使用 lsblk 之类的指令发个分区表和挂载信息出来，大家可以帮你判断是哪一种情况，如何处理。

计算机在与目标 IP 通信前，会先查看自己接入了哪几个网段，然后看目标 IP 在自己的哪个网段里。如果自己同时接入的多个网段有重合，而目标 IP 恰好在这个重合范围内，有可能计算机会使用错误的网络接口尝试与目标 IP 通信。
如果目标 IP 不在自己接入的任何网段，且自己可以连接到至少一个网关，那么将会尝试让网关帮忙找到路由。

这个过程不会获得到目标的子网信息，仅靠一个目标 IP 和自己的接入的网络信息来完成。

用旧笔记本可以零成本吧，你先用方案 1 用一阵试试，到时候觉得不满足自己的需求再根据需求进行调整就好。

笔记本电池拿掉，基本不会有起火问题，还担心就搞个烟雾传感器、备两罐车载那种便携灭火器。

NAS 就是个无底洞，要求和投入可以高到天际，没啥所谓合理不合理，能满足你现有需求就行。

开公司，申请出境的网络线路，直接到国外调用 API 就行了。
其他的就是做好合规，比如数据出境，还有最近出的几个生成式 AI 的法规，做好内容审查就行了。

不过按照美国商务部前几年的法规来说，可能禁止出口 AI 到中国，也就是说你合法了可能 OpenAI 没法符合美国法律提供服务给你。

拉面说的冬阴功是我第一次觉得好吃的冬阴功（虽然可能不是正宗冬阴功），很清爽。有一点辣味，但我不喜欢吃辣的朋友也觉得好吃。

当然口味这种东西比较私人，东南亚泡面花活比较多，有机会了可以找一些比较出名的挨个尝试一下。

Debian 和 Arch 用户表示，我就纯看热闹。

是破坏了一些生态，但一方面红帽有这个权利，另一方面破坏的生态并不是红帽提供的生态体系。对于愿意付费订阅红帽的人来说，这种变动没有影响。

开源界的供应链风险是始终存在的，因为依赖者与被依赖者之间并没有合同、协议来维系这种依赖关系，公共许可证通常也不对此进行约束，这也就是为什么一些基于其他发行版的发行版，最终会选择切断依赖来维护相对独立的发行版。

对商业公司来说，开源从来都是手段而不是目的，比如 Google 开源 Chromium 和 AOSP 并不是为了其他人可以做 Chrome 、Android ，而是为了巩固市场壁垒。可能现在红帽的管理者认为限制 RHEL 的源代码的访问，在市场方面来说利大于弊，我也不清楚这属于是正确的商业决策，还是竭泽而渔。