2023年1月

GNOME 的调查数据揭示了一些令人感兴趣的用户偏好。这是否会影响 GNOME 在不久的将来的开发决策?让我们拭目以待。

GNOME 的研究报告说,超过 90% 的系统安装了 Flatpak

在 2022 年 8 月,GNOME 开发了 一个工具,让用户可以匿名提供关于他们的系统配置、扩展和 GNOME 调整的设置。

这是为了帮助 GNOME 深入了解用户的偏好,并在分析数据的基础上做出更好的决定。

GNOME 设计团队的成员 Allan Day 在最近的一篇博文中分享了收集的数据。它包含了一些有趣的洞察和发现。

让我带你了解一下:

研究报告的发现

本研究报告包括来自 2,517 个用户的数据,这些用户的硬件和软件配置各不相同。

? 这些数据是使用 gnome-info-collect 工具 从向 GNOME 提供数据的人那里获得的,并不代表 GNOME 的全部用户。

最初,他们收到了 2,560 个回复,但由于一些数据没有来自使用 GNOME 的系统或来自虚拟机,他们不得不从数据集中删除一些。

它包含什么?它含有匿名的非敏感数据指标,显示了用户是如何设置他们的系统的。

? 这对 GNOME 团队来说可以有很大的用处,他们现在可以使用这些数据来做出设计和开发的决定。

其中一个引起我们注意的数据指标是在他们的 GNOME 系统上使用 Flatpak 的人的百分比。

超过 90% 的系统都安装了 Flatpak。

在 2517 个用户中,有高达 2344 个用户在他们的 GNOME 系统上安装了 Flatpak。其中 2,102 人完全启用了它。

在这样一个小的数据集中,这是一个巨大的数字! ?

关于这一点,Allan 有这样的补充说明:

Flatpak 和 Flathub 对 GNOME 的战略方向至关重要,所以了解它们的采用程度是很有用的。这种采用程度也与 GNOME 的软件应用设计有关。

除此之外,一些关键的收获包括:

  • 最常用的默认网页浏览器是 Mozilla Firefox。
  • 在使用 GNOME 的人中,最常用的发行版是 Fedora。
  • 谷歌是配置了在线账户的用户的首选账户。
  • GIMP 是安装在 GNOME 上最受欢迎的应用程序之一,紧随其后的是 VLC。
  • 83% 的用户至少启用了一个 GNOME 扩展。

我建议你通过该 研究报告 来获得更深入的了解。

这是否有助于改善 GNOME 的体验?

收集这些数据是为了通过分析和提供给设计和开发团队来改善桌面体验。

然而,收集到的数据仍然相当有限,可能无法代表大多数的 GNOME 用户。

为了解决这个问题,博文中提到:

总的来说,这些数据对于 GNOME 项目应该专注于哪些功能给出了一些有力的提示。它也提供了关于哪些功能不应该被优先考虑的证据。需要记住的是,虽然我们在这里有关于一些 GNOME 用户做出的决定的证据,但这些数据并没有让我们深入了解为什么他们会做出这样的决定。

GNOME 团队希望在根据这些数据做出决定时保持谨慎。而且,像这样的调查应该能让他们更好地了解用户的偏好,并把重点放在基本层面上更重要的东西上。

当然,不可能照顾到每一种类型的用户。但是,只要基本面得到了照顾,桌面体验最终应该得到改善。

你对这些发现有什么看法?欢迎在下面的评论中分享你的想法。


via: https://news.itsfoss.com/gnome-research-report/

作者:Sourav Rudra 选题:lkxed 译者:wxy 校对:wxy

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

只要你遵循这些通用流程,代码评审并不可怕。

你是否需要在你还没有完全理解整个项目时就对代码进行评审?抑或你避开了评审,以免让你看起来不知道如何进行。

本篇文章想要告诉你一个更好的方法。 代码评审 code review 并不需要你知道所有事情。实际上,就我个人经验而言,这种情况非常普遍。

