## 辣椒卡宴：下一代数据加速，助力规模化
Spice Cayenne 是 Spice.ai 推出的最新数据加速器，旨在处理低延迟的多太字节数据湖工作负载。Cayenne 旨在克服 DuckDB 和 SQLite 等现有加速器在规模化时的局限性，它结合了高性能的 **Vortex 列式格式**（来自 Linux 基金会）和精简的 **嵌入式元数据引擎**。
这种分离优化了存储和元数据管理，从而实现 **更快的查询和显著降低的内存使用量**。Spice 通过在本地计算引擎中实现数据集来加速数据，减少网络 I/O 并实现亚秒级查询时间，而无需额外的基础设施。
Cayenne 通过利用 Vortex 高效的随机访问和与 Apache Arrow 的零拷贝兼容性，解决了大数据集中的关键挑战——并发瓶颈、高内存消耗和复杂的索引管理。基准测试表明，Cayenne 的查询速度比 DuckDB **快 1.4 倍**，同时使用的内存 **减少了近 3 倍**。
目前处于 Beta 阶段，Spice Cayenne 通过在 Spicepod.yml 中配置 `engine: cayenne` 来配置，并承诺进一步改进，例如索引支持和额外的元数据后端。它旨在成为太字节和拍字节级分析和人工智能工作负载的领先加速器。
每日HackerNews RSS
展示 HN：Spice Cayenne – 基于 Vortex 的 SQL 加速
Show HN: Spice Cayenne – SQL acceleration built on Vortex
2 天前
Spice Cayenne 是 Spice.ai 构建的一种新型 SQL 加速工具，利用高性能的 Vortex 列式数据格式。Spice.ai 是一个开源数据和 AI 引擎，专为大规模数据处理而设计，Barracuda Networks 和 Twilio 等公司已经在采用。
Cayenne 利用“数据加速器”将来自各种来源的数据转化为嵌入式数据库。这个新版本受 Ducklake 启发，使用 Vortex，它在随机访问、扫描和写入方面比 Apache Parquet 快得多，并且在内存使用方面优于 DuckDB。
虽然 DuckDB 加速器通常最大容量约为 1TB，但 Spice Cayenne 旨在实现 PB 级部署。开发者正在寻求对这个初始版本的反馈，并强调 Spice 的独特功能，包括原生数据加速、联合查询、混合搜索和 LLM 推理。
更多信息请参见 Spice.ai 博客和 GitHub 仓库。
## TRELLIS.2：高保真图像到3D生成
TRELLIS.2 是一种新的40亿参数大型3D生成模型，能够以惊人的速度和效率从2D图像创建高分辨率、完全纹理化的3D资产。它利用了一种新颖的“无场”稀疏体素结构，称为O-Voxel，能够生成复杂的拓扑结构——包括开放表面和内部结构——并完全支持PBR材质（颜色、粗糙度、金属度、不透明度）。
该模型在NVIDIA H100 GPU上大约60秒内即可实现高达1536³的分辨率。其主要优势在于纹理网格和O-Voxel之间的快速转换（<10秒CPU到O-Voxel，<100毫秒CUDA到网格）。
TRELLIS.2 建立在专门的软件包之上，例如O-Voxel、FlexGEMM和CuMesh，以实现优化的性能。代码可在GitHub上获取（仅限Linux，需要具有≥24GB内存和CUDA Toolkit 12.4的NVIDIA GPU）。预训练模型可通过Hugging Face访问。网络演示和PBR纹理生成即将推出。该项目采用MIT License发布，部分依赖项具有单独的许可条款。
微软发布了TRELLIS.2，一种先进的开源大型3D生成模型（40亿参数），并计划公开发布配套代码和数据集。 在影响深远的TRELLIS 1的基础上，新版本采用了新颖的O-Voxel数据结构，能够高效地将体素数据转换为网格，类似于一次性PNG到SVG的转换。
用户指出，与之前的模型相比，该模型在质量和PBR材质及纹理生成方面都有所改进。 虽然直接使用需要24GB显卡，但像vlm.run这样的替代方案允许从图像生成资源，而无需强大的硬件。 一些评论员观察到，演示结果不如展示的示例令人印象深刻，这表明输出可能经过了精选。
该项目被誉为开源3D生成领域的重要一步，但也有人预计未来将朝着Sparc3D等模型的质量方向进一步发展。 演示可在Hugging Face上找到 ([https://huggingface.co/spaces/microsoft/TRELLIS.2](https://huggingface.co/spaces/microsoft/TRELLIS.2))。
展示HN：阻止AI爬虫猛击你的自托管博客
Show HN: Stop AI scrapers from hammering your self-hosted blog (using porn)
2 天前
人工智能公司广泛抓取网站以获取训练数据，保护您自托管的博客可能具有挑战性。**Fuzzy Canary** 是一种旨在通过微妙地将指向不良内容（如色情内容）的不可见链接注入到您网站的 HTML 中来阻止这些抓取器的工具。这会触发许多人工智能抓取工具的内容保护机制。
您可以**服务器端**（推荐，效果更好，尤其对于非 JavaScript 抓取器）或**客户端**实施 Fuzzy Canary。服务器端集成使用 React 框架（如 Next.js 和 Remix）非常简单，通常只需添加一个组件。客户端使用单个导入进行自动初始化。
Fuzzy Canary 通过检查用户代理来智能地避免标记 Google 和 Bing 等合法的搜索引擎。然而，这对于**静态网站**提出了一个问题，在构建时无法进行用户代理检查，可能会损害 SEO。对于静态网站，建议使用客户端初始化，但可靠性较低，因为它依赖于机器人执行 JavaScript。
## FuzzyCanary：对抗AI抓取的创意（且有争议）解决方案
一个名为FuzzyCanary的新项目，提供了一种独特的——尽管非常规——防御方法，以对抗AI公司抓取自托管博客用于训练数据。该项目认识到传统的`robots.txt`方法会被忽略，并且与资源雄厚的实体竞争是徒劳的，因此开发者将指向色情网站的隐藏链接注入到博客的HTML中。其想法是这些链接将触发抓取器的数据管道中的安全机制，导致它们拒绝该网站。
虽然承认存在SEO风险，但该项目试图通过仅向抓取器展示这些链接，而不是向合法的搜索引擎展示来减轻这些风险。讨论强调了抓取器和网站所有者之间的军备竞赛，建议范围从更复杂的机器人检测到数据中毒，甚至利用谷歌发布的爬虫IP范围。
这篇帖子引发了关于各种反抓取技术有效性、数据抓取的伦理以及AI绕过这些防御措施的可能性的辩论。许多评论者分享了他们经历的过度抓取流量，并探讨了替代解决方案，如Cloudflare（存在一些限制）和自定义验证码系统。最终，FuzzyCanary代表了一种富有创意，尽管绝望，试图在面对激进的AI数据收集时夺回内容控制权的尝试。
德克萨斯州总检察长肯·帕克斯顿正在起诉五家主要电视制造商——索尼、三星、LG、海信和TCL，指控它们秘密记录观众的习惯，用于定向广告和潜在监控。诉讼称，这些电视使用自动内容识别（ACR）技术收集有关*所有*观看内容的数据，包括流媒体服务、通过HDMI连接的设备，甚至安全摄像头拍摄的画面。 帕克斯顿认为，这些公司通过隐藏和误导性的提示来欺骗性地激活ACR，在未获得知情同意的情况下收集数据——据称有些公司每半秒拍摄一张截图。他还对海信和TCL的中国关联表示担忧，将它们的电视称为潜在的“中国赞助的监控设备”。 该州指控这些公司违反了德克萨斯州欺诈贸易行为法，并寻求处罚，以及停止数据收集和销售。帕克斯顿表示，拥有电视不应等同于向科技公司或外国实体牺牲个人隐私。
## 德克萨斯州起诉电视制造商，涉嫌侵犯隐私
德克萨斯州正在起诉多家主要电视制造商，指控他们未经同意监视观众的观看习惯。诉讼声称这些“智能”电视非法收集人们观看内容的数据。Hacker News上的讨论凸显了人们对数据隐私和现代技术中普遍存在的监控的广泛担忧。
许多评论者希望购买“哑”电视——没有数据收集“智能”功能的型号，或者能够轻松禁用追踪功能。担忧不仅限于电视，用户还指出其他智能设备（如冰箱）也存在类似问题。一些人建议将设备从互联网上断开连接，但承认这会限制流媒体服务等功能。
一个关键点是普通消费者难以理解和控制数据收集。关于是否可以通过单独的流媒体设备解决问题，以及制造商是否会绕过隐私措施，存在争论。值得注意的是，沃尔玛拥有的Vizio未被纳入诉讼，引发了对其潜在影响力的质疑。对话还涉及更广泛的监控资本主义问题，以及对个人数据更大的透明度和控制的需求。
## Gleam 位数组：摘要 Gleam 提供了强大的位数组语法，灵感来自 Erlang，用于构建和模式匹配二进制数据。位数组由 `<<` 和 `>>` delimits，是段的序列，每个段代表编码为位的数值。段定义为 `value:option1-option2`，数据类型包括 `Int`、`Float`、`String`，甚至其他 `BitArray`。 默认情况下，`Int` 段为 8 位有符号，而 `Float` 使用 64 位 IEEE 754。`String` 默认使用 UTF-8 编码。`size` 选项控制段的位数，并提供简写表示法。字节序默认为大端，但可以设置为小端或本机端。 位数组不仅用于创建，而且在模式匹配方面表现出色。你可以通过匹配特定字面量或将值赋给变量来提取数据。字符串匹配存在限制（不支持任意长度的字符串），但可以使用 `bytes` 进行 UTF 代码点和字节级匹配。 虽然在很大程度上镜像 Erlang 的行为，但一些特性（如 `native` 选项和 UTF 代码点模式匹配）对于 JavaScript 目标仍在开发中。位数组通过基本的 NBT 编码器/解码器示例进行演示，展示了它们在数据操作方面的实用性。
Hacker News 新闻 | 过去 | 评论 | 提问 | 展示 | 招聘 | 提交 登录
充分利用 Gleam 中的位数组 (gearsco.de)
13 分，由 crowdhailer 1 天前发布 | 隐藏 | 过去 | 收藏 | 讨论
指南 | 常见问题 | 列表 | API | 安全 | 法律 | 申请 YC | 联系
搜索：
## 中央盘古山脉的兴衰
在超大陆盘古大陆形成期间（石炭纪-三叠纪），由于劳亚古陆和冈瓦纳古陆的碰撞，形成了一座巨大的山脉——中央盘古山脉。这座山脉的高度可与今天的喜马拉雅山脉相媲美，它曾经连接着现在散布全球的山脉，包括苏格兰高地、阿巴拉契亚山脉和摩洛哥的阿特拉斯山脉。
最初高耸的山峰在二叠纪经历了强烈的风化，形成了山谷并降低了整体高度。这种侵蚀一直持续到三叠纪，显著地降低了山脉的高度。到了侏罗纪（大约2亿年前），该山脉的西欧部分已经大体消失，分裂成孤立的高地，被新形成的海洋盆地分隔开，标志着其最终衰落的开始。
## 古老的联系：山脉的共同历史
最近的Hacker News讨论强调了苏格兰高地、阿巴拉契亚山脉和阿特拉斯山脉之间令人惊讶的地质联系——它们都是同一座古老山脉的一部分，形成于数亿年前大陆碰撞时。
对话扩展到相关话题，如徒步国际阿巴拉契亚步道和东部大陆步道，以及苏格兰-爱尔兰人定居在阿巴拉契亚山区的历史原因（寻找熟悉的地貌）。用户还探讨了这些地区的独特地质，包括阿巴拉契亚山脉异常的侵蚀模式以及喜马拉雅山脉通过最近的大陆碰撞形成。
讨论涉及文化联系，例如苏格兰酿酒师从阿巴拉契亚山脉采购木材用于酒桶，甚至争论了所展示地图的准确性，一些人指出其过于简化。 许多用户分享了进一步学习的资源，包括地质讲座和相关的维基百科文章。最终，这个帖子展示了地质、历史和文化联系在各大洲之间迷人的交汇。
## T5Gemma 2：新一代高效多模态模型 T5Gemma 2 在 T5Gemma 的成功基础上，融合了 Gemma 3 系列的创新，进一步发展了编码器-解码器架构。这一代产品引入了**多模态**能力——理解图像和文本，并显著**扩展了上下文窗口**，最高可达 128K tokens。 T5Gemma 2 效率的关键在于架构改进：**共享词嵌入**（编码器和解码器之间共享）和解码器中的**合并注意力**，从而减少了参数数量。这使得模型更加紧凑——2.7亿-2.7亿、10亿-10亿和40亿-40亿参数，非常适合设备端应用和快速实验。 T5Gemma 2 在一个庞大的多语言数据集上进行训练，支持超过 140 种语言，在各种任务中都表现出强大的性能，继承了 Gemma 3 的强大能力，同时提供了一个更易于访问和更通用的编码器-解码器解决方案。
## T5Gemma 2 摘要
谷歌发布了新的编码器-解码器模型 T5Gemma 2，引发了 Hacker News 的讨论。该模型拥有 128K token 的上下文窗口和多模态能力（处理文本和图像）。然而，预训练检查点并未发布，这让一些希望在没有大量后训练的情况下进行实验的用户感到沮丧。
讨论的中心是编码器-解码器架构相对于仅解码器模型（如 Gemma）的优势。编码器-解码器因其在推理和微调方面的潜在效率而受到关注，尤其是在诸如摘要和翻译之类的任务中。然而，一些人认为，随着强大、提示工程前沿 LLM 的兴起，微调变得越来越不重要。
关键点包括在微调时复制训练条件以保持多模态能力的重要性，以及将大型模型中的知识提炼到较小的 T5Gemma 2 实例中的潜力。用户还争论编码器是否提供了真正“自然”的嵌入，以及参数效率的绑定嵌入的实际优势。
## 一键清理器：简化HTML以进行可访问性审计
可访问性顾问伊恩·劳埃德（Lloydi）开发了“一键清理器”来简化在可访问性审计期间分析复杂HTML的过程。 劳埃德对反复解码高度嵌套、属性众多的标记感到沮丧，因此在之前的工具“HTML清理器”的基础上，创建了一个更快、更集中的解决方案。
“一键清理器”作为书签或Chrome扩展程序提供，通过删除不必要的类、琐碎的属性和过度的嵌套来简化HTML。 它优先显示仅对辅助技术至关重要的属性——那些影响角色、状态和焦点的属性。
用户只需在浏览器中单击一个元素，该工具就会呈现其标记的简化版本，以便复制。 一个切换按钮允许快速与原始代码进行比较，并且有一个选项可以进一步展平嵌套结构。 输出结果会自动包装在Markdown中，以便于报告。
虽然该工具不能*修复*错误的标记，但它显著减少了理解标记所花费的时间，使审计员能够快速识别和解决可访问性问题。
一场由链接“地狱是别人的标记语言”（htmhell.dev）引发的 Hacker News 讨论，围绕着现代 Web 开发和 HTML 结构复杂性展开。
最初的帖子引出了关于优化网站加载速度的讨论——特别是使用 Google 的压缩工具以及内联数据（如图片）以减少缓存查找。然而，评论者表达了希望更深入地探讨“净化”HTML 的需求。
一位用户指出标题让人期待对更广泛的社会问题的批判，而另一位则强调了干净的标记语言与实际开发需求之间的权衡，尤其是在 B2B 应用中。他们认为，即使这会创建更深的 DOM 树，有时“div 汤”也是可以接受的，因为它能提高组件隔离性和可维护性。这场讨论最终触及了在代码优雅性、用户体验和开发效率之间取得平衡的问题。
## Composify：React 组件的可视化编辑 Composify 是一个开源的 React 库，提供了一个可视化编辑器，使非开发者能够使用现有的、可用于生产环境的组件来构建和修改页面。Composify 不同于僵化的页面构建器或复杂的无头 CMS，它弥合了差距，允许团队使用他们已建立的设计系统来可视化地组合内容。 只需在目录中注册你的 React 组件，用户就可以拖放它们、调整属性并创建动态页面，而无需工程支持。这可以实现更快的 UI 更改——甚至无需重新部署的即时更新——非常适合营销活动、A/B 测试和快速原型设计。 Composify 提供服务器端 UI 解决方案，赋予内容和营销团队自主权，同时工程师可以专注于核心功能开发。它与 Next.js、Remix 以及任何 React 环境兼容，并且你可以保留完全的数据所有权。 对于需要完全托管解决方案的团队，Composify Cloud 提供托管、协作功能和版本历史记录。详细文档和项目贡献请访问 [composify.js.org/docs](https://composify.js.org/docs)。
## Composify：React 组件可视化编辑器
Composify 是一款新的开源工具，旨在赋能非开发者构建和修改基于 React 的着陆页和营销内容。由开发者 injung 创建，它解决了营销团队经常需要页面更改，而这些更改常常给工程资源带来负担的常见问题。
与传统的无代码构建工具或无头 CMS 解决方案不同，Composify 独特地允许用户通过拖放界面直接利用*现有*的 React 组件，生成 JSX，而无需修改代码或学习新的模式。
该工具源于之前一家初创公司的内部解决方案，最终驱动了他们 60% 的流量，显著减少了工单请求并实现了 A/B 测试。虽然目前仍处于早期开发阶段，并且需要改进文档，但 Composify 为希望利用其组件库以加快内容迭代的团队提供了一种简洁灵活的方法。
更多信息请访问 [https://composify.js.org](https://composify.js.org)。
## 流体排版：使用 CSS 调整字体 流体排版旨在在不同屏幕尺寸之间创建平滑缩放的字体大小，避免在断点处出现突兀的跳跃。 传统上，这涉及使用 `calc()` 和 `vw` 单位基于基础屏幕宽度和字体大小计算比例。 近期 CSS 的进步，特别是 **类型化算术** (Chrome 140+)，彻底改变了这一过程。 最初，无单位值对于兼容性至关重要。 现在，类型化算术允许直接计算，例如 `calc(10em / 1px)`，从而能够根据视口宽度动态调整排版比例。 像 **Utopia** 这样的工具可以帮助生成这些流体值，并提供预定义的刻度。 然而，一个关键的改进是计算一个 `--screen-normalizer` 变量，以便在定义的范围内流体地调整基础字体大小 *和* 排版比例。 这允许实时原型设计，并使用 CSS 变量轻松缩放。 未来的 CSS 函数有望提供更大的灵活性，可能允许自定义函数根据设计系统步骤生成大小。 虽然目前仅限于 Chrome，但可以使用 `@supports` 实现回退解决方案。 这种方法可以实现和谐的排版，并能美观地适应任何屏幕尺寸。
Hacker News 上围绕“交互流体排版”(electricmagicfactory.com) 及其实用性展开讨论。 许多评论者强烈不喜欢自适应/流体布局的趋势，认为有意的呈现方式是内容的一部分，对引导读者至关重要。 一位用户认为，鉴于平板电脑和笔记本电脑等更大屏幕的普及，这些技术是不必要的。
另一些人抱怨网站本身，特别是其试图覆盖浏览器缩放功能以及不成比例的大型固定导航栏遮挡内容。 然而，一些用户报告缩放没有问题，引发了关于浏览器/设备兼容性的疑问。 核心争论在于，优先考虑灵活布局是增强还是损害了阅读体验和有意的的内容设计。