変奏現実

パソコンやMMORPGのことなどを思いつくまま・・・記載されている会社名・製品名・システム名などは、各社の商標、または登録商標です。

この画面は、簡易表示です

アクリルアミド

焼いたり揚げたりした食品にはアクリルアミドが含有されているので、大抵の調理したものは大体該当する。
検出量が多いものがあった食品は・・・

食品 検出値
(ng/g)
ポテトチップス 1008
コーンスナック 535
フライドオニオン 428
ほうじ茶 567
カレー粉 423
フレンチフライ 784

検出値には、かなり開きがあるので、焼き加減次第の様だ。
アーモンドなど保存用に加工する際に入ったりしている様で、燻製も多そう。
ビールには入っていないようだが、発泡酒や日本酒は計測値すらなく、含まれているかどうかすら判らない。
それどころかフライパンで調理したら真っ黒けになったもの、沸騰したお湯で煮込み過ぎてカラッカラになったもの、電子レンジで休息過熱したものなど、いかにもアクリルアミドが大量に含有していそうなものが含まれておらず、怪しい結果となっている。
 
 



起動時間 systemd-analyze

systemd-analyze で起動時間を調べてみた
ホストOSは
# systemd-analyze
Startup finished in 7.791s (firmware) + 5.127s (loader) + 2.282s (kernel) + 2.074s (initrd) + 9.397s (userspace) = 26.672 s
ゲストOSは
# systemd-analyze
Startup finished in 1.974s (kernel) + 6.030s (initrd) + 28.896s (userspace) = 36.902 s
どんだけ無駄なものが入っているのか?
# systemd-analyze blame | more で細かく見てみると

ホストOS ゲストOS
時間 単位 サービス 時間 単位 サービス
4.771 s network.service 21.375 s clamd.service
2.958 s kdump.service 8.439 s kdump.service
1.044 s postfix.service 6.467 s mariadb.service
780 ms tuned.service 5.059 s systemd-vconsole-setup.service
570 ms wpa_supplicant.service 4.008 s postfix.service
466 ms lvm2-monitor.service 3.481 s dovecot.service
398 ms iprinit.service 2.625 s firewalld.service
394 ms iprupdate.service 2.119 s tuned.service
338 ms NetworkManager.service 2.088 s httpd.service
312 ms lvm2-pvscan@8:3.service 1.686 s network.service
294 ms avahi-daemon.service 1.222 s iprupdate.service
224 ms rhel-dmesg.service 1.220 s iprinit.service
224 ms systemd-logind.service 1.214 s avahi-daemon.service
207 ms nfs-lock.service 980 ms systemd-logind.service
206 ms rsyslog.service 799 ms rsyslog.service
190 ms abrt-ccpp.service 649 ms chronyd.service
187 ms libvirtd.service 622 ms saslauthd.service
180 ms iprdump.service 591 ms boot.mount
174 ms chronyd.service 572 ms NetworkManager.service
169 ms netcf-transaction.service 563 ms lvm2-monitor.service
128 ms systemd-fsck@dev-disk-by\****.service 448 ms sysstat.service
126 ms microcode.service 438 ms systemd-user-sessions.service
125 ms systemd-user-sessions.service 384 ms yum-cron.service
123 ms proc-fs-nfsd.mount 353 ms rhel-dmesg.service
118 ms systemd-udev-trigger.service 320 ms dmraid-activation.service
114 ms yum-cron.service 270 ms systemd-udev-trigger.service
104 ms ksmtuned.service 241 ms iprdump.service
86 ms kmod-static-nodes.service 223 ms kmod-static-nodes.service
85 ms sysstat.service 211 ms auditd.service
75 ms dmraid-activation.service 204 ms systemd-fsck-root.service
71 ms polkit.service 197 ms systemd-udev-settle.service
71 ms systemd-readahead-replay.service 172 ms systemd-sysctl.service
71 ms systemd-readahead-collect.service 165 ms sys-kernel-debug.mount
68 ms systemd-udev-settle.service 149 ms plymouth-quit.service
64 ms var-lib-nfs-rpc_pipefs.mount 146 ms plymouth-quit-wait.service
61 ms boot.mount 138 ms polkit.service
60 ms home.mount 128 ms dev-mqueue.mount
57 ms systemd-vconsole-setup.service 128 ms systemd-fsck@dev-disk-by\****.service
55 ms plymouth-start.service 127 ms dev-hugepages.mount
47 ms ksm.service 117 ms systemd-tmpfiles-setup.service
44 ms sys-kernel-debug.mount 113 ms rhel-readonly.service
43 ms plymouth-quit-wait.service 110 ms lvm2-pvscan@252:2.service
41 ms dev-hugepages.mount 96 ms systemd-tmpfiles-setup-dev.service
41 ms dev-mqueue.mount 91 ms systemd-udevd.service
39 ms auditd.service 91 ms sshd.service
38 ms rpcbind.service 89 ms rhel-import-state.service
37 ms plymouth-quit.service 81 ms plymouth-read-write.service
37 ms rhel-readonly.service 79 ms systemd-remount-fs.service
35 ms systemd-sysctl.service 75 ms systemd-tmpfiles-clean.service
35 ms sshd.service 60 ms proc-sys-fs-binfmt_misc.mount
33 ms systemd-fsck-root.service 54 ms dev-mapper-centos\x2dswap.swap
33 ms systemd-tmpfiles-setup-dev.service 40 ms systemd-random-seed.service
26 ms proc-sys-fs-binfmt_misc.mount 36 ms systemd-journal-flush.service
22 ms systemd-remount-fs.service 25 ms abrt-ccpp.service
22 ms systemd-tmpfiles-setup.service 23 ms plymouth-start.service
21 ms dev-mapper-centos\x2dswap.swap 23 ms systemd-update-utmp-runlevel.service
20 ms boot-efi.mount 17 ms sys-kernel-config.mount
19 ms rhel-import-state.service 10 ms systemd-update-utmp.service
18 ms systemd-journal-flush.service
17 ms systemd-fsck@dev-mapper-centos\x2dhome.service
17 ms plymouth-read-write.service
16 ms systemd-udevd.service
9 ms systemd-tmpfiles-clean.service
9 ms systemd-machined.service
8 ms systemd-update-utmp-runlevel.service
8 ms systemd-random-seed.service
7 ms sys-kernel-config.mount
6 ms systemd-readahead-done.service
4 ms systemd-update-utmp.service

