返回首页
最新
大家好！npm-daycare 是一个基于 Verdaccio 构建的简单 NPM 代理，它会过滤掉以下所有包：<p>- 发布不超过 48 小时的包（它会提供一个旧版本）<p>- 每周下载量少于 5,000 的包<p><a href="https://github.com/stack-auth/npm-daycare" rel="nofollow">https://github.com/stack-auth/npm-daycare</a><p>这是为了应对最近破坏 JavaScript 生态系统的供应链攻击 [1]。这个问题可能不会很快消失，因此我们决定构建一些东西来防范它。<p>在代理层面上进行此操作意味着它将在整个系统中工作，因为代理是全局设置的。未来，我们还可以为代理添加更多过滤器。<p>要开始使用，只需运行 Docker 容器：<p><pre><code> docker run -d --rm --name npm-daycare -p 4873:4873 bgodil/npm-daycare
npm set registry http://localhost:4873/
pnpm config set registry http://localhost:4873/
yarn config set registry http://localhost:4873/
bun config set registry http://localhost:4873/
npm view @types/node # 有最近的更新
npm view pgmock # 每周下载量 < 5,000
</code></pre>
缺点：在默认配置下，npm-daycare 不会显示发布不超过 48 小时的包，因此在尝试更新包以修补零日漏洞时请注意这一点。<p>你可能也不应该将其作为唯一的防御手段。期待听到你的想法！<p>[1] <a href="https://news.ycombinator.com/item?id=45260741">https://news.ycombinator.com/item?id=45260741</a>
我公司最近发布了一个招聘职位，结果收到了大量由人工智能生成的申请者。我们遇到了404个LinkedIn个人资料，几乎是已知真实申请者的复制品，还有缺席面试、人工合成的声音，真是应有尽有。然而，假简历往往很难与真实简历区分开来。大家都在使用什么策略来筛选假申请者呢？我希望能采取一些难以被人工智能规避的措施，但又不想给真实求职者带来负担，因为我意识到许多人急于找工作，采取了广撒网的方式，甚至一个小任务可能就会将他们排除在外。
连接点滴：<p>* 语法不完美的人更可能使用人工智能在社交媒体上写作。<p>* 也许这些人并不是以英语为母语，因此更可能属于少数群体——所以对他们使用人工智能感到不满是种种族主义。<p>* 也许这些人的教育程度或智力水平不如语法完美的人——所以对他们使用人工智能感到不满是种精英主义。<p>人们总是根据你的语法来评判你。人工智能消除了这一信号，这就是人们感到不满的原因。
非常希望能得到任何反馈。
我是一个独立开发者，想分享最近的一个经历，作为关于当前App Store和独立开发状态的案例研究。
几个月前，我开发了一个简单的macOS工具，旨在解决我个人的一个困扰：在Mac菜单栏中验证USB-C电缆和设备的实际速度。这个应用叫做USB连接信息，支持macOS 13及以上版本。在发布之前，Mac App Store中没有其他类似的应用。这个应用意外地成功，进入了付费实用工具的前100名，并获得了相当不错的自然曝光。
在过去的两周里，至少有五个几乎完全相同的应用出现在App Store上。令人担忧的是，这些克隆应用中有一些复制了我的App Store描述，包括我关于为什么开发这个应用的个人故事。
在GitHub上也出现了一些开源克隆，我认为这是社区的积极贡献。但我担心的是那些在App Store上进行抄袭的商业克隆。
这引发了我几个问题，我很想听听HN的看法：
我在Reddit上对我的成功保持透明。大型语言模型（LLMs）在多大程度上降低了进入门槛，让其他人能够在几天内复制一个经过验证的想法和市场文案，生成一个功能性克隆？
看起来，带有抄袭描述和应用元素的衍生应用正在毫无问题地获得批准。这是否意味着App审核的方向发生了变化？
我的应用的价值在于其简单性。在一个简单且成功的想法可以如此快速复制的环境中，竞争壁垒是什么？是品牌、创新速度、市场营销，还是其他什么？
期待听到你们的看法。
过去几年，跨平台桌面应用程序的现状主要依赖于 Electron，但这也意味着每个应用几乎都要捆绑一个 Chromium，这并不是理想的解决方案。那么，为什么我们不开发一个类似于 Linux 中的 glibc 或 Windows 中的 DirectX 的 libchrome 呢？想象一下，如果每个游戏都要捆绑自己的 DirectX 版本，那将会是什么样子。我想，主要的障碍在于稳定性，glibc 的变化不大，但 Chrome 却在不断变化。不过，我觉得通过维护一个长期支持（LTS）版本的库，这个问题是可以轻松解决的。之前有人提出过这个想法吗？Chromium 作为一个引擎，是否与 Chrome 作为桌面应用的逻辑耦合过于紧密，以至于无法将其作为库进行发布？