在美国，可以根据所在地免费注册地区性域名，例如 `somename.city.state.us` 。这些域名自 1992 年起存在，并由政府合同维护。要注册，你必须是美国公民或永久居民、在美国注册的组织，或在美国有实际存在的实体。整个流程有若干步骤，首先要选定想要的地区域名。

许多地区性域名已被委托给具体公司负责注册。虽然有一份 2009 年的注册商联系方式列表，但其中一些公司后来可能更名或重组。如果你的地区不在该列表上，你可能可以在 `gen.your-state.us` 下注册，适用于一般独立实体。但如果某个地区根本未被委托，你大概率无法注册，因为未被委托域名的管理者 NeuStar 基于长期政府政策，只允许地方政府机构注册这类域名。

在注册前需要设置名称服务器，这一点比较特别，因为大多数域名注册商会自动提供名称服务器。 Amazon Lightsail 为非顶级域名提供免费的名称服务器。你只需创建一个 AWS 账户，进入 Lightsail 控制台，为目标域名建立一个 DNS 区域，就能获得注册表单所需的名称服务器地址。

注册使用的表单名为 Interim .US Domain Template v2.0，需要填写完整域名、个人或组织信息、预期用途说明以及名称服务器信息。名称服务器的 IP 地址可用在线 DNS 查询工具或 dig 命令获取。表单中还包含 US Nexus 要求，用以验证你的资格（如公民或居住身份等）。

填好表单后，将其通过电子邮件发给对应地区域名的注册商。处理并非自动化，可能需要数天到数周时间。一旦获批，你会收到确认，然后可以回到 Lightsail 配置 DNS 记录，把域名指向你想要的服务器，无论是网站托管、游戏服务器还是其他用途。作者使用 GitHub Pages 做免费网站托管，但任何托管服务在正确配置 DNS 后都可用。

FAQ 部分回答了关于地区性域名的常见问题：你不一定要居住在域名所代表的地区；WHOIS 查询不会泄露你的个人地址，通常只显示注册商信息。文章最后感谢了那些帮助作者完成这一流程的指南，也正是它们促使作者写出这篇更详细的说明，供有兴趣注册地区性域名的人参考。 In the United States, it's possible to register a free domain name based on your location, such as `somename.city.state.us`. These locality domains have existed since 1992 and are maintained under government contract. To register one, you need to be a US citizen or permanent resident, a US-incorporated organization, or an entity with a bona fide presence in the US. The process involves several steps, starting with choosing your desired locality domain.

Many locality domains have been delegated to specific companies that handle registration. A list from 2009 provides contact information for these registrars, though some companies may have changed names or restructured since then. If your locality isn't on the list, you might be able to register under `gen.your-state.us` for general independent entities. However, if registration hasn't been delegated at all, you're likely out of luck, as NeuStar, the manager of undelegated domains, only allows local government agencies to register them due to longstanding government policy.

Before registering, you need to set up nameservers, which is unusual since most domain registrars provide these automatically. Amazon Lightsail offers free nameservers for non-top-level domains. You create an AWS account, navigate to the Lightsail console, and set up a DNS zone for your intended domain. This gives you the nameserver addresses required for the registration form.

The registration form, called the Interim .US Domain Template v2.0, requires several pieces of information. You'll provide your full domain name, personal or organizational details, a description of your intended use, and your nameserver information. For the nameserver IP addresses, you can use online DNS lookup tools or the `dig` command. The form also includes US Nexus requirements to verify your eligibility based on citizenship or residency status.

After completing the form, you send it to the registrar for your locality domain via email. Processing can take days or weeks since it's not automated. Once approved, you'll receive confirmation and can return to Lightsail to configure your DNS records, pointing your domain to whatever server you want, whether for web hosting, gaming servers, or other purposes. The author uses GitHub Pages for free web hosting, but any hosting service will work with proper DNS configuration.

The FAQ section addresses common questions about locality domains. You don't necessarily need to live in the area your domain represents, and WHOIS requests won't leak your personal address, only showing registrar information instead. The article concludes with thanks to other guides that helped the author navigate this process, which inspired them to create a more detailed explanation for others interested in registering their own locality domains.

美国在 AI 竞赛中最关键的商业化环节上占据领先。自 2025 年初 DeepSeek R1 引发轰动以来，美国企业提速发展，OpenAI 向智能体领域和 Codex 扩展，Anthropic 把 Claude Code 打造成为商业产品。中国有竞争力的模型，但美国在营收、采用率、工具链和全球影响力上明显领先。对中国而言，DeepSeek 的真正战略价值不在于商业主导，而在于通过推动推理向华为昇腾等国产硬件迁移，减少对 Nvidia 的依赖，支持供应链自主，而非追求以盈利为核心的 AI 霸主地位。

能源对 AI 很重要，但并非决定性因素。廉价电力能降低模型运行成本，美国的零售电价低于德国、英国、法国和西班牙等西欧主要经济体，但中国和俄罗斯的电价更便宜。电力本身不足以决定输赢：即便电价低廉，如果缺乏云规模、平台覆盖、开发者生态和大量可用数据的获取渠道，也会落败。美国在这些层面都形成了协同效应，这恰恰是其最强的优势。

真正决定胜负的是云基础设施和数据。全球性的超大规模云服务商——AWS 、 Azure 和 Google Cloud——掌握了模型触达世界的主要通道。美国的平台同时在生成和组织驱动 AI 所需的数据，从 YouTube 的视频语料，到嵌入日常办公的 Google Drive 与 Microsoft 365，再到深度参与软件开发的 GitHub 。它们既是分发系统，又是数据平台，使得新模型可以迅速推送到人们日常使用的产品中。中国在其庞大的国内市场内也具备许多这样的能力，但欧洲不具备这一整套体系。

欧洲有高水平的工程人才，但仅有人才还不够。美国的超大规模云服务商已占据主导地位，要想迎头赶上，除了要为本土云提供巨额资金，还必须把银行、制造业和公共机构迁移到这些平台上，这一过程可能耗时接近十年。而到那时，美国平台的领先优势将更难撼动。唯一的例外是 Arkady Volozh 正试图把 Nebius 打造为一家欧洲 AI 基础设施公司，但这恰恰说明了欧洲在这场竞赛中的起步仍然很晚。

SAP 的 Christian Klein 主张欧洲不需要更多数据中心，仅靠大语言模型也远远不够——这两点都是对的。但他忽视了一个核心事实：美国之所以领先，是因为它在同时构建每一个关键层面——芯片、能源、数据中心、云平台、开发者工具、消费级平台和企业软件。 AI 只有与真实数据、真实工作流和真实产品结合时才有价值，而美国具备将这些环节在大规模上整合起来的体系。

