IPLIST UPDATE というタイトルがいっぱい詰まっていた。
アップデートがいっぱいあると来るらしい。
手動で
# ./iptables.sh ← 元ネタはこちら。
その後は来なくなった。
この画面は、簡易表示です
IPLIST UPDATE というタイトルがいっぱい詰まっていた。
アップデートがいっぱいあると来るらしい。
手動で
# ./iptables.sh ← 元ネタはこちら。
その後は来なくなった。
と云えば何の役にも立たないこのブログのこと。
捨てるなら、電源を切るだけでいい。
しかし中には使ってないパッケージが結構残っているらしい。
yum-utilsを入れておけば、要らないパッケージをリストアップしてくれるコマンドが使えるらしい。
# package-cleanup –leaves
読み込んだプラグイン:fastestmirror, langpacks, priorities
NetworkManager-glib-1.0.0-14.git20150121.b4ea599c.el7.x86_64
giflib-4.1.6-9.el7.x86_64
libXrender-0.9.8-2.1.el7.x86_64
libXtst-1.2.2-2.1.el7.x86_64
libertas-sd8686-firmware-20140804-0.1.git6bce2b0.el7_0.noarch
libertas-sd8787-firmware-20140804-0.1.git6bce2b0.el7_0.noarch
libertas-usb8388-firmware-20140804-0.1.git6bce2b0.el7_0.noarch
libreport-plugin-logger-2.1.11-23.el7.centos.0.1.x86_64
libreport-plugin-mailx-2.1.11-23.el7.centos.0.1.x86_64
libreport-plugin-rhtsupport-2.1.11-23.el7.centos.0.1.x86_64
libreport-rhel-2.1.11-23.el7.centos.0.1.x86_64
libsysfs-2.1.0-16.el7.x86_64
libtool-2.4.2-20.el7.x86_64
リストアップされたパッケージをどんどん消していく、
# package-cleanup –leaves
読み込んだプラグイン:fastestmirror, langpacks, priorities
libSM-1.2.1-7.el7.x86_64
libXi-1.7.2-2.1.el7.x86_64
libtar-1.2.11-28.el7.x86_64
リストアップされたパッケージをどんどん消していく、
# package-cleanup –leaves
読み込んだプラグイン:fastestmirror, langpacks, priorities
libICE-1.0.8-7.el7.x86_64
libXext-1.3.2-2.1.el7.x86_64
リストアップされたパッケージをどんどん消していく、
# package-cleanup –leaves
読み込んだプラグイン:fastestmirror, langpacks, priorities
もう無いらしい。
# yum list | wc
9103 26836 733650
それでも9103もパッケージが入っている。
何か消し過ぎたら、明日にはボロボロとメールが飛んでくるだろう。
# df -h ファイルシス サイズ 使用 残り 使用% マウント位置 /dev/mapper/centos-root 18G 5.3G 13G 31% / devtmpfs 1.4G 0 1.4G 0% /dev tmpfs 1.5G 0 1.5G 0% /dev/shm tmpfs 1.5G 8.4M 1.4G 1% /run tmpfs 1.5G 0 1.5G 0% /sys/fs/cgroup /dev/vda1 497M 270M 227M 55% /boot
古いカーネルも消してみる
# package-cleanup –oldkernels
読み込んだプラグイン:fastestmirror, langpacks, priorities
–> トランザクションの確認を実行しています。
—> パッケージ kernel.x86_64 0:3.10.0-123.13.2.el7 を 削除
—> パッケージ kernel.x86_64 0:3.10.0-123.20.1.el7 を 削除
—> パッケージ kernel.x86_64 0:3.10.0-229.1.2.el7 を 削除
—> パッケージ kernel-devel.x86_64 0:3.10.0-229.1.2.el7 を 削除
–> 依存性解決を終了しました。
依存性を解決しました
================================================================================
Package アーキテクチャー
バージョン リポジトリー 容量
================================================================================
削除中:
kernel x86_64 3.10.0-123.13.2.el7 @updates 127 M
kernel x86_64 3.10.0-123.20.1.el7 @updates 127 M
kernel x86_64 3.10.0-229.1.2.el7 @updates 131 M
kernel-devel x86_64 3.10.0-229.1.2.el7 @updates 32 M
トランザクションの要約
================================================================================
削除 4 パッケージ
インストール容量: 416 M
上記の処理を行います。よろしいでしょうか? [y/N]y
Downloading packages:
Running transaction check
Running transaction test
Transaction test succeeded
Running transaction
削除中 : kernel.x86_64 1/4
警告: ファイル /lib/modules/3.10.0-123.20.1.el7.x86_64/weak-updates: 削除に失敗 しました: そのようなファイルやディレクトリはありません
警告: ファイル /lib/modules/3.10.0-123.20.1.el7.x86_64/modules.softdep: 削除に失敗しました: そのようなファイルやディレクトリはありません
警告: ファイル /lib/modules/3.10.0-123.20.1.el7.x86_64/modules.devname: 削除に失敗しました: そのようなファイルやディレクトリはありません
削除中 : kernel-devel-3.10.0-229.1.2.el7.x86_64 2/4
削除中 : kernel.x86_64 3/4
警告: ファイル /lib/modules/3.10.0-229.1.2.el7.x86_64/weak-updates: 削除に失敗しました: そのようなファイルやディレクトリはありません
警告: ファイル /lib/modules/3.10.0-229.1.2.el7.x86_64/modules.softdep: 削除に失 敗しました: そのようなファイルやディレクトリはありません
警告: ファイル /lib/modules/3.10.0-229.1.2.el7.x86_64/modules.devname: 削除に失 敗しました: そのようなファイルやディレクトリはありません
削除中 : kernel.x86_64 4/4
警告: ファイル /lib/modules/3.10.0-123.13.2.el7.x86_64/weak-updates: 削除に失敗 しました: そのようなファイルやディレクトリはありません
警告: ファイル /lib/modules/3.10.0-123.13.2.el7.x86_64/modules.softdep: 削除に失敗しました: そのようなファイルやディレクトリはありません
警告: ファイル /lib/modules/3.10.0-123.13.2.el7.x86_64/modules.devname: 削除に失敗しました: そのようなファイルやディレクトリはありません
検証中 : kernel-3.10.0-123.13.2.el7.x86_64 1/4
検証中 : kernel-3.10.0-229.1.2.el7.x86_64 2/4
検証中 : kernel-devel-3.10.0-229.1.2.el7.x86_64 3/4
検証中 : kernel-3.10.0-123.20.1.el7.x86_64 4/4
削除しました:
kernel.x86_64 0:3.10.0-123.13.2.el7 kernel.x86_64 0:3.10.0-123.20.1.el7
kernel.x86_64 0:3.10.0-229.1.2.el7 kernel-devel.x86_64 0:3.10.0-229.1.2.el7
完了しました! # df -h ファイルシス サイズ 使用 残り 使用% マウント位置 /dev/mapper/centos-root 18G 5.0G 13G 29% / devtmpfs 1.4G 0 1.4G 0% /dev tmpfs 1.5G 0 1.5G 0% /dev/shm tmpfs 1.5G 8.4M 1.4G 1% /run tmpfs 1.5G 0 1.5G 0% /sys/fs/cgroup /dev/vda1 497M 150M 348M 31% /boot ←120MBぐらい減ったらしい。
reboot してもpanicメッセージは飛んでこなかったので大丈夫だったようだ。
ホストの方も試してみたら
# package-cleanup –leaves
読み込んだプラグイン:fastestmirror
libsysfs-2.1.0-16.el7.x86_64
libvirt-1.2.8-16.el7_1.3.x86_64
これはちょっと消しにくいなぁ(笑
# package-cleanup –oldkernels
読み込んだプラグイン:fastestmirror
No old kernels to remove
作り直したばかりだからそうかもしれない。
でも
# yum list | wc
8881 26163 715718
それなりに多い。
Windowsタッチ付きのBluetoothマウス。
Windowsタッチを押し込むとWindowsキーと同じ操作。
Windowsボタンを上に向かってスワイプすると画面を順送りする。
Windowsボタンを下に向かってスワイプすると画面左に使用中のアプリをリストアップする。
最初はただのボタンだと思い、Windows印を押しこんで上に向かってスワイプしてしまった。
親指で押し込んではいけない。
親指でわずかに触れるぐらいでスワイプしなければいけない。
ちゃんとスワイプできると、マウスが振動する。
重量は136gで、 Logicoolの小さいM185マウスの75gより重い。
MS-ACCESSを使っているとフィールド名などを [フィールド名] と しがちだ。
ほとんど問題にならないが、
VB6から
DAOの2.5/3.51 COmpatibility Library(dao2535.tlb)を参照指定しておけばスルーしてくれるけど
かなり古いMDBしかまともに読み書きできないので、
DAO3.6 Object Library(dao360.dll) に変える多少マシだが・・・
fields(“[フィールド名] “) と書いてある部分は
[フィールド] なんてフィールドは無いのでヌルポになる。
よく、rst.fields(“[フィールド名] “)=”00000” などとやっつけな感じで書くので、
本気でヌルポに”00000”を代入してと VB6がdao360.dllに要求するから、
真面目なエラーメッセージは
dao360.dllの中でヌルポっぽいと表示され、
エラー内容を送信しますか?と、確認までされてしまう。
VB6なのに・・・orz
かなり前のことだけど、
原子力発電はCO2を発生しないので環境に優しい
と宣伝されていた時期があった。
今となってはギャク未満でしかない。
しかし、環境に優しくエコなエネルギーとされるものにも色々落とし穴がある。
例えば、
石油などの化石燃料ばかりに頼らず、穀物からメタノールなど燃料を取り出そうという風潮が出たら、食料が値上がりしたり買占めで食料が買えないなど大変な出来事が起きたが、一時期より石油の価格が下落し採算性が悪くなったのか事業から撤退するトコロもあるようだ。
ソーラーパネルも電力の買取価格が下がっていて、これも大規模な事業をしている企業にとっては大変なことだろう。
それよりは水から水素を作るのはマシな気はするけれど、これも水不足が続く地域ではどう云うことになるのだろう。
何かと目の敵にされているCO2からディーゼル燃料を作るeディーゼルにしても、大気中のCO2濃度が0になるまで吸収してしまうと危ない様だし・・・
な感じで、結局、何をやってもトラブルは起きるらしい。
エコなものは安心
と慢心してはいけない
ということだけは確かな様だ。
原子力発電にしても、ちゃんと運用できれば、そう危険ではないのかもしれない。
でも、ちゃんと運用できそうもないなら・・・使わない方がよさそうだ。
しかし、エコなエネルギーの方がマシだと無頓着にエコエコしても
ちゃんと運用できなければ・・・・やっぱり危ないことに変わりはない。
ずーっとこのまま続れば・・・電力料金上がりっぱなし!
停止している原子力発電に目を付けても、いざ運用してみれば安全対策とか燃料の値上がりとか色々な要因が重なり、ダラダラと電力料金は上がりっぱなし!使った方が高くついてしまった!なんてことになりかねない。
そう、沢山の手段を持ち、色々と手段を取り替えても、すぐに採算が取れなくなる器用貧乏症では堂々巡りするだけでどうしようもない。
化石燃料の石油も最初は明かりや暖房の燃料する以外にはほとんど使い道が見つからずゴミ同然だっただろう。しかしこのゴミを利用するエコな内燃機関ができあがったり化学繊維やプラスチックの原料として使われ出すと、当初は価格も安く都合が良かったが、長らく使っているうちに【必須アイテム】となり、手放せなくなってしまうと、もうゴミではなく戦略物資の1つになってしまったのかもしれない。
電力も当初は燃料タンクに燃料を継ぎ足さなくても使える便利な照明や電力源として都合が良かったが、長らく使っているうちに【必須アイテム】となり手放せなくなった。
今では、色々な【必須アイテム】があり、どれも手放せなくなり、どうしたらいいのか判らない。
というところが一番痛いところなのかな?
※RTMのリリースが間近になり、プレビュー版の提供は停止中らしい。
qemuのlahf_lm の設定を有効にすると、KVMでWindows10が動くらしい。
「Load AH from Flags (LAHF) and Store AH into Flags (SAHF) in long mode」の略で、AMDの64ビット命令のLAHF、SAHFが、古いINTELのCPUの64ビット命令(EM64T)には無かったが後にEM64Tに追加されたので、これらの命令の実装の有無を区別するためのフラグらしい。多分、INTELのARKのページでVT-xがYESになっているCPUなら良いのだろう。
なぜVM用の命令が必要なのかは不明だが、インストール時に必要なら、中でHyper-Vが使えるハズなので、古いWindowsの環境のHDDが残っていれば、うっかりバックアップを忘れたメーラーのデータ(大抵はトンデモナイところに保存されているので中々見つからない)などをコピーできるハズなので、大助かりのハズだ。
/etc/libvirt/qemu/****.xml に
<cpu mode='custom' match='exact'>
<model fallback='allow'>kvm64</model>
<feature policy='require' name='lahf_lm'/>
</cpu>
と追加されればなんとかなるらしい。
qemu のコマンドラインなら
-cpu kvm64,+lahf_lm
とすればいいらしい。
が、Windowsのインストール直後に【困った顔】が出たゲストの設定にコレを付けても、ブートローダすらインストされていないから無理だろう。virsh undefineしディスクイメージも消して再インストールするしかない。
で、virt-installの設定に
–cpu kvm64,+lahf_lm
を付け足してやると/etc/libvirt/qemu/*****.xmlに
<cpu mode='custom' match='exact'> <model fallback='allow'>kvm64</model> <feature policy='force' name='lahf_lm'/> </cpu>
な風に設定される。
とりあえず困った顔のマークは出なくなった。
Thanks!
※SPICEのport指定するとTLS接続の扱いになってしまうので今回は外しました。
代わりにコマンドを打って確認。
# virsh dumpxml VMゲスト名 | grep spice|grep port
<graphics type=’spice’ port=’5900‘ autoport=’yes’ listen=’0.0.0.0′>
この例では5900に設定されている。
※ディスク20GBではインストールが終わらない?みたいなので32GBに変更した
※virt-topではCPU40%だが、普通のtopでは123%。J1900のCPU1コアでは無理っぽい。
※ディスクを増やしても–vcpus=1では「お待ちください…」がさっぱり進まないので2に変えるとインストールが進むようになった。
ブログ鯖で egrep model /proc/cpuinfo を観るとmodelが13だったので、ホストと同じCPUを指定すると
<vcpu placement='static'>1</vcpu>の後に<cpu mode='host-passthrough'/>
を付ける# egrep model /proc/cpuinfo
model : 55
model name : Intel(R) Celeron(R) CPU J1900 @ 1.99GHz
に変わったので、
–cpu host-passthrough,+lahf_lm \
にしてみた。
多少効果はあるかもしれない。
というか、
–cpu host-passthrough \
にしておけばlahf_lmも自動的に有効なのかな?manコマンドにこれらオプションの記載は無く、オプションの書き方だけが書いてあるのでネット情報が全てな様だ。kvmもlibvirtもqemuなどのパッケージを口当たりが良い様にまとめたフロントエンドでしかないのかな?いつのまにかヘルプや参照先に載っている情報が古く(Core2Duo全盛期)なってしまった様だ。-lahf_lm的な記載もその当時の状況を反映したものなのだろう。よく安定して動作するものだなぁ~と感心しつつ、LinuxのパッケージもWindowsっぽくなっていくんだな・・・とも思えた。
※でもWindowsのCPU表示にはちゃんとJ1900と表示された。
※調整したもののWindows 10のインストールの「簡易設定」の「お待ちください…」は長いまま。
やっと
「こんにちは」が出てきた。
そして
「しばらくお待ちください」
しばらくが付いた!
「最後の処理をしています」
ほ、本当か?
「PCの電源を切らないでください」
待つしかない・・・
「あと少しです」
待つしかない・・・
「通常より時間がかかっていますが、まもなく準備を完了します」
SPICEクライアントの設定ミスか?ちょっと文字が裏返って表示されたり変な感じ。
待つしかない・・・
「さぁ始めましょう」
MRTGをみてみると
J1900のコアが50℃まで上がってた。
インスト中はCPU負荷がほぼ100%。
通信量は最大で320KB/秒と並。br0の限界?
このせいで「お待ちください…」が長かったのかもしれない。
とりあえずJ1900にはお疲れ様。
やっと窓から光が・・・
インストの後、暫くすると46℃まで下がった。
Windows自体のCPU負荷はそう大きく無いようだ。
とは云え、J1900にKVMのホストさせゲストにWindowsを入れSPICEクライアントで覗いているんだから・・・
なのは仕方が無い。
やはりJ1900にはブログ鯖が限界のようだ。
Windows 10のインストールはCPUのパワーが結構必要らしく、virt-installのパラメータをちゃんと調整しないとインストすらまともにできない様だ。
KVMゲストでもVT-xを使える設定になったハズなので・・・
しかしHyper-Vが見当たらない。
Windows8.xでは【プログラムと機能】⇒【Windowsの機能の有効化または無効化】の中にあったんだけど、
【Windowsの機能の有効化または無効化】すら見つからない。
探し方が悪いのかな?
ただでさえパワー不足でUI操作がモタついている状況なのに、KVMの中でHyper-Vするつもりはないけどね。
それとも
のだろうか?
ps.
アップデートを入れたらBuild 10162の表示が消えた。
ここ最近のゲームのCMでよく目にするのは【進化】と云う言葉、バージョンアップのことなのかな?
以下インストールに成功したスクリプト。※赤い文字部分は要確認。
#ISOイメージのパス指定 ※qemuユーザのアクセス制限で/tmp以外に置くと読み込みに失敗する。
ISOIMG=/tmp/Windows10_InsiderPreview_x64_JA-JP_10162.iso
#KVM上での名前を指定 IMAGE_NAME=Win10ip # VIRTUAL DISK FILEPATH IMG_PATH=/var/lib/libvirt/images # USE MEMORY SIZE (MB) RAM=3096 # VIRTUAL DISK SIZE (GB) DISK=32 virt-install \ --name ${IMAGE_NAME} \ --ram ${RAM} \ --disk path=${IMG_PATH}/${IMAGE_NAME}.qcow2,size=${DISK},format=qcow2 \ --vcpus=2 \ --os-type windows \ --cpu host-passthrough,+lahf_lm \ --os-variant=win7 \ --network bridge=br0 \ --accelerate \ --graphics spice,listen=0.0.0.0 --channel spicevmc \ --video qxl \ --cdrom ${ISOIMG}
7/8/2015 Catalyst Software Suite Rev.15.7 For Windows 8.1 (64-bit)
Windows® 10 Support
Virtual Super Resolution (VSR)
Frame Rate Target Control™ (FRTC)
AMD FreeSync™ and AMD CrossFire™ Support
ファイナルファンタジーXIV: 蒼天のイシュガルド ベンチマーク
計測日時:2015/07/10 3:03:45
SCORE:5204
平均フレームレート:40.570
評価:とても快適
-とても快適な動作が見込めます。グラフィック設定をより高品質に設定しても、とても快適に動作すると思われます。
ローディングタイム:
シーン#1 3.082sec
シーン#2 14.807sec
シーン#3 6.118sec
シーン#4 5.800sec
シーン#5 5.245sec
シーン#6 3.124sec
合 計 38.178sec
DAT:s20150710030345.dat
画面サイズ: 1920×1200
スクリーンモード設定: 仮想フルスクリーンモード
DirectX バージョン: 11
グラフィック設定のプリセット: カスタム
描画設定
-水濡れ表現を有効にする: 有効
-オクルージョンカリングを有効にする(見えないものの描画を簡略化する): 無効
-LODを有効にする(遠影表示に簡易モデルを使用し描画負荷を軽減する): 無効
-リアルタイムリフレクション: 最高品質 (DirectX 11 でのみ有効)
-アンチエイリアス: FXAA
-ライティングの品質: 高品質
-細かい草の表示量: 最大表示
-背景の細かい凹凸表現: 高品質
-水面の凹凸表現: 高品質
影の表示設定
-自分: 表示する
-他人: 表示する
影の表現
-キャラクターの影のLODを有効にする: 無効
-影の解像度: 高解像度:2048ピクセル
-影の表示距離: 最長表示
-ソフトシャドウ: 強く
テクスチャ品質
-テクスチャフィルタ: 異方性
-テクスチャ異方性フィルタ: x16
揺れの表現
-自分: 適用する
-他人: 適用する
画面効果
-周辺減光を有効にする(画面の隅を自然に暗くする効果): 有効
-放射ブラーを有効にする(爆発などで周囲に向かって画面をぼかす効果): 有効
-SSAO(立体感を強調する効果): HBAO+:高品質 (DirectX 11 でのみ有効)
-グレア(光があふれる表現): 通常表現
カットシーン効果
-被写界深度表現を有効にする: 有効
システム環境:
Windows 8.1 Pro 64 ビット (6.2, ビルド 9200) (9600.winblue_r9.150322-1500)
Intel(R) Core(TM) i7-3770T CPU @ 2.50GHz
24520.961MB
AMD Radeon HD 7900 Series (VRAM 3051 MB) 8.17.0010.1395
このベンチマークは「ファイナルファンタジーXIV: 新生エオルゼア」Windows版及び「ファイナルファンタジーXIV: 蒼天のイシュガルド」Windows版の動作を保証する物ではありません。
ファイナルファンタジーXIV: 蒼天のイシュガルド 公式サイト http://jp.finalfantasyxiv.com/pr/
(C) 2010-2015 SQUARE ENIX CO., LTD. All Rights Reserved.
— SNSシェア用テキスト —
タイプ1
http://sqex.to/ffxiv_bench_jp #FF14 SCORE:5204 1920×1200 カスタム DX11 Intel(R) Core(TM) i7-3770T CPU @ 2.50GHz AMD Radeon HD 7900 Series
タイプ2
http://sqex.to/ffxiv_bench_jp #FF14 SCORE:5204 1920×1200 カスタム DirectX11 仮想フルスクリーンモード AMD Radeon HD 7900 Series
タイプ3
http://sqex.to/ffxiv_bench_jp #FF14 1920×1200 カスタム DirectX11 SCORE:5204 とても快適
タイプ4
http://sqex.to/ffxiv_bench_jp #FF14 1920×1200 カスタム DirectX11 仮想フルスクリーンモード SCORE:5204
長いタイプ
ファイナルファンタジーXIV: 蒼天のイシュガルド ベンチマーク
SCORE:5204 とても快適
1920×1200 カスタム DirectX11 仮想フルスクリーンモード
Intel(R) Core(TM) i7-3770T CPU @ 2.50GHz
AMD Radeon HD 7900 Series
http://sqex.to/ffxiv_bench_jp #FF14
# yum install cups
これは順調に進む。
インストール中 : lcms2-2.5-4.el7.x86_64 1/21
インストール中 : openjpeg-libs-1.5.1-10.el7.x86_64 2/21
インストール中 : poppler-data-0.4.6-3.el7.noarch 3/21
インストール中 : poppler-0.22.5-6.el7.x86_64 4/21
インストール中 : libfontenc-1.1.1-5.el7.x86_64 5/21
インストール中 : libXfont-1.4.7-2.el7_0.x86_64 6/21
インストール中 : 1:xorg-x11-font-utils-7.5-18.1.el7.x86_64 7/21
インストール中 : urw-fonts-2.4-16.el7.noarch 8/21
インストール中 : ghostscript-fonts-5.50-32.el7.noarch 9/21
インストール中 : poppler-utils-0.22.5-6.el7.x86_64 10/21
インストール中 : bc-1.06.95-13.el7.x86_64 11/21
インストール中 : avahi-glib-0.6.31-14.el7.x86_64 12/21
インストール中 : cups-filters-libs-1.0.35-15.el7_0.1.x86_64 13/21
インストール中 : qpdf-libs-5.0.1-3.el7.x86_64 14/21
インストール中 : 1:cups-client-1.6.3-17.el7_1.1.x86_64 15/21
インストール中 : libXt-1.1.4-6.1.el7.x86_64 16/21
インストール中 : ghostscript-9.07-18.el7.x86_64 17/21
インストール中 : 1:cups-filesystem-1.6.3-17.el7_1.1.noarch 18/21
インストール中 : cups-filters-1.0.35-15.el7_0.1.x86_64 19/21
インストール中 : 1:cups-1.6.3-17.el7_1.1.x86_64 20/21
インストール中 : ghostscript-cups-9.07-18.el7.x86_64 21/21
しかしモジュールが多い。
IP4200用のRPMもインストール
# yum localinstall cnijfilter-common-2.60-3.i386.rpm
–> 依存性解決を終了しました。
エラー: パッケージ: cnijfilter-common-2.60-3.i386 (/cnijfilter-common-2.60-3.i386)
要求: gtk+
エラー: パッケージ: cnijfilter-common-2.60-3.i386 (/cnijfilter-common-2.60-3.i386)
要求: libxml
というので
yumのリポジトリィにepelを追加
yum -y –enablerepo=epel install gtk+
http://rpm.pbone.net/でlibxmlを検索しlibxml-1.8.9-5.i386.rpmをダウンロード。
yum localinstall libxml-1.8.9-5.i386.rpm
# yum localinstall cnijfilter-common-2.60-3.i386.rpm
インストール中 : cnijfilter-common-2.60-3.i386 1/1
検証中 : cnijfilter-common-2.60-3.i386 1/1
インストール:
cnijfilter-common.i386 0:2.60-3
完了しました!
yum localinstall cnijfilter-ip4200-2.60-4.i386.rpm
要求: libglib-1.2.so.0
エラー: パッケージ: cnijfilter-ip4200-2.60-4.i386 (/cnijfilter-ip4200-2.60-4.i386)
要求: libgdk-1.2.so.0
エラー: パッケージ: cnijfilter-ip4200-2.60-4.i386 (/cnijfilter-ip4200-2.60-4.i386)
要求: libgmodule-1.2.so.0
エラー: パッケージ: cnijfilter-ip4200-2.60-4.i386 (/cnijfilter-ip4200-2.60-4.i386)
要求: libgtk-1.2.so.0
延々とネットを探すも無駄だったらしい。
ps.
ゴチャゴチャになったので、KVMホスト入れ直し。
プリンタは買い換えるか。
あからさまにウェラブル風で名前もそのまんまなSMART WATCH2。
すでに主流はSmartWatch 3なのだろうけどまだ使い続けている。
と云うのも、たまにタイマーを使うことがあるけど、主な利用は時計や通知ばかり、仕事中もお買い得品やゲームの通知が飛んでくるので、その度にフリックして画面を切替る。無くてもいいような有ってもいいような中途半端な使い方しかしていないが、一つだけ昔しながらの時計らしい使い方をしている。バッテリーの残容量の心配だ。何年も持つ電池ではなく自動巻式が多かった頃は時々腕時計が正しい時刻を示しているか確認していたが、今は後どれくらいバッテリーが残っているのか確認している。
バッテリーの心配をしなくなったら、また手に付けるのが面倒なダケのシロモノになってしまうかもしれない。
ただ、SmartWatch 3に変えたら声でメールの返信ができるので便利かな?と思うけど、スマフォと2つ持ちしないとダメなんだよね。
あと・・・Android Wear™アプリを入れられるスマフォなら連携できるので、SONY製のスマフォじゃなくても良いところも捨てがたい!(笑
マザボのバックプレートが上向きになるように縦置きする煙突系のPCケース。
最初の煙突系(FT03)は一見ゴミ箱のような形状で、上面にファンを取付け排気するので排気効率が良かったが、通常は人間から離れた場所にある裏面が上面くるため取付けたファンと人との距離がかなり短くまた直接ファンが見えたりするので、システムファンやグラボの排気ファンの音が気になって仕方が無かっただろう。ケースの高さが結構あるので、デスクの上に設置するのが一番よかったハズだが、デスクの上にゴミ箱?という変テコな風景になっただろう。
このSST-CS01シリーズはmini-ITX用でサイズは小さ目、故にハイエンドの大きなグラボは対象外、拡張スロットも1つあるがロープロファイル、ケース下面に12cmファンを設置しここから吸気しケース上部の穴から自然排気する様になっており静穏性にも配慮している様に思える。
-HSにはケース上面に6個の3.5inchHDD用のホットスワップベイまで付いたNAS向けケースとしては安い様な気もする。
フットプリントが21cm×21cmと小振りでデザインも良いので置き場所にもあまり困らないだろう。
オフィスにPCばかりでファイルサーバーが無い状況だったらコレもよいかな?