运营三十一年后，Salon 正式停止发布。该机构回顾了自己的历程，认为它从来不只是一个网站，更是在互联网萌芽时期对新闻业可能走向何方所进行的一次雄心勃勃的实验。 Salon 于 1995 年 11 月上线，力求形成独特的声音：把对世界的真切好奇与这样一种信念融为一体——数字平台能够在记者与受众之间建立新的、有意义的联系。

在三十多年的发展中，Salon 开辟出一块独特的空间，让政治、文化与批判性的思考在此交汇。该出版物聚焦于审视权力结构，追问根深蒂固的既定观念，并呈现那些往往没有进入主流视野的声音与故事。编辑团队并非只为追逐突发新闻而存在，而是希望解释日常生活表层之下正在变化的复杂力量。

该机构向多年来支撑这份出版物的无数个人致以由衷感谢，包括奠定其气质的创始人、员工与撰稿人。其工作的遗产被视为属于这一群创造者：正是他们的努力，为数字新闻奠定了基础，也将长期影响行业的发展。

团队也向读者送上最后的谢意。正是读者的积极参与、直面质疑的讨论与一贯的支持，使这个网站从单纯的数字出版物成长为真正的社区。读者愿意分享并展开辩论的态度，验证了该媒体的核心使命，也让编辑团队在长期工作中始终拥有清晰的目标。

最终，关闭的决定源自独立数字新闻业不断变化的商业现实。该出版物指出，在当下环境中，其现有商业模式已无法持续。团队虽承认这次停刊令人难过，但也强调他们最大的成就，是向世人展示数字叙事的潜力，并守住了一个让观点真正具有分量的空间。 After thirty-one years of operation, Salon is officially ceasing publication. The organization reflects on its journey, noting that it was never merely a website but rather an ambitious experiment in what journalism could become during the internet's infancy. Launching in November 1995, the outlet sought to establish a unique voice, blending a genuine curiosity about the world with the conviction that digital platforms could forge new, meaningful connections between reporters and their audiences.

Throughout its three-decade history, Salon carved out a distinct space where politics, culture, and critical inquiry intersected. The publication focused on examining power structures, questioning prevailing assumptions, and highlighting voices and stories that frequently escaped mainstream notice. Rather than simply reporting on breaking news, the editorial team aimed to make sense of the complex forces shifting beneath the surface of everyday life.

The organization expresses deep gratitude to the countless individuals who sustained the publication over the years, including the founders, staff, and contributors who shaped its character. The legacy of the work is described as belonging to this community of creators, whose efforts established a foundation for digital journalism that would influence the industry for years to come.

The team also extends a final thank you to their readers, whose active engagement, challenging discourse, and consistent support transformed the site from a digital publication into a true community. The readers' willingness to share and debate ideas helped validate the outlet's core mission, providing purpose to the editorial team's work over the long run.

Ultimately, the decision to close was driven by the changing business realities of independent digital journalism. The publication concludes that its existing business model is no longer sustainable in the current landscape. While acknowledging the sadness of this closure, the team emphasizes that their greatest achievement was demonstrating the potential of digital storytelling and maintaining a space where ideas truly mattered.

搭建 Hackintosh 的做法，即在非 Apple 硬件上运行 macOS，源远流长，最早可追溯到 20 世纪 80 年代末。大约十年前，早期的先驱者借助 KVM 和 PCI passthrough 技术，在 x86 主机系统上实现了接近原生的 macOS 性能。当时这可谓开天辟地，让爱好者能够绕过硬件限制，并充分发挥强大的 GPU 加速能力。

2021 年，Apple 转向基于 ARM 的 silicon 后，社区里不少人担心这会是"终点"。 M 系列芯片带来了明显的效率与功耗优势，但与此同时也意味着 x86 支持终将走向被弃用。随着近期 macOS 27 的发布，该系统已正式不再兼容 x86 架构，社区仿佛要就此淡出视野，把自定义 Apple 硬件的日子交给过去。

然而，出乎意料的是，事情并没有走向衰落。推动这次"复兴"的主要动力来自软件开发中 AI 的深度融入。通过使用诸如 Claude Code 和 OpenAI Codex 这类 AI 工具，爱好者们找到了新的路径来弥合"不兼容硬件"与"现代软件需求"之间的鸿沟。一次近期实验显示：用 ThinkPad 运行 macOS 26 并用于 iOS 开发的过程证明，AI 辅助编码能够在创纪录的时间内解决复杂的集成问题，等于把过去需要大量手工、费时费力的工作有效自动化。

AI 驱动的这种变化让社区焕发了新生机，并掀起了爆发式的开发热潮——甚至许多旁观者在五年前都难以想象。如今的项目不断突破过去看似不可能的边界，包括在 Snapdragon 笔记本上运行 macOS 27，甚至把操作系统移植到基于 ARM 的单板计算机上（例如 RK3588）。更令人意外的是，iOS 17 竟然还能在诸如 Nintendo Switch OLED 这类非传统硬件上运行。

