Monthly Archives: 2月 2013

携帯電話はインフラか?

Pocket

 

携帯電話業界にいると、「我々インフラ業者は」という言説がよく用いられるように思う。

たしかに、携帯電話はもはや私たちの生活になくてはならないもの、かもしれない。
でも、「携帯電話はインフラである」と言ったときに、「はいそうですね」とは素直に頷けない違和感が私の中にある。
違和感の原因はなんだろう?
端的に言えば、インフラとしてすぐに頭に浮かぶ電気上下水道ガスと、携帯電話を同列に扱う据わりの悪さだ。
モヤモヤとしたまま、あれやこれや調べ考えた事をまとめる。

インフラってなんだ?

そもそもインフラとは何であろうか。Wikipediaによれば社会や企業の運用に必要な物理的かつ組織的な構造体、または経済活動に必要なサービス、施設を指し、一般的には道路や橋、電気上下水道、電話を指す、とのこと。

確かに、Wikipediaに示される定義に沿えば、電話も、ひいては携帯電話もインフラだろう。企業運用や経済活動には必須だから。

モヤモヤの正体

しかし私が「インフラ」から受ける印象は、人間が生活するにあたって必須のもの、というものだ。端的に言えば電気ガス水道。そこが間違ってると言えばそうなんだが、結局のところ私がモヤモヤしているのは、果たして携帯電話は電気ガス水道と同じように生活に必須のものかどうかということ。

じゃあそれで追っかけてみよう。

NeedsかWantsか

マーケティング用語にNeedsとWantsという便利な分類がある。(もう一つdemandsがあるけど割愛)

Needsとは、それなしでは人が生きられないもので、放っておいても人が買うもの。
Wantsとは、必須ではないけどあったらいいもの。

この分類で電気ガス水道、携帯電話を比べてみよう。

水道はNeedsでしょう。
ガスは?最近は電気で代替できるけれども、暖房、調理(、照明)でまあNeeds。
電気は?照明、冷暖房、調理、そのほか電化製品でNeedsでしょう。

では携帯電話は?難しいところであります。加えて携帯電話には電話という側面と、モバイルインターネット/ブロードバンドという側面があるし。

しかしここでNeedsインフラである電気で考えてみる。電気をNeedsたらしめているものは何かといえば、私たちが深く依存している数々の電化製品のためである。

電気ガス水道の歴史

ローマ時代からあった水道と比べて、電気、ガスは比較的新しいインフラである。

これまたWikipediaで調べてみたら、ガスは1810年頃、電気は1870年頃からインフラとしての利用が始まったようだ。

ガスは当初、照明として利用されたが、燃料だけに取り扱いが難しく、電気に代替された。

電気も最初は照明で使われたのだが、こちらは抜群に取り回しが効くエネルギーである。照明以外にもあらゆる分野で使われるようになった。

携帯電話の活用は始まったばかり?

電気の歴史を眺めてみると、携帯電話はWantsからNeedsの変わり目にいるように感じる。

携帯電話がモバイルインターネットになって、4Gでモバイルブロードバンドになり、電話以外での活用が始まったばかり。あと何年かして、携帯電話システムの上でいろんなサービスが花開くと、私もすっきり「はい。携帯電話はインフラです」と言えるようになるのだろうと思う。

しかし携帯電話がインフラになるには大きな障害があるように思う。有り体に言えば高すぎるように思う。

インフラ支出比較

インフラ支出

これは各家庭が電気、ガス、上下水道、通信に月々いくら払っているかを示す。

総世帯ではまだまだ電気が優勢だが、4人家族を見ると\15,000を超えてくる。高い。

しかし「通信」なんてくくられてるとよく分からん。

いろいろ調べてみると、移動電話通資料として月々どれだけ払っているかを世帯主年齢別かつ推移で示す統計があった。それがこちら。
月額推移

これを見ると60歳の上と下でくっきりと分かれていて(この強烈な落差には興味が湧きますな)、60歳未満が世帯主の家庭では携帯電話料金として月々1万円超を払っていることが分かる。

安価さもインフラの定義じゃないだろうか。

