2021年5月

在过去的几天中,我编写了一个叫作 dnspeep 的小工具,它能让你看到你电脑中正进行的 DNS 查询,并且还能看得到其响应。它现在只有 250 行 Rust 代码

我会讨论如何去尝试它、能做什么、为什么我要编写它,以及当我在开发时所遇到的问题。

如何尝试

我构建了一些二进制文件,因此你可以快速尝试一下。

对于 Linux(x86):

wget https://github.com/jvns/dnspeep/releases/download/v0.1.0/dnspeep-linux.tar.gz
tar -xf dnspeep-linux.tar.gz
sudo ./dnspeep

对于 Mac:

wget https://github.com/jvns/dnspeep/releases/download/v0.1.0/dnspeep-macos.tar.gz
tar -xf dnspeep-macos.tar.gz
sudo ./dnspeep

它需要以 超级用户 root 身份运行,因为它需要访问计算机正在发送的所有 DNS 数据包。 这与 tcpdump 需要以超级身份运行的原因相同:它使用 libpcap,这与 tcpdump 使用的库相同。

如果你不想在超级用户下运行下载的二进制文件,你也能在 https://github.com/jvns/dnspeep 查看源码并且自行编译。

输出结果是什么样的

以下是输出结果。每行都是一次 DNS 查询和响应:

$ sudo dnspeep
query   name                 server IP      response
A       firefox.com          192.168.1.1    A: 44.235.246.155, A: 44.236.72.93, A: 44.236.48.31
AAAA    firefox.com          192.168.1.1    NOERROR
A       bolt.dropbox.com     192.168.1.1    CNAME: bolt.v.dropbox.com, A: 162.125.19.131

这些查询是来自于我在浏览器中访问的 neopets.com,而 bolt.dropbox.com 查询是因为我正在运行 Dropbox 代理,并且我猜它不时会在后台运行,因为其需要同步。

为什么我要开发又一个 DNS 工具?

之所以这样做,是因为我认为当你不太了解 DNS 时,DNS 似乎真的很神秘!

你的浏览器(和你电脑上的其他软件)一直在进行 DNS 查询,我认为当你能真正看到请求和响应时,似乎会有更多的“真实感”。

我写这个也把它当做一个调试工具。我想“这是 DNS 的问题?”的时候,往往很难回答。我得到的印象是,当尝试检查问题是否由 DNS 引起时,人们经常使用试错法或猜测,而不是仅仅查看计算机所获得的 DNS 响应。

你可以看到哪些软件在“秘密”使用互联网

我喜欢该工具的一方面是,它让我可以感知到我电脑上有哪些程序正使用互联网!例如,我发现在我电脑上,某些软件出于某些理由不断地向 ping.manjaro.org 发送请求,可能是为了检查我是否已经连上互联网了。

实际上,我的一个朋友用这个工具发现,他的电脑上安装了一些以前工作时的企业监控软件,但他忘记了卸载,因此你甚至可能发现一些你想要删除的东西。

如果你不习惯的话, tcpdump 会令人感到困惑

当我试图向人们展示他们的计算机正在进行的 DNS 查询时,我的第一感是想“好吧,使用 tcpdump”!而 tcpdump 确实可以解析 DNS 数据包!

例如,下方是一次对 incoming.telemetry.mozilla.org. 的 DNS 查询结果:

11:36:38.973512 wlp3s0 Out IP 192.168.1.181.42281 > 192.168.1.1.53: 56271+ A? incoming.telemetry.mozilla.org. (48)
11:36:38.996060 wlp3s0 In  IP 192.168.1.1.53 > 192.168.1.181.42281: 56271 3/0/0 CNAME telemetry-incoming.r53-2.services.mozilla.com., CNAME prod.data-ingestion.prod.dataops.mozgcp.net., A 35.244.247.133 (180)

绝对可以学着去阅读理解一下,例如,让我们分解一下查询:

