Assemblyの温もりに浸る：Webサーバーをゼロから構築する
高レベルフレームワーク、クラウドネイティブな抽象化、そしてAI生成コードが主流の現代において、Webサーバーを完全にアセンブリで記述するという行為は、実用的なエンジニアリングの選択というよりも、デジタル・パフォーマンス・アートのように感じられます。開発者 imtomt によるプロジェクト ymawky（「yuh maw kee」と発音）は、あらゆる利便性のレイヤーを剥ぎ取り、ARM64アセンブリと直接的なシステムコールのみを使用して、機能的な静的ファイルWebサーバーを構築しています。
ほとんどの現代的な開発者にとって、カーネルはオペレーティングシステムによって管理され、libc のような標準ライブラリを介してアクセスされる遠い存在です。これらのライブラリを完全にバイパスすることで、ymawky はソフトウェアが実際にどのようにハードウェアやOSと通信するかを示すマスタークラスとして機能し、生産性の指標よりも職人技と深い技術的好奇心が優先される「ハッカー」精神を思い出させてくれます。
ymawky のアーキテクチャ
ymawky は、syscallのみ、no-libc、fork-per-connection（接続ごとにプロセスを生成）サーバーとして設計されています。これは、リクエストが来るたびに、サーバーが接続を処理するために新しいプロセスを作成することを意味します。これは並行処理に対する古典的な（必ずしもスケーラブルではないものの）アプローチであり、低レベル環境における状態管理を簡素化します。
コア機能
アセンブリで記述されているにもかかわらず、このサーバーは静的ファイルホストとして驚くほど機能が充実しています。
- HTTPメソッドのサポート:
GET,PUT,DELETE,OPTIONS,HEADリクエストを処理します。 - 高度な GET 機能:
Range: bytes=リクエストをサポートしており、ビデオのシークや部分的なコンテンツ配信（HTTP 206）を可能にします。 - アトミックなアップロード:
PUTリクエストは、一時ファイルに書き込んでから名前を変更することで処理され、並行するアップロードが破損したファイルや書き込み途中のファイルを残さないように保証されます。 - MIMEタイプ検出: サーバーはファイル拡張子を分析し、
.wasmや.webpから.mp4や.pdfまで、あらゆるものに対して正しいContent-Typeを提供します。 - セキュリティのガードレール: 一般的な脆弱性を防ぐため、サーバーはパス・トラバーサル検出（
..をブロック）を実装し、PATH_MAXを超えるパスを拒否し、O_NOFOLLOW_ANYを使用してシンボリックリンクを拒否します。
防御的設計
アセンブリでの記述は、しばしばメモリ安全性の懸念を招きます。作者は、いくつかの「安全性」機能を実装することで、これらを軽減しています。
- タイムアウト・メカニズム: Slowloris スタイルの Denial of Service (DoS) 攻撃を防ぐため、サーバーはデータが10秒以内に受信されない場合、またはヘッダーの受信に時間がかかりすぎる場合に接続を閉じます。
- リソース制限:
MAX_PROCS制限（デフォルト 256）により、サーバーがシステムの PID スペースを使い果たすのを防ぎます。 - 入力バリデーション: 最初の16バイト以内にパスが含まれていないリクエストは、直ちに拒否されます。
ポータビリティの課題
ymawky の最も際立った側面の一つは、macOS への深い依存です。作者はポータブルにしようと試みましたが、実装ノートには Unix 系カーネル間の顕著な違いが明らかになっています。
例えば、macOS はシステムコール番号に x16 を使用し、呼び出しに svc #0x80 を使用しますが、一方で Linux は x8 と svc #0 を使用します。fork() のような基本的な操作でさえ、異なるシステムでは異なるレジスタに異なる値を返します。さらに、このプロジェクトは renameatx_np() や、作者が libc ト램プリンを完全にスキップできる独自の sigaction 構造体を利用しています。
コミュニティメンバーの @mappu は、次のように述べています。これによって、低レベルプログラミングの継続的な現実が浮き彫りにされます。「macOS のシステムコールは安定性が保証されていません... 安定したシステムコール番号は Linux のものだけです。他の誰もが、祝福されたシステムライブラリを使用しています。」
コミュニティの考察：アート vs. 実用性
このプロジェクトは、LLM の時代における手動コーディングの役割について、Hacker News コミュニティの中で哲学的な議論を論争点として巻き起こしました。
一部の人は、このプロジェクトを「vibe coding」に対する必要な反 rebellion (反乱) と見なしました。@stbev は次のように述べています。あえて逆行することには、深い満足感があります。
"I want to feel challenged again. I know it's crazy, and by no means useful. Prerfectly expressed, perfectly expressed."
他の人は、このような手動の作業を、消えゆく芸術形式として惜しみました。@rdevilla は、視点の変化について次のように述べています。「10年前、私は誰かエリート層がこのようなものを作れるほどに技術的に高度な技術を持っていたら、効率をよく用いてください。Today, I just think, 'how long would LLMs have taken to write this?'"
しかし、支配的な感情は、Go や Python の数行でできることを、数千行のアセンブリをマッピングすることに要する純粋な決意に賞賛の念を、提供します。それは、高レベル言語がソフトウェアの提供方法（how）を提供し、アセンブリはコンピュータが実際にどのように機能するかという理由（why）を提供することを思い出させてくれます。
結論
ymawky は、本番環境向けのツールではありません。それは教育的な演習であり、情熱の結晶です。ネットワーク、ファイル I/O、プロセス管理の基本は、現代的なフレームワークを使用するか、レジスタの間でバイトを移動させるかに関わらず、常に一定であることを示しています。そうすることで、作者（および読者）に、絶対的な技術的制御の追求を通じて、意味のある感覚を与えています。