「汎用機」を含む日記 RSS

はてなキーワード: 汎用機とは

2018-05-30

anond:20180530105549

業務精通してる人が足りなくなってるというシステム開発に限らず大半の職種で起きるであろう問題が何故かCOBOL出来る人が足りませんていう問題すり替えられてるよな。

実際の求人では「COBOLでの開発経験があること」じゃなくて「○○という汎用機での開発経験があること」となってたりするから現場の方が問題を軽視してるわけじゃないんだろうけど。

anond:20180530105549

あれってCOBOLという言語をできる人がいないという言い方が誤解を招いてる気がする、ソースを解析したり書いたりはクソみたいなソースでも時間をかければどうにかなるし、実際は使用されているメインフレームによって実装が違うから人が足りないというのが正しいと思う。

それに汎用機ルールなんて機種の開発会社によっても違うし機種が同じでも運用によってルールが違うし、原因が高齢化による退職だというなら解決方法は人を育てるしかない。

2018-05-11

anond:20180511091901

他社はエンジニア不足が囁かれてから態度が変わったけどFだけは汎用機時代から変わっていないイメージ

2018-04-04

大手SIer入社した僕がゾンビになるまで

Qiitaにいるような人たちとはまったく違う、意識が低かったがゆえの自己責任の話。


大分昔のことだが、新卒大手SIer入社した。

それまでプログラミングなんてしたこともなかった人間入社させてくれるのが大手SIerである

覚えることは沢山あったし、関わるプロジェクトによって言語Webアプリケーション開発用のものから汎用機のものまで様々。

設計運用もそれぞれ違う。

毎回付いて行くだけで必死で、仕事以外ではストレス発散のためにプログラミングとは別のことをしていた。


勉強は嫌いじゃなかったと思う。資格取得が奨励されていたのもあって、自分もいくつか持っている。

でもプログラミングが好きかと言ったら、特に作りたいものも思いつかず、プライベートでの勉強はしていなかった。

自分にとってプログラミングとは仕事で関わるシステムありきだった。

その時関わっているシステム関係すれば必要最低限のことは学ぶし、それ以上ではなかった。


大手SIerというのはそういう人間も沢山いるのだ。

PM職でもないのに(システム業務要件機能仕様理解しなくてもやれるのはPMなどのマネジメント職だけだと個人的には思う)、関わっているシステム言語さえ学ぼうとしない人もいる。

そういう所である

そういう所の中では自分はまあまあ上手くやれていたと思う。


大手SIer技術力など期待してはいけない。

研究部門を抱えている所も最新技術を開発している所もあるだろうが、そういう優れた人たちは組織のごくごく一部だ。

マネジメントも含めて、優れた人間などそんなにいない。それどころか設計コーディングさえあやしい人たちも沢山見てきた。

まあ自分が見ていない所に優れた人が沢山いた可能性もちょっとだけある。


自分マネジメントにも興味がなかった。それは数字管理をしているだけのように見えた。

リスク管理ヒューマンリソース管理などの概念自分になかったとも言う。


それまでどんなきつい所でもそれなりにやれてしまった経験があったため、自分には警戒心がなかった。

ある日、マネージャーが詳細を教えないプロジェクトにぶち込まれた。ぶち込まれた、というのがまったくふさわしかった。

詳細は伏せるが、SAN値が削られて行くようなものであった。

新しい技術が学べるといったプラスの側面も一切存在しない。

やがて周囲が倒れ、自分も倒れた。


以来、無気力になって生きている。


自分のいるSIerにいるマネジメント職は成功や失敗について学ばない。学ぶ人もいるんだろうけど自分の見た範囲では学ばない。

なぜ成功したのかもなぜ失敗したのかも分析をしない。

名ばかりのPM職を送り込んだって失注するに決まってるじゃん…というようなアサインを繰り返す。

PM職に払っている給料の元を取りたいんだろうか?そうやっても失注するんだけど。


大型プロジェクトゆえに新技術の取り込みが遅れるとしても、そのプロジェクトなりに効率良く開発するための準備はあるのにそれをしない。

どこで失敗してしまうのかを学ばず、人の数だけ増やして、その増やした人間が頑張ればできると考える。

増やした数の中には最低限のことさえしない人も含まれている。

そういう人たちも、プロジェクトの進め方も、改善しないままにぶち込まれるのが続く。

改善提案?している。けれども一緒に動こうとする人なんかいないのだ。

