鯛焼ぷろじぇくと。Official Website 
このシリーズでは、数学の研究環境を整えていった過程を順番に記録しています。
前回は【なぜ壊れたのか（WSLとWindowsの構造を理解する）】について書きました。まだの方は、先にこちらからどうぞ。
問題を「手順」ではなく「設計」として捉え直しました
第4回では、WSL導入時にOSが起動不能になった原因を整理しました。
そこで見えてきたのは、単なる操作ミスではなく、そもそもの設計の問題でした。つまり「何をどうやったか」ではなく、「どのような構成を選んだか」が問題だったということです。
それまでは、環境構築を「手順の問題」として捉えていました。正しいコマンドを入力し、必要な機能を順番に有効にしていけば最終的に環境は整うだろう、という前提で進めていました。
しかし今回の経験を通して、その考え方では不十分だと感じました。特に、OSの深い部分に影響する操作を含む場合、手順よりも設計の方が重要になることに気づきました。
新しい方針へ
この経験を踏まえて、環境構築の方針を明確に定義し直しました。具体的には、次の3点を重視することにしました。
- Windows本体に影響を与えないこと
管理者権限でOSに変更を加える処理を避ける。 - 問題が起きた場合に簡単に切り離せること
システム構造に複雑に干渉する方法を避ける。 - 再構築が容易であること
うまくいかなかったときに、その部分だけ削除する・戻すなどが容易な方法を考える。
これらを満たす構成であれば、仮に何か問題が起きても被害を最小限に抑えることができます。
また、やり直しが効くという点も重要でした。今回のようにOS全体を初期化するような事態は、できるだけ避ける必要があります。
OSの初期化は、アプリを消すもののデータは残すという方法をとりましたが、それでも結構面倒です。
アプリの入れ直し、ライセンス認証のやり直しなどを個別で行わなくてはなりません。
これを書いている現在も、すべてのアプリを元に戻せたわけではありません。
優先度の高いアプリのみ入れ直ししている状態です。
改めて選択肢を比較しました
この新しい方針をもとに、改めてLinux環境の導入方法を見直しました。
候補として考えたのは、第2回と同じくWSLと仮想マシンです。
まずWSLについては、手軽さや統合性という点では依然として魅力的でした。しかし一方で、今回の経験から、Windowsの機能に直接依存している点が気になるようになりました。WSLは便利である反面、OSと密接に結びついているため、トラブルが発生した場合の影響範囲が広くなる可能性があります。
次に仮想マシンについて考えました。VirtualBoxなどを使う方法です。
こちらは、あらかじめ用意した仮想環境の中でLinuxを動かすため、Windows本体とは明確に分離されています。仮想マシン内で何か問題が起きても、最悪の場合その環境を削除すれば元に戻せます。
この違いは、今回の方針に照らしてみると非常に大きなものでした。
VirtualBoxを選択
最終的に、仮想マシンを使う方法、具体的にはVirtualBoxを採用することにしました。
決め手になったのは、やはり「分離されている」という点です。
- Windows本体とは独立している
- 仮想マシン単位で管理できる
- 問題が起きても削除すれば済む
この構造であれば、今回のようにOS全体が影響を受けることは基本的にありません。また、環境を作り直すことも比較的簡単です。
この時点での認識としては、「多少重くても構わないので、安全な構成を選ぶ」というものでした。最初にWSLを選んだときとは、判断基準が大きく変わっていました。
仮想マシンの導入には他にも選択肢がありますが、比較的メジャーでトラブルシューティングも行いやすそうなVirtualBoxを選択しました。他の選択肢でも、比較的安全に導入できるだろうとは思います。
判断基準は重要
振り返ってみると、この第5回の段階が一つの転換点でした。第2回では「手軽さ」を優先してWSLを選びましたが、この時点では「安全性」と「可逆性」を優先するようになっていました。
つまり、単にツールを選び直したのではなく、環境構築に対する考え方そのものが変わっていました。この変化は、その後の作業にも大きく影響しています。
次回
次回は、実際にVirtualBoxを導入し、Ubuntuの仮想環境を構築していった過程について書きます。
ここからようやく、安定した前提のもとで環境構築を進められる状態になりました。
次回は、【VirtualBox + Ubuntu 環境構築】について書きます。