导读：本期要闻包含OpenStack网络如何给组织带来好处、Portworx CEO分享的如何让Kubernetes跑得快还不出错的秘籍等精彩内容。

大数据要闻

Elasticsearch 7.6.2 发布，分布式搜索和数据分析引擎

Elasticsearch 7.6.2 发布了，Elasticsearch 是一个分布式的 RESTful 风格的搜索和数据分析引擎。更新内容较多，摘取部分如下：

修复并发令牌刷新支持中的潜在 bug  #53668；

未确认时，ILM 冻结步骤重试  #53287；

Features/Java High Level REST Client；

将不支持的参数添加到 HLRC 搜索请求 #53745；

通过 Rest 修复 AbstractBulkByScrollRequest slices 参数  #53068 (issue: #53044)；

对存储的脚本禁用监视程序脚本优化  #53497 (issue: #40212)；

修复 Term 向量 #53504 (issue: #53494)；

修复并发请求竞争滚动上下文限制  #53449；

修复 can_match 阶段中碎片的预排序  #53397；

修复 FuzzyTermsEnum 中潜在的 NPE  #53231 (issue: #52894)

更多详情见更新说明：

https://www.elastic.co/guide/en/elasticsearch/reference/7.6/release-notes-7.6.2.html#bug-7.6.2（转载于OSChina）

大厂要闻

近日，小米已开源基于 Android Q 的 Redmi K30 Pro 的内核源码，可从 GitHub 进行下载。

Redmi K30 Pro 的预装系统为 MIUI 11（基于 Android Q），随着内核源码的发布，开发者和愿意折腾的用户能够充分利用硬件的潜力，相信市场上也会很快出现该机型的第三方固件。

小米在开源内核方面的动作一直以来都比较积极，比如在发布 POCO X2 时开源了 Redmi K30 5G 的内核源码，以及小米10、小米9系列发布当天即开源内核源码。小米手机系统软件部总监张国全也表示欢迎下载编译，“使用开源系统，回馈开源社区”。（内容转载于OSChina）

战疫要闻

D-Wave宣布为COVID-19病毒研究者开放量子计算云服务

近日，D-Wave Systems宣布，致力于应对COVID-19危机的任何人都可以通过Leap量子云服务立即免费访问其量子系统。

合作伙伴和客户包括CINECA，DENSO，ForschungszentrumJülich，京瓷公司，京瓷通信系统，MDR / Cliffhanger，Menten AI，NEC Solution Innovators Ltd.，OTI Lumionics，LMU Munich的QAR Lab，Sigma-i，日本东北大学（Tohoku University）和大众汽车公司将为具有专业知识的工程团队提供访问权限关于如何使用量子计算机并提出问题，以及帮助开发解决方案的知识。

这项倡议是响应加拿大政府要求解决跨行业大流行的要求而提出的。北美，欧洲和亚洲的35个国家/地区的从事COVID-19响应工作的任何人都可以立即通过Leap不受限制地免费访问D-Wave量子计算机，在这里可以访问Leap量子云服务。

要有效地响应COVID-19，就需要跨各种组织（包括私人和公共机构）的协作和全球性努力。通过免费访问Leap的量子处理资源和量子专业知识，D-Wave及其合作伙伴希望为找到解决COVID-19危机的解决方案做出贡献。

通过设计，混合量子经典计算非常适合解决这种性质的一系列复杂问题。COVID-19的潜在关注领域包括多种混合量子应用，例如分析新的诊断方法，对病毒传播进行建模，优化医院后勤，供应分配，药物组合等。

通过量子经典计算机模拟的混合工作流程，有望解决诸如史无前例的COVID-19危机中出现的药理学和流行病学的复杂问题，以加速解决这些问题，”Jülich超级计算中心的Kristel Michielsen教授说。“为了有效利用D-Wave的优化和AI功能，我们正在将系统集成到模块化HPC环境中。”

（内容转载于Linux公社）

中国提出 NEW IP 标准化提案，欲代替现行的 TCP/IP

近日，英国的《金融时报》近日发表新闻报道，华为联合中国联通、中国电信、中国工信部（MIIT）等向联合国国际电信联盟（ITU）提出了一份全新的网络架构「NEW IP」，并打算在 2030 年用 NEW IP 代替现行的 TCP/IP。在官方提案中，华为将支撑全球网络的现有互联网基础设施 TCP / IP 描述为「不稳定」和「严重不足」，无法满足数字世界的要求。

