DeepLで論文を邦訳して読んだ

以前日本からはDeepLは課金できなかったんですが、少し前にできるようになりました。

satoru-takeuchi.hatenablog.com

その記念といってはなんですが、Webブラウザのテキストボックスに入れた文書を訳すのではなく"Translate whole files"というファイルを丸ごと翻訳する機能を使ってみました*1

私が今回この機能を試す際に使ったのは"Decoupling Cores, Kernels, and Operating Systems"という未読の英語論文です。

www.usenix.org

なぜもっと一般的な文書ではなくわざわざ論文なのかというと、理由は2つあります。1つは単に他に別に読みたいものが無かったこと、もう一つは、未読の英語論文を計算機が邦訳したものをどれだけ理解できるかに興味があったからです。

さて、この論文はpdfとして公開されているのですが、残念ながらこの機能で現在訳せるのはwordのファイル、powerpointのファイル、そしてテキストファイルだけでした。しょうがないので次の方法を使いました。

  1. pdfをgoogle docsに食わせる
  2. docxにexportする
  3. docxをDeepLに食わせる

で、それっぽい日本語が出てきたので喜び勇んで読み始めたら、何を書いているか全然わかりませんでした。文法的に日本語として成立しているけれども何が書いてあるかはわからない、といったところでしょうか*2。技術カンファレンスにおける技術者ではない翻訳のプロによる同時通訳くらいのものを思い浮かべてもらうといいかもしれません。

「これで英語理解できなくても英語論文が読める!」なんというのにはほど遠いですが、翻訳ソフトはここまでできるようになったのか、と感心してしまいました。すごい。

最後になりますが、たぶん専門用語が少ない文書ならもっといいのが出てくると思います。

*1:無料版でも使えるんですが、文字数が限られるらしいです

*2:その後英語で一ページ目を読んだらちゃんと理解できる内容だったので、読解に必要な能力不足というわけではないはず

github sponsorでスポンサー募集することにしました

以前よりわたしはOSS、とくにLinuxカーネルなどのハードウェアに近い部分のものについての普及活動にライフワークとして取り組んできました。そのうちの一部は書籍として販売して印税を受け取ったり、雑誌に掲載してもらって原稿料を受け取ったりしてきましたが、ほとんどのものは無償で公開しています。この無償で公開している部分についてgithub sponsorsを使ってスポンサーを募ることにしました。

github.com

github sponsorsで支援を受ける人といえばOSSのコードやドキュメントへの貢献者というイメージがあるでしょうが、私はOSSおよびその関連技術についての普及活動をする人、として登録しました。なぜこういうことをするかというと、理由は大きく2つあります。

1つ目は単純に「お金ほしい」です。お金をもらわなければ活動をやめなければいけないといった切羽詰まった話では全然ないのですが、趣味とはいえ限りある可処分時間*1を費やして人のためになるであろうコンテンツを提供しているので、可能であれば対価を受け取りたいと思っています。

2つ目は私の好むお金の流れを作れないかなという実験です。私は常々、お金は余裕のある人や年長者から余裕のない人、若者によどみなく流れていくのがよいと思っています。この考えをもとに、私が提供するコンテンツが後進のために有用だと思ってくださるかたに支援していただき、コンテンツを必要としているかたがたに無償で提供する、というような流れが作れればと思っています。

スポンサーが増えたらどうなるかというと額にもよるのでなんともいえませんが、たとえば次のような展開が考えられます。

  • コンテンツの更新頻度が増える
  • いままで有償で公開しようと思っていたものを無償公開することが増える
  • youtube動画コンテンツを収益化しない(つまり広告を出さない)。現在は収益化条件を満たしていないので広告は出ませんが、いまのところ条件を満たせば収益化する予定でいます
  • コンテンツの英訳をする(現在はほとんどが日本語)

どうなるのかよくわかりませんが、わたしがやっていることに賛同してくださるかたはぜひご支援いただけたらと思います。

以下、いままでやってきたことリストです。

  • 書籍(有償)

www.amazon.co.jp

  • 技術同人誌(有償): 以下URLのうち著者名が「武内 覚」のもの

