2024 08 27 HackerNews

2024-08-27 Hacker News Top Stories #

  1. Telegram虽被称为加密消息应用, 但实际上默认并不启用端到端加密, 用户需手动开启“秘密聊天”功能, 且此功能不适用于群聊。
  2. Dokku 是一个开源的 PaaS 平台, 允许用户在自己的 VPS 上部署应用, 提供了类似于 Heroku 的便利性, 同时避免了高昂的费用。
  3. 1982年, 格蕾丝·霍普上尉在一场讲座中探讨了数据和计算机技术的未来发展, 强调了人类在技术进步中的重要性。
  4. 澳大利亚员工现在有权在下班后忽略工作邮件和电话, 这项政策旨在改善员工的工作与生活平衡。
  5. 一篇文章记录了作者作为首次贡献者修复 Google Chrome 中一个与 Chromium Devtools 和网络请求集成相关 bug 的全过程。
  6. 通过简化 Pinecone 公司的定价计算器, 移除了不必要的复杂性, 从而提高了用户体验和增长潜力。
  7. Dozer 是一个用纯 C 语言编写的 Rust 编译器项目, 目的是解决 Rust 编译器引导过程中的复杂性。
  8. UUID 有八个版本, 其中 v4 和 v7 最常用, v5 和 v8 在特定需求下使用。
  9. 荷兰数据保护局因优步将司机数据转移至美国未采取适当保护措施, 对其处以 2.9 亿欧元的罚款。
  10. “分片”这一术语可能源自于《乌尔图玛在线》这款游戏, 并在游戏中和数据库管理中得到了广泛应用。

Is Telegram really an encrypted messaging app? #

https://blog.cryptographyengineering.com/2024/08/25/telegram-is-not-really-an-encrypted-messaging-app/

这篇文章的作者是 Matthew Green，标题为《Telegram 真的算是一个加密消息应用吗？》。文章主要探讨了 Telegram 在加密消息传递方面的实际表现，尤其是其默认设置和用户体验。

主要内容摘要： #

  1. Telegram 的加密定义：

    • 文章指出，许多新闻报道将 Telegram 称为“加密消息应用”，这种说法在技术上并不完全错误，但在实际使用中却严重误导了用户。加密消息应用通常指的是默认启用端到端加密的应用，这样只有通信双方能够读取消息内容，而服务提供商无法访问。

  2. 缺乏默认加密：

    • Telegram 并不默认启用端到端加密。用户必须手动激活“秘密聊天”功能，且此功能仅适用于一对一的对话，无法用于群聊。这意味着大多数 Telegram 对话都是可见的，Telegram 服务器可以记录用户之间的所有消息内容。

  3. 用户体验问题：

    • 启用加密的过程对普通用户来说相当复杂，需要多次点击才能找到相关选项。即使启用了“秘密聊天”，如果对方不在线，用户也无法立即开始加密对话。

  4. 用户需求与隐私：

    • 虽然 Telegram 有许多用户可能并不在意隐私，使用它作为社交媒体平台，但许多用户在使用过程中可能会希望进行私密对话。文章认为，Telegram 的设计未能满足这些用户的隐私需求。

  5. Telegram 的市场宣传：

    • 尽管 Telegram 的加密功能受到批评，Telegram 的 CEO 仍然将其宣传为“安全的消息应用”，并对其他平台（如 Signal 和 WhatsApp）进行攻击，声称它们的加密协议不可信。这种宣传与 Telegram 自身的加密实现之间存在矛盾。

  6. 加密协议的技术细节：

    • Telegram 的“秘密聊天”功能使用了一种名为 MTProto 2.0 的自定义协议，尽管其加密算法在某些方面是安全的，但由于用户使用率低，实际效果受到限制。

  7. 元数据问题：

    • 文章最后提到，即使有端到端加密，用户的元数据（如谁在使用服务、与谁交谈等）仍然可能被收集和利用，这在隐私保护中是一个重要问题。

结论： #

作者认为，Telegram 在加密方面的表现与其宣传不符，用户在使用时应对其隐私保护能力保持谨慎。尽管 Telegram 提供了一些加密功能，但其复杂性和默认设置的缺失使得大多数用户可能并未真正享受到安全的通信体验。

