Mongoose OS – An Open Source Operating System for the Internet of Things
mongoose-os.com
mongoose-os.com
> Micropython Moving to production (C/C++) or factoring out critical pieces to C/C++ is not trivial
VS.
> mJS - JavaScript engine for prototyping and C/C++ for production
I don't know much about it, but from the surface it seems that the problem is exactly the same? What is the benefit of prototyping in JS instead of Python? In the end, either you refactor everything purely in C, or you use both in your production system.
I see mJS does FFI to interface with other C routines. Why introduce a second language to your project? This seems like a huge overhead for no benefit (you're still expected to write C at some point). The language is only a subset of JS, so "not JS", so no ecosystem and new assumptions you have to redefine before getting serious with it?
Is it just me who thinks it's a bad idea? Would someone be able to explain the advantage of going in this direction?
Therefore, the industry has been looking for ways to combat both the below par developer experience, and the development time. Samsung's Jerryscript [1] is another example.
That said, I think these things are aspiration more than they are practical.
Note: Edited to clarify C++ vs. dynamic languages.
But I'm mostly wondering the actualy benefit of choosing mJS instead of micropython to do so. It seems that both are capable of handling this problem, however mJS seems aiming at a compromise between JS and C, and my opinion on this is that it will introduce huge overheads on any projects. This mostly stems from my being wary of multi-language projects.
The process involved in embedded platforms seems heavy enough as it is, no need to blur the lines further.
I agree with your concern: to me Micropython seems like a much better choice. On the other hand, it's pretty limited to what hardware it runs on.
Also, MicroPython has pretty much all the features of core Python whereas mJS appears to have pretty much all the useful features of JS removed. Why not just use C instead of mJS?
Finally, couching Mongoose in a way that criticises the efforts of others is a bit of a turn off for me. Give me positive reasons for using your product rather than bashing the people you believe are your competitors. The culture and community of a project is important - negativity such as this is a worrying signal.
Perhaps mjs has a repl? Don't really know, but that would be the only real advantage imo.
For others, having a simple way to prototype fast on the target hardware is a big benefit.
If i was having an IoT company or start-up, i would make sure to hire proper engineers; the ones that have no problem with switching between Javascript, C, and Python, or learning them on the fly if needed.
Seriosly, is this really a problem at all?
It is obvious that it is quicker to prototype in Python or JS or whatever scripting language. While for real world usage you would also care about performance and efficiency issues which would better be solved by having more direct control over the bare-metal (C, even assembler.)
Yes. I write Python and C everyday. I am highly proficient in both. I would quickly withdraw from a project that mixes both in the same code base.
I'd also be slightly alarmed to see someone claiming to be able to distinguish proper engineers and not being aware of the issue with multi-language projects :-) .
My issue with multi-language project is that you introduce a lot of overhead to the process surrounding the code. The code-review / static analysis, build and test all requires an additional toolchain and associated best practices. It is already an issue with single-language projects to do this right, it quickly becomes a nightmare when you introduce an additional language.
And that's without even considering the need of FFI integration or likewise, with possibly (preferably) framework to handle the generation of the interfaces, and thus the introduction of another dependency, a possible sub-par codebase with the associated bugs, and potentially very subtle bugs due to your objects not playing nice with the intermediate representation.
I did it with a C++ / Java interface, never again. I would never greenlight such a project.
This has nothing to do with the proficiency or the willingness to learn of your engineers.
This confuses me, the GPLv2 doesn't say anything about commercial use, it merely says that you need to redistribute the source code to anyone that you distribute your software to.
Have they placed additional restrictions on the GPL (which I believe you are prohibited from doing)? or are they just trying to highlight that they are dual-licensing it under a license that isn't copyleft if you pay them (since lots of companies have no-gpl policies)?
https://github.com/mongoose-os-libs/mqtt/blob/master/LICENSE
In practice everybody acts under the assumption that the GPL affects all code that is statically linked together, but nothing else. Some people extend the interpretation to dynamic linking, but consensus is that the GPL does not affect code interoperating over other interfaces like web APIs.
Not a lawyer, but I don't see how that flies. They could make their own GPL-like license with that clause added in. But using it as-is means it's open for commercial use, subject of course to the GPL terms. https://www.gnu.org/licenses/gpl-faq.html#GPLCommercially
It would be the equivalent of writing a GUI plugin for WordPress and trying to sell it as something like Squarespace.
Not that I agree with this possibility of Mongoose OS's approach. I don't at all, and think it would completely negate their "open source" claim, from a semantical standpoint.
A workaround is a plugin mechanism with dynamic loading of .dll or .so libraries. But that won't fly on a microcontroller.
If you are building a library and you want it to be open source but also usable by products that are not open source, you can use LGPL. If you are building a proprietary library and you want to keep it proprietary, but link it into a GPL application, I think there is nothing is stopping you from doing that.
You still have an open-source application, it just won't work without the proprietary library.
(This sounds like it should be against the letter of the GPL, but as a thought experiment, pretend someone else wrote the library. Say, Nvidia, and you are Linus. You have no control over how their library gets licensed, and there is no person or body which can stop you from releasing your own code as GPL, even if it may have branches that depend on proprietary code.)
Doing OSS this way is most certainly against the spirit of the GPL, but I think it is within the letter.
> .dll won't help with GPL, only with LGPL (IANAL)
Was pretty much totally ambiguous about what exactly was meant.
I assume what they mean is that you can purchase a special license which allows you to use moongoose without GPL (typically for proprietary use), for example, x264 and x265 (well known GPL licensed encoders for h264 and h265) does exactly this.
At that point, doesn't the trivial defense just become "It's not GPL. It's my own custom license which happens to have all the requirements of the GPL plus $my_awesome_additions"?
> Door bell - ESP32, AWS IoT
> Door sensor - ESP32, MC-38, AWS IoT/MQTT, SNS
> Smart heater on AWS IoT
> IoT doorbell that works via MQTT - generic MQTT server, AWS IoT, Google IoT, etc
Why the hell would I want my door bell be controlled via MQTT on AWS?
It's probably one of first examples, like "Hello World!". Who in their right mind would write hello world, they are written for all languages already.
https://www.alittletothewright.com/index.php/2017/05/doorbel...
With the first child, I made the mistake of hanging out of the window at 10PM trying to get the attention of the pizza guy so he didn't ring the door bell so we got to eat in peace.
By the third child, you could set a firework off in the living room and she'd stay in bed.
Be noisy! Be free!
I think a smart doorbell is a great idea for a product.
The Old Way - Varies, depends on many factors. Requires ongoing investments, hiring developers or integrators
The New Way - GPLv2 license: FREE FOR NON-COMMERCIAL USE / Commercial License: CONTACT US
So with Mongoose OS, you don't have to invest, or hire developers? Am I being unfair by thinking that, while the other points make life easier, this is scraping the barrel a bit?
Why not just say "and the price which gets you all of these advantages is.." ?
https://github.com/cesanta/mongoose - that's the project from which Mongoose OS stems.
spark(hadoop tool vs java framework), yarn (hadoop tool vs facebook pkg manager), ...
In the section on their main page contrasting with arduino, they bascailly just say that they're more reliable, with nothing to really back that up.
Looking at their documentation, I don't really see how they can make that claim. The issues with Arduino's reliability stems, IMO, from the fact that Arduino code isn't an RTOS. Ie. there's no separation of real time priorities. This also seems to not really be an RTOS either, just a fancy bare metal environment.
What is this structurally bringing to the table beyond Arduino other than "we think we wrote the code better"?
Security: TLS 1.2, x509 certificates, ability to stop random people from flashing your board)
Remote management: OTA process doesn't seem that different from other methods, but they have some other nice things. For example they make it really easy to separate your code from your configuration.
That part in particular seems like a really bold assumption.
http://janos.io/ https://www.youtube.com/watch?v=0qgIObR6jGs http://mono.hm/
Yocto project creates a custom embedded distro based on your needs https://www.yoctoproject.org/
Zephyr supports hardware that can't easily run Linux https://www.zephyrproject.org/
On a serious note though - Does anyone know a mass manufactured product (based on a uController) that actually uses anything other than C/C++?
Rust is a strong contender too, surprised to not see it mentioned here. See an older discussion about Rust on ARM Cortex M[2]
1. https://twitter.com/ppatierno/status/894575063562936321 2. https://news.ycombinator.com/item?id=14071282
None that I know of, but ESP8266 and similar MCUs are so widespread that probably there are lots of products using say nodemcu (ESP+Lua scripting) under the hood. http://nodemcu.com/index_en.html
Wifimcu is a similar product but uses a STM32F4 MCU. http://www.wifimcu.com/
I would personally love to see more use of Nim in this field; it just seem the right tool for the job for being easy to learn, small, fast and powerful.
While I can't say I know intimately all the problems that need to be solved for IoT to responsibly reach mass consumption, but I'm pretty sure having an operating system wasn't the problem. Maybe this is just an enterprise cash grab?
So first off, the project is GPLv2 whether you use it for commercial or non-commercial use. The team's first language is not English, they are actually Russian and based out of Ireland, so there is bound to be some confusion. What they were basically trying to say with that, is if you need the extra features and the backend, etc. Those are not GPLv2 but the project itself is--no matter how you use it--is. I mentioned it to them team and they already corrected the site.
Second, the value proposition behind this is tremendous. Remember the days before Unix and DOS/Windows ran on every machine in the world? Every machine had its own design, its own arch/cpu, its own OS, and its own interfaces. Computing was cool, but each machine was really an island. If you wanted to run your code on another machine then you had to port it over. Then Unix and CP/M-80/DOS came along and you could write something on one machine and it ran (almost) on anything with the same OS. Thats the name of the game here. This is groundbreaking for embedded/IOT development.
Real embedded development is hard enough as it is. If you're doing a one off project for something in your home, then its pretty straightforward. Now try and take that to a mass production-scale product and the level of complexity is increased 50x.
Imagine trying to bring a product to market, you need to pick a hardware platform/MCU to build with. Now imagine your suppliers hit a chip shortage and you can't use that chip, what do you? Sit back and wait for 6 months? What Mongoose OS allows you to do is write your code once and run it on multiple embedded platforms, you would just select another MCU, maybe make some minor modification to the pinouts, flash the firmware and BAM, you are back in business. Not to mention the fact that you have standard interfaces across all devices, MCUs, etc. It just makes development so much simpler.
Not only that, but you now have to manage potentially hundreds of thousands of devices (or millions if your product is really successful). What do you? How do you handle firmware updates? How do you track status of all those devices? How do you do customer support without a debug interface, well the enterprise offering (or something like AWS IOT) will help you manage that process and make your life a whole lot easier.
Now on the topic of why mJS vs. Python and a mix of C. You have to understand that embedded development is often EXTREMELY resource constrained. mJS fits into ~25K of flash space and less than 1K of RAM. This is awesome. It affords you the smallest possible functionality with the greatest possible flexibility. Write your logic in js and then call C for anything more critical/performance.
I asked one of the team members and basically what he said was (I paraphrase) that mixing C with a scripting language is a pretty production ready solution. Obviously its preferable to write the critical pieces in C and then the higher level logic in the higher level language. It would be ideal if you could have type safety and compile-time checks in the high-level language. The ideal language to write logic in would be Go, and Go 2 promises to have a smaller runtime/footprint so hopefully one day that will be a possibility.
In terms of everyone else talking about how the project is positioning itself, well let's just say that marketing is a work in progress ;)
I'll refer you to this page on the site, https://mongoose-os.com/docs/overview/security.html. It'll give you a pretty good overview of where the teams head is at. Mongoose is using ARM mbedTLS with a few patches to optimize for small memory constraints. Theres support for quite a few of the most common crypto chips which are used. All the supported cloud platforms (AWS, GCP and Adafruit I/O) as well as the mqtt support and local http/ws support all have the options to turn enable tls. The greatest think, imho is that its possible to fully encrypt the flash on the espressif chips. For those who don't know, those chips are pretty prolific in IoT and AFAIK mongoose is the only platform (aside from the Espressif SDK itself) which can do that. So pretty keen on security.
Your point about automatic device update being hacked is just FUD. There are can be multiple attack vectors on any given device, and thats why great security doesn't just happen, it has to be a pervasive part of the underlying philosophy of the platform. All the sound bases are kind of covered here, encryption on almost every level, from the application level to the transport level to the flash itself.
I agree, but having said that, I have been trying to use Mongoose on the CC3200 and it is very difficult with Mongoose and mJS. Mongoose with mJS occupies upwards of 225K of flash, and the CC3200 only has 256KB of RAM (and the program must be loaded into RAM to execute). Plus I believe you lose another 16K to the Mongoose bootloader.
But this is more of a problem with the CC3200, admittedly; 256KB of RAM isn't great for an internet-connected device.
^ Contact us for pricing