10年ぶり?くらいにデスクトップを新調しました

デスクトップで使っていたマシンが壊れた。このときに買ったやつである。

kuenishi.hatenadiary.jp

この時点で2年経っているらしいので、2012年に組んだマシンらしい。ドスパラの購買履歴をみると 2012/09/17 となっているので、今日の時点でほぼちょうど9年経っている。構成は

1. マザーボード ASRock Z77 Extreme4(Z77 1155 ATX DR3)
2. CPU Intel Core i7-3770 BOX(1155/3.40/8M/C4/T8)
3. メモリ TRJ JM1600KLH-16GK(DDR3 PC3-12800 8GBx2)
4. メモリ TRJ JM1600KLH-16GK(DDR3 PC3-12800 8GBx2)
5. ドライブ(内蔵) Pioneer BDR-207MBK BULK(SATA BD12X ソフト無 黒)

みたいな感じになっている。GPUは当時はなくてオンボードだった気がする。そのあと ELSA GD750-1GERX(GTX750 1G GDR5) を2014年に買ったらしい。マザーボードのHDMI端子につなぐとディスプレイが映るので、どうやらGPUが壊れたらしい、と切り分けてGPUをまず捨てた。

f:id:kuenishi:20210914231837j:plain

で、使えなくて半年ほどノートパソコンで暮らしていたのだけど、ひょんなことから知人にGPUを譲ってもらえることになった。でそいつを代わりに刺してみたところ、起動しない・・・ああ電力がたりないのかな・・・ボコボコ刺さっているHDDを全部外してみよう・・・C少し経ったらやっぱり落ちる!ということで改めて電源を買い直しました。

www.dospara.co.jp

適当に選んだやつ( Corsair CP-9020196-JP (RM850 2019 850W) )。でこの電源を刺して動かしてみても、やっぱりChromeとSlackで落ちるやんけ!と、これ以上9年モノのマシンの故障箇所切り分けに時間を溶かしても無意味なので、諦めて残りを新調することにした。
Ryzen比較表【2021年最新】世代や種類別にRyzenのCPUを比較 をみるとAMD Ryzen 5 5600Xあたりがスペックがよい。Ryzen 7 5800Xもいい感じのコスパだったが、まあバチバチにゲームするわけじゃなし誤差やな・・・ということで安い方を選んだ。

www.amd.com

ちょうどドスパラでマザボと組み合わせセールをやっていたので適当にペアになっていた
ROG STRIX B550-F GAMING | ROG Strix | Gaming マザーボード|ROG - Republic of Gamers|ROG 日本 を選択。メモリは適当にDDR5 16GB x4 でちょっと奮発して64GBにした。CPUでちょっと節約したもんね。SSDは今回はSATAの在庫があったので流用。

1. Corsair CMK32GX4M2A2666C16(DDR4 PC4-21300 16GBx2)
2. メモリ !Corsair CMK32GX4M2A2666C16(DDR4 PC4-21300 16GBx2)
3. マザーボード N !ASUS ROG STRIX B550-F GAMING (B550 AM4 ATX DDR4)
4. CPU N !AMD Ryzen 5 5600X BOX (AM4/3.7GHz/35M/C6/T12/65W)

それが届いて…

こうして…

こうじゃ!

Arch Linux にSteam入れてゲームできるようにしたら、今はかなりのゲームがLinuxでもできるようになってた、ってのはまた別の機会に。

Old Brains

そろそろ歳も40近くなり、老いについて考えることが増えてきた。たとえば10ヶ月も続く在宅勤務の中で少しでも運動をサボると左膝がすぐに痛みだしたり、うっかり水分を摂り忘れたりすると頭痛がきたりする。もちろん体重は史上ピークを記録し続けている。身体の老いについては、まあそういうものであるし、特に外見などに気を遣って生きてきたわけでもないからそんなには気にしていない。しかしながら、人間の人間たる由来はその精神や振る舞いにあると思っているから、そちらでの老いの方が問題だ。

前職までは大抵、わたし自身は年齢が1番か2番めくらいに若い職場で仕事をしていることがほとんどであった。ほとんど同年代か、10から20くらい上であることが多かったように思う。単に物理的な年齢もあるが、職業経験も私より長い人たちばかりであったので、教わることの方が多かったから、物事の考え方が揃っていたことが心地よかったということには、後から気付いたのであった。親切な先輩ばかりであったから、自分が一番の下手であるような職場に慣れてしまっていた。Erlang/OTPがすごいんですよと話したら「昔○○という技術があってね…」と諭されたり、分散ファイルシステムの歴史をまとめた資料を作ろうとしたら「SunOSのファイルシステムは・・」と昔話を聞いたこともあった。SSDが市場に出てき始めた頃に「SSDをやりましょう」といったらICカードに組み込もうとしたフラッシュメモリの辛い話を聞いたりと、比較的歴史の浅いと言われているコンピュータ産業に限っても、私の知らない歴史を無限に教わることができた。Javaで知らないことを聞けばすぐに誰かが教えてくれた。

ところが現職になって多くのことが変わった。周囲の同僚は全員が私よりも年下で、職業経験もわたしより浅い。だからといって能力的に劣っているということは全くなく、Ph.Dを持っていたりそのキャリアで成功していたりするわけだし、分野が違うこともあって私の知らないことを多く知っている。というか、何なら同僚だけじゃなくて、インターネット上で観測される多くの人が VSCode をコンテナプラグインやover SSHで使っているし、 Dockerfile や docker-compose.yml なんかは息を吐くようにサラサラと書いたりする。もちろんシェルプロンプトは何か絵文字が沢山出ている、簡単なPythonは全部 Jupyter Notebook 上で書いていたりする。 peco や ghq やらを使いこなしているし、 AWSやGCPもお手のものだ。何か問題があると「それAWSの○○でできるよ」みたいな趣旨のことを言う(わたしは理解できていない)。フロントエンドの話になるともうSappariで Vue とか Flutter とか React とか…あれ、こないだまでTypeScriptの話してなかった?え???みたいな状態である。

