The logging framework isn't a bottleneck, and other lies your laptop tells you

I guess in a pinch but that is a solution that I just don't think I would like.... I would feel like we're going to figure this out, not surrender to the absurd...

Every customer except one used our app on linux machines, and every developer had linux environment, but sometimes you had to debug or build a new version of the software for that one windows customer.

In that case we connected through remote desktop to Rafał's Computer and worked there, because nobody could figure out how to make it work anywhere else.

Rafał quit that company 1 year after I came to work there. When I was leaving 6 years later the "Rafał's Computer" was a part of critical infrastructure and there was an effort to virtualize it :) It's a miracle it worked so long without disk failing TBH :)

I'm sometimes wondering if now, 5 years later - they still have Rafał's Computer around. Hopefully they managed to virtualize it eventually :)

Another problem with developing locally is that the dev is the only simultaneous user, and doesn’t have to share the resources with other users.

I guess the takeaway is to always validate your assumptions through measurements like profiling etc.

In my opinion is is much better to develop a cross platform/environment product that can work everywhere and the key to that is to avoid assumptions about where the product is executing. In the long run, this makes your software much more flexible.

I really doubt it has been that recent — I think the Great Migration to Macs started a decade earlier.

Meanwhile, a lot of us have been developing on Linux and deploying on Linux even longer still. Heck, that's a good part of how Linux got popular, although once upon a time it was develop on Linux in order to deploy on Solaris or HP-UX (or even AIX)!

For example, here's what you're looking for: https://www.supermicro.com/en/products/system/1U/1029/SSG-10...

Cloud computing price is still based around (illegally monopolized and price fixed) memory prices, which is absurd because two load-balanced NVME disks are comparably as fast as DDR3 RAM.

Anyway, I've been considering building some pcie/m.2 boards for a couple of markets because the price difference between a "consumer grade" board and the server/embedded board with nearly the same features but minus a couple important things for some markets is about $25 in parts, but the markup is about $500. Its even worse in some of the built for purpose devices where wrapping a bit of sheet metal around said machine adds another $2k+.

The m.2 vs U.2 market is such a shitshow at the moment. And if one of the major players decides to create a form factor that happens to be compatible with m.2? Well huge industry outcry because they might remove everyones fat margins on "enterprise" gear.

I've seen so many developers who can't understand that the average user isn't going to spend hours clicking through menus to find what they want.

It's about costs.

> Why is firmware initialization getting so darn slow when computers are getting faster?

That alone has zero bearing with regard to the initialization process is it doesn't have to compute stuff, but wait for signals and much, much slower IO/memory.

First, there's the out-of-band management engine, which is technically in control of everything. The BIOS and the Lights-Out management system are interdependent. They will communicate with each other.

Just initialising this communication channel is more complicated that a normal computers entire BIOS.

Then there's activating every sensor and hardware device, most servers aren't actually the 2 x86_64 CPUs that are socketed to the motherboard, they're more like 30+ CPU's, various hardware controllers, including networks, fan controllers, drive controllers, power supply controllers.

Each of them also has firmware equivelant of a whole BIOS, and they also will communicate with each other.

Thirdly, every sensor/firmware/device test is synchronous and logged. That logging is painfully slow as it's logging via the out-of-band management engine and that engine is super tiny and low power.

Finally all that memory will be tested and not 'assumed' to be fine. Each individual DIMM is blasted with voltage to test if it's seated well, then there is some memory testing which is not only more extensive than the 'fast check' your laptop will do, it's more heavy than the "heavy" check your laptop will do.

There's a bit more to it too, like the fact that memory gets "extended" into the out of band system so that it can control VGA/Serial/USB.

Edit: If you wish to microbenchmark - lock the CPU frequencies (core/uncore for intel), lock the voltage too and measure the power draw as well. You wish to use taskset too, depending how many cores the benchmark utilizes.

Having production quality hardware for the dev cycle is extremely valuable for these uses.

In aggregate yes the server cpu numbers are great. But looking at them per core makes them much worse. I checked some random Xeon Platinum CPU vs a mobile i7, both being Skylake (so essentially same microarch). The Xeon had 28 cores, 38.5M cache (=1.4M/core) and 6 memory channels(=0.2/core). In comparison the i7 had 4 cores, 8M cache (=2M/core) and 2 memory channels (0.5/core). The Xeon uses 25% faster memory, but that doesn't really make up the difference.

1. provide or give (a service, help, etc.). "money serves as a reward for services rendered"

2. cause to be or become; make. "the rains rendered his escape impossible"

3. represent or depict artistically. "the eyes and the cheeks are exceptionally well rendered"

You seem to be stuck on the 3rd definition (there are more, but 1, 2 and 3 cover everything we need here to see how it's appropriate based on both the server and client side actions.

The other way of looking to it is that the server renders [something] to HTML, and the client renders HTML to pixels.

It's quite common to refer to things being rendered to another forms, the term is not owned by processes with a visual output.