2013年12月19日木曜日

VineSeed (2013.12) 概観

はじめに

ディストリビューション/パッケージマネージャー Advent Calendar 2013も19日目です。
本日はVine Linuxの開発版、VineSeedの現状について書きます。

2年ほど前から勉強会やイベントに参加するようになりましたが、その都度自己紹介するたびに言われるコメントとしては

  • 「Vineの人ですか!」
  • 「Vine昔は使ってました。」
  • 「今もまだ頑張っていたんですね…」
あたりが定番ですが、
  • 「とっくに消滅したと思っていました」
とか言われるのは、開発側にとっては流石に辛いわけです。

開発陣の人数がそれほど多くないためリリース頻度も多くないことに加え、有力な海外Linuxディストリビューションが続々と林立するようになった昨今、相対的に存在感が低下してしまっているのは否定し得ません（日本における他のディストリビューション関係者は概ねキャラ立ってるうえに濃いしなあ…と、Debian/Gentoo/Ubuntu方面を見て思うわけです）。

そんな中少しでも存在感を出してみようということで、次期安定版に向けて開発中のVineSeedについて、触り程度ではありますが紹介・解説してみようというのが本記事の主旨になります。

VineSeedの概要

VineSeedは開発版なので、当然ISOイメージは提供されていません。VineSeedの開発状況を知るには

あたりが定番なのですが、手早く一目で知りたいという人にはDistroWatchがまとめているサマリーページを利用するのがお勧めでしょう。このサマリーを元にいくつかの項目に分類・整理すると、以下のようになります。

【ベース】

パッケージバージョンupstream最新版
bash4.2yes
gcc4.8.2yes
glibc2.18yes
grub0.97
(2.00はtest package)		2.00
linux(kernel)3.10.203.12.5
openssl1.0.1eyes
systemd-208
xorg-server1.14.41.14.5

【軽量言語】

パッケージバージョンupstream最新版
perl5.12.35.18.1
php5.5.7yes
python
(Python 2)		2.7.6yes

【デスクトップ環境】

パッケージバージョンupstream最新版
GNOME
(gtk+,gnome-shell,
nautilus)		3.10yes
KDE(kdelibs,qt4)4.11yes
LXDE(lxde-common)0.5.5yes
MATE(mate-desktop)1.6.1yes
xfce(xfdesktop)4.10.0yes

【デスクトップアプリケーション】

パッケージバージョンupstream最新版
chromium22.0.1229.9431.0.1650.63
firefox26.0yes
gimp2.8.10yes
thunderbird24.1.124.2.0
vlc2.1.2
(self-build package)		yes

【サーバー】

パッケージバージョンupstream最新版
bind9.9.49.9.4-P1
cups1.4.81.7.0
dhcpd4.1.ESV.R44.2.5-P1
httpd2.2.232.4.7
mariadb--
mysql5.5.305.6.15
openssh6.4p1yes
postfix2.10.2yes
postgresql9.0.129.3.2
samba4.1.3yes

今の所、特にサーバーソフトウェアに古いパッケージが多く見受けられるものの、それ以外では概ね最新版に追従できており、他のディストリビューションとほぼ遜色はないと言えるでしょう。

先にも述べた通りVineSeedはVine Linuxの開発版という位置づけにあるため、次期安定版はVineSeedをベースに作成されます。故に、特別な理由でバージョンを固定するもの以外は概ね安定版をリリースする時点で最新、或いはそれに近いバージョンのソフトウェアが投入されますので、「Vineはソフトウェアのバージョンがが古くて…」というイメージは持たないで欲しいものです。
※安定版のリリース間隔が空くことにより収録ソフトウェアに相対的に古くなってしまうものが出てくるのは事実ですが、安定性に支障のない範囲で更新はされますので、致命的に利用に問題が出てくるという状況には今の所なっていないと思います。

各項目解説

ここでは、上記の項目毎に適宜補足・解説してみたいと思います。

