2023年11月

mkosi 是一个轻量级工具,用于从发行版软件包构建镜像。本文介绍如何使用 mkosi 从 RHEL 和 RHEL 通用基础镜像 Universal Base Image (UBI)的软件包构建镜像。RHEL UBI 是 RHEL 的一个子集,可以在没有订阅的情况下免费使用。

mkosi 特性

mkosi 支持一些输出格式,但最重要的是 可发现磁盘镜像 Discoverable Disk Images (DDI)。同一个 DDI 可用于引导容器、或运行在虚拟机、抑或是复制到 U 盘以引导真实物理机,然后从 U 盘复制到磁盘以引导系统。该镜像具有标准化的布局和描述其用途的元数据。

mkosi 依赖其他工具来完成大部分工作:使用 systemd-repart 在磁盘镜像上创建分区,使用 mkfs.btrfs / mkfs.ext4 / mkfs.xfs 等创建文件系统,并使用 dnf / apt / pacman / zypper 下载和解压包。

mkosi 支持一系列发行版:Debian 和 Ubuntu、Arch Linux、openSUSE,当然还包括 Fedora、CentOS Stream 及其衍生版本,以及最近的 RHEL UBI 和 RHEL 。由于实际的“重活”是由其他工具完成的,mkosi 可以进行交叉构建。这意味着可以使用一个发行版构建各种其他发行版的镜像。唯一的要求是主机上安装了相应的工具。Fedora 有原生的 aptpacmanzypper,因此它为使用 mkosi 构建任何其他发行版提供了良好的基础。

它还有一些有趣的功能:镜像可以由非特权用户创建,或者在没有设备文件的容器中创建,特别是没有对回环设备的访问权限。它还可以在没有特权的情况下将这些镜像启动为虚拟机(使用 qemu)。

配置是声明性的,非常容易创建。使用 systemd-repart 创建磁盘分区,并使用 repart.d 配置文件定义应该如何完成此操作。

有关更多详细信息,请参见 Daan DeMeyer 在 All Systems Go 大会上的两个演讲:《systemd-repart: Building Discoverable Disk Images》 和 《mkosi: Building Bespoke Operating System Images》。

项目目标

mkosi 的一个目标是允许对软件项目进行针对不同发行版的测试。它将为一个发行版创建一个镜像(使用该发行版的软件包),然后将软件项目编译并安装到该镜像中,插入不属于软件包的额外文件。但是,首个阶段,即从软件包创建镜像的过程,本身就是有用的。这是我们将首先展示的内容。

我们 [1] 最近添加了对 RHEL 和 RHEL UBI 的支持。让我们从 RHEL UBI 开始,利用发行版软件包创建镜像。

请注意,下面的示例要求 mkosi 19,而且不适用于更早的版本。

带有 Shell 的基本 RHEL UBI 镜像

$ mkdir -p mkosi.cache
$ mkosi \
    -d rhel-ubi \
    -t directory \
    -p bash,coreutils,util-linux,systemd,rpm \
    --autologin

上面的命令指定了发行版 rhel-ubi,输出格式 directory,并请求安装软件包 bashcoreutils、…、rpmrpm 通常不需要放到镜像内部,但在这里用于内省会很有用。我们还启用了以 root 用户自动登录。

在启动构建之前,我们创建了缓存目录 mkosi.cache。当存在缓存目录时,mkosi 会自动使用它来持久化下载的 RPM 包。这将使相同软件包集合的后续调用速度更快。

然后,我们可以使用 systemd-nspawn 将此镜像作为容器启动:

$ sudo mkosi \
    -d rhel-ubi \
    -t directory \
    boot
systemd 252-14.el9_2.3 running in system mode (+PAM +AUDIT +SELINUX -APPARMOR +IMA +SMACK +SECCOMP +GCRYPT +GNUTLS +OPENSSL +ACL +BLKID +CURL +ELFUTILS -FIDO2 +IDN2 -IDN -IPTC +KMOD +LIBCRYPTSETUP +LIBFDISK +PCRE2 -PWQUALITY +P11KIT -QRENCODE +TPM2 +BZIP2 +LZ4 +XZ +ZLIB +ZSTD -BPF_FRAMEWORK +XKBCOMMON +UTMP +SYSVINIT default-hierarchy=unified)
Detected virtualization systemd-nspawn.
Detected architecture x86-64.
Detected first boot.

