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コマンドは指定した秒数のぴったり後に終了するわけではないよ」と主張した舌の根も乾かぬうちにこういうのを書くのもどうかと思いましたが、まあ、細かいことはいいんです。
なお、知ってる人は知ってると思いますが、このネタは一時期話題になったsleep sortのパクりです。
まじめなことを書くと、これについてtwitterでつぶやいていたら以下のようなご意見をちょうだいしました。
- 単に数値の足し算をするときではなく秒を示す"s"などのsuffixを付けて*1"sleep 4m 33s"と書くような場合に便利
- 浮動小数点数の計算をsleep内でやってくれると便利かも(bashは整数演算しかできない)
- "sleep <ベースの値> <乱数>"のようにスリープ時間にゆらぎを持たせたいときに便利そう
- 複数の乱数を組み合わせて正規表現分布する時間スリープしたいことがあるかも
みなさんすごいですね。わたしは足し算しか思いつかなかったです。
チャンスをつかむということ
はじめに
「幸運の女神には前髪しかない」という言葉があります。女神(チャンス)が目の前にあらわれたときにつかんでおくべきで、過ぎ去った後に「やっぱりちょっと待って」と掴もうとしても掴むところがないのでもう遅い、というような意味です。うまいこといいますね。今日は人生において目の前のチャンスをダボハゼのようにつかみつづけてきた自分の過去の一つの経験談をもとに、チャンスについての話をします。まずは自分語りからはじめて、その後に、そこから得られた教訓について話します。
自分の過去の経験
話はわたしの最初の就職、いわゆる新卒入社についてのものです。当時大学院生だった私は色々あって「なんとしてでもLinuxカーネルの開発を仕事にする」と意気込んでいました。その動機については本筋ではないので省略します。幸運にも当時は国内サーバベンダが「Linuxサーバやるぞ！」と意気込んでいた時期でしたので、その手の仕事も存在していました。
しかし、ここで一つ大きな問題がありました。当時のわたしはコンピュータを扱う学科には在籍しておらず、材料工学を学んでいました。この状態で何も考えずに応募しても、私にをカーネル開発の能力、あるいはそれができるようになるためのポテンシャルを持っているか、面接官から見ると極めて疑わしいことは明白でした。なんとかならないかと考えていた時、友人から「インターンというものがある」と聞きました。今でこそインターンは当たり前ですが、当時は今ほど誰でも行くようなものではなく、かつ、わたしはそういうものがあることすら知らなかったのです。幸運にもわたしが受けたかった会社のLinuxを開発している部署はインターンを募集していました。
当時プログラミングの経験はあったものの、学科内にはそのような友人はおらず、コンピュータ関連の学科にも知り合いはいなかったため、自分の能力がどの程度のものかがわかりませんでした。ここも現在と違っていて、twitterなどのSNSや勉強会を通じて同志に出会うというのはなかなか困難でした。「応募したとして私には先方に求める能力があるのか」「何もできなくて大恥かいたらどうしよう」「そもそも畑違いの私が受かるのか」など、応募するかどうかは相当ためらいましたが、最終的には「自分のできることと熱意を精一杯書き連ねて応募するしかない、自分はこれをどうしてもやりたかったんだからやらない理由はない、落ちてもダメージは無い、あとは知らん」と、応募しました。
余談ですが、応募用紙には自分のできることはおろか、かなり盛ったものを書きました。当時の面接官であり、その後の上司でもあった皆様、今謝ってっておきます。すいません。
閑話休題、その後インターンに行ってみると私は幸運にも大きな成果を出し、その後無事に希望の会社、希望の部署に就職できました。つかんだチャンスを見事モノにしたというわけです。ここまでが自分語りです。
経験から得られた教訓
前節で述べたことから私が言いたいのは、「俺はできる人だ」という自慢ではなく、そういう人であっても、一歩足を踏み出してチャンスをつかまないと、そもそも勝負にならないということです。当時インターンに応募しておらず、かつ、後になって「やっぱりあきらめきれない、応募しよう」となっても、かなり困難な道が待ち受けていたでしょう。
もう一点、わたしが大きな成果を出せたのは「Linuxカーネル開発者になりたい」という思いを実現するために大学の勉強や研究そっちのけで(当時の先生方、今謝っておきます、本当に申し訳ありませんでした)関連知識を身に着けるという準備をひたすらやっていたからです。チャンスは目の前にあらわれたときにつかむだけではなく、つかんだあとに成功に結び付けるための下準備をしておく必要があるのです。
ここで「それはあなたの頭がいいからできたんでしょう？」というかたがいるでしょう。しかしながら、少なくとも私は学校の勉強と言う意味では劣等生であることが多かったです。実際材料工学を学んでいた理由も大学受験でコンピュータを扱う学科に落ちたからです。「コンピュータには適正があったからでしょう？」といわれるかもしれません。これは実際にそうだと思います。ただ、これもやってみなければわからなかったことです。やる前からあきらめるのは得策ではありません。
おわりに
チャンスを何も考えずに全部つかもうとすると大失敗してひどいめにあうこともあります。実際わたしも明らかに実力不足だったにもかかわらず無理してチャンスをつかもうとしてひどいめにあったことも多々あります。なので「チャンスは絶対つかむべき」などということは言いません。しかしながら、いったんつかんでみて、失敗してもたいしたダメージが無いのであれば、どんどんやってみていいのではないでしょうか。というのをtwitterで未踏やらセキュキャンやらGSocやらに応募するかしないかで悩んでいる学生さんなどを見て書いてみたのでした。
100分de名著を読み始めての感想
数か月前に以下のブログを読んでから100分de名著シリーズを読むようになりました。
なにかしら自分の世界が広がることを期待して、できれば自分が普段絶対に買わないであろう本をあえて狙って買うようにしました。だいたい今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コミュニティを盛り上げようと技術者を開発に投入したり、イベントを主催したり、資金援助をしたり、などなどです。
おわりに
他にもいくらでも書くことはあるのですが細かいことを書きすぎると見づらくなるし話の焦点がぼやけるのでこのあたりにしておきます。
youtuberはじめました
はじめに
COVID-19禍の影響か、知人、友人がけっこうyoutuberをやるようになっていた*1のと、それらコンテンツが面白かったことより、自分も真似してみようと思ってyoutuberになってみました。それについての話を少々します。
コンテンツはコンピュータ技術について、とくにわたしの専門である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」
実際の所要時間
- 1時間
課題
- コンテナの実行において、コンテナイメージサイズを最小化しつつ、稀にしか使わないデバッガなどのその他ツールも使いたい
- アプリもその他ツールもすべて入ったイメージは無駄に大きすぎる
- アプリが通常使わないその他ツールをイメージから削除してしまうと、いざというときにその他機能が使えない、使うとしてもコンテナに外からツールを流し込まなくてはいけないので面倒
- コンテナイメージのベースイメージを小さくする*1のはlibcの入れ替えなどによる互換性の問題が避けられない
解決方法概要 -コンテナイメージをslimイメージとfatイメージの二種類に分ける
- slimイメージ: アプリ実行に必要なものだけが入っている - fatイメージ: その他ツールが入っている。slimイメージにその他ツールを足した拡張版、というわけではない。コンテンツはなんでもいい。CNTRはfatイメージを使わずホスト環境を直接使う方法もあるが、説明は割愛- これ以降slimイメージから作られたコンテナをslimコンテナ、fatイメージから作られたコンテナをfatコンテナと記載
- アプリの実行にはslimイメージを使う。その他ツールが使いたくなったらアプリのコンテナにfatイメージから作ったコンテナをアタッチ(詳細は後述)
- 上記環境からはユーザはslimコンテナ、およびfatコンテナの両方にアクセス可能。つまりfatコンテナ内のデバッガを使ってslimコンテナ内のアプリをデバッグ、といったことができる
解決方法詳細
- ユーザがCNTRを呼び出す。このときCNTRにslimコンテナの名前*2とfatイメージをパラメタとして指定する
- コンテナの名前をもとに、カーネルから動作中のコンテナのnamespaceや環境変数、cgroupsの一覧といったコンテナのコンテキストを得る
- コンテナ名をもとにコンテキストを得る方法はコンテナランタイム依存なので、CNTRがランタイムごとにこの処理を実装する必要がある
- fatイメージを使ってコンテナを立ち上げて、CNTRFSサーバ(後述)を動かす
- 前述のコンテナのコンテキストをもとに、アプリのコンテナ上にネストしたnamespaceを作る
- 上記namespaceの中にCNTRのユーザがアクセスできる環境(ここではCNTR環境と呼ぶ)を用意して、その上で動作するシェルをユーザに提供する
- ユーザがファイルシステムにアクセスすると、CNTRFSは次のように実際のアクセス先を分ける
- "/var/lib/cntr"以下にアクセスするとslimコンテナのデータにアクセス
- "/proc"や"/sys"以下はslimコンテナのものを直接見せる
- それ以外の場所へのアクセスするはfatコンテナのデータにアクセス
効果
- xfstestsをほとんどパスするほどの高い互換性がある
- コンテナ実装に依存する部分が少ないこともあって、DockerやLXC,systemd-spawnなどの有名どころのコンテナランタイムで使える
- Dockerhub上の有名どころのコンテナイメージのサイズを平均で2/3程度に小さくできる
- 性能オーバーヘッドは少ない
感想
- かっこいい。言われてみるとなるほどだけど、うまくやるなあと思った
- たくさんfatコンテナを付けると面白そう
- Kubernetesのephemeral containerをほうふつとさせる。なにか関係があるんだろうか。
