2 puan yazan GN⁺ 4 시간 전 | 1 yorum | WhatsApp'ta paylaş
  • ymawky, yalnızca ARM64 assembly ile yazılmış statik dosya web sunucusudur; libc olmadan sadece syscall kullanır ve her bağlantı için fork eden bir yapıyla çalışır
  • Geliştirme hedefi MacOS'tur ve çalışma yalnızca Apple silicon arm64 üzerinde mümkündür; derleme için Xcode Command Line Tools ve make gerekir
  • Varsayılan çalıştırma 127.0.0.1:8080 üzerinde başlar ve port belirtilebilir, ancak şu anda özel adres desteği yoktur; yalnızca 127.0.0.1 üzerinde çalışır
  • Belge kökü varsayılan olarak www/ dizinidir; GET /, www/index.html dosyasını arar ve hata sayfaları err/(code).html üzerinden sunulacak şekilde yapılandırılmıştır
  • Desteklenen HTTP metodları GET, PUT, DELETE, OPTIONS, HEAD'dir; sunucu tarafı kod çalıştırma veya /search?query=term gibi gelişmiş URL ayrıştırma desteklenmez
  • PUT, varsayılan olarak en fazla 1GiB yüklemeyi destekler ve kısmi yüklemelerin mevcut dosyanın üzerine yazmaması için önce geçici www/.ymawky_tmp_<pid> dosyasına yazıp ardından rename eder
  • GET, Range: bytes= isteklerini destekler; bytes=X-N, bytes=-N, bytes=X- biçimlerini işler ve video içinde ileri-geri sarmayı da iyi desteklediği belirtilir
  • Dosya uzantısına göre MIME tipi algılayarak Content-Type yanıt başlığını gönderir; web dosyaları, görseller, fontlar, belgeler, videolar, ses dosyaları ve sıkıştırılmış dosya uzantılarının çoğunu tanır
  • Yol güvenlik önlemleri olarak PATH_MAX üzerindeki yolları reddeder, .. tabanlı dizin kaçışını engeller, tüm istek yollarına www/ öneki ekler ve O_NOFOLLOW_ANY ile symlink içeren yolları reddeder
  • slowloris türü DoS hafifletmesi için okuma aralığı 10 saniyeyi aşarsa veya tüm başlıkların alınması 10 saniyeyi geçerse bağlantıyı kapatır ve 408 Request Timeout döndürür
  • HTTP/1.1 isteklerinde Host: başlığı gereklidir; Host değerini fiilen kullanmasa da RFC 9112 Bölüm 3.2 uyarınca başlığın varlığını zorunlu kılar
  • config.S içinde belge kökü, hata sayfası dizini, varsayılan dosya, alım zaman aşımı, PUT hız ve boyut sınırları, maksimum eşzamanlı süreç sayısı gibi ayarlar değiştirilebilir
  • Linux veya diğer Unix sistemlerine taşımak için syscall çağrı register'ları ve svc, hata dönüş yöntemi, fork(), SO_NOSIGPIPE, O_NOFOLLOW_ANY, renameatx_np(), struct yerleşimleri, Mach-O relocation sözdizimi, signal handling gibi bölümlerin değiştirilmesi gerekir

