你看看打包好的 rpm/deb 里，每个服务用的用户就是这样创建的，这个范围的 uid 按约定不用于交互登录用户，是拿来跑服务的系统用户，如果打包的撞车了是发行方的错，你自己乱用是你的错。打包的 post-inst 脚本里加-o ，是为了保证包升级、不同来源的兼容包平替等场景下不用考虑复杂的创建用户操作，已有的用户可以继续使用。

认真看一下 man useradd 了解 -r 参数的意思

以前吐槽音译，现在看来，在计算机技术这个变化比较快的领域，还是音译好（更好的是不译，直接用原文），至少不会存在一对多、多对多的语义冲突时的选择分歧。

用来做透传很方便

交换器上根据 mac 查端口

传统业务系统换数据库，往往不是换数据库的事。得重构应用层代码做适配。

建议不迁移。

换个思路，干脆用无意义的字符串比如 UUID 做路径，反正现在的用户都是从搜索和导航来找的，使用时也不会关心 URL ，甚至根本注意不到

5.7 已经 EoL 了，官方的 repo 里不包含，很正常

没听说过。PG 是有的。

要不再等等，等 qcom 收购了 intc 再说

“我林家满门忠烈，你懂个屁的 Windows”

有可能你的洁癖只是别人的规范，人家已经把按规范做导致的出码速率“降低”作为规范化管理和质控的成本考虑进去了，也有可能人家出码过程的局部低效率换来的是程序质量提升带来的整体高效益。

群众理解的“高通进军 PC 市场”：培育 ARM PC 生态，从 X86 手里抢份额
资本理解的“高通进军 PC 市场”：买一个遭遇打击但市场份额还在的 X86 CPU 领袖

TS 的定位是为大型项目的工程化开发而创造出来的，JS 的超集。所以以你的情况学 TS 会增加明显的学习负担而没有明显的收益。
至于不同语言之间的配合，所谓的不同语言有两种情况，一是在同一个 scope ，比如都是后端的业务逻辑，那么一般在一个项目里会统一，比如约好都用 Java 或者都用 Python 或者都用 JS/TS ，或者再宽限一些，都用 JVM 的语言，比如 Java 、Scala 、Kotlin 都用，但是划分好不同人开发的模块边界；另一种情况是在不同的 scope ，比如前端用 JS/TS （目前的情况，前端基本上就是 JS 及其衍生语言，别的语言从项目运作角度不现实），后端用 Java ，这样其实是没关系的，因为前后端的代码并不直接互操作，而是通过 HTTP 协议传输数据。另外，如果一个项目的后端涉及不同语言的强势生态，或者要跟存量系统的代码对接，那其实可以解耦成第二种情况，并不写在一个大程序里，而是通过网络调用（说法不是很严谨，大致可以这么理解）对方接口来传数据的方式来集成，那其实跟是不是一种语言就没关系了。

@wxw752 中间件……用老版本呗。去年还帮人验收了一个 CentOS 6 + Java 6 + Tomcat 6 的 666 项目。主要是很多地方性、行业性的信息化小公司对 infrastructure 的更新不当回事，而没有技术力量的甲方单位则毫无概念，从来不会提要求。

警告往往是隐患。

过公网的大量数据传输，只建议针对具体业务场景做整体方案设计（至少包含网络拓扑等基础设施建设），而不是纠结传输协议的比较。

仿佛穿越回 20 年前