微软 Defender 去年阻止了 300 亿次电子邮件威胁

在很多人心目中，微软还是那个操作系统和 Office 软件巨头，但是现在，游戏和云业务才是拉动微软营收快速增长的主要驱动力。除此以外，微软的安全业务也得到了快速的发展，在 2020 年里安全业务的总营收超过 100 亿美元，同比增长了 40%。

微软和其他竞争对手的主要区别在于能够综合使用人工智能和自动化的方法，大量使用微软安全机制的客户每天都会与该公司分享他们的安全信号。在 24 小时内，微软能够收集到 8 万亿条安全信号。微软 Defender 每天会执行 25 亿次的云端检测，成功阻止超过 60 亿次的端点威胁。适用于 Office 365 的 Defender 阻止了超过 300 亿次的电子邮件威胁。

Canonical 继续努力希望用 Wayland 取代 X.Org

Canonical 宣布，在 Ubuntu 21.04 中将使用 Wayland 取代 X.Org 作为默认显示服务器。不过，由于某些持续存在的问题，英伟达用户仍将默认使用 X.Org 显示服务器，可能要等到下个版本才能使用 Wayland。

X.org 实在太老太破了，Canonical 一直都想将它替换为自己开发的 Wayland。早在 2017 年的 Ubuntu 17.10 中，就采用了 Wayland 作为该版本的默认显示服务器。不过由于 X.org 的历史包袱太重，在 Ubuntu 的 LTS 版本中一直没有将 Wayland 作为默认显示服务器。

Canonical 已经为此做了非常多的工作，预计在明年的 22.04 LTS 中就可以使用 Wayland 作为默认显示服务器了。

不过，以我看来，对于生产环境更重要的 LTS 版本，其实图形界面并不太重要，所以无论采用哪种显示服务器，都不要紧。但是，Canonical 积极推进 Wayland 替代的意义很重要。

Linux 内核维护团队考虑缩减 5.10 LTS 的支持周期为两年

2017 年，Linux 宣布拓展 LTS 版本的内核服务年限，从原先的 2 年拓展至 6 年。这意味着 5.4 LTS 持续支持到 2025 年，4.19 LTS 支持到 2024 年，甚至于 4.14 LTS 都支持到 2024 年年初。

最近 Linux 稳定版内核的维护者格雷在邮件列表中对 Linux 5.10 支持时间进行了讨论，如果没有太充足的理由，Linux Kernel 5.10 LTS 只能维持两年。格雷表示，他希望知道有多少公司依赖于 5.10 LTS，如果大家都不是很在意的话，那么 5.10 可能就支持两年了，到明年年底停止支持。

看来，内核维护团队对这么多要维护的内核有点不堪重负了，毕竟，除了非 LTS 的内核之外，LTS 的内核就有好几个，而现在的内核也越来越复杂和庞大了。

一套完整启用的 DevOps 工具链可推动你的创新计划，实现快速部署并节约成本。

不同规模和不同行业组织都致力于为提高软件交付的速度和质量提供解决方案。这不仅保证了他们的生存，还令他们在全球市场取得了成功。DevOps 可以帮助他们规划出一条最佳路线。

DevOps 是一个系统，通过引入不同的工具链连接不同工作流程，以便及时交付项目并降低所需的开销。

在我工作的 IT 服务公司 Accedia，我们会帮助客户落地一套完整的 DevOps 工具链，这套工具链能帮助他们达到甚至超越他们的业务目标。在这篇文章，我会分享目前为止从 DevOps 项目中汲取的经验。

DevOps 工具链是什么？

一套完善的 DevOps 工具链可以在不同阶段中使用不同的 DevOps 工具来解决特定的业务带来的挑战。一条工具链能保证前端和后端开发者、质量测试人员、客户都能够从中获得收益。构建工具链的目的是为了自动化开发和部署过程，以确保快速、可靠、预算友好地交付与创新。

我们发现成功构建一套 DevOps 工具链不是一个简单的事情。它需要实验和不断的完善，保证必要的流程是完全自动化的。

为什么你需要 DevOps 工具链

DevOps 工具链自动化了工作流中的所有技术元素。它能让不同团队在一个平台上进行工作，因此可以使你专注于业务战略以推动组织走向未来。

我们总结了五个实现 DevOps 工具链所带来的好处。你可以让管理层相信，是值得为 DevOps 工具链的开发投入资源和时间的。

