Ubuntu 18.04 LTSとNVIDIAドライバーの組み合わせでサスペンド・レジュームができるようにする

私のUbuntu 18.04 LTSシステムでは、NVIDIAのGeForce 1050 Tiを搭載したグラフィックボードを使用している。ところがこの影響なのか、サスペンドから回復(レジューム)しようとすると、システムは動いているのだが画面が回復しないという症状が発生してしまっていた。

備忘録代わりとなるが、今回いろいろと組み合わせてうまく行ったので、その方法について書いてみることにする。

まず使用しているドライバーだが、nouveauと呼ばれるオープンソースのものではなく、NVIDIA提供のプロプライアタリなものを使っている(バージョンは390系)。これを最新のものにすることで、この問題が解決するケースもあるようだ。私の場合は残念ながらうまくいかなかった。

そこで取った手は以下の通り。

(1) /etc/default/grubを書き換える。起動時に読み込まれるコマンドを記した行、GRUB_CMDLINE_LINUX_DEFAULTにいくつか書き加えて、このような感じにする。書き換えたあとは、sudo update-grubコマンドの実行を忘れずに。

GRUB_CMDLINE_LINUX_DEFAULT="quiet splash nouveau.modeset=0"

(ただし、nouveauドライバは使っていないので、ここは意味がないかも知れない)

(2) /etc/X11/xorg.confを作る。rootで何らかのエディタ(例えばgedit)を開いて、以下のような内容を足す。

Section "Device"
Identifier "Screen0"
Driver "nvidia"
VendorName "NVIDIA"
BoardName "GeForce GTX 1050 Ti"
Option "NvAGP" "1"
EndSection

ポイントはDriverの行と、最後のOptionの行である。BoardNameは自身のボードに合わせて適当なものを記入すればよい。

(3) 続いて、/etc/modprobe.d/blacklist.confを編集する。同様にrootでエディタを開いて、以下を追加する。

blacklist intel_agp

この状態で再起動する。これで、サスペンド・レジュームが有効になる(正確には復帰しても画面が真っ暗のまま、ということがなくなる)はずだが、念のため、コマンドラインから一度サスペンドをテストしてみるとよいだろう。

sudo pm-suspend

Grubで前に起動したシステムを記憶する

私は特にノートパソコンでUbuntuとWindowsのデュアルブートをよく使う。メインはUbuntuであっても、たまにWindowsが必要だったり、Windowsのアップデートをかける必要があるときがある。

一般的にUbuntuを導入すればデフォルトでUbuntuが起動するようになっているはずである。しかし、たまにはそうでないようにしたいときがある。
例えばWindows Update、とりわけWindows 10なら半年に1回ある大きなアップデート(アップグレード)のときにWindowsは何回も再起動するのだが、そのたびにGrubを見張ってGrubのWindows起動メニューを選ぶというのは面倒である。
かといって、Grubの設定を変更して常にWindowsを優先起動するほどではない…そんな悩みをお持ちの方も多いだろう。

そのような場合、Grubに「前に起動したシステム」を覚えさせる、という手がある。
例えば、前にWindowsを起動していれば、次回の起動時には自動的にWindowsが起動するようになる。もちろん、Ubuntuに変えたければ、起動時にUbuntuのメニューを選べばいい。

このようにするためには、Grubの設定ファイルを少しだけ修正する必要がある。
/etc/default/grubを管理者モードで編集する。コマンドラインで”sudo gedit /etc/default/grub”と入れるのがいいだろう。

そして、以下の2行を追加する、というか、GRUB_DEFAULTの部分はすでにあるはず(たいていは0となっている)なので、それを編集する。

GRUB_DEFAULT=saved
GRUB_SAVEDEFAULT=true

(ウェブに出ている情報で、GRUB_DEFAULTだけ変更するように書かれているものもあるが、2行目も必要である。)

編集が終了したら、以下のコマンドを実行し、変更内容を反映させる。

sudo update-grub

GRUB_DEFAULTは、Grubの初期画面の何番目(何行目)をデフォルトで選択するかを示すもので、大抵はこれが0となっている。これは一番最初のエントリーをデフォルトで起動するというものであり、これを1、2などとすれば、デフォルトのエントリーを変えることも可能である。
ここを「saved」とすれば、前回に選択した起動システムを記憶してくれるので、Windowsを何回も再起動で選択しなければならない、といったときもただ放っておけばよい。
なお、Ubuntuに戻る際には、改めてGrub画面でちゃんとUbuntuを選ぶ必要がある。

LinuxとWindowsのデュアルブートで、両者をそこそこ使うような場合には便利なオプションだろう。

UbuntuでGoogleアカウントを使い分ける

職場と自宅、あるいは個人用でも複数といったように、今や複数のGoogleアカウントを持っている人は多いはずである。こういったとき困るのが、特にブラウザにおけるアカウントの扱いである。
以前使ったアカウントがそのまま残っていて、いちいちログアウト・ログインを繰り返さないと別アカウントを使うことができないというケースはけっこうある。
Ubuntu、あるいはそれに限らず、そのような場合の対応策について考えてみた。なお、ここでは基本的にFirefoxを使用した場合とする。Google Chromeであればもう少しスマートな解決方法はあるかも知れない。

まず、最も基本的(?)な方法は、ブラウザの使い分けである。アカウントAはFirefox、アカウントBはGoogle Chromeのように、複数アカウントをブラウザごとで使い分けるという手である。ただ、これではブラウザが固定されてしまって、ここのブラウザがもつ機能をそれぞれのアカウントで使うことができない。また、利用するアカウントが多い場合にはブラウザの数に追いつかないということも考えられる。

そこで、 Firefoxだけで使い分けることを考えよう。
Gmailだけであれば、FirefoxのアドオンであるX-Notifierが便利である。
X-Notifierは、複数のGmailアカウント(すなわち、Googleアカウント)を管理して、メールの着信を通知、自動的に複数のGmailタブを開いてくれる便利なアドオンである。
Googleアカウントの使用がGmailだけであれば、これで十分である。

ところが、Googleアカウントをほかにも(例えば、YouTubeやAdSense, Mapなど)細かく使い分けていて、ブラウザごとに変えたいという場合には、これではちょっと不十分である。
そこで、このような場合、ブラウザのウィンドウごとにGoogleアカウントを切り替える、Multifoxというアドオンを利用することにする。
Multifoxは、Firefoxの上部にボタンを持ち、アカウントを切り替えたいときにはそこから「プロファイル」(これはFirefoxでいう「プロファイル」とはまた異なるようである)を切り替えて対応する。別ウィンドウが別のGoogleアカウントになるので、Gmailはもちろん、YouTubeやAdSenseなどもウィンドウごとに別々のGoogleアカウントとして問題なく機能する。

