@julyclyde 贵互联网行业大厂才有专门为业务开发团队需要的基础设施来搞打包的人。鄙各行各业信息化领域，都是（不明学历不明经验不明素养不明薪酬的）开发人员兼职到甲方生产环境做实施的（而且并不是 NetFlix 那种开发有责任做运维），业务功能导向的绩效评定，做规范打包（以及实现业务功能开发外的其它活）是不会额外拿钱的，所以所有东西都扔到一个目录下拷走是性价比最高的选择。

最基本的字节序问题

“每种情况的人我都见过”，因为很多人的主要职责是做开发，顺便兼做部署实施……所以往往并没有系统学习过 FSH 之类的规范，而是会根据自己（个人以及所在团队）的经验发明一些目录布局。

楼上有盆友提到，按 FSH 放太散乱了，不如把所有东西放一个独立目录下方便备份和搬运。的确这也是一个很实用的经验。但是这经验通常也是来自兼做部署实施的开发人员的经历。而从专职运维的人的视角来看，虽然这样做本身没什么大问题，但会“把所有东西放一个独立目录下”的实施案例，通常在目录结构的 owner 和 mode 设置上不太讲究，比如在系统里开一个可以登录的交互帐户，同时用做安装文件和启动 daemon 的功能，装好的文件 owner 就是这个帐户……而你仔细观察一下发行版打包的 rpm 和 deb ，通常装好的文件里不会在运行时修改的内容（放到 bin/sbin 里的程序、放到 share 里的静态数据、放到 etc 里的配置） owner 是 root ，启动 daemon 用的 euid 是专用帐户（比如 Debian 系发行版启动 Apache 和 Nginx 用的是 www-data ），只有运行时会修改的数据，其 owner 才是运行 daemon 的用户。这样的好处是，如果 daemon 因为有爆栈之类 bug 被 exploit 了，至少可以保证入侵者不会篡改配置、静态数据甚至在可执行程序里埋入木马。所以建议，不论用什么样的目录布局，最好是把运行时不会改的文件的 owner 和启动 daemon 用的 euid 设置为不同用户。发行版打包用的规范，其实是做底层基础设施的人根据经验总结的最佳实践。做业务系统应用开发的场景跟基础设施不太一样，但有些是可以借鉴的。

旁路由这个不正规的概念基本上就是墙内环境下莫名其妙生出来的。针对科学上网需求，但同时又有不关注科学上网的家人要正常用网：

1. 一家内的主路由（拨号到宽带，承担全家所有非科学需求的 NAT ）最重要的是稳定可靠。
2. 部分设备（源）或者到部分网站（目标）要科学上网。

对于 2 ，有人的观点是不需要惊动路由器，在需要科学上网的浏览器和 app 里单独做配置，这样更灵活，而且人不在家的时候用流量也能正常科学。那就不存在这贴要讨论的问题了。但是也有很多人希望能在家里的网络基础设施上实现这个功能，对终端设备和应用程序是透明的。那就希望 1 和 2 兼顾。但是要兼顾这两种需求的单一路由器是比较难找的。

通常来说，经过市场考验的成品路由器（不讨论严重缩水型号和陈年老 bug 不改的踩雷型号）对 1 的满足程度是比较高的。但正因为是上市销售的成品，为了不给公司惹麻烦，所以很忌讳搞科学上网功能。而对 2 满足程度比较高的是各种自折腾方案，比如在 OpenWRT 或者其它开源、半开源固件上搞各种标准或非标协议的 VPN 。从 2 的需求来看，最好是主路上能直接科学，这样最方便。但是自己折腾出来的东西，稳定性不太能保证（这些开源半开源固件本身经受的考验就不能给商业路由器比，更何况加上自己折腾这一步骤），而且对主路由折腾的过程会影响家人上网。（不过其实以我的经验，OpenWRT 不要搞太多功能也不要用所谓大神定制，就是用 imagebuilder 把 dnsmasq-ipset 包加上，再加一个自己精心选定的小众协议 VPN ，稳定性还是足够的）

