法律上都没问题，这个其实主要是夫妻双方协商以及如何与双方直系亲属达成共识的问题。

大家都觉得 OK，就这么办，觉得不 OK 就修改一下方案，和生意谈合同是一样的，看自己和对方有多少筹码，如果谈不拢顶多这个生意不做了。

至于能不能争取到什么，就看自己谈判的技术如何了。

正所谓清官难断家务事。

见人说人话，见鬼说鬼话。分析你所投递的岗位招聘方的需求是什么，然后再着重在简历里体现相关的内容。

如果是海投，就都写一写，可以适当参考 STAR 法则，让招聘方了解你能给企业带来什么。

重建速度和硬盘大小、读写速度、阵列程序处理速度都有关系，比如 1T 的机械硬盘重建数据应该也用不了多少时间，但是如果是 12T 的硬盘，可能就得需要几天的时间。

我自己组了 NAS，做了一些 RAID 的调研，RAID5 是一块以上硬盘损坏就丢失数据，翻车主要在于：
1. 同一生产批次的硬盘寿命往往非常相近，坏的时间点也可能非常相近，1 块盘坏了换新盘重建完成之前另一块盘坏的概率较高。
2. 一旦有一块盘坏了，就处于没有任何保障如履薄冰的状态，重建时间长的情况下（比如大容量重建好几天），其他盘有可能在重建过程中达到寿命极限坏掉，特别和第一条配合效果极佳。
3. （待证实）在冷数据长期不读写又没有闲时校验机制的情况下，可能有些数据已经损坏了，只不过没有读到这里没有发现，一旦发现有数据损坏的时候，其实已经有了多处损坏，这些损坏的地方会在重建的时候暴露出来。

所以如果数据真的很重要的话，建议上 RAID6，或 RAIDZ2 。当然多组几套小容量的阵列也是可以考虑的，大幅缩短重建时间可以让翻车概率大幅减低，而且每套阵列之间互相故障隔离。
如果数据重要性一般，但不希望坏了多块盘上的数据就难以恢复，可以参考一些快照方案，比如 SnapRAID 。
如果以读速度为主要需求的话，就无所谓了。

我自己是 4 块盘采用 SnapRAID，3 块数据 1 块校验（可以自定义的），由于数据还是按照正常使用 3 块硬盘的方式存储的，所以 1 个文件只会在 1 块硬盘上，数据损坏也只是损坏相连的几个文件，其他文件可以正常读取，1 块校验盘的配置允许像 RAID5 一样 4 块里任何一块被替换成新盘可以直接重建。缺点是校验数据是非实时生成的，需要手动或用定时脚本触发校验数据的更新（这时候有个好处就是如果在更新校验数据之前误删了数据，SnapRAID 支持单文件恢复可以很方便还原回来），且因为像直接用 3 块硬盘一样，所以没有读写速度上的提升。不过我个人就是存一些照片、家庭录像、电影的数据，读写频率可以接受一天一更新校验数据，机械硬盘的读写速率对我来说也能满足需求。
为了找文件不用频繁在 3 块硬盘里切换，我用了 MergerFS，可以用软件的形式把 3 块硬盘的目录树重叠在一起，虚拟成 1 块硬盘，和 LVM 的区别在于其层级位于文件系统之上，3 块硬盘依然可以独立挂载、独立访问且与虚拟出来的 1 块磁盘的访问兼容。

最后有一些建议：
1. 组阵列最好不要用同一批次的盘，可以隔一段时间买一块，或者买同一批次的盘，提前间隔较长时间买新盘替换下来，避免一起坏。
2. 定期做全套的 S.M.A.R.T.检查，以便及时发现问题。
3. 注意叠瓦盘和非叠瓦盘可能不能混在一起用于实时 RAID 方案。

换个大夫，或换家医院？

说真的，关系到身体健康的事情，还是咨询专业医生吧。

现在云计算可以在虚拟机级别实现弹性伸缩、快照、负载均衡、监控等技术，如果没有硬需求上 CI/CD 、K8s 的话，其实完全可以连容器都不用。

1. 理论上只要你的服务器在别人那，别人就有能力看你的数据，不管是不是 serverless，除非你只上传字节码或混淆代码，这样拿到也看不懂。
2. 不管是物理机独占、虚拟机、容器还是 Serverless （当然容器也可以包装成 Serverless ），都得按需求选择，不能说现在 Serverless 很火热就把所有系统迁移到 Serverless，任何模式都有其适用和不适用的情况。

阿里的任何轮子都不推荐，除非是送给社区驱动且目前活跃的。

@stoneabc 这里的关系主要是因为算法差异吧，如果是一模一样的算法，除非引入模拟信号，否则不会有差异吧。

补充一下，很多视频转码软件对 GPU 的利用非常有限，很多都是完全依赖 CPU 来做转码的，用上了 GPU 也仅仅是借用部分功能来适当提升性能。

如果你的软件能利用硬件编码、解码器的话，不出意外的话是新出的硬件会好，相比于旧硬件做了优化以及修复缺陷，硬件编码、解码器通常因为算法固化在硬件上了所以通常无法通过打补丁的方式改进。

