いまておるみんって言ったの誰めうかー？（お前だめうー）

携帯端末をポンポン買わないしゲーミング PC は所有していない小市民だよ。

まだ j のほうが納得感

This account is not set to public on notestock.

This account is not set to public on notestock.

Google Japan Blog: 思いどおりの日本語入力 - Google 日本語入力 https://japan.googleblog.com/2009/12/google_03.html

「ググる」の精度を高めるために必要なもの － ＠IT自分戦略研究所 http://jibun.atmarkit.co.jp/lcareer01/rensai/cas003/cas001.html

MeCab と mozc の作者どちらも同じで MeCab の名称はもう作者が和布蕪好きというだけ

mozc は実際に海藻のモズクだと思う。mozc が出たばかりのとき形態素解析ライブラリとして著名だった MeCab（メカブ）と無関係のネーミングじゃなさそう

cga でキャというのわりと使われてるストロークだったりするのかな

cja のほうがまだ納得がある

cga でキャなのなんか直感的じゃないな

-in とか -un とか -on とか -ei とかは二重母音にならないか。

発話上は普通二重母音になるからべつにいいかと思ってた

This account is not set to public on notestock.

連続した音，というより二重母音

This account is not set to public on notestock.

誰かあの bot を黙らせろ 3

This account is not set to public on notestock.

誰かあの bot を黙らせろ 2

おるみんはおるみんなのでておるみんでもて・おるみんでもてお・るみんでもない。

This account is not set to public on notestock.

ちくパ

慌てないめう。落ち着いてちくわを数えるめう！

漢直の無連想変換もそうで，結局ローマ字入力とか慣れると「か……だから k と a で……」とかやらずに身体に染み付けた 2 ストロークで自然に「か」が入力できるわけで，訓練すれば連想変換も無連想変換も同じ（むしろ文字の打ち安さと配列を結び付けてる無連想変換のほうが効率的）と言える

平仮名をローマ字で入力する際にローマ字を入力すること自体を意識してるとわりとアレなので，入力位置と文字の関係をいっぺん忘れて 2 ストロークで文字が入力できるということだけを身体に染み付けてると良かったりする気がする

手書きで悩んだりはあまりしないのなら脳内で発話しながら入力すれば良いと思う

それはそれとして，「うごく」は「うご-」を語幹にする五段活用の動詞なのだから自然とどこらへんが漢字になるか判断しやすい

本を読もう

動くが「う・ごく」だったか「うご・く」だったか悩んでしまうの流石に衰えすぎでは感がある

にこきゅっぴん☆

わたしこういうのすき

やる気が出ない〜〜

にゃーーーん

とかとかとか

確率モーメント求めるのに積分無しでどうやってやるん

統計の確率分布関数とかおもいっきり積分出てくるやん，あとガンマ関数とか積分で定義されるやん。

離散数学にも積分や微分はある

名古屋大学の良さげな講義ノートあるやん http://www.math.nagoya-u.ac.jp/~nakamako/Resources/Probability.pdf

いや，確率空間から大数の法則，中心極限定理，ランダムウォークとかブラウン運動とかちゃんと講義は受けたけど 1 限だったからあんまりちゃんと勉強しなくって赤点だった

私は測度論をちゃんと勉強していないので確率論もわからない

確率をちゃんと理解するにはルベーグ空間とかルベーグ積分とか理解してないと理解できない

他にも空間って距離に関する空間（ユークリッド距離とかバナッハ距離とか）とかもある

確率に関する空間，測度空間ですね

もう無限に既出っぽいネタだ

@yantene でもたぶん型クラスのクラスは集合論のクラスから来てるので数学的構造とはまた別です

@omasanori よく考えると reviewed-by も付けられてたかもしれないけどもうわからなくなってしまった（コミットログを漁ればでてくるとは思うけど）

群・環・体とかの基礎的な代数的な構造については大学の 1 年生とかでまあやるよね

@yantene しかし型クラスとかもそうであるように，例えば順序について定めた順序的構造とか，あと，位相空間についての位相的構造とかも数学的構造には存在するし，それらの構造のメタ的な構造として圏論の圏もあるので，Interface かと言われると違うところもあるよ，という

@yantene これはたとえば任意の実数という型について，Haskell の型クラスや Rust の trait みたいに制約条件を與える，というのにちょっと近い。で，型クラスとかもよく Java 他の Interface に類似されるので，そういう意味では数学的構造はインターフェースっぽいもの，と言えなくもない

