Q&A

最後の講義では、学生から送られた質問に回答しました。

プロセッサ、仮想メモリ、割り込み、メモリ管理など、オペレーティング・システムに関連したトピックを学習するのにおすすめはありますか？

まず、これらは非常に低レベルのトピックなので、 これらすべてに精通する必要が本当にあるのかが不明です。 これらは、カーネルの実装や改変など、より低レベルのコードを書き始めたときに問題となります。 そうでない限り、他の講義で取り扱ったプロセスやシグナルを除き、 ほとんどのトピックは関連がありません。

これらのトピックを学ぶ良いリソースには以下があります。

優先的に学ぶべきツールは何ですか？

優先する価値のあるトピックを以下に挙げます。

Python、Bashスクリプト、その他言語を使うのはどのような場合ですか？

一般的に bash スクリプトは、特定の一連のコマンドを走らせたいだけという時など、短く単純な1回のみのスクリプトに便利です。 bash にはいくつかの特殊性があり、より大きなプログラムやスクリプトでの作業はしにくくなっています。

そのため、より大規模、または複雑なスクリプトでは、 Python や Ruby などより成熟したスクリプト言語を使用することをおすすめします。 これらの言語での一般的な問題は、すでに多くの人が解決しており、たくさんのライブラリとして入手可能です。 もし、着目している特定の機能が実装されたライブラリがある言語で存在するのを見つけたならば、通常その言語を使うことが最善手です。

source script.sh と ./script.sh の違いは何ですか

両方のケースで、 bash セッションで script.sh が読まれ実行されます。違いは、どのセッションがコマンドを実行しているかです。 source では、コマンドは現在の bash セッションで実行されているため、あらゆる変更は現在の環境に対して行われます。 source 実行を終了しても、例えばディレクトリの変更や関数の定義は現在のセッションで存続します。 ./script.sh のようなスタンドアロンのスクリプトを実行すると、現在の bash セッションが新しい bash インスタンスを開始し、これが script.sh のコマンドを実行します。

そのため、 script.sh がディレクトリを変更すると、新しい bash インスタンスはディレクトリを変更しますが、終了し、親の bash セッションに管理が戻ると、親セッションは同じ場所にあるままです。 同様に、もし script.sh がターミナルでアクセスしたい関数を定義しているなら、現在の bash セッションで定義するためには source が必要です。そうでないと、実行した時、現在の shell ではなく新しい bash プロセスが関数定義を処理してしまいます。

パッケージやツールはどこに保存されていますか？ 使用するための参照方法は？ /bin や /lib とは何ですか？

ターミナルで実行しているプログラムによりますが、これらは PATH 環境変数に保存されているディレクトリにあります。 which コマンド（または type コマンド）で、特定のプログラムをシェルがどこで見つけているかを確認できます。 一般的には、特定の種類のファイルをどこに保存するかにはいくつかの慣習があります。以下には講義で取り扱ったものを挙げます。より包括的なリストは Filesystem, Hierarchy Standard を参照してください。

Python のパッケージのインストールには、apt-get install python-[パッケージ] か、pip install [パッケージ] どちらを使うべきですか？

この質問へのユニバーサルな回答はありません。 これは、ソフトウェアをインストールするのに、システムのパッケージマネージャか、言語に特化したパッケージマネージャを使用するか、という一般的な質問に関連しています。 考慮すべきいくつかの点を以下に挙げます。

インストールには、両方の方法ではなく片方のみ使用するべきです。なぜなら、併用することでデバッグが困難なコンフリクトを起こす可能性があるからです。 おすすめは、可能な場合はできる限り言語に特化したパッケージマネージャを使用し、（ Python の virtualenv のような）隔離された環境を使用して、グローバル環境の汚染を避けることです。

コードのパフォーマンスを改善するのに、一番簡単で最善のプロファイリングツールは何ですか？

プロファイリングに非常に便利な一番簡単なツールは print timing です。 コードの様々なパーツの間で、かかった時間を手動で計算します。 これを繰り返すことで、コードのバイナリサーチをして、コードの中で最長の時間がかかっているセグメントを効率的に見つけることができます。

