正点原子的那个手持示波器？

之前看好像评价还挺不错的，价格也还行，当然性能上肯定不如桌面级别的好

至于能不能看 MIPI 信号就要你自己查下参数了

忘说了一件事，目前我们正在缓慢拓展用户中，如果有自带流量的 V 友愿意推广的话，可以直接用首页的推广链接做推广，现在这个推广阶段注册的用户以后所有的付费都有分成

警惕 GPT 依赖，GPT 对于这种定性的问题很容易一本道。对于定性的问题，最好是自己在这个领域已经有了一定程度的了解，才去问 GPT ，否则很容易被带偏还不自知

我觉得 memcpy 不检查边界这件事情对 C 程序员来说应该是常识来着的

@lelandsu 这个是一个问题，过几天的新版会修复

@wynemo 昨天提交新版本了，现在审核已经通过，应该会自动更新下来了

@wanguorui123 你是想自动保存网页的 mht ，而仅仅是纯 HTML ？这样会很大的哦，估计一天就能有几个 GB 出来

@zooo 曾经想过做全文索引然后加快搜索速度，但是考虑到本地没法实现，而如果在服务端实现的话对个人来说部署又太麻烦，于是还是直接采用扫描的方法搜索

@dasenlin 这是一个问题，做的时候确实没考虑到这种情况，过几天会更新一个版本出来解决

@Rookiewan 如果指定目录的话应该就只搜索这个目录下的，我回头再测试确认一下

@xujinhui1 应该是要先设定 WebDAV 链接，然后才能用，这地方的提示应该是没做好

这个网站看起来很 360 ，第一印象不太好。
进去看了之后发现功能意外地还不错，然而，如果真要使用的话，我就开始顾虑：
1. 这网站看起来不是很大的样子，会不会用着用着就跑路了？
2. 作者都在 V2EX 上发文困惑要不要跑路了，我看我还是别用了吧

@HeyWeGo 显示就像没有 CSS 的网页，反正只是回溯一下文字内容而已，不是经常看，显示效果完全无视
@TrembleBeforeMe 保存的是存文本，主要是考虑到连图片一起保存的话太大了，而且我自己主要是需要找文字内容而已。
@caomu 浏览器限制太大，本地索引不好做，真要做的话还是在服务端实现比较好，但是服务端实现的话部署就比较困难，不像现在这样随便整个 NAS 就行


我倒是想做一个类似 Rewind 的东西，就直接屏幕截图，然后 OCR 文字，全文索引

@mhqshen 这是一个笔误，你不说我都还没发现，捂脸……
@eaststarpen 没有清理功能，手动清理，反正会用 WebDAV 的都会……其实我自己是保存到 NAS 上的，纯文本再多还能给我撑爆了不成。话说历史记录……我一天几百个网页的浏览量，想找一天的都难，别说几天了

@Thiece 不是，具体算法就是计算连续平方取模，因为后面的计算依赖前面的结果，所以没法并行加速。类似连续哈希

@iqoo 新年好。我看了一下 Crypto API ，它提供的主要是密码学相关的高级函数，而这个验证码的计算只是简单的乘法取模，没法使用 Crypto API 进行加速。
PoW 是有很多方案，但是这里需要选择一个可以抵抗并行加速的方案，否则攻击者用显卡就可以轻松绕过了。

@devliu1 新年快乐。实际上我就是受 mCaptcha 的启发，wCaptcha 和它的思路是一样的。区别在于，mCaptcha 的方案是普通的连续哈希，这就给显卡加速留下了可乘之机。
不知道它现在有没有更新算法，现在 mCaptcha 的网站似乎挂了，回头我再去看看它有没有更新。

@iqoo 愿闻其详，wasm 已经是我能找到的在浏览器里面计算最快的方法了

继续回复大家关注的点：

1. 关于 GPU 加速的问题，虽然说可以用 GPU 对多个工作量证明进行并行计算，但是平摊下来每条流水线的速度估计会很慢（关于这一点我没证实过，只是纯推测），这样就没法在一定时间内算出结果了。另外之前也回复过了，对于多个请求进行并发计算，这验证码是没法直接防住的，需要根据具体业务做一点额外的工作。

2. 关于是否能有不消耗 CPU 而是消耗内存的算法。这种算法肯定是有的，不过我还没有研究过，过段时间可以翻一翻论文找找。

3. 大家别看到工作量证明就想到挖矿哈，客户端算个几秒钟不算什么消耗嘛，该消耗的 CPU 还是该消耗的嘛，就像谷歌一次就要排放多少克碳，可我们该搜索也还是要搜索嘛。传统的需要交互的验证码，虽然不用消耗 CPU ，可却消耗了用户的生命不是嘛

统一回复一下大家比较关注的点：

1. 关于 CAPTCHA 太多影响体验的问题，其实这个 CAPTCHA 是可以在后台运行的，初衷之一就是为了解决需要用户交互的问题，用户开始填表单的时候就开始计算，等用户填完表单了也算完了，这时候直接提交就行，不需要输个验证码或者选个图片之类的麻烦操作

2. 这个 CAPTCHA 的核心思路是，每个请求都必须消耗一定的 CPU 资源，如果想要发起很多请求，那么就要消耗很多 CPU 资源，攻击者的成本就上去了

3. 这个 CAPTCHA 也不是什么银弹，可以一劳永逸地解决人机验证问题，它可以应付的情况仅限于恶意攻击需要发起大量请求的情况，使用场景还是有一定限制的

@Jirajine @IvanLi127 我也没想到 wasm 速度居然差这么多，测试下来也是出乎我的意料。wasm 这边是直接丢进 gmp-wasm 里面计算的，具体的计算也就是连续几百万次平方取模，看起来也没什么复杂的东西会导致两边的性能差距。现在我觉得最大的可能是原生代码可以直接利用 CPU 的指令集特性，而编译成 wasm 的 gmp 只能用乘法器和除法器死算

@mxT52CRuqR6o5 是的，这是一个弱点，不过在具体实践上可以做点额外的工作。

比如爆破某个账户，可以根据账户名，限制同一时间只能提交一个工作量证明，工作量证明提交之后，此前产生的所有工作量证明问题直接失效，这样就没法针对这个账户做并发请求了。

这个验证码其实也就是一个很基础的框架而已，最好还是结合业务的实际情况来适配一下，效果才好。

@sunshower 其实我也是受另一个 CAPTCHA 的启发，那个 CAPTCHA 用纯 hash 的方式做计算量证明，我有点怀疑它在挖矿，不过我也没细看它的源码就是了。
@zenxds 用 headless 不如直接上原生程序，速度更快。另外这个验证码的目标是过滤掉那种需要大量发送请求的用户，对于其他类型的恶意用户是无能为力的