驚くかもしれないけど、UMLは、普通のアプリのデバッグに有用なときもあるんだ。たとえば、わけのわからないエラー、しかも、システムコール関係のそれがでて、どうすりゃいいか見当もつかない。いや、そこまではいかなくて、カーネルのドキュメントを見て考えるぐらいの余裕はあっても、実際には、たとえば、エラーコードからエラー原因をさぐろうにも、そのエラーコードを返す原因なんてクサるほど記載されていて特定不能だったり、さらには、そもそも、そんなエラーコードなんて、ドキュメントのどこにも載ってなかったり・・・。なんかありがちな状況だよね。
そんなときはUMLを使うのは一案かも。カーネルの中にブレークポイントを仕掛けてアプリを走らせれば、一発で何が悪いのかわかる、、かもね。

あたらしいカーネルのテストにもUMLはいいかも。UMLはハードを直接たたいてるわけではない。あなたがわざわざ許可した場合は別だけど。だから、新しいカーネルに、たとえば、HDDを吹っ飛ばすような凄すぎるバグがあったばあいでも、吹っ飛ぶのは、UMLの仮想ディスクファイル（ ubdとかroot_fs とか）だけだ。

UMLは、教育分野において、強力なツールとなりうる。とくに、生徒にルート権限を渡さないといけないような分野、たとえば、OSの構造に関する教育とか、ネットワーク管理者の養成とか、それ以外でもシステム管理者関係とかのばあい、強力なツールとなりうる。 Jeff Dike の知ってる範囲でも、UMLは、さまざまな教育用途に使われています。ここにおいて特筆すべきことは、一人一台実際のマシン、という環境より、一人一台仮想マシン、という環境のほうが、はるかに便利だということです。
訳注：なぜ便利かというと、一番端的には、試行錯誤が許されるからです。ちょっと時期的に古いかもしれませんが、IT講習会騒動のときに使われればなぁ、といった印象を持ちました。

UMLは、UMLを走らせている本物のマシンではありえない状態に設定できます。たとえば、より多くのメモリ、より多くの周辺機器、そして、（これは今後の開発しだいですが）シングルCPUのマシン上で、マルチプロセッサを持つ（ように見える）UMLをつくり出すこともできます。ですから、対応するハードウェアを持っていない場合でも、そのハードウェアがあればどうなるのか、ということに関し、開発や検証が可能です。

UMLは、本物のLinux の上で動いています。よって、UMLのなかのLinuxカーネルの内部構造をいろいろイジるのは、普通のソフトのデバッグとあまり変わりません。 ですから、OSの内部構造に関心がある人にとっては、便利でしょう。

特別な許可を与えない限り、UMLの中のLinuxカーネルは、ハードウェアに対する直接のアクセスをしません。ですから、ヤバ目なソフトでも安心して実行できます。ウィンドウズにおいては、すでにウイルスが大流行ですが、それがLinuxにも上陸するでしょう。そんなときには、ヤバ目なソフトのテスト実行などが安心してできるUMLは便利でしょう。
（訳注：sandbox/jail とは、直訳すれば砂場、牢屋だが、コンピュータセキュリティ業界では「隔離施設」のような意味で使われる。）

ある日突然、あなたのマシンがブートしなくなったらパニックですよね。 UMLは、仮想的にそんな大事件を提供できます。それをつかえば、そのような大惨事からどう復活するかの避難訓練が可能です。でも、そんなに深刻にとらえなくてもいいですよ。やってみると面白いから。
このコマンドを実行したらどうなることか。

rm -rf /

危ぶむなかれ。UMLなら危険なし。

いわゆるレンタルサーバ業への応用も面白いでしょう。UMLは、そのための有用な手段となりえます。 といっても、これは、あくまでも可能性のレベルの話ですし、Jeff Dike としては、これが行われているという話は知りませんが。
１ユーザに１仮想マシンをつくり、その仮想マシンへのルートアカウントまですべて渡してしまう。あとは、仮想マシンの内部限定ですが、そのユーザは何でもできます。