最新

供应链攻击的数量及其造成的影响范围正在不断增加。主要的罪魁祸首是那些不仅仅是编程语言的生态系统，这些生态系统中本应“自带电池”的内容，最终却堆积成一大堆没人愿意审查的库和模块。 这种情况无法扩展。让所有潜在用户审查这些代码无疑是在自找麻烦，绝大多数人最初就没有资源来编写这些模块/库，因此他们很可能也没有资源去审查他们所使用的所有内容。 我试着想象一下，如果Linux不只有一个发行版，而是有几千个，每一个都有可能在瞬间变得恶意，这在长远来看是行不通的。所有这些系统只能在没有恶意行为者、并且你可以隐含信任源头的世界中运作。 请改善内容的策划。下一个供应链漏洞很可能会是“重大漏洞”，而我相当确定，随着概念验证的增多，各国政府正在努力实现这种能力。我们需要更少的分发点，提供更好的策划，并在纳入之前进行更严格的审查，类似于Linux内核的做法。 我们不需要这种疯狂的高发布速度，整堆代码每天都在更新。你应该放慢速度，做好质量保证。 可靠性来自于投入时间进行审查和增加理解的能力，而不是来自于以惊人的速度发布的能力。不要把下游当作质量保证的工具，等到出错后再去修复。如果今天编写的代码，世界明天甚至后天都不需要。开发环境到发布的“快速通道”也有可能将任何环境的妥协导出到你的发布版本中，尤其是当你接受外部对代码的贡献时。

我尝试过Reddit、Instagram和Product Hunt，但效果不太好。有什么建议吗？

作为一个没有编程背景的人，我想知道是否有人有一些建议，可以在使用Claude代码时减少AI的错误。同时，我也对其他AI编程工具的使用案例持开放态度。

你是否曾经打开 tmux，担心自己数十个会话都在占用内存……更糟的是，如果某个插件失败，它们可能会消失？<p>我曾经使用 tmux-resurrect 和 tmux-continuum 多年。它们“能用”，但：<p>- 会话有时会完全消失<p>- 当会话数量较多时，所有内容都保留在内存中<p>因此我开发了 Lazy Tmux： https://lazy-tmux.xyz<p>它将所有会话以树状结构展示——就像它们已经存在一样——但只有在你进入时才会真正加载它们。<p>- 保持数十个会话而不占用过多内存<p>- 快速导航大型会话层级<p>- 懒加载窗格、命令、shell 和滚动历史<p>目前还处于早期阶段，GitHub 上有许多未解决的问题。欢迎反馈、想法或贡献： https://github.com/alchemmist/lazy-tmux<p>如果你曾经在 tmux 会话管理中挣扎过，这可能会让你的工作流程更加顺畅。