Monolithic design again?

05 Aug 2016

I just skimmed though the release announcement and also some linked pages including the mbed-os github repo and it seams the whole OS has the same monolithic design (all targets etc. in one repo) as it had in mbed classic (mbed OS 2). for me this seems like a step backwards rather than forwards as the modular design in mbed OS 3 using yotta was much more elegant and in my eyes also easier to use.

05 Aug 2016

Hi Martin,

The core mbed OS platform that is always included has moved to just a single source repository (although which parts are pulled in is configurable), but components that are created and composed around the OS to form applications (like drivers, middleware) still remain as separate components.

The main observation was that all the components of the core OS are well known, are developed and tested together, and fundamentally want to all move together as they develop. The benefit of the modularisation of the core didn't outweigh the cost of managing them all separately across many different repos, versions and theoretically exposing many different internal APIs that people may or may not rely on.

However, that trade-off is certainly not the same when it comes to things you compose around the OS, which can be all sorts of combinations and contributions from partners and the community. For that, one repo really hurts, and it is much better to make it easy to pull in and compose different libraries from different sources, including some you created yourself.

So the core OS becomes one large component in that system managed in one repo (with configuration so you only pay the cost for what you need), and your application is composed of that plus any other modules you want to pull in or create. Conceptually slightly less elegant, but fundamentally more pragmatic.

Thanks, Simon

02 Dec 2016

Simon Ford wrote:

Hi Martin,

The core mbed OS platform that is always included has moved to just a single source repository (although which parts are pulled in is configurable), but components that are created and composed around the OS to form applications (like drivers, middleware) still remain as separate components.

The main observation was that all the components of the core OS are well known, are developed and tested together, and fundamentally want to all move together as they develop. The benefit of the modularisation of the core didn't outweigh the cost of managing them all separately across many different repos, versions and theoretically exposing many different internal APIs that people may or may not rely on.

However, that trade-off is certainly not the same when it comes to things you compose around the OS, which can be all sorts of combinations and contributions from partners and the community. For that, one repo really hurts, and it is much better to make it easy to pull in and compose different libraries from different sources, including some you created yourself.

So the core OS becomes one large component in that system managed in one repo (with configuration so you only pay the cost for what you need), and your application is composed of that plus any other modules you want to pull in or create. Conceptually slightly less elegant, but fundamentally more pragmatic.

Thanks, Simon

I suppose that makes some sense logically, but it still doesn't FEEL right.

I always envisioned Yotta as being a huge step for embedded c/c++ software development. Configuring a build is the first and maybe the biggest barrier to entry of embedded programming and I believe Yotta can change that.

I also really respected the fact that Yotta was designed for c++ development as a whole versus locked into being an mbed application specific tool.

Now we're stuck with mbed-cli, the same boring mercurial based repository host... and to me, the same stale mbed legacy community.

Don't get me wrong, I still think everything the mbed dev team is doing is amazing!

But I don't think mbedOS 3 was given enough time to pick up steam before deciding to do an entire year of rework.