Red Hat Enterprise Linux 9.2 (Plow)
...
[ OK ] Created slice Slice /system/getty.
[ OK ] Created slice Slice /system/modprobe.
[ OK ] Created slice User and Session Slice.
...
[ OK ] Started User Login Management.
[ OK ] Reached target Multi-User System.

Red Hat Enterprise Linux 9.2 (Plow)
Kernel 6.5.6-300.fc39.x86_64 on an x86_64

image login: root (automatic login)

[root@image ~]# rpm -q rpm systemd
rpm-4.16.1.3-22.el9.x86_64
systemd-252-14.el9_2.3.x86_64

正如前面提到的,此镜像可以用于启动虚拟机。但在此设置下,这是不可能的 —— 我们的镜像没有内核。事实上,RHEL UBI 根本不提供内核,因此我们无法使用它进行引导(无论是在虚拟机上还是在裸机上)。

创建镜像

我一开始说是要创建镜像,但到目前为止我们只有一个目录。让我们开始实际创建一个镜像:

$ mkosi \
    -d rhel-ubi \
    -t disk \
    -p bash,coreutils,util-linux,systemd,rpm \
    --autologin

这将生成 image.raw,一个带有 GPT 分区表和单个根分区(用于本机架构)的磁盘镜像。

$ sudo systemd-dissect image.raw
Name: image.raw
Size: 301.0M
Sec. Size: 512
Arch.: x86-64

Image UUID: dcbd6499-409e-4b62-b251-e0dd15e446d5
OS Release: NAME=Red Hat Enterprise Linux
VERSION=9.2 (Plow)
ID=rhel
ID_LIKE=fedora
VERSION_ID=9.2
PLATFORM_ID=platform:el9
PRETTY_NAME=Red Hat Enterprise Linux 9.2 (Plow)
ANSI_COLOR=0;31
LOGO=fedora-logo-icon
CPE_NAME=cpe:/o:redhat:enterprise_linux:9::baseos
HOME_URL=https://www.redhat.com/
DOCUMENTATION_URL=https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/9
BUG_REPORT_URL=https://bugzilla.redhat.com/
REDHAT_BUGZILLA_PRODUCT=Red Hat Enterprise Linux 9
REDHAT_BUGZILLA_PRODUCT_VERSION=9.2
REDHAT_SUPPORT_PRODUCT=Red Hat Enterprise Linux
REDHAT_SUPPORT_PRODUCT_VERSION=9.2

Use As: ✗ bootable system for UEFI
        ✓ bootable system for container
        ✗ portable service
        ✗ initrd
        ✗ sysext extension for system
        ✗ sysext extension for initrd
        ✗ sysext extension for portable service

RW DESIGNATOR PARTITION UUID PARTITION LABEL FSTYPE ARCHITECTURE VERITY GROWFS NODE PARTNO
rw root 1236e211-4729-4561-a6fc-9ef8f18b828f root-x86-64 xfs x86-64 no yes /dev/loop0p1 1

好的,我们现在有一个镜像,镜像中包含了一些来自 RHEL UBI 软件包的内容。我们如何在其上加点我们自己的东西呢?

使用自己的文件扩展镜像

有几种方法可以扩展镜像,包括从头开始编译某些东西。但在那之前,让我们做一些更简单的事情,将一个现成的文件系统注入到镜像中:

$ mkdir -p mkosi.extra/srv/www/content
$ cat >mkosi.extra/srv/www/content/index.html <<'EOF'
<h1>Hello, World!</h1>
EOF

现在,该镜像将包含 /srv/www/content/index.html

这种方法用于注入额外的配置或简单的程序。

从源代码构建

现在让我们过一遍完整流程,从源代码构建一些东西。例如,一个简单的 Meson 项目,有一个单独的 C 文件:

