彻头彻尾地不安全

- 慢慢逆向实现
- 找黑客黑了作者拿到源码
- 找作者商议购买源码

如果不被滥用，只是 110 119 120 122 这些救命用的热线在用，那我觉得是很有用的 feature

https://ex.noerr.eu.org/settings 自定义 css 里
#Main .cell .avatar {
display: none;
}

不太确定，但简单的方案可能是 HDMI dongle ？

我建议你补缴，不需要熟人，自己去问政策

最近在 github 提 PR 时已经遇到了几次 coderabbitai 了，体验还不错

@Donaldo #107

> 独立完成 fork brunch commit push pr 这一套流程

关于这一点我认为你想复杂了。她更可能是在文档页点击 Edit this page （ https://kubernetes.io/docs/reference/kubectl/docker-cli-to-kubectl/ ），就自动 fork 了，Edit 后就可以在网页上提交，提交后就会自动提示 PR 到上游，整个流程都可以网页上完成。因为看她 PR 的 commit 恰好是 GitHub sign 的（ GPG key ID: B5690EEEBB952194 ）。

@cinlen #111 确实，我当时看到主页也觉得是老油条演的。不过看她的评论区里她提到参与过阿里的文档项目，那可能是以前有过经验或者有朋友指导也说不定。

总之，论迹不论心吧，毕竟还没干出什么坏事。

@accelerator1 #112

> 她的这 pr 的修改内容是什么？你看了么？加个毫无意义的换行也算社区贡献？

有意义，页面都有变化。我也想问，你看了么？

> 最后这个 pr 合入了吗

提 PR 32 分钟后被 LGTM：
https://github.com/kubernetes/website/pull/47399#issuecomment-2275301619

两天后被 approve 并 merge ，并且提醒她以后注意避免 trivial edits：
https://github.com/kubernetes/website/pull/47399#issuecomment-2281231488

现在这个小小的变化已经被应用到文档站：
https://kubernetes.io/docs/reference/kubectl/docker-cli-to-kubectl/

所以她已经确确实实地对 kubernetes 项目做出了开源贡献，尽管是很微小的贡献。

> 开源项目要真是大量这种 pr ，那才是毒害社区

是，但按照我的经验，社区对于新人会更宽容（再次提醒，这是 kubernetes/website 文档 repo ），她要是未来不听劝继续提这样的 PR ，才应该被社区批评——没错，她的另一个 PR 虽然很不恰当，但由于是和这个 PR 同时提的，所以具有相同的“新手度”，依然应当被宽容对待，事实上 kubernetes 也是这么做的： https://github.com/kubernetes/website/pull/47414#issuecomment-2277646230

> 真心是想做开源贡献的人不会提这种 pr 的，你是多瞧不起 985 的含金量？

我衷心希望你没有在维护任何开源社区，我认为任何开源社区有你这样的想法都不会是好的社区。

@julyclyde 不赞同，举例一个场景：一个用户配置或者被迫配置了奇怪的 DNS 导致 AAAA 被丢弃，但一些 APP 又会有内置的解析，导致用户可能在意识不到的情况下依然在使用 IPv6 访问，而当用户使用这样的查询 IP 的网页服务时，我的方案可以消除掉这类影响，覆盖更多场景

”想读书的人，不会找不到目录“到底源自哪本书？看到很多次了

E5 订阅扩容上限是不是 25T ？

@julyclyde #8

需求是一个查 IP 的网站，没办法自定义解析，那么 API 用域名就会增加对解析服务的依赖。例如有的人会在 adguardhome 里屏蔽掉 AAAA ，而实际上设备有 IPv6 。所以直接用 IP 当 hostname 的 API 可以去掉这层依赖。

@julyclyde #4

1. 我认为这个需求比较稳妥的办法是干脆跳过解析这一步，即直接访问 IPv4/IPv6
2. 2024 年提供服务却没有 HTTPS 保护是 **绝不应该的**，所以要给 IP 申请证书