2023-09 このところLAN 内の利用についてローリングリリースを色々試しています。
Debian、Ubuntu 系についてもちょこっとだけ試してみたのでその印象・概観です。詳しいお試しリポートではありません。
なお、Debian のローリングリリース版については 2023-06 の Chap-13. Debian と一部重複します。
以下の記述中ではローリングリリースのことを RR などと表現しています。
2023-11-18:ローリングリリース系をギークっぽく使うのは無理筋なので、そっち系利用は考えないことにしました。
Sec-１．Debian-unstable 版
Sec-２．kali、Siduction 等の Debian-unstable 派生
Sec-３．Ubuntu 直系の RR 版らしい mantic (snapshot-RR)
Sec-４．Ubuntu 系の RR である Rhino Linux
Sec-５．Xubuntu の mantic 化（ RR 化)
Sec-６．余談
Chap-13. に書いているので一部重複です。
この版はセキュリティパッチが流れてこなくて、しかも２年のサイクルのうち数ヶ月程度コードフリーズがあります。
その時点では重大な事象（セキュリティーホールが見つかったとか、大きなバグが見つかったとか・・）に対応が難しそうです。
なので、個人的印象ですがその時期（コードフリーズ時期）だけは利用を避けたほうが無難です。
Debian のサイトでも一般利用を想定していない風の書き方だったと思います。テストと開発用。
Debian の良い点の一つに情報提供が割合と適切です。なので「これ、一般利用を考えると具合悪そうだなあ・・」なんて判断が出来ます。ここまでちゃんと情報提供しているのはとても良いことです。
普通に考えれば Debian-unstable の持っている「一般利用にはいささか具合の悪い部分」すなわちコードフリーズ期間中にはおそらくバグ等の事象に対応できそうにないという点を引き継いでいるだろうと想像されます。なので本家 Debian のコードフリーズ時期は利用を避けたい。
ただし、もしかしたら派生ディストリ独自に何か対応できるように算段を考えているかもしれません。なので決定的に「まずい」とも判断しにくい。
これら派生ディストリのサイトにはその点について何も情報提供がありません。
結局のところ「良さそうとは判断できない」という曖昧な評価、よくわからない評価になります。
Distrowatch の Ubuntu のところで、一番左にある版です。表示では Rolling になっています。その表示が、これが RR なのかどうか判断する唯一の情報源です。
2023 初春頃にこの存在に気が付きました。早速ネットで検索してみましたが Ubuntu rolling で出てくるのは Rhino ばかりで mantic (snapshot-RR)に関する情報は何もありません。本当に RR なのかどうかよく分からない。でも多分そうなんでしょう、笑。
これを評価する上で Debian-unstable の派生なのか、独立系 RR なのかが重要なポイントだと思います。「Debian-unstable の派生そのまんま」だとコードフリーズ時のセキュリティ対策の問題があります。独立系で本当に RR ならその問題はとりあえず無しとなります。
そこでパッケージのバージョン番号を見てみます。
Rhino と mantic はパッケージのバージョン番号が酷似していますが、mantic と Debian-unstable は微妙にバージョン番号が違います。特に大事な点として、mantic の方が Debian-unstable よりバージョン番号が新しいものも散見されます。
そこから考えると、どうやら独立系 RR らしいです。言い切る自信は無いですが、もしかしたらイケてる版かもしれません。もしかしたら・・・
6月始めにノートパソコンを買い替えて面白そうなのでこれをインストールしました。約三ヶ月に渡り、これまでのところ何も不具合も無く快調に動いています。安定性は良好です。リポには security や updates もあるのですが、実際に流れてくる更新は updates や security は無くて main 系ばかりです。RR っぽいです。
安定性は Rhino よりこっちのほうが良いと感じました。
2023-11 本当にローリングリリースだと仮定するとギークっぽい使い方には向かないと思います。が、この Ubuntu はリビングで Windows っぽく使います。ギーク風には使いません。なのでローリングリリースモデルであるなら、ありがたいと思います。
2024-06
この版は2023年の冬頃に更新エラーが出てしまってチェックを諦めました。順調に24.04とか26.04 とか上がっていくのかどうか確かめることができなかったということです。
個人的にローリングリリースモデルへの興味が 2023-11 頃に失せてしまったので再挑戦はやりません、汗。
基本的に Ubuntu-mantic と似たような評価を私はしています。ただ、安定性は Ubuntu-mantic より多少劣るようです。少し。
2023-07頃に Ubuntu-server (22.04LTS) を mantic 化しようとしましたが、うまく行きませんでした。
その時の mantic が 23.10 相当。22.04 から 23.04 等を飛ばしていきなり 23.10 に上げるのは無理だったようです。
そこで今回は Xubuntu-23.04 を使ってこれを mantic (23.10 相当）にあげてみましたが、大体においてうまく行きました。
やり方は簡単です。
これだけです。これで Xubuntu のローリングリリース化は出来上がったはずです・・・よう知りませんけど、笑。
Ubuntu-server のときと違って何もエラーメッセージが出ずに更新が済みました。リブートしてもまあまあ普通に動きます。安定感では Ubuntu-mantic と特に違いを感じません。
自分はやっていませんが、Lubuntu、Kubuntu も同じようにやるとローリングリリース化できそうに思います。保証はしませんけど、笑。
なお、Ubuntu-mantic や Rhino と同様です。自信を持って「独立系 RR なのでセキュリティ上の問題も無い」と言い切れるわけじゃないです。なんとなく言えそうなんだけど・・・まだ分からない、笑。
snapd
ここ最近、Ubuntu については mantic(snapshot-RR)、Xubuntu-23.04( RR 化)、Ubuntu-server(22.04-LTS) をいじりました。
このうちサーバはもちろん無駄な snapd を削除しました。DE版については Ubuntu-mantic は snapd を削除して使い、Xubuntu-23.04( RR 化)については snapd が入ったままお試しを続けています。
＊サーバで snapd を削除したときは以下の具合でした。
# systemctl disable snapd.socket # systemctl disable snapd # systemctl stop snapd.socket # systemctl stop snapd # systemctl mask snapd.socket # systemctl mask snapd # apt remove snapd # apt-mark hold snapd # reboot
これで次回から snapd なしのサーバになります。そもそもサーバで何故 snapd が入れてあるのか理解できませんね。
＊Ubuntu-mantic で snapd を削除したときは以下の感じ。
# snap remove firefox # systemctl disable snapd.socket # systemctl disable snapd # systemctl stop snapd.socket # systemctl stop snapd # systemctl mask snapd.socket # systemctl mask snapd # apt remove snapd # apt-mark hold snapd # reboot
これで次回から snapd なしになります。削除した firefox は後から flatpak を有効化してこれでインストールしました。
＊Xubuntu-23.04( RR 化）ではそのまま snapd が入った状態でお試しを続けています。したがって firefox は snap 版です。
他のパッケージを入れるときはすべて # apt install hoge で入れています。なので snap 版は firefox だけです。
＊firefox は snap 版でも flatpak 版でもあまり違いを感じません。どっちでも良さそうです。
つまり DE 利用なら snap が入った状態で使っても、snap を削除して使っても、どっちでも良さそうに思えます。(snap 版は firefox だけという前提ですが）
apt upgrade、apt dist-upgrade
今までこの2つの使い分け、あまり真剣に考えてきませんでした。長く使っていても、いい加減です、汗。
今回、以下の URL を参考として調べてみました。著者さん、御礼申し上げます。
https://penpen-dev.com/blog/upgrade-tigai/
版が変わるときを例にして簡単に書きます。現実よりも少し物事を簡素化して書きます。
旧版
bbbbbccc
新版
AAABBBBB
これで apt update、apt upgrade すると
BBBBBccc
になるようです。ようですって、いい加減な表現ですが、笑。
この後、リブート後に apt update すると「まだ更新できるパッケージがある」って表示と「以下のヤツは不要なので auto autoremove せよ」って表示が出ます。
apt list --upgradable すると更新漏れのパッケージ名が例えば hoge1、hoge2、hoge3 と表示されます。これは apt upgrade では入らないので
apt upgrade hoge1 hoge2 hoge3 と明示的に指定します。それでインストールされます。
つまり
AAABBBBccc
の状態になります。
更にこの後、apt autoremove するとようやく
AAABBBBB
の状態になって版のアップが完了します。
で、上記 URL によれば更新にあわせて後の2つの作業をいっぺんにやってくれるのが dist-upgrade らしいです。つまり新規追加分もちゃんとインストールしてくれて、不要なヤツはちゃんと削除してくれる。
なるほど・・・笑。
なので、個別のパッケージを上げていくだけで良い時は apt upgrade 使って、版を上げる時は apt dist-upgrade やるのが良いってことらしい。
(dist-upgrade やってもしも削除もれとかあったら apt autoremove しましょう)
ただし、水をさすようですが apt upgrade で新規パッケージがインストールされることも現実にはあります。新たに依存関係で必要になったとか、何か理由があるのでしょう。
なので上記の説明は物事を簡素化して概念的に説明しています。