## Tiny C 编译器 (TCC) 概要
TCC 是一款非常小巧、快速且多功能的 C 编译器，专为资源受限的环境设计——甚至可以放入救援盘（约 100KB）。 与使用字节码的编译器不同，TCC 直接生成 x86 代码，从而显著提高了编译速度——在大型项目（76936 行代码）中，速度可达 GCC 的 9 倍。
TCC 旨在完全符合 ISO C99 标准，并支持动态库。 它允许直接执行 C 源代码，无需单独的链接或汇编步骤，甚至支持带有简单 shebang 行的 C 脚本。 内置的内存和边界检查器增强了代码安全性。
此外，TCC 可以通过 `libtcc` 用作动态代码生成的后端。 虽然开发速度有所放缓，但它仍然是特定用例的强大选择，并采用 GNU Lesser General Public License 许可。
每日HackerNews RSS
## Tiny C 编译器 (TCC) - 摘要
这次黑客新闻的讨论围绕着 Tiny C 编译器 (TCC)，这是一款小型、快速且易于修改的 C 编译器。用户强调了 TCC 的独特特性，包括其自编译能力——使其成为一个强大的测试用例——以及其最小的尺寸，适用于需要精简构建的项目。
最近的讨论点包括一个支持 RISC-V 的分支、它在 Guix 等项目中的引导用途，以及它作为脚本语言（如 Nim）后端，提供接近原生性能的潜力。一个关键点是，尽管 8 年没有发布新版本，但 TCC 仍在通过社区贡献在一个独特、几乎未审核的仓库中积极维护。
讨论还涉及与 AI 生成的编译器的比较，强调了复制现有代码与创建全新编译器之间的区别。由于法律问题，官方仓库被英国地理封锁的担忧也被提出，以及对有志于成为编译器作者的资源推荐。
展示 HN：一种亮度依赖色度压缩算法（图像压缩）
Show HN: A luma dependent chroma compression algorithm (image compression)
2 天前
本文详细介绍了一种高度压缩图像色度（颜色）数据的技术，有可能在不产生明显视觉伪影的情况下，实现每像素低于0.5比特的压缩。该方法利用了色度通道通常与亮度（Y）通道高度相关的观察结果——本质上，颜色信息可以从亮度近似得到。
核心思想是在图像块（起始为16x16像素）内，使用基于该块内最小和最大Y值的简单方程线性近似色度值。这只需要存储每个色度通道每个块的两个值，从而大大减小数据大小。使用可变块大小（低至2x2）以提高复杂区域的精度，并使用单个比特指示是否应分割块。
为了减轻这种近似造成的“块状”伪影，应用了一种边缘误差估计和补偿技术，以平滑块之间的过渡。结果表明，可以实现低至每像素0.13比特的压缩，但质量损失会增加。进一步的改进可能包括高级熵编码和去块算法的改进。作者提供了一个实验性C++代码链接以供实现。
## HN讨论：亮度依赖色度压缩
一篇Hacker News帖子详细介绍了一种新的图像压缩算法，利用“从色度推导亮度”的技术。然而，评论者很快指出这种方法并非新颖，已经在像JPEG XL、AV1和HEVC等先进的编解码器中被使用。
核心思想——从亮度（明度）预测色度（颜色）信息——是有效的，但面临着准确表示边缘的挑战。原作者的解决方案使用四叉树结构来解决这个问题，但评论者指出现有的编解码器通过诸如低分辨率斜率图像或类似的差分预测方法来处理这个问题。
尽管该方法并非新颖，但讨论强调了探索这些概念的价值。一些用户发现这篇文章激发了他们自己项目的灵感，证明了分享即使是成熟技术的益处。对话还涉及了为复杂的图像压缩领域做出贡献的难度以及影响既定标准的规模。在较低码率的示例中，也观察到持续的色彩偏移（红色/黄色损失，蓝色/绿色增加）。
最近，作者在使用Windows 11时遇到一个令人沮丧的问题：由于Microsoft商店的许可错误，无法使用记事本和截图工具等基本内置应用。这凸显了Windows越来越不像传统的操作系统，而更像一项依赖云服务的平台。
作者是一位资深的Windows爱好者，对这种转变感到担忧，特别是像记事本这样 historically 简单、离线的核心应用，现在也与在线账户绑定，并越来越多地集成Copilot等功能。虽然可以通过卸载OneDrive、创建本地账户等方式进行自定义，但需要使用变通方法以及潜在地依赖第三方“清理”脚本，这显得不必要且可能存在风险。
核心问题并非反对改变，而是反对突如其来的中断以及失去本地控制。作者认为Windows应该保持离线功能，用户不应该被迫依赖互联网连接才能使用基本工具。对于Windows的未来仍然感到担忧，担心它会进一步依赖在线服务，并且Windows 12可能会变得更加依赖云，从而可能促使用户回归更早、更可定制的版本。
这个故事说明了意图转变如何会在组织内部和个人层面显著增加摩擦。作者回忆起曾经由乐于助人的秘书Joann管理的无缝差旅报销流程，被一个专注于查找错误的审计员和复杂的系统所取代——这明显是退步。 这种转变突显了一个关键点：如果没有以*帮助*和简化为核心意图，系统自然会倾向于寻找问题。这种“摩擦作为产品”的动态并非仅限于工作场所。个人也可以在内心创造出吹毛求疵、阻碍进步的“审计员”，尤其是在注意力从成长上转移时。 作者将此与心态联系起来，指出积极、以成长为导向的态度常常会受到愤世嫉俗的对待，而与那些专注于建设的人们产生共鸣。最终，优先考虑意图——专注于解决方案和动力——是消除障碍和取得成功的关键。
## 官僚主义的兴起与信任的丧失
Hacker News 上的一篇博文讨论了从精简、人工处理的费用报销流程（由一名名为 Joann 的员工负责）转变为复杂的自动化系统（如 Concur）。用户普遍认为，这种变化是由公司发展和成本削减驱动的，最终*增加了*员工的工作量，而可能节省的钱却很少。
核心问题是信任的转变。随着组织规模扩大，一种假设善意的“高信任”环境让位于专注于防止滥用的“低信任”环境。这表现为详细的报告要求和严格的规则。 许多评论员指出，外部因素，如政府法规和资金限制（尤其是在大学中），也加剧了复杂性。
许多人认为，自动化系统并非真正实现自动化，而是简单地将工作量*转移*到员工身上，他们现在需要花费大量时间来应对令人沮丧的流程。 一些人认为 LLM 可能会潜在地恢复“Joann 式”的服务，而另一些人则认为增加的监督是管理层获取更多控制权和可见性的方式，即使这种方式适得其反。一个反复出现的主题是，机会成本——员工因官僚主义而浪费的时间的价值——很少被纳入成本节约的计算中。
这是一个简单的代码探索，灵感来自（并借鉴自）https://iventions.com/，在X平台看到。在这个例子中，我尝试实现一个在用户点击按钮时显示的菜单。仅使用HTML+CSS，不使用JS。有两个剪切路径：菜单通过一个从屏幕左上角增长到右下角的圆来显示。我在这里使用的一个有趣的剪切路径计算（clip-path: circle(calc(1.42 * 100vmax) at 0 0);）基于vmax，它是视口宽度或高度中较大的那个。然后乘以1.42，因为1.42是2的平方根，这是视口宽度与高度之比。第二个剪切路径是一个多边形，用于模拟“射线”。多边形现在是硬编码的，但可以使用js计算，以实现尊重导航尺寸的动态尺寸和响应式设计。感谢您的访问。
一位开发者分享了对[Iventions.com](https://iventions.com/)上独特导航展开效果的纯CSS复刻，并将代码发布在GitHub上([https://github.com/Momciloo/fun-with-clip-path](https://github.com/Momciloo/fun-with-clip-path))。该效果利用两个剪切路径——圆形和多边形——来展现导航菜单。
该帖子引发了关于美学设计与可用性之间平衡的争论。一些评论者赞扬了其创造性和视觉吸引力，认为并非所有网页设计都需要优先考虑即时功能，尤其是在作品集或营销网站上。另一些人则批评该设计不实用，指出它增加了鼠标移动距离，并可能存在可访问性问题，尤其是在移动设备上。
人们对不同设备和浏览器尺寸下的性能和响应能力表示担忧。许多评论者强调了优先考虑用户体验和高效导航，而非纯粹的风格选择的重要性，并质疑这种设计是否解决了实际的用户问题。尽管存在批评，但许多人仍然欣赏其中展示的技术技巧和实验精神。
这位开发者选择用纯C语言进行单人游戏项目开发，这是一种出乎意料的做法。他们最主要的需求是**可靠性、可移植性和持久性**——这是从Flash消亡中吸取的教训，以及避免平台锁定的愿望。虽然性能是一个考虑因素，但**简洁性**至关重要。他们优先选择一种可以熟练掌握，无需不断查阅资料的语言，并结合强类型和强大的调试工具来减少令人沮丧的错误。 C++、C#和Java等替代方案被认为过于复杂，并且经常强制使用他们不喜欢的面向对象编程风格。Go语言很有吸引力，但对于游戏来说，垃圾回收机制存在问题，并且库支持有限。虽然对Haxe很感兴趣，但对其年轻的年龄仍有顾虑。 最终，C语言达到了最佳平衡。尽管由于其底层特性而“危险”，但它**速度快、可移植、可靠，并拥有强大的工具**。开发者承认这个选择非常个人化，源于舒适性和对代码的直接控制偏好，让他们能够专注于*制作*游戏，而不是与语言本身作斗争。
## SectorC：一个微型C编译器
SectorC是一个非常小的C编译器，完全容纳在x86机器的512字节引导扇区内——可能是迄今为止最小的。它支持C的一个有用的子集，包括全局变量、函数、`if`和`while`语句、运算符、指针解引用、内联汇编和注释，从而能够编写出令人惊讶的复杂程序。
该编译器通过创新技术实现其小尺寸。它使用空格分隔的“Barely C”语言，有效地创建“超符号”以减少解析开销。它还采用基于哈希的方法来处理标识符，避免了传统的符号表。
尽管存在局限性，SectorC可以运行像移动正弦波动画这样的程序，甚至可以通过PC扬声器播放音乐。它依赖于一个最小的运行时库来实现I/O和基本功能。
该项目表明，显著的功能可以被封装到极其有限的空间中，挑战了关于编译器尺寸的传统观念，并突出了巧妙优化的力量。它证明了创造力，并对编程语言边界进行了有趣的探索。
## SectorC：一个512字节的C编译器
一位开发者创建了SectorC，一个能放入512字节引导扇区的C编译器。这在Hacker News上引发了关于编程极简主义和C语言演变的讨论。用户指出，20世纪80年代的类似实现可能影响了C标准，并且优化编译器有可能消除未使用的代码。
几位评论者分享了相关项目，包括他们自己编写的引导扇区C编译器和自举工具，如`stage0`和`OTCC`。对话涉及了该编译器的局限性——它仅支持C的一个子集，缺乏`for`循环和结构体等特性——以及在这些限制下它是否真正能被称为“C编译器”。
有人将其与最近发布的人工智能生成的C编译器进行比较，突出了能力上的差异（内核编译与有限的C子集）。该项目因其优雅地使用哈希算法来处理词法单元和符号表而受到赞扬，并展示了C的核心简洁性，其根源在于Fortran等语言。
启用 JavaScript 和 Cookie 以继续。
## RHIC 结束 25 年运行，展望与 EIC 的未来
布鲁克海文国家实验室的相对论重离子对撞机 (RHIC) 已完成 25 年的粒子对撞运行，为在同一隧道内建设电子离子对撞机 (EIC) 铺平了道路。 此次关闭引发了前研究人员的回忆和讨论，他们回忆起维持超导温度和最大化束流时间所需的严苛 24/7 运行——成本约为每分钟 1000 美元。
虽然一些人质疑像 RHIC 这样的基础物理研究的实际投资回报，但许多人强调了其重要的科学成就以及对同步辐射光源（用于药物发现和材料科学）、医学成像（PET 扫描）甚至万维网等技术的贡献。 还有人强调了扩展我们对宇宙理解的内在价值。
人们也对布鲁克海文过去的环保措施提出了担忧，包括潜在的放射性物质污染，但一些人反驳说风险已被缓解，并且正在进行监测。 尽管 RHIC 已经结束，但布鲁克海文仍然活跃，斯托尼布鲁克大学将深度参与即将到来的 EIC 项目。
## 编码代理选择：超越排行榜
“哪个编码代理最好？”这个问题具有误导性。性能因语言、任务甚至时间而异，使得单一的“最佳”选择不可靠。与其*预测*最佳代理，更有效的方法是*从*候选池中*选择*——一种“最佳N选一”策略。
这包括并行运行多个代理，每个代理处理相同的任务，并由人工审核员选择最佳实现。这个过程不仅能提供更高质量的代码，还能基于实际合并生成有价值的评估数据。
对18个代理在211个任务上的分析揭示了性能等级，顶级代理与其余代理之间存在明显差距。然而，即使在顶级等级中，排名也存在噪声且置信区间重叠。运行一个群体可以显著提高胜率：顶级代理单独成功率为24%，而三个代理的组合提高到51%，七个代理的组合提高到91%。
关键在于，运行一小群表现最佳的代理——优先考虑前几个——可以大大提高成功几率，超过了额外token的成本，并减少了昂贵的人工工程时间。
请启用 JavaScript 并禁用任何广告拦截器。
## 美国失业与政治辩论
一篇《福布斯》文章报道了自大衰退以来最快的1月份失业率增长，在Hacker News上引发了热烈讨论。最初的帖子引发了对失业原因的争论，迅速演变成政治辩论。
许多评论员指出历史数据表明，民主党政府领导下的就业增长明显高于共和党政府，一些人指出自1989年以来，这一比例为50:1。反驳意见集中在经济政策的时间滞后以及外国战争和金融放松管制可能产生的负面影响上。
对话扩展到更广泛的经济问题，包括二战后劳动力短缺的影响、人工智能的作用以及潜在的垄断行为对工资的压制。一些人对经济数据的准确性和政治议程的影响表示怀疑。科技、交通和医疗保健等行业的具体裁员，以及外包和H1B签证问题也得到了讨论。
最终，该帖子凸显了在解读经济趋势和追究失业责任方面存在深刻的分歧。