これで、UnitedLinuxの中の協力者をSCOが訴えると脅かしSCO threatening to sue、自分のGNU/Linux関連活動を疑うsuspension of its own GNU/Linux related activities.との奇妙な状態が生じた。怪しげな法的位置に取り残されたSCOの GNU/Linux顧客はどうなるかと思うだけだ。SCOはSCO所有の知的財産（又は何か）を不法に販売した訳だから、多分SCOを訴えることになるだろう。
この状態を理解するには、Eric RaymondのOSI position paper を読むと良い。これは読む価値がある。この文書には、法律事件関連のUNIXの歴史の面白い概観が示されている。SCOの主張には、一つか二つの矛盾、間違い及び明らかな虚偽と誤魔化しがある。この狂気の沙汰のうち幾つかは、どのコードが（少なくとも非公開協定に署名しないでsigning a nondisclosure agreement）知的財産の侵害に当たるかを明らかにするのをSCOが拒んだとのLinux Weekly Newsの記事が強調している：
どんな結果に終わるかは誰もが考えるが、物語は未だ進行中だ。マイクロソフトのSCOソフトウエアにライセンスする決定 decision to license SCO softwareが、SCOの法的冒険に融資して、フリーでオープンソースなソフトウエアに対する信頼を損なう undermine confidence のを助けるのではないかとの疑いを生じる、味付けをする。Caldera-Microsoftの独禁法訴訟文書の書庫をSCOが壊したとの噂Reports がこのような推測に油を注いだ。新たな参加者 weighing inと意義を唱えられたコードの所有権主張とが、物事を更に混乱させた。面白い発展は、LinuxはSCO知的財産を不法に含むとSCOが言うのを禁止するドイツ法廷が与えた差し止め命令 granting by German courts of an injunction だ。
最良の行く末はRay Dessenが提案しproposed by Ray Dessen、Debian プロジェクト・リストとウィークリニュース報道されたものであろうで reported by Debian Weekly News：
IBMは、Royal Dutch Shellと地震データ処理のスピードアップの仕事をしている。Globus とGNU/Linuxを走らせるIBM eサーバとxサーバに基づくこのソリューションは、データの質を向上させながら、地震データの処理時間を短縮する。IBMはまた、RBC保険と関西電力を新しいGrid顧客として発表した。
６月29日（日）正午から６時までに オレゴン州ポートランド10番街1731で開かれるGEEK FAIR (バージョン3.0)を計画中である。フリー・コミュニティブロック・パーテーには、固定ディスクドライブ・シャッフルボード、生演奏、スケアダンス、食物、露店などがある。
地理的条件から大多数の読者はこの行事に参加するには問題があるだろうが、類似の催しをそれぞれの地域で計画する参考になるであろう。
Gelatoの技術的重点は、会員とスポンサが決定し、共同作業はGelato portalを通じておこなわれる。この半年で、会員数の増加を反映して、po-rtalの活動は３倍になった。Gelato portal を通じて利用出来るようになった最近の会員ソフトウエアには、CERNからの二つの業績：物質を通る粒子経路のシミュレーション用ツールキット GEANT4と、高エネルギ物理学用クラス・ライブラリCLHEP、及び、Gelato会員 NCARからの：多重ヘッド分光変形のライブラリSpectral Toolkitがある。
SuSE Linux CGL 版は、SuSE Linuxエンタープライズ・サーバ８の顧客に対しては、サービス・パックとして無料で提供する。GCLはOSDLの通信業者グレードLinuxワーキンググループ、つまりSuSE, HP, IBM, Intel 及び主要テレコム及びネットワーク装置プロバイダ をメンバーに含む.主導者、が定義した技術を組み込んでいる。
PostgreSQL 7.3.2 リリースと100%互換性があるMammoth PostgreSQL は、Win32、MacOSX 及びRed Hat Linux x86 のため、商業的に支援され最適化されたPostgreSQLサーバを提供する。
GNU/Linux とWindowsで利用することの出来るプラットホーム無関係PostgreSQL アドミニストレータ Mammoth pgManage 1.0もまたリリースされた。
AppendPDF Pro は、購入用に http://www.appligent.com/からと同時に、米国. General Services Administration (GSA) Advantage ウェブサイトから.入手出来る。
アジソン・ウェルズレイにいる人々が、私にこの本の書評を依頼したのは賢明だった。ウエブサイト・セキュリティは読者が完全には理解出来ない事柄だ。ここで本の帯の宣伝文や著者の推薦をしたりする気はない。代わりに単純な疑問に重点を置く。ウエブ開発者に実用的なことを教えて暮れるか？もしそうなら、$49.99払う価値があるかだ。そうでなければ暖炉にくべる。私は高価な分厚い結果読者を満足させない本には批判的だ。"Web Hacking" (ウェブハッキング)の中身を見てみよう。
"Web Hacking" は四つの章に分かれる。E-Commerce? Playground（電子取引？遊び）, URLs Unraveled（URLの内幕）、How Do They Do It?（彼らの手口）及び、Web Kung Fu（ウェブ・カンフー）だ。著者の出だしは良い－URLに雰囲気は不要なことを実感する。残りの部分に文法の間違いなどがあっても、ネット使用からは、これだけで十分だ。著者は、学問的なスタイルの上に、この本に適したオシャベリの会話的スタイルを重ねている。
「電子取引？遊び」は、簡単な事例研究から始めてHTTPだけを用いる小さい事業用ウエブサイトに対する効果的な攻撃を立証する。攻撃者は下手に書かれたPerlスクリプトを探す（ユーザは認めても、問題には役立つ）。著者は、ファイヤウォールと侵入検出が殆ど役に立たないと指摘し、この本では一貫してこれを主張する。これは覚えて置いた方が良い。確かに事例研究の攻撃は、Amazon又はDellには無効だが、摘み取りるばかりに熟した小型ウエブサイトは沢山あり、これらサイトのうち一つが、君のクレディット番号を持っていることもある。
１章 Web Languages（ウェブ言語）は、PerlからASP まで、あらゆることを、小さく纏めている。ここの考え方は、どの言語にも、賢いハッカーに狙われる弱点があると言うことだ。殆どのウエブ開発者とシステム管理者が、ここで学ぶ新しいことはないが、会社の将来のウェブサイトに完全な言語を採用するまでは、この章を飛ばさないのが良い。
２章Web and Database Servers（ウェブとデータベース・サーバ）は、極めて短くて、ウェブサーバ・フロント上のApache とIIS及びデータベースフロント上のMS SQL サーバとOracle だけを論じる。他のウエブサーバを論じていないが、各種HTTPサーバが沢山あってこれは最も変わった場所で起こるので、これは余り価値がない。Oracle及びMS SQL サーバについて実際にライセンスを有する種類の、企業レベル顧客のため書かれたセキュリティを扱う章は、別の本にした方が良い。ここで MySQL又はPostgreSQL を扱っていないのには失望した。世界では、気付くより多いサイトが、特にパパママ型の事業で、バックグラウンドにMySQL を使っており、正しく安全を確保したMySQL インストレーションが沢山ある。
３章Shopping carts and Payment Gateways（ショッピング・カートと支払い窓口）は、私に取って新しい材料だった。重要（価格など）情報の記憶に顧客側クッキーとGET変数を用いるシステムへの古い攻撃には慣れているが、支払い検証システムを巻き込む攻撃もあるとは考えなかったので、本の実例が供給設計の重要性を強調した。
4章HTTP and HTTPS: The Hacking Protocols,（HTTPとHTTPS、ハックキング・プロトコル）は、大部分を、攻撃者に必要な全ては、URLがキャリア選択を後悔させるようにすること事実の強調に費やしている。HTTPと HTTPSプロトコル取材ががサムネール調査に有用なことはさておいて、ネットワーク初心者に価値があるか疑わしい。
5章URL：The Web Hacker's Sword（ハッカーの剣）で第１部を終わる。この章には「スターウオース・エピソードIV：新しい望み」からの引用を前書きにしており、著者のおたく風を示している。５章は、URL構造やエンコードなど、、実際にURLハックを扱うと同時に、メタ文字いたずらとＨＴＭＬ形式を扱う。記述された攻撃の幾つかはGET変数のみに働く。これらはユーザに対するURLを通じる変数だ。だから、容易なウエブハックに対する簡単なヒントは：永続的なデータにセッションの使い、ブラウザからサーバに対しPOST変数でデータを渡すことと、警告している。私は、大学で長い時間働いたので、ユーザ入力を信じてはいけないと言われたときは信じる。抑も、"Web Hacking" の第１部は、全体として、新任の管理者、開発者に有用で、熟練専門家に取って新しいことがあるとは思えない。
第２部URLs Unraveled（URLの内幕）は、別の事例研究から始まる。この事例研究は、賢いハッカーが公開されたURLに基づいてウエブサイトを解析し、そこのの知識を攻撃の立ち上げに使う方法を示す。この事例研究は、後の章の動機付けに役立っている。
6章 Web: Under Cover（ウェブの内幕）は、ウェブ・アプリケーション構造の概観、と同時に目標システムを解剖するのにハッカーが使う方法を示す。ここには、ウェブサーバAPI、ODBC、JDBCをはじめとする異様な方法が全部ある。サーバプラットホームに対し内線を適合させるのに役立つ小さな章さえもある。著者は、露出を限定するため出来ることも述べており、良い考えは(私見によれば)エラーとメッセージがブラウザに漏れるのを防ぐことであると言う。この章をザッと眺めて事例を見るとよい。
７章Reading Between the Lines,（行間を読む）は、弱点を見付けて攻撃を仕掛けるため（"View Page Source"経由で）HTMLソースを解析する方法に重点を置く。短い開発サイクルでは見逃し勝ちな内容が冷静に述べられている。wgetとgrepの不埒な使用例もある。
８章Site Linkage Analysis（サイトリンケージ解析）は、解析方法の説明を続ける。この章は、主としてサイト解析用ソフトウエアツール幾つかの使用に重点をおく。それら全部は、（wgetを除き）ウィンドウズ・ツールである。この章では涙が出た。殆どの題材は明白だが、既に良く知っていたからだ。初心者全部と中級専門家は、掛け値なきこの章から学ぶことが多い。
第３部How Do They Do It（彼らの手口）は、この本の心臓部で、ウエブハッカー世界の「偉大な魔術の種明かし」となっている。９章Cyber Graffiti（サイバーの落書き）は、一般にメディアで報じられたウエブサイト汚損攻撃を扱う。詳細な事例研究が、プロキシサーバ構成、HTTP認証、直接ブラウズを含む多数のセキュリティ問題、を扱う。
10章 E-Shoplifting?（e-万引き）は、幾つかの販売業者をつなぎ合わせたe-取引システムの事例研究を示す。基本的な攻撃は、顧客側書式認証と価格情報を渡す隠しフィールドに基づいていた。監査人が明らかにしたリスクを目的とするサイト修理が詳細に述べられている。
11章Database Access（データベースアクセス）は、短いが興味のある攻撃と、しっかりした防御を述べる。
12章Java: Remote Command Execution（Java：遠隔コマンド実行）は、私には新しい分野だった。JavaよりCOBOLのプログラムに興味があるが、賢い開発者として、JAVAが普及しているのは知っている。この章では、スマートなことを学んだが、持ち帰りたい重要なことは、常にユーザ入力を殺菌して濾過することだ。servlet管理に基づく対策もまた述べられている。
13章Impersonation（擬人化）は、セッション、セッション乗っ取り、及びクッキーを扱う。この章は面白いが、開発者が、推測可能なセッションIDを作ったり、クライアント使用のクッキーに重要データを記憶するなど、余程馬鹿げたことをしない限り、これらの攻撃は、怖くない。
14章Buffer Overflows: On-the-Fly?（バッファ・オーバーフロー：進行中？）は、これだけで一冊の本に纏められる。近頃聞く弱点の殆ど全部は、バッファ・オーバーフローによる。この章は、極めて技術的な題材を扱うので、Ｃ又はASMコードに出会うことがある。この章は、サイトの弱点全部が、情報システムの消費者側の下手なプログラム作成又はシステム管理によることを強調するより他に価値があるかは、良く分からない。Sun、IBM、Microsof、及びそれらの同族は全部、既に知られたバッファ・オーバーフローを伴って出荷されている。販売業者さえも間違いをする。第３部は、必読の部分である。全体として、読むに値する。著者は攻撃を解剖するのに良い仕事をしており、「身元に拘わらず入力全部を検証」するとの簡単な対策を強調する。
第４部Advanced Web Kung Fu（最新ウェブ・カンフー）には、目を見開いた。全くの驚きだった。15章Web Hacking: Automated Tools（ウエブハッキング自動化ツール）は、普通に使われるハッキングツールの単なる概観だ。正直なところ、知っているのはnetcatだけだった。論じられた唯一のUnixツールだからだ。この比率に苦情を述べる気はない。
16章Worms（虫）は、インターネットを破壊した有名な虫の単なる概観だ。
17章Beating the IDS（IDS退治）は、侵入検出システム(IDS)に対しすることの出来る面白いことを扱うが、それは単なる好奇心だけだ。この章は、「最新ウェブ・カンフー」より「酔っ払いを見ていない間に棒で叩く」のに似ていて、この本では最も詰まらない部分だ。
17章Beating the IDS（IDS退治）は、侵入検出システム(IDS)に対しておこなうことの出来る興味ある事項を扱うが、単に好奇心だけだ。この章は「最新ウェブ・カンフー」より「酔っ払いを、見えない時、棒で叩く」のに似ていて、この本で最も失望する部分だ。PHBの自己満足のため書かれたような気がする。上手くやっている人への侮辱だ。
近頃の有能な開発者が、この本で詳説する攻撃に敏感なアプリケーションを展開することが（セッションの使用だけでもこれらの攻撃が無効になる）少しの言い訳になるが、この本は、一般的に開発初心者と管理者が読むのに値する。もっと熟練した開発者は、立ち読みするかインターンに売りつけると良い。492頁あるが、$49.99は高過ぎる、$24.99でも高い。
最近まで、バックアップ作業の範囲は、時々自分のホームディレクトリのCDコピイを取って、重要ファイルのコピイを、普通は別のディスク・パーティションかフロッピイなど別の場所に保管するだった。
これら全てはWindows遺産アプリケーションを走らせる必要から変わってしまった。この仕事に適した唯一のマシンは、私の主ワークステーション、四つのディストリビューションに多重ブートする1.2 GHz Athlonマシンだった。私は、Mandrake 9.0,を保持する第一基本パーティションを首にして、Windows パーティションを設定することにした。
内容を７番パーティションに移して第一基本パーティションを空け、拡張可能Vector Linux 3.0 ディストリビューションを上書きした。安全のためDebian 3.0にブートし、両パーティションを /mntににある個々のmount点にマウントし、ルートとしてtarとpipeを使って、全てのリンクとパーミッションを含む何もかもをソースパーティションから目標パーティションに移した。数分経って、grubブートメニューを変えた後、７番パーティションにあるMandrake 9.0 Linuxにブートすることが出来たので、全てが予想通りであることを確かめた。
この時点で、空けた第一パーティションをDOSフォーマットしてWindowsをインストールするのが普通だが、少し心配になった。Windowsはドライブ全体をフォーマットしたり何かへまをすることがある。そのときは、パーティションをfdiskして初めから何も彼もインストールし直さなければならない。元のディスクには、自分でインストールしたものを除いて、勿論アプリケーションすべてが入っているが、特注コンフィギュレーションが無くなってしまう。
マシンは現在、Mandrake 9.0、Debian 3.0、Slackware 8.1を走らせている。このうち、Slackwareを喪うだけでも悲しかった。これはサインを含め、KDE 3.0に30秒以下でブートした。とてつもなく安定だった。LAN上のプリンタ用CUPSプリントシステムも持っている。だから、この設定は何としても保つ必要がある。解決策は、Slackwareインストールから全てをバックアップすることだ。
この点から、簡便で誰でも出来るバックアップと復元の方法が欲しくなった。
ホーム又はSOHO Linux ユーザであれば、以下を薦める：
最近のGazette 記事見直しと、ウェブ検索により、多数のバックアップ解決策がある。多くはバックアップ機能を専門的に扱い、その多くは、予め定めて状態に戻るための全体作業の修復とシステム復旧を扱っている。自分のシステムや固有の要求に合わせたものはないので、自分の解決策を見付ける必要がある。それをここでおこなう。
ホーム又はSOHOユーザの多くは、テープドライブを持っておらず、バックアップの目的で買う気もない。テープ・システムもソフトウエアもコンピュータ自体より高い。必然的に可動ディスク、同一又は別のハードディスク、CD、ネットワーク経由で別のハードディスクへのバックアップとなる。この最後は、自分のシステムがダウンした時を除いて、複雑なバックアップとなる。そこで三つの選択肢を検討する。
フロッピイ －日常の追加パックアップに良く、進行にしたがって仕事をバックアップするのに最適だが、システム全体の復元には実用にならない。 LS120 Disk とthe Zipディスクはここで考える簡便で完全なバックアップには十分でない。
ハードドライブ －同一ドライブの別のパーティションにパックアップ出来るが、そのドライブが故障すると使えない。同一コンピュータの別のドライブにバックアップ出来る。これは良い方法だが、停電や近くの落雷で（又はコンピュータ盗難）両ドライブが壊れると復元のため何も残らない。
ネットワークファイルシステム －これは、インストールの方法を正しく知っている人には、ファイルのバックアップと復元に良い方法だが、ファイルを復旧できる時点までシステムを戻すには役立たない。複雑過ぎる。
CD-ROM －これには興味がある。殆どのLlinuxにCDバーナがありCD-RWの入手も容易で、在来の回転パックアップシステムと似ている。これが我々のためのものだ。
最も基本的な要件は、CDバーナがあることだ。今のLinuxディストリビューションには必要なツールがあるので、費用を最低にするには、約4ドルで良質なCD-RW２枚が買える。日常のバックアップには約5年半持つので、週一度のマシン使用なら永久に持つ。
ここで提案する計画は、２枚のCD-RWを交互に使う方法で、私は、交替を正しくするためディスクケースの背に赤と緑でカラーコードを付けた。
バックアップ・ディスク自体が実働Linuxシステムにブートする必要もある。これはマスター・ブート・レコード(MBR)と必要あれば元の残りのパーティションを再建することが出来るのを確実にするためだ。これは、大多数のディストリビューションで普通に供給されたままのブート・デスク・イメージの使用を禁止する。
自己ブートCD上の小型Linuxを早読みした後、TomsRtBt ディスクを2.88 MBイメージ・フォーマットで試すこととした。これはISOイメージではないが、焼き付けるISOのブート・イメージにするには適している。これは、ウェブにある別の各種のソースでも見出される。私はこれをフロッピイ・フォーマットで使ったが、良好で完璧だった。これにはTomのFAQもある。
稼働中のLinuxシステムを与えられた状態に復旧するには、日の単位で変わる、つまり処理インストールから変わった現在のディレクトリ内容全部を記録する必要がある。これは、復元しなければならないものを最低にする検査と詳細リストにより難儀しておこなうか、又は、これらディレクトリの内容全部をバックアップすれば、容易におこなうことが出来る。.
私は、Slackware 8.1パーティションの /home /etc /usr/local /opt /var /root /boot の内容全部をバックアップすることに決めた。
上述の各ディレクトリ内容に加えて、ブートに突然の不具合があったとき無いと困る極めて重要な情報がある。MBRのバイナリコピイ、、パーティション・テーブルのテキスト・リスト、どのパーティションがどのファイルシステムに相当するか忘れた場合のfstbファイルのコピイ、及び任意選択で今のXF86Configファイル及び／又はlsdevやlspciなどのコマンドの全システム情報に関するテキスト出力だ。
この情報全部を、完全に自己充足で手元の課題に使えるよう、確実にCDに収容するためどのように構造化するが問題だ。
私のしたことは、先ずバックアップする情報全部を収容するディレクトリを作る。ルートとしては、mkdir /tmp/backup。ここで、バックアップCDの定数部分のレポジトリとして /tmp を使っていることに注意。Slackwareではこれが安全だが、他ではそうでもないかも知れない。安全で、tarにより自分自身をバックアップしない場所を選ぶこと。
バックアップ・ディレクトリにTomsRtBt Img ファイルをコピイする：cp ./tomsrtbt288.img /tmp/backup/tomsrtbt288.img 。ここで Img ファイルは、私のホーム・ディレクトリだ。
バックアップ・ディレクトリにマスター・ブート・レコードをコピイする： dd if=/dev/hda bs=512 count=1 > /tmp/backup/MBR.bin。この MBRは、採用するブート機構の第一ステージを保持する。私の場合はCrubのステージ１、GRand Unifiedブート・ローダ、又はLILOである。基本パーティションに関するパーティション情報も保持する。拡張パーティション情報は、ディスク上のどこかに保持されるので、必要ならば、次に詳説するfdiskコマンドから記録する情報とともに記録することが出来る。
バックアップ・ディレクトリにパーティション情報のリストを入れる：fdisk -l > /tmp/backup/Partition_Table,、これは復旧する前に、パーティション・テーブルのTomのリストと比較するのに使われる。
バックアップ・ディレクトリに、ファイルシステムのマウント点を定義する fstab をコピイする。ここでエラーがあると、ファイルとデバイスにアクセス出来なくなる。cp /etc/fstab /tmp/backup/fstab.bak
任意選択で、新しく復旧したLinuxシステムにブート出来るようになる前に利用したい別の情報があれば、コピイする。アクセスを容易にするため、私はXF86Configをディスクにコピイして、新システム更新をインストールするときであっても、常にＸを自分の望む方法で設定出来るのを確実にした。またGrubをブート・ローダに使うのでmenu.lstもコピイした。 cp /etc/X11/XF86Config /tmp/backup/XF86Config.bak ... cp /boot/grub/menu.lst /tmp/backup/menu.lst.bak
これらのファイルは、焼き付けるバックアップ・ディスクの各コピイに追加したので、そのうち一つが変更されたとき、上書きして変更するだけが必要だ。
これをおこなうスクリプトを下に示す。テキストコピイは backup.を見ること。.sh.txt部分のないファイルは必ずrenameして実行可能にすること - chmod 755 ./backup - また、ルートPATHのどこか、/usr/local/bin が良い場所、にコピイして、同じことを次のスクリプトにおこなうこと
#!/bin/bash
# バックアップ
#------------------------------------------------------------------------------
# 重要Linuxファイル全部の簡易バックアップを可能にし
# 特注システム修復ディスクを作るためのスクリプト
# バックアップ交替のため"赤"と"緑”ラベルのついたCD-RWケース二つを使う。
#------------------------------------------------------------------------------
# バックアップディレクトリには、既にブート用と修復用のディレクトリがある。
# もっと追加することが出来る－私のSlackware 8.1 システムバックアップは、< 580MB.
Backup_Dirs="/home /etc /usr/local /opt /var /root /boot"
Backup_Dest_Dir=/tmp/backup
Backup_Date=`date +%b%d%Y`
Image_File=/tmp/backup.iso
declare -i Size
# 識別を容易にする目的で、本日の年月日のついたファイルを作る
tar cvzf $Backup_Dest_Dir/$Backup_Date.tar.gz $Backup_Dirs &> /dev/null
# ローカル CD-RW ドライブに対するバックアップ処理を開始
echo "Backing up $Backup_Dest_Dir to CD-RW Drive - $Backup_Date"
echo "Creating ISO9660 file system image ($Image_File)."
mkisofs -b toms288.img -c boot.cat -r \
-o $Image_File $Backup_Dest_Dir &> /dev/nul
# 焼き付けるディレクトリのサイズを MBで点検
Size=`du -m $Image_File | cut -c 1-3`
if [ $Size -lt 650 ]
then
echo "Size of ISO Image $Size MB, OK to Burn"
else
echo "Size of ISO Backup Image too Large to burn"
rm $Backup_Dest_Dir/$Backup_Date.tar.gz # Remove dated tar file
rm $Image_File # ISO は次のバックアップが上書きするが、いずれは消去される
exit 1
fi
# CD-RWを焼き付ける
Speed=4 # 自分のシステムのCD-RWに最適の速度を用いる
echo "Burning the disk."
# cdrecord -scanbusから dev=x,x,x を設定
cdrecord -v speed=$Speed blank=fast dev=1,0,0 $Image_File &> /dev/null
Md5sum_Iso=`md5sum $Image_File`
echo "The md5sum of the created ISO is $Md5sum_Iso"
# md5sums を検証するため、ここでMd5sum_Isoを使ってTESTすることが出来るが、問題は、扱い難い
echo "To verify use script md5scd, this will produce the burned CD's md5sum"
echo "run this as User with backup CD in drive to be used for recovery."
echo "This verifies not only the md5sum but that disk will read OK when needed."
# イメージファイルを削除してファイルをtarする
echo "Removing $Image_File"
rm $Image_File
echo "Removing : $Backup_Dest_Dir/$Backup_Date.tar.gz"
rm $Backup_Dest_Dir/$Backup_Date.tar.gz
echo "END BACKUP $Backup_Date"
echo "Be sure to place this backup in the RED CD case and previous CD in GREEN"
echo "------------------------------------------------------------------------"
exit 0
使用の過程は簡単だ。私は毎日、システムを余り使わないときは毎週、バックアップする。バックアップ開始の度に、緑のCDをバーナーに入れる。xterm でルートにsu して、コマンドnohup backup &> /tmp/backup.log & を発し、xtermを選んで寝てしまう。バックアップには15分位しか掛からないので、便利な時間にすれば良い。次にはコンピュータで、cat /tmp/backup.log してるバックアップが上手くいったことを確認する。
バックアップISOを検証したいときは、記載されたISO md5sumの最初と最後の4,5文字を記録する。私のバーナーは書き込んだばかりのCDを信頼性高く読まないので、CDを自分のcdromに移してスクリプトmd5scd（下を見よ）を使ってmd5sumsが同じであることを検証する。同じなら、新しく焼き付けたCDを赤のケースに入れ、最後に焼き付けたCDを緑のケースに入れて、次のバックアップに備える。混同のおそれがあるときは、tarファイルの日付を点検することが出来る。バーナーはバックアップCDを正しく読まないことがあるので、md5sumsの自動チェックは含まなかった。検証の失敗がCDのエラーではなくバーナーからの読取だけしか意味しないからだ。事実、cdromを使ったときは md5sumの比較に失敗したことがない。MD5チェックサムは不可欠である。たった一つのビットエラーでも圧縮アーカイブ全体を損傷することがあるからだ。
#!/bin/bash
#------------------------------------------------------------------------
# md5scd ---- Data CD md5sum Verifier
# ISO9660 CDのため Md5sum を自動判定するスクリプト
# 注記 - このスクリプトは正しいmd5sumが知られているとき
# 特定のCDコピイが正しく焼き付けられたことを検証したい場合を想定する。
# ダウンロードISO イメージで作業するときは、コマンド行で "md5sum ISO" を使う。
#------------------------------------------------------------------------
# Linux ディストリビューション全部に見られる標準ツールが必要。
# ユーザとしてこのスクリプトを呼び出すときは、パーミッション、グループなど全部を点検のこと.
# アーギュメント脱落？
if [ $# -ne 2 ]
then
echo "Usage - md5scd mountpoint device, ex - md5scd /mnt/cdrom /dev/hdc"
exit 1
else
: OK have arguments
fi
# md5sum 判定全体をループ ... install-festのため良いコピイ100?
again=yes
while [ "$again" = yes ]
do
echo "Please insert CD at $1 and press ENTER when ready"
read #ディスク挿入を待つ
mount $1
Block_Count=`df -k $1 | grep $1 | cut -c 25-30`
#700Mb ディスクはこの^^^^^ カラム限界を1k ブロック超えられない
umount $1
Md5sum_Cd=`dd if=$2 count=$Block_Count bs=1024 | md5sum`
echo "The md5sum of the CD at $1 is " $Md5sum_Cd
echo
echo -n "Verify another CD? [yes/no]"
read again # Wait for "yes" -> repeat, anything else -> drop through'
done
exit 0
バックアップがブートすることを最終的に確かめる前に、tomsrtbtの限界を承知し、利用出来る唯一のエディタはVIなので、バックアップ・ディスクに置かれた各種ファイルの読取に習熟すること。ディスクは先ず mount -t iso9660 /dev/xxx /mntでマウントしなければならない。tarしたファイルは、先ずgzip 次いで tarを用いることによりtomsrtbt を使って unzip しuntar することが出来る。
しかし、先ずパーティション・テーブルが正しいことをfdisk -lを使い、記憶したテーブルを参照してチェックし、正しくなければ、MBRを修復するのが良いだろうdd if=/mnt/MBR.bin of=/dev/hda bs=1 count=512 。これは、基本パーティションとブートローダを修復する。次いで fdisk とパーティション・テーブル・ファイルを使って人手で拡張パーティションと中の論理パーティションを修復する。これには神経と経験が必要だ。しかし、確信が無いか練習だけなら変更全部を中止することが出来る。
次に、今は正常になったパーティションに正常なインストールをおこなう。ルート・コンソールのある場所にブートし直す。バックアップCDを取り付けて tar xvzf /Mount_Dir/Backup_Tar_Filenameを実行する。これで、以前のディレクトリ全部を正しい場所に復元して、殆ど完全に復旧したシステムを残す。
問題が喪失又は破壊されただけのファイルであるときは、セーブした任意のディレクトリを任意の時期にtar xvzf /Mount_Dir/Backup_Tar_Filename /homeなどを、用いて復元することが出来る。
あらゆるシステムのてすとは、「働くか？」だ。私は最初にバックアップCDがTomのLinuxシステムにブートして、テキスト資料全部が読めることを検証した。勿論fdisk -l が記憶したバージョンに対応していた。MBRは、バイナリ・イメージ・ファイルから元に戻すことはしなかったが、必要ならそこにある。
最終テストは、私のSlackware 8.1システムを、Windowsのインストール前で、多分復旧を必要とする前に、元のMandrake 9.0の場所に戻すことだった。
短く言うと、
これは追加の5分で、バックアップしたパーティション内容全部をインストールし直し、Ｘ設定とkdeログインで復元したslackware 8.1 に入った。/dev をセーブしなかったので、デバイス・パーミッションの幾つかを再設定しなければならなかったが、細かいことだ。全体の処理に掛かったのは半時間以下だった。通常のインストールと、それに続く好きなプログラムロードの長い手順には程遠い。.
バックアップはするのも続けるのも易しい。 使用の際には、数多くの改良を加えることが出来る。人手のバックアップと検証のコマンドは、シェル変数にして単一の言葉で呼び出すことが出来る。またファイルの全サイズが使用の要因になるときはtarの--除外フラッグを使って不変なコードの大きい部分をtarファイルに含ませないか、又はbzip2圧縮を使うことが出来る。今のままで、完全なディレクトリがルートからセーブされる。
Windowsアプリケーションに関する差し迫った必要はそれほど緊急ではなくなったが、定期的にバックアップする製品を作った。私の次の計画は、多分Wineをインストールしてこの厄介なアプリケーションを再ブートの必要なくLinuxの中で動かすことだろう。
改善のご意見に興味がある。どんなご意見も歓迎する。明らかな欠点や脱落は特に歓迎するこのアドレス this addressに連絡されたい。この計画は短時間しか使っていないが、今のところ満足している。定期的バックアップの確立をお薦めする。迅速な既製方法をお望みならこれを使われたい。スクリプトを少し変更すれば日々のバックアップに役立つ筈。
この記事は著者がポーランド語から翻訳した。原文はCHIP Special Linuxの夏季号で発表される。
好みのディストリビューションの新バージョンが出たときはいつでも、何もかも初めからインストールするか、更新するか使い慣れたものを続けるかで迷う。
極端な可能性二つを考える：システムを初めからインストールしてコンフィギュアするのは、新しい特性全部を見付けて使うことが出来る一方、今のままに止まると何の障害もなく今のプロジェクトを続けることができる。直面するのは、革新と安定との間のありふれたが抗争だ。
システムの基本的コンフィギュレーションは難しくない。必要が多ければ、作業量も多くなる。システムのインストレーションとコンフィギュレーションを楽にする方法はあるだろうか？完全で明確に設計した基本に、導入した変更に関する情報を含み、システムの前のバージョンで働かせると、新バージョンへの適合が遙かに容易になる。この方法は、データを集めればそんなに複雑ではないが、コンフィギュレーションを復元するとき作業量が多くなる。どうしたら自動化して簡単にすることが出来るだろうか？
幸い、Linuxは各サービスのコンフィギュレーションに付いての情報をテキストファイルに記憶する。その上、このファイルの処理のため沢山の極めて良いツールを与える。だから、正しいスクリプトを作り、システムをもう一度インストールするとき、それを使うだけで十分だ。
この記事は、スクリプトのグループを二つ述べる。第一のものは個別パケージのインストールと削除に、第二のものは、システムを侵入に対し安全にするのに用いる。両方ともSlackware Linux用に設計した。パケージのインストールと削除のためのツールは、SlackPkg 又はPackwareからのプログラムのように洗練されていないが、システム全体を完全に制御する。システム安全のスクリプトについても同じだ。これらは、基本的動作だけをする。ツールの両セットは、slack*moreバンチに集めた。
パターンにすると、任意のサービス又はコンフィギュレーションの処理を自動化するため別のツールを用意することが出来る。人手ではシステムを全く合わせないが、引き続くプロシージャで適切なスクリプトを補完すると決めたときは、システムをコンフィギュアするための自分のプログラムが手に入る。さらに、これらのプログラムを自分で作るので、好みに合ったものとなる。.
Slackware Linuxを例に説明したのは、これが自然な方法でユーザをコンフィギュレーション・ファイル・ディレクトリにつなぐからだ。この目的で複雑なプログラムを提供する他のLinuxは、コンフィギュレーションに付いての情報を含むファイルからユーザを遠ざける。したがってそのプログラムはユーザを怠け者にするか又は、システムの中で所謂フレンドリなプログラムで実際に変えられたのは何で何時かを確かめるのに高等な調査を強制する。
Slack*more は、二つの部分に分かれる。INSTALL.tgz アーカイブは、プログラムの搭載、削除又は更新のためのツールを含む。SECURE.tgz アーカイブは、システムを予備的に安全確保するためのものだ。
図１．./Slackware-9.0 ディレクトリからのSCRIPT.sh スクリプトのお陰で、個別グループから沢山の明確なリストを作ることが出来る。図は、ｄ（開発）グループからのパケージのリストを示す。
INSTALL.tgz パケージの最も重要な成分は INSTALL.sh スクリプトと、SCRIPT.sh スクリプトとSlackware fileファイルを含む ./Slackware-9.0 ディレクトリだ。
これらのツールを初期化するには、 /mnt/cdromディレクトリににSlackwareのインストール版をセットアップし、次いで /Slackware-9.0ディレクトリからSCRIPT.shを走らせる必要がある。スクリプトがCD-ROMのディレクトリを調べ、そこにあるtagfileの案内で、パケージに関する情報を含むファイルを作る（図１）。各ファイルは、示されたグループの名に相当する名を有する。例えば、e-ファイルは、Emacsを構築するパケージを登録する。とりわけ、以下の登録を見出す筈だ：
emacs: ADD emacs-misc: REC emacs-nox: OPT
Slackware Linuxを知っているユーザは、ADD カテゴリがプログラムの中で使うのが不可欠のパケージを指摘、REC カテゴリは推奨パケージを、OPT カテゴリは任意選択のものを意味することは承知している。
パケージ関するこのような基本的情報があると、どの成分が必要でどれが不要かが分かる。だから上述のe-ファイルの内容を次のように変更すると、
emacs: ADD #emacs-misc: REC !emacs-nox: OPT
emacs パケージはインストールされると予想され、emacs-misc パケージは無視され、emacs-nox パケージは無視されないだけでなく、－前にインストールされていれば－削除される。
./Slackware-9.0 ディレクトリからのSlackware ファイルには、パケージの個別グループに関する情報が幾つかある：
a ap d e f ...
これに基づいて、スクリプトは、パケージのどのグループを考慮に入れるかを決定する。このファイルを次のように変更すると：
a ap #d !e f ...
d グループは無視され、前にシステムにインストールされたe グループからの各パケージは削除される。
こうして、パケージ又はグループの名の前に＃を置くとそれは除外され、！を置くと対応する成分がシステムから削除される。パケージ又はパケージのグループがインストールされていないときは、＃と！の意味は同じになる。グループ名を含むファイルからの登録は、パケージ名を含むファイルからの登録に優先する。だから、グループ全体を無視するか又はそれに属するパケージを削除したいときは、ファイルに書かれた情報に無関係に、スクリプトが個別パケージの名を集めてそれをおこなう。
Slackware ファイルと個別パケージに関する情報を含むファイルが整ったら、INSTALL.sh を走らせる。スクリプトが、対応する成分をシステムに追加又は削除する。Slackwareの予備インストールで、システムが適切に調整されていないときは、新ディストリビューション用プラットホームとして使うハードドライブの作業を最適化するのが良い。それには、INSTALL.hda 又は INSTALL.hdbスクリプトのうち一つを使うことが出来る。このお陰で、パケージのインストール又は削除が速くなる。
INSTALL.sh は、多重使用の設計となっている。することがないときは、何もしない。このスクリプトを使って、Slackwareの基本的インストールが出来る。Slackwareのセットアップ・プログラムを使って最初に一つのグループからパケージをインストールするだけで十分だ。次にスクリプトをシステムに入れて不要なパケージ又はグループをコメントし、INSTALL.shを呼び出して、残りをインストールする。
./Packages ディレクトリにはSCRIPT.sh スクリプトがある。Slackware CD-ROM,を取り付けて既述のスクリプトを走らせると、システムの個別パケージに関する情報のあるファイルを含むディレクトリ構造を作る。パケージに関するこのような参照データベースは、選択したパケージの用途を知りたいとき一々インストレーションディスクを取り付けないで済むので便利である。このようなベースの構築に理由があるのは、Slackware Linux全部をインストールしないときだけだ。インストールすれば/var/log/packagesディレクトリに情報がある。
./Patches ディレクトリには、二つのスクリプトが含まれる。使いたいときは、先ず0.check を走らせる。これが sunsite.icm.edu.pl サーバを点検して、Slackware 9.0 用に利用出来る更新を探し、更新に関する情報を含むPackages.html ファイルと、パケージ名を含むPackages.txtファイルを作る：
mutt-1.4.1i-i386-1 sendmail-8.12.9-i386-1 sendmail-cf-8.12.9-noarch-1
1.get script は、最後のファイルを使ってパケージ、適切な .txt ファイルと.tgz.asc ファイルを入手する。これをするため、このスクリプトは、コマンド wget -c -t0 を使うので、同じファイルを繰り返し入手するおそれはない。他方、示されたファイルが入手済みであるとのチェックには時間が掛かるので、1.getを開始する前にPackages.txt ファイルを閲覧し、入手済み又は気にしないパケージ名をそれから削除するのが賢明だが、これは不要だ。
ファイル入手のためのコマンドを wget -c -t0 -b に変更することが出来る。すると全てのファイルが同時にサーバから－バックグランドに－与えられる。サーバ全部でこのような同時接続を出来る訳ではない。sunsite.icm.edu.pl サーバがニーズに合わないときは、 0.check と1.get スクリプトに別のホストを登録することが出来る。次いで、Packages.html ファイルからPackages.txt ファイルを適切に作ってコマンド内容を適切に作り直さなければならない：
cat Packages.html | grep ".tgz.asc" | sed 's/.tgz.asc//g' | sed \ 's/.*A HREF="//' | sed 's/">.*//' > Packages.txt
1.get スクリプトは、カジュアルなパケージの情報だけを登録する。Slackware用の巨大な更新は別のディレクトリ（kde, kdeiなど）に入れられる。これらが欲しいときは、人手でおこなうか又は元のスクリプトを適切に変更しなければならない。
/usr/local/bin ディレクトリには、atpkg スクリプトがある。これは、システムにインストールされたパケージ全部についての情報に関し /var/log/packages の中で利用することの出来るファイルを容易に調べる。 INSTALL.sh は、ローカル ./usr/local/bin の内容全部をシステム全体の同等物にコピイする。だから、ここにシステムに対する初期作業の間に使いたいスクリプトを、入れることが出来る。
図２．SECURE.sh スクリプトは、選んだファイルからSUID とSGID ビットを取り去ってそれに関する情報を表示する。
SECURE.tgz アーカイブの主スクリプトはSECURE.sh. である。これは次を実行する：
・/etc/login.defs ファイルで PASS_MAX_DAYS 変数を182に設定する。.そのお陰で、新ユーザのパスワードの検証時間が６ヶ月に制限され。
・/etc/profile ファイルで HISTFILESIZE 変数を100 に設定する。そのお陰で、コマンド歴のファイルが百行に制限される。
・/root/.bashrc ファイルで TMOUT 変数を900 に設定する。そのお陰で、ルートの不活動セッションが15分後に中止される。
・/etc/inetd.conf ファイルでコメントされていないもの全部をコメントするが、ネットワークサーバには危険の可能性がある。
・マシンに対する外部アクセスをブロックするため /etc/hosts.deny ファイルに ALL: ALL@ALL エントリを入れる 。
・/etc/hosts.allow ファイルにe ALL: ALL@127.0.0.1 : ALLOW エントリを入れて, ローカルマシンのリソースに対するアクセスを与える。
・/etc/host.conf で order hosts, bind シーケンスを、もっと安全な order bind, hosts に変更し nospoof on シーケンスを追加する。
・/etc/securetty ファイルで /dev/tty1 を除く全コンソールに対しルートへのアクセスをブロックする。
・/etc/group から殆どの場合に余計なnews とuucp グループを削除する。これは groupdel news と groupdel uucp コマンドを与えるのと同等である。
・/etc/passwd ファイルから news, uucp, operator, sync, shutdown users を削除する。これは適切なパラメータを取る連続の userdel コマンドと同等である。
・Performs the parallel actions with reference to /etc/shadow ファイルを参照し平行作用を実行する。
・/etc/inittab ファイルでca::ctrlaltdel:/sbin/shutdownから始まる行にコメント記号を設定する。そのお陰で、Ctrl-Alt-Delete shortcut が、マシンの再ブートが起こるのを止める。
・Takes away from all the scripts from /etc/rc.d ディレクトリからの全スクリプトから、グループ又は他のユーザがそれをを読み取り又は実行する権利を取り去る。
・/etc/rc.d/rc.local ファイルに、別のサービスに切り換える数個のコマンドを追加する。 これらのコマンドを働かせるには、Kernelに IP: TCP syncookie support mモジュールを追加しなければならない。
・数十個のトラブル・プログラムをテストし、それらからSUID ビットを取り去る。これは、これら修正に関する情報をログファイルに記憶する（図２）。
・SUID と SGID ビットを取り去る同様の作業を数十個のプログラムに対しておこなう。
・ /etc/mail/sendmail.cf config ファイルにエントリ O PrivacyOptions=noexpn と O PrivacyOptions=novrfy を入れる。これはシステムがアカウントの遠隔点検をするのを禁止する。
・削除スクリプトを /etc/cron.daily ディレクトリにコピイする。これは各種一時ディレクトリ又はファイルをシステムから自動削除するのに使われる。
・有用スクリプト数個を /root/bin ディレクトリにコピイする。
これらの処置は、システムのセキュリティを著しく向上するが、起こりそうな割れ目の弥縫策の始まりに過ぎない。SECURE.sh スクリプトは繰り返し走るように書かれた。だから、スクリプトに任意のプロシージャを追加して問題なく摘要することが出来る。
このスクリプトは各種サービスを修正するが、過負荷にはしない。/etc/inetd.conf,を読み直すには killall -HUP inetd コマンドを用いる。変更した /etc/inittabを実行するには、 init q コマンドを走らせる。sendomailを再スタートするには /etc/rc.d/rc.sendmail restart 又は kill -HUP `head -1 /var/run/sendmail.pid` コマンドを用いる。.
これらのコマンドをスクリプトに含むことが出来るが、危険性もあるのを考慮しなければならない。sed プログラムの呼出に小さな間違いがあると、修正 /etc/inittab の代わりに、空のファイルに入ってしまう。その結果initの再ブートの後、システムへのアクセスを失って、別のパーティション又はディスクにインストールされたLinuxシステムを使って、コピイから /etc/inittab を記憶し直す羽目になる。これは、特にLinuxのあるパーティションが無いときは、余り気持ち良くない。
図３．巨大サイズのファイルのリスト。見られるように、/opt ディレクトリにインストールされたOpenOffice.orgスーツのファイルが大部分を占めると同時に、RealPlayer とPingusファイルがある。
TEST-SECURE.sh スクリプトは、ある種のファイルをシステムから捜し出す：
・SUID 又はSGID ビットを設定したふぁいる。.
・巨大で古いファイル(1 MB 以上のファイル、修正又は三ヶ月以上使用しないもの）
・飛び抜けて大きいファイル (図3.)。
・システム内のユーザ又はグループに無関係のファイル。
ファイルの各カテゴリに関する情報は別のログファイルに登録される。さらに、TEST-SECURE.sh が、SECURE.sh スクリプトの作業結果を使用して、ログファイルの内容を、SUID 又はSGIDビットのないプログラムについての情報を表示する。
これら全部の課題を纏めて実行するとは限らないので、/root/bin ディレクトリには、各々が特定のテストをおこなう 1.suid, 2.巨大+旧, 3.巨大, 4.誰も書かない、がある。.
SECURE.sh スクリプトを、追加特性のコンフィギュレーションとインストレーション担当する別のプロシージャで拡張するのは、価値がある。スクリプトで使用したプロシージャに続けて、サービスの切り換え、ユーザ・アカウントの構成、ネットワーク設定、e-メールとWWWサービスとクライアント、X Window などのための次のスクリプトを書くことが出来る。唯一の制約は、君の想像力だ。Linuxは殆ど何事でもこんな方法で扱うことが出来るからだ。これらのスクリプトを完成したら、Enterキイを数回押すだけで、自分のニーズに合わせてシステムを構成することが出来る。
私は幸運だ。重要な高校レベルの会合すべてに夫Lazioに同伴し、洗練されたシリコンバレー幹部社員が夫の革新的情熱を楽しむかを聞いている。彼はハンガリーの革命家でソビエトと戦い、あの悪魔の帝国に最初の割れ目を作った。だが今では、彼の革命は実在の悪魔の帝国マイクロソフトに対するものだ。新しい武器はLinuxとインターネットだ。
コーヒーブレーク一つの間、Lasioは、革命世界でのコーヒーの重要さを説かずにはいられない。1956年のブタベストの学生は、ブタのキャッスルヒルのコーヒーハウスでエスプレッソを啜りながら革命の種を育てた。1953年のスターリンの死以来、ブタペストの青年達は殆ど毎日集まって共産主義暴君に立ち向かう計画を練った。
今でも、1956年10月22日に機が熟していたとは思えない。
大学の彼の同僚と彼は、どのシティスケアで平和な抵抗をおこなうか判断した。ベンスケアの工科大学、革命詩人のスケアにある医科大学、別の場所にある科学工芸大学。
百年にわたって、コーヒーは、考えを刺激し、気分を高揚させ、眠気を防ぎ、支配者に対する反抗を育てるとの評判を勝ち取った。歴史を通じる支配者のある者は（ナポレオン、フレデリック大王、クレメント法王）は、評判のため使用の普及を止めようとした。16世紀末にクレメント法王は、コーヒーが大変好きで、止めないことにした。
1700年に、英国のコーヒーハウスは革命の温床として禁止された。1789年に、ダントンはパリのコーヒーハウスで革命仲間と会ってフランス革命を計画した。1956年にハンガリーでコーヒーハウスは禁止されなかったので、彼と彼の同僚はエスプレッソを啜って、明日始める革命の戦略を話した。
会合は、サンフランシスコのサンフランシスコ・ヨット・クラブで、雰囲気はコーヒーハウスに似ており革命的な議論にふさわしかった。役員はマリーナに早朝到着したので、深い霧と小雨に迎えられた。昼になって霧が晴れ、サンフランシスコの夏特有の涼しい快晴になった。大きい窓とベランダのあるヨットクラブの環境は、片側にアルカトラ反対側に金門橋のあるサンフランシスコ湾の壮大な光景が見渡せる。デッキに急降下して撒いてやった肉塊を取り上げる鴎の叫びが会合に音響効果を与える。
だが、会合は大変長いので、車椅子に座っている私の脚は何度もむくむ
会合の主題は深くて重要だ。補助的技術に何が出来よう、団塊の世代のため何をすべきか。
団塊の世代が老齢になるにつれ、祖父母、叔父叔母、両親、映画俳優や歌手が我々の前の世代から亡くなるのを認める。稀な例だが、二つの埠頭、両ビートル、有名でない埠頭幾つか、最も悪いのは、子供達の死を認めさせられた。今や我々自身の死と言う現実に直面しなければならない。1980年に私が複合硬化症(MS)と診断されて以来直面して来たものだ。
マーロン・ブランドやリス・テーラーを含む俳優の世代にさよならを言はなければならないまで長くはないだろう。1970年に彼らのようになろうと努力した。今は、彼らのようになろうとは思わない。間もなく、ダスチン・ホフマン、メリル・ストリープ、残った二人のビートルズ、エルトン・ジョーン、コングレス、クリントンなど他の俳優や歌手及び家族又は時間切れになた人々と別れるだろう。
ろくでなしは、有り難い支社の音楽を慰めのため聴くのに慣れた。今はジャック・ケボキアン博士を思い出す。
1994年に、スーパーマンを勇気のある、英雄的な想像のキャラクタと見なし、その勇敢さに憧れた。彼の1995年の事故の後、世界はスーパーマン（クリストファー。リーブ）を勇気のある、英雄的な実世界の人物とみなし、前よりも彼の勇敢さに憧れた。
今、私は車椅子に縛られているので、何物からも逃げられない。コンピュータと電話に音声認識を使う必要があり、両方とも口を動かしボタンを押すのに夫の手助けが要る。テレビとCDプレーヤのリモコンも同様だ。ハンズフリーのコンピュータ、電話、テレビ、CDプレーヤ、車椅子の制御を必要としている。
重要なのは、私の周りに良い物があることだ。私は盲目ではない、一文無しでない、退屈していない、裏切られていないし、脳死状態でもない。
ハイテク産業にいる人々には、精度を高めるため読唇と対になった音声認識で制御されるハンズフリー製品を作る義務がある。その日が来ると確信する。何時か知らないだけだ。差し当たっては、2002年にある音声認識を使わなければならないので、コンピュータに話し掛けて夫に怒鳴るが、コンピュータの方が良く答えて勿体振らない。
誰でも生涯のうち何時かは身障者になる。道路を見続けなければならないドライバを考えると、電話呼出を起動し、会話し、終わるのに音声を使うのが良いだろう。何時の日か、車を音声で運転するだろう。時間の問題だ。
技術開発者は、団塊の世代と市場の大部分を占めることを覚えて置かなければならない。彼らが家庭や自動車にその世代のため速度で技術を持ち込むなら、多大の時間を勝ち取るだろう。
ヨットクラブでの疲れる会合の後、夫は私の脚に手を伸ばし膝の上に載せて休ませた。これを見て、役員の一人が、君の夫は優しいねと要った。私は、ええ、易しいこともあるけど、護りを固めないと、嫌な奴になることもあるのよ、と答えた。
Laszlo はこれを聞いて、付け加えた、嫌な奴でも、気高い嫌な奴だ。
コンソール・ドライバ
Linux 2.4.x,の時点で、kernel はキイボード・ドライバとスクリーン・ドライバに細分されるコンソール・ドライバを含む。コンソール・ドライバは、Linux 2.6.0 のため完全に書き直されたが、この段階では、基本的に、キイボード・ドライバが文字をアプリケーションに送り、アプリケーションが仕事をして、ディスプレー上への何らかの出力をスクリーン・ドライバに要求する。コンソール・ドライバは、 /usr/share/kbd/ 又は /usr/lib/kbd/に常駐すると思われるkbbパケージにより補完される。
キイボード・ドライバからアプリケーションへ更にスクリーン・ドライバへの経路で、文字はコード（16進数）以外の何物でもない。また、最後に画面で小さい画（象形文字）を見たいので、象形文字をこれらの文字と結合する方法がある筈だ。
この記事は、キイボードとアプリケーションとの間で起こるが与えるものを取り上げで、何かスクリーン・ドライバだけに重点を置く。フォントの基本的概念の幾つかが必要である。またユティリティ 'setfont' に関するマニュアルを手元に置くこと。この記事は、以下からの資料に基づく：
ユニコード
伝統的に、文字エンコードには８ビットを使うので、 2^8=256 文字に限られ、これでは十分でない。勿論、昔は、プリンタやモニタは特殊記号（アクサン、ウムラウトなど）を知らず、もっと前には、大文字と馬鹿にされた小文字しかなかった。この時代は、 i18n (国際化)256文字をおつまみと格各付けして終わった。
ユニコードとも言われるUCS (ユニバーサル文字セット)は、中国、韓国、日本の象形文字を含む世界中の活字を扱うため作られた。これはに65000 文字以上で発足したが、2^31まで増やすことが出来る。想像されたい。
UCS は、32-ビット/4-バイトエンコードである。ISOが10646-1規格として規格化した。UCSから元雄も広く使われる文字は、その UCS-2 16-ビット・サブセットに含まれる。これは現在Linuxコンソールで使われているサブセットである。Linuxが南北アメリカ、西ヨーロッパ及びアフリカで規定値として使う文字セットは latin1又はISO 8859-1と呼ばれる。
便利のため、UTF-8 と言うエンコードは、ASCII逆互換のため設計された。UCSエンコードを有する文字は全部UTF-8シーケンスで表現することが出来る、逆も真である。それでもUTF-8とユニコードは別々のエンコードである。
UTF-8モードでは、コンソール・ドライバはASCII範囲の文字を前と全く同様に扱うので、古いテキストビューワもASCIIの表示を続けることが出来る。ASCII範囲を超える文字は、バイトの可変長シーケンス（文字当たり6バイトまで）に変換される。UTFは文字通りユニコード変換フォーマット（Unicode Transformation Format）を意味し、UTF-8は－在来の文字セットが占めた－8-ビット文字の転換を含む。
ユニコードは複雑である。任意の文字にIDを割り当てると思えば良い。そのIDは完全な形で四バイト、UCS-2 sサブセットでは二バイトを含むので、ユニコードIDは0x2502 のようになり、U+2502とも書く。IDが分かると、適切なフォントからその文字に関する象形文字（絵）を拾い上げることが出来る。実際象形文字の名称さえも規格化されているので全ての大文字、例えば：
FEMININE ORDINAL INDICATOR
全て明白だろうか？
問題 2: 与えられたユニコードの象形文字を入手する
問題1 は、Linuxコンソール・ドライバに関する限り重要でない。最も普通の公式名はkbdディレクトリ ../consoletrans の中の *.trans ファイル、又はkbdディレクトリ../unimapsの中の*.uni ファイルで見出すことが出来る。詳細は下記を参照：
本当に厄介なのは問題2だ。
象形文字
象形文字については既に説明し直感的に明らかになったと思うが、少し追加する。
winword又はワープロを立ち上げて 'a' を数回フォントとサイズを変えてタイプして見る。これらのaすべては同じに見えるが形とサイズが異なる。共通なのは一つの象形文字、'a'の象形文字と言う事だけだ。
象形文字への参照は、何かを見るため使う必要のある特定のフォントからの抽出のようなものだ。
フォント a は、特定の形の象形文字の集積だ。グラフィック・モードの間、書体（形）が重視される。コンソールでは主にどの象形文字が含まれ又は含まれないか－及びフォントサイズ－を気にする。コンソール用のソフトフォントは、バイナリ・ファイルに各象形文字のビットパターンで入る。そしてVGAアダプタのROMにはハードウエア・フォントがある。これは、ブート時にソフトフォントをロードしとき見られるフォントだ。
ユニマップ
画面フォントマップ（Screen Font Map）は、コンソールフォントの位置毎に、描写文字のリストを与える。Linux 2,4xの下で、スクリーンドライバはUCS-2エンコードに基づく。.
画面フォントマップはまた、ユニコードマップ又はユニマップ又はコンソールマップ又はスクリーンマップpsfテーブルなどとも呼ばれる。技術は多岐に変化するので、理解するのは容易でない。特にユニコードが出る前はこれらの用語が違う意味を持っていた。同じ目的で同じフォーマットを有するファイルに、異なる拡張子を付けて命名していた。普及していて明確だと思うので、ユニマップを選んでファイルを *.uniとする。kbdパケージからのこれ以外のユティリティに出会ったら、技術の迷路に注意されたい。
象形文字一つは、別のユニコードにも役立つ。同じ象形文字が沢山の名を持つことがあるからだ。例えば、重要な文字 'A' はロシア語でも英語でも別の名で利用されるが、英語とロシア語を含むフォントに 'A' の象形文字を二つは必要としない。だからこの場合別々のユニコードが同じ物を示す。
二つの象形文字が別のものだが互いに似ており、空間の節約と他の代理に役立てるため、そのうち一つだけをフォントに含むことがある。これはタイプライタの時代に似ている。例えば、開きと閉じの引用符は、活字は違うが、同じである。
代用は、代替登録を用いて公式化する。代替動録は、空白で別れた二つ以上のUCS-2コードのシリーズである。最初のものが、象形文字の欲しいユニコードで、続くものは、最初のコード専用に象形文字が設計されていないとき使う象形文字の物である。コードの順序は、優先度の順を示す（あれば自分の象形文字、次に第二候補、第三候補、など）
スクリーン・モード
UTF-8 モードでは、アプリケーションから受け取り画面に書かれるバイトは、UTF-8シーケンスと解釈され、ユニコードに転換してユニマップを探し、使用する象形文字を決める。
１バイトモードでは、アプリケーションが送ったバイトに対し、ユニマップを使用する前に、追加の中間マップを適用する。
この中間マップは、Application Charset Map又はApplication Console Map (ACM 又は acm)と呼ばれて来た。残念乍ら、これは静かに消えたと思われるコンソール－ツール・パケージの用語である。.
kbd パケージは、マップに固有の名を付けていない。翻訳テーブルと呼ぶか又は拡張子 .transの付いたファイルに格納する。setfontのマニュアルでは、ユニコード・コンソール・マップと呼ぶが、これはユニコード・マップ（unimap）を連想させるので、おかしい。袋小路から逃げる方法として、ここでは、至る所にあらわれる略語、cmapと呼ぶ。
二つのモードの簡単な図解を示す：
１バイトモード:
アプリケーション-> cmap -> unimap -> 画面
(bytes) (UCS-2)
UTF-8 mode:
アプリケーション-> unimap -> 画面
(UTF-8 / UCS-2)
この図は文書の森を切り開く鉈なので、覚えておくこと。cmapとunimapの違いを確認しておくこと。
CMAP の役割
cmapには幾つかのフォーマットがあるが、マップが実際にすることを理解出来るのは一つだけだ。例として、kbdパケージの../consoletrans ディレクトリにあるcp437_to_iso01.transファイルを見てみよう。 コードペイジ437は早期のDOSに芽生え、未だにあらゆるVGAアダプタのROMにあるフォントとなっている。
このファイルには、16進数の２カラムがある。第一カラムは、フォントの中のスロットを列挙し、256位置が最大となっている。cmapでは256個だけ扱う。
この例は完全に働くが、cp437とlatin1は大いに異なるので、別の場合には、文字の一般的置換による間違いに出会う。又は近似、代替に出会う。例えば、シルコンフレッククス記号が上にあるａが欲しいとき大文字の'A'を与えられる。
256 文字フォントを使うときは、cmapが実際に翻訳するのは代替を意味する。代替が不要なときは、cmapは直行フォントである。各文字はそれ自体に翻訳され、unimapだけが関係する。これが最も自然で普通の場合だ。
しかし、フォントは一つ以上の文字セットを対象とする設計にすることが出来る。これは512文字セットで明らかだが、実際には（部分的にだが）一つ以上の文字セットを扱うことの出来る256文字フォントがある。このようなフォントを使っているときは、cmapに対象とする文字セットの一つを選ばせることが出来る。一例(lat1-16.psfu)を下で論じる。
G0/G1 LEGENDS
一時に作動するcmapは一つしかないが、kernelはそれらを四つ知っている。そのうち三つは、ビルトインで変わることはない。これらはIBMコードペイジ 437から早期のDOS版までをボックスドロー文字で、DEC VT100 charsetもまたボックスドロー文字で、及びISO latin1 charsetを定義する４番目のkernel charset は、ユーザ定義で、規定値では直行フォント・マッピングで、これだけがソフトフォントをロードして変えることが出来る。
コンソール・ドライバには、G0とG1のラベルが付いた二つのスロットがある。それぞれが、四つのkernel charsetのうち一つと関連している。G0とG1は、cp437, vt100, latin1を指す限り、コンソールからコンソールに変わることが出来る。これら三つと異なるcmapを任意のコンソールのG0又はG1スロットいずれかに入れると、他のコンソールが同じユーザ定義文字セットに切り換わる。規定値では、GOがlatin1を指し、G1がvt100を指す。G0とG1はプロンプトでエスケープシーケンスを用いて作用させることが出来る。だから何度も言ったが、単独のままにするのが良い。理由は？
ユーザ定義の文字セットはどうだろうか？ソフトフォントをロードしているときは（そして現在のフォントをディスクにセーブするだけの時を除いて、setfontを走らせるとソフトフォントをロードするときは）kernelからユーザ定義文字セットを拾い上げるエスケープシーケンスが、ソフトフォントをcmapとしてそれに絶対的なchrsetとともに作動状態にして、ROMフォントに戻ることが出来なくなる。softfontのソースコードを見ると、それらはソフトフォントの文字セット兎に角作動させているのが分かる。ユーザ定義文字セットは何の役にも立たないので忘れて、setfontに任せる。
他方、ROMフォントを走らせてソフトフォントをロードしないと、ユーザ定義文字セットの要求はcp437をリセットするだけだ。理由は、ユーザ定義文字セットは規定値直行フォントを有するからだ。例えば、小文字を持たない vt100 を選んだとすると、たちまちがらくたが表示される。ユーザ定義文字セット（これは未だ定義していないので未だに規定値を有する）のためのエスケープシーケンスを送るとがらくたは消えて、再び小文字があらわれる。
助言：latin1が適切でない地域にいるときは、自分のディストリビューションが提供するフォントに貼り付くこと（ボックスドロー要素にはさよなら）。latin1で良いなら、lat1-16.psfuを用いる。これでlatin1文字とファイルマネージャ用ボックスラインが得られる。
ドキュメンテーション又はその欠落
Linux コンソール・フォントを巡る問題は、殆ど文書化されていない。マニュアルは薄いし、用語は大袈裟で、kbdパケージに付いて来るハウツーには落胆する。これを推薦する人は読んだことがあるのかと思う。
この記事で示した内容は、基本的なもので、理解するにはまたまだ努力が要る。別の角度から纏めて見る。害にはならない。
質疑応答
ROM フォントをコンソールで強化する方法は？
echo -ne '\e(U'
setfont -o cp437-16.psf
ファイルcp437-16.psf ROM フォントを格納する。このフォントの高さは16ピクセル。
echo -ne '\e(K'
setfont -om current_font.trans
エディタを使ってcurrent_font.trans の中を見る。これは、100% は働かない。一定の文字範囲(0-31 と128-159) は、象形文字を記憶していても、正しく表示されないからだ。フォントがunimapを有しているときは、その unimap が公式名で文字全部をリストする。これで象形文字が分かる。
今は、働くのに忙しい。返事の要るe-メールが沢山来る。午後に提出する品質解析報告広報に渡す宣伝文書、書式エラーを直すため点検するコードの山がある。その上、絶対に見逃したくないTV番組がある。どうするか？勿論TVチューナ・カードに切り換える。コンピュータ画面の片隅でTV番組を見る。皆が働いていて、遊んでいる者はいない。上梓が肩越に覗こうとしたれ何時でも、ウインドウを最小にする。いっそ全画面にして、一緒に見ませんかと誘う。技術の夢だ！
Linux プラットホームは、ビデオカメラや、メディア装置の組合せと同時に、多数のチューナ・カードをサポートする。他のOSと同じく、アプリケーション・プログラムやkernel自体とは、一線を画して明確に切られている。技術で言う Video4Linux (又は V4L)は、草案バージョン１から、もっと頑丈なバージョン２に未だ発展中である。途中で、沢山のデバイスドライバが、主としてbrooktreeチップセットを巡って開発されたが、次第に他のモデルにも及んでいる。アプリケーション・プログラムは、ユーザのため、TV視聴、ディスクへの記録、文字多重放送の解読読取などなどに、GUIベースのインターフェイスに重点を置いている。TVを見るには、画面上に正しいサイズのウインドウを作ること、それを生きたビデオせ満たす（オーバーレイ）ための関係デバイスドライバを要求すること、画面上の目視範囲のサイズ変更とそれにしたがう調整をドライバに依頼すること、ユーザ要求を渡して特定のチャンネルに同調したりチューナからの入力をAVモードに変えたり無音にしたりすること、などの課題は、アプリケーション・プログラマの仕事である。アプリケーションはチューナドライバの最前線で、ユーザの要求を、アプリケーション・プログラマ・インターフェイス(API)と言う名の、定まった方法でドライバに渡す。
次の数頁では、読者も筆者も我慢が必要だ。TVチューナ・カードの働き、作り、各種の型、Linuxで働かせる方法などなどを、互いに示す。「互いに示す」と言ったのは、この記事を一緒に書きたいからだ。私が少し研究するのは、読者のためだ。お互い様なので、紙とペンを用意して読み進められたい。
警告：居眠りしてはいけない。後でテストがある。
重要な言葉：
PCI バス、I2C バス、IF (インターフェイス頻度)、ビデオ・プロセッサ、フレーム・バッファ、DMA、IRQ。
脚注１："Linux kernel" に対する引用はすべて kernel version 2.4 以降
TV チューナ・カードを見てみよう。ボード上には最低三つのチップがある。
実際のチューナ「チップ」は、高周波成分を取り付け、保護シールドの銀箔で綺麗に包んだボード全体体だ。図を見ると、チューナ・モジュールは、目立ったパケージになっていて、殆ど同じ外観だ。アンテナ・ケーブルはカード右端のソケットに入る。チューナ・モジュールの仕事は、特定TV番組に同調する高周波混合の魔術をすることだ。TV番組がどんな周波数であろうと、所定の中間周波数（IF)に変換される。この「所定の」周波数が、歴史的な（政治的な？）理由で、全くの曲者だ。各TVシステム(PAL、SECAM、NTSC、など)に独特のIFがある。IFがどうであろうと、チューナは、一つだけの仕事、宇宙の無数の高周波の中から、命令にしたがって、正しいTV番組を篩い分ける。５．I2Cバスの章で、好きなスポーツ・チャンネルに同調させるためチューナ・モジュール命令する方法が分かる。
チューナ・モジュールからのIF は、デコードして、目視可能のフォーマットに変形する必要がある。これがビデオ・プロセッサの仕事だ。目視可能のフォーマットもまた、歴史的理由で、色々な形と大きさになる。既に、平易な古いビットマップ・フォーマット、パレット化し平坦化したVGAフォーマット、RGB（赤、緑、青）フォーマット、YUVフォーマット（及びその難解な変形））その他数々の特許フォーマットがある。行間を敏感に読めば、上述の「変形」には復調とAD変換が含まれると推測するだろう。それがTVチューナ・カードのすべてなのだ。コンピュータ画面でTVを見るとき、実際に見ているのは、ビデオ・プロセッサからのデジタル化ビデオデータをVGAアダプタが表示したものなのだ。これを、二つのステップに分けよう：
どうしてそうなるかを見る前に、フレームバッファを理解する必要がある。フレームバッファは、ビデオバッファとかフレームRAMとも呼ばれ、通常VGAカード（熟練者は我慢して、暫くAGPを無視されたい）
API figure (フレームバッファの働きの図）
フレームバッファ内のデータはすべて、直ちに画面に反映される。これはVGAコントローラの仕事だ。画面に何かを表示したいときは、データをフレームバッファにダンプしさえすれば、直ちに画面で見ることが出来る。ほとんどのプラットホームでは、フレームバッファが物理メモリアドレス空間に配置されているので、他と同じ只のメモリ対メモリのコピイだ。しかし、何かのメモリ保護をおこなっているシステムでは、アプリケーションはシステムRAMへの直接アクセスを許されていない。Linuxでは、これを /dev/ram デバイスノード又はフレームバッファ・デバイスドライバとの関連で、nmap()システム呼出を用いて制御される。詳細は mmap() のマニュアルを参照。勿論、これを敏感に働かせるためには、表示したいもの、フレームバッファバッファに書き込むもの及び場所についてVGAコントローラが同意しなければならない。これは、「VGAモード設定」によりおこなう。VGA「モード」の設定により、フレームram内のあらゆるビットの意味を、VGAコントローラが知ることになる。例えば、VGAモードを8 bppで"640x480" に設定すると、VGAコントローラは表示について、二つのことを知る：
ここに別の可能性がある。ピクセルフォーマットだ。各ピクセルには、輝度と色と言う二つの特性がある。色々なピクセル表示法が何年もの間に発達した。最も有名なのはRGBとYUVフォーマットだ。両者の説明は論議の範囲を超えるが、詳細は取るに足らぬので前に進む。したがって、我々のビデオモードの完全な設定は、RGBフォーマットで、解像度8bppにおける "640x480" となる。だからこの画面を表示するフレームバッファの大きさは640 x 480バイトとなる。
API figure （ピクセルフォーマットの図）
ここで、典型的なチューナ・カードを想像する。特定のチャンネルに同調し、ビデオデータをピクセル毎にデジタルフォーマット(8 bpp 又はYUVなど)で取り込んで、RAMにダンプする。この過程を「ビデオ・キャプチャ」と言う。ビデオ・キャプチャには二，三の可能性がある：
チューナ・モジュールはRFをIFに復調するのに忙しい。ビデオ・プロセッサにはADコンバータがある。これが各ピクセルからサンプルを取り、このサンプルがビデオプロセッサからの制御信号の助けを借りて、RAM内のフレームに組み立てられる。この記事では、例として、極めて簡単なビデオプロセッサ－ITT VPX3224D－を考察する。
チューナ・カードは、一般に音響を二つの異なる方法で扱う。第一の方法は、IFから音響を復調するのにオーディオ・プロセッサを使う（IFには音響と映像両方の情報が含まれる）。こうして得られた音響信号が、外部音響ジャックに送られ、そこからは適切なケーブルを使って別のサウンドカードのライン入力に送り直さなければならない。サウンドカードを持つほど金持ちでなければ、ハイファイセットのライン入力でも良い。
第二の方法は、オーディオ・プロセッサにIFからの音を復調させ、これをデジタル・サンプルに転換して、DMA（PCIバスの章で説明）などの技術を用いて、これらのサンプルを内部システムバス（PCIバスなど）経由でサウンドカードに送る。そこからは、サウンドカードを使ってデジタル・サンプルを音響信号に再変換する。この方法は、複雑だがTV音響レベルをチューナカード自体で調節出来るので、融通性がある。第一の方法は、別のサウンドカードのサウンドドライバに命令することによってのみ贅沢な品を利用することが出来る。いずれにせよ、要求される事項と、チューナ・カードの有能なデバイスドライバ作者として何が必要かを纏めてみよう：
Alan Cox が、Linux API 用ビデオに関しキャプチャカードのため優れた記事をLinuxに(Documentation/DocBook/videobook.tmpl)（脚注２)書いており、Video4Linux APIに関連する問題も扱っている。扱っていないのは、チューナ・カード処理の詳細である。一つの記事で各種TVキャプチャカード全部の詳細を扱うのは不可能だが、入手可能なチューナ・カードは、ここで示すことに合致すると思う（USBポートに入るWebカメラなどは断言出来ない）。
linux/videodev.h（脚注３）は、V4L APIに関する権威ある参考資料なので、ここではV4L APIに関する詳細説明は省く。これに関する概念的詳細は、上述のAlan Cox の文書にある。その上V4L API は、発展中の規格である。今日は良くても明日適当であるがは分からない。
先ず、アプリケーションとデバイスドライバとの間の連絡に従事する機構を見る。キャラクタデバイスについてご存知なら、これは繰り返しなので、ここは飛ばして構わない。
#include <stdio.h>
#include <stdlib.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <fcntl.h>
main(){
char *buffer;
/* 出来るだけ大きいバッファを割り当てる */
buffer = malloc(65535);
/* デバイスノードを読取で開く*/
if((fd = open("/dev/video0", O_RDONLY))<0)
fprintf(stderr, "Sorry, error opening device /dev/video0\n");
exit(-1);
}
/* プログラムの中断又はデバイスがデータを使い尽くす(あり得ぬ)まで読み取る*/
while( read(fd, buffer, 65535)) write(0, buffer, 65535);
free(buffer);
}
上のコードで目立つのは、device nodeに他のファイルと同じくアクセスすることが出来ると言うことだ。類似性はこれで終わる。open(), read(), write(), seek()の他、device nodeは、ioctl()と言う特殊システム呼出を有する。V4L API経由で「ドライバに命令」する魔術が働くのはioctl呼出である。
ビデオ表示に切り換えたいときは、
ioctl(fd, VIDIOCSAUDIO, &v);
int video_exclusive_release(struct inode *inode, struct file *file);
int video_usercopy(struct inode *inode, struct file *file, unsigned int cmd, unsigned long arg, int (*func)(struct inode *inode, struct file *file, unsigned int cmd, void *arg));
このとき出来ることは、我々の技術者が、プログラムに、捕捉を開始し、音響スイッチをオンにし、ビデオデータを前後に動かすなど、色々なことをチューナ・ハードウエアがするコードを書くのに重点を置くことだ。ほとんどのV4L ioctlは、これらの問題から逃げている。最後に、全てが整ったら、最新最大のV4L API を、基礎になる我々のコードに橋渡しすることが出来る。これが標準の技術手順だ。
ドライバの一部は、チューナ・モジュールが正しく同調していること、ビデオ・プロセッサが正しい規格(PAL, NTSCなど)でデコードしたこと、ビデオ・プロセッサ・ハードウエアがサポートする輝度、色相、彩度などの特性が正しく調整済みか又は規定値になっていること、を確認した上で、ビデオデータ取得に関係する。音響取得もまた、ドライバのこの部分の仕事だ。これらはI2Cの章で詳しく述べる。
ドライバの別の部分は、取得したデータが正しく画面に表示されていることの確認に関係する。ドライバのこの部分は、ウインドウでビデオが見られていいるか、他のアプリケーションのウインドウとの重畳問題が正しく扱われているか、を確認しなければならない。ビデオウインドウのピッチ、取得したライン数、取得したピクセル数など、ビデオウインドウのサイズ変更や別の位置にドラッグしたとき影響を受けるパラメータの詳細は、ドライバのこの部分の仕事だ。Xwindowsなどのウィンドウ作成環境では、ビデオ重畳はウインドウ内でおこなう必要がある。重畳問題は、別のアプリケーション・ウインドウの隅がビデオウインドウの一部に重なったとき始まる。
ここで二つのオプションがある：
ここで出来ることは、彩度キイの設定、ビデオウインドウのサイズ設定、ウインドウの位置決めなど、細かいことをするルーチンを書くことだ。これらを習う最良の方法は実例だ。学習の基礎を、私が非公式に作業中のPixelview
Combo TV
plus用ドライバからのコード断片に置く。これは、チューナ・カードと同じ位、簡単なカードである。チューナ・モジュール、ビデオ・プロセッサ及びVGAコントローラ全てが同じカードに乗っている。カードはPCIスロットに差し込んで、チューナ・カードとVGAカードを兼ねる。
カードの概要：
API figure （ビデオバッファの図）
ビデオバッファはフレームバッファ内の任意の場所に置くことが出来るが、普通は、フレームバッファの最後に置く。これは、捕捉ビデオデータを既にフレームバッファに存在するグラフィックサンプルから保存し逆もおこなう。
例を用いて説明しよう：
|
|
|
|
|
|
|
|
|
|
|
|
ハードウエア・ウインドウは、VGAモードが管理するのと全く異なって、その管轄下のデータを翻訳して表示する。このビデオ・ウインドウの位置を大きさは、VGAレジスタ関連のプログラム作成で変更することが出来る。GD-5446 には、三つのレジスタ、つまりコントロール・レジスタ、グラフィック・レジスタ、シーケンス・レジスタ、がある。これらVGAレジスタの各々は、ハードウエア・ポートに対する複数の読取と書込によりアクセスされるので、専門ファンクションの中に包まれる。私はこれらを gd_read_cr(), gd_write_cr() などと名付ける。これにより、コードの信頼性が改善され、エラーのチャンスが減る。私のドライバから２，３のルーチンを示す。短くするため裸にした：
#define GD_SR_OFFSET 0x3c4
#define GD_GR_OFFSET 0x3ce
#define GD_CR_OFFSET 0x3d4
/* アダプタ - 低レベル・ファンクション */
unsigned value;
io_writeb(reg, gd_io_base + GD_CR_OFFSET);
value = io_readb(gd_io_base + GD_CR_OFFSET + 1);
return value;
}
高レベルのファンクション二、三を示す
void gd_enable_window();
static void gd_set_window(,,,);
void gd_set_pitch(
{
CR3C = gd_read_cr(card_p, 0x3c);
CR3D = gd_read_cr(card_p, 0x3d);
/* CR3C[5] = offset[11], CR3D = offset[10:3]*/
gd_bit_copy(&CR3C, 5, &offset, 11, 11);
gd_bit_copy(&CR3D, 0, &offset, 3, 10);
gd_write_cr(card_p, CR3C, 0x3c);
gd_write_cr(card_p, CR3D, 0x3d);
gd_write_cr() は、値を特定のVGAレジスタに書き込むのに使われる。変数 card_p は、今の所無視されたい。これは、ドライバに付いての全体状態情報を記憶する構造体だ。card_p は、帳簿付け目的のみのためgd_write_cr に使われる。gd_write_cr (card_p, CR3C, 0x3c)は、変数CR3Cの内容をコンソール・レジスタ0x3cに書き込む（CR3Cの名前に騙されてはいけない 、これは 'unsigned long foo' 程度の変数だ）。
チューナ・カードの一般の場合は、VGAコントローラが別のハードウエア・ビデオ・ウインドウを作らないので、ビデオ・プロセッサがフレームをグラフィックデータの中間にダンプしなければならない。これは、VGAコントローラがフレームバッファの新しい内容を表示するとき、ビデオフレームが正しく現れて歪まない、ようにおこなわなければならない。これは、ビデオデータをピクセル境界上に合わせること必要とする（8bppの各バイト、16bppの一つおきのバイト、32bppの４バイト毎）。その他に、ビデオプロセッサ内のピクセル表示は、VGAコントローラの現在モードに合致しなければならない。ビデオプロセッサはビデオを32bppで取得して16bppフレームバッファにダンプすることは出来ない。また、ビデオデータは、線型で連続な方法ではかぶせることが出来ない。各ラインのバッファ・オフセットは下図のように計算しなければならない。
API figure （オフセット計算図）
ビデオバッファ・オフセット
= ビデオバッファ・オフセット+ ビデオウインドウ・ピッチ×ライン番号
言い換えると、Ｘサーバがアプリケーション・ウインドウを描く間にＸサーバがおこなう予防措置と計算を、ビデオプロセッサも考慮する必要がある。ここでは、ビデオプロセッサは、グラフィックバッファに直接書き込むので、ビデオデータとグラフィックデータとの間に区別はない。
しかし、GD-5446の場合は、ビデオプロセッサはグラフィック領域に書き込まないので、整列問題を気にする必要はない。ビデオプロセッサが保証しなければならない全ては、ビデオがフレームバッファ内に、ビデオバッファがスタートする場所に、正しいオフセットで捕捉されることだけだ。gd_set_vbuf1() ルーチンがこの面倒を見る。ウインドウする細目は、このときGD-5446ハードウエアが面倒を見る。.
For detailed descriptions of GD5446 ハードウエア・レジスタの詳細説明は、GD-5446 技術参照マニュアルを見られたい。
IOCTL 呼出を案内する時期が来た。 xawtv (http://bytesex.org/参照)などのvideo4linuxアプリケーションが、TVウインドウに切り換えるため、 ioctl() を呼び出した瞬間を考えてみよう。
