The problem is that the bottom end of 1k RAM still exists. In fact, because the main change is that it gets cheaper every year, it's even more prevalent. Just because there aren't lots of blog posts, doesn't mean that isn't a large proportion of the industry.

The word 'embedded' is not well defined, but if you use it on things with 1GB of RAM, what do you call a PIC with 1K?

My personal definition of embedded (which is of course still flawed) is anything without an MMU. A Raspberry Pi isn't embedded for instance, it's just a small computer, just like a phone.

Then what do you call a server with a CPU+MMU for its remote management or an iPhone with a CPU+MMU for its secure enclave? A cluster?

There is certainly a lot of technical merit in calling the five-inch thing in my hand a distributed system of multiple computers, but in practice it's not the common definition.

> The word 'embedded' is not well defined

> ...

> My personal definition of embedded (which is of course still flawed) is anything without an MMU

Probably "embedded" would better be defined as an electronic device capable of performing digital computations small enough to be put literally into other stuff, usually everyday things.

And nobody has suggested to use it on such tiny devices. "Embedded" spanning a large range of devices isn't new. 20 years ago, mainboards for high-end x86 CPUs of the day that were made to be put into industrial devices were already called "embedded". Because they're embedded into machines etc.

If you mean tiny devices, why not say "microcontroller" or something?

>The word 'embedded' is not well defined, but if you use it on things with 1GB of RAM, what do you call a PIC with 1K?

_very_ embedded

1K ram embedded device surely doesn't even exist in compute scenarios where kubernetes operates. There's very different fields

We're still in a place where there are millions of embedded devices out there in actual real world use where these resource constraints are real.

Would you put or even need Kubernetes for those devices?

Using MicroEJ, RTOS, Zephyr, mbed and other OSes to target Cortex-M4/ESP32 devices already allows for lots of possiblities with 512KB.

Yes 1GB is huge, my Windows Phones are capable of so much with a tiny portion of it.

At some point in time, the physical realities of electrons and metal wires will kick in. Then the growth will stop and you'll start kicking your own ass about performance and pointer arithmetic and cache policy.

Maybe that point in time is now, maybe it isn't. But it is coming nonetheless, that is one thing we can be sure of.

True, but not for all developers.

For at least 50% of developers, the "physical reality" is that of gathering client requirements quickly and accurately and implementing them correctly and on budget.

Not of micro-optimizing CPU cache hits :)

You missed the point.

A day will come when CPU speeds and RAM sizes will stop increasing. When that day comes you don't be able to ignore performance, because a lack of performance will mean actual, real-world dollar costs for the client, and so performance will be the #1 requirement of the client.

CPU speeds haven't changed much in 10 years, and to be honest, I would argue that performance has been getting worse and is not a priority for many/most developers.

The client doesn't seem to care, and just sees the 5-20 second webpage load times as totally normal (at my company/industry at least). Our applications are horrifically slow, but we're still the market leaders in our segment

> The client doesn't seem to care, and just sees the 5-20 second webpage load times as totally normal

Yes, but will they tolerate 2 minute page load times? 10 minute?

At some point reality kicks in and you start to have to care about the nuts-and-bolts hardware.

Most of the time those things are caused by gross development errors, not by cache hits. Stuff like looping while sending an individual SQL query for each record.

I didn't miss it. For the vast majority of applications, which are Line Of Business (LOB) applications, performance doesn't really matter. It's good enough.

LOB applications are made to replace humans and they need to be a multiple of times faster than human operations (+ the extra benefits of automation). And the vast majority of them are. And most programmers are working on those applications.

So there's 0 incentive for what you're saying.

The real heavy lifting will be done, as usual, by a handful of people: OS devs, DB devs, game engine devs, runtime devs, etc.

Implying nobody would bat an eyelid at performance problems in LOB applications...