mywkfmnrのホームページ

全101件 (101件中 41-50件目)

< 1 2 3 4 5 6 7 8 9 10 11 >

2004年04月13日
XML
カテゴリ:カテゴリ未分類
こんどのプロジェクトで使用する小規模データベースの選定のためにOracle 10gの30日間体験版をダウンロードしてMiracle Linux 2.1評価版にインストールしようとしたのですが、そしたらびっくり。インストーラから門前払いの扱いを受けました。

日本オラクルのサイトでは、Oracle 10gはMiracle Linux 2.1でも動作することになっているし、Miracle Linux 2.1のサイトでは、Oracle 9i Release 2 対応キットをインストールすることでOracle 10gもサポートされるような記述があったので、よもや、このような扱いを受けるとは考えていませんでした。
クイックインストールガイドを読みながら、いろんな事前準備を行い、ようやく、インストーラ起動にたどり着いたのですが、インストーラを起動したとたん、サポート対象外のLinuxである旨のエラーになってしまったのです。
なに?、これ!
おかしいと思って、OracleやMiracle Linuxのサイトを探し回ったら、1箇所だけ、それも小さな注記で「4月上旬に対応予定です。」だって。
え~っ!
そういうことなら、もっとはっきりと、全ての箇所で書いて欲しいものですね。他の箇所の記述は、すでにサポート済みとしか思えないような記述になっているのですから。
それに、4月上旬って、もう過ぎてますヨ。

とりあえず、やりたかったのは、DBMSの比較評価なので、他のDBMSを先に評価することにして、その間にMiracle Linux 2.1がサポートされるのを待つことにしました。たぶん、Oracle 10g Release 1 対応キットのようなものが出てくるのでしょうね。

Miracle Linuxで こんな状況だと、KNOPPIXでOracle 10gを動かすなんて、無理そうですね。あきらめかな? これは。
KNOPPIXでOracleが使えると、便利だと思うんですねけどね。




(2004/4/14 更新1)
この問題を回避するためのツールとしてmlsetverというコマンドが、MILACLE LINUXでサポートされていることが分かりました。このコマンドを使ったらインストールできたという報告もあるようなので、明日(4/15)、このコマンドを使って再トライしてみます。






最終更新日  2004年04月14日 21時12分58秒
コメント(0) | コメントを書く


2004年04月11日
カテゴリ:カテゴリ未分類
前回の実験が失敗したのは、使用しているgccのバージョンの問題かも知れないと考えていたのですが、KNOPPIXには、gcc-3.3の他にgcc-2.95もインストールされているので、今度はgcc-2.95に変更して再トライしてみました。

その結果は、多少先に進んだのですが、やはり、同じmakeファイルの処理中にエラーになってしまいました。