となった。



cheero Power Plus 3

モバイルバッテリーは充電できる回数が500回ぐらいですが
放電が早くなったものもありますが
まだまだ使い切っていない感じがするものが
手元にゴロゴロありますが・・・
ポチってみました。
スペックは、
 

  • [内蔵バッテリー/容量] Panasonic製リチウムイオンバッテリー/13400mAh 3.6V (48.24Wh)
  • [本体サイズ/重量] 92 × 80 × 23 mm/245 g
  • [本体充電時間/使用回数] 約 8 時間(2A USBアダプター使用時)/約500回
  • [入力/出力] DC 5V 2A/出力1:DC 5V 1A 出力2:DC 5V 2.4A(合計3.4A)
  • [付属品] 本体充電用USB-MicroUSBケーブル、取扱説明書、保証書(半年保証)

 
ポーチやLEDライトは付いていません。
とりあえずAmazonで、2,700円(税込、送料無料)。
ps.2014/12/08 1日早く届きました。思ったより・・・小さいw



JrunScript

JDK6以降についているjrunscriptコマンドが付いている。
※最新のVer.8でもJREなら付いていない。
なぜか、JDK8のインストーラは
PATH変数に C:\ProgramData\Oracle\Java\javapath; を先頭に追加するが、そこには java.exe、javaw.exe、javaws.exe  しかないので、コマンドプロンプトで使いたいJDKコマンドを、C:\ProgramData\Oracle\Java\javapath にショートカットかシンボリックリンクを貼れば良さそうだが、jrunscriptはjli.dllを参照しているので無理だったので、素直に環境変数を変えた方が良さそうだ。
新規に JAVA_HOME 変数を作り C:\Program Files\Java\jdk1.8.0_25 を設定。
PATH 変数の最後に ;%JAVA_HOME%\bin を追記。
※本当は正しい方法が別にあるのかもしれない。
※もし、C:\ProgramData\Oracle\Java\javapathにシンボリックリンクなどを貼ったまま放置すると「エラー: メイン・クラスcom.sun.tools.script.shell.Mainが見つからなかったかロードできませんでした」となってしまうので消しておくこと。
パラメータを付けなければ、インタラクティブモード、つまり古式ゆかしい対話式でJavaScriptを実行してくれる。
対話式の注意点としは、for文など { ブロック形式 } を使う文法も一行に収めなければダメ。

