Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Althttpd: Simple webserver in a single C file

sqlite.org

Post reply on HN
Print view View original

221–230 of 345 posts

Re: Althttpd: Simple webserver in a single C file

#221

Post by scruple »

JoeQuery wrote: post #217
metalliqaz wrote: post #178

Earlier quoted context omitted.

from the linked thread: > I just cloned your repo. Everything is working fine. Breath, Zed. seems like he panicked and made it worse, then rage-quit

It's been a few years but my one and only interaction with Zed via an email exchange showed me he was quite unstable and prone to outbursts. Never meet your heroes, they say.

I had exactly one interaction with him, too, whereby he shared with me a very long list of companies that he knew of which were hiring at the time, this would've been around 2012 or so. I got quite a few interviews as a result, and quite a few offers, FWIW, though I ended up taking a job with a company that wasn't on this list.

I understand both that he is and why he is such a polarizing figure. Just wanted to put my positive anecdote on the pile, since they seem to be a less common when he comes up in online comments.

Re: Althttpd: Simple webserver in a single C file

#222

Post by postalrat »

pjc50 wrote: post #24

/* ** Test procedure for ParseRfc822Date */ void TestParseRfc822Date(void){ time_t t1, t2; for(t1=0; t1 There's only two billion integers, guess we can test them all. Well, substantially fewer than two billion with that skip. I wonder if that completes in a few seconds.

How would you write a better test?

IMO most tests are fundamentally flawed. The way most testing is done it would be easier and better to just write everything twice, have a method to compare results, and hope you got it right at least once.

Re: Althttpd: Simple webserver in a single C file

#223

Post by falcolas »

sydthrowaway wrote: post #61
cube00 wrote: post #35

> A separate process is started for each incoming connection, and that process is wholly focused on serving that one connection. It makes you wonder just how "heavy" operating system processes actually are. We may not need to worry about the complexity of trying to multiple run async requests in a single process/thread in all cases.

So what was the point of the async/callback web programming revolution if processes were good enough?

To add on to every other sibling comment, switching threads or processes requires a trip back up to the kernel space (a context switch), instead of just remaining in user space. in this switch, all of your caches get busted.

Not a problem for most folks, but when you want the greatest possible performance, you want to avoid these kinds of transitions. Basically, the same reason some folks use user-space networking stacks.

Re: Althttpd: Simple webserver in a single C file

#224

Post by papaf »

Jach wrote: post #202
systems wrote: post #169

Earlier quoted context omitted.

long long long time ago Fossil destroyed code for Zed Shaw And since that day, not one looked at Fossil the same way, at least not the same way they looked at git https://www.mail-archive.com/fossil-users@lists.fossil-scm.o... I can't tell for sure how much of impact this had on fossil's adoption, its hard to beat git no matter how good you are, but I think it was a bit hit

I'm pretty familiar with a lot of Zed's doings but I had missed this one. I doubt it impacted the adoption much, losing one advocate like that isn't going to doom your project. I finally gave Fossil a serious try last year for a few months, just on my own but I don't think my opinions would change if I tried in a team setting. I still love the idea, but the execution is... ghetto. Serviceable, certainly, but ghetto i…

And git+[choice of issue tracker]+[choice of forum]+[choice of wiki]+[choice of project website]+etc. is the real competition against Fossil

I think that this is only true for some projects. For some people, the ease of self hosted setup (one executable) and the fact that you can change the documentation, edit code and close bugs offline is a big win that no centralized service can compete with.

Re: Althttpd: Simple webserver in a single C file

#225

Post by GordonS »

Winsaucerer wrote: post #58
ecmascript wrote: post #3

I'm all for SQLite and I am a fan of the author of the project but for a webserver I have turned my back away from Nginx for https://caddyserver.com/ because of the simplicity. Caddy is just really awesome as a reverse proxy (2 line config!!) and I am in the processes of moving all my projects to it. It is fast enough as well since other things will be the bottle neck way before that. I am not affiliated with Caddy i…

I fiddled around for many hours with traefik, and could not get it to do what I wanted -- something I'd done before and had a known example working config of. 10 minutes of caddy, I had everything running exactly as I wanted and the job was done.

I tried Traefik for the first time around 6 months ago (version 2) - man, coming from nginx (which I wouldn't call simple), I found Traefik config to be really confusing. It felt like I had to specify the same stuff 2 or 3 times, and in general it was just so unintuitive. And the docs (at the time at least) only showed snippets of trivial examples.

I don't think I'd choose to use it again. Instead, I'll try Caddy, or HAProxy if I need massive performance.

Re: Althttpd: Simple webserver in a single C file

#226

Post by skeeter2020 »

emn13 wrote: post #103
pdimitar wrote: post #100

Earlier quoted context omitted.

The lack of ability to squash PRs into single commits is a deal breaker for many, myself included. No, having a commit "fix typo" in the main branch's history is not at all useful and won't ever be. It's noise. In a work setting it's much better to reduce noise.

I never understood the point of squashing if you just want the short version, only read the merge commits; if you want the full details to figure out some bug or whatever, then yes, I want those fix typo commits most definitely, because as often as not, those are at fault. Squashing buys you next to nothing, and costs you the ability to dive into the history in greater detail. I suppose if your project is truly huge,…

greater detail can ultimately lead to less information if noisy commits crowd out the important ones. IME you want a commit to mean something and that usually leads to tweaking the work/change/commit relationship, which is where squashing helps.

Re: Althttpd: Simple webserver in a single C file

#227

Post by scruple »

chrismorgan wrote: post #68
lmilcin wrote: post #50

Earlier quoted context omitted.

Binary protocols aren't (or at least don't have to be) any more difficult and frequently are even easier to implement. Text protocols have difficult problems like escaping or detecting the end of particular field that are frequent source of mistakes. The issue is that many (especially scripting) languages treat binary data as second class. The only real issue is that inspecting the binary message visually is little b…

And capitalisation issues, and encodings… give me a binary protocol to parse any time. They’re normally comparatively well-defined, whereas text protocols are seldom properly defined and so have undefined behaviour left, right and centre, which inevitably leads to security bugs—or even if they are well-defined, they’re probably done in a way that makes your language’s string type unsuitable, and makes parsing more co…

> give me a binary protocol to parse any time

I don't disagree in principle but I've come across a handful of very poorly documentated binary protocols in my years and that is an extremely painful thing to deal with compared to text-based protocols.

Re: Althttpd: Simple webserver in a single C file

#228

Post by skeeter2020 »

pdimitar wrote: post #109
emn13 wrote: post #103

Earlier quoted context omitted.

I never understood the point of squashing if you just want the short version, only read the merge commits; if you want the full details to figure out some bug or whatever, then yes, I want those fix typo commits most definitely, because as often as not, those are at fault. Squashing buys you next to nothing, and costs you the ability to dive into the history in greater detail. I suppose if your project is truly huge,…

Having full history in the feature branch is mandatory -- nobody is disputing that, myself included. All due diligence is done there, not in the main branch. The main branch only needs to have one big commit saying "merging PR #2169". If you need more details you'll go that PR/branch and get your info. The "fix typo" commit being in the main branch buys you nothing. It's only useful in its separate branch.

This is fine if its how your team develops but not for everyone. We don't care about full history in branches; maybe it has more detail than main/master but it should still be contextually meaningful. I'd never approve a commit into main with the message "merging PR #xxx" either; it's redundant (merging), has no summary about what it actually does and relies on an external system (your PR/MR process) for details. I do agree that keeping noise out of your main is key, but would go even further than you to keep it clean AND self-contained.

Re: Althttpd: Simple webserver in a single C file

#229

Post by kahlonel »

foxes wrote: post #115
Cthulhu_ wrote: post #48

Earlier quoted context omitted.

Your point being? It's been serving sqlite.org just fine for all this time. You seem to be making some pretty big assumptions about security here without actually explaining what your specific concerns are.

I think the original comment is partially a joke. Maybe there isn't specifically anything wrong with this, but there is the fact that it is written in C. Historically there is a good precedent of this being an issue. C does not guarantee correctness to the same level as more modern languages. If it was written in Haskell or Rust for example you could be more sure about correctness. I believe for something like this,…

People need to stop assuming that memory safety == functional safety. They are two very different things. Rust ensures memory safety, but it won't stop you from making logical mistakes. You can't be "sure about correctness" unless proven mathematically.
Post reply on HN