Faking it

■「御福餅」も表示不正の疑い　農水省が調査

これはきょうかなりこころに残った記事でした（笑）。なんか赤福と御福が争う（？）テレビドラマがあったなぁー。

こうなったら、修学旅行で伊勢に来た関西の小学生はなにをおみやげに買えばいいのかこまってしまうだろうなぁ。表示をごまかしていたとしても、具体的な被害は聞かないし、ここはおふだをまいて「ええじゃないか」ということでどうでしょうか（だめか）。

Leopard

最近のアップルは業績が良くて、ややつむじ曲がりなわたしは、あいつらちょっといい気になってやがる、iPod touchなんか買うものか、とおもったりもしたが、やっぱりなんだかんだいいながらeMacを毎日使っているので、いつまでもPantherでは不便なことも出てきたので、観念してLeopardを買ったら、Tシャツももらえたので満足（単純）。

２日使っただけでは、正直違いはあまりわからない。メインマシンはあいかわらずWindows XPなので、タイムマシーンもたぶんそんなに使うこともないんだろうとおもう。でも、古いマシン（1.25GHz PowerPC + 1Gメモリ）でも最新のOSがスムーズに動くというあたりはMSも見習って欲しいところだ。中身的にたいして変わっていないということかもしれないけれど。

日本語関係の辞書が載ったのはうれしいな。電子辞書をべつに持っているから、それを使えばいいのだけれど、表示の見やすさが違う（リーダーズ英和だったらもっとうれしかったが）。

これで、あと最低３年はこのeMacを使うぞ。

ASUS Eee PC vs IBM ThinkPad 220

昨日のエントリを書いていて、ASUS Eee PCは２１世紀のIBM ThinkPad 220ではないかとおもったので、対応表をつくってみた（適当につくったので間違ってたら教えてください）。

名前	ASUS Eee PC 701	IBM ThinkPad 220
大きさ	225×165×35 mm	226×166×32mm
重さ	0.92kg	1.2kg
CPU	Celeron-M ULV 900MHz	i386SL/16MHz
メモリ	512 MB (MAX 1G?)	2 MB (MAX 6M)
ディスク	4 GB SSD	80 MB HDD
ディスプレイ	7" TFT 800x480	7.7" STNモノクロ 640x480
電源	リチウムイオン	単三６本
カードスロット	MS/SD/MMC	PCMCIA Type II
ポート類	USB 2.0 × 3	シリアル、パラレル
その他	イーサーネット、WiFi、カメラ	フロッピーディスク
OS	Linux	IBM DOS 5.0/V
販売開始	2007年10月	1993年5月
値段	48,700円（13,900台湾ドルから概算）	248,000円

こうやって書いてみると技術のあまりの進歩に驚愕しますな。つくづく自分が歳を取ったなとおもうと同時に、まぁこの進歩を見て来れたのは幸運だったなともおもう。

これから１５年後にはまた想像もつかないようなマシンが出てくるんだろうか。

OLPC Production Delays

■ OLPC XO hit with production delays (Engadget)

OLPC XOの生産が遅れているそうです。年内に手に入らないかも？

ASUS Eee PCに走ろうかなぁ。おなじような値段でメモリは大きいし（まぁ"give 1 get 1"じゃないからだけれど）、軽いし、Eee PCに入っているOpenOffice.orgのワープロだったらたぶん日本語対応もちゃんとしてるだろうし。

Webを見るためのデバイスとしては、Nokia N810というのも相当魅力的だな。あと、iPhone/iPod touchのSDKも出るようだから、Steve Jobsと和解して（というか勝手に毛嫌いするのをやめて）、iPod touchを買うというのもあるか。

おもちゃとしてはChumbyがほしい。

さて、最終的にはどれを買うんだろう＞自分

sugar-jhbuild (3)

（前回までのあらすじ）sugar-jhbuildをだましだまし通したが、ワープロが立ち上がらなかった。

Alt-0のDeveloper Consoleのログを見ると、

**** (1) Assert ****
**** (1) pFrame at abiwidget.cpp:623 ****
**** Continue? (y/n) [y] ****

というのが出ている。フレームウィンドウの作成あたりでおかしくなっているようだ。やれやれ。