我还记得作为实习生加入 红帽 Red Hat 的时候,被要求参与代码评审。我们当时采取的是 +1 或 -1 的投票系统,而我在一开始的时候常常踌躇于该如何评审。我发现我会问自己,如果我对于一处改动给予了 +1,而别人却投了 -1,我是不是看起来很蠢?

如果你对一处改动投了 +1,而别人投了 -1,这又意味着什么呢?答案是不意味任何事!你可能只是漏掉了一处别人注意到的细节。这不意味着世界末日。这也是为什么我们会用投票系统。正如同所有开源项目一样,代码合并是一项协同工作。

最近,我接到了太多的代码评审工作,以至于我几乎做不过来。我同时也注意到,参与评审的贡献者数量正在稳步减少。

出于这个原因,我想要写一篇文章阐述我对代码评审的个人观点。在这篇文章里,我会分享一些诀窍与技巧。我将会向你展示几个用来问自己的问题,以及在评审代码时需要注意的一些地方。

代码评审的目的是什么?

你是否曾写过一个非常简单的补丁?你认为它是如此微不足道,不需要审查。或许你直接就合并了它。直到晚些时候,你意识到你犯了个错误,一个明显的或是愚蠢的错误,比如错误的缩进,比如几行重复的代码而不是调用函数(是的,这些都是经验之谈!)。

如果有其他人来审查代码,就会发现这些东西。

代码评审的一个目的便是为你带来一双新的眼睛,从新的视角看待你要尝试解决的问题。这种新的背景也正是为什么代码评审至关重要。

你可能认为你必须是一个语言专家,才能审查别人的代码、项目,或两者。让我来告诉你一个所有代码评审者都想跟你说的秘密吧:大错特错!你并不需要完全理解该项目或者编程语言,就可以为一个改动提供全新的视角。下面,我将向你展示代码评审的通用流程。

代码评审的通用流程

这是我的代码评审流程,拆分成了几个要点。这个流程包含了我会问自己的一些问题,以帮助我专注于代码的变化以及其后果。你不需要严格依照这个顺序来进行评审。如果有任何原因导致你无法执行其中的某一步,跳过那一步就好。

1、理解改动,它想要解决的问题,以及为什么要这么做

为什么需要改动的解释以及任何相关背景都应该被放在 提交 commit 信息里。如果没有,请要求提供,并请投 -1 直到相关信息被提供。

改动想解决的问题需要被解决吗?它是项目应当关注的问题,还是与项目完全无关?

2、你会如何实现解决方案?它会不一样吗?

在这个时候,你应该已经知道代码改动是为了什么。换做是你会怎么做?在进一步对改动进行细节评审前,先思考这个问题。如果你想出了一个不一样的解决方案,并且你认为你的方案更好,在评审中提出来。你不需要投 -1;去问问作者为什么没有往那个方向走,看看这次讨论会把你们带向何方。

3、运行有改动和没有改动的代码

我通常会在代码中设置几个断点,运行代码并检查新代码是如何与其余部分互动的。

如果你无法运行整个代码,试着将带有新代码的函数复制到一个新的本地文件,模拟输入数据,然后运行。这在你不知道怎么运行整个项目,或者无法接触到运行所需的特殊环境时很有帮助。

4、新代码会破坏任何东西吗?

我是说,任何东西。想一想可能的后果。

以一个新的命令行选项为例,它会总是被目标所接受吗?

是否存在这样一种情况,使得新选项无法被接受或是会与其他东西起冲突?

或许新代码是导入了新的东西。那么这个新的库,以及可能的新的依赖关系,能够在老版本或者项目的运行系统中被找到吗?

安全方面呢?新的依赖足够安全吗?你至少可以在网上快速地搜索一下。还有,注意一下控制台日志里的警告。有的时候在同一个库里也可以找到更安全的函数。

5、新代码是否有效?

