[ソフト開発日誌] カテゴリの記事
全883件 (883件中 851-883件目)
-
DION の名簿漏れ - 自分も該当者かも知れない
blog は楽天につけているけど、入っているプロバイダーは DION だったりする。こんな風に書いている時点で名簿漏れはあまり気にしていないのかもしれない。色々と漏れた条件を当てはめると、自分も該当者の可能性が高い。でも待てよ、生年月日: どこかに書いてあるかもしれない名前: scankeylx の説明に書いてあるし住所: 引っ越してしまったので、誰か知らない人の所連絡用メールアドレス: 確か携帯だか、前のプロバイダーのアドレスの筈だけど、携帯は事情があって変えたし、前のプロバイダーも契約は終了しているし何だかとっても自分の情報に関して言えば役に立たないゴミ情報になってしまっている。もっとも、過去の情報を元に自分に成りすまして振舞われると少し困るかもしれない。自分が自分である証明は結構ややこしい。
2006.06.14
コメント(0)
-
誰のために規格はある - お客様が安心して使うために
たまには仕事のことでチョット書いてみる。具体的な製品とかは伏せておく。自分の直接の仕事ではないが、隣のミーティングコーナーから大きな声が響く、何でも規格認定試験ではねられたそうだ。はねた理由はアプリケーションレベル、要するに機械的、電気的、通信手順のことではなくて「使い勝手の観点」で問題ありとされたようだ。議論は使い勝手まで規格で定めていないのに何事かという事だった。さも認定機関が恣意的にダメだししたとの論調だった。確かに技術的には論は理にかなっている。しかし、使い勝手の向上こそデジタル家電が背負う課題だと思う。使う人の立場に立って考えると、やはり今の設計では問題ありだと感じる。当事者ではないので何とも言えないけど。おごれる家電メーカーは気づかぬうちに常識を外す。そして、全てを失ったときそれに気づく。
2006.06.06
コメント(0)
-
Cell システムは何ワット食うのか？ - インターネットに隠し事はない
噂では Cell を使った次世代ゲーム機は 500W と言われているけど、いまだ事実を公に確認した情報源はない。だけど、インターネットは広い、実は探すと色々と出てくる。Cell の評価システム Cell Technology Evaluation System (実際のリンクは製品群) というのが売られている。その中に軍事向けに PowerBlock 200 System というのが存在する。その技術概要の中に 28VDC 400W としっかり書かれている。もちろん軍事向けゆえ、冷却機構は強化してあるだろうし、IO 端子はかなり多い、9 個の Gigabit Ether I/F, 4 個の 2-Gb Fiber Channel, Mezzanine card I/F だってついている。これらの分を差し引くと恐らく 300W から 350W がプロセッサ + 周辺 + メモリの消費分だと思われる。さて、ここからは逆に足し算だ。ゲーム向けの色々な周辺を加えていくと、どうだろう 400W に逆戻り(いや、超えるかもしれない)だろう。2 スピンドルで 30W、互換回路で 20W、I/O で 10W、グラフィックスで少なくとも 100W というところか。合計は 400W から 460W がありえる線だと思う。ちなみに、Cell Technology Evaluation Systemから、少し計算はややこしいけど似たような結論が出てくる。ラック自体の消費電力は IBM のサイトで探せば全て把握可能である。思うに変に洒落た筐体より PowerBlock 200 System のような無骨なデザインのほうがかっこいいじゃないかと。最後に断っておこう、ただの推測でしかない。大きくいい方向に外してくれることを願う。
2006.05.29
コメント(0)
-
RTL8169 - 亜種(OEM)が存在する Giga 蟹
RTL8169 1 Gigabit Ether Network カードが認識できない。Windows は RealTek から拾ったドライバが不適合だと言う。壊れたのか？と思って実は買いなおしてしまった。しかし、落ち着いて調べてみたら、RTL8169 には亜種(OEM)が存在することが分かった。PCI の Vendor ID と Device ID をPCI カードの情報を調べるサイトで調べてみたらVendor:DeviceCorega 型番コメント10EC:8169CG-LAPCIGT2いわゆる本物のギガニ1259:C107CG-LAPCIGTAllied Telesyn (アライドテレシス) と Corega のギガニだった。調べたとおり Corega からドライバを持ってきたら適合した(Corega はアライドテレシスの子会社 - でも持ち株会社が出来たようだから少し様子が違うかも)。前期型 CG-LAPCIGT と 後期型 CG-LAPCIGT2 の 2 製品があることからすると、何かてこずったのかもしれない。後期型は本物の RTL8169 (10EC:8169) だからだ。ちなみに Windows XP で Vendor ID と Device ID を調べる方法は「スタート」ファイル名を指定して実行「mmc %windir%\system32\devmgmt.msc」列挙されたツリーを適当に開いて現れた「デバイス」を右クリック「プロパティ(R)」選択「詳細タブ」「デバイスインスタンスID」の VEN_XXXX の所が Vendor ID, DEV_YYYY の所が Device ID である。そろそろ、マザーボードに 1 Gigabit Ethernet の I/F 付のを買うべきだとは思うけど、こうやって NIC が増えていくんだよな。
2006.05.28
コメント(0)
-
scankeylx r0605a リリース - 実際のリリースは 5/28 だけど
プロダクトキー検索ツール scankeylx をバージョンアップしてリリースし、0605a 版となった。今回は大変だった。主な強化点は次のとおりKNOPPIX 5.0 対応検索可能なキー拡大検索結果を整理するツール添付メモリ不足になってしまう問題を解消説明文書見直し後退した点はフロッピーディスクで利用する形態を廃止USB ストレージに必要な容量を 32Mbyte に引き上げKNOPPIX 3.9 を実行環境から外す(3.9 自身の動作が非常に怪しい)一応色々とチェックしてきたけどまだ漏れがあるかもしれない。KNOPPIX 5.0 から 3.8x まで色々と環境が変化していて対応には困ったことが多かった。色々と変わったところが多く、戸惑うかもしれませんが、新版をよろしくお願いします。
2006.05.27
コメント(0)
-
SiI0860 IDE カード - それなりに動作する
拾った SiI0860 IDE カードを試しに動かしてみることにした。いきなりハングなどの重大な障害は発生しない。Windows Xp でドライバもインストールできた。とりあえず CD-ROM ドライブを接続して様子を見ることにした。CD-ROM のアクセスに問題はないようだ。Windows から中身を確認できる。ただし、SiI0860 経由で接続した CD-ROM からブートできない。原因不明、CD-ROM のブートコードをロードすることはできている。しかし、BIOS が正しく動作していないのか、ブートコードが CD-ROM ドライブを見失っているようである。BIOS を書き換えれば改善するかもしれない。ただし、当面は緊急の用ではないので見送ることにする。やはり捨てられたカードなのか。
2006.05.25
コメント(0)
-
Sil0860(訂正 SiI0860) IDE カード Get - どうも動かないから捨てられたか？
Silicon Image のSil0860(訂正 SiI0860) IDE カードを拾った。でもどうやら動かないから捨てられたらしい。まだ動作チェックはしていないけど、簡単な目視でチップのピン間に半田ブリッジらしきものを発見し除去した。そのほか細かなごみもピン間に見られた。Sil0860(訂正 SiI0860) で検索してみるとなにやら相当てこずるカードらしい。RAID は構成しないので多分大きな問題は抱えないと思う。さて、空いている PCI スロット有ったけ？
2006.05.23
コメント(0)
-
MSDN Pro 更新 - なんか毎年高くなっているような
MSDN Professional Subscription 契約を更新した。なんか毎年高くなっているような気がする。今年は 13 万円ちょっとの所を値引きで 12 万円ちょっとになった。Open Licence を使えということなんだろうけど、企業でないと簡単にはライセンス形態を変更できそうにない。ただ、今年は高くなったせいか、プラスチックカードの証書が来た。最近は OS のライセンスしか活用していない。Visual Studio はもっぱら HTML エディタだ。言語関係は全部入りでタダになってしまったし。それでも組み込み向けのバグが多く使いにくいコンパイラとデバッカのセットよりは安い値段なんだよな。
2006.05.21
コメント(0)
-
開発ソース修復 - まるごとバックアップすれば良かった
論理的なディスクの破壊を起こした Vine Linux を修復(過去の日記)し、開発を続行できるようになった。ソースコードも復旧し事なきを得たかと思った。しかし、kylix3 でコンパイルしたアプリケーションのフォームがターゲット環境の KNOPPIX で崩れてしまう問題が発生した。Font の CharSet を設定し取りあえず違和感が無い程度に修正。言語指定を明確に Laten1 にした。しかし、それでも少しおかしい。この際開発環境の OS まで新しくしようと思ったのが裏目に出た。そう、「元に戻す」という鉄則を忘れていた。以前の環境であちこちに施した修正を忘れているのかもしれない。特に X11 周りは修正が分散しやすい。/etc/、/usr/X11R6/、~/.[xX]* など沢山ある。環境のレギュレーションまたはブートするところから全てバックアップする必要性を改めて感じる。
2006.05.20
コメント(0)
-
ソースコード格納ディスク壊れる - 開発最終段階に差し掛かるとお約束の様に起こること？
scankeylx のソースを格納しているディスクが論理的な破壊を起こした。Vine Linux を立ち上げたら fsck でディスクをチェックしろとの指示が出て、root shell を起動するためのパスワード待ちになっていた。「そうか、fsck をすれば良いのか、ext3 だし大きな問題にはならないだろう」。と思って実行したら、エラーの嵐に見舞われた。「まずい、fsck でファイル構造を破壊してしまう」。と思った時には遅かった。かなり大量のファイルが失われていく(lost+found 行きだけど、大量に有るとただのゴミでしかない)。しかし、いまさら修正の問いに No とは答えられない。昔 SunOS 4.1.x 台の OS で、マズイ思いをした。ディスクの障害が発生して fsck をしたのだけど、ルート付近のノードが失われたため、ファイルを全て失う羽目になった。ノードのバックアップを分散して配置してある筈だけど、役に立たなかった。fsck の鉄則を忘れていた、fsck -N でとにかくどの程度の規模の問題があるか見積もってから、どうするか考えるべきだった。落ち着いて dd で丸ごとコピーを作ってから、コピーを修復してみる余裕だって出来たはずだ。幸いなことに fsck 後のディスクはファイルがかなり失われているかもしれないけどマウントできるし、連休前に DVD-R にバックアップも作ってあるし、と言っても帰省中に進めようと思って実家に持って行ったまま置いてきたのだけど、捨てられてなければ...。反省すべきは、予兆として kernel panic が頻発していたことに無頓着だったことバックアップを作ってはあったが直ぐにアクセスできる状態ではないこと修復作業を慎重にしなかったこと修復のやり直しが出来る様にしなかったこと開発最終段階でお約束の様に大きな設備トラブルに巻き込まれる事に備えなかったことだと思う。まぁ、どれも教科書に書いてあることだな。まぁ大丈夫、ソースが完全に lost した訳じゃないし
2006.05.17
コメント(0)
-
scankeylx 動作確認中 - KNOPPIX の版を限定しようかな
scankeylx を KNOPPIX 5.0 に対応させた。しかし、後方互換性も確認する必要がある。久しぶりに古い KNOPPIX を引っ張り出してきて動作させてみた。色々と後方互換性に問題があることが分かってきた。手順書に書いてあるとおりにならない。・KNOPPIX 3.9 デスクトップの下のバーにコンソールアイコンが存在しない。・ドラッグ＆ドロップの仕様が違う、ターミナルにファイルをドロップすると版によっては UNIX パス /mnt/auto/... ではなく media:/... の様に KDE 独自の URI になってしまう。面倒だ。Linux の TCO の問題って版が違うとことごとく動作が違っていて、そのつど検証に追われる事だと思う。しかも Windows と違って同一の仕様が 1 年も持たない。そう言えば何処かのゲーム機も Linux 載せるとか？もしかして載せた Linux 自身も日々進化する？冗談じゃない！検証の組み合わせ爆発だけは勘弁してくれ。
2006.05.15
コメント(0)
-
Buffalo IFC-ATS2P2 - コントローラーは VT6421L
scankeylx の試験機材として Buffalo IFC-ATS2P2 を買う。コントローラーは VIA VT6421L だった。serial/parallel ATA 両方のインターフェースを備えたコントローラーだ。詳細は追って調べようと思う。Google の検索結果によれば Vine Linux では Parallel ATA 側のドライブは認識しないそうだ。KNOPPIX で Serial ATA 接続のディスクを少し試した限りでは動作している。不良セクタを読み込んでもドライバが原因でハングアップ状態になる事もなかった。玄人志向の方で SAPARAID-PCIというのも売っている。基板形状が少し違うだけで、部品はほぼ共通に見える。こちらのほうがロープロファイルのパネルは付いているし RAID 対応だし使い勝手が良さそうな気もする。ちなみにメーカーは IFC-ATS2P2 は Linux 対応だとは言っていない。
2006.05.12
コメント(0)
-
Bluetooth ヘッドホン - 無線接続は使いやすいのか
Bluetooth ヘッドホンを使おうとしている人を見た。よく見ると色々と弄っているようである。電車の中で見たのだけど、乗り合わせている間 10 分間ずーと弄り続けていて、落ち着いて聞いている様子は無かった。ひざの上に再生機器があり、そのヘッドホン端子にマッチ箱ほどの大きさの無線装置を差し込み、耳に Bluetooth ヘッドホンを掛けていた。音が聞こえないらしく、掛けようとしていた。距離からすれば無線である必然性は無い。普通のヘッドホンであればオーディオケーブルを端子に直接差し込めば直ぐに音が聞こえる環境である。10 分の間音が聞けなかったのは、どうやら Bluetooth のペアリング手続きで失敗しているようであった。いゃ、もしかして、成功していたけど実験していたのか？何処か別のところにもう一つの Bluetooth 機器があったのであろうか？今でこそ普及していないから問題ではないけれど、誰もが Bluetooth 機器を持つような状況になった場合、少し混んだ電車の中で初めてのペアリングを敢行することは簡単ではないかもしれない。直接ケーブルで繋がっているという分かりやすさを無線機器で実現するのって難しいのかな。
2006.05.09
コメント(0)
-
scankeylx の最低動作環境 - MMX Pentium 233MHz, 192Mbyte
scankeylx の最低動作環境を調べてみた。次の版で出す予定のもので、現在公開中の r0512a ではない。次の版ではメモリ使用量を制限することにしている。MMX Pentium 233MHz, 192Mbyte で動作することが分かった。ただし、スキャン速度は最速で 1.3Mbyte/sec で非常に遅い。3Gbyte 程度なら 1 時間以内にスキャンを終了する。1.3Mbyte/sec しか速度が出ない理由はまだ分析できていない。1 バイトあたり 180 サイクルを費やすと言うことだ。CPU の処理能力で律速されている可能性を一番考えている。DMA を ON にしている状態で、ディスクのアクセスランプが途切れ途切れに点滅している。バッファも一杯まで読み溜めている。これで現在公開している版も含めて、だいたい妥当なシステムの要件が Celeron 500MHz, 256Mbyte だということを改めて確かめることが出来た。それにしても、かつて MMX Pentium 233MHz を早いと感じていた。でも今は遅いと感じる。すっかりプロセッサの進化に頼るプログラマになってしまったらしい。
2006.05.07
コメント(0)
-
実家のパソコンメンテナンス - My Document 移動
実家の父親が使っているパソコンのディスクが一杯になりかかっていたので My Document を移動した。実は父親のパソコンは 2 パーティションに切られていて D ドライブの方はまったく使っていなかった。使うことにした。作業自体は簡単で「マイ ドキュメント」を右クリックして「プロパティ(R)」を選択、「移動(M)...」ボタンを押すと移動先のフォルダを(作成して)選択出来る。大量にファイルが有る場合は数時間を要する作業である。スワップ(仮想メモリファイル)の移動、Local Sttings\Temp の掃除も行いだいぶ余裕が生まれた。2 パーティションに切るメリットはデータとアプリケーションを分離できることのはずだけど、素人は全くメリットを生かせない。メーカー製 PC で 2 パーティションに切られているのを見ると結局どうして欲しいのか理解に苦しむ。大きな画像を扱いだしたし、色々と重いアプリも使い出したのでメモリ増設も考える必要が出てきた。ちょっと買ってきてプレゼントと思ったけど Note PC 用は高いな...
2006.05.04
コメント(1)
-
動いているものはいじるな - 永遠のテーマなのかなぁ
ちょっと処理速度改善のためアルゴリズムを修正したら、プログラムが動かなくなった。ついつい手を出すとこうなっちゃうんだよな。製品開発だとすごく悔しい気持ちを抑えて、直ぐに修正を戻すのだけど、結構後々まで引っかかることが多い。結局処理速度が遅くて使い物になるギリギリだったりする。動く動かないはハッキリしているけど、早い遅いはいつももめる。
2006.04.26
コメント(0)
-
Windows Desktop Search - まだインデックス作成が終わらない
Windows Desktop Searchをインストールした。色々とファイルが増えてきて探すのが難儀だった。就寝中や会社に出ている間は休止状態にしているので、まだ 8 時間程度しか経過していない。しかし、インデックス作成は終わらない。総容量 300Gbyte なんで仕方が無い。Windows Desktop Search は Vista にも搭載される機能だと思う。Vista の 3D UI が重くて古いパソコン総入れ替えの様な事が言われているけど、意外と Desktop Search が一番重荷になる様な気がしてならない。ウイルススキャン、インデックス作成、ファイアーウォール、セキュリティホールを突く挙動不審なプログラムの監視、その他諸々のバックグラウンド処理にマルチプロセッサのパワーが使われ、1Gbyte 程の広大なメモリーも半分以上はバックグラウンドが占めてしまいそう。それより、Windows Desktop Search はメールにくっ付いてきたウイルスを積極的に食べてしまい、ウイルスバスターに怒られる現象を起こすようだ。バスターによってインデックスファイルのアクセスを拒否されてしまう。大丈夫なのかなぁ。
2006.04.18
コメント(0)
-
新しいパソコン - マニュアルは軽くなったけど
新しいパソコンを支給された。早速組み立てなんだけど、ちょっと戸惑った。年を取ったせいなのかな。PC は DELL OptiPlex GX620 で LCD モニタは自社製品(社名は コンピューター ディス○レイ でググって下さい)だった。DELL パソコンは以前のものに比べてさらに簡素な筐体になっていた。訳あって、PCI カードを増設することになったのだけど、側面パネルに何も手掛かりが無く寝かせた状態では開かない。結局説明された方法ではなく、立てた状態で少し傾けながら自重落下で開いた。PCI カードのロック機構も作りに余裕がありすぎるせいか、なかなか完全なロックの嵌め込みが出来ない。自社製 LCD モニタは、うーん、苦言しか出てこない。■9.6Kg重 あるモニターの取り出し方が分からない。■組み立て方の説明が無いので力の無い人とか、組み立てが苦手な人は難儀する。■説明書に書かれている付属品と内容物が一致していない。機種ごとに違うと書かれているけどその差異を見出すのが難しい。■機種ラベルを確認せよとあるけど、ふたの下に隠れて全く見えない。■PDF のマニュアルが有る、それを読むのにモニタがいる。缶詰の中に缶切りを入れてどうするのだ。マニュアルは薄くなったのだけど、それを見ながら最低限の作業が出来るかどうか確認していないように思う。箱を開けて机に置くまで 10 分、その間だけ読ませるものなのだから、分量は要らないはずだ。だけどとうしたらよいかは詳しく書いて欲しい。こんな事だと自社製品は売れなくなる。ちと悲しい。
2006.04.17
コメント(0)
-
HDD 壊れた - 壊れた HDD を探していると言ったら...
壊れた HDD を探していた。そうしたら、自分の所で手に入れることになった。もちろん、一部のセクタが読めない壊れ方でいいい感じに壊れている。まさに願いどおりだ。しかし、自分のところでは一番新しい SATA 250GByte が壊れた。使用開始から 1 年経っていない orz。もっと古い HDD も有るのに。データ・プログラム格納用の HDD ではなかったので、大事にならなかった。接触不良や電源不安定が原因ではなさそうだけど、コネクタと電源の状態を再確認する必要がありそうだ。参考までに scankeylx が不良セクタを発見した場合に記録する内容を下に示しておく。多分こんな記録は見ないだろうし、見たらかなり落胆するだろう。/media/sdb1/scankeylx: 2006/04/15 21:35:23: Started./dev/hda: Maxtor 7Y250P0 Y------E 251G bytes(233G bytes)/dev/hdc: _NEC DVD_RW ND-1300A 3G bytes(3G bytes)/dev/sda: ATA Maxtor 6L250S0 B--- 251G bytes(233G bytes) ←これが壊れた/dev/sdb: USB Flash Memory 1.04 255M bytes(244M bytes)/dev/sdc: BUFFALO USB Flash Disk 3.00 515M bytes(492M bytes)BufferSize: 44820kB.BufferAlign: 3kB.BufferAvailableSize: 44804kB.AlignedTopAddress: 0xB3EB0000./dev/sda: 2006/04/15 21:36:28: Begin scanning.-- 省略 --/dev/sda: 2006/04/15 21:57:55: 88076800/490234752 ( 17.97%) 15:1 42.8 Mb/s 48.8 Mb/s 50.0 Mb/s./dev/sda: Read error, slow down read speed, FilePointer=0xA7FE40000, LBA=88076800./dev/sda: Determine SkipFactor=5600./dev/sda: Read error, Input/output error, FilePointer=0xA80059000..0xA800591FF, LBA=88081096..88081096./dev/sda: Read error, Input/output error, FilePointer=0xA80059200..0xA800595FF, LBA=88081097..88081098./dev/sda: Read error, Input/output error, FilePointer=0xA80059600..0xA80059BFF, LBA=88081099..88081101.-- 省略 --/dev/sda: Read error, Input/output error, FilePointer=0xA80070C00..0xA800733FF, LBA=88081286..88081305./dev/sda: Recover normal read speed, FilePointer=0xA800FC000, LBA=88082400./dev/sda: 2006/04/15 22:01:18: 88082400/490234752 ( 17.97%) 15:1 11.4 kb/s 11.4 kb/s 30.3 Mb/s.さて、データ・プログラム用ディスクが壊れない前にバックアップを始めるとしますか。
2006.04.15
コメント(0)
-
knoppix 5.0 - やはり手順書は変更、改善も見られる
knoppix 5.0 を動かし始めた。/mnt/auto が廃止された。scankeylx の説明に変更が必要になったこと、ソフトも若干の修正が必要になったことが分かった。下は /mnt 以下の ls -la の結果だ。knoppix@ttyp0[~]$ cd /mntknoppix@ttyp0[mnt]$ ls -la合計 2drwxr-xr-x 2 root root 1024 2006-04-15 00:17 .drwxr-xr-x 13 root root 1024 2006-04-15 09:10 ..lrwxrwxrwx 1 root root 10 2006-04-15 00:11 hdc -> /media/hdclrwxrwxrwx 1 root root 11 2006-04-15 00:11 hde1 -> /media/hde1lrwxrwxrwx 1 root root 11 2006-04-15 00:11 hde2 -> /media/hde2lrwxrwxrwx 1 root root 11 2006-04-15 00:11 hdg1 -> /media/hdg1lrwxrwxrwx 1 root root 10 2006-04-15 00:11 sda -> /media/sdalrwxrwxrwx 1 root root 11 2006-04-15 00:14 sda1 -> /media/sda1lrwxrwxrwx 1 root root 10 2006-04-15 00:14 sdb -> /media/sdblrwxrwxrwx 1 root root 11 2006-04-15 00:11 sdb1 -> /media/sdb1lrwxrwxrwx 1 root root 10 2006-04-15 00:14 sdc -> /media/sdclrwxrwxrwx 1 root root 11 2006-04-15 00:17 sdc1 -> /media/sdc1lrwxrwxrwx 1 root root 10 2006-04-15 00:17 sdd -> /media/sddknoppix@ttyp0[mnt]$ cd auto-bash: cd: auto: そのようなファイルやディレクトリはありませんknoppix@ttyp0[mnt]$他にもいくつか変化が見つかった。今分かったことをまとめておく。/mnt/auto が廃止された。/mnt/auto を使ったコマンド入力手順はもはや使えない。/mnt は /media に対するシンボリックリンクで存続している。GUI (konqueror) 経由で使う方法も変更が必要、シェルスクリプトをクリック/ダブルクリックして起動することは出来なくなった(そこまでセキュリティに気を使うのか？)。 /dev/ub* が廃止されて /dev/sd* に統一されたようだ(歓迎したい)。/dev/ub* 扱いだった USB ストレージが /dev/sd* 扱いになって SCSI コマンドを受け付けるようになった(歓迎したい)。一部 GUI 操作だけだと確実に認識出来ないデバイスがあったが、解消された様だ(歓迎したい)。konqueror で media:/ を開いた場合、デバイスが全く表示されない場合があるが、再表示アイコンで復旧する。konqueror が USB ストレージをボリュームラベルで表示する様になった(分かりやすなったので歓迎したい)konsole の文字が大きくなった。解像度によっては画面からはみ出ないかチェックが必要全体的に見れは改善点が多いように思う。もちろん、操作体系が変更されたのは不満だけど、USB ストレージを /dev/sd* で統一的に扱い、安定して認識できるようになったのはかなり前進したと思う。もう少し USB ストレージの種類を増やしてみて、認識の安定性を確認する必要性は有りそうだ。秋葉原でジャンク USB ストレージ探しかな。
2006.04.14
コメント(0)
-
KNOPPIX 5.0 - また動作確認か
KNOPPIX 5.0 が出たと聞く、scankeylx の動作確認の必要性が出てきた。取りあえずダウンロードを始めた。「udev採用でマウントポイントが /mnt -> /media へ変更 」とある。どうやら手順を見直す必要がありそうだ。杞憂であって欲しい。シンボリックリンクなどで互換性を残していることを期待したい。うーん、Linux にかかわっている人たちは(自分もそうだけど)こういう変更が、GNU ツール以外の様々なアプリケーションを育てない要因になっているのに気づかないのかなぁ。とにかく一度決めた OS とアプリケーションあるいはユーザーの取り決め(インターフェース)は変更しないと言う基本的な約束を忘れているような気がする。変更があるたびに、動作確認、手順変更、ダメだった場合はソフト変更にまで及び、新規開発の時間を奪っていくし、何の生産性もない改修作業に追われる。しかも、変更した側からはどうすれば良いか何も示さないことも多い。Linux の場合さらに状況が悪いのは、インターフェースが変更になりコマンド操作に行き詰った場合、真っ黒いターミナル画面から「じゃ、これからどうすればよいのか？」というヒントを自発的に収集・解決するのも絶望的な努力が必要なことだ。そりゃ、Linux は好きに出来る OS かもしれないけど、誰かの好みに振り回されるしかない立場の周辺の人々はとても困る。こういうことがある度に「だから Linux は嫌いなんだ」と思う。えっ？使わなきゃ良いじゃないかって？そりゃそうなんだけど、逆に問いたい「使って欲しくないの？」
2006.04.13
コメント(0)
-
辞書作り - scankeylx で検索できる範囲を拡大する
scankeylx で検索できるのはいまのところ Windows, Office, そして Visual Studio のキーだ。もう少し範囲を広げたいのだけど、そうすると沢山の不要情報を拾ってしまう。レジストリに Licence, Serial と言う名前を付けて保存された値を対象に検索範囲の拡大を考えている。しかし、License, Serial とも普通の文書やソースコードの中に大量に現れる単語だ。そのまま拾ってどうなるか試した。大量の普通の文書、ソースコード、Serial Port 関連の設定情報が混じってきた。とても役立つ情報ではなくなった。そこで、不要情報だという判断をするための辞書を作り始めている。しかし、単調な作業ゆえ飽きてしまう。自動で作れないのかと言う疑問もあるだろうけど、不要情報からそのまま辞書を作ってしまうと、色々と引っかかる単語が混じってくる。手作業で調整していくしかない。また、辞書もなるべく高速に 2000 パターン程度に一致するかどうか調べる必要がある。こちらのアルゴリズムは大体目処は立った。辞書を作っては調整の繰り返して、飽きが来るがねばるしかない。たぶん後で要領のいい人が、あっけなく自動で辞書を作り出す方法を考えるのだろうけど。
2006.04.08
コメント(0)
-
壊れたディスクのはずだけどエラーなし - テスト機材を探す
scankeylx をテストするのに壊れたハードディスクを使う。じつは、開発初期の頃は適当に壊れかかったディスクがあって、読み取りエラーを程よくテストできていた。だけど、壊れていることに間違いない。大体エラー回避処理が出来上がった頃に本当に壊れた。もう、認識すらしない。2, 3 ヶ月ほど持ったので長いほうだと思う。いま 2 代目を探している。ドライバを改造してテストする方法もありそうだが、そこまでは面倒だ。今日は 1 台壊れた(カッコン、カッコン)という事でという事で試してみたが、何事も無く全セクタ読み取り成功してしまった。多分壊れかかっているのだろうけど、程よくではなさそうだ。
2006.04.07
コメント(0)
-
fstat64 - Kylix3 の Libc.pas にバグがあるので回避
Kylix3 の Libc.pas にバグが見つかる。下のソースにもあるように、Libc.pas の中で fstat64 関数を 直接 __fxstat64 にマップしている。 __fxstat64 は引数が一つ多いので、Libc.pas の fstat64 を使うと(引数の値が無茶苦茶なので)エラーになる。回避策として、次のような自前関数を用意してしのぐことにする。一つ多い引数を補うラッパである。Fstat64B としたのは名前がぶつからないようにするためだ。xxx.FStat64 の様に常にモジュール名を付けていれば、同名定義でも構わないはず。 (* fstat64 関数 - 自前実装版 @arg fd fstat しようとする File Descriptor @arg st64 結果格納先の構造体変数 @note kylix3 の fstat64 の実装に誤りがあるので自前で実装する。 kylix3 の fstat64 を直接 __fxstat64 にマップしていて動作しない。*)function FStat64B(fd:integer;var st64:TStatBuf64):integer;begin Result:=Libc.__fxstat64(Libc._STAT_VER,fd,st64);end;ソースがあるのは有りがたいのだけど、バグ取り人柱だけは勘弁してほしい。
2006.04.06
コメント(0)
-
PointSec - スキャンディスクもデフラグもしたぞ、なのに
PointSec をインストールしろとのお達しが会社であった。要するに丸ごとHDD暗号化ソフトだ。インストール前にスキャンディスクとデフラグをしておく手順になっている。あぁ、1日掛けてやったさ！だけど何だぁ。インストールステップが進んで、ダイアログが現れ「フラグメントが多すぎ、駄目ジャン」(意訳)となって先に進まない(いゃ、まぁその前の社内の情報部門が作った導入ツールも腐っていて怒り心頭なのだが)。ググって調べたがこんな問題があると FAQ に書いていない。社内で出回っている手順書も色々と「他の問題」の回避方法が多く書かれている。Windows のデフラグツールは完璧にデフラグできない場合があるのは知っている。しかも、デフラグしたとはいえない状態でデフラグツールが完了した(でも 15% の空きは有ったし、22% 空けてもデフラグは進まない)。個人的な感想ではあるけど PointSec って、製品として如何かと思うレベルで販売されている気がする。少なくとも Windows 標準ツールで何とかできない問題があるなら、解決するソフトをバンドルするべきだし、それが無理なら商品ではないと思う。まぁ、自分の scankeylx もかなりダメダメなんだけどね。だから(いい訳だけど)タダでやるしかない。やれやれ、明日もソフト削ってデフラグだ。
2006.04.04
コメント(0)
-
USB ストレージから起動しない - scankeylx 動作不具合対策
scankeylx に USB ストレージから起動しないと言う問題点が見つかったので、暫定対策を紹介します。以前、ご利用していただいた方から報告があったのですが、自分のところでも再現を確認しました。御不便をかけて申し訳ないです。手っ取り早く使いたいの手順 4 でコマンド for d in ... done を入力しても起動しない問題が見つかりました。特徴として、コマンドを入力した後、次のようなメッセージが表示されます。bash: /mnt/auto/uba1/start_scankey: そのようなファイルやディレクトリはありません。もう一度、for d in ... done までのコマンドを実行してください。再入力するのは面倒なので、コマンド履歴を [↑] キーで呼び出して、内容を再確認して [Enter] キーを押してください。恐らく確実に起動できるコマンド入力があると思います。また、問題の根本は Linux の automount が正常に動作していないためです。Boot セクタを USB ストレージから予め読み出して、慣らしておかないと(と言う言い方しかできない)、正しく認識できず、記録したファイルにアクセスできない問題があるようです。「慣らし」も 100% 確実な方法ではないので対策にも限界があると考えています。
2006.04.02
コメント(0)
-
Linux usbdevfs - 仕事のことだけどメモ書き
仕事で Linux 上で USB デバイスを操作するプログラムを書いている。libusbとか便利なライブラリがあるのは十分承知しているのだけど、商用だと libusb は使えない。なぜなら、(1) LGPL である。 まぁ、LGPL だから内部に手を出さなければ大丈夫なはず、しかし。(2) Multi Thread(MT) Safe ではない。結局 MT Safe を必要とするアプリケーションを作ろうとすると libusb 使い物にならない。内部に手を出す必要が出てくる。実は libusb も LGPL にするため、わざわざ /usr/include/linux/usbdevice_fs.h (GPL) を使わないように同様のヘッダを独自に持っている。GPL の理想と現実の乖離を垣間見る。さて、libusb に対する不満はここまでにしておいて、取りあえず気づいたことをメモしておく、ioctl() で Control Request (USBDEVFS_CONTROL) を発行すると実際の転送長だけ、data に指定した領域にコピーされるのではなく、常に wLength (大抵はバッファ最大長) だけコピーされ、ゴミデーターも Kernel はアプリケーションに投げてくる。注意していれば良いがかなり迷惑な仕様だ。って、セキュリティ平気なのか？ゴミ漁りができるのは問題だぞ。usbdevfs 上のデバイスファイル /proc/bus/usb/#port/#dev を close() すると、なぜか SetInterface が行われる(まだ Kernel 内の問題かどうかは未確認)。もう使うのを止めるのに初期化シーケンスが走るのはどうかしていると思う。どうやらこのせいでデバイスが混乱してしまい、応答がおかしくなることが有るようだ。取りあえず、デバイスの初期化処理で SetConfiguration (USBDEVFS_SETCONFIGURATION) をすると問題なく動作する様になった(Set Configuration をサボる理由も無いのだけど、OS によっては全て済んでしまった事になっている)。時間が有れば詳細に理由を調べる必要がある。なんだ、今度は Kernel に対する不満だなぁ。Linux 家電が注目されているけど大丈夫かなぁ。
2006.03.27
コメント(0)
-
ソースを振り返って 浦島太郎
scankeylx のソースを修正開始した。手始めに起動スクリプトを修正して、出力ターミナルの履歴行数制限を行う。よく言われることだけど、自分の書いたソースコードをなぜか理解できない。色々とコメントを入れているところは何とかなるけど、ついついサボった所は何でだろうの連続だ。個人でチョコチョコ開発しているので、ソフトの動作に全く変更が無い箇所でも気軽に振り返り、コメントを入れていくことが出来る。時に自問自答が、潜在的なバグを見つけることになる。商用の製品開発では管理規約もあって、動いているものに手を付けることは中々出来ない。コメントすら入れなおすことはできない。ただ、こんな感じでゴミみたいになってしまったソースを商用の製品開発で良く見る(自分の勤め先だけかな)。そうか、ちょっと昔の自分と話せる仕掛けがあればよいのか。と言うのは無理だけと、最近は未来の自分に向かって話しかけるような少し奇妙なコメントを入れるようになった。
2006.03.26
コメント(0)
-
mmap を使ったメモリ使用量と /ramdisk Free 変化調査
前回は予備調査だった。すこし本腰を入れて調査した結果がまとまったのでまとめておく。試験環境として次のように KNOPPIX 4.02 を起動した。 メモリ量256MByteboot:knoppix 3 noswap追加デーモンsshd, smbd, nmbdsshd, smbd, nmbd には Windows 環境から遠隔操作できるようにするために追加したデーモンだ。runlevel 3 なので X Server は起動していない状態となる。このような環境で指定したバイト数(len)だけ、 ptr = mmap(NULL, len, PROT_READ | PROT_WRITE, MAP_PRIVATE | MAP_ANONYMOUS, -1, 0); の様にメモリ確保して random byte でptr が指している領域を埋めるプロセスを起動してみた。mmap し random byte で埋めた後は、キー入力待ちになり、mmap を維持するようになっている。結果の結論は次のとおりだ。mmap で主記憶を使用した場合(当然map領域に書き込む)、使用量の大小に関係なく、/ramdisk の free は変化しない。/ramdisk の free は /ramdisk に書き込んで占有している量のみ反映する。/ramdisk に書き込んで主記憶の使用量が限界に達したときは、(特定できない)プロセスを signal#9 で終了し、空きメモリを増やした上で、 /ramdisk の書き込みを優先して完了させる。このとき /ramdisk に書き込んでいるプロセスに対し、ENOSPC (空きがないというエラーコード)は返さない。つまり、/ramdisk に書き込めるつもりで書き込んだら、知らないプロセスが死んでしまうことがある。書き込んだ側も、何も通知されないし、死んだプロセスも #9 で瞬殺なので苦しまない。とてもハッピーだ(え？)。scankeylx に必要な対策としては、検索結果出力ターミナルで使う /ramdisk 使用量を制限したり、監視して緊急事態には何らかの対処をする必要があることが分かった。以下は詳細だ。mmap メモリ使用量と /ramdisk Free 変化の観察mmap メモリ使用量を 1M, 2M, 4M, ... 187M byte と変化させた場合の、free コマンドの Used 項目変化、df /ramdisk の Used, Free 項目変化を観察してみた。187Mbyte で打ち切ってあるのは、187Mbyte の少し手前で主記憶の限界だと思われる挙動を観測したためである。結論として、free の Used 項目は mmap 量を反映して変化している。少し少なめなのは観測用コマンドやバックグラウンドプロセスの状況に拠るものと思われる。少ないからといって現象に大きな影響を与えるものではないと考えている。対して df /ramdisk の結果は全く変化が無く、主記憶の使用状況によって動的に変化しているとはいえない。mmap メモリ量bytes$ freeUsed 項目変化$ df /ramdiskUsed 項目変化$ df /ramdiskFree 項目変化備考1M111600-2M19840 0-4M409200-8M818400-16M1636800-32M3273600-64M6559600-128M13119200-182M18382400-183M18010400それなりに使える限界184M18368000極端に遅くなる185M---暫くすると Kill186M---mmap の後 random fill で kill187M---mmap の後 random fill で killmmap で 183Mbyte 使用時の /ramdisk 書き込み可能量mmap で 183Mbyte 使用した状態で /ramdisk に書き込むことをしてみた。183Mbyte を選んだ理由は主記憶の限界に近く、かつギリギリで様々な操作が可能な状態と考えたためである。/ramdisk に書き込む操作は rm -f /tmp/a.bin; dd if=/dev/urandom of=/tmp/a.bin bs=262144 count=16 の様にしている。/tmp に対する書き込みだが KNOPPIX では実質、/ramdisk の書き込みに相当する。書き込み量に相応して、df コマンドで観測した Used, Free 量が変化している。どれも Used=-Free なので、書き込み分しか反映していないと考えられる。4.5Mbyte 以上の書き込みをした後は、コマンドを投入しようとしたりする時点で、何かしらのプロセス(多くの場合は mmap でメモリを占めているプロセスだが、たまに別のプロセスもある)が強制終了してしまった。特に 6Mbyte 以上の書き込みでは、書き込み中にプロセスが強制終了してしまう(書き込みプロセス dd は生存している)。書き込み自体は正常に行われていて、書き込み内容が /ramdisk に維持されている。/ramdisk 書き込みみ量 Bytes書き込めた長さ Bytes$ df /ramdisk Used 変化$ df /ramdisk Free 変化強制終了発生状況0.5M0.5M520-520発生なし2M2M2056-2056発生なし4M4M4104-4104発生なし4.5M4.5M4620-4620何らかの別の操作時点で Kill 発生5M5M5132-5132何らかの別の操作時点で Kill 発生5.5M5.5M5644-5644何らかの別の操作時点で Kill 発生6M6M6156-6156書き込みで Kill 発生
2006.03.21
コメント(0)
-
mmap でメモリを占有した場合の /ramdisk 挙動調査開始
KNOPPIX の調査を継続予備調査の段階だけど、ストレスを掛ける方法として mmap() でメモリを確保して、そこにランダム値を敷きつめる。すなわち、実際に主記憶を割り当てて使用状態にする。ストレス状態で /ramdisk の free 変化を見てみる。取りあえず分かったことは主記憶ぎりぎりまで占有し、linux(KNOPPIX) が瀕死の状態になっても、/ramdisk の free 値は全く減らない。たとえば、noswap, 主記憶 256Mbyte に対して mmap() で確保し 180Mbyte を割り当てた状態(ランダム値で敷きつめた状態)でも、df で調べると /ramdisk もまた 180Mbyte ほど使用可能に見える。合計で 360Mbyte を使えることになっている。しかし、有り得ない事態だ。OS が占有しているメモリが 0 であっても合計は 256Mbyte 以下のはずだ。では /ramdisk に書き込むとどうなるか、disk full ではなく、適当にプロセスを強制終了させて、あくまでファイル書き込みのほうを成功させるように振舞うようだ。もう少し、事態を整理する必要がありそうだ。つくづく Linux は変な OS だとおもう。
2006.03.15
コメント(0)
-
少し頭を冷やして状況調査 - konsole は出力の 6 倍メモリを食う
scankeylx では konsole の履歴バッファ(逆スクロールバッファ)を無制限にして、スキャン結果を表示しています。果たして妥当なのかどうか？どうも妥当とは言えなさそうな結果が出ています。状況を単純化して把握するため、KNOPPIX を立ち上げ、次のような 1 行 64 文字の出力を konsole 内で行って調査することにしました。履歴は無制限に設定します。指定した行数を出力する前と後で df で /ramdisk の状況を観測し差分を観察してみます。00000000:9ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF00000001:9ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF...条件を振ってみる必要は有りますが、複数行出力するとおおよそ、konsole は出力文字数の 6.1 倍の ramdisk (普通の Linux なら /tmp)を消費し、履歴を維持しているようです。ramdisk の free の変化と used の変化か一致するため、プロセスのメモリには履歴が維持されていない様子です。実は同時に konsole プロセスも ps で観測しています。しかし、SZ に目だった変化がありません。下の表の "64 Chars Lines" が、1 行 64 文字の行を出力した行数です。"Total Chars (w/o newline)" は 64 * "64 Chars Lines" の値です。改行を除いた総出力文字数に相当します。"Used Before (KB)", "Used After (KB)", "Used Delta (KB)" は df で見た /ramdisk の Used 項目の様子、Before が出力前、After が出力終了後、Delta が差分です。"Used Delta per (Total Chars)" は "Used Delta (KB)" に 1024 を掛けてバイト数に換算し、"Total Chars (w/o newline)" で割った値です。この値が出力した文字数に対し konsole が消費した /ramdisk 量の比です。"Free Before (KB) Free", "After (KB)", "Free Delta (KB)" は df で見た /ramdisk の Free 項目の様子、Before, After, Delta は Used 同様です。64 CharsLinesTotal Chars(w/o newline)UsedBefore (KB)UsedAfter (KB)UsedDelta (KB)Used Deltaper (Total Chars)FreeBefore (KB)FreeAfter (KB)FreeDelta (KB)16384104857674961375262566.10938187776181520-6256327682097152749619980124846.0957187776175292-12484655364194304749632448249526.0918187776162824-249521310728388608749657368498726.08789187776137904-49872262144167772167496107208997126.0859418777688064-99712結果からすると、スキャンしたログ結果が 10MByte 程度になると、60Mbyte ほどのメモリを消費することになります。swap 無しで 256Mbyte 程度の主記憶で動作する KNOPPIX にとって無視できない値になると結論できます。うーむ、konsole の履歴バッファは結構メモリ食いだというショックな事実、淡々と対応するしかないか。
2006.03.12
コメント(1)
-
エロサイト Track Back を消して思うこと
うーん、大分熱も気にならない程度になった。しかし、風邪の抵抗は続く、喉を徹底的に攻めて再興を図るか、脱出を試みているようだ。体力の回復を見てそろそろ scankeylx のサポート情報も追加し始めないといけない。洗礼エロサイト Track Back が問題になっていると聞いていたので分かっていた。けど、いざ自分のサイトがその対象になると色々と考えさせられる。自分のページなのだから、ルールは自分で決めればよく、Track Back 削除の判断も俺ルールでよいはずだ。しかし、一応曲がりなりにも他人の書き込み(多分、プログラムによる自動処理で書き込んでいると思う)、削除は他人の言論を妨げることになる。うーん、憲法に触れる問題なのか？悩んでも仕方が無い(悩むほど判断に苦しむリンクではなかった)のでサクッと消してしまった。話は飛んで絡んで P2P - 山田オルタナティブむかし、会社の同僚と P2P システムの構築をどうしようかと、議論したことがある。Winny が広がり始めた頃だった。最大の課題はお互いのノードがどこにあるか「人間が介在してソフトに教えることなく」、「特定のサーバーの存在なしに」知り合える方法は無いのだろうかということだった。「IP アドレスの適当打ち込み」、「アドレス帖をあさってとにかくメール」など色々と出たが決定的な方法がなかった。「山田オルタナティブ」もそうだが、特定の掲示板(サーバー)を連絡用の情報蓄積装置にしている。しばらくたつと掲示板の管理者あるいは、その ISP がアドレスを閉鎖して沈静化してしまう。P2P 2.0 あるいは... しかし、Track Back を削除していて思った。P2P 間のリンク確立に blog のコメントや Track Back を使ったらどうなるのだろうか？ P2P ソフトが自ら google で 「花子 blog」 、「太郎 blog」 の様に特定キーワードで blog を漁ったり、ポータルサイトの blog/RSS リーダーページから、人気のありそうなページを収集した後、その blog のコメントや Track Back に P2P システムがお互いに連絡を取るための情報を書き込んで/読み出してしまうのだ。こうする事で「特定の」掲示板、「特定の」サーバーという条件を外せる。もちろん、キーワードとか、人気サイトとか本質的には「特定条件」がある。しかし、その条件に合致する対象は常に(かつ緩やかに)変化する。掲示板やアドレス閉鎖による沈静化策を回避し続けることができる。blog が炎上してしまうかもしれないので、適当な分散対策を盛り込む必要はあると思う。また、blog に謎の書き込みが残るので非常に気味は悪い。何れ高度な回避策も出てくるだろうけど、今までの P2P フィルターに比べかなり高度な処理が必要になるだろう。さて誰か作らないかなどうなるか分からないけど、今まで見てきたこととは明らかに違う何かが起きそうだ。
2006.03.10
コメント(3)
-
scankeylx が検索途中で CD/DVD-ROM が光りっぱなし
メモリ不足 (tmpfsのメモリ管理異常) 対策scankeylx がもし検索途中で CD/DVD-ROM が光りっぱなしで、検索が進まなくなってしまったら、scankeylx の結果出力画面「Results - scankeylx - Konsole」の「設定」→「履歴」を選択して、「履歴の設定」ウインドウが現れるので、行数を 3000 にして、[OK] を押して下さい(途方も無い数でなければ 2000 でも 4000 でも構いません)。とりあえず、これでメモリを圧迫することはなくなります。遡れる結果が少なくなっても、USB メモリには全て保存されるので、後で見返してみることができます。
2006.02.26
コメント(0)
全883件 (883件中 851-883件目)
-
-
- ブログ更新しました♪
- ６月２日 記事更新致しました。
- (2024-06-02 20:30:28)
-
-
-
- Amazonマケプレ
- Best Chopping Board in the UK: Dee…
- (2024-05-30 04:55:20)
-
-
-
- 楽天ラッキーくじ
- 楽天ラッキーくじ更新情報（2024/6/1…
- (2024-06-01 18:20:10)
-
