@kkk9 是哦，都开源了还不恭恭敬敬把东西喂你嘴里，现在玩开源的人真是太把自己当回事了。

另外，什么是内容农场啊？哪里都 Copy 一遍全文才叫内容农场好吗？

yc news 、techmeme 全是外链，也是内容农场？

然后打开方式 也可以是类似于 github.dev 的方式来做 (github.dev 套的是 vscode)，例如： https://github.write.dimstack.com/user/repo

@Peiiii 很有意思，期待继续完善，视觉和交互细节更好一点，也包括大量目录和文件的时候

另外，有计划支持 github 和别的存储吗，例如 s3 ？

@Peiiii 可以提交回去吗？

@jy02534655 有没有可能把返回结果数设置为 20 条或 50 条的时候就有了呢？

还是支持一下 op ，反对这种技术行业的“官僚”主义。

@moving80kg
另外 casdoor 项目用起来小问题，这也很大程度打击我们的使用信心。这个跟需求是无关的。
原本我以为是我们的错觉，但看到 https://www.v2ex.com/t/1021725 发现同样有人提到（缺乏测试）。

再提一次之前说过的声明，如果他们出了 SAAS 服务，我觉得可以一用，因为有服务，小问题只要甩给他们就可以解决。自部署开源版本，建议慎用。

@moving80kg
1. 我没用 logto
2. 所以 8 楼和 9 楼分享了自己的判断，帮助其他人更明确需求
3. 并且受 10 楼邀请在 17 楼做了一些说明和补充
4. 然后因 18 楼的误解在 20 楼又做了说明和补充
5. 最后因 24 楼的莫名奇妙在 25 楼做了一次梳理

请问有什么问题吗？

@pseudo 我没说 Logto 和 Casdoor 简单，反而是说：我们的需求很简单，他们太复杂（然后又容易引入一些小问题）所以才决定自己写。

所以这些只和 casdoor 有关吗？ logto 是不是已经做得非常健壮、安全、完整了？是否可以支持上有自定义需求的一键登录行为了，我不知道，你知道吗？

现在 rust 都这么普及了，我们自己早就用自研的东西把 Nginx 系、dnsmasq 系这种简单的组件替代掉了，再替换掉 Redis 这种简单的工具替代掉有什么奇怪的吗？

其他的，你就别跟我扯什么耶稣上帝了，跟我没关系，跟你也没关系（你这杠真的有必要抬到把 Redis 一个简单的工具跟整个前端、机器学习这种大生态的行业强行做对比吗？）。

@cydian 本身希望非常简单地接入使用，结果还是遇到很多磕磕绊绊。实际使用之后发现整体比较复杂，比较难在短时间搞熟。另外也不排除有一些小问题小 bug ，我们自己还修改了代码，这个时候已经有了一些不满（原本就是为了自己可以不亲自处理这方面的东西），但由于使用场景目前也非常简单，自己修了 2 个 bug 后倒也相安无事，就继续用。

后在使用其他服务需要用到一键登录的需求时，发现又不能直接使用（结果还得自己写了个中转接口）。最后痛定思痛，觉得因为想解决一个小问题引入了一套复杂的东西实在得不偿失，而且连最初的目的都达不到（成为账户中心，方便接入）。
@xiaohanyu 我们也是在自己修了几个小 bug 之后其实也是真切体会到，这套东西实际真的很简单，但之前被一个个的名词和一套套的协议给吓到了。本质就是一个特别简单的东西，不值得引入复杂的不确定性因素。当然使用云服务，有专业支持的话，问题可能不大。现在自己写了，接入什么都很容易实现，灵活度和可靠性大大提高。

@wuyuandev 用了 casdoor 之后也坚定了自己写的决心。

这些年用了很多，真的就是 Framer 最好用了。
如果想导出代码只是为了（自部署）加速，可以用我们的 Framer 加速服务。
如果导出代码是强需求，可能就是 webflow 。

欢迎用我们的服务来优化 Framer 在大陆地区的速度： https://framer.bitiful.com/

支持楼主去抗争啊，联通这种做法这也太鸡贼了，合同宽松，执行严格。
最好是告上公堂，然后弄个新闻热点出来，倒逼运营商搞搞把合同弄得清清楚楚、严严格格的。
不然那些 PT 和 PCDN 的蛀虫太猖獗了。

@franklight 自动的。

@lee88688 因为国内使用的大模型都要备案的啊，不备案某种程度上就是违法啊。你这直接通过中间服务绕过管制在国内使用国外的大模型肯定封你啊。

@stoneabc 我们最终的目的是发布一个类似 cdnperf.com 和 cloudperf.com 的长期观测项目来跟踪。不过你认为应该如何测试，我们也希望可以改进。
@justfindu 这个确实是第一次听说，会了解一下（之前只知道不同运营商会有这种行为）
@x86 我们用阿里云监控从多地区多线路测的，并且我们的测的是对象存储，不是主机，没有测回程的能力。

@R18 有可能啊，我们会长期跟踪。然后为什么会有这些差距，比较复杂，我们会单开一篇来说网络层的原因。
@Greenm
1. 我们没有想当裁判，只是发布我们的数据观察；
2. 测试周期也不会仅一周，会每周或每月持续观察和发布；
3. 不太懂，国内的对象存储为何要用海外节点测呢？
4. TTFB 你可以不在意，但不妨碍它是评判 http 性能的最重要指标之一；
5. 我们正式运行不到 4 个月，但公测运行了近 2 年，仍然没有发布 SLA ；
6. 但我们做这些跟踪和观察的目的恰恰就是通过连续跟踪到的指标，来先行实践我们的可靠性，为 SLA 提供说服力。我们对 SLA 很谨慎也很尊重。
7. 我们的可用性看板 https://stack-status.com/ 是完全独立的架构（包括域名），并且国内其他公有云都是手动。
8. 我们确实是草台班子，但我们对技术的态度是敬畏的。
@gxt92 那应该怎么测试呢？
@hallomou 不知道该怎么说，因为我知道华为技术非常非常强，而你也看到了，上面有人觉得这种测试方法很扯。肯定有需要改进的地方。