品質悪化プログラム

Windowz10は、過去のWindowzで問題になっていた「更新プログラムを適用しないユーザーは脆弱性が放置される」という問題への解答として“強制アップデート”が標準となった。

だが過去十数年間、Windows updateが100%信頼に足るサービスであった事は無く、度々トラブルの原因となっていたために一部のユーザーは自動更新を切り、ユーザー自身の判断で更新プログラムの適用を行って来た。

これがWindowz10になってから非常に手間のかかる作業となり、度重なる仕様変更に翻弄され、とにかく時間を浪費する原因でしかなく、無駄にかかった時間を自給換算してM$に請求したい衝動にかられるほど。


そこに来てRS3からまた仕様変更があって、過去に行ったWindows updateの手動化の方法について私の頭が混乱し、何がなんだかサッパリとなったところにようやく一つの答えを見つけた。


品質更新プログラム適用のトラブルを未然に防ぐ
https://news.mynavi.jp/article/win10tips-265/


こんなものは本来アップデート前に仕様が公開されてそれを確認すれば良いのだが、正直もう付いていけない。

それよりも現在のWindows updateは更新プログラムに“品質更新”と付いているが、今年は毎回トラブルが出ているおかげで品質更新というよりも「品質悪化」の間違いではないかと。

もうすぐRS4が出るらしいが、もう何も変えて欲しくないと心の底から思っている。

Uberの自動運転自動車事故続報

2018年3月18日の22時頃に発生したとされる、Uberの自動運転自動車による道路横断者を轢いて死亡させた事故。

先日GIGAZINEにこの事故の車載カメラによる映像の記事が出ていた。


Uberの自動運転カーが（中略）、ドライバーの確認不足の疑いも
https://gigazine.net/news/20180322-uber-accicent-driver/


自動運転のテストをしているのに、“ドライバーの確認不足”とは一体なんなのか。

・・・記事では映像から抜き出した画像がいくつか紹介されていて、その画像と共にその時の状況の説明が付けられている。


写真や記事の説明などから、この事故は夜の暗い道路で起きた事がわかるが、道路を横断する人が最初に写っている画像を見る限り、地元警察の見解とする「人間が運転していたとしても、事故が避けられる状況ではなかったかもしれない」というようにはとても思えない。


その写真には走行車線の中央にまで移動した歩行者の靴がが白く写りこんでいるが、写真から推測されるおおよその距離は30m前後。
道路の外からこの位置にまで歩行者が移動する時間を考えると、「遅くとも歩行者が車道に侵入する直前まで」に発見出来ていれば十分に余裕をもって停止出来たはず。

計算すると以下のようになる。（事故を起したクルマは時速60Kmで走行）

・写真から推測される歩行者までの距離を30mと仮定
・路肩からセンターラインまで３ｍと仮定、発見時の歩行者位置は路肩から２ｍと仮定
・自転車を押して歩く歩行者のスピードを秒速1mと仮定
・時速60kmの自動車が1秒で移動する距離は16.67m

以上の数字から計算すると、路肩に入る時点で発見すれば50m以上手前からブレーキ操作が可能。
これは緊急のブレーキではなく、普通に減速して止まれる距離である。

現場は障害物の無い直線道路で見通しも良く、車道脇の植え込みに使うと思われる土が露出している帯状の部分にも視界を遮る障害物となるものは草一本生えていない。画像ではヘッドライトがロービームになっているが、通常このような場所ではハイビームにしなければならない。発見が遅れた一因はヘッドライトがロービームだった事が挙げられるが、画像には道路を照らす照明が画面奥に写っており、画像では暗くて見えない部分も肉眼では歩行者の影がはっきり認識できるはず。

これは私自身夜間の自動車運転経験が非常に多い事から、そうした経験上の判断である。


このような状況下では、本来ならば現在の自動運転自動車の車載カメラやレーダーでも十分余裕をもって認識できるはず。今回はそれが正常に働くとは限らない一例を示した。

