いや、本当にないわけではなく。
今日は東京はげんなりするような雨です。
あまりにも激しく降るので、邪魔な本を古本屋に売りに行くこともできない。
そろそろ飯を喰いたいのだが、食糧の備蓄もない(3/6から出張だから、意図的に)。
家でじっとしながら、 ThinkPad が壊れていた間できなかったデータ入力をするわけですが、そうすると当然、徐々に、徐々に気も滅入ってくるわけで…。
そんなときに井上陽水なんぞ聞かされて御覧なさい。
こんなタイトルの日記の一つも書く気になるから。
2006年2月25日
ヨコハマ買い出し紀行 最終回
ヒーリング漫画として名高い、ヨコハマ買い出し紀行が今月号のアフタヌーンで最終話をむかえました。
アルファさんともこれでお別れです。
…なんというか、できればこういう終末の迎え方にしたいものです。
アルファさんともこれでお別れです。
…なんというか、できればこういう終末の迎え方にしたいものです。
2006年1月27日
全社合宿@湘南国際村
湘南国際村に全社合宿に来ている。去年、一昨年にやった建物の隣なのに、
- インターネット環境はある
- 飯は莫大に出る
- デザートが出る
なお、十分には程遠いのもこれまた事実。
- 温泉が無い
- 温泉が無い
- 温泉が無い
2006年1月1日
Charlie's Chocolate Factory
ようするにあれだ。
「ドゥークー伯爵は歯医者さんだった」
「だからアナキン・スカイウォーカーにも嫌われて、いきなり首チョンパ」
と言う、StarWarsの裏話だったんだな。(違)
"Dark Side of the Floss is the path way to many abilities some consider to be un-natural.."
...つーか新年一発目のネタがこんなんでいいのか?!?
「ドゥークー伯爵は歯医者さんだった」
「だからアナキン・スカイウォーカーにも嫌われて、いきなり首チョンパ」
と言う、StarWarsの裏話だったんだな。(違)
"Dark Side of the Floss is the path way to many abilities some consider to be un-natural.."
...つーか新年一発目のネタがこんなんでいいのか?!?
2005年12月22日
Your "wish" is not "correct"
Project DOUBT のような事をしていると、よくいろんな人から
「Linux に問題があるらしいけど、じゃあどうLinuxを使えばいいの?」
と聞かれる。で、実際のところ
「どうしようもありません」
という事実を伝えると
「無責任だ」
となじってくる人が結構多い。
いや、無責任といわれても。そもそも、Open Source OS は Linuxだけじゃない。それを Linux に限定したのは私ではない。あんたらだ。
私が Linux を作ったというのなら無責任といわれてもしょうがないが、ありゃ私が作ったものではない。
おまけに、その Linux をろくなテストもせずに採用したのに至っては、あんたらがやったことじゃないか。私じゃないぞ?!?!! なぜ 私が 無責任なんだか言って見やがれっ!!!!
さらに、この手の人は「自分の希望が正しい」と思い込んでいる。たとえば NFSv2 や v3 では同期的整合性は保てない。のに、同期的整合性を前提とする要求を平然と出してくる。同期しないんだから「いつデータが反映されるかなんか何の保障も無い」と言っても
「いやいやいや、むつかしくてわかんない。」
とくる。ばか者。「むつかしい」んじゃなくて、自分の望みと違うだけだろうが。それは幼稚園児がおもちゃ売り場の前で手足をばたばたさせて泣き叫んでるのと同じことだ。
というわけで、私の説明を聞いて、「難しい」といいたくなったら、それはあなたが無責任な要望を出そうとしているのだ、と考えなさい。常に。
私の説明は「簡単・明瞭・簡潔・丁寧」に決まっているんだから。
「Linux に問題があるらしいけど、じゃあどうLinuxを使えばいいの?」
と聞かれる。で、実際のところ
「どうしようもありません」
という事実を伝えると
「無責任だ」
となじってくる人が結構多い。
いや、無責任といわれても。そもそも、Open Source OS は Linuxだけじゃない。それを Linux に限定したのは私ではない。あんたらだ。
私が Linux を作ったというのなら無責任といわれてもしょうがないが、ありゃ私が作ったものではない。
おまけに、その Linux をろくなテストもせずに採用したのに至っては、あんたらがやったことじゃないか。私じゃないぞ?!?!! なぜ 私が 無責任なんだか言って見やがれっ!!!!
さらに、この手の人は「自分の希望が正しい」と思い込んでいる。たとえば NFSv2 や v3 では同期的整合性は保てない。のに、同期的整合性を前提とする要求を平然と出してくる。同期しないんだから「いつデータが反映されるかなんか何の保障も無い」と言っても
「いやいやいや、むつかしくてわかんない。」
とくる。ばか者。「むつかしい」んじゃなくて、自分の望みと違うだけだろうが。それは幼稚園児がおもちゃ売り場の前で手足をばたばたさせて泣き叫んでるのと同じことだ。
というわけで、私の説明を聞いて、「難しい」といいたくなったら、それはあなたが無責任な要望を出そうとしているのだ、と考えなさい。常に。
私の説明は「簡単・明瞭・簡潔・丁寧」に決まっているんだから。
2005年12月19日
Am I lucky? or Unlucky
12/19は、東急田園都市線にとって厄日だった。
7:30 頃、二子玉川の辺りで車輌故障が発生。8:00に再開するも全線各駅停車。しかも、その運行さえ前後の車輌間隔のせいでものすごく遅かったのだ。
おかげで普段より10分も早く駅に着いたのに、会社に着いたのは普段よりも40分も遅れてのことだった…。
さて、このちんたらした電車の中で、時間をつぶすために「AI麻雀」for PSPをやっていた。そうしたらなんと。緑一色をあがることができた…。
さて、今日、私は lucky? それとも unlucky?
7:30 頃、二子玉川の辺りで車輌故障が発生。8:00に再開するも全線各駅停車。しかも、その運行さえ前後の車輌間隔のせいでものすごく遅かったのだ。
おかげで普段より10分も早く駅に着いたのに、会社に着いたのは普段よりも40分も遅れてのことだった…。
さて、このちんたらした電車の中で、時間をつぶすために「AI麻雀」for PSPをやっていた。そうしたらなんと。緑一色をあがることができた…。
さて、今日、私は lucky? それとも unlucky?
2005年11月15日
Have they requested for BINARY interface? or Source Level interface?
When we talk about device driver interface, there should be three styles, not two:
1. Source code level interface.
2. Binary code level interface.
3. interface for user process device driver interface.
According to what I believe, 1 is usually good idea. Having 1 with full GPL, will prevent non-open device driver availability, and help device driver programmer for they do not have to re-write driver whenever internal interface changes.
2, on other hand, is somewhat little bit more disgusting. You can make it from 1, if you designed the interface. But usually not necessary.
3, lastly, I belive, is something we SHOULD have. This interface will give driver programmer to do debugging at user space, can test long run test to see for memory leak, etc.
Since user process device drivers performance are usually terrible due to lots of system calls required, if proprietary device drivers are being released in binary-only user process style, there shall be only three cases:
1) user choose different HW, for it performs terrible in Linux
2) HW vender will give up, and make program open
3) they decide Linux not to be their market
Any case seems OK to me.... I mean, it's really TRAP for those who do not make device driver source code open. Once they choose 3 for solution, Marketing and Sales persons will start helping community, by forcing development section to SPEED UP the device driver.
If source code could not be open due to BUSINESS reason, we should give them the reason why it is better. Not by giving ideal, broad view. By showing concrete vantage.
1. Source code level interface.
2. Binary code level interface.
3. interface for user process device driver interface.
According to what I believe, 1 is usually good idea. Having 1 with full GPL, will prevent non-open device driver availability, and help device driver programmer for they do not have to re-write driver whenever internal interface changes.
2, on other hand, is somewhat little bit more disgusting. You can make it from 1, if you designed the interface. But usually not necessary.
3, lastly, I belive, is something we SHOULD have. This interface will give driver programmer to do debugging at user space, can test long run test to see for memory leak, etc.
Since user process device drivers performance are usually terrible due to lots of system calls required, if proprietary device drivers are being released in binary-only user process style, there shall be only three cases:
1) user choose different HW, for it performs terrible in Linux
2) HW vender will give up, and make program open
3) they decide Linux not to be their market
Any case seems OK to me.... I mean, it's really TRAP for those who do not make device driver source code open. Once they choose 3 for solution, Marketing and Sales persons will start helping community, by forcing development section to SPEED UP the device driver.
If source code could not be open due to BUSINESS reason, we should give them the reason why it is better. Not by giving ideal, broad view. By showing concrete vantage.
2005年11月9日
What was the problem behind?
Greg,
I do wish to know about "what was the reason behind their problem."
# because it lacks subject, it might be of NFH's reason, but might be of open source side.
# what were you trying to say?
I do have one point of sympathy about NFH's opinion having "Abstraction Layer."
When people outside the HW vendor tries to write device driver, they ether reverse engineer, or read manual. Anyway, HW is already fixed, and solid. Solid enough so that reverse engineering do works. Solid enough so that people can write manual about it.
This is not so for programmer INSIDE the HW vender. HW is not solid, the interface ( and the timing of interfaces ) changes very rapidly. I even experenced interface changing 3times within a week. I see many peoples not believing this, but it does.
How can they change so rapidly? Didn't creating new mask for chips takes about several million dollors? Easy. Because the changes are being caused by micro code, the software.
Hard Coded chips are already there, with plenty of bugs (most of them are still not being found yet ). HW venders do not have extra budget to re-design a chip again. How do we fix HW bugs? with micro code, and if we can't? we call it spec, and device driver have to handle it. Because micro code is under development, they change. The change speed of under development microcode is even faster than kernel interface, and bug list grows like ... like ... I think it's the fastest growing stuffs in the universe...
But on the other hand, many vender wish to have their driver on newest kernel as well. As result, device driver programmer have to take care of two changes at once. One from micro code, and other from kernel internal interface change. This will kill device driver programmer.
How can we help device driver programmers from dying? Fix the interface of kernel to solid state, so that programmers can concentrate on interface change of HW. At least, you can't blame people who came up with this idea, no matter how stupid it may be.
I don't know if this idea is good or bad. But I do have sympathy with people working inside HW vender, trying to struggle for device driver, and those who trys to ease their works by defining Abstraction Layer.
Also, I do know that in old days, well designed Abstraction Layer did last for 10 years without change, and did scale. I don't know if we can say same thing for next 10 years, or even 5 years. But it did in past. How can you blame if people next to hell dreamed of new design lasting for next decade...
If Abstraction Layer is bad, we should not simply give them a reason why it's bad, but also how to solve their problem. How to ease their device driver programmer, without telling them to look for a change within kernel every week, nor month.
Not writing a driver till HW is solid, is not the answer. That's for sure.
I do wish to know about "what was the reason behind their problem."
# because it lacks subject, it might be of NFH's reason, but might be of open source side.
# what were you trying to say?
I do have one point of sympathy about NFH's opinion having "Abstraction Layer."
When people outside the HW vendor tries to write device driver, they ether reverse engineer, or read manual. Anyway, HW is already fixed, and solid. Solid enough so that reverse engineering do works. Solid enough so that people can write manual about it.
This is not so for programmer INSIDE the HW vender. HW is not solid, the interface ( and the timing of interfaces ) changes very rapidly. I even experenced interface changing 3times within a week. I see many peoples not believing this, but it does.
How can they change so rapidly? Didn't creating new mask for chips takes about several million dollors? Easy. Because the changes are being caused by micro code, the software.
Hard Coded chips are already there, with plenty of bugs (most of them are still not being found yet ). HW venders do not have extra budget to re-design a chip again. How do we fix HW bugs? with micro code, and if we can't? we call it spec, and device driver have to handle it. Because micro code is under development, they change. The change speed of under development microcode is even faster than kernel interface, and bug list grows like ... like ... I think it's the fastest growing stuffs in the universe...
But on the other hand, many vender wish to have their driver on newest kernel as well. As result, device driver programmer have to take care of two changes at once. One from micro code, and other from kernel internal interface change. This will kill device driver programmer.
How can we help device driver programmers from dying? Fix the interface of kernel to solid state, so that programmers can concentrate on interface change of HW. At least, you can't blame people who came up with this idea, no matter how stupid it may be.
I don't know if this idea is good or bad. But I do have sympathy with people working inside HW vender, trying to struggle for device driver, and those who trys to ease their works by defining Abstraction Layer.
Also, I do know that in old days, well designed Abstraction Layer did last for 10 years without change, and did scale. I don't know if we can say same thing for next 10 years, or even 5 years. But it did in past. How can you blame if people next to hell dreamed of new design lasting for next decade...
If Abstraction Layer is bad, we should not simply give them a reason why it's bad, but also how to solve their problem. How to ease their device driver programmer, without telling them to look for a change within kernel every week, nor month.
Not writing a driver till HW is solid, is not the answer. That's for sure.
2005年11月6日
The most powerful subwoofer on the planet
これはすごい。これ、何だと思いますか?
扇風機じゃありません。換気扇でもありません。
重低音用サブウーハーですよ。
Eminent Tech TRW 17 というこいつは、WebPageによると、ファンが左右に回転して「送吸風」を発生させ、それによって 1Hz の波を作り出すのだそうだ。
ま、確かに。旧来のコーン紙を動かす方式では1Hzのスピーカーを作るのは至難の業だわな。
普通のコーン型のスピーカーだと100Hz出すのに片道最大3cmぐらい移動できるように出来ている。同じ速度でコーン紙を動かすと、1Hzだと片道300cm…3mだ。3m! もはやそれはスピーカーとかではなく「棒」である。
いや、まぁ、それにしたってさ。原理はわかるけど、誰? これを「造ろう」って言った人は。
2005年10月25日
Press Enter ....
まずはこれを見てほしい。なかなかのスクリーンショットでしょう?
じゃぁ、今度はこれ。もう少しロングから：
見慣れている人はもう判ったでしょうか?
こ れは2005年10月22日に、 JAL 780便のエコノミークラス 18-Dで、自席についているモニターを撮影したものです。本来ならば、ビデオとかオーディオとかが楽しめるシステムなんですが、こいつを interactive モードにして『映画』を選択し、画面になかなか映画一覧が出てこないので思わず6連射をぶちかましたら出てきた画面がこれです。
たぶんベースは Monta Vista なんじゃないかなぁ、と思います。/rhs73/lib/の下にあるのが何なのか本当のところは判りませんが、ゲームか何かを実装する際に Red Hatのライブラリでも使ったのでしょう。
いや、何も飛行機の娯楽施設にLinuxが使われるようになったことを喜びたいわけでも、嘆きたいわけでもありません。今回得られた経験値はちょっと違うところにあります。
最初のほうの画像の最下段にはこうあります：
Please press Enter to activate this console.
しかし、「Enter キー」なんてありません。手元のコントローラーには。いや、もちろん、組み合わせもいろいろ試しましたとも。でも駄目です。どうしようもありません。
はっきり言いましょう。ものすごいストレスです。イライラします。要因は2つです。
1つめの要因は、『本来使えるはずの娯楽施設が使えない。回復させるための操作も出来ない』という事から来る、不自由感に基づいた不快感です。リブートさせれば直ると判っているわけですから、一刻もはやくそのような操作をして環境を回復したいのに出来ない不快感。これはこのような画面を見せられたユーザー誰もが感じることでしょう。
でも、そんなのは2つ目の要因に比べれば些細なことです。
『目の前にバグがあり、
勝手知ったる世界であり、
かつソースコードへのアクセスが阻害されている』
この不愉快さ。Richard Stallman が FSF を作るに至った不快感と本質的に同等な不快感です。
これを検出した瞬間に、GPL2.0では駄目だ!! と思いました。
GPL2.0では、結局GPLで配布されているバイナリの持ち主が、「ソースもくれ」と言えば、ソースコードがもらえる、という制約しかありません。今回バグを出したプログラムがGPLで公開されていたとしても、2つも問題があるのです。
どちらも、「そりゃそうだ」としか言いようがない話に過ぎないように見えますが、これらはようするに
GPLに対して LGPL があるように、GPL3.0では是非、コントロールレベルを複数存在させてほしい。その中にはこれらのアクセサビリティ問題についても
「常にソースコードを参照し、
常にソースコードを変更できる環境を
ユーザーに提供しなくてはいけない」
などという一見非常識なほどの制約をかけたものも用意してほしい。そして、それを選ぶ自由を、プログラマに与えてほしい。
そんな思いが去来したのが、最大の成果でした。
なお、JALの名誉のために言っておきますと、離陸5分後にはリセットをかけていただきましたし、その後はちゃんと動作していました(6連射はやっていませんが)。周囲の座席への影響もなかったようです。
ただ、そのように復旧してしまったコンソールはただひたすらに退屈なものに過ぎず、私は映画も見ずに眠ってしまったのでした…。
じゃぁ、今度はこれ。もう少しロングから：
見慣れている人はもう判ったでしょうか?
こ れは2005年10月22日に、 JAL 780便のエコノミークラス 18-Dで、自席についているモニターを撮影したものです。本来ならば、ビデオとかオーディオとかが楽しめるシステムなんですが、こいつを interactive モードにして『映画』を選択し、画面になかなか映画一覧が出てこないので思わず6連射をぶちかましたら出てきた画面がこれです。
たぶんベースは Monta Vista なんじゃないかなぁ、と思います。/rhs73/lib/の下にあるのが何なのか本当のところは判りませんが、ゲームか何かを実装する際に Red Hatのライブラリでも使ったのでしょう。
いや、何も飛行機の娯楽施設にLinuxが使われるようになったことを喜びたいわけでも、嘆きたいわけでもありません。今回得られた経験値はちょっと違うところにあります。
最初のほうの画像の最下段にはこうあります：
Please press Enter to activate this console.
しかし、「Enter キー」なんてありません。手元のコントローラーには。いや、もちろん、組み合わせもいろいろ試しましたとも。でも駄目です。どうしようもありません。
はっきり言いましょう。ものすごいストレスです。イライラします。要因は2つです。
1つめの要因は、『本来使えるはずの娯楽施設が使えない。回復させるための操作も出来ない』という事から来る、不自由感に基づいた不快感です。リブートさせれば直ると判っているわけですから、一刻もはやくそのような操作をして環境を回復したいのに出来ない不快感。これはこのような画面を見せられたユーザー誰もが感じることでしょう。
でも、そんなのは2つ目の要因に比べれば些細なことです。
『目の前にバグがあり、
勝手知ったる世界であり、
かつソースコードへのアクセスが阻害されている』
この不愉快さ。Richard Stallman が FSF を作るに至った不快感と本質的に同等な不快感です。
これを検出した瞬間に、GPL2.0では駄目だ!! と思いました。
GPL2.0では、結局GPLで配布されているバイナリの持ち主が、「ソースもくれ」と言えば、ソースコードがもらえる、という制約しかありません。今回バグを出したプログラムがGPLで公開されていたとしても、2つも問題があるのです。
- ソースをくれと言って、ソースが手元に到着したころには飛行機は目的地に着いている
- ソースをもらっても、キーボードがない環境ではデバッグも出来ないし、システムへの再インストールもできない
どちらも、「そりゃそうだ」としか言いようがない話に過ぎないように見えますが、これらはようするに
- GPL2.0 ではソースコードへのアクセス時定数という側面を考慮していない。
つまり、ソースコードは「いつかは」手に入るだろうが、「それがいつになるのか」の保証がない、という事です。 - GPL2.0 ではソースコードへのアクセサビリティの保障という側面を考慮していない。
つまりソースコードは得られるかもしれないが、それは、このジャンボジェットの座席システムのように著しくアクセサビリティの悪い環境でしか参照できないように細工されたメディアかもしれないのです。
GPLに対して LGPL があるように、GPL3.0では是非、コントロールレベルを複数存在させてほしい。その中にはこれらのアクセサビリティ問題についても
「常にソースコードを参照し、
常にソースコードを変更できる環境を
ユーザーに提供しなくてはいけない」
などという一見非常識なほどの制約をかけたものも用意してほしい。そして、それを選ぶ自由を、プログラマに与えてほしい。
そんな思いが去来したのが、最大の成果でした。
なお、JALの名誉のために言っておきますと、離陸5分後にはリセットをかけていただきましたし、その後はちゃんと動作していました(6連射はやっていませんが)。周囲の座席への影響もなかったようです。
ただ、そのように復旧してしまったコンソールはただひたすらに退屈なものに過ぎず、私は映画も見ずに眠ってしまったのでした…。
登録:
投稿 (Atom)