DevOps要闻

推荐一个开源『DevOps + 研发效能』知识平台

过去的一个月里，因为种种不可告人的原因，我开始建设一个 DevOps 知识平台。因为，现有的笔记系统都太 TM 难用了。所以，我要写一个，我要造一个轮子。在这一个轮子里，它可以通过 markdown 编写内容，并渲染出各种绚丽的效果。哦，不对，这部分的内容偏题了。

在这个知识平台里， 它包含了这么一些内容：

DevOps 工具元素周期表 。帮助您进行数字化时代的 DevOps 工具选型。

DevOps 设计工具 。帮助您设计组织内的 DevOps 流程，涵盖了流程、人、工具、制品等等。

案例学习 。从社区的知识库中，我们总结了传统企业走向 DevOps 的经验，并浓缩到易于使用的内容和材料中。

最佳实践 。我们从海量的 DevOps 内容中，提炼出了一系列的最佳实践，以更好地帮助企业进行 DevOps 实践。

模式与原则 。基于我们的实践，我们提炼了位于它背后的模式与原则，帮助个人和组织更好地了解 DevOps 文化。

操作手册 。只凭实践与原则，无法让中小型 IT 团队进行 DevOps 转型，所以我们准备了详实的操作手册，以帮助您一步步前进。

度量 。KPI - 度量、度量 - KPI、KPI - 度量，帮助您更好地度量 DevOps 转型情况。

报告 。我们尝试从丰富地 DevOps 报告中，提炼出有用的实践和工具。

Mobile DevOps 。我们相信移动应用的 DevOps 改进，才是大多数公司的挑战。

工具 。工具，工具，工具是最好的生产力，工具比人的记忆力更加可靠。

起先，我是想做一些 DevOps 工具，比如说适合于中国国情的『DevOps 元素周期表』。顺带一说，这个工具不是我首创的，我只是用更好的架构实现了一遍。。如此一来，对于大部分开发人员来说，它们就可以从这个表中，组合出适合于自己组织的分子（毕竟周期表上都是原子）。几天之后，我就有了这个工具，根据整个研发体系的每一个过程，你可以从中挑选出适合你的要素。

为了凑满上面的元素，我不得不找一个又一个大公司的案例，看看他们到底是用什么技术栈。所以，我七拼八凑得差不多了，顺便一想，既然我有这么多大公司的案例，为什么不抽象一下这些案例呢。

于是，我们从互联网的各个地方（来源见内容中标明的出处），帮你抽取了各大公司的案例：

腾讯

小米

招商银行

美团

……

在这些案例，背后往往包含、隐藏了各种各样的价值取向。所以，进一步地，我想去提取这些模式，所以就包含了：

流畅度模式

度量体系设计

学习型组织构建

……

画完这些大包之后，随后，我们就可以进入 DevOps 的设计和实施阶段。我们要找到那些最好的实践：编程、团队、文化、能力、测试等等。

当然了，为了在组织中实施 DevOps，我们还需要一本操作手册，来帮助你一步步构建 DevOps 体系。

从度量，到实践，到工程化，再到流程打通，顺势而来，一步下实践。

光有手册是不行的，我们还把各种各样的工具做了上去，除了工具的名称，还包含：

工具的准备事项

工具的操作步骤

工具的示例

该工具的在线工具使用

还有更多的功能在开发中。也欢迎加入我们的开发队伍，更多的案例将帮助每个人更好地成长。

GitHub：https://github.com/phodal/ledge/，在线使用：https://devops.phodal.com/

OpenStack要闻

为什么企业会采用OpenStack而不是其他IaaS选项？

VK Cody BumgardnerVK Cody Bumgardner：这是一个战略选择。并非对每个地方都有利-例如，医院是由供应商驱动的。他们想要供应商堆栈中的所有东西，并且要有人垂直控制集成的每个点。

对于其他人，它使您可以选择进行体系结构决策。您不必重新发明轮子。如果要使用特定类型的同类最佳网络，则可以。如果要在计算机中使用软件，则可以。如果您可以灵活并有才能利用同类最佳系统，那么OpenStack就是一个不错的选择。

如果那不是您的文化，并且您拥有几乎规定的基础架构，那么OpenStack可能不是一个好选择。提供商业支持的公司可能是中间立场，但选择权分为两个阵营。

