2023年1月

我使用笔记本电脑很长时间了,但最近才切换到台式机上,以便进行远程工作。

我注意到我的扬声器不断发出嗡嗡声。这很烦人,让我头疼。我开始着手解决这个问题。了解问题的根本原因非常有趣。

我将分享我在 Linux 中修复扬声器嗡嗡声的经验。我发现它可以在同一硬件上对 Ubuntu、Debian 和 Pop OS 都有效。

需要考虑的一件事是,如果本指南不适合你,你可能遇到了严重的硬件问题。对于大多数用户来说,给定的方案应该可以解决问题。

在尝试修复之前

我试图让事情变得容易安全地遵循。你可以尝试临时修复,如果有效,则将更改永久化。但是,最好使用 Timeshift 制作系统快照。如果你在出现故障时很容易惊慌失措,你可以将系统恢复到之前的状态。

另外,检查你的声卡。在我的例子中,它是 snd_hda_intel。对于 USB 卡,它可以是 snd_usb_audio。你必须根据你的声卡更改命令。

cat /proc/asound/modules

Linux 中扬声器发出嗡嗡声的原因

梳理了无数的论坛帖子和网站后,我了解了问题的根本原因。这是因为扬声器中的电容放电。它可以通过关闭声卡的省电设置来解决。

通过关闭省电,你允许系统在这些电容放电时为其充电。这类似于在一直充电时使用电话。

你可以使用给定的命令检查你的系统是否启用了声卡的省电设置:

cat /sys/module/snd_hda_intel/parameters/power_save

power saving setting in sound card making buzzing sound in linux

如果你像我一样输出是 1,那么省电功能已打开。因此,让我们看一下方案。

不用担心。这不会显著影响你的电池百分比,因为所示方法仅适用于声卡。

尝试修复嗡嗡声问题(临时)

我之所以包括临时方法是为了确定嗡嗡声是由于电容放电引起的,还是存在严重的硬件问题。

如果此临时方案有效,你可以继续使用永久方案。

第一步是切换到 root 用户:

sudo su

然后,执行给定的命令,它应该停止嗡嗡声直到下次启动:

echo 0 > /sys/module/snd_hda_intel/parameters/power_save

如果你使用的是 USB 声卡,则必须将 snd_hda_intel 替换为 snd_usb_audio,如下所示:

echo 0 > /sys/module/snd_usb_audio/parameters/power_save

如果上述技巧解决了问题,那么你必须使变更永久化。否则,下次重启系统时更改将丢失。

修复嗡嗡声问题(永久)

在这里,我将对内核参数进行更改。

将你的工作目录更改为 /etc/modprobe.d

cd /etc/modprobe.d

现在,创建一个名为 audio_disable_powersave.conf 的新文件,并使用给定命令使用 nano 文本编辑器打开:

sudo nano audio_disable_powersave.conf

并在该文件中放入以下行以永久关闭声卡中的省电设置:

options snd_hda_intel power_save=0

fix buzzing sound in linux

对于 USB 声卡,你需要使用 snd_usb_audio

options snd_usb_audio power_save=0

现在,保存更改并退出 Nano 文本编辑器 并按 Ctrl+X 键。重启你的系统,你就可以享受无噪音的工作空间。

总结

本指南解释了嗡嗡声的原因以及如何直接解决该问题。

同样,除了电容放电之外,你可能还有其他问题,因此你应该始终尝试临时方法。

让我知道你是否能够以这种方式解决 Linux 中扬声器发出的嗡嗡声。


via: https://itsfoss.com/buzzing-noise-speaker-linux

作者:Sagar Sharma 选题:lkxed 译者:geekpi 校对:wxy

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

BioArchLinux 是生物工作者的 Arch Linux 社区,它包含了一个生物信息学软件的 Arch Linux 仓库。这个仓库易于贡献,用户友好,可以帮助大家在 Arch Linux 及其衍生的发行版、Windows 以及 Docker 下面快速安装好生物信息软件。

BioArchLinux

为什么会有 BioArchLinux 项目?

以目前科学相关的发行版为例,它们大多基于 Ubuntu ,比如 Bio-Linux 以及 Poseidon Linux ;也有基于 CentOS 或者 RHEL 的,比如 Scientific Linux 。但是最终这些发行版都慢慢不再活跃,Scientific Linux 发出的各种 公告 也是表现出身不由己。

从 Scientific Linux 的经历可以看出,如果将各种软件包打包在一个依赖商业公司或者由商业公司主导的发行版上,发展方向就会变得不可知,最初的目标和规划自然不能得以实现。最初 Scientific Linux 依赖付费的 Linux 发行版 RHEL ,后期依赖商业公司的免费社群发行版 CentOS(CentOS 8 以及之前是一个稳定的发行版),红帽将 CentOS 8 的生命周期草草结束,进而支持滚动发行版 CentOS Stream(现在是 RHEL 的上游发行版),因此 Scientific Linux 不得不变成基于 CentOS Stream 的发行版。只能说,Scientific Linux 一开始就选择错了。

