2021年4月

正如我们昨天报道的,明尼苏达大学的研究人员被踢出了 Linux 贡献群体,Linux 内核社区撤销了之前他们提交的所有 Linux 内核代码,并且,以后默认拒绝所有来自该大学的内核贡献!

发生了什么?是什么让 Linux 内核社区勃然大怒?

这一切始于 2021 年 4 月 6 日对 Linux 内核的一个看似无辜的补丁。明尼苏达大学的一名博士生(Aditya Pakki)提交了一个一共只修改/增加了两行的小补丁

Signed-off-by: Aditya Pakki <[email protected]>
---
 net/rds/message.c | 1 +
 net/rds/send.c    | 2 +-
 2 files changed, 2 insertions(+), 1 deletion(-)

diff --git a/net/rds/message.c b/net/rds/message.c
index 071a261fdaab..90ebcfe5fe3b 100644
--- a/net/rds/message.c
+++ b/net/rds/message.c
@@ -180,6 +180,7 @@ void rds_message_put(struct rds_message *rm)
         rds_message_purge(rm);
 
         kfree(rm);
+        rm = NULL;
     }
 }
 EXPORT_SYMBOL_GPL(rds_message_put);
diff --git a/net/rds/send.c b/net/rds/send.c
index 985d0b7713ac..fe5264b9d4b3 100644
--- a/net/rds/send.c
+++ b/net/rds/send.c
@@ -665,7 +665,7 @@ static void rds_send_remove_from_sock(struct list_head *messages, int status)
 unlock_and_drop:
         spin_unlock_irqrestore(&rm->m_rs_lock, flags);
         rds_message_put(rm);
-        if (was_on_sock)
+        if (was_on_sock && rm)
             rds_message_put(rm);
     }
 

由于这个补丁很简单,而且似乎改善了代码的质量,它最初得到了一些成员的支持,但后来在 4 月 9 日受到了 Eric Dumazet 的质疑

而在 4 月 19 日,资深的内核贡献者 Al Viro 斥责该贡献者提交了一个“没有修复任何东西的补丁”。他指出了提交垃圾代码补丁的两种可能性:

简单地说,这个补丁要么显示出完全缺乏理解,要么显示出有人不真诚地行事。如果是后者[1],我可以建议尊敬的社会学家们滚蛋,不要再用故意喷出的排泄物来测试审核者了?

如果你觉得他用词太激烈了,这背后是有原因和历史的。

前不久,明尼苏达大学的博士生 Qiushi Wu 和助理教授 Kangjie Lu(看起来是中国人或华裔?)提交了一篇研究论文《论通过伪装提交在开源软件中隐蔽地引入漏洞的可行性》。据之前发布在明尼苏达大学的一篇新闻稿(已被删除),该论文被 2021 年 IEEE 安全与隐私研讨会接受:

CS&E 很荣幸地与大家分享博士生 Qiushi Wu 和助理教授 Kangjie Lu 为即将举行的第 42 届 IEEE 安全与隐私研讨会所撰写的论文。IEEE S&P 是展示计算机安全和电子隐私发展的首要论坛,并将该领域的研究人员和从业人员聚集在一起。

他们的论文《论通过伪装提交在开源软件中隐蔽地引入漏洞的可行性》集中讨论了开源软件的供应链安全。

“这项工作影响深远,”Lu 教授说,“供应链安全已经成为当今的一个重要话题。我们的论文已经引起了安全界和开源社区的极大兴趣。”

Wu 和 Lu 将在 5 月的虚拟会议期间展示他们的研究。

研究人员正在测试通过伪装提交在开源软件中隐蔽引入漏洞的可行性,也就是说,以看似有益的提交实际上引入了其他关键问题。结合最近发生的一些软件供应链攻击事件,看起来这是一篇很有意义的论文,也难怪会被 IEEE 会议接受。

然而,似乎他们选择了 Linux 内核项目来进行他们的实验来完成论文。Al Viro 发现,Aditya Pakki 的“无用补丁”很可能是这项研究的一部分。

对 Aditya Pakki 提交的另外一个补丁

     }
-    gss_release_msg(gss_msg);
+    if (gss_msg)
+        gss_release_msg(gss_msg);
 }

GKH 警告称,不要浪费内核维护者的时间提交这种补丁,Greg Kroah-Hartman(GKH)是仅次于 Linus Torvalds 的内核项目负责人:

请停止提交已知无效的补丁。你的教授正在玩弄审查程序,以便用一些奇怪的、怪异的方式实现一篇论文。
这是不对的,这是在浪费我们的时间,我们将不得不再次向你的大学报告此事……

显然,这不是唯一引起争议的补丁请求。而 Leon Romanovsky 指出,还有 3 个这样的补丁来自同一个研究人员,并认为这些补丁增加了安全漏洞:

他们故意引入内核错误。昨天,我看了一下从 Aditya 那里接受的 4 个补丁,其中 3 个增加了各种严重的安全 “漏洞”。

面对这些公开抨击,该大学的研究人员 Aditya Pakki 认为自己是受害者,指责内核维护者的态度

敬请停止胡乱指责,这近乎诽谤。

这些补丁是作为我写的一个新的静态分析器的一部分发送的,它的灵敏度显然不是很高。我发送补丁的目的是希望得到反馈。我们不是 Linux 内核方面的专家,反复发表这些言论让人听了很反感。

显然,这一步错了,但你的先入为主的偏见是如此强烈,你提出的指控毫无根据,这种怀疑也不会带来任何好处。

这种态度不仅让人讨厌,而且对新手和非专家也是一种恐吓,我再也不会发送任何补丁了。

这激怒了 GKH,他说:

你和你的团队,已经公开承认发送了有缺陷的补丁,以了解内核社区对它们的反应,并且发表了一篇基于这项工作的论文。现在你又提交了一系列新的有明显错误的补丁,那么我应该对这样的事情怎么看?

它们显然不是由一个有智慧的静态分析工具创建的,因为它们都是完全不同的模式的结果,而且所有这些显然根本没有修复任何东西。 那么,除了你和你的团队在继续通过发送这种无稽之谈的补丁对内核社区的开发者进行试验之外,我还能想到什么?

……

任何有 C 语言知识的人,只要花几分钟就能看出你提交的文件根本没有任何作用,所以认为一个工具创造了它们,然后你认为它们是一个有效的“修复”,这完全是你的疏忽,而不是我们的疏忽。你才是有错的人,我们的工作不是成为你创造的工具的测试对象。

……

我们的社区不喜欢被实验,也不喜欢通过提交已知的补丁来“测试”,这些补丁要么是故意什么都不做,要么是故意引入错误的。 如果你想做这样的工作,我建议你找一个不同的社区来进行你的实验,这里不欢迎你。

正因为如此,我现在不得不禁止你的大学今后的所有贡献,并撕掉你以前的贡献,因为它们显然是以恶意的方式提交的,目的就是为了造成问题。

随后,GKH 撤销了明尼苏达大学提交的大量补丁,GKH 表示:

我一直想这么做,但最近的事件终于迫使我这么做了。

……

这个小组提交的所有文件都必须从内核树上撤销,并需要再次进行审查,以确定它们是否真的是一个有效的修复。 在这项工作完成之前,请删除这些变更,以确保没有问题被引入代码库。

这个补丁集包含了“简单”的修正,还有 68 个需要人工审查的修正。 其中一些不能被恢复,因为它们已经被恢复了,或者被确定其为无效的后续补丁所修复。这证明这些提交的文件几乎都是错误的。

我将和其他一些内核开发者一起工作,以确定这些还原是否真的是有效的变更,如果是的话,以后会重新正确提交。就目前而言,还是安全为上。

我将通过我的开发树进行,所以维护者们不需要担心这个问题,但他们应该意识到,未来任何从 umn.edu 地址来的人提交的文件应该被默认拒绝,除非确定它实际上是一个有效的修复(即他们提供证据,你可以验证它,但是说真的,为什么要浪费你的时间做那些额外的工作?)

对此,你怎么看?

本文参考信息: lore.kernel.org、news.itsfoss.com。

Grafana、Loki 和 Tempo 改用 AGPLv3 许可证

过去几年,多个知名的开源项目如 Elastic、Redis Labs 和 MongoDB 出于盈利考虑而修改许可证,切换到非自由的商业授权许可证(SSPL)。开发 Grafana 以及 Loki 和 Tempo 等开源项目的 Grafana Labs 公司决定不这么做,它宣布旗下核心开源项目采用的许可证从 Apache License 2.0 切换到 AGPL v3,允许其他人自由修改和提供服务,但修改的版本需要回馈上游。Grafana Labs 公司表示,它这么做是试图在开源和社区的“价值创造”以及商业化策略的“价值获取”上取得平衡。