HN 热度 563 points | 评论 542 comments | 作者：md224 | 1 day ago #

https://news.ycombinator.com/item?id=41350530

  • 有人认为 Telegram 的“泥坑测试”可以用来判断其是否真正具备端到端加密，但通过该测试并不意味着其没有后门。
  • 许多人对 Telegram 的信任表示怀疑，认为其数据隐私并不可靠，用户实际上是在信任 Telegram，而不是其加密技术。
  • 有评论指出，Telegram 在某些情况下可能会与国家机构合作，尤其是在俄罗斯等国家。
  • 也有人认为 Telegram 在某些方面比其他社交平台表现得更好，尤其是在用户信息的获取和内容审查方面。
  • 有人提到 Telegram 的隐私政策在某些情况下允许在法庭命令下交出用户信息，但不包括加密密钥。
  • 讨论中提到，Telegram 的设计使得其能够在多个设备上同步消息，但这可能会影响其安全性。
  • 有评论认为 Telegram 的加密技术存在设计缺陷，可能导致用户数据的安全性不足。
  • 还有人指出，Telegram 与其他应用相比，虽然声称提供安全性，但实际上并未实现真正的端到端加密。
  • 讨论中提到，Telegram 的云存储特性使得用户在不同设备上访问消息变得方便，但也带来了安全隐患。
  • 最后，有人提到 Telegram 的用户在使用时需要谨慎，尤其是在涉及敏感信息时。

Dokku: My favorite personal serverless platform #

https://hamel.dev/blog/posts/dokku/

这篇博客文章的标题是《Dokku: 我最喜欢的个人无服务器平台》，作者是 Hamel Husain，发表于 2024 年 1 月 9 日。文章主要介绍了 Dokku，一个开源的 PaaS（平台即服务），它可以在用户选择的单个服务器上运行，类似于 Heroku，但用户拥有自己的服务器。

主要内容摘要： #

  1. Dokku 简介：

    • Dokku 是一个开源的 PaaS，允许用户在自己的 VPS（虚拟专用服务器）上部署应用，避免了 Heroku 的高昂费用。
    • 作者使用 OVHcloud 的每月 7 美元的 VPS 来运行 Dokku，主要用于其 LLM（大语言模型）咨询工作。

  2. Dokku 的特点：

    • 易于使用，类似于 Heroku。
    • 自动 SSL 证书管理（通过 Let’s Encrypt）。
    • 支持基本身份验证，可以对网站进行密码保护。
    • 通过单个命令轻松扩展或缩减应用。
    • 灵活性强，支持多种应用（如 Node.js、Python 等），并可以定义 Docker 容器。
    • 提供大量官方插件，几乎可以满足所有需求。
    • 通过 git 命令轻松部署。

  3. Dokku 的基本示例：

    • 部署 Docker 容器应用：用户需要在 git 仓库根目录中放置 Dockerfile，并通过 Dokku 命令创建应用。
    • 部署静态网站：用户可以从私有 GitHub 仓库轻松部署静态网站，并进行密码保护。

  4. SSL/HTTPS 支持：

    • Dokku 提供 Let’s Encrypt 插件，简化 HTTPS 的设置，尽管作者选择让 Cloudflare 处理 SSL。

  5. 使用 GitHub Actions 自动部署：

    • 文章提供了一个示例 GitHub Action 工作流，展示如何自动部署 Dokku 应用，避免手动推送。

  6. 其他提示：

    • 文章还列出了一些常见的命令和技巧，例如如何远程运行命令、清除 Docker 缓存、以及如何在不推送的情况下重建应用。

总结： #

Dokku 是一个强大的工具，适合希望拥有自己服务器的开发者，提供了与 Heroku 类似的便利性，同时避免了高昂的费用。文章通过具体示例和实用技巧，帮助用户更好地理解和使用 Dokku。

HN 热度 542 points | 评论 189 comments | 作者：tosh | 9 hours ago #

