这 12 项基本原则能够帮助团队快速高效地构建高度可扩展的应用程序

12-Factor 应用方法论 为在短时间内构建应用程序并使其具有可扩展性提供了指导。它由 Heroku 的开发人员创建，用于软件即服务（SaaS）应用程序、网络应用程序以及可能的通信平台即服务（CPaaS）。在有效组织项目和管理可扩展应用程序方面，12 要素应用程序方法论对开源开发具有强大的优势。

12-Factor 应用方法论的原则

12-Factor 应用方法论的规则非常严格，也是开发和部署 SaaS 应用程序的基石，并且不受任何编程语言或数据库的限制。

1：一份基准代码，多份部署

每个应用程序都应该有一个具有多个不同环境/部署的代码库。

开发人员不应仅仅为了在不同环境中设置而开发另一个代码库。不同的环境代表不同的状态，但这些不同的环境应该共享同一个代码库。

在许多开源项目都存储在 GitLab 这样的版本控制系统中的情况下，一个环境可以被视为一个分支。例如，你可以在任何中央版本控制系统中为名为 VoIP-app 的云 VoIP 应用程序创建一个单独的存储库，然后创建两个分支：开发分支（development）和暂存分支（staging），并将主分支（master）作为发布分支。

2：明确声明和隔离依赖关系

应声明所有依赖关系。你的应用程序可能会依赖外部系统工具或库，但不应对系统工具或库有任何 隐含的 依赖。你的应用程序必须始终明确声明所有依赖关系及其正确版本。

在代码库中包含依赖关系可能会产生问题，特别是在开源项目中，外部库的更改可能会将错误引入代码库。例如，代码库可能会使用一个外部库，但没有明确声明该依赖关系或版本。如果外部库更新到更新的、未经测试的版本，这可能会与你的代码产生兼容性问题。如果明确声明了依赖关系及其正确版本，你的代码库就不会出现这种问题。

根据技术栈的不同，最好使用软件包管理器，通过读取代表依赖库名称和版本的依赖库声明清单，在各自的系统上下载依赖库。

3：在环境中存储配置

当需要支持多个环境或客户端时，配置就成了应用程序的重要组成部分。不同部署之间的配置应存储在环境变量中。这样就可以在部署之间轻松更改配置，而无需更改代码。

对于闭源应用程序来说，这一原则是有益的，因为你不会希望数据库连接信息或其他秘密数据等敏感信息被公开。然而，在开放源代码开发中，这些细节都是公开的。在这种情况下，好处是你不需要反复修改代码。你只需这样设置变量，只需改变环境，就能让代码完美运行。

4：把后端服务当作附加资源

所有后备服务（如数据库、外部存储或消息队列）都被视为附加资源，由执行环境附加或分离。根据这一原则，如果这些服务的位置或连接细节发生变化，仍无需更改代码。这些细节可以在配置中找到。

备份服务可以从部署中快速附加或分离。例如，如果基于云的电子表格的数据库无法正常工作，开发人员应该能够创建一个从最近备份恢复的新数据库服务器，而无需对代码库进行任何更改。

5：严格分离构建和运行

12-Factor 应用方法论要求严格区分构建、发布和运行阶段。

• 第一阶段是 构建 阶段。在这一阶段，源代码被组装或编译成可执行文件，同时加载依赖关系并创建资产。每次需要部署新代码时，构建阶段就会开始。
• 第二阶段是 发布 阶段。在此阶段，构建阶段生成的代码与部署的当前配置相结合。最终发布的版本包含构建和配置，可在执行环境中立即执行。
• 第三个阶段是 运行 阶段，也是最后阶段：应用程序在执行环境中运行。该阶段不应被其他任何阶段打断。

通过严格区分这些阶段，我们可以避免代码中断，使系统维护更加易于管理。

6：以一个或多个无状态进程运行应用

应用程序作为一个或多个进程的集合在执行环境中执行。这些进程是无状态的，其持久化数据存储在数据库等后台服务中。

这对开源非常有用，因为使用某版本应用程序的开发人员可以在其云平台上创建多节点部署，以实现可扩展性。数据不会在其中持久化，因为如果其中任何一个节点崩溃，数据就会丢失。