我司的产品主要就是视频，压片常年就是 FFMPEG+i7 4790k，没有用任何 GPU 。选型这方面理论只是给你一个大概的方向，实际还是得看文档、问开发者、做压测。

画质和转码参数有关，和用什么硬件没关系。

要选择什么硬件搭配，要看你压片用的软件用了哪些硬件的接口，这方面去问软件的开发者，或者看官方文档就行了。

看了很多分析，纠结了几个月，论据都是猜，没有逻辑学上周密的因果关系。

中国的经济非常具有中国特色，虽将跻身于发达国家，但并不与资本主义国家完全相同，所以很多人参考现有发达国家的利率来解读中国的 LPR，我个人觉得不靠谱。

任选就好了，然后走一步看一步吧，毕竟政策也随时在变。

自从一年前发现 Firefox Android 端可以装 Extension 以后，就完全从 Chrome 切到 Firefox 了。

个人感受是 Chrome 总是强迫用户接受他们的设计，当然总想着培养用户习惯也没什么不好的，只是不满足现阶段个人的需求而已。

Google 也是鸡贼，把一些产品功能在 Chrome 上独占，比如 Google 搜索页在 Chrome 上展示的功能就比 Firefox 多，以及 Google Translate 相关 Extension 对非 Chrome 浏览器的支持很难。

补充一点：
5. 没有什么是一成不变的，随着业务、技术、团队情况等等的变迁，标准可能需要修订。标准一旦实施就得 100%遵守，但是允许对标准有疑议，对新人来说可以出个标准的 FAQ，对老人来说随时可以拉会重新讨论标准。

分情况。

1. 要依照具体情况制定标准。举个例子，代码缩进，后端代码逻辑复杂，且每一行不会太长（很多语言长语句拆成多行阅读更清晰），强化视觉层级可以加强代码可读性，所以可以考虑缩进四个空格；前端 HTML 代码可能因为标签属性较多，每一行都会很长，所以为了尽量避免折行，可以考虑缩进 2 个空格，甚至 1 个。（当然，可以换成 Tab ）
2. 制定标准要有理有据，不能作为信仰开圣战，也不要盲从大公司、大牛、著名项目。比如有的人见过 StandardJS （注意这个不是 JS 官方标准）之后就唾弃一切在末尾加分号的行为，但忽略了之所以可以不加分号是因为有 StandardJS 的 Linter 在排雷，没有 Linter 的时候盲目省略分号基本上就是作死（从不失手的肉体解释器除外）。
3. 如果是多人协作的项目，要以团队为重，个人让步，Leader 负责把控标准对于项目整体和未来发展的适用性。只要没有明显的风险其实都可以尝试接受。
4. 能用工具限制的事情，尽量不要靠自觉。一来可以使得团队和睦，免去扯皮；二来可以提高效率。各自语言的 Linter 、.gitignore 、editorconfig 、commitlint

再说说管理上的，个人建议就事论事，有问题解决问题，没必要带入情绪（当然做到这个很难）。
其实通常出现情绪主要还是因为举手无措，由一个问题反复解决但是最终仍然复发而导致的懊恼；可以尝试加一些轻的奖惩机制，比如 6 人的团队，谁出现一次不符合标准的情况就请大家伙下午茶，这样惩罚不重，但也始终有个惩罚在那时刻提醒大家要遵循标准。

@nobody123123 可以联系 JetBrains 的客服说一下这个情况，没准他们可以操作一下让你享受这个折扣，毕竟他们也是希望你续费以及换成年度付费计划的。

我之前想 WebStorm 转 IntelliJ Ultimate，自己操作只能从原价开始新买 IntelliJ Ultimate，后来找客服，客服非常爽快地帮我把 WebStorm 剩余时间转化成了优惠金额放到了 IntelliJ Ultimate 订单里，而且还直接享受两年以上的 7 折优惠，我只需要补差价就行了。

堡垒机记录所有人工操作，那么不管你是登录到云主机还是容器环境内都是通过堡垒机做跳板的，堡垒机会记录所有操作。

现阶段等保只会以物理机或虚拟客户机作为一般意义上的服务器，可以不认为容器内部环境为服务器，当然这个在你上报设备信息的时候就得这么去分类。

K8s 产生的日志、K8s 的管理控制台操作日志，以及容器产生的日志，都要存档、异地备份、保存 180 天以上。

@CBS 哎呀，跟人打交道与情商上长期累积的经验有关，跟人说人话、跟鬼说鬼话，不是一套统一话术就能摆平所有人的。

要是你打算和同事沟通且没有头绪的话，可以从一个基本的三步法来开始：
1. 我想了解或已经十分了解你的情况和需求是什么样的。
2. 我的情况和需求是什么样的。
3. 咱们看看能不能找到一个双方都能接受的平衡点。

我觉得其他楼已经提供了很多思路了，要是自己还是搞不定的话可以求助于情商高或领导力比较强的同事来帮忙协调，不论是一对一商量还是开个小会大家一起商量，只要最终能达成一个大家都能接受的共识就行，毕竟空调是死的，人是活的。