./sugar-jhbuild run abiwordとすると、いちおうワープロは走る。でも、日本語設定はどこでやるのかな？sugar-jhbuildでSugarを走らせて、Alt-0でDeveloper Consoleを出しても、ターミナルのTabが見当たらない。QEMUでイメージを走らせたときはあったのになんで？うーん。

つづく（だんだん疲れてきた）。

(附記)そういえば、ビルド用にLANGをen_US.UTF-8にしていたなと思いだし、これをja_JP.UTF-8にして、./sugar-jhbuild run abiwordにscim-anthyで日本語入力できた（変換ウィンドウの位置は相変わらずおかしい）。なるほど。エミュレータじゃないんだから、親プロセスの環境を見ているということか。ちゃんと考えればあたりまえか。

とりあえずは、それなりの環境は整った、ということかな。

sugar-jhbuild (2)

sugar-jhbuildつづき（結論はありません）。

きのうはただやみくもにビルドしようとしていただけだったので、もう一回更地にして、やってみようとしたが、./sugar-jhbuild updateの段階でAvahiというコンポーネントのソースをwgetできない。ブラウザで見ても、avahi.orgのHTTPサーバーにつながらないので、なんらかの理由でサーバーが落ちているようだ。

あと、もうちょっとSugarのビルドについて勉強しようとサーチをかけたら、こんな親切なページが見つかった。

■ OLPC 開発その１。環境設定。

このページはFedora Core 6ベースだが、まぁ素人にはなかなか困難だということらしい。

さてどうするか。

(附記)avahi-0.6.20.tar.gzというファイルを落としたいらしいので、同じ名前のファイルをロシアのFreeBSDをミラーしてるサーバーから落としてきて、sourceディレクトリに入れてやったら、Avahiのビルドはできた。が、Sugarのビルドはやっぱり失敗する。Makefileの

sugar-xo.gtkrc: gtkrc.em
        $(srcdir)/em.py -D theme=\'sugar-xo\' $(srcdir)/gtkrc.em > \
                $(top_builddir)/data/sugar-xo.gtkrc
@INTLTOOL_XML_RULE@

install-data-hook:
        if [ -z "$$DESTDIR" ]; then \
                update-mime-database "$(datadir)/mime"; \
        fi

この@INTLTOOL_XML_RULE@が悪いんだけれど、正しくはどうあるべきなのか？うーん。

(附記2)どうもこの辺の話を理解しなきゃいけないようだな。

■　GNOME アプリケーションの国際化
　　3.3. Makefile の変更

(附記3)この@INTLTOOL_XML_RULE@というのはどうもsugar.xmlをつくるためのルールを定義するものらしいから、同じディレクトリにあるsugar.xml.inというのをただコピーしてやれば、とりあえずビルドは通るのではないかと思いつき、やってみた。案の定、そこの部分は無事通過したが、つぎは、

 make[1]: Leaving directory `/home/tami/jhbuild/sugar-jhbuild/source/sugar/po'
make[1]: Entering directory `/home/tami/jhbuild/sugar-jhbuild/source/sugar/po'
cd .. \
          && CONFIG_FILES=po/Makefile.in CONFIG_HEADERS= CONFIG_LINKS= \
               /bin/sh ./config.status
