Windows 7 Professional 32-bitに、Oracle OLEDB Provider Version 12.2.0.1.0をインストールするには、
例えば、C:\app\instantclient_12_2に必要なDLLを揃えて、PATH環境変数にこのディレクトリーを追加した後で、
regsvr32 C:\app\instantclient_12_2\oraoledb12.dllを実行すれば良い。
しかし、「指定されたモジュールが見つかりません。」のエラーが出ることがある。
こうなるとOLEDB Providerは登録されないので、OLEDB経由でOracle Databaseに接続することはできない。 これは、Visual C++ 2013 redistributableを インストールすることで解消された。
Is it time for open processors? を読んだので翻訳しておく。 ただし、正しく訳せているとは思わない。
これは、 Jonathan Corbet氏による2018年1月9日のlwn.netにおける記事で、 Creative Commons Attribution-ShareAlike 4.0 International (CC BY-SA 4.0) で公開されている。
MeltdownとSpectreの2つの脆弱性の公開により、 ハードウェアレベルのセキュリティー上の問題が存在し得ることに、 改めて注目が集まっている。 ソフトウェアの脆弱性に関しては、まだ脆弱なソフトウェアのセキュリティー の解消のために非常に多くの努力がされているが、 ハードウェアな脆弱なままであれば、全て無駄な努力である。 私たちのシステムを動かしているCPUは、高度にプロプライエタリーであり、 嬉しくない驚きを内包していることが示されている (例えば、Intel Management Engine)。 そうなると、ソフトウェアがそうであったように、 オープンソースハードウェアに移行しようという動きがでてくるのは当然だろう。 オープンソフトウェアハードウェアへの移行は可能かもしれないし、 確かに利点はあるが、それで全てが解決する訳ではないだろう。
現代のCPUは複雑であり、販売されている市場は過酷な状況である。 オープンなやり方でCPUを開発しようと言うのは驚かれるかもしれない。 しかし、この分野でもオープンな開発を進める動きはある。 オープンなCPUと言う考えは、ファンタジーではない。 以下に、いくつかの事例を紹介する。しかし網羅的なものではない。
POWERアーキテクチャーを元にしたOpenPOWERの事例を見てみよう。 これは真にオープンソースではない。 主体的に利用するのであれば、OpenPOWER Foundationに加盟しなければならない。 しかし、プロセッサーを共同作業として開発するという例ではある。 比較的オープンな設計に基づいた製品が出荷されている。 OpenPOWERは、ハイエンドに特化している。 この設計に基づいたチップが、近い将来携帯電話やノートPCに搭載される というのはありそうにない。
OpenSPARCという試みもある。Sun MicrosystemsがSPARC T1とT2の設計を完全に オープンにしたものである。 これらの設計を使おうとしたプロジェクトはいくつか存在する。 しかし、どこまで成功したのかは分からない。 オープンなSPARCの設計は10年前の設計であり、 SPARCに未来があるのかも疑わしい。 Oracleが最新のプロセッサーの設計を公開するのであれば面白いかもしれないが、 実現しそうではない。
OpenRISCは完全にオープンなプロセッサーであり、 組み込み用途をターゲットにしている。 OpenRISC 1000という完成したプロセッサーが1つ存在する。 商業化されたOpenRISC 1000も存在する。 mor1kxと行ったレファレンス実装も存在する。 Linuxカーネルは2011年にリリースされたバージョン3.1から OpenRISCをサポートしており、2014年にはDebianも移植されている。 しかし2016年にはDebianのサポートは終了してしまった。 LinuxカーネルにおけるOpenRISC関係の活動は減速してしまったが、 2017年にはSMPサポートが追加されている。 全体的に言って、OpenRISCはかつての勢いを失ってしまったようだ。
最近はRISC-Vアーキテクチャーに関連した動きが活発になっているようだ。 RISC-Vプロジェクトは、特定の実装ではなく命令セットアーキテクチャー(ISA)に 特化している。しかしハードウェアの実装は存在する。 Western Digital社は、ストレージ製品にRISC-Vプロセッサーを使用していく 予定であると、最近発表している。 これが実現すれば、何百万ものRISC-Vプロセッサーが出荷されることになる。 このプロセッサーを試してみたい人に向けて開発キットが入手可能であり、 いくつものコアの設計が使用できる。
OpenRISCと違い、RISC-Vは非常に新しい。 実際Linux Kernel 4.15で初めてサポートされる予定である。 開発は非常に活発で、ツールチェインとライブラリーのサポートも それぞれのプロジェクトに取り込まれつつある。 RISC-Vは商業的なサポートも存在する。 RISC-V Foundationには多くの会社が加盟している。 RISC-Vは、しばらくの間は、活発に開発が進むであろう。
MeltdownとSpectreの回答として、RISC-V Foundationはより安全な代替案として RISC-Vを押し進めるプレスリリースを出した。 実際、RISC-Vは投機的なメモリーアクセスをしないため、これらの問題は存在しない。 しかし、RISC-V Foundationは、RISC-Vには特定の脆弱性がないということを越えて 利点があるとしている。つまり、開発モデルがオープンであると言うことである。 RISC-V Fundationは、幅広い開発者から最良のセキュリティーに関するアイディアを 迅速に集められると語っている。
これはますます説得力を持って来ている。 Linuxはカーネルレベルでハードウェアの脆弱性に対処しようとしているが、 プロプライエタリーなハードウェアとカーネルより下で動いているプロプライエタリー なソフトウェアを制御することはできない。 RISC-Vのようなオープンなアーキテクチャーの魅力は増して来ており、 いずれ全てを制御できるようになるかもしれない。 これは追い求めるべき夢だと思うが、その前に克服しなければいけない困難が 存在している。
1つ目は、当然だが、コンパイラーがフリーであるように、チップを製造する設備が フリーではないと言うことだ。特に、ハイエンドのプロセッサーを製造するには 高価な設備が必要となる。 シリコンのレベルで陳腐化が進めば、既に進んでいるという人もいるが、 製造設備はより小規模の顧客も使用できるようになり、 私たちがプロセッサーの設計を実験できるようになることも現実的になって来る。 しかしmakeコマンドを実行するように簡単で安価にはなりそうにはない。
誰でもプロセッサーを作れるようになるまでは、自分のプロセッサー を誰かに作ってもらうしかない。 これは私たちの多くが、自分のためのソフトウェアを他人にビルドして もらわないといけないのと同じように、良くない状況である。 ソフトウェアのレベルで、毎回同じバイナリーが生成されるようにビルドすることは、 重要であり、在も取り組みが続いている課題である。 ハードウェアレベルでも難しい課題になるだろう。 しかし、実際のハードウェアの一部となった設計を検証できないのであれば、 自分の使用しているチップの実装が、想定している設計通りかを確認することは できないだろう。
RISC-Vの仕様に限った話ではないが、実装の設計は公開されなければならない。 RISC-Vが市場で成功したとしても、私たちの実際に購入するプロセッサーが フリーなライセンスの設計になるとは限らない。 自分自身のデータセンターを構築するような大規模の事業者は、 フリーなライセンスのプロセッサーを使っていると確信の持てるかもしれないし、 自分自身でプロセッサーを作ってしまうかもしれないが、 私たちのほとんどは、それより不利な立場に置かれることになる。
最後に、もし完全にオープンなプロセッサーを手に入れたとしても、 脆弱性から無縁になるということはないだろう。 フリーなカーネルは存在するが、カーネルの脆弱性は存在している。 これと同じである。 オープンなハードウェアは私たちが自分自身のハードウェアを 制御化に置くのに不可欠ではあるが、問題を全て解決してくれる 魔法の杖ではない。
しかし、以上のことにより、私たちが、自分自身のハードウエアの設計を もっとオープンで自由なものにしようという動きが阻害されるとは思わない。 かつて、フリーなオペレーティングシステムを作るのは、非常に 困難なことだと思われていたが、私たちはいくつものフリーなオペレーティング システムを作り上げた。 プロプライエタリーなハードウエアの設計を使わないようにするのは、 私たちの自由を維持する最良のチャンスの1つである。 これを試すのはばかばかしいことではない。
Microsoft Windows 10をMay 2020 (2004)にアップデーしたら、Windows To Goがコントロールパネルになくなってしまった。 廃止されてしまったらしい。 BIOSを更新するために使っていたので不便になってしまうが、仕方がない。 ...