ところが困ったことに、このMultifoxとX-Notifierは同時に使用できない(複数のGoogleアカウントには対応しない)。どちらかを選ばないといけないのだ。
そうすると、X-Notifierで便利だった通知機能はMultifoxにはないので、これが使えないのは痛い。

そこで登場するのが、Ubuntuの機能である「Unity Mail」である。
Unityという名前からもわかるように、これはUbuntuのユーザインタフェース機能、Unityの中に実装されている。Ubuntuソフトウェアセンターで「Unity Mail」で検索すると、候補の中にUnity Mailがあるので、それをインストールすればよい。

Unity Mailは、複数のGoogleアカウントのメール通知に対応している。メールの到達状況は、Unityのランチャーの中に、このような形で表示される。

Unity Mail

さらに、画面上部のアイコンも、メールが到達すると青色に変化して知らせてくれる。これで、メール通知も(一応)ばっちりということになる。
もちろん、画面右上にポップアップが出る、デスクトップ通知にも対応しているので、メールの到達はむしろX-Notifierよりわかりやすいかも知れない。

ただ残念ながら、Unity Mailは、どのアカウントからのメールが到着したのかまでは知らせてくれないので、どのアカウントに到着したのかがわからない場合には、それぞれのウィンドウを開けてメールをチェックしなければならない。その点が若干不便ではある。

Windowsでも同様の環境を構築する場合には、Gmail Notifierをデスクトップ常駐アプリとして使用し、同じようにMultifoxを使用すればよいだろう。
また、Unity Mailの設定画面をみるとお分かりかと思うが、メールの着信はIMAPでみている。もしご自身のメール環境がIMAPに対応している場合、IMAPサーバーとポート番号が分かれば、設定することによってUnity Mailでの新着通信に対応することは可能である。例えばYahoo!メールも可能である(と思われる。私自身試していないので…)。

私自身、GoogleアカウントはGmail以外にもかなり広範に使い分けしているので、試行錯誤の上こういうやり方にたどり着いている。また新しいやり方ができ次第、随時報告する。

6年もののネットブックを余ったSDカードで高速化してみる・続報 スリープ・ハイバネート不具合への対処

(ご注意) 現時点でも対処は継続中です。良好な結果が出次第、本エントリは随時更新されます。

以前のブログの記事にて、ネットブックに余ったSDカードを挿入し、それをスワップ領域として活用することで高速化を図るやり方を紹介した。ところが、この方法を採用すると、スリープやハイバネートが効かなくなるという問題点がある。
今回はそのための対処の方法である。(参考サイト: http://afrivirt.wordpress.com/2010/06/04/4/)

まず、内蔵ハードディスクのスワップ領域が残っていることを確認する。
スワップが内蔵ハードディスクの場合にスリープやハイバネートが正常であり、SDカードをスワップ領域にするとうまくいかないという場合には、スリープやハイバネートのときに、このSDカードのスワップ領域を使用停止にするとよい。もちろん、回復するときには改めて有効にすることも必要である。

そのために行うのは、/etc/pm/sleep.dというディレクトリの下に、ちょっと特別なファイルを作成することである。

端末から、

sudo gedit /etc/pm/sleep.d/11_sdcardswap

(ファイル名は任意だが、先頭の11_はあまり変えない方がいいだろう)と打ち込み、ファイルを作成する。このファイルは以下のような内容とする。

#!/bin/bash

case $1 in

hibernate)

echo “Turning off sdcard swap …”

swapoff /dev/mmcblk0p1

;;

suspend)

echo “Turning off sdcard swap …”

swapoff /dev/mmcblk0p1

thaw)

echo “Turning on sdcard swap …”

swapon -p 10 /dev/mmcblk0p1

;;

resume)

echo “Turning on sdcard swap …”

swapon -p 10 /dev/mmcblk0p1

;;

*)

echo “Wrong operation”

;;

esac

さらに、このファイルは実行可能にしておかなければならない。端末から以下のコマンドを打ち込む。

sudo chmod +x /etc/pm/sleep.d/11_sdcardswap

先ほど作成したファイルは、スリープ時やハイバネート時にSDカードへのスワップをOFFにし、逆にレジューム時やハイバネートからの回復時にはSDカードへのスワップを再びONにするものである。
ただ、このままでは、スリープやハイバネートのときにスワップがなくなってしまう(そうなると特にハイバネートのときにはたいへん困ったことになる)。そこで、改めてハードディスクのスワップ領域を有効にしておく。これは、/etc/fstabで記述する。
このときに、なるべくSDカード側のスワップ領域が使われるよう、スワップの優先度を変更しておくとよい。

/dev/mmcblk0p1    swap    swap   sw,pri=10  0   0

/dev/sda3               swap    swap   sw,pri=0   0   0

上記は、/etc/fstabにおけるスワップの部分だけの抜粋である。
オプション領域で「sw,pri=…」と記述されているのが、スワップ領域の優先度である。この場合にはSDカード領域(/dev/mmcblk0p1)の方をハードディスク(/dev/sda3)より高く設定している。

以上の作業が終わった時点で再起動し、設定を有効にすれば大丈夫なはずである。

…はずなのだが、現時点では、スリープはまぁまぁ動作する(しない場合もあるが、コマンドラインでsudo pm-suspendとするか、メニューから選ぶとほぼ間違いない)ものの、ハイバネートはほとんどダメである。
ひょっとして、Ubuntu 14.04だとうまくいく、ということもあるのかも知れないが、さすがにもう6年にもなるネットブックをいまさらアップデートするのも何なので、とりあえずUbuntu 12.04のままで対処方法を探ってみているところである。

au WALLETの嘘: クレジットチャージに気をつけろ

auが5月から始めた新しいポイントシステム、au WALLET。この仕組みは、ポイントと電子マネー、クレジットカードのいいとこ取りのような仕組みがあるという点で、auにとって販売促進のための強力なツールになっているようである。

au WALLET | au - Mozilla Firefox_005実はこのau WALLETは、マスターカードが運営するウェブマネーの仕組みを使っている。これは、マスターカードのクレジットカードにひも付けされた電子マネーで(ひも付けしなくても、単体でもマスターカードとして運用ができる)、それにポイントなどau向けのカスタマイズを施した形になっているようである。

いちいちチャージするのに、auショップを探し回ったり現金を引き出してくるような手間をかけたくない私としては、チャージ方法として、

  • auかんたん決済
  • クレジットカードチャージ
  • じぶん銀行口座からのチャージ

のどれかを選ぶことになる。ところが、auかんたん決済の場合には引き落とし方が口座振替か特定のクレジットカードということになり、条件から外れる。
また、じぶん銀行には口座を持っていない。
新たに口座やクレジットカードを持つのがいやな私としては、現行のカードでの運用をいろいろ考えた。現在、VISAとJCBのカードを使用しているので、作戦として、ハウスカードとなっているクレジットカードをマスターカードに「昇格」させて、ここからチャージさせる作戦をとろうと考えたのである。

