アカウント名:
パスワード:
「オープンソース」というのが、単に無料にしろ! という意味ならそれは可能かもしれないけど
派生、改善、バグフィクスとかは、ごく小規模のものしかできないと思うn百人年投資しているだろう、MS自身が積極的に関与するなら別だけど
Joel On Software私訳http://anond.hatelabo.jp/20080227113835 [hatelabo.jp]
青木さんの本にも同文の翻訳あります
Windowsアプリのデバッグ時に、デバッガに噛ませてWindows搭載ライブラリ内の該当行を表示するとか。ライブラリのコードが読めても役立たないかもしれませんし、私は(Gtk/Qtばかりで)VisualStudioでのWindowsアプリの開発経験がないので、それが役立つのかどうかわかりませんが。少なくとも、リードオンリで使う(コードを参照する)分には、役に立つ場合もありそうかな、という気はします。
もし、レイモンド・チェンのブログに書かれているような互換性Fixや、Joel on SoftwareのBillGレビューの時のような内容が、コード中コメントやドキュメント化されているなら、それはとても面白い読み物かもと思う。(でもきっとそうなってはいない)
VisualStudioだとCRTとかプログラミング言語に近い領域のライブラリはソースが提供されてて、特定の操作がWinAPIレベルでどう動作するのかとかは調べられるようになってますね。VC6とかの頃はOSのデバッグシンボルも付いてきてインストールすれば使えたらしいですが、こっちは触ってないのでよく分からず。今でもSDKとかDDKにはついてるんだろうか?あとマイクロソフトと契約することでソースコードを得られるって話も聞きますね。デバッグ向けのリードオンリなソース開示は意外とやってる方といえるかもしんない。
デバグシンボルは Microsoftのシンボルサーバからダウンロードできるようになってます.以前は設定が必要でしたけど今の Visual Studio だとメニューで選ぶだけでダウンロードしてきてくれますよ.
VisualStudioの「内部コンパイラエラー ファイル ***.c 行番号 NNN」はどうコケてんのか中を見せろと思うこと多々ありますが、Windows自体では直接そういう場面に遭遇しませんね。付属の純正ソフトやサードパーティ製ドライバなど、ソースをあらためたくなる悪ガキは大抵アプリ層。
ソースコードの公開は、オープンソースコミュニティへの丸投げと同義ではありませんよ。ソースコードは公開して自由に使っていい(修正して使ってもいい)けど、従来どおりメーカー(マイクロソフト)が一義的に開発を行なうというスタンスでも、十分に「オープンソース」が成り立ちます。
同意します。
でも、それをやると何故か、本来のオープンソースではないって言う人がいるんですよねえ。
そういう奴には、「オープンソース」という呼び方を考案したESRの「伽藍とバザール」を読め、と。
やるとすればスリム化過去の遺産とかごっそり削ってやる
過去の遺産を削ってしまうのであればWindowsである理由がないような…
うん??全くそんなことないと思うけど
どんな状況を想像してる???
後方互換性を重要視されている点が Windows の最大の利点だ、ということでしょう。
既存のドライバやらアプリケーションとの互換性を切り捨てるのならそもそもWindowsを使う理由が無いってことじゃない?MacでもLinuxでも好きなOS使えばいいじゃん
nLiteとかvLiteとか思い出します。OSASK/ReactOS/Linuxと並んで、私がこの業界にハマり込んだ、きっかけのひとつでした。
誰かがビルドシステムを整理して、カスタム項目一覧を付けたアプリを出したら、nLiteみたいな感じになるかも。
Windowsが重いのは巨大な互換ライブラリが原因ですからねぇ。それでいてWindowsのライブラリは流行の取り込みが遅く、柔軟性も低い(機能の拡張に制限がある)ので、結局は独自実装するか、オープンソースのライブラリが好まれている現状。
windowsは8年前のハードウェア、core2duo 2GHzにメモリ4GBでべつに重くはないですが、いったい何と比較しているんでしょう
あ、メモリは3GBしか認識してないのかな、アップルが捨てたmacbook 2006 lateですが
linuxと比べて、何やるにしても妙にディスクアクセスが多いせいか、待ち時間がすごくかかります。もちろん、同じハードウェア上での話です。
どっちもメモリへのキャッシュでごまかしているのでメモリが余っていればサクサクでふー。//空きメモリが減った時のことは考えないようにしております
プロセス起動のことでは。Windowsはプロセスの起動が遅いですね。理由はわかりませんが。Unix系ツールのような、小さなプロセスを多数起動するようなスタイルだと、遅さを感じます。
それは設計思想の違いによる物ですね。Windows はスレッド指向なので、そもそもプロセスを軽くすると言う考え方は少なかったんだと思います。UNIXのエミュレーションをやろうとすると辛いのは仕方の無い部分もあります。
シェイプアップならMicrosoftが頑張っていて成果も出ています。互換性の維持を目的として記述された部分とそうでない部分を読み分けるのは骨が折れるので止めて方が良いのでは?
逆だろ。
XPをオープンソース化して、代わりに本家は完全64bitOS化して過去の負債を切り捨てる。MSは足枷を外して未来に向かえるし、過去の遺産にしがみつく向きはオープンソース化されたXPをメンテできる限りいつまでも使える。「ぼくのかんがえたさいきょうのWindows」をフォークしたっていい(手間の割に合わないと思うが)。
Win-Winじゃね? Windowsだけに
そうだとしても、MSが単にオープンソースにコミットする [srad.jp]だけでなく、主力プロダクトのオープンソース化に言及するなんて隔世の感があります。
で、青木さんて誰?
訳者 [ohmsha.co.jp]
ソース公開したとき必死になって調べ始めるのは恐らく大半クラッカーだよねセキュリティ上の不安が増すだけだと思う
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
クラックを法規制強化で止められると思ってる奴は頭がおかしい -- あるアレゲ人
非常に複雑なソフトウェアはソース公開しても無意味 (スコア:5, 参考になる)
「オープンソース」というのが、単に無料にしろ! という意味ならそれは可能かもしれないけど
派生、改善、バグフィクスとかは、ごく小規模のものしかできないと思う
n百人年投資しているだろう、MS自身が積極的に関与するなら別だけど
Joel On Software私訳
http://anond.hatelabo.jp/20080227113835 [hatelabo.jp]
青木さんの本にも同文の翻訳あります
Re:非常に複雑なソフトウェアはソース公開しても無意味 (スコア:1)
Windowsアプリのデバッグ時に、デバッガに噛ませてWindows搭載ライブラリ内の該当行を表示するとか。
ライブラリのコードが読めても役立たないかもしれませんし、私は(Gtk/Qtばかりで)VisualStudioでのWindowsアプリの開発経験がないので、それが役立つのかどうかわかりませんが。
少なくとも、リードオンリで使う(コードを参照する)分には、役に立つ場合もありそうかな、という気はします。
もし、レイモンド・チェンのブログに書かれているような互換性Fixや、Joel on SoftwareのBillGレビューの時のような内容が、コード中コメントやドキュメント化されているなら、それはとても面白い読み物かもと思う。
(でもきっとそうなってはいない)
Re: (スコア:0)
VisualStudioだとCRTとかプログラミング言語に近い領域のライブラリはソースが提供されてて、
特定の操作がWinAPIレベルでどう動作するのかとかは調べられるようになってますね。
VC6とかの頃はOSのデバッグシンボルも付いてきてインストールすれば使えたらしいですが、
こっちは触ってないのでよく分からず。今でもSDKとかDDKにはついてるんだろうか?
あとマイクロソフトと契約することでソースコードを得られるって話も聞きますね。
デバッグ向けのリードオンリなソース開示は意外とやってる方といえるかもしんない。
Re:非常に複雑なソフトウェアはソース公開しても無意味 (スコア:3, 参考になる)
デバグシンボルは Microsoftのシンボルサーバからダウンロードできるようになってます.
以前は設定が必要でしたけど今の Visual Studio だとメニューで選ぶだけでダウンロードしてきてくれますよ.
Re: (スコア:0)
VisualStudioの「内部コンパイラエラー ファイル ***.c 行番号 NNN」は
どうコケてんのか中を見せろと思うこと多々ありますが、
Windows自体では直接そういう場面に遭遇しませんね。
付属の純正ソフトやサードパーティ製ドライバなど、
ソースをあらためたくなる悪ガキは大抵アプリ層。
Re:非常に複雑なソフトウェアはソース公開しても無意味 (スコア:1)
ソースコードの公開は、オープンソースコミュニティへの丸投げと同義ではありませんよ。
ソースコードは公開して自由に使っていい(修正して使ってもいい)けど、従来どおりメーカー(マイクロソフト)が一義的に開発を行なうというスタンスでも、十分に「オープンソース」が成り立ちます。
Re: (スコア:0)
同意します。
でも、それをやると何故か、本来のオープンソースではないって言う人がいるんですよねえ。
Re: (スコア:0)
そういう奴には、「オープンソース」という呼び方を考案したESRの「伽藍とバザール」を読め、と。
Re: (スコア:0)
やるとすればスリム化
過去の遺産とかごっそり削ってやる
Re:非常に複雑なソフトウェアはソース公開しても無意味 (スコア:1)
過去の遺産を削ってしまうのであればWindowsである理由がないような…
Re: (スコア:0)
うん??全くそんなことないと思うけど
どんな状況を想像してる???
Re: (スコア:0)
後方互換性を重要視されている点が Windows の最大の利点だ、ということでしょう。
Re: (スコア:0)
既存のドライバやらアプリケーションとの互換性を切り捨てるのなら
そもそもWindowsを使う理由が無いってことじゃない?
MacでもLinuxでも好きなOS使えばいいじゃん
Re:非常に複雑なソフトウェアはソース公開しても無意味 (スコア:1)
nLiteとかvLiteとか思い出します。
OSASK/ReactOS/Linuxと並んで、私がこの業界にハマり込んだ、きっかけのひとつでした。
誰かがビルドシステムを整理して、カスタム項目一覧を付けたアプリを出したら、nLiteみたいな感じになるかも。
Re: (スコア:0)
Windowsが重いのは巨大な互換ライブラリが原因ですからねぇ。
それでいてWindowsのライブラリは流行の取り込みが遅く、柔軟性も低い(機能の拡張に制限がある)ので、
結局は独自実装するか、オープンソースのライブラリが好まれている現状。
Re: (スコア:0)
windowsは8年前のハードウェア、core2duo 2GHzにメモリ4GBでべつに重くはないですが、いったい何と比較しているんでしょう
Re: (スコア:0)
あ、メモリは3GBしか認識してないのかな、アップルが捨てたmacbook 2006 lateですが
Re: (スコア:0)
Re: (スコア:0)
linuxと比べて、何やるにしても妙にディスクアクセスが多いせいか、待ち時間がすごくかかります。
もちろん、同じハードウェア上での話です。
Re: (スコア:0)
どっちもメモリへのキャッシュでごまかしているのでメモリが余っていればサクサクでふー。
//空きメモリが減った時のことは考えないようにしております
Re: (スコア:0)
プロセス起動のことでは。Windowsはプロセスの起動が遅いですね。理由はわかりませんが。
Unix系ツールのような、小さなプロセスを多数起動するようなスタイルだと、遅さを感じます。
Re:非常に複雑なソフトウェアはソース公開しても無意味 (スコア:1)
それは設計思想の違いによる物ですね。
Windows はスレッド指向なので、そもそもプロセスを軽くすると言う考え方は少なかったんだと思います。
UNIXのエミュレーションをやろうとすると辛いのは仕方の無い部分もあります。
Re: (スコア:0)
シェイプアップならMicrosoftが頑張っていて成果も出ています。
互換性の維持を目的として記述された部分とそうでない部分を読み分けるのは骨が折れるので止めて方が良いのでは?
Re: (スコア:0)
逆だろ。
XPをオープンソース化して、代わりに本家は完全64bitOS化して過去の負債を切り捨てる。
MSは足枷を外して未来に向かえるし、過去の遺産にしがみつく向きはオープンソース化されたXPをメンテできる限りいつまでも使える。「ぼくのかんがえたさいきょうのWindows」をフォークしたっていい(手間の割に合わないと思うが)。
Win-Winじゃね? Windowsだけに
Re: (スコア:0)
そうだとしても、MSが単にオープンソースにコミットする [srad.jp]だけでなく、
主力プロダクトのオープンソース化に言及するなんて隔世の感があります。
Re: (スコア:0)
Re: (スコア:0)
で、青木さんて誰?
Re: (スコア:0)
訳者 [ohmsha.co.jp]
Re: (スコア:0)
ソース公開したとき必死になって調べ始めるのは恐らく大半クラッカーだよね
セキュリティ上の不安が増すだけだと思う