ましてや、街路樹や電柱などといった障害物の陰から人や動物などが飛び出す場合でも、体の一部でも障害物からはみ出していれば人間の目にはそれがなんであるか、その一瞬後には何が起きるのか容易に予測できるが、現在の自動運転自動車のセンサーとコンピュータの組み合わせでそれが可能なのか疑問が残る。
こうした歩行者の認識が難しい状況に、夜間の暗さや雨天などの悪天候が加わったらどうなるのだろうか。

もうこうなったら人間にも自動運転のシステムの一部になるような機械を取り付ける必要があるかもしれない。


なお、この事故の責任の所在について議論が分かれているが、私は100%、Uberに責任があると思う。

自動運転車初の死亡事故、責任の所在が争点か
https://jp.reuters.com/article/uber-self-driving-legalrisk-idJPKBN1GY0G9


他記事

[ビデオ]: Uber自動運転車の死亡事故のときドライバーはよそ見をしていた
https://jp.techcrunch.com/2018/03/22/2018-03-21-video-the-driver-of-the-autonomous-uber-was-distracted-before-fatal-crash/

人と衝突しても相手がケガをしないように、自動運転自動車はボディをマシュマロで作るべきだ！



関連記事：

「Uberの自動運転車で死亡事故」というニュースに思う
https://17inch.blog.so-net.ne.jp/2018-03-21

Ryzenに内蔵されるセキュアプロセッサの脆弱性について

先日CTS Labsから異例の情報公開が行われた、AMD製CPUのZENコアに内蔵されるARM Cortex-A5ベースのセキュアプロセッサに関する脆弱性問題について、先日21日、AMDより正式な発表が行われた。


Initial AMD Technical Assessment of CTS Labs Research
https://community.amd.com/community/amd-corporate/blog/2018/03/21/initial-amd-technical-assessment-of-cts-labs-research


この記事によると、脆弱性は確かに存在するようだ。
当初デマの可能性があると多くの人が考えていた（私もそうだ）が、脆弱性の存在自体は本当であった模様。

ただし脅威としては実質ゼロに近い。
何故なら、この脆弱性を利用するには“管理者権限が必要”という、すでに悪意のある者にコンピュータが乗っ取られている状態である事が前提であるからだ。ただし今回の問題は、乗っ取られた後の段階でより深刻な被害を受ける可能性があるために放置は出来ない。（具体的には、乗っ取られた後も有効なOSの各種セキュリティ対策がほとんど無効にされるために、より簡単に様々な操作が可能となる。）


AMDによると、この問題に対しては数週間以内に対策されたUEFI(BIOS)の配布を行う予定。

また、チップセットのX370に存在するバックドアに対しても、同様にUEFI(BIOS)による対策が行われる。

従って、実際にこれらが現在稼働中の“ZENコアのCPU”を搭載したコンピュータに反映されるのは、AMDによる対策パッチの配布が始まってからさらにその後、パソコンの各製造会社やマザーボード製造会社等がこの対策を反映したUEFI(BIOS)を現在稼動している対象のコンピュータ向けに配布を始めて、さらに対象のコンピュータを所有或いは管理する人が対策されたUEFI(BIOS)を受け取って書き換え作業を行った場合、となる。


まあ、ZENコアのCPUを使ったサーバーを運用している会社や、Ryzenのパソコンで機密に関わる情報を管理している会社や組織など、個人ではない場合には大いに関係がある問題だが、趣味で使うような個人所有のパソコンの場合にはほとんど関係が無い。

何故なら、それ以前の必要な対策を十分に行っていないような環境では、Ryzenの持つ脆弱性とは無関係に情報をタレ流しているのだから。

個人の場合、UEFI(BIOS)の書き換えに必要な知識があり、かつ情報漏えいに関して日頃から特に対策を行っている人ならば、誰に言われるまでも無く自分の持つパソコンのFEFI(BIOS)の対策されたものが出たかどうかを調べるだろうし、対策されたUEFI(BIOS)が出れば自分で書き換え作業を行う事だろう。（当然この問題を知っている事が前提だが）

それ以外の人の場合は、漏れなく放置されると思われる。
というか、ほとんどの人はそれ以前にこんな問題がある事すら知らないだろう。


この件に関して過去に書いた記事はこちら↓


今回発表されたRyzenの脆弱性をわかりやすく言うと
https://17inch.blog.so-net.ne.jp/2018-03-17

