ディスカッション (10件)
「Zeroserve」は、面倒な設定を一切排除しつつ、eBPFのパワーで柔軟にカスタマイズ可能な新しいWebサーバーです。複雑な構成ファイルに悩まされることなく、プログラム可能な制御を実現したいエンジニアには見逃せないツールになるでしょう。
良さそうだし、機能もナイス。でも、なぜかピンとこないんだよね。なんだか人工的すぎて。メトリクスが捏造されてるのか、便利な関数がちゃんと動くのか、まともなハードニングがされてるのかが分からないし。
「vibe coding(直感的なコーディング)」で作られててREADMEがAI生成でも許容できるけど、発表のブログ投稿までAI生成だとね。正直、開発者側と自分のソフトウェア品質に対する感覚が一致してるか判断するための材料が何もないんだ。
不思議な時代になったものだ。数年前にAIの断り書きなしでこれが発表されてたら、疑いもせずに飛びついていただろうな。でも今は、READMEが見栄えの良いコマンドラインパラメータを並べてると、「これってAIのハルシネーション(幻覚)じゃないの?実際にはそのパラメータ存在しないんじゃないの?」ってすぐに疑ってしまう。
このアイデアいいね。
個人的には.cファイルじゃなくて.rsファイルをeBPFディレクトリに放り込めるようになったらもっと嬉しいかな。せっかくのRustプロジェクトなんだし!:)
あと、勝手に「カーネルアクセラレーションを使ったWebサーバー」を期待してたんだけど、もしeBPFで安全に実現できるなら最高だね!
それと、シングルスレッドなのかな?Linuxならforkして受信接続キューを共有するのは基本だし、Rustなら数行で書けるはず。SO_REUSEPORTを使えばカーネルが勝手にやってくれるし。
余計なお世話かもしれないけど、io_uringを推進するならkTLSも検討すべきだと思う。ハンドシェイク後のユーザー空間でのSSL処理を回避できれば、設計が劇的にシンプルになるはずだよ。
LLMのおかげでこういうアイデアを低コストかつ短時間で検証できるようになったからこそ生まれたんだろうね。こういうのを見るのは大好きだよ。
ただ、個人的な教訓としては、nginxってそれ単体で相当すごいんだなと再認識させられた。あと、以下の記述が気になったよ。
nginxやCaddyの代替を目指していて、その設計の賭けは「設定」にある。それらのサーバーは宣言的な設定言語(locationブロック、rewriteルール、mapディレクティブ、try_filesなど)を提供しているが、それが限界に達すると、LuaやCaddyプラグインのような外部のスクリプト環境を無理やり追加することになる。結果として、動作が2層に分断されてしまう。独自に制御フローを増やしていくディレクティブと、リクエストのライフサイクルのどこかで動くスクリプトの両方を頭に入れておかないといけないからね。
でも、その「賭け」は的外れな気がする。みんなコードより設定を好むし、それは今に始まったことじゃない。ビルトインの機能で大半の人のニーズは満たせてるし、わざわざCコードを書きたがる人はいないよ。
面白いアイデアだけど、静的ファイルにフォーカスすべきじゃないと思う。最近は静的ファイルのためだけにわざわざサーバーを立てるなんてことはあんまりしないからね。
なんでtarballなの?
techempowerのWebサーバーベンチマークが終わってしまったせいで、新しいサーバーが自分の実力を証明する場がなくなってしまったね。
追記:自分が情報を追えてなかったみたいだ。今は https://www.http-arena.com/leaderboard/ がホットな場所なんだね。がんばって!
すごくいいね!xdpプログラムやsocket mapにアタッチするプログラムみたいな他のBPFプログラムタイプと組み合わせて、L7のHTTP機能を下層に統合できたら面白そう。
これ最高に見える
面白い新しいコンセプトだね、気に入った。
本当の問題は開発者のコミットメントとコミュニティだよ。CaddyやNginxの開発者たちは製品を支えるためにずっと取り組み続けてきたからね。ここから先は相当な集中力と情熱が必要になるはず。