Zeroserve: eBPF ile betik yazılabilen yapılandırmasız web sunucusu

• Küçük ve hızlı bir HTTPS sunucusu olan zeroserve, bir web sitesi tarball’ını alıp bunu HTTP/2 ve TLS 1.3 ile sunuyor; tarball içindeki eBPF programlarını ise her istekte kullanıcı alanındaki sandbox middleware olarak çalıştırıyor
• Yapılandırma dosyası olmadan, eBPF programları istek bazında yönlendirme, başlıklar, kimlik doğrulama, hız sınırlama ve proxy kararlarını vererek nginx·Caddy’nin bildirimsel yapılandırmasını ayrı bir betik katmanıyla tek bir yapıda birleştiriyor
• Site tek bir tar dosyası olarak indeksleniyor ve diske açılmıyor; tarball değiştirilip SIGHUP gönderildiğinde site, betikler ve TLS verileri bağlantı kaybı olmadan atomik olarak değiştiriliyor
• Tek çekirdekli HTTPS benchmark’ında zeroserve, küçük statik dosyada 36,681 req/s, 10ms eBPF dinamik JSON’da 46,945 req/s, küçük proxy’de 26,486 req/s elde etti; ancak 100KB proxy senaryosunda 5,882 req/s ile nginx önde
• zeroserve, nginx ve Caddy’ye alternatif olmayı hedefleyerek tek tarball dağıtımı, programatik yapılandırma, kullanıcı alanı eBPF ve modern TLS’i bir araya getiriyor; ancak büyük proxy yanıtlarında nginx daha uygun

---

Genel bakış

• zeroserve, tek bir web sitesi tarball’ını HTTP/2 ve TLS 1.3 ile sunan küçük, hızlı ve yapılandırmasız bir HTTPS sunucusudur
• Tarball içine konan eBPF programları her istekte kullanıcı alanındaki sandbox middleware olarak çalışır; istek yeniden yazma, kimlik doğrulama, hız sınırlama ve arka uç reverse proxy işlemlerini gerçekleştirebilir
• Tek çekirdek bazında, küçük ve büyük statik dosyalar, betik middleware ve küçük yanıt proxy’si dahil çoğu iş yükünde nginx’ten daha yüksek performans hedefleyen bir sunucudur
• eBPF betikleri native koda JIT derlenir ve kullanıcı alanında sandbox içine alınır; her istekte çalıştırılabilecek kadar düşük ek yük hedeflenir
• Ağ ve disk işlemleri, monoio runtime’ı üzerinden io_uring ile gönderilir
• TLS 1.3, HTTP/2, Encrypted Client Hello, SNI sertifika seçimi ve JA4 fingerprinting desteği sunar
• Tüm site ve TLS verileri tek bir tarball’dan sunulur ve SIGHUP ile hot reload yapılabilir

Yapılandırma modeli: program yapılandırmanın kendisi

• zeroserve, nginx ve Caddy’ye alternatif olmayı hedefler ve temel tasarım tercihi yapılandırma biçimidir
• nginx ve Caddy, location blokları, rewrite kuralları, map direktifleri, try_files gibi bildirimsel yapılandırma dilleri sunar; sınırlarına gelindiğinde ise Lua veya Caddy eklentileri gibi isteğe bağlı betik runtime’ları eklenir
• Bu yapıda davranış, kendi kontrol akışına sahip direktif katmanı ile istek yaşam döngüsünün belirli noktalarında çalışan betik katmanı arasında bölünür
• zeroserve’de yapılandırma dosyası yoktur; tek bir eBPF programı tüm istekleri görür ve yönlendirme, başlıklar, kimlik doğrulama, hız sınırlama ve proxy kararlarını verir

Tek bir tarball’ı olduğu gibi sunma

• Tüm site tek bir tar dosyasıdır; zeroserve yükleme sırasında path -> byte-range haritası oluşturur ve dosyaları sunmak için doğrudan tarball üzerinde byte-range okuması yapar
• Hiçbir dosya diske açılmadığı için site yalnızca tek bir dosya içinde bulunur; yanlış bir location kuralının açığa çıkarabileceği bir document root yoktur
• Dağıtım, tek dosyanın atomik olarak değiştirilmesiyle yapılır; yeni sürüm için tarball değiştirilir ve ardından SIGHUP gönderilir
• Dizin paketleme ve çalıştırma komutu şu biçimdedir