【ベース】

  • gccやglibc等は、昨月アップデートが行われました。これらに関しては過去の事例から考えて、大きな問題が出てこない限り今後しばらくは大幅なアップデートは行われないと思います。
  • kernelは最新のものではありませんが、3.10系はLTS(長期サポート、Long Term Support)である旨が宣言されているバージョンです。最近は3.10系で更新されていますので、次のLTSが登場するまでは3.10系で更新されていくことになると考えられます。
  • systemdは従来のinitデーモンに代わるものとしてRHEL 7に搭載されることで注目を集めています（参考）。しかし、現状VineSeedにはパッケージがありません。VineではUbuntu由来のUpstratが採用されており、Vine 6.2では1.2、VineSeedでは1.6が投入されています。このままUpstratでいくのか、それともsystemdに切り替える or 対応させるのかは、まだ公式にミーティング等で議論がされていません。

【軽量言語】

  • perlがだいぶ古いです（Vine 6と同バージョン）。しかし、メンテナーが作業することを宣言しているので更新作業はされるはずです。
  • DistroWatchではRubyがピックアップされていませんが、2.0系が投入済です。ておくれな人たち御用達のmikutterも動きますよ！
    ※self-build-mikutterとしてパッケージが存在します。

【デスクトップ環境】

  • メジャー所のデスクトップ環境は概ね使用可能です。Linux Mintで採用されているCinammonも利用可能です。
    ※最新版の2.0ではなく1.8.8。
  • Qtを用いた軽量デスクトップ環境であるRazorQtは現在ありません。以前、LXDEとRazorQtが統合するとのニュースがありましたが、それをうけてLXDEもどうすべきかという課題が生じているため、今後の動きを見て考えることになると思われます。
    ※VineにおけるLXDEのメンテナーは私です。

【デスクトップアプリケーション】

  • Vineではマルチメディア系アプリケーションの多くがself-buildという仕組みで提供されています。これはバイナリで配布することが難しいソフトウェアを導入するための独自の仕組みですが、vlcをはじめとしてmplayerやffmpeg等がこれで提供されています。
  • self-buildの仕組みを利用したinstall-assistという仕組みもあります。これは外部で提供されているパッケージを自動的に取得し、インストールする仕組みです。LibreOfficeやOperaのインストールにこの仕組みが用いられています。

【サーバー】

  • サーバーソフトウェアは全般的にメンテナンスが遅れ気味です。メンテナーがいるパッケージは追従されてはいるのですが…

終わりに

かなりざっくりと紹介してきました。全体の傾向として、ベースやデスクトップ環境は最新への追従が行き届いている一方、サーバーソフトウェアはメンテナンスが遅れ気味ということがわかると思います。

開発陣が少ないために一人で多数のパッケージをメンテンナンスしているのが実情ですが、どうしても追い切れない部分や特定のメンテナーに負担がかかる状況は避け得ない問題で、それがサーバーソフトウェアに端的に現れていると言えます。
※これはサーバーソフトウェアに限定される問題ではなく、例えばpythonは本体もさることながらライブラリーのメンテナンスが滞りがちです。

締めとしてこの文言もどうかとは思いますが、上記状況を何とかしてみようという意志のある方、Vine Linuxの開発に参加してみませんか？開発コミュニティへの参画は様々な方面へと知見を広めるチャンスともなり得ますし、メンテナンスが滞りがちなパッケージではあるが自分が必要としているパッケージなどは、自分の好きなようにカスタマイズできますよ。

投稿者 時刻: 0 件のコメント:

2012年8月8日水曜日

MigMixフォントのライセンス変更要求に関して

先月、以下の記事が公開されていることをtwitter上で知りました。
IPAフォントライセンスv1.0は非共存ライセンスと判明 - itouhiroメモ
http://d.hatena.ne.jp/itouhiro/20120607

上記はVineだけではなく、Debianにもパッケージが存在するMigMixフォントの製作者のブログです。
このフォントはIPAフォントとM+フォントを合成したフォントで、今までライセンスは

  • IPAフォントライセンス
  • M+フォントライセンス