192.168.1.181.42281 > 192.168.1.1.53: 56271+ A? incoming.telemetry.mozilla.org. (48)

  • A? 意味着这是一次 A 类型的 DNS 查询
  • incoming.telemetry.mozilla.org. 是被查询的名称
  • 56271 是 DNS 查询的 ID
  • 192.168.1.181.42281 是源 IP/端口
  • 192.168.1.1.53 是目的 IP/端口
  • (48) 是 DNS 报文长度

在响应报文中,我们可以这样分解:

56271 3/0/0 CNAME telemetry-incoming.r53-2.services.mozilla.com., CNAME prod.data-ingestion.prod.dataops.mozgcp.net., A 35.244.247.133 (180)

  • 3/0/0 是在响应报文中的记录数:3 个回答,0 个权威记录,0 个附加记录。我认为 tcpdump 甚至只打印出回答响应报文。
  • CNAME telemetry-incoming.r53-2.services.mozilla.comCNAME prod.data-ingestion.prod.dataops.mozgcp.net.A 35.244.247.133 是三个响应记录。
  • 56271 是响应报文 ID,和查询报文的 ID 相对应。这就是你如何知道它是对前一行请求的响应。

我认为,这种格式最难处理的是(作为一个只想查看一些 DNS 流量的人),你必须手动匹配请求和响应,而且它们并不总是相邻的行。这就是计算机擅长的事情!

因此,我决定编写一个小程序(dnspeep)来进行匹配,并排除一些我认为多余的信息。

我在编写时所遇到的问题

在撰写本文时,我遇到了一些问题:

  • 我必须给 pcap 包打上补丁,使其能在 Mac 操作系统上和 Tokio 配合工作(这个更改)。这是其中的一个 bug,花了很多时间才搞清楚,用了 1 行代码才解决 :smiley:
  • 不同的 Linux 发行版似乎有不同的 libpcap.so 版本。所以我不能轻易地分发一个动态链接 libpcap 的二进制文件(你可以 在这里 看到其他人也有同样的问题)。因此,我决定在 Linux 上将 libpcap 静态编译到这个工具中。但我仍然不太了解如何在 Rust 中正确做到这一点作,但我通过将 libpcap.a 文件复制到 target/release/deps 目录下,然后直接运行 cargo build,使其得以工作。
  • 我使用的 dns_parser carte 并不支持所有 DNS 查询类型,只支持最常见的。我可能需要更换一个不同的工具包来解析 DNS 数据包,但目前为止还没有找到合适的。
  • 因为 pcap 接口只提供原始字节(包括以太网帧),所以我需要 编写代码来计算从开头剥离多少字节才能获得数据包的 IP 报头。我很肯定我还遗漏了一些情形。

我对于给它取名也有过一段艰难的时光,因为已经有许多 DNS 工具了(dnsspy!dnssnoop!dnssniff!dnswatch!)我基本上只是查了下有关“监听”的每个同义词,然后选择了一个看起来很有趣并且还没有被其他 DNS 工具所占用的名称。

该程序没有做的一件事就是告诉你哪个进程进行了 DNS 查询,我发现有一个名为 dnssnoop 的工具可以做到这一点。它使用 eBPF,看上去很酷,但我还没有尝试过。

可能会有许多 bug

我只在 Linux 和 Mac 上简单测试了一下,并且我已知至少有一个 bug(不支持足够多的 DNS 查询类型),所以请在遇到问题时告知我!

尽管这个 bug 没什么危害,因为这 libpcap 接口是只读的。所以可能发生的最糟糕的事情是它得到一些它无法解析的输入,最后打印出错误或是崩溃。

编写小型教育工具很有趣

最近,我对编写小型教育的 DNS 工具十分感兴趣。

到目前为止我所编写的工具:

以前我尽力阐述已有的工具(如 digtcpdump)而不是编写自己的工具,但是经常我发现这些工具的输出结果让人费解,所以我非常关注以更加友好的方式来看这些相同的信息,以便每个人都能明白他们电脑正在进行的 DNS 查询,而不仅仅是依赖 tcmdump。


