最新

不久前收到了这封邮件： 从 2026 年 10 月 1 日开始，Microsoft Publisher 将不再作为 Microsoft 365 的一部分提供支持。许多 Publisher 的常见应用场景都可以在其他 Microsoft 365 应用中使用，包括 Microsoft Word 和 PowerPoint。 建议采取的行动：在 2026 年 10 月 1 日之前，将您现有的 Publisher 文件转换为 PDF 或 Word 格式。在此日期之后，您将无法再使用 Microsoft Publisher 打开或编辑这些文件。 这家公司真是太疯狂了。 接下来我们该怎么办？Affinity？InDesign？Quark？Scribus？

我每天都看到有人为了在 HN 上发帖而建网站，而且这些网站的内容全是 AI 生成的。网站、文字、想法，都是 AI 弄出来的。显然，这个人最初是有想法的，但执行起来却很粗糙。 这些人把自己的名字署在这些东西上，而现在全世界的人都在学习辨别 AI 写作的特征。语气、抽象程度、特定的措辞，我们都清楚。这让人反感。 所以我的想法很简单：自己写文案。这现在是一种优势。在今天，这变得越来越稀缺。做真实的自己。无论这对你来说意味着什么。

首先，让我先说明一些问题。<p>强制披露：为了证明这并非又一个用 LLM 搞出来的垃圾项目，我曾为 SciPy 做过类似的工作，并手动翻译了 ARPACK、PROPACK、QUADPACK、ODEPACK 以及其他一些软件包（完整的列表请参见 <a href="https:&#x2F;&#x2F;github.com&#x2F;scipy&#x2F;scipy&#x2F;issues&#x2F;18566" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;scipy&#x2F;scipy&#x2F;issues&#x2F;18566</a>，约 85K 行代码），当时 LLM 还不擅长这类工作。大多数翻译已经在之前的 SciPy 版本中发布，因此我希望这能为 F77 -&gt; C11 的翻译工作提供可信度。现在 LLM 稍有进步，对于 LAPACK 的翻译，我使用了 Claude Code 作为助手来完成某些任务。以上是免责声明。<p>-------- 现在我们回到正题。<p>这是对古老的 Fortran77 线性代数库 LAPACK 的 C11 翻译版本。如果您无法承担或不想依赖 Fortran，这个项目可能会有所帮助。它完全使用 CBLAS 接口，以避免影响其他供应商的符号命名问题（大小写、有无尾随下划线等）。有点争议的是，翻译从内部开始使用 0 索引，除了错误代码。不幸的是，`info = 0` 表示成功，所以我们对此无能为力。<p>目前的测试覆盖率：LAPACK 自己的测试套件（45 万个参数化测试，也映射到 C）、NumPy 测试套件和 SciPy 测试套件都通过了。至少在最常见的算法中，它是可靠的。对于覆盖较少的算法，仍然可能存在错误，因此我目前将其标记为 alpha 版本。但如果您发现任何问题，请在仓库中提交 issue。<p>此外，这使得为您的机器或任何需要运行的地方编译 OpenBLAS 和 LAPACK 变得更加容易，并启用了架构优化，而且它具有更精简的二进制文件大小。<p>如果您也想要一个即插即用的替代方案，还提供了一个 fortran-shim，它将把包装器转换为 1 索引（这就是我测试 NumPy/SciPy 的方式），但会带来一些性能损失。<p>如果您不喜欢默认设置，您还可以使用前缀和后缀来随意修改符号名称。ILP64 也受支持，如果您尝试与 ILP64 CBLAS 链接，如果它被意外链接，它会报错，或者如果您提供了标志，它会为您处理问题。<p>出于某种原因，Netlib 上 doxygen 版本的文档总是让我觉得不舒服；因此我尝试了我的版本。在这里：<a href="https:&#x2F;&#x2F;ilayn.github.io&#x2F;semicolon-lapack&#x2F;" rel="nofollow">https:&#x2F;&#x2F;ilayn.github.io&#x2F;semicolon-lapack&#x2F;</a><p>我特别想经常看到的一个细节是同时看到所有四种风格；现在它们被这样分组 <a href="https:&#x2F;&#x2F;ilayn.github.io&#x2F;semicolon-lapack&#x2F;api&#x2F;linear-systems&#x2F;symmetric-indefinite&#x2F;sytrf.html" rel="nofollow">https:&#x2F;&#x2F;ilayn.github.io&#x2F;semicolon-lapack&#x2F;api&#x2F;linear-systems&#x2F;...</a> 如果我失败了，请告诉我，我仍在探索细节。例如，默认字体肯定需要改进。<p>为了避免无益的讨论，有几点说明：<p>- Fortran 没有任何问题。如果您喜欢它，请继续使用它。虽然我不是，但我很喜欢 Fortran77 及其所处的时代，但对所谓的现代版本不太感冒。 - 这项工作与 Fortran 无关。它试图服务于特定受众，他们专门使用 C 工具链，并且不希望出现跨语言问题。 - 这项工作希望吸引更多人来优化 C 代码，以造福大众。<p>文档中给出了更多理由。<p>欢迎所有反馈/批评。

我最初是在 Chrome 上看到的，决定在 Safari 上测试一下。结果数据非常相似。<p>我还把它和 Facebook 做了对比，刻意滚动 5 分钟，最多消耗了 650 MB，平均大约 400 MB。<p>有没有 Web 开发者能解释一下 LinkedIn 和 Facebook 之间如此巨大的差异？看起来信息流中的视觉信息量几乎相同，但 LinkedIn 却占用了 5-7 倍的内存。<p>我查了一下，Facebook 使用 React 和虚拟 DOM，而 LinkedIn 使用 Ember（以前从未听说过）。难道仅仅是因为 Facebook 在不再需要 JavaScript 对象时，能更好地动态清除它们吗？