の両者が適用されていました。これを承け、VineではSPECに両ライセンスを併記し、ドキュメントにも両ライセンス文書を含めていました。

ところが、上記ブログではIPAからこのライセンス適用は適切ではないから修正せよ（具体的にはIPAフォントライセンス単独適用とせよ）と求めてきたため、IPAフォントライセンスのみの適用に修正し、IPAもその結果を諒としたと述べています。

この流れを読み疑問を感じたのは、
M+フォントのライセンスについて、IPAは一体どう捉えて処置を指示したのか？
という点でした。

IPAに質問してみた

この疑問に対してあれこれ考えるよりも、要求をした大元に尋ねるのが一番手っ取り早いだろうと考え、以下の質問メールをIPAのフォームより投じてみました。（実は6月中にも一度同様の内容を投じたが音沙汰無し。そのため、7月にもう一度投じている）

本日、IPAフォントを用いた合成フォントMigMixとMiguの作者のブログを閲覧した際、IPAフォントライセンスが非共存との指摘を受けたとの記事を目にいたしました。
http://d.hatena.ne.jp/itouhiro/20120607

上記記事では作者による対処の結果が記されており、結果MigMix及びMiguの両フォントはIPAフォントライセンスだけが適用された状態となり、IPAもそれで諒とした旨が述べられております。

しかし、上記の対応からはIPAフォントと他のフォントを合成した際、IPAフォント以外に用いられたフォントのライセンスはどのように適用・処置されるべきなのか、疑問が生じます。（MigMixの場合、M+フォントのライセンスは無いものとされたように見える）

合成フォントを作成する際に用いられたIPAフォント以外のフォントのライセンス適用について、IPAとしては如何に考えているのか、お答え頂ければ幸いです。なお、今回の質問及び返答については周知を目的として公開を考えておりますが、問題ございませんでしょうか。

以上、よろしくお願いいたします。

IPAからの回答

上記質問メールに対し、IPAのIPAフォント担当者より返答がありました。ちなみに、回答内容の公開については最初返答がなく、再度問いなおしたところ"転載を禁止する"との返答をいただいています。ゆえに、メール内容そのものの転載はせず、こちらで要旨を箇条書きにまとめてみました。

  1. IPAフォントライセンスはOSIによる「オープンソース定義（OSD）」に準拠したライセンスと認定されている。
  2. ソフトウェアの作者がどのライセンスを採用するかは自由だが、採用ライセンスの種類次第では権利が制限される場合がある。（ここでの"権利"とは、再配布行為や他のソフトウェアと組み合わせての利用のこと）
  3. "ライセンス間の矛盾について"（http://sourceforge.jp/magazine/06/06/09/1537222）の以下の部分が引用される。
    「二つないし複数のプログラムを「リンク」すると全ては一つになり、結合著作物となる。複製や頒布など、「リンク」したものを一緒に扱う際には、「リンク」したプログラムのライセンスで指定された条件を全て満たすようにしなければならないわけだ。言い換えれば、最も制約の厳しいライセンスが全体のライセンスと等しくなる。」
  4. 異なるオープンソースライセンスで配付されている二つ以上のソフトウェアの組み合わせ利用の可否は、それぞれのライセンスの内容に基づき判断が必要。ライセンス適用方法については弁護士等への相談を勧める。
  5. IPAではIPAフォントライセンス第3条4項に明記されている通り、IPAフォントに関する個別相談（ユーザーサポート・ライセンス面等）は受けつけていない。

内容は概ね以上となります。私の質問の仕方に問題があったせいか内容がやや断片的なきらいはありましたが、繰り返し読み込んで調査しながら考えていった結果、IPAがMigMixフォントに対してライセンス変更を要求するに至った論理が概ね推測できました。以下、私の考察を述べてみます。

考察

IPAからの回答一点目については、概ねオープンソースに携わっている人たちなら承知していることだと思いますので特段問題ないでしょう。肝は二点目を承けた三点目の中、つまり「最も制約の厳しいライセンスが全体のライセンスと等しくなる」にあるように考えられます。

