最新

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

好的，如果你运营一个自托管的博客，你可能已经注意到一些人工智能公司在抓取你的内容作为训练数据。而且并不是少量（愿你的服务器账单安息）。 如果没有Cloudflare，你几乎无能为力。这些公司会忽视robots.txt，而你正在与资源比你丰富的团队竞争。这就像你在与编程界的巨头对抗，你是无法赢的。 但还是有解决方案的。现在我不会说这是一个很好的解决方案……但解决方案就是解决方案。如果你的网站包含能够触发他们抓取器保护机制的内容，那么这些内容就会被从他们的数据管道中剔除。 那么，fuzzycanary的作用是什么呢？它会在你的HTML中注入数百个指向色情网站的隐形链接。这些链接对用户是隐藏的，但在DOM中存在，以便抓取器可以抓取这些链接，并表示“好的，我们以后不会再抓取这里了”。 这种方法的问题在于，它会严重影响你网站的SEO。因此，fuzzycanary还会检查用户代理，并不会将这些链接展示给合法的搜索引擎，这样Google和Bing就看不到它们。 有一个警告：如果你使用静态网站生成器，它会将这些链接嵌入到所有人的HTML中，包括googlebot。有没有人有不涉及使用代理的解决办法？ 请试试看！设置只需一个组件或一个导入。 （别告诉我这是个糟糕的主意，因为我已经知道了） 包： [https://www.npmjs.com/package/@fuzzycanary/core](https://www.npmjs.com/package/@fuzzycanary/core) GitHub： [https://github.com/vivienhenz24/fuzzy-canary](https://github.com/vivienhenz24/fuzzy-canary)

嗨，HN， 我是拉尔夫。我拥有软件开发学位，在过去的15年里，我一直从事网站开发和搜索引擎优化（SEO），最近6年经营着一家代理公司。 几年前，我意识到人工智能可以在自动化我们代理公司许多初级SEO任务和手动工作方面发挥作用。我详细列出了我们的流程，绘制了人工智能可以发挥作用的领域，并开始将其整合。 这创造了一个基于人工智能的SEO平台，能够自动化关键词研究、元标题/描述、图片替代文本和页面级内容，并配备审批工作流和基于令牌的使用。我还在探索链接建设、全面技术审计和人工智能生成的推荐修复的自动化。 最大的挑战之一是管理上下文相关性，给系统提供足够的信息以全面理解一个网站，同时又不至于让模型感到不堪重负或稀释相关性。 该平台目前处于测试阶段，但我在继续追求“完美”和专注于尽早分享、让真实用户引导实际需求之间感到矛盾，因此我在这里寻求反馈。 我非常感谢任何见解，特别是关于这个平台在工作流程中适合或不适合的地方、对返回响应质量的反馈，以及可能导致采用时出现摩擦的任何因素。 为了在测试阶段保持成本可预测，用户可以使用令牌支持的工作区测试100页或更少的网站。

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