より進化したツールとして、 Valgrind の Callgrind があります。これはプログラムを走らせ、全部にどれだけの時間がかかるかと、全コールスタック、どの関数がどの他の関数を呼び出ししているかを測定します。 その後、プログラムのソースに行ごとにかかった時間のメモがついたものを出力します。 しかし、これはプログラムを相当遅くしますし、スレッドをサポートしていません。 他のケースでは、 perf ツールや他の言語に特化したサンプリングプロファイラが、便利なデータを素早く出力できます。 Flamegraphs は、このようなサンプリングプロファイラの出力を便利に可視化するツールです。 さらに、プログラム言語や、作業中のタスクに特化したツールも使用するべきです。 例えば web 開発では、 Chrome や Firefox にビルトインされた開発ツールに、素晴らしいプロファイラが組み込まれています。

コードの遅い部分の原因が、システムがディスク読み込みやネットワークパケットなどのイベントを待機しているから、というケースもあります。 このようなケースでは、ハードウェア能力の観点から理論的な速度について簡単な計算をして、それが実際の測定値から外れていないか、確認するのが良いでしょう。 さらに、システムコールでの待機時間を解析する専門ツールもあります。ユーザのプログラムのカーネルトレーシングを実行する eBPF などがあります。特に、 bpftrace は、このような低レベルでのプロファイリングを行う場合、必見です。

ブラウザのプラグインは何を使っていますか？

お気に入りをいくつか挙げます。ほとんどがセキュリティとユーザビリティに関連したものです。

便利なデータ収集ツールには他に何がありますか？

データ収集の講義で取り扱う時間がなかったデータ収集ツールには、 jq や pup があります。それぞれ JSON と HTML のダータのパーサーに特化しています。 他の小技は column -t コマンドで、ホワイトスペースで分離されたテキスト（整形されている必要なし）を、カラムで整形されたテキストに適切に変換します。

さらに一般的で柔軟性のあるデータ収集ツールを紹介すると、 vim と Python です。複雑で複数行に渡る変換には、 vim のマクロをツールとして非常に便利に使えます。 一連の動作を記録し、必要な回数だけ繰り返せは良いのです。 例えば、 講義ノート と（去年の ビデオ）には、 vim のマクロのみを使用して XMLフォーマットのファイルを JSON に変換する例が収録されています。

表形式のデータはしばしば CSV として登場しますが、 Python ライブラリの pandas が素晴らしいツールです。 グループ化、結合、フィルタなどの複雑な操作を簡単に定義できるだけでなく、データの様々な特性を簡単にプロットできます。 さらに、 XLS 、 HTML 、 LaTeX などの多くの表フォーマットへのエクスポートもサポートしています。 代替ツールとして、 プログラミング言語の R （議論の余地はあるが 悪い プログラミング言語）には、 データから統計を計算する機能が多くあり、パイプラインの最後のステップとして非常に便利です。 ggplot2 は、 R の素晴らしいプロット用ライブラリです。

Docker とバーチャルマシンの違いは何ですか？

Docker は、コンテナと呼ばれるより一般的な概念に基づいています。 コンテナとバーチャルマシンの違いは、バーチャルマシンはカーネルを含む OS のスタック全体を実行することです。カーネルがホストマシンと同じであっても実行されます。 コンテナが VM と異なるのは、カーネルの新たなインスタンスを実行するのを避け、代わりにホストとカーネルを共有する点です。 Linux では、これは LXC と呼ばれるメカニズムによって実装されています。一連の分離メカニズムを使用して、プログラムに独自のハードウェアで実行しているかのように思わせますが、実際はホストとハードウェアとカーネルをシェアしているのです。そのため、コンテナは完全な VM に対して低負荷です。 一方、コンテナの分離は弱く、ホストが同じカーネルを実行している場合のみ機能します。例えば、もし Docker を macOS で走らせているとして、 Docker が初期の Linux カーネルを取得するために Linux のバーチャルマシンを起動する必要がある場合、負荷は大きなままです。 最後に、 Docker はコンテナの特別な実装であり、ソフトウェア開発用に調整されています。そのため、奇妙な現象があります。例えば、 Docker のコンテナはデフォルトでは、再起動の間いかなるストレージにも残存しません。

各 OS の利点と欠点、選び方について教えてください（例：ある目的に最適な Linux のディストリビューション）

