シェルスクリプトを書いていると「それはbash独自機能だから」「POSIXシェルには無い機能だから」と言われることがよくあります。だいたいは「それみんな使ってるのでPOSIXで標準化されてると思った」といったものなのですが、本記事では便利なものから「え、それやるくらいならPythonでよくない?」まで、bashの機能を紹介しようと思います。 for文でC言語っぽくループを回す シェルスクリプトでfor文といえばfor i in $(seq 10)とかをよく使いますが、bashだと以下のように書けます。

「あるソフトウェアがオープンソースである、OSSである」とみなせる条件は、そのソフトウェアがOpen Source Initiative(OSI)が定義するオープンソースなライセンスの下に頒布されていることです。それ以外の条件はありません。この「それ以外の条件はありません」のところが誤解されやすいので、どのように誤解されるのか、および、実際のところどうなのかということについて書きます。 OSSの代表格といえば、サーバ、スーパーコンピュータ、組み込み機器など様々な用途で世界中で使われているOSカーネルであるLinuxでしょう。Linuxには以下のような特徴があります。 a. オープンソースライセンスであるGPL v2の下に頒布されている b. 世界中の技術者たちが誰でもオープンに開発されていて、その開発過程もメーリングリストなどによってオープンになっている これは事実なのですが、aに加えてb

2022/10/16 以下ご指摘をもとに内容を修正および追記 https://zenn.dev/link/comments/463223a4de9ec2 はじめに Linux上でコマンドを実行したときのコマンドライン引数についてつらつら書きたくなったので書きます。 プロセスのコマンドライン引数とは、たとえばfoo bar bazというコマンドを実行したら、通常はコマンドライン引数はfoo、bar、およびbazになります。直観的には引数は”bar”と"baz"だけのようにおもえるかもしれませんが、とにかくこういう定義です。 コマンドライン引数はプログラムの中からはCやC++ではmain関数のargv配列引数から参照できます。上述の例であればargv[0]には実行ファイル名が入ります。それ以降の"bar"はargv[1]に、"baz"はargv[2]に入っています。argvに相当する変数はシェ

はじめに Linuxを使っているみなさんは普段からLinux上で様々なコマンドを実行していると思います。それらを識別するときに「コマンド名」という単語を使っていると思いますが、文脈によってこの単語が意味するものは異なります。本記事ではLinuxカーネルがいうところのコマンド名がどういうものかについて書きます。 一番最初に短い結論、その次に具体的な説明、そして最後にこれについて調べようとしたきっかけ、およびその後の調査プロセスについて書きます。 結論 Linuxカーネルから見たコマンド名は実行ファイル名のbasename(ファイル名からディレクトリ部分を除いたもの)の先頭15バイト カーネルのメモリ内のプロセス(正確にはカーネルレベルのスレッド)ごとに存在するtask_structという名前の構造体の中のcommという16バイトのフィールドにNULL終端文字列として格納されている カーネルの

オープンソースソフトウェア(以下OSS)にはいろんなものがあることについて書きます。さんざ語りつくされてきたことですけど、自分でもう一度整理したくなったので書きます。 オープンソースなソフトウェアとそうでないものの区別 オープンソースは「俺がオープンソースと言ったらオープンソース」とか「人によっていろいろな考え方があるよね」とかではなく、明確な定義があります。 以下Open Source Initiativeによる定義です。 八田さんによる邦訳。 これ以降は邦訳のほうを使って説明します。 OSSについてのよくある勘違いに「ソースが公開されていればOSSでしょ」というものがありますです。これはたとえば「3. 派生ソフトウェア」を見れば、違っていることがわかります。 ライセンスは、ソフトウェアの変更と派生ソフトウェアの作成、並びに派生ソフトウェアを元のソフトウェアと同じライセンスの下で頒布する

本記事は書きかけなので内容(タイトルすらも)は随時書き換わっていきます。ドラフトのうちは内容の正確性や文書全体としての整合性についても荒っぽい部分が多々あります。ご容赦ください。 はじめに 本記事はソフトウェア開発者がハードウェアに近い低レイヤといわれる領域に入門するとき、とくにアセンブリ言語に出会ったときにつまずきがちなことを紹介します。主な対象読者はJavaScriptやPythonなどのスクリプト言語などによるアプリ開発からソフトウェア開発に入った、それより下のレイヤになじみのない人です。 筆者は常々アセンブリ言語は技術的にものすごく難しいわけではないものの、学習につまずく人が非常に多いという印象を持っています。その主な原因の一つは、みなさんが普段慣れ親しんでいる人間に使いやすいように作られた高級プログラミング言語(以下高級言語)と、機械に解釈させやすいように作られているアセンブリ言

はじめに なんとなく書きたくなったので書きます。詳しいレビューなどは書きません。書いても一言程度。実は昔似たようなエントリを書いたことがあるんですが、そちらは初心者+αくらいの人に勧める本についてのもので、こちらはあくまで私に刺さった本です。 達人プログラマー ソフトウェア技術者としての考え方のいくつかはこの本の影響によって身に着けました。この手の本は抽象的でスカスカなことが多いのですが、この本は著者の文書作成技術が高いこと、例が具体的なこともあって、ずいぶん納得できることが多かったです。わたしが読んだのは第一版ですが、あえて第二版へのリンクを張っています。 プログラミング作法 よいプログラムをどう組めばいいかということを学べました。いろいろな言語を題材にしていますが、どういうものを使っていても役に立つ実践的なことが書いています。 珠玉のプログラミング アルゴリズムについて、具体的にどう役