ハウスカードは日産カードである。

トップページ - 日産カード - Mozilla Firefox_006ここでハウスカードをVISA・マスターなどに切り替えると、UCカードとしても使えるようになる。
au WALLETの利用条件としては、サイトにはチャージは「すべてのMasterCard」で可能と書かれているので、当然のことながら、ここからのチャージが可能になるというわけである。もちろん、すでに持っている2つのカードがアウトになったときのサブカードとしても使える。 カードへのチャージ(入金)方法 | ご利用ガイド | au WALLET - Mozilla Firefox_007範囲を選択_008さて、その作戦のもとにハウスカードからマスターカードへの切り替えを実行、2週間ほどしてようやくカードが到着した。
早速カード番号を登録しチャージを行う。そうすると、「本人認証サービスへの登録が必要です」と表示される。
この本人認証サービスというのは、ネット決済などにおいて、カード番号やCVコード(カードの裏、署名欄にある3桁の数字)、有効期限、暗証番号での決済ではなく、あらかじめ本人として登録した認証コード(要はパスワードである)を入力することで、本人であることを再確認するものである。このシステムがあると、例えば拾ったカードをネットで使おうとしても、この認証コード(パスワード)が知られていない限り決済はできない。非常にセキュリティの高いサービスである。たいていのクレジットカード会社は、このサービスを提供している。

今回の場合、日産カード(マスター)はUCカードでもあるので、UCカードが提供する本人認証サービスであるアットユーネットを利用してまずカード番号を登録し、パスワードを設定することで認証設定が完了する。

アットユーネットとは?|クレジットカードはUCカード - Mozilla Firefox_009ところが、何回行っても認証は成功せず、そのたびに「UCカードお客様センターへ電話してください」と表示される。しかもまたこれがフリーダイヤルではないというおまけ付きだ。

仕方がない。翌日営業時間にそのお客様センターへ電話をかけてみると、どうやらカードが本人認証サービスに対応していないということで、詳細については日産カードに問い合わせろということだった。
そこで今度は、日産カードのサポートデスクに電話(こちらにはフリーダイヤルが存在した)。状況を聞いてみると、本人認証サービスを提供していないということであった。

つまり、

マスターカードであるにも関わらず、(本人認証サービスを提供していないカード会社が発行したカードは)au WALLETにチャージすることができない

という大きな落とし穴が存在していたのである。
もちろん、上の画像にある、「すべてのMasterCard」というのは嘘、虚偽表示ということになる。

早速auのサポートセンターにこの点を問いただしたところ、事実を認めた上で早急なページの修正と、クレジットカードチャージの改善を行う旨、回答をもらっている。
私のような犠牲者が出ないためにも、大至急のレベルでの修正・告知を行って欲しい。
さて、auではクレジットカードチャージの改善を行うと言ってはいるが、この本人認証サービス、よくみると元のウェブマネー側がそれを要求しているので、au単体で対応することかなり難しいだろう。

電子マネーWebMoney(ウェブマネー) - クレジットカードを利用した購入方法 - Mozilla Firefox_010 範囲を選択_011だいたい、まさかau WALLETのチャージのためにウェブマネーのページまでわざわざ調べに来るという人はいないだろう。私も今回の問題が起きたので改めて調べてみたわけである。

となると最大の問題は、日産カードが本人認証サービスに対応していないということになる。この点、対応を尋ねてみると「お客様からのご要望が多い場合には…」というなんとも頼りない答だった。

日産カードはハウスカードなら年会費無料だが、VISA・マスターに切り替えると1250円の年会費がかかる。不適切、不十分な情報提供のため、1250円の年会費と、カード切り替えに費やした余計な時間を浪費してしまったことになる。まったくもって腹立たしい限りである。
※ただし、日産カードの場合、年会費は初年度は無料ということである。解約の場合、契約月から1年以内であれば年会費はかからないとのこと。

さて、どうするか。
カードの枚数をむやみに増やさないというポリシーを貫くのであれば、使えない日産カードを即時解約して、その代わりに別のマスターカードを契約するのが最良のパターンとなる。もっとも、一応は「いちるの望み」を託す形で、日産カード(日産フィナンシャルサービス)が本人認証サービスを行うのを待つか、au側が本人認証コード以外の形でのチャージを行えるようにするのを待つか、どちらを待ってみることにしたいと思っている。
ただそうなると、いちいちauショップへ行って現金(そう、auショップでのチャージもクレジットカード対応ではないのだ)を持ち出す必要がある。auショップに行く前に銀行でお金をおろして電子マネーを使うという極めて前時代的な対応が必要になるのである。だからといってauが誘導しようとしているUCやじぶん銀行に屈したくはない。
しばらくはau WALLETに多めにチャージしておくようにする自衛策が必要なようだ。

それにしてもこれだけネット決済でクレジットカードを使う時代において、未だに本人認証サービスに対応していないという日産カード、会社としてセキュリティをどう考えているのだろうか。日産グループ全体に疑念を持たざるを得なくなってくる。
これでは個人的に日産車も解約したくなってきてしまう。

※ブラウザのスナップショットはいずれも2014年7月4日午後7時前後のもの。
※この状況でもう1つ考えられる作戦としては、au携帯電話の引き落とし口座を日産カード(マスターカード)の口座にするという手がある。幸い、UCカードでもあるので、auかんたん決済での対象カードにもなっている。ただ、今回の一件があると、UCカードであるといえど日産カードへの不信感は大きい。うまくいくかどうか試してみないとわからないというのは個人的には怖いし、もうこれ以上手間をかけたくないというのが正直なところだ。また、チャージ額に限度があるというのもいただけない。

Ubuntu起動画面(splash画面)が崩れてしまうときは

Ubuntuが起動するときには、「Ubuntu」の文字とロゴがしばらくの間表示され、その後ログイン画面、あるいは直接ログインする場合にはデスクトップ画面へ移行する。このシンプルだが美しい画面のことを「スプラッシュ画面」(splash画面)という。

昔のLinuxディストリビューションでは、起動時にはいろいろなサービスが起動する様子が延々と表示されていたので、それに比べるとシンプルで一般向けといえるだろう。さらに、このスプラッシュ画面は、いろいろなアプリのテーマのように着せ替えることもできるので、自分が気に入ったものを利用することも可能だ。