f:id:kuenishi:20201214221059j:plain
若者と技術的な話をしているときの私

一方で若者たちと話をしていると、ウォーターフォール開発について知らなかったり、Plan9という単語を聞いたことがなかったり、Docker以前のコンテナ技術について何も知らなかったりということがあるので、そういうときは聞かれたら知る限りの歴史をかいつまんで答えるようにはしていた。うーん世代差…だからといって仕事でやることが特に変わるわけじゃないし、ホモソーシャルな空間で仕事をしたいというわけでもない。まして古いものを押し付けたりすることはないけど、新しいことに日々挑戦しなくなっているという実感があった。むしろ軽い危機感だった。新しい技術に飛びつくことがいいわけじゃないけど、全く関心を持たないのはよくないんじゃないかと悩んでいたのだ。

ところがある日、GVRの "Really I don't recommend Emacs to new developers. It just exists for old brain compatibility." という一言を見かけた。

わたしの中のEmacs教原理主義者なんかは「ホラ見ろ!!Emacsでいいんだよ!」と一瞬思ったけれども、日を追うごとに、わたしの中の穏健派はこれで救われたような気がしていった。別に新しいものに無理やり挑戦することはないんだ、互換(≒できることが変わらない)なら無理にやり方を変えることもない、というわけだ。だからEmacsも使い続けるし、1stでないとはいえ2年連続で国際会議に論文を通すことができてしまったし、会社からも悪くない賃金を得ている。今までなんとなく持っていたちょっとした功名心というか自己顕示欲のようなものは徐々に満たされつつ薄まってきて、現状に満足し始めてしまったのかもしれない。

こういう風に満足してしまった状態は直感的によくないと感じていて、知らないうちに増長して同僚たちに迷惑をかけてないかどうかが不安になってしまう。例えば何か新しい要素技術Xが登場してきて、それはやってみる価値があるかどうかという話になる。私は昔の技術Yに似ているという第一印象を持つが、概要だけだと何が違うのかよく分からない。そのときにすぐ「昔のYと何がちがうの?」みたいなことを悪しざまに言ってしまうと、これはいわゆる老害というやつで、Xに挑戦しようとする若者の足を引っ張ってしまうことになるわけだ。妙な偏見のない状態で実際にやってみれば成功するんじゃないか?わたしが変なことを言って偏見を植え付けてはいないか?となるのである。こういうとき、どういう風にリアクションするのがよいだろうか?

新しい技術や製品はどれも、この歳になると最初に聞いたときは脊髄反射で「それオモチャじゃね?」となってしまうわけだ。わたしはこの言葉をいろんな人から聞いたが、自分でもそう思うようになってしまった。例としては、

  • TCP/IPが登場したとき「電話(回線交換)に比べたらオモチャ」
  • オープン系システムが登場したとき「MFに比べたらオモチャじゃん」
  • Linux が登場したとき「Solarisに比べたらオモチャじゃん」
  • MySQL が登場したとき「トランザクションないじゃん」
  • MacOS 10 が登場したときの「Windowsじゃないと仕事では使えない」
  • Gitが登場したとき「Mercurialでいいじゃん」
  • OpenvSwitch をはじめとするホワイトボックススイッチが登場したとき「そんなのオモチャじゃん」
  • AWS が登場したとき「たけえじゃん自分たちで買えばよくない?」
  • Hadoop が登場したとき「GCのある処理系で高信頼なミドルなんて作れるわけないじゃん」
  • 深層学習が登場したとき「ネコ判別してどうすんの?」
  • Kubernetes が登場したとき「Mesosでよくね?」

などなど、キリがないわけである。どれも最初に登場したときはオモチャなのだけど、これを面白いと思った人たちが集まってエコシステムが成長してビジネスになり始めると、それはオモチャを卒業していくわけだ。実際に大切なのはオモチャかどうかよりも、可能性があるかどうか、人が集まるかどうかの方が大切なわけだ。オモチャかどうかというのは極論すると見る側の主観にすぎないし、既存の技術の焼き直しであるかどうかもどうでもいい。重要なのはリソースが投下される価値があるかどうか、人々の問題を解決するかどうかだ。

その価値を見極めるために、過去の歴史を知っておくことは副次的に必要だけど、もっと重要なのは現在の技術やソフトウェアで何ができないかを知っておくことだ。現代の人たちがどういう問題を抱えているかを何かのきっかけで知ったときに、それが技術的に解決できるかどうか、解決できるとしてどれくらいの手間がかかるのかを即座に偏見なしに判定できるようになっていると、勢いはなくてもオッサンとしての価値は下がらないんじゃないか。いやいや偏見なしって、そんなことが簡単にできるならそもそも悩んでない・・・と思って今日もゲームに励んでいる。

Splatoon 2 (スプラトゥーン2) - Switch

Splatoon 2 (スプラトゥーン2) - Switch

  • 発売日: 2017/07/21
  • メディア: Video Game

これじゃダメだ。互換性がなくなったらゴミなんだからもうちょっとなんか勉強しようよ。ホラあんなに積読たまってるよ。と私のなかの真面目君は主張するのだけど、私のなかの怠惰君は「えーでも今日も疲れたよ・・・ビール飲みたい・・・」と言う。不惑とは何だったのか。ねえ孔子さん何とかして。

f:id:kuenishi:20201221105326j:plain
nikuyoshiさん@フリー素材

いかがでしたか?

