@znonymous 偶的意思是反正都得加至少 1 个 2.5G 交换机或路由
要么买个带至少 2 个 2.5G 口的软路由，比如 R68S 替代弱电箱的 AX6000 ，R68S 有四个网口(2 个 2.5G+2 个千兆网口)，其中 2 个 2.5G+1 个千兆口当 LAN 口交换机用，这样你次卧的 NAS 和书房的电脑都有 2.5G 口了，剩余 1 个千兆口当 WAN 口接光猫，用 R68S 当主路由拨号而不是用光猫拨号，再怎么也比 AX6000 快，换下来的两个 AX6000 都设为 AP 模式组 MESH ，1F 和 2F 各一个，这样 NAS 和电脑都有 2.5G 连接，缺点在于次卧和书房还要添加有线设备的话，还得买 2.5G 交换机
要么买个 2.5G 交换机放书房，NAS 也搬回书房和电脑一起接到 2.5G 交换机上，其他的房间原有千兆网也够用了，省的折腾，这样还能用上端口汇聚，电脑连 NAS 能到 5G 速度

能放进弱电箱的小体积的双 2.5G 是有的，比如 r68s 软路由，双 2.5G 口一个接书房一个接次卧，双 1G 一个接卧室，一个设为 wan 口接光猫拨号，ax6000 改成 ap 模式都放在弱电箱外，mesh 回程 1f 和 2f 卧室各一个
主路由改为软路由后，书房的软路由可以去掉了，这样书房的电脑和次卧的 nas 都是 2.5G 口，ax6000 也不用放在弱电箱影响信号
但其实这样折腾意义不大，如果 nas 支持端口聚合的话，不如 nas 改回书房，书房的交换机换成 2.5g 支持端口聚合的，nas 接两根 pc 接两根，这样两者有 5g 的链接速度，当然前提是 nas 硬盘速度能有 500MB 哈

单纯学语言很无聊的，要做出东西或解决问题才容易有成就感
既然学的 Python ，那就搞几块便宜的 esp32 的板子，用语法一样的嵌入式 MicroPython 点下跑马灯，读取温湿度做个气象站或红外控制下空调电视机什么的，硬件容易出成品培养兴趣

很明显那个帖子里对方听不进意见
除性格自我外，最大的原因估计是知识面狭窄，偶也猜他只会 PHP ，因为但凡他懂任意一门强类型语言或者会写 APP 都能自己感受到，他所谓的格式在 JSON 结构反序列化后会变成一个有众多属性，但属性名不固定而且居然是中文的类，苦逼的后端能怎么办，只能加上异常检测，实在不行还得反射找属性名，费心费力还严重影响性能
PS：如果这种水平如果还是负责人，又极度听不进意见的话，建议还是别去吵了，尽早跳槽更实际吧

Redis 不是要尽量避免 bigkey 的吗，还专门存 Redis ？

继承过户成本最低，不急的话公示三个月，就几十块印花税，急的话继承公证也要一两万
当然一般不会正好碰到继承，直系亲属过户也只能走买卖，实测亲母子之间走买卖过户，如果价格太低也会被要求核定，这个房管局不管，由同在政务中心的税务局核定，而且不同区域房产底价税务局不公开
当然也可以选择赠予过户，那后续再出手很大概率要交 20%个税，各地政策不同，建议去政务中心问清楚
如果只是直系亲属之间只是求个保障的话，两人签个房价等额的借款合同，然后用房产证做抵押登记，登记费几百块，求保险的话可以先过户个最低份额 1%到 5%，这样房产既单人无法过户也私下抵押也影响不大(抵押登记优先受偿)，然后慢慢等继承

keepass2 + 直接存储在坚果云免费的 webdav 上