你刚刚确认了被提出的解决方案大概是正确的。现在该检查代码本身了。你需要关注代码的有效性和必要性。

检查新代码的风格。它与项目的代码风格相匹配吗?任何开源项目都(应该)有一份文档告知(新)贡献者项目所遵循的风格和优秀实践。

比如说,OpenStack 社区的所有项目都有一份 HACKING.rst 文件。你经常也能找到一份新贡献者指南包含所有必须知道的信息。

6、确认所有新增的变量和导入都被使用

你正在评审的代码常常已经过多次迭代,有的时候代码的最终版本与初始版已迥然不同。所以我们很容易忘记一些在历史版本中加入的变量与引用。自动化检测通常会用到 lint 工具,类似 Python 中的 flake8。

(LCTT 译注:lint 指编程中用来发现代码潜在错误和约束代码风格的工具,起源于 C 语言编程中的静态分析工具 lint。“lint” 本意为衣服上积累的绒毛与灰尘,“lint” 的取名寓意则在于捕捉编程时产生的“绒毛与灰尘”)

(LCTT 校注:我建议,“Lint” 工具可以翻译为 “代码清理” 或 “代码清洁” 工具。)

你可以在不声明新变量的情况下重写代码吗?通常情况下你可以,但问题是这样是否更好。这会带来什么益处吗?我们的目标不是要创造尽可能多的单行代码,而是写出高效且易读的代码。

7、新的函数和方法是否必要?

项目里的别的地方是否存在可以被复用的功能类似的函数?确保避免重新发明轮子以及重新实现已经被定义的逻辑永远都是值得的。

8、有单元测试吗?

如果补丁增加了新的函数或者在函数内添加了新的逻辑,它也应该附带对应的单元测试。新函数的作者总是比别人更适合写该函数的单元测试。

9. 验证重构

如果这次提交对现有代码进行了重构(它可能重命名了某个变量,或者是改变了的变量的作用域,或者是通过加减参数来改变函数的足迹,又或者是删去了某个东西),问一问你自己:

  • 这个可以被删除吗?它会影响到稳定分支吗?
  • 所有出现的地方都删掉了吗?

你可以利用 grep 命令 来查找。你不会相信有多少次我投 -1 就是因为这个。这是一个任何人都会犯的简单错误,也正因如此任何人都可以发现它。

提交的所有者很容易忽略这些事情,这完全可以理解。我也犯过很多次这种错误。我最终发现问题的根源在于我太急于提出评审,以至于我忘记了对仓库进行整体检查。

除了对项目仓库的检查外,检查其他代码用户也十分必要。如果有别的项目导入了这个项目,它们可能也需要进行重构。在 OpenStack 社区中,我们有对应的工具来查询别的社区项目。

10、项目文档是否需要做出更改?

你可以再一次使用 grep 命令 来检查在项目文档中是否提到了相关的代码改动。用常识来判断这次改动是否需要被收入文档以告知最终用户,还是只是一个不会影响用户体验的内部变化。

额外提示:考虑周到

当你在评审完新代码后提出建议或评论时,要考虑周到,反馈准确,描述详尽。如果有你不理解的地方就发出提问。如果你认为代码存在错误,解释你的理由。记住,如果作者不知道什么地方出了问题,他们就无法修复它。

最后几句

唯一的坏评审是没有评审。通过评审和投票,你提供了你的观点并为此投票。没有人指望你来做出最终决定(除非你是核心维护者),但是投票系统允许你提供你的观点和意见。相信我,补丁所有者会很高兴你这么做了的。

你能想到别的要点来给出好的评审吗?你是否有我不知道的特殊技巧?在评论中分享它们吧!


via: https://opensource.com/article/22/10/code-review

作者:Martin Kopec 选题:lkxed 译者:yzuowei 校对:wxy

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

英特尔砍掉了 Pathfinder for RISC-V 项目