这也是一个不错的尝试,就是不知道 AGPL 是否能适当的保护开源项目,并与商业组织取得合适的平衡。

明尼苏达大学开发者被禁止向 Linux 内核提供代码

明尼苏达大学的 Qiushi Wu(博士生)和 Kangjie Lu(助理教授)提交了一篇研究论文《通过伪装的提交在开源软件中隐蔽地引入漏洞》,以看似有益的提交实际上引入了其他关键问题。而根据最近 Linux 内核接到的一些补丁来看,他们选择了 Linux 内核项目来进行他们的实验。

负责维护 Linux 内核的格雷(GKH)是仅次于 Linus 的负责人,他对这种行为进行了强烈谴责!但是发送这些补丁的人认为这只是他们写的一个静态分析器提交的补丁,最多只是质量不佳。格雷认为这些是谎言,愤怒之下决定禁止该大学向 Linux 内核提交代码,并撤销了他们之前提交的补丁。

简直是够了,Linux 内核不是试验场,供任何人随意摆弄。

Google 资助开发 OpenSSL 的替代品 Rustls

许多 SSL/TLS 库由于是用 C 语言编写的,所以安全问题由来已久。通过使用 Rust 开发的 OpenSSL 替代品 Rustls,开发人员可以尽可能确保代码是内存安全的,这将大大减少安全问题的数量。

互联网安全研究组(ISRG)宣布,谷歌已经为 Rust 开发者提供了资金,以对 Rustls 进行改进。ISRG 将使用 Rustls 来使 Apache HTTP 服务器更加安全。

期待看到 Rustls 能证明 Rust 的成功。

了解 Linux 如何使用库,包括静态库和动态库的差别,有助于你解决依赖问题。

 title=

Linux 从某种意义上来说就是一堆相互依赖的静态和动态库。对于 Linux 系统新手来说,库的整个处理过程简直是个迷。但对有经验的人来说,被构建进操作系统的大量共享代码对于编写新应用来说却是个优点。

为了让你熟悉这个话题,我准备了一个小巧的 应用例子 来展示在普通的 Linux 发行版(在其他操作系统上未验证)上是经常是如何处理库的。为了用这个例子来跟上这个需要动手的教程,请打开命令行输入:

$ git clone https://github.com/hANSIc99/library_sample
$ cd library_sample/
$ make
cc -c main.c -Wall -Werror
cc -c libmy_static_a.c -o libmy_static_a.o -Wall -Werror
cc -c libmy_static_b.c -o libmy_static_b.o -Wall -Werror
ar -rsv libmy_static.a libmy_static_a.o libmy_static_b.o
ar: creating libmy_static.a
a - libmy_static_a.o
a - libmy_static_b.o
cc -c -fPIC libmy_shared.c -o libmy_shared.o
cc -shared -o libmy_shared.so libmy_shared.o
$ make clean
rm *.o

当执行完这些命令,这些文件应当被添加进目录下(执行 ls 来查看):

my_app
libmy_static.a
libmy_shared.so

关于静态链接

当你的应用链接了一个静态库,这个库的代码就变成了可执行文件的一部分。这个动作只在链接过程中执行一次,这些静态库通常以 .a 扩展符结尾。

静态库是多个 目标 object 文件的 归档 archive ar)。这些目标文件通常是 ELF 格式的。ELF 是 可执行可链接格式 Executable and Linkable Format 的简写,它与多个操作系统兼容。

file 命令的输出可以告诉你静态库 libmy_static.aar 格式的归档文件类型。

$ file libmy_static.a
libmy_static.a: current ar archive

使用 ar -t,你可以看到归档文件的内部。它展示了两个目标文件:

$ ar -t libmy_static.a
libmy_static_a.o
libmy_static_b.o

你可以用 ax -x <archive-file> 命令来提取归档文件的文件。被提出的都是 ELF 格式的目标文件:

$ ar -x libmy_static.a
$ file libmy_static_a.o
libmy_static_a.o: ELF 64-bit LSB relocatable, x86-64, version 1 (SYSV), not stripped

关于动态链接

动态链接指的是使用共享库。共享库通常以 .so 的扩展名结尾(“ 共享对象 shared object ” 的简写)。