個人努力でどうにかなるならプロジェクト炎上なんてしないのではないかな。水源も道具もないのに消防士というだけで消火できるなんてことはない。






主体性がないというのはゾンビのようなものだな、と思う。

技術自分で学んでこなかったから、自分で選んで環境を変えることができない。技術がないというのはそういうことだ。

システム自分を合わせるだけで済ませているというのはそういうことだ。

仕組みの中だけで終わらせているというのはそういうことなである

気付くのが遅すぎたが、ゾンビでも自力歩行ができるように、あるいはきれい燃え上がって終わりにするために、自分のために少しずつ学び始めている。

2018-04-01

上京して17年経ったので振り返った

18歳で地方私立高校を出て、上京して17年経ったのでまとめた。

大学中退して悩んでいる人、入ったばかりで中退せざるを得ない人に読んで欲しい。

自分場合だけど、ほぼ身一つで上京することが出来たようなもので、引っ越し先の1Rマンションにはカーテンも照明もなく、夜とか窓から入り込む月明かりで過ごす日々だった。

1日に使えるお金も500円ぐらいで、朝に飲物一つとパン一つを買って、それで夜まで凌いで、夜はおにぎりとかそんな生活

大学に入ったはいものの、家庭の事情ですぐに大学を辞めざるを得ないといけない上京になって、半年足らずで仕事を探して働き始めた。

初めての仕事での給料税込みで15万円/月ぐらい、今はほぼ無くなったと思うけど、システムオペレーターっていって大型汎用機とかの操作をする仕事をしてました。

地下とかにこもって、テープの入れ替えやら、印刷した帳票をまとめてラックに入れるとか、24時間365日で対応するそんな仕事

賞与とかって概念は無かったから、年収ベースで200万いかないとか、ほんとバイトした方がマシだったのかもしれない。

それが17年経ち、紆余曲折あったけど、今の仕事マーケティング支援もする営業企画みたいな仕事をしてる。

年収ベースで700万、マンションだけど首都圏に買えたし、車も買ったし結婚して家族もいる。

端折っちゃうけど、この17年で身から出た錆びで数百万円の借金を抱えたこともあるし(全額返済済)、離婚したことがある。

でも何とか生きているし、このご時世を考えると、たぶん人よりもちょっとだけ良い暮らしが出来てるんじゃないかとは思ってる。

運が良かったの一言で済ませるのかもしれないけど、学校中退してたって人並みの生活は出来るんだから、腐らずに頑張って欲しい。

2018-03-16

1年と2ヶ月で転職2回。面接通らん死にたい

25歳(鬱のため休学2年)。

3社とも全部IT系

1社目(新卒)と2社目は半年、3社目は2ヶ月続いた。

1社目は人間関係自主退職。2社目は自分無能すぎて契約打ち切り。3社目は鬱発症自主退職

1社目は汎用機保守運用OS移行お手伝い。2社目はデータ分析お仕事(望んでいた仕事だったが成果なくクビ)。3社目は常駐先でひたすら手順書作成

求人に応募しても経験がなさすぎるのと短すぎるために書類すら通らず、面接にありつけない。

今はもう何もしたくない。やりたいこともない。

友達恋人もいない。相談する相手もいない

死にたい

2017-12-07

anond:20171207112027

古の昔の汎用機時代

コードを手で書いて業者パンチを依頼していた時代があった

ホスト使用料馬鹿みたいにかかるから

コーディングは打ち込むだけ

開発は設計+コーディング+テストまでってイメージ

2017-10-15

anond:20171013135420

本体老朽化によるリプレースだろ。

からソフトデータがそのまま使えるように、本体エミュレートすればいい。

エミュレータやワンチップの方が汎用機のもの(まだ売ってるのか)よりずっと安いはず。

2017-10-14

あと5年もすれば昔を知る人が居なくなり日本中で同じ事が起こるだろ



あと5年もすればいよいよ昔を知る人が居なくなり日本中で同じ事が起こるだろ

技術者を軽視してきた経営側・管理側の招いた負の遺産となるだろう。

Q6.役所が現行システム資料を出すべきだろうが!

A6.もっともだけど、できないから無理だよ。

上記の通り仕様書がないことも多いうえ、システム課に限らず市役所人員は基本ローテーションするよ。

導入当初の担当者が残っていることは珍しいし、30年も前に導入した汎用機ことなんてここ10年に入った職員にはわからないよ。

