クリップボード履歴-antiX-linux

2025/11/03
antix にはデフォルトで、clipit というクリップボード履歴ソフトがインストールされていますが、機能が限定的です。
copyQというフリーウエアのクリップボード履歴ソフトのほうが使いやすいので、インストールしてみましょう。

インストール
sudo apt update
sudo apt install copyq

# IceWMのstartupファイルを編集
nano ~/.desktop-session/startup

# 以下の行を追加
copyq &
これで再起動しましょう。

LinuxとWindowsのクリップボード挙動の違い

LinuxとWindowsのクリップボードの挙動の違いを理解しておくといいです。

Windowsの感覚でLinuxを操作すると、特に戸惑いやすいのが「コピーしたはずなのにペーストできない」「FIFOのように感じる」といった現象があります。
Linux(正確にはX Window System)が持つ**複数のクリップボード(セレクション)**の仕組みに起因しています。

Windowsのクリップボードは基本的に「1種類」です。`Ctrl+C`(または「コピー」)でデータが格納され、`Ctrl+V`(または「貼り付け」)でそれを取り出します。常に「最後にコピーした1つのもの」だけが保持されます(履歴機能は別として)。

一方、LinuxのGUI環境(X Window System)では、主に2種類のクリップボード(セレクションと呼ばれます)が並行して動作しており、混乱しがちです。

+2種類のクリップボード(セレクション)**

項目PRIMARY (プライマリ)CLIPBOARD (クリップボード)
概要選択即コピー明示的コピー
コピー操作テキストをマウスで選択(反転)した**だけ**で、自動的に格納されます。`Ctrl+C` キーや、メニューから「コピー」を明示的に実行した時に格納されます。
ペースト操作マウスの**中ボタンクリック**で貼り付けられます。`Ctrl+V` キーや、メニューから「貼り付け」を実行した時に貼り付けられます。
Windowsとの対応なし(Linux/Unix特有の文化)Windowsのクリップボードとほぼ同じものです。

+なぜ「FIFO」や「意図しない貼り付け」が起きるのか**

この2つのバッファは**別々に内容を保持しています**。

たとえば、以下の操作をしたとします。
1. ブラウザで「A」というテキストを `Ctrl+C` でコピーします。(`CLIPBOARD` に "A" が入る)
2. 次に、ターミナルで「B」というテキストをマウスで**選択だけ**します。(`PRIMARY` に "B" が入る)

この時点で、`CLIPBOARD` には "A" が、`PRIMARY` には "B" が入っています。
  1. この状態で...
  2. `Ctrl+V` を押すと: `CLIPBOARD` の内容である "A" が貼り付けられます。
  3. マウスの中ボタンをクリックすると: `PRIMARY` の内容である "B" が貼り付けられます。
ユーザーが「最後に操作したのは "B" の選択だから "B" がペーストされるはず」と思って `Ctrl+V` を押すと、古い "A" が出てきてしまい、「FIFOのようだ」「コピーしたはずのBがペーストできない」と感じることになります。
あるいは、無意識に中ボタンをクリックしてしまい、意図しない `PRIMARY` の内容(直前にたまたま選択していたテキスト)が貼り付けられることもあります。

+「プロパティの値」がコピーできない件について**

これはクリップボードの仕組みの問題ではなく、**アプリケーション(GUIツールキット)側の実装の違い**です。
  1. WindowsのUIは、ダイアログボックス内の「プロパティ値」のような静的なテキストラベルでも、比較的コピー操作を許容するように作られていることが多いです。
  2. Linuxのアプリケーション(特にantiXで使われるような軽量なGTK+やQt以外のツールキット)では、それらの値が「単なる表示ラベル」として扱われ、テキストとして選択・コピーする機能が実装されていない場合があります。
これはデスクトップ環境や使用するアプリケーションの設計思想によるもので、Linuxだから一律でコピーできない、というわけではありません(GNOMEやKDEの標準アプリではコピーできることも多いです)。

★antiX23での日本語入力設定(決定版)★

2025/11/03
antiXでの鬼門といわれる、日本語入力。(日本語表示は全く問題ありません)
私としては、かなり突っ込んで調べたので、これで少なくとも バージョン23.2 においては大丈夫だと思います。
知ってしまえば、設定は簡単です。

runitのデスクトップ12種で動作することを確認しています。
よくよく考えれば、IceWM,JWM,Fluxboxに分岐するまえの、~/.desktop-session で設定しているので、全部に効くはずですね。