via: https://jvns.ca/blog/2021/03/31/dnspeep-tool/

作者:Julia Evans 选题:lujun9972 译者:wyxplus 校对:wxy

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

SigNoz 帮助开发者使用最小的精力快速实现他们的可观测性目标。

 title=

SigNoz 是一个开源的应用可观察性平台。SigNoz 是用 React 和 Go 编写的,它从头到尾都是为了让开发者能够以最小的精力尽快实现他们的可观察性目标。

本文将详细介绍该软件,包括架构、基于 Kubernetes 的部署以及一些常见的 SigNoz 用途。

SigNoz 架构

SigNoz 将几个组件捆绑在一起,创建了一个可扩展的、耦合松散的系统,很容易上手使用。其中一些最重要的组件有:

  • OpenTelemetry Collector
  • Apache Kafka
  • Apache Druid

OpenTelemetry Collector 是跟踪或度量数据收集引擎。这使得 SigNoz 能够以行业标准格式获取数据,包括 Jaeger、Zipkin 和 OpenConsensus。之后,收集的数据被转发到 Apache Kafka。

SigNoz 使用 Kafka 和流处理器来实时获取大量的可观测数据。然后,这些数据被传递到 Apache Druid,它擅长于存储这些数据,用于短期和长期的 SQL 分析。

当数据被扁平化并存储在 Druid 中,SigNoz 的查询服务可以查询并将数据传递给 SigNoz React 前端。然后,前端为用户创建漂亮的图表,使可观察性数据可视化。

 title=

安装 SigNoz

SigNoz 的组件包括 Apache Kafka 和 Druid。这些组件是松散耦合的,并协同工作,以确保终端用户的无缝体验。鉴于这些组件,最好将 SigNoz 作为 Kubernetes 或 Docker Compose(用于本地测试)上的微服务组合来运行。

这个例子使用基于 Kubernetes Helm Chart 的部署在 Kubernetes 上安装 SigNoz。作为先决条件,你需要一个 Kubernetes 集群。如果你没有可用的 Kubernetes 集群,你可以使用 MiniKubeKind 等工具,在你的本地机器上创建一个测试集群。注意,这台机器至少要有 4GB 的可用空间才能工作。

当你有了可用的集群,并配置了 kubectl 来与集群通信,运行:

$ git clone https://github.com/SigNoz/signoz.git && cd signoz
$ helm dependency update deploy/kubernetes/platform
$ kubectl create ns platform
$ helm -n platform install signoz deploy/kubernetes/platform
$ kubectl -n platform apply -Rf deploy/kubernetes/jobs
$ kubectl -n platform apply -f deploy/kubernetes/otel-collector

这将在集群上安装 SigNoz 和相关容器。要访问用户界面 (UI),运行 kubectl port-forward 命令。例如:

$ kubectl -n platform port-forward svc/signoz-frontend 3000:3000

现在你应该能够使用本地浏览器访问你的 SigNoz 仪表板,地址为 http://localhost:3000

现在你的可观察性平台已经建立起来了,你需要一个能产生可观察性数据的应用来进行可视化和追踪。对于这个例子,你可以使用 HotROD,一个由 Jaegar 团队开发的示例应用。

要安装它,请运行:

$ kubectl create ns sample-application
$ kubectl -n sample-application apply -Rf sample-apps/hotrod/

探索功能

现在你应该有一个已经安装合适仪表的应用,并可在演示设置中运行。看看 SigNoz 仪表盘上的指标和跟踪数据。当你登录到仪表盘的主页时,你会看到一个所有已配置的应用列表,这些应用正在向 SigNoz 发送仪表数据。

 title=

指标

当你点击一个特定的应用时,你会登录到该应用的主页上。指标页面显示最近 15 分钟的信息(这个数字是可配置的),如应用的延迟、平均吞吐量、错误率和应用目前访问最高的接口。这让你对应用的状态有一个大概了解。任何错误、延迟或负载的峰值都可以立即看到。

 title=

追踪