こういった無意味な人事ローテーションをやめて、スペシャリストをしっかり身内に育成してきていれば良かったのに

残念なことに、「属人化は良くない」といった言い訳で、専門家を軽視してきた。

Q8.じゃあ役所は悪くないの?

Q8.悪いよ。

みんな沈む。

https://anond.hatelabo.jp/20171012165214

2017-10-13

汎用機シュミレータまたは1チップ汎用機

汎用機からの移行失敗とかの記事を見て思ったのだがx86上で汎用機をシミュレーとするとか1チップ汎用機を作るとかいう方向はないのだろうか。つまりハードウェアは置き換えて、ソフトはそのまま使うという方法

それなりの開発規模になるので、IBMはともかく富士通日立には無理な気もするけど。

2017-10-12

京都市が今回失敗したような、自治体システム更新について

http://itpro.nikkeibp.co.jp/atcl/column/14/346926/101101158/

Q1.役所仕事なんて全国でほぼ一緒なのに、なんで自治体ごとに別のシステムを作るの?

A1.地方自治体事務財務について法律で決まっているのは大枠だけだよ。

  それを実務≒内部規定に落とし込むのは各役所ごとなので大枠は似てても実務プロセス全然役所で違うよ。例えば同じ業務でも独自の語彙があったり、下手すると同じ語で市町村ごとに意味が違ったりするよ。


Q2.なんで新規で作らないの?

A2.80年代ぐらいにやったよ。その結果が政令市クラスに残ってて今回京都市更新しようとしてるような、メインフレーム上のシステムだよ。


Q3.メインフレーム汎用機)って何?

A3.みんなが使ってるWindowsとかLinuxとかのOSがなかった時代コンピュータだよ。IBMとかがベンダーごとに作っていてOSベンダー謹製だよ。性能はいいけどメチャ高いよ。

システム内でクローズして専用線以外では他とつながってなかったから、汎用機からPCサーバへの移行を「オープン化」と言うよ。

オープンソースソフトウェアとは全然関係ないよ。


Q3.使いまわしってどうやってやるの?

A3.80年代かに作ったシステムで動いてるCOBOLとかPL/IとかをLinuxとかUnixとかWindows上で動く言語コンバートしてリコンパイルするよ。

DBデータ階層データモデルからリレーショナルDB用にコンバートして移行するよ。こういう開発形態を「マイグレーション」と呼ぶよ。

あと、バッチジョブ制御もJCLという汎用機用の言語で動いているよ。これもそのままでは動かないのでコンバートするよ。

コンバート先はperlだったり、シェルスクリプトだったり、ベンダごとの独自スクリプトだったりするよ。

COBOLとかの実行プログラム移行も大変だけど、帳票の大量印刷はたいていバッチジョブでこなしてるので、JCLの移行もめちゃ厄介で大抵もめるよ。

今回もめたのもバッチらしいね


Q4.80年代のものを使いまわすとか。新規で作ればいいじゃん

A4.お金無限にあればできるよ。今の時代お金があった時代システムフルスクラッチ再開発するととんでもない予算になって市役所内の決裁が通らないよ。

しか汎用機時代の納品は割といいかげんだったのか、仕様書が残ってなかったりするから費用さらにかさむよ。


Q5.そんなんでよく運用できてたな

A5.当時はSE汎用機付属品みたいについてって、困ったらオペレーターとして介入して動かしていたみたいだよ。

そうやって現場感覚バリバリでやっているので、オペレーターしか知らないプロセスがあったりするよ。

マイグレーション開発では総合テスト中にそういう隠しプロセスが「発見」されたりするよ。こわいね


Q6.役所が現行システム資料を出すべきだろうが!

A6.もっともだけど、できないから無理だよ。

上記の通り仕様書がないことも多いうえ、システム課に限らず市役所人員は基本ローテーションするよ。

導入当初の担当者が残っていることは珍しいし、30年も前に導入した汎用機ことなんてここ10年に入った職員にはわからないよ。



Q7.なんで入札にしたの? 現行ベンダ指名してやらせたほうが良くない?

A7.金額がでかいから、たぶんどこの市役所でも入札案件だよ。

随意契約(随契)は無理だし、入札業者発注者指定する指名競争入札談合の温床になってたか最近あんまりやらないよ。