另一个正在出现的前沿是武器化的 AI 。下一阶段可能会出现国家之间在机器人网络、网络攻防和自主武器上的 AI 对抗。将系统调整为去人性化对手或针对特定人群令人不安地容易，一旦模型被嵌入媒体、网络和武器中，偏见就会转化为力量。这也把 AI 竞赛推向了一场安全竞赛。像 Anthropic 的 Mythos 这样的模型预示着另一次转变：以往的开源冲动会让位于通过"隐藏式安全"实现的封闭体系，采用封闭的软件、工具、固件和芯片。专有堆栈的价值会延伸到硬件层面，因为无法在目标的代码和架构上训练的模型，将缺乏上下文并且运行速度更慢。 The US is winning the AI race where it counts most, commercialization. Since DeepSeek R1 made waves in early 2025, American companies have accelerated faster, with OpenAI pushing into agents and Codex and Anthropic turning Claude Code into a business. China has competitive models, but the US leads clearly in revenue, adoption, tools, and global reach. DeepSeek's real strategic value for China is less about commercial dominance and more about reducing dependence on Nvidia by pushing inference toward domestic hardware like Huawei Ascend, supporting supply chain autonomy rather than profitable AI leadership.

Energy matters for AI, but it is not the decisive factor. Cheap electricity lowers model costs, and the US enjoys lower retail power prices than major Western European economies like Germany, the UK, France, and Spain. However, China and Russia are even cheaper. Power alone does not determine the winner. A country can have inexpensive electricity and still lose if it lacks cloud scale, platform reach, developer ecosystems, and access to large flows of useful data. The US has all of these layers working together, which is where its strongest advantage lies.

The decisive layers are cloud infrastructure and data. The US owns the global hyperscalers, AWS, Azure, and Google Cloud, which serve as the primary channels through which models reach the world. American platforms also generate and organize the data that fuels AI, from YouTube's video corpus to Google Drive and Microsoft 365 embedded in daily office work to GitHub sitting inside software development. These are both distribution systems and data platforms, allowing new models to be pushed into products people already use every day. China has much of this within its large domestic market, but Europe does not.

Europe has strong engineering talent, but talent alone is not enough. US hyperscalers already dominate, and catching up would require not just financing cloud champions but also migrating banks, manufacturers, and public agencies onto those platforms, a process that would take most of a decade. By then, American platforms would be even further ahead. There is one exception, Arkady Volozh's effort to build Nebius into a European AI infrastructure company, but that only confirms how early Europe still is in this race.

SAP's Christian Klein has argued that Europe does not need more data centers and that large language models alone are not enough. He is right on both points, but his broader view misses the main fact. The US is winning because it is building every major layer simultaneously: chips, power, data centers, cloud platforms, developer tools, consumer platforms, and enterprise software. AI only becomes valuable when tied to real data, real workflows, and real products, and the US has the integrated system to make that happen at scale.

There is another frontier emerging: weaponized AI. The next phase may involve country-versus-country AI in bot networks, cyber campaigns, and autonomous weapons. Tuning systems to dehumanize rivals or target populations is disturbingly easy, and once models are embedded into media, networks, and weapons, bias becomes force. This makes the AI race also a security race. Models like Anthropic's Mythos point to another shift, where the old open-source instinct gives way to security by obscurity, with closed software, tooling, firmware, and chips. Proprietary stacks raise their value all the way down to hardware, because a model that cannot train on a target's code and architecture will have less context and speed.

我把代码从 GitHub 迁到自托管的 Forgejo 实例，有好几个原因，但归根到底是一个问题：所有权。在截至 2026 年 4 月的一年里，GitHub 记录了 257 起事故，其中 48 起属重大事故；CTO 公开道歉，称容量需要扩大 30 倍才能应付 AI 带来的负载。但宕机只是表象，根本转折是在 2025 年 8 月：GitHub 不再有自己的 CEO，被并入微软的 CoreAI 部门，也就是在开发 Copilot 的团队。现在把代码推到 GitHub 等于推到了微软 AI 组织的一个单元，这从根本上改变了你与平台的关系。

2026 年 4 月训练数据默认设置的变更把这件事具体化。 GitHub 修改隐私声明，Copilot Free 、 Pro 和 Pro+ 用户的交互数据默认用于 AI 训练，并且没有仓库级别的退出选项。作为维护者，我不能要求 GitHub 不在我的代码库交互上进行训练。退出是按用户账户设置的，这意味着任何使用 Copilot 的人接触到我的代码时，代码都有可能被用作训练素材，不论我如何授权。私有仓库的豁免也没想象中完全：当 Copilot 激活时生成的"代码片段和交互上下文"仍会被收集。只有 Copilot Business 和 Enterprise 客户例外，且是因为他们受单独的数据保护协议约束。

还有管辖权问题。 GitHub 和 Microsoft 都是美国公司，这意味着它们持有的任何数据都可能受到 FISA 第 702 条和 CLOUD Act 的影响，不管数据物理存放在哪儿。 GitHub 于 2024 年 10 月推出的欧盟数据驻留选项解决了数据位置问题，但没能解决管辖权，因为 CLOUD Act 是随企业控制权而非地理位置生效。微软一位律师在法国参议院听证会上宣誓表示，他无法保证存放在欧洲数据中心的欧盟数据不会被美国政府静默访问。荷兰政府也得出相同结论，并于 2026 年 4 月软启动了 code.overheid.nl——一个自托管的 Forgejo 实例，正是因为需要在一个自己真正拥有的平台上发布源代码。

我选择 Forgejo 而不是 GitLab，主要出于两点考虑。第一是许可：GitLab 采用 open core 模式，许多生产功能被锁在企业版后面；而 Forgejo 在 2024 年 8 月改用 GPLv3+ 许可，明确要保持 copyleft，抵抗商业收编。第二是治理：Forgejo 隶属于 Codeberg e.V.，一家在柏林注册的非营利组织，有成员选举的董事会和公开预算。 2022 年 12 月从 Gitea 分叉，正是因为 Gitea Ltd 在未经社区同意的情况下控制了商标，项目结构也反映了这次教训。 Forgejo v15.0 LTS 于 2026 年 4 月 16 日发布，长期支持到 2027 年 7 月。

我的部署跑在一台 64 GB 内存的 Intel NUC 上。 Forgejo v15 LTS 、 Postgres 17 和 Traefik 在 Docker 中运行；Actions 运行器放在由 Incus 管理的 KVM 虚拟机里。运行器才是真正需要下功夫的部分，因为它要执行不受信任的代码，例如对我的仓库做 npm 和 pip 安装，并按 Renovate 的日程每天运行。我用了五层重叠隔离：用 KVM 虚拟机避免共享主机内核；在该虚拟机内用 gVisor 作为 Docker 运行时，在用户空间拦截系统调用；每周做一次破坏性重建，从干净基础镜像销毁并重建整个虚拟机；用 nftables 做出口过滤，阻断对局域网的访问；以及使用范围绑定的运行器令牌，确保令牌只能在注册范围内使用。这些技术本身并不新，但把它们整合到一台 NUC 的单人家庭实验室里，才使整体方案可行。

这其中有真实的权衡。可发现性和社交网络是最大的代价，因为贡献者习惯在 GitHub 上找到我。我的计划是在迁移完成后将每个公共 GitHub 仓库归档，并在 README 中指向 code.jorijn.com，以保持发现路径。 Forgejo Actions 倾向于与 GitHub Actions 保持相似体验，而不是完全兼容，所以有些功能会静默失效，比如工作流级别的权限受限，有些 action 需要固定版本或自行分叉。 Forgejo 没有 Dependabot，因此我在同一自托管运行器上运行 Renovate 。也没有 7×24 的厂商支持，只有一个 issue 跟踪器和一个聊天室——对单人运维足够，但对更大团队可能难以扩展。