再从 Bio-Linux 的角度来看待,Bio-Linux 本质上是把各类软件包打包到 Ubuntu 内之后形成的一个发行版。这必然有一个周期,在这个一年或者两年的周期内,各类软件总会有更新的,而 Bio-Linux 不考虑这个问题,所以会出现使用过时的版本来分析数据的情况,很明显这不利于研究。而且, Bio-Linux 8 自 2014 年发布了基于 Ubuntu 14.04 LTS 的发行版之后,就没在发行新的版本了,而目前 Ubuntu 22.04 LTS 都已经出来了。Bio-Linux 的 软件包 除了老旧,还特别冗杂,我需要的包他们不全有,我不需要的包他们有很多,这毫无疑问增加了我 PC 的负担。

Poseidon Linux 也有着类似的问题。这种发布发行版的方式滞后且需要重装系统,特别不方便。实在不如直接经营一个各类包的仓库,可以快速更新,不必频繁发布 ISO 文件又可以将软件更新到最新版。

所以,如果你希望想长期使用,那么就建议使用非商业公司关联的 Linux 系统;如果你需要参与 Linux 的发展,那么你就要寻找一个方便使用第三方仓库/官方仓库、且非商业公司关联的发行版。这里我们就选择了 Arch Linux。

同时,我们也不希望只是一群为 AUR 做贡献人,因为曾经我自己的设想是这个团体可以像 RedHat 那些发行版之类的 SIG,但是 SIG 的运作模式是为官方仓库贡献包。而 AUR 只是存储一个脚本,并不是一个预先编译好的包。这样带来的麻烦有很多,首先是 AUR 不能和官方仓库的包有冲突,但是这对于生物信息的目标用户群体是个麻烦事情,比如我要找 picard,但是 community 仓库里的 picard 已经是别的同名软件了,但是它只是在 community 仓库里,我不会用到它,因此我要几经周折地找到 AUR 里的 picard-tools。AUR 另外一个不方便的点在于软件包的来源不一定不被封锁,曾经我向我师姐十分热情的推销 Arch 系的发行版,她也觉得蛮好用,但当她想从 AUR 里下载软件时候,互联网限制了她的想象。但是,当我们组成了一个有镜像源的仓库的时候,我们就不需要担心这个问题了,来自互联网封锁国家的人们就无需忍受缓慢的互联网速度和法律风险访问他们所需要的软件了。

如何使用 BioArchLinux?

首先,BioArchLinux 本身的属性决定了用户可以在哪些地方使用它。 BioArchLinux 是一个生物工作者的 Arch Linux 社区,包含了一个生物学软件的 Arch Linux 存储库、可以编辑的 wiki 以及 Matrix 聊天频道。

在 Arch Linux 中使用 BioArchLinux

正如它本身的属性所定义,它可以用于 Arch Linux 及其衍生发行版(不包括 Manjaro stable & testing),从 BioArchLinux 安装软件很容易。只需几个简单的命令即可安装所需的软件包。

# echo -e "[bioarchlinux]\nServer = https://repo.bioarchlinux.org/\$arch" >> /etc/pacman.conf
# pacman-key --recv-keys B1F96021DB62254D
# pacman-key --finger B1F96021DB62254D
# pacman-key --lsign-key B1F96021DB62254D
# pacman -Syy
# pacman -S pkg_name

在最初接触 Linux 时候,我使用 Ubuntu 。当我想要安装生信软件的时候,我曾经一下午都在处理循环依赖的问题。这或许是某些发行版的特性,而且由于我是图形化安装的,我其实对未来怎么迁移系统并没有足够的把握。对于小白来说,好不容易装好的环境想要迁移很难避免重复性的工作。Arch Linux 的特性避免了这里很多问题,从打包的粒度考虑,循环依赖可以说是很罕见的了。另外就是当你需要构建一个包,你只需要会写 Shell 脚本再看一看维基,事情会容易很多。相比于 Debian 等发行版,这样其实会有利于你迁移你安装的软件。

当然,和其他软件仓库不同的是,BioArchLinux 仓库在可能的情况下,在每个包描述中提供了一个 DOI。 这使用户能够轻松地了解有关每个包的用途和方法的更多信息,并在准备出版物时快速识别适当的引用。

$ pacman -Ss doi_number
$ pacman -Qi pkg_name

在 WSL 中使用 BioArchLinux

另外,当 Windows 和 macOS 用户需要使用 Linux 环境来运行生物信息软件的时候,也可以轻松使用 BioArchLinux。因为 BioArchLinux 同样提供 WSL 以及 Docker 镜像。

对于 Windows 用户优先推荐 WSL,因为 Docker 在 Windows 下依赖 WSL。只需要在任意一个镜像站点的 wsl 文件夹下找到 tar 文件即可。解压它,在安装了 wsl 的前提下双击 BioArch.exe 文件,就可以开始成功安装,安装好后键入下述命令即可进入:

wsl -d BioArch

在使用前需要做一些初始化的任务,比如初始化 WSL,这里的镜像地址可以更改为你喜欢的镜像,镜像列表见 mirrorlist 仓库 里的 mirrorlist.bio

# echo 'Server = https://mirrors.sdu.edu.cn/archlinux/$repo/os/$arch' > /etc/pacman.d/mirrorlist
# echo 'Server = https://mirrors.sdu.edu.cn/bioarchlinux/$arch' > /etc/pacman.d/mirrorlist.bio
# pacman -Syu

此时,你就可以使用该 WSL 了。

在 Docker 中使用 BioArchLinux

至于 Docker 的使用和 WSL 类似,只不过在安装完 Docker 后使用如下命令进入。进入后依然需要使用 WSL 初始化的命令初始 Docker 容器。

# docker pull bioarchlinux/bioarchlinux
# docker run -it --privileged --name container_name --restart=always bioarchlinux/bioarchlinux /bin/bash

BioArchLinux 如何运作?

BioArchLinux 运行流程

BioArchLinux 存储库由几个开源软件包维护。 主要工具是一个名为 lilac 的 python 应用程序。

最基本的步骤是按照 Arch Linux 和 lilac.yaml 的标准编写脚本。我们编写一个 PKGBUILD shell 脚本和一个 YAML 文件(以及可选的 Python 脚本),并将它们放在 Git 存储库的一个文件夹中。

nvchecker 读取 lilac.yaml,获取上游网站的信息,可以查看最新版本。如果 nvchecker 无法从上游网站找到包版本,它会向管理员发送电子邮件报告问题。

nvchecker 的信息发送给 lilac,由 lilac 判断包是否需要升级。如果软件包需要升级,lilac 会将软件包发送到 Arch Linux 打包工具 devtools

devtools 为软件包提供了一个干净的环境,只有 PKGBUILD shell 脚本中的依赖项列表允许构建。这可以避免在使用过程中丢失依赖项。如果包构建失败,则会自动向包维护者发送警告电子邮件。如果包构建成功,archrepo2 会将 Arch Linux 包放入特定路径,并生成一个新的数据库文件,形成一个全新的包仓库。如果 lilac.yaml 中含有维护 AUR 的指令,包更新也将退送给 AUR。

整个构建过程被记录为日志文件,可以使用 Rust 应用程序 bioarchlinux-packages 读取,并显示在日志网站上。

我们的维基网站是基于 MediaWiki 构建的。所有人都可以自由地为本网站贡献关于生物信息学软件的使用以及生物信息学概念和术语。

BioArchLinux 展望

上面讲了那么多的好,其实 BioArchLinux 也有很多的不足。

先从仓库说起,我们虽然在短短一年内有了约 4.2 k 的软件包,维护了约 4.7% AUR 包,但是,我们相比于 Debian Med 以及 bioconda 都有很大的数量上的差距,急需更多的维护者参与进来,并且需要不断提升打包的质量。

除此之外,比较急切的是我们国内镜像源目前仅仅有几家高校,南京大学、西安交通大学、山东大学以及南京邮电大学,我们希望更多的镜像站能够添加我们。另外因为计算机资源的问题,我们也没有 archive 网站,这给回滚造成了一定程度的困难。

其余就是扩大仓库的受众和加强社区的维护。虽然我们有了 WSL 还有 Dokcer,但是有些人很喜欢在虚拟机里运行,我们却提供不了 ISO 文件,也需要相关的维护人员。我们也没有专门的维基管理人员,有段时间因为没有限制用户注册,网站有被垃圾信息灌爆。

甚至我们在网站的搭建上面还是有欠缺,比如没有像 Arch Linux 那样的搜包界面,这需要更多开发人员的参与。除此之外,如何以非 root 用户的角色使用仓库仍然是一个很大的课题。

我们十分欢迎更多的人参与到我们的社区中来,一起做一些疯狂且美好的事情,不管再多困难,我相信,这个那么 FFF(community friendly, user friendly, earth friendly)的项目会长命百岁。(注:community friendly 帮助维护 Arch Linux community 的 AUR 软件包;user friendly 易于使用、以用户为中心;earth friendly 减少大家编译的次数,尽可能减少计算机资源的消耗。)

致谢

非常感谢 xTom、Mick Elliot 以及 Bipin Kumar 对这个项目的资助,也十分感谢一起为仓库工作的所有 BioArchLinux 成员。另外特别感谢 Arch Linux CN 依云 以及 imlonghao,没了他们维护的软件,BioArchLinux 不可能那么顺利的运作。同时也感谢南京大学、西安交通大学、山东大学以及南京邮电大学和其他为 BioArchLinux 提供镜像的机构和个人。最后,感谢之前 Bioinformatics Open Source Conference(BOSC)为参会免除会议费用。


作者简介:

MRes Evolutionary Biology, International Society for Computational Biology 会员


作者:Guoyi 编辑:wxy

本文由贡献者投稿至 Linux 中国公开投稿计划,采用 CC-BY-SA 协议 发布,Linux中国 荣誉推出

谷歌希望 RISC-V 成为 “一级” 安卓架构

谷歌在 RISC-V 峰会上说,希望 RISC-V 被看作安卓的 “一级平台”,这将使它与 Arm 并驾齐驱。在 RISC-V 上实现优化的安卓构建需要大量的工作,可能需要“几年”才能实现。AOSP 早在去年 9 月就开始发布了官方的 RISC-V 补丁,但目前你最多只能得到一个命令行。谷歌承诺,在 2023 年初提供初始的模拟器支持,并在第一季度为 Java 工作负载提供安卓运行时(ART)支持。一旦谷歌真的让安卓系统在 RISC-V 上运行起来,安卓应用生态系统的很大一部分都会随之而来。

消息来源:Ars Technica
老王点评:RISC-V 俨然已经成为“全村人”的希望。

智能电视机的隐藏获利方式

智能电视机比其它电子产品便宜的主要原因可能是它能从它收集的数据中获利。这些智能电视都能播放在线服务的内容,能安装各种应用,它们免费为我们服务,代价是对我们进行监控,然后将收集的数据出售给广告商。智能电视收集了用户的观影内容、时长等信息,然后打包出售。电视机厂商将这一模式称为购买后货币化,意味着它们可以以接近成本的价格出售硬件,通过分享客户的观影数据长期获利。

消息来源:The Atlantic
老王点评:就如一句老话,免费服务的代价就是你自己。

Debian 移除 Python 2

Debian 从 FTP 服务器上移除了 Python 2 软件包。Python 2 已经在 2020 年结束支持,Python 开发者在 2020 年 4 月发布了 Python 2.7 分支的最后一个版本:Python 2.7.18。这标志着大部分 Linux 发行版开始着手移除 Python 2 包。

消息来源:Debian
老王点评:想要淘汰 Python 2 可真不容易啊。

CFW(Cyber Firewall)是一个人性化的 Linux 防火墙。

概括

CFW(Cyber Firewall)是一个人性化的 Linux 防火墙。它旨在协助阻止拒绝服务攻击(DDoS),同时能控制 Linux 系统端口的开关。CFW 基于 Linux 原生基础设施运行,拥有良好的软件兼容性。

该软件基于 iptables 和 ipset,使用 Python 开发,使用时建议关闭发行版自带的防火墙(如 firewalld、ufw)避免冲突。

通过 CFW,你将能够:

  • 通过自定义的规则自动封禁互联网中的恶意 IP,以防止拒绝服务攻击
  • 保护 Linux 的所有端口遭受 DDoS 攻击,而不仅仅是 Web 应用
  • 获得良好的软件兼容性,原生支持 Nginx、Caddy 等服务器
  • 支持配合 CDN 使用,使用 CDN 时请将 CDN 的 IP 段设置为 CFW 白名单
  • 控制开启或关闭 Linux 系统的 TCP/UDP 端口
  • 获得友好的命令行交互式体验

背景

Web 应用程序运行在复杂的互联网中,随时可能面临恶意攻击,导致拒绝服务现象。为了封禁这些不友好的 IP,CFW 正是为此而诞生。

CFW 的灵感最初来自宝塔面板的 Nginx 防火墙。然而,使用 Nginx 防火墙的过程中遇到诸多不顺。该防火墙仅针对 Web 应用(通常是 80 和 443 端口)防御 CC 攻击,无法保护 Linux 服务器的其他端口。同时,该防火墙需要按月付费,并始终捆绑宝塔生态(最新的宝塔面板甚至需要登录绑定手机实名制的账号),从而限制了软件自由度。我们想在纯净的 Linux 中运行防火墙,并对所有端口生效,于是自己开发了一个。

由于 CFW 基于 iptables 和 ipset,不免会与发行版自带的防火墙(如 firewalld、ufw)冲突,我们增加了 CFW 对端口开关的控制。

实现

CFW 通过 ss -Hntu | awk '{print $5,$6}' 命令获取当前服务器的所有连接。客户端的请求若超过设定并发数,该 IP 将被 iptables 封禁,并存储在 ipset 数据结构中。

CFW 通过调用 iptables 命令实现 Linux 端口的开关。

安装

请先确保系统拥有以下依赖。

对于 Debian、Ubuntu 等:

sudo apt install -y curl ipset python3 git net-tools

对于 CentOS 等:

sudo yum install -y curl ipset python3 git net-tools

安装好系统依赖后,输入以下命令安装 CFW:

sudo curl https://raw.githubusercontent.com/Cyberbolt/cfw/main/install.py | python3

你也可以下载该脚本阅读,以了解该脚本所进行的工作后再执行上述命令。