裏技としてRFP指名したいベンダーに書かせて公募指名入札にしたり、RFPの段階でハードを全部特定ベンダで型番まで指定するというのがあるけど、公になると多分問題になるよ。こわいね



Q8.じゃあ役所は悪くないの?

Q8.悪いよ。

入札案件RFPで書かれた各項目をどれだけ満たすかの技術点と、価格点で決まるよ。点が高ければだいたい自動的にそのベンダーに決まるよ。

なので、技術点の項目に現行システム調査にかかる項目を入れるとかして、現行機の開発・保守ベンダ高得点を取れるようにしておけば価格勝負してくるベンダーをはじけた可能性はあるよ。

もちろん現行の会社に嫌われて逃げられたとか、役所が現行の会社めっちゃ嫌いになって声をかけなかったとかもあるかもしれないけれど、可能性は低いと思うよ。



Q9.じゃあベンダーは悪くないのか?

A9.ここまで述べたようにこの手のマイグレーション火薬庫だよ。火を噴いても爆発しなければラッキーぐらいなので、強いて言うなら入札したことが悪いよ。

安すぎる見積もりを出したSEだか営業だかは死んでね。



Q10.お前(増田)は何者?

A10.前にマイグレーションをやったことがあるSEだよ。もうやりたくないよ。今は転職してSIerじゃなくなったからやらなくてよくなったよ。うれしいね

  しょぼいSEからここに書いたことは個人体験に基づく参照情報だよ。一般的じゃないことを言ってたり、間違ってたら教えてもらえると助かるよ。





(2017.10.13 追記)

Q3がかぶっていたよ。恥ずかしくてなきそうだけどブコメに番号で言及してくれている人がいるから忍んでそのままにするよ。


あと、「オープン化」の定義が違くない?という指摘があったよ。確かに増田が間違っていたので、記事の主旨から外れるけど補記するよ。

メインフレームは本文で述べたようにOSからハードまでメーカー謹製なので独自仕様のカタマリだよ。

これに対しPCサーバ標準規格で作られているよ。こういう標準規格に基づくサーバオープン系と呼ぶよ。

独自規格クローズしたコンピュータから、そうでないオープン系に移行するからオープン化なのであって、専用線とかは関係なかったよ。半可通な知識で語ってしまったよ、ごめんね。

京都市で火中にいるシステムズさんのサイト解説がこの増田よりも分かりやすくて正確だから気になる人は見てほしいよ

http://www.migration.jp/column/column01.html

完全に余談だけどオープン系のx86サーバに移行しても、システムはそんなにオープンにならなかったりするよ。

H系に頼むとDBが拝承DBになったり、Fに頼むとシステム管理が全部SystemWalkerになったり、要するにベンダ独自のミドルに入ってがっつりロックインされたりするよ。

オープン化(オープンではない)みたいなことになって面白いよ(面白くない)

2017-06-07

http://anond.hatelabo.jp/20170606234634

そうだったのか。申し訳ない

その中だとハードウェアSIerで、汎用機からオープン化の世界線に住んでて完全に取り残されてるわ。

2017-03-12

書き換える必要なくね?

大企業銀行で、昔から動いている基幹システムは、大抵メインフレームCOBOLの組み合わせである

それをここ十年くらい、リプレースx86サーバJavaという構成に変更することが多い。

しかし、ハード汎用機からオープン系になるのはともかく、プログラムを別の言語に書き換えるとか、誰も幸せになる気がしない。

ぶっちゃけCOBOLCOBOLのまま移植し、今後も改修を続けるほうが、長い目で見たコストも低くなるのでは?と思うのだ。

その理由はこうだ。


COBOLで書かれたバッチ処理は、設計書の書式がフローチャートであることが多い。

勿論ロクに設計書がない場合もあるだろうけど、いずれにせよCOBOL文法は、「普通の人にとっての仕事らしい仕事」をそのまま入れ子状のフローチャート(分岐の先が別のフローチャート参照みたいになってるやつね)に書き表したものである

そういうモノが既にある企業銀行文化において、当然発注側は担当者からお偉いさんまでCOBOLerフローチャート脳だし、新しいシステム設計でもそれを踏襲しようとする。

というか踏襲すること前提じゃないと設計書をレビューできない。

UMLで考えるようなパラダイムシフトはまず不可能なので、それを求めるのは受注者の傲慢だろう。

