Hatena::ブログ(Diary)

hnwの日記 このページをアンテナに追加 RSSフィード

[プロフィール]
 

2015年4月19日(日) PHPのJSONライセンス問題が一応決着 このエントリーを含むブックマーク このエントリーのブックマークコメント

2012年頃に、PHPJSONエクステンションソースコード中に次のようなライセンス文言が含まれていると話題になりました。


The Software shall be used for Good, not Evil.

これはJSONライセンスと呼ばれるライセンスの一文です。「このソフトウェアを良いことに使うのはいいけど、悪いことには使っちゃダメ」といったところでしょうか。


これはフリーソフトウェアの定義に反しており*1、各種LinuxディストリビューションJSONエクステンションを配布できないことになるため、ちょっとした騒動になったというわけです。


本稿ではこのJSONライセンスへの対応が現在どうなっているかを紹介します。


各種Linuxディストリビューションの対応

PHPJSONエクステンションはjson_encode()やjson_decode()などの重要な関数を提供するエクステンションですから、ディストリビューションとしても提供しないわけにはいきません。


多くのディストリビューションでは、標準のJSONエクステンションを削除し、代わりにpecl-json-cという別実装をphp-pecl-jsoncやphp5-jsonといったパッケージ名で提供しています。


このエクステンションは、この問題が発生したあとでPHPコミッターであるRemi Colletさんが開発したもので、JSON-Cラッパーとして実装されています。


ただ、UTF-8以外の文字の取り扱いが標準のJSONエクステンションと異なるなど、ユーザー目線では不便も残っている状況のようです。pecl-json-cが気に入らなくて標準エクステンションを自前ビルドして使っている人もいるようですね。


ちなみに、自分の手元でどちらのエクステンションが使われているかはphpinfo()でわかります。JSONエクステンションの情報に「JSON-C version (bundled)」という表記があればpecl-json-c版です。


PHP本体の対応

この問題は「PHP :: Bug #63520 :: JSON extension includes a problematic license statement」でPHP本体のバグレポートとしても議論されていましたが、ずっと膠着状態が続いていました。


また、「PHP RFC: Switch from json extension to jsonc」というRFCPHP標準のJSONエクステンションpecl-json-cに差し替えようという提案もされましたが、結局議論がまとまらなかったのか、最新のPHP 5.6.8でもライセンス的に問題のあるコードが残っています。


一方で、PHP7ではjsondが標準JSONエクステンションとして採用されました。これはJakub Zelenka(@bukka)さんがre2cとbisonで新規実装したものです。


PHP7からはライセンス問題がなくなるよ!ということでPHP本体としても解決といったところでしょうか。上記バグレポートもjsondのPHP7への取り込みをもってcloseされています。


参照

*1https://www.gnu.org/philosophy/free-sw.en.htmlfreedom 0「The freedom to run the program as you wish, for any purpose」に反している

トラックバック - http://d.hatena.ne.jp/hnw/20150419

2015年4月1日(水) PHP 5.4.0から無限大==無限大になってた このエントリーを含むブックマーク このエントリーのブックマークコメント

本日はエイプリルフールなので、嘘でも本当でも誰も困らないネタを紹介します。


内容としてはタイトルの通りで、浮動小数点数の無限大とマイナス無限大に関する==の挙動がPHP 5.3.xまでとPHP 5.4.0以降で変わっていたという話題です。


$ php-5.3.29 -r '$x=INF;var_dump($x, $x==$x);'
float(INF)
bool(false)
$ php-5.4.0 -r '$x=INF;var_dump($x, $x==$x);'
float(INF)
bool(true)

このように、PHP 5.4.0以降は INF == INF、-INF == -INF という挙動になりました。


僕は過去の記事「「===」がtrueを返し「==」がtrueを返さないサンプル」で、当時のPHPINF === INF なのに INF != INF となるのは違和感があるという風に書きました。これが自然な方向に修正されていたというわけです。やったね!

2015年3月8日(日) マルチブート環境の全OSで同じBluetoothデバイスを使う このエントリーを含むブックマーク このエントリーのブックマークコメント

マルチブート環境(デュアルブート・トリプルブートなど)でBluetoothデバイスを使う際の話題です。


Bluetoothデバイスを利用する際は通常「ペアリング」という作業が必要です。これは、初回接続時に128bitのリンクキーを発行して両者で共有し、通信相手のBDアドレスに紐付けておく仕組みです。これにより、次回接続時は同じリンクキーを使ってお互いを認証することができますから、面倒な手続きなしに利用することができます。


ところで、この仕組みはマルチブート環境ではうまく働きません。マルチブート環境ではそれぞれのOSが同じBluetoothアダプタを共有するため、Bluetoothデバイスからは各OSを区別できないのです。


もう少し具体的に説明します。マルチブート環境で1つのOSからデバイスをペアリングしたあとで別のOSを起動した状況を考えてみましょう。このとき、デバイス側から見るとペアリングが済んでいるはずのBDアドレスなのに、OS側ではペアリングしていないためリンクキーがわかりません。再ペアリングをすれば新たなリンクキーが発行されて接続できるようになりますが、今度は最初のOSがリンクキーを共有していない状況になってしまいます。別のOSを起動するたびに毎回ペアリングすれば使えるものの、これではせっかくのBluetoothの利便性が台無しです。


これを解決するには、OSの管理しているリンクキーの情報を書き換えてやるしかありません。本稿ではMacOSXWindowsLinuxのトリプルブート環境でリンクキーを揃える方法を紹介します。