1 yorum

 
GN⁺ 4 시간 전
Hacker News yorumları
  • Gerçekte assembly, özellikle de makro assembler ile büyük programlar yazmayı denediğinizde, bunun sadece daha ayrıntılı olduğunu ve yüksek seviyeli programlamadan temelde çok da farklı olmadığını çabucak fark ediyorsunuz.
    Sonuçta prosedürler ve makrolarla soyutlama kurmaya alışmak yeterli oluyor; ayrıca assembly’yi etkili biçimde okumak çoğu zaman yazmaktan çok daha zor olabiliyor.

    • Bu çalışma sırasında ben de aynı şeyi fark ettim. Çok daha açık seçik yazmanız gerekiyor ama tek tek fonksiyonların çalışma biçimi özünde farklı değil.
      strlen, ister C’de ister Rust’ta ister Assembly’de ya da başka bir dilde olsun, sonuçta dizgeyi dolaşıp NULL baytını bulur. CPU’nun tam olarak neyi hangi sırayla yapması gerektiğini doğrudan açıp yazdığınız için, bazen diğer dillere göre daha sezgisel bile gelebiliyor.
  • Gerçekten çok güzel ve iyi yapılmış bir proje. Diğer yorumların devamı olarak bakarsak, bu tür projeler bana daha çok Minecraft haritası gibi geliyor.
    Devasa ve hayranlık uyandıran haritalar da var, küçük hayatta kalma haritaları da, sadece arkadaşlarla ve kendin için yerelde açtığın haritalar da, ticari olarak büyük ölçeği hedefleyen sunucular da. AI sayesinde sunucuda ev yapmak ya da yeni yollar tasarlamak artık çok kolaylaştı ama o dünyada üretilen değer, sunucunun asıl amacına ve daha fazla evle yol yapmanın gerçekten anlamlı olup olmadığına bağlı.
    Ticari sunucuların daha hızlı büyüyüp daha fazla ev ve yola sahip olabilmesi harika ama sanat projelerinin ürettiği sevgi ile kıyaslanamaz.

  • Birilerinin hâlâ böyle şeyleri eliyle doğrudan yapmaya giriştiğini görmek içimi ısıttı. Bunu yapan tek kişi ben değilmişim.

    • Ben de bir süredir bu fikre takmıştım, sonunda başladım ve birkaç hafta boyunca tamamen içine gömüldüm.
      Benzer projeler varsa görmek isterim; bunu yapan tek kişi olmadığımı bilmek güzel. Çoğu programcının birkaç hafta ya da birkaç ay assembly öğrenmesi, CPU ve derlenen dillerin nasıl çalıştığına dair gizemin büyük kısmını ortadan kaldırır diye düşünüyorum.
  • Eğlenceli bir proje. x86 Linux için çok daha minimal bir sürüm yapmıştım; nasıl göründüğüne bakmak isterseniz burada: https://github.com/jcalvinowens/asmhttpd

    • Vay, o proje bana gerçekten büyük ilham verdi. Yıllar önce okuduğumda çok etkilenmiştim.
      README’me deponuzun bağlantısını eklememde sakınca olur mu diye merak ediyorum.
  • O sahte O'Reilly kitap kapağı gerçekten müthiş.

    • Aslında bunu yapmama neden olan şey tam olarak o kitaptı. Kitabın alt başlığı, projenin adının kısaltmasını verdi.
  • Pek anlamlı bir karşılaştırma olmasa da, tam özellikli web sunucularıyla kıyaslandığında performansın ne durumda olduğunu merak ediyorum. Saniye başına en yüksek istek sayısı gibi metrikleri görmek isterdim.

    • Dürüst olmak gerekirse henüz benchmark yapmadım ama ymawky büyük olasılıkla tam özellikli web sunucularının çoğundan epey daha yavaştır.
      ymawky bağlantı başına fork eden bir yapıda; bu da nginx ya da Apache gibi üretim ortamı sunucularının kullandığı yaklaşımdan temelde daha yavaş. nginx, olay tabanlı G/Ç için kqueue/epoll kullanıyor; böylece her istek için süreç çatallamanın ek yükü olmadan binlerce eşzamanlı bağlantıyı işleyebiliyor. Apache ise her istek için yenisini oluşturmak yerine birden fazla bağlantıyı işlemek üzere thread pool kullanıyor.
      Diğer web sunucularıyla doğrudan karşılaştırma yaparsanız çoğunlukla bağlantı başına fork ile event loop/thread pool arasındaki farkı ölçmüş olursunuz; bunun assembly ile pek ilgisi yok.
      Aynı şekilde bağlantı başına çatallayan bir sunucunun C ile yazılmış sürümüyle kıyaslansa, aktarım hızının neredeyse aynı olacağını tahmin ediyorum. Çünkü bu modelde darboğaz gerçek kod değil, fork() çağrısının kendisi. Saniye başına istek sayısından çok ikili dosya boyutu ve başlangıç süresine etki etmesi daha muhtemel. Yine de gerçekten benchmark yapmak eğlenceli olurdu.
  • Güzel iş. Ben de RISC-V ile benzer ama daha küçük bir proje üzerinde çalışıyorum; bu gerçekten harika.

    • Gerçekten çok havalı. Herhangi bir yerde yayımladıysan mutlaka görmek isterim.
  • Bu vibe coding dünyasının gittiği yöne bilerek ters gitmek ve yeniden meydan okunuyormuş gibi hissetmek istediğim için bir WebAssembly yazılım rasterizer’ı yazmayı deniyorum.
    Bitirebilir miyim bilmiyorum, çılgınca ve pek de faydalı denemez. Ama gerçekten iyi hissettiriyor.
    Asıl yazarı başarısından dolayı tebrik ederim.

    • Ben de tam olarak aynısını yaptım ve gerçekten çok eğlenceliydi. Dünyaya yeni bir şey çıkarmak için değil, sadece kendim için keyifli bir meydan okumaydı.
      Bitirdikten sonra onunla bir oyun yapıyorum ama artık meydan okuma hissi kalmadığı için o tarafta pek ilerleyemiyorum. Yine de sorun değil, eğlenceliydi. Vibe coding ile yapsaydım o eğlenceyi ya da tatmini alamazdım.
    • 3D yazılım rasterizer’ından mı bahsediyorsun? Gençlik yıllarımda ve kariyerimin başlarında x86 ve C ile bunlardan çok yaparak öğrendim.
      LLM’in saf 8088 assembler ile CGA için bir rasterizer’ı ne kadar iyi yazabildiğini görmek istedim ve denettim; tek seferde gayet iyi bir demo üretti. Prompt’a Elite gemisinin vektörlerini vermiştim.
      https://imgur.com/a/Dy5rUku
  • İlk assembly projelerimden biri, %100 x86 assembly ile yazılmış bir CGI betiği idi.
    Elbette tam bir web sunucusu çok daha etkileyici. Yine de yeni başlayanlara önce Apache’nin CGI ve mod_cgi tarafına bakmalarını öneririm.

    • Vay, dürüst olmak gerekirse assembly ile sunucu yazmaktan çok CGI betiğini assembly ile yazmak daha korkutucu geliyor.
      CGI desteği birkaç haftadır aklımda ama henüz ciddi biçimde içine dalmadım. Herhangi bir yerde barındırılmış örneği varsa görmek isterim; ileride bunun üzerinde çalışırken iyi bir referans olabilir.
  • Biz AI’a geçerken kod yazmayı ve kafa patlatmayı bırakıyoruz, burada ise biri assembly ile web sunucusu yazıyor.
    İnsanı alçakgönüllü yapıyor.

    • Alçakgönüllü yapıyor. Hangi yolu daha çok tercih ettiğim ise gayet açık.
    • Buradaki “biz” kim? Kendi işini düzgün yapmak yerine makinenin ürettiği özensiz kodu teslim edecek kadar özsaygımdan vazgeçmiş değilim.