Live data from Hacker News

Althttpd: Simple webserver in a single C file

sqlite.org

171–180 of 345 posts

Re: Althttpd: Simple webserver in a single C file

#171
post #113

Earlier quoted context omitted.

Yes and no. Debugging a binary protocol is a bit more difficult then a text one; which is the reason HTTP is ascii based.

The reason HTTP is ASCII based isn't because it's easier to debug. It's because back then the other end was as likely to be a human as a piece of software. Because HTTP in it's early days barely had headers or even formatting, so people typed "GET /" at the server directly or used the same method to send mail directly. Nobody does that anymore and debugging is easily solved by converting your binary protocol to a tex…

I don't think this is about human readability (albeit it might be to some extent during the design phase). Instead, I think this was the sensible thing to do when byte order was way more variable across a network. If you only send single bytes to begin with, you can as well use a textual format, IMO.

Re: Althttpd: Simple webserver in a single C file

#172
post #139

Earlier quoted context omitted.

Having commits that do not build represents the history more accurately. It could very well be a “fix” to some build error that silently introduces an issue, that context is lost when you squash.

Representing the history more accurately is not a useful design goal

Representing the history more accurately is a useful design goal

Re: Althttpd: Simple webserver in a single C file

#173
post #16

Earlier quoted context omitted.

if you run gnu/linux and are worried by C code running... I have bad news for you.

The google security team is working on fixing this with rust.

Indirectly, they're also pushing for "fixing" of Firefox with Rust (only 84%[?] to go!)

Re: Althttpd: Simple webserver in a single C file

#174
post #139

Earlier quoted context omitted.

Having commits that do not build represents the history more accurately. It could very well be a “fix” to some build error that silently introduces an issue, that context is lost when you squash.

Representing the history more accurately is not a useful design goal

Why not? I do not see any reason to have a history at all for anything except to be able to go back to a specific version to track down a problem. Inaccurate history makes that less useful.

Re: Althttpd: Simple webserver in a single C file

#175
post #139

Earlier quoted context omitted.

Squashing for example allows me to have a history where each commit builds. This has been very useful for bisecting for me. I wouldn't call it "next to nothing". The "greater detail" part can cost me a lot of time.

Having commits that do not build represents the history more accurately. It could very well be a “fix” to some build error that silently introduces an issue, that context is lost when you squash.

Storing every single version of the file which ever hit disk locally on my machine in the history would be the most accurate, yet no one seems to advocate for that. Even with immutable history, which versions go into the history is a choice the developer makes.

Re: Althttpd: Simple webserver in a single C file

#176
post #161

Performance is really bad. This is good for running a small HTTP server on an embedded device but if plan is to use it for HTTP server to serve production web traffic performance is really bad. Below is report of running the server and hitting a minimal index.html page and hitting it with artillery. All virtual users finished Summary report @ 09:39:57(-0400) 2021-06-08 Scenarios launched: 33645 Scenarios completed: 2…

It serves sqlite.org just fine. Most people don’t need FANG tools.

I'm not sure I would call Apache or Nginx "FANG tools" (or FAANG tools)

Re: Althttpd: Simple webserver in a single C file

#177

There is also redbean ( https://justine.lol/redbean/ ) - a single-file web server with embedded Lua interpreter as an Actually Portable Executable by Justine Tunney, the creator of Cosmopolitan.

That is amazing. And it looks like she may embed SQLite in as well.

Re: Althttpd: Simple webserver in a single C file

#178
post #91

Take a look at Fossil too: https://www.fossil-scm.org/ It's the distributed version control (and more) used by SQLite. Most people have no idea about how cool the SQLite ecosystem is, and how it's used even on avionics!

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

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

Re: Althttpd: Simple webserver in a single C file

#179
post #91

Take a look at Fossil too: https://www.fossil-scm.org/ It's the distributed version control (and more) used by SQLite. Most people have no idea about how cool the SQLite ecosystem is, and how it's used even on avionics!

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.

Fossil does has the ability to squash commits.

The difference is that Fossil does not promote the use of commit-squashing. While it can be done, it takes a little work and knowledge of the system. Consider the premature-merge problem in which a feature branch is merged into trunk before it is ready, and subsequent typo fixes need to be added. To do this in Fossil you first move the errant merge onto a new branch (accomplished by adding a tag to the merge check-in) then fix the typo on the original feature branch, then merge again. So in Fossil it is a multi-step process. Fossil does not have a "rebase" command to do all that in one convenient step. Also, Fossil preserves the original errant check-in on the error branch, rather than just "disappearing" the check-in as Git tends to do.

The difference here is a question of priorities. What is more important to you, an accurate history or a clean history that tells a story? Fossil prioritizes truth over beauty. If you prefer a retouched or "photoshopped" history over an auditable record of what really happened, Fossil might not be the right choice for you.

To put it another way, Fossil can squash commits, but another system might work better for you if commit-squashing is your go-to method of dealing with configuration management problems.

Re: Althttpd: Simple webserver in a single C file

#180

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

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

Right. Reading the entire conversation shows the parent messaging is FUD.
Post reply on HN