最近のアップデートでAndroid版Chromeのアドレスバー、タブバーその他が、多くのページにおいて一定時間後に隠されるようになった。(Nexus 7上で確認)
この事自体は、コンテンツの表示面積が増えるという点で歓迎する。

しかし、タブ間の移動に戸惑うことが増えた。
タブ間の移動をしようとして、App間移動のアイコンを押すという間違いが頻発している。

タブ間の移動と、App間の移動という類似した動作に対応したした2つのナビゲーションウィジェットの内、片方した常時表示されていないという状況に慣れない。

考えてみるに、私の使い方では特に関連していない複数のタブを同時に開いている事が多い。
このタブ間の関連性の欠如は、AppとAppの間の関連性の欠如に通じるものがある。
私の脳は、この類似性によってタブ間の移動も右下のアイコンで出来るものと錯誤するようだ。
双方とも画面上に常時表示されているならともかく、片方が非表示という状況下では、非表示のタブバーの存在に意識がいかなくなる。

ここからは負け惜しみだが、Chromeのタブ間移動をApp間移動に統合するというのはどうだろうか？
関連性が薄いものの間で移動するという点において、両者は非常に似通っている。
ナビゲーションもシンプルになり、混乱する要素が一つ減り、タブのプレビューも表示出来るようになるという利点もあるので、どうだろう。

欠点としては、タブ間移動が2手間かかるようになることだ。
ただ、非表示のタブバーを表示するために1手間かかる現状を考慮すると、この欠点は些少なことだと考えている。

yumの主開発者であったSeth Vidal(36)が7月8日夜に轢き逃げされて死去した。自宅付近を自転車走行中の出来事だった。Fedoraプロジェクトのアナウンスメント。yumはRedHat系で使われているcliパッケージマネージャである。

殆どDebianばかり使って来た私は、一時期CentOSを組織の方針で使わされた時しかyumに触ったことがない。それでも、使ったことがあるツールの作者が知っている場所で亡くなられたのは結構ショックだった。年齢も近いし。

ただ一つ言えることは、彼が死亡したことには驚いたが、サイクリストが事故に巻き込まれることには正直驚きがない。周辺一帯、街頭少ないし。覚えている限りでも数年前に近場で死亡事故あったし。

ここ最近 apt-get update しても、依存関係の問題でgoogle-chrome-unstable がアップデートされない。
libc6 2.15 以上が必要なのに Sid に入っているのは 2.13 である。
Experimental には 2.17 があるが、流石に libc をExperimental から入れる勇気はない。
ということで、Sid に新しい libc6 が来るまで現状維持。

開発者や翻訳者の皆様お疲れさまでした。

Sidを常用している身としては、いつも以上にapt-listbugsとapt-listchangesの出力から目が離せない日々が当分続きそうですね。

そういえば、WheezyはMySQLが入っているようですが、次期バージョンのJessieではMariaDBになるんでしょうか。

昨日のアップデート以降、mobile chromeの日本語フォントもしくはそのレンダリングが変わった感じがする。(Chrome 25.0.1364.123 / Android 4.2.2; Nexus 7 Build/JDQ39)

小さいフォントはなんか滲んだように読み難く、大きいフォントは線が細くなってスマートな感じで読み易くなったような気がする。

あと、アップデート直後はタブのタイトルは表示されるのに、どのページも本文は真っ白にしかレンダリングされなくて焦った。
強制終了とかしてみても改善が見られなかったが、Adblock Plusを無効化したら直った。

LinuxでもOSXでも、最近ChromeのFlashがよく固まる。

特に、ヤフーのニュースを開こうとした際に固まることが多い印象。

裏で動画サイトを開いている時とかは迷惑極まりない。
Youtubeとかだと動画を途中から読み込むことが可能なので、復帰するのは比較的簡単。
一方、ニコ動は必ず最初から読み込み、読み込まれていない所まで一気にシーク出来ないという糞仕様なので、Flashが落ちる度に再読み込みを待つ必要があり、回線が細い所にいる私には非常に不便。

ちなみに、ChromeはVersion 25.0.1323.1 dev。

この問題は開発者側にも知られているようなので、次のバージョンで直っているのを期待。

特有の問題と言うわけではないが、全トラフィックをVPN経由にしようとしたが外部サイトに繋がらなかった。結果としてはnet.ipv4.ip_forwardが無効化されていて、iptablesでの設定をしていなかっだけというお粗末な原因だった。

次はwolあたりを試そうかな。

あと、e17はやめてdwmにした。何年ぶりだろうか。

製造開始から約9ヶ月、販売開始から約半年を経過したボードPC「Raspberry Pi」の英国内製造がついに開始された。このPCを設計した非営利団体「Raspberry Pi財団」は当初から、英国内での製造を目標として掲げていたが、コスト関連の問題から国内生産パートナが見付からず、現在までの製造は全て中国で行なわれてきた。