在这些大胆移植之外，社区在硬件适配与"翻译"方面也取得了显著进展。开发者正在探索实现加速视频解码的办法，让非标准硬件具备原生 AirDrop 功能，甚至研究如何在 x86 平台上运行 macOS 27 的翻译版本。借助 AI 的强大能力，用户正在重新夺回对自身硬件的掌控力，也让"在定制系统上运行 macOS"这一愿景不仅仍然活着，甚至可以说比以往任何时候都更有实现可能。 The practice of building a Hackintosh, which involves running macOS on non-Apple hardware, has a rich history reaching back to the late 1980s. Nearly a decade ago, early pioneers utilized KVM and PCI passthrough technologies to achieve near-native performance for macOS on x86 host systems. At the time, this was a breakthrough that allowed enthusiasts to bypass hardware restrictions and leverage powerful GPU acceleration.

When Apple transitioned to ARM-based silicon in 2021, many in the community feared it marked the end of the road. The shift to M-series chips offered significant efficiency and power advantages, yet it also signaled that x86 support would eventually be deprecated. With the recent release of macOS 27, which officially dropped compatibility for x86 architectures, the community seemed poised to fade into obscurity, leaving the days of custom Apple hardware builds behind.

However, a surprising resurgence has occurred, driven primarily by the integration of AI in software development. By using AI tools like Claude Code and OpenAI Codex, enthusiasts have found new ways to bridge the gap between incompatible hardware and modern software requirements. A recent experiment using a ThinkPad to run macOS 26 for iOS development demonstrated that AI-assisted coding could resolve complex integration issues in record time, effectively automating tasks that once required manual, labor-intensive coding.

This AI-driven transformation has breathed new life into the community, sparking an explosion of development activity that most observers could not have predicted just five years ago. Modern projects are pushing boundaries that previously seemed impossible, including running macOS 27 on Snapdragon laptops and porting the operating system to ARM-based single-board computers like the RK3588. Even more unexpected is the capability to run iOS 17 on unconventional hardware such as the Nintendo Switch OLED.

Beyond these ambitious ports, the community is making significant strides in hardware support and translation. Developers are finding ways to enable accelerated video decoding, native AirDrop functionality on non-standard hardware, and even methods for running translated versions of macOS 27 on x86 platforms. By leveraging the sheer power of AI, users are regaining control over their hardware, proving that the dream of running macOS on customized systems is not only alive but arguably more capable than ever before.

Window Sweaters 是一款 macOS 菜单栏应用，旨在通过把桌面窗口包裹在可定制的针织边框里，营造舒适、个性化的观感。该应用以 Felix Kratz 的 JankyBorders 为基础衍生，借助 macOS 的私有窗口 API 来跟踪当前处于活动状态的窗口，并应用多种图案与配色方案，从而让计算环境更有触感、视觉上也更与众不同。

用户可以通过菜单栏里的 yarn 图标与应用互动，在其中调整图案类型、边框厚度和针脚大小等设置。它的一大亮点在于为常用应用内置了 37 种手工针织配色，例如 Safari 、 Slack 、 VS Code 和 Figma 。对于没有预设 sweater 的应用，软件会从图标中动态采样颜色来生成匹配的观感，确保即使是未被识别的程序，也能保持整体统一的风格。

应用提供两种主要模式：By App 会为特定程序应用专属、量身定制的 sweater；Zigzag 则会用从应用图标颜色提取出来的乳白色锯齿图案，呈现更统一、柔和的外观。若想进一步掌控细节，用户可以编辑本地配置文件来定义自定义配色规则，或替换自带的图片文件作为边框纹理。系统也很灵活，允许用户对单个应用或整个工作流程随时关闭该效果。

由于该项目依赖私有 API，开发者说明目前仍在开发中，因而存在一些固有限制，例如在调整窗口大小时边框可能会暂时消失。它兼容 macOS 13 及更高版本，并可在 Apple Silicon 与 Intel 设备上运行。尽管该应用目前尚未获得 Apple 的官方公证，但项目提供了清晰的手动安装与配置说明，并另有 Homebrew 方案以便更轻松地部署。

对于希望参与贡献或扩展项目的人，源代码以 GPL-3.0 许可证发布。仓库中包含本地编译所需的构建脚本，以及自动化测试工具。无论是通过调整配置文件，还是修改底层代码，用户都可以按自己的偏好定制体验，让 Window Sweaters 成为一个持续演进的桌面个性化工具。 Window Sweaters is a macOS menu-bar application designed to provide a cozy, personalized aesthetic by wrapping desktop windows in customizable knitted borders. Built as a derivative of Felix Kratz's JankyBorders, the app leverages private macOS window APIs to track active windows and apply various patterns and colorways, aiming to make the computing environment feel more tactile and visually distinct.

Users can interact with the app via a yarn icon in the menu bar, which allows them to adjust settings like pattern types, border thickness, and stitch size. A standout feature is the inclusion of 37 hand-knitted colorways for popular applications, such as Safari, Slack, VS Code, and Figma. For applications without a pre-defined sweater, the software dynamically samples icon colors to generate a matching aesthetic, ensuring that even unrecognized programs maintain a cohesive look.