好处是您拥有使用API控制基础结构的标准方法。在选择部署方式和选择管理的基础结构方面，它更加灵活。

组织应了解哪些OpenStack网络要求？

Bumgardner：主要问题是：您的文化是什么？您是否去找供应商说：“请给我您的设计，告诉我要买什么以及如何支持它”？首先，您要评估系统。您有什么选择？

如果您遇到了在特定型号的设备上工作的孤单的人，那么OpenStack可能不适合您。如果您的人员具有较高的职能，并且对使事情正常运行的底层体系结构有一些基本的了解，那么OpenStack对您非常有用，而且您所受的限制也要少得多。

当您对OpenStack进行更改时，它允许最终用户或开发人员在计算机级别上自己做出决定。如果我构建的内容应具有静态地址，则可以请求并自动接收静态地址。或者，如果我想在租户中创建网络层次结构，则可以这样做。

在正常的企业系统中，您将与十几个人交谈，并获得不同的批准，从OpenStack的角度来看，您可以在租户内部建立自己的世界。至少在内部，网络控制取决于您，因为您可以创建该层次结构。

一个示例是负载平衡应用程序。您不能在一个OpenStack群集中进行地理负载平衡，但是可以进行本地负载平衡。负载平衡器可能是租户唯一暴露的东西。然后，您可以在租户中部署三层体系结构，该体系结构本身在OpenStack系统中是多种多样的。这意味着架构师可以控制它。即使在开发环境中，您也可以将设计和体系结构部署的控制权授予通常从应用程序角度知道他们想做什么的人。

网络团队和开发团队如何才能充分利用OpenStack网络部署？

Bumgardner：让您从网络，开发和存储方面一起工作的一件事是能够查看同一基础结构以查看其配置方式。

如果您可以在任何地方有效地部署OpenStack，它将为您提供厂商和技术中立性。

具有网络经验的人可以为网络功能虚拟化或负载平衡器创建特殊的配置，而不会损害更广泛的功能和策略。在企业空间中，网络人员将拥有一个或多个大型负载平衡器以及某些开发人员必须遵循的部署策略。将功能虚拟化并推送到租户中，意味着网络人员可以与应用人员更紧密地合作，以创建用于网络功能，负载平衡等的自定义服务。

您可以获得标准工具的好处，但是故障域仅限于特定项目，并且网络基础结构可以针对特定租户或应用程序进行定制，而不必尝试集中部署。

OpenStack网络要求给组织带来了哪些好处和挑战？

Bumgardner：如果您可以在任何地方有效地部署OpenStack，它将为您提供厂商和技术中立性。您将始终拥有某种形式的存储，计算和网络连接，但是如果有任何组件可供使用，就供应商或事物之间的连接方式而言，您可以更改基础物理基础架构。

从管理和监视的角度来看，部署资源，监视正在发生的事情以及提供身份验证和授权的方式都是相同的。您无需在技术上保持一致即可获得OpenStack的优势，但您需要在文化上保持一致并拥有合适的人员。

如果您的文化了解事物是如何工作的，并且您掌握了技术知识以了解事物的工作方式并使其工作，那么OpenStack就是很棒的选择。您可以安全地将更改推送给单个用户，而无需花费所有时间来尝试为人们提供服务。

但是，如果您的文化意味着您有问题，请致电供应商并让他们为您做所有事情，那么OpenStack可能不是最好的。您可以得到支持，但是如果您的组织没有了解计算，存储和网络之间关系的人员，则可能难以利用。如果您不了解这些事情的工作方式或协同工作，那么将很难获得支持。

Kubernetes要闻

Kubernetes无用论：真正的容器即服务是不需要编排的

计算的未来既不会是功能即服务（FaaS）产品（例如AWS Lambda），也不会是Kubernetes所必需的服务器群管理以操作容器。我认为，计算的长期命运是在无服务器基础架构上运行容器。我想要的是适用于容器的AWS Lambda。我想要的是真正的容器即服务（CaaS）。

