Liam Proven 发布的文章

1983 年和 1993 年之间的变化显著,然而从那时候到现在,变化其实并不大。

2023 年即将过去,我们来回顾一下三十年前的科技。不只是与今天进行对比,也是和更早的十年前对照。有趣的不是变化有多大:而是变化的速度有多快。

一位澳洲老极客近期指出,距离 id Software 的“最具影响力的恐怖动作游戏”问世,以及它带来的网络“死亡竞赛”,已经 三十年 了。回顾 1993 年的科技,并把它和 1983 年对比一下,真是令人惊叹。仅仅十年的时间,现代计算的大部分技术都诞生了。许多始于 1993 年的重大技术,如今依然是我们依赖的核心。

正如 DOOM 在 1993 年重新定义了电子游戏,Windows NT 也赋予了 PC 操作系统全新的定义。NT 的第一个版本在 DOOM 发布前几个月就 问世 了,其影响力甚至更为深远。1993 年我们也见证了 NCSA Mosaic 的发布,这是最初的 Web 浏览器。Mosaic 的衍生品是 Netscape。起初它开始运营的名字是 Mosaic 通信公司,不知为何,这家公司的首页现在 仍然存在。后来,Mosaic 公司 变成 了 Netscape,进而催生出了今日的 Mozilla。1993 年还有一项里程碑式的事件,那就是 Trojan Room 咖啡壶摄像头的上线,这是有史以来第一台网络摄像头。

1993 年奠定了现代计算的发展方向。一代人的时间过去了,大多数桌面电脑用户仍在使用基于 NT 系统的变体:Windows 11 仍然基于它。而 Mosaic 代码库的最后一部分随着 IE 11 的退场已经销声匿迹,但我们仍然在使用间接源于 Mosaic 的 Web 浏览器。

要想了解 1993 年带来的影响有多大,可以将其与早更的十年前做个比较。1983 年,Camputers Lynx 亮相,但它根本无法与 英国的热销机型 —— ZX Spectrum、BBC Micro 和 Commodore 64 相抗衡。而就在 Lynx 问世的同一年,另一款价格更昂贵的失败产品也在池塘边面世。虽然数以千计的苹果 Lisa 最终被扔到了垃圾填埋场,但其精简成本后的继任者 Macintosh,确立了个人电脑的新标准 —— 即便现代 Mac 中几乎找不到初代 Macintosh 的技术影子。