Linking external procedure agent (extproc)
rm -f /home/knoppix/oracle/product/8.1.7/rdbms/lib/extproc
gcc -o /home/knoppix/oracle/product/8.1.7/rdbms/lib/extproc ...
/usr/bin/ld: /home/knoppix/oracle/product/8.1.7/rdbms/lib/extproc: hidden symbol `stat64' in /usr/lib/libc_nonshared.a(stat64.oS) is referenced by DSO
collect2: ld returned 1 exit status
make: *** [/home/knoppix/oracle/product/8.1.7/rdbms/lib/extproc] エラー 1

前回は最初のLinkでエラーになっていたので、それに比べれば、だいぶ進んだようですが、gcc以外にも問題があるということなんでしょうね。
glibcは2.3.2のままですし、Oracle 8.1.7にとって、KNOPPIX 3.3は新し過ぎて、合わないということのようです。

やはり、今度、Oracle 10gのLinux版の開発ライセンスを入手したら、メモリを512Mバイト以上積んだマシンを探してトライすることに期待するしかなさそうです。



過去のKNOPPIX関連日記一覧はこちら

KNOPPIX実験室








最終更新日  2004年04月11日 22時13分36秒
コメント(0) | コメントを書く
2004年04月10日
カテゴリ:カテゴリ未分類
この実験は2004年8月に成功しています。
以下は、なぜKNOPPIXでOracleなのかという点と2004年4月に失敗したときの苦労話です。
googleで検索してこのページに来ても、成功した記事になかなかたどり着けないようなので更新しました。(2005/4/2更新)

結果から言うと、うまくいかなかったのですが、実験してみたので、とりあえず、報告します。

OracleとKNOPPIX、非常にちぐはぐな取り合わせですね。普通に考えると、そんな取り合わせにどんな意味があるのと思われそうなので、まず、その辺から。

データベースを業務で使う場合、Oracleだと、これまでは最低でも数十万円かかりました。今月発売されたばかりのOracle 10gでは、最低価格は大幅に値下げされたので、10万円割れからOracleを選択できるようになりましたが、それでも、無償でインストール不要の簡単Linuxが売りのKNOPPIXには釣合いませんよね。KNOPPIXならMySQLかPostgreSQLを選ぶのが普通です。

しかし、Oracleをインストールする目的にはもう一つあります。台数的にはその方が多いかもしれません。それは、開発・評価目的のOracleです。

開発するデータベースが大きなものになってくれば、それにつれて、開発に携わる人、部署、事業所も増えてきます。
そんなとき、開発用のOracleサーバは、たぶん、部署ごとに別々に持つことになるはずです。
というのは、開発の初期段階(単体テスト~連動テスト)や、本番開始後の保守段階では本番用のデータベースには接続できないのが普通だからです。それでも、開発・テスト・調査などのためにデータベースが必要になるので、手元のあり合わせのマシンに本番用と同じバージョンのOracleをインストールして使うわけです。

以前は、このような開発・評価などを目的とする場合にも、製品版を購入する必要があるとされていました。それが数年前から変わってきました。開発ライセンスが無償~低価格で配布されるようになってきたのです。開発ライセンスというのは、開発・テスト・評価・調査などの目的に限定して使用を認めるというもので、配布されるCDに入っているパッケージは製品と全く同じものでした。体験版に良くありがちな使用期間制限や機能制限などはありません。私が初めて開発ライセンスを入手したのは、1999年秋にiDevelop1999というOracle主催のコンファレンスで参加者に無償配布されたときでした。当時のOracleの最上位エディションの開発ライセンスを入手できました。
現在は、OTN有償会員(約3万円/3ヶ月)になると、現在のOracleの全製品の開発ライセンスを入手できますし、今月発売されたばかりのOracle 10gなら、5月末までのキャンペーン期間中に申し込めば、わずか3千円で最上位エディションの開発ライセンスを入手できます。

このようにしてライセンスの問題が解決すると、次に問題になるのは、それをインストールするマシンです。
Oracleはこの数年間に非常に沢山のバージョンを発表してきました。Oracle 8以降だけでも、以下のような状況です。
・Oracle 8 : 8.0.3、8.0.4、8.0.5、8.0.6
・Oracle 8i : 8.1.5、8.1.6、8.1.7
・Oracle 9i : 9.0.1、9.2.0
・Oracle 10g: 10.1.0
これだけ、いろんなバージョンが矢継ぎ早に出てくると、同じバージョンのOracleを2度以上使うのはめずらしいケースになります。
結局、現状では以下のどれかを選んで対応することになります。
(1)新しいマシンを調達して新しいOracleをインストールする。(滅多に無い)
(2)古いマシンの古いOracleを削除して新しいOracleをインストールする。(よく失敗する。ひどいときはシステムごと再インストールしたことも。また、複数プロジェクトでの共有は困難。)
(3)古いマシンに複数のOracleをインストールし、必要に応じて選択して起動する。(ディスク領域の手当てと、開発プロジェクト間の調整が必要。)
(4)古いマシンの古いOracleを使い続ける。(新バージョンの新機能は使わず、無視する)

私の場合は、このうち(3)か(4)になることが多いです。

さて、ここからが本題。もし、KNOPPIXにOracleがインストールされていたらどうでしょう。サイズ的にCDブートは無理ですが、DVDブートかFAT32ブートならOK。データベースファイルとスワップを確保するためにFAT32パーティションは必要になりますが、メモリが128MB以上搭載され、FAT32パーティションに2~3GB程度の空きを確保できるという条件だけなら、意外に多くのマシンが使用できそうです。もっとも、メモリ128MB以上で使えるのはOrcale 8iまでの話で、Oracle 9i/10gは512MB以上のメモリが必要になりますが、デスクトップPCなら、空いているマシンからメモリを集めてくるなどにより、何とかなりそうです。

最近は事務用PCと実験用PCの2台のパソコンを一人で扱う場合も多くなってきました。実験用PCの方には多くの開発ツールと一緒に大抵Oracleクライアントなども入っています。しかし、この実験用PCにOracleサーバをインストールしようという話になると、ちょっと身構えてしまいます。新たにWindows 2000 ServerやMiracle Linuxなどをインストールするとこれまでに揃えた各種開発ツールが使えなくなってしまいますし、いつものWindowsにインストールするのは、上に上げた理由や、他にもいくつか理由があり、好ましくないのです。

反面、事務用PCにOracleをインストールする方には可能性があります。開発や実験の間は、事務用PCは空いているので一時的に転用できる可能性があるからです。もっとも、Oracleを事務用マシンのいつものWindowsにインストールするとか、新たにWindows 2000 ServerやMiracle Linuxなどを事務用マシンにインストールするというと、やはり身構えてしまいますが、KNOPPIXなら、FAT32パーティションに数GB程度の空きを確保し、そこにいくつかのファイル(cloopファイル、継続的ホームディレクトリファイル、スワップファイル、パッチファイルなど)をコピーして置くだけで良いので、現実味を帯びてきます。
他にも、同様な理由で、KNOPPIXで使うなら使っても良いというマシンは出てきそうです。

そこで、本当にKNOPPIXにOracleをインストールできないだろうかと思って始めた実験がこれです。
KNOPPIXにOracleをインストールする場合、大きく次の2つのケースがあると考えます。

(ケース1)cloopファイルは産総研製のものをそのまま使い、Oracleのプログラムとデータベースは継続的ホームディレクトリにインストールする。
(ケース2)cloopファイルにOracleのプログラムもインストールしてあり、継続的ホームディレクトリにはOracleのデータベースだけをインストールする。

使う立場では、(ケース2)の方が使い易いのですが、とりあえず実験してみるには(ケース1)の方が簡単なので、今回は(ケース1)で実験しました。
#もうひとつ、KNOPPIXをHDにインストールして使う方法があるといわれそうですが、HDにインストールするなら、Miracle Linuxなど、もっと良いLinuxがあるので、ここでは考えないことにします。

現在、私がOracleの開発ライセンスを持っているのは、Linux版ではOrcale 8i 8.1.6と8.1.7だけなのと、テスト機がノートパソコンで、メモリが384MBしかないことから、今回は8.1.7を使うことにしました。

次にインストール方法ですが、「Oracle8i for Linux Intel インストレーション・ガイド リリース8.1.7」を読むと、カーネルの再構成が必要になるように書かれています。私は昨年5月ごろ、FAT32ブートのままカーネルの再構成に挑戦して失敗しています。なぜ失敗したのか、ある程度分かってきたので、いずれ機会を見て再挑戦しようとは考えていました。しかし、今回、それをやらなければいけないとすると、うまくいくのか、少々不安でした。

そんなとき「Oracle8i R8.1.7 for Linux スタートガイド」を知り、そちらには、カーネルの再構成をしないで済ます方法が解説されていました。そこで、今回の実験では、このスタートガイドにそってインストールしました。このスタートガイドどおりにならない点は、以下の通りです。
(1) KNOPPIXではKDEを別のアカウントでログインしなおすというのが容易ではないので、スタートガイドに書かれているユーザ名・グループ名の追加はせず、「knoppix」をそのまま使用しました。(ユーザ名・グループ名共)
(2) JDK 1.1.8はBlackdown のFTP サイトからダウンロードしましたが、そのURLは少し異なっていました。
(3) ORACLE_BASEなどの環境変数の設定を追加するのは、「.bash_profile」ではなく「.bashrc」になります。
(4) ORACLE_BASEの位置は、継続的ホームディレクトリ内に確保するため、「/u01/app/oracle」⇒「/home/knoppix/oracle」に変更しました。
(5) インストール作業の途中で実行する構成スクリプト「root.sh」では、awkのフルパス名が/bin/awkになっていましたが、KNOPPIXでは/usr/bin/awkなので、このroot.shをkwriteなどのエディタで修正する必要があります。

以上のようにすることで、しばらくの間は、おおむね順調にインストールが進んでいきました。しかし、ある程度進んで構成スクリプト「root.sh」の実行を促すメッセージを表示する直前あたりで、makeがエラーになり、止まってしまいました。そのときのmakeのログの最後の部分は以下のようになっていました。
$ cd /home/knoppix/oracle/product/8.1.7/rdbms/lib
$ /usr/bin/make -f ins_rdbms.mk install ORACLE_HOME=/home/knoppix/oracle/product/8.1.7
chmod 755 /home/knoppix/oracle/product/8.1.7/bin
rm -f oracle ・・・
- Linking Oracle
rm -f /home/knoppix/oracle/product/8.1.7/rdbms/lib/oracle
gcc -o /home/knoppix/oracle/product/8.1.7/rdbms/lib/oracle ・・・(1159桁の長いコマンドライン)
/home/knoppix/oracle/product/8.1.7/lib//libdbicx8.a(sndwutl.o)(.text+0x1307): In function `sndwugtf_get_temp_file':
: warning: the use of `tempnam' is dangerous, better use `mkstemp'
/home/knoppix/oracle/product/8.1.7/lib//libpls8.a(spssimb.o)(.text+0x303): In function `pss_gets':
: warning: the `gets' function is dangerous and should not be used.
/usr/bin/ld: /home/knoppix/oracle/product/8.1.7/rdbms/lib/oracle: hidden symbol `__fixunssfdi' in /KNOPPIX/usr/bin/../lib/gcc-lib/i486-linux/3.3.3/libgcc.a(_fixunssfdi.oS) is referenced by DSO
collect2: ld はステータス 1 で終了しました
make: *** [/home/knoppix/oracle/product/8.1.7/rdbms/lib/oracle] エラー 1