追踪页面按时间顺序列出了每个请求的高层细节。当你发现一个感兴趣的请求(例如,比预期时间长的东西),你可以点击追踪,查看该请求中发生的每个行为的单独时间跨度。下探模式提供了对每个请求的彻底检查。

 title=

 title=

用量资源管理器

大多数指标和跟踪数据都非常有用,但只在一定时期内有用。随着时间的推移,数据在大多数情况下不再有用。这意味着为数据计划一个适当的保留时间是很重要的。否则,你将为存储支付更多的费用。用量资源管理器提供了每小时、每一天和每一周获取数据的概况。

 title=

添加仪表

到目前为止,你一直在看 HotROD 应用的指标和追踪。理想情况下,你会希望对你的应用进行检测,以便它向 SigNoz 发送可观察数据。参考 SigNoz 网站上的仪表概览

SigNoz 支持一个与供应商无关的仪表库,OpenTelemetry,作为配置仪表的主要方式。OpenTelemetry 提供了各种语言的仪表库,支持自动和手动仪表。

了解更多

SigNoz 帮助开发者快速开始度量和跟踪应用。要了解更多,你可以查阅 文档,加入社区,并访问 GitHub 上的源代码。


via: https://opensource.com/article/21/4/observability-apache-kafka-signoz

作者:Nitish Tiwari 选题:lujun9972 译者:geekpi 校对:wxy

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

Linus Torvalds 认为 GPL 是 Linux 成功的重要部分

Linux 创始人 Linus Torvalds 接受邮件采访回顾了 Linux 的三十年。Torvalds 说开发 Linux 时他真的没有想得太远,更多是一种概念验证,向外展示下他过去几个月的工作成果,更好的理解他的新 PC 硬件。Linux 最初是作为替代品提供给负担不起昂贵的商业 UNIX 系统的人,因此它采用的许可证是不能商业使用。当有人想通过软盘在本地的 Unix 用户组分发 Linux 但想要至少收回软盘的费用后,他切换到了 GPL 许可证。随后基于软盘的发行版 SLS 和 Slackware 就诞生了。他相信选择 GPL 是 Linux 以及 Git 成功的一个重要部分。他认为 GPLv2 完美的平衡了“每个人在相同规则下的工作”。

虽然不是每个开源软件都喜欢 GPL,但是如果没有 GPL ,或许不会有如今的 Linux 和整个开源世界。

奇亚币占用超过 1EB 存储空间

据报道,在过去的一个月时间里,分配给奇亚币(CHIA)的硬盘空间从 120PB 一直增加到 1143PB,也就是 1.14 EB,相当于 6 万多个 20TB 硬盘,奇亚币已经让硬件市场形成了一个新的领域。

奇亚币是以硬盘空间和时间来作为资源,利用 CPU 或者显卡通过某种算法将硬盘空间写入数据,用户将数据存储在硬盘上一段时间,赢得奖励的机会和分配的空间成正比。简单来说的话就是程序在你硬盘上写满了彩票号码,服务器会不时随机抽奖,分配的硬盘空间越大,在线时间越长,中奖的可能性越大。这迫使挖奇亚币需要尽可能扩充存储空间容量和长时间运行,事实上除了耗损硬盘,内存的消耗也很大,整个系统各个模块加起来的耗电量也不低。

比特币、以太坊等一直被批评空耗能源和处理能力而挖掘无用的加密货币,而奇亚币则把没被其它加密货币利用的存储能力也利用了。以至于计算机用户们哀叹显卡、CPU 之后,硬盘也买不到了。

Opera 原生支持 IPFS

Opera 宣布原生支持点对点协议 IPFS(星际文件系统)。在这之前,Brave 成为首个支持 IPFS 点对点协议的浏览器。IPFS 类似 BitTorrent,设计作为去中心化储存系统,允许用户在数百甚至数千个节点之间共享内容。

IPFS 的理想非常好,但是可能与现实的兼容性有点问题。

