ymawky - servidor web hecho directamente en ensamblador ARM64

• ymawky es un servidor web de archivos estáticos escrito únicamente en ensamblador ARM64; funciona sin libc, usando solo syscalls, y opera con una estructura que hace fork por cada conexión
• El objetivo de desarrollo es MacOS y solo puede ejecutarse en Apple silicon arm64; para compilarlo se necesitan Xcode Command Line Tools y make
• La ejecución predeterminada inicia en 127.0.0.1:8080; se puede especificar el puerto, pero actualmente no se admite una dirección personalizada y solo funciona en 127.0.0.1
• La raíz de documentos es www/ por defecto; GET / busca www/index.html, y las páginas de error están configuradas para servirse desde err/(code).html
• Los métodos HTTP soportados son GET, PUT, DELETE, OPTIONS, HEAD; no soporta ejecución de código del lado del servidor ni parsing avanzado de URL como /search?query=term
• PUT soporta por defecto subidas de hasta 1GiB y escribe primero en el archivo temporal www/.ymawky_tmp_<pid> antes de hacer rename, para evitar que una subida parcial sobrescriba un archivo existente
• GET soporta solicitudes Range: bytes= y maneja los formatos bytes=X-N, bytes=-N, bytes=X-, por lo que se indica que también funciona bien para la búsqueda en video
• Detecta el tipo MIME según la extensión del archivo y envía el encabezado de respuesta Content-Type; reconoce muchas extensiones de archivos web, imágenes, fuentes, documentos, video, audio y archivos comprimidos
• Como protecciones de ruta, rechaza rutas de tamaño PATH_MAX o mayor, bloquea escapes de ruta basados en .., antepone www/ a todas las rutas solicitadas y usa O_NOFOLLOW_ANY para rechazar rutas que incluyan symlinks
• Para mitigar DoS del tipo slowloris, si pasan más de 10 segundos entre lecturas o si la recepción completa de encabezados tarda más de 10 segundos, cierra la conexión y devuelve 408 Request Timeout
• Las solicitudes HTTP/1.1 requieren el encabezado Host:; aunque el valor de Host no se usa realmente, se exige la presencia del encabezado según la Sección 3.2 de RFC 9112
• En config.S se pueden ajustar la raíz de documentos, el directorio de páginas de error, el archivo predeterminado, el timeout de recepción, los límites de velocidad y tamaño de PUT, y el número máximo de procesos simultáneos
• Para portarlo a Linux u otros Unix, habría que modificar los registros de llamada de syscall y svc, la forma de retorno de errores, fork(), SO_NOSIGPIPE, O_NOFOLLOW_ANY, renameatx_np(), el layout de estructuras, la sintaxis de relocaciones Mach-O, el manejo de señales y otros elementos

[GN⁺]

Comentarios de Hacker News

• En la práctica, cuando uno escribe programas grandes en ensamblador, especialmente con un ensamblador de macros, enseguida se da cuenta de que no es algo fundamentalmente distinto de la programación de alto nivel, solo más verboso
  Al final basta con acostumbrarse a crear abstracciones con procedimientos y macros, y muchas veces leer ensamblador de forma efectiva es bastante más difícil que escribirlo

  • Durante este trabajo yo también me di cuenta de lo mismo. Hay que escribir todo de forma mucho más explícita, pero la manera en que funciona cada función individual no es fundamentalmente distinta
    strlen, ya sea en C, Rust, Assembly o cualquier otro lenguaje, al final recorre la cadena buscando el byte NULL. Como uno escribe de forma explícita exactamente qué tiene que hacer la CPU y en qué orden, a veces incluso se siente más intuitivo que otros lenguajes

• Es un proyecto realmente hermoso y muy bien hecho. Siguiendo la idea de otros comentarios, para mí este tipo de proyecto se parece más a un mapa de Minecraft
  Hay mapas enormes e impresionantes, mapas pequeños de supervivencia, mapas que abres localmente solo para ti y tus amigos, y también servidores comerciales que apuntan a una escala grande. Gracias a la IA, se volvió muy fácil construir casas en el servidor o diseñar caminos nuevos, pero el valor que se crea en ese mundo depende del propósito original del servidor y de si de verdad tiene sentido seguir agregando casas y caminos
  Está muy bien que los servidores comerciales puedan crecer más rápido y tener más casas y caminos, pero el cariño que produce un proyecto artístico no tiene comparación

• Me dio una sensación cálida saber que todavía hay gente que intenta hacer estas cosas a mano. No era solo yo

  • Me obsesioné con esta idea durante un tiempo y al final empecé, y me metí de lleno por completo durante varias semanas
    Si hay proyectos parecidos me gustaría verlos, y me alegra saber que no soy el único. Creo que si la mayoría de los programadores dedicara unas semanas o unos meses a aprender ensamblador, gran parte del misterio sobre cómo funcionan la CPU y los lenguajes compilados desaparecería