はじめに 本記事はLinux環境における次のようなことをざっくり理解するための記事です。 Application Programming Interface(API)って何? Application Binary Interface(ABI)って何? システムコールとAPIとABIの関係って？ それぞれ何がどう違うの? この手の情報はググればwikipediaやらにいろいろ情報が載ってるんですが、初心者が理解するには細かいことまで書かれすぎていて、かつ、それぞれの関係がわかりにくいです。なので、用語を逐一解説するのではなく、ありがちな質問のQAという形をとりました。人によって用語の意味の揺らぎがあったりするんですが、私の解釈ということで。あからさまに間違っていたら指摘していただけると嬉しいです。 これを書こうと思ったきっかけは、以前こんなtweetを見かけたことです。それから「そういえば最

みなさん、新機能は好きですか。ソフトウェアへの機能追加は、ユーザ目線で単純に考えると「できることが増えていくのでよい」という響きを帯びています。しかし実際は、長く使われるソフトウェアであればあるほど、新機能を追加すべきかどうかはものすごく気を使って決めるものであって、やればいいというものではないのです。この記事の目的は、新機能の追加には細心の注意が必要だとわかってもらうことです。おもな対象読者はソフトウェアを長期間メンテしたことがないかたがたです。 みなさんが使っているOSSに新機能を追加するPRを送った場合を考えてみましょう。ここで重要なのは、PRが送られてきたメンテナやコミッタといわれるコア開発者たちの立場になって考えることです。彼らの役割は、自分たちを含むユーザがそのソフトウェアを使い続けられるようにメンテし続けることです。このメンテのコストに注目すると、機能追加は基本的にコストを上

はじめに なんらかの理由によってOSやOSカーネルに興味を持つ人は多々います。しかし、その次のステップとしてどんな本を読めばいいんだろうと思っている人はこれまたいっぱいいます。そこで、長年Linuxカーネルにかかわってきた筆者がこれまでに読んでよかったと思うものについてここの列挙しました。紹介するのは本だけであって、記事は省いています。 OSそのものに興味を持った人は、その後に興味の方向が次のような二つに分かれることが多いと筆者は考えています。 オレオレOSを作りたい 既存のOSを改造したい この仮説をもとに、それぞれについて筆者がかつて真面目に読んだ本の中から「自作OS」および「Linuxカーネル」というキーワードでよかったものを挙げておきます。Linux以外の既存OSについては語れるほどの知識はないので書いてません。 筆者について 本の良し悪しは人によってさまざまなので、筆者がどういう

はじめに システムに存在するリソースには同時にアクセスしてはいけないものが多々あります。身近な例を挙げると、Ubuntuのパッケージ管理システムのデータベースがあります。aptコマンドの動作によってこのデータベースは更新されるのですが、同時に2つ以上のaptが動作できたとすると、データベースが破壊されてシステムが危機的状況に陥ります。 このような問題を避けるために、あるリソースに同時に1つの処理しかアクセスできなくする排他制御というしくみがあります。排他制御はOSが提供する重要な機能の一つです。 排他制御が必要なケース 排他制御は直感的ではなく非常に理解が難しいのですが、ここでは比較的理解が簡単なファイルロックというしくみを使って説明します。説明には、あるファイルの中身を読みだして、その中に書いてある数字に1を加えて終了するincというという単純なプログラムを使います。

はじめに よくソフトウェア技術者にはプログラミング以外にもたくさんの技術が必要といわれます。では具体的に何が必要なのか…というと、実のところ個々人が置かれた状況によって全然異なるので何とも言えません。ただこれだけだと実務経験が無い人には全然ピンと来ないと思うので、現役職業プログラマである私が今の仕事で必要になっている能力について書きます。 私が現在なにを作っているか 私がやっていることはオンプレのインフラ基盤であるKubernetesクラスタの開発、およびその上で動くストレージ基盤であるRook/Cephクラスタの開発です。簡単に言ってしまえばこれらを作るのが現在所属しているプロジェクトのミッションです。 その中でもわたしのわかりやすい仕事はRookの開発です。上記インフラ基盤に必要な機能の開発、バグ修正が中心です。Rookはメンテナとして開発に参加しているので、それ以外にもコードレビュー

はじめに 本記事はKubernetesの嬉しいところではなくてつらいところについて書きます。Kubernetesを少しは触ったことがあって基礎的な用語がわかるくらいの人であれば読めると思います。 Kubernetesのよく言われる売り文句は「Kubernetesを使うと自分でぽちぽちコマンドを叩かなくても、あるべき状態を宣言しておけば後はKubernetesが勝手にその状態になるように保ってくれるのですごく運用が楽」でしょう。これはその通りで自分もKubernetesのおかげで楽をしているなあと感じることがかなりあります。 しかし、何年も実際に使い込んできた経験からいうと、前述の売り文句には「大体の場合は」という但し書きが付きます。では「大体は」じゃないときにどうなるかというと、つらくなります。ここからはどんなときにどんなふうにつらいのかを簡単な例を使って説明します。 冗長度を自動回復して

はじめに gcc v12.1において、C++の正規表現ライブラリstd::regexに、正規表現のバリデーションを改善するパッチ(以下"改善パッチ"と表記)が取り込まれました。改善パッチによって、これまではバリデーションにひっかからなかった不正な正規表現文字列が"正しく"不正なものと認識されて例外が発生するようになりました。 これだけ聞けばいいことだけのように思えるかもしれませんが、実はそうでもなかったりします。経験豊富なかたであれば見た瞬間ゾッとしたかもしれません。本記事では、この一見問題なさそうな改善パッチによって発生しうる問題、および、その具体的例について紹介するとともに、この手のパッチを当てるかどうかは難しい判断になるという知見を共有します。 結論 改善パッチによって発生する問題 発生条件 gcc v12.1以降、あるいは改善パッチをバックポートされた任意のバージョンを使ってC++