[kwlug-disc] UNIX in 1982

[Ronald Barnes]

Chris Frey wrote on 2024-10-18 19:18:

> Hard to say... one is 32bit the other is 64bit (i.e. larger), one 
> might be caching much more, keeping code and data in memory just in 
> case.
> 
> I think the comparison is pretty fair, because it doesn't take much 
> code to serve files over TCP and HTTP.

Is there some module(s) loaded, like mod_php? That'd be my first guess.

Also, defaults on caching and memory consumption have probably changed 
over the years, one would have to look at the defaults in place back in 
the 32 bit era on a specific distro then configure today's version to match.

*Then* one could draw some comparisons on size & speed.  Which could be 
quite interesting!


I mean, the whole CGI bin thing went away, replaced by mod_{perl|php}, 
then came back with fcgi.  Cycle of life, things change, etc.



> Yet there is an argument that such features don't belong in the
> browser.  You could code this as an HTTP proxy, or a pluggable module
> in apache or nginx as well.

Interesting idea, but now browser devs have a whole bunch more work to
do, then field all the bug reports when some (now) external module a 
user depended on isn't loaded.

Not sure if there are gains to be had here, but it is interesting.


> Firefox for example comes by default with nearly a programmer's IDE 
> full of debug and analysis tools: console, network, profiler, 
> debugger, etc.
> 
> That's a choice, and it's been made for you.  Not everyone needs
> that in their browser

Most users won't use any of those features, but most of those tools are 
just exposing the rendering engine to reporting and manipulation and 
probably don't add much bulk as a percentage of executable size.


Also, keeping them means devs can use the browsers that have the tools, 
and devs recommend what devs use, and that is (or at least was) a strong 
driver of which tech becomes popular.


Thanks...