Last Updated at $Date: 2010/03/09 16:36:53 $.
岩崎恭子さんの回の再放送を偶然に見る．挫折と復活．なんとも言えぬ．
学生に読ませるべきかなあ? あまり深刻にならずに気楽に進学して，駄目だったら気楽に転身する，という風にはならないものか．
「定型」的制約を課すこと、あえて「フィクション」を書かせること。 それによって、「ほんとうのことを言おう」と思っているかぎり口にされないことが語られるという背理は、 ある意味では諸刃の剣のように危険なものである。
最近，DFSG の改訂についてもめている．
DFSG および，それの転じた形である OSD は， ノウアスフィアを維持・拡大することを本旨として書かれていると考える．
まず，改変不可能部分が存在することは，そんなにも本質的にまずいことなのか? われわれ，プログラマーは，著作権表記を改変したり削除したりすることに対して， 非常に大きな禁忌を感じている． これを具体的な文面で禁止したライセンスを設定したとしても， 私たちの社会的な規範の自然な反映に過ぎないのではないか?
RFC などの規格書は，再配布は可能だが，改変は禁じられている． もしも，これらの規格書の改変が可能であったならば， 可能性としては，非常に沢山の修正された規格が乱立してしまうことになりかねない． そのようなことになれば，作成されたソフトウェア間の interoperability はかなり損なわれることになってしまうだろう． また，interoperability を確保するための，非常に無駄な労力が必要となるだろう． つまり，規格書は「改変を制限する」ことによって， 私たちのノウアスフィアを拡大することにかえって役立っているのではないか? 実際，インターネット上で相互に通信を行うプログラムを作成するハッカー達は RFC に進んで従うし， RFC に違反しているソフトウェアを批判するではないか? 改変を制限せず，「改変者は改変個所を明示しなければならない」というライセンスでも， そのような改変を不当なものと見なす強い圧力が働くであろう事は簡単に予想されるから， 改変を禁止する必要性は低いのかも知れない． しかし逆に，「改変を禁止する」ことの害悪も殆んどないのではないか?
「改変を禁止する」を，単に「改変されたバージョンを同一名で配布する ことを禁ずる」条項と考えてはどうだろう? 一般的に，OSD 準拠のライセンスでは，原作者と改変者の名誉を守るために， 後から加わった改変項目については，改変者と改変個所を明示することが求められている． 名前を変更するというのは，改変が行われたことを明示するもっとも極端な形に過ぎない． 「複製禁止」「再利用禁止」「改変禁止」という区別を行ってはどうだろう． 重要なのは，プロジェクトを fork させる権利だ． 「改変禁止」とは，完全に同一の複製を配布することは許可されているが， 改変したバージョンを同一の名前で公開することを禁止しているライセンス． この場合，改変を含むバージョンを，まったく別の名前で公開することが許容されているならば， 最悪の場合には，名前を変更することによってプロジェクトを fork させることができる． 「再利用禁止」とは，完全に同一の複製を配布することは許可されているが， 改変されたバージョンを別の名前で公開することも禁止しているライセンス． この場合，プロジェクトを fork させることができない． 「複製禁止」は，そもそも同一の複製を無条件に配布することも許可されていないライセンス． もちろん，プロジェクトを fork させることなんて不可能． ここで，従来は「改変禁止」は non-free 扱いだったが， 「再利用禁止」を non-free 扱いの条件にしてはどうだろう? RFC の場合，明示的に再利用が許可されているわけではないが， 公開著作物であり，実質的には再利用できる状態と考えて良いだろう． GFDL は改変禁止条項を含むことができるが，プロジェクトの fork を妨げてはいない．
DFSG は本来，明示的ではなかったハッカー倫理を明文化した形であったはずだ． ならば，改変禁止部分を含むようなライセンスを無条件に批判する前に， それが私たちの社会的な規範に照らして，正当か否かを問うべきではないのか? DFSG を単なる法律として，それを字面上だけで一貫性のあるものにしようとして， 杓子定規に運用しようとすることは，Debian の自殺につながるだろう．
今ほどフリーソフトウェアが流行していなかった頃，初期の Linux や Apache を見て，
悪意のある開発者がバックドアを仕込むことが可能だから， 信頼性の重要な部分にフリーソフトウェアを使うべきではない．
と言っていた人が居たことを思い出しました． 何か信頼性を担保するための仕掛けが考案されたとか，そういう変化があったわけではありませんが， 今では上のような疑問を呈する人はかなり少なくなったのではないかと思います． 採用実績の積み重ねられたことによって，上のような疑問が重要視されなくなったのでしょう．
ここで，フリーソフトウェア運動で可能だったことが， Wikipedia でも可能かどうか? ということが問題になります．
私個人としては，どちらも普通の人間がやっていることには変わりないのだし， なんとかなるんじゃないかなあ，と楽観的に捉えています(根拠はありませんが)． ただ1つだけ，両者のコミュニケーション手段の相違が問題になるかも知れません． フリーソフトウェアの開発においては，途中までの議論は普通の自然言語で行われていても， 最終的には実際に動くプログラムコードになります． たとえば，提案者の意見が分かりにくい場合には， 「動くコードで示して」と言うことができます． 非常に過激な意見の持ち主に対しては， 「(私個人としては無理だと思うけど)動くコードで示してくれたら考えますよ」 と言うことができますし，実際にフレームを避けるためによく行われます． それに対して Wikipedia では，最終的な実装も自然言語の形で行われますから， このような逃げ道がありません．
そういう不利はあるかもしれませんが，私は Wikipedia を信頼しています．
以下は，関連するリンク．
不覚にも30秒ほど「そんな知人いたっけ?」と悩んでしまった． へッダを調べると MailDistributor で送信していることが分かったので，幸いにも返信せずに済んだが， これが Outlook とかだったら念のために返信してたかもしれないな．
Received: from unknown (HELO localhost) (202.211.128.88) by my-mail-server.example.net with SMTP; 19 Sep 2004 03:09:25 -0000 Received: (qmail 26305 invoked from network); 18 Sep 2004 18:23:26 -0000 Received: from unknown (HELO tf-004) (192.168.0.70) by localhost with SMTP; 18 Sep 2004 18:23:26 -0000 From: sawada aiko <sawada_aikojp@yahoo.co.jp> To: <tsuchiya@...> Reply-To: <sawada_aikojp@yahoo.co.jp> Date: Sun, 19 Sep 2004 03:21:24 +0900 Subject: あのぉ・・・ X-Mailer: MailDistributor 澤田ですけど、 何も書いてないメールくださいましたよね？ 念のために返信しますが、どちらさまでしょうか？ 知人のいたずらですか？
それにしても，手の込んだことをするものだ． ここまで手間をかけても，活きているメールアドレスを集めるのは儲けになるのだろうか?
爆笑してしまった…．私は「徹夜」と「現実逃避」のコンボ技に頼ることが多いかなあ．
「世界Aの始末書」 で取りあげられていた通り，「暗号の危殆化」なんて SF 的な設定だろうと思っていたのですが． なんとまあ，現実にそういうことが起こるとは． 暗号アルゴリズムに重大な欠陥が発見されたらしい． これからしばらく，大騒ぎが続くことになりそうですね．
Matz 日記でまつもとさんが以下のように発言されていた．
この点、私は「GPL は契約ではない。著作権行使方法の宣言である」と読んでます。 日本でもアメリカでも誰からも文句が出ない形で GPL を契約として成立させるのは無理があるような気がします。
最初に，GPL が契約ではなく，著作権行使方法の宣言に過ぎないと仮定してみます． そうすると，GPL の第11節に含まれている以下の「無保証条項」も単なる宣言に過ぎない， と解釈されることになるでしょう．
11. BECAUSE THE PROGRAM IS LICENSED FREE OF CHARGE, THERE IS NO WARRANTY FOR THE PROGRAM, TO THE EXTENT PERMITTED BY APPLICABLE LAW.
(snip)
SHOULD THE PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING, REPAIR OR CORRECTION.
もしも，無保証条項が契約として成立していないことになると， ソフトウェアのバグが原因で損害が発生した場合に損害賠償請求される可能性が出てきます． これは開発者にとって非常に不利な解釈なので， 少なくとも開発者は「GPL は契約だ」と主張する必要があるのではないでしょうか． なお，権利不行使の宣言と見なされる可能性については 「GPL と日本法の整合性」 でも指摘されています．
この点について，私はオープンソフトウェアの法的諸問題に関する調査の「3.1 GPL 契約の有効性」が参考になりそうだと考えています．
しかしながら，GPL が成立しないということになると， GPL に基づくオープンソース・ソフトウェアを複製・改変・領布している者は著作権者の許諾無しにこれらの行為をしていることになり，それは著作権侵害ということになり， オープンソース・ソフトウェアに関連する活動の主要部分を即座に止めろということになってしまう．
GPL は，「自身の著作権を利用して，複製・改変・領布などの方法に加えた制限を強制する」 という構造になっています．したがって，著作権者の許諾が必要な行為をしているユーザーを対象とする場合は， GPL を契約として強制することができるでしょう． 少なくとも，許諾無しに複製を利用されているという趣旨で反訴することは可能でしょう． それに対して， 著作権による制限を受けない形態(例えば，私的複製や正当な引用)で利用している利用者については， GPL が単なる宣言として解釈される可能性があることになりそうです．
しかし，損害賠償請求をふっかけるような裁判沙汰にすることができるのは， ほとんどの場合は企業です． そして，企業が業務を目的としてフリーソフトェアを利用している場合には， 私的複製や引用の範囲には含まれず，著作権者の許諾を必要とするでしょう． つまり，企業を対象とする場合には，GPL を契約として強制することができるでしょう．
そういうわけで，GPL が単なる宣言と見なされる可能性はあるが， 多くの場合には契約として機能していると考えることができるのではないか， というのが現時点での私の解釈です．
読まないと．しかし長い…．
されてしまいました．いずれ，呑み会でも企画しましょう．
うーん．
「著者＝読者」という構造が崩れた。 現在P2Pネットワーク上で行われている共有は、 「著者」不在で「読者」のみの間での共有だ。
新規著作物の生産には何ら寄与しないフリーライダー問題は，確かに存在します． しかし，複製および配布に係るコストが極端に低下した社会において， フリーライダー問題はそんなに深刻な問題なのでしょうか． フリーライダーがいかに増えようとも， その人々がたとえば押し掛け厨とかになったりしないかぎり， 著者の活動の阻害要因にはならないのではないかと思います．
仮に，「フリーライダーが存在によって著者の活動が阻害されるようになっている」 ことが説得力ある形で示されるのであれば，話は別ですが． それまでは，そう言った連中は，礼儀正しく無視して差し上げるのが， 健全な態度ではないかなあと思っています．
コピーレフトなコンテンツが増えたら， もっと世の中面白くなるだろうになあと思ってはいました． しかし，世の中のコンテンツの大半はコピーレフトにならないだろうとも思っていました． それは，大半の作者は「自分の書いたものは自分のもの」にしておきたがるだろう， という予想があったからです．言い換えれば， 大半の作者は「コピーレフトにしたがらないだろう」と予想していたことになります．
この予想の下でコピーレフトなコンテンツを増やすには， 作者の独占欲を上回るような，何か強力な動機付けがひつようになります． しかし，私には「あなたも以前は別のコンテンツの恩恵を受けているのだから， その恩返しにコンテンツを公開すべきだ」というような論理しか思いつけませんでした． しかし，この論理は，フリーライダー問題を解決できませんから，多分うまく動かないでしょう．
そこに，今や強力な反証が現れたわけです． 旅行者間の情報共有に関する動機付けと，ハッカー精神との相似性を説明している以下のくだりは， とても感動しました．
たしかに，このような価値観を共有しているコミュニティの中では， 情報の共有と発展がうまくいきそうな気がします． Wikipedia もうまくコンテンツが増え続けているようですしね．
すると，この活動を持続可能なものとしている背景には何があるのか， を説明することがまず重要です． その背景とハッカー精神との関連付けが行われれば， より広汎な範囲に適用できる普遍的ハッカー的価値基準というものを見い出すことが出来るかもしれません．
以下の条項は矛盾していると思うのは私だけでしょうか? 最初に「プログラムの実行については，この約款の対象範囲外だ」と宣言しているのに， 後で「実行結果についての責任は負わない」と書くのは良いのでしょうか． 以前の GPL についての話でも指摘されていた問題が， 解決されていないのではないかと思うのですが…．
- 第1条
- 1
- (省略)
- 2
- 本約款が適用されるのは、著作権法で規律される複製、 公衆送信及び改変の各行為についてのみであり、 甲の提供するプログラムの著作物を電子計算機上で実行する行為自体には、 本約款を適用する余地はない。
- 第8条
- 1
- 甲は、乙に対して、オープンソースプログラムの利用について、 何ら対価関係なく許諾するため、甲は乙に対して、 オープンソースプログラムの動作等についていかなる保証もしない。
- 2
- (省略)
- 3
- オープンソースプログラムの質と性能に関するリスクのすべては乙に帰属する。 オープンソースプログラムに欠陥があると判明した場合、乙は、 乙が使用する範囲で必要となる保守点検や補修、修正に要するコストのすべてを引き受け、 乙は、甲に対し、何らの補償を求めないものとする。
- 第9条
- 甲は、乙その他のオープンソースプログラムを使用する者に対して、 オープンソースプログラムの使用又は使用不能によって生じるいかなる直接間接の、 一般・特別、結果的、または付随的な損害（事業利益の逸失、代替品の費用、 情報の逸失等を含むが、これらに限定されない）について、損害賠償の責任を一切負わない。
さて，またもや困ったことになった．
おそらく，大抵のものは体力勝負になるのではないかと．
難しい話題，としか言いようがない． 未だにきちんと社会に適応できていない人間としては．
8年前のパソコンをそろそろ捨てようと思う．ショップブランドなので，リサイクルは不可能．
単純に大型ごみに出すしかない．
そうすると，気になるのはハードディスクの内容だ．完全に消去するにはどうしたらいいのだろう?
と言うわけで，調べてみると
ファイル等を復元できないように削除するソフトウェア
という一覧表が見つかった．
GNU shred を使って，shred -n 2 -z -v /dev/hda
とすれば良いようだ．
さて困ったことになった…． 良心的な技術者は，セキュリティホールが存在しているにも関わらず， それを塞がないのは恥知らずなことだと，つい考えてしまう． しかし，そのような技術者的に健全な反応を，会社組織に常に求めることはできない． たとえ，セキュリティホールを放置したために情報が漏洩したとしても， それが営利上の損害にならなければ，会社組織としては損害ではない． と言うことは，営利上の問題を伴わないセキュリティホールの指摘は， 無視される可能性が高い． また，正業に就いている者が，そのようなセキュリティホールを公開した場合は， 民事裁判などの手段に訴えれば，殆んどは威圧できてしまうだろう． そうすると，世の中には， そのようなセキュリティホールを業として悪用するような人しか残らないのではないか? つまり，マフィアとクラッカーの結託だ． ここで問題なのは，たとえマフィアとクラッカーが結託したとしても， 会社には影響はなく，私たちの市民的自由とか社会的コストの問題にしかならない，ということだ． 言い換えると，セキュリティホールを会社が放置したツケを， 私たちが払わされるようになるということだ． この問題を避けるためには， セキュリティホールを放置することを法律で禁止するしかないのだろうか?
確かに．本質的に孤独な行為であるからこそ，共同作業がうまく行った時の快感は大きいのだろう．
考えをまとめている暇がないので，とりあえずリンクだけ．
コミュニケーションというものに対する自分の立ち位置をはっきりさせる必要を，最近強く感じる．
今更言うまでもないことだが，この2〜3年， WEB日記という形式で発表される文章が非常に増えてきている． これらの中には，自分の利用したソフトウェアの感想や使い方を述べている文章も多い． しかし，これらの文章を書くのは，なんとも自閉的なコミニュケーションの形態だなあと良く感じる． 特に，フリーソフトウェアのバグや不具合について述べている文章を見ると，とても悲しくなる． なぜ，それらの文章の筆者は，ソフトウェアの作者に連絡しないのだろうか． どうして，自分一人でぼそぼそと書きつけるだけなのだろうか． そんなにも連絡するのは，コミュニケーションを試みるのは面倒なのだろうか．
日本語文字コードの自動判定についての考察は， 大変参考になる．また， 天泣記でも追試されている．
理想論かも知れなくても，こう言った原則を忘れてはならないと思う．
大変参考になる． 特に，GPL が権利不行使の宣言に過ぎないと解釈されるならば， 無保証条項が無効になってしまう可能性は他人事ではない． 素人考えでは，「利用する場合も無保証条項を承認したものと見なす」 という文言を追加すれば良いのではないか? と思うのだが， このような「見なし契約の成立」が認められるかは疑問． しかし，この「見なし契約の成立」が認められないことになってしまうと， 配布の度に契約成立を確認しなければならないことになって， 自由な再配布が事実上不可能になってしまうのではないだろうか?
LWN の記事も参考になる． (2004年1月6日追記)
考えてみれば当たり前のことなんだけど． 日食は「月の影が地上に落ちる」と言うことなんですね． それにしても，凄い絵だ．
Ruby/GTK + Embeded Mozilla で作られたブラウザ． Ruby に関連するライブラリの進歩の速さに驚愕する．
私は Emacs Lisp が大好きだ．理由は幾つかあると思うが，
何と言っても editor と言語が結合されているために，
プロトタイピングが非常にやりやすくなっている点が大きい．
ちょっと何かを試したくなったら，*scratch*
バッファが使えばすぐに確かめられるので，便利この上ない．
しかし，最近の他の言語の展開を見ていると，どうも Emacs Lisp は進歩が止まっているんじゃないか? という気がしてくる． やっぱり，他言語で記述されたライブラリを組み込む能力や， 継続などの機能が欠けている点が問題なのだろうか．
半世紀以上も前にこういうことを考えていた人がいたんだなあ． emacs-w3m も， こういう風に簡単にメモ書きをとれるようなツールに育てたいと思う．
別に私は疑り深くないけれど，後で読もう．
ついつい，実行速度を考えてしまって，直接アクセスにしてしまうんですよねえ． やっぱり，富豪的に考えないと．
Web 日記の形成期の資料．
院生というものは時間に余裕があり，一日中コンピュータに向かいっぱなしなので， 新しいことに飛びつくのはたいてい院生である．<中略> ネットワークの管理維持は死活問題であった． 自分の車をぴかぴかに洗車するマイホームパパのように，彼らはネットワークを大事にした．
という一節を見て，複雑な気分になったりする．
後で読もう．
全体に，プログラマ以外の一般的な人々にも分かり易く書かれている点は良いと思います．
しかし，個人的には，題名だけは何とかしてほしいと思います．確かに，フリーソフトウェア運動は， 複製コストが異常に低いという情報財の性質に依存していることは確かですが， だからと言って，参加者が(何らかの手段で)糊口の資を得ることができなければ成り立ちません． prosumer(= 生産者消費者)に対してタダ働きという言葉を使うことは， 単なる消費者的観点を助長し， 消費者という断絶を惹起することにつながりかねません． 本文を読めば，そう言うことを意図しているのではないことははっきりとしていますが， こういう文書においては主張と表題は一致しているべきだと思います．
先見の明と先見の迷惑．さてどちらが多いか?
Democracy is the worst form of Government except all those other forms that have been tried from time to time.
Winston Churchill, 1874-1965
これまでは，著作権が侵害されていることを侵害の被害者(= 提訴側)が立証しなければならなかったのが， 改正案では，侵害していないことを侵害を疑われている人が立証しなければならなくなるらしいです． ‥‥‥と言うことは，大企業からは個人を提訴し放題ってことですか? 確かに，大企業重視の知財権保護の流れとしては一貫性があるけど， ベンチャーを振興しようとか言ってることとは一貫性がないんじゃないかなあ．
オープンソースの定義の注釈を， 開発者の負担を最小化するという観点から，自分なりに書き換えてみた．
再頒布に条件をつけると，条件の境界領域が必ず発生する． すると，境界領域上の事例について， 条件を満たしているかどうかを問い合わせる必要が生じて， 開発者の負担が増える．
修正案付きのバグ報告が期待できるので，開発者の負担が減少する．
条件をつけると，条件の境界領域が必ず発生する． すると，境界領域上の事例について， 条件を満たしているかどうかを問い合わせる必要が生じて， 開発者の負担が増える．
評判ゲームにおける開発者のリスクを低下させる．
利用できる個人やグループに対して条件を加えると， 条件の境界領域が必ず発生する． すると，境界領域上の事例について， 条件を満たしているかどうかを問い合わせる必要が生じて， 開発者の負担が増える．
利用できる分野に条件を加えると，条件の境界領域が必ず発生する．以下同じ．
利用できる製品に条件を加えると，条件の境界領域が必ず発生する．以下同じ．
「他のソフトウェア」に含まれるソフトウェアとは何かという条件に， 境界領域が必ず発生する．
各所で話題になっていますが，私も debian package をインストールしてみました． とてもかっこいい見映えになっています．
ただし，ページの言語を設定するメニューが削除されていたので，
Content Negotiation
を採用しているページを見ようとしたときに，少し困りました．
使用上のヒント
を参考に，about:config に移動して以下のように変更すると，
正常に日本語のページが選ばれるようになりました．
intl.accept_languages
intl.charset.detector
intl.charset.default
内田樹さんの『自分は邪悪な人間であるという観点から構成された自分史』 という記述が今日になってようやく親身に理解できたような気がする．
確かに自分は，
というような構造をきちんと言語化できる哲学という学問は， 確かに興味深い学問だなあ．
鵜飼さん，野首さん，前原さんと京都で呑み会．
原作者がキーワードを適宜指定することによって，名前の自動生成を行うというのはどうだろうか．
kakasi の辞書を mecab 形式に変換すればいい． 全ての単語の品詞を名詞であると仮定して，長さに基づくスコアを与えれば， 最長一致の単語分割を行わせることができるから， mecab によって kakasi 互換の結果が得られるだろう．
知識を増やすために学会(特に学会誌または論文誌)が果たしている重要な役割として， 海のものとも山のものとも分からない雑多な発見に対するある種の権威付けという役割がある． 権威付けされた知識は，一定の価値を持つことが保証されているから， 良質の知識を蓄積することが容易になる．
フリーソフトウェアを振興するために，フリーソフトウェアの学会を興すことを考える． この場合，上述の考えから，フリーソフトウェアの評価機構を何とかして作ることが必要になる． しかも，フリーソフトェアが継続的に存続するためには， 新規性のみならず，継続性を何らかの形で評価することが必要である． 現在のハッカー世界での評価を見ると，原作者の貢献に対する評価に対して， 継続的にメンテナンスを行っている作業者に対する評価が低すぎるのではないだろうか．
研究会としては，新規プロジェクト研究会，メンテナンス研究会，マーケティング研究会， ライセンス研究会の4部門があると良さそう．
深いなあ．
私という現象は，仮定された有機交流電灯の1つの蒼い照明です． あらゆる透明な幽霊の風景や，みんなと一緒にせわしくせわしく明滅しながら， いかにも確かに灯り続ける銀河交流電灯の1つの蒼い照明です．
メモ書き技術を考える必要があるなあ…． とりあえず，SpamAssassin を使うときにテスト結果を本文内に書かないようにする(へッダのみに書く)ためには， 以下の設定で良いようだ．
report_header 1 use_terse_report 1 rewrite_subject 0
あと，日本語メッセージ用に以下の設定も重要． 何か分からないことがあったら，Mail::SpamAssassin::Conf(3) を見るべし．
ok_languages ja en ok_locales ja en
実際の移転は随分前(今年の3月頃)でしたが…． 実際問題として，この移転には非常に多くの問題があったと思いますので， このページからリンクすることによって， ページを作成されている方への応援に代えさせて頂きます．
面白い。特に以下の北野さんのコメントには考えさせられた。
星野氏は、知能ロボットの研究は目的が曖昧であると指摘している。同感である。 人間の知能を理解したいなら、知能ロボットの研究者は、 もっと脳を研究するべきであるし、工学として有用なロボットを開発したいなら、 人間の認知のことはあまり気にするべきではないであろう。 サイエンスなのかエンジニアリングなのかが曖昧である。 もちろん、人間の知能 をロボットを使いながら研究する手法もあるが、 この場合、理論は実際の脳での実験的検証で確認されるべきで、 ロボットがどう動いたかで検証されるべきではない。
これは自然言語処理の分野にも言えることだと思う。 ただ、ロボカップの場合は標準問題がうまく設定されているので、 それによって達成度をはっきりと知ることができるが、 現在の自然言語処理はそうではないように見える。 と言うよりも、 標準問題が設定できる問題(形態素解析・構文解析など)の技術は順調に進歩しているのだが、 それ以外の問題の進歩が遅れていると言うべきだろうか。
高林さんの日記に紹介されて、 急に広まり始める。
お正月企画。Info の中で解説されている関数などについて、 通常の脚注を辿る場合と同じように処理されるように advice を定義した。
最近、quick sort は良くないと説教されてしまったので、ちょっと sort について勉強している。で、Comb sort というソート法があるらしい。
で、このアプローチは Shell sort の変形にしか見えないのだが…。 特に、ステップが9または10の場合は11にするという操作によって高速化されると言う記述を見ると、 そんな気がする。本当のところはどうなんだろうか?
2週間の間に論文の締切が3本重なると…。 想像もしたくない事態になります。
「遺跡の声」(堀晃)買いました。 「太陽風交点」ってこんな話だったかなぁ。 前に読んだときは中学生だったので、記憶もおぼろげ。 ロッシュの限界って言葉を知ったのは、何の話だったっけか。
野尻抱介さんの作品です。面白いです。 舞台設定も面白いのですが、それがきちんと謎解き形式になっているのが良いです。 もう少し文章表現が凝っていると更に嬉しいですが。
私にとってソーシャル・テクスト事件から分かったこと。 「本を買う前には、その著者の発言内容について良く調査するべきである」
すっごい、cool な Elisp です。是非使うべし。
科学的立場について真剣に考えさせられます。
語りえないことがらについては、沈黙しなければならない。
失踪したい…。
提出した。後は公聴会を残すのみ。呑みに行く。
現在枚数 / 予定枚数 = ?????
ここを読んで、 私だけじゃないんだ…と心を和ませる。
しむ。
ついに寝袋を持ち込みました。 と言っても、もうそんなには使わないと思うんですけどね。 だって、コーディングは気力で何とかなるという側面もありますが、 作文の方は気力ではどうもならないでしょう。やっぱり、クリアな頭でなくちゃ。 まあ、気構えの問題かな。
いえ、締め切りはまだなんですけど。なんつーか、修論締め切りの日に、 三津子さんの日記みたく『おしまいの日が来た』って書いたら受けるかな、とか。
学会の投稿締切日。鬼のような生活を送っています…。
CVSは、本当に便利です。作業用のコピーを複数持てるから、 一部分だけ変更して試したい場合の処理がとても楽です。
うーん…。皆さん何を見に来ていらっしゃるんでしょうねぇ。
「真理はひとつ」となどと考えるのは、せいぜい大学の学部生あたりまでで、 大学院生以上になると、「真理はボスの数だけ存在する」と知る。
という一節に思わず笑ってしまいました。
いつものことだよ…。
最後の更新になる予定。 この文書と同じように存在意義が疑われる文書は、出来るだけ削除していくべきなんじゃないかな…、と思うんだけど。
うーん…、現実逃避。書き換えと併せて、SSH 対応版 impost の更新を行いました。従来のものと比べて、エラー処理が強力になり、頑健になりました。 また、手元に環境がないので確認できませんが、Perl4 でも使えるようになったはずなのですが…。
元々は研究室の先輩から頂いたスクリプトだったのですが…。 いつの間にか、こんなに肥大化してしまいました。
Mule-2.3@19.28 に対応するために sdicf.el その他に変更を加えました。 該当する Mule を使用されている方は更新された方が良いかも知れません。
科学というのは、人間集団が知識を共有しようとする試みですから、 すごく分かりやすいところから始めざるを得ないんです。 文系の学問のように、一人の天才が出現したらそれでおしまい、 という訳にはいきませんので。
変更は Meadow などの Windows 環境でのインストール用スクリプトだけで、 本体には変更はありませんから、インストールできている人は特に追随する必要はありません。
.emacs で設定している項目」を更新しました。
(1999年2月10日)
従来、xdic として公開していた辞書閲覧プログラムを SDIC と改名、大幅に拡張して公開しました。xdic の最初のバージョンを公開してから、ちょうど1周年。 このプログラムの開発を通していろんな人と知合い、面白い経験が出来ました。 さーて、本業を頑張らなければ。
Emacs/Mule に標準的に付属している shell-command はコマンド名やファイル名などの補完が効かないため、使い勝手が悪かったので、補完が効くようにした shell-command-with-completion を作りました。
.emacs で設定している項目」を更新しました。
(1998年11月23日)
.emacs で設定している項目」を更新しました。
(1998年11月12日)
バージョン 0.5beta を公開。バグありませんよーに。
ちょっとしたバグです。あせあせ。
いろいろな Emacs に対応していくと、本質的でないコードが増えて、 コードが汚くなってくる…。しくしく。
fetchmail の開発者がフリーソフトの開発についての考えを述べているページ。 なぜ、Linux が成功したのか、極て説得力のある理論が展開されている。
リンク集に色々追加しました。そろそろ、1ページでは足りなくなってきたかなぁ。
あぁ、早くこの泥沼から解放されたい…。
内容は、今のところインストールログがメインです。 今後増えていくでしょう。多分。
自分があまり使わない機能を付け加えるものではないですね…。 --delete オプションにバグがありました。
『急いで修正すると、修正したつもりでバグが増え』(おそまつ)
fj.sources 他に流した直後に、馬鹿なミスに気が付きました。 急いで直しましたが、その間に持っていってしまった人が何人かいるようです。 すみませんが、もう一度、ここから持っていってください。
ディレクトリの permission が保存されていませんでした。 これに対応するため、スクラッチから書き直しました。
Wnn 関連のリンクなどいくつか追加
300人→500人は、なんだかかなり早かったですね。 これからもよろしくお願いします。
卒論終わりました…。 ひーん、3日も徹夜したので体も頭もフラフラです〜。
中学英語の教科書に出てくるような間違いを、 しかもトップページでしていました…。 あーはずかし。
卒論〆切まで後12日。こんなことしてる場合ではないんだが…。
う…、現実逃避が止まらない。どうしたもんだか。
お客さんの人数が300人を越えました。自分がアクセスした回数も入っているし、 本当はどのぐらいなのか、というのはよく分かりませんが…。 それにしても、どんな人が見ていっているのかなぁ? Internet は相手の顔の見えないメディアだということを意識はしていたつもりでしたが、 なんだか、すこし怖いな、と唐突に思いました。
私が 96 年度の学生実験の時に書いたレポートの原稿を置いてあります。 内容については一切保証致しませんので、悪しからず。
変数 case-fold-search の値が nil の場合の動作を修正しました。
tar でファイルを展開する時のオプションを変更しました。
HTML ファイル中の <a name="foo">bar</a> タグから、 索引を生成するコマンドを作りました。
紹介していた定型文中で、<head> タグと勘違いして、 <header> タグを使っていたのを修正しました。
ファイル先頭で jperl 用のスクリプトとして指定されていても、 普通の perl をデバッガとして使っていたのを修正しました。
ああ、現実逃避の病が…。定型文についての記述を大幅に変更しました。
grep/egrep/fgrep のどれを使いますか? (1997年12月16日)
fj.unix で、「What is a unix wizard ?」という題名のスレッドが 盛り上がっているのですが、その記事中で、
「というやり取りがあったんで、各種egrepが一番速いから、それを使う」
「いや、正規表現を使うか使わないかによって使うgrepを変える」
grep の比較をしてい
るページを
覗いてみました。
それで…、OS に標準で付属している各種 grep には色々
と使い分けの根拠があるようなのですが、結局、標準品より GNU のが速
い、そーです。(しかも、GNU の場合、grep/egrep/fgrep
は全て同じバイナリなんだそうです)
それにしても、たかが grep されど grep
という感じでした。正規表現のマッチングアルゴリズムの比較が非決定
性オートマトンなどを使って説明されていたので、ちょっと勉強になり
ました。情報理論的にも結構きっちりしたもんだったんですね。
あ…、また現実逃避の病が…
わーい、開設20日目で100人越えましたー。ありがとうございます。 (なんて志が低いのだろう) しかし、100人の内、自分がアクセスした回数が 20 回は含まれていると思 われる…。ま、都合の悪いことには気が付かない振りをしていよう。
複製元の permission が保存されないバグを修正しました。
研究がうまく進まないものだから、思わず現実逃避…。ホームページのメ ンテナンスなんかしています。これでいいのか! (いやよくない)
syncdir.perl は、自分自身を子プロセスとして呼び出しています。従って、 パスの通っている場所に置いておかなければ、子プロセスとして呼び出す ことができず、動作しませんでした。そこで、絶対パスで指定されたとき に限って、子プロセスをも絶対パスで呼び出すように変更してみました。 後、-u オプションを付け加えました。
アクセスがとろくなるのが分かってたんで、少し悩んだんですが、
という恐怖感に勝てず、設置してしまいました。て訳で、今日を正式オー プンの日とさせて頂きます。ひょっとして誰もアクセスしてないんちゃう?
[Top] / [更新記録 & 雑文]