この記事は pyspa Advent Calendar 2020 - Adventar の21日めの記事として書かれました。

Hiroki Uchida on Twitter: "(この画像はフリー素材です… "

NextDNSというサービスは子持ち家庭のインターネットを安心安全にする

tl:dr;

  • 子供にも安全にインターネットさせたいが、なるべく親がコントロールしたい
  • いままで /etc/hosts を工夫して狭い範囲でブラックリスト管理していたが運用が辛かった
  • NextDNS.io というサービスがやりたいことを全部実現していたので課金した

我が家には小学生と幼稚園の男児がいて、どちらもラップトップを持ってネットサーフィンをする。分からないことは自分で調べさせたりScratchでプログラミングさせたりして遊ばせれば、これが結構な時間潰しになる。わたしの古いMacBook Airを使わせたりしていたが、予算に余裕が出たタイミングで上の子にはMacBook Proを買い与えた。いちどそのMacにMinecraftをインストールしてやったらすぐに廃人になったので、さすがにそれはアンインストールして禁止した。おおよそ自由にネットサーフィンはさせているのだが、インターネット上での出会いは禁止したい。小学生や幼稚園児には早すぎるし、そもそもインターネット上のSNSなんてロクなもんじゃない。

基本的なリテラシー教育は「学校では教えてくれないこと」シリーズの 学校では教えてくれない大切なこと(12)ネットのルール | 旺文社 をいくらか読ませたら大体は理解するようだ。

学校では教えてくれない大切なこと 12 ネットのルール

学校では教えてくれない大切なこと 12 ネットのルール

  • 発売日: 2016/07/15
  • メディア: 単行本(ソフトカバー)

とはいえ放っておくとやっぱりYouTubeであれやこれやのサイトを見に行ってしまうので、ある程度コントロールしたいという要求がある。で、どうやっているかというと

1. OSの管理者権限は与えない、必要なアプリは親がインストールする
2. アクセスさせたくないドメインは /etc/hosts でloopbackを向くようにする
3. ChromeにはFamily linkで作ったアカウントでログインさせる
4. CloudFlareの 1.1.1.1 for Families を使って(親にとって)未知の怪しいドメインもブロック

という方針で管理していた。これには技術的にいくつかの問題があって、アクセスさせたくないドメインをいちいち /etc/hosts に前部下記並べないといけないのが面倒だった。ワイルドカードであるドメイン以下は全部禁止( e.g. *.youtube.com のような指定)はできない。

- name: Set up /etc/hosts, blacklist
  become: true
  lineinfile:
    path: /etc/hosts
    state: present
    line: "::1	{{ item }}"
    regexp: "::1	{{ item }}"
  loop:
    - twitter.com
    - mobile.twitter.com
    - youtube.com
    - www.youtube.com
    - ...

こういう感じのPlaybookを書いていつも実行するという、面倒なことをやっていた。

ChromeにFamily link 済のアカウントでログインすると言ってもSafariを使えばそういった問題は全部回避できるし、適当なブラウザをインターネットからダウンロードしてユーザーランドにインストールしてしまえば何だってできる。しかも子供がほしいといったアプリをいろいろインストールするのはとても面倒であった。mac OS のペアレンタルコントロールである程度アクセスを制御できるといっても、しかもこのペアレンタルコントロール、OSをアップデートすると設定が全部飛んだことがあった(Screen timeに切り替わったタイミングだったように思う)。泣きたかったが、儲なので涙をこらえた。

困っていたところに id:ymotongpoo に教えてもらったのが NextDNS だ。

nextdns.io

いわゆるフルスペックのDNSサービスで、Googleの8.8.8.8やCloudFlareの1.1.1.1のような存在に近い。しかし大きく異なるのは、サービス側でユーザーを認識して異なる設定に基づいたクエリ返答をすることができる点だ。

ほしかった機能

1. MalwareやPornなどぁゃしぃインターネットをドメインでブロックする
2. どういうドメインがブロックされたのか知りたい
3. ブロックされるドメインのリストをいい感じに賢くメンテナンスしたい(してほしい)
4. うちにある多様なOSのサポート: MacOS, Android, iOS, Linux
5. 大人と子供で異なる設定にしたい(端末毎に設定を変えることができる)

いままでAnsibleのPlaybookを書いて流すことで、上記のうちいくつかは実現できていたが、まあ面倒だ。SSHで入れるように設定しないといけなかったのもそうだ。

感動したところ

メジャーなOSをカバーしている

おうちの野良ハックで済ませるのが難しい iOSとAndroidに対応していて、アプリのインストールが簡単にできた。Mac, Linuxがどちらも使えるし、ソースアドレスを設定すればルーターにも適用することができる。家のトラフィックのほとんどのケースをこれでカバーできる(家庭内ユーザーが自分で他のDNSを使うとかはさすがにできない)。

さらに、OSだけじゃなくFirefoxやChromeなど、メジャーなブラウザにも設定することができる。

SNSをリストから選んでブロック

子供にはFamily linkでGMailのアドレスを与えているので、その気になればFacebookやTwitterで親の知らないアカウントが作れてしまう。しかも新しい趣向のSNSは次から次へと生えてくるので、それを簡単にブロックできるようにしたかった。その理想的な実装がNextDNSにはあった。設定画面にメジャーなSNSがリストされていて、それをポチポチを選ぶだけでブロックできる。

f:id:kuenishi:20200606111527p:plain
適当に選んでブロックしたSNSのリスト。トグルスイッチもついていて、一時的にサイトを選んでブロックを解除することもできる。

DNSクエリの統計情報

GAFAM率とかが出せる。端末ごとに統計を見ることができる。

f:id:kuenishi:20200606111339p:plain
統計情報の一部

f:id:kuenishi:20200606111237p:plain
GAFA Dominance

