AtheOSがまた分裂 60
ストーリー by yourCat
あらら 部門より
あらら 部門より
Anonymous Coward曰く、"オープンソースの BeOS 風 OS として話題を呼んだ AtheOS (サーバが落ちてる？) がまた分裂した模様。派生したのは Syllable プロジェクトで、さっそく ver.0.4.0 がリリースされている。" (…)
"事情をご存知ない方のために「また」の意味を説明すると、今年 3 月にも分裂騒ぎがあり、Cosmoe プロジェクトが派生した。こちらはカーネルは Linux、ウィンドウシステムは XFree86 を使い、GUI やライブラリだけ AtheOS から引き継いだものである。これは BeOS に対する Blue Eyed OS のスタンスに近い。
それに対して Syllable は AtheOS の開発が停滞しているのに業を煮やした別チームが開発を進めることにしたもので、スクリーンショットからも分かるように完全に AtheOS のコードベースを使用している。BeOS は元が商用のためコードベースを引き継げないという違いはあるものの、こちらは BeOS に対する Open BeOS のスタンスに近く、興味深い。
GNU 界隈の一部では、BSD 界での分裂はライセンスに起因するもので、GPL ではそのような分裂は起きにくいと言われていたが、AtheOS は GPL であるのに BSD 的な分裂の様相を呈している。ライセンスと運営の関係についての議論に一石を投じるかもしれない。"
マルチプラットフォーム (スコア:2, 参考になる)
しかし BeOS でしか使えないという弱点があった。
これがもし他の OS (Windows, Linux) でも使えるライブラリで、
BeOS 上では最も性能を発揮するという位置付けで、
しかも非商用フリーで提供されていたのであれば、
今の Qt が収まっている地位に収まったかもしれない。
（OpenTracker [sourceforge.net] が KDE みたいなものになったりとか）
その意味で Blue Eyed OS とか Cosmoe は、
BeOS や AtheOS のソフトを Linux で動かすという、
マルチプラットフォームライブラリの性格を帯びている。
元の BeOS や AtheOS の資産と連動できれば
面白いことになるのにな～って思いませんか？
ちなみに OpenStep は理想に近いものだったが、
フリーで提供されることはなかったし、
Apple も Yellow Box for Windows の提供を断念したことで、
今は OS X だけにしか通じないものに成り下がってしまった。
（その意志は Java が継いではいるけどね）
逆に MS の .NET がマルチプラットフォームで勢力を伸ばす構え。
Rotor (CLI for FreeBSD) や mono が出てきたし、
今後は Kylix.NET なんてのも出てくるらしい。
ともかくライブラリの肝はマルチプラットフォームだと思います。
Re:マルチプラットフォーム (スコア:1)
Re:マルチプラットフォーム (スコア:2, 興味深い)
実際に使ってみたことあります？
GUI に関してはとてもじゃないけど使えないですよ。
以前白山さん [nest.or.jp]がおっしゃっておられたんですが、
Foundation に関してはちょっと手を加えれば日本語も通るので
業務にも使っておられるというお話でしたが、
GUI に関してはさじを投げておられたようでした。
（日本語化さえ絶望的らしい）
GTK+ の Objective-C バインド辺りがまともにつかえるなら
まだ何とかなるのかもしれませんが、
開発止まって何年も経ってるみたいですし……。(-_-;)
Re:マルチプラットフォーム (スコア:2, 参考になる)
Cocoaでいうなら FoundationKit にあたる部分です。API的には問題なかっ
たのですが、実装に「1UNICODEが1バイトに1対1変換できる」という愉快
な仮定を強いたコードがあったので、そういう部分をなおしたまでです。
GUI部分は X WindowSystemに載っかってて、私は X のプログラミングを
ようしないのと、フォント周りがどうなってるか分からないのと、ここに
至って「1UNICODEが1バイトに1対1変換できる」の仮定に依存したコード
をみつけちまったので鬱になったのと、最大の理由ですが「仕事ではFoun-
dationしか使わない」ので「仕事時間中にする理由がない」というのが重な
ってやっておりません。
X の事がきちんと分かっている人なら対処は可能と思います。
で、このFoundation っつーか gnustep-base を使ったものが社内利用だけで
お客様に渡されることもなかった事もあって、日本語化したものは公開して
おりません。隠すつもりはないのですが、正直人に渡せるだけの説明や資料
を作る(正確には作り直す)余力がないもので...
なお、日本語化とは言ってますが、本来通るようにコードをなおしたので、
試す環境もリソースもないから試してないけど他の非ヨーロッパ系の言語も
それなりに通るようになってるはずです。
ちなみに、makefileまわりを直すだけで、ほぼそのまんまのソースがMac OS X
でも動きます。私のプログラムの場合、なおしたのは高速化のためにC使ってた
所だけでした(^^;
Mac OS X でも Linux + GNUstep でも Solaris + WebObjects 4.5 でもまったく
同じソースで動いているものすらあります。
単一のソースで全て済むのは 気持ちいいですよぉ～
# ただし、Linuxはスレッド周りが Machや Solaris に比べてタコ過ぎるので、その
# 為の対応をこまごま入れなきゃいかん事もままあって鬱になりますが... NetBSD
# がSMP+まっとうなスレッド対応してくれたら、Linux なんてポイしちゃうのです
# けど、ねぇ...
---
SHIROYAMA Takayuki : psi@fortune.nest.or.jp
Re:マルチプラットフォーム (スコア:1, 参考になる)
Foundation 上に構築された gnome-objc あたりがあったら もうちょっと使えるんかなぁ…
Re:マルチプラットフォーム (スコア:0)
Re:マルチプラットフォーム (スコア:1)
分裂の要因 (スコア:1)
まあ、ライセンスの変更が原因でforkというケースもありますけどね。例えばReWind [sourceforge.net]とか。
そもそも… (スコア:2, 興味深い)
分裂できることがopen sourceの特徴ではないの？ 特にGPLはそれを明示的に保証しているしさ。無理に妥協をするぐらいだったら分裂したほうが利用者にとっては理解しやすいと思うけどな。
Re:そもそも… (スコア:1)
オープンソースなら世界中の開発者の力を結集できる、って神話を否定するからじゃないかな。
-- wanna be the biggest dreamer
オープンソースが乗り越えるべき問題 (スコア:2, 興味深い)
素直な考え方をすると、世界中の開発者の力を結集できる可能性があるだけです。スケジュールが全くなしというならともかく、(大抵はユーザの圧力によって)スケジュール通りに開発を進めるとなると、どうやって開発者の力を結集させるか、あるいは結集することを保証するにはどうすればいいかという別の問題が出てきます。
ところが、よくよく調べると、開発の元になっているhackingという行為はあくまで自発的にするものという論調が強いんですよね(文書が行方不明なのが残念だが、「研究によれば報酬は動機づけにはならない」というものもある [genpaku.org]そうで)。少なくとも、結集を保証する方法論やそれでどこまでいけるかを論じた文書は私は知りません。
分裂や空中分解を嫌う人というのは、結集の保証が必須であることになかなか気づかず、よしんば気づかされたとしても結集を保証するための方法論が天下りに与えられることを無意識のうちに仮定してしまうのでしょう。実際には頭の中には人を集める具体的な方法が何もないので、実際にやろうとすると「早く動くものを作れ」といわれる一方、そのために必要な人が集まらない原因がわからずに苦しんでしまうわけです。
個人的には、もし開発力の結集が保証できるシステマティックな方法論が見つかったならば、オープンソースによるソフトウェア開発は立派なソフトウェア技術になれると考えています。個人のみならず企業でも必要ならば適切な教育によりすぐに採用できる方法になるでしょう。現状ではそこを乗り越えることができず、単なる比較文化論に終わっているのが残念でなりません。
Re:オープンソースが乗り越えるべき問題 (スコア:1)
例えばもともとオープンソースだったものを企業が流用するとか、必要な機能は全て出そろって後はbug fixだけというところまでmatureになったものならあるでしょう。しかし、企業がscratchからオープンソースの手法を用いて作り上げたものはいまだに聞いたことがありません。
もっとも、オープンソースに関して書かれた各種文書でも、scratchからソフトウェアを作り上げることを取り上げたものはざっと見たところなさそうです(Sambaなどのように事例はあるが、それを詳しく分析した文書が見つからない)。もしかしたらオープンソースのコミュニティは既存のものを改良することに興味はあっても、scratchから何かを作ることにはあまり食指が動かないのかも知れません(そうだとするとSambaは哀れだが)。
Re:そもそも… (スコア:1)
Linux の Distribution の乱立は肯定しているのか、それとも RedHat 以外を知らないのか、疑問に思いました。
Re:そもそも… (スコア:0)
Re:そもそも… (スコア:1)
Re:そもそも… (スコア:1)
Re:分裂の要因 (スコア:1, 興味深い)
Re:分裂の要因 (スコア:3, 興味深い)
AtheOSってコアはKurt氏ひとりが書くということで、パッチすら受け付けてないですよね。Kurt氏がいなくて仮死状態になってしまうこともあったようだし、これは分裂して当然という気がします。Kurt氏もこの開発体制をとっている以上、分裂しても気にしないつもりでやってるんじゃないかと思えますが。
Re:分裂の要因 (スコア:0)
エリックの3部作だったかペレンスの論文だったかに
このことが論述してあった気がするんですが、
見返してみても該当部分が見当たらないですね……。
うーん、見付かったらまた書き込みます。
Re:分裂の要因 (スコア:1)
意味がわからん・・・(汗) (スコア:1)
修正BSDスタイルのかなり自由なライセンスは、FreeBSD/NetBSD/OpenBSD
(商用のBSD/OSは知らないので除外します)で採用されてますが、
同じライセンス形態を採用してて、なんで
「ライセンスに起因する分裂」に見えるのでしょう？？
＃ほんっとに意味わからん(汗)。
＃米国の暗号技術輸出規制に引っかかったとか、そういうことなら
＃わかるけど、なんでライセンスの問題？
＃・・・あ、AT&Tとのライセンス係争の問題？
＃あれは普及に歯止めをかけただけで、i386で動くこと優先の
＃FreeBSDと、マルチアーキテクチャを志向したNetBSDへの開発者の
＃分離には、あんまり寄与しなかったように思うのだけど・・・。
よろしければ、誰かもっと詳しい解説をしていただけませんか？
＃わたし個人の見るところでは、開発ポリシーと、興味の方向が
＃違うから道が分かれただけだと思っているのだけれど、
＃実際は違うのかな？
>GPL ではそのような分裂は起きにくいと言われていたが、
・・・って、ディストリビューション乱立状態の渦中にいる
GPLの主流(あえてLinux全部とは言わない)が、
それを言うのかね(苦笑)？
＃と言っても、Linuxディストリビューションの乱立も、
＃ライセンスの問題ではなくて、開発ポリシーや
＃開発母体の差異に起因するものだとわたしは認識してたので、
＃*BSDとそう変わらない、と思っていたのだけど・・・
＃実は違うのかなぁ(汗)？
---- redbrick
Linuxは分裂しない (スコア:2, おもしろおかしい)
TomがリーダならTomix、BobがカリスマならBobixになるだろうに。
Re:Linuxは分裂しない (スコア:3, おもしろおかしい)
ロボットのポージーが代表で Posix
製薬メーカーの参入で ハリックスとかパテックスとか、、、オイラックス、、、痒いところに手が届く。
オリックスが参入して Orix ってそのまんまじゃん。
スーパーのユニーが参入して UNIX だな、やっぱり｡
「年中無休でOpenしてます」
Re:Linuxは分裂しない (スコア:1)
Re:Linuxは分裂しない (スコア:1)
Tomix... Nゲージの車両に載せれば速度や照明制御、駅におけば進路や信号制御のプログラムが組めるOSっすか?
Re:意味がわからん・・・(汗) (スコア:0)
> 「ライセンスに起因する分裂」に見えるのでしょう？？
> ＃ほんっとに意味わからん(汗)。
確かエリックかペレンスの論文にそんなことが書いてあったんですが、
今はちょっと見当たらないです。
# 誰かご存知ないかな……。
> ・・・って、ディストリビューション乱立状態の
Re:意味がわからん・・・(汗) (スコア:3, 参考になる)
>今はちょっと見当たらないです。
># 誰かご存知ないかな……。
ESRの「ノウアスフィアの開墾」より引用
http://cruel.org/freeware/noosphere.html#SP
Linux と BSD の世界とのおもしろいちがいの一つは、Linux のカーネル（および関連するOS の中心的なユーティリティ）は一度も分裂していないけれど、BSD は少なくとも 3 回は分裂しているということだ。これがおもしろいのは、BSD グループの社会構造は中央集権化されていて、権限をはっきりと線引きすることで分裂を防ぐようになっているのに、中央集権化されていなくて不定型なLinuxコミュニティは分裂を防ぐような手段をまったく講じていないからだ。開発をなるべく開放したほうが、いちばん分裂しにくくなるとしか思えない！
うーん、これを読むと別にGPLだから、BSDライセンスだから何だとは書いていない…
Re:意味がわからん・・・(汗) (スコア:0)
> うーん、これを読むと別にGPLだから、BSDライセンスだから何だとは書いていない…
失礼しました。
BSD だと手元の拡張を隠せるという一般論と混同していたみたいです。
Re:意味がわからん・・・(汗) (スコア:2, 興味深い)
＃「伽藍とバザール」をちょうど読んでた。
>> うーん、これを読むと別にGPLだから、BSDライセンスだから
>>何だとは書いていない…
>BSD だと手元の拡張を隠せるという一般論と混同していたみたいです。
なるほど、理解できました。
＃BSDライセンス下での改変公開の規制の緩さと、BSDで見られる中央集権的
＃(と、外からは見られている)リリースエンジニアリングが、
＃主流の流れを分割しやすいのではないか、と連想的に結びついたわけですね。
うーん・・・(汗)、GPLでも、不特定多数にbinaryを公開しない場合は、
改変部分を不特定多数に公開しなくてよい
(source配布はbinaryを入手した相手だけにするのでよい)のですし、
中央集権的というBSDのリリースエンジニアリングチームに相当する位置に
Linusとその他のkernel開発者が今現在いるように思うのですけど、
それらのことを考えると、わたしには、BSDとの差異がどこにあるか
わからなくなってしまいます(汗)。
＃patchなんて*BSDでも誰でも投稿できますしね。
＃もちろん吟味はされますけど、それはlinux kernelでも同じでしょうし。
＃・・・なにが一番大きな違いなのでしょうね？
＃やっぱりライセンス、なのかな？
---- redbrick
最終的な決定権の持ち主が決め手? (スコア:3, 参考になる)
Linux kernelの場合、実はあのsourceの汚なさ(あれじゃ関数がgrepできんぞ)ゆえに、Linusだけしかsourceの全体像が把握できていないのではないでしょうか? そうなると、patchが飛んできてもどうしてもLinusが見る羽目になるので、最終的な決定権もLinusの手に落ちつくわけです。
例えばFreeBSDだと、src/sysがいじれる人はどんどん自分で修正を加えています。説明責任も、修正を加えた各個人が負っています。NetBSDは若干根回しが必要だったと思ったけど、portmasterという考え方が昔からあるので特定の1名に見せなければというほど厳しいものではないはずです。
他のprojectを見ていても、最終的な決定権が誰に落ちるかというのが結局は鍵を握っているように見えます。Linuxだって、userlandだけ見れば様々なdistributionがあり、それぞれに基本的なbinary群、hier(7)、package管理の方針があります。*BSDな立場から見れば、それこそ分裂に見えるんですけどねぇ...
Re:最終的な決定権の持ち主が決め手? (スコア:1, 参考になる)
> 修正を加えています。説明責任も、修正を加えた各個人が
> 負っています。NetBSDは若干根回しが必要だったと思ったけど、
> portmasterという考え方が昔からあるので特定の1名に
> 見せなければというほど厳しいものではないはずです。
NetBSD の「若干根回しが必要」ってのは、FreeBSD でたとえば
ACPI まわりを「大きく」いじるのに、msmith やら iwasaki やら
takawata やらに相談しといたほうがいい、というのと同レベルです。
細かい変更なら、勝手に突っ込んじまっても文句言われませんし、
あるいは面倒くさいから send-pr してキーパーソンに何とかしてもらう、
というのも良く使われる手です。
実際には、FreeBSD でもそれを忘れて badcommiter 行きになる人も
いますし、NetBSD でも macppc 方面で不幸が起こってますし。
Re:最終的な決定権の持ち主が決め手? (スコア:0)
・forkしていないといっても、実際にはRed Hat等のdis
Re:最終的な決定権の持ち主が決め手? (スコア:0)
でもって現在のlinusはBitKeeperでの管理へと移行してます。
Re:最終的な決定権の持ち主が決め手? (スコア:1)
gentoo.orgの記事 [gentoo.org]
Don't ask me why!
Re:意味がわからん・・・(汗) (スコア:1, すばらしい洞察)
ソースがオープンかどうかでしかないので、
「分裂」という言葉の意味も結局のところ、
「オープンなもの」と「オープンでないもの」への
分裂にしか向いてないんではないかと思われ。
実際、現行の各 BSD 間のソースの融通は非常に活発ですし、
分裂してる部分というのは多分にライセンスや技術的な部分とは
関係ない政治的(というほど立派な理由でもないが(*))な理由によるものです。
(*) 捨て台詞を吐いて飛び出した Theo 君とか、
既存実装への不理解から新しいものをわざわざ作った new-bus とか。
Re:意味がわからん・・・(汗) (スコア:0)
> 同じライセンス形態を採用してて、なんで
> 「ライセンスに起因する分裂」に見えるのでしょう？？
> ＃ほんっとに意味わからん(汗)。
これは確か GPL より BSD の方が分裂しやすいとかいう論調でした。
BSD ライセンスの差異でもめたという意味ではないです。
# 原文はどこだ……。
Re:意味がわからん・・・(汗) (スコア:1)
＃元の論文も伝聞情報を元にした、と言うのだったら、
＃情けなくてちょっと泣けてきますけど・・・(汗)。
>これは確か GPL より BSD の方が分裂しやすいとかいう論調でした。
GPLは派生物にGPLを強制するので、派生して分裂しても双方GPLに
なる、ってだけではないのかな？
＃派生したら、それはそれで分裂だと思うけど。
GPLで、開発者が主流に集まって分裂しにくい傾向がある、ってのは
どういう理由でそうなると言えるのでしょう？
＃もちろん人間同士ですから感情の対立や、志向や意見の違いは
＃あると思うのだけど、それを乗り越えてヒトを結びつける秘訣が
＃あるのかな？？
＃やっぱり、わたしには意味がよく理解できない・・・(汗)。
＃読解力が低いのかなぁ・・・。
---- redbrick
Re:意味がわからん・・・(汗) (スコア:0)
すみません、まだ一時情報が出てこないんですが、
BSD だとライセンスが伝染せず独自拡張を隠しても構わないので、
結果としてフォークの原因になるとかそういう話だったような気がします。
Re:意味がわからん・・・(汗) (スコア:0)
結局は開発体制次第、という至極自明な結論になりそうな。
Re:意味がわからん・・・(汗) (スコア:1)
開発中に目的がsplitしたがゆえにprojectとしてまでsplitしたという例であれば、それこそLinux kernelだって2.4をMarcelo Tosattiに丸投げ [srad.jp]したわけで、2.5と違う方向へ発展してもおかしくない(というよりそれを狙って丸投げした)ですよね。名前が同じだから分裂していないっていう説明自体が甘いような気が。
Re:意味がわからん・・・(汗) (スコア:0)
その表現は思いっきり間違っていると思うんですけど・・・。
Re:意味がわからん・・・(汗) (スコア:0)
Re:意味がわからん・・・(汗) (スコア:1)
Re:意味がわからん・・・(汗) (スコア:0)
所詮マニアの中のマニアくらいしか関心を持ってない AtheOS よりも、
タレコミ者がフレームの種になるような変なオフトピック話のほうに
関心が向くのは必然的なことでしょうなぁ。
追っかけ (スコア:0)
マイナー OS は面白がられるけど手を出す人って少ないのかな……。
Re:追っかけ (スコア:1, すばらしい洞察)
まだやってたんだ… (スコア:0)
Re:まだやってたんだ… (スコア:0)
俺は自称 OS マニアだったんだけど、
今は煽りとかじゃなくて、本当にそんな気がする。
この手の OS の完成度は論外だし、
KDE や GNOME でさえあの状態だし、
やっぱ Windows の天下は安泰かなあ。
俺も折れちゃって今は Windows オンリーに成り下がったし。;-(
Re:まだやってたんだ… (スコア:0)
Unixとしての完成度はこちらのほうが上。
これで、Postgresqlやmysqlなどのデータベース関係や
他の有名どころのプロジェクトが対応してくれればなあ。
Re:まだやってたんだ… (スコア:1)