こういった統計をつらつら見るにですね、まだまだ携帯電話料金てすごく高いのではないかと思うのだ。

モバイルブロードバンドとしてほんのわずかしか活用できてないのに、月々1万超ですよ。電気なんてあんなに使えて1万弱。仮に電気代がいまの3倍だったらどうだろうか。

言わずもがな、携帯電話はまだまだ新しく、過渡的な時期だと思う。

しかし。少なくとも今の電気代くらいに料金をそれほど気にせず使えるようになった時こそ、携帯電話はNeedsという意味のインフラになるんじゃないだろうかと思った。

 

統計は下記を参照した。
http://www.stat.go.jp/data/kakei/sokuhou/nen/index.htm
http://www.soumu.go.jp/johotsusintokei/field/kojin02.html

 

No tags for this post.

FreeBSDのSecurity Advisory対応方法

Pocket

FreeBSDのSecurity Advisory(以降, SA)。bind, libcに問題あり。
せっかくなので久しぶりにメモっておく。

BIND remote DoS with deliberately crafted DNS64 query(FreeBSD 9.x以降のみ)
http://www.freebsd.org/security/advisories/FreeBSD-SA-13:01.bind.asc

glob(3) related resource exhaustion
http://www.freebsd.org/security/advisories/FreeBSD-SA-13:02.libc.asc

 

淡々とHandbook、およびSA沿って作業すればよろし。

V.   Solution
Perform one of the following:
(略)
3) To update your vulnerable system via a binary patch:

Systems running a RELEASE version of FreeBSD on the i386 or amd64
platforms can be updated via the freebsd-update(8) utility:

# freebsd-update fetch
# freebsd-update install

Restart all daemons, or reboot the system.

Restart all daemonsは面倒なので再起動しておしまい。

なおkernelにパッチがなければuname -aなどで表示されるパッチレベルやリビジョン番号は変わらない。

本当にパッチがシステムに適用されてるか不安なら、/usr/src/sys/conf/newvers.shのBRANCHを見ればまあよし。

$ grep "^BRANCH" /usr/src/sys/conf/newvers.sh
BRANCH="RELEASE-p1"

しかしbindはしょっちゅうSA発表されるなあ。

No tags for this post.

QCサークルと神話

Pocket

 

QCサークルというのをご存知だろうか。
QCとはQuality Controlの略。
職場を共にする少人数グループで行う品質管理活動のこと。有り体に言えばトヨタのカイゼンである。
http://ja.wikipedia.org/wiki/QCサークル
http://www.juse.or.jp/qc/

良い事例については共有し、他の職場でも活用してもらいたい、というのは会社として当然のこと。そこで活動結果の発表会が催される事になる。なんと全国大会もあるのですよ。

私の勤める会社でもQCサークルがあり(どちらかといえばQCサークルは製造業向けで私の会社にはややそぐわない気もするのだが)、活動結果の発表会もある。

で、私はこの発表会が大嫌いなのであった。
もう少し詳しく言うと、発表会で一般的なフォーマットが嫌いなのだ。

そのフォーマットとは。
たとえばここを見てほしいが、まずグループや職場の紹介から始まるのである。
「誰々と誰々がいて、彼は気は優しくて力持ちです」
「とても楽しい職場です」
次に活動のテーマ選定をどう選んだか。
それから目標設定、現状把握。
いつまで経っても結論に至らないのである。

いま流行りのロジカルシンキングで言えば、例えばまず最初に「これこれの問題がありましたが、改善活動の結果、このような対策を講じてこれこれの効果を得ました。改善活動の内容について説明いたします」と言うべきだろう。
そう考える私にとっては、改善活動の事例発表を聞くのは苦痛以外の何物でもない。

が。
あるときふと、これは敢えてやっているんじゃないだろうか、という疑念が湧いた。
端的に言えば、事例発表会は物語の共有じゃないか、ということ。

人間がものごとを認知する方法には二つのモードがある、と言われる。
ブルナーという人が言い出したことらしいが、一つは論理モード(Paradigmatic Mode)であり、もうひとつは、ストーリーモード(Narrative Mode)である。

前者はすなわちロジカルシンキング手法であり、後者は物語だ。
効率性で言えば断然に前者だろう。物語だなんてまどろっこしいこと言ってられるか。