zeroserve --pack ./public > site.tar  
zeroserve --addr 0.0.0.0:8080 site.tar  

• Hot reload komutu şu biçimdedir

killall -SIGHUP zeroserve  

• Reload, aynı süreç içinde siteyi, betikleri ve TLS verilerini atomik olarak değiştirir ve bağlantı kaybı olmadan çalışır
• Her instance tek iş parçacıklı bir event loop’tur; tek süreç açısından bu bir sınırlama olsa da ölçekleme birimi “daha fazla süreç” olduğunda uygun bir model olarak sunulur

Kullanıcı alanında eBPF betik çalıştırma

• .zeroserve/scripts/ altına konan tüm .c dosyaları, paketleme anında clang ve llc ile eBPF nesnelerine derlenir ve her istekte çalıştırılır
• eBPF, kernel BPF subsystem’i ya da CAP_BPF olmadan, normal ayrıcalıksız bir süreç içindeki async-ebpf runtime’ında kullanıcı alanında çalıştırılır
• async-ebpf, uBPF gömerek bytecode’u native x86-64 makine koduna JIT derler
• Pointer cage, JIT derlenmiş kodun tüm bellek erişimlerini programa özel arena ile maskeleyerek hatalı erişimleri betik belleği içinde hapseder
• Betikler doğrudan zeroserve’ün tek event loop’u üzerinde çalışır; yavaş bir betiğin diğer bağlantıları durdurmaması için bir zamanlayıcı, çalışan JIT derlenmiş native kodu yürütme sırasında kesebilir ve kontrolü event loop’a geri verebilir
• Programlama modeli, dosya adı sırasına göre çalışan bir betik zinciridir ve betikler istek bazlı bir metadata haritasını paylaşır
• Bir betik zs_respond veya zs_reverse_proxy çağırdığında zincir kısa devreyle sonlanır
• zs.response.header.* altındaki anahtarlar tüm yanıtların başlıkları olur; diğer anahtarlar ise HTML dosyalarındaki <zs-meta>visitor</zs-meta> gibi placeholder’ları çıktı anında değiştiren küçük bir template geçişinde kullanılır
• Helper yüzeyi, istek metodu·yolu·query·başlıklar·peer adresi okuma, URI yeniden yazma, başlık ayarlama ve silmeyi destekler
• Kriptografi ve kodlama helper’ları SHA-256, HMAC-SHA256, base64, hex ve getrandom sağlar
• JSON helper’ları istek gövdesi ayrıştırma, belge ağacı oluşturma ve değiştirme, ayrıca zs_json_respond ile yanıt vermeyi destekler
• Hız sınırlama, peer IP veya API anahtarı gibi key’lere dayalı token bucket desteği sunar; durum hot reload sonrasında da korunur
• AWS SigV4 helper’ı, S3 ve diğer AWS servisleriyle iletişim için imzalı Authorization başlığı ve presigned URL desteği sağlar
• OIDC girişi, Authorization Code + PKCE tabanlı relying-party akışı sunar; tüm oturum durumu sealed XChaCha20-Poly1305 cookie içinde tutulur, böylece sunucu stateless kalırken statik bir site “Google ile giriş yap” arkasına alınabilir
• Dinamik endpoint’ler, belirli yollarda betiğin doğrudan yanıt vermesiyle çalışır; örnekte /health isteğine application/json başlığı ve {"status":"ok"} gövdesi döndürülür
• Her betik varsayılan olarak 256KB bellek üst sınırı altında çalışır; runtime uzun süren betikleri executor üzerinde time-slice eder ve kontrolden çıkan betikleri throttle eder
• Betikler zs_call ile birbirini çağırabilir ve çağrı derinliği sınırlıdır
• Sonsuz döngüye giren bir betik yalnızca kendi isteğini geciktirir; preempt timer bunu keserek sunucunun diğer istekleri işlemeye devam etmesini sağlar
• TLS katmanı yalnızca TLS 1.3’tür ve BoringSSL ile sonlandırılır
• Encrypted Client Hello, gerçek SNI’nin düz metin olarak görünmesini engeller; dizin tabanlı SNI sertifika seçimi ve betiklere açılan JA4 istemci fingerprinting’i sağlar
• Şeffaf ECH relay modu, çözülemeyen handshake’leri gerçek upstream’e byte düzeyinde aynen ileterek korunan adların açık adların arkasında karışık şekilde bulunmasına imkân verir