共享库是 Linux 系统中依赖管理的最常用方法。这些共享库在应用启动前被载入内存,当多个应用都需要同一个库时,这个库在系统中只会被加载一次。这个特性减少了应用的内存占用。

另外一个值得注意的地方是,当一个共享库的 bug 被修复后,所有引用了这个库的应用都会受益。但这也意味着,如果一个 bug 还没被发现,那所有相关的应用都会遭受这个 bug 影响(如果这个应用使用了受影响的部分)。

当一个应用需要某个特定版本的库,但是 链接器 linker 只知道某个不兼容版本的位置,对于初学者来说这个问题非常棘手。在这个场景下,你必须帮助链接器找到正确版本的路径。

尽管这不是一个每天都会遇到的问题,但是理解动态链接的原理总是有助于你修复类似的问题。

幸运的是,动态链接的机制其实非常简洁明了。

为了检查一个应用在启动时需要哪些库,你可以使用 ldd 命令,它会打印出给定文件所需的动态库:

$ ldd my_app
        linux-vdso.so.1 (0x00007ffd1299c000)
        libmy_shared.so => not found
        libc.so.6 => /lib64/libc.so.6 (0x00007f56b869b000)
        /lib64/ld-linux-x86-64.so.2 (0x00007f56b8881000)

可以注意到 libmy_shared.so 库是代码仓库的一部分,但是没有被找到。这是因为负责在应用启动之前将所有依赖加载进内存的动态链接器没有在它搜索的标准路径下找到这个库。

对新手来说,与常用库(例如 bizp2)版本不兼容相关的问题往往十分令人困惑。一种方法是把该仓库的路径加入到环境变量 LD_LIBRARY_PATH 中来告诉链接器去哪里找到正确的版本。在本例中,正确的版本就在这个目录下,所以你可以导出它至环境变量:

$ LD_LIBRARY_PATH=$(pwd):$LD_LIBRARY_PATH
$ export LD_LIBRARY_PATH

现在动态链接器知道去哪找库了,应用也可以执行了。你可以再次执行 ldd 去调用动态链接器,它会检查应用的依赖然后加载进内存。内存地址会在对象路径后展示:

$ ldd my_app
        linux-vdso.so.1 (0x00007ffd385f7000)
        libmy_shared.so => /home/stephan/library_sample/libmy_shared.so (0x00007f3fad401000)
        libc.so.6 => /lib64/libc.so.6 (0x00007f3fad21d000)
        /lib64/ld-linux-x86-64.so.2 (0x00007f3fad408000)

想知道哪个链接器被调用了,你可以用 file 命令:

$ file my_app
my_app: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, BuildID[sha1]=26c677b771122b4c99f0fd9ee001e6c743550fa6, for GNU/Linux 3.2.0, not stripped

链接器 /lib64/ld-linux-x86–64.so.2 是一个指向 ld-2.30.so 的软链接,它也是我的 Linux 发行版的默认链接器:

$ file /lib64/ld-linux-x86-64.so.2
/lib64/ld-linux-x86-64.so.2: symbolic link to ld-2.31.so

回头看看 ldd 命令的输出,你还可以看到(在 libmy_shared.so 边上)每个依赖都以一个数字结尾(例如 /lib64/libc.so.6)。共享对象的常见命名格式为:

libXYZ.so.<MAJOR>.<MINOR>

在我的系统中,libc.so.6 也是指向同一目录下的共享对象 libc-2.31.so 的软链接。

$ file /lib64/libc.so.6
/lib64/libc.so.6: symbolic link to libc-2.31.so

如果你正在面对一个应用因为加载库的版本不对导致无法启动的问题,有很大可能你可以通过检查整理这些软链接或者确定正确的搜索路径(查看下方“动态加载器:ld.so”一节)来解决这个问题。

更为详细的信息请查看 ldd 手册页

动态加载

动态加载的意思是一个库(例如一个 .so 文件)在程序的运行时被加载。这是使用某种特定的编程方法实现的。

当一个应用使用可以在运行时改变的插件时,就会使用动态加载。

查看 dlopen 手册页 获取更多信息。

动态加载器:ld.so

在 Linux 系统中,你几乎总是正在跟共享库打交道,所以必须有个机制来检测一个应用的依赖并将其加载进内存中。

ld.so 按以下顺序在这些地方寻找共享对象:

  1. 应用的绝对路径或相对路径下(用 GCC 编译器的 -rpath 选项硬编码的)
  2. 环境变量 LD_LIBRARY_PATH
  3. /etc/ld.so.cache 文件

