変奏現実

Windows７はアタリ。
※但し、それは発売当時の話で、クラウドが当たり前の今では、現行のOSがほとんど64ビット化されている中、７に搭載されている仮想マシンは32ビット版のOSのみ対応で、はっきり言えば特定のOSでしか使えない。その特定のLinuxのいくつかのインストーラでは仮想マシン環境のHDDを認識できない仕組みになっている。またWindowsUpdateの自動再起動でゲストが簡単にクラッシュするなど地雷原になっている。なので今更Windows-7を使うメリットは何も無い。
次の８はハズレ。
だから、その次の１０はアタリ！
ということがまことしやかに書かれている記事があった。
しかし、
本来なら・・・アタリ９が来るべきのところを・・・Verを１つスキップして、１０を出してきたのだから・・・
やはり
１０はハズレでしょ？
と、ボクは思う。
９をスキップした本当の理由はよく判らない？
WindowsのバージョンチェックのAPI（GetVersionEx）が返すコードと商品名のVer番号とはすでに一致していない。
※Ver5: 2000、XP、Server 2003
※Ver6: Vista 、7 、８、１０、Server 2008
そのため、GetVersionExを使っても、どのWindowsなのかはっきりしない状況で、実質的な非推奨APIも同然で、GetFileVersionInfoが勝手に推奨されだしたため、
その場しのぎのバージョンの最初の一ケタ目しか見ていない「おっちょこちょいなサンプル・コードが無分別にどのアプリにもコピペされ」、Windows – 9 とWindows – 98の区別が付かない！というオチが発生した。
なので、「本来は」商品名から番号を外して名前（XPとかVISTA）を付けるべきだったのだ。
それなのに、１０にした理由って何だったのだろう？なぜ番号にこだわらなければいけなかったのだろう？
もうバージョンアップを本当にしないなら・・・
Windows－Final－Release　でもよかったはずなのだ！
ならば、１０という数字には・・・
（今は）バージョンアップ（なんて）しない（つもり）です。（未来のことは私たちには解りませんから！）
という意味が込められているのかもしれない。
ならば、
２０２０年までにWindows-11が登場するはずだ！（ロゴはサッカーボール風になる！）などと誰かが予言しても、今は笑い話でしかないが、９９．９９９９％くらいの確率でアタルんじゃないのかな？
と思えてくる。（大笑い
VRを本格的にUIに取り込めれば「売れる！」んじゃないかな？などと考え始めたら・・・
Ver.１１でVR向けにUIをガラっと変えてサッカーしようぜ！というのも、ありそうに思えるからだ。
 

何気に26日(木)頃から見れなくなっていた様だ。
再起動したが、アクセスしてくるのはIPアドレスを知っている？BOTたちだけ
なぜか外からは見れないらしい。
IPアドレスが、　　***.***.***.1 になると外部からのアクセスに失敗する様になったのかな？
ルータも再起動して、IPアドレスを再取得してみた。
後はnslookupで更新待ち

apacheでバーチャルドメインを使う場合

NameVirtualHost *:80

と宣言してから

# AAA.xxx
<VirtualHost *:80>
 ServerName AAA.xxx
 DocumentRoot "/var/www/AAA.xxx"
 ErrorLog logs/virtual-AAA-error_log
 CustomLog logs/virtual-AAA-access_log combined env=!no_log
</VirtualHost>

とすればいい。

NameVirtualHost *:80は無くても動くときは動くけどね。

※さっきまでコメントになってた（大笑
マルチドメインなら続けて

# BBB.xxx
<VirtualHost *:80>
 ServerName BBB.xxx
 DocumentRoot "/var/www/BBB.xxx"
 ErrorLog logs/virtual-BBB-error_log
 CustomLog logs/virtual-BBB-access_log combined env=!no_log
</VirtualHost>