なぜエラーになるのか、まだ原因は分かっていませんが、使用しているgccのバージョンの問題かもしれません。
Red Hat Linux 7.1に対して適用するパッチの解説を読んでみると、glibcなど、いくつかのライブラリは、Red Hat Linux 6.2互換の古いもの(glibc-2.1.3など)をインストールしないといけないそうです。より新しいLinuxには未対応になので、KNOPPIXのような最新のLinuxにインストールするのは無理があるのかもしれません。
結局、このエラーを解決することが出来ず、ここで中断しているのが現状です。


過去のKNOPPIX関連日記一覧はこちら

KNOPPIX実験室








最終更新日  2005年04月02日 11時13分20秒
コメント(0) | コメントを書く
2004年04月04日
テーマ:ニュース(92623)
カテゴリ:カテゴリ未分類
このニュース、前回、私がコメントした頃から、だいぶ様子が変わっていますね。

回転扉の利用自粛が広まっているというニュースを聞いて、ああやっぱり・・・という気がします。

この事故、死亡にまで至ったのは初めてのようですが、軽傷で済んだものまで含めると、あちこちで、かなりの数の事故が発生していたようですね。死亡事故になる確率は相当に低いでしょうから、それ自体が氷山の一角で、その下に膨大な軽傷事故があったということは、容易に想像できます。中には、骨折に至るようなものもあったようですね。
過去に2件以上この種の事故を経験しているところでは、今回の事故は身につまされて相当に怖かったでしょうから、自主規制に走る気持ちは分かります。
でも、こうなってくると、一事業者の問題ではなく、社会問題になってきます。初期の頃にあった、過去に軽傷事故が何回かおきたときになぜ抜本対策を打たなかったのかという議論は、安全基準が無いではないかという議論に変わってきたようです。
そうですよね。センサーの死角が取りざたされているようですが、安全基準が無かった以上、死角を広げたこと自体を非難することは難しいわけですし、技術者(畑違いではありますが)の目から言わせて頂けば、テープと人間を区別できないような原始的なセンサーを使っていて良いのだろうかという問題や、前回指摘したように仮に挟まれてしまっても事無きを得るような仕掛け(フェイルセーフ)なども検討の余地があると思います。適切な安全基準が設定され、より安全な形で戻ってくることを期待したいですね。ただ、行過ぎて、お役所の利権の餌食にされないよう、うまい落としどころを探って欲しいとも思っています。