需要记住的是,将一个库加到系统库归档 /usr/lib64 中需要管理员权限。你可以手动拷贝 libmy_shared.so 至库归档中来让应用可以运行,而避免设置 LD_LIBRARY_PATH

unset LD_LIBRARY_PATH
sudo cp libmy_shared.so /usr/lib64/

当你运行 ldd 时,你现在可以看到归档库的路径被展示出来:

$ ldd my_app
        linux-vdso.so.1 (0x00007ffe82fab000)
        libmy_shared.so => /lib64/libmy_shared.so (0x00007f0a963e0000)
        libc.so.6 => /lib64/libc.so.6 (0x00007f0a96216000)
        /lib64/ld-linux-x86-64.so.2 (0x00007f0a96401000)

在编译时定制共享库

如果你想你的应用使用你的共享库,你可以在编译时指定一个绝对或相对路径。

编辑 makefile(第 10 行)然后通过 make -B 来重新编译程序。然后 ldd 输出显示 libmy_shared.so 和它的绝对路径一起被列出来了。

把这个:

CFLAGS =-Wall -Werror -Wl,-rpath,$(shell pwd)

改成这个(记得修改用户名):

CFLAGS =/home/stephan/library_sample/libmy_shared.so

然后重新编译:

$ make

确认下它正在使用你设定的绝对路径,你可以在输出的第二行看到:

$ ldd my_app
    linux-vdso.so.1 (0x00007ffe143ed000)
        libmy_shared.so => /lib64/libmy_shared.so (0x00007fe50926d000)
        /home/stephan/library_sample/libmy_shared.so (0x00007fe509268000)
        libc.so.6 => /lib64/libc.so.6 (0x00007fe50909e000)
        /lib64/ld-linux-x86-64.so.2 (0x00007fe50928e000)

这是个不错的例子,但是如果你在编写给其他人用的库,它是怎样工作的呢?新库的路径可以通过写入 /etc/ld.so.conf 或是在 /etc/ld.so.conf.d/ 目录下创建一个包含路径的 <library-name>.conf 文件来注册至系统。之后,你必须执行 ldconfig 命令来覆写 ld.so.cache 文件。这一步有时候在你装了携带特殊的共享库的程序来说是不可省略的。

查看 ld.so 的手册页 获取更多详细信息。

怎样处理多种架构

通常来说,32 位和 64 位版本的应用有不同的库。下面列表展示了不同 Linux 发行版库的标准路径:

红帽家族

  • 32 位:/usr/lib
  • 64 位:/usr/lib64

Debian 家族

  • 32 位:/usr/lib/i386-linux-gnu
  • 64 位:/usr/lib/x86_64-linux-gnu

Arch Linux 家族

  • 32 位:/usr/lib32
  • 64 位:/usr/lib64

FreeBSD(技术上来说不算 Linux 发行版)

  • 32 位:/usr/lib32
  • 64 位:/usr/lib

知道去哪找这些关键库可以让库链接失效的问题成为历史。

虽然刚开始会有点困惑,但是理解 Linux 库的依赖管理是一种对操作系统掌控感的表现。在其他应用程序中运行这些步骤,以熟悉常见的库,然后继续学习怎样解决任何你可能遇到的库的挑战。


via: https://opensource.com/article/20/6/linux-libraries

作者:Stephan Avenwedde 选题:lujun9972 译者:tt67wq 校对:wxy

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

学习一款老派的文本处理软件 groff,就像是学习骑自行车。

 title=

我第一次发现 Unix 系统是在 20 世纪 90 年代早期,当时我还在大学读本科。我太喜欢这个系统了,所以我将家里电脑上的 MS-DOS 也换成了 Linux 系统。

在 90 年代早期至中期,Linux 所缺失的一个东西是 字处理软件 word processor 。作为其他桌面操作系统的标准办公程序,字处理软件能让你轻松地编辑文本。我经常在 DOS 上使用字处理软件来撰写课程论文。直到 90 年代末,我都没能找到一款 Linux 原生的字处理软件。直到那时,文字处理是我在第一台电脑上保留双启动的少有的原因之一,那样我可以偶尔切换到 DOS 系统写论文。

