逆向工程TicketMaster动态条码

背景与问题

作者购买TicketMaster音乐会门票后，发现必须使用其SafeTix动态条码系统（条码每15秒自动刷新）入场，而非传统可打印PDF票据。该系统在拥挤场馆因网络信号差导致多人无法加载条码，暴露了实时依赖互联网的缺陷。

TicketMaster的营销宣称

TicketMaster宣传SafeTix通过动态条码防止欺诈和非法转让，声称截图或打印件无法扫描。但作者指出：

• 条码的“移动动画”仅是CSS视觉效果，不影响截图后的可读性。
• 强制安装官方应用带来隐私风险，且离线使用能力与数据隔离政策存在逻辑矛盾。

技术逆向分析

1. 条码格式

   • 使用PDF417条码编码UTF-8文本，结构为：静态Base64令牌::TOTP1::TOTP2::Unix时间戳。

2. 动态机制

   • 两个6位数字码类似TOTP（基于时间的一次性密码），每15秒更新。
   • 静态Base64数据解码后为48字节随机数据，充当票据标识令牌。

3. 密钥发现
   通过Chrome DevTools分析TicketMaster Web应用：

   • 从/api/render-ticket/secure-barcode接口响应中提取JSON数据，包含字段：
     • t：静态票据令牌（48字节）。
     • ck（客户密钥）和ek（事件密钥）：20字节十六进制数。
   • 源码分析显示generateSignedToken函数使用ck和ek作为密钥，结合15秒时间步长生成TOTP。

4. 验证确认
   使用oathtool命令行工具，以ek和ck为密钥、对应时间戳生成TOTP，结果与条码中的数字匹配，证实了密钥用途。

5. 令牌提取

   • 原始令牌可直接从浏览器控制台获取（组件挂载时自动打印）。
   • 若持有有效的票据令牌、事件密钥和客户密钥，可生成完全相同的动态条码。

令牌有效期与离线使用

• 根据TicketMaster开发者文档，原始令牌有效期可能约20小时，需在活动开始前刷新。
• 作者构建了离线应用TicketGimp，输入令牌即可生成条码，证明无需官方应用亦可实现票据验证。

结论

TicketMaster的SafeTix系统技术上并未实现绝对的反欺诈，其动态机制基于标准TOTP算法。通过逆向工程可提取必要参数实现离线使用，但该系统仍限制了票据转让并推动用户使用其封闭生态。作者批评该技术设计服务于商业垄断而非用户便利，并呼吁拆分TicketMaster。

JavaScript中模拟2000万个粒子的技术总结

核心挑战与初始方案

作者的目标是使用纯JavaScript（不使用GPU或WASM）在移动设备上模拟100万个粒子并保持60fps。初始方案是使用对象数组和forEach循环进行更新，但考虑到移动设备多核CPU的特性，需要并行化处理。

性能优化的关键策略

1. 数据结构的优化：

   • 为避免JavaScript对象的开销和内存碎片问题，使用TypedArray（如Float32Array）和SharedArrayBuffer来存储粒子数据（x, y, dx, dy等）。
   • 确保数据在内存中是紧密连续的，以提高CPU缓存命中率。

2. 多线程并行化：

   • 使用Web Workers将模拟计算分配到多个CPU核心。
   • 主线程和Worker之间通过SharedArrayBuffer共享数据，配合信号机制（或postMessage）进行同步，尽量避免多个线程同时写入同一内存地址，以保证确定性。

3. 渲染优化：

   • 采用CPU软件渲染：在主线程使用ImageData和Canvas，将每个粒子绘制为一个像素点。
   • 为提升渲染性能，将渲染任务也分发给Worker线程。每个Worker拥有独立的像素缓冲区，最后在主线程合并结果。
   • 引入双缓冲技术，使渲染和模拟可以流水线化进行，减少等待时间。

4. 交互功能实现：

   • 通过监听鼠标/触摸事件，将交互数据（如位置、是否触摸）写入共享内存供Worker读取。
   • 在模拟中加入了基于距离平方反比的“引力”效果，并进行了艺术化调整以增强交互体验。

面临的挑战与进一步优化

• 数据缓存问题：粒子更新渲染时，对像素缓冲区的随机访问导致缓存未命中，成为性能瓶颈。
• 内存与计算开销：随着粒子数量增加（如1000万），内存占用和主线程合并像素缓冲区的成本急剧上升。
• 解决方案：
  1. 使用粒子计数网格：不再为每个Worker存储完整的像素颜色缓冲区，而是让所有Worker共享一个网格，网格中每个单元格记录落入其中的粒子数量。最后根据计数计算颜色。这大幅减少了内存占用，并消除了主线程合并多个缓冲区的开销。
  2. 结合GPU渲染：将粒子计数网格作为纹理，利用WebGL进行最终渲染。CPU只需更新网格数据并上传纹理，渲染由GPU高效完成。这种方法突破了CPU渲染的瓶颈，最终实现了2000万粒子的模拟。

最终成果与总结

• 通过上述一系列优化，在纯JavaScript环境下，实现了在移动设备上以60fps运行100万粒子模拟。
• 结合GPU纹理渲染后，可处理高达2000万至4000万粒子（取决于CPU核心数），展示了JavaScript在性能密集型场景下的潜力。
• 核心经验：高性能计算的关键在于缓存友好的内存访问模式、减少数据移动以及充分利用并行计算。了解硬件（如CPU缓存层级、多核特性）对于优化至关重要。

适用于 macOS 的现代 Jupyter 客户端概述

本文介绍了一款专为 macOS 打造的现代化 Jupyter 客户端，旨在通过极简设计和强大的 AI 辅助功能，为开发者提供更快速、流畅的编码与数据分析体验。

核心功能与特性

1. 极速启动与 AI 辅助编码

• 性能优越：启动速度显著快于 VS Code 和 JupyterLab。
• AI 深度集成：支持上下文感知的提示单元格（Prompt cells）内联生成代码；提供智能自动补全和 AI 代码重写（AI Edits）功能；可通过 Agent 模式实现数据分析自动化。
• 自然语言交互：支持以自然语言编写提示，并像执行代码一样运行。

2. 强大的开发与数据处理能力

• 数据库与远程连接：支持连接远程服务器；内置 SQL 单元格可直接查询数据库，并能引导 AI 学习数据库 Schema。
• 代码质量管控：集成 Linting 检查与 Black 代码格式化，确保代码规范且减少 Bug；提供便捷的代码搜索功能。
• 数据可视化：集成 Plotly，支持交互式探索海量数据点，并可一键复制图表与表格。
• 环境管理：提供极其简便的虚拟环境管理方案。

3. 极简设计与专注体验

• 无干扰界面：采用极简设计帮助用户保持专注（心流状态）；冗长的错误信息默认截断显示，避免视觉干扰。
• 命令面板：内置命令面板（Command Palette），方便用户快速查找功能和管理快捷键。

4. 开箱即用的简易配置