ところが、困ったことにこのsplash画面が非常にみにくいものに変わってしまうことがある。特に、起動時に画像ではなく、文字で「Ubuntu」と表示されるようなケースがある。
これは、ビデオドライバをプロプライエタリなものに変えた場合によく発生する。典型的なのがNvidiaのドライバで、これを利用するとたいてい、文字表示に変わってしまう。
もちろん、文字表示でもUbuntuの利用に実害は発生しないが、せっかく美しいデザインを誇るUbuntuのこと、できればもとの美しいスプラッシュ画面が出てくれるようにしたい。
このようなときに、以下のような方法にすると修復が可能なようである。

以下、Ubuntu 14.04でテストしている。なお、以下編集するファイルはいずれもシステム設定ファイルなので、慎重に編集すること。また、管理者権限でないと書き込みできないので注意する。端末を開き、

sudo gedit /etc/default/grub

のようにするとよいだろう。

<その1>

  1. 最初のUbuntu起動画面(grubの画面。背景が紫色)のところで、「C」を押して起動を止める。
  2. プロンプトが出るので、ここで「vbeinfo」と入力する。
  3. 数多くの解像度の組み合わせが出てくる。例えば「640x480x32」とあれば、640×480ピクセル、32ビット解像度での表示をサポートしているということである。この中から1つを選んで記録しておく。自分のディスプレイの解像度になるべく近いもの、そしてなるべく高い解像度のものを選んでおく。
  4. 「exit」と入力してgrubの起動画面に戻るか、Ctrl+Alt+Delを押して再起動する。
  5. このままコンピュータをブートし終わったら、作業開始である。まず、grubの設定を変更する。/etc/default/grubで、以下のようにある行

    #GRUB_GFXMODE=640×480

    の次の行に、以下のように書き足す。

    GRUB_GFXPAYLOAD_LINUX=1920×1080-32

    ここで、=のあとの部分は解像度と色のビット数である。先ほど起動時に調べた解像度と色のビット数を上の数字に当てはめて書いておく。この数字を間違えるとスプラッシュ画面がうまく起動しないので、もしうまくいかない場合はgrubでの解像度と色の数値をいろいろと試し、ここの部分を書き換えてみよう。なお、解像度と色の数値はできるだけ高いもののほうがよいようだ。

  6. 次に、/etc/initramfs-tools/conf.d/splashというファイルを編集する。ここにはただ1行、

    FRAMEBUFFER=y

    とだけ書く。

  7. 以下のコマンドを実行して、initramfsへの変更を有効にする。

    sudo update-initramfs -u -k all

  8. 以下のコマンドを実行して、grubへの変更を有効にする。

    sudo update-grub

  9. 再起動し、スプラッシュ画面が出てくるかどうかを確認する。

<その2>

「その1」の方法でスプラッシュ画面が出ない時には、先ほどのファイルに書いた解像度と色の数値が間違っていないことを確認した上で、さらに次のような変更を加えてみる。

  1. 先ほどと同様、/etc/default/grubを再度編集する。今度は、

    GRUB_CMDLINE_LINUX_DEFAULT=”quiet splash”

    と出ている行の先頭に「#」を加えてこの設定を無効化し、その下に以下のように書く。以下は1行である点に注意。

    GRUB_CMDLINE_LINUX_DEFAULT=”quiet splash nomodeset video=uvesafb:mode_option=1920×1080-32,mtrr=3,scroll=ywrap”

  2. 同じく/etc/default/grubにおいて、

    GRUB_GFXMODE=1920×1080-32

    とある行があり、その先頭に「#」が入っていたら、それをとって、この行の設定を有効にする。なお、数値は先ほど述べた通り、grubでサポートされている解像度と色の数値のうち、いちばん高いものを選んでおく。

  3. 続いて、/etc/initramfs-tools/modulesファイルを編集する。このファイルの最後に、以下の1行を加える。

    uvesafb mode_option=1920×1080-32 mtrr=3 scroll=ywrap

  4. 「その1」の6.で行った、/etc/initramfs-tools/conf.d/splashファイルの作成を行っていない場合は、それを行う。
  5. 以下のコマンドを実行して、initramfsへの変更を有効にする。

    sudo update-initramfs -u

  6. 以下のコマンドを実行して、grubへの変更を有効にする。

    sudo update-grub

  7. 再起動し、スプラッシュ画面が出てくるかどうかを確認する。

<その3>
上記2つでもうまくいかない場合には、そもそもスプラッシュ画面が出せる状態になっているのかどうかを確かめよう。スプラッシュ画面を表示しているソフトはPlymouthというものである。これを実行してみる。

sudo plymouthd ; sudo plymouth –show-splash

これで画面が出るはずである。画面が出たことを確認できたら、Unityで端末を選んでおいて、

sudo plymouth quit

でPlymouthを終了する。

これで画面が出ない場合、plymouthの一部パッケージを追加する必要がある。追加して出るかどうかを確認しよう。

sudo apt-get install plymouth-x11

これで上記のPlymouth画面表示を試し、それでもダメであれば、さらに/etc/default/grubを以下のように編集する。
まず、

#GRUB_GFXMODE=640×480

という行があれば、その行の下に

GRUB_GFXPAYLOAD_LINUX=auto

という1行を加える。grubへの変更を有効にするため、update−grubを実行する。

sudo update-grub

再起動し、スプラッシュ画面が出るかどうか試して欲しい。

私の場合は、「その1」「その3」の組み合わせ、あるいは全てのケースを投入した結果うまく行っている。おそらくは「その1」「その2」だけで、解像度を正しく記述すればうまくいくかも知れないが、それぞれに違いがある可能性もあるので、上で記述した方法をいろいろ試してみて欲しい。

<参考>

6年もののネットブックを余ったSDカードで高速化してみる

いまから5〜6年前だろうか。「ネットブック」、あるいは「ミニノート」と呼ばれるコンピュータがはやったことがあったのを覚えていらっしゃるだろうか。
比較的能力の低いCPU、狭い液晶画面、小さなHDD、少ないメモリ領域という形で、性能をぐんと抑えつつ価格を5〜6万とものすごく安くしたコンピュータである。
ただ、その後間もなく登場したタブレット機器に押されて、一気に下火になり、今は店頭で見かけることもまずなくなってしまった。

さて、私の手元には、2008年9月に投入したこのネットブックがある。Acer Aspire ONE、AOA-150Bbである。
性能はといえば、

  • CPU…Intel Atom N270 (1.6GHz, デュアルコア)
  • メモリ…1GB (増設不可)
  • ハードディスク…160GB
  • プリインストールOS…Windows XP Home Edition

というものである。ちなみに、私が欲しいなぁと思っているタブレット、Xperia Z2タブレットでは、

  • CPU…Snapdragon 801 (最大2.3GHz, クアッドコア)
  • メモリ…3GB
  • 記憶容量…32GB
  • プリインストールOS…Android 4.4