The application offers two primary modes: By App, which applies unique, tailored sweaters to specific programs, and Zigzag, which provides a uniform, softer look by utilizing a cream-colored zigzag pattern derived from the app's icon colors. If a user wishes to exert more control, they can edit a local configuration file to define custom color rules or swap in their own image files to serve as border textures. The system is designed to be flexible, allowing users to toggle the effect off for individual apps or entire workflows.

As a project that relies on private APIs, the developer notes that it is currently a work in progress with some inherent limitations, such as borders temporarily disappearing during window resizing. It is compatible with macOS 13 and later, running on both Apple Silicon and Intel hardware. While the app is not yet officially notarized by Apple, the project provides clear instructions for manual installation and configuration, as well as a Homebrew option for easier deployment.

For those interested in contributing or extending the project, the source code is available under the GPL-3.0 license. The repository includes build scripts for local compilation and automated testing tools. Whether through adjusting the configuration files or modifying the underlying code, users are encouraged to customize their experience, making Window Sweaters an evolving tool for desktop personalization.

motorola signature 27 作为该公司最先进的旗舰智能手机问世，融合了高端设计与尖端性能。它以一套被 DXOMARK 认可为 2026 年发布的世界最佳摄像头系统脱颖而出，提供如采用 LOFIC 技术的 50MP Sony LYTIA 主传感器，以及支持 100x Super Zoom 的 200MP 潜望式长焦摄像头等功能。此外，这款设备还配备了 EVS 动作传感器，专门用于对快速移动的主体进行精准捕捉。

视觉体验是该设备的重点之一，搭载 Extreme AMOLED Duo 双串联显示屏，峰值亮度可达 12,000 nits，使其成为目前智能手机中亮度最高的屏幕。该显示技术不仅提升了户外场景下的清晰度，还在能效方面较前几代提高了 34% 。设备由 Snapdragon 8 Elite Extreme Gen 6 平台驱动，并由大面积 ArcticMesh 系统散热，确保在游戏或 AI 处理等高负载任务中保持稳定性能。

人工智能以 Gemini Intelligence 深度融入日常使用。设备支持多项进阶能力，包括多步任务自动化、 Rambler 工具用于将自然语音精炼成书面文本，以及生成个性化主屏幕小部件的功能。此外，它还是首款集成 Motorola Qira 的手机，这是一套旨在统一 Motorola 与 Lenovo 更广泛生态体验的 AI 系统，同时也支持通过前置摄像头进行实时 American Sign Language 翻译等定制化功能。

音频表现同样出色，motorola signature 27 也是市面上唯一配备 Audio by Bang & Olufsen 的智能手机。此次合作带来了定制调校的扬声器架构，以及为维持音频保真而设计的专属音效模式。硬件采用耐用框架承载，使用陶瓷与玻璃结构，符合军用级 MIL-STD-810H 标准，并具备 IP68 与 IP69 防尘防水等级。

续航与安全方面也同样到位。设备内置 7000mAh 电池，支持 90W 有线充电和 50W 无线充电，电量补充速度非常高效，最快可在不到 15 分钟内完成显著补电。更值得高强度用户关注的是，motorola signature 27 是首款支持 GrapheneOS 的 Motorola 设备，这是一款以隐私为核心的开源操作系统。通过将高端硬件与七年 OS 及安全更新承诺相结合，公司希望为既追求创新又重视数据完整性的用户提供可靠、长期的解决方案。 The motorola signature 27 arrives as the company's most advanced flagship smartphone, blending high-end design with cutting-edge performance. It distinguishes itself with a camera system recognized by DXOMARK as the world's best launched in 2026, offering features like a 50MP Sony LYTIA main sensor with LOFIC technology and a 200MP periscope telephoto camera capable of 100x Super Zoom. Additionally, the device introduces an EVS action sensor specifically designed to capture fast-moving subjects with precision.

Visuals are a primary focus, supported by an Extreme AMOLED Duo tandem display that reaches a peak brightness of 12,000 nits, making it the brightest screen currently available in a smartphone. This display technology not only improves clarity in outdoor settings but also enhances energy efficiency by 34% compared to previous generations. The device is powered by the Snapdragon 8 Elite Extreme Gen 6 platform, cooled by a large-surface ArcticMesh system to ensure consistent performance during intensive tasks like gaming or AI processing.

Artificial intelligence is deeply integrated into the user experience through Gemini Intelligence. The device supports advanced capabilities, including multi-step task automation, the Rambler tool for refining natural speech into written text, and the ability to generate personalized home screen widgets. Furthermore, the phone is the first to include Motorola Qira, an AI system meant to unify experiences across the broader Motorola and Lenovo ecosystem, while also supporting specialized features like real-time American Sign Language translation via the front camera.

Audio performance is another key differentiator, as the motorola signature 27 is the only smartphone on the market to feature Audio by Bang & Olufsen. This partnership includes custom-tuned speaker architecture and specialized sound modes designed to maintain audio fidelity. The hardware is housed in a durable frame, featuring a ceramic and glass construction that meets military-grade MIL-STD-810H standards and holds IP68 and IP69 ratings for dust and water resistance.

Battery life and security round out the device's premium offerings. It houses a 7000mAh battery that supports 90W wired and 50W wireless charging, allowing for significant power replenishment in under fifteen minutes. Perhaps most notably for power users, the motorola signature 27 is the first Motorola device to support GrapheneOS, a privacy-focused, open-source operating system. By combining high-end hardware with a seven-year commitment to OS and security updates, the company aims to provide a reliable, long-term solution for those seeking both innovation and data integrity.

