一周热榜

在两个浏览器窗口中打开相同的标签。在 Chrome 或 Safari 中，你会得到两个不相连的页面。而在 Arc 中，一个窗口显示占位符。在 Zen 中，它会默默地创建一个副本。 在我构建的浏览器 Refrax 中，两个窗口显示相同的页面，并实时更新。你可以在任意数量的窗口中查看同一个网页。 这本不应该是可能的。WebKit 的 WKWebView 一次只能存在于一个视图层次中。随着 macOS 26 的发布，苹果增加了一个 SwiftUI API，将 WebView 与 WebPage 分开，这样你可以拥有多个视图引用同一个页面。但如果你尝试这样做，你的应用会崩溃。WebKit 源代码中有一个前提条件，注释是：“我们不能有多个拥有页面，但我们需要决定这是否是一个错误，是否可以优雅地处理，以及它可能有多确定……” 所以，这就是我如何做到的。 CAPortalLayer 是一个未记录的私有类，自 macOS 10.12 起就存在。它通过引用相同的 GPU 内存来镜像一个层的合成输出，而不是复制它。每次滚动、动画或重绘都会立即反映出来。这就是驱动液态玻璃效果、iOS 文本选择放大器和拖放时的虚影的技术。苹果使用门户来实现效果。我则利用它们在两个窗口中显示相同的网页。 Refrax 每个标签保持一个真实的 WKWebView，并在其他地方显示 CAPortalLayer 镜像。当你点击不同的窗口时，协调器会将真实视图移动到那里，而旧窗口则获得一个门户。你无法分辨哪个是哪个。 这在理论上听起来简单，但要让它真正无缝工作却花费了不少精力。每个 macOS 窗口都有自己的渲染上下文，而上下文 ID 是异步更新的，因此立即创建一个门户会捕获一个过时的 ID，导致什么都无法渲染。门户的创建需要延迟，但延迟会造成视觉间隙。我使用一个私有的 CoreGraphics 函数捕获 GPU 快照，并将其放置在门户后面作为后备。另一个困难之处在于，这些都没有文档。门户非常不稳定，如果使用不当会导致应用崩溃。我不得不检查头文件，然后反汇编二进制文件，以探索它的具体工作原理，从而构建出一个稳健的系统。 在此之前，我从未参与过浏览器的开发，只是一个用户。我在 2022 年开始使用 Arc。我记得曾请求邀请，学习快捷键，慢慢适应它。起初我并不喜欢，因为它对我来说有太多 Google Chrome 的味道，而那时我一直在使用 Safari。但我逐渐喜欢上了它，当它基本上被放弃并卖给 Atlassian 时，我再也无法回到 Safari。 我尝试了所有东西：Zen、SigmaOS、Helium。没有一个让我觉得合适，我也不想要另一个 Chromium 分支。WebKit 随操作系统一起提供，但你得到的只是渲染引擎。标签、历史记录、书签、密码、扩展，其他一切都必须单独制作。因此，作为一个非常理智的人，我决定从头开始制作自己的 Arc 替代品。 我做到了。Refrax 是用 Swift 和 Objective-C 构建的，没有外部依赖。应用本身不到 30 MB。我现在打开了 393 个标签，使用了 442 MB 的 RAM；而在 Safari 中，150 个标签已经超过 1 GB。我已经每天使用它超过一个月，我的一些朋友也是。 门户镜像只是一个功能。整个浏览器都采用了相同的方法，寻找苹果为自己构建的东西，并利用它创造他们没有想到的东西。你可以用可调的混合模式和透明度为你的玻璃窗口上色。紧凑模式下的侧边栏会采样页面并匹配颜色。它还支持 Firefox 和 Chrome 扩展。 Alpha 版本是公开的。可以从链接网站下载，输入 REFRAX-ALPHA-HACKERNEWS 激活。无需账户。遥测仅包括崩溃报告和每日活跃用户的 ping，别无他用。如果你发现了 bug——我独自构建了这个，所以我会认真阅读你的报告。

我想要一个免费的 Nomad List 版本，并且不想要过于复杂的功能，因此我制作了 Minimum Viable Expat。它专注于生活成本和比较居住地，仅此而已。这个项目还处于早期阶段，欢迎反馈。

嘿， 我最近一直在思考，了解和比较各大云服务提供商（AWS、GCP、OCI、Azure）以及现在的人工智能/大语言模型（LLMs）成本是多么困难。 大多数工具只显示历史支出，但并没有真正展示： - 相同工作负载在其他地方的成本 - 不同的人工智能提供商在相同使用情况下的比较 我很好奇大家现在是如何处理这个问题的。 你们是依赖内部工具、电子表格，还是其他什么方式？ 我一直在尝试开发一个小工具来解决这个问题，但仍在努力理解这是否是一个真正的痛点，还是仅仅是我个人的困扰。 很想听听你们是如何应对这个问题的。

我对这种炒作曾经翻了个白眼，但实际上，<i>阅读</i>这方面的内容和<i>体验</i>它是完全不同的。如果你有任何旧的代码库，试试看，你可能会感到惊讶。 我不确定对于复杂的遗留企业系统，长期的“*90% 生产力*”的说法是否可信，但对于模板、库、构建工具和重构来说，收益是巨大的。那些耗时且令人紧张的工作大部分都得到了处理。 一开始你会像鹰一样仔细检查每一个差异，期待它会破坏东西，但老实说，很快你会发现大多数情况下这并不是必要的。你只需保持IDE开启，将“分析代码”的输出反馈给它。在Java中，告诉它“<i>添加checkstyle，运行mvn verify并修复</i>”的效果很好，你甚至可以去喝杯咖啡，而不是与linter警告作斗争。 理论上，剩下的只是<i>逻辑</i>和<i>想法</i>。当架构真正变得复杂时，我们将看看这一点是否成立。但目前，让它分支、创建模板并编写简单的测试，同时你只需在规格上进行迭代，效果出奇地好。只有在写下规格用普通英语太麻烦时，你才会编写源代码。 这提出了一个真正的问题：如果你的竞争对手Y刚刚解雇了90%的开发人员以节省成本，你会盲目跟随吗？还是会保留你的团队，利用这个巨大的杠杆，以一个远远更好的产品将Y彻底超越？