4 月 20 日,全世界都知道了明尼苏达大学(UMN)进行的一项研究计划,该计划涉及提交有意的错误补丁以纳入 Linux 内核。从那时起,由这项工作产生的一篇论文被撤回了,各种信件来来回回,来自 UMN 的许多补丁被审计。显然,现在是时候对情况进行更新了。

LCTT 译注:明尼苏达大学“伪君子提交”这件事引发了开源和技术社区的很多争议,我们也一直关注此事,本文是 LWN 编辑对事件后继发展的总结和观点。

关于这项研究的论文的撰写并不是最近事件的直接原因;相反,它是由 UMN 的另一位开发者发布的一个源于实验性静态分析工具的错误补丁引起的。这导致内核社区的开发者怀疑,提交故意恶意补丁的工作仍在进行。情况显然不是这样的,但当整个故事变得清晰时,讨论已经全面进行了。

LCTT 译注:提交“实验性静态分析工具的错误补丁”的开发者也是 UMN “伪君子提交”研究团队的成员,只是按该团队的说法,“伪君子提交”研究已经结束,最近引发争议的补丁来自另外一个项目。

老话仍然适用:不应该把那些可以充分解释为无能的东西归结为恶意。

4 月 22 日,Linux 基金会技术顾问委员会(TAB,写作本文的 LWN 编辑是该委员会的成员)发表了一份简短的声明,指出,除其他事项外,最近的补丁似乎是真诚地提交的。同时,Linux 基金会和 TAB 给 UMN 的研究人员发了一封信,概述了应该如何处理这种情况;该信没有公开发布,但 ZDNet 显然从某个地方得到了一份副本。除其他事项外,信中要求完全公开作为 UMN 项目的一部分而发送的错误补丁,并要求撤回这项工作所产生的论文。

作为回应,UMN 的研究人员发布了一封公开信,向社区道歉,几天后又发布了他们作为“伪君子提交”项目的一部分所做工作的总结。总共有五个补丁是从两个 sock-puppet 账户提交的,但其中一个是普通的 bug 修复,被错误地从这个错误的账户发送。在剩下的四个补丁中,其中一个是试图插入一个 bug,但是它本身没插入成功,所以这个补丁实际上是有效的;另外三个(123)包含真正的 bug,这三个都没有被维护者接受,尽管拒绝的原因不一定是有关的 bug。

LCTT 译注:根据 UMN 团队发布的总结:

  • 第一个补丁是以“伪君子提交”而发出的,但是后来实际检查发现实际解决了问题,于是 UMN 团队就没有阻止该补丁被合入。
  • 第二个补丁没有合入,但是内核维护者说之前有个别人的类似实现的补丁合并过,后来发现有问题而被别人撤销了。
  • 第三个补丁没有合入,内核维护者发现了一个问题而没有接受,但是其实该补丁还有另外一个问题并没有被发现。
  • 第四个补丁没有合入,和上一个类似,内核维护者没有发现有意放入的缺陷,而是找到另外的编码问题,因此没有合入。
  • 第五个补丁是有效的补丁,但不是这个项目的,使用了错误的邮箱发出的。

论文本身已被撤回,不会按原计划在 5 月提交。希望大家可以认为 UMN 在短期内不会再进行类似的研究了。

LCTT 译注:在原文下面有不少评论认为这个研究方向应该继续下去,只是方式方法需要改善。

补丁的重新审查

UMN 活动引起的关注的一个直接结果是,人们对其开发者失去了信任,加上某些方面希望采取某种惩罚性行动。因此,当整个事件爆发时,首先发生的事情之一是 Greg Kroah-Hartman(GKH)发布了一个由 190 个部分组成的补丁系列,以撤销他能找到的尽可能多的 UMN 的补丁。事实上,这并不是所有的补丁;他提到了另外 68 个需要人工审查的补丁清单,因为它们不容易撤销。