Alpine Linux 发布了一项关于密码身份验证绕过漏洞的关键安全公告。该漏洞影响运行 openssh-server 软件包的系统：攻击者只要能访问 SSH 端口网络，即可在满足特定条件时在不知晓密码的情况下登录到目标账号。具体来说，该漏洞要求目标账号的密码字段被设置为星号（这在仅限密钥的账号中很常见），并且机器上至少还存在一个其他账号，该账号使用 SHA-256 或 SHA-512 密码哈希进行保护。当攻击者发送经过特殊构造的长密码时，身份验证流程会错误地校验连接，从而触发绕过。

如果系统运行的是未启用 PAM 支持编译的标准 openssh-server 软件包，或使用 openssh-server-pam 且禁用了 UsePAM 配置选项，则该系统被视为受影响。此外，只要启用了 PasswordAuthentication（OpenSSH 的默认设置），就存在风险。对于那些保留无密码账号的用户而言尤其危险，例如某些配置下的 root 用户、创建时未设置密码的仅限密钥用户，或通过目录服务管理的账号。 3.18.11 到 3.24.3 之间发布的官方 tiny-cloud 镜像也被列为潜在目标。

问题的技术根源在于：在没有 PAM 的情况下，系统处理密码哈希的方式不正确。当账号没有密码时，系统会尝试把登录尝试与空字段进行比较。由于用于密码哈希的 C 库函数存在行为差异，超过特定长度的输入会触发错误，并返回一个与无密码账号使用的占位符相匹配的字符串，进而导致身份验证绕过成功。 OpenSSH 项目已在 10.6p2 版本中修复该问题，Alpine Linux 也已将必要补丁反向移植到所有受支持版本，并修补了追溯到 3.16 的更旧、不再维护的版本。

为修复该漏洞，管理员应立即通过软件包管理器更新系统，并重启 sshd 服务，确保更新后的守护进程生效。若暂时无法立刻更新，最有效的缓解措施是彻底禁用密码身份验证：在 sshd 配置中将 PasswordAuthentication 设置为 no，然后重启服务。同时建议用户检查系统日志，寻找任何未经授权登录的迹象，重点关注本应仅支持密钥登录的账号是否出现了"密码验证通过 / 接受"的记录。

此外，负责管理云实例或容器化环境的用户需要特别注意自身配置。只要容器不运行 sshd 就相对安全；但对于尚未更新的云镜像，只要其中存在带哈希密码的账号，就应将其视为可能已受影响，因为这为攻击者利用该绕过提供了必要条件。通过应用补丁并核对配置项，用户可以有效关闭这一安全缺口，防止基础设施遭受潜在的未经授权访问。 Alpine Linux has issued a critical security advisory regarding a password authentication bypass vulnerability affecting systems running the openssh-server package. This flaw allows an attacker with network access to the SSH port to log into an account without knowing the password, provided certain conditions are met. Specifically, the vulnerability requires the target account to have its password field set to an asterisk, which is typical for key-only accounts, and necessitates that the machine contains at least one other account protected by a SHA-256 or SHA-512 password hash. When a specially crafted, long password is sent by the attacker, the authentication process incorrectly validates the connection.

Systems are considered affected if they run the standard openssh-server package, which is compiled without PAM support, or if they use openssh-server-pam with the UsePAM configuration option disabled. Furthermore, the risk applies if PasswordAuthentication is enabled, which is the default setting for OpenSSH. Users are particularly vulnerable if they maintain accounts with no password, such as the root user in certain configurations, key-only users created without passwords, or accounts managed through directory services. Official tiny-cloud images released between versions 3.18.11 and 3.24.3 are also flagged as potential targets.

The technical root of the issue lies in how the system handles password hashing when PAM is absent. When an account lacks a password, the system attempts to compare the login attempt against a null field. Due to a behavioral quirk in the C library function used for password hashing, input exceeding a specific length causes an error that returns a string matching the placeholder used for passwordless accounts. This leads to a successful authentication bypass. The OpenSSH project has addressed this in version 10.6p2, and Alpine Linux has backported the necessary patches to all supported releases, as well as older, end-of-life versions dating back to 3.16.

To remediate this vulnerability, administrators should immediately update their systems using the package manager and restart the sshd service to ensure the updated daemon takes effect. For environments where an immediate update is not feasible, the most effective mitigation is to disable password authentication entirely by setting PasswordAuthentication no in the sshd configuration and restarting the service. Users are also advised to check their system logs for any signs of unauthorized logins, specifically looking for accepted password attempts on accounts that are intended to be key-only.

Finally, those managing cloud instances or containerized environments should take note of their specific configurations. While containers that do not run sshd remain safe, cloud images that are not yet updated should be treated as potentially compromised if they contain any account with a hashed password, as this provides the necessary prerequisite for an attacker to exploit the bypass. By applying the patches and verifying configuration settings, users can effectively close this security hole and protect their infrastructure from potential unauthorized access.

