Linux as the default for the sort of devices mbed is focusing on is, plain and simple, not feasible by any shape of the imagination. The first constraint is memory; the microcontroller world is full of very powerful chips that can only address a few kilobytes of memory. Using a chip capable of running any sort of Linux kernel means limiting yourself to chips that cost at least 5-10 times more than other chips, plus the added cost of RAM, plus the design costs associated with the extra chips and discrete components, etc. Second, you are limiting what you can do with the chip; Linux, for example, has no support for being an SPI slave device, so if that's part of your design requirements, you now have to start writing your own kernel drivers for something that's almost always built into other OSes/frameworks for microcontrollers.

Finally, for many tasks, your code will end up being more complicated. Because power consumption tends to be crucial in a lot of designs, you want to spend as much time as possible sleeping, waking up only to handle whatever event you received. As such, most microcontroller frameworks have excellent support for event/interrupt-centric programming, where a device will only wake up long enough to handle the input at hand before going back to sleep. Linux just doesn't have the apis needed to support this sort of behavior well, which means you either need a proper real-time microkernel under Linux to handle your i/o, or you're going to be stuck putting all of your operations in kernel space, negating the point of Linux.

In short, stating Linux should be the default is short-sighted and neglects a lot of what is going on in the systems that mbed is focusing on. Trying to wedge it in, or even think of wedging it in, is going to make your device more expensive, and less useful, than using the right tool for the job from the get-go. All the world does not need to be Linux.

Linux won't run on most Cortex-Ms that this is for. These devices have 192KB of RAM on the high end and no MMU.

Linux also means higher hardware costs and bigger size and worse peripheral selection. Those are critical parameters in this market.

Generally, that's the way it's going but there are still many situations where a lightweight real-time kernel like uC/OS or ThreadX, etc. is preferable.

I'd really rather not have my toaster running, e.g., bash, since a toaster will never get firmware upgrades.

Linux doesn't run without an MMU (cortex M only has an MPU). Furthermore, I don't think one size fits all. Putting a server OS on an embedded system is nuts and will hurt you across the board (power consumption, performance, ... etc.).

I agree this has to be considered. I see this pattern some times: wow, this small device is really fun to work. Now I want to hook a camera (usb) and process the data (opencv) to do something. And I realize I should've been using arm + linux.

Linux is just too big. And we need variety to explore new ideas.

Maybe some people like reinventing the wheel with every piece of code they write Or, they like having a pool of only a couple hundred people that can help with problems, instead of a couple hundred thousand. Or they don't like the freedom to program in fifty different languages. Or they don't like a thoroughly tested, mature, code base. Perhaps they don't like when their code runs on multiple different processor architectures. Maybe they hate the abundance of freely available communication protocols, file systems, and graphical frontends. Maybe they're overwhelmed by the ease of searching for solutions to common problems because of linux's ubiquity.

I don't get it.