しかし、このPCの需要が想定を遥かに上回っていたため、英国内生産でもコストの問題を克服出来る目処がたち、これにより国内に製造パートナを見付けることが出来た。今回そのパートナとなったのはSonyで、ウェールズ Pencoedにある工場で月産三万個製造する契約を結んだそうだ。なお、この契約により新たに三十人分の雇用が創出される。

販売開始から長く続いている品薄状態も、現在では大分解消されてきており、購入を考えているのならいい機会かもしれない。なお注意すべき点としては、販売元はRS ComponentsとPremier Farnellという二つの独立した企業グループが担当していて、注文から発送までの時間に多大な差異があることである。現在RS系で注文すると十五週近く待たされるらしいが、Farnell系で注文すると一週間以内で発送されている模様だ。タレコみ人も八月中旬に当初はRS系で注文したが、十二週間待ちとの注文確認メールを受けとり、即キャンセルした。その後、Farnell系で注文したら、翌日に発送された。

なお、この二つのグループは製造ラインもそれぞれ独自に持っていおり、今回Sonyと製造契約を結んだのは後者のFarnellである。

Raspberry Piに関連した最近の他のニュースとしては、今までに報告された問題点を改善した改訂版(rev. 2)の製造開始や、ケンブリッジ大学のCS学部の全入学生へのRaspberry Piの配布などが発表されている。また、$25でイーサネットポート無し、USBポート一つの教育機関向けバージョン(Model A)の販売開始は年内の予定だ。

(ケーブルを改造した)外部給電方式のハブを電源として運用しているが、Rpiは順調に稼動している模様。

とりあえずTightVNCをOpenVPN経由で動作させている。Debian Wikiの情報を元に、OpenVPNは証明書を使った設定にしている。TightVNCはブート時から起動するように、http://www.abdevelopment.ca/blog/start-vnc-server-ubuntu-bootを参考にinit scriptを準備。その後、リブートしてサービスの稼動を確認した。

ちなみに、VNCのビューアとしてNexus 7上でandroidVNC を主に使う予定だし現に使っているのだが、Raspbianのデフォルトのデスクトップ環境であるLXDEが使いにくかった。主に、ボタンのサイズという点で。家のデスクトップではawesomeを使っているのだが、特殊キー(ctrlとかaltとか)の入力が頻繁に必要になるという点で、androidVNCとの相性が致命的に悪い。

Linusとde Icazaの論争を追っていたら、Alan CoxがEnlightenmentを高く評価しているのを発見した。ちょうどいいのでe17をインストールして、UIをillumeにしてみたら使い易かった。当分これで行く。

外部から接続するために無料DDNSサービスのdnsdynamic.orgを利用しているのだが、最初ddclientの設定を誤り、ローカルアドレスを登録してしまって、外部からVPNが繋んなくてはまった。

当分はこんな感じで運用していこうかな。

USBポートの低出力に加えて、更なる問題に遭遇。

家に転がっていた外部給電式USBハブを使って、USB HDDをRaspberry Piに接続した。
ディスクも順調にスピンアップして、正常に動作しているようにみえた。
そこで、badblocksを実行中にふとdmesgを見てみると、凄い勢いでethernetに関するエラーが記録されていた。

smsc95xx 1-1.1:1.0: eth0: Failed to read register index 0x00000114

それでもsshで普通に接続出来ていたので、そのままにしていたら最終的にusb関連のエラーが出てbadblocksが強制終了されてしまった。

公式フォーラムで調べてみたら、やっぱり他にも同じような問題を抱える人達がいるらしく、原因の可能性として電力の供給不足と外部給電式USBハブからのバックフィードの2つがあげられていた。

電力の供給に関しては現在は5V 850mAのKindleのアダプタを使っている。5V 1A 以上の電力供給が薦められている現状、このアダプタは多少非力かもしれない。しかし、5V 750mAという最低限のラインは十分に満しているので現状維持する。

後者に関しては、安物の外部給電式USBハブの中には、ホストに電力を送ってしまう(バックフィード)物があり、USBの仕様上は許可されていない挙動のようだ。安物のハブという点で心当たりがあったので対処法を調べてみたら2つ程見付けた。1つ目はいいハブを買う、2つ目は給電ラインを物理的に切断してしまうというもの。コストを考えて後者の給電ラインの物理的切断を採用した。これはケーブルの被覆を剥して赤いラインを切断するだけという、お手軽かつ失敗した場合は代替のケーブルを購入すればいいだけという懐への優しさに溢れた手順だ。結果、一応ホスト-ハブ間での電力の供給が無くなった所までは確認したが、肝心のHDDは別のPCでbadblocks中なので、動作確認は未だ行えていない。これでバックフィード現象は解決できるだろうが、問題が続く様ならばアダプタの交換を検討する。

RPiのこの現状はなんというか、昔良く聞いたハードウェアの相性問題って言葉がしっくりくる気がする。コスト削減の過程で仕様を多少満たさない製品とかを複数の会社が販売していれば、そりゃ動かない組み合わせとかも当然あるわな。今回は35ドルという値段に納める為に結構無理して動作のマージン削ってしまったので、優等生ではない外部機器との間で問題が発生しているんではないかと想像している。