| I work on embedded appliance software at my job. A few comments: It's quite easy to find yourself having non-zero boot times for some unfortunate reasons. At least in my org, the software as a whole is RAM/ROM constrained rather than speed constrained. Even when you're this close to bare metal, devs tend to write over-abstracted code riddled with inefficiencies. And of course most people don't profile the application at all. This is a symptom of the software being under-tested imo. I have personally written tooling to integration test the whole application for a few appliances, and for one appliance initializing the application 56 times took over 1 second. On a modern machine it should take milliseconds. After profiling I found that 99%+ of our time was spent servicing a subscription tied to all events, that really only needed to subscribe to just one or two. Along with that there are other reasons for long apparent boot up times: - Waiting for other boards to connect and talk to each other. Your UI can't do anything until it knows the state from the main control. - Randomized delays to prevent current surges after a blackout. You'll see this on ACs or other appliances that might have hundreds of identical units in a building. - Waiting for flash memory to be readable All of this adds up to seconds of boot time. Yet ultimately none of this matters to the business people because we're an appliance company, NOT a software company. Our software is mostly incidental to having a functioning product, and boot times could go way higher without the business being worried. Though recently yes, we have entered the data market hence the push for smart features. Word to the wise, avoid any appliance with Android in it if you don't like the idea of forced connected features! I unfortunately don't have any solutions to most of the problems presented in the article. All I can do is continue to try writing bullet-proof software and push back against forced connected features. |