@mingl0280 本地和环回是两个概念。
LAN = 本地区域网络

@v2tudnew 不是冲突，而是 CNAME 覆盖其他任何记录。
你读读我 #26 到底写了啥，ANAME/ALIAS 就是为了避免这个问题的，而不是为了楼主的 ping

《分治》

@DeWjjj 不是说这个，是说制程后期良率高了，但中低端需求更高，还是硬来一波屏蔽当成做坏的卖。
（故意做坏是不可能的，只是好的也屏蔽罢了）
这属于第二类价格歧视。只要是市场经济，这种操作避不开，也没法追究；当然，第二类价格歧视是好是坏是我认为不存在绝对答案的相对价值判断。

@2i2Re2PLMaDnghL 话说起来顾名思义都行
变基，是指『变更』提交的『基础』
合并，是指将两个分支的提交进行『合并』（我知道，循环定义了）
也就是说，当且仅当这些提交是那些提交的『基础』时才进行变基。

@vjnjc 你可以 diff <merge 的主支>...<merge 的分支>
据说 fossil 合并后分支会变成 tag 永久保留，你也可以轻易地看到这个 branch 的历史。
squash 似乎不太适合在时域上进行 bisect，这对于大型项目还是挺重要的。

历史可以分叉是很恶的（双关：恶心且邪恶），但是因为爱因斯坦的关系不得不这么干。
凡 git 的事想一想用邮件怎么玩。

1. 什么时候 rebase ？
你以别人的软件的 v1.0 为基础开始写一个 feature，还没写完的时候 v1.1 发布了，你把新代码 pull 下来并把你的修改全都 rebase 到 v1.1 上去。

2. 什么时候 merge ？
别人为你的软件写了一个 feature，然后 send-email 给了你。你拿到了他的 patch 并 merge 进你的代码。

想要隐私还是推荐 Replicant 并且只安装来自 f-droid 和自行编译的软件，且全局 Tor
不会真有人信了苹果关于隐私权的那套说辞吧，CSAM 审查还不够说明问题吗？再重申：「噱头」不是「保证」。
一个把高端消费品搞得像是个奢侈品的品牌…… 这是卖给穷人，然后让这些穷人自以为是富人的东西。
类似地，卖给完全不懂隐私为何物的人，让这些人觉得自己的隐私得到了保护。

- What is the purpose of our privacy policy?
- To protect users' privacy.
- It is to make people *believe* users' privacy is protected.
- The hackers?
- Not the hackers, the users! The hackers know it's not.

意义不明，你到底要优化什么？

没看代码，我猜你可以预处理一下把 > 11:30 的数据点直接挪到下一个 k 线
再推荐个中文变量名。

SICP 第五章我也没能仔细看下去（

先问下你为什么要调 ping 的结果？
一般而言提供展平是为了同时存在其他记录，而避免因 CNAME 的性质导致无法保存其他记录，比如 MX 记录（邮件服务器）
只是为了 ping 去做展平有点多余。很多网站都没做展平。

nginx 怎么重定向 ICMP ？你还是先学学吧，思而不学则殆

cloudflare 我记得有个 aname 还是什么的，会把 cname 展平。

不然的话只能看看 ping 有什么选项这么做了。

ssl pinning
到底是谁让你隐私整改，你就算自己设计协议，都 root 了直接 hook 函数不好吗？

#4 不是返回 default，而是先求 default 再求 next
但因为求 default 导致了无限递归，你永远不会求 next
不妨试试这样写
original_next = next
def next(*args):
... print("running next()")
... return original_next(*args)
你再试试，你会发现 "running next()" 一次也没被打印。

你在 get_a 里面还没进迭代器呢就先重复 get_a 了，罚您重看 SICP 1.1.5
next 的参数不会懒惰求值，咱把 get_a 写成 applicative order
def get_a(k,v):
t1 = filter_a(k,v)
t2 = get_a('a',2)
t3 = next(t1, t2)
return t3
显然，计算 t2 的时候就已经无限递归了

你需要的大概是
try: return next(filter_a(k,v))
except StopIteration: return get('a',2)
或者 chain 一个生成器上去
next(itertools.chain(filter_a(k,v), (get_a('a',2) for _ in range(1))))

但也有个问题，如果没有 x['a']==2 的记录，还是会无限递归。

具体选型的问题还考虑到你的前瞻性。
你说的 schema 不稳定，但其实如果不是记录间有差异（比如每个人有不同的职业，各种职业具有不同的参数，导致要么字段重载，要么大量空字段），否则 SQL 没有问题，都不过是用着爽不爽的问题。
记录间有差异其实也可以用辅表。

如果又要不确定的字段又要进行查询，是典型的需要 ES 的情况。但得问你是不是真的需要压这点性能。我记得说 PG 的 JSON 是可以作为查询条件的（只是效率问题）。

题外话，
我认为完全可以存在大一统的数据库，采用图论数据库的基本模型并且根据实际需求写优化查询的方案。
但是现在似乎普遍不希望数据库负担运算任务，即使实际业务的执行树已经复杂到数据库传输成本过高，也是每个前台添加 Redis 或者添加更多只读从库解决。

@murmur 用爱发电也可能是不保证服务可用性，被 D 就下线。
或者就用爱发电跑个树莓派，流量域名都是白嫖的比如 .tk+CF+github pages （

压缩可能比 protobuf 更少。
比如如果你一千个坐标里面有五百个是同一个坐标，压缩能减很多。

我都怀疑你是特地凑好的
64*64=4096

如果限定在 ASCII 内，则只有 94 个字符可供表示（从 0x20 到 0x7F 再去掉引号和反斜杠），用 base94 表示的话
log_94 4096 = 1.83
仍然是四个字符表示一个坐标，和 base64 没区别

如果拓宽到 unicode，鉴于 UCS-2 会导致其他部分全部翻倍，得不偿失，所以还是 UTF-8
这就有个问题，UTF-8 编码效率非常不稳定，甚至可能三字节表示一个码位，看你的分布了

压缩有压缩的工具。