これは確かに正しいのですが、その際に、closed なものを選ぶのか、open なものを選ぶのか、で長い目で見て違いがあると思います。というのは、open なものを選んで参入障壁を低くすれば、OS からライブラリ、アプリケーションのレベルまで多くの試みをしようという気になり、情報関連の全体的なスキルがあがる可能性がある。一方 MS の closed なものを OS として採用すると、アプリケーションレベルはともかく、いつまで立っても国内での OS の開発レベルが上がらない。アプリケーションレベルも、なんだかんだといって Windows や Office に取り込まれて、国内のソフト産業全滅、なんてことになったら、運用体制を整えるための人材が育たない。
運用体制というのは、単に MS や redhat の提供するパッチを当てることではなく、自分の運用しているシステムと指摘されている問題を把握して、パッチを当てるべきか、選択的にパッチするのか、あるいは自前でパッチやライブラリを作るか、といったことができる人材をコンスタントに供給できる体制まで含まないと、(少なくとも国が主導する話としては)片手落ちでしょう。
運用体制 (スコア:2, すばらしい洞察)
んです。責任をとる人が必要なら責任を持つ部門をつくればいい話。
例えばセキュリティホールが発見されたとすれば,その深刻度や修正をあてる
ことによって既存の業務システムへの影響を検討する専任の責任者がいて,
既存の業務を一時停止させてでも修正をあてるべきであるならばその旨現地に
修正手引書だとか代替運用の段取りをつけたりとか
Re:運用体制 (スコア:0)
>んです。責任をとる人が必要なら責任を持つ部門をつくればいい話。
これには激しく同意!!
>こういうのについてはMicrosoftの場合情報提供が遅い,また知っていても
>情報を公開しない,などの場合があるので比較すればオープンソースOSの方
>がこういう運用はしやすいんじゃないかと。
これは認識間違い。
以前に比べれば驚くほど情報が早く出回るようになった。
英語サイトをちゃんと見てる?
日本語サイトでのんきにやってると置いてかれるぞ。
通報してもひたすら放置し続け、
さ
Re:運用体制 (スコア:1)
これは確かに正しいのですが、その際に、closed なものを選ぶのか、open なものを選ぶのか、で長い目で見て違いがあると思います。というのは、open なものを選んで参入障壁を低くすれば、OS からライブラリ、アプリケーションのレベルまで多くの試みをしようという気になり、情報関連の全体的なスキルがあがる可能性がある。一方 MS の closed なものを OS として採用すると、アプリケーションレベルはともかく、いつまで立っても国内での OS の開発レベルが上がらない。アプリケーションレベルも、なんだかんだといって Windows や Office に取り込まれて、国内のソフト産業全滅、なんてことになったら、運用体制を整えるための人材が育たない。
運用体制というのは、単に MS や redhat の提供するパッチを当てることではなく、自分の運用しているシステムと指摘されている問題を把握して、パッチを当てるべきか、選択的にパッチするのか、あるいは自前でパッチやライブラリを作るか、といったことができる人材をコンスタントに供給できる体制まで含まないと、(少なくとも国が主導する話としては)片手落ちでしょう。