标签 openSUSE 下的文章

KVM虚拟机可以说在Linux中是一套十分成熟的套件。在suse中,它可以很简单的安装好,但好像又没那么简单。

首先是安装。有两个方式,但无论哪种,都先打开YaST吧。

第一种,控制中心有一个虚拟化专区,这里可以直接点击安装KVM选项即可进行全配件的安装。

另一种,打开YaST软件管理,进入到“模组”标签页。如果没有这个标签,可以通过“视图”按钮添加。在这个标签页下,直接勾选“KVM主机服务器”软件集——接受,等待安装完成就可以了。

现在,你可以打开libvirt这个图形化的虚拟机管理器了。但试试就会发现:虚拟机连不上网——这是我在slowroll下发现的问题。如果你在使用Leap 或者风滚草本草,可以试试是不是有相同的情况。如果有同样问题,那么就需要进行一些配置操作了。

原因其实很简单:防火墙阻止虚拟机的网络连接了。因此放开相关策略即可。但首先我们需要配置一下libvirt自己的防火墙策略:

  1. 用文本编辑器打开/etc/libvirt/network.conf
  2. firewall_backend = "iptables"最前面的注释符号去掉,保存

然后,配置系统防火墙。还是在YaST里:

  1. 打开防火墙组件
  2. 点击接口—自定义,弹出的窗口中,区域选择“libvirt”,接口输入libvirt 中的虚拟网卡名(默认应该是“virbr0”),确定
  3. 点开区域中的libvirt,确认右侧至少有dhcp、dhcpv6、dns、ftp、http、http3、https、imap、imaps、proxy-dhcp、telnet、tftp。至少目前我使用下来,允许这些就已经不会出现莫名连接不上的问题了。如果你有特殊的使用场景,也针对性的添加即可。
  4. 接受,保存防火墙配置。

到此,一个正常可以联网的KVM虚拟机套件就安装完成了。

openSUSE在Leap上启用了全新安装器,且舍弃了YaST。借着安装虚拟机的机会,来看看。

先解释一个问题:为什么要在suse里再安装一个suse虚拟机?一句话回答:需要一个纯净的系统,以便维护OBS仓库。
接着,给不使用suse的朋友简单介绍一下YaST是什么。


YaST界面

依然一句话概括:Windows控制面板在图形Linux中的实现。几乎你能想到的各种需要终端才好完成的设置,在这里可以图形化解决。
最后,来看看传统的suse安装程序是什么样。


旧系统安装界面

我的评价就是:典型的线性设定流程、高度的系统组件及环境自定义性、以及完全面向桌面设备的界面设计。

那么,如今的安装程序是什么样子呢?


新系统安装界面

这个安装器名字叫Agama,基于web技术实现。直接把鼠标顶到顶端就可以直观的发现,安装过程直接运行在火狐浏览器中。


指针顶到顶部,可激活火狐窗口功能

如此设计带来一个直接的变化:如果安装过程中需要访问互联网,可以直接新开标签页,而不再需要拿起另一个硬件来完成了。

但相对于传统安装器来说,新的安装器暂时没有老安装器那么高的自定义性,且弱化了线性设定流程,仿佛刚进入安装程序就已经可以直接点击安装来部署系统了。


概览页变可直接点击安装按钮,此时才会弹出未设定内容提示

就个人的使用体验来说,还原以前的自定义性都是次要,将必要步骤放在安装程序“必须设定”的流程中还是有一定的优化空间。

接下来,舍弃YaST这个操作。从社区讨论得知,有一个只有YaST自己使用的C++-Ruby绑定,维护的性价比很低。因此目前Leap的新版本已经舍弃了YaST图形界面,转而提供了梅林和Cockpit来部分替代YaST原有的功能。

但就我个人—可能也是一部分桌面版SUSE用户—来说,YaST可以说是openSUSE相比其他发行版一个最独特的优势。在我前面发布的内容中,评论就有提到SUSE跟红帽的功能存在一定重叠。舍弃YaST就SUSE来说,也许是可以降低相当成本的。但如此“降本增效”之后,进一步减少了同红帽的区别,那由此产生了一个问题:使用RPM包的发行版,为什么要选择openSUSE而不是红帽或其衍生呢?

不过,风滚草系列目前还是保留有YaST的。只能说希望在风滚草系列也完全去除YaST之前,SUSE能推出一个替代性的“控制面板”,以一定程度上维持SUSE这个独特产品吧——虽然可能性不大。

虽然现在存储价格不低,但这台电脑还是被我修好了。既然系统重装,那就又回到了一个老问题:该选哪个发行版?