https://news.ycombinator.com/item?id=41358020

  • 有用户分享了 Dokploy，认为其界面友好，易于部署 Docker/Compose 解决方案，并且内置了自动 LetsEncrypt 功能。
  • 一些评论认为在讨论特定工具时，提及其他工具是合适的，尤其是当主题是“最喜欢的个人无服务器平台”时。
  • 有人指出，Dokku 的使用体验良好，但在处理复杂性和故障恢复方面可能存在不足。
  • 讨论中提到 Dokku 的 HTTPS 支持和 LetsEncrypt 插件，使得 SSL 证书管理变得简单。
  • 有用户提到 Dokku 在单节点环境下的可靠性问题，认为在 VPS 崩溃时应用无法自动重启。
  • 有人对 Dokku 的“无服务器”称谓表示质疑，认为其实际上仍需在服务器上运行。
  • 讨论中提到 Dokku 与 Kubernetes 的比较，认为 Dokku 在简单性和易用性上有优势，但 Kubernetes 在扩展性和故障恢复上更强。
  • 有用户表示 Dokku 的开源特性和社区支持使其成为一个值得推荐的选择。
  • 也有用户提到 Dokku 在配置管理方面的不足，期望能有更好的配置文件支持。

NSA releases 1982 Grace Hopper lecture #

https://www.nsa.gov/helpful-links/nsa-foia/declassification-transparency-initiatives/historical-releases/view/article/3880193/capt-grace-hopper-on-future-possibilities-data-hardware-software-and-people-1982/

在 2024 年 8 月 26 日，美国国家安全局（NSA）发布了海军少将格蕾丝·霍普（Grace Hopper）于 1982 年 8 月 19 日为 NSA 员工所作的录像讲座《未来的可能性：数据、硬件、软件和人》。这场讲座强调了技术基础原则、领导力的宝贵视角以及在计算机科学和数学领域克服挑战的共同经验。

霍普在讲座中探讨了数据和计算机技术的未来发展，强调了人类在技术进步中的重要性。她的演讲不仅展示了技术的潜力，还鼓励女性在科学、技术、工程和数学（STEM）领域的参与。霍普的遗产在情报界继续发挥着重要作用，为女性在这些领域的职业发展指明了方向。

这场讲座的发布旨在促进对技术和领导力的理解，同时也为历史上的重要人物和他们的贡献提供了更广泛的认识。

HN 热度 533 points | 评论 128 comments | 作者：gaws | 11 hours ago #

https://news.ycombinator.com/item?id=41356528

  • 评论中提到，霍普的演讲强调了计算能力的扩展方式，提倡通过增加计算机数量而非单纯提升单台计算机的性能。
  • 有人提到，早期计算机界普遍相信计算能力与价格的平方成正比，但这种观点在微处理器时代并未持续。
  • 讨论中提到，历史上在运输重物时，使用多头牛而非单一更大牛的做法，反映了在计算中采用并行处理的必要性。
  • 一些评论指出，尽管并行处理在理论上有优势，但在实际应用中常常面临性能瓶颈。
  • 还有观点认为，选择合适的工具和方法取决于具体任务，单一的解决方案并不总是适用。
  • 许多评论者对霍普的演讲内容表示赞赏，认为其对计算机科学的影响深远，尤其是在标准化和模块化方面。
  • 讨论中提到，虽然并行处理有其优势，但在某些情况下，提升单台计算机的性能仍然是有效的策略。
  • 有人提到，技术的进步和创新往往是基于对现有资源的有效利用，而非单纯追求更高的性能。

Australian employees now have the right to ignore work emails, calls after hours #

https://www.reuters.com/world/asia-pacific/australian-employees-now-have-right-ignore-work-emails-calls-after-hours-2024-08-25/

根据最新报道，澳大利亚的员工在 2024 年将获得一项新权利，即在工作时间之外可以不必回复工作邮件和电话。这项政策旨在改善员工的工作与生活平衡，减少因工作而产生的压力和焦虑。

这一变化是由澳大利亚政府推动的，旨在回应员工对工作与生活平衡的日益关注。根据相关规定，雇主不得期望员工在下班后处理工作事务，员工有权在非工作时间内不回复工作相关的通讯。

此外，这项政策也反映了全球范围内对工作文化的重新审视，越来越多的企业和国家开始重视员工的心理健康和福祉。预计这一政策的实施将对澳大利亚的工作环境产生积极影响，促进员工的幸福感和生产力。

总之，澳大利亚的这一新规标志着对现代工作方式的重大转变，旨在为员工创造一个更加人性化的工作环境。