• 无缝集成 macOS：兼容所有 .ipynb 文件，支持直接从 Finder 中双击启动。
• 自动环境检测：自动识别并加载系统中现有的 Jupyter 内核（Kernels）和 Conda 环境。
• 零配置：无需复杂的环境搭建与设置，下载应用后即可直接开始编码。

Onlook：开源可视化代码编辑器

Onlook 是一个开源的、以可视化为主导的代码编辑器，旨在通过 AI 在 Next.js + TailwindCSS 环境中创建网站、原型和设计。它允许用户在浏览器 DOM 中直接进行可视化编辑，实时关联代码，是 Webflow、Figma Make、Bolt.new 等工具的开源替代方案。

当前状态与协作邀请 该项目仍在积极开发中（🚧 状态），团队正在寻找贡献者来共同打造优秀的“提示词到构建”体验。开发者可以通过查看开放问题和加入 Discord 社区参与协作。

核心功能

• 快速创建应用：在几秒内创建 Next.js 应用，支持从文本、图像、预置模板、Figma 文件或 GitHub 仓库导入，并可直接向 GitHub 仓库提交 PR。
• 可视化编辑：提供类似 Figma 的界面，支持实时预览、管理品牌资产和组件、页面导航、图层浏览、图像管理以及组件检测与拖拽面板。支持使用分支进行设计实验。
• 开发工具：包含实时代码编辑器、从检查点保存/恢复、通过 CLI 运行命令以及连接应用市场。
• 快速部署与团队协作：可在数秒内部署应用，生成可分享链接并绑定自定义域名。支持团队实时编辑和评论。
• 高级 AI 能力：支持队列多条消息、使用图像作为项目中的参考或资产、在项目中设置和使用 MCP（工具调用），并允许 Onlook 将自身作为工具调用来进行分支创建和迭代。
• 高级项目支持：未来计划支持非 Next.js 和非 Tailwind 的项目。

技术架构与工作原理

1. 创建应用时，代码被加载到 Web 容器中运行并提供服务。
2. 编辑器接收预览链接并在 iFrame 中显示。
3. 编辑器读取并索引容器中的代码，并通过工具将界面元素映射到其代码位置。
4. 元素被编辑时，先在 iFrame 中修改，随后同步更新代码。
5. AI 聊天同样拥有代码访问权限和工具，可以理解和编辑代码。 此架构理论上可扩展至任何声明式渲染 DOM 元素的语言或框架（如 JSX/TSX/HTML），目前专注于 Next.js 和 TailwindCSS。

技术栈

• 前端：Next.js、TailwindCSS、tRPC
• 数据库：Supabase（认证、数据库、存储）、Drizzle（ORM）
• AI：AI SDK、OpenRouter、Morph Fast Apply、Relace
• 沙盒与托管：CodeSandboxSDK、Freestyle
• 运行时：Bun（ monorepo 管理、运行时、打包）、Docker（容器管理）

参与和许可 项目采用 Apache 2.0 许可证分发。欢迎通过 Fork 仓库提交 Pull Request 或创建 Issue 参与贡献。详细贡献指南见 CONTRIBUTING.md。

文章核心观点：作者认为当前浏览器市场被Chrome主导，缺乏健康竞争，威胁开放网络。尽管Firefox是重要的替代选择，但其运营方Mozilla的商业模式和治理结构存在问题，无法接受用户的直接资助。因此，作者选择资助新兴的、接受用户资助的Ladybird浏览器项目，以证明用户资助模式的可行性。

浏览器多样性的重要性

• 一个开放的网络需要多个竞争的浏览器，避免单一厂商（如谷歌）垄断Web标准。
• 历史教训：微软IE的垄断曾阻碍Web发展，而Firefox的竞争推动了开放。
• 当前现状：Chrome市场份额超过65%（加上使用同引擎的Edge超过70%），谷歌可推行如限制广告拦截的Manifest V3等政策。

为何无法资助Firefox？

1. 收入结构问题：Firefox由Mozilla Corporation运营，其主要收入（2022年占81%）来自与竞争对手谷歌的搜索合作协议。
2. 商业决策争议：为增收，Mozilla采取了损害用户体验的措施：
   • 内置广告、赞助链接、推广“Pocket”阅读列表等。
   • 静默安装推广插件（如Mr. Robot扩展）。
   • CEO薪酬高昂（2022年690万美元），而市场份额却在下降。
3. 捐赠渠道缺失：Mozilla基金会接受捐赠，但针对的是Thunderbird邮件客户端，而非Firefox。尽管架构上可能可行，但Mozilla始终未开放对Firefox的用户直接资助。

选择资助Ladybird

• 项目背景：Ladybird最初是SerenityOS的浏览器，2024年6月独立成为专注于浏览器开发的非营利项目（Ladybird Browser Initiative）。
• 现状与承诺：项目尚不完整（首个Alpha版计划于2026年发布），但已有可运行的代码，并且接受用户资助。
• 个人行动：作者决定每月捐赠15美元，并呼吁其他人也通过资助来支持用户主导的浏览器开发模式。

补充观点

• 广告拦截的必要性：在线广告体验极差，广告拦截器对用户体验、旧电脑寿命及安全至关重要，连FBI都推荐使用。
• Web标准的倒退：缺乏浏览器竞争导致谷歌能强推“加密媒体扩展”（DRM）等损害用户控制权的功能，而Mozilla为维持份额未能坚决抵制。

波音公司同意就与737 MAX致命坠机事件相关的刑事欺诈指控认罪，这将使这家美国航空航天巨头成为“重罪犯”，但能帮助其避免审判，并试图从安全和制造危机中翻开新的一页。

根据协议，波音将面临最高4.872亿美元的罚款，但司法部建议法院将波音根据先前协议已支付的金额计入其中，从而使罚款减至2.436亿美元。该认罪协议需经联邦法官批准方可生效。

若协议获批，作为重罪犯，波音向美国政府销售产品的能力可能会受到影响，尽管公司可以寻求豁免。波音去年近780亿美元的收入中，约32%来自其国防、太空与安全部门。国防部官员表示将评估波音的补救计划及与司法部的协议，以确定采取何种必要和适当措施保护联邦政府。

协议还包括设立独立监督员，在三年缓刑期内监督波音的合规情况。根据法庭文件，波音还必须至少投资4.55亿美元用于合规和安全计划，并同意其董事会与坠机事故受害者家属会面。

该协议是司法部于周日晚公布的。此前数月，美国检察官表示这家航空航天巨头违反了2021年的一项使其免于起诉三年的和解协议。认罪协议迫使波音选择要么认罪并接受附加条款，要么面临审判，而此时公司正试图扭转制造和安全危机、遴选新首席执行官并收购其机身制造商Spirit AeroSystems。

波音在一份声明中确认，已与司法部就解决条款原则上达成协议，具体条款需待书面化并获批。