Lisa 之所以失败,部分原因是其售价高达 $9,995,约合今日的 $30,000。确实不菲,但对比一下,原始版 IBM PC 标配硬盘的第一代,即 IBM PC/XT,也是在 1983 年发布的。由于拥有 10 MB(注意,不是 GB)的硬盘,其价格达到了 $7,545,大约相当于今天的 $22,500。这就是为什么像 Commodore 64 这样的 8 位设备在 1983 年的市场中占据主导地位的原因:64 KB 内存、磁带存储,以及一台模拟电视作为显示器,是大多数家庭用户能负担起的全部。Commodore 64 在 1981 年发布时的定价为 $595](https://www.theregister.com/2012/01/02/commodore_64_30_birthday)。到 1993 年,按通胀计算这个价格约为 [$1,000,而这在当时可以买到一台 486 PC

转瞬十年变迁

1973 年,微处理器几乎还没有出现。那时还没有英特尔 8080 或 CP/M。我们所认为的 PC 该有的能力需要一台定制的工作站才行,其成本约合今天的 $280,000:Xerox Alto。和其相比,Lisa 看起来还算便宜。另外,1973 年,以太网 也诞生了。

在十年之后,一台售价 $10,000 的个人电脑刚刚能够实现单色的图形用户界面(GUI),但很少有人意识到其好处,买的人就更少了。再过十年,到 1993 年,Windows for Workgroups 3.11 发布,而那时连低配置的 PC 也能流畅运行它。同年,MacOS 7.1.1 也发布了,任何 1993 年生产的 Macintosh 都能毫不费力地运行它。1983 年最畅销的 电子游戏 是《 吃豆人 Pac Man 》和《 大金刚 Donkey Kong 》,十年之后,人们痴迷的是一款网络实时 3D 第一人称射击游戏 —— DOOM。

从 1983 到 1993,计算机世界从 8 位 CPU 和几十 KB 的存储,发展到拥有 MB 存储的 32 位机,并且图形用户界面成为了标准配置。NT 3.1 是首个具有完全抢占式多任务处理和内存保护功能的 Windows 版本,它取代了 Windows 3 和经典 MacOS 的原始而不稳定的协同多任务处理。NT 3.1 也是首个内置 TCP/IP 的 Windows 版本,当时以太网开始成为标准配置,图形网页浏览器也应运而生。浏览器和第一台网络摄像头的出现,是使 互联网盈利 的关键所在。

虽然对大多数人来说并不重要,但 Windows NT 的第一个版本已经支持了 双 CPU,它使用的 英特尔 MP 标准,曾出现在 Compaq SystemPro 中,其首个 386 型号发布于 1989 年。当 双核芯片 开始面世时,NT 已经做好准备,但实际上,多处理器 PC 并不是在二十世纪九十年代才出现的,它们是 80 年代末期的技术,在 1993 年已经落地并投入使用。

在屏幕图形方面,我们或多或少获得了实时 3D 技术,尽管仍然是通过软件渲染的。OpenGL 标准在前一年获得了批准,Windows 上的“视频”应用也在此时作为 Windows 3 的免费附加组件出现。

那么,后来发生了什么呢?

在接下来的十年中,许多较小的部分逐渐到位,但它们的变化更像是演进,而不是变革:是帮助而非突破。Windows 95 使得桌面界面现代化,而现在的大多数工作方式仍 与那时相同,尽管微软已经作了 大量努力。在世纪之交,英国开始全面推广 ADSL 宽带,让大部分人享受到了快速的互联网。一年之后,Windows XP 的问世,终结了基于 DOS 的 Windows 时代。 NT 发布十年后,首款 64 位 PC 芯片 问世。

从那时起……那么,你能说出哪些重大进步吗?在 PC 之前,手机就可以 听懂口语命令(尽管我们一度认为这只是个 噱头)。你的脸可以 解锁设备,但它们仍然无法读懂你的表情。手势操作仍然只限于触摸板。从 32 位转移至 64 位的进程相当平淡乏味:主要的变化就是你可以拥有更多的内存。计算机变得更小,更节能,运行更安静,拥有更多也更快的存储……仅此而已。

尽管 PC 行业绝不承认这一点,但正如在 2021 年,或者说更早的十年前也一样,计算机的速度增长已经不再那么显著。存储设备也如此,最新的耗电大户 GPU 这类半专用的特定用途芯片也依然如此……不过近来 苹果芯片 的表现显示,提升图形性能的效率秘诀并不在于在总线末端挂载一个庞大的高热 GPU 群,而是将更小的 GPU 集成到 CPU 芯片中。

现在我们已然走过 21 世纪的四分之一,但在可编程性、交互性或全新的不可预见的技术等方面却没有取得惊人的突破,三十年来,电脑容量和并行处理性能的增长,主要让操作系统和应用程序变得前所未有的臃肿。

Windows NT 3.1 操作系统的最新版本是 Windows 11 ,而 1993 年时它已经具备了 Windows 11 大部分的功能。NT 3.1 能够在两种 CPU 架构(x86-32 和 MIPS)中运行,并拥有用于 DOS、Windows 3、UNIX 和 OS/2 应用程序的子系统…… 这一切都被集成在只有 50 MB 的 ISO 文件中。而如今的 Windows 11 需要 6 GB 的存储空间。它扩大了 120 倍。如果你认为现在的功能是当初的 120 倍,那么请举手。

(题图:DA/a10b4730-ce44-48c2-aa61-d630ddca8660)


via: https://www.theregister.com/2023/12/19/windows_nt_30_years_on/?td=rt-3a

作者: Liam Proven 译者: ChatGPT 校对: wxy

虽然你可能听到不同的看法,但实际上,它并未像一些批评者所想象的那样完全专有。

对 Ubuntu 的 Snap 打包格式最常见的误解之一是它是专有的 —— 但是深入研究其文档后,会发现这个说法并不对。

在上周末拉脱维亚的里加举行的 Ubuntu 峰会上,笔者有幸采访到 Ubuntu 的 开发者大使 developer advocate ,Igor Ljubuncic。期间,他们详细探讨了关于 Snap 的各种误区,包括它被视为完全闭源的、受 Canonical 控制、必须使用 Canonical 的 Snap 商店等众多谬论。

如果说有什么比糟糕的软件更加厌恶的,那一定是谎言。正如我们在 点评 Fedora 39 时所注意到的,即使在 Linux 诞生之前,各种软件的拥趸们就经常爆发各种 圣战。但我们至少希望能坚守事实的公道。毫无根据的恶意指责是没有必要的:生活本身已经足够糟糕。

笔者的立场很明确,我们并不特别偏爱任何 Linux 发行版或其打包工具。像许多资深电脑技术人员一样,在长期和各种软件打交道后,笔者已经对所有的软件厌烦至极。一句广为接受的说法就是:没有一个软件不让人头疼

Linux 就是一个软件,因而它难免让人头疼。承此,所有的 Linux 发行版也都不尽如人意。包管理器也是一个软件,同样也不尽人意。但幸运的是,至少大多数 Linux 发行版都有一个包管理器。这比没有软件包管理器要好,或者更糟糕的是,有不止一个以上的包管理器,这一点 XKCD 927 漫画体现的淋漓尽致。

我们并不特别青睐 Snap,也不特别反对 Flatpak。笔者个人更偏好 AppImage 格式,它不需要其他额外的框架。但虽然有个 AppImageHub,但该格式却并没有提供软件更新的工具,这个问题就留给了应用本身来解决。

鉴于所有的软件都不完美,那唯一重要的区别就在于其问题严重的程度。一段时间以后,你最关注的就是它是否可运行,能否满足你的需要,以及它的可靠性。

我在早年的职业生涯中花了很多时间在技术支持上,修复其他人的软件。因此,我学到了一个经验,那就是降低软件让人厌烦程度的一个重要因素就是它工作的方式是否容易理解。

Btrfs 是复杂的,而修复它则更是如此。Git 属于本质复杂,其 名称 就体现出这一点。(没错,“git” 是一个名词,而非缩写或代号,有实际的意思 —— “饭桶”。)OStree 可以说是针对二进制文件的 Git,这使得它比普通 Git 至少复杂两倍。而 Flatpak 则是 OStree 的封装。

这意味着增加了两层额外的复杂度:首先,对复杂事物的封装只能隐藏其复杂性,而不能消除其复杂性。其次,你不能使用 Flatpak 构建一个操作系统,因此你还需要 OStree。

因此,我们将来逐一揭穿关于 Snap 格式和工具的一些误解。这不是一篇入门指南,而是对那些不那么显而易见,并且对 Snap 有所误解的人的一份快速概览。

无需商店进行分发

Snap 包其实就是一个 Squashfs,类似于大多数 Linux 安装介质上的系统镜像。Snap 包以两个文件传递:其中一个是命名为 <name>_<revision>.snap,该文件包含了软件本身;另一个则是一个伴随的 声明文件,它为 Snap 提供了数字签名。然后,Canonical 还进一步 详细阐明 了版本修订的工作原则。

使用 snap download 的指令(而非 snap install)可以容易获取这些基本文件:

# snap download firefox
Fetching snap "firefox"
Fetching assertions for "firefox"
Install the snap with:
  snap ack firefox_3252.assert
  snap install firefox_3252.snap

然后,这些文件便可以被复制到另一台设备上进行安装,这种操作不需要访问 Snap 商店,仅需使用输出中的指令即可。

如 Igor 所说:

“这样,从 Snap 商店中,你可以选择你想要的 Snap 包(如 Firefox),将其放入你的内部仓库中,或是 FTP,或是 NFS 上。接着你可以使用它作为在内部安装 Snap 的来源,而这不需要去访问商店。此外,你还可以将这个操作与你所使用的任何调度或部署机制结合起来,就如配置管理那样。”

安装无需声明文件的 Snap 包

通常来说,snap ack 命令会首先读取并验证签名,但是你可以选择跳过这个步骤。

snap install "downloaded snap" --dangerous

上述指令会安装该 Snap 包,并不会验证其签名。请注意,这样做虽然操作简单,但也有一个重要的限制:使用 --dangerous 选项安装的 Snap 包不会自动从商店中更新。

所以,实际上,你可以在你的网络内部分发 Snap 包,避免它们试图连接到 Snap 商店,并自主管理更新。

管控 snapd 内置的更新机制

另一方面,你可以在不忽略验证机制的前提下,管理和控制操作系统何时以及如何更新 Snap 包。Igor 则曾撰写过关于如何使 Snap 更新暂停 的文章。

你可以设置暂停 Snap 的更新一段时间,或永久暂停,甚至只选择暂停特定的 Snap 包,同时也能简单取消此设置。例如:

snap refresh --hold
Auto-refresh of all snaps held indefinitely.

另外,你也可以通过以下方式设置防火墙拦截 Snap API:

sudo iptables -A OUTPUT -d api.snapcraft.io -j DROP

在无 snapd 环境下运行 snaps

.snap 文件实际上就是一个压缩的文件系统,它包含着程序文件(以及各种库等),这些都被存放在一个传统的目录结构中,而该目录结构对于打包在 Snap 应用程序内的应用来说,就是它的根目录。Snapd 负责为此设置挂载名空间,并通过 Apparmorseccomp 实现安全隔离。

你可以将其内容解压并直接运行:

unsquashfs firefox_3252.snap  
Parallel unsquashfs: Using 20 processors
565 inodes (5428 blocks) to write
[=====================/] 5428/5428 100%
created 399 files
created 149 directories
created 166 symlinks
created 0 devices
created 0 fifos
created 0 sockets
ll squashfs-root/
total 80
drwxr-xr-x  7 igor igor  4096 lis  10 02:33 ./
drwxr-xr-x 10 igor igor  4096 lis  19 15:32 ../
drwxr-xr-x  5 igor igor  4096 lis  10 02:33 data-dir/
-rw-r--r--  1 igor igor 32441 lis  10 02:33 default256.png
-rw-r--r--  1 igor igor  9146 lis  10 02:33 firefox.desktop
-rwxr-xr-x  1 igor igor  2680 lis  10 02:33 firefox.launcher*
drwxr-xr-x  2 igor igor  4096 lis  10 02:33 gnome-platform/
drwxr-xr-x  4 igor igor  4096 lis  10 02:33 meta/
-rwxr-xr-x  1 igor igor  3716 lis  10 02:33 patch-default-profile.py*
drwxr-xr-x  4 igor igor  4096 lis  10 02:33 snap/
drwxr-xr-x  4 igor igor  4096 sij  19  2022 usr/

如果你查看 Snap 内 Firefox 二进制文件的动态依赖,你会注意到它希望从根文件系统中获取文件:

ldd usr/lib/firefox/firefox-bin
       linux-vdso.so.1 (0x00007fff33cc5000)
       libstdc++.so.6 => /lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f6cf2c00000)
       libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f6cf2e40000)
       libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f6cf2be0000)
       libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f6cf2800000)
       /lib64/ld-linux-x86-64.so.2 (0x00007f6cf300e000)

