Linux-Mandrake 8.0 がリリースされた。詳細は website. で。ハイライトは、KDE 2.1.1, GNOME 1.4, Kernel 2.4.3, Xfree86 4.0.3, とAnti-aliasing.。プロジェクトへの寄付は、 http://www.linux-mandrake.com/donationsへどうぞ。
Progeny Debian が出た out 。 ダウンロード版は既に入手可能で available、ボックス セットは4月23日から販売中。 Progeny CEO 兼社長のIan Murdock,and が言うには別のLinux配布を考えておらず「これは全社を挙げて開発したDebianの強化版で必ずユーザーの役に立つ」と。
Red Hat はRed Hat Linux 7.1 with 2.4 kernel. を発表。新特徴の全容は Red Hat webサイト new features.で。
Slackware の継続を望む人は PayPal 勘定を通じて paypal@slackware.com に寄付されたい。
Newlix Corporation はLinuxサーバーアプリケーション用に新規管理ソリューションを開発した。Newlixサーバーウエアは開発者によれば「全ITをサーバーに取り込んだように見える」優れた管理エンジンだ。サーバー申し込みの機能性と使用容易性の改善を目的とする。詳細は Newlix Webサイトで available 。
● eCluster インターネットサーバーClustering
XGforce からのeCluster は、1024組のインターネットクラスタグループにクラスタ出来て、各クラスタが1024個のクラスタノードを含む(1024X1024)ことの出来るクラスタシステムである。往復通信時間負荷平衡アルゴリズムを用いて、任意のCPU上の任意のOSをクラスタすることが出来る。SQLデータベースサーバーの事務用転送の無停止で迅速な転送を保証する負荷平衡とフェールセーフモードをサポートする。
CPU負荷、加重負荷、vm利用率、往復時間などの負荷平衡アルゴリズムを使用する。ネットワーク通信量配分、フェールセーフ、CFSなどが利用出来るなどの特徴がある。詳しくはXGforce website へ。
● ActiveState が ASPN イニシャティブを開始
オープンソース技術を用いるプログラミングを可能にする新規イニシャティブをActiveStateが開始した。ActiveState Programmer Network (ASPN) には、Perl、Python 、Tcのバイナリ配布、多国語、多プラットホームIDE、技術参考書、サンプルコード、レシピなどが含まれる。詳細は ASPN website.へ。
● OTGソフトウエア
OTG Software は Smart Storageの取得を発表した。OTGはメディア市場への早期参入、国際化、UNIX及びLinuxでのデータ記録入手のソリューションのためStorageの CD/DVD に期待している。
OTGはまた、BMC Software のアプリケーション集中記憶管理コンソーシアム ( ACSM)への参加を発表した。これは、会員に市場開発、顧客サービス、市場拡張の機会を与える会員制プログラムである。
The Duke of URL は以下のリンクを用意している：
The linux-kernel mailing list FAQを参照すると on-list.に何が起こっているか良く解る。
SlashDot は以前に次のリンクを提案した：
Bryan Pfaffenberger が Why Open Content Matters について Linux Journal web カラム " Currents"に書いている。
Microsoft Office ヘルプクリップの最新技術セクター redundancy も良い。
最後に、厳密にLinuxではないが、 UnixSpace.com がConteXtデータベースサーバーへの無料オンラインインターネットアクセスservice を発表した。データベース構築に主眼をおいた30Mbシェルコマンド行とGUI処理を含む。
Open SSH はそのソフトウエアのバージョン2.5.2を発表した。OpenSSH はrlogin とtelnetに代えssh、rcpに代えscp及び、ftpに代え sftp を含む。パケージサーバー側のsshd及びssh-add、ssh-agent、ssh-keygen、sftp−サーバーのような基本ユティリティを含む。OpenSSHはバージョン1.3、1.5、2.0をサポートする。セキュリティは無視出来ない。
Cylant Technologyは、既知未知の攻撃に対する侵入防御システム、Linux用CylantSecureをリリースした。 システム防御に修正kernelをカスタムkernelと共に用いる。他のIDS製品と異なり、CylantSecureは攻撃識別に、既存データベースに依存するルールやパターンを用いない。実際のソフトウエア行動に焦点を当てて公称システム行動の構造的モデルを構築する。コンピュータが行動解析をして攻撃を識別する。詳細はpress release.へ。
●ICS はテーマをOpen Motifに統合
Integrated Computer Solutions は、テーマをOpen Motifに加えるイニシャティブの開発者リリースを発表した。テーマはLinuxと共に提供されデスクトップに独特の概観を与える能力である。Open Motif用テーマはGnome用に作られたGTKと共に働く。今はOpen Motifが扱えるフォーマットに人手で転換されているが、自動的に出来るようになる。ICS はこの計画を助ける開発者を募集している。詳しくはICSフォーラムwebsite.へ。
● インターネット交換メッセージ・サーバー５
International Messaging Associates は最新製品nternet Exchange Messaging Server 5 (IEMS 5)のベータ版を立ち上げた。IEMS 5は分散計算環境をサポートし、LinuxとWindows混合プラットホーム上で働く。「現在のところ若干のLinux上で働いている」と言う。これらにはRedHat, SuSE, VALinux, Turbo Linux, Caldera, Mandrakeなどが含まれる。この製品はユーザーが Internet Exchange Web Mail Clientと同時にMicrosoft Outlook, Netscape Navigator, Eudora Mailのような POP3 又はIMAP4を使うクライアントを経由してメイルボックスにアクセス出来るようにする。
IEMS 5 のコピイはhttp://www.ima.com/download/v5eval.htmlで入手出来る。製品概観もダウンロード downloaded出来る。今ならUS$300（約30%）割引価格で入手出来る。
●その他のソフトウエア
Better Access Networking がLinux用Teamware Office 5.3 につきベルギーのTeamware's新規販売協力者となった。Teamware はスエーデンの Coresys AB とも協力提携をした。最新ニュースは newsletter.を。
Python 2.1,と互換性のある新版 Mailman, 2.0.4が出た。LWN に記事 story.
Insignia が最近の埋め込みシステムコンファレンスを協賛する。詳細は online.
今月の新連載ウイークエンドメカニックにようこそ。実はこのコラムは1996-1998にJohn M Fisk が書いていたので、新規ではないのだが、将来の読者のために書き直す。
ウイークエンドメカニックは、Linuxの経験と問題解決を毎月読者と一緒に行う。話題を以下に絞る。
Linuxを使う多くの人が、致命的な間違いをする恐れのあるコマンド行ではなくGUIのみに頼ろうするが、シェル環境をカスタム化するにはコマンドをタイプが必要な場合がある。そこでこの記事ではAliases, editors, shells, などの特性を望み通りにするため、 login shell をカスタム化する方法を述べる。
先ず、適当なエディタを選ぶ。emacs, joe, jed, pico, viなど色々あるが、エディタを決めたら（筆者はPico とJedを使用）シェルに使用を告げる。Cronのようなプログラムはエディタ設定を有するシェルに依存するのでcrontabをエディットすることが出来る。
ホームディレクトリに .bashrcと .bash_profileとして置かれた二つのファイルがある。私の .bashrc ファイルは次のように始まる：
# User specific aliases and functions alias ls='ls -o --color=auto' alias cad='cat /var/squidGuard/db/blacklist/adverts' alias cc='cd /mnt/cdrom/Mandrake/RPMS' alias mail='mail -v' alias rm='rm -i' alias cp='cp -i' alias mv='mv -i' alias d='ls' alias s='cd ..' alias p='cd -'
Aliasesは、例えば、cd /var/spool/users/home/mail/root/sun のような長いコマンドをタイプするとき、有用だ。全部タイプする代わりに"shortcut" を規定することが出来る。
cd /var/spool/users/home/mail/root/sun コマンドの代わりに "checkmail" の語を使うことをシェルに告げる。リストに次を加える：
alias checkmail='cd /var/spool/users/home/mail/root/sun'
alias eamcs='emacs' alias emcas='emacs'
次のセクションは、走らせるプログラムをシェルに告げる方法だ。私の.bash_profile ファイルには、以下が入っている：
PATH=/sbin:/usr/sbin:/bin:/usr/bin:/usr/X11R6/bin ENV=$HOME/.bashrc USERNAME="root" export USERNAME ENV PATH
これは変数設定を集中するセクションだ。設定されていない共通変数は、現在ログイン中のユーザーに共通の変数でユーザー毎に違う値を規定する "EDITOR" と"MAIL"などだ。
変数 EDITOR は、
export USERNAME ENV PATH EDITOR
変数をエキスポートすると、それを単一プログラムに閉じこめるのでなく、環境に開放する。エキスポートにより各種プログラムが同一変数を同一値で使用出来る。
"export" リストを加えたら、ファイルをセーブしてエディタを出る。新変数を規定したので、Bashに告げる。それにはファイルを"source" しなければならない。ファイルを再読取するのはbash builtin で、これを二つの方法のうち一つでタイプする。
source filename
これで新付加変数が働くようになる。これでここは終わり。
一日中同じことを繰り返して自動化出来ないかと考えたことがあるだろう。Mr. Cron がそれをやってくれる。
Cronは、daemonと呼ばれるスケジュールプログラムだ。daemonはバックグラウンドで命令を待ちながら走るプログラムだ。命令があれば実行し、終わると眠る。
Cronは、ランレベルに切り換えると、スタートするが、スタートするだけだ。
ps ax | grep crond
のコマンドを入れたとき：
root 311 0.0 0.7 1284 112 ? S Dec24 0:00 crond root 8606 4.0 2.6 1148 388 tty2 S 12:47 0:00 grep crond
のように応答したら、cronはスタートしているので使える。"crond" が返らないときは
crond
とタイプしてdaemonをスタートしなければならない。
Cronはバックアップと一般メンテナンスが必要なとき、特に有用だ。Cronにプログラムスタート時期を告げるには、幾つかのフィールドを見たさなければならない。Cronを通じてスケジュールされた別個の各プログラムは crontab と呼ばれるファイルの収容される。フィールドは次のように定義される。
Min Hour DOM Month DOW User Cmd
その入力値の説明を次表にまとめる
| FIELD | DESCRIPTION |
| Min |
時間以後の経過分を示す 数値は0 から 59. |
| Hour |
プログラムを走らせる時刻２４時制で示す数値は0 から 23 "0" は深夜 |
| DOM |
コマンドを走らせる日付を規定、例えば 毎月23日にコマンドを走らせるなら DOMは23となる |
| Month |
1から12の範囲でスクリプトを走らせる月を規定。月の最初の3文字例えばMayと記しても良い。 |
| DOW |
0から7で、曜日を規定（0と7は共に日曜日）Monなど３文字で記してもよい。 |
| User | コマンドを走らせる人を規定。 |
| Cmd | 走らせるscript/program のパスと名称 |
時間フィールドの何れででも"*" (""なしで)を用いて「毎分」「毎時」などをあらわすことが出来る。 上の説明を頭におくと、次の例は有効である。
01 * * * * root /usr/bin/script "このコマンドは毎時１分過ぎに実行" 17 8 * * * root /bin/mail "このコマンドは毎日 8:17 amに実行" 17 20 * * * root /usr/bin/fetch "このコマンドは毎日 8:17 pm に実行" 00 4 * * 0 root /bin/qweb "このコマンドは毎日曜日 4 am に実行" * 4 * * Sun root /usr/bin/file2rpm "このコマンドは毎日曜日 4 am に実行" 42 4 1 * * root /usr/bin/squidlog "このコマンドは毎月１日に4:42 am に実行" 01 * 19 07 * root /usr/bin/xman "このコマンドは7月19日に毎時実行"
Cronはまたこれらの説明に、run "man 5 crontab" と言う簡潔な時間規定も受け付ける。
Cron登録を書く場所はまだ説明していないが、一寸待て。
Linuxシステムに搭載されるCronの最も普通のバージョンは"vixie-cron"なので、 "/etc"フォルダは"crontab"ち言う名になっている。環境変数EDITOR（上記を参照）を定義していれば、簡単に
crontab -e
とタイプすれば、ファイルがテキスト・エディタにロードされる。
上述のコマンドを用いて開いていないときは、選んだテキスト・エディタを使って開くか、又は次のようなものを探す。
SHELL=/bin/bash PATH=/sbin:/bin:/usr/sbin:/usr/bin MAILTO=root@grangedairy.linux HOME=/ # run-parts 01 * * * * root run-parts /etc/cron.hourly 02 4 * * * root run-parts /etc/cron.daily 22 4 * * 0 root run-parts /etc/cron.weekly 42 4 1 * * root run-parts /etc/cron.monthly
SHELL 変数は、使用中のシェルを示す
PATH は、最も共通のプログラムへのパスを示す
MAILTO オプションは、Cron結果（働こうが働くまいが）及びプログラム出力を送るべき相手先を示す。面倒ならこの変数を省いてもよい。
"#runparts" 以下の部分は、例えば、フォルダー "/etc/cron.daily" にどんなスクリプトがあろうが毎日実行するのように働くことを想定しているが、何かの理由で全く働かなかった。そこで、私自身のCronリストを規定するのが簡単だと考えた。
上述の例を私のcrontabに加えには、コピイして渡すだけだ。
SHELL=/bin/bash PATH=/sbin:/bin:/usr/sbin:/usr/bin MAILTO=root@grangedairy.linux HOME=/ # run-parts 01 * * * * root run-parts /etc/cron.hourly 02 4 * * * root run-parts /etc/cron.daily 22 4 * * 0 root run-parts /etc/cron.weekly 42 4 1 * * root run-parts /etc/cron.monthly #Custom Crontabs -- Put in by Thomas Adam 01 * * * * root /usr/bin/script 17 8 * * * root /bin/mail 17 20 * * * root /usr/bin/fetch 00 4 * * 0 root /bin/qweb * 4 * * Sun root /usr/bin/file2rpm 42 4 1 * * root /usr/bin/squidlog 01 * 19 07 * root /usr/bin/xman
続いて、ファイルをセーブする。最後になすべきことは、ファイルをエディットしたことをCronに告げることだ。これは次のコマンドで行う：
crontab -u root /etc/crontab
このまま黙って待っていれば、君の仕事量は25%位減る筈だ。
Cronはまた、Cronのユーザーを選ぶことが出来る。これを行うには、フォルダー"/etc"にcron.allow とcron.deny の二つのファイルを作る。Cronを誰にも使わせたくないなら、cron.denyファイルに "ALL" の行を加える。許す人の名を cron.allow ファイルに加える。
ファイルを毎回エディットするのでなく、次のコマンドを使う方が遙かに簡単だ。
cat username >>/etc/cron.allow
今月はここまでです。この記事に対するご意見や、ご忠告などをお待ちしています。Linuxを少しでも良くしたいと思っています。
#!/usr/bin/perl
# ftp://ftp.tardis.ed.ac.uk/users/ajcd/psutils.tar.gz
# http://www.dcs.ed.ac.uk/home/ajcd/psutils/
# cp Makefile.unix Makefile
# ln -s /usr/bin/perl /usr/local/bin/perl
# mkdir -p /usr/local/share/man/man1
# /usr/local/bin/psbook
#system ("lynx --source ftp://ftp.tardis.ed.ac.uk/users/ajcd/psutils.tar.gz > /tmp/psutils.tar.gz)";
# system ("cd /tmp; tar -zxvf psutils.tar.gz; cd psutils; cp Makefile.unix Makefile");
# system ("ln -s /usr/bin/perl /usr/local/bin/perl; mkdir -p /usr/local/share/man/man1");
# system ("cd /tmp/psutils; make; make install; ln -s /usr/local/bin/psutils /usr/bin/psutils");
# Ignore the lines above, unless you don't have psutils.
# I keep the lines above just so I remember how I installed psutils.
my $TempFile1 = "/tmp/HOWTO_Convert_1.ps";
my $TempFile2 = "/tmp/HOWTO_Convert_1.pdf";
my $SourceDir = "/root/HOWTO";
my $Destination = "/root/HOWTO_Books";
my $ZippedPDF = "/root/HOWTO_books_pdf.tgz";
my $ZippedPS = "/root/HOWTO_books_ps.tgz";
if (!(-d $Destination)) {system "mkdir $Destination";}
print "Downloading HOWTOs from http://www.ibiblio.org/pub/Linux/docs/HOWTO/other-formats/ps/Linux-ps-HOWTOs.tar.gz\n";
system ("lynx --source http://www.ibiblio.org/pub/Linux/docs/HOWTO/other-formats/ps/Linux-ps-HOWTOs.tar.gz > $SourceDir/Linux-ps-HOWTOs.tar.gz");
system ("cd $SourceDir; tar -zxvf Linux-ps-HOWTOs.tar.gz");
my @Files = <$SourceDir/*.ps.gz>;
foreach my $File (@Files)
{
my $command="gunzip -c $File | /usr/bin/psbook -s4 | mpage -2 > $TempFile1";
print "Executing psbook and mpage on $File\n$command\n";
system ($command);
$command = "ps2pdf $TempFile1 $TempFile2";
print "Executing ps2pdf\n$command\n";
system ($command);
my (@Temp) = split(/\//,$File);
my $NamePDF = pop @Temp;
my $NamePS = $NamePDF;
$NamePDF =~ s/\.ps\.gz$/\.pdf/;
$NamePS =~ s/\.ps\.gz$/\.ps/;
my $NewPS = "$Destination/$NamePS";
my $NewPDF = "$Destination/$NamePDF";
system ("mv $TempFile2 $NewPDF");
print "Created the book-formatted HOWTO, $NewPDF\n";
system ("mv $TempFile1 $NewPS");
print "Created the book-formatted HOWTO, $NewPS\n";
}
print "Creating zip files $ZippedPDF and $ZippedPS\n";
system ("tar -zcvf $ZippedPDF $Destination/*.pdf");
system ("tar -zcvf $ZippedPS $Destination/*.ps");
初期ステップ
追加の３ステップ
Browser=true SetPosition=true PositionX=100 PositionY=100 Exclude=bin,daemon,adm,lp,sync,shutdown,halt,mail,news,uucp,operator,nobody,gdm,postgres,pvm,otherlogin GlobalFaceDir=/usr/share/faces/
#!/bin/sh /usr/X11R6/bin/xsetroot -solid "#363047" xsri -geometry +5+5 /etc/X11/xdm/Logo2.png xsri -geometry +400+5 /home/mark/public_html/wedding/wed2.jpg xsri -geometry +700+500 /home/mark/public_html/wedding/walk.jpg xsri -geometry +200+500 /home/mark/public_html/wedding/kiss.jpg xsri -geometry +5+175 /home/mark/public_html/kiss.gif xsri -geometry +5+500 /usr/local/apache_gnujobs/htdocs/images/zing.png xeyes -geometry +825+5 & xclock -digital -geometry +825+125 -update 1 & xtriangles -geometry +800+300 &
cp /usr/local/apache_gnujobs/htdocs/images/zing.png /usr/share/faces/root
KDMとGDMと比べたいが、KDMのWebを見付けるのは難しい。
CVS はソース・ファイルの履歴を記録するversion control システムである。多人数で同一プロジェクトを開発するとき、各人が同一コードを分担するのに役立つ。コードは中央サーバーに存在し、各人はCVSサーバーからコードを受け取って（チェックアウト）、開発の後CVSサーバーに戻す（チェックイン）。新コードをチェックインすると、相違は上書でなく新版としてセーブされる。これによりサーバーは、必要あれば旧版を再生するが、規定値では最新版を配布する。この記事は、CVSの効果的使用方法を説明する。
CVS は http://www.cvshome.org/downloads.html からLinuxに取り入れる。
CVS のホームペイジは http://www.cvshome.org/.
CVSレポジトリは、あらゆるファイルを記憶するが、通常はレポジトリに直接アクセスしないで、CVSコマンドを使ってファイルのコピイを自分の作業ディレクトリに入手して作業する。変更作業を終えてレポジトリに返すと、レポジトリは、あらゆる変更その他の情報を記憶する。
レポジトリの作成
レポジトリを作るにはCVS initコマンドを走らせる。すると、通常の方法で規定されたCVS rootに空のレポジトリが設定される。
cvs -d /usr/local/cvsroot init
ここで /usr/local/cvsroot がレポジトリになる。
CVSROOT 環境変数
CVSROOT環境変数をシェルスタートアップスクリプト、例えば~/.bashrc、に設定する。
$ export CVSROOT=:pserver:username@foo.com:/usr/local/cvsroot
レポジトリのバックアップ
レポジトリのバックアップをするとき考える問題が少しある：
リモート・レポジトリ
ソースの作業用コピイが、レポジトリでなく異なるマシン上にある方法でCVSを使うのはクライアント／サーバー・オペレーションと呼ばれる。
サーバーの設定：
以下の入力をサーバー上の in /etc/inted.conf に入れる：
2401 stream tcp nowait root /usr/local/bin/cvs cvs -f --allow-root=/usr/cvsroot pserver
inetdが生のポート番号でなく、シンボリック・サービス名を要求するときは、次を`/etc/services' に入れて、
cvspserver 2401/tcp
`inetd.conf ' には2401の代わりに cvspserver を入れる。
変更の後、HUP信号をintedに送る。
リモート・レポジトリのためのパスワード変更
リモート・パスワード認証にはファイル`$CVSROOT/CVSROOT/passwd' を置く。このファイルは次のようである。
anonymous:
kapil:1sOp854gDF3DY
melissa:tGX1fS8sun6rY:pubcvs
パスワードはUnix暗号化形式である。例の１行目は、パスワードに関係なく匿名(anonymous)のCVSクライアントにアクセスを与える。２行目と３行目は、それぞれの平文パスワードを与えたときkapilへのアクセスを与える。
３行目は正しいパスワードを与えたときmelissaへのアクセスを与えるが、CVS操作は実際はシステムユーザーpubcvsの下でサーバーサイドで働く。
注記： CVS `config' file ($CVSROOT/CVSROOT/config) 中でSystemAuth=no と設定すると、CVSは、CVS認証のためUNIXリアルパスワードファイル /etc/passwd を点検しない。
パスワードを用いるクライアントが使う
最初にCVSサーバーにログインしなければならない。
cvs -d :pserver:kapil@foo.com:/usr/local/cvsroot login
これでCVSコマンド全てをリモートマシン上で使うことが出来る。
cvs -d :pserver:kapil@foo.com:/usr/local/cvsroot checkout someproj
読取専用レポジトリ・アクセス
パスワード認証サーバー使用者に読取専用アクセスを与えることも可能である。「包含」と「除外」の二つの方法がある。「包含」はユーザーを`$CVSROOT/CVSROOT/readers'ファイルに含むことで、これはユーザーの新らしい行で分けたリストである：
kapil
yogesh
john
(新しい行を最後のユーザーの後に加えることを忘れないこと)
「除外」は書込アクセスの出来る者のリストを作ることである。ファイル$CVSROOT/CVSROOT/writersがあると、リストにあるもののみ書き込みが出来て、その他のものは読取専用となる。`writers' ファイルと`readers' ファイルは同一形式である。
レポジトリ内のファイル設定
CVSに搭載したいファイルが `someproj'であり、レポジトリ内に`$CVSROOT/someproj'としてあらわしたいとすると、
$ cd someproj
$ cvs import -m "Imported sources" someproj vendor
rel1-1
とする、ここで文字列`vendor' はベンダータグで、 `rel1-1' はリリースタグである。
レポジトリ内のCVS ロック
レポジトリ内の名が`#cvs.rfl.' で始まるファイルは全て読取ロックで、`#cvs.wfl' で始まるファイルは書込ロックである。ディレクトリ`#cvs.wfl' はマスターロックの役をする。つまりその他のロックを作る前に、このロックを得なければならない。
読取ロックを得るには、先ず`#cvs.lock' ディレクトリを作る。既にあれば、少し待ってからやり直す。与える情報（例えば、ホスト名、プロセス識別番号など）に続いて `#cvs.rfl.' と言う名のファイルを作る。続いて`#cvs.lock' ディレクトリを削除してマスターロックを解除する。続いてレポジトリ読み込みを続ける。終わったら`#cvs.rfl'ファイルを削除して読取ロックを解除する。
書込ロックを得るには、先ず`#cvs.lock' ディレクトリを作る。次いで`#cvs.rfl.'で始まる名のファイルがないことを確かめる。あれば`#cvs.lock'を除去して少し待ち、やり直す。読者がいなければ、前と同じようにして `#cvs.wfl' と言う名のファイルを作る。`#cvs.lock' を保留して、レポジトリ書込を続ける。終わったら `#cvs.wfl' ファイル続いて`#cvs.lock' ディレクトリを削除する。
CVS内のタグを使うシンボリック改訂
最新ソフトウエアリリースのリリース識別番号はCVSの改訂と異なる。改訂番号は二つのリリースの間で数回変更される。ファイルの改訂版にシンボリック名を与えるのにタグコマンドを使うことが出来る。
タグ付与には作業ディレクトリを変更して次のコマンドを発行する。
$ cvs tag rel1-1 file.c
このコマンドはファイルに改訂1.1としてファイルに "file.c" のタグを付ける
$ cvs tag rel1-1 .
このコマンドは現行ディレクトリの全てのファイルに繰り返し改訂1.1のタグを付ける。
ファイルの持つタグ全てを見るためステータスコマンドに`-v' フラグを付けて、次のコマンドを出すとどの改訂番号をあらわすかを見ることが出来る
$ cvs status -v file.c
次のコマンドを使うとモジュールの何れの改訂も点検することが出来る。
$ cvs checkout -r rel1-1 module1
ここで "module1" はモジュール名である。-r フラグは checkout オプションとともに、モジュール`module1'の改訂１．１をしたソースの復旧を将来いつでも容易にする。
ファイル・ステータス
CVSステータスコマンドを用いて、ファイルのステータスを得ることが出来る。
$ cvs status [options] files
ファイルを更新する
ファイルを更新又は合併するには、updateコマンドを使う。これは作業用コピイに他人が行った変更取り込む。更新に際して自分の修正は変更されない。改訂がないと更新はなにの作用もしない。ファイルを編集すると、新版が利用出来、CVSは全ての変更を作業用コピイに取り込む。
衝突の解決
同一ファイルの違う場所に二人が同時に変更を加えると、CVSは変更自体を合併するが、同じ場所であると、CVSは最終結果が判らず「衝突」が起こる。衝突は、一人が変更したとき、２番目の開発者がCVS更新をして変更結果を受け取らずに、変更しようとしたとき起こる。解決には数時間、時には数日かかるので、ここでソース衝突を解説する。
変更又はプロジェクト付加した全てのファイルを自動的にアプロードするため cvs commit コマンドを入力するとき、CVSレポジトリサーバーは、ローカルにエディットしたファイルが更新されていないか、たの開発者がレポジトリに新版をアプロードしているファイルを手動で合併する必要があるか、を知らせる。CVS commit プロセスで出る警告メッセージは次のようである。
$ cvs commit
cvs commit: Examining .
cvs commit: Up-to-date check failed for `andy.htm'
cvs commit: Up-to-date check failed for `sample.htm'
cvs commit: Up-to-date check failed for `index.htm'
...
cvs [commit aborted]: correct above errors first!
自分のローカルコピイをレポジトリの最新版に更新するにはcvs update コマンドを使う。作業用コピイ全部を更新するには、コマンドプロンプトを開いて、開発中プロジェクトを含むディレクトリに変更し、次のコマンドを送る。
$ cvs update
これで最後にCVSレポジトリからコピイして以来変更された全てのファイルが自動的に合併される。テキストファイル（HTMLファイルなど）が自動的に行毎に更新される。手動エディットと合併が必要なファイルがあれば一覧で示す。
自動合併の例：
"index.html"と言う名のプロジェクトファイルをローカルにエディットしており、そのファイルをCVSレポジトリに預けようとしたとき、CVSは次のエラーを告げる。
$ cvs commit index.html
cvs commit: Up-to-date check failed for `index.html'
cvs [commit aborted]: correct above errors first!
これは、CVSレポジトリに同一ファイルの新版があるため起こる。cvs update コマンドを使って最新版をCVSレポジトリからローカルマシンに入手しなければならない。
$ cvs update index.html
RCS file: /usr/local/cvsroot/index.html,v
retrieving revision 1.4
retrieving revision 1.5
Merging differences between 1.4 and 1.5 into index.html
M index.htm
自動合併処理の後、合併コピイが正しく働くかを点検しなければならない。"index.html"ファイルのローカルコピイに満足したらCVSに預けることが出来る：
$ cvs commit index.htm
index.htmの点検に当たっては；
/usr/local/cvsroot/index.htm,v <-- index.htm
new revision: 1.6; previous revision: 1.5
done
手動合併の例：
場合によっては、自分の最新の作業が余り違っていて、皆の作業統合してサイトレポジトリに返すため、CVSが手動介入を必要とすることがある。
$ cvs commit index.html cvs commit: Up-to-date check failed for
`index.html' cvs [commit aborted]: correct above errors first!
ローカルコピイにサイトの更新をさせるには cvs update コマンドを用いる。
$ cvs update
cvs update: Updating .
RCS file: /usr/local/cvsroot/index.html,v
retrieving revision 1.5
retrieving revision 1.6
Merging differences between 1.5 and 1.6 into index.htm
rcsmerge: warning: conflicts during merge
cvs update: conflicts found in activity.htm
C index.htm
今回CVSはファイルを自動的に合併出来なかったので、元のindex.htmlの代わりに衝突ファイルの特別コピイを作った。このファイルは、衝突領域の始めと終わりを示すため；例えば
<<<<<<<< filename
のマーカー行を有する。衝突を解決するには、index.html を編集してマーカー間のテキストを置き換え、うまく働くまで結果を試験する。マーカーもファイルから削除しなければならない。
<<<<<<<<========>>>>>>>>
ファイルの修正と試験を終わったら、cvs commitコマンドを用いて最新コピイをレポジトリに置く。
$ cvs commit
index.html内の点検；
/usr/local/cvsroot/index.html,v <-- index.html
new revision: 1.7; previous revision: 1.6
done
監視 (CVS 通信)
CVSは記録保持と同時に通信装置の機能も果たす。"watches" 特性は同一プロジェクトで働く多数の開発者相互に、所与の時間に誰がどのファイルに作業しているかを知らせる。file/directoryに「監視設定」をすることにより、e-メイルを送るなどの方法で、そのファイルに誰かが作業を始めたことをCVSに知らせることが出来る。
watches を使うには、レポジトリ管理領域に、"$CVSROOT/CVSROOT/notify"ファイル（CVSに通知方法を告げる）と "$CVSROOT/CVSROOT/users"ファイル（外部ｅ−メイルアドレスを示す）の二つのファイルを編集しなければならない。管理ファイル修正の最良方法はレポジトリからコピイ一つを取り出して編集し、レポジトリに返すことである。
ｅ−メイル通告を規定するには、先ず"$CVSROOT/CVSROOT/notify"ファイルから次の行をアンコメントする：
ALL mail %s -s "CVS notification"
このコマンドは、通告を、題名行 "CVS notification" と共にｅ−メイルで送らせる。
次いでファイル "$CVSROOT/CVSROOT/users" を作成／編集する。ユーザーファイル内の各行のフォーマットは：CVS_USERNAME:EMAIL_ADDRESS 、例えば、
kapil:kapil@linux4biz.net である。
行頭のCVS usename は、CVSROOT/password つまりCVSを使う人のサーバー側システムusername に相当する。コロンに続くのは、監視通知を送る相手先ユーザーのｅ−メイルアドレスである。
ログファイル付きE-メイル通告
CVSは預託が生じたとき、プロジェクトで働く各人に自動化ｅ−メイルをログメッセージと共に送る機能を備えている。メイル送付プログラム−CVSソース内のcontrib/log.pl−はシステムの何処にでも置ける。"$CVSROOT/CVSROOT"に置くことも出来る。log.plの中の次の行を変更する：
$mailcmd = "| Mail -s 'CVS update: $modulepath'";
一旦 log.pl を設定すると、同様の行を “loginfo”ファイルに挿入出来る。“loginfo”ファイルは "$CVSROOT/CVSROOT"の中にあり、`cvs commit' ログ情報が送られた場所の制御に用いられる。
projectteam1 CVSROOT/log.pl %s -f CVSROOT/commitlog -m projectteam1@linux4biz.net
projectteam2 CVSROOT/log.pl %s -f CVSROOT/commitlog -m projectteam2@linux4biz.net
%s は、預託に関連するファイル名に拡張する；Log.plへの-f オプションが、ログメッセージを加えるファイル名を取り（したがってCVSROOT/commitlogは常に長くなる）、-mフラグは預託に関するメッセージを送るｅ−メイルアドレスを取る。アドレスは通常メイルリストだが、-mオプションを次のようにも定義出来る：
many times as necessary in one log.pl command line.
ファイルへのwatches設定に関する幾つかのコマンド
預託だけの情報が欲しいのであれば、-a（actionの意）フラグで通告を制限出来る。
$ cvs watch add -a commit hello.c
編集と預託は監視したいが、アンエディットは不要であれば、-aフラグを二回使う。
$ cvs watch add -a edit -a commit hello.c
watchに-aフラグを加えても既存watcheは削除されない。hello.c上の三種のアクション全部を監視してきるとき、
$ cvs watch add -a commit hello.c
を走らせても効果はなく、三種のアクション全部を監視する。
監視を削除するには：
$ cvs watch remove hello.c
これは規定値のaddと同じで、三つのアクションに関する監視を除去する。-a属性を抜かすと、規定の監視だけを削除する：
$ cvs watch remove -a commit hello.c
ファイルを監視する人を見出すには、cvs watchersを走らせる：
$cvs watchers
$cvs watchers hello.c
ファイルをエディットしている人を見出すには、cvs editorsを走らせる：
$cvs editors
$cvs editors hello.c
注記：任意のファイルを将来の作業を監視出来るようエディットする前に"cvs edit" を走らせる必要がある。確実にするため、CVSはcvs editを使う人にコマンド上で watchのヘルプを用いて注意喚起をする。
$ cd project
$ cvs watch on hello.c
cvs watch をhello.c上で走らせることにより、kapilはチェックアウトして作業用コピイ内に読取専用 hello.c を作る。それに触ろうとする誰かには、それが読取専用であることがわかり、先ずcvs editを実行することに気付く。
$cvs edit hello.c
前のバージョンに戻りたいとき、CVSバージョンコントロールの下にあるプロジェクトは、迅速簡便に前段階に戻ることが出来る。共通例を述べる：
$ cvs checkout -D '1 year ago' preproject
ここでpreproject は、プロジェクト名である。
$ cvs checkout -r1.4 preproject
1.4 はそのバージョンに対する CVSの改訂番号である。
よく使う用語:
Import（インポート）： これは既存のディレクトリツリーを用いてCVSレポジトリにコピイし、新CVSプロジェクトを作ることを意味する。
Commit（預託）：変更すべてをCVSレポジトリに申し出ること。各変更ファイルには新規CVSバージョンが割り当てられる。
Checkout（チェックアウト）：ファイルのコピイをCVSレポジトリからローカルディレクトリにコピイすること。
Export（エキスポート）：チェックアウトと同じ。唯一の違いは、エキスポートがCVS管理ディレクトリをコピイしないので、出来上がったツリーでCVSコマンドを走らせられないこと。他方、これは配布用の最終コピイの作成方法でもある。
Upload（アップロード）： インポート又は預託の一般用語。
Download（ダウンロード）：チェックアウト又はエキスポートの一般用語。
Checkin（チェックイン）：一般用語、預託と同じ。
CVS レポジトリ"My_Files"へのファイルの追加
$ cvs add File3.txt
$ cvs commit
cvsはファイルをアプロードしないが、次の預託でアプロードする登録をする。
これは規定値テキストエディタを呼び出して、変更入力を催促する。ファイルをセーブしてエディタを出る。CVSが継続を質問するので継続を選ぶ。これでファイルがCVSレポジトリの "My_Files"にアプロードされる。
CVS レポジトリ"My_Files"へのファイルの変更
これはcvs commitコマンドで行う。 ファイル File2.txt に内容を追加し、cvsレポジトリに預託する。
$ ls /var >> File2.txt
$ cvs commit
ファイルの削除
サイトからファイルを削除するには作業用コピイの中の望みのファイル名にremoveコマンドを用いる。「安全対策」としてファイルの作業用コピイが未だあるときは働かない。
Syntax: $ cvs remove [options] files
$ cvs remove file.html
cvs server: file `file.html' still in working directory
cvs server: 1 file exists; remove it first
$
これを避けるには、cvs removeコマンドに-fオプションを付けるか、又は先ずファイルを削除してからcvs removeコマンドを実行する。
$ cvs remove -f oldfile.html
cvs server: scheduling `oldfile.html' for removal
cvs server: use 'cvs commit' to remove this file permanently
$ cvs commit
又はOr
$ rm File3.txt
$ cvs remove File3.txt
$ cvs commit
これでは未だ実際のファイルはCVSサーバーから削除されず、プロジェクトの作業用コピイを次回預託するときこれらファイルを削除する覚え書きを作るだけである。
ディレクトリの削除
ディレクトリの削除はその中のファイル全部を削除することで、ディレクトリ自体を削除する方法はない。代わりにcvs update 又はcvs checkoutコマンドに'-P'オプションを規定すると、CVSが空のディレクトリを作業用ディレクトリから削除する。（cvs exportは常に空のディレクトリを削除することに注意）。`-P'オプションはcheckoutの `-r' 又は`-D' オプションを意味することに注意。こうしてCVSは特定のバージョンに関係なくディレクトリを作成する。
ディレクトリの中のファイル全部をcheckout する：
CVSレポジトリの中に多数のファイルからディレクトリを作成する
cvs import コマンドは幾つかのプロジェクトをCVSレポジトリ中に置くのに使用される。
$ cd source ここでsource はcvsレポジトリに置きたいファイルである。
$ cvs import -m "Test Import" My_Files Revision1 start 文字列‘Revision1’ はvendor tag,で、 `start' は release tag 。“My_Files” はcvs repository の中のファイル名である。–m オプションはログメッセージを置く。
CVSから作業用ファイルのコピイを入手
これらのファイルを作業用ディレクトリにダウンロードしよう。
パケージをcvsからチェックアウトすると、新ディレクトリが作られる。ファイルをcvsにアプロードするとき決めたパラメータ"My_Files"が、パケージをダウンロードするときのディレクトリ名となる。
ここでcvsパケージを入手する必要がある。
$ cvs checkout My_Files
他人が行った更新をダウンロードする
他人の行った更新の変更全部をダウンロードするときは、次のコマンドを実行する。
$ cvs update -dP
"d" は、抜けているディレクトリを作成し、"P"はレポジトリから削除されたディレクトリを削除する。
相違を観察する
cvsを使う二つのファイルの相違を見るには：
$ cd project
$ cvs diff index.html
このコマンドはdiff を走らせて、作業用コピイにチェックアウトした `index.html' バージョンを比較する、ここで "project" はローカルプロジェクトディレクトリの名である。
$ cvs diff -r 1.20 -r 1.21 hello.c
このコマンドは同一ファイルの二つのバージョンの間の相違を示す。
annotate コマンド
annotateを使うと、ファイルの各行に最後の接触した人物とその改訂が判る。historyコマンドより沢山の情報が得られる。
$cvs annotate
logsを見る：
$ cvs log -r 1.21 hello.c
これは hello.c version 1.21に対するログを示す
Henner Zeller's CVSweb
特徴は、CVSレポジトリをWebブラウザで眺め、ファイル毎の最新改訂を示すこと。CVSで管理するすべてのサイトとプロジェクトとWebベースの接続が出来る。入手は、 http://stud.fh-heilbronn.de/~zeller/cgi/cvsweb.cgi/
Martin Cleaver's CVSweb
特徴は、CVSレポジトリのファイルアプロード及びファイル概観、入手は、 http://sourceforge.net/projects/cvswebclient/
LinCVS
Linux用 CVS GUI クライアント。使用が容易。入手は http://www.lincvs.org/
WinCVS
Windows 用 CVS GUI クライアント。入手は http://www.cvsgui.org/download.html
CVS マニュアル： http://www.cvshome.org/docs/manual/index.html
CVS メイルリスト： http://www.cvshome.org/communication.html
ｅ−メイルアドレスを持っていれば、招かれざるメイル（通称spam）に悩まされることがる。Spamとは、3Dの食堂にHormel Corp （これは http://www.spam.com/も所有）が作った昼食である。大量に送られる広告などで、ここで扱おうとするのはUC/BE (招かれざる広告や大量Ｅ−メイル）である。
Linux (又は *nix)を持っておられれば、Spam撃退の強力なツールを設定している。これらツールは、製品メイルサーバーを走らせると、もっと有効に働く。
Spam撃退の基本三原則は：
自己防衛をしてアドレスを盗まれないこと。以下のステップを踏まないに限り、何処にもアドレスを明かさないこと。
１．投書には「廃棄」アドレス（abcde@yahoo.comなど)を用いる。Spamされたと判ったら廃棄する。
２．自分のドメインを走らせるときは−１週間か１ヶ月だけ有効な−「期限付き」メイルアドレスを用いる。me-mar31-apr31@mydomain.com.など、もしドメインがなければ、代わりにme-mar31-april31@yahoo.comなど。
３．これら二つの方法には、メールアドレスを始終変える必要があるとの欠点がある。ISPがsendmailを使っているときは、別の選択肢「plus」アドレスがある。
plusアドレスはsendmail の新バージョン(8.8 以降)で利用出来る。プラス符号を付けるだけで、useunameの後で＠の前に任意の文字列を入れてメールが送られる。例えば、me+foo_bar@myisp.comはme-に届く。各種ＭＴＡにおけるplusアドレシングの方法に関するＦＡＱはhttp://www.faqs.org/faqs/mail/addressing/（プラス符号の代わりに−符号を使うMTAもある）
義務的通告：ｅ−メイルにplusアドレスを使う前に、自分宛に送って常にとうちゃくすることを確かめること。
plusアドレスは、spammerがアドレスを盗む場所を明らかにする長所がある。例えば、Linuxインドヘルプリストにメイルするとき、you+lih@yourdomain.comと登録する。PINEもMuttも投書に別のアドレスが使える。plusアドレスの別の利点は、plusアドレスに多数のspamが到着したら、全部をDave Null (別名 /dev/null)に送って読ませられることである。.
pine 4.x とMuttで、多数の識別符号（plusアドレスを含む）の構成方法は下記の付属書＃１を参照。
Procmail フィルタを使ってMTAレベルで行うことが出来る。リモートメイルボックスにUnixシェルアカウントがあれば、Linuxデスクトップでなくそこのフィルタを働かせる。当然、MTAレベルの config / patchingとして、ルートしなければならない：
ほとんどのspamを捕らえて無効にするprocmailレシピは色々あるが、最も有名なのはCatherine Hamptonのものでhttp://www.spambouncer.org/.から無料でダウンロード出来る。別に有名なのはhttp://alcor.concordia.ca/topics/email/auto/procmail/spam/にあるコンコルディア大学のものである。 Walt DnesのSpamDunk も調べるとよい。
殆どのLinuxにsendmailが搭載されているので、詳細を述べる。Sendmail 8.8.7（Redhat 5.1と一緒に来る）以上には、 MAPS RBL その他のリストに記載されたドメインからののメイルを無視するspam阻止機能がある。sendomailの最新版は何時でも入手出来る。
sendmailをコンパイルするのは良い考えだ（sendmailソースツリーのINSTALLの詳細説明にしたがって容易に出来る）。構築済みのバイナリを好みのフォーマット(rpm, deb その他）で入手することも出来る。
Stock sendmail搭載により、データベースの篩い分け規則に従つドメイン／アドレスへのSMTP接続を拒否出来る−/etc/mail/access (及びmakemap hash access.db < accessを使って作成する /etc/mail/access.db)参照。
/etc/mail/access はｅ−メイルアドレス、全ドメイン又は特定のIPアドレス／ipブロックをキイとして持つことが出来る。
spammer@yahoo.com 550 Get lost - spammers を全く許さない
spammer.com 550 Go to hell
192.168.212 REJECT
がspammer@yahoo.com、spammer.com (又はspammer.com ドメイン内のホスト)からのユーザー、及び 192.168.212.* ネットブロック上のホスト全部からのspamを拒否する。詳細についてはhttp://www.sendmail.org/~ca/email/ にあるClaus Assmannの頁（及び http://www.sendmail.org/faq/にあるsendmail FAQ ）を参照。
自分に試験メイルを送りfetchmailを使ってダウンロードし、−ｖアーギュメントを使ってこれを試験すること。これでSMTP転送を監視出来る−FROMアドレスを見たとき、sendmailがアドレスをブラックリストに載せるをfetchmailが点滅する。警告−自分のメイルホストやfetchmeilを使ってメイルを受け取るホストにrejectを登録しないこと−これをするとメイルが無くなる。
またsendmail.mcのdnsbl機能と作動させsendmail.cfを再構築して、MAPS RBL 及びその他のDNSベースブラックホールリストに記載されたホスト全部からのメイルを拒絶することが出来る。詳細はhttp://www.mail-abuse.org/rbl/usage.html を参照。
自分がオープンリレーでないことを確認のこと。オープンリレーはspammerが悪用してメイル列に組み込むので、怒りのメイルが殺到しRBLに記載される。詳細については、http://www.sendmail.org/tips/relaying.html とhttp://www.orbs.org/otherresources.html参照。
linuxconf（又は自動構成ツール）を使ってsendmailを構成する誘惑に抵抗するなら−sendmailの新版はオープンリレーにしない。sendmail.mc ファイルを作ってsendmail.cf.を再作成する。http://www.hserus.net/sendmail.html 参照（ http://www.hserus.net/dlhowto.htmlにあるダイアルアップHOWTOの一部）。
MTA内のspam対抗策（オープンリレー閉鎖を含む）については付属書＃２を参照。
spamは陰険でいつの間にかメイルボックスに忍び込む。Linuxではspammer追跡に必要なツール−whois, nslookup, traceroute, 及び最良のdigなどの基本的 *nixツール−が揃っている。最良の対策は少し時間を掛けてspammerのWebホスト、ISP、無料メイルプロバイダに苦情を申し立てることだ。これらツールは http://www.samspade.org/.でも入手出来る。類似の追跡、報告のリンクについては付属書＃３を参照。
PINEの中のRoles−PINE 4.x 以上を用いて S (Setup) と R (Roles)を押す。好きなだけrolesを追加して＃を使ってその間を切り換える。又はe-メイルに返答するとき各種rolesの間で切り換える。
Muttの中のRoles−フォルダーフックを用いて、特定フォルダーからの発信メイルがme+tag@myisp.com に設定されたfromフィールドを持つようにする。
folder-hook linux "my_hdr From: me+linux@myisp.com (My Linux Account)"
set envelope_from # sets the envelope sender, which is what's checked
# by the list server <= mutt 1.2.x and above
dev/nullへのprocmailレシピで、多すぎるspamを引き付けるタグ付きアドレスに送られた全メイルをdev/nullに入れる。
# メイルが you+spam_string@yourisp.com に送られたら
:0:
*^TO_ you+spam_string@yourisp.com
/dev/null
に捕らえる
QMail：http://www.summersault.com/chris/techno/qmail/qmail-antispam.html にqmailのspam対抗策の詳細がある
その他のMTA： Debian にはEximが付いている。別の*nix MTA もある。包括的方法については http://www.mail-abuse.org/tsi/ar-fix.html (及び各MTAの webサイト) を参照。
参考リンク：
OLinux: 先ず経歴をお話し下さい。
Ben Collins: 一般的にはプログラマーでシステム管理者です。デスクトップ・パブリッシャやWebデザイナとして働いたこともあります。 NASA LaRC、若干の ISPで働いたこともあり今は Winstar で働いています。
OLinux: Debian'の歴史を簡単に教えて下さい。無料ソフトウエア開発についての哲学と組織は？
Ben Collins: 哲学は遙かな昔に戻ります。日常作業に必要なすべてを完備した無料OS作成が可能であると考えたのがDebianを始めた理由で、Ian MurdockにDebian宣言を書くことを薦めました。これがプロジェクトの始まりで、ソフトウエアは自由の観念から無料であるべきと考えるDebian無料ソフト指針（DFSG)の起源です。ユーザーを支援するDebian 社会契約もここから発しています。後に成長するにつれ、我々のOSを定義しプロジェクト内の権限を定義するConstitutionが出来ました。
我々は、我々の政策の指針に従う限り、基本的に各パケージの完全な管理をそのパケージの保有者に与えて来ました。我々の政策は、Debianディストリビューションの強みの一つです。それなくしてはパケージの凝集力を維持し得ず。搭載／更新は夢になるでしょう。
OLinux: Debianプロジェクトの前線に立ったときどう思いましたか？Debianプロジェクトについてお考えのことがありますか？やり方を変えるお気持ちがありますか？
Ben Collins: 大変感激しました。DPLで三度目の職場で、私の能力を評価して下さった皆様のお陰で到達した最終目標です。我々の組織にひびを入れるたるんだ所を一掃する積もりです。その後で、将来問題になりそうな難しい問題に取り組みます。
OLinux: 前任者と貴方とのリーダーシップの違いは何ですか？
Ben Collins: 初めてDebianに来たとき、Ian Jackson はDPLとしての問題を終えており、消極的でした（彼のため言い訳すると、筆者は彼の立場を何も知らない）。続いてWichertと二つの問題を引き継いだが、うまくやったとは思いません。私の考えは、直面する問題にこだわるより前進することだと思います。
OLinux: 異なるプロジェクトで世界中の違う場所で行われている作業を管理するのに、人々はどんな風に組織されており、そのためのツールは何ですか？
Ben Collins: Debianの中にメインテナ（800人位）がいます。各々が一つ以上のパケージの保守を担当しています（パケージ保守はしないが、ftp アーカイブ、www サイトなど他のプロジェクトを使って助ける人もいる）。この人達は指針と政策の範囲内で自分の問題の完全な管理を行います。この範囲内で、特定問題管理のためグループを組む開発者もいます。例えばDebian Junior プロジェクトや、(sparc, arm, alapha, powerpc, などのような)ポート及び言語のプロジェクトです。
作業はメイリングリストを通じて組織されます。直接会話に（ircオープンプロジェクト計画を通じて）IRCを使う人もいます。プログラムやシステムのバグ追跡にDebianバグ追跡システムもあります。誰でもWebペイジから入手して進行を保守者から直接追跡することが出来ます。
OLinux: Debianには現在何人働いていますか？ 結果に満足ですか？
Ben Collins: 最近のチェックでは800名です。結果には満足です。満足でないのは、うまく管理する計画のないメンテナです。仕事は進行中ですが、この分野の論議と監視を望みます。
OLinux: Debian 2.2 にはバグが多過ぎるとの批判をどうお考えですか？ この見方を変えるため"Woody" で何をなさるお積りですか？
Ben Collins: 皆がそう言っているとは知りません。既知のセキュリティ関連バグすべてを解決する優秀なセキュリティチームを持っています。定期的にポイントリリースして（現在2.2r3の作業中）セキュリティ補修を行っています。Woodyについては、リリースまでに必要な時間を短縮する新しい「試験」機構を持っています。これでもっと頻繁なリリースが出来ると思います。
OLinux: "Woody" 立ち上げへの期待は何ですか？
Ben Collins: woodyで得られる多くのことを楽しみにしています。Woodyはまた、一度にリリースした最高のアーキテクチャを約束します（どのディストリビューションでも）
OLinux: Debianで活発なプロジェクトは何ですか？内容と担当者の点で各プロジェクトをどう分担していますか？
Ben Collins: 通常Debian内のプロジェクトはニーズを満たすために自体を創造します。プロジェクトは自己管理で、どの問題を誰が担当するかは自ずから決まります。黙ってDebianを良くしているので、私は全部のプロジェクトを知っていません。
OLinux: ブラジルでは Debian BR と言うプロジェクトがあります。Debianの内容をポルトガル語に訳すプロジェクトです。御存知ですか？ イエスならどうお考えですか？ ノーならdebian-br.sourceforge.net にあるDebian BR を訪ねて下さい。他国のこのようなプロジェクトをご存じですか？
Ben Collins: 聞いていません。JPや似たようなプロジェクトと同様優れたものだと思います。Debianには参加する人が多い程良いのです。webサイトを訪ねて成功を祈ります。
OLinux:Debianは世界の指導的GNU/Linuxディストリビューションとお考えですか？
Ben Collins: 多くの点でイエスです。Debianが私に取ってどんなに重要か考えて見て、他の人に重要な領域で欠けているようです。助けになる話題は搭載している人です。中程度の搭載者が進歩しているようです。woodyの時代ではないかも知れないが、こんな人々が目標を達するでしょう。
OLinux: DebianとGNOME 基金との関係は？ KDE リーグとは？
Ben Collins: お答えする能力がありません。何人かの開発者が両プロジェクトと密接に働いおりGNOME とKDEが我がディストリビューション内で完全に統合されているのは知っています。
OLinux: Debian の利点とSuSEやRed Hat のような他の有名ディストリビューションとの違いは何ですか？
Ben Collins: 三つの長点があると思います。一つは開発モデルで、ユーザーベースのバグ報告と提案を生で入手出来る開発者は他にいない筈です。
すべてが統合されていて搭載の容易なパケージを私達の程多く持っているディストリビューションはありません。
私達のように容易な更新の出来るディストリビューションはありません。Debian 1.3 (bo)から現在の安定な 2.2 (potato) に容易に移行した報告が多数あります（これはlibc5 からlibc6 への更新パスです）。Debianは更新のサポートだけでなく保証もするのが目標です。
OLinux: Debianプロジェクトの成果をどう評価されますか？来年の見通しと目標は？
Ben Collins: Debianが生きていて成長しているのが成果です。無料で安定なディストリビューションを生む目標を失っていません。あと数年間Progenyのような会社を通じDebianが繁栄すると期待しています。ベンダーが搭載済みデスクトップシステムに有力なソリューションであると判って呉れると思います。
OLinux: これからの２年５年１０年間のGNU/Linux OSの成長について予測は？
Ben Collins: 予測は困難です。無料なので、GNU/Linuxは経済の影響を直接受けます。インターネット会社が行き詰まる最近の傾向により過去数年Linuxに流入したベンチャーを淘汰するでしょう。これは良いことでLinux会社が利益を生じ、波に飲み込まれないでしょう。２年でLinuxの刺激が治まり、もっと厳しく見るでしょう。
５年で、GNU/Linux は家庭にMacOS、Solaris、Windows のように普及するでしょう。10年後は判りません。技術の世界の永遠のようなもので、Linuxも陳腐化するでしょう。
OLinux: 企業向け市場で更に開発されるのためGNU/Linuxにに必要な改良は？
Ben Collins: 受け入れられ使い易いインターフェイスです。KDE とGNOMEはここに向かって進んでいます。インターフェイスが良くなっても、受け入れられ「普及」するには、開発より永く掛かるでしょう。
OLinux: Debian は文字通り最後のLinuxディストロでしょうが、そのハードウエア構成インターフェイスとそのインストーラは馴染んでいません。Debianプロジェクトは、最終ユーザーとの会話を重視しますか、相変わらずシステム管理者中心ですか？
Ben Collins: Debianインストーラグループはこの点で非常な努力をしています。管理者と一部マニアの隙間使用狙いに止まる気はありません。