2021年，波音同意支付25亿美元（包括2.436亿美元刑事罚款、对航空公司的赔偿以及5亿美元的受害者家属基金）以达成延期起诉协议。美国指控波音阴谋欺骗政府，就其在MAX机型上安装的、后被认定与两起坠机事件有关的飞行控制系统误导监管机构。这两起坠机事件——2018年10月的狮航航班和2019年3月的埃塞俄比亚航空航班——共导致机上346人全部遇难。

司法部周日提出认罪协议后不久，受害者家属在法庭文件中表示将反对该协议，认为其“对波音做出了其他刑事被告永远无法获得的不公平让步，未能让波音为346人的死亡负责”。家属的律师保罗·卡塞尔表示，法官应拒绝该协议，“直接安排公开审判，让所有案件事实在陪审团面前于公平公开的论坛上得以呈现”。

协议要求监督波音缓刑期的公司监督员必须具有独立性，这一点旨在解决受害者家属律师的关切。协议还规定波音向受害者幸存亲属支付的赔偿金额不设上限。尽管如此，律师们仍坚持波音应受审。家属的另一位律师埃琳·阿普尔鲍姆表示：“波音是一家大公司。无论他们给家属开多少支票，都无法换回家人的生命。”

本文介绍了如何将一块2英寸SPI显示屏用作树莓派的显示器，使其能像普通HDMI显示器一样显示终端（TTY）和X图形桌面环境。目标是构建一个可外接键盘的手持式“主机”。

硬件配置：

• 显示屏：Adafruit的2英寸240x320 IPS TFT屏，采用ST7789控制器，通过SPI接口通信。
• 计算机：树莓派Zero 2 W（成本约15英镑），也适用于其他树莓派型号。
• 接线：共8条线，包括电源（两根）、SPI信号（MOSI、SCK、CS），以及数据/命令（D/C）、背光（支持PWM调光）和复位线。

与显示屏通信： 显示屏通过发送命令和参数进行控制。作者封装了一个C语言API，封装了初始化、设置颜色格式、地址模式及绘制图像等功能。API能自动将大块数据（如全屏图像）分块发送，以避免超过SPI缓冲区限制（默认4096字节，可调至65536字节）。

用作显示器的实现： 核心思路是强制树莓派输出与TFT屏相同分辨率（320x240）的图像，然后将帧缓冲区数据通过SPI传输至屏幕。

1. 终端显示：通过读取 /dev/fb0 获取TTY终端的帧缓冲区数据（16位色深），经内存映射后复制到屏幕。需在树莓派配置中强制热插拔并设置分辨率为320x240。
2. X11桌面显示：无法直接使用帧缓冲区，需使用Xlib库每帧抓取X屏幕图像。需手动配置X11以使用正确的分辨率和16位色深。还通过在新图像上覆盖绘制光标图标解决了X11不显示鼠标指针的问题。

最终程序： 作者编写了一个作为系统服务运行的镜像程序。它包含两个线程：

• 管理线程：监控活动TTY以决定使用帧缓冲模式（TTY）还是X11模式（桌面），并检测X的DPMS状态以实现屏幕休眠（关闭背光）。
• 渲染线程：根据模式从相应源（帧缓冲或X）获取图像数据并发送到屏幕。

程序处理了X11错误（如退出桌面时）以避免崩溃，采用了 setjmp/longjmp 进行异常处理，确保能平滑切换回帧缓冲模式。

最终效果： 系统服务运行时占用约2.5MB内存和2% CPU，支持DPMS节能。

自行设置指南：

1. 接线：按文末表格连接树莓派GPIO与显示屏引脚。
2. 软件配置：
   • 启用SPI（通过 raspi-config 或编辑 /boot/config.txt）。
   • （可选）增大SPI缓冲区大小。
   • 在 /boot/config.txt 中设置强制HDMI输出及320x240分辨率。
   • 创建X11配置文件 /etc/X11/10-monitor.conf 指定16位色深和320x240模式。
   • 安装依赖库 libx11-dev 和 libxext-dev。
3. 安装服务：
   • 克隆代码并用 make 编译（可优化参数）。
   • 将二进制文件放到指定路径。
   • 创建systemd服务文件并启用，使其开机自启。

Xpra: 持久化远程X11应用程序

Xpra 被称为“X11的screen工具”。其无缝模式允许您在远程主机上运行X11程序，并将显示定向到本地机器，然后断开与这些程序的连接，并从相同或不同的机器重新连接，而不会丢失任何状态。这实际上为您提供了对单个图形应用程序的远程访问。它还可用于访问现有桌面会话和启动远程桌面会话。

Xpra是开源的（GPLv2+），客户端支持多个平台，服务器内置了HTML5客户端。它能在多种网络协议上运行，并尽力适应各种网络条件。Xpra转发并同步许多额外的桌面功能，使远程应用程序能够透明地集成到客户端的桌面环境中，包括：音频输入和输出、打印机、剪贴板、系统托盘、通知、摄像头等。它还可以远程打开文档和URL，显示高色深内容，并会尝试遵循显示器的DPI设置。

安装

• 官方稳定下载：提供Windows（EXE， ZIP， MSI）、macOS（x86_64/arm64 DMG/PKG）和Linux（RPM， DEB）的安装包，所有包均有签名。此外还提供LTS和测试版构建。
• 从源码构建：可通过Git克隆仓库并使用python3 ./setup.py install命令安装。

使用

• 前提条件：客户端和主机上都必须安装xpra，或者可使用仅需主机安装xpra的HTML5客户端。
• 无缝模式：在远程主机运行程序并在本地显示，例如：xpra seamless ssh://USER@HOST/ --start=xterm。
• 影子模式：查看远程主机上正在运行的现有桌面会话：xpra shadow ssh://USER@HOST/。
• 网络访问：Xpra服务器可通过单个TCP端口支持多种连接类型（SSL、SSH、HTTP/WebSockets、RFB等），支持加密和多种认证模块。会话可通过多播DNS在局域网内自动通告，便于客户端连接。灵活的代理服务器可用作多个服务器会话的中继或前端。

