|
Ｔ-４の整備日誌v2Ｔ－４の徒然なる駄文
|
« 2007年06月 | メイン | 2007年08月 »
Mediawikiのデータベースがインポート出来ないって記事を以前に書きましたが、Mediawiki側のバグだったらしく、修正版がリリースされました。→アナウンス
Fixed installation on MyISAM or old InnoDB with charset=utf8, was giving overlong key errors.
というのが、それにあたるようです。
他にもいくつかバグフィックスされているので、アップデートしたほうが良いでしょう。
つい先ほど、カーネルアップデート、リリース4.5への移行、Xサーバの更新に伴い、サーバを再起動しました。
Webアクセス、FTP、DNS、メールともに特に問題は確認されておりません。
テレビ終了まで4年を切ろうかという時期になってきましたが、後継のデジタル放送は一回しかコピーを許さない通称コピワンとなっています。ここで言うコピーとは放送局から家庭内の録画機器へのコピーの事で、録画機器からDVDやBDやHD DVDや、ましてやPCのHDDではありません。
コピーが一回しか駄目なので、DVDにコピーということは出来ません。最近HD DVDのCMを東芝がよくやってますが、ムーブしか出来ません。DVDに残して、携帯でも見るとかは不可能です。
この日本独自の悪習ともいうべきルールに対して、総務省は、9個までのコピーを許す方向で放送局に要請を行なうと発表されました。HDDに番組を蓄積しながら9回のコピーが可能で、10回目はムーブという運用ルールに変更されるとか。
今まで買ったHDDレコーダ、もちろん宣伝中のHD DVDレコーダも含めて、ですが、これらはこのルールにまず適合出来ません。今買うと損というか、コピナインにしたかったら買い替える必要がありますが、テレビのCMはもちろん、新装開店した上進の店員も口が裂けても言いません。売れなくなるからです。
現時点でも普及してるとは言いがたいデジタル放送機器。
規格がまた変ると知った貴方。もう少し買い控えますか？
しかし、コピー回数が1回から9回になったところで、コピワンとなんら変りはないのです。
コピーが出来るのはマスタのHDDからだけです。コピーをしたければ残しておく必要があります。しかしHDDの容量は有限です。一杯になったら消していくしかありません。
「ハイビジョンで残そう」のキャッチに載せられて、HD DVDに録画しました。少したった後、このHD DVDからコピーを作って携帯で見ようとしました。無理です。出来ません。
記録媒体の説明書には「大切なデータを失わないために複製を～」との注意書きがされている事が一般的です。思い出の番組だから複製してバックアップしておきましょう。これも出来ません。
HD DVDはBlurayDiscとの競争に敗れて廃れました。HD DVDに録画した番組をBDに移そうとしました。もちろん出来ません。
出来ませんだらけになんら代わりが無いのです。
デジタル記録はエラー訂正の出来る閾値を超えない限り、劣化しません。でも、これはデータが無くならない事を意味しません。着実にコピーを重ねていかないと、「記録」して永続的に残せないのです。劣化しないのはデータそのものであり、入れ物たるメディアは陳腐化し、物理的に劣化し、中のデータを保持できなくなります。かつて「永遠」を実際に謳っていたレーザーディスク。これもつい最近生産が止まりました。いつまでプレイヤーがあるでしょう？いつかは再生出来なくなる時がきます。BDもDVDもHD DVDも同じです。しかし、幸いにもLDにはまったくコピーガードがありません。LDでしか発売れなかったタイトルもごまんと存在しますが、DVDに移し変える事でその命を永らえる事が出来ました。しかし、BDもCPRMなDVDもHD DVDも、そこでデータは死んでしまいます。
コピーワンスもコピーナインも実は「記録」するという行為を不可能にします。子供を生んでもその場で去勢するのと同等の行為です。だったらコピーネバーにしてしまえば？と思う私です。
一回で不満なら9回にしてやる。という今回の変更。意味はまったく有りません。HDDレコーダーを買う予定があるならば、店員虐めの材料にはなるかもしれないですけどねｗ
結局のところ、本来の記録たる録画をしたければ、アナログ経由で録画するしかないようです。HDMIでも出来ますが、莫大な投資が必要とされているのが現状です。
今日、アカウント停止についてご連絡くれた方、返信はしておきましたが、YAHOOメールだったので、迷惑メールに分類されてしまっている可能性が高いです。迷惑メールフォルダも確認して下さい。
SenderID 導入すれば解消されるのだろうかｗ
修正を入れましたので報告します。
1.全般的
致命的エラーの処理関数を変更。
通常の使用法では呼び出される事はありませんが、不正なセッション(手続きを踏まずにあるフェーズを呼び出す)、ブラウザの戻るを使って、消去済みアイテムを呼び出す、SQLの構文が不正になった等の場合に呼び出されて処理を中断します。
ある場所に操作ログを吐き出すようにして、ユーザには簡潔なメッセージのみとしています。
2.HTML構文の修正。
滅多に呼び出されないユーザ編集や削除のあたり。
3.HTMLサニタイジングの強化
15ファイルぐらい書き換えたので、バグってたらご報告ください。
展示ルームですが、最近チョコチョコ変更を入れています。
投票システムを展示ルームのソースから流用して作りつつあるのですが、ちょっと前ならOKだったようなやり方に攻撃方法が見つかって駄目になってたり、このチェックだけではすり抜けたりと、なんだかんだとありまして、コピペしてさっさと作るという目論見は崩れております。
また文法チェッカというものを当時は使っておりませんで、間違いまくりだったりでして、それも直しています。
結局のところ、展示ルームからコピペというより、投票システム開発から、展示ルームにバックポートしてるような状態です。
本日の影響箇所
1.全般的
JavaScriptを組み込が可能な事からXSSの可能性があるためにあるサーバ変数を別のものに変更。
置換ツール使って全体的に変えましたが、デグレる可能性は殆どありません。
2.ログイン、ログアウト、ユーザ登録、ユーザ登録OK、ユーザ編集、ユーザ削除、ユーザ編集OK、ユーザ削除OK、個人データ参照、シリーズデータ参照、シリーズ検索
HTML構文の間違いを修正
formタグの括りが間違ってるとデグレると思いますが、一通りはチェック済み
3.共通関数
メール、ホムペのチェックの関数をバイナリセーフになるように変更しました。
4.ユーザ登録処理
htmlサニタイジングの強化
一応、diaruga(開発マシン)上で動作チェックはしてから、decalto(運用マシン)に適用していますが、おかしな挙動に気がついたら報告をお願いしておきます。
僅かですが、Webサーバの設定を変更しました。
殆ど影響はないはずですが、Cookieの受け入れを完全に拒否していると、セッションを使用しているページは見れなくなる可能性があります。デフォルト拒否の人でもセッション関係のCookieは受け入れてください。