昨日のブログで「Windows SideShow」について調べていたら、
ASUS社のマザーボードに「ScreenDUO」という補助ディスプレイが
付属していることがわかった。
面白そうなので、もう少し詳しく、この「ScreenDUO」について調べてみることにする。
「ScreenDUO」についての ASUSTeK Computer Inc. の 日本語サイトでの情報では、
ScreenDuoは、PCやWebサイトと同期してさまざまな情報を表示できる
コンパクトな液晶ディスプレイユニットです。
液晶画面にハードウェア情報を表示したり、
天気予報を表示したりできます。
液晶サイズは2.4型で解像度は320×240ドット、
約26万色のカラフルな表示が可能です。
とある。
また、Engadget 日本版 の
「ASUS ScreenDUO サブディスプレイ」
ページでは、
ScreenDUOは2.5インチQVGA画面(非タッチスクリーン)に4Way方向キー、
前面と側面にボタン4つ(+電源ボタン)、
USBコネクタを備えた補助ディスプレイ兼入力機器。
VistaのサイドバーガジェットのようなWidgetを表示させて使用します。
とある。この記事によると、マザーボード本体との接続にはUSBを利用しているようだ。
また、英語圏には、何でも専門のサイトがあるが、
「
SideShow Devices」
という、Microsoft Vista の Sideshow に関する専門のサイトもある。
このサイトの
「
Auxiliary Display」
のページには、「ScreenDUO」を含め、その他の Sideshow対応のデバイスが紹介されている。
また、このサイトには、今はやりの「デジタル写真立て」についてのページ
「
Picture Frames」
があり、こちらでは、I-mate社の「Momento WIFI Digital Picture Frame」が紹介されている。
このように、ASUS社のマザーボードに付属している「ScreenDUO」という補助ディスプレイについて
調査してみたが、残念ながら、どうも別売り等は していないようだ。
【参考リンク】
カテゴリー:
Device
22:24
| コメント (0)
| トラックバック (0)
「Windows SideShow」 と いう技術と言うか 機能 と言うか があるそうだ。
この「Windows SideShow」については、
マイクロソフト(Microsoft)の
「Windows SideShow」機能説明
に解説されている。
また、塩田紳二氏の
塩田紳二のPDAレポート「SideShowデバイス」
に詳しく解説してある。
「Windows SideShow」とは、
塩田紳二氏の解説から引用させていただくと、
SideShowとは、SideShowデバイスをPCに接続し、
SideShowガジェットと呼ばれるVista上のソフトウェアから表示を制御する機能だ。
SideShowデバイスは、PCにUSBなどで接続可能な表示デバイスであり、
SideShowガジェットは、そこに情報を表示するソフトウェアである。
とある。
実際に SideShow が搭載された製品として、ASUS社のノートPCがある。
これについては、ITmedia の
「ASUSのWindows SideShow対応ノートが3月下旬に日本登場」
という記事がある。この記事の中でWindows SideShowについての
わかりやすい説明があるが、
PCの補助ディスプレイみたいなもの。
2つ折りの携帯電話には、たたんだまま外から見えるように補助ディスプレイがついているが、
ああいったイメージのようなもの
と紹介されている。
記事中の写真をみると、たしかに、携帯電話のように、
メインのディスプレイの背面に、小さなディプレイと十字キー等のボタンがついている。
また、ノートPCだけではなく、デスクトップというかマザーボードに関しても
ASUS社からSideShow対応端末が付属したマザーボードがリリースされている。
それに関しては、PC Watch の
「ASUSTeK、Vistaの新機能に対応したマザーボード4製品 〜SideShow対応端末/ReadyBoost対応メモリを装備」
の記事にある。この記事によると、
ASUSのマザーボードのVista Editionシリーズには
320×240ドット表示対応2.4型液晶を装備した端末「ScreenDUO」と
呼ばれるSideShow対応端末が付属しているそうだ。
【参考リンク】
カテゴリー:
Windows
22:22
| コメント (0)
| トラックバック (0)
昨日、調査した Flickr のアカウントを実際に作ってみる。
Flickr は 数年前にYahooに買収されたので、
Flickr にアクセスするためには Yahoo! のアカウントが必要となるようだ。
- 「www.flickr.com」へ行く。
- 「Creat Your Account」ボタンをクリック。
- 「Sign in to Yahoo!」とあるので 米国Yahoo!にログインしなければならないようだが、
もし、米国Yahoo!のアカウントを持っていない場合は、画面下にある「Sign Up」リンクをクリック。
- 米国Yahoo!のアカウント作成画面に飛ぶので、そこで、名前などの必要事項を入力。
- 入力後、「Creat My Account」ボタンをクリックすると、確認画面になる。
- 「Continue」ボタンをクリックすると、Flickr の ログイン画面に戻ってきた。
このとき既に、「Yahoo! ID:」は、先ほど登録したものが表示されているので、
「Password:」だけを入力して 「Sign In」ボタンをクリック。
- すると「Make a new Flickr account」と「Merge with an existing Flickr account」という選択画面になる。
ここでは新しく 別の「Flickr screen name」を指定することも できるようだ。
ためしに「CREAT NEW ACCOUNT」ボタンを押して、新しいFlickr account を作ってみた。
- 「OK. You're all set, 」と表示されて、登録が終了したことになる。
【参考リンク】
カテゴリー:
flickr
22:33
| コメント (0)
| トラックバック (0)
写真サイトとして有名な
www.flickr.com
を使っているブロガーは多い。
遅ればせながら、私も使ってみようと思うが、
では、いったい無料で使えるのはどこまでなのか?
それについて調査してみた。
FlickrのFAQの
「
Free Accounts, Upgrading and Gifts」
というカテゴリーをみてみると、
プロ・アカウント(Pro Account) と 無料アカウント(Free Account) の
違いがまとめてあった。それによると、 無料アカウントの制限事項は、
- 100 MB monthly upload limit (アップロードは月間100MBまで)
- 10MB per photo (写真1枚 10MBまで)
- 3 sets (3セットまで)
- Photostream views limited to the 200 most recent images (直近の200枚までの写真を閲覧可能。)
- Post any of your photos in up to 10 group pools (10 グループ・プールまで)
- Only smaller (resized) images accessible (though the originals are saved in case you upgrade later)
(縮小写真のみ閲覧可能。オリジナルの写真はプロ・アカウントになった時のために保存はされている。)
ということだ。
ちなみに、プロ・アカウント(Pro Account) は 年間 24.95 米ドル。
これで、上記のほとんどの制限がなくなる。
その他、上記制限の詳細として、
「
How many photos can I upload for free?
(無料アカウントでどれだけの写真をアップロードできるのか?)」
という項目がある。その回答が、
When you have a free Flickr account,
you can upload 100MB worth of photos each calendar month.
This is a bandwidth limit,
and not an amount of space that you have on Flickr servers.
Your bandwidth allowance is reset to zero at midnight
in Pacific Time Zone (Flickr headquarters time) on the first of each calendar month.
You can't recover any of your monthly allowance by deleting photos.
If you have a free account, you'll see your limit on the upload page.
となっている。この回答によると、
「Flickrの無料アカウントでは、
月間100MBの写真がアップロードできる。
これは、バンド幅によるの制限であり、Flickrサーバーにおけるスペース上の制限ではない。
この従量カウントは毎月1日、太平洋時間の午前零時にリセットされる。
いくら写真を削除しても、従量カウントは復帰しない。
無料アカウントでは、アップロード・ページで制限値が表示される。」
といった感じ。
また、
「
I have a free account. Some of my photos aren't showing up. Why?
(無料アカウントで 写真が何枚か表示されないが、なぜか?)」
という項目では、
On a free account, Flickr limits the number of photos displayed.
If you have fewer than 200 photos, we display them all.
If you have more than 200 photos, only the most recent 200 are displayed.
「無料アカウントでは、表示される写真の数に制限がある。
最初の200枚までであれば、すべての写真が表示される。
200枚を超えると、最近にアップロードした写真から200枚が表示される。
」とある。
それから 続きで、
Your photos are not removed from Flickr,
only from the list of your photos.
If you blogged a photo and it no longer appears in your list,
it will still appear on your blog,
and the photo's Flickr page will still work just fine.
「リストされなくなった写真でもFlickrから削除されたわけではない。
ブログに貼り付けた写真は、リストに表示されなくなった写真でも、
ブログ上では表示され、写真のフリッカー・ページも問題なく動作する。」
とある。
このことからすると、こと ブログに写真を貼り付けることだけを考えると、
無料アカウントのままでも枚数無制限に利用できてしまうことになる。
ただし条件として、ブログに貼り付けてしまう、もしくは
200枚をアップロードする前に、写真に付けられた番号を控えておく必要がある。
注意点として、無料アカウントで 90日の間 アクセスしないと
写真が削除されてしまうようだ。
【参考リンク】
カテゴリー:
flickr
22:33
| コメント (0)
| トラックバック (0)
昨年の11月と同様に
「Google Japan Engineering Open House」が
マウンテン・ビュー(Mountain View)のグーグル(Google)本社で開かれた。
今回の Open House は Googleキャンパスの中でもメインの建物である
「Building 43」の2階で行われた。
テクニカルプレゼンテーションの内容としては、
- ビデオ検索について
- 日本語版Googleマップについて
- 東京とマウンテン・ビュー(Mountain View)の日本語チームの統合について
- Googleとのパートナーシップについて
と、いったところ。
日本人エンジニアの方々が英語または日本語で話された。
会場には、同時通訳の設備も整え、
必要な方には、受信機が配られていた。
会場に着いて驚いたのは、ここでの実名の公表は控えさせていただくが、
シリコンバレーでは有名な日本人プログラマーの方も
数日前にGoogleに移籍されたそうで、
グーグル・Tシャツを着て
この Google Japan Engineering Open House に参加されていた。
少し、お話させていただいたのだが、
前の会社(これもスゴイ会社なのだが)に入った時よりも
今回の Googleへの移籍の方が
もっとプレッシャーを感じる、ということだった。
前回の Open House の時から比べると 日本人エンジニアの数が
だいぶ増えてきている感じではあるが、
まだまだ足りない、というのが実情なのだろう。
会場には日本語チームの求人パンフレットがいくつも置いてあった。
カテゴリー:
シリコンバレー
22:59
| コメント (0)
| トラックバック (0)
自閉症児 渡の宝箱「バッテリー交換」
にも書いてあるとおり、
再び出動要請があったので行って来ました。
バッテリーが上がったのは2004年型のミニバン。
実際にバッテリーの電圧を測定してみると、
12.5Vほどあるので、それほど低いわけでもないのだが、
3年前に新車で買って、それ以来、一回も
バッテリー交換したことがない、ということだった。
車のオーナーの方も、できれば新品に交換してほしい、ということだったので、
思い切ってバッテリーを新品に交換することにした。
古いバッテリーを外してた後、
現場がシアーズ(Sears)にも近かったので
迷わずシアーズのオートセンターへ直行。
幸い、ちょうどいいバッテリーの在庫が1個だけあった。
現場に戻って、買ってきた新品バッテリーを取り付けてみると
何の問題もなくエンジンがかかるようになった。
結局、今回のバッテリー交換も、
今までこのブログでバッテリーについて
調査してきたことをそのまま実行しただけだった。
今回の教訓としては、バッテリー交換後の電圧測定を忘れたこと。
つまり、非常に少ない確立ではあるが、
発電機(ダイナモ)が故障して、その結果、
バッテリーが上がってしまったのかもしれない、
という可能性が残っているからだ。
チョット心配だったので、翌日 改めて測定させていただいた。
その具体的な方法は、
バッテリーのプラス、マイナス両端間の電圧を
まずはエンジンを切った状態で測定する。
だいたい、正常であれば、12.6V前後になるハズ。
次に、エンジンをかけた状態でもう一度測ってみる。
すると この場合、だいたい 14.0V 付近の電圧が測定できれば
発電機が発電していると言える。
実際に測定してみると、予想通りの電圧だったので
まずは一安心といったところ。
【参考リンク】
カテゴリー:
バッテリー
22:53
| コメント (0)
| トラックバック (0)
「
自閉症児 渡の宝箱「ジュースがかかったPC」」
にも書いてあるとおり、
ノートPCにダイエット・コーラがかかってしまった、
ということで出動要請があった。
モノは東芝の「Satellite A200」。
最近 ご購入されたノートPCである。
ちなみに Windows Vista がインストールされている。
状況としては、昨晩、ダイエット・コークが
キーボードの上にこぼれてしまったそうで、
その直後に、PC表面の拭き取りと、掃除機による吸引をされたそうだ。
分解してみると、キーボード・ユニットは
接点の部分がゴムの幕で覆われているいる構造だったので、
コーラの直撃を受けたにも関わらず、
表面のコーラを拭き取っただけで、
問題なく動作した。
それから、外せるディバイス、つまり
メモリ、HDD、オプティカル・ディバイス 等を まず外し、
それから、本体のカバーの取り外しにかかった。
ところが、液晶パネルの部分を固定している
ネジまで外さないと本体表面のカバーが外れない構造になっていたので、
結局、液晶パネルまで外すことになってしまった。
液晶パネルを外すということは、本体基板と画面信号ケーブルのコネクタ、
それから、最近のノートPCは、ワイアレスLAN や ブルートゥース(Bluetooth) が
組み込まれているので、それらのアンテナへの同軸ケーブルも外さなければならなくなる。
その辺がチョット面倒くさかった。
どうにか、本体カバーを外して メインの基板を観察してみたのだが、
思ったほど内部には流れ込んでいなかったようだ。
それでも、部分的にはコーラが基板の上に付着し、
既に乾燥し始めていたので、それらを
綿棒にアルコールを含ませて丁寧に拭き取っていった。
全ての拭き取り処置が終わった後、
段階的に組み立てながら、その都度、
電源を入れて動作確認をしていったが、
問題なく動作してくれてた。
完全に組み上げてた後、全体の動作確認をしたが、
全ての機能が問題なく動作してくれた。
これで一安心。
教訓として、
「
自閉症児 渡の宝箱「ジュースがかかったPC」」
にも書かれているが、
ノートPCの上にジュース等をこぼした直後であれば、
掃除機による吸引というのは結構 効果があるようだ。
しかし、いずれにせよ 本体を 分解・掃除 をするに越したことはないと思う。
カテゴリー:
PC
22:36
| コメント (0)
| トラックバック (0)
Microsoft Office 2007 のプログラムである
PowerPoint 2007、Excel 2007、Word 2007 では
保存形式として Office オープン XML 形式が追加された。
この新しい形式で保存されたファイルの拡張子がそれぞれ
パワーポイントの場合「.ppt」が「.pptx」へ、
エクセルの場合「.xls」が「.xlsx」へ、
そしてワードの場合「.doc」が「.docx」へ、と変更されている。
マイクロソフト(Microsoft)からは、
この新しい Office オープン XML 形式のファイルを
以前のバージョンの Microsoft Office で開いたり保存したりできるようにするために
互換機能パックが提供されている。
これについては、マイクロソフト(Microsoft)の
「
Microsoft Office 互換機能パックをインストールして、2007 Office プログラムで作成したファイルを以前のバージョンの Excel、PowerPoint、および Word で開いたり保存したりできるようにする方法」
に詳しく解説されている。
このページによると、互換機能パックは、
Microsoft Office 2003 プログラム、Microsoft Office XP プログラム、
または Microsoft Office 2000 プログラムを実行しているコンピュータにインストールできる、
とある。
大まかな手順としては、
まず、Office の更新プログラムを利用して、
最新のサービス・パックやパッチを当てておく。
次に、
「
Word/Excel/PowerPoint 2007 ファイル形式用 Microsoft Office 互換機能パック」
のページからを互換機能パック「FileFormatConverters.exe」をダウンロードする。
そして、最後にダウンロードした「FileFormatConverters.exe」を実行してインストールすることができる。
互換機能パックが正常にインストールされると、
上記の新しい形式のファイルを開けるようになるのはもちろんのこと、
加えて、Word、Excel、PowerPoint、それぞれのアプリケーションにおいて、
名前をつけて保存する際に、
「.docx」「.xlsx」「.pptx」 の新しいファイル形式を
指定することができるようになる。
【参考リンク】
// Amazon Japan の ライブリンク (ソフトウェア)
カテゴリー:
Windows
22:32
| コメント (0)
| トラックバック (0)
今回のJTPAギークサロンは ユーザインタフェースに関する研究で
「富豪的プログラマー」として有名な、
現在はAppleに勤務されておられる 増井俊之氏。
増井氏に関する情報として、
増井氏は 今までの研究成果を
「
pitecan.com」
というサイトで公開されておられる。
今回のサロンでも このサイトに挙がっている項目についてのデモなどが多々あった。
また、サロンの題目にもなっている富豪的プログラミングについても、
このサイトの
「
富豪的プログラミング」
ページに その考え方が示されている。
さらに、増井氏は Rubyist としても有名で、
Rubyist Magazine の
「
Rubyist Hotlinks 第5回 増井俊之さん」
に インタビュー記事が掲載されている。
今回のサロンの内容とも重なる部分があるので、
興味のある方は、こちらも読まれることをお薦めする。
実際には多数のデモがあったが、例えば、
などなど。
ちなみに、上記の辞書が なぜ 「ピテカン(pitecan)辞書」というかと言うと、
「Pithecanthropus」という単語を検索する際にも
間違った綴りの「pitecan」と入力しても見つけ出すことができるからだそうだ。
また、現在 アップル社に在籍中の増井氏は
デモ機としてMacを使っておられたが、途中
ご自分の 日本語入力システムをデモされた際に
MacOSの「ことえり」は不要だ、ということで
「ことえり」を終了させてしまって、会場は 大爆笑になった。
ちなみに、「ことえり」の生みの親は、
JTPAでも おなじみの 木田さん である。
【参考リンク】
カテゴリー:
JTPA
22:18
| コメント (0)
| トラックバック (0)
Javaの 組み込み機器用のプラットホーム「JavaME(Java Platform, Micro Edition)」には
現在のところ、2つのコンフィグレーションが存在する。
ひとつは、昨日のブログでレポートした「CLCD (Connected Limited Device Configuration)」で、
もうひとつが、今日のブログのネタである
「CDC (Connected Device Configuration)」である。
CDC は、比較的高速なネットワークに接続された
ハイエンドのPDA、セットトップ・ボックス
等のコンシューマー機器 や 組み込み機器を 想定デバイスとしている。
そのスペックとして
32-bit のプロセッサ、2 MB の RAM、
Javaプラットホーム用の 2.5 MB の ROM が
搭載されていることを前提としている。
CDC は CLCDのスーパーセットであり
CDC 1.1の機能は、J2SE 1.4.2に相当する。
ただし、一部機能は利用できない。
CDC上のプロファイルとしては以下のように3つあり、
- Foundation Profile
- JavaSE(Java Platform, Standard Edition)を基にした クラス・ライブラリ
- GUIはサポートしていない
- CLDC 1.0 互換ライブラリ
- Personal Basis Profile
- Foundation Profile API を全て含む
- Lightweight component (軽量コンポーネント) をサポート
- Xlet をサポート
- Personal Profile
- Personal Basis Profile API を全て含む
- 完全な AWT をサポート
- アプレットをサポート
- PersonalJava からの移行可能
のような構成になっている。
上記を見てもわかるように、
「Foundation Profile」を「Personal Basis Profile」が、
その「Personal Basis Profile」を「Personal Profile」が包含している。
これらの各プロファイル毎の違いは
基本的にGUIに関する部分の違いによる。
CDCのプロファイルに上記の3つが あるということ知っておくと、
例えば カタログに「CDC/FP」というような記述があった場合に、
それが CDCの Foundation Profile のことを意味していることがわかる。
CDCのドキュメントに関しては、API Documentation として
「
日本版 Connected Device Configuration (CDC), バージョン 1.1.2」、
「
日本版 Foundation Profile, version 1.1.2」
がある。また、
「
CDC White Paper 日本語版」
でも、CDC全般に関しての詳しい説明が日本で読めるので非常に参考になる。
【参考リンク】
カテゴリー:
Java
22:10
| コメント (0)
| トラックバック (0)
Javaの 組み込み機器用のプラットホーム「JavaME(Java Platform, Micro Edition)」には
現在のところ、2つのコンフィグレーションが存在する。
ひとつは、「CDC (Connected Device Configuration)」で、
もうひとつが、この「CLCD (Connected Limited Device Configuration)」
である。
CLDCは、CPUパワーやメモリ、グラフィック性能が制限されている
ポケベル、携帯電話、低機能のPDA などで
利用されることを前提に設計されている。
CLDCで具体的に前提としている機能や性能としては、
- 16MHz以上のクロックの 16-bit もしくは 32-bit のプロセッサ
- CLDCライブラリや仮想マシン用の 160KB以上の不揮発性メモリ
- Javaプラットホーム用の 最低192KBのメモリ
- バッテリーでも稼動できる 低消費電力
- 帯域幅の制限されたネットワーク接続機能
となっている。
上記のような仕様の機器でJavaを走らせるために、
CLDCライブラリは、
JavaSE(Java Platform, Standard Edition) のAPIのうち
- java.lang
- java.io
- java.util
という3つの基本パッケージのサブセットと
という、合計でも わずか4つのパッケージの構成になっている。
CLDC上のプロファイルとして、
- MIDP (Mobile Information Device Profile)
- DoJa
- IMP (Information Module Profile)
などが存在している。
この中でも「DoJa」は NTTドコモの携帯電話でJavaアプリケーション、
いわゆる「iアプリ」を開発するためのプロファイルである。
【参考リンク】
カテゴリー:
Java
22:07
| コメント (0)
| トラックバック (0)
昨日のブログで、Java のプラットフォームに
「JavaSE」「JavaEE」「JavaME」の3つがあることまで調査できた。
今回は特に、「JavaME」について調査してみる。
Java ME とは、以前は「J2ME」と表記されていたもので、
MEは「Micro Edition」の頭文字から来ており、
主に組み込み機器を対象としている。
組み込み機器と言っても、ポケベルや炊飯器のような機器もあれば、
携帯電話、PDA、セットトップボックスや
インターネット接続もできるテレビまで といろいろである。
また、メモリやCPUの性能の違いというだけでなく、
機能として、キーボードやディスプレー・デバイスが
あるものないものと、それぞれの機器によって、動作環境が異なるわけだ。
そのため、「Java ME」には
「JavaSE」「JavaEE」とは異なり、
「Java ME」というプラットフォームの中にさらに
もっと細かな分類が存在している。
このことについては、
Sun Developer Connection(日本語版)「Java ME」
に解説されているとおり、
- コンフィグレーション
- プロファイル
- オプションパッケージ
の3つの分類がある。
「コンフィグレーション」 については、
Java 仮想マシンおよびクラスライブラリの最小セットを定義している。
現在のところ、
- CLDC (Connected Limited Device Configuration)
- CDC (Connected Device Configuration)
という2つのコンフィグレーションがある。
「プロファイル」 と言うのは、
携帯電話あるいは PDA など特定のカテゴリに属するデバイス向けの
完全な実行環境を提供するために定義された API のセットである。
CDC、CLDC の各コンフィグレーション毎に、
MIDP、 DoJa、
Foundation Profile(JSR 219)、
Personal Basis Profile(JSR 217) 、
Personal Profile(JSR 216)
など複数のプロファイルが存在する。
「オプションパッケージ」とは、
より限定的なマーケットの要求をサポートするために、
コンフィグレーションおよびプロファイルに追加して使用できる機能
(Web サービスやマルチメディア機能など)を定義している。
【参考リンク】
カテゴリー:
Java
22:27
| コメント (0)
| トラックバック (0)
今日も Javaの続き。
今回は、Java のプラットフォーム について調査してみた。
Javaはもともと、「 Write once, run anywhere.(一度コードを書けば、どの環境でも動く)」
を目指していたので、当初は1種類のJavaしかなリリースされていなかった。
しかし、下は ポケベルのような小さな組み込みシステムから
上は大規模なエンタープライズ・サーバー・システムまで
と多様化するニーズに1つのJavaで対応するのは不可能と
サン・マイクロシステムズも判断し、現在のところ、
以下の3つのプラットフォーム(エディション)に分かれている。
- Java SE(Java Platform, Standard Edition)
主にデスクトップを対象としており、
最も一般的なJava環境。
- Java EE(Java Platform, Enterprise Edition)
主にサーバーを対象としており、
Java SE に加え、サーバーサイドに特化した機能が付加されている。
- Java ME(Java Platform, Micro Edition)
主に組み込み機器を対象としており、
メモリなどのリソースが限られた機器上でも動作できるように
機能を限定した環境。
以前は、上記のプラットフォームを それぞれ
「J2SE」 「J2EE」「J2ME」と呼んでいた時期もあり、
少し古い書籍などでは そのような表記が残っているが、
現在では、上記のとおり
「JavaSE」「JavaEE」「JavaME」となっている。
【参考リンク】
カテゴリー:
Java
22:44
| コメント (0)
| トラックバック (0)
昨日に続き、Javaについて。
Javaのことを調査していると、必ず
「JSR 176」というような表現に出会う。
これは何なのかを調べてみる。
JSRについて調べるまえに、
まず、Javaの仕様の決め方について。
Javaは もともと Sun Microsystems社 によって開発されたので、
その仕様も もちろん Sun Microsystems社によってきめられたものだった。
しかし現在では、
Javaの新しい仕様や方向性については
Sun Microsystems 1社で決めているわけではなく、
多くの企業や個人が参加するコミュニティによって決められている。
このコミュニティによって進められる仕様策定のプロセスのことを
「
JCP(Java Community Process)」
と呼んでいる。
JCPのメンバーによって、提案された新たなJavaの仕様は
JSR(Java Specification Request) 文書として
番号付きで管理される。
その後、専門家によるコミュニティ・ドラフト、
そして一般からのレビューとフィードバックを受けるパブリック・ドラフト
の段階を経て最終承認を受けることになる。
最終承認を受けた後も、その仕様のJSR番号は そのまま残されている。
また、同じテクノロジーに関する仕様でも、
そのバージョンにより、別々のJSR番号になっている。
例えば、Java Standard Edition に関して言えば、
J2SE1.4 が JSR 59、
J2SE5.0 が JSR 176、
Java SE 6 が JSR 270
のようになっている。
このような仕様の承認経緯から、
最近のすべてのJavaの仕様にはJSR番号が割り振られている。
主なJavaの仕様と そのJSR番号は
ウィキペディア「Java_Community_Process」に一覧としてまとめてある。
【参考リンク】
カテゴリー:
Java
10:12
| コメント (0)
| トラックバック (0)
これから、少しずつ、Javaについても調査してみようと思うが、
今日は、まず Java に関する情報の収集方法について調査してみる。
「Java」は、ご存知のとおり、
サン・マイクロシステムズ(Sun Microsystems)社が開発した
プログラミング言語である。
よって Javaに関する情報は サンが供給しているものがオリジナルとなる。
Javaについて調査していると、すぐに見つかるのが
「
java.com」
であるが、これは どちらかと言うと ユーザー向けのサイトになっているようだ。
ここでは、各種OS向けの Java Runtime Environment が
ダウンロードできるようになっている。
開発者向けの情報は
Sun Microsystems 「The Source for Java Developers」
が本家。もちろん英語。
日本語では、
「
JAVAテクノロジ」がホームページとなっているが、
詳細については、ほとんどの項目が英語サイトへのリンクとなっているようだ。
どうも、Javaの開発環境について、詳しく調査するには
英語を読むしかないようだ。
日本語としては、どちらかというと
「
Sun Developer Connection(日本語版)」
の方が情報量が多いようだ。
それから Javaのチュートリアルは、もちろん英語ではあるが、
「
The Java Tutorials」
からアクセスできる。
Java言語仕様は
「
The Java Language Specification」
にある。現在のところ第3版になっている。
書籍として出版もされているが、
ウェブページ
「
The Java Language Specification, Third Edition
からでも読むことができる。
でも このサイトを読むのは よっぽどのことでもなければ読まないと思うが。
Javaに関する日本語の情報としては、@ITの
「
Java Solution」
に 多数の記事としてまとめられている。
ここにある記事を読みこなせば、立派なJavaスペシャリストになれるかもしれない。
【参考リンク】
カテゴリー:
Java
22:06
| コメント (0)
| トラックバック (0)
最近ちょうど電波時計を入手したのだが、
実際に 時間情報を受信させてみると、
結構 時間がかかっている。
その理由を探ってみた。
「
日本標準時プロジェクト」
のサイト内には、
「
標準周波数局の諸元」
というの掲載されている。それによると、
変調波が 1 Hz (秒信号) となっている。
これは単純に言うと、1秒間で1ビット、
つまり 1 bps の転送レートということになる。
最近のインターネットのDSLのスピードが 1Mbps とか 光ファイバーだと 100Mbps と言われているのと比較すると、
どれだけ「ゆっくり」としたスピードかが判る。
また、
「
長波JJY送信方法」
に 電波に乗せられている情報の詳細が記載されている。
それによると、
この標準電波に載せて送らなければならない情報は、
- 時: 4時間制日本標準時 ( 6 bit, 累積 6 bit)
- 分: 日本標準時の分 ( 7 bit, 累積 13 bit)
- 通算日: 1月1日を1とした通算の日 ( 10 bit, 累積 23 bit)
- 年: 西暦年の下2桁 ( 8 bit, 累積 31 bit)
- 曜日: 日曜〜土曜を0〜6に割り当てた値 ( 3 bit, 累積 34 bit)
- うるう秒情報: うるう秒の有無と正負の別 ( 2 bit, 累積 36 bit)
- パリティ: 時と分に対応し、それぞれ1ビットの偶数パリティ ( 2 bit, 累積 38 bit)
- 予備ビット: 将来の拡張性用。夏時間が採用されるとこのビットを利用するようだ。 ( 2 bit, 累積 40 bit)
- 停波予告ビット: 保守作業等で標準電波の停波が予定されるときの情報( 6 bit, 累積 46 bit)
と、このように、全体のビットの合計は 46ビット。
つまり、標準電波上で これだけの情報を 送信(受信)するのに、
最低46秒は必要となる、ということだ。
実際問題として、私の電波時計では、時刻情報の取得に3分から5分ほど掛かっている。
【参考リンク】
カテゴリー:
便利グッズ・ガジェット
,
通信
22:53
| コメント (0)
| トラックバック (0)
昨日のブログで、日本の標準電波送信所についてレポートしたが、
最近、日本で発売されている電波時計も 北米対応になってきているようだ。
それでは アメリカでの標準電波は、どうなっているのであろうか?
日本では標準電波の管理を
「
独立行政法人情報通信研究機構
(NICT:National Institute of Information and Communications Technology)」
が行っている一方 アメリカでは
「
NIST(National Institute of Standards and Technology)」
という組織が それを行っている。
アメリカの標準電波送信所のコールサインは「WWVB」。
コロラド(Colorado)州 フォート・コリンズ(Fort Collins)にある。
「
Google Map」
で全米の地図を開いてみるとわかるが、アメリカ大陸のほぼ中央に位置している。
シリコンバレー(Silicon Valley)からすると、東北東くらいの向きになる。
ということは、電波時計を家の中で置いておく場合は、
東向きの窓際に置いておいた方が良いことになる。
この標準電波送信所「WWVB」について詳しくは、
「
NIST Radio Station WWVB」
に掲載されている。
このページによると、発信周波数は60kHz。
ということは、昨日のブログで紹介した
日本国内に2つある標準電波送信所のうちの1つ、九州北部の
「
はがね山標準電波送信所」
と同じ周波数ということになる。
また、空中線電力も 50kW と同じである。
考えてみると、日本の場合、
狭い国土に対し、2ヶ所の標準電波送信所があり、
それぞれが、空中線電力 50kW の出力である。
一方、アメリカの方は 広い国土にもかかわらず、
コロラド(Colorado)にある1ヶ所の標準電波送信所で
全米をカバーしよう、ということになる。
しかも空中線電力は、2つある日本の送信所の片方の送信所と同じ。
つまり、日本の半分ということになる。
感覚的に、広大なアメリカ大陸全体をカバーするなら、
もうチョット電波の出力を上げてもいいんじゃない、
っていう気がする。
【参考リンク】
カテゴリー:
便利グッズ・ガジェット
,
通信
22:47
| コメント (0)
| トラックバック (0)
先日の6月10日は「時の記念日」だったそうだが、
最近ちょうど電波時計を入手したので、
それについて調査してみた。
「電波時計」は最近 非常に普及してきたので
既にお使いの方も多いと思うが、
ご存知の通り、基準となる電波を受信して、
時刻の修正を行い、常に正確な時刻を刻み続ける時計のことである。
では一体、その電波は誰がどこから発信しているのか、という疑問がわいてくる。
調べてみると、日本国内での標準電波の発信は
「
独立行政法人情報通信研究機構
(NICT:National Institute of Information and Communications Technology)」
が行っている。
実際には2つの標準電波送信所があり、
1つは、「福島局」と呼ばれている
福島県田村市都路町と双葉郡川内村境界の
大鷹鳥谷山(おおたかどややま)山頂の
「
おおたかどや山標準電波送信所」。
もう一つは、「九州局」と呼ばれている
佐賀県佐賀市富士町と福岡県前原市境界の
羽金山(はがねやま)山頂の
「
はがね山標準電波送信所」
である。
コールサインは「JJY」
空中線電力は それぞれ 50kWとなっている。
周波数は、福島局が「40kHz」、
九州局が「60kHz」となっており、
これは、電波の分類としては長波となる。
ちなみに通常のAMラジオの周波数が530kHz〜1600kHz
であるから、どれだけ低い周波数であるかがわかる。
【参考リンク】
カテゴリー:
便利グッズ・ガジェット
,
通信
22:54
| コメント (0)
| トラックバック (0)
JUNBAの定例講演会として、
「行政官庁論 経済産業省 VS 文部科学省」
と仰々しい題目のパネル・ディスカッションが行われた。
これは、ベイエリアからこの6月末で帰任される
文部科学省の2名の方と 経済産業省の1名の方に
帰任を前にして、今までの在任期間を振り返っていただき、
今後のシリコンバレー、そして日本について
大いに語っていただこう、という企画。
さらに 折角
産業界を司る「経済産業省」と
教育界を司る「文部科学省」という
日本を代表する2つの行政官庁 の お役人に
お越しいただくわけなので、
それぞれの組織の違いや、
取り組み方の違いについても、語って頂いた。
私は日本国内のことはよくわからないが、
おそらく、このような会合は
日本国内では行われたことがないのではないかと思う。
講演会では まず それぞれのパネラーに
ご経歴や、シリコンバレーに赴任されるまでの経緯、
赴任後の活動等を語っていただいた。
その中には、アメリカでの子供さんの教育を通しての感想もあった。
それは、よく言われていることではあるが、
アメリカでの教育ではプレゼンテーションが重視されている、ということ。
その時の表現をお借りすると、
「トリビアの泉」の「へー」ボタンを
いかに沢山 押してもらえるプレゼンテーションができるのか、ということ。
アメリカでは小学校からでも そのような教育が行われている。
その後、「経済産業省 VS 文部科学省」ということで、
経済産業省と他省との比較が議論された。
その時の資料に 中井 浩一 による
「
徹底検証 大学法人化」
からの引用があった。
それを ここでいくつかご紹介させていただくと、
経産省は、外国との貿易交渉を使命とし、
広く国内全体を視野に入れて動いている官庁である。
そのために最初から横割り的な発想と行動が身についている。
それに比べると、他は縦割り行政の官庁なのだ。
そこで「攻める」経産省に「守る」他官庁という図式が構成される。
他省から見れば、経産省は自分のテリトリーに出てきているように見えるし、
経産省から見れば他は「自分の省益の範囲でしか頭が動かない」ように
見えるわけだ。
経産省の行動は、基本的に「問題提起型」だ。
現状に異議申し立てをするのが仕事なのだ。
一方、他の官庁は、基本的に「現状維持型」と言える。
経産省には、新たなプランの策定、新たな視点を絶えず提出する役割がある。
逆に言えば、それが自己確認であり、それをし続けないと、
自己を見失ってしまう官庁なのだ。
文科省は どんどん小さくなっていく。
文科省の使命は、この地方の時代への移行をスムーズに行い、
自らの「終わり」を完結することだろう。
しかし、文科省がなくなることはないだろう。
「監督官庁」としての役割を終え、情報サービスの官庁になっていくのではないか。
実際の パネル・ディスカッションも
内容を踏まえたものとなった。
その議論から、私なりに理解したことは、
- 経済産業省は他省と比べると異質な存在であり、
その原因は、他省と異なり、ビジネスの世界を対象としているためのようだ。
- 文部科学省は、確かに 経産省と比較すると保守的である。
また、いろいろな活動をやっているにも関わらず、国民からの誤解を受けやすい。
原因は PR下手。 省としてのプレゼンテーション能力に欠けているからのようだ。
なんとなく、文科省 より 経産省 の方が良い、と言った雰囲気の
論調で展開してしまったが、
将来の日本を背負う次世代の子供たちに必要なのは教育であり、
その教育を司るのは「文部科学省」であることには変わりない。
このシリコンバレーでの小さな会合が
日本の未来に少しでも お役に立つことを期待したい。
この日のJUNBA定例講演会終了後は、
親睦会を兼ねたテニス大会、それに引き続いて
帰任の御三方の送別会を兼ねての
バーベキュー・パーティーとなった。
カテゴリー:
JUNBA
22:43
| コメント (0)
| トラックバック (0)
ここ数日で、FreeBSD上で Apache 2.2.x が吐き出す
「[warn] (2)No such file or directory: Failed to enable the 'httpready' Accept Filter」
というエラーへの対処方法について、その原因を調査してきた。
先日のブログで、それなりの対応方法をレポートしたが、
今日は、別の方法も探ってみる。
先日のブログでレポートした、accf_http.koをカーネルにロードする方法は、
自分で管理している場合はよいが、
これが、Jail環境等のバーチャル・サーバー環境等では、
必ずしも、accf_http.ko をカーネルにロードできるとは限らないであろう。
さて、そのような場合には、どのように対応したらよいのか?
昨日のブログで書いたとおり、
2.1.5 以降の Apache では、システムが FreeBSDだと、
デフォルトでAcceptFilterが有効となってしまうようだ。
それでは、強制的に AcceptFilter を無効にしてしまってもよいのではないだろうか。
つまり、強制的に AcceptFilter を無効にするための
AcceptFilter http none
AcceptFilter https none
の2行を httpd.conf に記述してしまえばよいのではないか。
では、実際に実験してみた。
実験なので、httpd.conf の先頭に、上記の2行を挿入し、
それから、/boot/loader.conf の
accf_http_load="YES"
を削除してから、システムをリブートしてみた。
結果として、Apacheを起動する際には何のエラーの表示されなかった。
また、確認として kldstat コマンドを実行してみたが
% kldstat
Id Refs Address Size Name
1 7 0xc0400000 7a05b0 kernel
2 1 0xc0ba1000 5c304 acpi.ko
3 1 0xc2447000 19000 linux.ko
のように、確かに accf_http.ko は ロードされていない。
結論として、FreeBSD上で Apache 2.1.5以降 が吐き出す
「[warn] (2)No such file or directory: Failed to enable the 'httpready' Accept Filter」
エラーに対応する方法は 2通りある。
一つは、カーネル・ロードモジュール accf_http.ko をロードすること(先々日のブログ参照)。
そして、もうひとつは、今日のブログのとおり、httpd.conf に
AcceptFilter http none
AcceptFilter https none
の2行を付け加える、
という方法である。
【参考リンク】
カテゴリー:
Apache
22:13
| コメント (0)
| トラックバック (1)
昨日のブログで、Apache 2.2.x が吐き出す
「[warn] (2)No such file or directory: Failed to enable the 'httpready' Accept Filter」
というエラーへの対処方法について調査したが、
今日のブログで、もう少し根本原因ついて調査してみたいと思う。
いつものごとく、いろいろググっていたら、
(FreeBSD) apache-2.2.xの「httpd -DNOHTTPACCEPT」って何だ? 〜 accf_http
というページに出くわした。このページで非常に詳しく解説してあったので、その内容に基づいて、調査を進めてゆく。
まず、上記のエラーは アパッチの
「
AcceptFilter ディレクティブ」
に関係があるそうだ。
マニュアルを引用させていただくと、
Listen しているソケットに対して、
OS が固有に持っているプロトコルについての最適化を
有効にするディレクティブです。
大前提となる条件は、データが受信されるか
HTTP リクエスト全体がバッファされるかするまで、
カーネルがサーバプロセスに ソケットを送らないようになっている、
ということです。
現在サポートされているのは、 FreeBSD の Accept Filter と
Linux のプリミティブな TCP_DEFER_ACCEPT のみです。
とある。
そして、FreeBSD のデフォルト値は :
AcceptFilter http httpready
AcceptFilter https dataready
である、と記述されている。
ここでやっと エラーの中にある「httpready」というキーワードがみつかった。
さらに
httpready Accept Filter は HTTP リクエスト全体を、
カーネルレベルでバッファリングします。
リクエスト全体を受信し終わると、
その後サーバプロセスにそれを送ります。
詳細については accf_http(9) を参照してください。
HTTPS のリクエストは暗号化されているので accf_data(9) フィルタのみが使用されます。
と説明されている。
それでは FreeBSDマニュアルの
「
accept_filter 「入力接続フィルタ」」
をみてみる。 その解説には、
accept フィルタは、カーネルが入力接続を前処理することを、
アプリケーションが要求することを可能にします。
accept フィルタは、SO_ACCEPTFILTER の
optname で渡すことで、setsockopt(2) システムコールを介して要求されます。
とある。このように、accept_filter は カーネルが入力接続を前処理するために
汎用的なしくみを提供している。
その中でも、特に HTTP に関して バッファリングを行っているのが
accf_http「ある完全な HTTP リクエストの到着までの間の入力接続バッファ」
のようだ。これを有効にすると、HTTPのリクエストが全て揃うまで、カーネル側でパケットをバッファリングしておく。
リクエストの全てが揃った段階でアプリケーションサイド(この場合はApache)へパケットを受け渡すことにより、
カーネルとアプリケーション間の無駄なタスク切り替えを少なくすることができ、
結果的にCPUの利用効率を向上されることができるようだ。
以上のことから、
「[warn] (2)No such file or directory: Failed to enable the 'httpready' Accept Filter」
エラーの原因を考えてみる。
前述の通り、2.1.5 以降の Apache では、システムが FreeBSDだと、
デフォルトでAcceptFilterが有効となってしまうようだ。
一方、FreeBSDを普通にインストールすると、accf_http.ko がカーネルにロードされていない。
よって、FreeBSDに Apache 2.1.5 以降 をインストールすると、
このエラーに遭遇する、と考えられる。
このことから、もう一つの解決方法が考えられるが、それについては、
明日のブログとしよう。
【参考リンク】
カテゴリー:
Apache
22:41
| コメント (0)
| トラックバック (0)
FreeBSD上で Apache 2.2.x を起動させると
[warn] (2)No such file or directory: Failed to enable the 'httpready' Accept Filter
のようにWarningが出る場合がある.
このWarningの意味は何なのか?
どのように対応したらよいのか?
いろいろググってたら、原因は
accf_http.koというカーネルモジュールがないためのようだ。
よってその解決策としては、
# kldload accf_http.ko
を行って、accf_http.ko カーネル・モジュールをロードしてから
アパッチを再起動するとよいらしい。実際に試してみると確かに上記のエラーが出なくなった。
ちなみに
「
kldload」
とは カーネルリンカを用いて XXXX.ko をカーネルにロードするコマンド。
また、現在のカーネルモジュールを確認するには、動的カーネルリンカの状態を表示するコマンド
「
kldstat」
を用いて
# kldstat
Id Refs Address Size Name
1 8 0xc0400000 7a05b0 kernel
2 1 0xc0ba1000 5c304 acpi.ko
3 1 0xc2447000 19000 linux.ko
4 1 0xc2843000 2000 accf_http.ko
のようにするとよい。
ただし、このままでは アパッチを起動する際に、毎回 kldload コマンドを手入力しなければならなくなる。
この事態を避けるためには FreeBSDの起動時に自動的に accf_http.ko を読み込ませればよいことになる。
そのためには、
/boot/
loader.conf
に
accf_http_load="YES"
の一行を加えておけばよい。
これも実際に試してみて、確かに
FreeBSDの起動時から Apache 2.2.x がエラーなく起動するようになった。
これで、とりあえず、エラーは出なくはなったが、
何故、このエラーが表示されていたのか?
このエラーに対してアパッチ側での何の対応もできないのか?
という疑問が残る。
もう少し、調査してみることにする。
【参考リンク】
カテゴリー:
Apache
,
FreeBSD
22:31
| コメント (0)
| トラックバック (0)
FreeBSD において、
例えば emacs をports からインストールしようとすると
デフォルトでは X11 関連のライブラリも同時にインストールされてしまう。
しかし、バーチャル・プライベート・サーバ等を間借りしているような場合は
telnet(SSH)でログインして、キャラクターベースでしか emacs を使わない訳だから、
X11関連のライブラリは不要である。
そんな不要な X11関連の巨大なファイル群で
貴重なディスク・スペースが占領されてしまうのは非常にもったいない話だ。
そこで、emacsを X11無しでコンパイルする方法があるのかを調査してみた。
まず、/usr/ports/editors/emacs にある、Makefile を解析してみる。
# New ports collection makefile for: GNU emacs
# Date created: 11 October 2001
# Whom: MANTANI Nobutaka <nobutaka@nobutaka.com>
#
# $FreeBSD: ports/editors/emacs/Makefile,v 1.73 2007/10/08 23:29:46 keramida Exp $
#
PORTNAME= emacs
PORTVERSION= ${EMACS_VER}
PORTREVISION= 2
CATEGORIES= editors ipv6
MASTER_SITES= ${MASTER_SITE_GNU}
MASTER_SITE_SUBDIR= ${PORTNAME}
MAINTAINER= keramida@ceid.upatras.gr
COMMENT= GNU editing macros
.if !defined(WITHOUT_X11)
.if defined(WITHOUT_GTK)
LIB_DEPENDS= Xaw3d.${XAWVER}:${PORTSDIR}/x11-toolkits/Xaw3d
.endif
LIB_DEPENDS+= jpeg.9:${PORTSDIR}/graphics/jpeg \
tiff.4:${PORTSDIR}/graphics/tiff \
ungif.5:${PORTSDIR}/graphics/libungif \
png.5:${PORTSDIR}/graphics/png
.endif
CONFLICTS= emacs-19.* emacs-21.* \
xemacs-[0-9]* xemacs-devel-[0-9]* \
xemacs-mule-[0-9]* xemacs-devel-mule-[0-9]*
EMACS_VER= 22.1
GNU_CONFIGURE= yes
USE_GMAKE= yes
.if !defined(WITHOUT_X11)
.if !defined(WITHOUT_GTK)
USE_GNOME= gtk20
.else
USE_XLIB= yes
.endif
USE_XPM= yes
.endif
CONFIGURE_TARGET= ${MACHINE_ARCH}-freebsd
.if defined(WITHOUT_X11)
CONFIGURE_ARGS= --with-x=no
.else
.if !defined(WITHOUT_GTK)
CONFIGURE_ARGS= --with-gtk
.endif
.endif
.if defined(WITHOUT_XIM)
CONFIGURE_ARGS+= --without-xim
.endif
MAN1= ctags.1 emacs.1 emacsclient.1 etags.1
PLIST_SUB= EMACS_VER=${EMACS_VER} EMACS_ARCH=${CONFIGURE_TARGET}
MAKE_ENV= LC_ALL=C
INFO= ada-mode autotype calc ccmode cl dired-x ebrowse ediff \
efaq eintr elisp emacs-mime emacs erc eshell eudc \
flymake forms gnus idlwave info message mh-e newsticker \
org pcl-cvs pgg rcirc reftex sc ses sieve smtpmail speedbar \
tramp url vip viper widget woman
LATEST_LINK= emacs
.include <bsd.port.pre.mk>
.if ${ARCH} == "ia64"
BROKEN= Emacs 22.X does not currently build on ia64
.endif
pre-everything::
.if !defined(WITHOUT_X11) && !defined(WITHOUT_GTK)
@${ECHO_MSG} "====>"
@${ECHO_MSG} "====> To disable GTK+ interface support, define WITHOUT_X11 or WITHOUT_GTK"
@${ECHO_MSG} "====>"
.endif
.if !defined(WITHOUT_X11) && !defined(WITHOUT_XIM)
@${ECHO_MSG} "====>"
@${ECHO_MSG} "====> To disable X11 Input Method support, define WITHOUT_XIM"
@${ECHO_MSG} "====>"
.endif
post-patch:
@${RM} -f ${WRKSRC}/info/*
.include <bsd.port.post.mk>
この中で、ports間の依存関係を記述しているのが 20行目の
LIB_DEPENDS= Xaw3d.${XAWVER}:${PORTSDIR}/x11-toolkits/Xaw3d
という記述だ。
ここで、 Xaw3d など、X11関連が指定されている。
よくみると、その2行上に
.if !defined(WITHOUT_X11)
という記述がある。
これは、「もし、WITHOUT_X11が定義されていなければ」と読める。
つまり、「 LIB_DEPENDS= 」は 「 WITHOUT_X11 」が定義されていない場合に限り
評価される、と言うことだ。
逆に言うと、「もしWITHOUT_X11が定義されていれば、LIB_DEPENDS=... は無視する 」
ということになる。
その後、ググッたりして確認してみると、
先日のブログ「FreeBSD の /etc/make.conf」で ふれた
/etc/make.conf に
WITHOUT_X11=yes
の1行を記述しておくと、
emacs の ports を make する際に、何も指定しなくても、
X11関連を省いた形でビルドしてくれることが判明した。
これについては、
「portsでX非依存で入れたい」
にも記述がある。
また、「WITHOUT_X11=yes」だけでなく、「WITHOUT_GUI=yes」や
「NO_X=true」などもあるようだ。
どこかに、これらの変数についてまとめてあるとうれしいのだが。
【参考リンク】
カテゴリー:
FreeBSD
22:03
| コメント (0)
| トラックバック (0)
既に、Apache 2.0 で 走っているサイトを 、Apache 2.2 にバージョンアップしてみた。
その時のトラブルと、その解決方法について。
以前のブログでもふれたとおり、通常Apacheを起動するためには、
# /usr/local/apache2/bin/apachectl start
のようなコマンドで起動することになる。
一方、今回バージョンアップしたこのサイトには、
https: つまり SSL でアクセスするページが含まれていた。
Apache 2.0 では、SSLを有効とするために、
「start」オプションではなく、
# /usr/local/apache2/bin/apachectl startssl
のような「startssl」オプションを指定する必要があった。
ところが、Apache 2.2 からは、この「startssl」というオプションが廃止され、
SSLを起動する場合でも「start」オプションでよくなった。
これについては、マニュアルの
「
Upgrading to 2.2 from 2.0」に
The apachectl option startssl is no longer available.
To enable SSL support,
you should edit httpd.conf to include the relevant mod_ssl directives
and then use apachectl start to start the server.
An example configuration to activate mod_ssl has been included in conf/extra/httpd-ssl.conf.
と記述されている。
Apacheを 2.0 から 2.2 にアップグレードした後、
従来の httpd.conf と ssl.conf のままに
「apachectl start」として起動してみた。
ちなみに、httpd.conf から ssl.conf をインクルードする設定にしてあり
今まで問題なく起動してきているモノだ。
その結果、通常のページ、 つまり、ポート80 の「http://」のページには
問題なくアクセスできるのだが、
SSLページ、つまり、ポート443 の「https://」のページには
アクセスできないトラブルにハマッてしまった。
いろいろ 試してみた結果、ssl.conf は
キチンとインクルードされていることは確認できた。
その後も いろいろ調査した結果、
結局この問題の解決策として、ssl.conf の中に記述されている
<IfDefine SSL>
と
<IfDefine>
を コメントにすることによって、
従来どおりにSSLのページが動作するようになった。
推測であるが、Apache 2.0 の apachectl は
「startssl」オプションで起動すると、
おそらく、SSLという変数を定義してから、
httpd.conf (ssl.conf) を読み込んでいた、と考えられる。
ところが、Apache 2.2 になって それがなくなったために
<IfDefine SSL> 〜 <IfDefine>
の内部が解釈されなくなったようだ。
それから、今回のようなケースでは、
/usr/local/etc/rc.d/apache2.sh
等の Apacheの自動起動スクリプトの記述にある、
「apachectl startssl」を 「apachectl start」
に書き換えるのもお忘れなく!
【参考リンク】
カテゴリー:
Apache
22:20
| コメント (0)
| トラックバック (0)
FreeBSDでは、アプリケーションを ports で
コンパイル(Make)する際の動作をコントロールするためや、
カーネルやシステム全体をコンパイルし直す際に
「/etc/make.conf」というファイルを作成して、
いろいろ設定する必要がある場合がある。
「make.conf」についてはマニュアル
があり、その一節には、
make.conf の主要な目的は、通常、/usr/src, /usr/doc と /usr/ports にある
FreeBSD ソース、文書 (ドキュメント)、と移植されたアプリケーションの
コンパイルを制御することです。
一般に、特定の制御変数の値をデフォルトから変更する必要があるとき、
システム管理者は make.conf を作成します。
とある。
マニュアルには、沢山の変数についての説明がある。
この 「make.conf」のデフォルト値は、
/usr/share/example/etc/make.conf
もしくは
/usr/share/examples/etc/defaults/make.conf
にあるようだ。
このサンプルmake.confファイルに
多くの変数がコメントとして記述されている。
実際にこのmake.confを利用する際には、
# cp /usr/share/example/etc/make.conf /etc/make.conf
のようにサンプル・ファイルをコピーしてから、
必要に応じて、/etc/make.conf にある
沢山の変数の中からコメントを外すなり、設定値を変えるとよいようだ。
いろいろ make.conf について調査していると、
マニュアルには記述されていない変数も 沢山 存在しているようだ。
例えば、Perlに関しては
PERL_VER=5.8.8
PERL_VERSION=5.8.8
のような設定が存在しているようだ。
【参考リンク】
カテゴリー:
FreeBSD
22:44
| コメント (0)
| トラックバック (0)
FreeBSD が走っている環境で CPU や 周辺デバイスを調査するには、
「 /var/run/dmesg.boot 」というテキストファイルを見てみると良い。
このファイルはマニュアル
「
dmesg」
によると、
「通常は、起動時にファイルシステムがマウントされたすぐ後の、
バッファ内容のスナップショット」
であると記述されている。
具体例を見てみようと思う。
チョット古めPCサーバーを例としてみる。
実際のファイルは長いので、まずは始めの部分だけをみてみると、
Copyright (c) 1992-2004 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
The Regents of the University of California. All rights reserved.
FreeBSD 4.10-STABLE #0: Fri Dec 3 17:06:15 EST 2004
admin@bsdhost.jvds.com:/usr/obj/usr/src/sys/GENERIC
Timecounter "i8254" frequency 1193182 Hz
CPU: Intel(R) Pentium(R) 4 CPU 3.20GHz (3194.10-MHz 686-class CPU)
Origin = "GenuineIntel" Id = 0xf43 Stepping = 3
Features=0xbfebfbff
Hyperthreading: 2 logical CPUs
real memory = 2138767360 (2088640K bytes)
avail memory = 2077728768 (2029032K bytes)
Preloaded elf kernel "kernel" at 0xc0554000.
Warning: Pentium 4 CPU: PSE disabled
Pentium Pro MTRR support enabled
となっている。
この4行目の
FreeBSD 4.10-STABLE #0: Fri Dec 3 17:06:15 EST 2004」
で このシステムのバージョンが 4.10 の STABLE であることがわかる。
さらに、7行目の
CPU: Intel(R) Pentium(R) 4 CPU 3.20GHz (3194.10-MHz 686-class CPU)
で CPUの メーカー、 種類、クロックまでわかる。
また、11行目の
real memory = 2138767360 (2088640K bytes)
avail memory = 2077728768 (2029032K bytes)
という行で、メモリが 2Gバイト 搭載していることがわかる。
この後、各種デバイスについての記述となる。
例えば、
rl0: <RealTek 8139 10/100BaseTX> port 0xe400-0xe4ff mem 0xfbfff800-0xfbfff8ff irq 11 at device 13.0 on pci1
rl0: Ethernet address: 00:17:31:0d:0a:ba
で、 Eternet が 「RealTek」の 8139 で 10/100 対応であることと、
その Macアドレス が判明する。
それから、このサーバーのストレージ・システムを例にとると、
twe0: <3ware Storage Controller driver ver. 1.40.01.002> port 0xe800-0xe80f mem 0xfb000000-0xfb7fffff,0xfbfffc00-0xfbfffc0f irq 11 at device 10.0 on pci1
twe0: 2 ports, Firmware FE8S 1.05.00.068, BIOS BE7X 1.08.00.048
で、3ware の Storage Controller を利用しているのがわかるし、
twed0: <Unit 0, TwinStor, Normal> on twe0
twed0: 114472MB (234439600 sectors)
Mounting root from ufs:/dev/twed0s1a
で、全体の容量が114Gバイトあり、
ルート・ディレクトリ が /dev/twed0s1a にマウントされていることもわかる。
【参考リンク】
カテゴリー:
FreeBSD
22:52
| コメント (0)
| トラックバック (0)
現在、自分が使用中のPCについての
正確な CPUの種類や クロック数、
ましてや マザー・ボードに使用されている
チップセットに関する情報については
なかなか判りずらいものである。
これらの情報を簡単に集めて
教えてくれるソフトウェアがある。
それが、
「
CPU-Z」
というソフトだ。
このソフトは
CPUID というサイトから
zipファイルをダウンロード後、解凍するだけ。
インストールする必要は全くない、
単に、「cpuz.exe」を実行するだけである。
画面には
「CPU」「Cache」「Mainboard」「Memory」「SPD」「About」
という6つのタブが表示される。
例えば、「CPU」タブなら
「Processor」「Clocks」「Cache」
3つのセクションに分かれていて、
プロセッサーの Name, Package, Core Voltage, Core Speed, その他
沢山の関連情報が表示される。
一般の方々に おそらく最も役に立つであろうと
思えるのが、「SPD」タブ。
このタブでは、マザーボード上のメモリのスロットに関する情報が表示される。
メモリ・スロットはいくつあるのか?
また、どのスロットに どのサイズのメモリ・モジュールが搭載されているのか、
まで判ってしまう。
メモリ増設を考える際に、このソフトがあると、
本体の蓋を開けなくても済んでしまうわけだ。
【参考リンク】
カテゴリー:
Software
22:14
| コメント (0)
| トラックバック (0)
以前のブログで、ファイルのダウンロード時に
MD5ハッシュ値(いわゆるMD5チェックサム)の確認方法について調査した。
FreeBSD 上では、標準で「md5」というコマンドが存在するので
何ら新しいソフトウェアをインストールする必要はなかった。
では、ウィンドウズ上にファイルをダウンロードした際には
どうやってMD5ハッシュ値を調べたらよいのだろうか?
これについては、
@IT の
「
ハッシュ値を利用してファイルの同一性をチェックする」
という記事に詳しい解説がある。
この記事では、Windows上で動作する フリーソフトということで
GUI用ツール
「
HashTab Shell Extension」
と
コマンドライン用ツール
「
Availability and description of the File Checksum Integrity Verifier utility」
の2種類を紹介している。
ちなみに、後者 コマンドライン「FCIV」 の方は
本家マイクロソフト(Microsoft)のサポート・ページからダウンロードできるものだ。
今回は、GUI用ツール Beeblebrox.org の
「
HashTab Shell Extension」
の方を試してみよう。
Beeblebrox.org サイトの説明を引用させていただくと、
This is a Windows shell extension that adds a tab to the file properties page.
The new tab is called "File Hashes" and it displays the MD5, SHA1 hashes of the file's contents as well as the CRC-32.
It also has a field where you can paste in the text of a hash for comparison.
This is useful for when download sites display hashes of a file
and you want to check the hash after you download.
See the HashTab page for more info...
となっている。
つまり、ファイルのプロパティ表示に「ハッシュ値」という
タブが新たに加わり、そのタブ内で MD5, SHA1, CRC-32 の3つの
ハッシュ値を表示してくれるらしい。
実際に
Beeblebrox.org
ダウンロードする際には64bitバージョンもあるので、どちらかを選択できる。
32bitバージョンの方の「hashtab_setup.exe」を
ダウンロードしてみたが サイズは 187KB であった。
あとはこの「hashtab_setup.exe」を実行すると
「HashTab 1.14 for x32」セットアップ・ウィザードが起動する。
インストールが終了すると、次に瞬間から利用することができる。
適当なファイルを右クリックして、プロパティを表示させると、
「ハッシュ値」という新しいタブが追加されている。
おどろいたことに、表示が日本語になっている。
言語の設定をみて表示が変わるようにしてあるのであろう。
また、サイズの大きなファイルを指定すると、当然だが計算に時間がかかる。
その様子が「ハッシュ値の取得状況」として画面下にグラフとして表示される。
MD5, SHA1, CRC-32 の それぞれの計算値の下には
空欄があり、その欄へ既知のハッシュ値をカット&ペーストして
横にある「比較」ボタンをクリックすると 比較結果を教えてくれる。
ウィンドウズ上でファイルをダウンロードする機会の多い方は
インストールしておくと便利なソフトだと思う。
【参考リンク】
カテゴリー:
Security
,
Software
,
Windows
22:15
| コメント (0)
| トラックバック (0)
FreeBSDでは システムのブート時に
ディレクトリ「 /usr/local/etc/rc.d 」 に置いてある
実行可能スクリプトを自動的に実行する仕組となっている。
この仕組をつかって Apache HTTP Server を自動的に起動させる
設定をしてみる。
以下のスクリプトが 私が今までに使ってきているモノ。
具体的には、ルート権限になって、
ディレクトリ /usr/local/etc/rc.d に
以下のスクリプトを「apache2.sh」という名前で
保存する。
#! /bin/sh
#
# apache start script
#
#
case "$1" in
start)
if [ -x /usr/local/apache2/bin/apachectl ];then
/usr/local/apache2/bin/apachectl start
fi
;;
stop)
/usr/local/apache2/bin/apachectl stop
;;
*)
echo "Usage: `basename $0` {start|stop}" >&2
exit 64
;;
esac
exit 0
それから、実行可能とするために
# chmod 755 /usr/local/etc/rc.d/apache2.sh
としておく。
あとは、システムを再起動してみて
実際に 自動的に起動するかどうかを確認する。
【参考リンク】
カテゴリー:
Apache
,
FreeBSD
22:38
| コメント (0)
| トラックバック (0)
Apache HTTP Server 2.2 をインストールした
前回のブログからの続き。
まず、起動する前に、-M オプションで
静的にリンクされたモジュールを確認してみる。
% /usr/local/apache2/bin/httpd -M
Loaded Modules:
core_module (static)
authn_file_module (static)
authn_default_module (static)
authz_host_module (static)
authz_groupfile_module (static)
authz_user_module (static)
authz_default_module (static)
auth_basic_module (static)
include_module (static)
filter_module (static)
log_config_module (static)
env_module (static)
setenvif_module (static)
mpm_prefork_module (static)
http_module (static)
mime_module (static)
status_module (static)
autoindex_module (static)
asis_module (static)
cgi_module (static)
negotiation_module (static)
dir_module (static)
actions_module (static)
userdir_module (static)
alias_module (static)
so_module (static)
Syntax OK
問題なく動作していることが確認できた。
これを見る限り、2.2 からは mod_so.c が
デフォルトでリンクされているようだ。
2.0の時は、--enable-so を
指定しなければならなかったような気がする。
次に 手動で起動してみよう。
Apache HTTP サーバ バージョン 2.2「コンパイルとインストール」
を参考にすると
# /usr/local/apache2/bin/apachectl -k start
[Tue May 30 13:12:52 2007] [warn] (2)No such file or directory: Failed to enable the 'httpready' Accept Filter
何やらワーニングのメッセージが表示されるが、
とりあえず起動したようだ。
ブラウザからアクセスしてみると
「It works!」と表示される。
以前はもっと気の効いたデザインだったような気がするが。
ではApacheの終了方法。
# /usr/local/apache2/bin/apachectl -k stop
正常に終了されると何も表示されないようだ。
試しに、起動していな時に終了コマンドを実行してみると
httpd (no pid file) not running
と表示される。
ちなみにApacheの起動時の apachectl に付けられている「 -k 」オプションは
無くても構わない。
上記のコマンドは「apachectl」の代わりに 「httpd」でも同様に動作する。
但しこの場合は「 -k 」オプションが必要となるようだ。
# /usr/local/apache2/bin/httpd -k start
httpd (pid 1195) already running
先ほど出ていたワーニングのメッセージは表示されなくなった。
【参考リンク】
カテゴリー:
Apache
22:13
| コメント (0)
| トラックバック (0)