所以在 1 和 2 不能完美兼顾的情况下，有人灵机一动想出聪明的办法，网络拓扑里加一个连接 VPN 的“旁路由”节点，在这个节点上配置 NAT 从 VPN 走，对于需要科学上网的终端，把它的 MAC 地址写到 DHCP 配置里作为单独的一个 scope ，通过 DHCP 给它推送默认路由为旁路由，这样就自动科学了，而其它终端不受影响，还是走主路由。同时，自己折腾旁路由对用主路由的家人也没有影响。当然，旁路由策略具体可以有很多变通。

不过我现在用的方案不是根据终端做配置，而是用了支持策略路由和根据域名对解析结果打 ipset 标签的主路由器（别问是什么型号，问就是 EdgeRouter ），访问要科学的域名时解析的 IP 地址被引流到旁路由去。这样就不需要为每个终端配置，而且不管啥终端，访问正常网站时仍然走的是正常线路，完全透明。

二十年前就成熟了的话题……InstallShield 、Wise Installer 、InnoSetup 、NSIS……后来微软还搞出了 MSI 安装体系

https://en.wikipedia.org/wiki/Insert_(SQL)#Retrieving_the_key

用子句方式的自然不存在这个问题。用存储过程方式的，是通过数据库内部的实现保存了当前会话里最近一次的数据变更操作结果，而不是再写一条 SQL 到表里去查。注意，你所提到的“self.connection.ops.last_insert_id”实际上是在一个 else:分支里，前面还有 if 和 elif 两个分支，处理的就是用子句方式的情况。

所以其实答案的关键不是 Django 怎么做，而是底层的 SQL 怎么做。这个功能的正确性是 RDBMS 本身保证的。如果某个 RDBMS 不能保证，那 Django 怎么写也没用。

跟年代无关，只跟你要做什么有关。

堪比 js 圈的 leftpadding

如#2 所说。但是 /usr/bin 是标准路径，正常情况下不会需要指定的。而且从出错信息来看寻找 make 的位置居然是在源码目录下，这太不正常了，感觉像是 PATH 被破坏了。还有它居然是在 sh 文件的 line 1 ？处处透露着诡异。
不如把你写的 sh 内容原样贴上来大家帮你看下。这样盲猜不太好猜。

互联网开发，糙、快、猛 rules all

第四题没啥问题。bash 作为 login shell 和 interactive shell 的标准行为在 man bash 的 INVOCATION 里有明确说明。至于有的发行版会在 profile 里再去额外运行 bashrc 之类的定制，这本身就不属于 bash 本身的一部分。

反向代理（不要把这个称为转跳，301/302 那种才是转跳）其实是一件挺复杂的事。前面的代理服务器的配置就已经挺麻烦了，有时候仅仅配对前面，后面的业务系统没有“意识到”自己处在反代后面从而做出一些行为调整，也会导致反代的效果不太对。

Nginx 的`proxy_pass`后面参数，写完主机名和端口号，如果不跟路径就结束，那它的意思其实是把传进来的 URI 的全路径直接附加到指定的主机后面，并不会剥掉`location`里指定的前缀`/abc`，所以 8080 上的业务系统就找不到了，所以需要按#4 的写法。

但是这样写了之后，后面的业务系统仍然是按照自己服务在根路径下来运行的，也就是说生成的页面内绝对 URL 并不会多一个`/abc`，这样对前端浏览器（或走 HTTP 协议的其它客户端）来说就错掉了。所以一个业务系统要运行在反代后面，其实是要跟前面的反代约定好，如何让业务系统知道自己要服务的子路径等信息。有的 web 框架会通过特定的 HTTP header 来做这事，有的则提供了通过配置参数来指定的方法，如果什么都没有，那就得在业务系统里自己实现这个逻辑了。

看了一眼你用的这个软件……注意到有个参数：`--root <ROOT>`，看起来像你需要的东西。

@yufeng0316 @Buges @JeffGe 谢谢！

你所谓的“软件行业”内不同客户场景之间的差别，可能比软件行业和互联网的差别还大。有相当多的是想追求速度而不得，同时又保障不了“稳定性和资料的完整性”。

都是被一线运维工作毒打后的实在题

我用微信登录第三方系统时会出现一个帐号选择，一个是我自己的帐号，另一个的用户名是机器生成风格的……鬼知道哪里来的。

非独立博客就是要小心平台作妖

半冷知识：Windows Server 是一个很严肃的服务器操作系统

如果不介意写 CTE ，可以 1999 和 2000 各做一张中间表，然后 JOIN