Performans

• Benchmark koşulları

  • zeroserve, nginx 1.26 ve Caddy 2.11, 8 çekirdekli Ryzen 7 3700X üzerinde aynı içerik ve aynı self-signed sertifika ile HTTPS sunumu için karşılaştırıldı
  • zeroserve instance’ı tasarım gereği tek iş parçacıklı olduğu için karşılaştırma ölçütü çekirdek başına performanstı
  • Tüm sunucular taskset ile tek bir CPU’ya sabitlendi; nginx worker_processes 1, Caddy GOMAXPROCS=1, zeroserve ise mevcut tek iş parçacıklı yapısını kullandı
  • Yük, başka çekirdeklerde wrk -t4 -c100 ile üretildi ve 10 saniyelik 3 çalışmanın medyanı kullanıldı
  • wrk HTTP/1.1 kullandığı için sayılar, TLS 1.3 üzerindeki HTTP/1.1 içindir; el sıkışma maliyetinin uzun keep-alive bağlantılarla amorti edildiği, zaten açık HTTPS bağlantılarındaki kararlı durum maliyetini gösterir

• Küçük statik dosya 174B

  Sunucu	req/s	p99
  zeroserve	36,681	5.4 ms
  nginx	31,226	7.8 ms
  Caddy	12,830	22 ms

  • zeroserve, tek çekirdekte küçük dosyaları nginx’ten yaklaşık %17 daha hızlı sundu ve tail latency değeri de daha düşüktü
  • HTML sayfaları, küçük JSON ve CSS gibi statik site temel senaryoları, zeroserve’ün optimize ettiği alanlardır

• Büyük statik dosya 100KB

  Sunucu	req/s	Throughput	p99
  zeroserve	8,000	782 MB/s	22 ms
  nginx	7,600	773 MB/s	28 ms
  Caddy	6,084	590 MB/s	44 ms

  • Üç sunucunun sonuçları birbirine yakındı; zeroserve tek çekirdekte yaklaşık 780 MB/s ile az farkla öne geçti
  • nginx’in büyük dosyalardaki sendfile() avantajı TLS altında kullanılamaz; çünkü byte’ların kullanıcı alanında şifrelenmesi gerekir, bu yüzden üç sunucu da şifreleme ve yazma döngüsüne bağlı kalır
  • Üç sunucuda da kernel TLS kapalıyken, zeroserve’ün io_uring okuma-yazma yolu biraz daha hızlı sonuç verdi

eBPF vs Lua

• Betik karşılaştırmasındaki rakip, web sunucusu içinde hızlı kod çalıştırmanın yaygın yolu olan nginx + LuaJIT ngx_http_lua_module’dür
• zeroserve varsayılan olarak betik preemption timer’ını her 2ms’de bir ayarlar; daha sık aralık sorunlu betikleri hızlıca throttle eder ama normal betiklere de maliyet bindirir
• Varsayılan 2ms ayarında, tamamen dinamik yanıt senaryosunda eBPF yaklaşık 32k req/s ile nginx Lua’nın 41k req/s değerinin altında kalır
• --preempt-timer-interval-ms değeri 10’a çıkarıldığında betik throughput’u yaklaşık %40 toparlanır ve sonuç tersine döner

