Slackware, FreeBSDもX.org採用 45
ストーリー by Oliver
ライセンス選択の重要さを再認識 部門より
ライセンス選択の重要さを再認識 部門より
Jadawin 曰く、 "X.Orgが、X11R6.7をリリースしたことは記憶に新しい。それに呼応して本家ストーリーでも示されたように、RedHat, Debian, Gentoo, OpenBSDなどが、XFree86 4.4の不支持とX.Orgへの間接的な支持を表明している。最近の動向としては、Slackware-currentの変更履歴でX.Orgの採用が明らかになっている。また、FreeBSDのX11関連のMLでは、メンテナーのEric AnholtがX.Orgサーバ／ライブラリの取り込み作業の報告をしている。
X11R6.7のリリースドキュメントによれば、X.Orgのサーバ／ライブラリの方がドライバなどが新しく、技術的に優れているらしい。単純な入れ換えでは済まない部分もあるようだが、そろそろ入れ換えを考えてみる時期かもしれない。"
ドメイン名 x.org (スコア:2, 興味深い)
他の1文字ドメイン名.orgは IANA 名義になってるのに。
UNIX系だからとか、親しい人がいるからだとか
そんな理由だと、ちょっとどうかと思う。
# 一応 *BSD ユーザですが気になったので……
[Q][W][E][R][T][Y]
Re:ドメイン名 x.org (スコア:0)
Re:ドメイン名 x.org (スコア:0)
少なくともx.orgというドメインは、XFree86からforkしたX.Orgプロジェクトがスタートする前から、X本体の配布元として存在してます。とりあえず、Motifがオープンソース化された時のプレスリリース [opengroup.org]には、既にwww.x.orgへのリンクが存在してますね。
とい
Re:ドメイン名 x.org (スコア:1, 参考になる)
1988 … Open Software Fundation (OSF) 設立 [intap.or.jp](X Toolkit 推進派 [idg.co.jp])
1993 … MIT から独立したX Consortium [freedesktop.org]が設立。
1994.01 … MIT から XC に X11 の権利が移転。
1994 … OSF, UI (Unix International) を吸収。
1996.02 … OSF と X/Open が合併 [webopedia.com]、Open Group になる
1997.12 … X Consortium 解散、X11 の権利は Open Group に移転。
少なくとも1993年には x.org はあったはずです。
念のため (スコア:1, 参考になる)
Re:念のため (スコア:1)
両チームがどう違うのか、2行程度でだれか説明してください。
Re:念のため (スコア:1, 興味深い)
もうちょっと書くと、XFree86のリリースの遅さが全てを物語っている気がします。私は単なるユーザなので詳しくは知りませんが、プロジェクトが長いこと続いてきた結果、「オフィシャルなソースをいじれる権限を持つ人」と「実際にゴリゴリ開発したいアクティブな人」というのが一致しなくなってきたことによる軋轢みたいですね。違ってたら訂正よろしこ。＞みなさま
＃FreeBSDでも昔に似たような揉め事があった気がするのはデジャブ？(苦笑)
Re:念のため (スコア:0)
Re:念のため (スコア:1)
＃あ、まだ生きてたんだ、と思ってしまった＜TNG
Re:念のため (スコア:1, 興味深い)
多分元記事はDragonflyBSD [dragonflybsd.org]の件を指してるんだと思うんだけど、個人的には、これはNetBSDとOpenBSDみたいに「目指すものが違ってきたから分かれた」というイメージ。つまり違うゴールを目指すために分かれた。
でまぁ、XFree86とX.orgやSambaとSamba-TNGの場合「ゴールは同じなんだけど、そこにいたる道筋の選択で意見が分かれた」という感じに見える。ま、このあたりは主観が入ってるんで意見は分かれると思うけど。
TNGまだ生きてたんだ、という感想についてはまったく同感。TNGの目指してたものはSamba3であらかた実現したことだし、ここらで過去は水に流して再合流してもいいんじゃないかなぁ、と思う。なかなかそこまでは割り切れないとも思うけど。
Re:念のため (スコア:3, 興味深い)
PAOを本家にマージする/しないの騒動からはじまり、次世代FreeBSDのドライバをnewconfigとnewbusのどちらにするかという揉め事があり、newconfig派の中心だった日本コミュニティが「一部でもいいから具体的なnewconfigの実装を見せて提案しよう」とまで考えていたにも関わらず、初期のFreeBSDメンバーを中心に、まともな議論をする前に一方的にnewbus採用が決定されてしまいました。
以下、偏見を大いに交えて書きますが、結局、当時のcore teamからは「俺達の作ったFreeBSDに東洋の島国のやつらが何か言ってやがる」という扱いをされてしまい、すでに実績のあったPAOや(NetBSDで実績のあった)newconfigなど全ての提案を否定された上に、一時期は「PAOはbuggyだから使うな。∵PAOはnewbusじゃないから。... ただ、まだnewbusはFreeBSDに実装されてないんだけどね;-p」みたいな支離滅裂なことまで言われました。
で、その時のPAOやnewconfigへの反対派は実はすでにFreeBSDからは離れつつあるメンバーだったこともあり、そのときにcore teamの選挙制度が新たに作られましたし、Warnerのように日本の開発者コミュニティと真剣に付き合ってくれる人もできたので、結果的に得るものが無かったわけではないです。でも、制度の整備が遅れていたために失ったものは多かったです。一部の開発者は、このときを境に離れていってしまいましたし、NetBSDとの親和性が失われたのはBSDファミリーの一員として非常に痛かったように思えます。
＃もし当時JapanBSDができてたら、どうなってたのかなぁ...
Re:念のため (スコア:0)
Re:念のため (スコア:0)
Re:念のため (スコア:0)
こちらもご参考に。
日本語版は (スコア:1)
#でも英語版の方が情報量が多いです。
Re:念のため (スコア:0)
XFree86:やる気なし
X.Org:やる気満々
# ぐらいで当たらずとも言えど遠からず？
Re:念のため (スコア:2, おもしろおかしい)
つまり、
XFree86は、「エックス古い野郎」となる、つまり既にobsoleteであると自ら名言している。
Re:念のため (スコア:0)
対抗するにもX.orzじゃぁガックリだなぁ．
…え，X.orgでしたか!
# オヤヂギャグにもならんのでAC (!公共広告機構)
Re:念のため (スコア:1, すばらしい洞察)
X.Org: Xたろうとしつづけている
# なんてのはどうかな?
やっと使える… (スコア:1, 参考になる)
5月前半の時点でxorg-serverのport(およびそれに関連するxlibのport)はFreeBSDのport treeに既に存在していた。だけど、xtermやxdmなど、Xの標準配布物に入っているclientのportがXFree86側のものしか存在していなかったため、クリーンインストールした場合、portsのみを利用してX11R6.7の環境を構築することはできない状況が続いていた。
XFree86-Server-snapがbuildできない(BROKENが付いてる)FreeBSD/amd64で、かつVideoチップの都合上最新のX Serverを必要としていた１ユーザーとしては「どっちでもいいから早いとこ使えるようにしてくれぇ」ってのが本音。amd64のネイティブバイナリなんてもんは、XFree86もX.Orgも公開してくれるわけがないし。
一応手動buildは試みてみた(XFree86 4.4.0とX11R6.7の両方)んだけどね…挫折したのよorz
Re:やっと使える… (スコア:2, 参考になる)
出そろってますね。
事情のある人は、そろそろ試す時期ではないかと。
普通の人は、他のportsの移行を確認してからでしょうか？
＃XFree86-4-librariesに依存しているのが大分あるんじゃないかと。
X11R6.7に移行するのはもうちょっと時間かかるかも (スコア:2, 参考になる)
最大の問題はxorg-librariesとXFree86-4-librariesの共存が出来ないことかと。
この為、依存してるportsをまとめていっぺんに切り替えないと、インストールできないportsが多発する可能性が…
とは言ってもいっぺんに切り替えるのは無理だから、xorg版のportsを作って徐々に移行するのかな？
たとえば今はemacsはXFree86版だから、emacs-xorgとかを作ってから時期を見てemacs-xfree86に移行して、時間がたってからxorgの方をemacsに変更するとか。
あるいは、メジャーバージョンアップのタイミングで切り替えるか？
このへんはメンテナの考え方次第だから物によって対応が異なる可能性が高いと思うけど…
ちなみにFreeBSD/i386でX.orgのtar ballを展開してコンパイルすると、そのままではエラーになります。
解決方法はFreeType2Dirを指定してあげるか、組み込みのFreeTypeを使うかですね。
ただし組み込みのFreeTypeを使ったときはXのconfigからLoad freetypeを外さないとstartxでエラーになります。
次のX.orgのリリースではこの辺の問題を解決して欲しいですねぇ…
FreeBSD/amd64は手元に無いのでわかりませんが、ビルドはそんなに難しくないような気がします。
腐乱化…もといFlanker
Re:やっと使える… (スコア:2, 参考になる)
多分それは問題にならないです。portsのRUN_DEPENDSやLIB_DEPENDSは、データベース的な依存関係ではなく、プログラムやライブラリ自体をサーチパスから探してるはずです。つまり、要はlibX11*というライブラリが存在すればいい訳で、それがXFree86のものかxorgのものかは区別してないと思います。ライブラリ関数のインターフェースが変わってたりすれば当然ダメですが。
まぁ、今buildしてるところなので、放っておけばそのうち判りますが（ｗ
Re:やっと使える… (スコア:1, 参考になる)
のようなことが万が一にも発覚した場合には、現在のUSE_XLIBを暫定的にUSE_XFREE86_LIBにおきかえ、新たにUSE_XORG_LIBをつくってから、どちらのXlibでもいけることが確認できたportsだけUSE_XLIBにすれば...って、面倒くせーーー！！！
ま、FreeBSDのportsは単純なワリにけっこう良くできてるので、(上記のような手順になるかどうかは知りませんが)portsの枠組み内で対処することになるんでしょうね。少なくと個別のportsについてXFree86版とX.org版を明示的に分離することは無いでしょう。それでも、とにかく面倒くさいことは明らかですが。
っていうか、もしその辺りのインタフェース互換すら無くなったら、そもそもX11である意義が激減だし、実際にアプリ作ってる人もどっちを使えば良いのか悩ましいですよね。あぁ、でも、そうやってデファクトスタンダードを取った方が生き残るという弱肉強食も面白いかも。
依存モジュールのCONFLICTSが問題になるのでは？ (スコア:1)
portsでインストールする時に問題になるのは依存モジュールのMakefileにあるCONFLICTS指定でコケる事じゃないかと。
まだ試していないのでなんともいえないのですが、ports AはXFree86依存、ports BはXorg依存と言う場合に、
先にports AをインストールするとXFree86-4-librariesがインストールされますよね、
その状態でports Bをインストールするときに依存モジュールのxorg-librariesをインストールしようとしてCONFLICTSでエラーになるとインストール出来ない。
この状態が発生しないように出来れば、問題ないわけです。
この辺はメンテナの腕の見せ所というところでしょうか。
逆に例えば、
cd /usr/ports/editors; cp -r emacs emacs-xorg
とかやってMakefile等をxorg用に修正すればxorg版が（多分手軽に）作れると思いますから、
手軽にxorg版を作りたいならこちらの作戦になるかと。
腐乱化…もといFlanker
現実問題として (スコア:3, 参考になる)
XFree86-librariesとxorg-librariesのコンフリクトが問題になることは現時点ではありません。何故かというと、関係するであろうxorg-clients自体が
という依存関係になっているから（ｗつまり現時点のports上のXの実質的な選択肢は
- XFree86-libraries＋XFree86-server(-snap)
- XFree86-libraries＋xorg-server
という組み合わせだけだと思います。細かく言うと、xtermなどのX標準添付のclientをbuildするときには、XFree86-librariesが必要になるので、xorg-librariesはxorg-serverをbuildするためだけにしか使えない。んで、xorg-serverはXFree86-librariesでもxorg-librariesでもbuildできる（はず）。ということで、結局のところxorg-librariesって宙に浮いちゃってるんですね。
今後のFreeBSDのX環境はModular libraries [freedesktop.org]に移行してくというのがメンテナの考えのようです。なので、xorg-serverがportsに入った当初は、Modular librariesのmeta portであるx11/xlibsに依存してました。でも、これだとX serverはbuildできても、xdmやxkb関係など、周辺ツールが一切入らないので、portsの枠組みの中でX.orgなX環境を整えようとすることが出来なかった訳です。おそらく#560588 [srad.jp]が言っているのはそういうことだと思います。
xorgのports単独で見れば、まずは最新のXを欲しがる人（私のような（ｗ）向けに、それぞれのportsの独立性はひとまず無視して、とりあえず使える環境を用意した、というのが現状だと思います。
…で、我が家のFreeBSD/amd64でxorg-clientのbuildがコケた原因追求はまた明日ですねorz
Re:現実問題として (スコア:1)
実際のところですね、XFree86-4.3.0が入ってるところにX11R6.7.0のtar ballから上書きインストールしちゃっても問題なく動作するのでXの方の互換性は現時点では殆ど問題ないだろうと思います。
ということで、xorg-librariesは他のportsがxorgに移行するための下準備なのではないかと。
一方、xorg-clientsですが、これはFreeBSD/i386でビルドしてもエラー落ちしますねぇ（苦笑）
で、原因は…なんじゃこりゃ？xdmで落ちるのでソースを見るとsession.cの58行目でヘッダファイルと違う形でプロトタイプが… orz
せっかくパッチ当ててるならここも当ててよ～とか言いつつこれを消したらエラー出なくなったけど、今度はxhostで落ちる… _no
あぅぅ…これって実はまだBROKENを付けとかないといけない状態ではないのか？（汗）
腐乱化…もといFlanker
Re:現実問題として (スコア:3, 参考になる)
- x11/xorg-libraries
- x11-servers/xorg-server
- x11/xorg-clients
という順番でインストールしていったら、何となく入ってしましました…。xorg-clientsが一番にインストールすると失敗。xorg-serverを一番にインストールしようとするとXFree86-librariesを入れようとするし、XFree86-librariesの後にxorg-librariesを入れようとするとconflictしたので、この順番がよいかと。
LIB_DEPENDでXFree86-librariesになってるところも取り敢えず、xorg-librariesが入ってることでインストールせずに済みました。
あとはフォント周り(x11-fonts/xorg-fonts-*)がx11/XFree86-4だ(x11-fonts/XFree86-4-*ですが)と一緒にインストールしてくれましたが、自分で入れていかないといけないのが面倒かと。ということで、x11/xorgなるものをプリーズです。
# 早く研究環境作り直さないといけないのに、こういうコトしてたらいつまで経っても…
Re:現実問題として (スコア:0)
xorgのportsを作ろうとして挫折しました orz (スコア:1)
deinstall出来ない暫定版なら手元にあるのですが、他のportsがXFree86-4-librariesに依存してる現状では、これの価値はあまり無いですね。（苦笑）
Xだけインストールすれば良いという状況は少なくて、多くの場合は他のXアプリやライブラリも必要になりますから。
他のXアプリもソースからインストールしちゃうような人の場合はtarballからインストールできると思いますから、どうしても必要な方が居るようでしたら情報提供しますが…
＃xorg系のportsはまだ開発途中みたいで、色々細かい問題がありそうですね。
腐乱化…もといFlanker
Re:やっと使える… (スコア:1)
(しかもSunの国際化やってた人まで巻き込んで)
XorgのX11ライブラリではどうなってるんだろう...
Re:やっと使える… (スコア:0)
X.org on FreeBSDまとめ (スコア:0)
#560588のACです。とりあえず昨日の結果報告。
の順番ならインストールできます。何故かportinstallが使えなかったけど。
失地回復はできないでしょうね。。。 (スコア:1)
反発したらXFree86はライセンスを元に戻しても
失地回復はできないでしょうね。。。
Re:失地回復はできないでしょうね。。。 (スコア:1, 参考になる)
新しいライセンスの配布物から問題の条件を取り除くのは面倒ですよ。
＃xfree86の新しいライセンスは、導入直前にforkされた段階で
＃終わってる気がするんだけど。
どっちだろうがかまわない (スコア:1)
問題はグラフィックチップ/ボードメーカのプロプラなドライバが出るかどうか. なにしろ性能(特に3D関連)や機能(マルチヘッド等)で標準のドライバとは比較にならないぐらい良いですから.
ということで私はしばらくはXFree86とnVIDIAドライバの組み合わせで静観です.
UNIXなんだから (スコア:0)
#窓は選べないのでAC
Re:UNIXなんだから (スコア:1)
シェル [sourceforge.net]をオープンソースで
作ってる人はいるけどWindowManagerを作ってる人は
聞いたことがないな
#litestepもWindowsシェルとして動くね
やなぎ
字面じゃなく論旨を読もう。モデレートはそれからだ
Re:UNIXなんだから (スコア:0)
WindowManagerじゃなくてWindowシステムか。
------
やなぎ
確かにそうだが (スコア:0)
パッケージ管理システムにどっぷりつかった身としては、誰かがバイナリパッケージを提供してくれる方しか使えません、ハイ。
堕落したような気はするが、今更昔には戻れないAC。
くだらない争いは (スコア:0)
Re:くだらない争いは (スコア:0)
今XFree86 4.4採用してる所も遅かれ早かれX.orgに移行するだろうし。
いつのまにかVineも (スコア:0)
3.0で本格採用？ということでしょう。
apple/MacOS Xは？ (スコア:0)
10.2.8ではX11R6.7.0がビルド＆インストール成功して (スコア:1)
もし成功したようならrootでインストールすれば使えるようになります。
＃私はsudoでインストール出来るかどうか試してません。だれか試した人が居たらコメントお願いします。
問題になりそうな点は、ルートレスモードで起動してしまうとtwmのメニューが出ないという点でしょうか。
デスクトップをクリックしたらFinderに制御が移ってしまって…
ルート表示モードだと普通にXとして使えるけど、これだと他のアプリと連動させるのがねぇ…
他のウィンドウマネージャは全然試してないので、どれが使えるかはわかりません（苦笑）
MacOSXの場合はアプリのビルドが一番問題になるかも。
Darwinって癖が強いからなぁ…
腐乱化…もといFlanker