私は、この事件には、もう一つの問題があるような気がします。過去に軽傷事故が何回も起きていたのに、なぜ、安全基準が無かったのだろうかということです。
私が当事者だったとすると、仮に自分の子供が事故にあって、怪我をした、あるいは骨折したとしても、生きていて、後遺症も無かったとしたら、ビルやメーカが誠意を持って対応してくれれば、それ以上ことを荒立てたりはしないでしょう。仮にビルやメーカの担当者だったら、被害者には謝罪し、不満が出ないようにいろいろ対応したとしても、外部には隠して何も言わないでしょう。それに、軽傷なら、他にも多くの事故が起こっているはずで、それらに埋もれて、あまり重要視されないかもしれません。
そういったことが重なって、あちこちで軽傷事故が起きていたにもかかわらず、見過ごされ、埋もれてしまっていたのでしょうか。
氷山のように海上に現れてくれば発見は容易ですが、すでに問題は大きくなっています。まだ海中に埋もれている状態で発見するのは難しいかもしれませんが、その状態でも埋もらせずに見出す仕掛けも考える必要がありそうな気がします。






最終更新日  2004年04月04日 12時20分01秒
コメント(0) | コメントを書く
2004年03月27日
テーマ:ニュース(92623)
カテゴリ:カテゴリ未分類
このニュースで、昔、電車の扉に良く手を挟まれたことを思い出した。私が小学校3~5年の頃のことである。
私は幸運だった。挟まれたのが電車の扉だったので何度挟まれても、そのたびに周りの大人に助けてもらい、かすり傷ですんだ。このニュースの子はたった一度挟まれただけで・・・。かわいそうに。

その後のニュースを聞くと、センサーで検出が遅れるだの、止まるまでに何十cm動くだのいってる。あたりまえのことじゃないか。
今の技術で突っ走ってくる男の子を事前に認識するのは容易なことではない。人間が何秒も前に危ないと気付いたって、機械はまだ気付いていない。数十cm手前でセンサーが働いたって、歩いてくるならまだしも、突っ走ってくるものに間に合うわけが無い。
しかし、子供にそんな危険があることを事前に察知できるわけも無いし。
かといって、回転扉は危険だからやめろという議論に発展するのも賛同できない。
効果的な対処方法はないのだろうか。

電車の扉に手を挟まれた経験から、ふと、ヒントに気付いたので、ここに書くことにする。

最近、電車のドアの引き込み口にだれかが手を挟んだといって満員電車が止まっている光景を見たことが無い。
私は、通学に電車を使っていたので、毎日、満員電車に乗っていた。それも、降りる駅でちょうど階段のそばに来る扉が好きだった。乗ってから、その扉が最初に開くのは降りる駅だった。いつも、友達と一緒に何人かで最後に乗り込み、降りる駅ではドアが開いたら改札まで競争だった。だから、挟まれる環境はそろっていたわけで、私か友人が電車のドアの引き込み口のわずかな隙間に手を挟まれて騒ぎになったことは、3年間に5~6回程度はあったのではないだろうか。
そのたびに、騒ぎになり、満員電車が数分止まっていた。

最近、電車のドアに子供が手を挟んだということを聞かないのは理由がある。ドアの引き込み口にゴムが張ってあって、手を挟まれても簡単に取り出せるようになっているのだ。これだと、引き込まれても、たぶん痛くないだろうし、かすり傷さえ負うことは無いだろう。
つまり、ヒントとは、このゴムを使うことである。
ニュースの映像を見ていると、回転扉の仕切りの前後に数十cmのガードがある。あのガード、固い素材で出来ているように見えるが、あれがゴムだったら、大事には至らなかったのではないだろうか。
センサーが働いてから停止するまで数十cmなら、それより少し広いゴムのガードがあれば、男の子が挟まれても、イテテぐらいで済む。
停止した後、ゴムの力で反対に押し戻され、数十cm戻ってから止まるようなら、男の子はすぐ脱出でき、事なきを得る。

