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…
Althttpd: Simple webserver in a single C file
171–180 of 345 posts
Re: Althttpd: Simple webserver in a single C file
#172Earlier 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
Re: Althttpd: Simple webserver in a single C file
#173Re: Althttpd: Simple webserver in a single C file
#174Earlier 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
Re: Althttpd: Simple webserver in a single C file
#175Earlier 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.
Re: Althttpd: Simple webserver in a single C file
#176Performance 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.
Re: Althttpd: Simple webserver in a single C file
#177There 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.
Re: Althttpd: Simple webserver in a single C file
#178Take 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
> 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
#179Take 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.
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
#180Earlier 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