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

121–130 of 345 posts

Re: Althttpd: Simple webserver in a single C file

#121

Post by emn13 »

layoutIfNeeded wrote: post #114
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,…

I want to be able to tell why a given line of code was introduced. Seeing "Fix indentation" in the output of `git blame` won't help me with that.

git blame --first-parent

Re: Althttpd: Simple webserver in a single C file

#123

Post by pdimitar »

emn13 wrote: post #116
pdimitar wrote: post #109

Earlier quoted context omitted.

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.

But that's what a merge commit is - the diff along the merge commit is what the squashed commit would be; the only thing squashing does is "forget" that the second parent exists (terminology for non-git VCS's may be slightly different). Why not merge?

Because in big commercial projects several people or teams merge inside the main branch on a regular basis. It's easier to look at a history only including squashed commits each encompassing an entire PR (feature or a bug).

It gives you better high-level observability and a good bird's-eye view. And again -- if you need more details you can go and check all separate commits in the PR/branch anyway.

And finally, squashed commits are kind of atomic commits. Imagine history of three separate PRs happening at roughly the same time. And now all those commits are interspersed in the history of the main branch.

How is that useful or informative? It's chaos.

EDIT: my bad, I conflated merging with rebasing. Still, I prefer a single squashed commit for most of the reasons above, plus those of the other two commenters (useful git blame output and buildable history).

Re: Althttpd: Simple webserver in a single C file

#125

Post by elliotf »

layoutIfNeeded wrote: post #114
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,…

I want to be able to tell why a given line of code was introduced. Seeing "Fix indentation" in the output of `git blame` won't help me with that.

I also want to be able to tell _why_ which is why I dislike working on codebases that squash commmits. Too many times I've done a blame to see why a change was made, and it's a giant (> 10) list of commit messages. Oftentimes, the macro description of what was going on does not help me with the line-level detail.

Also, in case it helps you in the future, `blame -wC` is what I use when doing blame; it ignores whitespace changes and tracks changes across files (changes happened before a rename, for example.)

Re: Althttpd: Simple webserver in a single C file

#126

Post by jedimastert »

niutech wrote: post #120

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.

Everytime I come across Justine's work, I'm always amazed.

Re: Althttpd: Simple webserver in a single C file

#127

Post by emn13 »

pdimitar wrote: post #123
emn13 wrote: post #116

Earlier quoted context omitted.

But that's what a merge commit is - the diff along the merge commit is what the squashed commit would be; the only thing squashing does is "forget" that the second parent exists (terminology for non-git VCS's may be slightly different). Why not merge?

Because in big commercial projects several people or teams merge inside the main branch on a regular basis. It's easier to look at a history only including squashed commits each encompassing an entire PR (feature or a bug). It gives you better high-level observability and a good bird's-eye view. And again -- if you need more details you can go and check all separate commits in the PR/branch anyway. And finally, squas…

Oh yeah, rebasing branches as a "merge" policy is definitely tricky like that. (I mean, I'm sure some people do that with and perhaps with good reason, but it makes this kind of stuff clearly worse).

Re: Althttpd: Simple webserver in a single C file

#128

Post by throw0101a »

zaarn wrote: post #113
daitangio wrote: post #107

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 question the ascertain that humans were doing "GET /" or "HELO my.fq.dn" on any regular basis. There were mail clients from the very beginning for example:

* https://en.wikipedia.org/wiki/History_of_email

Perusing document-based information was also done via clients, first with Gopher and then with the WWW: either GUIs like Mosaic, or on the CLI via (e.g.) Lynx.

Re: Althttpd: Simple webserver in a single C file

#129

Post by zaarn »

throw0101a wrote: post #128
zaarn wrote: post #113

Earlier quoted context omitted.

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 question the ascertain that humans were doing "GET /" or "HELO my.fq.dn" on any regular basis. There were mail clients from the very beginning for example: * https://en.wikipedia.org/wiki/History_of_email Perusing document-based information was also done via clients, first with Gopher and then with the WWW: either GUIs like Mosaic, or on the CLI via (e.g.) Lynx.

I would question if this weren't the case often enough that people would demand it be compatible with their teleprompter.

Re: Althttpd: Simple webserver in a single C file

#130

Post by minusf »

wongarsu wrote: post #77
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.

Apache's thread-per-connection model used to run basically the entire internet until nginx came along and demonstrated 10k simultaneous connections on a single server. If you only have around 100 concurrent confections, a separate thread per connection is entirely feasible. A whole new process is probably fine on Linux, but e.g. Windows takes pretty long to spawn a process

the default mode in apache/apache2 used to be _process_ per connection (pre forked workers) not thread per connection. threads came much later.
Post reply on HN