2022年9月

pyp2rpm 使得创建 RPM 包的过程更加自动化。

当你安装一个应用程序时,你通常是在安装一个软件包,其中包含应用程序的可执行代码和重要文件,如文档、图标等。在 Linux上,软件一般被打包成 RPM 或 DEB 等格式,用户只要通过 dnf 或者 apt 等命令就可以进行安装了,这取决于你使用的 Linux 发行版。然而几乎每天都有新的 Python 模块发布,因此你很容易遇到一个尚未打包的 Python 模块。这就是 pyp2rpm 存在的意义了。

最近我在尝试安装一个叫 python-concentration 的模块,但是进展并不太顺利:

$ sudo dnf install python-concentration
Updating Subscription Management repositories.
Last metadata expiration check: 1:23:32 ago on Sat 11 Jun 2022 06:37:25.
No match for argument: python-concentration
Error: Unable to find a match: python-concentration

虽然这是一个发布在 PyPi 的包,但它仍不能被打包成 RPM 包。好消息是你可以使用 pyp2rpm 以一个相对简单的过程将它打包成 RPM 包。

首先你需要设置两个目录:

$ mkdir rpmbuild
$ cd rpmbuild && mkdir SPECS

像这样去安装 pyp2rpm

$ sudo dnf install pyp2rpm

1、生成 spec 文件

RPM 包的基础是一种 spec 文件,这个文件包含你创建这个包的所有信息,如所需的依赖关系、应用的版本号、安装的文件等信息。当指向某个 Python 模块时,pyp2rpm 会为它构建一个 spec 文件,你可以用它来创建 RPM 包。

下面以 python-concentration 为例演示如何构建一个 spec 文件:

$ pyp2rpm concentration > ~/rpmbuild/SPECS/concentration.spec

下面是它生成的文件:

# Created by pyp2rpm-3.3.8
%global pypi_name concentration
%global pypi_version 1.1.5

Name:           python-%{pypi_name}
Version:        %{pypi_version}
Release:        1%{?dist}
Summary:        Get work done when you need to, goof off when you don't

License:        None
URL:            None
Source0:        %{pypi_source}
BuildArch:      noarch

BuildRequires:  python3-devel
BuildRequires:  python3dist(setuptools)