模型上下文协议（Model Context Protocol，简称 MCP）是一项开放标准，旨在将 AI 应用连接到它们所需的各类工具和数据源。其核心架构包含一个宿主（host），例如 AI 智能体或开发环境，以及一个 MCP 服务器（MCP server）。服务器是一个小程序，用于暴露特定的能力（capabilities）、数据（data）或提示（prompts）。模型本身处于关键位置，它负责决定何时调用这些外部工具，但重要的是：模型从不直接与服务器通信。

这种交互机制以 JSON-RPC 作为底层消息格式，不过 MCP 进一步通过定义具体方法、能力协商以及传输机制来提供更完整的结构。与标准的 REST API 不同，MCP 支持双向通信，使服务器可以反向与宿主进行交互。该协议还会管理这些连接的完整生命周期，包括初始化、持续运行以及关闭；同时集成了诸如用于远程服务器访问的 OAuth 2.1 等安全特性。

从功能上看，该协议为服务器端和客户端划分了不同的功能集。服务器端提供模型可调用的工具（tools）、应用可读取的资源（resources），以及用户可选择的模板（prompts）。与此同时，客户端或宿主端提供诸如采样（sampling）之类的能力：它允许服务器借用模型；还包括用于请求用户输入的引导（elicitation），以及定义服务器允许运行的根目录（root directories）。诸如进度跟踪（progress tracking）和日志记录（logging）之类的工具，确保这些自动化任务保持透明且易于管理。

工作流程按固定步骤展开：AI 应用首先向服务器查询，以发现其可用的工具。随后，这些信息会被传递给模型，使其理解自己可以触发哪些函数。当用户提出请求时，模型会判断需要调用哪一个工具，生成所需的参数（arguments），并指示应用通过服务器执行该工具。服务器完成处理后，将结果返回给模型，模型再整合信息，生成并输出给用户的最终答复。

尽管该协议提供了连接所需的基础框架，但诸如智能工具检索或更复杂的代码生成模式等高级能力仍不在规范范围内，而是由具体实现来完成。此外，MCP 的开发也非常重视安全性，充分认识到工具投毒（tool poisoning）、注入（injection）或钓鱼（phishing）等潜在风险。协议的持续更新不断扩展其能力，未来的迭代将致力于引入更强的扩展，用于提升智能体能力（agent skills）、改进交互式用户界面，以及优化任务管理。 The Model Context Protocol, or MCP, serves as an open standard designed to connect AI applications to the diverse tools and data sources they require. At its core, the architecture involves a host, such as an AI agent or a development environment, and an MCP server, which acts as a small program that exposes specific capabilities, data, or prompts. The model itself occupies a central role by deciding when to utilize these external tools, but importantly, it never communicates with the server directly.

The mechanics of this interaction rely on JSON-RPC as the underlying message format, though MCP adds significantly more structure by defining the specific methods, capability negotiations, and transport mechanisms. Unlike a standard REST API, MCP facilitates bidirectional communication, allowing servers to interact back with the host. The protocol manages the entire lifecycle of these connections, including initialization, ongoing operation, and shutdown, while also incorporating security features like OAuth 2.1 for remote server access.

Functionally, the protocol is divided into distinct feature sets for both servers and clients. Servers provide tools that the model can call, resources that the application can read, and templates known as prompts that users can select. Meanwhile, the client or host features include capabilities like sampling, which allows a server to borrow a model, elicitation for requesting user input, and the definition of root directories where a server is permitted to operate. Utilities such as progress tracking and logging ensure that these automated tasks remain transparent and manageable.

The workflow follows a structured sequence where the AI application first queries the server to discover its available tools. This information is passed to the model, allowing it to understand what functions it can trigger. When a user provides a request, the model determines the necessary tool, generates the required arguments, and instructs the application to execute that tool via the server. Once the server processes the task, the result is fed back to the model, which then synthesizes a final response for the user.

While the protocol provides the fundamental framework for these connections, certain advanced features like intelligent tool searching or sophisticated code generation modes remain outside the spec, functioning instead as implementation details. Furthermore, the development of MCP includes a focus on security, acknowledging potential risks like tool poisoning, injection, or phishing. Ongoing updates continue to expand the protocol, with future iterations aiming to introduce even more robust extensions for agent skills, interactive user interfaces, and improved task management.

尽管普遍说法认为科技公司通过侵入式的数据收集，对我们的个人生活了如指掌，但对许多用户来说，现实却出乎意料地脱节。尽管监控与机器学习的规模庞大，最终的结果往往却很平淡，甚至毫无意义。大多数算法并不会以惊人的精准度预判需求，而只是反复推送用户已经买过的商品，或是把与用户真实生活方式完全无关的产品硬塞过来。

这些系统的一个关键问题在于，它们根本抓不住基本的行为规律。比如音乐流媒体平台往往会无视长期偏好：明明一贯会跳过有人声的曲目，却仍偏向于偏好纯器乐的 techno 。搜索引擎和内容平台也常常把用户那种特定的、一次性的提问误当成持续存在的兴趣。当用户搜索某台特定电器的安装指南时，算法却会默认他突然对"烤箱"这个类别产生了普遍的执念，而不是识别出这不过是一个有针对性的、单次的实用需求。