というわけで、受注した大手SIerは、ほぼ確実にフローチャートもしくはそれに準じる記法設計書で処理を組み上げざるを得なくなる。


そうなると、実装フローチャート設計を基にコードを書くわけだが、こういう設計ハッカー文化で発展してきた言語(FortranC/C++Javaという流れと、PerlからPythonPHPというインタプリタ系の諸言語)との相性が最悪である

設計とは実装を楽にするために書くのに、これらの言語において、フローチャート設計は役に立たないどころか、邪魔しかない。

からFortranしかなかった頃から、本物のプログラマ達はフローチャートdisってきたわけである

ちなみに筆者はハッカー文化が生み出した恩恵に敬意を示すし、実際とても好きという立場である

しかし、「普通人達普通思考からはかけ離れ過ぎているという意味で、「普通人達普通仕事」をシステム化する時にどこまで役に立つかについては、非常に懐疑的に見ている。

…いささか話が脱線してしまったが、とにかくフローチャートで上がってきた設計書でコードを書くならCOBOLアセンブラ選択すべきだし、それで書けないなら書く意味が無いくらいに思ったほうが良い気がする。


というわけで、自分COBOLからリプレース案件は、その根本的な愚かしさを抱えている現状を見るに、今後一切関わる気はない。

COBOLリプレースするのでない限りは。

2016-05-11

昔風に言うと銀の弾丸だっけ

今日日本の何処かで、基幹システムリプレースが行われている。

基幹システム…そう、古くは汎用機COBOLという、枯れるを通り越してまさに朽ち果てんとしているアレだ。

そもそも朽ちて土に還る前に建て直すためのリプレースだ。

てか朽ちないんだったら、もう半永久的に触るべきじゃないと思うんだけど、形あるものは必ず滅びるのだ、作り直すしかない。勘弁してくれーという感じだ。

じゃあ何を用いて作り直すか?またCOBOLが一番手っ取り早そう(ソースいじらず移植という意味で)だが、それは許されないのだそうだ。ふざけんな。

今だったら大体どこでもJavaで作り直しだ。どういうわけか今のトレンド()だ。

てかそれ、オブジェクト指向Webアプリに夢見過ぎじゃね?別にそれ銀の弾丸でもないしエクスカリバーでもなければ伝家の宝刀でもない、ただの道具なんですけど。

その証拠に、色々共通化されて保守性も拡張性も格段に上がったとか言ってる割に、その実態は、数える気にもならないほどインターフェースをimplementしまくった、複雑怪奇クラスファイルの乱立ですよ。

もちろんドキュメントも上から下のレイヤーまで、そのクラスの分だけ揃ってる。というか山のようにある。いやそれ分量的に読めねーから

ちなみに、今時の銀行大企業は、基幹システム一つだけなんて事は無いケースが多い。基幹システム複数あって相互通信する巨大システム群の中の一つに過ぎなかったり。

そこで基幹システムだけ今風に作り直した所で、コスト増大の根本原因である複雑さの解消に、微塵も貢献しているとは思えないのだが、その質問ダメらしい。


もうさ、ぶっちゃけちゃうと、そもそも人間という柔軟な脳を持つ生き物がこなしている業務を、人間より正確かもしれないけど全く融通が効かないコンピュータ代替することが限界なんじゃね?と思うんだわ。

基幹システムを見ていると、そんな暗澹たる気分になる。

そりゃCOBOL汎用機しか選択肢のなかった時代から比べて、今は色んなソリューションソフトウェアがある。どれもシンプルに造るため、分かりやすく造るためにある。

しかしこの国の基幹システムは、それでもなお複雑さを解消していない。

あるいは、そういう大きなシステムを抱えている日本組織性の問題なんですかね?

だったらそんな組織爆発しろと暴論を吐いてみる。

爆発しなくてもいいから、Google辺りに生息している本物のプログラマが、そういう複雑さを一気に解決するような、黒船もびっくりなソリューションで、今のITゼネコンありきのSI世界に風穴を開けてくれることを切に願う。

それこそ、ミッドウェーのように日本側が大打撃を被るほうが未来は開けそうとか、終わってると思うけど仕方ない。

この世界発注者も受注者も色んな意味で疲れる存在なので。

2016-03-15

往年の名機「PC-98」未だに中古市場で根強い人気の理由

http://withnews.jp/article/f0160314001qq000000000000000W00b0901qq000013115A

てっきりクラシックゲームかなんかの用途だと思ったら違った。