config.status: creating po/Makefile.in
config.status: executing depfiles commands
config.status: executing default-1 commands
make[1]: *** No rule to make target `@ALL_LINGUAS@.gmo', needed by `all-yes'.  Stop.
make[1]: Leaving directory `/home/tami/jhbuild/sugar-jhbuild/source/sugar/po'
make: *** [all-recursive] Error 1
*** error during stage build of sugar: ########## Error running make   *** [20/46]

だそうだ。これまたよくわからんが、poディレクトリのMakefile.inのALL_LINGUASをいじったり、aclocal.m4というファイルのAC_SUBST(ALL_LINGUAS)という行をコメントアウトしたりしたら（いいかげん）、いちおうビルドは通るようになった。よし。

で、./sugar-jhbuild runでSugarがめでたく走った。ブラウザやEtoysも快調。ただしワープロ(Writeアクティビティ）は動かず(怒)。

つづく（のかな？笑）。

sugar-jhbuild

またしてもとりとめのない 雑記。

よっしゃあ、Fedora 7も入ったし、OLPCのビルド環境を作るぜ！とおもい、このページを見てsugar-jhbuildしてみたが、sugarビルドが失敗しますよ？

*** Building sugar *** [20/46]

make 
Making all in bin
make[1]: Entering directory `/home/tami/sugar-jhbuild/sugar-jhbuild/source/sugar/bin'
make[1]: Nothing to be done for `all'.
make[1]: Leaving directory `/home/tami/sugar-jhbuild/sugar-jhbuild/source/sugar/bin'
Making all in data
make[1]: Entering directory `/home/tami/sugar-jhbuild/sugar-jhbuild/source/sugar/data'
Makefile:593: *** missing separator.  Stop.
make[1]: Leaving directory `/home/tami/sugar-jhbuild/sugar-jhbuild/source/sugar/data'
make: *** [all-recursive] Error 1
*** error during stage build of sugar: ########## Error running make   *** [20/46]

たしかにsource/sugar/dataにあるMakefileの593行目が変だが、どうやって直したらいいのかわからず。

うーん。とりあえず、今日はここまでか。

Huge Pine USB to UART Driver

パソコン道楽報告（とりとめのない内容です）。

このあいだ書いていたKVM Switchが届いたので、さっそく古いマシンにFedora 7を入れてみた。それで知ったのですが、Fedora 7はCD-ROMイメージがないんですね。DVDのみ。まぁそういう時代ですか。古いマシンにはDVD-ROMがついていないので、NC State UniversityのFTPサイトからネットワークインストールした。多少時間が掛かったものの、なにも問題なく完了。KVM Switchもじつに快適。これはもっと早く買うべきだったな。

Fedora 7は、もはや見かけはWindowsやMac OSと遜色ないくらいまでに洗練されていて、このあいだOLPCのイメージで試したIPAフォントやAnthyのかな漢字変換なんかを組み合わせれば、もう本当に市販のOSはいらないかなぁとおもう。まぁ、それでも市販ソフトが良くできている場合も多々あるのだけれど。

それはともかく、KVMを買うついでに、USB-シリアルの変換アダプタを買った。最近BETA-BRITEをシリアルポートにつけているので、無印eTrexをPCにつなげるためには、PC背面のシリアル端子をごそごそする必要があり、面倒になったからだ。じつは、この間eBayで激安のやつ（送料込みで＄１０ちょいくらいだったか？）を買ったが、うまく動かず、Amazonである程度評判が良さそうなこいつで再挑戦したのだった。

結果は…成功！だったけど、サウンドカードが鳴らなくなりましたよ！？
Device Managerを見ると、サウンドカード（SoundMAX Integrated Digital Audio)に黄色い”！”マークが付いていて、"Code 10"でデバイスがスタートできないというエラーが出ている。

USB-シリアルアダプタを入れる際にインストールされたドライバのなにかが悪さをしているのはまちがいないので、とりあえず"Add or Remove Programs"から、"Huge Pine USB to UART Driver"というのを除いてみて、リブートしたら、音がまた鳴るようになった。不思議なことには、それがなくても無印eTrexへのデータ転送はできたりする。よくわからんが、ひとまずはこれでいいことにしておこう。

Mac OS X Leopard

Mac OS X Leopard、10月26日発売決定。シングル・ユーザーライセンス$129.00。

iPod touchの件もあって、わたしのアップル熱はすっかり冷め切っていて、Steve Jobsにもう１セントも儲けさせたくないんだけれど、TigerをスキップしてしまってぼちぼちフリーウェアでもJaguarでは動かないものが増えてきたから、今回は降参して、eMacに入れることになりそう。

でも、Leopardはともかく、IT業界にいるものとして、そろそろ一台くらい家にWindows Vistaの入ったマシンがあってもいいかとも思う。OLPCを買うのは決めたけれど、ASUSのEee PCもいよいよ発売されるようだし、年末年始にかけて、コンピュータ関連の出費がかさみそうだ。

IOGEAR GCS62 MiniView Micro KVM Switch

