泰晓资讯·07月 / 第一期 / 2019

“泰晓资讯”，广泛报道 “Linux/开源” 业界资讯。欢迎广大读者投递相关资讯来源和素材，本站将进一步收集整理后发布给大家。

Linux 0.11 Lab 和 CS630 Qemu Lab 同时发布 v0.1 rc1

关键词：Linux 0.11 Lab, CS630 Qemu Lab

Linux 0.11 Lab 是 Linux 0.11 的极速实验环境，可配合《Linux 0.11 内核完全注释》使用。源自吴章金同学于 2008 年左右学习赵炯博士《Linux 0.11 内核完全注释》一书时的读书笔记和代码实践。2008 年的代码实践有回馈给赵老师的论坛，之后有很多同学复用相关的代码。2015 年在 Docker 兴起之后，作者重构了历史代码，发布到 Github 上，并取名为 Linux 0.11 Lab。经过数年的开发和迭代，目前已经收获了 355 Stars，172 份 Forks，最近一段时间，修复了部分 Bugs，基本功能已经足够完善，计划发布一个正式的版本 v0.1，这里先发布 v0.1 rc1。

CS630 Qemu Lab 是 X86 Linux AT&T 汇编语言的极速实验环境，可配合旧金山大学的高级微机编程课程 CS630 使用。它源自吴章金同学早年自学 CS630 课程时的实践成果，该实践成果有回馈给 CS630 课程的老师并且得到了老师的积极反馈。这门课程非常精彩，特别推荐给所有高校计算机专业的老师和学生。经过了数年的开发和迭代，这个 Lab 也已经非常完善，是时候发布 v0.1 了，先发布 v0.1 rc1，方便接收更多测试和验证。

Linux 在印度第一颗基于 RISC-V 架构的处理器上成功引导运行

RISC-V Workshop in Chennai, India, hosted by The Indian Institute of Technology Madras (IIT Madras), achieved a significant milestone by booting Linux on its first ever RISC-V based silicon chip processor named Shakti (Project Page).

关键词：shakti, RISC-V

印度钦奈（Chennai）的 RISC-V 研讨会由印度马德拉斯技术学院（Indian Institute of Technology（IIT）Madras）主办，在发布了其首款基于 RISC-V 架构的处理器 “Shakti”(代表女性力量的印度神话人物)之后，又成功地在基于该处理器的系统上启动了Linux，实现了一个重要的里程碑。据悉印度 Shakti 处理器 2016 年启动开发，基于开源的 RISC-V 指令集架构，得到了印度电子和信息技术部的大力支持。

华为向 EROFS 文件系统添加新的 LZ4 解压缩支持

This new EROFS support allows for LZ4 decompression to happen in-place so that data decompression can be done without any memory copies. This, of course, is helping out performance. Gao Xiang of Huawei commented on one of the patches, “On kirin980 platform, sequential read is slightly improved to 778MiB/s after the new decompression backend is used.”

关键词：EROFS, LZ4

EROFS 的新特性支持 LZ4 本地解压缩，避免了数据解压缩过程中的内存拷贝。 这有助于提高处理效率。 来自华为的补丁提交者 Gao Xiang 在注释中介绍说，“在 kirin980 平台上，在使用新的解压缩算法后，顺序读的速率略微提升，达到 778MiB/s。”

微软希望加入 Linux-Distros 邮件列表，加还是不加?

关键词：Microsoft, Linux

自称 Linux 内核黑客的微软开发者 Sasha Levin 希望代表雇主申请加入 Linux-Distros 邮件列表，要知道 Linux-Distros 邮件列表被各大 Linux 发行版用于报告、协调和讨论尚未公开的安全问题。如果获得批准微软将能了解有关内核及其代码漏洞、补丁和安全问题的幕后讨论。为了证明微软有资格像 Ubuntu、Debian 和 SUSE 那样成为 Linux-Distros 的成员，Sasha Levin 举了 Azure Sphere 和 Windows Subsystem For Linux (WSL) 2 的例子。有趣的是内核的主要维护人员 Greg Kroah-Hartman 也发邮件力挺 Sasha，愿意为其担保。

LWN: Ubuntu 将不再支持 i386

“The Ubuntu engineering team has reviewed the facts before us and concluded that we should not continue to carry i386 forward as an architecture. Consequently, i386 will not be included as an architecture for the 19.10 release, and we will shortly begin the process of disabling it for the eoan series across Ubuntu infrastructure.”

关键词：Ubuntu, i386

从 19.10 版本 （代号为 “Eoan Ermine”）开始， Ubuntu 将不再支持 32 位的 x86 体系架构。

LWN: Cloud-Native Computing Foundation 和他们的愿景规划

At KubeCon + CloudNativeCon Europe 2019 there was a public meeting of the Cloud Native Computing Foundation (CNCF) Technical Oversight Committee (TOC); its members outlined the current state of the CNCF and where things are headed. What emerged was a picture of how the CNCF’s governance is evolving as it brings in more projects, launches a new special interest group mechanism, and contemplates what to do with projects that go dormant.

关键词：CNCF, TOC