私ごときが、日記に何か書いた程度で何か効果があるとは期待できませんが、どうしてもどこかに言いたかったので、ここに書きました。今後、この事件を教訓に、より安全性が高められたものが出てくることを期待したいと思います。






最終更新日  2004年03月27日 12時34分40秒
コメント(2) | コメントを書く
2004年03月13日
カテゴリ:カテゴリ未分類
カーネルのバージョンが2.4.22-xfs⇒2.4.24-xfsにアップした新しいKNOPPIXが登場しました。KNOPPIXメーリングリストには、さっそく、このバージョンアップの恩恵を受けたという報告がありました。たぶん、カーネルのバージョンアップのおかげでしょう。
このKNOPPIXの変更点は、KNOPPIXメーリングリストでのアナウンス[knoppix:3030]を見ていただくことにして、ここでは、このアナウンスで紹介されなかった変更点をいくつか紹介することにします。

1.dmaオプションがブートの最初の段階から適用されるようになりました。

これまで、dmaオプションを指定しても、適用されるのはknoppix-autoconfig実行後からでしたが、これが、linuxrcで最初にCDROMをマウントするよりも前にdmaオプションが適用されるようになりました。この結果、toramオプションやtohdオプションによってブート中に大きなファイルをコピーする場合にもdmaオプションが適用されるようになりました。

これまで、KNOPPIX実験室の実験1-6(オンメモリKNOPPIXの実験)で提供してきたminiroot.gzでは、/cdromにCDROMやFAT32パーティションなどをマウントしたとき、マウントしたデバイスに対してdmaオプションが適用されるようにしてきました。この結果、toramオプションの実行時間が短縮されるという効果がありました。(KNOPPIX実験室 実験1-6 2003/12/16の実験結果参照)

こんどのKNOPPIXでは、最初にCDROMをマウントするよりも前に全てのIDEデバイスに対してdmaオプションが適用されるようになりました。この結果、toramオプションだけでなく、tohdによってCDROM⇒HDにコピーする場合にもdmaオプションで高速化されることになると思われます。


2.fromhdオプションでfromhd=/dev/xxxx形式の指定がサポートされました。

fromhdオプションについて、knoppix-cheatcodes.txtでは「fromhd=/dev/xxxx」の形式で指定できると書かれていましたが、この仕様は、これまではサポートされていませんでした。(詳細はこちら) それが、このバージョンでようやくサポートされました。
本実験室で提供するminiroot.gzにはcdrom=/dev/xxxxというオプションがありますが、このfromhd=/dev/xxxxは、cdrom=/dev/xxxxと同じ結果が得られます。今後、本実験室で提供するminiroot.gzではfromhd=/dev/xxxxとcdrom=/dev/xxxxの両方ともサポートしていきます。



この新しいKNOPPIXに対応したminiroot.gzは先ほど実験1-6にアップしました。ただし、Howto3-4/3-5でKNOPPIX_20020031119-20040202版等を使って作成した継続的ホームディレクトリは、そのままではKNOPPIX_20040216-20040220版では使えません。この継続的ホームディレクトリをKNOPPIX_20040216-20040220版に移行する方法は近日Howto3-6としてアップする予定です。



過去のKNOPPIX関連日記一覧はこちら

KNOPPIX実験室








最終更新日  2004年03月13日 17時27分00秒
コメント(1) | コメントを書く
2004年02月27日
カテゴリ:カテゴリ未分類
夜行バス利用になるので、体力的にちょっと厳しいのですが、深夜に出発して早朝に到着するので、時間のロスが最も少ない方法だったりします。毎日、休みなく出ているようですが、安くて人気が高いようで、前日あたりに予約しても満席になっていることがあるようです。
先日の大阪出張中に知り、帰りに使ってみました。バスは、普通の観光バスだったので寝づらかったですが、夜寝ることを考慮してか、座席間隔はほんのわずかながら広いタイプのバスでした。昔、良く山に行っていた頃、夜行バスで尾瀬に行ったことが何回かありましたが、そのときは、普通の昼行用のバスと同じ座席間隔だったのを思い出して、アレに比べればと自分を慰めながら乗っていました。
このバス、最初は、土曜に帰れる予定だったので、土曜の夜発のバスを予約していたのですが、終了間際にトラブったため、数日延期になってしまい、キャンセル。結局、平日の夜行で帰ってきて、翌日はそのまま出社したため、かなりしんどかったですね。使うなら、やはり、翌日が休みになるようなとき(金曜か土曜の夜行)の帰宅手段に使う方が良いようです。
ただし、キャンセル料は高めなのでご注意を。私の場合、前日キャンセルだったので約40%取られました。当日キャンセルだと、約50%も取られてしまいます。
このバスの連絡先は、06-6258-6605/03-5705-3358。






最終更新日  2004年02月28日 03時00分04秒
コメント(2) | コメントを書く
2004年02月18日
カテゴリ:カテゴリ未分類
といっても、昨日ではなくて、2004/2/4のことです。