@yantene この，構造の公理系を使うと，（つまり線形性を利用すると）いろいろ便利なことも多いし計算機の数値計算や機械学習でも線形性を仮定することでアレコレやるけれども，

@yantene つまり，零元があることと，任意の元について加法やスカラー倍をしてもベクトルになる（つまり，それらの演算について閉じている）という，“構造”が存在する集合，ということになる

@yantene たとえば，線形空間というときの空間というのは，集合に数学的構造を導入したもので，線形空間は集合の元がベクトルである
（つまり空間 V について，
0 ∈ V;
v1, v2 ∈ V なら v1 + v2 ∈ V;
v ∈ V かつ c ∈ ℝ について cv ∈ V
が成り立つということ）
が保証されてる

@yantene そうと言えばそうかもしれないけど微妙に違う気がする（概念の話を実装論で捉えてもどうしてもズレしか発生しなさそう

@yantene インターフェースというと何と何に対してのインターフェースなのかさっぱりなので例えがわからん

OSv ではレビューの結果に signed-off-by がつけられてた（けど LKML だとちがうみたいね

@yantene （これは代数的構造の話なので数学的構造と言うともっと広いか

@yantene 数学的構造のことでは（ざっくりと，間違ってるけど平易な表現としては，一定の演算が定義されている（備えている）数学的な集合のこと）

いや signed-off-by もあるじゃん

でもたしかに LKML は reviewed-by とか acked-by でした

signed-off-by もあるよ，ウン

私は OSv のパッチは投げたけど LKML にはパッチを投稿したことなくて経験不足です

いや，pull-req のページでちゃんと議論してパッチを review しなさいという話である

LKML のような ML で議論するパッチって結構 reviewer がちゃんと議論を重ねて数人決定権を持つコミッターが signed-by を付けてようやく merge されるので結構良いと思ってる。GitHub の issue+Pull-req のワークフローはすごいフットワーク軽い代わりにアレゲなパッチもガンガンマージされるし

良いですね

このパッチの番号は，git-format-patch(1) を使ってコミットの範囲を指定してパッチを出力すると勝手にナンバリングされます

LKML のパッチだと，例えば，
https://lkml.org/lkml/2017/11/3/606
みたいに [PATCH 00/15] と 0 番目になってるのはパッチじゃなくてパッチのシリーズ全体の説明でここに問題とその解決を論文とかくらいに論理的にわかりやすく記述して，
その次に
https://lkml.org/lkml/2017/11/3/607
と個々のパッチについて説明+パッチ本体というのがある

まあでも GitHub pull-req 主体なら issue 使えよと思います

まあ開発フローに寄るというのもある（Linux なんかだと絶対 GitHub を使った開発フローはやらないからパッチのコミットメッセージはもっと長くなるしどういう問題があってどういう解決をしたかはパッチのカバーに書くことが多い（個々のパッチにはパッチの個々の修正の説明を書く

This account is not set to public on notestock.

しんまつようこそl

This account is not set to public on notestock.

This account is not set to public on notestock.

まあどっちのコミットも既に master に merge されてるんだし，ueno さんがこうせいって言わなかったんだろうからこれはこれで問題はない（が，今後は少し直すと良いよ

https://github.com/ueno/libskk/commit/7fffd6dfdcc36979bd2fcbbf42d89ac282c58a98
とかはエラー文の情報とかバージョン情報は〜云々は issue を開いてそこに書くべきで，Pull-request のほうには
"travis: fix to pass test corectlly #issue番号 "
だけで良さそう

https://github.com/ueno/libskk/commit/fb7162f697367f513a13ee19e6f1743c8cb90dce
も，
"travis: reduce unnecesary package"
って書いた後に，その下に空行挟んでから，
coveralls が repository を見つけられないから gem install する必要があって云々を書くべき。
あと BUILD_OPTS がわからなかったとかは書かなくても良い（不要な情報だから。もしBUILD_OPTS に何か追加したい人がいたらそれはその人がやるでしょうから）

たとえば
https://github.com/ueno/libkkc/commit/e5adcf4523d4ba70c464ad4af572fcf0ad17d3d8
は
"travis: Switch to use Docker with Fedora image"
みたいに書かれてるよね

そうね，本来は一行で abstract みたいにして書いたあとに，行空けてその後に why を中心に書くべき（どういうパッチなのかはパッチを見ればわかる）