$ cat >hello.c <<'EOF'
#include <stdio.h>

int main(int argc, char **argv) {
    char buf[1024];

    FILE *f = fopen("/srv/www/content/index.html", "re");
    size_t n = fread(buf, 1, sizeof buf, f);

    fwrite(buf, 1, n, stdout);
    fclose(f);
    return 0;
}
EOF

$ cat >meson.build <<'EOF'
project('hello', 'c')
executable('hello', 'hello.c',
            install: true)
EOF
$ cat >mkosi.build <<'EOF'
set -ex

mkosi-as-caller rm -rf "$BUILDDIR/build"
mkosi-as-caller meson setup "$BUILDDIR/build" "$SRCDIR"
mkosi-as-caller meson compile -C "$BUILDDIR/build"
meson install -C "$BUILDDIR/build" --no-rebuild
EOF
$ chmod +x mkosi.build

总结一下:我们有一些源代码(hello.c),一个构建系统配置文件(meson.build),以及一个由 mkosi 调用的胶水脚本(mkosi.build)。对于实际的项目,也会有相同的元素,只是更加复杂。

这个脚本需要一些解释。mkosi 在创建镜像时使用用户命名空间。这允许包管理器(例如 dnf)安装由不同用户拥有的文件,即使它是由一个普通非特权用户调用的。我们使用 mkosi-as-caller 切换回调用者以进行编译。这样,在 $BUILDDIR 下编译期间创建的文件将由调用者拥有。

现在让我们使用我们的程序构建镜像。与之前的调用相比,我们需要额外的软件包:mesongcc。由于我们现在有了构建脚本,mkosi 将执行两个构建阶段:首先创建一个构建镜像,并在其中调用构建脚本,将安装产物存储在一个临时目录中,然后构建最终镜像,并将安装产物注入其中。(mkosi 设置 $DESTDIRmeson install 自动使用 $DESTDIR,因此并不需要我们明确指定。)

$ mkosi \
    -d rhel-ubi \
    -t disk \
    -p bash,coreutils,util-linux,systemd,rpm \
    --autologin \
    --build-package=meson,gcc \
    --build-dir=mkosi.builddir \
    --build-script=mkosi.build \
    -f

此时,我们有了带有自定义载荷的镜像 image.raw。我们可以启动我们新创建的可执行文件作为 shell 命令:

$ sudo mkosi -d rhel-ubi -t directory shell hello
<h1>Hello, World!</h1>

获取 RHEL 的开发者订阅

RHEL UBI 主要用作容器构建的基础层。它提供了有限的软件包(约 1500 个)。现在让我们切换到完整的 RHEL 安装。

获取 RHEL 的最简单方法是使用 开发者许可证。它提供了权限注册 16 个运行 RHEL 的物理或虚拟节点,并提供自助式支持。

首先,创建一个账户。然后,转到 管理页面 并确保启用了“用于 Red Hat 订阅管理的简化内容访问”。接下来,创建一个新的激活密钥,选择 “Red Hat 个人开发者订阅”。记下显示的组织 ID。在下面,我们将使用密钥名称和组织 ID 分别表示为 $KEY_NAME$ORGANIZATION_ID

现在,我们准备使用 RHEL 内容:

$ sudo dnf install subscription-manager
$ sudo subscription-manager register \
    --org $ORGANIZATION_ID --activationkey $KEY_NAME

使用 RHEL 构建镜像

在之前的示例中,我们通过参数开关指定了所有配置。这对于快速开发很友好,但可能在情况复杂时变得难以处理。RHEL 是一个严肃的发行版,所以让我们改为使用配置文件:

$ cat >mkosi.conf <<'EOF'
[Output]
Format=directory
Output=rhel-directory

[Distribution]
Distribution=rhel

[Content]
Packages=
bash
coreutils
util-linux
systemd
systemd-boot
systemd-udev
kernel-core

Bootable=yes
Bootloader=uki
Autologin=yes
WithDocs=no
EOF

首先,让我们检查一下一切是否正常:

$ mkosi summary