英特尔 2022 年第四季度灾难性地亏损了 6.61 亿美元,市值跌掉 80 亿美元,利润率跌至几十年来的最低点。在此形式下,英特尔宣布砍掉了一系列项目,包括 Pathfinder for RISC-V 项目。该项目是英特尔探索新 CPU 开放架构的一次尝试,旨在帮助加速开发 RISC-V 芯片,允许用户构建 RISC-V 芯片然后运行在 FPGA 上。直接砍掉该项目意味着这次尝试的失败。

消息来源:Tom's Hardware
老王点评:毕竟,固守发家的主业还是更可靠些,但这给 RISC-V 的发展蒙上了阴影。

奔驰成为美国首家获得三级自动驾驶认证的汽车公司

周四,奔驰确认其 Drive Pilot 自动驾驶辅助系统(ADAS)现在符合内华达州第 482A 章的要求,成为目前美国唯一合法的三级自动驾驶系统。第三级能力将使车辆在参与时能够处理 “所有方面的驾驶”,这比我们今天看到的二级系统,如特斯拉的 “完全自动驾驶”、福特的 “蓝色巡航” 和通用的 “超级巡航”,有了很大的进步。奔驰称,其 ADAS 可以“在 40 英里/小时的速度范围内接管保险杠对保险杠的爬行任务,而驾驶员不需要将手放在方向盘上。” 甚至可以对 “意外的交通情况作出反应并独立处理,例如,在车道内进行规避动作或进行制动动作。”

消息来源:Engadget
老王点评:原本我以为会是特斯拉率先推出三级自动驾驶辅助系统的。

《科学》期刊禁止将 ChatGPT 列为论文的共同作者

《科学》期刊宣布了一项更新的编辑政策,禁止使用 ChatGPT 生成的文本,并澄清该程序不能被列为作者。《科学》期刊要求作者签署一份表格,声明他们对自己对工作的贡献负责任,而由于 ChatGPT 不能这样做,所以它不能成为作者。此外,他们认为,即使在准备论文时使用 ChatGPT 也有问题。因为 ChatGPT 会犯很多错误,这些错误可能会出现在文献中,如果科学家们开始依赖人工智能程序来准备文献综述或总结他们的发现,那么工作的正确背景和结果应有的深入审查就可能会丢失。

消息来源:《卫报》
老王点评:有一定的道理,但是我认为是徒劳的,就像你不可能阻止使用计算器一样。计算器本身并不能替你完成全部求解,只是一个辅助工具。经过 AI 辅助的研究论文终究会找到它应有的位置。

zram 是一个用于创建内存压缩缓存的工具,特别是可以用作交换空间。

我在我的电脑上花了很多时间(我是说工作),我发现了很多有趣的东西。其中最近引起我注意的是 zram0 设备。我是在几个月前写一篇文章时第一次注意到它,它显示在 lsblk 命令的输出中:

# lsblk
NAME          MAJ:MIN RM   SIZE RO TYPE MOUNTPOINTS
sda             8:0    0 931.5G  0 disk
├─sda1          8:1    0   600M  0 part
[...]
zram0         252:0    0     8G  0 disk [SWAP]

它被识别为交换空间,这就是首先引起我的好奇心的原因,所以我做了一些研究。zram 最初被称为 “ 压缩缓存 compcache ”,即 “压缩的高速缓存”。事实证明,zram 是一个用于创建内存内压缩缓存的工具,特别是作为交换空间使用。

但为什么呢?

当我开始研究 zram 时,我只发现了几篇关于将 zram 用于交换空间的基础文章。起初,这对我来说似乎有点违反直觉。毕竟,如果你的内存快用完了,你把页面交换到内存中的虚拟驱动器中,有什么好处呢?

然后我找到了 Fedora 项目的维基页面,它提议使用 zram 交换空间 swap-on-zram 。该建议说:“交换是有用的,除了它的速度很慢。zram 是一个使用了压缩的内存驱动器。在启动时创建一个 zram 交换空间,并且不再使用默认的交换分区。”

