libook

https://www.guokr.com/article/437642

个人认为人体对环境的适应能力是非常强大的，所以建议把重点放在已经被证实为与儿童成长有关的主要因素上。

建议做 DevOps 或者 SRE，目前还是比较有发展前景的，关键跟你原有的方向多少有些相近，转开发除非是通信领域的产品开发，否则以前的经验都打水漂了。

做开发也不一定有成就感，之前经常看到 V 站里有后端开发抱怨日常工作都是重复数据库的 CRUD，实际上这也是大多数后端开发工作的现状。

多数前端开发除了乏味的 UI 交互以外就是折腾样式，做 IE 适配非常酸爽。

其实对工作的感受很多都来源于自己对待工作的心态。比如很多人觉得做 IT 支持工作很乏味；但如果做 IT 支持的可以开发工具大幅度提升工作效率，以往 1 个 IT 只能 hold 住 20 个员工的支持需求，现在能 hold 住 200 人甚至更多；这多少还是比较能鼓舞人的。

内存用多少关键还是要看运行的软件，所以了解都有哪些软件在运行，然后逐个优化，关闭不用的软件，用耗内存少的软件调换内存大户。

要说硬件内存少的话，树莓派就很少，官方的 Raspbian 有 x86 版的，可以试试。

@claymore94
Lastpass 也不是每次都需要使用主密码，如果用户愿意信任设备环境，用降低安全性来换取提升便利性也是可以的，比如本地缓存主密码，然后使用环境提供的其他可靠机制来控制主密码缓存的使用，像浏览器扩展运行的沙盒环境、手机系统提供的手势密码、指纹、虹膜、人脸识别等，环境厂商会负责保障这些的安全性，如果用户信任这些的话，可以让用户自愿选择将主密码缓存至本地，这样就不需要每次输入主密码了。但换设备就一定得输入主密码了，毕竟新设备本地没有缓存。
安卓系统上的手势解锁的安全性主要不是在于位数，而是在于本身是封闭的，输入手势和解密是一起哈成的，用户不可能绕过输入手势的环节直接输入手势的每一位对应的代码来暴力破解（假设没有程序失误），但如果输入手势和解密是两个独立阶段且对外暴露的话，就肯定会产生暴力破解的风险；这么讲可能过于抽象，我举个例子吧，我们日常生活中的锁，之所以具备较好的安全性，主要是因为锁外面的一层厚厚的铁壳，使得锁内部的机械成为一个封闭系统，如果它是开放的、可以任意操作里面的机械，那么安全性就肯定下降了很多。另外手势解锁的封闭系统内也有超过错误次数上限就禁止尝试这种机制，同样也是无法绕过的（假设没有程序失误）。

其实并没有泼冷水的意思，只是发现了一些问题，不希望楼主因为这些问题而造成损失，所以就及时提出来了。
有极客精神是非常可贵的，也希望楼主不要有负能量。
不过任何产品都是需要不断打磨不断迭代的，我相信很多人也都是希望自己提供的建议能够被采纳于改进产品，知识不足可以学，设计不完善可以再慢慢琢磨。

一直在用 Lastpass，感觉完全满足需求。

云安全的关键点在于加解密都在本地进行，让云端没有任何解密能力。

基本思路就是用用户提供的主密码，做不可逆的 Hash 运算，使用生成的 Hash 串以固定算法生成对称加密秘钥，然后对整个密码库进行加密，再上传云端。

这时候即便云端有解密算法，但没有用户的主密码做为引子是无法解密的。

解密的时候从云端拉取加密过的密码库，用户输入主密码，做不可逆的 Hash 运算，再用同样的固定算法生成对称加密秘钥，用对称加密的解密算法把密码库解密，取出密码。

这个应该可以解决云安全的问题，但还有很多其他安全问题需要解决，比如本地安全问题、钓鱼。

Hash 步骤可有可无，加上可以某种程度上提高安全等级（因为 Hash 串通常都比主密码长很多，增加暴力破解难度，即便暴力破解了也不知道主密码是什么，避免撞库）。

还要考虑多种解密方式，因为主密码可能会忘记，不清楚 Lastpass 是如何实现的，一种思路是把主密码 Hash 生成的对称秘钥导出来，让用户在安全的地方妥善保存，一旦用户忘记了主密码，就直接使用秘钥来解密密码库+改密码。

其他的就是便利性，商业的密码管理工具都是提供跨平台密码输入工具的，有的还提供团队共享密码的机制。

最后：
不要自己造加密算法！
不要自己造加密算法！
不要自己造加密算法！

除非你自己是个密码学博士，发的 Paper 经过几家顶级安全实验室验证 OK~

开发的时候静态资源直接放 Nginx 吧，企业级线上方案都是用 CDN，用 Node.js 来 host 静态文件性价比太低。

要是只想写写 Web API 找个最简便的框架，Koa 是最合适的，Static 已经跟 Web API 关系不太大了；但不管用什么技术都得了解内部原理，就像以前经常有人拿 C#当 Java 用，就感到处处碰壁。

或者自己拿 Node.js 的原生 http 模块写 API 其实也挺快的，只需要看看 API 文档以及了解一下 Stream 就行了。

容器内用不用 pm2 看具体需求是什么，只是想启动的话确实没啥必要，但如果想用 pm2 现成的的日志机制、重启机制、Cluster 模式甚至 APM，也完全可以用呀。

个人感觉一般情况下对于 Node 技术栈来说在公有云上用容器和虚拟机的区别不大，本身部署就是 0 配置已经非常方便了，拉代码、装包、pm2 启动，就看哪个便宜。
除非严重依赖基于容器的 DevOps 以及 K8s 之类的集群方案。

像 Java Web 之类的可能对环境配置要求比较高的就非常适合用容器，做到开发、测试、上线环境统一。

欢迎～

这条是在 Arch Linux 环境中回复的。

Arch 大杀器 AUR，比 PPA 更丰富。
系统挂了用 U 盘进 arch-chroot，只要是软件问题都马上有解决的能力了（当然，肯定是得折腾一番）。
有问题上 Arch Wiki，在其他 Linux 发行版上有问题这个 Wiki 也能发挥很大作用（毕竟都是一样的 kernel ）。

用了 5 年+，挂过 2 次，主要滚动升级不会有大版本停止维护的问题。
个人的经验是能不开 multilib 就不开，特别必要建议容器或虚拟机，因为开了之后各个软件包之间的依赖关系会变复杂，想关上可能就比较困难了。
然后能用官方软件包尽量用官方的，不行的话尽量用 AUR 的，再不行的话尽量用 PKGBUILD ；尽量不要直接 make install。
最后积极学习 Linux 系统以及常用软件的概念、机制和用法。

只是看文档和图片的话，平板电脑很方便，续航还好，在工地之类的环境复杂的地方故障率比普通非三防笔记本要低一些，而且续航要好的多，实在没电了也能很方便解决。