语言和地区设置也暴露了个性化技术的巨大缺口。即便账号、浏览器和操作系统都被明确设置为英语，用户依然常常只因为自己的物理位置，就被推送当地语言的内容；而且这种情况即使在用户登录了会保存语言偏好的全球账号时也不会改变。无论是游戏商店界面被重置成 Finnish，还是银行应用推送无关的签证信息却完全忽略护照数据，整体数字体验都显得支离破碎，让人沮丧，同时也对用户已记录的身份缺乏基本的理解。

广告投放体验同样粗糙笨拙。用户经常被推送他们从不会购买的高价值商品，比如工业设备或营销软件，这类推荐往往只来自一次不小心点错的行为。于是就形成了恶性循环：一次错误的互动会让系统把用户归错类别，之后便无限期地沿着错误方向继续推送。此外，平台还会继续宣传与用户毫不相干的"家庭场景"或"金融需求"相关的产品，进一步证明那些被采集的大量个人数据，往往并没有真正用到有效的地方。

最终，这份挫败感来自一种反差：数据追踪的深度很惊人，但由此带来的用户体验却相当浅薄。被持续监视的感觉一直存在，可把这些数据真正用聪明的方式转化成帮助的能力却明显不足。既然公司已经在进行如此广泛的追踪，却依然做不到提供更相关的内容或记住简单的用户设置，这确实令人失望，也让"高度个性化"的技术承诺在很大程度上落了空。 While the common narrative suggests that tech companies possess an omniscient understanding of our personal lives through intrusive data collection, the reality for many users is surprisingly disconnected. Despite the massive scale of surveillance and machine learning, the actual output is often mundane or nonsensical. Rather than anticipating needs with uncanny accuracy, most algorithms merely repeat advertisements for items already purchased or push products that are completely irrelevant to the user's actual lifestyle.

A primary failure in these systems is their inability to grasp basic behavioral patterns. For instance, music streaming services consistently ignore long-standing preferences, such as the systematic skipping of vocal tracks in favor of instrumental techno. Similarly, search engines and content platforms frequently misinterpret specific, one-time inquiries as broad, ongoing interests. When a user searches for an installation guide for a specific appliance, the algorithm assumes a sudden obsession with ovens in general, rather than recognizing a practical, singular task.

Language and location settings also highlight a major gap in personalization technology. Despite having accounts, browsers, and operating systems explicitly set to English, users are frequently bombarded with content in local languages based solely on their physical location. This persists even when the user is logged into global accounts that store these language preferences. Whether it is a gaming store resetting to Finnish or a banking app sending irrelevant visa information that ignores passport data, the digital experience is often disjointed and frustratingly unaware of the user's documented identity.

The advertising experience remains particularly clumsy and unrefined. Users are frequently targeted with high-value items they would never purchase, such as industrial equipment or marketing software, often based on a single accidental click. This creates a feedback loop where an errant interaction forces the system to miscategorize the user indefinitely. Furthermore, services continue to promote products for family situations or financial needs that the user does not have, proving that the vast archives of personal data being collected are rarely put to effective use.

Ultimately, the frustration lies in the discrepancy between the depth of data tracking and the shallowness of the resulting user experience. The sense of being monitored is constant, yet the lack of genuine intelligence in how that data is applied is glaring. If companies are already engaged in such extensive tracking, it is disappointing that they cannot perform the basic functions of providing relevant content or remembering simple user settings, leaving the promise of hyper-personalized technology largely unfulfilled.

Discord 正在逐步告别 Electron，这是一款广泛使用的跨平台框架，允许开发者用 Web 技术构建桌面应用。尽管 Electron 曾是开发者的热门选择，但它经常因资源占用过高而遭到批评——在正常使用时也往往会消耗大量内存。 Discord 希望通过把桌面应用彻底迁移到 Rust 来缓解这些性能问题。 Rust 是一种现代编程语言，以高效和内存安全著称。

据 Discord 首席技术官 Stanislav Vishnevskiy 介绍，公司自 2018 年起就开始在基础设施和语音技术中引入 Rust 。让客户端完全基于 Rust 一直是开发团队的长期目标。此次迁移也意味着不再使用 React Native，不过 Discord 仍计划为移动端保留原生界面，并通过 Rust 与桌面端共享核心应用代码。

从内部测试结果来看，这一转变的优势已经开始显现。 Vishnevskiy 展示的预览表明，Discord 的 Windows 客户端运行时的内存占用约为 290MB 。考虑到目前基于 Electron 的 Windows 应用会根据用户同时参与的服务器数量轻松突破 1GB 内存，这无疑是显著的效率提升。

虽然尚未确认全面迁移到 Rust 的具体完成时间，但公司计划在不久的将来就启动与用户相关的测试。这样的战略调整体现了公司在优化平台性能、缩小系统占用方面的更大决心，最终将让依赖该应用进行日常沟通的用户获得更顺畅的体验。 Discord is moving away from Electron, the widely used cross-platform framework that allows developers to build desktop applications using web technologies. While Electron has been a popular choice for developers, it is frequently criticized for being resource-heavy, often consuming significant amounts of memory even during standard usage. Discord aims to address these performance concerns by transitioning its desktop application entirely to Rust, a modern programming language known for its speed and memory safety.