1. 更快、更高效的生产部署：DevOps 工具自动化了大部分软件开发进程。这会使产品开发专注于创新，交付更加敏捷，更领先于竞争对手。
2. 预算和时间优化：将手动的任务转变为自动化会使你的组织节省时间和资源。当没有人为的错误和时间管理不足带来的额外支出，预算自然会得到优化。
3. 高效的开发：DevOps 工具链会减少开发工作中不必要的延时，提高开发效率。前端、后端、质量测试人员的工作是一致的，所以没有人需要协调不同团队之间人员的交付。
4. 更快的部署意味着更高的质量：DevOps 工具链保证了缺陷能够很快被解决，并且迅速完成高质量的部署进程。怎么样？它可以生成有针对性的告警，并将重要的事件通知给你的团队。这会让你主动地发现并解决潜在的问题，从而规避故障的不断的升级从而导致的客户服务不可用。
5. 及时事件管理：DevOps 工具链有助于优化事件管理记录。它能够识别 IT 事件并且逐渐升级事件级别，通知给指定团队的成员，直到问题被解决。这意味着消息的接受和处理会更加的迅速，因为它们发送给了正确的目标。

DevOps 工具链的实践

对我的团队来说，DevOps 并不新鲜。我们已经敏捷开发很长时间了，并且我们总是热衷于探索最优的工作流。在我们的实践中，往往都是应用复杂性增加从而带来了自动化的需求。

这是我们为一个客户配置的工具链。这个项目包含了移动运营方案，连接了金融交易的所有参与者 （卖方、买方、银行）。这个客户需要动态响应用户反馈并且将故障时间缩短到最小，从而来提高用户体验。我的团队设计了一套工具链用于自动化应用的维护和部署新功能。

(Accedia, CC BY-NC-SA 4.0)

1. 首先，我们团队编写了自动化测试，可以立即识别应用程序的变更。
2. 当新版本已经准备就绪的时候，代码将被提交到 Gitlab 中。
3. 通过 Gitlab，提交会自动触发 Jenkins 构建。
4. 在 持续集成中，新的代码版本通过 Chai 和 Mocha 进行了测试，以检测是否运行正常。
5. 当测试通过，持续部署阶段 将会开始并创建一个可用的 Docker 镜像并上传到 Sonatype 的 Nexus。（这是 Sonatype 公司的的一个开源工具）
6. 最后，新版本应用会通过 Nexus 下载并且部署到线上环境中，例如 Docker 容器 （持续部署阶段）

简而言之，每当有人在仓库中创建一个新的提交，又或者团队上传新的代码版本、功能、升级、缺陷修复等，应用程序包都会自动更新并且交付给客户。

这套系统拥有良好的事故控制能力以保证快速部署，但不以牺牲质量为代价。它对于用户的反馈是动态的，意味着新功能和旧功能的和更新只需要之前一半的时间，同时将故障时间降低到最低。

把它封装起来

一套完整并且正确实施的 DevOps 工具链可以从始至终推动你的创新计划并且加速部署。

根据你的需求，你的工具链可能看起来和这些不一样，但是我希望我们的工作流能够让你了解如何将自动化作为一种解决方案。

via: https://opensource.com/article/21/1/devops-tool-chain

作者：Tereza Denkova 选题：lujun9972 译者：AnyISalIn 校对：wxy

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

文件夹的用途是存储信息和任务。使用标签来帮助你更好地组织这些文件夹中的内容。

在前几年，这个年度系列报道了诸如 Notmuch 和 Syncthing 之类的开源的组织应用程序。今年，我们除了关注 2021 年的策略外，还将关注一体化解决方案。欢迎来到 2021 年 21 天生产力的第九天。

我用我的电子邮件、待办列表和笔记来做这件事，有一天我决定我要把这些“组织起来”，重新安排我保存东西的方式和位置。有时我发现了一个新的程序，我必须（再次）从头开始配置。有时，当前的方法已经花了很多时间，与我使用系统的时间相比，我花了更多的时间在保持存储顺序最新。我去年测试一些待办列表软件时，最后一个软件让我有了一个非常重要的认识。

所有事情都有存放的地方（Kevin Sonney, CC BY-SA 4.0）