现在让我们构建镜像(呃,或者说,目录):

$ mkosi build
$ mkosi qemu
Welcome to Red Hat Enterprise Linux 9.2 (Plow)!

[ OK ] Created slice Slice /system/modprobe.
[ OK ] Reached target Initrd Root Device.
[ OK ] Reached target Initrd /usr File System.
[ OK ] Reached target Local Integrity Protected Volumes.
[ OK ] Reached target Local File Systems.
[ OK ] Reached target Path Units.
[ OK ] Reached target Remote Encrypted Volumes.
[ OK ] Reached target Remote Verity Protected Volumes.
[ OK ] Reached target Slice Units.
[ OK ] Reached target Swaps.
...
[ OK ] Listening on Journal Socket.
[ OK ] Listening on udev Control Socket.
[ OK ] Listening on udev Kernel Socket.
...
Red Hat Enterprise Linux 9.2 (Plow)
Kernel 5.14.0-284.30.1.el9_2.x86_64 on an x86_64

localhost login: root (automatic login)
[root@localhost ~]#

很好,我们将“镜像”构建为一个带有文件系统树的目录,并在虚拟机中引导了它。

在引导的虚拟机中,findmnt / 显示根文件系统是 virtiofs。这是一个虚拟文件系统,将主机的目录暴露给客户机。我们其实也可以构建一个更传统的镜像,其中包含文件系统和文件内的分区表,但“目录 + virtiofs” 对于开发来说更快且更友好。

我们刚刚引导的镜像未注册。要允许从镜像“内部”下载更新,我们必须将 yumsubscription-managerNetworkManager 添加到软件包列表,并在下载任何更新之前以与上述相同的方式调用 subscription-manager。在这之后,我们在基本仓库中就有大约 4500 个软件包可用,并且还有一些包含更多专业软件包的额外仓库。

最后

今天就是这些了。如果您有问题,可以在 Matrix 上找到我们,地址为 #mkosi:matrix.org,或者在 systemd 邮件列表 上找到我们。

(题图:MJ/a6e60316-ed03-4e23-b8b4-22332a0f5bfa)


  1. Daan DeMeyer、Lukáš Nykrýn、Michal Sekletár、Zbigiew Jędrzejewski-Szmek ↩︎

via: https://fedoramagazine.org/create-images-directly-from-rhel-and-rhel-ubi-package-using-mkosi/

作者:Zbigniew Jędrzejewski-Szmek 选题:lujun9972 译者:GlassFoxowo 校对:wxy

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

1 Ubuntu Budgie 准备转而采用 Xfce

去年一月,有报道称,Budgie 桌面计划从基于 GNOME 转向 Enlightenment。但最近,Budgie 项目负责人称,Budgie 桌面希望构建一个纯 Wayland 环境,但由于 Enlightenment 对 Wayland 的只是还只是“实验性”的,因而该开发团队将与 Xfce 开发人员合作,为 Budgie 的 Wayland 未来而努力。

消息来源:The Register
老王点评:虽然我一直不批评 Linux 桌面到处在造轮子,但是目前看起来,无论是 GNOME、Enlightenment,还是 Xfce 都有各自的问题。

2 KDE Plasma 的 Wayland 支持仅剩一个阻碍

KDE Plasma 6.0 的功能冻结很快就会到来,Plasma Wayland 支持的三大阻碍也即将全部清除。在本周的改动中,在 Plasma Wayland 会话中重启或关闭系统将导致未保存更改的应用程序提示用户保存,而不是立即退出。这是 KDE 的最后三个 Wayland 问题之一。目前只剩下一个阻碍:并非所有的粘滞键选项都能正常工作,该问题也将很快解决。

消息来源:Phoronix
老王点评:怎么感觉,一夜之间大家都纷纷快速逃离了 X11 了?

3 PHP 8.0 生命终结

与所有软件一样,PHP 也有一个稳定的开发周期,以便解决新功能、错误和安全问题。2023 年 11 月 26 日,发布于三年前的 PHP 8.0 版本将终止支持,安全问题将不再得到修补。而前几天,PHP 8.3 刚刚发布。8.4 正在开发中。

