meta's blog - The Power To Serve

■ RealVNC から TigerVNC へ乗り換えるべき理由 (2)

本記事は以下の記事の続きです。

• RealVNC から TigerVNC に乗り換えるべき理由 (1)

タイトルに「(1)」と書いてある通り、はじめから複数回に分けて書くつもりだったんですが、1年以上放置してました。

結論から言います。VNC の派生ソフトウェアは数多くありますが、本家の RealVNC を含めどれを使っていいのかよくわからなければとりあえず TigerVNC を使っておけばいいです。おすすめです。ついでに検索に引っかかるようにいくつか言わせてもらいます。これからは TigerVNC の時代です。今から新規採用するなら TigerVNC を使っておけば間違いないです。

RealVNC はオリジナルの VNC の開発者が設立した会社の社名であり、同時に製品の名前でもあります(以下、会社を表す場合は RealVNC 社といいます)。よって RealVNC はオリジナルの VNC の正当な後継となる製品です。このため「VNC って色々種類があってよくわからないしとりあえず本家っぽい RealVNC を使っとこう」という感じで使われることが多いのですが、RealVNC を使う理由がこの程度であれば TigerVNC を使うことをおすすめします。

ライセンス上の問題 (商用利用ができないなど)

RealVNC にはオープンソース版とプロプライエタリ版の2つに大きく分けられ、さらにプロプライエタリ版をエディションで区別すると以下の4つのエディションがあります。

1. オープンソース版
2. Free Edition
3. Personal Edition
4. Enterprise Edition

このうち、無料で使えるのは GPLv2 でライセンスされているオープンソース版と Free Edition の2つです。 RealVNC 社によって公開されているオープンソース版 RealVNC の開発は既に停止していて、4.1.3が最終版です(後述)。この記事を書いた時点でのプロプライエタリ版の最新バージョンが5.0.4なのに比べると遥かに古いです。

一方、新しい方の Free Edition ですがこちらは商用利用することができません。個人での非商用利用に限られています。 企業などで RealVNC の無料版を使っている場合、バージョン 4.1.3 以前を使わなければライセンス違反となる可能性があります。 5以降のバージョンも無料で使えるから会社で使おうと考えている人は、記憶に新しい Adobe CS2 無償配布祭りを思い出してください。

• Adobe、CS2の公開について説明　非正規ユーザーの利用は「ライセンス違反となり得る」

多くのネットワーク帯域を必要とする＆通信が暗号化されない

無料で使えるオープンソース版及び Free Edition は通信データが圧縮されない(全く圧縮していないわけではない)ので、LAN内で使用するにはあまり問題ないものの、インターネット経由で使う場合、消費するネットワーク帯域の多さや動作の重さが問題になります。また、RealVNC 4.1.3 では送信される画面のデータやキーストロークは暗号化されないためそのままではインターネット経由で使用するのは避けるべきです。

オープンソース版はバージョンが古い

GPLv2 で公開されているオープンソース版は、RealVNC 社による開発は終了していて既に時代遅れです。例えば前回の記事で触れたように、スクリーンのサイズを動的に変更する XRandR や他の多くの X 拡張を使うことができません。

もちろんソースコードが公開されているので、オープンソース版 RealVNC の4.1.2や4.1.3をベースにした派生 VNC が数多く存在します。 しかし、数多くの派生ソフトウェアが存在するために実装がバラバラで、異なる VNC 同士で通信すると互換性のために古い RFB プロトコルが使用され、せっかく追加された機能が使えなかったり、ネットワーク帯域や暗号化の問題が解決されなかったりします。

次に、数多くの VNC 派生ソフトウェアの中でなぜ TigerVNC を選択するべきなのかを説明します。

TigerVNC を選ぶ理由

ざっと上げてみるとこれだけあります。

• 最も後発のプロジェクトで開発が活発
• Red Hat 社や ThinLink 社などが開発に参加している
• TightVNC や TurboVNC の開発者が TigerVNC の開発に合流した
• Fedora などいくつかの Linux ディストリビューションで採用されていて RealVNC を置き換える傾向にある
• 多くの VNC 派生ソフトウェアの実装を整理して集約しようとしている
• 画面の動的リサイズに対応している

RHELの開発メーリングリストに流れたメールによると、TigerVNC は2009年2月末頃にスタートしたプロジェクトです。今は2013年なので、もう5年目に入るプロジェクトですが TightVNC の開発者や TurboVNC の開発者が合流したことにより、バラバラに拡張されていた各々の VNC も整理されつつあります。 また、Fedora プロジェクトや RHEL が採用したことで、Red Hat 社の社員が開発に参加したり、シンクライアントメーカーである ThinLink 社もプロジェクトに参加したりしているので、しっかりした開発体制となっています。

他の Linux ディストリビューションにも採用されつつあり、これからは TigerVNC が VNC の標準的な存在になっていくと考えられます。