いろいろなフィルタを選べる

インターネットにはさまざまなドメインリストが落ちているので、それをポチポチと選んで使うことができる。しかしながら、個々人の要件を完璧に満たす禁止リストなんてものは落ちていないので、どうしたってブロックされては困るドメインもある。例えばうちだと子供がなぜかUnityを使うので、 "id.unity.com" にアクセスできないと困る。「このサイトは見れません」とブラウザに拒否されたら、DNSクエリのログ(しかもブロックされたものだけ)を見て、ドメインを禁止してるフィルタを選んで外すことができる。こうやってDNSのポリシーを要件に合わせてデバッグしていくことができるのは嬉しい。


個人用でも使える価格設定

無料枠は30万クエリまでで、それを超えると普通のDNSとして振る舞うようになるらしい。無料枠以上でも普通に使うためには 1.9USD/mo, or 19.90USD/y で、日本円だと250JPY/moという価格になる。年間2500円で適切にコントロールした家族の安全なインターネットが手に入るので安いと思って課金した。

ちょっとした不満点

  • ログインにMFAを設定できない
  • Macでの設定アプリはユーザーごとにやらないといけなくて、ユーザーが自分でEnable/Disbleを切り替えられてしまう
  • 野良のブロックリストをいくつか設定できるが、使いたいアプリが失敗したときに「ネットワークにつながりません」みたいなエラーしかでないので、いちいち管理画面でドメインがブロックされたログを探して原因になっているリスト設定を見つけないといけなくて面倒
  • ブロック可能なSNSにWhatsApp, Skype, ZoomがあるのにLINEがない

雑感

さて一週間使ってみたところ特に不満なく、これで家庭が平和でマルウェアもトラッキング広告も踏まないし、ニュースサイトをみていたら広告があったスペースに何も映らなくなる。広告はインターネットにとって重要な資金源だが、Webサイト利用者の有限のアテンションをとって思考をどうしても妨げるものだ。それがないと本当に快適になる。画像は asahi.com の見え方だ。→ 🔗

f:id:kuenishi:20200606110345p:plain
広告の映らない新聞社サイト( (C)asashi.com )

どこもそうだと思うのだが、ISPが提供するDNSはチラホラ遅かったり落ちていることがあって、そういうときにGoogle Public DNSとかCloudFlareのDNSを使うようにしていた。しかしまあDNSくらいISPにあるものが近くて速いだろうということで使っていたのだが、さすがにこれだけ付加価値のあるサービスがでてきたらもうISPのものを使っていられない。実際NextDNSはIP Anycastを使って世界中のASと接続しているので世界中どこでも似たような性能が出ると思う。NextDNSのCo-founderは凄腕のハッカーでNetflixの偉い人だったりするので、ビジネス面(サービスの継続性)でも割と大丈夫なんじゃないかって信用できると思う。

LinusがZFSにLKMLで言及した件

先日Linusが盛大にZFSを非難したことがインターネット・カーネル界隈の噂を駆け巡った。これをタイトルだけみたり本文をちょっと読んだら「ああ、LinusはZFSが嫌いなんだ」とか「LinuxでZFSを使うべきではない」といった理解をする人が非常に多いだろうと思う。Linusは当然Linuxユーザーにとって大きな影響力を持つ人物であり、多くのLinuxユーザーがこの理解のままでいることになりかねない。公私ともにZFSに頼りっきりになっている私は特にそういう状況は非常に困るし、Canonicalは19.10からUbuntu LinuxでのZFS rootを標準にしようとしているくらいだからもっと困るだろう。複雑な状況になっていると思うので、このニュースの深層を探ってみよう。

まず元スレ

元になったLinusのレスによると、そもそも最近カーネルにドライバのインターフェース変更があってZFSがこれで大きな影響を受けたとのこと。カーネルのFPUのインターフェースがGPL-onlyと宣言されたことでZFS on Linuxは非常に困っている。これについてLinusに「どう思う?」と質問があったという流れだ。

  • 「ユーザーに影響を与えない」ポリシーはユーザー空間のアプリと、私が見ている範囲のカーネルについての話だ
  • 外部のカーネルモジュールは対象外で、その面倒までは見きれない
  • Oracleの法務かLarryがサインした書類がなければZFSに関するコードは一切マージしない
  • それどころか、shimみたいなのも一切入れる気はない、Oracleのインターフェース著作権(Javaのアレとか)のことを考えればライセンスに関して落とし所はないだろう
  • ZFS使うなよ。バズワードでしょ。ライセンスの問題がある限りは一考に値しない
  • ベンチマークもそんなにいいと思わないしそもそもメンテされてないんじゃね