しかしドナルド・ノーマンは「人を賢くする道具」で、以下のように述べる。

「物語には,形式的な解決手段が置き去りにしてしまう要素を的確に捉えてくれる素晴らしい能力がある。論理は一般化しようとする。結論を特定の文脈から切り離したり,主観的な感情に左右されないようにしようとするのである。物語は文脈を捉え,感情を捉える。論理は一般化し,物語は特殊化する。論理を使えば,文脈に依存しない凡庸な結論を導き出すことができる。物語を使えば,個人的な視点でその結論が関係者にどんなインパクトを与えるか理解できるのである。」

 

中原淳、金井壽宏の「リフレクティブ・マネジャー」ではこんな話が紹介されていた。
コピー機の修理をする部隊を調査した。学びには何が一番役に立ったか。
なんとそれは、研修や技術書などではなく、同僚との他愛もないおしゃべりだったという。
「先日、どこどこのこんな故障をこのようにして切り抜けた」
「こういう操作をしたらひどい目にあった」
といった何気ない成功談、失敗談から最も多く学んだというのである。

物語で認知する、という機能が私たちに備わっていることは、何千年も残る神話が証明している。
そして21世紀になった今でも、その機能を利用した大きな大きな商業装置がある。
ハリウッド映画である。

大塚英志の「ストーリーメーカー」では、多くのハリウッド映画が神話の形式に則っていることが示される。

有名どころではスターウォーズがそうだし、当該本ではバイオハザードを例題に詳しく説明している。
私が最近に観た映画で言えばTrue Gritがそうであった。

すなわち主人公は冒頭で何かを失い、異界へ赴き、そして結果を得るが、代償として何らかの「しるし」を身に負う(実際はもっといろいろなパーツがある)。

この形式に沿えば、私たちは全体を自然に認知できるし、「形式的な解決手段が置き去りにしてしまう要素を的確に捉え」(ノーマンの前述書)られるのだ。

翻って、退屈で仕方がなかったQCサークルの事例発表である。
今にして思えば巧妙に計算された結果の神話フォーマットなのではないか。
どうでしょう皆さん。

なお念のためノーマンの本から続けて引用する。
「物語が論理より優れているわけではない。また,論理が物語より優れているわけでもない。二つは別のものなのだ。各々が別の観点を採用しているだけである。」

 

No tags for this post.

FreeBSDに、現状でdefaultではないRuby1.9をインストールするには

Pocket

 

備忘のために残す。

2013/2/12現在、FreeBSDで何も考えずにRubyをインストールすると1.8になってしまう。
しかし世の中はもう1.9で動いているのでこれでは困るのである。

ところが、デフォルトとはちょっと変わった事をやりだすといろいろ面倒の発生するのがports。

 

Ruby 1.9をインストールする「前」に即すべきこと。

おもむろに/etc/make.confを開き、以下の二行を加えよ。

RUBY_VERSION=1.9.3
RUBY_DEFAULT_VER=1.9

一行目の意味は、/usr/local/bin/rubyを作るという意味。
意味が分からないかもしれないが、ほんとう。
というのも、現時点でRuby 1.9をインストールすると、/usr/local/bin/ruby19が作成され、/usr/local/bin/rubyは出来ない。

一行目の記載をしておけばインストール時にruby19から「ハードリンク」を張ってくれる。
symlink張ってもいいのだが、こういうのはシステム側にやらせておいた方がいい。

ちなみに、検索するとmake.confにこう書け、と教えてくれるページはいくらでもあるのだが、根拠は見つけられなかった。
根拠、つまりインストール前にこういうところを見ておけばいい、というのが分からないので、今後もまず躓いてから考える事になる。これは…。

二行目は、その名の通り、システムデフォルトをRuby1.9にするということ。
これがないと、例えばRuby Gemsをインストールするとき、Ruby1.9がインストール済みでも問答無用でRuby 1.8をインストールし始めるので注意。

なおこちらは/usr/ports/UPDATINGに記載があった。
ただこれをインストール前に知る事が出来るのだろうか。「UPDATING」じゃないか。アップデートするときに読むものじゃないか。

 

