マルチモニターと似たようなデスクトップの使い方を１つのモニターでページを切り替えて扱えるソフトのこと。遠く離れたサーバーで動くOS（Windowsなど）のデスクトップ画像を手元の端末で表示し、手元のマウスとキーボ－ドで操作できるVDI(仮想デスクトップインフラ)と云うのもあり、「仮想デスクトップ」の意味はかなり曖昧になっている。
要はパソコンにデスクトップ付のＯＳをインストしたかの様に扱えるけど、

• 実はデスクトップが何倍も広いんです。
• 実はＯＳは遠くのサーバーにインストールされてるんです。

という感じで「実は・・・なんです。」が付けば「仮想デスクトップ」なのかもしれない。
ただ

• 実はディスクがサーバーの中なんです。

は最初からディスクレスと云う呼び名が付いていた。
ブラウザの画面にデスクトップっぽい内容を表示する「ウェブデスクトップ」も「仮想デスクトップ」の一種で、お手軽に遠くのサーバーのデスクトップを操作（GUI）できる。しかし機能やGUIの表現に制限（ブラウザやHTMLあるいはセキュリティ上の制約）が多く、開き直ってデスクトップそのものをHTMLブラウザ仕立てにすることで解消したOSもあるようだ。
もともと「仮想＊＊＊」という用語は「＊＊＊に似てるけど、ちょっと違う」の意味であり、こんな感じなんだと大体のイメージが付くと別の名（通称）が付くので時節モノである。
※仮想メモリは例外的に長く使われており、未だ通称が無い。このままスマートメモリが実現してしまうと先に絶滅しかねず不憫である。
※仮想メモリはＣＰＵから見た（論理）メモリアドレスを都合の良い様に（物理）メモリアドレスにアドレスを変換する機能と、メモリの容量をオーバーしたデータをディスクに退避するスワップ機能の２つで構成される。ＧＵＩでは複数のアプリを順不同で操作することが多く、アプリからメモリ領域の全てを読み書きできる仕組みでは、使っているアプリやその組み合わせにより、データ破壊やアプリの異常終了さらにシステムダウンにまで起きてしまう始末で、今ではアプリのメモリ領域は互いに隠ぺいするのは当たり前になり、アドレス変換のみが機能している状態を特に「仮想メモリ」とは云わなくなっている。

さて年が明け２０１４年がやってきました。
古いと云わつつある立体感のあるボタンのデザインですが、前世期のMS-Windows3.xがウケた主な理由は平面なボタンから立体感のあるボタンのデザインに変わったことでした。
当時の光学マウスは高値の華、主流は機械（ボール）式でした。そのボールも専用のマウスパッドの上でも空転しやすく微妙な力加減が必要で、長時間操作すると肩が凝ってしまう始末でした。そういう感じでしたから、マウスポインタを画面の中のボタンまで移動し、クリックしても平らなボタンがピカっとハイライト（高輝度）やカラーコードを反転するだけで物足りなかったのでしょうね。
しかし昨今のタブレットやスマホではディスプレイの上で指をスライドさせて操作することが多いせいで、ディスプレイが平面であることを強く意識してしまい、画面に映されるものも立体感がない平面なデザインの方が直接触っている感じがします。スワイプするモノがリアルで立体的だったら重そうじゃないですか？（笑
そうなんです、色がちょっと変わったりする軽い感じの方がぴったりなんです。
そうそうマウスよりも更に古いものにライトペンがありました。今ではタブレットペンとして形を変えて復活してしまいました。そうなんです手に持って扱うタブレットなら指より細いタブレットペンの方が実に操作しやすいのです。
そう考えると、「３０年ひと昔」と昔の人は云ってましたが、UIもそんな感じで、グルグルと取り替えてるだけなのかもしれません。
画面に直接触らず操作できるマウスが丁度良かったのも、前世期ディスプレイの主流だったブラウン管の構造が真空管そのもので静電気や磁気の影響を受けやすく直接手で触るのは控えた方が長持ちしそうだったことも要因の一つだったかもしれません。
では、ディスプレイを直接手で触ると、どうしても汚れやすいですから次第にイライラの原因になり、PS-VITAみたい本体裏側からも操作するUIの方がクールになるのでしょうか？
もしかすると専用の３Dメガネが必要ない３Dディスプレイが主流になれば、見えるけど触れない立体的なフルサイズのキーボードやマウスが浮かび上がってくるのかもしれませんよね？
とすれば、UIのデザインの移り変わりも、ディスプレイの持つ長所や短所とかなり密接な関係にある様です。
果たして、「昔のタブレットのディスプレイは２Dつまり平面な表現しかできず、キーボードが飛び出さなかったから、直接ディスプレイの上をなぞってたんだよね？だからすぐ汚れて・・・」などと云っているボクが居そうな未来は来るのでしょうか？（大笑

サーバーを仮想化すると何が嬉しいか？
それは・・・
インスト仕立てのイメージを残しておけば、元に戻すのが簡単だから（大笑
サーバーに必要なパッケージ（アプリとかサービス）を入れているうちに、使用しているライブラリィのバージョンの競合問題とか色んなことが発生する。
そうなったら、とりあえず、前の状態に戻すのが一番だ。
しかし、何かトラブルが発生すると、アンスト自体失敗しかねず、何かゴミファイルが残っていることに気が付かないと、それがきっかけになってパッケージの再インストに失敗することも多い。
そう、何かパッケージを入れる前に、仮想化の管理ツールからディスクのスナップショットを取っておくのが一番なのだ。
そうしておけば、とりあえずインストして、終わったら直前のスナップショットに巻き戻すなんてこともできる。
パッケージの設定方法はなぜか色々あって、どれが一番良い結果になるのか・・・・・・・・・・・・・・・・・・・・・・・