と、ストレージさえ除けば処理性能は圧倒的に上回っている。もうそんなボロいネットブックなんて処分してしまえばいいとは思うのだが、そこは「もったいない」精神が働くというわけで、できる限り現役のまま使ってあげたいというのが私の気持ちである。

現在このネットブックは、Ubuntu 12.04 LTS(当然32ビット版)が動作している。以前はWindows XPとのデュアルブートであったが、XPのサポート終了に伴ってWindows領域を削除、さらにディスクパーティション構成を組み替えて、完全にUbuntu専用機になっている。
なお、さすがに処理性能を考えて、Unityは2Dとしてある。他の軽量デスクトップも考慮に入れてはあるのだが、持ち歩いて頻繁に使うこと、電源性能(サスペンド、ハイバネートのしやすさ)の問題で、重いがUnityを使用している。

で、これがどれだけ遅いのかということだが、簡単なベンチマークということで、Google ChromeとFirefoxを、起動後Unity操作可能時点で同時にクリックし、両方が起動する時間を測定してみることにした。Google ChromeもFirefoxも、数個のタブがすでに開いており、それを読み込みながら起動する設定となっている。

  • Google Chromeの画面(どこか1つ)が出てくる時間…4分10秒
  • Firefoxの画面(どこか1つのタブ)が出てくる時間…7分30秒

普通のコンピュータでブラウザ1つを立ち上げるのに7分かかっていたら処分した方がよいに決まっている。

このようにとんでもなく遅い原因はメモリ不足である。最近のブラウザであれば、数個タブを開いていれば1GBなんてあっという間に食ってしまう。つまり、ブラウザを立ち上げていると(もちろん、起動直後なので、他のプロセスも次々に起動しているが)メモリを食い、1GBを使い尽くすと、今度は仮想メモリ(スワップ)領域へのデータ移動が始まり、両方でディスクアクセスを取り合ってずっとディスクにアクセスしたままになる、という構図である。
(なお、この実験のときには、スワップのしやすさを表す数値 swappinessは通常の60から10へと変更して、よりスワップがかかりやすくしている。)

この遅いマシンを何とか改善したい。そこで目をつけたのは、使われずに自宅で放置されていた2GBのSDカードである。
Aspire ONEには2つのカードスロットがある。1つは右側にあるSDカード専用スロット、1つは左側にある、SDカードなどいろいろなカードを読み込めるマルチカードリーダースロットである。
作戦としては、このどちらかにSDカードを挿入、スワップ領域をこちらに移設して、高速なアクセスを実現させようというものである。
なお、大量のアクセス(読み書き)が発生するため、SDカードの寿命は著しく短くなってしまうが、もともと使われていなかったSDカードなので、そう惜しいという気持ちはない(もし皆さんが実践されるときには、その点よく注意して欲しい)。

作戦はこうである。

  • Aspire ONEのSDカードスロットにSDカードを挿入
  • 起動時にマウントさせるように認識、かつそれがスワップ領域であるようにする
  • スワップ領域をこのSDカードに割り当て
  • swappinessを調整してわざとスワップされやすいようにする

今回は、左側のマルチカードリーダースロットをスワップ用SDカードに割り当てた。これは、Ubuntu上では/dev/mmcblk0p1として参照することができる。
普通に挿入するとリムーバブルメディアとして認識されてしまうので、まずマウントを解除、次にディスク領域をスワップ領域として確保する。これは、Ubuntu付属の「ディスク」ツール、GParted、コマンドラインからであればfdiskなどいずれかで可能である。これらでSDカード領域をまるごとスワップ領域にする。

最後に、起動時に必ずマウントされるようにするため、/etc/fstabをちょっとだけ改良する。もしもともとスワップ領域を設けているのであれば、そのエントリーを参考に次の行を付け加える。なお、もともとあるスワップ領域の行は消さないで、先頭に「#」を入れておき、コメントで無効にする。

/dev/mmcblk0p1 none swap sw 0 0

これでOKだ。再起動するか、

sudo swapoff /dev/sda4 (デバイス名は機器によって変更すること)
sudo swapon /dev/mmcblk0p1

を実行すれば、新しいSDカード上のスワップ領域が有効になる。cat /proc/swapsにより、スワップ領域の使用状況を確認することが可能だ。一応、確認しておこう。

次は、スワップしやすくしてしまう(積極的にメモリからSDカードに「吐き出す」)設定である。これは、swappinessという数値をいじる。この値は、スワップのしやすさを表す数値で、0に近づくほどスワップしにくくなる。通常は60であり、最近の大容量メモリを搭載した機種では10や0という値をとることも珍しくないが、今回は逆に、80や90という値にしよう。これを設定するのは、/etc/sysctl.confというファイルである。ここに1行、こういうふうに記述する。

swappiness = 90

再起動してこの設定を有効にすれば、準備完了である。
それでは、どのくらい速くなったかを調べてみよう。先ほどと全く同じ設定で、起動直後にGoogle ChromeとFirefoxを起動して、両者のタブ(のうち1つ)が操作可能になる時間を測定する。まず、swappinessが60(デフォルト値)の場合。

  • Google Chrome…3分33秒
  • Firefox…2分ちょっと(10秒程度。このとき計測がうまくいかなかった)

まぁもちろんまだ遅いといえば遅いが、先ほどのケースからすれば劇的に改善された。さらに、swappinessを90とし、preloadを有効にした上で(いままではメモリが少ないので有効にしなかった)改めて測定する。

  • Google Chrome…2分40秒
  • Firefox…2分10秒

となる。Google Chromeで性能が向上しているのは、タブあたりのメモリ割り当てが多いGoogle Chromeで効果が顕著に出ていることを示していると思われる。
もちろん、Firefoxが起動して2分もかかって表示されるのはそれでもイライラするかとは思うが、起動したあとしばらく待ってマシンが落ち着いてから起動するようにするなど、運用を工夫すれば若干気分的にも改善できると思う。
なお、この時点でスワップ領域の消費量は300MBほどで、2GBのSDカードの10数パーセントである。

いろいろ書いたが、この方式は、いってみればWindowsのReadyBoostと同じような考え方で、HDDよりは高速な半導体デバイスに記憶領域を間接的に移動させるというアイディアである。
同じ考え方はデスクトップ機にも応用可能である。例えば、使用していない2GBや4GBのUSBメモリなどが余っているのであれば、それらをスワップとして割り当ててやれば、メモリが少ないマシンでも高速化の効果が出る可能性はある。

ただ、この設定で運用を行って以来、サスペンドやハイバネートが効かなくなってしまった。
サスペンドについては原因が不明である。
ハイバネートは、このSDカードの領域が足りないためと推測される(Write errorが出るのだが、SDカードそのものの検査を行ってもディスクエラーは確認されない)。そこで、ハイバネートをかけたい場合、いったん無効にしたHDD上のスワップ領域を有効にする。

