TidBITS#165/18-Mar-2013 TidBITS#165/18-Mar-2013今週の大ニュースは Google から届いた。何か新しいものというわけではなくて、古いもの、Google Reader が消え去るというニュースだ。Josh Centers が、Google Reader で RSS ニュースフィードを読んだり、他の RSS アプリを搭載したデバイスとの間で RSS ニュースフィード同期したりしていた人のために、これに代わって使えるものをいくつか紹介する。また、Adam Engst はこの機会を利用して、Google Reader の消滅が何を意味するかを、ツール対プラットフォームの観点から、出版者対配布者の観点から、インターネット上の情報の無限性の観点から、より深く考察する。さて、地に足の着いた話題に戻れば、Adam が OS X 10.8.3 アップデートについても検討し、Joe Kissell は FlippedBITS をお披露目する。これはテクノロジーに関する思い違いを是正することを狙った新たなコラム記事シリーズで、さっそくその第一回として Joe はハードディスクの複製からブートしている際に気を付けるべきことを説明する。今週注目すべきソフトウェアリリースは、Snow Leopard および Lion 用セキュリティアップデート 2013-001、MacBook Pro Retina SMC アップデート 1.1、Pear Note 3.1、LaunchBar 5.4.2、Microsoft Office 2011 14.3.2 および 2008 12.3.6、Default Folder X 4.5.8、それに Dropbox 2.0 だ。
記事:
----------------- 本号の TidBITS のスポンサーは: ------------------
---- 皆さんのスポンサーへのサポートが TidBITS への力となります ----
文： Adam C. Engst: [email protected], @adamengst
訳： Mark Nagata <nagata@kurims.kyoto-u.ac.jp>
OS X Mountain Lion 10.8.3 アップデートと、その中に含まれる Safari 6.0.3 で、Apple はずっと付きまとっていたバグを数多く解消した。その大多数は極めて個別的なもので、半年近く前により大幅な 10.8.2 リリースを出した際に見過ごされてしまったものたちだ。（2012 年 9 月 19 日の記事“OS X 10.8.2 が通知センターとメッセージのフラストレーションを緩和”参照。）今回の無料アップデートは Mac App Store 経由で入手できるが、Apple のサポートダウンロードサイトから直接にも差分アップデート (540.46 MB、10.8.2 から) と統合アップデート (793.69 MB、10.8 のどのバージョンからでも) の二種類の形でダウンロードできるようになった。今回のアップデートに関する問題点を私たちはまだ何も耳にしていないけれども、新たな問題が何も発生していないことを確認するまで数日間ほどアップデートせずに待つことをお勧めしたい。アップデートの内容を少し詳しく見ていこう。
嬉しいニュースだ！ ファイル URL のバグが消えた。記事“A Simple Text String that Crashes Most Mac Applications”(2013 年 2 月 4 日) をご覧頂きたい。これはごくマイナーなバグだったが、とても気恥ずかしいものだったので、Apple が対処してくれて良かった。
連絡先アプリではプリントに関係したいくつかのバグが修正された。カードが順番通りにプリントされないバグや、住所が間違った位置にプリントされるバグなどだ。私たちは今もまだ主に BeLight Software の製品でより多機能の Labels & Addresses を使ってプリントをしているので、これらの問題を経験することはなかった。（2008 年 12 月 12 日の記事“Labels & Addresses でホリデーカードに正気を取り戻す”参照。）
VMware Fusion や Parallels Desktop でなく Boot Camp を使っていて、フェンスの両側とも最新版を使いたいと思う人のために、10.8.3 では Windows 8 のインストールに対応するとともに、3 TB ドライブ搭載の Mac にも対応した。
見た目が素敵なものが大好きな人には、10.8.3 でようやく Mountain Lion の Slideshow スクリーンセーバがサブフォルダにある写真を表示できる機能が復活し、またログアウトや再起動の後にデスクトップピクチャが変更されてしまうバグが修正された。スリープからの復帰後に画面が変になるのが気になっていた人も、もうその問題を心配する必要がなくなったはずだ。
オーディオ関係の修正も二つあるので耳を澄ませよう。一つは 2011 年リリースの Mac でオーディオが途切れていた問題の修正、もう一つは特定のプラグインを使用中に Logic Pro が反応しなくなる問題の修正だ。
ネットワーキングについては、Mail で Microsoft Exchange アカウント使用時の信頼性が向上し、Notes アプリにおいて IMAP サーバとの互換性が向上し、Messages でスリープからの復帰後にメッセージが順番通りに表示されない問題を修正し、高遅延ネットワーク上で遅れが生じたりシステム環境設定の セキュリティとプライバシー パネルにアクセスするとユーザーをロックアウトしたりする Active Directory の二件のバグを修正した、と 10.8.3 は約束している。
Safari 6.0.3 では、Facebook でスクロールする際と、ウェブページをズームインしながらスクロールする際、およびプラグインコンテンツが含まれているウェブページにおいて、それぞれパフォーマンスを改善している。また、ブックマークを変更できないという誤った警告が出るバグ、Mac 上の Safari でブックマークを編集すると iOS デバイスでブックマークが重複表示される問題、ペアレンタルコントロールが有効になっていても Google 検索の際にフィルタ処理されていない検索結果にアクセスできてしまう問題、それと Safari で前のページに戻った際に直前の位置が復元されない問題が修正された。
いつもと同様、10.8.3 と Safari 6.0.3 の双方とも、数多くのセキュリティ脆弱性に対処している。Safari 6.0.3 では WebKit におけるメモり破損のバグが 15 件以上修正されたのに加えて、クロスサイトスクリプティングの問題を 2 件解決している。10.8.3 におけるセキュリティ修正も多岐にわたっており、Apache、CoreTypes、International Components for Unicode、Identity Services、ImageIO、IOAcceleratorFamily、カーネル、ログインウィンドウ、メッセージ、PDFKit、QuickTime その他のコンポーネントやアプリに対処が施された。また、このアップデートにより不正な SSL 証明書を許可しないようになった。
マルウェア除去ツールについても述べられている。Apple によれば、アップデートのインストールの際にこのツールが走り、マルウェアの最も一般的な変種を除去するという。マルウェアが見つかった場合に限り通知が出る。
最初に述べた通り、10.8.3 と Safari 6.0.3 における変更点はいずれも歓迎すべきものだが、Apple が意図せず新たな問題を持ち込んでしまったか否かは全くわからないので、今回のアップデートで修正された具体的問題のどれかにあなたが日々悩まされているのでない限り、新し物好きの人たちがすべてをクリアにしてくれるまで、しばらくこのアップデートをせずに待つことをお勧めしたい。
コメントリンク13637 この記事について | Tweet リンク13637
文： Joe Kissell: [email protected], @joekissell
訳： Mark Nagata <nagata@kurims.kyoto-u.ac.jp>
今日は私たちが始める新しい記事シリーズを皆さんにご紹介したい。私たちはこの記事シリーズを FlippedBITS と名付けた。［訳者注： あべこべになった情報ビット、というような意味です。］私たちがこれを考えたのは、テクノロジーは思い違いを生みやすく、私たちがものごとをする際に情報の欠如が原因で一見もっともらしいけれども間違った思考的モデルを頭の中で作り上げてしまうことがあまりにも多いからだ。こうした誤った考えが原因となって、日常的に起こる問題を解決するのがより困難となったり、時間と労力とお金の浪費に繋がったりすることもある。FlippedBITS 連載記事の一つ一つで、こうした誤解を一つか二つずつ取り上げて、事実の白黒をはっきりさせるために最大限の努力をしてみたいと思う。
2 歳になる私の息子はまだ世界がどのように動いているかを学んでいる最中だが、テクノロジーに対する彼の理解が発展する様子はとても興味深い。ほんの数ヵ月前、彼はリモコンを手に持って電話のようにそれに話しかけようとしていた。彼の頭の中では、片側にボタンが並んでいるプラスチック製の長方形の箱は電話であったに違いない。どうして彼がそんな間違いをしたかを推察するのは容易いことだ。（それに、公平を期して言えば、私たちの使っていた電話とリモコンはとってもよく似ていた。）今では、リモコンが別のものであることを彼は理解している。リモコンはテレビに向けて使って大好きな番組を見るためのものだ。そこで今度は、ボタンを押すと音が出るだけのオモチャのリモコンを手渡してみると、彼は混乱してとてもイライラした。どうしてテレビが反応しないのか、彼には理解できなかったからだ。
子供たちがこの種の間違いをするのは当然予想できることだし、子供たちが何かを一つの論理範疇に入れてみて、それがうまく当てはまらないのに気付き、また別の範疇を試してみる様を見ながら私たちは物知り顔で笑う。そういったことはすべて、子供の成長そのものなのだ。けれども実際のところ、世界を解明したいという私たちの試みが止まることはない。大人になった私たちもやはり完全には理解できない新しいものに出会うし、そういうものを見て私たちがその中身はきっとこんな風になっているに違いないという思考的モデルを頭の中で作り始めるのは、ほぼ自動的に、おそらく無意識のうちに、起こることだ。そのようなモデルは、ただ単に現在見ているものを説明するための役に立つばかりでなく、将来ものごとがどう働くかを予測するための役にも立つ。ただ、時々私たちは間違った予測をするのであって、それは決して私たちが悪いわけではない。
例えば、私は初めて「レーザープリンタ」という新式のデバイスのことを聞いたときのことをよく覚えている。当時私は大学一年生であった。何も書いてない紙を入れると、何かレーザーに関係することのお陰で、鮮やかな黒い文字でテキストが印刷されて出てきた。でも、これがどうなっているかという点について私が最初に持った印象は、レーザー光線が紙の上に直接文字を焼き付けているのだろうというものだった。結局のところ、レーザー光線は物を焼き焦がすのだから。後になって、レーザープリンタがトナーと呼ばれる黒い粉を使うことを知った私は、自分の理論を修正しなければならなかった。ひょっとしたら、レーザー光線を照射する前にまず紙をトナーで覆っておいて、レーザー光線の熱でトナーがその場で融けて紙にくっつくのかもしれない。もちろん、それもまたとんでもなく見当外れの理論であった。当時の私は、レーザー光線が帯電を反転させることによりドラムにくっついていたトナーを自由にすること、そして紙がドラムに巻き付く際にドラムに残ったトナーが（やはり静電気引力で）紙に移ること、それから熱と圧力によってトナーが紙に結合されること、などを知る由もなかった。私の考えた理論はいずれも、私が入手できた情報に基づけばもっともらしいものに思えたし、プリンタから出てきた紙が暖かいことを正しく予想してさえいたのだが、それでも私の頭の中の思考的モデルは現実を反映したものではなかった。
レーザープリンタの仕組みを誤解したことは、何も否定的な結果を私に及ぼさなかった。けれども時として、思考的モデルが誤っていることが深刻な問題に繋がることもある。もしも自動車のエアバッグの働きに関するあなたの思考的モデルが、あらゆる種類の衝突においてエアバッグが完璧な保護を提供してくれるというものであったならば、それを根拠にわざわざシートベルトなんかする必要がないと考えてしまうかもしれない。その結果として、例えば自動車がひっくり返る事故に遭えば生死にかかわるかもしれない。
私の本や記事を読んだ人たちから、あるいは私がどこかで話した講演を聴いた人たちから、私はたくさんの技術的質問を受ける。そのうちのかなりの割合のものが、誤った思考的モデルから生まれたものであることを示す言い回しの質問だ。例えば、ここ数週間以内に少なくとも三人の別々の人たちから、私はほとんど同じ質問を受けた。「FileVault がディスク上のすべてのファイルを暗号化するということは、ファイルを他のディスクにコピーしてもそのファイルはまだ暗号化されているのではないか？」というものだ。そうではない！ それは、決してそんなことを意味しない。（いずれ、FlippedBITS 記事でそのことも説明したいと思っている。）けれども、そういう結論に陥りやすいことは容易に推察できるし、この種の誤解の結果として重要なファイルの扱い方に安全でない判断をしてしまうのも十分あり得ることだ。
正直に告白しよう。この種の質問を聞くと、時々私は目を丸くして「何て馬鹿げた考え方だ！」と叫び出したい衝動に駆られることがある。でも、私自身もまた、これまで馬鹿げた思い違いをたくさんしてきた。（おそらく今もまだたくさんしているだろう。）何かをきちんと理解していなかったり、あるいはものの働き方について正しくない観念を持っていたりするからといって、それはあなたが馬鹿だということにはならない。それはただ、そのものに対してまだ十分な情報を得ていないというだけのことだ。そこで、私は全力を尽くしてそれらの欠落した事実を供給することで、皆が正しい道を進めるようにしたいと願っている。FlippedBITS で取り上げたい話題として既にかなりの数のものをリストアップしてあるが、もしも適切な良い話題をお持ちならばどうぞ提案して頂きたい。
それで、"FlippedBITS" という名前はいったいどこから出てきたのか？ もちろんここ TidBITS にいる私たちが何にでも名前の後に "BITS" を付けたがるのはご承知の通りだが、情報 (bit) があべこべになっている (flipped) というのが、ここで正そうとしている種類の誤りの説明として適切だと思ったのだ。ご存じの通り、コンピュータは 1 と 0 の並びとして情報を保存する。bit とは、その 1 または 0 を保持することのできる「スロット」だ。その bit の保持する値が 0 のときにそれを flip すれば、1 になる。もう一度 flip すれば 0 に戻る。時には、プログラミングのエラーや、機械の故障、メディアの劣化、宇宙線の照射 (本当の話だ！)、その他気まぐれな出来事により bit が flip されてしまうことがある。そして残念なことに、bit がたった一個 flip されただけで、つまり 0 であるはずが 1 になるか、またはその逆が、たった一ヵ所で起こっただけで、一つのプログラムが成功するか失敗するかの違いを意味することになりかねない。早い話が、"w" という文字のバイナリ表現は 01110111 だけれども、それとほとんど同じでたった一個の bit を flip した 01110011 は "s" という文字になる。たった一個の bit の flip が、"win" (勝利) という単語を "sin" (罪) という単語に変えてしまうのだ！
そういうわけで、願わくはこれから長く続いて皆さんのお役に立てる記事シリーズとなるべき FlippedBITS の第一回、“FlippedBITS： 複製ボリュームから Mac をブート”(2013 年 3 月 13 日) に読み進んで頂きたいと思う。
コメントリンク13617 この記事について | Tweet リンク13617
文： Joe Kissell: [email protected], @joekissell
訳： Mark Nagata <nagata@kurims.kyoto-u.ac.jp>
FlippedBITS の第一回となるこの記事では、あなたの Mac をその起動ディスクの複製（いわゆる「クローン」）からブートした場合に何が起こるかについて検討してみたい。その際いくつかのよくある混同、特にバックアップの継続や、その他のタイプのデータの同期について何が起こるかという点についてもはっきりさせておきたい。
もう何年も前からずっと、私は三方面のバックアップ、つまりバージョン分けされたバックアップ (例えば Time Machine や CrashPlan を使ってできる)、ブート可能な複製 (あなたの起動ディスク上にあるすべてのものの完璧なコピーを、外付けドライブの上に保存したもの)、それからオフサイトのデータ保存 (クラウド上か、または物理的メディアを他の場所へ持ち回りすることによる) の三つを含むバックアップ戦略を推奨してきた。それらを組み合わせることによって、あなたのデータはほとんどどんな災厄からも守られるし、万一の場合にも可能な限り簡単に復旧ができるからだ。（私が提案する戦略について詳しいことは、特にブート可能な複製の作成のしかたについては、"Take Control of Backing Up Your Mac" をご覧頂きたい。）
Carbon Copy Cloner や SuperDuper などのツールを使って複製を作るのは簡単だ。それを済ませておけば、システム環境設定の「起動ディスク」パネルを使うか、あるいは再起動の際に Option キーを押さえておいてその複製を含むボリュームを選ぶかすれば、その複製を使って Mac を起動できる。こうすることで、仮に起動ディスクで何かがおかしくなっても、あなたはすぐに仕事に戻ることができる。複製を使って走らせればあなたの Mac は何事もなかったかのように働くからだ。ここまでのところは、何も問題ない。
けれども、バックアップについて書いたさまざまの本や記事を読んだ人たちと私がやり取りした数限りない電子メールでの会話に基づいて言えば、いったん複製からブートした後で何をすべきかは明確でないことがありがちだ。複製が元のディスクとあらゆる状況で全く同じ挙動をすると期待する人たちもいるが、それは厳密には正しくない。また、複製が元のディスクと違うことを気にするあまり、複製のままではあらゆる種類の問題が起こり、余分の不必要な作業が必要となるのではないかと心配する人たちもいる。そういったものごとを解きほぐすために、まずは曖昧さの一番少ない状況から話を始めよう。
起動ドライブを交換する -- あなたの Mac の内蔵ハードドライブが完全に死んでしまって、そのドライブをあなたの Mac から取り外してから、ブート可能な複製として作ってあったドライブと交換する場合を考えよう。この場合、あなたの Mac はその新しいハードドライブが以前と違うブランド、容量、速度を持っているかどうかを全く気にしない。Mac にとって重要なのは、以前と同じデータが以前と全く同じ場所にあるディスクだということだ。だから、あらゆる実用的な目的において、それは以前と同じディスクだ。つまり、あなたはまるで何事もなかったかのように使い続けることができ、バックアップも含めてあらゆることが、これまで通りの場所から、同じように働くはずだ。まず間違いなく、それはまさにあなたの望んだことだろう。
さて、ここに一つだけちょっと注意しておかなければならないことがある。あなたがその複製を作成した時点と、それを使い始めた時点との間に、時間差があった場合はどうすればよいのだろうか？ もしも、その時間差の間に、あなたが起動ディスク上のデータを作成したり編集したりしていて、それをブ−ト可能な複製とは別の場所にバックアップしていたらどうすべきか？ その場合、あなたが使い始めた新しい起動ディスクは少し古くなっているわけで、それを最新の内容にするために、あなたはその別のバックアップに行き、最後に複製を作成したよりも 後に 変更を受けた重要なファイルを見つけ出してリストアしなければならないだろう。そのための手順は、残念ながら、完全に手動の作業になってしまうことが多い。バックアップ用アプリの多くは（ここでもやはり Time Machine と CrashPlan を念頭に置いているが）単純に「時刻 x より 後に 変更を受けてバックアップされたファイルのみをすべて表示する」方法がない。おそらくあなたは、バックアップアーカイブの中で多数のフォルダを一つ一つかき分けて、欲しいファイルを探し出さねばならないだろう。もちろん、特定の時刻以後にバックアップされたもの すべて について既存のものを上書きしてリストアするようにソフトウェアに命ずることは可能かもしれないが、それには相当長い時間がかかるだろう。他の機能は非常に充実している多くのバックアップアプリが、この目的でにはうまく使えないのはとても残念なことだ。
外付けドライブからブートする -- たった今説明した状況が曖昧さの一番少ないものだが、それはまた比較的稀にしか起こらない状況でもある。一方最も起こり得る状況は、これはより多くの混乱を伴いやすいものでもあるが、通常の起動ディスクがまだ存在して機能しているけれども、そこに複製のディスクを繋いで一時的にそちらからブートする場合だ。その複製がちゃんと動作するかどうか確認するためにそうしているのかもしれない（その場合、複製から走らせるのはほんの数分間だけかもしれない）し、あるいは起動ディスクに問題が生じていて、いつもの仕事を続けつつディスク修復ユーティリティを走らせたいのかもしれない。
いずれにしても、まずはここで問題には ならない 点から説明を始めよう。一つには、起動ディスクが外付けかどうかは問題でない。動作速度を別にして考えれば、起動ディスクが内部の SATA ポートに接続されていようと、USB、FireWire、Thunderbolt、あるいは他のどんな方法で接続されていようと、Mac は全く同じに動作するはずだ。だから、このことは少しも気にする必要がない。
もう一つは、複製からブートしている間にクラウドとの同期が起こっても問題でない。例えば、iCloud を使っているならば、カレンダー、連絡先、ブックマーク、その他がバックグラウンドで同期される。複製ディスクの上にある古いデータがクラウド上のより新しいデータを上書きしないかと心配する必要はない。それどころか、実はクラウドにある方が「マスター」コピー（「本物」と呼ばれることもある）なので、あなたの複製ディスク上のデータの方が最新のものに変わる。同じように、Dropbox やその他のクラウドベースのファイル保存サービスを使っているならば、やはりあなたのディスク上のデータをクラウド上の本物を使って最新にしてくれるので、あなたがそのことについて頭を悩ます必要はこれっぽっちもない。
（ただし、電子メールに POP を使っている場合、あるいはルールやフィルターを使って IMAP または Exchange サーバから届く電子メールをローカルのメールボックスの中へ仕分けしている場合は、頭を悩ます必要が ある。複製ディスク上のものは簡単な手順では元のものに適用できない方法で変更されてしまっているので、確信が持てない場合は複製ディスクからブートしている間は電子メールをチェックしない方が安全だろう。）
エイリアスについて心配する必要すらない - 通常は。現在のブートドライブ上にある項目のエイリアスを作れば（これには Finder のサイドバー上の項目や、あなたのログイン項目のリストに並ぶものも含まれる）Mac OS X がそれに対する 相対的 リンクを作成する。つまり、もしもあなたが複製ディスクを作って、その複製ディスクからブートし、エイリアスを開けば、その結果開くものはその複製ディスク上のものであって、元のディスク上にあるものではない。（おそらくあなたはそうなることを望んでいるだろう。）だからと言って、あなたの Mac にスクリプトや、あなたが Terminal で作成したシンボリックリンク、あるいはその他ファイルやフォルダをディスク名を使って参照するポインタが含まれていないとも限らないし、もしもそういうものが存在すれば、あなたが知らないうちに違うファイルやアプリケーションを開いてしまったり、違うディスクにデータを保存してしまったりということが起こり得る。（もしもそのことが心配で、開こうとしているものがどれであるかを絶対確実に知りたいと思うならば、複製からブートしている際はディスクのトップレベルから手動でナビゲートすればよい。）
しかしながら、あなたは気付かないかもしれないが、少なくとも一つの重要なことが違っている可能性が高い。たとえあなたの複製ディスクに元の起動ディスクと同じ名前が付いていたとしても（おそらくそうなるのが最も一般的だろうが）時として少しばかり変なことが起こり得る。Mac OS X は、二つの全く同じ名前のボリュームを同時にマウントさせてくれないからだ。Finder の中では両方が同じ名前を持っているように 見える かもしれないが、もしも既に "Macintosh HD" という名前のボリュームをマウントしていて、二つ目のものをマウントしようとすれば、舞台裏で、二つ目には作業用の異なる名前が付く。(この場合は "Macintosh HD 1" となる。) その理由は、Mac 上では名前によるディスクの区別に依存してたくさんのことが起こっているからだ。名前だけではディスクの区別に曖昧さが生じるということになってしまえば、ファイルが間違った場所に保存される事態が起こりかねない。
通常は、このようなその場限りの改名で、問題なくものごとが進む。けれども絶対確実というわけには行かない。"Macintosh HD" と "Macintosh HD 1" がマウントされている状況で、もしもネットワーク上にいる別のユーザーがあなたの Mac に接続して、ファイルを今の "Macintosh HD"、つまりあなたの複製ディスクにコピーしたとすればどうなるだろうか？ あなたはそれに気付かないかもしれないが、その後あなたがいつもの起動ディスクに戻った時には、あるはずのファイルがもはや存在していない。同じようなことが、ファイル同期アプリや、ソフトウェアのダウンロード、その他のことでも起こり得る。その上、Mac OS X が混乱してしまい、舞台裏でのボリューム名のリストを正しくアップデートしないことも時々あるので、例えば "Macintosh HD" があなたが "Macintosh HD 1" よりも あとで マウントしたボリュームになってしまう状況に遭遇するかもしれない。
他方、複製ディスクの名前を変えても必ずしも問題は解決されない。例えばあなたの通常の起動ディスクが "Cindy" だとして、あなたが一時的に "Kate" からブートしたとすると、今のところは名前のミスマッチの問題を避けられるかもしれない。けれども、後になって、恒常的に "Kate" で起動するようになれば、まだデータを "Cindy" に保存するつもりでいるアプリやユーザーたちが混乱してしまう。結局のところ、私は複製ディスクを元のディスクと同じ名前にしておく方がより良い結果が得られると思うが、問題を起こさないためにも複製の方で走らせている間はいくつかの注意点（すぐ後で説明する）を念頭に置いておくべきだと思う。
それと同時に、もう一つの微妙なバックグラウンドプロセスにも気を配っておくべきだろう。そう、バックアップだ！ 結局のところ、おそらくあなたのバックアップソフトウェアは自動的に動作するように設定されているのだろう。例えば一時間に一度 (Time Machine の場合) あるいは常時 (CrashPlan の場合) といった具合に。通常、Mac をブートした直後はバックアップが即座に始まることはないが、10 分か 15 分以内には走り出すことが多い。それより長い時間にわたって複製から Mac を走らせ続けたい場合はどうすべきだろうか？ いつも通りにバックアップを走らせる（つまり複製の方をバックアップする）べきか、それともバックアップをオフに切り替えるべきか？
一般的に言って、バックアップを走らせ続けても別に害はないし、むしろ利益が大きいと私は思う。あなたのバックアップソフトウェアはその複製ディスクがあなたの通常の起動ディスクであるかのように挙動し、あなたが通常通りに再起動したかのようにしてファイルをいつも通りの保存先へコピーし続けるだろう。それはおそらく、まさにあなたが望むことだ。なぜなら、複製ディスクで走らせている間にファイルを作成または変更すれば、それがバックアップされるからだ。実際のところ、問題が起こりやすいのはそれと反対の場合だ。つまり、あるファイルを変更してもそれが（おそらく定時バックアップの時刻がまだ来ていなかったため）バックアップされなかった場合にはどうなるだろうか？ あなたが通常の起動ディスクに戻ると、そのファイルはもはやそこにはなくて（または古い状態のままで）しかもバックアップにも残っていない。もちろん複製ディスクの方には残っているけれども、それが手に入るのはあなたがその複製ディスクを次にアップデートするより前にそのディスクの中をチェックする気になった場合のみだ。それを忘れて複製ディスクをアップデートしてしまえば、おそらくその新しいファイルは起動ディスク上にないので削除されてしまうだろう。
以上のことをすべて考えに入れた上で、短期間だけ複製からブートしなければならない場合にあなたが守るべき注意点として、私は次のことをお勧めする：
ファイルの作成・変更・ダウンロードを避けることができるならば、なるべく避けよう。避けられない事情がある場合は、そのファイルをクラウドに同期するか、通常の起動ディスクにコピーするか、バックアップするか、あるいはその他の方法を使って、あとで通常のディスクに戻ってもそのファイルが使えるようにしておこう。
通常の、バージョン機能付きのバックアップ (Time Machine や CrashPlan など) を、いつも通りに動かしておこう。ただし、いつものディスクに戻る前に（すぐ前の項目で述べた通り）作成せざるを得なかったファイルが間違いなくバックアップソフトウェアでバックアップされたことを確認しよう。
ブート可能な複製に対しては、スケジュールで動くアップデートをすべてオフにしておこう。あなたが絶対に望まないのは、あなたがテストをしている最中に複製ディスクが勝手に自らをメインの起動ディスクの上へクローンしたり、あるいは何かのソフトウェアが勝手な行動をして元のディスクのクローンを現在ブートしている複製ディスクの上へクローンしたりし始めるといった事態だ。
他のユーザーたちがあなたの Mac に接続させないように、とりわけファイルをアップロードさせないようにしよう。
別の Mac からブートする -- もう一つ、考えておくべき状況がある。ある Mac を、別の Mac の起動ディスクの複製でブートする場合だ。例えば、あなたが iMac の起動ディスクの複製を作っておいたとして、その iMac を修理のために店舗に持って行かなければならなかったとしよう。修理を待つ間、あなたはその複製を MacBook Pro に繋いで、それが iMac である「ふりをして」使うことにする。その MacBook Pro が iMac で走っていたものと同じバージョンの Mac OS X に対応している限り、このお膳立ては問題なく働くはずだ。ただし、もう皆さんは予想して下さっているとは思うが、注意点が二つある。
まず第一に、この状況はさきほど説明した状況、つまり Mac を一時的に別のドライブからブートする状況と見かけ上はよく似ているけれども、状況が継続する時間枠が長い（数時間でなく数週間になるかもしれない）ところが違っている。だから、ファイルの変更や電子メールのチェックなどの作業を避けるという方針は現実的でない。そこで、この MacBook Pro 上の複製ディスクは通常あなたが iMac の内蔵ドライブを使うのと同じように使うことをお勧めしたい。そして、iMac が修理から戻ってくれば、外付けの複製をそちらに繋ぎ、逆向きクローンの作業（つまり、外付けドライブの内容すべてを iMac を起動した内蔵ドライブの中へコピーして戻す作業）をすればよい。
第二に、あなたの MacBook Pro が複製で走っている間、それはほとんど あらゆる面で iMac である かのように走る。ファイル共有やスクリーン共有といったものでは、iMac の名前さえ使うことになる。けれども、すべての Mac はそれぞれ固有の識別子をいくつか持っている。シリアル番号、UUID (universally unique identifier)、各ネットワークインターフェイスごとの MAC (media access control) アドレス、といったものだ。ソフトウェアによっては、それが認証あるいはライセンスを受けたものと同じ Mac で走っていることを確認するために、これらの識別子のどれかをチェックすることがある。
最も一般的な実例が iTunes だ。その iMac があなたの iTunes アカウントを利用するように認証されているならば、その iMac のディスクの複製を使って MacBook Pro を起動しても、その MacBook Pro が自動的に認証されるわけではない。その MacBook Pro をまだ認証していないのならば、改めて手動で認証しなければならない。（iTunes で、Store > Authorize This Computer を選ぶ。）けれども認証回数を既に使い尽くしている場合は（Apple は一人あたり認証を五回までに制限している）他のコンピュータの認証を外すか、あるいはすべての認証を解除しない限り、このコンピュータであなたの iTunes アカウントを使うことはできない。（Apple は認証解除を一年に一回のみに制限している。）他のソフトウェアにも、同じような（あるいはもっと酷い）苦難を要求するものがあるかもしれない。
心配する必要はない -- こうやって説明してくるとやたら複雑に聞こえるかもしれないが、Mac を複製ディスクからブートするのはたいていの場合単純なことであって問題は起こらないだろう。それでも、万一に備えて、背景で何が起こっているかをしっかり把握しておくに超したことはない。特に、その複製ディスクをかなり長期間使うことになりその間ファイルを作成したり変更したりすることになるのかどうかについて、よく考えて心構えをしておくべきだ。それが当てはまらない場合は、単純にそのまま元のディスクに戻しても心配ない。けれども、かなり長期間にわたってその複製ディスクを使う場合は、それが終わった後に元のディスクへ逆向きクローンの作業をする必要がある。
最後にもう一言： 複製は、できるだけ頻繁に更新しておこう。一時間ごとに更新するのはやり過ぎだろうけれども、一日に一回か二回というのは悪くない考えだと思う。忘れないで頂きたいが、複製を最後に更新してから長い時間が経てば経つほど、そこからブートする必要に迫られた際に、欠けたファイルや古過ぎるファイルに直面する可能性が高くなり、その復旧のために大変な苦労をしなければならなくなるのだから。
コメントリンク13618 この記事について | Tweet リンク13618
文： Josh Centers: [email protected], @jcenters
訳： 亀岡孝仁<takkameoka@kif.biglobe.ne.jp>
Google は Google Reader RSS 集約そして同期サービスを 1 July 2013 に終了すると言っている。(話を簡単にするために、我々は馴染みの言葉である "RSS" を、 RSS と Atom ニュースフィードフォーマット及び配給のニュースフィードの全体的なエコシステムの両方を意味するものとして使用する。) Reader は出版者に対してのトラフィックを、同社の Google+ サービスよりも多く生成しているという報道があるにも拘わらず、この決定はなされた。Web クライアントが無くなると言うことだけでも悪いのに、多くの RSS アプリ開発者は同期処理と検索のアップデートのために Google Reader に依存してきたので、多くの独立の RSS リーダーの将来は疑わしい。これには、現在 Black Pixel に所有されている尊敬すべきNetNewsWire for Mac OS X も含まれる。(Google Reader の終焉が何を意味するかについて更に考えたければ、Adam Engst の "Google Reader 消滅に際しての考察" 14 March 2013 を参照。)
開発者達は、Zite 及び Digg も入るが、Google の発表によって残されたギャップを埋めようと懸命の努力をしている。RSS 競争は続いており、Google Reader が消滅する時までには新しい動きも見えてくるであろう。しかしながら、それでは現在の Reader ユーザーの役には立たない。幸いにして、移行の苦しみを和らげてくれる既存の製品も幾つかある。Online Journalism Blog の Paul Bradshaw は Google Reader 代替品についてのコメント募集を載せ、そして嬉しいことに、その結果をスプレッドシートに纏め てくれたので、どんなものがあるのか調べたり、競合製品を比較したり出来る様になっている。
Google から Takeout を -- まず最初にやるべきことをやろう。Google Reader からあなたの加入契約データをエクスポートする。こうすれば将来どの時点でも他の RSS リーダーに切り替えられる柔軟性を持てる。Google はそのデータ移植サイトである Google Takeout 経由での直接的な方法を提供している。そのサイトを訪れ、もし要求されたらログインし、そして Choose Services ボタンをクリックする。出てくる一連のボタンの中から、Reader をクリック、そして Create Archive をクリックする。ファイルそのものは巨大ではないであろうが、Google がそれを生成するのには恐らく多少の時間がかかるであろう。もし待ってなんかいられないというのであれば、"Email me when ready" のチェックボックスを選択しそしてその間何か他の事をやることも出来る。
Google Reader エクスポートは、ダウンロード出来る Zip ファイルとして纏められる。その中には各種のメタデータをもった幾つかの JSON ファイルがあるが、一番重要なのは ssubscriptions.xmlと呼ばれるファイルである。これは OPML フォーマットの XML ファイルであり、RSS リーダーに対する標準的なインポートとエクスポートのフォーマットである。このファイルであれば、殆ど如何なる RSS クライアントへでもインポート出来、あなたの Google Reader 加入契約を復元出来る。
(もし NetNewsWire を使って Google Reader と同期しているのであれば、あなたの加入契約は手元でもエクスポート出来る。同期を完了していることを確認し、それから、File > Export Subscriptions を選択、OPML ファイルを作成する。)
簡単な解をフィードして -- もしワンクリックの移行を探しているのであれば、最善の策は Feedly であろう。これは Google Reader クライアントで、色々な形態が用意されていて、Web クライアント, Chrome エクステンション, Safari エクステンション, Firefox アドオン, iOS アプリ, そして Android アプリが含まれる。Feedly クライアントの一つからあなたの Google Reader アカウントにログインすると、あなたの加入契約を魅力的な、雑誌スタイルのフォーマットで表示してくる。これはタッチスクリーンにはピッタリである。
Feedly に関して最も説得力ある点は、その見栄えではなく、間もなく提供される Normandy サービスで、これはあなたの機器間であなたの加入契約を同期してくれる。Google Reader がその扉を閉じる時、Normandy は舞台裏でそれに取って代わる。それが継ぎ目のない移行であることを望みたい。他の開発者もまた Normandy に対するサポートを組み込める。
Fever っぽい -- Feedly は素晴らしいが、難点は RSS を読むためにもう一つの企業に依存しなければならないことである。もし少々のシステムアドミンなら手におえると言うのであれば、Fever は検討に値する。Fever は自己ホスト型のニュースリーダーとフィードアグリゲーターである。値段は $30 で、自前の Unix サーバーを用意し Apache, MySQL, そして PHP が走っていなければならない。もし私が何を言っているのか皆目見当もつかない人には、Fever は向いていない。
Fever と Google Reader は機能的には同等である。Fever の中のニュースはその Web クライアントを通して読む。Fever と Google Reader の違いは、Fever は記事を "温度" によってソートしそして集める。この温度とは、その記事がどれだけ多くのリンクとどれだけ多くの議論を生成したかによって計算される点数である。
Fever は、iPhone や iPod touch のための Reeder RSS クライアントのファンにとっては興味深い、というのもそれはもう既に Google Reader に加えて Fever もサポートしているからである。残念ながら、Mac 及び iPad バージョンの Reeder は Fever をサポートしないので、これらのプラットフォーム上では Fever の Web アプリに頼らなければならない。しかしながら、Fever は Mac 上でのサイト専用のブラウザ Fluid 経由でなら働くので、その Web インターフェースを Mac アプリに変え、そして Dock には未読の項目の数まで表示する。iPhone と iPod touch のための他の専用 Fever クライアントが欲しければ、Sunstroke がある。
いい Vibe だ -- Google は、単に Reader を殺すだけではなく、個人化された Web ポータルである iGoogle も 1 November 2013 に閉じようとしている。幸いにして、両方を置き換えることの出来る昔懐かしいものがある： Netvibes である。
Netvibes は数年前に個人化された Web ポータル、iGoogle の様な、を始めたが、それ以降 RSS リーダーとしても進化した。クリック一つでモード間の切り替えが出来る。ウィジェットモードでは、個々のフィードフォルダはタブとして現れ、そして個々のフィードがそれ自身のウィジェットとなる。このモードは読むためには使い辛いので、大抵の人は恐らくリーダーモードの方を好むであろう。このモードでは、フィードはより伝統的な形で提供される。
Netvibes の更なるうまみは、あなたのインターフェースに単なる RSS フィード以上のものを付け加えたことから来ている。メールのためのウィジェット、Google Analytics、天気、等々である。また、まずまずと言えるモバイルサイトもある。もっとも何らかの理由からそれを iPhone ホームスクリーンに保存しても、結果として現れる Web アプリは iPhone 5 のスクリーンを一杯にはしない。
残念ながら、Netvibes は年齢を感じさせる。そのデザインは旧式だし、動きも遅くそして不格好な感じがする。しかしながら、もし Google Reader と iGoogle の両方を失うことで痛みを感じているのであれば、これは当座しのぎとしては悪くない。そして Netvibes はあなたのフィードをエクスポートさせてくれるので、後になってもっといい所が見つかったら簡単に引っ越しできる。
RSS: まだ死んではいない！ -- Google は Google Reader の停止に対して、ユーザーにも開発者にも十分な対応時間を与えなかった。既に代替策も幾つかあり、そしてこれから登場するものもあるであろうが、開発者がアップデートするのを止めたり或いはユーザーが期限までに移行しなかったりした場合、Google Reader の同期能力に依存している多くのアプリはこの移行で壊れてしまうであろう。
しかし、RSS 信奉者よ、恐れることなかれ。有用なインターネット技術は、絶え間なく変化し続ける環境に合わせて常に進化している。電子メールの持続性に勝る証拠は無い。メールは多くの職業人に対する通信の基本的形態であり続けている。メールはオープン標準に基づいており、中央権力もいないし、そして巨大企業によって支配されることも有りえない。Google+, Facebook, そして Twitter と言ったソーシャルネットワーキングとはそこが違う。Google Reader の死に対するオンラインでの怒りが本物だとすると、RSS 経由での Web アップデート配給や Atom フィードは、近い将来においても意味のあるものとして生き残るであろう。
FUD - 恐怖、不安、そして疑念 - という化け物に苛まれるよりも、RSS の愛好者はもしろ喜ぶべきである。Google Reader は、良好な解を無料で提供することで、長年の間、全 RSS 世界を実質的に独占してきた。そしてその来るべき死を見越して、数えきれない程の開発者が、単に Google Reader を置き換えるだけでなく更にそれを超越していくものを意図した代替策を作り出そうとしている。
コメントリンク13642 この記事について | Tweet リンク13642
文： Adam C. Engst: [email protected], @adamengst
訳： Mark Nagata <nagata@kurims.kyoto-u.ac.jp>
私が特にそれほど RSS リーダーを使ったことがないことは真っ先に認めよう。確かに、私の Mac には NetNewsWire があって、20 か 30 ほどの RSS を購読しているが、起動するのは年にほんの数回、TidBITS の内輪の RSS フィードに何か問題が持ち上がったときくらいだ。私は Google Reader アカウントも持っているが、そこにログインするのもやはり年に数回程度だ。私が RSS でするほんの少しのことは、Blogtrottr の RSS-to-email サービスを経由してすべて電子メールに送っている。（こうして RSS の連続的媒体を電子メールの連続的媒体へと翻訳している。インターネットの先駆者 Brad Templeton がこの問題に見解を述べているのをぜひお読み頂きたい。その中で彼は、 連続的な媒体、ブラウズされる媒体、抽出される媒体の違い.を見事に切り分けて論じている。）
だから、2013 年 7 月 1 日をもって Google Reader を終わりにするという Google の発表も私にはあまり関係がないのだが、数多くの忠実なる Google Reader ユーザーたちの悲しき叫び声を見過ごすことは不可能だ。彼らは問いかける：「いったいなぜ私たちを見捨てるのか、Google よ？ 私たちはこれからどうすればいいというのか？」第二の質問に対するいくつかの実用的な答については、記事“Google Reader の代替を探る”(2013 年 3 月 17 日) をご覧頂きたい。そして、第一の質問については、Google が公に言明した「年を追って使用度が減った」という言葉が唯一の手掛かりだろう。
でも、この動きの背後には何があるのだろうか、そして、より一般的にこれは何を意味するのだろうか？ 一つには、クラウドベースのツールへの依存を避けることがますます難しくなりつつあるというのに、インターネット上にあるあらゆるものはいつ何時予告なく消え去るかわからないという事実がある。また、ツールとプラットフォームとの間にあるいくつかの興味深い差異をも示唆しているし、さらには出版者たち（インターネット上のコンテンツを制作する人は皆、つまりはすべての人が、出版者の役割を果たしている）と、Google、Facebook、Twitter といったとてつもなくパワフルな配布者との間にますます高まる緊張関係をも示している。さらに、Google Reader はインターネット上に無尽蔵にある情報の量が私たちに仕掛けてくる静かなる戦いの、また新たな犠牲者であるとも言える。
煙となって消える -- 諺に言う通り、変化を避けることはできないし、私たちはそれに慣れて行かなければならない。けれども私がここで言いたいのは、実際にはそれは本当でないということだ。たいていの大人にとって、毎日はそれほど変化に富んだものでなく、似たようなことが日々繰り返される。人生の中で、たいていの人は一人か二人の配偶者しか持たず、一人か二人の子供しか持たず、片手の指で数えられるほどの家しか持たず、大して多くない数の職業にしか就かない。Tonya と私は 45 歳だが、大人になってからこれまでたった 5 台の自動車しか持たず、最初の頃の中古車を別にして、初めて新車を買った 1991 年以後の 22 年間に限ればたった 3 台だ。仕事の性質上私たちはたいていの人より多くの Mac を所有したが、それでも私たちが新しいコンピュータを購入するのは 3 年から 5 年に一度だ。来る日も来る日も、私たちは先週や先月とほぼ同じやり方で人生を生き、大まかに言ってしまえば、毎年毎年その前の年とほぼ同じことを繰り返している。
こんな風に話を始めたのは、私たちが（ここでもやはり私は一般的な話をしている）ものごとが同じであることに慣れるものだと言いたいからだ。なぜならものごとは実際同じであることが多いからで、それは私たちが使うツールにも、私たちが慣れ親しんだ仕事のやり方にも当てはまる。昔は、今ほど頻繁に変化は起こらなかった。けれども今日の非常に競争の激しい世界においては、巨大な会社たちが想像もできないほど高い賭け金のために戦っていて、正気とは思えないほどの変化率が競争のために必要となっている。Apple も Google も Microsoft も、うんざりした新しいスマートフォン顧客の目にフレッシュで最新流行のものに映るべく、それぞれのモバイルオペレーティングシステムのアップデート版を出し続ける必要があるし、Facebook も Twitter も Google も、それぞれのソーシャルネットワーキングエンジンやインターフェイスを改訂し続けることで聴衆の心を引き付け続けようとしている。
けれども何か大きな変化が起これば、その度に多くの人々に心理的圧迫が襲いかかる。もちろん、ワクワクするような新機能に喜びを感じて、自分の仕事のやり方を調整し続けなければならないのを苦にしない人たちもいるが、定着した習慣と時の試練を経たやり方に依存しなければ生産的になれない人にとっては、変化はフラストレーションの元となり、心身を疲れさせ、圧倒され、心底恐ろしいものとなる。少なくとも Google は Google Reader のスイッチを切る前に数ヵ月の警告期間を提供しているし、Apple は MobileMe から iCloud への大規模な以降の前にさらに長い警告期間をユーザーに提供した。でも、例えば iTunes 11 では、iTunes 10.7 との間にこれほど見栄えの違いも大きく実験的な変更も施されることをあらかじめ知らなかった多くの人たちが散々髪を掻きむしり歯を食いしばる羽目になった。iTunes 11 が iTunes 10.7 に出来たことの事実上ほとんどすべてを出来たという事実は、彼らにはどうでもよかった。彼らにとって重要なのは、見慣れない世界にいきなり放り込まれて、以前と変わらないというその機能に手を届かせるための道筋を一生懸命に探り出し、曲がりくねった道の途中に目印となる風景を目に焼き付けなければならないということだった。（2012 年 11 月 30 日の記事“改装 iTunes 11、iCloud ストリーミングと新しい MiniPlayer をもたらす”参照。）
問題の核心にあるのは、クラウドを経由した統合だ。Google Reader についてユーザーたちが抗議しているのはただ単に別の RSS リーダーへの切り替えを余儀なくされる人たちがいるからという理由だけではない。もちろんそういう人たちは大勢いるのだが、もっと大きな理由は多くの RSS リーダーが依存する同期サービスを Google Reader が提供していたからなのだ。私たちは、単に一つの RSS リーダーを失うだけには止まらない。多くの開発者たちが構成要素と考え、その上にそれぞれのエレガントなソフトウェアを構築することができていたものを失うことになる。開発者たちはすべて、お互いの肩の上に乗り、互いに支え合って構築するものだが、クラウド統合が盛んになるにつれて、それらの肩が不安定なものとなりつつある。iTunes 11 についてもそのことは言える。今でも iTunes 10.7 はまだ機能するけれども、iTunes Store との統合や、新たな iOS ハードウェアの登場が、いずれ間違いなく 10.7 の終焉の鐘を鳴らすだろう。
ここに喜ばしい解答を私は思い付くことができない。私は Google Reader の積極的ユーザーではないけれども、そんな私もさまざまのクラウドサービスに大きく依存している。もしもそのうちの一つが消滅すれば、私は途方に暮れるだろう。この種のことが起こるのを私は何度も見てきたので、他のいろいろな変化、例えば iWeb や iDisk や Google Sync や、あるいは Twitter が開発者向け機能を削除したことについても、一部の人たちに見られるほど被害者意識を持って受け取ることは（率直に言えば特に年配の人たちにそういう傾向が強いようだ）私にはできない。私が提案できるのは、皆さんがご自分の使っているツールやシステムについて思いを巡らし、もしも何かが消滅すればどうなるかを考えてみて欲しいということだ。データ喪失について昔から言われている通り、それは消えるか否かという問題ではなく、いつ消えるかという問題なのだから。
ツールかプラットフォームか -- Twitter が議論に登場したので、Google Reader の閉鎖が提起したもう一つの話題を考えてみよう。それはツール対プラットフォームの問題だ。Twitter が人気を得たのは、そのオープンな API によるところが大きい。オープンな API のお陰で、開発者たちはさまざまの種類の Twitter クライアントや、Twitter データに基づくウェブサービスを作り出すことができた。けれども Twitter 社は彼らに可能なことの範囲を狭めてきている。その理由は主として、Twitter のビジネスモデルが広告の販売に依存しているからで、ユーザー体験を Twitter がコントロールできて初めて広告の表示が保証されるからだ。本質において、Twitter はツールであることを止めてプラットフォームとなった。そしてその過程で、そこに出来た空白を埋めるために App.net が出現した。（2012 年 8 月 28 日に記事“新ソーシャルネットワーク App.net、チャットと広告の上を目指す”参照。）
Google もまた、長らく数々のツールの提供者であったし、Google Reader はその一つであった。特に同期サービスとしてその性格が強かった。Google のツールの多くは、自慢の「20 パーセントプロジェクト」制度から生まれたものだ。エンジニアたちは、勤務時間の 20 パーセントを何でも自分の興味の向くままに費やしてよいとされていた。その結果として、数々のツールやサービスが生まれ花開いたのだった。けれども今や、それらの花々はむしろ、Google をそのコアビジネスから脇道に逸れさせる雑草のようにも見える。中でも注目すべきコアビジネスは、Google が努力の大部分を注いできた Google+ だ。何もせず放置すればいずれ Facebook のソーシャルな手法が Google 検索よりも魅力的な広告プラットフォームとなるに違いないという意識が、Google+ を牽引してきた。けれども Facebook や Twitter と同じく、Google+ もまたプラットフォームであってツールではない。Google が API を用いて Google+ のいくつかの側面をオープンにすることはあるかもしれないが、Google Reader のごとくにユーザーが気付かないままバックグラウンドで使えるようになるとはどうしても思えない。
各社がツールからプラットフォームへ移行するこの傾向は何も驚くには当たらないし、ユーザーにとってもプロバイダにとっても理に適っている。プラットフォームは首尾一貫したユーザー体験を提供するので、技術に強くないユーザーたちが増えても使いやすく理解しやすいものとなれる。またプラットフォームは大体において自己完結しているので、それを管理する会社がコントロールの共有をしたり同じプラットフォーム内部の競争相手を心配したりする必要がない。さらに、プラットフォームはそこを離れるのが難しい。Facebook のルック＆フィールやコンテンツに既に慣れた人は、Google+ にわざわざ乗り換えようとは思わないだろう。それはまさに、Apple が iOS に用いている戦略がユーザーたちが Android や Windows Mobile に乗り換えるのを防ぐことを目的にしているのと同じだ。（もちろん、Google も Microsoft もこれと同じ姿勢で取り組んでいる。）
けれども、ツールが失われるのは憂慮すべきことだ。それは、家を建てるのにもはや大工たちが道具を手にすることがなく、ただ工場生産（プレハブ）の構造物をトラックで運び込んでドスンと下ろせば終わりなのが憂慮すべきと同じ理由だ。ツールがあるからこそ、創造力に溢れた人たちが他に誰も思い付かなかったようなものを築くことができ、金槌と鋸がただ単に家を建てること以外にも遥かに多様な目的に使えるのと同じように、デジタルなツールも当初それらが意図されたものを遥かに超えた目的に使えるだろう。私自身は App.net を Twitter に似たマイクロブロギングサービスとして使いこなすだけの時間の余裕はないが、他の人たちがその上にものを築く基盤構造を提供するサービスとしての App.net の役割を心から応援したいと思う。Google がツールのビジネスからますます離れつつあるのはとても残念なことだ。それは彼らにとって理に適ったことかもしれないが、そこに空いた空白を他の会社たちが埋めてくれることを願わずにはいられない。
出版者か配布者か -- Google は Google+ について、Google Reader の閉鎖に関連したことは何も述べていないが、批評家たちの多くは Google Reader の時は既に過ぎたと示唆している。なぜなら今や私たちは Twitter、Facebook、Google+ を経由してニュースを得ている（まだ抵抗している人たちも、得るべきである）からだと。そして確かに、彼らソーシャルネットワークの達人たちは、聞く耳を持つどんな会社に対しても、今すぐ tweet を始めるか Google+ ページを持つか Facebook で "like" を稼ぐかし始めなければあなたの会社は消える運命にある（そう、消える運命にあるのだ！）とまくしたてるだろう。
けれども、ソーシャルネットワークには一つ問題点がある。いやいやもちろん、ソーシャルネットワークには膨大な数の問題点があるが、ここで私がさきほど述べたプラットフォームの問題と結び付けて考えたい一つの問題は、私たちは皆それぞれに出版者であって、一方ソーシャルメディアのプラットフォームは、Google+ も、Facebook も、Twitter も、私たちの配布者となっているという点だ。彼らが私たちのコンテンツに依存するのは当然だが、私たちの方はそれより遥かに大きく彼らに依存している。そしてその点こそ、警鐘を鳴らすべきところなのだ。
もちろん、あなたが昼ご飯に何を食べたか投稿したり、可愛い猫の写真を投稿したりしているだけなら、自分のコンテンツに恒久的管理権を持っていないことなどおそらく気にならないだろう。けれども、もしもあなたが会社を代表していて、その製品について情報を広める必要があるのなら、自分には管理権がなくいつ消え去るかもわからないし不当に高い料金をいきなり課し始めるかもしれないプラットフォームに全面的に依存するなど真っ平ご免だろう。あなたが会社のブログとそれに付随した RSS フィードを出してきたのなら、Google Reader 喪失によって読者を失うかもしれないけれども、少なくともあなたはまだ自分のコンテンツに完全な管理権を持っているし、読者たちが再びあなたを見つけ出すのも簡単だ。（私は昔流のやり方が好きなので、もっと良い方法は独自のメーリングリストサーバを持ち電子メール経由で連絡を続けられるようにすることだと提唱したい。電子メールならば誰もあなたの足をすくうことはできないからだ。）
もっと悪いことに、ソーシャルネットワークはストリームだ。私が見てきた経験からすると、たいていの人たちはノンストップでソーシャルネットワークを監視したりしない。とりわけ、近しい友人以外の情報源を多数フォローしている場合はそうだろう。現状のように膨大な数の投稿が流れていれば、たいていの人はしばらくの間オフラインでいた後もわざわざ時間を遡って情報を確かめるようなことはしない。つまり、あなたがどんなことを投稿しても、それがたまたま見る人の注目に触れなければ、全く気付かれずに過ぎ去るだけの可能性が高い。対照的に RSS リーダーならば、確かにそれと特定して注目することは必要だけれども、個々の見出しをそれが読まれるまで、または既読とマークされるまで、キープし続けてくれる。
無限との戦い -- 最後に、そしてこの点についてはまた別の記事でさらに探求してみたいと思っているが、インターネットに溢れる無尽蔵の量の情報を相手に私たちが苦闘しつつある（そして敗れつつある！）戦いにおいて、Google Reader はその犠牲者であるという面が多分にある。
要点をまとめれば、初めに電子メールがあり、その後間もなく Usenet ニュースが生まれた。インターネットのテクノロジーとして電子メールは止めようのないゴキブリのごときものであるが、Usenet ニュースはあまりにも膨張し過ぎたため、その購読を扱うための非常に高度なソフトウェアを生み出した後、脚光を浴びる位置をウェブに譲り、自らの巨体の重みにゆっくりと砕け去った。ウェブの初期の時代にはウェブサイトの数も少なかったので、自分のホームページを作った私たちは皆、お気に入りのサイトのリストを作ったものだ。その後ウェブサイトの数があまりにも多くなると、人の手で作られた案内所、例えば Yahoo のようなものが登場して、インターネット上のすべてのサイトをカテゴリー分けしてくれた。けれどもやがてそうした案内所は検索エンジンによって脇に蹴りだされた。これもまた、サイトの数があまりにも増え、一つのサイトの中のコンテンツも多くなったためにカテゴリー分けが不可能になってきたからだった。それから、プロフェッショナルな出版とブログという二つの大きなニュースが到来し、それまでウェブサイトのリストを作っていた人たちは皆、ブログを始めるようになった。あまりにもたくさんのブログがあって定期的にチェックすることもできないので、毎日何百と届く見出しを監視できるための方法として RSS が必要となった。また、Slashdot や Daring Fireball といった監督者付き集約サイトもさほど遅れをとらずに続いた。なぜなら、RSS リーダーについて行くことさえ大変だという人も多かったからだ。そして Twitter と Tumblr と Facebook が興隆するに伴い、短いメッセージや興味深いリンクだけを投稿する方がずっと簡単にできるようになって、個人的ブログを運営する努力さえ正当化するのが難しくなるに至った。
Google Reader も、他の RSS リーダーと同様、インターネット上の情報の量を制御し続けるための試みであった。けれども、他のその種の試みと同様に、結局それは失敗する運命にあった。インターネット上の情報の量は今や、あらゆる実用的目的において、無限大だ。実際、現状はそれよりもっと悪い。私たちの興味を惹く情報だけでさえ、さらには私たちの興味を惹く情報についての一日分のニュースだけでさえ、本質的に無限大となっている。有限の人生を生きる私たちにとって、それらすべてを読み尽くすことは不可能だという意味だ。（もちろん、興味の対象がそれほど幅広くない人たちがいることは知っているが、例えばスポーツチームを一つか二つだけ、あるいは有名人を数名だけフォローするのでさえ今や不可能に近くなっている。）
さきほど触れた達人たちは、必要なニュースのすべてを RSS リーダーでなくソーシャルメディアから得ているのだと称している。彼らは基本的に、自分たちの選んだ RSS フィードの量に圧倒され、それよりも Twitter や Facebook や Google+ の方が扱いやすいと思うと言っているのだ。そして実際、同じ興味を持つ人たちをフォローすれば、価値ある投稿やリンクという見返りが得られる。けれどもこのやり方にはおそらく予期しなかった問題点がいくつかある。
そうやってあなたが得ることができるのは、高度に選択された情報だが、それはあなたでなく他の人たちが選択したものだ。それは良いことかもしれないが、良くないことかもしれない。また、投稿を見逃す可能性も大きい。一晩オフラインにして眠れば、次の朝にすべてに追い付くのはあまりにも面倒だ。これもまた、あなたの人生における情報量を削減してくれるので良いことかもしれないし、あなたが非常に重要と思うものを見逃してしまうのならば悪いことかもしれない。いずれにしても、良いものはしばらく話題に上り続けるのかもしれない。ずっと以前から私は、自分が興味あるのはメインストリームのニュースだけ、なぜならそういうものは二週間経ってもまだニュースのままでいるから、という冗談を言い続けてきた。
とは言うものの、一人の人をフォローして、また一つの会社をフォローして、新しい「友だち」を数人承認し、あるいは誰かを輪の中に加え、といったことを続けていると、やがてきっとソーシャルメディアサービスさえも、同じように無限大の、魂を砕くパワーに押し潰される運命にあるに違いないと私は思う。それは Usenet ニュースグループが、Yahoo のウェブサイト案内所が、そして今や Google Reader が、押し潰されたのと同じことだ。いや、既にその日が来ている人たちも多いに違いない。
公平のために言えば、Joe Kissell が記事“壊れているのはメールではなく、あなたの方だ”(2013 年 2 月 23 日) で、この問題を正しく認識している。電子メールが壊れているのではない。RSS リーダーが壊れているのではない。ソーシャルネットワーキングサービスが壊れているのでもない。壊れているのは私たちだ。私たちは有限の存在であると同時に、幅広いものごとに興味を持つ能力を生まれつき備えている。異なる人々、異なる種族、異なる権力、異性、社会的地位、そして もちろん 子猫たちに対する興味を。 無限を相手にしたこの戦いにおける私たちの唯一の武器は、セルフコントロール（自制心）だ。あまりにも多くのメーリングリストを購読すれば、あまりにも多くのニュースグループを読めば、あまりにも多くのブログを RSS 追跡すれば、あまりにも多くの人々をソーシャルネットワーキングサービスでフォローすれば、その具体的内容がどうであれ、ほしいままに情報を取り入れ過ぎるならば、どんなに優れたツールを使っていたとしても、いずれあなたは間違いなく無限によって押し潰されてしまうだろう。
コメントリンク13636 この記事について | Tweet リンク13636
文： TidBITS Staff: [email protected]
訳： Mark Nagata <nagata@kurims.kyoto-u.ac.jp>
Snow Leopard および Lion 用セキュリティアップデート 2013-001 -- Apple が Snow Leopard と Lion 用にセキュリティアップデート 2013-001 をリリースした。それぞれの大猫ごとに二つずつのバージョンがある。Snow Leopard 用 (316.63 MB) と Snow Leopard Server 用 (391.63 MB)、それから Lion 用 (31.42 MB) と Lion Server 用 (79.33 MB) だ。今回のアップデートはさまざまの脆弱性を塞いでいる。主なものとしては、Apache の HTTP 認証、Podcast プロデューササーバの Ruby on Rails による JSON データ処理、QuickTime で MP4 ファイルを開いた際のバッファオーバーフローなどがある。修正点の完全なリストは Apple サポートページにあって、今回のセキュリティアップデートと、最近リリースされたばかりの Mountain Lion アップデートに含まれるもの、双方ともについて詳しく述べている。（2013 年 3 月 14 日の記事“OS X 10.8.3 Mountain Lion、なかなか直らなかったバグを修正”参照。）今回のセキュリティアップデートはまたマルウェア除去ツールも走らせるようになっていて、何かが除去された場合に限りそのことを通知する。Apple が今回のアップデートを 10.6 Snow Leopard 用にもリリースしているのは興味深い。これまで Apple は、最新の大猫より一つ前のバージョンまでに対してのみセキュリティアップデートを継続するのが通例だったからだ。(無料)
Security Update 2013-001 for Snow Leopard and Lion へのコメントリンク:
MacBook Pro Retina SMC Update 1.1 -- Apple が MacBook Pro Retina SMC アップデート 1.1 を出した。グラフィックスを多用するゲームを 15 インチ MacBook Pro Retina ディスプレイモデルでプレイする際にフレームレートが「まれに低下する問題」に対する修正を提供している。また、Power Nap やスリープ解除に関するバグ修正、およびファン制御に関する問題の修正も、この SMC (System Management Controller) アップデートで施される。後者の問題についてリリースノートには詳しく述べられていないが、Apple サポートフォーラムでも詳しく取り上げられ Geek.com の記事にも載った、ファンが過度に活動する問題に対処していると思われる。インストール後は、SMC がバージョン 2.3f35 にアップデートされる。(無料、504 KB)
MacBook Pro Retina SMC Update 1.1 へのコメントリンク:
Pear Note 3.1 -- Useful Fruit Software が Pear Note 3.1 をリリースし、Mac の Retina ディスプレイにフル対応した。このマルチメディアノート取りアプリにはまた、アップデートされたばかりの Pear Note for iOS 2.1 の中で（授業の中で写真やスライドを使うようにして！）画像を使う機能への対応が追加され、書類の保存フォーマットをアップデートして書類が iOS アプリからも読めるようにした。古い Pear Note 書類で画像を含むものについては、いったん開いて保存し直すことを Useful Fruit は勧めている。それをすれば iOS アプリでも読めるようになる。今回のリリースではまた、スライドが逆向きに動くようになっていた保存のバグ、特殊文字を含んだ書類を共有すると Dropbox でホストされた場合に表示が不正になっていた問題、Spotlight 検索結果と Quick Look 生成ツールに関係するバグも修正している。さらに、Mac App Store 版が今回からサンドボックス化された。(新規購入 $39.99、無料アップデート、4.6 MB、リリースノート)
LaunchBar 5.4.2 -- Objective Development が LaunchBar 5.4.2 をリリースし、このキーボードベースのランチャーにおけるアクション、サービス、アプリケーションの索引付けに改善を施した。LaunchBar の索引付けエンジンに全般的なパフォーマンス改善がなされたのに加えて、今回のアップデートでは実行可能シェルスクリプトがより信頼性をもって（たとえファイル名拡張子が付いていても）認識されるようになり、アプリケーションの索引付けで iOS アプリを無視するようになり、1Password 索引付けを（特に複数のバージョンの 1Password がインストールされているシステムで）改善している。このリリースではまた、従来使っていた iTunes の汎用カテゴリーアイコン（アルバム、ジャンル、プレイリスト、その他）を専用のアイコンに替え、Play from Album オプションが選択されたトラックからでなくアルバムの冒頭から再生を始めていた問題を修正している。最後に、LaunchBar 5.4.2 ではコピー操作の際 (Command-C でなく) マウスを使った場合にコピー元の判定にバグがあったのを修正するとともに、Instant Send 経由でラベルの付いた電子メールアドレスを送信する際の問題と、Instant Send や Clipboard History で二重引用符の表示がおかしくなっていた問題も修正した。(新規購入 $35、 TidBITS 会員,には 20 パーセント割引、無料アップデート、2.5 MB、 リリースノート)
Microsoft Office 2011 14.3.2 および 2008 12.3.6 -- Microsoft が Office 2011 14.3.2 および Office 2008 12.3.6 をリリースした。いずれも「ユーザーが特別に細工された電子メールメッセージを開くと情報漏えいが起こる」可能性のあったセキュリティ脆弱性に対処するものだ。Microsoft のウェブサイトにあるセキュリティ情報によれば、これらのアップデートにより、いずれのバージョンの Microsoft Office for Mac も外部ソースからコンテンツをダウンロードする際にはユーザーの承諾を要求するようになる。さらに、Office 2011 14.3.2 にはその他の修正もいくつか含まれ、それらは主として Outlook に対するものだ。Gmail の IMAP 下書きメッセージで BCC 受信者が保存されないバグを解消し、x500 形式で作成された連絡先を宛先にしたメッセージが配信できない問題を修正し、短縮形がスペルミスとして指摘されないようにし、一部の Office 365 ユーザーで Offline Address Book が更新されない問題を修正している。今回のアップデートではまた、Track Changes を使用する際やサイズの大きな Word 書類をスクロールする際の安定性を改善するとともに、PowerPoint でスライドショーの切り替えの際にアーティファクトが表示される問題も修正している。(Office for Mac ウェブサイト から、または Microsoft AutoUpdate 経由で無料アップデート、113 MB/210 MB)
Microsoft Office 2011 14.3.2 および 2008 12.3.6 へのコメントリンク:
Default Folder X 4.5.8 -- St. Clair Software が Default Folder X 4.5.8 をリリースし、最近の二つのメンテナンスリリースで現われた問題点にいくつかさらなる修正を施した。（2013 年 3 月 10 日の記事“Default Folder X 4.5.7”参照。）Default Folder X は今回から、OS X 10.8 Mountain Lion で走る Java アプリケーションの中からもアクセスできるようになった。今回のアップデートではまた、Preview、TextEdit、Mail で Default Folder X のメニューを使った後にファイルダイアログでハングを起こしたバグを修正するとともに、存在しない項目がユーティリティメニューやコンテクストメニューにあった場合の問題に対処している。ユーザーインターフェイスに関するその他の修正点としては、ユーティリティメニューやコンテクストメニューの Quick Look コマンドをローカライズし、Default Folder X のツールバーボタンに VoiceOver ラベルを追加している。(新規購入 $34.95、TidBITS 会員には $10 値引、無料アップデート、11.4 MB、リリースノート)
Default Folder X 4.5.8 へのコメントリンク:
Dropbox 2.0 -- 機能性の面では画期的なバージョン更新というわけでもないが、Dropbox 2.0 では最近変更されたファイルの一覧を改善するとともに、共有フォルダ招待状を承認する新しい方法を導入するなど、メニューバーアイコンから利用できるインターフェイスを大幅に改善している。メニューバー上の Dropbox アイコンをクリックするとウィンドウが開き、Dropbox フォルダを開くボタンと Dropbox ウェブサイトを訪れるボタン、および最も最近に変更された三つのファイルのリストが表示される。変更されたファイルの一つの上にマウスを翳せば Share ボタンが現われる。ただし、この Share ボタンをクリックしてもアプリ内共有の機能が呼び出されるわけではない。その代わりに、Dropbox サイト上のそのファイルのページがウェブブラウザで開く。そのページの上でもう一度 Share ボタンをクリックすれば、ファイルのリンクを電子メールで送信したり、Facebook や Twitter で共有したり、あるいはリンクをクリップボードにコピーしたりできる。
デザインし直されたこのウィンドウには、他の Dropbox ユーザーから新たに共有されたファイルやフォルダの通知もあって、これは Recently Changed セクションの上の方に表示される。招待状の上にマウスを翳せば共有フォルダに参加できるし、その際現われる Accept ボタンをクリックすればそれがあなたの Dropbox フォルダに追加される。（Decline をクリックして止めることもできる。）けれども、共有ファイルを（ウィンドウの中でクリックして）承認しても、やはり Dropbox ウェブサイトを訪れることが必要で、ブラウザから直接ファイルをダウンロードするか、またはあなたの Dropbox フォルダに追加するかを選ぶことになる。
この最新リリースにおけるその他の変更点としては、Mac ラップトップで Discrete Graphics に切り替わっていたバグの修正や、ブラジルポルトガル語ローカライズ版の追加などがある。Mac OS X 10.6 Snow Leopard またはそれ以降で使える。(無料アップデート、26.1 MB、 リリースノート)
Read/post comments Dropbox 2.0 へのコメントリンク:
文： TidBITS Staff: [email protected]
訳： Mark Nagata <nagata@kurims.kyoto-u.ac.jp>
今週ウェブに登場したニュースとしては、Google の Android チームにいた Andy Rubin がチームを離れ、Adam Engst が MacVoices で Google Reader の消滅とツールがプラットフォームに変わり行く傾向について語り、Microsoft が Office for Mac 2011 において厳格かつ不親切なライセンス方式から引き返し、Dropbox が Mailbox を買収したことで私たちの頭の中の箱 (brainbox) もその意味するところに頭を悩ませる。
Android の責任者、春の大掃除で掃き出される -- Google が新たなプロジェクトリリースとして Google Reader を含むいくつかを「春の大掃除」で整理すると発表したその同じ日に、Google CEO の Larry Page は Android プロジェクト担当責任者 Andy Rubin が「プロジェクトを引き渡し、Google で新たな章を始める時が来たと決断した」と発表した。はたしてこれは偶然の一致だろうか？ 後任の Sundar Pichai は従来 Google で Chrome and Apps 担当責任者であったが、今後はそれに加えて Android プロジェクトも率いることになる。どんな理由で Rubin から Pichai への交代が起こったのかを知ることは不可能だが、Android は基本的に極めて大きな人気を得たにもかかわらず実際に Google の収益に寄与するところは大きくなかった（2008 年から 2011 年までの合計でたった 5 億 5 千万ドル程度と推定されている）ことがあるのかもしれない。Pichai が Android のエコシステムに何をもたらすか、またそれが iOS の世界にどう影響することになるのかは、今はまだ推測するしかない。
Adam Engst、MacVoices で Google Reader のニュースを歌い語る -- ホストの Chuck Joiner との対談で、Adam Engst は Google Reader が数ヵ月後に消滅するというニュースのより微妙な意味について掘り下げる。とりわけ、ツールがプラットフォームへと変貌しつつあること、変化がユーザーに及ぼす心理的効果、すべての変化がユーザーにとって良いわけではないという考えを支える価格モデル、といった話題について Adam は語る。
Microsoft、Office のライセンス変更を覆す -- MacTech によれば、最近 Microsoft は Office for Mac 2011 の従来のライセンス契約を Office 2013 for Windows のライセンス契約に沿ったものに変更した。つまり、ソフトウェアを一つのコンピュータから別のコンピュータへ移すことができないようにした。その後 Microsoft はこの Office 2013 使用許諾方針を元に戻して、再びソフトウェアをコンピュータの間で移すことができるようにした。（ただし移動は 90 日間に一回までに限られる。）Windows Office 発表の中で Microsoft は Mac 版について何も述べていないが、MacTech が調べたところによれば Mac 版についても使用許諾方針は元に戻っているという。要するに、すべてが期待通りの状態に戻ったというわけだが、Microsoft がこのような不親切なライセンス条項を考慮することさえ酷いことだと思うのに、いわんやそれを実装するとは何たることだろうか。
Dropbox が Mailbox を買収 -- 会社が会社を買収する際には、額面通りに受け取る限りにおいてはそれが将来の大きな方向を示唆するものなのか、具体的に優れた人やテクノロジーを手にするためなのか、それとも単に見当違いに思い付かれたものに過ぎないのか、どうにも理解できないことがある。iPhone アプリ Mailbox を作っている会社を Dropbox が買収するというのも、そのような買収に属するのではなかろうか。今のところは、それがどういうことなのかはっきりしない。風変わりな iOS 用電子メールクライアントを作ることは、どう見ても Dropbox の基本的使命とは懸け離れたものに見えるからだ。今後も Mailbox アプリは続くと述べられてはいるが、電子メールアプリ Sparrow と同じ運命を辿るかもしれないということは十分に考えられる。Sparrow は今も販売されているけれども、2012 年 7 月に開発者たちが Google に加わって以来もはや開発されていない。
TidBITS は、タイムリーなニュース、洞察溢れる解説、奥の深いレビューを Macintosh とインターネット共同体にお届けする無料の週刊ニュースレターです。ご友人には自由にご転送ください。できれば購読をお薦めください。
非営利、非商用の出版物、Web サイトは、フルクレジットを明記すれば記事を転載または記事へのリンクができます。それ以外の場合はお問い合わせ下さい。記事が正確であることの保証はありません。
告示：書名、製品名および会社名は、それぞれ該当する権利者の登録商標または権利です。
TidBITS ISSN 1090-7017©Copyright 2013 TidBITS: 再使用はCreative Commons ライセンスによります。
, 
日本語版最終更新：2013年 3月 28日 木曜日, S. HOSOKAWA