AMDのZENに深刻なセキュリティの欠陥がある？
https://17inch.blog.so-net.ne.jp/2018-03-15-1

「Uberの自動運転車で死亡事故」というニュースに思う

今日、こんなニュースをネット上で見つけた。


Uberの自動運転車で死亡事故--公道試験を停止
https://japan.cnet.com/article/35116397/


過去にはテスラのクルマでも死亡事故が起きているが、それは運転手自身が命を失った事故だった。
しかし、今回Uberの自動運転自動車が起した事故は他人を巻き込んでの死亡事故で、自転車を押して道路を横断していた人を轢き殺してしまったというものだ。

昨今はいくつかの地域で、一般公道での実証試験が行われ、或いはこれから行われるという状態。
すでに始まっている試験運行ではその内に必ず起きると思っていたが、意外と早く起きたと思う。（あれだけ自信を持ってやっているのだから、もっとマシなモノが出来ていると思っていた）

事故を起したUberの試験は当然に中止となったが、他の現在進行中の試験もこの事故が発端となって中止や延期になるだろう。


こうした事故は、新しい技術が開発されれば必ず起きる類のものだ。

現在機械的な意味での安全性において極まりつつある自動車であるが、自動車が実用化されたばかりの頃は事故率が高く死亡事故も起きまくっていた事だろう。自動車ではないが、初期の飛行機だって落ちまくって死屍累々だったはずだ。そういった犠牲の上で技術が進歩していった結果、現在の安全性が高い乗り物へと進化したのである。


しかし自動運転の場合は少し事情が違う。

何故なら、自動車の自動運転の場合は既存のすでに安全性が確立した乗り物を、人の手を介さずに走行できるようにするというものであり、大衆の認識も既存の自動車との比較になるからだ。

しかも、自動運転のコンセプトで最も重要な要素が「機械は人間と違ってミスをしない」という前提での“安全性”である。要するに自動運転の自動車が普及すれば、交通事故が劇的に減るというワケだ。

そこへ来て今回の死亡事故。
自動運転自動車の存在意義を真っ向から否定する事故である。

私は常々、自動運転の実証試験は時期早尚だと思っていた。
極めて限られた条件での元ならばまだしも、一般に利用させるというのは論外だと。
何もかもが足りていないのに、多少の実験的運用が成功したからといって気が大きくなっている人が多すぎる。

しかも今回の事故は、運転席に人が乗っていたにも関わらず起きている。
事故を起した車両は万が一のために運転手が乗っていて、いつでも操作が出来るようにしていたのだ。
これは、自動運転されたクルマに運転手が乗っていても緊急回避のための引継ぎなど不可能である事を示している。あっと思ってからハンドルを握って自動運転を解除しても、その時にはもう事故の回避など出来ない。運転手が、クルマが勝手に走る事に慣れれば慣れるほど、危機に対する反応は鈍くなるのだ。


というわけで、日本国内でも予定されている実験は、実験の条件を厳しく設定して安全性を担保するか、現在よりも完成度の高い実験車両を完成させてから行って欲しいと思う。そんな悠長に構えていては何年後に実験できるかわかったものではない、という意見が多いと思うが、10年や20年遅れたって実験による巻き込まれ事故が起きない方が良いに決まっている。（実験の当事者が死ぬのは尊い犠牲として納得できるが）

実験に巻き込まれて死ぬなんて、私はゴメンだ。


参考：

完全自動運転のクルマは本当に可能なのか？
https://17inch.blog.so-net.ne.jp/2018-02-05

セレナの自動運転機能搭載車が発売される
https://17inch.blog.so-net.ne.jp/2016-07-31

自動運転技術、未完のまま市場に出る恐れも
http://eetimes.jp/ee/articles/1510/20/news072.html

Uberの自動運転車によるサービスはなぜ中止に追い込まれたのか？
https://response.jp/article/2016/12/25/287550.html

Intel、Meltdown対策済みCPUを今年後半に出荷予定