よっしゃあ、自力でソースを直してワープロで変換途中の文字がちゃんとした位置に出るようにしてやる、かどうかはまだ覚悟ができていないが、OLPCを買うんだったら、うちのPCにFedora 7が入っているとなにかと便利なことがあるんじゃないか？とおもった。

いちばん簡単なのはいまつかってるDell Dimension 2400のパーティションを切り直して、Fedoraを入れるという案。しらべてみるとPartition LogicというPartition Magicと同じようなことができるフリーウェアもいまはある。

でも、メインのマシンを実験用に使い回しするのはもうやめたいなー（ぼくも大人になった。笑）。

ということで、Dimension 2400を買う前に使っていた、933MHz Pentium III (しかもSlot 1。笑）メモリ768MBといういかにも中途半端なマシンに入れることにした。でも、ディスプレイがないので、IOGEAR GCS62 MiniView Micro KVM Switchというスイッチで切り替えさせることに決定。＄２５。

面白くなってきた。

Somewhat broken Japanese input

OLPCのワープロで日本語変換したとき、変換途中の文字がへんな場所に表示される問題について（しつこい）。

OLPCのワープロが土台にしているAbiWordの問題じゃないかとおもって、Googleでサーチしてみたら、こんなのが見つかった。

● AbiWord-2.5.0 complex script testers please?
● Bug#:10756 Somewhat broken Japanese input

残された道は、自力でコードを修正することか（あきらめるか）。

OLPC (QEMU) + scim-anthy

性懲りもなくワープロでの変換文字の表示位置の問題を解決すべく、uim-anthyではなくて、scim-anthyで再挑戦してみた、が、ダメでした。ワープロの入力メソッドは"X Input Method"で動いたが、やっぱり左上に出る（uimのときとちょっと位置が違う）。"Embed Preedit String into client window"という設定オプションがあるのでいじってみたが、結果は変わらず。よく見たら、この中国語の例も、左上に出てるし（uimのときと同じ位置）。うーん。ワープロ側の問題かなぁ。

leafpadという簡単なテキストエディタだとちゃんと"On The Spot"変換するので、テキスト入力はそいつを使うことにして、本当にワープロが必要なときだけ使うということにするか（本当に必要なときはWindowsでMS Wordを使うだろう。笑）。

一応自分の覚えがきとして設定方法を簡単にまとめておこう。

0. /etc/X11/xorg.conf 変更。
1. Ctrl-Alt-3
2. login as root
3. yum intall scim-anthy
4. IPAフォントインストール(/usr/share/fontsにttfをコピー）
5. /home/olpc/.xinitrc のsugerを呼ぶ前に、

LANG=ja_JP.UTF-8 ; export LANG
scim -d &
XMODIFIERS=@im=SCIM ; export XMODIFIERS
GTK_IM_MODULE=scim ; export GTK_IM_MODULE
USE_XOPENIM=t ; export USE_XOPENIM

の行を追加（参照ページ）。

6. chown olpc:olpc .xinitrc
7. killall -i X

Google Earth on OLPC (QEMU)

日本語はこれでとりあえずいいとして、じゃあつぎはOLPCでGoogle Earthだ！ということで試してみた。

インストールは、落ちてきた.binファイルをchmodしても動かすことができず、/bin/shのパラメータで渡してやるとなぜかうまくいった。

で、動かしてやると、libGL.so.1がないとか言ってくるので、mesa-libGLというのをyum installで入れてやったら、Google Earthのロゴが出て、喜んだものつかの間、Xがリスタート（したみたい）。

マシンの能力的にこれは無理そうなので、Google Mapsでがまんするとするか。というか、そういうときは素直にWindowsのラップトップを使えばいいのだ（笑）。

OLPC (QEMU) + uim-anthy

うーん、どうも変換途中の文字が表示される位置が変だ。でもとりあえずuim-anthyでOLPCのワープロに日本語を入力することができそうだぞ。

自分以外だれの役に立つのかわからないが、手順は、

1. Ctrl-Alt-3でコンソールを出して、rootでログイン（デフォルトはパスワードなし！）。

2. yum install uim-anthy uim-gtk2
　　で、uim, anthy, uim-anthy, uim-gtk2をインストール。ブラウザの日本語入力だけなら、uim-gtk2はいらないみたい。ワープロはuim-gtk2を入れずに"X Input Method"で入力しようとすると固まった（原因不明）。

3. cd /home/olpc

4. vi .xinitrc
Ctrl-Alt-3のコンソールでviの画面が崩れるのだが、他のエディタは知らないし…

5. .xinitrcの終わりあたり、sugarを呼ぶ直前に、

LANG=ja_JP.UTF-8 ; export LANG
GTK_IM_MODULE=uim ; export GTK_IM_MODULE
uim-xim &
XMODIFIERS=@im=uim ; export XMODIFIERS

を入れて、セーブ。

5. chown olpc:olpc .xinitrc

6. killall -i X

です。

OLPC in Japanese (QEMU)

OLPCの日本語表示のつづき。

なんかフリーの日本語アウトラインフォント「IPAフォント」の一般公開が始まったということなので、このOLPC in Chineseの手順にしたがえば、たぶんそれをダウンロードして、/usr/share/fontsにコピーしてやれば日本語が出るのではないかと思い、QEMUエミュレーター環境でためしてみた。

WindowsへのQEMUのインストール、OLPCイメージの動かし方はここに書いてある通り。デフォルトだとフォントが小さくなりすぎるので、ここにある変更を/etc/X11/xorg.confに加えました。使ったイメージは安定版ではなくて最新版の10/4ビルド。ただあたらしい方がいいかとおもっただけで、特に意味はないです。

マシン（セレロン2.4G 1Gメモリ）が遅いのか、QEMUが遅いのか、もともとOLPCが遅いのかよくわからないが、ブラウザの表示はやたら遅い。でも、簡単に日本語は出た。ただし、フォントサイズの調節方法はわからず（笑）。Ctrl-+とかやったがだめ。まぁ、そういうのはそのうちやりかたがわかるのであろう。うんうん。

つぎは日本語入力か。ここ５年ほどまじめにLinuxで日本語入力していないが、ちょっと調べたところ、uim-anthyあたりを使うのが今風らしい。たぶんFedora 7用のRPMがそのまま使えるんじゃないかと思えるから、また試してみるとしよう。

OLPC Review Video

Engadget経由。New York Timesのサイトに載った、OLPCをレビューするビデオ。見れば見るほど欲しくなる。

CPUやグラフィックスのパワーではあきらかに上回るPS3が売り上げでWiiに完全に負けているいま、ラップトップの分野でも、もう必要なのはスペックではなくて、ハード・ソフトをひっくるめた優れたパッケージなのではないかとおもう。

OLPC in Japanese

まだ気が早いが、OLPCを年末までに手に入れることができたとして、やっぱり日本語を表示させたいものである。OLPCはLinuxベースだから、日本語表示くらい簡単にできそうだけれど、どんな感じに見えるのか知りたいと思い、サーチしたら、日本語は見つからなかったが中国語表示の情報が見つかった。

スクリーンショットを見る限りでは、かなり期待できそう。よしよし。

Paint.NET

日ごろ写真のレタッチにはPhotoshop Elements 4を使っていて、大きな不満はないのだけれど、立ち上げに少し時間が掛かるので、もう少し軽いフリーのレタッチソフトがないものかと思い、Paint.NETというのを試してみた。

.NET Frameworkを使っているせいか、素晴らしく軽快、というわけではないが、立ち上がりなんかは、Photoshop Elements 4よりはずっと速い。機能的にも充実（アンシャープマスクがないのは残念）。でも、フィルタ類がやたらと遅い。そういえばGIMPを以前試したときも（最新版は知らないが）、フィルタが遅かった。Gaussian Blurをやると、Photoshop Elements 4なら瞬時に処理が終わるのに、Paint.NETではステータス・バーを出しながら、ちんたら処理をしている。その上、半径を大きくすればするほど、待ち時間は飛躍的に長くなる。駄目だ、これでは使えない。

やっぱりこういうところのパフォーマンスの最適化は、フリーソフトに期待するのが（まだ）無理ってことなのかなぁ。