February 2014

https://bugzilla.kernel.org/show_bug.cgi?id=69771

最近のcryptはエラーリターンするかもしれないんだけど、manに反映されてなかったので対応依頼してたのだが
本日これが完了したようだ

Rubyがこのバグで問題になったケースがこちら
https://bugs.ruby-lang.org/issues/7312

glibcでのこの件についての議論はこのへん
http://sourceware-org.1504.n7.nabble.com/RFC-FIPS-compliance-and-other-crypt-3-improvements-td6884.html


cryptユーザー各位(いないと思うけど)におかれましては、くれぐれはエラーチェックをせずにcryptを使うことなきようお願い致します。
このエントリーをはてなブックマークに追加

https://groups.google.com/forum/#!topic/fluentd/dXc4weNEdCg

# New core committer

Motohiro Kosaki is now a Fluentd Committer.
Welcome!!

He is a Linux Kernel and Ruby committer, so
his experience and knowledge are very helpful for Fluentd and Fluentd community :)
We can improve and grow the Fluentd more quickly!


Enjoy Fluentd!



なにやら、Motohiro Kosakiという New Committerがやたらと持ち上げられてるが、
わたしの知っているこさきさんとはキャラクターが大きく異なるのできっと別人だろう。
このエントリーをはてなブックマークに追加

すごく面白かった!!

一時期流行った腐女子彼女というBlogの作者さんによる小説です。今作の主人公も著者とその体験が色濃く投影されており、掛け合いのノリは腐女子彼女とそっくりで、ああいう感じのラブコメが楽しい人には大変楽しいと思います。

ラストにちょっとしたどんでん返しがあるのですが、そのへんがちょっと昔の自分とオーバーラップするところがあり号泣してしまいました。(あとから考えてみると、あそこで風邪をもらってきただけかもしれない)

星5つあげる。



このエントリーをはてなブックマークに追加

セプキャン同窓会ことセキュリティ・キャンプフォーラム2014 に参加してきたのですが、そこであのへんの頭おかしい連中 バイナリに知悉した講師陣が新しい本を書いたと知りました。
ここでAmazonから紹介をピックアップしましょう

「5・7・5・7・7 」三十一(みそひと)バイトの機械語コードでなにができるか?
"遊び"と"ルール"の下で行うプログラミング「アセンブラ短歌」を完全解説。

機械語コードはアーキテクチャによってさまざまですが、可変長の命令を持つものならば命令の並びに5・7・5・7・7 各バイトに区切りを持たせることが可能です。あえてそのような制約のもとでプログラムを書いてみようというのが「アセンブラ短歌」です。どのような動作のプログラムになるのかもあわせて紹介していきます。

自然言語における「短歌」も制約を持たせた「言葉遊び」として生まれました。こうして書かれた文章には「味わい」や「感動」があります。それが長い年月をかけて発展し、格調高い文化として成熟してきたわけです。「遊びとルール」の下で行うアセンブラプログラミングを「近未来の文化的趣味」として楽しむため本書は執筆されました。

5・7・5・7・7 合計31バイトという制約を守るにはコツや試行錯誤が必要です。望みどおりの出力結果を得るために必要となる"短歌詠み"の基礎から技巧まで、本書にはプロ歌人の知恵が詰まっています。技術的な内容も多少なりともありますが、それよりも「味わい」のあるプログラムを多く扱うように心がけました。
Chapter.5ではさまざまな歌人による、浪漫主義(明星派)、写実主義(アララギ派)、新現実主義(新思潮派)、理想主義(白樺派)のアセンブラ短歌も紹介していきます。

アセンブラという実用言語が文化の域に到達していく過程の時代の証人に、あなたもなってはみませんか?