Rubyそのほか

make.confに追記したら、lang/ruby19をインストール。
Ruby on Railsが必要であれば、続いてdevel/ruby-gems, www/rubygem-railsをインストールする。

 

 

No tags for this post.

アーカイバlz4を試してみたら(圧縮は)速すぎ笑った

Pocket

 

lz4という圧縮形式があることを知った。
なんでも、なかなかの圧縮効率を誇るわりには、圧縮伸長が速いとのこと。
公式サイト通りにいえば、圧縮では1.5倍程度、身長では1.8倍程度速い、と(>50% faster on compression, >80% faster on decompression)。

速いアーカイバはなぜ嬉しいか。

速いアーカイバはなぜ嬉しいか。
端的に言えば圧縮されたバックアップからの書き戻し時間の短縮化であり、言ってみればMTTRというか、何らかの障害からの復旧速度に効いてくるからである。

というのも。
いくらHDDが安くなったとはいうものの、あればあるだけ使ってしまうせいで、バックアップにはいつまで経っても追いつかない。

そこでディスク容量をかせぐために、古いデータはしかたなく圧縮して保存するのだが、そうするといざ必要になったときには伸長待ちでえらく待たされる。
で、そういう古いデータが必要になるときというのは、高確率で緊急復旧が必要な時なんである。

みなさん、いつまで経っても終わらない伸長をジリジリしながら待ったことはあるだろうか。
ユーザが今か今かと待ってるプレッシャーを背中に感じて作業した事があるだろうか。

何年も前の私はほとほと痛い目を見たので、持っておける世代数は減るものの、原則として圧縮しないでtarで固めるだけにした(高い授業料であった)。

むろんディスクもっと買えとか、速いディスクにしろよとか、ディスク構成考えろとかあるけど、この世の中、インフラエリアにはなかなかお金を使ってもらえないよね。

というわけで、そこそこの圧縮効率があり、しかし速度がめっぽう速いとなれば気にならないわけがないのだ。

なお、速いアーカイバを活かせる道はもうひとつあって、それは圧縮ファイルシステム。
じっさい、lz4を知ったのも、ZFSに入れるよーという話から。

 

各種ポインタ

lz4のソース置き場はこちら。

http://code.google.com/p/lz4/

lz4については以下のslideshareを。ほー。ドラクエですか。

http://www.slideshare.net/komiyaatsushi/dsirnlp-3-lz4

 

入れてみよう!

FreeBSDのportsには入ってないのでsvnでgooglecodeからダウンロード。
コンパイルにはcmakeが必要なので注意。
cmakeディレクトリを引数にcmakeを実行し、さらにmakeを実行する。

$ svn checkout http://lz4.googlecode.com/svn/trunk/ lz4
(略)
Checked out revision 88.
$ cd ./lz4
$ cmake ./cmake/
$ make
Scanning dependencies of target lz4demo32
[ 12%] Building C object CMakeFiles/lz4demo32.dir/lz4.c.o
[ 25%] Building C object CMakeFiles/lz4demo32.dir/lz4hc.c.o
[ 37%] Building C object CMakeFiles/lz4demo32.dir/bench.c.o
[ 50%] Building C object CMakeFiles/lz4demo32.dir/lz4demo.c.o
Linking C executable lz4demo32
[ 50%] Built target lz4demo32
Scanning dependencies of target lz4demo64
[ 62%] Building C object CMakeFiles/lz4demo64.dir/lz4.c.o
[ 75%] Building C object CMakeFiles/lz4demo64.dir/lz4hc.c.o
[ 87%] Building C object CMakeFiles/lz4demo64.dir/bench.c.o
[100%] Building C object CMakeFiles/lz4demo64.dir/lz4demo.c.o
Linking C executable lz4demo64
[100%] Built target lz4demo64

 

すると同じディレクトリにlz4demo64, lz4demo32という実行ファイルができる。
このあとinstallとかするんだろうが、システムに入れたくはないので、自分の/binフォルダに入れる。64bitアーキテクチャなのでlz4demo64のほうを。

$ cp ./lz4demo64 ~/bin/lz4