这种迁移并不适合所有人。如果你的团队不想运行基础设施、如果你高度依赖 GitHub 特有功能如 Codespaces 或 Advanced Security 、或者你的贡献者群体完全依赖 GitHub 的社交网络，那么这些摩擦可能不值得。荷兰政府的方法是个好范例：code.overheid.nl 是软启动平台，而非全面替代。我的部署也是同样的思路：Forgejo 是我的主平台，GitHub 是镜像，我也不排除以后再调整。关键是：在一台 NUC 上实现一个有防护能力的自托管 Forgejo 部署是可行的，但运行器需要真正用心对待；如果你不准备处理 KVM 隔离、 gVisor 、 nftables 和每周重建，最好把 CI 任务放到托管运行器上，或者继续留在 GitHub 。 There are several reasons why I moved my code from GitHub to a self-hosted Forgejo instance, and they all boil down to one thing: ownership. GitHub logged 257 incidents in the year leading up to April 2026, 48 of them major, and the CTO publicly apologized, saying capacity needs to scale 30x to keep up with AI-driven load. But the outages are a symptom, not the cause. The real shift happened in August 2025 when GitHub stopped having its own CEO and was absorbed into Microsoft's CoreAI division, the same group building Copilot. When you push code to GitHub now, you're pushing it to a unit of Microsoft's AI organization, and that changes the relationship fundamentally.

The training-data default flip in April 2026 made this concrete. GitHub changed its privacy statement so that interaction data from Copilot Free, Pro, and Pro+ users is now used for AI training by default, with no repository-level opt-out. As a maintainer, I can't tell GitHub not to train on interactions inside my codebase. The opt-out is per user account, meaning my code becomes training material whenever anyone using Copilot touches it, regardless of how I license it. Private repositories get a narrower carve-out than it sounds, since "code snippets and interaction context" generated while Copilot is active are still collected. Only Copilot Business and Enterprise customers are exempt, and only because they're governed by separate Data Protection Agreements.

Then there's the jurisdiction problem. GitHub and Microsoft are US companies, which means anything they hold falls under FISA Section 702 and the CLOUD Act, regardless of where the data physically sits. GitHub's EU data residency option, launched in October 2024, solves data location but not jurisdiction, since CLOUD Act exposure follows corporate control, not geography. Microsoft's own attorney told a French Senate hearing under oath that he couldn't guarantee EU data stored in European datacenters was safe from silent US government access. The Dutch government reached the same conclusion and soft-launched code.overheid.nl in April 2026, a self-hosted Forgejo instance, specifically because the ministry needed to publish source code on a platform it actually owns.

I chose Forgejo over GitLab for two reasons. First, licensing. GitLab is open core, with many production features locked behind enterprise tiers. Forgejo relicensed to GPLv3+ in August 2024 with the explicit goal of staying copyleft and resisting commercial capture. Second, governance. Forgejo lives under Codeberg e.V., a non-profit registered in Berlin with a member-elected board and public budgets. The fork from Gitea in December 2022 happened precisely because Gitea Ltd took control of trademarks without community consent, and the project's structure now reflects that lesson. Forgejo v15.0 LTS shipped on April 16, 2026, with long-term support through July 2027.

My setup runs on a single Intel NUC with 64 GB of RAM. Forgejo v15 LTS, Postgres 17, and Traefik live inside Docker, and an Incus-managed KVM virtual machine hosts the Actions runner. The runner is where the real engineering lives, since it has to execute untrusted code like npm and pip installs against my repositories on a daily Renovate schedule. I use five overlapping isolation layers: a KVM virtual machine so the host kernel isn't shared, gVisor as the Docker runtime inside that VM to intercept system calls in user space, a weekly destructive rebuild that destroys and recreates the entire VM from a fresh base image, an nftables egress filter that blocks access to my LAN, and scope-bound runner tokens that can't be used outside their registered scope. None of these primitives are novel, but wiring them together for a single-user homelab on one NUC is what makes the setup work.

There are real tradeoffs. Discovery and the social graph are the biggest cost, since contributors expect to find me on GitHub. My plan is to archive each public GitHub repository once the migration is complete and point the README at code.jorijn.com, keeping the discovery path intact. Forgejo Actions aims for familiarity with GitHub Actions, not compatibility, so some things break silently, like permissions blocks at the workflow level, and some actions need pinning or forking. Forgejo doesn't have Dependabot, so I run Renovate on the same self-hosted runner instead. And there's no 24/7 vendor support, just an issue tracker and a chat room, which is fine for a one-person operation but might not scale for larger teams.

This move isn't for everyone. If your team has no appetite for running infrastructure, if you're heavily invested in GitHub-specific features like Codespaces or Advanced Security, or if your contributor base depends entirely on the GitHub social graph, the friction may not be worth it. The Dutch government's approach is a good model: code.overheid.nl is a soft-launch platform, not a wholesale replacement. My setup has the same shape, Forgejo is canonical for my work, GitHub is a mirror, and I'm willing to revisit that later. The key point is that a defensible self-hosted Forgejo deployment is achievable on a single NUC, but the runner is the part that requires real care, and if you're not prepared to think about KVM isolation, gVisor, nftables, and weekly rebuilds, you should run your CI jobs on a managed runner host or stay on GitHub.

作者描述了一次有意识的迁移：把整个数字基础设施从美国云服务迁向 European 替代方案，原因是他们对自己的数据和工具托管在自己无法控制、司法环境日益不可预测的服务器上感到越来越不安。作者认为，数字主权不是流行语，而是关于知道数据存放在哪里、不会因为一次政策变更或企业并购就失去对关键工具访问权的一种务实立场。这次迁移与其说是出于偏执，倒不如说是为了让基础设施选择与价值观保持一致。

分析工具是首个改动点。 Google Analytics 被自托管的 Matomo 替代：所有数据保留在作者自有服务器上，因而无需显示 Cookie 同意横幅。代价是增加了维护工作——作者必须负责更新与备份——但报告全面且界面熟悉。邮件服务从 Google Workspace 迁到 Proton Mail，后者基于 Switzerland，侧重隐私而非广告，在协议层面提供端到端加密。需要注意的是，Proton 的过滤系统不及 Gmail 强大，尤其无法根据邮件正文过滤；即便是高级方案，自定义域名也被限制为三个。密码管理也迁入 Proton 生态，采用 Proton Pass——一个端到端加密的开源工具，受同一 Switzerland 司法管辖，从 1Password 迁过去更多是横向替换而非升级。

在计算资源上，DigitalOcean 被 Scaleway 取代——这家位于 France 的云提供商出乎意料地给作者留下好印象：控制面板简洁、服务器启动迅速，并在选择地点时显示预计 CO2 排放量，这促使作者将大部分基础设施托管在 Paris 。对象存储从 AWS S3 迁到 Scaleway 的 S3 兼容服务，使用 rclone 迁移；由于 bucket 体量大，这一机械化过程耗时一周多。异地备份从 Backblaze 迁到 OVHcloud，作为 European 最大的云提供商之一，一旦配置生命周期规则把旧备份转入冷存储，会更划算；不过 OVH 的控制面板被形容为迷宫，需要耐心并配合终端操作才能顺利使用。