現在「Spectre」と「Meltdown」という問題により、セキュリティ上の脅威にさらされているIntel製のCPUを使ったコンピュータ。
(ちなみにAMD製のCPUは「Spectre」のみ脅威となるが、事実上ほとんど影響が無い）

OSやファームウェアに対策が施されていても、完全には問題の解決になっていないとか、システムの性能が目に見えて落ちるなどの対価があったりという問題が残る。


こうした問題の解決にはCPUそのものから問題を取り除く必要があるが、それはCPUの基本設計を修正しなければならず、私は対策が施されたCPUがIntelから出て来るのは早くても来年頭(2019年1月以降)だと思っていた。

しかしIntelの開発力はすごかった。

Intelへの問題の報告(2017年6月)からわずか一年余りで、対策済みの製品を出荷するというのだ。


Intel、Spectre対策をCPUに実装、今年後半出荷の第8世代Coreなどから
https://news.mynavi.jp/article/20180316-601776/


とはいえ、この対策済みCPUでも二つある「Spectre」と呼ばれる脆弱性の内一つは対処されていない。
こちらはアプリケーションソフトウェア側の対策で容易に対処できるから後回しなのか。

それでも特に致命的な問題とされる「Meltdown」への根本的な対処が出来れば、少なくともCPUが本来の性能を発揮できるようになる事はIntelにとって非常に重い意味を持つ。


もし、現在使用中のパソコンが「Spectre」と「Meltdown」への対策によって性能が落ちたと感じる人が居れば、今年後半に出るという新しいCPUを買う意味があるだろうし、そうでなくともより安全なシステムが必要ならば移行する価値があるだろう。



Intel製CPUの致命的問題が発覚
https://17inch.blog.so-net.ne.jp/2018-01-03

Intel・AMD・ARM等のCPUに関する重大な問題
https://17inch.blog.so-net.ne.jp/2018-01-04

CPU脆弱性問題は結局どうなのか
https://17inch.blog.so-net.ne.jp/2018-01-15

今回発表されたRyzenの脆弱性をわかりやすく言うと

2018年3月13日にイスラエルの“CTS Labs”というセキュリティ企業が発表した、AMD製ZENコアを使うCPU群(とそのチップセットの一つ)が持つとされる１３もの脆弱性。

AMDへの報告から１日と経たず公表された事が混乱を生んでいるが、コレって結局どういうコトなのか。


要は“CTS Labs”の発表したAMD製CPUの脆弱性は全て、利用するための前提として事前に「UEFI(BIOS)の書き換えが必要」だったり、「管理者権限の取得が必要」である。

つまりこの脆弱性が利用可能という事は、それ以前に管理者権限の取得が可能なマルウェアに感染していたり、管理者のパスワードが漏れていて自由にコンピュータをいじれる状態なわけで、それってAMDの脆弱性がどうこう言う以前の問題なのでは？という意見があるのも当然である。


この話をコンピュータの知識がゼロな人にも理解出来るような例えで言うと、

「この家は屋内の部屋の鍵が簡単に開けられるし、金庫も鍵が壊れている。だから、玄関の鍵を開けさえすれば、タンスの中身や金庫の中身は盗み放題である。」

と“CTS Labs”は主張しているのだ。（ちなみに「Spectre」や「Meltdown」を同じ例えで言うと、屋内に保管している家の鍵を玄関ドアの郵便受けから棒を差し込んで取り出せる、という感じか？）

彼らの繰り出すWebページやビデオ等が要らぬ不安を煽る内容である事も問題で、セキュリティ企業を名乗る者としてどうなのか。

そして、そもそも悪意のある者に対象となるコンピュータの全てが掌握されている事が前提の脆弱性に、彼らの主張するほどの深刻さがあると言えるのだろうか？


まあ、“CTS Labs”の主張する脆弱性が事実であると仮定すれば、確かにその脆弱性が存在するのは問題であり、AMDは早急に対処すべきである。

なによりも正確な情報が皆無に近い現状、第三者による検証結果と、AMDによる正式な発表が待たれる。


追記

トーバルズ氏、AMD製プロセッサの脆弱性に関するCTS Labsの主張を一蹴
https://japan.zdnet.com/article/35116259/

この記事の内容にはまったく同意する。

ここ数ヶ月の間に公表されたIntel製CPUに絡む脆弱性は、「Spectre」「Meltdown」の問題以外でもざっと探してみただけでこれだけあるが、“CTS Labs”のような手法で騒ぎを起こしているものは一つも無い事を考えると、今回の事態がいかに異常であるかがわかるというものだ。


Intel Management Engineなどに8個の脆弱性が発見

Intel Active Management Technology (AMT) にアクセス制限不備の脆弱性

Intel製CPUに特権の昇格の脆弱性、公式チェックツールがWindows/Linux向けに公開

Intelの内蔵グラフィックス用ドライバに特権昇格の脆弱性

インテル製品に新たな脆弱性発見、フィンランドのセキュリティー企業



関連記事

AMDのZENに深刻なセキュリティの欠陥がある？
https://17inch.blog.so-net.ne.jp/2018-03-15-1

Intel・AMD・ARM等のCPUに関する重大な問題
https://17inch.blog.so-net.ne.jp/2018-01-04

CPU脆弱性問題は結局どうなのか
https://17inch.blog.so-net.ne.jp/2018-01-15

AMDのZENに深刻なセキュリティの欠陥がある？

タイトル通り、先日AMD製のCPUコア“ZEN”を使うCPU製品群の全てに13ものセキュリティの欠陥が見付かったという発表が、イスラエルのセキュリティ企業“CTS Labs”により発表された。

影響を受けるのはパソコン及びワークステーション向けの“Ryzen”及び“Threadripper”全種と、サーバー向けの“EPYC”全種。（組み込み向けのZENコアを使うSoCなども含まれるかは不明）

一応余計な心配事を減らすためにこの問題に対する安心できる点を書くと、これらの脆弱性を悪用するためには“最初に管理者権限での物理的操作が必要”であるため、少なくとも「Spectre」「Meltdown」と違いネット経由で簡単に悪用可能という事ではない。
不特定多数が出入りするような場所に無造作に置いてあるパソコンでもない限り、そうそう問題にはならないだろう。


一方でこの発表に対しては、この手の発表は今年始めに世界中を騒がせた「Spectre」「Meltdown」の場合でも明らかであるように、発見直後は関係者のみに密かに報告がされ、世間に公表するのは対策がある程度まとまってからであるのが通例。

しかし今回はAMDへの報告後一日と経たず公表されており、しかも具体的な技術情報が無いために一部で“信憑性が無い＝ガセネタである”と言われているようだ。ガセネタである根拠は他にも

・AMDに通知するよりも前(2018年2月22日)に「amdflaws.com」が作成されている
　→最初からこの脆弱性ありきで情報公開の準備をしていた可能性がある
　
・2018年3月7日頃に一部でAMD買収の噂が流れ、それから1週間後にこの問題が発表された。

・CTS-LabsのCFOは、ニューヨークにあるヘッジファンドの社長と同一人物

等々、“CTS Labs”という企業そのものが今回の発表のために作られたと言われてもおかしくはない状況証拠がこれら以外にも複数見付かっていて、公開されている動画が合成画像を多用してウソクサイとか、発表のタイミングがAMDの株価操作に最適なタイミングであるなど、疑惑が尽きない状況である。

以上の事から、決め付ける事は出来ないが、この発表はウソである可能性が高いと私は考えている。（もちろん、同時にウソではない可能性もあると考えている）


なお欠陥の内容についてだが、簡単にまとめると以下の通り。


・CPUに内蔵されるセキュアプロセッサの脆弱性
※ZENには“ARM Coretex-A5”というARM系CPUコアが内蔵され、セキュアプロセッサとして機能している。

　この脆弱性は大きく分けて三種類あり、「Master Key」「Ryzenfall」「Fallout」と呼ばれる。
　
　「Master Key」はUEFI(BIOS)の機能として存在するセキュリティ機能を無効にしたり、UEFIそのものに任意のプログラムを書き込んだり出来る。この脆弱性を利用するにはUEFIを書き換える事が前提であるが、「Ryzenfall」を利用するとUEFIの書き換えを禁止してもこれをすりぬけて書き込む事が出来る。

　「Ryzenfall」は“Secure OS”に関する脆弱性で、本来アクセス出来ない領域にあるセキュリティ情報を盗み出したり、任意のコードをセキュアプロセッサで実行することなどが可能だが、OS側の対策で防ぐことが可能であるようだ。

　「Fallout」はサーバー用CPUであるEPYCに存在する脆弱性で、「Ryzenfall」と同様の脆弱性である模様。

　以上の事から、OS側に「Ryzenfall」や「Fallout」への対策をし、UEFIの書き換えを禁止に設定する事でこれらの脆弱性を回避出来る可能性がある。


・チップセットの脆弱性「Chimera」

　「Chimera」は主にRyzenで用いられるチップセット「X370」に存在する脆弱性。
　バックドアとして利用可能で、チップセットを交換しないかぎり根本的な解決には至らないらしい。


以上。


今の所は実証コードも公開されておらず、また具体的に何をどうすれば脆弱性の利用が可能なのか方法もわからないようなので（実証コードや脆弱性の詳細が書かれた非公開資料は存在するという“ツイート”はあるが、それがAMDに渡っているかはわからない）、もしこの脆弱性が実際に存在するとしても一般の消費者が被害を被るにはまだそれなりの時間が必要だ。

消費するだけのブタである我々は、あわてず騒がず、AMDからの正式な発表を待つ事が賢い選択である。



ネタ元の記事

AMDのプロセッサに脆弱性、セキュリティ企業が情報公開--懐疑的な見方も
https://japan.cnet.com/article/35116106/

AMD RyzenとEpyc CPUに13種の脆弱性。Spectre類似、機密情報へのアクセスなど許す可能性
https://japanese.engadget.com/2018/03/13/amd-ryzen-epyc-cpu-13-spectre/

AMDのプロセッサ「Ryzen」と「EPYC」に重大な脆弱性、セキュリティ企業が公開
http://www.itmedia.co.jp/enterprise/articles/1803/14/news060.html

AMD製CPUに「致命的」欠陥 悪用でPC乗っ取りも
http://www.afpbb.com/articles/-/3167253

RyzenおよびEPYCに深刻な脆弱性が存在することをイスラエルのセキュリティ企業が公表
http://www.4gamer.net/games/300/G030061/20180314093/

RyzenやEPYC内蔵のセキュリティチップに深刻な脆弱性
https://pc.watch.impress.co.jp/docs/news/1111496.html

AMD、RyzenやEPYCの脆弱性報告に対し声明を発表
https://news.mynavi.jp/article/20180314-600588/

【CPU】 悲報 RYZEN / EPYCで13種もの脆弱性が見つかる
http://blog.livedoor.jp/nichepcgamer/archives/1070431576.html

Windows updateに深刻な問題

先日定例のWindows updateが配信されたが、Windowz7の32bit版に今回のアップデートKB4088875を適用するとBSoDによる再起動を延々と繰り返すなどの問題がある事がわかり、配信から1日後には配信停止の措置が取られるという事態になった。

今年に入って毎月このような問題が起こっており、Micro$oft社製OSの品質は時を追う毎に悪化の一途を爆進中だ。

（ちなみに先日書いたWindowz10のRS2→RS3強制アップデートは、やはりMicro$oft側のミスである模様）


今回のこの問題は、P6系CPUに存在する物理メモリー拡張機能（PAEモード）を無効にした32bit版のWindowz7で起きているという。
また、数は多くないと思うがSSE2をサポートしないCPU(Pentium3 以前)を使うシステムでも同様の問題が起きているらしい。

なおOSが64bitである場合、この問題は起きない。


もしこの問題が起きた場合は、Safe modeで起動してKB4088875をアンインストールする事で復旧が可能である。

今の所私が面倒を見ている方々からは何の連絡もないので一安心だが。

この問題で不要の出費を強いられた人は、Micro$oft社に損害賠償請求が出来ると思う。

できるというだけで、やって元が取れるかというと逆に損害が拡大するだけだが・・・

Windows10に移行したくない

先日知人のパソコンを、Windowz10がインストールされたものに交換する作業を手伝った。

仕事に使っているパソコンなので、単に交換というのではなく、Windowz10で動作しない業務ソフトの有無やプリンターなどの動作チェックが必要なためだ。


作業自体は2時間もあれば十分と私は考えていて、実際作業の9割程度は1時間半で終わった。
さあ、あとはプリンターのドライバを入れて印刷のチェックだ、と思ったその時。

Windows updateが再起動を要求するのでパソコンの再起動を行うと、立ち上がってきたパソコンは勝手に何か作業を始めた。

どうやら元々入っていたWindowz10はRS2だったらしく、RS3へのアップデートが自動で始まったようだった。


あっと思った時にはもう遅い。

結果、作業時間は1時間以上延長せざるをえなくなって、茶を飲みながら雑談しつつ、アップデート中のパソコンを眺めるという無駄な時間を過ごすハメになった。


こういう事が起こり得るという事は良く知っていたが、実際遭遇すると非常に困る。
今回はその日の仕事が終わった後だったので時間の浪費だけで済んだが、もしこれが朝の始業時に起きたらと思うと、Windowz10への移行はとてもじゃないが出来る事ではない、という判断しか出来ない。

何よりも今現在使っているWindowz7で何も困る事が無い以上、金と時間を使い、さらに新しく覚える事まで発生するWindowz10への移行には非常に抵抗があるのに、こうも問題だらけではお話にならないではないか。


なんていう事があったと思い返していた今日、こんな記事が。


Windows 10への移行、約半数が間に合わない？　IDCが予測、このままではXPの二の舞いに
http://www.itmedia.co.jp/enterprise/articles/1803/08/news100.html

Windowz10への移行は今年中から始めなければならないとか、悪い冗談としか思えない。

とはいえ、2020年1月でWindowz7の延長サポートが切れる以上、セキュリティ面の問題を考えたら嫌でもそれ以前にWindowz10への移行を完了しなければならないのだが。


Micro$oftはWindowz10が生産性を向上させると言い張っているが、それは絶対に嘘である。

余計な仕事を増やすだけで生産性を落とす、史上最悪のWindowzであるとしか、私には思えない。

ビデオカードが高すぎる

ビデオカードの価格高騰が止まらない。

少し前はマイニング用途に使われる機種が中心に値上がりしていたが、現在は古いチップを使ったローエンド製品まで値上がり傾向だ。


こうした理由は、主にビデオメモリに使われるDRAMが品不足で価格高騰という説があったが、最近は他にも電解コンデンサなども品不足であるという。

DRAMにしろ電解コンデンサにしろ、部品が足りなければビデオカードの生産が出来ず、そのうえ本来と違った需要のおかげでさらに品不足に追い討ちと、価格高騰の理由が複数あるのでどうしようもない。


こうした部品の供給が追いつかない理由は、単に需要増というだけではないらしい。
DRAMに関しては事実上韓国の三星とSK、それにアメリカのMicronの３社のみが供給している状態だが、増産すると急な需要減により相場が崩壊した時の損失を恐れて生産設備の増強が出来ないようだ。それにDRAMを製造している会社は現在この特需と価格高騰によって莫大な利益を上げている。他に参入出来る会社も無いため、競争の原理も働かないというワケだ。

またコンデンサ類に関しては中国での需要増があまりに急激である事が理由らしい。
あるネットの記事では電気自動車に使われているという話だったが、それだけではあるまい。
中国ではありとあらゆるところにコンピュータの入ったデバイスが浸透しているから、そうしたものを作る為に電子部品の内中国国内で生産が出来ないか、出来ても品質の問題などで輸入に頼らざるを得ない。
そうすると他の国での需要に影響が出るというわけだ。


一方でSSDなどに使われるNAND Flashは値下がりしているかもしれない。
理由はSSDの価格が下がりつつあるから。
昨年までは3D NANDの生産が追いつかずにいたが、今年に入って東芝の工場が本格稼動を始めたのだろう。また、三星ではNAND Flashへの投資が爆増中の中国に対抗して増産体制にあるという。中国製のNAND Flashが世の中に出回る前に、そうした需要そのものを押しつぶす作戦らしい。


まあそんなわけで、当分はビデオカードにしろメインメモリのDDR4にしろ、必要になったら高い買い物になる事を我慢するしかないようである。