先日Linusが盛大にZFSを非難したことがインターネット・カーネル界隈の噂を駆け巡った。これをタイトルだけみたり本文をちょっと読んだら「ああ、LinusはZFSが嫌いなんだ」とか「LinuxでZFSを使うべきではない」といった理解をする人が非常に多いだろうと思う。Linusは当然Linuxユーザーにとって大きな影響力を持つ人物であり、多くのLinuxユーザーがこの理解のままでいることになりかねない。rootを標準にしようとしているくらいだからもっと困るだろう。複雑な状況になっていると思うので、このニュースの深層を探ってみよう。元スレ元になったLinusのレスによると、そもそも最近カーネルにドライバのインターフェース変更があってZFSがこれで大きな影響を受けたとのこと。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年前に大丈夫だという結論を出したとかいている。ここは簡単に結論を引用しておこう。modules.私もこれで大丈夫だと思うんだが、まあOracleが何をやってくるのか分からないということに関しては同意しておこう。Oracleが訴えたのはクラウド事業で競合関係にあるどころか数歩先を行く先行者のGoogleで、かつGoogleは基幹の事業ではめちゃくちゃ儲かっているとか、いろいろ条件が揃ってこうなったんじゃないかというのが私の推測だ。Javaのアレはこちらの解説が詳しいので深くは踏み込まないが、あのときはDalvikがすでに標準化が進んでいるJVMの仕様について、それの実装を作って利益を得たという状況だった。ZoLだと少し違って、LinuxがOpenZFSをライブラリ(VFSのひとつ)として利用している形態になる(しかも配布は別々で、ユーザーは自分でくっつける)。ZFSであってOpenZFSではないとはいえLinuxにZFSがマージされることはないだろうUbuntuはライセンスは問題ないと3年以上前に宣言しているあたりが事実。ちなみに、Oracleが公開しているZFSのドキュメントはLinuxの他のどのファイルシステムよりもよく書かれている。個人的には、ZFSはLinuxが標準で用意しているどのファイルシステムよりも必要な機能が揃っていて安定していて使いやすい(それゆえにシステム管理者から絶大な人気がある)ので、このまま使い続けられる状態であってほしい。FreeBSDみたいに標準でROOTにできるようにしてほしい。ZFSは割と無茶なオペレーションもやり遂げられるので安心感が違う。23:10LinusがZFSにLKMLで言及した件Tweetもっと読むコメントを書く2019-12-09コードを書いて金を稼ぐ初めてまともに携わったシステムはNTT研究所で作られていたCBoCといわれるものであった。内容について詳しくは述べないが、国内では割と先進的でありながらとにかくNTTの事業会社(割と稼いでいる)で使えるものを作ろうというものであった。この時期は研究所は研究だけしていればよいというものではなく事業貢献が求められており、論文になるような研究を生み出すだけでなくそれをどうやってビジネスにするかが重要視されていたのだと思う。このとき作ったものは実際に事業会社で使われ、退職の前後には年間数万円が口座に振り込まれるようになっていた。収入なので税金の扱いを間違えないように。特許といえばガッポガポ...というイメージだがそんなに当たることはない。わたしが携わったそのソフトウェアは確かに使われていたが、事業会社のビジネスの中核を支えていくようなものにはならなかった。ならなかったのでメンテナンスフェーズというやつに暗黙に入っていき、投資は徐々に細くなっていった。これから金と人を投入してさらにスケールさせていくというタイミングでそうなったのには諸事情があるがとても口惜しかった。開発に携わったとはいえ、大きなソフトウェアを大人数でスクラッチから開発するには多くの分業が必要になり、その多くの職種のうちわたしは最上流のアーキテクトのような立場になった。要求条件と仕様をまとめて、背景にあるベース設計を考えて伝えて、基本設計書をまとめてもらい、さらに詳細設計をレビューしたりコードをレビューしたり、協力会社が常駐できる環境を整えたりするのだ。何とかSubversionまでは用意したが、HudsonやBuildbotまでは用意できなかった。コードを書いたりコンピュータを動かす以外の仕事が沢山あり、それらを順番にこなしつつ、Subversionを監視しながら日々追加される大量のソースコードに圧倒されていた。次に関わったのはJubatusというソフトウェアだ。これは小規模なスタートであったから、最初の学習器のベース実装を確かOさんとUさんに作ってもらってサーバーに乗せて分散化する設計と実装をやった。今度はうって変わって精鋭たちとサクッと実装してサクッと動くものができた。このときTさんとペアプロして、まともなC++の書き方を初めて学んだ。大学の研究室でつくるようなのりだ。これで稼ぐソフトウェアが作れたのだろうか?という疑問の通り、実装はしたもののなかなか実用化には至らなかった。これは理由がいくつかあって、まずはそもそも先進的過ぎたということと、機械学習でしかもオンライン学習でなければならないアプリケーションは実は世間にはあまりなかったのだということが、あちこち営業して廻って気付いたことだった。技術開発には大きくわけてシーズベースのものとニーズベースの方法論があるが、どちらもビジネスや社会の現場の知識や経験がないと、最終的ては金にならないという当たり前の話である。当たり前の話であるが、とにかくモノがなければ始まらないので、作ったこと自体は間違いではない。それでもJubatus自体はニッチでもユースケースを見つけ、いくつか?のサービスで使われたらしいとは退職後に聞いた。10年近く経った今でもメンテナンスされているようだ。転職して次に関わったのはRiakというソフトウェアだ。これはErlang/OTPで実装された分散データベースであり、これもまだ市場には普及していない新しい技術を実装したものであった。アメリカ東海岸のスタートアップであり、アメリカに多くの顧客を抱えておりこれから日本にも進出するという。今度はある程度実績のあるソフトウェアに関われるということで興奮していた。これなら日本でも多く使われるようになって、自分の書いたコードが稼ぐようになるんじゃないかと思った。実際に顧客からの要望を受けて機能開発をしたりしていた。CSというファミリー製品のテックリードとなり製品にある程度責任ある立場となり、ますますコードを書くようになった。CEOが日本にやってきて外国の某社に数億円でライセンスが売れたと聞いたときはとても嬉しかったことを覚えている。結末は皆さんご存知の通りで、少し売れたくらいではソフトウェア作って食っていけるわけではなく、数年かけて最終的にその会社はなくなってしまった。Mesosにジョブスケジューラの機能を追加するものだ。今でこそKubernetesが全盛だが、先発のソフトウェアが必ずしも覇権をとるわけではないしそもそもあるソフトウェアが永遠に使われ続けることなんてないのだ。当時はMesosが最新で、データセンタースケジューラーが市場で必要になると踏んでMesosに足りないものを補完するソフトウェアとしてRetzを作った。このRetz(とMesos)は金を稼いだか?まず単体ではNoだ。当時はクラウドネイティブという言葉がやっと出始めたばかりの頃でコンテナで全てのサービスを運用するなんて先進的すぎたし誰もやっていなかっただろう。今だってちゃんとできているサービスは少数なんじゃないかと疑っているくらいだ。未熟なソフトウェアで未熟な市場に切り込むのはハイリターンが期待できるが、ハイリスク低確率なのである。バッチ処理というエンプラど真ん中のニッチな用途では尚更である。結局RetzとMesosが本番環境でみんなに使われたのは2例しかなかった。ソフトウェアそのものを売って金にする時代はわたしは終わったと思っている。Sunが買収されMicrosoftもOracleもサービスを売り始めた。いう例は枚挙に暇がない。ビジネス応用とデプロイメントが多様化しており、ユーザーに求められる能力や知識がどんどん高度化しているためだ。OSSじゃないといけないとか、エコシステムを育てるとかそういった問題ではない。転職して次に開発することになったのはChainerだ。これは既に会社を支える最先端のソフトウェアであり、わたしが入社したときには十分に稼ぐソフトウェアになっていた。Chainerそのものを販売しているわけではなかった。これは日本ではなく世界で最先端のソフトウェアであったし、ビジネスで使えるアプリケーションをすでに生んでいた。わたしは書いたコードが使われることにとても満足していたが、論文の執筆に少しだけ関わってKDD著者にもなることができた。Chainerは獲得したユーザーからは厚い支持を受けたものの、その数には限界があって結局世界的な潮流に飲まれてしまった。コードを書いてソフトウェアで稼ぐには、稼いでいるビジネスをコンピュータの力で支えるか、コンピュータやソフトウェアの力で新しいビジネスを生み出すかのどちらかしかない。これができている人を本当に尊敬するし、わたしにはビジネスは全然分からないし、コンピュータもよく分からない。できるのはそういう人に後ろからついていってちょっとお助けするくらいのものだ。コードを書いて家族を養うのはとてもとても難しい。難しいが、キャリアを通じてそういう場所にだんだん近づいていってる実感はある。今までもそういう期待を持ってやってきたし、今作っているもの、これから作ろうとしているものもそういう期待があってやっている。09:56コードを書いて金を稼ぐTweetもっと読むコメントを書く2019-12-04りんごチャレンジ先日都内某所で行われた秘密の会合の目的は、有志が一年間の進捗を共有するというものであった。私は減量を終えてから一月近く経過しており、しかも最悪なことに11月はほとんど怪我でトレーニングができていない状態だったため増量に入れておらず、特に報告できる進捗もなくトボトボと参加したのであった。真っ二つに素手で割ってかじり始めたのだった。彼のように片手でリンゴを握りつぶすことはできなくても、両手を使えば割れるのではないか。そんな希望が湧いてきた。(秋映)そうできなかったのである。盛り上がっていたが、一緒にいた友人たちは次々とパカパカ割っていくではないか。焦っていくつもリンゴに挑戦し、その度にヘタの辺りを妙に凹ませたりベタベタにしたりするが結局割れなかった。そのとき割れなかった人も他に何人かいたが、全員が翌日までに「帰ってやってみたら割れた」というではないか。私はクソザコのままなのか。いうわけで、翌日からトレーニングメニューを一新してリンゴを割ることにフォーカスした。普段は親指の付け根で握るが、親指の第一関節と手のひらを使って握る。これは案外力がよわく、全然閉じることができなかった。自宅に4kgのケトルベルがあったので、親指だけで持ち上げる。これを数日間毎日続けた。筋力が上がるわけではないが、日々神経が通っていくことを実感していた。「これならいける!」私は確信して今日、先日の会合の折に頂いて帰った秋映最後の一個を手にとった。・・・そうまたしても割れなかったのである。