消息来源:PHP
老王点评:别说 8.0 ,用更老版本的有没有?

如果在 Arch Linux 中安装软件包时遇到 “target not found” 错误,你可以采取以下措施。

有一天,我尝试在 Arch Linux 上安装 Hyprland。当我使用 Pacman 命令安装 它时,它抛出 “target not found”(目标未发现)错误。

$ sudo pacman -S hyprland
[sudo] password for abhishek:
error: target not found: hyprland

这是一个意外,因为我知道 Hyprland 是可用的。

我的修复方法是更新系统,在大多数情况下,它可以解决此问题。

sudo pacman -Syu

这里,本地包数据库不同步。我需要更新缓存。这里还建议更新系统。

在大多数情况下,这就是修复此错误的方法。但是,你看到此错误的原因可能还有其他一些。让我在这里详细讨论它们。

修复:更新系统

Arch Linux 是一个 滚动发布发行版,并且它提供的更新非常频繁。如果你不每隔几天更新一次系统,你的本地包数据库将与远程镜像不同步,并且你将在安装软件包时遇到问题。

本地包数据库仅保留包的元数据,例如版本号、用于获取包的仓库 URL 等。

当你搜索软件包时,pacman 会提供搜索结果,表明该软件包可用。但是,该包在你的本地数据库中具有较旧的版本号。当 pacman 在远程仓库中搜索包(以获取实际的包)时,它不再找到旧版本的 URL。

这就是导致 “target not found” 错误的原因。

修复方法是更新本地数据库。这可以与 pacman -Sy 一起使用,但是,建议 更新整个 Arch Linux 系统 以避免依赖冲突等。

sudo pacman -Syu
? 如果你已有几周没有更新系统,请做好更新超过 1 GB 的准备。这可能需要一些时间,具体取决于你的互联网速度和你使用的镜像。

就我而言,Arch 安装在我的辅助系统上。由于我一周左右无法使用它,该系统已经过时了。更新后,我就可以安装 Hyprland

? 如果这不起作用,请通过添加额外的 y 强制刷新所有包数据库: sudo pacman -Syyu

修复 “target not found” 错误的其他建议

如果上述方法没有为你解决此错误,这里有一些修复此错误的提示。

仔细检查包名称

我亲爱的 Watson,这可能看起来很简单,但人们通常只是错误地输入了包名称。

Linux 区分大小写,包通常以小写命名。因此,如果你要使用一个名为 Flameshot 的流行工具,那么它的包名称很可能是 flameshot。

此外,某些软件的拼写与常见软件的拼写不同。例如,它是 hyprland,这使我错误地输入了 hyperland(使用通常的 “hyper” 拼写)。

在极少数情况下,可能会混淆是 lI 或者 1

基本上,确保你输入的包名称是正确的。

查看该软件包在仓库中是否可用

Arch Linux 的仓库中有大量软件包。但这并不意味着它拥有所有可能的 Linux 软件包。

访问 Arch Linux 官方软件包网站:

Arch Linux 软件包搜索

在这里输入包名,查看该包是否可用。如果是,它是哪个仓库以及它在哪个设备上可用。

x86_64 适用于英特尔架构,任何包含 ARM 架构的均适用于 树莓派类设备

? 如果在某些仓库中找到该软件包,但 pacman 即使在更新的系统上也找不到它,请检查 pacman.conf 文件并查看是否启用了所述仓库。

确保它不是 AUR 包

Arch 用户仓库(AUR) 是提供更新包的附加社区支持平台。

现在,有多种使用 AUR 包的方法,但 pacman 不是其中之一。

检查你尝试安装的软件包是否是 AUR 软件包。首先检查官方 Arch 仓库,如上所述。如果不存在,请检查 AUR 页面。

如果它是 AUR 包,则必须 使用 yay 或一些 其他 AUR 帮助程序。你不能使用 pacman 安装 AUR 软件包。

你能解决这个问题吗?

在大多数情况下,更新系统可以解决此问题。在极少数情况下,可能还有其他原因,我已经提到了一些建议。