windhole.booth.pm

www.youtube.com

  • 記事の一部(はてなブログのものは検索性が悪いのでいずれgithub上にコピーする予定です)

employment.en-japan.com

Software Design 2018年5月号~2020年8月号に連載された「Linuxのしくみ」

satoru-takeuchi.hatenablog.com

satoru-takeuchi.hatenablog.com

satoru-takeuchi.hatenablog.com

satoru-takeuchi.hatenablog.com

satoru-takeuchi.hatenablog.com

satoru-takeuchi.hatenablog.com

satoru-takeuchi.hatenablog.com

satoru-takeuchi.hatenablog.com

satoru-takeuchi.hatenablog.com

satoru-takeuchi.hatenablog.com

satoru-takeuchi.hatenablog.com

satoru-takeuchi.hatenablog.com

satoru-takeuchi.hatenablog.com

satoru-takeuchi.hatenablog.com

satoru-takeuchi.hatenablog.com

satoru-takeuchi.hatenablog.com

satoru-takeuchi.hatenablog.com

satoru-takeuchi.hatenablog.com

satoru-takeuchi.hatenablog.com

*1:具体的なことをいうと私は週の時間のうち3/4は所属している会社の仕事に、残り1/4をこの活動に充てています

なんでもできるとおもわれがちな人ができないこと

はじめに

以下記事の続きです。実例編といってもいいかもしれません。

satoru-takeuchi.hatenablog.com

完璧超人とまではいかないでしょうが、わたしも次の理由によりSNSなどでは「いろいろできるすごい人」「低レイヤに詳しい人」と思われがちです。

  • Linuxカーネルに詳しい。カーネルに詳しい人は無条件でなんでもわかっていると誤解されることが多々ある
  • 自分あるいは自分が所属している組織の成果をよく宣伝する。このため、そういうことを好まない人に比べて「何かできる人」という印象がつきやすい
  • twitter上でそれなりに認知されている、かつ、twitter上で様々なすごい人とよく話している。「すごい人と話しているとすごい」と思われがち。

本記事の趣旨は、その私が世の中で想像されるほどいろいろできるわけではない、できることは限られているということを書いてみようということです。自分の弱みをわざわざさらけ出すと商品価値を下げることになりはしないかとも思いましたが、できないことをできると思われても困るので試しにやってみることにしました。

あまり多くの分野について話してしまうと焦点がボケるので、わたしが主戦場としているいわゆる低レイヤ技術について、さらにその中の独断と偏見で選んだ数個のものに絞って話します。

OSカーネルについて

Linuxカーネルについては、プロセススケジューラはだいたいわかる、ブロックデバイス、一部ファイルシステムについてはそこそこわかる、といったところです。このあたりは過去に開発、サポート経験がたくさんありますので、upstreamのLinuxカーネルの開発をゴリゴリやることもできますし、トラブルが起きても半分以上は一日以内で解決できる自信があります。それ以外の部分についてはかなりの濃淡がありますが詳細は省きます。

明確に苦手というところについても書いておきます。たとえばTCP/IPなどのネットワークに関するところは、そもそもカーネルどうこう言う前にネットワーク技術に関する経験が浅いので、よくわかりません。ハードウェアに近いところについても明るくないです。デバイスドライバについてはまともに書いたことがないです。

Linux以外のOSのカーネルについてはOSSであれば参考に見ることはありますが、これらのコードを読み解いてupstreamに取り込まれるコードを書けるレベルではまったくないです。

自作OSについて

過去にOSカーネルは二回実装したことがありますが、どれもオモチャといっていいレベルです。カーネルの上にUNIXライクなシステムを載せられるような本格的なものを作ったことは無いです。あくまでハードウェアおよびOSカーネルについての最低限の知識を得るための手段としてやっただけです。

OS自作を趣味としてやっている人を横目に見て凄いな、楽しそうだなと思う一方で、わたし個人としては特別な思い入れはないです。

バイナリアンかどうか