完成安装后,使用 source ~/.bashrc 激活 CFW 的环境变量。(或者新打开一个 shell 环境,自动激活环境变量。)

在 Linux 终端输入 systemctl status cfw,显示 active (running) 字样说明 CFW 已成功运行,同时会在服务器重启时自动运行。

卸载

sudo curl https://raw.githubusercontent.com/Cyberbolt/cfw/main/uninstall.py | python3

配置

配置文件在 /etc/cfw/config.yaml 中,修改配置文件后运行 systemctl restart cfw 即可生效。

配置文件参数说明:

# CFW 运行端口
port: 6680
# CFW 检测连接的频率,单位:秒。此处默认 5 秒一次。
frequency: 5
# 允许每个 IP 连接的最大并发数,超过将被 CFW 封禁。
max_num: 100
# 解封 IP 的时间。此处默认 IP 被封禁后 600 秒将自动解封。若此处值为 0,则永久封禁。
unblock_time: 600
# 数据备份时间,单位:秒。
backup_time: 60

# IPv4 白名单路径。写在文本文件中,一行一个 IP,支持子网掩码。)本地地址、内网地址默认在该文件中)
whitelist: /etc/cfw/ip_list/whitelist.txt
# IPv4 黑名单路径。写在文本文件中,一行一个 IP,支持子网掩码。
blacklist: /etc/cfw/ip_list/blacklist.txt

# IPv6 白名单路径。写在文本文件中,一行一个 IP。
whitelist6: /etc/cfw/ip_list/whitelist6.txt
# IPv6 黑名单路径。写在文本文件中,一行一个 IP。
blacklist6: /etc/cfw/ip_list/blacklist6.txt

# 日志文件的路径
log_file_path: /etc/cfw/log/log.csv
# 日志文件的最大行数。(达到最大行数后将自动滚动。若此处值为 0,则不限制最大行数)
log_max_lines: 10000000

命令

命令中 [] 表示变量。

运行

  • 停止 CFW:systemctl stop cfw
  • 启动 CFW:systemctl start cfw
  • 重启 CFW:systemctl restart cfw

IP 黑名单管理

  • 手动封禁单个 IPv4 地址:cfw block [ip]
  • 手动解封单个 IPv4 地址:cfw unblock [ip]
  • 查看 IPv4 黑名单:cfw blacklist
  • 手动封禁单个 IPv6 地址:cfw block6 [ip]
  • 手动解封单个 IPv6 地址:cfw unblock6 [ip]
  • 查看 IPv6 黑名单:cfw blacklist6

Linux 端口操作

  • 放行 IPv4 端口:cfw allow [port]
  • 阻止 IPv4 端口:cfw deny [port]
  • 单独放行 IPv4 TCP 端口:cfw allow [port]/tcp,示例如 cfw allow 69.162.81.155/tcp
  • 单独阻止 IPv4 TCP 端口:cfw deny [port]/tcp,示例如 cfw deny 69.162.81.155/tcp
  • IPv4 UDP 端口操作同理
  • 查看所有放行的 IPv4 端口:cfw status
  • 放行 IPv6 端口:cfw allow6 [port]
  • 阻止 IPv6 端口:cfw deny6 [port]
  • 单独放行 IPv6 TCP 端口:cfw allow6 [port]/tcp,示例如 cfw allow6 69.162.81.155/tcp
  • 单独阻止 IPv6 TCP 端口:cfw deny6 [port]/tcp,示例如 cfw deny6 69.162.81.155/tcp
  • IPv6 UDP 端口操作同理
  • 查看所有放行的 IPv6 端口:cfw status6

日志操作

动态查询日志 cfw log [num][num] 为查询日志的条数,查询结果将按时间倒序。

相关链接

更多

如果你在使用中遇到任何问题,欢迎在 https://github.com/Cyberbolt/cfw/issues 处留言。有了你的帮助,CFW 才能日渐壮大。

总结

CFW 可以防止一定程度的 DDoS 攻击,同时能控制开启或关闭 Linux 系统的 TCP/UDP 端口,很好地帮助我们解决恶意 IP 入侵的问题。但是不要做不切实际的想象,认为 CFW 可以抵御大型 DDoS 攻击。DDoS 攻击的规模往往与成本是正相关的,必要时提升网络带宽才能解决问题的根本。


作者简介:

Cyberbolt:一个自由的 Python 开发者。


作者:Cyberbolt 编辑:wxy

本文由贡献者投稿至 Linux 中国公开投稿计划,采用 CC-BY-SA 协议 发布,Linux中国 荣誉推出

想知道如何为你的开源软件项目收集使用指标?考虑一下使用这些替代方案的利弊。

我们这些支持开源项目社区的人经常被问到很多有关使用指标的问题。这些指标通常是为了通过用户量和知名度来衡量软件的重要性。我们一般都想知道有多少人使用该软件,有多少次安装,以及有多少人生活接触过它。

但简而言之,我们尚无法直接回答上述问题。

