2024-01-31

50 篇热帖

2. Show HN: Open-source x64 and Arm GitHub runners (www.ubicloud.com)

Ubicloud 开源 GitHub 运行器摘要

核心概述

Ubicloud 是一个开源云平台,提供针对 GitHub Actions 的托管运行器(Runners),旨在作为传统云服务提供商(如 GitHub 托管运行器)的开源替代方案,类似于 Linux 之于专有操作系统。用户可通过仅修改一行配置,将 GitHub Actions 工作流切换至 Ubicloud 运行器,从而在提升性能的同时大幅降低成本。

主要优势

  • 成本节省:相比 GitHub 托管运行器,成本降低 4 至 7 倍。标准运行器每分钟 $0.0010,高级运行器每分钟 $0.0016。
  • 性能提升:构建速度可提高至原来的两倍,尤其在高级运行器中表现突出。
  • 免费额度:每月提供 1,250 分钟的免费使用时间。
  • 硬件配置:提供多种规格(2 至 16 个 vCPU,8GB 至 64GB RAM),以满足不同工作负载需求。

运行器类型

  • 标准运行器:采用新一代 AMD EPYC Genoa 处理器,性价比比 GitHub 托管运行器高 7 倍,适合常规任务。
  • 高级运行器:搭载高性能 AMD Ryzen 9 游戏处理器,价格性能比比 GitHub 托管运行器高 7 倍,适用于对速度要求极高的构建场景。

安全与隐私特性

  • 隔离环境:每个作业在干净且临时的 Linux KVM 全隔离虚拟机中运行。
  • 密钥管理:支持 GitHub 即时(Just-In-Time)运行器配置,用于管理临时密钥,并实现静态与传输中数据加密。
  • 自动防护:内置密钥自动轮换、防火墙自动配置以及自动化漏洞警报功能。

开源与集成

  • 完全开源:源代码在 GitHub 上公开,用户可自主选择管理自己的运行器或使用 Ubicloud 的托管服务。
  • 无缝兼容:与 GitHub Actions 完全兼容,仅需修改一行工作流配置即可集成,预计 5 分钟内完成设置。

总结

Ubicloud 通过其开源架构、高性能硬件、强化的安全措施以及显著的成本优势,为 GitHub Actions 用户提供了一个高效且经济的运行器替代方案。

3. Tear up unused parking lots, plant trees (danrodricks.com)

废弃停车场改造:应对城市空间浪费与环境挑战

文章以巴尔的摩一家斯台普斯商店后的大型停车场为例,指出许多城市和郊区的停车场长期处于严重闲置状态。作者提议,巴尔的摩及周边县区应进行“无用停车场清查”,识别那些不再需要或规模过大的硬化地面(包括公共和私人区域),例如衰落的购物中心、废弃工业建筑等。建议将这些不必要的沥青地面清除,恢复为城市森林,或将其转化为其他有建设性的用途,如新建住房或太阳能发电场。

这一问题的根源在于过去城市规划与法规过度依赖汽车,导致停车位供应远超实际需求。引用《Slate》杂志撰稿人亨利·格拉巴尔在《铺就的天堂:停车场如何解释世界》一书中的观点,他指出全美停车位数量至少是汽车数量的四倍,意味着停车场平均占用率仅约25%,实际闲置率可能更高。

作者认为,尽管停车场在美国文化和环境中已根深蒂固,但生活方式与工作模式的变化(如购物中心衰落、实体零售业下滑、疫情后远程办公普及)已显著降低了对停车场的需求。同时,大面积沥青路面对人类健康及地球生态均产生负面影响。

4. Google search drops cache link from search results (www.seroundtable.com)

谷歌搜索已从搜索结果页面中移除缓存链接,这意味着用户点击搜索结果片段的三点菜单时,不再看到缓存按钮。经过多月测试后确认了这一变化,但用户仍可通过手动输入“cache:domain.com”(例如“cache:seroundtable.com”)来访问缓存内容。

谷歌搜索联络员丹尼·沙利文(Danny Sullivan)正式确认了缓存链接的废弃,解释说这一功能最初是为了帮助用户在网页加载不可靠的时代访问页面,但随着技术改善已不再必要。他个人表示希望未来能在“关于此结果”部分添加互联网档案馆(Internet Archive)的链接,以展示页面随时间的变化,但目前仅为提议,需进一步协调。

此外,拥有搜索控制台(Search Console)账户的用户仍可使用URL检查器(URL Inspector)查看爬虫内容。文章提醒“cache:”搜索命令也将在不久后停用,但“noarchive”指令将继续被尊重。论坛讨论和用户反馈显示部分用户可能仍处于测试组,但整体功能已逐步淘汰。

5. Why flying insects gather at artificial light (www.nature.com)

该研究通过野外立体摄影和实验室运动捕捉技术,对10个目昆虫在人造光周围的飞行行为进行了系统分析,揭示了飞虫聚集于人造光的主要原因是人造光干扰了昆虫依赖视觉确定姿态方向的“背光响应”机制,而非此前广为接受的导航或热吸引等假说。

核心发现:

  1. 异常飞行模式:昆虫在人造点光源周围表现出三种典型异常行为:环绕(围绕光源稳定盘旋)、失速(背对光源爬升直至失速)和翻转(飞越光源上空时姿态反转并俯冲)。这些行为在无光黑暗中极少出现,表明昆虫并非直接飞向光源,而是主要以与光源方向垂直的路径飞行。

  2. 背光响应干扰假说:研究提出,昆虫长期进化中依靠将视野最亮区域(通常是天空)朝上的背光响应来确定自身姿态(哪边是“上”)。附近的人造点光源会误导昆虫,使其错误地将光视为“上方”,导致昆虫持续将背脊朝向光源倾斜。这种姿态控制错误扰乱了昆虫的升力产生和航向稳定,从而引发了环绕、失速和翻转等异常行为模式,并将昆虫困在光源附近。

  3. 实验与模拟验证

    • 运动捕捉数据证实,昆虫在人造光附近飞行时,其身体轴线会强烈地向光源方向倾斜,且这种倾斜是导致异常飞行轨迹(如垂直于光源飞行)的直接原因。
    • 关键对比实验:当使用朝上的、产生漫射光罩(模拟天空)的UV光源时,昆虫能正常飞行,不出现聚集和异常行为;而当同一光源朝下时,昆虫则出现翻转和坠落。这直接支持了“光源方向误导姿态”的机制。
    • 计算机模拟显示,仅在模拟中引入一个简单的“将背脊朝向光源倾斜”的控制规则,就能完全复现野外和实验室中观察到的三种异常飞行模式,证明该行为机制足以解释光陷阱现象。
  4. 排除其他假说:研究通过实验证据排除了其他主流假说:

    • 导航罗盘干扰:通过快速切换两个光源的实验发现,昆虫能轻易改变盘旋方向,这与保持恒定方位角的罗盘导航预期不符。
    • 热辐射吸引:LED光源几乎无红外辐射,但仍能强烈吸引昆虫。
    • 致盲或逃逸机制:观察到的规律性飞行模式(如稳定的环绕)与无方向性的致盲逃逸行为不符。

意义与例外: 该研究将问题从“导航干扰”转变为“姿态控制扰动”,为理解光污染对昆虫的影响提供了新视角。研究指出,减少不必要的、无遮挡的、朝上或产生地面反射的人造光,可以减轻对夜间飞行昆虫的负面影响。同时,研究也发现了例外物种(如夹竹桃天蛾和果蝇),表明不同物种可能依赖不同的姿态感知机制或对光的敏感性存在差异,这为未来研究提供了方向。

6. The Far Side – By Gary Larson (www.thefarside.com)

该网站由安德鲁斯·麦克米尔通用公司(Andrews McMeel Universal)托管和运营。版权© 2019-2026 FarWorks, Inc. 保留所有权利。经许可使用。 《The Far Side》®、FarWorks, Inc.®、《Tales From The Far Side》®、拉森(Larson)®签名、阿米巴(Amoeba)®标志和奶牛(Cow)®标志是FarWorks, Inc.在某些国家的注册商标。 未经版权所有者事先书面许可,不得以任何形式或任何方式(包括通过任何计算机或无线网络)复制、数字化、存储于检索系统、提供或传输本网站上显示的任何图像或其他内容。 服务条款 | 隐私政策 | 请勿出售或分享我的个人信息

7. Macaroons Escalated Quickly (fly.io)

Fly.io 采用 Macaroon 作为其新的安全令牌系统。Macaroon 是一种基于 HMAC(哈希消息认证码)的 bearer 令牌,其核心特点是允许通过附加被称为“caveats”(限制条件)的声明来逐步限制令牌的权限。任何持有令牌的用户都可以自行添加这些限制条件,而无需服务器的直接参与,这为权限的精细化和委托提供了极大灵活性。

技术实现与核心机制:

  1. 基本结构:Macaroon 由用户ID、随机数和一个 HMAC 签名链组成。验证时,服务器根据用户ID查找密钥,并重新计算 HMAC 链以验证签名。
  2. Caveats(限制条件):每个 caveat 是一个 JSON 对象,描述了对请求的限制(例如 {'path': '/images'}{'op': 'read'})。新 caveat 通过使用前一个 HMAC 的输出作为密钥,对其内容进行 HMAC 签名来添加。因此,caveats 链式连接,且添加 caveat 只会削弱而非增强令牌的权限。
  3. 第一方 Caveats:由令牌颁发平台(如 Fly.io)定义和检查的规则,用于表达诸如组织、应用、机器等资源的访问权限(读、写、控制等)。
  4. 第三方 Caveats:这是 Macaroon 的强大特性。它允许集成外部服务(如 SSO、审计日志、自定义逻辑)。实现时,会生成一个加密的“票证”供外部服务读取,以及一个加密的“挑战”供平台验证。用户需要从第三方服务获取一个“discharge macaroon”(解除 macaroon)与原始 macaroon 一同提交才能通过验证。这构建了一个去中心化的授权插件系统。
  5. 实现细节:Fly.io 的正式实现使用了 Go 语言、SHA-256、Chapoly 加密和 MsgPack 编码。他们将令牌的验证(检查 HMAC 签名)和清除(评估 caveats)分开处理。验证由一个物理隔离的专用服务完成,并利用分布式 SQLite 数据库(LiteFS)实现全球快速验证和缓存。