HN 热度 457 points | 评论 370 comments | 作者：testrun | 24 hours ago #

https://news.ycombinator.com/item?id=41352681

  • 澳大利亚员工现在有权在下班后忽略工作邮件和电话，这一政策反映了对工作与生活平衡的重视。
  • 一些管理者在经济困难时期可能会对员工施加压力，认为员工在找工作上面临困难，因此可以利用这一点。
  • 商业谈判中存在不道德行为，许多公司在价格上采取不诚实的策略。
  • 员工与管理者之间存在权力不平衡，管理者的行为可能导致员工感到被压迫。
  • 在某些情况下，绩效评估可能被用作掩盖种族歧视或个人偏见的工具。
  • 私募股权公司在许多行业中通过削减成本和资源来追求利润，导致公司和员工的困境。
  • 企业文化和管理风格会随着时间和领导层的变化而变化，影响员工的工作体验。
  • 在一些文化中，工作与生活的界限模糊，员工可能会感到必须在非工作时间继续工作。
  • 对于许多员工来说，保持工作稳定性和避免失业是他们不愿意反抗管理者行为的原因。

Fixing a bug in Google Chrome as a first-time contributor #

https://cprimozic.net/blog/fixing-a-bug-in-google-chrome/

这篇文章详细记录了作者作为首次贡献者修复 Google Chrome 中的一个 bug 的全过程，主要涉及 Chromium Devtools 与网络请求的集成问题。以下是内容的详细摘要：

1. 问题描述 #

作者修复的 bug 出现在 Chromium Devtools 中，具体是与通过工作线程（如 AudioWorklet）发起的网络请求的集成。Devtools 的网络标签页完全未显示这些请求，且“禁用缓存”选项未生效，导致开发过程中无法清除过时的代码。

2. 获取代码与构建 Chromium #

作者首先从头开始构建 Chromium，尽管系统要求较高，但通过详细的文档，作者在 Linux 上顺利完成了构建。构建过程耗时约 45 分钟，使用了大量内存和磁盘空间。

3. 查找 bug 与修复 #

在调试过程中，作者发现 Chromium 的代码库非常庞大，难以快速定位问题。通过追踪网络请求的调用树，作者发现工作线程的请求缺少 devtools_id_，并且没有为工作线程创建 InspectorNetworkAgent。最终，作者通过修改代码，使得 InspectorNetworkAgent 能够处理工作线程和工作器的请求。

4. 测试与代码审查 #

修复完成后，作者清理了调试日志，并提交了代码变更（CL）进行审查。作者在审查过程中选择了几位主要贡献者作为审查者，并在他们的指导下添加了测试用例，以验证修复的有效性。

5. 提交与发布 #

在经过几轮审查和测试后，作者的代码最终被合并到主代码库中。作者还需提交一个小的变更到 devtools_frontend 仓库，添加网络功能支持。最终，修复在 Chrome Canary 版本中发布，作者确认修复有效。

6. 结果与反思 #

作者对修复 bug 的过程感到满意，尽管耗时较长，但这次经历让他对 Chromium 的开发流程有了深入的了解，并激励他未来继续参与开源项目。

这篇文章不仅展示了修复 bug 的技术细节，还反映了开源贡献的挑战与成就感。

HN 热度 456 points | 评论 129 comments | 作者：Ameo | 15 hours ago #

https://news.ycombinator.com/item?id=41355303

  • 许多评论者对 Chromium 代码库的复杂性表示担忧，认为初次贡献者可能会感到困难。
  • 有人提到使用 Sublime Text 和 VS Code 等工具可以帮助导航代码，但在大型代码库中仍然存在性能问题。
  • 对于 Chromium 的命名问题，有人质疑 Google 是否在故意阻止分支的存在，认为这可能是维护者的选择。
  • 维护 Chromium 分支的成本被认为很高，尤其是需要强大的硬件和工程师。
  • 一些开发者分享了他们在维护个人分支时的经验，认为只要有动力，普通开发者也能处理。
  • 评论中提到，调试和阅读代码是不同的活动，调试工具可以帮助更好地理解代码。
  • 有人建议使用在线代码浏览器来浏览大型代码库，认为本地构建不够可靠。
  • 对于 Firefox 的构建过程，评论者认为相对较为模块化，适合初次贡献者。
  • 一些人分享了在开源项目中提交补丁的经历，强调了测试的重要性。
  • 讨论中提到，开源项目的贡献过程可能会面临沟通不畅的问题，尤其是在大型项目中。