• Proyecto divertido. Tengo por ahí una versión mucho más minimalista para x86 Linux; si quieres ver cómo se ve, está aquí: https://github.com/jcalvinowens/asmhttpd

  • Vaya, ese proyecto de verdad fue una gran inspiración para mí. Lo leí hace tiempo y me impresionó muchísimo
    Me preguntaba si te parecería bien que agregara el enlace a tu repositorio en mi README

• Esa falsa portada de libro de O'Reilly está buenísima

  • De hecho, ese libro fue exactamente lo que me llevó a hacer esto desde el principio. El subtítulo del libro dio lugar al acrónimo del nombre del proyecto

• Aunque sea una comparación un poco sin sentido, me da curiosidad qué tanta performance tiene frente a servidores web con todas las funciones. Me gustaría ver métricas como el máximo de solicitudes por segundo

  • Sinceramente todavía no he hecho benchmarks, pero sospecho que ymawky será bastante más lento que la mayoría de los servidores web completos
    ymawky usa una estructura de fork por conexión, así que es fundamentalmente más lento que el enfoque que usan servidores orientados a producción como nginx o Apache. nginx usa I/O basado en eventos con kqueue/epoll, lo que le permite manejar miles de conexiones concurrentes sin el costo de hacer fork de un proceso por cada solicitud. Apache usa pools de hilos para atender múltiples conexiones sin crear uno nuevo por cada solicitud
    Si lo comparas de frente con otros servidores web, en la práctica casi siempre estarás midiendo la diferencia entre fork por conexión y un loop de eventos o un pool de hilos, y eso tiene poco que ver con el ensamblador
    Si se comparara con un servidor similar escrito en C que también haga fork por conexión, supongo que el throughput sería casi el mismo. El cuello de botella de este modelo no es realmente el código, sino fork() en sí. Probablemente el mayor impacto estaría en el tamaño del binario y el tiempo de arranque más que en las solicitudes por segundo. Aun así, sería divertido medirlo de verdad

• Muy bien hecho. Yo también estoy trabajando en un proyecto parecido pero más pequeño con RISC-V, y esto está excelente

  • Está realmente genial. Si lo tienes publicado en algún lado, me encantaría verlo

• Como quiero ir un poco a contracorriente de hacia dónde va este mundo del vibe coding, y volver a sentirme desafiado, estoy intentando escribir un renderizador por software en WebAssembly
  No sé si lo vaya a terminar, es una locura y tampoco diría que sea útil. Pero se siente muy bien
  Felicidades al autor original por el logro

  • Yo hice exactamente lo mismo y fue realmente divertido. No era para sacar algo nuevo al mundo, sino simplemente un reto entretenido para mí mismo
    Después de terminarlo, estoy haciendo un juego con eso, pero ahora que ya se fue la emoción del reto, casi no avanzo por ese lado. Igual no importa, porque fue divertido. Si lo hubiera hecho con vibe coding, no habría obtenido esa diversión ni esa satisfacción
  • ¿Te refieres a un renderizador por software 3D? Aprendí muchísimo haciendo cosas así con x86 y C cuando era adolescente y al inicio de mi carrera
    Quise ver qué tan bien un LLM podía escribir un renderizador para CGA en puro ensamblador 8088, así que se lo pedí, y de una sola vez produjo un demo bastante decente. En el prompt le metí los vectores de una nave de Elite
    https://imgur.com/a/Dy5rUku

• Uno de mis primeros proyectos en ensamblador fue un script CGI escrito 100% en ensamblador x86
  Un servidor web completo sin duda es más impresionante. Aun así, si alguien está empezando, recomendaría primero buscar CGI de Apache y mod_cgi

  • Vaya, sinceramente creo que escribir un script CGI en ensamblador me daría más miedo que escribir el servidor en ensamblador
    Llevo unas semanas pensando en soporte CGI, pero todavía no me he metido a fondo. Si está alojado en algún sitio, me gustaría verlo; podría ser una buena referencia para cuando me ponga a trabajarlo más adelante

• Mientras nosotros nos estamos pasando a la IA y dejamos de escribir código y de quebrarnos la cabeza, aquí alguien está escribiendo un servidor web en ensamblador
  Te pone humilde

  • Sí, te pone humilde. Tengo clarísimo cuál de los dos caminos prefiero
  • ¿Quiénes son “nosotros” aquí? Yo no tengo tan poco amor propio como para entregar código mediocre generado por una máquina en lugar de hacer bien mi trabajo