Meta发布首款真正的增强现实眼镜Orion

核心定位与背景 Meta于今日正式揭晓其首款真正的增强现实眼镜——Orion。该产品旨在弥合物理世界与数字世界，将用户置于中心，使其在现实环境中能更专注、互联且拥有更强能力。五年前Meta宣布研发AR眼镜，其理念是让人们无需在“获取数字信息”与“沉浸现实世界”间做选择。

AR眼镜的三大关键优势

1. 无界显示：通过大幅全息显示，将物理世界变为画布，可自由放置2D和3D内容与体验，摆脱智能手机屏幕的限制。
2. 情境化AI：无缝集成能够感知并理解周围环境的AI，以预测需求并主动提供协助。
3. 轻便社交：眼镜设计轻巧，适合室内外使用，且保持透明镜片，允许佩戴者自然展露面部表情和眼神，促进真实社交。

从Ray-Ban Meta到Orion的演进 Ray-Ban Meta眼镜开创了无显示屏但由AI增强的智能眼镜品类，提供免提访问数字生活的能力。然而，真正的AR眼镜一直是行业追求的目标——即将大视场角全息显示与个性化AI助手结合于一副舒适、适合全天佩戴的眼镜中。Orion正是为应对这一挑战而生。

Orion的突破性技术特点

• 极致的微型化：实现了前所未有的小型化设计，将众多创新组件压缩至毫米级，造就了兼具时尚外观与日常佩戴舒适度的形态。
• 业界领先的视场角：在迄今为止最小的AR眼镜形态中，提供了最大的视场角，支持多任务窗口、大屏娱乐、真人大小全息影像等沉浸式应用，并与现实世界无缝融合。
• 眼镜般的社交设计：与市面上的MR头显或其他AR眼镜不同，Orion外观和触感都像普通眼镜，采用透明镜片，确保了佩戴者之间能够进行自然的眼神和表情交流。

初步应用体验 Orion已运行Meta AI智能助手，能理解用户视线中的物理世界并提供可视化辅助。应用场景例如：根据冰箱内食材推荐食谱；在洗碗时通过视频通话与朋友聊天并调整家庭数字日历。此外，还可进行免提视频通话，并直接通过眼镜查看和发送WhatsApp、Messenger消息，无需掏出手机。

产品定位与未来计划 Orion并非消费级产品，而是一个高度成熟的“产品原型”，代表了未来可量产发售产品的可能性。Meta选择优先进行内部开发，以快速迭代技术，从而在未来推出更优的消费级产品。

• 当前计划：从Connect大会开始，Meta员工及部分外部人士将能使用该原型，以帮助团队学习、迭代并构建消费级AR眼镜产品线，计划在“不久的将来”开始发货。
• 优化方向：未来将着力于提升AR显示画质、进一步缩小产品尺寸，以及通过规模化生产降低成本。
• 长远视野：从Ray-Ban Meta到Orion，Meta持续探索如何让人们在享受数字世界便利的同时，更好地融入并赋能于物理世界。未来几年，公司预计将基于此项研发成果推出新设备。

PostgreSQL 17 版本发布摘要

PostgreSQL 全球开发组于2024年9月26日发布了 PostgreSQL 17，这是其先进的开源数据库的最新版本。此版本在性能、可扩展性、开发者体验和高可用性方面均带来了显著改进。

一、系统级性能提升

• Vacuum 优化：引入了新的内部内存结构，内存消耗最多可降低20倍，提升了速度并减少了共享资源占用。
• I/O 层改进：高并发写入吞吐量提升高达2倍；新的流式 I/O 接口加速了顺序扫描和 ANALYZE 统计信息更新。
• 查询执行优化：提升了使用 B-tree 索引的 IN 子句查询性能；BRIN 索引现支持并行构建；优化了 NOT NULL 约束和公共表表达式（WITH 查询）的处理；增加了对 AVX-512 的 SIMD 支持以加速计算。

二、开发者体验增强

• SQL/JSON 功能扩展：新增 JSON_TABLE 命令，可将 JSON 数据转换为关系表；支持新的 SQL/JSON 构造函数（JSON, JSON_SCALAR, JSON_SERIALIZE）和查询函数（JSON_EXISTS, JSON_QUERY, JSON_VALUE）；增加了更多 jsonpath 表达式以支持将 JSON 数据转换为原生数据类型。
• MERGE 命令增强：新增 RETURNING 子句，并支持对视图进行更新。
• 批量加载与导出：使用 COPY 命令导出大行时性能提升高达2倍；新增 ON_ERROR 选项允许在插入出错时继续导入。
• 分区与远程查询：支持在分区表上使用标识列和排除约束；postgres_fdw 现可将 EXISTS 和 IN 子查询下推到远程服务器处理。
• 新增排序规则提供程序：提供平台无关的、不可变的排序规则，保证文本排序结果在不同部署环境下一致。