如果你想要寻找一个明确的解决方案,那很抱歉要让你失望了。有关使用指标的问题,没有人有完美的答案,至少没有准确的答案。

好消息是,有一些近似的和替代指标至少能够部分地满足你对软件使用情况了解的渴求。本文探讨了这些替代方案以及它们的优点和缺点。

下载量

当你浏览提供软件的网站时,你通常可以看到软件的下载次数。映入我脑海的一个例子是 Firefox ,它曾经有一个下载计数器。Firefox 的下载量是一个印象深刻的数字,给人的印象是 Firefox 是一个流行的浏览器,在一段时间内确实如此。

然而,个人行为会直接影响这一数字的准确性。举例而言,当一个人定期重置他们的设备时,每一次重建都会引发一次独立的下载。考虑到这一现实,需要设计一种方法从下载量中去除几十次(或许是几百次)的下载次数,因为那是一个人。

下载量不仅会高估使用量,还会低估使用量。例如,一个系统管理员可能会下载一个新版本的 Firefox 一次并将其拷贝到 U 盘上,然后安装到数百台设备上。

下载量指标是易于收集的,你可以在服务器上记录每一个下载请求。问题在于你不知道在这些软件下载以后会发生什么。下载它的人是否如预期的那样使用软件,还是遇到了问题而放弃了它。

对于开源项目而言,你可以考虑各种下载量指标,比如来自以下途径的下载指标:

  • 项目官网
  • 包管理器,比如 npm、PyPi 和 Maven
  • 代码仓库,如 GitHub、GitLab、Gitee 等

你可能还对源代码的下载量感兴趣,因为下游项目更可能使用源代码形式(参见 《如何衡量你的开源项目的影响》一文)。相应的下载指标包括:

  • 从代码仓库克隆的数量,比如 GitHub、GitLab 和 Gitee
  • 从官网下载的归档文件(tar、zip)的数量
  • 通过像 npm、PyPi 和 Maven 这样的包管理器下载的源代码数量

源代码的下载指标比二进制代码的下载指标更不可靠(虽然尚无相关研究表明如此)。试想一下,一名开发人员想要你的最新版本的源代码,并将他们的构建管道配置为每次构建都克隆你的仓库。再想象一下,一个自动构建过程失败了,它试图重新构建而不断地克隆你的版本库。你还可以考虑这样一个下载量低于预期的场景——源代码仓库在某些地方缓存了,下载来源是由这些缓存所提供的。

相关阅读:跟踪你的开源社区的 5 个指标

总而言之,下载量指标是用于提供当前使用情况和探测趋势的很好的指征。我们无法明确地定义一次下载是如何转化为使用的。不过我们可以认为增加的下载量是更多潜在用户的标志。举例而言,如果你为你的软件做了广告并在活动期间得到了更高的下载量,可以合理地假定广告推动了更多人下载该软件。下载行为的来源与元数据还可以提供额外的与使用行为相关的内容。你的软件的哪些版本仍在使用中?什么操作系统或者特定语言的版本更加流行?这有助于社区决定将哪个平台的软件作为支持与测试的优先选项。

议题

作为一个开源项目,你可能有一个议题追踪器。当某个人提出一个议题时一般有两个目标,报告一个漏洞或者请求增加一项功能。提议者很可能已经使用过你的软件了。作为一名用户,他可能发现了一个漏洞或者发现了对一个新功能的需求。

很明显,大多数用户不会执行额外的步骤来提交议题。提议者是我们的忠实用户,我们对他们表示感谢。此外,通过提出议题,他们已经成为了非代码贡献者,他们也有希望成为代码贡献者。经验法则是大约每 10000 名用户中,可能有 100 名提议者,以及 1 名代码贡献者。当然取决于用户类型,上述比例可能有出入。

回到指标问题,你可以将提议者数量作为评估使用量的下界。相关的指标包括:

  • 提议者数量
  • 活跃提议者的数量(在过去 6 个月内提出议题的提议者)
  • 同时有代码贡献的提议者的数量
  • 尚未解决的议题的数量
  • 对议题发布的评论数量

邮件列表、论坛和问答网站

很多开源项目都拥有用户邮件列表、论坛,并且出现在类似 Stack Overflow 的问答网站上。与提问者一样,在这些地方发帖的人可被视作用户的冰山一角。与邮件列表、论坛和问答网站上的社区活跃程度相关的指标也可用于反映用户数量的上升或下降。相关指标可以集中于以下地方的活动,包括:

  • 用户邮件列表的订阅量
  • 论坛用户的数量
  • 问题的数量
  • 答案的数量
  • 发布信息的数量

上报功能

为了获得精确的用户数量,一个方案是让软件在使用时上报信息。

这是令人毛骨悚然的。想象一下,系统管理员的防火墙报告了一个非预期的到你的服务器的网络连接,你不仅无法再收到软件报告(被防火墙拦截了),恐怕连你的软件也可能在未来被禁止使用。

