@datocp #1 努力的方向一样重要 现在假装努力的人确实很多
@qingdouwangxiao #2 资源固然重要 不算是唯一的决定性因素吧
@AntiEoom #3 这倒是 纯靠能力 要被别人知道需要付出的努力还是很多的
@jenhe #4 何以见得 现在那些普世认知中比较好的工作“机会” 子承父业的可能性起码低于一半了吧

确实被动收入很让人鼓舞
我目前就是投视频 做点教程啥的
靠这个半年已经赚了五十多块钱了

6
让用户静态配置 v6 这个操作确实好 6
听着离谱 理论上应该有接收 PD 前缀的方法吧 有没有可能只是 OP 没找到

南京电信 宽带好像没有安装费 iTV 初装费 100 元

网贷不知道 OP 是怎么沾染上的 我自己算了下实际年化利率之后就从来没看过了
可能是自己不小心沾上了消费主义 建议办张城市的旅游年卡 没事出去转转 多接触下自然世界
而不是靠所谓的消费、科技产品、花里胡哨的 EDC 之类的来定义自己 迟早会花好多钱进去 但是对自己又毫无提升

@zephyru #4 RAID0 是多倍容量 性能翻倍 任意坏一块盘则整个阵列完蛋
家用禁止做这个（除非纯下载盘或数据完全是缓存作用

家用最佳策略就是 RAID1 然后做好 3-2-1 备份！！

感觉没啥含金量 压根没看 纯靠着「软件需求工程」课程里学到的敏捷知识就裸考通过了 复习时间 1 天 今年刚过的

@libook #6 我来帮楼主回复一下 他说的“有几率发生目录错乱的场景”
估计是重启 又打开了自动启动阵列 然后文件共享还正常的启动了
但是他重启前手动的 mount 了一个子文件夹 （如果不 mount 到 user 下 在容器的网页管理 volume 里看不到）
如外置的 USB 盘 或者啥 U 盘设备 或者 NFS 设备 命令可能是 mount /dev/sda /mnt/user/download/usb_disk
重启后 容器仍然正常运行了 并且配置的 volume 仍然是 比如 /mnt/user/download/usb_disk
但是此时没有 mount 导致容器直接写了文件到阵列里 如果这个时候楼主没有发现这个问题
又直接 mount 了外置存储 就会导致阵列里已有的文件被掩盖 后面又需要挪来挪去

如果只是对 mover 有问题 感觉不至于发生楼主说的目录错乱

顺带一提 备份方案我是用的是 rsync 远端全量同步 到云是用的是 restic 设置 128M 的备份文件大小 全量上传至云

重启之后自动 start 关掉 自己设置好再重新提供服务就好了
我觉得设计上还是挺不错的 提供 disks 等可以直接操作数据存在哪块盘上的接口
也提供 user 和 user0 前者指代阵列本身 后者如果配置的 share 目录有 cache （第二存储空间）会忽略掉
打算有空出一个文章详细讲一下吧 感觉不少小白并不清楚 unraid 的 mnt 下所有的文件结构 加上现在有了 zfs 之后更混乱了

坐标 025 （南京电信）看了下我的 PD 前缀确实是/60 但是我自己设置的请求前缀就是 60
晚上回家看一下家里光猫自己拨的宽带是不是/56 我记得一直都是/56 还没在意过
不过对我的影响还不是很大 额外的子网我就划了一个/64 出来

楼上讲 QQ/微信的明文有点过于严重了 不装自签证书的话很难看到 SSL 加密的原文
不过实测能检测到登录的 QQ 号 这个是明文传输的 很容易就看到 自家路由有镜像功能的话可以抓包看看

支持一下

@microka #53 我目前是方案二 匹配入站流量 对特定一个高位端口放行 ipv6 其他方案实在维护起来麻烦

访问到？就是一个路由器呀
查看你的/etc/resolv.conf 能看到位于内网的 DNS 服务器
那反正是阿里的私有域名 帮着解析呗 根据你的源 IP 自动把这个域名解析成内网不就好了

同样折腾了类似需求 不过最终放弃了 目前是文件尽量不打包（为了搜索效率）

@dearliuliu #29 目前就是自己用 并不打算推给啥用户 系统已经完成迭代了一次
（由前后端不分离的 Django+BeautifulSoup5 过渡到前后端分离的 Vue3+elementPlus
主要的用户就是家人和同事 打印好贴纸给他们 可以方便的记录物品信息

@yzwsreng #30 二维码做物品收纳唯一不好的就是数据线之类的东西不好收纳
所以我的选择是买了小的牛皮纸袋 把数据线之类的不好贴的物品放进去

@huangmingyou #31 这么大的台灯贴贴纸的意义重点不在于找 而是记录
况且同款台灯我有三个 系统目前已经支持了语音、图片和视频记录功能
比如可以将购买来源 购买记录、订单号、截图等附在这个 UID 上
有购买信息就方便找客服 也方便记录过保时间或者物品保质期

开发这个功能的初衷是
公司有一部分设备是采购买的
需要找售后的时候客服让提供订单截图
这种截图随货走的形式就很方便

现阶段我在考虑怎么把物品信息这张大表稍微拆拆
虽然已经像用户表、用户详情表这样分离了基础字段
但是详情表里的拓展字段还是太多了
准备拆分成属性表 然后这个属性表 K-V 的 K 就是字符串
V 可以是 IP 地址、日期、数字、文字、图片、语音、视频、网盘文件等

目前在测试的功能是时间记录和提醒 比如食品即将过期
不过比较偷懒的是 提醒用的是方糖推送（

虽然可能有点跑题 但我这个系统初衷更像是在线记录实体的相关信息
具备寻物功能（树状的层级关系）但重点不在此贴的寻物

@dearliuliu #11 哈哈 为啥要做一个后台 因为虽然设计上是前后端分离的
但是同时规划了 web 端和小程序端 也是为了不完全耦合小程序
web 端做的就偏后台管理 类似超市收银台 手输条码或者搜物品名字
然后小程序端主要实现的功能是物品归集 就是把一堆东西放进箱子里 和箱子关联
还有在开发的功能是定期寻物
用程序标记在一个箱子里所有物品为未找到状态 然后挨个扫码 用来追踪比较频繁变动的箱子里面的东西少了哪些
当然 上面说的箱子不局限于箱子 可能是一个场所/容器/关联物品比如充电器和数据线的关联
其实最主要原因是我是个偏后端的程序员 对小程序了解比较少 开发起来就很慢

同样有寻物需求
所以我自制了一个物品管理系统
用 UUID 作为物品唯一编码
然后手动维护场所-物品 之间的关系
一般不常用的东西只会出现在固定的地方
所以还是挺好用的
示意图如下：
目前微信小程序端还没开发完善 只是个预览
后台管理已经基本搞完了 日常用起来没问题