最新

我编写了一个小型 Linux 工具，用于确定性地验证 GPU PCIe 链路的健康状况和带宽。<p>它会报告： - 协商的 PCIe 代数和宽度 - 主机→设备和设备→主机 memcpy 的峰值带宽 - 通过 NVML 获得的持续 PCIe TX/RX 利用率 - 仅从可观察到的硬件数据得出的基于规则的判断<p>之所以开发这个工具，是因为 PCIe 问题（代数降级、通道宽度减少、转接卡、分叉）通常在应用程序层是不可见的，并且无法通过内核调整或异步重叠来修复。<p>仅限 Linux：它依赖于 sysfs 和 PCIe AER 暴露，而 Windows 并不提供这些。

好的，如果你运营一个自托管博客，你可能已经注意到 AI 公司正在抓取你的博客数据用于训练。而且抓取的量还不小（你的服务器账单要哭了）。 如果没有 Cloudflare，你对此无能为力。这些公司会无视 robots.txt 文件，而你正在与拥有比你更多资源的团队竞争。这是你 vs 编程界的“MJ”（指那些大公司），你赢不了的。 但有一个解决方案。我不会说这是一个好方案……但有总比没有好。如果你的网站包含的内容会触发他们的抓取程序的安全措施，它就会从他们的数据管道中被删除。 所以 fuzzycanary 的作用是：它在你的 HTML 中注入数百个指向色情网站的隐形链接。这些链接对用户是隐藏的，但在 DOM 中存在，以便抓取程序可以抓取它们并说“不，我们将来不会再抓取那里了”。 这种方法的问题在于它绝对会毁掉你网站的 SEO。所以 fuzzycanary 也会检查用户代理，并且不会向合法的搜索引擎显示这些链接，因此 Google 和 Bing 也不会看到它们。 一个警告：如果你使用静态网站生成器，它会将这些链接嵌入到你的 HTML 中，供所有人使用，包括 Googlebot。有人有解决这个问题的方法吗？不需要使用代理的那种？ 请试一试！设置只需要一个组件或一个导入。 （别告诉我这是个糟糕的主意，因为我已经知道了） 包：<a href="https://www.npmjs.com/package/@fuzzycanary/core" rel="nofollow">https://www.npmjs.com/package/@fuzzycanary/core</a> GitHub: <a href="https://github.com/vivienhenz24/fuzzy-canary" rel="nofollow">https://github.com/vivienhenz24/fuzzy-canary</a>

大家好，我是拉尔夫。我拥有软件开发学位，过去 15 年来一直从事网站开发和 SEO 工作，其中最近 6 年经营着一家机构。 几年前，我意识到人工智能可以用于自动化我们机构的许多初级 SEO 任务和手动工作。我详细阐述了我们的流程，绘制了人工智能可以发挥作用的领域，并开始将它们全部整合起来。 由此创建了一个 AI 驱动的 SEO 平台，该平台可以自动化关键词研究、元标题/描述、图片 alt 文本和页面级内容，并带有审批工作流程和基于 token 的使用方式。我还在探索自动化链接建设、全面的技术审核以及 AI 生成的修复建议。 最大的挑战之一是如何管理上下文相关性，为系统提供足够的信息以全面了解网站，同时又不会让模型过载或稀释相关性。 该平台目前处于 Beta 测试阶段，但我一直在纠结是继续朝着“完美”的方向努力，还是把精力放在尽早分享它，让真正的用户来指导真正重要的东西，所以我来这里征求反馈意见。 我非常感谢任何见解，特别是关于这个平台是否适合以及如何融入工作流程，对返回结果的质量的反馈，以及任何可能阻碍用户采用的因素。 为了在 Beta 测试期间保持可预测的成本，用户可以使用一个 token 预置的工作区进行测试，适用于 100 页或更少的网站。

好吧，我当然尝试了。我必须这样做，因为它有一个受“数字极简主义”启发的特定特性。 这个特性是它每天（或每 X 天）只允许你获取一次新文章。 为什么？让我来解释一下... 我希望我的互联网内容像一份无聊的报纸。你早上拿到它，一边喝着早晨的咖啡，一边读完所有内容，然后就结束了！今天不再有新的信息了。没有提示，没有警报，平静，安静，禅意等等。 但有了这个，我需要它能够一次性从我数百个订阅源中获取所有文章。这就是 Zig 和 curl 优化发挥作用的地方。我尝试了所有能想到的技巧。如果我遗漏了什么，请告诉我！ 首先，我在网络层使用了 curl multi。很酷的是它会自动进行 HTTP/2 多路复用，这意味着如果你的订阅源托管在同一个 CDN 上，它会重用相同的连接。我已将其配置为总共处理 50 个连接，每个主机最多 6 个连接，这似乎是服务器开始变得可疑之前的最佳点。此外，还有条件 GET。如果订阅源自上次以来没有更改，服务器只会说“未修改”，我们立即退出。 当 curl 正在下载订阅源时，我不希望 CPU 闲置，所以当 curl 完成下载单个订阅源时，它会触发一个回调，立即将 XML 扔进一个工作线程池进行解析。主线程继续管理所有网络事务，而工作线程并行处理 XML。Zig 的内存模型非常适合这个。每个订阅源都有自己的 ArenaAllocator，它基本上是一个游乐场，你可以在解析期间分配字符串，然后当我们完成时，我们只需一次性清除整个 arena。 对于解析本身，我正在使用 libexpat，因为它不会像 DOM 解析器那样将整个 XML 加载到内存中。这很重要，因为一些播客订阅源尤其是 10MB+ 的 XML。因此，通过智能截断，我们下载前几个 X mb（可配置），向后扫描以找到最后一个完整的 item 标签，在那里截断它，然后只解析它。即使订阅源大小变得很大，也能保持内存使用量合理。 对于 UI，我只是将所有内容管道到系统的“less”命令。你可以免费获得 vim 导航、搜索和分页。此外，我正在使用 OSC 8 超链接，因此你实际上可以单击链接以在浏览器中打开它们。不需要任何 TUI 框架。我还包括了 OPML 导入/导出和订阅源组作为附加功能。 结果：在几秒钟内从数百个 RSS 订阅源中检索内容，并且在一天剩下的时间里安心。 代码是开源的，并获得 MIT 许可。如果你有关于如何使其更快或更好的想法，请在下面评论。也欢迎在此处或 GitHub 上提出功能请求和其他建议。