Chap-24. openSUSE(leap) を試用

試す事柄
 2024-09:
 以前の leap はコミュニティベースでした。コミュニティーベースの時代はバグフィックスやセキュリティフィックスが遅れがちな印象で、良いイメージは持っていませんでした。
しかし、最近は SLE(業務用・サーバ用OS)をベースにして tumbleweed のパッケージを部分的に使える(インストールできる)ようにしているらしい。既に業務用OSベースに移行完了しているようです。そうなると、バグやセキュリティ対策はコミュニティベースの時代よりかなり良くなっていると想像されます。
 また、これまで SUSE はじめ mandriva、mandarake からフォークしたディストリ全般で emacs の挙動が不審でした。日本語IMとX端末を組み合わせると、おかしな誤作動をして使い物になりませんでした(mageia、openmandriva 等も同様)。が、今回SUSEについてはどう対処すればその問題を回避できるか知りました。emacs がまともに動かなかったのは、私が SUSE を避けていた一番の理由でした。
晴れて emacs がまともに動くようになったことだし業務用OSベースに移行して良くなっただろうし・・・ここでは SUSE のうちの固定リリース系 leap についてリポートします。

 かねてから、私は以下の見方で各ディストリを眺めています。また、これに加えてギーク系趣味を前提とした見方をしています。

Sec-1.インストール
Sec-2.インストール後、最初に試す事柄
Sec-3.Windows 代替としての利用(ATW)
Sec-4.全般としての印象



Sec-1.インストール

 インストーラは GUI で、それを使って一般的な GUI のシステムにも、CUI のサーバ向けシステムにもインストール出来ます。
クリックする箇所に注意するだけ。そこは Debian、Slackware 等と同じで好印象です。
UNIX ライクシステムとして管理するやり方は、GUI に入れても CUI に入れても同じです。この点も好印象です。
GUIについては GNOME で試しました。




Sec-2.インストール後、最初に試すこと

 例によって普通の UNIX マシンらしく管理・設定ができるか、以下の項目を試しました。ギークぽい使い方前提。
ちょっとだけクセを感じましたが、基本的に大丈夫です。

*NetworkManager を選んでおけば、IPアドレス等の管理は Debian と全く同じです。
*rc.local の動かし方も Debian と全く同じです。
*パケットフィルタは nftables が使えます。問題無いです。
*デーモン管理も systemd 前提なので Debian と全く同じです。
*GUI インストールした場合も、CUI インストールした場合も、特に管理上の違いはありません。
*各種コンパイルのために入れる必要のあるパッケージについては、Chap-7. に書いておきます。全て問題なくコンパイル・インストール出来ます。

 シリアル回線について
 シリアル回線を使ってルータの制御をやるなら、com ポート増設用のカードを刺した方が良さそうです。USB-RJ のケーブルを刺したら Debian と同様にハングアップしました。ダメです。
com ポート増設カード経由で /dev/ttyS* を使えばルータにつながって制御できました。ただし、ttyS4、ttyS5 の2ポートでした。Debian だと ttyS0、ttyS1 です。どの番号に割り付けられるか、ここはディストリによって差がでます、笑。
なお、パッケージの cu(uucp) はうまく動きませんでした。野良コンパイルした uucp-1.07.tar.gz の方は調子良かったです。

 開発系の野良コンパイル・インストールについて
 Debian だと lua に関しては野良コンパイルしたものが組み込みにうまく使えません。組み込みっぽく使うなら Debian 付属のパッケージ(今だと liblua5.4-dev )を使う必要があります。
一方で suse は自分で最新版(今なら lua-5.4.7)を野良インストールしても、うまく組み込みに使えるようです。この点は SUSE の方がちょっと使いやすい。

 rc.local は自分でサーバソフトを野良コンパイルして使うようなことがない限り、不要だと思います。

Emacs の設定について
 最近のディストリだと普通は個人設定ファイルを $HOME/.emacs.d/init.el とします。しかし suse ではこれはうまく行きません。
emacs をインストールすると自動的に $HOME/.emacs というファイルが出来ますが、これは一旦削除。
その後で、個人の設定ファイルを $HOME/.eamcs として保存します。他のディストリのように $HOME/.emacs.d/init.el ではありません。
こうすることで emacs + 日本語 IM + X 端末で使ったときの変な誤作動を防ぐことが出来ます。
ポイントは、システムが勝手に作る $HOME/.emacs を最初に綺麗サッパリ削除することでした。





Sec-3.Windows 代替としての利用(ATW)

 このセクションもあまり書くことがありませんが、特徴を並べてみます。

*** プリンタの設定 ***
 ドライバ等のインストールは Chap-32. の Sec-3. または Sec-4. で対応できます。Sec-4. でいくなら cups-devel をインストールします。
Sec-4. でいくなら postfix パッケージを予め入れておく必要はありません。
プリンタ登録は Sec-5. です。

