$ ruby -v
ruby 2.0.0p451 .....

$ node -v
v0.10.25

Ruby

require 'openssl'
require 'digest'
require 'base64'

def encode(cryptkey, iv, cleardata)
    cipher = OpenSSL::Cipher.new('AES-256-CBC')
    cipher.encrypt
    cipher.key = cryptkey
    cipher.iv  = iv

    encrypted = ''
    encrypted << cipher.update(cleardata)
    encrypted << cipher.final
    Base64.strict_encode64(encrypted)
end

encode w/ Ruby

data = 'The quick brown fox jumps over the lazy dog'
cryptkey = Digest::SHA256.digest('012345678901234567')
iv = '0a1b2c3d4e5f6g7h'
x = encode(cryptkey, iv, data)

=> "SWozLQpQiz2itvbl1PomOPBTvxMmIE6rl4gZlerajsnJrhAfvp6jj5MBSlu+8fle"

Node.js

var crypto = require('crypto');

b64dec = function(data) {
  buf = new Buffer(data, 'base64');
  return buf.toString('binary')
};

decode = function(encrypted_64, cryptkey, iv) {
    var cryptkey = crypto.createHash('sha256').update(cryptkey).digest(),
        decipher = crypto.createDecipheriv('aes-256-cbc', cryptkey, iv),
        decoded  = decipher.update(b64dec(encrypted_64));

    return Buffer.concat([decoded, decipher.final()]);
}

decode w/ Node.js

decode('SWozLQpQiz2itvbl1PomOPBTvxMmIE6rl4gZlerajsnJrhAfvp6jj5MBSlu+8fle',
    '012345678901234567','0a1b2c3d4e5f6g7h').toString()

'The quick brown fox jumps over the lazy dog'

5秒おきに、現在値がざっ、ざっ、と動くような感じ。向いてる方向もせわしなく動く。Google Map アプリのナビや Waze なんか使おうもんなら、移動してないのに向きがせわしなく切り替わったり、あっちいったりこっちいったり、斜め後ろ向いたままザザッと動き続けたり。

これは使えん。GPS アンテナか GPS ユニットが壊れたんかなぁ、と。

ところが、原因切り分けのために、ふと思い立って Wi-Fi を off にすると、急にまともに使えるように。Wi-Fi を on に戻すと、また不正確な位置と向きをせわしなく表示。ふーむ。

通常は GPS から取得した位置情報と Wi-Fi から取得した位置情報、そしてモバイルデータ通信から取得した位置情報をうまく使ってくれるはずなのですが、Wi-Fi を on にしていると、GPS と Wi-Fi の位置情報を使わずにモバイルデータ通信からの位置情報のみを使ってくれているように見える。どうもソフトウェア的な何かの不具合に思えます。

というわけで、PC にバックアップを手動でとったのち、いちど工場出荷状態に戻し、バックアップから復元し直しました。4000曲くらいが iTunes から同期されていているのですが、全て（ハイレゾや 16/44 から）192kbps AAC に変換されて同期されるので、復元にはもの凄く時間がかかります。寝る前に復元開始し、朝起きたら終わってました。あいぽんの空き容量も9GBくらいから14GBくらいに増えてる。いろんなアプリや iOS の吐くゴミデータで埋まってたのかな。

で、今朝幼稚園へ送る際に確認してみたところ、直ってました。

もし復元でも直らなかったら、ジーニアスバーに持ち込んで新品に交換してもらおうと企んでいたのですが、それはなくなりました。ともあれまた意図した通りに動作してくれて一安心。。。

追記 (2013/11/06)：
直ってませんでした（涙）。というか状況の切り分けが間違ってました。

正確にはこうでした。「カーオーディオにUSB接続すると、あいぽんのGPSがアホになる」。よって、自家用車による走行中のみ GPS がおかしかったことになります。手持ちで徒歩の時などは全く問題ないことを確認しました。普段歩きながらマップを見たりしないので、気付かなかった（状況切り分けを間違えた）という感じです。。。