バイナリを直接扱う能力は持ち合わせていません。ここでは16進ダンプを見て必要な情報を見つけ出す、いわゆる目grepの能力について述べます。目grepについては次の2つの記事が詳しいので、知らない人は一読ください。

satoru-takeuchi.hatenablog.com

note.com

2つ目の自分で書いた記事にも書いていますが、わたしはこの手のことが息をするようにできるわけではありません。訓練によって一部についてはできることがある、という程度です。

コンパイラが書けるかどうか

まともなコンパイラは書いたことがないです。最近興味が出てきたので、以下ruiさん本で勉強中です。

www.sigbus.info

構文解析や字句解析については上記ruiさん本や、UNIXプログラミング環境に記載のhocの章に書いてあること以上の知識は持ち合わせていません。

アセンブリ言語が扱えるかどうか

読むほうはx86_64ならば簡単なものなら読めます。しかしカーネル内に出てこない浮動小数点演算についてのコードはマニュアルを見ながらでないと読めないです。最近のCPUに追加されたようなかっこいい命令は全然わかりません。書くほうについては必要に迫られて書くことは稀にありますが、苦手、かつ、遅いです。「アセンブリ言語が苦手なのにLinuxカーネル屋さん?」と思われるかもしれませんが、LinuxカーネルのほとんどはC言語で書かれている、かつ、わたしが得意とするのはハードウェアから遠い部分なので、さほど困らないのです。

好き嫌いの話をすると、あんまり好きではありません。コード量が多くなりがちなことと、および、実現したいロジックだけではないCPUの実装の都合によって追加で考えなくてはいけないパズル的要素が多いのがその理由です。

おわりに

本記事を読むことによって、わたしはできるところはすごくできるけれども、それ以外は別にそうでないことがある程度わかっていただけたのではないかと思います。とくに、いままで私を過大評価をしてくださっていたかたにこれを読んでいただいて、「なんでもできると思っていた人が実はそうではないんだ」や「低レイヤですごいっていうのは雑なくくりだった」などと認識をあらたにしていただければ嬉しい限りです。それとともに、完璧超人と戦って疲弊している人の心を少しでも軽くできれば、とも思います。

sleepコマンドの足し算機能

GNU coreutilsに入っているsleepコマンドにはマニアックな機能がいくつかあって、そのうちの一つが「引数を2つ以上指定できて、それらの引数をすべて足した秒数だけ待つ」という謎機能です。以下Ubuntu 18.04のman sleepより抜粋

SLEEP(1)                                                       User Commands                                                       SLEEP(1)

NAME
       sleep - delay for a specified amount of time

SYNOPSIS
       sleep NUMBER[SUFFIX]...
       sleep OPTION

DESCRIPTION
       Pause for NUMBER seconds.  SUFFIX may be 's' for seconds (the default), 'm' for minutes, 'h' for hours or 'd' for days.  Unlike most
       implementations that require NUMBER be an integer, here NUMBER may be an arbitrary floating point number.  Given two or  more  argu‐
       ments, pause for the amount of time specified by the sum of their values.

何に使うのかよくわかりませんでしたが、足し算に使えるそうなことがわかりましたので、やりかたを書いておきます。たとえば「1+5+2の答えは一体なんだったっけ…まったく思い出せない」という場合に以下のコマンドを使えばたちどころに答えが得られるというわけです。

$ time sleep 1 5 2

real    0m8.002s           # 答えは8!
user    0m0.001s
sys     0m0.000s

仕組みは簡単で、引数を足した値sleepしてくれるということは、timeコマンドを使ってsleepを実行すると、実行にかかった経過時間(real)は引数の値をすべて足したものに若干のオーバーヘッドを加えたものになるだろう、という話です。

本日公開した動画で「sleepコマンドは指定した秒数のぴったり後に終了するわけではないよ」と主張した舌の根も乾かぬうちにこういうのを書くのもどうかと思いましたが、まあ、細かいことはいいんです。

youtu.be

なお、知ってる人は知ってると思いますが、このネタは一時期話題になったsleep sortのパクりです。

www.geeksforgeeks.org