在 Fly.io 的应用与优势:

  • 灵活的权限系统:通过组合不同的 caveats,可以表达从管理员全权限令牌到最小化部署令牌等各种角色,用户甚至可以定义自己的角色。
  • 安全令牌传输:Macaroon 本身只包含权限声明,不包含认证信息。真正的用户认证通过附加的“登录服务”第三方 caveat 实现,使得权限令牌可以相对安全地在用户间传递。
  • 集成 SSO:可以轻松添加要求 Google、Github 等 SSO 登录的 caveat,并能按组织(Organization)要求不同的 SSO 策略。
  • 服务间授权与安全暴露 API:可以将用户令牌转换为“服务令牌”,并进一步通过 caveat 将其锁定到特定的工作服务器或 Fly Machine。这使得平台可以安全地向客户虚拟机暴露自身 API,同时确保访问可追溯,且能防止令牌被盗用。
  • 插件化与扩展性:第三方 caveat 机制本身就是一个插件系统。Fly.io 演示了一个 Slack 机器人示例,该机器人可以接受票证并返回 discharge macaroon,从而参与授权决策,而整个过程仅依赖密码学,无需平台预先知晓 Slack。
  • 令牌撤销:每个 Macaroon 都有一个唯一的随机数标识,平台可以通过该标识撤销令牌,并通过缓存失效机制全球同步。

总结:Fly.io 通过实现 Macaroon,获得了一套强大、灵活且用户可编程的权限管理系统。它不仅解决了传统 API 令牌过于强大、角色定义僵化的问题,还通过第三方 caveat 机制打开了集成外部认证逻辑和实现最小权限原则的大门,显著提升了系统的安全性和可扩展性。

9. RavenDB 6.0.2 (A Jepsen Report) (jepsen.io)

本文总结了Jepsen对RavenDB 6.0.2数据库的独立测试报告,揭示了其事务一致性保证与官方宣传存在严重不符。

核心发现

测试发现,即使在健康的单节点集群中,RavenDB 6.0.2也存在严重的安全性异常:

  1. 默认丢失更新:在默认的单节点事务模式下,事务会频繁丢失更新,违反了快照隔离(Snapshot Isolation)和可串行化(Serializability)等基本隔离保证。
  2. 断裂读取(Fractured Reads)
    • 开启乐观并发(optimisticConcurrency)后,虽然避免了丢失更新,但允许断裂读取:一个事务可能观察到另一个事务的部分效果,但非全部。
    • 在集群范围事务(CLUSTER_WIDE)模式下,虽然旨在提供可串行化隔离,但同样存在断裂读取现象。 断裂读取是快照隔离及多种更弱一致性模型(如读原子、因果一致性等)所禁止的严重异常。

关键问题分析

  • 文档与宣传矛盾:RavenDB官方声称提供“ACID事务”、“快照隔离”和“可串行化”,但测试表明这些保证均无法实现。文档中关于节点独立运行(导致不可用性)与ACID保证的表述存在理论冲突。
  • “事务”定义模糊
    • 文档和营销材料多次声明“会话代表一个单一业务事务”。
    • 但CEO在问题回复中解释称,事务仅限于单个HTTP请求(如SaveChanges()调用),会话并非交互式事务。这与文档描述严重不符,易使用户误解。
  • 一致性与可用性理论矛盾:RavenDB数据库层被描述为基于最终一致性的AP系统,但同时声称提供ACID事务(属于CP属性),这在理论上是不兼容的。

测试细节

  • 测试环境:单节点Debian Bookworm,使用RavenDB JVM客户端5.0.4。
  • 工作负载:使用Elle工具进行列表追加工作负载,验证事务隔离性。
  • 异常案例:测试中,多个事务读取同一键值后进行追加操作,均成功提交,导致更新丢失或列表顺序不一致。

建议

  1. RavenDB应修正文档和营销材料:移除关于“ACID”、“可串行化”和“快照隔离”的声明,转而提供准确、内部一致的安全属性描述(例如,默认提供“读已提交”或“单调原子视图”,并明确说明断裂读取等异常的存在)。
  2. 用户需谨慎评估:依赖RavenDB事务安全性的应用应重新评估其设计,考虑在并发场景下进行简单测试以验证应用不变量。
  3. 明确事务定义:RavenDB应统一术语,清晰区分“会话”与“事务”的范围和一致性保证,避免误导用户。

未来研究方向

报告指出,此测试仅针对无故障单节点集群。未来研究可扩展至多节点集群、引入网络/进程故障,以及评估次级索引、分片事务等复杂场景的安全性。

10. Show HN: Open SaaS – An open-source alternative to paid boilerplate starters (github.com)

Open SaaS:开源免费的 SaaS 应用启动模板

概述

Open SaaS 是一个完全开源、免费的 SaaS 应用模板,旨在替代市面上的付费样板项目。它提供开箱即用的丰富功能,并支持与主流 AI 编码工具(如 Claude Code、Cursor)集成。

核心特性

  • 全栈解决方案:基于 Wasp 框架(集成 React、Node.js、Prisma),可快速构建全栈应用。
  • 开箱即用功能
    • 🔐 完整身份验证:支持邮箱验证与社交登录。
    • 💳 支付集成:兼容 Stripe、Polar.sh 或 Lemon Squeezy。
    • 📊 分析工具:支持 Plausible 或 Google Analytics。
    • 📁 文件存储:集成 AWS S3。
    • 📧 邮件服务:支持 SendGrid、MailGun 或 SMTP。
    • 🧪 端到端测试:使用 Playwright 进行测试。
    • 🤖 AI 集成:提供 OpenAI API 调用示例。
  • 开发体验优化
    • ⛑️ 端到端类型安全:自动生成前后端类型推断。
    • ⚙️ 后台任务:通过配置文件定义定时任务或队列。
    • 🚀 一键部署:支持通过 CLI 部署至 Railway 或 Fly.io。
    • 💅 UI 组件:使用 ShadCN UI 构建界面与管理后台。

技术栈

  • 核心框架:Wasp(全栈)、Astro(文档/博客)
  • 前端/组件:ShadCN UI
  • 支付网关:Stripe / Polar.sh / Lemon Squeezy
  • 数据库:Prisma(通过 Wasp 集成)
  • 测试工具:Playwright

快速开始

  1. 安装 Wasp CLI(macOS/Linux/Windows WSL):
    npm i -g @wasp.sh/wasp-cli
    
  2. 创建新项目:
    wasp new
    
    此命令将基于 Open SaaS 模板生成一个新目录,可立即开始开发。

文档与支持

  • 详细文档:涵盖安装、更新、服务集成、SEO、部署等内容,详见 Open SaaS Docs
  • 社区支持
    • Wasp Discord 的 #🙋questions 频道提问。
    • 通过 GitHub Issues 反馈问题。

开发与贡献

  • 代码质量工具
    • Prettier:自动格式化代码(npm run prettier:check)。
    • ESLint:代码检查与自动修复(npm run lint:fix)。
  • 欢迎贡献:项目鼓励社区参与完善功能,详见 CONTRIBUTING.md
11. The business of check cashing (www.bitsaboutmoney.com)

支票兑现业务解析

业务概述

支票兑现(Check Cashing)是一种替代性金融服务,主要服务于社会经济边缘人群,帮助其将工资支票、政府福利支票等快速兑换为现金或可直接使用的资金,并收取一定手续费。该业务与发薪日贷款(Payday Loans)虽有重叠,但性质不同。其存在虽具争议,却因满足特定群体的金融需求而持续运营。

运作流程与核心机制

支票兑现基本流程

  1. 无银行账户场景:客户携带实体支票至“货币兑换”等商业网点,经工作人员核实身份(可能无需政府ID)并要求背书后,当场获得扣除了手续费的现金。
  2. 背书的法律意义:背书是将支票支付权利转让给兑现机构的合法程序,使兑现机构成为支票的新收款人,后续资金清算在兑现机构的银行与出票人银行间进行。
  3. 信用风险本质:银行或兑现机构在兑现支票时,实质是向客户预先提供短期信用,因为支票可能因出票人资金不足(NSF)或欺诈等原因被退回,机构需承担追索风险。

费用结构

兑现费用根据支票类型和金额分层定价,典型示例如下:

  • 公共援助支票:固定费率1.5%
  • 工资支票/政府支票:低于100美元收2.40%+$1,高于100美元收2.33%
  • 个人支票:低于100美元收2.45%+$1,高于100美元收3.00% 费用覆盖信用风险、运营成本(门店租金、人力、合规)及银行合作成本。

客户群体与市场逻辑

未银行化(Unbanked)群体的选择动因

  • 银行服务门槛:部分人群因信用记录不佳(如曾退票)被传统银行拒绝开设支票账户,无法享受低成本兑现服务。
  • 服务体验差异:银行柜员常因制度约束表现出对低收入群体的疏离感,而兑现网点工作人员往往更亲和、不具评判性,提升了客户体验。
  • 成本规避:传统银行账户虽看似“免费”,但可能通过高额透支费(尤其针对经济不稳定群体)变相获利,部分人认为兑现手续费更透明可控。

商业可行性

  • 风险定价:费用中的信用风险溢价反映不同支票类型的违约概率,但主要风险来自出票人;收款人风险通常由兑现机构吸收(约占运营成本的20%)。
  • 身份管控:通过记录客户身份(如拍照、保存ID副本)和黑名单管理控制违约风险。
  • 规模效应:通过大量小额交易实现盈利,依赖稳定客流覆盖成本。