ちなみに車中のホルダーに装着していても、Lightning to USBケーブルによる接続を外せば、再び位置情報がまともになります。つまり、車中のために GPS 電波が拾いにくくなって不正確になっているのではない、ということです。

エンジンを完全に off にすると、位置情報は正確に戻ります。そしてキーをひねって acc や on の位置にする（カーオーディオに通電する）と、とたんに位置情報が乱れ出します。今日はそこまで確認。

問題は、数週間前まで、こんなことはなかった、ということ。ここから先の原因特定は少し難儀です。

1. iPhone5 の内蔵 GPS アンテナが劣化（？）して感度が落ちてきてるのか？
• これはない気はしますが。。。
2. iOS7 に上げたタイミングとおおよそ一緒？（な気がする）
• 現在使用中のカーオーディオと iOS7 の問題な可能性も捨てきれません
3. あるいは。。。クルマ側の電気系統側のなんらかの問題なのか？
• うちのクルマならありえる（涙）
4. 現在使用中の lightning to USB ケーブルのせい？
• これもないと思うけど、後日別のケーブルで比較検証することに

もうちょっと状況証拠を集めてみようと思います。

追記 (2013/11/07)：
iPhone5s を借りてカーオーディオに接続してみたところ、（私の iPhone5 がかつてそうだったように）特に問題なく現在位置を捕捉していることを確認。ということで、

1. iPhone5 の内蔵 GPS アンテナが劣化（？）して感度が落ちてきてるのか？

のケースに該当していそう。Genius Bar で交換してもらえる程度なのかは微妙な気が。。。

追記 (2013/11/09)：
なんと直ってしまった（笑）。壁打ちテニス中にあいぽんをポケットから落としたせいらしい。多分、基板からGPSセンサーが外れかけていて？接触不良で？、落とした衝撃でちゃんと繋がったのではないかと推察。。。Genius Bar 予約はとりあえずキャンセルすることに。

BackBlaze や Bitcasa などと比較検討し、以下の点で採用を決定しました。

• ローカルデバイス以外（外部接続デバイス、マウントしている NAS ドライブ）などもバックアップ対象に選べる
• マルチプラットフォーム

自宅のルータ兼サーバ（Vine Linux で稼働中）上で動かせ、ローカルネットワーク上にあって NFS マウントして使っている NAS（NETGEAR ReadyNAS）上のコンテンツをバックアップできる、という点で選定しました。デーモンも管理UIも Java で動くというスタイルのようです。

USBをシリアル通信（RS232 9ピン）に変換　変換名人　USB-RS232

なんもせずにフツーに認識されてフツーに使えた。ややつまんないけど。

ドライバはそのまんま pl2303。

Bus 005 Device 002: ID 067b:2303 Prolific Technology, Inc. PL2303 Serial Port
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               1.10
  bDeviceClass            0 (Defined at Interface level)
  bDeviceSubClass         0 
  bDeviceProtocol         0 
  bMaxPacketSize0        64
  idVendor           0x067b Prolific Technology, Inc.
  idProduct          0x2303 PL2303 Serial Port
  bcdDevice            3.00
  iManufacturer           1 Prolific Technology Inc.
  iProduct                2 USB-Serial Controller
  iSerial                 0 
  bNumConfigurations      1
  Configuration Descriptor:
    bLength                 9
    bDescriptorType         2
    wTotalLength           39
    bNumInterfaces          1
    bConfigurationValue     1
    iConfiguration          0 
    bmAttributes         0x80
      (Bus Powered)
    MaxPower              100mA
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       0
      bNumEndpoints           3
      bInterfaceClass       255 Vendor Specific Class
      bInterfaceSubClass      0 
      bInterfaceProtocol      0 
      iInterface              0 
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x81  EP 1 IN
        bmAttributes            3
          Transfer Type            Interrupt
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x000a  1x 10 bytes
        bInterval               1
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x02  EP 2 OUT
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0040  1x 64 bytes
        bInterval               0
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x83  EP 3 IN
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0040  1x 64 bytes
        bInterval               0
