OKR 需要员工自己制定，但制定完成后需要上级审批，一经审批就表明上级签字画押不可否认了。

复盘的时候需要对 OKR 的合理性进行诊断，如果认定不合理，那么审批通过的领导也有责任的。

每个案件都是独一无二的，不能因为一个案件的判决结果而导致以后所有类似案件都是完全一样的判决结果，需要就事论事。

这也是法庭存在的意义，因为事情是复杂的，法条是概括的，所以这其中的灵活性就由法庭来体现，通过举证、辩论，以及对法条思想的解释和扩展，再进行研判。

这方面属于民事诉讼的范畴，很多时候合同、协议更起决定性作用，除非合同、协议条款本身属于法律明确规定违法的行为。实际上一些单位在于雇员签订劳动合、保密协议、竞业协议的时候，会有知识产权相应的条款。比如规定在职期间无论是不是工作时间，员工的任何发明创造和著作都由公司所有，并且需要让员工自己在劳动合同上写明自己已有的发明创造和著作列表，以明确被排除在外。如果明确有这些条款的存在，在其本身不受法律明令禁止的情况下，出现员工非工作时间创作的作品的产权纠纷，单位可能就占有显著优势了。所以签合同、协议以前需要仔细阅读条款。

在用人单位的角度上，也可能存在不同的态度，是仅仅出于防御性目的避免被员工坑，还是想有朝一日能耍流氓捞一笔，而且还存在被收购清点的情况。

其实作为员工，需要有意识避嫌，比如创作前可以先评估一下是否与自己的工作单位有利益冲突，以及可以考虑把产权交接给信任的他人或社区组织，最重要的就是让用人单位没有起诉的意愿，毕竟欲加之罪何患无辞，知识产权也只是众多法律武器中的一种而已。

我在 Windows 上用 Cygwin 装 XServer ，然后在 WSL2 里装 IntelliJ ，可以直接投到 Windows 的 XServer 上，使用起来跟直接在 Windows 上跑 IntelliJ 一样。

WSL 内尽量使用自己的文件系统，建议仅在需要文件传输的时候才在 WSL 内部访问 Windows 的文件系统，以避免一些兼容性和 hook 问题。

有需求就有市场，市场选择就是车前进的方向。

试想这样一个场景：
一个团队用 React 做了一个网站；
后来发现移动端的流量更高，于是就适配了移动设备；
然后发现基于应用商店的运营策略可以带来更多流量，于是想做 APP ，所以用 WebView 做了个 APP 壳，然后内嵌自己的网站；
后来用户反馈在一些复杂页面很卡（当时手机机能还没现在这么强），同时产品经理希望增加一些现有 Web API 不支持的功能。

作为 CTO ，有如下选择：
1. 保留现有 Web 开发人力开发 Web 端以外，额外招聘同等产能的 Android 和 iOS 开发人员，以原生方案重写，开发人员预算增加 1-2 倍；
2. 让所有前端开发人员去学 Dart 和 Flutter ，招聘具备 Flutter 开发经验的人员补足离职空缺的岗位，原有代码推翻重写，缺轮子找替代品或自己造，不过 APP 性能可以改善不少；
3. 试一下 RN ，原有代码可以得到最大限度复用，开发人员只需要了解一下 RN 的使用方法，还能改善 APP 性能。

当然，最终什么方案适合，得经过深入调研和试验才能得出结论，比如也有可能 RN 与原有架构设计方面不兼容，那就可以考虑是不是还要继续走这条路。

Microsoft Remote Desktop ，微软官方的 RDP 客户端。

我家里的宽带有公网 IP ，华硕路由自带 DDNS 和 OpenVPN ，我就是从公司连 OpenVPN ，然后直接用 RDP 连 Windows 。

其实方案适不适合得看你的具体情况和需求。

现在的电脑都会有静电保护功能，有静电的时候不启动，解决办法就是断电，然后按住开机键几秒钟，此时会释放里面的静电，再通电，就可以开机了。

