本の虫: Linus、今までの行いを謝罪し一時的にカーネルメンテナーの立場を退いて人の気持ちを勉強してくると発言
Linus、今までの行いを謝罪し一時的にカーネルメンテナーの立場を退いて人の気持ちを勉強してくると発言 完全に背景事情を調べ上げたわけではないのだが、どうもLinusが毎年参加しているLinuxカーネルの会議に、Linusがスケジュールを間違えて参加できなくなるという事態が発生した。当のLinus本人はもう20年も続いている会議だし自分がいなくてもやっていけるだろうと楽観視していたが、会議自体がLinusの都合にあわせてリスケジュールされた。 LinuxにおいてLinus Torvaldsといえば第一人者であり極めて重要な存在で、そのLinusが毎年参加している重要な会議にLinusが参加できないとあれば、その他のあらゆるコストを度外視して根回し調整を行い、Linusが参加できるようにイベント全体のリスケジュールを行うのは人間の感情から考えて当然である。しかし当のLinus本人は他人の感情
濫用に当たる職務質問を受けたと考えたので弁護士に相談して訴訟を起こすことになった話
去る7月3日の午後の通勤途中に、私は職務質問を受けた。その次第は以下のブログ記事に職務質問を受けた当日書いて投稿した。ただし、投稿時に日付を超えてしまったので投稿日時は7月4日になっている。 本の虫: 警察官に職務質問をされた話 さて、振り返って見るに、私は先日の職務質問が警察官職務執行法第一条に規定された、「目的のため必要な最小の限度」を超えていて、「濫用」にあたるのではないかと考える。というのも、 「下を向いて歩いていた」、「帽子を目深にかぶっていた」という理由は、同法二条にある「合理的に判断して何らかの犯罪を犯し、若しくは犯そうとしていると疑うに足りる相当な理由」にはならない。 仮に「疑うに足りる相当な理由」であったとしても、職務質問を開始してかなり早い段階で、その疑いに対して「重い荷物を背負って長距離を歩いたので疲れたのではないか」、「人間は下ぐらい向くものだ」、「日差しが強く帽子
ここらでもう一度マストドンについて語っておくか
オレが間違っていたぞ、清水亮。 なんで「オレが間違っていた」と最初に書けないのか。つまんねープライドもってんなー -- 清水亮 https://mstdn.onosendai.jp/users/shi3z/updates/1002 前回、前々回と、マストドンについての批判を書いた。結論を先に書くと、私の技術上の懸念以外の懸念はすべてあたらなかった。 本の虫: そろそろマストドンについて語っておくか 本の虫: マストドンが直面している問題はすでにP2P技術が15年前に遭遇した問題だ そうこうしていると、ドワンゴがマストドンのインスタンスを立ち上げた。 https://friends.nico/ これはなかなか興味深い。というのも、私はドワンゴに雇用されているので、ドワンゴが悪意を持っているかどうかについては内部の情報があるため判断しやすい。マストドンはインスタンスの管理者が悪意を持っているか
そろそろマストドンについて語っておくか
世間ではマストドンが流行っている。結論から言うとマストドンは思想的にも設計的にも失敗しているのでお祭りのように一時の話題になった後、急速に忘れ去られる運命にある。 マストドンを語るには、まずマストドンが実装しているプロトコルであるOStatusについて説明する必要がある。これはもともと、StatusNetというソフトウェアが提唱したプロトコルで、Twitterようなマイクロブログの更新通知のためのプロトコルだ。StatusNetは今は名前を変えてGNU Socialとして自由ソフトウェア財団の傘下になっている。 マストドンはいうなればGNU Socialの互換実装だ。その基本的な思想や設計はGNU Socialと同じだ。どちらも現在の大手ソーシャルネットワークサービスに共通の問題に対処しようとしている。 問題とは何か。権力の一極集中である。TwitterにしろFacebookにしろGoog
Sarah Sharp、Linuxカーネルコミュニティの暴力性に嫌気がさして貢献をやめる
Closing a door | The Geekess ドアは閉められた この記事は一年もの間、下書きフォルダーに入れてた。いまこそ投稿すべき時。炎上は怖かったので、この問題について触れるのはなるべく避けてきたのだけれど、部屋の中の象を指摘しないのはもやもやする。そういうわけで、公開する。 つまりこういうこと。私はもうLinuxカーネル開発者じゃなくなった。2014年の5月にUSB 3.0ホストコントローラードライバーのメンテナーの座を明け渡したし、2015年の1月には女性向けFOSS推進計画(FOSS Outreach Program for Women)のLinuxカーネル部門とかその他の役職も降りたし、2014年12月6日には、最後のLinuxカーネル開発のプレゼンをした。2015年8月のシアトルでのLinux Plumbers Conferenceへの協力は断った。Linux財団
結婚することになった
突然だが、結婚をすることになった。年内に籍を入れることを考えている。あまりに唐突に決まったため、周囲からも本人も、ノリで結婚することになったと言っている。 「契約結婚しましょう」 と女は言った。その言葉は江添に対して発せられたようではあるが、どうにも意図が曖昧である。女は江添に対して結婚を申し込んでいるようにも聞こえ、あるいは、江添は誰かと結婚をすべきであると言っているようにも聞こえる。前者の解釈が誤りである場合、江添は大変なうぬぼれをしたことになる。前者かどうかを確かめるには、ここでわざとらしいにやけ顔を作り、おどけた声で、「私と？」などと答えればよいだろう。たとえ解釈間違いであったとしても、うぬぼれやを気取った冗談で済む対応だ。 ここは筆者の住むシェアハウスのリビングであり、たまたま何人かの男女が集まって、軽く酒を飲みながら話をしている。となりでは、いかにも恋愛経験の豊富そうな大人の女
闘会議2015のアナログゲームエリア、とある運営スタッフの感想
週末に、闘会議2015が行われた。これはアナログゲームの上級エリアの運営スタッフであった筆者による感想記事である。 筆者は名を江添亮と言う。闘会議ではカタンのインスト要員として参加した。当日はスキンヘッドで口ヒゲを伸ばしていたのが筆者である。 さて、今回の闘会議では、アナログゲームエリアとして、様々なボードゲームを遊べる場所が設置された。 今回初めてとなる闘会議では、色々と突貫作業であり、ボードゲームの理解の浅い人間が企画をしたようで、色々と準備に難があった。 まずボードゲームのインストを出来るスタッフが絶望的に足りないということだ。ドワンゴのボドゲ部員にスタッフ参加の応援要請が来て、開催日の数日ぐらい前に打ち合わせをしたほどだ。 前日にリハーサルで現地を見てみると、ボードゲーム用に用意された机は表面がツルツルと滑り、しかも細長い机を二つ並べたもので、隙間があって使いづらかった。テーブルク
Pingプログラムの話
The Story of the PING Program そうだ。UNIXのpingを書いたのは俺さ。pingというものは誰でも知ってるだろうが、これはある夜、俺が千行程度で書いたハックだ。 名前の由来はソナーの音だ。俺は大学でソナーとレーダーシステムの設計をさんざんやっていたので、サイバースペース的なものとは親和性が高かった。新しい分野に既存の概念を適用したというわけだ。pingはIP/ICMP ECHO_REQUESTとECHO_REPLYパケットを使って時間を測り、ターゲットマシンへの「距離」を計測する。 4.2a BSD UNIX用のPINGを書いた着想は、1983年の7月に、ノルウェイでのDARPA会議で、Dave MIlls博士からきいた話が元だ。博士はFizzball LSI-11システムで、ICMP Echoパケットの時間を計測して、経路遅延を計測したと話していた。 19
fork()は失敗するんだぜ、覚えときな
fork() can fail: this is important あー、fork()のことね。プロセスがもっとプロセス作るためのやつな。いや、他にもプロセス作る方法はあるけどな。ま、面白い話がもうひとつあるから聞かせてやるよ。 forkは失敗するんだぜ。分かってるか？ マジで分かってるか？ マジだぜ。forkは失敗するもんだ。mallocと同じさ。失敗することもある。そんなに頻繁にってわけじゃないけどさ、でも失敗したら、無視できっこないぜ。ちっとは脳みそ働かせなきゃならん。 forkが0を返したら、そいつは子プロセスで、親なら正数を返すってことは、みんな知ってるよな。その値は子のpidだ。こいつを保存しといて、あとで使うってわけだ。 失敗を確認しない場合どうなるか知ってるか？ そうだよ。お前多分、"-1"（forkのエラー通知）をpidとして扱ってるんだろ。 さて、問題の始まりだ。本当
bzrは死につつある。Emacsは移行しなければならない
bzr is dying; Emacs needs to move Emacsのソースコードは、Bazaarでバージョン管理されてきた。しかし、Bazaarは分散バージョン管理システムとしては、Gitに敗北したし、もはや死につつある。Eric S. Raymondは、Emacsは他のバージョン管理システムに移行しなければならないと書いている。 私がこの投稿をしている理由は、バージョン管理システムとその周辺ツールのエキスパートとしての責務であって、この議論に参加したいがためではない。 bzrバージョン管理システムは死につつある。ほとんどの点で、もはや死んでいる。dev listは死んでいるし、Canonicalのほとんどの内部プロジェクトはbzrを捨ててgitを使っているし、古参開発者の一人が、なぜbzrが失敗したかについて書いている: http://www.stationary-trave
様々なUNIX環境のecho.cの比較
UNIX V5, OpenBSD, Plan 9, FreeBSD, and GNU coreutils implementations of echo.c UNIX Fifth Editionのecho.cは、以下のような実装になっている。 main(argc, argv) int argc; char *argv[]; { int i; argc--; for(i=1; i<=argc; i++) printf("%s%c", argv[i], i==argc? '\n': ' '); } いかにも昔のC言語らしいコードだ。ヘッダーの#includeはなく、関数の戻り値の型も指定されない。仮引数の型も、今となっては物珍しいだろうが後書きだ。 OpenBSDのコードは以下の通り。 /* $OpenBSD: echo.c,v 1.7 2009/10/27 23:59:21 deraadt
自由ソフトウェア財団が技術的な指導力を失いつつある
GNU sed 4.2.2 released, and a rant from the maintainer GNU sed 4.2.2のリリースに合わせて、メンテナーであるPaolo Bonziniが、GNU sedを含むGNUプロジェクトのメンテナーをやめると発言している。さらに、その理由について書き立てている。 私はGNU sed 4.2.2を喜ばしく発表する。 喜ばしからぬ発表として、私はGNU sed(8年間)とGNU grep(3年)のメンテナーから降りる。私はさらに、Autoconf, Automake, Libtool, gnulib, libsigsegv, Bsionのコミットアクセス権も放棄する。 GNUメンテナーと外部の者に告ぐ。この発表や、Nikos Mavrogiannopoulosの発表、gnutlsの移行は、驚くにあたらない。 gnutls is movin
60%の人間はプログラミングの素質がない
Coding Horror: Please Don't Learn to Code Please Understand Learning to Code Coding Horrorで有名なJeff Atwordが、ある州知事が今年の目標としてプログラミングを習得することを挙げていることに対し、そもそも税金を払う我々市民は、政治家にはプログラミング習得以上に重要な、政治家にしかできない問題の解決を望む、よってプログラミングを学ぶのをやめてくれという記事を書いた。これに対して、反論が多数上がっているが、Jeffも読んでいるある論文をあげて、この議論の参加するためには、必ずこの論文を知っておくべきであると書いた人がいる。この論文は有名で、非常に興味深いので、全プログラマーが読むべきである。 ふたこぶラクダという名前で知られている有名な論文がある。この論文では、60%の人間にプログラミングの素質が
GPGPU時代のハッシュアルゴリズム
Coding Horror: Speed Hashing xkcd: Password Strength GPGPUが一般的になった現代では、従来のハッシュアルゴリズムは十分な強度ではないというお話。一般人が五百ドル程度で購入できるハイエンドグラフィックカードは、現在のハイエンドCPUより150倍も高速にハッシュ計算ができる。しかも、GPGPUで高速に計算できるということは、並列性が高いということを意味する。つまり、GPUを増やせば容易にスケールするので、さらに危ない。 もはや、MD5やSHA-1、SHA-2の時代は終わった。これからの開発者は、GPGPUに対しても十分な強度を持つ、容易に並列化できないハッシュアルゴリズムを採用しなければならない。 ユーザーは、長いパスワードを使わなければならない。現時点でのJeff Atwoodのおすすめは、12文字以上である。1(xY%08などという、
Dartすごい。マジすごい。美しい
Dart : Structured web programming というわけで、Dartが発表されてからこのかた、Dartの規格を読んでいたのだが、これはすごい。マジですごい。ヤバイほどすごい。美しすぎる。 私が多少なりともかじっている言語は、C++とJavascriptとアセンブリである。私は、もうこれ以上、学びたいと思う新言語が出てくるとは思っていなかった。たしかに、C#はWindowsでアプリを作るには面白そうだし、PythonやらRubyやらは、かなり人気だ。しかし、これらの言語を学びたいとは思わなかった。昔、Schmeに興味を持ち、SICPを買った。しかし、未だ綺麗なまま、本棚の中に眠っている。Haskellに興味を示したこともあったが、やはり最初の感動が覚めると、学ぶ気にはならなかった。つまりは、わざわざ学ぶほどの魅力がなかったのだ。しかしどうやら、私は間違っていたようだ。D
コンピューターウイルスという用語は廃止すべき
慣習的に、malwareを「ウイルス」とか「ワーム」とか「トロイの木馬」などと読んでいる。これは、やめるべきである。結局、これらの言葉は、一般人には理解出来ない専門家が、ある特定のソフトウェアのカテゴリー分けをするために使っていた符牒である。符牒は、一般人に使われることを想定していないのだ。 寿司屋では、「上がり」とか「おあいそ」といった言葉が使われる。これは、「うぉーい、客が帰(け)ェるぞぉ。茶ァ出せ茶ァ」とか、「勘定しろぉい」など叫ぶのが、あまりにも客に対してぶあいそであるので、店側の人間だけで通じる、同様の意味を持つ暗号を取り決めたのだ。それが、いつの間にか客側にも広まってしまい、今では、客が「上がり頼むよ」とか「今日はこのへんでおあいそして」などというようになってしまった。本来、客側での使用を想定していない言葉が定着してしまったために、知らないものから見ると、非常に不思議に聞こえる
本は死んだ
The “book” is dead [dive into mark] JavaScript: The Definitive Guide Sixth Edition pdf download ebook - davidflanagan.com オライリー JavaScript本（通称サイ本）の作者、David Flanaganのブログに関して、Google社員のMark Pilgrimが反論している。 オライリー JavaScript 第5版の作者である、David Flanaganが書いている。 この15年というもの、私は成功した作家の一人であった。自分と家族の食い扶持を、本の印税収入だけで得ることができたのだ。しかし、出版業界は斜陽であり、私の印税収入も、ドットコムバブルの崩壊よりこのかた、下がる一方である。私は、サラリーマンとしての就職口を見つける必要があると結論した。 15年という
本の虫: Chromeがいつの間にか縦書きを実装し始めていた
注意：ここに示したCSSは、実用的な目的には、まだ使ってはならない。何故ならば、-webkitベンダープレフィクスを使っているからである。。これは、webkitの実装がまだ完全ではないことを意味する。 Chrome（というよりもwebkit）がいつの間にか、縦書きを実装し始めていた。つまり、CSS3のwriting-modeプロパティのvertical-rlとvertical-lrをサポートしているのである。まだ、ベンダープレフィクスが必要なので、完全な実装ではないのかもしれないが、少なくとも、ある程度は動くようだ。 例えば、以下の様なマークアップが、 <p style=" writing-mode : vertical-rl ; -webkit-writing-mode : vertical-rl ; font-family : '@ＭＳ 明朝' ; font-size : 16pt ;
多くない文
ある日本語を学んでいる外人から、こんな質問を受けた。 本当に日本語は常に否定疑問文を論理的に答えるのか？ 例えば、「多くない？」って聞かれたときはどう答えるんだ。 はて、これはどうしたことか。私は今まで、日本語は常に否定疑問文を論理的に答えると考えていた。しかし、「多くない？」という疑問文に対しては、目的物が多くなかった場合、 うん、多くないね。 いや、多くないよ。 と、両方答えることが可能であるし、目的物が、多い場合にも、やはり同様に、二種類の答え方が可能だ。 はて、これはどうしたことだろう。常日頃、「英語はなんて非論理的な言語だ。日本語を見よ」と笑っていたのが、急に恥ずかしくなってきた。 ところが、どうも思うに、「多くない？」という文章は、私の感覚からすると、肯定疑問文にも、否定疑問文にも、受け取れるのだ。事実、英語のように非論理的に答える場合、私は肯定疑問文だと解釈している。とすれば
日本の参考書には図表が多すぎではないか
私は、ここ五年ぐらい、日本語で書かれたプログラミングの参考書を読んでいない。というのも、日本語で書かれた参考書の質が非常に悪いため、もとより読む気にならないのだ。 ところで、今ふと翻訳ではない日本語の参考書を眺めてみたところ、いずれも図や表がやたらと多いということに気がついた。どう考えても多すぎである。本の半分以上は図表で占められているのではないかと思うぐらいだ。何故こんなに多いのか。 私は、図表が嫌いである。思うに、図表というのは、物事を視野の範囲に収まるぐらいに見せかけるだけであり、実際に物事を理解できるわけではない。物事を明確に説明するには、文章による記述が必要である。 もちろん、機械の操作方法の説明で、ある場所に位置するボタンを押すという説明の場合には、機械の絵や写真があれば分かりやすいとは思う。しかし、プログラミング言語の場合、「機械の絵や写真」に該当するものは、ソースコードであ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
