2008年12月31日水曜日

Unix と C は究極のコンピュータウイルスである。

悪いデザインをとること。

非力でダメなマシンでも十分に動く余地を与えること。

年末に停電する

なぜに停電するのか。

しかも誰もいない年末に。

工場地帯にサーバを置くなということだろうか。最近、停電情報は、事前に告知されなくなったそうである。広範囲に、狭い地域の停電を告知すると犯罪を誘発する恐れがあるから? だそうだ。

おかしいだろ。

停電=防犯能力の低下 ということは、電力インフラを集中的に配置することは、ぜい弱性そのものじゃないか。 そんな危険な国家運営があっていいのか。 コジェネと太陽電池パネルの更なる普及を進めるべきだ(なんか違う)

ま、客先のダメ受電装置が壊れ掛けているのは間違いないので、そっちだと思う。
ホントだめだめです。

2008年12月29日月曜日

年末に壊れる

客先のExpress5800/110Gc がおかしくなった。

寒さによって壊れたのだろうか?

どうも違うらしい。 ひどい寒さはHDDの回転を止めてしまうし、正常な動作を保証するのは室温5度以上だ。 寒くなり始めた時点で壊れたのだろうか・・・・・・。 まあ、原因はともあれ来年考えることにしよう。

2008年12月25日木曜日

Youtubeは、ダウンロードである。

flashvideoのストリームは、技術的にファイルに還元しうるわけで。

現時点でflvをダウンロードしたり、rmをダウンロードできたりと。

悪徳の町に天罰を・・・じゃなくて、ダウンロードを行ったファイルを塩の柱にしてしまうような技術があるのだろうか。 


インターネットで配布されている形態のあらゆる動画が、メタな動画ファイルに変わってしまう可能性は、どこにでもありうることだ。 これを避けることは、手で掬った水をこぼさないようにする努力に似る。

ストリーミングとダウンロードの違いについて

簡単に言うと・・・

・テレビ放送(録画しない)・・・は、ストリーム
・テレビ放送(録画してみる)・・・は、ダウンロード。

本質的に、受け取る側の問題じゃないか?

リプレイ攻撃にも弱い。(地デジ放送で応用例が)

ましてや鍵交換方式なんてダメ(CASカード)。 やっぱり出鱈目じゃないかと、わが心の師匠が言いそうな話。

いかにも、このあたりの技術音痴を騙すシステム作りですな~。いやはや

2008年12月22日月曜日

ストリーミングサーバって?

よくわからない代物を引き受けることになる。
flvファイルを公開すれば、ストリーミングサーバになるのだろうか。

ffserver なるものを用意して構築作業をやってみるのだ。

光ファイバー



1000BASE-SX の試験

2008年12月20日土曜日

古いVAIO=憂鬱の塊

なぜ、VAIOを仕事に使うんだろう?

新品を3年も使うとすでに陳腐化している。 何故かと言えば、価格設定と盛り込まれた性能バランスの悪さ。 加えてごてごてしたいらない独自アプリケーションの山。 国産のパソコンはどこかしらこういうものをすべて持ち合わせていて、日電や富士通の個人向けは目も当てられない。あんな甘ったるいクリームを塗りたくったような機材には、バグならぬ無駄なエネルギーを浪費するCPU時間蝿がたかってしまうのだ。やはりましなのは東芝くらいなもので、あとは似たり寄ったりである。 国産でもビジネス用PCと銘打ってあれば、仕事で3年使ってもまあ我慢もできる程度にしか劣化しない気がする。 ところが、素人さん向けの機材はどう見てもデザイン料と派手なAV機能に埋もれて実質的なソフトウェア利用環境としてのプラットフォーム機能は、きわめて貧弱なものが売られていたことは否めない。 

もちろんこれから売られる機材がそれらの反省に基づいて、骨太で質実剛健な機材が売られるという保証は全くない。 怪しい品質であっても、量販店とメーカーは売れればいいのである。 そんな家電品に成り下がってしまったパソコンに、明日を生き残る可能性は極めて少ないと予言しておこう。

