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.
Yes.
> bigger size
If you're comparing something like a bare ATTiny to a Raspberry Pi, sure, but the size difference between a standard Arduino and the Pi isn't great.
> worse peripheral selection
Um, compared to what?
mbed, a new operating system, will have to have drivers written for everything it supports - which is likely much shorter list than for Linux.
Until you solve this mindset problem(god knows how), GPLv3 isn't a workable solution.
Right now I've got a dishwasher that pukes on every second cycle. I know it's a software problem, yet their solution is to replace the whole controller board, taking months to diagnose and order a new one. Luckily I don't own it, so I'm only paying for this circus with my time.
The quip about GPL3 was meant as one possible example, although it does line up incentives pretty well. Users should be wary of devices that have worked quite well with mechanical timers/thermostats/etc being replaced with an essentially infinitely complex microcontroller, and the solution for taming that complexity to be the manufacturer retaining indefinite control.
But solving that is much, much bigger than just open-sourcing embedded code.
Also
>>Oh I'm well aware. Version control with something other than zip files isn't compatible with the mindset of embedded developers :P
That's one thing the mbed default IDE(web ide) does well - it gets people to use version control.
It certainly beats the current standard of manufacturers dropping firmware support after 5 short years, and older devices being left completely high and dry for the sheer majority of people that don't update appliances based on fashion.
I don't get it.