2004/2/3まで2週間半ほど大阪に出張に出ていたのですが、その仕事が一段落し、休みが取れたので比叡山行ってきました。

すでに、大阪市内や京都市内は何回か行ったことがあるので、今度は京都周辺の山に行ってみたいなと思っていたからです。源氏物語にも北山の聖や横川の僧都などが登場してくるので興味を持っていたことと、もともと山が好きだったからということもあります。
といっても、出張先からなので靴は革靴しかなく、普通なら山歩きはできません。比叡山ならケーブルカー・ロープウェイ・バスとアクセスも整備されているし、延暦寺もあるので道は参道として整備されているだろうと思って比叡山に決め、京都側から登って延暦寺周辺を散策後、琵琶湖に下りることにました。京都側にも琵琶湖側にもケーブルカーやロープウェイがあるので、それを使えば革靴でも問題ないはず、時間が許せば横川まで足を伸ばそうと考えていたのですが・・・。

行ってみてびっくりしました。低いとはいえ、やはり山ですね。ロープウェイの山頂駅を降りたら道に雪が積もって凍結していて滑り易くなっているのです。春~秋のシーズン中なら良く整備された歩き易い道だったろうと思いますが、凍結しているので非常に歩きにくくなっているのです。しかも、そんな道が延暦寺東塔まで延々と2Kmも続いているではありませんか。
また、シーズン中ならシャトルバスも運行しているようですが、冬季は運休。京都駅行きなどの路線バスなら1日3本程度運行しているようですが、時間が折り合いません。
このバス道なら凍結の心配は無さそうですが、大きく遠回りをしているので、ちょっと歩く気にはなりません。

かといって、せっかく来たのに引き返すのは癪なので、結局、この凍結した道を革靴で歩くことに。しかし、やはり、歩き始めの数分間に2回も転倒しました。
この道は、途中から山道に入るので、場所によっては転倒したら怖いようなところもあります。木につかまったり、少しでも雪の少ないところや雪が凍結せずに残っているところなどを探して歩いたりして、慎重にゆっくり行ったおかげで、一時間くらいかかりましたが、その後は転倒することなく、延暦寺の東塔まで到達しました。

この道、この先も西塔を経て横川まで続いているのですが、ずっと、似たような状態だと思われたので、その先に行くのはあきらめてしまいました。

東塔周辺には延暦寺の様々なお堂があり、その周辺の道は舗装され、十分に整備されていたので、ここは革靴でもなんら問題がありません。琵琶湖側からのロープウェイも、ここにつながっているので、革靴で来るなら、琵琶湖側からピストンした方がよいようですね。

この日は、シーズンオフで、しかも平日だったため、非常にすいていました。いくつかのお堂はたった一人で見学させてもらいました。
この日一日いて見かけた観光客(単にすれ違っただけの人たち)は、全部で数十人程度ではなかったかと思います。
1/31(土)に清水寺に行ったときは、相当な賑わいがあったのに比べると、雲泥の差ですね。

しかし、たった一人でスーツ姿で歩いても、何か虚しさがありますね。こんどは家族で行きたいな。道が凍結しているのは困るので、シーズンオフは外して、しかし平日のすいているときに、家族でゆっくりと横川あたりまで散策したい気がします。








最終更新日  2004年02月19日 13時04分59秒
コメント(2) | コメントを書く
2004年02月14日
カテゴリ:KNOPPIX
訂正:Javaを標準でサポートしたLinuxは沢山あると思っていたのですが、私の使ったことのあるLinuxの中では、Live Linux2だけでした。
最近発売の有償Linuxでは、以下のものでJavaがサポートされているらしいことはWebページで確認できました。
・Miracle Linux Standard Edition 2.1
・Red Hat Professinal Workstation
・Red Hat Enterprise Linux 2.1
しかし、私が使ったことのあるFTP版のLinuxでは、どれも、標準ではJavaはサポートされていませんでした。
重要な点で勘違いしていたことをお詫びし、訂正いたします。(以下の記述は訂正済みです。)

現在、KNOPPIXではJavaがプリインストールされていません。代わりにインストール用のスクリプトが添付されていて、自分でダウンロード&インストールして使うようになっています。
なぜ、そんな面倒なことになっているのでしょうか。
それは、KNOPPIXでは全てのプログラムがインストール済みで即使用可能な状態で配布されるという、通常のLinuxとは異なった特殊な側面があるために生じるJavaのライセンスの解釈の問題のようです。

JREはダウンロード、使用、再配布がフリーです。でも、ソース提供がなく、改変も認められていません。KNOPPIXの開発者は、この2点から、JavaをKNOPPIXで配布するのは問題ありと考えたのでしょう。

でも、JREをプリインストールしたCDブートLinuxが無いわけではありません。
Live Linux2にはJREがインストールされ、Tomcatもインストールされていました。
Java2 Standard Edition SDKはインストールされていませんでしたが、これは、当時、このSDKの再配布が認められていなかったからです。コンパイラなどの一部バイナリが再配布可能になったのは、Live Linux2の発売直前だったようです。でも、コンパイラが無いと、Tomcatだけあっても、Javaのプログラムを作れないので使い物になりません。そこで、かわりにjikesが入っていました。