sudo swapoff /dev/mmcblk0p1 && swapon /dev/sda4

これでハイバネートは元に戻るが、運用上面倒ではある。このあたり、いいアイディアがあれば追求してみたいが、もう6年ものとなっているネットブックがいつまで持つかという点も問題ではある。

【2014年8月28日追記】その後のスリープ・ハイバネート対応を別記事にまとめてみました。参考になさってください。

Xperia ZL2で日産カーウィングスを利用する

私は日産カーウィングス(2007年式の日産デュアリス、メーカーオプションのナビ使用)を利用していて、しかも結構ヘビーユーザーである。オペレーターサービスはもちろんのこと、情報チャンネルもフル活用、渋滞情報のダウンロードも行って、常に最速ルートが選択されるようにしている。

さて、日産カーウィングスを含め、こういった通信機能付きのナビは、たいていはBluetoothで接続している。
ややこしくなるので詳細は省くが、Bluetoothにはいくつかの「プロファイル」と呼ばれるものがある。いわば機能である。例えば、HSP(ヘッドセットプロファイル)は、Bluetooth経由でヘッドセット(まぁ、ヘッドフォンではあるが、場合によってはスピーカーなどということもあるだろう)を実現する。

こういった通信機能付きのナビは、大抵の場合BluetoothのDUN(Dial-Up Network Protocol.ダイヤルアップネットワークプロトコル)という、一昔前の通信をシミュレートするような通信プロトコルを使用する。ところが、 たいていの携帯、とりわけスマートフォンでは、Bluetoothには対応していても、DUNプロトコルを実装していないのである。
従って、日産カーウィングスの「携帯対応確認ページ」へ行くと、スマートフォンには一部機種を除き対応していない旨書かれている。これが、私がずっとガラケーを利用してきた理由である(もちろん、ガラケーでも対応していない機種はある。なので、事前にこの表をチェックして対応機種を購入するわけである)。

しかし、いつまでもガラケーに縛られるのもいやである。私自身とうとう我慢しきれずスマートフォンに乗り換えてしまった。機種は、auのXperia ZL2 (SOL25)である。
もちろん、日産カーウィングスのページには対応表は載っていないし(まだ出たばかりだし),おそらくDUNプロファイルは実装されていないので対応しないだろう。しかしそう黙ってカーウィングスを諦めるのはいやである。そこで考えたのは、DUNを実現するソフトウェアをスマートフォン側にインストールするという手である。

幸い、こういう、DUNを実現するアプリがいくつかある。代表的なものでは、

と、複数出ている。

今回はこの3つを試してみた。その結果、まずbt Dunはアプリを起動すると異常終了して使えない。残り2つ、BlueDunとCobaltBlue 3に絞られることになった。

両者ともお試しモードだと意外にあまり安定して通信できない。一応通信はできるようなのだが、2回続けるとつながらなかったりする。そこで、意を決してどちらか購入して試すことにした。今回はCobaltBlue 3をチョイス。こちらの方が価格が高いのだが、通信の安定性がお試し版の時点で若干上だったのと、日本人による開発のため日本語でのサポートが(万一の場合)受けられそうだ、というのが理由である。

では、インストールを始めよう。
最初に、CobaltBlue 3をインストールしておく。支払いも済ませておこう。
正式版になると、Bluetoothと連動してアプリが起動できるようになるので、アプリ内の設定からその機能をONにしておく。

まずは、カーウィングスナビ側での設定である。
スマートフォンの接続に際しては、最初に携帯電話を登録する必要がある。通常は会社を普通に選べばいいのだが、Xperial ZL2のような「au (LTE)」などという選択肢は当然2007年型デュアリスのナビには存在しない。そこで、携帯電話は手動登録する。
(追記: 多分、どの携帯電話会社、あるいは通信方法を選んでも大丈夫なような気はする。)
携帯電話は手動登録を選び、番号だけ自分の番号をセットしておく、あとの設定はいじらない。ここで、カーナビ側に表示が出て、「この状態のまま、携帯電話を操作します…」という表示が出る。まだここではスマートフォン側のBluetoothは起動しないようにする。

次にスマートフォンをBluetooth接続させる段である。この時点でCobaltBlue 3がインストールされている必要がある。
ここで、スマートフォン側でBluetoothを起動する。この時点でスマートフォン側には、MY-CARという機器と接続する(ペアリング)ためのパスワード(数字である。もし設定を変えていなければ1234)を入力する画面が出るので、間違わずに1234を入力する。このMY-CARがカーナビである。
うまく接続できれば、カーナビ側にも「携帯電話が登録されました」という表示が出る。これでOKだ。

よく間違えやすいのが、CobaltBlue 3をインストールしていない状態で接続し、アンテナが立っているので接続できると思ってしまう状態である。このアンテナは単にハンズフリーフォンでの通話が可能かどうかを示すだけであって、肝心の通信機能を意味するものではない。したがって、上記の手順を踏む必要がある。

今のところ、以下の機能については問題なく作動することを確認した。

  • 一般的な通信機能(情報チャンネル)
  • オペレーター通信(オペレーターに目的地を伝え、その情報をダウンロードし、目的地を設定)
  • 渋滞情報(定期的に取得)
  • CDタイトルの検索・ダウンロード

したがって、一般的なカーウィングスの機能はほぼ使えるといってよいだろう。

もう1つの大きな障壁は、電話帳の転送である。これはGoogleの連絡帳が転送されるのか、内蔵(ローカル)の電話帳が転送されるのかよくわからないので、まだそのままにしてあるが、いずれ試してみたいと思っている。

カーナビも、DUNを必要としない方向に向かっているようである。日産のカーウィングスは、最新のものであれば通信モジュールを内蔵しており、携帯電話やスマートフォンはあくまでハンズフリーシステムとしてだけ動作するようになっている(例えば、V37スカイラインの内蔵カーナビ)。
いずれ、このシステムに置き換えられていくとは思うが、それにはまだ多少時間がかかりそうである。それまでのつなぎとしても、あるいはスマートフォンライフとカーウィングスを両立させたい方にも、ぜひ試してみてもらいたい。

Ubuntu 14.04 “Trusty”がいい感じ

この4月にリリースされる予定のUbuntu 14.04 “Trusty Tahr”、私も次期プラットホームになる予定なので、アルファ段階からのテストに入っているが、予想外に安定していることにちょっとびっくりである。

Trusty-snapshotTrustyはその名の通り、「信頼できる」という雰囲気を大きく感じさせるリリースである。
基本的に13.10などからの大きな変化はない。もちろん、ユーザインタフェースなどの細かい点ではいくつかの違い(改善)がみられるが、基本的には、Unity,上部アプリケーションバーといった画面構成などに変更はまったくなく、むしろそれをうんとブラッシュアップした感じとなっている。