Removing stuff is never obvious yet often better #

https://www.gkogan.co/removing-stuff/

这篇文章的标题是《Removing stuff is never obvious yet often better》，作者是 Greg Kogan，主要探讨了在产品、项目或公司中，简化复杂性的重要性。

文章开头提到，许多人在使用产品时常常感到复杂性过高，导致决策困难。Kogan 以 Pinecone 公司的定价计算器为例，讲述了一个关于复杂性的问题。最初，Pinecone 在其定价页面上设置了一个计算器，用户可以根据预期的使用模式估算费用。然而，用户反馈显示，计算器的估算结果往往过高，导致潜在客户因误解而不愿注册。

经过深入分析，Kogan 发现计算器的设计过于复杂，用户在输入时容易出错，甚至可能导致估算结果高达 1000 倍的偏差。尽管团队尝试通过添加说明和细节来解决问题，但反而增加了更多的混淆。最终，Kogan 提出了一个大胆的问题：“我们真的需要这个计算器吗？”虽然这个建议最初被忽视，但他决定进行 A/B 测试，看看如果去掉计算器会有什么影响。

测试结果显示，去掉计算器后，用户注册的可能性提高了 16%，联系公司的可能性提高了 90%，而关于定价的支持请求没有增加，表明用户的困惑减少了，满意度提高了。

Kogan 总结道，许多公司在面对复杂性时，往往倾向于通过增加功能来解决问题，而不是考虑去除不必要的部分。他指出，简化过程、去除非必要元素可以带来更好的用户体验和更高的增长潜力。文章鼓励读者反思当前面临的复杂问题，考虑是否可以通过去除某些部分来实现更好的结果。

总之，Kogan 强调，简化并不容易，但通过勇于质疑和去除复杂性，企业可以实现更高的效率和更好的客户体验。

HN 热度 431 points | 评论 184 comments | 作者：mooreds | 22 hours ago #

https://news.ycombinator.com/item?id=41353328

  • 有人认为隐藏产品价格信息可能会导致更多用户注册，但这并不意味着他们会满意，后续可能会面临不满的账单。
  • A/B 测试常常忽视长远影响，可能导致短期内的成功掩盖潜在问题。
  • 计算器的设计可能导致用户输入错误，从而产生不准确的报价，简化计算器可能是为了避免这种情况。
  • 一些评论者认为，计算器的复杂性可能是故意的，以便让用户在未完全了解价格时更容易注册。
  • 透明度与用户体验之间存在矛盾，过于简化可能会导致用户对价格的误解。
  • A/B 测试的结果并不总能反映用户的真实需求，可能需要更深入的分析。
  • 有人提到，设计应以用户为中心，而非仅仅追求转化率。
  • 讨论中提到，移除不必要的功能有时是明智的，但也需考虑未来可能的需求。
  • 一些评论者认为，过度依赖数据和测试可能导致忽视用户的真实体验和反馈。
  • 文章强调，去除多余的内容通常是有益的，但需要在设计时考虑用户的感受。

Writing a Rust compiler in C #

https://notgull.net/announcing-dozer/

这篇文章的标题为《为什么我要用 C 语言编写 Rust 编译器？》，作者是 John Nunley。文章主要介绍了他正在进行的一个开源项目，名为 Dozer，这是一个用纯 C 语言编写的 Rust 编译器。

