Linux 2.6.20リリース 100
ストーリー by kazekiri
順等なペース 部門より
順等なペース 部門より
2/4付でカーネル2.6.20がリリース(Changelog)されています。コードは各地ミラーに転送されているので、ftp.jp.kernel.org等から取得できると思います(ちなみに、今朝7時半ぐらいにftp.jp.kernel.orgから落とそうとしたらミラー中だったのか中途半端に落としちゃいました)。
内部的な変更はまとまった情報が拾いにくいため把握しきれていないのですが、過去の情報からすると、
* PLAYSTATION3対応(cell CPU)のコードが入っている
* KVM(kernel VM)が入ったことでpara-virtualizationがしやすくなった
という部分はそれなりに大きいと思います。
それにしても、git化されてからchangelogの類が細かくなりすぎて、どこかに「～が変わったよ」という概要の情報が得にくくなってるという気がします。こういうのってちゃんと知りたかったらソースとMLをちゃんと追うかしないといけないんでしょうか。みなさんどこからネタを得てるんでしょうか、あわせて情報を求めたいような気もします。
2.6.20 Changelog (スコア:5, 参考になる)
屍体メモ [windy.cx]
Re:2.6.20 Changelog (スコア:4, 興味深い)
2.6.20-rc6(7?)あたりから起きている、vt8237をsata_viaで使うと、SATAドライブ（日立製）が突然ロックアップして止まる現象の原因らしき事が-rc7以降のパッチで改善していると書いてあるのですが、どんなものだか(;´Д`)
2.6.20-rc7時点の安定性を考えると、又、例によってUnstableなのかもしれないな(;´Д`)と思ってこわごわと様子を見ています(^^;
ieee1394(Re:2.6.20 Changelog) (スコア:1)
lkmlでバグレポートとパッチが錯綜している状況で全て追いかけるのが容易では無いですが、このスレッドあたり [iu.edu]が根本的な解決策のひとつかもしれません（って、これから色々パッチを試していく訳なので可能性の提示だけに留めておきますが）
それにしても、2.6.20-rc1段階でコードを大掃除しただけならばいいんですが、それが設計にまで踏み込んだ「掃除」であったがためにバグを埋め込む原因になったり、それ以前に次世代の新しく根本から設計しなおした1394スタック（これは、http://www.linux1394.org/ [linux1394.org]で公表されていましたが、今は開発凍結中の模様）が既にSVNにCommitまでされているのにそういうリスキーな「大掃除」をやるか？とか、今回の件に関しては、メンテナ氏の考えと言うか思考回路を疑ってしまいます(;´Д`)
Re:2.6.20 Changelog (スコア:3, 参考になる)
だからこそ概要程度のものが欲しいというわけです。@ITの記事の方とかがすごいと思います。
2.6.19シリーズのmmap壊れ問題かどうかはわかりませんが、2.6.19が出た直後に差し替えたら多くのサービスがなぜかコケるという事態に遭遇し、2.6.18.3に戻したことがありました。
今回は特にそういう問題もなさそうなので少し安心してます。
-- やさいはけんこうにいちば〜ん！
Re:2.6.20 Changelog (スコア:4, 参考になる)
すると、スクリプトでダイジェストっぽいとこだけ拾えそうな感じがしたのでやってみました。
http://fuga.jp/~densuke/diary/?date=20070205#p05 [fuga.jp]
フォーマットに変化がなければ、今後も抽出できるかも。
-- やさいはけんこうにいちば〜ん！
Re:2.6.20 Changelog (スコア:4, 参考になる)
Re:2.6.20 Changelog (スコア:1, 参考になる)
ここにもちょっとだけありました。タイトルが2.6.12になってますが、内容はそれっぽいです。
Re:2.6.20 Changelog (スコア:1, 参考になる)
これ、カーネル側に問題があったってことかねえ。
Re:2.6.20 Changelog (スコア:1, 興味深い)
3年前と2年前にファイルシステム(ext3)のバグによるデータ破壊に泣いているので、
Linuxのファイルシステムは信用しないようにしてます。
ext3 は枯れていると信じたい (スコア:2, 興味深い)
あくまで願望でしかないんだよなぁ。
実際、mmap 周りが犯人とはいえ今回もデータ飛んでるし。
自分は今のところ致命的な自体は経験したことが無いけど単に幸運なだけか。
その「経験したバグ」ってACL周りとかじゃなくて、
ファイル本体あるいはファイルシステム全体が吹っ飛ぶような状態？
今の仕事では業務データの多くが AIX5L JFS に入ってるんですが、
さすがにこういう商用のものは大丈夫なんだろうな。
屍体メモ [windy.cx]
Re:ext3 は枯れていると信じたい (スコア:2, 興味深い)
ジャーナルまたは、キャッシュの書き戻しに問題があったらしく、
ファイルを編集してしばらくは大丈夫だけど、数時間後、ディスクに書き出されるときにファイルが破壊されていきました。
問題のあるファイルを特定し、バックアップから修復、動作確認をして、一息ついたころに、ファイルがぶっ壊れる恐怖。
ファイルシステムのバグの前には RAID も無意味なんで、もっと安定させて欲しいものですね
Re:ext3 は枯れていると信じたい (スコア:1, 興味深い)
>さすがにこういう商用のものは大丈夫なんだろうな。
私の経験でも、Linuxではファイルシステムを壊した経験があるけど、
AIXのJFSでは無いなあ。
（HDDの故障はしょうがないとしても）
4L時代のJFSは頻繁にdefragfs をやる必要があったのは鬱陶しかったけど。
でも今の職場はext3がごろごろ。たーくさん。
Re:ext3 は枯れていると信じたい (スコア:1, 興味深い)
＃かなり作り直したからAIX向けJFSのソースツリーとは別らしい。
結局商用かどうかじゃなくて、枯れるまで時間と人的リソースをつぎ込めたかどうかじゃないのかな。
＃OS/2向けはそれができずに最後までHPFS386からの乗り換えを促すことが出来なかったと思う。
Re:ext3 は枯れていると信じたい (スコア:1)
集中してパッチを出してくれますから。
まあ、そういうところに商用としてお金を払っているんですけどね。
やっぱり業務で使う分には物理的に他メディアへバックアップを取る
のは管理する側からすれば当然なので、たとえデータが飛んでも、
OSメーカに文句は言っても、泣き言は言わない。
私のところはHP-UXが多いのですが、ファイルシステム関連のパッチ
はHPからバラバラとよく出てますね。相当クリティカルだというもの
しか適用しませんけど。
そもそも正しく書き込めないのが困る (スコア:1)
改竄対策で Tripwire のようなもの（ハッシュとかその他もろもろの付加情報も取る）を作ってファイルのデータベースを作成し、定期的に健全性をチェックするということは（要件に入っていたので）やっているものの、リアルタイムではないしそもそも最初から正しく書き込めてなかったりしたらどうしようとか orz
考えすぎると眠れない。（考えなければ眠れる）
屍体メモ [windy.cx]
HFS+ (スコア:1, 興味深い)
FAT32のWindowsはあまり壊れた記憶がないですね。
もう少しHFS+もどうにかしてほしい。
Re:2.6.20 Changelog (スコア:1)
SGI出身の結構実績のある（はず）ファイルシステムなのですが、CentOS ではデフォルトで対応してなかったり。
ファイルシステムも何種類か調べてみたんですが、付加価値（や実績）を求めると、フリーのものには「これだ！」というものが無い気がします。
ん？ 俺、今何か言った？
Re:2.6.20 Changelog (スコア:1, 参考になる)
ソースの数十MBってのはもちろん、モジュール化したのに圧縮しても数MBって何やねん。
make zdiskでフロッピーに書き込んで起動チェックしていた頃が懐かしい…。
Re:2.6.20 Changelog (スコア:1)
ペンギン
次はなんだろ
旅に出ます．(バグを)探さないで下さい．
やっぱり日本語 (スコア:5, 参考になる)
Linux Kernel関連のまとまった情報というと、Linux Kernel Watch [atmarkit.co.jp]が一番ありがたいですね。
月イチ連載なのでリリースとタイミングが合うとは限りませんが、大きな変更が入る場合は話題として取り上げられますし(その手の大変更は、リリース前から議論になってる場合が多いから)、なんたって日本語で読めますから。
# どうせすぐに追従するわけじゃないしね。
変更点の要約 (スコア:3, 参考になる)
full-virtualization (スコア:1, 参考になる)
IntelのVTやAMDのSVMがあるCPUを搭載した環境であれば、
KVMでfull-virtualizationも出来ますね。
性能向上してるみたい (スコア:1, 参考になる)
権利者 (スコア:1)
かなりの数になってるんじゃないかと思うんだけど。
それぞれの権利者の情報とかって、集中管理されてたりする？
案外、そこらへんは適当に放置されてたりするんじゃないかと思うんだけど。
この間のJASRACを中心とした著作権情報の集中管理を見て、オープンソースのそういった所が気になった。
みんなJASRACは嫌いだろうけど、見習える所は見習ってもいいと思う。
Re:権利者 (スコア:2, 参考になる)
新規ファイルであれ、パッチの採用であれ、そのソースコード上にGPLが宣言されている以上、それに従って利用できるし、書いた人でさえ変に覆すこともできない。
まあ、だからこそ商用のもののコードが交じったりすることに対して敏感になってるし、2足の草鞋な人はそれぞれの成果が混入しないように留意しているわけですしね。
# 会社と面談したことあるのですが、あえてIDで
M-FalconSky (暑いか寒い)
Re:権利者 (スコア:1)
GPLといえども、著作権に基づいたライセンスですから、他の著作権が面している問題を同じく持っていますよ。
今はまだ大きな問題ではありませんが、今の法律のままでも、権利者が死んで５０年経てば権利は消えます。
そうでなくても、権利者が死んで、相続する人がいなければ、その時点で権利は消えます。
著作権の権利が消えれば、それ以降の利用にはGPLに従う必要も無くなるのです。
また、現状でも、権利者と交渉して、GPLと矛盾しないダブルライセンスにしてもらえば、
他のライセンスでの運用を可能にできたりしませんか？
そういった著作権の運用に関して、オープンソースは、JASRACに大きく遅れてる気がします。
Re:権利者 (スコア:1)
>GPLといえども、著作権に基づいたライセンスですから、他の著作権が面している問題を同じく持っていますよ。
一回GPLで出したコードは次のバージョンで非GPLとなっても
利用可能だから、誰かがGPLバージョンを引き継いで開発すれば問題ないですよ。
# たぶん・・・
# ライセンス問題はややこしいのがいやだからBSD like
# ライセンスを選んでる人もいるんじゃないかと思う
Re:権利者 (スコア:1)
>利用可能だから、誰かがGPLバージョンを引き継いで開発すれば問題ないですよ。
引き継いだ人の権利は、引き継いだ人が作ったものにしか適用されませんよ。
元のコードの権利はそのままです。
Re:権利者 (スコア:2, 興味深い)
Linuxカーネルのソース -> GPLによるライセンス(著作権を背景とする)
-> GPLはライセンスという契約形態にすることで、オープンを強制しフリーを維持する。
Linux上での著作権切れのコード -> そもそも著作権的にフリーとなるため、再利用や改変に制限は必要ない。
-> なので、それらのコードを含むGPLなソースが存在してもライセンス的に矛盾しない。
-> Linuxカーネルなるソースコード群はメンテナンスされつづける限りにおいて最新版では全体がGPL対象になる。
となるような気がしますが。
なんか間違ってますかね?
# GPL的な強制オープンは旧版のものには無理がありますが、最新版でないと利便性が低く、あまり意味がないと思います。
M-FalconSky (暑いか寒い)
Re:権利者 (スコア:3, 参考になる)
>-> GPLはライセンスという契約形態にすることで、オープンを強制しフリーを維持する。
ライセンスは利用者と権利者との間の契約です。
著作権が有効な間は、契約無しに利用すれば著作権法違反になるので、必ず契約する必要がある。
>Linux上での著作権切れのコード -> そもそも著作権的にフリーとなるため、再利用や改変に制限は必要ない。
>-> なので、それらのコードを含むGPLなソースが存在してもライセンス的に矛盾しない。
著作権切れのコードをGPLなコードとあわせて利用するのは問題無いと思います。
>-> Linuxカーネルなるソースコード群はメンテナンスされつづける限りにおいて最新版では全体がGPL対象になる。
ソースコード郡として利用するなら、そこに有効なGPLなコードが１つでもあれば、全体がGPLになると思います。
ですが、カーネルのソースコード全体を利用せずに、一部だけ利用したいって場合に権利の所在と有効性の確認は重要だと思います。
Re:権利者 (スコア:1)
そもそもそのコード片を複雑な状況をクリアにしてまで再利用したいのであれば、そこにコストを払えばいいのだろうし、権利者ら（個人であったり、IBM などの企業)は Public Domain や修正 BSD ライセンスなどでのリリースをしていない時点で、GPL ライセンス下での利用、あるいはそのあたりのコストを払わないと利用できない状況を望んでいたりはしないのでしょうかね。
Re:権利者 (スコア:1)
「GPLは、契約なのか. 単なる不行使宣言なのか. 」 [osdn.co.jp]という方もいらっしゃいますし。
GPLv3でもDraft1のときに「契約ではない」と本文に明記されたので、契約で片の付いていた国から反対にあって、Draft2で削除されたとか。
ライセンスは契約と解釈するのが日本法での一般的な解釈なのかもしれませんが、 GPLがそうかはグレーっぽい。
> ですが、カーネルのソースコード全体を利用せずに、一部だけ利用したいって場合に権利の所在と有効性の確認は重要だと思います。
そもそも、いちいちそういうことで問い合わせられても面倒くさいので、そういうこと無しにフリーに使ってほしいというのがGPL.
他のライセンスにしてほしい？原則却下。(FAQにその雰囲気は伺える [gnu.org]) だから再頒布の際、同じライセンスで配布を義務付けている。
そうやって、問い合わせる必要無いようにしているのがGPL。
そう解釈しているのですが、違いましたかね？
Re:権利者 (スコア:1)
GPLとして利用する人達にとっては、GPLとして引き継がれたものを利用していけば良いだけです。
でも、GPLが切れた後に、フリーなコードとして利用する事を考えると、引き継がれたコードの権利は引き継いだ人のコードにだけ適用されるというのは重要です。
Re:権利者 (スコア:1)
そういう事を、権利者を集中管理してれば楽なんじゃないの？と思ったのですよ。
他にも権利者の情報が整理されれば、GPLを守る為にも役立つだろうし。
でも、#1104782が書かれているように、ソースに必ずそのコードへの著作権者の名前が明記されていて、その人に連絡を取ればいいだけなら、それでいいのかも。
どれだけの人の名前や連絡先がそこに並ぶのか知らないし、連絡先が変わるたびにソースコードを書き換えていく事になるんでしょうけど。
Re:権利者 (スコア:2, すばらしい洞察)
JASRACを引き合いに出すのは構わんが、その前に何のために権利者の情報を管理するのかまず考えような。
JASRACは徴収した著作物の使用料を再配分するために権利者の情報を管理する必要があるが、GPL2の下で自由に使っても良いことが保証されてるLinuxカーネルで、権利者の情報を管理する必要が本当にあるのか？
Re:権利者 (スコア:1)
とりあえずは、ドキュメントのライセンス事項(この場合はGPL v2.0)に入っている"as is"とか"No warranty"と言う言葉の持つ本当の意味を噛みしめて見ては如何でしょうか？
# 基本的には免責条件の為の文句であるのですが…
Re:権利者 (スコア:1)
なんだろ、こんなに激しくコメントが来るとは思わなかった。
そんなに権利の所在がハッキリするのが怖いのかな、オープンソースな人達は。
Re:権利者 (スコア:2, 興味深い)
Re:権利者 (スコア:1)
とても興味深いお話なのに、「"as is"とか"No warranty"と言う言葉の持つ本当の意味」ってだけじゃ、理解できませんでした。
できれば、そのFOSSと商品ソフトウェアの根底的な思想の違いを具体的に教えてください。
権利のありかたを、JASRACとオープンソースは同じにしろと言ってる訳じゃなくて、権利の情報は集中管理したほうが良いのではないかと思ったのです。
思想の違いで違ってくるんですね。
そこを説明してもらえるとありがたいです。
Re:権利者 (スコア:2, 興味深い)
今はまだ、コードのほとんどは権利者が生きてるでしょうし、権利は生きてるって仮定で行動してるだけだと思います。
でも、実際には、権利が切れてるかもしれない。
そこをハッキリさせるのは、GPL違反してるかも知れない人にとっても、GPLを守りたい人にとっても良い事だと思います。
Re:権利者 (スコア:2, すばらしい洞察)
逆に、権利の所在がはっきりしてしまうと、著作権がきれたときに、GPLの思想に従おうとしない奴にとっては簡単にパブリックドメイン扱いで利用できてしまいます。それは少なくともGPLで配布されることを望む元の著作権者にとっては不都合なことなのです。とはいえ、そんなことは自分の死んでから50年たった後のことなので、その点は全く気にしていないでしょうが。
彼らにとって権利の集中管理をすることに全くメリットはなく、むしろそれは負担でしかないと思います。
GPLを守りたい人にとっては、自分は権利は生きているという仮定だけで行動すればよいです。例え、権利がきれているものがGPLの思想に従わないようにに利用されたとしても、それは著作権を集中管理したからといってどうにでもなるものでもなくて、著作権法上しかたのないことです。GPL違反しているかもしれない人にとっては、権利関係が不明ならライセンスどおりにGPLの元でやれば？ということだと思いますし、それはGPLを守りたい人にとっては都合のいいことです。
# 「〜が大事」「〜が良いこと」と言うが、具体的にどんなよいことがあるのか説明してもらいたい。
Re:権利者 (スコア:1)
連絡が付かないコードについては、金を払えば使えちゃう訳ですね。
今は、文化庁長官の裁定が必要ですけど、先日の共同でデータベースを作るというニュースの中には、その一環として、その手続きの簡略化を目指すってのも含まれています。
この権利者不明の著作物の利用を後押しするって案が通れば、権利者不明のGPLコードは、お金を払えばGPLに縛られずに使える可能性が出てしまいます。
今、Linuxカーネルのコードの中で、権利者が不明だったり、権利者へ連絡の取れなくなっているコードは無いのでしょうか？
権利者の情報のデータベースを作ったり、権利の認可の代行を行う仕組みを作っておけば、権利を有効に使えると思います。
Re:権利者 (スコア:1)
元のコードの権利は、そのコードを書いた人にあるので、そこからの派生物の権利者は何も言えないと思います。
そのコードを書いた人、もしくは権利を委譲されている人へ連絡が取れる状態にしておくべきです。
Re:権利者 (スコア:1)
「権利者の連絡先」は不明だけど「権利者」と「利用条件（ライセンス）」は明確になってる、という場合にも適用されるんですかね?（これらは各ソースファイルに埋め込まれてるはずですが）
もし GPL のような利用自体は自由、というライセンスに対してまで「供託金を払えばライセンスの範囲外で利用可」という制度が適用できてしまうのであれば、確かに問題だとは思いますけど、でも逆に言えば、そうでもない限り FOSS の開発者にとってデータベースを作って維持するコストに見合うほどのメリットはないんじゃないでしょうか。
権利の許認可を便利に行いたい人にとっては、データベースは有意義でしょうけど、GPL はそもそも個別の許認可など必要なしにすべてのコードが自由に使えることを目的に生まれてるワケで、そんなライセンスを選ぶような人たちが「権利の認可の代行を行う仕組み」に手間と暇をかけたりはしないんじゃないかなあ。
Re:権利者 (スコア:1)
デュアルライセンスいう形があるんだし、適用されるんじゃない？
GPLで公開されているコードの権利者に、デュアルライセンスでコードの利用をお願いしたいが、どうやっても連絡が取れないって事はあるかも。
そうなれば、そのデュアルライセンスが、それ以前の契約と矛盾しない限りOKだと思うけど。
Re:権利者 (スコア:1)
連絡先が変わればソースを更新し、権利が消滅したらソースから削除するって作業をしてるわけですか…
やっぱり一括で管理したほうがいいのでは？
Re:権利者 (スコア:1)
誰かがＧＰＬを守らずに訴訟沙汰になった
↓
なんらかの賠償金and/or権利を勝ち取ることができた
↓
あとから知らない権利者を名乗る人がたくさんでてきた
[Q][W][E][R][T][Y]
Re:権利者 (スコア:1)
JASRACを例えに出しましたけど、それは、権利を代行するという事ではなく、JASRACの上記のような取り組みの事です。
Re:HZ=300 (スコア:4, 参考になる)
アプリが使うスレッド数(>=プロセス数) よりもCPU数の方が多い時は
逆に早くなることのほうが多いはずです．
ところで，なぜ300Hzなのか？ 理由はChangelogに書いてありました．以下，引用します．
試してみる価値ありそうです．
Re:HZ=300 (スコア:1, 興味深い)
cpufreq をオフにするか、復帰したときに毎回最大値にセット し直すかのどちらかで解決するようです。