tokuhirom /dev/urandom って開いたまま fork して読み込んだらまずいんですっけ? 親 process で /dev/urandom 開いたまま、fork してそれぞれの子プロセスで読んだら同じの取れる? kazuho 同じの取れないですね 一般論なファイルについてもそう つまり、open file descriptionは同一なので、readしたらその中にあるfile offsetは進むので (edited)
/dev/urandom を fork して読み込んでもいいんかって話 - tokuhirom's blog
tokuhirom /dev/urandom って開いたまま fork して読み込んだらまずいんですっけ? 親 process で /dev/urandom 開いたまま、fork してそれぞれの子プロセスで読んだら同じの取れる? kazuho 同じの取れないですね 一般論なファイルについてもそう つまり、open file descriptionは同一なので、readしたらその中にあるfile offsetは進むので (edited)
H2O version 2.2.3 released, incl. vulnerability fixes
Today, we have released H2O version 2.2.3. This is a bug-fix release, including two security fixes and 14 bug fixes from 7 people. Please consult the release page for details. The vulnerabilities being fixed are #1459 (CVE-2017-10868) and #1460 (CVE-2017-10869). Both are vulnerabilities against DoS attacks. It is recommended that the users of H2O update their deployments to the newest release. We
雑なツイートをしてしまったばかりにrubyを高速化するはめになった俺たちは！
逆に言うと、Rubyの文字列型の内部実装がropeになれば、freezeしてもしなくても変わらない速度が出るようになって、結局freezeする必要なんてなかったんやーで丸く収まるんじゃないの？と思いました #雑な感想 — Kazuho Oku (@kazuho) October 6, 2015とツイートしたところ、処理系の中の人から @kazuho 文字列を弄る話じゃなくて、文字列の identity の話なので、ちょっと関係ないかなぁ、と — _ko1 (@_ko1) October 6, 2015みたいなツッコミをもらって、うっすみません…ってなってRuby VMのコードを読むことになったわけです。 で、まあ、いくつか気になる点があったので手をつけてしまいました。 1. オブジェクト生成のホットパスの最適化 ホットスポットだとされていたところのコードを読んでると、オブジェクト生成の際に
Linux 上で5秒で chroot jail を使えるコマンド「jailing」が凄い！ - tokuhirom's blog
https://github.com/kazuho/jailing/ kazuhoさんがやってくれました。 ずいぶん前からlinuxでchroot jailを作るのに簡単な方法ないかなーと思ってました。個人的にはsystemd-spawnというのを使ってたのですが、幾らか気に入らない所があったり構築に時間がかかったり、ディスク容量を消費していました。簡単に使えて、ディスク容量を消費しないやつがほしいなーっておもってたんです。 とあるIRCで昨日、kazuhoさんと「ほしいですよねー」という話から始まって、github にある docker とかも物色しながら「いいのないねー」とか言ってたらkazuhoさんが「もすこし綺麗に書けそう」って言い出して朝から本格的に書き始めてついさっき出来上がりました。速いw 名前はjailing とても小さく、実装コードだと100数十ステップ程です。しかもpe
Kazuho's Weblog: さらば、愛しき論理削除。MySQLで大福帳型データベースを実現するツール「daifuku」を作ってみた
さらば、愛しき論理削除。MySQLで大福帳型データベースを実現するツール「daifuku」を作ってみた 先のエントリ「論理削除はなぜ「筋が悪い」か」で書いたとおり、データベースに対して行われた操作を記録し、必要に応じて参照したり取り消したりしたいという要求は至極妥当なものですが、多くのRDBは、そのために簡単に使える仕組みを提供していません。 daifukuは、RDBに対して加えられた変更をトランザクション単位でRDB内にJSONとして記録するためのストアドやトリガを生成するコマンドです。 % daifuku dbname tbl1 tbl2 > setup.sql のように実行すると、指定されたテーブル（ここではtbl1とtbl2）にセットすべきトリガや、更新ログを記録するためのテーブル「daifuku_log」を生成するCREATE TABLEステートメントなど、必要なSQL文をset
Kazuho's Weblog: 「技術的負債」は避けるべき？ - 割引率を使って考えてみた
「技術的負債」をコントロールする定量評価手法への期待 からの続きです。 ソフトウェアサービス企業における技術責任者の最も重要な仕事のひとつが、エンジニアリングの効率化です。そのためには、サービスの初期開発コストだけでなく、運用コストを織り込んだ上で正しい技術的判断を行っていく必要があります。 「技術的負債」という言葉は、この運用コスト最適化の重要性を指摘する上で、とてもキャッチーなフレーズだと考えられます。しかし、「技術的負債」を産まないように、あるいは負債を早めに返していこうとすると、開発工数が大きくなってしまうという問題もあります。 初期開発コストと運用コストのバランス注1を、どのようにとっていけば良いのでしょう？ 同等の機能を提供する「ソフトA」と「ソフトB」を考えてみます。ソフトAは、初期開発工数が6だが、２年目以降の維持工数が毎年4かかるとします注2。ソフトBは、初期開発工数が1
[メモ] TCP上（もしくはHTTP）にリトライ可能なアプリケーションプロトコルを実現する方法
HTTP/1.1の持続的接続においては、サーバがリクエストを受け取ったあとに異常終了したのか、リクエストを受け取らずに接続を閉じたのか判別することができない。このため、べき等性の保証がないアプリケーションにおいて、リトライを行うべきか否か自動的に判断できなくなる場合がしばしば発生する注。 リトライ可能か否か（ピアがメッセージの処理を開始した否か）を判別するには、より細かな情報交換を行う別種のプロトコルを採用しても良いが、複雑なプトロコルはパフォーマンスに悪影響を及ぼす可能性が高いので避けたいところである。 というわけで、以下本題。 pipeliningを行わないHTTP/1.1のような単純なリクエスト／レスポンス型プロトコルをそのままに、アプリケーションレイヤへのリクエスト到達可否を判定する手軽な方法としては、SO_LINGERを用いる方法がある。具体的には、以下のような形式でサーバを実装
[メモ] root権限でrsyncする方法
サーバの移転作業時など、rootしかアクセスできない設定ファイルやアクセス権を保ったままrsyncしたいことってありませんか？ そういった際には、sudo の -A オプションと rsync の --rsync-path オプションを使うと良いようです。 まず、リモートサーバに、パスワードを標準出力に出力するスクリプトファイルを配置します（ファイルのパーミッションを厳しくするのを忘れずに）。 % cat > bin/askpass #! /bin/sh echo "{{my_password}}" % chmod 700 bin/askpass % そして、rsync を実行する際には --rsync-path オプションを使い、リモートサーバの rsync を sudo -A 経由で起動するようにすれば良いのです。 % sudo rsync -avz -e ssh \ --rsync-p
DRY(don't repeat yourself)するかしないか、その判断基準について - kazuhoのメモ置き場
「過剰なDRYが技術的負債を生む」みたいな内容の記事を書きたいが、うまく言語化できない。「過剰な食事制限が健康を損なう」程度の内容に成り下がりそうだけど、そんなんじゃないんだよ… @methane 実装におけるDRYみたいなものを考えていて、そうすると前者のDRYというのがどこに位置づけられるかはわからないんですが、とにかく暗黙知みたいなものを過剰に増やすDRYは良くないよね、というような話なんです という@moriyoshitさんのツイート（1, 2）を見かけたので、僕の考え方をコメント。moriyoshitさんの考えたい問題とは、ずれてるかも。 DRY化の功罪とは何か？ 僕の理解で言うと、共通するコード片をDRY化することには以下の変化をもたらす。 循環的複雑度は変化しない コールグラフは複雑化する モジュールをまたぐDRY化を行うと、モジュール間の依存関係も複雑化する*1 関数内の複
MySQL用にランキング専用ストレージエンジンを作る話 - kazuhoのメモ置き場
前提: ゲームに限らずランキング機能が必要になるケースは多い つまり需要はある だが、MySQLで高速なランキング表示は難しい 具体的に言うと、以下の要件を満たすのが不可能 １行の更新コストが要素数Nに対して O(log N) 以下 任意のランキング位置周辺のSELECTコストが O(log N) 以下 ならば、専用のストレージエンジンを作ればいいのではないか いつやるか？ 今でしょ！ 以下理由 MySQL 5.5以降?だとストレージエンジンをまたぐトランザクションがまともになってるはず*1 ランキング専用でいいから、テーブル構造とか固定でいい（つまり実装が簡単！） ランキング専用だから、テーブル・ロックで十分（つまり実装が簡単！） 更新すると順位がずれる（つまりテーブルの大部分に影響がある）ので行ロック実装するメリットが小さい*2 ランキング専用でいいから、全データをメモリにもっても問題
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
