パスワードを忘れた？ アカウント作成
Close
7097 story

マイクロソフト、6大学の研究グループにソースコードを公開 97

ストーリー by GetSet
MSサンタからのプレゼント 部門より

nekopon 曰く、 "マイクロソフトが、東京大など6つの大学で構成する研究プロジェクトに対し、 Windows を含むマイクロソフト製品のソースコードを公開することになった。シェアードソースイニシアティブの適用例としては、国内では初の事例となる(マイクロソフトのプレスリリース) (インプレスの Enterprise Watch の記事)
対象となる研究プロジェクトは、文部科学省科学研究補助金特定領域研究「社会基盤としてのセキュアコンピューティングの実現方式の研究」で、慶應義塾大学・東京工業大学・東京大学・東京理科大学・筑波大学・北陸先端科学技術大学院大学の6大学が参加している。研究対象は悪意あるプログラムやコンピュータウイルスへの対策、なりすましへの対応とのことで、暗号は含まれていない。公開対象となるソースコードは、他社製品である部分、および認証などのクリティカルな部分を除く、ほとんどの製品のコードという。
研究領域の年限が2004年3月なので、時間はあまりないのかもしれない(継続されるかもしれないが不明確だ)とはいえ、ネットワーク基盤の一部である Windows が、少しでも頑健になっていけば、それだけネットワークの安全性も向上するはずだ。注意深く見守りたい。"

この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。