今日見たのは、VAIOの幽霊屋敷ともいった方がいいような零細企業。どこもかしこもVAIOだが、どれもほとんど5年超の機材。今日見たのも少しましだったが、まっ更な機材にXP/SP1aが稼働していて、これは相当昔の機材である。そんな老骨をいつまでも使うなと思うのだ。おかげで、SP3を入れるのに1時間弱、他合わせて3時間弱無駄な時間を使わされる羽目に陥った。
おまけにくだらない機能(いまどきチューチューまうすだぁ?)やら、ド派手な壁紙だの、”よい仕事の魂は単純な環境にのみ宿る”という私の信条からすれば、二度と触りたくない機材、本当に利用者の仕事に対するセンスが疑われる。

こんなイライラにはさして効く薬がない。 まあソニーを信奉する人のために多少慰めになる話をするなら、私も自宅にもさる筋からVAIOを引き取っている。 自分の仕事に使えるようにするため、いろいろ常駐モノを引っ剥がすとようやく実用に耐えるレベルとなるのだが、これもシンプルな環境にこそ仕事に使えるものが残るという哲学に基づいた、”削り込み”を行った結果である。ソニーの機材が悪いのではない。 売らんかなの根性でゴテゴテと飾り付けることが悪いのだ。

 最近、私自身がダイエットを始めたことにも通ずるのだが、自らの生活(特に食生活)も必要としないものを取り込むことをやめたことで、自分に必要な本当のカロリー量に見合った食事ができるようになった来た気がする。 不必要なエネルギー、食料の消化につかう別のエネルギーが思考に振り向けられるようになるのだ。 古代の思想家が断食を繰り返した事実は、まさにこの無駄を省く生き方、すべてに当てはまるものである。

2008年12月18日木曜日

Qosmioのノートパソコン

今、作業中のパソコンは、メモリが少ない~



挿そう!挿そう! 1GB~
挿そう!挿そう! 大容量メモリ~
あなたもあなたもあなたもあなたも~
みんなで挿そう! 大容量メモリ~

2008年12月15日月曜日

2008年12月14日日曜日

オタク度

From Gigazine:

Geek Test


I am 42% Geek.
Geek? Yes, but at least I got social skills.
You probably work in computers, or a history deptartment at a college. You never really fit in with the "normal" crowd. But you have friends, and this is a good thing.



日本では:

PC度チェック

私は日本のPC度チェックでは229%汚染されているとのことです。

2008年12月13日土曜日

古いといえば

先日の投稿で出した エプソン PC386を未だに持ってるお客さん。 

以前、クロメムコも持っていました。

20年の昔に、クロメムコ(クロメンコ、クロメンコって黒いメンコかと思って聞きなおした?)は、MC68000とZ80 (数字の前に英文字を入れるCPUは時代を感じますな。)を同じアーキテクチャに押し込めた、まさにフタナリマシンでして、S-100バスを搭載しています。

Z80では、8080系 CP/Mが動き、 68000でも、CP/Mがありましたな。

あの当時からお仕事されてきた皆さんにはおなじみの機材ネタを集めたサイトがあります。
こちらから過去のマイコン世代を懐かしんでください。

2008年12月11日木曜日

古いパソコン




客先にてみかける。

古すぎる。 DOSが動く。 
ナツカシすぐる。

2008年12月10日水曜日

光ファイバーが入っているマンションでも

知り合いがインターネットつなぎたいと言った。

マンションには光ファイバーから配線してて、壁まで来ていると言った。

『じゃあ、簡単じゃないか。 Webで問い合わせてみろ』とWebで開設の申し込みして見たら・・・・・・

なんとNTT東からの返事は「その住所には回線が来てません」とのこと。

大家(大X建託)に聞いてみたら、「全戸に入れてなかった」と告白。

『ガガーソ』(この衝撃を食らったのは僕じゃないゾよ)




ということで、首尾よくつなげてもらえるといいねぇ。 んで、何が必要かというと・・・・・あなたには、これだな。