@junkk Go 只是木有类似 Django 、spring 全家桶之类前后端一把梭的框架，但就开发个后台 api ，一般就是十几个接收 http 请求再返回纯 json 的接口，整个项目随便用什么语言开发都不过几百行代码，用大而全的框架，绝大多数功能用不着还严重影响性能，随便配置下框架可能都不止这点代码
而 Go 都是精简框架，只提供了基础的路由、响应、中间件等，很适合 api 开发啊，比如 fiber 之类，因为用了 fasthttp 非常适合密集的小请求，比如物联网设备，偶 2 核 8G 的云服务器支持近 60 万设备几分钟定时上报存时序，外加十几处大屏缓存显示，QPS 平均 2 万高峰期过 5 万服务器还空得很，换 spring 全家桶的话服务器预算加个 0 估计都悬
当然如果预计 QPS 不过千又不需要保密源码的 API 服务，FastAPI 一把梭就是了

大多数梯子都不太稳定，偶尔需要手动操作换源。建议还是装个旁路由，单独指定需要外网的设备走旁路由
新手最便宜的方法是买个 t1 、n1 之类的盒子刷旁路由固件，足够用了，nas 虚拟机或找个能刷 iStoreOS 的盒子，iStoreOS 向导自带旁路由模式，设置方便

看标题还以为是嵌入式硬件，那弄块合宙 9.9 包邮的 esp32c3 开发板，新手自己看 arduino 入门再转 idf
没想到是 BIOS 开发，建议如果前端耽误了学习进度，都很难靠自学跟上的话，BIOS 就算了吧，两者差距跟小学二年级直接考高数差不多

单纯写 API 的话，偶最初选的 Python FastAPI ，专业写 API 的框架，确实自动类型验证和生成接口文档方便不少，但实测性能实在孱弱，同配置下都是异步读写 Redis ，FastAPI 压测 QPS 仅 4 千，而 Go Fiber QPS 有 5 万，而且不少库比如 TDengine 官方 Python 连接器不支持异步，性能更差
果断中途换 Go Fiber ，大项目新手可能会学很久，但如果只写 API 也就接收几个参数，读写下缓存和数据库再返回 JSON 而已，Go 新手熟悉下文档三天内肯定能写 API ，压测性能爆表，实测 Fiber 代码量也没比 FastAPI 大多少，就是 err 处理繁琐点，没选 gin 是因为据说路由不好用

现在西数企业级的 SN640 7.68T 也才 1K5 出头吧，国行 5 年保，写入寿命无敌，就是速度慢点
达墨 16T 2K 左右很奇怪咩？再贵的话难卖吧

呃，居然被当成疑似内部人士了，别太敏感，偶只是路过吃瓜码农
只是正好最近接触过类似援助，都是劳动者先申请仲裁但不给材料，仲裁委会先通知补正，继续不理的话就会因通知补正仍不齐备下达不予受理裁定，拿着这份裁定就能直接诉讼了，大概 7~10 天吧，不用耗 2 个月，不少律所都这么干
另外，就算审判长同意因涉及个人隐私不公开，但案件基础信息比如原被告姓名和案由还是会上传的，只是裁判文书内容一栏显示为不公开，去裁判文书网搜索下名字，名下有案件的案由是劳动争议，基本就懂了，你可以去裁判文书网自己看看，这种涉及隐私不公开的案子离婚纠纷和抚养纠纷里比较多，虽然正文隐藏但名字和案由都能看到的
PS：至于偶说“如果不占理还闹大了”，个人认为仲裁无法调解闹到法庭就算闹大了，实务中很多都是劳动者的诉求合法但不合情理，用人单位捏着鼻子认栽再回去找法务补漏，当然也有用人单位自己作死的，反正闹到法院大概率都是劳动者赢，祝你成功吧

本地律所接劳动仲裁，一般都是仅提交仲裁但不给材料，这样很快就会因材料不全被驳回，然后走诉讼，一般耗时一周左右，用不着 60 天
诉讼确实可以主动向审判长要求不公开直播审理，文书也不提交裁判文书网，但审判长不一定会同意，毕竟用人单位大概率会反对
而且就是文书不公开也防不了背调吧，从社保记录里找到上几家单位打电话一问不就曝光了，虽然仲裁记录不可查，但如果不占理还闹大了大概率瞒不住吧