文档与帮助 当前开发版本有详尽的文档，并随每个发布版附带。更通用的信息可参考项目Wiki。若需帮助，可查阅FAQ，或在GitHub讨论区、IRC频道(#xpra on libera.chat)及Discord提问。如遇bug，请参考错误报告指南。

奔腾处理器中的标准单元设计探秘

1993年，Intel发布了性能强大的奔腾处理器。尽管该芯片拥有330万个晶体管，其晶体管结构在显微镜下仍清晰可见，不同于现代芯片。通过移除芯片的四层金属层，可以观察到底层的硅结构，揭示出用于构建逻辑门、触发器等电路的标准单元技术。

标准单元设计原理

早期的处理器（如Z80）采用手动布局每个晶体管，过程繁琐且易错。标准单元设计则通过预先创建的标准单元库（包含各类逻辑门、触发器等）来解决问题。这些单元具有固定的高度和可变的宽度，可以排列成行，并通过自动化“布局与布线”软件进行设计。这种方法在Intel的386处理器中开始采用，大幅提升了效率并减少了错误。

CMOS电路基础

奔腾处理器基于CMOS工艺，使用NMOS和PMOS两种晶体管。NMOS在栅极高电平时导通，适合拉低输出；PMOS则相反。两者协同工作，实现互补逻辑。芯片采用600纳米工艺，晶体管结构在显微镜下可见。奔腾的构建更为复杂，包含四层金属布线（M1至M4），用于连接晶体管和传递信号。

关键标准单元实现

通过去除金属层后的显微镜图像，可以观察到标准单元的具体实现：

1. 反相器：最简单的CMOS门，由一个PMOS和一个NMOS晶体管组成。输入为高时，NMOS导通，输出为低；反之，PMOS导通，输出为高。
2. NAND门：由两个PMOS（并联）和两个NMOS（串联）晶体管构成。仅当所有输入为高时，输出才为低。
3. 复杂逻辑门：如5输入OR-NAND门（计算~((A+B+C+D)·E)），其晶体管拓扑结构更复杂。
4. 锁存器：用于存储1位数据。其核心是一个多路选择器（MUX），利用“传输晶体管”在时钟信号控制下选择输入或保持之前的值。传输晶体管仅作为开关传递信号，而非将输出拉至电源或地。
5. 触发器：在奔腾中广泛使用，采用边沿触发。它由两个锁存器（主和从）级联而成，在时钟上升沿捕获并输出数据。其标准单元包含复杂的金属布线以连接子组件。
6. BiCMOS缓冲器：奔腾的特色是使用了BiCMOS工艺，结合了CMOS和双极型晶体管（如NPN管）。这种缓冲器结构复杂，能提供更高的电流驱动能力并减少信号延迟。NPN晶体管呈圆形结构，明显区别于CMOS晶体管。

结论

标准单元设计是构建复杂处理器的基石，其自动化和模块化特性在现代芯片中依然通用。奔腾处理器因其较大的特征尺寸，成为了观察和研究早期数字电路实现的宝贵“时间胶囊”。尽管随着工艺微缩和电压降低，BiCMOS技术最终被放弃，但它在奔腾时代提升了性能。对这些基础单元的审视表明，即使是最复杂的处理器也是由可观察、可理解的基本晶体管电路构成。

Pyxel：适用于 Python 的复古游戏引擎

Pyxel 是一款专为 Python 语言设计的复古游戏引擎，旨在让开发者能够轻松创建像素艺术风格的游戏。

核心特性

• 复古规格限制：引擎设计灵感源自早期复古游戏机，采用极简的技术规格。例如，仅支持 16 种颜色显示和同时播放 4 个声音通道，从而完美还原经典的复古游戏体验。
• 开源且免费：该项目基于 MIT 许可证开源，允许用户免费且自由地使用。
• 独立开发维护：项目由个人开发者独立推进，并依靠 GitHub 社区的 Star（星标）鼓励来维持持续开发。

资源与社区支持

为了帮助开发者更好地使用引擎，Pyxel 提供了以下配套资源：

• 用户指南：提供详细的文档，帮助开发者快速上手。
• 用户示例：展示丰富的参考案例，激发创作灵感。
• 作品分享：提供专门的渠道供开发者提交和分享自己制作的游戏作品。

TUI for Managing WiFi on Linux

🎯 简介

这是一个名为 Impala 的终端用户界面（TUI）工具，用于在Linux系统上管理WiFi网络。

✨ 核心功能

• 支持 WPA Enterprise (802.1X) 认证。
• 同时支持 Station（连接模式） 和 Access Point（热点模式）。
• 可通过生成 二维码 快速分享网络。
• 支持连接 隐藏网络。

💡 系统要求

• Linux操作系统。
• 后台服务 iwd 正在运行。
• （可选）nerdfonts 以支持图标显示。
• 重要提示：为避免冲突，应禁用如 NetworkManager 或 wpa_supplicant 等其他无线管理服务。

🚀 安装方式

提供多种安装途径：

1. 下载预编译二进制文件：从项目的 GitHub 发布页面下载。
2. 通过 crates.io 安装：使用 Cargo 包管理器安装。
3. 特定发行版包管理器：
   • Arch Linux：通过 pacman 从官方仓库安装。
   • NixOS：使用 nix-env -iA nixpkgs.impala 命令安装。
4. 从源码编译：

   git clone https://github.com/pythops/impala
   cd impala
   cargo build --release
   

   生成的可执行文件位于 target/release/impala，可将其复制到 $PATH 路径下的目录中。

🪄 使用与配置

• 主要通过 终端界面 交互。
• 键位绑定 高度可自定义，配置文件路径为 $HOME/.config/impala/config.toml。
• 配置示例：

  switch = "r"
  mode = "station"
  esc_quit = false  # 设为 true 则按 Esc 键退出程序
  
  [device]
  infos = "i"
  toggle_power = "o"
  
  [access_point]
  start = 'n'
  stop = 'x'
  
  [station]
  toggle_scanning = "s"
  
  [station.known_network]
  toggle_autoconnect = "t"
  remove = "d"
  show_all = "a"
  share = "p"
  
  [station.new_network]
  show_all = "a"
  connect_hidden = ""
  

🤝 贡献指南

• 不接受 AI 生成的内容。
• 提交拉取请求前，需先建立议题或进行讨论。
• 保持拉取请求精简且目标明确。

⚖️ 许可证

项目采用 GPLv3 许可证。

Geomys：可持续开源维护公司蓝图

核心理念 Geomys 是一家专注于 Go 生态系统关键开源项目的专业维护公司，旨在为"开源维护者"这一职业探索可持续的商业模式。

公司背景与团队

• 由前Google工程师于2023年创立，从独立维护者转型为小型公司。
• 核心团队包括：
  • 联合创始人：Filippo Valsorda
  • 关联维护者：Nicola Murino（维护x/crypto/ssh）、Dominik Honnef（维护Staticcheck和Gotraceui）
  • 行政总监：Matilde Dal Zilio

项目组合 维护一系列广泛使用、基础性的Go开源项目：

• Go标准库的crypto/...和golang.org/x/crypto/...（与Google团队共同维护）
• filippo.io/... 加密包（包括edwards25519）
• x/crypto/ssh：Go的SSH实现，支撑众多CI/CD系统
• Staticcheck：被vscode-go默认启用的高信噪比静态分析器
• Gotraceui：Go执行跟踪可视化分析工具
• bluemonday：流行的HTML清理器
• age：文件加密工具、库和格式
• mkcert：用于生成本地开发证书的工具

商业模式

• 客户端：企业客户支付固定月度年费，以确保整个项目组合得到专业维护，并获得所有维护者的专家访问权限。
  • 提案简洁：确保关键依赖可持续、可预测地维护，并获得难以内部培养的专家访问权。
  • 对客户而言，成本远低于雇佣一名全职高级工程师。
• 维护者端：
  • 关联维护者获得稳定、有保障的收入（远高于GitHub Sponsors收入），并可获得未来年费收入增长的分成。
  • 无版权转让、无锁定期限、无GitHub所有权转移。保持灵活性，维护者可按自己的方式和时间工作。
  • 公司承担行政、法律、沟通、销售等支持成本，为维护者提供难以单独承担的资源。

运营哲学

• 专注Go：深耕Go生态系统，确保相关性和专业深度，避免稀释资源。鼓励他人在其他技术栈建立类似公司。
• 有机增长：不寻求外部投资，依靠现有现金流支持。缓慢、有机地扩展团队和项目组合。
• 低开销管理：不微观管理维护者，旨在为其提供支持，使其能专注于已擅长的工作。
• 客户信任：客户认可专业团队维护的价值，愿意支持公司扩大项目维护范围。

愿景与目标 Geomys 是推动"开源维护者"成为成熟职业的又一步。它提供了一个可复制的小型专业公司模型，使维护者无需承担独立创业的风险即可获得可持续收入，并为依赖关键开源组件的企业提供了清晰、可靠的维护保障。

现代间谍活动：有时老技术更安全

在冷战时期，间谍机构广泛使用短波广播进行秘密通信。从20世纪60年代中期到2008年，任何在短波频率（5.422至16.084兆赫兹）之间调谐无线电的人，都可能会周期性地听到一段欢快的英国民歌长笛演奏。随后，一个带有清晰英国口音的女声会开始朗读数字：“零、二、五、八……”这些传输被认为是英国军情六处发送的编码信息。其中最著名的便是被命名为“林肯郡偷猎者”的广播站，它以其欢快的曲调而闻名，是间谍机构与现场特工通信的众多“数字广播站”之一。

这种老式的技术手段在今天看来可能有些过时，但它具有一些现代数字通信难以比拟的安全优势。短波广播的信号可以传播极远距离，且接收设备简单廉价。对于情报机构而言，最重要的是其匿名性和单向性。接收者只需知道频率和时间，无需任何回传信号，这使得追踪定位变得极其困难。现代网络通信虽然高效，却容易留下数字痕迹，而传统的无线电广播在加密和隐匿方面反而提供了独特的保护层。

文章指出，尽管现代技术日新月异，但老式的技术方法在某些特定的安全场景下仍保有其价值。这提醒我们，在追求新技术的同时，不应完全忽视经过时间考验的传统工具。安全的核心在于根据具体需求选择最合适的方法，有时，最简单的手段反而最有效。

本文是ICANN（互联网名称与数字地址分配机构）官网提供的一个页面，旨在公开透明地展示已被终止的顶级域名（gTLD）注册局协议列表，特别是那些被视为“虚荣”的、通常由特定品牌或组织持有的顶级域名。

页面核心内容与流程

该页面提供了关于注册局协议终止的最新信息。根据《新gTLD注册局协议》，协议任何一方均可在满足特定要求（如协议第4.4(b)条）的情况下终止协议。终止流程通常包括：

1. 终止通知：注册局运营商或ICANN发出终止通知。
2. 初步确定：ICANN在与注册局运营商协商后，进行“初步确定”，决定是否将该顶级域名的运营权移交给继任注册局运营商。
3. 公众评论：ICANN就其初步确定公开征求公众意见。
4. 最终确定：ICANN考虑所有意见后，做出“最终确定”。最终结果通常有两种：
   • 不移交运营权：终止协议，并撤销该顶级域名在根区的授权。但这不排除该顶级域名在未来的新gTLD申请轮次中重新申请。
   • 移交运营权：终止原协议，但将该顶级域名的运营权移交给新的继任注册局运营商。
5. 执行：根据最终确定执行，即撤销授权或完成移交。

终止协议列表特点

页面主体是一个持续更新的表格，列出了从2015年至2025年期间被终止的顶级域名协议。列表呈现以下特点：

• 时间跨度：从2015年9月的.doosan到2025年9月的.goo，涵盖了近十年的时间。
• 主要终止方：绝大多数案例是由注册局运营商主动发起终止（依据协议第4.4(b)条）。少数案例由ICANN主动终止（如2024年12月对.nowruz、.pars、.shia等域名的处理）。
• 域名性质：被终止的域名多为品牌、企业名称、产品名或特定组织名称的“虚荣”顶级域名，例如：
  • 品牌/公司：.wolterskluwer（威科集团）、.bentley（宾利汽车）、.volkswagen（大众汽车）、.intel（英特尔）、.burgerking（汉堡王）。
  • 组织/产品：.goo（NTT DOCOMO）、.nowruz（波斯新年）、.pars（波斯地区名称）。
  • 中文域名：表格中包含非拉丁字符的顶级域名（IDN TLDs），如xn--mgbt3dhd（代表.shia的波斯语域名）、xn--3oq18vl8pn36a（大众汽车中国投资有限公司的中文域名）等。
• 最终结果：列表中绝大多数顶级域名最终的结局是“TLD Delegation Revoked”（授权被撤销）和“Registry Agreement Terminated”（协议终止）。仅有极少数域名（如2023年的.desi和2020年的.wed）的最终确定是“Transition Operation of the gTLD”（移交运营权）。
• 流程状态：表格清晰展示了每个案例从通知到最终执行的各个阶段和日期，包括评论开放与截止日期，体现了流程的公开性。

总结

该页面是ICANN履行其开放透明承诺的体现，系统地记录并公开了大量“虚荣”顶级域名注册协议被终止的过程与结果。这些终止主要由原注册局运营商主动发起，表明许多企业或组织在申请并运营自己的品牌顶级域名后，因各种原因（如业务调整、成本考量等）选择放弃。ICANN的标准化处理流程确保了终止过程的有序和公开，并通过公众参与机制增强了决策的透明度。最终，这些被终止的顶级域名大多被永久撤销授权，退出互联网根区。

滑雪板确实会变钝。作者在文中反驳了一位自称前奥运滑雪调校师的观点——该观点认为滑雪板变钝仅因腐蚀，只要保持干燥就能维持锋利。作者通过个人实践和显微镜观察提出，滑雪板边缘的磨损实际主要来自摩擦损伤，而非单纯的腐蚀。

作者展示了滑雪板使用约4天后的边缘显微镜图像，指出理想的滑雪板边缘应呈约88°角，但实际图像显示边缘出现圆角化和金属缺损，形成微小的锯齿状结构。这种磨损模式与腐蚀造成的坑蚀、圆钝化损伤特征不同。作者认为，这种磨损会导致滑雪板在某些雪况下出现“抓雪”现象。

文中还提到，修复这类磨损并不复杂。作者使用3D打印夹具配合500目金刚石磨石，沿边缘轻划几次即可恢复锐利角度，消除锯齿。修复后的边缘呈现清晰锐利的角度，作者强调滑雪板锋利度对冰面滑行安全至关重要。

文章开头简要介绍了作者Marc Brooker的背景，他是AWS工程师，业余爱好包括机械加工、焊接、烹饪和滑雪。文末补充说明，滑雪板边缘经打磨后会留有毛刺，但作者未观察到去除毛刺对其滑雪体验有显著影响。

Python包管理工具过多问题

Python编程语言虽然强大，但其包和环境管理生态系统碎片化严重，与其他语言（如Rust的Cargo、JavaScript的npm）的标准化方案形成鲜明对比。

理想包管理模式

以Rust的Cargo为范本：通过单一TOML配置文件管理依赖和设置，生成lock文件确保可重复性，依赖解析应快速高效，使用公开元数据API并本地缓存。

Python工具现状

经典工具

• pip和venv：pip是原始包管理器，但依赖解析能力弱（2020年后加入回溯功能），不管理虚拟环境；venv用于创建隔离环境，但卸载依赖时不会自动删除子依赖。
• pyenv：管理不同Python版本，但易误用导致项目版本混乱。
• pipenv：结合pip和venv，使用Pipfile和Pipfile.lock，但依赖解析不佳且不遵循新标准PEP 621。

配置文件冗余

历史上存在多种配置文件（如requirements.txt、setup.py、Pipfile、environment.yml等），造成重复和混乱。2020年PEP 621被接受，提议将配置统一到pyproject.toml文件中。

基于PEP 621的新工具

• Poetry：接近理想工具，支持pyproject.toml，管理虚拟环境并生成lock文件，但依赖解析慢（算法用Python编写），且依赖上限指定可能引发冲突。
• PDM：类似Poetry，但支持PEP 582（无需显式虚拟环境），更符合PEP标准。
• Hatch：完整构建系统，支持并行测试多Python版本。

Conda生态系统

• conda：管理Python和非Python依赖，适合数据科学，但配置冗余，不支持pyproject.toml，不生成lock文件。
• mamba：conda的C++重写，依赖解析更快（使用libmamba解析器）。

Rust相关工具

• huak：实验性工具，尝试移植Cargo体验到Python。
• pixi：替代conda的工具，用Rust编写，支持lock文件。
• rye：最初依赖pip工具，现由Astral.sh维护，使用uv解析器，功能类似Poetry。
• uv：最有前景的工具，用Rust编写，旨在成为pip替代品和Python版Cargo，依赖解析速度快（基于回溯算法），支持pyproject.toml。

总结与展望

Python包管理碎片化问题持续存在，目前数据科学推荐使用conda，生产环境可用pip或Poetry（但Poetry解析较慢）。新兴工具如uv有望未来统一生态，但需等待API稳定和社区采用。

《哈佛商业评论》2005年发表的文章《自我管理》（Managing Oneself）指出，在知识经济时代，个人成功的关键在于自我认知——了解自己的优势、价值观以及最佳工作方式。

文章回顾历史，指出普通人过去很少需要主动管理职业道路，要么依赖出生阶层，要么由公司规划职业生涯。然而，历史上伟大的成就者（如拿破仑、达芬奇、莫扎特）始终在进行自我管理，这正是其卓越成就的重要原因。但这些人物天赋异禀、成就非凡，属于特例。

如今，绝大多数人，即便是天赋普通者，也必须学会自我管理。这意味着需要学会自我发展，将自己置于能够做出最大贡献的位置，并在长达50年的职业生涯中保持思维敏捷与投入，因此必须懂得何时以及如何转变自己的工作内容。

文章标题： Unit 是一个通用的可视化编程系统

内容摘要： 本文内容为一个网页的简介，该页面属于 Unit 可视化编程系统。根据描述，其核心信息是：Unit 是一个通用目的的可视化编程系统，且当前页面为该系统的主页。

ShareDrop：被LimeWire收购及经典版本介绍

收购动态 ShareDrop已被领先的文件共享平台LimeWire收购。用户现在可以通过ShareDrop（sharedrop.io）或LimeWire（limewire.com）继续享受以下服务：

• 在同一网络内设备间传输文件。
• 支持匿名上传与下载。
• 提供端到端加密。
• 免费用户享有最高40GB的存储空间。
• 注册用户可使用集成的AI工具。 ShareDrop的GitHub代码库将保持原样，用户仍可下载并在自己的基础设施上运行经典版ShareDrop。

经典ShareDrop介绍 ShareDrop是一款受苹果AirDrop启发的Web应用程序，允许设备之间直接传输文件，无需先上传至任何服务器。它采用WebRTC技术实现安全的点对点文件传输，并使用Firebase进行设备在线状态管理和WebRTC信令。

核心功能与特点

• 同网段快速传输：在同一局域网内（即拥有相同公网IP地址的设备），只需在所有设备上打开 https://www.sharedrop.io，即可自动发现彼此，无需配置。
• 跨网络传输：支持跨网络文件分享。用户可通过点击页面右上角的“+”按钮创建一个具有唯一URL的房间，并将该链接分享给目标接收方。接收方在浏览器中打开链接后，双方即可见。
• 与AirDrop的主要区别：ShareDrop需要互联网连接来发现设备，而AirDrop则无需互联网，通过创建临时无线网络实现。但ShareDrop的优势在于支持跨移动平台（Android和iOS）、桌面设备以及跨网络传输。

支持浏览器

• Chrome
• Edge (基于Chromium)
• Firefox
• Opera
• Safari 13+

本地开发设置

1. 配置Firebase：注册账号并创建数据库，在“安全规则”标签页加载 firebase_rules.json 文件，并记录数据库URL和密钥。
2. 安装工具：运行 npm install -g ember-cli 和 yarn。
3. 创建环境文件：复制 .env.sample 为 .env 文件，用于配置本地运行环境变量。其中 SECRET 密钥用于加密Cookie和基于公网IP生成房间名。
4. 启动应用：运行 yarn develop。

部署（以Heroku为例） 创建一个新的Heroku应用，并将代码推送至Heroku仓库。

网站管理员部署Anubis系统，旨在保护服务器免受AI公司大规模抓取网站的侵害，这种抓取行为常导致网站资源不可用。Anubis采用类似Hashcash的工作量证明方案，通过增加单个请求的计算负担，使大规模抓取变得成本高昂，从而减少其对网站资源的冲击。此方案作为临时解决方案，为开发更精细的指纹识别和识别无头浏览器技术争取时间，以避免向合法用户展示挑战页面。此外，Anubis依赖现代JavaScript功能，因此建议用户禁用如JShelter等可能干扰其运行的浏览器插件。

1JPM：单文件Java构建工具概述

1JPM（1 Java Project Manager）是一个创新的构建工具，作为Maven/Gradle的替代方案，其核心特点是将整个构建配置封装在一个Java文件（JPM.java）中。用户通过编辑这个Java文件来配置项目，而非使用XML或Groovy/DSL。

核心概念与基本使用

• 单文件集成：将JPM.java拖放到项目根目录，通过终端执行java JPM.java即可构建（要求Java 11及以上版本）。旧版Java（8-10）有特定执行命令。
• 配置即代码：构建配置以Java类（如ThisProject）形式定义在JPM.java中，设置groupId、artifactId、依赖项、编译参数等。
• Maven基础：1JPM本质上是Maven pom.xml的生成器，构建时会自动生成POM文件并利用Maven执行任务，兼顾了Maven的成熟生态与IDE兼容性。

主要功能与插件系统

• 多模块支持：通过JPM.portChildProjects()可自动将工具部署到子项目并生成初始POM。支持通过project.isAutoParentsAndChildren自动管理父子项目关系。
• 原生可执行文件：集成NativeImagePlugin，利用GraalVM将应用编译为原生镜像，提升性能。
• 原生安装包：通过PackagerPlugin可将应用打包为包含JRE的独立安装程序。
• 自定义逻辑：可在构建时执行自定义Java代码（如在应用中注入构建时间戳）。
• 插件扩展：支持第三方插件（以Java编写），可封装Maven插件或添加自定义功能，但插件开发当前受限于无法引入外部依赖。

优势与特点

• 代码简洁：相比Maven的XML配置，1JPM能显著减少构建配置的代码量。
• 直接访问：项目代码可直接导入JPM.java以访问构建信息（如版本号）。
• 自动更新：工具本身支持自我更新机制。
• 生成POM：可覆盖toXML()方法自定义生成的POM内容。

局限性

• 插件开发相对复杂，目前无法使用外部第三方库。
• 对于超复杂的构建需求，仍需依赖Maven及其插件生态。

1JPM旨在为熟悉Java的开发者提供一种更直观、类型安全的构建配置方式，特别适合偏好用代码管理构建过程的小型到中型项目。

需要更好的Goodreads替代品

文章讨论了追踪阅读的重要性，但作者强调更注重个人阅读管理而非社交压力。追踪阅读可以帮助建立习惯、反思阅读偏好，但阅读挑战和目标会带来压力。作者希望一个平台能管理书籍、追踪进度，并支持与读者和作者互动，同时促进本地独立书店。

Goodreads的衰落
被亚马逊收购后，Goodreads面临诸多问题：设计过时、功能有限、缺乏更新、负面评论泛滥、恶意行为频发，且对独立作者收费高昂。这些因素导致用户体验下降，促使人们寻求替代品。

替代品概述

• Literal和Oku：约2020/21年出现，提供现代设计和社交功能，但Literal在2022年后开发停滞，团队离职，活跃度下降；Oku也归于沉寂。
• Hardcover：专注于更好的推荐和统计，但应用存在bug，社交疲劳可能不适用。
• StoryGraph：提供详细阅读统计、AI个性化推荐、基于情绪的书籍发现、阅读挑战和社交功能，有公开发展路线图，被视为最全面的替代品之一。
• BookWyrm：基于联邦模式，允许加入小型社区，支持ActivityPub服务如Mastodon，注重隐私，开源且核心功能齐全。
• Papertrail：强调数字批注和社交讨论，但开发活跃度存疑，最后更新较久。
• PaperTrail：不同产品，提供私人书籍追踪和统计，无社交功能，设计现代且仍在更新。
• lit.salon：定位为“讨厌Goodreads的人的Goodreads”，强调社区、无阅读挑战和进度追踪，设计独特，注重自然互动。
• 个人应用：如Book Tracker和Sequel，用于私人书籍整理，无社交方面，功能丰富且设计精美。

挑战和结论
构建和维护Goodreads替代品面临可持续性挑战，如订阅疲劳和商业模式难题。作者目前使用个人追踪应用，并指出尽管有多个替代品出现，但需要找到平衡社交与个人需求的平台。文章建议读者尝试StoryGraph、BookWyrm等替代品，或Book Tracker等个人应用。

Incidental 开源事件管理平台介绍

Incidental 是一个处于早期开发阶段的开源事件管理平台，旨在简化组织的事件响应流程。它提供一个集中化的枢纽，用于高效地声明、管理和解决事件。用户可通过 GitHub issues 提供反馈以帮助改进项目，并可通过其托管版本进行体验。

核心功能

• ChatOps：可在 Slack 工作区内直接声明和管理事件。
• Web UI：提供易于使用的网页界面管理事件。
• 自定义能力：支持自定义严重等级、自定义字段、自定义事件类型和自定义角色，以匹配组织的特定需求。
• 状态页面：通过可定制的状态页面向相关方展示事件当前状态。
• 自定义工作流（即将推出）：将支持自动化事件响应流程。

快速启动指南（本地开发）

• 环境要求：需要安装 Docker、docker-compose、pnpm 和 Node.js v18。
• 设置步骤：
  1. 使用提供的清单模板在 Slack API 平台创建新的 Slack 应用，并替换其中的前后端基础 URL。
  2. 根据后端和前端目录下的 .env.example 文件创建并配置对应的 .env 环境变量文件。
  3. 在后端目录运行 pnpm install 和 pnpm run dev 启动后端服务（默认端口5000）。
  4. 在前端目录运行 pnpm install 和 pnpm run dev 启动前端服务（默认端口3000）。
  5. 访问 http://localhost:3000 创建新账户。

其他信息

• 资源：项目网站及联系邮箱（hello@incidental.dev）。
• 贡献：欢迎通过 Fork 仓库、创建特性分支、提交更改并发起 Pull Request 的方式参与贡献。
• 许可证：本项目采用 MIT 许可证。
• 截图：提供了包含仪表盘与 Slack 集成以及公共状态页面的界面截图。

大语言模型的推理能力：几何视角

本文从几何角度探索大语言模型（LLMs）的推理能力，旨在通过理解其几何特性来增强模型在实际应用中的表现。研究建立了LLMs表达能力与自注意力图密度之间的联系，表明自注意力图的密度定义了多层感知器（MLP）块输入的内蕴维度。通过理论分析和玩具示例，作者证明了更高的内蕴维度意味着LLMs具有更强的表达能力。进一步，论文提供了实证证据，将该几何框架与近期旨在提升LLMs推理能力的方法相关联，突出了几何视角在理解和优化模型推理性能中的潜力。

本文探讨了俄罗斯圣彼得堡无家可归者的生存现状与心理转变，指出“无家可归”不仅是失去物理住所，更是深刻的社会排斥与心理重塑，回归“正常生活”极其困难。

核心观点与生存困境

• 社会与制度排斥：流浪汉在医疗、法律和就业上面临系统性冷漠。医院常在流浪汉冻伤或感染未彻底治愈时便将其赶回街头；警察对非法侵占房产事件不作为；雇主对流浪汉抱有严重偏见，导致他们求职屡屡受挫。
• 心理转变与自我边缘化：长期街头生活会彻底改变一个人。许多流浪汉产生了自我厌恶，认为自己不配得到帮助；同时，频繁的受挫让他们陷入“习得性无助”，丧失了改变现状的动力。

典型人物案例

• Kirill Nikolayevich：退休老人因轻信骗子背上小额贷款，无力偿还被法院驱逐，流落街头，连泡面都需要志愿者帮忙烧水。
• Anna：前美术教师遭女婿侵害并被女儿抛弃。她靠便利店保安的接济和代签合同的兼职保洁维生。她认为最痛苦的不是没有房子，而是过去的生活彻底终结。在跌入谷底后，她反而感受到一种无需迎合他人的“自由”。
• Sasha：父亲去世后房产被他人霸占，流落街头11年，冬天睡在雪地里。因求职屡遭歧视，他陷入恶性循环，甚至放弃了补办丢失的护照，每天重复寻找食物的麻木生活。
• Denis与Larisa：Denis因老板卷款跑路背负债务，后被妻子赶出家门。他与妻子在街头搭建帐篷生活，认为摆脱了工作和社交规则后获得了真正的“自由”，已完全适应且不愿改变现状。

总结

无家可归者曾经都是“有家人”，但家庭变故、诈骗、疾病及社会系统的冷漠将他们推向街头。当物理上的“家”与社会关系双重丧失后，街头生活重塑了他们的认知。对许多流浪汉而言，流浪不仅是无奈的生存挣扎，更成为一种逃避社会期望、接受自我边缘化的最终归宿。真正的无家可归，是个人空间的丧失与社会排斥的结合。

扎克伯格与彼得·蒂尔关于Facebook、千禧代及2030年预测的内部邮件摘要

核心议题

邮件讨论聚焦于Facebook如何更好地定位自身以适应千禧代（1981-1996年出生的人群），并调整公司战略以应对代际权力转移的趋势。

彼得·蒂尔的关键观点

• Facebook的千禧代本质：Facebook由千禧代创立，是千禧代最成功的公司，其用户基础与品牌叙事与千禧代紧密相连。
• 扎克伯格的角色：扎克伯格被视为千禧代的“代言人”，但这种角色既不公平也不合适，因为他并非千禧代的典型代表。
• 建议的“千禧代倾斜”：
  • 扎克伯格应主动以千禧代发言人身份进行沟通，而非遵循婴儿潮一代的期望。
  • 具体建议包括：在演讲中更贴近年轻毕业生困境、调整慈善事业优先级、在董事会增加千禧代成员代表、增加对硅谷科技生态系统的投资。
• 代际权力转移预测：婴儿潮一代长期掌控社会关键机构（如大学、政府），这种“铁腕掌控”将在2020年代突然而激烈地结束，权力将移交给更年轻的一代。

马克·扎克伯格的回应与展望

• 2030年预测：到2030年，教育、医疗、住房等核心社会机构将由千禧代和Z世代主导运营，权力天平将向年轻一代倾斜。
• 公司策略调整：
  • 定位与沟通：承认Facebook是“千禧代公司”，传播重心应转向千禧代。他本人作为同代人中最知名者，其个人沟通方式也需调整。
  • 产品与政策重点：思考如何在住房、大学债务等具体议题上提供更针对年轻人的解决方案。例如，推行不依赖大学学位的招聘项目。
  • 投资与资本分配：暗示应减少股票回购（被认为更倾向婴儿潮一代股东），转而进行更符合千禧代价值观的战略投资。

尼克·克雷格的补充与挑战

• 现实阻力：指出大科技公司在千禧代中并不受欢迎（如调查显示70%美国千禧代倾向社会主义），且当前政策制定者仍多为婴儿潮一代。
• 执行建议：
  • 产品与营销：利用“倾听与被听见”广告活动及解决孤独感的长期项目来吸引千禧代。
  • 研究与领导：对千禧代的细分需求进行深入研究，并建议由千禧代员工主导相关工作。
  • 策略权衡：建议区分Facebook产品对千禧代的持续吸引力，与大公司在年轻群体中获取认可的难度。

后续行动

邮件显示团队已开始执行具体措施：

• 启动针对千禧代对Facebook及扎克伯格态度的研究。
• 扎克伯格的新年帖及后续沟通已体现“千禧代倾斜”导向。
• 计划由千禧代员工领导相关战略的后续推进。

附带背景：比尔·盖茨1995年备忘录

提及盖茨对互联网作为开放商业工具的早期预测，与主文讨论的代际技术适应主题形成时间上的呼应。

NanoKVM：经济实惠的多功能 Nano RISC-V IP-KVM

NanoKVM 是一系列紧凑、开源的 IP-KVM 设备，基于 LicheeRV Nano（RISC-V）平台构建。它允许用户远程访问和控制计算机，如同坐在其面前一样，适用于服务器、嵌入式系统和无头机器。

产品家族

• NanoKVM-Cube Lite：面向 DIY 用户和批量部署的裸板套件。
• NanoKVM-Cube Full：即用型套件，包含外壳、配件和预烧录的系统 SD 卡。
• NanoKVM-PCIe：采用 PCIe 插槽外形，可安装在机箱内部。从 PCIe 插槽供电，可选 Wi-Fi 和 PoE。
• NanoKVM-Pro：高性能版本，具有重大升级：
  • 分辨率：最高支持 4K@30fps / 2K@60fps。
  • 网络：从百兆以太网升级到千兆以太网 + PoE + Wi-Fi 6。
  • 延迟：硬件加速编码将延迟从 100-150ms 降低到 50-100ms。

核心技术规格对比

下表对比了 NanoKVM-Pro 与基础版 NanoKVM 的关键特性：

共同功能：两款设备均支持 UEFI/BIOS 访问、模拟 USB 键盘鼠标、ISO 仿真、IPMI、网络唤醒、Web 终端、串行终端、自定义脚本和 ATX 电源控制。

项目结构与开发

项目结构清晰，主要模块包括：

• kvmapp: 核心 KVM 应用程序更新包。
• web: 前端 UI（基于 React）。
• server: 后端服务（基于 Go）。
• support: 辅助模块（镜像子系统、状态、更新、OLED、HID 等）。

开发指南分为三部分：

1. 系统支持模块：参考 support/sg2002/README.md 构建底层硬件支持组件。
2. 后端服务：参考 server/README.md 设置和构建 Go 服务。
3. 前端 UI：参考 web/README.md 开发和构建 React 界面。

注意：后端编译和运行验证需要目标工具链或 NanoKVM 设备。系统镜像专为 NanoKVM 硬件构建，并非通用的 KVM 软件包。

硬件平台

NanoKVM（Cube/PCIe）基于 Sipeed LicheeRV Nano 构建，硬件组件包括：

• NanoKVM Lite: LicheeRV Nano + HDMI 转 CSI 板。
• NanoKVM Full: NanoKVM Lite + NanoKVM-A/B 板及外壳。
• HDMI 转 CSI 板: 转换 HDMI 输入信号。
• NanoKVM-A 板: 提供 OLED 显示、通过 USB-C 的 ATX 控制输出、辅助电源及物理电源/重置按钮。
• NanoKVM-B 板: 连接 NanoKVM-A 与主机 ATX 针脚以实现远程电源控制。

贡献与社区

项目欢迎贡献。流程为：Fork 仓库 -> 创建特性分支 -> 提交更改 -> 推送分支 -> 开启 Pull Request。高质量的贡献者可能会获得设备奖励。

• 购买渠道：AliExpress、淘宝等。
• 社区支持：Discord、QQ 群、电子邮件及常见问题解答。
• 许可证：GPL-3.0。