在 Snap 内部,这个“根”就是你的基础系统(比如 core18 或 core20 等)。但是一旦你解压了这个 Snap,没有 snapd 在安装和运行 Snap 时提供的安全隔离,Firefox 将会尝试直接访问你的根目录的库。这可能会导致执行时的不一致性。

举例来说,你的 Snap 内可能包含的是 GNOME 3.38 版的库,但是你的主机上运行的可能是 GNOME 3.32。如果你尝试解压并运行这个应用,它可能会试图从主机中加载库,这可能引起不一致 —— 更甚者,可能会让程序崩溃。

为了避免这种情况发生,你需要做的唯一事情就是设置 LD_LIBRARY_PATH 环境变量,以让程序知道其库在何处,确保它首选这些库,而不是使用可能导致其运行失败的操作系统中的库副本。

LD_LIBRARY_PATH: ${SNAP_LIBRARY_PATH}${LD_LIBRARY_PATH:+:$LD_LIBRARY_PATH}:$SNAP/usr/lib:$SNAP/usr/lib/x86_64-linux-gnu

通常,你会希望 LD_LIBRARY_PATH 开始于 /snap/<snap name>/,然后是 /lib/usr/lib 和其他常用路径。至于其他内容,firefox.launcher 文件负责准备运行环境,剩余的,比如 firefox.desktop,都用于桌面集成:如图标、全名、文件关联等。这些内容虽然使应用看起来效果更好,但它们并非严格的必需品。

其实,你甚至不需要解压 Snap 的内容,你可以直接将 Snap 文件本身作为一个 回环设备 挂载 —— 你甚至可以设置为只读 —— 但没有挂载命名空间隔离。并且,如果没有设置环境让 Snap 内部的应用在寻找它的库时首先从 Snap 内部开始,你仍然需要正确地设置库路径。

代理和缓存 Snap 包

正如 Igor 所说,如果客户并不打算自行运营一家具备完整品牌属性的 Snap 商店,他们可以选择手动设置一个 Snap 代理。对此,Canonical 也提供了相应的 文档,并描述了所需的 网络访问 权限。

同时,你也可以 配置 一个缓存 Snap 代理 —— 这项任务稍微简单一些,对于希望降低下载带宽的家庭网络来说,可能是个不错的选择。

搭建自己的 Snap 商店

就如我们之前所述,你完全可以忽略所有来自 Canonical 的基础设施,直接运行自己的 Snap 商店。去年,我们写过一篇关于 Ubuntu Unity 维护者 Rudra Saraswat 的文章,他就 做到了这一点,这只是他的众多项目中之一。据悉,好几个在生产环境中使用 Ubuntu Core 的组织都采取了此种做法,而所有所需的工具都存放在 Ubuntu 仓库中。