让我打个比方。一个任务（或电子邮件或笔记）就像你在一次活动中收到的那件很酷的 T 恤。它是黑色的，有一个很棒的图案，后面有一个标签，上面写着尺寸，领口有一个标签，上面写着洗涤说明。到了该收起来的时候，它该放在哪里呢？是和黑色的 T 恤放在一起吗？是和类似主题的衬衫放在一起吗？是按尺码放吗？是按需要洗涤的方式？还是按材质？

一件 T 恤只能放在一个地方，即使它可以有多种特质。我们需要以同样的方式对待任务、电子邮件和笔记。大型电子邮件提供商已经允许我们把一个标签当作一个文件夹。一封邮件（或一个文档或一个任务）可以同时在两个文件夹中！或者三个！甚至 11 个！

它高达 11 个（Seth Kenlon, CC BY-SA 4.0）

我必须明智地决定不再这样做。文件夹不是标签，标签也不是文件夹。这让我找到了我目前整理待办事项清单（和笔记，以及电子邮件）的规则：

1. 一个任务只应该在一个文件夹里。文件夹是以“大事”来命名的，比如一个地方或组织。我目前有三个文件夹来存放任务。“工作”、“家庭”和 “爱好”。当我专注于其中一个领域时，我知道我在看什么任务。
2. 一个任务可以有任意个我需要的标签。我尽量保持在三个左右或更少。
3. 一个任务应该有一个明确的意义。也许是你要写的程序的名字。也许是一些通用的东西，比如“要读的书”或“账单”。但如果你记不起 “4rg8sn5” 就是“要支付的账单”，这就对你没有帮助。

利用这些规则，如果我有一个“写第 9 天文章”的任务，它就会进入”爱好“文件夹，我给它打上 “OSDC”、“文章”、“2021” 的标签。如果我想在我的 Elementary Planner 中看到我所有的 2021 年的任务，我可以搜索这个标签。任务最终会出现在 “OSDC” 的搜索中，其中可能还包括一个对文章发表评论的待办事项，一个开始规划 2022 年系列的待办事项，还有一个跟进我认为有好文章想法的人。

我的“工作”文件夹里的东西通常是按项目标记的。“完成管理 CLI 文档”可能会被分为 “github”、“prod” 和 “admin”。“docs” 标签包含了“工作”和”爱好“文件夹中的项目，因为写文档是这两个文件夹都需要做的事情。

文件夹和标签（Kevin Sonney, CC BY-SA 4.0）

将“标签”和“文件夹”进行心理分离，帮助我将任务进行分组和分类，而不至于过度。这也意味着我可以更快地找到事情，花更少的时间去维护我的待办事项清单，而花更多的时间去做清单上的事情。

via: https://opensource.com/article/21/1/labels

作者：Kevin Sonney 选题：lujun9972 译者：geekpi 校对：wxy

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

阿里云的 CentOS 替代品 OpenAnolis 宣布成立理事会

在 2020 年 12 月 CentOS 项目组宣布 CentOS 8 将于 2021 年底结束支持后，几个公有云服务商纷纷宣布基于之前的内部使用的发行版推出 CentOS 替代发行版，这包括华为云的 openEuler、腾讯云的 TencentOS、阿里云的 OpenAnolis。

OpenAnolis 社区由阿里云于 2020 年 9 月发起，而近日 OpenAnolis 社区宣布正式成立理事会、技术委员会和运营委员会。首批理事成员单位包括阿里云、统信软件、飞腾、兆芯、龙芯等主流芯片厂家和国内领先云公司，以及以 Intel 等国外领先芯片厂家为代表的合作伙伴单位。

OpenAnolis 社区将于 2021 年第二季度发布 Anolis OS 8，和 CentOS 完全兼容。

虽然基于对这些云服务商的历史风评，开源和技术社区对他们推出的这些发行版有种种不同看法，但是我认为，还是应该对这些发行版的成长持乐观态度，我也认为，这对国内的开源生态和发行版生态有一定的促进作用。当然，目前看起来，这些发行版在社区治理、项目价值方面还没有公开的、明确的计划和思考，存在着发展上的隐忧。

sudo 被爆有史以来最重要的高危漏洞，可 root 提权

安全研究人员今日披露了一个 sudo 的高危漏洞 CVE-2021-3156，可以据此漏洞提权至 root。更严重的是，这个漏洞已经出现了近 10 年之久了。

