その国の海岸からは、沖に向かって電線が伸びていました。
高台にエルメスを停め、キノは水平線に消えていく電線を眺めました
「壮大な眺めだね」
とエルメスの感想。
「すごいでしょ」
ハイキングの格好をしている女性が、声をかけてきました。
「海の向こうにまで電気を届けているんですか？」
「いやいや、逆だよ」
「逆？」
「そう、この国は海の向こうから電気をもらっているの」
「こんなに大げさな設備を作ってまで、電気が必要だったの？」
キノが思いついたのと同時に、エルメスが質問をしました。
「もったいないから」
「もったいない？」
そこで女性は海の向こうに視線を向け、語りはじめました。
「昔、海の向こうに小さな島国があってね。火山が多くて地震や津波にくるしんでいる国があったんだよ。
とても技術力はあったんだけど、あるとき巨大な地震と津波のせいで発電所が壊れて、発電に使う有害物質で国土が汚染されてしまった。
今は綺麗な土地に戻っているんだけど、そこに住んでいた人たちは、また同じようなことがあってはいけないと、発電所をとても高い堤防で囲んだんだ」
「ちゃんと学習したんだね」
エルメスの言葉に、女性は少し困ったような顔を浮かべて振り返りました。
その表情の意味が分からず、キノは訊ねました。
「その国の人たちは、今も安全に暮らしているんですか？」
女性は再び海に向き直り、
「その後、また津波があってね。発電所の堤防は高かったから、国土は汚染されなかったんだけど、他の堤防が疎かになっていたんだ」
「ありゃま」
「きれいさっぱり流れちゃってね。今その国には発電所だけ残っているんだ」
「なるほど、それでもったいないと」
「そう、使う人がいないのに、発電所は電気を作り続けている。
最初の災害の後、技術力が更に上がって施設も安全になって、もう壊れることはないから、今後何があってもあの国は電気を作り続けるんだよ」
「儲かっちゃったね」
エルメスに本音を言い当てられたからか、女性は苦笑を浮かべました。
港へ続く海沿いを走りながらエルメスが訊ねます。
「海の向こうの国には渡ってみるの？」
「いや、行かない」
「まあ発電所しかないもんね」
「なにか特産品でもあればいいけど」
「電気しかないもんね」
「それより美味しい魚が食べたい」
「いいね」
「エルメスは食べられないでしょ」
「塩気はちょっと・・・」
「エルメスも電気で走れるようになったらいいのにね」
「電気もちょっと・・・」
「魚の油なら、頑張れる？」
「キノほど食いしん坊じゃないよ」
「まずは生き残らないと、好き嫌いも言えないよ」
10月 07, 2012
地元神社の祭り
昨日、家の近所の神社でお祭りがあった。
天狗が出てくると言うので、朝の10時頃に見に行ったら、すでに子供神輿は終了していて境内では子供たちが騒ぎ、数えられるぐらいの老人たちが神事を見守っていた。神社の本殿では神事が執り行われていて、スーツを着た人や法被を着た人たちが、神主からお祓いを受けたり、巫女さんが舞ったり、お神酒を受けたりしていた。
「あの中の誰が天狗に変身するんだろう？」
「神主が祭壇へ登ってお神酒をとっているついでに天狗に変身するんじゃないか？」
「あのスーツを着た足元おぼつかない最長老が、天狗に豹変するに違いない」
などと言いつつ見守る。
待ちくたびれて座り込んでいる孫を連れたおじいちゃんが「天狗出てくるで」と言っているので、天狗がでてくる事自体は間違いないようだ。
そうこうしているうちに神事は無事終了し、神主さんが表に出てきて「どうぞお入りください」などと言う。
見物人もいつしか数十人になっていて、ぞろぞろと本殿の中へ。
要領が分からずまごついていると、お婆さんから「早くから来られてたんだから、どうぞお先に」と勧められ、一同と一緒に本殿内へ入り着席。
後ろの方では何やら「二人分の席が足りない」などの声が聞こえる。
やがてお神楽が始まり、巫女さんが剣と鉾で舞い始め、神楽鈴(手に持つ鈴がたくさんついた物)でお祓いも受ける。すると三宝に載った赤いキーホルダーが出てきて、参加者に配られ始めた。
しかしよく見ると、周りの人は小さなピンク色の小さな紙切れを持っていて、それと引き換えに授かっているようだ。
我々は飛び入りでそんなものは持っていない。
「なに！部外者が居るだと？」
「者ども出会え出会え！」
「氏子にも成らずして天狗様のお力を甘受するなど！」
などと言う事はなかったが、ちょうど受け取った者から解散のような状態になっていたので、そそくさと退散。
同じ町内に住んでいるのだけど、昔から付き合いのあるところにしかお知らせは回っていないのか、町内会に入っているところだけなのか、我々の住むマンションにまでは氏子募集のお知らせは来てなかったのだった。あの紙の相場はいくらぐらいするのだろう。
きっと後ろで座れなかった人たちの席を取ってしまったんだ。申し訳ないことをした。
教訓、神事への飛び入り参加は注意しよう。
天狗が出てくると言うので、朝の10時頃に見に行ったら、すでに子供神輿は終了していて境内では子供たちが騒ぎ、数えられるぐらいの老人たちが神事を見守っていた。神社の本殿では神事が執り行われていて、スーツを着た人や法被を着た人たちが、神主からお祓いを受けたり、巫女さんが舞ったり、お神酒を受けたりしていた。
「あの中の誰が天狗に変身するんだろう？」
「神主が祭壇へ登ってお神酒をとっているついでに天狗に変身するんじゃないか？」
「あのスーツを着た足元おぼつかない最長老が、天狗に豹変するに違いない」
などと言いつつ見守る。
待ちくたびれて座り込んでいる孫を連れたおじいちゃんが「天狗出てくるで」と言っているので、天狗がでてくる事自体は間違いないようだ。
そうこうしているうちに神事は無事終了し、神主さんが表に出てきて「どうぞお入りください」などと言う。
見物人もいつしか数十人になっていて、ぞろぞろと本殿の中へ。
要領が分からずまごついていると、お婆さんから「早くから来られてたんだから、どうぞお先に」と勧められ、一同と一緒に本殿内へ入り着席。
後ろの方では何やら「二人分の席が足りない」などの声が聞こえる。
やがてお神楽が始まり、巫女さんが剣と鉾で舞い始め、神楽鈴(手に持つ鈴がたくさんついた物)でお祓いも受ける。すると三宝に載った赤いキーホルダーが出てきて、参加者に配られ始めた。
しかしよく見ると、周りの人は小さなピンク色の小さな紙切れを持っていて、それと引き換えに授かっているようだ。
我々は飛び入りでそんなものは持っていない。
「なに！部外者が居るだと？」
「者ども出会え出会え！」
「氏子にも成らずして天狗様のお力を甘受するなど！」
などと言う事はなかったが、ちょうど受け取った者から解散のような状態になっていたので、そそくさと退散。
同じ町内に住んでいるのだけど、昔から付き合いのあるところにしかお知らせは回っていないのか、町内会に入っているところだけなのか、我々の住むマンションにまでは氏子募集のお知らせは来てなかったのだった。あの紙の相場はいくらぐらいするのだろう。
きっと後ろで座れなかった人たちの席を取ってしまったんだ。申し訳ないことをした。
教訓、神事への飛び入り参加は注意しよう。
8月 19, 2012
カブのエンジンオイルを交換
メーター11008km。
4500kmぐらい走ってしまった。お店の人はオイルの交換は5000kmぐらいでいいって言ってた気がするんだけど、ネットで検索するとマニュアルには3000kmって書いてあるらしい。マニアっぽい人は1000kmで交換してるとか。
5000kmも交換しなかったら3年ぐらいで駄目になるとマニアっぽい人は書いていた。お店の人はまた買わせるためにそう言ったのかな？
ペットボトルを半分に切って、そこに受けるようにした。
「ドレンボルトを閉めすぎるな、最初に締まっていた感覚で閉めろ」とネットには書いてあったが、結構強く締まっていた。
ドレンボルトはエンジンの真下、17mm。斜めに付いている14mmを開けちゃうと、なんかバネとか出てくるらしい。
オイルが出なくなっても、キックスタートのペダルを踏めば出てくる。
もう出ないかなってところでドレンボルトを締めて、上からオイルを注ぐ。キャップを何度か閉めて注油量を確認。
それからチェーンの調整も行った。
チェーンカバーを外してたるみを確認。チェーンカバーは外さなくても、黒いカバーを外せばたるみは確認できる。
今回はもうたるんでいるのが音で分かったので、最初からカバーを外してしまう。
後輪位置を決めるのは自転車と同じ。左右のねじを調整して、チェーンがまっすぐになるように。
メモリが付いているけど左右でずれているので信用できない。1cmぐらいのたるみを残しておく。
オイル交換後は若干エンジンが掛かりにくかったが、何度かキックしたりセルモーターを回すとエンジンが掛かる。
アイドリング音もしずかになって、回転数も下がった感じ。
チェーンのたるみがなくなった分、ミッションを切り替えたときの前後の振動がなくなった。
延びすぎたらチェーン交換という認識でいいのかな。
後輪のチェーンが噛む部分がサビだらけだったけど、油が足りないのだろうか？
チェーン側の油は足りなさそうだったので、機械油を指した。
4500kmぐらい走ってしまった。お店の人はオイルの交換は5000kmぐらいでいいって言ってた気がするんだけど、ネットで検索するとマニュアルには3000kmって書いてあるらしい。マニアっぽい人は1000kmで交換してるとか。
5000kmも交換しなかったら3年ぐらいで駄目になるとマニアっぽい人は書いていた。お店の人はまた買わせるためにそう言ったのかな？
ペットボトルを半分に切って、そこに受けるようにした。
「ドレンボルトを閉めすぎるな、最初に締まっていた感覚で閉めろ」とネットには書いてあったが、結構強く締まっていた。
ドレンボルトはエンジンの真下、17mm。斜めに付いている14mmを開けちゃうと、なんかバネとか出てくるらしい。
オイルが出なくなっても、キックスタートのペダルを踏めば出てくる。
もう出ないかなってところでドレンボルトを締めて、上からオイルを注ぐ。キャップを何度か閉めて注油量を確認。
それからチェーンの調整も行った。
チェーンカバーを外してたるみを確認。チェーンカバーは外さなくても、黒いカバーを外せばたるみは確認できる。
今回はもうたるんでいるのが音で分かったので、最初からカバーを外してしまう。
後輪位置を決めるのは自転車と同じ。左右のねじを調整して、チェーンがまっすぐになるように。
メモリが付いているけど左右でずれているので信用できない。1cmぐらいのたるみを残しておく。
オイル交換後は若干エンジンが掛かりにくかったが、何度かキックしたりセルモーターを回すとエンジンが掛かる。
アイドリング音もしずかになって、回転数も下がった感じ。
チェーンのたるみがなくなった分、ミッションを切り替えたときの前後の振動がなくなった。
延びすぎたらチェーン交換という認識でいいのかな。
後輪のチェーンが噛む部分がサビだらけだったけど、油が足りないのだろうか？
チェーン側の油は足りなさそうだったので、機械油を指した。
6月 21, 2012
Windows7をバックアップイメージ経由で移動
パラレルATA接続のハードディスクでWindows7を使っていたのだけど、いい加減速度が遅いのでシリアルATAのハードディスクに移動することにしました。
パーティションをコピーするツールを使ってコピーしてみたのですが、ブートの情報までコピーされないのか起動してくれない。
そこで以前、Windows7のバックアップを経由して別ディスクに移動したことがあるので、この方法で行ったところはまりました。
結論から言うと「バックアップの取得時と復元時に余計なドライブを繋ぐな」 ということ。
以下が流れ。
コントロールパネルのバックアップから、「システムイメージの作成」で余っているハードディスクにバックアップをとります。
そして新しいディスクを繋ぎ、回復ディスクから、修復モードを立ち上げます。
（どうでもいいけど、回復ディスクをUSBメモリに出来ませんかね、マイクロソフトさん）
Windowsのような画面が起動し、IMEの種類を選択したところで、
はて、バージョンが違うってどういうこと？回復ディスクは以前作ったやつで、サービスパックが当たっていないから？
ということで、再度回復ディスクを作り直してチャレンジ。
しかし改善しない。
ハードディスクを繋ぎ直したりしているうちに気がついたのが、データ用ドライブに昔システムが入っていて、そのバージョンを認識してエラーが出ている様子。
回復ディスクで起動するときは、システムが入る予定のドライブだけを繋ぐことで突破出来た。
（なんでこれから回復するっていうときに、別のドライブの残りかすを見てエラーにするんでしょうか、マイクロソフトさん。バックアップイメージと回復ディスクのバージョンを比較するべきでしょう）
なんとか復元対象のバックアップイメージを選択し、回復がスタートしたところですぐにエラー。
復元開始直前に、復元対象から除外するディスクを選択出来る画面があったのですが、そこでは復元先ディスクが表示されていました。
もちろん除外対象にもなっていません。
ネットで検索してみたところ、どうやらバックアップ時に接続されていたディスクの容量からサイズが減るとこのエラーが出るらしい。
このとき、バックアップ時にデータドライブが繋がっており、バックアップ対象にはしていないのに回復時に存在しないため、容量が足りないと認識されていたようだ。
（何この仕様？）
結局、バックアップを取るときにはシステムドライブと、バックアップイメージ保存ドライブだけを繋いでバックアップ。復元時は、復元先ドライブと、バックアップイメージ保存ドライブ、CD/DVDドライブだけを繋いで起動するとよいようです。
もうちょっと分かりやすい仕様になりませんかね。せめてメッセージだけでも。マイクロソフトさん。
パーティションをコピーするツールを使ってコピーしてみたのですが、ブートの情報までコピーされないのか起動してくれない。
そこで以前、Windows7のバックアップを経由して別ディスクに移動したことがあるので、この方法で行ったところはまりました。
結論から言うと「バックアップの取得時と復元時に余計なドライブを繋ぐな」 ということ。
以下が流れ。
コントロールパネルのバックアップから、「システムイメージの作成」で余っているハードディスクにバックアップをとります。
そして新しいディスクを繋ぎ、回復ディスクから、修復モードを立ち上げます。
（どうでもいいけど、回復ディスクをUSBメモリに出来ませんかね、マイクロソフトさん）
Windowsのような画面が起動し、IMEの種類を選択したところで、
このバージョンのシステム回復オプションは、修復しようとするWindowsのバージョンと互換性がありません。このバージョンのWindowsと互換性のある回復ディスクを使用してくださいと言われて先に進めなくなってしまう。
はて、バージョンが違うってどういうこと？回復ディスクは以前作ったやつで、サービスパックが当たっていないから？
ということで、再度回復ディスクを作り直してチャレンジ。
しかし改善しない。
ハードディスクを繋ぎ直したりしているうちに気がついたのが、データ用ドライブに昔システムが入っていて、そのバージョンを認識してエラーが出ている様子。
回復ディスクで起動するときは、システムが入る予定のドライブだけを繋ぐことで突破出来た。
（なんでこれから回復するっていうときに、別のドライブの残りかすを見てエラーにするんでしょうか、マイクロソフトさん。バックアップイメージと回復ディスクのバージョンを比較するべきでしょう）
なんとか復元対象のバックアップイメージを選択し、回復がスタートしたところですぐにエラー。
システムディスクの回復に使用できるディスクが見つかりませんディスクが見つからないとはどういうことか。
復元開始直前に、復元対象から除外するディスクを選択出来る画面があったのですが、そこでは復元先ディスクが表示されていました。
もちろん除外対象にもなっていません。
ネットで検索してみたところ、どうやらバックアップ時に接続されていたディスクの容量からサイズが減るとこのエラーが出るらしい。
このとき、バックアップ時にデータドライブが繋がっており、バックアップ対象にはしていないのに回復時に存在しないため、容量が足りないと認識されていたようだ。
（何この仕様？）
結局、バックアップを取るときにはシステムドライブと、バックアップイメージ保存ドライブだけを繋いでバックアップ。復元時は、復元先ドライブと、バックアップイメージ保存ドライブ、CD/DVDドライブだけを繋いで起動するとよいようです。
もうちょっと分かりやすい仕様になりませんかね。せめてメッセージだけでも。マイクロソフトさん。
6月 15, 2012
tar.bz2なバックアップファイルが復元出来なかった（解決）
tar.bz2なバックアップファイルが復元出来なかった。
bzip2recoverを使えということで、使ってみる。
コンパイルし直せとのこと。
http://www.bzip.org/
からソースをダウンロード
bzip2recover.cの真ん中ぐらいに
tar.bz2のファイルサイズは21,113,008,629なんだけど、どのくらいまで増やせば良いのだろう。
この進捗に表示されている108,490,796,940を調べてみる。
ソースを追いかけてみると、このfromとtoはbStartとbEnd、そして他の場所に
ファイルサイズをビット換算すると168,904,069,032。
8分の5ぐらいのところまで処理しているようなので、余裕を持って2倍にしてみる。
再度bzip2recoverを実行。
これを結合しつつ展開
このファイルだけを再度bzip2recoverに掛けてみたが、エラーは消えず。
結局この部分だけを破棄することとなった。
bzip2: Data integrity error when decompressing.
Input file = (stdin), output file = (stdout)
It is possible that the compressed file(s) have become corrupted.
You can use the -tvv option to test integrity of such files.
You can use the `bzip2recover' program to attempt to recover
data from undamaged sections of corrupted files.
tar: アーカイブ中に予期せぬ EOF があります
tar: アーカイブ中に予期せぬ EOF があります
tar: Error is not recoverable: exiting now
70GBのファイルを20GBまで圧縮してあるのだが、どうやら壊れてしまったようだ。bzip2recoverを使えということで、使ってみる。
block 49998 runs from 108483591327 to 108485995530 block 49999 runs from 108485995579 to 108488398408 block 50000 runs from 108488398457 to 108490796940 bzip2recover: `all0609.tar.bz2' appears to contain more than 50000 blocks bzip2recover: and cannot be handled. To fix, increase bzip2recover: BZ_MAX_HANDLED_BLOCKS in bzip2recover.c, and recompile.50000ブロック以上には対応出来ないようだ。
コンパイルし直せとのこと。
http://www.bzip.org/
からソースをダウンロード
bzip2recover.cの真ん中ぐらいに
#define BZ_MAX_HANDLED_BLOCKS 50000という記述があるので、これを増やすと良いらしい。
tar.bz2のファイルサイズは21,113,008,629なんだけど、どのくらいまで増やせば良いのだろう。
この進捗に表示されている108,490,796,940を調べてみる。
ソースを追いかけてみると、このfromとtoはbStartとbEnd、そして他の場所に
bStart[currBlock] = bitsRead;という記述があることから、ビット表記らしい。
ファイルサイズをビット換算すると168,904,069,032。
8分の5ぐらいのところまで処理しているようなので、余裕を持って2倍にしてみる。
#define BZ_MAX_HANDLED_BLOCKS 100000configureなどはないので、直接make。
再度bzip2recoverを実行。
ls rec15610all0609.tar.bz2 rec31226all0609.tar.bz2 rec46842all0609.tar.bz2 rec62458all0609.tar.bz2 rec78074all0609.tar.bz2 rec15611all0609.tar.bz2 rec31227all0609.tar.bz2 rec46843all0609.tar.bz2 rec62459all0609.tar.bz2 rec78075all0609.tar.bz2 rec15612all0609.tar.bz2 rec31228all0609.tar.bz2 rec46844all0609.tar.bz2 rec62460all0609.tar.bz2 rec78076all0609.tar.bz2 rec15613all0609.tar.bz2 rec31229all0609.tar.bz2 rec46845all0609.tar.bz2 rec62461all0609.tar.bz2 rec78077all0609.tar.bz28万近いファイルが生成された。
これを結合しつつ展開
find . -name "rec*.bz2" | sort | xargs -n1 bzcat | dd bs=65536 | tar xvf -
all0609.pgbackup
bzcat: Data integrity error when decompressing.
Input file = ./rec15012all0609.tar.bz2, output file = (stdout)
It is possible that the compressed file(s) have become corrupted.
You can use the -tvv option to test integrity of such files.
You can use the `bzip2recover' program to attempt to recover
data from undamaged sections of corrupted files.
どうやらrec15012all0609.tar.bz2がまだ壊れているようだ。このファイルだけを再度bzip2recoverに掛けてみたが、エラーは消えず。
結局この部分だけを破棄することとなった。
6月 10, 2012
glibc 2.15のビルドがループする（未解決）
CentOS5.8にgcc 4.7が入っている環境で、glibc 2.15をビルドしようとすると、nptlのところで延々とループしてしまう現象に遭遇した。
検索してみると、「時計が狂ってるんじゃない？アハン？」「VMだったから狂ってたよ！イエアー」みたいな感じで解決してしまっていた。
しかし、うちの場合は実マシンに直接入ってるし、dateコマンドを叩いてみても正しい時刻が返ってくる。
途方に暮れていたところ、別の検索結果から、インストール先のincludeを消すか名前を変えたら上手く行ったよ、という書き込みを発見。
/usr/localにインストールしようとしているときに、/usr/local/includeの方を参照しちゃって、まずいことになるらしい。
早速、
mv /usr/local/include /usr/local/include_org
としてconfigureしてみると、ヘッダファイルが見つからないというエラー。
そ、そうか…。
元に戻して、configureをしてから/usr/local/includeをリネーム。
すると、gd.hが見つからないというエラー。
確かに、gd.hも/usr/local/includeに入っていた。
もう一度、configure --helpを見直すと、gdのインクルードディレクトリを指定するオプションがあった。
もしかして、このために？というようなオプション。
結局、以下のような手順で問題の箇所は通過出来た。
1.ソース展開
tar jxf glibc-2.15.tar.bz2
2.展開したディレクトリに入る
cd glibc-2.15
3.ビルドディレクトリを作る
mkdir -p build
4.ビルドディレクトリに移動
cd build
5.gdのインクルードディレクトリを参照するためのシンボリックリンクを用意
ln -s /usr/local/include /usr/local/gd
6.configure
../configure --disable-sanity-checks --with-gd-include=/usr/local/gd
7.インストール先のincludeディレクトリをリネーム
mv /usr/local/include /usr/local/include_org
8.シンボリックリンクの先が居なくなってるので張り直し
rm -f /usr/local/gd
ln -s /usr/local/include_org /usr/local/gd
9.make
make
しかし、その後もmakeでエラーが頻発し、もう前にも後ろにも進めないという状態。
結局諦めた。
1.そもそもの発端は、MongoDBにアクセスするC++プログラムを書きたい。
2.標準で入っているboost 1.33では、古くてビルドが通らない。
3.boost最新版がgcc4.1でビルド出来ない。
4.gcc4.7を/usr/localに入れる。
5.phpが起動しなくなった。
6./lib64に入っているlibc.so.6(glibc 2.5由来)と/usr/local/lib64/libc.so.6(glibc 2.15由来)が衝突している（後者を読んで欲しいのに、前者が読まれる）
というようなことで、いろいろ環境を立ち直らせたかったのですが、gcc4.7はまだ早すぎたようです。
結局CentOS6.2を入れ直して標準のgccのバージョンが上がれば…と期待しつつ、システムを入れ替えることにしました。
アップグレードはサポート対象外とのことで、再インストールを予定しています。とりあえずはyumからのアップデートも試してみようかと思います。成功した報告はないらしいのですが。
検索してみると、「時計が狂ってるんじゃない？アハン？」「VMだったから狂ってたよ！イエアー」みたいな感じで解決してしまっていた。
しかし、うちの場合は実マシンに直接入ってるし、dateコマンドを叩いてみても正しい時刻が返ってくる。
途方に暮れていたところ、別の検索結果から、インストール先のincludeを消すか名前を変えたら上手く行ったよ、という書き込みを発見。
/usr/localにインストールしようとしているときに、/usr/local/includeの方を参照しちゃって、まずいことになるらしい。
早速、
mv /usr/local/include /usr/local/include_org
としてconfigureしてみると、ヘッダファイルが見つからないというエラー。
そ、そうか…。
元に戻して、configureをしてから/usr/local/includeをリネーム。
すると、gd.hが見つからないというエラー。
確かに、gd.hも/usr/local/includeに入っていた。
もう一度、configure --helpを見直すと、gdのインクルードディレクトリを指定するオプションがあった。
もしかして、このために？というようなオプション。
結局、以下のような手順で問題の箇所は通過出来た。
1.ソース展開
tar jxf glibc-2.15.tar.bz2
2.展開したディレクトリに入る
cd glibc-2.15
3.ビルドディレクトリを作る
mkdir -p build
4.ビルドディレクトリに移動
cd build
5.gdのインクルードディレクトリを参照するためのシンボリックリンクを用意
ln -s /usr/local/include /usr/local/gd
6.configure
../configure --disable-sanity-checks --with-gd-include=/usr/local/gd
7.インストール先のincludeディレクトリをリネーム
mv /usr/local/include /usr/local/include_org
8.シンボリックリンクの先が居なくなってるので張り直し
rm -f /usr/local/gd
ln -s /usr/local/include_org /usr/local/gd
9.make
make
しかし、その後もmakeでエラーが頻発し、もう前にも後ろにも進めないという状態。
結局諦めた。
1.そもそもの発端は、MongoDBにアクセスするC++プログラムを書きたい。
2.標準で入っているboost 1.33では、古くてビルドが通らない。
3.boost最新版がgcc4.1でビルド出来ない。
4.gcc4.7を/usr/localに入れる。
5.phpが起動しなくなった。
6./lib64に入っているlibc.so.6(glibc 2.5由来)と/usr/local/lib64/libc.so.6(glibc 2.15由来)が衝突している（後者を読んで欲しいのに、前者が読まれる）
というようなことで、いろいろ環境を立ち直らせたかったのですが、gcc4.7はまだ早すぎたようです。
結局CentOS6.2を入れ直して標準のgccのバージョンが上がれば…と期待しつつ、システムを入れ替えることにしました。
アップグレードはサポート対象外とのことで、再インストールを予定しています。とりあえずはyumからのアップデートも試してみようかと思います。成功した報告はないらしいのですが。
4月 02, 2012
カラオケボックスにおける新しい体系
わたしは音痴です。
自分の下手さ加減に、こんな歌声は聞きたくないと自分が思います。
ですので自分からカラオケに行くことはないのだけど、流れ上避けられない状況というのはあります。
そういう場合、何かと理由をつけて歌うのは断るのですが、カラオケボックスでは歌うことがメインになりすぎていて、なかなか場を白けさせずにということに気を遣います。
そこで、どういう状態がベストなのか、そこから導き出された提案を書いてみます。
こんなことをカラオケボックス内でやりとりしたくないし、それこそ場が白けるので、こんなところに書いています。
まず、なぜ音痴なのか。なぜ歌を上手くしようと思わないのか。
すべての人には得手不得手があります。そりゃ、頭の回転も良くて、記憶力も抜群、運動能力も高く、ルックスも万人受け…そんな人になりたいです。
しかし、持って生まれた身体。鍛えるにしても限界があります。
池乃めだか氏にダンクシュートをしろと言っても無理なのです。
Q:誰も聞いてないよ。
A:わたしが聞いています。
Q:歌えば気持ちいいよ。声出せば気持ちいいよ。
A:だから自分の歌声を聞きたくないのです。それならさきっちょでアメマと叫びます。
Q:出せる音域の歌を歌えばいいじゃないのか。
A:歌いたい歌を歌わずにして、何が気持ちいいのでしょうか。声が出るなら高いキーの曲を歌いたいです。
Q:歌わないと楽しくないよ。
A:他の人の上手い歌を聴いているだけで十分楽しいのです。
Q:下手でもいいじゃない。
A:わたしが苦痛になってもいいというのか。
そんなこんなで、最初にも書いたとおり、カラオケボックスは一般人にとって歌う場でしかなく（オフ会とかで、歌わずに過ごす場合もありますが、それは別にして）、歌が苦手な人にとっては苦痛な空間であることが多いです。
そこで、カラオケボックスの仕組みがもう少し変われば、みんな好き勝手なことしてて楽しめるのに、とも考えました。親交を深めるという意味では、どうなのかという気もしますが、うまく変えられればいけるのではないでしょうか。
例えば、飲み屋でハンドルキーパーは割引になるように、歌声キーパー(笑)の人が居ると、キーパーは割引、歌う人も少し割引とか。（調べてみたのだけど、最近の通信カラオケは一曲当たりの単価じゃないみたいで、店舗にメリットがない？）
カラオケの曲がビートマニア・ポップン・DDRみたいになっていて同時に遊べる。（歌声でバンゲリング帝国が操作できるとか）
なかなか上手い組み合わせが思いつきませんが、カラオケというものを別のものに進化させることができれば、もっと多くの人が楽しめる場になるのではないかと、思うのです。