オープンソースビジネスの挑戦と現実｜Rui Ueyama

2023/06/07 625 users 現実 挑戦

いい感じのオープンソース・ソフトウェアを書いて、それを元に起業することを考えてみたことがある人は結構いるようだ。実際に僕はここ1年半ほど、自作のオープンソース・ソフトウェアを元にビジネスを立ち上げようと試行錯誤してきた。その経験についてここでシェアしてみようと思う。 あらすじ薄々予期していたことで... 続きを読む

IPv6がなぜいまだに普及していないのか｜Rui Ueyama｜note

2019/11/04 865 users プロトコル Note パケット 欠点 IPv6

現在のインターネットの基本をなしているIPv4というプロトコルには、広く知られた大きな欠点がある。パケットのアドレスフィールドの幅が32ビットなので、ネットワークに接続可能なホスト数の上限が2³²（約43億）になってしまっているのだ。その欠点を修正するために、1990年代後半にIPv6という新たなプロトコルが設計さ... 続きを読む

オープンソース活動がフルタイムの仕事になる仕組みの話｜Rui Ueyama｜note

2018/11/01 606 users アップル ソニー プロダクト Note 反応

僕の仕事をひとに説明するときに、「Googleで仕事をしているけどオープンソースなのでGoogleのプロダクトを作っているわけではないし、むしろアップルとかソニーの人と一緒に仕事している」と言うと、「？？？」という反応になることが多いので、僕はこういう仕事をしているんだよということをここでちょっと説明してみ... 続きを読む

「悪い方が良い」原則と僕の体験談｜Rui Ueyama｜note

2018/04/06 999 users Note 原則 リンカ lld コンパイラ

ソフトウェアの世界には 「悪い方が良い」原則 という有名なエッセイがある。キレイにレイヤ分けされた一貫性のある良いデザインよりも、一見手抜きの悪いデザインのほうが実は良いときもあるという話だ。この逆説的なデザイン原則を僕は身をもって体験したことがある。それについてちょっと書いてみようと思う。 僕はlldというリンカのオリジナルの作者だ。リンカというのはコンパイラと組み合わせて使うもので、実行ファイ... 続きを読む

メモリのエラーとセキュリティの話｜Rui Ueyama｜note

2017/11/20 680 users Note メモリ エラー セキュリティ メモリエラー

ハードウェアのエラーでメモリの内容が化けてしまうことがごく稀にある。大抵のDRAMエラーはプログラムがクラッシュする結果になるだけだが、稀にデータ破壊になることもあるし、悪意のある使い方をすればセキュリティ破りに使うこともできてしまう。ここではメモリエラーとセキュリティの話をしようと思う。 メモリのエラー率は意外なほど高い。データセンターで大規模なマシン群を対象に 実際に観測 したところ、1年間に... 続きを読む

オーバーフローが引き起こした面白いバグの話｜Rui Ueyama｜note

2017/11/17 541 users 空中 Note パク ロケット 数値

一度聞いたら忘れられないような印象深いバグというものがある。僕は数値のオーバーフローと聞くと必ずこの2つのバグを思い出してしまう。どちらも面白いエピソードなのでちょっと紹介してみよう。 一つ目は、Ariane 5ロケットの初回テスト打ち上げ時に発覚したバグである。この事例では、ロケット打ち上げ数十秒後に制御プログラムが停止してロケットが進行方向に対して横を向いてしまい、空中分解して、400億円近く... 続きを読む

ソフトウェアの互換性と僕らの"User-Agent"文字列問題｜Rui Ueyama｜note

2017/11/15 690 users User-Agent リンカ アドホック lld Note

いろいろな環境で動くプログラムでは互換性のためにアドホックなことをしないといけないことがよくあるけど、歴史が積み重なってくると、アドホックな技の上にアドホックな技が積み上がる喜劇的な状態になることがある。こういう問題は認識するのは簡単だが直すことは誰にもできない。まさに僕がそのような体験をしたのでちょっと説明したい。 僕は仕事としてオープンソースのlldというリンカを書いている。リンカというのはコ... 続きを読む

絵文字がある種のUnicodeバグを世界から一掃しつつある件について｜Rui Ueyama｜note

2017/11/13 1446 users Note unicode UTF 絵文字 プログラム

UnicodeのUTF-16エンコーディングではほとんどの文字（コードポイント）は2バイトで表現されるが、Unicodeに後から追加収録された文字の多くは4バイトで表現される。4バイト文字がうまく扱えないプログラムというのはわりとよくある。しかし世界中で広く使われるようになった絵文字がよりによって4バイト文字であるせいで、そのような文字が扱えない問題がよいペースで解決に向かいつつある。それについて... 続きを読む

「プログラミングの常識」を時々見直す必要性について｜Rui Ueyama｜note

2017/11/02 1011 users Note プログラミング 常識 血道 window

自分の中のプログラミングの常識というものは、ときどき現実のハードウェアに合わせて調節しないといけない。ハードウェアが進歩し続けているので、コンピュータで簡単にできることと相対的に難しいことのバランスが変化し続けているからだ。ここでは特にストレージにフォーカスして書こうと思う。 昔はメモリが相対的にとても貴重な資源だったので多くのプログラマがメモリを節約することに血道を上げていた。例えばWindow... 続きを読む

スタンフォードのコンピュータサイエンスの授業の感想｜Rui Ueyama｜note

2017/04/06 564 users スタンフォード Note Itanium レジスタ コンパイラ

いまのところ25単位分（マスター修了に必要な単位数の約半分）の授業を取ったので感想を時系列でちょっとまとめたい。昔のやつは記憶が曖昧になっているけど。 CS 243 プログラムの解析と最適化 要するにコンパイラの最適化の授業。前半はデータフロー解析とかでかなり実用的な感じがしたが、後半は行列計算の命令の依存関係を抽出してベクトル最適化とか、ItaniumみたいにレジスタのたくさんあるCPUでループ... 続きを読む

ソースコードって実際のところどういうふうに書いていますか？｜Rui Ueyama｜note

2016/07/15 588 users Note ソースコード 実際 ところ

一日中コードを書いているような私ですが、他の人の作業をつぶさに観察したことがあるわけでもないので、自分で当たり前だと思っているコーディングの方法が他の人にとってはそうではないこともあると思ってます。上手い人がどういうふうにしてプログラムを書いているのか知りたいんですよね。 逆に私はどういうふうに書いているかちょっとまとめてみました。自分はこうしている、というのがあったらぜひ教えてください。 まず私... 続きを読む