まじめなことを書くと、これについてtwitterでつぶやいていたら以下のようなご意見をちょうだいしました。

  • 単に数値の足し算をするときではなく秒を示す"s"などのsuffixを付けて*1"sleep 4m 33s"と書くような場合に便利
  • 浮動小数点数の計算をsleep内でやってくれると便利かも(bashは整数演算しかできない)
  • "sleep <ベースの値> <乱数>"のようにスリープ時間にゆらぎを持たせたいときに便利そう
  • 複数の乱数を組み合わせて正規表現分布する時間スリープしたいことがあるかも

みなさんすごいですね。わたしは足し算しか思いつかなかったです。

*1:これもGNU拡張機能

チャンスをつかむということ

はじめに

「幸運の女神には前髪しかない」という言葉があります。女神(チャンス)が目の前にあらわれたときにつかんでおくべきで、過ぎ去った後に「やっぱりちょっと待って」と掴もうとしても掴むところがないのでもう遅い、というような意味です。うまいこといいますね。今日は人生において目の前のチャンスをダボハゼのようにつかみつづけてきた自分の過去の一つの経験談をもとに、チャンスについての話をします。まずは自分語りからはじめて、その後に、そこから得られた教訓について話します。

自分の過去の経験

話はわたしの最初の就職、いわゆる新卒入社についてのものです。当時大学院生だった私は色々あって「なんとしてでもLinuxカーネルの開発を仕事にする」と意気込んでいました。その動機については本筋ではないので省略します。幸運にも当時は国内サーバベンダが「Linuxサーバやるぞ!」と意気込んでいた時期でしたので、その手の仕事も存在していました。

しかし、ここで一つ大きな問題がありました。当時のわたしはコンピュータを扱う学科には在籍しておらず、材料工学を学んでいました。この状態で何も考えずに応募しても、私にをカーネル開発の能力、あるいはそれができるようになるためのポテンシャルを持っているか、面接官から見ると極めて疑わしいことは明白でした。なんとかならないかと考えていた時、友人から「インターンというものがある」と聞きました。今でこそインターンは当たり前ですが、当時は今ほど誰でも行くようなものではなく、かつ、わたしはそういうものがあることすら知らなかったのです。幸運にもわたしが受けたかった会社のLinuxを開発している部署はインターンを募集していました。

当時プログラミングの経験はあったものの、学科内にはそのような友人はおらず、コンピュータ関連の学科にも知り合いはいなかったため、自分の能力がどの程度のものかがわかりませんでした。ここも現在と違っていて、twitterなどのSNSや勉強会を通じて同志に出会うというのはなかなか困難でした。「応募したとして私には先方に求める能力があるのか」「何もできなくて大恥かいたらどうしよう」「そもそも畑違いの私が受かるのか」など、応募するかどうかは相当ためらいましたが、最終的には「自分のできることと熱意を精一杯書き連ねて応募するしかない、自分はこれをどうしてもやりたかったんだからやらない理由はない、落ちてもダメージは無い、あとは知らん」と、応募しました。

余談ですが、応募用紙には自分のできることはおろか、かなり盛ったものを書きました。当時の面接官であり、その後の上司でもあった皆様、今謝ってっておきます。すいません。

閑話休題、その後インターンに行ってみると私は幸運にも大きな成果を出し、その後無事に希望の会社、希望の部署に就職できました。つかんだチャンスを見事モノにしたというわけです。ここまでが自分語りです。

経験から得られた教訓

前節で述べたことから私が言いたいのは、「俺はできる人だ」という自慢ではなく、そういう人であっても、一歩足を踏み出してチャンスをつかまないと、そもそも勝負にならないということです。当時インターンに応募しておらず、かつ、後になって「やっぱりあきらめきれない、応募しよう」となっても、かなり困難な道が待ち受けていたでしょう。

もう一点、わたしが大きな成果を出せたのは「Linuxカーネル開発者になりたい」という思いを実現するために大学の勉強や研究そっちのけで(当時の先生方、今謝っておきます、本当に申し訳ありませんでした)関連知識を身に着けるという準備をひたすらやっていたからです。チャンスは目の前にあらわれたときにつかむだけではなく、つかんだあとに成功に結び付けるための下準備をしておく必要があるのです。