我遇到大多情况都是因为这个，如果靠这个办法解决不了，也有可能是开机键老化了，如果机箱有重启(reset)键的话，你可以尝试把电源和重启键的线交换插一下，然后用重启键来开机，如果明显好用了，可能就是开机键长时间使用后磨损得接触不好了。

排版是技术活，不管有没有首行缩进，只要让我看得舒服我就能接受。

我猜题主想说的是”推荐“。

关注功能更多是以用户为主导的，而推荐功能更多是以平台为主导的，社交平台上没有关注功能不会导致流量经济的破灭，因为流量只是个中间关节，最终目的还是把流量变现，比如把所有关注功能都移除，但每天被平台推荐的号，依然能有很强的带货能力，甚至因为没有了关注功能可以直接抹杀那些不符合平台推荐策略或不买推荐位的号，导致平台进一步垄断这个市场。

人们通常会使用关注数量来对一个号的信誉、内容质量等进行预测，也就是说人们通常会相信关注数量越高的号就越好，至少大多情况下是这样的，否则不会形成这样的意识。
但就有些人会利用这一点来作弊，刷关注量来提高人们的预期，来获得人们进一步了解的机会。
这个就好要分开看了，关注功能本身是没有错的，有错的是作弊行为，整治的重点也应该是这些作弊行为。

我游戏电脑放卧室里，晚上睡觉开着会吵，扔别的屋子里就没法在卧室里打游戏。

我以前有台 NAS ，扔别的屋子里，除了做文件存储以外，还跑了一大堆东西，可能配置不够高，或者限制没做好，会互相抢性能，比如跑了个 AI 程序之后，文件存储功能也卡得没法用了。还有，姑且不说压制 Windows 的自动重启更新需要好一番折腾，不知道是不是因为没有用 ECC 内存，还是说非 Server 版 Windows 是不是在稳定性上有啥缺陷，跑时间长了就会遇到莫名其妙的问题，通常重启能解决。

后来我就想性能、故障隔离，当然也跟我的用途需求有关，我决定专机专用，NAS 就老老实实干存储的活、软路由就老老实实干网络的活、服务主机就老老实实跑服务，哪个有问题就收拾哪个，不需要一停全停。

当然，每个人每个时期的需求都是有区别的，而且不同的需求和问题的优先级都是因人而异的，有可能我不能接受的你可以接受，或者你不能接受的我能接受，我只能说拿 PC 跑 NAS 肯定是可以跑的，就看是不是符合你的需要。

@MEIyiyi #4 file 协议？也就是说用浏览器自带的 PDF 阅读器打开本地的 PDF 文件？你想用 JS 控制的话是打算把 JS 写在哪呢？

软 RAID-1 是 RAID 方案，ZFS 是文件系统方案，这俩不是一个维度上的问题；比如 ZFS 也有 RAID-Z0 、RAID-Z1 、RAID-Z2 、RAID-Z3 ，如果你换了 ZFS 却用的是 RAID-Z0 ，那还不如以前的软 RAID-1 可靠。

我重度使用过 Ext4 和 Btrfs ，ZFS 据我的了解就是提供了一些性能优化和快照之类的实用特性，服务器用的主流文件系统可靠性都差不多，实际上存储可靠性方面文件系统是很低优先级去考虑的，更高优先级是：
1. 机房所在整个地区电力或网络故障了怎么办；
2. 整个机房故障了怎么办；
3. 整台服务器故障了怎么办；
4. 整块硬盘故障了怎么办。

前面那些问题解决了之后，基本就解决了 99%的可靠性问题。

我有一块 U 盘这么写废过。

U 盘是基于低频读写的场景设计的，每次写入都会减少一些寿命，等写废了 U 盘会进入保护模式，只允许读不允许写。