Canonical 在这方面发布了大量的文档,包括怎样构建你的 第一个 Snap 包,以及如何用 不同的编程语言 构建。今年的峰会上有多场关于如何构建 Snap 的演讲 - 包括 在平板电脑上构建 Snap 包,以及如何 自动化构建更新的 Snap 包,虽然这对笔者来说有点过于复杂。

学习一些新的术语是有必要的,同时也有 官方文档 提供帮助。这段解释我们特别喜欢:

  • 插槽 slots 是指提供方(即 Snap 提供的资源)
  • 插口 plugs 是指消费者(即使用 Snap 提供的资源的用户)
  • 接口 interfaces 是交互的地方(负责将插口和插槽连接起来)

从我们与 Canonical 代表的对话中,他们似乎对 Snap 商店被误解,以及 Snap 被视为封闭、专有系统的争论显得尤为不满。

大约十五年前,有人曾声称 Canonical 的代码托管和项目管理平台 Launchpad 是专有的,所以 Canonical 在整理代码后在 2009 年 公开发布 了代码库。但如我们交谈的人所言:“没人在意。” 它是 Canonical 的内部工具,对其他人来说并没有太大的用处。他们表示,他们不希望再经历一次这样的情况。

我们还注意到,红帽正在朝反方向前进,即从开源的 Bugzilla 迁移 到封闭的、基于云的 Jira —— 这并未引起太大的争议。

snapd 自身的代码已经托管在 GitHub 上,作为 Canonical 的 snapcore 仓库的一部分。这个被大多数发行版使用的打包格式是一个已经存在、有文档记录的格式。用于进行隔离的工具,是已经存在并在其他发行版中使用的第三方工具,比如,Debian 和 SUSE 家族也使用了 AppArmor,这与 Arch 维基中的 描述 相符,而它的主要竞品,SELinux,则更复杂,主要在红帽及其衍生产品中使用。

尽管 Canonical 自家定制的 Snap 商店 的后端仍然 闭源,但 Snap 格式、snapcore 软件、snapcraft.io 前端,以及更多组件都是开放的。我们再次强调,你完全可以自行搭建 自己的 Snap 商店

请不要受到愤怒的论坛喷子们的误导。

最后再说一点...

实际上,撰写这篇文章的作者曾经就职于红帽和 SUSE,但他主要还是使用 Ubuntu,从 2004 年 Ubuntu 刚刚发布起就开始一直使用。Ubuntu 不但运行顺畅,使用起来也十分便捷。然而,早在多年前他就已经从他的主要工作电脑上删除了 snapd 和相关的一切工具,取而代之的是 deb-get —— 最初这是 Ubuntu MATE 的创造者 Martin Wimpress 编写的。为了更加迅速,他还选择使用 Nala 包管理器 而不是 Apt。

如果可以的话,笔者很希望可以放弃各种形式的 Unix,除了服务器,其他情况下更倾向于使用 RISC OS 或是经典的 MacOS。但是遗憾的是,这两个操作系统在网络浏览器、网络连接,还有多核支持和整体稳定性上有待改进。

笔者今年参加 Ubuntu 峰会的费用是由 Canonical 承担的,这一点他愿意公开。类似的,Linux 基金会曾资助他参加 今年 在 Bilbao 的开源峰会,而红帽则资助了他在 2016 年在 Kraków 参加 Flock to Fedora 峰会。这类赞助可以让我们将广告预算分配到其他地方,但并不会对我们的报道产生影响:我们总会积极追踪那些 IT 新闻。

(题图:MJ/520ba58f-9e07-4acb-af4a-f4832762311f)


via: https://www.theregister.com/2023/11/10/snap_without_ubuntu_tools/

作者:Liam Proven 译者:ChatGPT 校对:wxy

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

Armbian 23.08 版本已出炉,初步开始为这款轻薄的 Snapdragon 笔记本提供支持。

最新发布的 Armbian 有助于解决在 Arm 计算机上安装并运行 Linux 发行版的困难 —— 这是一项不小的挑战。

今年 3 月我们 评测 的联想 Thinkpad X13S 第一代,是我们评估的首款主流 Arm 驱动笔记本电脑。当然,市面上确实还有其他的 Arm 笔记本,如 Pine64 的 Pinebook Pro 和多款基于 Arm 的 ChromeBook 等。然而,X13S 更接近常规的基于 x86 的笔记本电脑:具备优质的配置,配有 16GB 内存和 256GB 的 NVMe SSD,更重要的是,它搭载了 PC 行业标准的 UEFI 固件,这在消费级 Arm 计算机上尚属罕见。另一个好消息是,你可以禁用安全启动,这是许多 Arm 设备不支持的。十年前,这是最初的微软 Surface RT 的一个 关键问题:Windows RT 一团糟,而它的固件不让你运行其他的系统。

虽然 X13S 从 2022 年 5 月就开始发售,但要让这个机器支持运行 Linux,却花费了一段不短的时间。一篇 博客文章 列出一些相关问题,文章副标题 “拥抱苦难” 已经透露出难度之大。这篇文章链接了一篇有关如何在该机器上安装 Debian 的 很老的指南。我们按照指南操作,尝试安装中间版的 Debian,定制内核,看起来安装成功了。

将其从 SSD 启动,着实需要巨大的努力,这涉及到进入 UEFI 固件 Shell,并手动逐个查阅 30 到 40 个条目才能找出并启用正确的 UEFI 启动条目,但经过数小时的寻找和无数次的重启,它成功工作了,Debian 能够启动。不幸的是,在启动已经安装的操作系统时,屏幕在输出几行以后就变黑了,再也没亮过。虽然操作系统还在运行,例如,按下电源键会在几秒后干净地关闭电源,但由于没有显示,甚至是文本显示也没有,我们无法配置 Wi-Fi 连接,而且该机器并没有内建的以太网接口。

随着最新固件和更新的支持,现在已经能在基于 Arm 的 Thinkpad 上使用 Ubuntu Lunar 的 GNOME 桌面环境。

