视频点此

可以说unity桌面是我正经使用Linux后最早接触的桌面环境，也可以算是我最习惯使用的桌面环境之一。而关注unity或者ubuntu的朋友可能知道，ubuntu从18.04开始，其默认的桌面环境切换回了gnome。但在2020年出现了由一个印度小兄弟领导发布的ubuntu unity，旨在提供回原生的unity桌面体验。所以在我发现这个发行版之后，我便在unity的吸引下重新装回了放弃多年的ubuntu。但最终，我还是把ubuntu给换掉了，今天就来简单聊聊其中的原因。

一、优势

无论如何，ubuntu可能也是用户数量相当高的一个发行版，因此很多网上Debian系发行版的教程、可以搜索到的疑难解答实际上都是参照乌班图的软件仓库进行编写的，这样一来在日常使用过程中就可以有相当方便、快捷的网络支持体验。同样的，由于使用人数众多，如果一个软件想兼容Linux，那么一般来说最先得到官方适配的基本就是ubuntu无疑了。

此外，ubuntu背后有公司存在，且基于Debian衍生，所以在寿命、稳定性方面可以信任。除了LTS版本提供更长时间的支持之外，还可以加入ubuntu pro计划以获得更长的维护支持。且如果个人使用的话，这个还是免费的。

更多优势我就不说了，老生常谈。最主要的是我为什么最终换掉了它。

二、劣势

原因只有一个：snap。
Snap是ubuntu自己推出的一种软件包形式，且已经融合在ubuntu中。随着snap的逐渐完善，Ubuntu也在逐步降低对deb软件包的支持力度。而官方更是给出了将在23.10版本中加入snap商城，可能后续加入的应用程序会优先提供snap形式，再适时加入到apt仓库之中。
Snap的优势算是比较明显的，简单来讲就是类macOS组织形式，应用之间相互隔离，依赖版本冲突可以得到很好的解决。
但一个比较致命的问题：snap的服务器在国内没有镜像站点。
是的，即使不使用Linux的朋友都可以猜到个大概了：虽然可以建立连接，但速度太慢了。更不用说时不常的还需要检查并更新snap应用。这很难让人很难坚持下去。

此外，由于snap在程序启动时候相当于建立了一个虚拟的系统环境，这使得程序的启动速度相对传统的方式会减慢不少——当然，可能是因为我的Linux分区还是使用机械硬盘的缘故，如今固态硬盘这个影响可能已经不明显了。

但建立虚拟的程序环境意味着一个问题：系统所有的配置应该都可以映射过去，这样才能保证使用的过程中不会出现什么奇异的问题。但目前的snap分明没能完全顾全这一点。比如我的chrome下载文件默认的保存位置是一个轻易找不到的路径，我当时为了这个路径研究了半天文件夹之间的映射关系。如果是一个没有发现相关规律的用户使用的话，那对snap版本的chrome可能只有一个评价：这个chrome下载会把文件下丢。
另一个比较影响使用的情况：输入法。在我使用的这段时间中有两种经典情况：输入法候选列表不展示、根本无法唤醒中文输入法。这个不多解释，想想就能知道对于中文用户来说，这种程序在使用的时候会有多麻烦。

可能会有朋友说ubuntu还有其他的一些问题，比如版本号更新经常性的更坏掉、经常性的报告系统错误弹窗之类的。但这些是ubuntu在使用snap格式软件包之前就存在的一些问题。既然选择了ubuntu那么说明这些经典问题已经考虑过了，相较于unity，还是unity更香一些。但真的使用起来，发现snap异味完全覆盖过了unity的清新。

当然，snap这些问题可能也是因为unity没有完全适配好，官方版本不会出现。诚然，可能官方对snap的支持会更全面一些，但国内镜像站点不存在就是不存在，而且官方使用gnome桌面，我能有什么特殊的理由一定要选择ubuntu呢？

视频点此

深度更新了Deepin15.5版本之后，增加了面容识别功能。对于其他发行版，有没有可能拥有呢？这就是今天要介绍的开源程序：howdy。

如果你在深度论坛中大概浏览过的话就会发现，有些人认为深度的人脸识别功能就是将howdy内置到系统中实现的。具体怎么做的我在这里就不深究了，不过我们可以通过howdy在其他发行版中增加人脸识别这一功能。

安装在大多数发行版中都是十分简单的，我们可以参照howdy的GitHub介绍来完成：

