分类: 技术新闻

技术新闻

  • Fedora Linux 40 发布

    Fedora Linux 40 发布

    硬件概述

    Fedora 40 提供了适合各种应用程序的软件。存储、内存和处理要求因使用情况而异。例如,高流量数据库服务器比企业桌面需要更多的内存和存储,而企业桌面又比单一用途虚拟机具有更高的要求。

    最低系统配置

    下图是默认安装的建议最低值。您的要求可能有所不同,大多数应用程序将受益于超过最低限度的资源。

    • 2GHz 双核处理器或更快
    • 2GB 系统内存
    • 15GB 未分配的驱动器空间

    配备最小内存为 2GB 的系统的用户可能需要考虑资源密集型桌面环境的 Fedora Spins

    低内存安装Fedora 40 可以安装和使用在某些应用程序资源有限的系统上。对于内存非常低的系统,建议使用文本、VNC 或 kickstart 安装,而不是图形安装。较大的软件包集在安装过程中需要更多的内存,因此系统内存小于 768MB 的用户在执行最小安装并在之后添加它可能会获得更好的结果。为了在内存小于 1GB 的系统上获得最佳效果,请使用 DVD 安装映像。

    对于具有 Gnome 桌面的默认 x86_64 Workstation 安装,建议使用下图。您的要求可能会有所不同,具体取决于桌面环境和用例。

    • 2GHz 四核处理器
    • 4GB 系统内存
    • 20GB 未分配的驱动器空间

    低内存安装

    Fedora 40 可以安装和使用在某些应用程序资源有限的系统上。对于内存非常低的系统,建议使用文本、VNC 或 kickstart 安装,而不是图形安装。较大的软件包集在安装过程中需要更多的内存,因此系统内存小于 768MB 的用户在执行最小安装并在之后添加它可能会获得更好的结果。

    为了在内存小于 1GB 的系统上获得最佳效果,请使用 DVD 安装映像。

    显示分辨率

    支持 1024×768 屏幕分辨率的 VGA

    图形安装需要 800×600 或更高的分辨率

    Fedora 的图形安装要求最低屏幕分辨率为 800×600。分辨率较低的设备(例如某些上网本)的所有者应使用文本或 VNC 安装。

    安装后,Fedora 将支持这些低分辨率设备。最低分辨率要求仅适用于图形安装。

    图形硬件

    加速桌面的最低硬件

    Fedora 40 支持大多数显示适配器。像 GNOME3 和 KDE Plasma Workspaces 这样的现代、功能丰富的桌面环境使用视频设备来提供 3D 加速桌面。较旧的图形硬件可能不支持加速:

    • GMA9xx 之前的英特尔
    • NV30 之前的 NVIDIA(GeForce FX5xxx 系列)
    • R300 之前的 Radeon (Radeon 9500)

    CPU 加速显卡

    具有较旧或没有图形加速设备的系统可以使用 LLVMpipe 技术来加速桌面环境,该技术使用 CPU 渲染图形。LLVMpipe 需要带有扩展的处理器。处理器支持的扩展列在SSE2flags:/proc/cpuinfo

    为您的硬件选择桌面环境

    Fedora 40 的默认桌面环境 GNOME3 在硬件加速方面表现最佳。对于图形硬件较旧的用户或使用 LLVMpipe 时性能不足的用户,建议使用替代桌面。

    桌面环境可以添加到现有安装中,并在登录时进行选择。要列出可用的桌面,请使用以下命令:dnf grouplist

    # dnf grouplist -v hidden | grep Desktop

    安装所需的组:

    # dnf groupinstall "KDE Plasma Workspaces"

    或者,使用短组名称安装:

    # dnf install @mate-desktop-environment

    Fedora 40 for System Administrators 的变化

    安装程序更改

    有关 Fedora 的 Anaconda 安装程序和相关组件(如 Kickstart)的更改列表,请参阅上游发行说明

    Fedora IoT 可启动容器

    现在有一个可用于 Fedora IoT 版本的可启动映像。这为用户提供了使用 Fedora 物联网的新方法,这可能更适合他们的环境和生态系统,从而允许更广泛的采用。

    您可以在 Fedora IoT 官方页面下载新映像。另请参阅文档

    [[389-目录服务器-3-0-0]] == 389 目录服务器 3.0.0 Fedora 40 提供了 389 Directory Server 的新主要版本,这是对以前版本中提供的 2.4.4 版本的重大升级。

    一个主要的变化是,从这个版本开始,新实例默认使用 LMDB 创建,而不是以前默认的 BerkeleyDB。有关详细信息,请参阅此处

    将pam_userdb从 BerkeleyDB 切换到 GDBM

    pam_userdb是在支持 BerkeleyDB 的情况下构建的,但这个项目不再作为开源维护,因此在 Fedora 40 中被 GDBM 取代。请参阅 Fedora 系统管理员指南以获取有关如何转换的信息。

    AD 和 IPA 后端已删除对该功能的支持enumeration

    该功能提供了列出所有使用 AD 和 FreeIPA 提供商或已删除功能的用户或组的功能的功能。enumerationgetent passwdgetent group' without arguments. Support for the `enumeration

    sss_ssh_knownhostsproxy工具将在将来的版本中替换

    sss_ssh_knownhostsproxy工具已被弃用,将被新的、更多 高效的工具。详见上游工单

    删除 SSSDfiles provider

    Fedora 40 中移除了之前弃用的 SSSD “文件提供程序” 功能,该功能允许处理本地用户。这不会影响默认配置,其中本地用户由 glibc 模块 () 处理,在大多数情况下是这样。如果特定配置需要 SSSD 处理本地用户(智能卡身份验证或本地用户的会话录制),请改用 SSSD。如果您属于这些用例之一,请参阅上游文档了解更多详细信息。libnss_files.so.2proxy provider

    Authselect 最小配置文件替换为本地配置文件

    Authselect 的配置文件现在替换为 。新的配置文件基于但获得了额外的可选功能,它用于为没有 SSSD 的本地用户和组提供服务。从配置文件到配置文件的迁移是在重新安装或升级到 Fedora 40 时自动执行的,用户不受影响。但是,由于配置文件不再可用,用户应使其脚本适应新的配置文件。minimallocallocalminimalminimallocallocalminimal

    bogofilter使用 SQLite

    Bogofilter(包)是一种快速的反垃圾邮件过滤机制,它使用贝叶斯统计分析将电子邮件分类为垃圾邮件或非垃圾邮件。它使用 Berkeley DB(包)作为其数据库引擎,用于存储单词概率和过滤过程中使用的其他相关数据。bogofilterlibdb

    在这个版本中,Bogofilter 将其数据库引擎从 Berkeley DB 切换到了 SQLite,因为 Fedora 弃用了该软件包。libdb

    Bogofilter 一次只支持一个数据库后端,因此更新后的包将无法处理数据。因此,新包提供了一个迁移脚本。或者,您可以使用此命令手动迁移单词列表。bogofilterlibdbbogomigrate-berkeley ~/.bogofilter/wordlist.db

    podman 5

    容器引擎已升级到版本 5,该版本提供了多个错误修复和增强功能。值得注意的变化包括:podman

    • 放弃了对版本 1 的支持(环境必须切换到版本 2)cgroupscgroups
    • 已弃用的容器网络接口 (CNI) 插件(环境必须切换到网络堆栈)netavark
    • 已弃用的 BoltDB
    • 设置为默认的无根网络服务,而不是passtslirp4netns
    • 改进了对文件的处理containers.conf
    • 隔离绑定,确保提高可用性podman

    有关更新的完整范围,请参阅上游发行说明

    ROCm 6

    用于图形处理单元 (GPU) 计算的 ROCm 堆栈已更新到版本 6,它提供了多个错误修复和增强功能。值得注意的变化包括:

    • 改进了在低精度数学和注意力层等领域的性能
    • 全新 hipSPARSELt 库,通过 AMD 稀疏矩阵核心技术加速 AI 工作负载
    • 对 PyTorch、TensorFlow 和 JAX 等 AI 框架的最新支持
    • 新增对 DeepSpeed、ONNX-RT 和 CuPy 等库的支持

    有关更新的完整范围,请参阅上游发行说明

    stratisd 3.6

    此升级包括 stratisd 3.6.7 和 stratis-cli 3.6.0 的新版本。

    这些版本包括许多改进、错误修复和内务管理 变化。以下是更改的简要摘要。

    Stratisd 3.6.7 包括对 Stratisd 3.6.6 中引入的一个错误的修复,该错误 如果池已加密,则导致 stratis-min pool start 命令失败 并在命令行上指定了用于解锁池的密码。它 还包括对 Stratisd 3.6.4 中引入的错误修复,该错误阻止了 挂载 /etc/fstab。

    Stratisd 3.6.6 修复了一个错误,该错误可能会误报 尝试启动时已运行的 stratisd 实例的 PID 另一个实例。它还包括对字符串大小的限制 Stratis 池级元数据中的值。

    StratisD 3.6.5 包括对其内部锁定机制的修改 它允许与当前持有的锁不冲突的锁 在锁之前。此更改放宽了公平性限制,即 仅根据锁的顺序优先 放置在等待队列中。

    stratisd 3.6.4 包括对 Start命令的 stratisd-min 处理的修复 由 Stratis-min 发送到未加密的池。它还捕获和记录错误 thin_check 或 mkfs.xfs 可执行文件发出的消息。

    StratisD 3.6.3 在调用时将 nrext64 选项显式设置为 0 mkfs.xfs. 最新版本的 XFS 将 nrext64 的默认值更改为 1。 显式将值设置为 0 可防止 stratisd 创建 XFS 在早期内核上无法挂载的文件系统。

    Stratisd 3.6.2 修复了精简设备的分配方式 以避免瘦数据设备的不同部分错位。这样 错位可能会导致性能下降。

    Stratisd 3.6.1 包括一个修复程序,用于纠正 Stratisd 会失败的问题 如果池同时使用 Clevis 和内核加密,则解锁池 密钥环方法,但内核密钥环中的密钥不可用。

    Stratisd 3.6.0 扩展了其功能,允许用户设置限制 文件系统的大小,并包括许多额外的增强功能。

    stratis-cli 3.6.0 命令行界面已扩展为 用于在创建时设置文件系统大小限制的附加选项和两个新选项 文件系统命令 set-size-limit 和 unset-size-limit,用于设置或取消设置 创建文件系统后的文件系统大小限制。

    所有版本都包括各种内部改进、便利性和次要功能 Bug修复。

    有关更多详细信息,请参阅 stratisd 更新日志和 stratis-cli 更改日志

    下降增量 RPM

    增量 RPM (DRPM) 是一项功能,它通过仅下载新旧版本的 RPM 包之间的差异 (delta) 来减少更新包所需的时间和数据。然后,根据您当前的版本和增量,您的系统会在本地使用新版本的软件重新组装完整的 RPM 软件包。

    在这个 Fedora 发行版中,DRPM 将不再在编写过程中生成。此外,默认情况下,DRPM 支持将处于禁用状态。此更改的一些最显着原因如下:dnfdnf5

    • 由于在编写过程中生成 DRPM 的方式,不可能为所有包生成 DRPM。因此,这可能导致涉及数百个软件包的升级,但其中只有一小部分(或根本没有)在存储库中具有适当的 DRPM。
    • 重新构建新的 RPM 版本可能会失败。这会导致额外下载新版本的完整 RPM。
    • 存储库中 DRPM 的存在会增加存储库元数据的大小。所有用户都需要下载该元数据,无论实际升级是否涉及 DRPM。

    此更改旨在带来以下好处:

    • 简化了“更新”和“更新测试”存储库的编写过程,因为跳过了 DRPM 的生成。
    • 减少存储库元数据更新的带宽使用量。
    • 由于元数据较小和 DRPM 丢失,减少了 Fedora 基础设施和存储库镜像的存储需求。
    • 为用户提供更可靠的升级。

    默认情况下停止下载文件列表

    文件列表是 XML 文件,它提供重要的元数据和信息,便于 RPM 包的安装、管理和维护。

    在这个 Fedora 发行版中,DNF 行为发生了变化,默认情况下将不再下载文件列表。原因是,文件列表提供的元数据在大多数用例中是不必要的,而且它们的大小很大。这导致用户体验显着减慢。

    此更改旨在带来以下显着好处:

    • 显著减少 RPM 包构建、安装、测试环境创建等的处理时间和资源使用
    • 降低 Fedora 镜像服务器操作的成本
    • 降低 DNF 进程的 RAM 要求,解决了在低内存机器(如 Raspberry Pi)上运行 Fedora 系统时的现有问题

    请注意,在查询位于 或目录中的文件提供时,您仍然可以使用没有文件列表元数据的 DNF。/usr/bin/usr/sbin/etc

    wget2 作为 wget

    Fedora 40 中的命令使用 Wget2。wget

    GNU Wget2 是 GNU Wget 的继任者,它提供了由新库支持的 wget 的现代实现:.从 wget 1.x 切换到 wget2 的目的是切换到更积极开发的实现,并为利用 wget 的功能提供更丰富的接口。libwget2

    默认情况下,在 NetworkManager 中启用 IPv4 地址冲突检测

    现在,NetworkManager 中默认启用 IPv4 地址冲突检测。换句话说,RFC 5527 现在默认启用,间隔为 200 毫秒。

    为 Wi-Fi 连接分配单独的稳定 MAC 地址

    Fedora 40 采用默认模式,在 NetworkManager 中为 Wi-Fi 连接分配单独的、稳定的 MAC 地址,在不影响网络稳定性的情况下增强用户隐私。stable-ssid

    更改涉及添加新文件 .此文件设置为 Fedora Linux 40 的 NetworkManager 中 Wi-Fi 连接中 MAC 地址选择的默认模式。该模式根据网络的SSID和机器ID选择不同的MAC地址,旨在增强用户隐私。这个新的默认值将应用于 Fedora 40 及更高版本中不会覆盖默认值的 Wi-Fi 配置文件。/usr/lib/NetworkManager/conf.d/22-wifi-mac-addr.confwifi.cloned-mac-address=”stable-ssid”stable-ssid

    随着 ‘stable-ssid ‘ 在 Fedora 40 中采用默认值,现有用户可能会遇到 Wi-Fi 连接行为的变化,尤其是那些网络设置依赖于固定 MAC 地址的用户。请注意,升级到 Fedora 40 将默认应用这个新的 MAC 地址随机化。需要为特定网络保持一致的 MAC 地址的用户可以通过执行以下步骤之一来解决此问题:

    1. 手动将特定配置文件的 wifi.cloned-mac-address 设置为永久:nmcli 连接修改 [$PROFILE] wifi.cloned-mac-address 永久
    2. 在 中创建自定义配置文件,该文件可以为空或包含特定配置。这将阻止加载默认文件。/etc/NetworkManager/conf.d/22-wifi-mac-addr.conf/usr/lib
    3. 创建一个优先级更高的 .conf 文件,例如 ,其中包含以下内容:/etc/NetworkManager/conf.d/90-wifi-mac-addr.confwifi.cloned-mac-address=永久

    有关配置文件的加载顺序及其优先级的详细信息,请参阅。man NetworkManager.conf

    PostgreSQL 16

    Fedora 40 提供了 PostgreSQL 的版本 16。有关更多信息,请参阅上游发行说明

    SPDX 迁移

    RPM 软件包使用许可证的 SPDX 标识符作为标准。63%的软件包和几乎所有来自ELN的包装都已迁移到SPDX标识符。其余的软件包估计将迁移到 Fedora 41 中的 SPDX。

    Fedora 40 桌面版用户版变更

    KDE Plasma 6

    Fedora 40 提供了 KDE Plasma 6 桌面环境,这是对之前版本的重大升级。

    新版本提供了许多重大更改,包括部分 HDR 支持、新的概览效果、浮动面板等。此外,立方体又回来了。

    KDE Plasma 6 是 KDE 社区创建的 KDE Plasma 5 的继任者。它基于 Qt 6 和 KDE Frameworks 6,与以前的版本相比带来了许多变化和改进。对于 Fedora Linux,向 KDE Plasma 6 的过渡还将包括完全放弃对 X11 会话的支持,只留下 Plasma Wayland 作为唯一提供的桌面模式。但是,仍然支持 X11 应用程序。有关详细信息,请参阅“更改”页面上的“反馈”部分。

    有关新 KDE 版本的完整信息,请参阅官方公告

    IBus 变更

    在 Fedora 中提供多语言输入的 IBus 软件包已更新到 1.5.30 版。增强功能包括:

    • 和 命令适用于 Wayland 上的 KDE Plasma。(他们之前曾在 X11 的 Plasma 中工作过。ibus startibus restart
    • “首选项”菜单项将显示在 Wayland 上 Plasma 的 IBus 激活菜单中。(在 X11 上的 Plasma 中不需要更改,因为上下文菜单也可用。

    此外,更新后的软件包现在为使用日语区域设置的用户更新了 2024 年的日语时代。ibus-anthy

    Fedora 40 For Developers 的变化

    PyTorch的

    Fedora 40 是第一个提供 PyTorch 的 Fedora 版本,PyTorch 是一个基于 Torch 库的机器学习框架,用于计算机视觉和自然语言处理等应用程序,最初由 Meta AI 开发,现在是 Linux 基金会的一部分。它是在修改后的 BSD 许可证下发布的免费开源软件。

    将 PyTorch 作为 Fedora 软件包提供意味着用户现在可以使用 DNF 而不是 pip 进行安装。Fedora 40 中提供的初始版本是 2.1.2。要安装,请运行 。dnf install python-torch

    要开始使用 PyTorch,请参阅官方文档。那些对 Fedora 中的 PyTorch 特别感兴趣的人——开发人员、打包者、最终用户等等——可以加入 PyTorch Fedora 特别兴趣小组

    PHP 8.3的

    PHP 编程语言解释器的堆栈已升级到版本 8.3,它提供了多个错误修复和增强功能。值得注意的变化包括:

    • 类常量的显式类型
    • 动态类常量 fetch
    • 新属性#[\Override]
    • 只读属性的深度克隆
    • 新功能json_validate()
    • 新方法Randomizer::getBytesFromString()
    • 命令行 linter 支持多个文件

    有关更新的完整范围,请参阅上游发行说明

    Golang 1.22

    Fedora 40 提供 Golang 版本 1.22。有关更改的完整列表,请参阅上游发行说明

    停用 Python 3.7

    从此版本开始,Python 版本 3.7 被视为自 2023 年 6 月起生命周期结束,因此被视为停用且不替换。

    LLVM 18型

    所有 LLVM 子项目都已更新到版本 18,其中包括 llvm 库的同名版本更改。添加了兼容包 clang17、llvm17 和 lld17,以确保当前依赖于 clang 和 llvm 版本 17 库的包将继续工作。

    其他值得注意的变化包括:

    • 默认情况下,clang 将发射 DWARF-5 而不是 DWARF-4。这与上游默认值匹配。由于 https://bugzilla.redhat.com/show_bug.cgi?id=2064052,Fedora 一直使用 DWARF-4 作为最近几个版本的默认版本。
    • 兼容包现在将包含与主包相同的内容。在以前的版本中,兼容包仅包含库和标头,二进制文件和其他内容被剥离。这些包将支持用作其他 RPM 包的依赖项,但不支持最终用户使用一般用途。Fedora 用户应该使用 Clang/LLVM 18。
    • 为 Fedora 40 添加的兼容软件包将在 Fedora 41 分支之前停用。
    • 如果此功能在上游 LLVM 18 版本中及时完成,我们将在 redhat-rpm-config 中启用 Fat LTO。Fat LTO 是一项功能,它允许编译器生成包含 LTO 位码的库以及传统的 ELF 二进制代码,以便可以在 LTO 模式和非 LTO 模式下链接库。gcc 也支持此功能,并在 Fedora 中启用了它。在 Fedora 39 及更早版本中,启用了 LTO 后,clang 只使用 LTO 位码生成二进制文件,因此我们需要在库上运行后处理脚本 (brp-llvm-compile-to-elf) 将它们转换为 ELF 代码,以便其他软件包可以使用它们。启用 Fat LTO 允许 Fedora Project 删除此脚本并简化构建过程。

    有关详细信息,请参阅上游发行说明

    GNU 工具链更新

    GNU Compiler Collection、GNU Binary Utilities、GNU C Library 和 GNU Debugger 构成了 GNU 工具链的核心部分,对于我们的用户来说,在制作 Fedora 的新版本时,将这些组件作为一个完整的实现进行转换是很有用的。

    GNU 工具链的组件(gcc、glibc、binutils、gdb)在 Fedora 40 中已更新到以下版本:

    Boost 1.83

    Fedora 40 包括 Boost 1.83。有关更多信息,请参阅上游发行说明

    Ruby 3.3

    Ruby 语言在 Fedora 40 中已经更新到 3.3 版,高于之前 Fedora 发行版提供的 3.2 版。新版本添加了一个名为 Prism 的新解析器,使用 Lrama 作为解析器生成器,添加了一个名为 RJIT 的新纯 Ruby JIT 编译器,并提供了许多性能改进,尤其是 YJIT。

    java-21-openjdk 作为系统 JDK

    系统 JDK 已在 Fedora 40 中从版本 17 更新到版本 21。

    有关 Java 21 的更多信息,请参阅 JDK 21 发行说明迁移指南

    另请参阅更改页面,了解有关此更改的快速常见问题解答。

  • 关于现在的SSL库

    关于现在的SSL库

    自从2014年4月7日Openssl的心脏出血Heartbleed漏洞被曝出现后引起了广大开源社区的重视,有实力有需求的厂商和开源组织开始重新审视Openssl加密库的安全问题,因此先后出现了像boringssl,libressl,quictls等新的版本的openssl库。呈现出百花齐放的来源事态。

    Openssl的心脏出血Heartbleed是一个出现在加密程序库OpenSSL的安全漏洞,该程序库广泛用于实现互联网的传输层安全(TLS)协议。它于2012年被引入了软件中,2014年4月首次向公众披露。只要使用的是存在缺陷的OpenSSL实例,无论是服务器还是客户端,都可能因此而受到攻击。此问题的原因是在实现TLS的心跳扩展时没有对输入进行适当验证(缺少边界检查),因此漏洞的名称来源于“心跳”(heartbeat)。该程序错误属于缓冲区过滤,即可以读取的数据比应该允许读取的还多。HeartBleed主要存在与OpenSSL的1.0.1版本到1.0.1f版本。利用该漏洞,攻击者可以远程读取服务器内存中64K的数据,获取内存中的敏感信息。

    我们这里谈谈这三个主流的取代openssl的加密库:

    Boringssl

    Boringssl是谷歌主导的一个openssl分支,目的为满足gooogle自己的开发需求而建立。虽然BoringSSL是一个开源项目,但它并不适合一般 使用,就像 OpenSSL 一样,谷歌不建议第三方依赖它。谷歌不提供对第三方的API及ABI和稳定性保证。话虽如此,谷歌的意思是不要过分依赖第三方的版本,而是根据自己需求去构建自己的副本。谷歌的Boringssl的正是因为谷歌日益增加的内部需求而构建来的。但是其实谷歌自身的产品包括Chrome/Chromium、Android都使用了Boringssl库。

    Boringssl具备谷歌很多创新和紧扣技术发展的新的更新。印象中它好像是最早引入Quic库的。因此个人建议是:该用则用,背靠大树好乘凉!

    Libressl

    LibreSSL是OpenSSL加密软件库的一个分支,为一个安全套接层(SSL)和传输层安全(TLS)协议的开源实现。在OpenSSL爆出心脏出血安全漏洞之后,一些OpenBSD开发者于2014年4月创立了LibreSSL,目标是重构OpenSSL的代码,以提供一个更安全的替代品。LibreSSL复刻自OpenSSL库的1.0.1g分支,它将遵循其他OpenBSD项目所使用的安全指导原则。

    从以上官方的介绍我们可以看到libressl是从安全角度重构的一个ssl库。LibreSSL 是由 OpenBSD 项目开发的 OpenSSL 1.0.1g 的一个分支。目标是对代码库进行现代化改造, 提高安全性,并应用 OpenBSD 的最佳实践开发流程。

    LibreSSL 提供了大部分 OpenSSL 1.1 API。OpenSSL 3 API 当前没有 支持。项目之间存在不兼容性,并且由于 两者都以不同的目标和优先事项发展。重要的不兼容性将 如果可能的话,只要它们对 LibreSSL 的不太有害,就可以解决 简单、安全和理智的目标。我们不会添加新功能、密码和 没有充分理由的 API,并要求新代码干净且高质量。
    Libressl不保证兼容openssl的API和ABI。当然毕竟都复刻修改的分支,陈旧的openssl确实也需要持续进步和发展了。

    Libressl提供相当高的稳定性和移植兼容性虽然主要是在 OpenBSD 上开发并利用 API 的, LibreSSL 可移植项目试图为 其他操作系统,并协助改进操作系统原生实现 在可能的情况下。

    在撰写本文时,已知 LibreSSL 正在构建和工作:

    Linux(推荐内核 3.17 或更高版本)
    FreeBSD (在 9.2 及更高版本中测试)
    NetBSD(推荐使用 7.0 或更高版本)
    惠普-UX (11i)
    Solaris 11 及更高版本
    Mac OS X(在 10.8 及更高版本上测试)
    AIX(5.3 及更高版本)
    LibreSSL 还支持以下 Windows 环境:

    Microsoft Windows(Windows 7 / Windows Server 2008R2 或更高版本,x86 和 x64)
    Wine(32 位和 64 位)
    Mingw-w64、Cygwin 和 Visual Studio。

    个人建议:系统集成级别的安全性和开发流程,稳定的开发流程。可以放心的使用,但是在一些特别前沿的开发可能会略晚。毕竟谷歌有钱有人嘛!

    QuicTLS

    QuicTLS是另一个Openssl分支,此分支添加了 QUIC 实现可用于连接的 API 握手。引用 IETF 工作组章程,QUIC 是一个“基于 UDP、 流多路复用,加密传输协议。这里的 API 由 Microsoft 的 MsQuic 和 Google 的 Chromium QUIC 提供。因此我们可以看出QuicTLS单纯就是openssl+quic API支持。因此我们认为应该只在需要Quic的时候使用,其他时候官方也建议直接使用Openssl.个人建议:需要保持相对纯净的QUIC需求的可以使用。这家背是 Akamai 和 Microsoft。

    总结:

    三者都可以使用,需要一些新功能和看好谷歌的直接选择Broingssl,需要系统级稳定性的选择Libressl。

    参考:

    https://github.com/google/boringssl

    https://github.com/libressl/portable

    https://github.com/quictls/openssl

  • Nginx发布新的稳定版本Nginx-1.26.0

    Nginx发布新的稳定版本Nginx-1.26.0

    Nginx社区于2024-04-23发布了新的稳定版本nginx-1.26.0.新版本带来1.25.x上的一些新的更新内容:

    实验性的HTTP/3的支持

    新的HTTP/2针对单独Server的设置

    流模块中的虚拟服务器、将流连接传递到侦听套接字等.

    https://nginx.org/en/CHANGES-1.26

  • 将 Cloudflare 连接到互联网的代理——Pingora 的构建方式

    将 Cloudflare 连接到互联网的代理——Pingora 的构建方式

    Cloudflare 博客

    将 Cloudflare 连接到互联网的代理——Pingora 的构建方式

    2022/09/14

    简介

    今天,我们很高兴有机会在此介绍 Pingora,这是我们使用 Rust 在内部构建的新 HTTP 代理,它每天处理超过 1 万亿个请求,提高了我们的性能,并为 Cloudflare 客户带来了许多新功能,同时只需要我们以前代理基础架构的三分之一的 CPU 和内存资源。

    随着 Cloudflare 规模的扩大,我们已经超越了 NGINX 的处理能力。多年来它一直运作良好,但随着时间的推移,它在我们规模上的局限性意味着我们有必要构建一些新的东西。我们无法再获得我们所需要的性能,NGINX 也没有我们在非常复杂的环境中所需要的功能。

    许多 Cloudflare 客户和用户使用 Cloudflare 全球网络作为 HTTP 客户端(例如 Web 浏览器、应用程序、物联网设备等)和服务器之间的代理。过去,对于浏览器和其他用户代理如何连接到我们的网络,我们已进行过许多讨论,我们开发了很多技术并实施了新协议(参见 QUIC 和 http2 优化)来使这段连接更高效。

    今天,我们将关注这个等式的另一部分:代理我们的网络和互联网上服务器之间的流量的服务。这个代理服务为我们的 CDN、Workers fetch、Tunnel、Stream、R2 以及许多其他功能和产品提供了动力。

    让我们研究为什么我们选择取代我们的旧版服务以及 Pingora 的开发过程,这是我们专门为 Cloudflare 的客户用例和规模而设计的新系统。

    为什么要再建一个代理

    这些年来,我们对 NGINX 的使用遇到了限制。对于部分限制,我们进行了优化或选择绕过它们。但另一些限制则更难克服。

    架构的限制损害了性能

    NGINX worker(进程)架构对于我们的用例而言存在操作缺陷,这会损害我们的性能和效率。

    首先,在 NGINX 中,每个请求只能由单个 worker 处理。这会导致所有 CPU 内核之间的负载不平衡,从而导致速度变慢

    由于这种请求进程锁定效应,执行 CPU 繁重阻止 IO 任务的请求可能会减慢其他请求的速度。正如这些博客文章所表明的那样,我们已经花了很多时间来解决这些问题。

    对于我们的用例来说,最关键的问题是糟糕的连接重用。我们的机器与原始服务器建立 TCP 连接,以代理 HTTP 请求。连接重用通过重用之前从连接池建立的连接,跳过新连接所需的 TCP 和 TLS 握手,来加快请求的 TTFB(首字节时间)。

    但是,NGINX 连接池与单个 worker 相对应。当请求到达某个 worker 时,它只能重用该 worker 内的连接。当我们添加更多 NGINX worker 以进行扩展时,我们的连接重用率会变得更差,因为连接分散在所有进程的更多孤立的池中。这导致更慢的 TTFB 以及需要维护更多连接,进而消耗我们和客户的资源(和金钱)。

    正如在过去的博客文章中所提到的,我们为其中一些问题提供了解决方法。但如果我们能够解决根本问题:worker/进程模型,我们将自然而然地解决所有这些问题。

    有些类型的功能难以添加

    NGINX 是一个非常好的 Web 服务器、负载均衡器或简单的网关。但 Cloudflare 的作用远不止于此。我们过去常常围绕 NGINX 构建我们需要的所有功能,但要尽量避免与 NGINX 上游代码库有太多分歧,这并不容易。

    例如,当重试请求/请求失败时,有时我们希望将请求发送到具有不同请求标头集的不同源服务器。但 NGINX 并不允许执行此操作。在这种情况下,我们需要花费时间和精力来解决 NGINX 的限制。

    同时,我们被迫使用的编程语言并没有帮助缓解这些困难。NGINX 纯粹是用 C 语言编写的,这在设计上不是内存安全的。使用这样的第 3 方代码库非常容易出错。即使对于经验丰富的工程师来说,也很容易陷入内存安全问题,我们希望尽可能避免这些问题。

    我们用来补充 C 语言的另一种语言是 Lua。它的风险较小,但性能也较差。此外,在处理复杂的 Lua 代码和业务逻辑时,我们经常发现自己缺少静态类型

    而且 NGINX 社区也不是很活跃,开发往往是“闭门造车”

    选择建立我们自己的

    在过去的几年里,随着我们的客户群和功能集的持续增长,我们持续评估了三种选择:

    1. 继续投资 NGINX,向其付款进行定制,使其 100% 满足我们的需求。我们拥有所需的专业知识,但鉴于上述架构限制,需要付出大量努力才能以完全支持我们需求的方式重建它。
    2. 迁移到另一个第三方代理代码库。肯定有好的项目,比如 envoy 和其他一些。但这条道路意味着在几年内可能会重复同样的循环。
    3. 从头开始建立一个内部平台和框架。这一选择需要在工程方面进行最大的前期投资。

    在过去的几年中,我们每个季度都会对这些选项进行评估。没有明显的公式来判断哪种选择是最好的。在几年的时间里,我们继续走阻力最小的道路,继续增强 NGINX。然而,在某些情况下,建立自有代理的投资回报率似乎更值得。我们呼吁从头开始建立一个代理,并开始设计我们梦想中的代理应用程序。

    Pingora 项目

    设计决定

    为了打造一个每秒提供数百万次请求且快速、高效和安全的代理,我们必须首先做出一些重要的设计决定。

    我们选择 Rust 作为项目的语言,因为它可以在不影响性能的情况下以内存安全的方式完成 C 语言可以做的事情。

    尽管有一些很棒的现成第 3 方 HTTP 库,例如 hyper,我们选择构建自己的库是因为我们希望最大限度地提高处理 HTTP 流量的灵活性,并确保我们可以按照自己的节奏进行创新。

    在 Cloudflare,我们处理整个互联网的流量。我们必须支持许多奇怪且不符合 RFC 的 HTTP 流量案例。这是 HTTP 社区和 Web 中的一个常见困境,在严格遵循 HTTP 规范,和适应潜在遗留客户端或服务器的广泛生态系统的细微差别之间存在矛盾和冲突,需要在其中作出艰难抉择。

    HTTP 状态码在 RFC 9110 中定义为一个三位整数,通常预期在 100 到 599 的范围内。Hyper 就是这样一种实现。但是,许多服务器支持使用 599 到 999 之间的状态代码。我们为此功能创建了一个问题,探讨了争论的各个方面。虽然 hyper 团队最终确实接受了这一更改,但他们有充分的理由拒绝这样的要求,而这只是我们需要支持的众多不合规行为案例之一。

    为了满足 Cloudflare 在 HTTP 生态系统中的地位要求,我们需要一个稳健、宽容、可定制的 HTTP 库,该库可以在互联网的各种风险环境中生存,并支持各种不合规的用例。保证这一点的最佳方法就是实施我们自己的架构。

    下一个设计决策关于我们的工作负载调度系统。我们选择多线程而不是多处理,以便轻松共享资源,尤其是连接池。我们认为还需要实施工作窃取来避免上面提到的某些类别的性能问题。Tokio 异步运行时结果非常适合我们的需求。

    最后,我们希望我们的项目直观且对开发人员友好。我们构建的不是最终产品,而是应该可以作为一个平台进行扩展,因为在它之上构建了更多的功能。我们决定实施一个类似于 NGINX/OpenResty 的基于“请求生命周期”事件的可编程接口。例如,“请求过滤器”阶段允许开发人员在收到请求标头时运行代码来修改或拒绝请求。通过这种设计,我们可以清晰地分离我们的业务逻辑和通用代理逻辑。之前从事 NGINX 工作的开发人员可以轻松切换到 Pingora 并迅速提高工作效率。

    Pingora 在生产中更快

    让我们快进到现在。Pingora 处理几乎所有需要与源服务器交互的 HTTP 请求(例如缓存未命中),我们在此过程中收集了很多性能数据。

    首先,让我们看看 Pingora 如何加快我们客户的流量。Pingora 上的总体流量显示,TTFB 中位数减少了 5 毫秒,第 95 个百分位数减少了 80 毫秒。这不是因为我们运行代码更快。甚至我们的旧服务也可以处理亚毫秒范围内的请求。

    时间节省来自我们的新架构,它可以跨所有线程共享连接。这意味着更好的连接重用率,在 TCP 和 TLS 握手上花费的时间更少。

    在所有客户中,与旧服务相比,Pingora 每秒的新连接数只有三分之一。对于一个主要客户,它将连接重用率从 87.1% 提高到 99.92%,这将新连接减少了 160 倍。更直观地说,通过切换到 Pingora,我们每天为客户和用户节省了 434 年的握手时间。

    更多功能

    拥有工程师熟悉的开发人员友好界面,同时消除以前的限制,让我们能够更快地开发更多功能。像新协议这样的核心功能充当我们为客户提供更多产品的基石。

    例如,我们能够在没有重大障碍的情况下向 Pingora 添加 HTTP/2 上游支持。这使我们能够在不久之后向我们的客户提供 gRPC。将相同的功能添加到 NGINX 将需要更多的工程工作,并且可能无法实现

    最近,我们宣布推出了 Cache Reserve,其中 Pingora 使用 R2 存储作为缓存层。随着我们向 Pingora 添加更多功能,我们能够提供以前不可行的新产品。

    更高效

    在生产环境中,与我们的旧服务相比,Pingora 在相同流量负载的情况下,消耗的 CPU 和内存减少了约 70% 和 67%。节省来自几个因素。

    与旧的 Lua 代码相比,我们的 Rust 代码运行效率更高。最重要的是,它们的架构也存在效率差异。例如,在 NGINX/OpenResty 中,当 Lua 代码想要访问 HTTP 头时,它必须从 NGINX C 结构中读取它,分配一个 Lua 字符串,然后将其复制到 Lua 字符串中。之后,Lua 还对其新字符串进行垃圾回收。在 Pingora 中,它只是一个直接的字符串访问。

    多线程模型还使得跨请求共享数据更加高效。NGINX 也有共享内存,但由于实施限制,每次共享内存访问都必须使用互斥锁,并且只能将字符串和数字放入共享内存。在 Pingora 中,大多数共享项目可以通过原子引用计数器后面的共享引用直接访问。

    如上所述,CPU 节省的另一个重要部分是减少了新的连接。与仅通过已建立的连接发送和接收数据相比,TLS 握手成本显然更为高昂。

    更安全

    在我们这样的规模下,快速安全地发布功能十分困难。很难预测在每秒处理数百万个请求的分布式环境中可能发生的每个边缘情况。模糊测试和静态分析只能缓解这么多。Rust 的内存安全语义保护我们免受未定义行为的影响,并让我们相信我们的服务将正确运行。

    有了这些保证,我们可以更多地关注我们的服务更改将如何与其他服务或客户来源进行交互。我们能够以更高的节奏开发功能,而不用背负内存安全和难以诊断崩溃的问题。

    当崩溃确实发生时,工程师需要花时间来诊断它是如何发生的以及是什么原因造成的。自 Pingora 创立以来,我们已经处理了数百万亿个请求,至今尚未因为我们的服务代码而崩溃。

    事实上,Pingora 崩溃是如此罕见,当我们遇到一个问题时,我们通常会发现不相关的问题。最近,我们的服务开始崩溃后不久,我们发现了一个内核错误。我们还在一些机器上发现了硬件问题,过去排除了由我们的软件引起的罕见内存错误,即使在几乎不可能进行重大调试之后也是如此。

    总结

    总而言之,我们已经建立了一个更快、更高效、更通用的内部代理,作为我们当前和未来产品的平台。

    我们之后将介绍有关我们面临的问题和应用优化的更多技术细节,以及我们从构建 Pingora 并将其推出以支持互联网的重要部分的经验教训。同时还将介绍我们的开源计划。

    Pingora 是我们重写系统的最新尝试,但它不会是我们的最后一次。它也只是我们系统重新架构的基石之一。有兴趣加入我们,帮助建立一个更好的互联网?

  • Angie–Nginx的俄罗斯本土分支

    Angie–Nginx的俄罗斯本土分支

    Angie 是 NGINX Web 服务器的代替品,旨在扩展原始版本的功能。

    让我们从一些背景开始。NGINX 股份有限公司由 NGINX 的原始作者 Igor Sysoev 和 Maxim Konovalov 于 2011 年 7 月成立,旨在为该软件提供商业产品和支持。它是 F5 Networks Inc. 的一部分,F5 Networks Inc.于2019年3月斥资6.7亿美元收购了它,以帮助它们从一家硬件公司发展成为一家更专注于服务的公司。今年 8 月,拥有 NGINX 版权并负责其开发的 F5 Networks Inc. 停止了在俄罗斯的业务,完全退出了市场。几乎所有俄罗斯办公室的开发商都接受了搬迁到加利福尼亚州圣何塞的提议。

    然而,事情似乎发生了变化。一些 NGINX 的首席工程师已经回来了,因此,一家新公司 Web Server LLC 已经成立,其旗舰产品是 Angie Web Server。所以,让我们看看我们目前对它的了解。Angie 是 NGINX 的一个分支,旨在扩展远超原始版本的功能。它可以用作 NGINX 的替代品,因此您可以使用现有的 NGINX 配置而无需进行重大更改。

    可供安装的初始稳定版本是 Angie 1.0.0。该软件在 BSD 2-Clause “Simplified”许可下分发,可在项目的 GitHub 页面上免费获得。该许可证允许 Angie 在商业上免费、修改、分发和私人使用。Angie Web 服务器包括以下内置模块:http_addition_module http_auth_request_module http_dav_module http_flv_module http_gunzip_module http_gzip_static_module http_mp4_module http_random_index_module http_realip_module http_secure_link_module http_slice_module http_ssl_module http_stub_status_module http_sub_module http_v2_module mailmail_ssl_module streamstream_realip_module stream_ssl_module stream_ssl_preread_module

    此外,用户还可以在项目的 GitHub 存储库中找到以下动态模块:angie-module-geoipangie-module-geoip2angie-module-njs目前,Angie Web 服务器目前只能安装在两个 Linux 发行版上:Ubuntu 和 Debian。更具体地说,是 Debian 10 (Buster)、Debian 11 (Bullseye)、Ubuntu 20.04 LTS (Focal Fossa) 和 Ubuntu 22.04 LTS (Jammy Jellyfish)。

    该项目的 GitHub 存储库正在积极开发中;因此,受支持的 Linux 发行版列表预计会大幅度增长。最后,我们要指出的是,NGINX 的原作者 Igor Sysoev 没有参与这两个项目。他于今年 1 月正式离开 F5 Networks Inc.,专注于个人项目并享受与家人和朋友在一起的快乐时光。您可以从项目页面获取有关 Angie Web 服务器的更多信息。

    Angie官方网站:https://angie.software/en/

  • FreeNginx的前世今生

    FreeNginx的前世今生

    Freenginx Web服务器致力于重现开源开发“造福公众”的精神,摆脱企业控制。

    译自Freenginx: A Fork of Nginx,作者 Steven J. Vaughan-Nichols 也称为 sjvn,自从 CP/M-80 成为尖端的 PC 操作系统,300bps 成为快速的互联网连接,WordStar 成为最先进的文字处理器以来,他就一直撰写有关技术和技术业务的文章,而我们也很享受这一切。

    一名志愿的 Nginx 开发者正在把Nginx(发音为 EngineX,是世界上最流行的 Web 服务器分叉为 Freenginx。

    根据Netcraft的统计,Nginx 是世界上最受欢迎的 Web 服务器。因此,当 Nginx 的顶级开发者 MaximDounin宣布他要分支 Nginx时,这可能是一个巨大的举动。

    Dounin 做出这个决定是因为他对 Nginx 的企业所有者F5在项目管理方面的过度干预感到不满。具体来说,他讨厌管理层在安全策略方面所做的事情,以及他们现在如何在 Nginx 的实验性 HTTP/3 代码中分配常见漏洞和披露(CVE)错误。

    正如 Dounin 写的:”F5 的一些新的非技术管理人员最近决定他们更了解如何运行开源项目。特别是,他们决定干预 Nginx 多年来使用的安全策略,无视策略和开发者的立场。” 具体来说,Douin 反对将这些错误视为安全问题,而是将其视为普通错误,这并不值得进行安全公布。

    然而,与其说是这个具体问题,不如说是 F5 的态度,正如他在另一个说明中解释的那样。”并没有公开讨论。我所知道的唯一讨论发生在 security-alert@ 邮件列表中,共识是该错误应该作为普通错误进行修复。尽管如此,我还是在几天前收到信息,说一些无名的管理层不管政策和开发者的立场,坚持要求发布安全公告和安全版本。”

    被忽视的高级程序员就是火气很大的程序员。

    根据他自己的说法,自从 F5 公司因入侵乌克兰而在 2022 年退出俄罗斯以来,Dounin 就不再是 F5 的员工。相反,在过去两年中,他一直是重要的志愿贡献者。

    现在,他觉得虽然由于“我不再能够控制 F5 内的 Nginx 更改,也不再将 nginx 视为为公共利益开发和维护的自由开源项目”,F5 有权随意处置这个项目,但他不会再为 Nginx 工作。相反,他将为Freenginx工作,“这是一个替代项目,它将由开发者而不是企业实体来运行。”

    正因如此,Dounin 没有加入之前的开源 Nginx 分支Angie。这个程序是由在 F5 退出莫斯科后遭遇困境的俄罗斯 Nginx 开发者创建的。Angie 属于俄罗斯公司 Web Server,Dounin 担心任何营利公司都可能干扰代码的适当开发和维护。

    这一发展的背景复杂,涉及地缘政治紧张局势、企业收购以及在商业利益与开源理念之间寻求平衡的固有挑战。Nginx 的历史一直很动荡。F5 在 2019 年收购 Nginx被视为一个带来财务稳定和增长的新篇章。然而,随后俄罗斯国家代理人代表俄罗斯网络公司 Rambler 突袭 Nginx 在莫斯科的办公室,声称拥有 Nginx 代码的所有权,这使该公司陷入困境。F5 关闭莫斯科办事处只增加了叙述的复杂性。

    Dounin 的新创业 Freenginx 旨在重拾开源开发的精神,“为公共利益”服务,摆脱企业控制。Freenginx 的第一个代码版本freenginx-1.25.4已于 2024 年 2 月 20 日发布。这是一个旧代码库的克隆,只做了几项较小的更改。其中一项是修复导致分叉的错误。

    那么 F5 对此作何反应呢?一位公司代表说:“F5 致力于提供成功的开源项目,这需要大量不同的贡献者社区,以及运用严格的行业标准来分配和评分已识别的漏洞。我们认为这是为客户和社区开发高度安全软件的正确方法,我们鼓励开源社区加入我们的努力。” 在我看来,他们对这个分支并不担心。

    因此,至少就目前而言,Dounin 似乎可以自由地尝试在无干扰的情况下获得网络服务器的关注度。但是,根据 Freenginx 邮件列表中的低活跃度,似乎兴趣不大,但只有时间才能告诉我们这个项目是否会在用户或开发者中获得热度。

  • Nginx的非商业运营社区分支–Freenginx

    Nginx的非商业运营社区分支–Freenginx

    核心 Nginx 开发者创建新分支 Freenginx:引领 Web 服务器性能与安全性新篇章

    一、引言

    近日,核心 Nginx 开发者 Igor Sysoev 宣布创建了一个名为 Freenginx 的新分支。这一举措旨在进一步提高 Nginx Web 服务器的性能和安全性,满足日益增长的网络需求。本文将详细介绍 Freenginx 的背景、目标以及潜在影响。

    二、背景介绍

    Nginx 是一款高性能、高并发的 Web 服务器和反向代理服务器,广泛应用于互联网和企业内部网络。自 2004 年首次发布以来,Nginx 已经成为全球最受欢迎的 Web 服务器之一,市场份额远超其他竞争对手。

    Igor Sysoev 是 Nginx 的核心开发者之一,他长期致力于优化 Nginx 的性能和安全性。此次创建 Freenginx 分支,是他对 Nginx 未来发展方向的又一重要探索。

    三、Freenginx 的目标

    Freenginx 分支的主要目标是进一步提升 Nginx 的性能和安全性,以满足以下需求:

    1. 高并发场景下的性能优化:随着互联网用户数量的不断增长,Web 服务器需要应对更高的并发连接数。Freenginx 将通过优化内核参数、改进事件处理机制等方式,提高 Nginx 在高并发场景下的性能表现。

    2. 安全性增强:网络安全是当今互联网领域的重要议题。Freenginx 将引入新的安全特性,如更好的 DDoS 防护、更严格的访问控制等,以提高 Nginx 的安全性。

    3. 模块化和可定制性:为了满足不同用户的个性化需求,Freenginx 将提供更加模块化和可定制的解决方案。这将允许开发者在 Freenginx 基础上构建定制化的 Web 服务器,以满足特定应用场景的需求。

    四、潜在影响

    Freenginx 分支的创建将对 Nginx 社区和整个 Web 服务器市场产生深远影响

    1. 促进 Nginx 社区的发展:Freenginx 将吸引更多开发者参与到 Nginx 的开发和维护工作中,进一步推动 Nginx 社区的发展和壮大。

    2. 提升 Nginx 的竞争力:凭借卓越的性能和安全性,Freenginx 有望巩固 Nginx 在 Web 服务器市场的领先地位,甚至吸引更多原本使用其他 Web 服务器的用户转向 Nginx。

    3. 推动 Web 服务器技术的进步:Freenginx 的探索和尝试将为整个 Web 服务器行业带来新的启示和技术创新,推动整个行业的发展和进步。

    五、结语

    核心 Nginx 开发者 Igor Sysoev 创建 Freenginx 分支,预示着 Nginx 将迎来性能和安全性方面的全面提升。我们期待 Freenginx 能够引领 Web 服务器技术的新篇章,为全球互联网用户提供更加高效、安全和可靠的 Web 服务。

    FreeNginx官网:https://freenginx.org/

    FreeNginx源码:http://freenginx.org/hg/nginx

  • Rocky Linux和Alma Linux发布9.0版本

    Rocky Linux和Alma Linux发布9.0版本

    Rocky Linux 9.0 现已推出

    我们很高兴地宣布 Rocky Linux 9.0 全面上市。Rocky Linux 文档中提供了发行说明- 这些说明包含重要信息,包括已知错误和有关此版本更改的全面详细信息。

    下载

    Rocky Linux 9.0 可以在 x86_64、aarch64、ppc64le 和 s390x 架构的下载页面上下载。

    云图像列在“云图像”页面上。

    支持

    • Rocky Linux 9 将被支持到 2032 年 5 月 31 日。
    • Rocky Linux 8 将继续受支持,直到 2029 年 5 月 31 日。

    各种商业支持提供商都提供对 Rocky Linux 的扩展支持。

    强调

    桌面

    Rocky Linux 9 附带 GNOME 40 作为默认桌面环境。重新设计的核心应用程序、设置和 UI 使得使用 Rocky Linux 作为桌面操作系统变得前所未有的容易。在工作、启动应用程序和安排您的个人工作区时,活动的外观和感觉提供了更好的体验。

    桌面使用的其他显着改进包括:

    • 通过右键单击并选择适当的选项,软件可以在单独的显卡上运行
    • 可以通过选择请勿打扰来静音通知,这将在通知中显示为单独的按钮
    • 每个屏幕可以使用不同的刷新率
    • 活动程序允许您使用拖放方法将应用程序图标分组到文件夹中
    • 分数显示缩放

    文件系统

    XFS 现在支持直接访问 (DAX) 操作,允许直接访问字节可寻址的持久内存,有助于避免使用传统块 I/O 约定的延迟。NFS 引入了“eager write”挂载选项来帮助减少延迟。

    语言运行时和工具

    Rocky Linux 9 拥有许多最新的运行时和编译器,包括 GCC 11.2.1、LLVM (13.0.1)、Rust (1.58.1) 和 Go (1.17.1)。

    Rocky Linux 9 更新了开发人员工具链的版本,包括 GCC (11.2.1)、glibc (2.34) 和 binutils (2.35)。GCC 编译器中的新功能通过改进的调试选项帮助开发人员更好地跟踪代码流,并编写优化的代码以有效地使用硬件。

    Rocky Linux 9 扩展了 Rocky Linux 8 中可用的模块打包功能。所有打包方法,例如 Software Collections、Flatpaks 和 RPM,都已合并到应用程序流中,使开发人员更容易使用他们喜欢的包。

    • Rocky Linux 9 的整个生命周期都将支持Python 3.9,并带有许多新功能,包括时区感知时间戳、新的字符串前缀和后缀方法、字典联合操作、高性能解析器、多处理改进。
    • Node.js 16包括将 V8 引擎升级到 9.2 版、新的 Timer Promises API、新的 Web 流 API 以及对 npm 包管理器 7.20.3 版的支持。Node.js 现在与 OpenSSL 3.0 兼容。
    • Ruby 3.0.3提供了多项性能改进,以及错误和安全修复。重要的改进包括并发性和并行性、静态分析、与 case/in 表达式的模式匹配、重新设计的单行模式匹配和查找模式匹配。
    • Perl 5.32提供了错误修复和增强功能,包括 Unicode 版本 13、新的实验性中缀运算符和更快的功能检查。
    • PHP 8.0提供了错误修复和增强功能,包括使用结构化元数据语法、新命名的与顺序无关的参数以及改进的即时编译性能。

    安全

    默认情况下,已禁用通过 SSH 使用密码进行的根用户身份验证。OpenSSH 默认配置不允许 root 用户使用密码登录,从而防止攻击者通过暴力密码攻击获得访问权限。用户可以使用 SSH 密钥登录来访问远程系统,而不是使用 root 密码。

    OpenSSL 3.0 添加了提供程序概念、新版本控制方案和改进的 HTTPS。内置实用程序已重新编译以利用 OpenSSL 3。OpenSSL 3.0 的新 FIPS 模块可防止使用非 FIPS 算法,同时可以在内核中设置 FIPS 标志,而无需将 OpenSSL 切换到 FIPS 模式。

    系统监控

    Cockpit Web 控制台具有改进的性能指标页面,可帮助确定 CPU、内存、磁盘和网络资源使用高峰的原因。

    AlmaLinux 9 现已推出!

    你好社区!AlmaLinux OS 基金会自豪地宣布AlmaLinux OS 9.0全面上市。AlmaLinux 9 支持以下 4 种架构,与上游完全对等:

    ISO、实时图像、云和容器

    安装 ISO 很好,但 AlmaLinux 已经为您提供更多内容。我们已开始更新以下图片,这些图片将很快推出:

    发行说明和更多信息

    AlmaLinux OS 9.0 基于上游内核版本 5.14,包含围绕云和容器开发的增强功能以​​及对 Web 控制台(驾驶舱)的改进。此版本还增强了安全性和合规性,包括额外的安全配置文件、大大改进的 SELinux 性能和用户身份验证日志。其他各种更新包括 Python 3.9、GCC 11 和最新版本的 LLVM、Rust 和 Go 编译器,以使应用程序的现代化更快、更容易。您可以通过查看发行说明了解更多信息。

    视觉增强

    我们知道你们中的一些人会很高兴看到此版本中提供了一些新壁纸。我们还保留了 AlmaLinux 8 的标准版本,以适应任何心情 🙂

    投入

    AlmaLinux 在去年取得了如此多的成就,还有更多工作要做。加入我们的社区。成为基金会成员(完全免费)并声明您的投票权。给我们您的反馈并成为魔术的一部分。

    加入我们的AlmaLinux 社区聊天以获得您需要的任何帮助并帮助他人。您还可以在我们的9.0 论坛、 Reddit上的 AlmaLinux 社区或Twitter上发布问题。

    请报告您在错误跟踪器上看到的任何错误。

    玩得开心,敬请期待更多精彩的公告和有用的工具即将推出。

    谢谢你

    AlmaLinux 操作系统基金会要感谢所有参与 CentOS Stream 9 工作的人、CentOS SIG 和其他使这个版本成为可能的人。感谢 Fedora 和 RHEL 团队,以及各地的上游项目和贡献者。你摇滚!

  • Fedora Linux 36发布

    Fedora Linux 36发布

    Fedora 36今天发布,这是最近一段时间以来又一个强大、前沿而又稳定可靠的Linux发行版本,除了这些特点外,Fedora 35还在原先的基础上增加了新的功能和细节打磨。Fedora 36使用GNOME 42作为其默认的Fedora工作站桌面环境。

    OpenSSL 3.0,Linux 5.17内核是当前使用的版本,Mesa 22.0用于开源图形驱动,当使用NVIDIA专有驱动栈时,Wayland会话会自动成为默认,而不是X.Org,与此同时Google Noto字体现在被作为默认字体集使用。

    对于开发者,Fedora 36提供了全新的GCC 12编译器栈。还有Autoconf 2.71, Glibc 2.35, LLVM 14, Ruby 3.1, Ruby on Rails 7.0, PHP 8.1, 以及其他更新的软件包。OpenJDK 17 在 Fedora 36 上提供了更新的默认 Java 环境。还有其他一些可能感兴趣的软件包更新,比如Ansible 5, Django 4.0, LXQt 1.0, PostgreSQL 14, 和Stratis 3.0。

    除了使用最新的Linux内核和Mesa图形驱动,以及默认使用Wayland作为NVIDIA专有驱动堆栈外,这个版本还有一个值得注意的底层图形变化。Fedora 36现在使用SimpleDRM和DRM FBDEV仿真代码来取代传统的FBDEV驱动,这是又一个现代化改造。

    Fedora 36将于今天在GetFedora.org提供下载。

  • CentOS Stream 9发布

    CentOS Stream 9发布

    随着新的Fedora35发布,RH也终于发布了大家都曾经不待见的CentOS Stream9,大家也许都转到Alma Linux或者Rocky Linux。新的版本大家还是一起体验一下吧!

    SOPackagesOthers
    x86_64RPMsCloud | Containers

  • Fedora 35正式发布

    Fedora 35正式发布

    Fedora 35正式发布,版本如下:

    对于 x86_64:

    • Fedora 35:x86_64 DVD ISO下载

    对于 ARM ® aarch64:

    • Fedora 35:aarch64 DVD ISO下载
    • Fedora 35:aarch64 原始图像下载

    新的版本期待新的功能!

  • Debian 11– bullseye 正式发布

    Debian 11– bullseye 正式发布

    Debian社区于2021年8月14日正式发布了代号为bullseys的Debian11 新版本。同时我们也看到了新启动的下一代测试版本,代号为bookworm

    桌面版新软件包括:

    • Gnome 3.38,
    • KDE Plasma 5.20,
    • LXDE 11,
    • LXQt 0.16,
    • MATE 1.24,
    • Xfce 4.16.

    包含最新版的程序包括:

    • Apache 2.4.48
    • BIND DNS Server 9.16
    • Calligra 3.2
    • Cryptsetup 2.3
    • Emacs 27.1
    • GIMP 2.10.22
    • GNU Compiler Collection 10.2
    • GnuPG 2.2.20
    • Inkscape 1.0.2
    • LibreOffice 7.0
    • Linux kernel 5.10 series
    • MariaDB 10.5
    • OpenSSH 8.4p1
    • Perl 5.32
    • PHP 7.4
    • PostgreSQL 13
    • Python 3, 3.9.1
    • Rustc 1.48
    • Samba 4.13
    • Vim 8.2