此外,尚有一种 “概念版” 的 Ubuntu 23.04 “Lunar Lobster”,其开发并未完成,该公司要求我们不公开相关链接。自从我们拿到这台机器以来,已经进行了多次固件更新:最初其固件版本为 1.25,如今已经更新至 1.57。在固件版本更新到 1.49 时,固件设置程序增加了一个处于测试阶段的 “Linux” 选项,并随着下一次更新,机器首次成功通过我们的 Ubuntu USB 启动盘启动。但引导过程极慢,开机至少需要 10-15 分钟,甚至更久,而且当它运行在 立付 Live 系统模式下时,设备功能有显著限制:比如无法发出声音,Wi-Fi 仅支持 2.4GHz 等。尽管如此,它的运行效果尚可,足以完成安装。初次启动进入的是空白屏幕,然而,你可以切换到虚拟控制台,登录并从 Shell 提示符下更新操作系统。在更新并重启后,图形登录界面出现,此时我们可以正常登录,5GHz Wi-Fi 也开始正常工作。

在固件 1.56 更新阶段,Ubuntu 在这款硬件上仍有诸多限制:无声音,仅支持 Wayland,不支持 X.org。按照我们的惯例,我们安装时将 /home 挂载在独立的磁盘分区中,Ubuntu 在一个只读的主目录上启动,但这导致 Ubuntu 无法保存任何设置,也未能创建常用的文件夹(如 ~/Documents 等)。然而,执行了一条手动的 chown 命令后,权限问题得以解决,/home 目录也得以写入。

全面更新后,就连 X.org 也能正常运行,这意味着非 GNOME 桌面可能最终也能被成功运行。

固件版本 1.57 出现在上个月,重新安装并更新 Ubuntu “Lunar” 后,声音和 X11 功能得以正常工作,这意味着非 Wayland 桌面现在也变得可行。尽管仍有一些困难,但是配备一个 USB-C 以太网适配器会有很大帮助,现在的 X13S 笔记本已经可以很好地运行 Ubuntu。相较于 Windows 运行下的状态,一个显著的差异在于,没有了 x86 模拟环境,只有原生的 Arm64 应用,机器的运行状况变得没那么热了。尽管底座会变热,但它可以放在白白的大腿上使用而不会烫到你。

甚至连声音芯片也得到了支持,我们可以播放音频并调整音量。

一个(相对)更加简单的选择是——Armbian

在 Arm 笔记本上运行 Linux 的问题在于,基于 Arm 的计算机并不仅仅是一台 CPU 类型不同的 x86 个人电脑。标准的主板和芯片组以及可替换的 GPU 是相当稀有的。大部分机器都是围绕一种高度集成的 SoC 构建的,它包含了 CPU、GPU 以及所有其他组件。

在 x86 个人电脑上,操作系统可以依赖标准固件来启动计算机,但并非所有的 Arm 设备都拥有这样的固件。制造商为每种 Arm 设备打造适合运行特定操作系统的设备,替换为另一种操作系统可能非常棘手。这就是为什么树莓派计算机系列成功的原因之一:不是因为它们特别简单,它们并不是,而是因为它们的销售量大,因此得到广泛的支持。

Armbian 项目就是对这个问题的答案。它为大量的单板计算机(SBC)——主要是 Arm 架构的,正如名字暗示的那样,虽然并非只有这些——编译了特殊的内核。在 23.08 版本(代号为 Colobus)的发布时,已经列出了支持的 59 个 Arm64 设备,以及 8 个 RISC-V 的板卡,还有一个 通用的 x86-64/UEFI 版本。我们在去年 3 月时点评了 Armbian 22.02,但我们重新回顾它,是因为这次发布包含了一个在 X13S 上的 版本,即使支持仍在 持续进行

对于 x86 PC 来说,你通常从安装介质启动,然后将操作系统安装到机器的内部硬盘上。但对于 SBC 来说,更常见的是将镜像写入内存卡,然后从内存卡启动电脑,因此并无特定的安装进程。Armbian 为 X13S 提供的下载压缩后只有大约 2GB,但它包含了一个完全安装的系统,因此你至少需要一个 16GB 的 U 盘。第一次启动时,它会进入文本模式提示并要求 root 密码、用户账户的凭据,时区以及地区信息。只有在这些信息输入完毕之后,它才会加载图形桌面。

Armbian 的 Cinnamon 桌面实际上是专为 Arm64 设计的 Debian 12.1,额外附加的驱动及微调使其符合 X13s 的需要。

这套方案成功地创建了一个工作正常的系统,包括屏幕亮度调节等功能。系统重启后,我们可以连接 2.4GHz 和 5GHz 的 Wi-Fi,并以典型的 Debian 方式进行更新:使用 sudo apt update && sudo apt full-upgrade -y 命令。然而,系统没有声音,而且电池支持也尚未到位:不能充电,并且电量指示器不能工作。而且,我们的 Planet Computers USB-C 集线器上的以太网端口也未被检测到。我们试图使用 armbian-installer 脚本将 Armbian 安装到 SSD,但尽管 Ubuntu 找到并将其添加到 GRUB 菜单中,Armbian 仍无法从 SSD 启动。

总结

随着时间推移,高通 Snapdragon 8cx Gen 3 平台的 Linux 支持得到了改善。在最新版本上,Ubuntu 在 X13S(内核版本 6.2)上已经可用,我们预期,随着下个月 Ubuntu 新版的发布,这种设备可能变成一个受到支持的平台。

与此同时,一些其他的发行版也在进行支持工作。虽然 Fedora 有一个 内核镜像,但目前只是停留在这个阶段。另外,openSUSE Tumbleweed 也有一个预发布 镜像,但还没有安装程序,对声音以及电池也尚无支持。

OpenBSD 可以直接支持高通芯片,但是这个操作系统的常规限制,如蓝牙的全面缺失仍然存在。我们已经验证了其可以从 USB 启动并成功配置 Wi-Fi 及 USB 以太网卡,但我们并未深入尝试,因为对于删除我们当时唯一能够完全运行的操作系统——Windows,我们持保守态度。

在 Windows 11 Arm64 上的 Ubuntu 22.04 上运行的 GNOME 网络浏览器 Epiphany