%description
Concentration [![PyPI version]( [![Test Status]( [![Lint Status]( [![codecov](

%package -n     python3-%{pypi_name}
Summary:        %{summary}
%{?python_provide:%python_provide python3-%{pypi_name}}

Requires:       (python3dist(hug) >= 2.6.1 with python3dist(hug) < 3~~)
Requires:       python3dist(setuptools)
%description -n python3-%{pypi_name}
Concentration [![PyPI version]( [![Test Status]( [![Lint Status]( [![codecov](


%prep
%autosetup -n %{pypi_name}-%{pypi_version}

%build
%py3_build

%install
%py3_install

%files -n python3-%{pypi_name}
%license LICENSE
%doc README.md
%{_bindir}/concentration
%{python3_sitelib}/%{pypi_name}
%{python3_sitelib}/%{pypi_name}-%{pypi_version}-py%{python3_version}.egg-info

%changelog
*  - 1.1.5-1
- Initial package.

2、运行 rpmlint

为了确保 spec 文件符合标准,你需要对文件使用 rpmlint 命令:

$ rpmlint ~/rpmbuild/SPEC/concentration.spec
error: bad date in %changelog: - 1.1.5-1
0 packages and 1 specfiles checked; 0 errors, 0 warnings.

看起来更新日志(%changelog)需要记录日期。

%changelog
* Sat Jun 11 2022 Tux <[email protected]> - 1.1.5-1

再次运行 rpmint

$ rpmlint ~/rpmbuild/SPEC/concentration.spec
0 packages and 1 specfiles checked; 0 errors, 0 warnings.

成功!

3、下载源码

你需要下载好打包的代码才能进一步构建 RPM 包。一种简单的方式是解析你的 spec 文件以获取源码的网址。

首先,通过 dnf 安装 spectool

$ sudo dnf install spectool

然后通过 spectool 来下载源码:

$ cd ~/rpmbuild
$ spectool -g -R SPEC/concentration.spec
Downloading: https://files.pythonhosted.org/...concentration-1.1.5.tar.gz
   6.0 KiB / 6.0 KiB    [=====================================]
Downloaded: concentration-1.1.5.tar.gz

这样就创建了一个 SOURCES 目录并将源码放入其中。

4、构建源软件包

现在你已经验证过 spec 文件了,接下来就可以通过 rpmbuild 构建源软件包了。如果你还没有安装 rpmbuild,你也可以通过 dnf 安装 rpm-build 包(或者在使用 rpmbuild 命令时根据终端的的提示进行安装)。

参数 -bs 表示构建源软件包。添加这个参数会产生一个 src.rpm 文件,这是一个用于为特定架构重新构建的通用包:

$ rpmbuild -bs SPECS/concentration.spec
Wrote: ~/rpmbuild/SRPMS/python-concentration-1.1.5-1.el9.src.rpm

为你的系统构建一个可安装的 RPM 文件:

$ rpmbuild –rebuild SRPMS/python-concentration-1.1.5-1.el9.src.rpm
error: Failed build dependencies:
        python3-devel is needed by python-concentration-1.1.5-1.el9.noarch

看起来这个包需要安装 Python 的开发库才能继续构建。安装它们以继续构建。这一次,构建成功了,并且渲染了更多的输出(为了清楚起见,我在这里简略了输出):

$ sudo dnf install python3-devel -y
$ rpmbuild –rebuild SRPMS/python-concentration-1.1.5-1.el9.src.rpm
[...]
Executing(--clean): /bin/sh -e /var/tmp/rpm-tmp.TYA7l2
+ umask 022
+ cd /home/bogus/rpmbuild/BUILD
+ rm -rf concentration-1.1.5
+ RPM_EC=0
++ jobs -p
+ exit 0

你的 RPM 包现在已经构建在 RPMS 子目录下,像平常一样使用 dnf 安装它。

$ sudo dnf install RPMS/noarch/python3-concentration*rpm

为什么不使用 PyPi?

通常情况下我们并不需要将 Python 模块打包成 RPM 包。通过 PyPi 来安装模块也是可以接受的,但是 PyPi 会安装额外的包管理器对你的模块进行检查和更新。当你使用 dnf 来安装 RPM 包时,你在安装完成时就能够获取到完整的安装列表。有了 pyp2rpm 之后,这个过程就变得快速、简单且自动化了。


via: https://opensource.com/article/22/6/package-python-module-rpm

作者:Sumantro Mukherjee 选题:lkxed 译者:Return7g 校对:wxy

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

开源贡献者 Hari Rana 表达了他对传统 Linux 软件包格式不再适合现代应用的看法。

传统的 Linux 软件包格式不适合现代应用

图片来源:来自 UnsplashKelli McClintock

我多次遇到用户抱怨 LTS 和稳定版的应用软件包有问题,但又声称开发版从来没有发生过这种事情。然而,以我在软件包技术方面的经验和知识,我不能不强调,这是不对的。

发行模式不是问题的根源所在,根本的问题是传统的软件包格式不适合现代的图形应用,不管是什么发行版。那么像 Nix 和 Flatpak 这样的格式是如何解决这些基本问题的?有趣的是,大多数服务器确实利用了容器化(即 Docker),因为它提高了可重复性并增强了可维护性。我们可以从中得到启发,采用一个适用于 Linux 桌面的类似标准。

免责声明

  1. “传统软件包”是指使用包管理器发布的图形应用程序,而不使用容器,如 aptdnfpacman 等。
  2. “发行模式”是指发行过程,如长期支持版(LTS)、稳定版和开发版等。
  3. “类似的应用程序”是指两个在技术上真正相似的应用程序,如 Visual Studio CodeCode - OSS
  4. 在这些例子中,我将使用 Arch Linux 作为参考。然而,这些行为与那些大量采用传统软件包格式的发行版是一致的。
  5. Nix 不使用容器,它也不是一种容器格式。但为了简单起见,我暂时把它称为一种容器格式。

根本问题

图片来源:来自 UnsplashJackson Simmer

大多数(或许不是全部)大量采用传统软件包格式的发行版都有这个共同的问题:它们都没有利用容器或其他方便的方法来分离依赖关系。用通俗的话说,容器是一个盒子,我们可以把东西放在里面,在不影响主系统(主机)的情况下单独使用它们。

容器通常不会影响“盒子”外的任何东西。并且它们是可移植的,因为它们可以安装在其他发行版上,同时提供一致的体验。利用容器的包管理器会将每个软件包安装在不同的容器中,这提供了一个额外的安全层。这给了开发者更多的控制权和灵活性,他们可以决定在软件包内捆绑什么。

传统的软件包格式产生了一些问题,比如依赖性和包的冲突,这些问题通常需要解决,而不同的发行版有不同的解决办法。

依赖性和软件包的冲突

如果我们试图安装 Visual Studio Codevisual-studio-code-bin),而 Code - OSScode) 已经安装在 Arch Linux 上,我们会遇到这个问题:

$ paru -S visual-studio-code-bin
[...]
:: Conflicts found:
    visual-studio-code-bin: code  
:: Conflicting packages will have to be confirmed manually
Aur (1)                     Old Version  New Version  Make Only
aur/visual-studio-code-bin               1.70.1-1     No

这就是所谓的软件包冲突,即两个或多个软件包不能共存。在这种情况下,我们不能同时安装 Visual Studio Code 和 Code - OSS。

当两个应用程序或软件包提供相同的文件,具有相同的名称,并被放置在同一目录下,那么它们实际上是不能共存的,因为这些文件会发生冲突。在这个例子中,Visual Studio Code 和 Code - OSS 都提供了一个名为 code 的文件,它们都被放在 /usr/bin 中。Visual Studio Code 提供的 code 文件用于启动 Visual Studio Code,而 Code - OSS 的 code 文件则用于启动 Code - OSS。 虽然这个例子只展示了 Visual Studio Code 和 Code - OSS,但这种情况经常发生在不同的应用程序、库和其他软件中。

无法选择依赖项

图片来源:来自 UnsplashPriscilla Du Preez

传统软件包格式的最大问题之一是,打包者不能选择依赖项。

例如,如果一个应用程序最近更新,需要依赖版本 1 的程序 A,但发行版只提供了版本 0.9 的程序 A,那么对于升级该应用程序来说就不太理想,因为发行版无法满足要求。这意味着打包者将不得不暂缓打包,直到该发行版发布新的依赖项,或者采用变通的方法。

同样,如果一个应用程序需要依赖 0.8.1 版本的程序 A,但发行版却只提供了 0.9 版本的程序 A,那么这个应用程序就会表现失常,甚至完全不能运行。

带补丁的库和编译配置

为了扩展,一些应用程序需要带补丁的库或额外的编译配置才能正常运行。例如,OBS Studio 需要一个 打了补丁的 FFmpeg 来与 OBS Studio 更好地整合。

在传统的软件包格式下,一次只能安装一个依赖项的变体。如果发行版提供的是未打过补丁的 FFmpeg,那么就没有办法安装打过补丁的 FFmpeg,除非打包者能解决这个问题。如果安装了打过补丁的 FFmpeg,但另一个程序高度依赖未打过补丁的 FFmpeg、打过其他补丁的 FFmpeg、内置或删除了其他功能的 FFmpeg,那么其他程序就会出现 bug。

现代应用程序本质上是脆弱的。依赖关系树中的一个小错误或不一致,就会导致应用程序的 bug,使用户体验恶化,甚至会让人觉得是应用程序的问题,而不是软件包本身的问题,这就会妨碍应用程序的声誉。

变通方法

让我们看看目前开发者用来打包应用程序的变通方法:

  1. 第一种解决方法是在不同的目录中安装依赖库。例如,Electron 是一个巨大的框架,开发者用它来构建应用程序,然后将它们捆绑起来。然而,基于 Electron 的应用程序是不同的,因为它们是建立在不同版本的 Electron 之上的。Discord 捆绑了 Electron 13,而 Element 捆绑了 Electron 19。对于 Arch Linux 上的 Electron 打包,某些目录需要安装在 /opt/APPLICATION_NAME 中,所以这些 Electron 版本 不会相互冲突
  2. 第二种解决方法是篡改应用程序。例如,给应用程序打上补丁,使其在没有某些依赖库或功能的情况下编译,这可以使应用程序成功编译,但不能保证该应用程序能够启动或按预期工作。
  3. 第三种解决方法是在编译应用程序时禁用许多编译选项,这也可能禁用一些功能。例如,在 Arch Linux 上,OBS Studio 在编译时禁用了许多基本功能,这 导致了不合格的体验

这些解决方法因人而异,有些会限制应用程序的功能,有些会引入稳定性问题等等。

不一致的体验

西班牙兰萨罗特岛(加那利群岛)的蒂曼法亚火山国家公园的火山口景观

图片来源:来自 Unsplashalevision.co

虽然这些技术限制在整个传统软件包格式中是一致的,但用户体验往往不是这样。由于软件包的发布方式,发行模式与传统软件包格式相结合会影响用户体验。

一些发行版,如 Arch Linux,接近于开发版,因此有最新版本的软件包。然而 Debian 和 Ubuntu LTS 是 LTS 长期支持版,所以它们的很多软件包都落后几个版本。同时,Fedora Linux 和 Ubuntu 稳定版处于 Debian / Ubuntu LTS 和 Arch Linux 之间。

一些软件包格式喜欢尽可能少地给软件包打补丁,以保持它们最接近原版;而另一些格式打补丁是为了增加更多的功能,使用旧库或进行其他类型的更改,以改善用户体验。一些格式喜欢使软件更加轻量化;而另一些格式更喜欢尽可能地添加更多内置功能。软件包有各种各样的习惯和偏好。

正如我们所看到的,一个应用程序在不同的发行版中的构建方式非常不同。此外,不同的发行版的依赖关系也是不同的。传统软件包格式的许多技术限制需要根据发行模式和打包策略采取不同的解决方法。这些微小的变化往往给用户带来不完整的、不合格的体验和错误的印象。一些应用程序可能在某些发行版上运行得更好,但在其他发行版上运行得很差,而其他一些应用程序则运行得更好。即使一个应用程序在每个发行版上的构建方式不同,但其名称和品牌却保持原样,给用户留下错误的印象。

解决方案

图片来源:来自 UnsplashRiccardo Annandale

如上所述,解决这些问题的方法是使用容器。

容器被设计用来分离系统的几个方面。通过使用容器,打包者可以挑选依赖项而不受主机上的库限制。因此,打包者可以发布最新的、功能完整的软件包,同时保持发行的稳定性。

这一点非常重要,因为这些容器格式可以将应用程序和发行版发挥出最大的作用,而不会对系统造成破坏性的影响。

Nix 和 Flatpak

Nix 是一个跨平台的包管理器,可以在类 Unix 操作系统中运行,如 Linux 发行版、BSD 和 macOS。Nix 有几个 通道(分支)供用户使用。

另一方面,Flatpak 是一个用于 Linux 桌面的通用软件包格式,它也利用容器,但另外还有沙盒来隔离它们。它旨在以后可以供普通人使用,并被设计为与软件商店(如 GNOME “ 软件 Software ” 和 KDE “ 发现 Discover )集成。换句话说,Flatpak 更像是发行版的一个扩展,而不是一个软件包格式的替代品,因为它的设计初衷不是为了取代系统包管理器。

如果使用 NixOS 等发行版,Nix 也可以作为一种扩展或单独使用。

类似的应用

Nix 和 Flatpak 解决了传统软件包格式的许多基本问题。由于应用程序的分离,这些格式可以安装类似的应用程序,如 Visual Studio Code 和 Code - OSS,而不会冲突。

多个版本

Nix 和 Flatpak 可以安装同一个应用程序的多个版本。使用 Nix,我可以从 nixpkgs-stable(LTS)安装应用程序,同时也可以从 nixpkgs-unstable(开发版)安装同一个应用程序。

同样地,使用 Flatpak,我可以同时从 stablebeta 分支安装应用程序。我可以从更多的途径和分支继续安装同一个应用程序,而不会遇到冲突。

挑剔的依赖项

采摘樱桃

图片来源:来自 UnsplashIsh de loyola

此外,打包者可以将应用程序与不同变体的库捆绑在一起,从而有机会启用更多的构建选项,并使用打过补丁或特定版本的库,从而为用户提供完整的体验。

这意味着打包者可以将打了补丁的 FFmpeg 与 OBS Studio 捆绑在一起,只为了用在 OBS Studio 中。如果我在主机上安装了普通的 FFmpeg,那么 OBS Studio 的补丁 FFmpeg 就不会与主机的 FFmpeg 发生干扰或冲突。

各个发行版的环境都是一致的

如上所述,各发行版使用不同的补丁、构建选项和环境构建应用程序。这导致了应用程序的碎片化,每个应用程序的构建方式和工作方式往往不尽相同。由于 Nix 和 Flatpak 是为跨发行版运行而设计的,它们在每个发行版中为应用程序提供一致的环境,前提是发行版提供了 Nix 或 Flatpak 的支持版本。

缺点

就像所有事物一样,Nix 和 Flatpak 不是完美的。由于最近在 Linux 桌面上容器技术得到了推崇,它们可能为许多应用程序提供了不寻常的环境。

Flatpak 不仅包含了应用程序,还对它们进行沙盒处理。Flatpak 的开发者已经实施了一个短期的变通方案,“在沙盒上打洞”,即所谓的静态权限。他们正在开发适当的长期解决方案,称为 XDG 门户,以解决有关沙盒的许多问题,并使其像 Android 的安全模型一样。

唯一的短期问题是,工具包、框架和应用程序必须采用这些标准。GTK 和 Qt 这样的工具包集成了其中一些 门户 portal ,但它们也需要时间来集成其他的门户。同时,许多其他的工具箱还没有真正集成任何门户。

工具包、框架和应用程序采用这些新标准是一个时间问题,因为在 XDG 门户之前没有任何适当的标准。应用程序可以直接访问文件系统和 API,所以静态权限保持这种 “标准”。

结论

传统软件包格式的根本问题是它没有利用容器。许多图形化的应用程序本质上是复杂的,需要非常具体的依赖关系才能按预期运行。许多发行版通过使用变通的方法在不同的环境中构建同一个应用程序,例如给应用程序打补丁或禁用某些构建选项。这导致了一个应用程序的不同变体、不一致的行为和不合格的用户体验。

当然,发行版的维护者不可能在几天内现实地重写他们的包管理器并使用容器。这些重写会破坏许多脚本、功能等,而且还需要很长时间才能投入生产环境。

我个人的建议是使用和推广 Flatpak,因为它只是为了扩展现有的发行版,而不是取代它。打包者不必担心打包应用程序,以及诉诸变通的问题,因为 Flatpak 已经在处理这些问题了。

作者 Hari Rana 最初发表于此博客

Hari 是 Fedora 杂志的 Fedora 编辑委员会的成员。他也是 Fedoea 质量保证(QA)的一员。Hari 希望通过推广各种技术和帮助需要帮助的人,为 Linux 桌面的采用作出贡献。

本文所表达的观点和意见是作者本人的,并不代表我们的观点。


via: https://news.itsfoss.com/traditional-packaging-modern-applications/

作者:Community 选题:lkxed 译者:gpchn 校对:校对者ID

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

Rust Linux 驱动程序实现与 C 代码相当的性能

在都柏林举行的 2022 年 Linux Plumbers 大会(LPC)的 Rust 小型会议上,介绍了 Rust for Linux 工作的最新状况。Linux 内核已经有了很好的 C 语言编写的 NVMe 驱动,西部数据的测试显示,虽然其开发的 Rust NVMe 驱动仍处于早期阶段,但其驱动性能与 C 编写的驱动一样好。会议上介绍了最新的补丁系列是如何被精简以减轻上游工作的,以及过去一年的各种进展,但是关于 Rust 何时并入主线,会议上并没有披露具体的时间表和进展。

消息来源:Phoronix
老王点评:非常好的信号,但是大家都更关心什么时候能进入主线。

PyTorch 成为 Linux 基金会的顶级项目

开源 Python 机器学习库 PyTorch 成为 Linux 基金会托管的顶级项目,成立 PyTorch 基金会,其理事会的核心成员包括 AMD、AWS、谷歌云、Meta、Azure 和英伟达。PyTorch 最早由 Facebook 创建,自 2017 年以来,已经有超过 2400 名开发者在 PyTorch 基础上创建了 54000 个项目,PyTorch 成为了 AI 研究的主要平台之一。

消息来源:PyTorch
老王点评:PyTorch 是一个不错的项目,在 LF 的支持下,应该会有更好的发展。

思科承认“阎罗王”勒索团伙泄露了其数据,但表示没有问题

5 月份对思科进行了攻击的“阎罗王(Yanluowang)”勒索团伙周末在暗网上公开泄露了盗取的文件。显然,思科选择不支付勒索团伙要求的勒索,这导致被盗数据被公布。思科的威胁情报部门证实了所泄露文件的真实性,并重申其业务没有受到不利影响。然而,“阎罗王”勒索组织说,其窃取了多达 55GB 的数据,其中包括源代码和机密材料等敏感信息。

消息来源:The Register
老王点评:这组织的名字真是别致,但是到底对思科有没有影响,只有思科自己知道。

得益于开发者们最近的贡献,在 Ubuntu 中使用自己的强调色是很简单的。

每个 Linux 发行版都有它们默认的主题,具有各自的主色调。强调色用于在各个设置中突出主色调。通常,主色调和强调色应该形成对比和补充。

在最近的 GNOME 桌面的更新之后,Ubuntu 桌面在 22.04 LTS 版本中引入了强调色。

尽管如何应用它们是显而易见的,但是为了 Linux 的新手,我将解释如何在 Ubuntu 桌面中使用强调色。

在 Ubuntu 桌面中应用强调色

  1. 从应用菜单中打开 系统设置 System Settings
  2. 进入 外观 Appearance 菜单
  3. 风格 Style 菜单下,你应该见到一套预设的颜色。
  4. 选择其中的一个来改变强调色。

一旦更改,强调色将被应用到 GTK 应用程序中的选区和 GTK 控件中,如切换按钮和文件夹的默认外观。

默认的强调色是橙色,有十种颜色可供选择,具体如下:

  • 橙色
  • 树皮色
  • 鼠尾草色
  • 橄榄绿
  • 铬绿
  • 普鲁士绿
  • 蓝色
  • 紫色
  • 品红色
  • 红色

Accent Colour in Ubuntu

(LCTT 译注:树皮色是一种棕色,鼠尾草色是一种灰绿色。)

你应该记住一点,深色和浅色的主题的强调色组合可能改变你的桌面的整体外观。

以上的特性只是只适用于目前使用 GNOME 桌面的 Ubuntu,而不适用于其它提供原生 GNOME 的发行版,例如 Fedora Workstation。因为有一些内容是由 Ubuntu 团队开发的,并且并没有合并到 GNOME 上游。

Kubuntu 中的强调色

使用带有 KDE Plasma 桌面的 Kubuntu,你可以简单地使用强调色。KDE Plasma 提供了预设的颜色,也有自定义的颜色选择器选项。另外,自 KDE Plasma 5.25 起,强调色可以根据壁纸来改变。

为了在 Kubuntu 中改变它,跟着下面的步骤走:

  • 在应用菜单中打开 系统设置 System Settings
  • 进入 外观 Appearance > 全局主题 Global Theme > 颜色 Colours 标签
  • 选择你的强调色

KDE Plasma 5.25 - Accent Colour Change Based on wallpaper

我知道 Lubuntu 与 Xubuntu 并没有这个特性。而且它不太可能很快到来。

使用愉快。


via: https://www.debugpoint.com/ubuntu-accent-colour/

作者:Arindam 选题:lkxed 译者:yjacks 校对:wxy

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

关于 Unix 及其起源的简短回忆。

The beginning

Unix 的起源

如今,几乎整个世界都运行在 Linux 之上。数以十亿计的移动电话和服务器运行在 Linux 之上。但在 Linux 之前,是 Unix,没有 Unix 就没有现在的 Linux。

Unix 的起源可以追溯到人类登陆月球的时候。在 1965 年,三个著名的机构共同开展了一个操作系统研发项目,准备开发一个能够服务多个用户,并共享数据和资源的操作系统。

Scanned copy of actual Unix code

这三个机构是著名的 贝尔电话实验室 Bell Telephone Laboratories 通用电气公司 General Electric Company (GE)以及 麻省理工学院 Massachusetts Institute of Technology (MIT)。这个合作项目被称为 “Multics” —— 即“ 多路传输信息和计算业务 Multiplex Information and Computing Service ”的缩写。

不幸的是,该项目并没有见到成功的曙光,由于系统设计复杂且没有什么成果,贝尔实验室停止了该项目。

曾参与该项目开发的贝尔实验室的 肯·汤普森 Ken Thompson ,也投入到了新的工作中。在 数字设备公司 Digital Equipment Corporation (DEC)的一台古老的 PDP-7 计算机上,他重新开始设计了一个新操作系统。不久后, 丹尼斯·里奇 Dennis Ritchie 也加入了,二人一起设计了分层文件系统、设备文件、命令行解释器以及进程。这就是 Unix 的诞生过程,它的名字是由 Multics 项目的另一名成员 布莱恩·克尼汉 Brian Kernighan 给命名的。(LCTT 校注:前不久,80 高龄的布莱恩还为他共同创造的 AWK 添加了新的特性。)

接着在 1971 年,Unix 被移植到了稍微先进一些的 PDP-11 计算机上,它仅有 512 KB 的磁盘。当时,Unix 只支持 16 KB 内存,可以为用户程序分配 8 KB 的内存。

然而,Unix 大多数代码是用汇编语言编写的,十分依赖于硬件。因此它并不具备移植性。

Ken Thompson (sitting) and Dennis Ritchie at PDP-11 (credit and learn more about this image1)

C 语言的创建

如此一来,要使 Unix 具有可移植性,使之与 机器无关 machine-independent ,唯一的方法是使用高级语言编写它,这样编译和相应的目标代码就可以进行机器指令的转换了。

解决该问题的伟大思想诞生于一瞬间。肯·汤普森从零开始创建了一种名为 “B” 的高级语言。然后,他做了大量的工作,将 Unix 的汇编代码转换成这种新创建的语言。然而,“B” 语言也存在一些局限性,丹尼斯·里奇在此基础上创建了著名的 “C” 语言,这使得 Unix 真正成为一个可移植的操作系统。

著名的 “C” 语言至今还在使用。

到上世纪 80 年代中期,Unix 已经变得十分成功,从微型计算机到大型机,它可以在成千上万种硬件上运行。

The text book of C which we all read

MINIX 和 Linux 的诞生

1987 年,计算机科学教授 安德鲁·斯图尔特·特南鲍姆 Andrew S. Tanenbaum 开发了一个名为 NINIX 的类 Unix 系统,在其著作《 操作系统设计与实现 Operating Systems: Design and Implementation 》中用以解释操作系统的概念,并随该书一起免费分发了这个操作系统(16 位的版本)。那些学习计算机科学专业(包括我)或相关专业的人都知道,这是一本解释操作系统基础知识的“神级”教科书。

1991 年, 李纳斯·托沃兹 Linus Torvalds 在赫尔辛基大学学习期间开始了一项 爱好项目。他的项目是基于 MINIX 和 GNU C 编译器的。他启动这个项目是为了能够在他的配有新款 80386 处理器的新 PC 上运行程序。他编写的整个操作系统包含了 MINIX 所缺乏的特性,最终成为了 Linux 内核。

Famous operating systems book by Tanenbaum

BSD 和 macOS

上世纪 80 年代,当 Unix 初具规模时,贝尔实验室基于 Unix 的最初源代码(在 PDP-7 和 PDP-11 上运行的版本)开发了 BSD( 伯克利标准发行版 Berkeley Standard Distribution )。BSD 是由加州大学伯克利分校的 计算机系统研究小组 Computer Systems Research Group (CSRG)分发的。在其形成之后,BSD 被许多工作站供应商(传统桌面系统),如 昇阳微系统 Sun Microsystems ,改编为专有的 Unix 变体。

该版本最终分叉创建了一些开源的变体,例如 OpenBSD、FreeBSD 等。这些自由版本为 史蒂夫·乔布斯 Steve Jobs 创立的 NeXT 创建 NeXTSTEP 开辟了道路。而 NeXTSTEP 最终成为苹果公司 macOS 的基础。

总结

Unix 是少数具有独到思想并致力于解决问题的人取得的非凡成就。如果考虑到在创建操作系统当时可用的计算能力和内存量,这个操作系统简直就是一件艺术品。

几十年来,所有这些一步步的进步,最终使我们走到了今天。无论有多少内核、操作系统和以编程语言形式出现的抽象概念,就其本质而言,它们都始于一个单一的来源。

我一直认为程序或代码是人类的思想,是你的逻辑、想法,只是写在 “IF-ELSE” 语句中,以实现一些现实世界的结果。

参考资料:

“所有的革命,在它们发生之前,都是历史的必然。” —— 大卫·米切尔 《云图》

via: https://www.debugpoint.com/unix-history/

作者:Arindam 选题:lkxed 译者:Donkey-Hao 校对:wxy

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

Retbleed 修复导致虚拟机性能降低 70%

VMware 在 Linux 内核邮件列表中报告,在内部测试发现,在 ESXi 管理程序上运行使用 5.19 版 Linux 内核的 Linux 虚拟机,使用单一 vCPU 的计算性能下降高达 70%,网络性能下降 30%,存储性能下降高达 13%。而关闭了 5.19 版内核中的 Retbleed 补救措施后,ESXi 性能恢复到 5.18 版的水平。

消息来源:The Register
老王点评:许多 VMware 用户可能会在生产中使用 Skylake CPU,这样的性能损失不可能接受,那就只能冒着风险了?虽然这个漏洞并不太容易利用。

停止十年的 Ubuntu 线下峰会将于今年 11 月启动

Canonical 曾经在每个 Ubuntu 开发周期中举办 “Ubuntu 开发者峰会”,但那是十年前的事了。后来它在变成了一个线上活动,然后逐渐消失,转而变成支持 Canonical 的内部路线图规划和其他员工之间的开发者冲刺的活动。新的活动现在名叫“Ubuntu 峰会”,即将于 11 月在捷克的布拉格举行。

消息来源:Phoronix
老王点评:不知道 Ubuntu 峰会会不会带来一些惊喜?总感觉现在每个 Ubuntu 版本的发布都缺乏令人激动的新变化。

微软推出点对点流媒体技术 eCDN 解决方案

微软的企业内容交付网络(eCDN)可以提高加入直播流的参与者的数量,使其有可能满足有众多参与者的公司范围的会议。这是一个基于 WebRTC 的解决方案,利用了点对点流媒体技术。微软称,微软 eCDN 可以同时容纳数百万的参与者,而不会使企业网络过载,也不会遇到视频流的质量、安全和隐私方面的麻烦。

消息来源:Redmond Mag
老王点评:大规模实时流量还是得依赖点对点应用。