この内容はApple Support Communitiesの「Dual pairing in OS X and Windows」がベースになっていますが、僕は正解にたどり着くのに苦労したのでまとめ直してみました。


Macのマルチブート環境

Macに他のOSインストールするということではBoot Campが有名ですね。本稿の情報はそうしたMacOSXWindowsデュアルブート環境でも活用できるかと思います。


ちなみに僕はBoot Campを使わずにMacBook Air(2010 Late)にMacOSX 10.9、Windows 7(32bit)、Ubuntu 14.04LTS(64bit)の3つをインストールしています*1。先日SSDを256GBに換装したので試しにインストールしてみたのですが、思ったより実用的だと感じています。


今回の作業で、これら3つのOSすべてで同じNexus5経由のBluetoothテザリングができるようになりました。

続きを読む

*1:興味がある方は「refind macbook」などのキーワードでググってください

トラックバック - http://d.hatena.ne.jp/hnw/20150308

2015年3月7日(土) 例示のためのMACアドレス このエントリーを含むブックマーク このエントリーのブックマークコメント

例として推奨されているドメイン名とIPアドレス - あどけない話」に、例示のためのドメイン名とIPアドレスが紹介されています。お役立ち情報ですね。


ところで、MACアドレスを例示したい場合はどうすればいいのでしょうか。答えがRFC7042に載っていたので紹介します。


48bit MACアドレスの場合

48bitというのは我々が普段見るスタイルのMACアドレスです。「2.1.2. EUI-48 Documentation Values」によれば、次のアドレス範囲が例示に利用できます。


  • ユニキャストアドレスの場合
    • 00-00-5E-00-53-00 から 00-00-5E-00-53-FF まで
  • マルチキャストアドレスの場合
    • 01-00-5E-90-10-00 から 01-00-5E-90-10-FF まで

これらは先頭の40bitが固定されているので、使えるアドレスはそれぞれ256個です。NICやその他身近なネットワークデバイスにはユニキャストアドレスが割り当てられているはずですから、通常は前者のみが使えるということになるでしょう。


64bitのMACアドレスがどういう状況で使われるのか残念ながら僕は知りませんが、こちらも「2.2.3. EUI-64 Documentation Values」に記述があります。ご参考まで。


Bluetooth device address(BD_ADDR)とMACアドレスとの関係

Bluetoothでもデバイスごとにユニークな48bitのBluetooth device addressが割り振られており、これをMACアドレスと呼んでいる資料も多く見つかります。Bluetooth device addressもMACアドレスも上位24bitをベンダーごとに割り振っており、そのベンダーごとのIDも両者で一致しているようですから、非常に似ているのは間違いありません。


ただ、Bluetooth device addressがMACアドレスそのものなのか、また上のアドレスを例示に使っていいのかについてはわかりませんでした。詳しい方がいらしたら教えてください。


とはいえ、Bluetooth device addressの例示について言えば上のアドレスを使っておけば現実のデバイスと重複することは無い、ということは言えそうです。(00-00-5EがIANA所有になっているため)

トラックバック - http://d.hatena.ne.jp/hnw/20150307

2015年3月1日(日) CloudFlareのCNAME FlatteningをGitHub Pagesで使ってみた このエントリーを含むブックマーク このエントリーのブックマークコメント

(03/04 08:15 追記)今回のDNS設定変更でGitHub Pagesで提供しているCDNが使えるようになったことを追記しました。


今回はDNS方面の話題です。僕ははてなダイアリー以外にhttp://hnw.jp/という古めかしいサイトも管理しています。サイトの実体はGitHub Pagesで、これまでAWSのRoute 53でカスタムドメインの設定をしていました。


ところで、このサイトが2月の頭から1ヶ月ほど見えなくなっていました。原因は僕がGitHubからのメールを読み飛ばしており、DNS設定の変更を怠っていたためです。これに懲りて、今後DNS設定を二度といじらなくて済むようRoute 53からCloudFlareに引っ越してみました。その顛末を紹介します。


GitHub Pagesのカスタムドメイン設定

GitHub Pagesを普段使っていない人も多いと思いますので、まずは背景を紹介します。


GitHub PagesGitHubの提供する機能の一つで、GitHub上の各リポジトリhttp://hnw.github.io/hnw.jp/のようなURLを与え、特定のブランチをWebサイトとしてアクセスできるようにするものです(URL中のhnwがGitHubユーザー名、hnw.jpがリポジトリ名です)。WebサーバGitHubが提供してくれるので、gitの操作に慣れた人が静的コンテンツだけのサイトを手軽に作るにはもってこいのサービスだと言えるでしょう。


さらに、自分でドメインを持っていればGitHub PagesのURLを好きなホスト名に変更することもできます。「Setting up a custom domain with GitHub Pages」にも書いてある通り、リポジトリ上にホスト名を書いたファイルを追加した上でDNSのCNAMEレコードを設定すればカスタムドメインの設定ができます。


ただし、ホスト名として「zone apex」を使っている場合は設定方法が変わります。zone apexというのはドメイン名と同じホスト名のこと*1です。この場合RFCの制約から通常CNAMEを設定することができない*2ため、AレコードGitHubIPアドレスを直接指定するしかありません。


僕のサイトもzone apexだったため、Aレコードを設定していました。


zone apexでも放置運用したい

続きを読む

*1:正確には違いますけど説明用ということで…

*2RFC 1912 2.4にある「A CNAME record is not allowed to coexist with any other data」が根拠です

トラックバック - http://d.hatena.ne.jp/hnw/20150301
 
ページビュー
1451648