当然,还有 Windows 的 Linux 服务 Windows Services for Linux (WSL)。这目前是最快捷到达可工作的 Linux 系统的途径:我们试验了在 Windows 11 下的 WSL2 中运行 Ubuntu,它工作得相当完美——且带来附加优势,你明确知道你正在运行的是原生 Arm 应用,而非在耗电的模拟环境下运行的 x86 代码。然而,要注意运行 Windows 本身并不高效,如果你在后台有一些 X86 的应用,你的电池续航会严重受影响。

如果你乐意从 U 盘启动——此处我们推荐使用一个高速 USB-C 盘——那么 Armbian 就能很轻松地帮你启动,虽然有一些限制。随着新内核支持的提升,Armbian 的功能也将随之增强。

X13S 并未准备好全面采纳任何自由和开源的操作系统——例如,网络摄像头尤其仍未得到支持——但 Ubuntu 已经差不多准备好了。目前的镜像并非官方版本,但你可以在你信任的搜索引擎上找到它。如果这个方式失败,那么 Armbian 将是你的第二选择。

(题图:MJ/701d8523-f00b-4ac4-b559-428a9ab2746f)


via: https://www.theregister.com/2023/09/08/linux_on_the_thinkpad_x13s/

作者:Liam Proven 译者:ChatGPT 校对:wxy

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

考虑到它已经如此之老,它的活力令人惊讶。

USENET 管理委员会已经重新召开,这个早于万维网的原创社交网络上出现了增长的新苗头。

USENET(或 NetNews)是一个纯文本的社交讨论平台,或者说,是一系列的被称为“ 新闻组 newsgroup ”的讨论组,这些讨论组部署在遍布世界各地的服务器上。虽然其原始开发者在 2010 年 关闭 了他们的服务器,但那只是几百个服务器中的一个,在全球范围内,还有许多服务器运行得很好。USENET 并没有消失,它仍然活着,你可以免费加入,而且大多数操作系统都有协助你使用它的各种客户端应用程序。

尽管 USENET 是去中心化的 P2P 网络,但 Big-8 理事会仍是其最接近中央的管理机构。理事会成员 Tristan Miller 说:“我和 Jason Evans 在 2020 年 重建 了这个理事会,此后,Rayner Lucas 几个月后加入了我们。”

包括其他事项在内,理事会开始重新管理新闻组列表。他们应版主的要求删除了一些过时的群组,并添加了多年来的首个新新闻组,这是一个用于 Gemini 协议 的新闻组。如果你有新闻客户端,你应该可以打开 news:comp.infosystems.gemini。此外,理事会也对网站进行了全新改版,举办了 Reddit AMA(在线问我任何事)活动,更新了版主所用的 GNU Stump 和 WebStump 软件包等。

USENET 比万维网更早,并且它运行的方式更类似与电子邮件:服务器会保存一份新闻组列表,并与其他服务器同步信息。

(USENET 之所以走向衰败,其原因之一是人们发现了如何发布二进制文件的方式 —— 将其编码为多段的 ASCII 文本。它仍然存在 盗版问题,但你可以选择忽略。这也是互联网历史上 首次出现垃圾信息 的地方。)

连上 USENET 其实非常简单。你只需在 USENET 服务器上创建一个账户,安装一个客户端并告知它服务器地址。下载群组列表,选择订阅一些群组,新的消息便会传递到你的客户端,就这么简单。

The Register 的 FOSS 部门使用的是一个名为 “Eternal September” 的服务器,该名字源自当年 AOL 向其互联网客户端引入 USENET 访问功能,导致大量的网络新手涌入但不了解其规则的 事件。这里我们可以给出一条建议:请严格遵循 纯文本、底部回复 的电子邮件“网络礼仪”。

“Eternal September” 只有文本新闻组,不接受二进制文件,但它提供完全免费的账户。而另一些大容量的服务器如 EwekaGiganews 等则会收取访问费。

至于客户端 —— 如我们在新的 Thunderbird ESR 版本的介绍中所提到的,我们选用了 Thunderbird。它是免费的,易用,并能运行在所有主流的桌面操作系统上。当然,市面上还有许多其他的客户端可供选择。甚至 谷歌的网上论坛 都还在运营,尽管显得有些被忽视。

作为一位重度科幻读者,我乐于深入研究 rec.arts.sf.writtenrec.arts.sf.fandom 等群组。计算机历史群组 alt.folklore.computers 依然活跃。在一些复古计算频道中依然充满生机,我们也在这些频道中愉快地讨论了 Acorn RISC OS 和 Fortran 等诸多主题。

(题图:MJ/97691bbe-858c-47d2-b47a-b4ca460016d6)


via: https://www.theregister.com/2023/08/30/usenet_revival/

作者:Liam Proven 译者:ChatGPT 校对:wxy

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

这是运行在 AWS Firecracker 上的,当然,同时也有其他的新兴微 虚拟机 microVM 引擎可供选择。

在更换了 FreeBSD 内核中的排序算法后,其启动速度提高了 100 倍以上……虽然这是专门针对 微虚拟机 microVM 的优化,但所有人都应能从中受益。

过去五年,微虚拟机在科技研发领域中备受关注。其核心理念是重新包装和创新了 IBM 在 1960 年代随着 虚拟机管理程序 hypervisor 诞生所发明的 一些概念和技术:设计专门作为另一个操作系统上的访客系统运行的操作系统。这意味着该操作系统必须专门构建在虚拟机内执行,并与特定的管理程序提供的资源进行交互,而不是模拟硬件。

这就意味着访客操作系统几乎不需要针对真实硬件的支持,只需要 VirtIO 驱动,它们可以直接和宿主机的管理程序提供的功能进行交互。反过来说,管理程序无需提供模拟的 PCI 总线、模拟的电源管理、模拟的显卡、模拟的网卡等等。结果就是,管理程序本身可以变得更加微型和简化。

通过无情地缩减虚拟机监视器和运行在其内部的操作系统,这让两端都能更小、更简洁。意味着虚拟机能更少的使用资源,并能更快速地启动。