ここで「それはあなたの頭がいいからできたんでしょう?」というかたがいるでしょう。しかしながら、少なくとも私は学校の勉強と言う意味では劣等生であることが多かったです。実際材料工学を学んでいた理由も大学受験でコンピュータを扱う学科に落ちたからです。「コンピュータには適正があったからでしょう?」といわれるかもしれません。これは実際にそうだと思います。ただ、これもやってみなければわからなかったことです。やる前からあきらめるのは得策ではありません。

おわりに

チャンスを何も考えずに全部つかもうとすると大失敗してひどいめにあうこともあります。実際わたしも明らかに実力不足だったにもかかわらず無理してチャンスをつかもうとしてひどいめにあったことも多々あります。なので「チャンスは絶対つかむべき」などということは言いません。しかしながら、いったんつかんでみて、失敗してもたいしたダメージが無いのであれば、どんどんやってみていいのではないでしょうか。というのをtwitterで未踏やらセキュキャンやらGSocやらに応募するかしないかで悩んでいる学生さんなどを見て書いてみたのでした。

100分de名著を読み始めての感想

数か月前に以下のブログを読んでから100分de名著シリーズを読むようになりました。

anond.hatelabo.jp

なにかしら自分の世界が広がることを期待して、できれば自分が普段絶対に買わないであろう本をあえて狙って買うようにしました。だいたい今50冊くらいを読んだところでの感想を書いておきます。

まずは狙い通り多少なりとも自分の中の世界が変わりました。あるいは変わるきっかけをつかめました。「なるほどこういう考え方もあるのか」「こういうジャンルがあるのか」「こんな人がいるのか」と思うことが多々あり、自分のすき好むものだけに触れているだけでは出会えないものにたくさん出会えたかと思っています。一部については実際に取り扱われている本を買いもしました。もちろんテキストだけ読んでもその本で書かれていることの最深部にたどり着くなんていうのは不可能だとは思いますが、これらの本を手に取るきっかけになるだけでも価値がありました。

その他に興味深かったのは解説者のひととなりがうかがえたこと、および、解説されている本を手に取ってみようかという判断にそれが大きく関与したということです。「この人は本当にこの本が好きなのだな」「とにかく読書が好きなんだな」ということがわかると、解説の熱量におされて解説内容そのものよりも「この人が勧めているのなら一度読んでみよう」という気になったことがよくありました。場合によっては、解説者の成果物を手に取ってみたくなることまでありました。その一方で、「この人は、この本を読んでいる自分が好きなんだな」「本はどうでもよくて自説の御開帳ができればそれでいいんだな」ということもありました。この場合は、解説者はもとより、解説されている本への印象もとばっちりで悪くなってしまったこともありました。私は本に対する読む前の印象が紹介してくれた人への評価によって大きく変わることがわかったのは、とてもよい体験でした。

一冊数十分で読める新書より軽く読めるものなので、今後もゆるゆると読み進めていきたいと思います。

オープンソースソフトウェア(OSS)にまつわる色々な誤解

はじめに

筆者はオープンソースソフトウェア(OSS)に20年近くユーザないし開発者としてかかわってきました。その間ずっとOSSは様々な誤解を受けてきましたし、また、その誤解をもとに多くの根拠のない希望、その後の落胆を生んできました。何度も語られてきた陳腐な話題ではあるのですが、見かける頻度が多い誤解とそれに対する筆者の見解を書いておきます。

オープンソースはボランティアベースで開発されている。

これはyesでもありnoでもあります。ボランティアの定義は人により様々ですが、ここでは「有志が無償でやっている」くらいの意味だと考えてください。

まず、個人あるいは組織が誰からの利益を得ることもなくOSSを開発をしているという一般にイメージしやすいケースは数多くあります。ただしその目的は千差万別です。