アルファ版からの使用感にしても、もちろんアルファならではのとんでもないエラー勃発などはあるにしても、全体に非常に安定しており、また、12.04 LTSのユーザである私からみても大きな戸惑いを感じない設計となっている。

12.04 LTSは、確かにPreciseというニックネームでデビューしたが、実際のところはどこまで”Precise”であったかという点でやや疑問が残るリリースであった。とりわけUnity、あるいはそれにまつわるCompizなどはあまり安定しているとはいえない部分もあったし(度重なるアップデートでずいぶん改善されたが)、私もこれを2年使うというのはちょっとつらい部分もあった。正直今ですら13.10にアップデートしようかと思うくらいである(もう14.04が待ち構えているのでやらないが)。

特にプリンタ周りでは12.04 LTSには相当苦労させられた。もともと、Ubuntuは印刷機能が弱点の1つではあるのだが(これはUbuntuに限らず、Linux全体にいえることだが)、12.04 LTSはかなりこれがひどかった。職場のマシンではプリンタがハングアップするトラブルにいくども出くわし、自宅のマシンではブラウザからプリントアウトすると画面が真っ黒になるというトラブルが出る有様。
前者はアップデートが出たのだが、そのアップデートを適用しても治らないケースが多発。後者については私だけの症状だからなのかLaunchpadでも放置されたままである。
ただ、仕事で使っている私のようなユーザにとってはプリンター使用は必須であるだけに、12.04 LTSのような悲惨なプリンタサポートではちょっと困るのである。

14.04についてはまだ実機をつなげてのプリンタテストは行っていないが、ネットワークプリンタの使用だけに限定していえば、スピードの改善などがみられ、期待を持たせてくれる。

その他の点でみても、12.04 LTSではなかった「再起動」メニューが追加されていたり、細かな点での改良の積み重ねがいい感じで効いてきている。
4月のリリースが待ち遠しい。

有人宇宙開発への道・その0

先日、私が期せずして有人宇宙開発について連発してツイートを発したのだが、その内容について鈴木一人先生が大変ていねいにブログにまとめて下さり、またコメントも付して下さった。私のやや暴走気味のツイートに対して本当にていねいな考察、ご意見をつけて下さったことに本当に感謝と敬意を申し上げたい。

ツイートそのものについては、鈴木先生のブログをご参照いただきたい(自分のツイートなのだが、取り出すのがなかなか大変なので)。
また、その一連のツイートの元になった、松浦晋也さんの日経ビジネスONLINEへの投稿「姿を現したインドの有人宇宙船」もぜひお読みいただきたい。松浦晋也さんの本稿脱稿のツイートが元になって、一連のツイートが始まっている(ただ、松浦さんご自身は関与していないので念のため)。

まず、私が有人宇宙開発に積極的な理由としては、以下のような点がある。

  •  人間を宇宙空間に送り込むことによる技術的な優位性
    科学的探査、あるいは将来予想される資源採掘などにおいても、現時点では機械的な無人による調査、行動などよりも、人間を利用した現地調査などの方が技術的、科学的な収穫という点で優位性が高い。とりわけ、月や火星など、あらかた無人探査が一巡しているような天体においては、より詳細な科学的な調査を行おうとすれば、有人という選択肢は必ず入ってくるものと考えている。人間が現地で判断し、動作を素早く切り替え、決定することができれば、無人探査では得られない、あるいは非常に時間とコストがかかる成果を得ることが期待できる。
  • 国家の技術的な優位としての有人輸送手段
    宇宙空間という、将来的に大きな経済的、国家戦略的な利益が得られる場所において、そこへのアクセス手段を自国において確保しておく、あるいは少なくともそのような技術を自国により確保しておくことは、将来、他の国による技術独占、アクセス手段独占、あるいはそれに伴う国家的な利益の減少を防ぐことにつながる。

もちろん、「次世代への刺激」や「技術の継続性の担保」といった部分もあるかも知れないが、私としては上記のような点となる。

以下、鈴木先生のブログを引用しながらコメントしていく。

むしろ、このツイートで気になるのはインドにも「抜かれた」という点で、個人的には有人宇宙事業で「抜かれた」としても特に問題はないどころか、拙著『宇宙開発と国際政治』で論じたとおり、限りある国の資源を経済的・科学的・軍事的価値の低い有人宇宙事業に他国が投入してくれるのはむしろ喜ばしく、どんどん抜いてくれ、と考えています。

ここの点はおそらく鈴木先生とは立場が合わない部分になるとは思うのだが、実際に有人宇宙開発が経済的・科学的・軍事的な価値が低いのかどうかという点については私はそうは思っていないというところである。
軍事については人間を宇宙空間に送り込むことによる軍事優位性というのが現時点ではまだ考えられないが、将来的には十分にありうると思われる。むしろ、現在の宇宙開発のルールが未整備で「やってしまった者勝ち」の世界であれば、どこかの国が宇宙空間を軍事利用のために使用する、あるいはそのために宇宙飛行士などを送り込むということは十分考えられることである。
科学的な面でいえば、上記で述べた通りで、いくら高度な機械、センサーを現地に投入したとしても、実際に物を触れない、プログラムされた動きしかできない無人探査では限界がある。いずれは有人による科学探査を検討する時期になってくるはずである。経済的な面については、このあとにさらに触れていくことにしよう。

寺薗先生のツイートがそういう意図なのかどうかは明示的ではないが、そういう議論であるとすれば、それは経済学でいう「サンクコスト」の概念で説明され るべきであろう。企業が失敗してきた事例として、過去の業績や成功に囚われ、不採算部門を切れずにそのまま続けることで会社が傾くといったことが見られる が、有人事業についても、過去にどれだけ投資したとか、どのくらい宇宙飛行士がいるからといった議論で有人事業を継続すべきだ、という議論は積極的に支持 できない。

このサンクコストの側面についてはよりデータが必要で、本当にどれだけのコストを日本がこれまでの有人宇宙開発で費やし、また現在費やしつつあるかという見積りが本来は必要なのであるが、今のところ私もそのような資料を持ち合わせていない。ただ、今の日本の有人宇宙開発が「不採算部門を切れずにそのまま続けることで会社が傾く」ほど不成功だとは私は思っていない。さらにいえばサンクコストだけでなく、国家保障や、次世代のフロンティアに進むための先達権などを確保するという意味で、コストにならない、あるいは現在かけるべきコストが存在することも考えられるわけで、一概にサンクコストだけをみて有人宇宙開発から撤退することは、次世代の技術の放棄にもつながる可能性があるであろう。