目前,这个商业目标是提供 “ 无服务器 serverless ” 的计算能力。实际上,“无服务器” 是一种市场双关语:当然,真实世界中的服务器仍存在于某个数据中心中。但这与提供“基础设施即服务(IaaS)”模型不同,而是提供“函数即服务(FaaS)”的模式。这就代表着你不需要了解任何有关基础设施的知识 —— 你的程序直接调用另一个程序,然后管理工具会运行所需的特定操作,返回结果,然后删除用于执行计算的虚拟机。你根本不需要知道这过程在何处,如何进行。

对消费者来说,这种技术的优势在于其快速和易用性。而对服务提供商而言,因为能够更快地回收和再利用资源,使得相同的硬件能服务更多的客户,这是一个巨大的优势。

AWS 通过一项名为 Lambda 的服务提供 FaaS,这个名称是来源于一个深奥的函数式编程术语。Lambda 由亚马逊自家研发的 Firecracker 管理程序提供支持,Firecracker 同样也支撑着 Fargate 这一无服务器服务。

Firecracker 基于 Linux 内核的内建 KVM 管理程序:这本身就有别于之前 AWS 基于 Xen 管理程序 的实践。这也就意味着它本质上是一个 Linux-on-Linux 的解决方案。这听起来对 FreeBSD 内核开发者 Colin Percival 来说像是一个挑战,正如我们 一年前的报道:他决定在 Firecracker 上运行 FreeBSD。然而就如同大部分的计算任务一样,优化的过程大致上是:首先,让它可以运行;然后,提高其运行速度。

根据他本周稍早的一则 推文,他最新的性能优化成果相当令人震惊:替换排序算法使 FreeBSD 内核启动过程加速了约一百倍,将内核加载时间降至了惊人的 25 毫秒。换言之,只有四十分之一秒的时间。

FreeBSD(HEAD)现已不再执行其 SYSINIT 上的冒泡排序。如今,我们运行的是更高效、速度大概快了 100 倍的归并排序:https://cgit.freebsd.org/src/commit/?id=9a7add6d01f3c5f7eba811e794cf860d2bce131d

当 FreeBSD 内核在 Firecracker (配备 1 CPU,128 MB 内存)中启动时,现在有大约 7% 的时间用于执行其 SYSINIT 上的冒泡排序。

当你需要对上千个条目进行排序时,O(N^2) 的复杂度可能会带来较大的影响。因此,是时候将冒泡排序替换为更高效的算法了。

这一调整只是一系列优化措施中的最新一个环节,两天后,他进一步 详细 阐述了这些优化。这包括了引导所需的初始更改:消除了假定在 Xen 下引导的一些初始化步骤,然后查询 ACPI 获取处理器的类型和数量。这一步出现了问题,因为 Firecracker 并未提供 ACPI。接着,对其仿真的唯一的硬件,串行控制台,进行初始化也失败了。

在内核成功启动之后,内存的使用迅速成为了一个问题:Firecracker 默认只给客户端分配了 128MB 的内存,原因在于一个必须修改的假设。之后是一整套的优化清单,每一项都为减少时间作出了一部分贡献。

即便你不是特别懂技术,阅读这篇文章也会很有趣。一些步骤更改了在专用硬件上引导的合理选择,在虚拟环境中,这些选择在机器产生、做工作、然后在几秒钟内再次被删除的情况下,已经无法适用。

Percival 评论 称:

我相信在相同的环境下,Linux 的引导时间是 75-80 毫秒,而我已经让 FreeBSD 在 25 毫秒内引导。

接着 说道:

当我开始研究提速引导的过程时,内核大约需要 10 秒钟的时间来引导,所以现在我拥有的内核引导速度,比我几年前快约 400 倍。

目前,已经优化的系统内核是 FreeBSD 14 版的,运行在 x86-64 架构上,但也正在进行适配到 Arm64 的工作 —— AWS 是世界上 最大的 Arm 服务器用户

Firecracker 是众多备受瞩目的微虚拟机中的一员,但也有其他的微虚拟机,而且它的成功也激励了 QEMU 开发者增加了一个 微虚拟机 平台。Canonical 的开发者 Christian Erhardt 在 博客 上介绍了如何在 Ubuntu 中使用这种技术,并且在线代码开发环境供应商 Hocus 最近 解释 了为什么它从 Firecracker 转移到了 QEMU 等价物。

我们可以看到微虚拟机有很多潜在的使用场景,不仅仅是在云场景中。能够在一个完全不同的 OS 上运行为另一个 OS 构建的单个程序,而不需要始终运行完整的模拟环境,可能在各种情况下都非常方便。

容器是一个非常有用的工具,但在容器中你只能运行与宿主 OS 相同的二进制文件。运行任何其他的东西 —— 比如在 macOS 上运行 Docker Linux 容器 —— 意味着有一些模拟和一个访客操作系统被隐藏在堆栈的某个位置。这个 VM 能够越小,并且使用的资源越少,无论是对容器还是整个机器的整体性能来说都会更好。

(题图:MJ/a5910e84-656d-4a5c-abad-bb0b0ffcb3fc)


via: https://www.theregister.com/2023/08/29/freebsd_boots_in_25ms/

作者:Liam Proven 译者:ChatGPT 校对:wxy

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

如果人们能停止争论谁算谁不算,那就会加倍了。

Linux 现在占据全球桌面操作系统市场略超过 3%,不包括 4% 多的 ChromeOS(虽然 ChromeOS 实际上 也是 Linux,但是它是“错误类型”的 Linux)。

Web 服务器统计聚合网站 Statcounter 上周宣布,截至 2023 年 6 月,Linux 占据 全球桌面操作系统使用量的 3%。然而,ChromeOS 的使用量仍然超过 Linux,这意味着 Linux 桌面占不到一半的 Linux 桌面市场的份额。如果你感到这话有点奇怪,那你是对的。

显然,Linux 桌面的使用量为 3.08%,落后于 ChromeOS 的 4.15%。问题在于,ChromeOS 实际上 也是 一种 Linux 发行版。它是一种奇怪的发行版,在几个方面不符合标准,它目前的版本基于 Gentoo Linux 构建,是几年前从基于 Ubuntu 转换而来的。