该页面的其余部分是关于它的细节、好处、副作用和反馈。

Linux 上用于交换空间的 zram

使用 zram 作为交换空间,与常规的基于分区或基于文件的交换空间做的事情相同。当内存压力过大时,一些最近使用最少的数据会被移到交换空间。平均来说,它会被压缩到其原始大小的 50% 左右,并被放置在内存的 zram 空间中。这比将这些内存页存储在硬盘上要快得多,并可以释放出它所使用的内存用于其他用途。

节省交换空间

我试图找到关于配置多少交换空间或 zram 交换空间的总结建议。这使我重新回顾了交换空间的设置,以及我之前的文章《现代 Linux 系统的正确交换空间是多少?》。就我所知,从 RHEL 和 Fedora 的最新文档来看,推荐的交换空间数量并没有改变。不过,该文档忽略了 zram 的使用。

然而,在不使用 zram 的旧版 Linux 或 zram 被禁用的情况下,之前文章中的表格仍然为交换空间的分配提供了一个好的起点。

我找到的关于 zram 功能的文档在 zram 如何根据内存大小分配空间,以及分配给 zram 交换空间的数量方面是不一致的。

由于缺乏权威性的文档,我进行了一些实验来凭经验确定用于分配 zram 交换空间的算法。我为此使用了我自己的物理和虚拟系统。结果很有趣,与我迄今为止发现的任何文档都不一致。

在所有足够大的系统上,zram 的默认大小是 8GB,但在内存较小的主机上通常会大大减少。在我用于测试的一台虚拟机(VM)上,可以访问 4GB 的内存,zram 的虚拟交换空间被分配为 3.8GB。我的一台旧戴尔电脑拥有 8GB 的内存,zram 被设置为 7.6GB。当内存减少到 2GB 时,zram 就减少到 1.9GB。

我拥有的所有内存超过 8GB 的物理和虚拟主机都显示正好是 8GB 的 zram。这包括我拥有 64GB 内存的主工作站和其他拥有 16GB 或 32GB 内存的主机。

基于这几个数据点,我可以得出这样的结论:目前的默认设置是最多 8GB 的 zram,而在 8GB 或以下的主机上,zram 占内存的 95%。

我读过一些文章,其中提到了 zram 交换空间的其他大小,甚至高达 100% 的内存,但这些似乎都是理论上的,而不是现实。

你的发行版可能不同,但这里是 Fedora 和类似发行版的实际 zram 交换空间的分配情况:

  • 内存 ⇐ 8 GB:0.95 × 内存
  • 内存 > 8 GB:8 GB

请注意,zram 交换空间大小的算法并没有基于对任何给定的现实世界的系统或应用程序的 “最佳” 交换大小的建议。这种 zram 交换空间的分配是一种相当概率性的方法,它应该在广泛的 Linux 主机上运行良好。然而,最大的 zram 交换空间大小被配置为 8GB,而且我一直推荐 8GB 作为传统交换空间的最大容量,我想我可以说它反映了 zram 交换空间的最佳大小。

管理 zram 交换空间

zram 的默认值保存在 /usr/lib/systemd/zram-generator.conf 配置文件中。以下是我的一个测试虚拟机,分配了 5097GB 的内存。

# cat /usr/lib/systemd/zram-generator.conf
# This config file enables a /dev/zram0 device with the default settings:
# - size - same as available RAM or 8GB, whichever is less
# - compression - most likely lzo-rle
#
# To disable, uninstall zram-generator-defaults or create empty
# /etc/systemd/zram-generator.conf file.
[zram0]zram-size= min(ram, 8192)

你可以在 zram-generator.conf 配置文件的最后一行改变默认的 zram 交换空间大小。但我建议不要这样做,除非你能明确说明这样做的原因,并在你做任何改变后测试你的结果。像 Linux 中的许多其他配置默认值一样,zram 的默认值已经被很好地测试过了,适合大多数使用情况。