では、KNOPPIXで問題ありと判断されたJREをLive Linux2でインストールされているのはライセンス違反だったのでしょうか。
ここがKNOPPIXとJava、いや、CDブートLinuxとJavaの関係の微妙なところで、判断の分かれるところです。
私は、Live Linux2のようにJREをインストールしてもライセンス違反とは言えないと考えています。
Live Linux2が何を根拠にこのような判断を下したかは不明ですが、私は、以下のような考えから、CDブートLinuxにJREをプリインストールして配布しても問題無いのではないかと考えています。
#これは、あくまで私の個人的な意見です。この意見が正しいのかどうか私には分かりません。
#この意見はあくまで参考にとどめ、最終的にはご自身の責任で判断してください。
#その判断の結果、何か損害をこうむったとしても、私は何らその責を負うことは出来ません。
#とはいえ、KNOPPIX(またはその派生版)を提供する権限と責任を持つ立場の方が、この意見を読んで、Javaをプリインストールして配布しても問題ないと判断してくれることを期待して、この記事を書きます。

(1)ソースが提供されない点について。

GPLのFAQに次のような記述があります。
http://www.gnu.org/licenses/gpl-faq.ja.html#MoneyGuzzlerInc
(GPLで保護されたプログラムを改変し、カネヨコセ社(Money Guzzler Inc.)から出ているポータビリティライブラリとリンクしたいのですが、私はカネヨコセ社のライブラリのソースコードを頒布することができません。そこで、カネヨコセ社のライブラリとリンクしたバージョンを改変したいユーザは、それらのライブラリを別に入手しなければなりません。どうしてGPLはこれを許可していないのですか?)

このカネヨコセ社をSun、ポータビリティライブラリをJREに当てはめて考えてみると、Sunはカネヨコセとは言っていないだけで、あとは符合します。つまり、JavaとGPLのプログラムを組み合わせたものを作ることは出来ないということでしょうか。
だからか、Javaを使ったプログラムにGPLを採用するものを私は知らないので、問題が無いのかもしれません。しかし、Javaで書いたプログラムからLinuxのシステムコールや各種のコマンド・プログラムを使ったりするのは問題ないのでしょうか。単に使うだけなら問題ないことが多いのでしょうが、いろんなライセンスのものが混在しているので、私には良く分かりません。
ただ、この問題はKNOPPIXだけにとどまりません。Javaをサポートする全てのLinuxに言えることです。
いまだに多くのLinux(FTP版)でJavaがサポートされない理由の一つはここにあるのでしょうか。

しかし、最近、有償版ではJavaをサポートしたものも出てきたようです。
・Miracle Linux Standard Edition 2.1 (標準で、SunのJava2 SDK 1.3.1-04が入っている。Tomcat 4.0.3も標準で入っている。)
・Red Hat Professinal Workstation (インストールCDには入っていないが、同梱の別CDでIBMとSunのJREが提供される。)
・Red Hat Enterprise Linux 2.1 (モデルによってはIBMのJREが標準でサポートされている。SunのJREは無し?)

本件は有償・無償とは無関係なはずなので、少なくとも、これらのディストリビュータは、本件に関しては問題ないと考えているということだと思います。
(2)改変を認めていない点について。

これは微妙な問題を含んでいます。
まず、改変とは、何処までを言うのでしょう。JavaのVMやライブラリを一部でも変更すれば該当することは自明ですが、これらを変更しない場合が問題です。
Sunから提供されるインストーラを使ってインストールした即実行可能な状態のもの(cloop)を配布することは、改変したものを配布することになるのでしょうか。
これが改変だということになると、面倒な問題が出てきます。KNOPPIXのcloopファイルを作成するということは、そこにインストールする多くのプログラムに、この改変を加えて、1つのcloopファイルに統合することだということになると考えるからです。ということは、複数のプログラムを改変して統合した1つのプログラムという位置づけになってしまうのではないでしょうか。GPLの場合、独立したプログラムの集合体なら、ライセンスの異なるプログラムを一緒に配布することが認められていますが、そうでなければ、全体がGPLでなければなりません。つまり、Javaはおろか、Apacheのようなものでさえ、ライセンスがGPLでないため、組み込めないことになってしまい、KNOPPIXのライセンスは破綻してしまいます。

KNOPPIXのような配布形態でも、GPLで言うところの独立したプログラムの集合体に該当すると言うためには、改変・統合とは別の見方をする必要があると考えます。

私は、通常のLinuxとKNOPPIXのようなCDブートLinuxは、配布とインストールのやり方が違うだけで、ライセンス的には同等であると考えます。
通常のLinuxは独立した複数のプログラムの集合体をCDROMなどのメディアに記録して配布し、エンドユーザが、インストーラを使って、これらのプログラムを特定のファイルシステムにインストールして使います。
これに対して、CDブートLinuxでは、独立した複数のプログラムの集合体をディストリビュータがCDROM上のファイルシステムにインストールして配布します。エンドユーザは、この配布されたファイルシステムをそのまま使います。

