オープンソースソフトウェア(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コミュニティを盛り上げようと技術者を開発に投入したり、イベントを主催したり、資金援助をしたり、などなどです。

おわりに

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

youtuberはじめました

はじめに

COVID-19禍の影響か、知人、友人がけっこうyoutuberをやるようになっていた*1のと、それらコンテンツが面白かったことより、自分も真似してみようと思ってyoutuberになってみました。それについての話を少々します。

www.youtube.com

コンテンツはコンピュータ技術について、とくにわたしの専門であるLinuxカーネルや、それより少し下のハードウェアに近いレイヤについてのものが中心です。しかもそれらを巨大なソースコードを見たりせずに、なるべく平易に解説するのが目的です。

始めた動機

なぜLinuxカーネルなどを選んだかというと、わたしがこのネタを好きなことと、世の中の人に知ってもらいたいという思いがあるからです。実はこの思いは以前から書籍や雑誌連載(Software Design)、このブログ上の記事などで何年もにわたって実践してきていました。

その過程で思ったのは、「文書以外にも伝える方法はあるんじゃないか」ということです。上記書籍などの反応では「実際にやっているところが見たい」などの声が多数ありました。ソースコードを公開していても、文書の中で「みなさんもやってみてください」と書いても、やっぱり自分でやってみるのは面倒くさいものだというのは理解できます。

もう一点、知人から、「わたしの息子はわからないことがあるとググるんじゃなくてyoutubeで検索して解説動画を見るところが入り口」という話を聞いたのも大きなきっかけでした。私の初心者向けコンテンツのメインターゲットになるであろう若い世代には実は書籍よりも動画のほうが響くのかもしれないな、と、この話を聞いて思いました。

上記のような考えをもとに、とりあえずやってみよう、うまくいかなかったらやめればいいや、という気持ちではじめた、というわけです。

反響と改善点

はじめてみたところ数日でチャンネル登録者数が1000人を超えるなど、予想をはるかに上回る反応がありました。評価も高評価の割合95%程度と高く、かつ、コメントもおおむね好意的なものが多かったです。新しい動画を公開するごとに順調に再生回数は減っていますが、それでも、どれも数百回見られる程度には需要があるようなので、しばらくは続けてみるつもりです。

最初のほうは動画の長さが20分くらいあったのですが、友人から「長いと最初から見てもらえない、途中で切られるリスクが高いよ」という助言をもらったのをきっかけに、最近のものは10分程度にしています。これ以外にも一度に詰め込みすぎないようにする、普通に生きていたら出会わないであろう知識を小ネタとして、遊びとして混ぜる、などの工夫をしています。今後も改善を続ける予定です。

それ以外にいま寄せられている改善要望で一番多いのが音に関するものです。たとえば音質がそれほど良くないとか、音が小さいとか、あるいは回によって音の大小が違うとか。これについては、今すぐがんばって改善する気はないのですが、そのうちやるかもしれません。

収益化について

前節において述べた通り、非常に反響が大きかったことより、収益化の最低条件であるチャンネル登録者数1000人と直近12ヶ月の総再生時間4000時間のうち、前者はすでにクリアしています。後者についても現在開始一週間、動画の数5つで600時間を超えているため、夢物語ではないところまで来ています。主目的を見失わないのを第一にしつつ、見る人も有益な情報が得られて、かつ、配信者も楽しくお金を稼げる、となることを願っています。

おわりに

趣味として楽しく、あわよくばお金が稼げると嬉しいな～、というくらいで飽きないようにゆるゆると続けていけたらなと思います。ご意見ご要望などありましたら、このエントリへのコメントでもtwitterでも動画へのコメントでも、なんでもいいのでお伝えください。

*1:ウィルス騒動のはるか前からやっていた人もいますけど

DeepLは2020年5月4日現在、日本から課金できない

DeepLをいたく気に入ったので課金しようとしたらアカウント作成中にエラー発生。よくわかんなかったのでサポートに問い合わせたら「税制上の理由で日本からはまだ課金できない。でも、できるようにいま頑張ってるよ(意訳)」とのこと。

以下サポートから届いたメールの抜粋。

Unfortunately, due to tax reasons, it is currently only possible to book DeepL Pro within the European Union, United Kingdom, Switzerland the United States and Canada. We are working hard to make it possible to order DeepL Pro in Japan soon.

If you wish to keep updated with the news from our company (including when it will be possible to book DeepL Pro from outside of the EU), you can visit our Blog (https://www.deepl.com/blog.html) or follow our social media pages on Facebook and on Twitter.

はやく課金したい。

30分で論文流し読みシリーズ ９「Cntr: Lightweight OS Containers」

www.usenix.org

  • 実際の所要時間

    • 1時間

  • 課題

    • コンテナの実行において、コンテナイメージサイズを最小化しつつ、稀にしか使わないデバッガなどのその他ツールも使いたい
    • アプリもその他ツールもすべて入ったイメージは無駄に大きすぎる
    • アプリが通常使わないその他ツールをイメージから削除してしまうと、いざというときにその他機能が使えない、使うとしてもコンテナに外からツールを流し込まなくてはいけないので面倒
    • コンテナイメージのベースイメージを小さくする*1のはlibcの入れ替えなどによる互換性の問題が避けられない

  • 解決方法概要 -コンテナイメージをslimイメージとfatイメージの二種類に分ける

     - slimイメージ: アプリ実行に必要なものだけが入っている
 - fatイメージ: その他ツールが入っている。slimイメージにその他ツールを足した拡張版、というわけではない。コンテンツはなんでもいい。CNTRはfatイメージを使わずホスト環境を直接使う方法もあるが、説明は割愛
    • これ以降slimイメージから作られたコンテナをslimコンテナ、fatイメージから作られたコンテナをfatコンテナと記載
    • アプリの実行にはslimイメージを使う。その他ツールが使いたくなったらアプリのコンテナにfatイメージから作ったコンテナをアタッチ(詳細は後述)
    • 上記環境からはユーザはslimコンテナ、およびfatコンテナの両方にアクセス可能。つまりfatコンテナ内のデバッガを使ってslimコンテナ内のアプリをデバッグ、といったことができる

  • 解決方法詳細

    1. ユーザがCNTRを呼び出す。このときCNTRにslimコンテナの名前*2とfatイメージをパラメタとして指定する
    2. コンテナの名前をもとに、カーネルから動作中のコンテナのnamespaceや環境変数、cgroupsの一覧といったコンテナのコンテキストを得る
      • コンテナ名をもとにコンテキストを得る方法はコンテナランタイム依存なので、CNTRがランタイムごとにこの処理を実装する必要がある
    3. fatイメージを使ってコンテナを立ち上げて、CNTRFSサーバ(後述)を動かす
    4. 前述のコンテナのコンテキストをもとに、アプリのコンテナ上にネストしたnamespaceを作る
      • CNTRFSというCNTR専用ファイルシステムをマウントする。このCNTRFSはユーザからのファイルアクセスをslimコンテナおよびfatコンテナにforwardするproxyとなる
      • このときにユーザが指定したfatコンテナをパラメタとして渡す。これによってCNTRFSからのファイルアクセスフォワード先が、ユーザの指定したfatコンテナになる。フォワードにおいてはCNTRFSクライアントとサーバが連携
    5. 上記namespaceの中にCNTRのユーザがアクセスできる環境(ここではCNTR環境と呼ぶ)を用意して、その上で動作するシェルをユーザに提供する
    6. ユーザがファイルシステムにアクセスすると、CNTRFSは次のように実際のアクセス先を分ける
      • "/var/lib/cntr"以下にアクセスするとslimコンテナのデータにアクセス
      • "/proc"や"/sys"以下はslimコンテナのものを直接見せる
      • それ以外の場所へのアクセスするはfatコンテナのデータにアクセス

  • 効果

    • xfstestsをほとんどパスするほどの高い互換性がある
    • コンテナ実装に依存する部分が少ないこともあって、DockerやLXC,systemd-spawnなどの有名どころのコンテナランタイムで使える
    • Dockerhub上の有名どころのコンテナイメージのサイズを平均で2/3程度に小さくできる
    • 性能オーバーヘッドは少ない

  • 感想

    • かっこいい。言われてみるとなるほどだけど、うまくやるなあと思った
    • たくさんfatコンテナを付けると面白そう
    • Kubernetesのephemeral containerをほうふつとさせる。なにか関係があるんだろうか。

*1:たとえばUbuntuからAlpineなど

*2:コンテナランタイムが個々のコンテナを識別するもの

swapは無効化されぬ、何度でも蘇るさ！

めも

Rookのintegration testを動かそうとしたら、テスト用のK8sクラスタを作るスクリプトにおいて、K8sクラスタが立ち上がらない、および、「kubeletはswaponだと動かないよ」というエラーメッセージが出ていることがわかった。しかし上記スクリプトはクラスタ構築前にswapoff -aを実行していた。どういうことかと思って調査すると、たとえswapoff -aしていてもsystemdが定期的にシステムに存在するswap領域の状態を監視しており、無効になっていた場合は再度有効にしているらしいことがわかった。というわけで次のようなパッチで解決。

github.com

寝室からスマホを追放した話

以前から寝る前にスマホをぼさーっと見るのをやめたいなと思ってたんですが、寝室にそもそもスマホを置かないという方法でそれを達成しました。その結果、今朝はえらく頭がすっきりしていて、なんだか睡眠の質が改善したような気がします。たった一日なので因果関係はまだわかりませんが、寝る前にディスプレイを見るのはよくないとかいうし、しばらく続けてみようかと思います。

寝室にスマホを置かないというのは別に珍しい方法ではなくて、スマホを見ないと死ぬというほどスマホ中毒というわけでもないんですが、ここに至るまでにはけっこう時間がかかりました。その理由は、「スマホはなくてもいいけど目覚ましアラームは欲しいなあ、でもかっこいい目覚まし時計はなかなか見当たらないなあ、でも気合い入れて探すのもめんどくさいなあ」、という完全なる怠け根性から来るものでした。で、そんなときに前から気になっていたGoogle Nest Miniを買ってみてアラーム機能を使ってみたら、幸いにも「ああ、これでいいや」と思えました。昨晩からスマホはアラームをすべて解除して書斎の机の上にほったらかしにしています。

store.google.com

ところでGoogle Nest Miniで音楽を流してみると、どんどんYoutube Music Premium(ないしYoutube Premium)を契約する気がわいてきます。ああ怖い。

Ergo Proxyを見た

https://amzn.to/3aZpFC9

ストーリーは難しくて何言ってるのか最初は全然わからなかったものの…といいたいところですが結局最後まで全く理解できないまま終わりました。しかし世界観、とくに主人公のデザインがすばらしかったです。最初から最後まで映像の綺麗さと格好いい雰囲気を楽しんでいました。こういう楽しみかたをしたアニメは初めてかもしれない。

同僚に「Lainが好きならErgo Proxyはきっと気に入るとおもう」と言われて見始めたやつなんですが、なんと見始めたのが去年の二月末。一年以上かけて見ていたことになります。アニメを見る精神力がなくなっていますね。