XFree86プロジェクト分裂の危機 115
fork() 部門より
Technobose 曰く、 " ZDNetによると、「XFree86プロジェクトのCore Teamは3月20日、元メンバーのKeith Packard氏が別のXFree86プロジェクトを立ち上げようとし、その理由の説明を拒んだことから同氏を除名したと発表した。」とのこと。
オープンソース・プロジェクトにつきものの分裂ですけれど、ついにXFree86まで、という感じです。ところでBSD系では、FreeBSD、NetBSD、OpenBSDと流れがあり、それぞれが独自の価値観に基づき独自に開発をしながら、協調もしていますよね。XFree86でも同じように、複数の開発グループで、それぞれ自分たちの価値に基づきながら開発を進め、重要な点では協調するということがあってもいいと思うのですけど、いかがでしょうか?
それとXFree86と同じようなUNIX用のGUIのオープンプロジェクトって何かありましたっけ? "
本家に最初に掲載されたストーリによると、Keith Packardは隠れて分裂を準備していたので、コアチームに不適合であるとして、放り出された。(アナウンス)。彼は最近のXFree86の開発メンバーの中では精力的に動いていて、FontConfigやXft、X Render Extentionなどの開発にかかわっていただけにX関連のフォーラムは大荒れしている。これを受け、XFree86側がこのテーマ専門のメーリングリストを設置した。
本家のふたつめのストーリからリンクされているOSNewsの記事がそこへの投稿からおいしいところを拾ってくれている。ひとつは11年前にXFree86をはじめた一人であるDavid Wexelblatによるコアチーム側の主張。XFree86プロジェクトにはたしかに変化が必要だが、それはKeithが提案しているものでもなければ、Keithのやりかたは裏切り以外のなにものでもない、というものだ。その対極に、プロジェクトはリリースが遅すぎ、融通が効かず、もっとオープンにコミュニティ主導のものにならなければいけない、というKeith Packardの反論がある。これらを中心に、ディストリビューションメーカやX上でソフト開発を行っている企業まで巻き込み、Xの根本的なネットワークモデルの是非や過去との互換性といったテーマをも含む、XFree86の将来を模索する議論が続いている。
Xかnot Xか (スコア:5, 興味深い)
話題になってて、多くの人が関心を持っている事が伺えます。
The Register に掲載されたXFree86 dust-up questions X11 model [theregister.co.uk]
という記事では、Alan Coxのコメントが引用されています。曰く、
「Xはもっとドライバメンテナを信頼せよ」「XFreeプロジェクトは変わらなきゃ」
話をややこしくしているのは、これに乗じて、Xそのものをすげ替える
べきだ、という議論が巻き起こっている事。今のXに不満を持っている
人が多いという事がよくわかります。今後はXプロトコルと互換性を
保ちつつも、X Window Systemとはまた違った形のグラフィック層が
出てくるかもしれませんね。
ここでFresco [fresco.org]か?歴史は長いが…
Re:Xかnot Xか (スコア:1)
>今後はXプロトコルと互換性を
>保ちつつも、X Window Systemとはまた違った形のグラフィック層が
そういうものって、技術的には存在可能なのですか?
プロトコルが即ちXの有り方全体を規定している、のかとてっきり思っていたので。
つまり、違う層に対して再編を行う、という話なのかな?と思っていたんですが。
互換性を保つんだったらそれは只のラッパーであり、それなら今までも無数に存在する
「X上の」グラフィック/GUIライブラリと同じなのじゃないか?とちょっと思ったもので。
また、Xとそれ以外との複数の足回りに対応したGUIライブラリ、ってのも色々あるよね。GtkやQtもそうだし。
Re:Xかnot Xか (スコア:1)
想定していたのは、まったく新しいフレームワークで構築した
グラフィック層が出てきたとして、Xをすげ替えていく過程では、
既存のXクライアントもサポートしていく事になるんだろうな、
という事です。上位互換とか相互接続性と書いた方が良かったな。
ただ、これは言う程簡単な事ではないので、そのシステムで動作
するXサーバを起ち上げて(Astec-Xのようなもの)、それを介する
という実装にする方が楽だろうな。
ちなみに、「グラフィック層」と書いているのは、Window System
だとぴったりしないようになってきたなぁ(フルスクリーンもの等)、
という程度の意味です。
Re:Xかnot Xか (スコア:1)
(X Serverが入ったのは後日ですけど)
# rm -rf ./.
とりあえず、 (スコア:4, 参考になる)
Berlin改めfresco [fresco.org]を。
Fresco日本語FAQ (スコア:2, 参考になる)
ご参考までに、Fresco日本語FAQ [fresco.org]
Re:Fresco日本語FAQ (スコア:1)
CMS は Zope?
Re:Fresco日本語FAQ (スコア:1)
今の時点で多言語WikiをやるとしたらやっぱりUTF-8を使うのが一番現実的なのかな。
Re:Fresco日本語FAQ (スコア:1)
(1つの頁の1つの議論が多言語で行われることを喜ぶべきか悲しむべきかはさておき、
仕組みとしてはそれを受け入れないと、最大限うまくやったとしても
「頁ごとに言語が固定」などということになり、それは多分Wikiとしては辛いだろう…)、
UTF-8あたりになっちゃうんでしょうね。
#Unicodeの駄目っぷりの話はさておき。
そういやオフトピだけど、WinとUnixつまりSJISとECUの文化(笑)の中に
更に第三の候補としてUTF-8が入ってくると、結構厄介ですね。
今まではコードを自動変換すればいいじゃんという感じだったけど、
これからはファイルがUTF-8かSJISか(笑)で悩まないとならなくなるんで。
#悩まされるのはJava方面かな。
で、両者って自動判別は困難なのでしたよね?
Re:Fresco日本語FAQ (スコア:1)
Keith はかなり昔から X11 な人 (スコア:1, 参考になる)
いつからだったかな MIT X Consortium の頃にはいたのは
xc/lib/font/fontfile を見れば明らかなんだけど
あと Fresco ももともとは X11 の後継とかいっていた時代があって
X11R6 の workinprogress に LBX などとともに含まれていたこともあったし
InterViews とかも懐かしいのう
Xutf8 (スコア:2, 参考になる)
コミュニティとしてやばいなぁと思ったので、あまり驚きはないです(^^;)
あの時も分裂の話があったと思いますが、結局Xutf8ってどうなったんでしょう?
当時はまともに日本語が使えないという話もあったようですが、
今は特に問題ないようなので…。
Re:Xutf8 (スコア:2, 参考になる)
それよりも、数ある文字コードのひとつにすぎない UTF-8 を特別扱いすることへの批判が大きかったような。
つまりは、いつもの Unicode 派と CSI (Code Set Independent) 派の論争ってやつかな。Linux (GNU libc) は wchar_t を UCS-4 決め打ちにしようという方向だったのでどうでもいいけど、 CSI な国際化を目指していた *BSD にとっては重大な関心事だったと思います。
Re:Xutf8 (スコア:2, 参考になる)
これって実装が簡単だったからですか?
ちょっと前に多言語化に興味を持って色々調べたことがあるんですが
Code Set Independent 用のライブラリってあるんだろうか…。
(当時)Code Set Independent 派の主張が絵に書いた餅だったのなら、
UTF-8 を選択した XFree86 を安易に責めるわけにもいかないような。
// 個人的には Keith 派かなぁ。
This cookie has a scrap of paper inside. It reads:
If you can't learn to do it well, learn to enjoy.
Unicode vs CSI (スコア:3, 参考になる)
いまだにモノが出てこないというのは、
仕方がない部分もあります。
というのは、Unicode 派は、CSI でいう
Unicode サブモジュール部分だけを実装すれば
いいからです。逆に言えば、Unicode hardcode
手法だったら完成品ができてしまうくらいの手間を
かけて、ようやくサブモジュールがひとつ完成します。
もちろん、それだけの手間をかけるだけの価値が
あればいいわけですが、CSI のほうが絶対的に有利に
なる場面って、漢字の扱いしかないんですよね。
もちろん、われわれ東アジア人にとってはそれは
非常に大きなことですが、漢字以外のほとんどの文字、
とりわけアルファベット文字圏にとっては、
ほとんど同じ文字が収録されている ISO-8859-1 とか
2 とか 3 とか 15 とか 16 とかを使い分けたり ISO-2022
に基づいた同時使用をしたりするよりは Unicode の
ほうがずっと素直です。みんな、Unicode に移行したくて
うずうずしてると思いますよ。
漢字にしたって、各国の漢字を同時使用しない限りは
Unicode でいいわけで、でもそれはだめだと主張したのが
日本人しかいなくて、中国人も韓国人もそんなに異体字には
こだわらない人が多いっぽいから、けっきょくUnicodeに
反対するのは日本人だけの孤立無援状態になってしまってる、
というのが現状だと思います。
それから、話は戻るけど手間というのが、いちど
ライブラリを作ってしまってあとはそれを使うだけ、
というのならいいけど、アプリケーションレベルでも
それなりに気を使ったプログラミングをしないといけない
わけで、そうすると、現在の、国際化されていないソフトが
どんどん作られ、それに対して国際化パッチを作って対応
しないといけないという状況は改善されません。
理想としては、たとえば素人プログラマが作っても自動的に
国際化されてるというようなのがいいわけで、CSIでは
ちょっとしんどい。といっても、Unicodeに基づいていても、
8ビットフォントを扱うAPIとかを用意しているようじゃ、
だめなんだけどね。
Re:Unicode vs CSI (スコア:1, 参考になる)
> いまだにモノが出てこないというのは、
> 仕方がない部分もあります。
X の locale model は昔から CSI ですけど。
Solaris は CSI モデルの上でうまく Unicode を扱ってますけど。
実際のところ、ISO C locale の実装に限れば、
CSI でも UCS Normalization でも手間は大して変わらないか、
CSI のほうが楽でしょう。ISO C locale 以上となると話は別ですが。
あの時 Xutf8 に反対した一人として言うと、Xutf8 の駄目な
ところというのは、現状の Xmb* でできるようなことしかできず、
また全く拡張性もない中途半端な API だというところにあります。
あれではせっかくの Unicode も泣いてしまいます。
一方で、私は UCS Normalization という考え方自体は
否定しません。なぜならば、Unicode は現状で M17N に関して
(いろいろ文句はあるものの)実用的な仕様が定義されている
唯一の系である、というところです。もはや ISO-2022 系の
発展が止まってしまっていることを考えると、
多言語環境を目指すなら、CSI にこだわってもしょうがない
という気はします。
X_LOCALE (スコア:1)
調べてみたのですが、どうやらX_LOCALEのバグ [mycom.co.jp]を見て勘違いしてたようです(^^;)
そりゃX_LOCALE使ってないLinuxだと関係ないはずだ。
どうやら直ったみたい [mycom.co.jp]ですね。
# X_LOCALE使ったことないので適当:D
Re:Xutf8 (スコア:1, 参考になる)
Re:Xutf8 (スコア:1, 興味深い)
そのうえxtermは物議を醸す国際化しかできないので、 リファレンスの役割も果たせていないように思います。
上のacが言ってるとおり、ddxに注力してXサーバーとXlibだけの 配布にするんがいいんじゃないでしょうか?
Re:Xutf8 (スコア:1)
標準添付のアプリケーションはm17n/i18nに難があって使いモノにならないし、
かと言って patch を反映してもらえる状況でもなさげ。
// だから Keith は抜けようとしたのでしょう。
This cookie has a scrap of paper inside. It reads:
If you can't learn to do it well, learn to enjoy.
Aqua (スコア:2, おもしろおかしい)
言い出したらおもろいだろうなぁ……。
Xとの互換インターフェースとかもくっつけて。
でも……スティーブ的にはないだろうな。
やなぎ
字面じゃなく論旨を読もう。モデレートはそれからだ
another side of X (スコア:2, すばらしい洞察)
webサーバとかいろいろ種類があるんだし、
X プロトコル、ドライバ、APIだけ標準化しておけば
ほかの実装はいろいろ種類があっていいと思います。
Mozillaのgeckoみたいにレンダリングエンジンを
別にリリースするとかはどうなんでしょうか。
Re:another side of X (スコア:1)
そんな意味では、 X Server の実装として Java で動作する WiredX [wiredx.net] や Windows で動作する ASTEC-X [astec.co.jp] なんかがありますね。
DirectFB, SDL (スコア:2, 参考になる)
Re:DirectFB, SDL (スコア:1)
http://www.atai.org/guitool/ なんぞどでしょう?
そもそもXってGUIなの?描画ライブラリに近い?
Re:DirectFB, SDL (スコア:1)
描画ライブラリでもないですし、どちらかというとプロトコルそのものがXなのでは?
そしてその実装の一つがXFree86であると思っていたのですが。
XDirectFB (スコア:1)
# 全てのウインドウが半透過しているのに意味があるのかどうか…
Re:XDirectFB (スコア:1)
個人的には Eterm の様に root window が見えるだけじゃなくて、
全ウィンドウが透過してる方が綺麗でイイと思います。
This cookie has a scrap of paper inside. It reads:
If you can't learn to do it well, learn to enjoy.
ユーザにとって。 (スコア:1, すばらしい洞察)
そのことによって開発力が分散してしまって共倒れに
なってしまうと大損害です。
プロジェクトが大きくなると、新規の開発者が入って来にくい状況に
なってしまうのはある程度仕方のないことだと思いますが、
Keith Packard氏が多くを語っていないので分からないのですが
内部にわだかまりがないかたちで解決して欲しいと思う。
そういえば、以前も分裂の危機ありませんでしたっけ?
Re:ユーザにとって。 (スコア:1)
ただ、オープンソースであれば互いに他者の良い所をコピーできるし、開発の速度を損ねる政治問題が少なくなるので、むしろ開発力が上がるケースもあります。この世界の良い所ですね。
Re:ユーザにとって。 (スコア:1)
タレコミから辿れる XFree86.org の ML(Forum?) で Keith 氏自身がメールで
考えを述べています。是非読んでみてください。
This cookie has a scrap of paper inside. It reads:
If you can't learn to do it well, learn to enjoy.
GUIのオープンプロジェクト (スコア:1, 参考になる)
プロジェクト XでXFree86プロジェクト (スコア:1)
その時、David Wexelblatは思った…
# 視聴率稼げそうになくて企画倒れ
こうなってしまったからには (スコア:1)
--
Kenta MURATA
Re:こうなってしまったからには (スコア:1)
そもそも PDF は PostScript の命令を短縮して,Web でのページビューに適したファイル構造にしたものであって,Display PostScript の代案としての Display PDF にはあまり魅力を感じません.
--
Kenta MURATA
Re:こうなってしまったからには (スコア:1)
Kenta MURATA
重要な点では協調 (スコア:1, 興味深い)
どこでも分裂、統合は起きる。
未完成と思っているのであれば、ある面おきなければ不思議。
妥協できる点であれば、協調していくと思う。
分裂した目的に価値がなくなるか、共通の目的ができれば、
また、統合する。
分裂、統合、分裂、統合のサイクルで、真の目的?に近づく。
今回のとは、あまり関係ないかもしれませんが…。 (スコア:1)
昔の
・emacs
・Xemacs
#チョット、関係ないですが列挙
・Nemacs
・mule
を真っ先に連想しました。
いずれ、別れていったプロジェクト同士が歩み寄っていくならば、分裂・各々発展・良いとこをマージ…、って流れになれば良いな、って思ってしまいました。
#まぁ、こちらは全体から見れば、スムーズに連携していったように見えました(はため=ユーザー側からです。キーバインドの違いは目をつぶるとして…。)
でも、今回件はX(GUI)全般に関わってしまうので、
「俺らぁ、Emacsは使ってないから関係ないや」
の様に、楽観視できないので、複数のXが生まれてしまうのは自体が収束するまでXに関わるプログラム全体を巻き込みますね。
#僕もそうなるだろう(汗;
疲れているので、当たり前のことを当たり前のように書いてるな(^^;
閑話休題
dot.kde.orgより (スコア:1)
関連記事 [kde.org]が掲載されたようです。
Re:70年代 (スコア:1, 興味深い)
過激派なんて、せいぜい同じ民族の同じ言語をしゃべる人達だけで集まって、 それでも対立する派がごろごろしてる。。。。ってこれだけだと普通の政党にも 当てはまるなあ。
Re:70年代 (スコア:2, 興味深い)
んで、分裂して、いつのまにか消えてるプロジェクト・とまっちゃったプロジェクトなんて、ごろごろあったりしてね。
だから、ネチネチという意味ではないかなって感じますけどね。
Re:70年代 (スコア:1)
モノ作ってナンボなんだから、当然でしょう。
某刑事ドラマじゃありませんが、開発はリポジトリで起きているのです ;-)
// 新作が楽しみなので ID
This cookie has a scrap of paper inside. It reads:
If you can't learn to do it well, learn to enjoy.
Re:感情 (スコア:1)
逆にハッカーでない人は「技術屋として大切な何か」を失ってる恐れもあるわけだし。
一概にどうこう云えない罠かと思った。
--労使曰く、ひとごとを尽くして神頼み--
Re:感情 (スコア:2, おもしろおかしい)
多少キ印であるぐらいが良い。
捨て身の改革…… (スコア:2, すばらしい洞察)
分裂の後、混乱を乗り越えた本家が、謙虚に冷静に分家の提示したコンセプトを取り入れていった……、とか言う場合、経緯はどうあれ、分家した人は本家に影響を与えることに成功したことになるわけですよね。
……てなことを Xemacs と Emacs を見ていて思いました。 Emacs21 って gtk+2 対応になったんですねえ。
移ろい行く世界…… (was Re:捨て身の改革……) (スコア:1)
>提示したコンセプトを取り入れていっ た……、とか言う場
>合、経緯はどうあれ、分家した人は本家に影響を与えること
>に成功したこと になるわけですよね。
別な言い方をすると、分裂により開発意欲、開発力のある
開発者を失った「本家」が衰退し、結局推進力のある「分家」
系列に呑み込まれることもあると。
あるいは、分裂によりカリスマ性、機動力、実行力に長けた
「分家」が、「本家」を抹消し、無効化し、形骸化させ、
「分家」が「新本家」となり、だれも「本家」のことなど
気にしなくなり、あるいはだれも「本家」が存在したことすら
知らない事態に至っちゃりして、「新本家」が「本家」と
認識する世界になったりすると。
IN EARTH AND SKIE AND SEA STRANGE THYNGES THER BE.
Re:オープンソースのフォークといえば... (スコア:1)
>り、知名度的な問題もあっ てうまくいかないんじゃないかという気が
>しますね。
うまくいかなかった一例だけを挙げてそこまで言う……
>つまり、単に「開発力の分散」というデメ リットしか無く、得るもの
>は何も無いんじゃないかと思います。
なんだそりゃ。こういうのは楽しいからやってんじゃないのか?
IN EARTH AND SKIE AND SEA STRANGE THYNGES THER BE.
Re:オープンソースのフォークといえば... (スコア:1)
こうしてみると、今回の fork も悲観するものじゃないのかもしれませんね。
// むしろ乱立気味の Linux の distribution の方が…(冷汗
This cookie has a scrap of paper inside. It reads:
If you can't learn to do it well, learn to enjoy.
Re:オープンソースのフォークといえば... (スコア:1)
>一面の真実しか語っていないことに気づいてください。
確かに。NetBSDの系譜でMacBSD(386BSDをmacに移植しようとした
プロジェクトで、NetBSD/mac68kに成果のほとんどを引き継いだはず)
について全く触れない、名前も出ないってのは、かなりヘンですしねぇ・・・。
---- redbrick
Re:オープンソースのフォークといえば... (スコア:1)
ちょっと違うと思いますが・・・。
#ええ、もちろんmac68kのページにかなり詳細な記述があるのは
#知ってますよ。
#例えば、NetBSD/mac68kのhistory [netbsd.org]なんかが詳しいですね。
・・・今は、FreeBSD側のbsdの系譜の中の記述に限っての話だったと
思ったんですが、違いましたっけ??
>いちいちportのマージ元プロジェクトについても全部書けとかそういう話?
うーむ、NetBSDのsource treeから移植が始まったものについては
そうは考えていません。
一応、独立したOSとしての386BSD(i386系部分のみの継承)が書かれているのに、
参考となるBSDそのものがあったとはいえ、それを別アーキテクチャ(mac68k)に
移植するところまでやった、かなりの規模のプロジェクトが書かれない
ってのは、なんかヘンじゃないですか?
#PPCのみがターゲットのMacOS Xがあって、なんでmac68kターゲットで
#386BSDを移植したという記録が残らないのか、理解に苦しみません?
#わたしは、非常に理解に苦しむんですけどね・・・(汗)。
>そういうサブプロジェクトも書き始めると訳分からなくなると思うけど。
>#Citrusとかそういうのも書くべき?
Citrusって、BSDの枠組みでの国際化フレームワーク、つまりOSの内部の
仕組みの一部ですよね?
OS内部の仕組みに関わるプロジェクトが記載されてましたっけ?
---- redbrick