既報だったAMDの「PIC」--開発途上国向けPCも正式に発表されました。まずインドやメキシコの市場で売られるそうです。どなたか、一台お土産として買ってきてください。
お土産として観光客が買って持ち帰るよりも、必要としている現地の方が購入して使っていただいた方が好ましいのではないだろうか。
転職情報や就職情報などで、「企業からは問題を解決する能力が求められている」というようなことが書かれていることがある。
しかし、問題認識能力や問題予想能力について触れているものは見当たらない。
問題が発生する前に片づける手腕の方が重要だと思う。スリップした時に、態勢を立て直すという解決能力よりもスリップしたら危険だろうと予想して速度を落とす能力も必要だ。また、そもそも、スリップしていることに気づかないとせっかくの問題解決能力を発揮できずに事故に至る。同様にスリップしていることに気づいても、スリップしていることが危険であるということが認識できないと意味がない。
まさかTeXで年賀状印刷を行うとは思わなかった。
シナリオどおり、プロ野球参入。
パフォーマンスとしてはライヴドアの方が一枚上手というか、残念会見をしっかりと地元候補地の仙台で行ったりして好感度を地道に稼いでいたので、楽天が相対的に悪者風味に。
なにしろポフェショナルでpofessionalだし。
Googleでpofessionalを検索するGoogleの中の人にももしかして : professional
とか言われちゃうくらいポフェショナル。
アクリルの保護シートは剥がさないのに、封印シールは剥がしてしまって本体を分解してしまうギャップが楽しい。
士郎正宗マウスとMXエンジンの夢のコラボレーション! とか思っちゃったよ。こっちのロジテックとは別のロジテックだ。くそー。
細かいことだけど、
を見比べてみると不思議だ。
| Athlon FX-55の記事 | FSB 1,066MHzのP4記事 | |||
|---|---|---|---|---|
| P4 XE 3.40GHz | FX-55 | P4 XE 3.40GHz | FX-55 | |
| 3dsmax-03 | 15.83 | 16.54 | 16.46 | 16.13 |
| catia-03 | 12.49 | 14.37 | 12.52 | 12.64 |
| ensight-01 | 6.197 | 7.012 | 6.332 | 6.318 |
| light-07 | 12.96 | 15.52 | 12.99 | 14.34 |
| maya-01 | 12.96 | 11.81 | 12.96 | 10.99 |
| proe-03 | 15.47 | 17.70 | 15.70 | 14.65 |
| sw-01 | 12.48 | 14.13 | 12.73 | 11.48 |
| ugs-04 | 12.81 | 17.35 | 13.17 | 15.30 |
どういう環境の変化があったのか解らないが、軒並みP4のスコアが上がってFX-55のスコアが下がっている。
前回の結果と比べてみると、3ds maxやCATIA、EnSight、Pro/ENGINEER、SolidWorksなどAthlon 64系で有利だったテストでいずれもPentium 4 XE 3.46GHzが上回る成績を出しているのはなかなか見事というしかない。
確かに前回のテストの時にはP4 3.40GHzのスコアはFX-55に劣っていた。3.46GHzで追い抜いたようにも見えるが、今回のテストの数値を見る限り3.40GHzと3.46GHzのどちらもFX-55を上回る成績を出している。
と言うわけで、FSBが上がったからFX-55を上回ったのではなく別の要因で上回ったとしか考えられない。もしくはFX-55の性能が低下したか。
maya-01のスコアはぴったり一致しているので後からテスト結果の数値だけを操作したとは考えにくい。テスト環境に何らかの変化があったと考えている。
MYCOMのレビュー記事はこうした比較が行いやすいので個人的には大変好ましい書き方だと思っている。
どのBSDだよ。
WindowsやLinuxの被害件数件数が多いのは、ユーザの多さもあるだろうけど「専任を用意できないからお手軽にWindowsで」とか「簡単だと言われているからLinuxで」とかいう感じでスナック感覚でWindowsやLinux機を配置してまともに管理をしていないのではないだろうか。敢えてBSD系を使用する選択をした人たちはWindowsに比べてコストがかかることを承知して使用しているわけで、それなりのコストを掛けているような気がする。
WindowsでもLinuxでもしっかりとした運用をしていればもっと安全になるだろうし、BSD系を使ってもスナック感覚で運用していたら危険だろう。
OS別ではなくて専任管理者の人数/兼任管理者の人数など管理に掛けている手間隙コストで調査したらどうなるだろうか。
10年前からの問題にやっと向き合う姿勢を見せている、というところ。
CPUにトランジスタをつぎ込んでも、演算性能は上がらない。このこと自体は80386の頃には・・・というか私自身がこの辺りに興味を持ちだしたのが80386からなのでもっと前からの話だったのかもしれないけど、私の知る限りは80386をいじっていて、トランジスタの数の割りには性能が無いなあと感じた。80386の前がPC-8801MCのZ80なのでちょっとギャップがあるのだけど。
Z80の場合は演算器の処理が遅くて、そもそも1命令を1クロックで処理できないので使っている分には問題に気づかなかったのだけど、80386を触っていて気づいたのが、このCPUの中にある演算器は普段は動いていないということ。命令を読み込んでいる間は実行ユニットは寝ているのだ。
命令ユニットのの稼働率を引き上げて全体の実行効率を上げよう、ということで80486ではCPUをパイプライン構成にした。これにより、命令の読み込みと解析、実行を並列に行えるようになり遊んでいるトランジスタが減った。
命令の読み込みと解析は比較的短時間で行えるものの、実行には時間がかかる。そのため、パイプラインにしたところで命令の読み込み部(フェッチ)と解析部(デコーダ)はほとんどの時間を停止して過ごしている。実行ユニットを増やせば命令の実行中にでも次の命令を空いている実行ユニットに振り分けることができる。そんな発想からスーパースカラという構成が生まれた。これはPentiumで実装されている。
Pentiumのスーパースカラでは命令実行のためのパイプラインを2つ用意した。それぞれがUパイプ/Vパイフと呼ばれている。これにより、同時に2つの命令を実行できるようになった。命令を読み込んでUパイプに処理を任せ、Uパイプの実行ユニットが処理を終える前に次の命令をVパイプに入れてしまうのだ。これによりフェッチとデコードの稼働率も上がり、処理効率がよくなる。
実は、マルチコアに行く分岐路はここにあった。Pentiumでは
| フェッチ | デコード | 実行部 |
| 実行部 |
こういう構成だったので、一連の流れの命令しか実行できないのだけど
| フェッチ | デコード | 実行部 |
| フェッチ | デコード | 実行部 |
という作りにしてしまえば実のところマルチコア(というかHT)CPUになってしまう。1クロックで同時に複数の命令が処理できる。しかし、実際にはPentium Proではこのようになった。
| フェッチ | デコード | 実行部 #1 | 実行部 #2 | 実行部 #3 | 実行部 #4 |
| 実行部 #1' | 実行部 #2' | 実行部 #3' | 実行部 #4' |
面倒だから4つしか書かなかったけど、実際には8段だっただろうか。Pentium !!!では10段になる。ちなみにPentiumでも元々こんな感じで5段だったような記憶がある。
つまり、命令の読み取り口を増やすのではなくて、実行部を増やした。1クロックで複数の命令を処理しようというのではなくて、実行を流れ作業にして高速回転させようという発想だ。
流れ作業の1手間を簡単なものにすることで回転数、周波数を上げて全体の効率を上げようというアプローチ。この図の場合、実行部を4つに細分化したので回転数は理論的には4倍にできる。あとはフェッチとデコードが追いつく限り回し続けることができる。
実際には途中でメモリアクセスが入って待たされたり、流れ作業を頭からやり直すことになったり(分岐予測の失敗とか割り込み処理とか)で流れ作業がスムーズに流れなかったりする。それに、実行部が2つあっても片方の処理が終わらないと次の処理に取りかかれないものもあったりする。脱水が終わらないと洗濯物を干せない、みたいな。そんなこんなでせっかく複数用意した実行ユニットはフルスピードで回転しているわけではなくところどころ止まってたり待っていたりやり直していたりしていて稼働率は上がらない。
この辺りはPenitumでも同じなんだけど、Pentium Proではデコーダで命令を入れ換えたりすることで流れ作業が止まらないような工夫が入っているので大分マシになった。でも80386の頃は1段で済ませていたものを10個に分割して実行することになるのでちょっと無駄も出るしどこかでこけたらそのラインが全部止まることになるのでデメリットもある。
デメリットはあるけど、売り出し文句としては100MHzよりも200MHzと周波数が処理性能に直結するイメージがあったのでなんとかなった。
Pentium 4ではもっと細かく、20段になる。
さすがにここまで細かく分けると無駄も多い。1枚の板チョコを20粒に分けて一つ一つ個別包装したようなものだ。細かく分けた方が一口サイズで食べやすいかもしれない。でも包装紙がもったいない。
そんな感じでPentium 4では20段とものすごい数にパイプラインを分けてしまった。Prescottではさらに細かくなって30段。こうなると、20個の内どれか一つは寝ていたりする。タイムシェアリングシステムで複数のプログラムを切り換えながら実行しているのだから、足し算をしているときには同時に掛け算はできない。だから足し算をしている間は乗算器は寝ている。当たり前の話。命令をどんどん実行しようということで加算器のような命令実行ユニットをどんどん追加してもそのほとんどは使われず、どれか一つだけがアクティヴに動くことになる。結局のところトランジスタの無駄だ。というわけで寝ている実行ユニットも動かそうとしたのがHyperThreading。こうして
| フェッチ | デコード | 実行部 #1 | 実行部 #2 | 実行部 #3 | 実行部 #4 |
| フェッチ | デコード | 実行部 #1' | 実行部 #2' | 実行部 #3' | 実行部 #4' |
こういう形になった。元の形からフェッチとデコード部分を追加するだけなのでそれほど大変なことは無いらしい。上のラインが止まったら下のフェッチとデコード部が別の命令を読み取って適当に空いている実行ユニットに流す、という仕掛け。しかもフェッチとデコードの回路は上のものと同じものを使い回せる(寝てるから)。
実行のための回路の横軸を細かく分けて回転数を上げていくアプローチでは先が見えてしまっていたので、縦軸を増やして同時に実行できる命令を増やしてしまえ、というのがこれからの流れになる。
TransmetaのEfficeonでは縦軸が8段という構成。そのために周波数が低くてもある程度の性能が稼げる。パイプラインは7段とPrescottの30段と比べると1/4以下だ。仕組み上、デコードに手間がかかるからパイプラインを深くして回転数を上げる意味がないのかもしれない。
| フェッチ | デコード | 実行部 |
| 実行部 | ||
| 実行部 | ||
| 実行部 | ||
| 実行部 | ||
| 実行部 | ||
| 実行部 | ||
| 実行部 |
周波数を上げられなくなってきたのだから、こうした並列実行に頼るしか性能向上の方法は無い。
ただ、何も考えずに並列実行させてしまうと、ただでさえ中が3GHz、外が0.8GHzと4倍のギャップがあるメモリにアクセスが殺到するのでこの辺りも解決しなければならない。
フロントエンドの命令帯域が4wide(4命令/サイクル)の既存アーキテクチャにPARROTを適用した場合には、電力消費の増大を4%に抑えながらIPCを17%向上させることができるという。さらに、PARROTの適用に合わせて命令帯域を8wideに広げた場合には、電力の増大は39%で、IPCの向上は45%になるという。
現時点のCPUのTDPは限界といわれている125Wに近い。もっとも限りなく限界に近い。夏場に冷却が足りなかったりするので油断は禁物でーす。
というわけで(なにが)消費電力を上げるわけにはいかない。145%になる性能を電力分、139%で割ろう。すると同じ消費電力では104.31%、つまりたったの4%の性能向上でしかない。意味無い。
携帯電話の番号「13333333333」を2,300万円で落札。
どうでもいいけど、中国にはいたずら電話とかないのだろうか。うらやましい。
各メディアは、落札者の詳細を伝えていない。また、６日にこの番号に電話をかけたところ、誰も応答しなかった、という。
用もないのに>掛けるなよ。
中国では番号は13から始まる、ということなので「13131313131」だったりするといくらくらいの値がつくのでしょうか。微妙に掛けにくい気もするけど、登録してしまえば選ぶだけだからどうでも良い。
個人的にはもう用は無いから撤退するタイミングを計っているのだと思う。今、何もせずに撤退すると敗退という印象が強いので何でもいいから解りやすい「勝利」のイメージをとってから撤退したい、というところか。
ウソでもいいから「アメリカ勝利!」「アメリカ最高!」とか褒めたたえておけば撤収しそうな気もする。というか、適当に勝利宣言してそれに報道が反発せずにその通り報道してくれるという確約でもあれば撤退するんじゃないだろうか。とりあえず欲しい利権については押さえたし、暫定政府経由で目処もついているわけだし。
磁石が液体だとどっちがN極とか解るんだろうか。というかコンパスに使ったらどうなるだろうか、とか。
ただ、自ら磁石として働く液体を作るには、イオンの向きをそろえるなど、更に研究が必要だという。
あー、やっぱり極が無いのか。つーか揃えたら極ができるのか。青木ヶ原に持って行って見物したい。
ITmediaに表示された広告。
甲殻!
AMDがCPUの製造を外部委託。これにより供給量が改善される。
デュアルコア化でダイサイズが大きくなることが予想され、供給量が少なくなる可能性が指摘されていたのだけどもこれで安心、というところか。
「ん」が入力できなくなった。というかキーを押しても下に下がらない。なんだろうと思って強めに押してみたら「ばちっ」と音がして押せた。すると、キートップがグラグラになってしまった。ぶっ壊したらしい。
確かにそろそろ買い換えの時機だったのだけども今は仕事に使っているので代替するPCがないと困る。ちょっとFIVAでは追いつかない。
実のところ、他のところにはなんら異常がない。せいぜいハイバネーション後にたまに音が出なくなるとかタッチパッドの右ボタンがぐらついているとか一部の塗装がはげているとかカーソルキー下のプリントが剥がれ掛けているとか液晶がすこし暗くなってきたとかその程度で、せいぜいが買うときにけちったせいでHDDが足りなくなっているくらいだ。
って結構マズいな。まあ、そんなものは気にしなければなんとでもなるというか気の持ちようだ。
しかし、キーがぶっ壊れたというのはダメだ。我慢なら無い。とくに「ん」。これは「Y」キーでもあり良く使うキーだ。幸いクリック感は失われていないのでキーを押したつもりで押していないということは防げているけども、タイピング中にキーが「ふにっ」とずれるので一瞬、「別のキーまで指を動かしてしまっただろうか?」という感覚に陥って手元を確認してしまう。割とストレスになる。
男版家事手伝い
というけど、実のところ「家事手伝い」とか「無職」という分類が成り立たなくなっている。
「家事手伝い」という呼称自体が不可解だ。従来は「在職」がデフォルトだったためそれに対して区別するために「無職」という呼称ができた。しかし、「在職」がデフォルトではない人たちもいる。というか、いた。主婦だとかいわゆる女性。デフォルトが無職なので、デフォルトが在職である男性優位社会の言葉をそのまま用いることに何か解らないがいろいろ問題があったのだろう、無職とは呼びにくい状態だったのだと想像する。そこでひねり出されたのが無職女性を示す「家事手伝い」。
今は普通に女性も仕事しているわけだし、「家事手伝い」なんていう呼称を用いることなく、男性と同じように「無職」と呼んで構わないと思う。
ニートという新たな呼称が与えられて注目されているようだけど、結局のところ収入が無く生活を他社に依存しているところは以前に流行った「パラサイト」と同じ人たちで新しい呼称がついたからといって中の人が新しくなるわけではない。
寄生先が親か、ということは寄生行為自体には関係ない。
だからもっと自信を持って「パラサイト」とか「無職」とか名乗れば良い。「在職」がデフォルトではなくなり、「無職」が充分に広まっているのだから。
なんてソーダだ。
中のパンタグラフを別のキーと取り替えれば良いのだ。ってFnキーくらいしか思いつかない。
かっとしてやった。今ではワクワクしている。
第８条 （ウェブログの公開について）
- （変更前）
- 本サービスにて作成されている全てのウェブログについて、当サイトの宣伝を目的として利用者への通知なしに自由に利用することができるものとします。
- （変更後）
- 本サービスにて作成されている全てのコメントおよびトラックバックを含むウェブログについて、弊社は、利用者への通知なしに無償で利用することができるものとし、利用者は、弊社及び弊社の指定する者に対し、著作権等(著作者人格権の行使も含む)を行使しないものとします。
著作者人格権ということは同一性保持権も含むということで、これを行使させないということは大変なことだ。
記事を書いてlivedoorのサーバに保存したところ、勝手に改竄されたとしても文句を言えないという。あり得ない。
これはすごい。
何が売りかというとブログに投稿する記事をオフラインで作成できる
ところ。
正直これが売りになるとは思わなかった。私の場合、手元でHTMLを書いてある程度固まったらlivedoor blogにログインしてHTMLをペースト、そして保存。ブラウザのフォームだと入力領域が狭いし使い勝手も悪いのでテキストエディタに書いてそれを貼り付けるというのが当たり前だと思っていた。一般市民はあの使いにくいフォームでちまちまと入力してますか。HTML+-modeの無い状態でタグとか書いていられないのだけど。
なんとなく、「それは一般市民の行動ではありません ZAP ZAP ZAP」とかいう声が。
面倒なのが画像の扱い。サーバに保存するまでファイル名が未確定なのが難しい。画像は別サーバ、とすると簡単になるのだけど。
結局のところはPOSTリクエストさえ投げられればいいのだからそれ用のリクエストを作るHTTPクライアントがあると便利かもしれない。
やじうまWatchだと流れるのでこちらもリンク。
この手の権利関係の制限については、もっと範囲を限定する必要があると思う。というのも、範囲が曖昧だとどこまでが許可されていてどこからが許可されていないのかが解らなくなり、後で紛争となる。
弊社は主に当サイトの宣伝を目的に利用する場合を想定して、当事者へ無償で利用することをこの規約で確認しておりますが、宣伝かどうかの定義をすることが困難な場合も考えられる為にこのような定義といたしました。
と、範囲を限定する方向ではなくて範囲を曖昧にする方向にするとそのまま拡大解釈されるおそれが出てくるため利用者は不安になるし疑ってしまう。
もう少し具体的に利用者は何をして良いのか、利用者は何をしてはいけないのか、livedoorは何をして良いのか、livedoorは何をしてはいけないのかというのを書くべきだと思う。当然、規約本文ではなくて構わない。
また、ここでいう当サイト
というのが曖昧なのも気に入らない。私は当サイト
というのは利用者のblogのことだと思っていた。なぜなら、元の規約で
本サービスにて作成されている全てのウェブログについて、当サイトの宣伝を目的として・・・
とあったので、当サイトというのは本サービスにて作成されている全てのウェブログ
を指し示しているのだと思っていた。blog.livedoor.jp/XXXX/の宣伝のためにblog.livedoor.jp/XXXX/以下のリソースをlivedoorが利用するのは全く問題ないだろうと。
さて、この文脈で言う「当サイト」とはどのサイトだろう。
関係ないけど、「当サイト」という音の響きは「ゾイサイト」に似ている。
「再生にはWindows Media Player(無料)が必要です。」なんて書いてあるのだけど、そのためにはWindowsが必要なんじゃないのかとか思った。N88-BASICで再生できましたっけ?(その前にマシンパワーが足りませんというか8色ですか)
家事手伝いとパラサイトとは完全に別物じゃないかな。
とあったのでちょっと考えた。私の中では「家事手伝い」という呼称は正当な労働に対する呼称ではなくて、何もしていないことに対して見栄を張るための呼称だという認識なのでこうなっている。
肩書は会社員なんだけど、実態はちょーサボり系ぐーたら社員とか。
で、先日はいい言葉が思いつかなくて主婦だとかいわゆる女性。
なんて書いてしまったわけだけども、主婦というのは正当な労働だと思っているので実はここで挙げるには不適当だ。
で、思いついた。これだ。「花嫁修行中」。
これは、いわゆる「永久就職」に就くための「職業訓練」に当たりますか?
そういえば、朝は雪が降っていた。
どれがでるかはお楽しみ。
と書いてあるものの、「どれ」というのがどの集合から抽出されるのかがさっぱり解らず、迂闊に選択するとタブクリアとかサスケが出てくるのではないかとビクビクしている。
幸い、端に配置されているため間違って選択ボタン押すことは無いと思われる。
SleipnirというIEコンポーネントを使用したブラウザのソースコードが盗難にあったらしい。というか、盗難にあったのはソースコードが格納されたPCを含む家財道具もろもろ、通帳その他だそうだ。
このために開発継続が困難になったとのアナウンスがあった。
私の場合はCVSリポジトリがPCG-SRX3にあったりするのでこれが盗まれると大変なことになるが、ちょっと前のソースコードであれば別のプロバイダのWeb用ディレクトリにぽつんとおいてあったりするので、仮に家が燃えてもDFとBKEYのソースコードはだいたい安心できる。
しかしDFCUSTとかDFVUのソースコードは保存の対象にしていないので、こちらは失ったらそれまでだ。これも保存しておいた方が良いかもしれない。
地理的に別の場所というのは重要なポイントでこのあたりは以前にフィンローダさんがバックアップとして記録したCD-Rを自宅とアジトの二カ所に分けているという話をされていたのを受けて、私もまねをしてこのような体制としている。
ちなみに隔離して保存してあるDFのソースコードにはアクセス制限など掛けていないので、URLが解れば誰でもダウンロードできてしまう。そこまでコストを掛ける必要性を感じていないのでそのようにしてある。
今バックアップ先を確認したら1998年物のソースとかがあって感慨深いものがある。
で、./Jのコメントにおもしろいものを見つけた。
ソースリストをプリントアウトとかしていなかったのかなぁ…と、思ったんですが。 机上デバッグとかの為に、印刷するのは普通じゃないんでしょうか。
今どきプリントアウトする人がいるのだろうか。手軽にデバッガを使える計算機環境なら手間のかかる机上デバッグを行う必要がない。
そもそもプリンタを持っていないかもしれない。私もたまに、モノクロレーザがあればソースを印刷するときに便利かなあ、とは思うけどそもそも印刷しないので不要。
とりあず今は、VAIOカルテのPDFを印刷するのにレーザプリンタが欲しい。
まだリリースというかDFのディレクトリにはputしていないのだけど、手元では手を入れている。何が起きているか、ということは書いておくべきだろう。
この版での修正項目として書くつもりでいるのは
CreateProcess()とShellExecute()とShellExecuteEx()の違いについていろいろ☆
というやけに情報量の少ないものだけど、ここで情報量が多くてもあまり意味がないというか意味を見いだせていないのでこんな感じだ。
まず、外部プロセスを生成するためのAPIとそのユーティリティAPIについて説明する。代表的なのは上に挙げた3つだ。DFでもこれらを使う。他にもあるが、OSのバージョンによってアレだこれだとややこしい制限があるので他のものを使うことは想定していない。
最も単純なプロセス生成API。理論上、これでプロセスを生成するのが最高速であり余計なサービスが無いため軽い。できるだけこれを使いたい。
また、拡張子の関連づけを用いないため、Sircamのように.EXEファイルの関連づけを変更していても該当プロセスを生成できる。この理由からもできればこれでプロセスを生成したい。
実行ファイル名と、パラメータはひとまとめで指定する。独立して渡すことも可能だが、手間がかかるのでしない。
拡張子に関わらずプロセスを生成できるので、PEヘッダさえ適切であれば拡張子が.MPGなファイルでもプロセスは生成できる。これは危険かもしれないので除外する仕組みが必要。
関連づけを用いて起動する。関連づけ情報はレジストリから取得する。
実行ファイル名と、パラメータはひとまとめで指定するため特に何も考えなくて良い。
ただし、関連づけがなされていない拡張子の場合は単純にエラーとなり、どのアプリケーションで開くかという問い合わせがなされない。
関連づけを用いて起動する。関連づけ情報はレジストリから取得する。
実行ファイル名と、パラメータは分離して渡さなければならない。
関連づけがなされていない拡張子のファイルを指定した場合、どのアプリケーションで開くかという問い合わせを行ってくれる。
以上の違いからShellExecute()では未登録の拡張子を指定したときのフォローが足りないため使用しない。
また、「C:\MY.EXE」という実行ファイルがあるときにShellExecute("C:\My Document\readme.txt");を実行するとC:\MY.EXEが起動してしまう。これは危険というか安全ではない。同様にC:\PROGRAM.EXEがあると、C:\Program Files\Microsoft Office\Office\Excel.exeを指定してもExcel.exeではなくてC:\PROGRAM.EXEが起動してしまう。
ShellExecuteEx()であれば実行ファイル名とパラメータを分離するため大体の問題は解決する。SirCamに感染している場合のような拡張子.EXEに別のものが関連づけられていることを考えるとこれは避けたい。使えるケースでは積極的にCreateProcess()を使うのが安全だ。
というわけで、
と、与えるパラメータが異なってくる。162以前でバッチファイルへパラメータを渡せなかったのはShellExecuteEx()を用いるときにもファイル名とパラメータを分割していなかったためだ。これはC:\MY.EXEがある時の動作に不安を感じていたために、変なものが動くよりは動かない方がましだろうということでこうしておいた。乗り越えるには cmd.exe /k batch.bat param param paramとでも指定しておけば良いので個人的には問題だと思っていなかったということもある。
個人的にはWindows 98からWindows XPに移行したことによりFD.COMを起動する必要がなくなったため(これはPEヘッダを持たないDOSアプリなのでCreateProcess()では起動できない)ShellExecuteEx()でのアプリ起動は単独ファイルの関連づけさえできれば良い状態になりパラメータを渡す必要がなくなった。そのため、ますますShellExecuteEx()でパラメータを分割していないことは問題だと思っていなかった。
しかし、スレでバッチファイルにパラメータが渡せないということが指摘された。私はパラメータを使ってまで処理を行うようなバッチャーがいることに感動してしまったため、安易にファイル名とパラメータを分割してShellExecuteEx()を呼び出すように変えてしまった。
この際、"でくくられている場合にパラメータを分割し損なうと、わざわざ"でくくっててもC:\MY.EXEを起動してしまうというまぬけな事態になってしまう。よって、ある程度の考慮はしておいた。
手元で試したところ、"c:\program files\test.exe" paramを「"c:\program files\test.exe」と「param」にしたところ起動に成功した。後ろの"は拡張子判定で.EXEと.EXE"を異なるものだと見てしまうので消しておかないと困る。が、前の"はあっても問題がないようなので放置しておいた。で、これでバッチファイルにパラメータ付けて起動できることを確認。163として放流。
しかし、"C:\Program Files\DF\DFCUST.EXE" $Rが起動できない、という想定外の指摘。試すとこちらでは起動するため問題が解らない。
つづけて
具体的には、「"test.bat" hoge」を入力すると、「'"test.bat'が見つかりません」云々のエラーダイアログが出る。
ということで、これは前の"は消さなくても問題なさそうだと思って消さなかったことの弊害のようだ。ただ、こちらでは動いてしまっているので何がいけないのか解らない。消しておくのは簡単だ(というか、消してみた)がこれで直るのかどうかが判断できない。
162相当に戻してしまうのが良いのか。もっと広範なエラーが発生する入力パターンをサンプリングして調べた方がよいのか。何にしろ判断するには情報が足りない。
ブルースクリーンがIRQ不足である。
と結論づけてますが、エラーメッセージはIRQL_NOT_LESS_OR_EQUAL。IRQではなくてIRQLが不足。
これはどういう意味かというと、割り込みを処理している時の権限が不足しているという話。カーネルドライバでは大雑把に割り込みが発生した直後のディスパッチレベルと、そうではないパッシヴレベルの2つがある。で、パッシヴレベルの時には動作に制限はほとんどない物のディスパッチレベルでは一部の動作が制限されてます。IRQL_NOT_LESS_OR_EQUALというエラーは、そういった動作のレベルが不足しているというもので、決してIRQが不足していることに起因するエラーではありません。
主旨と異なるツッコミが多いので。主旨はIRQ(カーネルモード）を使ってるのに、十分試験してないってどういうこと？
とのことなので、こだわりませんし、動作確認が足りないのではないかという主張には同視します。しかし、結論としているIRQ不足
という認識に誤りがあるため
自作マシンの人はディスクを抜いて入れるとブルースクリーンになる可能性があるので注意して欲しい。
ということは誤りです。
想定外の割り込み処理モードでドライバが呼び出されているために発生しているエラーなので、これはどんなシステム構成でも発生するエラーです。周辺機器をたくさん接続していてIRQに空きがないから発生するというものではありません。
おそらくDVDドライブのドライバに寄生する形のドライバ(フィルタドライバ)として作ってあってそのDVDドライブのデバイスドライバに起因するエラーなのではないかと思います。
NVIDIAとIntelが提携。これにより、nForce相当のチップセットがIntel CPU向けにも作られることが期待できる。
AMD向けのチップセットにおけるnForceの魅力は、SiSやVIAと比較しての性能の高さだけれどもIntel向けとして考えると微妙。というのもIntel向けであれば価格は高いものの高性能なチップセットをIntel自身が出しているからだ。
となると、Intelが期待しているのはnForceがあるからAMDを選択するというNVIDAマニアか、nForceのネームバリューか、nForce内蔵グラフィクスのどれかだろう。
nForceを使いたいだけでAMD製CPUを選択するほどのマニアは数が少ないと思う。というか存在するのかどうか。「高性能なnForce」といううたい文句は、同じくチップセットを作っているIntelが望んでいるものとは違うのではないか。IntelとしてはnForceよりもハイスペックなチップセットを出したいだろうし、出してくるはずだ。そうなると、内蔵グラフィクスが目当てではないかという気がする。
ATiもグラフィクス内蔵チップセットは出しているものの、グラフィクスの性能は芳しくない。現時点のIGPではX300ベースというローエンドな内蔵グラフィクスしか提供していないからだ。i915Gに内蔵しているGMA900の性能はメモリの帯域にもよるけどいい線行ってGeForce FX 5200相当でしかなく、性能面では少々心許ないのかもしれない。
入力値はチェックしろ、というのはプログラミングでの格言というか常識というか。
解っちゃいるけど、想定している範囲であればチェックしようとは思うけども想定していないものを突っ込まれるとそもそもチェックしようという発想が生まれない。危機管理というか危機認識能力が問われる。
DF設定="C:\Program Files\DF\DFCUST.EXE" $R
>>152とか。何が予想外かというか、$Rの前に空白を置くところだ。
このため、DFでは"C:\Program Files\DF\DFCUST.EXE "という、解りにくいが末尾に空白がついたコマンドを実行しようとする。別に問題にはならないので構わないのだが、私としては
DF設定="C:\Program Files\DF\DFCUST.EXE"$R
こういう指定をするものだと想定していたのだ。空白に意味があるかもしれないので無条件に削除するのはいかがなものか、というわけでそのまま実行するようにしていた。当該スレの当該レスの人だけではなくて、$MFや$Rの前後に空白を付ける人は結構多いようだ。末尾の空白については無条件に削除してしまった方がトラブルが少ないのではないかということで消してみた。
また、$Rの後ろにオプションを続ける人がいるのにも驚いた。というのは、元ネタのFDでは
- $R
- 登録コマンドの起動時に追加パラメータの入力を省略します．また，このマクロ以後の文字列は無視されます．
というわけで、$Rの後には何も書けないのだ。DFでパクる…いや、互換性のために同等の機能を実現しようとした時に$Rの後ろを無視というのはいかがなものか、と思ったので無視するというかパラメータ解析を打ち切るということはしなかった。しなかったけども、実際に$Rの後ろに文字が追加されているところを見るとなかなか不思議な気分だ。
よく考えたら末尾に書くよりも先頭に書いた方が解りやすくていいかもしれない。DF=$RDF.EXEとか。それにしても$?とかの前後に空白がつくというのは予想外だった。
さらに、2005年中を目標に、企業向けパソコンと家庭向けパソコンの共通プラットフォーム化を図る予定であり、同時に、ノートパソコンとデスクトップパソコンの部品の共有化も目指すという。
これもコスト削減に大きな威力を発揮することになる。
コストの削減に成功したが利益も削減、という結果になりそうだが大丈夫か。
ノートパソコンとデスクトップパソコンの部品を共有化ということはどちらも中途半端になってしまいそうだ。マウスを共通化というのならまだ解るけど、液晶を共通化した結果10.4インチ液晶を搭載したモバイルデスクトップパソコンなんて作られても困る。というか、買わないから困らないけど。
これはアレだとしても、マザーを共通化した結果ノートみたいに小さなデスクトップパソコンが作れたとしてPCIカードも刺さらない、VGAも交換できない、そんなデスクトップが売れるだろうか。買った人は満足できるだろうか。
私自身はROやLineage2やMoEをやっていたりやっているので動作環境スレみたいなものを良く見たりする。見るどころか回答を付けまくったりする。それはそれとして、見ていると意外と省スペース型のデスクトップを使っている人は多いようだ。で、せっかくパソコンが有るのだからゲームもしてみようか、でも動きが悪いなあ、ということで相談にくるのだろう。
こうした省スペース型ユーザに対するアドバイスとして真っ先にあがるのが「買い換えろ」。まあ、回答者の考える「快適」と省スペース型ユーザの考える「快適」というのには大分差があって目標60FPS、悪くても30FPSは維持、というのと今10FPSだからせめて20FPSくらいまでは…と考える人とでは話があわない。
low profileなVGAカードをお勧めしてみたりはするけども、low profileのGeForce FX 5200でも付ければ今よりはましになるけど、せっかくだったら+n円出してPC買い換えたら? という話になってしまう。
買った当時はゲームなんてするつもりは無かったかもしれないけど、普通の人は年賀状を印刷したらもうあとはゲームくらいしかすることが無いというかできることが無いわけで、「せっかくだからゲームでも」という発想に至るのはとても自然だ。ゲームでもしようと考えた途端に「買い換えろ」と言われてしまっては、二度とそのメーカのパソコンを買おうとは思わないのではないか。本当に悪いのは、ゲームもしたくなるかもしれないという可能性に至らなかった購入者なのだけども。車の場合なら「ちょっと買い物に使うくらいだから」とミニ買ってみたものの、結婚したり家族が増えたりしてミニでは狭いとなったとき、購入者は「こんな予定ではなかったが」とは思いつつも車を買い換えるだろう。車は見れば積載量というか広いか狭いかくらいは解るし、購入者もある程度の知識があるから納得できるわけだ。
しかしパソコンとその購入者はまだそのレベルまで成熟していない。外から見ただけでどの程度まで使用に耐えるかというのは解らないし使う方もこの程度の使用用途だからこの程度でOKという判断ができていない。
デスクトップパソコンなら高い拡張性があるので後から足りない部分をパワーアップできます、みたいな売り文句があったりするけども省スペース型には当てはまらない。こういったことを知らない購入者もいる。メーカや販売店はきちんと伝える必要が有るのではないか。となると悪いのはメーカや販売店なのか。
昨日はデスクトップとノートの部品を共通化したら中途半端になって売れないだろう、とか思った。
省スペース型デスクトップで一番の難点はPCIカード/AGPカードが使えないところなんだけど、これが必要なのはキャプチャカードとビデオカードくらいだろう。というか、ゲームしようという用途であればビデオカード以外は考えられない。
ここで思い出したのが後藤弘茂のWeekly海外ニュースでも話題にされていたXMX。
デスクトップ代替ノートと省スペース型デスクトップであれば共通化できるし、どちらもそれなりに売れ線だから狙い目かもしれない。となるとXMXが使える環境、PCI-Expressが浸透してからが日立の本当の勝負だ。
別にPCIカードが刺さる厚さが20cmくらいあるノートとか出てきても面白いのだけど。
別に厚さが20cmでなくても、ディスプレイの奥行きが20cmくらいで、ディスプレイの裏にPCIカードを刺す仕組みでも良いかもしれない。MZ-80みたいな感じ。通じないか。こんなかんじのやつなら奥行きがあってもあまり違和感が無い。ような気がする。
来るべきtype Tに備え、持ち運びカバンを検討中。
WISEWALKERというのがSRXにちょうど良いサイズで気に入っていたのだけど、ジッパーがほつれてしまったのでピンチ。これからの雪国では生きていけない。type TはSRXよりも横幅が少し大きくなるのでサイズも少し考えないといけない。
紙幣は高い耐久性を誇るものの、ホログラム部分は比較的熱に弱い。日銀は詳しい耐熱性を明らかにしていないが、アイロンを何秒間も押しつけた場合、他の部分は大丈夫でも、ホログラムは模様が浮かび上がらなくなったり、下地が出たりするという。
ATM/CDで、紙幣に自動的にアイロンを掛けてくれるものがあったと思うのだけど、あれは大丈夫なのだろうか。
ホログラムが壊れても紙幣としての価値は変わらない。
とのことなので気にせずバンバンアイロンを掛けてもよいのだとは思う。
AOpenがDothan+Alviso(Sonoma)の組み合わせのノートを展示したらしい。Dothan機を注文したばっかりだというのに!(まだ届いていない)
ExpressCardも搭載されていて発売予定は2005年1月。もうすぐだ。しくじったか、と後悔したものの落ち着いて考えればこのタイミングで買ってもExpressCard対応の@FreeDもAirH"もないわけで激しく不要。ここはDothanで粘ってExpressCardが普及するのを待つフェイズではないか、と思うことにした。
負け惜しみとも言う。
午前3:30頃(?)、激しく揺れて目が覚めた。
おかげさまで眠い眠い。
雪だっ。寒いぞ。
吉川氏は「私的録音が野放しになっているという主張もあり、早急に解決しなくてはならない問題だ」と述べる
私的複製は著作権法上でも認められている権利であり、何をもって野放しと言っているのか疑問。
もしかして、買ってきたCDをClieにコピーしたり、ベーマガのソースリストをコピーして打ち込むといった私的複製は行ってはいけないものだと考えているのだろうか。
軽く私的録音補償金制度にも触れているけど、私はあの制度は妥当なものだと思っていない。私はよく10分テープや30分テープを買っていたが、あれらのテープはPC-6601SRに接続したデータレコーダ(PC-DR312)でプログラムを記録するために使用していたものだ。なぜ自分が書いたプログラムを記録するために私的録音補償金などというものを払わなければならないのか納得がいかなかった。
レンタルCDなどからダビングした時には著作者に還元すべきだ、というのは解る。だから、録音メディアから徴収するのではなくてレンタルショップから徴収するのがスジといえよう。ダビングしなければ著作権者に還元しなくてもよいというものではないのだから。どの作品がどのくらい貸し出され、その補償金としていくらの収入があった、と細かなデータがあったほうがレコード会社からもマーケティングの資料として有用だ。録音メディアからの徴収だとどの曲に人気があるのかさっぱり解らないではないか。これでは著作権者に適切に還元することなんてできやしない。
どうにもこうにもRedHat Enterprise Linux用のkgdbやkdbが見つからない。それっぽいのを突っ込んでみるとpanicする。kdbはrejectされるし。スケジューラ周りに手が入ってるせいで何をどうしたらデバッガのパッチを当てられるのかがさっぱりだ。
というわけで、RHELに使われている2.4.21に近そうで、kgdbやkdbのパッチが用意されている2.4.23を準備。
圧縮ファイルの検索がめちゃくちゃ遅い。
linux 2.4.xカーネルのbz2ファイルをLHMeltで展開しようとしたらものすごい勢いでCPUタイムを消費し始めて何もできなくなった。
LHMeltが悪いのかと思ってDFのビューアでlinux-2.4.23.tar.bz2を開いてみてもかなり固まる。ビューアで開くだけでmcshield.exeのCPUタイムが45秒ほど増え、その45秒間はほぼ操作不能。というわけで、LHMelt無罪。悪いのはmcshield.exe。これはMcAfeeのVirusScanに含まれる実行ファイルだ。
VirusScan 4.xのころは一番軽いスキャナだと思っていたけど、今使っている7.1.0は使い物にならないほど遅い。30MBもないような圧縮ファイルのスキャンにどれだけ時間を掛けているのだ。というか、時間がかかるのは仕方がないにしてももう少しプライオリティが低い状態でやってほしいというか、スキャン中にほかの処理もできないのは困る。
PCG-SRX3にプリインストールされていたNorton AntiVirus 2002ではここまでひどくなかったような気がするが、修理中なので計測できない。
ちなみに、45秒固まるのはThinkPad R30というPentium !!!/1GHzのマシン。PCG-SRX3よりはパワフルだ。SRXのキーボードに慣れてしまうとR30のキーは重くてイライラする。借り物なのでキーボードドライバにパッチを当てるのもちょっとためらいがあったりしてCtrlキーを押し間違えること多数。
キーボードと液晶、タッチパッドとすべてsonystyleの3年間保証サービスで修理してもらえることとなった。ビバsonystyle。
LHMeltもDeacesも、アーカイブを読み込んだ後のリストのソートだとかそういうところにものすごい時間がかかる。もっと速いものはないのだろうか。
13日に注文したtype Tが、sonystyleから発送されたとのメールを受信。わくわく。