主要内容摘要： #

  1. 项目背景：

    • 作者最近的生活经历导致他在开源社区的活动减少，包括亲人的去世和工作责任的增加。
    • 尽管如此，他仍在进行一个大型项目，即 Dozer，这是他在开源领域最大的项目。

  2. 编译器的必要性：

    • Rust 代码需要通过编译器（如 rustc）进行编译，rustc 本身是用 Rust 编写的，因此需要一个编译器来编译 rustc。
    • 文章探讨了编译器的引导过程（bootstrapping），即如何从一个简单的编译器逐步构建出复杂的编译器。

  3. 引导过程的复杂性：

    • 每个新版本的 rustc 都是用前一个版本编译的，最终追溯到最初的 OCaml 编写的编译器。
    • 文章提到，最终需要一个 C 编译器（如 GCC）来完成这个过程，而 GCC 在早期是用 C 编写的。

  4. Dozer 的目标：

    • Dozer 旨在创建一个可以从 C 语言引导的 Rust 编译器，特别是能够从 TinyCC（一个用 C 编写的编译器）引导。
    • 目前，Dozer 的开发已经完成了词法分析器和部分语法分析器，能够编译简单的 Rust 代码。

  5. 未来计划：

    • 作者计划逐步完善 Dozer，使其能够编译基本的 libc 示例、libcore 和 rustc。
    • 还计划创建一个类似 cargo 的工具，以便使用 Dozer 编译 Rust 包，并最终实现 rustc 和 cargo 的编译过程。

  6. 个人感受：

    • 作者对这个项目充满挑战和不确定性，但他认为尝试总比不尝试要好。

总结： #

Dozer 项目是一个雄心勃勃的尝试，旨在用 C 语言编写一个 Rust 编译器，解决 Rust 编译器引导过程中的复杂性。作者希望通过这个项目，能够为 Rust 的生态系统提供一个新的编译器选择。

HN 热度 374 points | 评论 207 comments | 作者：todsacerdoti | 1 day ago #

https://news.ycombinator.com/item?id=41351446

  • 有人建议先用 C 语言编写一个简化版的 Rust 编译器，然后再用这个简化版编写完整的 Rust 编译器。
  • 现有的 mrustc 编译器已经没有借用检查器，这并不会破坏正确的程序，但会让很多不正确的程序能够编译。
  • 一旦完成自举，可以重新编译编译器，加入借用检查和优化。
  • Rust 程序的用户如何判断二进制文件是用 mrustc 还是 rustc 编译的，通常假设大多数 Rust 二进制文件是用 rustc 编译的。
  • 编译器不需要功能完整，只需能生成更完整的二进制文件。
  • 有人提到在 Mozart/Oz 项目中，使用 Scala 编写了一个简化的编译器来编译真正的编译器。
  • 有人认为用 C 编写小编译器再用 Rust 编写大编译器比直接用 C 编写大编译器更简单。
  • Rust 编译器已经用 Rust 编写完成，讨论的重点在于如何简化自举过程。
  • 讨论中提到，Rust 的借用检查器使得编写程序变得更安全，但也让初学者感到困难。
  • 有人认为在 Rust 中编写非平凡程序比在 C 中更容易，尤其是使用 Cargo 和 Rust 库生态系统时。
  • 讨论了自举过程中的信任问题，强调从纯源代码构建的重要性，以避免潜在的安全问题。
  • 有人提到，编译器的自举过程可以通过简单的工具实现，逐步构建到更复杂的编译器。
  • 讨论中提到，编译器的自举过程不仅适用于软件，也适用于硬件，涉及到更广泛的技术构建问题。

TIL: Versions of UUID and when to use them #

https://ntietz.com/blog/til-uses-for-the-different-uuid-versions/

这篇博客文章讨论了不同版本的 UUID（通用唯一标识符）及其使用场景。UUID 有八个版本（v1 到 v8），每个版本都有其特定的生成方式和应用场景。

UUID 版本概述： #

  1. UUID 版本 1（v1）：基于时间戳、单调计数器和 MAC 地址生成。
  2. UUID 版本 2（v2）：保留用于安全 ID，具体细节不明。
  3. UUID 版本 3（v3）：基于提供的数据生成 MD5 哈希，RFC 建议使用 DNS 和 URL 作为数据来源。
  4. UUID 版本 4（v4）：完全随机生成，通常是人们最常遇到的 UUID 类型。
  5. UUID 版本 5（v5）：基于提供的数据生成 SHA1 哈希，RFC 同样建议使用 DNS 或 URL。
  6. UUID 版本 6（v6）：与 v1 相似，但改变了数据顺序，以便按创建时间排序。
  7. UUID 版本 7（v7）：基于时间戳和随机数据生成。
  8. UUID 版本 8（v8）：完全自定义，除了版本和变体字段外。

