|Number of watchers on Github||95|
|Number of open issues||2|
|Open pull requests||0+|
|Closed pull requests||0+|
|Last commit||over 4 years ago|
|Repo Created||over 7 years ago|
|Repo Last Updated||over 2 years ago|
|Organization / Author||jcalvinowens|
|Do you use asmhttpd? Leave a review!|
|View open issues (2)|
|View asmhttpd activity|
|View on github|
|Fresh, new opensource launches 🚀🚀🚀|
Software engineers: It's time to get promoted. Starting NOW! Subscribe to my mailing list and I will equip you with tools, tips and actionable advice to grow in your career.
Just run "make". You will need NASM on your system.
sudo ./asmhttpd "/path/to/your/webroot"
Q: Why? A: Just for fun, this is obviously completely impractical. Q: How tiny is it? A: The core of the daemon uses one single page of memory (4KB). It is quite literally impossible for a program to use less memory than this one does. Each connection allocates an additional 32KB. Q: Why do you use a thread-based model for serving files? A: Because it was substantially easier to write that way. Q: Why are all the source files #included into a single file? A: The linker doesn't handle code written like this very well. Twice, I spent a significant amount of time chasing bugs that turned out to be due to the linker incorrectly optimizing out chunks of code. Q: Why do you use NASM? A: It was what I was familiar with when I wrote it. NASM is actually a great little assembler, but the Intel syntax is a drag.
Bug reports are greatly appreciated! The most useful information is the line that probably got printed in `dmesg`, which shows the address of the instruction which caused the segfault. Core dumps are not of much use, but send them if you have them. If the bug doesn't crash the daemon, send me a very detailed description of what you did to cause the issue. My E-Mail is: firstname.lastname@example.org