• İstek başına başlık ekleme middleware’i

  Motor	req/s	p99
  zeroserve eBPF 10ms	43,709	5.1 ms
  zeroserve eBPF 2ms varsayılan	31,334	6.7 ms
  nginx Lua header_filter	28,653	8.4 ms

  • Betiğin çalıştığı ama statik dosyanın sunulmaya devam ettiği middleware senaryosunda 10ms eBPF, nginx Lua’dan yaklaşık %50 daha yüksek ve tail latency de daha düşüktür

• Tamamen dinamik JSON yanıtı

  Motor	req/s	p99
  zeroserve eBPF 10ms	46,945	4.5 ms
  nginx Lua content_by_lua	41,231	6.4 ms
  zeroserve eBPF 2ms varsayılan	32,393	6.7 ms

  • 10ms aralığına ayarlanmış eBPF, tamamen sentezlenmiş yanıt senaryosunda da nginx’in content_by_lua yaklaşımından daha yüksek throughput elde eder
  • Her iki motor da native koda derlenir; LuaJIT bir tracing JIT iken async-ebpf, uBPF üzerinden eBPF’yi JIT derler
  • TLS şifrelemesinin ortak istek maliyeti olduğu koşullarda, ayarlanmış eBPF yolu throughput’ta öne geçer
  • Varsayılan 2ms ayarında eBPF middleware avantajını korusa da sentezlenmiş yanıt liderliğini kaybeder; bu nedenle üretim betikleri için 10ms önerilir

Reverse proxy olarak kullanım

• zeroserve, betik içinden zs_reverse_proxy("http://127.0.0.1:9000";) çağrısıyla arka uca proxy yapar
• Upstream bağlantı havuzu, her backend için en fazla 128 bağlantı ve 30 saniyelik idle yeniden kullanımını destekler
• Adil bir karşılaştırma için nginx tarafında, varsayılan olarak her istekte upstream bağlantısını kapatma davranışı dikkate alınarak keepalive 128, proxy_http_version 1.1 ve boş Connection başlığı açıkça kullanıldı
• Caddy, varsayılan davranışıyla bağlantı yeniden kullanımını sürdürdü
• Her proxy tek çekirdekte TLS sonlandırıp paylaşılan düz metin backend’e iletti; backend ise ayrı bir 2 çekirdekli sunucuda kendi başına 100k req/s sürdürebildiği için yalnızca proxy ek yükü ölçüldü

• Küçük 174B yanıt proxy’si

  Proxy	req/s	p50	p99
  zeroserve	26,486	3.3 ms	8 ms
  nginx	21,761	4.2 ms	10.5 ms
  Caddy	7,683	10.3 ms	33 ms

  • zeroserve’ün havuzlanmış io_uring proxy’si nginx’ten yaklaşık %22 daha hızlıydı ve Caddy’ye kıyasla yaklaşık 3.4 kat throughput sağladı
  • API çağrıları, küçük JSON ve uygulama sunucusu HTML’i gibi yaygın proxy iş yüklerinde zeroserve, TLS sonlandırma ve backend iletimini daha hızlı gerçekleştirir

• 100KB yanıt proxy’si

  Proxy	req/s	Throughput
  nginx	5,882	585 MB/s
  Caddy	4,285	406 MB/s
  zeroserve	3,631	359 MB/s

  • Proxy gövdesi büyüdüğünde nginx’in buffering mekanizması byte’ları daha verimli taşıyarak öne geçer; Caddy ortada, zeroserve geride kalır
  • Proxy yanıtları büyükse nginx daha iyi araçtır; çok sayıda küçük yanıt varsa zeroserve daha hızlıdır

Bellek

• Boştaki tek bir zeroserve instance’ı yaklaşık 15MB PSS kullanır; bu değer nginx’in yaklaşık 6MB’ından fazla, Caddy’nin yaklaşık 60MB’ından ise düşüktür
• Çalıştırma biriminin tüm süreç olması önemlidir; çekirdek başına bir kopya çalıştırıldığında aynı binary eşlenir ve kod sayfaları paylaşılır
• Ek süreçler, kendi working set’leri dışında az miktarda ek bellek kullanır

Yayın

• zeroserve, GitHub’da açık kaynak olarak yayımlanan bir projedir

[GN⁺]

Hacker News yorumları