事务性邮件从 Twilio SendGrid 切换到 Lettermint——一个更精简的 European 服务，投递表现良好、定价透明；通过合并两个 SendGrid 账户，作者实际上节省了成本。错误追踪由 Sentry 改为自托管的 Bugsink，仅需一行配置就能接收 Sentry 的 SDK 。 Bugsink 功能本就精简，缺少性能监控和高级告警，但对作者来说，一个带堆栈跟踪的远程错误日志已足够，而且数据完全不离开他们的基础设施。 AI API 集成从 OpenAI 转到 Mistral——这家总部在 Paris 的提供商提供开放权重模型和清晰的 API，迁移在质量上属横向，但在资金去向和提供商价值观上更有意义。

并非所有服务都迁移。 Cloudflare 仍被保留为 CDN，因为其主要作用是缓存并保护已公开的内容，这改变了关于主权的考量；而其诸如安全规则和 Workers 平台等功能，Bunny CDN 未能充分替代。支付处理仍使用 Stripe，尽管作者更倾向于 EU 司法管辖，因为迁移会牵扯到账单逻辑、 webhook 和税务发票等，需要谨慎时机；Dutch 替代方案 Mollie 在他们的用例下反而更昂贵。 AI 代码辅助从 OpenAI 切到 Claude Code，后者仍基于美国，但作者之所以选择，是因为 Anthropic 在安全性和透明度方面的方法更有结构性基础；作者也指出，像 Alibaba 的 Qwen 这样的本地模型在完全在自有硬件上运行推理方面正变得越来越可行。 GitHub 也保留用于面向公众的 NPM 包和开源问题跟踪——网络效应和开发者预期让它成为现实的选择。

总体评价是积极的：大多数迁移只花了半天时间，少数耗时更久，但没有发生严重问题。两个月下来，一切平稳运行。作者的结论是，European 云生态大体成熟，工具可靠且功能完善，唯一阻碍他们的只是惰性。数字主权就是要意识到谁在持有你的数据、政治变化会带来什么影响，而这次迁移证明，完全可以主要依靠 European 基础设施来运行专业级的数字技术栈。 The author describes a deliberate migration of their entire digital infrastructure away from US-based cloud services toward European alternatives, driven by a growing unease with how much of their data and tooling sat on servers they didn't control, in a jurisdiction they found increasingly unpredictable. Digital sovereignty, they argue, isn't a buzzword but a practical stance about knowing where your data lives and not being one policy change or corporate acquisition away from losing access to critical tools. The migration was less about paranoia and more about aligning infrastructure choices with values.

Analytics was the first target. Google Analytics was replaced with a self-hosted Matomo instance, which keeps all data on the author's own server and eliminates the need for cookie consent banners. The tradeoff is maintenance overhead, since the author is now responsible for updates and backups, but the reporting is comprehensive and the interface familiar. Email moved from Google Workspace to Proton Mail, which is based in Switzerland and built around privacy rather than advertising, with end-to-end encryption at the protocol level. The adjustment worth noting is that Proton's filter system is more limited than Gmail's, particularly the inability to filter on email body content, and custom domains are capped at three even on higher-tier plans. Password management followed into the Proton ecosystem with Proton Pass, an end-to-end encrypted, open-source tool under the same Swiss jurisdiction, making the move from 1Password more of a lateral shift than an upgrade.

For compute, DigitalOcean was replaced with Scaleway, a French cloud provider that turned out to be a pleasant surprise with a clean control panel, fast server provisioning, and the notable feature of displaying projected CO2 emissions alongside location choices, which led the author to host most infrastructure in Paris. Object storage migrated from AWS S3 to Scaleway's S3-compatible offering using rclone, a mechanical process that took over a week due to bucket size. Offsite backups moved from Backblaze to OVHcloud, Europe's largest cloud provider, which is cheaper once lifecycle rules are configured to move older backups to cold storage, though the OVH control panel is described as a labyrinth that requires patience and terminal work to navigate.

Transactional email shifted from Twilio SendGrid to Lettermint, a leaner European service with solid deliverability and straightforward pricing that actually cut costs by allowing the author to merge two SendGrid accounts. Error tracking moved from Sentry to Bugsink, a self-hosted tool that accepts Sentry's SDK with a one-line configuration change. Bugsink is bare-bones with no performance monitoring or advanced alerting, but for the author's needs, a simple remote error log with stack traces, it works perfectly with no data leaving their infrastructure. AI API integrations switched from OpenAI to Mistral, a Paris-based provider with open-weight models and a clean API, making the transition lateral in quality while meaningfully better in terms of where the money goes and the values behind the provider.

Not everything moved. Cloudflare remains as the CDN because its role is to cache and protect already-public content, making the sovereignty calculus different, and its feature set including security rules and the Workers platform wasn't matched closely enough by the European alternative Bunny CDN. Stripe remains as the payment processor despite the author's preference for EU jurisdiction, because migration touches billing logic, webhooks, and tax invoicing in ways that require careful timing, and Mollie, the Dutch alternative, is more expensive for their use case. AI code assistance moved from OpenAI to Claude Code, which is still US-based but chosen because Anthropic's approach to safety and transparency feels more structurally grounded, and the author notes that local models like Alibaba's Qwen are becoming increasingly viable for running inference entirely on your own hardware. GitHub also remains for public-facing NPM packages and open source issue tracking, where network effects and developer expectations make it the practical choice.

The overall assessment is positive. Most migrations took an afternoon of work, a few took longer, and none were catastrophic. Two months in, everything runs without incident. The author's conclusion is that the European cloud ecosystem is mostly mature, the tools are reliable and capable, and the only thing that was stopping them was inertia. Digital sovereignty, they argue, is about being conscious of who holds your data and what happens when politics shift, and this migration proved it's entirely possible to run a professional digital stack mostly from European infrastructure.

2026 年 5 月 13 日，互联网清理基金会推出了 SecurityBaseline.eu，这是一个用于监控和可视化欧洲各国政府网络安全状况的新网站。该项目源自 Netherlands 的"Basisbeveiliging"计划，后者已经追踪基础安全十余年。基金会在网站上线前三个月向欧洲各国政府发送了数万封邮件，给各方机会在数据公开前审查并修复问题。其目标是提高网络透明度，并通过促使政府对自身和国家实施更高的安全标准来更好地保护公民。

SecurityBaseline.eu 使用名为 Web Security Map 的软件，该软件已开发超过十年。网站覆盖 32 个国家，包括所有 EU 成员国以及 Switzerland 、 Norway 、 Iceland 和 Liechtenstein，检测约 67,000 个地方政府的近 200,000 个互联网域名（实际的政府域名数量可能高出十倍）。网站每天生成超过 1,800 张"交通灯"式地图：红色表示存在安全问题，橙色表示有警告，绿色表示无问题。这些地图基于 21 项指标，涵盖从加密质量到是否存在跟踪 cookie 等多方面内容。

其中一项令人担忧的发现是，有 3,081 个欧洲政府网站在未经用户同意的情况下使用跟踪 cookie，这违反了 GDPR 。按比例看，Slovakia 以近 9.88% 位列首位，其次是 Greece（8.16%）和 Portugal（7.63%）。 YouTube 是这些跟踪 cookie 的最大来源，出现 2,077 次，其次是 Google Ads（842 次）。基金会指出，许多跟踪 cookie 是集成现代技术时带来的副作用，这类技术往往隐藏了广告相关代价，因此敦促政府采用更尊重隐私的网页开发做法。