• 对于Ubuntu系：添加ppa源，然后通过apt安装即可
• 对于Debian系：从GitHub的release界面下载deb包安装即可
• 对于Arch系：通过aur安装即可
• 对于Fedora：启用CPOR源，然后通过dnf安装即可
• 对于openSUSE：通过opi，自动添加OBS源并安装即可

但是在实际安装过程中，我的openSUSE15.3出现了一些依赖问题，所以对于这个系统，需要进行一些额外的补充。

缺少的依赖是python3-opencv3，我们选择忽略依赖继续，将howdy包先装好。此时，howdy的部分功能是可以使用的，但最核心的识别功能不可用，所以还是需要对依赖进行补全，直接通过opi来安装即可。推荐在查询结果中选择science这个官方性质的OBS源使用，避免后期不必要的问题。

接下来就是对howdy进行配置，让howdy知道这台电脑的人脸识别设备——也就是摄像头——是哪一个。

1. 使用文本编辑器打开/etc/lib64/security/howdy/config.ini
2. 查找device_path一行，将等号后面的none更改为摄像头设备的路径
   a. 安装v4l-utils，这个包可以直接安装
   b. 使用命令v4l2-ctl --list-devices查看设备
   c. 记录摄像头名称对应的路径，填入配置文件即可
3. 保存

现在，就可以尝试添加一个面容数据了。

1. 使用命令sudo howdy add
2. 根据提示随便输入一个模型名称（不能超过24个字符）
3. 面向摄像头，让它认识你
4. 你会看到“Added a new model to 你的用户名”，这就代表完成了

这时，通过sudo howdy list就可以看到刚刚录入的脸部模型了。当然，howdy也提供一些管理模型的参数，具体可以查询GitHub的介绍。

最后，就是将人脸识别加入到密码认证的步骤当中了。对于openSUSE来说，虽然不是howdy要求的依赖，但必须安装一个叫pam-python的包才能将howdy与认证联系起来。但在openSUSE15.3中，又不存在这个包，所以需要手工安装一下。

1. 进入openSUSE官方的包搜索工具
2. 搜索pam-python，选择ALL Distributions
3. 进入搜索结果中，找到openSUSE Leap 15.2，点击official release中的Expert Download
4. 打开的页面中，点击Grab binary packages directly，下载不带.src的一项
5. 双击下载的文件安装

到此，这个负责认证的包就安装好了。接下来，就是将人脸认证接入。

相关文件全部在/etc/pam.d中，根据需要增加语句即可。这里以使用sudo命令时进行人脸认证为例。其他命令使用人脸的方法一样，只是调整一下编辑的文件即可

1. root权限打开sudu文件
2. 在文件最开始增加人脸认证语句
   auth sufficient pam_python.so /usr/lib64/security/howdy/pam.py
3. 保存

此时，当使用sudo命令时，摄像头便会启动，尝试识别人脸。如认证通过，则正常执行命令，否则弹出密码输入要求，我们可以通过密码来进行认证。

不过对于openSUSE来说，使用sudo时候默认请求的是root账户密码，因此人脸也是请求的root账户的人脸。但刚刚howdy录入的人脸是我们这个账户的人脸，所以我们可以通过howdy指定用户录入功能录入root人脸信息，也可以通过修改sudoer文件，将请求的密码改成当前账户即可。

视频点此

曾经有一个半个钟头的视频，大概演示了一下如何在Optimus模式的笔记本电脑上实现英伟达显卡的虚拟机直通，后来又用了一个视频简单说了说如何在Linux中安装KVM虚拟机以及一个简单的图形界面。不过得益于KVM虚拟机在Linux上面的优异表现，KVM虚拟机的图形界面程序也算是层出不穷。这其中不乏观感不错、使用简单的图形界面程序。今天就来看一个，我认为可以当作是virtual box平替的KVM图形界面程序——Quickgui

简单来说，quickgui是quickemu和quickget的一个图形化前端，而quickemu是简化qemu建立KVM虚拟机的一个终端脚本。因此与virt-manager等KVM图形化管理器差异的地方，在于quickgui侧重于帮助用户根据选择的系统和自身电脑的配置一键配置好一个可用的KVM虚拟机，并统一管理已经建立的KVM机器。在这个过程中甚至不需要用户事先准备安装镜像文件。那么接下来就看看如何安装。

就像前面说的，quickgui是quickemu和quickget的前端，因此首先需要安装好这两个。前往quickemu的github，可以看到对于arch用户，可以通过aur直接安装，而乌班图用户则可以添加它的ppa并完成安装。但我现在用的是opensuse，就需要手工来安装了。