现在轮到你了。如果你能够解决此问题,请在评论区告诉我。

(题图:MJ/b71c9760-4cb1-41de-a336-3e38026bcfeb)


via: https://itsfoss.com/target-not-found-arch-linux/

作者:Abhishek Prakash 选题:lujun9972 译者:geekpi 校对:wxy

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

并不是,不过 “功能源代码许可证” 却更进一步混淆了开源许可证的界限。

回溯到我们还用打孔卡和磁带载入软件的那时,所有的程序都是 “自由软件” 和 “开源” 的。然而随后专有软件的出现,一切都变了。针对此状况,程序员们反抗并发展出了第一个正式的自由和开源软件的定义。

现如今,不开源的代码甚至成为了罕见的例外。然而,这并未阻止某些误将开源视为一种商业模式,而非开发模式的公司,试图将专有方法和 “开源” 代码相结合。最新的案例就是 Sentry 推出的 “ 功能源代码许可证 Functional Source License ”(FSL)。

沿袭 服务端公共许可证 Server-Side Public License (SSPL)、 公共条款 Common Clause 商业源代码许可证 Business Source License 的传统,FSL 表面上似乎重视开源的重要性,却对开源的核心理念进行嘲讽,形容其方式为“享有自由却无需付出努力”。

呵呵。

其实,Sentry 是一个面向开发者的应用代码监控服务,它源于对 Django(一款开源的,高级的 Python 网络框架)的少量代码开发。如今,它仍然主要用开源代码进行开发。不难看出,没有开源,Sentry 啥都不是。

这也同样适用于其他所有使用 “ 源代码可用 source-available ” 或其他半开源许可证的公司。它们都源自于开源公司,然后为了最大化利润,它们将免费获取的代码进行了重新许可,以锁定代码。

正如 开源倡议 Open Source Initiative (OSI)董事会副主席 Thierry Carrez 对我说的,“有些公司通过利用开源代码库作为主体建立了他们的软件,不需要在使用数百个开源软件包作为他们的依赖关系之前就请求许可。他们通过公开承诺遵守开源原则建立了口碑。但在试图追求更大价值的过程中,他们短视地放弃了最初带给他们成功的模式。”说的真对。

例如 Sentry、MariaDBRedisHashiCorp 这样一些前开源公司,之所以他们能做出这样的举动,可以归功于他们采用了侵犯了权利的 贡献者许可协议 Contributor License Agreements (CLA)。这些协议是一种法律文件,它定义了贡献者为他们的代码在开源项目中被使用所设定的条款。尽管有些 CLA,像 Apache 软件基金会的 CLA 或 Linux 的 开发者原创证书 Developer Certificate of Origin ,只是用来保护他们项目的法律权利。但其他一些,比如 MongoDB 的贡献者协议,却被用来占有你的代码及其版权。通过这样的 CLA,在任何他们喜欢的方式中使用和重新许可你的代码,对于他们来说易如反掌。

SourceHut 的创始人兼首席执行官 Drew Devault 在谈论 Elasticsearch 从开源向“源码可用”转变时表达了他的观点:“Elasticsearch 归其 1,573 名贡献者所有,他们自己保留着版权,并向 Elastic 授予了一个无条件分发他们作品的许可。当 Elastic 决定 Elasticsearch 不再开源时,他们就利用了这个漏洞,这个漏洞实际上一开始就被他们故意安插进去…… Elastic 对 1,573 的贡献者们、以及所有信任、忠诚于他们,给予他们支持的人们翻了脸。”

如今,我们看到企业 Sentry 和之前的案例如出一辙,换汤不换药。公正地讲,Sentry 很长一段时间以来都一直在使用源码可用许可证。在该公司创建并采用 FSL 前,自 2018 年以来就用了 BSL。如果还有人继续向 Sentry 捐献代码,那他们肯定知道自己在做什么。