オープンだったはずなのに、汎用機的な理由で求められるとは、面白いな。

2014-11-03

http://anond.hatelabo.jp/20141102225754

うん。分かる分かる。

過去に掠っただけの経験を盛って何とか面談相手のニーズ合致してますアピールをしなきゃならないこの苦しさ。

日本システム開発現場って無駄にギョームケイケンを求めすぎなんだよな。

どの現場も作ってるもんは画面の入力内容をRDBMSに保存して、画面やら帳票やらファイルに出力するだけ。

オンラインバッチ汎用機オープン系、この位の粒度経験がかぶってて、オブジェクト指向言語どれか一つ使いこなせりゃ別に現場に入ってから学習全然事足りるし、業務知識なんて販売管理やら在庫管理やらの一般的な業務システムの知識を本とかで仕込んでおいて後は現場で覚えりゃ十分。

必要なのは仕組みを作る能力、周りとすり合わせる能力だろ。

まるで、専門知識がなければ戦力にならないかのようにみんな面接してくるけど、どうせお前外部の人間にそこまで深くコミットした仕事させねーだろって思うわ。

ま、そもそも面接自体違法だけどな。

2014-10-21

http://anond.hatelabo.jp/20141020015159

からそりゃ昔手書きのが速いし正確だと本気で信じてた時代があるし、

話の流れを追ってなくて横レスだけど、1990年くらいのころに職場仕様書作成手書きからワープロに移行しようって話が持ち上がったけど、ベテラン仕事を増やすなって猛反対して流れたってことがあったね。

一人一台じゃなかったけどみんなPCとか汎用機の端末を使っていて、手書きよりワープロのほうが圧倒的に楽だとわかりそうなもんだけど、ワープロ編集する機械じゃなくて清書機だって思い込みがあったんだろうね。

2013-10-04

http://anond.hatelabo.jp/20131004211326

80年代はみんなそんな感じだったよねぇ。

今でも汎用機界隈はそんな感じなんじゃない?

2013-09-04

UPSCVCF

サーバ運用管理を10年少々やってる。

以下、確認しないで思い込みで書く。

停電対策として、UPS(UnstoppablePowerSupply)をつなぐんだけど、一定以上の年代の人(50代以上?汎用機経験してる人とか)は、必ずCVCFと呼ぶ。

CVCFってControlledVoltageControlledFrequencyかConstant~か知らんけど、要はコンセントの100V/50Hzを整える意味しかいから、それじゃ停電したときに役に立たないじゃんって思う。

昔は、AC電源の品質が低くて安定していなかったのか、それともコンピュータ側がきじゃくだったんだろうか。

UPSにも2種類あるようで、常にバッテリーを経由して電気を出力するものと、普段はAC直結で停電時のみ切り替えるものがあるらしい。

そうなると、前者はCVCF的な要素もあるわけで、CVCFと呼べなくもない。

ただ、おじさんたちは明らかに区別しないで呼んでるんだよな。

2013-02-21

http://anond.hatelabo.jp/20130221204530

PC汎用機だし始めから持ってるわけで、ゲーム用に4,5万のグラボ買って刺すと考えればそんなもんじゃね。

2013-01-26

想像はるかに超える高速性と安定性を持つWindows Server

想像はるかに超える高速性と安定性を持つWindows ServerをメインにWindowsLinuxハイブリッド環境インフラを構築

http://gihyo.jp/admin/serial/01/gloops/0001

たとえばWindows環境メリットの1つに,

IISASP.NET,そしてC#で書かれたアプリケーション

想像はるかに超える高速性を実現していることが挙げられます

そのうえ,安定して動作しているのです。

Javaを中心としたプラットフォームのものと比べると,

もう全然比較にならないぐらい安定していると感じています

【全ての分野においてWindows圧勝

東京証券取引所の基幹システムとして稼動するWindows

ttp://itpro.nikkeibp.co.jp/article/NEWS/20090609/331590/?SS=imgview&FD=-654674548

HPCでもダントツパフォーマンスをたたき出すWindows

ttp://cloud.watch.impress.co.jp/docs/interview/20101224_416025.html

Windows上で稼動するメインフレーム

ttp://wsmgr.jp.brothersoft.com/screenshot-50450.html

NASパフォーマンス比較テストWindowsLinuxを圧倒!!

ttp://www.flexense.com/documents/nas_performance_comparison.pdf