监控 zram

可以使用 zramctl 工具来查看 zram 的当前状态。

# zramctl
NAME       ALGORITHM DISKSIZE DATA COMPR TOTAL STREAMS MOUNTPOINT
/dev/zram0 lzo-rle       4.8G   4K   80B   12K       4[SWAP]

传统的 swapon 命令也可以用来查看交换,包括作为交换使用的 zram:

# swapon --show
NAME       TYPE      SIZE USED PRIO
/dev/zram0 partition 4.8G   0B  100

需要注意的是,zramctl 在不包含数据时不报告 zram,所以结果会包含空输出。而像 lsblkswapontopfreehtop 等工具,即使不包含数据,也会显示 zram。

停用 zram

swapoff -a 命令会关闭 zram 交换空间以及用作交换的传统 HDD 或 SSD 存储。swapon -a 命令在 zram 为空时不显示它,可以使用 zramctl /dev/zram0 代替。

# swapon --show# lsblk
NAME          MAJ:MIN RM  SIZE RO TYPE MOUNTPOINTS
sda             8:00  120G  0 disk
├─sda1          8:10    1G  0 part /boot/efi
├─sda2          8:20    1G  0 part /boot
└─sda3          8:30  118G  0 part
  ├─vg01-root 253:00   10G  0 lvm  /
  ├─vg01-swap 253:10    3G  0 lvm  [SWAP]
  ├─vg01-usr  253:10   30G  0 lvm  /usr
  ├─vg01-home 253:20   10G  0 lvm  /home
  ├─vg01-var  253:30   30G  0 lvm  /var
  └─vg01-tmp  253:40   10G  0 lvm  /tmp
sr0            11:01 1024M  0 rom
zram0         252:00    0B  0 disk
# zramctl## zramctl /dev/zram0
NAME       ALGORITHM DISKSIZE DATA COMPR TOTAL STREAMS MOUNTPOINT
/dev/zram0 lzo-rle         0B   0B    0B    0B       4

注意,/dev/zram0 在这些命令中并没有显示为交换空间,直到它被用于该目的。这给我造成了一些困惑,直到我的实验表明这是事实。

创建 zram 交换空间

zram 本身已经存在了大约 20 年,但只是在过去的一两年里才在一些发行版上作为交换空间使用。你的一些或所有主机上当前的 Linux 环境可能没有用 zram 创建交换空间。如果是这种情况,它可以很容易地被补救。

对于 Fedora 32,它是默认使用 zram 交换空间之前的最后一个版本,它只需要三个简单的命令。

首先,验证是否存在 zram-swap.service 文件,它作为 zram RPM 包的一部分安装:

# systemctl status zram-swap
● zram-swap.service - Enable compressed swap in memory using zram
     Loaded: loaded (/usr/lib/systemd/system/zram-swap.service; disabled; vendor preset: disabled)
     Active: inactive (dead)

接下来,安装 zram-generator-defaultszram-generator 软件包:

# dnf install zram-generator-defaults zram-generator

启用并启动 zram-swap 服务:

# systemctl enable zram-swap.service# systemctl start zram-swap.service

然后验证 zram0 是否存在并被用作交换空间:

# lsblk
NAME          MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
sda             8:00  120G  0 disk
├─sda1          8:10    2G  0 part /boot
└─sda2          8:20  118G  0 part
  ├─vg01-root 253:00   10G  0 lvm  /
  ├─vg01-swap 253:10    3G  0 lvm  [SWAP]
  ├─vg01-usr  253:20   35G  0 lvm  /usr
  ├─vg01-tmp  253:30   15G  0 lvm  /tmp
  ├─vg01-var  253:40   35G  0 lvm  /var
  └─vg01-home 253:50   20G  0 lvm  /home
sr0            11:01 1024M  0 rom
zram0         252:00  7.5G  0 disk [SWAP]

用 zram 改进交换空间