Device Status:     0x0000
  (Bus Powered)

故 Jobs 氏への強い思い入れは不思議とほとんどなかったのかな、 と改めて思いました。 むしろ Bill Atkinson さん、故 Jeff Raskin さん、 Andy Hertzfeld さん、Joanna Hoffman さん、といった、 エンジニアな方々への興味の方が強かったのかな、と。

Bought a MacBook Air (Middle 2011) - 11inch, US Keyboard, 4GB Memory, 128GB SSD and Core i7 - to replace my MacBook (Early 2008) that has served me very hard as a Vine Linux development environment as a daily basis for a few years.

To be honest, I always have used my whity MacBook with Vine - Mac OS X is always there on the harddrive in a separated partition, but I seldom booted it up on my MacBook - maybe once or twice a year? Another OSX machine at home, an old PowerMac G4 MDD, is still there and serving me as a daily basis as well, to store my huge digital music contents (almost all in lossless format) on iTunes (still hundreds of CDs left to get ripped though), and as a scanning machine (connected to the old SCSI A3 flatbed scanner).

The first thing I did on my new toy was to play around the new OS for a while that amazed me a bit. This was the first time for me to play with the multi-touch trackpad and gestures. I felt Gestures and "Mission Control" are really great for portable computers with small screens like this MBA 11inch.

And the next thing I gonna do was, of course, to figure out how well this brand new machine is supported on Linux - I know there are so much to get done on the Linux kernel, the X thing, and some userland utilities, to run Linux on the MBA 2011 flawlessly, but I just thought it was worth checking out and playing around.

panic occurred, switching back to text console
BUG: scheduling while atomic: swapper/0/0x10010000
Modules linked in: sit tunnel4 rfcomm sco bnep l2cap vboxnetadp vboxnetflt vboxdrv autofs4 sunrpc
ipv6 acpi_cpufreq freq_table mperf dm_mirror dm_region_hash dm_log dm_mod uinput snd_hda_codec_realtek
snd_hda_intel lib80211_crypt_tkip snd_hda_codec wl(P) snd_hwdep uvcvideo btusb snd_seq_dummy
snd_seq_oss snd_seq_midi_event snd_seq videodev bluetooth ohci1394 v4l1_compat snd_seq_device
applesmc snd_pcm_oss snd_pcm hwmon rfkill lib80211 ieee1394 led_class snd_timer snd firewire_ohci
soundcore firewire_core i2c_i801 snd_page_alloc sky2 input_polldev mbp_nvidia_bl pcspkr crc_itu_t
joydev iTCO_wdt iTCO_vendor_support appletouch processor battery thermal ac ata_generic pata_acpi
uhci_hcd ohci_hcd ehci_hcd i915 dkms_kms_helper drm i2c_algo_bit button i2c_core video output
[last unloaded: cpufreq_ondemand]
Pid: 0, comm: swapper Tainted: P       D     2.6.35-20vl6 #1
Call Trace:
[<c102d3a6>] __schedule_bug+0x1/0x56
[<c1359495>] schedule+0x83/0x4b9
[<f7d7b78e>] ? drm_crtc_helper_set_config+0x84/0x65b [drm_kms_helper]
[<c135999d>] _cond_resched+0x2e/0x47
[<c10c8b80>] __kmalloc+0xa8/0x145
[<f7d7b78e>] drm_crtc_helper_set_config+0x94/0x65b [drm_kms_helper]
[<c1005e37>] ?show_trace_log_lvl+0x39/0x43
[<f7d7aae8>] drm_fb_helper_force_kernel_mode+0x2b/0x5b [drm_kms_helper]
[<f7d7ab62>] drm_fb_helper_panic+0x17/0x1d [drm_kms_helper]
[<c104b6c3>] notifier_call_chain+0x14/0x16
[<c1359289>] atomic_notifier_call_chain+0x14/0x16
[<c1359289>] panic+0x73/0xbc
[<c1005c17>] oops_end+0x7a/0x88
[<c102088f>] no_context+0x115/0x11f
[<c102098a>] __bad_area_nosemaphore+0xf1/0xf9
[<c1020af0>] ? do_page_fault+0x0/0x2eb
[<c10209a4>] bad_area_nosemaphore+0x12/0x15
[<c1020c32>] d0_page_fault+0x142/0x2eb
[<c10080fd>] ?sched_clock+0x9/0xd
[<c104bfb3>] ?sched_clock_local+0x17/0x11e
[<c1020af0>] ?do_page_fault_0x0/0x2eb
[<c135b9b6>] error_code+0x66/0x6c
[<c104007b>] ? ignore_signals+0x21/0x27
[<c1020af0>] ?do_page_fault+0x0/0x2eb
[<f91a3e0d>] ?rtMpNotificationLinuxOnCurrentCPU+0xa/0x9d [vboxdrv]
[<f91a3a51>] rtmpLinuxWrapper+0x22/0x27 [vboxdrv]
[<c10572e7>] generic_smp_call_function_single_interrupt+0xa0/0xba
[<c1017e29>] smp_call_function_single_interrupt+0xa0/0xba
[<c135b546>] call_function_single_interuupt+0x2a/0x30
[<c104007b>] ? ignore_signals+0x21/0x27
[<f86fa1ea>] ? acpi_idle_enter_bm+0x24d/0x289 [processor]
[<c12b7475>] cpuidle_idle_call+0x73/0xce
[<c10023a3>] cpu_idle+0x4e/0x67
[<c1357280>] start_secondary+0x1a8/0x1ad