后来,我发现 Linux 提供了一款文字处理软件:GNU troff,它一般称为 groff),是经典的文本处理系统 troff 的一个现代实现。troff 是 “ 排版工快印 typesetter roff ” 的简称,是 nroff 系统的改进版本,而 nroff 又是最初的 roff 系统的新实现。roff 表示 快速印出 run off ,比如“快速印出”一份文档。

利用文本处理系统,你在纯文本编辑器里编辑内容,通过 macro 或其他处理命令来添加格式。然后将文件输入文本处理系统,比如 groff,来生成适合打印的格式化输出。另一个知名的文本处理系统是 LaTeX,但是 groff 已经满足我的需求,而且足够简单。

经过一点实践,我发现在 Linux 上使用 groff 来撰写课程论文与使用字处理软件一样容易。尽管我现在不再使用 groff 来写文档了,我依然记得它的那些宏和命令。如果你也是这样并且在那么多年之前学会了使用 groff 写作,你可能会认出这 5 个 groff 程序员的标志。

1、你有一个喜欢的宏集

输入由宏点缀的纯文本,你便能在 groff 里对文档进行格式化。groff 里的宏是行首为单个句点(.)的短命令。例如:如果你想在输出里插入几行,宏命令 .sp 2 会添加两个空行。groff 还具有其他一些基本的宏,支持各种各样的格式化。

为了能让作者更容易地格式化文档,groff 还提供了不同的 宏集 macro set ,即一组能够让你以自己的方式格式化文档的宏的集合。我学会的第一个宏集是 -me 宏集。这个宏集的名称其实是 e,你在处理文件时使用 -me 选项来指定这个 e 宏集。

groff 还包含其他宏集。例如,-man 宏集以前是用于格式化 Unix 系统内置的 手册页 manual page 的标准宏集,-ms 宏集经常用于格式化其他一些技术文档。如果你学会了使用 groff 写作,你可能有一个喜欢的宏集。

2、你想专注于内容而非格式

使用 groff 写作的一个很好的特点是,你能专注于你的 内容,而不用太担心它看起来会怎么样。对于技术作者而言这是一个很实用的特点。对专业作家来说,groff 是一个很好的、“不会分心”的写作环境。至少,使用 groff -T 选项所支持的任何格式来交付内容时你不用担心,这包括 PDF、PostScript、HTML、以及纯文本。不过,你无法直接从 groff 生成 LibreOffice ODT 文件或者 Word DOC 文件。

一旦你使用 groff 写作变得有信心之后,宏便开始 消失。用于格式化的宏变成了背景的一部分,而你纯粹地专注于眼前的文本内容。我已经使用 groff 写了足够多内容,以至于我甚至不再看见那些宏。也许,这就像写代码,而你的大脑随意换档,于是你就像计算机一样思考,看到的代码就是一组指令。对我而言,使用 groff 写作就像那样:我仅仅看到文本,而我的大脑将宏自动地翻译成格式。

3、你喜欢怀旧复古的感觉

当然,使用一个更典型的字处理软件来写你的文档可能更 简单,比如 LibreOffice Writer、甚至 Google Docs 或 Microsoft Word。而且对于某些种类的文档,桌面型字处理软件才是正确的选择。但是,如果你想要这种怀旧复古的感觉,使用 groff 写作很难被打败。

我承认,我的大部分写作是用 LibreOffice Writer 完成的,它的表现很出色。但是当我渴望以一种怀旧复古的方式去做时,我会打开编辑器用 groff 来写文档。

4、你希望能到处使用它

groff 及其同类软件在几乎所有的 Unix 系统上都是标准软件包。此外,groff 宏不会随系统而变化。比如,-me 宏集在不同系统上都应该相同。因此,一旦你在一个系统上学会使用宏,你能在下一个系统上同样地使用它们。

另外,因为 groff 文档就是纯文本文档,所以你能使用任何你喜欢的编辑器来编辑文档。我喜欢使用 GNU Emacs 来编辑我的 groff 文档,但是你可能使用 GNOME Gedit、Vim、其他你 最喜欢的文本编辑器。大部分编辑器会支持这样一种模式,其中 groff 宏会以不同的颜色高亮显示,帮助你在处理文件之前便能发现错误。

5、你使用 -me 写了这篇文章

当我决定要写这篇文章时,我认为最佳的方式便是直接使用 groff。我想要演示 groff 在编写文档方面是多么的灵活。所以,虽然你正在网上读这篇文章,但是它最初是用 groff 写的。

