运营准备内容由开发来修改显然是不合理的。但是在这种做法已经是既定的情况下，你提出的方案其实是改变了原来的担责模式（也就是老板所谓的“老板害怕运营瞎改”）。要知道，很多做业务出身的人是讨厌信息系统的任何变动的，不要说工作流程了，哪怕按钮换个位置都要跳起来叫好几年。

一年半过去了，没有下文了。为啥 dnsmasq 可以跟踪到源头而 unbound 不行呢？

SQL 各种成分的书写位置是固定的，不可能根据一个条件子句的位置判断是用来做聚合前过滤还是聚合后过滤。
这张设计是为啥就不可考了，也许为了 parse 方便。不过 SQL 的语法确实槽点满满。也有人设计了语义贺和 SQL 一样但语法不一样的查询语言，但这样的改变并不是实质性的，一点点语法糖终究抵不过 SQL 的既成影响力。

你自己写的大概率不如 syslog+logrotate 靠谱。
——一位跟行业信息化圈子里水平不高还很自信的业务程序员们搏斗了十多年的稍微懂一点代码的老运维如是说

ipset 的好处是可以到 dnsmasq 后面，根据 gfw2dnsmasq 转出的遇难域名列表来动态加到要走隧道的清单。当然 dnsmasq+ipset 在 ROS 上就没办法了，要 EdgeRouter 或者 OpenWRT 或者正常的 Linux 发行版。

当然,从楼主贴的链接里看，楼主更看重的是，哪怕没遇难的外国网段，走隧道也大多比直连快一些。

但对我等穷人来说，国外流量都走隧道的话，那首先要找又便宜又快又稳定又不会在 3 月 6 月 10 月等特殊时期卡顿的隧道……这是个大难题。国外的机子，不管是什么线路，总是会不可控的卡顿。而 UOVZ 之类的，又死贵。

注意由于 EdgeOS 的配置系统只能 mangle 转发的包，路由器上本机生成的包不会进到 AUTO_VPN 规则里去，所以不能在路由器测试是否成功，要用 LAN 里的机器。

set firewall group address-group DYN_XXW
set firewall group network-group STATIC_XXW network xx.xxx.xx.0/24
...
set firewall group network-group STATIC_XXW network xx.xxx.xx.0/20

set firewall modify AUTO_VPN rule 20 action modify
set firewall modify AUTO_VPN rule 20 description 'XXWList address resolved by dnsmasq-ipset'
set firewall modify AUTO_VPN rule 20 destination group address-group DYN_XXW
set firewall modify AUTO_VPN rule 20 modify table 8
set firewall modify AUTO_VPN rule 20 protocol all
set firewall modify AUTO_VPN rule 21 action modify
set firewall modify AUTO_VPN rule 21 description 'Static XXW networks'
set firewall modify AUTO_VPN rule 21 destination group network-group STATIC_XXW
set firewall modify AUTO_VPN rule 21 modify table 8
set firewall modify AUTO_VPN rule 21 protocol all

set protocols static table 8 route 0.0.0.0/0 next-hop yy.yy.yy.yy

set service dns forwarding options 'conf-dir=/config/data/dnsmasq.d,*.conf'

其中 STATIC_GFW 里加的地址可以是类似电报这种不通过域名解析的 AS 静态网段，当然也可以把股沟等确定范围的网段加进去而不必要通过 dnsmasq+ipset 来处理。
DYN_XXW 是通过 dnsmasq+ipset 来处理的目标地址。
table 8 的 next-hop 是你内网里另外的小盒子，上面开一个小众协议的 VPN……（抱歉我不会玩 SS 所以举不出 SS 做透明 proxy 的配置例子，我是用的其它的小众协议）。
/config/data/dnsmasq.d 里放 dnsmasq 的附加配置文件，比如 xxwlist2dnamasq 生成的.conf 文件。

看下来感觉楼主应该是一个比较聪明，个人能力比较强的程序员，并且习惯于跟类似水平的人合作。

但是现实中因为各行各业信息化的需求太大，高水平程序员根本不够用，导致大量低水平的人经过各种泛滥的商业培训班速成甚至没经过培训进入这个行业。而且高水平程序员通常不太愿意去垒技术含量不高的 CRUD 代码。所以 IT 行业看起来这么热闹，但必须面对的一个现实问题就是怎么把低水平的程序员管好，能在可控的资源消耗下以可控的时间做出质量未必很高但按项目标的通过验收的系统。

这种控制，有两方面的努力。一是来自于管理学。在软件开发领域的实践就是软件工程，通过开发过程的管理来控制质量和保证效率。这一点大家回帖里已经讲得很多了。另一个是来自编程语言理论，通过编程语言本身的方法论变革，一方面约束程序员，另一方面又提供便利，把很多因为人的脆弱性而导致的问题消灭在源码阶段，又尽可能提升生产力。比如近些年来函数式语言的复兴，很多较新的语言都或多或少引入了函数式的特征。其实类型系统也属于 PLT 的范围。很多人厌恶 Java 、C#之类“开发业务系统的场景下最常用”的静态类型语言，有一个因素是所有地方都要自己明确写变量类型……但是在近几年的新静态类型语言里，包括一些传统静态类型语言的演化里，通过类型推导极大减少了这种繁琐劳动。再比如通过对 union type 的 pattern matching 处理，也很大程度上让有可能多种不同类型的数据在运行时出现在同一上下位的情况有了较为优雅的容错解决办法。

建议楼主有空的时候了解一下对类型系统依赖性更大的语言，比如 Haskell 、Rust，并尝试用来在工作中完成一些相对独立不影响全局的小任务。看看静态类型的语言是如何也可以拥用很高生产效率的。尤其是 Rust，它在不引入 GC 的情况下实现自动内存管理，就是把资源的生存周期作为类型的一部分，通过强大的类型推导来让编译器发现分配的资源要在什么地方释放。

静态类型并没有那么讨厌。在很多场合下，它是程序员的好朋友。

因为他们只对升职转管理岗脱离具体技术工作感兴趣

那不就是相当于 Debian 系的 proposed-updates 么。确实不是 Debian testing 那个意义上的滚动发行。对于整个 RHEL 来说也不能算是 beta 版，大概可以看作是的 issue fix 的 beta 版。

不过呢，作为常年保持 Debian 随手升甚至 n 多次跨版本大升都没出问题的人，唯二两次升挂掉之一就是曾经开了 proposed，之后就再也坚决不开了。

你再想想变量名里的各种稀奇古怪 Chenglish 拼写……就会觉得读音的问题还算好的了

你的“除非”，就是很多人的常态刚需

换同事

@eason1874 你说的协调之类的工作是项目经理不是产品经理

nginx 配置语法是描述式的，不是过程式的

20 多年前就开始做桌面 GUI 的老人表示现在前端的工程化（某种意义上也就是一些人认为的复杂化）其实就是把桌面 GUI 工程化过程踩过的坑再踩一遍罢了。
但是跟当年桌面 GUI 的发展🈶️两点不一样
一是 web 前端由于历史进程原因颇有一些尴尬的技术限制，导致经常要额外绕路和填坑，于是更加复杂了。
二是当年桌面 GUI 是按部就班慢慢打磨着发展的，而 web 技术（不只是前端）托互联网行业风大能吹猪的福，难免发展糙快猛。

Windows 里真正的版本号也是一个元组结构啊，讲究的程序并不会偷懒用字符串比较。

以我的浅薄经验，几年前的代码只能算是一坨屎，要重构几次之后才能成为屎山