另一大问题是数据库管理界面的外置，尤其是 phpMyAdmin，本不应对外公开。基金会在 3,529 个域名上发现了 1,070 个 phpMyAdmin 门户，France 有 513 个实例、 Poland 有 499 个。暴露的管理面板风险极高，容易引发安全事故，例如今年早些时候 cPanel 中发现的严重漏洞。基金会还指出，尽管 phpMyAdmin 是开源软件，但没有任何欧洲政府对该项目提供资助，这反映出对自身线上安全投入的不足。

或许更令人震惊的是，欧洲有 99% 的政府邮件加密水平不达标。只有 Netherlands 和 Denmark 的情况相对较好，分别有 58% 和 44% 的邮件域名符合现代加密标准。该加密质量依据 Netherlands 政府的最新指南进行测评，这些指南尚未在欧洲层面标准化。 Germany 和 France 等国虽有各自指南，但相互不兼容且缺乏简便的检测工具。加密不足使得政府通信易被窃听和篡改。

基金会强调，这些问题不能靠一次性修补解决，而需要持续改进并适应未来变化，例如更强的加密和量子密码学。他们敦促各国政府建立变更流程并加大线上安全投入。 SecurityBaseline.eu 的数据公开可查，基金会鼓励政府利用这些数据提升安全态势，并邀请组织与个人通过成为会员或提出进一步研究请求来支持他们的工作。

文章最后附有详细来源表，展示各国在跟踪 cookie 、 phpMyAdmin 面板与邮件加密质量方面的分布，直观呈现了安全格局，便于政府与公众识别需改进之处。基金会的工作得到包括 CIP 、 RDI 、 SIDN Fonds 、 cobytes 和 procolix 及其会员的支持，致力于通过透明化与对在线可用性、完整性和机密性的研究，推动互联网更安全。 ## European Government Security: A Wake-Up Call from SecurityBaseline.eu

On May 13, 2026, the Internet Cleanup Foundation launched SecurityBaseline.eu, a new website designed to monitor and visualize the cybersecurity posture of European governments. This initiative is a spin-off from the Dutch "Basisbeveiliging" project, which has been tracking baseline security for over a decade. The foundation sent tens of thousands of emails to European governments three months prior to the launch, giving them time to review their security status and address any issues before the data became public. The goal is to make the web more transparent and to help governments protect their citizens by imposing higher security standards on themselves and their countries.

SecurityBaseline.eu uses software called Web Security Map, which has been in development for over ten years. The site measures security across 32 countries, including all EU member states plus Switzerland, Norway, Iceland, and Liechtenstein. It covers nearly 200,000 internet domains across approximately 67,000 local governments, though the true number of government domains is likely ten times higher. The site generates over 1,800 maps daily, each colored like a traffic light: red for security issues, orange for warnings, and green for no issues. These maps cover 21 different metrics, ranging from encryption quality to the presence of tracking cookies.

One of the most alarming findings is that 3,081 European government sites use tracking cookies without user consent, which is illegal under the GDPR. Slovakia leads with nearly 9.88% of its governmental sites placing tracking cookies, followed by Greece at 8.16% and Portugal at 7.63%. YouTube is the largest source of these tracking cookies, with 2,077 instances, followed by Google Ads with 842. The foundation notes that many of these tracking cookies are a side effect of integrating modern technologies that have hidden advertising costs, and they urge governments to adopt more privacy-friendly web development practices.

Another significant issue is the exposure of database management interfaces, specifically phpMyAdmin, which should not be publicly accessible. The foundation found 1,070 phpMyAdmin portals across 3,529 domains, with France leading at 513 instances and Poland at 499. These exposed panels are particularly dangerous because they are prone to security incidents, such as the severe vulnerability discovered in cPanel earlier this year. The foundation also points out that while phpMyAdmin is open-source software, no European governments have financially contributed to the project, highlighting a concerning lack of investment in their own online security.

Perhaps the most shocking discovery is that 99% of governmental email in Europe is poorly encrypted. Only the Netherlands and Denmark show somewhat promising numbers, with 58% and 44% of their email domains meeting modern encryption standards, respectively. The encryption quality is measured using the latest guidelines from the Dutch government, which are not yet standardized at the European level. Countries like Germany and France have their own guidelines, but they are not compatible and lack simple testing tools. This poor encryption leaves government communications vulnerable to eavesdropping and tampering.

The foundation emphasizes that these issues cannot be fixed with a one-time effort but require continuous improvement and adaptation to future changes, such as stronger encryption and quantum cryptography. They urge governments to establish change processes and invest in their online security. The data from SecurityBaseline.eu is publicly available, and the foundation encourages governments to use it to improve their security posture. They also invite organizations and individuals to support their mission by becoming members or requesting further research.

The article concludes with detailed source tables showing the distribution of tracking cookies, phpMyAdmin panels, and email encryption quality across European countries. These tables provide a clear and transparent overview of the security landscape, allowing governments and citizens to see where improvements are needed. The foundation's work is supported by various organizations, including CIP, RDI, SIDN Fonds, cobytes, and procolix, as well as their members. They remain committed to making the internet safer through transparency and research into online availability, integrity, and confidentiality.

作者认为，软件正在经历他所称的"Emacs 化"，这一变化由 AI 代码代理推动。 Emacs 文化是指用户为了解决自己特定的问题，构建个人化、常带个人风格的工具，这类工具往往牺牲了可发现性和广泛可用性。现在这种理念正从文本编辑器蔓延到应用开发领域。原本构建原生用户界面很难，需要专业开发者，但有了代理，任何人都能迅速"挤出"定制化应用。这些应用不挣钱、没有明显的市场定位，仅仅是让一小撮极客的生活稍微好一点。

这一浪潮源于对现有工具糟糕体验的失望。作者指出，虽然 Markdown 已成为软件开发的通用语言，但在终端里用等宽字体阅读常令人疲惫；而图形化编辑器又对只是"查看"文件来说太过侵入。为了解决这个问题，作者用 Claude 代理做出了 MDV.app——一个专门的原生 macOS Markdown 查看器。它包含搜索、书签、复制粘贴等常规功能，注重排版并用 SQLite FTS 建索引。大约用了 30 分钟的互动时间，就做出了一款比 App Store 上现有工具更能提升他日常体验的产品。

作者认为 MDV.app 预示着更大趋势的开端。开发者不再需要依赖臃肿的、把 Chromium 打包进来的单体 Electron 应用，而会越来越多地用代理去构建专门的原生 UI 工具——关键在于创意而非源代码本身。他明确鼓励读者不必拘泥于使用他的工具，而是"拿去这个想法"，做出更好的变体。这是向个人化软件的转变：一波开发者会为了解决自身痛点去打造界面优雅、针对特定"极客"问题的工具，而这些工具以前难以证明投入的价值。

所谓软件的"Emacs 化"，就是向个人化、定制化应用的转变。在这个生态里，驱动软件的提示词和背后的想法，比源代码更有价值。作者形容这种"Emacs 化"被 AI 代理"撬开"，让原生 UI 开发变得可接近且有趣。他把这种体验比作配置 Emacs：软件开发平台变得极具可配置性。这一趋势会让"极客软件"更有吸引力，人们会用新工具替代那些糟糕的终端专用工具。