我要的不仅是无服务器的容器基础架构，而且是无容器编排的基础架构。我想要的是能够说“这里是一个容器，请为我运行”的能力，然后让基础架构完成其余工作：基础设施应启动和销毁容器；基础结构应确定运行您的应用程序需要多少个实例；基础结构应自动管理容器上的负载；基础架构应该管理容器，就像AWS Lambda管理功能一样……我不必关心容器中有多少个实例正在运行，系统应该为我执行此操作。我不必担心与容量短缺有关的可用性问题，系统应该为我做到这一点。我不必担心多余的容量浪费，系统应该为我处理。

随之而来的是Fargate。我在2018年的文章中预测了真正的“容器即服务”，当时我相信AWS的一项新产品将提供它-该产品是Fargate。AWS Fargate是一种无需管理组成容器集群的单个服务器的方法。使用AWS Fargate，您可以指定要运行的容器数量以及这些容器的大小，然后Fargate将启动足够的服务器容量来为您管理该组服务器。最后，我们将拥有真正的“容器即服务”。

Fargate是一个很好的开始，我在原始文章中说过，但这还不够。Fargate是朝着真正的“容器即服务”方向迈出的一步，但这并不是一个完整的步骤。您会看到，在Fargate中，您仍然必须进行容量管理。您必须确定要运行多少个容器实例。确定容器数量后，Fargate将确定所需的必要服务器机队。但是您仍然必须指定所需的容器数量。Fargate并没有消除执行容量管理的需求。它只是将容量管理功能从确定所需的服务器容量转移到确定所需的容器容量。这是完全相同的问题，只是范围不同。

Fargate并未消除容量管理问题。Fargate并未删除业务流程作为您的基础架构团队关注的话题。Fargate确实可以解决此问题，但是并不能解决所有问题。

在2018年Fargate首次问世时，我说我认为计算的未来就是Fargate。这是因为我完全期望Fargate随着时间的推移能够有所改进，以解决其容量管理方面的不足。

所以我等。但是什么也没来。两年后，看来Fargate毕竟不会成为无服务器计算未来的解决方案。Fargate不会解决容量管理问题。

在真正的“容器即服务”模型中，您只需将容器的图像提供给服务，其余部分由服务处理。没有服务器管理。没有编排。没有。如果需要更多的容器实例来处理当前应用程序负载，则会启动更多实例。当不再需要容器的某些实例时，它们会被旋转。目的是始终提供适量的集装箱容量。

您不必为运行的容器数量付费，而只需为容器处理的负载量付费。换句话说，您不必为某种形式的已分配容量付费，而是为处理应用程序需求而实际消耗的资源数量付费。这是您今天无法使用Fargate进行的操作，也无法使用今天可用的任何其他编排系统或容器管理服务。像我在这里描述的那样，一个真正的“容器即服务”模型是我们真正需要的，它可以改变将来在基于云的基础架构中管理应用程序计算的方式。（原作者：Lee Atchison）

Portworx CEO：要让Kubernetes跑得快 还得不出错

目前，Portworx公司大约有130个客户，其中全球财富2000强中有50个，几乎所有的客户都是在生产环境中部署重要的企业工作负载。去年，我们看到2018年的客户订阅量增长200％以上，完成了13项六位数交易。这种增长来自新客户和现有客户，充分说明了企业通过采用容器架构正在实现加速创新，简化运营以及迁移到多云环境。

Portworx近期还推出了新的功能帮助企业在生产环境中投入更多的投资运行有状态的容器。例如，一旦发生故障，PX-Security和PX-DR可以帮助公司保护和恢复容器中运行的数据。去年11月，Portworx推出用于容量管理和PX备份的PX-Autopilot。凭借PX-Autopilot，客户可以按需付费，无需超额配置，可以节省多达65％的云存储成本。操作方面，PX-Backup能让用户可以更轻松地备份和还原基于Kubernetes的应用，能在需要时更快地查找和删除精确的客户数据以便遵守GDPR和CCPA等法规。

企业正在承受迅速交付新应用和服务的压力以便满足客户需求和提升市场竞争力。Kubernetes和容器出现了，但存储管理组件太困难且效率低下。我们看到了在云原生时代下对存储和数据管理进行现代化变革的机遇，然后抓住了。从容器和Kubernetes出现开始，公司已经运作了大约五年时间。这些技术提供了一种跨公有云，私有云，混合云和多云环境之间业务转换的有效方式，但公司仍然需要企业级功能，如安全性，高可用性，备份和恢复，SLA管理，合规性等等。这就是Portworx的真正的“战场“。我们与所有类型的存储和数据库一起使用来管理和编排底层数据，让用户放心使用容器和Kubernetes的强大功能。