ボランティアという字面から想像されるような世の中をよくしたい、世の中のためになりたい、という強い思いを持っている人もいますが、それだけではありません。自分が作ったものを誰か使ってくれるかもしれないからとりあえず公開しているという人もいますし、最近では就職/転職活動用に自分のコーディング能力を示すものとして自分がこれまでに書いたものを公開しているだけ、という人もいます。

noでもあるといったのは、企業から給与を受け取ってOSSを開発しているというケースです。これはとくに多くの人が使っている有名OSSにあてはまります。たとえばLinuxカーネルについては今や余暇などに無償で開発している人よりも、企業の社員として開発している人のほうがはるかに多いです。

企業が無償でソフトウェアを開発して何がうれしいのかについては、企業のビジネスモデルによって様々な理由があります。一つ例を挙げると、特定のOSSのサポートを顧客に有償で提供する企業があります。この企業には、顧客のシステムでトラブルが起きないようにするために、サポート対象のOSSを改善する動機があります。また、多くの顧客ないし潜在的な顧客が求める機能が当該OSSになければ、その機能を追加する動機があります。

ではなぜわざわざソースを公開する必要があるのか、あるいはクローズドソースのものを自作するのではなくOSSを担ぐ必要があるのかについては、それはそれで大きな話となるので、ここでは割愛します。

OSSは自分で修正できる

これは技術的にはyesです。まずは、皆さんが自前で運用しているAというOSSになんらかのバグを発見したとしましょう。ここでみなさんがAに修正をして使い続ける。これはもちろんできます。ただし、これにはAを修正できるほど理解しているというのが前提条件であり、ソフトウェアの規模が大きければ大きいほど、大変になります。

ある企業BにAのサポートをお願いしている場合を考えてみましょう。この場合は上述のものと事情が変わってきます。一般的にOSSのサポートをしている企業は、特定バージョンのupstream OSS(企業などによる独自修正が入っていないもの)、あるいはそれに当該企業独自の修正をいくつか適用したものをサポート対象としています。それ以外のものはサポート外になるでしょうし、場合によってはそのようなものを使った時点で契約違反になることもあるでしょう。

つまりこの場合は、みなさんは修正方法がわかっていても、自分達で勝手に修正を適用したものを軽々しく使うわけにはいかないのです。この場合、一般的にはB社が修正を取り込んだAの新バージョンをリリースするのを待って適用することになるでしょう。

自分の報告したバグが修正されないのはおかしい。自分が投稿した修正が取り込まれないのはおかしい。

OSSの開発者、とくにコードの修正に責任のあるメンテナやコミッタといわれる人達には、個々のユーザの要望に応える義務がありませんので、そういうものです。上述したように企業の技術者がOSS開発をしていることもありますが、彼らが責任を負うのは彼らが所属している企業の顧客に対してであり、彼らが開発しているOSSのユーザ全員ではありません。

OSSでシステムを組むと低コスト

これは一概には言えません。OSSならばコストが低い、クローズドソース製品ならコストが高い、といった単純な話はありません。高品質、高価なクローズドソースな商用システムと似たOSSのサポートが安価で提供されているということはよくありますが、必ずしも全部がそうというわけではありません。そもそも、高価な製品に似たソフトウェアを安価で売るという戦略はOSSに限ったことではありません。

OSSは世界中の人々がよってたかって開発しているので開発スピードが速い。世界中の人々が使っているので問題が検出されやすく、枯れやすい。いいことずくめ

これはものによります。個々のOSSに誰もが使いたいとおもう魅力があれば当てはまりますし、そうでなければユーザがいなくなり、開発者がいなくなり、死を迎えます。表題の話は理想的にはこうなる、という話であって、すべてのOSSに当てはまるというわけではありません。ただし、あるOSSを使っている、あるいはこれから使いたいと思っている企業は、この理想状態を目指して様々な活動をしているということは言えるでしょう。たとえば当該OSSコミュニティを盛り上げようと技術者を開発に投入したり、イベントを主催したり、資金援助をしたり、などなどです。

おわりに

他にもいくらでも書くことはあるのですが細かいことを書きすぎると見づらくなるし話の焦点がぼやけるのでこのあたりにしておきます。