※2025/11時点の情報です。

理屈は不要、手順が欲しいという方はこちら

深謝
antix linuxで中国語入力と日本語入力を切り替えできるようにする
VirtualBoxにAntix入れて日本語環境用に設定する俺用メモ(2)
antiX 19 〜超軽量・軽快 ・・日本語化を含む設定の難易度が高いantiXがDebian 10.1 Buster baseとなってリニューアル!・・インストール・初期設定・日本語化を極める!
Windows 10サポート終了に備える:antiXへの移行と安全対策ガイド
antiX-19 で日本語入力をする設定にチャレンジ【完全版】

antiX runit 日本語IMEをスムーズに導入しましょう

技術的要点

  1. 日本語入力をしようとする各アプリケーションは、環境変数でメソッド名(ibus,Fcitx5等)を取得し、それに見合ったツールキット(プラグイン)を自分の中でロードし、ibus/Fcitxと通信する体制を整えます。
  2. 物理キーが押下され、Xサーバーがそれを受け取って、アプリ(GTK/QT)に渡します。
  3. アプリ*1はD-Busアドレス に接続し、D-Busを通してIMサーバ(ibus/Fcitxデーモン)と通信します(双方向)。各テキスト入力欄(widget)ごとに「Input Context(入力コンテキスト)」を作って通信します。
  4. D-Busは、プロセス間通信一般に使われるソケットのようなもので、高速な通信経路ですが、そのD-Busセッションアドレスをお互いが知って、同じセッションアドレスを通して通信する必要があり、そのセッションアドレスを知らせるための環境変数が、DBUS_SESSION_BUS_ADDRESSです。
  5. 日本語入力に関しては、ibus/fcitxデーモンと、アプリ(GTK/Fcitx)が同じD-Busアドレスを知る必要がありますが、自動的に同じアドレスを知るのではなく、設定によってうまく知らせる必要があります。
  6. DBUS_SESSION_BUS_ADDRESSをシステム内で一意に正しく設定する必要がありますが、antiXの場合、WM(window Manager)とFM(File Manager) が枝分かれして起動していくので、うまく設定しないとD-bus経路(アドレス)を2つ作ってしまい、WMとFMが、異なるD-Busセッションアドレスを扱ってしまうこととや、D-Bus経路が一本であってもDBUS_SESSION_BUS_ADDRESSが、WMとFMとで異なるという不整合が起きる場合があります。
  7. 枝分かれ不整合がある場合、アプリは、枝分かれしたどちらかのプロセスから起動されたかによって、把握するDBUS_SESSION_BUS_ADDRESSが異なることとなります。WMから起動された場合(例:タスクバーからの起動)と、FMから起動された場合(例:デスクトップアイコンからの起動)で、異なるDBUS_SESSION_BUS_ADDRESSがアプリに伝わることとなるからです。
  8. アプリが把握しているDBUS_SESSION_BUS_ADDRESSとIMデーモン(ibus/fcitx)が一致しているほうは通信が成功しますが、食い違っているほうは通信が失敗し*2、日本語入力ができない状態となってしまいます。
  9. 確実に効く設定は「~/.desktop-session/desktop-session.conf(4つの環境変数設定)」+「~/.desktop-session/startup(IMデーモン起動)」の組み合わせです。これでWMとFile Managerrが枝分かれする前にD-BUSデーモンを稼働させてDBUS_SESSION_BUS_ADDRESSを設定し、枝分かれ後にD-Busデーモンが再度起動されることを抑止することで、システム全体で一意のDBUS_SESSION_BUS_ADDRESSを共有することが可能となります*3
  10. antiX(desktop-session)では、Debian標準の im-config 流儀(~/.xinputrc と /etc/X11/Xsession.d/*)の環境変数が使えません。なぜなら仕組み上、必要な環境変数がGUI セッション「全体へ一意に」到達しないからです。
よって概念的には「ENV(環境変数) は desktop-session.confで設定、IMデーモン起動は startup」に一本化するのが最短・最安定の解となります。
IM方式(環境変数GTK_IM_MODULE/QT_IM_MODULE)と通信経路アドレス(環境変数DBUS_SESSION_BUS_ADDRESS)を適切にアプリに伝えるために、最低3つの環境変数を適切にセットする必要があるわけです。

D-Busアドレスでの通信ができない場合、そのままでは日本語入力ができないこととなりますが、その場合にはアプリ側(GTK/QT)からフォールバックし、全く別の古い方式(=XIM方式)で日本語入力することを試みます。このときの(バックアップの)方式を設定するのが、環境変数XMODIFIERSです。例えば、XMODIFIERS=@im=ibus と設定しておくと、D-bus通信が失敗したとき、D-busとは異なる古い経路を使って通信することができます。ただし、これは古い方式であり、①アプリ側でXIM方式に対応していなければフォールバックしないし(最終的に失敗)、②フォールバックしたとしても、アプリ内のインラインでの表示ができず、ポップアップボックスの中で入力・変換したうえで一気にアプリに伝える形式となるので、人間にとってはストレスのある入力作業となります。

上記から、現代で使う高速道路(D-Bus)を使うための3つの環境変数、そして古い旧道を通る方式にフォールバックするための環境変数の合計4つを適切に設定する必要あり、そのうちのひとつ(DBUS_SESSION_BUS_ADDRESS)はD-Busデーモンを先に動かさないと決まらないので、設定と同時にデーモンを稼働させる(厳密にはデーモン稼働後にすぐに環境変数が設定される)こととなります。
  • xterm (旧道しか知らない)
GTK_IM_MODULEは見ない。XMODIFIERS(旧道)のみを見る。
結果: ポップアップ入力(XIM)が成功する。
  • leafpad (古いGTK 2 / フォールバックする)
GTK_IM_MODULE=ibusを見る。D-Bus接続(高速道路)に失敗すると...
フォールバックする → XMODIFIERS(旧道)を見に行く。
結果: ポップアップ入力(XIM)が成功する。
  • Chrome (モダンなGTK 3/4 / フォールバックしない)
GTK_IM_MODULE=ibusを見る。D-Bus接続(高速道路)に失敗すると...
フォールバックしない(諦める) → XMODIFIERS(旧道)を無視する。
結果: 日本語入力が完全に失敗し、英字入力のみになる。


そしてもちろん、ibus/fctxデーモンも稼働させおく必要がありますが、これは、configファイルではなく、startupで起動させます。

ibus-daemon と d-bus-daemon の前後関係は、先にd-bus-daemonが起動することで確実にibus-daemonに環境変数DBUS_SESSION_BUS_ADDRESS)を渡すことができますが、ibus-daemonが、d-bus-daemonより先に起動した場合でもibus-daemonの仕様として、d-bus-daemon起動後にXウィンドウから自力で、d-busアドレスを拾ってくる仕組みがあるので、ibus-daemonが先起動でも日本語入力はできるということです。しかし、その仕組みに頼るのは危険なので、やはりibus-daemonは、d-bus-daemonの後に起動するようにしておいたほうがトラブルは少ないと思われます。

入力メソッドとアプリ側の受け側仕様

入力メソッドには、ibus(堅牢・質実剛健型)、Fcitx5(柔軟、使い勝手を変更できる)の2種類があります。ibusはRedhat主導で開発され、Fcitx5は中国人コミュニティ中心に開発されたそうです。

一方で、アプリ側仕様も、GTK方式とQT方式の種類があります。アプリによって異なります。

アプリ側GTK/QTとibus/Fctxデーモンが通信するために、D-Busデーモンが作る経路(DBUS_SESSION_BUS_ADDRESS)を使う、ということとなります。

日本語変換エンジン

ibus/Fctx5は、Mozcという変換モジュールと通信し、日本語への変換は、Mozcが担当します。
ibus/Fcitx5は、GTK/QTからキー押下情報(元々はXサーバーから受け取ったもの)を取得して、Mozcに渡し、Mozcが変換したものを受け取って、GTK/QT(アプリ)に返すこととなります。

私は、ibusの挙動が好きなので、ibusで使っています。

windowsだと、MSIMEとかATOKとかのIMEがありますが、おおざっぱにいえて、windowsIME = linux(入力メソッド(ibus,Fcitx5等) + 日本語変換(Mocz等)) という関係になります。
(QTかGTKかは、アプリで隠蔽されています)
入力メソッドと変換エンジンについてはこちらがわかりやすい

*1 : 厳密には、D-Busに接続する主体はGeanyやChromeといった「アプリ」そのものではなく、アプリが起動時に環境変数(GTK_IM_MODULE)を読み、GTK(UI部品)がim-ibus.soのようなIMモジュール(プラグイン)」をロードします。D-Busに接続し、ibus-daemonと直接会話(プロセス間通信)するのは、この「IMモジュール」です。

*2 : システム的には応答がないだけなので失敗とは思っていない

*3 : 個人的感想としては、デフォルト設定のantiXでのD-Busデーモン起動タイミングが遅いと思う。またOSにプレインストールされているfirefoxやleafpadは、DBUS_SESSION_BUS_ADDRESSによってD-Busアドレスが伝わらない場合、自分でXサーバーのプロパティから「強引に」D-Busアドレスを参照するようです。

環境

項目内容
ディストリantiX23 Linux(runit)
対象IBus + Mozc / Fcitx5 + Mozc
antiXコントロールセンタから設定すれば、より簡単ですが、きちんと?処理できるよう、あえてシェルからの導入としています。

概要

下記の2つのファイルに、日本語設定をします。
設定ファイル設定項目
~/.desktop-sesshion/desktop-session.conf環境変数の設定+Dbus設定
~/.desktop-sesshion/startupIMデーモン起動の設定

手順

パッケージ導入 ibus,fcitx5の両方をインストールしておきましょう。

sudo apt update
sudo apt install -y ibus ibus-mozc ibus-gtk ibus-gtk3 ibus-gtk4 fonts-noto-cjk
sudo apt install -y fcitx5 fcitx5-mozc fcitx5-frontend-gtk3 fcitx5-frontend-qt5 fcitx5-config-qt
ここから先は、設定ファイル、startupファイルを書換、追記します。
ファイルの変更方法は様々ありますが、antiXコントロールセンタ→(左メニュー)セッション→ユーザのデスクトップセッション、からファイルを選択するのが楽だと思います。
※ここで間違ってIceWM設定の編集、とかに入らないように。ファイル名が同じでもディレクトリ名が異なれば、全く違う設定箇所となります。ここでは、デスクトップ全体設定(初期の設定)変更となります。

環境変数(*ここがキモ*) — ~/.desktop-session/desktop-session.conf

desktop-session.conf の「ファイルの一番最後」に下記の追記をします。
.xsissionとか他のディストリビューションで使われる設定ファイルではうまくいきませんのでご注意ください。公式もこのファイルで設定するように言っています。

ここではibusで設定しますが、Fcitx5としたい方は入れ替えてください。

~/.desktop-session/desktop-session.conf
# ibus をローカル変数に代入
im_module="ibus"
#im_module="fcitx5"

# 環境変数に代入(展開)
export GTK_IM_MODULE=$im_module
export QT_IM_MODULE=$im_module
export XMODIFIERS=@im=$im_module

# WMでの Dbus-deamon起動を禁止(ここでDbus-deamonを起動させ、環境変数も設定)
DBUS_SESSION_LAUNCH="false"

#下記の実行で、環境変数 DBUS_SESSION_BUS_ADDRESS がセットされる
eval $(dbus-launch --autolaunch $(cat /var/lib/dbus/machine-id) --sh-syntax --exit-with-session)
DBUS_SESSION_LAUNCH="false" については80行目付近に、true で先行代入されているのでそれをオーバーライドです。80行目付近をfalseに書き換えることでも構いません。
このDBUS_SESSION_LAUNCHをfalseにしておかないと、非オープンソース版Chromeなどでトラブルが発生します。(これに気がつくのに時間がかかりました)

IMデーモン起動 — ~/.desktop-session/startup

startupファイルで、IMのdeamonを起動、常駐させます。以下をファイル末尾に追加。
Fcitx5を選択する場合は、ibusをコメントアウトして、fcitx5の # を外してください。

## すでに動いていれば何もしない(-d)、見えない(-x)、再接続(-r)
## ibus か fcitx5かどちらかを選択
ibus-daemon -drx
#fcitx5 -d &

再ログイン後の検証

printenv | egrep 'GTK_IM_MODULE|QT_IM_MODULE|XMODIFIERS'
ibus engine   # ← mozc-jp が返ればOK

構造の要点(im-config が効かない理由の整理)

/etc/X11/Xsession.d/70im-config_launch は Xsession フェーズで ~/.xinputrc を読み込み、XMODIFIERS/GTK_IM_MODULE/QT_IM_MODULE などを export する。
・ しかし antiX の desktop-session は**独自セッション起動**のため、標準 Xsession の export が IceWM/アプリへ届かないケースがある。
・ また antiX は軽量化思想により「IMデーモン自動起動」を行わない。startup にて明示起動が必要。
・ よって、**desktop-session.conf(ENV)+ startup(デーモン起動)** を正として運用する。

ありがちな失敗と対処

症状主因対処
トレイに「あ/A」やキーボードが出るが日本語へ切替できないENVが空(GTK_IM_MODULE 等が未設定)desktop-session.conf の3変数を export 付きで定義→再ログイン
im-configでFcitxを選んだのに入力不可ENV=fcitx5 なのに startup が ibus-daemon 起動startup を fcitx5 -d & に統一
Qt アプリだけ入力不可Qtフロントエンド不足IBusなら ibus-qt、Fcitx5なら fcitx5-frontend-qt5 を導入
文字が豆腐CJKフォント不足fonts-noto-cjk を導入

検証・診断コマンド

環境変数がGUIへ届いているか
printenv | egrep 'GTK_IM_MODULE|QT_IM_MODULE|XMODIFIERS'
現在のエンジン確認
ibus engine        # IBus: mozc-jp が理想
fcitx5-remote -n   # Fcitx5: mozc 等の名前が返る
プロセスの実在
pgrep -a ibus
pgrep -a fcitx5
pgrep -a mozc
WMプロセスにENVが載っているか(IceWM例)
grep -azE 'IM_MODULE|XMODIFIERS' /proc/$(pgrep icewm)/environ | tr '\0' '\n'

補足メモ

・デーモン起動 `&` を忘れるとログイン処理が停止・遅延する。必ず末尾に付ける。
・ENV の多重定義やデーモン二重起動は不具合の温床。**「ENV は desktop-session.conf、起動は startup」**に一本化

付録:パッケージ一覧(例)

IBus系
ibus ibus-mozc ibus-gtk ibus-gtk3 ibus-gtk4 ibus-qt fonts-noto-cjk
Fcitx5系
fcitx5 fcitx5-mozc fcitx5-frontend-gtk3 fcitx5-frontend-qt5 fcitx5-config-qt fonts-noto-cjk

antiX-linux

2025/11/02

超軽量linux-antiX

antiXというlinuxディストリビューションがあります。
古いノートパソコンに何かlinuxをいれようかな、と思っていたところに出会いました。

超軽いのはいいのですが、同じantiXでも、アーキテクチャ2種類、デスクトップ12種類、合わせて24通り*1の組み合わせがあり、どれを選択すべきか迷わしいです。

私は当初は、sysVinit Rox-JWM だったのですが、今はrunit,zzz-iceWMにしています。
他の組み合わせももちろん、考えられるのですが、なぜこういう結論に至ったか、は、徐々に記します。

っていうか、syVintとrunitって全く違うディストリビューションだと思うのですが、これをメンテしている中の人のご苦労が忍ばれます。

どんな種類があるのかは、antiX Linuxの起動方式とデスクトップ環境の選択ガイドをご参照ください

*1 : バージョン23.2の場合

antix-雑感

2025/11/02

雑感

・USBはデフォルトで有効なので楽ちん。マウスも自動認識してくれました。
・RDPクライアントのremminaは、よくできている。WindowsのRDPソフトとはフォントが若干違うのが違和感あるが、慣れの問題かな。

antiX Linuxの起動方式とデスクトップ環境の選択ガイド

2025/11/02
迷ったら、わからないとき、最初のお勧めはこちら

antiX Linuxの起動方式とデスクトップ環境の選択ガイド

はじめに - 選択肢の豊富さと迷い

antiX Linuxをインストールしようとすると、まず驚かされるのがその選択肢の多さです。起動方式(init system)だけでも2つあり、さらにデスクトップ環境の組み合わせを考えると、最低でも24種類の構成が可能です。

この豊富な選択肢は、一見すると初心者を混乱させるかもしれません。
しかし、ユーザーに選択の自由を与え、それぞれのニーズに最適化された環境を構築できる、これがantiXの大きな魅力となっているそうです。
本記事では、antiXの起動方式とデスクトップ環境について、その背景から具体的な選択基準を解説します。

起動方式

sysVinitとrunitの2種類があります。
stsVintiが古い方式だけど、逐次起動なのでわかりやすいが、各プロセスの監視はゆるゆるです。
runitは並列起動、かつ、各プロセスコントロールをsysVint より細かくします。

さらにsysytemDという中央集権的なシステムが最近は主流ですが、これはantiXではあえて採用していません。重くなる、ということだと理解しています。

antiXでのGUIの種類の表し方

GUIを実現するためには、WM(=Window Manager)というグラフィカルな窓(ウィンドウ)をコントロールする仕組みと、FM(File Manager)という、いわゆるファイラーとデスクトップ画面でのアイコン配置をコントロールする仕組みが組み合わさっています。
WMもFMも種類があるので、その掛け合わせです。

antiXでは、WM3種類、FM4種類となります。FMはFMなし、という選択肢も1種類として数えています。これで12種類あることとなります。

選び方

というわけで、起動方式2種類×WM3種類×FM4種類=24種類あることとなりますが、sysVint か runit のどちらにするか、をまず決める必要があります。

WM3種類×FM4種類 については、インストールしてから選択できます。

でも
起動方式2種類は、そもそもインストールファイル(ISOイメージ)が異なりますので、マルチブート環境でない限り、どちらか1つを最初に決めてインストールする必要があるからです。

sysVint か runit か

インストールファイルが異なるため、インストール前に決定する必要があります。sytemdはantiXにはないので、比較のための参考用です。

比較

項目sysVinitrunitsystemd
設計年代1980年代(System V)2004年2010年
設計思想シンプル・逐次処理軽量・プロセス監視重視統合・並列処理
スクリプト言語シェルスクリプトシェルスクリプト独自ユニットファイル
起動方式逐次(順番に一つずつ)並列可能並列
プロセス監視なし(起動のみ)常時監視・自動再起動常時監視・自動再起動
依存関係管理手動(スクリプト内)簡易的高度な依存関係グラフ
ログ管理syslog等に依存svlogd(シンプル)journald(統合)
学習難易度易しい中程度難しい
メモリ使用量最小中~大
項目sysVinitrunitsystemd
起動速度遅い(逐次処理)中程度~速い速い(並列処理)
メモリ使用(init本体)1-2MB程度2-3MB程度5-10MB以上
監視プロセスなしサービスごと統合管理
総合的リソース最軽量軽量中~重量
ディスク使用量最小
AIが言うには以下のとおりです。
  • antiXでの選択基準
    runitを選ぶべき場合
    ・常用環境として長期間安定稼働させたい
    ・サーバー的用途(メールサーバー、Webサーバーなど)
    ・RDP等のサービスを常時起動させる
    ・プロセスの自動再起動が必要
    ・最新のLinux技術を学びたい
    
    sysVinitを選ぶべき場合
    ・Linuxの基礎をじっくり学習したい
    ・極限まで軽量化したい
    ・シンプルさを最優先
    ・カスタマイズを細かく制御したい
    ・トラブルシューティングを学びたい
    
    ・学習重視ならsysVinit … 起動の仕組みを一つ一つ追いかけられる
    ・実用重視ならrunit … RDPクライアントの安定稼働、プロセス監視の恩恵
    
ということなのですが、私は異論があり、runitから入るべきと思います。
ただし、linuxをすでにバリバリに使い来ないしている方は、sysVintでいいと思います。

AIと逆の発想ですが、バリバリの方は、sysVintを自分なりに活用してantiXの特徴である「軽さ」「シンプルさ」を堪能できると思います。
一方で、runitは私のようにlinux初心者が最新のsysytemdに繋がる知識を得て、トラブルや面倒さも若干あるけれど、勉強になるし、実用にも十分耐えうる、と思います。
そして、もっとシンプルなのがいいや、となれば、sysVintに移行してもよいと思います。

ということで私は runit を選択しました。(一番最初はあまり考えずsysVintをインストールしたのですが、runitにすぐにかえました)。

WMとFMの組み合わせ--WMの部(ウィンドウマネージャー)

インストール後に簡単に変更できます。

WMの種類

項目JWMFluxboxIceWM
実装言語CC++C++
メモリ使用量(起動時:AI調査)3-5MB8-15MB10-20MB
起動速度1秒未満1-2秒1-2秒
設定ファイル形式XML(単一)テキスト(複数)テキスト(複数)
設定方式XML(直接編集)テキスト(柔軟だが複雑)INI形式(わかりやすい)
タスクバー内蔵×(別途必要)
システムトレイ内蔵×
メニュー生成自動/手動手動/スクリプト自動/手動
タブ機能×○(高機能)×
テーマ対応△(基本的)○(豊富)○(豊富)
Windows風UI×
依存ライブラリ最小中程度中程度
日本語表示
キーバインド柔軟性
ワークスペース管理基本的高機能高機能
透過効果×△(限定的)
最小動作メモリ16MB32MB32MB
CPU負荷最低
設定の学習コスト中~高
開発の活発度低~中
古いPCでも快適。玄人向き。antiX標準。Windowsに似たGUI操作がわかりやすい。
JWMは確かにデザインが古めですが、それでもwindowsXPぐらいなので、グラフィカルな点では、私はどれも遜色ないと思います。

メモリ効率の詳細

  • JWM(3-5MB)
最も軽量で、極限環境でも動作します。メモリ使用量は他の2つの半分以下で、組み込みLinuxやレスキューディストリビューションで重宝されています。
  • Fluxbox(8-15MB)
JWMの2-3倍のメモリを使用しますが、その分高度な機能を提供します。タブ機能を多用すると追加で2-3MB程度増加しますが、複数ウィンドウを効率的に管理できます。
  • IceWM(10-20MB)
3つの中で最もメモリを使用しますが、統合されたタスクバーとシステムトレイ、豊富なテーマ機能を考慮すると妥当な範囲です。Windows風のテーマを使用すると、さらに5MB程度増加することがあります。

実環境でのメモリ使用量目安

典型的な使用時(ターミナル2つ、ブラウザ1つ起動):

JWM環境: 全体で150-200MB
Fluxbox環境: 全体で180-250MB
IceWM環境: 全体で200-280MB

この差は、メモリが256MB以下の環境では決定的な違いになります。JWMなら快適に動作する環境でも、IceWMでは若干のもたつきを感じる可能性があります。
古いPCの再生や、VPSでのGUI環境構築など、メモリが貴重な環境ではJWMの選択が最も合理的です。一方、1GB以上のメモリがある現代的な環境では、この差はほとんど体感できないため、機能性や使い勝手で選ぶのが良いでしょう。

メモリ容量別の推奨:

128MB以下: JWM一択
256MB-512MB: JWMまたはIceWM(用途による)
512MB以上: どれでも快適、機能で選択

用途別の推奨:

サーバー管理用の最小環境: JWM
Windows代替デスクトップ: IceWM
開発環境・パワーユーザー: Fluxbox
古いノートPCの再生: JWM
日常使いのデスクトップ: IceWM

antiXでの実際の使用感では、IceWMはzzz-IceWMの組み合わせで使いやすく、Windows的な操作性とLinuxの軽快さを両立できています。JWMは本当に軽く、メモリ使用量を気にする場合の第一選択です。Fluxboxは設定に時間をかけられる場合に、最も自分好みの環境を構築できるとされています。

WMとFMの組み合わせ--FMの部(ファイルマネージャー)

項目無印(CLI)Minimal系ROX-FilerzzzFM(旧SpaceFM)
メモリ使用量(AI調査)0-5MB約10-20MB約15-25MB約20-35MB
起動速度即座非常に高速非常に高速高速
GUI/CUICUIGUIGUIGUI
依存関係coreutils、bashのみGTK+2/3、最小限GTK+2、最小限の依存GTK+2/3、udev対応
特徴一見GUIにみえるがCUI相当シンプルな機能、基本的なファイル操作のみドラッグ&ドロップ対応ドラッグ&ドロップ対応
適用シーンサーバー環境、上級者、自動化処理LXDE環境、リソース制限環境軽量デスクトップ環境一般ユーザー、カスタマイズOK
CPU使用率ほぼゼロ最低(1-2%)低(1-3%)低〜中(2-5%)
ディスク容量0MB(既存ツール)約1-2MB約2-3MB約5-8MB
デスクトップアイコン配置非対応PCManFMを使って対応対応(Pinboard機能)対応(--desktop オプション)
マウス操作非対応対応対応対応
ネットワークドライブmount経由で対応基本対応基本対応拡張対応
ファイルプレビュー別ツール必要アイコンのみアイコンのみサムネイル対応
無印とMnimalは、一般ユーザーにはお勧めできません。無因に至っては、GUIとはいえないと思います。
メモリの心配がないレベルであれば、zzzFM(旧SpaceFM)、なるべく軽い方がいいならROXです。
ただし、ROXは、ディレクトリのファイル/ディレクトリ数によってウィンドウの大きさを勝手に動かすので、私はストレスがありました。

で、どの組み合わせがいいのよ

antiX-デスクトップのオススメと設定留意点