この記事は openSUSE Advent Calendar 2022 の22日目です。

ファイルマネージャーにDolphinを使ってるのですが、開いているディレクトリでコンソールを即座に使う方法を紹介します。

方法

F4を押す

以上です。

普通のDolphinはこんな感じでコンソールはありません。

F4を押すと下部に開いているディレクトリをカレントディレクトリにしたコンソールが表示されます。

もちろん、コンソールとして使えます。

ウィンドウズでアドレスバーにcmdと打つとコマンドプロンプトが立ち上がるの、地味にいいなぁと思っていて、同等機能を探していたら見つけました。

最近はPDFの表示などをDolphinからすることが多いので、その横にあるテキストファイルをcodeで開きたい、とかいう時に重宝しています。

（と思ったのですが、ファイルを右クリックで「Visual Studio Codeで開く」が出てきましたね・・・）

この記事は openSUSE Advent Calendar 2022 の21日目です。

openSUSE、というかKDEを使ってる方なら、手軽に外観をがらりと変えることが出来ます。

事実、僕は月に一回変更して、都度新しいイメージを楽しんでいます。

ではさっそく方法ですが、メニューから「設定」->「KDE設定」を選んでKDE設定を開きます。

その中から、「外観」を選びます。

ここからGlobal Themeを選ぶと、がらりとイメージが変わります。アイコン、起動時の画面、ウィンドウのデザインと変わるので、別OSになった気分です。

え？これだけ？と思われるかもしれませんが、ご安心ください。有志の方が作成された多くのテーマを右下の「Get New Themes…」から選ぶことが出来ます。

ドラッグすれば結構な数のテーマが表示されていきます。中にはvistaライクな外観も・・・

なお、上に表示されているように、openSUSEがレビューしたりしているわけではない、有志の作ということを留意してください。

たまに切り替え直後にアイコンが表示されなかったり（何かの拍子に直ります）、テーマによってはLibreOfficeのアイコンがみずらくなったりしてしまうのですが、元に戻すのも簡単ですのでぜひいろいろと試して新しい風をopenSUSEデスクトップに吹かせてみてください。

なお、自分のテーマを作成してアップロードすることもできますので、「俺の考えた最強のデスクトップ」をお持ちの方はぜひアップロードしてみてください。

この記事は openSUSE Advent Calendar 2022 の20日目です。

オンラインカンファレンスなどで広く使われてるZoomをopenSUSEで手軽に使おうと思います。

そう、もうおわかりですね。Flatpakで導入します。

Flatpakとはコンテナ技術をデスクトップアプリに応用したユーティリティで、隔離環境でデスクトップアプリを使うことができます。

つまり、ホストの環境に依存しないので、僕のようにあれこれしてしまっているホストでも安心して使うことが出来ます。

まず、Flatpakがインストールされてなければインストールします。

sudo zypper in flatpak

そして、Flathubという、パッケージのリポジトリを登録します。

flatpak remote-add --user --if-not-exists flathub https://flathub.org/repo/flathub.flatpakrepo

登録したらアップデートを行います。

flatpak update

後はFlathubの公式ページ通りにすればすべてOKです。

Zoomのインストール

flatpak install flathub us.zoom.Zoom

Zoomの起動

flatpak run us.zoom.Zoom

これだけで比較的新しいバージョンのZoomを使うことが出来ます。

僕の所にパッケージで入っていたZoomがあったのですが、ある日「バージョン上げないとログインできないよ」と出てしまい、さっと思いついたのがFlatpakの利用でした。確か、30分後にZoomが必要、な時で、ちょっと焦ったのを覚えています。Flatpakを抑えておくと、こういう時に助かったりします。

また、skypeもslackもdiscordも、僕はFlatpakで快適に運用しています。

隔離環境のため、ローカルファイルとの連携などに多少流儀がありますが、環境を気にせず使える利点はありがたいです。いずれ、Flatpakを深堀してみたいと思います。

第四世代の Intel CPU を使ったマシンで openSUSE を使っていると、シャットダウンコマンドで電源をOffにしようとしても( poweroff など)電源が切れません。一旦切れたようになりますが、再度起動してしまいます。この動作は、なぜか Windows と BSD (Dragon Fly BSD)では起こらず Linux のみ起こる現象のようです。 openSUSE 意外に Debian でも現象を確認しています。

色々調べたのですが、正解にはたどり着けず、毎回手動で電源を落としていました。そうすると、マジックパケットを飛ばして WOL による起動ができなくなり、ちょっと不便に感じていました。