• TechEmpower web sunucusu benchmark'ları ortadan kalkınca, bu tür yeni projelerin kendini kanıtlama fırsatı da azalmış gibi görünüyor
  Düzeltme: Sanırım geride kalmışım; bugünlerde öne çıkan şey https://www.http-arena.com/leaderboard/ gibi görünüyor. Bol şans

  • “Ortadan kalktı” derken ne kastedildiğini anlamadım. Hâlâ https://www.techempower.com/benchmarks/#section=data-r23 adresinde duruyor ve son benchmark da 2025 Şubat'ında yapılmış
    Ama zaten hiçbir zaman çok sık çalıştırılmıyordu; tur geçmişine bakınca yılda bir kereden bile az yapıldığı görülüyor
  • LLM UI/UX gerçekten çok kötü. Böyle bir şeye hafta sonundan bir iki gün ayırmak bile kullanıcı deneyimini epey iyileştirebilirken neden yapılmadığını anlamıyorum

• Bu tür denemelerin LLM sayesinde görece ucuz ve hızlı biçimde keşfedilebilir hâle gelerek ortaya çıkmasını görmek güzel
  Ama burada bende bıraktığı asıl izlenim, nginx'in kendi başına ne kadar etkileyici olduğu. Dikkatimi çeken başka bir nokta da, bu projenin nginx ve Caddy'ye alternatif olduğu ve yapılandırma yaklaşımına oynadığı yönündeki açıklamaydı
  nginx ve Caddy bildirimsel yapılandırma dilleri sunuyor; sınırlarına gelindiğinde ise yanına Lua ya da Caddy eklentileri gibi bir script çalışma zamanı ekleniyor, yani davranış iki katmana bölünüyor
  Ama bu bahis bence yanlış. İnsanlar çok uzun zamandır kod yerine yapılandırmayı tercih ediyor ve çoğu durumda yerleşik özellikler yeterli olduğu için C kodu yazmaya gerek kalmıyor

  • Bundan o kadar emin olmak zor
    Tüm yapılandırma dosyası biçimleri başlangıçta basit görünüyor. YAML'nin temeli de oldukça makuldü ama insanlar anchor'lar ve alias'larla daha karmaşık şeyler istemeye başladı
    GitLab'ın bile koşullu ifadeler ve değişken benzeri öğeler içeren kendine özgü bir biçimi var; üstelik sadece belirli yerlerde çalışan, hack'e yakın bir şey. Apache de XML tabanlı yapılandırma biçimiyle benzer bir yola gitti
    Sonunda yapılandırma yönetimi için sayısız özel programlama dili ortaya çıktı. Kurumsal ortamlarda insanlar bunu doğrudan düzenlemiyor; uzaktan cerrahi gibi işlemler için Ansible iş akışlarını script'lerle kuruyorlar
    Sunucuya doğrudan Lua veya Python gibi bir yorumlayıcı gömülüp yapılandırma yönetimi onunla yapılsaydı bu sürecin çoğu atlanabilirdi; en azından özel yapılandırma dosyalarını programlarla yamamaktan daha basit olurdu
    Elbette bu özel yaklaşımların genel amaçlı dillerden daha iyi optimize edildiği söylenebilir, ama bu iddia baştan beri böyle bir düzeneğin gerekmeyeceği oyuncak örneklerin dar kapsamına uyuyor
    Windows INI dosyalarını hatırlıyor musunuz? Kodun kod, verinin veri olduğu güzel günlerdi
  • Önümüzdeki 96 saat içinde birilerinin LLM ile nginx ya da Caddy yapılandırma dosyalarını zeroserve'in kullanabileceği koda dönüştürüp paketleyen bir araç yapabileceğini hayal etmek zor değil
    Daha basit bir yaklaşım olarak, bir Kubernetes kümesindeki tüm Ingress manifest'lerini okuyup pack'i baştan üretmek de mümkün olabilir
    Mesele şu ki araçlarla yapılandırma arasındaki arayüz de sadece başka bir API; sistem yöneticileri zaten sistem durumunu daha yüksek seviyeli yapılarla tanımlıyor ve yapılandırmayı oluşturan somut baytlar da bunun çıktısı oluyor
  • Karmaşıklığı soyutlayıp makrolarla “yapılandırma dosyası” tarzı bir kurulum elde etmek nasıl olur diye düşünüyorum
  • Yapay zeka giderek daha çok insan dili → makine etkisi kurabildiği için bu tercihin değişip değişmeyeceğini izlemeye değer gibi görünüyor
    Yapay zeka açısından bu yöntem daha yönetilebilir olabilir. Yapay zeka her iki tarafı da idare edebildiği için, böyle bir geçişin açıkça iyi bir fikir olarak yerleşmesi uzun zaman alabilir
  • Neden bu kadar ısrarla krediyi LLM'ye vermek istiyorsunuz anlamıyorum. Metnin yazımında LLM'den yardım alınmış olması, deneylerin de LLM tarafından yapıldığı anlamına gelmez