This account is not set to public on notestock.

ueno さんのコミットメッセージみる感じ元々からしてコミットメッセージが雑なプロジェクトぽいから今回は気にしなくて良さそうだけど

そう。たとえば travis-ci についてなら，
travis-ci: なんちゃらかんちゃら
みたく対象のサブシステムとか機能とかをまず書いてコロンで区切って，そこから詳しく書く（この場合は英語）とかのほうが良かったりする

This account is not set to public on notestock.

あと，プロジェクトをホストしてる ueno さんが何も言わないからたぶんこれは良いとは思うのだけど，コミットメッセージも本当は他のコミットに合わせたほうがいいですね

あとインデントの文字を変えるコミットが master に入るのよくないし本来は最初からそうしとけよ的なうっかりミスを修正するコミットは最初のコミットと合体させたほうがいいと思った

他のコミットに粒度を合わせて

This account is not set to public on notestock.

アーク・リアクター作るしかねえな

高速前進マージ

いや要らないな

おうち融合炉欲しい

git fetch origin/master からの git rebase -i

rebase は強力だけどすでに push したコミットの歴史まで改変すると push のとき -f するしかなくなるし多人数のときにそれは絶対にダメなのでご利用は計画的に

なるほど太郎

党大会は 10/24 には終わったよ

指導部に入るのおかしくない？

This account is not set to public on notestock.

LHC の規模感ハンパないな

これリニアモーターカーのレール

上海のリニアモーターカー乗れなかったのすごい心残りだったけど，車で空港まで移動してたら高速道路の本当すぐ隣にリニアのレールが走ってて，特にフェンスとかちゃんとしてるわけじゃないのにあの距離で 431 km/h 出す物体が走るのかとか思ったら非常に怖かった（あとしかもレールは永久磁石）

50 Hz/60 Hz 問題とか些細だったなとか思える

中国，共産党パワーではよ電気プラグ形状を統一してほしい（7 種類くらいある）

中国に渡航してたときほぼほぼ全てのトラヒックを自宅の VPN サーバーに流してたのグリーンコンピューティングの視点から言えば最悪だと思う

カッパーとファイバーどっちが通信路の消費エネルギー低いんだろ（グリーンコンピューティングとかまるで興味ない（ひどい）のでよくしらない）

バカ話してるけど月曜までにジャーナル書き進めないとやっぱりシバかれそう

MATSUDAI だと厳しいけど MAZDAI ぐらいならなんとかなりそう（略称のこじつけ）

天才か？

This account is not set to public on notestock.

まず女装モノ OS ってなんだろうな

絶対指導教官にシバかれる

晒されちゃう

今後やる研究ネタのプロジェクト名を Joso とかにするか

絶対最強の女装モノ OS を作って SOSP で報告して強者になりてえ……

This account is not set to public on notestock.

This account is not set to public on notestock.

上海交通大学の Haibo 教授とかヤバいんだよな，たぶん 30 代に入った直後くらいで中国工学系の最高峰の大学で教授職だし

SOSP の併設ワークショップのうちひとつ，AI workshop に何故か Tensor Flow の作者とか iwiwi 氏とか来て喋っててヤバかった

OS とは？？？？

SOSP '17 の Best Paper Award の片割れです >> [1705.06640] DeepXplore: Automated Whitebox Testing of Deep Learning Systems https://arxiv.org/abs/1705.06640

programmable NIC とか NVMM とかディープラーニングとかだったよ今回の会議

私も libOS の末裔ぐらいしか追えてない（Symposium of Operating System Principles なのにディープラーニングのテストフレームワークの話が初っ端に来てしかも best paper award だったからもう OS わからん）

筑波のリサーチ OS，新城先生ところの世界 OS とか？

この前の SOSP の併設ワークショップで Rust ネタが二報と，SOSP 本体でも Rust への言及みたいなのが一報くらいあって，さすがにあのレベルの会議の参加者が注目するレベルだと結構 Rust はイイ線いってるっぽい気がする

分散 OS は一度時代に敗北したからねえ。タネンバウム教授の Amoeba OS もどっかいったし

This account is not set to public on notestock.

UEFI の公式サポートのアーキテクチャとかにも RISC-V 入ってるぽいしちょっとがんばりそうじゃない？

かなしい……

あと，今の Intel 64 アーキテクチャの CPU（Core i7 とかね）はマイクロコードとかは RISC っぽくなってるし Arm や MIPS は CISC みたいな複雑性を持ちはじめてるし，CPU アーキテクチャの分類としては RISC と CISC というの意味がもうなくなってる