在quickemu的页面里写了所需的依赖，其中要求QEMU版本需要在6.0或更高。但openSUSE官方源中，其版本刚刚到达5.3，所以首先需要做的就是升级QEMU。

1. 直接打开终端，输入opi qemu，在弹出的源列表中选择Kernel:tools，然后按照提示更新提供方，完成。
2. 打开YaST的软件管理模块，切换到模组标签，找到KVM主机服务器，将右侧打勾的版本全部切换到刚刚添加的源上（如有），确定。

到此，QEMU版本的升级就完成了。

如果你是全新安装的openSUSE，可能还有一些依赖需要你去补齐。可以按照github的指引进行安装，或者先按照下述步骤安装好quickemu与quickget尝试运行，失败的话再查看依赖问题。

1. 克隆quickemu到一个文件夹：git clone --depth=1 https://github.com/wimpysworld/quickemu
2. 全局安装quickemu到系统：sudo update-alternatives --install /usr/local/bin/quickemu quickemu /path/to/quickemu 50，其中，/path/to/quickemu为刚刚保存了克隆工程的文件夹，其中可以找到quickemu这个脚本
3. 将quickget全局安装到系统，命令同2，只是将所有的quickemu更改为quickget

到此，你应该可以直接在终端中使用命令quickemu或quickget来直接调用这两个脚本而无需再进入到保存的文件夹中执行了。这也意味着我们已经建立好quickgui所需的基本环境了。接下来就是安装quickgui

• 前往quickgui的github，下载最新发布的预编译包，解压到某个目录下

进入这个目录，双击quickgui，一个好看的管理界面就正常启动了。

它的功能非常简单：管理已有的机器与建立新机器。初次使用时，可以通过新建机器功能快速建立一个KVM虚拟机。而且这个建立只需要我们选择好需要的操作系统版本和保存路径，点击下载，软件便会自动下载并部署好，等待启动。待下载完成，切换到管理已有机器的界面，便可以看到刚刚创建的虚拟机了。

管理界面也很简洁，只有三个可以操作的功能：启动、停止、删除。如果你是arch 或者乌班图用户，此时应该可以通过启动按钮直接简单的打开这个虚拟机了。但对于openSUSE，你会发现无法正常显示虚拟机窗口，再等待一会儿就恢复到了启动前的状态了。这是为什么呢？

因为openSUSE的QEMU默认不到有fd文件——KVM的efi程序，同时已经不再支持sdl模式运行。所以我们需要针对这两个进行调整。

首先，补全fd文件。

1. 前往https://www.kraxel.org/repos/jenkins/edk2/下载对应你的电脑架构的rpm包
2. 无需安装，直接找到其中保存了fd文件的文件夹，将这堆fd文件解压到/usr/share/qemu
3. 将其中的ovmf_VARS-pure-efi.fd重命名为ovmf_VARS.fd

到此，fd文件我们就补齐了。

当然，只从rpm包中解压出ovmf_VARS-prue-efi.fd也是可行的。这里全部解压只是为了方便而已，也为了避免之后特殊需要时候再次补充。

对于sdl支持，我尚未找到什么好的解决方法，所以我目前的方式就是通过终端来启动构建好的虚拟机。

1. 进入到创建虚拟机时选择的保存路径，应该可以看到对应这个虚拟机的conf文件
2. 使用命令启动虚拟机：quickemu --vm 配置文件.conf --display gtk

到此，我们便成功构建并打开一个KVM虚拟机了。

视频点此

这一晃，上班都一年半了，我所有的电脑——除了MacBook——就像我之前那个讨论archlinux与opensuse的视频里所说的那样，全都上到opensuse了。不仅如此，还陆陆续续的“维护”了一些我自己用到了，但尚没有人在opensuse的源中提供的软件。在这个过程中，Leap也从15.2过渡到了15.3。虽然版本号只提了0.1，但其变化是异常巨大的。但今天，我不细说它的变化，而是来谈谈我自己认为安装好15.3后必须做的几件事儿。

首先，禁用debug和source源。我只是一个普普通通的用户，并不会debug，也不关心程序代码。所以这两个源对我来说是毫无用处的。因此首先就把这两个源给禁用掉。直接前往YaST的软件源模块，将所有debug和source条目的自动刷新和启用勾选去掉即可。