负责任的设置上报功能的方式为设置一项可选服务来检查更新并让用户知道使用最新版本。另一项可选功能可以集中在使用遥测上,你可以通过该功能询问用户是否允许匿名上报软件使用情况。如果经过深思熟虑的实施,这种方式可以允许用户通过他们使用软件的方式帮助优化软件。用户可以持有这样的意见:我一般不允许这种使用信息的分享;但对于一些软件,因为希望开发人员在长期内将软件优化得更好,我愿意这样做。

星标与复刻

星标与复刻是如 GitHub、GitLab、Gitee 等社交化编程平台的功能。这些平台上的用户可以给一个项目加星标。为什么他们要给项目加星标呢?GitHub 的文档作出了解释:你可以给一个仓库和主题加星标,以跟踪感兴趣的项目,和在你的新闻订阅中发现相关的内容。给一个项目加星标与将其加入书签的效果一样,并且还提供了一种向项目仓库的维护者展示赞赏的方式。星标的数量已经成为了项目流行程度的标志。当一个项目发布重大公告并获得相当的关注时,项目的星标数量会呈上升趋势。星标的数量指标并不反映软件的使用量。

在社交化编程平台上的 复刻 Fork 是将项目仓库复制一份在自己名下。仓库的非维护者可以在他们自己的克隆仓库中做修改,并将修改通过 拉取请求 pull request (PR)的方式提交审核。复刻比星标更能反映软件社区的规模。开发者也可能为了保存一份代码副本而克隆一个项目,以便在原始仓库消失后他们仍能访问代码。因为复刻功能在代码贡献工作流中的应用,复刻量是衡量开发社区的良好指标。复刻量通常也不反映非开发人员的使用,因为非开发人员一般不创建复刻。

社交媒体

包括 Facebook、Instagram、LinkIn、Reddit、Twtter 等社交媒体平台提供了相同兴趣的人们聚集的平台。采用社交媒体策略,开源项目可以通过在平台上设置相应的聚集空间来吸引对项目感兴趣的人们。通过这些社交媒体途径,开源项目可以分享项目新闻、更新,指出贡献者和用户。这些社交媒体途径还可以用于认识那些本不会通过其他途径与项目互动的人。

我在犹豫是否建议关注以下指标,因为它与软件的真实使用量没有清晰的联系,并通常需要分析其中的积极、消极和中性的情绪。人们可能因为很多不同的原因对你的项目感到激动而关注它,但并不实际使用它。然而与之前已经讨论过的指标一样,能够在社交媒体上吸收人群本就是项目受关注的整体指标。不同社交媒体平台的指标包括:

  • 关注者与订阅者的数量
  • 消息的数量
  • 活跃的消息作者的数量
  • 喜欢、分享、回复以及其他交互的数量

网站分析与文档

网站流量也是一个有用的指标。这一指标主要受到你的服务范围以及市场营销活动影响,而不是用户量。然而,我们还有一张王牌:我们的用户文档、教程、手册以及 API 文档。我们可以发现我们的网站以及文档中的什么主题更引人注意。文档的访问者数量应当大致随着软件的使用者数量增长而增长。因此我们可以通过网站的访问量探知对项目的普遍兴趣,并进一步通过观察文档的访问者来观察用户风向。这些指标包括:

  • 网站访问者数量
  • 文档访问者的数量
  • 访问者在你的网站与文档上所花的时间

活动

活动的指标可以在你主持与项目相关的活动时使用。这是建立社区的很好的方式。有多少人提交摘要想要在你的活动中发言?有多少人出席你的活动?不论是在线下活动还是线上活动这可能都很有趣。当然,你如何推广你的活动在很大程度上决定有多少人到场。同时你可以将自己的活动与人们出行的大型活动放在一起以方便人们参加你的活动。只要你使用一贯的活动策略,你可以通过演讲者提交的材料与参会者注册的增加来表征软件受欢迎程度与用户群的增加。

你并不需要举办你自己的活动来收集有用的指标。如果你在开源活动中主持有关你项目的讨论,你可以衡量有多少人出席主要关注你的项目的会议。像 FOSDEM 这样的活动,一些讨论特别聚焦于开源项目的更新与发布,会议室中都挤满了人(像 FOSDEM 的所有会议一样)。

你可以考虑如下指标:

  • 以你的项目为中心的活动的出席人数
  • 提交到以你的项目为中心的活动的演讲数量
  • 以你的项目为中心的演讲的出席人数

关于估算开源软件使用的结论

正如我们已经如上展现的,有很多指标可以反映软件使用的趋势,没有一个指标是完美的。在大多数情况下,这些指标可能被个人行为、系统设计和噪音所严重影响。因此,考虑到每一个指标的相对不确定性,我们建议你不要孤立地使用任何一个指标。但是如果你从不同的来源收集了一系列的指标,你应当能够探测到用户行为与软件使用的趋势。如果你有办法在多个具有共性的开源项目中比较同一组指标,例如类似的功能、强大的相互依赖性、在同一基础设施上托管,以及其他特征,你就可以提升你对用户行为基线的感知。