我希望这激发了你学习如何使用 groff 撰写文档的兴趣。如果你想学习 -me 宏集里更高级的函数,参考 Eric Allman 的《Writing papers with groff using -me》,你应该能在系统的 groff 文档找到这本书,文件名为 meintro.me。这是一份很好的参考资料,还解释了使用 -me 宏集格式化论文的其他方式。

我还提供了这篇文章的原始草稿,其中使用了 -me 宏集。下载这个文件并保存为 five-signs-groff.me,然后运行 groff 处理来查看它。-T 选项设置输出类型,比如 -Tps 用于生成 PostScript 输出,-Thtml 用于生成 HTML 文件。比如:

groff -me -Thtml five-signs-groff.me > five-signs-groff.html

via: https://opensource.com/article/21/4/groff-programmer

作者:Jim Hall 选题:lujun9972 译者:liweitianux 校对:wxy

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

龙芯推出自主指令集 LoongArch,可翻译支持 MIPS/ARM/x86

最近,龙芯宣布推出 LoongArch 指令集,拥有 2500 多条自主指令。该指令集可以通过二进制翻译的方式兼容 MIPS、ARM 及 x86 处理器。当然,翻译其他指令面临效率问题,LoongArch 对 MIPS 指令的翻译效率是 100%,对 ARM 可以达到 90%。而对于 x86,在 Linux 下翻译的效率可达 80%,Windows 下的效率则减少到 70%,不过后续还会有更多的优化。

龙芯的目标是到 2025 年消除指令集之间的壁垒,彻底搞定不同指令集的兼容问题。龙芯找了国内外的知识产权团队作了梳理,对于使用二进制翻译别的指令集系统,是没有专利权纠纷的。之后,龙芯还会继续进行知识产权分析,并建立 LoongArch 上游社区分支,同时组建 LoongArch 联盟,一方面免费开放 LoongArch,另一方面要在高校推广,取代 RISC-V。

自主指令集固然很重要,而兼容现有主流指令集也很重要,祝龙芯成功!

火星直升机“灵巧号”成功首飞,GitHub 为使用的开源项目颁发徽章

美国宇航局今天创造了历史,完成了在另一个星球上进行的首次动力飞行。火星直升机“灵巧号”成功地飞上了火星的天空,进行了一次短暂的旅行。

“灵巧号”使用了商用配件,大量采用了开源项目,这包括 Linux、FPrime、cUrl 以及大量 Python 项目。GitHub 宣布,为在火星直升机上使用的开源项目做过贡献的开发者颁发“火星 2020 直升机贡献者”徽章。

有拿到了直升机贡献者徽章的同学可以炫耀一下~~

中国开通全球规模最大的互联网试验设施主干网

据新华社报道,4 月 20 日,“未来互联网试验设施 FITI”高性能主干网开通仪式在清华大学举行。FITI 是当前全球规模最大的互联网试验设施,是我国信息领域第一个国家重大科技基础设施项目:未来网络试验设施的重要组成部分。FITI 主干网核心节点分布在全国 31 个省区市,核心节点间的带宽达到 200G,同时支持不少于 4096 个大规模试验网络,实现了与国内外 IPv4/IPv6 试验设施的互联互通。

希望将来的互联网越来越好,越来越互联互通吧。

使用 Scrcpy 可以把你的手机屏幕变成一个“应用”,与在树莓派或任何其他基于 Linux 的设备上的应用一起运行。

 title=

要远离我们日常使用的电子产品是很难的。在熙熙攘攘的现代生活中,我想确保我不会错过手机屏幕上弹出的来自朋友和家人的重要信息。我也很忙,不希望迷失在令人分心的事情中,但是拿起手机并且回复信息往往会使我分心。

更糟糕的是,有很多的设备。幸运地是,大多数的设备(从功能强大的笔记本电脑到甚至不起眼的树莓派)都可以运行 Linux。因为它们运行的是 Linux,所以我为一种设置找到的解决方案几乎都适用于其他设备。

普遍适用

我想要一种无论我使用什么屏幕,都能统一我生活中不同来源的数据的方法。

我决定通过把手机屏幕复制到电脑上来解决这个问题。本质上,我把手机变成了一个“应用”,可以和我所有的其他程序运行在一起。这有助于我将注意力集中在桌面上,防止我走神,并使我更容易回复紧急通知。

