オープンソースビジネスの挑戦と現実｜Rui Ueyama
いい感じのオープンソース・ソフトウェアを書いて、それを元に起業することを考えてみたことがある人は結構いるようだ。実際に僕はここ1年半ほど、自作のオープンソース・ソフトウェアを元にビジネスを立ち上げようと試行錯誤してきた。その経験についてここでシェアしてみようと思う。 あらすじ薄々予期していたことではあったけれど、結論から言うと、そんなにはうまくいかなかった話ということになる。要点をまとめると次の通りだ。 「moldリンカ」というオープンソースのツールを開発して、それを元にビジネスを行おうとしていた そこそこ稼ぐことはできたものの、大きなリターンを得るのは難しかった ほとんどの企業はオープンソースを大々的に活用していても「無料のソフトウェア」にはお金を払うつもりはないし、払いたくても社内制度上できない 大きなリターンを得たいのならば、自作のオープンソース・ソフトウェアを元にサービスを立ち上げ
IPv6がなぜいまだに普及していないのか｜Rui Ueyama
現在のインターネットの基本をなしているIPv4というプロトコルには、広く知られた大きな欠点がある。パケットのアドレスフィールドの幅が32ビットなので、ネットワークに接続可能なホスト数の上限が2³²（約43億）になってしまっているのだ。その欠点を修正するために、1990年代後半にIPv6という新たなプロトコルが設計されたのだけど、いまだにインターネットではIPv6は少数派で、主流ではいまだにIPv4が使われている。 1990年代当時は、IPv6は規格を策定すれば比較的すぐに普及するはずで、それによってインターネットが抱えているアドレス枯渇の問題が解決されるという雰囲気だったように思う。1998年にタイムトラベルして、20年たってもまだIPv4を置き換えることに成功していないと当時の人のIPv6推進者たちに教えたら、多分すごくびっくりされるだろう。一体どうしてこんなに普及が遅れてしまったのだろ
オープンソース活動がフルタイムの仕事になる仕組みの話｜Rui Ueyama｜note
僕の仕事をひとに説明するときに、「Googleで仕事をしているけどオープンソースなのでGoogleのプロダクトを作っているわけではないし、むしろアップルとかソニーの人と一緒に仕事している」と言うと、「？？？」という反応になることが多いので、僕はこういう仕事をしているんだよということをここでちょっと説明してみようと思います。 （2016年の僕のFacebookの投稿の転載です。） 僕のいるチームはLanguage Platform Teamというところで、プログラミング言語や開発ツールの開発をしています。LPTの中にもいろいろ細かいチームが分かれているのですが、僕がいるのはC++チームで、Googleで主要開発言語になっているC++言語の開発環境を担当しています。 C++で開発をするときには、C++ツールチェインと呼ばれる一連のツールを使います。ツールチェインの一番大きなコンポーネントは、人
Cコンパイラ制作の夏期集中コースが思っていた以上にうまくいった話｜Rui Ueyama
2018年の夏に僕はセキュリティキャンプ（以下「セキュキャン」）というイベントでCコンパイラ作成コースの授業を行いました。授業はとてもうまくいったといってよいと思います。参加者は6人だったのですが、6人全員プログラミング技術がかなり飛躍的に向上したようですし、そのうち3人は期間中にセルフホスト（自分の書いているコンパイラで自分のコンパイラ自身をコンパイルできること）まで漕ぎ着けることができました。 この文章では、その授業をどのように僕が教えたのかということと、生徒にできるだけ多くのことを学んでもらって自信をつけてもらうために僕が何を気をつけていたのかという2つの点について説明します。 セキュキャンとはセキュキャンは5日間の合宿イベントで、学生を対象としてコンピュータセキュリティやプログラミングについて教えるというものです。いくつものコースが用意されているのですが、僕が受け持ったのは「集中コ
コンパイラに仕込まれた細工とシステムのセキュリティの話｜Rui Ueyama
コンパイラのソースには書いていないのにバイナリだけで代々伝わっていく情報というのがあって、それはコンピュータのセキュリティに大きく関わっている。ここではそれについて書いてみよう。 僕は8ccというCコンパイラをスクラッチから書いたことがあるのだけど、8ccには文字列を読む部分で、"\"の後に"n"がきたら"\n"という文字（改行文字）を読んだことにするという箇所がある。これはよく考えてみれば自己言及的になっていて、ソースコードの中に"\n"のASCIIコードが一体本当は何なのかという情報が含まれていない。しかしコンパイラをコンパイルするコンパイラからその情報が受け継がれるので、できたバイナリは改行文字をきちんと出力できる。つまり8ccの改行文字は何度セルフコンパイルしても最初に使ったGCC起源ということになる。 コンパイラは、改行文字の文字コードというレベルではなく、もっと大きな情報をバイ
もしコンパイラを全世界で同時にうっかり削除してしまったら、元の状態に復旧できるのだろうか？｜Rui Ueyama｜note
思考実験として、全世界の人が同時に、自分の持っているコンパイラやインタープリタなどの実行ファイルをうっかり全部消してしまったとしよう。そうするとそれ以降、ソースコードが残っていても、コンパイラ自身も含めてどのようなプログラムもコンパイルできなくなってしまう。この状況から人類は元のコンピュータ文明を復旧することができるのだろうか？ 僕は結論としては、かなり簡単に復旧できると思う。ここではその手順についてちょっと考えてみよう。 コンパイラのバイナリファイルが全部消えてしまった後、復旧のために目指すべきマイルストーンは、おそらくCコンパイラを元に戻すことになるだろう。Cで書かれたプログラムはOSやコンパイラ自身を含めてたくさんあるので、そこを起点にすれば、たくさんのプログラムを芋づる式に復旧していけるからだ。 ほとんどのCコンパイラはCかC++で書かれている。最近のGCCやClangは巨大かつC
エレベータに見るアルゴリズムの性能と公平性のバランス｜Rui Ueyama
現実世界でもコンピュータの中でも、何らかの性能指標だけを追求すると参加者にとって極端に不公平になってしまうことがある。例えばエレベータとHDDは共通点がありそうに思えないが、この2つは性能特性的にとてもよく似ていて、リーズナブルな性能と公平性を両立させるために同じ制御方法が使われている。これについてちょっと説明してみよう。 1基しかない場合のエレベータの動き方は単純だ。一度上に動き出すと、上で待ってる人や降りる人がいる限り上昇し続ける。同じように、一度下に動き出すと、下で待っている人や降りる人がいる限り下降し続ける。これ以外の動き方をするエレベータはまず存在しないので、これが唯一の制御方法のように思えるけど、別にこうしなければいけないというルールはない。 エレベータの平均待ち時間を最適化することを考えてみよう。そうすると、一方向に動き続ける代わりに、エレベータが現在存在する階に一番近い人の
ソフトウェアの互換性と僕らのUser-Agent文字列問題｜Rui Ueyama
いろいろな環境で動くプログラムでは互換性のためにその場しのぎのことをしないといけないことがよくあるけど、歴史が積み重なってくると、アドホックな技の上にアドホックな技が積み上がる喜劇的な状態になることがある。こういう問題は認識するのは簡単だが直すことは誰にもできない。まさに僕がそのような体験をしたのでちょっと説明したい。 僕は仕事としてオープンソースのlldというリンカを書いている。リンカというのはコンパイラが生成したバイナリファイルをつなぎ合わせて最終的な実行ファイルやDLLを作成するプログラムで、知らない人も多いと思うけど、何をコンパイルしても最後にはリンカが動いている。lldは既存プログラムより何倍も速くてビルドが早くなるというので最近は結構人気が高まっていて、FreeBSDなどのいくつかのOSが全面的にスイッチしようとしたり、あるいは大規模プロジェクト（Chromeや、どうもFire
絵文字がある種のUnicodeバグを世界から一掃しつつある件について｜Rui Ueyama
UnicodeのUTF-16エンコーディングではほとんどの文字（コードポイント）は2バイトで表現されるが、Unicodeに後から追加収録された文字の多くは4バイトで表現される。4バイト文字がうまく扱えないプログラムというのはわりとよくある。しかし世界中で広く使われるようになった絵文字がよりによって4バイト文字であるせいで、そのような文字が扱えない問題がよいペースで解決に向かいつつある。それについて少し説明してみようと思う。 Unicodeが80年代から90年代初頭にかけてデザインされたときの目標の一つは、Unicodeに含まれる文字数を65536個以内に収めることだった。現代の文章を実用的なレベルで表すためには、漢字などを含めてもそれだけの種類の文字があれば十分だと考えられたのだ。当然これは1文字を2バイトで表すことを念頭に置いていた。つまりコンピュータの揺籃期から当時に至るまで単純に英語
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