需要注意的是,在这篇概述中,我们选择突出能够评估直接使用情况的指标。而大多数软件都依赖于其他各种软件包,如果我们不提及作为软件依赖链的一部分而被间接使用的严重影响,这就是我们的疏忽。因此,我们建议将上下游依赖的合计数量作为你的分析中的另一层内容。

最后,作为数据与指标的使用者,我们鼓励你认识到你的利益相关方的权利与责任。你发布的任何指标都有可能影响用户行为。最好的做法是经常一同分享你的背景信息——基础、来源、估算方法和其他关键上下文信息,这有助于其他人解释你的结果。

感谢 CHAOSS 社区在爱尔兰都柏林举行的 CHAOSScon EU 2022 上的富有洞察力的对话,上述对话激发这篇博文的想法。我们还要感谢 CHAOSS 社区的成员审阅并帮助优化本文。


via: https://opensource.com/article/22/12/open-source-usage-metrics

作者:Georg Link 选题:lkxed 译者:CanYellow 校对:wxy

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

Ultramarine Linux 的新版本来了。Ultramarine Linux 37 带有新的自定义软件仓库、KDE Plasma 特色版等等。

如果你不知道,Ultramarine Linux 是一个基于 Fedora 的发行版,提供了 Budgie、Pantheon、GNOME 等桌面环境。这个发行版通过这些令人赞叹的桌面环境给你提供了最好的 Fedora 体验。

最近,这个小项目被 FyraLabs 收购,后者是 PhotonBrowser 和 tauOS 背后的公司。而这使得 Ultramarine 项目有了必要的人力和资金来继续建设他们的发行版。

自 Fedora 37 发布以来,该团队一直致力于重建当前版本,这包括采用新的基础设施和 CI/CD 管道迁移。终于,Ultramarine Linux 37 登场了。

那么,它有什么新东西呢?

Ultramarine Linux 37 的新功能

自从被 Fyralabs 收购后,该团队升级并迁移到用于自动化 CI/CD 构建的 GitHub Actions。Ultramarine 自己的软件仓库用于分发其精心组织的软件包(例如 Pantheon 桌面),它在这个版本中会发生变化,并转移到 FyraLabs 的基础设施上。

因此,如果你正在运行 Ultramarine 36 版本,它可能无法正常工作。你最好重新安装这个版本,因为显然没有从 36 版到 37 版的升级路径。

此外,Ultramarine 37 为 Fedora 软件包引入了一个名为 Terra 的滚动仓库,其中包括数百个 Fedora 不提供的应用程序。你可以认为它类似于 RPM Fusion,尽管有所不同。

要了解更多,请访问 本页 或从命令行添加以下软件仓库:

sudo dnf config-manager --add-repo https://terra.fyralabs.com/terra.repo

事实上,这开启了一种可能性,因为你也可以尝试在 Fedora Linux 中谨慎地使用它。如果上述软件仓库能在普通的 Fedora 安装中开箱即用,那就更棒了。

在上述变化的基础上,Ultramarine Linux 37 首次引入了 KDE Plasma 作为官方版本。KDE Plasma 特色版带来了含有 Latte Dock 和 Lightly Qt 主题的 Pop OS 风格外观。

Ultramarine Linux 37 具有独特的 Pop OS 风格的 KDE Plasma 主题

Ultramarine Linux 37 也放弃了 Cutefish 桌面,因为它目前正处于 混乱的开发状态,没有可见的路线图。这是该团队的一个很好的决定,因为打包一个已经停止的项目是没有意义的。

Budgie 桌面旗舰版使用上游的 Fedora 软件包,有更多的默认应用程序。最近,Fedora Linux 删除了对 elementary OS 的 Pantheon 桌面的支持,很遗憾。感谢 Ultramarine Linux 开发者,你仍然可以体验它,因为它已经被转移到新的 Terra 软件仓库中。

你应该庆幸,Ultramarine Linux 是唯一一个的基于 Fedora 的支持令人赞叹的 Pantheon 桌面的发行版。

最后,Ultramarine Linux 37 的核心基于 Fedora 37,采用 Linux 主线内核 6.0。因此,所有更新的软件包和工具链都在这个版本中。

所以,这就是关于这个版本的总结。请继续关注几天后对这个版本的官方点评。如果有兴趣,你可以在这里阅读之前的版本(36)的评论。

Ultramarine Linux:带有 Budgie、Cutefish 和 Pantheon 桌面的终极 Fedora 特色版

下载和升级

由于没有升级路径,建议你对该版本进行全新安装。你可以在下面下载各个桌面环境的 ISO 文件。

下载 Ultramarine Linux 37

参考自:发布公告


via: https://debugpointnews.com/ultramarine-linux-37-release/

作者:arindam 选题:lkxed 译者:wxy 校对:wxy

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