7：通过端口绑定提供服务

你的应用程序应作为独立的服务，独立于其他应用程序。它它应该能通过URL供其他服务访问，以服务形式存在。这样，你的应用程序就可以在需要时作为其他应用程序的资源。利用这一概念，你可以构建 REST API。

8：通过进程模型进行扩展

该原则也称为并发原则，它表明应用程序中的每个进程都应能够自我扩展、重启或克隆。

开发人员可以创建多个进程，并将应用程序的负载分配给这些进程，而不是将一个进程变大。通过这种方法，你可以将每种工作负载分配给一个进程类型，从而构建能处理不同工作负载的应用程序。

9：快速启动和优雅终止以增强健壮性

你的应用应当基于简单的进程构建，因此开发者可以放大进程的同时还能在发生问题时重启它们。这使得应用的进程易于丢弃。

根据这一原则构建应用程序意味着代码的快速部署、快速弹性扩展、更灵活的发布流程以及稳健的生产部署。所有这些在开源开发环境中都非常有用。

10：尽可能的保持开发、预发布、生产环境相同

同一项目的团队应使用相同的操作系统、支持服务和依赖关系。这样可以降低出现错误的可能性，减少开发所需的时间。

由于开源项目的开发人员分散在各地，他们可能无法就所使用的系统、服务和依赖关系进行 沟通 ，因此将这一原则付诸实践对于开源项目来说可能是一个挑战。减少这些差异的一种可能性是制定开发指南，建议使用何种操作系统、服务和依赖关系。

11：把日志当作事件流

日志对于排除生产问题或了解用户行为至关重要。但是，12-Factor 应用方法论并不适合处理日志的管理。

相反，应将日志条目作为事件流，写入标准输出，并将其发送到单独的服务进行分析和存档。机器人流程自动化（RPA）技术可作为处理和分析日志的第三方服务。执行环境将决定如何处理该数据流。这为反省应用程序的行为提供了更大的灵活性和能力。

12：后台管理任务当作一次性进程运行

这一原则实际上与开发无关，而是与应用程序管理有关。管理进程应在与应用程序常规长期运行进程相同的环境中运行。在本地部署中，开发人员可以直接使用应用程序签出目录内的 Shell 命令来执行一次性管理进程。

结论

使用 12-Factor 应用方法论开发应用程序，可以提高效率，加快发布速度。在开源开发中，偏离某些指导原则可能是有意义的，但最好还是尽可能严格遵守这些指导原则。

开源的 12-Factor 应用是可能的。一个很好的例子是 Jitsi, （一个开源视频会议平台）, 在疫情期间扩展了 100 倍的规模，取得了巨大成功，它就是采用 12-Factor 应用方法论构建的。

（题图：MJ/4bc8b463-49d0-4702-8ad3-6a07a718d5d9）

via: https://opensource.com/article/21/11/open-source-12-factor-app-methodology

作者：Richard Conn 选题：lujun9972 译者：trisbestever 校对：wxy

本文由 LCTT 原创编译，Linux中国 荣誉推出

当然，如果你真的关注性能，市面上自然有更出色的选择。

今年是 TOP500 公开排名全球最快超级计算机 30 周年。

为纪念这个重要的里程碑，也因应科罗拉多州正在举行的年度超级计算大会，我们想弄个有趣但稍显愚蠢的实验：看看以今天技术，我们能以多低的成本重现 1993 年超级计算机十强的性能。于是，我们在云上运行了几台虚拟机，并对 HPLinpack 基准进行了编译测试。这里简单透露一下：我们这项实验的结果，你可能并不会太震惊。

到 1993 年年末，最快的超级计算机是日本国家航空实验室的富士通数值风洞。这台装备了 140 个 CPU 核心的系统，能够实现 124 GigaFLOPS 的双精度（FP64）计算能力。

如今，我们的系统已经 突破 了 exaFLOPS 的难关，然而在 1993 年 11 月，如何在功率最高的十个系统中占据一席之地呢？只要你的 FP64 性能超过了美国 CM-5/544 机型的 15.1 GigaFLOPS。因此，我们设定的目标是让云虚拟机超过 15 GigaFLOPS 的性能。