碰巧的是,这些“容易撤销”的补丁也需要人工审查;一旦最初的愤怒过去,就没有什么愿望去恢复那些实际上没有错误的补丁。在过去的一周里,这种审查过程一直在进行,一些开发人员在为之努力。大多数可疑的补丁被证明是可以接受的(即使不是很好),已经从撤销列表中删除了;如果本文作者的计数是正确的,仍有 42 个补丁将被从内核中撤出。

对于这 42 个补丁,撤销背后的原因各不相同。在某些情况下,这些补丁适用于旧的、可能是未使用的驱动程序,而且没有人愿意去适当地审查它们。在其他情况下,其希望实现的变更做得很差,将以更好的方式重新实现。而有些补丁包含了严重的错误;这些肯定需要被恢复(而且一开始就不应该被接受)。

不过,看一下全套的 UMN 补丁,印证了一些我们的早期印象。首先,几乎所有的补丁都解决了某种真正的(即使是晦涩难懂的且难以解决)问题;为之写一个补丁是有理由的。虽然这些补丁中有许多显示出对代码的理解程度很低,因此包含了错误,但似乎其中任何一个修复程序的意图都不大可能是恶意的。

也就是说,“恶意”有多种定义。对一些相关的开发者来说,发布未经验证的实验性静态分析工具的补丁而不披露其性质是一种恶意行为。这是另一种涉及未经同意的人类的实验形式。至少,这是对内核开发社区有效工作所需的信任的一种侵犯。

LCTT 译注:如果研究涉及到人类,为了避免人类受到伤害,需要取得人类同意,这就是研究需要得到 IRB 许可的原因。UMN 认为 “伪君子提交” 不是针对人类的研究,给予了 IRB 免除许可。在这个事件中,有人对 UMN IRB 的意见也很大,而且怀疑 IRB 是否有能力对计算机相关研究给出有效判断。

这 190 个补丁中有 42 个坏补丁,坏补丁比率是 22%。很有可能,对几乎任何一个内核开发者的 190 个补丁进行详细审查,都会发现一些回想起来并不是一个好主意的补丁。但愿这个比率不会接近 22%。但必须说的是,所有这些补丁都被整个内核的子系统维护者所接受,这不是一个好的结果。也许这比最初的“伪君子提交”的研究人员所寻找的结果更有意思。他们故意插入 bug 的努力失败了,但却在无意中增加几十个 bug

同时,还有一份不能干净地撤销的补丁清单。这个名单还没有公布,但 GKH 是从其中的七个子集开始的。他还指出,TAB 将在所有这些补丁的审计工作完成后公布一份完整的报告。到目前为止,这些补丁中还没有任何一个在主线上被撤销;这似乎有可能在 5.13 合并窗口结束时发生。

吸取的教训

从这一系列事件中得到的关键教训之一显然是:不要把自由软件开发社区作为你的实验性工具的一种免费验证服务。内核开发者很高兴看到新工具的产生,并且 —— 如果这些工具能带来好的结果 —— 就使用它们。他们也会帮助测试这些工具,但他们不太乐意成为缺乏适当审查和解释的工具产生的补丁的接受者。

另一个教训是我们已经知道的:内核维护者(以及许多其他自由软件项目的维护者)工作压力过度,没有时间正确地审查经过他们手中的每一个补丁。因此,他们不得不依赖向他们提交补丁的开发者的可信度。可以说,当这种信任得到妥善建立时,内核开发过程是勉强可持续的;如果通常无法信任进入的补丁时,那么它将无法维持下去。

推论 —— 也是我们已经知道的 —— 是进入内核的代码往往不像我们所想的那样得到很好的审查。我们希望相信每一行被合并的代码都经过了高质量的内核开发人员的仔细审查。有些代码确实得到了这种审查,但不是所有的代码。例如,考虑一下 5.12 开发周期(一个相对较小的周期),它在十周的时间里向内核添加了超过 50 万行的代码。仔细审查 50 万行代码所需的资源将是巨大的,因此,不幸的是,其中许多行在被合并之前只得到了粗略的审查而已。