• Fikir hoşuma gitti
  Ama eBPF dizinine .c dosyaları yerine .rs dosyaları koyabilseydik daha içim rahat olurdu. Sonuçta zaten bir Rust projesi
  Bir de nedense çekirdek hızlandırmalı bir web sunucusu beklemiştim. Eğer eBPF ile güvenli biçimde yapılabilirse gerçekten çok etkileyici olur
  Ayrıca tek iş parçacıklı mı? Linux'ta fork edip gelen bağlantı kuyruğunu paylaşmak neredeyse önemsiz bir iş ve Rust'ta da birkaç satır sürer. SO_REUSEPORT kullanırsanız gerisini çekirdek halleder
  Bu arada io_uring'i zorlayacaksanız bence kTLS'yi de zorlamalısınız. El sıkışmadan sonra kullanıcı alanında SSL işlemeyi ortadan kaldırabilmek tasarımı ciddi biçimde sadeleştirir

  • Teşekkürler. fork + SO_REUSEPORT uygulamayı planlıyorum
    Şimdiye kadar bu tür işler için nftables kullandığım için buna doğrudan ihtiyaç duymamıştım

• Çok havalı. Bunu XDP programı ya da soket haritalarına bağlanan programlar gibi diğer BPF program türleriyle birleştirip L7 HTTP işlevlerini daha alt katmanlara entegre etmek mümkün olur mu merak ediyorum

• Fikir güzel ama statik dosyalara odaklanmak doğru mu emin değilim. Artık çoğu insan bu amaç için yeni bir sunucu ayağa kaldırmıyor

  • Geçen hafta Ghost'u statik hâle dönüştürürken tam olarak bunu yaptım ve kendi içinde her şeyi barındıran tek bir binary daha hızlı olabilir mi diye yarı ciddi düşünüyordum
    O yüzden bu bana sanki benim için yapılmış gibi geliyor, ama tipik kullanıcı olmadığımı da kabul ediyorum
  • Bu, alanına göre değişir. Birçok bilim alanında büyük veri kümeleri statik dosya biçimleri üzerinden verimli şekilde sunuluyor. Örneğin https://zarr.dev/ veya https://parquet.apache.org/ gibi