Linux のディストリビューションについては、数多くのディストリビューションがあるものの、 ほとんどの使用ケースについてほとんどがかなり同じような挙動をします。 Linux や UNIX の機能、内部構造のほとんどは、どのディストリビューションでも学べます。 ディストリビューションの根本的な違いは、パッケージのアップデートをどう取り扱っているかです。 Arch Linux のようないくつかのディストリビューションでは、ローリングアップデートポリシーを採用していて、あらゆるものが最新ですが非常に頻繁に壊れます。 一方、 Debian 、 CentOS 、 Ubuntu LTS リリースのような一部のディストリビューションは、 レポジトリにアップデートをリリースするのに遥かに保守的で、新機能を犠牲にする代わりに通常は非常に安定しています。 デスクトップとサーバーの双方で簡単かつ安定した体験をするためのおすすめは、 Debian または Ubuntu の使用です。

Mac OS は、素敵に磨かれたインターフェイスを持つ Windows と Linux の良い中間地点です。 しかし、 Mac OS は Linux よりむしろ BSD が基礎なので、 システムの一部やコマンドは異なります。 チェックすべき代替案は FreeBSD です。 FreeBSD で走らないプログラムもありますが、 BSD のエコシステムは Linux よりも断片化が少なく、ドキュメントも充実しています。 Windows は、 Windows アプリの開発や、解決が必要な難しい問題がある場合、 例えばゲーム向けの充実したドライバーのサポートなどが必要な場合以外にはおすすめしません。

デュアルブートシステムについては、最も実用的な実装は macOS の bootcamp で、他の組み合わせは、 特にディスク暗号化などの他の機能と組み合わせた場合、長期的に見て問題が起こる可能性があると考えています。

Vim vs Emacs?

我々 3 人は vim を主要エディタとして使っていますが、 emacs も良い代替案です。 両方を試して、どちらがしっくり来るか試してみるといいでしょう。 Emacs は vim のモーダルな編集に追随していませんが、これは Evil や Doom Emacs などの Emacs のプラグインで実現可能です。 Emacs を使用するメリットは、エクステンションを Lisp で実装できることで、 これは Vim のデフォルトのスクリプト言語、 vimscript より優れたスクリプト言語です。

機械学習アプリケーションに関して、ヒントや小技はありますか？

この講義での講義や宿題の一部は、 ML のアプリケーションに直接応用できます。 多くの科学の流派でそうであるように、 ML でも一連の実験を行い、何が動き、何が動かないか、確認したくなることがしばしばあるでしょう。 シェルツールを使って簡単かつ素早くこの実験を検索したり、 結果の統計を理解しやすい方法で取ることができます。 これには、特定のタイムフレーム内の全ての実験を選んだり、特定のデータセットを使用したもののみを選択するなどの使い方があります。 実験に関連したパラメータをすべてシンプルな JSON ファイルで記録すれば、これは講義で扱ったツールを使用して非常に簡単に実現可能です。 最後に、GPU にジョブを送る種類のクラスタで作業をしていないならば、 このプロセスを自動化する方法も検討するべきです。 非常に時間がかかるタスクになる上に、 MP も削られるからです。

Vimの小技は他にありますか？

いくつかの小技を紹介します。

2FA とはどのようなもので、使うべき理由は何ですか？

2 要素認証（Two Factor Authentication、2FA）は、アカウントのパスワードの上にさらに保護のレイヤーを追加するものです。ログインの際、パスワードを知っているだけではなく、あるハードウェアデバイスにアクセス可能であることを「証明」する必要があります。これは、電話で SMS を受信することで実現できますが、 SMS 2FA に関しては 既知の問題 があります。私たちが支持するより良い代替案は、 U2F ソリューションを使用することで、例として YubiKey があります。

ウェブブラウザの違いについてコメントはありますか？

2020年時点でのブラウザの様相は、ほとんどが Chrome に似ているというものです。これは同じエンジン（Blink）を使用しているからです。 これは、 Blink をベースとした Microsoft Edge も、 WebKit をベースとした Safari も、これは Blink に似たエンジンですが、 Chrome の下位互換にすぎないということです。 Chrome は、パフォーマンスとユーザビリティの点においてまあまあ良いブラウザです。 他製品が必要ならば、 Firefox が私たちのおすすめです。 あらゆる点で Chrome に匹敵し、プライバシーの面では優れています。 他には、 Flow というブラウザはユーザの使用準備はできていませんが、新しいレンダリングエンジンを実装していて、 現在のものより速いと請けあっています。

このページを編集する

Licensed under CC BY-NC-SA.