アカウント名:
パスワード:
M/Fっていうのの存在価値がよくわかりません。# 研修で実マシンそのものを見たこともあるし、Win上でコンソールエミュレータも触ったことあります。# 本当に触って一部の（おそらく簡単で定例的な）処理を打ち込ませてもらったことがある程度ですが。
よくわかっていないので、M/Fの重要性は次のように認識しているけど間違いあるのかなぁ。・整数型が扱いやすい（桁数で管理している。固定小数点１０進数型。会計処理でDouble型を使って浮動小数点のバグを混在させられる心配が無い）・既存の完成された仕掛けを移行する巨大なリスク。いわゆる「レガシー」の言葉で批判的に言
アベイラビリティ（可用性・故障しないで動く性質）の代わりにスケーラビリティ（拡張性・パワーを拡大させる性質）はあんまり無いかんじですかね。
確かにOpen系は「壊れても仕方ない・壊れたら交換。どうせ安いし」って言う発想が強いですよね。M/Fあたりは「決して壊れない」という考え方なんでしょうか。（といいつつ、隣のM/Fオフィスはトラブル続き・・・ハードウェア障害ではないかもしれませんが）
Win系やLinux・Unix系に比べても、チューニングしたりすることは少ないように思います。メーカーが標準で提供している機能の外のことは、「仕様外です」って言ってしまうような。（この辺は単に文化の違いかな？）
それにしてもM/Fって何十億もかかるんですか・・・。コストがそんなにかかるならば、Open系の並列や大多数サーバ化になってもコストを取る戦略に入ってしまうのが理解できますね。
やっぱり環境構築・運用ルール策定まで含めたトータルソリューションこそ、M/Fを知る上での重要ポイントなのかもしれませんね。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
UNIXはシンプルである。必要なのはそのシンプルさを理解する素質だけである -- Dennis Ritchie
Open系しか実際には知らない平成生まれだけど (スコア:0)
M/Fっていうのの存在価値がよくわかりません。
# 研修で実マシンそのものを見たこともあるし、Win上でコンソールエミュレータも触ったことあります。
# 本当に触って一部の（おそらく簡単で定例的な）処理を打ち込ませてもらったことがある程度ですが。
よくわかっていないので、M/Fの重要性は次のように認識しているけど間違いあるのかなぁ。
・整数型が扱いやすい（桁数で管理している。固定小数点１０進数型。会計処理でDouble型を使って浮動小数点のバグを混在させられる心配が無い）
・既存の完成された仕掛けを移行する巨大なリスク。いわゆる「レガシー」の言葉で批判的に言
Re: (スコア:2)
人生は七転び八起き、一日は早寝早起き
Re: (スコア:1, 参考になる)
アベイラビリティ（可用性・故障しないで動く性質）の代わりに
スケーラビリティ（拡張性・パワーを拡大させる性質）はあんまり無いかんじですかね。
確かにOpen系は「壊れても仕方ない・壊れたら交換。どうせ安いし」って言う発想が強いですよね。
M/Fあたりは「決して壊れない」という考え方なんでしょうか。
（といいつつ、隣のM/Fオフィスはトラブル続き・・・ハードウェア障害ではないかもしれませんが）
Win系やLinux・Unix系に比べても、チューニングしたりすることは少ないように思います。
メーカーが標準で提供している機能の外のことは、「仕様外です」って言ってしまうような。（この辺は単に文化の違いかな？）
それにしてもM/Fって何十億もかかるんですか・・・。
コストがそんなにかかるならば、Open系の並列や大多数サーバ化になってもコストを取る戦略に入ってしまうのが理解できますね。
やっぱり環境構築・運用ルール策定まで含めたトータルソリューションこそ、M/Fを知る上での重要ポイントなのかもしれませんね。
Re: (スコア:2, 参考になる)
逆だと思いますけど。
一般的なラインナップに載っている範囲では、汎用機の方が広いです。
（ハードの性能ではなく、リース料金で性能上限が決まる点に注意）
｜チューニングしたりすることは少ない
OSの導入は非常に面倒です。導入作業＝チューニング作業、ですから。
（使用メモリ量を減らして月額リース料金を下げるという目的もあります）
・チューニング項目に関して
OSそのものに大量のカスタマイズポイントが用意されています。
また、APIの取捨選択も可能です。
（unixならばカーネルソ
notice : I ignore an anonymous contribution.
Re: (スコア:1, 参考になる)
昔は性能向上のためOSのモジュールをインストールする順番まで決まっていたそうです。
バッチとかを流しても同じ処理であればCPU時間はどんなシステム負荷が高くても変わらないので重宝しました。
DBの講習会も4泊5日であったりして、1回のI/Oが50msとして6時間以内でバッチが完了できるかと言う演習もありました。
今では勘定系でもWindows系が使われるようですがやっぱり不安。
Re:Open系しか実際には知らない平成生まれだけど (スコア:2)
OSは落ちないけど、RDBとかディスクをいじりたくなると、すぐに静的なな時間を確保してくださいという話になって、IPL(再起動)になりませんか。
昔ながらの日中オンライン、夜間はバッチ処理という流れであれば作業時間をとれるので、静的な時間を確保するのは難しくないですが、24時間オンラインが一般的な現状にはちょっと辛い気がします。
Re: (スコア:0)
>ちょっと辛い気がします。
どういう場面か掴み難いですが、その手の状況が発生するのであれば
多重化したシステムという構成になっているものではないでしょうか？
更に、少なくとも「ちょっと構成をいじりたい」みたいな状況を作らない運用が
汎用機では行われるのが普通だと感じます。つまり、計画をきちんと立てることが
前提なので安易なシステム変更などは行わないので。
その点、パソコン・ワークステーション系だとトライアンドエラーが結構安易に行われ
る傾向がありますが、それを「柔軟な対応」と言えば聞こえはいいですが、
計画の詰めが足りない裏返しだと感じることもあります。