【最新ITトピック】 Red Hat、オープンソース事業で通期売り上げを11億ドル超に

Red Hat社の第4四半期売り上げが、 $297 million　となり、通年で$1.13 billion、と、11億ドル超の売り上げとなりました。

japan.internet.com: 米 Red Hat、OSS Linux でついに11億ドル超を稼ぐ

売り上げの多くがSubscriptionによるものですが,内訳としては、JBoss Enterpise SOA Platformなどのミドルウェア事業の占める割合が大きくなっています。
今後はクラウド事業への軸足も強化しており、Linuxを基盤にはしていても、軸足の向きはOSSを基盤にしたビジネスソリューションに向いています。
いや、今更書かなくても、と思われる方の方が多いとは思いますが。

ウィルキンソンジンジャーエールPET、今度は大丈夫(いや何が？）

昨日この件を書くのをすっかり忘れていました。

ついに解禁『ウィルキンソン ジンジャエール』PETで新発売！

これで、リターナル瓶の処理に困ることもありません。
近くのコンビニで買えるので、早速試しましたが、今回は大丈夫(だから何が、と)で、早速箱買いに走った猛者もいるようです。

なぜにウィルキンソンジンジャーエール?　と思われる方も多いと思います。
実は、昔ぷらっとホームの店舗にはウィルキンソンジンジャーエール(無印瓶)が常備されていました。
それは建前上は「自分が飲むため」で、定期的に秋葉原の赤塚酒店より配達されていました。
ただ、限りなくフリーアクセスに近い形で置いてあり、料金箱にお金さえ入れて置けば勝手に飲めるようになっていました。
ウィルキンソンジンジャーエールだけ飲みに来た、という人もいたはず。

ちなみに、商品の仕入れとして買うわけではないので、購入価格のまま、としていましたが、次の配達で支払い分に足りない、ということは一度もありませんでした。
ひと昔ほど前の、良き秋葉原時代の思い出です。

【最新ITトピック】 IPA、ファジングによる脆弱性検出の有効性の実証結果を公開

ソフトウェア製品などに何万種類もの問題を起こしそうなデータ（例：極端に長い文字列）を送り込み、ソフトウェア製品の動作状態（例：製品が異常終了する）から脆弱性を発見する技術、ファジングについて、IPAがその有効性の実証と、普及の促進を目的とした「脆弱性検出の普及活動」を開始しました。

IPA プレス発表: ファジングによる脆弱性検出の有効性の実証結果の公開 ～「ファジング活用の手引き」を活用し、ソフトウェア開発にファジングの導入を～

今後のソフトウェアリリース/管理に向けて欠かせない技術と言えるでしょう。

【最新ITトピック】 How Emacs changed my life

今年のFSF Award for the Advancement of Free Softwareは、Rubyの生みの親、まつもとゆきひろさんが受賞されました。アジア人としても初、とのこと。
受賞式での発表のスライドが公開されています。非常にシンプルですが、それだけに思いを強く感じます。

How Emacs changed my life

小野秀貴: Open vSwitch によるOpenFlow の利用

◆OpenFlow/Open vSwitchとは

OpenFlowは、1台のOpenFlowコントローラで複数のOpenFlowスイッチを制御する
仕組みです。OpenFlowスイッチは転送機能を提供します。OpenFlowコントロー
ラは経路制御をまとめて行います。OpenFlowスイッチは必要に応じて経路情報
をOpenFlowコントローラに問い合わせる形となります。OpenFlowコントローラ
とOpenFlowスイッチ間はOpenFlowプロトコルで通信が行われます。

Open vSwitchはオープンソースの仮想ソフトウェアスイッチで、XenServer,
KVM, VirtualBoxなどの仮想化プラットフォームでも使用されています。
Open vSwitchは仮想化プラットフォームと組み合わせなくても普通のLinux上で
動作可能です。Linux上で動作させる場合はユーザ空間でのパケット転送処理の
他にカーネルモジュールを利用して高速にパケット転送処理を行うことも可能
です。
またOpen vSwitchは設定によりOpenFlowに対応したOpenFlowスイッチとしての
動作も可能となっています。




◆動向/必要性

OpenFlow 1.0仕様は2009年12月、OpenFlow 1.1仕様は2011年2月にそれぞれリリー
スされました。2011年12月にIPv6のサポートなどが追加されたOpenFlow 1.2仕
様がONF(Open Networking Foundation)で承認されました。1.2はまだ出たばか
りなので現状では1.0/1.1が主流となっています。
OpenFlowは技術的には比較的新しく、またセキュリティ上の懸念なども議論さ
れていたりなどまだ実用段階には至っていません。一方、集中制御できること
から大規模データセンターなどでの利用が期待されています。

このようにOpenFlowは大規模データセンターなどをおもなターゲットとして検
討されているようですが、L2〜L4の情報に基いて細かい制御が可能ということ
で比較的小規模のネットワーク環境で効果的に使える可能性も考えられます。

Open vSwitchではバージョン1.4.0(2012年1月リリース)でOpenFlow 1.0
に加え、OpenFlow 1.1/1.2の一部の機能(IPv6など)に対応しています。



◆Open vSwitch導入

OpenBlockS 600DにOpen vSwitchを導入してみます。

まずはOpenBlockS 600Dでセルフ開発環境を整えます。
今回は、ファームウェア、および開発環境として以下を用いました。

 ftp://ftp.plathome.co.jp/pub/OBS600/debian/files/squeeze/2.6.29-4/uImage.initrd.squeeze
 ftp://ftp.plathome.co.jp/pub/OBS600/debian/files/squeeze/obs600d_squeeze_develop_edition_20110726.tgz

パッケージはaptitude upgradeで2012年2月21日時点での最新版にしました。

 # aptitude update
 # aptitude safe-upgrade

またopenvswitchコンパイルのための準備としてlibssl-dev, pkg-configパッケー
ジを追加しました。

 # aptitude install libssl-dev pkg-config

openvswitchでは、転送処理をカーネル(モジュール)で行う方法とユーザランド
で行う方法の2通りがありコンパイル時に選択します。今回は準備が多少面倒で
すが性能が出るであろう前者のカーネルモジュールを選択することにします。

カーネルモジュールを作成するためにモジュール生成のための環境が必要とな
るので、まずはその準備をします。

開発環境でカーネルのソースはすでに入っていますが、最新のファームと同じ
環境にするために、最新ファーム用のカーネルソースを取得します。

 # cd /usr/src
 # wget ftp://ftp.plathome.co.jp/pub/OBS600/debian/linux/linux-2.6.29-20111128-00.tgz
 # mv linux-2.6.29 linux-2.6.29.old
 # tar xvf linux-2.6.29-20111128-00.tgz

モジュール生成時にはautoconf.h等が必要になるためその準備をします。今回
はモジュールシンボル(Module.symvers)も生成したかったのでmake modulesま
で行いました。make vmlinux modulesは数時間を要します。確認はしていませ
んがmake prepareまで行えばopenvswitchはコンパイル可能かもしれません。

 # cd /usr/src/linux
 # wget -O /usr/src/linux/.config ftp://ftp.plathome.co.jp/pub/OBS600/debian/files/lenny/LATEST/dot.config
 # cd /usr/src/linux/include
 # rm asm
 # ln -s /usr/src/linux/arch/powerpc/include/asm .
 # make oldconfig
 # make prepare
 # make vmlinux modules

さて、これで準備は整ったのでようやくopenvswitchソフトウェアのコンパイル
にうつります。まずは2012年2月21日時点での最新版(1.4.0)のソースを取得し
展開します。

 # wget http://openvswitch.org/releases/openvswitch-1.4.0.tar.gz
 # tar zxvf openvswitch-1.4.0.tar.gz

powerpcではオリジナルのままだと一ヶ所だけ関数未定義でコンパイルを通らな
い箇所があるため以下の修正を加えました。

--- datapath/tunnel.c.orig    2012-01-31 16:08:18.000000000 +0900
+++ datapath/tunnel.c        2012-02-22 17:53:23.000000000 +0900
@@ -38,6 +38,7 @@
 #include <net/ip.h>
 #if defined(CONFIG_IPV6) || defined(CONFIG_IPV6_MODULE)
 #include <net/ipv6.h>
+#include <net/ip6_checksum.h>
 #endif
 #include <net/route.h>
 #include <net/xfrm.h>

次にopenvswitchのmakeを行う。

 # cd openvswitch-1.4.0
 # ./configure --with-linux=/lib/modules/`uname -r`/build
 # make

makeが問題なく通ったらmake installを行います。デフォルトでは/usr/local
以下にインストールされます。さらに作成したモジュールをinsmodします。

 # make install
 # insmod datapath/linux/openvswitch_mod.ko

特にエラーメッセージ等が出なければ準備完了となります。




◆構成と設定ファイル初期化

openvswitchの構成は以下の図のようになります。

各種設定は設定用のデータベースで管理されます。データベースへのアクセス

はデータベースアクセス用デーモン(ovsdb-server) を通してアクセスされます。

その他のツールはovsdb-serverと通信して動作を行います。今回はunix domain
socketを用いる設定にしました。
ovs-vswitchdはスイッチのデータパスの設定等を行うメインのデーモンです。
ovs-vsctlはスイッチ関連の各種設定を行うコマンドです。

まずは、初期化を行います。
設定ファイル用のディレクトリを作成し、データベースを新たに作成します。
データベースはovsdb-toolコマンドを用いて生成します。

 # mkdir -p /usr/local/etc/openvswitch
 # ovsdb-tool create /usr/local/etc/openvswitch/conf.db vswitchd/vswitch.ovsschema
 Feb 22 09:50:54|00001|lockfile|INFO|/usr/local/etc/openvswitch/.conf.db.~lock~: lock file does not exist, creating

次にデータベースを操作するためのサーバを起動します。
データベースサーバへはunix domain socket(db.sock)を通してアクセスします。

 # ovsdb-server --remote=punix:/usr/local/var/run/openvswitch/db.sock \
                     --remote=db:Open_vSwitch,manager_options \
                     --private-key=db:SSL,private_key \
                     --certificate=db:SSL,certificate \
                     --bootstrap-ca-cert=db:SSL,ca_cert \
                     --pidfile --detach

ovs-vsctlコマンドでデータベースの初期化を行います。

 # ovs-vsctl --no-wait init

open vswitchのメインサーバ ovs-vswitchdを起動します。

 # ovs-vswitchd --pidfile --detach
 Feb 22 09:54:27|00001|reconnect|INFO|unix:/usr/local/var/run/openvswitch/db.sock: connecting...
 Feb 22 09:54:27|00002|reconnect|INFO|unix:/usr/local/var/run/openvswitch/db.sock: connected

◆Open vSwitch基本動作確認

最も単純なeth0, eth1 をブリッジさせる動作を確認します。

まずはブリッジデバイスを作成します。

 # ovs-vsctl add-br br0
 device br0 entered promiscuous mode

 # ifconfig br0
 br0       Link encap:Ethernet  HWaddr fe:b2:9d:a2:84:45 
           BROADCAST MULTICAST  MTU:1500  Metric:1
           RX packets:0 errors:0 dropped:0 overruns:0 frame:0
           TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
           collisions:0 txqueuelen:0
           RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

次に、eth0, eth1 をこのブリッジのポートして追加します。

 # ovs-vsctl add-port br0 eth0
 device eth0 entered promiscuous mode
 # ovs-vsctl add-port br0 eth1
 device eth1 entered promiscuous mode

br0をupするとブリッジ動作を行うようになります。

 # ifconfig br0 up

ovs-vsctlコマンドでブリッジの情報を確認できます。

 # ovs-vsctl show
 a54365a7-c6a5-43b0-b920-bf56e53f37f5
    Bridge "br0"
        Port "eth1"
            Interface "eth1"
        Port "br0"
            Interface "br0"
                type: internal
        Port "eth0"
            Interface "eth0"

なお、注意点としてopenvswitchを導入したマシンでsshなどのIP通信を行うに
は、eth0, eth1ではなくbr0にIPアドレスをふる必要があります。
試しにDHCPでアドレスをふってみます。

 # dhclient br0
 # ifconfig br0
 br0       Link encap:Ethernet  HWaddr 00:0a:85:04:15:5f 
           inet addr:192.168.100.211  Bcast:192.168.100.255  Mask:255.255.255.0
           inet6 addr: fe80::20a:85ff:fe04:155f/64 Scope:Link
           UP BROADCAST RUNNING ALLMULTI MULTICAST  MTU:1500  Metric:1
           RX packets:833632 errors:0 dropped:0 overruns:0 frame:0
           TX packets:52700 errors:0 dropped:0 overruns:0 carrier:0
           collisions:0 txqueuelen:0
           RX bytes:90350673 (86.1 MiB)  TX bytes:18998763 (18.1 MiB)

動作確認のため3台のOpenBlockS 600D（OBS600D）を用いて以下のネットワークを構成しました。
obs600-3は上記でopenvswitchを導入済のマシンです。

openvswitchのブリッジが動作をしているかをobs600-1からobs600-2へのpingで
確認します。

 obs600-1# ping 192.168.100.219
 PING 192.168.100.219 (192.168.100.219) 56(84) bytes of data.
 64 bytes from 192.168.100.219: icmp_req=1 ttl=64 time=116 ms
 64 bytes from 192.168.100.219: icmp_req=2 ttl=64 time=0.366 ms
 64 bytes from 192.168.100.219: icmp_req=3 ttl=64 time=0.307 ms
 64 bytes from 192.168.100.219: icmp_req=4 ttl=64 time=0.368 ms

openvswitchでは一方向のデータパスのテーブルをもとにスイッチングを行って
います。データパスの情報を確認するにはovs-dpctlを用います。

 # ovs-dpctl show
 system@br0:
    lookups: hit:2284446 missed:151252 lost:86
    flows: 6
    port 0: br0 (internal)
    port 1: eth0
    port 2: eth1

br0のデータパスを確認してみます。

 # ovs-dpctl dump-flows br0 |grep 192.168.100.123
 in_port(2),eth(src=00:0a:85:04:93:99,dst=ff:ff:ff:ff:ff:ff),eth_type(0x0806),arp(sip=192.168.100.123,tip=192.168.100.219,op=1,sha=00:0a:85:04:93:99,tha=00:00:00:00:00:00), packets:0, bytes:0, used:never, actions:0,1
 in_port(1),eth(src=00:0a:85:04:15:5e,dst=00:0a:85:04:93:99),eth_type(0x0800),ipv4(src=192.168.100.219,dst=192.168.100.123,proto=1,tos=0,ttl=64,frag=no),icmp(type=0,code=0), packets:4, bytes:392, used:0.145s, actions:2
 in_port(1),eth(src=00:0a:85:04:15:5e,dst=00:0a:85:04:93:99),eth_type(0x0806),arp(sip=192.168.100.219,tip=192.168.100.123,op=2,sha=00:0a:85:04:15:5e,tha=00:0a:85:04:93:99), packets:0, bytes:0, used:never, actions:2
 in_port(2),eth(src=00:0a:85:04:93:99,dst=00:0a:85:04:15:5e),eth_type(0x0800),ipv4(src=192.168.100.123,dst=192.168.100.219,proto=1,tos=0,ttl=64,frag=no),icmp(type=8,code=0), packets:4, bytes:392, used:0.145s, actions:1

eth1側からの入力はin_port(2)に対応し、arpおよびICMP echo request
(type=8)のデータパスが確認できます。actions:1は出力ポートが1(=eth0)
となっています。arpはactions:0,1となっていますが、ブロードキャスト
の場合は自分自身用にport 0(=br0) へも出力していることが確認できます。

なお、このデータパスは最大256個となっています。使用されなくなったら数秒
で消えてしまうようです。





◆Open vSwitch性能測定

OpenBlockS 600Dでopenvswitchをカーネルモードで利用した場合の性能を測定してみます。
今回は機材の関係上、obs600-1 <--> obs600-2 間のTCP転送性能を測定します。
測定にはnuttcpを用いました。
まずobs600-2でnuttcpをサーバモードで起動します。

 obs600-2# nuttcp -S

そして、obs600-1ではクライアントモードで起動し、10秒間測定します。

 obs600-1# nuttcp -i1 -T10 192.168.111.219

比較のため、まずはopenvswitchなしの場合で、obs600-1, obs600-2 間を測定
します。ネットワーク図は以下のとおりです。
なお、obs600-1, obs600-2のeth0をmtu 1500にした場合と mtu 9000の場合と2

パターンで測定しました。

なお、今回はカーネルパラメータなどのチューニングは行っていません。

         

結果

mtu 1500
  224.1250 MB /  10.02 sec =  187.6814 Mbps 41 %TX 99 %RX 0 retrans 0.44 msRTT

mtu 9000
  322.0000 MB /  10.02 sec =  269.6913 Mbps 48 %TX 99 %RX 0 retrans 0.46 msRTT

次にopenvswitchを間に挟んで同様の測定を行いました。
ネットワーク図は以下になります。mtu 1500, mtu 9000の2パターンで測定を行

いましたが、この際openvswitchのmtu(br0,eth0,eth1)も同一にしました。

 

結果

mtu 1500
  209.5625 MB /  10.03 sec =  175.2363 Mbps 40 %TX 98 %RX 0 retrans 1.56 msRTT

mtu 9000
  324.0000 MB /  10.01 sec =  271.3858 Mbps 43 %TX 99 %RX 0 retrans 1.53 msRTT

測定結果を比較すると明白に違いはみられません。
今回の測定では末端のOpenBlockS 600Dの性能がボトルネックとなってしまい、上限の正確な
値は確認できていませんが、すくなくとも、

 mtu 1500では 170 Mbps

 mtu 9000では 270 Mbps

程度の性能は出ることが確認できました。



◆OpenFlow風にOpen vSwitchをコントロール

Open vSwitchではovs-vsctl set-controllerコマンドによりOpenFlowコントロー
ラに接続してコントーラからフロー設定できるようになります。
今回はその前段階としてOpenFlowコントローラは使用せずに、ovs-ofctlコマン
ドを用いることで直接Open vSwitch上のフロー情報を書き換えて動作を確認し
ます。

今回の実験は、マルチホーム環境でopenvswitchの配下にあるクライアントから
の上流へのアクセス時に、特定のTCPポート(今回はSMTP=25)の通信だけ異なる
router を経由するように変更します。
このとき、routerやclientの設定は一切変更せずにopenvswitchの操作だけで上
記制御を行います。

今回使用したネットワーク構成は以下のようになります。

obs600-1ではデフォルトルートは192.168.100.1(router-1)となっていて、
通常の外部への通信はISP 1側を通して行います。

 obs600-1# ip route
 192.168.100.0/24 dev eth1  proto kernel  scope link  src 192.168.100.123
 default via 192.168.100.1 dev eth1

初期状態でのopenvswitchのフローを確認します。

 # ovs-ofctl dump-flows br0
 NXST_FLOW reply (xid=0x4):
  cookie=0x0, duration=40.911s, table=0, n_packets=404, n_bytes=70012, priority=0 actions=NORMAL

actions=NORMALとなっているひとつのエントリが存在します。任意のパケット
はこのエントリにマッチして通常のブリッジ動作を行う。

次に新たなエントリを追加します。
宛先MACアドレスがrouter-1でTCP宛先ポートが25の場合のみ、宛先MACアドレス
を強制的にrouter-2に向かうように変更します。
これを行うにはovs-ofctl add-flowでフローを追加します。

 # ovs-ofctl add-flow br0 'priority=100,in_port=2,dl_dst=00:00:00:00:00:01,tcp,tp_dst=25, actions=mod_dl_dst:00:00:00:00:00:02,output:1'

priority=100を指定することで、条件にマッチする場合このエントリが優先さ
れます。in_port=2(eth1)から入力したパケットはmod_dl_dstにより宛先MACア
ドレスを変更してoutput:1でPort 1(eth0)に出力されます。

再びovs-ofctl dump-flowsでフローを確認します。

 # ovs-ofctl dump-flows br0
 NXST_FLOW reply (xid=0x4):
  cookie=0x0, duration=1171.997s, table=0, n_packets=0, n_bytes=0, priority=100,tcp,in_port=2,dl_dst=00:00:00:00:00:01,tp_dst=25 actions=mod_dl_dst:00:00:00:00:00:02,output:1
  cookie=0x0, duration=1304.627s, table=0, n_packets=2753, n_bytes=347468, priority=0 actions=NORMAL

openvswitch配下のクライアント(obs600-1)で実際に外部SMTPサーバに接続をしてみます。

 obs600-1# telnet smtp.example.org 25
 Connected to smtp.example.org.
 Escape character is '^]'.
 220 smtp.example.org. ESMTP Postfix

このとき外部サーバでアクセスログを確認すると、ISP-2経由でアクセスされて
いることが確認できます。
WWWサーバ(Port 80)へも同様に接続してみます。

 obs600-1# telnet www.example.org 80
 Connected to www.example.org.
 Escape character is '^]'.

外部サーバで同様にアクセスログを確認すると、ISP-1経由のアクセスであるこ
とが確認できます。

これにより当初の目的が達成できました。

このときのOpen vSwitch上でのデータパスも確認してみます。

 # ovs-dpctl dump-flows br0
  - 省略 -
 in_port(2),eth(src=00:0a:85:04:93:99,dst=00:00:00:00:00:01),eth_type(0x0800),ipv4(src=192.168.111.123,dst=175.41.248.246,proto=6,tos=0x10,ttl=64,frag=no),tcp(src=45737,dst=25), packets:3, bytes:206, used:0.645s, actions:set(eth(src=00:0a:85:04:93:99,dst=00:00:00:00:00:02)),1
  - 省略 -

 # ovs-dpctl dump-flows br0
  - 省略 -
 in_port(2),eth(src=00:0a:85:04:93:99,dst=00:00:00:00:00:01),eth_type(0x0800),ipv4(src=192.168.111.123,dst=175.41.248.246,proto=6,tos=0x10,ttl=64,frag=no),tcp(src=35688,dst=80), packets:0, bytes:0, used:never, actions:1
  - 省略 -

dst=80の場合はactions:1に対して、dst=25の場合はMACアドレスが変更
されていることが確認できます。



◆まとめ

今回はOpenFlowに対応した仮想スイッチOpen vSwitchをOpenBlockS 600D上に導入し実際
の動作確認を行いました。転送処理はカーネルモードで行うようにビルドを行
いました。

Open vSwitchをブリッジとして動作するように設定しOpen vSwitch の各種デー
モンやコマンドを使い動作確認を行いました。

OpenBlockS 600D上でのOpen vSwitchの転送性能を測定したところ、最低でも

 mtu 1500では 170 Mbps
 mtu 9000では 270 Mbps

程度はでそうなことが確認できました。

Open vSwitch上でフローを設定することで、特定のフローについての
動作を変更できることを確認しました。実際にはTCP宛先ポート25(=smtp)
のパケットを異なるルータに転送するという例を実現しました。

以上で今回目的としていたことは一通り確認できました。

さくらクラウドに何が起こっているのか？

シンプルで自由度が高く、そして圧倒的なコストパフォーマンスを売りにした、国産のIaaS型パブリッククラウド、さくらクラウドが、今回、抜本的なシステムの構築を行うとともに、システムの安定稼動を確認するまではサービスを無償提供すると発表しました。

さくらのクラウドの現状報告および課金対応について

現状の障害報告を見る限り、ストレージ回りのパフォーマンス低下により、頻繁に負荷が増大する状況のようです。
個人的に、さくらクラウドのシステムを把握していない、という前置きをしたうえで、考えられることは、システムの再起動後のキャッシュクリアにより、しばらくの間パフォーマンスが出ないことからも、クラウドの根幹になるDBのパフォーマンスが、memcashdあたりに大きく依存しているのではないかと思われます。
そして、当面はディスクの競合処理のロックのタイムアウト時間を大幅に緩和したファームウェアにより対処する、と。
ただ、ディスク回りのパフォーマンスの見直しがシステム全体のパフォーマンスを考えると重要なファクターだとは思うのですが、それと同時に、クラウドの分散DB自体を見直す必要があるのかもしれません。

【最新ITトピック】H.264、残るはgoogleの決断だけに

MizillaがH.264サポートに転向し、webMへの一本化を断念しました。

Engadget Japanese: Mozilla が H.264 をサポートへ、webM 一本化を断念

オープンフォーマットではない、という事を理由に、デファクトスタンダードともいえるH.264をサポートしない、という判断には、おそらく企業や団体のポリシーや方針なのだとは思いますが、そのポリシーとて、つまりは、ユーザの利便性あってこそでしょう。
今回も、MozillaはFlashがあればそのポリシーに関しては保たれ、事実上のダブルスタンダードでやり過ごすつもりが、adobeの方針転換によって目論見が崩れた、というところでしょうか。

【最新ITトピック】Facebookの台頭によってmixiの立ち位置はより明確に

Facebookが絶好調なため、どうしても国産SNSのmixiと比較されてしまいますが、そもそも比較する対象なのでしょうか？

INTERNET Watch: Facebookの月間ユーザー数は1000万人、年内にもmixiを抜き去るか

Facebookはソーシャルメディアとして認識したほうがよく、友達同士で何かを共有するための手段ではなく、社会における自身の繋がりや立ち位置での発言を共有する手段でしょう。
友達は少なくとも、シェアにより容易に拡散され、身内での話はよほど細かく制御しなければ機能しません。そもそも、Facebookの友達のレイヤを細かく調整するなら、Facebookではなく別の手段を使うべきでしょう。
アゴラに以下のようなblog記事がありました。

アゴラ: 今ではmixiがTwitterよりFacebookより奇妙なことに使いやすい

個人的にも、自分の社会に対する公式な見解や、自分を取り繕ってアピールする部分はFacebookのTLに置いて行きますが、本音や趣味の話、毎日の取りとめのない報告はmixi日記に書きます。
正直、Facebookの自分は、繋がりも含め右でも左でもなく、今回の震災に関連する立場に関しても、あえて曖昧にしています。仕事がら無駄な敵を作ることは出来ませんし、実名である以上所属する組織に迷惑もかけられません。
上の記事でも書かれている通り、mixiのコミュニティは事実上機能していませんし、スマホアプリも使いにくい上に仕様変更も多いわけですが、その程ほどにクローズな部分が丁度いいわけです。

Facebookがこういった部分を吸収できるか、というと、すでに友達という構造が違い過ぎて難しい。
その上、情報の流れる速度があまりにも速いために、mixiのような日記ベースの速度には戻れないと思います。

【最新ITトピック】Cisco ルータとの拠点間 VPN 相互接続を実現したPacketiX VPN の IPsec 対応ベータ 2 を公開 L2TPv3 over IPsec に対応し、Cisco および SEIL との接続が可能に

レイヤ2/3 VPNソフトウェア製品である、PacketiX VPN ServerのIPsecサーバーとして動作するベータ版が、ベータ2において、「L2TPv3」 (国際標準規格: RFC3931)に対応すると発表されました。

ソフトイーサ: Cisco ルータとの拠点間 VPN 相互接続を実現したPacketiX VPN の IPsec 対応ベータ 2 を公開

この機能は本日よりベータ 2 として無償でダウンロード提供を開始し、 2012 年 11 月 30 日まで利用可能。日本語版・中国語 (簡体字) 版の 2 カ国語で提供されています。

L2TPv3 over IPsec (RFC3931) に対応した VPN ルータとの相互接続を可能とし、ソフトイーサ社では、
    ・Cisco Systems 社製 Cisco ルータ (2005 年以降に発売された L2TPv3 対応のもの)
    ・IIJ 社製 SEIL ルータ (L2TPv3 対応のもの)
との接続が可能な事を確認されており、Point-to-Multipointに対応した上位Cisco製品に代わり、PacketiX VPN Serverによる複数拠点とのVPN接続を可能としています。

なお、本機能は、次回リリース版の製品版 PacketiX VPN Server に正式な機能として組み込まれるほか、オープンソース版 UT-VPN にも搭載され、無料で利用可能になるとともに、開発部分のソースコードも公開も予定されています。

【最新ITトピック】PCがなくなる、という言葉への違和感

Windows8のリリース情報にあわせ、PC時代の終焉を匂わす記事が増えています。

日経ビジネスオンライン: MSが新OS、タブレット照準

モバイル端末がタブレットやスマートファオンに取って代わられ、その流れがPCを飲み込み始めている、というのは分かります。
しかし、オフィス業務では、描画以外の場所でタッチインタフェースが便利かと言えば、必ずしもそうはなりません。
タッチインタフェースは、閲覧という意味では非常に便利ではありますが、入力、機能の変更などを頻繁に行う操作には、機能が足りないからです。
簡便なるインタフェースで多数の仕事をこなす事、それは、意味理解を含めたトータルな計算機の進歩が必要であり、Siri一つ満足に動いていないこの状況ではまだまだ人間のオペレーションより勝るものがあるとは思えません。
結果的に、閲覧や、簡単なメッセージ交換を中心とした、パーソナルな用途はタブレット型の装置が適しているというだけ、というのが現状です。
MSがOSを統合させる、ということは、モバイル端末のハードウェアスペックの向上により、モバイル端末と従来のPC向けのOSコアを分ける必要がないというだけの話であり、そういった実装方針への取り組みをWindows8から取るということでしょう。

ただ、PCという言葉を否定するなら、昔のWorkstationという言葉に戻ればいいのではないでしょうか。

【最新ITトピック】 メディア報道における、富士通研究所発表によるビッグデータ通信量100分の1の意味

これは、富士通の発表が悪いのではなく、メディアの受け取り方が悪いのではないかと思います。

RBBTODAY:爆発的に増加するM2Mデータを分散処理……データ量を100分の1に！富士通研究所が発表

つまりは、「インテリジェントソサエティ」によりローカルモニタリングを強化するとデータが増えるからローカルで解析して、解析した結果だけクラウドに上げます。その時のデータ量が元データの1/100になるということです。

しかしながら、スマートグリッドとセンサネットワークにより、何万人もの人を監視するというシチュエーション自体が現実的なのでしょうか。
例えば、電源ならば、部門での導入機材からおおよその電力消費は予想できるため、毎月の積算電力で結果をモニタリングすれば足る事。
ヒューマンセンシングにしても、毎日の行動をモニタリングすることは必要以上のプライバシーの侵害になるし、そもそもただでさえ過負荷ともいえる情報社会においては精神的ストレスの元となるのは明らかです。
もちろん、警備や管理などの一人作業者のモニタリングなど、必要な場所はあります。
しかし、ビッグデータとなるような規模での導入は考えにくいのです。

それ以前に、ICTというのは、会社の業務フローをなぞって設計されるものであり、元々の主体は人。その業務フローを計算機を使って作業効率を如何に上げるかということであり、全く利に適っていることです。元々人を中心にICTは作られているのです。
そのため、今になってわざわざ主客逆転というのは言い過ぎで、ヒューマンセントリックはあくまでアシスタンスのためのシステムではないかと思うのですが、どうでしょうか。

【最新ITトピック】DELL、SonicWallを買収

DELLが、UTMやSSL-VPN製品を始めとしたセキュリティアプライアンス製品を手がけるSonicWall社を買収すると発表しました。

Dell Announces Intent to Acquire SonicWALL, Inc.

クラウド化を中心とした流れの中で、エッジ側のネットワーク環境までも含むトータルなソリューション展開をしていく、ということは規定路線とも思えます。

【最新ITトピック】米ヤフー、Facebookを特許侵害を提訴して得られるもの

米国Yahooが上場を狙い済ましたかのように特許侵害による提訴に踏み切りました。 

Yahoo! ニュース: 米ヤフー、Facebookを特許侵害で提訴

Yahooがもつビジネス特許は膨大なものです。しかしながら、表立ってそれを振りかざした場合、デメリットもあります。
Yahooの新経営陣はそれでも利益を取ったということは、とにかく実績を作って、自分の報酬を正当化しようとしているのでしょうか。
それとも、保有特許に対するFreerideをどこまで許すのか、ということに、一定の線引きをしたいと思っているのでしょうか。
個人的には、Web全体のシステムで共用すべき実装というものがある以上、それは共通化され、お互いそれを主張しない、という方が前向きだと思いますし、もしそれを強固に主張すれば、敵を増やし、別の実装に取って代わられてビジネス的に阻害される要因になるのではないでしょうか。

【最新ITトピック】 Androidマーケットを巡るビジネス判断

先ごろから、Androidに関しての悪い話が続いていますが、これはどうなのでしょうか。
 
ITmedia: 「Androidはもうからない」――人気ゲームメーカーが開発終了を発表: ITmedia

撤退するにはいくつかの理由があると思いますが、Android向けのアプリケーション開発は、OSのバージョンの違い、スペックの違いなど、機種毎に調整する項目が多すぎて、手間がかかること、一般的に言われていることですが、App Storeのユーザと違い、Androidマーケットのユーザはあまり有料アプリにお金を払わないことなどがあります。
そして、そのような開発環境上の不備があるにも関らず、ここに来て3D対応などに伴うアプリサイズの上限変更など、F1でいうところのレギュレーションの上方修正をしてきた、と。
他のゲームコンソールでもあったスペックのインフレには体力的に対応できないという話。
ただ、単純にAndoroidだけの話だとは思いません。モバイル端末向けアプリも別のステージに立たされているだけの話だと思います。

【最新ITトピック】軽量化Linuxとモバイルデバイスは今

Linux Mintの軽量版、LXDEがリリースされました。

SOURCEFORGE.JP: USBメモリからのブートにも対応、ネットブック向け軽量OS「Linux Mint 12 LXDE」登場:

Linux MintはUbuntuをベースにしていても、現実的な路線でUbuntu本体からの移行組を多数抱える人気のディストリビューション。
ネットブック向けに対しても、最低スペックが256MBメモリ、3GB以上のストレージと、軽量化と利便性を兼ね備えたものとなっています。
ただ、ネットブックがAtom CPUを中心に普及した時代とは違い、モバイル端末は、iPadやAndroidベースのタブレットPCを中心としており、ノートPCもFusion等の新しいコアにより、高性能かつ低価格化しているという側面はあります。
以前のAtomベースのEeePCの様なレンジを狙っているとしたら少しターゲットがぶれているかもしれません。
例えば、Windows XPのサポート終了後の我がEeePC901には丁度いいのですが、その頃までEeePCを使い続けるなら、おそらく2度目のバッテリ交換をすることになります。
結果として、交換よりは新しい端末に乗り換える、という判断が多くなるのではないでしょうか。

jobs みんなを強引に、しかし巧妙に引っ張るジャイアン

株価が高値を更新し続けるApple、それを捕らえて、SonyやPanasonicがAppleになれない、という話が多いのですが、個人的には、

404 Blog Not Found: 実は誰もが知っている「AppleがSonyになれた本当の理由」


こちらのblogよりです。
偉い人たちは、方法論として、どうすれば、売れるものが作れるかという話を唱えられますが、それより、時代や環境で、個人の能力は生かされたり殺されたりします。
昔はあれですよ、電灯のソケットを2又にしただけとか、海外から新しい技術もってきて小さな装置作っただけで、パトロンもつき、商品も売れたわけですよ。当然、そのあとには販路を作ったりとかの商才が関係してくるのですが、商品そのものの立ち上げってもっとシンプルでした。
しかし、今の時代、個人に物を売ることを徹底して考え商品と利用環境を作る、というのは、当たり前に出来るようで、なかなか難しいと思います。
個人的にはjobsってこうなんだろうな、というネタを少し前にFBのノートに書いていたので転載しておきます。

--
jobs みんなを強引に、しかし巧妙に引っ張るジャイアン

ちょっと他のウォールのネタから考えてみたこと。
jobsがいなければ、Appleはどうなるの？
jobsのismがないなら、やはり今のapple色なくなるんじゃね、とか、いやいや、製品を愛する俺たちがいるから大丈夫とか、ある。

jobsって、つまりこうだろ。

「俺さ、最近mp3プレーヤ使ってみたんだけど、なかなかいいんだよ。これさ、俺作れば、もっと売れると思うんだよ。もっとシンプルにして、そして、ネットからどーんと落とせるようにしてさ。俺金あるからやっちゃうよ。すぐに。1曲も1$くらいで新しいの落とせるみたいにさ。俺だったら出来るからさ、んで、本体もそうだな3万位ならいいだろ。だからお前も買えよ。な、な、な」

これがSonyだとどうなるか。
たとえば、iphoneをsony が出したら。

「新しいタッチインタフェースを備えた、革新的なスマートフォンです。楽曲やゲームのダウンロードも3G回線によりより快適に行え、新しい携帯電話のソリューションがここから始まります。価格はオープン価格です」

論客A「タッチなんて使い道が不明だ。それより使いやすいキーボードとかつけろよ」

論客B「またタッチ型端末かよ。もういいよ。ダウンロードったって、なんか料金わかんないし、いつまでサービスやんの？　また切っちゃうんじゃね」

論客B「ソニータイマー...」

ってとにかく意見がまとまらない。そして、結局製品だしてるsony自体が混乱し始めて、仕様がコロコロと変わる携帯電話が出まくる、と。
結局、ジャイアンにもいいところはあるんだよ。それも金持ちのジャイアン。

【最新ITトピック】 FacebookやTwitterとの付き合い方以前の問題として

最近、デマの拡散についての話題がTLに頻繁に出てきます。
直近では、「被災者姉妹の最後のメール」でしょうか。真偽についてはまだ明らかにはされていないものの、拡散している時点では、限りなく黒に近いグレーの様な状況だったと思います。
自分は、この手のものはまず「作家物」としてレッテルを貼ってしまう、ヒネクレた性格なのですが、ヒネクレていなくとも、直情的に何かを右から左に回してしまうのはどうかと思います。
自身でも、FBに「流れがあると感じているなら、自分がそれに乗らなくたって勝手に流れる」とは書いていますが、ogochanが自身のblogのエントリにまとめているので、こちらの方が分かり易いでしょう。

僕が拡散に参加しなかったわけ

拡散すること=自身もその情報ソースの発信元の一部となる、ということは常に頭に入れておく必要があります。
当然ですが、デマであっても自身の目論見に合っていればあえて拡散するということもあります。様々な目論見があって、デマは拡散されているのです。

【最新ITトピック】 Nicoraが語るOpenflowの立ち位置

Nicora Networkは、はOpenflowプロトコルの開発者が創立者であることから、Openflowをビジネスモデルの中心にすると思われることが多いのでしょうか。

Yahoo! ニュース: Niciraは、あなたの考える（かもしれない）OpenFlowではない

Openflowに関しては、Publickeyにおいて、

OpenFlowによってネットワーク機器がただの土管になるわけではない

という記事にもありますが、現状のOpenflowをどういう位置付けで使っていくかということになるかと思います。
Nicoraからすれば、NVPのエッジにOpen v Switchを使い、コントロールする実装にした。しかし、これをスケールするのは現実的ではないし、土管になる部分のネットワークはそれぞれで制御して最適化してくれ、ということを強調しているのでしょう。

【ヨタ】素晴らしき配線技術

それはまだTK80という、ワンボードマイコンなるものが秋葉で売られていた時代

客「あの〜、先日ここで買ったKitのTK-80を組み立てて見たんですが動かないんです」
店員「キットですから、何か半田付け不良かなんかでしょう、基板見せてもらえます？」

と、渡された基板をまじまじと見つめる店員。
そのボードには、説明書通り、ICがきちんと取り付けてあった。
そう、ICは、取り付けてあったのだ。瞬間接着材で。

と、ここまでは良い。この話が出たのは、AppleIIクローン華やかなりし頃。
みんな、口を揃えて言うのだった。
「でもさ、スルーホールだよな。しっかり密着すれば動くよな。動けば芸術だぜ」