作者还举出超出简单 Markdown 查看器的例子：用代理为复杂的系统监控工具（如 bpftrace 、 iostat）构建原生 UI，取代丑陋的终端可视化。他把这种变化看作"纯粹的好事"，尽管围绕 AI 的安全隐忧仍然存在。他鼓励大家别把构建软件当成传统的体力活，而是开始用代理去"配置"。建议极客们去试一试，做"某个愚蠢但非常特定的东西"，然后分享成果，或者至少分享所用的提示词。

作者认为，这种转变会催生一波缺乏广泛商业吸引力的个人软件。这些工具可能只服务小群体，甚至只是开发者本人。 Emacs 化让任何人都能创建这些小众、个性化的工具，代表了从单体 Electron 应用向小型、原生、按需定制软件的转变。用于创建这些工具的提示与想法，与工具本身一样重要，构建软件的过程正在演变成一种配置行为。 The author argues that software is undergoing what he calls "Emacsification," a shift driven by AI code agents. Emacs culture is defined by users building personal, often idiosyncratic tools to solve their own specific problems, frequently at the expense of discoverability or broad usability. With AI agents, this same ethos is now leaking out of text editors and into application development. Building native user interfaces used to be difficult work that required professional software developers, but agents now allow anyone to quickly "extrude" bespoke applications. These applications make no money and have no obvious market fit. They simply make life slightly better for a small group of nerds.

The phenomenon was triggered by frustration over the poor quality of existing tools. The author suggests that while Markdown has become the universal language of software development, the tools used to read it in the terminal are often fatiguing when rendered in monospaced fonts. Graphical UI editors are too intrusive for just "viewing" a file. To solve this, the author used the Claude agent to build MDV.app, a dedicated native macOS Markdown viewer. The tool includes standard features like search, bookmarks, and copy-paste, along with good typography and a SQLite FTS index. It took about 30 minutes of interactive time to build something that improves the author's daily quality of life better than anything currently on the App Store.

The author believes SDV.app marks the start of a larger trend. Instead of relying on awful, monolithic Electron apps that carry their own copy of Chromium, developers will increasingly use agents to build specialized native UI tools where the key artifact is the idea rather than the source code. He explicitly encourages readers not to necessarily use his tool, but to "steal the idea" and build their own better versions. This represents a shift toward personal software. He suggests that we will see a wave of builders scratching their own itches, solving specific "nerd" problems with pleasant interfaces that were previously too difficult to justify the effort of building.

The "Emacsification" of software refers to the shift toward personal, bespoke applications. In this ecosystem, the prompts and the ideas behind the software are more valuable than the source code itself. "Emacsification" is described as "fracked" by AI agents, making native UI development accessible and fun. The author compares the experience to configuring Emacs, because the platform of software development has become vastly more configurable. He suggests that this trend will make "nerd software" more interesting as people build tools to replace terrible terminal-only utilities.

The author concludes by providing examples of this trend beyond simple Markdown viewers. He mentions using agents to build native UI for complex system monitoring tools like `bpftrace` and `iostat`, replacing ugly terminal visualizations. He frames this as an "unalloyed good," even amidst the dread surrounding AI and security vulnerabilities. He encourages readers to stop thinking of software construction as "building" in the traditional, labor-intensive sense and instead start "configuring" with agents. He advises nerds to give it a shot, "make something stupidly specific," and then share the results, or at least the prompts.

He suggests that this shift will lead to a wave of "personal software" that lacks broad commercial appeal. These tools will be created for small groups, or even just the developers themselves. He suggests that the "Emacsification" of software is making the creation of these personal, niche tools accessible to everyone. This represents a move away from monolithic Electron apps. It shows that the future of software might be small, native, and custom-built for specific problems. The prompts used to create these tools are as important as the tools themselves, and the act of building software has become a form of configuration.

Elevator 是一款开创性的二进制翻译器，能够在无需调试信息、源代码或关于代码布局的假设下，将整个 x86-64 可执行文件静态地转换为 AArch64 。不同于现有系统，它不依赖启发式规则或运行时回退来解决代码与数据混淆这一难题；相反，Elevator 会对二进制中每个字节的所有可能解释一一考虑，预先为每种可行解释生成独立的翻译。每个字节既可能是数据、也可能是指令或指令参数，系统为每种可能性构建独立的控制流路径，仅剪除会导致非正常终止的路径。

该系统通过组合从源指令集的高级描述自动派生出的代码"瓦片"来生成翻译，这使得翻译框架既灵活又易于适配。其方法是完全确定性的，意味着输出是完整且自包含的可执行文件，可信代码基中不含任何运行时组件。这与需运行时支持的模拟器或 JIT 编译器不同，后者既有运行时开销，也无法在编译时确定最终会执行哪些代码。

这种彻底性带来的主要代价是代码体积显著膨胀：同一字节的多种解释会产生多条代码路径，导致生成的代码增多。然而，关键优势在于生成的二进制确实代表将在目标硬件上运行的实际代码，从而可以在部署前对翻译结果进行测试、验证、认证，甚至进行加密签名，相较于那些只有在运行时才能确定最终执行代码的方法，这大大降低了风险。

研究者在多种真实二进制上对 Elevator 进行了评估，包括整个 SPECint 2006 基准套件。结果表明，静态的全程序二进制翻译既可靠又实用。在性能上，Elevator 的表现与广泛使用的 QEMU 用户态 JIT 仿真相当或更优，这一成就是值得注意的，因为静态翻译通常难以与能在运行时自适应优化的 JIT 编译器竞争。

总体而言，这项工作标志着二进制翻译技术的一大进步，证明可以在不同处理器架构之间实现对复杂真实二进制的完整静态翻译而不牺牲可靠性。通过消除对启发式方法和运行时组件的依赖，Elevator 为那些对代码完整性和可预测性有严格要求的场景开辟了新可能，例如安全敏感的应用或需要形式化认证的系统。 Elevator is a groundbreaking binary translator that can statically convert entire x86-64 executables to AArch64 without needing debug information, source code, or assumptions about how the code is laid out. What sets it apart from existing systems is that it doesn't rely on heuristics or runtime fallbacks to handle the tricky problem of distinguishing code from data. Instead, it considers every possible interpretation of each byte in the binary, generating separate translations for all feasible interpretations ahead of time. Any byte might be data, an opcode, or an opcode argument, and Elevator creates separate control flow paths for each possibility, only pruning those that would lead to abnormal termination.

The system builds translations by composing code "tiles" that are automatically derived from a high-level description of the source instruction set architecture. This makes the translation framework nimble and adaptable. The approach is fully deterministic, meaning it produces complete, self-contained binaries with no runtime component in the trusted code base. This is a significant departure from emulators or JIT compilers, which carry runtime overhead and uncertainty about what code will actually execute.

The main trade-off for this thoroughness is substantial code size expansion, since multiple interpretations of the same bytes result in multiple code paths being generated. However, the key benefit is that the output represents the actual code that will run on the target hardware. This enables testing, validation, certification, and even cryptographic signing of the translated binary before it's ever deployed, which significantly reduces risk compared to approaches where the final executing code isn't known until runtime.