Portworx能够让你在生产环境中运行容器。企业容器的采用正在迅速增长，其中87％的企业采用容器技术，而90％的企业在生产环境中运行容器。Portworx是唯一一家为基于容器的应用提供生产环境操作的存储和数据管理解决方案供应商。我们能让数据存储，安全性和保护到备份恢复，SLA管理以及合规性的全过程实现自动化，目前已经助力GE （通用电气）Digital，德国汉莎航空和T-Mobile等公司在Kubernetes上运行容器来实现其数字化转型。现在对于CIO们而言有一个“潜”规则——“运行快点，然后别出错儿！”但有时候似乎事与愿违。现代化，管理良好的容器环境能能满足CIO的要求，在一个始终由CIO掌控，有着良好管理，具有规范化的环境中，让团队能快速创新和部署新应用。我们需要正确的堆栈来达到目的，Kubernetes虽然功能强大，但不能提供企业本身所需的全部功能，这是Portworx的机会。让数据管理组件变得简单，并提供企业在生产环境中运行容器所需的安全性，高可用性，备份和恢复，自动化等功能。

VMware在2019年宣布计划将容器和Kubernetes纳入其主要业务vSphere当中时，对Kubernetes押注很大。此举是数字化转型战略实现更大转变的一部分——企业正在将其从硬件基础架构的注意力转向将资源投入到通过容器和Kubernetes实现应用和数据自动化。VMware意识到容器是商业价值的未来所在，这就是其在Kubernetes上进行大量投资的原因。此外，应用不再绑定到单个数据中心或存储平台。而是根据客户的位置，服务提供商的可用性和其他业务需求将它们分布在多个环境中。VMware认识到有必要加码其传统产品，采用Kubernetes对数据中心进行以机器为中心的控制，而Kubernetes可以跨公有云，混合云和数据中心对应用和基础架构进行以应用为中心的控制。很高兴看到VMware拥抱创新以及加速Kubernetes的主流化。

不久，硬件升级推动了创新（买功能更强大的服务器，开发新软件，引入新工艺）。但云计算消除了硬件的限制，并让应用比以前更快，更经济地大规模部署。现在，企业正在转向多云环境——贯穿多个公有云和私有云（包括自己的数据中心）。

云可以无处不在，相同的云原生堆栈可与在云上实现速度和创新，还可以部署在私有数据中心上。因此，云模式已经扩展到所有的环境中，Portworx是赋能这种“无处不在的云”模式的公司之一。虽然Docker带起了容器热度，但Kubernetes的发布使得容器能够迅速发展。在我们的2019年容器采用率调查中，提高开发人员的速度和效率被列为容器采用率的主要驱动力。紧随其后的是提高敏捷性，以及提高在多云环境运行容器，避免供应商锁定的能力。市场上主要的云供应商本身都支持Kubernetes，这使得其更具吸引力。

Linux要闻

Linux 5.6 发布

Linus Torvalds 在内核邮件列表上宣布释出 Linux 5.6。Torvalds 称，他没有看到内核开发受到新冠疫情影响的迹象，大部分人可能早就习惯了在家远程工作。他估计 Linux 5.7 的发布不太会有变动，但有人错过合并窗口还是可能的，毕竟合并窗口没有你或你周围的人的健康更重要。Linux 5.6 的特性包括：Arm EOPD 支持，时间命名空间，BPF 调度器和批映射操作，openat2（） 系统调用，WireGuard VPN 实现，流队列 PIE 包调度器，2038 年问题接近解决，pidfd_getfd（）系统调用，ZoneFS 文件系统，BPF TCP 拥堵控制算法实现，移除 /dev/random blocking pool 等等。

Swift 将增加对 Windows 和其他 Linux 发行版的支持

Swift 开发团队表示，其即将推出的 5.3 版本的目标包括“增加对 Windows 和其他 Linux 发行版的支持”。他们提到 Swift 5.3 将包括重大的质量和性能增强。更重要的是，此版本还将扩展 Swift 可用和受支持的平台的数量，特别是增加对 Windows 和其他 Linux 发行版的支持。苹果开源了 Swift 编程语言，但除了自家的平台，似乎没有动力去扩大对其他平台的支持，所以 Swift 跨平台的进展比较缓慢，目前仅支持 macOS 和 Ubuntu。

