土耳其能源部长阿尔帕斯兰·巴伊拉克塔表示，土耳其没有计划向美国出售其新发现的稀土元素。位于埃斯基谢希尔省贝利科瓦的这一重要矿藏——全球第二大——将由国有企业埃蒂矿业公司完全开发和运营。 目前正在计划建设一座稀土加工厂，预计明年奠基，并在两年内完成。该过程将包括露天采矿，并生产氟石和钍等副产品，以及放射性废物储存设施。 土耳其目前的提纯度为92-93%，旨在提高这一水平。尽管与中国签署了合作协议，以推进采矿业，尤其是在稀土元素方面，但部长明确表示，稀土元素不会出售给美国。一个试点设施已经投入运营，并将进行扩建。
每日HackerNews RSS
## 土耳其与美国稀土元素：摘要
一份近期报告声称土耳其不会向美国出售稀土元素，引发了 Hacker News 的讨论。然而，多位评论员指出原始来源曲解了该声明。一位土耳其官员澄清，土耳其与美国之间没有*达成*出售稀土元素的协议，这与一份双方都会公开声明的核相关协议形成对比。
讨论迅速扩大到地缘政治影响。许多评论员对美国的对外政策表示怀疑，并质疑可靠“盟友”的概念。人们对土耳其日益独立的立场、其与俄罗斯和中国之间的关系，以及其对北约集体防御的潜在影响，特别是关于获取军事装备关键资源方面，表示担忧。
一些人主张将土耳其从北约中移除，而另一些人则为其战略重要性辩护，特别是其对博斯普鲁斯海峡的控制。总体情绪表明，随着全球力量动态的转变，不信任感日益加剧，并正在重新评估联盟关系。
启用 JavaScript 和 Cookie 以继续。
最近对1.8亿个工作岗位的分析表明，尽管人们担心被广泛取代，但在人工智能时代，软件工程仍然是一个令人惊讶的稳定职业。虽然人工智能编码工具正在获得进展，但Hacker News上的评论员指出，使用人工智能*需要*软件工程技能，本质上使得人工智能的使用者，本身就是软件工程师。
其论点是，目前需要软件工程师来*构建*将自动化其他工作的AI工具，从而确保未来10-15年的需求。此外，人工智能*增加*公司收入的潜力通常超过完全自动化软件开发岗位的成本节约。本质上，人工智能足以提升“营业额”，以证明保留工程师的合理性。
## 通往安全的25年之路 俄勒冈州罗德花附近的一段长1.26英里的危险的26号美国公路，事故和死亡事件频发，引发了为期25年的关于一项简单安全改进的斗争：增加左转车道。1998年，居民请愿进行升级，理由是由于众多车道直接连接繁忙的公路，存在超过650个安全隐患。 最初的计划立即面临反对，这源于迈克尔·P·琼斯，他一再声称该地区存在未记录的美国原住民墓地——这一指控被考古学家多次驳斥。尽管多次调查证实没有历史意义，琼斯和不断更换的代表仍然坚持要求根据《国家历史保护法》进行进一步审查，从而使该项目延误了几十年。 俄勒冈州交通部门（ODOT）于2007年完成了环境评估并批准了道路拓宽，但诉讼一直持续到2023年。在延误期间，事故持续发生，导致受伤，甚至至少一人死亡。最终，左转车道建成，但这一事件凸显了冗长的环境和历史保护程序，即使面对压倒性的安全问题，也可能极大地延误重要的基础设施改进——付出巨大的时间、金钱和生命代价。
黑客新闻 新 | 过去 | 评论 | 提问 | 展示 | 招聘 | 提交 登录
罗德花路口的转弯车道 (greentape.pub)
9 分，由 apsec112 1小时前发布 | 隐藏 | 过去 | 收藏 | 1 条评论
geophph 24分钟前 [–]
“不可能这是关于去胡德山路上罗德花的路口”…确实是。回复
考虑申请YC冬季2026批次！申请截止至11月10日
指南 | 常见问题 | 列表 | API | 安全 | 法律 | 申请YC | 联系
搜索：
开源替代Open WebUI – 类似ChatGPT的UI、API和CLI
OSS Alternative to Open WebUI – ChatGPT-Like UI, API and CLI
2 小时前
## llms.py：你的私有离线LLM中心
llms.py是一个轻量级、单文件的Python应用程序，提供类似ChatGPT的界面来访问多个大型语言模型（LLM），完全离线并保持你的数据私密，通过浏览器存储实现。它支持超过160种LLM，包括本地模型（通过Ollama）和远程API（OpenRouter, OpenAI, Google, Groq等）。
**主要特性：**
* **多提供商支持：** 无缝集成各种LLM提供商。
* **离线访问：** 本地运行，确保数据隐私。
* **OpenAI兼容性：** 与任何支持OpenAI API的客户端兼容。
* **智能路由：** 根据模型支持和定义的优先级（成本、本地偏好）自动选择最佳可用提供商。
* **多功能输入：** 处理文本、图像和音频。
* **可定制：** 通过`llms.json`配置提供商、模型和聊天模板。
* **CLI & 服务器模式：** 提供命令行界面和OpenAI兼容的HTTP服务器。
* **Docker支持：** 通过Docker和Docker Compose轻松部署。
**开始使用：**
使用`pip install llms-py --upgrade`安装。将API密钥配置为环境变量或在`llms.json`中配置。使用`llms "你的提示词"`运行。对于服务器，使用`llms --serve 8000`。Docker简化了各种架构的部署。
更多详细信息和定制选项可在[GitHub仓库](https://github.com/ServiceStack/llms)中找到。
Hacker News 新闻 | 过去 | 评论 | 提问 | 展示 | 招聘 | 提交 登录
Open WebUI 的开源替代方案 – 类似 ChatGPT 的 UI、API 和 CLI (github.com/servicestack)
14 分，mythz 发表于 2 小时前 | 隐藏 | 过去 | 收藏 | 3 条评论
kosolam 发表于 22 分钟前 [–]
Openwebui 也是开源的，不是吗？回复
mythz 发表于 18 分钟前 | 父评论 | 下一个 [–]
他们已经改用自定义许可协议来阻止竞争性分支 [1]，用他们自己的话说 [2]：
[1] https://www.reddit.com/r/opensource/comments/1kfhkal/open_we...
[2] https://docs.openwebui.com/license/
brazukadev 发表于 5 分钟前 | 父评论 | 上一个 [–]
有野心的人总是会努力奋斗
考虑申请 YC 2026 冬季批次！申请截止日期为 11 月 10 日
指南 | 常见问题 | 列表 | API | 安全 | 法律 | 申请 YC | 联系方式
搜索：
这个 Rust 项目展示了三种不同的光线追踪实现：基于 CPU 的渲染器、离线 GPU 渲染器和实时交互式 GPU 光线追踪器。
**CPU 光线追踪器** 执行软件渲染，将场景输出到 PPM 图像文件。**GPU 光线追踪器** 利用计算着色器实现显著更快的渲染速度，达到与 CPU 版本相当的质量，同样输出到 PPM。
最后，**实时 GPU 光线追踪器** 提供实时、交互式体验，具有相机控制。用户可以在具有光照/阴影的完整光线追踪和法线可视化调试模式之间切换。
所有版本都支持网格 (.obj) 和球体图元，GPU 版本需要兼容的 GPU（Vulkan、Metal 或 DirectX 12）。该项目使用最新的稳定 Rust 版本构建，并为每种实现提供清晰的构建/运行说明。 还有一个实时、基于 Web 的演示。
一位名为tchauffi的开发者创建了一个基于Rust的光线追踪器，它既可以在本地运行，也可以通过WebAssembly和wgpu图形库直接在浏览器中运行。该项目受到Sebastian Lague的作品启发，能够渲染具有网格渲染（由BVH加速）和通过直接和间接照明实现逼真光照的3D场景。
该光线追踪器作为一个免费的网页演示托管在GitHub Pages上([https://tchauffi.github.io/rust-rasterizer/](https://tchauffi.github.io/rust-rasterizer/))，源代码在GitHub上([https://github.com/tchauffi/rust-rasterizer](https://github.com/tchauffi/rust-rasterizer))。该开发者正在寻求具有wgpu、光线追踪或Rust图形编程经验的人的反馈，并计划未来探索使用Rust进行机器学习项目。
## pgvector：炒作之外
pgvector 提供了一个引人注目的想法——利用现有的 Postgres 基础设施进行向量搜索，但其生产就绪程度往往被高估。许多教程展示了简单的演示，掩盖了重大的扩展挑战。
主要问题包括复杂的索引管理（IVFFlat 与 HNSW，各有优缺点）、内存密集型索引构建可能扰乱生产数据库，以及难以在持续数据摄取的情况下保持实时搜索。更新需要仔细规划，以避免停机或性能下降。
此外，使用过滤器优化查询（对于实际应用至关重要）需要深入的 Postgres 专业知识，因为查询计划器难以处理向量特定的成本。混合搜索（结合向量和文本搜索）需要自定义实现。
虽然 Timescale 的 pgvectorscale 等解决方案解决了一些问题，但它们增加了复杂性。专用向量数据库（Pinecone、Weaviate 等）提供诸如智能查询计划、内置混合搜索和可扩展的实时索引等优势——在考虑工程时间和基础设施开销时，通常具有可比或更低的总体成本。
最终，pgvector 是一个有用的扩展，但团队应仔细权衡其操作复杂性与专用向量数据库的优势。
一篇 Hacker News 的讨论围绕着名为“PGVector 的反对理由”的文章，PGVector 是 PostgreSQL 的向量嵌入扩展。尽管文章提出了担忧，但评论者普遍认为 PGVector 具有实用性。
多位用户报告称已成功在生产环境中大规模使用 PGVector（Discourse 利用它服务数十亿页面浏览量），并强调了迭代扫描等改进，解决了性能问题。一个关键论点是尽量减少服务复杂性（“YAGNI”原则）——坚持使用 PostgreSQL 可以避免运营开销和由独立向量数据库造成的数据孤岛。
有人担心专用数据库的可扩展性限制和厂商锁定，并将其与 PostgreSQL 的稳定性和持续改进形成对比。最后，有人指出，即使在更大的语言模型上下文窗口出现后，向量数据库也不会消失；索引仍然比重新处理整个数据集更有效，即使注意力机制有所进步。
该项目旨在创建一个完全可运行的 Linux 系统，该系统可以在 Web 浏览器中执行，并使用原生 WebAssembly (Wasm)。它通过将 Linux 内核 (6.4.16)、musl libc (1.2.5) 和 BusyBox (1.36.1) 编译为 Wasm 来实现，同时使用修补后的 LLVM 工具链 (18.1.2) 实现 Wasm 链接。 该脚本支持在主机上或在 Docker 容器中构建和运行该系统（提供了基础构建环境和隔离的构建过程）。关键修改包括用于 Wasm 架构支持和 Wasm 控制台的内核补丁，以及允许 musl 和 BusyBox 与 Wasm 工具链编译的修改。 创建了一个最小的 initramfs 来启动系统进入 shell。一个基本的 JavaScript 运行时演示了如何托管 Wasm Linux 环境。请注意，由于 Wasm 的限制，Linux 系统以 NOMMU 配置构建。该项目包含一个 `linux-wasm.sh` 脚本，用于管理下载、构建和使用。
## Linux 内核对 WebAssembly (WASM) 的支持
一个新项目旨在将 WebAssembly (WASM) 架构支持直接引入 Linux 内核。这种方法将二进制文件编译为 WASM，并将每个进程作为 WebWorker 运行，将内核 ABI 作为 WASM 导出函数公开——无需 ISA 模拟层，可能为完整系统环境带来显著的性能提升。
讨论的重点在于这与现有解决方案（如 `container2wasm`，使用模拟）的比较，以及它最终提升 WASM 采用率的潜力，目前 WASM 的采用受到文档不足和速度问题的阻碍。用户正在测试演示，并注意到其快速的加载时间。
进一步的讨论涉及安全考虑——建议浏览器标签应具有类似 SELinux 的上下文——以及由于其更清晰的输出而使用 Rust 进行 WASM 编译的好处。该项目仍处于早期阶段，对新发现的错误进行测试是下一步的关键。
## 海鱼幼体瓶颈：海鲜的未来
鳀鱼、沙丁鱼和鲱鱼——曾经丰富的“海鱼幼体”，构成了太平洋食物网的基础——现在却被大量研磨成鱼粉，用于饲养鲑鱼和虾等养殖海鲜。这种做法虽然促进了水产养殖业的发展，却造成了一种危险的悖论：我们正在剥夺海洋的基础来*构建*其表面，威胁着野生生态系统和长期的粮食安全。
最近鳀鱼种群的崩溃，与过度捕捞和海水变暖有关，这表明了其脆弱性，导致了海鸟和海豹的大规模饥饿，以及渔民的经济困难。认识到这种“海鱼幼体瓶颈”，诸如F3挑战等倡议正在激励替代鱼饲料的创新。
新的突破正在出现——从植物性混合物和藻类衍生的omega-3脂肪酸到昆虫和细菌蛋白——为野生捕捞鱼类提供了可行的替代品。这种转变不仅仅是寻找替代品；而是关于重新构想营养，类似于农业革命。开源合作和潜在的“无鱼饲料”标签正在进一步推动这一变革。
最终，确保海鲜的未来——以及养活不断增长的全球人口——取决于减少我们对野生海鱼幼体的依赖，并拥抱可持续的创新饲料解决方案，从而使海洋和水产养殖业都能蓬勃发展。
Hacker News 新闻 | 过去 | 评论 | 提问 | 展示 | 招聘 | 提交 登录
养殖海鲜的问题 (nautil.us)
17 分，由 dnetesn 42 分钟前发布 | 隐藏 | 过去 | 收藏 | 2 条评论
datadrivenangel 12 分钟前 | 下一个 [–]
为了喂养鱼类，对野生蛋白的需求非常强烈，以至于南极洲周围存在磷虾盗窃行为！https://apnews.com/article/whales-antarctica-krill-global-wa... 回复
CGMthrowaway 7 分钟前 | 上一个 [–]
啊，鱼 - 我们尚未弄清楚如何用大豆喂养的唯一一种养殖动物。我想很快就会实现。
尽管文章有暗示，但我不太确定“无鱼饲料喂养的鱼”会像“草饲牛肉”一样有吸引力。回复
考虑申请 YC 2026 冬季批次！申请截止日期为 11 月 10 日
指南 | 常见问题 | 列表 | API | 安全 | 法律 | 申请 YC | 联系方式
搜索：
作者对Nextcloud的性能感到沮丧，尽管欣赏它的一体化功能（文件、日历、笔记等）。核心问题是过多的JavaScript——初始页面加载需要下载15-20MB，即使经过压缩。这严重影响了响应速度，即使在良好的硬件上也是如此，在移动设备上尤其缓慢。
“core-common.js”包和各个应用程序脚本（日历、文件、笔记）都加剧了这种臃肿，一些应用程序仅需基本功能就需要几兆字节的JavaScript。虽然缓存有所帮助，但巨大的体积仍然会影响执行时间。
因此，作者正在迁移一些功能——任务到Vikunja（一个更精简的1.5MB），照片到Immich——同时勉强保留Nextcloud的全面功能。他们将问题归因于Nextcloud的架构，并提倡更好的Web性能实践，引用了Alex Russell在这方面的工作。最终，这种性能差异导致了用户体验的下降。
## Nextcloud性能问题与替代方案
一篇Hacker News讨论集中在Nextcloud的 perceived 速度缓慢问题上，Nextcloud是一个自托管云解决方案。用户认为这是由于臃肿的Javascript包造成的，并质疑为什么该应用程序变得如此庞大，尽管人们希望拥有轻量级、简单的云服务。
对于那些寻求更精简选项的人，有几种替代方案被提出。**Seafile** 反复出现，被认为是强有力的竞争者，因其功能和缺乏臃肿而受到称赞，但其iOS应用程序受到批评。其他提到的选项包括 **Immich**（专门用于照片）、**bewcloud**、**Peergos**（具有端到端加密）、**Syncthing**（缺乏选择性同步）、**Resilio Sync** 和 **Copyparty**（速度快但用户体验差）。
一些用户提倡使用专门的单功能应用程序，例如 **Radicale** 用于日历，而不是一体化套件。尽管存在缺点，许多人承认Nextcloud作为大型、公开开发的项目的价值，并且在很大程度上避免了付费的企业功能。
``` 错误 403 403 403 古鲁冥想： XID: 221118569 Varnish 缓存服务器 ```