*** スキャナ ***
 Yastでスキャナ設定をすれば、シンプルスキャナでも Xsane でもスキャンできます。これで LAN(wifi)経由でスキャナが使えます。



Google-chrome のインストールは以下のような具合です。

まず
https://www.google.com/chrome/
を訪問する。

*ダウンロードをクリック
*64bit(For Fedora/openSUSE) を選ぶ
*クリックするとダウンロード開始。
*「YaSTで開くか?」と聞いてくるので Yes
*インストール続行、実行
*途中、「壊れている」と出るが、無視して続行。
*それでインストールが完了して、無事に動く。

2021-08 補足
 Flatpak の利用については、Chap-31.を見てください。



2021-07 補足
 ディストリ固有のVLCを使って、市販DVD再生してみます。
Chap-31.に書いたようにFlatpak を利用してVLCをインストールすると、おそらく簡単に再生できると思います。でも、ここではディストリ固有のVLCにcodec を追加インストールして、市販DVD再生を試みます。

 1)まずディストリのVLCをインストールします。
 2)次にcodecパッケージのダウンロードとインストールです。パッケージをダウンロード出来るサイトは「Linux libdvdcss download」と検索すると簡単に見つかります。以下のサイトです。

https://pkgs.org/download/libdvdcss 

このサイトのSUSEをたどっていくと、

https://download.videolan.org/pub/vlc/SuSE/Tumbleweed/x86_64/libdvdcss2-1.4.2-2.7.x86_64.rpm

にあるのがわかります。これをダウンロードするだけ。(上記URLをブラウザのURL欄に貼り付ければダウンロード出来ます)
codec をインストールするのは、ダウンロードした libdvdcss2-1.4.2-2.7.x86_64.rpm を置いたディレクトリで

# zypper in ./libdvdcss2-1.4.2-2.7.x86_64.rpm

とするだけです。これで必要 codec がインストールされます。
以下、ディストリのVLCで市販DVDが再生できます。




Sec-4.全般としての印象

 3つの視点で評価します。
   視点a. ・・・十分安定していて、インターネットサーバで運転しても問題ありません。
   視点b. ・・・こちらも優秀です。Geek 風に使うのも十分対応できそうです。各種コンパイル作業も簡単です。
   視点c. ・・・割合とたくさんのパッケージがあるようです。イケると思います。

*アップデートでおかしくなることはありません。リポは安定しているようです。
*世間では Debian-stable、Ubuntu-lts ほどの評価ではないと思いますが、安定感は十分あります。
*サーバ運用でもそれなりにいけそうに思いますが実績(サーバ利用のユーザ)は少なそうです。
 (後で知ったことですが、2017 年頃から富士通が SUSE をサポートしている様です。実際は SLE でしょうけど。)
*業務OSがベースの固定リリースなので、セキュリティホール等が発見されても適切な対応があるだろうと想像されます。ここはコミュニティ時代よりずっとマシだと思います。
*このディストリとか Manjaro にありがちな事ですがディスプレイが時々茶色っぽくなります。この欠点はなかなか治らないです。KDEだとDEの中で修正できます。でも GNOME だとハードウェア(つまりディスプレイの設定)でしか修正できません。AMD のマシンで発生するのかもしれないですが intel のマシンではどうなのか、うちでは試せません。



 SUSE って設定をいじったりしたとき、他のディストリに比較してリブートする頻度が高い。マメにリブートしたほうが良いって意味です。
 CUI で更新をやるのが好みにあう自分にとって、SUSE の packagekit はちょっとうっとおしい。CUI での更新を邪魔しちまいます。
しかも、# systemctl disable packagekit と # systemctl stop packagekit をやっても、次に電源入れると、また packagekit デーモンが立ち上がっていて、しつこい!
どうやら、# systemctl コマンドで disable、stop、mask をやると、もう立ち上がらなくなるようです。
しつこい packagekit が嫌いな人は試してみてください。
 コミュニティがなんとなくふわふわした印象なのですが、そんな風に感じるのは私だけだろうか?
素早く上流側の更新を入れなければならないはずのローリングリリースで、セキュリティ対策に逆行するようなスローロールを始めてみたり・・・
はたまた、RedHatベースのクローン・プロジェクトに参加してみたり・・・
一体どこに行きたいのか意味不明なコミュニティです、笑。
SLEベースってのはかなり良好な方向性です。余計なことをしないで、この道一本で進んだほうが良いと思うのですがね・・・
配布物は良好だし低評価する気はありませんが、このコミュニティは行動パターンが気まぐれに見えます。
もっとも「気まぐれ」なんて言葉を私が発すると、どの口が言ってるんだと揶揄されそうですが、笑。




一つ前・・・・www.quinos.net/htdocs/topico/topico.02.html
二つ前・・・・www.quinos.net/htdocs/topico/topico.01.html