技术变革与替代方案

移动应用与金融科技的冲击

  • 成本降低:数字兑现(如Ingo Money)通过去除实体网点、自动化处理,将500美元工资支票的手续费从$11.65降至$5,并提供延迟10天免费兑现选项。
  • 服务集成:Cash App等产品将支票兑现嵌入综合金融生态,鼓励用户直接存款,降低传统支票依赖。
  • 公共福利电子化:政府福利通过EBT卡等电子方式发放,减少纸质支票及其兑现需求。

社会背景与批评

现实存在性

支票兑现业务反映了美国社会阶层分化与金融排斥现象。银行通过风险规避间接将低收入客户推向替代金融体系,而兑现网点成为连接两个阶层的“防火墙”,其工作人员需具备传统银行缺乏的同理心与灵活性。

争议焦点

批评者认为该业务“掠夺穷人”,因手续费实质是贫困税(如每年$574)。但支持者指出,若取消此服务,部分群体可能面临更严峻的金融真空,且银行未提供有效替代方案。

总结

支票兑现业务是传统金融体系缺陷的补充,其存在基于深刻的信用风险逻辑、社会阶层隔离现实与特定群体的刚性需求。尽管费用高昂且常被诟病,但在银行服务缺失或排斥低收入人群的背景下,它提供了关键的金融接入途径。技术革新正通过降低成本、提升包容性逐步改善该领域,但彻底变革仍需银行系统与社会政策的协同推进。

12. Neovide – A simple, no-nonsense, cross-platform GUI for Neovim (neovide.dev)

Neovide简介

Neovide是一个为Neovim设计的简单、直截了当、跨平台图形用户界面。Neovim是Vim编辑器的积极重构版本,旨在提供现代化的编辑器功能。Neovide在可能的情况下进行了图形改进,但功能上应与终端UI保持一致,确保用户熟悉的操作体验。

主要特点与资源

  • 设计原则:强调简单性和跨平台兼容性,支持Windows、macOS和Linux等操作系统。
  • 图形改进:优化视觉效果,但不改变Neovim的核心功能,使其更适用于图形环境。
  • 源代码访问:源代码托管在GitHub上,用户可自由查看和贡献(链接提供在原文中)。
  • 文档与搜索:文档支持搜索功能,可通过按s键或点击左上角放大镜图标快速查找信息。
  • 安装方式:支持通过包管理器安装或从源代码构建,满足不同用户需求。
  • 功能与配置:提供所有可用功能的列表,并允许用户自定义Neovide配置,以增强使用体验。

附加信息

内容包含一张截图示例,展示Neovide在Windows系统上的运行界面,直观呈现其图形效果。整体上,Neovide旨在为Neovim用户提供一个高效、易用的图形前端,同时保持终端编辑器的灵活性和功能完整性。

14. Google Announces Fourth Quarter and Fiscal Year 2023 Results [pdf] (abc.xyz)
15. In Praise of Buttons (www.nubero.ch)

按钮设计的价值:形式即功能

文章《按钮赞歌》批评了当前图形用户界面设计中按钮逐渐被边缘化的趋势,指出许多设计师为了追求“新颖”而放弃了按钮清晰可辨的形态,这实际上损害了用户体验。

按钮的本质与趋势 按钮因其长期有效而被视为“陈旧”,但这恰恰是其价值所在。然而,一些设计师为了标新立异,会重新设计按钮的外观或功能,并包装为“最新设计”,却忽视了用户需求。

图形界面中的问题按钮 当前流行的一种设计是使用纯文本或图标作为按钮,缺乏明确的按钮形状(如谷歌的Material Design或苹果iOS 7的扁平化设计)。这种“极简主义”可能显得现代,但未必用户友好。

  • 图标示例:仅靠图标的按钮(如加号、减号)无法自身传达“可点击”的意图,依赖上下文才能被识别。
  • 瑞士军刀的启示:物理产品(如军刀的指甲槽)通过形态设计明确提示功能,虚拟按钮同样需要清晰的“示意符”来告诉用户此处可操作。
  • 分组与间距:有统一形状的按钮更容易让用户感知元素之间的分组和间距关系。
  • 触控区域问题:在触屏界面,纯图标按钮的实际可点击区域往往很小,容易导致误触或漏按。

文本按钮的困境 当按钮仅为文字时(如“同意”与“不同意”),问题更突出。苹果iOS更新条款中的文字按钮仅靠颜色区分,与大量文本混杂,且字体选择欠佳,难以快速识别。

  • 改进示例:通过增加按钮形状、选用字形更清晰的字体(如FF Unit),并利用阴影区分文本区域,能显著提升可读性和可操作性。

直接操作与反馈的重要性 物理世界的动作会带来多感官反馈(触觉、听觉、视觉)。大脑期望这种反馈,并通过其构建对世界的认知。

  • 缺失的反馈:没有按钮形状的界面按钮通常也缺乏视觉反馈(如下压状态),用户在触屏时可能因手指遮挡而无法确认操作是否成功。
  • 等待期间的 reassurance:当操作需要时间加载时,按钮被按下后的状态变化能提供即时反馈,安抚用户。
  • 多感官反馈:理想情况下应结合视觉、听觉和触觉反馈,模拟物理交互的连贯性。

设计案例:苹果照片应用 iOS 17照片应用在“选择”和省略号按钮上使用了模糊的按钮形状,而“相簿”按钮却仅靠文字和箭头。设计逻辑不一致。改进版则确保所有可点击元素外观统一且明确。

回应批评:非怀旧主义 支持扁平化设计的人可能指责作者怀旧。但作者强调,核心是产品必须好用。如果一个元素功能如同按钮,其外观就应呈现按钮的特征。这并非全盘否定扁平设计,而是反对为了形式而牺牲功能的“懒惰极简主义”。

结论:降低认知负荷 设计的根本目标是降低用户认知负荷。大脑通过模式识别和环境分区来工作。让不同功能的元素具有明显不同的外观,比让一切看起来“简化”更有效。虽然某些界面(如网站)可以灵活设计按钮外观,但在操作系统等核心交互中,按钮应保持其应有的清晰示意作用。

16. Constructing a Four-Point Egg (dotat.at)

这篇文章介绍了如何用几何方法构造一个四点蛋形(Four-Point Egg),并提供了用于计算机绘图的具体参数。

核心构造过程如下:

  1. 基础设定:从坐标轴和单位圆开始。使用角度单位“圈”(τ,即一圈),从正午方向顺时针测量。
  2. 绘制下部(大端)
    • 首先画一条从单位圆的南点(0,-1)出发、半径为2的圆弧,从τ·3/8到τ·5/8,形成蛋形宽大的底部。
    • 接着,以西点(-1,0)为圆心、半径为2+√2,画一条从τ·2/8到τ·3/8的圆弧,构成蛋形的右下部分。
    • 左下部分对称绘制,以东点(1,0)为圆心、相同半径,从τ·3/8到τ·2/8。
  3. 确定上部起点与中心:下部右左两条圆弧在X轴上的交点即为蛋形的东点和西点。以此两点画一个辅助圆,该圆与Y轴正半轴的交点(0, 1+√2)即为蛋形的“北中心”。
  4. 绘制上部(小端)
    • 以西点(-1,0)为圆心、半径为2+2√2,画一条从τ·1/8到τ·2/8的圆弧,构成上部右侧。
    • 上部左侧对称绘制,以东点(1,0)为圆心、相同半径。
    • 最后,以北中心(0, 1+√2)为圆心、半径为√2,画一条从τ·1/8到τ·1/8的圆弧,连接上方两条圆弧的末端,形成尖细的顶部。

关键要点

  • 整个蛋形由6段圆弧光滑连接而成,这些圆弧的圆心共6个,其中4个对应于蛋形的“四点”。
  • 作者指出,虽然构造看似固定,但其中一些选择(如辅助线位置)具有一定任意性,并提供了一个交互式工具以便观察调整各点时形状的变化。
  • 与Moss’s蛋(三点蛋形)相比,四点蛋形的上半部分相同,但下半部分由两个斜向圆弧构成,而非简单的半圆。
17. XFaaS: Hyperscale and Low Cost Serverless Functions at Meta (www.micahlerner.com)

XFaaS:Meta超大规模低成本的无服务器函数系统

概述

本文介绍了Meta内部的无服务器函数即服务系统XFaaS,该系统在超过10万台服务器上每日处理数万亿次函数调用。文章重点分析了系统在达到当前状态前解决的五大挑战,以及其架构设计、性能优化和评估结果。

主要挑战

  1. 应对负载激增:处理来自Meta内部系统调度大量函数执行时的突发流量。
  2. 快速启动与执行:确保函数快速启动和运行,以改善开发者体验并提高资源利用率。
  3. 全局负载均衡:在Meta分布式私有云中实现跨区域负载均衡,避免数据中心过载。
  4. 高资源利用率:提高资源使用效率,控制运行系统的成本增长。
  5. 防止下游过载:避免函数在执行计算时通过RPC请求访问或更新数据,导致下游服务过载。

系统架构

XFaaS的多区域基础设施包含五个核心组件:

  • 提交器:系统的入口点,对客户端进行配额管理与限流,防止下游组件过载。
  • 队列负载均衡器:将函数执行请求均衡转发至持久化队列,该队列存储函数的元数据。
  • 调度器:根据函数的优先级、执行截止时间和容量配额,确定执行顺序。它使用内存中的函数缓冲区和运行队列管理调度。调度器可依据“流量矩阵”决定是否从其他区域调用函数以平衡负载。
  • 工作池:通过类似负载均衡的方式接收调度分配的执行任务。为提高利用率,系统引入局部性组,将函数的执行限制在工作池的一个子集中,减少加载代码和数据的开销。