最后一个教训是,人们可能倾向于认为内核正面临着被具有比 UMN 研究人员所展示的更多技能和资源的行为者插入恶意补丁的可怕风险。这可能是事实,但事情的简单真相是,正规的内核开发者继续以这样的速度插入错误,恶意行为者应该没有什么必要增加更多。2 月份发布的 5.11 内核,到 5.11.17 为止,在稳定更新中已经积累了 2281 个修复。如果我们做一个(过于简单的)假设,即每个修复都会修正一个原始的 5.11 补丁,那么进入 5.11 的补丁中有 16%(到目前为止)被证明是有错误的。这并不比 UMN 补丁的比率好多少。

所以,这也许是我们从整个经历中得到的真正教训:内核处理流程的速度是它最好的属性之一,我们都依赖它来尽可能快地获得功能。但是这种速度可能与严肃的补丁审查和低数量的错误不相容。在一段时间内,我们可能会看到处理变得有点慢,因为维护者觉得有必要更仔细地审查变化,特别是那些来自新的开发人员。但是,如果我们不能将更谨慎的处理流程制度化,我们将继续看到大量的 bug,而这些 bug 是否是故意插入的,其实并不重要。


via: https://lwn.net/SubscriberLink/854645/334317047842b6c3/

作者:Jonathan Corbet 译者:wxy 校对:wxy

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

与 Yaru 团队合作,Ubuntu MATE 带来了一个主题大修、一系列有趣的功能和性能改进。

自从 18.10 发行版以来,Yaru 一直都是 Ubuntu 的默认用户桌面,今年,Yaru 团队与Canonical Design 和 Ubuntu 桌面团队携手合作,为 Ubuntu MATE 21.04 创建了新的外观界面。

Ubuntu MATE 21.04 有什么新变化?

以下就是 Ubuntu MATE 21.04 此次发布中的关键变化:

MATE 桌面

此次更新的 MATE 桌面相比以往并没有较大改动,此次只是修复了错误 BUG 同时更新了语言翻译,Debian 中的 MATE 软件包已经更新,用户可以下载所有的 BUG 修复和更新。

Avatana 指示器

这是一个控制面板指示器(也称为系统托盘)的动作、布局和行为的系统。现在,你可以从控制中心更改 Ayatana 指示器的设置。

添加了一个新的打印机标识,并删除了 RedShift 以保持稳定。

Yaru MATE 主题

Yaru MATE 现在是 Yaru 主题的派生产品。Yaru MATE 将提供浅色和深色主题,浅色作为默认主题。来确保更好的应用程序兼容性。

从现在开始,用户可以使用 GTK 2.x、3.x、4.x 浅色和深色主题,也可以使用 Suru 图标以及一些新的图标。

LibreOffice 在 MATE 上会有新的默认桌面图标,字体对比度也得到了改善。你会发现阅读小字体文本或远距离阅读更加容易。

如果在系统层面选择了深色模式,网站将维持深色。要让网站和系统的其它部分一起使用深色主题,只需启用 Yaru MATE 深色主题即可。

现在,Macro、Metacity 和 Compiz 的管理器主题使用了矢量图标。这意味着,如果你的屏幕较大,图标不会看起来像是像素画,又是一个小细节!

Yaru MATE Snap 包

尽管你现在无法安装 MATE 主题,但是不要着急,它很快就可以了。gtk-theme-yaru-mate 和 icon-theme-yaru-mate Snap 包是预安装的,可以在需要将主题连接到兼容的 Snap 软件包时使用。

根据官方发布的公告,Snapd 很快就会自动将你的主题连接到兼容的 Snap 包:

Snapd 很快就能自动安装与你当前活动主题相匹配的主题的 snap 包。我们创建的 snap 包已经准备好在该功能可用时与之整合。

Mutiny 布局的新变化

应用了深色主题的 Mutiny 布局

Mutiny 布局模仿了 Unity 的桌面布局。删除了 MATE 软件坞小应用,并且对 Mutiny 布局进行了优化以使用 Plank。Plank 会被系统自动应用主题。这是通过 Mate Tweak 切换到 Mutiny 布局完成的。Plank 的深色和浅色 Yaru 主题都包含在内。