ルータ

ということで、ここから買って行って暮れたら設定してあげますかね~。

モニター故障!

先月買った22インチWXGA+ モニターが、一昨日なにやら燻ったりした後
デジタル入力を受け付けなくなってしまった・・・・・・。





辛うじてアナログ入力は動くが、なんだかほかも壊れたらしく色がおかしい。
1日耐えたがちゃんとした色がわからないと、モニターの信号変換のアンプでも壊れてるためだろうか画面上半分と下半分で若干色味が違って燻った色だし、オレンジ色と赤色の境が怪しくて、一太郎のアイコンは良いけど、Bloggerのアイコンが
何気に茶色いとか、なんだか気色悪い。

仕方ないので、少し安くて新しいモニターを昨日注文して、今日届いた(はや~!)





どう考えても初期不良。 もう、なんだか仕事に差し支えるから新しいモニターの予備はほしい。今までの予備はもう薄暗くってバックライト焼けまくりのXGA。バックライト交換が仮に
出来たとしても馬鹿らしいくらい狭い。 19インチの1280x1024が狭く感じるが、隣にも
かなり古いコリアン19インチがあってこいつがノイズ立てるのでイラつく。

というわけで、BenQになってしまいましたとさ(悲)

いまだに三菱はくそ高いし、やっぱりプロ向け使いたいけど、もっと儲かってからかな。

2008年12月5日金曜日

壊れたportsの適当な直し方

portsは、慣れないうちにリポジトリ操作のミス、更新手順の不備、手順前後、勝手な削除、継ぎ足しなどで、徐々に壊れて更新がままなくなることがある。 

一番多いのは、依存関係に矛盾が生じる削除。 pkgdb -F で、似たようなパッケージがあればそれに依存関係を接続しなおす作業が必要になる。

たとえば、あるパッケージが なんちゃらのm4が必要だとしよう。 でもこのm4は、自分の使いたいm4と違って文法エラーが出まくって、みなみ最近…イライラする(笑)・・・ というような時には、間違ってなんちゃらのm4をぶっ飛ばしてしまうかもしれない(訳注:pkg_deinstall なんちゃらのm4) ので、こういう時には、別のm4で接ぎ穂を足されなくてはならない。そうでもしないと単にportsdbを眺めるだけのportsversionすら追跡できない。

autotool辺りはこのバージョン違いが激しく存在し、autoconf-2.13から、autoconf-2.62までのすべてのバージョンを持っているシステムというのも、現時点では存在する可能性がある。
そして、それぞれのバージョンコンパチビリティが低いので、相互補完できず、こいつのwrapperがキチンと入るまで相当に混乱していた。  3年位前まではそんなこんなで、荒馬のportsを乗りこなすのには、狭いパッケージ選択を余儀なくされていたが、wrapperの出現で管理はしやすくなったといえよう。 だが、未だにwrapperもなく、バージョンコンパチの無いシステムがおおい。

あと、ソースレベルから駄目なものの例として、OpenLDAPbdbがあるだろうか。 bdbはバージョン4の中ならば、それほど違いが無いのだが、やはりデータベースのフォーマットが異なってるために、入れ替えれば、再構築がつき物である。 もちろん bdbは、単なるdbmに過ぎないから、物理的にむき出しになったファイルを管理する傾向が強く、やはり何かの管理・操作ミスで破壊されやすいことが良く知られているためか、練れたアプリケーション側には修復ツールが必ず付いてきて、データベースを自動的に直すようになっているので、めったに酷い目にはあわないのだが、やっぱりその自動修復には時間がかかり、最近イライラする! という傾向にある。 また、OpenLDAPに至っては、2.1~2.4までインストール作業を行ってきて、そのたんびに ldifに落として入れなおす。 バイナリはもちろん、扱うデータ形式も変わってしまうのだから注意が必要だ。