のっけから溢れ出る日本語でおk感がすばらしいですね!(謎

当日は、XSS短歌(XSSで5・7・5・7・7を守る)とバイナリ短歌のどっちが高尚か、とか季語が欲しかったのでSJISとして開くと半角カナで キゴ って入るような命令列を研究したとか、手遅れ感溢れるキチガイ話をたくさん聞いて大変面白かった。
愛甲さんは表紙を自分にデザインさせてくれればベストセラーになったはずなのにと息巻いていたが、はせがわさんに、そもそもこんな本、商業誌で出版されたこと自体が頭おかしいわ。編集は止めるべきだろ! と突っ込んでいたのが超おもしろかった。

というわけで、バイナリアンは全員購入して続編が出せるようにしてあげるといいと思うよ!


このエントリーをはてなブックマークに追加

いちおうこちらでも告知。デブサミ後、鍋を囲んだ話しあいの結果、Rubyコミッタが fluentd いじっててもいいんじゃねという話でまとまったようです。F2Fミーティング、っていうかむしろ鍋?って重要だよね。
このエントリーをはてなブックマークに追加

物語はふたたび、アミル編へ…。

アミルの兄、アゼルは苦悩していた。生き残るために、カルルクの村を略奪すると決めた親族たち。
その背後には、つぶし合いを狙うロシアの思惑が見え隠れする。
一族への忠誠心と、妹アミルへの愛情、ふたつの板挟みのなかで、アゼルが決めた「正しい選択」とは……?
前巻までのラブ・コメディーから一転、全編に渡ってアクション描写が冴え渡る、戦闘群像の『乙嫁語り』第6巻!



だそうです。
絵も綺麗だし、バトルも迫力満点。なのにいまいち気分が高揚しないのはこの漫画に求めてるの癒やしであってバトルではないんだろうなあと自分を再確認するなど。
でも絵は綺麗です(大事なことなのでry

次巻からドタバタ劇にもどるっぽいのでそちらに期待



このエントリーをはてなブックマークに追加

ページの半分ぐらいが描きおろしおまけマンガなので、あんまり割高感はない。
ぜんぜん関係ないがストーリーとまったく関係ないところで

井上「チャイナ服着て旧満州の駅で写真取るのになぜ銃がないの!?
嫁&カメラマン「?」

というやりとりをしているシーンが好き。
結 婚 写 真 だ ぞ


このエントリーをはてなブックマークに追加

タイトルにつられて買ったけど、ただのストーリー万歳本だった。このへんもうちょっと深堀りした本はないかねえ。



このエントリーをはてなブックマークに追加

そういうわけで、今年もサンフランシスコに行ってきます。
たぶん今年は日本人が何人か来そうな気配
このエントリーをはてなブックマークに追加

eglibcをメンテしていた Joseph S. Myers が glibcのMLに、eglibcの主要なパッチは全部glibcに
入ったから glibc2.19 リリースをもって eglibcのメンテを終了すると発表した。



List-Id:
List-Archive:
Date: Sun, 2 Feb 2014 18:15:48 +0000
From: "Joseph S. Myers"
To:
Subject: Distribution merge status Feb 2014

As of 2.19, all the changes from EGLIBC that I wanted to get merged into
glibc have been merged and I will cease maintaining EGLIBC trunk after
2.19 is out. (A few changes - items 2 to 10 at
- were dropped
rather than making an attempt to merge them to glibc.)

How are other distributors doing on merging their changes to glibc as far
as relevant? That is, about how many changes (in principle relevant to
glibc rather than only making sense at all in the distribution context)
are yet to be merged and when might you expect to have them
submitted/merged by? Specifically:

* gnulib (where I think the aim should be for identical sources of shared
files in both locations, except for gnulib's automatic changes to license
headers and replacement of TABs by spaces). Note that for portability
fixes - any change that won't affect the code as used in glibc - review
for glibc should basically be about style rather than the substance of the
code not being used in glibc, as per
.

* GNU Hurd (where the aim should be for everything to be in mainline glibc
so distributors don't need to apply any unmerged patches, or backport
anything beyond bugfixes such as go on the release branches anyway).

* GNU/Linux distributions.

(The same applies to distribution bug trackers - if a distribution bug
describes a bug present in current git, getting it into glibc Bugzilla is
useful. But I'm thinking first in terms of resolving the backlogs of
unmerged patches.)

--
Joseph S. Myers
joseph@codesourcery.com


このエントリーをはてなブックマークに追加

↑このページのトップヘ