Charlie's volatile short

情報が少ない

ネットで調べても同じ境遇の人の絶対数が少ないので情報が見つけられない。 悩みどころは同じでも、OSのディストリビューションの違い、バージョンの違い、カスタマイズの違いなどで応用できる情報ではなかったり。

Windowsで、XPの『アプリケーションの追加と削除』が「プログラムのアンインストール」とか「プログラムの追加と削除」に変わっているようなもんですが、Linuxではディストロのバージョンアップの際に同種機能の別プログラムに置き換わったりするので混乱の度合いが大きい。lilo→grubとか。

日本人特有の問題として、英語の情報が苦手(その人にとっては情報が無いのも同然)ということもある。

同じことをする手段がいろいろありすぎる

ある目的に対して手段が複数用意されている。しかも「標準」の一つを覚えれば事が足りるというのではなくて、特定の環境で使えるのは一種類だけだったりするので結局二つ三つと覚えないといけなくなる。

例えば、「管理者権限で/etc/***.confを編集する」という時のお作法はいろいろある。 これまで経験しただけでも以下のようにいろいろ。

• suでrootのパスワードを入力する
• suで現在のアカウントのパスワードを入力してrootの別名アカウントになる
• sudoで現在のアカウントのパスワードを入力する
• ssh-agentに鍵を登録しておき、sudoする

どの方法が有効かはディストリビューションではなくサーバ毎のポリシー依存だから、結局全部のお作法を覚えていかないといけない。

ディストロパッケージという平和な世界は儚く脆い

OSディストリビューションのパッケージとして提供されていないプログラムを使いたい時に、ソースからビルドするとき。 configureに、ライブラリが古いと言われたがディストロパッケージでは新しいバージョンが提供されていない。 するとソースからビルドした新しいライブラリを入れることになるのだが、ディストロパッケージ由来のを削除しようとしても、依存している他のパッケージがインストールされていると警告が出て削除できない。

例えば以下のようなやり方が考えられる。
1だと、後からディストロパッケージをインストールしようとして競合するおそれがあるのでかなり危険。
2, 3は知識と手間をかなり要する。

いずれの手段をとっても、ディストリビューションの提供する世界から一歩外に出ようとすると、途端に地獄が待っているということ。

1. 依存関係を無視させてライブラリのパッケージを削除
   →ソースからbuild & install→プログラムをbuild & install
2. prefixをつけてライブラリをconfigure & build & install
   →ライブラリ、ヘッダのサーチパスをカスタマイズしてプログラムをconfigure & build & install
3. プログラム専用の仮想環境を作って、新しいバージョンのライブラリを提供しているディストリビューション(Fedoraとか?)を入れる

Depndency hellはWindows OSにおいてわざわざDLL hellという固有名詞(?)が与えられていてWindowsの問題として覚えられがちだが、今となってはLinuxの方が深刻なのではないかと思う。
GTK+とpangoのように開発グループが分かれているようなのだと、特定の組合せしか考慮していないアプリが結構ある。

まとめ: 敷居を上げちゃうような多様性が問題では

カスタマイズや組合せの自由ばかり増えても、トータルで使いこなせないものになっては意味がない。一人の人間が理解して制御できる世界なんて限られているのだから。

複雑さを増さずに機能を追加する方法はUI/UXの分野で研究されているんだけども、なんだか範囲限定でしかトータルのバランスがとれていない気がして惜しい。例えば特定のアプリケーションがOSやウィンドウマネージャのL&Fを無視した独自UIを提供するとか。

あと、既存のエクスペリエンスを体験してきたユーザが違和感なく新しいエクスペリエンスに馴染めるようにする工夫がもっとほしい。