正因如此，不少社区成员十分积极将 Swift 移植到更多平台。例如，IBM 在服务器端方面为 Swift 贡献了 Kitura 框架，但由于令人失望的使用情况，IBM 在2019年12月放弃了对它的大部分支持。尽管如此，目前仍然有一个官方的 Swift Server 工作组（SSWG），其主导的项目包括 Swift NIO（事件驱动的网络框架）。此外，还有知名的 Vapor 框架，这是一个可在 macOS 和 Ubuntu 上运行的 Web 开发框架。

对于 Windows 平台，曾经有过一个开源的 SwiftForWindows 项目来支持在 Windows 中提供易于使用的开发环境，不过现在似乎已宣告死亡。除此之外，还可以使用 Windows 的 Linux 子系统（WSL）运行 Swift 编译器，但会存在一个问题——交互式命令行 REPL（Read Eval Print Loop）在 WSL 1.0 中不起作用。所以，对于希望在 Windows 上使用 Swift 的开发者来说，在 Docker 容器中运行 Swift 工具链是行之有效的一个解决方案。

好消息是，目前针对 Windows 的原生 Swift 官方路由已经完善。该项目被称为 swift-build 而不是 swift-windows，因为它涵盖了 Linux 和 Docker 以及 Windows。受支持的 Windows 10 最低版本为 10.0.17763.0（2018年10月更新）。

5种最佳Linux桌面发行版推荐

在使用了包括Red Hat，Zorin OS，Kali Linux Debian，CentOS等各种版本的Linux发行版之后的20多年中，我几乎可以看到每种发行版。对特定操作系统的大量了解使您可以轻松地列出最佳Linux桌面发行版列表。考虑到这一点，这是我最适合整体使用的Linux发行版列表。请记住，这是针对台式机的，因此不包括Red Hat Enterprise Linux，CentOS，Kali Linux和SUSE Linux之类的服务器发行版。

elementary

elementary是轻量级Linux发行版，位于我的“最受推荐”列表的顶部。为什么？有两个原因。首先，市场上少有特别优雅，更干净的Linux台式机。elementary OS的开发人员和设计人员在创建台式机方面做得非常出色，无论技术水平如何，任何人都可以使用。从您的孩子到您的祖母，他们都可以跳到基本的OS上并立即感到宾至如归-这是需要零学习曲线的少数Linux发行版之一。第二个原因是应用商店。尽管elementary预装了很少的应用程序，但该发行版包括市场上最好的应用程序商店之一，因此只需单击一下即可安装需要工作和玩的应用程序。除了应用商店的简便性，初级团队为使开发人员的工作报酬而做的工作值得称赞。elementary基于Ubuntu（基于Debian），因此Linux的这种发行版还具有出色的稳定性，共享相似的软件存储库，非常容易安装，具有相同级别的硬件识别能力，并且可以在台式机或笔记本电脑上很好地运行。

Ubuntu

据我所知，Ubuntu在每个Linux桌面分发列表的顶部或附近都处于统治地位，这有很多原因。首先，Ubuntu基于Debian，它是地球上最稳定的操作系统之一。其次，Ubuntu的设计人员和开发人员不遗余力地调整GNOME界面，以使此桌面环境易于使用且高效可用，因此几乎不需要添加GNOME扩展-除非您有特定的功能取决于。如果您选择的桌面环境是KDE，则始终可以选择Kubuntu。在桌面上，Ubuntu Linux几乎不需要进行任何调整就可以使该桌面发行版完成您所需的工作。从硬件到软件再到编解码器，一切都可以正常工作。使用Ubuntu，您 安装操作系统时，将获得一个相对较新的内核。而且，随着apt软件包管理器准备好安装您想要的任何类型的软件，您就不会出错。Ubuntu一遍又一遍地证明了您可以使用Linux而无需接触终端窗口-仅此一点就将Ubuntu置于几乎所有“最佳整体桌面发行版”列表的顶部。

Pop！_OS

