history

青木日記 RSS

<前の日 | この月 | 次の日>

2004-01-24

TD4 / クロック精度

12/07の日記 にツッコミがあったのでこっちでも追記。 TD4 でクロックがきっちり 1Hz にならないそうです。

http://www.bea.hi-ho.ne.jp/m-okaniwa/cpu.htm

家の TD4 もクロック・リセットだけはできているので、 ストップウォッチ片手に測ってみました。

結果は 60 秒で 58 クロック。やっぱりちょっとずれてるけど、 ツッコミの人は 53〜54 ということなんで少しはましなのかな。 ふーむ。この違いはなんだろう。

※ どうでもいいが「ツッコミの人」という表現は 「紫のバラの人」の構造に酷似しているような 気がするのは気の迷いですか。そうですか。

TD4 も早く続きをいじりたいんだけど、とりあえず今は締切だにゃ。

ああっ、わかってますってば、書きます! 書きますとも! そんな恨みがましい目をしないでえええ!

(17:50)

BitChannel / ページ凍結

http://i.loveruby.net/w/BitChannelRequest.html

やはりページ凍結機能の要望が来てしまったか……。

結論から言うとページ凍結は導入しません。 理由は実装がめんど……じゃなくて、あまり意味がないと思うからです。

例えば、上記のページには凍結が欲しい例として 「SitePolicyを変更されたらやだ」 という例が挙げられていますが、SitePolicy を凍結しといても FrontPage を変更してリンクを張り換えてしまえば効果は同じです。 あるいは、SitePolicy だけ守っても他のページをことごとく消されたら やっぱり困るでしょう。

ではどうするかというと、 基本的には荒らされちゃったらあきらめるしかないのかなあと思います。 でもまあ、何も対策しないってのも悲しいので、

  • 何か変なことがあったらすぐにわかる
  • できるだけ簡単に復旧できる

と、復旧機能を充実することで解決しようと思います。

ページを復旧するのは BitChannel では超簡単です。 History → ViewRev → EditThis → SAVE と 4 回クリックするだけで任意のリビジョンを復活できます。

他に、CVS で直接操作する手もあります。 これなら「何でもあり」なので、全ページを特定の日付の状態に戻すなんてのも簡単。 もちろん、バックアップがあるならレポジトリごと戻しても OK。

問題は変更を検出するほうですが、 こっちがまだ弱いんですね。 とりあえずメール送信と RDF 出力は対応します。 問題は口をどこに作るかですが、 まず他の Wiki の状況を調査してからにします。

(19:27)

SFU + Cygwin = ...

一つのファイルを SFU の vi でいじりつつ Linux で cvs ci して Cygwin から cvs up すると摩訶不思議なことになるということがわかった。

(01:58)

mput'sちゃんねる

http://mput.dip.jp/mput/

見ればわかる。

(03:50)

Java並列プログラミングTips

http://www.netgene.co.jp/java/concurrentTips.html より引用 (とくひろ日記@tDiary経由)

The Java SeriesにはDoug Lea著の「Javaスレッドプログラミング」があるが,こ
れについても補足しておこう.この本の原題は"Concurrent Programming in
Java:Design principles and patterns"で,このタイトルから判断すると本来は
並列プログラミングの書籍である.(略)
……
原文で読んでも理解するのはかなり難しく並列プログラミングを知る者にさえも
内容を把握するのは困難.少なくともほとんどのベテランプログラマーを含む
「並列プログラミング初心者」には,絶対に勧められない代物となっている.
 
「Java言語で学ぶデザインパターン入門マルチスレッド編」や「Javaプログラム
デザイン」のマルチスレッド関連の解説も,Doug Leaの「Javaスレッドプログラ
ミング」を参考にしているらしい.このため,これらのいずれもが Javaを使った
並列プログラミングの参考には,あまりならないと考えられる.

げげ、そ、そうなの?

内容もすごすぎ。Tips とかいうレベルじゃない。

(04:59)

本日のツッコミ(全5件) [ツッコミを入れる]
ささだ (2004-01-24 21:46)

1000ページあったとして,各ページに100回くらい機械的な荒らしのアタックがあったとして,更新通知メールは100000通.根本的には対策は無理なんですかね.まぁ,時間制限とかなんとか入れるとしても,いろいろ抜け道はありそう.その中から有用な変更を救おうとすると,さらに大変そう.

根本的な対策は恨みを買わないことくらいなのかなー.

青木 (2004-01-24 22:53)

その回数だとWikiとか関係ないっす。
家の貧弱な環境なら回線がつぶれて終わり。
それに、そこまでやっちゃうと悪戯じゃ
すまないので、荒らすほうとしてもリスクが
高すぎるでしょう。

青木 (2004-01-24 23:03)

と思ったけど、100000セーブくらいじゃだめかな。
個人運営ならその程度でも攻撃と認めてくれるだろうか。

まちゅ (2004-01-25 08:13)

通知メールを送るタイミングをページの更新ではなく、一定時間ごとにすればどうでしょうか。

青木 (2004-01-27 21:19)

ああいや、たぶん実際にメールが100000通来ることはなかろうと思うので
あまり本気で心配はしてません。実際に起きたらなんか考えます。

名前
メールアドレス

<前の日 | この月 | 次の日>
2002|04|05|06|07|08|09|10|11|12|
2003|01|02|03|04|05|06|07|08|09|10|11|12|
2004|01|02|03|04|05|06|07|08|09|10|11|12|
2005|01|02|03|04|05|06|07|08|09|10|11|12|
2006|01|02|03|04|05|06|07|08|09|10|11|12|
2007|01|02|03|04|05|06|07|08|09|10|11|12|
2008|01|02|04|05|06|09|10|
2009|07|
2010|09|

Copyright (c) 2002-2007 青木峰郎 / Minero Aoki. All rights reserved. LIRS