In general, stable syscall numbers are just a Linux thing. Everyone else uses blessed system libraries
Show HN: Building a web server in assembly to give my life (a lack of) meaning
51–60 of 246 posts
Re: Show HN: Building a web server in assembly to give my life (a lack of) meaning
#52Re: Show HN: Building a web server in assembly to give my life (a lack of) meaning
#53Re: Show HN: Building a web server in assembly to give my life (a lack of) meaning
#54I'm wanting to read this repository as a learning tool, so it'd also be nice to include docs—even AI-generated docs, but obvious I'd prefer docs with your own design notes and decisions—about the architecture of the code. Really cool project though!
Re: Show HN: Building a web server in assembly to give my life (a lack of) meaning
#55Humbling.
Re: Show HN: Building a web server in assembly to give my life (a lack of) meaning
#56Maybe it's finally time to move on from being a career programmer.
Re: Show HN: Building a web server in assembly to give my life (a lack of) meaning
#57An agentic LLM should be pretty good at Arm64 assembly generation, but maintainability of large code could become an issue. Why would it not run on Linux?
I wrote it for MacOS because I don't have a Linux machine right now :( Once I get one up and running again, I'll probably work on porting this. As for why it wouldn't run on Linux, there are some pretty big differences in the actual assembly. One pretty superficial difference is calling conventions -- MacOS uses the x16 register for syscall numbers, Linux uses x8. Calling the kernel in Mac uses "svc #0x80", in Linux…
Re: Show HN: Building a web server in assembly to give my life (a lack of) meaning
#58Even though it's a meaningless comparison, I'd be interested to see how performance compares (max requests per second?) for this compared to fully-featured web servers.
In a comparison between a similar fork-per-connection server written in C and this, I would imagine the throughput would be about the same, because the bottleneck in this model is fork() itself rather than the actual code. It probably matters more for binary size and startup time than requests/sec. Would be fun to actually benchmark, though.