三、逻辑复制与高可用性改进

• 简化大版本升级：从 PostgreSQL 17 开始升级时，无需删除逻辑复制槽，避免了升级后重新同步数据。
• 高可用增强：为逻辑复制添加了故障转移控制。
• 新工具：引入 pg_createsubscriber 命令行工具，可将物理副本转换为逻辑副本。

四、安全、运维与监控

• 安全与操作：新增 sslnegotiation TLS 选项以支持直接 TLS 握手；添加 pg_maintain 预定义角色，用于执行维护操作。
• 备份工具增强：pg_basebackup 支持增量备份，并新增 pg_combinebackup 实用工具用于重建完整备份；pg_dump 新增 --filter 选项以选择转储对象。
• 监控与分析：EXPLAIN 现可显示本地 I/O 块读写耗时，并新增 SERIALIZE 和 MEMORY 选项；新增索引 vacuum 进度报告；添加 pg_wait_events 系统视图以深入分析会话等待原因。

五、其他资源

更多新特性和改进的完整列表，请参阅官方发布说明。用户可通过官方下载页面获取 PostgreSQL 17。

关于 PostgreSQL：它是一个拥有超过25年开源历史的、以可靠性、健壮性和可扩展性著称的先进数据库管理系统。

摘要：

提供的内容包括一个标题“Mira Murati leaves OpenAI”和一个正文错误消息。正文内容为技术性提示，指出在访问x.com时出现问题，原因是隐私相关扩展可能干扰网站功能。消息建议用户禁用这些扩展并重试，以解决访问问题。内容结构简洁，主要功能是识别问题原因并提供操作指导，帮助用户恢复正常使用。标题所指的主题未在正文中涉及，因此摘要仅基于实际文本内容。

WordPress.org封禁WP Engine事件概述

事件核心

WordPress.org因法律纠纷，已禁止托管服务商WP Engine访问其平台资源，包括主题、插件及更新服务。

冲突详情

• 封禁措施：WP Engine客户无法通过WordPress.org安装插件、更新主题或获取安全更新，但网站运行暂未受影响。
• 双方立场：
  • WordPress方：WP Engine未对开源社区做出足够贡献，却通过“篡改版”WordPress代码盈利，且涉嫌侵犯WordPress和WooCommerce商标。
  • WP Engine方：指控Automattic CEO马特·穆伦威格滥用控制权，干扰正常服务，并威胁“焦土政策”以迫使支付收入分成。
• 商标争议：WordPress基金会称WP Engine违反商标政策，禁止在公司名、域名等中使用“WordPress”商标。政策昨日已更新并以WP Engine为例。

用户影响

• 小型组织及非营利机构面临迁移成本增加、安全风险提升等问题。
• 开发者指出，封禁影响所有依赖WP Engine工具（如ACF）的用户。

事件背景

• 双方均为WordPress主要托管商，各占约5亿美元年收入。
• 矛盾于上周公开化：穆伦威格公开批评WP Engine后，双方互发停止侵权函。
• 穆伦威格透露，此前曾长期尝试与WP Engine签订许可协议，要求支付许可费或提供开源贡献，但未达成一致。

Git-absorb: 自动化 Git fixup 提交工具

核心功能 Git-absorb 是 Facebook 的 Mercurial hg absorb 工具的 Git 移植版本。它能够自动将工作目录中未暂存的更改（修改）智能地合并到对应的祖先提交中，实现了 git commit --fixup 和交互式变基（git rebase -i）的自动化，从而维护原子提交的清晰历史。

典型使用场景 当团队成员在功能分支上进行代码评审并指出缺陷后，开发者可以针对每个缺陷进行修复。此时，无需手动查找每个需要修正的提交的SHA值，也无需执行复杂的交互式变基，只需执行以下命令：

1. git add 暂存所有修复的文件。
2. git absorb --and-rebase。 工具会自动识别哪些提交可以安全修改，并为每个暂存的更改创建对应的 fixup! 提交，随后立即自动变基，将这些修正合并到目标提交中。

