@Xusually 然而我对话过的所有欧美的开发者都不念 “拉”，所以官方文档也阻挡不了人们对自然发音的追求。现实就是如果你读 “拉” 听上去会很不自然。

这是 jira 自己做的广告 https://www.youtube.com/watch?v=q89KV_wyJZI&list=PLaD4FvsFdarTjXnEtJeyNAB0-6v6RLpJn

看得出来不同国家的人发言是不同，英语母语的人倾向于读 /dʒiːrər/，jeep 里的 jee，error 里的 ror 。

@ysmood 我说的 flag 就是指的这个 GODEBUG=madvdontneed=1 啊。所以理论上应该去修正监控和报警吧，虽然可能改 flag 是最现实的做法，但我觉得最好是把理论也说清楚以免看不懂的人误解。

内存报警不应该是泄漏导致需要内存的地方没有足够内存使用吗？还需要怎么定义？现在是其它程序需要内存依然能正常得到吧？

我觉得去业界看看用的多的监控系统源代码，肯定有监控系统已经修正或者打算修正这个问题了，也不是只有 go 才能触发。

所以说白了就是监控反应的不是真实情况，运维需要与时俱进改善对新 linux 内核的监控方式（笑

所以还是没提算法边界条件的细节，单纯靠设置 flag 或者吹气球只是在回避问题核心？
比如写个最小 go 实例能 100% 复现这个问题。一般人真正关心的是如何在 go 代码层回避这个问题吧？

@loading @falcon05 这里竟然没有把全部的规则写出来？ https://www.v2ex.com/help/currency：

回复
创建每条回复将消耗至少 5 铜币。如果回复的内容越长，那么消耗的铜币也会越多。创建回复时消耗的铜币，会转移到主题创建者。如果是回复自己创建的主题，那么不会发生铜币转移，只会消耗。

你确定不是因为你回复太长了？

@loading 2400 天太强了吧， 在海外生活是无法充值 V2EX 的，支付宝会直接报错无法使用海外 IP 支付，所以免疫了这个问题。

@stay 你的报错信息里其实已经说了原因：“git.io port 443: Connection refused”，这个脚本是自动下载项目 release 页面的文件，github 用到了 aws，由于众所周知的原因国内估计是很难流畅使用。你可以去 https://github.com/ysmood/v2ex-clockin/releases 手动下载可执行文件试试，但是科学上网可能是必须的。

@laoyur 这没多年有多厉害啊，你是如何解决验证码问题的？别告诉我是打码服务

@opengps @Takuron 仁者见仁智者见智吧。代币机制我觉得设计的初衷是增加用户粘性，并给新用户提供更多的发言机会，但这并不是一种完美的可持续性机制。只能说这是一个非常易于用代码实现和维护的机制，且在平台初期有一定的提升发言品质的作用，但弊端是很容易产生通胀而导致内容垃的圾化。

所以与其不让自动获取代币，不如把代币机制更换成更现代一些的机制会更好。比如研发 Reputation System: https://en.wikipedia.org/wiki/Reputation_system 或则它的一些改进变体算法来更好的维持社区的内容质量。

@no1xsyzy 浏览器插件这种如果退出了浏览器应该就无法运行了吧。关键是有空我自己拿 pytorch 跑跑 ML 就可以完全放 linux server 上独立运行了，这个浏览器插件就的差更远了。

@cumt21g 其实项目的 readme 里已经提到了和 chromedp，puppeteer，以及 cypress 的对比。

我们一开始也是使用的 chromedp，但是用了一段时间之后发现了很多它的根本设计问题，chromedp 为了并不常用的 context 设计了反直觉的 DSL 来绕开这个问题，这使得我们不得不大量重复的使用它设计不完全的语法操作网页内容，写个 if-else 都要多增一些代码，而且不小心写错了还容易出奇怪的 bug，debug 相当痛苦，每次断点到它的代码里基本就会迷路，原因就是它利用自己的 DSL 将 golang 的强类优点基本全屏蔽了，类型跳转根本没法用，基本就等于是在用 nodejs 了，那我何不直接用 puppeteer 呢？

另外一个要命的问题就是它底层设计时用了 chrome 自己的 json schema 来生自动成类型代码，而 chrome 自己的 json schema 本来就设计不好，比如最底层的 api call 其实是有个可选的 session id 字段的，然而 schema 里并没有表达，这导致 chromedp 等利用这个自动生成代码的库都没有把这个 session id 带上，这对于 iframe 的操作是很关键的。这也就是为什么这么多年了他们这个 issue 还没任何进展 https://github.com/chromedp/chromedp/issues/72
iframe 的支持对于我们支付服务的测试是必要的（比如 stripe 多层 iframe 套娃）关键是他们底层设计太繁杂，我觉得自己写个都比去改它代码省事。这也是我觉得有必要自己写个框架的主要原因。

仅仅是我个人的观点：即使给一些外语的技术演讲加上中文字幕都会更促进社区的进步，很多演讲能给人的启发远远大于文档能产生的收益。
另外，不只是英文，有想法的人任何国家都有。

建议先做个问卷调查，看看到底不能阅读英文文档的程序员的比例，我估计很少，大学毕业就需要 4 级英文了，英文文档一般都浅显易懂。
我也很赞同授人以渔的观念，或许多花些时间到技术相关的英文教育上会更有效，这方面其实也可以有很多开源项目可做的，比如做一个平台用 AI 分析搜集常见的容易误解的技术性英文单词或者句子等等。

顺便附上个我 4 年前写的库，和一般 rpc 库不同的是你可以一次调用多个函数组合而不用每次都把数据拉到本地处理，相当于你发送了一个脚本到远端去运行，而且这个脚本是安全可控难以注入攻击的： https://github.com/ysmood/nisper

引用一个标准 rest 库不就可以不手动写了吗？ http with url 本身就是一种 rpc 啊，ajax 符合一切 rpc 要完成的事，只不过 function name 现在是 url path name 了，params 换成 query 或者 post body 了，http 的 status 返回码也是有标准错误定义。哪个都很符合 rpc 要完成的事。

所以从问题出发，如果你发现生写 ajax 处理很麻烦，就写个库或者引用别人的轮子将这个步骤抽象掉，问题解决。这个跟 rpc 没有太大关系。rpc 很古老了，对于前端来说也一点不新鲜。

rpc 是在 http 之前就有了，当计算机性能带宽不再是通信瓶颈后，人们选择牺牲性能和带宽来增加协议的可读性，这样你会发现 http debug 只需要截获他的包用文本编辑器就能读懂，这样就衍生了一大批友好的 http 开发和调试工具，这也是 http 能普及的总要原因，而像 grpc 的数据包你是没法人肉读写的，代理更是没法简单根据数据内容优化路由或者缓存。

各有各的好处，没有完美，只在于取舍而已。如今分布式的流行又让 rpc 的一些想法火起来了而已。