在我们分析结果之前，有几点值得一提。如果我们选用了支持 GPU 的实例，我们知道我们能够达到更高的性能。不过，云端的 GPU 实例租赁并不便宜，并且在 2000 年年中至年底，GPU 才真正开始广泛出现在 TOP500 的超级计算机中。此外，在 CPU 上运行 Linpack 比在 GPU 上运行要容易得多。

这些测试只是为了纪念 30 周年，只是稍微有点新颖，决不具有科学严谨或详尽无遗的特征。

一台 5 美元的云虚拟机对比一部 30 年前的 TOP500 超级计算机

但在开始测试前，我们需要开启一对 VPC。在本次测试中，我们选择在 Vultr 上运行 Linpack，但其实在 AWS，Google Cloud，Azure，Digital Ocean 或者是你喜欢的任何云服务商上，这都同样适用。

首先，我们启动了一个月费 5 美元的虚拟机实例，它具备了一个共享的 vCPU，1GB 的内存和 25GB 的存储。准备就绪后，我们便启动了 Linpack 的编译。

在这，事情可能会有些复杂，因为我们实际上可以对系统进行一些调优，挤出一些额外的 FLOPS。然而，考虑到这只是一个测试，也为了尽可能保持简单，我们选择了依照 这个指南 进行操作。此份操作手册是基于 Ubuntu 18.04 编写的，但是我们发现在 20.04 LTS 上运行也一切正常。

为了产生我们的 HPL.dat 文件，我们利用了一个巧妙的 表单，它会自动产生一个优化版的 Linpack 运行配置。

我们对几种不同类型的虚拟机进行了三次基准测试，并从每次运行中挑选出最高的得分。以下就是我们的发现：

从我们的测试结果可以看出，一个单一的共享 vCPU 在与 1993 年 11 月十大超级计算机的比较中表现出颇为出色的性能。

我们通过一个 CPU 线程就获得了 31.21 GigaFLOPS 的 FP64 性能，这使得我们的虚拟机与 1993 年排名第三的超级计算机 —— 明尼苏达超级计算中心的 30.4 GigaFLOPS CM-5/554 Thinking Machines 系统相提并论。这确实令人吃惊，因为那台系统拥有 544 个 SuperSPARC 处理器，而我们的系统只有一个 CPU 线程，虽然我们的系统运行在更高的时钟速度下。

如你从上面的图表中所见，每月多花 1 美元，我们的性能跃升至 51.85 GigaFLOPS，而选择一个价值 18 美元的“高级”共享 CPU 实例，双线程使我们进一步接近 87.46 GigaFLOPS 的性能。

然而，要超过 富士通的数值风洞，我们需要升级到四个 vCPU 的虚拟机，由此我们抓取到了 133 GigaFLOPS 的 FP64 性能。然而不幸的是，升级到四个线程的费用跳到了每月 48 美元。达到这个价格，Vultr 实际上是在销售部分 GPU，我们预计如果采用 GPU，性能应会有显著提升，效率也会更高。

更好的选择

我们需要明确的是，这些都是我们选择的共享类型实例。一般来说，共享实例意味着在一定程度上进行了超额配置。

由于共享实例可能会受到其他租户的影响，这也使得性能有时难以预知，甚至每次运行的性能都可能略有不同，这主要取决于云区域中主机系统的载荷状态。

在我们的非常不科学的测试中，我们并未观察到太多的性能变化。我们想这可能是因为核心并未处在过高的负载下。在专有 CPU 实例上进行同样的测试，结果与我们每月 6 美元的共享实例相若，但成本高达五倍。

但是，除了这场小实验的新奇趣味之外，这没太多实际意义。如果你需要在短时间内获得大量 FLOPS，有许多已优化的 CPU 和 GPU 实例可供选择。它们的成本无法与每月 5 美元的实例相媲美，然而大多数实例是按小时账单的，因此实际成本将取决于你完成工作的迅速程度。

此外，让我们不要忘记，你的智能手机与这些存在已久的 30 年老计算系统相比，又会有怎样的对比呢？

（题图：MJ/16cf957e-a4e4-43b1-99b2-df0574a064dc）

via: https://www.theregister.com/2023/11/14/five_dollar_supercomputer/