我们认为更准确的计算结果应该是,Linux 现在占据了 Statcounter 统计的使用数据的 7.23%,而 ChromeOS 占据了一半以上:总计 57.4%。这似乎是一个更积极的解释,Linux 粉丝应该会乐于接受,但显然事实并非如此。例如,Linux 布道网站 Linuxiac 在其报道中甚至没有 提到 ChromeOS。

(顺便说一下,我们怀疑 “未知” 类别下的 3.23% 操作系统很可能也是 Linux 用户,只是他们的极度谨慎遮掩了他们的用户代理或其他信息。)

为什么 ChromeOS 算进去呢?它是一个在标准 glibc C 库之上构建的 Linux 内核和 Linux 用户空间。你可以打开 Shell。如果你愿意,你还可以运行一个 Debian 容器,并在其中安装和运行任何 Debian 应用;我们的实验性 ChromeOS Flex 机器运行着 Firefox 和 DOSemu。

如果有人说 “安卓不是 Linux”,这还是有一定的道理的。你不能轻松免费地下载它,也不能在自己的通用个人电脑上运行它。尽管有一些实验性的基于安卓的桌面操作系统,但迄今为止它们都失败了。在其原生平台的智能手机和平板电脑上,你无法在安卓上运行普通的 Linux 应用程序。它是一种不同类型的系统,尽管从技术上讲,它是一个带有 Linux 内核的系统。但仅此而已。它甚至使用了奇怪的、非标准的、非 GPL 许可的 libc,名为 "Bionic"。默认情况下,除了内核之外,它没有任何其他类似 Linux 的东西。没有 Shell,没有桌面,没有 X11 或 Wayland,什么都没有。

但 ChromeOS 不是如此。在其独特的 GUI 层下(与 macOS 不同,它是 开源 的),它是一个相对标准的 Linux,可以直接在 x86 和 ARM 平台上运行标准的 Linux 应用程序。因此,它是目前最成功的桌面 Linux。

它不是典型的 Linux,因为典型的 Linux 是给怀有技术痴迷的黑客人群使用的工具,这种操作系统永远不会成为主流,除非有人强迫人们使用它。

ChromeOS 是一个去除了 Linux 特性的 Linux 桌面。没有关于分区的选择。没有奇怪的双启动机制。不用选择桌面环境或软件包管理器。甚至没有软件包管理器!

从重要的方面来看,ChromeOS 是一个主流、商业成功、精心设计的面向最终用户的桌面操作系统,而且它确实是一个 Linux 系统。

因此,自由开源软件(FOSS)阵营的力量自然对它充满敌意。当然他们愿意这么做。他们是如何表达这种蔑视呢?他们声称它不是一个“真正的 Linux”。

Unix 就像一种宗教:不知何故,它鼓励分裂和分散的派别,每个派别都否认其他派别的合法性。这几乎成了 Unix 的定义特征之一。

如果我们忽略所有商业版的 Unix,因为它们实际上都已经 不复存在,只关注 FOSS 阵营,有大约十几个竞争派别:NetBSD、FreeBSD、OpenBSD、DragonflyBSD、Minix、HURD 和 L4 及其 各种分派、Plan 9(9front、HarveyOS、Jeanne 等)、Inferno、xv6v7/86,当然还有 Linux 和数千个不同的发行版。

确切地说,只有 两个 基于 Linux 的操作系统在面向非技术用户的 GUI 系统中取得了大规模的商业成功。一个拥有 数十亿用户,另一个则有 数亿用户。它们都来自谷歌,并且都具有一个定义性的特征:自由开源软件(FOSS)世界拒绝接受它们。

ChromeOS 有两个版本:普通的 ChromeOS 只能通过购买专门为其设计的硬件来获得(就像苹果的 macOS 一样),而另一个是 ChromeOS Flex。Flex 过去被称为 Neverware Cloudready。Neverware 起源于 Hexxeh 对普通个人电脑 重新混编和重构 的 ChromiumOS。Hexxeh 开发了 ChromeOS Flow,它是 ChromeOS Flex 的直接前身:两者都是可以用在通用个人电脑硬件上的 ChromeOS。这是其中一个重要的方面,它表明 ChromeOS 就是又一个 Linux 发行版。

ChromeOS Flex 不像安卓。从重要的方面来看,它就是一个 Linux。它既是自由 开源 的,也有多个混编和重构版本。它可以在通用的具有普通 BIOS 或 UEFI(包括安全启动)的设备上运行。它有自己独特的桌面环境。你可以打开一个 Shell,并安装和运行任何任意的 Linux 应用程序。

外观上它看起来像一个 Linux,行为也像一个 Linux,并且像任何其他桌面 Linux 一样运行。它基于通用的 Linux 内核,使用与其他桌面 Linux 相同的 Linux 二进制文件执行 Linux 相关的操作。

它没有 systemd,但感谢伟大的 Torvalds 大神以及他的使徒圣·Cox,它还不是 Linux 发行版的要求。它使用的是 upstart,这是一种最广泛使用的初始化系统之一。

当某种特定形式的基于 Linux 的操作系统开始变得主流,并被 大约一半 的人使用时,Linux 世界的真正信徒们会放弃它,这完全符合 Linux 世界的特点。安卓不是 Linux。好吧,他们某种程度上是对的。

但是对于 ChromeOS,尤其是 ChromeOS Flex 来说呢?当然,所有的倡导者都会声称它不是真正的 Linux,但随之而来的很快就变成了一个“没有真正的苏格兰人”的争论。红帽族认为 Ubuntu 是垃圾,Debian 迷们认为其他一切都是垃圾,Arch 族认为自己是真正的前沿,Slackware 爱好者认为其他人都是新手,而 NixOS 的那些人则认为其他所有人仍然停留在某个石器时代……

(题图:MJ/3dcb3470-0b08-41bf-b826-be5afac57775)


via: https://www.theregister.com/2023/07/18/linux_desktop_debate/

作者:Liam Proven 译者:ChatGPT 校对:wxy

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