关键优化

  1. 时间错位计算:允许函数在资源空闲时延迟执行,平滑负载。系统通过“预留配额”和“机会配额”激励用户使用此灵活性。
  2. 协作式JIT编译与配置文件引导优化:在一个工作节点上生成的性能优化代码(通过配置文件引导优化)可分发至整个集群的其他节点,共享优化成果,提升整体吞吐量。

防止下游过载机制

系统借鉴了TCP中的背压机制(加法增大/乘法减小),当下游服务出现问题时,会自动减少对这些服务的函数执行,避免加剧故障。

系统评估

  • 高利用率与负载平滑:CPU利用率的峰谷比仅为1.4倍,相比接收请求的4.3倍峰谷比有显著改善,部分归功于时间错位计算的灵活配额。
  • 工作池稳定性:通过局部性组,单个工作者执行的函数数量和内存利用率保持相对稳定。
  • 性能提升:配置文件引导优化显著提高了吞吐量。
  • 过载防御有效性:在下游服务(如图数据库TAO)发生故障时,系统成功减少了对相关服务的函数执行,避免了情况恶化。

结论与讨论

XFaaS展示了在超大规模下运行无服务器系统的独特实践。其高利用率数据(远超以往研究)引人注目,但这也得益于其在封闭环境、安全隔离要求较低以及不处理用户交互路径上的延迟敏感函数等特殊约束条件。文章指出,部分系统执行的函数可能更适合批处理作业,并对基于“轶事知识”的超高利用率声明提出了数据来源的疑问。

19. Intel's Humbling (stratechery.com)

本文围绕英特尔的困境与转型展开分析,重点探讨了其战略失误、当前挑战、复苏努力以及一项关键的新合作。

核心困境与历史失误

  • 战略错过时机:2013年,时任CEO科兹安尼克未采纳建议,将英特尔转型为代工厂(为外部客户制造芯片),而是继续专注于自有芯片设计与制造(IDM模式)。这导致英特尔错过了十年构建客户服务能力的机会。
  • 丧失制程领导地位:在科兹安尼克任期内,英特尔在先进制程(如10nm)上一再延迟,被台积电超越。尽管股价因短期财务表现良好而上涨,但长期隐患已埋下。
  • 当前危机:现任CEO基辛格正为此买单。2024年一季度业绩指引不及预期,股价大跌。问题在于数据中心CPU市场被AMD(使用台积电更优制程)蚕食,同时面临ARM架构和AI计算(转向GPU)的竞争压力。

基辛格的复苏战略

基辛格正在执行十年前该做的战略转型:

  1. 重返制程领先:推进“四年五个节点”计划,旨在通过Intel 18A(相当于台积电2nm级别,采用RibbonFET晶体管和背面供电)重回制程领导地位。目前进展按计划进行,且已流片客户产品。
  2. 发展代工业务:努力将英特尔转变为代工厂。已获得超过50个测试芯片订单,并争取到了包括一个高性能计算客户在内的四个Intel 18A代工客户。但最终成功取决于外部客户芯片的商用,这仍需数年时间。

关键新合作:英特尔与联电

为应对挑战并填充闲置产能,英特尔与台湾联电达成合作:

  • 合作内容:共同开发12纳米制程,计划于2027年在亚利桑那州生产。该技术适用于物联网、连接芯片等非尖端应用。
  • 互补性:联电拥有成熟的客户服务与知识产权(IP)库,但缺乏投资尖端制程的资本;英特尔则拥有大量闲置的成熟制程(如14nm)产能和已折旧的设备。此合作结合了联电的客户服务能力与英特尔的闲置产能。
  • 战略意义:这是一个务实且重要的举措。它能为英特尔带来急需的现金流,而无需巨额新投资。虽然技术不算先进,且面临台积电7nm的竞争,但它能利用英特尔已有的资产产生利润,支持其前沿制程的豪赌。文章认为,这种“屈辱”的合作比任何空谈都更能表明英特尔正在务实求变。

总结

英特尔正处在一个关键转折点。它面临短期财务压力和市场份额流失的严峻现实,同时正投入巨资押注于长期的制程技术复兴和代工业务转型。与联电的合作是一个聪明的短期策略,旨在利用闲置产能创造价值,为长期目标提供支撑。文章的核心观点是,半导体行业以十年为周期,而华尔街只关注季度财报,因此英特尔的管理层能否获得足够的时间来执行这一正确但漫长的战略,是其未来最大的不确定性。

20. Python HTTP library 'urllib3' now works in the browser (github.com)

Python HTTP库urllib3现可在浏览器中运行

🖥️ 浏览器支持

  • urllib3新增了实验性支持,可通过Pyodide在浏览器环境中运行
  • 感谢开发者Joe Marshall的贡献,此功能得益于urllib3 v2.0中将API与http.client解耦的工作
  • 目前支持在启用线程的跨域隔离浏览器环境中进行流媒体传输

🚀 HTTP/2筹款进展

  • urllib3正在筹集约40,000美元,用于:
    • 开发HTTP/2支持功能
    • 确保项目的长期可持续维护(2023年财务支持大幅下降)
  • 呼吁使用Python并受益于HTTP/2支持的企业和组织(如Requests、pip、云SDK等项目)提供财务支持

📋 主要变更