helpを与えてみるとこんな感じ。

$ lz4 -h
*** Compression CLI using LZ4 algorithm , by Yann Collet (Feb 11 2013) ***
Usage :
./lz4demo64 [arg] input output
Arguments :
-c0: Fast compression (default)
-c1: High compression
-d : decompression
-b#: Benchmark files, using # compression level
-t : check compressed file
-h : help (this text)
input  : can be ‘stdin’ (pipe) or a filename
output : can be ‘stdout'(pipe) or a filename or ‘null’

 

試してみよう!

 

手元にあった685MBytesのFreeBSDインストールディスクイメージをgzip, bzip2, lz4の三種で圧縮、伸長し、その速度と圧縮効率をグラフにしてみた。

それがこれ。スクリーンショット 2013-02-11 21.50.16

青が圧縮時、緑が伸張時にかかった秒数を左軸で示す。
圧縮後、どれくらいのサイズに縮んだかを黄色、右の軸で示す。

gzip, bzip2で6割程度のサイズにまで圧縮したのに対し、lz4は75%に留まる。

そして気になる圧縮伸長では。
lz4が圧縮ではほぼぶっちぎりである。
しかし一方の伸張ではgzipと同じくらいで公式サイトの額面通りには行かなかった。

ただ、圧縮したものがインストールディスク、つまり中身は圧縮済みデータが多かろう点には注意が必要かもしれない。
仮想マシンのディスクイメージだったらまた面白い結果が出たかもしれないけど時間切れである。

え?lzmaですか?試したけど明らかに遅くて途中でやめた。

それからマシン負荷も気になって三種アーカイバのload averageも記録したけどグラフにするの面倒でやめた。

 

まとめ

伸張の方はまだまだ使わないと分からないけど、圧縮は本当に速い。
あっという間に終わってリアルで「えっ?」と言ったほど。

ただ、弱点があって、それはoutputのファイル名を指定しないといけないこと。
zcatのようなもので、これは弱点というよりそういう仕様なんで何とも言えない。

本記事のマクラに出したバックアップへの利用にもちょっと。

でも速いぞ。おまえらも一度使ってみろ。

No tags for this post.

おまえらよく遊んで驚き笑い泣き、よく寝て海馬を休めろ

Pocket

先日もTwitterをつらつらと眺めておりましたら立て続けに二つのTweetが。

池谷裕二 (@yuji_ikegaya) 01/28 12:14:35
歳をとると睡眠が短くなるのはホントです。今朝の『ネイチャー神経科学』誌より→ http://t.co/t0kDHeD7 とくにノンレム睡眠が減ってしまうので、海馬が活性化しっぱなしになり、その結果、記憶力にも悪影響がでます

なおリンク先の記事はAbstractであっても何が書いてあるかさっぱりわからん。
そしてもう一つ。

Shane Parrish (@farnamstreet) 01/28 02:37:43
Great performers typically sleep significantly more than the rest of us. http://t.co/MBd68xvy

上手いバイオリニストは8時間しっかり寝てることに加え、昼寝もすると。
特にトップバイオリニストは一に練習、二に睡眠とまで言うそうな。

リンク先からさらにリンクされているHBRのブログでは、睡眠不足は一般的におまえらが思うよりもパフォーマンスに影響するのだと言うことがつらつらと書かれている。

そして、望ましい睡眠時間は7~8時間程度であろうとのこと。これは平均睡眠時間が7時間という研究結果とも齟齬はなさそう。(ただし記事を書いた人は8~9時間との意見)

small_7687221498

ただ。
俺が思うには、「じゃあたくさん寝ようぜ」ってのは早計じゃないかと思うのだ。
そもそも上記の記事のうち、少なくとも後者はバイオリンの技巧と睡眠時間には相関があるということしか伝えていない。
(Natureの論文にはそのへんキッチリ書いてあるのかもしれないが理解できん)

まったくの推測だが、これはむしろ「バイオリンをひたすら練習したからよく眠れる」という因果関係を示すものじゃないかと思うんだな。

時間の分子生物学 (講談社現代新書)
という、タイトルからはちょっと推測できない睡眠に関する面白い本がある。
こちらによれば、眠りというのは、疲れることで受動的に引き起こされる生理現象だと言う。