几乎目前所有在使用的 sudo 版本都受影响，这包括从 1.8.2 到 1.8.32p2 的经典版本，以及从 1.9.0 到 1.9.5p1 所有稳定版本。研究人员说，该漏洞“可被任何本地用户利用”，在不需要认证的情况下获得最高权限。在流行的 Ubuntu 20.04、Debian 10、Fedora 33 等 Linux 发行版上均可以获取完全的 root 权限。

各大发行版都在纷纷准备补丁，系统管理员们要及时更新，这个漏洞“可能是有史以来最重要的 sudo 漏洞”。

微软 Office 借助容器技术，可编辑和使用恶意文档

微软上线了适用于微软 Office 的应用防护功能。该功能可以在用户打开来自不信任来源的文件之前，将其放置在容器中，以便于抵御恶意威胁。据微软说，它不仅可以让你的系统免受恶意文档的侵害，而且由于使用了基于 Hyper-V 的容器，你的文件也受到保护，不会受基于系统内核的攻击。并且，这与以只读模式打开文件的保护视图不同，你可以在不离开容器的情况下以有限的容量编辑和打印文件。

很早以前，文档都是无害的，但是随着要求文档加入各种自动和智能的功能，文档也成了恶意代码的潜伏地。我认为，微软的这种容器式沙盒模式很有意义，可以真正隔离风险。之前没有推出这样功能，可能是因为容器的运行成本比较高吧。但是随着现在容器技术的发展，微软也在 Windows 上支持了更多的容器技术，将容器技术应用到文档上是一个很好的创举。

KDE 很棒，但当你使用这个统一个人信息管理器 Kontact 时，它才真正发挥了作用。

在前几年，这个年度系列涵盖了单个的应用。今年，我们除了关注 2021 年的策略外，还将关注一体化解决方案。欢迎来到 2021 年 21 天生产力的第六天。

在很久很久以前，当编译内核还是获取 WiFi 驱动的唯一途径时，图形环境主要是用来运行网页浏览器和打开大量终端窗口。其外观和感觉是由程序作者选择使用的各种工具箱组成的大杂烩。然后，在 1996 年 Matthias Ettrich 提出并随后发布了第一个版本的 KDE。它是基于当时专有的 Qt) 工具箱（后来成为自由而开源的）。这个版本引发了 Linux 上的桌面革命，同一时期出现的还有使用当时的自由开源软件 GTK 工具包所创建的 GNOME 桌面 。不管是 KDE 还是 GNOME，Linux 从一个只有电脑操作人员使用的 Linux 操作系统变成了一个人人都能使用的强大桌面环境。

Fedora KDE 版的默认桌面 （Kevin Sonney, CC BY-SA 4.0）

KDE Plasma 5 是最新的 KDE 版本，它的功能非常丰富，可以提高你的工作效率。它包括了 Konqueror 网页浏览器、Dolphin 文件管理器和 Konsole 终端模拟器，所有这些都为这个桌面环境提供了一个很好的坚实基础，但是 KDE 真正提高生产力的方法是这个统一个人信息管理器：Kontact。

Kontact 为其他几个 KDE 程序提供了一个单一的界面，包括：KMail（电子邮件）、KOrganizer（日历、待办事项和日记）、KAddressBook（地址簿）、KNotes（笔记）、Akregator（RSS/ATOM 订阅阅读器）等。第一次启动时，Kontact 会引导你完成电子邮件提供商的设置，它支持本地和远程邮件配置。然后，Kontact 会进入一个仪表板，默认情况下，该仪表板会显示最近的电子邮件、日历事件、计划任务和最近的笔记。

Kontact 概览页面 （Kevin Sonney, CC BY-SA 4.0）

设置“流程”看起来有点奇怪，因为在内置的本地账户之外没有配置统一的单一账户。在 Kontact（通过 KMail）引导你完成邮件设置后，你就可以进入日历页面添加你的日历，这里也配置了待办事项和日记应用（对于某些提供商，还可以配置通讯录）。

邮件和日历组件非常简单明了，可以如你期望地正常工作。待办事项页面和日记是与日历绑定的，这对于一些不完全支持所有日历类型的日历提供商来说可能是个问题（Google，我说的是你）。如果你使用的是这些提供商中的一个，你将需要为日记和待办事项创建一个特定的本地日历。

Kontact Calendar （Kevin Sonney, CC BY-SA 4.0）

