# Y1 - OS自作ゼミ 応募課題


## はじめに
問題は4つあります。
回答する際は以下のことに気をつけてください。

- 密度の濃い回答を心がけてください。
  - 各設問は、皆さんが各設問に対してどのように思考して、手を動かして調査し、最終的にどのような結論に至ったのかという過程全体を見ています。
  - 分からないことがあった場合でも「分かりませんでした」とだけ記述するのではなく、何をどのように調べ、どこまでのことは理解できたが、何が理解できなかったか、どういった可能性が考えられるか、という途中経過を書いてください。
  - 回答本文は各設問ごとにそれぞれ2048文字以下としてください。(ソースコード、URLリンク、その他添付ファイルを除く。)
  - 記述量が闇雲に多いが情報量に乏しい回答は避けてください。
- ほかの文献に当たって知ったことをそのまま書く際は出典を必ず示してください。
  - URLや書籍名、閲覧日などを明記してください。
- ソースコードはコンパイルが通る状態で提出してください。
  - `clang-format`などで整形して提出してください。
  - ソースコードは別ファイルとして提出してもよいですし、Markdownのコードブロックとして記述しても構いません。


### LLMの使用について
回答に際しては、LLMを自由に利用していただいて構いません。（もちろん無理に利用する必要もありません。）
ただし、使用したモデルと与えたプロンプト、および回答に際して行った対話のログ全体を添付してください。

LLMの回答はもっともらしく見えるよう最適化されていますが、必ずしも実世界の事実を反映していない場合があります。適宜出典を確認し、回答に含まれる情報の真偽を確かめてください。

最終的な課題への回答で引用されている資料が実際には存在しないものであったり、回答と関係ない、もしくは不確実な情報が記載されている資料を引用している場合は、LLMを有効に活用できていないとみなします。また、過度に多数の文献を引用することも避けてください。

LLMの出力結果だけでなく、自ら手を動かして検証した結果や思考も必ず含めるようにしてください。


## 問題.1
​本ゼミで自作したいOS（もしくはそれに類するもの）について、講義概要をよく読んだ上で具体的に回答してください。

もしこの分野について初心者である場合は、なぜシステムソフトウェアに興味を持ち、OSのどのような点に惹かれて自作したいと思うに至ったのか、あなたの個人的な実体験に基づいて記述してください。

​さらに、以下の2点について必ず言及してください。

​i. 現在感じている限界: その目標を一人で今すぐ完遂することを阻んでいる、具体的な技術的・認知的障壁（理解が及んでいない概念、実装で躓いているポイント、設計上の迷いなど）は何ですか？

​ii. キャンプで得たいもの: セキュリティキャンプという、講師や他の受講生がいる環境を利用して、上記iで述べた障壁をどのように突破しようと考えていますか？

「有意義な議論がしたい」といった抽象的な期待ではなく、具体的にどのような技術的テーマについて議論（あるいはペアデバッグなど）をしたいか記述してください。


​## 問題.2
​これまでにあなたが行った中で最も困難だった「デバッグ」体験について詳しく教えてください。

ここでいうデバッグは、必ずしもプログラミングやコンピューターに限らず、論理的推論と試行錯誤によって解決した、何らかの仕組みの意図しない挙動を修復した経験を指します。もちろん、プログラミングのデバッグ体験でも構いません。

​解決に至る過程のなかで、どのように思考し、どのように手を動かして調査し、最終的に解決に至ったのかを具体的に語ってください。壮絶なデバッグ体験であればあるほど歓迎します。

​その際、あなたの「思考の軌跡」をより解像度高く理解するため、以下の3点について必ず言及してください。

i. ​最大のタイムロスを生んだ落とし穴: デバッグの過程で、あなたが「絶対にここが原因だ」「こういう仕様のはずだ」と信じ込んでしまい、結果的に時間を無駄にした仮説は何でしたか？

​ii. 突破口となったきっかけ: 上で述べた、誤った思い込みを打ち砕き、真の原因へとたどり着くきっかけとなった具体的な事象（ある1行のエラーログ、ドキュメントの記述、物理的な観察結果、他者との対話など）は何でしたか？

​iii. そこから得た学び: 最終的に判明した原因は、あなたの事前の理解や推測とどのように食い違っていましたか？また、その経験から自身の「思考の癖」や「システムに対する向き合い方」について何を学びましたか？


​## 問題.3
​システムソフトウェアの世界は、物理法則や限られたリソースに起因する「解決不能なトレードオフ」の連続です。
例えば「パフォーマンスの極限追求」と「消費電力の抑制」、「過去の巨大なソフトウェア資産との後方互換性の維持」と「実装の美しさ」、「抽象化レイヤによる安全性」と「ハードウェアの直接制御による性能の最大化」などが挙げられます。

​もしあなたが、新しいOSやシステムソフトウェアをゼロから設計するとしたら、どのようなトレードオフに関して、どのような「尖った」決断を下しますか？
​
回答に際して、以下の3点について具体的に記述してください。

i. 直面するトレードオフの定義: あなたが最も葛藤を覚える、あるいは最も興味がある「相反する2つの要求」は何ですか？

​ii. あなたの決断とその背景: 上記の対立において、あなたはどちらを優先しますか？一般論ではなく、あなたの個人的な経験に基づいて「そう決断する理由」を語ってください。
​
iii. 「犠牲」への向き合い方: その決断によって、必然的にシステムから切り捨てられるメリットや、不利益を被るユーザー（あるいは開発者）が存在するはずです。その「犠牲」に対して、設計者としてどのように責任を持ち、あるいは割り切りますか？


## 問題.4

以下のプログラムを見てください。

```c
#include <stdio.h>

int rec(int n) {
  printf(""%d\n"", n);
  return rec(n+1);
}

int main(void) {
  return rec(0);
}
```

このプログラムを実行する前に、このプログラムの実行結果がどのようになるのかをできる限り正確に予想して、その予想の背後にあるあなたの理解を説明してください。必要であれば、OSのソースコードや設定パラメーターを調査しても構いませんが、このプログラムに類するコードを実行してはいけません。

予想を書き終わったら、このプログラムを実行してみましょう。
上記のプログラムを`a.c`として保存して`gcc -o a a.c`や`clang -o a a.c`などでコンパイルして実行してください。

実行できたら、その実行結果を回答に貼り付け、その結果と先程記した予想がどう異なっていたか、なぜその差異が生じたのかをできるかぎり詳しく調査して報告してください。定性的に述べるだけでなく、実際の実行環境におけるパラメーターや実装コードを示しながら、定量的にその結果が得られた理由を突き止めてください。必要に応じて、追加の実験を行ってその結果を記して利用しても構いません。また、再現性を確保するために必要と思われる情報、たとえばOSのバージョンやコンパイラのバージョンなども、必要十分な範囲で回答に含めてください。


## アンケート: 事前学習に割ける時間について

選考を通過して本ゼミへの参加が確定した場合に、どの程度の時間を事前学習に割けるか、現時点でわかる範囲で教えてください。（この項目は選考結果には影響しません。）
講師が準備を行う際に、講義の具体的内容やスケジュールを決定する際の参考とします。