这就是全部内容了。在 Fedora 上这很容易。不同的发行版可能也一样简单,只是软件包名称和命令的细节可能不同。在你的电脑上试试 zram 交换空间吧。在我的下一篇文章中,我将进一步演示一些 zram 选项。


via: https://opensource.com/article/22/11/zram-swap-linux

作者:David Both 选题:lkxed 译者:wxy 校对:wxy

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

Mastodon 并不是一家公司。所有 Mastodon 实例都由各自所属服务器的贡献者负责支持维护的。以下是它的一些其他优势。

社交媒体并不总是社交性的,有时我们还需要足够的推动力来改变我们工作和阅读的内容。我在 2008 年开始使用 Twitter 作为 RSS 阅读器的替代品,这彻底颠覆了我那时的阅读和学习方式。世界各地的教育家和自由与开放源码(FOSS)倡导者的推文让我了解并参与到一个无与伦比的学习网络中。但这在过去的六年间,事情发生了变化,以及最近它的所有权发生了变化,造成我阅读的内容更多是由算法驱动的,而不是出于我个人的兴趣和选择。在几年前的 Opensource.com 记者编辑碰头会中,Seth Kenlon 建议我试试 Mastodon。于是我在 2019 年加入了 Fosstodon。Fosstodon 是一个专为喜欢自由和开源软件的同好们搭建的实例。

Mastodon 与 Twitter 对比

作为一个墨守成规的人,改变对我来说并不容易,尽管 Twitter 变得越来越让人厌倦,我还一直在使用。可是到了 2022 年的春天,Twitter 的出售危机让我重新考虑使用 Fosstodon 了。

1、收藏而不是点赞

Mastodon 的界面与 Twitter 很相似。但在 Mastodon上,你不是“点赞”一个帖子,而是通过点击帖子下方的星标来“收藏”一个帖子。

Favorite button

2、分享帖子

在 Twitter 上,重新分享是“ 转推 retweet ”,但在 Mastodon,它是“ 转嘟 boost ”。你可以点击帖子下方的双箭头图标来转嘟。

Boost button

3、Mastodon 实例

任何人都可以运行一个 Mastodon 实例,这让不同的实例上发展出了独特的社区(类似在 Twitter 上围绕特定标签形成的社区,不过 Mastodon 也有标签),有些实例有一套独特的规则。举个例子,和我以前的社交网络不同,Fosstodon 上采取了内容审核制度。最初这让我觉得有些严格,我发了一个与自由与开放源码软件无关的帖子,然后帖子就被删除了。我被告知的删除原因是,我没有给帖子打上 “内容警告”。这惹怒了我,于是我尝试寻找别的实例,发现了几个更符合我胃口的。其中一个是 Mastodon.social,另一个是 Scholar.social,前者是一个泛用的实例,没有预设的发帖主题,后者则是一个学术专用的实例。当然,他们也都制定有严格的行为规范。

每个实例都有规则,虽然在表述上略有不同,但都清楚地说明了可以接受和不可接受的行为。Fosstodon 公布了它的 行为规范,确立了站点的规则和预期。

4、开源社交网络

如果你也想运行自己的 Mastodon 实例或协助开发一个,好消息是,Mastodon 是开源的。它使用 AGPLv3 许可证,它的源代码可以在 Git 仓库 获得。Mastodon 使用 ActivityPub 协议与世界各地的服务器通信。

Mastodon 不是互联网上的单一的网站,而是一系列横跨全球并相互通信的网站们。这个联邦网络被称为 “ 联邦宇宙 Fediverse ”。不像其他社交网站有单一的所有者,任何人都可以在服务器上运行 Mastodon 或者其他 ActivityPub 协议网站。

从用户的角度来看,这一开始时其实并不重要。你可以在任何 Mastodon 实例上注册,然后连接到其余所有的实例。