作者：Tobias Mann 译者：ChatGPT 校对：wxy

每月 5 美元的虚拟机性能超过了 30 年前的第三快的超算

今年是全球公开的最快超级计算机 TOP500 排行榜发布 30 周年。1993 年，当时的超算榜首是位于日本国家航空航天实验室的富士通数值风洞，该系统拥有多达 140 个 CPU 内核，可实现 124 gigaFLOPS 的双精度性能。有人做了一个有趣的测试，结果表明，每月只需要 5 美元的单个 vCPU 线程的虚拟机可以与 1993 年排名第三的超级计算机明尼苏达超级计算中心相抗衡，而该系统拥有 544 个 SuperSPARC 处理器。如果升级到 4 个 vCPU 虚拟机，就可以击败当年的榜首，每个月仅需要花费 48 美元。

消息来源：The Register

老王点评：不算意外，只是有些吃惊。不敢想象三十年后计算机能强大到什么程度，或许地球会爆炸吧。

Canonical 发布快速部署全功能私有云的 MicroCloud

Canonical 公司今天发布了最新的软件产品 MicroCloud，它的目标是在 Ubuntu Linux 上轻松部署一个 “几分钟内就能实现全功能云” 的私有云。他们宣传自己的私有云部署就像使用 Snap 命令一样简单。其代码以 AGPL-3.0 许可托管在 GitHub 上。据介绍，MicroCloud 至少需要三台机器，目前可扩展到 50 台机器。

消息来源：Phoronix

老王点评：现在看起来，私有云有公有云不可比拟的好处，最起码重启起来比较快~

DeepMind 能更快更准确地预测极端天气

根据一份研究，谷歌 DeepMind 的模型 GraphCast 能够提前 10 天预测天气状况，比目前的黄金标准更准确、更快速。在 1300 多个测试区域中，GraphCast 在 90% 以上的测试中都优于欧洲中期天气预报中心的模型。最重要的是，GraphCast 还能比标准模型更早地为气象学家提供有关极端气温和气旋路径等情况的准确预警。GraphCast 使用图神经网络，将地球表面映射成 100 多万个网格点。它不使用物理方程，而是根据四十年的历史天气数据进行预测，可以利用机器学习在一分钟内完成这些计算。

消息来源：Technology Review

老王点评：没想到不是超算，而是人工智能拯救了天气预测难题。

今天的帖子来自于最近的 Go 语言的一次小测试，观察下面的测试基础片段 ^[1] ：

func BenchmarkSortStrings(b *testing.B) {
        s := []string{"heart", "lungs", "brain", "kidneys", "pancreas"}
        b.ReportAllocs()
        for i := 0; i < b.N; i++ {
                sort.Strings(s)
        }
}

sort.Strings 是 sort.StringSlice(s) 的便捷包装器，sort.Strings 在原地对输入进行排序，因此不会分配内存（或至少 43% 回答此问题的 Twitter 用户是这么认为的）。然而，至少在 Go 的最近版本中，基准测试的每次迭代都会导致一次堆分配。为什么会是这种情况？

正如所有 Go 程序员应该知道的那样，接口是以 双词结构 实现的。每个接口值包含一个字段，其中保存接口内容的类型，以及指向接口内容的指针。 ^[2]

在 Go 语言伪代码中，一个接口可能是这样的：

type interface struct {
        // the ordinal number for the type of the value
        // assigned to the interface 
        type uintptr

        // (usually) a pointer to the value assigned to
        // the interface
        data uintptr
}

interface.data 可以容纳一个机器字（在大多数情况下为 8 个字节），但一个 []string 却需要 24 个字节：一个字用于指向切片的底层数组；一个字用于存储切片的长度；另一个字用于存储底层数组的剩余容量。那么，Go 是如何将 24 个字节装入个 8 个字节的呢？通过编程中最古老的技巧，即间接引用。一个 []string，即 s，需要 24 个字节；但 *[]string —— 即指向字符串切片的指针，只需要 8 个字节。

逃逸到堆

为了让示例更加明确，以下是重新编写的基准测试，不使用 sort.Strings 辅助函数：