つまり、上手なバイオリニストは、毎日毎日ハードな練習をしており、そのためによく眠れるということじゃあないだろうか。

じゃあ年寄りの睡眠が短いのは?
もちろん加齢による脳組織の萎縮もあろうが、経験が蓄積されているせいで反射だけで過ごす時間が多くなり、脳に十分な負荷を与えていないせいじゃないだろうか?
非日常や不確実性を嫌い、ルーチンばかりの毎日を送りがちなせいじゃないだろうか?

といったような事を考えたのであった。
しょせん根拠もない世迷いごとなんだけれども、年取っても驚き泣き笑い怒り、もしそれで夜はよく寝れるなら、それはそれでいいじゃないか。
海馬も休まるしな。

photo credit: 55Laney69 via photopin cc

No tags for this post.

[telecom] 携帯電話での音声通話は高くなるのかしらん

Pocket

数日前、こんなニュースが見かけて個人として思ったことをつらつらと書く。

音声電話の死: 携帯電話での通話、50%減

Vodafone が調べたところによると、彼らの市場(おそらくヨーロッパ圏)で音声通話の平均時間はこの5年で半減し、たかだか1分40秒程度になったとのこと。

別の調査会社も、去年、同様の報告をしている。

減る音声通話: テキストメッセージのトレンドをOfcomが示す

二つの記事が示すのは、成熟した携帯電話市場では、人々は音声通話よりもSMS, SNS, IMなどに移るということ。
それは単にインターネット接続が一般的になり、代替手段が増えただけのことと言ってしまえばそうだろう。

言うまでもなく「電話」は双方が同時に参加しなければならない。双方ともに負担のある通信手段である。
特に時間に制限のある状況で、扱う話題のプライオリティが双方で異なるのに電話を使ったりすると、一方はとてもストレスを感じる。
誰しも「そんな用件で電話かけてくるんじゃねえ。こっちは忙しいんだ」と感じたことはあるはずだ。電話に出て用件を聞くまでプライオリティは分からないし。
それだけに不要不急の通信はメッセージングサービスに移っていくのは自然とも思う。

一方で、例えば緊急時の安否確認をする場合、プライオリティの事前共有が済んでいる場合、あるいは通信内容に意味はなく、単に時間を共有したい場合など、電話は比率を下げながらも使われていくはずだ。

上記の話を踏まえて携帯電話キャリアの話になるのだが、実は彼らにとって電話のような「同期サービス」と、メッセージングサービスのような「非同期サービス」を同時に提供しなければいけないのはとても悩ましい問題だ。

ご存知の通りここ何年か、データ通信が爆発的に増加している。
それを捌くために、各社ともLTEに移行していて、さらにはできるだけ周波数を割り当てたい。となれば邪魔なのは3Gだ。
が、電話のニーズがある以上、すぐには撤去できない。

なぜか?
LTEは大量のデータを短期間で送ることを想定して作られている(データ通信の発生したユーザに一時的に広い帯域を割り当てさっさと終わらせる)。
音声のような、ほそぼそとしたデータを送ることには向いていないのだ。(なお、同じ理由でM2Mのような、ごく少量のデータを大量の端末で扱うパターンも苦手)

だからVoLTEとして根本的な仕様から標準化を進めている。
じゃあそれをさっさと導入する?
しかしVoLTEにはまだまだ制限がたくさんある。110, 119などの緊急呼の扱いもそうだし、一番のネックは端末のバッテリーを急速に消費すること。とてもすぐには導入できない。

というわけで、しばらく電話は3Gを使ってもらうしかないだろう。ただしユーザは高い通話料金を請求されるかもしれない。
だって3G設備は古くなるし、保守費もかかる。電話の使用がダウントレンドなら、キャリアは今さら追い金も払えないから。

いやなら少々品質が悪くてもSkype, Facetime、LINE、WhatsAppなどのOTT音声サービスを使え、ということになるのかも。
でも、youtubeが賑わっているところをみると、ほとんどのユーザはそれで十分なのかもしれない。

 

No tags for this post.