laozhoubuluo

@bclerdx 这种事儿哪儿说的清楚啊，电磁辐射对人的影响是没有证据证明有害而不是已知无害，再说了一般搞这种的人也别指望有什么科学素养。
热点地区以公共建筑，商业楼宇为主，附近居民数量很少所以形不成规模。
另外小区里边建设基站占用的公共资源是属于业主公有的区域（公共建筑，商业楼宇肯定不属于普通住户），又没有法律法规或者文件规定小区里的基站属于基础设施任何人不得干扰正常运行不得拆除，所以如果支持者超过一定人数那从法理上确实可以拆。

@bclerdx 这种拆基站的投诉一般不是普通的投诉，请参考前几年四家联合声明那几个小区的折腾方法。

光猫本身差异倒是不大，主流厂商都做了互联互通处理，但主要有以下几个问题比较麻烦：

1. 运营商采购的定制光猫通过 TR069 实现了和自家管理平台的对接，如果不支持 TR069 的话就需要手动配置业务数据，就跟当年 ADSL 时代要配置 VPI/VCI 一样但操作起来比 VPI/VCI 复杂不少（毕竟不是纯宽带桥接，有些地方 ONT 入网还需要后台许可才能通）。手动配置的话对维护人员技术要求高不少，而且效率也低（扫码开通十分钟开一台，手动配置半个小时不见得能通）。而且有时候割接之类的还会导致配置变更，如果没有 TR069 下发配置的话那全部得维护人员上门变更，这个工作压力可想而知。
2. 如果通过固件实现集成倒是没问题，但运营商也没法保证适配所有品牌所有型号，而且不同类型光猫支持的能力也不一样，买起来就很麻烦了。比如用户办了条 500M 宽带并赠送一个固话号码，运营商线路是 EPON 的，用户买了个 GPON 只有一个百兆口的杂牌设备，恰巧杂牌设备没适配该运营商该省，这业务怎么开。如果锁定特定的一批型号的话，好像还不如外线直接拿来让客户购买、租用甚至白送呢。
3. 换光猫的理由类似于 1 所提到的现场人员受限于水平排查故障效率很低，复杂的故障协调后台层层排查反倒浪费时间，不如直接换个新的或者良品光猫（这个分地方和库存）解决。坏的光猫拿回去运营商统一找人清零测试，数据问题清零之后测试完直接做备件，硬件故障的在保修期内就返给厂商维修之后测试完再做备件（也有地方不管什么问题统一返给厂商维修的），不在保修期的就报废处理更简单有效率。

1. 撤销低效能 4G 高频站，同频率让给 5G 实现替代。毕竟语音、短信和 IoT 设备对网速需求不高。
2. 可能因为用户投诉、站址不再续租等原因撤销整个站址，那就是 245G 全没了。

断的话记下具体位置和他们反馈让他们解决呗。

缺人砍维护资源这种事情对于任何项目都没办法，而且受影响的范围相对没那么大。
个人用户刨除（内核版本无所谓），中间件适配能力强的用户刨除（比如 Web 类应用或者容器化的应用没那么挑内核），红帽这种具备强大 backport 能力的刨除（团队有能力识别并针对老内核做安全更新），不更新的用户刨除（这年头国内还有一堆 CentOS 6/7 在跑着甚至没有替换计划），剩下的才是影响范围。

@8355 是这样，20 QPS 感觉如果几个人一起用的话确实有可能能顶到峰值，例如 DNS 都指向外网而不是软路由的同时几个人输入域名一起回车的场景。
现在运营商 DNS 搞针对境内网站的 DNS 劫持之类的没有之前那么多了，所以没有 DNS 劫持的地区确实优先考虑运营商 DNS 。

一般这种要求给钱但给不出任何细节的基本都是诈骗。
Bug bounty 可以搞，但一般规则都是先交漏洞后给钱，给多少钱以厂商计算为准。

国际市场的话必然有一定影响，毕竟有这次之后绝大多数开发者都要考虑一下能不能接受 Unity 一言不合就改授权政策的行为，而且中小厂商有自己的生态位所以大厂用不用 Unity 对他们压力没那么大。
国内市场影响能有多大不好说，具体得看大厂商是否带头在新项目中弃用 Unity 了。如果大厂认为反正有买断源码不怕，那根据我国市场特色小厂商基本上也被迫选 Unity ，毕竟员工对学习一套大厂很少用的技术这件事上必然动力不足，除非喜欢过朝不保夕的生活。

@ENIAC 仔细测试了一下发现了个问题，encode 似乎并不能处理中文。

例如：
```
const json = '{"Username":"测试","UID":20}';
const encoded = encode(json);
console.log("编码内容:", encoded);
```

返回结果是（空格是我添加以便区分的）：
编码内容: x10Y75Y1eNBwyuCnC undefined undefined YCXzXYGZvCMb1W3jr

那这样的话如果输入内容包含中文，那么势必会出现乱码的情况的。