According to Discord chief technology officer Stanislav Vishnevskiy, the company has been integrating Rust into its infrastructure and voice technology since 2018. Achieving a fully Rust-based client represents a long-standing goal for the development team. This transition also involves moving away from React Native, though Discord intends to maintain native user interfaces for its mobile apps while sharing core application code with the desktop version via Rust.

The benefits of this shift are already apparent in internal testing. Vishnevskiy shared a preview showing the Discord Windows client operating on approximately 290MB of RAM. This represents a substantial efficiency gain, as the current Electron-based Windows app can easily exceed 1GB of memory usage depending on the number of servers a user is actively participating in.

While there is no confirmed timeline for when the full migration to Rust will be completed, the company plans to initiate testing with users in the near future. This strategic shift reflects a broader commitment to optimizing the platform's performance and reducing its system footprint, ultimately providing a smoother experience for users who rely on the application for daily communication.

现代企业互联网环境对数字保存越来越不友好，导致我们珍视的内容面临在毫无预警的情况下突然消失的风险。如果你查看旧的 YouTube 播放列表，通常会发现很多视频已经无法播放，这也说明在没有个人归档的情况下，数字内容并不真正属于用户。要确保还能随时观看喜欢的内容，必须把这些文件下载下来，并本地保存到个人硬盘或网络附加存储（NAS）中。

对于想要直接上手的人来说，像 yt-dlp 以及其各种更易用的封装工具都非常有效。这些工具会在合理的默认设置下完成大部分下载需求，让用户把视频保存到结构清晰的文件夹里。虽然不少用户会觉得基础命令行工具有些让人望而生畏，但网上资料非常丰富，使流程变得更容易掌握，从而提供一种可靠的方式来维护永久的数字媒体库。

不过，也有一些用户有更具体的需求，比如把 YouTube 内容整合进现有的媒体服务器环境，例如 Jellyfin 。要搭建一个真正可用的库，需要解决元数据管理和播放列表结构等问题，因为传统媒体服务器通常是为常规电影和电视节目设计的。借助像 ytdl-sub 这样的专用自动化工具，你可以把数百个视频按不同播放列表进行整理，让观看体验呈现出类似专业媒体库的结构化效果。

维护这种系统往往需要在复杂度和实际效用之间做权衡。比如，使用像 Tdarr 这样的工具把视频文件重新编码为更高效的编解码器（如 HEVC/H.265），通常能显著减少存储占用，但同时也会带来在界面设计和软件稳定性方面的技术挑战。自动重编码确实能节省数百 GB 的空间，但你需要有心理准备去应对可能让人烦躁的软件环境，并排查诸如元数据或缩略图同步之类的问题。

归根结底，建立个人存档的目的在于确保你喜欢的内容始终掌握在自己手里，不受企业平台政策变化的摆布。无论是用一个简单的下载文件夹，还是搭建更复杂的自托管 Homelab，主动为自己的数字足迹提供保障，都是一项至关重要的实践。尽管搭建过程可能永远无法做到完全精致，但你投入的时间会让你在互联网环境不断变化的情况下，仍能继续访问自己钟爱的媒体。 The modern corporate internet environment is increasingly hostile toward digital preservation, leaving the content we value at risk of disappearing without warning. If you check your old YouTube playlists, you will likely find that many videos are already unavailable, demonstrating that digital goods do not truly belong to the user unless they are personally archived. To ensure access to favorite content, it is essential to download and store these files locally on a personal hard drive or network-attached storage.

For those looking for a straightforward approach, tools like yt-dlp, or its various user-friendly wrappers, are highly effective. These utilities handle most download requirements with sensible defaults, allowing users to save videos into organized folders. While many users may find basic command-line tools daunting, the wealth of online documentation makes the process accessible, providing a reliable way to maintain a permanent collection of digital media.

Some users, however, may have more specific needs, such as integrating YouTube content into existing media server setups like Jellyfin. Creating a functional library requires overcoming challenges like metadata management and playlist structure, as traditional media servers are typically designed for conventional film and television. By using specialized automation tools like ytdl-sub, it is possible to organize hundreds of videos across various playlists, allowing for a structured viewing experience that mimics professional media libraries.

Maintaining such a system often involves a trade-off between complexity and utility. For instance, using tools like Tdarr to re-encode video files into more efficient codecs, such as HEVC/H.265, can significantly reduce storage requirements, though it introduces technical hurdles regarding interface design and software stability. While automated re-encoding can save hundreds of gigabytes, it requires a willingness to navigate potentially frustrating software environments and troubleshoot issues like metadata or thumbnail synchronization.

Ultimately, the goal of building a personal archive is to ensure that the content you love remains under your control, free from the whims of corporate platform policies. Whether through a simple download folder or a complex self-hosted homelab, taking the initiative to secure your digital footprint is a vital practice. While the setup process may never be perfectly polished, the effort invested guarantees that your favorite media remains accessible regardless of how the internet landscape changes.