ここで、M+フォントライセンスとIPAフォントライセンスをざっくりと比較してみます。

M+フォントライセンス（http://mplus-fonts.sourceforge.jp/mplus-outline-fonts/index.html#license）は非常に制限の緩いライセンスです。その内容をまとめると、

  • 利用・複製・再配布は許可（改変の有無・商業利用も問わない）
  • 全て無保証
の二点となります。

一方、IPAフォントライセンス（http://ossipedia.ipa.go.jp/ipafont/index.html）はM+フォントライセンスより厳しい制約を課しています。詳細は上記リンクに譲りますが、

  • 改変・再配布は可能だが、派生物にはIPAの名称を使用してはならない
  • オリジナルのIPAフォントに戻せる方法を提供しなければならない
  • 派生プログラムを定められた条件の下でライセンスしなければならない（MigMix作者にライセンス変更を要求した根拠となったライセンス第3条1項(3)）
などが規定されています。

つまり、大まかな流れとしては

M+フォントライセンスとIPAフォントライセンスを比較した際、後者がより厳しい制限を課している。
↓
「リンク」したものを一緒に扱う際は「リンク」したプログラムのライセンスで指定された条件を全て満たすようにしなければならないから、最も制約の厳しいライセンスが全体のライセンスと等しくなる」という見解がある。
↓
M+フォントとIPAフォントを合成した場合（今回の場合MigMixフォント）、両ライセンスの条件を満たすようにするにはIPAフォントライセンスがMigMixフォントのライセンスとなるべき
という思考の流れで今回の要求に至ったのではないかと私は推察しました。

まとめ

IPAにはこういう考えですか？と回答内容の公開について再度問いなおした際に書いたのですが、反応がありませんでした。そのため隔靴掻痒の感が否めないのですが、つまるところIPAの行動は「ライセンスの影響力の強さ」を踏まえたものであったように思われます。

投稿者 時刻: 0 件のコメント:

2012年6月10日日曜日

lcrt日本語化作業の覚書