来自 KubeCon + CloudNativeCon Europe 2019 的报道。随着 Cloud Native Computing Foundation (CNCF) 引入了越来越多的项目，有关如何加强基金会管理的问题日益突出。CNCF 在 2016 年创始之初只有一个项目，即 Kubernetes。截至 2019 年，该基金会旗下第一梯队（相对成熟）的项目有 6 个，处于 “孵化期（incubating）” 阶段的项目有 17 个，另外还有 15 个项目刚刚启动。这么多的项目是否值得被基金会接受以及如何发展，这些工作都由 CNCF 中的一个独立的委员会 Technical Oversight Committee (TOC) 来负责。

LWN: 内核维护中的 Rebase and merge

Maintaining a subsystem, as a general rule, requires a familiarity with the Git source-code management system. Git is a powerful tool with a lot of features; as is often the case with such tools, there are right and wrong ways to use those features. This document looks in particular at the use of rebasing and merging. Maintainers often get in trouble when they use those tools incorrectly, but avoiding problems is not actually all that hard.

关键词：Linux, rebase, merge

如果你需要维护内核代码，首先需要熟悉的是如何使用 Git 这个源码管理工具。Git 是一个功能强大的工具，该工具的每个功能都有其正确的用法，但我们也会发现一些常见的错误用法。这篇文章主要专注于给大家介绍了 rebase 和 merge 这两个方面，如果您对提交和维护内核代码感兴趣，不妨仔细读读这篇文章。当然与之对应的，这篇文章的作者（大名鼎鼎的 Jonathan Corbet 先生）为了在合并内核代码期间减少子系统维护者所碰到的问题，专门提交了一份类似主题的 kernel document，预计会随 5.3 版本合入，放在 Documentation/maintainer/rebasing-and-merging.txt 目录下，另外还有一个在线的维护者手册页在 https://www.kernel.org/doc/html/latest/maintainer/index.html ，大家也可以去看看。

LWN: Intel 为支持短延迟开发的新指令以及 Linux 对其的支持

If a user-space process needs to wait for some event to happen, there is a whole range of mechanisms provided by the kernel to make that easy. But calling into the kernel tends not to work well for the shortest of waits — those measured in small numbers of microseconds. For delays of this magnitude, developers often resort to busy loops, which have a much smaller potential for turning a small delay into a larger one. Needless to say, busy waiting has its own disadvantages, so Intel has come up with a set of instructions to support short delays. A patch set from Fenghua Yu to support these instructions is currently working its way through the review process.

关键词：Linux, Intel, delay

对于一个应用来说，虽然内核可以提供好几种实现超时等待的手段，但如果等待的时间较短，譬如是几微秒级别的，则这些手段都无法保证超时时长的确定性（由于时钟精度等问题可能会导致等待超长），所以程序员一般更倾向于直接采用忙等待的方式（有限次数的忙循环，busy loops）。毫无疑问，这么做有好处也有坏处，最大的坏处就是忙等待会浪费处理器的计算能力，除了导致发热，对于支持超线程(hyperthread)的处理器来说还会阻碍另一个超线程的运行。为此，Intel 公司在其即将推出的 “Tremont” 处理器上提供了几个新的指令来改进这个问题，可以支持无需忙等下的短时长延迟，而从 kernel 的角度来说，则需要为该特性提供一定的封装，方便用户的使用。具体的补丁由 Fenghua Yu 实现。在对该补丁的 review 过程中有人提出该功能可能会涉及一些安全性方面的问题。具体内容请参考原文描述。

LWN: Python 是否需要一个更快速的发布周期?

Python has followed an 18-month release cycle for many years now; each new 3.x release comes at that frequency. It has worked well, overall, but there is interest in having a shorter cycle, which would mean that new features get into users’ hands more quickly. But changing that longstanding cycle has implications in many different places, some of which have come up as part of a discussion on switching to a cycle of a different length.

关键词：Python, Release

多年来，Python 一直按照 18 个月的周期进行发布; 至少每个新的 3.x 版本都是以这个频率发布的。 总体而言，该机制运作良好，但社区中有些人希望能够缩短发布的周期，这样新的功能可以更快地进入用户的手中。 但是改变这个周期势必会在许多不同的地方产生影响，不少人对这个想法提出了各自的意见，比较激进的人建议调整后的周期为 9 个月，也有人建议是 12 个月，也就是按年为单位发布。究竟最后的决定是多少，让我们拭目以待。

LWN: TCP 协议栈中的一个 bug 可能会导致系统崩溃

Selective acknowledgment (SACK) is a technique used by TCP to help alleviate congestion that can arise due to the retransmission of dropped packets. It allows the endpoints to describe which pieces of the data they have received, so that only the missing pieces need to be retransmitted. However, a bug was recently found in the Linux implementation of SACK that allows remote attackers to panic the system by sending crafted SACK information.

关键词：TCP, SACK, panic

Selective acknowledgment (SACK) 是 TCP 协议中用到的一种机制，该方案提出时间是在 1996 年，具体可以参考 RFC 2018，其用处是可以帮助减少丢包重传所导致的拥塞。网络的端点（endpoint）可以利用这个机制，来告诉对端自己收到了哪部分数据，然后对端就只需要重新传送缺失的部分数据即可。不过，最近在 Linux 的 SACK 实现中发现了一个 bug。远程攻击者可以利用该漏洞，通过发送特制的 SACK 信息让接收方的 Linux 系统产生 panic。

联系我们

资讯内容部分来自 “LWN.net“。如果您对某些 LWN 文章感兴趣（譬如希望获得全文翻译的）请扫描二维码加微信联系我们：