滚动更新的发行版,更新频率高,但组件变化快,系统在一段时间内可能出现不稳定。而按版本发布的发行版,整体更稳,但在跨版本升级时,同样存在失败的风险。

那么,有没有一种介于两者之间的更新模式?既不过于激进,也不至于滞后。

你可能会想到 Manjaro。它基于 Arch Linux,会先对上游更新进行一段时间的测试,再推送到自己的仓库。

但它本质上并不是由 Arch 官方维护。在我有限的使用过程中,偶尔会遇到组件之间配合不够顺畅的情况。

如果从这个角度来看,一个更理想的前提是:发行版本身就同时提供滚动和版本两种更新模式。在这样的体系下,才有可能衍生出一种更“折中”的官方方案。

那么,这样的发行版存在吗?

确实存在。比如我之前提到过的 openSUSE。

而现在,它不仅提供两种模式,还进一步引入了一种更接近“又新又旧”的方案:Slowroll。

这个分支基于 openSUSE Tumbleweed 的滚动更新机制,但显著降低了更新频率。

通过官方给的示意图:

可以清晰的看出来Slowroll 以月为单位发布快照,每一次更新都整合了当月内通过测试的 Tumbleweed 变更。

这种方式带来的结果很直接:更新节奏被控制在一个更可预期的范围内,同时依然能够跟进上游的新版本。在稳定性上,也比 Tumbleweed 更进一步,并且避免了 openSUSE Leap 那种跨版本升级带来的潜在风险。

如此看来,Slowroll确实提供了一种介于两者之间的选择。

当然,需要说明的是,Slowroll 目前仍处于测试阶段。因此,这次把它装在这台电脑上,也算是对这个版本做一个长测。后续更细节更实际的体验,再慢慢记录。

转眼都到了2024年了。回看一下2023年,我居然发布了整整16个乱七八糟的内容,我实在太勤奋了。

那么,作为一个以类unix系统教程碎片为主的频道,在新年之际跟你分享一下2023年的一些变化。

更新频率降低的最主要原因就是莫名其妙的没有太闲着,而没有太闲着导致的结果就是很少打开家中常用的电脑,而不用家中电脑就意味着我这一年实际上很少使用Linux或者macOS系统。可以说,我在2020年换掉archlinux时候的预言在2023年得到了完美的体现。属实是:不是不报时辰未到。

但即使使用的频率很低,我还是将ubuntuunity更换到了Debian12。这可能是我这一年中最大的一个更改,这其中的具体原因我也有分享过,可以回看一下。

提到了乌班图,这让我想到了2023年乌班图的一个改变人生轨迹的变化:引入了基于flutter的应用商店。这项调整体现在了前几个月发布的乌班图23.10版本中,用以替代老朋友——乌班图软件中心。相对来说,新版本的商店有着更现代、更流畅、更一致的使用体验,可能也会助力乌班图全局snap化的布局。

可能你觉得使用flutter开发应用商店与全局snap化没啥关联,不过乌班图在2023年2月宣布,官方版本不再支持flatpak格式软件包开箱即用你又如何看待呢?很明显,乌班图为了推广并应用自己发布的snap格式软件包在自己的系统上不遗余力,撤销开箱支持flatpak可以说是最明显的一项措施。不过仅仅是无法开箱即用,你还是可以手动部署相关的程序以恢复flatpak支持。

顺带一提,即将推出的ubuntu24.04为长期支持版本也有一个新的变化,那便是它将可以获得长达12年的更新支持——当然,这需要你注册ubuntu pro。不过这项服务对于个人用户来说是免费的,如果你习惯并长期使用乌班图的话,安装这个版本并加入ubuntu pro也不失为一个好的选择。

你方唱罢我登场,与ubuntu所处的Debian分支相对的,则是RHEL分支中一个改变人生轨迹的变化:RHEL与2023年中旬宣布限制其源码访问。现在看来这个大概是转变CentOS性质的接续步骤:目前的CentOS完全可以说是RHEL的测试版,而曾经的CentOS则可以看作是RHEL的免费版。两者位置的变更似的RHEL可以将全部精力投入到企业客户上,而无需再考虑普通用户。这个消息在刚发布时反响剧烈,不过就目前来看,这更多的改变了RHEL下游发行版的生存轨迹,对于其他分支,甚至RHEL本身的企业用户来说,影响不大——暂时不大。

现在从发行版层面剥离出来,看看内核层面改变人生轨迹的变化:支持周期从六年缩短至两年了——我是说LTS内核。这个变化大概对用户来说影响不大,毕竟现在常见的发行版,要么像SuSE,不更新内核主版本,但自己长期单独维护,以至于跟用新内核没啥区别;要么就像Arch,有新的就直接给更新上来了。但支持周期的缩短对与内核维护人员来说可是重大利好——再也不用管理那么多没啥人用的旧版本内核了。