待办事项列表有很多功能。虽然它可以作为一个简单的任务清单与提醒，它也支持一些轻量级的项目管理功能。它有一个完成百分比的滑块，可以从主列表视图中更新，这样你就可以跟踪进度。它能够附加文件和分配 1-10 的优先级。最后，它可以像其他日历约会一样将用户添加到任务中。

创建一个日记条目本质上是在日历上给自己创建一个笔记。它是一段形式自由的文本，就像写在实体笔记本和计划手册的某一天上那样。如果你要记录工作，写下每天的日记，或只是需要个地方记录会议记录，这个功能是非常方便的（本系列后面有更多关于这个的内容）。

Kontact Journal （Kevin Sonney, CC BY-SA 4.0）

构成 Kontact 的这些程序非常强大，如果你愿意的话，也可以作为单独的应用运行。Kontact 通过给你提供一个集中的地方，在一个应用内找到你所有的信息，从而提升了它们的实用性。

大多数发行版都允许你在没有 KDE 的情况下安装 Kontact 和它所使用的组件，但当它作为 KDE 桌面的一部分使用时，它才会真正发挥其作用。KDE 在 Fedora KDE 版、KUbuntu、KDE Neon（基于 Ubuntu LTS）和其他几个发行版中都是默认桌面。

via: https://opensource.com/article/21/1/kde-kontact

作者：Kevin Sonney 选题：lujun9972 译者：geekpi 校对：wxy

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

这是 Python 之禅特别系列的一部分，重点是第十和第十一条原则：沉默的错误（或不沉默）。

处理“异常情况”是编程中争论最多的问题之一。这可能是因为风险很大：处理不当的错误值甚至可以使庞大的系统瘫痪。由于“异常情况”从本质上来说，是测试不足的，但发生的频率却令人不快，因此，是否正确处理它们往往可以将一个噩梦般的系统与一个“可以工作”的系统区分开来。

从 Java 的 checked 异常，到 Erlang 的故障隔离，再到 Haskell 的 Maybe，不同的语言对错误处理的态度截然不同。

这两条 Python 之禅是 Python 对这个话题的冥思。

错误绝不应该悄悄传递... Errors should never pass silently…

当 Python 之禅在 Tim Peters 眼里闪烁而出之前，在维基百科被俗称为“维基”之前，第一个维基网站 C2 就已经存在了，它是一个编程指南的宝库。这些原则大多来自于 Smalltalk 编程社区。Smalltalk 的思想影响了许多面向对象的语言，包括 Python。

C2 维基定义了 武士原则 Samurai Principle ：“胜利归来，要么不归。”用 Python 人的术语来说，它鼓励摒弃 哨兵值 sentinel value ，比如用返回 None 或 -1 来表示无法完成任务，而是采用引发异常的方式。一个 None 是无声的：它看起来像一个值，可以放在一个变量中，然后到处传递。有时，它甚至是一个有效的返回值。

这里的原则是，如果一个函数不能完成它的契约，它应该“高调失败”：引发一个异常。所引发的异常永远不会看起来像是一个可能的值。它将跳过 returned_value = call_to_function(parameter) 行，并上升到调用栈中，可能使程序崩溃。

崩溃的调试是很直接的：有一个堆栈跟踪来指示问题以及调用堆栈。崩溃可能意味着程序的必要条件没有满足，需要人为干预。它可能意味着程序的逻辑有问题。无论是哪种情况，高调失败都比一个隐藏的、“缺失”的值要好。用 None 来感染程序的有效数据，直到它被用在某个地方，就如你可能已经知道的，错误信息会说 “None 没有方法进行拆分”。

除非显式消除 Unless explicitly silenced

有时需要显式地捕获异常。我们可能会预见到文件中的某些行格式错误，并希望以特殊的方式来处理它们，也许可以把它们放在一个“需要人来看看的行”的文件中，而不是让整个程序崩溃。

Python 允许我们用 except 来捕获异常。这意味着错误可以被显式消除。这种明确性意味着 except 行在代码审查中是可见的。质疑为什么应该在这里显式消除异常并从异常中恢复，是有意义的。自问一下我们是否捕获了太多或太少的异常也是有意义的。

因为这些全都是明确的，所以有人可以阅读代码并了解哪些异常是可以恢复的。

via: https://opensource.com/article/19/12/zen-python-errors

作者：Moshe Zadka 选题：lujun9972 译者：wxy 校对：wxy

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