在基于 musl 的 Linux 发行版（如 Alpine 、 OpenWrt 和 Yocto）中，OpenSSH 长期存在一个安全漏洞。该漏洞源于 libc 处理身份验证错误的方式，与 OpenSSH 为缓解计时攻击所采取的措施之间的相互作用。十多年来，配置为使用单个星号作为密码占位符的账户（这是希望仅依赖 SSH keys 的用户常见做法）无意中接受了任何超过 256 个字符的密码。该缺陷使攻击者能够绕过安全防护，获取那些本应明确禁止基于密码登录的账户的未授权访问。

该问题可追溯到 2012 年。当时 musl 库修改其 crypt 函数以避免系统崩溃。从历史来看，如果身份验证函数无法计算哈希值，它会返回一个 NULL 指针，许多程序因为未检查这一情况而会崩溃。 musl 通过改为返回一个字面星号字符来修复这一点：它假设由于不存在任何有效哈希能与字面星号匹配，结果会被当作密码验证失败。然而，这一修复与同时引入的 256 字节密码长度限制发生了重叠，用于防止拒绝服务攻击。当密码长度超过限制时，musl 的 crypt 函数会失败并返回同样的星号。

更复杂的是，OpenSSH 在 2016 年引入了一套用于防止计时攻击的缓解策略。当用户尝试登录一个不存在的账户时，OpenSSH 通常会立即拒绝登录。为防止攻击者根据响应时间推断有效用户名，OpenSSH 开始从系统中存在的账户里随机挑选一个有效 salt，以执行"伪哈希"计算。这样可以确保服务器在拒绝有效用户和无效用户时耗时一致。结果，OpenSSH 反而不经意间提供了触发 musl 漏洞所需的关键条件。

当用户试图针对一个密码域为星号的账户进行身份验证时，OpenSSH 会判断需要执行用于隐藏计时的哈希计算。它会从系统中另一个账户取得有效 salt，并对用户输入的内容进行哈希处理。如果输入长度超过 256 字节，musl 的 crypt 函数就会返回星号。由于被访问账户的密码字段同样是星号，比较结果会被判定为匹配。于是，任何长度超过 256 个字符的密码都能充当锁定账户的"通用密钥"，包括许多默认的 Alpine Linux 云映像中的 root 用户。

由于大多数标准 Linux 发行版依赖 glibc 和 PAM，它们在处理这类身份验证流程时方式不同，且不会受到相同的交互影响，因此该漏洞基本被忽视了十年。该问题主要影响那些在没有 PAM 的情况下使用 musl 的系统——这种配置在轻量级容器和云环境中很常见。建议用户立即升级到 OpenSSH 10.6p2，或在配置文件中将 PasswordAuthentication 设置为 no 以降低风险。同时建议检查日志中是否出现异常的长字符串密码输入尝试，以判断系统是否已经被入侵。 A long-standing security vulnerability has existed within OpenSSH on musl-based Linux distributions, such as Alpine, OpenWrt, and Yocto, stemming from an interplay between how libc handles authentication errors and how OpenSSH mitigates timing attacks. For over a decade, accounts configured with a single asterisk as a password placeholder—a common setting for users intended to rely solely on SSH keys—have inadvertently accepted any password exceeding 256 characters. This flaw allows attackers to bypass security measures and gain unauthorized access to accounts that were explicitly intended to prohibit password-based logins.

The origins of this issue date back to 2012, when the musl library modified its crypt function to prevent system crashes. Historically, if an authentication function could not compute a hash, it would return a NULL pointer, causing many programs to crash because they failed to check for this condition. Musl addressed this by returning a literal asterisk character instead, assuming that since no valid hash could ever match a literal asterisk, the result would be interpreted as a failed password. However, this fix coincided with the introduction of a 256-byte limit on password lengths to protect against denial-of-service attacks. When a password exceeds this length, musl's crypt function fails and returns that same asterisk.

Compounding this is an OpenSSH mitigation strategy implemented in 2016 designed to prevent timing attacks. When a user attempts to log into a non-existent account, OpenSSH typically rejects the login immediately. To prevent attackers from guessing valid usernames based on response times, OpenSSH began picking a random valid salt from an existing account to perform a fake hash calculation. This ensures that the server takes the same amount of time to reject both valid and invalid users. By doing so, OpenSSH unintentionally provided the necessary ingredients to trigger the musl vulnerability.

When a user attempts to authenticate against an account locked with an asterisk, OpenSSH identifies that it needs to perform a timing-hiding hash. It grabs a valid salt from another account on the system and hashes the user's provided input. If that input is longer than 256 bytes, the musl crypt function returns an asterisk. Since the account being accessed also contains an asterisk as its password field, the comparison results in a match. This effectively allows any password longer than 256 characters to act as a universal key for locked accounts, including the root user in many default Alpine Linux cloud images.

This vulnerability largely went unnoticed for ten years because most standard Linux distributions rely on glibc and PAM, which handle these authentication flows differently and do not suffer from the same interaction. The issue specifically targets systems that use musl without PAM, a configuration common in lightweight containers and cloud environments. Users are advised to immediately update to OpenSSH 10.6p2 or set PasswordAuthentication to no in their configuration files to mitigate the risk. Checking logs for unusual, long strings in password entry attempts is recommended to determine if a system has already been compromised.