この両者は以下の点で同じです。
・共に独立した複数のプログラムの集合体を基にしています。
・実際にエンドユーザが使うものはインストールが終わったファイルシステムだという点も同じです。

違う点があるとすると、以下の点です。
・エンドユーザから見ると、CDブートLinuxでは、独立した複数のプログラムの集合体が見えません。
・インストール時にライセンス確認があった場合、それを確認するのは、CDブートLinuxでは、エンドユーザではなくディストリビュータになります。

この2点の違いを克服して、通常のLinuxとCDブートLinuxはライセンス的に同じ立場にあるということが出来れば、通常のLinuxでサポートできるプログラムなら何でも、CDブートLinuxにプリインストールして配布できることになるのではないかと考えています。
(3)独立した複数のプログラムの集合体がエンドユーザから見えない点について。

これについては、すでに類似の問題があります。GPLではソースをエンドユーザに提供することを求めていますが、現在の多くのLinuxの配布媒体からはソースは見えない点です。
これについては、インターネットからソースをダウンロードできるようにしたり、エンドユーザが要求すればいつでもソースを記録した媒体を実費程度の価格で配布できるようにすることで、問題無しとされています。
したがって、CDROM上のファイルシステムへのインストールに使用したプログラムについても、そのインストール用のバイナリパッケージに対して、ソースと同様な処置を講じれば、同じ論理で問題無しとなるのではないでしょうか。
実際、KNOPPIX本家では、このようなバイナリパッケージをインターネットから自由にダウンロードできるようにしてくれています。
(4)インストール時のライセンス確認をディストリビュータが行う点について。

これについては、ディストリビュータがライセンスを確認した時点で、そのライセンスをディストリビュータの責任でエンドユーザに通知し、確認を求める義務を負うと考えることで対処できるのではないでしょうか。そうすれば、ディストリビュータが、その義務を全うすることで、インストール時のライセンスをエンドユーザが確認したとみなすことが出来るようになり、問題は克服されると考えるからです。
その方法となると、すでに多くの先例があるので、おおよその見当は付くと思います。(少々面倒くさいものにはなりそうですが)

しかし、この問題は、インストーラでライセンス確認するプログラムだけの問題でしょうか。Linuxではインストーラでもライセンス確認しないものの方が多く存在しますが、これらのプログラムでも、ライセンスに同意しなければ使えない、あるいは、使ったことによってライセンスに同意したとみなされる点は同じです。
したがって、そのような仕掛けになっていることを包括的にでもエンドユーザに通知して、同意を求める必要があるのではないでしょうか。つまり、インストーラでライセンス確認するプログラムをプリインストールしたかどうかとは無関係に、全体の包括的なライセンスをディストリビュータの責任でエンドユーザに通知し、確認を求めることは、もともと、ディストリビュータに求められている義務なのではないでしょうか。
実際、Red Hat Linuxなどの統合インストーラを持つLinuxではインストールの最初の段階で、この包括的なライセンスの確認を求められます。
また、CDROMで配布されるものの場合には、CDROMの開封時にライセンスの確認を求めるのが一般的です。
KNOPPIXのようにisoイメージのダウンロードで配布されるものの場合は、ダウンロード時に、この包括的なライセンスの確認を求める必要がありそうな気がします。そして、その包括的なライセンスの中に、再配布する場合は、再配布者の責任でエンドユーザに包括的なライセンスの確認を求める義務があることを明記しておけば良いように思います。

以上のような対処をすることで、私は、CDブートLinuxもライセンス上は通常のLinuxと同じ立場に立つことが出来るようになり、通常のLinuxで配布できるプログラムなら何でも、CDブートLinuxにプリインストールして配布できるようになるのではないかと考えています。


過去のKNOPPIX関連日記一覧はこちら

KNOPPIX実験室








最終更新日  2004年08月17日 18時45分54秒
コメント(2) | コメントを書く
2004年02月11日
カテゴリ:カテゴリ未分類
注文を受けたといっても、実費提供なので、利益はほとんどありませんが、私の作ったものを使ってもらえると思うと、やはり、うれしいですね。

このCDROMは1月10日にマスタを作っているので、それをコピーして出すことも出来たのですが、その後、一ヶ月くらいの間に、いろいろと改良したいところが出てきていてました。せっかくの初ユーザなので、少しでも良いものにして出したいという思いがあり、もう一度、マスタを作り直すことにしました。

というわけで、今日は、先日着手したばかりのKNOPPIXでTomcatする実験は、今日はお休みさせていただきました。
#今週末には再開する予定です。

かわりに、源氏物語の世界 再編集版関係では、以下のようなことをやっていました。
・全文検索プログラムの改良
・jooxさんによる源氏物語の解説を読ませていただきながら、うちの再編集版と対応を取る作業
・csv形式の再編集版の解説の見直しなどです。

これらの結果は、数日中にアップしたいと考えています。






最終更新日  2004年02月12日 00時23分10秒
コメント(0) | コメントを書く

全101件 (101件中 41-50件目)

< 1 2 3 4 5 6 7 8 9 10 11 >

PR

X

© Rakuten Group, Inc.