上面这些2023年Linux世界的变化是好是坏还请各位评判。不过,Linux版Steam使用率超过macOS,从哪种角度来看到可以算是2023年Linux世界一个不错的消息吧——当然了,这俩货加起来都追不上Windows的零头,不过,这至少证明Valve这几年在Linux游戏领域所做的不懈努力不是白费的——要知道,为了能让Linux运行Steam 中大多数的游戏,Valve从大概疫情前便开始基于wine来开发Linux 的游戏兼容层proton,并在这些年中取得了极大的进步。截止目前,Steam上热门游戏通过官方测试可以运行的已经超过了10000款,而根据玩家的测试,这个数量可以上升至大约17000款。我想这对于一名普通玩家来说已经不是一个小数字了。

但诚然,目前这个兼容层还不是十全十美:比如联网游玩的游戏,反作弊插件目前还无法正常运行。但车到山前必有路,由于Valve的proton套件是开源的,因此针对部分特定游戏,有个人开发者定制了proton套件,使得可以通过定制版套件达到正常运行带有反作弊插件游戏的目的。不过这些仍只是个例,Linux联网游戏任重而道远。

以上便是跟各位分享的2023年Linux世界的一些重大的、改变人生轨迹的变化。祝各位能在这曲里拐弯的人生中好好生活。

视频点此

Linux系统会为每一个用户建立一个home目录,其中有几个金刚路径,如桌面、文档、音乐、下载等等。通常来讲,在图形界面下使用这几个文件夹可能不会意识到什么问题,但如果使用终端的话,你也许会发现:在不同的发行版里,这几个金刚文件夹的实际名称可能是中文,可能是英文。也就是说虽然在图形界面下,文件夹名字显示为“桌面”,但实际上需要在终端中输入cd ~/Desktop才能进入桌面文件夹。这个是为什么呢?

这个问题——其实也不是问题。因为只是设置存在一些差异。

一、如果你是图形界面用户

以KDE为例,你可以发现在设置个性化-应用程序-位置项中可以随意定义这几个金刚文件夹的路径。因此如果想把中文路径调整为英文,直接输入即可。确定时按照提示,系统会自动完成文件夹的重命名操作。
另外,由于可以随意自定义,所以理论上如果你有长期挂载一个网盘当作本地扩容的分区,那么你也可以通过这个设置,把这个网盘当作某一个金刚文件夹对应的路径。

二、如果你是终端用户

这个文件夹映射关系保存在~/.config/user-dirs.dirs文件中,因此只需要修改对应的路径即可实现调整。但是需要注意,由于终端无法完成自动重命名,所以如果需要保留文件夹中的数据,需要在修改路径之后手工将原先的文件夹修改成对应的名称才能保证继续映射。

视频点此

如果你关注过一些国内的for Linux应用的话就会发现,它们之中很多都是通过网页版套壳实现的。对于一些有着非常完善的网页版应用来说,如此方法确实可以在很短时间内打造一款全平台兼容的本地化应用。对于这类操作,Linux下拥有一个小工具来实现——nativefier

这是一个纯粹的终端程序,一行指令即可将一个网页打包成一个全平台兼容的electron套壳应用。可以前往GitHub查看具体内容。这里只介绍基本用法。

一、安装

在很多发行版中都可以直接通过源来安装。对于openSUSE,直接通过opi nativefier即可搜索到对应的OBS源,添加安装即可。

对于源中没有这个软件的,或者Windows、macOS来说,由于此工具由nodejs编辑,直接使用npm install -g nativefier安装即可。

二、基本使用

在安装完成后,便可以直接使用了。

基础命令为:nativefier -n <打包后的应用名称> -p <程序兼容的平台> —-arch <架构> —- weight <窗口宽度> —-height <窗口高度> <网页URL>

如打包微信网页版:nativefier -n WeChat -p Linux ——arch x64 ——width 1024 ——height 768 https://wx.qq.com/

  • 如果想让程序可以后台运行,可以增加参数——tray
  • 如果不想在使用时可以调出chrome的开发者工具,可以增加参数——disable-dev-tools
  • 如果想控制程序在同一时间只能运行一个实例,则增加参数——single-instance

设置好参数后回车,第一次运行会自动获取一个electron的依赖,然后自动开始打包。打包完成的程序会放置在~/<应用名称>-<兼容平台>-<架构>/文件夹下。你可以直接在这个文件夹下执行二进制文件以启动程序,或自己编辑一个desktop文件,将这个打包好的程序“安装”到系统中运行了。