听起来有吸引力吗?你也可以这样做。

设置 Scrcpy

Scrcpy 俗称屏幕复制(Screen Copy),是一个开源的屏幕镜像工具,它可以在 Linux、Windows 或者 macOS 上显示和控制安卓设备。安卓设备和计算机之间的通信主要是通过 USB 连接和 安卓调试桥 Android Debug Bridge (ADB)。它使用 TCP/IP,且不需要 root 权限访问。

Scrcpy 的设置和配置非常简单。如果你正在运行 Fedora,你可以从 COPR 仓库安装它:

$ sudo dnf copr enable zeno/scrcpy
$ sudo dnf install scrcpy -y

在 Debian 或者 Ubuntu 上:

$ sudo apt install scrcpy

你也可以自己编译 Scrcpy。即使是在树莓派上,按照 Scrcpy 的 GitHub 主页 上的说明来构建也不需要很长时间。

设置手机

Scrcpy 安装好后,你必须启用 USB 调试并授权每个设备(你的树莓派、笔记本电脑或者工作站)为受信任的控制器。

打开安卓上的“设置”应用程序。如果“开发者选项”没有被激活,按照安卓的 说明来解锁它

接下来,启用“USB 调试”。

 title=

然后通过 USB 将手机连接到你的树莓派或者笔记本电脑(或者你正在使用的任何设备),如果可以选择的话,将模式设置为 PTP。如果你的手机不能使用 PTP,将你的手机设置为用于传输文件的模式(而不是,作为一个 叠接 tethering 或者 MIDI 设备)。

你的手机可能会提示你授权你的电脑,这是通过它的 RSA 指纹进行识别的。你只需要在你第一次连接的时候操作即可,在之后你的手机会识别并信任你的计算机。

使用 lsusb 命令确认设置:

$ lsusb
Bus 007 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 011 Device 004: ID 046d:c21d Logitech, Inc. F310 Gamepad
Bus 005 Device 005: ID 0951:1666 Kingston Technology DataTraveler G4
Bus 005 Device 004: ID 05e3:0608 Genesys Logic, Inc. Hub
Bus 004 Device 001: ID 18d1:4ee6 Google Inc. Nexus/Pixel Device (PTP + debug)
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

然后执行 scrcpy 以默认设置运行。

 title=

性能和响应能力取决于你使用什么设备来控制你的手机。在树莓派派上,一些动画可能会变慢,甚至有时候会响应滞后。Scrcpy 提供了一个简单的解决办法:降低 Scrcpy 显示图像的位速率和分辨率使得你的计算机能够容易显示动画。使用以下命令来实现:

$ scrcpy --bit-rate 1M --max-size 800

尝试不同的值来找到一个适合你的值。为了使键入更方便,在选定一个命令之后,可以考虑 创建自己的 Bash 别名

剪断连线

Scrcpy 开始运行后,你甚至可以通过 WiFi 连接你的手机和计算机。Scrcpy 安装过程也会安装 adb,它是一个与安卓设备通信的命令。Scrcpy 也可以使用这个命令与你的设备通信,adb 可以通过 TCP/IP 连接。

 title=

要尝试的话,请确保你的手机通过 WiFi 连在与你的计算机所使用的相同的无线网络上。依然不要断开你的手机与 USB 的连接!

接下来,通过手机中的“设置”,选择“关于手机”来获取你手机的 IP 地址。查看“状态”选项来获得你的地址。它通常是 192.168 或者 10 开头。

或者,你也可以使用 adb 来获得你手机的IP地址:

$ adb shell ip route | awk '{print $9}'

To connect to your device over WiFi, you must enable TCP/IP connections. This, you must do through the adb command:
$ adb tcpip 5555
Now you can disconnect your mobile from USB.
Whenever you want to connect over WiFi, first connect to the mobile with the command adb connect. For instance, assuming my mobile's IP address is 10.1.1.22, the command is:
$ adb connect 10.1.1.22:5555

连接好之后,你就可以像往常一样运行 Scrcpy 了。

远程控制

Scrcpy 很容易使用。你可以在终端或者 一个图形界面应用 中尝试它。

你是否在使用其它的屏幕镜像工具?如果有的话,请在评论中告诉我们吧。


via: https://opensource.com/article/21/3/android-raspberry-pi

作者:Sudeshna Sur 选题:lujun9972 译者:ShuyRoy 校对:wxy

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