アカウント名:
パスワード:
おっしゃる通りだと思います。
参考資料 [ya.maya.st]およびそれを受けてのコメント [diary.imou.to]。
いまならやっぱりNetBSDじゃないでしょうか. 利点としては
というあたりが挙げられると思います. FreeBSDだと最新版に追随した解説書 [amazon.co.jp]があるんですが, かなりadhocな実装が有ったりしますので, 学習にはやっぱりNetBSDの方が良いと思います.
Linuxのカーネルを読まないのって, こうした道標になる基本的なドキュメントが揃っていないからじゃないかな.
制度上、情報科学専攻以外の学生も受講可能になっていて、実際に受講していました。予備知識の少ない受講生もいますが、このコードは何をしているかをおおまかに理解する程度のことは、けっこうなんとかなります。 コツは、
ただし、ソースコードに手を入れることができるようになるには、これだけでは全然足りません。
どこの大学院でやっているか、差し支えなければ教えていただけないでしょうか?
これ(traceroute)は,厳密にはカーネルのプログラムではないが,通常はカーネルに一緒に添付されている基本的なユーティリティ・プログラムである。
traceroute6.cなんてどこにもないのだが。
/bin/traceroute6はtracerouteへのシンボリックリンクですね。FC5のiputilsパッケージにtracerouteは含まれていませんし、件のtraceroute6.cの入っているiputilsを探してみました [inr.ac.ru]が、中身が全然違うように思えます。
このiputils自体、3年以上更新されていません。問題のコードのある関数名pr_typeとtraceroute6.cでGoogleにあたってみる [google.com]とBSDのソースが出てきますが、switch、caseで切り分けていました。
バグがあるとされたこのtraceroute6.c、はたして使われているのでしょうか。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
犯人はmoriwaka -- Anonymous Coward
実は (スコア:4, すばらしい洞察)
本当に楽しければ自然に増えると思います。
Re:実は (スコア:4, すばらしい洞察)
自分のだって時間が経ってからだと辛いのに。
Re:実は (スコア:2, 興味深い)
少々オフトピック気味なので話を戻すと、gccの-Wall -Werrorを使うようにするだけでも未初期化変数の参照とか、結構見つかりますね。
Re:実は (スコア:1)
自分で実装してみるともっと駄目なコードを吐くヘタレです。
批判するのは簡単だ・・・
Re:実は (スコア:1)
Re:実は (スコア:1, 参考になる)
少なくとも、元の設計がわからなくなるほどつぎはぎだらけなアプリのソースを解析して改修するよりは、はるかに楽。
Re:実は (スコア:4, 参考になる)
"Membership Reduction" ttab2で検索してみました [google.co.jp]が、 07/31/96の時点でのソースしか出てきませんでした。このソースを利用した形跡はディストリビューション中ではもはや検索に引掛からず、ビルドのテストを2002/09/27にした跡があるのが最新でした。
Debian/sarge(tracerouteパッケージ)のtraceroute.cではswitch/caseしてました。他の「2006年2月時点」に相当するtraceroute6.c [google.co.jp]でもswich/caseのようです。 もしかして古いコードがカーネルのソースに紛れ込んでることを言ってるのでは、と思いpr_typeも検索してみた [tamacom.com]のですがそれも無し。
「書き込むため・・・」は記事の著者に先入観があるらしいので置いておくとして、 問題点を整理すると
たまたま私はLinuxを使っていて記事の内容と使用感が違い過ぎるので調べてみたわけですが、ソースのバグを示されてもC言語が読めるだけなら多くの人は「これはひどい」ですませてわざわざ元ファイルまで調べないんではないでしょうか。 中身はバグだらけでもセンセーショナルな文章で最後まで読ませて「やっぱりそうか〜」と思わせるあたり、さすがマスコミのライターさんだと思いました。
この記事にはフリーソフトの欠陥を誇大に吹聴してコミュニティーの無能さをアピールしている (と言われてもしかたないですよね?)所にもう一つ問題があると思うのですが、「カーネルソースを読もう」という記事の主旨は良かったと思います。私も含めて少なからずの人が、カーネルを読んでみようと思ったのではないでしょうか?執筆に感謝、内容に異議あり、でした。
Re:実は (スコア:3, おもしろおかしい)
「萌えるLinux kernel」とかあればいいんですかね。
Re:実は (スコア:4, おもしろおかしい)
ぶつぶつ独り言を言ってるipcタンとか、
最初は何の機能もなくて段々物事を覚えていくロボット娘のmodulesタンとか、
みんなを指揮する委員長キャラのscriptsタンとか、
メインヒロインのkernelタンとか、
困ったことがあるとポケットから秘密道具を出すdriversタンとか、
なんかどこかとリンクしている電波娘のlibタンとか、
何かあると皆から質問されるインテリキャラのincludeタンとか、
みんなのたまり場を提供してるけど存在感の薄いfsタンとか、
ストーリーのきっかけになるような突飛な行動をとるトリックスター的な役回りのinitタンとか、
遊び道具を出したり片付けたり駒鳥のように働いている真面目娘のmmタンとか
#若干無理があるな
Re:実は (スコア:0)
若干どころじゃなくて…
Re:実は (スコア:1, おもしろおかしい)
# もしかすると突っ込み所が違うかもしれないのでAC
Re:実は (スコア:0)
ダイナミックリンクハァハァ
Re:実は (スコア:0)
Re:実は (スコア:0)
Re:実は (スコア:2, すばらしい洞察)
Re:実は (スコア:4, すばらしい洞察)
Re:実は (スコア:5, すばらしい洞察)
「他人のソースを読まない人は、結局は、自分でプログラムを書けない」は、その人のレベル次第だと思いますね。コードから何かを学ぶ場合、「こうすれば良い」と「こうしてはいけない」の2つがあると思います。ある程度のレベルに達すると、残念ながら「こうすれば良い」が学べるコードの数は限りなく少なくなって行きます。「こうしてはいけない」は数限りなく見ているので、もうお腹いっぱいです。「プログラム言語とかライブラリのAPIマニュアルさえあればプログラムが書けるとか思っている」人が書いたコードから何が学べるのでしょうか。デスマ突入の秘策とか?
大体、GNUのコードとかでプログラミング作法を覚えた人は、仕事としてならそれが間違っているのかを理解していない人が多いですし、その間違いを説明するだけで一苦労です。GNUとかのコードとプロダクトグレードのコードでは、コードを書く姿勢も重要となる側面もまったく違うのに。単眼的な見方が染みついているので、他の要素の存在を受け入れないんですね。
「一方で、おおざっぱな全体構成とか仕様だったら、プログラミング能力がなくても書ける」って、エンジニアリングセンスに欠けた人による設計はたとえ外部であっても、あるいは要求仕様であっても、苦痛のタネですしトラブルの元だと思いますよ。品質に問題ありのプロダクトとか、デスマ日常でもカットオーバーが遅れるとか、そういう事の原因の一端は、シロウトさんの設計によってですね。設計と実装は車の両輪みたいなもので、どちらをシロウトさんに任せられるか、なんて議論は危険そのものだと思いますよ。
コードを読んで楽しいかどうかは、人の置かれている状況次第でしょう。趣味でコードを読むならどんなコードでも良いけれど(読みたく無ければ止めれば良いし)、仕事でならクソなコードは苦痛そのものですね。出来れば読みたくないのですが。
Re:実は (スコア:2, 興味深い)
人それぞれなんだろうけど、仕事でコードを書く人には、ただテストに通ればいいと思っているんじゃないかというような、非常に汚くてへたくそなコードを書く人もいるんですよね。だからといって、きれいに書き換えることもできないのが、仕事でコードを読む場合のつらいところだったりしますが。
Re:実は (スコア:4, 興味深い)
ソフトの規模が大きくなったがために、効果的な教育システムやシステマチックなマネジメントが無い状態で、適性を無視して大量動員を行った結果ですね。
今日、2006/04/08の朝日の朝刊に「バグ猛威、デジタル製品」の記事が載ってました。内容を読んで見て思ったのは「それは自業自得じゃない?」ですね。単価を切り下げて人集め、糞と味噌の区別もつかない、そんな事をやっていればこうなるのは必然です。記事中でソニー中鉢社長は技術系の人材が欲しいと言っていますけれど、それは必要な事ながら、それで問題が全て解決するとも思えません。糞と味噌の区別もつかないマネジメントが根本問題なのですから。
Re:実は (スコア:1)
おっしゃる通りだと思います。
件の素人なのだが (スコア:5, すばらしい洞察)
って、思いっきりそう思ってるんだけど、呼びました?
うぅ〜〜〜ん、、、
原理や基本概念さえ分ってれば、
それで全く問題ないプログラム書けるはずなんだけどなぁ、、、
そもそも、そのためのライブラリであり、APIマニュアルのはずなんだが、、、
基本的にAPIマニュアルだけで書けないのは、
大抵の場合マニュアルに不備があるせいじゃないだろうか?
結局、その場合ソース読む羽目になる訳だが、
原理や基本概念が分ってないと、結局読めない。
また、ソースはあくまでも1つの実装に過ぎない。
本当に大切なのは、ソース読む事ではないような気がするんだけどなぁ、、、
デザインパターンなんかも
まさにそこを狙ってる気がするんだけど、
その辺りどう思います?
もちろん1実装手段、
テクニックの実例としては
ソースは重要だと思うのだけど、
プログラミング能力って点では、
ソースは具象的過ぎる、、、
大切なのはもっと抽象的な概念の部分じゃないかと、、、
# アルゴリズムとかね、、、
uxi
Re:件の素人なのだが (スコア:1)
> 大抵の場合マニュアルに不備があるせいじゃないだろうか?
ンなわきゃねー。今Java2Dの資料見てるんだけど、何かを実現するためにどれをどう組み合わせればよいのかなんて、APIのドキュメント「だけ」眺めてるんじゃ絶対わかんない。
Java は基本的に門外漢なんだけど、、、 (スコア:5, すばらしい洞察)
Java 2D の API マニュアル [sun.com]ではなく、
JavaTM 2D API プログラマーズガイド [sun.com]じゃないかな、、、と、、、
# 外してたら申し訳ない、、、m(_ _)m
個人的印象としては、
どうも Java の API マニュアルは取っ付き難い印象が強いですね、、、
クラスライブラリとしては同規模程度と思われる
MFC や ATL 等のマニュアル [microsoft.com]と読み比べてみると、
僕の感覚では、Microsoft に軍配が上がっちゃう、、、
# あれも、最初は分量の多さにどこから手を付けて良いのか途方に暮れたけど、
# それでも Java のマニュアル程の取っ付き難さは感じてなかったような気が、、、
# 多分 API マニュアルから概観の解説が引けてたのと、
# メソッド毎に、簡単なサンプルコード付いてる確率が高かったのが大きいのかも?
とりあえず、
Java の API マニュアルは全体的にボトムアップ的な印象が強いですね、、、
# プログラマーズガイドはトップダウン的だと思うけど、、、
# これとはリンクの結び付きが弱い、、、
# その結果、やりたい事は分ってても、使うべき機能に到り付き辛い印象が、、、
# 読み方がなっとらんと言われれば、その通りなのだが、、、orz
既に全体像が分っていて、
やりたい事に対応するクラス名、メソッド名がぱっと思いつく人にとっては、
悪くないリファレンスだと思うんだけど、
とかく入門者はどこから手を付けて良いか途方に暮れてしまいそうですよ。
また、デザインパターンの知識を暗黙の了解としている節もあり、
サンプルコードも皆無に近い状態なので、
その辺りの下地が一通り整ってないと、
入門書、参考書、解説書の類がないと苦しいのではないかと、、、
僕個人の感触では、あのマニュアルは
オブジェクト指向のマイナス面の体現である気がしていけない、、、
本来、おおまかな機能と、インターフェースさえ分っていれば、
小難しい事あと回しで使えて良いはずなのに、
そうさせてくれる糸口が前の方に出て来てないので、
なかなかそうさせてもらえない印象が強いと言うか、、、
うっかりしてると、プログラマーズガイド見落してて、
API マニュアルだけ見て、どこから読めば良いんだ?って事が何度かあったし、、、
# まぁ、マニュアル自信の問題と言うよりも、
# ポインタの示し方の問題のような気もするんだけど、、、
この辺りは、反論がある方は是非コメントして下さい。
逆に、トップダウン的だなと感じるマニュアルの例は
PHP のオンラインマニュアル [php.net]かな?
あれは、チュートリアルとほとんど合体してる上、機能別に整理されてるから、
全体像を知らなくても、やりたい事から探して行くと、
自動的に使うべき関数のリファレンスに到り付いてるような印象が、、、
# まぁ、オブジェクト色は薄いですけどね、、、(^^;;;)
また、サンプルコードも比較的豊富に盛り込まれているので、
入門からリファレンスまであれ一つで済んじゃうので
参考書の必要性がほとんどない印象も、、、
uxi
Re:Java は基本的に門外漢なんだけど、、、 (スコア:1)
ライブラリも万能ではないから、、、 (スコア:1)
追加する部分が多いなら、
追加ライブラリのような物をこさえる必要が生じるのが常ですね。
でも、そういう事は、既にみんな通って来ているはずだから、
(素人である)僕がここで講釈するまでもないと思うんだけどなぁ、、、
なぜそこが疑問点になるのか僕としてははちょっと理解に苦しむ所です、、、
とりあえず、基本的には、基礎概念が分ってるって前提で、
ソースを書く手間を省くのがライブラリであり、
ライブラリの内部実装を隠蔽する、
つまりソースを読む手間を省くのが(API)マニュアル。
あくまで、これらは手間を省く手段であって、
それが全てを解決してくれる万能薬である事はまずないわけで、
省けない手間は、自分できっちり手間かけてやるしかないですよね、、、
で、、、
使える物は有り難く使わせてもらうとして、
自分がかけた手間は、
なるべく他人も再利用し易い形(例えばライブラリ等)にして
公開、還元して行く事で、
みんなで幸せになろうよ、、、ってのが
ハッカーとかフリーソフトウェアとかオープンソースの
文化なんだと思いますです。はい。
uxi
Re:実は (スコア:0)
ってなんですか?
QEMU? VMware?
Re:実は (スコア:0)
GDBのデバッグエージェントになる機能があって、GDBでtarget remote ...みたいな感じで接続できるものがある。
高価(安くても10万円)だし、カーネルのデバッグのために使うようなものではないと思う。
うちではもっぱらハードウェアのデバッグとFlashROM焼き専用だな。
Re:実は (スコア:1, 興味深い)
Re:実は (スコア:2, 興味深い)
仕事の内容は、qmailの謎の挙動に関する調査および修正作業だったのですが
結局、バグはdjb氏のコードにではなく、他の方が作成したパッチにありました。
パッチの作者もコードの独特さに混乱してしまったのだろうなと、普段だと
プログラムミスをした人に対しては感じない同情的な気分になった・・・・。
qmail (スコア:2, 参考になる)
参考資料 [ya.maya.st]およびそれを受けてのコメント [diary.imou.to]。
Re:実は (スコア:1)
独特と言うか哲学にちかい作り方ですね。
これもアリだと思います。
kusanagi shin
Re:実は (スコア:0)
ボロカスに文句を言ってる人たちは、他人のコードを自分好みにインデントしながらじゃないと読めないんじゃないでしょうか。
ぼくは、初めて読んだときは、世の中にこんな汚いコードの書き方ががあるのかとビックリしたけれど、よくよく読んでみるとなるほどと思うことも多いし、ひじょうに勉強になりました。使わせてもらっているテクニックもあります。
とはいえ、わざわざあんな書き方を真似することはないでしょうけれど。
Re:実は (スコア:4, 興味深い)
エンジニアリング的に見るとすれば、インデント云々もさることながら、同機能の標準関数とは微妙に違う引数並びとか、ある特定の状況下(qmailの中での使用)でしか通用しない機能実装(ジェネリックなものを含めて)とか、問題だらけですね。
だからこそ、qmailのコードは参考にならないし、排斥すべきものなのです。鵜の真似をする烏じゃないけれど、凡人がdjbの様な天才の真似をしても、高転びに転ぶだけです。エンジニアリングが僕を含めて凡人が怪我をせずに歩ける道だとすれば、qmailのコードはエンジニアリングや凡人から一番遠い所にある存在です。
学習目的の OS ソースコード (スコア:1, 興味深い)
やはり NetBSD とか Minix かな?
Re:学習目的の OS ソースコード (スコア:3, 参考になる)
いまならやっぱりNetBSDじゃないでしょうか. 利点としては
というあたりが挙げられると思います. FreeBSDだと最新版に追随した解説書 [amazon.co.jp]があるんですが, かなりadhocな実装が有ったりしますので, 学習にはやっぱりNetBSDの方が良いと思います.
Linuxのカーネルを読まないのって, こうした道標になる基本的なドキュメントが揃っていないからじゃないかな.
Re:学習目的の OS ソースコード (スコア:5, 興味深い)
制度上、情報科学専攻以外の学生も受講可能になっていて、実際に受講していました。予備知識の少ない受講生もいますが、このコードは何をしているかをおおまかに理解する程度のことは、けっこうなんとかなります。 コツは、
ただし、ソースコードに手を入れることができるようになるには、これだけでは全然足りません。
Re:学習目的の OS ソースコード (スコア:1)
Re:学習目的の OS ソースコード (スコア:1)
Re:学習目的の OS ソースコード (スコア:2, 参考になる)
# MINIXもMINIX 3 [minix3.org]の開発が活発のようですし、MINIX本の第3版 [amazon.co.jp]が出てますので、大変興味がありますが。
Re:学習目的の OS ソースコード (スコア:2, 参考になる)
2.0のころからLinuxカーネルの開発していますが昔のほうが理解はずっと簡単でした。
Re:学習目的の OS ソースコード (スコア:2, 興味深い)
例えばデバイスドライバの登録は「グローバル変数の直接書き換え」ですよ。カプセル化?なにソレ?(devfsとかudevとかで状況はまた変わってるけど)
あと(よく言えば進化が激しいので)バージョンごとの差異も大きい。よって解説書が出るころには古いバージョンの解説になってる(詳解Linuxカーネル等)
特定バージョンでしか役に立たないahdocなバッドノウハウを身に付けても学習にはよろしくないでしょう。
そうはいっても(これまた力技で)だんだんきれいになってきてはいます。
余談ですがLinuxでは(高速化のため)インライン関数やマクロを多用しているところで、(Net)BSDは関数を使用していることが多いように思います。これがLinuxとBSDの定数オーダの微妙な速度差の原因であるならば、BSDもインライン関数もしくはIPO対応コンパイラを使えば同様の速度になるんじゃないでしょうか?
Re:学習目的の OS ソースコード (スコア:0)
Re:実は (スコア:0)
Re:実は (スコア:1, 参考になる)
Re:実は (スコア:0)
>ここでいうOSとは,Linuxのカーネル(OSの“核”となるソフト)のこと
と書いているのに、素晴らしい論理展開ですね。
で、FC5だけど。
$ rpm -qf /bin/traceroute6
traceroute-1.0.4-1.2
$ tar tvfj traceroute-1.0.4.tar.bz2
してもtraceroute6.cなんてどこにもないのだが。
Re:実は (スコア:4, 興味深い)
/bin/traceroute6はtracerouteへのシンボリックリンクですね。FC5のiputilsパッケージにtracerouteは含まれていませんし、件のtraceroute6.cの入っているiputilsを探してみました [inr.ac.ru]が、中身が全然違うように思えます。
このiputils自体、3年以上更新されていません。問題のコードのある関数名pr_typeとtraceroute6.cでGoogleにあたってみる [google.com]とBSDのソースが出てきますが、switch、caseで切り分けていました。
バグがあるとされたこのtraceroute6.c、はたして使われているのでしょうか。
Re:実は (スコア:0)
Re:実は (スコア:1, 参考になる)
なんだか記事が正しい気がしてきた。重箱の隅をもっと尖ったものでつついてみよう!
Re:実は (スコア:1, すばらしい洞察)
linux kernelの話なのになんでtracerouteなのか?と。
traceroute6.cはiputilsパッケージに含まれているようですが、
ディストリビューションによっては標準インストールでは入らないかもしれません。
linux kernelのソースよりさらに読む人が少ないと思います。
Re:実は (スコア:0)