• İyi görünüyor ve özellikleri de fena değil. Ama bir yerlerde fazla yapay hissettiriyor, bu yüzden içime tam sinmiyor.
  Metriklerin sahte olup olmadığını, yardımcı fonksiyonların gerçekten çalışıp çalışmadığını, düzgün bir hardening yapılıp yapılmadığını bilemiyorum.
  Vibe coding ile yapılmış olmasını ve README'nin otomatik üretilmiş olmasını kabul edebilirim. Ama duyuru blog yazısının bile yapay zeka tarafından üretilmiş olması, ayrıca yazılım kalitesi anlayışının benimkiyle aynı olup olmadığını değerlendirecek hiçbir dayanak bırakmıyor.
  Garip bir dünyadayız. Birkaç yıl önce yapay zeka belirtmeden yayımlansaydı muhtemelen hiç şüphe duymadan kabul ederdim; şimdi ise şık bir README ve makul görünen komut satırı parametreleri görünce, README'nin halüsinasyon ürünü olabileceğinden ve gerçekte o seçeneklerin hiç bulunmayabileceğinden hemen şüpheleniyorum.

  • Yazarı benim. Bu projenin bazı çekirdek kısımları, örneğin async-ebpf, bu tür kodlama ajanları ortaya çıkmadan çok önce yazıldı.
    zeroserve'ün kendisini geliştirirken yapay zekadan epey yardım alıyorum ama yapay zeka çıktısını bizzat doğruluyor ve sorumluluğunu da ben üstleniyorum.
  • Benchmark'lara bakınca, 174B boyutundaki küçük bir statik dosyada zeroserve 36,681 req/s ve p99 5.4ms, nginx 31,226 req/s ve p99 7.8ms, Caddy ise 12,830 req/s ve p99 22ms veriyor.
    zeroserve, tek çekirdekte küçük dosyaları nginx'ten yaklaşık %17 daha hızlı sunuyor ve tail latency de daha dar. HTML sayfaları, küçük JSON ve CSS, zeroserve'ün iyi sonuç verdiği durumlar.
    100KB'lik büyük statik dosyada ise zeroserve 8,000 req/s, 782 MB/s, p99 22ms; nginx 7,600 req/s, 773 MB/s, p99 28ms; Caddy de 6,084 req/s, 590 MB/s, p99 44ms veriyor.
    Yine de ben böyle yeni bir proje yerine denetlenmiş, gerçek dünyada kanıtlanmış ve hardening'den geçmiş eski bir projeyi tercih ederim. İyileşme farkı, riski almaya değecek kadar büyük değil.
  • Gerçekten üzücü bir durum. Yakın zamanda ffmpeg-wasm projesi vardı ve test ettiğimde çalışıyordu. Ama vibe coding yapay zekasıydı ve ben yapay zekaya tahammül edemiyorum. Çalışıyor olması da bunu değiştirmiyor.
    Mümkün olduğunca eski usul dönemde kalmaya karar verdim. Akıllı insanlar yazılım yayımlıyor ve akıllı insanlar bakımını yapıyor. Onların yapay zekaya ihtiyacı yok. Benim nişim de bu.
    Yok olabiliriz ama yine de o taraf daha iyi. Tabii bunun için o akıllı insanların dokümantasyon da yazması gerekiyor. Dokümantasyon yazmaktan hoşlanmayan çok akıllı insan da var.
    Çok zaman önce, dokümantasyonu olmayan yazılım ne kadar harika olursa olsun zamanımı harcamaya değmeyeceğine karar verdim. Bu daha çok uygulamalar tarafı için geçerli; Linux dokümanlarına neredeyse hiç bakmadım ama başkaları o kadar da kötü olmadığını söylüyor, bilemiyorum.

• İlginç bir yeni kavram ve hoşuma gitti.
  Asıl soru geliştirici bağlılığı ve topluluk. Caddy ve Nginx tarafındaki insanlar ürün desteğini istikrarlı biçimde sürdürdü; bu proje de çok fazla odak ve ilgi gerektirecek.

• Neden tarball?

  • Kaynaklara byte aralıklarıyla erişmeyi kolaylaştıran basit bir format ve herkesin bunun için araçları var; en önemlisi de sıkıştırılmamış olması.
  • “One tarball, served in place” bölümünün ilk paragrafına göre tüm site tek bir tar dosyası ve zeroserve yükleme sırasında bunu indeksleyip yol üzerinden bir byte-range map oluşturuyor, ardından dosyaları sunmak için tarball'ın kendisi üzerinde byte aralığı okumaları yapıyor.
    Diske hiçbir şey açmıyor. Site tamamen o tek dosyanın içinde olduğundan, hatalı location kurallarının açığa çıkarabileceği bir document root yok ve dağıtım da tek bir atomik dosya değişimiyle yapılabiliyor.
    Ama bu açıklama da LLM usulü bir gerekçelendirme olabilir. Yazının çeşitli yerlerine “the right shape” ya da “the surface is broad” gibi ifadeler serpiştirilmiş.