@
starxg 那个《柒个我》名字错了，这个是中国版的剧，一样的剧本，韩版的叫《杀了我治愈我》
这剧不错，男一男二互动嗑得很开心。
韩国有好几个鬼怪题材的都很不错，《哦我的鬼神大人》《你好再见，妈妈！》
另外还有几个非鬼怪的，但比较魔幻的，比如《 W 两个世界》《柒个我》
我前几天遇到了这个问题，根据 Google 的官方的文档，进入 Play Store 的应用程序信息界面，然后清除数据，重新启动就好了。
印象里 RDP 和 VNC 都是不保证传输安全的，需要靠额外的安全传输通道来保证传输安全，比如 SSL/TLS 、SSH 、安全 VPN 。
安全都是相对的，采用什么程度的安全措施取决于你能接受多高的风险。
比如你相信内网是安全的，不会有蹭网者或者通过其他方式入侵到内网的人或程序搞事情，那么你完全可以在内网裸奔，比如全都明文传输，甚至都不设置密码。
理论上来说，你用安全 VPN 或 SSH 两者之一就能具备较好的传输安全，当然嵌套越多安全性也就越高，但相应的性能和维护成本可能就会成为主要问题。
干哪行都不容易。
软件开发行业的竞争可能比财务要激烈很多，那么问题来了，你打算如何在这个竞争十分激烈的行业中立足？没有破釜沉舟的觉悟的话应该也做不久。
不过作为业余爱好还挺好的，可以学个 Python 、JS 之类的，平时处理个数据、算个公式啥的还挺方便的。
买啥戏机取决于想玩什么游戏。有的游戏 PS4 不能玩，有些游戏 Switch 不能玩。所以先看看游戏，想玩啥，然后再看什么主机能玩。
越简单的语言对开发者要求越高，比如 C 、JavaScript，稍不注意就可能写出有缺陷的代码，而且这些代码中大部分是可以运行的。
可以去 benchmarksgame 看看 Rust 的压测表现，性能和 C/C++相当，到这种程度又要规避很多 C/C++常见的开发痛点，于是就设计出了一些复杂的开发模式，以至于让 Rust 的学习曲线变得陡峭。
可能习惯了就好了，特别是现在还带着很多其他语言的思维定式，比如 Rust 里的 Ownership 和 C 里的指针操作乍一看长得差不多，但实际上是完全不同的理念。
当然看代码看不懂也不一定是自己的问题，代码是有可读性好坏之分的。
作为一个大学英语四级都没过的人，原版 Book 已经看了一半了，打算看完后再看 Rust by Example，以及去 GitHub 上找找 coreutils_rs 之类的简单项目看看。
每个人对团队氛围的要求是不一样的。
很多人都不喜欢被束缚，尤其是我，所以我通常是不会用 eslint 的。
首先要明确一点：JS 是一门极其灵活的语言，一个需求可以用超多种方案来实现，但并不是所有方案都没有隐患，所以对开发者的要求很高，开发者需要有大量的经验以及良好的习惯来规避各种各样的隐患。
于是在团队协作的项目中，你会发现因为每个成员的水平不一样，并不都能驾驭好各种各样的骚操作，以及不同的编码风格可能会导致整体代码的可读性较差；
当代码问题成为阻碍产能的重要问题的时候，就需要工具来辅助：Linter
接下来是另一个共识：工具是用来解决问题的，不是用来制造问题的。
那么如何利用 ESLint 来解决团队已经遇到的问题，同时又不产生更多问题，这个不同的 Leader 可能会有不同的策略。
我的策略是做加法，即为先关闭所有规则，然后把实际代码中的问题搬到 Codereview 会上然后让团队一致同意添加相应的 lint 规则。
我会对规则进行分类：
1. 一定或在绝大多数情况下都会导致缺陷的写法。
2. 虽然不会导致缺陷，但是会较明显地影响代码的可读性。
添加每一种规则的时候，要记录有问题的代码案例，以及为什么添加这一条规则，这样新入职的员工可以参考。
最后就是，这些规则都不是一成不变的，如果随着变化使得某一条规则不再适用，可以随时讨论修改或去掉它。
没有物理隔离就没法谈安全。
所以最最最最底线是要保证你的终端设备是安全的，否则你不用 pin 用长的主密码也照样会被窃取，再加上目前主流的密码管理工具都是本地加解密模式，说不定偷解密的密码库比偷秘钥还简单。
上面分享 Windows Hello 的文章跟楼主讨论的问题其实并不是毫无关系，主要是介绍了一下 pin 的安全性思想，这个在任何产品上都是通用的，即是：pin 机制的安全性是建立在诸多限制和安全策略的前提之上的，因为有相对合理的安全性，所以可以用在一些场景中。
所以正面回答楼主的提问的话，破坏了保证 pin 机制的限制和安全策略之后，显而易见 pin 的安全性大打折扣，但与此同时，主密码的安全性也损失不少。
如果不放心，可以牺牲一些便利性换取更多的安全性；毕竟，
安全都是相对的。
人们习惯上认为 nightly 适合测试尝鲜、stable 适合生产，但其实不同的项目会因为流程、质控等差异而体现出不同的稳定性。
Rust 设计哲学之一就是可靠，所以用 Rust 写的程序可能不需要花多大功夫就能天生比 C/C++可靠很多。
另一方面生产肯定还要结合合理的开发管理制度、流程以及严格的测试来确保最终交付的质量符合预期。
任何技术选型都是要评定风险的，所以建议跟社区实际了解 Rust 的 nightly 版本的可靠性表现，然后作为风险因素来权衡选型；比如生产项目对可靠性要求极高，而 Rust 本身语言带来的可靠性综合 nightly 版本带来的不可靠性是项目可接受的，那么就用 nightly，否则就用 stable 或者其他技术选型。
越简单的语言，对开发人员要求越高。
C 很简单，但是经验不足的开发者极其容易写出有缺陷的程序，而且恐怖的是这些程序多半是可以启动运行的。
Rust 的设计目标之一就是能用一些万全策略来规避以往在 C 、C++上遇到的各种问题；如果你觉得解决这些问题并不是你的首要需求，那么你可能并不需要 Rust 。
作为一个大学英语四级都没过的人，Rust 是第一个我完全读英文教材学习的语言。
就单能阅读英文文献这一点，北京也不好招。特别是 Vue 中文文档写得巨完善，导致入门门槛很低。
你可以试试，每个地区每个时期可能情况不一样，没准运气好遇到了呢。
Firefox，我主要是因为 Firefox Nightly 的安卓端可以装扩展。
我基本上就是写 JS，然后加上类型声明啥的，扩展名写 ts——齐活儿。
TS 兼容 JS 的语法，没啥大难度。
TS 不是银弹，项目上有问题可以用 TS 来解决就用 TS，没有啥特别需求的话也没必要强上。
JS 非常灵活，所以对开发者要求很高，经验不够丰富的开发者很容易写出一些有缺陷的代码，TS 可以被用来实现一些开发上的约束，从而规避一些问题。
相应的还有 Go，没有那么灵活，大多需求都有确定的一种方案，所以降低了无意间造成的“骚操作”，减少了问题。
TS 仅会做编译时类型检查，不做运行时的保障，所以对于外源输入数据的情况还是要自己做好类型检查，或者使用一些真·强类型语言。
JS 也不是说就可以扔了，TS 再怎么🐂🍺最终也都是编译成 JS 运行的，精通 JS 可以让你有更强的解决问题的能力。
看需求。
如果希望除污渍和消毒的话，洗面奶可能达不到相关洗手液的效果。
不过不同人体质不同，不同产品在不同人身上的效果可能也有差异，你可以自己尝试一段时间，感受一下。
话说……为什么不用洗手液洗手、用洗面奶洗脸……买多了可以看看保质期估算一下能不能在过期前用光，或者送给亲戚朋友啥的。
现在很多时候都是为了强调连续休息时间所以把周末也算上“放三天假”，但实际上就是只放 1 天，然后就会让人觉得“本来应该是三天假，结果其中两天是征用的我的周末”或者“前面和后面的周末我还要补班，这个假跟没放差不多”。
这其中的问题是先把人的预期拉高，然后又满足不了预期，于是导致失望情绪。
其实应该换种说法，比如就说“放 1 天假，连周末共休息 3 天”或“放假 1 天，加调休连续休息 3 天”，多加半句能让人好受很多。
部好线管，需要啥线日后都可以穿啥线。
装修的时候部署上了，放着不用也没啥影响；如果没有部署，日后突然有需求就会很蛋疼。
如果已经决定部署线管，可以考虑穿光纤，线材比网线便宜，除了设备稍贵以外，速度还快很多。不知道按照网线规格部署的线管是不是能够穿光纤，你可以咨询装修的电工。
你看一下群辉用的什么主板，应该有有头绪了。
我两年前攒了一台，用的迎广 MS04 机箱（四盘位），加华擎的 ITX 尺寸 J4105 板+U （板载 CPU ），再加点内存条，一共花了 1800 。10W 低功耗，支持 4K，x86 架构可以跑 Docker，可以刷黑群辉。对标的是群辉的三千多元价位的家用 Nas，群辉用的是 J3455，我的方案比群辉的性能还要好一些。
双 m.2 这个在 Nas 方案上很少见吧，大多都是 SATA 阵列，如果愿意舍弃这个需求的话 Intel 的 J 系列板载 U 很不错。
Select Language