新增功能

  • 支持Emscripten和Pyodide环境(#2951)
  • 新增HTTPResponse.read1()方法支持(#3186)
  • 基础HTTP/2支持已实现(#3284)

错误修复

  • 修复使用代理访问带尾随点的URL时SSL错误(#2244)
  • 修复代理连接后proxy_is_verified可能为None的问题(#3130)
  • 修复json=请求头被意外修改的问题(#3203)
  • 修复从HTTPS代理连接HTTP目标时is_verified设置错误(#3267)
  • 修复OpenSSL 3.2.0关于HTTP代理配置的错误消息处理(#3268)
  • 修复禁用服务器证书验证时的TLS 1.3握手后认证问题(#3325)

⚠️ 注意事项

  • 下游发行商进行集成测试时,现在需要两次运行测试(包括使用--integration pytest标志,#3181)
21. NASA's Webb depicts structure in 19 nearby spiral galaxies (webbtelescope.org)

NASA韦伯望远镜描绘19个附近螺旋星系结构

核心观测成果

NASA的詹姆斯·韦伯太空望远镜(Webb)对附近19个螺旋星系进行了前所未有的详细观测,揭示了其内部结构。这一成果突显了韦伯在高分辨率近红外波段观测中的卓越能力。

韦伯望远镜关键特性

  • 折叠设计:望远镜尺寸庞大,需以类似折纸的方式折叠后装入火箭,并在太空中如“变形金刚”般展开。
  • 轨道位置:运行在距地球150万公里的太阳轨道上(相比哈勃望远镜距地球仅560公里)。
  • 防护系统:配备5层遮阳板,保护望远镜免受太阳、地球和月球的红外辐射,防护能力相当于SPF 100万。
  • 无与伦比的灵敏度:能够探测135亿多年前、大爆炸后首批星系诞生时的宇宙景象。

相关最新观测新闻

  • 星团研究(2026年5月22日):韦伯近红外图像展示了梅西耶51(M51)星系一个旋臂区的星团结构。
  • 星系核心观测(2026年5月18日):呈现了星系M77核心的明亮发光区域。
  • 其他发现:包括探测星际彗星甲烷、直接成像系外行星、重新定义行星与恒星界限等。

博客与资源动态

  • 韦伯博客提供来自任务内部视角的深度内容,涵盖早期科学数据(未经同行评审)、任务运营和工程进展。
  • 官网提供图像库、观测跟踪工具及丰富的科学主题介绍。

国际合作与科学目标

韦伯望远镜是NASA、ESA(欧洲航天局)和CSA(加拿大航天局)的联合项目,汇聚了14个国家的数千名科学家与工程师。其四大科学主题包括:早期宇宙、星系演化、恒星生命周期和系外行星。通过公民科学项目“银河动物园”,公众可协助分类韦伯最新星系图像。

22. Reverse-Engineering a Scoreboard Display (hardfault.life)

逆向工程一个计分板显示屏

项目起源

作者从闲置电子商店以4美元购得一个1996年制造的Daktronics大型七段LED显示器(原用于篮球计分板)。其尺寸为高11英寸,宽6英寸,目标是将其改造为自己的物联网小工具平台的首个实用项目。

电路分析与逆向工程

  1. 初步观察:显示器背面有9针连接器,电路板上有两个标有“R220”的芯片,后确认为电阻排(内含16个220欧姆电阻)。
  2. 走线追踪:通过光照电路板(无接地平面),发现一根较粗的走线环绕整个板子,确定为公共引脚
  3. 结构推断:每段由两组并联的LED链构成,每组包含7个LED和一个220欧姆电阻。
  4. 电气特性估算
    • 单个红色LED正向电压估算为1.9V。
    • 7个LED串联电压降:7 × 1.9V = 13.3V。
    • 电阻电压降:220Ω × 20mA = 4.4V。
    • 总电压需求约18V。
    • 整屏最大电流约280mA,功耗约5W。
  5. 实际测试:用12V电源探试,确认显示器为共阳极结构。在12V下,单LED电流仅2.2mA,亮度较暗,进一步支持18V为原始工作电压的推测。

驱动电路设计与制作

  1. 初始原型:使用2N3904晶体管搭建开关电路,可接受3.3V/5V逻辑电平控制。
  2. 扩展功能:为减少微控制器引脚占用,引入74HC74双D锁存器,通过脉冲控制段开关。
  3. 最终电路板设计
    • 采用74HC273八D锁存器,集成7个段的控制。
    • 增加24V齐纳二极管过压保护和10μF滤波电容。
    • 预留了与显示器原装TE“Mate-N-Lok”连接器兼容的接口。
    • 电路板设计为可与显示器安装孔对齐,便于固定。

物联网平台集成尝试

  1. 驱动开发:在Zephyr RTOS中实现了七段显示器驱动(基于auxdisplay API),并通过微控制器成功点亮显示器(测试用12V,额定用18V,亮度差异显著)。
  2. 遇到的问题:尝试连接MQTT时,Zephyr的ESP32-AT驱动在处理接收到的TCP数据包时出现错误,无法正确解析SUBACK,导致集成失败。作者认为此驱动存在缺陷或兼容性问题,并考虑更换Wi-Fi模块。

总结

项目成功将一块废旧工业显示器逆向工程并改造为可控的七段LED显示屏,制作了专用驱动电路板,并初步尝试了物联网集成。主要挑战在于最终MQTT连接的底层驱动兼容性问题。

23. Show HN: Twine – Open source multiplatform RSS app (github.com)

Twine:开源跨平台RSS阅读器

Twine 是一款使用 KotlinCompose Multiplatform 构建的现代跨平台RSS阅读器应用。它提供了出色的用户体验,并能根据内容动态改变应用的主题颜色。

主要功能特性

  • 广泛的格式支持:兼容 RDF, RSS, Atom 和 JSON 格式的Feed源。
  • 完善的Feed管理:支持添加、编辑、删除、置顶和分组Feed。
  • 高效的浏览体验:主屏幕底部栏可快速访问置顶的Feed和分组;提供智能Feed发现功能(输入任何网站主页即可查找其Feed)。
  • 深度阅读与收听:文章阅读器内可一键获取全文;内置音频播放器支持播客和HTML音频标签。
  • 个性化与整理:支持自定义阅读器视图(字体、颜色)、收藏文章稍后阅读、搜索文章、设置关键词过滤(屏蔽词)。
  • 同步与备份:支持后台同步,并可与 FreshRSS (GReader), Miniflux, Dropbox(Alpha阶段)进行云同步。支持通过OPML格式导入和导出订阅源。
  • 外观与集成:提供主屏幕小部件、应用图标自定义,以及亮色、暗色和纯黑主题。

项目架构

项目采用模块化的 Kotlin Multiplatform 结构:

  • androidApp: Android 平台特定的应用代码和入口。
  • iosApp: iOS 平台特定的应用代码(Swift/Xcode项目)。
  • shared: 包含使用 Compose Multiplatform 构建的核心UI逻辑、ViewModel(使用 kotlin-inject)和共享的展示逻辑。
  • core/: 模块化的业务逻辑层,进一步细分为:
    • base: 基础工具、通用接口和平台抽象。
    • data: 数据层,包含仓库、本地数据库(SQLDelight)和同步逻辑。
    • model: 跨项目使用的领域模型。
    • network: 网络层,使用 Ktor 进行Feed获取和解析。
  • resources/icons: 共享的图标资源。

技术栈

核心依赖包括:

  • Kotlin Multiplatform & Compose Multiplatform
  • Kotlin CoroutinesKtorSQLDelight
  • Kotlin-injectCoilMultiplatform Markdown Renderer
  • Jetpack 库 (完整依赖列表详见项目的 libs.versions.toml 文件)

开发与贡献

  • 开发:克隆仓库后即可本地构建,需要 JDK 21+,并根据 libs.versions.toml 中定义的AGP版本使用相应的Android Studio导入项目。
  • 贡献:可通过提交PR来修复Bug,其他改进请先开Issue讨论。代码格式化使用 ktfmt(通过 spotless gradle 插件提供)和项目内置的 IntelliJ 代码风格,提交PR前需运行 ./gradlew spotlessApply 进行格式化。
  • 翻译:项目翻译可在 Crowdin 上协助完成,字符串资源使用Compose资源管理。

项目信息

Sasikanth Miriyampalli(开发)与 Eduardo Pratti(设计)共同创建,错误报告由 Sentry 支持。项目采用开源许可证。

25. The Vision Pro (daringfireball.net)

Apple Vision Pro 评测摘要

总体印象

作者将Apple Vision Pro同时视为三款革命性产品:一款眼动追踪的VR/AR头显、一个空间计算生产力平台,以及一个突破性的个人娱乐设备。它被比作像1984年Macintosh和2007年iPhone一样定义时代的里程碑产品,但其第一代硬件仍受限于当前技术,存在明显的短板。

硬件设计与体验

  • 外形与佩戴:设备本身较大较重(约650g),需通过磁吸的光密封件和两种头带(单圈针织头带或双环头带)进行个性化佩戴调整,以确保舒适和光学对准。佩戴过程需要一点学习时间。
  • 电池与续航:必须外接一个重约325g的电池组,续航时间约为2至2.5小时,断电即关机。电池无法热插拔。
  • 操控与设置:通过“注视与捏合”手势进行主要交互。初始设置包括眼动追踪校准和从iPhone/iPad导入设置,过程平滑。
  • 耐用性与便携:设备需小心处理以防刮擦,配有磁吸保护盖。附带的旅行盒体积较大。
  • 局限性:重量和体积令人疲劳,不适合运动使用。没有内置备用电池,电源线可能带来不便。

VisionOS 空间计算平台

  • 革命性交互:“注视与捏合”操控模式被认为是像Mac的“指向与点击”和iPhone的“触摸与滑动”一样自然的交互范式革新。
  • 无边界工作空间:应用窗口可置于用户所处的真实物理空间中,尺寸远大于传统显示器,并能保持在现实世界中的位置锚定。用户可移动并在不同房间重现相同的窗口布局。
  • 直观的窗口管理:窗口控制栏位于底部以免遮挡内容,支持在Z轴(深度)上自由移动和排列窗口,带来沉浸的科幻感。
  • 与Mac集成:“Mac虚拟显示器”功能可无线将Mac屏幕扩展为一个巨大的虚拟显示器,但在此虚拟界面内仍需使用物理键鼠操作。
  • 输入与兼容性:虚拟键盘仅适合简短输入,复杂文本输入需蓝牙键盘或语音听写。支持触控板/鼠标,iPad应用兼容性良好,但原生应用在视觉上更出色。
  • 当前状态:系统已有一些小bug,原生应用数量尚少,且应用图标(主页视图)无法手动整理。

视听与显示效果

  • 显示器:分辨率极高,肉眼不可见像素,文本显示清晰。但透视现实世界的摄像头画面存在延迟和动态范围限制,移动头部时会破坏“真实透过”的错觉。
  • 音频:内置扬声器音质卓越,空间感强,优于任何耳机,但缺乏隐私,会外泄声音。
  • 人物角色与EyeSight:用于视频通话的数字化身“人物角色”处于测试版,深度处于“恐怖谷”效应中,效果怪异。前置的EyeSight显示屏用于显示用户眼睛,但效果非常微妙,实用性存疑。

个人娱乐体验

  • 沉浸式观影:这是Vision Pro目前最震撼的功能。通过Disney+、Apple TV等原生应用,用户可置身于虚拟影院、主题环境(如《怪兽电力公司》惊吓场、《星球大战》驾驶舱)中,观看仿佛IMAX巨幕般的电影。3D效果自然,亮度无损。
  • 体育观赛:可将比赛画面放大到整个墙面大小,体验极具吸引力,尽管与他人共观赛的社交性会受到影响。
  • 总结:作者认为,单就私人影院的体验而言,Vision Pro就值回票价,其带来的震撼远超传统大屏电视。

结论

Vision Pro代表了未来计算交互的方向,其空间计算平台是真正的突破。然而,作为第一代产品,它存在重量、体积、续航、价格及部分功能(如人物角色)的明显不足。它不适合所有人,但为沉浸式个人娱乐和下一代计算平台树立了新的标杆。

26. Redeployment Part Three (brr.fyi)

文章总结

本文是“重新部署”系列文章的第三部分,记录了作者在南极洲生活工作446天后,离开南极并返回文明世界的全过程。

主要行程与经历

  1. 从南极点经停麦克默多站

    • 作者从南极点飞往麦克默多站,作为返回新西兰的中转。
    • 在麦克默多短暂停留期间,作者首次长时间呼吸海平面空气,感受到类似“超级英雄”的富氧效果,并借此精力攀登了观测山。
    • 他有机会与在南极结识的朋友重逢,目睹了麦克默多站的建设变化。
  2. 离开南极洲

    • 作者乘坐麦克默多站的新型大型运输车“Kress”前往凤凰机场。
    • 最终搭乘一架意大利空军的C-130J运输机,于2023年11月17日离开南极洲,结束了446天的南极之旅。
  3. 抵达新西兰基督城

    • 飞机于次日凌晨抵达基督城国际机场。
    • 作者首次嗅到雨水、泥土和生命的气息,标志着重返“真实世界”。
    • 他完成了入境手续,归还了美国南极计划(USAP)发放的极寒天气装备(ECW),并被安排入住酒店。
  4. 新西兰的休闲旅行

    • 作者在新西兰进行了为期两周的休整,尽情享受新鲜的食物(如咖啡、水果、蔬菜)、阳光和自然风光(如阿瑟山口、普纳凯基)。
    • 这段时间让他从长期的南极生活中恢复,并逐渐适应现代文明。
  5. 返回旧金山

    • 2023年12月1日,作者从基督城飞回旧金山,结束了整个重新部署旅程。
    • 回到离开16个月的公寓后,他发现回归“现实生活”的感觉异常平静。尽管经历了南极这一与世隔绝的奇特世界,但日常生活技能(如加油、去杂货店)迅速恢复,两种生活现实似乎自然而然地分离开来。

感受与反思

  • 作者回顾了自己独特的经历:一次性体验了南极的“飞行”(Winfly)、冬季、夏季、极夜和日出,这是大多数南极工作者不会在单次任务中完成的。
  • 他肯定了这段漫长旅程的价值,但也提醒考虑类似经历的人需慎重决定,因为这是长达一年多远离亲友和常规生活的承诺。
  • 文章以作者在南极冬季拍摄的一张喜爱的照片作为结尾,再次强调了南极世界的静谧与独特。

结尾

作者以系列文章的完结,感谢了读者的陪伴与互动,并分享了写作初衷仅是为少数亲友记录,未曾预料到博客会广受欢迎。

28. Spatial Computing (hypercritical.co)

空间计算

文章回顾了图形用户界面的发展,并重点探讨了“空间计算”的概念如何利用人类天生的空间认知能力。作者认为,成功的交互设计——如Macintosh的GUI和iPhone的触摸屏——之所以高效,是因为它们利用了人类数百万年进化而来的、用于在三维世界中识别和操纵物体的本能技能。

核心观点:

  1. “直接操作”的演变与成功

    • Macintosh GUI: 创新性地引入了“直接操作”概念,允许用户通过拖拽等视觉化动作与电脑交互,而非输入文本命令。这种“间接”指向设备(鼠标)的操作,在用户看来很快就成了第二本能。
    • iPhone 触摸屏: 进一步提升了“直接操作”的程度,用户可以直接用手指触摸屏幕上的对象,消除了鼠标这一层间接性,更贴近真实世界的操作体验。
    • 共同成功关键: 两者都利用了人类与生俱来的、用于在空间中推理和操纵物体的运动技能,降低了认知负担,使交互感觉自然、高效。
  2. 人类的空间认知本能

    • 在空间中操纵物体的能力是人类成功的基础,经过自然选择深深烙印在我们的基因中。
    • 与之相对,使用计算机的特定技能(如调试网络、使用软件功能)需要专门学习,并非天生。
    • 因此,能利用我们固有空间能力的界面具有巨大优势,感觉更直观、好用。
  3. 对Apple Vision Pro 的评估

    • 进步之处: Vision Pro(苹果称其为“空间计算机”)将空间界面提升到了新高度,通过模拟深度更丰富的三维环境,比传统的2D分层GUI更彻底。
    • 潜在疑虑: 其核心交互方式——先注视对象,再进行手势操作——在作者看来可能是一种“间接”操作,类似于使用鼠标,而不如iPhone的直接触摸直观。它是否能像iPhone的滑动浏览一样直观高效,尚需时间检验。
    • 结论: 虽然Vision Pro在提供沉浸式空间体验方面无与伦比,但其当前的交互模型可能未能像Mac和iPhone那样充分利用人类的先天空间操作技能。未来可能需要技术突破,或结合传统输入工具,才能使其交互达到同样的直觉和效率水平。

总结: 文章从“直接操作”和人类空间认知的角度,审视了从Mac到iPhone再到Vision Pro的交互演变,肯定了空间计算的发展方向,但也对最新头显设备的交互直觉性提出了思考。

31. A South Carolina lawmaker is suing Instagram after his son died by suicide (www.cnn.com)

南卡罗来纳州众议员布兰登·格菲(Brandon Guffey)正在起诉Instagram的母公司Meta,指控其未能充分保护儿童免受网络掠食者的伤害,该诉讼与其17岁儿子加文(Gavin)的自杀直接相关。

2022年7月,加文在Instagram上被一名骗子引诱,误以为对方是同龄女孩,随后发送了私密照片。骗子随即以此进行性勒索,威胁要公开照片并索要钱财。加文在支付了全部积蓄25美元并恳求宽限时间后,最终在家中自杀身亡。悲剧发生后,骗子甚至通过Instagram向其家人发送嘲讽信息并继续勒索。

这起事件凸显了FBI警告的日益严重的“性勒索”犯罪问题,该犯罪主要针对青少年男孩,骗子通常位于美国境外。据FBI报告,2022年10月至2023年3月期间,涉及未成年受害者的在线金融性勒索举报增加了20%;从2021年10月到2023年3月,此类举报超过1.3万起,并导致至少20起自杀事件。

诉讼指控Meta的社交平台通过算法激进地吸引青少年,导致抑郁、焦虑等问题,并未能提供足够工具保护未成年用户。布兰登·格菲认为,社交媒体公司应对其平台上的活动负责,并引用《通信规范法》第230条作为其免责的“盾牌”。

作为回应,Meta在一份声明中表示青少年安全是其首要任务,并提供了数十种资源和工具来帮助年轻用户保持安全、举报可疑内容,以及在紧急情况下联系执法部门。

父亲布兰登·格菲在推动此事公开化的同时,也积极投身立法。他发起并通过了一项以儿子名字命名的法律——“盖文法”,将性勒索定性为加重重罪,若受害者是未成年人、弱势群体或因此导致身体伤害或死亡,将面临更严厉的刑罚。他还在手臂上纹了儿子最后发送的爱心符号(<3),致力于成为其他受害家庭的发声者。

33. RISC-V Assembler: Arithmetic (projectf.io)

本文介绍了RISC-V架构中32位基础整数指令集(RV32I)的算术指令部分。RISC-V是一种精简指令集,其指令集设计紧凑且易于学习,特别适合汇编编程。

文章首先概述了RISC-V的不同指令集版本(如RV32、RV64、RV32E),并聚焦于RV32I。它指出RV32I拥有32个32位宽的通用寄存器(x0至x31),其中x0寄存器被硬连线为零。在编程实践中,遵循应用二进制接口(ABI)有助于代码互操作性,示例中主要使用了临时寄存器(t0-t6)。

核心内容围绕算术指令展开:

  1. 加载立即数(li):这是一个伪指令,用于将32位立即数加载到寄存器。由于RISC-V指令宽度仅为32位,无法直接编码32位立即数,因此li会被汇编器翻译成一条或多条真实指令。
  2. 加法(add/addi)add指令将两个源寄存器的值相加,结果存入目标寄存器。addi指令将一个12位有符号立即数(范围-2048到2047)与源寄存器相加。addi还可用于实现递增和递减操作。基于addi衍生出两个常用伪指令:
    • mv(移动):等价于addi rd, rs1, 0,用于寄存器间数据复制。
    • nop(空操作):等价于addi x0, x0, 0,仅推进程序计数器而不做任何改变。
  3. 符号扩展:RISC-V会对立即数进行符号扩展,即用立即数的最高位填充剩余的高位,以生成32位值。这一设计简化了指令集并使其更强大。
  4. 减法(sub)sub指令将两个源寄存器相减,结果存入目标寄存器。neg伪指令用于对寄存器值取负,等价于sub rd, x0, rs1
  5. 加载高位立即数(lui):此指令将一个20位立即数加载到寄存器的高20位,并将低12位清零,相当于将立即数左移12位。

文章深入剖析了li伪指令的实现机制:它实际上是luiaddi两条指令的组合。

  • 若立即数在12位有符号范围内,li通常被翻译为单条addi指令(源操作数为x0)。
  • 若立即数仅需设置高20位,则使用单条lui指令。
  • 对于完整的32位立即数,汇编器会使用lui设置高20位,然后用addi调整低12位。需要注意的是,由于addi的符号扩展特性,当低12位的最高位为1时,需要对lui加载的高位值进行相应修正(通常加1),以确保最终结果正确。使用li伪指令时,汇编器会自动处理此修正。

文末提到,后续内容将涵盖逻辑指令、移位指令、加载与存储指令等。

34. The theory of concatenative combinators (2007) (tunes.org)

文章概述 本文阐述了串联组合子理论,该理论源于曼弗雷德·冯·图恩设计的编程语言Joy。其核心是:程序即数据,计算通过栈操作完成,无需变量。文中探讨了基于此范式的组合子逻辑。

基本组合子与栈操作 理论从几个基础组合子开始,其行为可通过改写规则定义:

  • swapdupzap:分别用于交换、复制、销毁栈顶项。
  • catconsunit:用于重组引用(即栈上的程序片段)。例如,cat连接两个引用。
  • idip:用于去引用(执行栈上的程序)。i执行栈顶程序;dip执行栈顶程序,但先移开下一项,执行完后恢复。

组合子的相互构造性与完备基 这些组合子并非独立,许多可相互定义。例如,unitcat可用cons构造,swap可用dipunit构造。文章证明了一个完备基:集合 {i, dip, cons, dup, zap} 可以通过算法消除λ表达式,从而构造出所有组合子。

引入更小的基 随后引入了多用途组合子sip(保存并恢复栈项)。证明了更小的基 {i, cons, sip, zap} 同样完备,并可进一步构造出dipdup

组合子方案 文章介绍了多种组合子方案,用于批量操作栈:

  • dign/buryn:从第n项下挖掘/向第n项下埋藏栈顶项。
  • flipn:反转栈顶n项的顺序。
  • dipn/sipndipsip的扩展,可跳过或保存多项。 文中提供了这些方案的构造方法,并揭示了它们之间的紧密联系(可相互定义)。

应用式组合子与经典关联 引入了与经典组合逻辑对应的应用式组合子:wkbcs以及t。它们与基础组合子存在转换关系(如 [] w 可构造 dup)。这揭示了经典组合逻辑与串联理论之间的形式对应。

最小完备基的探索

  • 应用式基:从应用式组合子sk出发,通过修改得到s',结合k构成了完备的二元基 {s', k}
  • 保守完备性:研究不允许破坏操作(无zap)的系统。引入修改后的j'组合子,与i构成保守完备基 {j', i}。还探讨了另一对保守基 {coup, sap}
  • 线性完备性:进一步限制,同时不允许复制和破坏操作。探讨了线性基 {take, cat, i} 以及二元线性基 {cons, sap}

组合子与数字表示

  • 引入了组合子方案repn(重复执行程序n次)。
  • 引入了“Z组合子”方案zn,可用于表示数字(丘奇数)。定义了其上的算术运算(加法、乘法、指数),并展示了如何用repn方案类似地表示数字。

关于程序构造的说明 文末提到一个用于搜索组合子构造的计算机程序,但由于采用暴力搜索算法效率低下,仅适用于小规模构造。建议采用带回溯的增量搜索算法来改进。

35. Ask HN: Any good Silicon Valley Photo coffee table books?
36. Eleven US states now get over half their electricity from renewables (theprogressplaybook.com)

美国11个州可再生能源发电占比超50%

根据斯坦福大学教授马克·Z·雅各布森汇编的数据,美国目前有11个州每年产生的可再生能源足以覆盖其至少50%的电力需求。其中包括经济产出最大的州——加利福尼亚州。

各州可再生能源发电占比排名(截至2023年9月的12个月)

  • 南达科他州以96.9%的可再生能源发电占比领先,其中风能贡献了69.7%。
  • 爱荷华州位居第二,可再生能源占比81.4%,几乎全部来自风能。
  • 蒙大拿州(80.5%)、华盛顿州(79%)、堪萨斯州(65.1%)、新墨西哥州(64.6%)、俄勒冈州(64.5%)、怀俄明州(59.5%)、北达科他州(57.9%)和俄克拉荷马州(56.5%)紧随其后。
  • 加利福尼亚州的可再生能源占比为50.9%,在上榜州中排名最后,但其太阳能在能源结构中的份额远高于其他州。

加利福尼亚州的能源结构特点

  • 太阳能占主导地位:公用事业规模的太阳能光伏和聚光太阳能发电厂满足了该州16.6%的电力需求,屋顶太阳能则贡献了另外11.3%。
  • 储能支持:该州配套部署了7吉瓦的储能容量。

电价情况

  • 根据美国能源信息管理局的统计数据,除加利福尼亚州外,所有其他可再生能源占比超过50%的州,其电力零售价格均远低于美国平均水平
  • 加利福尼亚州的电价高于平均水平,部分原因是野火治理成本被转嫁给了消费者。
  • 截至2023年10月,北达科他州的电价在美国最低,其次是怀俄明州爱荷华州
37. Raspberry Pi is preparing for an IPO in London for likely more than $500M (arstechnica.com)

树莓派正在为伦敦首次公开募股(IPO)做准备,估值可能超过5亿美元。创始人埃本·厄普顿回应了公众对该公司使命和产品定价可能改变的担忧。

厄普顿表示,此次IPO主要是为了其慈善机构(基金会)。该基金会将出售其在商业实体中的部分多数股权,以筹集资金扩大项目。此前,基金会依靠商业子公司的股息获得资金。交易收益将用于培训教师、运行俱乐部、扩展项目,并使这些活动的规模至少翻倍。

针对上市后树莓派可能更关注大客户、忽略创客群体的担忧,厄普顿承诺“不会改变”产品种类,并表示创客群体“在文化上对我们非常重要”。他强调,树莓派的利润率结构“一直保持不变”,IPO后也应如此。

厄普顿否认会提高产品价格或降低功能。他以Zero 2 W和Pico等低成本产品为例,指出它们在能力更强、价格更低的水平上延续了教育与创新的使命。他回应疑虑时表示:“如果人们认为IPO意味着我们将提高价格、提升利润率、削减功能,我们唯一的回答是:看我们的行动。继续观察。让我们在15年、20年后再来看。”

38. The Soviet 1801VM2 LSI-11 Processor (2021) (www.cpushack.com)

苏联1801VM2处理器技术总结

核心概述

苏联制造的1801VM2处理器于1982年开发,是一款与DEC PDP-11指令集及QBUS总线二进制兼容的CPU。它是对早期1801VM1的改进,主频从5MHz提升至10MHz,属于独立结构设计。

技术规格

  • 指令集:72条处理器指令
  • 制造工艺:4微米N沟道硅栅MOS技术
  • 芯片尺寸:5.3 × 5.35 mm
  • 晶体管数量:18,500个有源晶体管,120,000个集成元件
  • 最高主频:10 MHz
  • 性能:寄存器操作(如加法)可达1 MIPS,乘法等复杂操作约100,000条指令/秒
  • 功耗与供电:+5V供电,功耗最高1.7W
  • 封装:40引脚陶瓷DIP(KM1801VM2)或塑料DIP(KR1801VM2),另有表面贴装版本

改进与设计特点

  • 为提升抗噪能力,地址/数据总线增加了额外接地触点。
  • 与1801VM1相比,新增扩展算术指令(MUL、DIV、ASH、ASHC)及浮点指令集(FIS)。FIS指令(FADD、FSUB、FMUL、FDIV)通过固件子程序实现,需中断调用系统ROM中的处理程序。
  • 设计存在一个微码错误,导致使用寻址模式17(MOV (PC), R0)读取时处理器故障。

生产与分级

  • Angstrem和**Solnechnogorsk Electromechanical Plant (SEMZ)**两家工厂制造。
  • 通过测试后的标记进行速度分级:无额外标记为“A”级(10MHz),添加小点为“B”级(8MHz)。

应用系统

  • DVK计算机:作为核心处理器用于多种型号,1983-1990年间生产约200,000台。
  • “Romashka”文字处理器:1990年代上半叶生产的电子打字机,具备文本格式化与电子存储功能,基于KM1801VM2构建。
  • “Electronics IM-05”象棋计算机:Svetlana协会生产。

衍生型号

  1. 1806VM2(1984年):

    • 军事级版本,采用CMOS工艺,最高主频5MHz,功耗仅0.025W。
    • 包含77条指令,修复了1801VM2的微码错误。
    • 封装:42引脚陶瓷DIP或64引脚CQFP,菱形标识表示军事级。
  2. 1836VM2/N1836VM2(1990年):

    • 抗辐射版本,与1806VM2兼容。

生产延续性

  • Angstrem工厂持续生产1806VM2至1999年,用于军事与工业领域,体现了苏联/俄罗斯对成熟可靠技术的长期依赖。
39. ASCII Theater (ascii.theater)

ASCII Theater 摘要

ASCII Theater 是一个由 MSCHF 团队创建的项目,旨在通过终端流式传输免费的基于文本的电影。用户无需图形界面,即可在命令行环境中观看以 ASCII 艺术呈现的影片。

主要功能与目的

  • 目的:提供免费、可访问的文本格式电影流媒体服务,强调桌面使用体验。
  • 关键特性:基于终端的流媒体、纯文本内容(ASCII art)、无需安装额外软件,只需使用 SSH 命令连接。
  • 访问方式:通过执行特定的 SSH 命令在终端中启动流媒体。

访问步骤指南

  1. 打开终端应用:在电脑的“应用程序”文件夹中,进入“实用工具”子文件夹,双击“终端”应用。
  2. 粘贴代码并连接:在终端中粘贴以下 SSH 命令,并按回车键执行:
    ssh -o StrictHostKeyChecking=no watch.ascii.theater
    
    此命令将连接到 ASCII Theater 服务器,开始播放当日的电影。
  3. 观看电影:电影会自动开始播放。要停止播放,只需关闭终端应用或按键盘上的“q”键。

其他细节

  • 今日放映:内容中重复提及“TODAY'S SCREENING”,表示每日更新影片。
  • 平台限制:仅限于桌面环境,需使用终端(如 macOS 的 Terminal.app)。
  • 设计理念:通过复古的文本界面提供独特的观影体验,突出技术艺术性和可访问性。
40. Gitstr: Send and receive Git patches over Nostr (github.com)

废弃通知: Gitstr 项目已废弃,建议使用 nak(Git 子命令)替代。

功能概述: Gitstr 是一个工具,允许通过 Nostr 协议(基于 NIP-34)发送和接收 Git 补丁,实现去中心化的代码协作。

安装方法:

  • 如果有 Go 环境,运行 go install github.com/fiatjaf/gitstr/cmd/git-str@latest 安装。
  • 或者下载预编译的二进制文件。
  • 确保 git-str 在系统 PATH 中,例如通过将 $HOME/go/bin 添加到 ~/.bashrc

接收补丁流程:

  1. 在仓库中初始化:运行 git str init -r <relay> 指定中继器,这会向中继器宣布仓库。
  2. 下载补丁:使用 git str download 获取所有补丁,存储在 .git/str/patches/ 目录;可通过 nevent1npub1 代码筛选特定补丁。
  3. 应用补丁:运行 git am -i <patch-file> 将补丁应用到本地仓库。

发送补丁流程:

  1. 获取目标仓库的 naddr1 代码(需从仓库所有者处手动获取)。
  2. 发送补丁:运行 git send <commit>(如 HEAD^)或指定补丁文件路径;支持使用标志回答问题。
  3. 发送到未宣布仓库:使用 --dangling 选项,补丁可通过 nevent1 代码下载。

贡献方式: 向指定的 naddr1 代码发送补丁,以参与此项目。

41. Show HN: ChatGPT prompt builder – the simplest prompt builder (mitenmit.github.io)

这篇文章介绍了一个名为“ChatGPT prompt builder”的网络工具,它被称为“最简单的提示词构建器”。该网站是基于Create React App框架开发的,旨在帮助用户更便捷地构建与ChatGPT交互时使用的提示词(prompt)。

42. CVE-2023-6246: Heap-based buffer overflow in the glibc's syslog() (www.qualys.com)

CVE-2023-6246:glibc syslog() 堆缓冲区溢出漏洞

漏洞概述

  • 编号与影响:CVE-2023-6246 是一个存在于 GNU C 库 (glibc) 的 __vsyslog_internal() 函数中的基于堆的缓冲区溢出漏洞。该函数由 syslog()vsyslog() 调用。
  • 引入版本:此漏洞由 glibc 2.37(2022年8月)的一次提交引入,并被回移至 glibc 2.36。
  • 根本原因:当程序名(__progname,即 argv[0] 的基础名称)或 openlog()ident 参数长度超过 1024 字节时,会导致一个计算错误,使得为消息缓冲区分配的内存空间过小(1字节),从而在后续向其写入时造成堆溢出。
  • 受影响系统:已在 Debian 12/13、Ubuntu 23.04/23.10、Fedora 37-39 上确认。其他使用受影响 glibc 版本的系统也可能存在风险。
  • 利用条件:此漏洞主要需要本地权限进行利用,因为攻击者需要控制 argv[0]openlog() 的参数。在典型场景下,无法远程触发。

漏洞分析 漏洞的核心位于 glibc__vsyslog_internal() 函数中:

  1. 函数尝试使用一个 1024 字节的静态缓冲区 bufs
  2. 在格式化日志头时,如果 LogTag 为 NULL,则会使用 __progname(攻击者可控的 argv[0] 基础名称)。
  3. 如果 __progname 非常长(>1024字节),__snprintf 函数的返回值 l 将大于 bufs 的大小,导致一个条件判断分支被跳过。
  4. 随后,程序会分配一个仅 1 字节的堆缓冲区 buf(因为 bufsize 仍为 0)。
  5. 接着,程序尝试将攻击者控制的长 __progname 再次写入这个 1 字节的 buf,造成堆溢出。

漏洞利用 研究人员通过 su 程序(一个常见的 SUID-root 程序)成功实现了本地权限提升(从任意非特权用户提升至 root)。利用过程如下:

  1. 触发路径su 在用户认证失败时,会通过 PAM 库调用 syslog()。此时,openlog() 未被调用,因此 LogTag 为 NULL,使得 __progname 被用作日志标识符。
  2. 堆布局控制:攻击者利用 su-w 选项(环境变量白名单),可以在程序启动早期通过 mallocfree 操作控制堆的布局,为后续溢出创造有利条件。
  3. 利用目标:溢出最终覆盖了 glibcName Service Switch (NSS) 子系统的堆结构(struct nss_module)中的 name 字段。
  4. 代码执行:当覆盖后的 name 字段包含斜杠(/)时(例如来自 tty 设备路径的一部分),NSS 模块加载函数 __nss_module_load 会根据被污染的字符串拼接共享库名称,并从当前工作目录加载该恶意库,从而以 root 权限执行攻击者代码。
  5. POC:一个简单的崩溃演示为:(exec -a "printf '%0128000x' 1" /usr/bin/su < /dev/null)。实际利用需要精心构造目录结构、恶意共享库文件名,并可能通过暴力破解确定精确的溢出参数。

时间线

  • 2023-11-07:Qualys 向 Red Hat 产品安全团队报告漏洞。
  • 2023-11-21:Red Hat 分配 CVE-2023-6246。
  • 2023-12-05 至 2023-12-13:在审查补丁过程中,研究人员又发现了同一函数中的另外两个漏洞(CVE-2023-6779 和 CVE-2023-6780)。
  • 2024-01-30:所有三个漏洞的协调披露日期。
43. What it was like to be the subject of a longitudinal study (2023) (slate.com)
46. Beej's Guide to Networking Concepts (beej.us)

Beej 网络概念指南资源总结

本文提供了《Beej 网络概念指南》的多种资源获取方式,主要面向读者、翻译者和写作者。

面向读者的资源

指南提供多种格式版本:

  • HTML 版本:包括标准版、宽屏版、单页版等不同视图,可下载 ZIP 压缩包。
  • PDF 版本:包含美国信纸(US Letter)和 A4 纸张尺寸,支持单面/双面打印,并提供语法高亮和黑白两种样式。
  • 示例代码:可下载示例文件,格式为 ZIP 压缩包。
  • 镜像站点:目前有加拿大镜像站(gmem.ca),作者欢迎其他镜像。

面向翻译者和写作者

  • 可通过克隆 GitHub 上的完整项目并遵循 README 文件进行翻译或写作。
  • 作者联系邮箱:beej@beej.us
47. Fix date-handling bug when today’s date is later than the target month (github.com)

文章标题:修复今天日期晚于目标月份时的日期处理bug

问题描述

当今天的日期部分(例如日)大于目标月份的天数时,无法将日程设置到该日期,原因是 JavaScript 的 Date 对象在验证日期时会导致错误回滚。

Bug 解释

  • 根本原因Date 对象在修改月份时,如果当前日期(如30号)在目标月份(如二月)中不存在,会自动将日期调整到下个月的第一天,从而导致后续设置错误。
  • 示例代码演示
    • 假设当前日期是 1/30/2024(new Date())。
    • 设置年份到 2025(d.setFullYear(2025)),日期变为 1/30/2025。
    • 设置月份到 2(二月,d.setMonth(2)),由于二月没有30号,日期回滚到 3/1/2025。
    • 随后设置日期为 15(d.setDate(15)),日期变为 3/15/2025,而不是预期的 2/15/2025。
  • 影响:这种回滚行为会导致日期计算错误,影响日程安排或类似功能的准确性。

关键细节

  • 该 bug 特别针对当今天的“日”数值超过目标月份最大天数的情况。
  • 问题源于 Date 对象的内置验证机制,而非用户代码逻辑。
  • 文章标题表明这是一个修复任务,但内容仅详细描述了 bug 的触发场景和示例,未提供具体修复方法。
48. Proton, a fast and lightweight alternative to Apache Flink (github.com)

Timeplus Proton:快速轻量的流处理引擎

产品概述

Timeplus Proton 是一个单 C++ 二进制文件的快速 SQL 管道引擎,专为流处理、分析、可观测性和 AI 设计。它是 ksqlDB 和 Apache Flink 的简单、快速且高效的替代方案,基于 ClickHouse 引擎构建。其核心设计理念包括:

  • SQL 驱动一切:支持原生连接器(Kafka、ClickHouse、MySQL、Postgres、MongoDB、S3/Iceberg、OpenSearch 等)、流式数据摄入、多流连接、增量物化视图、告警、任务以及 Python/JS 用户定义函数(UDF)。
  • 无 JVM、无 ZooKeeper、零依赖:仅提供速度、控制和可扩展性。

核心特点与优势

  1. 极致性能
    • 使用 C++ 编写,通过 SIMD 优化。
    • 在 Apple MacBookPro M2 Max 上测试:达到 9000 万 EPS4 毫秒端到端延迟,支持百万级高基数聚合。
  2. 轻量级
    • 单个二进制文件小于 500MB。
    • 无 JVM 或任何外部依赖。
    • 可通过 Docker 或在 AWS t2.nano 实例(1 vCPU、0.5 GiB 内存)上运行。
  3. 基于 ClickHouse 扩展
    • 利用 ClickHouse 的高速、资源高效特性。
    • 扩展了流处理能力,支持历史数据查询、存储和计算。
    • 内置数千个 SQL 函数,可毫秒级查询数十亿行数据。
  4. 最佳 Kafka/Redpanda 流处理引擎
    • 通过外部流实时查询 Kafka 或其他兼容流数据平台。

主要应用场景

  • 实时分析 ETL/管道:从 Kafka 等源高效摄入实时数据,在管道内进行转换(过滤、脱敏、丰富),并路由到下游系统(如 ClickHouse 数据仓库)。
  • 实时遥测管道与告警:处理日志、指标和跟踪数据,进行实时告警,并转发到 Splunk、Elastic 或 S3。
  • AI/ML 实时特征管道:通过低延迟、高吞吐的流式 SQL 和物化视图计算实时特征,支持回溯填充和高级窗口处理。

部署方式

  • 单个二进制文件:通过命令一键安装。
    curl https://install.timeplus.com/oss | sh
    
  • Homebrew(macOS)brew install timeplus-io/timeplus/proton
  • Docker
    docker run -d --pull always -p 8123:8123 -p 8463:8463 --name proton d.timeplus.com/timeplus-io/proton:latest
    
  • Docker Compose:提供示例栈,演示如何与 Kafka/Redpanda 交互。
  • 在线演示:提供免费试用环境。

使用示例

  • 连接外部系统:通过 SQL 创建 Kafka 外部流和 ClickHouse 外部表,并设置物化视图进行数据聚合和路由。
  • 随机数据流:无需 Kafka,可直接创建随机流进行 SQL 查询测试。

版本比较:Timeplus Proton vs. Timeplus Enterprise

功能 Timeplus Proton Timeplus Enterprise
部署 单节点 Docker 镜像或 Mac/Linux 二进制文件 单节点、集群、基于 Kubernetes 的自托管
数据源 随机流、Kafka/Pulsar/Redpanda 外部流、ClickHouse 外部表、REST API(紧凑模式) 包含 Proton 所有功能,另增 WebSocket/HTTP 流、NAT、CSV 上传、REST API(灵活模式)、数百个 Redpanda Connect 连接器
数据目的地(Sink) Kafka/Pulsar/Redpanda 外部流、ClickHouse 外部表 包含 Proton 所有功能,另增 Slack、Webhook、数百个 Redpanda Connect 连接器
支持 GitHub 和 Slack 社区支持 邮件、Slack、Zoom 企业级支持(含 SLA)

集成与生态

  • 驱动程序:提供 JDBC(Java)、Go、Python 驱动。
  • 系统集成:支持 ClickHouse、Docker/Testcontainers、Sling、Grafana、Homebrew、dbt 等。
  • 完整文档:详见 docs.timeplus.com
  • 许可证:采用 Apache License 2.0 开源。

社区与支持

  • 通过 GitHub Discussions 分享反馈或问题。
  • 通过 GitHub Issues 报告错误或建议功能。
  • 加入 Timeplus Community Slack 与工程师交流或咨询企业版信息。
49. Citation cartels help mathematicians–and their universities–climb the rankings (www.science.org)
50. GitHub Actions: M1 macOS runner available to open source (github.blog)

GitHub Actions: M1 macOS runner 正式对开源项目开放

GitHub 已面向所有计划用户推出基于 Apple M1 芯片的全新 macOS runner。此 runner 对公共仓库完全免费,私有仓库可使用套餐内包含的免费使用分钟数。

该 runner 提供高性能配置:

  • 3 核虚拟 CPU (vCPU)
  • 7 GB 内存
  • 14 GB 存储空间

它运行在最新的 macOS 14 系统上,为 Actions 工作流提供当前最先进的 Mac 硬件支持。

使用方法:只需在工作流 YAML 文件中,将 runs-on 的键值更新为 macos-14 即可启用。