The researchers evaluated Elevator on a diverse set of real-world binaries, including the entire SPECint 2006 benchmark suite. The results demonstrate that static full-program binary translation can be both reliable and practical. In terms of performance, Elevator achieves results on par with or better than QEMU's user-mode JIT emulation, which is a widely used and respected dynamic binary translation system. This is a notable achievement since static translation typically faces challenges competing with the optimization opportunities available to JIT compilers that can adapt at runtime.

The work represents a significant advance in binary translation technology, showing that it's possible to achieve complete static translation of complex real-world binaries across different processor architectures without sacrificing reliability. By eliminating the need for heuristics and runtime components, Elevator opens up new possibilities for scenarios where code integrity and predictability are critical, such as in security-sensitive applications or systems requiring formal certification.

从未大学毕业的 Eric Park 分享了他在美国毕业帽和礼服租赁体系的经历，指出租金高达 94 美元且必须归还。他还幽默地质疑典礼上把流苏从右侧移到左侧的传统，打趣称这是对左撇子的"歧视"。这一传统促使他制作了一个装置：当流苏被移动时，帽檐底部会亮起灯——毕竟根据租赁协议和 Purdue University 的规定，把帽子点着显然不被允许。

该项目使用了 Digispark ATtiny85 微控制器、 48 颗 WS2812B LED 、从报废的苹果 USB-C 数据线回收的线材、用于检测流苏的簧片开关和磁铁、一个 USB-C Power Delivery 触发板以及一个移动电源。代码用 Rust 编写，耗时大约两小时，但由于 avr-hal 和 ws2812-avr 库默认不支持 ATtiny85，他不得不对它们进行 fork 和补丁处理。硬件组装花了三个多小时，Eric 指出动手总比别人说的要难。

尽管做成了这个装置，Eric 最终决定不在毕业典礼上佩戴它，因为他觉得看起来"相当俗气"，像孩子眼中的游戏电脑，或是老一辈人认为会诱发癫痫的闪烁灯。他在视频中对快速闪烁灯做了警告，并提到与癫痫相关的一个错失的玩笑机会。项目完整源码可在他的 GitHub 仓库 github.com/ericswpark/gradcap-rs 查阅。 Eric Park, who had never graduated from college before, shares his experience with the US graduation cap and gown rental system, noting the high cost of $94 and the requirement to return them. He also humorously questions the tradition of moving the tassel from right to left during the ceremony, jokingly suggesting discrimination against left-handed people. This tassel-moving tradition inspired him to create a contraption that would light up the bottom of his cap when the tassel was moved, since setting the cap on fire was likely prohibited by the rental agreement and Purdue University regulations.

The project uses a Digispark ATtiny85 microcontroller, 48 WS2812B LEDs, wires salvaged from a dead Apple USB-C cable, a reed switch and magnet for tassel detection, a USB-C Power Delivery trigger board, and a power bank. The code was written in Rust, which took about 2 hours, though it required forking and patching the `avr-hal` and `ws2812-avr` libraries since they didn't support the ATtiny85 out of the box. The hardware assembly took over 3 hours, which Eric notes is always more challenging than people claim.

Despite building the device, Eric decided not to wear it to his actual graduation ceremony because he felt it looked "pretty tacky," comparing it to what kids might think of as a gaming PC or what older generations might consider seizure-inducing. He includes a video warning about rapid strobing lights, referencing a missed opportunity related to the seizure comment. The full source code for the project is available on his GitHub repository at github.com/ericswpark/gradcap-rs.

Cloudflare 的开源 QUIC 实现 quiche 默认使用 CUBIC 拥塞控制算法来管理 TCP 和 QUIC 连接的带宽。近期工程师发现了一个 bug：在发生拥塞崩溃后，CUBIC 的拥塞窗口（cwnd）会永久卡在最小值，即使网络条件恢复也无法增长。这个问题在大量丢包的集成测试中暴露出来，约 60% 的测试未能在预期时间内完成。

问题追溯到 2017 年 Linux 内核为防止空闲期后 cwnd 膨胀而做的一项优化。将该修复移植到 quiche 时引入了一个细微错误：实现用最后发送数据包的时间来度量空闲时长，而不是用最后收到 ACK 的时间。在最小 cwnd（仅两个数据包）情况下，这会让算法在每个往返时间都错误地判断为空闲，从而不断把恢复开始时间往前推移。结果形成了一个自我延续的循环：拥塞窗口被钉在最小值，在恢复和拥塞避免之间来回振荡，却始终无法增长。

修复只需一个关键的小改动：把空闲时长的起点改为 bytes_in_flight 实际降为零时的时刻（用最后 ACK 时间近似），而不是最后发送时间。这样避免了导致恢复边界不断追赶发送时间的 delta 值膨胀。仅三行代码的改动就使拥塞窗口在丢包后能按预期的 CUBIC 曲线正常增长，性能恢复如常。该方案既保留了原始优化对真正空闲连接的好处，又消除了最小 cwnd 处的"死亡螺旋"。

这一案例说明，"空闲"的定义比表面看起来更复杂，尤其在窗口很小时，管道延迟可能被误判为空闲。该 bug 在正常运行时不可见，仅在严重拥塞后显现。尽管工程师们使用 qlog 和可视化工具进行了数周调查，最终的修复却非常简单，证明有时最难捉的 bug 也有优雅的解决方案。该修复已提交到 cloudflare/quiche 仓库，提升了使用 CUBIC 拥塞控制的 QUIC 连接的可靠性。 Cloudflare's open-source QUIC implementation, quiche, uses the CUBIC congestion control algorithm as its default, which governs how TCP and QUIC connections manage bandwidth. Recently, engineers discovered a bug where CUBIC's congestion window (cwnd) would get permanently stuck at its minimum size after a congestion collapse, preventing recovery even when network conditions improved. This issue surfaced during integration tests involving heavy packet loss, where about 60% of tests failed to complete within the expected timeframe.

The problem was traced to a Linux kernel optimization from 2017 designed to prevent cwnd inflation after idle periods. When this fix was ported to quiche, it introduced a subtle bug. The implementation incorrectly measured idle time by using the last packet sent time rather than the last ACK received time. At minimum cwnd (just two packets), this caused the algorithm to falsely detect an idle period every round trip, pushing the recovery start time forward repeatedly. This created a self-perpetuating cycle where the congestion window remained pinned at its minimum, oscillating between recovery and congestion avoidance states without ever growing.

The fix involved a small but crucial change: measuring idle duration from when bytes_in_flight actually transitioned to zero (approximated by the last ACK time) instead of the last send time. This prevented the inflated delta calculation that was causing the recovery boundary to chase the send time. With this three-line change, the congestion window could properly grow along the expected CUBIC curve after loss events, restoring normal performance. The solution preserved the original optimization's benefits for genuinely idle connections while eliminating the death spiral at minimum cwnd.

This case highlights how defining "idle" is more complex than it appears, especially at small window sizes where pipeline delays can mimic idleness. The bug was invisible during normal operation and only manifested after severe congestion events. Despite weeks of investigation using qlog instrumentation and visualization, the final fix was remarkably simple, demonstrating that sometimes the most elusive bugs have elegant solutions. The fix has been contributed to the cloudflare/quiche repository, improving reliability for QUIC connections using CUBIC congestion control.