やってみないと判んない！

なんて場合にも便利だ。
失敗する度にＯＳから入れ直しなんてやってられないからね。
・・・（遠い目
それに無償パッケージばかりなら、うまくいったイメージをコピーして、比較的短い時間でサーバーの数を増やすこともできる。
Ｗｉｎｄｏｗｓ８　ＰＲＯにＨｙｐｅｒＶを追加すれば、仮想サーバーを作ることができるから、そこで、お試しでＣｅｎｔＯＳの新しいバージョンや古いバージョンを作って様子を見ることもそれほど費用をかけずにできる。※仮想サーバーで使う分のメモリを用意しておく必要はある。
ただ、DiXim Digital TVと何かが競合するようで、ＢＤレコーダの録画が見れなくなるのが欠点だけどね。（渇いた笑
 
そんな訳で、サーバーが扱いやすいものだったら、仮想化なんて不要なのだ！と云う点は押さえておこう。
 
つまり仮想化をプッシュしてくるという意味は結構根が深いのだ。
でも、現実問題として扱いやすいものなんて、早々巡り合えない訳で・・・
やはり仮想化は便利。
しかし、仮想化しなくても扱いやすいのが一番だよね！

一言で云えば無茶。
/etc/sysconfig/network-scripts/ifcfg-eth0 のようにBOOTPROTO=”dhcp”　を書けば、勝手にIPアドレスが貰える訳では無い。
無線LAN接続で、ログインして暫くたった後にブラウザやメーラを起動するハズ！そう云う考えで作られていることを痛感した。
大事なことなので復習しよう。
まず、wpa_supplicantパッケージをインストして、
# wpa_passphrase {SSID}  {パスワード}  >> /etc/wpa_supplicant/wpa_supplicant.conf
でひな形を作った後に、
無線LANの環境に合わせて、

proto=WPA2
key_mgmt=WPA-PSK
proto=WPA WPA2
pairwise=CCMP TKIP
group=CCMP TKIP WEP104 WEP40

などを追加し、
# service   wpa_supplicant   start
# ifup wlan0
# chkconfig   wpa_supplicant   on
これで起動したときに無線LANが使えるような気がするが
実際には無線LANのSSIDの認証をした後に毎回
# ifup  wlan0
が必要らしい。
しかし、モニターすら繋いでいないのに素で、起動の度にキーボードを繋ぐのも面倒なので、
/etc/init.d/wpa_supplicant　に
ifup wlan0を追記するのが現実的。
 
 
何度かコールドスタートを行い、 安定したことを確認したら、
# ifdown eth0
で有線LANをOFF、ルータからIPアドレスの割当てをMACアドレス指定の手動設定に変更し、外部から８０ポートでアクセスがあれば飛ばすようにする。
※このブログを見るにはＩＰアドレスのＵＲＬで十分だが、ＦＦ１４のブログの方はマルチドメイン寄生型なので、無理。
/etc/hosts に
自身のマシン名．ドメイン名     192.168.***.***
名前でＩＰアドレスを引ける様にしておかないと、WordPressの自動バックアップのメールが届かないっぽい。
また、メール送信にはトリガーとなる真夜中のアクセスが必要らしい。
 
しかし、LANケーブル一本減らすには面倒すぎるなぁ～

EJBを使ったJavaのなんたらシステムが起動した後に、中のEJBが安定するまでの時間は運用してみないと誰にも判らない。
と云うのも、ヤベーと誰かが気が付いて、実装クラスのインスタンスをインタフェースの変数にインジェクションするからだ。
云ってしまえば、インタープリターのごとき仕業であるので、遅いの一言に尽きる。
EJBを使えばjUnitでmockが便利なんて詭弁でしかない。
大体、mockのソースの賞味期限は数か月にも満たないのが普通で、
そんくらいなら、Eclipseで、src/main/javaとsrc/test/javaのクラスパスの順番を変えるくらいで十分だし、その為だけにjUnitのテストソースからプロセス起動するようなことをしてもよいだろう。
※当時の言い分：　EJBが出来た頃はEclipseなぞ無く、エディタ＋Shell＋吐き出されるログが全てだったので、環境変数のクラスパスを手で変更するのは大変危険だった。
とあるよく使うDaoなりActionなりをEJBで作り、jUnitでテスト環境を作ったとしよう。
それをベースに１０～２０個のコピペのようなものは、非常に簡単にできる。
しかし、
本当の地獄はその後に始まる。
Daoに何か変更が入ると、上記のコピペに一斉に修正が必要になる。
１０個ならマシだが・・・１００個だったら、結構大変だ。
そして、
当然の帰結として誰も誰も使わなくなり、
更に数か月が過ぎると、全く使い物にならないjUnitソースの残骸が残るだけなのだ。
無論、プロジェクトの立ち上げ時には非常に役に立つ。
但し、その後は捨てるものだ。
最後に残るのはEJBで作ったDaoやAction
どうやってテストするんだろうね？
え、実際に画面を実行？
です。（キッパリ
だって、その方がちゃんとしたテストデータもテストケースもあって、役に立つんですからね。
ここに到達してしまうと、
jUnitなんてもう使う訳もない。
※当初の仕様から全く変わっていないものを除く。
別に、直接Daoオブジェクトを作っても何も支障が無いことに気が付くわけである。
Actionだって、httpセッション経由で起動をかけることだって、別に難しい訳でもない。
それでも、今なおEJBは生き残っている。
理由はいたって簡単、
大半の機能を使うこともないlog4jを何となく使ってしまうのと同じなのだ。
多分、Java系の定番jarファイルを使うのを止めたら・・・
別世界なんだろうな。（大笑