という要旨で、まあZFSのことそんなによく知らないのかな?と思ったら、これに対する反応はだいたい次のような感じ。

  • カーネルモジュールのことは仕方がない、サードパーティだしね
  • マージされるとかshimがあり得ないとか、それも当然そうだと思う(より安全だしね
  • VM動かす系のユースケースだと使いやすい類似のファイルシステムはBtrfsしかないんだけどちょっとね…
  • VDO+thinp+XFSみたいなので頑張れなくはないけどそれでも機能がたりない
  • わたしのワークロードだとARC?が効いてページキャッシュがめちゃヒットして性能出る
  • いやOpenZFSむっちゃアクティブだよ!!!

これに対して、OpenZFSについてLinusから返事が(わたしの超訳です)。

  • ZFSといったらOracleのやつに決まってんじゃん!メンテされてないでしょそっちは
  • OpenZFSがアクティブなのは知ってる。でも著作権リスクについては同じことだよね

ここでスレは終わっている。つまりOpenZFSについては法的リスクだけを懸念しているわけで、他のことについては何もいってない。まとめると、ZoLユーザーは法的リスクを理解した上でZoLを使っているということになる。OracleのオリジナルのZFSについては、ZoLユーザーは関心はないだろう。

ZoLの法的リスクについて

これについては、Canonicalが一応の結論を出している。今年の8月にUbuntuがこれからZFSやっていくぜと宣言したときに、2年前に大丈夫だという結論を出したとかいている。ここは簡単に結論を引用しておこう。

While the CDDL and GPLv2 are both “copyleft” licenses, they have different scope. The CDDL applies to all files under the CDDL, while the GPLv2 applies to derivative works.

The CDDL cannot apply to the Linux kernel because zfs.ko is a self-contained file system module — the kernel itself is quite obviously not a derivative work of this new file system.

And zfs.ko, as a self-contained file system module, is clearly not a derivative work of the Linux kernel but rather quite obviously a derivative work of OpenZFS and OpenSolaris. Equivalent exceptions have existed for many years, for various other stand alone, self-contained, non-GPL kernel modules.

私もこれで大丈夫だと思うんだが、まあOracleが何をやってくるのか分からないということに関しては同意しておこう。ただまあOracleが訴えたのはクラウド事業で競合関係にあるどころか数歩先を行く先行者のGoogleで、かつGoogleは基幹の事業ではめちゃくちゃ儲かっているとか、いろいろ条件が揃ってこうなったんじゃないかというのが私の推測だ。Javaのアレはこちらの解説が詳しいので深くは踏み込まないが、あのときはDalvikがすでに標準化が進んでいるJVMの仕様について、それの実装を作って利益を得たという状況だった。ZoLだと少し違って、LinuxがOpenZFSをライブラリ(VFSのひとつ)として利用している形態になる(しかも配布は別々で、ユーザーは自分でくっつける)。

まとめると

  • Linusが非難したのはOracle ZFSであってOpenZFSではない
  • とはいえLinuxにZFSがマージされることはないだろう
  • Ubuntuはライセンスは問題ないと3年以上前に宣言している

あたりが事実。

ちなみに、Oracleが公開しているZFSのドキュメントはLinuxの他のどのファイルシステムよりもよく書かれている。個人的には、ZFSはLinuxが標準で用意しているどのファイルシステムよりも必要な機能が揃っていて安定していて使いやすい(それゆえにシステム管理者から絶大な人気がある)ので、このまま使い続けられる状態であってほしい。FreeBSDみたいに標準でROOTにできるようにしてほしい。ZFSは割と無茶なオペレーションもやり遂げられるので安心感が違う。

(追記)見返したらタイトルが煽りっぽかったので変えました

(追記2)より詳しい解説が出ていた:
Linus Torvalds says “Don’t use ZFS”—but doesn’t seem to understand it

コードを書いて金を稼ぐ

初めてまともに携わったシステムはNTT研究所で作られていたCBoCといわれるものであった。内容について詳しくは述べないが、国内では割と先進的でありながらとにかくNTTの事業会社(割と稼いでいる)で使えるものを作ろうというものであった。この時期は研究所は研究だけしていればよいというものではなく事業貢献が求められており、論文になるような研究を生み出すだけでなくそれをどうやってビジネスにするかが重要視されていたのだと思う。このとき作ったものは実際に事業会社で使われ、退職の前後には年間数万円が口座に振り込まれるようになっていた。なお収入なので税金の扱いを間違えないように。しかし特許といえばガッポガポ…というイメージだがそんなに当たることはない。わたしが携わったそのソフトウェアは確かに使われていたが、事業会社のビジネスの中核を支えていくようなものにはならなかった。ならなかったのでメンテナンスフェーズというやつに暗黙に入っていき、投資は徐々に細くなっていった。これから金と人を投入してさらにスケールさせていくというタイミングでそうなったのには諸事情があるがとても口惜しかった。

さて開発に携わったとはいえ、大きなソフトウェアを大人数でスクラッチから開発するには多くの分業が必要になり、その多くの職種のうちわたしは最上流のアーキテクトのような立場になった。要求条件と仕様をまとめて、背景にあるベース設計を考えて伝えて、基本設計書をまとめてもらい、さらに詳細設計をレビューしたりコードをレビューしたり、協力会社が常駐できる環境を整えたりするのだ。何とかSubversionまでは用意したが、HudsonやBuildbotまでは用意できなかった。コードを書いたりコンピュータを動かす以外の仕事が沢山あり、それらを順番にこなしつつ、Subversionを監視しながら日々追加される大量のソースコードに圧倒されていた。

 

次に関わったのはJubatusというソフトウェアだ。これは小規模なスタートであったから、最初の学習器のベース実装を確かOさんとUさんに作ってもらってサーバーに乗せて分散化する設計と実装をやった。今度はうって変わって精鋭たちとサクッと実装してサクッと動くものができた。このときTさんとペアプロして、まともなC++の書き方を初めて学んだ。大学の研究室でつくるようなのりだ。これで稼ぐソフトウェアが作れたのだろうか?という疑問の通り、実装はしたもののなかなか実用化には至らなかった。これは理由がいくつかあって、まずはそもそも先進的過ぎたということと、機械学習でしかもオンライン学習でなければならないアプリケーションは実は世間にはあまりなかったのだということが、あちこち営業して廻って気付いたことだった。

技術開発には大きくわけてシーズベースのものとニーズベースの方法論があるが、どちらもビジネスや社会の現場の知識や経験がないと、最終的ては金にならないという当たり前の話である。当たり前の話であるが、とにかくモノがなければ始まらないので、作ったこと自体は間違いではない。それでもJubatus自体はニッチでもユースケースを見つけ、いくつか?のサービスで使われたらしいとは退職後に聞いた。10年近く経った今でもメンテナンスされているようだ。

 

転職して次に関わったのはRiakというソフトウェアだ。これはErlang/OTPで実装された分散データベースであり、これもまだ市場には普及していない新しい技術を実装したものであった。アメリカ東海岸のスタートアップであり、アメリカに多くの顧客を抱えておりこれから日本にも進出するという。今度はある程度実績のあるソフトウェアに関われるということで興奮していた。これなら日本でも多く使われるようになって、自分の書いたコードが稼ぐようになるんじゃないかと思った。実際に顧客からの要望を受けて機能開発をしたりしていた。途中からRiak CSというファミリー製品のテックリードとなり製品にある程度責任ある立場となり、ますますコードを書くようになった。CEOが日本にやってきて外国の某社に数億円でライセンスが売れたと聞いたときはとても嬉しかったことを覚えている。結末は皆さんご存知の通りで、少し売れたくらいではソフトウェア作って食っていけるわけではなく、数年かけて最終的にその会社はなくなってしまった。

 

次に作ったソフトウェアはRetzというApache Mesosにジョブスケジューラの機能を追加するものだ。今でこそKubernetesが全盛だが、先発のソフトウェアが必ずしも覇権をとるわけではないしそもそもあるソフトウェアが永遠に使われ続けることなんてないのだ。当時はMesosが最新で、データセンタースケジューラーが市場で必要になると踏んでMesosに足りないものを補完するソフトウェアとしてRetzを作った。このRetz(とMesos)は金を稼いだか?まず単体ではNoだ。当時はクラウドネイティブという言葉がやっと出始めたばかりの頃でコンテナで全てのサービスを運用するなんて先進的すぎたし誰もやっていなかっただろう。今だってちゃんとできているサービスは少数なんじゃないかと疑っているくらいだ。未熟なソフトウェアで未熟な市場に切り込むのはハイリターンが期待できるが、ハイリスク低確率なのである。しかもバッチ処理というエンプラど真ん中のニッチな用途では尚更である。結局RetzとMesosが本番環境でみんなに使われたのは2例しかなかった。
ソフトウェアそのものを売って金にする時代はわたしは終わったと思っている。Sunが買収されMicrosoftもOracleもサービスを売り始めた。こういう例は枚挙に暇がない。ビジネス応用とデプロイメントが多様化しており、ユーザーに求められる能力や知識がどんどん高度化しているためだ。OSSじゃないといけないとか、エコシステムを育てるとかそういった問題ではない。

 

転職して次に開発することになったのはChainerだ。これは既に会社を支える最先端のソフトウェアであり、わたしが入社したときには十分に稼ぐソフトウェアになっていた。しかも、Chainerそのものを販売しているわけではなかった。これは日本ではなく世界で最先端のソフトウェアであったし、ビジネスで使えるアプリケーションをすでに生んでいた。わたしは書いたコードが使われることにとても満足していたが、論文の執筆に少しだけ関わってKDD著者にもなることができた。Chainerは獲得したユーザーからは厚い支持を受けたものの、その数には限界があって結局世界的な潮流に飲まれてしまった。

 

コードを書いてソフトウェアで稼ぐには、稼いでいるビジネスをコンピュータの力で支えるか、コンピュータやソフトウェアの力で新しいビジネスを生み出すかのどちらかしかない。これができている人を本当に尊敬するし、わたしにはビジネスは全然分からないし、コンピュータもよく分からない。できるのはそういう人に後ろからついていってちょっとお助けするくらいのものだ。コードを書いて家族を養うのはとてもとても難しい。

とても難しいが、キャリアを通じてそういう場所にだんだん近づいていってる実感はある。今までもそういう期待を持ってやってきたし、今作っているもの、これから作ろうとしているものもそういう期待があってやっている。先のことは分からないけど、どうやらそれしか能がないのかな?

りんごチャレンジ

先日都内某所で行われた秘密の会合の目的は、有志が一年間の進捗を共有するというものであった。私は減量を終えてから一月近く経過しており、しかも最悪なことに11月はほとんど怪我でトレーニングができていない状態だったため増量に入れておらず、特に報告できる進捗もなくトボトボと参加したのであった。みんなが進捗を確認しつつ談笑している中で @yuitowest が持ち込んだ秋映が机の上にゴロっと無造作に転がっていたのだが、いかんせん会場が会場なだけに特にナイフやまな板があるわけでもなく、どうやってリンゴを食べたものかと逡巡…していなかったのだが、リンゴを握りつぶすことで有名な @hiroki_niinuma がいきなりパカッと真っ二つに素手で割ってかじり始めたのだった。そこからは早かった。彼のように片手でリンゴを握りつぶすことはできなくても、両手を使えば割れるのではないか。そんな希望が湧いてきた。のでやってみた。


りんごチャレンジ day 0 (秋映)

そうできなかったのである。ワイワイ盛り上がっていたが、一緒にいた友人たちは次々とパカパカ割っていくではないか。私は焦った。焦っていくつもリンゴに挑戦し、その度にヘタの辺りを妙に凹ませたりベタベタにしたりするが結局割れなかった。そのとき割れなかった人も他に何人かいたが、全員が翌日までに「帰ってやってみたら割れた」というではないか。なんということだ。私はクソザコのままなのか。更に焦った。というわけで、翌日からトレーニングメニューを一新してリンゴを割ることにフォーカスした。主なメニューは

  • CoC G 親指ピンチング: 普段は親指の付け根で握るが、親指の第一関節と手のひらを使って握る。これは案外力がよわく、全然閉じることができなかった。
  • ケトルベル親指ピンチング: たまたま自宅に4kgのケトルベルがあったので、親指だけで持ち上げる。

である。これを数日間毎日続けた。とくに筋力が上がるわけではないが、日々神経が通っていくことを実感していた。「これならいける!」私は確信して今日、先日の会合の折に頂いて帰った秋映最後の一個を手にとった。


りんごチャレンジ Day 4 秋映

・・・

そうまたしても割れなかったのである。本当にクソザコだ。このままではダメだ。死ぬしかないそう思ったとき、撮影していた妻がおもむろに別室から別のリンゴを持ってきて私に手渡した。どれ、む、少し小さいな。手が余る。うーん割れるのかといいながら、また握った。


りんごチャレンジ Day 4延長線 シナノスイート

ええーこんな簡単に割れんの?!?!?!?まあいいやとにかく大勝利!!!!大勝利だ!!!111

私は上がりきったテンションでリンゴをかじる。シャクっと音がする。リンゴが好きな妻は家に大量のストックを持っており、その中のひとつがシナノスイートという品種だそうだ。こちらは秋映よりも小ぶりで軽め、さっぱりとした味だ。うんうまい。こうして私は大勝利をおさめ、今ここに筆を執ったのである。

…いや思ったよりサクッと割れたのでもう一回秋映に挑戦したのだが、こちらはどんなに頑張ってもダメだったので、妻に頼んで切り分けてもらい、家族で楽しく食べましたとさ。なお動画から音声を抜くのに使ったコマンドは次の通り。 "-an" オプションが、オーディオについては何もしないという意味になる。

$ ffmpeg -i VID_20191203_201430.mp4 -vcodec copy -an akibae.mp4

アドベントカレンダーは以上だ。今年は肉体に進捗なく、他に特筆することもまだなく、いよいよ不惑が近くなったが人格は特に成長せず、仕事でも進捗がなく、うーん…来年こそはいいことがありますように。明日はPythonの良心こと @aodag 先生だ。

減量記録2019

前回の減量は一年近くかけて、2018年の連休明けくらいまでかけて66~67kgくらいまで落としたのだけど、最後はたしか風邪を引いて、それを治すために終わりにしてそのままだった。そこから1年経ってまた75kgくらいまで戻ったので、また減量した。

kuenishi.hatenadiary.jp

今回の目標はあんまりはっきりとは決めていなかったけど、たしか6月に始めるつもりがダラダラ伸びて結局7月の始めに「ホラやるんでしょ」みたいな感じで妻に促されて始まった。なんでダラダラ始めなかったかというと、食事メニューがなかなか決まらなかったからだ。PuLPを使っていい感じに線形最適化されたメニューを組もうとしたのだけど、PFCだけをパラメータに食材を決めるとどうなるかというと、米とプロテイン粉末とMCTオイルだけの食事になってしまうのである。わたしはもうちょっと幸福に生きたいと思って、幸福度を最適化目標のひとつに入れようとしたり、もっと食物の選択肢を増やそうと食品成分表を持ってこようとしたりして回り道をしすぎていた。

妻が結局メニューを組んでくれて、最初は

  • 一日二食、鶏胸肉orささみと葉っぱをそれなりに12pmと8pmくらいに
  • ライスは360g/day, 120gずつオニギリor茶碗ひとつにして、昼2個、夜1杯
  • プロテインは9am, 3pm, 11pm で3回
  • トレ中はマルトデキストリン+BCAA溶液を入れる
  • 仕事中に腹が減ったら適当にアーモンドorプロテイン
  • トレは週2~3回、重量落とさずにrep数少なめで

みたいな感じにしていた。たしか1ヶ月くらいは内臓中の消化物がはけていくのと、水分が抜けるので順調に減っていったのだけど、結局脂肪と筋肉はあんまり減っていなかったように思う。停滞を感じたわたしは

  • ライスは300g/day, 100gずつオニギリor茶碗にして、 昼1個、3pmに1個、夜1杯

に変更した。これが一番効いて8月9月1杯まででおよそ5kgほど減って、水分が抜けた朝一番なんかは70kgちょうどくらいまでになった。ところがここからまた停滞した。9月終わりから10月頭にかけてである。外食もほとんどしていなかったしウーンわからんとなっていた。

トレーニングの内容も、満足度が低かったので少し内容を変えた。上半身とかをなんとなく広くやっていたのを、体幹系の種目に集中するようにした。二分割して、上半身と下半身を交互にこなすようにした。特に脚を重視して、最大重量を維持することよりも12〜15repできる重量をきっちりこなすようにして、翌日、翌々日に歩行困難に出るくらいになることを意識した。わたしの場合はバーベルスクワットは60~70kg程度だ。上半身のメニューでは大胸筋、僧帽筋のメニューを軸にした。あとはウォームアップにチンニングと、下半身強化のためのアブローラーをメニューの仕上げに入れることにした。これで体幹系の大きい筋肉のグリコーゲンを消費することを心がけたのである。腕や肩、膝より下はあまりやらず、体幹系のメニューをやって疲れる程度で満足するようにしておいた。

ちょうど微妙なタイミングで、右上7番の臼歯の再植手術をした。出血するし麻酔するし抗生物質は飲むしで、ようは静養が必要な状態になった。しかもそれに加えて、再植部分に雑菌が入らないようになるべく反対側の歯で噛むようにしなければならず、口内の衛生状態を保つために食後する歯を磨くことにした。オフィスでの食後の歯磨きは面倒なので、家で全部食事をとることにした。一日二食を少し運用を変更して

  • 一日二食、鶏胸肉orささみと葉っぱをそれなりに830amと8pmくらいに
  • オートミールは200g/day, 100gずつにして、朝夜1杯ずつ
  • プロテインも食事時のみ、一日2回
  • 仕事中も間食はなし
  • 安静にするためにジムなし

といった生活に切り替えたところ、さらに体重がおよそ-1kgくらいになった。トレーニングをしていないので筋肉も落ちただろうが、血糖値を上げずに食事回数を増やす(トータルの食事は増やさない)という常識ををうちやぶって、食事を一日になるべく固めるというのでもわたしくらいのレベルだと成果が出なくはなくてキープができるということが分かったのは収穫だった。

というわけで無事に今回の減量も終了。

f:id:kuenishi:20191101230242p:plain
まあまあ順調に減っている。4ヶ月で5kgくらい


今回実感したのは、カロリーを計算するよりも食事そのものをコントロールすることの方が重要だということ。以前ゴールドジム国立店でジャガー佐藤さんの「わたしはカロリーはあまり計算しないけど、ライスの量でカロリーをコントロールする」といった旨の話を聞いて「そんなもんかぁ〜」と思っていたのだが、今回はそれを強く納得できた。つまり、カロリーの書いてあるよくわからない既製品や外食よりも、自分で炊いた米の重さを量った方がいいということだ。毎日の変動要因をなるべく抑えて、観測と自分の感覚に耳を澄まして食事や生活にフィードバックしていくことが重要だということでもある。

追記

分散システムデザインパターン寸評

「分散システム」という言葉は大まかにいって複数のコンピュータが一つの系となって協調動作するようなシステムのことを指す。本書のお題はそのときにどういうパターンがあるかを解説するものだ。作者がKubernetesの開発者であることや、副題をみても、複数のコンピュータを使って大規模にスケールするサービスを設計するときに必要なテクニックを解説するものだ。

分散システムデザインパターン ―コンテナを使ったスケーラブルなサービスの設計

分散システムデザインパターン ―コンテナを使ったスケーラブルなサービスの設計

しかしながら、分散システムという言葉は狭義には「いつでも故障しうる」複数のコンピュータがひとつの系となって協調動作するシステムという強い条件がつく。その上で協調動作のなかでも最も難易度の高いコンセンサス(合意)という問題を解くことが、学問分野として長年研究されてきた。なので私もそのためのデザインパターンを記述したものだと期待してしまったのだが、そうではなかった。
分散合意(Distributed Consensus)は分散システムの中でもとても重要な問題で、これを上手く解かないと、Durability(永続性)のあるシステムを組むことができない。Durabilityのあるシステムとは、つまりデータを保存する能力をもったシステムやサービスのことを指す。これができていないと、例えばひとつのデータを保存したつもりが、読むときに各々のコンピュータが別の値を返してくることになる。

本書では、第一部から、第二部の8章まではずっと準備運動のようなもので、Kubernetesでよくあるデザインパターンつまり、いかに上手くシステムを組むかのノウハウが伝授される。例題もほとんどがステートレスなものだったり、コンセンサスやDurabilityが必要ないものだ。
9章だけはetcdを使った分散ロックの実装サンプルで、分散操作のプリミティブを組み合わせて別のプリミティブを組み合わせるという面白い問題だ。しかしながらロックを実装するサンプルになってしまっていて、実用的な場面について多くが語られているわけではない。それどころか、こう、わりとバッサリ切り捨てている。

マスタ選出は 2 種類の実装方法があります。1 つめは、Paxos や Raft のような分 散コンセンサスアルゴリズムを実装する方法です。しかし、これらのアルゴリズムの 複雑さはこの本の範囲を超えてしまっていますし、自分で実装するほどの価値はあり ません。こういったアルゴリズムを実装するのは、アセンブリのコンペア・アンド・ スワップ命令の上にロックを実装するようなものです。学部生のコンピュータ科学 コースの課題としては興味深いですが、普通は実践するようなものではありません。

バッサリと切り捨ててからロックの実装を解説している…が、実用性をめざすのであれば適当なライブラリを使ったらよいと思うし、 etcdのclientv3にはよいExampleが入っている。ここだけは中途半端で、実用性という意味ではちょっと物足りないし、原理の解説については始めから諦めているし、どうしてこのような章があるのかちょっと分からなかった。
実用的には、ライブラリを使うときのAdvisory Lockの問題点(Mandatoryにすることはできないので、コーナーケースを詰めきることはできない)を解説して、この上にリトライ機構を頑張って組んでアプリケーションのレベルで安全性を保証することを解説しないといけない。そこを乗り越えないと実用的にはならないので、ちょっと何というかメインディッシュを外された感じがする。

まあステート管理はすべてクラウドストレージとかマネージドDBMSでやるんだと割り切ればこういう話でいいのだろうし、本一冊の内容になるといえばなる。これまでの分散システムの解説本でそういうことが十分に解説されてきたか?といえばまあ疑問だが。。。

第三部ではバッチとか、オンラインじゃない処理をスケールさせるときの代表的な手法が解説されている。たしかにWebサービスやふつうのITシステムを組む上で必要十分かもしれないけど、ここ2年ほど深層学習目的のHPCクラスタ上で分散計算をしている身では物足りない・・・。

そういうわけで、本書は分散システムの最も難しくて重要な問題に切り込んでおらず、でもシステムを組む上で頻出する簡単なパターンを網羅している。簡単なパターンばかりなのでわりとアドホックに作り込むことができるものばかりだ(ライブラリや基盤的なシステムとして外だしする必要がない)。つまりタイトルの付け方がうまくて、もっとSpecificにつけるなら「分散アプリケーションデザインパターン」である。アプリケーションとは何だという話ではあるが、Kubernetes上でたくさんのコンテナを使ってサービスを構築・運用していきたい人には良書だと思う。私はそちらの方は疎いけど。。。


[1] リンク https://www.oreilly.co.jp/books/9784873118758/
[2] 原著 https://www.oreilly.com/library/view/designing-distributed-systems/9781491983638/
[3] Azure Download https://azure.microsoft.com/ja-jp/resources/designing-distributed-systems/en-us/