BDレコのOSはやはりWindowsだった!!

ttp://it.slashdot.jp/story/12/04/24/0052242/

【一方Linuxは…】

Linux Daily Topics:2011年9月2日 Kernel.orgがトロイの木馬の侵入被害に|gihyo.jp技術評論社

ttp://gihyo.jp/admin/clip/01/linux_dt/201109/02

Linux カーネルの基盤サイトクラッキングの被害に - japan.internet.com

ttp://japan.internet.com/webtech/20110902/2.html

Linux Daily Topics:2011年9月15日 狙われるLinux… 今度はLinux Foundationが標的に|gihyo.jp技術評論社

ttp://gihyo.jp/admin/clip/01/linux_dt/201109/15

Linux Daily Topics:2011年9月2日 Kernel.orgがトロイの木馬の侵入被害に|gihyo.jp技術評論社

ttp://gihyo.jp/admin/clip/01/linux_dt/201109/02

Linux カーネルの基盤サイトクラッキングの被害に - japan.internet.com

ttp://japan.internet.com/webtech/20110902/2.html

Linux Daily Topics:2011年9月15日 狙われるLinux… 今度はLinux Foundationが標的に|gihyo.jp技術評論社

ttp://gihyo.jp/admin/clip/01/linux_dt/201109/15

MySQL.comのWebサイト不正コード 闇市場root権限も販売か

ttp://www.itmedia.co.jp/news/articles/1109/27/news027.html

またもOSSプロジェクトが被害に! Wineプロジェクト不正侵入を発表 | エンタープライズ | マイコミジャーナル

ttp://journal.mycom.co.jp/news/2011/10/13/115/index.html

全く使用するメリットが見出せないLinux

・安定性・信頼性

 Linux

 フリーソフトであるLinuxの安定性・信頼性はハッキリ言って問題外。

 1日連続で稼動させることすら困難。

 Windows

 いまやWindowsの安定性・信頼性はメインフレーム(汎用機)をも凌ぐ。

 世界中メインフレームが全てWindowsServerに置き換わったのがその証拠。

脆弱性

 Linux()

 Linuxで稼動している世界中サーバークラックされまくっている。

 シェアが全くないLinuxウイルス対策ソフトも皆無。

 Windows

 デフォルトスタンダードOSとしてあらゆる攻撃を受けてきたWindowsはいまや世界で一番強固なOSとなった。

 豊富ウイルス対策ソフトもさりながら、カーネル構造的に絶対に外部からクラックされることが無いOSとなった。

コスト

 Linux

 フリーソフトなのでOS無料

 しかし上記内容により安定稼動させるのはほぼ不可能。

 またサポート存在しないため自前で何とかするしかなくかえってコスト高となる。

 Windows

 OS無料ではないが従来のメインフレームOS比較すると安価

 もともと安定性に優れたOSであるため、誰にでも安定稼動させることが容易である

 サポート面もマイクロソフトを始め、各ベンダー完璧サポートを行える体制となっている。

 またコンピュータOSとしてほぼ100%のシェアを誇っているので情報豊富である

2012-12-05

なんか毎日楽しくねーなー面白いことねーかなーとか思ってたんだけども、
 ある店長ブログを見ててその理由に気が付いた。

人とのコミュニケーションほとんど放棄しているからなんだ、と。

いやあの修羅場真っ只中の状況を見て面白そうとか楽しそうとか思っちゃうあたり
 どこの自宅警備員か事務系公務員か(事務系とジム系って似てるよね量産汎用機的な意味合いで
 ってなもんだけど、そして本当にあのブログ通りの会話がなされたのかはともかくとして、

打てば響く会話ってやっぱり楽しい面白いよね。

からみんなキャッチボールを続けるためにテレビ見たり流行に乗ったりするのか。
 最低でも試合に備えてバッティングセンターに通うのはありでも、
 試合どころか野球する気もないのにバット振っててもそりゃ面白くないし飽きるわなー。

といって話したい内容も主張したい思想もないけど、
そこで自己完結せずにもう少し誰かに届くように外向きの思考してみようと思いました、まる。

2012-09-02

http://anond.hatelabo.jp/20120902135130

汎用機器で済ませれるのはiPadどころかタブレット特有の話ではなく

PCというのが元からそういうコンセプトだろ

アーカイブ ヘルプ
ログイン ユーザー登録
ようこそ ゲスト さん