たかちゃん。

8月 122014
 

以前のエントリで SkyDrive に FreeBSD からネーテブアプリでアクセスしようぜぃ。ってのを二つ書きました。以下のエントリになるんですけども。

SkyDrive を FreeBSD に mount して使う。
SkyDrive を FreeBSD に mount して使う。そのに。

当時はまだ OneDrive ではなく SkyDrive と言っていたんですね。

そもそも、 FreeBSD から直接 OneDrive に(ネーテブなアプリで)アクセスすることは不可能で、中間的サービスを利用することになります。そのサービスは Storage Made Easy (以下 SME と記述)と、いうものです。

ここでアカウントを作成して、無料のサービスを利用すると SME のストレージサービスが利用できる他に、色々なクラウドストレージサービスプロバイダも合わせて利用できる。ってシロモノです。
簡単にいうと SME のサービスはプロキシみたいな感じで OneDrive とか Box 、 更には DropBox などにもアクセスできるようになります。

これは是非ともアカウントを一個くらいは作っておきたいですねぇ;-)。

SME のサービスはマルチプラットホーム対応で色々な OS 用のアプリがあり、スマートフォン・PC・Mac や Linux からもアクセスできます。 Linux 用はソースコードまで公開していて、そのソースコードを FreeBSD 上でコンパイルすると、 FreeBSD のネーテブアプリから OneDrive や DropBox にアクセスできる。と、いうすごいことになるんですねぇ。

以下の Lunix 用アプリについて書かれている URL です。

http://storagemadeeasy.com/LinuxDrive/

ここから CentOS の rpm をダウンロードして make してしまう ports を作ってみました。上にあるエントリでは随分と古い話でしたが、最近のソースコードは随分と美しくなり、起動するアプリケーションも直感的になりました。

 
話はガラっと変わるのですが、 Windows8.1 の場合、 OneDrive にアクセスするときには Windows Live アカウントでないとアクセスできない(ローカルアカウントでログインしている場合には一旦切り替えなければならない)ので非常に厄介です。

その場合、SME の Windows 版アプリをダウンロードして来て Windows8.1 の場合にはそれを利用するとローカルユーザーでも OneDrive にアクセスできるようになります。うひひ;-)。

Windows8.1 な人も是非利用してみてください。

 
さてさて。話を戻して、上記 URL より SentOS の storagemadeeasy-4.1-0.noarch.rpm をダウンロードしてサクっとインストールする ports を書いてみたのでもしよければ利用してみてください。

以下に ports の仕様を書いてみたいと思います。ダサいところが多々残っているんですが、僕には ports の書き方が判りませんでした・・。orz

あ。 ports は当然ながらノラ ports です。これがちゃんと ports のルールに従えられれば、前回のノラ ports である QtWeb とこれは commit してメンテナになってもも良いかなぁ。などと思っているんですけどもねぇ・・。

以下の URL にノラ ports はあります。ダウンロードしたら /usr/ports/net/ に展開して頂ければと思います。

http://icmpv6.org/Prog/FreeBSD_ports/ports-storagemadeeasy-20140812.tgz

ports の仕様は以下のような感じ。まぁ、Makefile を見て頂ければ解ると思いますf(^^;;。

1).ダウンロードはちょっと違うファイル名
https://storagemadeeasy.com/files/ から 380f74d2fcd051b21a64858ecb3f0923.rpm と言うファイルをダウンロードしてきます。