func BenchmarkSortStrings(b *testing.B) {
        s := []string{"heart", "lungs", "brain", "kidneys", "pancreas"}
        b.ReportAllocs()
        for i := 0; i < b.N; i++ {
                var ss sort.StringSlice = s
                var si sort.Interface = ss // allocation
                sort.Sort(si)
        }
}

为了让接口正常运行，编译器将赋值重写为 var si sort.Interface = &ss，即 ss 的地址分配给接口值。 ^[3] 我们现在有这么一种情况：出现一个持有指向 ss 的指针的接口值。它指向哪里？还有 ss 存储在哪个内存位置？

似乎 ss 被移动到了堆上，这也同时导致了基准测试报告中的分配：

Total:    296.01MB   296.01MB (flat, cum) 99.66%
      8            .          .           func BenchmarkSortStrings(b *testing.B) { 
      9            .          .               s := []string{"heart", "lungs", "brain", "kidneys", "pancreas"} 
     10            .          .               b.ReportAllocs() 
     11            .          .               for i := 0; i < b.N; i++ { 
     12            .          .                   var ss sort.StringSlice = s 
     13     296.01MB   296.01MB                   var si sort.Interface = ss // allocation 
     14            .          .                   sort.Sort(si) 
     15            .          .               } 
     16            .          .           } 

发生这种分配是因为编译器当前无法确认 ss 比 si 生存期更长。Go 编译器开发人员对此的普遍态度是，觉得 这个问题改进的余地，不过我们另找时间再议。事实上，ss 就是被分配到了堆上。因此，问题变成了：每次迭代会分配多少个字节？为什么不去询问 testing 包呢？

% go test -bench=. sort_test.go
goos: darwin
goarch: amd64
cpu: Intel(R) Core(TM) i7-5650U CPU @ 2.20GHz
BenchmarkSortStrings-4          12591951                91.36 ns/op           24 B/op          1 allocs/op
PASS
ok      command-line-arguments  1.260s

可以看到，在 amd 64 平台的 Go 1.16 beta1 版本上，每次操作会分配 24 字节。 ^[4] 然而，在同一平台先前的 Go 版本中，每次操作则消耗了 32 字节。

% go1.15 test -bench=. sort_test.go
goos: darwin
goarch: amd64
BenchmarkSortStrings-4          11453016                96.4 ns/op            32 B/op          1 allocs/op
PASS
ok      command-line-arguments  1.225s

这引出了本文的主题，即 Go 1.16 版本中即将推出的一项便利改进。不过在讨论这个内容之前，我需要聊聊 “ 尺寸类别 size class ”。

尺寸类别

在解释什么是 “ 尺寸类别 size class ” 之前，我们先考虑个问题，理论上的 Go 语言在运行时是如何在其堆上分配 24 字节的。有一个简单的方法：追踪目前为止已分配到的所有内存的动向——利用指向堆上最后分配的字节的指针。分配 24 字节，堆指针就会增加 24，然后将前一个值返回给调用函数。只要写入的请求 24 字节的代码不超出该标记的范围，这种机制就没有额外开销。不过，现实情况下，内存分配器不仅要分配内存，有时还得释放内存。

最终，Go 语言程序在运行时将释放这些 24 字节，但从运行的视角来看，它只知道它给调用者的开始地址。它不知道从该地址起始之后又分配了多少字节。为了允许释放内存，我们假设的 Go 语言程序运行时分配器必须记录堆上每个分配的长度值。那么这些长度值的分配存储在何处？当然是在堆上。

在我们的设想中，当程序运行需要分配内存的时候，它可以请求稍微多一点，并把它用来存储请求的数量。而对于我们的切片示例而言，当我们请求 24 字节时，实际上会消耗 24 字节加上存储数字 24 的一些开销。这些开销有多大？事实上，实际上的最小开销量是一个字。 ^[5]

用来记录 24 字节分配的开销将是 8 字节。25% 不是很大，但也不算糟糕，随着分配的大小增加，开销将变得微不足道。然而，如果我们只想在堆上存储一个字节，会发生什么？开销将是请求数据量的 8 倍！是否有一种更高效的方式在堆上分配少量内存？