RISC-V は RISC と CISC みたいな話の RISC じゃなくて，Arm とか x86_64 とか MIPS とかみたいな感じのアーキテクチャ名のひとつだよ

私がいってたんじゃなくて NEC のひとがいってた

こう，デバイスの刷新の嵐のなか，RISC-V も芽がありそうみたいな話をこのまえしてた

DL 販売とかくべきだった

主人公ボイス付きの版がオンライン販売にこないから「乙女理論とその周辺」も「月に寄り添う乙女の作法2」もまだできない

技術系ぽい話題してるけど技術がないし技術系ではない

100 GbE とか不揮発性メモリとかデバイスの刷新が大量に巻き起こってて全ての OS が時代遅れになりかけてるのだ，パタヘネのどっちか，たぶんパターソン先生とかも OS を新しくイチから作る時代に来てるとか言い続けてる

いや，会議のほうは一応国際会議と銘打たれてたけど日本語で publish しちゃったししょぼしょぼなので個人的につらい

業の績，日本語の会議論文一報と国際会議のポスター一回しかないからもうダメ

Facebook の LevelDB も，Key-Value Store だけどメモリとストレージで階層を作っていい感じにやるやつだけど，最近は階層がどんどん増えてるからそこに合わせないといけないのだなあ。昔は DRAM か HDD かしかなかったけど

バイトアクセスじゃないとダメだし，トランザクションとかやるのに DB なら当たり前のログとかを取り入れるのもそうだし，NVMM だけじゃなくて SSD/HDD と階層を作るのも必要だよね，みたいな

NOVA の問題意識はそもそもの物理的なファイルの扱いにあって，今は SSD/HDD が主流で，あいつらはブロック単位でアクセスできるけど，不揮発性メモリはメモリなんだから 1 バイト単位でアクセスできるんよね。だからファイルシステムもそこに合わせて再設計が必要

@babukaru （不揮発性メモリがないマシンだと全然意味はなさそうだけど）試すだけならすぐ試せるよ https://github.com/NVSL/linux-nova

USENIX FAST '16 の NOVA の論文より

BtrFS でも不揮発性メモリがデフォルトになってくるとクソ遅いんすなー。 >> https://mstdn.maud.io/media/ZvRM6stRswP_J3LmCwo

@omasanori でもこれでも超一流会議で OS 系最高峰カンファレンスである SOSP にペーパーを通せてるんだから何も言えねえって気持ち

@omasanori https://pdos.csail.mit.edu/papers/scalefs.pdf MIT の ScaleFS だった。ext4 みて，「Linux の FS はコアスケールしない，だから memFS と diskFS の二つを用意してキャッシュラインコンフリクトを避けてさらにログ操作を活用していいかんじにしたぜ，みたいなネタだった。論文でも比較対象が ext4 しかない上に scaleFS は xv6 をスケールするよう改造したリサーチ OS の sv6 に実装されてるんよね……。

@omasanori その時は比較対象が ext4 だけとかでエッてなった記憶

ext4 はフォーマットの mkfs のときに -j オプションでジャーナリングをつけると多少はマシになる

NOVA の良いところは，近年の SQL サーバーは必ずやってるログ書き込みによるトランザクションを OS のファイルシステムに取り入れた上で，Non Volatile Memory（不揮発性メモリ）と SSD／HDD で階層を作って両方をいい感じに使い分けて高速かつ安全な FS を実現してるとこですね

歴史で言うと ext4 より XFS のほうが古いというのはそう（sgi が IRIX のためにつくったので）

ところでさっきの NOVA について，SOSP の発表は ACM の論文だから有料だけど，USENIX FAST での発表は論文タダで読めるので読みましょう >> NOVA: A Log-structured File System for Hybrid Volatile/Non-volatile Main Memories | USENIX https://www.usenix.org/node/194455

ext4 つかうくらいなら XFS のほうがいい

ext4 を任意のファイルシステムの藁人形にするな

SOSP で ext4 を引き合いに出してる人がいて，それフェアじゃないじゃんとか思ってたら案の定質問サイト（学会発表だけど質問サイトとかが公式サイトにリンクされてておもしろかった）で ext4 はちょっとみたいなの言われてておもしろかった

ext4 とかもダメだよたぶん