結局、Kernel の詳しい人に正解をいただきました。Grub のオプションに
xhci_hcd.quirks=0x2000
を付けるのだそうです。これでちゃんと電源が切れ、さらに WOL も動くようになりました。

この記事は openSUSE Advent Calendar 2022 の18日目です。

systemd が使われるようになると、daemon の制御とかのやり方は大きく変わりました。/etc/init.d にあるスクリプトから、systemd パッケージに含まれるコマンドを使うようになってきました。それらのコマンドは、xxxxxctl という、末尾に ctl が含まれるものが多いように感じました。そこで、/usr/bin/ の中にある、末尾が ctl なプログラムがどんなものかを簡単に調べて見ることにしました。

今回は、wdctl を紹介します。

コマンド名: wdctl
パッケージ: util-linux-2.37.2-150400.8.8.1.x86_64
動作: ○

wdctl は、システムのウオッチドッグ情報を表示するコマンドです。引数なしで起動すると以下のように表示します。

% wdctl
Device:        /dev/watchdog0
Identity:      Software Watchdog [version 0]
Timeout:       10 seconds
Pre-timeout:    0 seconds

オプションによって表示形式を変更することは出来ますが、基本的に上記のような情報を表示するだけです。ですので、あまり使い道はないかと思います。

この記事は openSUSE Advent Calendar 2022 の15日目です。

CombustionはMicroOSのプリメイドイメージをプロビジョンしてくれるスクリプトです。

ここ数年でMicroOSのプリメイドイメージのプロビジョンソフトが移り変わったので、紹介させて頂きます。

cloud-init

cloud-initはもともとUbuntuのクラウドイメージのプロビジョンソフトウェアでした。MicroOSは初期の頃対応していました。今はOpenStack用のプリメイドイメージ専用になっています。

ignition

CoreOSのプロビジョンソフトウェアで、JSONで記述した設定ファイルを使います。

MicroOSは今もignitionに対応しています。MicroOSのignitionのwikiはこちらです。

Combustion

MicroOS専用のプロビジョンソフトウェアです。スクリプトを書くことで、かなり柔軟な設定をすることが出来ます。dracatモジュールとのことですので、追っていろいろ見てみたいと思います。Combustionのwikiはこちらです。

この記事は openSUSE Advent Calendar 2022 の14日目です。

大分遅くなりましたが、先月、自宅のopenSUSEを15.4にアップデートしました。なお、SLES15 サービスパック3（Leap 15.3のベース）は、2022年12月でサポートが切れる（セキュリティパッチの提供などが終了する）ので、皆さん15.4にアップデートすることをおすすめします。

さて、15.4にアップデートしたところ、emacsを起動した時に初期設定が反映されなくなりました。

そこでXDDCのもくもく会で力を貸して頂いて対処したので、書いてみます。なお、最終的な解決までには至りませんでした。

結論

/usr/share/hunspell に、ja_JP.affとja_JP.dicを配置する（中身は何でも良い）

症状

emacsを起動しても初期設定が反映されない

*Messages*に以下のメッセージが表示されている

ispell-find-hunspell-dictionaries: Can’t find Hunspell dictionary with a .aff affix file

教えてくださった方法

Ubuntuの開発者の方に、まずstraceでemacs.d/init.el読んでるかみてみたら？と教えて頂きました。

strace -f emacs > strace.log

straceはシステムコールやシグナルをトレースするプログラムです。

このログをinit.elでgrepしても、ヒットしませんでした。なので、そもそもinit.elを読んで無いようです。

どうやら、メッセージにある通り、hunspellの起動が失敗していて、init.elの読み込みまで進んでないようです。

それでhunspellでログをgrepしていると、/usr/share/hunspell/ja_JP.affと/usr/share/hunspell/ja_JP.dicを読みに行く跡がありました。

そこで、/usr/share/hunspell/en_US.affと/usr/share/hunspell/en_US.dicをそれぞれコピーして/usr/share/hunspell/ja_JP.affと/usr/share/hunspell/ja_JP.dicとして配置した所、無事init.elを読み込みました。

hunspellは日本語チェックをする事はないので、このファイルがあることは問題にならないのですが、回避策にしかならないですね・・・

hunspellはどうやらLANGの値を見ているらしく、以下のように起動するとエラーなく起動できました。

LANG=en_US.UTF-8 emacs 

hunspellがLANGの値を見る所を探っていけば、根本解決までいけそうですね。