与其在每个分配旁边存储长度，不如将相同大小的内容存储在一起，这个主意如何？如果所有的 24 字节的内容都存储在一起，那么运行时会自动获取它们的大小。运行时所需要的是一个单一的位，指示 24 字节区域是否在使用中。在 Go 语言中，这些区域被称为 Size Classes，因为相同大小的所有内容都会存储在一起（类似学校班级，所有学生都按同一年级分班，而不是 C++ 中的类）。当运行时需要分配少量内存时，它会使用能够容纳该分配的最小的尺寸类别。

无限制的尺寸类别

现在我们知道尺寸类别是如何工作的了，那么问题又来了，它们存储在哪里？和我们想的一样，尺寸类别的内存来自堆。为了最小化开销，运行时会从堆上分配较大的内存块（通常是系统页面大小的倍数），然后将该空间用于单个大小的分配。不过，这里存在一个问题————

将大块区域用于存储同一大小的事物的模式很好用 ^[6] ，如果分配大小的数量是固定的，最好是少数几个。那么在通用语言中，程序可以要求运行时以任何大小分配内存 ^[7] 。

例如，想象一下向运行时请求 9 字节。9 字节是一个不常见的大小，因此可能需要一个新的尺寸类别来存储 9 字节大小的物品。因为 9 字节大小的物品不常见，所以分配的其余部分（通常为 4KB 或更多）可能会被浪费。由于尺寸类别的集合是固定的，如果没有精确匹配的 size class 可用，分配将并入到下一个尺寸类别。在我们的示例中，9 字节可能会在 12 字节的尺寸类别中分配。未使用的 3 字节的开销要比几乎未使用的整个尺寸类别分配好。

总结一下

这是谜题的最后一块拼图。Go 1.15 版本没有 24 字节的尺寸类别，因此 ss 的堆分配是在 32 字节的尺寸类别中分配的。由于 Martin Möhrmann 的工作，Go 1.16 版本有一个 24 字节的尺寸类别，非常适合分配给接口的切片值。

相关文章

1. 我在 Devfest 2017年西伯利亚大会谈 Go 语言
2. 如果对齐的内存写操作是原子性的，为什么我们还需要 sync/atomic 包呢？
3. 为你的树莓派创建一个真实的串行控制台
4. 为什么 Go 语言线程的栈是无限制的？

（题图：MJ/01d5fe46-778f-48fe-9481-162f4d0289dc）

1. 这不是正确的对排序函数进行基准测试的方式，因为在第一次迭代之后，输入已经排序。但这又是另外一个话题了。 ↩︎
2. 此语句的准确性取决于所使用的 Go 版本。例如，Go 1.15 版本添加了直接将一些 整数存储在接口值 中的功能，从而节省了分配和间接性。然而，对于大多数值来说，如果它不是指针类型，它的地址将被取出并存储在接口值中。 ↩︎
3. 编译器在接口值的类型字段中跟踪了这种手法，因此它记住了分配给 si 的类型是 sort.StringSlice 而不是 *sort.StringSlice。 ↩︎
4. 在 32 位平台上，这个数字减半，但我们不再关注它。 ↩︎
5. 如果你准备限制分配为 4G 或者可能是 64KB，你可以使用较少内存来存储分配的尺寸，但实际上使用小于一个字来存储长度标头的节省会受到填充的影响。 ↩︎
6. 将相同大小的物品存储在一起也是一种有效的对抗碎片化的策略。 ↩︎
7. 这并不是一个不切实际的设想，字符串有各种形状和大小，生成以前未见过的大小的字符串可能就像附加空格一样简单。 ↩︎

via: https://dave.cheney.net/2021/01/05/a-few-bytes-here-a-few-there-pretty-soon-youre-talking-real-memory

作者：Dave Cheney 选题：lujun9972 译者：Drwhooooo 校对：wxy

本文由 LCTT 原创编译，Linux中国 荣誉推出

宇宙射线可以导致 SSH 私钥被窃取