Kraftwerk 于 1976 年发行的单曲 "Radioactivity"，出自他们的专辑《 Radio-Activity 》。五十年来，这首歌从一首开创性的电子曲目演变为一首有力的反核抗议颂歌。它以脉冲般的盖革计数器声、层层推进的合成器音色和令人难忘的口语化副歌为特征，最初颂扬科学创新，随后转向对核能的批判。这一变化体现了 Kraftwerk 将作品与当下议题相结合的能力，使 "Radioactivity" 成为一首与全球关于核能与环境安全关切持续共鸣的经典之作。

1975 年发行的原版《 Radio-Activity 》专辑是电子音乐史上的重要里程碑，把实验性流行乐与冷战时期的忧虑融合在一起。 Kraftwerk 的经典阵容——Ralf Hütter 、 Florian Schneider 、 Karl Bartos 和 Wolfgang Flür——利用 Minimoog 合成器、 Vako Orchestron 等前沿设备，创造出既富未来感又带有不安氛围的声音。专辑以恐怖与美感交织的方式探讨放射性与信息时代的渗透问题，为这首歌后来被赋予政治意味奠定了基础。

到了 1990 年代，Kraftwerk 将 "Radioactivity" 重新塑造为一首明确的反核颂歌，最显著的是他们 1991 年的混音专辑 The Mix 。在这个版本中，原本颂扬性的基调被声码器主导的核灾难点名所取代，歌词点出了 Chernobyl 、 Harrisburg 、 Sellafield 和 Hiroshima 等事件。更新后的内容强调了核能的危险，把这首歌变成了抗议曲目，Kraftwerk 也在如 1992 年由 Greenpeace 组织的 Stop Sellafield 音乐会上演出过这一版本。尽管乐队通常保持神秘的公共形象，这一转变仍凸显了他们对当代政治议题的回应与参与。

此后数十年里，随着诸如 2011 年 Fukushima 事故等事件的发生，这首歌的相关性愈加凸显。 2012 年，Kraftwerk 在东京的 No Nukes 音乐会上演唱 "Radioactivity"，并将歌词扩展到包括 Fukushima，显示出这首歌对新危机的适应性。这种持续的演变证明了它既是音乐作品又是政治宣言的持久力量，能够与全球关注核安全和环境恶化的听众产生共鸣。

Kraftwerk 的影响远超 "Radioactivity" 本身，他们的作品启发了从嘻哈到 techno 等各类艺术家。乐队在电子声音运用和概念化创作上的创新使他们成为领域先驱。正如 The Human League 与 Heaven 17 的 Martyn Ware 所言："我们那个时期的许多艺术家，如果不是因为 Kraftwerk，就不会以现在的方式存在。"当代音乐人不断从他们的蓝图中汲取灵感，确保了 Kraftwerk 在数字时代依然具有重要影响力。

如今，"Radioactivity" 依然被各种风格的艺术家翻唱与再造，从 Fatboy Slim 的放克版本到 Haruomi Hosono 的乡村民谣式演绎不一而足。它在电影和电视剧原声中的出现也进一步巩固了其文化地位。正如 Nabihah Iqbal 所观察："令人惊叹的是，即使现在，你也能听出这些作品如何渗透到如此多样的音乐类型中。"对新一代而言，Kraftwerk 的音乐不仅是怀旧的遗产，更是塑造现代电子音乐的重要活力。

当世界在核能与环境问题上徘徊不定时，"Radioactivity" 既是对过去的深刻提醒，也是对未来的行动召唤。它从科学颂歌到抗议颂歌的转变，展示了 Kraftwerk 愿景的持久相关性。正如 Yin Yin 的 Kees Berkers 所说："真的难以置信，Radioactivity 是 50 年前发布的。那些高莫尔斯电码脉冲、半速电鼓和史诗般的合成贝斯，完全可以成为一首新的 vaporwave 曲目。"这种超越时代的特质注定使 Kraftwerk 的激进作品在未来多年继续激发思考与争论。 Kraftwerk's 1976 single "Radioactivity," from their album Radio-Activity, has evolved from a groundbreaking electronic track into a powerful anti-nuclear protest anthem over its 50-year history. The song, characterized by its pulsing Geiger counter sounds, escalating synths, and haunting spoken-word refrain, initially celebrated scientific innovation but later transformed into a critique of nuclear power. This shift reflects Kraftwerk's ability to adapt their music to contemporary issues, making "Radioactivity" a timeless piece that resonates with ongoing global concerns about nuclear energy and environmental safety.

The original Radio-Activity album, released in 1975, marked a significant moment in electronic music, blending experimental pop with Cold War-era anxieties. Kraftwerk's classic lineup—Ralf Hütter, Florian Schneider, Karl Bartos, and Wolfgang Flür—crafted a sound that was both futuristic and eerie, using innovative technology like the Minimoog synthesizer and Vako Orchestron. The album's themes of radioactivity and information age infiltration were presented with a mix of horror and beauty, setting the stage for the song's later political reinterpretation.

By the 1990s, Kraftwerk reimagined "Radioactivity" as an explicit anti-nuclear anthem, notably on their 1991 remix album The Mix. This version replaced the original's celebratory tone with a vocoder-led roll call of nuclear disasters, including Chernobyl, Harrisburg, Sellafield, and Hiroshima. The updated lyrics emphasized the dangers of nuclear power, turning the track into a protest song that Kraftwerk performed at events like the 1992 Stop Sellafield concert organized by Greenpeace. This transformation highlighted the band's engagement with contemporary political issues, despite their typically enigmatic public persona.

The song's relevance has only grown in the decades since, particularly in light of events like the 2011 Fukushima disaster. In 2012, Kraftwerk performed "Radioactivity" at the No Nukes concert in Tokyo, with lyrics expanded to include Fukushima, demonstrating the track's adaptability to new crises. This ongoing evolution underscores the song's enduring power as both a musical and political statement, resonating with audiences worldwide who are concerned about nuclear safety and environmental degradation.

Kraftwerk's influence extends far beyond "Radioactivity," as their work has inspired countless artists across genres, from hip-hop to techno. The band's innovative use of electronic sounds and conceptual approach to music has made them pioneers in the field. As Martyn Ware of The Human League and Heaven 17 notes, "Many of the artists from my period wouldn't have existed in the way that we do now, if it weren't for Kraftwerk." Their impact is evident in the way contemporary musicians continue to draw from their blueprint, ensuring that Kraftwerk's legacy remains vital in the digital age.

Today, "Radioactivity" continues to be covered and reinterpreted by artists in various styles, from Fatboy Slim's funk version to Haruomi Hosono's country-folk take. Its presence in film and television soundtracks further cements its cultural significance. As Nabihah Iqbal observes, "The amazing thing is that even now, you can hear how that work has gone on to permeate so many different types of music." For new generations, Kraftwerk's music is not just a nostalgic relic but a living influence that shapes the sound of modern electronic music.

As the world grapples with uncertainty over nuclear power and environmental issues, "Radioactivity" remains a poignant reminder of the past and a call to action for the future. Its ability to morph from a scientific hymn to a protest anthem demonstrates the enduring relevance of Kraftwerk's vision. As Kees Berkers of Yin Yin remarks, "It's really unbelievable that Radioactivity was released 50 years ago. With those high morse code pulses, half-tempo electro drums and epic synth bass, it could be a new vaporwave track." This timelessness ensures that Kraftwerk's radical track will continue to inspire and provoke thought for years to come.