那么为何还要做一个新许可证呢?Sentry 的开源负责人 Chad Whitacre 这样解释道:“BSL 存在两个显著的弊端。首先,预设的非竞争期为四年,对于软件行业来说,这简直就是个漫长的周期。这可能会让人产生一种感觉,即最后的开源转变只是一种象征性的举措。这几乎可以说是 100 年那么长。对于 Sentry,我们选择将这个期限缩短到三年,但我们也承认,可能连三年都过长了。”

该许可证期满后,这些代码将会使用 Apache 2.0 或者 MIT 许可证。但实际上,这并不像初听起来那么慷慨。根据 FSL,你可以将它的代码用在任何用途 —— “除了竞争性使用的情况下。所谓竞争性使用,指的是利用该软件开发或提供能够与我们的产品或服务竞争的商业产品或服务,不论是该软件本身,还是我们基于该软件提供的任何其他产品或服务,只要我们是在该软件发布之日或之前就已经提供了这类竞争产品或服务。”

换种说法,你可以查看代码,但不能用这些代码运营业务。如需更深入了解,你可以查看该公司的 FSL 版本的 Apache 和 MIT 许可证。就我个人而言,我认为这两个都不算是开源许可证。

Whitacre 进一步说明了,“更严重的缺陷是 BSL 有过多的参数:变更日期、变更许可证,以及额外使用授予。最大的问题在于额外使用授予,它是一项巨大的填空题,意味着每一个 BSL 实质上都是不同的许可证。”

我无法反驳这一观点。每个公司的 BSL 都不一样。同时,这也意味着当客户与使用 BSL 的公司签约时,他们很难确切知道法律上为他们保留了哪些权益。Sentry 希望通过 FSL 让其产品和服务对其客户更具吸引力。

也许这方法行得通。但我赞同 Carrez 所说的:“发布另一种能剥夺开发者在技术选择中的自主权的许可证变体并非新鲜事:他们其实就是要从整个软件生态系统中摧毁开发者的基本自由,从而明确自己对其专有软件及其许可使用权的所有权。这并不是开源:这只是包装在开源幌子下的专有门户。”

(题图:MJ/beb19f23-c230-4a3f-9bb3-210066ad749b)


via: https://www.theregister.com/2023/11/24/opinion_column/

作者:Steven J. Vaughan-Nichols 译者:ChatGPT 校对:wxy

1 Debian 的 MIPS64EL 架构面临放弃

Debian 的 MIPS64EL 是一个 64 位小端架构。由于缺乏足够的编译守护进程资源来及时编译新软件包,该架构现在被视为 “不同步” 架构,如果情况得不到改善,它可能不适合作为 Debian 13 的发布架构。MIPS 作为 CPU 架构已经走入死胡同,没有进一步的开发计划。MIPS 公司现在正专注于 RISC-V,而中国以前著名的 MIPS 供应商龙芯现在已经将 MIPS 演进为他们自己的 LoongArch CPU 架构。几个月前,Debian 也已经放弃了其 32 位 MIPS 小端 MIPSEL 移植。最初的 MIPS CPU 32 位移植在 Debian 10 之后就被放弃了。

消息来源:Phoronix
老王点评:MIPS 这种架构早该放弃了,硬件都难找到了。

2 Blender 遭遇 DDoS 攻击

从 11 月 18 日到 22 日,3D 开源建模软件项目 Blender 遭遇了持续五天的 DDoS 攻击,网站一度被迫下线。该攻击由一个僵尸网络执行,其数百个 IP 地址发送了超过 15 亿次恶意请求,峰值速率为 10 万 RPS。目前还没有人声称对此次攻击负责,攻击动机也不明。攻击的重点是拒绝服务,项目和用户数据未受影响。Blender 是通过迁移到 CloudFlare 的 DDoS 缓解服务之后才解决问题。攻击在 23 日停止,网站恢复正常。

消息来源:Blender
老王点评:这得多闲,攻击这种开源软件项目能有什么好处?

3 四年后,OpenMandriva Lx 5.0 发布

在 4.0 发布四年多之后,OpenMandriva Lx 5.0 终于亮相了。OpenMandriva Lx 5.0 是 OpenMandriva Linux 发行版的定点发行版,也是在二月份发布 Plasma 6.0 桌面之前使用 Plasma 5 桌面的最后一个版本。在此版本中,OpenMandriva 首次合并了 //usr