> jrunscript
nashorn> for (i = 0;  i< 10; i++ ) { printf(“%d”,i);  }
0
1
2
3
4
5
6
7
8
9
nashorn>Ctrl+C

>

nashornはJDK8のJavaScriptエンジンの名前。Java SE 7ではrhinoのハズ。
普通にJavaScriptを読ませたければ、

> jrunscript   -f  JavaScriptファイル名

とすれば、ファイル単位でスクリプトを評価するので、

for (i = 0;  i< 10; i++ ) {

printf(“%d”,i);

}

も、ちゃんと読んでくれ、同じように実行してくれる。
これだけではシェルやBATファイルの代りにJavaScriptが使えるだけ、

ScriptEngineManager manager = new ScriptEngineManager();
ScriptEngine engine = manager.getEngineByName("nashorn");
engine.eval("for (i = 0;  i< 10; i++ ) { printf('%d',i);  }");
とやるようで結局JNDIな面倒な呼び方はそのまんま。
ただ、メソッドに渡すパラメータが複雑怪奇な構造だと
evalで呼び出すのは面倒でInvokeDynamicやMethodHandlerを使えるのは便利な気もする。
//エンジンを探す
ScriptEngineManager manager = new ScriptEngineManager();
ScriptEngine engine = manager.getEngineByName("javascript");
// スクリプトで ほげ関数を 定義する.
engine.eval("function ほげ(message) { print(message); }");
// Javaから ほげ関数を呼び出す.
Invocable invocable = (Invocable)engine;
invocable.invokeFunction("ほげ", "hello");
またスクリプトで
var a = Java.type("クラスのフルパス名");
とJavaのクラスが容易に呼び出せる一方で
var IntArrayType = Java.type("int[]")
var arr = new IntArrayType(10);

と 配列の扱いはなかなか面倒なようだ。



Office Premium 搭載パソコン