lcrt (http://code.google.com/p/lcrt/, https://github.com/niutao/lcrt) というリモートログインツールがあります。自機からSSHでリモートコンピューターと接続することが多い人には便利なツールだと思います。

このアプリケーションの利点としては、

  • 接続セッションが保存可能なのでいちいち入力せずともOK
  • 1つのウィンドウのまま複数の接続セッションを同時に実行できる（タブ使用可能）
  • 接続セッションの複製が容易
  • ローカルシリアルポートの接続をサポート
  • 比較的軽量
といった点が挙げられましょうか。（このアプリケーションに注目したのは、筆者がSSH接続の手間を若干煩わしく思っていたことに起因します）

多少なりとも使用してみた感触としては、長らくの開発停止状態から近年漸く再始動したWindows用ターミナルエミュレーターPoderosa (http://ja.poderosa.org/) に近い印象を抱きました。現状ではPoderosaほど機能は充実していませんが、開発は継続しているようなので、今後の発展に期待できるアプリケーションと言えましょう。

日本語化着手

さてこのlcrt、現在のところ日本語化はされていません。使われている英語はさほど難しいものではなく、SSHを普段から活用している人なら感覚で使いこなせそうなものですから、使用上大きな障害とはならないはず。しかし、そう言って放置するといつまで経っても誰も翻訳しないので、着手することにしました。

何この方式？

FLOSSに関わっている方々の中では、多言語対応にするため広く用いられているツールにgettextがあるのは周知の事実でしょう。lcrtもGTK+を使っているアプリケーションなので、gettextを利用しているのだろうと思っていたのですが……。

結論から述べるとlcrtのソースにはgettextで用いられる.poファイルが存在しません。かといって、Qtアプリケーションで用いられるような.tsファイルもありません。ならば、どのような形式のファイルが用意されていたかというと、C言語用のファイル（hoge.cとfuga.h）でした。しかも、最終的にはsqliteデータベースに格納されるという、今までにみたことがない方式。lcrtには表示言語を容易く切り替えられる設定があるので（勿論言語対応がされている範疇で）、その辺りと関わりがあるのかも知れないですが、稀な方式であることに違いはありません。

取り敢えずやってみよう

見慣れない方式とは言え、「原理からすれば日本語用の.cと.hがあれば取り敢えず何とかできるだろう」という安易な発想から英語用のen_US.cとen_US.hをコピー&リネーム（ja_JP.cとja_JP.h。ja_JP.cが日本語用ファイルの本体）して、作業を開始しました。

static struct lcrt_language_config ifile = {
    .table_name = LCRT_IFILE_TABLE,
    .members = LCRT_F_NUMBER,
    .config = {
         {"f_menuitem",                      "ファイル(_F)"},
         {"f_connect",                       "接続(_C) ..."},
         {"f_quick_connect",                 "クイック接続(_Q) ..."},
         {"f_connect_in_tab",                "タブで接続(_B)"},
         {"f_reconnect",                     "再接続(_R)"},
         {"f_reconnect_all",                 "全て再接続(_A)"},
         {"f_disconnect",                    "切断(_D)"},
         {"f_disconnect_all",                "全て切断(_O)"},
         {"f_clone_session",                 "セッションを複製(_N)"},
         {"f_lock_session",                  "セッションをロック(_K) ..."},
         {"f_print",                         "印刷(_P)"},
         {"f_print_setup",                   "印刷設定(_U) ..."},
         {"f_log_session",                   "セッションを記録(_L)"},
         {"f_recent_session",                "最近のセッション"},
         {"f_exit",                          "終了(_X)"},
    }
};/

ja_JP.cの内容は概ね上記のような感じになっています。一見してgettext方式とは異なることが判りますが、原文を日本語化しつつアクセラレーターが入っているものはしっかりと入れていくという作業自体の流れは、gettext方式と何ら変わるところがありません。

問題はmake関連ファイルの修正

日本語翻訳がある程度進行した状態で、一度バイナリをビルドして状態を確認しておく必要があるかなと思い、ビルドを試みました。gettext方式の場合、追加言語用のソース修正作業はしなくても問題なくビルドできることが往々にしてありますが、今回は必要でした。しかし、今までに経験したことがない方式なので勝手が違います。調べた結果、

  • lcrt/language/Makefile.in
  • lcrt/language/language.c
  • lcrt/language/language.h
の3ファイルでja_JP.cとja_JP.hに関する修正を施す必要があることが判りました。

最初は以上の修正でOK…と考えていましたが、この修正だけでは日本語ファイルのsqliteデータベースを作成しません。何が原因かと更に調べた結果、

  • lcrt/language/Makefile.am
の修正も必要と判明。どうやら、上記ファイル中の 
#include "mkconfig.h"
#define LCRT_SUPPORT_LANGUAGE 3
#define LCRT_LANGUAGE_NUMBER 18
の"LCRT_SUPPORT_LANGUAGE"を修正する必要もあったようです。（"LCRT_SUPPORT_LANGUAGE"は予め用意されていた言語数（英語・ドイツ語・簡体字中国語）。4に修正することで日本語も含まれるように）

以上の修正に加え、ja_JP.cとja_JP.hの中でen_US.cとen_US.hに由来する部分もsqlite日本語データベースに対応するよう修正した後でビルドを試みたところ、漸く日本語化ができました。

終わりに

ソースを参照した最初の感想が、「何故gettext使ってないの？」でした。gettextを利用せず、敢えてsqliteを使用した製作者の意図を推し量ることはできませんが、何らかのメリットがあるとは推測されます。ただ、lcrtの方式は翻訳者にとってはgettextを利用する方式と比較すると

  • 原文確認がしにくい
  • 作業が煩雑になっているのでは？
という印象を作業を通じて抱きました。果たして今後このような形式を採用したアプリケーションは登場するのでしょうかね……

投稿者 時刻: 0 件のコメント:
ラベル: ,
登録: 投稿 (Atom)