アカウント名:
パスワード:
産経新聞の記事 [sankei.co.jp] によると今日(11/27) 「Windows のソースコードを、日本国内で政府、大学、企業向けなどに限定して公開する方針を発表した。」ようです。
少なくとも、ソースの改変と再配布(有償無償のバリエーションはいろいろとあるだろうが)が可能で、フ
今日日ソースからMakeするやつなんてほとんどいない罠。 さらに、ソースを読むやつなんてほぼ皆無な罠。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
犯人は巨人ファンでA型で眼鏡をかけている -- あるハッカー
ソースコードの条件付き公開 (スコア:2, 参考になる)
Re:ソースコードの条件付き公開 (スコア:1)
少なくとも、ソースの改変と再配布(有償無償のバリエーションはいろいろとあるだろうが)が可能で、フ
Re:ソースコードの条件付き公開 (スコア:2, すばらしい洞察)
・セキュリティ/バグの事前監査と対策要求
・ミドルウェアなどの開発時の資料
それなりの意味はあると思うけど。違う?
独禁法裁判の処分の話とは違うからねえ。
目的はMicrosoftの力を殺ぐ事じゃない。
Re:ソースコードの条件付き公開 (スコア:3, すばらしい洞察)
「バックドア陰謀説の払拭」と「セキュリティ/バグの事前監査と対策要求」のためには,公開されたソースコードが客が実際に動かしているWindowsのものであることが確認でき
Re:ソースコードの条件付き公開 (スコア:0)
最低でも、Debianを一気にフルリビルドするぐらいの根性は必要ではないでしょうか。
# まぁ、XP とかのソースコードならきれいに整理されてる模様。
# Meは目も当てられない惨状のようですが。
Re:ソースコードの条件付き公開 (スコア:1)
結んでソースを参照して確認してまで
Windowsを使い続ける決断をするのであれば、
その環境を整えるのはセキュリティ担当者の
義務では(笑)?
わたしはそこまで金と手間が掛かるのなら、
代替手段を考えます。
オープンソースを採用するにしても同じ事。
ソースを閲覧できることをセキュリティが
高い要因のひとつに挙げるのであれば、
そのソースとバイナリの整合性を確保できる
ようにするべきで。
ソースが公開されていても自分でビルド
できないのであれば、「回避策」は打てても
「根本対策」は打てないですよね。
#「使うのをやめる」という根本策が打てるか。
Re:ソースコードの条件付き公開 (スコア:1, すばらしい洞察)
>できないのであれば、「回避策」は打てても
>「根本対策」は打てないですよね。
今日日ソースからMakeするやつなんてほとんどいない罠。
さらに、ソースを読むやつなんてほぼ皆無な罠。
ソースが読めることを利点に挙げてる人間の中で、
どれだけの人間がソースを読み、コードが書けるのだろうかね。
伝家の宝刀ってやつなんだろうが。
(本来の意味は「大事にしてるだけで役に立たない」)
#見られる環境にあることと、
#見て実際に確認することは全くの別問題。
#見て確認しなければ見られないのと同義。
Re:ソースコードの条件付き公開 (スコア:1)
公官庁なり私企業なりから、セキュリティ込みでシステム開発を請け負うところなら、Make くらいやる能力がないと困ると思うのですが。
そういう能力のない業者に発注してしまうとすれば、それは当然発注者の責任ですが。
Re:ソースコードの条件付き公開 (スコア:1, 参考になる)
> さらに、ソースを読むやつなんてほぼ皆無
ここ読んでる人々の中なら、それなりの割合で居るんじゃないかな?
ソース書く人ですらそれなりに多かろうに。
新しげな機能を使おうとすると文書化されてない場合が多くて困るんですが、
ソースが読めたおかげで理解できた、という経験も何度かあります。
確かに人の書いたソースは読みにくいこともあります(多い?)けど、
中には感動的なものもあり、幸運にしてそういうのにあたると非常に勉強になりますね。
Re:ソースコードの条件付き公開 (スコア:1)
(´д`;)
通常よりも確かに確認する必要があって? (スコア:2)
まぁ、その前段階で読める人集めるだけで予算通らないかも。
# 根拠なくてもなんとなくな最近
Copyright (c) 2001-2014 Parsley, All rights reserved.
Re:ソースコードの条件付き公開 (スコア:0)
他からも入れられるので省略。
#省略になってないって:-p
プログラムのソースを読むことと書くことは別物。
ソースを読めるが書けない人もいるし、書けるけど他人の書いた
ソースは読めない人もいる。
他人が読めないソースコードを書く人もいれば、すごい分かりやすい、
これからプログラミングを勉強する人は読んでおいたほうがい
Re:ソースコードの条件付き公開 (スコア:1)
> 力量なんて外部からはよくわからないけど、ソースコードを見れば一目瞭然
> なので、マイクロソフトが公開したソースコードをみて、マイクロソフトの
> プログラマたちの力量を測るにはもってこいだと思う。
んで、そのことにどういう意義が?
力量がある人が書いたソースでも、バグがないという保証にはならないし。
力量がわかったところで、酒の肴ぐらいにしかならないと思うのだが。
#ちなみに、DDKのサンプルやMFCなんかはソースが見れるんだけど、
#グループによってコーディングスタイルが違うっぽ。
#MFCのソースは比較的見やすいかな、と思ったり。
Re:ソースコードの条件付き公開 (スコア:0)
> 力量がある人が書いたソースでも、バグがないという保証にはならないし。
> 力量がわかったところで、酒の肴ぐらいにしかならないと思うのだが
品質評価として大いに意義はあると思うが。
ぐちゃぐちゃなプログラムはバグも多いから、そういう開発チームが作っている
製品は避けることができる。
も
Re:ソースコードの条件付き公開 (スコア:1)
> ぐちゃぐちゃなプログラムはバグも多いから、そういう開発チームが作っている
> 製品は避けることができる。
> もちろん逆にきれいなプログラムならバグも少ないし、あっても潰すのが簡単。
きれいなプログラムにバグが少ない、という点には同意するけど、
製品にバグが少ないかどうか、ってのは別問題だと思う。
きれいに見えるコードでも、設計がだめぽだったら穴だらけ、ってことになりうるし、
逆にソースが汚くても、苦心惨憺の末バグがつぶされてる、ってのはあると思う。
そのコードを書いた人の力量を評価することはできるけど、
製品にかかわる人ってコードを書く人だけじゃないから、
製品全体の評価はできないんじゃないかな?
> #サンプルソースは見せるためのソースだからきれいなのは当然。
> #実際に使われているソースがどうなのかは別問題と思ったり。
#ちゃうよ。MFCのほうは(多分)サンプルじゃない。
#逆にDDKのサンプルのほうは目も当てらんないのがあったりする。