HDD 前提のファイルシステムは近年の NVMM のような高速なストレージで破綻することが知られており，システム系の学会でもよく新しいファイルシステムが発表されている

This account is not set to public on notestock.

枯れてる幻想

パッチがでかくて入らないのは，ちゃんと機能ごとに分けたり，あるいは一部の機能を削るなどをして，全体に利益があることを主張し，丹念にコミットメッセージで説明を書くしかない

学会発表のスライドで喧嘩をするな

SOSP 2017 のストレージセッションはとてもよくって，Strata の人が次に発表控える NOVA を「あいつはスループットはいいがレイテンシがダメ」って実験結果のグラフ付きで殴りに行ったら，NOVA の発表で，「Strata はフォールト・トレラントを考慮してないからアイツはダメ」って殴り返しにいってたところがとても好き

NOVA，プレゼンで Linux に入れるぜつってたけどなおたさん曰く LKML を見るとパッチがデカすぎてまだまだ mainline 入りは長い道のりだとか

NVSL/linux-nova: NOVA is a log-structured file system designed for byte-addressable non-volatile memories, developed at the University of California, San Diego. https://github.com/NVSL/linux-nova

あー，パッケージ管理ネタでもやってくるな

This account is not set to public on notestock.

ファイルシステムなんですが，この前 SOSP 2017 で発表された Strata と NOVA，いいと思います（後者は FAST '16 でも出てた）

Android 向けの SKK はフリックに特化してなくて QWERTY だったりそもそも古かったりしたはず

なおたさんが飛んでくるのはカーネルネタと，一部の仮想化や OS やファイルシステムに纏わる研究ネタ（論文の URL 投げてくる）のと，Btrfs と，SF と，新左翼や学生運動ネタ

FlickSKK 使いはじめは記号の位置全然違う！ってなったけど今はまあわりと慣れた

This account is not set to public on notestock.

（フィーチャーフォン互換の入力はむしろ邪魔だから切ってる）

最近スマートフォンだと Qwerty よりフリックのほうが英字の入力も速い

Emacs つかわないから C-x C-c をそんなにつかわない

This account is not set to public on notestock.

たしか東京に来てから二年目の秋頃に和服着はじめてて，つまり二，三年ぐらいしか着物着てない気がするのですが，彼の人のキャンパスでは「あの着物の人」と言えば通じるらしい

スマートフォンは完全にフリックと SKK ですね（iOS）

Dvorak と Vim，キーマップのあれこれが面倒くて結局 Qwerty つかってる（そんなに面倒なくサクっと変更できるのはしってるけどやる気なし

なおたさんこの前の上海で私の指導教官に着物でないことを弄られてた（風邪を引いたらしい

それこそ SF の話もけっこうなおたさん造詣が深い（あと新左翼とか学生運動も）

なおたさんは漢直ユーザーだったから ThinkPad X1 Carbon の画面が割れたときにも自宅の Emacs サーバーにログインして Twitter に漢字かな混じりでツイートできた逸話を持つ

Dvorak ね。

かな入力も派生があって，親指シフトの NICOLA とか，他にも月配列なんてのもある

強いて言うなら QWERTY 使ってると QWERTY の配列が覚えられるので英語で入力が覚えやすいぐらいでは

ローマ字入力の利点，とくない

s/漢字直接変換/漢字直接入力/

かな入力の人そこそこ居るし親指シフトガチ勢も Twitter とかに生息してるよ

かな入力でも結局漢字変換は必要なので，かなの入力が 2 ストロークになる変わりに全ての漢字の入力も 2 ストロークになる漢字直接変換が良いですね。T-Code とか。

ワープロガチ勢世代だとむしろローマ字入力できない人が多そうな。もう 50 代〜60 代だろうけど

デューンは不毛の砂漠地帯やそこで脅威となっている巨大サンドワームが出てくるのですが，「スターウォーズ」でスカイウォーカー親子の故郷になってる砂漠の星とか，ファンタジーもので砂漠に巨大ワームが出現するのも，デューンがイメージの大元なんですな

とりあえず「デューン／砂の惑星」はオススメ，来年再度映画化するし。で，来年のデューンの映画の監督が「ブレードランナー 2049」の監督もしています。ブレードランナーはサイバーパンクの古典だし，フィリップ・K・ディックによる原作，「アンドロイドは電気羊の夢を見るか？」も名作なので読みましょう

最近色々 SF の古典を読もうとしてはいるけど広すぎて難しい