研究人员发现，可以观察到 SSH 签名生成过程中意外或自然发生的计算错误，并利用这些错误来计算 SSH 服务器的本应保密的密钥私钥。所谓自然发生的错误，指的是宇宙射线和其他会翻转比特的小故障造成的错误；而所谓意外发生的错误，指的是 RSA 签名生成算法执行不力。如果你监控了足够多的到易受攻击的 SSH 服务器的连接，你最终会发现一个可以利用的漏洞。研究人员检查了过去七年扫描互联网收集的 10 亿个使用了 RSA 算法的签名。在这些签名中，有百万分之一的主机私钥会被暴露。

消息来源：The Register

老王点评：所以，加密算法还得防着宇宙射线的攻击。

苹果公司拿走了 1/3 的 Safari 上的谷歌搜索广告收入

谷歌和苹果公司早在 2002 年就建立了合作关系，谷歌成为苹果 Safari 浏览器的默认搜索引擎，过去几年谷歌每年为此向苹果支付了数十亿美元。在诉谷歌反垄断案审判中，谷歌的经济学家在法庭上意外披露了用户通过 Safari 浏览器使用谷歌搜索产生的广告收入，其中 36% 会支付给苹果公司。谷歌和苹果公司都曾反对公开披露双方协议的细节。

消息来源：彭博社

老王点评：好家伙，浏览器可真是个摇钱树啊。

谷歌起诉涉嫌发布植入恶意软件的山寨版 Bard 的骗子

谷歌起诉称，越南的一些人一直在建立社交媒体页面并发布广告，鼓励用户下载一个 “Bard”，但这个版本的 “Bard” 并不能提供如何烹饪意大利烩饭之类的有用答案。一旦某个傻瓜下载了这个 “Bard”，它就会侵入系统并窃取密码和社交媒体凭证。诉讼指出，这些骗子特别将 Facebook 作为他们的首选传播方式。

消息来源：Engadget

老王点评：这是把免费服务当成恶意软件的载体了，不过我觉得比起来今天圈内将开源 LLaMA “改成” 自己的开源大模型的大瓜，也算不了什么。

走走停停，最终还是走到了西子湖畔。在这个冬日，LLUG 与你在杭州线下相见。

11 月 25 日，LLUG 杭州场将在杭州未来科技城国际人才园（五常地铁站附近）举办。

本次活动依然由 Linux 中国和龙蜥社区（OpenAnolis）联合主办，杭州 GDG 协办，杭州城西科创大走廊高层次人才联合会提供场地支持。

龙蜥社区（OpenAnolis）是国内的顶尖 Linux 发行版社区，我们希望在普及 Linux 知识的同时，也能让中国的 Linux 发行版，为更多人知晓，推动国产发行版的发展和进步。

杭州城西科创大走廊高层次人才联合会简称“高联会”，高联会是在杭州城西科创大走廊管委会指导下，旨在广泛吸纳与团结廊内高层次人才，助力人才在杭州城西科创大走廊的创新创业。

杭州 GDG（杭州谷歌开发者社区），谷歌官方赞助的杭州本地技术社区，每年定期举办免费开发者线下技术沙龙，聚焦谷歌相关开源技术，欢迎大家关注微信公众号“杭州GDG”，了解我们，参与技术交流。

成都场现场照片

深圳场现场照片

上海场现场照片

本次活动，我们将设常规的技术分享、动手实践和闪电演讲三种不同分享的形态。

• 技术分享会邀请来自 Linux 社区的开发者，分享自己在 Linux 中的技术实践，并配合 Q&A 的环节，帮助大家理解技术难点和实践，如果你有经验和实践想要分享给大家，欢迎报名分享
• 动手实践则会有来自各厂商的 Linux 大咖，带着大家用半个小时的时间来动手实践一个 Linux 主题，帮助大家动手体验 Linux 的种种新特性、特定的能力。
• 闪电演讲则不设定主题，每个人有 5 分钟时间来分享自己与 Linux、技术、开源有关的话题，共计 6 个闪电演讲名额，想要试试锻炼自己的演讲能力，不妨从闪电演讲开始。

欢迎大家扫码加入 LLUG 杭州分群，在群里为活动提出你的建议～

此外，如果你对分享感兴趣，欢迎填写下方问卷来提交你的议题，向开发者们分享你的研究、实践和经验：https://jinshuju.net/f/VJkeMZ

（题图：MJ/8f5c79b3-5531-4e49-872d-ddb79266600a）