其他调整和更新使得 Mutiny 在不改变整体风格的前提下具备了更高的可靠性

主要应用升级

  • Firefox 87(火狐浏览器)
  • LibreOffice 7.1.2.2(办公软件)
  • Evolution 3.40(邮件)
  • Celluloid 0.20(视频播放器)

其他更改

  • Linux 命令的忠实用户会喜欢在 Ubuntu MATE 中默认安装的 neofetchhtopinxi 之类的命令。
  • 树莓派的 21.04 版本很快将会发布。
  • Ubuntu MATE 上没有离线升级选项。
  • 针对侧边和底部软件坞引入了新的 Plank 主题,使其与 Yaru MATE 的配色方案相匹配。
  • Yaru MATE 的窗口管理器为侧边平铺的窗口应用了简洁的边缘风格。
  • Ubuntu MATE 欢迎窗口有多种色彩可供选择。
  • Yaru MATE 主题和图标主题的快照包已在 Snap Store 中发布。
  • 为 Ubuntu MATE 20.04 LTS 的用户发布了 Yaru MATE PPA。

下载 Ubuntu MATE 21.04

你可以从官网上下载镜像:

如果你对此感兴趣,请查看发行说明

你对尝试新的 Yaru MATE 感到兴奋吗?你觉得怎么样?请在下面的评论中告诉我们。


via: https://news.itsfoss.com/ubuntu-mate-21-04-release/

作者:Asesh Basu 选题:lujun9972 译者:Kevin3599 校对:wxy

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

曾经苹果也想让 Flash 运行在 iPhone 上

iPhone 和 iPad 从未支持过 Flash,对许多人来说,这是一个相当大的缺点。乔布斯本人表示过,苹果公司无意将 Flash 引入 iOS。但事实证明,乔布斯并不是不想让 Flash 出现在 iPhone 和 iPad 上。苹果公司的前高管在 Epic 诉苹果案中提供了一份证词,泄漏了 Adobe 和苹果在 Flash 方面的工作,“我们试图让 Flash 发挥作用……我们绝对有兴趣。当我们让它在 iOS 上运行时,它的性能简直是糟糕透顶,令人尴尬。”

当年如此流行的 Flash 最终却是因为问题多到补不胜补而被放弃。

争议之下,纽约警方将其配备的机器狗退回波士顿动力

纽约警察局去年开始租赁这种昵称为 Digidog 的机器人。该机器人在其任期内被部署了大约六次,主要是在潜在的敌对环境中充当移动摄像机。该部门在 2 月份说,“纽约市警察局自 20 世纪 70 年代以来一直在使用机器人,在人质及危险品事件中拯救生命。这个型号的机器人正在接受测试,以评估它的能力,与我们的紧急服务单位和拆弹小组使用的其他型号相比较。”

然而,许多人认为该机器人象征着警察开支的浪费和执法部门正在部署的越来越积极的战术。波士顿动力公司称这种机器从未被武器化,因为这样做会违反公司的服务条款,但它正被部署在越来越有争议的场合。巨大争议之下,纽约警察局取消了对美国公司波士顿动力公司制造的机器狗的试验。

虽然机器人(狗)用在特殊场景能减少很多危险,但是需要警惕的是机器人的使用是否会侵犯人类的空间。

《DNF》开发商购买 1 亿美元的比特币

韩国游戏戏开发商 Nexon 开发了《地下城与勇士》(DNF)、《冒险岛》等多款作品。据报道,Nexon 宣布已购买了价值 1 亿美元的 1717 枚比特币,成功加入了特斯拉等拥有数字货币的科技公司阵营。Nexon 表示,购买比特币也是 Nexon 的战略方向之一,在当下的经济环境当中,Nexon 相信,在确保公司未来投资和资产价值的同时,比特币能为公司资产提供持续的稳定性及流动性。

看来比特币是保持盈利的重要方法了。