工作原理 Git-absorb 的核心机制是通过检查补丁是否可交换来工作。对于索引（暂存区）中的每一个代码块（hunk），它会从最近的提交（HEAD）开始，向前逐个检查该提交是否可与这个代码块交换（即应用顺序是否影响结果）。当找到第一个不可交换的提交时，便推断该代码块应归属于这个提交，并将其转换为一个 fixup! 提交。如果代码块与检查范围内的所有提交都可交换，则意味着未找到合适的目标提交，该代码块将保留在索引中。

安装方法 提供多种便捷的安装途径：

• 直接下载：从项目的最新发布中下载适用于 Windows、macOS 或 Linux 的预编译二进制文件。
• 系统包管理器：在多个主流 Linux 发行版和 macOS 的包管理器中可用，例如：
  • Arch Linux: pacman -S git-absorb
  • Debian/Ubuntu: apt install git-absorb
  • Homebrew (macOS/Linux): brew install git-absorb
  • Windows Package Manager: winget install tummychow.git-absorb
  • 以及 Fedora, openSUSE, FreeBSD, Nix 等。
• 从源码编译：需要安装 Rust 的 cargo 工具，然后执行 cargo install git-absorb。

基本使用流程

1. 暂存更改：使用 git add 将你希望被吸收的更改添加到暂存区。
2. 运行吸收：执行 git absorb。它会在当前 HEAD 上创建一系列 fixup! 提交。
3. 验证与应用：
   • 可以检查生成的 fixup! 提交日志（git log）。
   • 确认无误后，执行 git rebase -i --autosquash 来自动整理历史。
   • 如果对结果不满意，可以使用 git reset --soft PRE_ABSORB_HEAD 恢复到操作前的状态。

待办事项与未来改进 项目仍有一些待完善的方面，包括：检查远程默认分支、优化错误输出、增加测试覆盖、改进文档（特别是关于栈大小和交换细节）、支持更多的合并场景（如复制/重命名检测）、避免一次性加载所有代码块以节省内存，以及实现索引锁定以防止并发修改。

作者将 Rust 比作初代 iPhone：基础出色（代数类型、内存安全、包管理器），但总有不足，感觉从未“完成”。语言进展显著放缓，700多个不稳定特性（如七年未稳定的协程）停滞不前，RFC流程可能因共识机制无法规模化而沦为“好想法的墓地”。

作者提出了一个虚构的编译器分支，旨在保留对主线Rust兼容的同时，引入一系列破坏性改进，打造一个更完善的“Seph版Rust”。主要构想包括：

1. 函数特性：为函数引入类似结构体trait的“效果”系统，声明其属性（如是否panic、是否为协程、栈大小、纯度等）。这能让编译器实现更精细的控制（如标记禁止panic的函数），并改善协程和异步函数的类型推断与存储。

2. 编译时能力：借鉴内存安全中unsafe的理念，为危险操作（如文件系统读写、网络访问、FFI）添加能力标记。第三方库默认不具备这些能力，开发者需在Cargo.toml中显式授权，从而大幅降低供应链攻击风险。

3. 重构Pin与移动语义：批评Pin机制复杂且反直觉（是“Move”标记trait的反面），导致不必要的堆分配和复杂性。提议通过扩展借用检查器直接支持结构体字段的借用状态（如&'Self::x），并引入Move标记trait来替代Pin，使自引用结构等场景更简洁安全。

4. 编译时执行：推崇 Zig 的 comptime，希望用 Rust 语言本身替代独立且“可怕”的宏语言进行编译时编程。这样能简化元编程（如println!的实现），并统一开发体验。

5. 其他小改进：

   • 为Range实现Copy。
   • 修复derive宏对关联类型的支持。
   • 为if let表达式支持逻辑与（&&）。
   • 改善裸指针的人体工学（如简化(*ptr).field的语法）。
   • 使集合类型在构造时接受分配器参数，而非默认使用全局分配器。

作者感叹，这些改进大多与现有Rust不兼容。尽管曾考虑撰写RFC，但认为低效的共识过程会使其沦为“未实现梦想的垃圾填埋场”，甚至幻想过亲自fork编译器来实现这些愿景。

起亚汽车远程安全漏洞及受影响车型分析

核心主题

本文揭示了一项针对起亚（Kia）汽车的严重安全漏洞，研究表明攻击者仅需获取目标车辆的车牌号，即可绕过安全验证，对车辆实施远程控制。

内容结构

文章主体提供了一个详尽的车型漏洞影响与功能支持矩阵。该列表系统梳理了起亚品牌从2014款至2025款的数百款车型及具体配置，全面覆盖了轿车、SUV、MPV，以及燃油、油电混动（Hybrid）、插电混动（PHEV）和纯电动（EV）等全系产品线。

