オープンソースの誤解がよろしくない理由 - enbug diary (2008-03-21
_ オープンソースの誤解がよろしくない理由 まず前提として述べておきますが、 私は長年GNU Maintainerをやっていることからもわかるように、 フリーソフトウェアの熱烈な支持者です。 趣味で話すときにオープンソースという言葉を使うことは、 せいぜい相手に合わせたいときだけです。 オープンソースはビジネス用語と割り切ってます。 さて、 う めだもちおは DISられるべきなの? に私なりのコメントをしておきます。 なぜオープンソースの妙な認識を広められると困るのか。 それはもちろん本来同じオープンソースであるべきものが、 誰かが広めたおかしな定義に基づいて、 「それはオープンソース的でない」とか、 わけのわからない批判が現れるからです。 勝手に決めた視野の狭い定義にしたがって、 オープンソースの守備範囲を狭めることは、 百害あって一利なしです。 古くは GNU Deluxe Distr
enbug diary(2008-03-15) 目からうろこが何枚も落ちたオープンソースの“人間的本質”
_ 著作権の供託補償金 質問されたけれど、私にはよくわからないので、 もし誰か知っていたら教えてください。 著作権法 第八節 裁定による著作物の利用: 第六十七条 公表された著作物又は相当期間にわたり公衆に提供され、若しくは提示されている事実が明らかである著作物は、著作権者の不明その他の理由により相当な努力を払つてもその著作権者と連絡することができないときは、文化庁長官の裁定を受け、かつ、通常の使用料の額に相当するものとして文化庁長官が定める額の補償金を著作権者のために供託して、その裁定に係る利用方法により利用することができる。 ここで言っている「補償金」というのは、もしも著作物の利用規定が明確に許諾されているような場合で、かつ、使用料を必要としないことが明示されている場合（例えば、GPL）でも、文化庁長官は補償金を徴収することが可能なのでしょうか。 本来無料で利用できることになっていた
enbug diary(2007-11-26)
_ What Every Programmer Should Know About Memory Ulrich Drepperの例の論文ですが、一通り読み終わりましたよ。 システム・デベロッパならこれぐらいのことは大体おさえておいてよ、 という程度の内容なので、特に新しいことは書いてませんが、 よくまとまっているので、こういう文書が手軽に入手できるようになったのは喜ばしいことです。昔は持ち運ぶのも苦労するような馬鹿高い書籍しかありませんでしたからね。 ちょっぴり面白かったのは、HTの活用法として、 prefetch専用のthreadを使うというところ。 これまで、HTって、パフォーマンスの向上にどう役立てることができるのか、よくわかりませんでしたが、確かにこれは悪くない発想。 しかし、頑張る量が多い割に効果が少ないんだよねえ。 まあ、何というか、ハードウェアで頑張っている人たちはすげーなあ
enbug diary(2007-08-15)
_ Rubyにも遂にお手軽外部イテレータ 個人的にはすごく嬉しいです。 _ エンジニアに勧める書籍三冊 エンジニアが読むべき書籍を三冊挙げるとしたら、何ですか？と尋ねられて、 せっかくなので、こっちにも書いておきます。 まず第一に、相手によって、私は返事を変えます。 相手が求めているもの、欠けているもの、すでに持っているもの、 そういったことが人それぞれ異なっているからです。 そこで、とりあえずこれぐらいの内容は抑えておいてほしい、という意味合いで挙げます。 構造化コンピュータ構成 ハードウェアの基本的な構造を理解するという意味で。 「パタヘネ」を勧める人も多いようですが、私自身はこっちしか読んでないので。 モダン オペレーティング システム またまたタネンバウム先生ですが、 OSの基礎を理解するという意味で。 ちなみに、私は昔の版である「OSの基礎と応用」を読んだ人間なので、 新しい版が
enbug diary(2007-02-18)
_ 継続、を説明できるかどうか試してみる zundaさんのメッセージ を見て、 継続って案外理解しにくいものなのかな？と感じたので、 自分なりに説明してみます。 実際に使ってみたら、あっさり理解できそうな気もしますが... 私自身の考え方は全般的にマシン寄りです。 プログラムがマシン上でどのように実行されるのか、 モデルが頭の中にあって、 それをベースに捉えます。 こういう考え方で継続を説明した例としては、 shiroさんのなんでも継続 がすでにありますが、 私なりの言葉で書いてみます。 例えば、古典的なチューリングマシンのようなものを考えます。 aとbを足して、cに入れる → cとdを掛けて、eに入れる 昔フローチャートで仕様を作って、 それでプログラムを書くなんてことが行われていたそうですが、 プログラムは上記のようにフローとして捉えることができます。 そして、そのフローは命令列によっ
enbug diary(2007-01-25) Lisp:S式の理由
_ Lisp:S式の理由 shiroさんがLispの拡張性について語っておられますが、 この点について、Lispが他の追随を許さないほど強力なのは全くもってその通りです。 ただ実用性という観点において、いくら原理的に可能であっても、 実装されていない機能ばかりで自分で作るものが多いと使わないんですよね、 大抵の人は。 時間もエネルギーも有限ですから。 例えば、最近の私はもはや名前つきパラメータのない処理系なんて使っていられない体になってしまってますが、 Schemeだと SRFI 89 として去年ようやく提案されたばかりで、 Gaucheでもまだ実装されていないのではないかと思います （違ったらごめんなさい）。 もちろん、作ろうと思えば理論的に可能なのだから、 自分で作ってしまえばよいという考え方もできます。 でも私はあんまりやりたいと思いません。 自分の関心はそこにはないので、 すでにサ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