2). post-patch はダサいねぇ・・
${WRKDIR}/usr/share/sme_install/*/* のディレクトリのパスを変更します。 それにしてもダサいのが、僕は SED マクロが書けませんでした。 find して xargs から perl -e で置き換えています。ここはもっちっと改修する必要が絶対にあります。

3). コンパイル
SME のアプリは Qt4 を利用しているので qmake-qt4 実行後に make します。 LIB_DEPENDS や USE_ は多分全てを読み込んでいて、モレはないと思います。

4). インストール
SME のアプリの make は make install が無いので ports の中で吸収する必要があります。PLIST_FILES に書かれたものがインストールされます。
が、しかし、これだけでは足りないんですよねぇ・・。 pkg-plist の書き方が解らなかったので pkg-message にイントール後にもう一個インストールするようにコマンドイメージを書いておきました。
ports の中に smeclient.tgz を同梱しているのですが、これは ${WRKDIR}/usr/share/smeclient/ ディレクトリのアーカイブになります。
なので tar でなくとも、以下のコマンドでも十分に OK なんですね。

# cp -pr work/usr/share/smeclient /usr/local/share/

 
以上が ports の仕様です。随分とダサいところ満載ですねぇ・・。書き方が解らない部分が多いんですよねぇ・・。この間作った QtWeb の ports のほうがまだ楽ちんでしたf(^^;;。

 
と、いうことで、インストールされたあとは /usr/local/bin/smeexplorer を起動してアクセスすれば色々なクラウド上のファイルの閲覧が可能になります。

SME のサービス自体が中々良い感じなのでそれが FreeBSD 上からウェブブラウザ経由ではなく、ネーテブアプリからアクセスできる。と、いうのが良いのであります。

あ。今回はキャプチャはありません;-)。

ただ、 SME のアカウントを作成しなければならない。と、いうのが煩わしいとは思うのですが、iOS や Android 、 Windows などと同じレベルで FreeBSD からもするーっとクラウドストレージへのアクセスが可能になるので、これはこれで利用すると非常に嬉しいですねぇ;-)。

 
皆さんも是非利用してください。とは言いませんが、あ。そーそー。最後にですが、当該 ports を ports のルールに乗っ取ったものに改修してくださる方絶賛募集中です。どうか宜しくお願いします。

 
2014/09/05 加筆
ちゃんと一発で make install と make deinstall できるように ports を更新しました。
改修点は以下になります。

・post-patch: の部分で perl で一括置き換えしていたものを REINPLACE_CMD を使うようにした
・最後に tar でインストールしようとしていたたくさんのファイルを do-install: で行うようにした

が主な改修点です。これで多分完璧;-)。

以下の URL にあるのでよかったら利用してください。

http://icmpv6.org/Prog/FreeBSD_ports/ports-storagemadeeasy-20140905.tgz

7月 232014
 

さくらの VPS を契約して一年が経ちました。で、ちょうどさくらインターネットから「契約更新するなら何もしなくて良いよ。」メールが届いたのですかさず解約してしまいました。

大阪リージョンはちょっと不憫だぁ・・。

・IPv6 無いしぃー。
・最近、僕の仮想マシンが載っている環境がやたらと遅いしぃー。

ってことで IPv6 は確か 07/20 に大阪リージョンも対応してくれるんだっけかな? なのでもう少し待っていればよかったんだろうけど、契約の更新時期と重なったし・・。

仮想マシンがやたらと遅いのは HDD と CPU がどうも遅い。例えば apache22 を worker で起動していても反応が(ブラウザでの表示)が遅い。まぁ、 WrodPress なので php と MySQL の影響もあるんだろうけど・・。

と、いうことで今回のエントリはさくらの VPS について、大阪リージョンを解約して石狩リージョンを別途契約したときの顛末を書いてみたいと思います。

 
1). 回線速度について
さくらインターネットのバックボーンについては以下の URL が参考になるかと思われます。

国内最大級の大容量バックボーン

これを見ると石狩より大阪のほうがネットワーク的には恵まれているかなぁ。と、いう感じはします。JPIX 東京で接続している ISP などの場合、大阪に行くパケットは大阪からではなく、東京から流れることになるので東京・大阪・石狩で、ネットワーク的にどこが一番良いか? となると、多分東京が一番良いような気がします。

ちなみに JPIX 東京に接続している某 ISP から色々調べてみましたが、石狩よりも大阪のほうがネットワーク的には早かったです。とわ言ってもその違いは 10ms 程度でしか無いんですけどね;-)。

 
2). サーバについて
と、いうことで石狩にサーバを作ってみました。こっちは速いですねぇ。って、それはそーですよね。このあと、バシバシ他の新規契約サーバが載ってくるんだから作った当初は随分と早く感じるはず;-)。

ちなみに今回作成したサーバは FreeBSD/amd64 9.2-RELEASE です。さくらの VPN でサポートされるようになったようなのでインストールしました。virtio や vtnet が利用できるのでカスタムカーネルを作る必要はありません。

ただ、インストール後、インストールが無事に終了して再起動したときに CD ブートしてしまうのには困りました。インストール完了後は再起動せずに電源断しないと CD がアンマウントしないしようになっているのですね。仕様のようです。なので、インストール後はきっちりとパワーオフしましょう;-)。

 
3). サーバの移設
大阪で動作しているサーバの情報を新しく動作した石狩のサーバに持っていきます。僕の場合は rsync で持って行きました。比較的早くデータの移設が完了します。

大阪の apache は apache22 で石狩の apache は apache24 にしたので、その点がちょっとややこしかったかな。 FreeBSD の ports-current は default が apache22 から apache24 に変わったので今回のタイミングがちょうど良くてバージョンを上げました;-)。

大阪 – 石狩 の間はさくらインターネット網内を抜けていくことになるので外部に出ません。ただ、大阪 – 石狩間ってのはネットワーク的にあまり早くないですね。
ってのは僕の気のせいかもしれません・・。石狩での二週間のお試し期間中にデータ転送するとむちゃくちゃ遅い 200kbps 程度しか出てなかった記憶があるのですが、本契約したらサクッと速度が出ますねぇ(@_o)。
お試し期間中にデータの移動をする方はご注意ください;-)。

 
4). DNS の移設
これが一番面倒でしたね。
僕はさくらの VPS 上で DNS のプライマリサーバを起動していて、さくらインターネットにセカンダリを持ってもらっています。
大阪から石狩にサーバを移動したとき、さくらインターネットで持ってもらっているドメインの情報は一旦削除して、ゾーンファイルの NS RR から削除して、whois から削除して、再登録しなければなりません。以下にその手順の詳細を書きます。

まずは構成図から。

sakura_vps_DNS

o.右側の二つの DNS: ns[12].dns.ne.jp はさくらインターネットの DNS でセカンダリ DNS を担当してもらっています。
o.左側の DNS はさくらの VPS 上に起動した DNS で FQDN は dns.icmpv6.org になります。

icmpv6.org のゾーンファイルの NS レコードは以下のようになっています。

        IN      NS      dns.icmpv6.org.
        IN      NS      ns1.dns.ne.jp.
        IN      NS      ns2.dns.ne.jp.

 

whois に登録してある DNS の設定も上記のようになっています。

さくらの VPS のコントールパネルから 会員メニュー > ドメイン > ゾーンの追加 では DNS の登録時にセカンダリを持ってもらうように設定しています。さくらインターネットから見えるプライマリ DNS は大阪のアドレスになっています。

この設定を新しく設置した石狩のサーバの IP アドレスに変更しようとしても受け付けてくれません。サポートに連絡したところ以下の URL を教えてもらいました。

http://sakura.custhelp.com/app/answers/detail/a_id/1451

さくらの VPS のリージョンを変更してサーバを引っ越しする場合 DNS が一番面倒だったりします。

1. ゾーンファイルの NS RR から ns[12].dns.ne.jp を削除
2. whois の DNS の設定に ns[12].dns.ne.jp が書かれていればそれも削除

上記の二点の作業後でないと DNS の登録を受け付けてくれません。僕が試したときには何回か色々なエラーメッセージが出たのですが、以下のエラーメッセージが表示されるときにはにっちもさっちも行かない状態になっていることになります。

エラーです(1)

登録することができませんでした。このゾーンまたは上位のゾーンが利用中です。(D5-01)

 
D5-01 なコードはぐぐってもサポートサイト検索しても出てこないんですけど・・。orz

と、いうことで上の二点を実施し、 ns[12].dns.ne.jp がどこにも書かれていない状態にしてから再度「ネームサーバ新規登録」の画面に進む必要があります。

さくらインターネットに対してネームサーバの登録が完了したら、登録のために設定した情報をもとに戻しても構いません。

1. NS RR に ns[12].dns.ne.jp を追加
2. whois の DNS の設定に ns[12].dns.ne.jp を追加

さっきと逆の作業を実施します。

あ。whois は DNS が二つないと登録できないので、一個しか無いときに辛いかも・・。僕の場合は自宅サーバがセカンダリの機能を持ちましたが。ふぅ。

 
と、いうことでふぅ。 DNS の登録も無事に完了しました。
サーバのデータの移動も完了して apache22 から apache24 への変更(各種設定や Require all granted への変更などの)作業もなんとか無事に完了しました(多分)。

これで、icmpv6.org と motsuyaki.org は多少早くなったのではないかと思われます。が、今後どんどん石狩も売れていくとまた重くなっていくんだろうなぁ・・。

まぁ、一番安いの契約しているのでしょーがないかf(^^;;。

7月 102014
 

X11 で利用するためのターミナルソフトというのは /usr/ports/ の下を探すと色々あるんですけども、僕なんかは KDE4 を利用していて『konsole あるじゃん。』となるんですが、どーも konsole は使いにくい。その中で色々と試して自分に良い感じのモノを利用したいモノです。

過去にもこのブログでは gtkterm2 のエントリを書いたりもしましたが、今回はそれに続く第二弾。と、いう感じでしょうかねぇ。

今回取り上げるのは xfce4-terminal です。 ports 的には x11/xfce4-terminal/ になります。もともとはウィンドマネージャである xfce4 (ports 的には x11-wm/xfce4)のターミナルソフトとしての役割があるのですが KDE4 を利用している場合においても x11/xfce4-terminal を make install することはできます。

xfce4 本体は利用せずともターミナルだけをインストールすると以下と、それに関連するプログラムがインストールされます。

libxfce4menu-4.10.0
libxfce4util-4.10.1
xfce4-conf-4.10.0
xfce4-terminal-0.6.3

まぁ、これくらいなら許せるかねぇ。って気がしないでもないので僕は使い続けているんですけどもね;-)。

で、xfce4-terminal のインストールが無事に完了し KDE4 で起動するとこんな感じになります。あ。上部のメニューの部分だけのキャプチャです。

xfce4-terminal_1

xfce4 をウィンドマネージャとして利用していると、ツールバーは 文字・アイコン・両方が選択できるのですが、 KDE4 上で利用するとその選択ができずに”両方”しか選択の余地が無いんですね。ちなみに xfce4 でウィンド装飾を設定するには xfce4-appearance-settings というプログラムを利用します。 ports 的には sysutils/xfce4-settings に含まれているのでいつを追加でインストールし xfce4-appearance-settings を起動してツールバーを”アイコンのみ”にしても KDE4 上で起動した場合には”両方”でしか表示できないんですね。

で、しばらくはツールバー無しで利用していたのですが、せっかくある機能、使わずしてどうする?などと、ザラ議長のような発想になってしまい、あちこち調べて格闘してみた。と、いうネタが今回のエントリーです;-)。

 
ウィンドマネージャである xfce4 の各種設定情報は $HOME/.config/xfce4/ に色々保存されます。ウィンド装飾の設定は $HOME/.config/xfce4/xfconf/xfce-perchannel-xml/xsettings.xml というファイルに保存されますが xfce4-terminal を単体で起動した場合にはこの設定ファイルを読み込まずにそのまま起動してしまうようです。 xfce4 のセッションを管理している何かしらの管理デーモンが画面全体を制御しているのでしょうなぁ。

では、 xfce4-terminal のソースを書きなおして default が BOTH なのを ICON に変えれば良いじゃないか。とか思い、ソースコードを見たのですが、うーむ。この辺りは GTK2 が管理しているようで GTK2 について詳しくない僕にとっては中々手強いのでありましたf(^^;;。

と、いうことで色々調べた結果、 KDE4 利用時に xfce4-terminal を起動しても無事にアイコンのみを表示できるようになりました。

xfce4-terminal_2

xfce4-terminal と xfce4-appearance-settings を同時に起動しました。

 
xfce4 は設定情報を全て管理していて、 xfce4 のアプリが起動したときに保存してある設定情報をアプリに渡すためのデーモンが存在しているようです。 KDE4 から xfce4-terminal を起動した場合、そのデーモンが起動していないために設定情報を xfce4-terminal に渡すことができなくて xfce4-terminal は default の設定で起動するんですね。

なるほど。では xfce4 の設定情報を渡すためデーモンを KDE4 利用時に起動して上げれば良いんだ。と、いうことになります。ちなみにそのデーモンは xfsettingsd というプログラムで sysutils/xfce4-settings に含まれています。

KDE4 でログイン後に xfsettingsd を起動してあげると xfce4 の各種設定が利用できるようになります。

まぁ、余計だとか CPU の無駄遣いとかイロイロあるとは思うのですが、最近はマシンパワーも余っていることですし、見てくれやツールバーの機能も重要なので今回はこれでヨシとしましょう。

あ。ツールバーが表示されたんだけど、「新規タブ」と「新規窓」のアイコンが表示されません。追加で x11-themes/icons-tango などをインストールしてあげてください。

これであなた好みのツールバーアイコンが利用できるようになるとか思われます。

ちなみに僕は非力なマシンとか仮想環境で X が必要なマシンでは KDE4 ではなく xfce4 を利用しています。機能的にも十分だし軽量なので重宝しております;-)。

 
さてさて。これだけではなんなんで、一個パッチを公開します。

xfce4-terminal ってのはショートカットとかキーバインドなどはソースにハードコーディングしているので変更できないんですね。
一番困ったのがタブの移動で default では Ctrl+Page_Up とか Ctrl+Page_Down なので不便でしょーがない。僕はタブの移動は Shift+Left もしくは Shift+Right にしているので、その部分を変更するパッチになります。

http://icmpv6.org/Prog/FreeBSD_ports/patch-terminal-terminal-window.c

自分のキーバインドにしたい場合には terminal/terminal-window.c の 210 行辺りを変更すれば良いと思います。
上記パッチは files/ の中にほーりこんで make すれば大丈夫なようにしています。

 
と、いうことで今回は xfce4-terminal について書いてみました。皆さんも機会があったら試してみてくださいー;-)。

6月 242014
 

今回は IPv4 のお話ではなく IPv6 のお話です。でもって Path MTU Discovery のお話です。

僕は IPv6 は Hurricane Electric の IPv6 Tunnel Broker を利用しています。以前からここの IPv6 トンネルを利用させてもらっているのですが、とあるタイミングで IPv6 の http や ftp が通らなくなりました。あらま。 ping や ssh は通るので、仕事柄の経験上「あぁ。 Path MTU Discovery にハマったな。」というのはすぐに解りました。

『ハマった』というのは『送受信の二点間において MTU の最小値を決定することができなかった。』と、いうことかな。
どうして『決定できなかった』のかと言えば『Path MTU を探査できなかったから。』と、いうことになると思います。
Path MTU が Discovery できないとパケットのフラグメントが発生しないので MTU サイズ以降のパケットは捨てられてしまうために通信が行えなくなります。

 
しかし、Hurricane Electric の IPv6 トンネルは今まで利用できていたのにどうしてある日突然 Path MTU Discovery ができなくなってパケットサイズの大きい通信が止まるのだぁ? などと不思議に思うのであります。

まず、どうして Path MTU Discovery に失敗するのか?

1). 自分が設定したファイアーウォールで ICMPv6 の Type2 (Packet Too Big)を止めてしまった
2). ISP がある日突然 ICMPv6 の Type2 に ACL をかけた
3). Hurricane Electric で仕様が変わった

が考えられると思います。 1). については自分が設定したファイアーウォールを flush して確認できると思います。
2). の場合、僕は ISP を二つ契約している(自宅でマルチホームっ!!;-)ので両方の ISP で Hurricane Electric のサービスにトンネルを掘って確認してみましたが、どちらも http が止まります。
すると、残りは 3). が原因か、もしかして 2). の二つの ISP の両方が ICMPv6 Type2 に ACL を設定しているか。ですね。

まぁ、どっちにしても通信はできません。orz

 
次に、本当に IPv6 Path MTU Discovery ができていないのかの確認方法です。

1). IPv4 は ping・ssh・http の通信ができることを確認
2). IPv6 で ping・ssh・http の通信ができることを確認
3). ping6 -s 1434 au.kddi.com もしくは ping -s 1280 au.kddi.com

1). の確認において IPv4 で上記プロトコルが全て利用できるようであれば、問題は IPv6 のみに特定できます。
2). では Path MTU Discovery にハマると http の通信のみできなくなります。まぁ、ftp ででかいデータを持ってくるときとか、パケットサイズが 1,500 バイトに近くなる通信では止まってしまいます。
3). は、じゃぁ実際に何バイトのバケットサイズであれば通るのだ?という確認のために ping でパケットサイズを指定します。 1,434 もしくは 1,280 バイトで ping してみて、通る、通らないでサイズを変更して色々確認してみるのが良いかと思われます。

さてさて。これらで確認することにより IPv6 Path MTU Discovery な地雷を踏んだか確認できますが、次にその対応について考えてみたいと思います。

 
まずはネットワーク構成図などを。

Tunnel_NetWork_01

真ん中の黄色いのがトンネルルータで Hurricane Electric に対して gif0 でトンネルを掘っております。 em0 のインターフェースは一個目の IPv6 セグメントです。
また、トンネルルータでは dtcps を起動していて gif10 と gif10 で更に二つのセグメントとトンネルを掘っております。

このネットワークでの IPv6 Path MTU Discovery の状態は・・。

1). 同一セグメント内では通信ができる
2). セグメント 1,2,3 の間ではで通信ができる
3). セグメント 1,2,3 から gif0 を抜けて Hurricane Electric の先にある IPv6 サイトと通信ができない

と、いうことが解りました。 どうやら MTU もしくは MSS の調整は re0 か gif0 で行う必要がありそうです。

 
が、その前に、クライアント PC 側で何か対応する手立ては無いか調べてみました。

1). クライアント PC の MTU を 1434 にする
2). IPv6 より IPv4 を先に利用するようにする

1). の場合は UNIX 系 OS だと比較的容易にできます。以下は FreeBSD で MTU を変更する場合のコマンドです。

# ifconfig re0 mtu 1434

 
IPv6 Path MTU Discovery でハマった時には MTU を1434 にしてあげると通信が復活します。セグメント内にいる全ての UNIX 系 OS で上記コマンドを叩く必要があります。

2). のほうは WindowsOS で有効な手段です。 DOS のプロンプトをアドミン権限で起動し、以下のコマンドを打ちます。

c:\ netsh interface ipv6 show prefixpolicies
c:\
c:\ netsh interface ipv6 set prefixpolicy ::ffff:0:0/96 50 0
c:\ netsh interface ipv6 set prefixpolicy ::1/128 40 1
c:\ netsh interface ipv6 set prefixpolicy ::/0 30 2
c:\ netsh interface ipv6 set prefixpolicy 2002::/16 20 3
c:\ netsh interface ipv6 set prefixpolicy ::/96 10 4

 

一行目のコマンドはステータスの確認です。これを見ると IPv6 のほうが先に利用されるように設定されているので IPv4 を先に利用するようにその後のコマンドでプライオリティを変更してあけます。

もとに戻すときにはこちらのコマンドで。

c:\ netsh interface ipv6 set prefixpolicy ::1/128 50 0
c:\ netsh interface ipv6 set prefixpolicy ::/0 40 1
c:\ netsh interface ipv6 set prefixpolicy ::ffff:0:0/96 35 4
c:\ netsh interface ipv6 set prefixpolicy 2002::/16 30 2
c:\ netsh interface ipv6 set prefixpolicy ::/96 1 3

 

これで WindowsOS もなんとか IPv6 Path MTU Discovery を回避できたのではないかと思われます。ちょっと弱い問題解決ですが・・。

しかし、IPv6 に対応しているスマートフォン(iOS や Windows Phone OS など)は IPv6 サイトが見られないんですよねぇ・・。

さてさて。こんなことばっかりしていても根本的な問題解決にならないので次に根本的な解決をしてみたいと思います。

 
IPv6 Path MTU Discovery ができないときの原因としては ICMPv6 の Type2 (Packet Too Big) パケットのやりとりができず、通信するための最小 MTU サイズが特定できないために発生します。それならばパケットを送信する側でパケットの最小サイズを明示的に指定して送信すれば良い(それはつまりは TCP SYN パケットの MSS オプション値を書き換えてあげる。と、いうことです)わけなんですけども FreeBSD にその機能があるのか?

今回利用しているトンネルルータは FreeBSD 9.1-RELEASE です。こいつには pf(4) があるのでそれを利用することにします。と、いうか、現状では pf(4) でしか制御できないようです。
他にもports に net/tcpmssd があるようなのですが、今回は pf(4) を利用することにします。

ちなみにトンネルルータのファイアーウォールは ipfw で設定しているのですが MSS のサイズは pf で設定することにします。
今回は ipfw の設定は省きます。以下は /etc/pf.conf の設定です。

scrub in  on re0  from any to any max-mss 1280
scrub out on re0  from any to any max-mss 1280
scrub in  on gif0 from any to any max-mss 1280
scrub out on gif0 from any to any max-mss 1280
pass all

 
FreeBSD の MSS サイズを固定に設定するためには max-mss を利用します。サイズは 1280 にします。上記構成図では re0 から抜けるパケットのみが 1,280 バイトになります。通常 IPv4 パケットは別の BB ルータから抜けていく(構成図には書かれていない)のでまぁ、問題は無いでしょ。

re0 と gif0 の両方の MSS サイズを小さくしている設定をしていますが、試した結果 gif0 のみの MSS を1280 に設定するだけで十分でした。

設定が完了したら以下のコマンドを打ちます。

# kldload pf
# kldload pflog
# kldstat
        :
33    2 0xffffffff8104b000 2a4a5    pf.ko
34    1 0xffffffff81076000 9c9      pflog.ko
#
# /etc/rc.d/pf onestart
# pfctl -sr
        :
# pfctl -sa
        :
#

 
カーネルモジュールをロードし、無事にロードできたか確認します。次に /etc/rc.d/pf を onestart で実行します。無事に実行できたかは pfctl の二行で確認(オプション -sr と -sa)しましょう。出力結果は省略します;-)。
無事に動作することができたら /etc/rc.conf などに pf_enable=”YES” などと書きましょう。

 
最後に確認方法ですが、簡単です;-)。セグメント 1,2,3 の各クライアント PC から IPv6 サイトが無事に見えるかどうか。だけです;-)。

au.kddi.com とか running-dog.net とか icmpv6.org などが無事に見えると pf で設定した max-mss 1280 が有効になっている。と、いうことですね。

 
とまぁ、ある日突然 IPv6 Path MTU Discovery が通信できない問題が降ってきたわけですけども、その対応策などをツラツラと書いてみました。皆さん、是非とも IPv6 Path MTU Discovery にハマらないようにしたいと思うわけですけども、もしハマったら pf で回避してみてください。

ふぅ。それにしても復活だぁ・・。

6月 192014
 

GNOME 方面の人にはまるで興味が無いとは思うのですが、 KDE というか Qt を利用している人にとっては、ご存知な方もいるのではないかなぁ?

世の中には超軽量ブラウザというのが存在しています。 rekonq も konqueror に比べると軽量かなぁ。arora も軽量ですね。 rekonq よりも軽量なのが QtWeb というブラウザです。 arora と同じくらい軽量かなぁ。

以下が QtWeb のサイトですね。

http://qtweb.net/

ここを見ると Windows・OS X・Linux と世界の三大ウィンドを制覇しているんですけどもね;-)。で、それぞれバイナリがあるのですが、ソースコードもあるので、それを FreeBSD に持ってきてコンパイルすると FreeBSD 上でも動作するんですけども。

キャプチャはこんな感じです。

Qtweb_1

で、せっかくなので今回は QtWeb の ports を作ってみました。 arora が ports になっているのに QtWeb が ports になってないのは悲しいことですし;-)。
以下の URL にあるのでもしも「僕も私もちょっと FreeBSD 上で QtWeb を使ってみようかなぁ。」などと思った人は試してみてください。

http://icmpv6.org/Prog/FreeBSD_ports/ports-qtweb-20140619.tgz

あ。コミットするつもりはありません。あくまでノラ ports ということで;-)。

QtWeb の ports の仕様やインストール方法などをちょっと書いてみます。

o. QtWeb をコンパイルするには Qt 4.8.6 のソースコードが必要
FreeBSD の ports 的には qt4-* で色々インストールされているのですが、 QtWeb は Qt ライブラリを static link するので FreeBSD の ports 的な Qt ライブラリは必要としません。
GNOME や xfce4 な人も Qt や KDE のコンポーネントをインストールすることなく Qt コテコテなブラウザを楽しむことがてできます。

しかし、裏を返すと Qt ライブラリ部分もコンパイルするのでコンパイル時間が随分と長いです。orz

僕が作成した ports では /usr/ports/distfiles/KDE/ に Qt 4.8.6 のソースがあればそれを利用し、なければとある日本のサイトからダウンロードしてきます。詳細は files/patch-qt-src.sh を見てください。

o. ports がインストールするもの
QtWeb のサイトからバイナリをダウンロードすると、本当に QtWeb 本体のみしかパッケージングされてないのですが、僕の作った ports では QtWeb バイナリの他に icon として QtWeb.png と QtWeb.desktop をインストールするようにしています。インストール直後から KDE のインターネットメニューに表示されるようにしました。

o. QtWeb の起動
ports からインストールすると /usr/local/bin/QtWeb ができるのでそれを実行するのですが、実行後にできるディレクトリが美しくないです。以下の三つのディレクトリができます。

・$HOME/.QtWeb Internet Browser/
・QtWebCache/
・QtWebSettings/

一番上の .QtWeb Internet Browser/ は $HOME にできるので良いのですが、 QtWebCache/ と QtWebSettings/ はどこにできるかわかりません。実行したときにいるカレントディレクトリにできたりとか、ヘタするとあちこちに QtWebCache/ と QtWebSettings/ ができてしまうような感じです。orz
なお、メニューから QtWeb の設定を変更するとその内容は QtWebSettings/ に保存されます。

が、しかし、それにしてもこの二つのファイルはどこにできるのか解らない・・。orz
ソースコードを書き換えてやろうかと思ったほどですが・・。
なのでしょうがない。起動用にスクリプトを一個書きました。

#!/bin/sh

cd $HOME/.QtWeb\ Internet\ Browser
QtWeb > /dev/null 2>&1
#/usr/local/bin/QtWeb > /dev/null 2>&1
#cd  $HOME

 
$HOME/.QtWeb Internet Browser/ 配下に QtWebCache/ と QtWebSettings/ が作成されるようにするためのスクリプトです。
不便やのぉ・・。って感じなのですが、ソースコード的には browserapplication.cpp の数カ所を直せばちゃんとコントロールできるんじゃね? って感じはします。

 
こんな感じの QtWeb というブラウザなのですが、もしよければ皆さんもコンパイルして使ってみてください;-)。

 
あ。最後にですが、 Qt-Webkit は x-sjis と x-euc-jp には対応してないので文字化けします。 rekonq も konqueror も Qt-WebKit を利用しているのでやはり x-* な文字コードは表示できません。最近は少なくなってきましたが、今では僕が知っている有名ドコロは VECTOR が x-sjis を利用しているので表示できません。

この件については以前 KDE 方面で(その昔は) Nokia の Qt のコードを書いている人に聞いたことがあるのですが、非対応だそうです。するっていと同じ KHTML から派生の Apple-WebKit は独自に x-* な文字コードに対応した。と、いうことなのでしょうなぁ。

 
PC に色々ブラウザが入っていると楽しいですよ;-)。 是非、試してみてください。;-)

6月 122014
 

ウェブサイトを斜め読みしていたら「安くて良い音がするヘッドホンが Amazon で売っていて人気になっている。」とのことだったので僕も購入して試してみました。

僕が看過された記事はこちらになります。

http://av.watch.impress.co.jp/docs/review/minireview/20140602_650832.html

なるほど。良い感じなのね。ちなみに今回購入したイヤフォンは iPhone5 で利用する予定です。

現状、 iPhone5 で音楽を聞く場合には iPhone5 に付属の EarPods を利用しているのですが、それについて以前のエントリである「iPhone5 利用してみました。」と「EarPods にスポンジ付けてみました。」に書いています。今回購入したのが、この Apple 謹製の EarPods イヤフォンと比較してどう違うのか、僕の耳と僕の感性でレポートしてたみいと思います。

とわ言いつつ、そんなに音にうるさいということは全然、全くないのですけどねf(^^;;。

 
さて。 Amazon で購入したのは送料込み 3,980yen でした(すごいグッドなタイミング;-)。下にリンクつけておきます;-)。 Amazon からはダンボールな箱ではなく、袋に入っていて届きました。中から出してみましたがこんな感じ。

IMG_7170_BEB_868B_1

付属品としては説明書と、巾着袋。あと、耳あてのゴムの替えパーツがドドドと大量に、色々な形のモノが入っていました。 Audio-Technica のイヤフォンを購入した場合は大・中・小が入っていますが、今回の Blue Ever Blue 868B にはその他にもゴロゴロと色々なのが入っていました。

IMG_7171_BEB_868B_2

さて。実際に音を聞いた感じですが、比較対象として iPhone5 に付属の Apple EarPods とになります。上にある二つの前回のエントリでは EarPods はすげー。ってことに、僕の中ではなっているのですが、今回はどうなったでしょう? ちょっと明らかな違いを箇条書きにしてみますね。

・音の広がり方は Blue Ever Blue 868B のほうが断然良い
・重低音ドドドは Apple EarPods が勝ち

こんな感じでしょうか。上に掲載した URL を見てみると HDSS 技術が素晴らしい。と、書かれていますが、僕にはその技術がどういうモノかよく判りませんf(^^;;。

 
話はガラリと変わるのですが、 docomo の『d ミュージック』から購入した楽曲は AAC 320kbps で iTMS の 楽曲の 256kbps より音が良い。と言われますが、僕にはその違いが判りません。ただ、d ミュージックで購入した楽曲は iTMS で購入した楽曲より音が大きいような気がします。音が大きいと色々な音が拾えるようになるので、だから「良い音の楽曲」に聞こえるのかなぁ。などと個人的に思ってしまうんですけども。

 
さてさて。今回確認のために利用(試聴)した曲目も書いておきましょう。

AKB48 の「Everyday、カチューシャ」はイントロ部分の右側の聞こえない音が聞こえてきます。これは前回書きました;-)。「ポニーテールとシュシュ」は音の広がりが体感できます。メンバのハモッている声までバッチリ聞こえます。
Loudness の「Crazy Night」はイントロ部分はちょっと重低音(フロアバスの音)が抜けるかなぁ。あと、最近は angela の「シドニア」をよく聞いているのですが、この曲は Apple EarPods で聞いたときの音のほうが好きです。

あ。楽曲を作る人は、聴く人が持っている環境(プレーヤーやスピーカー・ヘッドホンなど)に音色を合わせて音作りをする。と、いう話を聞いたことがあるので、もしかしたら新たしめの楽曲は Apple EarPods に合わせてチューニングした音作りになっているモノも多分あるのでしょうなぁ。

それにしても、僕は基本的には重低音好きな人ということになりそうですねf(^^;;。あ。 Blue Ever Blue 868B は重低音が弱い。なんてことは決してないです。7,8 年前のイヤフォンに比べると全然良い感じの音です。そして、それにしても音の広がりについては圧巻です。

 
と、いうことで比較はここまで。

あと、物理的な構造に対しての好き嫌いもあると思うのですが、

・簡単にポロっと耳から抜け落ちてしまう Apple EarPods
・しっかりとしたアルミ筐体で耳にピッタリとフィットする Blue Ever Blue 868B
・ケーブルというかコードの作りはこんがらない素材を利用している Apple EarPods が勝ち
・Blue Ever Blue 868B は耳に入れたりするときにクシャっと音がするのは素材は解らないがコーン紙が圧力で音を立てているのかな?

これらのの四点を音の観点にプラスしてみても Blue Ever Blue 868B を常用したくなります。ただ、最後の一点はちょっと心配ですが、僕の持っている個体の問題なのかな?

そして、あと、一点。

・リモコン機能どうするの?

って話がありますが、僕の場合、 Audio-Technica の AT338iS を持っているのでこれを再登場させることにしました。 iPhone5 → AT338iS → Blue Ever Blue 868B と接続することになるのですが、間に AT338iS が入っても回路的な音の劣化は、僕の耳では感じられませんでした。

 
と、いうことで、 Apple EarPods も定価で購入すると 2,200yen 、 Blue Ever Blue 868B も 3,980yen と非常に安価で良い音が手に入ります(耳に入るのかな?;-)。

 
と、いうことで今回はここまでにしておきます。比較や試聴の対象として皆さんの手元にあるモノを例に取り上げてみました。この文章を書いた人(それはつまりは僕のことですが)は AKB48 好き。なんてことは多分・絶対に無いのではないかと思われます;-)。

 

5月 312014
 

そもそも Flightradar24 ってのはなんぞや? となるのですが、iOS アプリです;-)。

URL 的にはこんな感じ。
http://www.flightradar24.com/35.69,139.75/7

これが iPhone アプリだとこんな感じ。
https://itunes.apple.com/jp/app/flightradar24-pro/id382069612?mt=8

今回は iPhone アプリのキャプチャを撮ってみました。

アウトドア好きの僕にとって、夜、焚き火を見ながらバーボンをコプリと喉に流しているときなど、遠く上空からゴーっと音が聞こえると空を見上げ「あの飛行機はどこに行くのだろう?」と漠然と思うわけです。そんな時にこのアプリに出会いました。

IMG_7141Flightradar24_1

確か有料だったと記憶していますが、これで、自分の位置情報から上空を飛んでいる飛行機がどこからどこに向かって飛んでいるのかリアルタイムに確認できるんですね。すげー。夢とロマンがあるじゃん。みたいな感じだっんですけども。

で、今回久しぶりに起動して驚きました。確かちょっと前にバージョンアップしているんですが、下のキャプチャは羽田空港近辺の地図で Flightradar24 が検知している飛行機がワンサカ写っているんですね。

IMG_7137_Flightradar24_2

飛行機をタップすると地図上に線を引いてくれてどこの空港からどこの空港へ、そして通ってきた経路を表示してくれます。

これだけでも随分と楽しいのですが、飛行機が表示されている下のメニューに “3D” とかいうのがあります。これをタップするとあーた。キャプチャはこんな感じ。

IMG_7138_Flightradar24_3

なんか、その昔、こーいうゲームがあったような気がしますが、キャプチャの画面下には当該機のデータがリアルタイムで表示されていて、そのデータをもとにしてコックピットの風景を動画として表示してくれるんですね。

一番楽しいのが空港に着陸する瞬間でしょうかね。このキャプチャのように滑走路がズンズンと迫ってきます。
東京湾上空の飛行機も楽しくて景色がくるくる変わっていきます。町並みはあまり美しくはないですけどね。

 
Flightradar24 と、いうアプリはもう随分と前に購入したのですが、今回久しぶりに起動してみて、こんなに機能が充実しているとは思いませんでした。

飛行機好きな人、外で飛行機が気になる人はは是非ともインストールしたいアプリですね。おすすめです。今の価格は 300yen かぁ。僕は 200yen くらいで購入したような気がする;-)。

 
あ。僕的には随分と珍しいアプリケーションレビューのエントリでした;-)。

5月 072014
 

以前のエントリで「MVNO の SIM 購入。」というのを書きました。この頃は利用し始めてすぐのときに書いたのですが、今回、しばらく使い込んでみたので以前の記事の内容のアップデート風に書いてみたいと思います。

そもそも、僕は MVNO の SIM は WindowsPhone8.1 のスマートフォンで利用しています。以前から何回か書いていますが Nokia Lumia 620 ですね。で、それとは別に docomo のスマートフォンである NEC MEDIAS N-04D の Android4.0 のスマートフォンも持っていますが、こいつにはたまに MVNO SIM を入れたりしています。その二台で利用した場合について書いてみます。

 
1. SMS に対応してないので・・
僕が利用している ASAHI ネット の「ASAHIネット LTE」の 1 ギガプラン はデータ通信のみで SMS に対応してないのでアンテナピクト問題が発生しています。アンテナの強度が表示されない問題ですね。しかし、二台のスマートフォンで動作が違います。

o. Nokia Lumia 620 : 電波の強度が表示されない
o. NEC MEDIAS N-04D : 強度が表示され 3G/LTE まで表示される

と、いうことでどういう制御してるんだろ? Android が秀逸なのか、 docomo の機能として出しているのか、僕には判りません。

wp_ss__MVNO_2_1

こーいう感じのキャプチャは色々な OS で、あちこちで見ますよね。

 
2. SMS 及び電話番号が無いと・・
上のとリンクしているかもしれませんが WindowsPhone OS ではウェブページからログイン後にウェブ上からアプリを購入して Lumia 620 に送ったり、電話を探しだしたりする機能があるのですが、 SMS 及び電話番号が無いとこの機能が動作しません。結構痛い・・。

「ウェブサイト(Microsoft)から SMS を送信することを許可」とかチェックボックスがあるのですが、そーいうのが機能しないし、ウェブページからログイン後の機能の半分くらいが動作しなくなります。そう考えるとデータ通信のみの SIM カードというのはちょっと痛いかもしれないです。

 
3. テザリング対応状況
いやー。これは驚きました。まず先に結果を書きます。

o. Nokia Lumia 620 : テザリングできます
o. NEC MEDIAS N-04D : テザリングできません

Lumia 620 はテザリングができたとしても 3G でしか通信できないので、恩恵というのはあまり受けられません。
それにしても MEDIAS N-04D ですが、こいつは MVNO SIM を入れるとピクトアンテナが LTE Ready になるのですが、設定画面からテザリングをオンにするとシュシュシューっと本当に音が聞こえるかのように通信不能状態になっていきます。
で、再度設定画面でテザリングをオフにし、しばらくするとスゥーッとアンテナが生えてきます。

と、いうことで docomo の Android 機は何かしらの制御をしていて MVNO SIM を入れてテザリングをオンにすると 3G/LTE の電波を遮断する機能が搭載されているようですね。「テザリング・ 3G/LTE ジャマー」とかそんな感じのネーミングを勝手に付けてしまいたくなるX-(。

 
4. IIJ SIM って IPv6 対応らしい。
番外編ですが Nokia Lumia 620 はキャリアの APN の情報を入力する場合に IPv4 と IPv6 と、あと IPv4v6 の設定があります。IIJ の MVNO SIM は IPv6 対応らしいので IPv4v6 を指定すると IPv4 は(IIJ の仕様により)プライベートアドレスが、IPv6 はグローバルアドレスが利用できるそうな。

wp_ss_MVNO_2_2

ふむー。さすがは IIJ。SIM カードでの通信時に IPv6 が利用できるとは恐れ入りました。 ちなみに NEC MEDIAS N-04D の Android4.0 自体が IPv6 に対応してないので問題外。 iOS は WindowsPhone8.1 と同様 IPv6 に対応しているのでこれまたちゃんと設定すると SIM での通信時に IPv6 が利用できるのでしょうなぁ。

 
と、いうような感じでツラツラと書いてみました。一言、端的に言えるのは 3G にしか対応していない Nokia Lumia 620 では遅いっ!! ってことは力強く言えます。ただ、 3G にしか対応してないので 1G のデータプランでも全然余裕で使えるー。って話はありますが;-)。

今回僕が利用した「ASAHIネット LTE」は最低利用期間が一ヶ月なので、イヤになったら(初期設定料は 3,000yen ですが)サクっと解約できるので、こーいうプランのヤツで先に色々検証して、そのあとでコッテリと濃いぃ本当に自分が利用したい MVNO SIM 見つけるとか、それに合う端末を見つけるなどしたほうが良さそうです。

あ。僕はもう少し「ASAHIネット LTE」を利用してみるつもりではいます;-)。

4月 162014
 

ちょっと前に「WindowsPhone8 update3」と、いうエントリを書きました。ようやっと Lumia Black 対応になって画面の横向きを停止できたりとか、色々な恩恵を受けられたんですけども。

その後、2014/04/02 に開かれた Microsoft Build Developer Conference 2014 において Windopws 8.1 Update と一緒に Windows Phone 8.1 が発表され、今回、僕の持っている Nokia Lumia 620 に Windows Phone8.1 開発者向け Preview 版が降ってきました。

上のエントリのところでも書いていますが、僕自身がデベロッパ登録して、 Lumia 620 自体も開発者向けアンロックされている端末なので「設定」->「電話の更新」メニューから調べてみると、アップデートがあってバババと、ほぼ一晩かけてバージョンアップが完了しました。

まず最初に多分 Windows Phone 8.1 対応のために電話機側のバージョンアップが必要だったのでしょうねぇ。三回くらいバージョンアップを繰り返しました。しかし、それでも Windows Phone 8 のままで・・。
その後、大規模な更新が入って「お。いよいよ Windows Phone OS 本体のバージョンアップ開始かぁ?」などと思いバージョンアップしつつ力尽きて寝てしまいました。

次の日に起きて確認すると Windows Phone 8.1 になっていて、最後にデータを最適化してバージョンアップが完了です。

20140416_1

さてさて。Windows Phone 8.1 になってどこが変わったか? Windows Phone 8 からどう変わったか? などについてちょっと書いてみたいと思いますが、まずはダメな点から。

 
1). Windows Phone 8 から引き続きダメな点
o. ヲレヲレ SSL な https:// サイトの対応がダメだぁ・・。
今後のブラウザアプリで更新されるのかもしれないけど、ヲレヲレ証明書の SSL を通過できるブラウザは IE だけ。と、いうお粗末さ。アプリストアからダウンロードしたサードパーティー製ブラウザは根こそぎヲレヲレ証明書な SSL サーバにアクセスできません。

IE を利用したとしても「永久に信じる」ってのが無いので毎回確認する必要があります。Windows Phone 8.1 になってもダメなのでいいかげん何とかして欲しいような気がします。

けどもまぁ、セキュリティのことを考えると、これはしょーがないのかなぁ・・。

o. DHCP は相変わらずだぁ。
Wi-Fi で接続した時に DHCP アドレスしか取得できないというのも以前バージョンから変わっていませんね。
僕は自宅では Wi-Fi 環境でも固定アドレスを利用しているので Windows Phone の場合には dhcp サーバで Mac アドレスの設定を入れ、固定アドレスを配布するように設定しています。

o. いい加減 Bluetooth キーボードに対応してくれぇ・・。
今回のバージョンでは Bluetooth キーボードは「接続完了」状態にはなったんだけど、文字が打てない・・。orz。 Bluetooth キーボードは二個持っているんだけど、どっちも利用できない。
今回のバージョンでは Bluetooth キーボードは対応してくれたのかなぁ?

 
2). WindowsPhone 8.1 になってダメになった点
o. 「自分アプリ」って言うんですかねぇ? 投稿時の動作が・・。
Facebook と Twitter などを統合して表示してくれるアプリがあるのですが、記事を書くときに以前のバージョンだと、一個の文章を Facebook と Twitter の両方に投稿することができたんだけど 8.1 になってからどっちかにしか投稿できなくなったみたい。

同じ文章を Facebook と Twitetr の両方に投稿できなくなったのはちょっと痛いかなぁ。

o. 「バックグラウンド」メニューはどこに行った?
僕がまだ見つけられていないだけかもしれませんが、 Windows Phone 8 でバックグラウンドで通信を行うアプリを制限できたんだけど、そのメニューがなくなってしまったようです。バックグラウンドで通信やアプリの制限をかけたいんだけどどこで制御するんだろ?

 
3). Windows Phone 8.1 になって気がついた点
o. NFC が「設定」メニューに登場
以前は「ファイル共有」とかそんな感じのメニューだったんだけど、 Windows Phone 8.1 からはちゃんと「NFC」と書かれるようになりました。

設定できる項目的にはまだ少ないんだけど、Windows Phone の仕様としては NFC タグからは連続して特定のアプリを起動できないらしいんですね。例えば、

Wi-Fi オン -> Bluetooth オン -> サードパーティ製音楽再生アプリ起動

と、いう一連の流れを一個の NFC タグで行おうとした場合、最後のアプリ起動が許可されていないんですね。が、しかし、今回の 8.1 以降ではその仕様が変わる可能性がある雰囲気はあります。今後に期待。でしょうかねぇ。

あ。ここに書いて良いのかわかりりませんが、メニュー的には “VPN” というのも出来ました。利用してないので機能的にどうなのかわかりません。

4). Windows Phone 8.1 になって増えた機能
これは色々なところで色々な人が書くと思うのでここでは取り上げなくても良いとは思うのですけどねぇ。

o. 通知センター(Action Center)ができた
上からスワイプすると、Android のメニューみたいなのがベロンと出てきます。

20140416_2

表示されるメニューは選べます。あと、メールとかスケジュールも表示されるので他の OS にだいぶ近づいてきた感じがするかなぁ(と、いうコメントもあちこちのレビューサイトで書かれていますね)。

o. Wubdiws Phone UI がぁーーっ!!
Lumia 620 は画面がちっこいのに横に並べられる四角いメニューが 1.5 倍になりました。今までは 小四個が最大だったのに今度は小六個まで並べることができるようになります。
当然、どっちにするかは設定メニューで選べますが、僕は今までどおり小四個で行くことにしました;-)。

バックグラウンドに写真が貼り付けられるようになったのは有名な話ですよね;-)。

o. コルタナ(Cortana)?
これも有名ですよね。 iOS の Siri のように賢くなったと言われていますが、日本語版についてはまだ動作確認はしていません。

以前は Windows ボタンを長押ししたら起動したんだけど、あれ? 動かなくなったなぁ。

ただ、Windows Phone 8.1 にしたときにメールというか SMS が飛んできたのですが、その文章をいきなり読みだしたのには驚きました。中々良い感じでメールの本文を読んでいました。日本語版もそこそこ充実して来たのかな?

20140416_3

 
と、いうことでパっと触ってみた Windows Phone 8.1 について書いてみました。 僕の持っている Lumia 620 は安い端末で見た感じ結構ちゃちぃですが、ハードウェアと OS の相性は中々良いと思います。サクサク動くし、ベンダの対応も早くデベロッパー用の OS バージョンが利用できたりするし。

マニアな人向けでも構わないですが、今後はもう少し流行っても良い感じがしますね。

 
あと、最近ボクが思っていることをちょっとだけ書くと、僕自身、スマートフォンというのは、初代 iPod Touch が出た時にすぐに購入しました(あ。スマート”フォン”ではないな;-)。そのあと、周りの人より随分早く iPhone3G を購入して、自称ですが当時時代の最先端をドヤ顔で歩いていたと思っています;-)。

しかし、今の時代、スマートフォンの最新鋭・高機能満載機種の iPhone・Android を持っていてもドヤ顔はできません。今ドヤ顔で利用できるのは Windows Phone だけだと思っています(自分が持っているし;-)。

今の時代、ドヤ顔するなら絶対に Windows Phone です;-)。

4月 042014
 

最近は IME に関するエントリが多いですが、もう一回書いてしまおう。でもって、最近の連続する一連のネタは多分これが最後でしょうかねぇ;-)。

いきなり手前味噌で大変申し訳ありませんが、そもそも mozc.el な(ノラ) ports は僕が一番最初に作成して NakataMaho さん がコミットしてくださり、その後 mozc-server のメンテナの方が取り込んでくださった。と、いう経緯があります(japanese/mozc-el/Makefile の一番上見てね;-)。

mozc 自体には当初から emacs 対応の mozc.el がバンドルされていたけど mozc-server の作者が「僕、emacs 使ってないしぃ。」と、いうとこで mozc.el が ports にならなかったし、インストールされなかったんですけども。

で、現在は mozc の最新版は mozc-1.13.1651.102 ですが、 FreeBSD の ports 的には 1.11.1502.102 のままです。まぁ、 mozc を FreeBSD に対応させるためには随分たくさんの改修を行いパッチを作成しなければ make が通らないという、その苦労はよぉーく知っているので現行バージョンである 1.11.1502.102 でも一応、問題はありません。

が、しかし、 mozc-1.11.1502.102 な mozc.el には以下のようなバグがあって困っていたんですね。

 
X11 の emacs 上 (emacs -nw ではない状態) で mozc.el 経由で日本語を入力しているときに mozc のサジェストがウィンドから飛び出ると入力した文字が消えてしまう。
確定前の文字が消えるだけなら良いのですが、それ以前に入力した文字まで消えてしまう。

 
結構悲惨な状態で、それがいやでしばらくの間は ibus.el (ports 的には textproc/ibus-el です)経由で mozc を利用していました。

ところが、ibus-1.5.5 になって ibus.el が ibus-daemon と通信できなくなったので、いよいよ mozc.el を利用しなければならなくなった。

mozc.el を利用しいるとき emacs のウィンドの上のほうで文字入力をしている分には問題ないのですが、下のほうに来るとサジェストがウィンドの下を突き破るようになるので入力した文字が消えてしまうんですけどね。

 
何か回避策はないものかいのぉ。とかと思い、mozc の最新版のソースコードを持ってきて mozc.el を /usr/local/share/emacs/24.3/site-lisp/mozc/ にほーりこんでみましたよ。そしたらあーたっ!!

いやー。最新版の mozc に付属の mozc.el もしっかり更新されていて日本語入力中のサジェストは、ウィンドの下辺りで入力している場合にはカーソルのある入力行の上に表示されるようになり文字が消えてしまうというバグが改修されているんですね。これを利用しない手はないっ!!

 
ってんで、やっとここからが本題です。

mozc-server 自体は現行バージョンで良いし mozc.el インストール時に mozc_emacs_helper (バイナリ)が一緒にインストールされるのですが、これも現行バージョンのモノで良い。ただ単に mozc.el のみ最新になってくれると随分と幸せになれます。

と、いうことでパッチを作成しました。以下の URL に置いておきます。

http://icmpv6.org/Prog/FreeBSD_ports/patch-unix_emacs_mozc.el-20140402

このパッチを以下の要領で japanese/mozc-server/files/ の中に入れてください。

# cd /usr/ports/japanese/mozc-server/
# cp ~/patch-unix_emacs_mozc.el-20140402 files/patch-unix_emacs_mozc.el
# cd ../mozc-el/
# make && make deinstall && make reinstall
#

 

既存の mozc.el のパッチのみを置き換えるとこによって 1.13.1651.102 の mozc.el が利用できるようになります。ダウンロードしたパッチは 1.11.1502.102 と 1.13.1651.102 の mozc.el を diff しただけです。

非常にお気楽に、そして簡単に emacs の mozc 入力が最新になります;-)。

FreeBSD の ports の現行バージョンの mozc.el で困っている方いましたら是非ともトライしてみてください。

コミッタの方、どなたかこのパッチを吸収してくれないかなぁ。まぁ、パッチは差分だけなので簡単に作成できると思うのですけどね;-)。