無人から有人に向かっているというのは果たして明らかなのだろうか。アメリカは国がやる有人から民間がやる有人に向かっているし、ロシアは過去の有人事業の遺産は維持しているが、新たなプロジェクトは無人が多い。中国、インド(+欧州) のトレンドだけを取り上げて「どの国も」や「世界の趨勢」というのは少し違う気はする。

世界の宇宙開発をみればアメリカ、ロシアは無人から有人へと着実に進めてきているし、中国、インドもそう進めてきている。ヨーロッパはというと、ロシア、中国などパートナーの力を得て独自の有人宇宙アクセス手段を保持しようとしているようである。またもちろん、ESAとしても宇宙飛行士を独自に養成しており、国際宇宙ステーションにも独自モジュールを確保しているほか、スペースシャトルなどによる飛行も行っている。この点ではやや日本と似た立場といえる。
宇宙開発というとこの6カ国(アメリカ、ロシア、ヨーロッパ、中国、インド、日本)が現在メインプレーヤーとなっており、結局そうなると世界の趨勢は「無人→有人のステップを着実に進めている」ということになるのではないだろうか。
なお、ロシアの新たなプロジェクトが無人が多いとはいっても、その宇宙開発のプロジェクトの大きな収入源が有人輸送費用(アメリカや日本などからの宇宙飛行士の輸送請負)であるという点は忘れてはならないだろう。

この点については強く反論せざるを得ない。これまで商業打ち上げで圧倒的なシェアを誇ってきたのは欧州のアリアンロケットであるが、欧州は有人宇宙船の技術を持っていない。世界で最も複雑で高度な有人技術を持っているアメリカのロケットも一時期商業打ち上げに参入していたが、顧客が全くつかず(だれもアメ リカのロケットで打ち上げようとせず)、商業市場から撤退した。ロシアのロケットは商業市場でも顧客を獲得しているが、それは技術が高いからではなく、価格が安いからである。つまり、有人技術があるかどうかは関係なく、価格と信頼性(実績)でロケットの選択は決まってくる。なので、有人技術がなくても、価格と信頼性のつり合いが取れれば人工衛星の打ち上げ受注は出来るし、有人技術の有無は無関係と言わざるを得ない。

たしかにこの部分はやや先走ったツイートだったかと思う。もっとも、有人宇宙開発技術で得られる高度な信頼性(無人に比べてはるかに高度な信頼性が要求される)が無人技術にもたらされれば、結果的にそれが技術的な信頼性に波及していくことは指摘しておきたい。

有人分野で抜かれることと、惑星探査(マンガルヤーンは火星探査)の分野で抜かれることは別次元の問題だと考えている。惑星探査の分野については、国際競 争の観点から考える必要もあるし、宇宙科学全体の中での資源配分など、様々な観点から論じるべきであると考えている。しかし、惑星探査の分野で抜かれるこ とと、有人分野で抜かれることは別の議論として論じる方が生産性が高いと思う。ただ単に「抜かれた」ということを起点として議論を起こすと、不毛な「宇宙競争」に突入し、貴重な人的・財政的資源を感情的な理由で振り向けてしまう可能性がある。それは避けたい。ゆえに「抜かれた」ということを起点に議論する のではなく、日本にとってどのように有人宇宙事業を考えるべきか、どのように惑星探査・宇宙科学を考えていくべきかについて論じるべきだと考えている。

一見すると確かに惑星探査と有人探査は別々のことのように思えるが、科学的な側面からの有人探査という点で考えればその点は決して別々ではない。例えば中国の場合では、嫦娥シリーズの無人機の打ち上げの後に、その実績を踏まえて有人月探査を実施しようとしている。それは資源確保かも知れないし、国威発揚かも知れないし、科学探査という側面もあるだろうが、無人探査と有人探査、(月・)惑星探査と有人探査は区別できない側面がある。とりわけ地球近傍(数百キロ)ではなく、月、火星、小惑星といった遠距離天体についていえば、この2つは切っても切れない関係にあるといえる。また、「抜かれる」という点に関してそれは別に構わないという感じで受け止められる部分もあるように思えるが、科学者としてナンバーワンデータが得られないということは非常にダメージが大きい。それは真っ先に人がいないところに行ってデータを得てくることである。もっとも、月や火星はもう科学的に十分なほどの無人機が行きデータを取得しているようにみえるが、科学者としてはそれではまだ足りない。
マンガルヤーンの場合、その「探査し尽くされた」火星にわざわざ赴くわけだが、そこで自国ならではの技術の確保(実際マンガルヤーンのいちばんの目的は深宇宙飛行技術の確保とされている)を行うことは、将来の科学探査、次のステップの前提であり、他の国がそれをやってしまっているときに何も手を打たないということは問題である。その技術を使って科学者がナンバーワンデータを得て科学的な成果を出せるということが重要であり、いくら科学データは世界共通、公開されるといっても、まずその国、あるいは参加した科学者が独占する期間があり、その間に参加した科学者が必死になって結果を出すからこそその国の科学技術が向上する。

ただ、このポイントは私も重要だと思う。

最後の一文はその通りだと考えている。有人をやるかやらないか、という議論を出発点にするのではなく、日本が宇宙開発で何をやり、どのように戦略的に存在感を発揮するべきか、という議論を出発点にして、そのために有人事業が必要かどうか、という議論にしていくべきだと考えている。

というより、ともかく議論の素地となるデータ、あるいは議論をする場所などが足りないのである。私もこうやって書きながらも、データを得ようとしてもなかなか得られない、あるいは得ようとすれば膨大なサーベイが必要になってしまう、という点で、1人の力の限界を感じているところである。

★★★

という形で、鈴木先生のブログへのお答えという形で書いてみたが、何よりも上述のように、データが足りない。私自身の素養も足りない。おそらくは時間も足りない。民間宇宙開発の急速な勃興や世界的な宇宙開発のトレンドの変化、とりわけ「ポストISS」へ向けた動きの状況によっては、この議論そのものが全く意味をなさなくなるようなことも起こりうるかも知れない。

いま日本が宇宙開発でなすべきこととしては、まず(有人にせよ無人にせよ)5年、10年、20年先を見据えた宇宙開発のビジョンを提示し、そこに向けて探査やインフラ整備などをどうしていくかを構想し、国がやるのか、民間がやるのか、あるいはやらないのか、といった議論を広く展開していくような場を作っていくことが必要だ。そして、その議論のための情報がわかりやすく用意され、容易にアクセスできるような環境にしていくことが必要かと思う。この練り上げられていない「バージョン0」ブログ記事も、そのためのきっかけになればせめてもの幸いである。

私自身の大変拙いツイートにお応え下さった鈴木先生に改めて感謝申し上げると共に、今回のやり取りを通して、宇宙開発に携わる人、宇宙開発を愛する人たちが、いろいろな形で「自分たちがやって行きたいこと」に声を上げて下さることを望む。