というわけで TigerVNC は多数ある VNC の派生ソフトウェアを統一して、分散していた開発者を集め労力を集中させるべく生まれたプロジェクトであるため、TigerVNC を使っておけば間違いないです。

TigerVNC プロジェクト発足の経緯

上で取り上げた TigerVNC プロジェクト発足の経緯を説明した Adam Tkak メールの日本語訳を置いときます。

• http://www.redhat.com/archives/rhl-devel-list/2009-March/msg00213.html

どうして(Fedora 11 の)ベータフリーズの直前に突然 TightVNC の機能が TigerVNC に改名されたのか、
その背景を説明させてください。

Fedora 10 では RealVNC をベースにした VNC を採用していましたが、開発元の RealVNC 社が
Fedora プロジェクトの作成したパッチを受け入れようとしなかったため、私達は Fedora 11 では
RealVNC を TightVNC で置き換えることにしました。

Fedora 11 に採用されるはずだった現在の TightVNC の "trunk" ブランチは、RealVNC と同じ
コードをベースにしています。TightVNC プロジェクトは RealVNC に "Tight" エンコーディング拡張や
他の便利な機能を追加しました。私は1年前に TightVNC の開発に参加し、すべての Fedora によるパッチを
移植することに成功しました。

しかし残念なことに、TightVNC のリーダー開発者は UN*X 版の次のリリースの計画を示すことができませんでした。
UN*X 版の開発者は皆、何の機能が次のバージョンに入るのか、いつリリースされるのか尋ねました。
マイルストーン(リリース目標)なしに開発を続けることが何人かの開発者には受け入れがたかったため、
TigerVNC を派生させました。

TigerVNC は2週間前に始まったばかりの新しいプロジェクトです。TightVNC に残っていたアクティブな
UN*X 版の開発者は皆 TigerVNC に参加しました。TurboVNC (3D ゲームなどのパフォーマンスにフォーカスした VNC)
のリーダー開発者も参加したので、私達は TightVNC より良い未来があると考えています。
公式の声明もあります(リンク切れ)

以上の理由により、TigerVNC は TightVNC より優れたものになると考えているため、可能な限り早く TigerVNC に
切り替えることを決断しました。

TigerVNC プロジェクト発足の経緯 その2

もうひとつ、各々の VNC 派生ソフトウェアを統一して TigerVNC プロジェクトを立ち上げた中心人物の声明の日本語訳も。 原文はこちら。

• http://article.gmane.org/gmane.network.tight-vnc.general/8610/

Virtual Network Computing テクノロジーは本当に素晴らしいものです。
数百万のユーザがいて、また VNC に触発されて派生した実装やプロジェクトも多数あります。
オープンソースライセンスがコードとアイデアの共有を促し、コミュニティの発展を進めました。
しかし、多すぎる派生実装が開発の成果とユーザの支持を分散させてしまっています。

この6年間、私は VNC コミュニティ、特に TightVNC プロジェクトで協力とで統一に奔走しました。
そして私達は大きな進歩を成し遂げました。1年ほど前に TurboVNC の開発者と Fedora VNC の
メンテナがこの勢力に参加したため、私達はこの技術を更に上のレベルの成功へ導き、開発を
加速させることができると信じています。

しかし最近、TightVNC プロジェクトはこの開発をサポートすることができないことが明らかになりました。
これが TigerVNC プロジェクトを発表している理由です。このプロジェクトは TightVNC の trunk の
ソースツリーをベースにしています。私達のターゲット層は TightVNC と比べて若干異なるかも
しれませんが、私達は高性能で安定した包括的な VNC の実装を提供することを目指しています。
Windows, Linux, そして Java といった複数のプラットフォームのサポートも続けていきます。
最新世代の X.Org は既に導入済みです。

加えて、私達の狙いは 当初 VirtualGL プロジェクトで開発されていた拡張を TurboVNC から
マージすることです。Cendio AB はこの取り組みを後援します。

私達は統一するという精神を持っているのに、新たな別の VNC を派生させることは間違っているように
見えるかもしれません。しかし実際は、TightVNC プロジェクトが 4年前に /trunk ソースツリーを
作ってから分岐しました。 TightVNC のコアチームは別のブランチで開発をしています。
/trunk ソースコードをベースにした TightVNC のリリースはなく、異なるブランチ同士をマージ
する取り組みも行われていません。 /trunk ブランチを独立したプロジェクトとして開発を続ける
ことが前進するための手助けとなるのです。例えば、今私達はバザール方式の開発モデルをとる
ことができるのです。

TightVNC の実装は近いうちにリリースされる Fedora 11 と ThinLinc 3.0.0 というソフトウェアに
含まれる予定です。詳しい情報については http://tigervnc.sourceforge.net/ を訪れてください。

Pierre Ossman, Cendio AB
Adam Tkac, Red Hat, Inc.
DRC, TurboVNC メンテナ
を代表して

Peter Åstrand, Cendio AB