誰も Linux kernel ソースを読んでいない？ 196
ストーリー by yoosee
千里のコードも一行から 部門より
千里のコードも一行から 部門より
tamo曰く、"ITpro は「誰も読まないOSのソース・コード」という記事で、
Linux のソース全体を把握している人がほとんどいない現状を伝えている。
それは「(少しでもソースをのぞけば，誰にでもすぐに見つけられるほど簡単なバグなのに) 誰もがよく使うソフトでさえバグが大量にある」ことからも明らかだという。
この記事で例として挙げられているような問題はコード検査ツールで見付けることができそうだが
(参考: Linux カーネル 2.6.16 リリース)、
だからといって、コア開発者と悪意を持っている人たちばかりがコードを読んでいる状態は不健全だろう。
記事によれば「現時点では，詳細にソースを読んでいる人はほとんどいないので，今から読み始めても決して遅くはない」
そうだ。新年度は自分の関心のある部分からソースコードを読むことを始めてみてはいかがだろうか。
……膨大だけど。"
実は (スコア:4, すばらしい洞察)
本当に楽しければ自然に増えると思います。
Re:実は (スコア:4, すばらしい洞察)
自分のだって時間が経ってからだと辛いのに。
Re:実は (スコア:2, 興味深い)
少々オフトピック気味なので話を戻すと、gccの-Wall -Werrorを使うようにするだけでも未初期化変数の参照とか、結構見つかりますね。
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]のですがそれも無し。
「書き込むため・・・」は記事の著者に先入観があるらしいので置いておくとして、 問題点を整理すると
- 2006年2月時点でtraceroute6.cに指摘されたバグは無い
- 相当するtraceroute6.cは1996年のもので、いつまで使われていたのか容易に特定できないほど古いもの
- 「2006年2月時点での極めて危険なバグ」であるにもかかわらず、問題のソースファイルの場所や環境が明示されていない
- そもそも「簡単に見付かる」はずのカーネルのバグが示されていない
あたりだと思います。たまたま私はLinuxを使っていて記事の内容と使用感が違い過ぎるので調べてみたわけですが、ソースのバグを示されてもC言語が読めるだけなら多くの人は「これはひどい」ですませてわざわざ元ファイルまで調べないんではないでしょうか。 中身はバグだらけでもセンセーショナルな文章で最後まで読ませて「やっぱりそうか〜」と思わせるあたり、さすがマスコミのライターさんだと思いました。
この記事にはフリーソフトの欠陥を誇大に吹聴してコミュニティーの無能さをアピールしている (と言われてもしかたないですよね?)所にもう一つ問題があると思うのですが、「カーネルソースを読もう」という記事の主旨は良かったと思います。私も含めて少なからずの人が、カーネルを読んでみようと思ったのではないでしょうか？執筆に感謝、内容に異議あり、でした。
Re:実は (スコア:3, おもしろおかしい)
「萌えるLinux kernel」とかあればいいんですかね。
Re:実は (スコア:4, おもしろおかしい)
ぶつぶつ独り言を言ってるipcﾀﾝとか、
最初は何の機能もなくて段々物事を覚えていくロボット娘のmodulesﾀﾝとか、
みんなを指揮する委員長キャラのscriptsﾀﾝとか、
メインヒロインのkernelﾀﾝとか、
困ったことがあるとポケットから秘密道具を出すdriversﾀﾝとか、
なんかどこかとリンクしている電波娘のlibﾀﾝとか、
何かあると皆から質問されるインテリキャラのincludeﾀﾝとか、
みんなのたまり場を提供してるけど存在感の薄いfsﾀﾝとか、
ストーリーのきっかけになるような突飛な行動をとるトリックスター的な役回りのinitﾀﾝとか、
遊び道具を出したり片付けたり駒鳥のように働いている真面目娘のmmﾀﾝとか
#若干無理があるな
Re:実は (スコア:2, すばらしい洞察)
Re:実は (スコア:4, すばらしい洞察)
Re:実は (スコア:5, すばらしい洞察)
「他人のソースを読まない人は、結局は、自分でプログラムを書けない」は、その人のレベル次第だと思いますね。コードから何かを学ぶ場合、「こうすれば良い」と「こうしてはいけない」の２つがあると思います。ある程度のレベルに達すると、残念ながら「こうすれば良い」が学べるコードの数は限りなく少なくなって行きます。「こうしてはいけない」は数限りなく見ているので、もうお腹いっぱいです。「プログラム言語とかライブラリのAPIマニュアルさえあればプログラムが書けるとか思っている」人が書いたコードから何が学べるのでしょうか。デスマ突入の秘策とか？
大体、GNUのコードとかでプログラミング作法を覚えた人は、仕事としてならそれが間違っているのかを理解していない人が多いですし、その間違いを説明するだけで一苦労です。GNUとかのコードとプロダクトグレードのコードでは、コードを書く姿勢も重要となる側面もまったく違うのに。単眼的な見方が染みついているので、他の要素の存在を受け入れないんですね。
「一方で、おおざっぱな全体構成とか仕様だったら、プログラミング能力がなくても書ける」って、エンジニアリングセンスに欠けた人による設計はたとえ外部であっても、あるいは要求仕様であっても、苦痛のタネですしトラブルの元だと思いますよ。品質に問題ありのプロダクトとか、デスマ日常でもカットオーバーが遅れるとか、そういう事の原因の一端は、シロウトさんの設計によってですね。設計と実装は車の両輪みたいなもので、どちらをシロウトさんに任せられるか、なんて議論は危険そのものだと思いますよ。
コードを読んで楽しいかどうかは、人の置かれている状況次第でしょう。趣味でコードを読むならどんなコードでも良いけれど（読みたく無ければ止めれば良いし）、仕事でならクソなコードは苦痛そのものですね。出来れば読みたくないのですが。
Re:実は (スコア:2, 興味深い)
人それぞれなんだろうけど、仕事でコードを書く人には、ただテストに通ればいいと思っているんじゃないかというような、非常に汚くてへたくそなコードを書く人もいるんですよね。だからといって、きれいに書き換えることもできないのが、仕事でコードを読む場合のつらいところだったりしますが。
Re:実は (スコア:4, 興味深い)
ソフトの規模が大きくなったがために、効果的な教育システムやシステマチックなマネジメントが無い状態で、適性を無視して大量動員を行った結果ですね。
今日、2006/04/08の朝日の朝刊に「バグ猛威、デジタル製品」の記事が載ってました。内容を読んで見て思ったのは「それは自業自得じゃない？」ですね。単価を切り下げて人集め、糞と味噌の区別もつかない、そんな事をやっていればこうなるのは必然です。記事中でソニー中鉢社長は技術系の人材が欲しいと言っていますけれど、それは必要な事ながら、それで問題が全て解決するとも思えません。糞と味噌の区別もつかないマネジメントが根本問題なのですから。
件の素人なのだが (スコア:5, すばらしい洞察)
って、思いっきりそう思ってるんだけど、呼びました？
うぅ〜〜〜ん、、、
原理や基本概念さえ分ってれば、
それで全く問題ないプログラム書けるはずなんだけどなぁ、、、
そもそも、そのためのライブラリであり、APIマニュアルのはずなんだが、、、
基本的にAPIマニュアルだけで書けないのは、
大抵の場合マニュアルに不備があるせいじゃないだろうか？
結局、その場合ソース読む羽目になる訳だが、
原理や基本概念が分ってないと、結局読めない。
また、ソースはあくまでも1つの実装に過ぎない。
本当に大切なのは、ソース読む事ではないような気がするんだけどなぁ、、、
デザインパターンなんかも
まさにそこを狙ってる気がするんだけど、
その辺りどう思います？
もちろん1実装手段、
テクニックの実例としては
ソースは重要だと思うのだけど、
プログラミング能力って点では、
ソースは具象的過ぎる、、、
大切なのはもっと抽象的な概念の部分じゃないかと、、、
# アルゴリズムとかね、、、
uxi
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:実は (スコア:2, 興味深い)
仕事の内容は、qmailの謎の挙動に関する調査および修正作業だったのですが
結局、バグはdjb氏のコードにではなく、他の方が作成したパッチにありました。
パッチの作者もコードの独特さに混乱してしまったのだろうなと、普段だと
プログラムミスをした人に対しては感じない同情的な気分になった・・・・。
qmail (スコア:2, 参考になる)
参考資料 [ya.maya.st]およびそれを受けてのコメント [diary.imou.to]。
Re:実は (スコア:4, 興味深い)
エンジニアリング的に見るとすれば、インデント云々もさることながら、同機能の標準関数とは微妙に違う引数並びとか、ある特定の状況下（qmailの中での使用）でしか通用しない機能実装（ジェネリックなものを含めて）とか、問題だらけですね。
だからこそ、qmailのコードは参考にならないし、排斥すべきものなのです。鵜の真似をする烏じゃないけれど、凡人がdjbの様な天才の真似をしても、高転びに転ぶだけです。エンジニアリングが僕を含めて凡人が怪我をせずに歩ける道だとすれば、qmailのコードはエンジニアリングや凡人から一番遠い所にある存在です。
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:学習目的の OS ソースコード (スコア:3, 参考になる)
いまならやっぱりNetBSDじゃないでしょうか. 利点としては
というあたりが挙げられると思います. FreeBSDだと最新版に追随した解説書 [amazon.co.jp]があるんですが, かなりadhocな実装が有ったりしますので, 学習にはやっぱりNetBSDの方が良いと思います.
Linuxのカーネルを読まないのって, こうした道標になる基本的なドキュメントが揃っていないからじゃないかな.
Re:学習目的の OS ソースコード (スコア:5, 興味深い)
制度上、情報科学専攻以外の学生も受講可能になっていて、実際に受講していました。予備知識の少ない受講生もいますが、このコードは何をしているかをおおまかに理解する程度のことは、けっこうなんとかなります。 コツは、
- まず、*.h から読む。
- ロック関係は、とりあえず気にしない。
- #ifdef KTRACEなどは後回し。
といったところです。ただし、ソースコードに手を入れることができるようになるには、これだけでは全然足りません。
Re:学習目的の OS ソースコード (スコア:2, 参考になる)
# MINIXもMINIX 3 [minix3.org]の開発が活発のようですし、MINIX本の第3版 [amazon.co.jp]が出てますので、大変興味がありますが。
Re:学習目的の OS ソースコード (スコア:2, 参考になる)
2.0のころからLinuxカーネルの開発していますが昔のほうが理解はずっと簡単でした。
ソースを読む必要性を感じるか? (スコア:4, すばらしい洞察)
いつでもソースを読めるのはメリットであるものの、
読まなくて済むならそれでも良いと思います。
勿論ソースを読む楽しみがあることは否定しませんが、
件の記事からモチベーションを持たせるのはちょっと
難しいように思います。
モチベーションを持たせることが難しいのは、
件の先生なら解ると思うんですが…
Re:ソースを読む必要性を感じるか? (スコア:4, 興味深い)
[今週見つかった安易なバグTOP10]としてバグの該当部分を具体的に公表すれば、バグ探しにチャレンジしてみようという人が増えるかも。
# 今度から、バグにぶつかったときくらいはソースコードを読むようにします。
Re:ソースを読む必要性を感じるか? (スコア:3, すばらしい洞察)
ソースを見るときは
・うまく動かないとき (バグの発見)
・ハックしたいとき:) (好奇心)
くらいではないでしょうか。
また全体の把握と言う面では、オペレーティングシステム全体の動作を理解している人は少ないし、求められている人材にもよく聞きます。
そういったスキルをもったエンジニアだと、
>カーネルのソースが読めると，たいそう儲かる
のかもしれませんね。
百科事典 (スコア:3, すばらしい洞察)
まあ、それが趣味の人とか活字中毒で本切れの人とかなら読むかもしれないけど
ほとんどの人は必要なところだけ読むし、中には全く読まない人もいるだろう？
そういうものになっているのではないの？
#自分はドライバとか読むことはある
#あとメモリ管理とかの一部ね。
Re:百科事典 (スコア:5, 興味深い)
読んでみると、意図的に間違い(というか、論旨を変な方向へ誘導する)を入れて、他社にパクられた場合に証拠とする、みたいなトラップを見つけられて楽しかったです。
ああ、ちなみにその仕事した後、クライアントは実際にパクった会社訴えたらしいですが。
# こんな仕事したのは日本でも数名だと思うのでAC
Re:百科事典 (スコア:2, 興味深い)
百科事典は読むかもしれないけど
ソースコードは必要がない限り読まないかなぁ
やっぱ、全部読むのはつらいので目次とか索引がほしいところ
そういうのがあれば自分で興味がある部分だけを読むこともできるし
おいらの場合だと
メモリ管理やってる場所どこ？とかドライバはどれ？ってのを探すところで挫折しちゃいそう
（ホントはもっと根本的にOSってどうやって動いているのってとこから理解しないとダメな気がするけどｗ）
Re:百科事典 (スコア:2, 参考になる)
はい, GLOBAL [gnu.org]. と言うか, すでに紹介されている [srad.jp]ソースコードツアーも, このGLOBALを使って生成されたものみたいですね. カーネルに限らず, 大規模プログラムを参照する場合の定番ツールです.
Re:百科事典 (スコア:2, すばらしい洞察)
索引とか目次って言っちゃうと伝わりにくいか....
Linuxのシステムの動作に対して、ファイル名や関数名というページ番号を与えるやつってので伝わるんだろうか？
もっと言い方を変えるとソースを追う手助けより、ソースを追わなくてすむ手助けがほしい
ソースを読んでないことが問題視されてるのにこういうこと言うのは変だと思うけど
実際、ある程度以上の規模になると
ソースだけを読んで全体像を把握とか、ある種の拷問に近いような気がする
わりとよくありがちなことでもあるけれど.....
分かりやすいバグ？ (スコア:3, すばらしい洞察)
> こうしたバグはカーネルのいたるところに存在するため，少し読めばすぐに発見できるそうだ。だが実際にはほとんどは放置されているという。「え，こんなに分かりやすいバグも放置されてるんですか？」。「そう，それだけソースを読む人が少ない，ってことなんや」。
分かりやすいバグじゃないと思うぞ。結果として単純なバグかもしれないが、そう簡単に気付くバグじゃないと思う。
しないさせない！スルー力
Re:分かりやすいバグ？ (スコア:5, すばらしい洞察)
Re:分かりやすいバグ？ (スコア:4, すばらしい洞察)
正直、Linuxのカーネルは仕様が変わりすぎだと思う。
Re:分かりやすいバグ？ (スコア:2, 参考になる)
主題と逸れますが、
カーネル間の互換性の背景（本質）は、ここ [internet.com]辺りで、と思うのですが。。。
Re:分かりやすいバグ？ (スコア:5, すばらしい洞察)
書き込んでないじゃん。ライターも分かってないんじゃ?
Re:分かりやすいバグ？ (スコア:3, すばらしい洞察)
Re:分かりやすいバグ？ (スコア:2, 参考になる)
arch/i386/kernel/cpu/cyrix.cなのですが、
という感じでccr4に値を設定したのにccr3を書き込んでしまうというのがありますが、こういうのは簡単に気付く部類だと思います。
ソース解読を手助けするツールがあればいいなあ (スコア:3, 興味深い)
ただ、確かに昔に比べるとソースをじっくりと眺めて机上デバッグを行う・・・という機会はあんまりなくなったなあ、というのは思いますね。
昔と今とじゃ規模も複雑さも段違いなのでいちがいに比較はできませんけど。
仕事で定期的にソースレビューをやってますが、やはり結構負担になるケースが多いので、こーいうソースレビューやら解読を楽しく進められるツールとか作れないかなあ・・・とか思うこともあります。
Re:ソース解読を手助けするツールがあればいいなあ (スコア:4, 参考になる)
オフトピなんだけど (スコア:2, 参考になる)
残念ながら、そんな人はほとんどいません(--;
まぁ、プログラマの立場からすると、そう言いたい気持ちはわかるけど、大学の先生って、たとえ情報関係で講義をしてプログラムを教えていても、基本的に彼らはプログラマではないですから・・・いわゆる「仕事」ではコードを書かないでしょう。
彼らの能力はプログラムではなく、もっと数学に近い分野など理論で生きている人がほとんどだし、「技能」ではなくて「学問」をやっている（じゃない人もいるけど）、そういうのは区別するべきだし、情報系の大学を出たのならば、そういう分野に興味がなくて、実践でコードしか書かなくても、そういう世界があるっていうのを知っておくべき。
彼らの畑では、やはり彼らは超人的にすごい。若くして＊教授になるようなやつは、尋常ではないほどの能力を有している。（長年助手を＊＊＊とかいう人とか、最後まで助教授のままとか、地方大学でのんびりのんびりやっていて、自分の研究分野でうだつの上がらない人はいるけどね。あと、世代の差とボケの取り方で、おじいちゃん先生はすごいけど、やっぱりおじいちゃんだなーって思うところも確かにある。言葉が明瞭でない人とか、教育に興味がなくてええかげんな人とか。なにかと誤解されやすい人種であるのは事実だ)
ともかく、大学のセンセが職業的プログラマで仕事をできないのと同じように、職業的プログラマは、大学のセンセの「研究」はできませんし、当然全く太刀打ちもできません。たぶん、互いに互いの職能に興味がないし。似ているからと言ってプログラムでくくってはダメです。
まぁ、だから、プロ野球の選手がサッカーの選手を「お前は野球が下手だからな」と貶しても仕方がない。ってこと。情報の先生だから・・・と彼らのスキルのレベルをプログラマの視点で見るのがそのそも間違っている。まぁ、プログラマの視点でものを見るのが好みだから、今プログラマをしている訳なんでしょうけど。
たまにメディアに踊られてとういか、あえて予算獲得のための道化というのもあるが、妙な本を書いたり、妙なことを言うセンセがいて、それを大学のセンセだと思う市民が多いのは事実だけどね。まぁ、そういうセンセもいるし、「声が大きい」センセは結構そういう海千山千のオヤジだったりもするが。
Re:ソース解読を手助けするツールがあればいいなあ (スコア:2, 興味深い)
このサイト自体Linux Kernelのソースの資料になっています。
今も昔も (スコア:3, 興味深い)
ケン・トンプソンあたりの最初のUNIXのコードには、彼がそのシステムにいつでも入ることができるバックドアを（半ばジョークで）しこんでいたそうだ。無論ソースは完全にオープンしてある。
でも、それが見つかって、周知の事実になってそのコードを消したのが、５年後だか１０年後だかというお話。ユーザの誰もソースをまともに読んでないじゃん！！
って話を思い出しました。結局オープンだからと言っても、誰でもいつでもチェックできるから！といって安心だというわけではなくて、何があるかわからない。ということの証明として結構有名な話だったはず。
Re:今も昔も (スコア:5, 参考になる)
Morphy GNU/Linuxはまだですか? (スコア:3, おもしろおかしい)
愕然とするほど簡単だったんですね?
> 今から読み始めても決して遅くはないのである。
そろそろやってみるかと思ったんですね?
> 1日100行ずつ読んだとしても，136年かかる計算になる。
1人を136年待たせることは約49674人を1日待たせるのに等しいということですね?
# つーか、そんな読み方してたら頭に入るものも入らないと思う
儲けには繋がらない (スコア:2, 興味深い)
Re:儲けには繋がらない (スコア:2, 参考になる)
Re:儲けには繋がらない (スコア:2, おもしろおかしい)
そりゃ凄い！
「給料の法則」 [vector.co.jp]が見事に成立しているのですね。 > #917333 [srad.jp], #917367 [srad.jp], #917390 [srad.jp]
そのまえに、すべて把握する必要があるのだろうか？ (スコア:2, 興味深い)
そして、全部読んだとしても数週間〜数ヶ月単位で更新されてしまうわけで、それをまた読んでいる間にまたほかの場所が更新されて……となるわけで。
まぁ大体の動作を把握することはまったく悪くないですが、それに意味があるのかというと疑問。
#つぅか実際にカーネルソースを参照しないといけない事態になったとき、ソースを読んでいたからといって即その部分が浮かんでくるかはまた別の問題だし。
#そして、ソースにバグがあろうとも、その部分が実行されなければバグにはならないということを記事には書いて欲しかったなぁ・・・
確かに誰も読んでいないようだな (スコア:2, すばらしい洞察)
/*
* Convert an ICMP "type" field to a printable string.
*/
char *
pr_type(register u_char t)
{
static char *ttab[] = {
"Echo Reply", "ICMP 1", "ICMP 2", "Dest Unreachable",
"Source Quench", "Redirect", "ICMP 6", "ICMP 7",
"Echo", "ICMP 9", "ICMP 10", "Time Exceeded",
"Param Problem", "Timestamp", "Timestamp Reply", "Info Request",
"Info Reply"
};
if (t > 16)
return("OUT-OF-RANGE");
return(ttab[t]);
}
Re:全然本筋とは関係ないところで感動 (スコア:3, すばらしい洞察)
今のうちにバラ色の生活が来ると夢を見させてあげても。
「依頼話が多い」→「商談が多い」→「実はさほど単価が良くない」→「断る商談が多い」→「こんなはずでは orz」
ってありがちです。
ちなみに私も依頼はそこそこあるんですが、
たいていフタをあけると「あーあぁ！orz」
てなのが多いんです。
clausemitz
Re:たいそう儲かる？ (スコア:2, すばらしい洞察)
供給過多で相場が下がるでしょう。
それに誰もが儲けたいわけじゃないし。
俺的には不満が無いならカーネルハックしなくても
アプリの改造なりプラグインの開発なり
好きなことをしたほうが楽しいと思うよ。