不过,这种分布式设计是有其好处的。如果你碰见一个实例上的社区内容你不想看,你可以从屏蔽该实例中的某个用户,或者屏蔽整个实例。

过去的一个月里,我又回到了 Fosstodon,主要还是因为我热衷开源。我很享受在 Fosstodon 上分享开源内容,而 Fosstodon 上的其他用户也都能乐于看到关于自由和开源软件的帖子。当我有一些内容不适合在 Fosstodon 上分享时,我会分享到 Scholar.social 或者 Mastodon.social 上。

不是所有的实例都有关注的主题,即便是那些有主题的实例,主题常常也是仅作参考,而不是严格作为删帖的依据。如果你有特定的兴趣,也许就能找到一个围绕这个话题建立的社区,然后马上就能收获及时的关注。当然,你也依然能够与其他实例的用户交流。

试试 Mastodon

Mastodon 不是一家公司,所有 Mastodon 实例都是由各自所属的服务器的贡献者负责支持维护的。有些能很容易地通过 Patreon 或 PayPal 提供支持。

我发现,联邦宇宙是个很温馨的地方,把快乐带回给了社交网络。你加入了 Mastodon 了吗?有没有什么收获?请在评论中告诉我们。


via: https://opensource.com/article/22/11/twitter-vs-mastodon

作者:Don Watkins 选题:lkxed 译者:onionstalgia 校对:wxy

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

欧盟拟议的《网络弹性法案》可能对开源产生可怕的影响

欧盟拟议的《网络弹性法案(CRA)》被称之为软件产品的 “CE 标志”。它有四个具体目标,其中之一要求制造商在 “整个生命周期” 内提高数字产品的安全性。对于软件开发商和硬件制造商来说,这将增加新的网络安全要求、合格评估、文件和报告义务的直接合规成本。这个成本预计将达到 290 亿欧元,但预计可以减少安全事件带来的成本为 1800 至 2900 亿欧元。问题是,自由软件开发者如何能够承担合规成本?这可能打破了开源生态系统的社会契约:免费提供用于任何目的的开源软件,可以自由修改和进一步分发,但作者、贡献者或开源分销商没有保证或责任。

消息来源:Dev Class
老王点评:我觉得,开源软件的基石不容触动,CRA 尽可以去约束那些商业的专有软件。

美国联邦调查局黑掉了勒索团伙

美国联邦调查局的政府黑客闯入了勒索团伙 Hive 的网络,并对该团伙进行了监视,窃取了该团伙用来解锁数据的数字密钥。然后他们提前提醒受害者,以便他们能够在 Hive 要求付款之前保护他们的系统。美国司法部表示,多年来,Hive 入侵了 80 个不同国家的 1500 多名受害者,勒索金额超过了 1 亿美元。周四,Hive 的网站被查封,并在该网站显示了查封信息。政府黑客对 Hive 的监视从 2022 年 7 月开始直到被查封前,都没有被 Hive 发现。

消息来源:路透社
老王点评:政府黑客技高一筹啊,看来是懒得和勒索黑帮玩下去了。

2022 年 FreeBSD 没有达到筹款目标

FreeBSD 发布了其 2022 年第四季度的状态报告。根据报告,他们 2022 年的筹款目标是 140 万美元,而截至现在大约是 114.7 万美元。他们正在考虑引进一个能够鼓励组织投资于 FreeBSD 的人。报告中其中值得关注的信息还有:发布工程团队正在努力推出 FreeBSD 13.2;正在开发集成应用容器 Vessel,以类似 Docker 的界面向应用开发者展示许多 FreeBSD 的特性。

消息来源:Phoronix
老王点评:FreeBSD 的日子比起来 Linux 惨淡得多,但是 FreeBSD 依旧带来了很多技术进步。

回音

  • AI 律师(#874)背后的公司受到多个州的律师协会 起诉,称未经授权进行律师执业活动在某些州属于轻罪,因此原定于 1 月 22 日的 AI 律师参与的庭审被取消了。