泰晓资讯 1 月 / 第 3 期 / 2020 —— 资讯收集
unicornx opened this issue · 5 comments
The Linux control-group mechanism was designed to make it easy to assign processes to groups or move them around; it is a simple matter of writing a process ID to the appropriate cgroup.procs file in the control-group filesystem hierarchy. That only works for processes that actually exist, though. Adding the ability to place a new process into a control group at birth is the subject of this patch set from Christian Brauner.
Linux 的 control-group 机制（即 cgroup）简化了将一个进程加入到某个组里面去，或者在组之间移动的操作。基于 cgroup，对应的操作只需要在 cgroup 文件系统中相应目录下的 cgroup.procs 文件中写入PID（进程ID）即可。不过，这个操作只对已经存在的进程有效。Christian Brauner 提出了一组补丁可以支持在创建一个新进程的同时就把它加入 cgroup。
之所以要增加这个功能的原因在于目前创建新进程和将其加入一个 cgroup 是两个独立的操作，之间存在的时间差可能会对某些应用产生影响（譬如一些用户希望精确统计组中的某个进程的资源使用情况，但由于进程在被加入组之前可能已经运行了一段时间，这可能会造成统计上的偏差）。
KRSI——另一个基于BPF的安全模块 https://lwn.net/Articles/808048/
One of the first uses of the BPF virtual machine outside of networking was to implement access-control policies for the seccomp() system call. Since then, though, the role of BPF in the security area has not changed much in the mainline kernel, even though BPF has evolved considerably from the "classic" variant still used with seccomp() to the "extended" BPF now supported by the kernel. That has not been for a lack of trying, though. The out-of-tree Landlock security module was covered here over three years ago. We also looked at the kernel runtime security instrumentation (KRSI) patch set in September. KP Singh has posted a new KRSI series, so the time seems right for a closer look.
BPF 虚拟机在网络之外的最初用途之一便是为 seccomp()] 系统调用实现访问控制策略。从那时起，尽管 BPF 已经从 cBPF 演进到如今内核支持的 eBPF，但在内核主线中，BPF 在安全领域的作用并没有太大的变化。KP Singh 刚发布了一个新的内核运行时安全监测 (Kernel Runtime Security Instrumentation，简称 KRSI) 设计修改，内核引入 KRSI 的目的是为了全面监视系统行为，以便检测攻击。在某种意义上，它被认为是内核审计机制的扩展，而使用 BPF 则是用来在此基础上提供更高级的可配置性。
January 1, 2020 marks the beginning of a new year and a new decade. Many things will doubtless change over the course of this year in the free-software community and beyond, while others will remain the same. One thing that will certainly hold true is LWN's tradition of starting the new year with some ill-advised predictions about what may be in store. Your editor has no special vision, but neither does he fear being proved badly wrong in a public setting — it's all in a day's work.
按照 “泰晓资讯” 的风格，对于 LWN 的最新报道一般采取摘录的方式。但对于这篇 LWN 面向未来十年的愿景，小编感觉干货满满，所以还是尽量全文翻译了，献给大家，希望大家能喜欢。
The Python community will continue to chart its post-Guido course. One relatively unnoticed development in the Python project's 2020 steering-council election was the quiet withdrawal of project founder Guido van Rossum's nomination. While he will still participate, he no longer wants a leadership role in the project. Increasingly, Python will have to find its way without the developer who has guided it since the beginning.
Python 社区需要慢慢适应在其创始人 Guido 不再继续担任领导下的发展。
Similarly, the GNU Project will have to decide what it will be in the 2020s. This project's founder, Richard Stallman, retains his post as its leader, and it's possible that he will still be there at the end of the year. But there is ongoing restlessness in the project that brings a desire for new leadership and new directions. After all these years, it still sometimes seems like GNU is stuck trying to reproduce the Unix workstations of the 1980s, leaving much of the current computing environment to systems that are half-free at best. We need a GNU project for mobile devices, private clouds, home systems, embedded applications, and more. Stallman once famously said "I'm not really concerned with what's running inside my microwave oven." The time has long since come to be concerned about such things; wouldn't it be a great thing if a newly reinvigorated GNU project were to take on this challenge?
类似地，GNU 项目需要决定其自身在 21 世纪 20 年代里将如何发展。项目创始人 Richard Stallman 仍然认为自己是项目的领导者，很可能直到年底，他也仍然会是这个职位。不过一直有声音要求 GNU 项目更换领导者和方向。时代变化了，应该要考虑这些了，我们满怀期待，希望 GNU 项目能够重现活力。
There is a common theme to those last two items that may not really arise in 2020, but will certainly come about in the 2020s: many of our leaders in the free-software community got their start in the 1980s and 1990s. In talking with those people, your editor increasingly gets the sense that many of them are thinking they have done this sort of work for just about long enough. Retirements will increase in the coming years, and we will lose much of the skill and experience that has gotten us this far. There are plenty of skilled and motivated younger developers who can certainly pick up where these folks leave off, but the transitions will go more smoothly if they are properly planned for.
我们对以上两个项目的期许并不会很快在 2020 年就发生，但变化肯定会在未来的几年内中来到，因为许多自由软件社区的领导人都是在 1980 或 1990 年代开始他们的事业的。我们可以越来越明显地感觉到他们中的许多人已经觉得自己已经做了足够久了。今后几年我们会看到更多的人退休，这意味着我们会因此失去很多好不容易才积累起来的技能和经验。当然同时也会有许多技术高超并且充满激情的年轻开发者加入进来，接过这些工作。希望能预先做好交接计划，使得这些过渡会更加顺畅。
The presence of highly experienced developers is perhaps felt most strongly in the kernel project. This is a good thing in a setting where mistakes can be catastrophic on a large scale, but it also partially explains why kernel developers have a distinctly old-school workflow. This is, remember, the project that only started using a source-code management system in 2002. Change is afoot, though, and the kernel workflow efforts will begin to bear fruit in 2020. We'll still be sending patches over email at the end of the year, but we'll have an improved understanding of what a better solution that can work at the kernel project's scale will look like. As part of this effort, the kernel's testing tools will also continue to improve at a rapid rate.
特别地，对于 Linux kernel 这个项目，我们能看到非常多的资深开发人员活跃其中。这对于像内核这种随便一个 bug 就会影响一大片用户的项目来说真是件大好事。不过这也部分解释了为什么内核的开发者仍在使用那些与众不同的陈旧工作流程。想想看，这个项目直到 2002 年才开始使用源码管理系统（Git）。不过改进一直在进行中，预计 2020 年我们在工作流程上能看到更多的成果。我们到年底的时候估计还会使用电子邮件来提交补丁，不过届时我们应该会对像内核开发这种大规模项目里面适合使用什么样的开发流程有更多的理解。同时，内核的测试工具也会继续快速改进。
For all its faults, though, the kernel's workflow produces reliable results. Thus, it is relatively safe to predict that the next long-term stable kernel release will be 5.9, on November 1, 2020. Most kernel release cycles have taken ten weeks in recent times. Should the process run a little faster and produce some nine-week releases, then the LTS release will, instead, be 5.10 in late December.
尽管内核工作流程上这样那样的缺点，但目前看来其运行还是相当可靠的。可以很有信心地预测说下一个 long-term stable 版本会是 5.9，预计于 2020 年 11 月 1 日发布。最近大多数内核版本的发布周期都是 10 周。如果后面这个流程能稍微加快一点的话可以缩短到 9 周，则 下一个 LTS 发布就会是 12 月份后期发布的 5.10 版本。
Strife in the Debian community will continue despite the project's recent decision on init-system policy. Debian suffers from a combination of hostile outsiders and certain project members who actively work to create turmoil on its mailing lists. The Debian community is resilient, and it will get past these problems too. But its mailing lists may not be a lot of fun to read in the meantime. The Devuan project, despite having picked up a post-vote defector or two from Debian, will continue to struggle for developer time and relevance.
Debian 社区的冲突还会继续，最近 Debian 刚刚就 init-system 的选择完成了一次大规模投票表决。Debian 面对的问题不仅来自外界，内部一些成员也总会在邮件列表上引发**。但好在 Debian 社区的自我恢复能力较强，会很快解决。不过 Debian 的邮件列表读起来总是让人不是很愉快。
It is now 20 years since the year-2000 bug failed to destroy civilization. Some now see y2k as an irrational panic, but without a focused effort there would have indeed been serious problems. The year-2038 bug looks distant and harmless, but it, too, requires a determined effort to avert real problems. The good news is that the year-2038 fixes will be mostly completed in 2020, at least at the kernel level. Yes, your editor has predicted this before and taken some good-natured grief for it, but this time it's for real.
2000 年的千年虫问题已经过去 20 年了，还好它没给人类文明带来什么麻烦。现在不少人都认为 y2k 问题其实是人类过于担忧了，不过如果当初人们没有及时应对的话说不定还真会出问题。后续还有个类似的 y2038 问题，虽然看起来还很久远，并且危害不大，不过，也会需要很多工作才能避免这个问题。好消息是，针对 y2038 的修复工作在 2020 年基本就会到位，至少内核会准备好。
BPF API issues will not go away in 2020. The in-kernel BPF virtual machine makes a great deal of power available to user space, and that will only increase in the coming year. Software providers will realize that it is often far easier to ship a BPF program to customers than to get a needed feature into the kernel itself. Sooner or later, one of those programs will break as the result of internal kernel changes and those customers will complain, quite possibly causing needed work to be reverted. The fact that much BPF functionality is available to proprietary programs is likely to create troubles of its own. A quick check shows 142 BPF helper functions in the 5.5-rc4 kernel; only 34 of those are marked GPL-only. Some developers are sure to see the growing set of BPF functions available to proprietary code as an erosion of whatever GPL protection the kernel has left.
BPF 的 API 问题在 2020 年仍会存在。通过在内核以 BPF 方式运行注入代码可以大大扩展用户态程序的能力，今年 BPF 程序会越来越多。软件供应商会意识到，相比在内核中增加一个新的功能，直接以 BPF 程序的形式发布给客户要容易得多。照此发展下去，势必会出现一种状况，就是客户手里的 BPF 程序由于和内核不兼容而导致无法使用。另外越来越多的 BPF 程序被标记为闭源，这也会导致问题。在 5.5-rc4 版本的内核中可以看到 142 个 BPF helper 函数，其中只有 34 个标记为 GPL-only。如此多的 BPF 函数被标记为私有，这简直就是对宣称遵守 GPL 的 Linux 内核的一种讽刺。
Expect perturbations in the employment market as various economic realities catch up with us. Both the dotcom crash and the 2008 crisis impacted the development community; the next downturn will do the same. As in the past, Linux and free software as a whole will not be significantly hurt when this happens, but the same cannot be said for individual developers, at least in the short term.
由于各种经济现实问题，我们预计会看到雇佣市场的波动。2000 年互联网泡沫破裂，2008 年经济危机，都曾经影响过开发社区。下一次经济下行也会有同样的效果。同过去一样，从整体上来看，Linux 和自由软件本身并不会受到太大的损害，不过短期上对于开发者个人来说情况很难讲。
Finally, though this is perhaps more of a wishlist item than a prediction: the free-software community has to think more deeply about what it is creating and how that will affect the world. At many levels free software has won; the world's computing infrastructure is built on the code we have created. We have much more control over our computing environments than we would have believed all those years ago; it's a great success.
最后要谈的这一点，其实应该算是一个期望而不是一个预言：自由软件社区需要更深入地思考它究竟创造了什么，以及它所做的一切会如何影响这个世界。自由软件在很多方面都取得了成功，全世界的计算基础设施都建立在我们创造的代码之上。当前我们对整个计算环境的掌控比起当年我们的预想要多得多，这是一个非常伟大的成功。
But we have also created — and continue to develop — the foundation for the most intensive surveillance machine the world has ever known. We have helped to build a world where sex toys report on their usage patterns, video doorbells cooperate with police, companies are attacked via fish-tank thermometers, cars can be disabled remotely, elections can be attacked by hostile countries, televisions report viewing habits, home devices phone home with audio recordings, and more. All of this machinery is used to sell us things, or to direct our behavior in even less benevolent ways. It is increasingly concentrated in the hands of a tiny number of huge companies; using it will inevitably prove to be a temptation that governments are unable to resist. We wanted a world where we controlled our computers, but we have created a world where our computers are used to control us. It is not enough to blame the companies involved; we have helped to build this world.
不过我们同样也创造了（并且仍在继续推动）世界上最大规模的监控基础设施。在我们帮助建立的这个世界中，sex toys 会上报用户的使用方式，视频门铃会受到警方的控制，汽车可能会被远程控制，选举可能会遭受到来自有敌意国家的攻击，电视机会上报您的观看习惯，家用设备会录音，诸如此类。整套机制会被用来向我们推销商品，指导我们的行为。这些手段越来越集中于少数巨型公司的手里，政府更是很难抵制这个诱惑。在我们创造的世界里，我们希望的是人可以控制自己的机器，但结果恰恰相反，我们自己反而受到了机器的控制。当然我们不能只责怪相关的公司，对现在这个局面的形成，我们自己也有份。
Back in 1983, the GNU project helped to focus attention on the need to create a free operating system for our desktop computers. Now we desperately need a project that can bring a similar level of attention to the need for free computing in every aspect of our lives. Free software was able to demonstrate enough advantages to convince companies to adopt it, even if it was less convenient in some ways at the time. The next generation of free software (along with freedom-respecting devices built on it) has to succeed in convincing people that there is a better way. If the free-software community can rally around this project, the outlook for the 2020s in general will be much improved.
回到 1983 年的时候，GNU 项目的出现在于唤起人们的重视，来创建一套自由的、运行于个人计算机上的操作系统。现在我们更需要一个项目来唤醒人们重视生活中各个方面对 “自由计算” 的需求。以往自由软件展示了很多优势，使得公司也愿意使用自由软件，尽管当时这些自由软件可能在某些方面并不完美。下一代自由软件（包括基于它们所制造的尊重自由的设备）也需要能够使得人们相信我们有一种更好的生活方式。如果自由软件社区能够围绕这个目标团结起来，那么总体而言，2020 年代的未来将会更加美好。
On a more mundane level, LWN is about to celebrate its 22nd birthday. Thanks to the solid support from you, our readers, we are still going strong after all these years. We wish for a great 2020 for all of you and we look forward to write for the best set of readers any publication could hope for.
最后啰嗦一下，LWN 即将迎来她 22 岁的生日。感谢各位读者的大力支持，祝愿我们变得越来越强大。也希望各位 2020 年生活愈加美好！
华为OpenEuler操作系统源码正式公开了
在2019年9月17日openEuler被宣布要在年底开源，近日，Euler操作系统终于正式开放源代码、镜像及开发测试环境。
华为表示OpenEuler的愿景是：通过社区合作，打造创新平台，构建支持多处理器架构、统一和开放的操作系统openEuler，推动软硬件生态繁荣发展。
openEuler项目来源于华为服务器操作系统EulerOS，开源后命名为openEuler。根据官网信息，EulerOS面向企业级通用服务器架构平台，基于 Linux 稳定系统内核，支持鲲鹏处理器和容器虚拟化技术，特性包括系统高可靠、高安全以及高保障，是目前支持TaiShan服务器最好的操作系统之一。
最后附上项目源码地址：
https://gitee.com/openeuler
https://gitee.com/src-openeuler
Tencent Linux操作系统宣布开源
近日，腾讯云宣布开源其云服务器操作系统 TencentOS 内核（TencentOS Server Kernel，又称 Tencent Linux，简称 Tlinux）。
Tencent Linux 是腾讯云物联网操作系统 TencentOS tiny 之后，TencentOS 家族对外开源的第二个项目。
开源地址：
https://gitee.com/mirrors/tencentos-kernel
https://github.com/Tencent/TencentOS-kernel
Tencent Linux 是腾讯针对云的场景研发的服务器操作系统。
Tlinux 是腾讯针对云的场景研发的 Linux 操作系统，提供了专门的功能特性和性能优化，为云服务器实例中的应用程序提供高性能，且更加安全可靠的运行环境。
支持平台
X86：支持intel, AMD(包括ROME平台)。
ARM64：支持热补丁，虚拟化。
腾讯介绍，相比业内其它版本 Linux 发行版，Tencent Linux 在资源调度弹性、容器支持、系统性能及安全等层面极具竞争力，特别适合云环境。
TencentOS 是腾讯云操作系统系列，由腾讯云架构平台部主力研发，覆盖数据中心、桌面系统、边缘设备和物联网终端等应用场景，提供云平台构建、接入和应用能力。
腾讯云操作系统团队表示：“将腾讯云服务器操作系统内核 TencentOS Kernel 开源，不仅可以与全球开发者共享腾讯云在服务器操作系统领域的技术和经验，还能够汲取全球服务器操作系统领域的优秀成果和创新理念，助力整体服务器操作系统生态的繁荣。”