直接拿公开域名做就好啦，公司防火墙做一下隔离就完事了，对应的 DNS 可以对外公开也可以不公开。
例如公司有个 abcd.com 对外域名，内网域名都用 internal.abcd.com 二级域名，或者另外注册个 abcd-int.com 内网域名。


@jobmailcn

实际上所有 CoW 的文件系统都不保证原来的数据块被覆盖，因为一个文件的数据块可能被其他不相关的文件或者快照引用。

对应的 UI 被设置为隐私敏感，禁止录屏截图的，这个安全机制已经存在很久了。
考虑带外录制的方案吧，不太记得 adb 截屏行不行，如果可以的话电脑用 scrcpy 遥控吧，或者像小米妙享之类的多屏协作方案，把问题转换为遥控 pc 。

这个记录可以在客户端连接前通过 DNS 了解服务器支持的 http 协议版本、端口号和偏好等。例如 HTTP 2/3 就可以直接建立连接，而不是先建立 HTTP/1.1 （可能还要加个 TLS ）后通过 Alt-Svc 头和 Protocol Upgrade 机制升级，改善首包响应时间。

反正就是要个网络环境，性能啥的不重要。

如果你打算用 systemd 、docker 等管理服务日志，用 stdout 问题不大
如果本身有 CLI 交互的就得换 stderr 了

内部存储( /data/data/包名 ) 是保证可用的，/sdcard 按 AOSP 规范属外部存储，不保证可用。
以前 /sdcard 是一个独立 FAT32 分区，可以以大容量存储的形式暴露给 USB 连接的主机上，此时对 app 而言 /sdcard 不可用。

wireshark 抓 icmpv6 router advertisement
fc00::/7 是 ULA 地址块，通常不会将拥有该地址视为 IPv6 可用

惯例内部存储指 /data/data/包名 / ，其余都是外部存储，可以有多个，插 tf 卡的机子普遍有两个。

最关键区别是内部存储永远可用，而外部存储不作此保证，也不保证受加密保护，app 使用前需要通过 API 检测。对于内置存储的机子，等于多了一个永远可用且受加密保护的外部存储。

非 root 系统存在通过 adb 和用户 UI 修改外部存储内容的方法，app 需要考虑文件被外部读取和修改的情况。
外部存储读写需要 READ_EXTERNAL_STORAGE 、WRITE_EXTERNAL_STORAGE 权限（ Android/data/包名 目录有特殊的管理机制），且受新的分区存储模型限制。

证书匹配时，*.example.com 和 example.com 是两个网站，所以如果用通配符证书，建议两个站点都用同一个证书（即证书的使用者可选名称要同时包含这两个）。
所以如果你是 www 301 重定向到裸域名，但 www 的证书验证有问题，依然有可能重定向成功，因为默认用 http 请求。但现在有些浏览器默认启用 https ，这个就会成问题了。

一般来说，同版本重复刷不会有啥副作用。
这里这么要求，估计是 hdmi 的新固件对 bios 对低版本有要求，防止先刷 hdmi 固件没刷 bios 时亮不了机。

现在新一点的手机系统都支持扫码连 wifi 的，行业标准早就有了。
不过一定要强调用系统的扫码 app,或者系统相机，毕竟扫码=微信扫一扫 已经深入人心了。

@snw

1. “闪付 QuickPass”是银联对非接触支付使用的统一品牌，与传统的磁条和芯片。”云闪付“指支付端需要联网的非接触支付，也是 APP 的名字。虽然电子现金（也就是你说的圈存机制）和现在联机账户小额免密、二维码的运行机制完全不同，但均符合非接触支付的定义；

2. 商户收银员培训不足问题到现在还存在。在聚合支付 POS 厂商进场后，我见个微信支付也要签字的，也见过信用卡无密支付也没要签字的。虽然我很清楚哪怕是信用卡，不签字基本也不影响收单；

3. 我见过的 POS 机感应位置都挺统一的：顶部出纸口。如果有密码键盘的就是密码键盘显示屏，这种设计还有个好处是用卡时可以保证卡不离手；

4. 联机免密可能涉及担责问题，早期我只见公交和麦当劳可以免密（公交还有同时支持电子现金的，我甚至不知道刷的是哪的钱），那时免密限额是 200 ，后面才逐步放开的。

@ouqihang
闪付有一个问题是需要先输金额后刷卡，跟磁条的顺序是反过来的，导致不少收银员不会操作了。

一般是不能，无法避免与操作系统打交道的。
裸机程序倒是可以，参考裸机 hello world

https://zhuanlan.zhihu.com/p/420610342

好像还有一种混合二进制，将 bsd 和 linux 的代码段混合在一个 ELF 里面，但做不到任意 OS ，至少 Windows 这种不使用 ELF 格式的就不好搞。

另外一点，不怎么喜欢用 zip/unzip 是因为这玩意一般不预装，但 tar 和 gzip/gunzip 一般都是预装的。
冷知识，docker cp （曾经？）依赖容器内的 tar 才能工作，这点约等于要求所有 docker 镜像都得预装 tar 。
至于选项开关 -c[reate] -e[xtract] -f[ile] 基本够用了，压缩方式让 tar 自己猜去。

tar 对 POSIX 文件系统元数据支持较好，zip 容器理论上也可以通过扩展支持，但不同软件不一定正确实现了这些扩展。
tar 只归档，gz 只压缩，gzip 是把 tar 作为一个整体进行压缩的（也就是固实），压缩率会好一些，坏处是没法原地修改和部分解压。zip 不支持固实。
zip 也不支持符号链接、硬链接、稀疏文件。

zip 的文件编码问题就是不同实现导致的。此中的吐血事可以看这个，支持了但没完全支持。

https://blog.abysm.org/2016/04/pkzip-filename-mojibake/

其实只要是有不同主流实现就有可能出现兼容性问题，linux 常用 infozip 但 windows 常用 7-zip 套壳。tar 的实现也有 GNU tar 和 bsdtar 两种，有时也会出点问题。

国内主要还是银联出手太慢，被支付宝微信抢先一步确立了日常小额支付的事实标准。

你想想在 2014 年，也就是开始推广线下移动支付的那一年，支持 NFC 的手机有多少，那年的小米 4 可是反向砍了 NFC ，哪怕是支付宝都觉得 NFC 硬件这条路不好走。那时银联手头像点样的对标产品就是电子现金（要在 ATM 圈存，不挂失，1000 限额的那个），而且推广完全摆烂。除非网络不通，否则你不会觉得这玩意好用。

现在 nfc pay 倒是回来了，但二维码支付已经推广完了，好像也没必要硬换掉原来的体系了。银联自己也投降了，废掉了电子现金改成银行担保的小额免密了。
我也知道二维码和 HCE 方案的安全性是比 eSE 差一些，但实践下来，这个方案的安全性是足够了。

曾经是搞过降频的，然后就吃官司了。
不要太把那 80%健康度当回事，因为这是要通过反复完整充放才能校准的，到寿命末期不好测量。基准功率供应不上就是大限已到，该换机的换机该换电池的换电池，不要折腾这些有的没的。上面跑的软件性能需求增加是不争的事实，降频降性能也是有限度的，不可能给你无限降下去。
Android 用户通常不会纠结这个，老实换电池去，100 左右，一般用到第二年不爽就可以考虑换了。