Pop！_OS是System76的内部发行版。它基于Ubuntu，因此该发行版已经拥有血统书，可以跳到最前面。有了System76，您将找不到运行Windows或macOS的硬件，因此对于开放源代码的纯粹主义者而言，这是双赢。但是Pop！_OS不仅是已经很美味的糖果的闪亮包装，System76还添加了一些额外的花哨功能，使Pop！_OS变得与众不同。首先，Pop！_OS是少数无需大量额外工作即可进行游戏的发行版之一。诸如Steam之类的服务只需很少的调整即可运行。而且Pop！_OS的性能（尤其是在System76硬件上）是无与伦比的。在System76方面，选择GNOME用户界面是明智之举。尽管他们对台式机确实采取了非常原始的方法，只需添加一些可选的GNOME扩展，即可使桌面外观和行为完全符合您的要求。由于Pop！_OS基于Ubuntu，因此您会发现这种Linux共享许多相同的软件安装库。与任何现代Linux发行版一样，Pop！_OS易于安装。最后，System76添加了一种更新固件的简单方法，几乎没有发行版可以声称。所有这些结合在一起带来了令人难以置信的桌面体验。很少有分布可以声称。所有这些结合在一起带来了令人难以置信的桌面体验。很少有分布可以声称。所有这些结合在一起带来了令人难以置信的桌面体验。

Deepin

Deepin使用Deepin桌面作为默认用户界面，该界面通常被认为是市场上最漂亮的桌面。实际上，没有台式机甚至可以与这种Linux风格相提并论— GNOME，KDE，Mate，Cinnamon…或任何Linux发行版上的任何其他台式机都没有。就像Deepin开发人员采用了Ubuntu基础一样，在GNOME桌面上分层放置了一些最常用的扩展，然后将它们与macOS桌面中的适当部分混合在一起，以形成功能和形式的完美比例。Deepin还包括大量软件（与Ubuntu共享类似的存储库），以帮助您工作和娱乐。Deepin与Linux的许多其他发行版之间的区别是Deepin选择了LibreOffice上的WPS Office工具套件。好消息是WPS是一款出色的应用程序，任何人都可以在几乎没有学习曲线的情况下使用它。Deepin通过侧边栏的形式将优雅风格扩展到控制面板中，从而使配置桌面的各个方面变得异常简单。寻找市场上最好看的台式机（也可以使用）的任何人都很难找到最好的Deepin发行版。

Manjaro

Manjaro是列表中唯一不基于Ubuntu的发行版。Manjaro是基于Arch的发行版。通常情况下，我绝不会将基于Arch的桌面Linux放在“最佳总体”列表上。为什么？一般来说，Arch Linux不适用于普通用户，但Manjaro并不是您的平均基于Arch的发行版。当有人问“是否有可能使Arch Linux用户界面友好”时，Manjaro Linux会发生什么情况。该问题的答案是“是”。Manjaro提供了带有Xfce，GNOME或KDE的版本。您还可以在操作系统安装期间选择所需的办公套件（LibreOffice或FreeOffice）。当新用户首次登录Manjaro桌面时，他们 欢迎工具将为您提供欢迎，该工具在开始使用OS方面提供了大量帮助。对于那些喜欢传统桌面的人来说，Manjaro对KDE的看法是杰出的。如果您想击败Arch Linux，那么Manjaro就是您的不二之选。该发行版证明了Arch Linux也可以作为台式机的绝佳选择。

Linux 5.7 Scheduler为Intel和Arm CPU升级

周一，Ingo Molnar发送了Linux 5.7内核的调度程序更新，该更新在本周初打开。对于Linux 5.7周期，有许多重要的调度程序添加。

Linux 5.7的调度程序方面的亮点包括：

-NUMA调度更新，因此负载平衡器和放置逻辑不会互相冲突，从而以较少的迁移来提高本地性和利用率。

- 热过载系统的热压力跟踪。这项工作最初集中在Arm CPU上，目的是确保更好地将任务放置在受限制/降频的热/过热内核上。

- 支持的Intel CPU的Schedutil频率不变性。这将产生更好的性能和电源效率。此频率不变性工作应在Skylake X和更新版本的Xeon Phi上工作，并选择Atom / Goldmont零件。这可能会取得一些重大胜利，我们将在不久的将来在内部运行一些基准测试。多亏了这一重大改进，P-State才努力从默认的powersave迁移到Schedutil。

-由于不对称的CPU容量唤醒扫描，big.LITTLE平台的容量利用率得到了提高。

-实时调度修复/改进。

-其他各种修复和改进。

通过此PR进行的调度程序变更的完整列表已在星期二合并。