在这里，你也许就会看到一个奇特的地方：相同名字的源会有两个，其中一个带有update标记。其实就是你想的那样，openSUSE把源分成了基本和更新两类。其中，基础源是不会很频繁的更新的，所有组件的更新全部通过update源来提供。因此自动刷新基础源是没有什么意义的。所以，还是在软件源这个模块，将基础源的自动刷新关闭。

到这里，对源的优化就算是完成了。

由于SUSE是实体组织的原因，很多专有软件无法直接通过这些源来提供，因此很多时候我们需要通过一个叫做packman的源来安装。但经过这段时间的使用下来，我发现packman包含的软件数量还是比不了其他发行版——可能是我使用的软件比较刁钻？所以我更多的会使用obs源来安装这些软件。obs提供浏览器版本的安装途径，但总是莫名其妙的搜不到想要的内容，所以想要完美使用obs的软件，还是借助一类似aur助手的终端工具：opi。直接通过YaST的软件管理工具安装即可。

准备工作做好，接下来就是一些我自己需要的基础组件了。首先，与其他非实体组织发布的发行版不同的地方在于SUSE初始不会带有专有解码器，默认情况下不能播放常见的音视频。因此首先就要安装解码器。还是在软件管理，打开到视图—源—packman，点击修改软件包版本到packman，确认即可。

我自己依然需要英伟达的专有驱动。因此回到软件源模块—添加—社区软件源—nVidia Graphics Drivers—确定。待刷新后前往软件管理，会自动勾选出需要的驱动，直接确定等待完成即可。如果没有自动选择，直接搜索nvidia，选择适合自己的x11-video-nvidiaGxx安装即可。一般使用G05应该不会出什么意外。

为了实现简单的双显卡切换，直接安装suse自己的切换模块suse-prime以及托盘程序suseprime indicator。如此我们便可以方便的在托盘右键来选择使用哪一块显卡了。

最后，由于我跨越三大操作系统在使用，所以我的移动存储设备全都是exfat格式的，但suse不会自带这个格式的驱动。因此额外再安装exfat-fuse，到此一个openSUSE便完全方便日常使用了。

视频点此

如果你需要在Linux中使用Xbox one无线手柄，那么这个软件包或许可以帮助到你。

当然如果你用的是最早的xbox手柄，或者有线连接Xbox one使用的话，那么在Linux下面是可以开箱即用的。唯独对于蓝牙或者接收器方式连接会出现问题。这时我们只需安装一个包：xpadneo。这是针对Linux平台的xboxone开源驱动，我用了很长时间了，通过steam的手柄设置来分配游戏中按键是很完美的，游戏用的延迟也非常低，是一个完全可以使用的开源驱动。

直接去往它的GitHub，就可以看到安装教程。如果你想的话，直接全部下载，然后终端执行./install.sh即可。但如果你跟我一样习惯于通过包管理器统一管理的话，那对于arch用户，直接通过aur即可安装，opensuse用户，通过opi搜索xpadneo，选择不带后缀的选项，再选择home:FrauHolle源即可自动安装。ubuntu好像可以通过apt直接安装。待安装完成，重启，便可以通过蓝牙正常连接xboxone手柄了。

第一期、第二期

前两天收到了这么一条私信。

这倒是提醒了我一个很早就想分享的一个小技巧，如何简单的使用不对应自己发行版的安装包程序。但在这之前想先跟各位铺垫一些内容：Linux安装包，或者说，一个二进制程序的安装包实际上在做什么。

macOS软件的安装过程能更好地展现。打开一个下载好的安装包，会看到一个应用程序图标和一个applications文件夹。

安装程序的话，只需将应用图标拖到applications文件夹上面，然后我们就可以在访达的应用程序文件夹下看到这个应用。在macOS中，应用程序文件夹的路径是固定的/Applications, 而安装程序的applications文件夹图标下面有一个快捷方式的小箭头，查看它的属性的话就可以看到，它指向的就是我们电脑中的应用程序文件夹(关注下图原身指向的路径)。

到此就可以看出，macOS应用的安装过程其实就是把应用复制到了应用程序文件夹中。而如果我们右键应用程序—显示包内容，还可以查看这个应用所拥有的各种文件。因此总的来说，macOS应用的安装过程其实就是把这个应用程序的文件夹复制到了一个指定的位置而已。

由此，我们可以类比一下Windows的安装程序。它与macOS的过程其实是一样的，只不过Windows允许用户自己选择应用程序的这一堆文件要复制到哪里，然后自动帮用户进行复制操作（当然，对于Windows，安装程序可能还需要进行注册表编辑的操作）。