こんなパッケージの状態に加えて重要なのが、portsそのものの健全性だったりする。
昔からあるのは、portsカテゴリの移動で、これに追跡が追いつかず、自動的なupgradeが頓挫するのを良く見たもんだ。

一般に、portsは放置していると腐ってしまい依存関係を無視してもコンパイルが出来なくなる。

であるから、まず一番重要なのは



1.新鮮なものを手に入れること。

  2008年に2006年頃のportsイメージを広げても、その根拠になるhttp/ftpでアクセス可能なソース配布元が消滅している可能性がある。古いのは駄目だ。


2.OSバージョンとの絡み

  バージョンが違えばportsの対象も異なる。 6.xがメインストリームになってから、4.xで動かないものは多々作られ、8.xがメインストリームになる頃には、6.xで動かない物だらけだろう。 6.xは幸い6.4で終わるので良い(4.x台が 11まで行ったのが異常)が。

3.OSマイナーバージョンで、portsの作法が変更されること。

 おそらく 6.xだけに起きた事ではないだろう。 6.2というここ5年の間ではかなり安定したバージョンのFreeBSDをインストールしたマシンでは、現行の6.4を想定したものが動かなくなりつつある。 インクルードファイルが追加されているので、 6.4に順次移行していく必要がある。


という具合である。 Xやphp 関連の話をすると、portsをキチンと管理しないと、Windowsのソフトウェア管理にも似た酷い状況があって、削除の嵐やら、強制アップデートなどという蛮行をしないと、もはやどうにもならないがこれについては別徒書くことにする。

ports install for server the newbies

新規FreeBSDサーバに ports 関連をきっちり入れていく手順について:

まず、要点から箇条書き。

・cvsup はもう要らない。

 どこかで、ezm3なんかが突っ込まれている場合は注意。
 FreeBSDソースツリーを取得するのには必要なcvsupだが、Modula-3の実装を
 必要とはしない。 csupがあるので、それを使うこと。


・csup も portsツリーの維持には不必要可欠。

portsnapも、不安定な回線にとってはあまりうれしくない場合がある。 Webキャッシュの誓で取れないケースがある。 とはいえ、csupを使うよりも手軽。 portsnapのミラーは、Googleとはいわないまでも、FreeBSDマシン1000台ベースの管理をするようになるまでは不要。

という点を踏まえてまずすべきは。

0. portsnap fetch
0a. portsnap extract

これには場合によっては30分くらいかかる。どちらも最初に長い時間を要する。
手近にcvsup-mirrorがたってれば、csup -L2 なんちゃら で、手近なports-cvsupツリーを
拾ってくるのもあり。


1. /usr/ports/database/db4x の導入。

こいつが何故いるかというと、portsupgrade パッケージを入れるためだが、適当にやると枯れきったdb41辺りから入れてくるので要注意。 Berkeley DBは 長年使われたことと、私企業の製品(BSDライセンスによる使用を許すものだが)に転化したということもあって、配布場所の変遷著しいし、古いものは、メンテナンスされなくなるのではないかという危惧があって db46位にしている。

もちろん、最新のdb47もあるのだが、これは、OpenLDAPのportsで使っておらず、db46/db47が相乗りになって、管理がややこしくなるから入れない。

2. portsupgrade の導入

こいつがないと、 portversionなどの aquisitionが出来ないし、アップグレードもわずらわしい。 難点は、ruby/bdbの絡みがあるので、こいつらが更新されるときに死ぬこと。 もちろん自分自身(portsupgrade自体がportsで提供される)の更新もこける。 ので、最近では、portsmasterも入れて、相互補完する。

管理上、portsupgrade は、portsinstall/portsversion/portsupgrade の主要三形態を利用する。 んで、pkg_deinstallなんかを掛けた時に、矛盾が生じたら pkgdb -Fで修復である。

3. 後は好きなものを入れて行く。

私の好みから言うと、 smartmontools/jed/zsh/sudo/ipmitoolまたはmbmon は欠かせない。 これらはサーバの管理作業に必要な情報、操作手順を用意する。 zshを使うのはいろいろ便利な機能があるからで、csh由来のtcshが嫌いなのもちょっとある。 

