所以说白了就是监控反应的不是真实情况，运维需要与时俱进改善对新 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 的一些想法火起来了而已。

可以试下 github.com/ysmood/storer，我觉得性能可易用性都比 bolt 好点。

这是你的压测 https://gist.github.com/ysmood/a18af48010b08a39886ef460f98fddaf

我觉是单纯只是设计上不友好，一般系统默认配置就能跑示例代码，而 kafka 非要设置额外的东西。而且在 docker 里还容易泄漏 pid 的 lock 文件。
所以我做了个 image 来处理这些琐碎的事，感兴趣可以试试 https://github.com/ysmood/kafka-image

这里注释了为什么我们要这样做 https://github.com/ysmood/kafka-image/blob/e58ee2c466890ba2d86d82a25def0d6828faa382/cmd/run/main.go#L24

@index90 有可能的吧。TCP 只是个协议，传输层不一定要按照协议传输，比如恶意程序劫持 TCP 包然后不按照顺序传输。只不过通用 TCP 实现都会有个 buffer 包然后通过解读包的内容重新排序，所以你在应用层 read tcp 包的时候感觉顺序是既定的。所以要看哪个层面在解读这个问题，是 tcp 实现层还是应用层。

几行代码自己写一个：


实现快捷键跳转到下一个搜索结果也很简单。

不知道这个能否满足你的要求 https://github.com/ysmood/umi