rmコマンドで大量のファイルを削除しようとするとjournaldがめっちゃリソース持っていく件— bokko (@cubicdaiya) 2017年8月3日 今時のファイルシステムはみんなジャーナルもってて何かあったときにそこからリカバリする仕組みになってるので、当たり前といえばそうなんだけども。 （TODO: ここにファイルシステムのツリー＋ジャーナルのポンチ絵を手描きでも何でも描く） ご本尊のデータのツリーと何らかのWALを1セットで持っておくのはRDBだろうがファイルシステムだろうがそうは変わらない、で、削除についても並行制御をうまくやるために削除フラグをログに入れておいてあとで本尊のデータを整理するというのが基本的な設計になる。そこで私は立ち上がった（TL;DR: 特にオチとかはないです）。 rm -rf が遅いのは人類にとって損失ではないか。もっと速く完了するようにすれば、 rm

先週Microsoft社がP言語に関するブログ記事を公開し一部界隈で話題となった。 P言語くん pic.twitter.com/uULzxIO4ct— Kuntaro Ishiyama (@_iamkuntao) 2017年3月26日 「いまさら一文字言語かよ…」「何個目だ？」といった批判的諦念的なものから、「RustとGoとErlangの間の子みたいなのだなあ」「なんか読みにくい」といった反応が多くこの言語の重要性やインパクトに対して正しく理解しているものがあまりなかった。尊敬しているTD勢ですらあまり重要性が伝わってないようだ 1 2 。上記のブログ記事を読んだり、マニュアルを読んだらすぐ分かるようなことではあるが、日本語で解説しておこうと思う。なおいわゆる言語入門とかそういった類のものではないことをご理解いただきたい。 TL;DR 並行処理や分散システムの形式証明や形式検証はそれ自体

日本の商習慣として未だに残っているのが「ファイルをまとめてzipで渡す」というやつである。数年前までビジネスで使われるコンピュータはWindowsがデファクトスタンダードだったので、zipファイルを作成するのも、展開するのも同じソフトウェアを使っていたから特に問題が起きることはなかった。古き良き時代であるが、近年ではMacOSも普及し、ビジネスでファイルをやりとりするのに使えるようになってきた。複数のOSが併用されるようになったが、相変わらずファイルのやりとりはzipで行われるという商習慣の形として残った。 私の意見はそもそもそういう商習慣を撤廃するべきだということに尽きるのだが、家族を養う手前既存の商習慣に従わなければならない。そしてここ数年は、仕事でもMacOSを使っている。MacOSとWindowsの間でファイルをやり取りするときの問題その1は暗号化zipである。問題その2は表題にあ

ちょっと発言力のありそうな方がテクニカルに誤りを書かれていたので、ここでひっそりと訂正しておきたい。 このスライドの43ページ目に、 The problem with Paxos-based algorithm is that replications are eventual consistent. と、色付き文字で協調されて書かれている。このスライドで主張したいことの本筋ではないが、Spannerの性能がよいこととは関係がなく、Paxosなどのレプリケーションと、トランザクションとの関係で誤解を広めそうなので指摘しておきたい。辻マサカリと言って差し支えないだろう。 PaxosはStrongly consistentであることがMade Simpleの論文で証明されている（Strongly consistentが何かはまた別の機会にここに書こうと思う）。ちょっと長いが引用しておこう。 T

自分が書いたプログラムのメモリ使用量を測定したいことがある。プログラムがOOM Killerによってお亡くなりになった場合や、ページフォルトをなくして高速化したい場合などだ。定常的に起動するサーバーのプログラムなら、sarや meminfo など（今なら Datadog とかだろうか）を使ってじーっと見つめるわけだ。もっとモダンにやるなら perf や DTrace を使ってもよいかもしれない。しかしこれらのツールは基本的にプロセスIDを渡してサンプリングして外から覗く方法だ。 わたしのユースケースはデーモンプロセスではなく、 main から入って必要な計算をして、それが終わったら main を抜けるバッチジョブ（単にコンソールから実行して終わるまで待つ、いわゆる "Hello world!" 的なやつ）だ。これだと、プログラムが起動して終わるまでそこそこの時間で終わってしまって、外部プロ

筑波大の川島さんに教えてもらって読んだ論文 The Stellar Consensus Protocol: A Federated Model for Internet-level Consensus がけっこう面白いので、紹介しようと思う。 32ページの長文で証明つきなのでガッツリ読み込めたわけではないのだけども。。。 背景 Bitcoinを始めとする電子貨幣（暗号貨幣）のブームは大きな投資を呼び込んで市場を開拓しつつある。またBitcoinの署名チェーンの部分のみを応用して、チェーンの合意を独自に構築する類似技術や製品をブロックチェーンと呼んだりする。私の理解だと、いずれもProof of WorkやProof of stakeの部分が難しい。PoWだと必要以上にアナーキーで時間がかかり、やたらCPUを食ってエコではないし、PoSでは結局は既存貨幣と同様に権威による認証が必要になること