portaudit また壊れた?

auditfile.tbz 100% of 51 kB 9185 kBps

portaudit: Database too old.

portaudit: Download failed.


おかしい。 何かがおかしい。

ぐーぐるに訊いてみる

 → portaudit broken again

??
 

2008年12月4日木曜日

Access200x と ワークグループ機能が如何に駄目かという

駄目だ。

こいつはもう駄目だ。

マイクロソフトの暗黒面は、Office20xxに永遠に残されるのであろうか。

まかりまちがって、パスワードなんかつけてしまったり、ワークグループ設定をしてしまうと最後である。
理解しないで設定して、開けなくなる。 わなである。これは罠だ。 MCPを取れと言うのかっ!


・・・・・sigh

2008年12月3日水曜日

shell の文法

時々忘れて恥をかく。

Shellの文法を忘れて、酷い目にあう。


if [ ?? ] then

fi

なぜ覚えないか? awkでやってしまうからだ。

FreeBSD portsの整理作業

FreeBSDを管理するのに、portsは避けることが難しい。

もちろん、無視して管理することは十分に出来る。 だが、portsを使ったほうが多くの関連を持つミドルウェア類を適切に管理していくコストが低くなることが多い。

これが、セキュアであるかはかなり微妙である。だが現実に多くのサーバ機材で稼動させるシステムを世代交代させていく過程では、徐々にバージョンアップしていく作業を続けていく方が、機材が壊れるたびに新しいパッケージを入れていくよりも、問題が少ないように思われる。 理由として、すでに発見された別の問題点が、ほかで影響が出たために解決されていないための回避策パッチなどが、長年、放置されることによって、”孤児”と化してしまうからである。 常に更新され続ければ、孤児はもちろんだが、セキュリティフィックスやOS更新に伴う挙動の変化を常に追い続けることも出来る。 OSが更新されたら、portsも新しくしないと構築すら出来なくなってしまう。

たとえば、6.2p9辺りで稼動していたシステムのportsを更新していて、最近、リリースOSバージョンが6.4に至った日以降、portsの更新でいくつかエラーが出るようになった。 bsd.options.mk など、includeファイル関連が変更されてきたからだが、こういう絡みがあるのもportsの問題でもあり、OS更新が先立って行われないと、portsに問題が出ることがようやく分かってきた。

squid+php+javascript+IE6.xで発生する怪現象

不思議な現象に出会った。

私が、某所でphpで作っているイントラネットのシステムである。ターゲット・クライアントがIEを想定しているのだが、こんな場合に問題がおきることが分かった。

  1. squid を経由する
  2. フレーム使っている。
  3. メニューの枠からjavascriptで .phpなどのURLを読んで、中央フレームに表示する
  4. IEである

この条件が揃ったとき、とある種類のPHPで作ったものが、中央フレームでレンダリングされず
ダウンロードされてしまう。 orz.

この現象に出くわしたとき、何がなんだか分からなかった。 cookieの関係でもないし、ポップアップブロックは解除されている。イントラネット設定なら、特に問題が無いはずだ。 Firefox内で、IE-TABを利用してIEのレンダリングエンジンを利用した場合や、IE直接でレンダリングした場合でも、必ずコンテンツがダウンロードされている。

この動作は、次のような条件を課することで、回避することが出来た。
  • PHPファイル名を短め(8.3形式)に抑える。
最後の "/" から10文字程度のPHPスクリプトを、直接レンダリングすることは可能だが、
Javascriptで、URL指定し、squidを経由した場合に、どうも上手く、対象URIからファイルの
情報受け取れなくなっている模様。 

もう少し調べてみないと、原因が分からない。 あまりにも発生する条件が狭すぎ、
原因となる場所が多すぎるからだ。 少なくとも squidを経由しなければ、発生しない。
squidを経由すると、なにやら情報が削られてしまうという感じはぬぐえない。

Webキャッシュは止めようかな~という気になる。