与えよ、さらば求められん - What #yapcasia gave me : 404 Blog Not Found
2012年10月02日01:00 カテゴリYAPC::AsiaLove 与えよ、さらば求められん - What #yapcasia gave me そういえばentryがまだだった。 とりもあえずはスライドはこちら。 YAPC::Asia::2012 - Perl as a Foreign Language その二週間前のPycon JP 2021のキーノートの姉妹編になっているのであわせてどうぞ。 で、本題。How Perl Changed My Lifeから頂いた。なんでこんなことを書こうと思い立ったかというと、本日のはじまりがあまりに不愉快で、心を洗濯する必要を感じたからだ。 救いようなし <@tsuda 出版業界はどんなにマンガ喫茶や自炊代行サービス出てきても、こんな悪趣味なこと→avexnet.jp/index.html しないもんな。最近出版業界ってホントに大人でインテリな業界
Open Sources 2.0
Read it now on the O’Reilly learning platform with a 10-day free trial. O’Reilly members get unlimited access to books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers. Open Sources 2.0 is a collection of insightful and thought-provoking essays from today's technology leaders that continues painting the evolutionary picture that developed in the 1999
DeNA のオープンソースについて外から見て思うこと - 宇宙行きたい
完全に外部から見た感想なんだけど 「Arctic.js」公開時に色々揉めたけど、オープンソースにすることを会社が支援していることが印象的だった。 で、すぐに MIT に変更した時点で会社が支援してくれていることと、法務も含め柔軟に対応していると感じた。 JSX 公開で前回揉めたにも関わらず更にオープンソースに出すことによって、会社が挑戦的な事を続ける心意気があることを感じた。 って事で俺的には DeNA という会社に対しての好感度は少なくとも上がっている。 素直にそういうところはいいなぁと思う。
OSSライセンス関連情報：IPA 独立行政法人 情報処理推進機構
オープンソースソフトウエアのラインセンシングと IPR:Intellectual Property Right (知的財産権)についての情報です。 オープンソースライセンスの説明
glibcの歴史 - karasuyamatenguの日記
普段あまり意識しないしないlibcだが、カーネルの門番とも言える重要なコンポーネントだ。Linuxで標準のlibcはGNU libc、略してglibc。最近このglibcのsteering committeeが解散した。これをうけてlwn.netのJonathan Corbetがglibcの歴史をふりかえる。 http://lwn.net/SubscriberLink/488847/cb91a5cc3d179f3c/ とても良く書けている記事なので原文を読むことをすすめる。以下、面白いなと思ったところをいくつか紹介。 フォーク FSFのプロジェクト管理に嫌気がさしたLinux開発者が90年代前半にlibcをフォークしていたとは知らなかった。当時のディストロたちは「Linux libc」と呼ばれるバージョンを使っていたそうな。 90年代半ばからUlrich Drepperがこつこつ開発する。
GitHubのnew Page Generatorがヤバい - すぎゃーん日記
Instantly Beautiful Project Pages · GitHub プロジェクトページから、ボタン一発でオサレなプロジェクトページが作れるようになった。やばい。これはやばい。 試しに自分のdotfilesで作ってみた。 dotfiles by sugyan デザイン選択するだけで、サクっとこんなのが出来ちゃう。ヤバい。まじヤバい。 最初から結構種類があるし、どれもイカしていてカッコイイ。 今まで作った全リポジトリのProject Pageをコレ使って勢いで作ってみたくなっちゃうし、コレを有効活用するためにもっとツールとかライブラリとか書こう！って気になる。 GitHubすげーーー！
ffmpegとlibavの背景事情
ffmpegをインストールしようとしたら、なにやらちょうど一年前あたり、大規模なforkが起こったらしい。いまや、ffmpegとlibavに分裂している。forkは自由なソフトウェアではいたって普通の出来事だ。大抵の場合、開発者の間での意見の不一致により起こる自然な現象だ。自由なソフトウェアであれば、fork自体はそれほど悪いことではない。どちらも自由であるので、双方の開発者がIRCやMLで広角泡を飛ばしながら喧嘩しつつ、何事もなかったかのように相手のコードをこちらのコードベースにマージできる。なぜならば、どちらも自由なソフトウェアという共通点を持っているからだ。 しかし、ffmpegは、だいぶ巨大なソフトウェアだ。おそらく、現時点でこれ以上にでかい動画と音声のソフトウェアは、mplayerしかあるまい。mplayerはffmpegを包括しつつ、さらに変態的なことをしている。これについては
DeNAの罠にはまってモバゲーのアカウントを取得するはめに - ただのにっき(2012-01-25)
■ DeNAの罠にはまってモバゲーのアカウントを取得するはめに ※タイトルにはおおげさな表現が含まれています。 昨日の夕方、急にTwitterのタイムラインが賑やかになって、何ごとかと思ったら「DeNA、HTML5開発支援フレームワーク「Arctic.js」を オープンソースとして公開」が話題になっているのだった。タイトルだけみると良い話なんだけど、GitHubに公開されたライセンス(公開当初のlicence.txt)がひどくて、明らかにOSDの定めるオープンソースではない。というかむしろプロプライエタリと言っても良いシロモノ。そりゃ騒ぎになるわけだわ。 DeNAは昨年、奥一穂さんが「オープンソース開発者がDeNAを選ぶ理由」なんて発表をするくらい「親OSSな会社」というイメージを打ち出せていただけに、これはちょっと笑えない話だ。結果として数時間後にはMITライセンスが適用されて丸く収まっ
本の虫: リチャード・ストールマンは常に正しかった
Richard Stallman Was Right All Along 去年の年末頃、オバマ大統領はテロリストの容疑者を裁判や令状なしに拘束できる法に署名した。世界中で起こっている平和的なオキュパイ運動家は、権力者からテロリストだとレッテル貼りをされている。通信を監視するSOPAを成立させるような圧力もある。30年前、リチャード・ストールマンがGNUプロジェクトを立ち上げてからこのかた30年間、彼の極端な物の見方は、馬鹿げていてパラノイアじみていると嘲笑されたものだ。しかし、この2012年において、パラノイアだと思われていた予測が、現実のものになろうとしている。 ごく最近まで、リチャード・ストールマンを世間離れしたパラノイアの狂人だと一笑に付すことは簡単であった。まあ、いってみれば、奴は古臭いコンピューターヒッピーだ。地下室に引きこもって自分の世界に浸っているパソコンオタクだ。あのヒゲ、
)
オープン ソース、オープンな標準にマイクロソフトはどう取り組んでいるか
丸山 ラベリノ氏はマイクロソフトでオープン ソース担当だと聞きました。どのような経歴を経て、いまのポジションになったのでしょうか? ラベリノ 私はこれまでずっとオープン ソースに関わってきました。Linux が公開された頃から関わってきたので、もう 20 年にもなります。 ビジネスの面ではオープン ソースを重視する企業で働いたり、ヨーロッパで会社を設立したりもしてきましたし、私が心から大事だと思っているオープン ソースのコミュニティにもずっと関わってきています。アパッチ ソフトウェア財団のバイスプレジデントでもあります。私は、いまの自分があるのはオープン ソースのおかげだと思って、とても感謝しています。 そうした経歴の自分に、ある日マイクロソフトから電話がかかってきました。オープン ソース コミュニティ担当のシニア ディレクターにならないか、という話でした。「それってどういう意味?」と聞き
MSのオープンソース取組（対談）、Roslynの舞台裏
今日は2件ほど。 オープン ソース、オープンな標準にマイクロソフトはどう取り組んでいるか オープン ソース、オープンな標準にマイクロソフトはどう取り組んでいるか なかなかいい内容の対談だった。一部、特に気に入ったところを引用。 ラベリノ： いいご質問ですね。例えばクラウドにおけるオープン性を考えると、単にそのクラウドのコードを開示しているだけでは十分ではありませんよね。クラウドでアプリケーションを運用することを考えると、データをそこにロックインされたくないからデータ用の API やデータ フォーマットの標準も欲しい。 だからオープン性にはさまざまな要素があって、オープンな API、オープン プロトコル、オープンな標準、そしてオープン ソース。この 4 つが柱です。けれどもどんなときにもこのすべてが必要というわけではありません。顧客がロックインされないためになにが必要か、というのはそれぞれ役
binutils にパッチ投げてみた話 - 兼雑記
Mach-O バイナリをコード見ながら逆アセンブルする方法が無いってのがずっと困っていました。つまり linux でよくやっている objdump -S みたいなことがやりたかったんですが、 objdump -S は Mach-O に対しては動かないし、 otool -tvV もソースコードは見せてくれないし、っていう。でまぁ一念発起して binutils というか libbfd をいじってみたのでした。 今回はじめて FSF なソフトに patch 投げてみて、まぁ特に著作権の処理とかどのくらい時間かかるもんなのかよくわからなくて、こちらのかた以外にあまり体験談的なのが見つからなかったので、なんか書いていみようかと。 とりあえず適当にパッチ書き。経験上デカいパッチいきなり投げるヤツはうざがられるので、なんか小さめな目標で…ってことで objdump -S を .o に対してだけ動くような
仙石浩明の日記: 技術力が高い人こそ、ビジネスモデルの良し悪しにもっと敏感になるべき
先週参加した社外の飲み会 (私は飲めないので専らウーロン茶でしたが) で、 Linux ディストリビューションの開発や、 カーネル技術を売りにしたコンサルティングで有名な某社の カーネル技術者とお会いしました。 彼はいま伸び盛りの若手カーネル・ハッカーなのですが、 オープン・ソース・ソフトウェア (以下 OSS と略記) ビジネスについて熱く語ったり、 ディストリビューションをサポートし続ける使命感に燃えていたのが、 わたし的にはちょっと気になりまして、 ひとこと言いたくなってしまいました(お節介ですね ^^;)。 ディストリビューションのサポート体制 (カーネルのバグにも的確に即応できる体制) を維持し続けることによって、 多くの企業で Linux を安心して使ってもらうことができて、 それが OSS の発展につながるし、 それこそが自分の使命だと彼は考えているようでした。 それはそれで
タダ飯よりも素敵なものは - steps to phantasien
GitHub co-founder の Tom Preston-Werner (以下もじょ先生) が お仕事のコードも大半はオープンソースにしたほうがいい という話を書いている。 (@higepon の tweet で知った。) 同じような主張は、ビジネスとしてのオープンソースが隆盛を極めた 2000 年前後にもみられた。 時は流れ、今はソフトウェアそのものよりはアプリケーションやサービスをウェブ越しに売る時代。 ハイテク企業の前線もコード自身からデータやユーザの時間といったコード以外の部分に少しづつ軸足を移しつつある。 そうした企業は十年前とは異なる文脈でコードをオープンソースにしはじめた… というだいたいの背景を踏まえつつ読むと、もじょ先生の話は感慨深い。 もじょ先生はスタートアップの founder/CTO らしい立場でオープンソースの利点を説いている。 私はスタートアップ勤務でもな
コミュニケーション力向上に役立ったOSS活動 - Linux/Ruby 小崎資広氏
「スキルアップが図れるのはもちろんですが、私にとっては初対面の方とのコミュニケーションがとりやすくなるという点が大きいですね。OSSコミュニティでアウトプットしておくことで、それが話題の1つになります。込み入った説明が必要なときには、『Google先生に聞いてください』なんてかたちで済ませられたりもします(笑)」――LinuxカーネルおよびRubyのコミッターとして著名な小崎資広氏は、OSSコミュニティでの活動メリットをこのように語る。 小崎氏は、富士通 Linuxソフトウェア開発統括部に所属するエンジニア。LinuxカーネルとRubyの2つのコミュニティで活発に活動しており、その名は世界的に知られている。2009年には日本OSS貢献者賞を受賞。@ITでは連載「Linux Kernel Watch」を執筆し、Linuxカーネルのメーリングリストで熱く議論されているトピックスを紹介している。
GitHub時代のオープンソース・プロジェクトとの付き合い方
■ GitHub時代のオープンソース・プロジェクトとの付き合い方 GitHubへpull requestする際のベストプラクティスからmaster ブランチで pull request していいのは小学生までってこともないの流れを読んでいて、先日ruby-listであったRedmineのRuby1.9,Rails3対応の話を思い出した。あのときは投稿者は納得して、「GitHub時代のコントリビューションの仕方」みたいなものを理解してくれたようなのだけど、その上で「masterでパッチ作るな」的なお作法を生真面目に受け取りすぎて敷居を高く感じてしまわれても困るよなぁと思った。 そこで、「GitHub時代にフリー/オープンソース・ソフトウェア(以下FOSS)プロジェクトと付き合うための五ヶ条」的なものをまとめてみた。まぁ、そんな大それたものでもないけど。 1. 貢献しようと意気込まない FOS
master ブランチで pull request していいのは小学生までってこともない - HsbtDiary(2011-06-16)
■ [git][github][tDiary] master ブランチで pull request していいのは小学生までってこともない GitHubへpull requestする際のベストプラクティス - hnwの日記を読んで感じたこと。 このエントリではmasterブランチで pull request していいのは小学生までと言われているけど、少なくとも tDiary ではどうでも良いからパッチ送れとしか思わないなあ。 具体的には master ブランチで作業したものを pull request しても別にコードの内容に問題がなければがんがん取り込むし、コンフリクトがひどかったり、なんじゃこりゃというのは差し戻すのでパッチを投げる側は気にする必要はない。繰り返すけど、Gitのお作法よりもコードの内容の方が重要ってことを頭に置いた方が良い。 もちろん、件の記事のようにちゃんと Git を
LPI-Japanによるオープンソースデータベース技術者認定試験の名前を見直すべき5つの理由
前回のエントリでは、真のオープンソースとは何か？と題して、LPI-Japanがオープンソースの定義を間違えているという点を指摘した。今回はさらに別の角度から、この認定試験の名前を変更するべき理由について考えてみたい。 1. オープンソースなRDBMSはPostgreSQLだけじゃないオープンソースのRDBMSと言えば、日本ではMySQLとPostgreSQLが人気を二分している。*1Googleで検索された回数であれば、MySQLのほうがやや有利だろうか。Googleの検索回数が多いからそれがどうしたと言われそうだが、日本で認知されているオープンソースRDBMSがPostgreSQLだけではないことは確かだろう。 オープンソースなRDBMSということでMySQLが使われる機会は多い。従って、上司や顧客から 「君、OSS-DB認定試験を持ってるんだって？じゃあMySQLの構築頼むよ。」 と言
真のオープンソースとは何か？
@tmaesaka氏からのツイートで知ったのだが、LPI-Japanが見過ごすことが出来ない発言をしている。 PostgreSQL技術者を認定、LPI-Japanが「OSS-DB技術者認定試験」開始 - ITpro 以下、引用。 OSS-DBには、PostgreSQLと米OracleのMySQLがあるが、「特定ベンダーの管理下にあるソフトは真のOSSとは言えない」（LPI-Japanの成井弦理事長、写真）として、今回スタートするOSS-DB ExamではPostgreSQLのみを対象とした。 これはおかしなことだ。一体誰が「特定ベンダーの管理下にあるソフトはOSSではない」などと決めたのだろう？ MySQLはオープンソースソフトウェアです。MySQLはれっきとしたオープンソースソフトウェアだ。ただし、Community Editionに限る。MySQLはデュアルライセンスであり、GPL版と
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GitHubを自前で持てるRails製オープンソースソフトウェア「GitLab」:phpspot開発日誌