那么Linux的安装包呢？

由于Linux更多的是在用包管理器进行操作，所以Linux用户可能很少去关注应用的下载和安装这两个前期过程。这时我就要推荐你去看看我之前的使用obs和aur分发软件包的内容了。

你理解了这个就能明白，Linux无论是包管理器还是手工下载的安装包，其软件安装过程与Windows和macOS依然是一样的。只不过使用包管理器安装，全程不需要用户手工干预，而使用下载的安装包安装，最多也只需要用户手工进行下载的过程而已。

不过，虽然Linux安装的过程本质上也是在往系统中复制文件，但与另外两个系统不同的是，Linux会把不同职责的文件放到对应职责的文件夹中，而且对于被很多程序共同需要的文件，Linux很可能会把这个文件当作一个单独的程序，就不再附加在其他程序的安装包中了。也就是说，Linux是以文件功能为视角来归类文件而不是以应用来归类，这就使得一个应用的文件会被放到多个文件夹中，且可能需要配合安装其他的一些共有组件包才能让程序正常运行。而这种互相关联的情况，就是平时提到的依赖。

但并不是只有Linux有依赖问题，windows同样存在，只有macOS才近似于没有。而Linux比较明显的原因就在于它把文件归类得太细致了。举个现实中不存在的例子：假如说三大操作系统都有dx组件，且现在需要安装的软件要求系统中有d3dx9_25才能正常运作。那么对于linux来说，我除了要安装这个软件之外，可能还需要另行安装一个名字叫d3dx9_25的软件才能实现运行；而windows虽然也需要安装dx的安装包，但它的dx安装包里边会包括了d3dx9_1至d3dx9_30所有的文件；至于macOS，d3dx9_1至d3dx9_30系列文件可能会直接包括在macOS的操作系统中打包提供，或者直接包括在了程序的安装包中，总之不会要求用户再另行安装一个其他的软件。而假如之后又有一个程序需要使用d3dx9_20，windows由于前一次安装时已经部署了dx系列所有的文件，它就不会再要求额外安装了；但linux还需要再额外安装一个包括了d3dx9_20的软件才能实现运行。由此让用户感觉：哇，Linux依赖问题太麻烦了。

为了不让用户自己解决上面这种额外安装的问题，Linux出现了包管理器这种东西。自然，为了顺应不同的包管理器，就产生了不同格式的软件安装包。但万变不离其宗，安装程序的本质依然是在复制文件进系统，没有太多麻烦的事儿，所以手工部署一个程序是可实现的。相对于包管理器来说，我们要解决的仅仅是如何手工组织文件，以及依赖问题。接下来，就以粤政易为例，实际尝试一下手工安装一个应用程序。

根据私信的描述，粤政易本身提供了.deb形式的安装包，但其使用的archlinux中没有对应的软件包可以使用。因此，唯一的突破口就是官方提供的.deb安装包了。

直接下载deb包，通过归档管理器打开——这个可能是Linux和macOS相对于Windows安装包又一个优势所在：前者的安装包仅仅是一个压缩包，因此可以直接用归档管理器打开查看。

可以看到其中包括的文件，这也是一个Debian安装包的基本构造。我们现在是为了可以手工安装，所以这里直接顾名思义，选择最靠谱的data.tar.xz——数据tarball打开。

如果你使用Linux的话，这两个文件夹应该就眼熟了起来。

这里普及一个可能是冷门的现象：对于粤政易这类国内Linux应用来说，普遍都没有完全遵循Linux的打包思路将文件分别归类，而是有些偏向macOS的风格，将一个应用所有需要的文件都放在了同一个文件夹，然后安装时全释放在/opt的程序文件夹里就算完成了。所以对于粤政易，直接将这个data包里opt中的粤政易拿出来，你便可以开始运行这个程序了，到此，整个手工安装过程也就完成了。

但对于一些较为遵循打包方法的应用，单独解压出来没法使用，怎么办呢？

只需要在程序文件夹执行一个命令：

ldd 二进制文件名

你便会得到一个完整的引导。箭头左边指出了这个应用需要的so文件，箭头右侧则给出了这个so在系统中的具体路径。这时只需要寻找右侧为空的so，来对应安装包含这些so的软件包，补全即可。

到此，无论是什么样的软件包，你应该都通过手工部署完成安装了。