消息来源:Phoronix
老王点评:这个发行版让我回忆起当年的曼德拉草,当时感觉很好,但是后来就没那么惊艳了。

就在昨日,LLUG 爱好者沙龙活动杭州场在杭州未来科技城国际人才园成功举办。

本次活动由 Linux 中国和龙蜥社区(OpenAnolis)联合主办,杭州城西科创大走廊高层次人才联合会和杭州 GDG 提供支持。本次活动主要由 5 位本地嘉宾和 1 位远程嘉宾线上线下分享,帮助大家在杭州遇到同为 Linux 爱好者的小伙伴,一起在这个周末,交流技术,学习技术。

来自 Deepin 团队的内核研发工程师王昱力分享了 Deepin V23 操作系统在内核层面、使用层面的一些更新,并帮助与会人员前瞻了 V23 的各项细节改进,帮助大家更好的了解到 Deepin 这一优秀的国产发行版的现状和未来。

老王则通过远程的为现场参会的同学们带来了他的分享:《高效开源(个人篇 + 企业篇)》,帮助参会的同学们了解开源、学习开源,从个人的视角加入开源,并从企业的视角来解读开源的价值,帮助参会者理解为什么企业要做开源,以及如何更好的推进开源的落地。

Bestony 为现场的同学们分享了自己的大模型的开发经验,帮助参会同学们理解大模型的原理、当下的开发者们如何使用和迭代自己对于大模型的使用,提升自己的能力。

杭州 LUG 活动组织者 strrl 也来到现场,为现场参会者介绍了 hzlug 的历史和现状,并邀请大家参与到 hzlug 的活动组织中,与更多的小伙伴共同交流技术。

开源云平台 laf 的工程师 smile 则为大家介绍了 laf 云平台的优势和价值,帮助大家了解 laf ,演示 Laf 的使用。

姜亦丰则带来他在研究八卦和计算机时的心得。

PPT及视频下载

LLUG 的创办希望帮助 Linux 社区当中的每一个人都可以充分的交流经验和心得,所以我们也将本次活动的视频以及演示文稿开放出来,供大家查看。视频托管在 Bilibili,PPT 文稿则托管在 Github 的 Linux-CN/LLUG-Shares 仓库中,供大家下载。

本次活动的 PPT 已经上传至 GitHub ,方便大家下载,视频也以上传至 Bilibili 和 Linux 中国视频号,方便大家收看。

类型活动主题主讲人PPT在线视频
主题演讲《deepin v23 内核成果分享与技术前瞻》王昱力,deepin社区 内核研发工程师下载Bilibili
主题演讲《开源实用指南(个人篇+企业篇)》硬核老王下载Bilibili
主题演讲《大模型应用开发经验分享》bestony下载Bilibili
闪电演讲《欢迎加入 HZLUG》strrl下载Bilibili
闪电演讲《LAF 开源云平台一览》smileBilibili
闪电演讲《伪随机数和梅花易数》姜亦丰下载Bilibili

致谢

本次活动的举办,得到了杭州城西科创大走廊高层次人才联合会提供的线下场地支持,为 Linux 爱好者们提供了活动场地,协助提供活动所需的各项物资,使得活动可以成行。同时,也感谢杭州 GDG 在活动推广过程中提供的帮助,帮助活动走向更多的人群。

感谢大家的支持,才能让本次活动成功举办!

12 月,北京见

LLUG 起于 2023 年的 6 月北京场,而在 2023 年的 12 月,我们将再次回到北京,在北京结束 LLUG 2023 年的旅程,为 2024 做好承上启下的工作。如果你感兴趣做分享,或是有更多的建议给到我们,可以扫描下方二维码,申报议题或提交建议。无论是标准的主题演讲 ,还是 5 分钟简短的闪电演讲,都期待你的报名~

主题演讲/闪电演讲报名

(题图:MJ/eacaca27-be46-4e32-9a74-c584f8f5fdf1)