08:49:11 # Debian 「IANALだけどね」．そんな言い訳一般人には通用しない． Debian独自の言葉というわけではないかもしれないが， Debian界隈でよく聞く略語．この言葉の意味はなんだろう．
'I am not a lawyer'という文章の頭文字をならべるとIANALになる．
法律の専門家ではないけど，弁護士ではないけど，という意味で使う．
debian-legalというライセンスについて熱く語るためのメーリングリストがあるが，
そこで「私には責任がありません」と同等の意味で使われる．
なお，そのメーリングリストは非常にマニアックで専門的で，フリーであることについて
理想が高い人が隔離されて集まっている．
このソフトウェアをこの国で配布することは可能なのか，ということを論じながら，
IANALで逃げ道をつくる．
どうも責任をとりたくない人達がだべっているだけのように見える．
これも，Debianの性質の一つなのだろう．
今後は本当に判断が必要なところには，責任をかぶってくれる，弁護士を
やとって判断をしてもらうというのが必要になるのかも．
しかしながらそもそもそういう判断に困るようなグレーな状況が増えないことを祈るばかり．
20:33:11 # Life Debian勉強会の宴会場を確保した． けっこう荻窪には飲み屋がそれなりにたくさんありますねぇ． もうすぐ，なんだか楽しみになってきました．よろしくお願いします．まだ空きはありますので， 参加できる方はどうぞ．
08:03:49 # Debian 「NMキューが長い」．いろいろな人が愚痴っている． でも，知らない人が聞いても意味が分からない． Debianでいう，NMってなんだろう．
NMはNew Maintainerの略． Debian ProjectにMaintainerとして新しく参加する人をさす． NMプロセスという，新しくメンテナになるための手順が整備されており， それに沿って思想の確認や，技術のレベルの確認，業績の確認などのプロセスが行なわれる． 例えば，大浦さんの頁には，彼の経験したNMプロセスの例が書いてある． すでにDebian Developerである人からの推薦を貰えば， AMという担当の人がついて，各種の確認をしたあと， AMからDAMにアプリケーションレポートを提出し，最終的にDAMが新規 Debian Developer追加の判断をして，アカウントの作成などを実行する． 現状，100人くらいが常時並んでいる長い列だ． これはAMの部分で待っている人も多いし，DAMの部分で待っている人も多い． DAMの処理量を軽減するために，迅速に処理するために構築したNMプロセスも 早ければ数日で終るのだが，1年近くの時間がかかることが見込まれる． Debianプロジェクトが死に絶えないためには， 新しい血の流入は必要だと思われるので，このシステムは重要だが， 期間や利便性については，改善も必要だと思われる． また，Debianに参加しても，MIAになる人もいる． そうなるとNMプロセスでせっかく処理したのに意味が失われてしまう． そういう状況も避けたい．できることなら思想のチェックや実績の確認あたりで 継続性のある人かどうかも判断できることを望む． ちなみに，このシステムが構築される前はDAMが直接電話して本人確認をしていたらしい． slink/potatoのリリースされたころまではそうだったのではないだろうか？ 今後はNMプロセスの時間的，精度的な改善を目指してなにか考えますかね？
06:50:29 # Debian 「DAMの反応が相変わらず悪いのだよ」．そんな愚痴を聞いても 知らない人は知らない． DebianのDAMってなんだろう．
DAMはDebian Account Managerの略で， Debian Projectに参加している人のユーザアカウントを管理する人のようだ． 実際に管理するのは，おそらくDebian管理のサーバにログインする際に利用する LDAPのデータベースと， DebianのGPG暗号鍵のキーリングを管理している． DebianのGPGのキーリングへの登録はDebianへパッケージをアップロードする際に 必要な手順で，キーリングに登録されていない鍵を使って暗号署名した パッケージをアップロードしても受け付けて貰えない． つまり，実際のDebian Projectへの参加を承認する権限を持っている人． 今はJames Troup． また，一応'Joey'もDAMだということになっているが，今は 全くDAMとして活動していない，ということらしい． いつまでこの体制で続いて，どうやったら変わるのか，ということについては不明． 建前としてはDPLが委任する，という形をとる． DebianのGPG鍵の管理を委任される人のため， 新しく委任されるための要件が難しい． 理想的にはあたらしくDAMになる人は，すでに存在している Debian Projectのメンバー全員から信頼に足りると 信任される必要があるだろう． Jamesがその要件を満たしているわけではないのだが，James以外の人がその要件を満たす ことは凄く難しいため，現状を維持しているようだ． Jamesはftp-masterとしての絶大な権力も持っているが，その権力については最近は分散されつつある． 今後はいかにDebianの整合性を保ちつつDAMの権限の委譲を行なうか，ということを検討する必要があるだろう． というのも，DAMの事務処理が遅くて新しいDebian Developer がなかなか追加されないという状況が出ているからだ． この状況の改善には政治的な気合いが必要だと思われる．
07:51:42 # Debian 「DPLの選挙ってつぎはいつだっけ？」 と聞かれても知らない人はわからない． DebianにおいてのDPLってなんだろう．
DPLとは，Debian Projet Leaderの略． 任期１年で，投票によって決定される． Debian Projectのリーダーとなる人． その一年間DPLとなった人はDebianの代表としていろいろなことをする． 主な業務としては，展示会とかで代表として名前を出すことと，最近ではDebian Conferenceで挨拶をすることくらいか？ 昔プロジェクトのリーダーで専制政治をとった人が居た影響で権力が全く無い地位になった，という話しらしい． DPLとしての判断が必要な業務というのは存在しないはず． 一応の形としては，DPLがftp-masterなどの各種の業務について委任する，という形をとる， という建前になっているが， Debianのボランティア制度，やりたい人がやりたいことをする，という主旨との整合性をとるのが難しい． つまり，命令が必要な人に命令を与えることができるが，自分の意志で命令をすることを期待されていないという存在． DPLという窓口が機能して，いろいろな雑務がうまく権限委譲できればよいのだが， Debian Projectの今の「やりたいひとがやりたいことをする」というルール(？) を壊さずにできる方法が見付かっていないのが現状ではないだろうか． DPLでないとできない，ということはおそらく何もない．
08:31:27 # Life Debian勉強会についての情報を更新． Debianについてリアルに語る場所をつくることが主眼です．よろしかったらどうぞ．
08:18:29 # Debian 「そのソフトウェアDFSGに準拠している？」 そんなこと聞かれても知らない人は知らないだろう． Debianで使われているDFSGという言葉はどういう意味なのだろう．
DFSGとは，Debian Free software Guidelineの略． フリーソフトウェアとはどういうものであるか，ということを簡潔に定義している． ここでの，フリーソフトウェアとは，Debianとして配布するフリーソフトウェアで， その「フリーソフトウェア」という言葉の範囲を定めているというわけ． フリーソフトウェアといってしまうとまぎらわしいので，「DFSG-free」 (DFSGの意味でのフリー)ということが最近は多いみたい． 改変が配布できて，いろいろな制限がされていないこと， そんな条件が 列挙されていり． DFSG自体は著作件法63条におけるいわゆる利用許諾ではなく，各ソフトウェアの利用許諾が Debianが配布するのに適しているか，ということを判断するための基準． 今後も，どのソフトウェアがこの条件に合致しているか，ということについて 熱い議論が継続され，より多くのソフトウェアがDFSGに合致した条件で配布されるようになるだろう． ただし，DFSGには，文面からは明確でないので， 部分的に変更不可能なものを許可する文面が今後盛り込まれる必要がある． たとえば，利用許諾条件を明記した文章の変更を許可する必要が無いという点については明記されていない． 何まで許可して何を許可しないのか，は今後の議論を待つことになる．
08:32:59 # Debian 「ポリシーに反しているバグはSeriousです」． そんなことを言われても不条理な． Debianでよく使われる「ポリシー」という言葉にはどういう意味があるのだろう．
Debian では， Debian Policy というものがあり，Debianが配布する各パッケージが 従うべき条件というものが明記されている． シェルスクリプトの記述時のルールからパッケージ名の構成要素， 依存関係の必要性など幅広くDebianプロジェクト内で 実施されてきた内容についてのルールが明記されている． これは，いままで実践された内容で，このルールに従うのが良い，ということが 判明したものについて，ドキュメント化しているもの． Debian Policyと同じようにパッケージ作成の際の指針について 記述した文書にDevelopers Referenceがある． Policyにはこのルールに反するものはDebianとして配布しないほうがよい という強制力が伴うという点で，違う． Policyの内容は，変更するのにはdebian-policy メーリングリストで提案して， そこで複数のデベロッパーの支持を得ることで実現できる一方，Developers Reference についてはそういう指針は無い． 今後もPolicyについては変化し続けるものだと思われる． 現状巨大な文書になりすぎているので，不要な部分についてはそぎおとす努力が必要だとは思う． 特にDevelopers Referenceとの住み分けを明確化していくのが必要ではないか？
08:07:23 # Debian 「Debian Social Contractに反する行動ではないのか？」そう言われても 納得できる人は少ないかも知れない． DebianででてくるSocial Contractにはどういう内容があるのだろうか．
日本語に訳した場合「社会契約」となっている． Debian Projectが社会に対して宣言している内容になる． 5項目からなり，Debianがフリーソフトウェア社会の一員としてよき市民であることを宣言している． フリーである構成物のみから構成することや，成果をコミュニティーに還元すること， 問題を秘密にしないこと，ユーザとフリーソフトウェアが大切であること，そしてフリーであることの定義(DFSG)からなっている． Debianの基本的な構成要素について定義しているので，基本的な方針を決定する際にはよく 引合にだされる． 日常で議論になるのはフリーであることの定義で， 新しくITPされたパッケージがフリーであるかどうかを検討する際に利用される． 問題を隠さない，という点とユーザが優先される，という点に付いては，たまにバグなどの解決の優先順位について議論する際に持ち出されるが，ユーザは神だ，という論理が通っているわけではない． 技術的な議論が失敗し，ソフトウェアの改変について議論する方法がすべて尽きた時に引合にだするものだろう．その場合は，もちろん，敗け戦．
2004年の春に改定され，ソフトウェアに制限せず，すべてをフリーである，という内容に変わった． そのため，Debian 3.1 (sarge)以降はドキュメントやデータなどにもフリーであることを要件としてリリースすることになる．sargeは投票の結果移行中の例外処置として，ドキュメントなどはフリーでなくてもよい，ということになっている．
今後の展開としては，ドキュメント等についてのフリーの定義について議論が深まっていくことを期待している．DFDG(Debian free documentation guideline)などが策定されてもよいだろう． その議論はdebian-legalメーリングリストあたりでされるだろう．
08:08:04 # Debian 「こいつ，MIAだ．パッケージをのっとってしまえ．」． そういわれても分からない人にはなんのことか分からない． Debianで出て来るMIAという言葉にはどういう意味があるのだろう．
MIAはMissing in actionの略．米軍の用語で，戦争中に行方不明になった 人，もしくは戦力外になった人をさすみたい． Debianの用語としては，メンテナとして作業をしていないのにもかかわらず，居なくなったことを 宣言しない人． 居なくなること，脱落することを宣言しないからいつやめたのかわからない，という特徴がある． MIAが発生すると，責任者がこっそりといなくなってしまった状況のパッケージが生まれる． それらがみなしごパッケージ． しばらくは誰も気づかずに放置され，メンテナンスされないという憂き目を見る． その状況を改善するために，QAチームはメンテナの行動を監視するシステムを構築して， 行動状況を逐一確認，何もしていない人には存在確認のメールを送って， 返事がかえってくるかどうかでMIAであるかどうかを調べている． 最近はその行動監視の意義について全体的に理解的だが，数年前は監視については 是非の議論が激しくなされていた． 将来的にはMIAになった人をより正確にわかるようないろいろな技法が充実して， 手続き的にも確立して，MIAの影響度を下げる方向にむかうと思われる． 希望としては，急にいなくなったりしない世の中になるのが理想なんだけれども．
08:04:52 # Debian 「このパッケージNMUしておきました」． そういわれても分からない人には分からない． Debianでたまに出て来るNMUという言葉はどういう意味だろう．
NMUはNon-maintainer Uploadの略で， 正式にはメンテナではない人がパッケージをアップロードする行為をさす． 通常はメンテナがパッケージの唯一の担当者なので，その人が 修正などをアップロードするのだが，それが実施できない場合などに NMUは発生する． メンテナが動けない場合や，行方不明になる場合というのは多数あり， その場合にパッケージに深刻な不具合があれば，現実的な解としてNMUすることが 許されている． しかし，メンテナとしての権限を継承することなく，NMUをするという行為は，つまり 「今ある問題は解決してあげるけど，今後のメンテナンスは面倒みないよ」 と言っているのに近い． しかし，リリースが近かったりすると，そういうことも言ってられないので， NMUが多く発生する． 今後は，よりグループでのメンテナ制度や，メンテナが居なくなってしまったパッケージについては よりメンテナ権限を継承しやすくなっていくことがおきていくだろう． 責任回避としてのNMUの一面をなくしていくのが今後の課題だと思われる． NMUしたらそのパッケージに関して新しく発生した問題について責任をとうような 制度と機構の変更が望ましいだろう． たとえば，現状では，NMUしたパッケージに対してBTS登録された報告は NMUした人には自動的には伝わらないような仕組みになっている． ここは改善の余地があるのではないか？
08:24:48 # Life Debianでの勉強会をしたいと思い，部屋をとってみた． 杉並区民として税金を納付しているだけではもったいない気がするため． 集まって何かをすることでDebian hack の刺激になれば，と思っています．
10:38:56 # Debian 「おい，このパッケージうごかないぞ，メンテナは誰だ？」 そういわれても知らない人には分からない． Debianでよく出て来るメンテナという単語はどういう意味だろう．
メンテナはパッケージの面倒を見る人という意味で，Debianでは， パッケージに対して担当者が決まっている． その人がそのパッケージの不具合については責任を持つ． パッケージ情報の制御フィールドにそのメンテナの名前が出て着ているので， 誰が担当だかすぐにわかるし，BTSに登録したらそのメンテナにメールが行く． Debianの特徴としては，金銭的な利益は全くないのにもかかわらず， メンテナとしてあるパッケージの責任をとる，と宣言している人達が1000人ほど 集まっている，という点． 最近はメンテナとしてグループがなったりしている． 一人では管理しきれない大きなパッケージというのがたくさんあるからだろうし， また，複数の人で管理するメリットというものもあるのだろう． 今後はよりグループでのメンテナが普及していくのではないだろうか？
ちなみにメンテナから見たパッケージの情報を集約しているサイトがある． QA.debian.orgのdeveloper.phpがそれで， 現在メンテナが担当しているパッケージの状況が一覧で出て来る． あるメンテナが何を担当しているのかが知りたければ，どうぞ．
11:20:07 # Life 昨日は表参道でクリスマスパーティーがあった． なんとも調子にのって飲みすぎたが，いろいろな方とお話しできてよろしい感じ．
11:15:06 # Debian 「ITPしてよ」． そういわれても分からない人にはさっぱり分からない． Debianでよく出て来るITPという単語はどういう意味だろう．
ITPはIntend-to packageの略で，Debianに新しいパッケージを追加するという宣言． Debian Projectでは，よさそうなソフトウェアを見付けて，Debianに入っていないことが確認できたら， ライセンスを確認して，debian-develメーリングリストにメールを投げることになっている． そこで，ライセンスがDebianの求める水準にあるかどうかの確認や，他のメンバと作業の重複が無いような確認をすることになる． 時にはすでにDebianに入っているのに気づかなかったりするので，その確認は重要． また，トラッキングを容易にするために，BTSの'wnpp'仮想パッケージに対して「バグ」を登録することになっている． そのバグのタイトルは「ITP：」 ではじまり，パッケージがDebianに入ったら，そのバグは閉じることになっている． 必要なソフトウェアがあって，だれかが作業しているか，ということが分かるので，それなりに便利なシステム． しかし，現状の問題としては，ITP一覧の頁を見たら分かるが やります，と宣言してから長い間そのままになっている報告が多い． 長いものでは，900日とか放置されている．宣言してから3年経っているのにもかかわらず，パッケージに至っていない． 今後は，この一覧表のメンテナンスポリシの策定などが必要なんじゃないか，な？
08:36:13 # Debian 「その不具合BTSしときました」． そういわれても知らない人はさっぱり分からないだろう． DebianでBTSってどういうことだろう．
BTSはBug-tracking systemの略で，Debianで利用している ウェブとメールインタフェースを持つ問題管理システム． 規定のフォーマットのメールを作成して，パッケージとバージョンを記述して 問題を報告すると，パッケージの問題が気づいたら解決されたりされなかったりする 便利なシステム． BTSに関しては，あらゆる記録が完全に公開されているという点がDebianらしいところ． BTSシステムにメールで問題を登録することを「BTSする」と表現したりする． 問題にはそれぞれ深刻さなども定義できて，その深刻さなどについて日夜議論がなされていたりしそうだ． 理想としては，問題を放置しないで，うまく処理するシステムが必要なのだが，現状としては， 古い問題がBTSに放置されていたりして，見通しが悪くなっているのが，問題，かな？
07:56:11 # Life 無敵会議番外編，SNS会議に入ってきた． 韓国のSNSサイトが韓国で一番みられているサイトだというのが凄い． 検索エンジンよりも利用されているらしい． 機能的，用途的に考えるとSNSは十分１位になる素質はあるのかもしれない． ウェブサーバに負荷がかかりまくるので，頁をロードするのに30秒かかるというのは面白い． 平均２時間，多い人で一日１８時間つかっているというのにも苦笑．
日本人も検索ばっかりしていないで腰をおちつけてみろ，という示唆だろうか？
13:30:32 # Life Debian/ibookでのxineの再生はALSAではなくOSSにしたらうまくいくらしい． 何故だ？ALSAのオーバヘッドが大きすぎるのか？
07:51:22 # Life hygrogenを使ってドラムパターンを作ってみる． 結構簡単だ． これにecasoundをかぶせてレコーディングの練習をしてみる．．．
20:11:35 # Life 今日のecasoundセッションのメモ． ecanormalizeは結構使える気がする． hydrogenのドラムパターンは良い．
ecasound -i:alsahw,2,0,0 -o:alsahw,0,0,0 -z:nointbuf ecasound \ -a:rec,1 -i alsahw,2,0,0 \ -a:m -i null -pn:metronome,70 \ -a:1,m -o alsahw,0,0,0 \ -a:rec -o 1.wav -z:nointbuf ecasound \ -a:rec,1 -i alsahw,2,0,0 \ -a:m -i dr1.wav \ -a:1,m -o alsahw,0,0,0 \ -a:rec -o 1.wav -z:nointbuf ecasound \ -a:rec,1 -i alsahw,2,0,0 \ -a:m -i dr1.wav \ -a:1,m -o alsahw,0,0,0 \ -a:rec -o 1.wav -z:nointbuf ecasound \ -a:rec,2 -i alsahw,2,0,0 \ -a:m -i dr1.wav \ -a:1 -i 1.wav \ -a:1,2,m -o alsahw,0,0,0 \ -a:rec -o 2.wav -z:nointbuf ecasound \ -a:rec,3 -i alsahw,2,0,0 \ -a:m -i dr1.wav \ -a:2 -i 2.wav \ -a:1 -i 1.wav \ -a:1,2,3,m -o alsahw,0,0,0 \ -a:rec -o 3.wav -z:nointbuf ecasound \ -a:rec,4 -i alsahw,2,0,0 \ -a:m -i dr1.wav \ -a:3 -i 3.wav \ -a:2 -i 2.wav \ -a:1 -i 1.wav \ -a:1,2,3,4,m -o alsahw,0,0,0 \ -a:rec -o 4.wav -z:nointbuf ecasound \ -a:rec,4 -i alsahw,2,0,0 \ -a:m -i dr1.wav \ -a:3 -i 3.wav \ -a:2 -i 2.wav \ -a:1 -i 1.wav \ -a:1,2,3,4,m -o alsahw,0,0,0 \ -a:rec -o 4.wav -z:nointbuf ecasound \ -a:rec,4 -i alsahw,2,0,0 \ -a:m -i dr1.wav \ -a:3 -i 3.wav \ -a:2 -i 2.wav \ -a:1 -i 1.wav \ -a:1,2,3,4,m -o alsahw,0,0,0 \ -a:rec -o 4.wav -z:nointbuf ecasound \ -a:rec,5 -i alsahw,2,0,0 \ -a:m -i dr1.wav \ -a:4 -i 4.wav \ -a:3 -i 3.wav \ -a:2 -i 2.wav \ -a:1 -i 1.wav \ -a:1,2,3,4,5,m -o alsahw,0,0,0 \ -a:rec -o 5.wav -z:nointbuf ecasound \ -a:rec,5 -i alsahw,2,0,0 \ -a:m -i dr1.wav \ -a:4 -i 4.wav \ -a:3 -i 3.wav \ -a:2 -i 2.wav \ -a:1 -i 1.wav \ -a:1,2,3,4,5,m -o alsahw,0,0,0 \ -a:rec -o 5.wav -z:nointbuf ecasound \ -a:rec,6 -i alsahw,2,0,0 \ -a:m -i dr1.wav \ -a:5 -i 5.wav \ -a:4 -i 4.wav \ -a:3 -i 3.wav \ -a:2 -i 2.wav \ -a:1 -i 1.wav \ -a:1,2,3,4,5,6,m -o alsahw,0,0,0 \ -a:rec -o 6.wav -z:nointbuf ecasound \ -a:rec,6 -i alsahw,2,0,0 \ -a:m -i dr1.wav \ -a:5 -i 5.wav \ -a:4 -i 4.wav \ -a:3 -i 3.wav \ -a:2 -i 2.wav \ -a:1 -i 1.wav \ -a:1,2,3,4,5,6,m -o alsahw,0,0,0 \ -a:rec -o 6.wav -z:nointbuf ecasound \ -a:rec,6 -i alsahw,2,0,0 \ -a:m -i dr1.wav \ -a:5 -i 5.wav \ -a:4 -i 4.wav \ -a:3 -i 3.wav \ -a:2 -i 2.wav \ -a:1 -i 1.wav \ -a:1,2,3,4,5,6,m -o alsahw,0,0,0 \ -a:rec -o 6.wav -z:nointbuf ecasound \ -a:rec,6 -i alsahw,2,0,0 \ -a:m -i dr1.wav \ -a:5 -i 5.wav \ -a:4 -i 4.wav \ -a:3 -i 3.wav \ -a:2 -i 2.wav \ -a:1 -i 1.wav \ -a:1,2,3,4,5,6,m -o alsahw,0,0,0 \ -a:rec -o 6.wav -z:nointbuf ecasound \ -a:rec,6 -i alsahw,2,0,0 \ -a:m -i dr1.wav \ -a:5 -i 5.wav \ -a:4 -i 4.wav \ -a:3 -i 3.wav \ -a:2 -i 2.wav \ -a:1 -i 1.wav \ -a:1,2,3,4,5,6,m -o alsahw,0,0,0 \ -a:rec -o 6.wav -z:nointbuf ecasound \ -a:rec,6 -i alsahw,2,0,0 \ -a:m -i dr1.wav \ -a:5 -i 5.wav \ -a:4 -i 4.wav \ -a:3 -i 3.wav \ -a:2 -i 2.wav \ -a:1 -i 1.wav \ -a:1,2,3,4,5,6,m -o alsahw,0,0,0 \ -a:rec -o 6.wav -z:nointbuf ecasound \ -a:6 -i 6.wav \ -a:m -i dr1.wav \ -a:5 -i 5.wav \ -a:4 -i 4.wav \ -a:3 -i 3.wav \ -a:2 -i 2.wav \ -a:1 -i 1.wav \ -a:1,2,3,4,5,6,m -o alsahw,0,0,0 -z:nointbuf ecasound \ -a:6 -i 6.wav \ -a:m -i dr1.wav \ -a:5 -i 5.wav \ -a:4 -i 4.wav \ -a:3 -i 3.wav \ -a:2 -i 2.wav \ -a:1 -i 1.wav \ -a:1,2,3,4,5,6,m -o alsahw,0,0,0 ecasound \ -a:6 -i 6.wav \ -a:m -i dr1.wav \ -a:5 -i 5.wav \ -a:4 -i 4.wav \ -a:3 -epp:40 -i 3.wav \ -a:2 -epp:90 -i 2.wav \ -a:1 -epp:10 -i 1.wav \ -a:1,2,3,4,5,6,m -o alsahw,0,0,0 ecasound \ -a:6 -epp:50 -i 6.wav \ -a:m -i dr1.wav \ -a:5 -epp:10 -i 5.wav \ -a:4 -i 4.wav -epp:90 \ -a:3 -epp:40 -i 3.wav \ -a:2 -epp:90 -i 2.wav \ -a:1 -epp:10 -i 1.wav \ -a:1,2,3,4,5,6,m -o alsahw,0,0,0 ecasound \ -a:6 -etc -epp:50 -i 6.wav \ -a:m -i dr1.wav \ -a:5 -epp:10 -i 5.wav \ -a:4 -i 4.wav -epp:90 \ -a:3 -epp:40 -i 3.wav \ -a:2 -epp:90 -i 2.wav \ -a:1 -epp:10 -i 1.wav \ -a:1,2,3,4,5,6,m -o alsahw,0,0,0 ecasound \ -a:6 -etc -epp:50 -i 6.wav \ -a:m -i dr1.wav \ -a:5 -epp:10 -i 5.wav \ -a:4 -i 4.wav -epp:90 \ -a:3 -epp:40 -i 3.wav \ -a:2 -epp:90 -i 2.wav \ -a:1 -epp:10 -i 1.wav \ -a:1,2,3,4,5,6,m -o mix1.wav
23:02:32 # Life 試してみる． supercollider，使いかた分からん． いろいろとwebを調べてみるも，returnではなく，enterキーをおせとか，MAC風のことしか書いていないので挫折． zynaddsubfx，まぁ，つかいなれているが，こっからecasoundで録音するのは難しそう． noteedit．．．
qjackctlをはじめて使ってみたが，コマンドラインを考えるよりよっぽど視覚的にできるので よいかも． デフォルトではzynaddsubfx は何も接続していない状態で起動してしまうので．．． 下記の状況は厳しかった．おとがきれている．
jackd -d alsa -d usb -s qjackctl zynaddsubfx -r 48000 ecasound -i:jack_auto,ZynAddSubFX -o:jack_alsa
下記のコマンドをうってモニターしながらキーボードを演奏しようとすると，マシンがすげえ遅くなる． というか，死ぬまでSWAPしまくって ecasound が落ちる．
ecasound -a:1 -i resample,mix1.wav -a:2,r -i:jack_auto,ZynAddSubFX -a:1,2 -o:jack_alsa -a:r -o key2.wav -z:nointbuf
museが使えそうな気がするので，ちょっと触ってみる． うーん，どうなんだろう．．．
07:33:49 # Life メールのRSSフィード. なにげなくDebian Weekly Newsを読んでいたら， gmaneでDWNが読めますよ，という記事があった． gmaneのRSSとBLOGフィードについて初めて知った． メールをRSSで配信するというのは発想の逆転っぽくてなんとも面白い． すげぇ便利． 下記例：
07:38:54 # Life カーネルのどの部分が一番ボトルネックか，というパフォーマンスを計測するには， /proc/profileを利用して，kerneltopを使えばだいたいわかる気がする． 各バージョンにおいてどうCPUの使用頻度が変わったかという傾向をみたらざっくりとした 手がかりになるのではないだろうか？
それに対して，oprofileはもっと全体的な機構のよう． カーネルに限定せずにユーザランドまで見ているようだ． ただ，通常の割り込みを使っているわけではないので，そこが各アーキテクチャ依存になってくるようだ．
08:09:51 # Life sted2 再来．久しぶりに手うちで音楽をいれてみようとsted2でグーグル検索してみたら， sted2がzaurus上で動作しているという報告があった． すげえ． sted2/zaurus
とりあえず久しぶりにsted2, timidity, freepatsをインストールしてみた．
ドラムパターンを作るためにhydrogenをインストールしてみる．
$Id: 200412.html.ja,v 1.30 2005/02/02 17:23:38 dancer Exp $