关键细节与数据分析

• 多维状态评估：每款车型后均紧跟5个状态指示符（“✅️”与“❌”）。结合远程控制主题，这5个维度大概率对应车联网系统（如Kia Connect）的5项核心远程功能（如远程解锁/闭锁、引擎启停、GPS定位、鸣笛/闪灯寻车、车辆状态读取），或代表该车型在5种特定攻击向量下的脆弱性表现。
• 智能化程度与风险正相关：
  • 新款与新能源车型：2021款至2025年的近期车型，特别是高配版本（如SX-Prestige）及新能源车型（EV、PHEV、Hybrid），其状态多显示为“✅️”。这表明高度依赖车联网和云端服务的智能汽车暴露了更多的API接口，是该远程劫持漏洞的主要受影响群体。
  • 老款与基础车型：2014款至2019款的早期车型，以及部分基础配置（如LX、S）或传统燃油车，状态多为“❌”。这反映出缺乏高级联网模块的车辆不受此特定远程攻击的影响。
• 高危车系分布：数据表明，当前市场主力热销车型如 Sportage、Sorento、Telluride、Carnival 以及 EV6/EV9 等，在多个控制维度上均显示为“✅️”，凸显了现代智能网联汽车在身份验证机制和后端API安全设计上面临的严峻系统性风险。

美国联邦贸易委员会（FTC）对AI公司DoNotPay采取执法行动，指控其进行虚假宣传。DoNotPay最初被宣传为“世界首位机器人律师”，声称“一键即可起诉任何人”。FTC指出，该公司未进行任何测试以验证其AI聊天机器人输出是否达到人类律师水平，也未雇佣或保留任何律师来验证AI输出或其法律声明的有效性。

为和解相关指控，DoNotPay同意支付19.3万美元（需经30天公众评议期确认后生效），但不承认任何责任。此外，该公司需警告2021年至2023年间的订阅用户其服务中法律相关功能的局限性，并承诺未来不得无根据地宣称其任何功能可替代专业服务。

DoNotPay发言人表示，该公司与FTC“建设性合作”解决了此案，并称相关投诉仅涉及几年前数百名客户使用已停止的服务。FTC此次行动是其打击欺骗性AI宣传的更大规模执法努力的一部分，当天还有另外四家AI公司受到处罚。FTC主席强调，利用AI工具欺骗、误导或欺诈消费者是非法的，现有法律同样适用于AI领域，以保护消费者并为诚实企业创造公平竞争环境。

cronexpr 是一个用 Rust 编写的库，专门用于解析 cron 表达式并驱动其调度，即计算给定时间戳之后的下一个或多个执行时间。它的核心功能是充当一个“模式匹配器”和时间计算器，而不负责执行具体的命令。

该库支持标准的五字段 cron 语法（分钟、小时、日、月、星期），并在表达式末尾增加了必需的时区字段（例如 Asia/Shanghai，UTC），以确保在处理夏令时等复杂情况时计算准确。从版本 1.1.0 开始，时区也可以设为可选。

除了标准语法，cronexpr 还支持多种非标准扩展，增强了表达能力：