マイクロソフト、6大学の研究グループにソースコードを公開 More

  • ソースを見てしまったからには (スコア:2, 興味深い)

    by Anonymous Coward on 2003年12月19日 10時35分 (#457905)
    ６大学の教員・生徒は他のＯＳの開発に関われないわけですかねぇ・・・
    そこがＭＳの狙いかもしれないのでAC

  • Who's Your Santa? (スコア:2, すばらしい洞察)

    by mgx_devil (17128) <{mgx_devil} {at} {yahoo.co.jp}> on 2003年12月19日 12時17分 (#457982) ホームページ 日記
    GetSet による 09:26 AM -- Friday December 19 2003 の投稿，
    MSサンタからのプレゼント 部門より．
    本家Poll [slashdot.org]より。
    MSさんは選択肢に無いですね。

  • 他社製品 (スコア:1, おもしろおかしい)

    by Anonymous Coward on 2003年12月19日 9時43分 (#457870)
    > 他社製品である部分を除くほとんどの製品のコード

    じゃあ殆ど公開されないんじゃ、と私のアンチMS脳が反応しました。

  • おねがいします (スコア:1, 参考になる)

    by Anonymous Coward on 2003年12月19日 9時49分 (#457873)
    mshtml.dllを使わないOutlook Expressを作ってください。
    # じつはこれだけで世のウィルスの大半が活動不能だったり。
  • 新聞が好んで使う「設計図」という表現が気持ち悪い。
    「ソースコード」は「ソースコード」でいいじゃないか。
    「オペレーティングシステム」は「オペレーティングシステム」でいいじゃないか。
    「基本ソフト」なんて気持ち悪すぎて新聞を放り投げだしたくなる。
    ギョーカイで絶対に使用しないような表現を、どうして新聞は金科玉条のように使うのか、
    なんかおかしいと思うんだけど。
    それともJISかなんかでちゃんと定義されたという正当性でもあるのか?
    (俺はそこまでは調べてない)
    • >それともJISかなんかでちゃんと定義されたという正当性でもあるのか?
      少なくとも「基本ソフトウェア」についてはその通りです。JIS X 0001の01.04.02。
      シェア
      親コメント

    • あはは。自分にとっては、
      設計図∈ソースコード
      です。仕様が変わるのに備えて、柔軟に設計していますよ :P。

      しかし、大学に研究をさせるのに、Windowsの仕様書を渡さずにソースコード
      だけを渡すということは考えにくいので、設計図だろうが仕様書だろうが、研究側の
      需要があってライセンス的に問題ないなら、それらの一部も供与するのでは
      ないでしょうか？

      シェア
      親コメント
    • UML のことを指しているとしたら、あながち外しているとも 思えん。 あれは図ではあるけど、そのまま独立したオブジェクト指向言語という 感じもするし。
      # UML がそのまま動く処理系募集。
      --
      -- 哀れな日本人専用(sorry Japanese only) --
      シェア
      親コメント
      • CNET Japan に掲載されてた江島健太郎の非ユークリッド幾何学の歴史とソフトウェア工学の進化（後編） [cnet.com]によると、

        ＞ UMLが実際に行ったのはポンチ絵の描き方を緩やかに標準化した程度のこと

        だそうな。
        ソフトウェア工学をメッタ切りしてます。

        # でも思わず「まあ、そんなもんだよなぁ」と思ってしまったり。
        --
        *-----------------------*
        -- ウソ八百検索エンジン --
        シェア
        親コメント
      • >あれは図ではあるけど、そのまま独立したオブジェクト指向言語という感じもするし。

        オブジェクト(つーかクラス)の「ある側面」の情報を記述できるだけなんですよね、UMLって。
        プログラムとして振舞うための充分な情報を与える手段が、結局、(少なくとも今は)無い。

        それどころか仕様書として振舞う(?)ための充分な情報すら書けない節がある。
        おかげで、仕様書として使おうとしたらnote(コメント)まみれになるのが今のUMLの姿です(^^;
        ＃プログラム言語としてはそもそも全く動かないので、「使った」ことは有りません。

        あとUMLが痛いのは絵を濫用してるって点。アイコン濫用と同じでして、
        少しづつしか違わない多数の図形種を的確に区別するのは、人間の目にとってなかなか骨です。
        もっと図形種が少ない言語だったら「読み書き」しやすかったんでしょうけど、
        今のアレは多すぎます。文字言語に対するアドバンテージが殆ど無い。

        ま、逆にいえば、あれだけ多彩な機能を有するUMLですが、実際人間にとって使い物になるのは
        そのうちの一部でしかない、って感じを受けてます。＃C++に似てるなあ(藁
        あと、方言っていうか「崩し」をしないと、やってけんっていう感じも、かなり受けています。

        UML図を「動かし」たくなる理由の1つとして、描くのにそれだけ「苦労」を要するから、
        投入した労力を「回収」したいという欲求が当然発生する、って面が有るんだと思っています。
        が、だとすればそれに対する回答はシンプルです。「UMLを使った時点で敗北です」。
        ＃少なくとも、現状の多くの使いにくいUMLツールや、

        そういえば、 MartinFowler blikiに、UML Modeっていう話が有る [capsctrl.que.jp]ようです。
        UMLとの付き合い方で、人のモードを3種に分類する話らしい。

        ># UML がそのまま動く処理系募集。

        現状は無理でしょうね。

        勿論、アクションを直接書けないという今(今度出るというアレじゃなく)のUMLの根本的問題も有りますが、
        それ以前の問題も色々感じます。こまごまとしたところで、アレも足りないコレも足りないって感じ。

        個人的に思うのは、UMLを一通り描いたらプログラムに必要な情報も一通り描いたことになる、
        なんてな誤解を設計者とかがすることは、断じて避けて欲しい、ってことです。
        それで泣くのはその設計を受け取った実装者なのですから(T_T)

        ＃泣いてるのでG7。
        ＃ま、そういう辺りを判ってない奴に書かせれば、UMLであろうがなかろうが、そういう点で突っ込み所満載な仕様書を書くんだけどさ。

        ところで、

        |class X|

        |class A|
        |--- |
        |x:X |

        |class B|
        |--- |
        |x:X |

        みたいなUMLクラス図を書けますが、この場合のAとBのxが「同一の」インスタンスになるのか、
        それとも別インスタンスなのか、を、UMLではどこに書けるんでしたっけ？＃Note不可でね。
        まさか、この程度のことも書く手段が無い、なんて言いませんよね？

        こういうケースは、「ある程度以上汎用性のある」クラスをあちこちで使いまわすときに頻発するわけですが…
        どう描いたらいいんでしたっけ？

        個人的には、プログラムの「静的構造」ってのは、(少なくとも)上記の点を書かないと
        全くもって表現したことにならないと思っています。
        だって、さもないと、つまり静的構造を表現するためには「型」の関係だけしか記述しなくていいのだとすると、
        型なし言語には構造が全く無い、という(明らかに変な)話になっちゃう(^^;
        代入可能かどうかを表現しただけで「静的構造」を表現したことになる、なんてこたぁ無いと思うんです。
        クラスを1つづつバラバラに注目してる時ならばそれでもいいんですが、不味いことにUMLのクラス図は
        複数のクラスを(しかも「関連」込みで)描けてしまうんですよね。それこそ構造を表現するためにです。
        言い換えれば、(UMLの)クラス図だけじゃ、とてもじゃないが(静的)構造は表現できん…

        なお、この話は、オブジェクト指向にとっては物凄く初歩的な話であるはずです。
        あっちとこっちからインスタンスを共有するかどうか？なんてな話が「初歩的」であることは、
        オブジェクトが実際存在する状況を想像すれば、誰でも判るはず。

        なのに、 UMLの初歩を解説する本やwebページでは、この点についての言及をしてるものを
        とんと見たことが無い…
        (俺がUMLの仕様を見落としてる恐れはさておくとして(^^;)
        これはいったいどういうことなんでしょうね？

        これはもしかすると、「OOPの基本は、継承、隠蔽、多態だ」みたいな間違った(^^;教育の賜物なんじゃなかろか？
        そ
        シェア
        親コメント

  • 教育にはマイナス (スコア:1, 興味深い)

    by Anonymous Coward on 2003年12月19日 12時21分 (#457986)
    よいコードじゃなければ。

    • Re:教育にはマイナス (スコア:1, すばらしい洞察)

      by Anonymous Coward on 2003年12月19日 12時31分 (#457995)
      反面教師とか、人の振り見て我が振り直せという言葉もありますが。

      要は受け取る側の受信能力の問題さ。
      シェア
      親コメント

    • Re:教育にはマイナス (スコア:1, すばらしい洞察)

      by Anonymous Coward on 2003年12月19日 12時48分 (#458016)
      よいコードしか見たことない人間を誰が雇おうと思うものだろうか。
      シェア
      親コメント

      • Re:教育にはマイナス (スコア:1)

        by G7 (3009) on 2003年12月20日 17時53分 (#458735)
        >よいコードしか見たことない人間を誰が雇おうと思うものだろうか。

        わるいコードしか見たことない人間も、やはり使えません(^^;
        だって彼ら、理想が(現実に障害をもたらすほどに)低すぎるんだもん。

        ＃Cの型間違い警告は(常に)キャストで潰すもんだ、と長年信じてたらしい奴が居たので、困り果てたG7
        ＃そんな調子のそいつのソース、字面も内容も、もう汚いのなんのって…
        ＃仕事でC書くなら、最低でもK&R2くらい精読してから出直して欲しい。

        ----

        一方、たぶん「よいコードしか見たことない人間」は、わるいコードに出会ったら
        脳がコアダンプっつーか戦意を喪失するでしょうね。
        手の付けようが無い(書き直したほうが速い(けど大抵は時間とかが不足で無理))事を
        早々に悟ってしまうから。

        で、「それじゃ仕事にならない」というのならば、即ち
        「その仕事場の既存コードは、わるいコードである」ことを、
        認めてしまったようなものです。

        ま、それが現実だろうけど。

        ま、汚いコード持ちたければ勝手にすればいいといえばそれまでなんだけど、
        ただ恐らく、(企業にとっての)問題は、
        「わるいコード」をなんぼ書いて/保守しても、競争力は上がらない、ってことなんだよね。
        ＃巧く騙くらかせば利益だけは上がるのかも知れないが。
        それは技術的負債 [capsctrl.que.jp]でしかないんだよね。
        もちろん(ちょっとだけ)長い目で見れば、金銭的にも負担になるでしょうし。
        シェア
        親コメント
  • 早稲田・明治・慶應義塾・法政・立教・東京

    の6つじゃないのか。
    （順番は2003年秋季リーグ戦の結果 [big6.gr.jp]による）
typodupeerror

日本発のオープンソースソフトウェアは42件 -- ある官僚