昨日、分散DB本読書会のあとに品川のラーメン屋でリアルタイムとは何ぞや〜みたいな話になった。自分の思いついたポエムをここに書いておこう。現場の問題とはあまり関係がない。 Stream Data Processing: A Quality of Service Perspective (Advances in Database Systems)という本によれば、DSMS (Data Steram Management System) とDBMS (Database Management System)の違いは、クエリを発行するデータ集合の性質にある。つまり、DBMSは今ある有限のデータに対して操作を行うための仕組みで、DSMSはこれからやってくる無限のデータに対して操作を行うための仕組みと定義されていた。このDSMSというやつは、古式ゆかしいストリーム処理システムのことで、まあいわゆるCEP

短期間にブラウザのタブがたまってきたのでここいらでひとつまとめておこうと思う。 なにより驚いたのはChaos Monkeyというやつである（via forbes.com）。日本では知名度は低いが、NetflixはインターネットTV（というと分かりやすいかな？）の米国最大手でCassandraやAmazon EC2のビッグユーザーである。最近だと何やらオープンな形でCDN事業に参入しようとしているとか、まあひかりTVなどをやろうとしているNTTからみると協力なライヴァルではいぱーじゃいあんとである。 そのNetflixが、分散システムのテストでCassandraプロセスをわざと強制終了して常に障害耐性をテストしていると言っていたが、ついにそのソースコードが公開された。残念ながらバージャーでGradleという私からは最も遠い世界なのでソースコードは全く目を通せていないが、サービスを運用するため

第4回 システム系論文輪読会 - connpassが開催されると聞いて、思い出した話。日本だと、○○読み会という形で、特定の国際会議の論文をうわぁーっと集中的に輪読するコミュニティはいくつかあるけど、ある分野なりをまとめて回し読みしようという試みはないように思うので、ここで Papers We Love というコミュニティを紹介しようと思う。 Papers We Love Too - October 2014 - YouTube 予め断っておくが、ぼくはまだ参加したことはないし、同僚がたまたまファウンダーの一人なので知っただけだ。これがなかなか面白い試みだ。 Papers We Love is a repository of academic computer science papers and a community who loves reading them. ということで、計算機

生活リズムが乱れることがしばしばあって、たとえば遅くまでプログラミングの仕事やネットサーフィンをすると脳が興奮してなかなか寝付けない。もともと寝付きが悪くて、遠足の帰りのバスも一人だけずっと起きてるような子供だったのでまあ仕方がない。さらに歳のせいか、連続して睡眠できる時間が短くなり、パフォーマンスの低下につながることが多くなった。 そこで真人間を目指していくつか施策を打っているのだが、そのひとつが布団のなかでPodcastを聞くというものだ。これは @omo2009 さんがTwitterでLeslie Lamportのインタビューの話をしていて、聴いてみたら思っていたより面白かったのがきっかけである。 そういうわけで、ちょっと眠れなそうな夜には、イヤホンを寝室に持ち込んでこのIEEEのPodcastを聴くことにしている。他にもいくつかチャンネル登録しているものがあるのだけど、それはいい話

11月の19,20日に開催されたWebDB Forumに参加してきた。カンファレンスそのものは、いろんな人に久しぶりに会えたり、ネット上でなんとなく知っていても話したことなかった人と話したり、意外な人の意外な一面をみることができたりと、とても楽しむことができた。立場としては所属している会社のスポンサー枠で参加して目的もあって発表もしてきたわけだが、いくつか思うところがあるのでここにまとめておきたい。 現実にアカデミックで起きていること WebDB Forumと銘打ってはいるものの、データベースに関する研究発表は非常に少ない。OSやネットワーク、システム系の研究と併せても、機械学習やNLP、Webなどの技術に感心を持つ人は多く数で圧倒されている。体感では 90% だ。それをいえば別に VLDB や SIGMOD などのトップカンファレンスもデータベースの技術を直接扱うことは少ないし、データベ

このテーマ自体はさんざん語り尽くされていることである。たとえば山口君によるWhy Erlang? というブログ記事の翻訳や、戦闘機本（Programming Erlang: Software for a Concurrent World (Pragmatic Programmers)）を読めば世間でいわれていることはよく分かる。もしくは、同僚が最近書いたソフトウェアデザインの記事を読んでもらってもよいだろう。 Software Design (ソフトウェア デザイン) 2014年 02月号 [雑誌] 出版社/メーカー: 技術評論社発売日: 2014/01/18メディア: 雑誌この商品を含むブログ (3件) を見る 私自身もErlangに出会ってから5,6年が経とうとしているが、当初はそのよさがよくわかっていなかったように思う。しかし、仕事で高可用性が要求される複雑な分散システムに携わるよう

昨日、GoCon（ごうこん）なるイベントに参加してきた。以下に続く話は5割以上がフィクションなので虚実織り混ざっている様を楽しみながらお読みいただけたらと思う。 最初に発表されたニュースを聞いたときは、Goはよい車輪のよい再発明で、結局GoogleはC++やJavaを使い続けるだろうし、世間はGoogle独自言語としてみなすのだろうなという予感はあったし、2010年だから2011年ころはそういう見方をされていたように記憶されている。私もそういうものだと思っていたし、特に関心を持つこともしなかった。いま思えば正常性バイアスだったのだろう。 実際に昨日のカンファレンスで一番興味深かったのは鵜飼さんによるGoの解説だった。比較対象がC++, Python, Javaだったことが最も印象的で、普段からErlangやOCamlといった関数型言語に接していた身として新鮮だった。話を聞くうちにGoogl