• 月末最后一天 (L)：如 L 表示月份的最后一天。
• 最近工作日 (W)：如 15W 表示离15号最近的工作日（周一至周五）。
• 月末最后一个星期几 (L)：如 5L 表示该月的最后一个星期五。
• 第N个星期几 (#)：如 5#3 表示该月的第三个星期五。
• 哈希值 (H)：通过哈希算法将任务分散到不同时间执行，避免资源争用。

库提供了一系列方法：

• parse_crontab：解析包含时区的 cron 表达式。
• matches：检查某个时间戳是否匹配该表达式。
• find_next：查找并返回给定时间戳之后的下一个执行时间。
• iter_after：返回一个迭代器，可以无限或有界地迭代后续的所有执行时间。

一个重要且已实现的行为是遵循 Vixie cron 规则处理日期和星期字段的交互。当其中一个字段以通配符 * 开头时，两者取交集；否则取并集。这导致 0 12 *,10 * 2 与 0 12 10,* * 2 含义不同，前者只在周二触发，后者每天都会触发。这与某些其他实现不同，是该库的一个关键特性。

该库的开发源于在 ScopeDB 中实现 CREATE JOB 语句的需求，旨在提供一个专注于解析和调度时间的组件，而非执行命令。它选择使用 jiff 库来处理日期时间，支持完整的 IANA 时区数据库。设计上，它刻意不支持秒级调度、年份字段以及 @hourly 等别名，认为这些对于典型的 cron 调度场景要么不实用，要么可以转换为支持的标准语法。

WP Engine被WordPress.org禁止

核心事件

• WP Engine因缺乏商标许可证，已被WordPress.org禁止免费访问其资源。
• 这一决定源于WP Engine的法律索赔和诉讼，以及他们试图控制WordPress用户体验的行为。

具体原因

• WP Engine昨日在尝试阻止WordPress社区知情时，不当操作导致数千客户网站受影响。
• WP Engine禁用并锁定WordPress核心功能以牟利，但未获得合法商标许可。
• WordPress.org质疑：为何在遭受攻击的情况下，还要免费为WP Engine提供服务。

影响与后果

• WP Engine将无法再免费使用WordPress.org的资源，包括用户登录系统、更新服务器、插件目录、主题目录、模式目录、区块目录、翻译、照片目录、工作板、聚会、会议、错误跟踪器、论坛、Slack、Ping-o-matic和展示页。
• 由于WordPress与主机合作以网络层阻止漏洞，WP Engine需自行复制安全研究，否则可能面临安全风险。
• WP Engine可以提供其修改版的WordPress代码，但客户将体验WP Engine版本的WordPress，而非官方生态。

建议与结论

• WP Engine客户遇到网站问题时，应直接联系WP Engine支持团队。
• WordPress.org建议用户选择其他主机服务来体验真正的WordPress，强调“WP Engine不是WordPress”。

AWS Nitro Enclaves 攻击面概要

AWS Nitro Enclaves 用于隔离敏感工作负载，但其安全需全面评估。以下总结关键攻击面及缓解措施。

威胁模型

• 攻击来源：飞地主要受父 EC2 实例攻击，攻击者可控制父实例内核及 nitro_enclaves 驱动。外部用户通过父实例转发流量也可能发起攻击。
• 信任假设：飞地视为单一信任区，组件妥协即整体妥协；管理程序受信任。
• DoS 风险：父实例可随时关闭飞地，但外部用户可能触发 DoS 攻击。

虚拟套接字（Vsocks）

• 入口点：仅父实例通过本地 vsock 访问飞地，由管理程序管理。
• 安全实践：
  • 确保异步连接处理，避免单用户阻塞。
  • 实施连接超时，防止资源耗尽。
  • 正确处理多线程状态同步和错误（如 recv 循环需处理 EINTR 和零长度返回）。
• 主要风险：DoS 攻击，但父实例可控制飞地生命周期。
• CID 混淆：多飞地环境可能误发数据，但端到端认证可缓解。
• 套接字类型：默认 SOCK_STREAM，改用 SOCK_DGRAM 时需评估安全属性。

随机性

• 熵源：飞地需安全随机性；推荐检查 rng_current 设置为 nsm-hwrng。
• 增强措施：从外部源（如 AWS KMS GenerateRandom）获取熵。
• 内核配置：考虑禁用 random.trust_{bootloader,cpu} 参数以符合 NIST/AIS 标准；使用内核版本 >5.17.12。

侧信道攻击

• 时序攻击：应用需常数时间处理机密数据，避免依赖网络抖动缓解。
• CPU 缓存侧信道：缓存线共享可能导致数据泄露；AWS 声称 L3 缓存不同时共享，但存在争议。
• 缓解：
  • 运行飞地在完整 NUMA 节点（资源密集）。
  • 使用 Intel Cache Allocation Technology (CAT) 隔离 L3 缓存。
  • 确保安全代码采用秘密无关的内存访问模式。
• 认证集成：实施缓解措施时需在认证中添加相关信息。

内存管理

• 分配与保护：内存从父实例分配，由管理程序隔离并在返回后清除。
• DoS 防护：限制外部用户数据存储量，避免耗尽内存导致崩溃。
• 存储限制：飞地使用 initramfs，文件系统大小约 40-50% 的总 RAM；无持久存储，关闭后数据丢失。
• 数据密封：需应用自行实现，因 AWS Nitro 未提供特定机制。

时间源

• 风险：攻击者控制时间可能导致回滚/重放攻击（如接受过期证书）。
• 受信任时钟：依赖管理程序提供 kvm-clock 源。
• 推荐配置：
  • 设置 current_clocksource 为 kvm-clock 并添加应用级检查。
  • 启用精确时间协议（PTP）同步。
  • 安全功能使用 Unix 时间，避免 UTC 时区问题。
• TSC 机制：不适合飞地，默认 kvm-clock 通过 pvclock 协议提供初始日期。

认证（Attestation）

• 信任基础：用户需正确解析和验证认证数据。
• 最佳实践：
  • 强制最小 nonce 长度。
  • 检查时间戳，但勿用于推断飞地时间。
  • 避免使用 RSA 作为 public_key 功能。
• 时间戳说明：由管理程序生成，与飞地内部时钟可能不同。

NSM 驱动

• 访问方式：通过 /dev/nsm 节点和 IOCTL 系统调用。
• 安全要点：
  • 合理使用平台配置寄存器（PCR），区分锁定与未锁定状态。
  • 正确解码 CBOR 编码的请求/响应。
  • 避免直接使用 nsm_get_random，改用标准随机 API（如 getrandom）。
  • 处理 nsm_init 返回 -1 的异常情况。

总结要点

• 视飞地为单一信任区，实施端到端安全。
• 通过 CPU 分配和常数时间处理缓解侧信道风险。
• 运行时验证熵源，使用受信任时间源。
• 加强认证实践，包括 nonce 和时间戳验证。
• 全面评估内存、网络和驱动安全，防止 DoS 和数据泄露。

这篇文章记录了作者通过三年间持续追踪衣物穿着数据，来量化分析衣物真实使用成本和个人消费模式的深度实践。其核心发现与见解如下：

1. 方法与数据基础

• 数据收集：自2018年1月1日起，作者每晚花费不到一分钟，在谷歌表格中记录当天所穿衣物，历时约1106天，覆盖426件物品，产生超30万个数据点。
• 技术实现：因数据量增长，作者使用R语言构建了自动化分析与可视化平台，代码量约2300行。
• 核心指标：引入 “每次穿着成本” 作为关键衡量标准，即购买价格除以穿着总次数。它能标准化不同价格衣物的成本效益，使比较成为可能。

2. 关键发现与分析

• 使用频率至关重要：CPW随穿着次数增加呈非线性下降。数据揭示了“实际穿着”与“想象穿着”间的巨大差距，许多衣物远未达到预期使用次数。
• 价格不总是等于性价比：
  • 案例一（鞋类）：30欧元的平价鞋与90欧元的匡威鞋CPW相近（约0.7-0.87欧元/次），但150欧元的Diesel鞋CPW却高达1.88欧元/次，说明更贵并不总是更耐用或更划算。
  • 案例二（衬衫）：昂贵衬衫（100欧元以上）的平均CPW是廉价衬衫（40欧元以下）的近三倍。但作者愿意为更优的材质、剪裁和体验支付溢价，并明确了这一偏好背后的具体金钱成本。
• 竞争动态影响使用：衣物存在“竞争关系”。作者将类别分为“受限类”（如内衣，受洗涤周期影响，竞争弱）和“非受限类”（如鞋、外套，竞争强）。在非受限类别中，拥有过多物品会稀释每件衣物的使用频率，降低整体性能。
• 类别与组合表现：
  • 类别成本：将CPW转化为年度成本后，发现尽管某些类别（如西装外套）单次穿着成本高，但因使用频率低，年度总成本未必最高。
  • 组合趋势：整个衣橱的日均成本长期稳定在10欧元左右，并随季节和衣物汰换缓慢下降。

3. 实践建议与心法 基于数据洞察，作者总结出优化衣橱的实用准则：

• 购买原则：只买真正需要且喜爱的衣物；优先考虑使用价值而非价格；避免“次优选择”和适用场景过窄的衣物。
• 使用与维护：尽可能提高衣物穿着兼容性；做好长期穿着计划；悉心保养以延长寿命；知道何时应断舍离已充分使用的物品。
• 心态调整：接受并规划自己对特定品类的“弱点”（如作者对西装外套的偏爱）；让衣橱整洁有序，提升选用体验。

4. 未来方向 作者计划在现有货币成本分析的基础上，未来探索将环境可持续性（如重量、材质）纳入性能评估维度，并考虑将此方法扩展到分析更广泛的“耐用品”或“服务型消费”的效用成本。

这篇文章展示了一种通过小数据（个人日常记录）实现深度自我认知和理性消费决策的方法，核心在于用数据揭示“使用真相”，从而做出更符合个人价值与成本的知情选择。

• 诈骗概述：FBI警告分时度假业主需警惕与墨西哥贩毒集团关联的电话营销诈骗。诈骗者冒充房地产中介，谎称有墨西哥买家愿高价购买房产，诱导受害者支付各类“行政费”“税款”等，最终卷款消失。该诈骗网络至少涉及24家虚假托管、产权和房地产公司。
• 案例细节：加拿大退休夫妇Dimitruks接到电话，称有人愿购买其佛罗里达分时度假房产。诈骗者通过虚假公司ecurrencyescrow[.]llc以传真形式处理文件，逐步要求支付“手续费”“税款”等费用，甚至用$5,000支付房产尾款。在近一年时间里，夫妇累计损失超$50,000。诈骗者后期还以“已开除坏员工”为由诱导继续付款。
• 贩毒集团关联：FBI与财政部金融犯罪执法网络（FinCEN）指出，该诈骗与墨西哥哈利斯科州新世代贩毒集团（CJNG）有关。该集团通过呼叫中心实施长达数年的电话营销诈骗，非法所得用于资助毒品生产等犯罪活动。2023年曾报道至少8名年轻人因试图退出该集团运营的呼叫中心而遇害。
• 诈骗网络调查：调查显示虚假公司关联大量域名（如realestateassetsllc[.]com等），均指向同一DNS服务商datasur[.]host。该服务商与数十个房地产/托管类域名关联，部分域名冒用合法公司或专业人士名义。escshieldsecurity[.]com网站甚至伪装为解决诈骗的方案，但无实际联系方式或注册记录。
• 安全风险：域名管理者的凭证曾因信息窃取恶意软件泄露，可能影响诈骗网络运作。受害者常因羞愧或惧怕贩毒集团报复而保持沉默，阻碍执法与赔偿。
• 报案建议：文章呼吁受害者向FBI互联网犯罪投诉中心（IC3）、联邦贸易委员会（FTC）、国际消费者保护执法网络及墨西哥消费者保护机构报案，以协助执法打击诈骗并追索资金。

httpdbg：Python HTTP请求调试工具

核心功能

httpdbg 是一个 Python 开发者工具，用于轻松调试程序中的 HTTP(S) 客户端和服务器请求。通过将 python 命令替换为 pyhttpdbg 来执行程序，即可在浏览器（http://localhost:4909）中查看请求记录。

支持特性

• 协议：支持 HTTP/1.0、HTTP/1.1 和 HTTP/2（通过 h2 库）。
• 客户端库：官方支持 requests、urllib3、httpx、aiohttp，也可通过 -i 参数添加自定义包作为“启动器”。
• 服务器框架：支持 Flask 和 FastAPI 的请求记录。
• 测试框架：支持 pytest 和 unittest，请求将按测试分组，并可标识夹具或设置/清理方法中的请求。
• 记录模式：默认记录客户端和服务器请求；使用 --only-client 可仅记录客户端请求。

使用方式

• 交互式控制台：运行 pyhttpdbg 直接进入 Python 控制台，执行的 HTTP 请求将被记录。
• 执行脚本：pyhttpdbg --script filename.py [参数] 追踪脚本中的请求。
• 执行模块：pyhttpdbg -m 模块名 [参数]（例如 pyhttpdbg -m pip install package），可追踪如 pip 这类模块发起的请求。
• 运行测试：pyhttpdbg -m pytest [参数] 追踪测试期间的所有 HTTP 请求。
• 运行服务器：pyhttpdbg -m flask --app app run 可追踪服务器接收的请求。

核心概念

• 启动器：发起 HTTP 请求的函数/方法。可通过 -i 参数添加自定义启动器包。
• 分组：
  • 客户端：启动器与分组通常相同。对一个 URL 的多次请求（如重定向）会归为一组。
  • 服务器：启动器是接收数据的底层套接字方法，分组是处理请求的端点方法。

配置与自定义

• 命令行选项：包括指定 Web 界面地址（--host/--port）、添加启动器（-i）、保持服务运行（--keep-up）、强制退出（--force-quit）、导出为 HTML（--export-html）、隐藏横幅（--no-banner）等。
• Web 界面：支持自定义显示，如更改请求分组策略、隐藏 URL 中的协议/主机、隐藏分组行或标签。可固定请求或删除未固定请求。配置可通过书签保存。

导出与限制

• 导出：可将 HTTP 跟踪记录导出为单个 HTML 文件（此时执行期间 Web 界面不可用）。
• 当前限制：
  • 理论上，只要使用标准 Python 套接字，HTTP 请求就能被记录。
  • 服务器端请求记录（v1.0.0 新增）仍在完善中，部分框架（如使用 uvloop 的 FastAPI）需要特殊机制支持。

文档

完整文档详见：https://httpdbg.readthedocs.io

文章总结

本文探讨了从源头消除内存安全漏洞的方法。内存安全漏洞（如缓冲区溢出和释放后使用）是许多严重安全事件的根源。传统的“检测和修补”方法成本高昂且难以根除问题。因此，业界正转向从源头解决，主要策略是采用内存安全的编程语言。

核心观点认为，使用像Rust、Go或Swift这样在设计上就保证内存安全的语言，是消除这类漏洞最有效的方式。这些语言通过其编译器和运行时系统，在编译期或运行时强制执行内存安全规则，从根本上阻止了相关漏洞的产生。

文章也承认，完全迁移到新语言面临挑战，包括现有代码库的规模和对性能的要求。因此，一个务实的方法是采用混合模式：在新开发的关键组件中使用内存安全语言，同时逐步将现有不安全代码迁移到安全模块或接口背后。

此外，文章强调，除了语言选择，配套的安全开发实践（如严格的代码审查、静态分析工具和安全测试）对于保障整体软件供应链安全依然至关重要。最终，向内存安全语言的系统性迁移，是降低软件安全风险、提升互联网整体安全性的长期根本解决方案。

这是一个用于图像拼接的Python实现，能够自动搜索重叠区域。

👨‍💻 使用方法 代码提供了main函数用于合并两张图像，并设置了最小重叠区域等参数。result_visualize函数用于可视化合并结果。

from src.main import main
from src.utils.visualizer import result_visualize

merged_image, cand = main(
    image1=image1,              # 要合并的第一张图像
    image2=image2,              # 要合并的第二张图像
    min_overlap=(5, 5),         # 最小重叠区域
    verbose=False,              # 是否打印日志
)
result_visualize(
    image1=image1,
    image2=image2,
    merged_image=merged_image,  # 输出图像
    cand=cand,                  # 参数
)

🎯 效果预览 在CIFAR-10数据集上的测试结果展示了：

• 图1：输入图像示例（红色区域为空）。
• 图2：预处理后的输入图像（包含旋转处理，绿色框为重叠区域）。
• 图3：最终输出图像。

🧠 主要思路 算法核心基于重叠区域的宽度和高度来限制搜索空间，避免捕获过小或次优的重叠区域。

• 受限情况：通过设定重叠区域参数，高效定位最佳匹配区域。
• 通用性：当图像尺寸小于重叠区域参数时，通过调整对宽度和高度的理解视角（如图4、图5所示），使算法能够处理任意尺寸的图像。

🙋‍♂️ 支持与联系 项目鼓励用户点赞、分享，并通过提交Issue提供反馈。

本文是关于利用复杂网络分析意大利音乐史的研究。作者通过构建音乐家与乐队之间的协作网络，分析意大利20世纪至21世纪音乐的发展脉络与结构特征。

研究数据与网络构建

作者爬取了近2500支意大利乐队的维基百科和Discogs页面，记录了他们发行的每张专辑的演奏者和制作人信息。数据时间跨度从1902年（恩里科·卡鲁索的首批唱片）到2024年（但近期数据不完整）。原始数据构建了一个二分网络，将艺术家与他们参与的乐队连接起来。

网络投影与分析

基于此二分网络，进行了两种投影分析：

1. 乐队协作网络：若两个乐队在多年间共享了数量统计上显著的成员，则连接它们。该网络主要受时间邻近性影响，形成了从左到右的时间梯度。
2. 艺术家协作网络：若两位艺术家在同一乐队中共事，则连接他们。

主要发现

乐队网络的时间与流派结构

• 时代划分：通过节点属性距离度量，可基于乐队平均发行年份在该网络中识别出意大利音乐的不同历史时期。
• 动态演变：通过网络方差分析发现，意大利音乐历史上最具动态性的时期是从1960年代末到1980年代初。
• 流派分布：流行、摇滚和电子三大流派在网络中形成了清晰的领域，而嘻哈音乐则位于它们的交集处。同样可通过流派属性距离进行聚类分析。

对最初假设的验证：朱安尼·马罗科洛的地位

最初引发研究的问题是：朱安尼·马罗科洛是否是意大利音乐的“弥赛亚”（核心人物）。通过分析艺术家协作网络（第二投影）的中心性指标（度中心性、接近中心性、中介中心性），发现马罗科洛并未进入任何一项中心性指标的前十名。在所有三项指标中均进入前十的唯一艺术家是保罗·弗雷苏，因此作者将“意大利音乐之王”的称号转授予他。

论文发表

该研究最终以论文形式发表于《应用网络科学》期刊，题为“节点属性分析用于文化数据分析：以意大利20-21世纪音乐为例”。