I'd been looking for the solution to the issue, and finally I found this was it:

• Ticket #9305: VBox modules randomly cause kernel panic on computer shutdown -> fixed as of 28-Jul 2011

The fix itself was very trivial:

--- src/VBox/Runtime/r0drv/linux/mpnotification-r0drv-linux.c	(revision 73209)
+++ src/VBox/Runtime/r0drv/linux/mpnotification-r0drv-linux.c	(revision 73210)
@@ -77,7 +77,7 @@
  * @param pvUser2           The notification event.
  * @remarks This can be invoked in interrupt context.
  */
-static void rtMpNotificationLinuxOnCurrentCpu(RTCPUID idCpu, void *pvUser1, void *pvUser2)
+static DECLCALLBACK(void) rtMpNotificationLinuxOnCurrentCpu(RTCPUID idCpu, void *pvUser1, void *pvUser2)
 {
     unsigned long ulNativeEvent = *(unsigned long *)pvUser2;
     NOREF(pvUser1);

Now the fix has been included on VirtualBox-4.1.0-2vl7 (VineSeed).

Same fix for Vine Linux 6 (more precisely, packages for VinePlus/6) will be uploaded as 4.1.0-2vl6 as well shortly.

We just watched the class behind the fence - not the trial lesson for my daughter. Sorry for her - she complained that she wanted to join the class and play with balls and racquets. Very sorry for her. Anyway we watched 80% of the whole lesson - about 40 minutes - until my daughter got bored of standing behind the fence, watching the kids class on the tennis court.

Not bad. We saw two children (two four-years-old boys) in the class on that day, while on the neighbouring court “Players' Course” (a very serious class for teens who wants to be professional tennis players) was playing very hard. The two kids were having fun at the class, moving and playing with much joy. They didn't look like they got bored.

To tell the truth I have been always wondering, why the progress bar on the boot-up screen looks like this. The progress bar is placed on the black background - the border is drawn in white colour - so the which is the progress bar itself, black one, or white one?

Seems like the “script” theme itself adopts black-coloured bar as a progress bar itself. So the following screenshot means that the boot-up process is now about 20% complete:

But don't you think it a bit strange? Sometimes do you see this as “the progress bar coming from the right side, now approximately 80% complete” or something?

I believe, in this example (black background, progress bar with white border), the following screenshot should represents “approximately 20% complete” far better:

If the latter one is still ambiguous, how about the following example whose border colour and the progress bar colour is bit different? I like this much better IMHO.

What would you think? Am I the only one who think it different?

P.S.
This change can be easily done by editing the following png files:

/usr/share/plymouth/themes/script/progress_bar.png
/usr/share/plymouth/themes/script/progress_box.png

And don't forget to execute “sudo /sbin/new-kernel-pkg --mkinitrd --depmod --install (kernel_version)” (kernel_version = 2.6.35-18vl6 for example) to take effect.

P.S. 2
Soon after this article was published, I noticed other Vine members were talking on the IRC channel about changing the default Plymouth theme from Script to Spinfinity - okay, okay - that's another solution to avoid the Script theme...

P.S. 3
Then here's yet another canditate from Daisuke-san - looking good. The very best IMHO. Now we can clearly distinguish the progress bar itself - no confusion here.

I found the following lines on the CMakeLists.txt in the digikam source code:

# Extract version of libjpeg so that we can use the appropriate dir
# See bug #227313, #228483
FILE(READ "${JPEG_INCLUDE_DIR}/jpeglib.h" jpeglib_h_content)
STRING(REGEX REPLACE ".*#define +JPEG_LIB_VERSION +([0-9]+).*" "\\1" jpeglib_version "${jpeglib_h_content}")
MESSAGE(STATUS "Identified libjpeg version: ${jpeglib_version}")

IF ("${jpeglib_version}" LESS 80)
    SET(DIGIKAM_LIBJPEG_DIR libjpeg-62)
ELSE ("${jpeglib_version}" LESS 80)
    SET(DIGIKAM_LIBJPEG_DIR libjpeg-80)
ENDIF ("${jpeglib_version}" LESS 80)

while on the other hand VineSeed now has libjpeg-turbo instead of the ancient libjpeg6b.

jpeglib.h from libjpeg-turbo does NOT have the line starting from #define JPEG_LIB_VERSION: instead the declaration is in another header file jconfig.h like this:

#define JPEG_LIB_VERSION 62

So the trivial hack (until the upstream fix this tiny issue) is like this:

--- digikam-1.9.0/CMakeLists.txt.orig   2011-02-28 05:16:18.000000000 +0900
+++ digikam-1.9.0/CMakeLists.txt        2011-06-08 14:10:15.000000000 +0900
@@ -153,7 +153,9 @@
 
 # Extract version of libjpeg so that we can use the appropriate dir
 # See bug #227313, #228483
-FILE(READ "${JPEG_INCLUDE_DIR}/jpeglib.h" jpeglib_h_content)
+# VINE: better check jconfig.h in place of jpeglib.h on libjpeg-turbo
+# FILE(READ "${JPEG_INCLUDE_DIR}/jpeglib.h" jpeglib_h_content)
+FILE(READ "${JPEG_INCLUDE_DIR}/jconfig.h" jpeglib_h_content)
 STRING(REGEX REPLACE ".*#define +JPEG_LIB_VERSION +([0-9]+).*" "\\1" jpeglib_version "${jpeglib_h_content}")
 MESSAGE(STATUS "Identified libjpeg version: ${jpeglib_version}")

• Tick Tock - student short film for Emory Campus MovieFest 2011 (YouTube)

を観ようとすると、

。。。。

どこか懐かしさもある、大昔遊んだマイコンのテレビゲームみたいな。。。。

結局、Flash の ハードウェアアクセラレーションを無効にする、というのが正解だった模様です。特定の YouTube 映像のみでおかしくなっていたので、まあなんか特定のエンコーディング用のアクセラレータの問題ではないかと思ってはいたのですが。
なにせ VineSeed でちょうど XOrg 1.10 一式が投入された直後ということもあり、原因はなんだなんだということに。。。

<d> flash10.2からVAAPI/VDPAUつかったh264のアクセラレーションが使われるようになったのだけど
<d> h264のプロファイルによっては壊れる
<d> &一回こわれるとflashプロセスを殺さないと
<d> 全部に影響するっぽい

ということだと。だいさめ 情報サンクス。