タグ

ブックマーク / note.com/ruiu (10)

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

    現在のインターネットの基をなしているIPv4というプロトコルには、広く知られた大きな欠点がある。パケットのアドレスフィールドの幅が32ビットなので、ネットワークに接続可能なホスト数の上限が2³²(約43億)になってしまっているのだ。その欠点を修正するために、1990年代後半にIPv6という新たなプロトコルが設計されたのだけど、いまだにインターネットではIPv6は少数派で、主流ではいまだにIPv4が使われている。 1990年代当時は、IPv6は規格を策定すれば比較的すぐに普及するはずで、それによってインターネットが抱えているアドレス枯渇の問題が解決されるという雰囲気だったように思う。1998年にタイムトラベルして、20年たってもまだIPv4を置き換えることに成功していないと当時の人のIPv6推進者たちに教えたら、多分すごくびっくりされるだろう。一体どうしてこんなに普及が遅れてしまったのだろ

    IPv6がなぜいまだに普及していないのか|Rui Ueyama
    KoshianX
    KoshianX 2019/11/05
    結局上位互換じゃなかったのが問題なのかねえ。メジャーどころでも IPv6 に対応してるのは Google, Netflix, Facebook, Wikipedia くらいで Twitter すら対応してないんだよな……。
  • 意図的にプログラムの動きをランダムにしてバグを早期発見するテクニックについて|Rui Ueyama

    プログラムを書いていると、素直に実装した結果として毎回特定の条件が満たされているけど、来それは誰も保証してないという場面に出くわすことがよくある。保証されていない偶然の動作に依存することで生じるバグというのはかなり多い。 例えば最近では、ドラゴンボールZ ドッカンバトルというゲームで、2回SQL文を実行した結果が同じ順序で並んでいるという誤った期待をしているコードがあったせいで、ガチャの確率表示がめちゃくちゃになってしまって、運営が確率操作しているのではないかという騒動が発生したことがあった [1]。データベースでは空のテーブルにデータを追加してその直後に読み返すと、データを追加した順番に結果が返ってきたりしがちなので、問題のコードはきれいなテスト環境では偶然うまく動いてしまったのだろうと思う。 上のようなバグを防ぐために最近よく使われているのは、来保証しないところをわざと壊すという方

    意図的にプログラムの動きをランダムにしてバグを早期発見するテクニックについて|Rui Ueyama
    KoshianX
    KoshianX 2017/12/14
    仕様より処理系の挙動をつい優先しがちだからのう。たしかに有用な時もあるかもなあ
  • もしコンパイラを全世界で同時にうっかり削除してしまったら、元の状態に復旧できるのだろうか?|Rui Ueyama|note

    思考実験として、全世界の人が同時に、自分の持っているコンパイラやインタープリタなどの実行ファイルをうっかり全部消してしまったとしよう。そうするとそれ以降、ソースコードが残っていても、コンパイラ自身も含めてどのようなプログラムもコンパイルできなくなってしまう。この状況から人類は元のコンピュータ文明を復旧することができるのだろうか? 僕は結論としては、かなり簡単に復旧できると思う。ここではその手順についてちょっと考えてみよう。 コンパイラのバイナリファイルが全部消えてしまった後、復旧のために目指すべきマイルストーンは、おそらくCコンパイラを元に戻すことになるだろう。Cで書かれたプログラムはOSやコンパイラ自身を含めてたくさんあるので、そこを起点にすれば、たくさんのプログラムを芋づる式に復旧していけるからだ。 ほとんどのCコンパイラはCかC++で書かれている。最近のGCCやClangは巨大かつC

    もしコンパイラを全世界で同時にうっかり削除してしまったら、元の状態に復旧できるのだろうか?|Rui Ueyama|note
    KoshianX
    KoshianX 2017/12/06
    コンパイラ以外のソフトウェアが残ってるという条件なら Python あたりで C コンパイラ書いちゃう人がでてきそうな気がするなあと思って検索したら普通にすでにあったw
  • x + 0.25 - 0.25 = xが成り立たないxとは何か|Rui Ueyama

    スタンフォードのコンピュータサイエンスの授業で、ときどきこれは良問と思う問題がテストで出ることがある。僕の印象に残っているのは「xをfloatとするとき、x + 0.25 - 0.25 = xが成り立たないxを求めよ」というものだ。浮動小数点数を理解していないと、両辺が同じにならないケースがあるほうが不自然に思えるだろうから、この問題は浮動小数点数の奇妙さを結構うまく突いていると思う。この問題を元に浮動小数点数についてちょっと説明してみよう。 まずコンピュータ上での数について少し考えてみよう。コンピュータにおける数と、数学の整数や実数は、よく考えてみると全然違う。コンピュータは有限の記憶領域しか持っていないので、無数にある数を表すことが根的にできない。つまりコンピュータ上の数は「物の数になるべく似せた別の何か」だ。現実的には、例えば32ビットの数なら2^32パターンしか表せないので、そ

    x + 0.25 - 0.25 = xが成り立たないxとは何か|Rui Ueyama
    KoshianX
    KoshianX 2017/11/29
    コンピュータで小数点なんてできるだけ使わないで済ませたいものだねえ……。いやしかしこれホントにちゃんと理解してないと回答できないな……。
  • 乱数生成器とゲームと諜報活動の話|Rui Ueyama

    ゲームなどを作っているとランダムさが必要になることがあるけど、コンピュータは基的に毎回全く同じように動くので、乱数を作り出すのはそう簡単なことではない。Wi-FiやHTTPSなどの暗号は乱数のランダムさに質的に依存しているので、高品質な乱数生成は世の中的にも重要な話題である。ここでは乱数生成について話をしてみよう。 ゲームではイベントがプレイヤーに予測不可能であればよいだけなので、真の乱数列ではなく擬似乱数列というものを使うことが多い。擬似乱数列は人間にはランダムにみえるけど、実際は何らかの数式によって順番に生成されているだけの数の列で、初期値を毎回違うものにしておくと、人間には毎回違う数列が生成されるようにみえる。初期値には現在時刻を使うことが多い。現在時刻は普通の用途では毎回違うからだ。 昔のゲーム機は現在時刻の設定がなかったので、ファミコンなどでは、起動してからの経過時間を疑似乱

    乱数生成器とゲームと諜報活動の話|Rui Ueyama
    KoshianX
    KoshianX 2017/11/22
    RDRAND知らなかったなー。中国とかじゃなくてアメリカの機関がやってるあたりが本当にいろいろと信用ならんよなあ……。
  • メモリのビット反転エラーとセキュリティの話|Rui Ueyama

    ハードウェアのエラーでメモリの内容が化けてしまうことが稀にある。大抵のDRAMエラーはせいぜいプログラムがクラッシュする結果になるだけだが、データ破壊になることもありえるし、悪意のある使い方をすればセキュリティ破りに使うこともできてしまう。ここではメモリエラーとセキュリティの話をしようと思う。 メモリのエラー率は意外なほど高い。データセンターで大規模なマシン群を対象に実際に観測したところ、1年間に1回以上のエラーが発生したDIMMモジュールは全体の8%にのぼったそうだ。DIMM 1枚に数百億個のメモリセルが実装されているといっても、このエラー率はちょっとびっくりするくらい大きな数字ではないだろうか? サーバでは普通はエラー訂正付きのDIMMを使うので1ビットのエラーは問題にならないが、エラー訂正のないコンシューマ機器ではこれは実際的な問題になりえる。 メモリエラーを利用したセキュリティ破り

    メモリのビット反転エラーとセキュリティの話|Rui Ueyama
    KoshianX
    KoshianX 2017/11/22
    ほおお、ごくごくわずかな確率でもユーザー数が膨大だと踏むやつも出てくるわけね。なるほど。
  • ソフトウェアの互換性と僕らのUser-Agent文字列問題|Rui Ueyama

    いろいろな環境で動くプログラムでは互換性のためにその場しのぎのことをしないといけないことがよくあるけど、歴史が積み重なってくると、アドホックな技の上にアドホックな技が積み上がる喜劇的な状態になることがある。こういう問題は認識するのは簡単だが直すことは誰にもできない。まさに僕がそのような体験をしたのでちょっと説明したい。 僕は仕事としてオープンソースのlldというリンカを書いている。リンカというのはコンパイラが生成したバイナリファイルをつなぎ合わせて最終的な実行ファイルやDLLを作成するプログラムで、知らない人も多いと思うけど、何をコンパイルしても最後にはリンカが動いている。lldは既存プログラムより何倍も速くてビルドが早くなるというので最近は結構人気が高まっていて、FreeBSDなどのいくつかのOSが全面的にスイッチしようとしたり、あるいは大規模プロジェクトChromeや、どうもFire

    ソフトウェアの互換性と僕らのUser-Agent文字列問題|Rui Ueyama
    KoshianX
    KoshianX 2017/11/15
    アドホックなハックで美しくなくても実際的にはやらざるを得ない、というのはまあ しょうがないことなんだよねえ……。そこで美しさを諦めちゃいけないんだけど、それはまず問題を解決してから。
  • 絵文字がある種のUnicodeバグを世界から一掃しつつある件について|Rui Ueyama

    UnicodeのUTF-16エンコーディングではほとんどの文字(コードポイント)は2バイトで表現されるが、Unicodeに後から追加収録された文字の多くは4バイトで表現される。4バイト文字がうまく扱えないプログラムというのはわりとよくある。しかし世界中で広く使われるようになった絵文字がよりによって4バイト文字であるせいで、そのような文字が扱えない問題がよいペースで解決に向かいつつある。それについて少し説明してみようと思う。 Unicodeが80年代から90年代初頭にかけてデザインされたときの目標の一つは、Unicodeに含まれる文字数を65536個以内に収めることだった。現代の文章を実用的なレベルで表すためには、漢字などを含めてもそれだけの種類の文字があれば十分だと考えられたのだ。当然これは1文字を2バイトで表すことを念頭に置いていた。つまりコンピュータの揺籃期から当時に至るまで単純に英語

    絵文字がある種のUnicodeバグを世界から一掃しつつある件について|Rui Ueyama
    KoshianX
    KoshianX 2017/11/13
    なるほど、絵文字を Unicode に入れてくれた Apple と Google には大感謝な話だなあ……。この2社が動かなければ 絵文字はガラケー専用外字のまんま消えていく運命だったものなあ……。
  • アメリカの面接で質問してはいけない事項について|Rui Ueyama

    アメリカで採用活動的なことに関わっていると、面接ではどういうことを聞くと違法になるのかを覚えておく必要がある。気軽な雑談が深刻な質問として受け止められていたりしてあとで訴えられたりしたら大変だ。たとえ結果的に訴えられることがなくても、法的にまずいことを聞くこと自体が大きな問題である。 アメリカでは第一にレジュメに写真などは貼られていない。写真が貼ってあったらこっちだって困ってしまう。全員を面接するわけではなく書類で通らないひともいる以上、書類だけの情報で採用されないひともいるわけだけど、そこに人種とか容姿がわかってしまうような情報が存在していても害しかない。 直接話をする場合でも、年齢によって差別的待遇を行うのは違法なので、年を聞くのはNG。人種や宗教、結婚しているかどうかなどを質問するのも当然よくない。性別を訊くのもダメ。自分の性別を聞かれたくない人はたくさんいるし、そういう仕事に関係な

    アメリカの面接で質問してはいけない事項について|Rui Ueyama
    KoshianX
    KoshianX 2015/10/08
    言語を身につけた経緯も聞いちゃダメなのか。
  • 昔の「コミュニティの偉くて怖い人」というのは何だったんだろうね|Rui Ueyama

    オープンソースのコミュニティで、偉いとみんなから思われていて、傍若無人な発言をよくしていて、なぜかそれが周囲から許されている人というのは、昔はよくいたように思う。 昔は僕も子供だったので、ネットでのコミュニケーションというのはそういうふうに殺伐としたものなのかな、と思っていたのだけど、いまになってみれば、ああいう人たちは一体なんだったんだろうと思う。ああいう人たちはちょっと何かがどうにかしていたのではないか? 僕はいまはLLVMで開発をしているけど、このコミュニティは基的に相互にリスペクトするべきという基的な原則が感じられて、あまりひどい発言などをすると誰かコミュニティの偉い人がたしなめに来たりする。困った人もいないわけではないけど、おおまかに言えばうまく運営されていると思う。コミュニティをどう運営するかというのは結局参加者の選択の問題で、殺伐としたコミュニティにすることもできるし、相

    昔の「コミュニティの偉くて怖い人」というのは何だったんだろうね|Rui Ueyama
    KoshianX
    KoshianX 2015/09/30
    fj と FreeBSD-users-jp くらいでしか見たことない気がするけれども。
  • 1