1 ，raid 不是备份。
2 ，磁盘全部 BASIC ，数据都在 A 盘，用套件定期备份到 B 盘。（每小时）
3 ，用套件定期备份到外置 USB 硬盘柜。（每小时）
4 ，用套件定期备份到公司群晖。（每天）以前用的百度网盘做异地，太慢还要会员，鉴权还老丢，放弃了。

这样 321 都有了，本地备份两份，异地一份。

这种时候要么就是**desk 一类的远程工具。
要么就是走 moonlight 串流，我个人非常喜欢串流的方式来共享屏幕，流畅度很高。

来不来常熟，四线城市，旅游城市，有山有水，江南福地，四季无灾，气候宜人。

大概率内鬼，哈哈哈哈

@aglsv #13 我没 16 ，我是 14 ，重量不会造成困扰。

@celaraze 继续补充下，2023 年末起，几乎所有手机厂商做的笔电开始在性能和续航上面很花心思也很有成效，这部分就是因为这些手机厂商搞 soc 调教经验太丰富了，买这些厂子的笔电不会错。

618 刚入，同款机型用户，redmibook pro 14 2024 。特地买来写代码，平时用 arc 核显玩 wow 无压力。去看看猪王和笔吧评测，我给的建议还是比较主观的。
1 ，续航在 windows 本里面很强。
2 ，做工没话说，新模具很舒服。
3 ，触摸板很硬，不好用，我是被 MacBook 养叼了。
4 ，屏幕素质没得说，我特别注重电子产品的屏幕素质。
5 ，性能？ 65W 全释放，试试就知道了。
https://i.imgur.com/UP936bT.png

#4 补充，设计时候要做对业务功能做模块化处理，如果闭源代码过于耦合，显然不适合。我是把闭源代码放在单独的目录中，这样才能用 git submodule 处理。

楼上都是说的啥，我使用子模块处理的，a 仓包含了 b 仓代码内容，b 仓不公开，a 仓 git submodule 加 b 仓地址。开发者正常 submodule update 会提示需要 b 仓的 credentials 才能拉取到这部分代码。

子查询直接丢 JOIN 不行吗？还是条件更复杂？

SELECT u.id,
u.name,
GROUP_CONCAT(i.email) AS email,
GROUP_CONCAT(i.phone) AS phone
FROM user u
LEFT JOIN (SELECT * FROM contact where conditions) i ON u.id = i.ref_id
GROUP BY u.id;

@yxd19 大部分是软件决定的，其中高可用（ HA ）、容灾冗余、备份等等都是需要硬件资源开销的，例如要做备份你得有额外的存储空间，要做高可用就得做多个 NAS 随时待命这样。

兄弟，大小周别整，没意思，直接新公司
单休不是简单的单休，按一周来看，双休是做 2.5 天休 1 ，单休是做 6 休 1 。

你信得过我就 Hyper Backup 整机加密备份到我白群，我有公网 IP ，每月请我喝杯咖啡就行^ ^

我自己的 321 方案是，A 盘存数据，B 盘存备份，都是 Basic ，A 盘所有备份全部到 B 盘，B 盘走 webdav+rsync 备份到公司白裙。

同蹲

这不是推广么，又发程序员节点了

是的，你理解的没错。
如果简单的存储需求即使如此。
但存储一旦开始需要信安、容灾、高可用、321 之类，就要自己折腾协议、授权认证、备份、计划任务、磁盘清理、（非）结构化检索、文件去重、压缩、加密存储。市面上的产品优势就体现了。
除此之外，容器化、虚拟机之类的本身不是 NAS 职责范围，只是 All in one 方案。

@SomeBodsy 我也是，巧了

短链接如果没有生命周期或者生命周期足够长，那久而久之，就失去了短链接的意义，最终会变成长链接。

我认为短链接分享的初衷是在于够短，短时间内方便快速传播。