使用建议： #

  • v4：适合需要随机 ID 的场景，是一个良好的默认选择。
  • v7：适合需要排序的场景，例如作为数据库键时。
  • v5 或 v8：当需要将特定数据包含在 UUID 中时使用。

其他版本的使用情况： #

  • v1 和 v6：通常不推荐使用 v1，v6 可以作为替代。
  • v2：用于未指定的安全用途，通常不适合普通使用。
  • v3：已被 v5 取代，后者使用更强的哈希算法。

总的来说，选择 UUID 版本时，v4 和 v7 是最常用的，而 v5 和 v8 则在特定需求下使用。

HN 热度 295 points | 评论 108 comments | 作者：fagnerbrack | 1 day ago #

https://news.ycombinator.com/item?id=41350225

  • UUID v2 主要用于安全 ID，但其定义不够清晰，很多人对其理解存在误区。
  • UUID v7 的时间戳特性对数据管理非常有帮助，尤其是在云存储中。
  • 有人希望有一种短 UUID 标准，便于记忆和使用。
  • ULID 被认为是一个不错的替代方案，因为它短且可排序。
  • UUID 的不同版本有不同的用途，使用时需考虑具体场景。
  • UUID 的生成方式可以影响其唯一性和安全性，需谨慎选择。
  • 在分布式系统中，UUID 可以避免重复生成 ID 的问题。
  • 对于需要可重复生成的 ID，UUID v5 可以通过哈希实现。
  • UUID 的标准化使得不同系统间的兼容性得以保障。
  • 使用 UUID 时，需注意其表示形式和生成方式对可读性的影响。

Dutch DPA fines Uber €290M because of transfers of drivers’ data to the US #

https://www.autoriteitpersoonsgegevens.nl/en/current/dutch-dpa-imposes-a-fine-of-290-million-euro-on-uber-because-of-transfers-of-drivers-data-to-the-us

荷兰数据保护局（Dutch DPA）对优步（Uber）处以 2.9 亿欧元的罚款，原因是该公司将欧洲出租车司机的个人数据转移至美国，并未采取适当的保护措施。这一行为被认定为严重违反了《通用数据保护条例》（GDPR）。

根据荷兰数据保护局的主席阿莱德·沃尔夫森（Aleid Wolfsen）的说法，GDPR 旨在保护个人的基本权利，要求企业和政府妥善处理个人数据。然而，沃尔夫森指出，在欧洲以外的地区，这并非自然而然的事情，尤其是一些政府可能会大规模获取数据。因此，企业在将欧洲人的个人数据存储在欧盟以外的地方时，通常需要采取额外措施。

荷兰数据保护局发现，优步收集了包括账户信息、出租车执照、位置信息、照片、支付信息、身份证明文件，甚至部分司机的犯罪和医疗数据等敏感信息，并将这些数据保留在美国的服务器上。优步在超过两年的时间里将这些数据转移至美国总部，且未使用任何数据转移工具，导致个人数据的保护不足。

2020 年，欧盟法院宣布无效欧盟-美国隐私保护协议（Privacy Shield），并指出标准合同条款（Standard Contractual Clauses）仍可作为数据转移的有效基础，但前提是必须在实践中保证相应的保护水平。自 2021 年 8 月起，优步未再使用标准合同条款，导致其对欧洲司机的数据保护不足。

此次调查始于 170 多名法国司机向人权组织“人权联盟”（Ligue des droits de l’Homme）投诉，该组织随后向法国数据保护局提出了投诉。荷兰数据保护局与法国数据保护局密切合作，并与其他欧洲数据保护局协调了此次决定。

根据 GDPR，企业在多个欧盟成员国处理数据时，需向一个数据保护机构报告，该机构为企业主要设立国的监管机构。优步的欧洲总部位于荷兰。

此次罚款是荷兰数据保护局对优步的第三次处罚，之前在 2018 年和 2023 年分别对优步处以 60 万欧元和 1000 万欧元的罚款。优步已表示将对这次罚款提出异议。

HN 热度 289 points | 评论 376 comments | 作者：the-dude | 16 hours ago #

