问甲方那边的员工咋解决这问题的。
如果是防泄密不能用无线通信设备的，很难想象有线网还会让你随便上网。如果可以用 IM 软件 /电子邮箱（几乎肯定有严格监控），强烈建议另开一个账号，不要用私人账号或者工作账号。

事实上现在不少网站已经这么做了，webp 首选，jpg 回落。
不过这么做主要是为了省流量，个人博客省流量的动力不大。

@bwangel JSON 想做到这点的可以用 JSON schema，前后端都老实点在 encode/decode 时用 schema validator 验证一遍。
( https://json-schema.org/implementations.html )

自描述的数据格式理论上都可以用 schema 验证，protobuf 由于不是自描述结构，所以等于强制所有程序实现了 schema 的功能。

曾经大家口中的那个稳定的 Windows，就是因为直接面向用户的功能几乎就是静止不迭代的状态，才有精力提高可靠性和稳定性。现在 Win10 功能迭代明显快了，bug 数量一下子就上去了。也不知道是好是坏。

以前微软就是安心卖系统，安心提高稳定性。这些效率工具让第三方去做，自带工具只保证基本可用（越复杂越容易出 bug ），自己不下场砸别人饭碗。但现在时代变了。

而且对于十年没怎么变过的东西，如果变了，不管好坏，必然一堆人骂的，至少以前的电脑入门教程就作废了。

之所以会觉得第三方软件不稳定，是因为微软发布新系统前不可能给所有软件做回归测试，只能通过 insider 预览版提早公布，然后指望下游软件作者赶在新系统 release 前发布新 fix 把不兼容问题解决掉。如果是下游作者偷懒，或者是一锤子买卖没有任何支持的软件，那就自求多福吧。

分享一个 2015 年收藏的系统介绍 TLS 的博文( https://blog.helong.info/post/2015/09/06/tls-protocol-analysis-and-crypto-protocol-design/ )，不过那是 TLS1.3 还在草案阶段。

目前主流的对称加密方法都是 AEAD 模式的 AES(AES_xxx_GCM_SHAxxx)或 CHACHA20-POLY1305，OpenSSL1.1.1 的 TLS1.3 实现只支持这两大类。

现阶段没有司法判决要求手机厂商必须提供安装未经厂商认可的操作系统的途径。被关闭验证的旧版 ios 就属于未经厂商认可的操作系统。

不太清楚 iphone 的在线验证是在新系统验证还是旧系统初始化时验证，如果是后者，那其实不算是硬件拒绝运行旧系统，而是旧系统拒绝在硬件上运行。

第一个问题：这些场景的 xml 其实是当成 DSL 用的。因为当时的环境直接用编程语言表达这个很不直观。

考虑下用执行代码描述一个用户界面，你得用这种顺序描述：
A.init,A.setP1,A.setP2,B.init,B.setP1,C.init,B.addChild(C),A.addChild(B)

如果换成 xml 能更好地体现层次结构，更好维护。

第二个问题：protoc 项目支持(proto->C/C++/OC/C#/Py/Ruby/java)，protobuf-gen-go 项目支持(proto->go)，项目本身用啥语言跟支持输出啥代码没有必然联系，你要愿意的话在 protoc 上扩充一下实现输出 go 也是有可能的。

按照 GPL 的条件，拿来讲课用作培训材料都没有问题。GPL 并不禁止使用者拿源码 /软件去盈利。触发 GPL 传染规则的前提是“发布或输送软件”，所以企业的 GPL 衍生作品只要保证不公开，例如运行在自家服务器上用于对外提供服务，是可以不接受 GPL 传染的。

哪种情况算违规呢？隐去原作者的版权声明和署名，例如向学员宣称这个项目是自己写的。

那作者怎么保持优势呢？开源项目的作者如果也去开课，有理由让潜在学员认为你比任何人更了解这个项目（简称懂王），作者能比别人教得更好。

很多文件复制软件都可以顺手做 checksum，例如 teracopy 。当然这只能检测损坏。
TF 卡上的文件损坏不算常见，建议直接买质量好点的卡，有坏块说明大限已至了。
切割文件的话用分卷 ZIP 之类的都是可以的，配合 checksum 进行检查和修复。

为了支持 graceful shutdown,你的程序应当捕获 SIGTERM 信号，在捕获该信号后开启 shutdown 工作，停止接受新任务。无论你是不是用容器都应当做到这点。

k8s 默认也是这样的，delete 动作后向容器进程发送 SIGTERM，等待 ShutdownGracePeriod （可适当调大些）后仍未退出就会发送 SIGKILL （不可捕获）杀死进程

估计你就是撞上灰度更新推送了，大公司产品几乎必备的功能。

一般来说不是因为布线原因都不建议搞旁路由，直接把路由串联进网络省事又高效。

使用支持 Reflink 的文件系统，CoW 的文件系统是最佳方案（ ZFS 、BtrFS 甚至不需要打开 dedup 都能做到），非 CoW 文件系统中 OverlayFS 、XFS 也可以支持

不同程序先通过 cp --reflink=always 创建轻量副本，之后所有修改都放在私有副本上进行。

不过需要注意这些方法都不可避免产生文件碎片，虽然节省空间但 IO 性能可能会下降。

这里最丢人的还是 armeabi 和 target26

@Chihaya0824 @typetraits
另外我看到一个观点是由于目前 GaN 的发热问题，不推荐用作长时间满功率供电（例如连续十几个小时跑额定功率）。反正用来接有电池的设备比较难遇到这种场景。所以长时间满功率供电保持稳定就不列为我的需求了。

@echo1937 我也不知道瞬时功耗论是不是靠得住脚，也不知道是否值得为了这个买留有功率余量的电源，但我想现在买 GaN 充电头 /高端显卡能遇到电压不稳、断电、啸叫的问题，好像也只能用瞬时功耗来解释了。

FCP 从来没推荐过给电源做 cost down，顶多认为他高估风险。同理，我也有理由认为平民价 GaN 不能买的论点是高估风险。高估风险算不上啥 RP 问题，FCP 也没有因为这个观点推销过任何特定品牌的产品，说他通过这个论点获取商业利并不合理。作为消费者，我没法用需要 EE 知识的方法判断某个产品的风险平衡点，只能用随市场大流的方法做出选择。

@echo1937 按照 FCP 的说法，啸叫跟动态负载相关，甚至可以故意触发，所以可能只能通过另类手段掩盖问题 ( https://weibo.com/1092211747/JDESIj6Gg ) 反正我觉得耳朵贴近才能听到的啸叫是可以忽略的。

@Chihaya0824 @typetraits
如果一个充电头短路就能把空开烧掉，那你应该怀疑你家的空开有问题不能在过流的时候自动断开。

另外我并不觉得 100-的价位买个 65W 算是什么很离谱的定价，其他主流厂家在这个价位的差价基本就是看有多少个口，多口就贵些，而且出货量都不算低的，要是这算有严重缺陷，那售后早闹翻天了。我买多口也就为了灵活性，因为多口功率分配策略导致超功率能自动断电我都没啥意见。

啥叫禁止网卡随系统启动？
如果希望网卡处于 unmanaged 状态，/etc/network/interfaces 移除所有 auto 及 allow-hotplug 方法

@allentong AOSP 的 package installer 就不能直接装 aab 文件也不能逐个安装 slice apk 的，所以不算国内魔改的锅。
但不能用 adb install-multiple 安装就肯定是魔改的问题了。