先月、欧州議会で近く行われるヨーロッパのフトウェア特許の将来に関する投票について報告した。多く無料及びオープンソフトウェアの支持者によれば、議会に対する提案は、多分永久に、ヨーロッパでのソフトウェア特許取得の慣習を確立するだろう。彼らの主張では、これは革新の縮小に結びつき、大きな資源を使用することが出来て小さい競争者を法律上市場から弾き出すことの出来る大企業ソフトウェア会社に不必要で激しい利点を与えることになるだろう。これらの見解に対する有力で行き届いた論議を TovaldsとAlan Coxが欧州議会に提出した公開状 で読むことが出来る。
Debian Weekly News は、Debianプロジェクトが、新規amd64アーキテクチャーに対する移植作業のため二重Opteronマシンに対しフル・アクセスを受領した と報じる。
Debian Weekly Newsによれば、debian-インストーラチームがsergeインストールの過程全体を案内するHOWTO. をまとめた。
Franz Schmidは、最近リリースされたScribus 1.0の上に構築するScribus 1.1.0 - Linux Desktop Publishingのリリースと同時に、 http://www.scribus.org.uk/.に統合Scribusウェブサイトを立ち上げるとを発表した。
XFceプロジェクトは、デスクトップ環境と開発プラットフォームのバージョン4.0のリリースを発表した。
著者紹介：
Mick はLGの「今月のニュース」 編集者だ。
![[Picture]](JTD_conry.jpg)
数年前にアイルランドで生まれたMichaelは、現在ダブリン大学医療工学部で博士論文に取り組んでいる。論文の題名はLamb wavesの非破壊検査への利用だ。この研究に GNU/Linux が極めて有用であったので、 Michael は他の工学にフリーソフトウエア・ソリューションを適用することに強い興味を持った。論文が出来上がったら、 Michael は長い徒歩旅行に出る予定だ。
何年も前、恐らく20年近く前に、compユースネ・ニュースグループ上で、仕事を仕上げるため最小のツールを使うことに付いての規則的な指摘があった。つまり、何かをするのに速くて狡い方法を誰かが求めており、その続報には、AWKソリューションが続き、sedソリューションが続くなどなどのCソリューションがを含まれていた。
今日でもまだ、私は、問題に取り組む場合にこの哲学を使おうとする。今の場合は、AWKを取り上げたが、古参者でこれを読む人がいれば、sedに基づくソリューションを思い付くだろうと期待する。
私は、両替レートの毎日の要約の手続きをした。これは無料で、ここ.に行くだけで加入することができる。ドルのユーロに対するレートを保ｃおんど毎日見て、e-メールをセーブしている。ときにはセーブするだけだ。いつか、傾向を示すプログラム書こうと思っているが、いつも優先度が低い。
昨日、少数の保存メイル・メッセージを見ていたとき、立派なプログラムを書く優先度は低いが、速くて狡い裏技なら、私のしている無作為抽出より少ない時間で出来ると思った。私が望んだものは、傾向の最小のグラフ表示が付いた日付と数字であった。
第一歩はデータを見ること。ここに、メッセージの一部の抜粋を示す。
>From list@en.ucc.xe.net Wed Sep 10 12:22:53 2003
...
XE.com's Currency Update Service writes:
本日の更新通貨、XE.comのサービスを示します。メッセージの終わりにある
著作権、使用契約条項及び情報の章をお読み下さい. CUS5D0B3D5C16D9
当社の無料通貨e-メールが役立つとお考えなら。このメールを友達に
送って下さい。 http://www.xe.com/cus/で無料で加入して下さい
<PRE>
Rates as of 2003.09.09 20:46:35 UTC (GMT). Base currency is EUR.
Currency Unit EUR per Unit Units per EUR
========================= =================== ===================
USD United States Dollars 0.890585 1.12286
EUR Euro 1.00000 1.00000
GBP United Kingdom Pounds 1.41659 0.705920
CAD Canada Dollars 0.651411 1.53513
...
</PRE>
このメールを読むヘルプはhttp://www.xe.com/cus/sample.htmを参照のこと。
...
このレポートを再生するのに使った三つの事項がある：
ソリューションの数値部分は全く易しい。日付情報とレート情報を把握するだけだ。</PRE>行があったら、それをプリントする。
グラフの部分は、レートに相当する数だけのプラス記号をプリントして行うだけだ。立派な解像度を得るため、幅の広いプリント出力あるいはある種のオフセットが必要であろう。私は、ユーロは$.90以下落ちないと仮定して、オフセットを採用した、今の方向を考えるとこれは、極めて安全だ。
最後に、標題を付けたかった。AWKのBEGINブロックを使用して、私は2、3の印刷ステートメントを入れた。文字を数えるのが嫌なので、すべてを整列させるためタイトル情報の前に置く必要のあるスペースの数になる変数overを定義した。これは、私がプログラムを走らせなければならないことを意味しただけだ。どの位、変数を調節しなければならなかったかを見られたい。
コードを示す：
BEGIN {
over = " "
print over, " Cost of Euros in $ by date"
print over, ".9 1.0 1.1 1.2 1.3"
print over, "| | | | |"
}
/Rates as of/ { date = $4 }
/^USD/ { rate = $6 }
/^<\/PRE>/ {
printf "%s %6.3f ", date, rate
rc = (rate - .895) * 100
for (i=0; i < rc; i++) printf "+"
printf "\n"
date = "xxx"
rate = 0
}
メール・ファイルを入力としてプログラムを走らせるだけで、結果の行全部を印刷するが、順序はメール・ファイルのものとなる。ソート・プログラムが救済する。出力の第1フィールドは日付で、タイトル・ラインの第1文字を注意深く選らぶと、すべてが頃合いにソートされることを意味する。そこで、走らせるには、次を用いる：
awk -f cc.as messages | sort
結果を示す：
Cost of Euros in $ by date
.9 1.0 1.1 1.2 1.3
| | | | |
2003.01.02 1.036 +++++++++++++++
...
2003.08.28 1.087 ++++++++++++++++++++
2003.08.29 1.098 +++++++++++++++++++++
2003.08.31 1.099 +++++++++++++++++++++
2003.09.01 1.097 +++++++++++++++++++++
2003.09.02 1.081 +++++++++++++++++++
2003.09.04 1.094 ++++++++++++++++++++
2003.09.05 1.110 ++++++++++++++++++++++
2003.09.07 1.110 ++++++++++++++++++++++
2003.09.08 1.107 ++++++++++++++++++++++
2003.09.09 1.123 +++++++++++++++++++++++
2003.09.10 1.121 +++++++++++++++++++++++
2003.09.11 1.120 +++++++++++++++++++++++
2003.09.12 1.129 ++++++++++++++++++++++++
2003.09.14 1.127 ++++++++++++++++++++++++
2003.09.15 1.128 ++++++++++++++++++++++++
2003.09.16 1.117 +++++++++++++++++++++++
2003.09.17 1.129 ++++++++++++++++++++++++
2003.09.18 1.124 +++++++++++++++++++++++
2003.09.19 1.138 +++++++++++++++++++++++++
sed 専門家よ、精を出してくれ。-- Phil Hughes, fyl@a42.com Phone/FAX: 506-483-1265 Aptdo. 89-4060, Alajuela, Costa Rica
著者紹介：
フィル・ヒューズはLinux Journal したがって Linux Gazette. の出版者だ。彼は、オリンピックの半島の太平洋沿岸上の自宅から永久にテレビ電話する夢を持っている。雇用者として、彼は、どのボスもそうであるように「意地悪で、邪悪で、ケチで、扱い難いが、円熟した人柄」だ。
Java servlets は、ウェブサイトと、ウェブベースのアプリケーションを構築するための強力なツールだ。あらゆるJavaウェル開発者が持たなければならない技術は、Tomcat servlet エンジンの搭載とコンフィギュレーションである。多くの人が、成熟した、安定な、オープンソース・ソフトウエアを作るのにApache ソフトウエア基金 の恩恵を受けている。これは最近 InfoWorld読者により、2003年最良アプリケーション・サーバに選ばれた。
この記事は、RedHat 9.0の上でTomcat をApacheに統合する方法を論じる。目標は、ユーザが安心してTomcatを使用することの出来る簡単で安定なコンフィギュレーションを作ることだ。
全てのコマンドは、別途の注記がない限り、ルートとして発行されることに注意されたい。
ApacheをインストールするのにRedHat RPMを使うことを選んだ。Apacheを市ソースからコンパイルする代わりにRPMを使うと、次のようにシステム管理が簡単になる。
RedHat RPMのいんすとーるには、RedHat up2dateコマンド行ユティリティを使うことをお薦めする。up2dateは、RedHat ネットワーク加入権を買わなくとも、使うことが出来るが、基本的加入権には、大きい価値がある。自分でインストールしたソフトウエアが正しいバージョンで自分のシステムに正しい従属性があることを確かめるための沢山の苦労が無くなる。
インストールしなければならないRedHat RPMは：
である。up2dateを使ってパケージをインストールするには、インターネットに接続していることを確認して、下記を入力する：
up2date -i httpd
up2date -i httpd-devel
これで、次のように start/stop/restart Apache をおこなうことが出来る筈だ：
service httpd start
service httpd stop
service httpd restart
Apacheをスタートして、ブラウザに http://localhost/ と入力して、Apacheが働いていることを確認する。文書にリンクした規定値Apacheインストールペイジが見られる筈だ。
Tomcat を走らせるための唯一の要件は、Javaソフトウエア開発ツール(SDK)とも呼ばれるJava開発キッと(JDK)がインストールされていて、JAVA_HOME 環境変数が設定されていることだ。
私は SunのJava 2 プラットホーム、標準版をインストールすることにした。これはhttp://java.sun.com/j2se/.からダウンロードすることが出来る。私はJ2SE v1.4.2 SDK Linux 自動抽出バイナリファイルを選んだ。
SDKをダウンロードしたディレクトリに変更して、自己抽出バイナリを実行可能にする：
chmod +x j2sdk-1_4_2-linux-i586.bin
自己抽出バイナリを走らせる：
./j2sdk-1_4_2-linux-i586.bin
これでダウンロードしたディレクトリの中の j2sdk1.4.2 と言うファイルに入る筈だ。SDKディレクトリをインストールしたい場所に移す。私は /usr/javaにインストールした。 /usr/javaがなければ作る。私が、ダウンロードしたディレクトリの中から使ったコマンドを示す：
mv j2sdk1.4.2 /usr/java
/etc/profileが以下を含むように変更して、JAVA_HOME 環境変数を設定する：
JAVA_HOME="usr/java/j2sdk1.4.2"
export JAVA_HOME
/etc/profileに設定される別の環境変数もあるので、多分JAVA_HOME を、既存のエキスポートコマンドに追加することになる。/etc/profile はスタートアップのときと、ユーザがシステムにログインしたとき走る。
Tomcatは、ルートとしてインストールしてコンフィギュアするけれども、Tomcatを下で走らせるためのグループとユーザアカウントを次のように作らなければならない：
groupadd tomcat
useradd -g tomcat tomcat
これで /home/tomcat directoryが出来上がる、ここに私のTomcatアプリケーションをインストールする。
最新リリースをhttp://www.apache.org/dist/jakarta/tomcat-4/binaries/.からダウンロードする。Tomcat は標準JDKのトップで直接走るので、ソースから構築しなければならない流はないと思う。
Tomcat バイナリは、二つの別の味付けで利用することが出来る：
各種のダウンロード・フォーマットを多数ある。私は、LE バージョン gnu zipped tar ファイル(jakarta-tomcat-4.1.27-LE-jdk14.tar.gz)を選んだ。
ダウンロードしたディレクトリから次のコマンドを発してTomcatを解凍する：
tar xvzf tomcat-4.1.27-LE-jdk14.tar.gz
これで、jakarta-tomcat-4.1.27-LE-jdk14と云う名のディレクトリが出来上がる。このディレクトリをTomcatをインストールしたい場所に移す。私は /usr/localを選んだ。ダウンロードしたディレクトリ内部から発したコマンドを示す：
mv jakarta-tomcat-4.1.27-LE-jdk14 /usr/local/
Tomcatを搭載したディレクトリを、Tomcat文書の中ではCATALINA_HOMEと呼ぶ。この場合はCATALINA_HOME=/usr/local/jakarta-tomcat-4.1.27-LE-jdk14である。
現在のTomcatバージョンをポイントするシンボリック・リンクを設定することをお薦めする。これで、Tomcat又はCATALINA_HOME環境変数を更新する度にスタートアップとシャットダウンのスクリプトを変更する必要がなくなる。これにより、Tomcatのバージョン数個をシステム上に維持して容易に切り換えることが出来る。/usr/localの内側から、/usr/local/jakarta-tomcat-4.1.27-LE-jdk14をポイントする/usr/local/jakarta-tomcatと言う名のシンボリック・リンクを作るコマンドを示す：
ln -s jakarta-tomcat-4.1.27-LE-jdk14 jakarta-tomcat
/usr/local/jakarta-tomcat と /usr/local/jakarta-tomcat-4.1.27-LE-jdk14 ディレクトリのグループとオーナーをtomcatに変更する：
chown tomcat.tomcat /usr/local/jakarta-tomcat
chown -R tomcat.tomcat /usr/local/jakarta-tomcat-4.1.27-LE-jdk14
CATALINA_HOME 環境変数と設定する必要なない。 Tomcat は賢いので自分でCATALINA_HOME を理解する。
これで、/startup.sh 及び ./shutdown.sh をCATALINA_HOME/binディレクトリからタイプすることにより、Tomcatをそれぞれスタート及びストップすることが出来る。Tomcatをスタートしてブラウザでhttp://localhost:8080とタイプして、Tomcatが働いているのを確かめられたい。ドキュメンテーションとサンプルコードへのリンクのあるTomcatのウエルカムペイジが現れる筈だ。例示リンクをクリックしてTomcatの働きを確認する。
この時点で、Apache とTomcat は単独作動モードで別々に働いている。TomcatはApacheの代替として単独作動モードで走らせることが出来る。事実、場合によっては、単独作動Tomcatは、静的コンテントにApacheを、動的コンテントにTomcatを使うより速いと言われている。しかし、Apacheをフロントエンドとして使うにのは切実な理由がある。単独作動Tomcatを使うと：
Apacheをフロントエンドとして使用することにより得られる機能性の増加は、コネクタをインストールしてコンフィギュアする手数を補って余りあると考える。この考えで私はmod_jk コネクタを選択した。久しい間極めて安定だ。 mod_jk2は将来のウエーブだが、今は差し控えている。2002年初め、当時の「将来のウェーブ」、mod_webapp、に莫大な投資をした。これは、最早開発されていない。そんな理由で、 mod_jk2への移行をためらっている。
mod_jk コネクタは、Apache とTomcatとの間の通信リンクだ。これはApacheからのリクエストをポート8009上で聴取する。
私の経験では、コネクタをバージョン従属と考えるの安全だ。Tomcatを更新して、コネクタに問題を生じたときは、バージョン固有のコネクタソースを使ってコネクタをコンパイルして見るとよい。
Tomcatバージョン用のコネクタソースはhttp://www.apache.org/dist/jakarta/tomcat-4/source/からダウンロードする。私は、jakarta-tomcat-connectors-4.1.27-src.tar.gzを用いた。別のコネクタ用(mod_jk, mod_jk2, coyoteなど)のソースは、このファイル一つで配布されている。
ファイルの内容を、次のようにして、ダウンロード・ディレクトリに解凍する：
tar xvzf jakarta-tomcat-connectors-4.1.27-src.tar.gz
これでjakarta-tomcat-connectors-4.1.27-srcと言う名のフォルダが出来上がる。このフォルダを、システム上でソースファイルを記憶する場所に移す。私は /usr/srcにする。ダウロード・ディレクトリの中から私が発したコマンドを示す：
mv jakarta-tomcat-connectors-4.1.27-src /usr/src/
コネクタソースがインストールされているフォルダをCONN_SRC_HOMEと呼ぶ。私の場合、CONN_SRC_HOME = /usr/src/jakarta-tomcat-connectors-4.1.27-srcである。
buildconfスクリプトを走らせてCONN_SRC_HOME/jk/native/configure ファイルを作る。
CONN_SRC_HOME/jk/native/buildconf.sh
自分のシステム上のapxs ファイルに対するパスと、下記のオプションを付けてconfigureスクリプトを走らせ右：
./configure --with-apxs=/usr/sbin/apxs
次のコマンドを用いて mod_jk を構築する：
make
全てが上手くいったときは、mod_jk.so ファイルが作られた。手で、Apache共有オブジェクト・ファイル・ディレクトリにコピイする：
cp CONN_SRC_HOME/jk/native/apache-2.0/mod_jk.so /etc/httpd/modules
workers.properties ファイルには情報が含まれるので、mod_jk が Tomcat worker processesに接続することが出来る.
CATALINA_HOME/conf/jk と言う名のディレクトリを作って、このディレクトリの Appendix にあるworkers.properties ファイルを置く。
server.xmlファイルにはTomcat サーバ・コンフィギュレーション情報が含まれる。Tomcatと一緒に来る規定値 CATALINA_HOME/conf/server.xml ファイルには多数のファイルが含まれているので、将来の参考用(server.xml.bakなど) にセーブして無から始めることをお勧めする。規定値server.xmlは、Tomcatが独立モードで働くこと確認するため、及びアプリケーションに付いて来る実例を見るため重要であるが、ApacheをTomcatと統合したいときは最良の出発点ではないと思う。その代わり、核心server.xmlファイルを次のようにして作る：
<Server port="8005" shutdown="SHUTDOWN" debug="0"> <Service name="Tomcat-Apache"> <Connector className="org.apache.ajp.tomcat.Ajp13Connector" port="8009" minProcessors="5" maxProcessors="75" acceptCount="10" debug="0"/> <Engine name="your_engine" debug="0" defaultHost="your_domain.com"> <Logger className="org.apache.catalina.logger.FileLogger" prefix="apache_log." suffix=".txt" timestamp="true"/> <Host name="your_domain" debug="0" appBase="webapps" unpackWARs="true"> <Context path="" docBase="/home/tomcat/your_application" debug="0" reloadable="true" /> </Host> </Engine> </Service>
</Server>
注記：
1.この設定は、Tomcat アプリケーションをCATALINA_HOME/webappsでなく /home/tomcatに置くと仮定する。これにより、容易にTomcatを更新し、Tomcatアプリケーションをバックアップすることが出来る。
1. 規定値server.xmlを保存するときは、ポート8009上で聴取するmod_jk以外のコネクタを確実にコメントアウトすること。規定値ファイルは、Tomcat独立作動サービスのため有効にしたCoyote/JK2 コネクタと一緒に来る。これは、Tomcat-Apacheの中のmod_jkコネクタと競合する。このコネクタをコメントアウトしなければならない。これは、Tomcatを独立モードで（ポート8080）直接接続するときは必要ないので、このコネクタが規定値で有効になっている理由は分からない。
Apache は、Apache コンフィギュレーション・ファイル /etc/httpd/conf/httpd.confの中におかれたディレクティブを用いてコンフィギュアする。RedHatが供給するhttpd.conf ファイルには、三つのセクション：(1) Global Environment, (2) Main Server Configuration、(3) Virtual Hosts.がラベルされているのに、気付かれるだろう。
Global Environmentセクションの中にある LoadModule ディレクティブの下に次を追加する：
LoadModule jk_module modules/mod_jk.so
Global Environmentセクションの中にある AddModule ディレクティブの下に次を追加する：
AddModule mod_jk.c
Main Server Configuration セクションの下に次を追加する：
JkWorkersFile "/usr/local/jakarta-tomcat/conf/jk/workers.properties" JkLogFile "/usr/local/jakarta-tomcat/logs/mod_jk.log" JkLogLevel info JkLogStampFormat "[%a %b %d %H:%M:%S %Y]"
上のコンフィギュレーションは、自分のバージョンのTomcatがインストールしたディレクトリをポイントするシンボリックリンク /usr/jakarta-tomcatを作ったと仮定する。
仮想ホストディレクティブをhttpd.confのVirtual Hostsセクションの中に設定する。以下は、全URLにTomcatの中で"servlet"を付けて送るためyour_domainウェブサイトを設定する方法の例である：
NameVirtualHost *:80 <VirtualHost 192.168.1.1> ServerAdmin webmaster@your_domain ServerName your_domain DocumentRoot /home/www/your_domain/html ErrorLog /home/www/your_domain/logs/error_log CustomLog /home/www/your_domain/logs/access_log common JkMount /servlet/* ajp13
</VirtualHost>
上のコンフィギュレーションは、アプリケーションの静的 html ファイルが、/home/www/your_domain/html ディレクトリからサーブされると仮定する。
次のようにタイプして。Apacheコンフィギュレーションをテストすることが出来る：
apachectl configtest
httpd.confにエラーがなければ、応答 "Syntax OK" を受け取る。
your_domain.com は、DNS登録を持つドメイン名である必要はない。試験目的で、好きなドメインをyour_applicationへのアクセスに用いる予定のマシンの/etc/hosts ファイル内に設定することが出来る。
以下の例は、開発用コンピュータに典型的な、単一マシンでApacheとTomcatを走らせる場合の登録を示す：
127.0.0.1 your_domain
ここでは、設定をテストすることが出来るよう、簡単なHello Worldサーブレットを作ってインストールする。
以下を、HelloWorld.javaと言う名のファイルにコピイする：
import java.io.*;
import javax.servlet.*;
import javax.servlet.http.*;
public class HelloWorld
extends HttpServlet {
public void doGet(HttpServletRequest request,
HttpServletResponse response)
throws IOException, ServletException {
response.setContentType("text/html");
PrintWriter out = response.getWriter();
out.println("Hello World");
}
}
このソースを次のようにクラス・ファイルにコンパイルする：
javac -classpath /usr/java/jakarta-tomcat/common/lib/servlet.jar HelloWorld.java
これで、HelloWorld.classと言う名のファイルが出来上がる。
/home/tomcat/your_applicationの中に、以下のディレクトリとファイルを作る：
/home/tomcat/your_application/WEB_INF /home/tomcat/your_application/WEB_INF/classes /home/tomcat/your_application/WEB_INF/web.xml
web.xml ファイルは、サーブレットの名をURLパターンにマップする場所なので、Tomcatは要求されたときサーブレットを走らせることが出来る。以下は、ブラウザにURL http://your_domain/servlet/HelloWorld が入力されたときは何時でも、HelloWorldサーブレットを走らせるweb.xmlファイルである：
<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE web-app
PUBLIC "-//Sun Microsystems, Inc.//DTD Web Application 2.3//EN"
"http://java.sun.com/dtd/web-app_2_3.dtd">
<web-app>
<servlet>
<servlet-name>HelloWorld</servlet-name>
<servlet-class>HelloWorld</servlet-class>
</servlet>
<servlet-mapping>
<servlet-name>HelloWorld</servlet-name>
<url-pattern>/servlet/HelloWorld</url-pattern>
</servlet-mapping>
</web-app>
HelloWorld.class ファイルを /tomcat/home/your_application/WEB-INF/classes ディレクトリにコピイする：
次の様にTomcat をスタートし直す：
/CATALINA_HOME/bin/shutdown.sh
/CATALINA_HOME/bin/startup.sh
Restart Apache as follows:
service httpd restart
これで http://your_domain/servlet/HelloWorld をブラウザにタイプして、 "Hello World"メッセージをみることが出来る筈だ。
以下のステップは必須ではないが、Tomcatを上手くインストールするためお薦めする。
システム立上がりの際Tomcatを自動的にスタートさせ、Apacheでするようにサービス・コマンドを用いて扱いたいときは、初期化スクリプトを作らなければならない。
次のTomcat 初期化スクリプトを /etc/rc.d/init.d/tomcatとして作る。
#!/bin/sh # # Startup script for Tomcat, the Apache Servlet Engine # # chkconfig: 345 80 20 # description: Tomcat is the Apache Servlet Engine # processname: tomcat # pidfile: /var/run/tomcat.pid # # Mike Millson <mmillson@meritonlinesystems.com> # # version 1.02 - Clear work directory on shutdown per John Turner suggestion. # version 1.01 - Cross between RedHat Tomcat RPM and Chris Bush scripts # Tomcat name :)
TOMCAT_PROG=tomcat
# if TOMCAT_USER is not set, use tomcat like Apache HTTP server
if [ -z "$TOMCAT_USER" ]; then
TOMCAT_USER="tomcat"
fi
RETVAL=0
# start and stop functions
start() {
echo -n "Starting tomcat: "
chown -R $TOMCAT_USER:$TOMCAT_USER /usr/local/jakarta-tomcat/*
chown -R $TOMCAT_USER:$TOMCAT_USER /home/tomcat/*
su -l $TOMCAT_USER -c '/usr/local/jakarta-tomcat/bin/startup.sh'
RETVAL=$?
echo
[ $RETVAL = 0 ] && touch /var/lock/subsys/tomcat
return $RETVAL
}
stop() {
echo -n "Stopping tomcat: "
su -l $TOMCAT_USER -c '/usr/local/jakarta-tomcat/bin/shutdown.sh'
RETVAL=$?
Echo
[ $RETVAL = 0 ] && rm -f /var/lock/subsys/tomcat /var/run/tomcat.pid
rm -rf /usr/local/jakarta-tomcat/work/*
}
# See how we were called.
case "$1" in
start)
start
;;
stop)
stop
;;
restart)
stop
# 不様なやり方だ # stopを離れる前にtomcatが本当に # 停止したかを確認しなければならない
sleep 2
start
;;
*)
echo "Usage: $0 {start|stop|restart}"
exit 1
esac
exit $RETVAL
このスタートアップ・スクリプトを、次のようにシステムに追加する：
chkconfig --add tomcat
次のコマンドを用いてこれをスタート／ストップ／再スタートすることが出来る：
service tomcat start
service tomcat stop
service tomcat restart
システムを立上げたときTomcat を自動的にスタートさせたいときは、次の用にTomcatをランレベルに追加する必要がある：
chkconfig --level 5 tomcat on
ランレベル 5 は、開発用コンピュータに典型的なX ウインドウズ・システムである。ランレベル 3 は、専用ウェブサーバに典型的である。
Apache とTomcat のスタート順は極めて重要だ。Apacheが自分でTomcatに付着することが出来るよう、Tomcat はApacheをスタートする前にスタートしなければならない。
開発中には、tomcatアプリケーションに直接アクセスする必要があるだろう。開発をおこなうユーザアカウントを /etc/groupにあるtomcatグループに追加する。例えば、yournameの下で開発をおこなうとき、 /etc/groupの中でどう見えるかを示すと：
yourname
tomcat:x:502:yourname
tomcat グループが/home/tomcatに対し書込許可を有しており/home/tomcat/your_applicationの中のTomcatアプリケーションに対しファイルを（antを用いるなどで）公開することが出来るのを確かめること。次のコマンドをルートとして発行する：
chmod g+w /home/tomcat
# workers.properties # # このファイルは、必要な情報とともに各種Tomcat workerに接続するための # jk誘導プラグインを提供する。このファイルのディストリビューション # バージョンは、プラグインで使える用になる前に修正を必要とすることに #注意のこと。 # # 一般的な注意として、文字 $( and )はマクロを内部で定義するため # 使用する。自分のコンフィギュレーション内で使用しないこと。 # # x=value # y=$(x)\something #のような行の組に出会ったときは、 # ｙの最終値は、value\somethingである。 # # 通常、為すべきことのすべては、最初の三つのプロパティ、即ち # workers.tomcat_home, workers.java_home 及び ps.をアンコメントする # ことである。殆どのコンフィギュレーションは、これらから導き出される。 # workers.tomcat_home, workers.java_home and psの更新をおこなったときは、 # 三つのworkers をコンフィギュアしなければならない： # - ローカルホスト8007に接続する ajp12 worker # - ローカルホスト8009に接続する ajp13 worker # - jni inprocess worker. # - load balancer worker # # しかし規定値でプラグインはajp12 workerだけを用いる。プラグインに別のworker # を使わせるには、workerリストを正しくコンフィギュアしなければならない # # OPTIONS ( jni モードでは極めて重要 ) # # workers.tomcat_home は、tomcatをインストールした位置をポイントし # なければならない。これはconf、webapps、libディレクトリのある場所だ。 # workers.tomcat_home=/usr/local/jakarta-tomcat # # workers.java_home は Java インストレーションをポイントしなければならない。 # 通常、その下に bin 及び lib ディレクトリがある筈。 # workers.java_home=$(JAVA_HOME) # # 環境をスラッシュでコンフィギュアしなければならない # ... ps=\ on NT and / on UNIXおよび何か別のどこか # ps=/ # #------ 高級モード ------------------------------------------------ #--------------------------------------------------------------------- # #------ 規定値 workert リスト ------------------------------------------ #--------------------------------------------------------------------- # # 自分のプラグインが作るべきworkerは、次を作って使用しなければならない。 # worker.list=ajp12, ajp13 # #------ 規定値 ajp12 WORKER 定義 ------------------------------ #--------------------------------------------------------------------- # # # 名称が ajp12で型が ajp12のworkerを定義する。 # 名称と型は一致する必要はないことに注意。 # worker.ajp12.port=8007 worker.ajp12.host=localhost worker.ajp12.type=ajp12 # # load balancing workeを用いるときは # ロードバランス係数を定義する # 注記： # ----> lbfactor は > 0でなければならない # ----> lbfactorが低いことはworkerのする仕事が少ないことを意味する worker.ajp12.lbfactor=1 # #------ 規定値 ajp13 WORKER 定義 ------------------------------ #--------------------------------------------------------------------- # # 名称が ajp13で型が ajp13のworkerを定義する。 # 名称と型は一致する必要はないことに注意。 # worker.ajp13.port=8009 worker.ajp13.host=localhost worker.ajp13.type=ajp13 # # load balancing workeを用いるときは # ロードバランス係数を定義する # 注記： # ----> lbfactor は > 0でなければならない # ----> lbfactorが低いことはworkerのする仕事が少ないことを意味する worker.ajp13.lbfactor=1 # # オープン接続キャッシュのサイズを定義する。 #worker.ajp13.cachesize # #------ 規定値 LOAD BALANCER WORKER 定義 ---------------------- #--------------------------------------------------------------------- # # ロードバランサ(型 lb) workers は、面倒なセッションを # 用いて加重連続ロードバランスを実行する。 # 注記 # ----> worker が働かなくなると、ロードバランサが時々 # その状態を点検する。それまでは、全ての仕事を # ピアworkerに向ける。 worker.loadbalancer.type=lb worker.loadbalancer.balanced_workers=ajp12, ajp13 # #------ 規定値 JNI WORKER 定義--------------------------------- #--------------------------------------------------------------------- # # 名称がinprocessで、型が jniのworkerを定義する。 # 名称と型は一致する必要はないことに注意。 # worker.inprocess.type=jni # #------ クラスパスの定義 ----------------------------------------- #--------------------------------------------------------------------- # # 追加クラスパス成分 # worker.inprocess.class_path=$(workers.tomcat_home)$(ps)lib$(ps)tomcat.jar # # tomcat用コマンド行の設定. # 注記：cmd_line ストリングにはスペースを含まない # worker.inprocess.cmd_line=start # # 必要ないが、カスタマイズすることが出来る # worker.inprocess.cmd_line=-config # worker.inprocess.cmd_line=$(workers.tomcat_home)$(ps)conf$(ps)server.xml # worker.inprocess.cmd_line=-home # worker.inprocess.cmd_line=$(workers.tomcat_home) # # 我々がこれから使う JVM # # これはJava2用 # # Windows # #worker.inprocess.jvm_lib=$(workers.java_home)$(ps)jre$(ps)bin$(ps)classic$(ps)jvm.dll # IBM JDK1.3 # worker.inprocess.jvm_lib=$(workers.java_home)$(ps)jre$(ps)bin$(ps)classic$(ps)libjvm.so # Unix - Sun VM or blackdown #worker.inprocess.jvm_lib=$(workers.java_home)$(ps)jre$(ps)lib$(ps)i386$(ps)classic$(ps)libjvm.so # RH + JDK1.4 worker.inprocess.jvm_lib=$(workers.java_home)$(ps)jre$(ps)lib$(ps)i386$(ps)server$(ps)libjvm.so # # これは、jdk1.1.X用 # # worker.inprocess.jvm_lib=$(workers.java_home)$(ps)bin$(ps)javai.dll # # Setting the place for the stdout and stderr of tomcat # worker.inprocess.stdout=$(workers.tomcat_home)$(ps)logs$(ps)inprocess.stdout worker.inprocess.stderr=$(workers.tomcat_home)$(ps)logs$(ps)inprocess.stderr # # tomcat.home Java を正しく設定する # # worker.inprocess.sysprops=tomcat.home=$(workers.tomcat_home) # # Java システム・プロパティ # # worker.inprocess.sysprops=java.compiler=NONE # worker.inprocess.sysprops=myprop=mypropvalue # # 追加のパス成分 # # worker.inprocess.ld_path=d:$(ps)SQLLIB$(ps)bin
Installing Tomcat on Linux 、Allan Peda作、2001年８月
著者紹介：
Mikeは、ジョージア州アトランタの Merit Online Systemsのシステムエンジニアだ。コンピュータに関する最初の経験は、1981年に IBM PC 上でBASICのプログラムを作ったことだ。プロペラ・キャップを被っていないときは、妻のデボラと時間を過ごすのを楽しみにしており、復職特別手当を台無しにしている。
mmillson@meritonlinesystems.com http://www.meritonlinesystems.com/
幾つかの回路を配線をして、古い20MHz オッシロスコープで眺めたのは、少し前だった。複雑で生き生きしたマルチタスクＯＳが、タイミングに敏感なコードの働きに影響する方法を、これらのプログラムが発生する信号をオッシロスコープで見て、観測するのは面白いだろうと考えた。この記事は、私のおこなった実験を幾つか示す。一つは、「正常」2.4.18 kernelについて、次にRATIプロジェクトが提供する`real time extensions' でパッチしたkernelについてだ。読者は単純なkernelプログラム作成の経験があると想定する。
使用しない「埋込Linux」実験プラットホームにあった古いCyrix CPU基礎のシステムを転用した。マザーボードをキャビネットから取出し−HDD、モニタ、キイボードなどは削除−ブートROMのあるEthernetカードだけをISAプロとボードと一緒に残した。このマシンは、数フィート離れた完全装備のLinuxシステムからブートする。こうして、高価なハードウエアを損なう心配をすることなく、実験をすることが出来る。普通の2.4.18 kernel 又はRTAIでパッチしたものの両方からブートするオプションがある。
一寸したユーザスペース・プログラムを示す。これは、スーパーユーザとして使ったとき、パラレルポート出力ピンに波形を発生する。この波形をオッシロスコープで見ることが出来る。
#include <asm/io.h> #define ON 100000 #define OFF ON*10
delay(unsigned int i)
{
while(i--);
}
main()
{
iopl(3);
while(1) {
outb(0xff, 0x378);
delay(ON);
outb(0x0, 0x378);
delay(OFF);
}
}
私のシステムでは、1ms/分割に設定したオッシロスコープを用いて約2.5 から 2.7ms までのオン時間で波形を観測する。
マイクロプロセッサの基本コースを終えた人は誰でも、ループを書いて遅延を生じる方法を知っている。ここでもそれを行っている。児戯だ。
全く変なのは、別のコンソールにログオンして"yes"コマンドを走らせると、場面上に文字"y"が連続流を生じる。スコープを見ると、格好の良い私の信号がメチャメチャになっているのが分かる。オンとオフの時間が非常に長くなっているので、私が見るのは、ほとんど0Vから5Vにジャンプし続ける連続線なのだ。
別の実験をして見る。もっと速いマシンからシステムを `flood ping' （-fオプションの付いたPingコマンド）して見る。ここでも、スコープ上で信号が乱れているのが分かる。
この理由は、分かり難いものではない。私のプログラムは、このとき別のものとCPUサイクルを争っている。遅延ループ実行の間に、コントロールは別のプログラムに切り換えて、それによ、最初のプログラムが理解するの遅延時間を長くすることが出来る。 `flood ping' は、OS kernelの中で多数の活動を生じる。これはまた、私のプログラムのタイミングに有害な影響を及ぼす。
問題の解決策は簡単だ−波形を生じるプログラムを乱さないだけだ。CPUを完全にコントロールさせよう。すると、疑問はOSが複雑なマルチタスクを持つかだ。調べよう。
「リアルタイム」信号を発生するプログラムをプログラムに呼び出す。そのプログラムを、規定の時間間隔でパラレルポートピンを「トグル」する役目の「タスク」として想像して見よう。発生する波形を、言わばサーボモータ（サーボの回転は、その全体オン-オフ周期が約20msであるパルスの「一周期」の長さにより制御される。オンの周期が1msから20msに変化するとき、サーボは180度回転する）などの物理的装置の制御に使用すると、パルス長さの変化は、劇的な効果を持つことが出来る。私のFutaba S2003サーボは、上述のようなプログラムにより制御されるとき、別のプロセスにより攪乱されると幅広く揺れる。このリアルタイム・プログラムには、正しい作動のため、合致しなければならないデッドラインがある。制御アプリケーションを設計する古典的解決策は、専用マイクロプロセッサとデジタル信号プロセッサを使用しなければならなかった。しかしPCハードウエアが大変安価になったので、広範囲のアプリケーションが、プログラムを敏感なタイミング要件で正確に走らせる、と同時に、ネットワークと交信する、データを図形インターフェイスで表現する、及び二次記憶にデータをログするなど、タイミング・デッドラインが問題でない、所謂る「非リアルタイム」ジョブをおこなう場所に浮かび出た。
Linux Kernel を何らかの方法で、（特殊な方法で作られ実行される）あるタスクに課せられたタイミング制約を、他の「非リアルタイム」タスクがあるときであっても、常に満たすため、修正することが出来るならば、理想的な解決策になる。この記事の少し後で、このような解決策は、一つではなく多数利用することが出来るのが分かる。
プログラムのタイミングが、システム内で進行中の多数の他の活動に左右される他に、我々は忙しいループを実行させることによりCPUサイクルを暴走させている（また、Pentiumなど複雑なマイクロプロセッサ上では、命令を計数して遅延を計算するのは困難である）。プログラムをスリープさせてはどうだろうか？
`nanosleep'などのファンクションを用いることにより、我々のプロセスをスリープさせ、特定の時期にウエークアップさせることをOSに命じる。しかし、ここでも、OSはKernel モードで他の作業（TCP/IPパケットの処理、ディスクI/Oの実行）又はkernelが我々のプロセスをウエークアップさせる直前に計画された別のプロセスを実行するのに忙しいので、我々のプロセスが特定の時期にウエークアップされて実行させない可能性がある。
我々の信号発生コードをkernelスペース・モジュールで実行するとどうなるだろうか？
#include <linux/module.h> #include <linux/fs.h> #include <linux/param.h> #include <asm/uaccess.h> #include <asm/io.h>
static char *name = "foo";
static int major;
#define ON 100000
#define OFF ON*10
void delay(unsigned int i)
{
while(i--);
}
static int
foo_read(struct file* filp, char *buf, size_t count, loff_t *f_pos)
{
while(1) {
outb(0xff, 0x378);
delay(ON);
outb(0x0, 0x378);
delay(OFF);
}
return 0;
}
static struct file_operations fops = {
read: foo_read,
};
int init_module(void)
{
major = register_chrdev(0, name, &fops);
printk("Registered, got major = %d\n", major);
return 0;
}
void cleanup_module(void)
{
printk("Cleaning up...\n");
unregister_chrdev(major, name);
}
これでユーザスペース・プロセスは、我々のプロセスを攪乱することはないけれども、未だパイピングのfloodによりネットワーク・カードを中断させることは出来る。中断はkernelコード実行中でもサービスされるので、スコープ上に表示される波形は、いつものように跳び周り始める。
kernel内でスリープさせることは出来る−これはシステムが見られるのを防止する−が、これでは我々の問題、リアルタイム・コードと非リアルタイム・コードの平和共存、は解決されない。
Linuxと我々のハードウエアとの間で`nano kernel' にスライドしたらどうだろか？このkernelは、両Linuxを「リアルタイムタスク」と同様に制御するだろう。Linuxは、高い優先度の「リアルタイム」タスクが存在しないときだけ処理される極めて優先度の低いタスクとして扱われる。中断の制御は、この専用kernelの手中にあり−中断を無効にするLinuxの要求は、その中断が本当に無効にならない方法で扱われる−Linuxだけはこれらの中断を見ることが出来ない−リアルタイム・タスクは、余り遅延することなく、それらの中断ハンドラを静かに実行することが出来る。
ビクター・ヨダイケン博士が導入したこの新しい概念の結果、RTAI Linuxが生まれた。その他多くの大学と研究所が、自分の実現方法を試みた−最も有望な（また完全に私有でない）ものの一つは、Dipartimento di Ingegneria Aerospaziale - Politecnico di Milano (DIAPM)の研究社が開発したRTALだ。
RTAI はここから入手することが出来る。主なコンポーネントが二つある：
パラレルポート・ピン上に波形を作るRATIプログラムを見よう：
#include <linux/module.h> #include <rtai.h> #include <rtai_sched.h>
#define LPT1_BASE 0x378 #define STACK_SIZE 4096 #define TIMERTICKS 1000000 /* 1 milli second */
static RT_TASK my_task;
static void fun(int t)
{
unsigned char c = 0x0;
while(1) {
outb(c, LPT1_BASE);
c = ~c;
rt_task_wait_period();
}
}
int init_module(void)
{
RTIME tick_period, now;
rt_set_periodic_mode();
rt_task_init(&my_task, fun, 0, STACK_SIZE, 0, 0, 0);
tick_period = start_rt_timer(nano2count(TIMERTICKS));
now = rt_get_time();
rt_task_make_periodic(&my_task, now + tick_period, 2*tick_period);
return 0;
}
void cleanup_module(void)
{
stop_rt_timer();
rt_busy_sleep(10000000);
rt_task_delete(&my_task);
}
ここの詳細を検討する前に、一般概念を見よう。先ず、何か有用なことをする `task' が必要だ。`task' は単なるＣファンクションだ。ほとんどの我々のタスクの構造は、次のようなものだ−ある行動を実行する、ある時間スリープさせる、もう一度ある行動を実行する、繰り返す。スリープさせる方法の一つは、 `rt_task_wait_period'を呼び出すことだ−問題はスリープ時間の長さだ。我々は、基本`tick'の倍数である一定の固定「周期」だけスリープさせる。システム8254タイマーをプログラムして、1KHz（１秒の1000倍）などの割で中断を発生することが出来る。RATIスケジューラは、tick毎にスケジュール決定をおこなう−我々のtaskの周期を`2 ticks'に設定したとき、各trikの間の間隔が1msであると、スケジューラは2ms後にウエークアップする。
`init_module'を用いてスタートする。先ずタイマーを`periodic timer' (別のモードも利用可能)としてコンフィギュアする。`rt_task_init'ファンクションは、RT_TASK型オブジェクトのアドレス、我々のファンクションのアドレス及びスタックサイズを、他の値と共に受領する。ある種の「初期化」が実行され、情報が、後でこの特定タスクを識別するため使用されるRT_TASK型のオブジェクトに記憶される。
我々のTICK_PERIOD は1000000 ナノ秒（１ミリ秒）である。nano2countファンクションは、この時間を内部「計数単位」`count units'に転換する。タイマーが、1msに等しいtick周期でスタートされる（これが `start_rt_timer' ファンクションのおこなうこと）。
残っているのは、タスクをスタートしてその周期を設定することだ（周期は、rt_task_wait_periodが使用して、タスクをウエークアップさせる時刻を設定する）。我々は、この周期を２tickに設定して、スケジューラに次のtickでスタートさせることを命じる。
我々のタスクの本体は極めて簡単だ−パラレルポート出力ピンに値を書き、値を記憶する変数を補完して、次の（2msの）周期を待つ。ウエークアップさせた後、これは同じ順序を、何度も繰り返す。最終結果は、オン時間が2msオフで時間が2msの波形をスコープ上で見ることだ。
先ず、アンロードしたシステム上で波形を観察した。次いで、floodパイピングをシステムにリソートした。スコープ上の波形は安定したままだった。RATIが約束したのは、Linuxを常に低い優先度で走らせること−Linuxは、リアルタイム・サービスがないときだけ走る−だった。リアルタイムタスクのウエークアップは、コントロールが直ちにそれに渡される結果となる（勿論、リアルタイム・スケジューラを起動して、コントロールをウエークアップしたばかりのタスクに渡すには、今行っていることが何であれ、それを封じるにはいくらかの遅延がある−この遅延は定数である必要はない）。これが、負荷を掛けてもほぼ安定な信号を見ることが出来る理由だ。
ファンクション `rt_sleep'の使用を実証するコードのセグメントを示す：
#define LPT1_BASE 0x378
#define STACK_SIZE 4096
#define TIMERTICKS 1000000 /* 1 milli second */
#define ON_TIME 3000000 /* 3 milli seconds */
#define OFF_TIME 1000000 /* 1 milli second */
static RT_TASK my_task;
RTIME on_time, off_time;
static void fun(int t)
{
while(1) {
outb(0xff, LPT1_BASE);
rt_sleep(on_time); outb(0x0, LPT1_BASE); rt_sleep(off_time);
}
}
int init_module(void)
{
RTIME tick_period, now;
rt_set_periodic_mode();
rt_task_init(&my_task, fun, 0, STACK_SIZE, 0, 0, 0);
tick_period = start_rt_timer(nano2count(TIMERTICKS));
on_time = nano2count(ON_TIME);
off_time = nano2count(OFF_TIME);
now = rt_get_time();
rt_task_make_periodic(&my_task, now + tick_period, 2*tick_period);
return 0;
}
データをユーザスペース非リアルタイム・プログラムからRATIタスクに転送することが必要になるだろう。これはfifoを使って簡単におこなうことが出来る。例えば、RATIタスクがPWM（パルス幅変調）信号を生じていると、幅をユーザスペースから制御しなければならない。RATIインストレーションは、rtf0、rtf1などの名で、ユーザファイル /dev/ goingの下に幾つかのデバイス・ファイルを作る。ユーザプログラムは、各fifoをその名で識別する一方、RATIタスクはそれを番号0、1、2などでおこなう。
#include <linux/module.h> #include <linux/errno.h> #include <rtai.h> #include <rtai_sched.h> #include <rtai_fifos.h>
#define STACK_SIZE 4096 #define COMMAND_FIFO 0 #define FIFO_SIZE 1024
int fifo_handler(unsigned int fifo)
{
char buf[100];
int r;
r = rtf_get(COMMAND_FIFO, buf, sizeof(buf)-1);
if (r <= 0) return r;
rt_printk("handler called for fifo %d, get = %d\n", fifo, r);
buf[r] = 0;
rt_printk("data = %s\n", buf);
return 0;
}
int init_module(void)
{
/* Create fifo, set handler */
rtf_create(COMMAND_FIFO, FIFO_SIZE);
rtf_create_handler(COMMAND_FIFO, fifo_handler);
return 0;
}
void cleanup_module(void)
{
printk("cleaning up...\n");
}
一般的なリアルタイム・プログラム作成問題に興味があれば、Herman Bruyninckxの書いたReal Time and Embedded Guide から始めなければならない。RATIプログラム作成は、プロジェクトのホームペイジから入手することの出来るRTAI manual 及び RTAI programming guide に詳しく説明されている。
厳しいタイミング要件を持つタスクの決定論的な実行のためサポートを提供するOSは、リアルタイムシステム設計景観の一部分に過ぎない。数日間RATIと取り組んだ後、これ（リアルタイム・プログラム作成）は、私のような初心者が趣味ですることが出来るものでないことが分かった−システム（ハードウエアとソフトウエア）を徹底的に理解するため多数の時間、労力及び忍耐を費やし、ツールも利用しなければならない。だが、そうすれば、実験して一寸した喜びを感じるのを止められなくなる。
著者紹介：
私は インドのカラチにあるICソフトウエアで働くインストラクタです。有機化学者になりたいと思っていましたが、可能な第二志望をしています。それはLinuxと取り組んで、プログラム作成を教えることです。
今日、ハードウエア素子は益々強力になり、１日毎にその能力と特徴を広げている。しかし、これらの素子は、これらの特徴を出来るだけ探査することの出来るソフトウエアがなければ、役に立たないのでソフトウエア工学と言うソフトウエア開発過程がコンピュータの最も重要な分野の一つであると言える。
ハードウエア産業における急速な進歩に追い付くには、ソフトウエアの核心の開発を任務とするプログラマとソフトウエア・エンジニアは、役立つ製品だけでなく、コンピュータやプログラマの努力が無駄にならないことを保証する良いソフトウエア慣行を実行する製品を作ったり開発することが必要であるとの考えを持たなければならない。
その筋書きの何処にLinuxが当て嵌まるだろうか？と考えるだろう。そう、フリー・ソフトウエア運動がその答えになる。Linux OS は、フリー・ソフトウエアの主義、概念及び哲学の普及を助ける偉大な成功プロジェクトの一つであった。
Linuxユーザの数に着目するならば、過去十年に著しい増加を記録した。ユーザはこのシステムを家庭、仕事場、及び学校でも採用した。これらユーザの多くは、ソースコードの利用性、つまり世界中の誰でもがソースを入手し、読み、修正し、そのコードをコピイして配布することが出来るためLinuxに合流した。これらユーザのほとんどは、以前にコンピュータ・プログラム作成及びUnixを基礎とするOSに関する知識を持っていた。
しかし、新奇のシステムを検討しUnix様システムの働き方を知ろうとの、好奇心だけでLinuxを採用したユーザもあった。そのうり何人かは、Linxが嫌いになるか使用しないかで離れて行ったが、何人かは生活方法と哲学としてLinuxを採用した。
この新Linuxファンは、システムについて出来るだけ多くを学ぼうとするので、誰にも公開され、Ｃ及びアセンブラ言語で構築されるソースを手に入れて、Linuxを理解するには、プログラムの方法を習う決心をする。そして、これは実際に起こったことだが、沢山の新ユーザがプログラム作成し、勝手にコードをいじって、オープンソース社会に貢献する目的でプロジェクトに自分の時間と労力を捧げ始めた。今日では、首尾良く進むプロジェクトが沢山あって、フリー・ソフトウエア開発哲学が実際に役立つことを示している。
これら新プログラマは、ソフトウエア開発に必要なプログラム作成言語を学び、自分に必要なソフトウエアを開発し、期待の結果を生じながら知識を実用化した。しかし、これらの作品が全体として信頼性が高く、その考えを可能な最良の方法で実現しているのと保証はない。
これは、ソフトウエア工学分野の知識付属のため起こる。ソフトウエア開発と作成に余り経験のない人が開発したプロジェクトが余り沢山あるため、これらのプログラマに対する考え方と理論が欠如している。プログラムを作ることは、たと予想通りの結果が得られても、単にテキスト・エディタを立ち上げてコードを書きまくり、それをコンパイルすることではない。
プログラム作成言語の文法を知ることは、プログラムを作成し良品質のソフトウエアを開発する方法を知ることを意味しない。ソフトウエア開発は、最初のアルゴリズム設計からデバッグとテストの段階まで、複雑な過程である。os言語規範とその相異（つまりオブジェクト・プログラム作成とプロシージャ的プログラム作成）の概念を持たないプログラマ、スタック、キュー、リスト及びバイナリツリーなど、osデータ構造の数個の方を深く知らないプログラマ、又は、ハードウエアが算術演算をする方法及びその論理回路の働き方を知らないプログラマは、たとえ働いても、あるべき通りには実行されないソフトウエアを開発することがある。
正しい方法で実行されないソフトウエアは、CPUの処理時間やメモリ管理の方法などハードウエア・リソースの無駄を生じ、プログラマの労力を無にする。詰まらない問題を複雑で高価な方法を使って解決するとき、彼はもっと容易な方法を知らないので、言語を下手に、時には間違って使用して、そのの特徴を台無しにしてしまう。これら全部の事柄がプロジェクトの最終コストを押し上げる。
この種の問題は「ソフトウエア危機」として知られる。良いソフトウエア工学に関する正しい知識を持たないで切り刻みを開始しプログラムを作る各人がこの危機の増大に力を貸している。
将来、これは、主としてフリー・ソフトウエア社会に対し大変危険なことになる。場合によっては、一旦その幾つかのプロジェクトがボランティア・プログラマの手で開発されると、プロジェクトの開発段階を監視と調和を担当する人が誰もいないからである。
この問題の解決策は明らかだ。ユーザとプログラマは、ソフトウエア工学、及びモデル作成、アルゴリズム解析、ソフトウエア試験及びそれぞれの模範と言語の詳細を深く勉強しなければならない。開発者は、ソフトウエア工学についての科学論文と技術書籍をもっと読まなければならない。多くのプログラマは自分のソフトウエアが予期する結果を生じることを望むだけだが、プログラマが上手な開発者になり、高品質の信頼性のあるソフトウエアを作りることを望むなら、実務の下に隠された理論的基礎を知ることが不可欠である。理論的知識は、あらゆる事柄の基礎なのだ。
沢山のプログラムとプロジェクトが論文でスタートするが、アルゴリズムの草案を何か作るのは恥ではない。時にはアイデアが描画を通じてもっと良く理解することが出来る高い抽象レベルで達成されることがある。消費者の手に入る前にソフトウエアをテストすることもまた重要で、ソフトウエア・テストにまつわる沢山の技術や問題がある。幾つかのプログラム作成用言語と言語凡例を知ることは、問題を解決する方法を選ぶとき、プログラマにより多くの柔軟性を与える。各言語には、それ自体の限界があるからだ。ソースコードを同文にすることさえも、ソースの信頼性を高めるため必要である。これら全部の事柄が、良いソフトウエア工学に関係しており、作品の品質を改善する。
この記事は、趣味のプログラマを批判したり萎縮させたりするのを目的とするものではない。むしろ、ソフトウエア開発過程に関わる問題をもっと深く知ることを励ますものだ。その方法によってのみ、良質で信頼性の高いソフトウエアを次の世代に持つことができる。
この記事がお役に立つと良いと思う。母国語ではないので、下手な英語を御容赦願いたい。将来の記事では少しましになるかも知れない。ご意見、ご質問及びご教示を歓迎する。遠慮なくgustavorondina at uol dot com dot brにe-メールされたい。
著者紹介：
Gustavo Rondinaです。ブラジルから来ました。卒業目前のコンピュータ科学四年生の学生ですが、コンピュータとLinuxには５年間触っています。
multitail [-i] file
multitail [-i] file1 [-i] file2
multitail [-i] file1 -I file2
multitail /var/log/apache/access.log -I /var/log/apache/error.log
multitail -l ls
multitail -l "ping localhost"
multitail -R 3 -l "netstat -p tcp"
colorscheme:postfix
cs_re:yellow:status=sent
cs_re:magenta:queue active
colorscheme:syslog
cs_re:green:\[|\]
cs_re:blue:^... .. ..:..:..
multitail -e "gnu-pop3d" /var/log/messages
multitail -v -e "ssh" -v -e "gnu-pop3d" -e "localhost" /var/log/messages
| -f |
これによりMultiTail はファイルを追跡する。元のファイルの名前を変更し、元のナノファイルを新しく作ると、MultiTail は元の名のファイル（入力したもの）を監視し始める。 |
| -u seconds |
MultiTail を遅いリンク（モデモ接続又はHAM）で使うとき、更新を少し遅くしたくなることがある。このパラメータを用いて、MultiTailがウインドウを更新する頻度を設定する。規定値は、直ちに。 |
| -H interval |
暫く何も起こらないとき自動的に接続を切るホスト（その上でMultiTailを使用中）に接続しているとき、 '-H'を使うことが出来る。使うと、MultiTailは、行を上に上げて、トラフィックを発生しながらカーソルを画面の周りで動かす。 |
| -V |
使用中のMultiTail のバージョンを知りたい場合は、'-V' オプションを付けてMultiTailをスタートすると、バージョンを表示して終了する。走っている間に、 'i' キイを押すことも出来る。 |
| G A C E T A D E L I N U X ...Making Linux just a little more fun! |
| Veracruz, México を FLOSSが征服 By: La Gaceta de Linux |
先週 (2003年9月17-19 日 ) フリー／オープン・ソフトウエア専門家の国際的大群が、メキシコのポートオブベラクルスに、 GULEV Linux Congress. (GULEV = Veracruz LUG）第三版祝賀会の間集結した。
PostgreSQLプロジェクトからのブルース・モンジャン、Novell/Ximianからのミゲル・デ・イクザ、Piensa Technologiesからのフィリッペ・バーローズ、Debianからのブデール・ガービーなどの有名人を始めメキシコの主要ソフトウエア・エンジニア など世界中のFLOSSコミニュティの トップスター 達が、ベラクルスの三日間の行事の間に、コンファレンスや個人的会話を楽しんだ。
天気も良く、参加者達は経験、アイデアを共有し、新しいフリー技術を学ぶする喜びに満ちあふれた。
参加者のほとんどが、学生と十台から三十才前半の若いプログラマであったと言えるが、各セッションには、企業からの人が少しと、立ち止まってLinuxに興味を示し質問をしたりアイデアを述べるシニアの人さえもいた。色々な人が集まって良かったと思った。
この GULEV三周年では、ベラクルスの世界貿易センター.以上の筋書きは無かった。別の場所にLinux、フリーソフト、オープンソースが、このような行事を頼めただろうか？この場所は誠に最良であった。
一年目は大学構内だった。二年目は市内のホテルの宴会場だった。行事の主組織者ミゲル・ロペスとルーシイ・ミジャンゴスが、今年の行事の円滑な運営に多大の貢献をし、皆がコングレスのプログラムに満足して、メキシコのFLOSS運動が成熟し他のどんな技術とも互角に競合するとの感を強くして帰国した。「改善する必要が沢山ある」とミゲルが言うのには同感で、この種の行事には常に改善の余地があるが、二年前の最初の時からは、随分長い道のりを来たものだと思う。
コンファレンスの逸話とコンファレンスの後や次を待つ間に人々の言った意見で、私の聞いたものには次のものがある。
息子のメシューと一緒に来たブルース・モンジャンは、PostgreSQL管理の修得のセッションを開いた。ブルースの言うヒント、レシピなど皆が彼の話全部を良く聞いていた。メシュオと喋る機会があったが、彼は「親父と旅行するのは楽しい、メキシコ料理は、・・・ウーム」だった。
ブルースの次のコンファレンスは、PostgreSQLの空想的側面で次のバージョンに期待出来ることだった。
ラリー・ウォールが一緒にベラクルスに来る筈だったが、病気になった来られなかった。この記事が出る頃には良くなっていると思う。
ミゲル・デ・イクザは、Mono及び、それが如何にLinuxでｍｐソフトウエア開発生産性を向上させたかについて話した。ソフトウエア開発中に競争力を保ち強化するとき、最も強力なツールと技術を準備することに明確な関心を示した。
一方ブデール・ガービーは、今日のDebianの立場を話した。有名な技術研究者フランシスコ・デ・ウルキジョニエンブロは、メキシコで進行中のデジタル革命の現状を講義した。彼は「オープンでフリーな技術は将来・・・自動車、家庭、ビル、その他あらゆるものにオープン仕様書を持つだろう」と言った。
フィリッペ・バーローズのコンファレンスは、Zope社のZopeフレームワークと、それを大企業で既に使われている強力なビジネス・アプリケーション開発に彼が使った方法に付いてだった。「Zopeは、極めて廉価で、偉大で、強力で、使い易く拡張性のある・・・短く言えば理想的なウエブベースのビジネス・アプリケーションである」とまとめた。
フェデリコ・メナ・キンテラの参画は、ドラッグ＆ドロップ特性が必要な GTK+ におけるアプリケーションのプログラム作成に使用される概念とアイデアについてであった。
彼のコンファレンスの間に、フェルナンド・ロモが、アプリケーション・レベルに全てのロジックを委せるのでなく、データベース自体の中にアプリケーションのロジックを構築する概念について話した。示唆と経験の立派な集まりがフェルナンドのコンファレンスで討論された。
話題の一方で、グンナー・ウォルフがオブジェクト指向Perlについて話した。
ベラクルスで話された話題は他に沢山ある。クラスタ構築からWiFiネットワークの設計と構築、 Perl とPythonでのプログラム作成まで53個のコンファレンスがあった。
500人以上の人が、メキシコのFLOSSショーに参加するだけのためベラクルスに行ったことが確認された。行事に対する大きい感触は、全てのコンファレンス室とコンファレンス期間全部にわたって、フリーWiFiインターネット・コミュニティがあったことだ。
行事の終わりに、その翌日、「Tajin」と言う、ベラクルスから自動車で４時間の、歴史前廃墟へのツアーがあった。楽しみにしていたのに連絡を仕損じて、参加出来なかったのは残念。来年行く口実が出来た。
来年のコングレスはもっと良くなり、３版の間になされたように、色々な面で成長が見られると確信している。
それはそうと、メキシコのポートオブベラクルスは、数世紀前に征服者がしたように、ベンギンとFLOSSに全く征服されてしまった。