https://news.ycombinator.com/item?id=41355021

  • 荷兰数据保护局对 Uber 处以 2.9 亿欧元的罚款，主要是因为其将司机数据转移到美国。
  • 数据存储的物理位置对隐私和数据保护至关重要，不同国家的法律可能存在差异。
  • 美国需要更严格的数据保护法律，以保护用户隐私。
  • 数据的物理位置影响法律适用性，尤其是在跨国数据传输时。
  • 欧盟允许将数据传输到其他国家，但前提是这些国家的数据保护标准与欧盟相当。
  • 美国的 Cloud Act 使得美国云服务提供商必须遵循政府的数据访问请求，这对欧盟的数据保护构成威胁。
  • 数据泄露和滥用的风险使得企业必须确保数据存储在法律保护更强的地区。
  • 欧盟的 GDPR 法律要求企业在处理公民数据时遵循严格的规定，违反者将面临高额罚款。
  • 对于美国公司而言，遵守欧盟的隐私法律可能会面临法律和合规的复杂性。
  • 许多国家已经实施数据驻留法律，要求公民的个人数据不得离开本国。
  • 数据的流动性使得物理位置的法律保护显得尤为重要，尤其是在全球化的背景下。
  • 欧盟对美国公司的监管力度较大，反映出对数据隐私的重视。

Database “sharding” came from Ultima Online? (2009) #

https://www.raphkoster.com/2009/01/08/database-sharding-came-from-uo/

这篇文章的标题是《数据库“分片”来自于《乌尔图玛在线》吗？》，作者 Raph Koster 探讨了“分片”这一术语的起源及其在数据库可扩展性中的应用。

文章首先介绍了“分片”这一术语的含义，即通过运行多个并行数据库来管理数据，而不是将所有数据压缩到一个数据库中。作者提到，虽然“分片”这个词在技术界逐渐流行，但其确切来源并不明确，似乎与一些早期的社交网络（如 Friendster 和 Flickr）有关。

接着，Koster 回忆起 Flickr 最初是作为一款名为“Game Neverending”的 MMO（大型多人在线游戏）开发的。他提到自己曾被邀请作为顾问，但因与索尼的合同未能成行。他认为在这些开发团队中，“shard”这个词很可能已经被提及，因为在 MMO 中，“shard”有着特定的含义，指的是数据库的分区。

Koster 进一步解释了“shard”一词的具体来源。他提到，在开发《乌尔图玛在线》时，团队意识到需要为用户提供多个完整的游戏副本，因此创造了一个虚构的背景故事来解释这些副本的存在。这个故事涉及到一个邪恶的巫师 Mondain，他试图通过一个水晶控制游戏世界 Sosaria。当玩家击败他并打破水晶时，水晶的碎片便成为了不同的游戏副本。

文章最后，Koster 表示，虽然“shard”这个术语在 90 年代的 MMO 开发中被偶尔使用，但并未成为普遍的行业术语。他对“分片”一词是否真的源于他 1996 年写的一份文档表示怀疑，但认为这确实是一个有趣的巧合。

总体而言，文章探讨了“分片”这一术语的起源及其在游戏和数据库管理中的演变，强调了虚构故事在游戏设计中的重要性。

HN 热度 280 points | 评论 120 comments | 作者：fanf2 | 1 day ago #

https://news.ycombinator.com/item?id=41351219

  • 对于“sharding”一词的起源，评论者们认为可能源于《Ultima Online》，但也有观点认为该技术早在 90 年代就已存在。
  • 有人提到，许多创新来自 MMO 游戏，因此不应感到惊讶，尤其是大型 MMO 推动了技术的前沿。
  • 评论中提到，Flickr 和 Slack 的创始团队曾尝试开发 MMO，但最终转向了其他项目。
  • 讨论中提到，数据库分区（partitioning）早已存在，而“sharding”可能只是一个新的术语。
  • 有评论者分享了他们在早期游戏开发中的经验，强调了游戏对技术发展的影响。
  • 一些评论者认为，尽管“sharding”在《Ultima Online》中被命名，但其背后的技术概念早已被其他系统使用。
  • 还有人提到，游戏设计师 Raph Koster 在游戏设计理论方面的贡献，认为他是该领域的重要人物。
  • 有人提到，现代游戏与《Ultima Online》相比，缺乏相同的社交体验和玩家驱动的虚拟社会。