为每个版本买一台。

在生产环境的服务器上，后台服务类软件强烈不建议装在自己家目录或者 owner 是自己的其它目录里，并且所有文件 owner 也是自己，然后还是用自己登录的账号身份启动到后台。

交互操作的工具一般来说无所谓。

开发环境也不用讲究，但要知道你开发出来的东西将来可能生产环境要求部署。

另外，强烈建议通读多遍 Linux File System Hierarchy Standard 并理解其设计动机和思路。

不怕用户智商低，只怕用户自作聪明。

需要符合规范的数据来源时，只要允许用户自由输入，就一定有（大量）用户自然而然地不按规范操作。
要么事后做数据清洗，要么开发有限制的输入界面。

netdata

openwhisk ?

35 岁找工作会被嫌老，凭什么 26 相亲就不能被嫌大？

供电可以，但不能跨品牌控制。

从 DOS 时代走过来的老人表示除了需要跨系统拷数据的移动存储之外想都不会去想 FAT family FS 。

名人收到好心但不明情况或并没有什么卵用的建议比我们普通人多得多。量变导致质变，你觉得拉黑是很严重的反应，也许以名人的消息接收量，最好的办法还是一拉为净，而不是去逐条消息判断对方的动机和心情。

刑不可知，则威不可测

@bthulu 容器化语境的动态扩容缩容指的是无状态应用增加减少节点，是 scale out ，而 PaaS 语境里传统关系数据库的动态扩容缩容指的是占用硬件资源规格的升降，是 scale up ，两码事的。传统关系数据库并不天然具有 scale out 能力。

如果是为学校做的工作，或者课业要求，那跟学校里负责这事的人提出你的合理诉求。
如果不是……那为啥要安装到你没有 root 权限的属于学校的服务器上。

懂技术又体贴的用户，我是运营商我肯定喜欢。

可能你最迫切需要解决的是为啥要在服务器的文件系统里任性整理文件的问题，这个是业务层面的根源。
而不是挑选技术方案。

假如说用了对象存储，甚至直接把附件存在数据库里，如果没有倒逼着优化和规范化业务规则，那还是要整理文件、改文件名、改文件的层次组织方式，只不过从文件系统里直接操作变成了通过业务管理系统去操作，那业务管理系统里要开发这一块的功能。但如果倒逼着优化和规范化了业务规则，管理系统配套了，即使仍然保存在文件系统上，也没问题了。

当然，用文件系统，总有人会忍不住“既然放在文件系统里，我能看到，能操作，那我手痒直接去整理总不会犯啥大错吧”……所以换对象存储也好😄

@ChenSino oauth 发明出来是用于给用户自行决定是否需要把自己在一个业务系统中所拥有的资源授权给自己在另一个业务系统中的帐号来跨系统访问的。后来被简化了用其中的一些 API 子集做跨系统认证。单个系统内部的访问控制逻辑是业务内部自己的逻辑。