コレを買うと、Office 365 Solo (¥12,744/年) のハズが
半額のOffice 365 サービス (Office Premium 搭載パソコン専用)(¥6,264 (税込))で更新できてお得ということになっているが・・・
まともなスペックのOffice Premium 搭載パソコンはドレも良いお値段になっている。プリインストールでOffice分がいくらなのかは判らないから、最初に大目に支払っているのだろう。(大笑
中にはメモリを1GBにケチるなどして安くしているOffice Premium 搭載パソコンもあるだろうけど、アンチウイルス系ソフトも常時動作しているのだ。
今までそうであったように、使用して年月が経つと、飛んでも無い量のWindows Updateにより起動が長い!動作がノロい!時どきフリーズする!などケチった分だけ痛い目に遭うのが早い事は想像しやすい。
とは云っても、過ぎたるは及ばざるがごとしの諺通り。Hyper-VでOSをいくつも動かすことが多いし、CドライブがHDDでは起動もHyper-VゲストOSも遅いので、手元のパソコンはメモリを24GBに増設しCドライブを40GBのSSDに変えてWindowsを再インストールしたらCドライブが真っ赤になっていた。
そう、そんなにメモリを載せる人が少なかった時期のWindows7なので副作用が出たのだ。Windows7の初期設定では実装メモリの3倍(仮想記憶(2倍)+ハイバネーション(1倍))の領域をHDDに確保する。圧倒的に容量が少ないSSDでも同様に確保しようとするが、さすがに遠慮して0GBにならないようになってるだけマシな状況だった。64GBのSSDでは多少遠慮して40GBぐらい食われるが、128GBのSSDになると遠慮なく実装メモリ量×3倍=72GBぐらい食われそうな勢いだった。(汗
そんな一例も含め、WindowsもOfficeも最初のバージョンから結構な年月が経っていることもあり、下位互換性を取るための様々なプログラムや設定が異常に多くなってしまう。(爆
例えXPの後継をWindowsServer200Xをベースに作ったとしても、最終的には【下位互換性を取るための様々なプログラムや設定を上乗せしない訳にはいかない】。(爆
そんなこんなで、何十年も前のWindows 3.3当時のOfficeの文書を何十年も前のパソコンで開くのと同じことをしようとすると、WindowsやOfficeを最新にバージョンアップしてしまった後では、当時よりも大幅に性能の良いパソコンが必要になってしまうのだ。
※といっても当時のOfficeの文書はフロッピーディスクという現在ではパソコンに搭載されることが極めて少なくなったメディアに入っているに違いない。MOもしかり。
だから、ずーっと同じOSやアプリを何十年も使っていると、諸々の要因で追加や変更が加わり、ごった煮になり、互換性のテストしなければいけない項目は増える一方!OSもアプリも保守が大変になるから、コストパフォーマンスはどんどん悪くなり、製品単価は下がるどころか、上がり始めるのだ。
ソフトウェアだから改造は容易だろう?と云う人もいるだろう。
例えば、ピラミッドの頂上にもう1個石を上乗せするのは大変だができない訳では無い。だが、後1個!後1個!・・・と云って無理を通せば、最後には誰がやっても出来ない特異点(無理っぽ)に到達するのは想像できるだろう。
いやソフトウェアだから永遠に積み上げられるという人もいるかもしれない。しかし、画面からはみ出した部分は観えなくなる。縮尺を縮じめてしまうと、さっぱり状況がわからない。今の高さをmで吹き出し表示させても、いつかは吹き出しが画面の横幅を越えてしまうので、どんな方法でも限界はあるし、新しい方法を生み出すには、ソフトウェア・デザインの大改造が必要で、その費用は誰が払うの?という最終問題が発生する。
ありていにいえば、しっかりと将来性や拡張性を見据えたものでも、見えてないデッドスペースが多いってだけであり、やはり最後には、特異点(無理っぽ)に到達するだ。
もっとはっきり云えば、無理を云う貴方の後ろにも、無理を云う別の貴方がいて、さらにその後ろにも・・・と、世の中は無理を云う貴方の行列は永遠に続くのだから、きりがないのだ。
IPv4のアドレスが枯渇するは先見性が足りなかったのではない。ただただ無理を通した結果なのだ。IPv6もIoTが好調に進み、地球上全ての温暖化マップを作成するための気温やCO2分圧の測定IoTを大量に散布するプロジェクトとか、血糖値などの測定用使い捨てのIoTなどで大量に消費されたりするなどの事態がいくども起きれば、経済は潤うが、無尽蔵に思えたIPアドレスが枯渇するのもそう遠い話ではないので、有限数のIPアドレス中継から無限数のドメイン中継に変わるのも時間の問題だろう。
ハードウェアのコストパフォーマンスが良くなる時期は見た目のコストパフォーマンスは改善されるが、WindowsやOfficeは保守が大変なのでハードウェアとは無関係にコストパフォーマンスは悪化する。
ハードウェアのコストパフォーマンスが良くならない時期(サブプライムローン破綻とか、今現在の円安とか・・・)は見た目のコストパフォーマンスは悪化し、更にWindowsやOfficeは保守が大変でコストパフォーマンスは同様に悪化する。
結局、WindowsやOfficeも無理が祟っているのが現状と云えるのではないだろうか?
そろそろ、WindowsやOfficeも捨ててしまった方が、全体としてのコストパフォーマンスは上昇するような気がする。
しかし、無理が祟っている様な状況だからこそ、WindowsやOfficeの競合らしいモノが実質的に無いのであって、全体としてのコストパフォーマンスは上昇するような気がする状況になれば、競合であふれかえる可能性が高い。
そして、それはユーザも同じこと。扱いに困るWindowsやOfficeだからこそ仕事になっているのだ。これが全体としてのコストパフォーマンスは上昇するような気がする状況になれば、こっちも競合であふれかえる可能性が高い。

憎まれっ子、世にはばかる。

は、意味深いコトワザなのである。
おまけに、最新のWindowsもOfficeも新しいUIはいづれも不評だ。
滅多に見ないバージョン表記なぞドコかに埋めておけばいいと思っているのか?最近のOfficeでバージョン表記を探すことすら大変だからだ。
Office 365で自動的に最新バージョンOfficeが使えることが1つの目玉であるが、その最新バージョンでは最初に「バージョン表記を探すクエストを請けなくてはいけない!2度目、3度目になれば苦痛になりそうだ。
今のバージョンではEXCELのシートに貼った図形をドラッグ選択したいと思った途端!

  1. ツールバーの左端のタグに切り替え、
  2. ツールバーの右端にある「検索」のプルダウンメニューを開き
  3. 下から2番目図形を選択するモードにチェックを入れなければいけない。

そして、また図形を追加するのは

  1. ツールバーの左端から2番目の挿入のタグに切り替え、
  2. ツールバーの「図形」をクリックして追加する図形(矩形とか吹き出しとか矢印)を選択しないといけない。
  3. 続けて追加するときにクリックを1回でも減らしたいなら、左端に図形が列挙されているので、目線を画面の左端と右端を高速で移動しなくてはいけない。

ので、結構メンドクサイUIなってしまっている。
次バージョンではどんな操作になるのだろうか?
もっとメンドクサイ仕様になっている気がする。
MMORPGを毎日プレイしていると、そのうちアップデートなんて仕様が変わるだけで、また覚え直すのが億劫になってくるが、やはりWindowsやOfficeでも同様である。
FFは遊びではないと云う人もいる。
仕事で使うWindowsやOfficeならなおさら。
嫌々付き合っていくしかないらしい。
本当に

憎まれっ子、世にはばかる。

は、意味深いコトワザなのである。
 
そんなことはない!新しいアップデートに挑戦することは楽しい!
確かにそうだろう。でも、楽しいのは3度目までだと思うよ。4度目には大抵の人はもう飽き飽きしているよ!
何でこの職場では4つのOfficeのバージョンの操作を即答しないといけないんだと!
そしてそれは、質問してくる奴が使っているOfficeのバージョンの探し方すら見当もつかないせいなのだ!と気が付くのである。
だから、最新バージョンでは最初に「バージョン表記」を探すクエストを請けなくてはいけない!のである。



19,800円

やっぱり売れスジっぽい値段。

  1. ECS LIVA
  2. DosPara Diginnos DG-D08IWB
  3. Mouse Computer  m-Stickシリーズ MS-NH1 19800円(税込)

 
1のLIVAはOSなし。
2のDG-Q10SR2はAndroidなので、DG-D08IWB
3のMS-NH1はUSBポートが1個しかない。
 
と、それぞれ使いにくさはあるけど、一応安いので売れてそうだ。
1は据え置きなら一番使いやすく、デュアルモニターでUSB3に外付けSSDを増設とか色々できる。nucが飛んだら買い替えようかな。
2はタブレットなので一式揃っている。鞄に入れておけばドコでも艦コレできる。但しeMMCが16GBなので、マイクロSDカードを増設しないやばいし、唯一ネットで買うと送料がかかる。
3は災害時の非常用PCとして鞄の奥に忍ばせておくと良さそうだ。
※19,800円(税込)と18500円(税別)とか、各店舗で表記がバラバラなのでよく判りません。(笑



WindowsPCの共有フォルダをLinuxで借りる方法

Androidのソースが大きすぎるのでWindowsPCのHDDを間借りすることにした。
# yum -y install cifs-utils
インストール:
cifs-utils.x86_64 0:6.2-6.el7
依存性関連をインストールしました:
libldb.x86_64 0:1.1.16-4.el7             libtalloc.x86_64 0:2.0.8-4.el7
libtdb.x86_64 0:1.2.12-3.el7             libtevent.x86_64 0:0.9.18-6.el7
libwbclient.x86_64 0:4.1.1-37.el7_0      pytalloc.x86_64 0:2.0.8-4.el7
samba-libs.x86_64 0:4.1.1-37.el7_0
完了しました!
# mkdir   /フォルダ
WindowsPC側で
共有するためのアカウントと共有フォルダを作る

アカウントは何でもいいが、パスワードを付けないとWindowsUpdateを全くやっていない一部のXP以外はネットワーク接続ができない。

共有するフォルダのプロパティで【共有】タグで【共有】ボタンを押し、先のアカウントで読み書きできるようにする。

# mount -t cifs -o user=ユーザ,password=パスワード //WindowsPCのIPアドレス/共有フォルダ   /フォルダ
#
何も出ないけど使える。
自動接続する場合は
echo //WindowsPCのIPアドレス/共有フォルダ /フォルダ cifs user=ユーザ,password=パスワード,defaults 0 0 >> /etc/fstab
でいいらしい。
しかしandroidのソースをコピーしてみると
cp: シンボリックリンク `/フォルダ/android-x86/ndk/sources/cxx-stl/llvm-libc++/libcxx/test/strings/basic.string/string.nonmembers/string_opgtEQ’ を作成できません: サ ポートされていない操作です
と出てきた。シンボリックリンク は使えないらしい。
もちろん repo init すら通らない。
Get http://git.android-x86.org/manifest
Traceback (most recent call last):
File “/フォルダ/android-x86/.repo/repo/main.py”, line 500, in <module>
_Main(sys.argv[1:])
File “/フォルダ/android-x86/.repo/repo/main.py”, line 476, in _Main
result = repo._Run(argv) or 0
File “/フォルダ/android-x86/.repo/repo/main.py”, line 155, in _Run
result = cmd.Execute(copts, cargs)
File “/フォルダ/android-x86/.repo/repo/subcmds/init.py”, line 390, in Execute
self._SyncManifest(opt)
File “/フォルダ/android-x86/.repo/repo/subcmds/init.py”, line 163, in _SyncManifest
m._InitGitDir(mirror_git=mirrored_manifest_git)
File “/フォルダ/android-x86/.repo/repo/project.py”, line 2076, in _InitGitDir
self._UpdateHooks()
File “/フォルダ/android-x86/.repo/repo/project.py”, line 2098, in _UpdateHooks
self._InitHooks()
File “/フォルダ/android-x86/.repo/repo/project.py”, line 2126, in _InitHooks
os.symlink(os.path.relpath(stock_hook, os.path.dirname(dst)), dst)
OSError: [Errno 95] Operation not supported
とは云え
# df -H
ファイルシス              サイズ  使用  残り 使用% マウント位置
/dev/mapper/centos-root      41G   22G   19G   55% /
devtmpfs                    1.7G     0  1.7G    0% /dev
tmpfs                       1.8G     0  1.8G    0% /dev/shm
tmpfs                       1.8G  9.0M  1.7G    1% /run
tmpfs                       1.8G     0  1.8G    0% /sys/fs/cgroup
/dev/sda2                   521M  168M  354M   33% /boot
/dev/sda1                   210M   10M  200M    5% /boot/efi
/dev/mapper/centos-home      20G   34M   20G    1% /home
/dev/sdb1                    63G   21G   39G   35% /usbSSD
//WindowsPCのIPアドレス/共有フォルダ  3.1T  537G  2.5T   18% /フォルダ
3.1Tは魅力的なサイズだ。(大笑
http://thinkit.co.jp/free/tech/26/4/1.html などを見てダミーファイルを作ろうとしたが
# dd if=/dev/zero of=/フォルダ/ext3.img bs=1G count=1 seek=128
何時まで経っても終わらないので・・・
dd のseek オプションで一瞬で大きなファイルを作るを参考に
128GB=128 × 1024 (MB) × 1024 (KB) × 1024 (B)=137438953472 だから
# dd   if=/dev/zero   of=/フォルダ/ext3.img  seek=137438953472   bs=1   count=1
1+0 レコード入力
1+0 レコード出力
1 バイト (1 B) コピーされました、 0.00187216 秒、 0.5 kB/秒
で、サクっとエリアを借り、フォーマット
# mkefs -t ext4  /フォルダ/ext3.img
ke2fs 1.42.9 (28-Dec-2013)
/フォルダ/ext3.img is not a block special device.
Proceed anyway? (y,n) y
Filesystem label=
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
Stride=0 blocks, Stripe width=0 blocks
8388608 inodes, 33554432 blocks
1677721 blocks (5.00%) reserved for the super user
First data block=0
Maximum filesystem blocks=2181038080
1024 block groups
32768 blocks per group, 32768 fragments per group
8192 inodes per group
Superblock backups stored on blocks:
32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208,
4096000, 7962624, 11239424, 20480000, 23887872
Allocating group tables: done
Writing inode tables: done
Creating journal (32768 blocks): [ENTER]done
Writing superblocks and filesystem accounting information:
長い。タスクマネージャで調子を見ていたらHDDの起動音が・・・ディスクが止まっていたらしい。すぐに
done
メモリが24GBなのでキャシュしていたのかな?
ま、他にも何かあるのかもしれない。
適当にマウントしてみると
# df -h
ファイルシス              サイズ  使用  残り 使用% マウント位置
・・・
//WindowsPCのIPアドレス/共有フォルダ   2.8T  756G  2.0T   28% /フォルダ
/dev/loop0                  126G   61M  120G    1% /ext3.imgをマウントしたフォルダ
とりあえずコレでシンボリックリンクも貼り放題。
巨大なファイル(qemuのイメージファイルとか)のコピーをWindowsのタクスマネージャで見てみると、瞬間最大で100MB/秒強(LANが1Gbpsなので上限値)とか、USB2でSSDにつなぐより速いのでrepoのダウンロードも短くて済みそうだが、nucのCPUファンが唸りっぱなしになった。
 
いつも使う訳ではないのでスクリプトで切り替える様にする
ssdmount.sh

 # WindowsPCのIPアドレス
WINPC_IP_ADDRESS=192.168.*.*
# WindowsPCの共有フォルダ
WIN_SHARE_FOLDER=共有フォルダ名
# WindowsPCのアカウント
WIN_ACC=user=ユーザ名,password=パスワード
# 共有フォルダのマウント先
WINPC_SHARE_MOUNT_POINT=マウントするフォルダ名
# WindowsPCの共有フォルダにあるext4イメージファイル
EXT_IMG=${WINPC_SHARE_MOUNT_POINT}/イメージファイル名
# ext4イメージファイルのマウント先
EXT4_MOUNT_POINT=イメージファイルをマウントするフォルダ名
#
if [ “$1” == “-u” ]; then
    echo  umount  mode
    mount  |  grep  “on ${EXT4_MOUNT_POINT}”
    mount  |  grep  “on ${WINPC_SHARE_MOUNT_POINT}”
    #EXT4イメージをアンマウント
    umount  ${EXT4_MOUNT_POINT}
    #共有フォルダをアンマウント
    umount  ${WINPC_SHARE_MOUNT_POINT}
elif [ “$1” == “-m” ]; then
    echo  mount  mode
    #共有フォルダをマウントするフォルダを作る
    if [ ! -e ${WINPC_SHARE_MOUNT_POINT} ]; then
        echo  make ${WINPC_SHARE_MOUNT_POINT}
        mkdir  ${WINPC_SHARE_MOUNT_POINT}
        chmod  0777  ${WINPC_SHARE_MOUNT_POINT}
    fi
    #EXT4イメージファイルをマウントするフォルダを作る
    if [ ! -e ${EXT4_MOUNT_POINT} ]; then
        echo  make ${EXT4_MOUNT_POINT}
        mkdir  ${EXT4_MOUNT_POINT}
        chmod  0777  ${EXT4_MOUNT_POINT}
    fi
    #共有フォルダをマウント
    mount -t cifs -o ${WIN_ACC}    //${WINPC_IP_ADDRESS}/${WIN_SHARE_FOLDER}    ${WINPC_SHARE_MOUNT_POINT}
    #EXT4イメージをマウント
    if [ -e ${EXT_IMG} ]; then
        mount   ${EXT_IMG}    ${EXT4_MOUNT_POINT}
    fi
    mount  |  grep  “on ${EXT4_MOUNT_POINT}”
    mount  |  grep  “on ${WINPC_SHARE_MOUNT_POINT}”
else
    echo unknown mode [$1].
    echo option -m or -u.
fi

いつも思うけど、手打ちしたものをシェルスクリプトにしてしまうと長くなるなぁ~
しかし、WindowsPC側にEXT4イメージファイルを配置してnucから使うのはトリッキーではあるけれど・・・
チョット使ってみたいのでKVMゲストをWindowsPCに作るには便利だ。
バックアップも取りやすい。
Windows10のプレビュー版もモサモサと動く(サクサクではない
 
参考 : http://ry.tl/mount.html



マウスコンピュータ  スティック型PC 「m-Stickシリーズ MS-NH1」

安くて気軽に買える。
小さくて置き場所に困らない。
サイズはChromecastぐらい。
eMMC(32GB)なのでCentOS7はインストできないがUbuntuなら大丈夫だろう。
WifiとBluetoothは付いている。
LIVAとの違いは、LIVAにはUSB3ポートと有線LANポートがあるけど、micro SDメモリースロットはない。
ブログ鯖にするなら、やはりLIVAのUSB3にSSDを繋いだ方が良さそう。
どっちも心配なのは24時間稼働(繋ぎっぱなし)で過熱しないかどうか?
ま、スペックをみるかぎり Windows 8.1 with Bing 付きらしいので、最安値。
中古のパソコンでいいんだけど?と云う人に進めてみるかな?
でも、HDMI出力しかなので、格安のアナログRGB入力のモニタに金物の変換アダプタを繋いでも映らない。
HDMI to VGA adapter ブラック / HDMI信号をVGA出力信号に変換するアダプターのようにRaspberry-Piでも使えると評価されたものを探すといいだろう。安い(今、880円)
注意点としてはUSBが1口なのでBluetoothのキーボードやマウスを使いたいが、最初にデバイスを認証させるために有線のキーボードとマウスを接続しておかないといけない。
無線アダプタ1個でキーボードとマウスを繋ぐ Logicool のMK270 (2~3千円前後)も買っておいた方がいいだろう。アダプタ自体にキーボードとマウスの認証情報が書き込まれるので、他のPCにアダプタを挿すとすぐ使えるので据え置きしてるノートPCにも使え重宝する一品。
 



Android-x86 を ビルド  ・・・ing

参考: http://www.android-x86.org/getsourcecode
curl http://commondatastorage.googleapis.com/git-repo-downloads/repo > ~/bin/repo
chmod a+x ~/bin/repo
$ branch=lollipop-x86
$ mkdir android-x86
$ cd android-x86
$ repo init -u http://git.android-x86.org/manifest -b $branch
$ repo sync
error: prebuilts/gcc/darwin-x86/aarch64/aarch64-linux-android-4.9/: platform/prebuilts/gcc/darwin-x86/aarch64/aarch64-linux-android-4.9 checkout 5dbc43c533f23bc0a566eb5b91a0f1ba5dbc9189
# df -H
ファイルシス            サイズ  使用  残り 使用% マウント位置
・・・
/dev/sdb1                  63G   60G     0  100% /usbSSD
仕方がないので移動。
# make iso_img TARGET_PRODUCT=android_x86
============================================
PLATFORM_VERSION_CODENAME=REL
PLATFORM_VERSION=5.0
TARGET_PRODUCT=android_x86
TARGET_BUILD_VARIANT=eng
TARGET_BUILD_TYPE=release
TARGET_BUILD_APPS=
TARGET_ARCH=x86
TARGET_ARCH_VARIANT=x86
TARGET_CPU_VARIANT=
TARGET_2ND_ARCH=
TARGET_2ND_ARCH_VARIANT=
TARGET_2ND_CPU_VARIANT=
HOST_ARCH=x86_64
HOST_OS=linux
HOST_OS_EXTRA=Linux-3.10.0-123.9.3.el7.x86_64-x86_64-with-centos-7.0.1406-Core
HOST_BUILD_TYPE=release
BUILD_ID=LRX21V
OUT_DIR=out
============================================
Checking build tools versions...
including ./abi/cpp/Android.mk ...
including ./art/Android.mk ...
・・・
オリジナルのソースはこっち、ブランチ名はこっち
repo init -u https://android.googlesource.com/platform/manifest


Hyper-VにAndroidX86を入れてみる

公式のAndroid-X86は純粋に32ビットバージョンなので、
64ビットのWin8のHyper-Vでは起動してもディスクを認識できない。
64ビットで試しに作ったらしいモノも見かけたがLANは繋がらなかった。
※https://code.google.com/p/android-x86/downloads/listのandroid-x86-4.3-20130725.iso
更に、Hyper-Vなのでホスト側のUSBなどを接続する方法も存在しない。
 




top