后来我的策略是找到所有写日志的程序，把日志分为三个等级：
1. 平时不看，有故障可以临时记录日志再看有啥问题；这种日志可以直接关闭；
2. 需要看日志的时候系统正常工作，而且仅需要看短时间范围内的日志；把日志路径改到 /tmp 下（或任何挂载到内存的目录下），并设置 logrotate 限制日志文件大小和时间，防止把内存写满；
3. 出问题的时候系统会不可访问，或者需要翻旧账；这种先用 folder2ram ，先写入内存再择机自动写入 U 盘，以此降低写入频率，并配置 logrotate 限制日志文件大小和时间，防止把 U 盘写满。

前几年夏天基本上大多时间都是开空调的，我开空调的时候会关闭门窗，且空调匹数适合我的房屋空间大小，个人认为家用空调在这种负载下连续工作问题不大，室温降到设定温度后空调制冷功能就会暂停，1 级能耗的话一天大概 2 度电左右。

有的人对空气新鲜程度比较敏感，需要用新风机或每隔一段时间打开窗户通风。

用过很长时间的 LastPass ，后来安全事故、涨价、境外服务墙内访问不可靠、客户端问题多（不知道现在是不是好些了），就换了 vaultwarden 服务端+Bitwarden 客户端（ Android 、Firefox 、Chrome 、CLI ），部署在自己的 NAS 上，定期备份到网盘。

NAS 是用 DDNS+VPN 来从外网访问的，联通家庭宽带，本来手机和笔记本电脑就是 7x24 小时出国的，所以就从家里做了个出国中转，然后添加路由规则让部分域转发给家庭网络内的服务，这样在外只需要连家里的中转服务器即可同时做到出国、访问家里服务、避免违反运营商私开 Web 端口的政策、避免公网针对 Web 服务的攻击。
目前这套方案已经稳定运转三年。绝大多时候是可访问的；而且因为客户端有缓存，也能顶得住短时间的不可访问的情况；极端情况下我还能回家直接接触硬件访问数据；遭遇天灾人祸还有网盘备份可以恢复。

经过严格的测试和校验之后，理论上不应该出现修改部分字段全量提交却让未修改的字段的值变化，这个问题不处理妥当，局部提交也会有问题。

顶多会出现因字段太多，用户操作的时候手误碰到了不想改的字段，然后就提交写入了，这个得产品经理和 UE 去优化的。

如果代码很长，提前返回可能不利于可读性；甚至建议除非有必要不写 else ，有 if 必有 else ，这样能规避一些逻辑盲区的 bug ，让任何情况都有所处理。

当然代码风格没有完全之策，最好是在每个项目的迭代过程中进行归纳整理，然后沉淀为 lint 规则。

@balduncle #28 那就无所谓了，这东西硬件门槛低，只要硬件本身没缺陷，基本就能跑，而且自用不像企业压力那么大，软件上不瞎折腾应该都比较稳。

大多情况下千兆网口应该够了，毕竟你用机械硬盘的话速度瓶颈在硬盘上。

为了省电，专门的 NAS 设备性能都比较弱，但做 NAS 本职工作绰绰有余了；相应的，用来跑其他东西可能会明显感觉性能不足，这个得有个预期。

家庭影音有两种方案，一种是播放机解码，NAS 仅传数据给电视、投影仪、电脑、手机，然后这些设备上解码；另一种是在 NAS 上转码，比如支持一些流式播放不友好的格式，或者可以根据网络情况动态调整分辨率、码率。
前者不需要啥计算量，后者对 CPU 、显卡有一定要求，具体可以看你用的工具的官方文档，比如 Plex 官方就有不同应用场景的硬件要求说明。

硬盘如果对静音有要求就用 NAS 专用盘，对静音没要求可以考虑企业级硬盘；心里有底想便宜的话也可以考虑监控盘。
用实时 RAID 、对写入性能有要求的话建议避免叠瓦盘；如果数据较冷就无所谓了，叠瓦盘还便宜一些。

同一生产批次的硬盘寿命相近，有可能的话尽量不要用同一批次的组阵列；
硬盘空间大的话，故障恢复时间也会更长，建议考虑 2 块冗余盘的方案，如 RAID-6 、RAID-Z2 。