な調子で追加すればいい。
このブログは<VirtualHost>の部分をファイルにしてconf.dに配置しているが
NameVirtualHost *:80
Include   conf.d/VirtualHost/*.conf
と順に読むように指定した方がいいかもしれない。
SSLの場合は普通ポートが443なので

NameVirtualHost *:443

と宣言してから

# AAA.xxx
 <VirtualHost *:443>
 ServerName AAA.xxx
 DocumentRoot "/var/www/AAA.xxx"

 SSLEngine on
 SSLCertificateFile      /どこかの/SSLサーバ証明書のファイル
 SSLCertificateKeyFile   /どこかの/SSLサーバ証明書とペアになる秘密鍵のファイル

 ErrorLog logs/virtual-AAA-error_log
 CustomLog logs/virtual-AAA-access_log combined env=!no_log
</VirtualHost>

とすればなんとなるらしい。
でも、普通はどこかのCAに署名してもらった電子証明書を使うので・・・

SSLCertificateChainFile　　/どこかの/中間証明書のファイル

が必要な気もするが、ブラウザの中にすでに入っている様な気もする。
とりあえず、
以前は<VirtualHost>の外側、つまり証明書を１つしか配置できなかったので便利になった。
でも、

NameVirtualHost を２つ（80,443）を配置したらどうなるんだろう？

動くのかな？
そろそろ、ここもSSL化した方がいいのかもしれない。
と思って調べてみたわけ。
でも、DDNSのドメインを使ってるから無理だよね。
まずは、ドメインから・・・
かな？

この前の3.10.0-327.4.5.el7は、ちょっと不調だった。
virsh console で覗いても　login: が出てこない。
virsh start の後、すぐに　virsh consoleでコンソールに起動ログを流してみると
最後に
[+] xxxxxxxxxxxxxxxxxxxx
[+] xxxxxxxxxxxxxxxxxxxx
[+] xxxxxxxxxxxxxxxxxxxx
で終わっていた。
カーネルがフォルトしているようだった。
何度リブートしても同じ。
こういう時には
いつも頼りにしているCentOS系のサイトがつながらなくなっていた。
同じオチに引っかかっているのかもしれない。
なので、適当に・・・

• GRUB（ブートローダ）らしき文字が映っている間に
• ↓を押して、1つ前の4.4.el7で起動してみたら
• うまく起動できた。

しかし、こんな時にも遥々中東からログイン画面を周回している奴が来て、コンソール画面は、あっと云う間に[IPTABLES INPUT] : IN=eth0 OUT= MAC=ｘｘｘｘのログで埋まってしまう。ルータからの接続を切ってから調整した方が良いだろう。
一旦、4.4.el7でゴミ掃除をしてもらうため、１分ほど経ってからreboot したら
メデタク4.5.el7で起動できた。
メデタシメデタシ？
こんな時にはいつもお世話になっているサイトが「安全ではない接続」のページになっていた。
ここのBLOGはどんな風に観えているのだろう？
「怪しいサイト」かな？
んー
それは年中そうなっている気がする。
数分後、いつもお世話になっているサイトはいつも通り見ることができるようになった。
メデタシメデタシ
いやそうではない。
大体 両方のサーバーが　同時に　yum update やってハマルということが起きる訳がないのだ。
おそらく０時０分に偶然再起動したのだろう。
偶然その時に覗いたので、偶然同じような不調な画面になっていたのだろう。
起動直後はSSLサービスも起動中で「安全ではない接続」かのように見える状況も起きうるのかもしれない。
だから、安定した今ならちゃんとサイトのページが見えるのだ。
メデタシメデタシ
んん。サイトの地球マークは灰色だ。
マウスでなぞると「このWebサイトには運営者を証明する証明書はありません。」
ではさっきの「安全ではない接続」ページへリダイレクトしたのは何だったんだろう？
 
謎は深まるだけだった。
（この項、終了

去年の年末に長らく（１５年ぐらい）使用していたDOCOMOをIIJに変えました。
一気に月額料金が下がったものの、12時～13時の間や夕方6時頃にアンテナマークが消える様になりました。
SO-04EのWifiテザリングはバッテリーの消耗が激しく、アンテナマークが消えると電波を必死に探すのだろうか？もっとひどくなるので、ASUSのME572CLは別回線。
２回線にしたせいか、2月1日時点での残量はSO-04Eが８GB、ME572CLが６GBと、契約の2倍。1月分がすべて引き継がれているかっこうだ。
さっぱり使っていない訳ではない、動画はまず見ないが、ゲームは（ほぼAUTOだけど）1日数時間くらいやっている。
もっとも、12時～13時の間や夕方6時頃に通信できないのが通信量が少ない主原因かもしれない。（大笑
一方で、2月からDOCOMOの０円携帯が消えるらしい。つまり割引額が減るのだそうだ。
見逃したのか？継続中のスマホの通信料金が安くなるという文字は見当たらなかった。
ま、新規やMNPの割引額が減るから・・・これからは値段が高いiPhoneには逆風？・・・それとも元々人気も高いiPhoneだから影響が少ない？
とりあえず、ボクのように値段が高いのでiPhoneが買えない人はいつまで経っても買えないが、好きな人は多少高くても毎年新iPhoneを買うだろう。だって、楽しみなのだから・・・
で、重要なのは、その比率。
 
で、どうなんだろうね？興味深々？んー
スポーツは観戦するもの。
でも、スマホのコレは、
iPhoneかAndroidかその他（WindowsMobileなど）のどれかを買って参加できるゲームになっている様な気がする。
ほどほどに一方が勝って、ほどほどに一方が負ける分には
自分は困らないので
勝敗はどうでもいいのだ。（大笑

svnadmin hotcopy で自動ロック付きで最新版をコピるのもいいけど、
リポジトリィを作ってから数年も経ったらsvnsync コマンドで、日々リポジトリィの差分アップデートする方がいいだろう。
hotcopyの処理時間が年月と共に大きくなりすぎた頃に思い知らされるだろう。
リポジトリィの２重化と同期が手早くできるなら、スタンバイ側をsvnadmin  dump で履歴をしっかり取ればもっと安心だろう。
世の中は既にsvnからGitに移り変わっている。
Gitは、いくつものリポジトリィを繋いで運用するのが前提になっているので、コーディング中、テスト中、αやβのリリース、最後にRCとフォークし、別々の担当者がバラバラに履歴を運用しやすくなっているのだろう。
これに対してsvnは基本は１リポジトリィで、リポジトリィ間の操作と云えばバックアップや負荷分散などでリポジトリィを一気にコピートする程度の機能しかないから、複数のリポジトリィを運用するには、十分に注意が必要で、プロジェクトの各担当者に仕事を割り振り、自主的にコミットさせてしまう・・・と、スケジュールの遅延次第では、新旧未来の状態が混在し、容易にはリポジトリィにタグを付けられなくなるから、バブルフローな仕事のやり方をしなければいけない。
こう書いてしまうと、忙しいご時世だからsvnはもう終わってると思えるだろう。
しかし、Gitも所詮は履歴管理システムであり、マメにリリースを管理できる人が必須な要員であり、ザルでソロな管理人には無用な長物。Gitに毛の生えた程度のEclipseのローカル履歴とsvnの組合せで十分だったりする。（大笑
 
 
 
 
 
 
 

yum で update 中に落ちた。
起動後にupdateしなおしたものの

-bash: warning: setlocale: LC_CTYPE: cannot change locale (ja_JP.UTF-8): No such file or directory
-bash: warning: setlocale: LC_COLLATE: cannot change locale (ja_JP.UTF-8): No such file or directory
-bash: warning: setlocale: LC_MESSAGES: cannot change locale (ja_JP.UTF-8): No such file or directory
-bash: warning: setlocale: LC_NUMERIC: cannot change locale (ja_JP.UTF-8): No such file or directory
-bash: warning: setlocale: LC_TIME: cannot change locale (ja_JP.UTF-8): No such file or directory

運悪くLC系のアップデート中だったらしい。
CentOS6の様に　i18n でゴニョしようとしても
# cat /etc/sysconfig/i18n
cat: /etc/sysconfig/i18n: そのようなファイルやディレクトリはありません
なので、そうすれば古い仕組みで見かけ上うまくいくかもしれないけど・・・
# locale -a  や　# grep ja_JP　はそれなりに動作するが
# locale -a | grep ja_JP　などとすると
LC_CTYPEが使えないせいで、上のメッセージだけ表示して中止。
同じ理由なのだろう。
poweroff　しても
電源が落ちない。
コレではマズいので
/usr/share/i18n/locales に ja_JPなどが多数あったので
# localedef -f UTF-8 -i ja_JP /usr/lib/locale/ja_JP.UTF-8
してsetlocaleを使っているプログラムなら大丈夫のハズだが・・・
SSHで接続すると、まだwarningが２つ出てしまう。
ググってみると、glibcのリンクがまだイカレている可能性があるようだ。
yum install glibc-common　してリンクを修正させた後に
localedef -f UTF-8 -i ja_JP ja_JP
するとやっとwarningが消えた。
poweroff
で電源も落ちた。
これでいいハズ。
なぜシェルからコマンドがうまく動作しなくなったのか？
原因はLC_CTYPEなどを使ってメッセージを日本語にできる仕組みを組み込んでいるプログラムの場合、自分のプログラムミスでLC_CTYPEでエラーが出た場合を想定して上のエラーメッセージを出し throw させているんじゃないかな？
なので、トリアエズ日本語にするのはいいけど、
どんな仕組み（実装）なのか判っていないと、
何気に見えないところでコマンドが通らなくなっていたりすると、ヤバすぎだね！（汗